Il blog sull'informatica

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).

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.

Spesso mi è capitato di avere a che fare con degli switch Cisco Catalyst 3750 configurati in Stack. Grazie a questa configurazione, due o più switch vengono visti, a livello logico, come un unico commutatore. Ciò significa che a tutto lo stack può essere associato un unico indirizzo IP di management.

Ma dove sta l'inghippo? Semplice: nel caso in cui si utilizzino dei sistemi di monitoraggio della rete (ad esempio nagios), il semplice ping non è sufficiente ad indicare che tutti gli switch di uno stack funzionano correttamente. Infatti, se uno di essi si guastasse, lo stack continuerebbe ad esistere e quindi ad essere raggiungibile a livello IP.

Come fare dunque per montorare l'effettivo stato di ogni singolo switch che costituisce lo stack? La risposta è semplice: SNMP.

In particolare, gli OID da utilizzare sono reperibili su questo server FTP anonimo (la directory è /pub/mibs/oid) ed il file di riferimento è CISCO-STACKWISE-MIB.oid

Per la precisione, gli OID che indicano lo stato di funzionamento relativo alle stackport degli switch che costituiscono uno stack sono i seguenti:

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5180 (per la prima porta del primo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181 (per la seconda porta del primo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5183 (per la prima porta del secondo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5184 (per la seconda porta del secondo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5186 (per la prima porta del terzo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5187 (per la seconda porta del terzo switch)

e così via.

Per verificare che gli OID sopra citati siano effettivamente supportati nell'ambito dello stack, potete utilizzare il comando snmpget (se avete a disposizione una linux box) oppure il tool Getif (nel caso in cui la vostra workstation sia una macchina Windows).

Configuriamo ora nagios. Per prima cosa definiamo il comando che ci permette di controllare lo stato dei vari switch:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config

nightfly@nightbox:~$ sudo nano snmp.cfg

Inseriamo la seguente direttiva:

 'snmp_stack' command definition
define command {
command_name    snmp_stack
command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o '$ARG2$'
}

Ora che abbiamo definito il comando, aggiungiamo il servizio per il monitoraggio degli switch all'interno del file di configurazione che identifica lo stack:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d

nightfly@nightbox:~$ sudo nano host-stack_nagios3.cfg

Inseriamo quanto segue:

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 1 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 1 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 2 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5183
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 2 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5184
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 3 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5186
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 3 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5187
}

Ovviamente sono partito dal presupposto che lo stack sia composto da 3 switch.

Salviamo il file e riavviamo nagios:

nightfly@nightbox:~$ sudo service nagios3 restart

e finalmente potremo monitorare l'effettivo stato degli switch di uno stack.

A presto.

Recentemente mi è capitato di avere a che fare con un tool per il monitoraggio della rete (weathermap). Questo tool, affinchè riesca a monitorare il traffico che interessa le varie interfacce di uno switch o di un router, effettua banalmente delle query SNMP.

Ora, la versione di tale protocollo abilitata sui vari device è la 2, ergo, utilizzando snmpwalk posso interrogare l'agente (e i vari subagent) in esecuzione sul dispositivo di mio interesse semplicemente digitando:

snmpwalk -v 2c -c <community string> <ip del dispositivo> 1.3.6.1.2.1.2.2.1.1

Direte voi... cos'è quel numero strano in coda alla query? Ebbene, quello è l'OID (Object Identifier) relativo alle interfacce del Catalyst. Ogni OID viene generato a partire dal cosiddetto SMI (Structure of Management Information), che presenta una struttura "ad albero". Per maggiore completezza, un esempio di SMI è riportato nella figura sottostante: