Il blog sull'informatica

Il protocollo SSH (acronimo si Secure SHell), viene utilizzato per stabilire una connessione cifrata con determinati host, in modo da ottenere accesso alla loro interfaccia a linea di comando (CLI).

Ora, l'accesso vero e proprio alla macchina remota può evvenire seguendo diverse strade, ad esempio mediante l'inserimento di opportune credenziali di accesso (username e password) oppure mediante uno scambio di chiavi (pubbliche). Quest'ultima modalità di accesso risulta estremamente utile quando un determinato host deve connettersi via SSH ad un altro in modo automatizzato (ad esempio attraverso un cronjob schedulato). Un caso molto diffuso riguarda l'upload via SCP dei log relativi ai vari dispositivi di rete direttamente sul logserver.

Vediamo ora come predisporre i nostri dispositivi per lo scambio automatico delle chiavi. Per prima cosa occorre generare, su ciascun host, una coppia di chiavi pubblica/privata (RSA a 2048 bit). E' possibile fare ciò mediante il comando:

nightfly@nightbox:~$ ssh-keygen

Durante la procedura di generazione delle chiavi è buona norma utilizzare una passphrase non vuota. Essa verrà adoperata per criptare la nostra chiave privata.

In particolare, la chiave pubblica verrà salvata all'interno del file id_rsa.pub nella direcotory nascosta .ssh presente nella home del nostro utente.

A questo punto connettiamoci all'host remoto via SSH in modo da aggiungere il suo fingerprint all'interno dei file known_hosts, anch'esso posizionato nella dir .ssh. Tale procedura si rende necessaria in quanto SSH prevede l'identificazione dell'host remoto e l'aggiunta esplicita (mediante popup di conferma) del suo fingerprint tra gli host fidati.

Una volta identificato l'host remoto occorre generare una coppia di chiavi anche su di esso. Il comando è del tutto identico a quello utilizzato sul notro PC.

Ora possiamo procedere con copia/incolla della nostra chiave pubblica sull'host remoto, salvandola all'interno del file authorized_keys, dopo averlo creato mediante il comando:

nightfly@nightbox:~/.ssh$ touch authorized_keys

e dopo avergli assegnato i permessi 600:

nightfly@nightbox:~/.ssh$ chmod 600 authorized_keys

Tale procedura va eseguita anche sul nostro PC, nel caso in cui dovesse essere il logserver ad effettuare una richiesta di connessione verso di noi. Ovviamente, in tal caso, all'interno del nostro file authorized_keys andrà copiata la chiave pubblica del server.

Attenzione: condizione necessaria affinchè tutto funzioni è che l'utente del nostro PC (che lancia la connessione SSH) e quello del logserver per il quale è stato definito il file authorized_key coincidano.

A presto.

PS: Grazie a Max per i prezioni suggerimenti.

Uno dei primi argomenti che vengono trattati nell'ambito del corso CCNA riguarda l'uso del comando service password-encryption per cifrare le password impostate durante la configurazione dei dispositivi di casa Cisco (altrimenti esse verrebbero salvate come plaintext, ovvero "in chiaro").

Peccato però che tale comando sia completamente inutile, in quanto l'algoritmo utilizzato per cifrare le password si è rivelato del tutto inadeguato per garantire un livello di sicurezza sufficiente. Basta quindi procurarsi un file di configurazione in cui sono presenti le password cifrate in modalità 7,  ovvero mediante un algoritmo proprietario Cisco che nasce inizialmente come sistema di cifratura one-way per poi rivelarsi (nel 2008) totalmente reversibile, per conoscere tutte le password settate dall'amministratore.

Mi sono imbattuto in tale problematica recentemente, studiando in modo piuttosto approfondito la configurazione di alcuni switch. Nella fattispecie, volevo verificare che le password definite fossero corrette.

Potete avere conferma di quanto detto semplicemente copiando una password cifrata in modalità 7 per poi incollarla nell'apposito campo di input presente su questo sito.

Ma come fare per ovviare a tale problema?

Per prima cosa conviene utilizzare enable secret anzichè enable password per definire la password relativa all'EXEC mode del nostro dispositivo. Inoltre, se la nostra configurazione viene postata su forum vari, soprattutto per testarne la qualità e verificare l'eventuale presenza di errori, è necessario rimuovere completamente la password cifrata in modalità 7.

Ma perchè enable secret consente di ottenere un livello di protezione superiore? Semplicemente perchè tale comando genera un digest MD5 della nostra password, molto più "solido" dell'algoritmo di cifratura Cisco, anche se non completamente sicuro (ma tale regola vale per tutti gli algoritmi di cifratura one-way).

Ci aggiorniamo. Bye.

Potrebbe capitare di dover effettuare un upgrade/downgrade della IOS presente sul nostro switch. Dopo aver seguito la solita procedura, lanciando 3 comandi in croce, come erase flash, copy tftp flash:image e reloadci accorgiamo che al reboot del Catalyst viene visualizzato un errore del tipo:

Loading "flash:c3750-ipbase-mz.122-25.SEC2/c3750-ipbase-mz.122-25.SEC2.bin"...flash:c3750-ipbase-mz.122-

25.SEC2/c3750-ipbase-mz.122-25.SEC2.bin: no such file or directory

Error loading "flash:c3750-ipbase-mz.122-25.SEC2/c3750-ipbase-mz.122-25.SEC2.bin"

Ciò si verifica poichè il boot loader si aspetta di trovare l'immagine della IOS nella directory c3750-ipbase-mz.122-25.SEC2. Inoltre, il file che il boot loader cerca è c3750-ipbase-mz.122-25.SEC2.bin, ovvero il filename della vecchia IOS.

Possiamo dunque impostare il nuovo pathname della IOS appena caricata semplicemente digitando il comando:

Router(config)# boot system flash:<nome_IOS.bin>

Salviamo la configurazione:

Router(config)# copy run start

Riavviamo:

Router(config)# reload

e finalmente il boot loader cercherà all'avvio il file della IOS corretto.

A presto.

Lo switch Cisco Catalyst 6500 è a mio avviso uno dei migliori core switch in circolazione. Esso è dotato di moduli di supervisione, altrimenti detti "schede supervisor", il cui compito, come si può facilmente intuire, è quello di gestire le operazioni di tale dispositivo (sia a livello 2 che a livello 3).

Ora, poichè questo switch è modulare, quando si interviene su una rete che non si conosce a priori, potrebbe tornare utile identificare il tipo ed il numero di moduli installati sul dispositivo in questione.

Per fare ciò si può utilizzare un semplice comando, ovvero show module all:

SW-6500# show module all

L'output sarà simile al seguente:

   Mod Ports Card Type                              Model              Serial No.

   --- ----- -------------------------------------- ------------------ -----------   

     2    2  Catalyst 6000 supervisor 2 (Active)    WS-X6K-SUP2-2GE    SAD04450LF1   

     3   48  48 port 10/100 mb RJ-45 ethernet       WS-X6248-RJ-45     SAD03181468   

     5    0  Switching Fabric Module (Active)       WS-C6500-SFM       SAD04420JR5   
       

   Mod MAC addresses                       Hw    Fw           Sw           Status   

   --- ---------------------------------- ------ ------------ ------------ -------   

     2  0001.6461.39c0 to 0001.6461.39c1   1.1   6.1(3)       6.2(0.97)    Ok   

     3  00d0.bb0f.9808 to 00d0.bb0f.9837   1.0   4.2(0.24)    6.2(0.97)    Ok   

     5  0001.0002.0003 to 0001.0002.0003   1.0   6.1(3)       6.2(0.97)    Ok   
       

   Mod Sub-Module                  Model           Serial           Hw     Status   

   --- --------------------------- --------------- --------------- ------- -------   

     2 Policy Feature Card 2       WS-F6K-PFC2     SAD04440HVU      1.0    Ok   

     2 Cat6k MSFC 2 daughterboard  WS-F6K-MSFC2    SAD04430J9K      1.1    Ok   
       

   Mod Online Diag Status   

   --- -------------------   

     2 Pass   

     3 Pass   

     5 Pass   

Per visualizzare, invece, informazioni relative ad uno specifico modulo basta digitare:
 
SW-6500# show module <numero modulo>
 
A presto. 

