Archivi tag: catalyst

Cisco port security

Sicurezza, , , , , ,

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.

Stack Catalyst 3750 ed SNMP

Networking, , , ,

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$' -r '$ARG3$'
}

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!1
}

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!1
}

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!1
}

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!1
}

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!1
}

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!1
}

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.

Snmpwalk: visualizzare informazioni sulle interfacce di un Cisco Catalyst 3750

learning log, , , , , ,

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:

Snmp.gif
Grazie alle MIB (Management Information Base), inoltre, è possibile identificare mediante una determinata stringa parte di un OID. La tabella seguente può far capire in modo abbastanza banale che cosa si intende per MIB:
OID                     MIB
1.3                      org
1.3.6                   dod
1.3.6.1               internet
1.3.6.1.1            directory
1.3.6.1.2            mgmt
1.3.6.1.3            experimental
1.3.6.1.4            private
1.3.6.1.4.1         enterprises
Quindi l’OID utilizzato nell’ambito della query effettuata mediante snmpwalk equivale a:
mgmt.1.2.2.1.1
Infine, occorre precisare che del protocollo in questione esistono ben 3 versioni: la 1 e la 2 piuttosto insicure, in quanto non cifrano la community string (neanche quando le query vengono effettuate da remoto attraverso Internet). La versione 3, invece, prevede un meccanismo di cifratura che la rende molto più sicura rispetto alle versioni precedenti.
Bye.

Abilitare SSH su switch Cisco Catalyst 3750

Networking, , , ,

Prima di introdurre questa mini-guida, occorre precisare che non tutte le IOS Cisco supportano SSH. Nella fattispecie, quelle abilitate a ricevere connessioni mendiante Secure SHell riportano la dicitura K9 nell’ambito del filename.

Ma veniamo a noi. Per prima cosa, occorre creare la chiave RSA da utilizzare come fingerprint. Per fare ciò basta digitare il comando:

Switch(config)# crypto key generate rsa general-keys label ssh-fingerprint

Dopodichè digitiamo:

Switch(config)# ip ssh version 2

in modo da abilitare sul dispositivo la versione 2 del protocollo SSH (più robusta della 1).

Adesso definiamo username e password di accesso:

Switch(config)# username <vostro username> password <vostra password>

A questo punto disabilitiamo l’accesso telnet e consentiamo solo quello ssh usando il comando transport input (e già che ci siamo aggiungiamo username e password appena creati come credenziali per il login):

 Switch(config)# line vty 0 15
 Switch(config)# login local
 Switch(config-line)# transport input ssh
 Switch(config-line)# end

Infine salviamo la configurazione:

Switch# copy run start

ed il gioco è fatto.

A presto.

Cisco port-channel

Networking, , , ,

Ora, premesso che il port-channeling NON E’ argomento CCNA come ho sentito spesso dire (almeno per quanto riguarda l’esame 640-801), il seguente post ha lo scopo di chiarire a cosa serve effettivamente la feature in questione.

Nella fattispecie, mediante il port-channeling è possibile fare in modo che più interfacce vengano coinvolte da un unico flusso logico di informazioni (in pratica è come se costituissero un’unica interfaccia), semplificando notevolmente la vita agli amministratori, soprattutto in caso di guasti o nel caso in cui si vogliano evitare i loop senza la necessità di utilizzare il protocollo STP.

Ora, le condizioni necessarie per garantire il corretto funzionamento del port-channeling sono le seguenti:

– Stessa velocità e duplex (half/full) delle porte coinvolte (è impensabile creare un port-channel tra una FastEthernet ed una GibabitEthernet);

– Le porte devono appartenere alla medesima VLAN (se il port-channeling non viene utilizzato per un trunk);

– Nel caso in cui il port-channeling riguardi un trunk, è indispensabile che tutte le porte coinvolte siano caratterizzate dallo stesso tipo di trunk, abbiano le stesse VLAN native e permettano il traffico proveniente dalle stesse VLAN (identificate con il termine VLAN-allowed);

– Nel caso in cui venga utilizzato l’STP per la gestione dei loop, le porte coinvolte devono avere il medesimo costo nell’ambito delle VLAN di appartenenza;

