Je drop une IP, pourtant elle passe

par **talvins** » 07 Sep 2011 10:15

Bonjour,

Je souhaite faire un simple

Code: Tout sélectionner: iptables -A INPUT -s xx.xx.xx.xx -j DROP

lorsque j'ai trop de login failed sur pop3d ou imapd mais après application de cette règle, l'IP bloquée peut toujours se connecter et continuer ses tentatives.
Pour quelle raison ?

Merci.

par **jdh** » 07 Sep 2011 21:15

C'est juste la compréhension de base de Netfilter/Iptables !

NetFilter/Iptables utilise des "chaines", dont certaines sont créés "de base".
Ici c'est la chaine INPUT.

Si vous cherchez (un peu) quel est le rôle de la chaine INPUT, vous devriez comprendre.
Il est à BIEN noter qu'une chaine indique un ordre de traitement ...

Néanmoins, à mon tour, une question : pensez avoir BIEN décrit votre contexte ?
Perso, je NE pense PAS donner d'autres pistes SANS avoir un description du contexte : un problème bien décrit est à moitié résolu ...

par **talvins** » 08 Sep 2011 12:31

J'utilisais souvent iptables il y a quelques années et je n'ai jamais eu de soucis (les tcpdump et autre ethereal ne me disaient pas le contraire) pour des problèmes autrement plus complexes, c'est ce qui me fait honte ici. Bon, effectivement le -A n'est pas la meilleure idée du monde

Comme j'ai balancé cette ligne directement dans la console, je n'ai pas pensé au fait qu'elle allait se stocker à la fin ; un peu comme si elle allait être prioritaire parce que tapé en "temps réel"... Je sais, c'est complétement con. Bref j'avais raison d'avoir honte =D>

Merci pour ton intervention.

par **jdh** » 08 Sep 2011 12:54

Le contexte n'est pas décrit.

En cas de tentative de "brute force" sur un serveur connecté à Internet, il est à conseiller d'utiliser un programme genre "fail2ban" ou "DenyHosts" ...

par **talvins** » 08 Sep 2011 15:35

J'utilise fail2ban. Ce dernier arrête tout plutôt convenablement (toutefois, le DOS sur ce type de service ne semble pas bien compliqué) mais, je ne sais pas - encore - pour quelle(s) raison(s), il ne bloque pas les multiples tentatives pop. Pas encore eu le temps de voir si les regexp matchées (elles sont pourtant très simples).

par **jdh** » 08 Sep 2011 16:05

fail2ban n'est pas configuré par défaut pour pop (de mémoire).

Merci de préciser pourquoi la ligne ne fonctionnait pas ...

par **Franck78** » 08 Sep 2011 19:09

@jdh,
non, tu ne sauras pas si c'est input ou forward ... na!

;-)

Franck

par **jdh** » 08 Sep 2011 19:48

Je pense que talvins a corrigé/trouvé mais il n'explique pas son erreur.
Donc un lecteur n'aura pas l'explication et n'en tirera rien de pratique.

@Franck78 : moi j'ai largement des idées sur l'origine du problème puisque je donne 2 pistes importantes qui jouent.
Je suis certain que tu aurais répondu comme moi à peu près.
Note bien que la piste la plus juste est la seconde.

par **talvins** » 12 Sep 2011 12:34

Je pensais avoir répondu assez clairement en fait. La règle balancée à la volée s'ajoutant en fin de liste et ayant, avant elle, une ouverture sur pop, le port reste ouvert même si l'IP est interdite.
En modifiant donc -A par -I (qui, par défaut, place tout en haut), l'IP est vraiment interdite pour tout. Ce qui, effectivement, fonctionne.

Pour fail2ban, oui, j'ai (re)configuré la plupart des services. Ce qui est nécessaire, déjà à cause des DOS possibles, et ensuite parce qu'une série de mauvais login chez un client avec 50 postes et ce sont les 50 postes qui sont bloqués.

C'est curieux car la regexp match sur le fichier de log, en me sortant bien les IP qui échouent trop souvent. Il me semble que fail2ban-regex ne teste que l'expression rationnelle sans prendre en compte les critères findtime et maxretry. Mais mes findtime (120) et maxretry (6) sont largement suffisant pour prendre en compte cette "attaque", qui n'a pourtant pas été stoppée.

par **jdh** » 12 Sep 2011 19:50

Plus précisément :
-A : append = ajoute en fin
-I : insert = insère (nécessite donc un n° d'ordre)

En fait, la bonne méthode consiste à scripter les instructions de firewall (ou mieux utiliser un générateur de script iptables comme shorewall).
On crééra donc un script avec la succession
- les traditionnels -F -X,
- les policy -P,
- les blocages d'ip (en -A),
- les réelles règles d'autorisation (en -A)
- les règles NAT,
- la masquerade.
(Il y a aussi pas mal de choses à faire en matière de martiens, de blocages IANA, de RFC1918, ...)
(Et j'oublie certainement beaucoup de choses ...)

Il est notable qu'un tel script est dépendant du contexte : la machine hôte est un firewall ou un hôte en DMZ = chaîne INPUT ou chaîne FORWARD !

par **talvins** » 15 Sep 2011 11:04

Oui, certes, je suis là dans un contexte firewall.

Pour -I, ça ne nécessite pas un argument : sans ça, ta règle passe avant les autres. C'est le comportement pas défaut.

Je drop une IP, pourtant elle passe

Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Re: Je drop une IP, pourtant elle passe

Qui est en ligne ?