Ho pensato di creare una nuova sezione del blog, intotalata "learning log", in cui posterò delle "pillole" di conoscenza, ovvero dei semplici trucchetti imparati durante le mie "scorribande" sistemistiche (e non).

Colgo l'occasione per ringraziarvi sentitamente... se questo blog ha superato la soglia delle 60000 visite è solo grazie a voi...

Ci aggiorniamo... stay tuned :D

In questo post vedremo come configurare correttamente L'EIGRP.

Per prima cosa occorre inizializzare il protocollo definendo l'AS all'interno del quale deve operare:

Router(config)# router eigrp <AS>

Successivamente è necessario definire le reti che tale protocollo deve pubblicare:

Router(config-router)# network <rete> [wildcard mask]

Nella fattispecie, la wildcard mask è facoltativa e rappresenta la classe della rete appena dichiarata. Ad esempio:

Router(config-router)# network 10.1.1.0 0.0.0.255

indica una rete di classe C, mentre:

Router(config-router)# network 192.168.1.0 0.0.255.255

indica una rete di classe B.

L'uso della wildcard mask consente di fornire al protocollo di routing in questione informazioni più dettagliate sulle reti che deve pubblicare, oltre a tenere sotto controllo gli effetti dell'auto summarization delle rotte.

Per configurare la default route che verrà utilizzata nell'ambito dell'EIGRP basta scivere:

Router(config)# ip default-network <rete> (quest'ultima deve essere presente tra le network dichiarate all'EIGRP)

mentre per rimuoverla occorre usare il comando:

Router(config)# no ip route <rotta>

La default route così definita verrà redistribuita a tutti i router vicini. Ciò non accadrebbe se la default route venisse dichiarata con il comando:

Router(config)# ip route 0.0.0.0 0.0.0.0 <IP del router connesso direttamente>

Occorre notare, però, che nel caso in cui avessi dichiarato una rotta del tipo:

Router(config)# ip route 0.0.0.0 0.0.0.0 <interfaccia>

avrei potuto ottenere la ridistribuzione della stessa, previa dichiarazione della rete 0.0.0.0 all'EIGRP mediante il comando network, ovvero:

Router(config-router)# network 0.0.0.0

Summarization delle rotte

La summarization delle rotte consente di ridurre notevolmente le dimensioni delle tabelle di routing (con conseguente risparmio in termini di banda). In particolare, mediante questa caratteristica (abilitata per default nell'ambito dell'EIGRP), possono essere rappresentate più reti contemporaneamente mediante un unico indirizzo IP che le ingloba.

Per calcolare il numero di reti che possono essere aggregate nell'ambito di un unico indirizzo basta applicare la formula:

n = <numero di bit della subnet mask> - <numero di bit della summary mask>. 2^n mi darà il numero esatto delle reti che possono essere aggregate grazie alla summarization.

Facciamo un esempio. Supponiamo che si voglia aggregare le rotte 192.168.1.0/24, 192.168.2.0/24 e 192.168.3.0/24 mediante l'indirizzo 192.168.0.0/22. Apllico la formula sopra citata per individuare quante sono le subnet che posso rappresentare mediante questo indirizzo:

n = 24 - 22 = 2. Inoltre 2^2 = 4. Posso quindi rappresentare 4 subnet in tutto (le tre citate in precedenza e la 192.168.0.0/24).

Per disabilitare l'auto summarization basta digitare:

Router(config-router)# no auto-summary

mentre per impostare manualmente l'indirizzo di summarization occorre scrivere:

Router(config)# ip summary-address eigrp <AS> <indirizzo di summarization> <subnet mask relativa all'indirizzo di summarization> [distanza amministrativa]

In particolare, l'ultimo parametro ci consente di definire la distanza amministrativa per la rotta aggregata. Nel caso in cui non venisse definita dall'utente, EIGRP assegnerà alla rotta aggregata una distanza amministrativa pari a 5.

NB: affinchè il router che fa uso delle rotte aggregate non vada alla ricerca di rotte più specifiche (creando potenzialmente dei loop), le summarizated route punteranno ad un interfaccia software fittizia, ovvero Null0.

Load balancing

