Quais são as regras essenciais do iptables para o IPv6 funcionar corretamente?

4

Eu tive um problema em que perdi a conectividade com um servidor no endereço IPv6 depois de algum tempo e ele acabou sendo causado pela queda dos pacotes do cliente DHCPv6 (porta 546) pela política INPUT padrão de DROP , esta é a minha pergunta sobre o problema, minhas regras eram:

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -s IP_OF_ANOTHER_HOST -j ACCEPT
-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
-P INPUT DROP

Eu pensei que essas regras são suficientes, permitindo especialmente RELATED e ESTABLISHED conexões, pois a política padrão da minha OUTPUT é ACCEPT , mas tive que adicionar essa regra para aceitar os pacotes do cliente DHCPv6:

-A INPUT -m conntrack --ctstate NEW -m udp -p udp --dport 546 -d fe80::/64 -j ACCEPT

O problema é que não quero adicionar mais regras que eu possa não precisar, quero manter minhas regras o mais simples possível.

Então, quais são as regras essenciais que devem ser definidas para o IPv6 funcionar corretamente? Devo também ativar a porta do servidor DHCPv6 547? e é aceitável aceitar todos os pacotes ICMPv6?

    
por Pierre 01.07.2018 / 12:10

2 respostas

4

As regras essenciais dependerão da rede, uma vez que a rede pode usar o SLAAC em vez do DHCPv6, ou pode haver outras complicações dependendo dos túneis, do manuseio do ICMP, etc.

-A INPUT -m conntrack --ctstate NEW -m udp -p udp --dport 546 -d fe80::/64 -j ACCEPT

é adequado para um cliente DHCPv6. Os clientes DHCP não devem aceitar o tráfego da porta do servidor 547, pois, presumivelmente, eles não são também um servidor DHCP. Os pacotes virão do servidor DHCP da porta 547 para a porta 546 no cliente; o rastreamento de conexão não será aplicado à medida que o cliente transmite (ou realmente faz o multicast no IPv6) e o servidor responde de um endereço não relacionado ao local de onde o cliente transmitiu.

Isso é bastante seguro, pois root é necessário para escutar as portas <1024 para que usuários aleatórios no sistema cliente não consigam iniciar um serviço malicioso lá por padrão (talvez eles pudessem acessar a rede DoS?). fe80 é o tráfego link-local para que usuários mal-intencionados remotos em alguma outra sub-rede não consigam rotear o tráfego para essa porta (se você tiver usuários mal-intencionados em sua sub-rede, provavelmente terá outros problemas mais importantes, como o uso de equipamentos de rede que impedem servidores DHCP desonestos).

O ICMPv6 pode ficar muito complicado dependendo do que você deseja permitir ou negar, embora provavelmente possa ser tratado com os padrões de rastreamento de conexão para um cliente IPv6 simples. Veja RFC 4443 e RFC 4890 para mais detalhes.

    
por 01.07.2018 / 16:59
2

Procurei exemplos no ufw, o firewall criado pelo Ubuntu. Parece que, uma vez que você tenha permitido o ICMP e o DHCP, não há muito o que se preocupar.

link

Como a Thrig aponta, parece que há muitos códigos ICMP diferentes para analisar. Suas regras atuais evitam fazê-lo permitindo todo o ICMP; Eu definitivamente posso ver o apelo dessa abordagem:).

Infelizmente ufw não é perfeitamente útil como uma referência para estes. Isso não justifica por que packet-too-big não será aceito por RELATED já. Mas parece uma fonte plausível para um default do iptables6 retirado do RFC4890.

RFC4890 na verdade menciona apenas um tipo de ICMP como tendo "risco de segurança significativo" - "Redirecionamento (Tipo 137)" . Os redirecionamentos ICMP são úteis somente em redes locais que possuem vários roteadores independentes e não estão configurados de maneira ideal. O manuseio do redirecionamento não é essencial, mas não utilizaria a rede da maneira mais eficiente possível. O ufw não permite explicitamente redirecionamentos. Com base nisso, acho que seria razoável permitir a maioria ou todo o ICMP, mas não permitir redirecionamentos de ICMP.