– Sulle interfacce coinvolte non deve essere implementato il port-mirroring (SPAN), il cui scopo è quello di mandare una replica dei frame ricevuti su una data porta dello switch verso un’altra porta dello stesso switch a cui è collegato un sistema di monitoring (ad esempio un IDS).

Detto questo, occorre fare alcune precisazioni:

1) quasi tutti gli switch marcati Cisco permettono la creazione di un numero massimo di port-channel pari a 64;

2) Ciascun canale può coinvolgere dalle 2 alle 8 interfacce, in modo tale da favorire le operazioni di bilanciamento del traffico (load-balancing).

Per ciò che concerne proprio il load-balancing, è possibile implementare un metodo di bilanciamento diverso per ogni port-channel. I metodi applicabili possono basarsi su alcuni parametri riguardanti i livelli 2, 3 e 4 della pila ISO/OSI. Nella fattispecie, le discriminanti possono essere:

1) Indirizzo MAC sorgente – src-mac;

2) Indirizzo MAC di destinazione – dst-mac;

3) Entrambi gli indirizzi MAC (sia sorgente che di destinazione) – src-dst-mac;

4) Indirizzo IP sorgente – src-ip;

5) Indirizzo IP di destinazione – dst-ip;

6) Entrambi gli indirizzi IP (sia sorgente che di destinazione) – src-dst-ip;

7) Porta (UDP o TCP) sorgente – src-port;

8) Porta (UDP O TCP) di destinazione – dst-port;

9) Entrambe le porte UDP o TCP (sia sorgenti che di destinazione) – src-dst-port.

Per scegliere il metodo pù adatto alle nostre esigenze ed implementarlo sullo switch basta digitare il comando:

Switch(config)# port-channel load-balance <opzione>

Per quanto riguarda, invece, la possibilità di formare i port-channel in modo dinamico, possono essere utilizzati i seguenti protocolli:

– PAgP (proprietario CISCO);

– LACP 802.1AD

Per mettere in piedi il port-channel vero e proprio è necessario digitare:

Switch(config-if)# channel-group <identificativo numerico> mode <modalità di funzionamento>

nell’ambito del sottomenù delle interfaccie che devono essere coinvolte durante formazione del port-channel stesso.

Le modalità di funzionamento sono le seguenti:

– on (non fa uso nè di PAgP nè di LACP 802.1AD, disabilitando di fatto la formazione dinamica dei port-channel);

– off (fa in modo che la porta non venga coinvolta nell’ambito del port-channel);

– auto (fa uso del PAgP in modalità passiva);

– desirable (fa uso del PAgP in modalità attiva);

– passive (fa uso del protocollo LACP in modalità passiva);

– active (fa uso del protocollo LACP in modalità attiva).

Ma qual è la differenza esistente tra la modalità attiva e quella passiva? Semplicemente nel primo caso l’interfaccia rimarrà in attesa di ricevere pacchetti appartenenti al protocollo utilizzato (PAgP  o LACP). Nel secondo caso sarà proprio l’interfaccia ad inviare i pacchetti necessari alla formazione dinamica del port-channel.

Ora, per risparmiare tempo e fatica, è stato implementato un utilissimo comando che consente di settare i parametri necessari per la creazione del port-channel su tutte le porte coinvolte (o su alcune di esse). Tale comando è il cosiddetto range:

Switch(config)# interface range fa0/0 - 4

E, successivamente, il prompt dei comandi apparirà nel seguente modo:

Switch(config-range-if)#

Possiamo dunque digitare (ad esempio):

Switch(config-range-if)# channel-group 1 mode on

Infine, alcuni comandi che possono tornare utili per eventuali operazioni di troubleshooting sono i seguenti:

Switch(config)# sh interfaces port-channel <identificativo del group-channel>

oppure:

Switch(config)# sh etherchannel <identificativo del group-channel> summary

e ancora:

Switch(config)# test etherchannel load-balance interface port-channel <identificativo> ip <IP sorgente> <IP di destinazione>

A presto.