Un tempo realizzare un sito web non era così semplice, la figura del webmaster era fortemente specializzata ed aveva padronanza del linguaggio che decideva di utilizzare. Adesso, per fortuna direi, molti strumenti vengono in aiuto. Questo tuttavia spesso (non sempre) si traduce in figure professionali meno attente sul profilo tecnico (per non dire a volte completamente a secco delle più basilari norme di sicurezza).
Per un periodo Drupal è stato un must, per poi essere sorpassato da Joomla ed infine da WordPress che ormai detiene il predominio dei CMS. Da un punto di vista di sicurezza questo predominio ha comportato, ovviamente, l'accensione dei riflettori mediante tool automatizzati ed in grado di scovare vulnerabilità, plugin pericolosi ed errori di configurazione.
Nel corso di un paio di decenni nella sicurezza e di oltre 10 anni di WP, ho adottato una serie di accorgimenti che condivido volentieri con il lettore di questo blog.
Attaccare per difendere
Al termine della nostra installazione di WordPress, non è una cattiva idea provare proprio quei tool per simulare ciò che un attaccante avrebbe tipicamente fatto per scovare problemi sul nostro sito.
Senza entrare nei meandri dei payload di metasploit, uno dei tool più efficaci è certamente WPScan, incluso nativamente in Kali Linux.
(immagine: fonte hackercool)
Essendo un software fortemente specializzato, ci restituirà delle indicazioni puntuali su cosa mettere in sicurezza. Salvo, ovviamente, non abbiate commesso i più elementari errori come nell'esempio:
(immagine: fonte hackercool)
Mettere in sicurezza il sistema Linux
Nelle installazioni professionali di alto profilo, WordPress viene ospitato da un server Linux dedicato, a differenza di quanto accade con i provider che vendono uno "spazio wordpress" dove centinaia di installazioni convivono sullo stesso server. Se ci troviamo nella situazione di poter mettere agevolmente mano sulla macchina Linux che ospita il nostro WP, possiamo adottare certamente delle contromisure efficaci.
Giocare con le ACL
Nei casi più estremi è possibile abilitare gli attributi speciali ACL, così nessuno potrà scrivere file, salvo questi non vengano sbloccati esplicitamente. Questo comporta, ovviamente, che ogni modifica richieda l'avvio di uno script di sblocco direttamente in SSH sul sistema Linux.
Verificare gli MD5
Creare uno script che ogni X minuti verifichi gli MD5 dei file e ne segnali eventuali variazioni, restituisce immediatamente evidenza di problemi di sicurezza e file caricati abusivamente. L'attaccante, inoltre, nella maggior parte dei casi è del tutto all'oscuro di uno script simile ed anche in caso di escalation di permessi, il tempo necessario a rilevare lo script diventa certamente superiore rispetto all'allarme che lo script può aver inviato.
Bannare IP leggendo i log di apache
Uno script che richiami iptables leggendo i log si apache ci consente di reagire immediatamente a qualsiasi bruteforce.
Chroot Jail
Avviare apache in chroot jail è cosa buona e giusta, a maggior ragione se abbiamo deciso di implementare script sul sistema. Questa pratica normalmente garantisce l'integrità degli script che abbiamo deciso di far girare al livello superiore e fuori dalla jail.
(immagine: fonte linuxclass)
Altre tecniche
Bhè... qualcosa devo pur tenermela per me, altrimenti rischio di restituire un vantaggio eccessivo a chi invece utilizza queste informazioni non a fin di bene.
Farsi aiutare da un firewall di livello 7
Per sua natura, un firewall hardware di livello 7 è in grado di ispezionare il traffico e identificare attacchi di natura protocollare o pattern di attacchi noti. Abilitare questo tipo di controllo aiuta molto ad incrementare la sicurezza per portarla ad un livello più alto.
Firewall di questo tipo normalmente sono in grado di bloccare a prescindere anche determinate categorie di IP, per cui è buona norma (sempre se si può anteporre un firewall hardware) bloccare tutto ciò che non sia strettamente necessario, come ad esempio le reti anonime TOR o gli IP provenienti da nazioni la cui visualizzazione non produce alcun interesse.
Altri tool e plugin specifici
WP possiede una serie di plugin di sicurezza, come ad esempio il famoso Wordfence in grado di avvertirci per una serie di casistiche (file modificati, bruteforce, aggiornamenti necessari, etc.) anche nella sua versione gratuita.
Personalmente, tuttavia, ritengo che un plugin per quanto efficace possa essere, sia sempre un componente facente parte di un sistema di per se vulnerabile. Se il sistema viene corrotto, il plugin potrà essere manomesso, e questo lascia il tempo che trova. La prima regola della sicurezza è proprio l'indipendenza del sistema a garanzia della stessa. Se WP è compromesso, manomettere un suo plugin sarà quanto di più facile e prioritario possibile.
Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.
