Cosa fa il plugin quando parte un attacco brute force

Ogni login fallito di un attacco brute force viene annotato: IP, nome utente provato, esito, orario. La password no, mai. Quando un IP supera la soglia che hai impostato, il plugin Cisilino Site Defense Network aggiunge una regola al .htaccess (compatibile con Apache 2.4 e 2.2). Da quel momento le richieste di quell’indirizzo si fermano al web server. WordPress non viene nemmeno caricato, quindi il sito torna a respirare.

Un dettaglio che conta: il contatore è un’operazione atomica sul database. Mandare cento tentativi insieme, nello stesso istante, non permette di scavalcare la soglia.

Dove vedere cosa è successo

In Impostazioni › Cisilino Site Defense Network trovi la scheda degli IP bloccati durante un attacco brute force, con filtro, e l’elenco delle ultime 50 rilevazioni. Se un cliente si è bloccato da solo, “Sblocca” sulla riga e finisce lì.

Quando gli IP sono tanti

Il blocco per IP ha un limite noto. Se un attacco brute force arriva da centinaia di indirizzi diversi, ognuno deve prima superare la soglia. Con la rete Cisilino un IP già visto fallire su un altro sito del tuo cliente viene bloccato prima ancora di arrivare. In ogni caso, usa nomi utente non ovvi e password lunghe: il plugin toglie il rumore, ma non rende forte una password debole.

Su un hosting nginx il plugin registra i tentativi ma non può scrivere la regola a livello server. Per capire quali altre contromisure esistono, l’OWASP ha una guida sul blocco degli attacchi brute force.

Domande frequenti

Come si blocca un attacco brute force su WordPress?

Contando i login falliti per IP e bloccando chi supera una soglia. Il plugin lo fa scrivendo una regola in .htaccess, così la richiesta si ferma prima di WordPress.

Il plugin salva le password provate?

No. Registra IP, nome utente tentato, esito e orario, mai la password.

Posso sbloccare un IP bloccato per errore?

Sì, dalla lista degli IP bloccati con il pulsante Sblocca su ogni riga.

Leggi anche

• Whitelist IP WordPress: sblocco e ban manuali con scadenza.
• Blocco IP condiviso tra siti WordPress con il pannello.
• Cisilino Site Defense Network: il plugin di sicurezza per WordPress.

The post Attacco brute force WordPress: come fermarlo sul login first appeared on Matteo Cisilino.

Chi ci casca non è stupido. Questo va detto chiaro fin dal primo articolo. L’ingegneria sociale funziona perché punta su leve umane del tutto normali. La fretta di chi ha trenta mail da smaltire. Il rispetto istintivo per un capo o per una banca. La fiducia in un fornitore che si conosce da anni. Nessuno è immune, io compreso in un giorno storto. Questa rubrica non è una lista di figuracce da sbeffeggiare. È uno spazio dove racconto casi veri. Li raccolgo via via, lavorando con i clienti. Servono per imparare a riconoscere le tecniche, prima che riconoscano noi.

Le leve psicologiche dietro l’ingegneria sociale

Nella pratica l’ingegneria sociale ricicla sempre le stesse quattro leve. Le trovi descritte bene anche nella voce di Wikipedia sull’ingegneria sociale applicata alla sicurezza informatica. La prima è l’urgenza artificiale: scadenze finte, “il pagamento è bloccato”, “rispondi entro un’ora”. La seconda è l’autorità finta: una mail che sembra del titolare o della banca, con firma e logo copiati bene. La terza è la familiarità: un fornitore vero, un collega vero, un numero che conosci già. La quarta è la paura di perdere qualcosa: l’accesso, la fattura, la prenotazione confermata. Riconoscere queste quattro leve è già metà del lavoro. Vale per chiunque gestisca ogni giorno una casella di posta.

Il primo caso l’ho già raccontato per intero. È un tentativo di phishing alberghiero arrivato a un gestore di struttura ricettiva, con le schermate reali della mail truffa e i dettagli che l’hanno tradita. Da lì in avanti aggiungerò i casi nuovi che vedo passare, uno per volta. Senza nomi, e senza dati che possano far riconoscere nessuno.

L’ingegneria sociale non sparirà. Cambia solo il pretesto, non la meccanica di fondo. Per questo conviene studiarla con calma, non quando è già arrivata la mail sospetta e il cuore batte un po’ più forte.

Se nei prossimi mesi ti arriva qualcosa che ti sembra strano, scrivimi. Lo guardiamo insieme. Se è un caso istruttivo, potrebbe finire, in forma anonima, nella prossima puntata di questa rubrica.

The post Ingegneria sociale: il problema tra sedia e tastiera first appeared on Matteo Cisilino.

Il mittente usa un nome generico. Niente di sospetto a prima vista. L’oggetto è innocuo: “Disponibilità camera dal 10 al 12 novembre”. Il testo è in italiano abbastanza naturale. Ha qualche piccola imperfezione, il tipo che un madrelingua noterebbe, ma niente che faccia scattare un allarme immediato. Chi scrive dice di voler prenotare. Chiede conferma della disponibilità. Poi aggiunge un dettaglio che sembra innocuo: dichiara di aver allegato una copia del passaporto, “per facilitare la prenotazione”. C’è anche un piccolo dettaglio temporale: sarà in viaggio dal giorno 9, quindi preferirebbe avere già tutto confermato in anticipo.

Quella frase, “sarò in viaggio”, è una leva psicologica precisa. Non è un’urgenza aggressiva. Non chiede soldi subito. Crea solo una ragione plausibile per sbrigarsi, per rispondere prima di pensarci troppo. Ho visto lo screenshot di questa email, con il link oscurato per sicurezza. La trovo un esempio quasi da manuale di come si costruisce un tentativo di phishing alberghiero efficace: gentile, credibile, con un pizzico di urgenza calcolata.

Come funziona il phishing alberghiero in due passaggi

Il meccanismo ha due fasi distinte. Vale la pena capirle entrambe, perché da fuori sembrano banali e invece funzionano. La prima fase è l’email. Contiene un link abbreviato, del tipo che passa attraverso un redirector: un servizio che nasconde la vera destinazione dietro un indirizzo corto. Cliccandolo, non si vede subito dove si sta andando a finire. Questo è già il primo inganno, piccolo ma efficace.

La seconda fase è la pagina di destinazione. È una schermata che si finge una procedura di conferma o di pagamento. Graficamente ricorda quella di una piattaforma vera, a volte abbastanza bene da ingannare anche chi lavora nel settore da anni. È lì che succede il danno vero. Il gestore della struttura, convinto di dover verificare la disponibilità o confermare la prenotazione, inserisce le proprie credenziali. Può trattarsi di quelle dell’extranet di Booking o Airbnb. Oppure di quelle della propria casella email, o del pannello di gestione del sito. Da quel momento, le credenziali sono già in mano a chi ha mandato l’email. Il resto, agli occhi di chi è stato truffato, succede dopo, quando è troppo tardi per tornare indietro.

Perché chi gestisce una struttura è un obiettivo comodo

Chi lavora in una struttura ricettiva riceve decine di richieste simili ogni settimana. Email di ospiti, domande sulla disponibilità, richieste di conferma last minute. È un flusso costante, spesso gestito di fretta, tra un check-in e l’altro. Un messaggio in più, educato e plausibile, si mimetizza bene in quel flusso. Non spicca. Il punto debole non è la tecnologia del gestore. È il suo tempo limitato, e l’abitudine a rispondere in fretta a chi sembra un cliente vero. Per questo il phishing alberghiero funziona così bene: non punta a un sistema informatico, punta a una persona impegnata.

Le red flag da riconoscere

Ci sono segnali concreti. Nessuno da solo basta a dimostrare una truffa, ma insieme raccontano una storia chiara. Il contatto arriva per email diretta, non dal canale ufficiale della piattaforma: Booking e Airbnb hanno sistemi di messaggistica interna, e un ospite reale li usa quasi sempre. Il link è abbreviato o mascherato, quindi non si capisce dove porta leggendo solo l’indirizzo. Il messaggio chiede di “verificare la disponibilità” cliccando un link, invece di lasciare che il gestore controlli dal proprio pannello, digitando l’indirizzo a mano come farebbe sempre. Il tono è gentile, quasi premuroso. L’urgenza è misurata: non spaventa, ma spinge comunque ad agire in fretta, prima di pensarci su.

Perché l’ho messa sotto “Tra la sedia e la tastiera”

Ho aperto questa categoria sul sito apposta per i casi come questo. “Tra la sedia e la tastiera” è una battuta che chi lavora in sicurezza informatica conosce bene. Indica il punto esatto in cui succede quasi sempre il danno: la persona davanti allo schermo, non il software. La piattaforma di prenotazione non ha colpe in questo episodio specifico. Il problema non è un bug di Booking o di Airbnb. È il momento in cui un umano, magari di fretta, clicca un link che non doveva cliccare. Capirlo aiuta a difendersi meglio. Non basta un antivirus. Serve l’abitudine di fermarsi un secondo prima di cliccare, ogni volta.

