Archivi tag: mac address

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.

WI-FI IP camera made in China: ennesima stranezza

Ok, avete ragione, sono un maledettissimo freak control. Però non è colpa mia se questo aggeggio continua a comportarsi in modo strano. Infatti, oltre a questa anomalia, ho notato che ogni tanto prova a contattare l’ennesimo server cinese, questa volta un nameserver (almeno sulla carta).

Inoltre, molto probabilmente quel nameserver (sempre se di nameserver si tratta) è di proprietà del costruttore di questi aggeggi, tant’è che un semplice whois mi ha rivelato le seguenti informazioni:

nightfly@nightbox:~$ whois 211.154.141.240
% [whois.apnic.net node-1]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:        211.154.128.0 - 211.154.159.255
netname:        ChinaMotion
country:        CN
descr:          China Motion Network Communication
descr:          9F,Yu Hua Industrial & Trading Building,Bao Gang Rd.
descr:          Luo Hu District,Shenzhen, Guangdong Province
admin-c:        BY158-AP
tech-c:         BY158-AP
status:         ALLOCATED PORTABLE
mnt-by:         MAINT-CNNIC-AP
mnt-lower:      MAINT-CNNIC-AP
mnt-irt:        IRT-CNNIC-CN
mnt-routes:     MAINT-CNCGROUP-RR
changed:        hm-changed@apnic.net 20060523
source:         APNIC

person:         Binghua Yang
nic-hdl:        BY158-AP
e-mail:         idc-service@hotmail.com
address:        9F,Yu Hua Industrial & Trading Building,Bao Gang Rd.Luo
address:        Hu District,Shenzhen
phone:          +86-0755-82189782
fax-no:         +86-755-82189789
country:        CN
changed:        shenzhi@cnnic.cn 20041126
changed:        ipas@cnnic.net.cn 20070514
mnt-by:         MAINT-CN-CMNET
source:         APNIC

Ma bando alle ciance, ecco cosa succede sniffando un pò di pacchetti con tcpdump:

18:13:28.222925 IP 10.1.x.x.3072 > 8.8.8.8.53: 125+ A? dns.camcctv.com. (33)
        0x0000:  4500 003d 62c7 4000 4011 bcd3 0a01 0105  E..=b.@.@.......
        0x0010:  0808 0808 0c00 0035 0029 af81 007d 0100  .......5.)...}..
        0x0020:  0001 0000 0000 0000 0364 6e73 0763 616d  .........dns.cam
        0x0030:  6363 7476 0363 6f6d 0000 0100 01         cctv.com.....
18:13:28.288413 IP 8.8.8.8.53 > 10.1.x.x.3072: 125 1/0/0 A[|domain]
        0x0000:  4500 004d a392 0000 2f11 ccf8 0808 0808  E..M..../.......
        0x0010:  0a01 0105 0035 0c00 0039 28b5 007d 8180  .....5...9(..}..
        0x0020:  0001 0001 0000 0000 0364 6e73 0763 616d  .........dns.cam
        0x0030:  6363 7476 0363 6f6d 0000 0100 01c0 0c00  cctv.com........
        0x0040:  0100 0100 0009 6800 04d3 9a8d            ......h.....
18:13:28.325038 IP 10.1.x.x.3072 > 211.154.141.240.2011: UDP, length 84
        0x0000:  4500 0070 0000 4000 4011 cdec 0a01 0105  E..p..@.@.......
        0x0010:  d39a 8df0 0c00 07db 005c e3b5 4d4f 5f48  ...........MO_H
        0x0020:  0000 0000 3738 2d41 352d 4444 2d30 342d  ....78-A5-DD-04-
        0x0030:  4138 2d33 4500 0000 3130 2e31 2e31 2e35  A8-3E...10.1.x.x
        0x0040:  0000 0000 0000 0000 0000 0000            ............

Che significa tutto ciò? Brevemente: dapprima manda una query DNS di tipo A al suo nameserver primario (8.8.8.8), richiedendo l’IP associato all’hostname dns.camcctv.com:

18:13:28.222925 IP 10.1.x.x.3072 > 8.8.8.8.53: 125+ A? dns.camcctv.com

La risposta alla suddetta query è la seguente:

18:13:28.288413 IP 8.8.8.8.53 > 10.1.x.x.3072: 125 1/0/0 A[|domain]

Una volta individuato l’indirizzo IP di dns.camcctv.com (ovvero 211.154.141.240) procede con l’invio, verso la porta UDP 2011, del proprio MAC address e del proprio indirizzo IP locale.

Facendo due più due il conto è presto fatto: con il dyndns abilitato di default, l’IP pubblico del network a cui la telecamera appartiene diventa di dominio pubblico (e soprattutto di dominio del costruttore). A questo aggiungeteci le info che manda a quel nameserver e praticamente, nel caso in cui ci fosse una qualche backdoor all’interno del codice dell’interfaccia Web di cui è dotata, il costruttore (o chi per lui) avrebbe la possibilità di accedere liberamente alla nostra IP camera. A questo aggiungeteci l’eventualità che tutto il traffico in ingresso su quella porta del nameserver potrebbe essere loggato, rilevando quindi l’indirizzo IP pubblico della rete a cui appartiene la telecamera.

Ora, poichè tale device ha un server FTP integrato, mi sono preso la briga di accedervi e di scaricare in locale tutte le pagine Web (.htm) che concorrono al funzionamento dell’interfaccia di gestione. Inutile dire che non ci ho trovato granchè, anche perchè tutte le modifiche alla configurazione vengono effettuate mediante delle chiamate AJAX a determinate pagine *.xml (che, naturalmente, non sono scaricabili).

Infatti, per capire cosa sia possibile fare tramite delle semplici chiamate alle suddette pagine, è sufficiente consultare questo documento:

IPCamera_AJAX (English Translation) – GadgetVictimsCom.pdf

Per completezza, se volete provare ad accedere al suddetto server FTP (della vostra telecamera, non di certo della mia) è necessario:

1) utilizzare un client ben preciso, ovvero CuteFTP (con tutti gli altri, client FTP Linux da CLI, client FTP Windows da CLI, FireFTP, eccetera, il demone della telecamera crasha miseramente);

2) loggarsi con username MayGion e con password maygion.com (credenziali case sensitive e non modificabili – dove maygion è il produttore del firmware).

Come ho risolto? Di nuovo, regola Iptables del tipo:

iptables -A FORWARD -i eth1 -o eth0 -p udp -d 211.154.141.240 –dport 2011 -j DROP

Sto anche monitorando tutto il traffico diretto alla porta HTTP della telecamera, vediamo cosa ne verrà fuori.

Alla prossima.

Aggiornamento del 16/12/2012

A quanto pare l’hostname dns.camcctv.com è qualcosa di hard coded all’inteno dei sorgenti del firmware (a giudicare dal questo 3D). Inoltre, sembra che si tratti dell’ennesimo servizio di DDNS ma, non essendoci alcuna opzione che mi consenta di disabilitarlo via interfaccia Web, lo terrò comunque in DROP.

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.