Archive for the ‘Networking’ Category

Configurare un proxy SOCKS over SSH con putty e firefox per aggirare il proxy aziendale

In questa guida vedremo come configurare una connessione ssh in modo da ottenere un proxy SOCKS. Essa può essere utile per by-passare il proxy aziendale e navigare anche su siti normalmente bloccati e, quindi, inaccessibili.

Requisiti di fattibilità sono:

  1. avere un pc linux a casa con un server ssh in ascolto sulla porta 22
  2. avere la porta 22 dalla intranet non bloccata verso internet
  3. conoscere l’ip del server (anche tramite dns dinamico come dyndns) e impostare il ruoter con port forwarding sulla porta 22 verso il pc linux
  4. avere un pc client con installato il client putty e il browser firefox

Iniziamo con il configurare correttamente il client ssh putty, per fare ciò dobbiamo conoscere l’ip pubblico del pc linux su cui è installato il server ssh, lasciamo impostata la porta 22, connection type selezionato su ssh e diamo un nome alla connessione (tipo “TUNNEL”); dopodiché facciamo Save.


Successivamente, dal menu a sinistra, selezioniamo connection. Nel campo “Seconds between keepalives” impostiamo 1 e flagghiamo le 2 opzioni sotto, principalmente “Enable TCP keepalives“.

putty connection

 

Da connection spostiamoci nel sottomenu connection->proxy e inseriamo i dati del proxy a cui siamo collegati per andare su internet specificando il tipo di proxy, l’ip o il nome del proxy, la porta su cui è in ascolto e le credenziali, se ci sono.

putty proxy

 

Nel menu connection->SSH->Tunnels valorizziamo il campo “Source port” con una porta a nostra scelta ma superiore alla 1024 (ad es. la 5000), sulle opzioni sotto scegliamo “Dynamic” e “Auto” e clicchiamo su “Add“: comparirà nel box l’indicazione Dxxxx dove xxxx è la porta scelta.

putty tunnel

Infine, torniamo nel menu session e facciamo salva per memorizzare i parametri. Tutti i parametri per la connessione e il relativo tunnel sono impostati, quindi facciamo click su “Open” per far partire la connessione e inseriamo nome utente e password. Se non ci sono stati intoppi la connessione con il server è instaurata e il tunnel ssh è già in funzione.

Il passo successivo è la configurazione di firefox per utilizzare il tunnel come un proxy SOCKS. Dal browser andiamo sul menu strumenti->opzioni->avanzate->rete, troveremo la voce “Determina come firefox si collega a internet” e clicchiamo su impostazioni. Si aprirà una nuova finestra dove dovremo impostare “Configurazione manuale dei proxy” e valorizziamo solamente la voce Host SOCKS con il valore 127.0.0.1, come porta quella impostata nel tunnel (nell’esempio è la 5000) e selezioniamo SOCKSv5.

impostazione proxy firefox

Facciamo ok. Se la configurazione è terminata correttamente, una volta instaurata la connessione ssh potremo navigare con firefox utilizzando il nostro pc linux di casa finché non verrà chiusa la connessione.
Ovviamente, la configurazione del proxy può essere cambiata non solo su firefox ma su un qualsiasi browser o programma che consentono di inserire a mano le impostazioni proxy, come ad esempio explorer, skype, antivirus e torrent.

Nel caso in cui il firewall aziendale blocchi la porta 22 basterà modificare la porta di ascolto del servizio ssh (e il relativo port forwarding sul router di casa) sulla porta 80 o sulla porta 443 verso il pc linux dato che tali porte saranno sicuramente aperte.

Funzionamento del protocollo OSPF

L’Open Shortest Path First (in seguito, OSPF) è un protocollo di routing link state pubblico e non proprietario.

I router che utilizzano protocolli link state identificano i propri vicini e comunicano con essi. L’OSPF raccoglie le informazioni dai router vicini circa lo stato dei link di ognuno di essi e invia i suoi dati agli altri. Questo scambio di informazioni sullo stato dei link permette ai router di creare la topology table o (link state database). Ogni router nella stessa area OSPF ha la stessa topology table e viene usata per calcolare la rotta migliore fino a una destinazione applicando l’algoritmo SPF (Shortest Path First). L’algoritmo SPF si basa sul costo che è principalmente basato sulla larghezza di banda; il percorso a costo più basso viene inserito nella routing table (o forwarding database).
Ogni router mantiene una lista di router vicini chiamata adjacency database. Tale lista è formata da tutti i router vicini con cui un router stabilisce una comunicazione bidirezionale ed è unica per ogni router. Per ridurre il numero di informazioni di routing scambiate tra i vicini all’interno della stessa rete, i router OSPF eleggono un designated router (DR) e un backup designated router (BDR) che vengono utilizzati come punti focali per lo scambio di informazioni di routing.

L’OSPF è un protocollo da utilizzare in reti estese e scalabili dove i limiti dei protocolli distance vector rendono improponibile utilizzarli, sia per utilizzo di metriche non basate sulla larghezza di banda che per la lenta convergenza del protocollo (in reti estese il RIP può avere la convergenza di alcuni minuti). Le principali differenze sono state già trattate in altri articoli.

OSPF si interfaccia con le reti broadcast multi-access (come l’Ethernet), pont-to-point e Nonbroadcast multi-access (NBMA, come il Frame Relay). Le reti di tipo point-to-multipoint possono essere configurate manualmente su un’interfaccia dall’amministratore.
In una rete multi-access non si conosce il numero di router a cui si è connessi, mentre nel collegamento point-to-point solo due router possono essere connessi. In una rete broadcast multi-access il numero di adiacenti può essere elevato e varia in base al numero di router della rete. In generale se N è il numero di router il numero di potenziali adiacenti sarà dato dalla formula

N*(N-1)/2

e ciò provocherebbe molto overhead. La soluzione di questa problematica sta nell’eleggere un DR che diventa adiacente di tutti gli altri router nel segmento di broadcast, quindi tutti i router inviano i LSA al DR ed esso invierà le informazioni  a tutti i router del segmento usando l’indirizzo multicast 224.0.0.5. Questa soluzione è efficiente ma presenta lo svantaggio che il DR funge come centro stella, quindi con problemi per la rete in caso di rottura. Per questo viene eletto un BDR tra i designated router. Per garantire la sincronizzazione delle informazioni tra DR e BDR vengono inviate le informazioni all’indirizzo 224.0.0.6.
Ovviamente in una rete point-to-point ci sono solo due nodi e non esistono né DR né BDR: entrambi i router hanno le complete adiacenze con l’altro.

Quando viene avviato un processo di routing OSPF su di un’interfaccia, il router manda pacchetti “hello” a intervalli regolari (Hello protocol) attraverso l’indirizzo 224.0.0.5 che invia il pacchetto a tutti i router OSPF. Tali pacchetti (molto piccoli, hanno solo un OSPF header) vengono inviati ogni 10 secondi di default, ogni 30 per reti NBMA e sono importanti poiché attraverso essi vengono eletti il DR e il BDR.

Funzionamento

Come già accennato, l’avvio di un processo OSPF su di un’interfaccia fa si che il router invii pacchetti hello a intervalli regolari; le regole che governano lo scambio di pacchetti hello viene chiamato hello protocol. In una rete multi-access l’hello protocol fa si di eleggere un DR e un BDR. I pacchetti hello trasportano le informazioni e tutti i vicini devono essere sincronizzati per formare adiacenze e scambio di informazioni sullo stato dei link. In reti multi-access sono il DR e il BDR a dover mantenere le adiacenze con tutti gli altri router OSPF.

I router adiacenti attraversano una sequenza di stati. Prima di formare la routing table i router adiacenti devono essere a conoscenza della topologia dell’intera rete. Ogni router invia LSA nei Link State Update (LSU) e tale LSA contiene al suo interno tutte le informazioni sui link del router; viceversa, ogni router riceve un LSA da ogni vicino per formare il topology database. Tale processo si ripete per ogni router della rete OSPF.

Quando il database è completo ogni router applica l’algoritmo SPF per calcolare una topologia logica esente da loop per ogni rete di destinazione da inserire nella routing table. Le informazioni di routing sono così fissate; quando vi è la variazione dello stato di un link, i routers usano un processo di flooding per notificare agli altri router della rete il cambiamento. Inoltre, per verificare se un adiacente è down, l’hello protocol impone un dead interval.

Link state routing protocol

Abbiamo già visto in un precedente articolo quali sono le principali differenze tra i protocolli di routing distance vector e i protocolli link state. In questo articolo continuiamo la trattazione e vedremo nel dettaglio le caratteristiche dei protocolli link state; prima, però, riprendiamo le differenze tra le due classi di protocolli di routing.

I protocolli distance vector (come RIP e IGRP) presentano le seguenti caratteristiche:

  • inviano l’intera tabella di routing ai router vicini;
  • aggiornamenti periodici frequenti;
  • metrica basata sui salti (solo il RIP);
  • vedono la rete dalla prospettiva dei vicini;
  • convergenza lenta;
  • possibili routing loops;
  • semplicità di configurazione;
  • alto consumo di banda.

Caratteristiche dei protocolli link state:

  • aggiornamenti al variare della topologia della rete;
  • uso dello Shortest Path;
  • invio di pacchetti link-state a tutta la rete (LSA, Link State Advertisement);
  • vista totale della rete in comune tra i router;
  • convergenza veloce;
  • non suscettibili di routing loops;
  • complessi da configurare;
  • richiedono molta memoria e potenza computazionale;
  • consumano poca banda.

Un router che utilizza protocolli link state colleziona le informazioni da tutti gli altri router nella rete e, successivamente, calcola il miglior percorso (SPF algorithm) per tutte le destinazioni della rete stessa. Le variazioni della rete vengono acquisite dai router in maniera veloce: le informazioni vengono inviate in maniera non periodica ma al variare della topologia (triggered updates). Inoltre, vengono inviati dei pacchetti “hello” per verificare la raggiungibilità dei vicini. Informazioni di “hello” e LSAs costituiscono lo strumento per conoscere la topologia della rete per poter creare la tabella di routing (routing table).

Quando vi è una rottura nella rete si ha un fooding di pacchetti LSAs a un indirizzo multicast dedicato; ogni router invia queste informazioni su tutte le porte tranne su quella in cui l’informazione è arrivata. Questo fa si che ogni router appartenente a una certa area debba ricalcolare le rotte, ecco perché il numero di router di un’area deve essere limitato.

Un link è un’interfaccia del router. Lo stato di un link è la descrizione dell’interfaccia e della relazione con i router vicini. La descrizione dell’interfaccia può includere l’indirizzo IP della stessa, la subnet mask, il tipo di rete a cui è connessa, i router connessi ecc. L’insieme di tali informazioni forma il database link state meglio conosciuto come database topologico (topological database). Applicando l’algoritmo di Dijkstra (SPF, Shortest Path First) si forma un albero SPF in cui il router che lo applica è la radice (root). Il percorso migliore calcolato viene inserito nella routing table.

Vediamo di riassumere i vantaggi e gli svantaggi dei protocolli link state. Vantaggi:

  • utilizzo del costo di un link come metrica che tiene conto della capacità del link;
  • utilizzo di LSAs per informare immediatamente gli altri router dei cambiamenti della topologia della rete così da avere un convergenza veloce;
  • vista completa della rete, i routing loops sono facilmente evitabili;
  • routing table sempre aggiornata in base alle ultime informazioni ricevute;
  • supporto a CIDR e VLSM.

Svantaggi dei protocolli link state:

  • richiedono maggiore memoria e potenza di calcolo rispetto ai protocolli distance vector. Questo può determinare un costo eccessivo per un’azienda con poco budget o con hardware datato;
  • richiedono una struttura gerarchica della rete per poterla suddividere in aree più piccole e gestibili riducendo la dimensione della topology table;
  • richiedono una buona conoscenza del protocollo da parte dell’amministratore di rete;
  • effettuano un flooding di LSAs durante il processo di discovery iniziale che può determinare un significativo calo della capacità della rete in questo periodo.

RIP v2 e default routes su router cisco

In questo articolo terminiamo la trattazione sul RIP iniziata nei precedenti articoli, RIP e configurazione sui router cisco e RIP: load balancing e integrazione delle rotte statiche, fornendo una comparazione tra il RIPv1 e il RIPv2.

Entrambe le versioni di RIP sono dei protocolli distance vector, sono facili da configurare e usano l’hop count come metrica (dopo 15 hop la rete viene posta come irraggiungibile), usano l’holddown timers e lo split horizon per evitare i routing loops. I router hanno conoscenza delle sottoreti direttamente connesse e gli aggiornamenti includono informazioni sulla topologia (almeno la metrica); tali aggiornamenti avvengono in maniera periodica.

Il RIPv2 apporta dei vantaggi rispetto alla prima versione del protocollo. In particolare il RIPv2:

  • supporta il classless routing;
  • include nei routing updates le subnet mask;
  • ha un meccanismo di autenticazione negli updates (utilizza la criptatura MD5);
  • invia gli aggiornamenti in multicast (indirizzo 224.0.0.9) anziché in broadcast;
  • usa un routing tag con VLSM.

La configurazione del RIPv2 è identica a quella del RIPv1, l’unica differenza sta nell’inserire il comando version 2, come da esempio sotto:

Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network network-number

Per la verifica della configurazione si possono utilizzare i comandi show ip protocols, show ip route e show ip interface brief oltre, ovviamente, a show running-config. Il troubleshooting del RIPv2 può avvenire con il comando debug ip rip mentre per disattivare il debug basta inserire no debug all oppure undebug all.

Prima di concludere parliamo della rotta di default (default route). In generale, un router apprende il percorso verso una data destinazione in tre modi: attraverso una rotta statica (l’amministratore inserisce manualmente la rotta), con una rotta dinamica (grazie agli aggiornamenti inviati secondo un protocollo di routing) oppure per mezzo di una default route.
L’amministratore di rete può definire manualmente una rotta di default, cioè il percorso da seguire nel caso in cui non conosca alcuna rotta per raggiungere la destinazione. La rotta di default porta come vantaggio l’avere una ridotta tabella di routing e un percorso di default per destinazioni non conosciute.
La default route può essere impostata dal comando ip default-network in reti che utilizzano routing dinamico:

Router(config)#ip default-network rete

ad es.:

Router(config)#ip default-network 192.168.10.0

oppure attraverso una rotta statica, ad es.:

Router(config)#ip route 0.0.0.0 0.0.0.0 s0/0

dove gli zeri sia nel campo ip che nella subnek mask indicano ogni rete di destinazione con qualsiasi maschera. L’s0/0 è interfaccia su cui inviare i pacchetti (nell’esempio la seriale 0, dovete modificarla in base alle vostre esigenze).

VLSM, CIDR e aggregazione delle rotte

La Variable-length subnet mask (VLSM) è una tecnica utilizzata dagli amministratori di rete per usare in maniera più efficiente gli indirizzi IP. Con la VLSM si offre una maschera più lunga a reti con molti host e una maschera più corta per reti con pochi host, ovvero la maschera varia a seconda del numero di indirizzi necessari a quella rete.
Per implementare la VLSM bisogna, ovviamente, utilizzare un protocollo di routing che supporta il classless routing (un protocollo che, invece, non supporta le VLSM viene detto classful). I protocolli di routing classless su cui utilizzare la VLSM nei router cisco sono:

  • OSPF
  • Integrated IS-IS
  • EIGRP
  • RIP v2
  • BGP v4
  • Routing statico

I protocolli di routing classful sono, invece:

  • RIP v1
  • IGRP
  • EGP
  • BGP v3

Il classless routing nasce per il problema della carenza di indirizzi IP dovuto al veloce aumento delle dimensioni delle tabelle di routing di Internet. Le soluzioni a questo problema sono state il subnetting, la VLSM appunto, il Classless Interdomain Routing (CIDR), l’utilizzo di indirizzi IP privati e il Network Address Translation (NAT). La soluzione definitiva sarà l’utilizzo del protocollo IPv6 che avrà un’astensione di 128bit per gli indirizzi di rete (quindi uno spazio di indirizzamento enorme).

In principio era stato deciso di non utilizzare né la prima (subnet zero) né l’ultima subnet (all-one subnet), successivamente è stato consentito l’uso anche di tali subnet, soprattutto in unione alle VLSM. Per non utilizzare la prima subnet sui router cisco basta digitare il comando no ip subnet-zero.