Se le credenziali finiscono comunque nelle mani sbagliate, va valutato se cambiarle subito, ovunque siano usate. Ne ho parlato quando ho raccontato la rotazione delle credenziali del database dopo una violazione. Il contesto tecnico è diverso, ma il principio resta lo stesso.

Cosa fare per proteggere la propria struttura

La prima regola è semplice, ma va ripetuta spesso: mai inserire credenziali cliccando un link arrivato per email, nemmeno se sembra urgente. Se qualcuno scrive dicendo di voler prenotare, si verifica dal proprio pannello. Si digita l’indirizzo a mano, non si segue un link mandato da uno sconosciuto. La seconda regola riguarda l’autenticazione a due fattori. Va attivata su ogni account che conta: extranet della piattaforma, casella email, pannello del sito. Anche se le credenziali vengono rubate, un secondo fattore blocca comunque l’accesso, nella maggior parte dei casi. La terza regola è la segnalazione. Ogni messaggio sospetto va segnalato alla piattaforma, che usa questi dati per bloccare altri tentativi simili. Non è un caso che la gestione di questi episodi sia uno dei motivi dell’indagine europea. Il problema del phishing alberghiero riguarda anche le piattaforme, non solo i singoli gestori.

Chi vuole seguire gli sviluppi può leggere la ricostruzione dell’agenzia AGI sull’inchiesta della Commissione contro Booking.com. Riassume bene cosa sta succedendo. E perché riguarda anche chi gestisce una struttura piccola, non solo le grandi catene.

Se hai già cliccato o inserito dei dati

Se è già successo, conviene muoversi in fretta. Cambia subito la password dell’account coinvolto. Cambiala anche ovunque la stessa password sia stata riusata: è un errore comune, e chi ruba credenziali lo sa bene. Attiva la verifica in due passaggi, se non l’avevi già fatto. Controlla la cronologia degli accessi dell’account. Cerca sessioni o dispositivi che non riconosci. Avvisa la piattaforma, che ha procedure dedicate per gli account compromessi. Se nella mail avevi allegato documenti veri, tienili d’occhio: un documento d’identità rubato può essere riusato altrove, non solo per altre truffe legate al settore alberghiero.

Il caso che ho visto non ha fatto danni. Chi l’ha ricevuto si è fermato un attimo prima di cliccare, e me l’ha segnalato. È bastato quello. La tecnologia aiuta, i filtri antispam aiutano, ma alla fine la differenza la fa sempre la persona che decide se cliccare o no. Il problema del phishing alberghiero, quasi sempre, resta tra la sedia e la tastiera.

The post Phishing alberghiero: l’email-truffa che ho visto arrivare a un gestore di struttura first appeared on Matteo Cisilino.

Perché i permessi file WordPress si rompono così spesso

Gestisco server in produzione da anni. I motivi sono sempre gli stessi. Una migrazione tra hosting diversi, con un client FTP configurato male, lascia cartelle a 777 e file eseguibili da chiunque. Un ripristino da backup che non preserva i permessi originali è un altro classico. L’archivio si scompatta con i permessi di default dell’utente che lo estrae, non con quelli che il sito aveva prima. Capita anche con un intervento manuale frettoloso via SFTP: si cambia un file di notte e si dimentica di rimettere i permessi giusti.

C’è poi un caso che mi sta particolarmente a cuore: la bonifica dopo un incidente di sicurezza. Quando ho scritto di come ho protetto i server durante l’emergenza PHP2Shell, uno dei passaggi era verificare i permessi file WordPress rimasti dopo la pulizia. Nessun file doveva restare scrivibile oltre il necessario. Lo stesso vale quando faccio la rotazione delle credenziali dopo una violazione ISPConfig. Ripristinare permessi corretti è uno dei controlli che faccio sempre, non un’opzione.

Cosa fa davvero lo script

Lo script è volutamente piccolo. Imposta le cartelle a 755, i file a 644, e protegge wp-config.php a 600 se lo trova. Vediamo perché proprio questi numeri.

#!/bin/bash

echo "Ripristino permessi nella cartella attuale..."

# Imposta tutte le cartelle a 755
find . -type d -exec chmod 755 {} +

# Imposta tutti i file a 644
find . -type f -exec chmod 644 {} +

# Proteggi wp-config.php se presente
if [ -f "wp-config.php" ]; then
  chmod 600 wp-config.php
  echo "=> wp-config.php protetto con permessi 600"
fi

echo "Fatto! Permessi aggiornati."

Lo script è fornito così com’è, a scopo informativo. L’uso è sotto la tua esclusiva responsabilità. Non mi assumo alcuna responsabilità per perdita di dati, interruzioni di servizio, o qualsiasi errore generato da un utilizzo scorretto o da un contesto diverso da quello in cui lo eseguo io stesso. Fai sempre un backup indipendente prima di eseguirlo in produzione.

Le cartelle vanno a 755, cioè rwxr-xr-x. Il proprietario può leggere, scrivere ed entrare nella cartella. Il gruppo e tutti gli altri possono solo leggerla ed entrarci. Quell’ultima “x”, sulle cartelle, non significa “eseguire” come per un programma. Su una directory vuol dire poter attraversarla. Il server web deve poter attraversare ogni cartella per arrivare al file richiesto. Ma non deve poterci scrivere dentro, se non ne è il proprietario.

I file invece vanno a 644, cioè rw-r--r--. Lettura per tutti, scrittura solo per il proprietario, nessun bit di esecuzione per nessuno. Un file .php non deve mai essere eseguibile come un binario. Viene interpretato da PHP-FPM o dal modulo del server, non lanciato direttamente dalla shell. Un file eseguibile a livello di filesystem è un segnale che qualcosa non va, non un vantaggio. Sono questi due numeri, 755 e 644, il cuore di come imposto i permessi file WordPress su ogni server che gestisco.

Il caso speciale è wp-config.php, protetto a 600, cioè rw-------. Solo il proprietario può leggerlo e scriverlo, nemmeno il gruppo. Quel file contiene le credenziali del database in chiaro, oltre alle chiavi di sicurezza di WordPress. Non c’è motivo che altri utenti del sistema, inclusi altri siti sullo stesso server condiviso, possano anche solo leggerlo.

Il dettaglio tecnico di find con il +

Chi guarda da vicino il comando find . -type d -exec chmod 755 {} + noterà quel + finale al posto del più comune \;. Non è un dettaglio stilistico. Con \;, find lancia un processo chmod separato per ogni file o cartella trovata. Su un sito con poche decine di file va bene. Ma su un hosting con centinaia di migliaia di file, tra core, plugin, temi e uploads, è diverso. Significa avviare centinaia di migliaia di processi uno dopo l’altro. Con +, invece, find raggruppa quanti più argomenti possibile. Li passa a poche chiamate di chmod, esattamente come farebbe xargs. La differenza di velocità, su un sito grande, si misura in minuti e non in secondi. Chi vuole la descrizione ufficiale può leggere la pagina man di find su man7.org, alla voce -exec command {} +.

Come lo lancio, anche da remoto

La versione che preferisco è scaricare lo script, dargli un’occhiata, e solo dopo eseguirlo. La consiglio anche a chi legge:

cd /percorso/del/sito
curl -sO https://cisilino.com/mscripts/fix_permessi.sh
cat fix_permessi.sh   # guardo cosa contiene prima di lanciarlo
chmod +x fix_permessi.sh
./fix_permessi.sh

Quando sono in fretta, su un server che conosco, uso la versione compatta. Scarico ed eseguo in sequenza, senza passaggi intermedi:

cd /percorso/del/sito && curl -sO https://cisilino.com/mscripts/fix_permessi.sh && chmod +x fix_permessi.sh && ./fix_permessi.sh

Ecco l’equivalente con wget. Utile sui server dove curl non è installato di default:

cd /percorso/del/sito && wget -q https://cisilino.com/mscripts/fix_permessi.sh && chmod +x fix_permessi.sh && ./fix_permessi.sh

Quello che non faccio mai, nemmeno di fretta, è la pipe diretta tipo curl https://... | bash. Tecnicamente funziona. Per questo script specifico il rischio è basso, perché lo conosco e lo controllo io stesso. Ma è un’abitudine che vale la pena non prendere. Eseguire alla cieca un codice scaricato al volo, senza un attimo per leggerlo, prima o poi si paga. Magari non con questo script, ma con un altro trovato in giro e meno affidabile. Un cat prima del chmod +x costa due secondi.

Dove lo script si ferma

Lo script opera su “.” in modo ricorsivo. Va lanciato dalla root del sito, non da una cartella superiore o da una sottocartella qualsiasi. Se lo lancio dalla cartella sbagliata, sistema i permessi solo di quella, oppure tocca file che non c’entrano nulla.

