Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:fail2ban [16/10/2023 10:57] – [Fail2ban] Zatalyz
+++ pratique:informatique:fail2ban [23/01/2024 11:48] (Version actuelle) – [Commandes Iptables utiles] Zatalyz
@@ Ligne 1: / Ligne 1: @@
 ====== Fail2ban et Iptables ======
+<WRAP center round important 100%>
+Tout ça n'est pas encore au point.
+À un moment faudra que tout ça soit revu de fond en comble... J'apprends petit à petit.
+En attendant, n'utilisez pas ça "comme ça", ne croyez pas à la qualité de ce qui est là !
+</WRAP>
 Fail2ban logiciel me file des boutons mais je n'ai pas vraiment trouvé de remplaçant. Son principal mérite est de délayer les attaques par brute-force ; en principe notre serveur n'y est pas vulnérable, mais les principes et la sécurité... Bref, c'est aussi bien de l'avoir comme protection supplémentaire, selon le principe du tamis : si ça passe une couche, avec un peu de chance ça ne passera pas la suivante.
@@ Ligne 75: / Ligne 84: @@
 #-A INPUT -m set --match-set blocklist_ip src -j DROP
 # Ça, ça ne veut pas...
+#rejeter tout le reste
+-A INPUT -j REJECT --reject-with icmp-port-unreachable
 </code>
 ==== Commandes Iptables utiles ====
 Lister "tout" en vrac :
@@ Ligne 86: / Ligne 99: @@
   iptables -L INPUT --line-numbers
+Sauf que ce n'est pas "tout", genre pour lister les règles nat :
+  iptables -t nat -S
 Enlever une règle d'après son numéro de ligne
   iptables -D INPUT 14
@@ Ligne 91: / Ligne 107: @@
 Restaurer des règles
   iptables-restore /etc/iptables/rules.v4
+==== Quelques explications ====
+=== Différence entre -I et -A ===
+  * ''-I'' signifie "insérer la règle à la ligne n° X" ; sans préciser de numéro, la règle se retrouve au début et a donc la priorité sur tout autre.
+  * ''-A'' indique d'ajouter donc ce sera à la suite du reste des règles.
+Bref, quand on a un fichier qui charge les règles, elles sont forcément les unes après les autres, ''-A'' est indiqué. Si on teste une règle, alors ''-I'' peut être plus pertinent.
+=== DROP ou REJECT --reject-with icmp-port-unreachable ===
+  * ''DROP'' ignore complètement le paquet (comme si le serveur n'existait pas). Il ne renvoie pas de message, ce qui évite les attaques où on force le serveur à envoyer des messages icmp à un autre serveur par exemple.
+  * ''REJECT --reject-with icmp-port-unreachable'' renvoie un message icmp disant que le port est fermé (comme si le service qui écoute sur ce port n'était pas lancé et que le port était inutilisé).
+=== Ordre des règles ===
+Les règles sont appliquées dans l'ordre.
+Donc il faut que les commandes d'ipset et fail2ban soient avant celles qui acceptent une connexion :
+  - On regarde si l'un de ces logiciels dit qu'il faut bloquer l'ip
+    - Si oui, elle dégage
+    - Si non, on passe à la règle suivante
+  - La règle suivante étant "on accepte".
+Sinon, ça serait :
+  - On accepte la connexion
+  - On regarde si fail2ban... ah ben non, forcément, ça ne marche pas, puisque la connexion est acceptée.
 ===== Ipset =====
-Créer une entrée pour toutes les ip qui vont être renvoyées dans les limbes (adapter le nom ''blocklist_ip'':
+Créer une entrée pour toutes les ip qui vont être renvoyées dans les limbes (adapter le nom ''blocklist_ip''):
   ipset create blocklist_ip hash:ip
@@ Ligne 211: / Ligne 253: @@
   * Vérifier la configuration avant de relancer : ''fail2ban-server -t''
   * Bannir une ip en particulier : ''fail2ban-client set <prison> banip <adresse IP>''
-  * Et la débannir : ''fail2ban-client get <prison> actionunban <adresse IP>''
+  * Et la débannir : ''fail2ban-client set <prison> unbanip <adresse IP>''
 ==== Faire ses propres règles Fail2ban ====
 Il y a quelques améliorations à faire concernant les filtres.
@@ Ligne 227: / Ligne 269: @@
 === Ajouter des regex et configurer une jail "aucune chance" ===
-Malgré ça, j'ai encore quelques tentatives des plus douteuses, pas toujours repérées, et puis surtout, c'est tellement suspect qu'une seule tentative devrait suffire à bannir.
+Malgré ça, j'ai encore quelques tentatives des plus douteuses, pas toujours repérées/bannies, et puis surtout, c'est tellement suspect qu'une seule tentative devrait suffire à bannir.
 Voici un exemple de certaines lignes que je souhaite filtrer :
@@ Ligne 251: / Ligne 294: @@
         ^.*connect from .*censys.*\[<HOST>\]
 ignoreregex =
+[Init]
+journalmatch = _SYSTEMD_UNIT=postfix.service
 </code>
 Notez que chaque ligne de la partie "failregex" correspond à une expression régulière différente. La partie importante est ''<HOST>'' qui correspond à l'ip à bannir ; il faut aussi commencer toute regex par ''^'' afin d'indiquer le début de ligne.
+Par ailleurs il faut inclure ''common.conf'' au début... et indiquer les logs à checker dans la section ''Init''.
 On peut ensuite lancer cette commande pour voir si ça checke des correspondances :
@@ Ligne 296: / Ligne 344: @@
 Il faut améliorer les regexp (avec fail2ban-regex). pour virer plus large :
 - toute ip qui tente de se co en ssh avec un user qui n'est pas autorisé => ban définitif
-- toute ip qui passe des commandes à postfix qui ne sont pas "valides" => idem
 </WRAP>
-La ligne postfix que j'aimerais détecter pour bannir, car trop louche :
--07-28T09:19:04.783707+02:00 poste postfix/smtpd[608140]: warning: non-SMTP command from scan-15n.shadowserver.org[184.105.247.252]: GET / HTTP/1.1
 ===== Bannir définitivement les IP harcelantes =====
@@ Ligne 458: / Ligne 503: @@
   * https://www.malekal.com/comment-utiliser-ipset-sur-linux/
   * https://sysreseau.net/iptables-12-commandes/
+  * http://www.delafond.org/traducmanfr/man/man8/iptables.8.html