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.

Dove si trova

Nel backend vai su Impostazioni > Cisilino Site Defense Network (punto 1 dell’immagine). Apri la scheda Registro attività (punto 2). Dall’alto in basso trovi queste sezioni:

• punto 3: “Impostazioni del registro attività”.
• punto 4: la riga di stato sopra il modulo, con i contatori delle righe.
• punto 5: “Diagnostica invio al pannello”.
• punto 6: “Attività registrate”, la tabella con i filtri.
• punto 7: “Svuota il registro locale”.

A cosa serve il registro attività WordPress

Ti aiuta a rispondere a domande come “chi ha disattivato quel plugin?” oppure “da che IP è entrato quell’utente?”. Ogni evento è una riga nella tabella del database del sito.

Non confonderlo con il contatore dei login falliti per IP, che serve a decidere i blocchi. Sono due dati separati, con regole di conservazione diverse. Il tentativo di login fallito però compare anche qui, una riga per tentativo.

Per lo storico lungo e per le ricerche serie conviene il pannello. Il registro locale funziona anche senza pannello. Il collegamento si configura in Impostazioni remote.

Come si usa

1. Apri la scheda e guarda la riga “Righe nel registro locale: N — in attesa di invio al pannello: M”.
2. Nel modulo scegli le impostazioni descritte sotto.
3. Premi Salva impostazioni registro. Compare “Impostazioni del registro attività salvate.”.
4. Per leggere gli eventi vai a “Attività registrate”. Scegli un gruppo dal menu Tutti i gruppi, oppure scrivi nel campo Utente, oggetto o IP, poi premi Filtra.

Le impostazioni del modulo

• “Registra le attività su questo sito”: se la spegni, non vengono scritte nuove righe. Le vecchie restano.
• “Retention locale (giorni)”: da 0 a 3650. Con 0 non si cancella mai per età.
• “Tetto righe conservate”: da 0 a 1.000.000. Con 0 non c’è tetto.
• “Invia le attività al pannello”: richiede il collegamento in Impostazioni remote.
• “Consegna immediata”: l’invio parte a fine richiesta, senza far aspettare il visitatore. Se la spegni, l’invio avviene solo con la sincronizzazione ogni 15 minuti.
• “Cosa registrare”: una casella per ciascuno dei 18 gruppi di eventi.

I gruppi di eventi

I gruppi hanno queste etichette, identiche nelle caselle di “Cosa registrare” e nel menu Tutti i gruppi: Accessi (login, logout, tentativi falliti); Utenti (creazione, modifica profilo, ruoli, eliminazione); Contenuti (articoli, pagine, custom post type); Categorie e tag; Commenti; Media (allegati); Plugin (attivazione, disattivazione, installazione, aggiornamento); Temi (cambio tema, aggiornamento, personalizzazione); Aggiornamenti di WordPress; Impostazioni di WordPress; Menu di navigazione; Widget; Editor file di temi/plugin da wp-admin; Esportazione contenuti; Caricamenti di file (compresi quelli fuori dalla libreria media); Integrità dei file del plugin; Impostazioni dei plugin (comprese quelle di questo plugin); Ciclo di vita del plugin (disattivazione, disinstallazione, svuotamento del registro).

Per le impostazioni di WordPress si registra solo una selezione di opzioni principali, per esempio blogname, siteurl, admin_email, default_role e active_plugins. Per gli altri plugin si vedono solo le impostazioni dichiarate con register_setting() o salvate da options.php. L’editor file registra il tentativo, non l’esito.

Come leggere la tabella

Le colonne sono Quando, Utente, IP, Gruppo, Azione, Dettaglio e Inviato. Le righe sono 50 per pagina, le più recenti per prime. Usa Precedenti e Successive per muoverti. Se non c’è nulla leggi “Nessuna attività registrata (con questi filtri).”.

Gruppo e Azione compaiono con il nome grezzo, per esempio plugins e deactivated. Chi non è autenticato appare come “(non autenticato)”. Nella colonna Inviato trovi la data di conferma del pannello, oppure “—” se la riga è ancora in coda. Il campo dei dettagli tecnici non è visibile qui: si legge sul pannello.

Un esempio di riga: 12/10/2026 09:14:02, utente mario (administrator), IP 203.0.113.5, gruppo plugins, azione deactivated.

Esempi di lettura

• Gruppo “Accessi (login, logout, tentativi falliti)” e un IP sospetto: una serie di failed seguita da un success può voler dire che qualcuno ha indovinato la password.
• Una riga users con azione role_changed e un utente inatteso: controlla se è una scalata di privilegi.
• Una riga del gruppo Caricamenti con un avviso di blocco: qualcuno ha provato a caricare un file pericoloso.

Valori predefiniti del registro attività WordPress

• Registro acceso, invio al pannello acceso, consegna immediata accesa, tutti i gruppi attivi.
• Retention: 30 giorni. La cancellazione per età avviene una volta al giorno.
• Tetto righe: 500. Il controllo scatta ogni 100 inserimenti, quindi la tabella può superarlo di circa 100 righe.
• Se salvi senza spuntare nessun gruppo, il registro resta acceso ma non scrive nulla.
• Non registra le visite normali e non esporta i dati.

Attenzione: un login fallito salva lo username digitato. Se qualcuno scrive la password nel campo username, quel testo resta nel registro, che può andare al pannello. Il plugin non lo filtra. Tienilo presente quando condividi o consulti il registro.

Attenzione: il tetto righe (default 500) cancella le righe più vecchie anche se non sono ancora state inviate al pannello. Il tetto ha la precedenza sulla garanzia di consegna. Sui siti con molto traffico non autenticato (login falliti, commenti, invii di file) 500 righe possono finire presto. Se ti serve lo storico completo, alza il tetto, ma tieni conto che con 0 togli il limite di spazio sul disco.

Attenzione: “Svuota registro attività” è irreversibile in locale. Prima chiede conferma: “Svuotare tutto il registro attività locale? L’operazione non è reversibile.”.

Che cosa non viene salvato

Le password in chiaro non vengono mai registrate. Alla modifica di un profilo si salva solo l’indicazione che la password è cambiata. Il campo “Chiave API” del plugin è mostrato come ***. Le opzioni di altri plugin il cui nome contiene parole come key, secret, token, password, auth, salt, nonce, license o credential hanno il valore sostituito con “*** (valore non registrato)”. I valori delle opzioni sono troncati a 200 caratteri.

Diagnostica dell’invio al pannello

La sezione al punto 5 serve quando le attività non arrivano al pannello. Un invio che fallisce non dà errori visibili: le righe restano in coda e riprovano. L’unico sintomo è il contatore “in attesa” che non scende.

La tabella mostra, tra le altre voci, “Collegamento al pannello”, “Registro attività”, “Invio al pannello”, “Consegna immediata”, “Righe in coda”, “Destinazione di error_log()” e “Ultimo tentativo di invio”. I valori problematici sono in rosso. Se l’ultimo tentativo risulta con meno righe accettate che inviate, compare “Righe scartate dal pannello”: quelle righe non vengono ritentate.

I pulsanti sono tre:

• Prova a inviare adesso: fa un invio di prova subito. L’esito è nella tabella.
• Attiva log dettagliato (poi Disattiva log dettagliato): registra anche gli invii riusciti.
• Svuota registro diagnostico: cancella solo l’elenco “Ultimi tentativi”, che tiene al massimo 25 voci. Compare solo se ci sono voci.

Cosa succede dietro le quinte

A fine richiesta il plugin chiude la risposta al visitatore, quando il server lo permette, e invia le righe al pannello in lotti da massimo 200, dalle più vecchie. Una riga conta come consegnata solo quando il pannello ne conferma la ricezione. Una sincronizzazione ogni 15 minuti fa da rete di sicurezza.

La retention per età cancella le righe vecchie una volta al giorno. Se l’invio è acceso e il pannello è configurato, cancella solo quelle già confermate. Altrimenti cancella per sola età.

Lo svuotamento tenta prima di inviare l’arretrato, poi cancella tutto. Registra l’evento di svuotamento, che diventa la prima riga del registro nuovo. Non invia alcun comando di cancellazione al pannello: lo storico già inviato resta lì. Dopo lo svuotamento leggi “Registro attività locale svuotato. Lo storico già inviato al pannello non è stato toccato.”. Se c’erano righe mai consegnate, un avviso in grassetto ti dice quante sono andate perse.

Se il registro attività WordPress non invia

• Il contatore “in attesa” non scende: apri la diagnostica, guarda l’ultimo tentativo e il codice HTTP, poi premi “Prova a inviare adesso”.
• Riquadro giallo sul pannello che non conferma: il pannello potrebbe non essere aggiornato. Le righe restano in coda e non si perde nulla.
• Collegamento “NON configurato”: senza customer code, chiave API e URL non viene inviato nulla. Torna a Impostazioni remote.

Per una guida più ampia sulle buone pratiche di registrazione leggi la guida OWASP al logging: spiega che cosa conviene registrare e che cosa evitare.

Torna al capitolo 1, l’indice del manuale. Capitolo precedente: Rate limiting. Capitolo successivo: Log di debug.

The post Registro attività: cosa è successo sul sito first appeared on Matteo Cisilino.

Dove si trova

Vai su Impostazioni e scegli Cisilino Site Defense Network (punto 1 dell’immagine). Apri la scheda “Rate limiting” (punto 2). Per salvare serve il permesso manage_options; su multisite serve manage_network_options.

Le sezioni sono quattro. Il punto 3 è “Come funziona, in concreto: cosa viene contato”. Il punto 4 è “1. Autori: pubblicazioni troppo frequenti”. Il punto 5 è “2. Visitatori: commenti e form di contatto”. Il punto 6 è “Utenti attualmente sospesi”. I valori di tempo sono tutti in secondi.

A cosa serve

Il paletto sugli autori ferma un account che pubblica a raffica, prima che riempia il sito di contenuti. Il paletto sui visitatori frena chi inonda commenti e form. Il codice conosce anche un terzo paletto, l’email obbligatoria. Lo trovi nella scheda “Registrazione utenti”, descritta nel capitolo precedente.

Come si usa

Cosa viene contato (punto 3)

Il riquadro informativo spiega le regole. Per gli autori, il controllo scatta quando WordPress salva un articolo o una pagina. Il plugin conta quanti articoli e pagine di quell’autore hanno data di creazione o pubblicazione negli ultimi T secondi. Se sono più di N, l’autore viene sospeso. Il salvataggio che supera la soglia va a buon fine: la sospensione blocca i successivi.

Non contano plugin e temi, gli accessi, le modifiche a contenuti più vecchi della finestra, le bozze automatiche, le revisioni, il cestino, i media, i commenti e gli altri tipi di contenuto. Gli ambienti temporanei, come quello di prova del Plugin Check, vengono ignorati.

Attenzione: l’esempio scritto in quel riquadro cita ancora N=3. È un testo vecchio. Il valore predefinito reale è 150 contenuti in 5 minuti, dalla versione 1.0.13.

Autori (punto 4)

1. Spunta “Rate limit attivo” per limitare le pubblicazioni degli autori.
2. Decidi se tenere “Alert via email”: ricevi una mail alla sospensione di un autore.
3. Imposta “N: contenuti ammessi”, da 1 a 1000. Predefinito 150.
4. Imposta “T: finestra (secondi)”, da 10 a 86400. Predefinito 300, cioè 5 minuti.
5. Imposta “S: sospensione (secondi)”, da 60 a 2592000. Predefinito 3600, cioè 1 ora.
6. Premi Salva impostazioni rate limiting.

La mail va all’indirizzo amministratore di Impostazioni > Generali. Contiene l’utente, i contenuti nella finestra, la scadenza e l’elenco fino a 20 contenuti recenti da controllare. La sospensione non modifica quei contenuti.

Visitatori (punto 5)

1. Spunta “Rate limit attivo” per limitare gli invii degli ospiti.
2. L’“Alert via email” è disattivo di default. Su un sito esposto può generare molte mail. Arriva allo stesso indirizzo amministratore di Impostazioni > Generali, una volta per ogni blocco.
3. “N: invii ammessi”, da 1 a 100. Predefinito 2.
4. “T: finestra (secondi)”, da 5 a 3600. Predefinito 60.
5. “S: blocco IP (secondi)”, da 60 a 2592000. Predefinito 3600.