Una funzione molto interessante relativa all'EIGRP è il cosiddetto load balancing, ovvero il bilanciamento del carico. Tale caratteristica permette di instradare il traffico lungo più cammini aventi la stessa metrica (costo). Per default il bilanciamento del carico viene effettuato utilizzando un massimo di 4 cammini. Posso comunque definire manualmente il numero di cammini da utilizzare (fino ad un massimo di 16) attraverso il comando:

Router(config-router)# maximum-paths <numero di cammini>

NB: ponendo il parametro <numero di cammini> pari a 1 disabilito il load balancing. Inoltre, il load balancing viene applicato solo al traffico che passa attraverso il router e non a quello che viene generato dal router stesso.

E' bene notare che il load balancing può essere applicato anche su cammini che non hanno la stessa metrica. In questo caso parliamo di unequal-cost load balancing. Posso implementarlo attraverso il comando:

Router(config-router)# variance <valore>

dove <valore> è un intero compreso tra 1 e 128 (1 indica l'equal-cost load balancing).

Per capire lungo quali rotte verrà bilanciato il traffico basta operare come segue:

1) considero la rotta avente metrica più bassa (ovvero la FD della successor route);

2) moltiplico la metrica (FD) per <valore>;

3) Una volta calcolato il prodotto, userò tutte le rotte aventi FD <= al prodotto stesso. Ad esempio:

RouterA FD 1100

RouterB FD 1100

RouterC FD 2000

RouterD FD 3000

Supponendo che il valore della varianza sia 2, otterrò:

1100 x 2 = 2200

Per il bilanciamento userò quindi le rotte che coinvolgono il router A, il router B ed il router C, ma non il router D. Tali rotte verrano salvate nell'ambito della tabella di routing.

Per controllare il bilanciamento del carico su rotte aventi metrica (FD) differente, occorre digitare:

Router(config-router)# traffic-share [balanced | min across-interfaces]

Con la keyword balanced distribuisco il carico proporzionalmente alla metrica (FD) dei cammini. Invece, mediante la keyword min across-interfaces effetto il bilanciamento solo lungo i cammini aventi metrica (FD) più bassa.

EIGRP e WAN

L'EIGRP lavora efficientemente nell'ambito delle WAN, sia per ciò che concerne i collegamenti point-to-point che per quanto riguarda le reti NBMA (point-to-point e multipoint).

Per default, l'EIGRP usa il 50% della banda dichiarata (mediante il comando bandwidth) su un'interfaccia fisica o su una sottointerfaccia virtuale, ma tale valore può essere modificato digitando:

Router(config-if)# ip bandwidth-percent eigrp 1 <percentuale>

dove <percentuale> può essere superiore al 100%, soprattutto se la banda dichiarata è inferiore all'effettiva capacità del canale.

Inoltre, per le reti Frame Relay, nel caso in cui la banda non venisse impostata in modo esplicito mediante l'apposito comando, essa verrà considerata uguale a quella tipica delle reti T1 (1544 Kbps).

Per quanto riguarda le topologie multipoint, la banda dichiarata deve essere suddivisa per il numero di vicini affinchè si possa calcolare la banda presente su ogni collegamento. Nel caso in cui vengano utilizzati link con capacità differente (CIR diversi tra loro), la banda da settare dovrà essere calcolata moltiplicando il CIR più basso per il numero di circuiti virtuali (VC).

NB: il CIR (Committed Information Rate) è un parametro usato nelle reti Frame Relay, il quale indica la banda minima garantita dal provider.

Autenticazione EIGRP

L'autenticazione EIGRP è disabilitata per default. Esistono, inoltre, due tipi di autenticazione:

- Simple password authentication (detta anche plain text authentication);

- MD5 authentication.

L'MD5 calcola il digest della password (key) concatenata al suo ID, ovvero H(key || key ID). Mediante l'autenticazione sarà possibile riconoscere la sorgente dei messaggi ed il digest verrà inserito all'interno di tutti i pacchetti inviati nell'ambito del protocollo di routing in questione.

E' possibile definire la durata (lifetime) relativa all'uso della password. Ciò conviene quando sono definite delle key-chains, le quali prevedono l'uso a rotazione delle password stesse. A tal proposito è necessario fare attenzione che non vi siano dei lassi di tempo in cui nessuna password risulta attiva (in questo caso i routing update falliranno sistematicamente). Inoltre, le password verranno utilizzate a partire da quella recante key ID più basso (a parità di lifetime).

