domenica, Dicembre 22, 2024

“SPAN veloce” su Cisco Catalyst

Alessandro Torchia
Alessandro Torchiahttp://www.areanetworking.it
Trent'anni, sistemista Unix, specializzato su Solaris, sistema Operativo di casa Sun. Attualmente lavora come consulente presso una delle aziende sanitarie presenti sul territorio italiano. Certificato Sun SCSA (Solaris Certified System Administrator) e Sun SCNA (Solaris Certified Network Administrator), è responsabile dei sistemi cluster Sun SPARC Midrange, e della Storage Area Network FC presenti nei CED dell'azienda. Attualmente studia per conseguire la certificazione Sun Cluster 3.2 Administrator. In passato ha lavorato in ambito networking presso varie realtà prevalentemente su apparati Cisco e Nortel. Ha frequentato l'Academy CCNA e Fundamentals of Wireless, e cerca di mantenere vive le conoscenze acquisite in quest'ambito, nonostante la sua predilezione per l'ambito sistemistico Unix e la passione per Solaris siano la sua prima scelta.

“SPAN veloce” non è l’ultimo grido nel già pessimo gusto che, spesso, il mondo IT ha nell’attribuire nomi.
E’ solo il mio modo di dirvi: ecco come fare alla veloce un mirroring di interfacce su altre, con lo scopo che volete, ma non ultimo quello di dare degli ottimi spunti a Snort e analyzers vari per il probing di ciò che passa sui vostri cavi.

In questo breve articolo, una macchina dedicata con funzione di sonda e IDS, attinge dal Catalyst le informazioni, pescando da punti vitali scelti con più o meno cura da voi, o da me nell’esempio.
Soprattutto voglio marcare la versatilità che uno switch decente (sì ok, un 2950 forse è esagerato, ma godiamocelo finchè c’è) può avere con poco ingegno e due VLANs.

Ingredienti:

  • Una interfaccia Ethernet “veryfree” su una macchina di modesta capacità (anche senza GUI, meglio se Linux)
  • 4 righe di configurazione sul Catalyst
  • Tonnellate di compilazioni e smanettaggi per settare ad hoc Snort, database e interfacce varie (o apt-get install acidlab) per farlo in quattro secondi su Debian)
  • Se non Snort (perchè a voi non interessa), va bene un tcpdump, ettercap, anche solo iptraf, etc.

Per sapere come installare e configurare ad-hoc Snort: andate pure qui http://www.areanetworking.it/installazione-di-snort-piu-interfacce-web.html

Inutile parlarne meglio e oltre. La vostra macchina sniffer-snorter sarà pronta in qualche batter di ciglia.

La nostra LAN d’esempio (a casa mia) è molto semplice ed è costituita di un modem con interfacce ADSL ed Ethernet, un router con due Ethernet connesso al modem di sopra lato outside, e lato inside al nostro fido Catalyst 2950G-EI (ma va bene praticamente qualunque, con microvariazioni se dotato di IOS e macrovariazioni nella sintassi usata se dotato di CatOS; noi vedremo come muoverci sul più simpatico IOS), da lì tutti gli hosts che vogliamo, lasciando una porta o più per la nostra sonda.
L’esempio di seguito illustrato vuole usare un’interfaccia dedicata senza IP in modalità promiscua per recuperare tutto il traffico che entra nella nostra LAN, dopo aver passato il router, dotato o meno di firewall (questo lo vedremo dopo). Il luogo migliore, per il migliore risultato, non può che essere nel cavo che dal router va allo switch (router[e1]-cat[e0/1] secondo la seguente figura:

figura1SPANcat.gif

Normalmente ci sarebbe bisogno di un hub o meglio di un tap Ethernet (che potete trovare in ottimo aspetto in un how-to alla fabbricazione nella sezione Docs di www.snort.org). Ma noi stavamo parlando di SPAN e di Catalyst.

Il problema (o la miglioria, a seconda delle situazioni) introdotto dagli switches è che, a differenza degli hubs, non permette di sniffare tutto ciò che vi passa semplicemente connettendosi a una delle sue “porte”. Proprio per la sua logica di funzionamento, lo switch divide in tanti microsegmenti il nostro ambiente, tanti quante sono le interfacce che state utilizzando: si tratta di veri e propri link punto-punto indipendenti tra loro, e vi sarà impossibile ricevere su una interfaccia il traffico che non vi è espressamente destinato durante il normale fuzionamento (salvo pochi casi).

Questo rende molto meno efficace quello che vogliamo fare: sniffare tutto il traffico senza problemi.
Quindi è importante scegliere dove andare a piazzare la nostra sonda e usare qualche accorgimento per recuperare proprio tutto ciò che vogliamo, nel nostro caso, tutti i pacchetti.
Inoltre “spezzare” il cavo richiederebbe un tap, su link full-duplex dell’hub non ve ne fate nulla, ma come già vi è stato consigliato, avrete già depositato hubs e amici nel bidone dei rifiuti: lasciamo il link router-catalyst al suo posto e plugghiamo la nostra sonda su una interfaccia libera dello switch (diciamo [e0/2] secondo Figura2).

Ci basterà loggarci sullo switch e dare i seguenti comandi:

mega@topobox ~ $ telnet cat
Trying 10.0.0.200...
Connected to cat.
Escape character is '^]'.
Password: 
catbox#en
Password: 
catbox#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
catbox(config)#monitor session 1 source interface fastEthernet 0/1 both
catbox(config)#monitor session 1 destination interface fastEthernet 0/2

(ricordate di salvare quando sarete soddisfatti della configurazione)
Tutto il traffico che attraversa il vostro router sarà visibile andando su un terminale della vostra macchina sniffer e dando

wallbox:~# ifconfig eth2 up
wallbox:~# tcpdump -i eth2

Solleverete un’interfaccia, senza bisogno di assegnargli un IP, e avvierete il dump su schermo del traffico che passa dal router allo switch, fino a voi tramite il mirror creato coi precedenti comandi, tra le interfacce fa0/1 e fa0/2 su Catalyst. Potete anche dire al vostro mirror di replicare solo il traffico che viaggia da router verso la LAN, in modo da non generare traffico non necessario sulla sonda. Consiglio di dare sullo switch un:

catbox(config)#monitor session 1 source ?
catbox(config)#monitor session 1 destination ?

Fantastico! Se Snort è su come lo è il mio comincerà quasi da subito a subbissarvi di falsi positivi. Configurate a dovere finchè siete contenti…ora nulla più scapperà al vostro vigile occhio…

… ma, se non foste contenti?
Nel caso vogliate di più e magari il vostro router ha un firewall ottimamente configurato che fa passare ben poco traffico “interessante” (e meno male), o volete farvi un’idea di cosa arriva sul vostro router, è possibile farci uno snapshot completo di ciò che vi arriva piazzando una seconda “sonda virtuale”.

Come:
Il sovradimensionato Catalyst può essere suddiviso in più bridge. Sui vecchi (o altri) Cisco era possibile dividere in più bridge virtuali il singolo switch (se non sbaglio in 4 bridge virtuali un catalyst 1900 o 2820). Non so se sia possibile anche su 2950, e sinceramente gli darei poco senso, vista la possibilità che dà l’uso delle VLANs in flessibilità e configurabilità.

Per chi non sa cosa siano le VLANs, la cosa si fa tesa e vi rimando, per riempire questo grave vuoto culturale a quest’altro mio articolo: Cisco VLAN Trunking Protocol e questo Le VLAN – 1a_parte che illustrano, oltre alle VLANs, il protocollo di gestione dinamica delle VLANs Cisco VTP in maniera abbastanza approfondita.

Fin’ora, su una configurazione standard, avevamo tutte le interfacce sulla VLAN di default: la VLAN1 su cui sono attestate le interfacce; e ci andava bene così, lungi dal configurare una VLAN apposita per il traffico e lasciare alla VLAN1 i soliti compiti di management e “repository di interfacce down”, se non ve n’è bisogno.
Ma adesso ci interesserebbe andare a monte del router-firewall, “spezzare” il cavo modemadsl-router e prendere i pacchetti alla fonte.

Utilizziamo per questo obiettivo due interfacce, la [fa0/3] che connetteremo alla [e0] del router e la [fa0/4] connessa al modem adsl. Creando una VLAN2 contenente le due interfacce interessate siamo in grado di creare uno switch virtuale a se stante che non fa altro che congiungere i due apparati, dandoci la possibilità di configurare un’altro mirror da passare alla nostra sniffing machine.
Qui ci scontriamo, non senza una facile soluzione, con una delle limitazioni imposte dalla serie Catalyst 2950 che sto utilizzando. Infatti mi permette di configurare una sola sessione di monitoraggio. Inutile dire che modelli più “grossi” non hanno questa limitazione (2 Span Sessions sui 35xx e molte di più sui 5/6000 CatOS based).

Ci tocca, quindi, ovviare aggiungendo la nuova porta alla sessione in corso (sempre che non avete deciso di eliminare la config precedente in favore di una soluzione con il solo span che andremo a configurare.
Passiamo ai fatti. Creazione della Vlan2:

catbox#en
catbox#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
catbox(config)#vlan 2
catbox(config-vlan)#media ethernet 
catbox(config-vlan)#no shut
VLAN 2 is not shutdown.
catbox(config-vlan)#exit
catbox(config)#int fastEthernet 0/3
catbox(config-if)#switchport mode access
catbox(config-if)#switchport access vlan 2
catbox(config-if)#no shut
catbox(config-if)#int Fa0/4
catbox(config-if)#switchport mode access
catbox(config-if)#switchport access vlan 2
catbox(config-if)#no shut

E abbiamo il nostro switch virtuale dedicato al link modem-router, completamente indipendente dagli altri links presenti, e in ottima sicurezza (si spera, la vlan2 dovrebbe poter comunicare con la vlan1 solamente tramite apposito router configurato espressamente per fare il Routing tra le due).
Un appunto è da fare, per quanto riguarda la configurazione delle VLANs.
Su 2950, e non solo, son presenti due metodi di configurazione: “da EXEC vlan databas” e da “Global Config vlan #”. Consiglio caldamente (lo fa anche Cisco), di utilizzare il secondo metodo, in quanto in linea con lo stile sintattico IOS e (seppur non ci dovrebbero essere problemi di compatibilità) soprattutto, in quanto il primo metodo è deprecato e sarà rimosso nelle future releases di IOS.
Non resta che replicare il traffico sulla SPAN port e siamo a posto:

catbox(config)#monitor session 1 source interface fastEthernet 0/3 both
catbox(config)#monitor session 1 destination interface fastEthernet 0/2

Il secondo comando non serve nel caso sia ancora configurata e attiva la parte vista precedentemente. Naturalmente potete scegliere se usare come source l’interfaccia fa0/4 piuttosto che la fa0/3.
Sotto abbiamo la situazione corrente riassunta in:

catbox#show vlan 

VLAN Name                         Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active     Fa0/1, Fa0/2, Fa0/5, Fa0/6
                                                         Fa0/7, Fa0/8,  Fa0/9, Fa0/10
                                                         Fa0/11, Fa0/12, Fa0/13, Fa0/14
                                                         Fa0/15, Fa0/16, Fa0/17, Fa0/18
                                                         Fa0/19, Fa0/20, Fa0/21, Fa0/22
                                                         Fa0/23, Fa0/24, Gi0/1, Gi0/2
2    VLAN0002                     active    Fa0/3, Fa0/4

catbox#show monitor session all
Session 1
---------
Type              : Local Session
Source Ports      :
    Both          : Fa0/1,Fa0/3
Destination Ports : Fa0/2
    Encapsulation : Native
          Ingress: Disabled

Ecco qua. Questo è uno dei metodi, forse il più semplice di utilizzare il Catalyst e le sue funzionalità SPAN e Vlans per facilitare il probing.
Sicuramente non è il solo, sia perchè sull’uso che si può fare del mirroring del traffico ci sarebbe molto di più da dire, e magari lo faremo in altra sede, sia perchè altre soluzioni si adatterebbero meglio a topologie/apparati diversi.
Ad esempio, come aggiustarsi nel caso anzichè un router ethernet , ci fosse stata una soluzione WAN integrata tipo il più consono 827/837 o maggiori? In quel caso, mi viene in mente come possibilità qualcosa tipo

RouterAdsl(827/837/17xx) -->�Sonda�--->Firewall(Linux/PIX)

In modo da avere tutto il traffico pulito e “raccolto” prima del filtering, o addirittura, più semplice ed economico gestire Sonda e Firewalling da una stessa Macchina *nix

RouterAdsl ----> Snort+Firewall(Linux/Bsd/Solaris)

Con questo pongo fine ai miei deliri! E mi pubblico sperando di essere stato utile/simpatico e ispiratore di nuovi esperimenti.
Vi invito a scrivermi per eventuali e sempre presenti correzioni-aggiunte-rimozioni o anche solo per chiedere chiarimenti: [email protected]

Articoli correlati

Noleggia una Tesla per il tuo evento ICT!

Categorie