Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 18/09/2019 à 22:48, Jean-Michel a écrit :
Personnellement, je trouve qu'un DROP par défaut de tout en fin
de chaîne (ou en action par défaut) va très bien et évite de surcharger
inutilement les règles.
Une règle DROP en fin de chaîne n'est pas commode si on veut pouvoir
ajouter des règles ACCEPT à la volée. Je préfère régler la politique par
défaut à DROP.
Pour l'IPv6, le jour où tu le déploieras, en effet, comme l'a rappelé
Pascal, il faut faire attention à bien autoriser le protocole NDP qui
reprend, entre autre, le rôle d'ARP en IPv4 et qui s'appuie sur de
l'ICMPv6. Autant en IPv4 tu ne peux pas bloquer l'ARP avec iptables,
Mais on peut assez souvent oublier d'autoriser le trafic DHCP. Par
chance (?), les clients DHCP comme dhclient injectent et capturent les
paquets directement sur l'interface réseau sans passer par la couche IP,
ce qui court-circuite iptables.
autant en IPv6 c'est assez facile de se couper les pattes en bloquant
NDP ou plutôt en oubliant de l'autoriser
NDP repose sur des paquets ICMPv6 échangés localement en multicast
certes, mais surtout des paquets ICMPv6 particuliers.
Personnellement, je n'autorise pas le multicast sur mes règles ip6tables
mais uniquement les paquets ICMPv6 dont les caractéristiques concordent
précisément avec les paquets attendus (adresses fe80::, HL = 255, types
& codes qui vont bien, etc...).
Attention, les paquets NDP peuvent contenir des adresses non link-local.
Autoriser RELATED sans restriction est une mauvaise habitude de beaucoup
de docs en ligne et la source de problèmes de sécurité importants même
si depuis la version 4.7 du kernel les helpers ne sont plus activés par
défaut pour éviter ce problème.
Pour moi ce sont deux problèmes distincts. Certes un helper peut être
abusé donc l'activer uniquement sur les connexions qui en ont besoin
renforce la sécurité, mais cela n'empêche pas d'en abuser lorsqu'il est
activé. Par exemple un paquet dans l'état RELATED lié au helper ftp
(initiant une connexion de données FTP) ne devrait être accepté que si
ses caractéristiques intrinsèques (ports source et destination,
éventuellement adresses IP source et destination) sont conformes au
trafic attendu :
- dans le cas d'une connexion active, port source 20 et port destination
dans la plage de ports actifs autorisée pour le client ;
- dans le cas d'une connexion passive, port source > 1023 et port
destination dans la plage de ports passifs définie dans la configuration
du serveur FTP.
En revanche, c'est mieux de le laisser
autoriser pour l'ICMP.
Si on est préoccupé à ce point par la sécurité, alors on ne devrait même
pas accepter tous les types ICMP dans l'état RELATED. Par exemple le
type "source quench" a été reconnu comme dangereux (déni de service) et
officiellement abandonné, et le type "redirect" peut être exploité pour
détourner du trafic. Pour ma part je n'autorise que les types d'erreur
"destination unreachable", "time exceeded" et "parameter problem".
De plus, il faudra activer le helper FTP pour ton serveur FTP. Une doc
ici sur le sujet :
https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac. Cela te
permettra en plus de fermer le port TCP/20
On n'a jamais eu besoin d'ouvrir le port TCP 20 pour FTP. C'est
uniquement un port source de connexions sortantes.
Reply to: