Attacchi e intrusioni

Intrusion Detection Systems (IDS) su Linux

Le attività e i campi di applicazione di un Intrusion Detection System sono vari, al punto che spesso vengono gestiti da diversi software, che nel loro insieme provvedono ad accorgersi dei tentativi di attacco o scansione di un sistema, prevedere meccanismi di notifica (Email, log, Sms) e reazione secondo eventi anche proattivi in grado di bloccare sul nascere le comunicazioni con IP da cui arrivano pacchetti ostili.
L'evoluzione naturale di un IDS relativo ad un singolo host è il Network Intrusion Detection System (NIDS) che monitora il traffico di una intera rete.

I meccanismi di individuazione di attività sospette sono diversi, ma generalmente si concentrano su:
- Verifica dei log di sistema o di specifici programmi per individuare attività anomale;
- Controllo dell'integrità dei file locali, modifiche sospette possono essere sintono di una avvenuta irruzione;
- Monitoring dei pacchetti destinati all'host, sia per reagire a pattern di attacco noti che per accorgersi di un port scan da remoto, generalmente prologo di un tentativo di intrusione.

Il mondo OpenSource offre una moltitudine di strumenti utili per questi scopi, si va da piccoli programmi per specifiche attività a sistemi più complessi di qualità evolute.
Per essere veramente efficace, l'implementazione di sistemi di Intrusion Detection oltre a richiedere un sostanzioso intervento sistemistico per la configurazione e la customizzazione del software usato, deve essere tale da permettere una rapida analisi: troppi log e mail di notifica sono alla lunga controproducenti e inutili se a questo non segue un controllo effettivo.
Segue un breve elenco di alcuni dei programmi più noti per le attività di Intrusion Detection.

LOG ANALYZERS
Sono programmi che monitorano le entry nei file di log di sistema e possono essere configurati per eseguire date operazioni in presenza di determinate righe di log.
E' bene che agiscano in tempo reale, dal momento che dopo una intrusione una delle prime occupazioni di un hacker è quella di cancellare le tracce eventualmente lasciate sui log vari.
In questa categoria possono rientrare:
Swatch http://swatch.sourceforge.net/ - Può monitorare in tempo reale ogni tipo di file. E' in Perl e richiede alcuni moduli generalmente non installati di default e scaricabili da CPAN, nei file di configurazione si settano le regole di pattern matching dei log e i comportanti da adottare.
Logsurfer - http://www.cert.dfn.de/eng/logsurf/ - Ha caratteristiche simili a Swatch ma presenta alcuni miglioramenti, tra cui la possibilità di correlare gli output di diversi log e, al contempo, propone un file di configurazione più complesso (è consigliabile ispirarsi agli esempio di conf esistenti).
LogWatch - http://www.logwatch.org/ - Installato di default su alcune distribuzioni Linux come RedHat monitora diversi tipi di log, secondo impostazioni configurabili e genera i relativi alert e report.
Logcheck - Prodotto da Psionic, recentemente acquisita da Cisco. Non ha più un home page ufficiale.

A prescindere dal meccanismo di controllo dei log utilizzato, alcuni accorgimenti rendono l'operazione più efficace:
- Loggare, se possibile, su una macchina remota, in modo tale da impedire la manipolazioni dei log dopo un'intrusione;
- Nel definire le regole di log checking seguire una policy di logging di tutto tranne dei messaggi noti: definire delle regole di esclusione di righe di log lecite; definire regole per l'inclusione di speciali e noti eventi sospetti; includere tutto il resto (righe di log ignote o non previste).
- NON eseguire i programmi di log check come utente root, eventuali stringhe maligne nei log potrebbero generare risultati incontrollabili;
- Allo stesso modo, non visualizzare i log da un terminale potenzialmente sensibile ad un "TERMINAL EMULATOR ATTACK" tramite caratteri escape che vengono mal utilizzati o interpretati da certi terminali (Per dettagli: http://www.digitaldefense.net/labs/papers/Termulation.txt)

FILE INTEGRITY CHECKERS
Una volta fatta con successo un'intrusione, oltre a guardarsi intorno e cercare di capire dove si trova, un hacker che vuole mantenere l'accesso e la possibilità di rientrare nel sistema provvede ad cancellare le proprie tracce dai log, ad installare trojan e programmi che aprano nuovi accessi remoti, controllino le attività degli amministratori (packet sniffers, key loggers...) servano per attacchi successivi, lanciati dall'host già violato. Queste attività sono facilitate e in parte automatizzate da rootkit dedicati ma, in ogni caso, lasciano tracce sul sistema: nuovi file copiati, log e binari modificati, cancellazioni ecc.
Gli strumenti di Integrity Check aiutano ad individuare simili manipolazioni e generalmente registrano cambiamenti nella data di creazione o modifica di un file, alterazioni dei permessi, degli attributi o dello contenuto di file di configurazione, binari di comandi più o meno comuni, testi di log ecc.
Tripwire - http://www.tripwire.org - E' uno dei primi, più evoluti e utilizzati sistemi di Integrity Check.  Oltre alla versione OpenSource ne esistono complementi proprietari che facilitano l'integrazione e la centralizzazione dei dati da diversi sistemi remoti, rendendo più agevole il monitoraggio di molti host.
Aide - http://www.cs.tut.fi/~rammer/aide.html - Si presenta come l'alternativa completamente Free a Tripwire, ha una logica simile e prevede controlli della stessa natura tramite una varietà di algoritmi di checksum.
Integrit - http://integrit.sourceforge.net/ - Altra promettente e performante alternativa a Tripwire che si presta ad essere integrata in un sistema di monitoring che utilizza diversi strumenti.
Chkrootkit - http://www.chkrootkit.org - E' una serie di script dedicati alla individuazione di rootkit noti. Oltre a controllare lo stato di alcuni binari esegue controlli di altra natura (verifica sul proc filesystem ecc.), ma non va considerato come una soluzione generica.

Una caratteristica comune di questi e altri Integrity Checkers è quella di creare una snapshop preliminare dello stato dei file di un host "pulito", adattare la configurazione per il proprio specifico sistema, eliminare controlli che producono eccessivi false-positive (troppi warning tendono ad essere ignorati) e schedulare periodicamente un check dello stato attuale del sistema rispetto allo snapshot iniziale.
In tutti i casi ci sono alcune precedure di base che è giusto seguire per migliorare la sicurezza e l'affidabilità di simili strumenti:
- Copiare i database di snapshot su un sistema remoto o comunque un mezzo non scrivibile dall'host a cui si riferiscono;
- Considerare che un checksum non è infallibile ed esistono metodi per mantenere lo stesso checksum in un file modificato (quantomeno per md5, l'algoritmo più utilizzato in questi casi);
- Controllare effettivamente i log generati e rifinire gradualmente la configurazione per evitare segnalazioni errate, falsi positivi, per file che vengono modificati a causa di normali attività sul sistema.  

PORT SCANS DETECTORS
Preludio ad ogni tentativo di intrusione è quasi sempre un network scanning remoto, con cui l'attaccante cerca di individuare le porte aperte sui sistemi bersaglio. Nonostante le tecniche di port scanning siano piuttosto evolute (nmap, per esempio, permette almeno 6 diversi tipi di scanning, più o meno "stealth") esistono sistemi per individuarle e, quindi, sapere prima ancora di subire l'attacco, quali IP remoti stanno raccogliendo informazioni sui propri sistemi.
Sebbene ogni cracker accorto cercherà di non eseguire alcuna operazione di probing o hacking, direttamente dal proprio IP, sapere da quali indirizzi può provenire una minaccia è sempre utile.
I programmi più noti per individuare un port scanning sono:
ScanLogD - http://www.openwall.com/scanlogd/ Viene eseguito come un demone, costantemente in monitoraggio di collegamenti a porte TCP locali. Utilizza dei metodi per evitare disservizi o problemi nel gestire tentativi di DOS e discriminare dei veri e propri scan da attività più innocue.
PortSentry - Anch'esso progetto della Psionic di cui non esiste più un Home ufficiale, prevede meccanismi di detection anche di stealth scan, con la possibilità di bloccare tutti gli accessi dagli indirizzi che eseguono scan o azioni ostili.

In genere un semplice port scan detector ha funzioni limitate e può essere sostituito con migliore efficacia da un NIDS in grado di individuare, oltre a normali port scan una varietà di attività di rete sospette.

NIDS, IDS, HIDS
Il mondo OpenSource offre una discreta varietà di NIDS, HIDS (Host Intrusion Detection Systems) e IDS che, però, generalmente difettano nelle interfacce di reporting e gestione, oltre che nella facilità di installazione, per le quali molte alternative commerciali offrono soluzioni più evolute.
Snort - http://www.snort.org - E' il progetto NIDS più noto nella comunità OpenSource. Seppur di non banale gestione e con un sistema di reporting piuttosto grezzo, viene utilizzato come base da molti altri prodotti che ne estendono le funzionalità migliorando la gestione e i meccanismi di reporting. Le policy di packet matching sono costantemente aggiornate sulla base di nuove vulnerabilità.
Tamandua - http://tamandua.axur.org/ - E' un progetto relativamente poco conosciuto ma interessante, è possibile convertire le regole scritte per Snort sul database di Tamandua e sono previste tutte le features tipiche di un NIDS.
Prelude - http://www.prelude-ids.org/ - E' un interessante ibrido fra un NIDS e un HIDS, che presenta sia sensori per il traffico di rete che sensori per il singolo host. Vanta prestazioni superiori a SNORT e una buona modularità.

Un buon NIDS è un ottimo strumento per avere un'idea della variegata fauna di pacchetti che arrivano ad una rete pubblica e, se ben configurato, può indubbiamente troncare sul nascere molti tentativi di intrusione.
Alcune raccomandazioni di massima valgono per ogni NIDS:
- Selezionare con cura le regole di packet matching, cercando di evitare falsi positivi troppo verbosi o relativi a rischi molto relativi (il logging di ogni PING ai nostri sistemi è assolutamente inutile).
- Tenere ragionevolmente aggiornate le regole di matching, appoggiandosi ai database online.
- Tenere in un luogo particolarmente protetto la macchina centrale, se esistono diverse sonde nella rete, o comunque quella in cui i dati vengono raccolti ed elabotati.
- Controllare con costanza le segnalazioni di warning e minacce, avendo la pazienza di rifinire le proprie configurazioni per evidenziare solo gli eventi più significativi.
- Non esagerare a implementare, o quantomeno verificare con regolarità, meccanismi proattivi che bloccano ogni comunicazione con IP da cui arrivano pacchetti molesti. Questi IP possono venire spoofati e un soggetto ostile può creare una sorta di auto DOS attack, facendo bloccare al nostro IDS comunicazioni con normali e validi indirizzi IP.

Logwatch: Installazione e configurazione

Logwatch è uno degli strumenti di log monitoring più interessanti fra quelli disponibili nel panorama opensource:
- E' modulare, permettendo customizzazione, adattamente ed estensioni;
- Si installa facilmente e su alcune distribuioni è operativo ed efficace senza alcuna necessità di configurazione post-installazione

La sua modalità di funzionamento non è in real-time: quando viene eseguito processa i log e invia una mail di report (di default a root), per cui si presta ad essere crontabbato, con tutte le limitazioni, in termini di sicurezza, del caso: se un intrusore fa in tempo a modificare i log e cancellare le sue tracce, LogWatch non si accorge di nulla. Si accorge però di tentativi di Intrusione, di attività sul sistema (anche legittime, di cui comunque è bene avere traccia) e di eventi anomali.

INSTALLAZIONE
Logwatch è composto fondamentalmente da script Perl e file di configurazione, non richiede ricompilazioni o adattamenti particolari a seconda della piattaforma, se non la configurazione sulla posizione e i nomi dei file di log.
Se si installa tramite RPM, LogWatch è immediatamente operativo e non richiede ulteriori interventi di configurazione. Installa i seguenti file:
[root@socrate /]# rpm -ql logwatch
/etc/cron.daily/00-logwatch E' un link simbolico a /etc/log.d/scripts/logwatch.pl, che di fatto è il programma vero e proprio, che quindi viene eseguito ogni giorno (comando logwatch senza particolari argomenti)
/etc/log.d La directory che contiene tutto "il mondo logwatch"
/etc/log.d/conf Directory che contiene i file di configurazione
/etc/log.d/conf/logfiles Directory che contiene le configurazioni per i singoli tipi di log
/etc/log.d/conf/logfiles/cron.conf [...]
/etc/log.d/conf/logwatch.conf File di configurazione generale, imposta tutti i parametri standard che vengono usati quando il comando logwatch viene lanciato senza argomenti
/etc/log.d/conf/services Directory che contiene le configurazioni per i tipi di servizi
/etc/log.d/conf/services/automount.conf [...]
/etc/log.d/logwatch Link al programma logwatch: /etc/log.d/scripts/logwatch.pl
/etc/log.d/logwatch.conf Link al file di configurazione: /etc/log.d/conf/logwatch.conf
/etc/log.d/scripts Directroy che contiene tutti i script Perl di logwatch e i suoi moduli
/etc/log.d/scripts/logfiles directory che contiene script per la gestione di file di log specifici
/etc/log.d/scripts/logfiles/samba [...]
/etc/log.d/scripts/logwatch.pl Il programma logwatch vero e proprio. Il fatto che esista il link /usr/sbin/logwatch fa in modo che possa essere evocato semplicemente scrivendo "logwatch"
/etc/log.d/scripts/services Directory con i filtri modulari per il parsing di specifici servizi
/etc/log.d/scripts/services/automount [...]
/etc/log.d/scripts/shared Directory che contiene i filtri comuni per tutti i servizi e tipi di log
/etc/log.d/scripts/shared/applystddate [...]
/usr/sbin/logwatch Link al programma logwatch: /etc/log.d/scripts/logwatch.pl
/usr/share/doc/logwatch-2.6 Directory con la Documentazione ufficiale
/usr/share/doc/logwatch-2.6/CHANGES [...]
/usr/share/man/man8/logwatch.8.gz Pagine del man di logwatch

Se si ha a disposizione il tar.gz di logwatch, l'installazione è ugualmente semplice:
- Scompattare il tarball;
- Copiare tutto il contenuto della directory creata in /etc/log.d (Se si cambia la directory di default, si deve cambiare la variabile $BaseDir all'inizio di logwatch.pl;
- Editare, se si vuole il file di configurazione generale logwatch.conf;
- Crontabbare, secondo la frequenza che si desidera, l'esecuzione di logwatch.pl (senza particolari argomenti).

CONFIGURAZIONE
Il file di configurazione generale /etc/log.d/logwatch.conf è piuttosto chiaro e prevede alcune opzioni interessanti, che possono essere sovrascritte dalla riga di comando. Seguono le impostazioni di default, che vanno bene in molti casi:
LogDir = /var/log Directory di default dove risiedono i log
MailTo = root A chi vengono inviate le mail di logwatch, può essere un utente locale o un normale indirizzo email
Print = No Se settato a Yes, l'output di logwatch viene visualizzato a schermo invece di essere inviato via mail
# Save = /tmp/logwatch Se impostato, l'output viene salvato sul file indicato invece di essere inviato via mail
# Archives = Yes Specifica se cercare anche nei file di log archiviati (anche gzippati) come /var/log/messages.1 o /var/log/messages.1.gz
Range = yesterday Indica su quale periodo fare l'analisi dei log: "All" analizza tutti i log (in questo caso si consiglia di impostare "Archives = Yes", "Yesterday" si riferisce ai log del giorno prima (utile quando si crontabba un esecuzione notturna), "Today" si riferisce alle righe di log relative al giorno corrente.
Detail = Low Livello di dettaglio dei report. Può essere "Low", "Med", "High"
Service = All Definisce per quali servizi verificare i log. Può essere "All" o uno o più servizi, da scrivere su più righe, come "pam_pwdb" e "ftpd-messages"
# LogFile = messages Specifica un singolo file di log da analizzare. Se "Service = All" vengono comunque analizzati tutti i log

UTILIZZO
La modalità di utilizzo tipica è l'esecuzione in crontab del semplice comando logwatch (su varie distribuzioni è un link simbolico /etc/log.d/scripts/logwatch.pl) che si basa sulle impostazioni generali nel file di configurazioni. Per test o controlli straordinari si possono comunque passare alcuni argomenti alla command line:

logwatch --print --detail High --archives --range All
Stampa a video (--print) invece che inviare via mail, con il massimo dettaglio (--detail High), includendo anche i log archiviati (--archives) tutti i messaggi di ogni data (--range All)

logwatch --save logwatch.txt --range Today
Salva sul file logwatch.txt (--save logwatch.txt) l'output relativo alla giornata corrente (--range Today), usando per gli altri paramentri le impostazioni definite nel file di configurazione.

Introduzione e installazione di Tripwire

Tripwire è un tipo di Intrusion Detection System, il suo lavoro è quello di verificare lo stato di determinati file rispetto ad uno stato di partenza (baseline). Una modifica non prevista di questo stato può essere indice della compromissione del sistema e della manipolazione non autorizzata di comandi, log o file di configurazione.
Esistono due versioni di Tripwire, una commerciale ed una Open Source.

Come punto di partenza Tripwire crea un database con all'interno una "fotografia" dei file del sistema in uno stato che iniziale che viene considerato sicuro. D'ora in poi Tripwire sarà in grado di controllare se ci sono state modifiche (nel contenuto, nella data di modifica, nei permessi, negli attributi...) o cancellazioni dei file presi in considerazione informando l'amministratore di sistema attraverso un rapporto.
Se le modifiche sono legittime, perchè dovute a normale attività del sistema, l'amministratore può aggiornare la baseline del database di Tripwire inglobando il nuovo status, altrimenti se le modifiche non vengono ritenute valide l'amministratore può immediatamente verificare quali componenti sono stati alterati.
Tripwire permette inoltre di criptare i suoi file di configurazione rendedoli modificabili solo attraverso l'inserimento di password creata in fase di installazione.
Sono richieste due password:
- la site password, di carattere generale, utilizzata per il file di configurazione e policies; può essere utlizzata per altre macchine esportando il file site.key
- la local password per il file database e i report

INSTALLAZIONE
Installazione di Tripwire tramite rpm:
[root@giove root]# rpm -ivh tripwire-2.3.1-14.i386.rpm
Preparing...                ########################################### [100%]
   1:tripwire               ########################################### [100%]

Directory create:
/var/lib/tripwire ---> directory in cui verranno memorizzati i rapporti e il database di sistema
/etc/tripwire     ---> si trovano i file di configurazione e le key di codifica

Post-Install
Per completare l'installazione è necessario eseguire lo script  twinstall.sh (nella dir /etc/tripwire/) il quale crea le password dei file di configurazione e produce le key di codifica  
[root@giove tripwire]# ./twinstall.sh

----------------------------------------------
The Tripwire site and local passphrases are used to
sign a variety of files, such as the configuration,
policy, and database files.

Passphrases should be at least 8 characters in length
and contain both letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
# Richiede l'inserimento della site password
Enter the site keyfile passphrase:
......
# Richiede l'inserimento della local password
Enter the local keyfile passphrase:
Verify the local keyfile passphrase:

FILE di CONFIGURAZIONE
I file di configurazione sono:
tw.cfg (criptato) vengono memorizzati i dati riguardanti la locazione dei file di configurazione e i paramentri per l'invio di email (twcfg.txt file di esempio non criptato).

tw.pol (criptato) file in cui viene specificata la modalità di funzionamento di Tripwire e le policy di controllo. Sono elencati i file da monitorare e il livello di "criticità" a loro assegnato (twpol.txt è un esempio non criptato).

INIZIALIZZAZIONE del SISTEMA
I file di configurazione e dati di Tripwire sono per sicurezza criptati, la loro modifica è possibile attraverso comandi che creano un file di testo relativo al file da modificare.

- Modifica del file tw.cfg:
[root@GIOVE tripwire]# twadmin --print-cfgfile > conf.txt
In questo modo viene creato il file conf.txt dove saranno leggibili i parametri di configurazione di Tripwire.

Per validare le modifiche effettuate sul file è necessario creare il nuovo file di configurazione specificando la "site key":
[root@GIOVE tripwire]# twadmin --create-cfgfile --site-keyfile /etc/tripwire/site.key conf.txt
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg
Le modifiche al file di configurazione sono ora attive.

- Creare il file tw.pol (file delle policies):
Prima di modificare le policy di tripwire bisogna creare il file da editare utlizzando il file tw.pol standard:
[root@GIOVE tripwire]# twadmin --print-polfile tw.pol > polfile.txt

Ora è possibile editare il file polfile.txt secondo le proprie necessità. Per rigeneraere il tw.pol definitivo si usa il comando:
[root@GIOVE tripwire]# tripwire --create-polfile polfile.txt

- Creare il database di sistema
Nel database di sistema verranno introdotti tutte le voci riguardanti i file da controllare secondo il file di configurazione tw.pol
[root@GIOVE tripwire]# tripwire --init
Please enter your local passphrase:
Incorrect local passphrase. # Ops!
Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Performing integrity check...
Nel caso alcuni file specificati in tw.pol non esistono il comando visualiza messaggi di errori
### Warning: File system error.
### Filename: /var/lock/subsys/portmap
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /var/lock/subsys/httpd
### No such file or directory
.....
# la locazione del file database è definita nel file di configurazione tw.cfg
Wrote database file: /var/lib/tripwire/GIOVE.twd
The database was successfully generated.

Tripwire è ora configurato, inizializzato e pronto per essere eseguito ed eventualmente schedulato per eseguire dei report sulle modifiche dei file del sistema:
[root@GIOVE tripwire]# tripwire --check

Individuare l'installazione di un rootkit

Una volta installato, un buon rootkit è, per natura, difficile da individuare proprio perchè tende a nascondere le tracce della propria esistenza.
Esistono tuttavia diversi metodi per individuarne la presenza che possono essere più o meno efficaci a seconda della natura del root kit:
- Il primo, più semplice, e piuttosto efficace è l'utilizzo di CHKROOTKIT, che è in grado di individuare sul sistema un numero sempre maggiore di rootkit.
- Verificare se il numero dei processi e i relativi PID che si visualizzano con ps è diverso da quello che si vede in /proc. Questa procedura, relativamente veloce, non funziona con rootkit basati su un modulo del kernel.
- Verificare con un port scanning da una macchina esterna, se sul sistema indagato sono aperte porte che non dovrebbero essere aperte e non vengono visualizzate con un netstat locale. Questo sistema non funziona con rootkit che modificano demoni esistenti come telnetd o sshd e tramite loro (e quindi tramite le rispettive porte) permettono accessi remoti non autorizzati.
- Indagare sempre quando un server si riavvia o si blocca senza apparente motivo o un servizio cade o comunque si riscontrano anomalie nel suo funzionamento: possono essere tutti indici di DOS attack o tentativi di intrusione o tentativi di installazione di un rootkit.
- Eseguire comandi come ls, ps, find da una fonte sicura (CDROM, NFS in read mode ecc.) e verificare se il loro output da risultati diversi dai rispettivi comandi di sistema. Questo metodo non funziona con rootkit kernel based.
- Verificare in /dev se esistono nomi di device sospetti, in particolare device pty senza numeri successivi (es: /dev/ptyr).
- Verificare negli script di startup del sistema se vengono lanciati comandi non noti: ogni rootkit deve garantirsi l'esecuzione in memoria al riavvio.
- Monitorare la banda utilizzata da ogni singolo server (MRTG è lo strumento ideale) e indagare quando si notano picchi di traffico anomali: non di fado una macchina compromessa viene utilizzata come repository di warez.
- Verificare su www.incidents.org se il proprio IP risulta nel database degli attackers: se lo è o siamo hacker maldestri o qualcuno sta usando la nostra macchina per lanciare attacchi altrove.

Come prevenire / intercettare l'installazione di un rootkit

Fra i metodi per difendersi dall'installazione sul proprio sistema di un rootkit ci sono:
- Innanzitutto impedire che un utente possa bucare il proprio sistema utilizzando security bug noti sui servizi in produzione, quindi mantenere il proprio sistema protetto e aggiornato;
- Utilizzare tool come TRIPWIRE che eseguono un check costante dell'integrità dei file di sistema;
- Utilizzare, su macchine in produzione, un kernel monolitico non modulare, che renderebbe impossibile l'installazione di un rootkit basato su un modulo del kernel (non basta con rootkit dell'ultima generazione che si basano su /dev/kmem);
- Utilizzare strumenti come LIDS che limitano permessi e accesso alle risorse del sistema a livello di singoli processi (se ben configurato LIDS appare come la soluzione estrema e più efficace);
- Usare un demone come RKDET, che si accorge quando un interfaccia di rete entra in promiscous mode e invia mail, disattiva il networking o esegue altre operazioni di conseguenza;
- Garantirsi l'integrità dei log: stampandoli direttamente su carta o inviandoli ad un syslog server remoto (protetto);
- Avere un sistema che non può montare in write mode le directory /sbin, /usr/sbin, /bin e /usr/bin, impedendo che i comandi ivi contenuti possano essere modificati. Contestualmente è necessario verificare che la $PATH della shell non venga modificata.

(Bad) Hackers' Tools: rootkits

Un rootkit è una collezione di tool che permette ad un cracker di cancellare le proprie tracce e assicurarsi la possibilità di rientrare sul sistema bucato, senza dover riutilizzare il buco di sicurezza con cui originariamente ha preso possesso della macchina.

I rootkit non servono per violare un sistema, vengono utilizzati solo quando è stato già compromesso e nella gran parte dei casi possono essere installati solo dall'utente root.
Generalmente un rootkit comprende:
- Un network sniffer, per registrare login e password utilizzate sulla o dalla macchina violata, in modo da estendere il raggio d'azione dell'intrusore e la qualità e quantità di informazioni in suo possesso;
- Un keystroke logger, che registra quanto digitato dall'utente direttamente in console;
- Dei log wipers, script che cancellano automaticamente le tracce dell'intrusione dai log di sistema;
- Versioni modificate (trojans) di comandi di sistema comunemente utilizzati che possono rivelare l'esistenza del rootkit: ls, netstat, ifconfig, ps, killall, find, top.
- Una backdoor che accetta connessioni remote sia appoggiandosi ad una porta locale (nascosta dal netstat modificato) che modificando le versioni sul sistema di server telnet, ssh o analoghi.

Esistono diversi tipi di rootkit con diverse peculiarità, in genere, quelli per Linux, si possono inquadrare in due grandi famiglie:
- Quelli che lavorano in user space, sostituendo comandi ed eseguendo processi estranei;
- Quelli che lavorano in kernel space, presentandosi come moduli del kernel stesso. Una evoluzione di questi ultimi sono i rootkit che scrivono direttamente in memoria tramite /dev/kmem e funzionano anche su kernel non modulari.

I primi sono generalmente più semplici da trovare: per un system administrator basta verificare se l'output di un ps (che in presenza di un rootkit è stato sicuramente trojanato) mostra meno processi, con relativo PID, di quanti vengono visualizzati nel /proc file system (dove esiste una directory con nome del PID per ogni processo in esecuzione sul sistema). Utilizzando inoltre versioni "sicure" di comandi tipo ps, find, ls, netstat (che si è certi essere integre e non modificate, perchè, per esempio, compilate staticamente ed eseguite da un file system che può essere montato solo in read mode (per esempio un CDROM)) la presenza di simili rootkit verrebbe smascherata senza particolari problemi.
I secondi sono invece molto più subdoli e complessi. Lavorando direttamente come moduli del kernel intercettano le chiamate di sistema di qualsiasi processo e modificano il risultato secondo quanto definito dall'intrusore. In questo modo possono nascondere anche directory nel /proc filesystem e modificare l'output di comandi integri.
In questi casi può essere utile uno strumento come chkrootkit per trovare l'esistenza di un rootkit nel sistema.

Per poter risiedere in memoria anche dopo un riavvio, l'esecuzione del servizio del rootkit che permette l'accesso remoto deve essere lanciata da qualche script o comando di avvio.
Una volta in memoria, tipicamente, il processo maligno non viene visualizzato tramite l'uso di comandi tipo ps e top, la cartella dove fisicamente risiede viene nascosta a comandi come ls, find e cat e le porte su cui ascolta non vengono visualizzate con netstat.

Password cracking

Per password cracking si intendono tutte quelle operazioni che permettono di reperire una password da una fonte di informazione come ad esempio un file criptato. Questi tipi di attacchi possono essere effettuati in numerevoli modalità sia da remoto, ad esempio con un Brutal force attack (un attacco che mira ad accedere al sistema tramite tentativi di login a ripetizione finchè non si trova un utente e una password validi) oppure in locale, tramite appositi tools come Crack che analizzano file come /etc/passwd.

Nei vecchi sistemi Unix queste stringhe criptate venivano salvate e verificate tramite il file /etc/passwd, durante il processo di login: username e relativa password venivano confrontati con le entry di questo file tramite la funzione chiamata crypt(), se questa funzione riproduceva una password criptata identica a quella inserita nel file l'utente poteva accedere.
L'inconveniente era che il file /etc/passwd doveva essere leggibili da ogni utente del sistema e quindi le password ivi criptate potevano essere viste da chiunque rendendo vulnerabile il sistema ad un password attack.
Per ovviare a questo problema ci si è appoggiati ad un secondo file leggibile solo da root, /etc/shadow (nella maggior parte degli *nix) il quale contiene le password criptate, ovviamente sempre affiancato a un /etc/passwd (sempre leggibile da chiunque) senza le password criptate.
Ormai tale configurazione è quella adottata da tutte le distribuzioni GNU Linux dove sono a disposizione (in configurazione standard) due algoritmi di criptazione one-way DES e MD5, i due algoritmi sono in grado di generare una stringa criptata da una password ma non viceversa e rendono "difficile" effettuare un cracking della password in poco tempo.
Inoltre occorre sottolineare che il cracking delle password non viene effettuato solo per eseguire un login su una shell ma in tutti quei casi in cui occorre inserire usename e password per accedere ad un servizio, dunque occorre prestare attenzione non solo alle password di sistema ma anche a quelle dei servizi correlati (per esempio gli accessi via web ad un'area protetta).
Al riguardo va fatta attenzione a dove viene mantenuto l'eventuale file delle password, da quali utenti è leggibile, se esistono password di default (che vanno ovviamente cambiate) o accessi anonimi.

Esistono innumerevoli tools come Crack o John the ripper che semplificano le operazioni di password cracking, questi stessi strumenti possono essere utilizzati dallo stesso system administrator per verificare la robustezza degli account sul proprio sistema.

Sniffing di pacchetti in rete

L'attività di monitorare i pacchetti di rete che arrivano al proprio computer si chiama sniffing.
Ogni sistema su una rete IP scambia informazioni con altri sistemi tramite singoli pacchetti che hanno un IP sorgente e un IP destinazione. Tipicamente un computer analizza e processa solo i pacchetti che arrivano al suo dispositivo di rete (una scheda ethernet, un modem ecc.) che hanno come IP di destinazione il proprio o che sono pacchetti di broadcast, indirizzati cioè ad ogni indirizzo IP attivo nello stesso network IP.

L'attività di sniffing il più delle volte è necessaria per monitorare e diagnosticare problematiche di rete ma può essere impropriamente utilizzata per intercettare informazioni sensibili di terzi, come login e password di accesso ad un determinato servizio.
Si possono sniffare pacchetti su ogni interfaccia di rete, ma tipicamente viene fatto su una scheda ethernet, per la quale possono esistere due tipi di ambienti tipici:
- Rete shareata, dove tutte le schede di rete dei computer nella rete locale ricevono TUTTI i pacchetti, anche quelli destinati ad altri indirizzi IP. In questo caso (rete ad anello con cavo coassiale oppure rete a stella con un hub centrale) le schede di rete dei PC normalmente selezionano solo i pacchetti destinati a loro e scartano tutti gli altri che attraversano il mezzo trasmissivo a cui sono collegati.
- Rete switchata, dove ogni PC riceve solo i pacchetti di broadcast o quelli destinati al proprio IP. Questa è tipicamente una rete a stella con uno switch al centro, che provvede autonomamente a forwardare ad ogni sua singola porta solo i pacchetti destinati all'IP del dispositivo collegato a quella porta, oltre ai broadcast, che vengono sempre propagati su tutte le porte.

Nel primo caso l'attività di sniffing permette di analizzare anche pacchetti destinati e originati da indirizzi terzi, ampliando notevolmente le possibilità di intercettare informazioni sensibili.
In una rete switchata, invece, quando si prova a sniffare i pacchetti che passano per l'interfaccia di rete, si possono solo incontrare pacchetti originati dal o destinati al computer locale, oltre ai soliti broadcast.
Esiste tuttavia una tecnica piuttosto evoluta (arp spoofing) tramite la quale è possibile sniffare pacchetti di terzi anche in una rete switchata.

Quando si vogliono sniffare pacchetti destinati a terzi, si deve impostare il "PROMISCUOUS MODE" sull'interfaccia di rete, in modo da farle processare tutti i pacchetti indifferentemente.

Esistono diversi strumenti di sniffing, alcuni sono esplicitamente realizzati per attività di hacking (Sniffit, Ettercap, Dsniff...) e evidenziano le login e le password che sono state intercettate, altri sono più orientati alla risoluzione di problematiche di rete (Ethereal, simile al Windows Network Monitor) e permettono l'analisi di tutti i pacchetti intercettati, altri hanno funzioni di monitoring e analisi a volte limitandosi a considerare solo le intestazioni dei pacchetti (tcpdump, snoop, iptraf, ntop).

Il motivo principale per cui si preferisce cercare di criptare ogni passaggio di login e password in rete (https, ssh, pop3s, sftp ecc.) è proprio per evitare che qualcuno, tramite sniffing, li possa intercettare e facilmente scoprire.

Effetti e sintomi di una intrusione

Gli strumenti di Intrusion Detection disponibili sul mercato automatizzano controlli e operazioni che possono essere saltuariamente eseguite a mano o tramite strumenti inizialmente pensati per altri scopi.

I mezzi e i modi con cui ci si può accorgere della avventua intrusione in un sistema possono essere vari:
Picchi di banda, di solito in uscita, non spiegabili. Tramite strumenti come MRTG è possibile visualizzare velocemente il traffico generato da un host nel corso del tempo (giorni, settimane, mesi, anni). Questi grafici possono evidenziare con un colpo d'occhio, eventuali attività di rete anomale, in quanto a quantità. Sta poi all'ammnistratore approfondirne i motivi, che possono essere assolutamente legittimi.
Rapida occupazione di spazio su disco, che può essere dovuto ad un DOS attack che mira a saturare i log di sistema o all'uso di una macchina violata come repository per warez (software copiato, materiale pornografico... ) di varia natura. In questo caso parallelamente all'ocupazione di spazio su disco, è plausibile un aumento dell'occupazione di banda.
Defacing di un sito, è il modo più rapido e definitivo per individuare un'intrusione (e farsi individuare). I motivi per cui qualcuno possa cercare di modificare l'home page di un sito sono vari (rappresaglia ideologica o politica, semplice esibizionismo, scherno...), gli effetti sono spesso deleteri per l'immagine di chi gestisce il sito ma dal punto di vista tecnico questo risparmia agli amministratori il rischio di avere per ulteriore tempo una macchina violata su cui un intrusore può fare quello che vuole.
Comportamenti anomali del sistema, di varia natura. Possono essere malfunzionamenti o "cose strane" e inusuale che accadono sul sistema o su alcuni suoi processi. Possono avere svariate cause: malfunzionamenti hardware (problemi di disco, memoria, processore, bus ecc), software (bug, implementazioni errate) o anche essere dovuti ad una intrusione (binari modificati, trojan, modifiche al sistema).
Blocco di un processo o del sistema. Può capitare che per motivi non chiari il sistema vada in crash o un singolo processo che magari gestisce un servizio pubblico muoia. Quando accade di solito si riavvia la macchina o il processo e si ritorna a fare altro. Quando accade, in realtà, è il caso di provare ad analizzare i motivi del problema. Anche in questo caso possono essere dovuti al malfunzioanmente dell'hardware, ad un bug di un programma o anche essere conseguenza di un attacco che può anche essere andato a buon fine.
Modifica o cancellazione di log. Se ci si accorge di un simile evento (tipicamente tramite programmi di Integrity Check, ma anche con casuali osservazioni manuali o utilizzo di comandi come last o lastlog) dovrebbero subito scattare un po' di allarmi nella nostra mente e le relative verifiche. Un log è fatto per incrementare costantemente di dimensioni, senza subire modifiche nei suoi contenuti precedenti.
Notifica di amministratori di sistemi remoti che rileva attività ostile da parte dei nostri IP. In questo caso l'intrusore potrebbe utilizzare i nostri sistemi per sferrare attacchi o scan su altri sistemi in rete. Gli IP che risultano ostili sono i nostri (con le potenziali complicazioni legali del caso) per cui è necessario intervenire e verificare in fretta.
Il proprio IP è segnalato su DShield. Un ottimo strumento per verificare se un proprio IP risulta fra quelli da cui sono sferrati attacchi in rete è il sito DSHIELD, è una sorta di Distributed Intrusion Detection System, in cui sono raccolti i log degli IDS di chi contribuisce al progetto e vengono segnalati gli indirizzi IP da cui arrivano la maggior parte degli attacchi.
Esiste una comoda pagina in cui si può inserire un indirizzo IP e visualizzarne varie informazioni tra cui se è stato origine di attività ostile: http://www.dshield.org/ipinfo.php  
Nuovi utenti sul sistema, che non ci sono familiari, sono sicuramente un sintomo che dovrebbe sollevare più di un sospetto. I nomi degli utenti possono essere sfacciati (r00t, 0wn3d, dud3) o più camuffati (bins, lpr) ma se hanno a disposizione una shell che non dovrebbero avere e, soprattutto, se non si conosce il motivo della loro presenza, bisogna subito allertarsi e verificare. Non è detto che un cracker abbia bisogno di crearsi un nuovo utente per tornare sul sistema, ma se succede è evidente dimostrazione di una avvenuta intrusione.
Interfacce di rete promiscue indicano nella maggior parte dei casi che qualcuno sta provando a sniffare il traffico di rete e, per individuare anche i pacchetti non direttamente indirizzati alla macchina locale, mettono l'interfaccia di rete in "promiscuous mode". Analogamente una doppia entry nella arp cache con lo stesso IP che risulta appartenere a 2 diversi Mac Address, è sintono di una probabile attività non lecita di arp spoofing.

Utilizzo di SNORT come NIDS

Un NIDS (Network Intrusion Detection Systems) è un sistema di monitoring di traffico di rete, volto ad individuare pattern di pacchetti potenzialmente ostili in risposta ai quali possono essere eseguite determinate azioni (notifica via mail, chiusura di una connessione, logging su un database ecc.).
Snort presenta vari modi per essere configurato come NIDS.

Innanzitutto prevede 3 tipi principali di regole:
-ALERT invia messaggi ad ogni infrazione;
-PASS non considera il pacchetto;
-LOG visualizza/scrive le informazioni del pacchetto;

Lo standard di Snort è stampare a video i messaggi di alert ma è possibile utilizzare altre modalita':
-full, visualizza l'intero messaggio
-fast, logging rapido dei messagggi
-unsock, invio dei messaggi ad un socket unix
-syslog, scrittura dei messaggi nel syslog di sistema
-smb messages, invio di messaggi di alert ad altri host tramite samba
-none, non invia nessun messaggio

Per le opzioni full,fast,unsock e none è necessario anteporre il comando -A mentre con -s i messaggi di alert vengono inviati al syslog. Per abilitare a Snort l'invio di messaggi tramite il samba client, una sorta di Winpopup, è necessario aggiungere l'opzione "--enable-smbalerts" in fase di installazione di Snort.

snort -c snort.conf -l /var/log/snort -h 192.168.0.0/24
salva i log nella dir /var/log/snort prendendo in considerazione la rete 192.168.0.0/24

snort -c snort.conf -b -h 192.168.0.0/24 -M HOSTS
salva i dati in modalità tcpdump (meno informazioni ma più veloce), invia gli alert alle workstation windows

snort -c /etc/snort.conf -l /var/log/snort -h 10.1.0.0/24 -aIe -D
mostra i pacchetti ARP, aggiunge il nome interfaccia al log, mostra il layer secondario del pacchetto e con -D agisce come demone senza occupare una shell