# ok icmp codes for INPUT (rfc4890, 4.4.1 and 4.4.2)
-A ufw6-before-input -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
# codes 0 and 1
-A ufw6-before-input -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
# codes 0-2
-A ufw6-before-input -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type echo-request -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type router-solicitation -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type neighbor-solicitation -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type neighbor-advertisement -m hl --hl-eq 255 -j ACCEPT
# IND solicitation
-A ufw6-before-input -p icmpv6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
# IND advertisement
-A ufw6-before-input -p icmpv6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
# MLD query
-A ufw6-before-input -p icmpv6 --icmpv6-type 130 -s fe80::/10 -j ACCEPT
# MLD report
-A ufw6-before-input -p icmpv6 --icmpv6-type 131 -s fe80::/10 -j ACCEPT
# MLD done
-A ufw6-before-input -p icmpv6 --icmpv6-type 132 -s fe80::/10 -j ACCEPT
# MLD report v2
-A ufw6-before-input -p icmpv6 --icmpv6-type 143 -s fe80::/10 -j ACCEPT
# SEND certificate path solicitation
-A ufw6-before-input -p icmpv6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
# SEND certificate path advertisement
-A ufw6-before-input -p icmpv6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
# MR advertisement
-A ufw6-before-input -p icmpv6 --icmpv6-type 151 -s fe80::/10 -m hl --hl-eq 1 -j ACCEPT
# MR solicitation
-A ufw6-before-input -p icmpv6 --icmpv6-type 152 -s fe80::/10 -m hl --hl-eq 1 -j ACCEPT
# MR termination
-A ufw6-before-input -p icmpv6 --icmpv6-type 153 -s fe80::/10 -m hl --hl-eq 1 -j ACCEPT

# ok icmp codes for OUTPUT (rfc4890, 4.4.1 and 4.4.2)
-A ufw6-before-output -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A ufw6-before-output -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
# codes 0 and 1
-A ufw6-before-output -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
# codes 0-2
-A ufw6-before-output -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type echo-request -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
-A ufw6-before-output -p icmpv6 --icmpv6-type router-solicitation -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p icmpv6 --icmpv6-type neighbor-advertisement -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p icmpv6 --icmpv6-type neighbor-solicitation -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT
# IND solicitation
-A ufw6-before-output -p icmpv6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
# IND advertisement
-A ufw6-before-output -p icmpv6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
# MLD query
-A ufw6-before-output -p icmpv6 --icmpv6-type 130 -s fe80::/10 -j ACCEPT
# MLD report
-A ufw6-before-output -p icmpv6 --icmpv6-type 131 -s fe80::/10 -j ACCEPT
# MLD done
-A ufw6-before-output -p icmpv6 --icmpv6-type 132 -s fe80::/10 -j ACCEPT
# MLD report v2
-A ufw6-before-output -p icmpv6 --icmpv6-type 143 -s fe80::/10 -j ACCEPT
# SEND certificate path solicitation
-A ufw6-before-output -p icmpv6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
# SEND certificate path advertisement
-A ufw6-before-output -p icmpv6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
# MR advertisement
-A ufw6-before-output -p icmpv6 --icmpv6-type 151 -s fe80::/10 -m hl --hl-eq 1 -j ACCEPT
# MR solicitation
-A ufw6-before-output -p icmpv6 --icmpv6-type 152 -s fe80::/10 -m hl --hl-eq 1 -j ACCEPT
# MR termination
-A ufw6-before-output -p icmpv6 --icmpv6-type 153 -s fe80::/10 -m hl --hl-eq 1 -j ACCEPT

# ok icmp codes for FORWARD (rfc4890, 4.3.1)
-A ufw6-before-forward -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A ufw6-before-forward -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
# codes 0 and 1
-A ufw6-before-forward -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
# codes 0-2
-A ufw6-before-forward -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
-A ufw6-before-forward -p icmpv6 --icmpv6-type echo-request -j ACCEPT
-A ufw6-before-forward -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
# ok icmp codes for FORWARD (rfc4890, 4.3.2)
# Home Agent Address Discovery Reques
-A ufw6-before-input -p icmpv6 --icmpv6-type 144 -j ACCEPT
# Home Agent Address Discovery Reply
-A ufw6-before-input -p icmpv6 --icmpv6-type 145 -j ACCEPT
# Mobile Prefix Solicitation
-A ufw6-before-input -p icmpv6 --icmpv6-type 146 -j ACCEPT
# Mobile Prefix Advertisement
-A ufw6-before-input -p icmpv6 --icmpv6-type 147 -j ACCEPT

(fim das regras do ICMP)

# allow dhcp client to work
-A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546 -j ACCEPT

O seguinte é necessário se você quiser usar o avahi para qualquer coisa na rede local. Múltiplas distribuições populares que têm políticas sobre serviços de rede, consideram avahi confiável o suficiente para ouvir a rede por padrão.

# allow MULTICAST mDNS for service discovery
-A ufw6-before-input -p udp -d ff02::fb --dport 5353 -j ACCEPT

UPnP às vezes é útil em máquinas clientes, mas é complexo, e eu não ouvi nada de bom nisso.

# allow MULTICAST UPnP for service discovery
-A ufw6-before-input -p udp -d ff02::f --dport 1900 -j ACCEPT
    
por 01.07.2018 / 17:47