Non gestisce i casi particolari in cui alcune cartelle devono restare scrivibili dal gruppo del server web. Capita con wp-content/uploads su certe configurazioni, o con la cache di alcuni plugin che scrivono file a runtime. In quei casi, dopo lo script, va rimesso a mano il permesso specifico che serve. Altrimenti il plugin smette di funzionare.

Non c’è nessuna modalità dry-run, né un backup integrato dei permessi precedenti. A differenza di script più strutturati, come quello per la rotazione delle password del database, qui non c’è rete di sicurezza. Va eseguito sapendo già cosa ci si aspetta di ottenere. E va lanciato con l’utente giusto: quello proprietario dei file, non root. Altrimenti i file finiscono di proprietà di root. A seconda di come è configurato PHP-FPM, il server web potrebbe non riuscire più a leggerli.

Con questi limiti chiari in testa, è uno script che tengo a portata di mano su ogni server. Quando i permessi file WordPress vanno in confusione, in un comando torno a una base pulita. Poi sistemo a mano le eccezioni che servono davvero.

The post Permessi file WordPress rotti? Lo script che li ripristina first appeared on Matteo Cisilino.

Quando la rotazione non è più facoltativa?

Ci sono alcuni scenari che tornano a sufficienza da farmi tenere pronto un piano di rotazione. Preferisco non improvvisarne uno sotto pressione.

Un plugin o un CMS su un sito ospitato viene compromesso. Ho raccontato un caso reale su questo tipo di server in PHP2Shell: come ho protetto i server in attesa della patch, una vulnerabilità PHP che permetteva a un attaccante di piazzare una web shell prima che esistesse una patch. Una volta che una web shell viene eseguita sotto un utente di hosting, spesso può leggere il config.inc.php di quel sito. Su un box ISPConfig condiviso, quel file sta proprio accanto alle credenziali del database del pannello di controllo stesso. Non solo la credenziale che l’attaccante stava effettivamente cercando.

Un file di configurazione finisce dove non dovrebbe. Un archivio di backup lasciato in una cartella pubblica. Un repository pubblicato con un file fuori posto. Un log più leggibile di quanto chiunque intendesse. config.inc.php e mysql_clientdb.conf non hanno motivo di stare in nessuno di questi posti. Gli errori succedono comunque, compresi i miei.

Un amministratore di sistema lascia il team. Per quanto amichevole sia l’addio, le credenziali database condivise che deteneva sono credenziali di cui non mi fido più del tutto. La fiducia non si trasferisce automaticamente quando qualcuno esce dalla porta.

Un’intrusione sospetta, anche non confermata. Questo è il caso più difficile da spiegare a chi non ha mai gestito un server sotto sospetto di attacco. Non si aspetta la prova prima di agire. Si presume la compromissione e si ruota. Una rotazione non necessaria costa un pomeriggio. Una saltata, dopo una violazione reale, può costare ogni sito ospitato dal server.

Perché la rotazione delle credenziali database manuale è così incline all’errore

La prima volta che ho ruotato a mano le credenziali database di ISPConfig, ho sottovalutato quanti file fossero coinvolti. Devono tutti cambiare insieme, altrimenti qualcosa si rompe silenziosamente poche ore dopo.

C’è config.inc.php sul lato server, e una seconda copia sul lato interfaccia. Entrambe devono avere gli stessi nuovi valori. C’è mysql_clientdb.conf, che ISPConfig legge per gestire il database di ogni sito ospitato, non solo la propria manutenzione interna. Dovecot, Pure-FTPd e Postfix mantengono ciascuno una propria copia di alcune delle stesse credenziali. Mail e FTP possono smettere di autenticarsi silenziosamente se aggiorni l’utente del database e ne dimentichi anche solo uno dei tre.

Poi c’è la topologia Master/Slave che alcune delle mie installazioni usano. Un nodo Slave si autentica al database del suo Master sulla rete, con una password separata. Quella password va ruotata sul Master stesso, non solo in locale. Sbaglia la sequenza, e uno Slave può chiudersi fuori dallo stesso Master da cui dovrebbe replicare.

Niente di tutto questo è concettualmente difficile. Sono tanti file. Diversi servizi da riavviare, in un ordine sensato. Quasi nessuna tolleranza per un errore di digitazione, specialmente mentre lo fai sotto pressione, appena dopo aver trovato qualcosa che non volevi trovare. Questa combinazione è esattamente il motivo per cui la rotazione delle credenziali database continuava a sembrarmi più rischiosa a mano di quanto il compito stesso dovrebbe essere. È per questo che ho scritto reset_DB_password.sh, dopo aver vissuto il problema io stesso più di una volta.

Cosa fa davvero reset_DB_password.sh

reset_DB_password.sh rileva se il nodo è Standalone, Master o Slave. Poi esegue solo le fasi che quel ruolo richiede.

La Fase A ruota la password root locale di MySQL. È la password che ISPConfig stesso usa per gestire il database di ogni sito ospitato. Lo script aggiorna mysql_clientdb.conf per farlo corrispondere al nuovo valore.

La Fase B ruota la password dell’utente di controllo ispconfig. Aggiorna config.inc.php sia sul lato server che sul lato interfaccia. Poi aggiorna le credenziali corrispondenti dentro Dovecot, Pure-FTPd e Postfix, così mail e FTP continuano ad autenticarsi senza un passaggio manuale separato su altri tre file di configurazione.

La Fase C viene eseguita solo su uno Slave. Si connette da remoto al database del Master. Ruota lì la password dell’utente Slave, poi aggiorna dbmaster_password in locale, così la replica continua ad autenticarsi correttamente con il nuovo valore.

Dopo la Fase B, lo script offre di riavviare Dovecot, Pure-FTPd e Postfix per te. Dico quasi sempre di sì. Una rotazione delle credenziali che lascia un servizio di posta in esecuzione con la vecchia password non è finita, è solo silenziosamente rotta. Riavviare nella stessa sessione, subito dopo il cambio dei file di configurazione, mantiene tutto dentro una sola breve finestra di manutenzione invece di tre scoperte separatamente più avanti.

Backup prima che qualcosa cambi

Prima di toccare un solo file, lo script esegue una copia rsync completa di /usr/local/ispconfig/ in una cartella con timestamp. Tenta anche un mysqldump non bloccante dei database mysql e dbispconfig. Non bloccante di proposito: preferisco finire una rotazione delle credenziali database piuttosto che restare in attesa di un dump bloccato per qualche motivo non collegato. Ogni file di configurazione che modifica riceve prima una propria copia .bak, prima che qualsiasi stringa al suo interno venga sostituita.

Niente di tutto questo sostituisce una strategia di backup indipendente. Continuo a fare uno snapshot separato, o un backup completo, prima di eseguire questo script su qualsiasi server che conta davvero. Il disclaimer dello script stesso dice la stessa cosa, in modo più diretto di quanto abbia appena fatto io.

Dry run prima, sempre

Ogni fase chiede conferma prima di cambiare qualcosa. –dry-run simula un’intera esecuzione senza toccare un solo file. Uso il dry-run prima su ogni server, ogni volta. Anche su quelli su cui ho già ruotato le credenziali, e penso di conoscere bene. –skip-local-root salta la Fase A, per quando serve ruotare solo la password dell’utente di controllo. –role=master o –role=slave forzano il rilevamento automatico, per il raro caso in cui non legga correttamente da solo la topologia di un server.

Le password che genera sono di 32 caratteri, solo lettere e cifre. Lunghe abbastanza da resistere a un tentativo di indovinare. Semplici abbastanza che i parser di MySQL e PHP non si inceppino mai su un simbolo fuori posto in una stringa di connessione. Ho testato lo script su ISPConfig 3.3.1p1. Non l’ho eseguito contro rami più vecchi o più nuovi. Non darei per scontato un comportamento identico lì, senza prima verificarlo io stesso.

Il ruolo di un nodo non è sempre ovvio a colpo d’occhio, specialmente su un server che hai ereditato invece di costruire tu stesso. È per questo che esiste –role, e perché l’output del dry-run merita di essere letto riga per riga la prima volta, non scorso velocemente. Preferirei passare due minuti a confermare che uno Slave è davvero uno Slave, piuttosto che scoprirlo nel modo peggiore a metà rotazione.

Cosa ti direi prima che tu lo esegua

Avviso: lo script è fornito così com’è, a scopo informativo. L’uso è sotto la tua esclusiva responsabilità: non mi assumo alcuna responsabilità per perdita di dati, interruzioni di servizio, o qualsiasi errore generato da un utilizzo scorretto o da un contesto diverso da quello in cui lo eseguo io stesso. Fai sempre un backup indipendente o uno snapshot VM prima di eseguirlo in produzione, indipendentemente da ciò che il passaggio di backup dello script già catturi per te.

È software libero. Puoi ridistribuirlo e modificarlo, con attribuzione a me come autore originale. Il codice sorgente di reset_DB_password.sh, e il resto della collezione ispconfig-fast-tools, è su GitHub su github.com/matteocisilino/ispconfig-fast-tools.

La rotazione delle credenziali database è un’abitudine, non un lavoro di pulizia

La rotazione delle credenziali database dopo una violazione confermata è semplicemente una risposta agli incidenti competente. La maggior parte degli amministratori lo farebbe senza bisogno di sentirlo due volte. L’abitudine più difficile è farlo dopo una violazione solo sospettata, prima che ci sia una prova. È l’unica versione del piano che limita davvero il danno, mentre è ancora limitabile. Uno script che esegue le fasi giuste per il ruolo di un server, fa prima i propri backup, e mi permette di simulare l’intera esecuzione prima di toccare qualcosa di reale. È quello che rende l’abitudine praticabile un martedì sera, invece che teorica in un articolo di blog.

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix e gli altri nomi citati sono marchi dei rispettivi proprietari. Sono usati solo per identificare i prodotti.

The post Rotazione delle credenziali database dopo una violazione ISPConfig first appeared on Matteo Cisilino.

Cos’è MPTCP e perché riguarda anche chi non lo usa

Multipath TCP (MPTCP) è lo standard RFC 8684. Estende il TCP classico per far viaggiare una singola connessione su più percorsi di rete insieme. Un telefono può usare WiFi e rete cellulare nello stesso momento, per la stessa connessione. Un server con più interfacce può fare lo stesso, per ridondanza o per somma di banda. Apple lo usa in produzione fin da iOS 7, nel 2013, per Siri: è il caso d’uso reale più noto. Alcuni operatori mobili, per esempio in Corea del Sud, lo sfruttano per il bonding WiFi/LTE. Diversi data center lo adottano per il multi-homing tra uplink diversi. Nel kernel Linux mainline c’è dal 5.6.

Il punto che mi ha fatto alzare un sopracciglio è un altro. Dalla versione 1.24, i programmi scritti in Go richiedono MPTCP di default per i socket in ascolto. Il Go Security Team l’ha confermato il 29 ottobre. Insieme, ha dato un avviso scomodo: il bug di cui parliamo oggi non è specifico di MPTCP. Un sistema senza listener MPTCP attivi può restare comunque esposto ad attacchi simili. Il codice vulnerabile è nel path TCP IPv4 generico, non in un modulo opzionale. Si può disattivare MPTCP programma per programma, con la variabile GODEBUG=multipathtcp=0 a runtime. Ma il Go Security Team definisce questa mitigazione “fragile”: basta un solo listener MPTCP rimasto esposto per vanificarla. Nessuno ha dimostrato che ogni exploit funzionante dipenda davvero da MPTCP. Ecco perché il codice MPTCP resta superficie di attacco, anche se nel tuo stack non lo attivi mai consapevolmente: basta che sia compilato nel kernel e raggiungibile.

Il progetto MPTCP stesso dichiara, sulla propria pagina, che le principali distribuzioni Linux correnti spediscono il kernel con il supporto MPTCP compilato di default (CONFIG_MPTCP=y). Nomina esplicitamente Debian, Ubuntu, RHEL e Fedora. È una dichiarazione del progetto stesso, non una verifica indipendente distro per distro, ma il concetto resta valido: il supporto è acceso a livello di kernel, non “opt-in” a livello di sistema operativo. Solo la negoziazione per singola connessione resta a carico dell’applicazione.

La vulnerabilità kernel Linux CVE-2026-98432 in breve

Il CVE team del kernel Linux ha pubblicato la CVE-2026-98432 il 15 ottobre 2026. Il fix upstream era già stato applicato dieci giorni prima, il 5 ottobre. Capita spesso che la pubblicazione segua il commit con un certo ritardo. Il punteggio CVSS di 9,8 (critico) è arrivato solo il 24 ottobre, nove giorni dopo la pubblicazione della CVE.

Il problema sta nella gestione dell’handshake TCP per IPv4, in particolare nella funzione tcp_v4_syn_recv_sock(). Quando una connessione viene creata, le opzioni IP del pacchetto SYN vengono passate dal request socket in attesa al nuovo socket. Per esempio Record Route o Timestamp, se il client le include in un SYN costruito ad arte. Il problema è che vengono passate per riferimento, non per copia, e senza il lock del listener. Secondo l’analisi tecnica della patch, le strutture coinvolte si chiamano inet_opt e ireq_opt. Una seconda CPU può liberare quel buffer con kfree(), chiamato da inet_sock_destruct() o da tcp_v4_reqsk_destructor(). Nel frattempo una prima CPU lo sta ancora leggendo in ip_options_build(), per costruire il SYNACK. È un classico use-after-free causato da una race condition. Il percorso IPv6 equivalente, tcp_v6_syn_recv_sock(), copia le opzioni invece di passarle per riferimento: non è vulnerabile alla race principale. Esiste anche una seconda via d’attacco, tramite la migrazione dei request-socket: net.ipv4.tcp_migrate_req=1 oppure un programma eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Entrambe sono disattivate di default.

Il bug è remoto e non richiede autenticazione né interazione dell’utente, secondo la valutazione del kernel team. È presente dalla versione 4.4 del kernel. Il fix è firmato da Eric Dumazet, segnalato da Xinyang Ge di Anthropic. Sposta la liberazione della memoria a dopo un grace period RCU, con kfree_rcu(): così nessuna CPU può più leggere un buffer già liberato. Le versioni stabili corrette sono 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e la mainline dalla 7.3-rc7.

Punteggi CVSS discordanti: non tutti i vendor sono d’accordo

Qui la storia si complica. Il kernel CVE team e Ubuntu valutano la complessità di attacco come bassa, e danno 9,8 (critico). Oracle e SUSE danno invece 8,1 (importante): stesso vettore CVSS, ma complessità di attacco alta. Red Hat, curiosamente, ha due valutazioni che non coincidono tra loro. La pagina CVE pubblica mostra “Moderate, 5.9”. Il file di advisory leggibile da macchina, aggiornato il 29 ottobre, mostra invece “Important, 8.1”, con impatto alto su confidenzialità e integrità. Lo stesso giorno il bug tracker interno di Red Hat ha alzato la severità da medium a high. Amazon, dal suo lato, assegna 7,0. Al momento in cui scrivo, l’NVD non ha ancora pubblicato un punteggio proprio.

Vale la pena dirlo con onestà. Questa incongruenza interna a Red Hat non è un dettaglio che ho dedotto io: è riportata così dall’articolo originale di The Hacker News, la mia fonte principale per questi dati. Non è la prima volta che un vendor pubblica due numeri diversi per lo stesso bug, su canali diversi. Ma qui il salto da “moderato” a “importante” nello stesso giorno dice molto. Anche per chi scrive il codice, stimare con certezza lo sfruttabilità reale di una race condition nel kernel è difficile.

Stato delle patch: Debian già corretto, altri ancora no

Questo è il punto che mi riguarda più da vicino: gli hosting che gestisco girano su Debian stable. E qui i fatti parlano chiaro, senza bisogno di aggiungere enfasi: Debian ha già corretto questa vulnerabilità kernel Linux, sia su trixie che su bookworm. Debian trixie (stable) è stata corretta il 16 ottobre 2026, con il pacchetto linux 6.12.113-1, avviso DSA-6568-1. Debian 12 (bookworm) è stata corretta in due passaggi: il 17 e il 22 ottobre 2026, con linux 6.1.190-1 (avviso DLA-4841-1) e linux-6.12 6.12.113-1~deb12u1 (avviso DLA-4850-1). Nella propria tabella di tracciamento, Debian non elenca un punteggio CVSS separato per questa CVE. Si limita a segnare lo stato di fix per ogni release: è l’informazione che conta davvero, per chi deve decidere se riavviare un server.

Confrontare questo con lo stato di altre distribuzioni molto diffuse aiuta a dare peso alla cosa. Al 30 ottobre, Red Hat ha aggiornato lo stato di RHEL 8, 9, 10 e OpenShift 4. Prima era “fix deferred” (segnato il 29 ottobre), ora è “affected”. Nessuna data di rilascio è stata comunicata. Ubuntu, su tutte le versioni supportate (22.04, 24.04, 26.04, 26.10), risulta ancora “in lavorazione”, senza una data. Ubuntu 16.04, 18.04 e 20.04 risultano vulnerabili, senza nemmeno un fix elencato. SUSE Linux Enterprise Server, dalla SP4 alla SP7 più la 16.0, è nella stessa situazione. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 e Amazon Linux 2023 risultano invece già corretti. RHEL 7 non è affetto: il percorso di codice vulnerabile non è mai stato distribuito su quella release.

Non lo dico per fare concorrenza a Ubuntu o RHEL. Restano distribuzioni serie, con processi di sicurezza robusti. Lo dico perché su questo singolo bug, in questa finestra temporale, i fatti sono questi: chi si affida a hosting basati su Debian stable ha già il fix installato. Su altre distribuzioni molto usate, invece, il server resta esposto per un periodo indefinito. È un vantaggio concreto, verificabile guardando le date. Non è un’opinione sul progetto Debian in generale.

