|
Voilà, cette partie a été traitée.
J'ai également remplacé :
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
par
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,NEW -j ACCEPT
J'espère que c'est cohérent.
Le script actuel :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
Merci.
Si on parle d'une machine exposée sur Internet comme ton VPS OVH,
tu n'as pas besoin du multicast. Cette techno n'a jamais pris sur
Internet. Si tu reçois du multicast sur l'interface, c'est du
bruit de fond local correspondant à des protocoles d'annonces de
services mals configurés sur les VPS voisins ou des besoins
spécifiques à OVH (FHRP par exemple).
L'IGMP est un protocole permettant à une machine de s'abonner à un
flux multicast routé. Donc si pas de multicast sur Internet, pas
besoin d'IGMP
Pour reprendre les propos de Pascal et Daniel, comme tu n'en pas
pas besoin, autant le bloquer mais sans pour autant créer des
règles dédiées. 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.
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, 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...).
Enfin, petit point si je puis me permettre :
# Permettre à une connexion ouverte de recevoir du trafic en
entrée.
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Personnellement, j'aurais fait comme cela :
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
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. En revanche,
c'est mieux de le laisser autoriser pour l'ICMP.
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
|