Re: questions sur iptables
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions sur iptables
On Sun, 13 Jan 2008 21:14:20 +0100 mpg [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions sur iptables
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions sur iptables
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 00 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 waitidentd /usr/sbin/identdidentd
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions sur iptables
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
questions sur iptables
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: questions sur iptables
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]
Re: questions sur iptables
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
