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.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
