iptables: O modo “script” ou o modo “* filter, rules, COMMIT”?

Question

Estou tentando descobrir como o NAT e o iptables funcionam. Enquanto eu estou na fase de tentativa e erro de aprender sobre isso, eu encontrei dois tipos de conflitos.

Um howto usa um script para chamar iptables regras uma após a outra. O script parece ser nomeado e armazenado de tal forma que é executado no início durante a inicialização do sistema, e acho que um problema pode ser que outros scripts possam ser chamados após ele e desfazer suas intenções. Eu até acho que fiz isso uma vez por acidente quando salvei e renomei o script original (00-firewall) usando um backup (00-firewall-old). O script de exemplo do howto é:

#!/bin/sh

PATH=/usr/sbin:/sbin:/bin:/usr/bin

#
# delete all existing rules.
#
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

# Always accept loopback traffic
iptables -A INPUT -i lo -j ACCEPT


# Allow established connections, and those not coming from the outside
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW -i ! eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow outgoing connections from the LAN side.
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

# Masquerade.
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

# Don't forward from the outside to the inside.
iptables -A FORWARD -i eth1 -o eth1 -j REJECT

# Enable routing.
echo 1 > /proc/sys/net/ipv4/ip_forward

Outro howto não usa um script, mas um arquivo onde algumas regras de filtragem são definidas. Parece assim:

*filter

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allows all outbound traffic
# You could modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allows SSH connections 
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
-A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT

# Now you should read up on iptables rules and consider whether ssh access 
# for everyone is really desired. Most likely you will only allow access from certain IPs.

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy:
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

Quais são os prós e contras das duas maneiras de configurar iptables? A informação de fundo é muito apreciada porque eu sou muito novo na coisa toda. Por exemplo, eu não entendo quem está lendo o arquivo do último howto e como ele é processado. Meu sentimento me diz o segundo howto sugere uma solução melhor, mas por que exatamente?

    

Answer 1

Eu usei as duas técnicas no passado. Nos dias de hoje, estou gravitando em direção a um híbrido dos dois.

Se o seu conjunto de regras tiver cinco ou seis regras simples, o método está bem. As coisas começam a ficar interessantes quando você tem grandes conjuntos de regras: grandes instalações, sua caixa de firewall faz um pouco de roteamento, etc.

Lembre-se, você pode atirar no próprio pé, não importa como você carregue seus conjuntos de regras. :)

Baseado em script

Você faz um script bash, um script Perl, um script Python - inferno, escreva um programa Lisp ou Befunge para todos se importam! No script, você cria todas as regras do Netfilter que deseja.

As vantagens:

• Direcionalidade. Você está experimentando regras e copia e cola as que funcionam diretamente da linha de comando para o script.
• Firewall dinâmico. Um cliente meu executa configurações de OpenVPN para seus próprios clientes, e cada cliente obtém sua própria instância do OpenVPN por motivos de segurança, firewall e contabilidade. O firewall de primeira linha de defesa precisa abrir as portas do OpenVPN dinamicamente para cada tupla (IP, porta). Portanto, o script de firewall analisa o manifesto das configurações do OpenVPN e dinamicamente envia os furos necessários. Outro armazena detalhes do servidor da web no LDAP; o script iptables consulta o servidor LDAP e permite automaticamente a entrada nos servidores da web. Em grandes instalações, esse é um grande benefício.
• Esperteza. Meus scripts de firewall permitem administração remota, mesmo sem o gerenciamento de luzes apagadas: depois que o conjunto de regras é carregado, se o operador não responder dentro de alguns minutos, o conjunto de regras é revertido para o último conhecido por funcionar. Se por algum motivo esse falhar, haverá um terceiro (e quarto) failback de segurança decrescente.
• Mais inteligência: você pode abrir o acesso SSH ao seu netblock no início do script, depois rescindi-lo no final do script (e deixar as sessões SSH filtradas entrarem). Então, se o seu script falhar, você ainda pode entrar lá.
• Exemplos online. Por alguma razão, a maioria dos exemplos que vi online usaram invocações de iptables (isso pode ser influenciado pelo fato de minhas primeiras configurações de firewall terem sido anteriores a iptables-save , e também pelo Netfilter - mas isso é outra história)

As desvantagens:

