Segui le loro mosse
Conosci Il Tuo Nemico: II

Lance Spitzner
http://www.enteract.com/~lspitz/papers.html
Ultima Modifica: 7 Luglio, 2000

Questo articolo è il secondo di una serie di tre parti. Nel primo articolo, Conosci Il Tuo Nemico, abbiamo trattato degli strumenti e delle metodologie dello Script Kiddie.  In particolare, come vengono scoperte le vulnerabilità e come avviene l'attacco. Il terzo articolo tratta di cosa gli script kiddie fanno una volta ottenuti i privilegi di root. In particolare come vengono nascoste le tracce e cosa succede dopo. Qui, nel secondo articolo, si tratterà di come seguire le loro mosse. Come in campo militare, si vuole seguire il nemico e sapere cosa sta facendo. Tratteremo di cosa si può e cosa non si può determinare, con i log di sistema. Si può essere in grado di determinare se qualcuno vi sta esaminando, per cosa vi sta esaminando, che strumenti sta usando e se sta avendo successo. Gli esempi proposti sono relativi a Linux, ma possono essere applicati a quasi tutti gli Unix. Tenete a mente che non c'è un modo garantito di seguire ogni passo dell'aggressore. Ad ogni modo questo articolo è un buon punto di partenza.

Proteggere i vostri log
Questo articolo non è sulla rilevazione di intrusione (Intrusion Detection, IDS), ci sono già molte eccellenti fonti che trattano di IDS. Se siete interessati alla IDS, vi consiglio applicazioni come Network Flight Recorder  o snort.  Questo articolo è incentrato sulla raccolta di informazioni. In particolare come sapere cosa il nemico sta facendo dalla lettura dei vostri log di sistema. Sarete sorpresi da quante informazioni potrete trovare nei vostri file di log. Comunque, prima di parlare della lettura dei log, dovremo parlare della sicurezza dei log di sistema. I vostri file di log sono inutili se non siete in grado di assicurare la loro integrità. La prima cosa che la maggior parte degli intrusi fanno è alterare i file di log del sistema compromesso. Ci sono una varietà di rootkits che cancellano la loro presenza dai file di log (come ad esempio cloak), o alterano tutte le registrazioni insieme (come ad esempio dei syslogd "cavalli di troia").  Quindi, il primo passo per utilizzare i log è la sicurezza dei log stessi.

Questo significa che avrete bisogno di utilizzare un server dei log remoto. A prescindere da quanto sia sicuro il vostro sistema, voi non potrete garantire la veridicità dei log su un sistema compromesso. Se non altro, l'intruso può semplicemente dare un rm -rf /* sul vostro sistema, cancellando il disco rigido. Questo rende difficile recuperare i vostri log. Per proteggersi da ciò, potete fare in modo che i vostri sistemi registrino il traffico sia localmente che su un server remoto. Raccomando di fare in modo che il log server sia una macchina dedicata, cioè che la sola cosa che faccia sia raccogliere log dagli altri sistemi.  Se il problema sono i soldi, potete facilmente mettere su una linux box che agisca da log server. Questo server dovrà essere estremamente sicuro, con tutti i servizi disabilitati e che permetta il solo accesso da console (vedi Proteggere Linux per un esempio). Inoltre, assicuratevi che la porta 514 UDP sia bloccata o dietro un firewall per un collegamento Internet. Questo proteggerà il vostro log server dal ricevere informazioni di log non autorizzate o maligne.

Per quelli di voi a cui piacciono le cose più difficili, a volte io ricompilo syslogd per fargli leggere un file di configurazione differente, come /var/tmp/.conf.  In questo modo il malintenzionato non capirà dove sia il vero file di configurazione. Ciò può essere fatto semplicemente cambiando la stringa "/etc/syslog.conf" nel codice sorgente con il file che volete. Quindi possiamo sistemare il nostro nuovo file di configurazione per avere i log sia localmente che sul server di log remoto (vedi esempio).  Assicuratevi di mantenere una copia standard del file di configurazione, /etc/syslog.conf, che punti a tutti i log locali. Anche se questo file di configurazione è ora inutile, ciò porterà l'intruso fuori strada nel capire la vera destinazione della registrazione remota. Un'altra opzione è usare un metodo di log sicuro sui vostri server.  Una possibilità è sostituire l'eseguibile syslogd con qualche prodotto che abbia il controllo di integrità ed una grande varietà di opzioni. Una scelta può essere syslog-ng, che potete trovare a http://www.balabit.hu/products/syslog-ng.html

Molti dei log che useremo sono quelli archiviati sul log server remoto. Come menzionato in precedenza, possiamo essere ragionevolmente sicuri dell'integrità di questi log in quanto sono residenti su un server remoto ed in sicurezza. Inoltre, siccome tutti i sistemi registrano su un singolo punto, è molto più facile identificare dei modelli in questi log.  Potremo vedere cosa succede su tutti i sistemi da un singolo punto. L'unico momento in cui vorremo controllare i log locali sarà per compararli con quelli del log server. Sarà possibile determinare se i log locali sono stati alterati comparandoli con quelli del log server remoto.

Corrispondenza di modello
Leggendo i vostri log, potete in genere determinare se siete oggetto di una esplorazione delle porte (port scanning). Molti Script Kiddie esaminano una rete per una singola vulnerabilità. Se i vostri log mostrano che la maggior parte dei vostri sistemi hanno connessioni dallo stesso server remoto, sulla stessa porta, questa probabilmente è una esplorazione per vulnerabilità (exploit scan).  In genere l'aggressore e' in possesso di un exploit per una singola vulnerabilità, ed esamina la vostra rete cercandola. Quando la trova, la sfrutta. Nella maggior parte dei sistemi Linux, TCP Wrappers è installato per default.  Così potrete trovare molte di queste connessioni in /var/log/secure.  Per altri tipi di Unix, è possibile registrare tutte le connessioni tramite inetd eseguendo inetd stesso con il parametro "-t". Un tipico exploit scan assomiglierà a quello qui di seguito. Qui abbiamo qualcuno che cerca vulnerabilità di wu-ftpd.

/var/log/secure
Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200

Qui vediamo l'IP 192.168.11.200 (fonte) che esamina la nostra rete.  Notate come la fonte esamina sequenzialmente ogni IP (non è sempre questo il caso). Questo è un vantaggio dell'avere un log server, perchè con i log combinati è possibile identificare più facilmente dei modelli nella vostra rete. Le ripetute connessioni alla porta 21, ftp, indicano che probabilmente stanno cercando un exploit per wu-ftpd. Avete appena determinato cosa sta cercando l'aggressore. Spesso le esplorazioni tendono ad arrivare a fasi. Qualcuno rilascia il codice per un exploit di imap, e voi improvvisamente vedete un aumento delle esplorazioni per imap sui vostri log.  Il prossimo mese sarà la volta del ftp. Un eccellente fonte per gli exploit attuali è http://www.cert.org/advisories/ . A volte vengono usati strumenti che permettono di esplorare diversi exploit alla volta, ed in questi casi vedrete una singola fonte che si connette a diverse porte.

Tenete a mente che se non registrate l'attività del servizio, non potrete sapere se siete sotto osservazione per quell servizio. Per esempio molte connessioni rpc non sono registrate. Comunque molti servizi possono semplicemente essere aggiunti a /etc/inetd.conf per essere registrati tramite TCP Wrappers.  Per esempio potete aggiungere una riga in /etc/inetd.conf per NetBus. Potete quindi configurare TCP Wrappers per negare e registrare le connessioni in modo sicuro. (vedi Intrusion Detection per maggiori informazioni).

Quali sono gli strumenti?
A volte è possibile determinare quali strumenti vengono usati per esplorare la vostra rete. Alcuni dei più semplici strumenti ricercano una specifica vulnerabilità, come ftp-scan.c. Se viene esplorata una sola porta o vulnerabilità, è molto probabile che stiano usando uno di questi strumenti "mono-obiettivo".  Esistono comunque strumenti che ricercano molteplici vulnerabilità o debolezze, i due più popolari sono sscan di Jsbach e nmap di Fyodor.  Ho menzionato questi due perché rappresentano le due "categorie" di strumenti di esplorazione. Vi raccomando caldamente di eseguirli sulla vostra rete, sarete sorpresi dai risultati :)
NOTA:. sscan è attualmente vecchio di un anno e seriamente antiquato. Viene qui trattato solo come esempio. Per esplorare le vulnerabilità della vostra rete vi consiglio Nessus.

• sscan rappresenta lo strumento di esplorazione "tuttofare" dello Script Kiddie. Esso fa un test della rete per un gruppo di vulnerabilità specifiche. E' configurabile, permettendo l'aggiunta di nuovi test di vulnerabilità. Dovete solo fornire allo strumento una rete ed una maschera di rete (netmask), ed il resto lo farà lui. Comunque l'utente deve essere root per usarlo.  Il risultato è estremamente facile da interpretare (rendendolo quindi molto popolare): viene dato un conciso riassunto di molti servizi vulnerabili. Tutto quello che è necessario fare è eseguirlo verso una rete, cercare la parola "VULN" nei risultati, e quindi eseguire "l'impresa del giorno".  Di seguito un esempio di sscan eseguito contro il sistema mozart (172.17.6.30).

          otto #./sscan -o 172.17.6.30

--------------------------<[ * report for host mozart *
<[ tcp port: 80 (http) ]>       <[ tcp port: 23 (telnet) ]>
<[ tcp port: 143 (imap) ]>      <[ tcp port: 110 (pop-3) ]>
<[ tcp port: 111 (sunrpc) ]>    <[ tcp port: 79 (finger) ]>
<[ tcp port: 53 (domain) ]>     <[ tcp port: 25 (smtp) ]>
<[ tcp port: 21 (ftp) ]>
--<[ *OS*: mozart: os detected: redhat linux 5.1
mozart: VULN: linux box vulnerable to named overflow.
-<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request.
-<[ *FINGER*: mozart: root: account exists.
--<[ *VULN*: mozart: sendmail will 'expn' accounts for us
--<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
--<[ *VULN*: mozart: linux mountd remote buffer overflow
---------------------------<[ * scan of mozart completed *

• Nmap rappresenta il gruppo di strumenti "raw data".  Non vi dice quali vulnerabilità esistono, piuttosto dice quali porte sono aperte, e voi determinerete l'impatto di sicurezza. Nmap è diventato rapidamente il port scanner di riferimento, e con buona ragione.  Esso prende il meglio di diversi port scanner e mette tutte le loro funzionalità all'interno di un unico strumento, inclusa la determinazione del sistema operativo, varie opzioni di assemblaggio dei pacchetti , esplorazione UDP e TC, randomizzazione, etc.  Ad ogni modo è necessario avere conoscenze di rete per usarlo ed interpretare i dati. Di seguito un esempio di nmap eseguito contro lo stesso server.

otto #nmap -sS -O 172.17.6.30

Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on mozart (172.17.6.30):
Port    State       Protocol  Service
21      open        tcp        ftp
23      open        tcp        telnet
25      open        tcp        smtp
37      open        tcp        time
53      open        tcp        domain
70      open        tcp        gopher
79      open        tcp        finger
80      open        tcp        http
109     open        tcp        pop-2
110     open        tcp        pop-3
111     open        tcp        sunrpc
143     open        tcp        imap2
513     open        tcp        login
514     open        tcp        shell
635     open        tcp        unknown
2049    open        tcp        nfs

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.35-36

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

Analizzando I vostri log, potete determinare quali di questi strumenti è stato usato contro di voi. Per fare questo, è necessario capire come funzionano. 

Un sscan si connetterà come mostrato di seguito (questo e' uno scan di default senza modifiche a nessun file di configurazione):

/var/log/secure
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200

/var/log/maillog
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=??? host=[192.168.11.200]
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while reading line user=??? host=[192.168.11.200]
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn root

/var/log/messages
Apr 14 21:03:09 mozart telnetd[11682]: ttloop:  peer died: Invalid or incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed

sscan ricerca anche vulnerabilità di cgi-bin. Questi tentativi non sono registrati da syslogd, è possibile trovarli in access_log.  Ho deciso di includerli comunque per vostro piacere :)

/var/log/httpd/access_log
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163

Notate come viene effettuata una connessione completa per tutte le porte (SYN, SYN-ACK, ACK)  e quindi chiusa. Questo perché sscan determina cosa e' in esecuzione a livello di application layer.  Non solo sscan vuole sapere se la vostra porta ftp è aperta, ma quale ftp daemon è in esecuzione. La stessa cosa per imap, pop, ecc.  Quasto può essere visto usando sniffit, uno strumento comunemente usato per "sniffare" password.

mozart $ cat 172.17.6.30.21-192.168.11.200.7238
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT 1998) ready.

Come visto sopra, viene effettuata una connessione completa per determinare la versione del wu-ftpd che è in esecuzione. Quando vedete una connessione completa nei vostri log, come quella qui sopra, molto probabilmente siete oggetto di una esplorazione da parte di uno strumento di questo tipo. Questi strumenti effettuano una connessione completa per determinare cosa state facendo eseguire.

Nmap, come molti port scanner, non si interessa di cosa state facendo eseguire, ma se state facendo eseguire servizi specifici. Per fare ciò, nmap possiede un nutrito gruppo di opzioni, lasciando a voi la scelta del tipo di connessione da effettuare, inclusi SYN, FIN, Xmas, Null, ecc.  Per una descrizione dettagliata di queste opzioni, fare riferimento a http://www.insecure.org/nmap/nmap_doc.html.   A causa di queste opzioni i vostri log possono essere differenti secondo le opzioni selezionate dall'utente remoto. Una connessione effettuata con l'opzione -sT è una connessione completa, e nei log sarà simile a quella di sscan, anche se di norma nmap esplora più porte.

/var/log/secure
Apr 14 21:20:50 mozart in.rlogind[11706]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.fingerd[11708]: connect from 192.168.11.200
Apr 14 21:20:51 mozart ipop2d[11709]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.rshd[11710]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: error: cannot execute /usr/sbin/gn: No such file or directory
Apr 14 21:20:52 mozart in.timed[11712]: connect from 192.168.11.200
Apr 14 21:20:52 mozart imapd[11713]: connect from 192.168.11.200
Apr 14 21:20:52 mozart ipop3d[11714]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.telnetd[11715]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.ftpd[11716]: connect from 192.168.11.200

Una cosa da tenere a mente è l'opzione -D (o decoy).  Questa opzione di nmap permette all'utente remoto di mimetizzare l'indirizzo di partenza. Potreste vedere delle esplorazioni da 15 differenti fonti nello stesso momento, ma una sola è quella reale. E' estremamente difficile determinare quale delle 15 fonti è quella vera.  Più spesso gli utenti usano l'opzione -sS durante l'esplorazione delle porte. Questa è una opzione che nasconde, in quanto viene inviato solo un pacchetto SYN.  Se il sistema risponde, la connessione viene immediatamente interrotta con un RST.  I log da questo tipo di esplorazione assomigliano a queeli qui di seguito(NOTA: Sono inclusi solo i primi cinque tentativi).

/var/log/secure
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown
Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown
Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown
Apr 14 21:25:09 mozart ipop3d[11720]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart ipop3d[11720]: connect from unknown
Apr 14 21:25:09 mozart in.rlogind[11722]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.rlogind[11722]: connect from unknown

Notate gli errori nelle connessioni. Siccome la sequenza SYN-ACK è interrotta prima che possa essere stabilita una connessione completa, il daemon del servizio non può determinare il sistema di partenza. I log mostrano che siete stati oggetto di esplorazione, ma sfortunatamente non sapete da parte di chi.  Ciò che è più allarmante è che, in molti sistemi (inclusi I più recenti kernel di Linux), nessuno di questi errori viene registrato. Per citare Fyodor " ... based on all the 'connection reset by peer' messages.  This is a Linux 2.0.XX oddity -- virtually every other system (including the 2.2 and later 2.1 kernels) will show nothing.  That bug (accept() returning before completion of the 3-way handshake) was fixed."

Nmap include altre opzioni di mimetizzazione, such as -sF, -sX, -sN dove sono usati vari flag.  Di seguito quanto mostrato dai log per questi tentativi:

/var/log/secure

Notate qualcosa qui, non ci sono log !  Inquietante huh, siete stati appena esplorati, e non lo avete saputo.  Tutti e tre I tipi di esplorazione danno lo stesso risultato, ma voi siete in grado di registrare solo il primo tipo, -sT (connessione completa).  Per scoprire queste altre esplorazioni nascoste, avete bisogno di usare divere programmi di log come tcplogd o ippl   anche alcuni firewall commerciali sono in grado di scoprirle (Ho avuto conferma su Checkpoint Firewall 1).

Hanno Avuto Accesso?
Una volta che avete determinato di essere stati esplorati, e per cercare cosa, la prossima grande domanda è "Sono entrati?". Molti degli attuali exploit remoti sono basati su buffer overflow (altrimenti conosciuto come "smashing the stack" (NdT. "spaccalapila").  Detto in parole povere, un buffer overflow è dato da un programma (in genere un daemon o server) riceve più dati di quanti se ne aspetta, andando così a scrivere in aree critiche della memoria. Vengono quindi eseguiti alcuni codici, che generalmente danno all'utente una accesso di root. Per maggiori informazioni sui buffer overflow, vedete l'eccellente lavoro di Aleph1a ftp://ftp.technotronic.com/rfc/phrack49-14.txt.

E' generalmente possibile identificare un attacco di buffer overflow nel log file /var/log/messages (o /var/adm/messages per altri tipi di Unix) per attacchi tipo mountd.  Si possono vedere anche log simili in maillog per questo tipo di attacchi contro imapd.  Un attacco di buffer overflow assomiglierà a questo:

Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200.
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together
Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3Û3À°^[Í~@3Ò3À~KÚ°^FÍ~@þÂuô1À°^BÍ~@~EÀubëb^V¬<ýt^FþÀt^Këõ°0þÈ~HFÿëì^°^B~
I^FþÈ~IF^D°^F~IF^H°f1ÛþÃ~IñÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1À~IF^P°^P~IF^H°
fþÃÍ~@°^A~IF^D°f³^DÍ~@ë^DëLëR1À~IF^D~IF^H°fþÃÍ~@~Hð?1ÉÍ~@°?þÁÍ~@°?þÁÍ~@¸.bin@~
I^F¸.sh!@~IF^D1À~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1À°^A1ÛÍ~@èEÿÿÿÿýÿPrivet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E

Quando vedete qualcosa del genere nei vostri log, qualcuno ha tentato di entrare nel vostro sistema. E' difficile determinare se l'attacco ha avuto successo. Un modo per farlo, seguendo il tentativo di accesso, è vedere se ci sono connessioni da una fonte remota al vostro sistema.  Se accedono con successo dal sistema remoto, allora sono entrati. Un altro indizio è se trovate account tipo "moof", "rewt", "crak0", o "w0rm" aggiunti al vostro /etc/passwd file.  Questi account, uid 0, vengono aggiunti da alcuni dei più comuni script di exploit. Una volta che l'aggressore ha avuto accesso, normalmente la prima cosa che farà sarà cancellare I vostri log ed alterare (trojan) il vostro programma di log (syslogd), per maggiori informazioni, vedere Conosci Il Tuo Nemico: III.  Da questo momento in poi non riceverete più nessun log dal vostro sistema in quanto compromesso. Cosa fare a questo punto è l'oggetto di un altro articolo :).  Nel frattempo, consiglio una visita a http://www.cert.org/nav/recovering.html

Per aiutarmi nella ricerca di anomalie nei miei file di log, ho messo giù uno script che li analizza I log per me. Per informazioni più dettagliate su ricerca ed ordinamento dei file di log, date un'occhiata a questo contributo di Marcus Ranum.

Bourne shell script Korn shell script

Conclusione
Le registrazioni dei vostri sistemi possono dirvi molto circa il nemico. Comunque il primo passo è garantire l'integrità dei vostri file di log. Uno dei modi migliori per farlo è usare un server dei log remoto che riceva e mantenga I log di tutti I sistemi. Una volta resi sicuri i vostri file di log, potete identificare dei modelli dalla loro analisi. In base a questi modelli ed al contenuto dei log, potete determinare che cosa l'aggressore cerca e potenzialmente che strumenti usa. Sapendo questo potrete dare maggior sicurezza e protezione ai vostri sistemi.

Biografia dell'Autore
Lance Spitzner si diverte ad imparare facendo saltare i suoi sistemi Unix a casa. Prima di questo, era Ufficiale della Forza di Intervento Rapido, dove faceva saltare cose di diversa natura. E' raggiungibile a lance@spitzner.net .

Whitepapers / Publications