Archivi tag: cam

Hub vs switch: facciamo un po’ di chiarezza

Qualche tempo fa un mio collega (che svolge tutt’altra mansione rispetto alla mia e che quindi non è un tecnico), mi ha chiesto quale fosse la differenza tra hub e switch, dato che i primi sono ormai quasi del tutto irreperibili sul mercato (a meno di qualche aggeggio usato).

In soldoni, gli hub non sono altro che dei repeater “multiporta” (lasciatemi passare il termine), ovvero il traffico ricevuto su ciascuna porta viene inoltrato, indifferentemente, su tutte le altre. Toccherà poi alle schede di rete dei dispositivi connessi all’hub “capire” se il MAC address di destinazione del frame è il proprio (in questo caso lo accetteranno) oppure è associato a qualche altra macchina, scartandolo. L’ultima affermazione è vera solo ed esclusivamente se la suddetta scheda di rete non è configurata in modalità promiscua. Questa modalità, infatti, le consentirebbe di “accettare” tutti i frame, indifferentemente dal fatto che siano destinati ad essa o meno (e ciò è indispensabile nel caso in cui si voglia sniffare il traffico dei dispositivi connessi all’hub).

comparison

Ad esempio, per mettere un’interfaccia in modalità promiscua su una macchina Linux, occorre digitare il comando:

[root@linuxbox ~]# ifconfig <nome_interfaccia> promisc

Inoltre, tale modalità viene abilitata in automatico nel caso in cui sulla Linux box sia installato ed attivo un software che funge da NIDS, quale snort.

Un’altra peculiarità dell’hub riguarda la gestione dei cosiddetti domini di collisione. Infatti, tutti i dispositivi collegati ad esso faranno parte del medesimo dominio di collisione, mentre gli switch, per definizione, riescono a garantire un dominio di collisione ad-hoc per ciascuna porta di cui sono dotati. Per essere più precisi, gli switch sono caratterizzati dalla presenza di una memoria interna, in gergo CAM (acronimo che sta per Content Access Memory), in cui vengono memorizzate le accoppiate MAC address sorgente/porta su cui è stato ricevuto. Tale fase di popolamento della CAM avviene per gradi, ovvero man mano che i dispositivi collegati a ciascuna porta iniziano a trasmettere: quando lo switch vede come MAC sorgente un dato indirizzo L2 su una specifica porta, memorizzerà tale accoppiata all’interno della CAM. Successivamente, quando un frame recante uno specifico MAC di destinazione verrà ricevuto dallo switch, esso lo inoltrerà solo ed esclusivamente sulla porta in cui il dispositivo recante il suddetto MAC è collegato.

Il vantaggio di tale meccanismo di gestione del traffico è abbastanza chiaro: mettendo in comunicazione solo mittente e destinatario, si viene a creare una sorta di “mezzo trasmissivo” dedicato tra di essi, riducendo notevolmente (ma non eliminando completamente) il rischio di collisioni (almeno per quanto riguarda le reti half duplex in cui tale fenomeno può verificarsi). Tirando le somme, è proprio per questo motivo che lo switch “garantisce” un dominio di collisione dedicato per ciascuna porta di cui è dotato. Inoltre, lo sniffing del traffico risulta impossibile, a meno che su una delle porte dello switch sia configurato il cosiddetto port mirroring (che la Cisco chiama SPANCatalyst Switched Port Analyzer). Nella fattispecie, essa consente di inoltrare il traffico ricevuto (su una o più porte) su quella in cui è configurato il mirroring (solitamente utilizzo allo scopo l’ultima porta dello switch o le ultime 2). Va da se che anche in questo caso l’interfaccia del PC adibito a sniffer deve essere configurata in modalità promiscua.

Spero di aver fatto un po’ di luce sulla questione.

Alla prossima.

Gli IP Plan non aggiornati

In un ambiente enterprise mantenere un IP plan aggiornato è un’operazione alquanto ardua (soprattutto se coloro che devono gestire l’infrastruttura IT sono dislocati su sedi diverse).

 

networking.jpg

Quello che mi è capitato di recente mi ha fatto capire quanto un IP plan attendibile possa essere importante. Nello specifico, dopo aver installato e configurato un nuovo server, ho richiesto un indirizzo IP privato da poter assegnare alla suddetta macchina, senza creare eventuali conflitti con gli altri apparati già in produzione.

