Come fermare la forza bruta e i bot su WooCommerce senza Wordfence

La settimana scorsa mi ha scritto un conoscente, il proprietario di un negozio online di ricambi per auto su WooCommerce. Scrive: "Oleg, il mio sito è lento, l'hosting si lamenta del carico, ma non ho cambiato nulla". Entro per guardare e vedere un dipinto classico. Nelle ultime 24 ore, sessantamila richieste a wp-login.php sono state stipate in access.log. Sessantamila. Da duecento indirizzi IP diversi. Qualcuno prova metodicamente le password - admin, amministratore, negozio, manager, test, 123456 - in cerchio, senza fermarsi. I bot funzionano come un orologio svizzero: da tre a quattro richieste al secondo, quanto basta per non cadere sotto la primitiva protezione del limite di velocità dell’hosting, ma abbastanza per far sì che il server soffochi l’elaborazione delle richieste PHP.

Il mio primo consiglio istintivo è stato “installa Wordfence”. È un riflesso, vero? La sicurezza di WordPress significa Wordfence. L'ho pensato anch'io per anni. Ma poi mi sono fermato e mi sono posto una domanda che avrebbe dovuto essere posta molto tempo fa: Wordfence è davvero l’unico modo per proteggersi dalla forza bruta? Ed è davvero il modo migliore per un negozio WooCommerce con i suoi carichi di lavoro e requisiti specifici? Onestamente, più scavavo a fondo, più mi convincevo che per i siti commerciali su WooCommerce, Wordfence è come sparare ai passeri da un cannone. Sì, lo farai. Ma allo stesso tempo distruggerai metà del muro.

Lascia che ti dica a cosa sono arrivato dopo diversi anni di lotta con bot e forza bruta su progetti WooCommerce reali - e perché a un certo punto ho abbandonato pesanti plugin di sicurezza universali a favore di soluzioni integrate basate su punti. Questo non è un confronto teorico tra i "top ten dei plugin di sicurezza": si tratta dell'esperienza con negozi industriali che hanno sedicimila prodotti, duemila visitatori al giorno e tolleranza zero per i tempi di inattività.

Perché Wordfence non è più la mia scelta predefinita

Non dirò che Wordfence sia un cattivo prodotto. Non sarebbe giusto. Wordfence è uno strumento potente, maturo e ben supportato con un enorme database di firme. Il problema è diverso: è stato pensato come soluzione universale per qualsiasi sito WordPress, dal blog di una casalinga al portale aziendale. E WooCommerce non è “qualsiasi sito”. Questo è un negozio con pagine dinamiche, un carrello AJAX, checkout, richieste API dai sistemi di pagamento, webhook dai servizi di consegna e sincronizzazione con 1C. E quando in mezzo a tutto questo c'è un plugin di oltre cento megabyte che, ad ogni richiesta, la confronta con un database di diversi milioni di firme, inizia il divertimento.

L'ho riscontrato per la prima volta su un progetto per un cliente che vende lubrificanti industriali. Ha un negozio su WooCommerce, sedicimila posizioni, sincronizzazione con 1C: Trade Management tramite OData, ricerca su Typesense, mega menù con navigazione a tre livelli, pricing B2B con gruppi di clienti. Negozio normalmente funzionante. Wordfence Premium costava centodiciannove dollari all'anno, tutto era come doveva essere. E poi un giorno abbiamo notato che le pagine del catalogo hanno iniziato a caricarsi un secondo e mezzo in più dopo l'aggiornamento di Wordfence. Un secondo e mezzo è un'eternità per un negozio online. Abbiamo iniziato a scavare e abbiamo scoperto che Wordfence è in conflitto con LiteSpeed ​​​​Cache. Entrambi i plugin cercano di controllare le intestazioni HTTP, entrambi vengono coinvolti nell'elaborazione delle richieste in una fase iniziale e, di conseguenza, la memorizzazione nella cache a volte funziona. Alcune pagine vengono servite dalla cache, altre no e l'utente vede un sito veloce o lento. L’incoerenza è la cosa peggiore che possa accadere nell’e-commerce.

Abbiamo impiegato due giorni per impostare le eccezioni. Aggiunti pattern URL per checkout, carrello, endpoint API, gestori AJAX per WooCommerce. Sembra che abbia funzionato. Un mese dopo, Wordfence è stato aggiornato e alcune eccezioni hanno smesso di funzionare perché il formato di configurazione era leggermente cambiato. Stiamo perdendo tempo ancora una volta. E ad un certo punto ho pensato: aspetta, cosa fa esattamente per noi Wordfence che non possiamo ottenere più facilmente?

Si è scoperto che dell'intero vasto arsenale di Wordfence, in realtà abbiamo utilizzato quattro funzioni: protezione dalla forza bruta, blocco di IP sospetti, CAPTCHA sui moduli e monitoraggio dei file. È utile un firewall con le sue regole WAF. Ma il nostro hosting ha già ModSecurity con il set di regole OWASP. Scanner malware: viene eseguito una volta al mese, non ha mai trovato nulla (perché non installiamo plugin e temi sbagliati). Autenticazione a due fattori: configurata solo per l'amministratore. Si scopre che paghiamo centodiciannove dollari all'anno e soffriamo di conflitti di memorizzazione nella cache per il bene di funzionalità che possono essere implementate molto più facilmente.

