On Sun, 13 Jan 2008 21:14:20 +0100, mpg <[EMAIL PROTECTED]> wrote: > Bonjour, Bonsoir, > Je suis en train d'écrire des règles de filtrage avec iptables pour mes > machines, et je me pose quelques questions. > > 1. Quelle est sous Debian « la » bonne manière de charger ses règles > iptables automatiquement : script dans init.d, dans if-pre-up.d, ailleurs > ? > Pourquoi n'y a-t-il pas de mécanisme générique prévu (il me semble que > c'est pourtant le genre de chose auquelles on pourrait s'attendre sous > Debian) ? On peut très bien combiner les deux. Un script dans le répertoire init.d permettant de charger la politique par défaut, et le chargement/déchargement de règles spécifiques aux interfaces en fonction de leur montage/démontage. Moi, cela me va très bien comme cela et je ne vois aucune raison pour mettre de tel mécanisme en place. C'est l'utilisateur qui choisit :p! Si quelqu'un en voit une pertinente j'écoute. > 2. J'utilise actuellement fail2ban, que j'apprécie pas mal, pour lutter > contre les attaque par force brute sur ssh : comment faire pour ne pas > tout > casser entre mes règles personnalisée et celles introduites pas fail2ban > ? Il faut utiliser les chaînes utilisateurs pour rediriger le traffic comme bon il te semble. Regarde les tutoriaux netfilter pour ce qui est des _user-defined chains_ si tu veux des exemples ou bien demande le explicitement. En tout cas, j'utilise énormément cela car je trouve que cela simplifie le script. > 3. Quelle est la différence entre iptables-restore et un script shell qui > commence pas tout nettoyer avant de définir les nouvelles règles ? Je n'ai jamais utilisé iptables-restore, mais je dirais que son intérêt réside dans un gain de temps au chargement des règles. Cela devient vrai quand le nombre de règles devient conséquent évidemment. Ce n'est pas 50 règles iptables qui vont jouer beaucoup. > 4. Sur une machine ne faisant en principe pas passerelle ou autre, que > faire > de la chaîne FORWARD ? Je pensais faire 'iptables -A FORWARD -P DROP' et > u > point c'est tout : est-ce raisonnable ? Je dirais, oui. L'utilisateur ou l'administrateur est quand même sensé connaître le traffic qu'il autorise. Si tu n'en a pas besoin autant ne pas l'autoriser. Dans la majorité des scripts tu remarqueras que la politique par défaut adopter est DROP ; on autorise ensuite ce que l'on a besoin. > 5. J'ai sur mes machines des services qui écoutent sur les ports 111 et > 113 : respectivement portmap et inetd, dont je ne sais pas pourquoi ils > sont là ni à quoi ils servent (embêtant pour décider de la politique > de > filtrage). Je ne sais pas non plus où configurer ces services, et je > constate que sur une machine, portmap écoute uniquement sur 127.0.0.1 > alors > que sur l'autre il écoute partout... Pour limiter l'accès au service portmap, aux services RPC comme lockd, mountd et autres, il faut travailler avec les fichiers /etc/hosts.allow et /etc/hosts.deny. Je ne suis pas assez au point sur portmap pour te faire une explication précise mais en gros il permet de gérer les différent services RPCs. Pour inetd, il permet de lancer des services sur demande. J'ai le cas par exemple de tftpd qui est lancé par inetd lorsqu'une demande de connexion arrive sur le port 69. Le démon associé à mon serveur tftp n'écoute pas en permanence sur le port 69 c'est inetd qui s'en charge et démarre le démon. > 6. Enfin, un question sans doute très stupide sur iptables : quelle est > la > différence entre régler la polique sur une chaîne (par exemple -P DROP) > et > rajouter à la fin de la chaîne une règle qui drope tout ? Moi je fais les deux. La politique par défaut est plus une sécurité au cas où une règle soit mal formatée et ne laisse transiter du traffic non autorisé. La mise en place des cibles DROP dans les règles te permet de dropper du traffic frauduleux le plus tôt possible en laissant passer son contraire pour parcourir toutes les autres règles. --- Franck Joncourt http://www.debian.org/ - http://smhteam.info/wiki/
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter 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]