Esta é uma pergunta canônica proposta sobre como entender e depurar o firewall do software nos sistemas Linux.

Em resposta à resposta da EEAA e ao comentário de @ Shog, precisamos de uma sessão de perguntas e respostas canônicas adequada para fechar perguntas relativamente simples sobre tabelas de ip.

O que é um método estruturado para depurar problemas com o firewall do software Linux, a estrutura de filtragem de pacotes netfilter , comumente referida pelas tabelas de iptables da interface do usuário ?

Quais são as armadilhas comuns, perguntas recorrentes e coisas simples ou um pouco mais obscuras para verificar se um administrador de firewall ocasional pode ignorar ou se beneficiar do conhecimento?

Mesmo quando você usa ferramentas como UFW , FirewallD (aka firewall-cmd), Shorewall ou similar, pode se beneficiar de olhar sob o capô sem a camada de abstração que essas ferramentas oferecem.

Esta pergunta não tem a intenção de ser um guia prático para a criação de firewalls: verifique a documentação do produto e, por exemplo, contribua com receitas para o iptables Trips & Tricks ou pesquise nas perguntas marcadas como iptables ufw firewalld firewall-cmd para ver se há alta pontuação frequente e bem considerada Perguntas e Respostas.

Em geral:

A visualização e modificação da configuração do firewall requer privilégios de administrador ( root), assim como a abertura de serviços no intervalo de número de porta restrito. Isso significa que você deve estar conectado como rootalternativa ou usar sudopara executar o comando como root. Vou tentar marcar esses comandos com o opcional [sudo].

Conteúdo:

1. Questões sobre pedidos ou a diferença entre -Ie-A
2. Exibir a configuração atual do firewall
3. Interpretando a produção de iptables -L -v -n
4. Conheça o seu ambiente
5. As cadeias INPUT e FORWARD
6. Módulos do kernel

1. A ordem importa ou a diferença entre -Ie-A

É importante lembrar que as regras de firewall são verificadas na ordem em que estão listadas. O kernel interromperá o processamento da cadeia quando uma regra for acionada, permitindo ou desabilitando um pacote ou conexão.

Acho que o erro mais comum para administradores de firewall iniciantes é que eles sigam as instruções corretas para abrir uma nova porta, como a abaixo:

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

e então descubra que não terá efeito.

O motivo disso é que a -Aopção adiciona essa nova regra, depois de todas as regras existentes e, como muitas vezes a regra final no firewall existente era aquela que bloqueia todo o tráfego que não é explicitamente permitido, resultando em

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Ou equivalente em iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

e a nova regra que abre a porta TCP 8080 nunca será alcançada. (como evidenciado pelos contadores teimosamente restantes em 0 pacotes e zero bytes).

Inserir a regra com -Ia nova regra teria sido a primeira da cadeia e funcionará.

2. Exiba a configuração atual do firewall

Minha recomendação para o administrador do firewall é examinar a configuração real que o kernel do Linux está executando, em vez de tentar diagnosticar problemas de firewall usando ferramentas amigáveis. Muitas vezes, depois de entender os problemas subjacentes, você pode resolvê-los facilmente em um assunto suportado por essas ferramentas.

O comando [sudo] iptables -L -v -né seu amigo (embora algumas pessoas gostem iptables-savemais). Muitas vezes, ao discutir configurações, é útil usar a --line-numbersopção também para numerar linhas. Referir-se à regra #X facilita a discussão sobre eles.
Nota: As regras NAT estão incluídas na iptables-savesaída, mas precisam ser listadas separadamente adicionando a -t natopção ie [sudo] iptables -L -v -n -t nat --line-numbers,.

Executar o comando várias vezes e verificar incrementos de contadores pode ser uma ferramenta útil para verificar se uma nova regra é realmente acionada.

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Como alternativa, a saída de iptables-savefornece um script que pode regenerar a configuração de firewall acima:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

É uma questão de preferência o que você achará mais fácil de entender.

3. Interpretar a produção de iptables -L -v -n

A política define a ação padrão que a cadeia usa quando nenhuma regra explícita corresponde. Na INPUTcadeia que está configurada para ACEITAR todo o tráfego.

A primeira regra na cadeia INPUT é imediatamente interessante, pois envia todo o tráfego (origem 0.0.0.0/0 e destino 0.0.0.0/0) destinado à porta TCP 22 ( tcp dpt:22), a porta padrão do SSH para um destino personalizado ( fail2ban-SSH) . Como o nome indica, essa regra é mantida pelo fail2ban (um produto de segurança que, entre outras coisas, verifica os arquivos de log do sistema em busca de possíveis abusos e bloqueia o endereço IP do agressor).

Essa regra teria sido criada por uma linha de comando do iptables semelhante iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHou encontrada na saída do iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Muitas vezes, você encontra uma dessas notações na documentação.

Os contadores indicam que esta regra corresponde a 784.000 pacotes e 65 megabytes de dados.

O tráfego que corresponde a essa primeira regra é processado pela fail2ban-SSHcadeia que, como uma cadeia não padrão, é listada abaixo da cadeia OUTPUT.

Essa cadeia consiste em duas regras, uma para cada abusador (endereço IP de origem 117.253.221.166 ou 58.218.211.166) que está bloqueado (com a reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

Os pacotes SSH que não são desses hosts bloqueados ainda não são permitidos nem desabilitados e agora que a cadeia personalizada está concluída será verificada em relação à segunda regra na cadeia INPUT.

Todos os pacotes que não foram destinados à porta 22 passaram a primeira regra na cadeia INPUT e também serão avaliados na regra 2 de ENTRADA.

A regra de entrada número 2 faz com que isso pretenda ser um firewall completo , que rastreia as conexões. Isso tem algumas vantagens: apenas os pacotes para novas conexões precisam ser verificados com relação ao conjunto de regras completo, mas uma vez permitidos pacotes adicionais pertencentes a uma conexão estabelecida ou relacionada são aceitos sem verificação adicional.

A regra de entrada nº 2 corresponde a todas as conexões e pacotes abertos e relacionados que correspondam a essa regra e não precisará ser mais avaliada.

Nota: as alterações de regras na configuração de um firewall stateful afetarão apenas novas conexões, não conexões estabelecidas.

Por outro lado, um simples filtro de pacotes testa todos os pacotes em relação ao conjunto de regras completo, sem rastrear o estado da conexão. Nesse firewall, nenhuma palavra- chave de estado seria usada.

A regra de ENTRADA # 3 é bastante entediante, todo o tráfego conectado à interface de loopback ( loou 127.0.0.1) é permitido.

As regras 4, 5 e 6 de ENTRADA são usadas para abrir as portas TCP 22, 80 e 443 (as portas padrão para SSH, HTTP e HTTPS) concedendo acesso a NOVAS conexões (conexões existentes já são permitidas pela regra 2 de ENTRADA).

Em um firewall sem estado, essas regras apareceriam sem os atributos de estado:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

ou

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

A regra final de ENTRADA, nº 7, é uma regra que bloqueia todo o tráfego que NÃO foi concedido acesso nas regras de ENTRADA 1-7. Uma convenção bastante comum: tudo o que não é permitido é negado. Em teoria, essa regra poderia ter sido omitida configurando a POLÍTICA padrão como REJECT.

Sempre investigue toda a cadeia.

4. Conheça seu ambiente

4.1 As configurações em um firewall de software não afetam as configurações de segurança mantidas em outros locais da rede, ou seja, apesar de abrir um serviço de rede com iptablesas listas de controle de acesso não modificadas nos roteadores ou outros firewalls na rede, ainda pode bloquear o tráfego ...

4.2 Quando nenhum serviço estiver escutando, você não poderá se conectar e obter um erro de conexão recusada , independentemente das configurações do firewall. Portanto:

• Confirme se um serviço está escutando (na interface de rede / endereço IP correto) e usando os números de porta que você espera [sudo] netstat -plnutou usa como alternativa ss -tnlp.
• Se seus serviços ainda não deveriam estar em execução, emule um ouvinte simples com, por exemplo, netcat: [sudo] nc -l -p 123ou openssl s_server -accept 1234 [options] se você precisar de um ouvinte TLS / SSL (verifique as man s_serveropções).
• Verifique se você pode se conectar a partir do próprio servidor, telnet <IP of Server> 123ou seja, ou echo "Hello" | nc <IP of Server> 123ao testar o serviço seguro TLS / SSL openssl s_client -connect <IP of Server>:1234, antes de tentar o mesmo em um host remoto.

4.3 Entenda os protocolos usados ​​pelos seus serviços. Você não pode ativar / desativar adequadamente os serviços que não entende o suficiente. Por exemplo:

• o TCP ou UDP é usado ou ambos (como no DNS)?
• o serviço está usando uma porta padrão fixa (por exemplo, algo como a porta TCP 80 para um servidor da web)?
• Como alternativa, é escolhido um número de porta dinâmica que pode variar (por exemplo, serviços RPC, como o NFS clássico, registrado no Portmap)?
• O infame FTP usa até duas portas , tanto um número de porta fixo quanto dinâmico, quando configurado para usar o modo passivo ...
• as descrições de serviço, porta e protocolo /etc/servicesnão coincidem necessariamente com o serviço real usando uma porta.

4.4 O filtro de pacotes do kernel não é a única coisa que pode restringir a conectividade de rede:

• O SELinux também pode estar restringindo os serviços de rede. getenforceconfirmará se o SELinux está em execução.
• Apesar de se tornarem um pouco obscuros, os TCP Wrappers ainda são uma ferramenta poderosa para reforçar a segurança da rede. Verifique com ldd /path/to/service |grep libwrape os /hosts.[allow|deny]arquivos de controle.

5. INPUTou FORWARDcadeias

O conceito de cadeias é explicado mais detalhadamente aqui, mas o mais curto é:

A INPUTcadeia é onde você abre e / ou fecha portas de rede para serviços em execução localmente, no host em que você emite os comandos iptables.

É na FORWARDcadeia que você aplica regras para filtrar o tráfego que é encaminhado pelo kernel para outros sistemas, sistemas reais, mas também contêineres Docker e servidores Servidores convidados virtuais quando sua máquina Linux está atuando como ponte, roteador, hypervisor e / ou endereço de rede tradução e encaminhamento de porta.

Um equívoco comum é que, como um contêiner de encaixe ou um convidado KVM é executado localmente, as regras de filtro que se aplicam devem estar na cadeia INPUT, mas esse geralmente não é o caso.

6. Módulos Kernel

Como o filtro de pacotes é executado no kernel do Linux, ele também pode ser compilado como módulo dinâmico, na verdade vários módulos. A maioria das distribuições inclui o netfilter como módulos e os módulos necessários do netfilter serão carregados no kernel conforme necessário, mas para alguns módulos, um administrador de firewall precisará garantir manualmente que eles sejam carregados. Isso diz respeito principalmente aos módulos de rastreamento de conexão, como os nf_conntrack_ftpquais podem ser carregados insmod.

Os módulos atualmente carregados no kernel em execução podem ser exibidos com lsmod.

O método para garantir que os módulos sejam carregados persistentemente nas reinicializações depende da distribuição do Linux.

Problemas comuns com diferentes protocolos

DNS: o DNS usa a porta 53 UDP por padrão, mas as mensagens que não couberem em um único datagrama UDP serão transmitidas usando TCP em vez disso (geralmente transferências de zona e outras), exigindo que a porta 53 TCP seja aberta também quando você executa um servidor de nomes .

Email: muitos provedores de acesso à Internet bloqueiam o tráfego SMTP (ou pelo menos a porta padrão TCP 25), tornando impossível receber ou enviar diretamente emails, e seus clientes são forçados a usar a retransmissão SMTP do ISP para todos os emails de saída e, às vezes, para emails de entrada . Relaciona-se ao §1.1.

FTP: FTP é um protocolo estranho, no sentido de que são usadas duas conexões. A primeira é a conexão de controle; por padrão, um servidor FTP escuta na porta TCP 21. A conexão de controle é usada para autenticação e emissão de comandos. As transferências de arquivos reais e coisas como a saída de uma listagem de diretório passam por uma segunda conexão TCP, a conexão DATA. No FTP ativo, a conexão DATA seria iniciada no servidor FTP da porta TCP 20 e conectada ao cliente FTP. O FTP ativo não funciona muito bem com os usuários protegidos por firewalls e gateways NAT, por isso caiu em desuso. A maioria dos servidores FTP suporta FTP passivo. Com o FTP passivo, o servidor FTP abre um ouvinte para a conexão DATA em uma segunda porta, à qual o cliente FTP pode se conectar. O problema para um firewall é que a porta DATA pode ser qualquer porta não privilegiada disponível entre 1024-65536.

Em um firewall sem estado que normalmente é resolvido restringindo o número de portas passivas que o servidor FTP pode atribuir e abrindo explicitamente essas portas. ie

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

Em um firewall stateful, você não precisa abrir explicitamente a porta DATA, o módulo auxiliar netfilter reconhecerá a porta dinâmica atribuída e abrirá dinamicamente essa porta para o cliente correto, marcando a conexão DATA como RELATEDapós a qual corresponderá à regra genérica :

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Isso requer que o módulo correto do kernel seja carregado, no caso do FTP manualmente, executando, por exemplo insmod nf_conntrack_ftp, tornando a persistência dependente durante a reinicialização, dependendo da distribuição.

Nota: O módulo de rastreamento da conexão FTP falhará quando o FTP for usado com SSL, pois a conexão de controle será criptografada e o nf_conntrack_ftp não poderá mais ler a reimpressão PASV.

NFS e serviços RPC similares : O problema com os serviços RPC é que, por design, eles não usam uma porta fixa específica. Eles podem escolher qualquer porta disponível aleatoriamente, que será registrada no daemon RPC Portmap. Um cliente que tenta se conectar consultará o daemon do Portmap e, em seguida, se conectará diretamente à porta correta. Isso resolveu o problema de ficar sem portas reservadas ...

De uma perspectiva de firewall, a porta 111 de TCP / UDP precisa ser aberta e a porta real que o serviço RPC está usando no momento. O problema de abrir uma porta aleatória em um firewall geralmente é resolvido restringindo o serviço RPC, como o servidor NFS, para usar uma porta fixa predefinida.

Iptables / Firewall "introdução"

Um firewall é basicamente um filtro de rede baseado em políticas. Os firewalls do Linux são criados em torno do Netfilter; a estrutura de processamento de pacotes de rede do kernel, composta por vários módulos do kernel que executam tarefas específicas:

1. O módulo FILTER (sempre carregado por padrão) nos permite principalmente aceitar ou remover pacotes IP com base em um determinado critério de correspondência.
2. O conjunto de módulos NAT permite realizar traduções de endereços de rede (SNAT, DNAT, MASQUERADE).
3. O módulo MANGLE nos permite alterar certos campos de pacotes IP (TOS, TTL).

Os usuários configuram a estrutura do Netfilter para atender às suas necessidades de firewall usando iptables na linha de comando. Com o iptables, definimos regras que instruem o kernel sobre o que fazer com pacotes IP quando eles chegam, passam ou saem da nossa caixa do Linux. Cada processo principal do Netfilter é representado por uma TABELA (FILTRO, NAT, MANGLE) na linguagem iptables. Eles têm vários pontos de gancho específicos no mapa de fluxo de pacotes da rede, onde são chamados pelo kernel para desempenhar suas funções. Certas seqüências especificamente localizadas de chamadas TABLE são chamadas genericamente de CHAINS internas, recebendo os nomes de PREROUTING, INPUT, FORWARD, OUTPUT e POSTROUTING. É fácil lembrar se associarmos um TABLE a um "tipo de processo" e um CHAIN ​​ao "local" no mapa de fluxo de pacotes da rede onde as instâncias desses processos são invocadas.

Como um pacote IP é recebido em uma interface de rede ou criado por um processo local, até que seja finalmente entregue ou descartado, o mecanismo Netfilter testará e aplicará sequencialmente as regras contidas no mapa de fluxo de pacotes da rede. Em cada bloco identificado por um par TABLE @ CHAIN, o usuário pode adicionar uma ou mais dessas regras consecutivas contendo um critério de correspondência de pacotes IP e um curso de ação correspondente. Existem ações (por exemplo, ACEITAR, QUEDA, etc.) que podem ser executadas por mais de uma TABLE e outras ações (por exemplo, SNAT, DNAT, etc.) que são específicas de TABLE.

ou seja, quando um pacote IP chega de uma interface de rede, ele é primeiro processado pela cadeia PREROUTING, invocando as regras definidas pelo usuário da tabela MANGLE, se houver. Se não houver regras que correspondam ao pacote atual, o curso de ação padrão correspondente "MANGLE @ PREROUTING" ou "política" se aplica. Nesse ponto, se o pacote não foi descartado, o processo continuará agora invocando as regras da tabela NAT na cadeia PREROUTING (veja o mapa) e assim por diante. Para facilitar o layout das regras, os usuários também podem criar suas próprias cadeias personalizadas e "pular" nelas a partir de diferentes pontos do mapa, conforme desejarem.

Embora as cadeias internas possam ter políticas definidas pelo usuário para pacotes ACCEPT ou DROP, as cadeias definidas pelo usuário sempre têm uma política padrão imutável de RETURN para o chamador para continuar o processo.

Comandos Iptables

Os comandos principais do iptables preenchem o mapa de fluxo de pacotes da rede com as regras de processamento necessárias.

A regra genérica do iptables pode ser escrita como:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Pode ser lido como:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Os comandos auxiliares do iptables concluem o cenário, definindo condições padrão, listando regras, regras de liberação, etc.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

O Iptables carrega nossos comandos no mecanismo Netfilter em tempo de execução, o Netfilter imediatamente aplica as regras e configurações carregadas, mas elas não são persistentes. Depois de reiniciar, todas as regras e configurações do Netfilter carregadas anteriormente serão perdidas. Por esse motivo, existem utilitários do iptables que permitem salvar o conjunto de regras ativo no momento em um arquivo e recarregá-lo posteriormente.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Resumo de Iptables

O Netfilter é uma estrutura extremamente flexível e poderosa, mas há um preço a pagar por isso; Iptables é complexo. Do ponto de vista do usuário, certos termos como TABLE, CHAIN, TARGET realmente não combinam muito bem com o conceito que representam e não fazem muito sentido a princípio. O tópico é longo, os comandos parecem ter uma lista interminável de parâmetros. Para piorar as coisas, não há um único livro que realmente domine o Iptables. Eles se enquadram principalmente em duas categorias: "livro de receitas" ou "livro de páginas de manual". Penso que esta introdução fornece um instantâneo do cenário Netfilter / Iptables mais a dose necessária de material de página de manual pré-digerido. Se você é novo no iptables, depois de ler esses parágrafos algumas vezes, estará pronto para ler os exemplos do iptables. Com alguma prática, você logo estará escrevendo suas próprias regras.

Firewalls

Um firewall é projetado principalmente para permitir ou negar dinamicamente o tráfego de rede com base em um conjunto de regras. Nesse ponto, é fácil entender por que a estrutura Linux Netfilter / Iptables é perfeita para a construção de firewall. Observando o mapa de fluxo de pacotes da rede, encontramos dois pontos particularmente interessantes na tabela FILTER nas cadeias INPUT e FORWARD; Podemos decidir lá o endereço de origem IP, o protocolo IP (UDP / TCP), a porta de destino (80, 21, 443, etc), etc., se ACEITARmos, REJEITARmos ou apenas deixarmos cair um pacote IP específico. É isso que um firewall faz 80% do tempo quando, ou seja, protege um servidor da Web de solicitações de rede não autorizadas. Os outros 20% do tempo estão manipulando pacotes de rede (NAT, MANGLE).

Cenários de firewalls

Existem centenas de layouts de firewall diferentes que atendem a diferentes necessidades, mas três deles podem ser considerados os cenários mais comuns de firewall.

1. Servidor web simples com uma ou mais interfaces conectadas à Internet. A política inclui regras básicas para permitir acesso de entrada restrito, acesso de saída irrestrito e regras antifalsificação. O encaminhamento de IP está desativado.
2. Esse firewall se conecta à Internet e a uma área interna protegida. A política inclui regras básicas para permitir acesso de entrada restrito, acesso de saída irrestrito e regras antifalsificação. Como a área protegida usa endereços IP privados, é necessário NAT. O encaminhamento de IP está ativado.
3. Esse firewall se conecta à Internet, à área interna protegida e desmilitarizada. A política inclui regras básicas para permitir acesso de entrada restrito, acesso de saída irrestrito e regras antifalsificação. Como as áreas protegidas e DMZ usam endereços IP privados, elas precisam de NAT de origem e destino. O encaminhamento de IP está ativado.

Eu escrevi isso para: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html