L’exploit (riportato, non verificato in modo indipendente) di Anthropic

La parte più insolita di questa storia riguarda Anthropic, l’azienda che per prima ha segnalato il bug tramite Xinyang Ge. Secondo i report di settore, uno dei suoi modelli AI interni, non rilasciato pubblicamente, ha costruito da solo un exploit root funzionante. Partendo solo dalla patch e dal report come prompt. L’attacco in due fasi funzionerebbe così. Nella prima fase, la race fa inviare all’attaccante byte extra dalla risposta del kernel. Da lì recupera un indirizzo kernel, per disinnescare KASLR. Nella seconda fase, lo stesso bug causerebbe un overflow di buffer. Sovrascrive un puntatore di callback con l’indirizzo di un payload già piazzato in memoria kernel dall’attaccante. Quando il kernel chiama quel puntatore, il payload esegue un comando shell a scelta come root. Una race persa farebbe fallire solo quel singolo tentativo di connessione, senza crashare il sistema: quindi sarebbero possibili tentativi ripetuti. Nel test descritto da Anthropic: 48 minuti per rubare l’indirizzo kernel, altri 5 minuti per arrivare all’esecuzione di comandi.

Red Hat dice che un attaccante remoto che raggiunge un servizio TCP esposto può in generale innescare la race. L’exploit root descritto da Anthropic, però, avrebbe preso di mira specificamente server con un listener multipath TCP attivo. Il post di Anthropic non chiarisce se un server senza MPTCP sia sfruttabile allo stesso modo. Né il record CVE né il fix upstream menzionano MPTCP in nessun punto. È la stampa di settore, non una fonte primaria, a riportare questo legame: lo scrivo quindi con lo scetticismo che merita, non come un fatto accertato al cento per cento. Anthropic non ha pubblicato il codice dell’exploit, né la versione esatta del kernel usata, né la configurazione del server target. Un’altra società, Innora, ha pubblicato un’analisi della causa radice, con un ambiente di riproduzione QEMU. Ha dichiarato che non rilascerà un exploit armato nel breve termine. Al momento non ci sono prove di sfruttamento reale da parte di vendor o CERT. Il bug non è nel catalogo CISA KEV, secondo la copia aggiornata da CIRCL del Lussemburgo al 28 ottobre.

Cosa fare adesso sui tuoi server

Nessun vendor ha pubblicato un workaround ufficialmente sanzionato per questa vulnerabilità kernel Linux. Red Hat dice esplicitamente che nessuna delle misure circolate finora raggiunge il suo standard di facilità di deploy e di stabilità. La mitigazione primaria resta applicare il kernel corretto e riavviare, quando la patch è disponibile per la tua distribuzione. Su Debian lo è già. Su RHEL e Ubuntu ancora no, al momento in cui scrivo.

Come difesa in profondità, non come soluzione definitiva, ha senso fare alcune cose. Verificare che net.ipv4.tcp_migrate_req sia impostato a 0. Controllare che non ci siano programmi eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE caricati. Valutare un filtraggio dei pacchetti IPv4 in ingresso con opzioni Record Route o Timestamp. Monitorare eventuali crash che citano ip_options_build, ip_build_and_send_pkt o skb_under_panic. Fare l’inventario di eventuali listener MPTCP esposti, evitando di lasciarli raggiungibili senza motivo. Se gestisci anche servizi contro attacchi applicativi più comuni, su come ho protetto i server in attesa della patch per PHP2Shell trovi lo stesso approccio: mitigare quello che si può, mentre si aspetta il fix definitivo, senza promettere protezioni che non esistono.

Per chi mi chiede se aggiornare subito: se usi Debian stable, il kernel corretto è già nei repository di sicurezza. L’aggiornamento è semplice, e la finestra di esposizione è già chiusa. Se usi altre distribuzioni, oggi non c’è ancora una patch da installare. Vale la pena seguire da vicino gli avvisi del tuo vendor nei prossimi giorni: la situazione cambia rapidamente.

Fonti: The Hacker News, Debian Security Tracker e il commit del fix. Debian, Red Hat, Ubuntu e gli altri nomi citati sono marchi dei rispettivi proprietari.

The post Vulnerabilità kernel Linux: un use-after-free nel TCP IPv4 first appeared on Matteo Cisilino.

Perché controllo il log email WordPress prima dei log del server

Il caso tipico è sempre lo stesso. Un modulo di contatto che “non arriva”. Un cliente che non riceve l’email di reset password. Un ordine che resta senza conferma. Senza un log a portata di mano, la prima ipotesi è la cartella spam. Poi i log del server SMTP. Poi magari il firewall. Con FluentSMTP salto quei passaggi. Vedo subito se WordPress ha davvero provato a spedire quell’email. A chi, quando, con quale risposta del server di invio.

FluentSMTP registra ogni chiamata a wp_mail(). Non solo le email dei plugin di terze parti, anche quelle generate dal core: notifiche di nuovo utente, promemoria di aggiornamento, avvisi di errore. Per ogni invio il log mostra mittente, destinatario, oggetto, intestazioni complete, corpo del messaggio. E la risposta del provider SMTP o dell’API usata. Se un’email è finita in errore, quella risposta del server è lì. Non devo indovinarla.

Cosa trovo davvero nel registro degli invii

Il plugin supporta decine di connettori: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Anche Google Workspace e Microsoft 365 via OAuth, oltre al classico SMTP generico. Sui siti che gestisco uso quasi sempre SMTP autenticato con il dominio del cliente. Qualche volta un’API dedicata, quando il volume di email cresce. In entrambi i casi il log email WordPress non cambia. Ogni riga ha uno stato, inviata o fallita. C’è un pulsante per rivedere il contenuto o rispedire il messaggio, senza che l’utente debba rifare l’azione che l’ha generato.

Il rinvio manuale è la funzione che uso più spesso. Un modulo compilato due volte perché “non arrivava” diventa un clic sul log. Non una nuova segnalazione al cliente. Per i fallimenti ripetuti ho attivato le notifiche su Telegram. Appena una connessione smette di funzionare, lo so prima che me lo scriva qualcuno. Invece di scoprirlo da un ticket di supporto.

Il log non riguarda solo le notifiche dirette a me o al cliente che amministra il sito. Finisce lì ogni email in uscita generata dal sito verso terzi: la conferma d’ordine che un negozio online manda al cliente finale, la ricevuta di un pagamento, la notifica di spedizione. Se quella conferma non arriva, la vedo nel log email WordPress esattamente come una notifica interna, con lo stesso pulsante per rispedirla al destinatario giusto senza fargli ripetere l’acquisto.

Come configuro FluentSMTP sui siti che gestisco

Dopo aver collegato il connettore giusto, cambio la conservazione del log. Di default resta attivo a lungo. Io lo porto a 30-60 giorni, in base al traffico del sito. Serve per risalire a un problema segnalato in ritardo. Senza riempire il database di righe che non consulterò mai. Attivo poi almeno un canale di notifica per i fallimenti, Telegram o Slack secondo il cliente. Il log da solo non avvisa nessuno: va aperto per essere letto.

Sui siti con form di contatto uso anche Cisilino Site Defense Network per il blocco dei bot. Meno spam in ingresso significa meno email generate dai moduli. Il log resta più leggibile, con meno rumore da filtrare quando cerco il messaggio giusto.

Le credenziali SMTP non restano in chiaro nel database

Un dettaglio che controllo sempre prima di salvare una connessione: dove finiscono le credenziali. FluentSMTP le cifra di default con le chiavi SALT di WordPress, quelle già presenti in wp-config.php per sicurezza delle sessioni. Si può disattivare la cifratura, ma il plugin stesso lo segnala come sconsigliato. Sui siti che gestisco preferisco un’altra opzione: salvare la password API o SMTP direttamente in wp-config.php, fuori dal database, definendo le costanti prima che il plugin le legga. Così anche un dump del database o un accesso non autorizzato al pannello non espone la chiave del provider di invio. È lo stesso principio che applico altrove: meno segreti nel database, meglio è.

Più connessioni insieme, non solo una alla volta

FluentSMTP permette di configurare più connessioni insieme, non solo una alla volta. Su un sito imposto quella predefinita e ne aggiungo una seconda come riserva: se il primo provider non risponde, l’invio passa automaticamente alla connessione di riserva, senza che io debba intervenire. La scelta della connessione dipende dall’indirizzo del mittente: ogni connessione ha il suo “From”, il resto passa per quella predefinita, con la riserva pronta solo se la predefinita fallisce davvero (un errore del provider, non un’email finita in spam). È una delle ragioni per cui lo preferisco a un singolo SMTP senza alternative: se SendGrid o Amazon SES hanno un problema per qualche ora, il sito continua comunque a spedire, e lo vedo subito nel log email WordPress. Tutto incluso nella versione gratuita, senza una versione pro a pagamento: si paga solo il provider di invio scelto, non il plugin.

Un controllo di salute ogni giorno, non solo quando qualcosa si rompe

Oltre al log riga per riga, FluentSMTP fa un controllo di salute della connessione ogni giorno, in automatico. Se il provider smette di rispondere, l’avviso arriva prima che un cliente mi scriva “il sito non manda più email”. Lo stesso pannello mostra un grafico con i totali giornalieri di invii riusciti e falliti: utile per capire a colpo d’occhio se un calo è normale o è il sintomo di qualcosa che si sta rompendo, senza dover aprire il log email WordPress riga per riga ogni volta. C’è anche un riepilogo periodico via email, con i totali della settimana: non è un avviso di errore, è un bollettino che leggo di sfuggita per sapere se il volume di invii è nella norma.

Per chi, come me, gestisce più siti da riga di comando, FluentSMTP espone anche dei comandi WP-CLI: un test di invio, un controllo di salute della connessione, le statistiche e la pulizia dei log vecchi. Li uso negli stessi script che già girano sui server per altri controlli di manutenzione, senza dover aprire il pannello di ogni sito uno per uno.

I limiti onesti del log email WordPress

Non è una soluzione magica. La conservazione è basata sui giorni, non su un numero massimo di righe. Su un sito con molto traffico transazionale la tabella del log può crescere in fretta. Conviene tenerla sotto controllo, o impostare una conservazione più breve. Le notifiche di fallimento arrivano solo sui canali di chat configurati, non per email. Ha senso: un’email che avvisa di un’email fallita rischia di fallire a sua volta. Ma va saputo prima di contarci.

Infine il log registra cosa è successo lato WordPress e lato provider. Non garantisce la consegna nella casella del destinatario. Se un’email è segnata come inviata ma finisce in spam, è un problema di reputazione del dominio o di configurazione SPF/DKIM. Non qualcosa che un log può risolvere da solo. Resta comunque il primo posto dove guardo, prima di qualsiasi altra verifica.

Il plugin è gratuito e open source. Pagina ufficiale su wordpress.org, senza funzioni bloccate dietro una versione pro. Per chi gestisce anche un solo sito con un modulo di contatto, vale la pena installarlo solo per il log email WordPress. La prima volta che risolve un “non ho ricevuto l’email” in un minuto invece che in mezz’ora, si è ripagato.

The post Log email WordPress: perché lo controllo con FluentSMTP first appeared on Matteo Cisilino.

Dove si trova

Apri la voce Plugin > Plugin installati (punto 1 dell’immagine). Nella riga di Cisilino Site Defense Network (punto 3) trovi il link Disattiva. Dopo la disattivazione (punto 4) la stessa riga mostra Attiva ed Elimina.

Cosa succede alla disattivazione

Disattivare il plugin lo ferma senza toccare i dati. Alla disattivazione il plugin fa quattro cose.

1. registra l’evento “Plugin disattivato su questo sito” e prova a consegnarlo al pannello, se è configurato.
2. cancella le tre attività pianificate.
3. svuota entrambi i blocchi di .htaccess, quello degli IP bloccati e quello dell’hardening.
4. aggiorna le regole di riscrittura di WordPress.

Attenzione: da disattivato non resta in vigore nessuna regola. Gli IP bloccati tornano a poter accedere e l’hardening non è più applicato. Il plugin non è nemmeno caricato, quindi non agiscono le altre protezioni. Smettono anche gli header di sicurezza, ma un browser che ha già ricevuto HSTS lo ricorda per il tempo impostato.

Il database resta intatto. Se riattivi il plugin, i blocchi di .htaccess vengono ricostruiti e trovi le impostazioni come le avevi lasciate.

Come disinstallare il plugin

Per disinstallare il plugin devi premere Elimina in Plugin installati, dopo averlo disattivato. Prima di farlo, segui questi passi.

1. Nella scheda Registro attività controlla che la riga “in attesa di invio al pannello” sia a zero, se usi il pannello.
2. Nella scheda Log di debug, scarica i file che ti servono. Poi, se vuoi, premi Elimina tutti i file.
3. Fai una copia di sicurezza, se non l’hai già fatta.
4. Disattiva il plugin e premi Elimina.

Cosa viene rimosso e cosa resta

Quando scegli di disinstallare il plugin, all’inizio lui registra “Plugin disinstallato da questo sito: dati locali rimossi” e prova a consegnarlo al pannello. Poi cancella, comunque sia andata la consegna.

Viene rimosso quanto segue.

• le quattro tabelle csdn_events, csdn_overrides, csdn_rate_hits e csdn_activity.
• quasi tutte le opzioni il cui nome inizia per csdn_, comprese le credenziali del pannello, la whitelist e le impostazioni delle schede. Ne restano tre, elencate più sotto.
• il dato di sospensione del rate limiting su tutti gli utenti.
• i dati temporanei del plugin.
• le regole dei due blocchi del plugin in .htaccess e le regole di riscrittura. I marcatori # BEGIN e # END restano nel file, vuoti.

Resta invece quanto segue.

• i file del log di debug nella cartella csdn-debug-* dentro uploads, perché sono dati tuoi: cancellali a mano oppure con il pulsante Elimina tutti i file prima di disinstallare.
• lo storico già consegnato al pannello, che si trova sul pannello e non sul tuo sito.
• le righe di .htaccess che stanno fuori dai marcatori del plugin.
• tre opzioni minori: csdn_registration_lock (la policy di Registrazione utenti), csdn_remote_ban_reasons (motivi dei blocchi ricevuti) e csdn_trigger_token (token ricevuto dal pannello). Restano anche il dato utente csdn_registration_blocked_at, se presente, e i dati temporanei csdn_rl_block_*, che scadono da soli. Si possono togliere a mano dal database.

Attenzione: disinstallare il plugin cancella anche il registro attività locale. Le righe non ancora consegnate al pannello, se il pannello non risponde, si perdono.

Dati personali trattati dal plugin

Il plugin tiene i dati sul tuo sito, nel database. Mai la password. Ecco cosa tratta.

• Login falliti: indirizzo IP, nome utente provato, numero di tentativi, prima e ultima occorrenza, stato di blocco. Non c’è una cancellazione automatica: restano nel database finché non disinstalli il plugin.
• Registro attività: data e ora, utente WordPress (id, login, ruolo), IP, tipo di azione, oggetto coinvolto (per i contenuti, il titolo) e una breve descrizione. In alcuni casi aggiunge dettagli: per un nuovo utente l’email e i ruoli, per una modifica di profilo il valore precedente e quello nuovo di email, login, nome visualizzato e sito web. Non salva il contenuto di articoli, commenti o file. Per le opzioni con nome sospetto, come chiavi o token, registra solo che sono cambiate.
• Rate limiting: IP e tipo di invio degli ospiti, conservati un giorno. Le sospensioni degli autori stanno nei dati dell’utente.
• Override IP, whitelist e blacklist ricevuta.
• Log di debug, se lo accendi: file che possono contenere percorsi e frammenti di dati.

Il registro locale tiene di default 30 giorni e al massimo 500 righe. Puoi cambiare entrambi i valori nella scheda Registro attività.

Cosa esce dal sito

Solo se colleghi il pannello. Ogni 15 minuti il plugin invia i login falliti: IP, nome utente, esito “failed” e data. Ne manda fino a 200 per volta. Aggiunge il customer code e l’URL del sito. Riceve gli IP bloccati. Il registro attività, con i dettagli sopra, viene inviato di norma subito, a fine richiesta, e ciò che resta in coda parte col giro dei 15 minuti. Parte solo se sono attivi sia il registro sia l’opzione “Invia le attività al pannello”. Gli override manuali non vengono mai inviati.

Cosa scrivere nell’informativa privacy

Finché non decidi di disinstallare il plugin, nell’informativa del sito indica almeno questi punti.

• che il sito registra IP e nome utente dei tentativi di accesso falliti, per ragioni di sicurezza.
• che tiene un registro delle azioni degli utenti, con IP, e per quanti giorni lo conserva.
• che, se hai collegato il pannello, alcuni di questi dati vengono inviati al servizio esterno.
• chi è il titolare e come gli utenti possono esercitare i loro diritti.

Adatta il testo alla tua situazione, con il tuo consulente se ne hai uno: il manuale non sostituisce un parere legale. Per le basi sui plugin la guida ufficiale di WordPress spiega anche la differenza tra disattivare ed eliminare.

Se qualcosa non va

Se dopo la disattivazione il sito dà errore, controlla .htaccess via FTP e guarda il capitolo Risoluzione dei problemi e domande frequenti. Se hai deciso di disinstallare il plugin per errore, i dati locali non tornano: serve una copia di sicurezza del sito.

Capitolo precedente: Risoluzione dei problemi e domande frequenti. Torna all’indice con l’introduzione al manuale CSDN.

