Re: vérifier l'utilisation d'une règle Iptables
Seb a écrit :
Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.
Je m'en doutais. ;-) Tu peux aussi ajouter dans FORWARD le bloc
169.254.0.0/16 qui correspond aux adresses non routables de type
link-local, utilisées entre autres par le mécanisme APIPA de Windows
(attribution automatique d'une adresse de repli en cas d'échec de DHCP).
Même chose dans INPUT sauf si la liaison entre ta passerelle et ton FAI
utilise ces adresses.
Pour information, je n'utilise plus de règles iptables pour filtrer ces
adresses sur ma passerelle. A la place, j'ajoute des routes "reject" avec
une métrique élevée dans la table de routage en conjonction avec le
paramètre du noyau /proc/sys/net/ipv4/conf/*/rp_filter (reverse path
filter) mis à 1 sur toutes les interfaces. C'est donc la pile IP qui fait
le filtrage. J'y trouve un triple avantage :
- élimine les paquets venant du WAN avec ces adresses source ;
- rejette les paquets venant du LAN ou de la passerelle avec ces adresses
destination, ce qui a pour effet d'empêcher l'émission de tels paquets
vers le WAN (pas très propre), avec envoi vers l'émetteur d'un ICMP
destination-unreachable ;
- si je veux router un sous-réseau appartenant à un de ces blocs sur mon
LAN, il suffit de créer une route avec une métrique normale, pas besoin
de modifier les règles iptables.
Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.
En fait la table mangle sert à toutes sortes de modifications des
en-têtes de paquets portant sur autre chose que les adresses et les
ports. Le marquage, qui est une modification "virtuelle", peut servir à
faire de la QoS, du routage avancé sur plusieurs interfaces, ou pour
faire du filtrage comme ici. Sur ma passerelle, je me sers de la table
mangle pour modifier le TTL des paquets IP entrants (et son équivalent le
hop-limit en IPv6) et compenser un bug des routeurs de mon FAI.
Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..
Tu peux le faire aussi sur la patte WAN, les gens qui se trompent
d'adresse et tombent par erreur sur la tienne t'en seront reconnaissants.
Eventuellement tu peux introduire une limite (-m limit) dans la règle
pour éviter de consommer trop d'upload et réduire les dommages
collatéraux d'une attaque par spoofing. Idem pour le ping.
Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.
S'il y a plusieurs serveurs, il faudra plusieurs règles.
Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.
Il suffisait de tester avec un autre serveur POP. ;-)
Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )
C'est classique. C'est pourquoi je répète à chaque fois qu'on ne peut pas
déduire grand chose d'une règle isolée, il faut toujours la replacer dans
son contexte avec les autres règles qui précèdent et qui suivent.
Reply to: