Archivi tag: sniffer

Cisco RV016 e firmware 4.2.3.03-tm: problemi con il server DHCP integrato

Premesso che il router Cisco RV016 sembrava uno dei migliori oggetti presenti sul mercato dedicato agli abienti SOHO, ho riscontrato, durante il suo normale utilizzo, tutta una serie di bug che ne inficiano il funzionamento e che mi hanno fatto ricredere sulla sua effettiva qualità.

Uno di questi bug riguarda il server DHCP integrato, il quale, di punto in bianco, ha smesso di rilasciare gli indirizzi IP (compresa subnet mask, gateway e nameserver) ai client connessi in rete.

Ho deciso di andare a fondo alla questione e, armato di sniffer (tcpdump), ho salvato le relative tracce, che si possono riassumere in quanto segue (nell’immagine seguente sono riportate le 4 fasi principali relative al “normale” funzionamento del protocollo DHCP) :

dhcp1) Il client invia in broadcast un messaggio del tipo DHCPDISCOVER, alla ricerca dei server DHCP in ascolto sulla porta UDP 67:

15:03:00.463759 IP (tos 0x0, ttl 128, id 29956, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 74:e6:e2:0e:3d:a0 (oui Unknown), length 300, xid 0x24dc5170, Flags [none]
          Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 7: ether 74:e6:e2:0e:3d:a0
            Hostname Option 12, length 10: "ClientPC"
            Vendor-Class Option 60, length 8: "MSFT 5.0"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server

2) Al suddetto messaggio fa seguito un DHCPOFFER, inviato dal server al client (unicast), il quale contiene tutta una serie di informazioni, come l’indirizzo IP che intende assegnare al dispositivo che lo ha appena contattato:

15:03:00.470460 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 332)
    dhcpserver.domain.local.bootps > 192.168.18.203.bootpc: BOOTP/DHCP, Reply, length 304, xid 0x24dc5170, Flags [none]
          Your-IP 192.168.18.203
          Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: dhcpserver.domain.local

3) Il client risponde al server accettando l’Indirizzo IP e gli altri parametri di rete che gli sono stati proposti, utilizzando un apposito messaggio denominato DHCPREQUEST (in broadcast):

15:03:00.473016 IP (tos 0x0, ttl 128, id 29957, offset 0, flags [none], proto UDP (17), length 345)
 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 74:e6:e2:0e:3d:a0 (oui Unknown), length 317, xid 0x24dc5170, Flags [none]
 Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
 Vendor-rfc1048 Extensions
 Magic Cookie 0x63825363
 DHCP-Message Option 53, length 1: Request
 Client-ID Option 61, length 7: ether 74:e6:e2:0e:3d:a0
 Requested-IP Option 50, length 4: 192.168.18.203
 Server-ID Option 54, length 4: dhcpserver.domain.local
 Hostname Option 12, length 10: "ClientPC"
 FQDN Option 81, length 13: "ClientPC"

4) Infine, il server, mediante un DHCPNAK (in broadcast), declina la suddetta richiesta inoltratagli dal client:

15:03:00.477422 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 278)    dhcpserver.domain.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 250, xid 0x24dc5170, Flags [none]
          Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: NACK
            Server-ID Option 54, length 4: dhcpserver.domain.local

Il malfunzionamento è proprio questo, ovvero il server continuerà a rispondere con dei DHCPNAK (anzichè i DHCPACK), inibendo l’ottenimento dei parametri di rete a tutti i client.

Ho risolto “migrando” il server DHCP dal router al Domain Controller.

Per ulteriori info sui messaggi DHCP potete consultare questa pagina.

Alla prossima.

PS: tale bug sembra essere strettamente correlato alla versione del firmware (4.2.3.03-tm), infatti con la versione immediatamente precedente (4.2.2.08) non ho mai riscontrato malfunzionamenti in tal senso.

kernel: ntop segfault su sonda backtrack4

Recentemente, tentando di mettere in ascolto ntop sull’interfaccia eth1 di una sonda basata sulla distro Backtrack 4, dopo un tempo totalmente randomico notavo che il servizio in questione si schiantava in modo alquanto brusco. Ad ulteriore conferma di quanto detto individuo un messaggio lapidario su /var/log/messages, ovvero:

Mar 28 16:54:02 sonda-bt4-ext kernel: ntop[4599]: segfault at 41445036 ip b72d6a18 sp b15dd230 error 6 in libc-2.8.90.so[b7265000+158000]
ntop.jpg

Oh che bello, un fantastico sementation fault. Cosa fare quindi? Gira che ti rigira individuo la presunta causa del problema nel file dnsCache.db presente nella dir /var/lib/ntop_eth1

Lancio il comando:

nightfly@bt4:/var/lib/ntop_eth1# cat /dev/null > dnsCache.db

avvio ntop_eth1 digitando:

nightfly@bt4:/var/lib/ntop_eth1# sudo service ntop_eth1 start

ed il problema è stato risolto.

Bye.

Sniffare il traffico su PIX 501

Ieri mi sono cimentato in un pò di sano trobuleshooting sulla mia rete. Guardando i comandi messi a disposizione dalla CLI del PIX ho notato la presenza di un comando interessantissimo, ovvero capture. In pratica, mediante tale comando è possibile catturare il traffico diretto ad una delle interfacce del PIX, semplicemente digitando:

PIX501# capture <nome della capture> interface <nome dell'interfaccia>

Quindi, se ad esempio volessi sniffare il traffico diretto all’interfaccia inside del firewall in questione, mi basterebbe digitare:

PIX501# capture pacchetti interface inside

Ora, per visualizzare i pacchetti catturati basta digitare:

PIX501# sh capture pacchetti

Ovviamente, per ottenere un filtro sull’output, è sufficiente utilizzare la direttiva include. Ad esempio, il comando:

PIX501# sh capture pacchetti | i icmp

mi consentirà di osservare soltanto il traffico icmp diretto all’interfaccia su cui è attiva la capture.

Un’altra operazione utile potrebbe essere quella che ci permette di azzerare il contenuto delle capture per fare un po d’ordine. In questo casa basta scrivere:

PIX501# clear capture pacchetti

Infine, per disattivare lo sniffer basta digitare:

PIX501# no capture pacchetti

Non sottovalutate le potenzialità di questo comando, in quanto uno sniffer può tornare estramamente utile durante le operazioni di troubleshooting.

A presto.

PS: in alternativa, per osservare il traffico icmp diretto al PIX si potrebbe utilizzare il comando debug icmp trace, il quale può essere disabilitato con un semplice no debug icmp trace oppure un undebug all.

Installare e configurare Snort 2.8.4 su Kubuntu 9.04

Recentemente ho notato (con mio sommo dispiacere) che l’unica versione di Snort installabile su Kubuntu 9.04 mediante repository è la 2.7.x. Peccato però che tale versione non sia più supportata; ecco allora che ho pensato bene di rimuoverla dal mio sistema ed installare, previa compilazione, la versione 2.8.4.

snort1sm.jpg

Per prima cosa occorre scaricare la tarball in cui sono contenuti i sorgenti di Snort (seguite questo link). Fatto ciò controllate, prima di partire con la compilazione vera a propria, che tutte le dipendenze (librerie e compagnia bella) necessarie al software in questione siano soddisfatte. A tal proposito bisogna posizionarsi nella cartella in cui abbiamo precedentemente salvato la tarball e lanciare il comando:

tar -xzvf /home/nightfly/snort-2.8.1.tar.gz

Una volta estratti i file accediamo alla directory appena creata

cd /home/nightfly/snort-2.8.1

Bene, adesso lanciamo il comando ./configure che servirà proprio a verificare che tutte le dipendenze siano soddisfatte. Solitamente le librerie che Snort richiede sono libpcap0.8-dev e libpcre3-dev. Entrambe possono essere installate digitando:

sudo apt-get install libpcap0.8-dev

sudo apt-get install libpcre3-dev

Se la procedura di configurazione avviata in precedenza va a buon fine, possiamo usare il comando:

make

per compilare i sorgenti e successivamente

make install

per effettuare l’installazione vera e propria di Snort.

Creiamo la directory in cui andrà inserito il file di configurazione relativo a Snort, le regole di rilevamento delle intrusioni (rules) ed altri file necessari al corretto funzionamento dell’applicativo in questione:

sudo mkdir /etc/snort

sudo mkdir /etc/snort/rules

Andiamo a creare, inoltre, la directory in cui Snort salverà i log delle intrusioni

sudo mkdir /var/log/snort

Sempre dalla cartella in cui abbiamo estratto la tarball lanciamo il comando

rm Makefile Makefile.in Makefile.am

e successivamente

sudo cp etc /etc/snort

Passiamo adesso alla configurazione di Snort, la quale può essere effettuata mediante la modifica ad hoc del file snort.conf posizionato nella dir /etc/snort.

sudo nano /etc/snort/snort.conf

Impostiamo il valore della variabile HOME_NET con la classe di indirizzi IP utilizzata nell’ambito della nostra LAN, mentre nella variabile EXTERNAL_NET andreamo a sostituire any con !$HOME_NET. In questo modo stiamo dicendo a Snort di considerare come indirizzi esterni alla nostra LAN (e quindi sorgenti di potenziali attacchi) tutti quelli che non rientrano nella classe associata ad HOME_NET. Modifichiamo inoltre la variabile RULE_PATH assegnandogli il valore /etc/snort/rules.

Questa piccola modifica del file di configurazione ci consente di fare in modo che Snort inizi ad effettuare il monitoraggio della nostra rete in modo corretto. E’ possibile comunque adattare ulteriormente Snort alle nostre esigenze andando a modificare la sezione relativa ai cosiddetti “preprocessori”, quali, ad esempio, http_inspect (per l’individuazione di attacchi basati sul protocollo HTTP) oppure sfportscan (per la rilevazione dei portscan).

Passiamo adesso al download delle rules, necessario affinche Snort ci segnali eventuali tentativi di intrusione. Tale operazione può essere eseguita utilizzando un semplice programmino a linea di comando, ovvero oinkmaster. Non perdiamo tempo ed installiamolo:

sudo apt-get install oinkmaster

Per poter installare le rules è necessario dapprima registrarsi sul sito snort.org e successivamente procedere con la generazione di un oinkcode (ovvero di un digest MD5) che ci identifica univocamente. In particolare, sarà possibile fare ciò andando qui (previo login) e cliccando sul pulsante Generate code.

Fatto ciò passiamo alla modifica del *.conf ad esso associato.

sudo nano /etc/oinkmaster.conf

e inseriamo la seguente stringa:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/<nostro_oinkcode>/snortrules-snapshot-2.8.tar.gz

Una volta completati download ed installazione delle rules, possiamo avviare Snort in modalità “test” per verificarne il corretto funzionamento. Digitiamo quindi:

sudo snort - T -c /etc/snort/snort.conf

e se ricevete la seguente stringa in output

 Snort sucessfully loaded all rules and checked all rule chains!
 Snort exiting

avete la prova che Snort sta funzionando correttamente. Un altro test che potrebbe tornare utile è quello che ci permette di visualizzare in tempo reale i pacchetti sniffati da snort:

sudo snort -c /etc/snort/snort.conf -v

Ora non ci resta che eseguire automaticamente Snort ad ogni avvio del sistema, possibilmente in modalità demone, ovvero in background. Per fare ciò andiamo ad editare il file rc.local presente nella directory /etc:

sudo nano /etc/rc.local

e successivamente inseriamo la stringa

sudo snort -c /etc/snort/snort.conf -i eth1 -l /var/log/snort -D

dove la flag -D specifica proprio l’esecuzione in background.

Infine, se ad esempio volessimo effettuare il download e l’aggiornamento delle rules ogni ora, possiamo procedere con la creazione di una regola per cron, mediante l’editing del file crontab:

sudo nano /etc/crontab

e digitiamo

0  *    * * *   root    oinkmaster -o /etc/snort/rules/

Bene, adesso Snort è configurato e pronto per l’uso. A presto.

PS: ho realizzato un piccolo programmino che invia, mediante SMS, gli alert generati da Snort. Per ulteriori informazioni non esitate a contattarmi.

PPS: è possibile effettuare download dal sito Snort.org solo ad intervalli (minimi) di quindici minuti, ergo non impostate regole di cron che agiscano troppo frequentemente.