Come bloccare get refreshed fragments con Nginx e Fail2ban

La gestione del carrello in WooCommerce può causare gravi colli di bottiglia sui server ad alto traffico. In molti casi estremi diventa indispensabile bloccare get refreshed fragments per preservare le risorse del database ed evitare crash improvvisi dell’istanza PHP-FPM.

Questo endpoint genera continue chiamate AJAX non memorizzabili in cache. Se i bot scansionano il negozio, le richieste simultanee saturano rapidamente la CPU del server.

Abbiamo già visto i concetti base nella guida su come proteggere endpoint wc-ajax. In questo approfondimento avanzato passeremo all’azione a livello sistemistico tramite Nginx e Fail2ban.

L’impatto di wc-ajax=get_refreshed_fragments sulle prestazioni

Perché WooCommerce esegue questa chiamata AJAX

WooCommerce aggiorna gli elementi del carrello tramite una chiamata asincrona standard. Lo script recupera i frammenti HTML per mostrare l’anteprima del totale e il conteggio articoli. L’operazione è utile per gli utenti autenticati, ma inutile per visitatori anonimi senza prodotti nel carrello.

Il problema del sovraccarico su PHP-FPM

Ogni richiesta verso questo endpoint bypassa la cache statica di Nginx. L’interprete PHP carica l’intero core di WordPress per ogni singolo visitatore. Centinaia di richieste al secondo causano la saturazione dei worker disponibili. Di conseguenza, il sito mostra errori 502 Bad Gateway e 504 Gateway Timeout.

I bot malevoli e gli scraper usano spesso questo endpoint per effettuare attacchi denial of service non intenzionali.

Architettura della difesa multilivello con Nginx e Fail2ban

Il ruolo del rate-limiting su Nginx

Nginx si posiziona davanti a PHP-FPM come reverse proxy. Il web server intercetta le richieste prima dell’esecuzione del codice. Grazie al modulo ngx_http_limit_req_module, possiamo limitare la frequenza delle chiamate verso parametri specifici della query string.

La mitigazione attiva affidata a Fail2ban

Nginx blocca gli eccessi momentanei restituendo un errore HTTP 429 Too Many Requests. Tuttavia, se l’attaccante insiste, continua a impegnare la banda di rete. Fail2ban legge i file di log degli accessi ed estrae gli IP recidivi. Il demone inserisce subito una regola nel firewall di sistema tramite iptables o nftables.

Configurare le regole di rate-limit su Nginx

Definizione della zona di memoria condivisa

Apri il file di configurazione principale di Nginx, solitamente posizionato in /etc/nginx/nginx.conf. Aggiungi la direttiva di memoria all’interno del blocco http:

  • limit_req_zone $binary_remote_addr zone=wc_fragments:10m rate=2r/s;
  • Imposta una dimensione di 10 megabyte per salvare circa 160.000 indirizzi IP unici.
  • Fissa una soglia conservativa di 2 richieste al secondo per singolo client.

Intercettare la query string nel Virtual Host

Nel file del blocco server del tuo e-commerce, dobbiamo isolare la chiamata specifica. WooCommerce invia l’argomento nella variabile $arg_wc-ajax. Inserisci la logica condizionale all’interno del blocco PHP:

  • Verifica la presenza del valore get_refreshed_fragments nella query string.
  • Applica la zona di limite precedentemente definita sul web server.
  • Definisci un burst ridotto per consentire solo picchi minimi legittimi.

Questa configurazione mirata permette di bloccare get refreshed fragments abusato senza compromettere il caricamento delle pagine standard del catalogo prodotti.

Integrare Fail2ban per isolare gli IP abusivi

Creazione del filtro personalizzato per i log

Crea un nuovo file filtro in /etc/fail2ban/filter.d/nginx-wc-fragments.conf. Il filtro deve rintracciare le risposte 429 generate dalle regole di Nginx:

  • Imposta failregex = ^<HOST> -.*"GET /.*wc-ajax=get_refreshed_fragments.*" 429
  • Salva il file e verifica la sintassi con il comando fail2ban-regex.

Configurazione della jail di sistema

Modifica ora il file /etc/fail2ban/jail.local aggiungendo la configurazione della protezione. Definisci una finestra temporale e la durata del bando:

  • Imposta enabled = true e specifica la porta http,https.
  • Configura maxretry = 5 e un tempo di osservazione findtime = 60.
  • Assegna un periodo di esclusione lungo impostando bantime = 3600.

Adesso il server possiede gli strumenti per bloccare get refreshed fragments quando le richieste eccedono i parametri di sicurezza stabiliti.

Procedura passo-passo per il collaudo e il riavvio

Test preliminare della sintassi e applicazione

Prima di rendere attive le modifiche, esegui sempre un controllo formale dei file di testo. Gli errori di sintassi interrompono il funzionamento dell’intero server web:

  1. Esegui il comando nginx -t nel terminale per validare le regole.
  2. Se il risultato è positivo, ricarica Nginx con systemctl reload nginx.
  3. Riavvia il servizio di sicurezza con systemctl restart fail2ban.
  4. Controlla lo stato della jail con fail2ban-client status nginx-wc-fragments.

Verifica del funzionamento con cURL

Simula chiamate rapide consecutive per confermare la corretta attivazione del blocco. Invia una sequenza rapida di richieste con il seguente comando da una macchina remota:

  • Esegui un ciclo for con dieci iterazioni verso il tuo endpoint di WooCommerce.
  • Verifica che le prime due richieste restituiscano codice HTTP 200.
  • Verifica che le chiamate successive ricevano il codice HTTP 429 da Nginx.
  • Verifica che dopo cinque tentativi falliti l’indirizzo IP venga isolato dal firewall.

Implementando questa procedura a doppio livello, potrai bloccare get refreshed fragments da scraper ostinati proteggendo l’uptime del negozio.

Domande frequenti sulla protezione dell’endpoint AJAX

Il blocco tramite Nginx danneggia l’esperienza degli acquirenti reali?

No, perché un cliente umano non genera più di due aggiornamenti del carrello al secondo. La soglia impostata protegge l’infrastruttura lasciando fluida la navigazione per i visitatori ordinari.

Cosa succede se il negozio si trova dietro Cloudflare o un proxy inverso?

Se utilizzi un proxy inverso, devi istruire Nginx a leggere l’intestazione corretta. Utilizza il modulo ngx_http_realip_module per ripristinare il reale indirizzo IP dell’utente prima di applicare i limiti.

È possibile disattivare completamente questo script in WooCommerce?

Sì, puoi rimuovere lo script registrato se il tuo tema non utilizza carrelli laterali o popup dinamici. Tuttavia, se il negozio necessita di tale funzionalità, il rate-limiting rappresenta la soluzione migliore per bloccare get refreshed fragments dalle scansioni dannose senza perdere vendite.

Articoli simili