Come proteggere WordPress con Fail2Ban

English version: How to protect WordPress with Fail2Ban

Insieme, WP Cerber e Fail2Ban possono bloccare gli attacchi brute-force prima ancora che raggiungano il tuo sito WordPress. WP Cerber rileva i tentativi di accesso falliti a livello di applicazione; Fail2Ban interviene a livello di sistema operativo, bloccando gli aggressori tramite iptables . Questa combinazione blocca gli attacchi brute-force e DoS con un impatto minimo sulle prestazioni.

Cos'è Fail2Ban?

Fail2Ban è un servizio di monitoraggio dei log che viene eseguito sul tuo server. Monitora i file di log alla ricerca di pattern che segnalino un attacco, come ripetuti tentativi di autenticazione falliti dallo stesso indirizzo, e una volta che un host supera una soglia da te impostata, blocca quell'indirizzo nel firewall di sistema per un periodo di tempo prestabilito. Di per sé, non ha alcuna conoscenza di WordPress; agisce esclusivamente in base a ciò che trova nei log. È qui che entra in gioco WP Cerber: monitora e registra i tentativi di accesso falliti in un formato che Fail2Ban può analizzare, fornendo al servizio gli eventi necessari per intervenire.

Scopri di più sugli attacchi: attacchi di forza bruta, DoS e DDoS: qual è la differenza?

Nota: per configurare Fail2Ban è necessario l'accesso root al server Linux.

Con WP Cerber hai tre opzioni per utilizzare Fail2Ban

1. Utilizzare le intestazioni di risposta HTTP 403 se si desidera monitorare il log di accesso di Apache.
2. Utilizzo dei file syslog per monitorare i tentativi di accesso non riusciti
3. Utilizzo di un file di registro personalizzato per monitorare i tentativi di accesso non riusciti.

Monitorare il log di accesso di Apache per le risposte HTTP 403.

Quando un tentativo di accesso fallisce, WP Cerber restituisce uno stato 403 nell'intestazione HTTP. Apache registra questa risposta nel suo file di log degli accessi, dove Fail2Ban può leggerla. Questo comportamento è abilitato per impostazione predefinita. Il compromesso è che Fail2Ban deve analizzare l'intero file access.log per trovare questi tentativi, il che risulta inefficiente su un sito molto trafficato.

Utilizzo di syslog per monitorare i tentativi di accesso non riusciti.

Per impostazione predefinita, WP Cerber registra i tentativi di accesso non riusciti nel syslog tramite la funzionalità LOG_AUTH . Per utilizzare una funzionalità personalizzata, è necessario definire la costante CERBER_LOG_FACILITY con un valore intero. In entrambi i casi, la scrittura nel syslog o in un file personalizzato (vedi sotto) avviene solo dopo aver abilitato l'opzione "Scrivi i tentativi di accesso non riusciti in un file di log" nelle impostazioni principali del plugin.

 define('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Utilizzo di un file personalizzato per monitorare i tentativi di accesso non riusciti.

Per inviare ogni tentativo di accesso fallito a un file di log a tua scelta, imposta il percorso assoluto con la costante CERBER_FAIL_LOG . Non dimenticare di concedere al tuo server web i permessi di scrittura sulla cartella o sul file e di abilitare l'opzione "Scrivi i tentativi di accesso falliti in un file di log" . WP Cerber crea il file di log se non esiste. Una volta definita la costante CERBER_FAIL_LOG , WP Cerber smette di scrivere nel syslog predefinito. È importante notare che un file CERBER_FAIL_LOG personalizzato mantiene i dati sotto il tuo controllo, a differenza del syslog, dove l'archiviazione segue le policy del server o dell'ambiente di hosting.

 define('CERBER_FAIL_LOG','/var/log/wp-cerber-auth.log');

Assicurati che il processo PHP del tuo server web abbia i permessi di scrittura sul file specificato.

Allineamento dei timestamp con l'orologio del server

La mancata corrispondenza del fuso orario è la causa più comune per cui Fail2Ban registra i tentativi di accesso ma non banna mai nessuno, quindi è importante capirlo anche quando tutto il resto è configurato correttamente.

Fail2Ban interviene solo in caso di eventi che rientrano nella sua finestra findtime , che determina confrontando il timestamp di ogni riga del log con l'ora locale del server. WordPress utilizza l'orologio UTC, indipendentemente dal fuso orario impostato sul sito. Pertanto, su un server che utilizza, ad esempio, il fuso orario Europe/Madrid, ogni riga scritta da WordPress sembrerà vecchia di un'ora o due. Fail2Ban scarta questi eventi considerandoli obsoleti e non attiva mai un ban, anche se i tentativi vengono registrati nel log.

WP Cerber aggira questo problema scrivendo i timestamp nel fuso orario del sistema del tuo server anziché nell'orologio di WordPress, in modo che corrispondano a quanto previsto da Fail2Ban. Sulla maggior parte dei server questo processo è automatico e non richiede alcun intervento da parte tua.

Se WP Cerber non riesce a risolvere automaticamente il fuso orario del sistema, impostalo manualmente tramite la costante CERBER_LOG_TIMEZONE , utilizzando un qualsiasi identificatore di fuso orario valido:

 define('CERBER_LOG_TIMEZONE', 'Europe/Madrid');

Questo valore sovrascrive il rilevamento automatico, quindi è il metodo più affidabile per impostare il fuso orario corretto qualora si riscontrassero variazioni nei timestamp. Funziona qualsiasi identificatore presente nel database standard dei fusi orari, ad esempio 'America/New_York' o 'Asia/Tokyo'. Questa costante è disponibile a partire dalla versione 9.7.4 di WP Cerber .

Cosa viene registrato

Questo registro contiene dati personali, quindi se il tuo sito è soggetto a una normativa sulla privacy come il GDPR, ti riguarda direttamente. Ecco cosa contiene.

Ogni tentativo di accesso fallito registra una riga contenente: l'indirizzo IP di origine, il nome utente inserito, il nome host del server, l'ID del processo e una data e ora. Le password non vengono mai registrate, in nessuna forma, e nessun altro dato relativo all'account viene memorizzato.

Due di questi campi sono dati personali ai sensi del GDPR: l'indirizzo IP (la sentenza Breyer ha stabilito che un IP è considerato tale) e il nome utente. Poiché WordPress consente l'accesso tramite email, il nome utente può anche corrispondere all'indirizzo email dell'utente . Questo vale anche per i tentativi di accesso non andati a buon fine, che comunque registrano che una persona specifica è stata presa di mira.

Questo ti rende il responsabile del trattamento di questi dati, con alcune conseguenze pratiche. Includi questi log nella tua politica di conservazione e ruotali o eliminali invece di lasciarli crescere senza limiti. Tieni traccia di dove vengono archiviati e inoltrati i record: un file CERBER_FAIL_LOG personalizzato mantiene i dati sotto il tuo controllo, mentre syslog potrebbe inviare i record a server centralizzati o esterni dove l'archiviazione e l'elaborazione seguono politiche di sistema che potresti non aver impostato. Anche le richieste di accesso o cancellazione da parte dell'interessato si applicano a questi log.

WP Cerber non supporta volutamente la cancellazione automatica di questi log perché non può controllare come syslog gestisce i record o come il sistema operativo del server elabora i file di log. Una funzione di pulizia integrata in WP Cerber coprirebbe solo una parte del problema e potrebbe erroneamente indicare che i dati sono stati rimossi quando in realtà non lo sono.

Questo è un riepilogo pratico, non una consulenza legale. Se gestisci dati provenienti da UE, Regno Unito o giurisdizioni simili, tratta l'indirizzo IP e il nome utente come dati personali e verifica i tuoi obblighi con chi si occupa della conformità per la tua azienda.