Outils pour utilisateurs

Outils du site


anubis

Anubis

Cette page est un court exemple d'installation et configuration d'Anubis. Elle ne prétend absolument pas être un tutoriel complet, juste une présentation de la configuration de base.

Anubis est une solution qui permet de bloquer les bots (en particulier ceux des sociétés d'IA) tout en laissant passer les vrais humains. C'est une solution légère qui ne nécessite pas de recourir à des captchas et qui est 100% auto-hébergée. Elle impose un peu de charge du côté de l'internaute, mais permet d'alléger énormément la charge sur le serveur.

Concrètement, Anubis se présente comme un reverse-proxy qui se place entre les internautes et votre site web. Il est assez léger (le .deb fait moins de 6 Mo), ne nécessite que 3 fichiers de configuration (exemples fournis) et ne consomme qu'une vingtaine de méga-octets de mémoire vive.

Site officiel : https://anubis.techaro.lol/

Pour voir à quoi ressemble le challenge, ouvrez une fenêtre de navigation privée sur le site officiel d'Anubis (ci-dessus). Notez qu'à partir du moment où vous avez activé Anubis pour un site, les internautes devront avoir javascript et les cookies d'activés, sans quoi ils ne pourront pas accéder à votre site.

Pour notre exemple, nous allons partir du principe que nous avons déjà un site web fonctionnel qui répond en http sur le port 80. Les chemins des fichiers et commandes sont ceux d'une Debian.

Téléchargement et installation

Configuration

Nous avons besoin de 3 fichiers:

  • Un fichier .env pour Anubis qui indique sur quel port écouter, vers quel port rediriger, et quelles policies (règles) appliquer.
  • Un fichier .botPolicies.yaml pour les règles.
  • Un fichier de configuration Apache (en mode reverse-proxy)

Anubis

Anubis fournit des fichiers d'exemple qu'on peut utiliser comme base.

sudo cp /etc/anubis/default.env /etc/anubis/monsite.env
sudo cp /usr/share/doc/anubis/botPolicies.yaml /etc/anubis/monsite.botPolicies.yaml

Nous allons modifier le fichier /etc/anubis/monsite.env et y mettre:

BIND=:9999
BIND_NETWORK=tcp
DIFFICULTY=4
METRICS_BIND=:9090
SERVE_ROBOTS_TXT=0
METRICS_BIND_NETWORK=tcp
POLICY_FNAME=/etc/anubis/monsite.botPolicies.yaml
TARGET=http://localhost:80

Avec ce fichier, Anubis va agir comme un reverse-proxy en écoutant sur le port 9999 et en renvoyant le trafic vers le port 80. On ne touche pas pour le moment au fichier monsite.botPolicies.yaml qui contient des règles par défaut.

On va maintenant activer le service Anubis:

sudo systemctl enable --now anubis@monsite.service

Et vérifier qu'il répond (la commande suivante doit vous renvoyer plusieurs pages de texte) :

curl http://localhost:9090/metrics

(Le port 9090 est juste un port de service pour Anubis)

Apache

Anubis ne parlant qu'en http, il faut utiliser Apache comme reverse-proxy pour décapsuler le trafic https. Pour tester, on va pour le moment le mettre en écoute sur le port 9443. On créé le fichier /etc/apache2/sites-available/anubis-monsite.conf contenant:

Listen 9443
<VirtualHost *:9443>
       ServerName monserveur.mondomaine.org
       DocumentRoot /var/www
       ErrorLog /var/log/apache2/anubis-error.log
       CustomLog /var/log/apache2/anubis.log combined

       SSLEngine on
       SSLCertificateFile /etc/letsencrypt/live/monserveur.mondomaine.org/fullchain.pem
       SSLCertificateKeyFile /etc/letsencrypt/live/monserveur.mondomaine.org/privkey.pem
       Include /etc/letsencrypt/options-ssl-apache.conf
       Protocols h2 http/1.1

       # Enable only strong encryption ciphers and prefer versions with Forward Secrecy
       SSLCipherSuite HIGH:RC4-SHA:AES128-SHA:!aNULL:!MD5
       SSLHonorCipherOrder on

       # Disable insecure SSL and TLS versions
       SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

       # These headers need to be set or else Anubis will
       # throw an "admin misconfiguration" error.
       RequestHeader set "X-Real-Ip" expr=%{REMOTE_ADDR}
       RequestHeader set X-Forwarded-Proto "https"

       ProxyPreserveHost On
       ProxyRequests Off
       ProxyVia Off

       ProxyPass / http://[::1]:9999/
       ProxyPassReverse / http://[::1]:9999/
</VirtualHost>

Puis on active cette config:

sudo a2ensite anubis-monsite.conf

et on demande à Apache de recharger sa config :

sudo systemctl reload apache2

Test

On se retrouve donc dans la situation suivante:

  • Le reverse-proxy Apache écoute sur 9443 en https et renvoie à Anubis en http sur le port 9999
  • Anubis écoute sur le port 9999 en http et renvoie au port 80 en http.

anubis-diagramme.png

Vous pouvez essayer d'accéder à votre site https://monsite.monserveur.org:9443

Si vous constatez que tout fonctionne bien, vous pouvez changer le port 9443 en 443 (et désactiver votre ancien virtualhost du port 443 dans la config Apache).

Pour aller plus loin

Je vous encourage à plonger dans le fichier de policies d'Anubis (.botPolicies.yaml) pour le modifier selon vos préférences (par exemple pour laisser explicitement passer certaines URLs ou certains User-Agents). C'est un sujet que nous n'aborderons pas ici.

La documentation se trouve là : https://anubis.techaro.lol/docs/admin/policies/

Par défaut:

  • Anubis présentera systématiquement le challenge aux clients qui prétendent être des navigateurs ("Mozilla" ou "Opera" dans le User-Agent). (Cela ne bloquera donc pas par défaut des clients comme curl, Python-urllib ou des clients RSS).
  • Anubis bloque par défaut les bots connus pour mal se comporter.
  • Anubis laisse passer les "bons" bots (indexeurs de moteurs de recherche (GAFAM, mais aussi Kagi, Mojeek, The Internet Archive…)
  • Anubis laisse passer les URLs "connues" sans challenge (well-known, favicon, robots.txt…)

Il est à noter que quand un client est refusé, Anubis n'envoie pas un code HTTP 4xx, mais un 200 ("ok"), car il semble que les bots insistent quand on leur renvoie autre-chose qu'un 200.

Anubis n'est pas une solution miracle qui va vous protéger de toutes les attaques. Son but n'est d'ailleurs pas la sécurité, mais juste de préserver les performances de votre serveur face à la majorité des bots.

FAQ

  • Pourquoi pas des captchas ?
  • Parce qu'avoir à résoudre 12 captchas de suite, c'est véritablement casse-couilles (coucou Google Recaptcha, entre autres). Avec Anubis, il y a juste à attendre quelques secondes. C'est beaucoup plus sympa pour l'utilisateur.
  • Pourquoi pas la protection de CloudFlare ?
  • Pour éviter de refiler encore des informations (et toutes les adresses IP de vos visiteurs) à CloudFlare (qui, je le rappelle, n'est toujours pas légale en Europe). De plus Anubis étant entièrement auto-hébergé, vous ne dépendez d'aucun fournisseur de service externe.
  • Pourquoi ça impacterait les bots/IA ?
  • Parce que les bots n'interprètent généralement pas le javascript. Ce qui leur bloque totalement l'accès à votre site.
  • Oui mais si les bots interprète le javascript, ils peuvent passer !
  • S'ils interprètent le javascript, ils se retrouvent avec un autre problème : Étant donné les requêtes massives qu'ils font, cela sera très couteux pour eux en CPU, et donc en électricité. Il faut les toucher là où ça fait mal: Le fric. Et c'est quelquechose d'extrêmement critique pour eux.
    • À titre d'exemple: Pour l'internaute, c'est généralement 4 secondes à attendre. Mais imaginez cela dans le cas d'OpenStreetMap qui se prend un million de requêtes en 24 heures de la part de Google. Imaginons qu'il faille 4 secondes de calcul. Un million de fois 4 secondes de calcul, cela fait 46 jours de calcul de CPU. Ça devient problématique pour eux.
    • Bien sûr c'est un jeu du chat et de la souris, mais la difficulté du challenge d'Anubis peut être ajustée avec un simple paramètre.

Liens

Alternatives

Au lieu de bloquer les bots, certains préfèrent les pourrir avec un labyrinthe de pages contenant des textes bidons. C'est aussi une manière d'entraver les sociétés d'IA, mais cela va augmenter la charge de votre serveur, non la diminuer.

anubis.txt · Dernière modification : 2025/05/19 15:30 de sebsauvage