NB: i router devono essere sincronizzati (mediante NTP - Network Time Protocol) affinchè usino la stessa password della key-chain per lo stesso lasso di tempo.

Per configurare l'autenticazione MD5 occorre digitare:

Router(config-if)# ip authentication mode eigrp <AS> md5

Creo dunque la key-chain:

Router(config-if)# ip authentication key-chain eigrp <as> <nome della chain>

Entro nella modalità di configurazione della chain:

Router(config)# key chain <nome della chain>

Router(config-key-chain)# key <key ID>

Setto la password vera a propria:

Router(config-key-chain)# key key-string <password> (il primo carattere della password non deve essere un numero).

Posso definire opzionalmente il lasso di tempo durante il quale tale password viene accettata per gli update in ingresso:

Router(config-key-chain)# accept-lifetime <inizio> {infinite | <fine> | duration <secondi>}

Il formato di <inizio> e <fine> è il seguente:

hh:mm:ss giorno (1-31) mese (prime 3 lettere del mese in inglese) anno (4 cifre)

Per l'invio dei pacchetti contenenti il digest occorre digitare:

Router(config-key-chain)# send-lifetime <inizio> {infinite | <fine> | duration <secondi>}

NB: la key-string (password) viene salvata in chiaro se non viene digitato il comando service password-encryption.

Inoltre, se sia la key1 che la key2 per l'accept-lifetime hanno durata infinita, il router accetterà sempre sia i pacchetti contenenti il digest della key1 che quelli contenenti il digest della key2.

