Início / unix / Perguntas / 436357
Accepted
Strangelovian
Asked: 2018-04-09 06:40:16 +0800 CST

netfilter TCP/UDP conntrack estado RELATED com ICMP / ICMPv6

  • 772

O rastreamento de conexão Netfilter é projetado para identificar alguns pacotes como "RELACIONADOS" a uma entrada conntrack.

Estou procurando os detalhes completos das entradas de conntrack TCP e UDP, com relação aos pacotes de erro ICMP e ICMPv6.

Específico para firewall IPv6, o RFC 4890 descreve claramente os pacotes ICMPv6 que não devem ser descartados

http://www.ietf.org/rfc/rfc4890.txt

4.3.1. Tráfego que não deve ser descartado

Mensagens de erro essenciais para o estabelecimento e manutenção das comunicações:

Destination Unreachable (Type 1) - All codes

Packet Too Big (Type 2)

Time Exceeded (Type 3) - Code 0 only

Parameter Problem (Type 4) - Codes 1 and 2 only

Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the

capacidades necessárias de inspeção de pacotes.

Connectivity checking messages:

Echo Request (Type 128)

Echo Response (Type 129)

For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are

permitido pelo firewall. Tem sido prática comum em redes IPv4 descartar mensagens de solicitação de eco em firewalls para minimizar o risco de ataques de varredura na rede protegida. Conforme discutido na Seção 3.2, os riscos da varredura de portas em uma rede IPv6 são muito menos graves e não é necessário filtrar as mensagens IPv6 Echo Request.

4.3.2. Tráfego que normalmente não deve ser descartado

Mensagens de erro diferentes das listadas na Seção 4.3.1:

Time Exceeded (Type 3) - Code 1
    Parameter Problem (Type 4) - Code 0

No caso de um roteador doméstico linux, a seguinte regra é suficiente para proteger a interface WAN, enquanto permite a passagem de pacotes RFC 4890 ICMPv6? (formato ip6tables-save)

*filter
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Adendo: claro, são necessárias outras regras para NDP e DHCP-PD:

-A INPUT -s fe80::/10 -d fe80::/10 -i wanif -p ipv6-icmp -j ACCEPT
-A INPUT -s fe80::/10 -d fe80::/10 -i wanif -p udp -m state --state NEW -m udp --sport 547 --dport 546 -j ACCEPT

Em outros termos, posso me livrar com segurança das seguintes regras para cumprir a RFC 4980, mantendo apenas a regra "RELATED" primeiro?

-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
linux networking

1 respostas

  1. Best Answer

    Eu não sei a resposta, mas você mesmo pode descobrir.

    Use estas regras (cria uma cadeia vazia "NOOP" para fins de contabilidade):

    *filter
...
:NOOP - [0:0]
...
-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j NOOP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
...

    Então, algumas vezes mais tarde, use ip6tables-save -cpara ver os contadores das regras acima. Se os contadores forem > 0 para as regras NOOP acima da linha "RELATED", mas 0 para as regras ACCEPT abaixo, você sabe que a correspondência "RELATED" cuidou de aceitá-los. Se o contador para alguma regra NOOP for 0, você ainda não pode dizer para esse tipo icmpv6 específico se RELATED o faz ou não. Se alguma linha ACCEPT tiver seu contador > 0, você precisará dessa regra explícita.

    • 4

relate perguntas