ACL Standard ed Extended

PC2 della sede di Roma (172.16.0.3) genera traffico indesiderato verso la LAN di Torino (172.16.3.64/27). L’obiettivo è bloccare solo questo host, permettendo comunque la comunicazione tra le altre macchine di Roma e la sede di Torino.

L’ACL standard 1 lavora unicamente sull’indirizzo sorgente: viene negato il traffico con sorgente 172.16.0.3 e permesso il resto. L’ACL viene applicata in ingresso sulla WAN di Torino, cioè sul traffico proveniente da Roma.

Topologia di riferimento

Configurazione ACL su Router Torino

Router>enable
Router#config terminal
Router(config)#ip access-list standard 1
Router(config-std-nacl)#deny 172.16.0.3 0.0.0.0
Router(config-std-nacl)#permit any
Router(config-std-nacl)#exit

Router(config)#interface f0/0
Router(config-if)#ip access-group 1 in
Router(config-if)#exit

Creazione e assegnazione ACL

Nella CLI del router viene creata la lista di controllo 1, con la riga di deny per l’host 172.16.0.3 e la permit any finale, quindi viene associata in ingresso all’interfaccia f0/0 verso Roma. Il comando show access-lists conferma la presenza delle entry configurate.

Ispezione della PDU bloccata

L’analisi della PDU su Router Torino mostra il pacchetto ICMP con sorgente 172.16.0.3 diretto a 172.16.3.67. L’ACL 1 in ingresso sull’interfaccia individua una corrispondenza con la riga deny host 172.16.0.3 e il pacchetto viene scartato.

Verifica dal punto di vista del client

Dal prompt di PC2 (172.16.0.3) il ping verso l’host 172.16.3.67 di Torino termina con Request timed out, mentre gli altri PC di Roma riescono a raggiungere correttamente la stessa destinazione, confermando che il blocco è limitato al solo PC2.

In questo modo l’intervento è mirato sul singolo host problematico, senza modificare il comportamento del resto del traffico tra Roma e Torino.

Il server della sede di Venezia (SRV-Venezia 172.16.2.100) eroga un servizio HTTP. Si vuole impedire l’accesso web da Milano e Torino, lasciando però disponibili gli altri servizi, in particolare ICMP e DNS, da tutte le sedi.

La soluzione utilizza un’ACL estesa numerata 101 applicata in uscita sull’interfaccia LAN di Venezia, in modo da controllare le richieste dirette al server web prima che raggiungano la LAN 172.16.2.0/24.

Topologia di riferimento

Configurazione ACL 101 su Router Venezia

Router>enable
Router#configure terminal
Router(config)#ip access-list extended 101
Router(config-ext-nacl)#deny tcp 172.16.3.0 0.0.0.63 host 172.16.2.100 eq 80
Router(config-ext-nacl)#deny tcp 172.16.3.64 0.0.0.31 host 172.16.2.100 eq 80
Router(config-ext-nacl)#permit ip any any
Router(config-ext-nacl)#exit

Router(config)#interface f0/0
Router(config-if)#ip access-group 101 in
Router(config-if)#exit

Creazione e assegnazione dell’ACL

L’ACL 101 nega il traffico tcp diretto alla porta 80 del server 172.16.2.100 proveniente dalle due sottoreti di Milano (172.16.3.0/26) e Torino (172.16.3.64/27). La riga permit ip any any consente tutti gli altri protocolli e destinazioni. L’ACL è applicata in uscita su f1/0, verso la LAN di Venezia.

Ispezione della PDU bloccata

La PDU catturata su Router Venezia mostra un pacchetto TCP con sorgente nella sottorete di Torino e destinazione 172.16.2.100 porta 80. L’uscita indica che la porta con ACL ID 101 verifica il pacchetto e lo scarta in corrispondenza della riga deny tcp ... eq www.

Verifica ICMP e HTTP dalle filiali

ICMP consentito verso il server

Un PC di Torino (172.16.3.65) esegue ping 172.16.2.100 ottenendo risposta. L’ACL agisce solo sul traffico TCP porta 80, quindi ICMP resta permesso.

Accesso HTTP: Roma OK, Torino bloccata

Dal PC di Roma l’URL http://172.16.2.100 carica correttamente la pagina del laboratorio ACL, mentre dal PC di Torino la richiesta termina con Request Timeout. Il filtro è selettivo: solo Milano e Torino non possono accedere al servizio web, tutte le altre sedi restano abilitate.

Questo scenario evidenzia l’uso delle ACL estese per filtrare in base a protocollo, porta e sottorete sorgente, proteggendo un servizio specifico senza interrompere la connettività generale tra le sedi.