Il paletto riguarda solo chi non è loggato. Conta gli invii per IP e per tipo, commenti oppure form. Un blocco sui commenti non blocca i form. I form di contatto coperti sono quelli di Contact Form 7. Il commento respinto mostra “Troppi invii” con errore 429.

Se un valore è fuori dai limiti, il plugin lo porta al più vicino ammesso. Il salvataggio mostra “Impostazioni del rate limiting salvate. I valori fuori dai limiti ammessi sono stati riportati al più vicino consentito.”

Rate limiting WordPress: sospensioni e blocchi

Un autore sospeso mantiene il suo ruolo e può usare il resto del pannello. Perde però i permessi di creare e pubblicare articoli e pagine. Spariscono “Aggiungi articolo” e le voci delle pagine, e se apre quelle schermate riceve “permesso negato”. In bacheca compare un avviso che non si può chiudere.

Attenzione: la sospensione degli autori colpisce anche gli amministratori. Un amministratore sospeso perde la creazione e la pubblicazione, ma può ancora aprire le Impostazioni e revocare la sospensione da solo. Non esiste una lista di eccezioni per utenti, ruoli o IP: la whitelist IP della scheda Generale non esenta dal rate limiting.

Attenzione: il blocco dei visitatori è per IP. Più persone dietro lo stesso IP, come un ufficio, possono essere bloccate insieme. In quel caso alza N. Il plugin legge solo l’indirizzo di connessione (REMOTE_ADDR) e non gli header di proxy o CDN: dietro un proxy inverso o una CDN tutti i visitatori possono apparire con lo stesso IP e bloccarsi a vicenda.

Come revocare una sospensione

Hai due strade.

1. Aspetta. La sospensione finisce da sola dopo S secondi.
2. Nella sezione al punto 6, “Utenti attualmente sospesi”, premi Revoca sospensione sulla riga dell’utente. Vedrai “Sospensione revocata: l’utente può di nuovo creare e pubblicare contenuti.” Se la tabella è vuota leggi “Nessun utente sospeso.”

La tabella mostra al massimo 100 utenti. Gli avvisi in bacheca hanno i link “Revoca la sospensione” e “Controlla e revoca”, che portano alla stessa scheda.

Spegnere “Rate limit attivo” non toglie una sospensione già in corso. Per toglierla devi revocarla o aspettare la scadenza.

Cosa succede dietro le quinte

La sospensione è una informazione salvata sull’utente, con la data di scadenza. Per gli ospiti, ogni invio viene registrato per 24 ore in una tabella del plugin e poi conteggiato nella finestra. Se due richieste arrivano insieme, qualcuna in più può passare. Sospensioni e blocchi finiscono nel Registro attività, se è attivo e se i gruppi Utenti e Commenti sono abilitati.

Attenzione: un’importazione legittima di molti contenuti può far scattare il paletto sugli autori. Prima di una migrazione disattiva il paletto o alza N.

Esempi di rate limiting WordPress

• Blog con un solo autore: puoi abbassare N a 10 o 20 con T=300. Intercetti prima un account compromesso. Sono valori di prova, non una regola del plugin.
• Redazione che duplica o importa pagine: tieni 150/300 o più.
• Uffici con IP condiviso: alza gli invii ammessi dei visitatori a 3 o 5.

Conversioni utili: 300 secondi sono 5 minuti, 3600 sono 1 ora, 86400 sono 1 giorno. Per approfondire il tema generale, leggi la guida OWASP Blocking Brute Force Attacks, che spiega perché limitare i tentativi ripetuti.

Precedente: Registrazione utenti: chi può creare account. Successivo: Registro attività: cosa è successo sul sito. Per l’indice generale vai al capitolo 1 del manuale.

The post Rate limiting: limiti su autori e visitatori first appeared on Matteo Cisilino.

Dove si trova

Nel menu di WordPress apri Impostazioni e poi Cisilino Site Defense Network (punto 1 dell’immagine). Scegli la scheda “Registrazione utenti” (punto 2). Per salvare serve il permesso manage_options; su multisite serve manage_network_options.

Le sezioni sono tre. Il punto 3 è “Policy di registrazione”. Il punto 4 è “Ruoli ammessi (solo livello “ruoli a basso privilegio”)”. Il punto 5 è “Email obbligatoria”.

A cosa serve

La policy vale per ogni via di creazione: il pannello wp-admin, la REST API, XML-RPC, WP-CLI e qualunque plugin o tema che usi le funzioni di WordPress per creare utenti. Il controllo è fatto in PHP, senza toccare il file .htaccess.

Come si usa

Policy di registrazione (punto 3)

Scegli un solo livello tra tre. Non si sommano.

• “Nessuna restrizione (disattivato)”: il modulo è spento e WordPress si comporta come sempre.
• “Solo ruoli a basso privilegio (mai amministratore/editor/autore)”: è il livello predefinito. Valgono i ruoli ammessi del punto 4.
• “Nessuna registrazione (esclusiva)”: nessun nuovo utente può essere creato.

Ruoli ammessi (punto 4)

Vale solo per il livello dei ruoli a basso privilegio. Puoi spuntare subscriber (spuntato di default), contributor e customer (utile con WooCommerce). Le caselle administrator, editor, author e shop_manager sono sempre disabilitate, con la scritta “mai consentito”.

Email obbligatoria (punto 5)

La casella “Non creare utenti senza un indirizzo email valido” è attiva di default. Impedisce la creazione di utenti senza un’email valida, da qualunque via. Non tocca gli utenti che esistono già. Questa impostazione è salvata insieme a quelle del rate limiting, ma si gestisce qui.

Alla fine premi Salva policy di registrazione. Vedrai “Policy di registrazione utenti salvata.” Il salvataggio finisce nel Registro attività, con l’etichetta “Registrazione utenti”.

Registrazione utenti WordPress: valori predefiniti e limiti