La prima cosa che ho fatto è stata quella di consultare l’IP Plan, scegliendo un indirizzo libero. Successivamente ho comunicato l’indirizzo in questione al sistemista network, il quale mi ha confermato la disponibilità dello stesso.

Per scrupolo ho effettuato un ping, il quale non ha fornito alcuna risposta, ergo tutti gli indizi mi lasciavano pensare che l’indirizzo scelto fosse effettivamente disponibile.

Fast forward di 30 minuti: una volta patchata la porta del server ed attestata sulla porta dello switch appartenente alla VLAN di riferimento, ho iniziato a ricevere degli ICMP echo reply a singhiozzo.

Tentando di connettermi via RDP alla suddetta macchina, con mio enorme stupore, ho notato che l’hostname del server su cui ero atterrato era differente da quello da me configurato, ergo vi era già una macchina che utilizzava l’indirizzo IP che credevo libero.

Nuovo giro di telefonate, altri check al volo e finalmente sono riuscito ad individuare un indirizzo IP effettivamente disponibile.

Contromisure

Per non incappare in una simile problematica è necessario aggiungere altri check al semplice ping ed alla consultazione dell’IP plan. Infatti, alcuni SO, quali Windows Server 2008 R2, hanno il firewall embedded configurato in modo da droppare le richieste ICMP. Quindi, per sincerarsi dell’effettiva disponibilità di un indirizzo, occorre dapprima consultare l’arp table dello switch su cui sono attestati i server della farm (generalmente trattasi di un core switch). Tale check va fatto a server disconnesso e partendo dal presupposto che non vi siano degli switch intermedi.

Per i Cisco, il comando da lanciare è il seguente:

Switch# sh arp | i <indirizzo IP>

Se l’arp table non restituisce alcun risultato significa che l’indirizzo IP scelto è libero. Ovviamente, se il server è stato disconnesso immediatamente prima di effettuare il suddetto controllo, è necessario aspettare che scada il cosiddetto aging time delle entry relative alla arp table (che varia in base alla tipologia ed al vendor dello switch, sempre che i valori impostati siano quelli di default).

Successivamente, a server connesso, si potrebbe individuare il MAC address della sua scheda di rete e controllare se l’associazione IP-MAC presente nella tabella ARP contiene il suddetto indirizzo fisico.

Infine, controllando le entry della CAM, ci si può sincerare che il MAC individuato sia stato letto sulla porta dello switch sul quale il server è effettivamente attestato.

Per i Cisco il comando da utilizzare è questo:

Switch# sh mac-address-table | i <indirizzo MAC>

Da notare che il MAC dovrà essere digitato nella forma aaaa.bbbb.cccc

In alternativa a tale procedura (che richiede comunque una certa familiarità con il networking), si potrebbe utilizzare un port scanner, ad esempio nmap.

Esiste anche una versione per Windows, scaricabile da qui, ed il comando da lanciare è il seguente:

nmap -P0 <indirizzo IP>

In particolare, con la flag -P0 sto imponendo al software di non lanciare dei ping preliminari per testare l’effettiva raggiungibilità dell’IP (evitando quindi i falsi negativi), procedendo immediatamente con la scansione delle porte.

State tranquilli, il port scan non è reato se non è seguito da dei tentativi di accesso non autorizzati (verificate comunque le policy aziendali prima di lanciarlo).

E’ tutto. Alla prossima.

Cisco port security

Come sono solito ricordare, la sicurezza dei dispositivi deve iniziare dai livelli più bassi (ad esempio da quello fisico, utilizzando case allarmati oppure posizionando i device all’interno di CED dotati di meccanismi per il controllo biometrico all’ingresso), fino ai livelli più alti (come quello applicativo).

Seguendo questo ragionamento, si può facilmente affermare che le celeberrime ACL standard, estese e nominali lavorano a livello 3 e 4, mentre il port security lavora a livello 2 (alias Data Link, in particolare sublyer MAC).

 

port_Sec.jpg

Ma come funziona realmente il port security? Semplice, controlla i MAC address provenienti da una data interfaccia ed in caso di anomalia (come la ricezione di un indirizzo MAC diverso da quello atteso) applica delle misure di protezione (ad esempio disabilitando la porta).

In questo modo lo switch (ma tale ragionamento vale anche per i router ed i firewall dotati di interfacce Ethernet), presenta una maggiore resistenza ad attacchi di vario tipo, come il cosiddetto MAC flooding, il cui scopo è quello di saturare la memoria CAM (di cui sono dotati gli switch), causando una sorta di denial of service.

Ma vediamo adesso come abilitare tale funzionalità su uno switch Cisco.

Per prima cosa occorre identificare le porte su cui applicare il port security. Per fare ciò è necessario indicare esplicitamente la modalità di funzionamento della porta stessa (access o trunk), in quanto tale misura di sicurezza non può essere applicata alle porte in dynamic mode.

Onestamente credo che abilitare il port security su una porta in trunk sia controproducente, poichè sarebbe meglio operare sul vlan allowed piuttosto che su un filtraggio a livello 2 (non possiamo conoscere a priori tutti i MAC address che transiteranno lungo il trunk ed anche se questo fosse possibile, bisognerebbe dichiararli tutti manualmente con grande mole di lavoro annessa).

Ergo, mettiamo in access le porte su cui vogliamo abilitare il port security, ad esempio:

 Switch(config)# int fa0/0
 Switch(config-if)# switchport mode access

Se volessimo mettere in access più porte possiamo utilizzare il comando int range, ad esempio:

 Switch(config)# int range fa 0/0 - 12
 Switch(config-if)# switchport mode access

Ora sulle porte che abbiamo messo in access possiamo abilitare il port security:

Switch(config-if)# switchport port-security

In questo modo, lo switch terrà conto del MAC address ricevuto su una data porta (e salvato nella CAM), e nel caso in cui su quella stessa porta riceverà un MAC address diverso da quello memorizzato, la disabiliterà.

Nel caso in cui, invece, su una data porta dello switch sia allacciata ad esempio una macchina fisica su cui gira un middleware (come VMWare ESX) che gestisce N macchine virtuali (ognuna delle quali è dotata di una o più schede Ethernet e quindi uno o più MAC address), possiamo utilizzare il parametro maximum per specificare il numero massimo di indirizzi MAC che possono essere ricevuti su quella specifica porta:

 Switch(config)# int fa0/0
 Switch(config-int)# switchport port-security maximum 5

Inoltre, è possibile definire a priori il MAC address consentito su una specifica interfaccia dello switch:

Switch(config-int)# switchport port-security mac-address XXXX.YYYY

I 16 byte utilizzati per la rappresentazione di un MAC (in notazione esadecimale, conosciuta anche come hex), nei dispositivi Cisco devono essere indicati come XXXX.YYYY.

Se un’interfaccia va in error-disabled state a causa di una violazione identificata dal port security, è possibile riabilitarla utilizzando i seguenti comandi:

 Switch# term mon
 Switch# conf t
 Switch(config)# int fa0/0
 Switch(config-int)# shut

Appena riceverevo in output una notifica simile alla seguente:

1w0d: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to down

possiamo riabilitare la porta:

Switch(config-int)# no shut

Occorre precisare che il comando term mon è fondamentale se ci si connette al dispositivo mediante vty, in quanto abilita la visualizzazione delle notifiche (ad esempio il cambio di stato di un’interfaccia).

Per verificare se il port security è stato applicato su una specifica porta è sufficiente digitare:

Switch# sh run int <nome porta>

Mentre per visualizzare le informazioni relative al port security applicato ad una specifica interfaccia occorre usare il comando:

Switch# sh port-security int <nome interfaccia>

Per visualizzare le informazioni sul port security relativo a tutte le interfacce su cui è stato applicato basta lanciare il comando:

Switch# sh port-security

Infine, per listare tutti i MAC address memorizzati dal port security (e quindi ritenuti sicuri), è necessario digitare:

Switch# sh port-security address

Ovviamente il port security consente una maggiore customizzazione rispetto alla procedura (piuttosto basilare) mostrata in questo post. Dunque per maggiori dettagli vi invito a leggere la guida ufficiale Cisco.

A presto.