L'impronta digitale di un file

L'impronta digitale di un file ( o di un oggetto digitale qualsiasi ) è la rappresentazione di un file in una stringa numerica ( checksum o digest ) composta da un numero di bit prefissato ed è il risultato dell'esecuzione di una serie di operazioni ( funzione di hash ) sul file stesso. Una funzione di hash eseguita su un file darà sempre lo stesso risultato numerico, per esempio:

	2b7a999dbdee8aa3e261711ff9a4e443

Se, a quel file, venisse apportata anche la minima modifica, la funzione di hash restituirebbe una stringa numerica completamente diversa. Ecco il motivo per cui il risultato della funzione di hash è definito impronta digitale. La sua persistenza, infatti, ci garantisce l'integrità del file che rappresenta. Per verificare, quindi, che un file non venga modificato a nostra insaputa, è sufficiente eseguire una funzione di hash, sul file, la prima volta, memorizzare il risultato della funzione di hash in un posto sicuro, eseguire la stessa funzione di hash, sullo stesso file, nei giorni successivi, accertandosi che il risultato restituito sia lo stesso. Stesso risultato significa: nessuna modifica intervenuta. Risultato diverso significa: qualcuno o qualcosa ha modificato il contenuto del file. Spesso, l'impronta digitale viene usata per il download dei file da server remoti. Per garantire l'integrità del file scaricato, l'autore del file ne pubblica l'impronta digitale originale. L'utente, una volta effettuato il download, può eseguire la stessa funzione di hash sul file ricevuto e verificarne il risultato. Attenzione: l'impronta digitale è cosa ben diversa dalla firma digitale. La prima è il semplice risultato di una funzione di hash, mentre la seconda è l'applicazione di un qualche procedimento di crittografia su una data stringa testuale. Per criptare una stringa testuale è necessario utilizzare una chiave di codifica. Per creare una firma digitale, la chiave di codifica utilizzata è la chiave privata di colui che applica la firma. Spesso, per applicare la firma digitale su un intero documento, invece di criptare l'intero documento ( processo che richiederebbe notevoli risorse hardware ), se ne crea l'impronta digitale, che ha una lunghezza predeterminata, e si applica la firma digitale solo sulla sua impronta digitale. MD5, SHA-1, SHA-2 e SHA-3 sono gli algoritmi più noti per la creazione dell'impronta digitale ( o algoritmi digest ).

openssl dgst

Il comando openssl dgst calcola l'impronta digitale ( digest ) di un file, utilizzando diversi protocolli:

	openssl dgst -md5 file
	openssl dgst -md4 file
	openssl dgst -md2 file
	openssl dgst -sha1 file
	openssl dgst -sha file
	openssl dgst -mdc2 file
	openssl dgst -ripemd160 file
	openssl dgst -dss1 file

Per controllare l'output:

	openssl dgst -binary -md5 file

per averlo in binario;

	openssl dgst -hex -md5 file

per averlo in valori esadecimali ( default );

	openssl dgst -c -md5 file

per averlo suddiviso in gruppi di due cifre esadecimali ( -hex ), separate dai due punti:

  a8:34:56:8e:09:11:07:49:78:47:27:fe:57:d6:96:e1:aa:0c:b5:60

md5sum

Il comando md5sum calcola e verifica l'impronta digitale di un file. MD5 è un algoritmo che accetta, come input, un messaggio ( o un file ) di una lunghezza qualsiasi e produce, come output, una stringa di 128 bit, definita "impronta digitale" ( fingerprint ) o "sunto digitale" ( message digest ) del messaggio ( o del file ) di input. Come dichiarato nella RFC 1321, il documento ufficiale che descrive l'algoritmo MD5, si pensa che sia matematicamente impossibile produrre due messaggi che abbiano lo stesso "digest" ( o checksum o impronta digitale ), oppure, produrre un messaggio che abbia un "digest" ( o checksum o impronta digitale ) prestabilito.

	md5sum [OPTION] ... [FILE] ...

	md5sum MyFile
	md5sum MyFileFirst MyFileSecond

E' possibile creare un file con i risultati ottenuti:

	md5sum MyFile 1>report.txt
	md5sum MyFileFirst MyFileSecond 1>report.txt

in modo da ricordare i valori originali. Per esempio:

86902cdeccbceb305293cdeb2c2495aa  MyFileFirst
2ae332a2659ab0816619f5d0da2bc7c7  MyFileSecond

Per verificare, successivamente, se i file MyFileFirst e MyFileSecond sono stati modificati, chiederemo a md5sum di eseguire un check, estraendo i valori di hash contenuti nel file report.txt e confrontandoli con i valori attuali:

	md5sum -c report.txt -w
	md5sum --check report.txt --warn

Con l'opzione warn, chiediamo a md5sum di avvisarci di eventuali righe del file malformattate. Se nulla è cambiato, nei file verificati, riceverete un output del tipo:

MyFileFirst: OK
MyFileSecond: OK

Se, invece, doveste ricevere un messaggio del tipo:

MyFileFirst: NON RIUSCITO
MyFileSecond: OK
md5sum: ATTENZIONE: 1 codice di controllo calcolato NON corrisponde

significherebbe che il file MyFileFirst è stato modificato. Tocca a voi decidere se quelle modifiche siano state autorizzate e lecite, oppure fraudolente. Per calcolare la somma MD5 sullo standard Input ( STDIN ) e non su un file, eseguire uno dei seguenti comandi:

	echo "Ciao" | md5sum
	echo "Ciao" | md5sum -

I rootkit

Un rootkit è un programma, o un insieme di programmi, che, una volta installato su un computer ospite ( solitamente, il vostro ) può eseguire qualsiasi sorta di azione, dalla più innocente e silenziosa alla più distruttrice e rumorosa. Inoltre, un rootkit è invisibile allo stesso sistema operativo, di una parte del quale ha sostituito e modificato il codice sorgente ( di comandi quali: ls, ps, find, lsof, ifconfig, inetd, netstat ), al fine di impedirgli di avvisarvi della sua presenza. Un rootkit intercetta tutte le informazioni in arrivo dal sistema operativo e le modifica in modo tale da escludere ogni accenno alla propria esistenza. Se usate Windows, un rootkit può modificare, preventivamente, anche le voci del registro di configurazione. Tutto questo, al solo scopo di rendere invisibili, ai vostri occhi, se stesso e tutti i programmi che installa nel vostro sistema ( malware, spyware, trojan, worm, backdoor ). Questo significa che un rootkit non potrebbe essere rivelato da un normale software di scansione oppure da un software antivirus. Come dice il nome stesso, inoltre, un rootkit tende ad installarsi in un sistema operativo, guadagnando i privilegi di "root" ( amministratore ). In un sistema operativo, un amministratore può eseguire qualsiasi operazione, anche la più deleteria ( come cancellare tutti i file del disco fisso ), senza che il sistema operativo si senta in dovere di eseguire un qualsiasi controllo.

rkhunter

rk sta per RootKit. Hunter, in inglese, significa "cacciatore". Il comando rkhunter, quindi, va a caccia di rootkit. Il comando rkhunter potrebbe non essere installato, di default, nel vostro sistema: comunque, il comando rkhunter è disponibile nei repository della maggior parte delle distribuzioni Linux. Il comando rkhunter è, in realtà, uno script di shell, che esegue diverse verifiche sul filesystem locale, in cerca di rootkit e malware. Oltre a verificare la presenza di eventuali rootkit e malware già noti, rkhunter verifica anche se un qualche comando di sistema, compresi i file di avvio del sistema operativo, sia stato modificato, oltre a controllare le interfacce di rete e le applicazioni eventualmente in ascolto. E' necessario, di tanto in tanto, aggiornare la lista dei rootkit e malware già noti a rkhunter, eseguendo il comando:

	rkhunter --update

L'elenco dei server dai quali rkhunter tenterà di recuperare i file aggiornati si trova nel file:

	/var/lib/rkhunter/db/mirrors.dat

Per poter utilizzare rkhunter, è necessario verificare la presenza, nel sistema operativo, dei seguenti comandi di shell:

	cat
	sed
	head
	tail

senza i quali rkhunter non verrà eseguito. Altri comandi di shell, quali:

	basename
	diff
	dirname
	file
	find
	ifconfig
	ip
	ldd
	lsattr
	lsmod
	lsof
	mktemp
	netstat
	perl
	ps
	pwd
	stat
	readlink
	md5
	md5sum
	sha1
	sha1sum

se non presenti, verranno sostituiti da script Perl. Se Perl non fosse installato nel sistema, anche l'assenza di questi comandi comporterebbe la chiusura di rkhunter. Stessa cosa si può dire per un comando, tra i tanti disponibili:

	wget
	curl
	(e)links
	lynx

che permetta a rkhunter di connettersi ad un server, per effettuare il download degli aggiornamenti. Inoltre, ci sono veri e propri programmi che, se presenti, permettono a rkhunter di eseguire ulteriori controlli sul filesystem:

	Skdet
	unhide
	unhide-tcp

Il processo di installazione di rkhunter crea un file di configurazione:

	/etc/rkhunter.conf

che può essere editato, oppure sostituito da una copia locale del file, che dovrà essere contrassegnata dal suffisso .local:

	/etc/rkhunter.conf.local

Prima di utilizzare rkhunter, è necessario creare il database del filesystem, che verrà salvato nel file:

	/var/lib/rkhunter/db/rkhunter.dat

in cui rkhunter conserverà le informazioni sui file presenti nel sistema, per poi verificare eventuali modifiche apportate agli stessi file, nel corso delle sessioni successive. Le proprietà dei file tenute sotto osservazione sono proprietà quali: il valore di hash, i permessi, uid, gid, numero inode e così via. Per creare ed aggiornare il database, utilizzare l'opzione:

	rkhunter --propupd

Come per tripwire, anche nel caso di rkhunter è nostra responsabilità accertare che una modifica intervenuta su un file o su un gruppo di file sia lecita. Il compito di rkhunter, infatti, è solo quello di verificare se un file ha subito modifiche. Ogni volta in cui verrà eseguito rkhunter, con l'opzione --propupd, rkhunter aggiornerà il suo database allo stato attuale del sistema. Ad ogni sessione, rkhunter genererà o aggiornerà un file di log:

	/var/log/rkhunter.log

E' possibile chiedere l'aggiornamento del database per un solo file:

	rkhunter --propupd filename

oppure per una sola directory:

	rkhunter --propupd directory

oppure per un solo package:

	rkhunter --propupd package_name

Una volta creato il database del filesystem, potremo eseguire la nostra prima verifica del sistema:

	rkhunter -c
	rkhunter --check

Con questo comando, rkhunter effettuerà una serie di verifiche sul filesystem. Al termine di determinate verifiche ( test ), rkhunter chiederà all'utente di premere il tasto return, per continuare. E' possibile disabilitare queste interruzioni, rispondendo, in modo interattivo, alla domanda del programma, inserendo una lettera s ( minuscolo ) o S ( maiuscolo ), oppure usando l'opzione da riga di comando sk:

	rkhunter -c --sk
	rkhunter --check --skip-keypress

E' possibile suggerire a rkhunter di effettuare sia la verifica del filesystem ( check ), sia l'aggiornamento del database ( --propupd ), attingendo le informazioni sui file dal Package Management System in uso nel sistema. Questo può essere fatto, sia modificando la riga del file di configurazione:

	PKGMGR=NONE
	PKGMGR=RPM
	PKGMGR=DPKG
	PKGMGR=BSD
	PKGMGR=SOLARIS

sia utilizzando l'opzione --pkgmgr dalla riga di comando:

	rkhunter -c --sk --pkgmgr NONE
	rkhunter -c --sk --pkgmgr RPM
	rkhunter -c --sk --pkgmgr DPKG
	rkhunter -c --sk --pkgmgr BSD
	rkhunter -c --sk --pkgmgr SOLARIS

	rkhunter --propupd --pkgmgr NONE
	rkhunter --propupd --pkgmgr RPM
	rkhunter --propupd --pkgmgr DPKG
	rkhunter --propupd --pkgmgr BSD
	rkhunter --propupd --pkgmgr SOLARIS

NONE è il valore di default per i sistemi operativi Debian, poichè l'opzione --propupd ha bisogno di un tempo superiore di almento 4 volte, quando viene specificato il Package Manager System DPKG. Questo accade perchè DPKG ( come BSD ) restituisce solo il valore di hash MD5 di ciascun file, costringendo rkhunter a ricalcolare, al valore attuale, tutte le altre proprietà dei file. In sostanza, solo i Package Management System RPM e SOLARIS offrono un beneficio reale nell'uso di un Package Management System. Per quanto riguarda il file LOG, se si desidera che il log venga scritto nel file di log già esistente, aggiungere l'opzione --appendlog:

	rkhunter -c --appendlog
	rkhunter --check --appendlog

Questa opzione corrisponde alla voce APPEND_LOG contenuta nel file di configurazione, che può assumere due valori:

	APPEND_LOG=0
	APPEND_LOG=1

dove 0 ( zero ) indica a rkhunter di creare un nuovo file di log per ciascuna sezione, salvando il precedente file di log nel file:

	rkhunter.log.old

Quali sono le verifiche ( test ) eseguite da rkhunter? Per saperlo, utilizzare l'opzione --list:

	rkhunter --list tests
	rkhunter --list rootkits

Per sapere, invece, quali lingue sono disponibili, per rkhunter, utilizzare le opzioni:

	rkhunter --list lang
	rkhunter --list languages

Per sapere quali moduli Perl sono disponibili per le verifiche di rkhunter, utilizzare l'opzione:

	rkhunter --list perl

Torniamo alla lista dei nomi delle verifiche. Come si può leggere nel file README di rkhunter, "In RKH ( RootKit Hunter ) ad alcune verifiche viene assegnato un nome. Esistono due tipi di nomi di test, o verifiche: i nomi di singoli test ed i nomi di gruppi di test ... All'interno di un gruppo di test, esistono uno o più nomi di singoli test ... Per esempio, alla verifica delle proprietà dei file è stato assegnato il nome di gruppo 'properties'. Tuttavia, all'interno di questa verifica, il test del valore di hash di un file è noto come 'hashes'. Allo stesso modo, la verifica degli attributi di un file ( permessi, uid, gid e così via ) è nota come 'attributes'.

Grouped test names:
	properties	=> attributes hashes immutable scripts

Da notare che, mentre è possibile dire a rkhunter di effettuare la verifica delle proprietà dei file, ma di ignorare la verifica dei valori di hash dei file, non è possibile dire a rkhunter di eseguire la verifica degli attributi dei file, ignorando la verifica dei permessi sui file. Infatti, rkhunter non prevede un nome specifico per il test dei permessi sui file: questa verifica, quindi, non potrà essere abilitata o disabilitata. RKH ( RootKit Hunter ) può, se richiesto, abilitare o disabilitare uno o più verifiche. La richiesta può essere fatta sia con le opzioni da riga di comando:

	--enable test
	--enable test_1, test_2

	--disable test
	--disable test_1, test_2

	rkhunter -c --enable 'rootkits'
	rkhunter --check --enable 'rootkits, hashes'

sia attraverso il file di configurazione di rkhunter, modificando le opzioni:

	ENABLE_TESTS test
	ENABLE_TESTS test_1 test_2

	DISABLE_TESTS test
	DISABLE_TESTS test_1 test_2

	ENABLE_TESTS="suspscan hidden_procs deleted_files"
	DISABLE_TESTS="suspscan hidden_procs deleted_files"

Quando si usa l'opzione da riga di comando --disable, il programma rkhunter andrà a leggere anche l'opzione DISABLE_TESTS del file di configurazione, per decidere quali verifiche effettuare. Se si vuole evitare che venga letto anche il file di configurazione, aggiungere l'opzione --nocf, dalla riga di comando. Per chiedere di effettuare tutte le verifiche, nessuna esclusa, è possibile utilizzare i valori speciali:

	ENABLE_TESTS="all"
	DISABLE_TESTS="none"

	rkhunter -c --enable 'all'
	rkhunter --check --disable 'none'

Non è possibile chiedere "none" verifiche a ENABLE_TESTS, oppure "all" verifiche a DISABLE_TESTS. Se viene specificata una combinazione di verifiche abilitate e disabilitate, le verifiche disabilitate verranno eseguite solo se presenti nella lista delle verifiche abilitate. RKH ( rkhunter ) guarda, come prima cosa, i test disabilitati, per poi eseguire i test abilitati. Per esempio, nel caso seguente:

	rkhunter --enable 'rootkits,deleted_files' --disable malware

la verifica chiamata 'malware' viene disabilitata, poichè fa parte della verifica chiamata 'rootkits', mentre la verifica chiamata 'deleted_files' non verrà eseguita, visto che è parte della verifica chiamata 'malware', che è stata disabilitata.