Internetworking V anno

La gestione della rete e dei sistemi

Introduzione Una rete è costituita da molte parti complesse, pezzi hardware e software che interagiscono: collegamenti, switch, router, host e altri apparati fisici ai molti protocolli che controllano e coordinano l’attività di questi dispositivi. Quando si mettono insieme centinaia di queste componenti per formare una rete, non c’è da sorprendersi se si presentano problemi di: • funzionamento; • configurazione; • degradi prestazionali; • danneggiamenti o rotture. L’amministratore ha il compito di mantenere in funzione la rete, gestire e prevenire i problemi e disporre degli strumenti adatti per risolvere ogni criticità. 3

Network management Con Network management si individua un insieme di attività richieste quando si deve gestire una rete di comunicazione: • pianificazione di rete (network planning); • allocazione delle risorse (allocating); • trattamento privilegiato delle applicazioni (QoS); • realizzazione (deploying); • coordinamento (coordinating); • gestione della banda (bandwidth management); • monitoraggio delle risorse di rete (monitoring); • aggiornamento del firmware o del software (upgrading); • distribuzione delle chiavi di crittografia (cryptographic key distribution). L’obiettivo delle tecniche di networking management varia a seconda della dimensione della rete o della sua importanza. 4

Documentazione di rete Prima di intervenire sulla rete o fare previsioni sul suo stato è importante che l’amministratore conosca bene la sua struttura fisica e logica e le normali prestazioni. Da qui nasce l’importanza della documentazione di rete. Un’adeguata gestione della rete richiede che un amministratore conosca e mantenga una serie di informazioni su di essa, quali: topologia fisica metodo d’accesso al mezzo trasmissivo protocolli dispositivi sistemi operativi applicazioni configurazioni Recuperare tali informazioni e organizzarle/fornirle attraverso database non è operazione semplice e veloce ma si rivela di fondamentale importanza per risparmiare tempo e lavoro in futuro. 5

Strumenti per la gestione della rete Al fine di agevolare lo svolgimento delle numerose e complesse attività legate al network management, negli anni sono stati sviluppati degli strumenti (network management tools) che permettono di eseguire funzioni di gestione quali: • il monitoring dei livelli di traffico nella rete; • l’individuazione di punti di congestione (bottleneck); • il controllo sull’utilizzo del software. Questi strumenti permettono di avere una supervisione di tutta la rete, dai router ai desktop. Solitamente forniscono una rappresentazione grafica della rete, con varie icone e l’uso di colori per indicare lo stato del device. Si tratta di applicazioni software altamente configurabili, in modo da adattarsi bene a qualunque ambiente di rete. Per contro sono solitamente molto costosi e richiedono una procedura di personalizzazione (customizing) non semplice. 6

Gruppi dei tools Gli strumenti per la gestione di reti e sistemi sono moltissimi e possono essere grossolanamente suddivisi in due gruppi: 1. Strumenti sviluppati dai produttori di apparati di rete e quindi specifici per la gestione di tali device; Anche detti “element manager”, ne sono esempi: • Cisco CiscoWorks; • Cisco Prime Infrastructure; • Avaya Unified Communication Management. 2. Strumenti sviluppati allo scopo di gestire reti formate da apparati eterogenei. Appartengono al questo secondo gruppo i seguenti prodotti: • HP Intelligent Management Center; • IBM Tivoli NetView; • CA Infrastructure Management; • BMC ProactiveNet Performance Management. 7

Traffic shaping Con il termine traffic shaping si identifica una tecnica di gestione delle prestazioni di rete che si applica a reti che gestiscono volumi elevati di traffico. Il traffic shaping consiste nel manipolare certe caratteristiche dei pacchetti al fine di gestire la quantità di traffico che attraversa la rete. Traffic shaping è utile quando si vuole gestire la QoS in rete, garantendo la consegna puntuale del traffico più importante e, nel contempo, offrendo le migliori prestazioni possibili ai restanti utenti (best effort). Le tecniche implementate possono infatti riguardare il rallentamento del traffico meno critico, l’aumento della priorità del traffico più importante, la limitazione della quantità di traffico che attraversa un’interfaccia in uno specifico intervallo di tempo. 8

Reti TCP/IP, livello Application Una rete, oltre ai protocolli che forniscono i servizi di rete e ai programmi applicativi che li usano, ha necessità di un software che permetta al gestore di individuare e risolvere i problemi, di controllare l’instradamento e identificare i computer che violano gli standard dei protocolli. Il protocollo per la gestione di una internetwork TCP/IP è definito a livello Application (e Transport). In una internetwork TCP/IP, un gestore deve poter controllare i router e gli altri dispositivi di rete. Tali apparati sono, però, collegati a reti differenti, quindi i protocolli per la gestione di rete vengono definiti a livello Application e comunicano usando i protocolli del livello Transport, così da essere svincolati dal tipo di rete fisica usata e dai protocolli di routing utilizzati. 9

Vantaggi livello Application La decisione di progettare software di gestione a livello Application presenta non pochi vantaggi: • protocolli definiti senza tenere conto dell’hardware sottostante, quindi si può usare lo stesso insieme di protocolli per tutti i tipi di rete; • uniformità di gestione che consente all’amministratore di lavorare sui router della rete con lo stesso insieme di comandi; • l’amministratore può controllare i dispositivi senza avere un collegamento diretto a ognuno di essi, poiché il software di gestione usa IP per la comunicazione. 10

Svantaggi livello Application Porre il software di gestione a livello Application comporta degli svantaggi: • se qualcosa nel software applicativo o di trasporto non funziona correttamente sarà impossibile all’amministratore contattare un router su cui si deve intervenire; • in caso di malfunzionamento sul sistema operativo di un router, non si potrà raggiungere il programma applicativo che implementa i protocolli per la gestione della inter-network, anche se il router può ancora rilevare gli interrupt hardware e instradare i pacchetti. 11

Modello architetturale Il modello architetturale utilizzato nelle reti TCP/IP è del tipo Client/Server. Il software del client solitamente si trova sulla stazione del gestore della rete, mentre ogni host gestito esegue un programma server. Il software del server è detto Management Agent (MA), o agent. Il software del gestore è detto Management Client (MC), o manager. 12

Software di gestione reti TCP/IP Il software di gestione della inter-network usa un meccanismo di autenticazione per garantire l’accesso o il controllo del dispositivo solo ai gestori autorizzati. Esistono vari livelli di privilegi. La gestione di reti TCP/IP prevede la specifica di due parti: 1. la modalità di comunicazione delle informazioni: questa parte definisce in che modo il manager (il software client) comunica con l’agent (il software server) dettagliando il tipo di messaggi scambiati, il formato dei nomi e degli indirizzi; 2. i dati: questa parte è relativa alle informazioni che devono essere memorizzate su un dispositivo, utili alla sua gestione; sono quindi specificati il nome di ciascun dato e la sintassi usata per definirlo. 13

Gli standard SNMP e MIB Lo standard per la gestione delle reti TCP/IP è il Simple Network Management Protocol (SNMP). L’ultima versione (SNMPv3) è standard IETF. SNMP definisce un protocollo molto semplice per controllare da remoto i dispositivi di una rete IP e, dalla versione 3, garantisce un livello di sicurezza che era mancato alle versioni precedenti. Il punto di forza di SNMP risiede nel database MIB (Management Information Base), utilizzato dai managed device (MA) per memorizzare le statistiche e i dati raccolti dalla stazione manager (MC). Il protocollo SNMP viene utilizzato per accedere a informazioni memorizzate tipicamente su: router: come stato delle interfacce di rete, traffico pacchetti, messaggi di errore; modem: statistiche sui numero caratteri inviati e ricevuti, sulle chiamate accettate o rifiutate ecc. 14

MIB La MIB si occupa di specificare “quali dati” devono essere resi disponibili. La MIB di TCP/IP divide le informazioni di gestione in molte categorie il cui nome è l’identificatore usato per specificare la tipologia dei dati raccolti. La seguente tabella riporta alcune categorie specificate nella MIB TCP/IP: 15

MIB e protocollo per la gestione di rete La definizione della MIB è indipendente dal protocollo per la gestione della rete. Mantenere la definizione di MIB indipendente dal protocollo per la gestione di rete presenta alcuni vantaggi sia per i produttori di apparati sia per i gestori di rete: • un produttore può includere il software dell’SNMP Agent nei dispositivi che produce sapendo che continuerà a rispettare lo standard anche dopo che sono stati definiti nuovi elementi nella MIB per la gestione di nuove caratteristiche o funzionalità; • un gestore può utilizzare lo stesso software client di gestione di rete per gestire più dispositivi che usano versioni diverse di MIB. N.B.: Chiaramente un apparato che NON conosce i nuovi elementi di MIB non potrà fornire informazioni su di essi, però, dal momento che tutti i dispositivi gestiti usano lo stesso linguaggio per la comunicazione, potrà analizzare la richiesta e fornire un messaggio di errore spiegando di non conoscere l’oggetto desiderato. Questa segnalazione sarà quindi gestita dall’amministratore di rete che interverrà nell’aggiornare il software. 16

Structure of Management Information Oltre agli standard che specificano le variabili delle MIB e il loro significato, ne esiste uno che definisce un insieme di regole da utilizzare per chiunque voglia specificare una MIB, si tratta dello standard Structure of Management Information (SMI). Lo scopo di SMI è quello di semplificare i protocolli per la gestione di rete. Per fare ciò vengono posti dei vincoli sui tipi di variabili consentiti in una MIB, stabilendo regole per la denominazione e per la definizione di nuovi tipi. Le regole SMI descrivono anche il modo in cui la MIB si riferisce a tabelle di valori. Le variabili MIB devono essere definite secondo un linguaggio formale specificato da ISO: l’Abstract Syntax Notation 1 (ANS.1) che rende forma e contenuti delle variabili NON ambigui. 17

La struttura della MIB È possibile pubblicare vari documenti MIB diversi, uno per ciascuna tipologia di dispositivo. Così, molti produttori hanno definito le variabili MIB specifiche per i loro prodotti hardware e software. Vari documenti IETF riportano informazioni sulle MIB; RFC 4181 è da considerarsi un documento di riferimento contenente le linee guida per scrivere una MIB. 18

Le variabili della MIB Le maggior parte delle variabili MIB associate ai protocolli TCP/IP assume un valore numerico che può essere memorizzato in un SINGOLO INTERO. Nella MIB, però, possono essere presenti anche strutture più complesse, per esempio; la ipRoutingTable si riferisce a un’intera tabella d’instradamento. È importante sottolineare che le variabili MIB offrono SOLO la definizione logica di ciascun dato, le strutture interne di dati che un apparto usa possono differire dalla definizione della MIB. Quando riceve dal gestore un’interrogazione, l’agent del managed device si occupa della corrispondenza tra la variabile MIB e la struttura di dati interna che utilizza per memorizzare quell’informazione. 19

Alcune variabili della MIB La seguente tabella riporta alcune variabili di MIB associate ai protocolli TCP/IP: 20

Il namespace Come detto, i nomi e i dati nella MIB sono rappresentati nel linguaggio ANS.1. I nomi, però, sono presi dallo spazio di denominazione degli identificatori di oggetti (object identifier namespace) gestito da ISO e ITU. Questo namespace è: assoluto perché i nomi sono strutturati in modo da essere univoci gerarchico perché l’autorità è suddivisa a ogni livello e singoli gruppi possono ottenerla per assegnare dei nomi senza dover consultare un’autorità centrale. 21

Struttura namespace Il nome di una variabile consiste nelle etichette numeriche incontrate lungo il percorso dalla radice alla variabile. Nella figura si mostra la parte del namespace usata per assegnare un nome alla variabili MIB. La radice della gerarchia (root) è senza nome e ha tre discendenti diretti, gestiti rispettivamente da: ISO, ITU e ISO-ITU. I numeri servono al software di gestione, il testo agli utenti. 22

Porte utilizzate da SNMP Gli SNMP Agent sono installati su device della rete e i dati utili alla gestione sono memorizzati nelle MIB. Infatti, una stazione SNMP Manager contatta l’SNMP Agent per ottenere informazioni dalla MIB che gestisce. SNMP si basa su UDP come protocollo di trasporto e utilizza le porte: • 161: per inviare/ricevere i messaggi SNMP; • 162: per inviare/ricevere le trap, cioè messaggi inviati in modo spontaneo dall’agent al manager. 23

Modello di comunicazione manager-agent La figura mostra il modello di comunicazione usato tra manager e agent. La scelta di UDP come protocollo di trasporto è dovuta alla sua natura connectionless che rende più veloce la comunicazione tra manager e agent. UDP non è un protocollo affidabile, perciò la verifica sulla perdita di datagram è affidata all’applicazione SNMP. Quando il manager invia una richiesta all’agent imposta un timer per l’attesa della risposta, allo scadere del timer la richiesta è ritrasmessa. 24

