Questa è la seconda parte della serie di guide sulla sicurezza di un sito web Joomla! tradotta dalla guida in ebraico. La prima parte era più per principianti con le prime semplici norme da seguire. Questa parte è per utenti più avanzati, con dettagli e spiegazioni più approfondite!Livello di difficoltà: Medio/Avanzato
Server
La maggior parte dei server web nel mondo funziona con sistemi operativi Linux, il motivo è che sono sistemi più sicuri e di facile manutenzione per i responsabili IT. La maggior parte degli attacchi verso siti web, che sono stati analizzati, non sono a causa di Linux, bensì la fonte di questi exploit è sempre stata negli strati al di sopra della piattaforma server. Se il nostro Hosting Provider si prende cura e mantiene tutti i livelli del server (Apache, MySQL e PHP) aggiornati, la maggior parte dei rischi per la sicurezza è a livello di applicazione, Joomla! in questo caso, quindi è qui che dovremo stare più attenti.
Permessi File
Una delle prime cose che dovremmo controllare sono i permessi dei file, se stiamo passando da un ambiente di sviluppo alla produzione (in un'installazione pulita di Joomla! non sarà necessario eseguire questa operazione). Per ogni file e directory in Linux ci sono tre flag: Read (r) Write (w) ed Execute (x). In aggiunta, ci sono tre gruppi collegati: User (u) Group (g) e Others (s). Ogni gruppo contiene i 3 flag. Ogni file dispone di autorizzazioni che possono essere convertite in numeri, ma non entriamo nel dettaglio di flag, gruppi e numeri (la documentazione riguardo questo argomento è facilmente reperibile su Google nonchè in altri articoli su Joomla.it). Ciò che è importante nei flag è il flag "write" del gruppo “others” che consente agli utenti di aggiungere dei file nel file system (un esempio di aggiunta di file nel file system è l'aggiunta di immagini e altri file al contenuto) Joomla! ha alcune directory che necessitano di autorizzazioni di scrittura per i file, tra cui la directory della cache (usata per la cache pagine), e la directory tmp (usata per i file temporanei assegnati durante l'installazione di un'estensione per esempio). Pertanto, si dovrebbero impostare queste directory “scrivibili”, ma solo queste, tutte le altre directory e file non dovrebbero essere scrivibili.
L'autorizzazione per i file dovrebbe essere impostata su 644 (cioè solo il gruppo "user" ha permesso di scrittura e non il gruppo "group" o "others"):
find /home/xxx/domains/xxxxxxx.com/public -type f -exec chmod 644 {} \;
Le directories richiedono un'autorizzazione 755 (vale a dire solo il gruppo "user" ha permessi di scrittura ed esecuzione, non il gruppo "group" o "others"):
find /home/xxx/domains/xxxxxxx.com/public -type d -exec chmod 755 {} \;
Nota bene:
- Se siete curiosi di sapere come convertire da flag e gruppi in numeri, consiglio di leggere questa guida, inoltre troviamo informazioni aggiuntive sui permessi file linux anche in questo articolo!
- Il comando può essere eseguito via ftp, ssh o un'interfaccia cpanel
- Teniamo presente che la directory /home/xxx/domains/xxxxxxx.com/public deve essere sostituita con il percorso della propria installazione di Joomla! sul server
Creare una directory scrivibile
Come già detto, a volte abbiamo bisogno che alcune directory siano scrivibili. Le directory che dovrebbero essere accessibili in scrittura sono: cache, tmp e images. Potremmo farlo con il seguente comando:
cd /home/xxxxxx/domains/xxxxxxx.com/public_html && chmod -R o+w images cache tmp
Ora, cosa succede se qualcuno vìola il tuo sito Joomla e carica un file di script?! (PHP è un linguaggio di script) Potrebbe essere caricato uno script che può fare potenzialmente qualsiasi cosa sul server, anche distruggere il nostro bellissimo sito. Naturalmente, Joomla! ha di default dei blocchi per evitare il caricamento degli script, ma cosa succede se qualche estensione non li blocca?!
La risposta è divisa in due opzioni: in primo luogo, se non abbiamo bisogno di caricare immagini per i contenuti, di utilizzare la cache o di installare qualsiasi estensione, semplicemente possiamo non rendere alcuna directory scrivibile!
Ma nel caso più ovvio in cui dovessimo avere bisogno di alcune delle caratteristiche sopra citate, o qualsiasi altra caratteristica che richiede directory scrivibili, è necessario disabilitare la possibilità di eseguire script per queste directory. Per fare questo, è necessario avere l'accortezza di aggiungere un file htaccess (inizia con dot!) per ogni directory, e deve contenere queste righe:.
# secure directory by disabling script execution
Options -ExecCGI
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Una direttiva htaccess precede qualsiasi attività Joomla! perché il file deriva da Apache, richiamando htaccess prima di ogni PHP.
MySQL Database
La raccomandazione è di evitare di utilizzare il prefisso jos_ di default per le tabelle MySQL. La versione 2.5 randomizza il prefisso, ma se abbiamo già installato Joomla! con questo prefisso per le tabelle del database, basta utilizzare uno script o una guida per convertire il prefisso delle tabelle, e non dimenticare di aggiornare correttamente la configurazione dopo.
Inoltre, è consigliabile che l'utente che esegue il servizio MySQL utilizzi solo le seguenti autorizzazioni specifiche (SELECT, UPDATE, DELETE, INSERT, CREATE). In ogni caso NON USARE l'utente root di MySQL. Potrebbe essere molto pericoloso!
Advanced: PHP
Le istruzioni successive sono per gli utenti avanzati che hanno accesso al file di configurazione di PHP ovvero php.ini
Se non si ha familiarità con questo file o con il php in generale, lasciamo fare al nostro provider.
Blocco funzione rischiosa
PHP è il linguaggio di programmazione più comune per applicativi web-based. È facile iniziare a sviluppare con PHP, è uno dei suoi grandi vantaggi, ma può essere rischioso. Ci sono alcune funzioni che possono dare l'accesso a posizioni "sensibili". Possiamo facilmente bloccare le funzioni pericolose con l'argomento disable_functions:
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, eval
Queste funzioni consentono agli utenti di eseguire funzioni sul server come ad esempio l'invio di dati, eseguire comandi dal server, ricevere informazioni sul server e altro ancora, ma fate attenzione: sono utili in un ambiente di sviluppo, ma in produzione non sono raccomandati affatto.
PHP access directives
PHP può accedere a qualsiasi posizione nel server web, a meno che non configurato diversamente. Questo è pericoloso, perché se qualche malintenzionato ottiene l'accesso al server può anch'egli accedere in qualsiasi posizione. Per ridurre questo rischio, definiamo in PHP a cosa può accedere:
open_basedir =/home/xxxxxx/domains/xxxxxxx.com/:/tmp
La directory tmp deve essere accessibile (non è la directory tmp di Joomla!), perché gli upload di PHP vengono fatti in questa directory, prima di passare a Joomla!
Advanced: htaccess
Come accennato prima, il file htaccess può filtrare i dati prima di entrare in applicazione Joomla! Questo va' bene, ma allora perché questa sezione è per utenti avanzati, se basta configurare e dimenticare?! La risposta è che htaccess è in grado di filtrare le informazioni richieste dalle richieste necessarie e talvolta, i principianti che partono con esperienza limitata a giocare con il file potrebbero danneggiare tutto. Nel peggiore dei casi possono rimuovere le direttive di riscrittura Joomla! e quindi il file htaccess sarà corrotto e le operazioni di base di Joomla smetteranno di funzionare (come ad esempio i collegamenti SEF).
La raccomandazione è quella di aggiungere una sezione specifica al file htaccess per ogni nuova direttiva, e tenere traccia delle direttive che sono state aggiunte. Salva l'originale come file testuale (htaccess.txt) in modo da poter tornare a una versione funzionante in caso di problemi.
È possibile trovare altri file htaccess di esempio più dettagliati nel wiki di Joomla (in lingua inglese) e utilizzare le sezioni specifiche da lì.
Bloccare accesso diretto al core di Joomla!
Tutte le richieste di applicazione Joomla devono passare attraverso un unico posto: index.php (nella versione 1.5 c'è anche index2.php) qualsiasi altro accesso diretto può essere considerato un tentativo di hacking. Nessuna estensione (o almeno la maggior parte) utilizza l'accesso diretto ai file ad eccezione di index.php; passando per la piattaforma Joomla, che passa attraverso questa porta. Pertanto, è possibile bloccare l'accesso diretto alla maggior parte dei file (ini, xml e php) aggiungendo la sezione successiva nel file htaccess:
#### @RS
# Deny access to php, xml and ini files
# within components and plugins directories
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_URI} \.php|\.ini|\.xml [NC]
RewriteCond %{REQUEST_URI} \/components\/ [OR]
RewriteCond %{REQUEST_URI} ^\/includes\/|^\/administrator\/includes\/ [OR]
RewriteCond %{REQUEST_URI} \/language\/ [OR]
RewriteCond %{REQUEST_URI} \/libraries\/ [OR]
RewriteCond %{REQUEST_URI} \/modules\/ [OR]
RewriteCond %{REQUEST_URI} \/plugins\/ [OR]
RewriteCond %{REQUEST_URI} \/templates\/ [OR]
RewriteCond %{REQUEST_URI} \/xmlrpc\/
RewriteRule ^(.*)$ index.php [R=404,L]
#### @RS
@RS segna l'inizio e la fine della sezione.
Bloccare MySQL injection hacks
SQL injection non funziona in Joomla perché la maggior parte degli sviluppatori utilizza le funzioni SQL del core di Joomla! Ma ci sono ancora pochi sviluppatori di estensioni, i più pigri, che non fanno questo, pertanto è possibile bloccare i tentativi con la sezione successiva:
#### @RS
# Prevent most common SQL-Injections
RewriteCond %{query_string} concat.*\( [NC,OR]
RewriteCond %{query_string} union.*select.*\( [NC,OR]
RewriteCond %{query_string} union.*all.*select [NC]
RewriteRule ^(.*)$ index.php [F,L]
#### @RS
Bloccare hijack tools
Chiunque visita il nostro sito web si chiama “user-agent”. Per i visitatori abituali, questo include l'identificazione del browser (Firefox, Explorer, Chrome) per i bot dei motori di ricerca c'è una speciale identificazione e per gli strumenti di dirottamento (hijack tools) ci sono identificazioni uniche che possiamo bloccare con:
#### @RS
# Block most common hacking tools
SetEnvIf user-agent "Indy Library" stayout=1
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Wget" stayout=1
deny from env=stayout
#### @RS
Fine Seconda Parte
Abbiamo imparato qualcosa in più sulla sicurezza in questa seconda guida, che è di un livello un po' più avanzato rispetto alla prima parte.
Teniamo sempre a mente che la sicurezza è un processo continuo e si deve sempre aver cura di mantenere il più sicuro possibile il nostro sito web!
Commenta questo articolo sul forum
