questions sur iptables

Le
mpg
Bonjour,

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) ?

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 ?

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 ?

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 ?

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

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 ?

Merci d'avance pour vos réponses !

Manuel.


--
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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Franck Joncourt
Le #9645541
On Sun, 13 Jan 2008 21:14:20 +0100, mpg
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
with a subject of "unsubscribe". Trouble? Contact
Geoffroy Youri
Le #9645531
mpg a écrit :
Bonjour,


Bonjour

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 ?



« bonne manière ™» je ne sais pas, mais l'une d'elle proposée dans le
manuel de sécurisation de Debian me convient particulièrement pour un
simple pare-feu :
http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.fr.html#s5.14.3.2

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 ?



Les deux cohabitent très bien, les règles sont définies dans des chaînes
différentes (généralement fail2ban-<JAIL> pour la conf. par défaut). Une
règle instaurée par fail2ban n'interfère pas avec celles définies par le
pare-feu. Du moins j'entends que fail2ban ne modifie pas de chaînes
qu'il n'a pas lui même écrites.

Voila, ce n'est que mon avis, je ne suis pas un spécialiste.

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 ?


As tu un exemple de commande iptable ?
Voila ce que je comprends.

Ignore (« Drop ») tout les paquets entrant :
iptables -P INPUT DROP

Ignore uniquement les paquets entrant sur le port telnet en tcp
iptables -A INPUT -p tcp --dport telnet -j DROP

Geoff



--
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
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #9645401
Salut,

mpg (il est partout !) a écrit :

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 ?



En complément des autres réponses, il y a aussi /etc/ppp/ip-{up,down}.d/
pour les interfaces PPP créées par pppd.

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) ?



Parce qu'il n'y a pas de solution universelle. Par exemple, il y a des
interfaces réseau dynamiques qui ne sont pas gérées par ifup|ifdown,
comme celles gérées par les serveurs VPN.

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 ?



Comme déjà dit, créer une chaîne utilisateur pour les règles de fail2ban
et l'appeler au bon endroit dans les règles personnalisées.

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 ?



Oui. De toute façon si le forwarding IP n'est pas activé et qu'il n'y a
pas de pont avec bridge-nf, aucun paquet ne passera par les chaînes FORWARD.

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



Tu veux dire inetd ou identd ? Le port 113 (auth) est normalement
utilisé par identd, qui sert à informer un serveur distant de l'identité
de l'utilisateur local qui se connecte à lui. C'est utilisé notamment
par les serveurs IRC. La plupart des serveurs IRC exigent d'ailleurs que
le port TCP 113 soit ouvert (ACCEPT) ou fermé (REJECT) mais pas bloqué
(DROP).

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 ?



Si on est amené à ajouter des règles après une règle DROP, elles sont
ignorées. La politique par défaut n'a pas cet inconvénient.
Si on vide une chaîne (iptables -F) la politique par défaut reste alors
que la règle DROP saute.


--
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
with a subject of "unsubscribe". Trouble? Contact
Marc Blanc
Le #9645381
On Sun, 13 Jan 2008 21:14:20 +0100
mpg

Je suis en train d'écrire des règles de filtrage avec iptables pour mes
machines, et je me pose quelques questions.



http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/

--
SGBDRO Open Source PostgreSQL,
Filtrage IP sous Linux avec Netfilter/Iptables,
Ecrire de la documentation avec DocBook.
http://pagesperso-orange.fr/arsace/


--
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
with a subject of "unsubscribe". Trouble? Contact
mpg
Le #9645171
Salut,

Le (on) lundi 14 janvier 2008 13:51, Pascal Hambourg a écrit (wrote) :

mpg (il est partout !) a écrit :


(toi aussi !) (note que je ne m'en plains pas)

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
?



En complément des autres réponses, il y a aussi /etc/ppp/ip-{up,down}.d/
pour les interfaces PPP créées par pppd.



Oki.

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) ?



Parce qu'il n'y a pas de solution universelle. Par exemple, il y a des
interfaces réseau dynamiques qui ne sont pas gérées par ifup|ifdown,
comme celles gérées par les serveurs VPN.