• La policy predefinita è “Solo ruoli a basso privilegio”, attiva anche se non hai mai salvato nulla.
• Il ruolo ammesso di partenza è solo subscriber.
• I ruoli vietati vengono scartati sempre, anche se qualcuno prova a inviarli a mano.
• L’elenco dei ruoli è fisso: non mostra i ruoli personalizzati del tuo sito.
• Non esistono liste di domini email, captcha o controlli anti-spam sulle registrazioni.

Attenzione: con “Nessuna registrazione (esclusiva)” nessuno può creare utenti, nemmeno l’amministratore. La voce “Aggiungi nuovo utente” sparisce dal menu e aprire user-new.php a mano dà un errore 403. Se al livello dei ruoli a basso privilegio togli la spunta a tutti i ruoli, l’elenco resta vuoto e nessun utente è ammesso. Qui però la voce di menu e la pagina restano visibili: l’errore 403 arriva solo quando provi a creare l’utente.

Con il livello predefinito non puoi creare un editor o un autore nemmeno da amministratore. Il plugin non prevede eccezioni per chi è già loggato. Per creare un utente con un ruolo alto, passa temporaneamente a “Nessuna restrizione”, crea l’utente e poi torna indietro.

Controlla anche il “Ruolo predefinito per i nuovi utenti” in Impostazioni > Generali di WordPress. Se è un ruolo vietato, come Editor, ogni registrazione senza ruolo esplicito viene respinta.

Cosa succede dietro le quinte

Il controllo principale agisce sul filtro pre_insert_user_data, solo alla creazione di un utente. Le modifiche agli utenti esistenti passano sempre. Un tentativo respinto mostra il titolo “Registrazione non consentita” con errore 403. Sulla REST API ricevi un errore JSON 403 al posto della pagina.

Con qualunque policy attiva, il plugin toglie il metodo XML-RPC wp.newUser. Con la policy esclusiva forza anche a falso l’opzione “Chiunque può registrarsi” di WordPress. Con il livello dei ruoli bassi, quell’opzione resta quella che hai scelto tu.

C’è anche una rete di sicurezza dopo la creazione. Se un account nasce lo stesso e viola la policy, il plugin gli toglie subito il ruolo e scrive un evento nel Registro attività. L’account non viene cancellato, così puoi esaminarlo.

Attenzione: un plugin o un tema compromesso che scrive direttamente nella tabella degli utenti con un INSERT nel database non passa da nessun filtro. Nessun plugin PHP può fermarlo. La registrazione utenti WordPress protetta da questa scheda è una barriera forte, ma non è assoluta.

Esempi

• Sito vetrina senza utenti pubblici: scegli “Nessuna registrazione (esclusiva)”.
• Sito con iscritti o commenti: lascia il livello predefinito con subscriber.
• Negozio con WooCommerce: aggiungi customer.
• Devi aggiungere un collaboratore con un ruolo alto: usa “Nessuna restrizione” solo il tempo necessario.

Se qualcosa non va

Se un’iscrizione viene respinta con il messaggio sul ruolo non consentito, controlla il ruolo predefinito di WordPress e i ruoli spuntati al punto 4. Il Registro attività ti dice se un account è stato privato del ruolo dalla rete di sicurezza. Per capire meglio i ruoli, leggi la pagina ruoli e permessi nella documentazione di WordPress. Elenca cosa può fare ogni ruolo.

Precedente: Paranoic Hardening: header di sicurezza e sessione amministrativa. Successivo: Rate limiting: limiti su autori e visitatori. Per l’indice generale vai al capitolo 1 del manuale.

The post Registrazione utenti: chi può creare account first appeared on Matteo Cisilino.

Dove si trova

Nel menu laterale di WordPress vai su Impostazioni e scegli Cisilino Site Defense Network (punto 1 dell’immagine). Apri la scheda “ Paranoic Hardening” (punto 2). Per salvare serve il permesso manage_options; su multisite serve manage_network_options.

La scheda ha quattro sezioni. Al punto 3 trovi “Paranoic Hardening — Header di sicurezza HTTP”. Al punto 4 c’è “HTTP Strict Transport Security (HSTS)”. Il punto 5 è “Verifica header di sicurezza”. Il punto 6 è “Autologout amministratori per inattività”.

A cosa serve

Gli header sono istruzioni che il sito manda al browser insieme a ogni pagina. Il plugin li invia con l’hook send_headers di WordPress, senza toccare il file .htaccess. Quindi non rischi un errore 500 e funzionano anche senza mod_headers.

Gli header riguardano solo il sito pubblico. Non vengono mai inviati nell’area di amministrazione. Il plugin non offre una Content-Security-Policy e non invia X-XSS-Protection.

Come si usa il Paranoic Hardening

Header di sicurezza HTTP (punto 3)

• X-Content-Type-Options invia nosniff. Il browser non “indovina” il tipo dei file. Il rischio è praticamente nullo.
• X-Frame-Options invia SAMEORIGIN. Il sito non può più essere incorporato in un <iframe> di un altro dominio. Se un sito partner mostra le tue pagine, smetterà di farlo.
• Referrer-Policy invia strict-origin-when-cross-origin. Verso altri domini viaggia solo il dominio, non il percorso. Statistiche di terzi che vogliono il referrer completo non lo riceveranno.

Spunta le caselle che ti servono e premi Salva Paranoic Hardening. Vedrai l’avviso “Impostazioni Paranoic Hardening salvate e applicate.” Le caselle che non spunti vengono salvate come disattivate.

HSTS (punto 4)

HSTS dice al browser di usare sempre https con il tuo dominio. Ci sono tre caselle: “Attiva HSTS”, “includeSubDomains” e “Preload”. L’header inviato ha max-age=31536000, cioè un anno. Il valore è fisso e non si cambia.

Il plugin rifiuta l’attivazione se la pagina non è stata aperta in https. In quel caso salva il resto e mostra un avviso rosso: “Impostazioni salvate, ma HSTS NON è stato attivato: questa richiesta non è arrivata in https. Apri il pannello in https e riprova.” Se la pagina è in http, le tre caselle sono anche disabilitate.

