Salut, j’essaie de bloquer temporairement un sous-réseau /16 abusif qui submerge un forum Discourse de requêtes. J’ai essayé ceci…
…mais je vois toujours un nombre énorme de nouvelles requêtes provenant de la même plage dans /var/discourse/shared/standalone/log/var-log/nginx/access.log.
Puisque ceux-ci sont configurés dans Discourse, je suis à peu près sûr que les adresses IP sont bloquées par Discourse, et non par NGINX, donc elles apparaîtront dans les journaux NGINX. C’est Discourse qui les bloque, pas nginx. Si vous voulez les bloquer afin qu’elles n’apparaissent pas dans les journaux NGINX, vous pourriez les bloquer avec votre pare-feu.
Merci Jay, tu as raison sur le fait que cela apparaîtrait toujours dans les journaux Nginx si bloqué au niveau de l’application. Cependant, le blocage au niveau de l’application ne fait pas non plus ce que j’attendrais. J’ai essayé de me connecter via un VPN, puis j’ai ajouté ma propre adresse IP à la liste « IP filtrées », mais cela m’a quand même permis de naviguer sur le forum. Je pense que cela doit être appelé « IP filtrées » et non « IP bloquées » car peut-être que cela empêche uniquement ces adresses IP de s’enregistrer pour un compte ?
Ce dont j’ai besoin, c’est que l’application Discourse refuse l’accès aux pages demandées pour les requêtes provenant de ces adresses, et surtout qu’elle ne rende pas ces pages, car toutes ces requêtes font saturer le CPU.
Est-ce que Discourse voit que vous venez d’une des adresses IP bannies si vous consultez l’enregistrement de l’utilisateur à partir de /admin/users ? (Si vous êtes derrière un proxy comme Cloudflare, alors Discourse peut voir votre IP de proxy et non l’IP de l’utilisateur.)
Oui, lorsque je me connecte au VPN, puis que je regarde la dernière adresse IP de mon compte utilisateur dans Discourse, elle affiche l’adresse IP que mon VPN m’a donnée. Cependant, lorsque j’ouvre une fenêtre de navigateur incognito et que j’essaie d’enregistrer un nouveau compte, cela ne le permet pas :
Les nouvelles inscriptions ne sont pas autorisées depuis votre adresse IP.
Il semble donc que les « adresses IP filtrées » soient uniquement destinées à l’enregistrement, et non à interdire complètement l’accès au site Web.
Et pour compliquer davantage les choses, ufw sur le serveur hôte ne bloque apparemment pas les choses comme prévu à l’intérieur de Docker :
Je ne suis pas sûr de l’endroit où nous documentons cela, mais cela a été soulevé à plusieurs reprises récemment.
Les « adresses IP filtrées » bloquent les enregistrements et les connexions à partir des adresses IP bloquées qui correspondent, mais pas les sessions existantes.
Je ne suis pas sûr de l’endroit (si tant est que nous le documentions) où cela est documenté.
Merci de votre confirmation.
Quelle serait donc la méthode la plus simple pour refuser les requêtes d’une adresse IP ou d’une plage d’adresses IP ? J’ai trouvé ceci, mais il semble que ce soit le contraire de ce dont j’ai besoin (liste blanche plutôt que liste noire) et jouer avec la configuration Nginx à l’intérieur du conteneur donne l’impression d’un travail de bricoleur :
Je pense que cela se fait avec UFW ou IPTABLES. Cela supprime et arrête les requêtes avant que Discourse n’intervienne. J’ai toujours peur de modifier les pare-feux de peur de me bloquer, mais si vous ciblez uniquement le port 443, vous ne courez aucun danger.
Digital Ocean a quelques indices : UFW Essentials: Common Firewall Rules and Commands for Linux Security | DigitalOcean. Je chercherais juste des exemples sur Google.
Exactement ma crainte aussi. Mais je l’ai activé sur l’hôte et pourtant, il ne bloque toujours pas la plage d’adresses IP problématique. Apparemment, il faut un ensemble de règles alambiquées pour qu’il applique les règles de refus aux conteneurs Docker.
Oh. Oui. C’est tout à fait vrai. J’ai fini par bloquer l’accès de mes serveurs web basés sur Docker à la base de données postgres basée sur Docker (probablement pas l’un de vos problèmes).
Voici une autre idée : Geo Blocking plugin
Merci, j’avais aussi regardé ça, mais il ne semble pas permettre de bloquer des plages d’adresses IP numériques, juste des pays entiers ?
Je ne l’ai pas installé récemment, mais je suis à peu près sûr que c’est le cas
(emphase ajoutée)
Mais ensuite, j’ai trouvé ceci :
Donc, je pense que cela signifie que vous pouvez y mettre le réseau que vous voulez.
/var/discourse/launcher enter app
apt install nano
nano /etc/nginx/conf.d/discourse.conf
Et dans le bloc server {, ajoutez :
## 2025-10-27
deny 12.34.0.0/16;
Ensuite, enregistrez et
nginx -t
service nginx reload
Je ne comprends pas tout à fait pourquoi je vois toujours des requêtes de 12.34.x.x dans le access.log de Nginx, mais cela semble fonctionner car l’utilisation du CPU est redevenue normale. Processus incroyablement compliqué à mon humble avis, mais suffisant pour le moment pour remettre le site sur pied.
Oui, mais actuellement, il n’accepte que les numéros AS et non la notation CIDR comme 1.2.3.0/24.
Est-ce que cela a fonctionné ? Je pense que vous devez faire
sv restart nginx
Mais si vous n’avez pas eu d’erreur, j’ai tort.
Nginx les voit toujours ? Indique-t-il qu’il les sert ? Voyez-vous ces requêtes dans le production.log de Rails ?
Ah. J’aurais peut-être dû prêter plus d’attention à cette page Wikipédia sur les numéros AS.
Je pense qu’il s’agit de deux anciens alias qui sont maintenant mappés sur des commandes systemd, donc systemctl restart nginx serait le plus approprié.
EDIT : Il semble que systemctl ne fonctionne pas à l’intérieur de Docker. Voici quelques explications sur les différences :
Oui, dans le access.log, ils apparaissent toujours comme :
[28/Oct/2025:00:29:27 +0000] "myforum.com" 12.34.56.78 "GET /permalink/12345 HTTP/1.1" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" "-" 403 691 "-" - 0.000 "-" "-" "-" "-" "-" "-" "-" "
Ils semblent principalement cibler les permaliens maintenant (migrés d’une ancienne plateforme de forum). Y a-t-il une sorte de faille avec les permaliens qui permet de contourner la règle deny ? Je n’ai pas encore vérifié le production.log.
Dans l’ensemble, je dirais que le manque d’interface graphique pour inspecter les logs d’accès et l’absence de liste noire d’IP au niveau de l’application sont une limitation assez importante de Discourse. C’est une occurrence peu fréquente, mais lorsque vous êtes frappé par l’une de ces attaques de bots/scrapers/crawlers, vous voulez simplement identifier immédiatement la source et l’atténuer, sans tripoter un tas de fichiers de configuration et de commandes obscures, surtout pas à des niveaux profonds à l’intérieur d’un conteneur Docker avec toutes les abstractions étranges qui s’y déroulent. L’ancienne plateforme de forum dont j’ai migré affichait une simple liste des utilisateurs ou des adresses IP ayant le plus de requêtes pendant une fenêtre de temps réglable, et elle pouvait même être filtrée par les utilisateurs et/ou les adresses IP qui occupaient le plus de temps CPU. De cette façon, je pouvais rapidement identifier l’adresse ou la plage fautive, et il y avait une interface en un clic pour l’ajouter à une liste noire, et cela renvoyait un 404 pour les requêtes provenant de ces adresses IP.
Si vous avez une règle deny, les choses sont toujours enregistrées dans nginx. Et cela fonctionne correctement, car il y a un 403 là-bas, ce qui signifie que le client s’est vu refuser l’accès.
Ces requêtes ne sont pas transmises à Discourse. Si vous voulez savoir si votre blocage fonctionne correctement, vous devriez soit
production.log de Discourse à la place403 dans le champ du code de réponse HTTP.Ce sujet est-il maintenant résolu ? Y a-t-il un message de @rgj ou @pfaffman que je peux choisir comme solution ? Il semble que vous ayez collaboré sur celui-ci !
Salut, je dirais que ce problème n’est pas vraiment résoluble pour le moment par des méthodes « normales ». L’interface d’administration pour les « IPs filtrées » ne fait pas ce que la plupart des utilisateurs attendraient probablement, et la méthode qui fonctionne réellement implique de trifouiller à l’intérieur du conteneur Docker de Discourse, c’est donc plus un hack sale qu’une solution, du moins selon moi. Ce serait formidable si cela obtenait un peu plus d’attention :