• Um erro de sintaxe no script e você está bloqueado no seu firewall. Parte da inteligência acima se resume a experiências dolorosas. :)
• Velocidade. Em caixas embutidas do Linux, um script bash (ou até mesmo traço) será lento e lento para ser executado. Devagar o suficiente para que, dependendo da sua política de segurança, você precise considerar a ordem da adição de regras - você pode ter um breve furo nas suas defesas, e isso é o suficiente. O carregamento do conjunto de regras é em nenhum lugar próximo à atômica.
• Complexidade. Sim, você pode fazer coisas incríveis, mas sim, você também pode tornar o script complexo demais para entender ou manter.

Baseado em regras

Adicione suas regras a um arquivo de conjunto de regras e use iptables-restore para carregá-lo (ou apenas salve seu conjunto de regras existente usando iptables-save ). Isto é o que o Debian faz por padrão.

Os profissionais:

• Velocidade. iptables-restore é um programa em C, e é deliciosamente rápido comparado a scripts de shell. A diferença é óbvia mesmo em máquinas decentes, mas é ordens de magnitude mais rápido em hardware mais modesto.
• Regularidade. O formato é mais fácil de entender, é essencialmente auto-documentado (uma vez que você se acostumar com as peculiaridades do Netfilter).
• É a ferramenta padrão, se você se importa com isso.
• Salva todas as tabelas do Netfilter. Muitas ferramentas do Netfilter (incluindo iptables ) operam apenas na tabela filter , e você pode esquecer que tem outras à sua disposição (com regras possivelmente danosas). Desta forma, você consegue ver todas as tabelas.

Os contras:

• Falta de flexibilidade.
• Com a falta de recursos de templates / parametrização / dinâmicos, a repetição pode levar a conjuntos de regras menos fáceis de manter e a enormes bugs de regras. Você não quer isso.

Uma solução híbrida - o melhor dos dois mundos

Eu tenho desenvolvido este por um tempo no meu Copious Free Time. Estou pensando em usar a mesma configuração baseada em script que tenho agora, mas depois que o conjunto de regras é carregado, ele salva com iptables-save e, em seguida, armazena em cache para mais tarde. Você pode ter um conjunto de regras dinâmico com todos os seus benefícios, mas pode ser carregado muito rapidamente quando, por exemplo, a caixa do firewall for reinicializada.

    

Answer 2

Parece-se com a saída de iptables-save e, consequentemente, a entrada para iptables-restore , que é usada para salvar e restaurar (por exemplo, na inicialização do sistema) o estado atual do firewall do netfilter.

O comando iptables manipula o firewall do netfilter. Ele pode ser usado para fazer uma única alteração na configuração do firewall ativo, por exemplo, a adição de uma única regra, mas também modificar ou excluir regras.

para que você crie a configuração desejada com o iptables, salve a configuração resultante com o comando iptables-save. E faça uma restauração dessa configuração após a reinicialização.

Ou faça um script dos comandos iptables que você usou para criar esse firewall: A opção -F limpa o firewall criando uma barreira em branco e, subsequentemente, a adição de regras em um script é uma alternativa ao uso do comando iptables-restore. estado final.

    

Answer 3

Concordo com o @zebonaut em que você precisa considerar cuidadosamente para garantir que seu firewall / roteador seja adequadamente protegido durante a inicialização e também durante o carregamento das regras. Acabei criando meus próprios scripts de criação de firewall e, quando testei, copiei para um script firewall.working, se os dois diferem, um trabalho cron executa o trabalho. Então, se eu ficar bloqueado, posso voltar. Isso é muito raro agora, já que as primeiras regras permitem tráfego estabelecido / relacionado. Eu tenho uma subcadeia diferente para cada interface para encaminhamento e entrada, facilita a depuração.

Eu tenho um arquivo de configurações separado que ativa / desativa certos acessos, o arquivo de configurações é alternado entre o dia e o modo noturno pelo cron para bloquear meus filhos para fora da internet quando eles deveriam estar na cama dormindo! Naturalmente eu também posso ultrapassar e bloqueá-los a qualquer hora que eu quiser : -)

O mesmo script manipula ipv4 e ipv6. Se eu usar um nome de host, eu o coloco em / etc / hosts ou no arquivo de configurações, em vez de confiar no DNS, porque se o DNS quebrar, a configuração do firewall será interrompida.