Sapete cosa alla fine mi ha convinto? Ho guardato la dimensione del plugin. Wordfence con il suo database delle firme, firewall, scanner e pannello di amministrazione supera i cento megabyte. Cento megabyte di codice PHP, che in qualche modo viene caricato con ogni richiesta al sito. Per fare un confronto, l'intero WooCommerce è di circa quaranta megabyte. Cioè, un plugin di sicurezza è più grande della piattaforma che protegge. Questo è tollerabile per un blog. Per un negozio con migliaia di sessioni simultanee, no.

E un altro punto che viene raramente discusso. Wordfence memorizza registri, statistiche, dati di scansione e tabelle firewall nel database WordPress. Nello stesso database di cui il negozio WooCommerce è già sovraccarico, wp_postmeta sul nostro progetto pesa 937 megabyte. Aggiungere molte altre tabelle con milioni di righe da Wordfence a questo significa aggravare la situazione già non banale con le prestazioni di MySQL.

Non sto dicendo che tutti dovrebbero disinstallare immediatamente Wordfence. Questa è un'ottima scelta per molti siti. Ma se hai un negozio WooCommerce con un carico elevato, caching a livello di server e integrazioni specifiche, vale la pena considerare se esiste un modo per ottenere la protezione necessaria senza questo peso massimo. Spoiler: sì. E ora ti dirò come abbiamo fatto.

Anatomia di un attacco: cosa fanno esattamente i bot e cosa vogliono

Prima di difenderci, vale la pena capire da cosa esattamente ci stiamo difendendo. Ho notato che molti proprietari di negozi percepiscono un "attacco al sito" come qualcosa uscito da un film di Hollywood: un hacker incappucciato che picchietta furiosamente sulla tastiera, caratteri verdi che corrono sullo schermo. In realtà, il 90% degli attacchi ai siti WordPress/WooCommerce sono processi completamente automatizzati. Bot. Script. Non c'è nessuna persona dietro lo schermo. Esiste una botnet composta da diverse migliaia di server e dispositivi IoT compromessi che esegue metodicamente la scansione di milioni di siti WordPress e tenta accessi standard con password da database trapelati.

L'obiettivo principale è ottenere l'accesso all'area di amministrazione. Non rubare i tuoi prodotti o la tua base clienti (anche se ciò accade). Molto spesso, WordPress compromesso viene utilizzato come collegamento intermedio: ospitano pagine di phishing, inviano spam tramite posta elettronica, installano minatori di criptovaluta e reindirizzano i visitatori a siti di terze parti. Per un negozio WooCommerce le conseguenze sono catastrofiche: Google segnala il sito come pericoloso nel giro di poche ore, i clienti vedono una schermata di avviso rossa nel browser, le vendite scendono a zero. Ripristinare la reputazione del tuo motore di ricerca può richiedere settimane.

Il vettore di attacco numero uno è la forza bruta tramite wp-login.php. La pagina di accesso standard di WordPress, accessibile a tutti per impostazione predefinita. Il bot invia una richiesta POST con una coppia login-password, riceve una risposta e invia la richiesta successiva. Con una velocità compresa tra tre e cinque richieste al secondo, il bot può selezionare decine di migliaia di combinazioni in un giorno. Se la tua password è “shop2024”, la domanda non è se verrai hackerato, ma quando. Inoltre, anche se il bot non indovina la password, provoca comunque dei danni: ogni richiesta a wp-login.php è una vera e propria sessione PHP con connessione al database, verifica delle credenziali e registrazione nel log. Sessantamila richieste di questo tipo al giorno sono un carico serio anche per un buon server.

Il vettore numero due è XML-RPC. Si tratta di un protocollo remoto WordPress che è stato inventato ai tempi in cui le persone pubblicavano post sui blog tramite applicazioni desktop. Nel 2026, circa lo zero per cento dei proprietari di negozi WooCommerce utilizza XML-RPC. Ma viene utilizzato attivamente dai bot, perché tramite XML-RPC è possibile inviare il metodo system.multicall con centinaia di coppie login-password in un'unica richiesta. Cioè, invece di bussare alla porta cento volte, il bot bussa una volta e consegna cento chiavi contemporaneamente. Molti plugin di sicurezza limitano i tentativi di accesso tramite wp-login.php, ma dimenticano XML-RPC e i bot passano semplicemente a questo canale.

Vettore numero tre: moduli di registrazione e pagamento. Su un negozio WooCommerce, a differenza di un normale blog, ci sono moduli aperti a disposizione degli utenti non autorizzati: registrazione di un account, effettuazione di un ordine, modulo di feedback e talvolta richiesta di un'offerta commerciale. I bot utilizzano questi moduli per due scopi: registrazione dello spam (creando migliaia di account falsi) e verificando la validità degli indirizzi e-mail dai database trapelati. Il modulo di pagamento è particolarmente vulnerabile perché attraverso di esso è possibile controllare le carte bancarie rubate in piccole transazioni: il cosiddetto test delle carte. PayPal, Stripe e YooKassa combattono tutti questo problema, ma se non hai un CAPTCHA al momento del pagamento, stai essenzialmente offrendo ai robot uno strumento gratuito di verifica della carta.