SNMPv1 e SNMPv2 community SNMPv1 e SNMPv2 usano la nozione di community per stabilire una connessione fidata (trust) tra manager e agent, infatti la community è usata in modo simile a una normale password di accesso. Un agent è configurato con tre community name: Read-only: permette al manager di sapere il numero di pacchetti trasferito attraverso le interfacce di un router Read-write: permette di azzerare il contatore del community name Read-only Trap: permette al manager di ricevere trap dall’agent. SNMPv1 e SNMPv2 usano la nozione di community per stabilire una connessione fidata (trust) tra manager e agent, infatti la community è usata in modo simile a una normale password di accesso. Un agent è configurato con tre community name: Read-only: permette al manager di sapere il numero di pacchetti trasferito attraverso le interfacce di un router Read-write: permette di azzerare il contatore del community name Read-only Trap: permette al manager di ricevere trap dall’agent. 25

SNMPv3 community La maggior parte dei produttori configura delle community string (una sorta di password) di default che sono inviate in chiaro e solitamente note: pubblic per read-only private per read-write Questo comporta problemi di sicurezza, risolti, come accennato in precedenza, dall’introduzione di SNMPv3 che introduce meccanismi di crittografia e autenticazione nelle comunicazioni tra manager e agent. 26

SNMP, VPN e il consiglio di sempre… Un modo per proteggere la community string è usare una VPN e criptare tutto il traffico di tutta la rete. Un altro modo valido per qualunque stringa usata come password è cambiare frequentemente la community string (usando uno script in caso di rete estesa). 27

Il paradigma fetch-store SNMP non definisce un insieme di comandi da utilizzare per svolgere le sue funzioni ma esegue tutte le sue operazioni secondo il paradigma fetch-store (estrai-memorizza). SNMP prevede di utilizzare solo due comandi che consentono al gestore di leggere il valore di un dato (fetch) o memorizzare un valore in un dato (store). 28

Vantaggi paradigma fetch-store I vantaggi principali del fetch-store paradigm sono: solidità: la definizione di SNMP è stabile semplicità: SNMP è facile da implementare, capire e verificare flessibilità: SNMP può gestire qualsiasi comando in una struttura predefinita Dal punto di vista del gestore SNMP resta nascosto. 29

Altri comandi del fetch-store Nelle specifiche del protocollo SNMP la modalità fetch-store si traduce, in realtà, in più di due comandi. La seguente tabella ne riporta nome e descrizione: 30

Le caratteristiche di SNMPv3 Come detto, SNMPv3 rappresenta un’evoluzione soprattutto per quanto riguarda la sicurezza e l’amministrazione, non sono state apportate modifiche né al protocollo né alle operazioni che possono essere effettuate. È stata però modificata la nomenclatura, abbandonando i termini manager e agent in favore di un unico nome: SNMP entity che può assumere un ruolo di manager o di agent a seconda delle funzioni che svolge. Ogni entità contiene un SNMP engine e una o più applicazioni. 31

SNMP entity manager 32

SNMP entity agent 33

SNMPv3 e sicurezza La nuova architettura definita in SNMPv3 aiuta a separare in modo chiaro le diverse parti del sistema SNMP così da rendere possibile una sua implementazione sicura. Dal punto di vista della sicurezza, SNMPv3 supporta: Autenticazione dei messaggi Crittografia Integrità del messaggio Controllo degli accessi 34

Modularità SNMPv3 I modelli definiti in SNMPv3 per la sicurezza sono: - USM (User-based Security Model): è usato per autenticare una SNMP entity e fornisce servizi di crittografia (encryption) per rendere sicure le comunicazioni tra manager e agent; VACM (View-based Access Control Model): è usato per configurare i diritti di accesso a un gruppo di entity (manager) tramite la definizione di viste che permettono di filtrare l’accesso agli oggetti delle MIB. Lo standard SNMPv3 definisce un modello per ciascuno dei due sistemi di sicurezza, lasciando però la possibilità di implementarne altri, infatti, grazie alla modularità con cui è stata definita la nuova architettura, l’inserimento di nuovi modelli è piuttosto agevole. 35

SNMPv3 configurazione in remoto Per rendere il sistema di sicurezza semplice da configurare e da modificare, SNMPv3 consente la configurazione da remoto, il che significa che un amministratore autorizzato può effettuare modifiche sugli elementi di sicurezza elencati sopra senza essere fisicamente presente dove si trova il dispositivo. 36