Ciao, sto cercando di bloccare temporaneamente una subnet /16 abusiva che sta inondando un forum Discourse di richieste. Ho provato questo…
…ma sto ancora vedendo un numero enorme di nuove richieste dallo stesso intervallo in /var/discourse/shared/standalone/log/var-log/nginx/access.log.
Poiché sono configurati in Discourse, sono abbastanza sicuro che gli IP vengano bloccati da Discourse, non da NGINX, quindi appariranno nei log di NGINX. È Discourse che li sta bloccando, non nginx. Se vuoi bloccarli in modo che non appaiano nei log di NGINX, potresti bloccarli con il tuo firewall.
Grazie Jay, hai ragione sul fatto che apparirebbe comunque nei log di Nginx se bloccato a livello di applicazione. Tuttavia, anche il blocco a livello di applicazione non sta facendo ciò che mi aspetterei. Ho provato a connettermi tramite una VPN e poi ho aggiunto il mio indirizzo IP alla lista "Screened IPs", ma mi ha comunque permesso di navigare nel forum. Penso che debba essere chiamato "Screened IPs" e non "Blocked IPs" perché forse impedisce solo a quegli IP di registrare un account?
Ciò di cui ho bisogno è che l’app Discourse neghi l’accesso alle pagine richieste per le richieste provenienti da quegli indirizzi e, soprattutto, che non renda quelle pagine, poiché tutte quelle richieste stanno sovraccaricando la CPU.
Discourse vede che stai arrivando da uno degli IP bannati se vai a guardare il record utente da /admin/users? (Se sei dietro un proxy come Cloudflare, allora Discourse potrebbe vedere il tuo IP proxy e non l’IP dell’utente.)
Sì, quando mi connetto alla VPN e poi controllo l’ultimo IP del mio account utente in Discourse, viene visualizzato l’IP che la mia VPN mi ha assegnato. Tuttavia, quando apro una finestra del browser in incognito e provo a registrare un nuovo account, non me lo consente:
Le nuove registrazioni non sono consentite dal tuo indirizzo IP.
Quindi sembra che gli “IP filtrati” siano solo per la registrazione, non per impedire completamente l’accesso al sito web.
E per complicare ulteriormente le cose, ufw sul server host apparentemente non blocca le cose come previsto all’interno di Docker:
Non sono sicuro di dove documentiamo questo, ma è emerso un paio di volte di recente.
“IP filtrati” blocca registrazioni e accessi da IP bloccati corrispondenti, ma non sessioni esistenti.
Non sono sicuro di dove (se) documentiamo questo.
Grazie per la conferma.
Quindi, qual è il metodo più semplice per negare le richieste da un IP o da un intervallo di IP? Ho trovato questo, ma sembra essere l’opposto di ciò di cui ho bisogno. (whitelist anziché blacklist) e armeggiare con la configurazione di Nginx all’interno del container sembra un lavoro da dilettanti:
Penso che farlo con UFW o IPTABLES. Questo rimuove e blocca le richieste prima che Discourse venga coinvolto. Ho sempre una vaga paura di pasticciare con i firewall per timore di bloccarmi, ma se prendi di mira solo la porta 443 non corri alcun pericolo.
Digital Ocean ha alcuni suggerimenti: UFW Essentials: Common Firewall Rules and Commands for Linux Security | DigitalOcean. Cercherei semplicemente esempi su Google.
Esattamente la mia paura. Ma l’ho abilitato sull’host e tuttavia non sta ancora bloccando l’intervallo di IP problematico. Apparentemente sono necessarie impostazioni complicate per applicare le regole di negazione ai container Docker.
Oh. Sì. È assolutamente vero. Ho finito per bloccare l’accesso dai miei server web basati su Docker al database postgres basato su Docker (probabilmente non uno dei tuoi problemi).
Ecco un’altra idea: Geo Blocking plugin
Grazie, ci stavo guardando anche io, ma non sembra permettere di bloccare intervalli di IP numerici, solo interi paesi?
Non l’ho installato di recente, ma sono abbastanza sicuro che lo faccia
(enfasi aggiunta)
Ma poi ho trovato questo:
Quindi penso che significhi che puoi inserire qualsiasi rete tu voglia lì.
/var/discourse/launcher enter app
apt install nano
nano /etc/nginx/conf.d/discourse.conf
E nel blocco server { aggiungi:
## 2025-10-27
deny 12.34.0.0/16;
Quindi salva ed esegui:
nginx -t
service nginx reload
Non capisco bene perché vedo ancora richieste da 12.34.x.x nel access.log di Nginx, ma sembra funzionare perché l’utilizzo della CPU è tornato alla normalità. Processo incredibilmente complicato secondo me, ma per ora è sufficiente per rimettere il sito in funzione.
Sì, ma attualmente accetta solo numeri AS e non notazione CIDR come 1.2.3.0/24.
Ha funzionato? Penso che tu debba fare
sv restart nginx
Ma se non hai ricevuto un errore, mi sbaglio.
Nginx le vede ancora? Mostra che le sta servendo? Le vedi nel production.log di Rails?
Ah. Forse avrei dovuto prestare più attenzione a quella pagina di Wikipedia sui numeri AS.
Penso che siano entrambi vecchi alias che ora sono mappati ai comandi systemd, quindi systemctl restart nginx sarebbe il più appropriato.
EDIT: Sembra che systemctl non funzioni all’interno di Docker. Ecco alcune spiegazioni sulle differenze:
Sì, nel access.log appaiono ancora come:
[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 "-" "-" "-" "-" "-" "-" "-" "
Sembra che stiano colpendo principalmente i permalink (migrati da una vecchia piattaforma di forum). C’è qualche tipo di scappatoia con i permalink che gli permette di aggirare la regola deny? Non ho ancora controllato il production.log.
Nel complesso, direi che la mancanza di un’interfaccia grafica per ispezionare i log di accesso e nessuna lista di blocco IP a livello di applicazione è una limitazione piuttosto significativa di Discourse. È un evento infrequente, ma quando vieni colpito da uno di questi attacchi di bot/scraper/crawler vuoi solo identificare immediatamente la fonte e mitigarla, senza armeggiare con un sacco di file di configurazione e comandi arcani, specialmente non a livelli profondi all’interno di un container Docker con tutte le strane astrazioni che avvengono lì. La vecchia piattaforma di forum da cui sono migrato mostrava un semplice elenco degli utenti o degli IP con il maggior numero di richieste durante una finestra temporale regolabile, e poteva anche essere filtrato per quali utenti e/o IP occupavano la maggior parte del tempo CPU. In quel modo potevo identificare rapidamente l’indirizzo o l’intervallo incriminato, e poi c’era un’interfaccia point-and-click per aggiungerlo a una lista di blocco, e avrebbe restituito un 404 per le richieste da quegli IP.
Se hai una regola deny, le cose vengono comunque registrate in nginx. E funziona correttamente, perché c’è un 403 lì, il che significa che al client è stato negato l’accesso.
Queste richieste non vengono inoltrate a Discourse. Se vuoi sapere se il tuo blocco sta funzionando correttamente, dovresti o
production.log di Discourse invece403 nel campo del codice di risposta HTTP.Questo argomento è ora risolto? C’è un post di @rgj o @pfaffman che posso scegliere come soluzione? Sembra che abbiate collaborato a questo!
Ciao, direi che questo problema non è risolvibile al momento con metodi “normali”. L’interfaccia di amministrazione per gli “IP filtrati” non fa quello che la maggior parte degli utenti si aspetterebbe, e il metodo che funziona effettivamente comporta l’intervenire all’interno del container docker di Discourse, quindi è più un hack sporco che una soluzione, almeno secondo me. Sarebbe fantastico se questo ottenesse un po’ più di attenzione: