Protezione del negozio WooCommerce: WAF, 2FA, blocco geografico e monitoraggio

La ​​settimana scorsa ho ricevuto un'e-mail da un cliente che possiede un negozio online di oli industriali su WooCommerce. L’argomento era laconico: “Siamo stati hackerati”. Dopo mezz'ora di telefonate ho saputo che la storia era banale al punto da far digrignare i denti. Qualcuno ha indovinato la password dell'account del gestore, è entrato nell'area di amministrazione, ha esportato il database dei clienti - nomi, numeri di telefono, indirizzi di consegna, cronologia degli ordini - ed è scomparso. Nessuno si è accorto dell'invasione per due giorni. Il manager utilizzava la password "company2024", non esisteva l'autenticazione a due fattori, lo standard wp-login.php era appeso in piena vista su tutta Internet e l'unica "protezione" era Wordfence, che ha smesso di aggiornarsi tre mesi fa a causa di una licenza scaduta. È un'immagine familiare? L'ho visto accadere dozzine di volte negli ultimi cinque anni, e ogni volta provo la stessa sensazione: un misto di frustrazione e consapevolezza che avrebbe potuto essere evitato.

Il punto è questo: quando lanciamo un negozio WooCommerce, tutti pensano al design, al catalogo prodotti, ai metodi di pagamento, all'impostazione della consegna e al SEO. La sicurezza è proprio l’elemento che finisce costantemente in fondo alla lista. “Lo sistemeremo dopo”, “questo non ci riguarda, siamo un piccolo negozio”, “chi ha bisogno di noi”. E poi si scopre che sono necessari. Perché WooCommerce non è solo un blog WordPress dove al massimo puoi spoilerare l'articolo. Si tratta di dati di pagamento, dati personali dei clienti, accesso al pannello amministrativo, da dove puoi fare cose per centinaia di migliaia di rubli. E non vi attaccano specificatamente, attaccano tutti in fila, con script automatizzati, assolutamente indifferenti sia che vendiate lubrificanti industriali o candele di design.

Mi occupo di sviluppo e marketing per aziende B2B e industriali da molti anni, e durante quel periodo ho visto abbastanza conseguenze degli hack per capire una cosa: la sicurezza del negozio WooCommerce non è un'opzione, è un fondamento. Senza di esso, tutto il resto (un bel sito web, un funnel di vendita semplificato, un CRM personalizzato) crolla all'istante. Ecco perché, quando abbiamo progettato il modulo di sicurezza per COS WP Woo, lo abbiamo affrontato non come “un’altra funzionalità”, ma come un sistema che dovrebbe coprire tutti i principali vettori di attacco per WooCommerce. E oggi voglio raccontarvi come funziona questo sistema, non in astratto, ma con esempi concreti e una spiegazione del motivo per cui è necessario ciascun livello di protezione.

Perché un negozio WooCommerce è un obiettivo gustoso

Vediamo innanzitutto perché i negozi WooCommerce vengono così spesso violati. Ci sono diverse ragioni e funzionano tutte contemporaneamente. WordPress è il CMS più popolare al mondo e alimenta oltre il 40% di tutti i siti web. WooCommerce è il plugin di e-commerce più popolare che trasforma WordPress in un negozio online a tutti gli effetti. Ciò significa che qualsiasi vulnerabilità rilevata diventa immediatamente applicabile a milioni di siti. Gli hacker non cercano una vulnerabilità nel tuo negozio specifico: trovano un buco nella versione 6.4.2 di WordPress o nel plugin Contact Form 7 versione 5.8, quindi uno script automatizzato esegue la scansione di centinaia di migliaia di siti e tenta di sfruttare questo buco. Finisci sotto la pista di pattinaggio. Nessun odio personale.

Ma c'è un altro lato. A differenza di un normale blog, WooCommerce memorizza dati che forniscono valore reale. La tabella wp_postmeta di un negozio medio contiene centinaia di megabyte di informazioni, inclusi indirizzi di consegna, numeri di telefono, indirizzi e-mail e talvolta anche dati parziali della carta. La tabella wp_users contiene gli hash delle password e se uno degli amministratori utilizza la stessa password su più servizi, considera compromessa l'intera catena. Ho lavorato con un negozio in cui la tabella wp_postmeta pesava quasi un gigabyte: quasi 17.000 prodotti, decine di migliaia di ordini in sette anni. La perdita di un database di questo tipo non è solo un fastidio, è una potenziale multa ai sensi della 152-FZ e un colpo alla reputazione da cui le piccole imprese potrebbero non riprendersi.

Ed ecco qualcos'altro che ho notato: c'è un malinteso comune tra i proprietari di negozi online secondo cui se hanno un certificato SSL configurato e qualche tipo di plug-in di sicurezza installato, allora sono protetti. SSL è una crittografia della connessione tra il browser e il server, una cosa meravigliosa, ma non protegge da iniezioni SQL, tentativi di password o script dannosi nel plug-in di qualcun altro. E "una sorta di plugin di sicurezza" spesso risulta essere una versione gratuita di Wordfence o iThemes Security, installata due anni fa e da allora non è mai stata aperta. La protezione reale non è uno strumento, ma un insieme di misure che funzionano a diversi livelli. E voglio attraversare ciascuno di questi livelli.

Pensa al tuo negozio WooCommerce come a un edificio. SSL è un recinto attorno al territorio. Ma all'interno della recinzione è necessario un sistema di videosorveglianza (monitoraggio), una guardia all'ingresso che controlli i documenti (autenticazione), serrature alle porte (restrizione dell'accesso), un rilevatore di movimento (firewall) e persino un sistema di allarme se qualcuno inizia a scassinare il muro (monitoraggio dell'integrità dei file). Rimuovi qualsiasi elemento e l'intero sistema diventa vulnerabile. Questo è esattamente il modo in cui ci siamo avvicinati alla progettazione del modulo di sicurezza: non un grande interruttore, ma una difesa a più livelli.

WAF è la prima linea di difesa che funziona prima che si verifichino problemi

Ho pensato a lungo da dove iniziare parlando di strumenti specifici e ho deciso di iniziare con WAF - Web Application Firewall. Perché questo è proprio il componente che taglia l'80% del traffico spazzatura prima ancora che la richiesta raggiunga il tuo codice PHP. Essenzialmente, un WAF è un filtro che analizza ogni richiesta HTTP in entrata e la confronta con un insieme di regole. Se la richiesta sembra un tentativo di SQL injection, bloccala. Se l'URL contiene una costruzione come ../../../etc/passwd, si tratta di un percorso trasversale, bloccalo. Se è presente codice JavaScript nei parametri della richiesta, si tratta di un attacco XSS, bloccalo.

Sembra semplice, ma l'implementazione è il diavolo nei dettagli. Ricordo che in un progetto abbiamo installato ModSecurity sul server e ha immediatamente iniziato a bloccare le richieste legittime da WooCommerce. Poiché WooCommerce invia tali moduli quando effettua un ordine, ModSecurity con le regole CRS OWASP inizia a sospettare l'iniezione SQL in ogni seconda richiesta POST. Il risultato è stato che i clienti non potevano effettuare un ordine, il tasso di conversione è sceso a zero e abbiamo trascorso due giorni a mettere a punto le regole. Questo è il motivo per cui un WAF che funziona a livello di applicazione e comprende il contesto di WordPress e WooCommerce non è la stessa cosa di un WAF a livello di server.

Nel nostro modulo, WAF funziona come un middleware che intercetta la richiesta in una fase molto precoce, anche prima che WordPress inizi a elaborare il routing. Controlla i parametri GET, il corpo del POST, i cookie, le intestazioni: tutto ciò che proviene dal client. E sa cos'è WooCommerce. Capisce che una richiesta POST al checkout con il campo billing_address_1 è normale, ma una richiesta GET con il parametro ?id=1 UNION SELECT * FROM wp_users non è normale. Questa è una differenza importante rispetto alle soluzioni universali: il nostro WAF è progettato per WordPress e WooCommerce, quindi il numero di falsi positivi è minimo.

Onestamente, quando guardo i log WAF dopo la prima settimana di lavoro su un qualsiasi negozio WooCommerce più o meno visitato, i miei occhi si spalancano ogni volta. Decine di migliaia di richieste bloccate. Iniezioni SQL, tentativi di attraversamento di directory, sonde XSS, scansione di vulnerabilità note nei plugin più diffusi: tutto ciò avviene 24 ore su 24, 7 giorni su 7, senza interruzioni o fine settimana. Su uno dei progetti dei nostri clienti, WAF ha bloccato 47.000 richieste dannose nel primo mese. Quarantasettemila. E il proprietario del negozio, prima di installare il nostro modulo, era sicuro che nessuno avrebbe attaccato il suo "sito di cui nessuno ha bisogno".

Ma WAF è la prima riga. Blocca massicci attacchi automatizzati. WAF non aiuterà contro gli attacchi hacker mirati che utilizzano credenziali rubate. Ciò richiede altri strumenti.

URL di accesso personalizzato e blocco XML-RPC: rimozione di target da posizioni visibili

E se guardassimo il problema dall'altro lato? Invece di costruire muri, puoi semplicemente rimuovere ciò a cui viene sparato. Chiunque abbia mai guardato i log di accesso di un sito WordPress ha visto infinite richieste a /wp-login.php e /xmlrpc.php. Questi sono due indirizzi che i bot conoscono a memoria. Sono scritti in ogni script di forza bruta, in ogni scanner automatizzato. Rimuovi questi indirizzi e il 90% degli attacchi automatizzati incorrerà semplicemente in un errore 404 e andrà a cercare la prossima vittima.

Un URL personalizzato per la pagina di accesso è un'idea che consideravo "sicurezza attraverso l'oscurità" e nei confronti della quale ero un po' snobmente sprezzante. Ad esempio, la vera sicurezza dovrebbe basarsi su password complesse e un’autenticazione corretta, non sul nascondere la porta. Ma la pratica ha dimostrato che mi sbagliavo. No, ovviamente, un URL personalizzato non sostituisce password complesse e due fattori. Ma è un modo incredibilmente efficace per ridurre il carico dei bot e rimuovere il 99% dei rifiuti automatizzati dai log. Quando abbiamo modificato /wp-login.php in un URL personalizzato su uno dei siti di vendita, il numero di tentativi di accesso al giorno è sceso da 3.000 a 12. Dodici! Queste sono persone reali che conoscevano l'indirizzo: amministratori e gestori del negozio. Tutti gli altri tremila erano robot che stupidamente martellavano l'indirizzo standard.

Nel nostro modulo questo è implementato tramite il componente LoginUrl. Specifica un indirizzo arbitrario: almeno /my-secret-door, almeno /academic, almeno /login-1234. Gli standard /wp-login.php e /wp-admin (per chi non ha effettuato l'accesso) smettono di funzionare, restituendo 404. Il bot arriva su /wp-login.php, riceve "pagina non trovata", prende nota "non c'è WordPress qui" e se ne va. Elegante ed efficiente.

Ora parliamo di XML-RPC. Si tratta di un protocollo antico che WordPress ha ereditato dal suo motore precedente: b2/cafelog. Ti consente di gestire da remoto il tuo sito tramite richieste XML. Un tempo questo era utile per le app mobili e gli editor front-end, ma con l'avvento dell'API REST, la necessità di XML-RPC è quasi scomparsa. Ma gli aggressori adorano XML-RPC. Perché? Perché il metodo system.multicall ti consente di inviare centinaia di tentativi di autenticazione in un'unica richiesta HTTP. Cioè, invece di fare 500 richieste a wp-login.php (che è facile da notare e bloccare), l'attaccante fa una richiesta a xmlrpc.php con 500 combinazioni login-password al suo interno. Alcuni plugin di protezione dalla forza bruta non si accorgono nemmeno di questo vettore, perché contano solo i tentativi di accesso tramite un modulo standard.

Chiudiamo semplicemente xmlrpc.php completamente. Un passaggio nelle impostazioni e il protocollo è bloccato. Nessun XML-RPC, nessuna chiamata multipla. Se hai bisogno dell'accesso da applicazioni esterne, esiste un'API REST per questo con autenticazione normale e limitazione della velocità. Non ho visto nessuno scenario aziendale reale nel 2025-2026 in cui sarebbe necessario XML-RPC. Ma mi sono imbattuto in abbastanza scenari in cui i siti web sono stati sfondati.

Vale la pena fare una precisazione importante. Alcuni diranno: "Bene, Jetpack utilizza XML-RPC per comunicare con WordPress.com". Sì, lo fa. Ma se sei passato al nostro modulo di sicurezza, non avrai più bisogno di Jetpack per questi scopi. Inoltre, Jetpack ha iniziato molto tempo fa la migrazione all'API REST. In breve, chiudi XML-RPC e non guardare indietro.

Autenticazione a due fattori e protezione dalla forza bruta: due lucchetti sono meglio di uno

Parliamo dell'autenticazione: il punto apparentemente più semplice e allo stesso tempo più vulnerabile di qualsiasi negozio WooCommerce. Posso installare il WAF più potente, chiudere XML-RPC, nascondere l'URL di accesso, ma se l'amministratore del sito utilizza la password “admin123”, tutte le mie difese crollano come un castello di carte. E non pensare che sto esagerando. Secondo le statistiche che ho visto in progetti reali, circa un negozio WooCommerce su quattro ha almeno un utente con diritti amministrativi e una password di dieci caratteri senza caratteri speciali. Questa non è negligenza: questa è la realtà in cui un responsabile delle vendite deve ricordare le password per venti sistemi e scegliere quella che è più facile da ricordare.

L'autenticazione a due fattori risolve radicalmente questo problema. Anche se un utente malintenzionato dovesse scoprire la password, rubandola, raccogliendola, intercettandola o trovandola in un database trapelato, non sarà in grado di accedere senza un secondo fattore. Nel nostro modulo abbiamo implementato TOTP - Time-based One-Time Password, lo stesso standard utilizzato da Google Authenticator, Microsoft Authenticator e dozzine di altre applicazioni. L'amministratore esegue la scansione del codice QR, l'applicazione inizia a generare codici a sei cifre che cambiano ogni 30 secondi. Quando si accede, è necessario inserire login, password e codice attuale dall'applicazione. Tre fattori? No, due: la password è "cosa sai", il codice dell'applicazione è "cosa hai" (telefono con l'applicazione). Classico due fattori.

Insisto affinché la 2FA sia obbligatoria almeno per tutti gli amministratori e i gestori dei negozi. Facoltativo: per tutti gli utenti. Sapete quale argomento sento più spesso? “È scomodo per i dipendenti, si lamenteranno”. Rispondo sempre allo stesso modo: sai qual è l'inconveniente? Chiama i clienti e spiega loro che i loro dati personali sono trapelati perché Masha del reparto vendite ha deciso che “qwerty” era una password abbastanza complessa. Il codice monouso aggiunge tre secondi al processo di accesso. Tre secondi contro la potenziale fuga di dati di migliaia di clienti. Mi sembra che la scelta sia ovvia.

Ma 2FA è un secondo blocco. E il primo? È qui che entra in gioco la protezione dalla forza bruta. Il nostro modulo LoginProtection funziona secondo il principio del blocco progressivo. I primi tre tentativi di accesso non riusciti costituiscono un avviso. Dopo il quinto l'IP viene bloccato per 15 minuti. Dopo la decima ora - per un'ora. Dopo il ventesimo - per un giorno. Inoltre, il blocco funziona non solo tramite IP, ma anche tramite nome utente. Questo è importante perché gli aggressori a volte utilizzano botnet distribuite con migliaia di indirizzi IP, ma prendono di mira un singolo account: “amministratore” o “manager”. Se il nome utente "admin" ha avuto 20 tentativi falliti da IP diversi, bloccheremo l'accesso per questo nome utente per un certo periodo, indipendentemente dall'IP.

E qui voglio raccontare una storia che illustra perfettamente perché tutti questi meccanismi sono necessari insieme. Uno dei nostri clienti è un produttore di attrezzature idrauliche con un negozio WooCommerce. Aveva tre manager che lavoravano per lui, ciascuno con il proprio conto. Uno dei manager si è licenziato, ma nessuno ha bloccato il suo account. Due mesi dopo, la password di questo account è emersa in una fuga di dati pubblici di un altro servizio (dove il gestore utilizzava la stessa password). Il bot ha trovato questa password, l'ha provata su wp-login.php ed è entrato. Se il nostro modulo fosse stato installato, un URL di accesso personalizzato avrebbe significato che il bot semplicemente non avrebbe trovato la pagina di accesso. Se per miracolo lo trovassi, 2FA richiederebbe un codice da un'applicazione che il bot non ha. E se non ci fosse la 2FA, il monitoraggio delle attività mostrerebbe una voce da un IP sconosciuto alle 3 del mattino e l’amministratore riceverebbe una notifica. Tre linee di difesa, ciascuna delle quali avrebbe potuto prevenire l'incidente da sola. E tutti e tre insieme rendono l’hacking quasi impossibile.

Vorrei dire qualcosa anche sui CAPTCHA. Supportiamo Google reCAPTCHA v2, reCAPTCHA v3 e hCaptcha: a te la scelta. Il CAPTCHA può essere abilitato nel form di login, nel form di registrazione, nella pagina di checkout, nel form di recupero password. reCAPTCHA v3 funziona in modo invisibile: l'utente non si accorge di nulla e Google, sulla base dell'analisi comportamentale, decide se si tratta di un bot o di una persona. Per la maggior parte dei negozi consiglio la v3: non irrita i clienti e allo stesso tempo elimina efficacemente i bot. Nei moduli di accesso dell'amministratore, puoi selezionare la v2 con la classica casella di controllo "Non sono un robot", qui la UX è meno critica, ma la protezione è più rigorosa.

Geoblocking: un approccio chirurgico al filtraggio del traffico

Sai, sono scettico riguardo al blocco geografico da molto tempo. Sembrava che bloccare interi paesi fosse uno strumento troppo rozzo, qualcosa come “colpire le zanzare con un martello”. Ma poi ho iniziato ad analizzare i registri degli attacchi sui siti dei clienti e ho cambiato idea. Non 180 gradi, piuttosto 120. Il blocco geografico non è una panacea, ma è uno strumento sorprendentemente efficace per determinati scenari.

Ecco i numeri specifici di uno dei progetti. In un mese, WAF ha bloccato circa 50.000 richieste dannose. Li ho divisi per geolocalizzazione. Il 38% proveniva da paesi del sud-est asiatico che non facevano parte del mercato di riferimento del negozio. Il 22% viene dal Sud America, anche lui di passaggio. Il 15% proviene dall'Africa. Il 12% proviene dall'Europa dell'Est (ma non dalla Russia o dalla CSI). Totale: l'87% del traffico dannoso proveniva da regioni in cui il negozio non aveva un solo cliente reale. Zero ordini, zero iscrizioni, zero richieste. Traffico di attacco puro.

Il blocco geografico consente di bloccare l'accesso al sito (o ad alcune parti di esso, ad esempio solo wp-admin e API REST) ​​per gli indirizzi IP di paesi selezionati. Questo non sostituisce WAF, è un'aggiunta. WAF analizza il contenuto della richiesta, geobloccando i filtri per fonte. Insieme creano un doppio filtro: in primo luogo, il traffico proveniente da regioni non target viene tagliato e ciò che rimane viene controllato da WAF per eventuali danni.

Ma voglio essere sincero: il blocco geografico non è per tutti. Se il tuo negozio vende in tutto il mondo, bloccare i paesi è una cattiva idea. Se hai clienti in Brasile o India, non puoi bloccare queste regioni. Il blocco geografico è ideale per i negozi con un mercato geografico chiaramente definito. Un negozio B2B russo che vende solo in Russia e nella CSI? Puoi bloccare in sicurezza l'accesso da paesi da cui sicuramente non arriveranno gli ordini, ma da cui arriveranno sicuramente gli attacchi. Un negozio che funziona per la Russia e l’UE? Chiudi quelle regioni con cui non lavori. Ogni regione bloccata significa migliaia di richieste dannose che semplicemente non raggiungeranno il tuo server. Questo è sia sicurezza che risparmio di risorse del server.

