Bonjour,
Je suis en train d'écrire des règles de filtrage avec iptables pour
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,
?
Pourquoi n'y a-t-il pas de mécanisme générique prévu (il me semble
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
?
3. Quelle est la différence entre iptables-restore et un script shell
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'
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
et
rajouter à la fin de la chaîne une règle qui drope tout ?
Bonjour,
Je suis en train d'écrire des règles de filtrage avec iptables pour
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,
?
Pourquoi n'y a-t-il pas de mécanisme générique prévu (il me semble
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
?
3. Quelle est la différence entre iptables-restore et un script shell
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'
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
et
rajouter à la fin de la chaîne une règle qui drope tout ?
Bonjour,
Je suis en train d'écrire des règles de filtrage avec iptables pour
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,
?
Pourquoi n'y a-t-il pas de mécanisme générique prévu (il me semble
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
?
3. Quelle est la différence entre iptables-restore et un script shell
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'
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
et
rajouter à la fin de la chaîne une règle qui drope tout ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
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 ?
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 ?
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
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 ?
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 ?
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
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 ?
Je suis en train d'écrire des règles de filtrage avec iptables pour mes
machines, et je me pose quelques questions.
Je suis en train d'écrire des règles de filtrage avec iptables pour mes
machines, et je me pose quelques questions.
Je suis en train d'écrire des règles de filtrage avec iptables pour mes
machines, et je me pose quelques questions.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ?
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 ?
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 ?
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.
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 ?
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.
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 ?
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.
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 ?