Viceversa, se il send-lifetime di una key è infinito (e tale chiave possiede l'ID più basso), verrà usata solo quella key durante l'invio dei pacchetti EIGRP.

Toubleshooting dell'autenticazione MD5

Il comando da utilizzare è il seguente:

Router# debug eigrp packets

l'output mostrerà il key ID e nel caso in cui le chiavi settate sui due router non coincidono, verrà visualizzata la dicitura "authentication mismatch". In tal caso l'adiacenza verrà formata solo per un lasso di tempo molto breve. ("retry limit exceeded" e " new-adjacency" come output).

Query EIGRP e stuck-in-active (SIA)

Se un router si accorge che la sua successor è down e che non esiste FSR, esso unvierà una query ai router vicini per individuare un percorso alternativo verso quella specifica destinazione. Se i router vicini non conoscono la risposta, propagheranno la query ai loro adiacenti e così via. Durante questo lasso di tempo la rotta rimarrà nello stato ACTIVE e non tornerà allo stato PASSIVE finchè alla query non seguirà una risposta (reply). Se tale risposta non viene ricevuta entro 3 minuti dall'invio della query, la rotta entra nello stato stuck-in-active (SIA).

NB: si può modificare il tempo limite oltre il quale viene dichiarato lo stuck-in-active della rotta digitando:

Router(config-router)# timers active-time <limite in minuti> oppure disabled

Appena il router identificherà lo stuck-in-active resetterà tutte le adiacenze con i vicini che non hanno risposto alla query.

Contromisure allo stuck-in-active

Esistono diverse contromisure allo stuck-in-active. Una di queste prende il nome di Active Process Enhancement. Per capire il funzionamento di tale meccanismo facciamo un esempio: il router A invia al router B una query che a sua volta verrà instradata verso il router C. Poichè vi è un problema relativo al collegamento tra il router B ed il router C, quest'ultimo non risponderà alla query, e di conseguenza B tarderà nell'invio della risposta ad A. Il router A crederà quindi che è il router B a presentare dei problemi e quindi rimuoverà l'adiacenza con lo stesso. Proprio per evitare una situazione del genere, a partire dalla IOS 12.1(5), è stato introdotto l'Active Process Enhancement. Grazie a tale meccanismo, il router B prima di inoltrare la query a C risponderà ad A attraverso un pacchetto SIA-reply, proprio per indicare il suo corretto funzionamento.

Un'altra contromisura allo stuck-in-active è rappresentata dal query range, detto anche query scoping. Esso limita la propagazione della query nell'ambito della rete, attraverso una route summarization oppure mediante l'uso di uno stub. Ad esempio, nel primo caso il router A invierà al router B una query richiedendo la rotta verso una specifica rete. Il router B, però, conosce la summarization di alcune rotte in cui è presente la rete cercata da A, ma non possiede nella propria tabella di routing l'indirizzo vero e proprio di quel network. Perciò, B risponderà ad A affermando che non conosce la rotta verso la rete che gli è stata richiesta.

Pe quanto riguarda lo stub, esso rappresenta un router che non può nè ricevere nè inviare le query EIGRP. Inoltre, a seconda dei casi, esso non può inviare alcuna rotta ai vicini, oppure può inoltrare solo le rotte direttamente connesse, le rotte statiche o le rotte aggregate. Per configurarlo occorre digitare:

Router(config-router)# eigrp stub [receive only | connected | static | summary]

Se invece viene specificato il comando:

Router(config-router)# eigrp stub

senza alcun parametro opzionale, lo stub inoltrerà solo le rotte direttamente connesse (previa loro esplicita dichiarazione mediante il comando network) e le summary route. Un altro modo per redistribuire le rotte direttamente connesse è quello di digitare il comando:

Router(config-router)# redistribuite connected

In questo modo, però, le rotte redistribuite verranno marcate come esterne dai router vicini che le hanno ricevute (flag EX) e quindi la loro distanza amministrativa non sarà 90 bensì 170.

Infine, è bene notare che uno stub deve essere necessariamente un router remoto ed in particolare, nelle topologie hub-n-spoke, uno stub è necessariamente uno spoke (per questo motivo può avere come vicini solo uno o più hub).

Graceful shutdown

Mediante il graceful shutdown un messaggio di disconnessione viene inviato dal router su cui non è più attivo il processo EIGRP. In questo modo si evita che l'adiacenza con i router vicini venga rimossa solo allo scadere dell'hold-timer, con conseguente spreco di banda.

Alcuni comandi utili

Di seguito riporto alcuni comandi utili per verificare il corretto funzionamento dell'EIGRP:

Router# sh eigrp neighbors

Router# sh ip route

Router# sh ip route eigrp

Router# sh ip protocols

Quest'ultimo mostra alcune informazioni riguardanti l'EIGRP quali il numero di AS, le summarization, l'hold-timer, il valore di K, la varianza, la distanza amministrativa, l'hop count e le filter list per il traffico in ingresso ed in uscita.

Abbiamo inoltre i seguenti comandi:

Router# sh ip eigrp int

che mostra le interfacce utilizzate dall'EIGRP

Router# sh ip eigrp topology

Router# sh ip eigrp topolgy all-links

Router# sh ip eigrp traffic

quest'ultimo mostra il numero di pacchetti EIGRP inviati e ricevuti. Inoltre, permette di visualizzare le statistiche relative a tutte e 5 le tipologie di pacchetti usati nell'ambito del protocollo in questione.

Router# debug ip eigrp

il cui output contiene informazioni sul calcolo della metrica

Router# debug ip eigrp summary

il quale mostra informazioni meno dispersive rispetto al comando debug ip eigrp

Router# debug eigrp neighbors

che permette di visualizzare il processo di individuazione dei vicini ed il contenuto dei pacchetti hello.

Router# debug ip eigrp packets

dove la dicitura nbr indica il vicino (neighbor), rely 1/0 indica che il pacchetto rappresenta la risposta ad un altro pacchetto che prevedeva la ricezione di un ACK (ad esempio un update), serno numero intero - numero intero indica il numero di cambiamenti che i due vicini hanno subito nell'ambito della loro tabella di routing, Seq 5/4 indica che il il vicino ha trasmesso un pacchetto con numero di sequenza pari a 5 e a tale pacchetto il router locale ha assegnato numero di sequenza pari a 4. La risposta al vicino dovrà contenere numero di sequenza pari a 5 (altrimenti il pacchetto verrà scartato). Inoltre, gli ACK avranno il primo valore del numero di sequenza uguale a 0 (ad esempio Seq 0/5), a testimonianza del fatto che essi non prevedono l'invio di un ulteriore ACK come conferma di avvenuta ricezione.