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]