Nel nostro modulo, il blocco geografico viene configurato tramite una comoda interfaccia: seleziona i paesi, indica cosa bloccare (l'intero sito o solo l'area di amministrazione) e attivalo. I database GeoIP vengono aggiornati automaticamente. Puoi impostare una lista bianca per IP specifici che non devono essere bloccati indipendentemente dal Paese: questo è utile se hai uno sviluppatore remoto da una regione bloccata.

E un altro punto che vale la pena sottolineare. Il geoblocco a livello di applicazione (il nostro plugin) funziona in modo leggermente diverso rispetto al geoblocco a livello CDN (Cloudflare) o server (CSF/iptables). A livello applicativo la richiesta ha già raggiunto PHP e la stiamo elaborando. Ciò significa un carico minimo sul server, ma la richiesta viene comunque elaborata. Se hai Cloudflare, l’ideale è abilitare il blocco geografico sia lì che qui. Cloudflare interromperà il traffico prima che raggiunga il server e il nostro modulo catturerà ciò che è sfuggito a Cloudflare (ad esempio, richieste direttamente all'IP del server, bypassando il CDN). Difesa in profondità: ricordi?

Gestione IP: liste nere e bianche, blocco automatico per pattern

La gestione IP è uno strumento che a prima vista sembra primitivo. Blacklist, whitelist: cosa c'è di così complicato? Ma se usato correttamente, diventa un potente strumento tattico. Ti dirò come lo usiamo e perché è importante in combinazione con altre misure.

La whitelist è un territorio sacro. Indirizzi IP che non vengono mai bloccati, in nessun caso. Ciò include gli indirizzi del tuo ufficio, degli amministratori IP domestici, indirizzi IP di servizi affidabili - sistemi di pagamento, 1C, partner API. Ho visto una situazione in cui il servizio di monitoraggio ha iniziato a inviare richieste che il WAF ha interpretato come scansione di vulnerabilità e le ha bloccate. Il risultato è stato che il monitoraggio ha evidenziato che il sito era inattivo, pur funzionando perfettamente. Una whitelist risolve questi problemi.

La lista nera è un blocco rigido. Un indirizzo sulla lista nera viene rifiutato immediatamente, senza alcuna elaborazione. La lista nera è utile per bloccare manualmente specifiche fonti di attacchi rilevate nei registri. Se vediamo che c'è attività sospetta proveniente da un IP specifico, lo aggiungeremo alla lista nera, lo scopriremo in seguito.

Ma la cosa più interessante è il blocco automatico basato su pattern. Il nostro modulo può inviare automaticamente un IP alla blacklist se viene rilevato un determinato modello di comportamento da questo indirizzo: troppi errori 404 in breve tempo (segno di scansione), troppi tentativi di login, tentativi di accesso a file PHP inesistenti, accesso a tipiche backdoor (wp-config.php.bak, .env, debug.log). Funziona insieme a WAF e LoginProtection, creando un sistema di risposta automatica: attività sospetta rilevata, bloccata, registrata, notificata all'amministratore.

Sapete cosa mi piace di questo approccio? Sta imparando da solo. Non nel senso del machine learning, ma nel senso che ogni attacco rende il sistema più forte. Ogni IP bloccato si aggiunge al database, ogni modello di attacco affina le regole. Dopo un mese di funzionamento, il tuo modulo di sicurezza riconosce gli specifici intervalli IP da cui il tuo sito viene attaccato più spesso e li blocca in modo proattivo.

Monitoraggio dell'integrità dei file: il tuo guardiano silenzioso

Ora parliamo di cosa succede quando tutte le precedenti linee di difesa hanno fallito. Supponiamo che l'aggressore abbia comunque ottenuto l'accesso. Forse attraverso una vulnerabilità in un plugin di terze parti, attraverso un account di hosting FTP compromesso, attraverso un'iniezione SQL che WAF non ha riconosciuto. Qual è la prima cosa che fa? Modifica i file. Aggiunge una backdoor al file Functions.php del tema, inserisce una shell PHP nella directory dei caricamenti, modifica i file core di WordPress per intercettare le credenziali.

File Integrity Monitoring (FIM) è un sistema che monitora le modifiche ai file core, plugin e temi di WordPress. Prende una "istantanea" del file system, un hash di ciascun file, e confronta regolarmente lo stato corrente con quell'istantanea. Se un file è cambiato, un nuovo file è apparso dove non dovrebbe essere o un file che dovrebbe essere lì è scomparso, l'amministratore riceve una notifica.

Ti racconterò la vera storia. In uno dei progetti, abbiamo scoperto che qualcuno aveva modificato il file wp-includes/version.php. Questo file contiene il numero di versione di WordPress e solitamente non cambia tra gli aggiornamenti. Il cambiamento è stato sottile: alla fine del file è stata aggiunta una riga di codice che, in determinate condizioni, scaricava ed eseguiva uno script da un server esterno. Senza il monitoraggio dell’integrità, questo cambiamento potrebbe non essere notato per mesi. Con il monitoraggio, abbiamo ricevuto la notifica entro un'ora.

Nel nostro modulo, il monitoraggio dell'integrità funziona secondo una pianificazione: puoi impostare un controllo ogni ora, ogni sei ore o una volta al giorno. Quando vengono rilevate modifiche, viene inviata una notifica e-mail con un elenco dei file modificati. L'amministratore può vedere cosa è cambiato esattamente e decidere se si tratta di un aggiornamento legittimo del plug-in o di un tentativo di introdurre codice dannoso.

Nota importante: quando aggiorni WordPress, plugin o temi, i file cambiano naturalmente. Una buona FIM deve essere in grado di distinguere i cambiamenti legittimi da quelli sospetti. Il nostro modulo sa quali file sono inclusi nella distribuzione standard di WordPress di una determinata versione e può confrontare i tuoi file con quelli di riferimento. Se il file wp-login.php sul tuo server differisce da quello fornito nella versione ufficiale di WordPress, questo è motivo di preoccupazione.

E qui voglio fare una digressione filosofica. Il monitoraggio dell'integrità dei file non è uno strumento di prevenzione. Questo è uno strumento di scoperta. Non fermerà l'hacking, ma te lo farà sapere rapidamente. E nella sicurezza informatica, la velocità di rilevamento è tutto. Secondo le statistiche, per le piccole imprese il tempo medio che intercorre tra un attacco hacker e il suo rilevamento è di 197 giorni. Per quasi sette mesi, un utente malintenzionato può prendere il controllo del tuo sito web, rubare dati, utilizzare il server per inviare spam, inserire collegamenti dannosi e tu non te ne accorgi nemmeno. Il monitoraggio dell'integrità riduce questa finestra a ore.

Registro attività: un quadro completo di ciò che sta accadendo

Il registro delle attività è una funzionalità di cui le persone iniziano a comprendere il valore solo dopo che si verifica un incidente. Quando tutto va bene, il registro sembra essere un rumore inutile: "L'amministratore dell'utente ha effettuato l'accesso", "Il gestore dell'utente ha modificato il prodotto n. 15748", "Impostazioni del plug-in aggiornate dell'amministratore dell'utente". È noioso, poco interessante, perché tenerlo? E poi si verifica un incidente e la prima domanda è: "Chi ha fatto questo? Quando? Cosa hai cambiato esattamente?" E senza un registro delle attività è impossibile rispondere a queste domande.

Il nostro modulo ActivityLog registra tutte le attività significative nel pannello di amministrazione di WordPress e WooCommerce. Login e logout utente (con indirizzi IP e user-agent). Creazione, modifica ed eliminazione di contenuti: post, pagine, prodotti, ordini. Modifica delle impostazioni: qualsiasi impostazione, comprese le impostazioni del plug-in. Installazione, attivazione e disattivazione di plugin e temi. Azioni con gli utenti: creazione, eliminazione, modifica dei ruoli. Lavorare con file multimediali. E decine di altri tipi di eventi.

Utilizzo i registri delle attività non solo per le indagini sugli incidenti, ma anche per la gestione quotidiana. Quando un team ha tre o quattro persone con accesso all'amministratore del negozio, il registro è il tuo strumento di controllo. Chi ha cambiato il prezzo di questo prodotto? Chi ha cancellato quella categoria? Chi ha installato lo strano plugin? Senza registro: accuse, incomprensioni, conflitti. Con un registro: fatti, date, orari. Niente di personale, solo dati.

E il registro delle attività è anche una rete di sicurezza legale. In caso di controversia con un cliente che sostiene che il suo ordine è stato modificato a sua insaputa, è possibile dimostrare che l'ordine è stato modificato da un determinato responsabile in un momento specifico. O viceversa: dimostra che nessuno dei tuoi dipendenti ha toccato l'ordine. In un mondo in cui le controversie sui dati personali stanno diventando sempre più gravi, questo livello di documentazione non è un lusso, ma una necessità.

I log vengono archiviati in una tabella di database separata con contesti, che consente di filtrare per utente, per tipo di azione, per data. È possibile impostare la pulizia automatica dei vecchi record, ad esempio archiviare i registri degli ultimi 90 giorni. Questo è sufficiente per la maggior parte dei negozi. Se hai bisogno di un'archiviazione a lungo termine, puoi esportare in CSV.

Trovo particolarmente utile il collegamento del registro delle attività con altri moduli di sicurezza. Quando WAF blocca una richiesta, questa viene inserita nel registro. Quando LoginProtection blocca un IP, questo viene inserito nel registro. Quando FIM rileva una modifica al file, viene inserita nel registro. Di conseguenza, si dispone di un'unica cronologia di tutti gli eventi di sicurezza che possono essere visualizzati in un'unica interfaccia. Non è necessario passare tra dieci schermate di plugin diversi: tutto è in un unico posto.

Perché non usiamo Wordfence e perché probabilmente non dovresti neanche tu

Ed è qui che inizia la parte divertente: il confronto con quanto già presente sul mercato. Wordfence è il plugin di sicurezza più popolare per WordPress, con oltre 4 milioni di installazioni attive. È bravo, serio, meritato. Io stesso l'ho usato per diversi anni su vari progetti. E ho accumulato un elenco di reclami che alla fine mi hanno portato alla decisione di sviluppare il mio modulo.

Il primo e principale problema riguarda le dimensioni e le prestazioni. Wordfence è un mostro. La versione gratuita occupa circa 30 MB di spazio su disco, la versione Premium ne occupa ancora di più. Ma la dimensione del disco non è poi così male. Wordfence esegue il proprio firewall su ogni richiesta al sito, scansiona il database, controlla i file e chiama un'API esterna per aggiornare le firme. Sull'hosting condiviso, ciò può aumentare il tempo di caricamento della pagina di 200-300 millisecondi. In un negozio WooCommerce affollato con migliaia di prodotti e traffico attivo, questo è evidente.

Il nostro modulo di sicurezza fa parte del COS di WP Woo che pesa... beh, fa parte di un plugin, non di un'entità separata. Non dispone di un proprio firewall a livello PHP che intercetta ogni richiesta tramite auto_prepend_file. Funziona tramite hook WordPress standard, il che significa migliore compatibilità e prevedibilità.

Il secondo problema riguarda la memorizzazione nella cache dei conflitti. L'ho riscontrato in ogni altro progetto Wordfence. LiteSpeed ​​​​Cache, WP Super Cache, W3 Total Cache - Wordfence è in conflitto con loro con invidiabile regolarità. Quindi non può scansionare i file perché la cache restituisce la pagina prima che Wordfence abbia il tempo di controllarla. Quindi il suo firewall blocca le richieste dal plug-in della cache. Quindi il monitoraggio del traffico in tempo reale inizia a mostrare le richieste memorizzate nella cache come “sospette”. Su un progetto con LiteSpeed, abbiamo trascorso due giorni lavorativi affinché Wordfence e LiteSpeed ​​​​Cache lavorassero insieme senza conflitti. Due giorni di lavoro da sviluppatore sono soldi veri.

Il terzo problema è il prezzo. Wordfence Premium costa $ 119 all'anno per un sito. Se hai cinque negozi: $ 595 all'anno. In dieci anni, seimila dollari solo per la sicurezza. E questo nonostante il fatto che la versione gratuita abbia limitazioni significative: le firme del firewall vengono aggiornate con un ritardo di 30 giorni (trenta giorni, Karl! - durante questo periodo la vulnerabilità avrà il tempo di diventare proprietà di ogni script kiddie), non esiste una lista nera degli IP in tempo reale, scansione limitata. Cioè, la versione gratuita è, in effetti, uno strumento di marketing per la vendita di Premium.

Il nostro modulo di sicurezza non ha una versione gratuita e una a pagamento. Tutte le funzioni - WAF, 2FA, blocco geografico, FIM, registro attività, CAPTCHA, gestione IP, URL personalizzato, blocco XML-RPC, protezione dalla forza bruta - sono disponibili come parte di COS WP Woo. Un plugin, una licenza, un set completo di strumenti. Non paghi separatamente per la sicurezza, separatamente per B2B, separatamente per ricerca, separatamente per integrazione con 1C. Tutti insieme.

La quarta sfida è l'integrazione. Wordfence è un plugin autonomo. Non sa nulla del tuo modulo B2B, della tua ricerca, del tuo CRM. Il nostro modulo di sicurezza fa parte di un unico ecosistema. Conosce gli utenti B2B e può applicare diverse policy di sicurezza per diversi gruppi di clienti. È integrato con il modulo di notifiche e-mail. Utilizza un sistema di impostazioni comune e un'interfaccia amministrativa comune. Non è un mosaico di dieci plugin diversi di dieci sviluppatori diversi: è un unico sistema in cui tutti i componenti sono progettati per funzionare insieme.

Non intendo dire che Wordfence sia un cattivo prodotto. Per un normale blog WordPress in cui non è presente WooCommerce e le prestazioni non sono critiche, Wordfence Premium è un'ottima scelta. Ma per un negozio WooCommerce con migliaia di prodotti, funzionalità B2B, integrazione con 1C e requisiti prestazionali, il modulo di sicurezza integrato funziona meglio perché è progettato per questo contesto.

Approccio integrato: come tutti gli elementi lavorano insieme

In particolare non ho descritto ogni componente del modulo di sicurezza come una funzione isolata, perché non funzionano in modo isolato. L'idea è che ogni componente migliora gli altri. Esaminiamo un tipico scenario di attacco e vediamo come reagisce il sistema in ogni fase.

Un bot dal Vietnam sta tentando di accedere al sito. Il geoblocco controlla l'IP: il Vietnam non è nell'elenco dei paesi consentiti. La richiesta è bloccata. L'incidente viene registrato nel registro delle attività. Fatto, la storia è finita, non è nemmeno arrivata al WAF.

Un altro bot, proveniente da un paese consentito, sta tentando di accedere a /wp-login.php. Il modulo LoginUrl intercetta la richiesta: l'URL non corrisponde a quello personalizzato. Viene restituito 404. Il bot pensa che il sito non abbia WordPress. Andiamo avanti.

Il terzo bot, più avanzato, in qualche modo ha appreso il vero URL di accesso. Cercando di indovinare la password. Dopo il quinto tentativo, LoginProtection blocca l'IP. Registrazione, notifica all'amministratore. L'IP viene automaticamente inserito nella lista nera tramite IpManagement.

Il quarto scenario prevede che l'aggressore non tenti di accedere, ma provi l'iniezione SQL tramite il parametro di ricerca. WAF riconosce il modello, blocca la richiesta e la scrive nel log. L'IP viene inviato in quarantena.

Il quinto scenario è che un utente malintenzionato abbia trovato una vulnerabilità in un plugin di terze parti (non il nostro) e sia riuscito a caricare una shell PHP nella directory degli upload. FIM rileva un nuovo file PHP in cui dovrebbero esserci solo immagini. L'amministratore riceve una notifica, elimina il file e aggiorna il plug-in vulnerabile.

Il sesto scenario è un bot che tenta di attaccare tramite xmlrpc.php. La richiesta è bloccata a livello del modulo XmlRpc. Non è nemmeno elaborato.

Vedi lo schema? Ogni livello ha il proprio filtro. Per accedere ai tuoi dati, un utente malintenzionato deve passare attraverso tutti i livelli. Ogni livello è indipendente e autonomo, ma insieme creano un sistema estremamente difficile da aggirare. Non è possibile scassinare una sola serratura: ci sono dieci serrature e ognuna è più difficile della precedente.

Sento spesso la domanda: “Tutto questo rallenterà il mio sito?” Domanda giusta. Risposta: no, se implementato correttamente. Il blocco geografico è un controllo IP rispetto a un database in memoria, microsecondi. Controllo URL di accesso: confronto di stringhe, nanosecondi. WAF: una serie di controlli regex per una richiesta in arrivo, un paio di millisecondi. Il CAPTCHA è una verifica lato client e non carica affatto il server. FIM funziona nei tempi previsti, in background. Registro attività: un inserimento nel database durante un evento. Il carico totale nell'elaborazione di una richiesta è di circa 5-10 millisecondi. Questo è molte volte inferiore a Wordfence con la scansione completa di ogni richiesta.

C'è un altro punto che voglio menzionare separatamente, perché spesso viene trascurato. La sicurezza non è una configurazione una tantum, è un processo. Oggi puoi configurare perfettamente tutti i moduli, ma tra tre mesi ci sarà un nuovo vettore di attacco, una nuova vulnerabilità in WordPress o in uno dei tuoi plugin, una nuova tecnica di bypass del CAPTCHA. Ecco perché il nostro modulo viene aggiornato insieme al plug-in: le regole WAF vengono reintegrate, i database GeoIP vengono aggiornati, gli algoritmi di rilevamento vengono migliorati. Non è necessario tenerlo d'occhio: gli aggiornamenti arrivano automaticamente. Questa è una differenza fondamentale rispetto all’approccio “impostalo e dimenticalo”, che termina con il fatto che sei mesi dopo la tua “protezione” funziona secondo le regole di sei mesi fa e gli aggressori utilizzano già metodi di cui il tuo plugin non è ancora a conoscenza.

Vorrei essere chiaro: la sicurezza del negozio WooCommerce non è un'area in cui dovresti lesinare o procrastinare. Ogni giorno senza protezione è un giorno in cui i tuoi dati, quelli dei tuoi clienti e la tua reputazione sono a rischio. Ho visto negozi chiudere dopo una violazione dei dati, non perché la violazione fosse catastrofica, ma perché non è stato possibile ripristinare la fiducia dei clienti. Ho visto aziende che hanno pagato centinaia di migliaia di rubli per il ripristino dopo un hacking: trasferimento su un server pulito, verifica del codice, notifica ai clienti, consulenza legale. E tutto questo avrebbe potuto essere evitato con un modulo configurabile in mezz'ora.

Il nostro approccio non è quello di vendere la sicurezza come un prodotto costoso separato, ma di renderla parte integrante dello strumento che già utilizzi per gestire il tuo negozio. Non è necessario installare un plugin separato, non è necessario acquistare una licenza separata, non è necessario comprendere l'interfaccia di un altro prodotto. Apri le impostazioni di COS WP Woo, vai alla sezione Sicurezza, abilita i moduli necessari e il tuo negozio è protetto. WAF funziona, 2FA è configurato, il blocco geografico filtra il traffico spazzatura, il monitoraggio monitora i file, un registro registra ogni azione. Non uno strumento, ma dieci - e funzionano tutti in armonia, come parti di un meccanismo.

E se lo guardassi dal punto di vista aziendale? Il costo di un incidente di sicurezza per un negozio online medio va da 200.000 a 2.000.000 di rubli, se si contano le perdite dirette (recupero, audit, avvocati) e indirette (perdita di clienti, danni alla reputazione, tempi di inattività aziendale). Il costo della prevenzione è pari a zero rubli aggiuntivi se hai già COS WP Woo. Non conosco investimento aziendale migliore. Il calcolo è semplice: dedica mezz'ora alla configurazione adesso o impiega settimane a eseguire il ripristino in seguito. Mi sembra che la scelta sia ovvia. E il cliente che mi ha chiamato con la frase "siamo stati hackerati" ora sarebbe d'accordo con questo.

Prova gratuitamente COS WP Woo- installa il plugin e ottieni 14 giorni di accesso completo a tutti i moduli, inclusa la sicurezza. WAF, autenticazione a due fattori, blocco geografico, monitoraggio dei file, registro delle attività: tutto ciò inizierà a proteggere il tuo negozio dal primo minuto. Nessuna restrizione, nessun costo nascosto, nessuna necessità di acquistare cinque plugin diversi. Uno strumento: protezione completa.