La sede di Milano (172.16.3.0/26) deve poter raggiungere la LAN di Venezia (172.16.2.0/24) solo tramite ICMP. Tutto il resto del traffico IP proveniente da Milano verso Venezia deve essere bloccato.

Per ottenere questo risultato viene utilizzata un’ACL estesa numerata 110, applicata in ingresso sull’interfaccia Fa0/0 del router di Venezia, che riceve il traffico proveniente da Milano.

Topologia di riferimento

Configurazione ACL 110 su Router Venezia

Router>enable
Router#config t
Router(config)#ip access-list extended 110
Router(config-ext-nacl)#permit icmp 172.16.3.0 0.0.0.63 172.16.2.0 0.0.0.255
Router(config-ext-nacl)#deny ip 172.16.3.0 0.0.0.63 172.16.2.0 0.0.0.255
Router(config-ext-nacl)#permit ip any any
Router(config-ext-nacl)#exit

Router(config)#interface Fa0/0
Router(config-if)#ip access-group 110 in
Router(config-if)#exit

Creazione e assegnazione dell’ACL

La prima riga della lista consente il traffico icmp da 172.16.3.0/26 verso 172.16.2.0/24. La seconda riga nega tutto il traffico IP tra le stesse reti. L’ultima riga permit ip any any evita di bloccare comunicazioni non coinvolte nello scenario.

ICMP consentito da Milano verso Venezia

Dal PC9 di Milano (172.16.3.1) il comando ping 172.16.2.1 va a buon fine. La richiesta ICMP corrisponde alla prima regola dell’ACL e viene inoltrata regolarmente.

Accesso HTTP bloccato verso il server di Venezia

Quando lo stesso PC9 tenta di aprire http://172.16.2.100, il pacchetto viene scartato. L’ispezione della PDU mostra che il router applica l’ACL 110 e che la richiesta HTTP viene bloccata dalla regola deny ip tra Milano e Venezia.

In questo modo Milano mantiene la possibilità di verificare la raggiungibilità di Venezia con il ping, ma non può utilizzare servizi applicativi come il web server della sede.

Nella sede di Venezia è presente un server web con indirizzo 172.16.2.100. La direzione decide che i PC della sede di Milano non devono più poter accedere al servizio HTTP del server, mentre il traffico verso Roma e Torino deve rimanere invariato.

La soluzione prevede la creazione di un’ACL standard numerata 3 sul router di Milano e la sua applicazione in ingresso sull’interfaccia WAN collegata al resto della rete. In questo modo il router scarta i pacchetti provenienti dal server di Venezia (host 172.16.2.100) diretti verso la LAN di Milano.

Topologia di riferimento

Configurazione ACL 3 su Router Milano

Router>enable
Router#configure terminal
Router(config)#ip access-list standard 3
Router(config-std-nacl)#deny 172.16.2.100 0.0.0.0
Router(config-std-nacl)#permit any
Router(config-std-nacl)#exit

Router(config)#interface f0/0
Router(config-if)#ip access-group 3 in
Router(config-if)#exit

Creazione e assegnazione dell’ACL standard

L’ACL 3 contiene due regole: deny host 172.16.2.100 che blocca il traffico proveniente dal server web di Venezia e permit any che consente tutto il resto. L’ACL è applicata in ingresso su FastEthernet0/0, interfaccia verso la WAN, così ogni pacchetto diretto alla LAN di Milano viene filtrato prima di essere inoltrato agli host interni.

Verifica della connettività da Milano

ICMP ancora consentito verso Venezia

Da un PC della sede di Milano si esegue il comando ping 172.16.2.1 (gateway della LAN di Venezia) ottenendo risposta. L’ACL standard agisce solo sull’indirizzo sorgente 172.16.2.100, quindi il resto del traffico verso la rete 172.16.2.0/24 continua a essere inoltrato normalmente.

Accesso HTTP al server web bloccato

Quando lo stesso PC tenta di aprire l’URL http://172.16.2.100, la richiesta non va a buon fine. L’ispezione della PDU sul router di Milano mostra che il pacchetto corrisponde alla riga deny host 172.16.2.100 dell’ACL 3 e viene quindi scartato. Per Roma e Torino, invece, il server resta raggiungibile perché l’ACL è applicata solo sul percorso verso Milano.

Lo scenario mostra come una semplice ACL standard, basata esclusivamente sull’indirizzo IP sorgente, possa essere utilizzata per isolare un servizio da una specifica sede mantenendo intatta la connettività con il resto della rete aziendale.