Le VLSM sono utilissime per utilizzare in maniera efficiente subnet con pochi host, in particolare per i collegamenti Point-to-Point con i WAN links in cui si può usare una maschera di 30 bit (/30) con 2 soli host utilizzabili.
Inoltre, l’uso di CIDR e VLSM permette di effettuare l’aggregazione delle rotte o summarization. Tale tecnica consiste nel fornire al router di uscita di una grande organizzazione (ad es. un ISP) un indirizzo che riepiloga le sottoreti raggiungibili da esso riducendo così il carico sul router. Per fare ciò è necessario che gli indirizzi vengano assegnati in maniera gerarchica in modo che gli indirizziriassuntivi” condividano lo stesso ordine superiore bit.

Connessione FTP sicura con server Aruba

Il protocollo FTP (File Transfer Protocol) è un protocollo molto utilizzato per lo scambio dati tra host, tipicamente con host remoti. Il problema principale di tale protocollo riguarda la sicurezza in quanto sia i dati che le credenziali d’accesso viaggiano in chiaro, non sono cifrati. Per ovviare a questa problematica si possono utilizzare protocolli diversi o varianti dello stesso protocollo FTP, in particolare: SFTP (SSH File Transfer Protocol), FTPS (FTP su SSL) e SCP (Secure Copy).

I server Aruba permettono di utilizzare connessioni sicure per lo scambio dati attraverso il protocollo FTPS che è una variante dell’FTP e utilizza le stesse porte per lo scambio dati. FTPS, al contrario di FTP, effettua una cifratura per l’invio delle credenziali d’accesso e/o dei dati tramite SSL/TLS (Secure Sockets Layer/Transport Layer Security).
L’iter della transazione è il seguente: il client si connette alla porte 21 del server FTP, deve accettare il certificato del server e a quel punto avviene la sincronizzazione con SSL/TLS.

Per utilizzare il il protocollo FTPS per lo scambio dati con i server Aruba basta modificare il nome host del server con ftps://ftp.nomedominio.xx al posto di ftp.nomedominio.xx e, successivamente, accettarne il certificato. Ove richiesto dal client FTP, è possibile utilizzare FTP su SSL/TLS sia implicito che esplicito.

SSH .File Transfer Protocol

Come cambiare il MAC address delle schede di rete in linux

Il MAC (Media Access Control) address è un indirizzo che identifica univocamente ogni scheda di rete prodotta a livello globale. Viene anche detto indirizzo fisico ed è composto da 48 bit di cui i primi 24 identificano il produttore (OUI, Organizationally Unique Identifier) dell’hardware mentre i restanti bit identificano il componente. Esso è usato per l’instradamento in reti switched, quindi a livello 2 dello stack ISO-OSI.

Anche se il MAC address è unico al mondo, per una determinata scheda di rete, è possibile modificarlo via software per usi più o meno “consoni”. In windows non è possibile modificarlo se non utilizzando appositi tools, mentre in linux la procedura è molto semplice, bastano poche istruzioni eseguite da shell.
Per visualizzare il MAC address delle nostre schede di rete, basta digitare il comando ifconfig e verranno visualizzate le informazioni su tutte le schede di rete attive sul pc; tra le informazioni troveremo il MAC address sotto la voce HWaddr.

Per modificare il MAC address bastano 3 semplici comandi: supponiamo di voler modificare il MAC della scheda ethernet (eth0), dobbiamo prima disattivarla, poi modifichiamo l’indirizzo fisico e, infine, la riattiviamo. Es.:

ifconfig eth0 down
ifconfig eth0 hw ether 00:11:22:33:44:55
ifconfig eth0 up

Ovviamente è possibile inserire al posto di 00:11:22:33:44:55il MAC address voluto. Per effettuare tale operazione è necessario avere i privilegi di amministratore, quindi se siete con ubuntu, ad esempio, dovete anteporre ai comandi l’istruzione sudo.

Se non ricordate più il MAC address originale niente panico! Riavviando il PC verrà reimpostato il MAC address originale della scheda di rete poiché la modifica viene effettuata solo via software senza modificare in alcun modo il firmware della scheda di rete.

Tags: , , , ,

Configurazione delle ACL: standard, extended e named. Posizionamento

Nel precedente articolo abbiamo iniziato a trattare l’argomento delle ACLs con una panoramica teorica e pratica sulle wildcard e sui tipi di ACLs. Abbiamo, inoltre, visto la configurazione di una semplice ACL standard. Prima di passare in questo articolo alle Extended ACLs, terminiamo dicendo che nelle Standard ACL (ma anche nelle altre) è possibile inserire un commento per meglio identificare l’ACL in maniera pratica e veloce tramite il comando remark (comando opzionale).
Per inserire il commento a una ACL esistente bisogna inserire il comando:

Router(config)#access-list numero remark commento

L’ultimo comando utilizzabile è il comando log (comando opzionale) alla fine della dichiarazione di una ACL: esso crea una serie di informazioni di logging sui pacchetti inviati o bloccati dalle ACLs. In tali informazioni si trovano il numero dell’ACL, il numero di pacchetti passati o scartati e  l’IP sorgente. In generale il comando per impostare una ACL standard è:

Router(config)#access-list access-list-number {permit deny} {test-conditions}

più le eventuali opzioni.

Passiamo adesso alle Extended ACLs che sono spesso preferite alle Standard ACLs in quanto sono configurabili con molti più parametri: esse possono fare un controllo sull’IP sorgente, su quello di destinazione, sul protocollo e sul numero di porta.
Le Extended ACLs sono caratterizzate da numeri identificativi che vanno da 100 a 199 e da 2000 a 2699; vanno applicate il più vicino possibile alla sorgente di traffico. Facciamo un esempio pratico per capire come settare questo tipo di ACL.

Supponiamo di voler bloccare il telnet dall’host 192.168.50.15, la regola sarà:

Router(config)#access-list 101 deny tcp host 192.168.50.15 eq telnet

oppure

Router(config)#access-list 101 deny tcp host 192.168.50.15 eq 23

Per prima cosa identifichiamo l’ACL con un identificativo nel range apposito, successivamente va indicato il protocollo (nel nostro caso il tcp) e l’indirizzo con la wildcard mask. Nel nostro esempio si è usato il comando host al posto della wildcard 0.0.0.0; infine va indicato il servizio o la porta da bloccare. Il resto dei comandi resta uguale alle standard ACLs:

Router(config)#interface {interfaccia}
Router(config-if)# ip access-group numero_acl {in|out}

Le ACLs viste finora sono dette numbered poiché la singola ACL è identificata da un identificativo numerico. Oltre ad esse vi sono le ACLs basate sul nome, dette named ACLs. Le ACLs named possono essere sia standard che estese e il tipo va specificato in sede di configurazione nel seguente modo:

Router(config)#ip access-list {standard|extended} ACL-name

Nelle named ACLs il comando access-list è preceduto dal comando ip. I vantaggi di tali ACL sono:

  • possibilità di utilizzare caratteri alfanumerici per identificare l’ACL (anche semanticamente più facili da ricordare);
  • non vi è alcun limite al numero di named ACLs;
  • possono essere modificate senza cancellare completamente l’ACL e riconfigurarla.

Dove vanno posizionate le ACLs?
La regola generale è quella di posizionare le extended ACLs il più vicino possibile alla sorgente di traffico da bloccare per bloccare i pacchetti il prima possibile. Le standard ACL non specificano l’indirizzo di destinazione, pertanto le standard ACLs vanno posizionate il più vicino possibile alla destinazione. Questo impedisce che venga bloccato anche traffico utile che invece non va controllato.

Terminiamo questo articolo dicendo che le ACLs possono essere utilizzate anche per limitare gli accessi sulle virtual ports, dette anche vty lines, attraverso il comando access-class al posto di access-group. Tale procedura serve ad aumentare la sicurezza della rete; ad esempio, serve a limitare l’accesso al router tramite telnet (connessione vty). Il procedimento per la creazione di una vty access list è la stessa di quella descritta per le interfacce a parte il comando access-class. Facciamo un esempio: supponiamo che gli utenti della rete 192.168.10.0/24 possano utilizzare le virtual ports mentre bisogna bloccare i rimanenti accessi utilizzando una standard ACL con identificativo 5; i comandi saranno:

Router(config)#access-list 5 permit 192.168.10.0 0.0.0.255
Router(config)#access-list 5 deny any

Applichiamo adesso l’ACL:

Router(config)#line vty 0 4
Router(config-line)#login
Router(config-line)#password secret
Router(config-line)#access-class 5 in

Nota: per la ACL su vty line possono essere applicate solo ACLs numbered e non named.

Introduzione alle Access Control Lists su router Cisco e alle wildcard mask

Le Access Control Lists (nel seguito ACLs) sono una lista di condizioni utilizzate per “controllare” il traffico e si applicano alle porte del router che decide se far passare un determinato pacchetto oppure bloccarlo. I criteri decisionali si basano sull’indirizzo IP sorgente, quello di destinazione, sulle porte e sui protocolli. Le ACLs possono essere usate con qualsiasi protocollo routed di livello rete come IP e IPX. Elenchiamo alcuni aspetti positivi apportati dalle ACLs:

  • limitano il traffico della rete aumentando così le performance;
  • effettuano un controllo di flusso sul traffico;
  • offrono un livello base di sicurezza per l’accesso alla rete;
  • decidono quale tipo di traffico inoltrare e quale bloccare.

Se non vi è alcuna ACLs configurata sul router tutti i pacchetti vengono inoltrati senza distinzione.

Vediamo ora il funzionamento di un’ACLs. L’ordine in cui vengono immesse le ACLs è fondamentale in quanto l’IOS effettua un controllo sulle condizioni dall’alto verso il basso, ovvero dalla prima condizione immessa fino all’ultima. Se ad esempio la prima condizione permette l’inoltro di tutto il traffico tutte le altre verranno ignorate! Bisogna fare quindi molta attenzione.
Quando una condizione è verificata il pacchetto viene inoltrato o bloccato in base alla regola impostata nella ACLs; se nessuna delle condizioni nell’ACLs combacia,  implicitamente vi è un deny any in fondo alla lista, di default e, quindi, il pacchetto verrà scartato.

Le ACLs utilizzano le wildcard mask per impostare le condizioni. Una wildcard mask è formata da 32 bit suddivisa in 4 ottetti (esattamente come gli indirizzi IP) dove lo zero indica il bit nell’indirizzo da esaminare mentre l’1 il bit corrispondente nell’indirizzo da ignorare.  Vi sono 2 wildcard particolari che sono la 0.0.0.0 e la 255.255.255.255: la prima è sostituita dalla parola chiave host (verifica tutto l’IP) mentre la seconda dalla parola chiave any. Più avanti faremo un esempio pratico, prima però passiamo alla definizione delle ACLs sui ruoter Cisco.

Ci sono diversi tipi di ACLs: standard, extended e named. Quando una ACLs viene configurata gli viene assegnato un identificativo univoco che identifica anche il tipo di ACLs in base a un range di identificativi. I range disponibili sono:

  • standard IP: 1-99, 1300-1999
  • extended IP: 100-199, 2000-2699
  • AppleTalk: 600-699
  • IPX: 800-899
  • extended IPX: 900-999
  • IPX Service Advertising Protocol: 1000-1099

Per inserire le regole in una ACLs si utilizza il comando access-list seguito dai vari parametri mentre per associarla a un’interfaccia si utilizza il comando access-group. La regola generale è:

Router(config)#access-list access-list-number {permit deny} {test-conditions}

mentre sull’interfaccia:

Router(config-if)#{protocol} access-group access-list-number

Vediamo un esempio pratico mostrando il funzionamento della wildcard. Supponiamo di voler bloccare in ingresso all’interfaccia ethernet1 il traffico proveniente dalla rete 172.16.0.0/16 con una stardard ACLs con identificativo 2 mentre bisogna lasciar passare tutto il resto del traffico dalla rete 172.0.0.0/8, i comandi saranno:

Router(config)#access-list 2 deny 172.16.0.0 0.0.255.255
Router(config)#access-list 2 permit 172.0.0.0 0.255.255.255
Router(config)#interface e0
Router(config-if)# ip access-group 2 in

La prima condizione forma un valore di confronto (applicando la wildcard) che, se rispecchiato dall’indirizzo del pacchetto in ingresso, tale pacchetto sarà scartato.

IP addess 172.16.0.0 10101100 00010000 00000000 00000000
wildcard mask 00000000 00000000 xxxxxxxx xxxxxxxx
Valore di confronto 10101100 00010000 xxxxxxxx xxxxxxxx

Se in arrivo ho un pacchetto da un host con IP 172.16.4.64 avrò una situazione di questo tipo:

IP addess 172.16.4.64 10101100 00010000 00000100 01000000
wildcard mask 00000000 00000000 xxxxxxxx xxxxxxxx
Valore di confronto 10101100 00010000 xxxxxxxx xxxxxxxx

il valore di confronto combacia e quindi, per la regola impostata, il pacchetto verrà scartato. Viceversa, la seconda regola mi forma un valore di confronto del tipo:

IP addess 172.0.0.0 10101100 00000000 00000000 00000000
wildcard mask 00000000 xxxxxxxx xxxxxxxx xxxxxxxx
Valore di confronto 10101100 xxxxxxxx xxxxxxxx xxxxxxxx

Se ho un pacchetto in ingresso all’interfaccia da un host con IP 172.8.10.1:

IP addess 172.8.10.1 10101100 00001000 00001010 00000001
wildcard mask 00000000 xxxxxxxx xxxxxxxx xxxxxxxx
Valore di confronto 10101100 xxxxxxxx xxxxxxxx xxxxxxxx

tale pacchetto verrà inoltrato in quanto il valore di confronto coincide con la regola impostata nell’ACLs.

La verifica della configurazione delle ACLs si effettua attraverso i comandi show. Il comando show ip interface mostra le informazioni sulle ACLs impostate sulle interfacce. Il comando show access-list mostra, invece, il contenuto di tutte la ACLs programmate sul router.

Nel prossimo articolo vedremo la configurazione dei vari tipi di ACLs.

IGRP: caratteristiche, metrica e configurazione

L’Interior Gateway Routing Protocol (IGRP) è un protocollo distance vector proprietario cisco. Essendo un protocollo distance vector l’IGRP invia aggiornamenti periodici di routing per mantenere la consistenza delle informazioni al variare della rete (per l’inserimento di nuove destinazioni o per identificare reti irraggiungibili).

Gli update di routing dell’IGRP vengono inviati ogni 90 secondi ai router appartenenti allo stesso AS (ricordiamo che l’IGRP è un protocollo IGP). Le caratteristiche principali di tale protocollo sono:

  • adattamento automatico alle variazioni anche in reti con topologia complessa;
  • flessibilità nella gestione di reti con diverse caratteristiche di banda e latenza;
  • scalabilità necessaria per reti molto estese.

Di base l’IGRP sceglie il percorso su cui instradare un pacchetto in base a una metrica basata sulla banda disponibile e sul ritardo. Tuttavia, l’IGRP può essere configurato per tenere conto, oltre che della banda e del ritardo, anche del carico in quel momento e dell’affidabilità della rete.  Tale metrica è, ovviamente, più accurata dell’hop count utilizzato dal RIP per scegliere il percorso di un pacchetto fino a destinazione. Vediamo meglio i parametri principali utilizzati nella metrica per la scelta del percorso:

  • banda: si tiene conto della banda delle reti che si attraversano fino a destinazione;
  • ritardo: ritardo cumulativo calcolato sulle interfacce oltrepassate lungo il percorso;
  • affidabilità: l’affidabilità del collegamento fino a destinazione determinato con lo scambio di informazioni riguardo la raggiungibilità delle reti nel tempo;
  • carico: il carico di un link verso la destinazione misurato in bit/secondo.

L’IGRP implementa le funzioni di holddowns, split horizons e poison reverse updates (già trattati in un precedente articolo). Tale protocollo non supporta le VLSM, supportate invece da un altro protocollo proprietario cisco che è l’EIGRP.

Passiamo adesso alla configurazione del protocollo. Il processo di routing si attiva con il comando router igrp in modalità configurazione (per disabilitarlo basta inserire il comando no router igrp). Perché il comando sia completo bisogna inserire anche un as-number, ovvero un identificativo per il processo IGRP; tutti i router che partecipano al processo di routing devono avere lo stesso as-number. Nel successivo menu bisogna inserire le reti direttamente connesse su cui inviare e ricevere gli update tramite il comando network (esattamente come accade per il RIP). Facciamo un esempio. Vogliamo inserire su un router 2 reti con identificativo di processo 101, i comandi saranno:

Router(config)# router igrp 101
Router(config-router)# network 192.168.10.0
Router(config-router)# network 192.168.11.0