Rootkit – Cosa sono e come evitarle

Quando si dice che non esistono malware per GNU-Linux purtroppo devo dirvi che non è vero. Ma è altrettanto vero che mantenere un server o un client sempre aggiornato, limitando il più possibile le installazioni di software provenienti da altri siti al di fuori dei repository, ed un’ottima conoscenza del sistema operativo vi evita queste brutte sorprese.

Prima di tutto il metodo di propagazione dei malware su GNU-Linux e sugli altri sistemi Unix-Like avviene in modo completamente diverso. Spesso l’attacco ad un server GNU-Linux deve essere mirato, e dura ore.

In questo articolo parlerò dei server, ma vale la stessa cosa anche per i client.

Le rootkit sono degli strumenti di hacking per accedere all’utente root, spesso standalone (in un unico file) e si mascherano come processi di sistema.

Esistono degli antirootkit molto validi che recensirò successivamente, vi spiegherò come si utilizzano e come effettuare gli updates, le scansioni, la generazione dei report e l’invio degli stessi in maniera del tutto automatica per mezzo di alcuni script.

Spesso le rootkit vengono compilate sulla macchina stessa, quindi sarebbe buono far sparire i compilatori dal server.

E’ cosa buona e giusta imporre delle limitazioni all’utente che utilizza il webserver, generalmente www-data, in modo da evitare un Privilege Escalation sul server stesso.

Il Privilege Escalation è una tecnica di hacking che permette appunto di scavalcare i privilegi di utente normale e raggiungere i privilegi di root. Ma ne parleremo approfonditamente in un articolo dedicato

Bisogna fare molta attenzione alle vulnerabilità del sito web hostato, perchè anche da una semplice SQL Injection è possibile iniettare codice PHP.

Non utilizzate mai i protocolli non sicuri come FTP, Webdav, Telnet o simili per accedere al vostro server, piuttosto utilizzate SSH e quindi l’utility SCP o SFTP per il trasferimento dei files in maniera criptata, in modo da evitare un eventuale attacco di tipo Man In The Middle (MITM) che significa appunto “uomo nel mezzo”, e permette all’attaccante di sniffare tutti i dati in entrata ed in uscita da un determinato protocollo, e quindi anche le oassword,

Chiudete l’accesso root di SSH, e non utilizzatelo sulla porta di default (la 22), possibilmente mettetelo oltre la porta 5000.

Spesso i crackers sono pigri, non scansionano le porte oltre la 5000.

Se state utilizzando un server non fate la pazzia di installare un ambiente desktop o un Window Manager, evitateli, pensate a FUSE (File sytem in user space) che permette di montare e smontare le partizioni con i permessi di utente. Gli ambienti desktop o i Window Manager spesso sono un veicolo di attacco perchè utilizzano alcuni processi che girano nel Kernel Space sull’User Space, e sono il divertimento perfetto dei crackers.

Non affidatevi alle configurazioni standard dei webserver o del php.ini, spesso sono buggate, anche solo dei piccoli accorgimenti sul php.ini rendono delle vulnerabilità non sfruttabili, ad esempio con il parametro “allow_external_url” disabilitato nel file php.ini potete anche avere una vulnerabilità di tipo Remote File Inclusion (RFI) sul vostro sito web, ma non può essere sfruttata.

Utilizzate una macchina virtuale per mettere online il vostro server, in modo da non compromettere la macchina reale, ed ovviamente forwardate solo le porte necessarie. Vi spiegherò su un altro articolo come fare.

Create più macchine virtuali per ogni servizio da mantenere online, in modo che se una macchina virtuale è compromessa è difficile compromettere anche le altre.

NON UTILIZZATE PROGRAMMI MAINSTREAM, sono quelli più soggetti ad attacchi, ed Apache è uno di questi.

Evitate come la peste programmi di gestione del server lato web come webmin o phpmyadmin, è molyo più sicuro utilizzare SSH con il normale mysql monitor a riga di comando.

Impostate sempre un fail2ban per SSH e tutti gli altri servizi aperti, in modo da bannare l’IP che effettua il wordlist o brute force attack, e sarà costretto a cambiare IP ogni tot tentativi.

Meno servizi girano sul server e meglio è, monitorate sempre la loro attività e soprattutto dovete avere la piena conoscenza di ogni singolo demone che gira sulla macchina, come vi dicevo prima le rootkit si spacciano come demoni di sistema.

Per quanto riguarda i CMS evitate i prefix di default, ad esempio per WordPress è “wp_” in modo da scoraggiare i lamers che trovano una vulnerabilità di tipo SQL Injection e provano a dumparvi il database con un exploit trovato in rete. Se il prefix delle tabelle non è quello di default non si accaniranno a cercare di trovare il vero prefix, anche se è possibilissimo farlo, e lo vedremo in altri articoli.

Spero di essere stato abbastanza chiaro. Dopo questo seguiranno vari articoli che parleranno degli antirootkit, di come utilizzarli, come leggere i logs, e come automatizzare la loro azione giorno per giorno.




Leave a comment