The post Disattivazione, disinstallazione e dati personali first appeared on Matteo Cisilino.

Risoluzione problemi: da dove cominciare

Prima di cercare la risposta esatta, passa in rassegna questo elenco di controllo.

1. Riesci ancora ad aprire wp-admin? Se sì, quasi tutto si risolve dalla pagina Impostazioni del plugin.
2. Leggi gli avvisi in alto. Il plugin spiega l’esito delle azioni con messaggi in riquadri colorati.
3. Ricorda l’ultima cosa che hai cambiato: una regola di hardening, una policy, un limite.
4. Se esiste un pulsante Verifica ora o Verifica adesso, usalo prima di tirare a indovinare.
5. Se non entri più nel sito, prepara l’accesso FTP o il file manager dell’hosting.

Accessi e blocchi

Mi sono bloccato da solo: che cosa faccio?

Se hai ancora accesso a WordPress, per esempio dal telefono con la rete mobile, apri la scheda IP bloccati. Cerca il tuo IP e premi Sblocca. Se il tuo IP non è in elenco ma sei bloccato (può venire dalla lista di sicurezza opzionale), vai nella scheda Generale, sezione “Override locali IP”: inserisci l’IP, scegli “Sblocca sempre (unban)” e premi Salva override. Poi, nella scheda Generale, premi Aggiungi alla whitelist.

Se sei bloccato anche dal sito, e vedi un errore 403, entra via FTP e apri .htaccess. Togli la riga con il tuo IP, oppure l’intero blocco tra # BEGIN Cisilino Site Defense Network e # END Cisilino Site Defense Network.

Attenzione: la modifica a mano è temporanea. Il blocco viene riscritto dalla stessa fonte al prossimo evento: un login fallito, una sincronizzazione o il giro ogni 15 minuti. Appena sei dentro, usa Sblocca e la whitelist.

Perché la whitelist non mi ha sbloccato?

La whitelist evita solo che i login falliti vengano contati. Non toglie i blocchi già presenti. Per togliere un blocco serve Sblocca, che crea un override permanente di sblocco su questo sito.

Un utente legittimo è stato bloccato

Il contatore dei tentativi è cumulativo per IP e non si azzera da solo. Anche errori sparsi in settimane possono arrivare alla soglia, che di default è 10. Sblocca l’IP e mettilo in whitelist, oppure alza la soglia in Impostazioni remote, dove il campo è “Soglia blocco locale (tentativi falliti)”.

Il blocco di un IP non finisce mai

Un blocco locale non scade. Un blocco manuale scade con la durata scelta, da 1 ora a 7 giorni. Se hai scelto “Permanente (finché non lo rimuovi)”, non scade. Un blocco ricevuto dal pannello sparisce quando il pannello lo toglie dalla lista. Uno sblocco a tempo, scadendo, fa tornare il blocco se la fonte originale è ancora lì. Per uno sblocco definitivo usa Sblocca, che è permanente.

Dietro un proxy o una CDN i blocchi sono strani

Il plugin legge l’IP solo da REMOTE_ADDR e ignora l’header X-Forwarded-For, perché si può falsificare. Guarda la frase “Il tuo IP attuale è …” sotto il campo Indirizzo IP della scheda Generale. Se non è il tuo IP pubblico, il plugin sta vedendo l’indirizzo del proxy. In quel caso evita di bloccare o mettere in whitelist quell’indirizzo, finché non hai chiarito la situazione con chi gestisce il proxy.

Errori dopo le regole in .htaccess

Questa parte della risoluzione problemi riguarda le regole scritte nel file del server.

Il sito dà errore 500 dopo aver salvato l’hardening

Il plugin non crea una copia di .htaccess e non controlla la sintassi dopo la scrittura. Un errore, o una regola che il server non accetta, si vede subito come errore 500.

1. Entra via FTP o dal file manager.
2. Fai una copia di .htaccess.
3. Elimina il blocco tra # BEGIN Cisilino Site Defense Network - Hardening e # END Cisilino Site Defense Network - Hardening.
4. Ricarica il sito, poi correggi le impostazioni nella scheda Hardening / IDS.

Il blocco dell’hardening viene riscritto solo quando salvi la scheda o riattivi il plugin, non dal giro ogni 15 minuti. La tua modifica a mano quindi resta.

Ho scritto un percorso personalizzato e tutto il sito dà 403

Nella casella dei percorsi personalizzati ogni riga è testo letterale, senza jolly. La regola blocca ogni indirizzo che contiene quella stringa. Scrivere / o wp blocca tutto, compreso wp-admin. Togli via FTP il blocco dell’hardening, come sopra. Poi, nella scheda Hardening / IDS, correggi o svuota la casella “Percorsi personalizzati da bloccare” e salva. Se non la correggi, un nuovo salvataggio o una riattivazione del plugin riscrive la regola e il sito torna a dare 403.

Compare “Impostazioni salvate, ma la scrittura in .htaccess è fallita”

Il file .htaccess non è scrivibile: controlla i permessi. Le regole di quel blocco non sono attive. Restano invece attivi i due interruttori che agiscono in PHP, cioè XML-RPC e ?author=N.

Il test dice che il blocco PHP in uploads non funziona

Nella scheda Test, il riquadro “Verifica blocco esecuzione PHP in uploads” segnala se il file di prova è stato eseguito. Controlla che l’hosting permetta .htaccess in quella cartella e che non esista un blocco <Directory> più specifico. Su nginx le regole non hanno effetto. La regola copre solo la cartella uploads standard.

Un plugin o il tema hanno smesso di funzionare

Spegni l’ultima regola che hai attivato e salva. I casi più comuni: il blocco del PHP in uploads rompe i plugin che ci scrivono file PHP; la disabilitazione di XML-RPC ferma app e funzioni remote; il blocco dei caricamenti eseguibili rifiuta anche file come .svg.

Utenti, autori e visitatori

Un autore non può più pubblicare: “il tuo account è sospeso”

Il rate limiting ha visto troppi contenuti creati in poco tempo. Di default il limite è 150 contenuti in 300 secondi, con sospensione di 3600 secondi. Dalla scheda Rate limiting, nella tabella degli utenti sospesi, premi Revoca sospensione. Altrimenti aspetta la scadenza.

Spegnere “Rate limit attivo” non toglie una sospensione già in corso. Prima di un’importazione grande alza il limite N o disattiva il paletto.

Un visitatore vede “Troppi invii”

Un ospite ha inviato troppi commenti o moduli in poco tempo: di default più di 2 in 60 secondi, e il blocco dura 3600 secondi. Il blocco è per IP, quindi può colpire più persone nello stesso ufficio. Alza il valore N della sezione visitatori. Non esiste un elenco di eccezioni.

Non riesco a creare un utente editor o amministratore

È voluto. La policy predefinita di Registrazione utenti è “Solo ruoli a basso privilegio” e non fa eccezioni, nemmeno per te. Passa temporaneamente a “Nessuna restrizione”, crea l’utente, poi torna indietro. Con “Nessuna registrazione (esclusiva)” nessuno può creare utenti. Controlla anche il ruolo predefinito in Impostazioni > Generali di WordPress: se è un ruolo vietato, le registrazioni vengono respinte.

Collegamento al pannello

Il collegamento al pannello non risulta

Lo stato è nel riquadro “Stato collegamento al pannello:” in cima alla scheda Impostazioni remote. Se il riquadro manca, i campi erano incompleti: servono Customer code, Chiave API e URL del pannello. Dopo “Salva e verifica collegamento” non compare un banner a parte.

• “URL del pannello non sicuro: serve https …”: l’indirizzo deve iniziare con https. Il plugin rifiuta anche di salvare un URL http.
• “Autenticazione rifiutata dal pannello: customer_code o chiave API errati.”: ricontrolla i due valori.
• “Impossibile raggiungere il pannello: …”: problema di rete, DNS o certificato.
• “Risposta del pannello non valida (non è JSON).”: l’indirizzo non punta al pannello giusto.

Se il pannello non risponde, la protezione locale continua e i dati in coda vengono inviati al giro dopo. Il plugin funziona anche senza pannello.

Le attività non arrivano al pannello

Nella scheda Registro attività guarda la tabella di diagnostica e la riga “in attesa di invio al pannello”. Premi Prova a inviare adesso: l’esito compare nella diagnostica. Il tetto di righe, di default 500, cancella le più vecchie anche se non sono state consegnate.

Log di debug, integrità e header

Il log di debug non si accende

Hai due messaggi possibili. “la cartella dei caricamenti non è scrivibile”: sistema i permessi di uploads. “i file della sua cartella risultano raggiungibili da internet”: probabile server senza .htaccess, come nginx. Blocca l’accesso alla cartella csdn-debug-* nella configurazione del server e riprova. Se il log si è fermato per il tetto di 200 MB, scarica o elimina i file e riaccendilo.

L’integrità segna “i file del plugin non corrispondono”