La comprensione di questi tre vettori determina la strategia di difesa. Non abbiamo bisogno di un firewall universale con milioni di regole. Dobbiamo chiudere tre porte specifiche e chiuderle in modo sicuro.

Protezione dalla forza bruta: blocco intelligente invece della forza bruta

Quando ho iniziato a progettare un modulo di protezione dalla forza bruta, la prima cosa che ho fatto è stata guardare come lo fa Wordfence. E sai cosa ho capito? L'approccio è in realtà semplice. Conti il ​​numero di tentativi di accesso non riusciti da un indirizzo IP in un determinato periodo. Se superi il limite, blocchi l'IP per un po'. Questa non è scienza missilistica. Ma il diavolo, come sempre, sta nei dettagli, e sono proprio i dettagli che distinguono una buona implementazione da una cattiva.

Il primo dettaglio è il bloccaggio progressivo. L'implementazione ingenua di "cinque tentativi - blocco per quindici minuti" non funziona contro le botnet serie. Il bot attende semplicemente quindici minuti e ricomincia. Oppure passa a un altro IP. Abbiamo implementato il blocco esponenziale: la prima serie di tentativi falliti - blocco per quindici minuti, la seconda - per un'ora, la terza - per quattro ore, la quarta - per un giorno. Un IP che tenta costantemente di indovinare una password dopo diversi cicli finisce per essere bloccato per ventiquattr'ore. Durante questo periodo, la botnet di solito passa ad altri obiettivi.

Il secondo dettaglio è contare i tentativi non solo per IP, ma anche per nome utente. Se qualcuno prova le password per l'account amministratore da mille indirizzi IP diversi, si tratta comunque di un attacco, anche se c'è stata una sola richiesta da ciascun IP. Contiamo separatamente: tentativi dallo stesso IP e tentativi allo stesso accesso. Il superamento di uno qualsiasi dei limiti attiverà il blocco. Per IP, l'indirizzo è bloccato. Per un login, la possibilità di accedere con questo nome è bloccata per un certo periodo, indipendentemente dall'IP.

Il terzo dettaglio riguarda le notifiche istantanee. Quando viene attivato il blocco, l'amministratore riceve un'e-mail. Non tra un'ora, non nel riassunto quotidiano, subito. La lettera indica l'IP bloccato, il Paese, il numero di tentativi e il login che hanno tentato di trovare. Questo è importante non solo per reagire, ma anche per comprendere i modelli. Quando vedi che per una settimana ci sono stati tentativi di accedere con il login "manager" da indirizzi IP da un blocco, capisci che qualcuno sta attaccando intenzionalmente il tuo sito e non conducendo una scansione di massa. E poi prendi altre misure.

Il quarto dettaglio è la whitelist. Se hai un IP fisso in ufficio, devi aggiungerlo alla lista bianca per non bloccarti accidentalmente. Sembra ovvio, ma conosco due casi in cui l'amministratore di un negozio ha bloccato il proprio IP con tentativi di accesso non riusciti (ha dimenticato la password, ha provato cinque volte) e quindi non è riuscito ad accedere all'area di amministrazione. Ciò non accadrà con una lista bianca. Abbiamo anche aggiunto il rilevamento automatico dell'indirizzo IP dell'amministratore durante la prima configurazione, in modo che non dimentichi di aggiungersi manualmente.

Tutto questo funziona a livello PHP, senza dipendenze esterne, senza chiamate ad API cloud, senza database di firme gigabyte. I dati sui tentativi di accesso vengono archiviati nella tabella del registro delle attività, già necessaria per il controllo. Nessun carico aggiuntivo del database: una riga scritta per ogni tentativo di accesso. Rispetto a Wordfence, che confronta l'IP con la base della reputazione del cloud con ogni richiesta (che è una richiesta DNS o una richiesta HTTP alla propria API), la differenza di prestazioni è significativa.

Ho pensato a lungo di aggiungere l'integrazione con database di reputazione IP esterni, come fa Wordfence con il suo Threat Intelligence Feed. Ho deciso di no. In pratica, il 95% degli attacchi viene fermato già nella fase di limitazione dei tentativi di accesso. Il restante 5% sono attacchi mirati, dai quali il database della reputazione IP non vi salverà comunque, perché l'aggressore utilizza proxy puri che non si trovano in nessun database. Inoltre, il costo per l'integrazione con un servizio esterno è la dipendenza da un'API di terze parti, una latenza aggiuntiva su ciascuna richiesta e potenziali problemi se l'API non è disponibile.

URL nascosti e CAPTCHA: due semplici trucchi che risolvono l'ottanta per cento dei problemi

Conosci il modo più semplice per fermare gli attacchi automatizzati su wp-login.php? Rimuovere wp-login.php. Più precisamente, non rimuoverlo, ma nasconderlo dietro un altro URL. Invece dello standard example.com/wp-login.php, la tua pagina di accesso sarà accessibile, ad esempio, su example.com/my-secret-door. E quando accede a wp-login.php, il bot riceverà un 404. Questa è una tecnica così semplice che molte persone la sottovalutano. Ma invano.

Il fatto è che la stragrande maggioranza dei bot che attaccano WordPress sono stupidi script codificati per accedere a wp-login.php e xmlrpc.php. Non analizzano la tua pagina alla ricerca di un modulo di accesso, non analizzano JavaScript e non cercano il collegamento “Accedi” nel menu. Inviano semplicemente una richiesta POST a wp-login.php e il gioco è fatto. Se viene restituito un 404 a questo indirizzo, il bot si sposta al sito successivo dall'elenco. Questo è tutto, l'attacco è finito prima ancora di iniziare.

Abbiamo implementato l'URL di accesso personalizzato in modo abbastanza elegante. Quando la funzione è attivata, l'amministratore imposta il proprio slug, ad esempio accademico, ingresso, mio ​​login, qualunque cosa. Il plugin intercetta tutte le richieste a wp-login.php e wp-admin (per utenti non autorizzati) e restituisce 404. Allo stesso tempo, tutti i collegamenti interni di WordPress - il pulsante "Esci", collegamenti in lettere sulla modifica della password, reindirizzamento dopo la scadenza della sessione - vengono automaticamente riscritti nel nuovo URL. L'utente non si accorge di nulla, per lui tutto funziona come prima, solo l'indirizzo di login è diverso.

Nel nostro progetto di combattimento - un negozio di oli industriali - abbiamo abilitato un URL di accesso personalizzato e in 24 ore abbiamo visto che il numero di richieste a wp-login.php è sceso da sessantamila a zero. Letteralmente a zero. I bot hanno continuato a bussare a wp-login.php, hanno ricevuto un 404 e se ne sono andati. Il carico sul server è diminuito notevolmente: lo stesso ritardo di un secondo e mezzo osservato in precedenza è scomparso. E questo senza una sola regola del firewall, senza un database delle firme, senza un servizio cloud.

Ma un URL nascosto è una difesa contro i bot automatizzati. Che dire degli attacchi semiautomatici in cui una persona trova la tua pagina di accesso e lancia un attacco di forza bruta mirato? O con registrazioni spam tramite modulo WooCommerce? O con il test della carta tramite checkout? È qui che entra in gioco il CAPTCHA.

