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.

          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 *

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