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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