Noté. En ce qui me concerne, je vais sans doute utiliser un script dans
init.d comme indiqué dans le securing-how-to que m'a indiqué Geoffroy. Sur
une de mes machines (celle que je tiens le plus à protéger) il n'y a de
toutes façons qu'un interface, tout le temps connectée. L'autre est un
protable, je pourrais sans doute faire des trucs subtils pour détecter si
je suis chez moi ou pas, mais bon...

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 ?



Comme déjà dit, créer une chaîne utilisateur pour les règles de fail2ban
et l'appeler au bon endroit dans les règles personnalisées.



En fait, fail2ban crée déjà une chaîne utilisateur. Par contre, dans mon
script init.d, il faudra que je fasse attention à la position relative de
mon script et de celui de fail2ban. Au pire je peux désactiver le script
fail2ban pour faire les choses tranquillement à ma manière.

Oui. De toute façon si le forwarding IP n'est pas activé et qu'il n'y a
pas de pont avec bridge-nf, aucun paquet ne passera par les chaînes
FORWARD.



Oki. J'ai d'ailleurs vu dans le securing-how-to qu'il y a d'autres
paramètres à régler en plus des tables netfilter, comme des 0 et des 1 à
mettre dans des fichiers sous /proc/sys/net/ipv4 (et sans doute ipv6).
C'est documenté où ce qui se trouve là-dedans ?

Tu veux dire inetd ou identd ? Le port 113 (auth) est normalement
utilisé par identd, qui sert à informer un serveur distant de l'identité
de l'utilisateur local qui se connecte à lui. C'est utilisé notamment
par les serveurs IRC. La plupart des serveurs IRC exigent d'ailleurs que
le port TCP 113 soit ouvert (ACCEPT) ou fermé (REJECT) mais pas bloqué
(DROP).



Hum, après vérification, il semble que non, ce soit bien inetd :

siegel:~# netstat -pln G 113
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN 3107/inetd
siegel:~#

Maintenant, j'ai fini par comprendre que visiblement inetd est un
meta-serveur qui écoute sur des ports, puis lance les services concernés
uniquement au moment ou une demande de connexion a lieu, en fonction du
port demandé. Et dans /etc/inetd.conf, on a effectivement :
ident stream tcp wait identd /usr/sbin/identd identd
ce qui confirme ce que tu disais. Par ailleurs merci pour l'info sur les
goûts des serveurs IRC (même si je ne pratique pas pour l'instant).

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 ?



Si on est amené à ajouter des règles après une règle DROP, elles sont
ignorées. La politique par défaut n'a pas cet inconvénient.
Si on vide une chaîne (iptables -F) la politique par défaut reste alors
que la règle DROP saute.



Oki, merci. Bon, maintenant me reste plus qu'à pratiquer et à expérimenter
tout ça :)

Manuel.


--
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
with a subject of "unsubscribe". Trouble? Contact
Jean-Michel OLTRA
Le #9645161
Bonjour,


Le mardi 15 janvier 2008, mpg a écrit...


Oki. J'ai d'ailleurs vu dans le securing-how-to qu'il y a d'autres
paramètres à régler en plus des tables netfilter, comme des 0 et des 1 à
mettre dans des fichiers sous /proc/sys/net/ipv4 (et sans doute ipv6).
C'est documenté où ce qui se trouve là-dedans ?



http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



--
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
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #9645061
mpg a écrit :

En fait, fail2ban crée déjà une chaîne utilisateur. Par contre, dans mon
script init.d, il faudra que je fasse attention à la position relative de
mon script et de celui de fail2ban. Au pire je peux désactiver le script
fail2ban pour faire les choses tranquillement à ma manière.



Le script d'init ? Euh, tu es sûr que c'est une bonne idée ? Autrement,
il reste la possibilité de modifier le fichier d'action de fail2ban qui
crée la chaîne au démarrage.

Oki. J'ai d'ailleurs vu dans le securing-how-to qu'il y a d'autres
paramètres à régler en plus des tables netfilter, comme des 0 et des 1 à
mettre dans des fichiers sous /proc/sys/net/ipv4 (et sans doute ipv6).
C'est documenté où ce qui se trouve là-dedans ?



Dans le fichier Documentation/networking/ip-sysctl.txt des sources du noyau.


--
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
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme