La gestione degli incidenti informatici
v 0.2

1. Introduzione

Questo documento segue abbastanza fedelmente le linee guida riportate in [1], fatte salve le necessarie modifiche per tenere conto delle specifiche situazioni a cui si rivolge e gli aggiornamenti resi necessari dall’evolvere della situazione tecnologica.

Anche se il documento è strutturato come un “ricettario”, va tenuto presente che l’argomento trattato, vista la sua variabilità, non è facilmente organizzabile in uno schema rigido come quello esposto. In altri termini: non si tratta di consigli validi in assoluto, ma solo nella maggior parte dei casi. È sempre all’amministratore del sistema, con la sua conoscenza della realtà locale, che spetta la decisione finale sull’opportunità o meno di certe misure.

In tutto il documento seguente, salvo esplicita indicazione contraria, quando si fa riferimento a problemi di “sicurezza”, ci si riferisce sempre alla sicurezza informatica.

2. Operazioni preliminari

Per essere in grado di rispondere efficacemente ad una situazione di improvvisa emergenza quale quella provocata da un incidente di sicurezza, è ovviamente necessario avere predisposto in anticipo una serie di procedure e strumenti che permettano di capire che cosa sta succedendo e come porvi rimedio.

2.1 Backup

Tutti i sistemi critici devono essere salvati periodicamente su di un supporto non raggiungibile da eventuali intrusi: né fisicamente, né via rete.

Le copie di backup e le procedure di ripristino vanno verificate periodicamente.

Con la stessa cura delle copie di salvataggio vanno anche conservati i supporti utilizzati per installare il sistema operativo (ad es. le distribuzioni di RedHat Linux) e le eventuali patch, in modo da essere sempre in grado di ripristinare il sistema all’ultima configurazione stabile. Va posta particolare attenzione alle patch, i cui file sorgente (ad es. rpm) devono essere salvati su di un supporto stabile (ad es. cd-rom) e non eliminati dopo la loro applicazione.

È necessario eseguire periodicamente dei test sull’integrità dei file di sistema, in particolare subito dopo ogni installazione (ad es. via aide [9]). È fondamentale che i database delle checksum siano conservati offline o su di un supporto protetto dalla scrittura.

2.2 File di log centralizzati

È importante che i file di log di tutte le macchine critiche siano registrati anche su di una macchina dedicata e accuratamente protetta. In questo modo, anche se l’intruso elimina i file di log sul sistema attaccato, rimane possibile cercare di ricostruire l’accaduto.

Nel caso di sistemi unix, per inviare copia dei log su di un sistema remoto bisogna aggiungere delle righe come la seguente in syslog.conf:

*.info;mail.none;authpriv.none @loghost

dove loghost è il nome del log server.

Per ridurre i rischi di attacchi di DoS al server di log, il suo syslogd deve essere configurato in modo da accettare input solo dalle macchine servite.

Uno strumento che può essere di aiuto per esaminare i file di log, anche in tempo reale, è wots [10].

2.3 Mantenersi informati

È fondamentale essere al corrente delle ultime vulnerabilità, in modo da poter decidere se i propri sistemi debbano o meno essere aggiornati.

Riteniamo che come ragionevole compromesso tra completezza di informazione e tempo disponibile siano sufficienti le seguenti mailing list:

§ CERT/CC mailing list [2];

§ Security Alert di GARR-CERT [3].

Nel caso si desideri una maggiore informazione (e si abbia il tempo disponibile) esistono numerosi portali specificamente dedicati al problema ([4]-[8]). Una mailing list ha il vantaggio che non richiede una partecipazione “attiva”.

2.4 Strumenti

Per gli strumenti di network intrusion detection si rimanda allo specifico documento.

Di seguito sono elencati alcuni strumenti, tra quelli di pubblico dominio, ritenuti particolarmente utili.

La scelta, tra le centinaia esistenti, non pretende di essere la migliore in assoluto, ma solo un punto di partenza da personalizzare a seconda delle diverse realtà:

§ file integrity checking: aide [9]  (cfr. Appendice A);

§ analisi dei file di log : wots [10] (cfr. Appendice B);

§ controllo presenza rootkit: chkrootkit [11];

§ sniffer: tcpdump [12] e ethereal [13];

§ controllo porte aperte: lsof (unix) [14] e Active Ports (windows) [15];

§ port scanner: nmap [16].

§ mini distribuzione linux (per copie salvataggio): tomsrtbt [17];

3. Gestione dell’intrusione

Spesso in una macchina compromessa le utilità di sistema (ad es. ps, netcat, ls, find) sono state modificate dall’intruso in modo da non mostrare alcuni processi, utenti o file. Programmi come chkrootkit [11] o di file integrity checking [9] possono aiutare nella rilevazione di questo tipo di compromissione (cfr. Appendice C). È dunque indispensabile utilizzare sempre versioni sicuramente “originali” delle utilità di sistema, recuperate da una copia di salvataggio anteriore alla compromissione.

3.1 Raccolta informazioni preliminari

Una volta rilevata un’intrusione, per determinare le modalità e l’entità della compromissione è necessario raccogliere quante più informazioni possibili sullo stato del sistema. Alcune lo devono essere prima dell’isolamento del sistema:

§ connessioni di rete;

§ processi attivi;

§ utenti attivi;

§ file aperti.

lsof e Active Ports sono molto utili per questo tipo di rilevazioni (cfr. Appendice C).

3.2 Isolamento del sistema

Una volta raccolte le informazioni preliminari è necessario “isolare” il sistema compromesso, per evitare l’estendersi dei danni e per poterlo studiare in una situazione controllata. Alcune volte l’intruso, per cautelarsi, provvede ad installare delle procedure che cancellano le sue tracce (o addirittura l’intero sistema) nel caso di perdita di connettività di rete: può quindi essere consigliabile spegnere la macchina agendo sul pulsante di alimentazione.

3.3 Ricerca di altri sistemi compromessi

È probabile che il sistema compromesso non sia unico nella rete locale, specialmente se esistono altre macchine con lo stesso tipo di configurazione (ad es. stessa versione del sistema operativo e stessi servizi attivi).

La ricerca di altri sistemi compromessi sulla stessa rete locale può essere facilitata dall’esame dei log dei router e dei sistemi di network intrusion detection. Ad esempio un sistema come argus [18] può facilmente dare risposta alle domande seguenti, di grande aiuto per cercare di capire che cosa possa essere successo (cfr. Appendice E):

§ quali nodi si sono collegati al nodo compromesso?

§ quanti di questi si sono collegati ad altri nodi della LAN?

§ quali connessioni (interne ed esterne) sono state fatte dal sistema dopo la compromissione?

3.4 Backup

Dopo lo spegnimento, controllato o meno, la macchina va riavviata in modalità stand-alone, per evitare l’esecuzione di eventuali procedure automatiche installate dall’intruso.

Prima di qualsiasi altra operazione va eseguito un backup completo del sistema, anche a eventuali fini legali, meglio se in doppia copia e su di un supporto non modificabile.

3.5 Identificazione del metodo di attacco e delle azioni dell’intruso

L’identificazione del metodi di attacco è spesso molto difficile se non si dispongono dei file di log esterni al nodo compromesso. Infatti una delle prime azioni dell’intruso è la cancellazione delle sue tracce dai file di log del sistema attaccato.

I log del router e di eventuali sistemi di Network Intrusion Detection possono essere utili se l’attacco ha sfruttato una vulnerabilità di un qualche servizio di rete.

Nel caso che l’intruso abbia utilizzato la macchina come server (ad es. IRC BOT) o per scansioni di altri nodi o vi abbia installato uno sniffer, i file di log prodotti possono essere di aiuto. Generalmente vengono nascosti in directory in posti insoliti (ad es. in /dev) o con nomi che possono passare inosservati ad un esame superficiale (ad es. spazio o …).

4. Comunicazione dell’intrusione

Si ricorda che l’intrusione informatica è un reato e che quindi va denunciata alle autorità competenti (ad es. la Polizia Postale).

A parte gli obblighi di legge, è comunque importante segnalare l’incidente al referente locale per la sicurezza. Informazioni sul responsabile della rete da cui proviene l’attaccante sono ottenibili con il comando whois (cfr. Appendice F).

In ogni caso sono utili le seguenti informazioni:

§ estremi del contatto;

§ data e ora dell’incidente;

§ precisione del clock della macchina;

§ origine e vittima dell’attacco;

§ altri siti coinvolti;

§ eventuali file di log

Ulteriori informazioni sono disponibili sul server web di GARR-CERT (http://www.cert.garr.it/).

5. Recupero dall’incidente

La maniera più sicura per eliminare tutte le possibili backdoor lasciate dall’intruso – software di sistema opportunamente modificato, nuovi account, nuovi servizi, ecc. ecc. -- è una completa reinstallazione del sistema, seguita dall’applicazione di tutte le patch di sicurezza ritenute necessarie.

A reinstallazione avvenuta, e comunque in ogni caso, è necessario cambiare tutte le password, controllando, nello stesso tempo, che non siano stati aggiunti (o riabilitati) utenti.

Nel caso si riutilizzino i file di configurazione in uso prima della compromissione, questi vanno attentamente esaminati per controllare la presenza di modifiche destinate a permettere il ritorno dell’intruso. Ad esempio:

§ abilitazione di nuovi servizi;

§ programmi suid che permettono ottenere i privilegi di root;

§ script automatici via cron;

§ esportazione di volumi via nfs.

I dischi che non sono formattati durante la reinstallazione vanno esaminati alla ricerca di programmi suid (ad esempio utilizzando il comando find).

6. Bibliografia

[1] K-P. Kossakowski et al., Responding to Intrusions (CMU/SEI-SIM-006), Software Engineering Institute, Carnegie Mellon University (1999). Reperibile all’indirizzo: http://www.sei.cmu.edu/pub/documents/sims/pdf/sim006.pdf

[2] http://www.cert.org/. Per abbonarsi alla mailing list inviare un mail a <majordomo@cert.org> con nel corpo la frase subscribe cert-advisory

[3] http://www.cert.garr.it/. Per abbonarsi alla mailing list inviare un mail a <majordomo@garr.it> con nel corpo la frase subscribe sicurezza

[4] CIAC: http://www.ciac.org/ciac/

[5] SANS Institute : http://www.sans.org/

[6] ICAT Vulnerability Search Engine: http://icat.nist.gov/icat.cfm

[7] SecurityFocus: http://www.securityfocus.com

[8] Sysman: http://sysman.na.infn.it/

[9] http://rr.sans.org/audit/aide.php. Include anche una rassegna di altri strumenti analoghi.

[10] http://www.hpcc.uh.edu/~tonyc/tools/

[11] http://www.chkrootkit.org/

[12] http://www.tcpdump.org/

[13] http://www.ethereal.com/

[14] ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/

[15] http://www.protect-me.com/freeware.html

[16] http://www.insecure.org/nmap

[17] http://www.toms.net/rb/

[18] http://www.qosient.com/argus/

A. File integrity checking

Questo è un tipico file di configurazione di aide (le righe che cominciano con # sono commenti)

database=file:aide.db

database_out=file:aide.db.new




# Questi sono i controlli possibili (a parte il checksum)

# p: perms, i: inode, n: links, u: user, g: group

# s: size, b: block count

# m: mtime, a: atime, c: ctime

# S: check for growing size




# Definizioni di tipi di controllo

Standard=s+p+u+g+c+sha1

Min=p+u+g+sha1
 
# i file in /boot (e sottodirectory) vengono controllati per modifiche sulla

# dimensione, permessi, proprietario, gruppo, data di creazione e hash
/boot Standard


/lib Standard




# I file in /etc (e sottodirectory) vengono controllati per modifiche sui

# permessi, proprietario, gruppo e hash
/etc Min
 
# /etc/ssh_random_seed non viene controllato (viene modificato molto spesso)

!/etc/ssh_random_seed


/bin Standard

/sbin Standard

/usr Standard
 
# I file in /usr/tmp (e sottodirectory) non vengono controllati

!/usr/tmp


/var Min

!/var/tmp

!/var/lock

!/var/lost+found

!/var/log

!/var/spool

!/var/run

B. Controllo dei file di log

Il seguente è un esempio di file di configurazione di wots (le righe che cominciano con # sono commenti).

Il primo campo della riga è un’espressione regexp (perl), il secondo l’azione da intraprendere nel caso che sia trovata nella riga del file.

Da notare che wots può analizzare più di un file contemporaneamente

# nome del file da analizzare
from /var/log/messages


###################################

# righe da ignorare (ntpd, named e ssh)
/xntpd/  ignore

/named-xfer\[.+\]:/  ignore

/ssh.*Generating.*key/  ignore
 
# queste righe vengono evidenziate

/auth failure/  echo=red;bold,mail,exec=alarm.sh

/tftpd/  echo=white;on_red

/telnet|ftp/  echo=magenta;bold

/rlogin|rexec|rsh|remsh/  echo=red;on_green
 
# tutte le altre righe vengono mostrate

/./  echo




# altro file da analizzare

from /var/log/authlog

####################################

/generating.+RSA key/ ignore

/./ echo=red

C. rootkit

Con il nome di rootkit si indicano quei pacchetti che permettono all’intruso di mascherare le sue tracce. Nel caso più semplice contengono versioni modificate delle principali utility di sistema che non segnalano la presenza di alcuni processi e file, che permettono di riottenere accesso privilegiato al sistema e che facilitano la cancellazione delle tracce dell’attacco dai file di log.

I file di configurazione sono contenuti in directory opportunamente ‘mascherate’, ad es. ‘…’, o con nomi apparentemente di sistema, ad es. /dev/pty00.

Uno dei rootkit più diffusi, ad esempio, consiste in

§ chfn, chsh, passwd modificati in modo da permettere di diventare root;

§ du, find, ls modificati in modo da nascondere alcuni file e directory (indicati nei file di configurazione);

§ ifconfig modificato in modo da non mostrare il flag di modo promiscuo (indicatore della presenza di uno sniffer);

§ vari sniffer;

§ login modificato in modo da permettere login come root;

§ netstat: modificato in modo da nascondere particolari connessioni;

§ ps, top modificati in modo da nascondore certi processi;

§ syslogd modificato in modo da non scrivere su syslog certe stringhe;

§ tcpd modificato in modo da permettere l’accesso senza login da alcuni host;

§ wted, z2 per modificare utmp, wtmp e lastlog.

Questo tipo di rootkit viene facilmente individuato da un programma come aide.

L’altro tipo di rootkit (ad es. Knark, Adore, Rtkit), invece, si basa sulla modifca del kernel del sistema attaccato, lasciando quindi inalterate le utility: è proprio il kernel che non fornisce loro le informazioni che l’intruso vuole nascondere. Questo tipo di rootkit vine, di solito, rivelato con dei programmi specializzati (ad es chkrootkit), che però vanno tenuti costantemente aggiornati.

D. Controllo connessioni di rete e processi

netstat ed lsof permettono di verificare quali connessioni di rete sono attive e quali processi le hanno aperte.

Questo è un esempio tipico di output di netstat

# netstat -a

Proto  Recv-Q  Send-Q   Local Address   Foreign Address   State

tcp   0   0   *:sunrpc   *:*     LISTEN

tcp    0   0   *:auth   *:*     LISTEN

tcp   0   0   *:ssh   *:*     LISTEN

tcp   0   20   host:ssh  pcc.es:4325   ESTABLISHED

udp   0   0   *:syslog    *:*

udp   0   0   *:sunrpc   *:*

udp   0   0   *:2345   *:*

lsof permette di scoprire quale processo è in ascolto sulla porta 2345 (un’informazione che netstat non fornisce)

# lsof -i | grep 2345

nc  12112  root 3u  inet  0x01437018 0t0 UDP *:2345

lsof permette anche di scoprire quali sono i file aperti da un processo. Nell’esempio seguente si cercano i file aperti da un processo che si chiama ‘ps’ (un nome spesso utilizzato per mascherare processi illegittimi:

# lsof | grep ps

ps  28637  root  cwd VDIR  31,0x5000  3072  10240  /dev/ttyq2

E. Esempio di utilizzo di argus

Il comando seguente estrae dal database creato da argus (argus.out) le connessioni fatte e ricevute dal nodo vittima (il numero dopo il nome del nodo è la porta e i numeri seguenti sono i byte e i pacchetti in entrata e in uscita).

ra -r argus.out -c host VITTIMA
08/11 20:49:36 *  tcp RETEVISION.1031  ->  VITTIMA.23 1550 1505 56659 41352 CLO
08/11 20:50:51 tcp VITTIMA.1067 -> TECHNOTRONIC.21 26 19 141 1332 CLO
08/11 20:51:12 tcp VITTIMA.1068 <- TECHNOTRONIC.20 4 5 0 2451 CLO
08/11 21:14:59 tcp VITTIMA.1071 -> BAROLO.21 20 16 109 410 CLO
08/11 21:15:10 tcp VITTIMA.1072 <- BAROLO.20 6 9 0 8145 CLO
08/11 21:26:25 * tcp RETEVISION2.1028 -> VITTIMA.23 2405 2362 1658 146227 CLO
08/11 21:29:47 tcp VITTIMA.1080 -> TITANIA.23 283 239 161 13700 CLO
08/11 21:29:47 tcp TITANIA.26862 -> VITTIMA.113 5 5 9 36 CLO
08/11 22:40:11 * tcp RETEVISION2.1053 -> VITTIMA.23 4938 5342 458935 90861 CLO
08/11 23:07:27 s tcp VITTIMA.1143 o> IRC1.6667 2 0 0 0 TIM
08/11 23:10:22 tcp VITTIMA.1147 <| IRC2.6667 1 1 0 0 RST
08/11 23:10:56 d tcp VITTIMA.1152 -> IRC3.6667 169 179 1367 14136 CLO
08/11 23:10:57 tcp IRC3.22133 -> VITTIMA.113 5 5 13 39 CLO
08/11 23:24:23 * tcp VITTIMA.1168 |> IRC4.6667 143 125 884 11665 RST
08/11 23:24:24 tcp IRC4.4531 -> VITTIMA.113 7 6 169 38 CLO

F. whois

Il comando whois (ci sono anche varianti web) permette di interrogare i vari database in cui sono conservate le informazioni di riferimento per tutti gli indirizzi ip assegnati. Purtroppo, però, spesso queste informazioni sono lacunose e obsolete.

I database sono diversi a seconda della collocazione geografica della rete:

§ per le reti europee:

whois –h whois.ripe.net xxx.xxx.xxx.xxx

§ per le reti americane (ha anche qualche informazione sulle altre reti):

whois –h whois.arin.net xxx.xxx.xxx.xxx

§ per le reti asiatiche:

whois –h whois.apnic.net xxx.xxx.xxx.xxx

dove xxx.xxx.xxx.xxx è l’indirizzo ip del nodo.

Questo è un esempio di output:

# whois -h whois.ripe.net 192.84.145.1



inetnum: 192.84.145.0 - 192.84.145.255

netname: INFNET20

descr: INFN (National Institute of Nuclear Physics)

descr: Sezione di Firenze

country: IT

admin-c: RC4178-RIPE

tech-c: RC4178-RIPE

rev-srv: avaxfi.fi.infn.it

remarks: Firenze INFN Department

remarks: GARR - Italian academic and research network

remarks: to notify any abuse cert@garr.it



route: 192.84.144.0/21

descr: Aggregated GARR routes



person: Roberto Cecchini

address: INFN, Sezione di Firenze

address: L.go E. Fermi 2

address: I 50125 Firenze

phone: +39 55 2307696

e-mail: roberto.cecchini@fi.infn.it

nic-hdl: RC4178-RIPE

Le informazioni utili, di solito, sono quelle sul responsabile amministrativo (righe admin-c e nic-hdl) e tecnico (righe tech-c e nic-hdl). Qualche volta, come nel caso di sopra, sono presenti righe addizionali (remarks) che forniscono informazioni utili proprio in caso di incidenti.