Se spegni “Attiva HSTS”, al salvataggio vengono azzerate anche “includeSubDomains” e “Preload”. Se riattivi HSTS, devi rispuntarle.

Verifica header di sicurezza (punto 5)

Premi Verifica ora. Il plugin fa una richiesta reale alla home del sito e controlla quali header arrivano davvero. Il risultato compare nel riquadro, con la data dell’ultimo test.

• Verde: “Tutti gli header attesi sono presenti nella risposta reale del sito.”
• Rosso: gli header attivi che non sono arrivati. Può essere un proxy, una CDN o un altro plugin che li rimuove. HSTS risulta mancante anche se l’indirizzo della home è http e non porta a https, perché il plugin lo invia solo su richieste https.
• Blu: “Nessun header attivo da verificare: attiva almeno un’opzione qui sopra e salva.”
• Rosso con “Richiesta di verifica fallita”: la richiesta non è andata a buon fine.

Il test controlla la presenza dell’header, non il suo valore. Non parte da solo: devi premerlo tu.

Autologout amministratori (punto 6)

Questa sezione del Paranoic Hardening ha un suo pulsante, Salva autologout amministratori. Spunta “Attiva” per disconnettere gli amministratori inattivi. Poi imposta il “Timeout di inattività (secondi)”. Se il browser blocca il localStorage (per esempio in navigazione privata), il controllo non scatta mai e non vieni disconnesso.

Il valore predefinito è 900, cioè 15 minuti. Il minimo è 60 e il massimo è 86400. Se scrivi un numero fuori dai limiti, il plugin lo porta al valore ammesso più vicino. Per esempio 30 diventa 60. L’avviso resta verde, quindi rileggi il numero nel campo dopo il salvataggio.

Vengono disconnessi solo gli utenti con il permesso manage_options. Editor e autori non vengono toccati. L’inattività è misurata nel browser: contano mouse, tastiera, scroll e tocco. La sessione si chiude come con “Esci” e le modifiche non salvate in un form aperto vanno perse.

Ordine consigliato di attivazione

1. Apri il pannello in https.
2. Attiva X-Content-Type-Options, salva e premi “Verifica ora”.
3. Attiva Referrer-Policy, salva e verifica.
4. Controlla che nessun sito incorpori il tuo, poi attiva X-Frame-Options, salva e verifica.
5. Attiva l’autologout con un timeout generoso, per esempio 1800. Riducilo solo dopo qualche giorno.
6. Per ultimo valuta HSTS, senza includeSubDomains e senza Preload.

Attiva una opzione alla volta. Se qualcosa si rompe, sai subito quale è stata.

Il rischio di HSTS, includeSubDomains e Preload

Attenzione: HSTS non si disfa dal sito. Se togli la spunta, il plugin smette di inviare l’header, ma i browser che l’hanno già ricevuto lo ricordano fino alla scadenza. Il plugin non invia mai max-age=0, quindi non ha un “annulla”. Lo dice anche il banner della scheda: gli effetti possono restare visibili per settimane o mesi.

Con HSTS attivo il browser rifiuta ogni connessione non https al dominio. Se il certificato scade o si rompe, il browser non mostra più nemmeno la schermata “continua comunque”. Il sito resta irraggiungibile da quel browser.

• includeSubDomains estende la regola a tutti i sottodomini. Un solo sottodominio senza https valido, anche di test o futuro, diventa irraggiungibile per chi ha già visitato il sito. Attivalo solo se tutti i sottodomini sono e saranno https.
• Preload aggiunge solo il flag preload all’header. Da solo non iscrive il sito: l’invio alla lista dei browser si fa a mano su hstspreload.org. La lista è dentro i browser, e uscirne richiede settimane. Considera Preload una scelta definitiva.

Salva sempre dalla versione https del pannello. Le caselle disabilitate non vengono inviate dal browser: salvando da una pagina http, HSTS e le sue sotto-opzioni si spengono.

Cosa succede dietro le quinte

Le impostazioni del Paranoic Hardening sono opzioni di WordPress, non regole del server. L’autologout stampa uno script solo nelle pagine di amministrazione. Lo script registra l’ultima attività nel localStorage del browser e ogni 5 secondi controlla il timeout. Alla scadenza chiede a admin-ajax.php di eseguire il logout e ti porta alla pagina di login. Il salvataggio finisce nel Registro attività solo se hai cambiato qualcosa.

Se qualcosa non va

• Il riquadro è rosso dopo “Verifica ora”: un proxy, una CDN o un altro plugin sta togliendo gli header. Controlla la loro configurazione.
• Un sito partner non mostra più le tue pagine: togli la spunta a X-Frame-Options e salva.
• Non riesci ad attivare HSTS: riapri il pannello con l’indirizzo https.
• Per controllare a mano gli header puoi usare gli strumenti sviluppatore del browser o curl -I sull’indirizzo https del sito.

Per capire meglio come funziona HSTS, leggi la pagina Strict-Transport-Security su MDN. Spiega max-age, includeSubDomains e preload con precisione.

Precedente: Scheda Test: verificare che le protezioni funzionino. Successivo: Registrazione utenti: chi può creare account. Per l’indice generale vai al capitolo 1 del manuale.

The post Paranoic Hardening: header di sicurezza e sessione amministrativa first appeared on Matteo Cisilino.

Dove si trova il test sicurezza WordPress

Apri Impostazioni > Cisilino Site Defense Network (punto 1 dell’immagine). Clicca sulla scheda Test (punto 2). Trovi due riquadri:

• punto 3: “Verifica blocco esecuzione PHP in uploads”.
• punto 4: “Integrità dei file del plugin”.

Dopo ogni pulsante il sito ti riporta alla scheda Generale, con un avviso in alto. L’esito però è scritto nella scheda Test. Riaprila per leggerlo.

Verifica blocco esecuzione PHP in uploads

Questo riquadro prova la regola “Blocca esecuzione PHP in wp-content/uploads” della scheda Hardening / IDS, descritta nel capitolo Hardening / IDS. Il testo spiega che è l’unico modo per sapere se la regola è davvero efficace su questo sito. Un AllowOverride disattivato o un blocco più specifico nel server potrebbero renderla inutile senza segnalarlo.