Se hai modificato a mano un file del plugin, è normale. Altrimenti tratta il sito come potenzialmente compromesso: reinstalla il plugin da una copia attendibile e controlla il resto. Se il messaggio dice che non c’è alcun riferimento, riattiva il plugin per scattare una nuova fotografia.

HSTS non si attiva, o non si spegne

Per attivarlo devi aprire le impostazioni del plugin in https, altrimenti compare “HSTS NON è stato attivato”. Salva sempre da una pagina https. Spegnere la casella ferma l’invio dell’header, ma i browser che l’hanno già ricevuto lo ricordano a lungo.

Se non trovi la risposta

Se la risoluzione problemi non basta, accendi il log di debug, riproduci il problema e leggi la voce. Poi apri una discussione sul forum di supporto del plugin: è il posto dove ricevere aiuto e vedere i problemi già segnalati. Non incollare percorsi del server o dati sensibili.

Capitolo precedente: Log di debug: gli errori PHP in un file proprio. Capitolo successivo: Disattivazione, disinstallazione e dati personali. Per l’indice: manuale CSDN.

The post Risoluzione dei problemi e domande frequenti first appeared on Matteo Cisilino.

Dove si trova

Vai su Impostazioni > Cisilino Site Defense Network (punto 1 dell’immagine) e apri la scheda Log di debug (punto 2). Le sezioni sono tre:

• punto 3: “Log di debug del sito”, con stato e accensione.
• punto 4: “File raccolti”.
• punto 5: “Ultime voci”.

A cosa serve il log di debug WordPress

Ti torna utile quando il sito mostra una pagina bianca o un errore critico, quando qualcosa si rompe dopo un aggiornamento, o quando il tuo hosting non ti lascia modificare wp-config.php né leggere i log. Le costanti WP_DEBUG e WP_DEBUG_LOG si definiscono prima del caricamento dei plugin, quindi un plugin non può accenderle. Questo log usa un gestore di errori PHP agganciato al caricamento del plugin.

Questo log si aggiunge, non sostituisce niente. Gli errori continuano ad arrivare anche dove arrivavano prima, cioè in debug.log e nel log del server. Non invia nulla al pannello.

Come si usa

1. Apri la scheda Log di debug.
2. Scegli Resta acceso per: 1 ora, 24 ore (predefinito) o 7 giorni.
3. Scegli Dimensione massima per file.
4. Premi Accendi il log di debug. Leggi “Log di debug acceso. Si spegne da solo allo scadere del tempo scelto; i file restano.”.
5. Riproduci il problema sul sito.
6. Torna alla scheda. Leggi “Ultime voci” oppure scarica il file dalla sezione “File raccolti”.
7. Quando hai finito premi Spegni il log di debug, oppure aspetta la scadenza. Vedrai “Log di debug spento. I file raccolti sono ancora qui sotto.”.

Lo “Stato:” ti dice se il log è “acceso, si spegne il gg/mm/aaaa hh:mm”, “spento (scaduto il …)” oppure “spento”. A log acceso puoi cambiare la dimensione con Salva dimensione.

File raccolti

La tabella elenca nome, dimensione e i pulsanti Scarica ed Elimina. Sotto trovi Elimina tutti i file. Prima di cancellare il plugin chiede conferma: “Eliminare questo file? L’operazione non si può annullare.”. Per Elimina tutti i file il testo è “Eliminare tutti i file del log di debug? L’operazione non si può annullare.”. Se non c’è nulla leggi “Nessun file: il log non è mai stato acceso o non ha ancora registrato nulla.”.

Ultime voci

Il riquadro mostra le 200 voci più recenti, dalla più nuova. Il menu Tutti i livelli ti permette di filtrare per Fatal error, Parse error, Recoverable error, Warning, Notice o Deprecated. Poi premi Filtra. Per tutto il resto scarica i file. Se il filtro non trova nulla leggi “Nessuna voce con questo filtro.”.

Una voce ha questa forma:

[2026-10-29 10:15:03 UTC] Warning: messaggio in /percorso/file.php:12 | GET /pagina

• L’orario è in UTC, diverso dall’ora del sito che vedi nel Registro attività.
• Dopo la barra verticale trovi metodo e percorso della richiesta, senza query string. Da riga di comando o cron vedi “cli/cron”.
• Un messaggio su più righe, come uno stack trace, resta una sola voce con le righe successive rientrate.
• Le righe “Info: log di debug attivato (utente N)” e “Info: log di debug disattivato (utente N)” non hanno un livello: con un filtro non compaiono.

Valori predefiniti e limiti

• Durata del log di debug WordPress: 1 ora, 24 ore o 7 giorni. Un altro valore diventa 24 ore.
• Dimensione per file: 1, 5, 10, 25 o 50 MB. Il predefinito è 5 MB. La dimensione scelta si salva quando premi Accendi il log di debug o Salva dimensione. Attenzione: Spegni il log di debug riporta la dimensione a 5 MB, perché quel modulo non contiene il menu della dimensione.
• Tetto complessivo: 200 MB, sommando file .log e .zip.
• Ogni messaggio è troncato a 4000 caratteri.
• Registra solo errori PHP: non query lente, errori JavaScript o richieste HTTP.

Esempi

• Errore critico dopo l’aggiornamento di un plugin: accendi per 1 ora, ricarica la pagina, filtra “Fatal error”. La voce indica file e riga, per esempio /…/plugins/xyz/file.php:210 | GET /negozio/.
• Avvisi sporadici: 24 ore, filtro Warning o Deprecated. Se il file è stato ruotato, scarica lo zip.
• Sito lento senza una causa chiara: 7 giorni con file da 25 MB, poi cerca Notice e Warning che si ripetono.

Tieni acceso il minimo necessario: spesso basta 1 ora.

Attenzione: i file del log di debug contengono percorsi del server e frammenti di dati. Non condividerli in pubblico. Restano sul disco anche dopo lo spegnimento e dopo la disinstallazione del plugin, che cancella le opzioni ma non i file. Eliminali tu quando hai finito. Il tetto complessivo è di 200 MB.

Attenzione: su server nginx l’accensione può essere rifiutata finché il server non blocca la cartella csdn-debug-*. Il messaggio è “Log di debug non acceso: i file della sua cartella risultano raggiungibili da internet (probabile server senza supporto a .htaccess, come nginx). I log possono contenere percorsi e dati: blocca l’accesso alla cartella csdn-debug-* nella configurazione del server e riprova.”. Se non gestisci il server, chiedi a chi lo gestisce.

Attenzione: il log non vede gli errori soppressi con @ né quelli generati prima del caricamento del plugin. Per esempio non vede gli errori di wp-config.php. Il log di debug WordPress del plugin non sostituisce i log del server.

Cosa succede dietro le quinte

Il log di debug WordPress salva i file in una cartella wp-content/uploads/csdn-debug- seguita da 16 caratteri casuali. Dentro ci sono un index.php, un .htaccess che nega l’accesso e il file in uso csdn-debug.log. All’accensione il plugin scrive un file di prova e prova a leggerlo via HTTP. Se risponde, rifiuta di accendere il log.

Quando il file in uso supera la dimensione scelta viene chiuso, compresso in .zip e ne parte uno nuovo. Nessuna voce va persa. Il .log originale si cancella solo dopo aver verificato lo zip. Se la compressione non riesce, il .log resta. Le voci di “Ultime voci” vengono lette solo dal file in uso, quindi dopo una rotazione quelle vecchie sono negli zip.

Prima di ruotare il plugin controlla il tetto di 200 MB. Se è raggiunto, il log si ferma per non sovrascrivere nulla. Compare l’avviso giallo: “Il log si è fermato perché i file hanno raggiunto il tetto di spazio (200 MB): per non sovrascrivere i dati non scrive più. Scarica o elimina i file, poi riaccendilo.”. Per ripartire elimina i file e riaccendi.

Alla scadenza il log si spegne da solo, ma i file restano. Il plugin non li tronca e non li cancella mai: lo fai solo tu con Elimina o Elimina tutti i file. Per gli errori fatali la voce viene scritta a fine richiesta.

Se il log di debug WordPress non funziona

• “Log di debug non acceso: la cartella dei caricamenti non è scrivibile.”: controlla i permessi della cartella wp-content/uploads.
• Il log non scrive: se la scrittura fallisce, il plugin lo segnala con una voce “Log di debug del sito: …” negli “Ultimi tentativi” della scheda Registro attività.
• Il log è fermo per il tetto: scarica ciò che ti serve, elimina i file e riaccendi.

La guida generale al manuale spiega dove si colloca questa scheda. Per capire meglio le costanti di WordPress guarda la guida ufficiale al debug di WordPress: spiega WP_DEBUG e WP_DEBUG_LOG, che questo plugin non può sostituire.

Capitolo precedente: Registro attività. Capitolo successivo: Risoluzione dei problemi e domande frequenti.

The post Log di debug: gli errori PHP in un file proprio first appeared on Matteo Cisilino.