Supportiamo tre opzioni: Google reCAPTCHA v2 (classico "Non sono un robot" con immagini), Google reCAPTCHA v3 (invisibile, valuta il comportamento dell'utente) e hCaptcha (alternativa a Cloudflare, senza dipendenza da Google). Ogni opzione ha i suoi punti di forza e di debolezza e la scelta dipende dalle specificità del negozio.

reCAPTCHA v2 è il più affidabile in termini di blocco dei bot. Se il bot non può fare clic sulle immagini con gli autobus, non passerà. Lo svantaggio è che infastidisce gli utenti live. Durante il checkout del negozio WooCommerce, questo potrebbe costarti una conversione. L’acquirente ha già inserito l’indirizzo di consegna, scelto il metodo di pagamento e poi gli vengono mostrate dieci fotografie sfocate con la domanda “seleziona tutte le immagini con idranti”. Alcuni decideranno che il sito non funziona, altri semplicemente si rivolgeranno alla concorrenza.

reCAPTCHA v3 risolve questo problema: è invisibile. L'utente non fa clic su nulla, non risolve alcuna immagine. Google analizza il comportamento degli utenti sulla pagina - movimenti del mouse, velocità di compilazione dei moduli, cronologia del browser - e assegna un punteggio da zero a uno. Superiore a 0,5: molto probabilmente una persona. Di seguito è molto probabilmente un bot. Ti consentiamo di personalizzare la soglia del punteggio nel pannello di amministrazione perché moduli diversi richiedono livelli di gravità diversi. Per accedere al pannello di amministrazione, puoi impostare la soglia su 0,7: è meglio andare sul sicuro. Per il checkout - 0.3, per non perdere acquirenti legittimi con comportamenti non standard (ad esempio, coloro che compilano un modulo utilizzando la tastiera senza mouse).

hCaptcha è un'alternativa interessante per coloro che fondamentalmente non vogliono fornire i dati degli utenti a Google. Funziona in modo simile, ma i dati vengono elaborati da Cloudflare. Per i clienti europei con requisiti GDPR, questo potrebbe essere di fondamentale importanza.

Il punto chiave è dove posizionare esattamente il CAPTCHA. Molti plugin di sicurezza lo installano solo su wp-login.php e considerano l'attività completata. Ma ci sono altre tre forme critiche in un negozio WooCommerce che spesso vengono dimenticate. Modulo di registrazione: attraverso di esso i bot creano migliaia di account falsi. Modulo di recupero password - tramite esso è possibile verificare se esiste una determinata email nel database (il modulo risponde in modo diverso per indirizzi esistenti e inesistenti). E la forma di pagamento è il test delle carte, di cui ho già parlato. Inseriamo i CAPTCHA in tutti e quattro i punti: login, registrazione, recupero password, checkout. È configurato separatamente per ciascun modulo: puoi abilitare v3 al momento del pagamento (invisibile) e v2 all'input (esplicito).

È qui che voglio sottolineare un punto importante. Il CAPTCHA non è una soluzione miracolosa. Le botnet avanzate possono aggirare reCAPTCHA v2 utilizzando servizi come 2Captcha o Anti-Captcha, dove persone reali fanno clic sulle immagini per pochi centesimi. reCAPTCHA v3 può essere ingannato emulando il comportamento umano in un browser headless. Ma tutto ciò richiede sforzi e risorse significativi da parte dell’aggressore. Un enorme bot che esegue la scansione di milioni di siti non spenderà un centesimo sul tuo CAPTCHA: passerà semplicemente al sito successivo senza protezione. Ma un attacco mirato rappresenta un livello di minaccia completamente diverso ed è necessario proteggersi con altri mezzi. Il CAPTCHA in questo caso è la prima riga che elimina il novantanove per cento della spazzatura automatizzata.

Queste due tecniche insieme - URL di accesso nascosto e CAPTCHA sui moduli - risolvono la stragrande maggioranza dei problemi con i bot su un negozio WooCommerce. Senza una sola riga di configurazione del firewall, senza abbonamenti al cloud, senza un plugin da cento megabyte. Solo protezione pura e mirata su specifici punti vulnerabili.

XML-RPC: il buco più sottovalutato di WordPress

Ricordo il momento in cui ho saputo dell'attacco di amplificazione XML-RPC. Questo è successo circa cinque anni fa e sono rimasto sinceramente sorpreso: come è possibile questo nel mondo moderno? XML-RPC è un protocollo WordPress legacy che ti consente di gestire in remoto il tuo sito tramite richieste XML. Pubblicare post, gestire commenti, caricare file: tutto questo può essere fatto tramite xmlrpc.php. Il problema è che questo file supporta il metodo system.multicall, che consente di combinare più chiamate in un'unica richiesta. E gli aggressori hanno capito rapidamente come usarlo.

Invece di inviare mille richieste separate con password diverse (che è facile da tracciare e bloccare), il bot invia una richiesta con il metodo system.multicall, all'interno del quale ci sono mille chiamate a wp.getUsersBlogs, ciascuna con una coppia login-password univoca. WordPress elabora onestamente tutte le migliaia di chiamate e restituisce il risultato. Una richiesta HTTP significa mille controlli della password. Nessun contatore di tentativi di accesso su wp-login.php lo vedrà, perché l'attacco arriva attraverso un canale completamente diverso.

Ma la forza bruta non è poi così male. XML-RPC viene utilizzato anche per un altro tipo di attacco: l'amplificazione DDoS. Il bot invia una richiesta di pingback XML-RPC al tuo sito con l'indirizzo di ritorno di una vittima falsa. Il tuo WordPress invia onestamente una richiesta di pingback all’indirizzo della vittima. Se un bot lo fa simultaneamente da migliaia di siti WordPress compromessi, la vittima riceve un attacco DDoS e il tuo sito diventa un membro inconsapevole della botnet. Bella prospettiva, vero? Il tuo dominio viene inserito nella lista nera, il tuo hosting riceve denunce di abuso e non sai nemmeno cosa sta succedendo finché un hoster arrabbiato non ti scrive.

Soluzione? Disabilita completamente XML-RPC. Nel 2026, nessun negozio WooCommerce avrà bisogno di questo protocollo. L'API REST di WordPress ha sostituito da tempo tutte le funzioni XML-RPC e lo fa in modo più sicuro, veloce e con la normale autenticazione. Applicazione mobile WordPress? Funziona tramite API REST dalla versione 5.0. Jetpack? Sono passato a REST molto tempo fa. Pubblicare tramite app di terze parti? API REST. Non esiste alcun motivo legittimo per mantenere aperto xmlrpc.php.

Disabilitiamo XML-RPC a due livelli. A livello di WordPress, tramite il filtro xmlrpc_enabled, che restituisce false. Ciò disabilita l'elaborazione delle richieste XML-RPC all'interno di WordPress. E a livello HTTP, intercettiamo le richieste a xmlrpc.php e restituiamo 403 prima ancora che WordPress inizi a elaborarle. Il secondo livello è importante perché anche dopo essere stato disabilitato dal filtro, il file xmlrpc.php rimane accessibile e può gestire alcune richieste prima che il filtro venga attivato. La doppia protezione è più affidabile.

Dopo aver disabilitato XML-RPC su un progetto di produzione, ho esaminato i log e ho visto che il numero di richieste bloccate a xmlrpc.php era in media da tre a cinquemila al giorno. Dalle tre alle cinquemila richieste che prima venivano gestite interamente da WordPress (analisi XML, connessione al database, verifica delle credenziali) vengono ora interrotte in una fase molto precoce con un consumo minimo di risorse. Non è solo sicurezza: è ottimizzazione delle prestazioni.

Gestione IP: quando serve l'artiglieria pesante

URL nascosti, CAPTCHA e disabilitazione di XML-RPC sono tre tappe fondamentali che risolvono il novanta per cento dei problemi dei bot. Ma a volte è necessario agire in modo più duro. A volte nei registri vedi che da un certo intervallo di indirizzi IP non ci sono solo tentativi di accesso, ma una scansione sistematica delle vulnerabilità: richieste a wp-config.php.bak, .env, .git/HEAD, debug.log. Oppure vedi che una particolare sottorete sta generando traffico anomalo verso le pagine del catalogo: non bot che tentano di accedere, ma scraper che copiano il catalogo dei prodotti con i prezzi. In questi casi è necessaria la gestione IP.

L'abbiamo implementato sotto forma di due elenchi: bianco e nero. La blacklist blocca completamente indirizzi IP o intere sottoreti (in formato CIDR): il server restituisce 403 a qualsiasi richiesta. La lista bianca, al contrario, esenta gli indirizzi specificati da qualsiasi controllo: nessuna restrizione sui tentativi di accesso, nessun CAPTCHA, nessun ritardo. La lista bianca contiene solitamente indirizzi IP dell'ufficio, connessioni domestiche degli amministratori e indirizzi di servizi affidabili (server 1C, sistemi di pagamento, servizi di consegna).

Ma mantenere manualmente una lista nera è un compito di Sisifo. Oggi bloccherai dieci indirizzi, domani l'attacco arriverà da un'altra botnet e ne dovrai bloccare altri venti. Ecco perché abbiamo aggiunto il blocco automatico basato su modelli di comportamento. Se un indirizzo IP genera più di un certo numero di richieste 404 in un'ora (il che indica una scansione di vulnerabilità), viene automaticamente inserito nella lista nera. Se l'IP supera per tre volte il limite dei tentativi di accesso, si verifica il blocco automatico. Se le richieste provengono dall'IP contenente linee di payload tipiche di SQL injection o XSS, blocco immediato. Tutto questo può essere configurato, le soglie possono essere modificate, perché il comportamento normale appare diverso per i diversi negozi.

Qui voglio avvisarvi di una trappola in cui io stesso ho camminato. Il blocco IP automatico può bloccare gli utenti legittimi che si trovano dietro un NAT o un proxy aziendale. In una grande azienda, centinaia di dipendenti possono accedere a Internet tramite un unico indirizzo IP. Se uno di loro tenta più volte di entrare nel tuo negozio senza successo, l'intero ufficio verrà bloccato. Pertanto il blocco automatico va configurato con attenzione: soglie elevate, tempo di blocco breve alla prima operazione, notifiche obbligatorie all'amministratore. E una whitelist per gli indirizzi IP dei grandi client, se li conosci.

Un argomento a parte è il blocco geografico. Se il tuo negozio opera solo in Russia e nella CSI, ha senso accettare traffico dall'Indonesia, dalla Nigeria o dal Brasile? Le statistiche mostrano che una parte significativa delle botnet ha sede in paesi del sud-est asiatico, dell’Africa e del Sud America. Bloccare interi paesi è uno strumento rozzo ma efficace. Supportiamo il blocco per paese in base al database MaxMind GeoIP. Puoi bloccare paesi specifici oppure puoi invertirlo: consentire solo determinati paesi e bloccare tutti gli altri. Per un negozio B2B che lavora esclusivamente con persone giuridiche russe, l’opzione “consenti solo Russia e Bielorussia” elimina un’enorme quantità di traffico spazzatura.

Ma devo essere onesto: il geoblocco non riguarda la sicurezza nella sua forma più pura. È più una questione di igiene. Un utente malintenzionato serio affitterà un VPS nel paese desiderato per cinque dollari e aggirerà il tuo blocco geografico in un minuto. Il blocco geografico è utile contro botnet di grandi dimensioni che non si adattano a un sito specifico. E questi sono la maggioranza.

Registro attività: sapere tutto ciò che accade sul sito

C'è una cosa che ritengo ancora più importante di tutti i meccanismi di protezione sopra elencati. Questo è il registro delle attività. Una traccia di controllo completa di tutto ciò che accade sul sito. Chi ha effettuato l'accesso, quando, da quale IP. Chi ha cambiato le impostazioni. Chi ha aggiornato il plugin? Chi ha modificato il prodotto. Chi ha cambiato il prezzo? Chi ha eliminato l'utente.

Perché è così importante? Perché la sicurezza non significa solo prevenire gli attacchi. È anche scoperta. E un'indagine. Se vieni comunque hackerato (e non esiste una protezione al 100%), il registro delle attività ti permette di capire: esattamente quando è avvenuta la penetrazione, attraverso quale vettore, cosa è riuscito a fare l'aggressore, quali dati sono stati compromessi. Senza un registro, agirai alla cieca: cambia tutte le password, reinstalla tutti i plugin, controlla tutti i file. Con un registro: correggi in modo specifico ciò che è stato interessato.

Ti racconto un esempio reale tratto dalla pratica. In un progetto, abbiamo scoperto che qualcuno aveva cambiato l'e-mail del destinatario dell'ordine nelle impostazioni di WooCommerce. Gli ordini continuavano ad arrivare sul sito, ma le notifiche venivano inviate a un'e-mail di terze parti: qualcuno ha letteralmente intercettato gli ordini con le informazioni di contatto del cliente. Senza il registro delle attività, forse non avremmo notato il problema per mesi. Con un registro: abbiamo visto una registrazione della modifica delle impostazioni, dell'ora, dell'indirizzo IP e persino dello user-agent del browser da cui è stata effettuata. Si è scoperto che uno dei dipendenti utilizzava una password debole, il suo account era stato compromesso e le impostazioni erano state modificate tramite lui. Abbiamo reimpostato la password, abilitato l'autenticazione a due fattori, restituito l'e-mail corretta e tutto ciò ha richiesto un'ora, non una settimana.

Il nostro modulo di registro delle attività registra gli eventi in tabelle personalizzate separate: wpaic_activity_log e wpaic_activity_log_contexts. Tabelle separate, non wp_options o wp_postmeta, che sono già sovraccariche. Ogni voce contiene un tipo di azione, un oggetto azione (post, prodotto, utente, impostazione), valore vecchio e nuovo, indirizzo IP, agente utente e timestamp. Tutte le azioni critiche vengono registrate: accessi e disconnessioni, modifiche di utenti e ruoli, aggiornamenti di plugin e temi, modifiche alle impostazioni di WooCommerce, modifiche a prodotti e prezzi, azioni di ordine, modifiche ai file.

Un dettaglio importante è la memorizzazione dei log. Se registri tutto per sempre, la tabella raggiungerà dimensioni oscene. Archiviamo i log per un periodo configurabile: novanta giorni per impostazione predefinita. Le voci più vecchie di questo periodo vengono automaticamente eliminate tramite Action Scheduler. Può essere aumentato a un anno o ridotto a trenta giorni, a seconda dei requisiti di audit. Per le aziende che lavorano con dati personali (e questo è qualsiasi negozio online), novanta giorni rappresentano un equilibrio ragionevole tra requisiti di sicurezza e risparmio di risorse.

E un altro punto che voglio sottolineare. Il registro delle attività non riguarda solo la sicurezza. Riguarda anche la gestione. Quando hai diversi manager che lavorano con un negozio, vuoi sapere chi ha cambiato cosa. Il manager ha ripristinato accidentalmente il prezzo di un prodotto popolare? Visibile nel registro. Il tuo stagista ha eliminato una pagina importante? Visibile nel registro. L'appaltatore ha aggiornato il plugin che ha interrotto il pagamento? Visibile nel registro. Questo non è uno strumento per la paranoia, ma per la normale gestione dei processi aziendali.

Quando mostro ai proprietari dei negozi il registro delle attività del primo giorno dopo l'accensione, la reazione è solitamente la stessa: "Non sapevo che stessero accadendo così tante cose sul sito". Ed è vero: la maggior parte delle persone non si rende nemmeno conto di quanti processi automatizzati WordPress e WooCommerce vengono eseguiti in background. Aggiornamenti temporanei, attività cron, Action Scheduler, webhook: tutto ciò genera eventi che rimangono invisibili senza un registro.

Tutto senza plugin separato: perché la protezione integrata è migliore

Ora parliamo di cosa hanno in comune tutti questi meccanismi e cosa rende questo approccio fondamentalmente diverso dall'installazione di Wordfence. Tutte queste funzioni - protezione dalla forza bruta, URL nascosto, CAPTCHA, disabilitazione XML-RPC, gestione IP, blocco geografico, registro attività - sono implementate come moduli di un plug-in, che gestisce contemporaneamente il catalogo, i prezzi B2B, la ricerca, la consegna e la sincronizzazione con 1C. Questo non è “un altro plugin di sicurezza sopra dieci altri”. Questa è una protezione integrata che sa tutto del tuo negozio.

Perché è importante? Perché i moduli dello stesso plugin non sono in conflitto tra loro. Il modulo di sicurezza conosce il modulo di memorizzazione nella cache CSS e non interferisce con il suo lavoro. Il modulo CAPTCHA riconosce i moduli di richiesta di preventivo e aggiunge automaticamente la verifica. Il modulo di registro delle attività conosce le azioni del modulo B2B e registra le modifiche nei gruppi di clienti, nelle fasce di prezzo e negli account secondari. Si tratta di un unico ecosistema e non di un insieme di strumenti disparati che devono essere configurati separatamente e sperare che non siano in conflitto.

Il secondo vantaggio sono le dimensioni e le prestazioni. Il modulo di sicurezza è composto da diverse classi PHP con un volume totale di circa cento kilobyte. Non un megabyte, un kilobyte. Non porta con sé un database di firme delle dimensioni di un'enciclopedia, non esegue la scansione del file system ad ogni richiesta e non invia dati al cloud. Fa esattamente quello che deve fare e non un grammo di più. In un negozio WooCommerce con LiteSpeed ​​Cache, Redis e Typesense, ogni megabyte e ogni millisecondo contano. Un modulo di sicurezza che aggiunge uno o due millisecondi all'elaborazione della richiesta è una storia completamente diversa da Wordfence con i suoi venti-trenta millisecondi.

Il terzo vantaggio è il costo. Wordfence Premium costa centodiciannove dollari all'anno per un sito. Sucuri Firewall: duecento dollari. iThemes Security Pro: circa cento dollari. Se hai più negozi, moltiplica. La protezione integrata è già inclusa nel prezzo del plugin che già utilizzi per gestire il tuo negozio. Nessun abbonamento aggiuntivo, nessuna licenza separata.

Il quarto plus è un singolo punto di configurazione. Invece di saltare tra l'amministratore di Wordfence, il pannello Cloudflare, le impostazioni .htaccess e la configurazione del server, configuri tutto in un unico posto. La scheda “Sicurezza” nel già familiare pannello di amministrazione del plugin. Protezione dalla forza bruta, CAPTCHA, URL personalizzato, XML-RPC, elenchi IP, registro attività: tutto sotto lo stesso tetto, con un unico stile di interfaccia e documentazione uniforme.

Sento l'obiezione: "Ma Wordfence ha un WAF con migliaia di regole per proteggersi da SQL injection, XSS e altri attacchi a livello di applicazione!" Giusto. E abbiamo anche WAF, un modulo Web Application Firewall con regole per rilevare SQL injection, XSS, path traversal e altri attacchi comuni. Ma non stiamo cercando di sostituire ModSecurity o di competere con Cloudflare WAF. Stiamo chiudendo il livello dell'applicazione, quello che vede attacchi specifici di WordPress che il WAF lato server potrebbe non rilevare. Si tratta di una protezione complementare e non sostitutiva del firewall del server.

Voglio parlare anche di un aspetto di cui quasi nessuno parla. Quando hai Wordfence sul tuo sito web, essenzialmente affidi la sicurezza del tuo negozio a una società terza, Defiant Inc. Se domani decidono di aumentare il prezzo a trecento dollari all'anno, pagherai perché l'intera configurazione di sicurezza è legata al loro plugin. Se chiudono la versione gratuita, pagherai. Se consentono una vulnerabilità nel loro plugin (e questo è successo), il tuo negozio ne risentirà. La sicurezza integrata come parte del plug-in principale di gestione del negozio è il controllo. Sai quanto costa, come funziona e non dipendi dalla politica dei prezzi di un singolo fornitore.

Mi piace l'analogia con l'auto. Wordfence è come installare un sistema di sicurezza separato e incernierato sulla tua auto: un sistema di allarme di terze parti, un immobilizzatore separato, un localizzatore GPS esterno, serrature aggiuntive sulla porta. Ogni componente è buono di per sé, ma insieme a volte entrano in conflitto: l'allarme viene attivato dall'immobilizzatore, il localizzatore GPS scarica la batteria, un blocco aggiuntivo blocca quello standard. La sicurezza integrata è come un sistema di fabbrica: ABS, ESP, airbag, immobilizzatore: tutto è progettato insieme, tutto funziona nel suo insieme, niente è in conflitto. Non è così elegante? Forse. Ma per il novantacinque per cento delle situazioni in viaggio è più che sufficiente. E per il restante 5% esistono soluzioni specializzate a livello Cloudflare Enterprise, che funzionano a un livello diverso e non sono in conflitto con nulla.

Non voglio che tu prenda questo articolo come "Wordfence è malvagio, cancellalo immediatamente." No. Wordfence è un buon strumento per determinati scenari. Ma se hai un negozio WooCommerce serio con carico elevato, memorizzazione nella cache a livello di server e la necessità di risparmiare ogni millisecondo, pensa se stai pagando un prezzo troppo alto (sia in termini di denaro che di prestazioni) per funzionalità che possono essere ottenute molto più economiche e facili. La protezione mirata a livello di vettori di attacco specifici - forza bruta, XML-RPC, registrazioni di spam, test delle carte - combinata con un controllo completo delle azioni fornisce una sicurezza reale senza effetti collaterali.

Prova ad abilitare il modulo di sicurezza, a impostare un URL di accesso personalizzato, ad aggiungere CAPTCHA ai moduli, a disabilitare XML-RPC e guarda i log in un giorno. Scommetto che vedrai decine di migliaia di bot bloccati e una notevole riduzione del carico del server. Quindi apri il registro delle attività e guarda cosa sta realmente accadendo sul tuo sito. Sarà sia spaventoso che gratificante. Spaventoso, perché vedrai quanto non avevi notato prima. Utile, perché ora hai il controllo.

E infine, un consiglio che non è correlato ai plugin. La protezione più affidabile contro la forza bruta è una password complessa. Venti caratteri, lettere in entrambi i casi, numeri, caratteri speciali, nessuna parola del dizionario. Sembra banale, ma vedo regolarmente negozi con un fatturato di decine di milioni di rubli, dove la password dell'amministratore è il nome dell'azienda con l'anno di fondazione. Tutte le misure di protezione tecnica che ho descritto sono barriere che rallentano l’aggressore ed eliminano i bot. Ma se la tua password è “admin2024”, nessun URL nascosto e nessun CAPTCHA ti salveranno, perché verrà indovinata nei primi cento tentativi. Una password complessa, l’autenticazione a due fattori, un URL di accesso personalizzato e la limitazione dei tentativi di accesso costituiscono quattro livelli di protezione, ognuno dei quali rende il compito dell’aggressore molto più difficile. Colpirli tutti e quattro contemporaneamente è un compito su cui nessuna botnet di grandi dimensioni sprecherebbe risorse. Andrà semplicemente al sito successivo in cui la password è "123456" e xmlrpc.php è aperto. Non essere questo sito.