Oggi ogni nuovo dispositivo, appliance e anche programma software per desktop è in grado di generare log o dati basati su testo. E la gestione delle informazioni contenute nei log impone di valutare una serie di aspetti.
Il primo consiste nella memorizzazione centralizzata e nella raccolta dei log (sono disponibili vari prodotti prodotti in grado di svolgere questa attività). I dati di solito sono inviati a un syslog, a un log management o a un sistema Sim che si trova in una posizione centrale della rete.
A questo punto si pone una questione: come si setacciano i dati dei log presenti nei server Web per trovare informazioni rilevanti per la sicurezza?
Il concetto di regex
Nonostante ci siano molteplici applicazioni open source e commerciali che eseguono analisi dei loga vari livelli, di solito tali prodotti sono accomunati da un particolare elemento – le regular expression (regex). Queste sono fondamentalmente una stringa di caratteri che consentono a quasi ogni linguaggio di scripting o tool di ricerca di eseguire ricerche veloci e avanzate all’interno di grandi quantità di dati di testo.
Esistono alcune variazioni dei formati regex e i più comunemente utilizzati dai linguaggi di scripting sono detti regular expression Perl-derivative. Queste includono i formati regex per il framework .NET, Python, Java, JavaScript e, naturalmente, Perl. Utilizzando questo tipo di regex in combinazione con qualsiasi linguaggio di scripting o tool di ricerca, è possibile analizzare in modo rapido ed efficiente grandi quantità di dati al fine di individuare informazioni significative.
Uno dei più comuni formati di log in cui si tende a individuare eventuali problemi è Apache o httpd. I log di questi server Web tendono a nascondere un certo numero di segreti che è vitale individuare, come per esempio i tentativi di attacco, le signature degli attacchi avvenuti con successo e anche attività che anticipano un imminente un attacco.
Noi ci focalizzeremo sull’impiego delle regex con egrep, il quale usa una sintassi molto semplice per la ricerca di file ed è presente in quasi ogni sistema operativo nei più comuni ambienti attuali (gli utenti Windows possono scaricare gratuitamente una versione da molteplici fonti). Ricordate che le regular expression utilizzate con egrep sono inoltre compatibili con qualsiasi programma o linguaggio di scripting che supporta le regex.
In questo articolo, analizzeremo i log di Apache. Ma i concetti applicati tramite i log di egrep, regex e httpd possono essere utilizzati in centinaia di altre piattaforme, tool e tipi di log. Capire cosa è pericoloso e come cercarlo è un grande passo verso il riconoscimento dei problemi di sicurezza all’interno della propria organizzazione.
Step 1. Formato dei log Web
Al fine di creare espressioni per analizzare il contenuto di questi log, abbiamo bisogno di capire la struttura di input del log. Apache memorizza una file chiamato log del server di accesso, di solito in /etc/httpd/logs e altrettanto di solito con un come tipo access_log.
È possibile configurare httpd (Apache) affinché siano inviati questi log a un syslog o a un sistema SIM; in tal caso, il formato del log può essere diverso da quello di default. Apache memorizza input delimitati nell’access_log nel seguente formato:
10.10.10.10 – frank
[10/Oct/2007:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0” 200 2326
Suddividiamo questo input sezione per sezione. Il primo valore, 10.10.10.10, è semplicemente l’indirizzo IP del client, direttamente seguito dal nome dell’host del client se è abilitato l’HostnameLookups. Quindi, abbiamo la data e l’ora, 10/Oct/2007 e 13:55:36 -0700. Questo è ovviamente importante per eventuali scopi di correlazione.
Di seguito, abbiamo le informazioni relative all’header HTTP. Ciò è particolarmente utile perché fornisce dati inerenti il tipo di richiesta che è stata fatta da parte del client. In questo caso, GET/apache_pb.gif HTTP/1.0 indica un metodo GET di richiesta, che ha come obiettivo l’immagine chiamata apache_pb.gif che si trova nella root della directory del server Web httpd.
Infine, il codice di ritorno del server, 200, indica che la richiesta è stata completata con successo.L’ultimo bit di informazione è semplicemente la dimensione dell’oggetto restituito al cliente per la richiesta.
Step 2. Analisi e indagini
Ora che abbiamo capito la ripartizione del formato del log, possiamo cominciare a stabilire la modalità per individuare le richieste che potrebbero evidenziare attività sospette.
Per esempio, le richieste che fanno riferimento a componenti di amministrazione come WebMin, un tool di gestione del server Web, o admin, un nome per l’interfaccia di login usato molto di frequente. Questo è molto probabile che faccia parte dei dettagli della richiesta nel log. Ciò detto, si potrebbero semplicemente usare questi nomi come stringhe di query in una regex all’interno di egrep: >egrep -n webmin access_log.
La struttura di questo comando è semplice: egrep è seguita da eventuali parametri di configurazione, quindi dai criteri di ricerca e infine dal nome del file da cercare.
In questo caso -n visualizzerà il numero della linea di log come riferimento.
Ciò dovrebbe riprodurre qualsiasi input nel server log in cui è stata fatta una richiesta a un URL che contiene webmin. Un esempio della risposta ricevuta potrebbe essere simile al seguente:
57:10.10.10.10 – bob
[10/Oct/2007:20:24:18 -0700] “GET / webmin HTTP/1.0” 404 726
Entrando nel dettaglio del risultato, sulla linea 57 del file di log viene evidenziato che al nostro server Web è stata presentata una richiesta alle 20:24 del 10 ottobre, richiedendo la directory Webmin. Siamo inoltre in grado di vedere che il server ha restituito il messaggio 404, il che indica che non è riuscito a trovare la directory. Questo è importante perché chi deve avere accesso a funzioni amministrative sul server vorrebbe sapere dove andare a cercare. Bob potrebbe essere alla ricerca di un modo per penetrare nel server.
Step 3. Raffinare la ricerca nel log del server
Potrebbe essere interesse verificare eventuali altre richieste effettuate da Bob, in particolare quella che ha restituito un codice 200, ovvero che indica che è stato trovato qualcosa. Il nostro comando potrebbe essere di questo tipo: > egrep -n -i “bob|200” access_log
Anche se questo troverà log che hanno Bob o il numero intero 200 da qualche parte al loro interno, ciò non significa che ogni log restituito avrà il codice del server “200” che Bob ha richiesto. E ciò effettivamente ci farà avere un po’ di dati che non ci interessano. Sarebbe più preciso effettuare la ricerca di log che includono sia Bob sia 200. Poiché entrambi (Bob e 200) avranno uno spazio bianco intorno a loro, siamo in grado di isolare le richieste che stiamo cercando. Si noti, inoltre, il parametro -i, che eliminerà la necessità di congruenza delle lettere maiuscole o minuscole in modo che Bob, bOb, boB, bob e BOB soddisfino tutti la nostra query regex.
egrep -n -i “bbobb.*200*” access_log
Questo comando restringerà la nostra query solo a linee nel log che contengono sia la parola bob sia il numero 200. Il parametro b che si vede su entrambi i lati di bob indica un word boundary, o l’inizio e la fine di una parola. Il simbolo * posto prima di 200 indica che esisteranno alcuni caratteri tra bob e 200 e il simbolo * dopo 200 consentono ai caratteri di esistere dopo lo stesso 200. Questo porta a ottenere input come i seguenti:
57:10.10.10.10 – bob
[10/Oct/2007:20:24:18 -0700] “GET / webmin HTTP/1.0” 404 726
59:10.10.10.10 – bob
[10/Oct/2007:20:24:59 -0700] “GET /admin HTTP/1.0” 404 726
65:10.10.10.10 – bob
[10/Oct/2007:20:25:35 -0700] “GET /login HTTP/1.0” 404 726
Ciò che potete notare quando controllate i risultati è che Bob è alla ricerca di qualcosa. Forse un’interfaccia di amministrazione o qualcosa del genere oppure un modo per accedere al Web server.
Inoltre, prestando particolare attenzione al momento alle informazioni temporali, è possibile vedere che tutte e tre le richieste sono state effettuate nel giro di un minuto, il che ci dice che Bob è molto rapido nell’uso della tastiera o che utilizza uno strumento automatico di qualche tipo. La seconda ipotesi è la più probabile e questo può fornirci informazioni sufficienti per avviare ulteriori indagini sulle sue azioni.
Inoltre, notiamo che le richieste di Bob hanno tutte dato origine al messaggio 404 “non trovato”. Se questo è il caso, allora, perché ci è stato mostrato? Noi cercavamo solo i 200 codici. Questo è un primo esempio di un computer che fa solo ciò gli si dice di fare, in questo caso, la data contiene la stringa “200” è ciò quanto abbiamo chiesto. L’utilizzo di regex può spesso causare falsi positivi, ma utilizzando la nostra semplice query, siamo stati in grado di eliminarne la maggior parte.
Indaghiamo un po’ di più su Bob.
Step 4. Seguire il percorso
Come ultimo sforzo volto a tenere traccia di tutte le attività di Bob, possiamo cercare tutte le richieste che Bob ha effettuato a partire dal suo indirizzo IP. Ciò richiede di effettuare “l’escaping” dei periodi in cui l’indirizzo IP è stato incluso nelle regex. L’escaping è un metodo di dire a un motore regex che invece di usare il significato speciale di un carattere, vogliamo utilizzarlo come ricerca letterale. Trovate un esempio del comando qui di seguito:
>egrep -n -i “10.10.10.10” access_log
In questo caso, stiamo dicendo a egrep di trovare tutte le istanze di 10.10.10.10 nel file di log. I nostri risultati saranno molto simili a questi:
57:10.10.10.10 – bob
[10/Oct/2000:20:24:18 -0700] “GET /web min HTTP/1.0” 404 726
59:10.10.10.10 – bob
[10/Oct/2000:20:24:59 -0700] “GET /admin HTTP/1.0” 404 726
65:10.10.10.10 – bob
[10/Oct/2000:20:25:35 -0700] “GET /login HTTP/1.0” 404 726
120:10.10.10.10 – [10/Oct/2000:21:14:11 -0700] “GET /index.html HTTP/1.0” 200 2571
157:10.10.10.10 – [10/Oct/2000:21:50:59 -0700] “GET /parent/directory HTTP/1.0” 404 726
260:10.10.10.10 – [10/Oct/2000:22:25:15 -0700] “GET /support.htm HTTP/1.0” 200 1056
Così ora abbiamo una buona idea che Bob sta girando attorno al sito, ma non necessariamente ha violato alcuna legge o attraversato confini..
Utilizzo dei dati dei log Web per rimanere all’erta
Quando cercate gli indicatori degli attacchi più pericolosi, tenete d’occhio la frequenza e la destinazione di una richiesta. Per esempio, quando monitorate un’applicazione di on-line banking, prestate particolare attenzione alle richieste inviate ai trasferimenti. Possiamo vederne diverse, quando qualcuno sta cercando di visualizzare i record di trasferimento di altre persone:
10.10.10.10 – [10/Oct/2000:x:x:x -0700] “GET /banking/view/transfer.jsp?id=12345 HTTP/1.0” 200 1042
10.10.10.10 – [10/Oct/2000:x:x:x -0700] “GET /banking/view/transfer.jsp?id=12346 HTTP/1.0” 500 798
10.10.10.10 – [10/Oct/2000:x:x:x -0700] “GET /banking/view/transfer.jsp?id=12347 HTTP/1.0” 200 1042
10.10.10.10 – [10/Oct/2000:x:x:x -0700] “GET /banking/view/transfer.jsp?id=12348 HTTP/1.0” 500 798
Dall’analisi del log si vede che qualcuno ha individuato l’ID = xxxxx nell’URL e ha provato a incrementare di uno il numero fino a quando non ha trovato altri record di trasferimento. Si tratta di un’importante falla nella sicurezza dell’applicazione Web.
