Irrobustire il sito: permessi, header e plugin di sicurezza

Modulo 7: Sicurezza · Tempo di lettura: 10 minuti

Obiettivo della lezione: dopo questa lezione sarà in grado di irrobustire un sito WordPress con permessi, impostazioni e header di sicurezza, e di valutare i plugin di sicurezza per il loro reale valore.

Concetti chiave: irrobustimento (hardening), permessi dei file (644, 755), DISALLOW_FILE_EDIT, nessun PHP in uploads, elenco delle cartelle, nascondere la versione, X-Powered-By, header di sicurezza, file di backup e .git nella cartella web, WAF sul server, WAF in un plugin, scanner di malware

Cos'è l'irrobustimento

Irrobustire (hardening) significa: configurare il sito in modo che un errore o una falla possa fare meno danni. Non sostituisce gli aggiornamenti e le password robuste (lezione 7.2 e 7.3), ma ne riduce le conseguenze. Pensi a una casa: gli aggiornamenti sono le serrature, irrobustire significa assicurarsi che un intruso che è comunque entrato non possa arrivare alla cassaforte.

Permessi dei file

Ogni file e ogni cartella sul server ha dei permessi: chi può leggere, scrivere ed eseguire. Vengono scritti come tre cifre, per il proprietario, il gruppo e il resto del mondo. La linea guida tratta dalla documentazione di WordPress:

Quale valore funzioni per wp-config.php dipende da come il Suo hosting esegue PHP: nella maggior parte dell'hosting condiviso PHP viene eseguito come il Suo stesso utente, e in tal caso 600 è sufficiente. Provi e verifichi che il sito funzioni ancora.

Mai 777. Significa: chiunque sul server può scrivere. Una guida che dice "imposti la cartella a 777 se il caricamento non funziona" risolve il problema nel modo sbagliato. Con un buon hosting non è mai necessario.

Impostazioni in wp-config.php

Alcune righe che fanno una grande differenza (sopra "Stop modifiche"):

// Nessuna modifica dei file dalla Bacheca (Aspetto > Editor del tema e Plugin > Editor dei plugin).
define( 'DISALLOW_FILE_EDIT', true );

// Messaggi di errore mai sullo schermo dei visitatori (lezione 5.4).
define( 'WP_DEBUG', false );

Con DISALLOW_FILE_EDIT scompare l'editor con cui, dalla Bacheca, si possono modificare i file PHP di temi e plugin. Un intruso che si impossessa di un account amministratore non può quindi inserire con due clic codice dannoso nel Suo tema. Può comunque ancora installare plugin; se vuole vietare anche questo (ad esempio per un sito che gestisce per un cliente), c'è DISALLOW_FILE_MODS, ma in tal caso anche gli aggiornamenti dalla Bacheca smettono di funzionare.

Nessun PHP in uploads, nessun elenco delle cartelle

In wp-content/uploads dovrebbero esserci immagini e documenti, mai file PHP. Gli intrusi che riescono a caricare un file tramite una falla cercano proprio di inserire un file PHP e poi di richiamarlo. Blocchi questo con un file .htaccess nella cartella uploads (con LiteSpeed e Apache):

<Files *.php>
Require all denied
</Files>

Disattivi anche la visualizzazione delle cartelle. Senza index.php o index.html in una cartella, alcuni webserver mostrano un elenco di tutti i file ("Index of /wp-content/uploads/2026/11"). È una vetrina per chi cerca backup o documenti sensibili. Nel file .htaccess della Sua cartella web:

Options -Indexes

Molti provider di hosting hanno già questa impostazione disattivata di default. L'esercizio di questa lezione lo verifica.

Nessun resto nella cartella web

Tutto ciò che si trova nella cartella web può essere richiesto via web, tranne ciò che il server esegue come PHP o blocca. Sono pericolosi:

• copie di wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ di un editor di testo): contengono la password del Suo database e vengono inviate come testo (lezione 1.3);
• backup come backup.zip, site.tar.gz o database.sql nella cartella web;
• una cartella .git di uno sviluppatore, con cui qualcuno può scaricare tutto il Suo codice (e a volte le password);
• debug.log in wp-content (lezione 5.4);
• vecchi file di installazione o di test come info.php con phpinfo().

Conservi i backup fuori dalla cartella web o fuori dal server, e rimuova i resti.

Nascondere la versione: un piccolo vantaggio

WordPress inserisce di default nell'HTML:

<meta name="generator" content="WordPress 7.1.4" />

e la stessa cosa nel feed RSS. Anche PHP a volte si segnala in un header: X-Powered-By: PHP/8.3.14. Nasconderlo è ragionevole, ma non si aspetti troppo: i programmi degli intrusi provano comunque una falla, indipendentemente dalla versione che mostra, e le versioni spesso si possono dedurre anche da ?ver= dopo gli script. Nascondere è fare ordine, non è sicurezza. Un sito che nasconde la propria versione ma non si aggiorna è altrettanto vulnerabile.

Ecco come fare, in un proprio piccolo plugin o in functions.php del Suo tema child:

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

E l'header PHP con expose_php = Off nelle impostazioni PHP del Suo hosting (con DirectAdmin in Select PHP version, Options), oppure con Header unset X-Powered-By in .htaccess.

Header di sicurezza

Con alcuni header dice al browser come comportarsi con il Suo sito. I più importanti:

In .htaccess (con LiteSpeed e Apache):

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Verifichi poi che tutto funzioni: contenuti incorporati, pulsanti di pagamento, un widget di chat. Strumenti esterni come securityheaders.com e internet.nl mostrano cosa invia il Suo sito.

Plugin di sicurezza, uno sguardo onesto

Esistono molti plugin di sicurezza (ad esempio Wordfence, Solid Security, All-In-One Security, Sucuri). Spesso includono: un firewall, uno scanner di malware, la protezione del login, l'autenticazione a due fattori, notifiche e un elenco di misure di irrobustimento. Utili, ma con dei limiti:

• Un firewall in un plugin (WAF) si attiva solo quando PHP è in esecuzione. Una richiesta dannosa deve prima passare attraverso il webserver e PHP prima che il plugin la veda. Una falla in un file PHP richiamato direttamente, o un attacco che sovraccarica PHP stesso, non viene sempre fermato. Un firewall sul server (ad esempio ModSecurity, Imunify360 o un firewall del Suo hosting) si trova prima nella catena e blocca di più, senza che il Suo pacchetto debba fare il lavoro di calcolo. Chieda al Suo hosting cosa gira sul server.
• Uno scanner trova a posteriori. Uno scanner di malware Le dice che qualcosa non va. È prezioso, ma non previene nulla. E uno scanner sullo stesso server di un sito compromesso può essere stato a sua volta modificato dall'intruso.
• Non sostituiscono gli aggiornamenti. Un plugin con una falla nota resta vulnerabile, anche con un plugin di sicurezza accanto. Alcuni servizi di sicurezza offrono "patch virtuali" che bloccano attacchi noti fino a quando non ha aggiornato; utili come soluzione temporanea, non come sostituto.
• Sono a loro volta un plugin. Più codice, più da aggiornare, a volte una falla propria. E due plugin di sicurezza insieme spesso entrano in conflitto.
• Richiedono potenza di calcolo, soprattutto gli scanner che girano sul Suo stesso server.

Una scelta ragionevole: guardi prima cosa fa già il Suo hosting (firewall, scansione malware, blocco dei tentativi di accesso). Integri ciò che manca, di solito l'autenticazione a due fattori e la limitazione dei tentativi di accesso. Un plugin di sicurezza completo è utile soprattutto con un hosting che di per sé fa poco.

Riepilogo

• L'irrobustimento limita i danni di un errore o di una falla; non sostituisce gli aggiornamenti e le password.
• Cartelle 755, file 644, wp-config.php più restrittivo; mai 777.
• Attivi DISALLOW_FILE_EDIT, blocchi il PHP in uploads, disattivi l'elenco delle cartelle e rimuova backup, .git e debug.log dalla cartella web.
• Nascondere la versione è fare ordine, non è sicurezza; gli header di sicurezza aiutano il browser a proteggere i Suoi visitatori.
• Un firewall sul server blocca di più di un plugin; i plugin di sicurezza sono un'integrazione, non un sostituto.

Quiz

Esercizio

Esercizio A7.4: Cosa mostra il Suo sito a tutti? Inserisca l'indirizzo del Suo sito. Il programma legge la homepage e il feed RSS (/feed/) e verifica: non compare una versione di WordPress nel tag generator dell'HTML e del feed, l'header X-Powered-By non mostra una versione PHP, e il Suo sito invia X-Content-Type-Options: nosniff, una protezione contro i frame (X-Frame-Options o frame-ancestors) e una Referrer-Policy? È ammessa l'assenza di HSTS (lezione 3.1) e di Permissions-Policy (arancione).

Esercizio A7.4b: Nessun resto nella cartella web. Dimostri che il sito è Suo (record TXT o file con il codice dell'esercizio). Il programma richiede poi un breve elenco fisso: la cartella /wp-content/uploads/ (nessun elenco delle cartelle), /.git/HEAD, /wp-content/debug.log e alcuni nomi comuni di copie di wp-config.php. Va bene se nessuno di questi restituisce contenuto (404 o 403). Il programma non prova nient'altro e non modifica nulla.

Per approfondire

Questi articoli descrivono i passaggi nei pannelli di WebOké; in altri pannelli funzionano in modo simile.

• Guida DirectAdmin 11.5: Permessi di file e directory (chmod)
• Guida DirectAdmin 11.4: Mostrare e modificare i file nascosti come .htaccess
• Guida DirectAdmin 15.10: Web Application Firewall
• Guida DirectAdmin 15.11: Imunify360: scansione del sito web alla ricerca di malware
• Bloccare file tramite .htaccess, ad esempio plugin-googlemap2-proxy.php
• Sicurezza PHP
• Irrobustire WordPress (developer.wordpress.org, in inglese): https://developer.wordpress.org/advanced-administration/security/hardening/
• Header di sicurezza (MDN, in inglese): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security