Como entender uma configuração de cadeia do iptables no OpenWrt

Question

Trata-se de como entender as cadeias encontradas na configuração padrão iptables em um roteador doméstico típico executando o OpenWrt (um Linux simplificado para dispositivos roteadores), mas que no final das contas pode não ser específico para esse sistema em particular.

Vamos nos concentrar no INPUT main chain aqui e desconsiderar FORWARD e OUTPUT do mesmo table , bem como PREROUTING e POSTROUTING da tabela nat .

Fazer um iptables -L -t filter mostra um grande número de regras. Eu rearranjei a saída abaixo para torná-la menos intimidante e na tentativa de identificar as partes que dificultam a minha compreensão.

Existem três cadeias incorporadas na tabela filter , que aparecem no topo da saída. (Eu especifiquei -v porque acho menos confuso .)

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1260  133K ACCEPT     all  --  any    any     anywhere             anywhere            ctstate RELATED,ESTABLISHED
    8   544 ACCEPT     all  --  lo     any     anywhere             anywhere
  787 41632 syn_flood  tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN
13012 1249K input_rule  all  --  any    any     anywhere             anywhere
13012 1249K input      all  --  any    any     anywhere             anywhere

Chain FORWARD … # not considering this chain here
Chain OUTPUT …  # not considering either

Como você pode ver, recortei as cadeias mencionadas de FORWARD e OUTPUT para se concentrar em INPUT . (Eu poderia ter escolhido qualquer um dos outros dois como eles são construídos de uma maneira semelhante.)

INPUT tem uma política de ACCEPT e especifica cinco regras. Os três primeiros são claros para mim. Primeiro, aceite coisas "estabelecidas" ou "relacionadas". (Por exemplo, aceite a resposta de uma solicitação HTTP ou DNS que eu fiz.) Segundos, aceite tudo que estiver indo para o dispositivo de loopback ( 127.0.0.1 ). (Isso só pode vir do próprio localhost, e eu quero que isso funcione. Não faria sentido de outra forma.) Terceiro, tenha uma proteção contra o Synflood. (Que protege contra um certo tipo de ataque.)

Chain syn_flood (1 references)
 pkts bytes target     prot opt in     out     source               destination
  787 41632 RETURN     tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50
    0     0 DROP       all  --  any    any     anywhere             anywhere

Mas há duas regras que se ramificam em duas cadeias chamadas input e input_rule , e a pergunta é: por que existem duas delas e qual delas você deve usar para quê?

Vamos detalhar a pilha de saltos dessas regras.

Chain input_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination

Não há nada aqui ainda. É para mim adicionar regras. Mas que tipo de regras?

Chain input (1 references)
 pkts bytes target     prot opt in     out     source               destination
 6315  482K zone_lan   all  --  br-lan any     anywhere             anywhere
 6697  767K zone_wan   all  --  pppoe-wan any     anywhere             anywhere

Ok, este tem coisas, indo mais longe na LAN e na WAN, o que faz sentido para um roteador doméstico.

Chain zone_lan (1 references)
 pkts bytes target     prot opt in     out     source               destination
 6315  482K input_lan  all  --  any    any     anywhere             anywhere
 6315  482K zone_lan_ACCEPT  all  --  any    any     anywhere             anywhere

Chain zone_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:bootpc
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp echo-request
 6697  767K input_wan  all  --  any    any     anywhere             anywhere
 6697  767K zone_wan_REJECT  all  --  any    any     anywhere             anywhere

Como você pode ver, cada uma dessas regras aumenta ainda mais a pilha para regras mais definidas pelo usuário.

Chain input_lan (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain zone_lan_ACCEPT (2 references)
 pkts bytes target     prot opt in     out     source               destination
    4  1322 ACCEPT     all  --  any    br-lan  anywhere             anywhere
 6315  482K ACCEPT     all  --  br-lan any     anywhere             anywhere

Qual é o objetivo de input_lan ? O outro é provavelmente aceitar pacotes, mas isso me faz pensar ... a política para INPUT é ACCEPT , então por que repetir ACCEPT aqui?

Agora, insira a partir da WAN. Se você rolar para cima, poderá ver que algumas coisas sobre UDP e ICMP são aceitas. Isso é para DHCP e, basicamente, ping . Isso é claro. O que é menos claro, novamente, é o material parcialmente vazio seguindo essas regras:

Chain input_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination

Mesma pergunta que para input_lan .

Chain zone_wan_REJECT (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 reject     all  --  any    pppoe-wan  anywhere             anywhere
 6697  767K reject     all  --  pppoe-wan any     anywhere             anywhere

Ok, isso é entrada da WAN (não estabelecida ou relacionada), e sim, provavelmente queremos rejeitá-la, e agora há dois tipos de rejeição aqui, um fechando o soquete ( tcp-reset ) para tentativas de conexão TCP e outro via resposta ICMP ( icmp-port-unreachable ) para mensagens ICMP (pense em ping ).

Chain reject (5 references)
 pkts bytes target     prot opt in     out     source               destination
  595 31817 REJECT     tcp  --  any    any     anywhere             anywhere            reject-with tcp-reset
 4858  582K REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable

Este último é um pega-tudo. Então nada será aceito aqui.

Por fim, aqui está uma lista de outras cadeias encontradas na tabela filter que não são referenciadas na cadeia INPUT incorporada na tabela net . Apenas por completude, e para ver que eles parecem ter construções análogas.

# other chains, not reached from the INPUT chain, so truncated and moved here
Chain forward (1 references)
Chain forwarding_lan (1 references)
Chain forwarding_rule (1 references)
Chain forwarding_wan (1 references)
Chain nat_reflection_fwd (1 references)
Chain output (1 references)
Chain output_rule (1 references)
Chain reject (5 references)
Chain zone_lan_DROP (0 references)
Chain zone_lan_REJECT (1 references)
Chain zone_lan_forward (1 references)
Chain zone_wan_ACCEPT (2 references)
Chain zone_wan_DROP (0 references)
Chain zone_wan_forward (1 references)

Então, bem. Desculpe por este longo post. Houve algumas perguntas ao longo do caminho. Eu não sei como colocar isso de maneira mais fácil ou mais curta. Esta configuração de iptables não é exatamente fácil de entender porque não há detalhes claros espalhados aqui e ali. Espero que você possa esclarecer isso e explicar o raciocínio subjacente. Obrigado pela sua atenção.

    

Answer 1

Até onde eu sei, o firewall é gerado a partir de algum arquivo de configuração de alto nível no openwrt. Como muitas possibilidades diferentes precisam ser suportadas, as regras de geração de fato não são otimizadas e podem conter cadeias desnecessárias / não utilizadas / vazias. Veja o artigo wiki do OpenWRT para mais detalhes.

Para responder a algumas das suas perguntas

• porque "input_rule" está vazio

  Como mencionado, pode ser um lugar onde o usuário pode facilmente inserir regras personalizadas. Outra possibilidade é que "input" era originalmente "input_rule" e que "input_rule" ainda é criado para compatibilidade com scripts antigos.

• Qual é o propósito de input_lan / input_wan?

  Lá você pode bloquear o tráfego de hosts internos na LAN para o roteador (por exemplo, para proteger sua interface de configuração) ou ativar o acesso de fora.

• O padrão para INPUT é ACCEPT, então por que repetir o ACCEPT aqui?

  Como você observou corretamente, isso não é necessário aqui. Mas como existe zone_lan_REJECT, parece que o script quer ser independente da política.

Answer 2

Esta é uma separação clara de preocupações. As regras de acesso para e da WAN devem ser diferentes das da LAN.

A configuração padrão não fornece regras para serviços não necessariamente oferecidos em sua rede. Normalmente, a maioria dos usuários não deve oferecer serviços à Internet. Adicionar regras apropriadas aos conjuntos de regras apropriados ativará os serviços. A interface da Web do OpenWrt deve fornecer assistência por meio de listas suspensas.

A documentação do Firewall Básico de Duas Intercalações Shorewall deve fornecer uma boa compreensão do que está e deveria estar acontecendo . É possível substituir o firewall OpenWrt por um firewall Shorewall-lite, mas para um firewall básico, o firewall existente funcionará. Alguns pacotes presumirão que estão trabalhando com o firewall padrão e levarão algum trabalho se você não o fizer.

    

Answer 3

Concordo com jofel.

input_rule, input_lan e input_wan é para compatibilidade com scripts antigos.

Para melhores estatísticas de pacotes para o novo UCI, coloque suas regras em zone_lan e zone_wan deve ser melhor. E também, o zone_lan_accept provavelmente usado para entrada e saída de pacotes.

    

Answer 4

Na verdade, as regras do openwrt iptables são bem organizadas.

Tome delegate_input por exemplo (outra cadeia tem estrutura semelhante):

• dois ACCEPTs: aceitam lo e tcp tráfego RELACIONADO, ESTABELECIDO
• syn_flood: elimine o tráfego de inundação de sincronização
• input_rule: lida com a entrada de BOTH lan e o tráfego de wan
• zone_lan: lida com a entrada SOMENTE da lan, ACEITARÁ tráfego sem correspondência
• zone_wan: lidar com a entrada APENAS do wan, rejeitará o tráfego sem correspondência

Answer 5

Eu escrevi uma ferramenta precisamente para essa tarefa . Ele reformata iptables -S output em uma árvore de cadeias conforme elas são aplicadas.

Ao analisar sua saída, deduzi que _rule chains são destinados a regras adicionadas manualmente.

A ferramenta também é útil para diagnósticos de regras: se você redefinir os contadores de regras, fazer um teste de rede e, em seguida, alimentar a saída com contadores de pacotes, será capaz de ver em qual (is) caminho (s) na árvore. .