Come si usa

1. Nella scheda Hardening / IDS attiva la regola e clicca su “Salva regole di hardening”.
2. Apri la scheda Test.
3. Nel riquadro “Verifica blocco esecuzione PHP in uploads” clicca su “Verifica ora”.
4. Torna alla scheda Test e leggi l’esito, con la riga “Ultimo test:” e la data.

Se la regola non è attiva e salvata, il pulsante è disabilitato. Il riquadro mostra: “Attiva e salva la regola “Blocca esecuzione PHP in wp-content/uploads” nella tab Hardening / IDS prima di poter eseguire il test.”.

Cosa fa il test

Il plugin scrive in uploads un piccolo file .php di prova. Lo richiede via HTTP, con un limite di 10 secondi. Poi lo cancella subito, in ogni caso. Il file contiene solo una stampa di controllo.

Come si legge l’esito

• Verde: “Blocco efficace: la richiesta al file di prova ha ricevuto N.”. Il numero è 403 o 404.
• Rosso: “ATTENZIONE: il file PHP di prova è stato ESEGUITO (risposta N).” La regola non blocca nulla. Il messaggio ti suggerisce di verificare che AllowOverride permetta .htaccess in quella cartella e che non esista un blocco <Directory> più specifico.
• Giallo: “Esito non chiaro (risposta N, corpo non riconosciuto): verifica manualmente con una richiesta diretta al sito.”.
• Blu: “Regola disattivata: attiva e salvala prima di eseguire il test.”.
• Rosso, per errori: “Impossibile determinare la cartella uploads.”, “Impossibile scrivere il file di prova in uploads (permessi?): test non eseguito.” oppure “Richiesta di verifica fallita”, con il motivo.

Attenzione: se il sito non riesce a chiamare se stesso, per esempio per un firewall, una password HTTP o un DNS locale, il test dà errore o esito non chiaro. Un 404 viene contato come blocco, ma potrebbe dipendere da altro. Il test prova solo la cartella uploads standard. Per pochi secondi un file .php esiste in uploads: se il blocco non funziona può essere eseguito, ma contiene solo una stampa.

Integrità dei file del plugin

È la seconda parte del test sicurezza WordPress. Il secondo riquadro confronta gli hash MD5 dei file .php del plugin con quelli attesi. Cerca file modificati, mancanti o aggiunti. Il controllo parte da solo una volta al giorno. Il pulsante “Verifica adesso” lo esegue subito.

Il riquadro riporta un limite fisso: chi ha già la scrittura sui file può anche riscrivere gli hash o spegnere il controllo. È un rilevatore di manomissioni, non una barriera.

Come si usa

1. Apri la scheda Test.
2. Nel riquadro “Integrità dei file del plugin” clicca su “Verifica adesso”.
3. Leggi l’avviso: “Verifica di integrità eseguita: l’esito è nel riquadro “Integrità dei file del plugin”.”.
4. Riapri la scheda Test e leggi il riquadro.

Come si legge l’esito

Verde: “Tutti i N file verificati corrispondono. Ultimo controllo: data.”. Se il riferimento è una fotografia, il riquadro aggiunge che rileva le modifiche successive, non un plugin già compromesso all’installazione. Rosso: “ATTENZIONE: i file del plugin non corrispondono a quelli attesi.”, con gli elenchi “Modificati”, “Mancanti” e “Non previsti”. Giallo: “Nessun riferimento disponibile”. In quel caso riattiva il plugin.

Il pulsante manuale non scrive nel registro attività. Lo fa solo il controllo pianificato, e solo se trova un problema o se i file tornano regolari dopo un allarme. Per i dettagli leggi il capitolo Sorveglianza dei caricamenti e controllo di integrità.

Attenzione: se hai modificato a mano un file del plugin, l’allarme rosso è normale. Se non l’hai fatto, tratta il sito come potenzialmente compromesso: reinstalla il plugin da una copia attendibile e controlla il resto dell’installazione.

Se qualcosa non va

Ripeti il test sicurezza WordPress dopo ogni correzione. Se il test sul PHP dà rosso, la regola non protegge. Chiedi al tuo hosting se .htaccess è abilitato. Se il server non legge .htaccess, per esempio con nginx, la regola non ha effetto. Ripeti il test dopo ogni correzione. Un 403 è la risposta che vuoi vedere: la pagina sul codice di stato 403 di MDN spiega cosa significa.

Capitolo precedente: Sorveglianza dei caricamenti e controllo di integrità. Capitolo successivo: Paranoic Hardening: header di sicurezza e sessione amministrativa. Per l’elenco dei capitoli torna all’introduzione del manuale.

The post Scheda Test: verificare che le protezioni funzionino first appeared on Matteo Cisilino.

Dove si trova

Attenzione al posto: il form non sta nella scheda “Hardening / IDS”. Apri Impostazioni > Cisilino Site Defense Network (punto 1), resta sulla scheda Generale (punto 2) e scorri fino in fondo. Dopo la whitelist trovi la sezione “Sorveglianza caricamenti file” (punto 3). Il controllo di integrità si legge invece nella scheda Test, spiegata nel capitolo Scheda Test.

A cosa serve la sorveglianza caricamenti file

La sezione dice: “Registra i file caricati sul sito, compresi quelli che non passano dalla libreria media: form di plugin, endpoint admin-ajax, upload arbitrari di un tema.” Da lì entra la maggior parte delle webshell. Un registro che guardi solo la libreria media non le vede.

Come si usa

1. Apri la scheda Generale e scorri fino a “Sorveglianza caricamenti file”.
2. Controlla la riga “Sorveglianza”: “Registra i caricamenti di file”.
3. Controlla la riga “Blocco file eseguibili”: “Rifiuta i caricamenti con estensione eseguibile (.php, .phtml, .phar, .sh, .htaccess…)”.
4. Clicca su “Salva sorveglianza caricamenti”.
5. Leggi l’avviso: “Impostazioni della sorveglianza caricamenti salvate.”.

Registra i caricamenti di file

Questa opzione è attiva di default. Gli eventi finiscono nel gruppo “Caricamenti di file” del registro attività. Su una richiesta senza file il costo è nullo. Il plugin annota ogni richiesta che contiene un file, con il campo e l’indirizzo che l’ha ricevuta. Le azioni che vedrai nel registro sono:

• “File ricevuto in una richiesta POST”.
• “File caricato”.
• “ATTENZIONE: caricato file potenzialmente eseguibile”.
• “Caricamento BLOCCATO”.

Il registro locale tiene al massimo 500 righe, se non cambi il tetto nelle impostazioni del registro attività. Come leggerlo è spiegato nel capitolo Registro attività.

Blocco file eseguibili

Questa opzione è disattivata di default. Funziona solo se è attiva anche “Registra i caricamenti di file”: con la sorveglianza spenta il blocco non fa nulla, anche se la casella è spuntata. Se la attivi, WordPress rifiuta il file con il messaggio: “Tipo di file non consentito su questo sito (Cisilino Site Defense Network: caricamento di file eseguibili bloccato).” Il controllo riconosce anche le doppie estensioni, come immagine.php.jpg.

Le estensioni considerate pericolose sono: php, php3, php4, php5, php7, php8, phtml, phps, phar, pht, shtml, cgi, pl, py, rb, sh, bash, htaccess, htpasswd, jsp, asp, aspx, exe, so, dll, ini, svg e svgz.

Attenzione: l’elenco blocca anche .svg, quindi i loghi in SVG non si caricano più. Blocca anche .ini, .py, .exe e .dll, che compaiono in allegati e pacchetti. Il plugin guarda tutte le parti dopo il primo punto. Un nome come archivio.pl.zip viene quindi rifiutato. Il blocco vale solo per i caricamenti gestiti da WordPress (filtro wp_handle_upload_prefilter). Un plugin che salva il file per conto suo viene registrato (“File ricevuto in una richiesta POST”) ma non fermato. Chi scrive direttamente su disco, senza una richiesta con file, non lascia traccia in questo registro.

Il controllo di integrità

A differenza della sorveglianza caricamenti file, qui non guardi i nuovi upload ma i file già presenti. Il plugin confronta gli hash MD5 dei suoi file .php con quelli attesi. Cerca file modificati, mancanti o aggiunti. Esclude le cartelle tests e dist. I file che non sono PHP non vengono controllati.

Il controllo gira una volta al giorno, tramite il sistema di pianificazione di WordPress. Se il sito ha poche visite, può slittare. Il riferimento è il file checksums.json nella cartella del plugin, se presente. Altrimenti il plugin usa una fotografia dei file scattata all’attivazione e a ogni cambio di versione.

Come si legge l’esito

Lo trovi nella scheda Test, nel riquadro “Integrità dei file del plugin”, dove c’è anche il pulsante “Verifica adesso” per lanciare il controllo subito. Ci sono quattro casi:

• “Nessuna verifica ancora eseguita.”, se non è mai partito.
• Riquadro verde: “Tutti i N file verificati corrispondono. Ultimo controllo: data.”.
• Riquadro giallo: “Nessun riferimento disponibile: impossibile verificare. Riattiva il plugin per catturare una nuova fotografia dei file.”.
• Riquadro rosso: “ATTENZIONE: i file del plugin non corrispondono a quelli attesi.”, con tre elenchi: “Modificati”, “Mancanti”, “Non previsti”.

Nell’elenco compaiono al massimo 15 nomi. Se vedi il rosso e non hai toccato i file a mano, il plugin ti dice di trattare il sito come potenzialmente compromesso. Reinstalla il plugin da una copia attendibile e controlla il resto dell’installazione.

Se il riferimento è la fotografia, il riquadro verde lo scrive. Quel confronto trova le modifiche successive, non un plugin già compromesso al momento dell’installazione.

Attenzione: l’integrità è un rilevatore, non una barriera. Chi ha già scritto sui file può anche riscrivere gli hash o spegnere il controllo. Modifiche fatte a mano o un caricamento a metà producono un allarme rosso.

Cosa succede dietro le quinte

La sorveglianza caricamenti file e l’integrità usano lo stesso registro. Il controllo giornaliero scrive nel registro attività solo in due casi: quando trova un problema e quando, dopo un problema, torna tutto regolare. Quando va tutto bene non scrive nulla. Il registro viene poi inviato al pannello, così una copia dell’allarme sta fuori dal tuo server.

Se qualcosa non va

La sorveglianza caricamenti file resta utile anche con il blocco spento. Se un plugin legittimo smette di caricare file, spegni “Blocco file eseguibili” e riprova. Per capire quali caricamenti arrivano sul sito, lascia attiva la sorveglianza e consulta il registro. Per le regole sui file in uploads vedi anche il capitolo Hardening / IDS.

Il rischio che qui si cerca di ridurre è descritto da OWASP: leggi la pagina sul caricamento di file senza restrizioni, utile per capire perché gli upload sono un punto debole.

Capitolo precedente: Hardening / IDS: le regole per .htaccess. Capitolo successivo: Scheda Test: verificare che le protezioni funzionino. Indice: introduzione del manuale.

The post Sorveglianza dei caricamenti e controllo di integrità first appeared on Matteo Cisilino.

Dove trovi l’hardening WordPress

Apri Impostazioni > Cisilino Site Defense Network (punto 1 dell’immagine). Poi clicca sulla scheda Hardening / IDS (punto 2). Nella scheda trovi tre sezioni, in questo ordine:

• punto 3: sotto il titolo “Hardening / controllo accessi (IDS)”, la riga “Regole .htaccess”.
• punto 4: “WordPress”.
• punto 5: “Percorsi personalizzati da bloccare”.

In cima la scheda dice: “Regole opzionali applicate a livello di server (.htaccess) o WordPress. Tutte disattivate di default: attivale solo se sai che non confliggono con temi/plugin del sito.” In fondo c’è un solo pulsante: “Salva regole di hardening”.

A cosa serve

Le regole riducono la superficie d’attacco. Tre interruttori scrivono nel file .htaccess, come anche il campo dei percorsi personalizzati. Due interruttori sono filtri di WordPress. Non è un firewall e non analizza le richieste: qui “IDS” vuol dire regole di accesso a file e cartelle.

Le regole .htaccess (punto 3)

Blocca esecuzione PHP in wp-content/uploads

L’etichetta completa è “Blocca esecuzione PHP in wp-content/uploads (protezione da shell caricate come “immagine”)”. Il plugin risponde 403 a ogni richiesta di un file con estensione php, php3, php4, php5, php7, php8, php9, phtml, phps, phar o pht il cui indirizzo contiene /wp-content/uploads/. Le maiuscole non contano.

Funziona solo con Apache 2.4 (serve il modulo mod_authz_core: senza, la regola non fa nulla e non lo segnala). Su nginx il file .htaccess viene ignorato e nessuna regola di questa scheda ha effetto, filtri di WordPress a parte. Copre la cartella uploads standard, non una cartella personalizzata. Può rompere plugin che servono davvero file PHP da quella cartella. Per sapere se funziona sul tuo sito usa la prova del capitolo Scheda Test.

Disabilita l’elenco dei file nelle directory senza index

Scrive una sola riga: Options -Indexes. Aprendo una cartella senza pagina indice vedrai un errore 403 invece dell’elenco dei file. Se usi una cartella come elenco pubblico di download, quell’elenco sparisce.

Blocca l’accesso diretto a wp-config.php, .htaccess, readme.html, debug.log

Il plugin scrive una regola per ciascun nome e risponde 403. Il controllo è sul nome del file, non sul percorso. Vale quindi per ogni file con quel nome in qualunque cartella del sito, anche dentro altri plugin. Un plugin che pubblica un proprio readme.html o debug.log verrà bloccato.

Le regole di WordPress (punto 4)

Queste due regole dell’hardening WordPress sono filtri PHP. Non toccano .htaccess.

Disabilita XML-RPC

L’etichetta è “Disabilita XML-RPC (bruteforce/pingback, quasi mai necessario sui siti moderni)”. Il file xmlrpc.php resta al suo posto, ma WordPress rifiuta i metodi XML-RPC che richiedono il login. Attenzione: si fermano l’app mobile di WordPress, parte delle funzioni di Jetpack e la pubblicazione da client esterni. Il metodo pingback.ping non richiede login e il filtro non lo ferma: non conti su questa regola per chiudere i pingback. I trackback non usano XML-RPC e non sono toccati. Il collegamento del plugin al pannello non usa XML-RPC, quindi non è toccato.

Blocca l’enumerazione utenti via ?author=N

Se la richiesta contiene il parametro author con un valore (diverso da vuoto e da 0), sul sito pubblico compare “Non trovato.” con risposta 404. Attenzione: questa regola non protegge la REST API. L’elenco degli utenti in /wp-json/wp/v2/users resta raggiungibile. Alcuni temi e plugin usano ?author= per filtrare gli archivi, e verranno bloccati.

Percorsi personalizzati da bloccare (punto 5)

Il campo di testo è per chi vuole chiudere una cartella precisa, per esempio /wp-content/uploads/vecchio-backup/. Scrivi un percorso per riga. Le righe vuote vengono ignorate.

Ogni riga è testo letterale. Le maiuscole contano e la parte dopo il ? dell’indirizzo non viene confrontata. L’aiuto sotto il campo parla di “pattern”, ma qui non ne esistono. Non esistono jolly: *, ^ e $ valgono come semplici caratteri. Il plugin blocca con 403 ogni indirizzo che contiene quella stringa, in qualunque punto. Per questo il percorso /wp-content/uploads/vecchio-backup/ blocca anche /blog/wp-content/uploads/vecchio-backup/x.

Questo campo non ha un interruttore. La regola è attiva appena il campo non è vuoto e salvi.

Attenzione: se scrivi / oppure wp blocchi tutto il sito, area di amministrazione compresa. Per tornare indietro dovresti correggere .htaccess via FTP. Anche una stringa come /uploads/ blocca tutte le immagini. Evita il carattere % nei percorsi.

Valori predefiniti

Cinque interruttori disattivati e campo vuoto. Le impostazioni sono nell’opzione csdn_hardening.

Come si usa

Procedi con calma: l’hardening WordPress si fa una regola alla volta.

1. Fai una copia di .htaccess prima di cominciare.
2. Spunta una sola regola.
3. Clicca su “Salva regole di hardening”.
4. Controlla che il sito si apra e che il pannello di amministrazione funzioni.
5. Passa alla regola successiva.

Dopo il salvataggio vieni riportato alla scheda Generale, non a quella in cui hai salvato. In alto trovi l’avviso. In caso di successo dice “Regole di hardening salvate e applicate.”. In caso di errore dice “Impostazioni salvate, ma la scrittura in .htaccess è fallita (permessi file?). Le regole non sono attive.”. Con l’errore, i due filtri di WordPress restano comunque attivi.

Attenzione: il plugin non crea alcun backup di .htaccess. Non controlla nemmeno la sintassi prima di scrivere. Una regola incompatibile con il tuo server può dare errore 500 su tutto il sito. Su una rete multisite il file è quello della rete: l’errore colpisce tutti i siti.

Cosa succede dietro le quinte

Il plugin scrive tra due marcatori: # BEGIN Cisilino Site Defense Network - Hardening e il relativo # END. Il resto del file non viene toccato. Un secondo blocco, separato, contiene gli IP bloccati. Se disattivi il plugin, i due blocchi vengono svuotati. Se spegni tutto e salvi, il blocco di hardening resta vuoto.

Se qualcosa non va

Se dopo l’hardening WordPress il sito mostra errore 500, apri .htaccess via FTP. Cancella le righe tra i due marcatori di hardening. Poi riprova con meno regole. Se non si scrive nel file, controlla i permessi di .htaccess.

Per un quadro più ampio sulle buone pratiche leggi la guida ufficiale di hardening di WordPress: spiega altre misure che stanno fuori dal plugin.

Capitolo precedente: Scheda IP bloccati: leggere la blacklist. Capitolo successivo: Sorveglianza dei caricamenti e controllo di integrità. Per l’elenco completo dei capitoli torna all’introduzione del manuale.

The post Hardening / IDS: le regole per .htaccess first appeared on Matteo Cisilino.