[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: questions sur iptables



 On Sun, 13 Jan 2008 21:14:20 +0100, mpg <manuel.pg@free.fr> 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/


Reply to: