Home > Networking & NetSecurity, Sicurezza > CISCO D.A.I. Module – Sopravvivere al Layer 2

CISCO D.A.I. Module – Sopravvivere al Layer 2

Ciao a tutti cari lettori, immagino che ormai vi stavate chiedendo che fine avevo fatto e come mai non scrivevo più nulla sul mio blog; ma tra lavoro, corsi di aggiornamento e master  il tempo per bloggare e condividere in rete un pò delle proprie esperienze risulta veramente poco ormai.

Oggi però ho deciso di trovare il tempo (ad un’orario pazzo tra l’altro) per parlare del CISCO D.A.I. Module.

Dieci giorni fa mi è capitato, durante una consulenza per un’azienda della mia zona (eseguita nel dopo lavoro), di controllare come mai ultimamente ci fosse la loro rete lenta, e talmente tanto sovvracaricata da rendere lunghissima qualsiasi comunicazione host to host all’interno della LAN. Fortunatamente la mia fida amica sonda IDS, configurata su una VDI predisposta temporaneamente come segugio sul server aziendale, ha rilevato un eccesso di traffico arp e molti tentativi di arp poisoning da parte di alcuni indirizzi IP che dovrebbero solitamente essere liberi .

Controllando i log, mi sono accorto che gli IP sorgenti cambiavano senza un rigor di logica preciso e senza essere registrati nel database DHCP del server aziendale; segno quindi che qualcuno configurava a random la NIC del proprio PC in static mode e lanciava questi tentativi di avvelenamento ARP.

A questo punto per professionalità( visto che mi pagano per risolvere i problemi) e buon senso civico ho deciso di risolvere la situazione definitivamente; anche se ho deciso di risolverla a modo mio, in quanto ora questa era diventata una sfida personale tra me e lo script kiddie che stava giocando con ettercap. Poi ovviamente ho notificato al responsabile di piano questa bravata affinchè prendesse provvedimenti disciplinari verso costui.

A questo punto entra in gioco come una manna dal cielo il CISCO D.A.I. Module; ovvero il CISCO DYNAMIC ARP INSPECTION MODULE.

Questo modulo, implementato e disponibile nel firmware di molti switch CISCO Catalyst, permette di ispezionare il traffico ARP di determinate VLAN e di verificare che le arp request siano conformi. Faccio un’esempio….se sulla porta 1 l’indirizzo di MAC 00-50-56-C0-00-01 corrisponde all’IP 172.16.10.134, e tale host invia o riceve 200 arp request  D.A.I. entra in  funzione loggando poi l’accaduto.

Voi adesso vi starete chiedendo…. VERY GOOD !!! Ma come si implementa questa cosa? Che scrivevo questo post a fare sennò? Nella rete di questa azienda c’era un server DHCP dedicato, che distribuiva quindi gli indirizzamenti e le configurazioni di networking generali(DNS, WPAD, GW ecc ecc) rendendo così la cosa ancora più semplice e meno macchinosa del previsto.

Mi sono collegato sullo switch via telnet, e entrato nella console ho cominciato la mia missione come da policies seguenti:

switch-p01(config)# configure terminal

switch-p01(config)# ip dhcp snooping

switch-p01(config)# ip dhcp snooping vlan 1-32 (se volete potete modificare il range di VLAN in base alla vostra rete)

switch-p01(config)# ip dhcp snooping information option

switch-p01(config)# interface 12

switch-p01(config)# ip dhcp snooping trust

switch-p01(config)# exit

switch-p01(config)# ip dhcp snooping verify mac-address

switch-p01(config)# ip arp inspection vlan 1-32 (se volete potete modificare il range di VLAN in base alla vostra rete)

switch-p01(config)# ip arp inspection limit 15

switch-p01(config)# errdisable recovery cause arp-inspection interval 300

switch-p01(config)# ip arp inspection validate dst-mac src-mac ip

switch-p01(config)# end

switch-p01(config)# copy running-config startup-config

Cosa succede ora al nostro caro script kiddie che si stava divertendo con ettercap? Ecco qua un piccolo log della console dello switch salvato proprio per voi durante il suo tentativo massiccio che rallentava tutto.

switch-p01# Oct 20 16:42:51.873: %SW_DAI-4-PACKET_RATE_EXCEEDED: 16 packets received in 252 milliseconds on Fa0/3.
switch-p01# Oct 20 16:42:51.873: %PM-4-ERR_DISABLE: arp-inspection error detected on Fa0/3, putting Fa0/3 in err-disable state
switch-p01# Oct 20 16:42:52.877: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
switch-p01# Oct 20 16:42:53.881: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down

Avendo tentato di Poisonare tutta la LAN con ettercap, per protezione la sua interfaccia è stata messa in stato di shutdown per 300 secondi; cioè per cinque minuti esatti. Sono stato cattivo vero? Lo so, però mi sembrava un tempo utile per farlo desistere dal ritentare ancora con questi giochetti😉

Molti di voi si staranno chiedendo….” Cosa succede se invece di poisonare tutta la LAN lo script kiddie ha già un elenco di host da poisonare oppure imposta un rate limit inferiore a quello massimo che hai impostato sopra??? ” Domanda corretta e lecita da parte vostra. Come avrete già intuito dalle righe di configurazione precedentemente descritte non ho di certo sottovalutato lo script kiddie, cercando di tener conto di tutte le varie modalità alternative con cui egli poteva eseguire l’attacco. Questo consapevole che il nostro amico ci avrebbe riprovato ancora, magari tentando di bypassare tale protezione o policy. Per sua sfortuna però, secondo le righe di sintassi che ho inserito prima, viene fatto pure un check-up sul MAC e l’indirizzo IP di sorgente/destinazione(la ciliegina sulla torta) sia a livello di ARP che di DHCP entries passanti sulle VLAN untrusted. In questo modo viene pure costruito un database in base agli indirizzi IP richiesti & poi rilasciati dal server DHCP della LAN. Insomma il suo attacco non ha più successo.

Infatti ecco a voi cosa succede sulla console dello switch a conferma di quanto detto

switch-p01# Oct 20 16:47:44.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/000c.2957.6b39/192.168.69.112/16:47:44 UTC Tue Oct 20 2009])
switch-p01# Oct 20 16:47:44.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/0016.cb97.3e33/192.168.69.31/16:47:44 UTC Tue Oct 20 2009])
switch-p01# Oct 20 16:47:45.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/000c.2957.6b39/192.168.69.31/16:47.44 UTC Tue Oct 20 2009])

Insomma come avrete visto dal secondo log, anche se le arp request fasulle sono in uscita lo switch le rileva e droppa tali pacchetti “manipolati” facendo passare solo le arp request/response valide originate dal client aziendale e non da ettercap.

Bene…. Anche questa volta abbiamo risolto il problema rendendo pure inoffensivo lo script kiddie e i suoi giochetti ARP. Spero che tale tutorial scritto in modo narrativo informale vi abbia soddisfatto, o comunque abbia incuriosito i colleghi in merito a tali features contro questi tipi di attacchi MITM che spesso sono un grattacapo per tanti network admin. Nel caso abbiate domande o dubbi io sono qui a disposizione; tempo permettendo.

Ciauz e alla prossima

  1. 7 agosto 2013 alle 06:03

    Thanks for sharing your thoughts on your site.
    Regards

  1. 31 ottobre 2009 alle 16:01

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: