Bonjour,
J’aurais besoin de conseils concernant le fonctionnement de fail2ban et iptables sur un RPI.
Je suis sous debian 11.11, et lorsqu’une adresse IP est bannie, tout fonctionne correctement si ce n’est qu’une ligne s’ajoute en 1er test dans iptables, ligne qui strappe ma config (DROP…).
Si tu parles de la ligne #1 c’est une règle de fail2ban qui a été activée dans /etc/jail.conf ou jail.local.
Il est donc normal que tu l’as vas apparaitre dans le résumé de iptable.
Tous les paquets entrants (dports) de type http ou https (port 80 ou 443) sont donc scannés et filtrés par cette règle.
Si tu veux avoir accès depuis l’extérieur à ton jeedom il te faut cette règle car le port 443 va être utilisé pour te connecter depuis l’extérieur, il faut donc le sécuriser d’où cette règle activée par l’installation de jeedom.
Suite aux bannissements d’adresses IP, je me suis aperçu qu’une même adresse IP revenait se faire bannir alors que son bantime n’était pas encore fini.
Je me suis ainsi aperçu de cette règle ‹ passe tout › s’ajoutait en 1ere règle dès qu’il y a un bannissement.
Dans la dernière règle iptables, j’ai bien une ligne qui autorise des paquets:
L’ordre des règles dans chaque chaîne (INPUT pour ce sujet) est important.
En fait, la 1ere règle d’une chaîne doit avoir un niveau de filtrage plus élevé que les règles suivantes et ainsi de suite.
Le filtrage des ‹ paquets › commence par la règle de la ligne 1. Si ce paquet n’est pas concerné par la règle de la ligne 1, une vérification est fait avec la règle décrite en ligne 2 et ainsi de suite jusqu’à la dernière règle.
Dès qu’une règle accepte le paquet, iptables autorise les trames de ce paquet.
Ainsi, si la 1ere ligne autorise tous les flux, il n’y a plus aucune interdiction.
J’ai regardé dans les fichiers jail et ne trouve pas ce qui modifierait iptables, de plus avec les droits de root.
Y aurait-il un fichier log qui pourrait me dire qui fait quoi sur iptables ou un autre moyen de savoir qui modifie les règles ?
Que vous mélangez deux choses: cause et conséquence.
Cette ligne c’est la requête du client. Il essaie donc d’accéder au fichier « sitemap.xml », un fichier bien connu en SEO. Ce client n’est donc qu’un robot d’indexation probablement.
Et ce log est généré par Apache, parce que l’accès n’a pas été autorisé par lui (qu’importe la raison) et donc requête http rejeté. Cela n’a aucun rapport avec iptables (on est déjà « après » dans la chaîne d’exécution)
Par contre c’est probablement plusieurs requêtes en échec de ce type qui ont provoqué le bannissement car c’est bien comme cela que fonctionne fail2ban (c’est dans le nom…): suite à trop de « fail », il « ban ». Autrement dit, en lisant les logs à la recherche de requêtes en échec/ refusées, il va bannir le client correspondant.
Autrement dis, ce log est probablement la cause du bannissement et non la conséquence.
Bonjour,
et Merci @Mips de vos explications qui permettent de mieux comprendre le pourquoi de ce message informatif
Il me reste donc à élucider pourquoi une règle ‹ généraliste › s’ajoute sans avertissement en 1er choix dans iptables juste après un bannissement, règle qui squeezent mes propres règles.
Je ne suis plus tout jeune , mais je ne me rappelle pas avoir eu ce ‹ fonctionnement › lorsque j’étais sous debian 10.
Comme je suis passé sous debian 11 il y a quelques mois (en suivant des tutos de la communauté) et ai découvert cette règle que récemment, je ne vais pas le valider.
Peut être une piste.
Je viens de ‹ trouver › que sous debian 11, iptables existe toujours mais s’appuie sur nftables, à priori son remplaçant.
Et dans son fonctionnement, nftables traiterait à l’inverse de iptables, à savoir la règle la moins stricte en 1er, jusqu’aux DROP.
Dans ma config où j’ai reproduit mon ancienne config iptables sur l’installation sous debian 11 (iptables était pré-installé), il se pourrait que j’ai maintenant un fonctionnement ‹ bancal › avec un filtrage utilisant iptables et un OS Debian qui réagirait sur un fonctionnement nftables.
Je me suis inspiré de l’écrit de @amoi69 que je remercie
En fait, j’ai placé ces règles ‹ passe tout › de chacune des prisons fail2ban en fin de ma Chain INPUT, soit après mes DROP (règles qui s’ajoutaient suite aux bannissements d’adresses IP (apache-noscript, etc.).
Ainsi, ces paquets seront acceptés seulement si les DROP précédents les autorisent.
Et dans cette configuration, les bannissements n’ajoutent plus ces règles dans INPUT.
Je n’ai pas trouvé par où ces règles s’ajoutaient mais d’un point de vue sécurité, je ne les ai plus (en tout cas je n’arrive plus à les déclencher avec des ban d’adresse IP).
Pour ceux qui pensaient comme moi que rien ne pouvait modifier cette table ‹ sécurité › une fois définie, je vous invite à jeter un œil sur vos règles
, mais je ne me rappelle pas avoir eu ce ‹ fonctionnement › lorsque j’étais sous debian 10.