Archivi tag: rkhunter

Rkhunter e le email di allarme

Rkhunter è un valido tool per identificare eventuali rootkit presenti sulla nostra macchina. In particolare, esso effettua una scansione ogni giorno, alla ricerca dei suddetti malware e se nota qualcosa di “anomalo” procede con l’invio di un’opportuna email di notifica.

rkhunter, warning, ssh, root access, email, fake alarms

Detto ciò, qualche giorno fa ho ricevuto la seguente email (proveniente da ben 4 macchine che gestisco, tutte sotto il medesimo dominio):

Oggetto: [rkhunter] Warnings found for hostname

Messaggio: Please inspect this machine, because it may be infected.

A differenza degli altri “falsi allarmi”, questa volta non ho fatto nessun balzo dalla sedia, ma ho deciso di identificare la causa delle suddette email.

Per prima cosa ho deciso di spulciare il file di log dell’applicativo in questione, ovvero /var/log/rkhunter/rkhunter.log, facendo un grep sulla keyword Warning.

Ecco l’output (parziale) del suddetto comando:

[04:02:45]   Checking if SSH root access is allowed          [ Warning ]
[04:02:45] Warning: The SSH and rkhunter configuration options should be the same:

Ok, problema identificato: se disabilito l’accesso root via SSH, devo specificare tale modifica anche all’interno del file di configurazione di rkhunter:

[root@hostname ~]$ nano /etc/rkhunter.conf

sostituendo

ALLOW_SSH_ROOT_USER=unset

con

ALLOW_SSH_ROOT_USER=no

Fine dei falsi allarmi.

Alla prossima.

Script bash per l’individuazione di eventuali rootkit mediante rkhunter

Recentemente ho creato questo semplice scrip bash che consente di identificare eventuali rootkit installati sulla nostra macchina, inviando successivamente il risultato della scansione al nostro indirizzo email. Tale scrip si avvale del tool rkhunter.

bash

Ecco il codice:

#!/bin/bash

destinatario=vostro.indirizzo@email.it

logfile=/var/log/rkhuntercheck.log

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

        ERRORE1="Errore 1: Devi essere root per eseguire lo scrip"
        echo $ERRORE1
        echo "$(date) $ERRORE1" >> $logfile

        exit 1

fi

rkhunter --update -c --sk --nocolors > temp_rootkit;

cat temp_rootkit | mail -iv -s "Esito scansione rootkit con rkhunter" $destinatario;

rm temp_rootkit;

exit 0

In particolare, la flag –sk consente di skippare il keypress, mentre la flag –nocolors consente di creare un report senza preoccuparci della formattazione del testo mediante i colori.

Inoltre, prima di effettuare uno scan, grazie alla flag –update, aggiorno rkhunter con le ultime signature.

Spero che questo scrip vi possa tornare utile.

A presto.

rkhunter ed il rootkit Xzibit

Qualche giorno fa sono rientrato dalle mie meritate ferie (che poi tanto ferie non erano) e mi sono ritrovato con uno un reverse proxy dell’ambiente di test spento.

Ho chiesto ai miei colleghi il perchè di questa cosa e mi è stato detto che proprio su quel proxy era stata pubblicata la porta 25 (SMTP) ed avevano paura che fosse stato ownato. Non chiedetemi per quale motivo è stato fatto questo accrocchio, ma qui i problemi erano altri, ovvero:

1) Essendo il reverse proxy basato su una distro che non viene aggiornata da illo tempore, c’era un’ampia probabilità (diventata certezza dopo ulteriore analisi) che il demone SMTP fosse bacato;

2) La porta 25 è stata lasciata in forwarding per circa una settimana, il che ha aumentato in modo esponenziale il rischio che la macchina venisse ownata da qualche lamer di turno.

rkhunter

Armato dunque di molta pazienza riaccendo la macchina ed effettuo una prima scansione con chkrootkit, che però non segnala nulla di anomalo. Non contento installo anche rkhunter (il cui rpm lo potete scaricare da qui), il quale, alla fine dell’analisi, mi riporta il seguente sommario all’interno del file di log:

[10:10:09] System checks summary
[10:10:09] =====================
[10:10:09]
[10:10:09] File properties checks...
[10:10:09] Required commands check failed
[10:10:09] Files checked: 141
[10:10:09] Suspect files: 6
[10:10:09]
[10:10:09] Rootkit checks...
[10:10:09] Rootkits checked : 253
[10:10:10] Possible rootkits: 1
[10:10:10] Rootkit names    : Xzibit Rootkit
[10:10:10]
[10:10:10] Applications checks...
[10:10:10] Applications checked: 7
[10:10:10] Suspect applications: 4
[10:10:10]
[10:10:10] The system checks took: 13 minutes and 25 seconds
[10:10:10]
[10:10:10] Info: End date is Wed Aug 31 10:10:10 CEST 2011

Uhm, possibile che sia stato installato il rootkit Xzibit? Spulcio ulteriormente il log, alla ricerca del file che ha fatto scattare l’allarme. Il risultato è il seguente:

Found string 'hdparm' in file '/etc/rc.d/init.d/vmware-tools'. Possible rootkit: Xzibit Rootkit

Ebbene, rkhunter ha interpretato come “sospetta” la stringa hdparm presente nei wmware-tools. Ma essendo una macchina virtuale è palese che si tratta di un falso positivo.

Dunque se la vostra macchina è virtuale e ci avete installato i wmware-tools è molto probabile che rkhunter generi questo allarme.

Stay tuned.

PS: per la cronaca, il reverse proxy è ok (o almeno così sembra).

chkrootkit ed i falsi positivi

Stamattina, come ogni lunedì, ho ricevuto via email i report relativi alla scansione rootkit eseguita sui miei server mediante chkrookit.

chkrootkit

 

Una di queste email riportava la seguente entry:

Checking `lkm'... You have 2 process hidden for readdir command

You have 2 process hidden for ps command

chkproc: Warning: Possible LKM Trojan installed

Avranno bucato la macchina oppure si tratta di un falso positivo?

Mi accingo dunque ad effettuare ulteriori controlli, tra cui una nuova scansione mediante un altro tool per l’individuazione dei rootkit, ovvero rkhunter:

nightfly@nightbox:/var/log$ sudo rkhunter -c

Inutile dire che tale scansione ha avuto esito negativo. Indi per cui sono quasi certo che si tratta di un falso positivo. La conferma arriva da una nuova scansione eseguita con chkrootkit, che non ha segnalato nessuna anomalia.

Sono sicuro che quel falso positivo presente nel report fosse dovuto ad un restart di qualche processo avvenuto proprio durante la scansione schedulata.

Morale della favola: prima di pensare al peggio assicuratevi che la macchina sia stata effettivamente bucata.

A presto.