netfilter Estado RELATÓRIO conntrack TCP / UDP com ICMP / ICMPv6

Question

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

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

Específico para firewalls 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. Traffic That Must Not Be Dropped

Error messages that are essential to the establishment and maintenance of communications:

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

necessary packet inspection capabilities.

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

allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, and it is not necessary to filter IPv6 Echo Request messages.

4.3.2. Traffic That Normally Should Not Be Dropped

Error messages other than those listed in Section 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 pelos pacotes RFC 4890 ICMPv6? (formato ip6tables-save)

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

Adendo: claro, é preciso ter outras regras para o NDP e o 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 regras a seguir para cumprir com o RFC 4980, mantendo apenas a regra "RELACIONADA" 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

    

Answer 1

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

Use essas 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, às vezes, use ip6tables-save -c para ver os contadores das regras acima. Se os contadores são > 0 para as regras NOOP acima da linha "RELATED", mas 0 para as regras ACCEPT abaixo, você sabe que a correspondência "RELACIONADA" tomou conta de aceitá-las. Se o contador para alguma regra NOOP for 0, então você não pode dizer ainda para esse tipo específico de icmpv6 se RELATED o faz ou não. Se alguma linha ACCEPT tiver seu contador > 0, então você precisa dessa regra explícita.