Les mauvaises pratiques s'accumulent, et si le crawl sauvage a toujours existé, il devient problématique à l'excès, menant à faire tomber les services web.

Avant de bloquer tout azimut, il faut définir ce qu'on veut bloquer. On peut par exemple décider, par conviction éthique, de bloquer les moteurs de recherhes et indexeurs LLM, ou bien les tolérer.

• Monitoring ?
  • Goaccess ? ça permettrait de voir ce qui circule, mais faut que je trouve comment le paramétrer.

Dans les dépôts debian. Doc sur https://goaccess.io.

Il faut les logs personnalisés apache.

/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

Puis modifier la config de goaccess.

/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\"

• %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.

Il n'y a pas une solution miracle, mais la mise en place de diverses techniques qui, cumulées, peuvent baisser les dégâts que font ces enquiquineurs.

1. Pare-feu paramétré sur chaque machine, idéalement nftables (cf aussi iptables au besoin.
2. SSH correctement paramétré ¹⁾, avec sshguard (facile et efficace, bien que redondant avec le reste) voir connexion via bastion.
3. Paramétrage de Reaction et Fail2ban. Un seul bien paramétré suffit, les deux peuvent cohabiter. Fail2ban a l'avantage d'avoir des lots de règles toutes prêtes, l'inconvénient qu'elles sont légères, et que l'archi générale est un enfer sur lequel intervenir.
4. Maintenir une liste d'ip bloquées par réseau (voir plus bas)

Certaines solutions sont propres au type de service.

• Web : apache/nginx. Liens vers les paramétrages de ces services.
  • Modules antibot Liens vers les paramétrages de ces services.
  • robots.txt :
    1. le faire à chaque racine de site
    2. paramétrer “Crawl-Delay” pour limiter les moteurs de recherches, capables de faire tomber aussi un site
    3. honeypot : mettre un Disallow /url-interdite. Quiconque la visite est directement banni.
  • L'url interdite peut aussi être présente ailleurs (genre pied de page), en nofollow, avec indiqué “si vous voulez vous faire bannir, cliquez ici”.
• Mail ?

Solutions type iocaine, anubis, cloudfront : je leur trouve pas mal de défaut sur les utilisatrices (typiquement je ne peux pas aller sur ce genre de site avec mon smartphone qui a peu de ram) pour un résultat discutable.

Les deux vont un peu ensemble.

D'abord, les listes d'ip bloquées.

• On peut déclarer des domaines comme problématiques, faire un script qui vérifie de temps en temps leurs ip liées, et bloquer ces réseaux. CF https://wiki.mesnumeriques.fr/securite:banlist
• On peut aussi analyser les ip bloquées via Reaction, et bloquer plus largement un réseau quand des ip différentes apparaissent.
• Comment détecter les ip tournantes ? Celles où l'ip ne teste qu'une seule adresse, mais que tout le pool d'ip le fait une fois ? (⇒ grosse charge aussi)
• Idéalement, partager ces listes entre ses serveurs. Mais je réfute des listes publiques ; les problèmes des uns ne sont pas ceux des autres, il n'y a pas une solution qui conviendra à tout le monde (typiquement je refuse de bloquer par pays, si je peux l'éviter).

Ensuite, les listes d'ip autorisées :

• Typiquement pour le mail, il *faut* déclarer les serveurs des gafams, ça évite de les bannir par inadvertance. Enfin, si on veut causer avec eux.
• Certains services demandent de communiquer avec d'autres serveurs (voir cette conversation Chatons), genre des instances de fediverse. Ces autres serveurs peuvent être dans des plages d'ip à côté de gros relous ; évitons de les bannir à cause de leur mauvais voisinage.
• Enregistrer les ip des utilisatrices enregistrées (en anonymisant) peut permettre de les mettre en allowlist.
• Idem sur des utilisatrices cliquant sur le bouton “je ne suis pas un bot” (mais faut faire la page et le formulaire).

Un souci compliqué. Grâce aux objets connectés moisis, les attaques peuvent venir d'ip résidentielles, et bannir largement va poser quelques soucis à des utilisatrices légitimes, sans parler de la charge mémoire de bloquer autant.

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.

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²⁾).

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 : aggregate. Usage (y'a ptet plus propre) :

cat badip_vrac.txt| aggregate -q > badip_concat.txt

1. 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).
2. On regroupe un peu avec aggregate déjà ?
3. On fait une requête whois au radb et on note les ASN ? (sort|uniq là aussi)
4. On récupère les CIDR des ASN. aggregate encore pour fusionner.
5. On envoie cette liste à nftables.