Différences

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

--- pratique:informatique:fight_bot [27/08/2026 12:48] – créée Zatalyz
+++ pratique:informatique:fight_bot [28/08/2026 11:24] (Version actuelle) – [SYN Flood] Zatalyz
@@ Ligne 12: / Ligne 12: @@
   * Monitoring ?
     * Goaccess ? ça permettrait de voir ce qui circule, mais faut que je trouve comment le paramétrer.
+==== Goaccess ====
+Dans les dépôts debian. Doc sur [[https://goaccess.io]].
+Il faut les logs personnalisés apache.
+<code bash /etc/apache/conf-enabled/log.conf>
+LogFormat "%h ☆ %v ☆ %t ☆ Code %>s ☆ %O o ☆ \"%r\" ☆ \"%{User-Agent}i\" ☆ \"%{Referer}i\" " vhost_maison
+CustomLog ${APACHE_LOG_DIR}/access.log vhost_maison</code>
+Puis modifier la config de goaccess.
+<code bash /etc//goaccess/goaccess.conf>
+# Format de l'heure comme Apache le gère
+datetime-format %d/%b/%Y:%H:%M:%S %z
+# Notre regex transcrite en langage goaccess
+log-format %h ☆ %v ☆ [%x] ☆ Code %>s ☆ %O o ☆ \"%r\" ☆ \"%u\" ☆ \"%R\"
+</code>
+  * ''%t'' devient ''[%x]'' parce que c'est le “datetime-format” dans goaccess et non “time-format”. Ça marche, on ne va pas chercher. Les autres trucs ont aussi quelques nuances mais ça reste proche.
 ===== Méthodes de combat =====
@@ Ligne 54: / Ligne 73: @@
 Un blocage géographique peut dépanner temporairement mais n'est pas une solution à long terme. Pulkomandy indique que ces bots "ont tendance à utiliser des user agents ne correspondant pas à la toute dernière version", cela peut être un critère de détection, mais qui me semble délicat à manier.
+==== SYN Flood ====
+Ce n'est pas exactement ça, mais ça en fait partie.
+La problématique : des milliers d'ip faisant chacune 1 requête. Fail2ban/reaction/les modules apaches ont du mal à détecter ça mais ça le serveur à genou.
+  * Rustine 1 : limiter le nombre de connexions pour apache (rate limite etc) ; mais cela rendra le web lent/innaccesible aussi pour les utilisatrices légitimes (suffit qu'elles soient dans le mauvais paquet)
+  * Rustine 2 : gestion du SYN flood via nftables et /etc/sysctl.conf (les deux). Je crains que le souci soit le même que l'autre rustine.
+  * À tester : Filtrage par ASN(([[https://fr.wikipedia.org/wiki/Autonomous_System|Autonomous System Number]], un identifiant pour un ensemble de réseaux informatiques IP intégrés à Internet, généralement sous le contrôle d'une entité/organisation unique (comme un fournisseur d'accès à Internet))).
+=== Lutte via ASN ===
+<WRAP center round todo 60%>
+Notes en brouillon.
+</WRAP>
+Trouver l'ASN lié à une ip :
+  whois -h whois.radb.net 192.*.*.*
+Une fois qu'on a le nom du fournisseur de datacenter qui merdouille, on peut pister son infra avec https://bgp.he.net/ : entrer le nom fourni (par exemple AWS) et on a toutes les plages qui lui sont attribuées. Le souci c'est qu'il y en a vraiment beaucoup. Le souci aussi est que certains réseaux sont mixtes : service de téléphonie+datacenters. Or on va essayer de limiter le ban du premier.
+Un outil pour réduire les plages d'ip : [[https://packages.debian.org/trixie/aggregate|aggregate]]. Usage (y'a ptet plus propre) :
+  cat badip_vrac.txt| aggregate -q > badip_concat.txt
+  - On va commencer par extraire toutes les ip incriminées d'un log (script bash => on garde *toutes* les ips mais on les trie par occurence (celles qui ont fait une seule demande, celles qui en on fait 100).
+  - On regroupe un peu avec aggregate déjà ?
+  - On fait une requête whois au radb et on note les ASN ? (sort|uniq là aussi)
+  - On récupère les CIDR des ASN. ''aggregate'' encore pour fusionner.
+  - On envoie cette liste à nftables.
 {{tag>Bot Informatique Sysadmin}}