Access Control Lists – La tua guida alla sicurezza delle reti con ACL [ Tutorial & Comandi ]

Quando esci di casa la mattina, (probabilmente) chiudi le porte dietro di te. In uno scenario normale, solo le persone che hanno le chiavi per sbloccare la porta dovrebbero avere accesso alla tua casa. Lo facciamo per ragioni di sicurezza. Allo stesso modo, potremmo voler controllare chi/cosa ha accesso a diverse parti della nostra rete e uno dei modi per farlo è usare le Access Control Lists (ACLs).

In questo articolo, faremo un’immersione profonda nelle ACLs come applicabili al controllo degli accessi alla rete. Considereremo la struttura di una ACL, come le ACL vengono elaborate e anche come applicare le ACL configurate. Inoltre, per rendere questo articolo il più pratico possibile, considereremo un caso di studio in cui configureremo le ACL su un dispositivo Cisco IOS. La conoscenza di questo caso di studio può essere applicata a dispositivi di altri fornitori.

Nota: le ACL non sono utili solo per scopi di filtraggio; trovano applicazione anche in altre aree come la configurazione del Network Address Translation (NAT), la corrispondenza di quali rotte pubblicizzare/accettare nei protocolli di routing dinamico, il routing basato su policy, e molte altre. Inoltre, le ACL non sono limitate alla rete, poiché sono anche usate in altri sistemi come i file system per controllare l’accesso a file/oggetti.

Liste di controllo d’accesso

Che cos’è una lista di controllo d’accesso?

Proprio come dice la frase, una lista di controllo d’accesso (ACL) è una lista che controlla l’accesso. Ciò significa che, quando vengono usate per il controllo dell’accesso alla rete, le ACL determinano quali host sono autorizzati (o non autorizzati) ad accedere ad altri dispositivi/destinazioni. Questo è tipicamente fatto su una base per pacchetto, il che significa che ogni pacchetto è controllato rispetto all’ACL per determinare se permettere o negare quel pacchetto.

Nota: le ACL possono essere usate per controllare vari campi in un pacchetto, incluso il Layer 2 (ad es. indirizzi MAC), Layer 3 (ad es. indirizzi IPv4), Layer 4 (ad es. numero di porta TCP), e così via. In questo articolo, limiteremo la nostra discussione al Layer 3+. Inoltre, la maggior parte delle ACL sono considerate “stateless”, il che significa che ogni pacchetto in un flusso è considerato da solo, a differenza del filtraggio stateful che tiene traccia dello stato di una connessione.

Struttura delle ACL

Come abbiamo già detto, una ACL è una lista, il che significa che è una lista di qualcosa. In termini tecnici, diciamo che una ACL è una lista di Access Control Entries (ACEs), con ogni voce che contiene criteri di corrispondenza per un particolare pacchetto.

In base a questa descrizione, una ACL può essere suddivisa in due parti principali:

• Identificazione ACL che è tipicamente un nome o un numero. Come vedremo più avanti, le ACL possono anche essere identificate dal loro tipo.
• Un numero di voci di controllo di accesso che sono tipicamente identificate da numeri sequenziali.

Access Control Entries (ACEs)

Le ACL costituiscono il grosso di una ACL con ogni ACL contenente da una a tante voci permesse da un particolare dispositivo. Senza prestare attenzione al tipo specifico di una ACL, un ACE è composto da quanto segue:

• Un’identificazione che di solito è un numero di linea. Per esempio, il primo ACE nell’ACL configurata su un router Cisco IOS ha un numero di riga 10 per default; il successivo ha un numero di riga 20; e così via.
• Un’azione da eseguire per un pacchetto che corrisponde alla voce. Tipicamente, questa è “permit” o “deny”.
• In alcuni casi, le informazioni sul protocollo e la porta che devono corrispondere in un pacchetto. Per esempio, un ACE può corrispondere a tutto il traffico IP mentre un altro ACE corrisponde solo al traffico HTTP.
• La fonte a cui corrispondere. Questo è di solito l’indirizzo (IP) della fonte del pacchetto. Può essere un singolo indirizzo, un intervallo di indirizzi, una subnet, o anche qualsiasi indirizzo.
• La destinazione da abbinare. Questo è di solito l’indirizzo (IP) della destinazione del pacchetto. Può essere un singolo indirizzo, un intervallo di indirizzi, una sottorete o qualsiasi indirizzo.

Tenete a mente che i componenti sorgente e destinazione degli ACE sono soggettivi, a seconda della direzione del pacchetto. Considerate il diagramma qui sotto:

Ci sono due scenari che possiamo considerare dalla prospettiva del router, R1:

1. Se il PC1 inizia la comunicazione con il PC2 (es.ping da PC1 a PC2), la sorgente del traffico è 192.168.1.100 mentre la destinazione è 192.168.2.200.
2. Se il PC2 inizia la comunicazione con il PC1 (ad esempio ping da PC2 a PC1), la sorgente del traffico è 192.168.2.200 mentre la destinazione è 192.168.1.100.

Elaborazione ACL

Quando un pacchetto viene controllato rispetto ad una ACL, si applicano le seguenti regole di elaborazione:

• Gli ACE in una ACL sono controllati in ordine dall’alto verso il basso. Questo significa che l’ACE #10 sarà controllato prima dell’ACE #20.
• Se un pacchetto non corrisponde ad un ACE, viene controllato rispetto alla voce successiva nell’ACL.
• Se un pacchetto corrisponde ad un ACE, il controllo rispetto all’intera ACL si ferma e l’azione specificata sull’ACE corrispondente viene applicata al pacchetto.
• Se un pacchetto non corrisponde a nessuna voce di una ACL, la maggior parte delle implementazioni ACL negherà/eliminerà questo pacchetto perché c’è una voce implicita di rifiuto alla fine di ogni ACL.

Facciamo un esempio per capire queste regole di elaborazione. Immaginiamo di avere una ACL con le seguenti voci:

• Seq #1: Permettere ICMP da 192.168.1.100 a 192.168.2.200
• Seq #2: Negare ICMP da qualsiasi sorgente a qualsiasi destinazione
• Seq #3: Permettere il traffico HTTP da 192.168.1.100 a qualsiasi destinazione
• Seq #4: Permettere il traffico HTTPS da 192.168.1.0/24 a qualsiasi destinazione

Q1: Cosa succederà a un pacchetto ping da 192.168.1.100 a 192.168.2.200?

A1: Poiché il ping è basato su ICMP, il pacchetto da 192.168.1.100 a 192.168.2.200 sarà permesso perché corrisponde all’ACE con Seq #1.

Q2: Cosa succederà ad un pacchetto ping da 192.168.1.50 a 192.168.2.200?

A2: Il pacchetto sarà controllato rispetto all’ACL a partire dalla Seq #1. Poiché non corrisponde a questa voce, verrà controllata la voce successiva (Seq #2). Questa voce nega l’ICMP da qualsiasi sorgente a qualsiasi destinazione. Poiché questo è un pacchetto ping (cioè ICMP) e la sorgente si qualifica come “any” e anche la destinazione si qualifica come “any”, il pacchetto sarà negato.

Q3: Cosa succederà ad un pacchetto HTTPS da 192.168.1.50 a 41.1.1.1?

A3: Questo pacchetto non corrisponderà alle prime tre voci dell’ACL. Tuttavia, corrisponderà alla quarta voce perché è un pacchetto HTTPS, con una sorgente che è contenuta nella subnet 192.168.1.0/24, e una destinazione qualificata come “any”. Pertanto, questo pacchetto sarà permesso.

Q4: Cosa succederà a un pacchetto HTTP da 192.168.1.50 a 41.1.1.1?

A4: Questo pacchetto non corrisponderà a nessuna voce di questa ACL (solo 192.168.1.100 è autorizzato a inviare traffico HTTP). Pertanto, sarà negato assumendo che la regola “implicit deny” si applichi a questa ACL.

Applicare le ACL

Proprio come è inefficace installare una serratura alla porta e uscire di casa senza chiudere la porta, anche configurare le ACL senza applicarle è inutile. Quando vengono usate per il controllo/filtraggio dell’accesso alla rete, le ACL sono tipicamente applicate sulle interfacce dei dispositivi, dispositivi come router, switch multistrato, firewall, e così via.

In generale, una ACL può essere applicata in due direzioni su un’interfaccia:

• In entrata: Si applica ai pacchetti che entrano nell’interfaccia
• In uscita: Si applica ai pacchetti che escono dall’interfaccia

Perché capire quale direzione applicare le ACL può essere difficile, facciamo un esempio. Nell’immagine qui sotto, il PC1 è connesso all’interfaccia Fa0/0 di R1 mentre il PC2 è connesso all’interfaccia Fa0/1 di R1.

Ora, immaginiamo di voler applicare una ACL su R1 tale che solo il traffico ping (ICMP) da PC1 a PC2 sia permesso; dove possiamo applicare questa ACL?

• Primo, possiamo applicare questa ACL sull’interfaccia Fa0/0 nella direzione in entrata. Questo perché il traffico ping da PC1 a PC2 entrerà in R1 dalla sua interfaccia Fa0/0.
• In alternativa, possiamo applicare questa ACL sull’interfaccia Fa0/1 in direzione outbound. Questo perché il traffico ping da PC1 a PC2 uscirà da R1 attraverso la sua interfaccia Fa0/1.

Suggerimento: qualcosa che ho imparato un po’ di tempo fa e che può aiutare nella comprensione delle direzioni ACL è pensare a te stesso come un router. Mettiti in piedi e stendi le braccia lungo i fianchi come se stessi formando una croce: il traffico che entra dalle tue dita nel tuo corpo è in entrata mentre il traffico che va dal tuo corpo alle tue dita è in uscita.

Caso di studio: ACL su dispositivi Cisco IOS

Sui dispositivi Cisco IOS, ci sono due tipi di ACL (come minimo):

• ACL standard che corrispondono solo all’indirizzo sorgente
• ACL estese che possono corrispondere a una combinazione di protocolli, indirizzi sorgente/destinazione, porte sorgente/destinazione, opzioni e così via.

Nota: Cisco ha altri tipi di ACL come le ACL basate sul tempo, le ACL riflessive, le ACL dinamiche e così via. Tuttavia, queste vanno oltre lo scopo di questo articolo.

A prescindere dal tipo, le ACL sui dispositivi Cisco IOS possono essere nominate (ad esempio “TESTACL”) o numerate (ad esempio 100). Si noti che se si usano ACL numerate, ci sono particolari intervalli di numeri per le ACL standard ed estese.

Quando si specificano gli indirizzi di origine e destinazione su un’ACL nella configurazione Cisco IOS, si usa qualcosa chiamato maschera, nota anche come maschera inversa o maschera jolly. A livello base, la maschera jolly è solo la maschera di sottorete capovolta, cioè gli 1 diventano 0 e gli 0 diventano 1. Per esempio, la maschera jolly corrispondente alla maschera di sottorete 255.255.255.0 è 0.0.0.255.

Per la maschera jolly, 0 significa “deve corrispondere” mentre 1 è un bit “non importa”. Per esempio, una rete 10.1.1.0 con una maschera jolly di 0.0.0.3 corrisponderà al traffico dagli indirizzi IP da 10.1.1.1 a 10.1.1.3.

Nota: corrisponderà anche a 10.1.1.0 ma poiché questo è un indirizzo di rete, non è un indirizzo sorgente valido su un pacchetto.

Utilizziamo il seguente setup di laboratorio per il nostro caso di studio:

È possibile costruire questa topologia in GNS3 o Packet Tracer. Gli indirizzi IP sono stati configurati su tutte le interfacce e EIGRP è in esecuzione sulla rete in modo che ci sia connettività tra tutti i dispositivi:

R1:

R2:

R3:

Per testare la connettività, farò un ping a R3 dalle interfacce di loopback di R2:

Creazione di ACL su Cisco IOS

Configuriamo ora una ACL su R1 in modo che siano soddisfatte le seguenti condizioni:

• Tutto il traffico ICMP da 192.168.10.0/24 verso qualsiasi destinazione dovrebbe essere permesso
• Tutto l’altro traffico ICMP dovrebbe essere negato
• Tutto il traffico IP da 192.168.20.0/24 a 192.168.30.0/24 dovrebbe essere permesso
• I dispositivi sulla rete 192.168.10.0/24 dovrebbero potersi collegare all’host 192.168.30.1 usando SSH; Telnet dovrebbe essere negato.
• Tutto l’altro traffico dovrebbe essere negato

Per configurare una ACL su un dispositivo Cisco IOS, usiamo i seguenti passi:

• Definire l’ACL usando un nome o un numero. Tenete a mente che le ACL con nome sono più facili da modificare. Il comando per configurare una named ACL è ip access-list < nome ACL>
• Configurare gli ACE sotto l’ACL usando la sintassi di base: <protocollo><rete sorgente>< maschera jolly sorgente>< rete destinazione>< maschera jolly di destinazione><opzioni>
• Andare sotto l’interfaccia necessaria e applicare la ACL usando il comando ip access-group < nome dell’ACL>

Quindi, la configurazione per ottenere questo su R1 è la seguente:

ip access-list extended EXAMPLE_ACLpermit icmp 192.168.10.0 0.0.0.255 anydeny icmp any anypermit ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.1 eq 22!interface FastEthernet0/0ip access-group EXAMPLE_ACL in!

Ci sono un paio di cose da notare su questa configurazione:

• Ho configurato una ACL chiamata “EXAMPLE_ACL”. Questa ACL è estesa perché ho bisogno di corrispondere a diversi campi.
• Possiamo usare la parola chiave “any” per corrispondere a qualsiasi indirizzo
• Possiamo usare la parola chiave “host” per corrispondere ad un singolo indirizzo
• Possiamo specificare una porta da corrispondere usando parole chiave come “eq” che significa uguale a, “gt” che significa maggiore di, e così via.
• Non ho esplicitamente negato tutto il resto del traffico – la regola “implicit deny” alla fine di ogni ACL Cisco negherà tutto il traffico che non è soddisfatto da questa ACL
• Ho applicato questa ACL in direzione inbound sull’interfaccia Fa0/0. Avrei potuto applicarla anche in uscita sull’interfaccia Fa0/1.

Verificare le ACL

Posso visualizzare la configurazione e le statistiche delle ACL usando il comando show ip access-lists o show access-lists:

Nota la numerazione: inizia da 10 e ogni nuova voce viene aggiunta sotto la voce precedente. Posso usare il comando show ip interface per visualizzare le ACL applicate su un’interfaccia:

Nota: Puoi applicare fino a due ACL su un’interfaccia, una in ogni direzione.

Modifica delle ACL

Tuttavia, applicando questa ACL, ho creato un problema tra R1 e R2:

La relazione EIGRP è stata terminata perché i pacchetti EIGRP vengono negati dalla regola “implicit deny” alla fine della ACL. Dobbiamo risolvere questo problema permettendo esplicitamente i pacchetti EIGRP nella nostra ACL.

Attenzione: Bisogna fare attenzione quando si modifica un’ACL, poiché i nuovi ACE vengono aggiunti in fondo all’ACL (prima del deny implicito). Tuttavia, con le ACL con nome, puoi specificare il numero di linea in cui vuoi che una voce sia posizionata.

Nel nostro caso, non importa dove aggiungiamo la voce per permettere il traffico EIGRP poiché non c’è nessun’altra voce che influenzi quel traffico prima della regola implicita deny. Tuttavia, solo per vedere come aggiungere voci in qualsiasi linea di una ACL, aggiungiamo la voce “permit eigrp any any” alla linea 5 della nostra ACL:

Fico! La nostra relazione EIGRP è tornata.

Testare le ACL

Possiamo ora andare avanti a testare la nostra ACL. Ricordate che quando testate le ACL, non dovreste solo testare ciò che dovrebbe funzionare, ma anche ciò che NON dovrebbe funzionare.

Test 1: Il ping da 192.168.10.1 a 192.168.30.1 dovrebbe essere permesso a causa della voce 10 della linea ACL.

Possiamo controllare i contatori della nostra ACL per vedere che questo traffico è stato soddisfatto dall’ACL:

Test 2: Ping da 192.168.20.1 a 192.168.30.1 dovrebbe fallire a causa della voce di linea ACL 20.

Test 3: Telnet e SSH da 192.168.20.1 a 192.168.30.1 dovrebbe essere permesso a causa della voce di linea ACL 30.

Test 4: SSH da 192.168.10.1 a 192.168.30.1 dovrebbe essere permesso a causa della voce 40 della linea ACL.

Test 5: Telnet da 192.168.10.1 a 192.168.30.1 dovrebbe fallire a causa della regola deny implicita.

Possiamo controllare i conteggi sull’ACL per assicurarci che il traffico abbia davvero colpito l’ACL:

Consigli utili per le ACL

Questi sono alcuni consigli per aiutare l’implementazione delle ACL:

• Siccome l’abbinamento su un’ACL si ferma una volta che una voce viene abbinata, metti le voci più specifiche in cima all’ACL e quelle più generiche sotto.
  Per esempio, se si mette la:

  deny icmp any any

  voce prima della

  permit icmp host 1.1.1.1 any

  voce, il traffico ICMP dall’host 1.1.1.1 host sarà anch’esso negato.

• Siccome le ACL sono ricercate dall’alto verso il basso, dovresti mettere il tuo traffico con più probabilità di essere abbinato verso l’alto dell’ACL. Questo ridurrà il tempo di ricerca e il consumo di risorse.
• Puoi usare i commenti per rendere le tue ACL più leggibili, cioè in modo che tu possa capire cosa fa una particolare voce e perché è lì.
• Per quanto possibile, applica una ACL il più vicino possibile alla sorgente del traffico. Non ha senso che il traffico attraversi tutta la rete solo per essere negato. Nota che questo suggerimento potrebbe non essere applicabile per le ACL standard.
• Se te lo puoi permettere, applica una ACL in entrata invece che in uscita. Questo perché i pacchetti sono già processati (ad esempio la ricerca nella tabella di routing) prima di essere controllati attraverso un’ACL in uscita. Perché sprecare risorse di elaborazione solo per poi abbandonare il traffico? Naturalmente, ci sono momenti in cui questo non può essere evitato.

Conclusione

Questo ci porta alla fine di questo articolo in cui abbiamo esaminato le Access Control List in dettaglio, concentrandoci su come sono usate per il filtraggio della rete. Abbiamo visto che le ACL sono composte da Access Control Entries (ACEs) che permettono o negano il traffico in base a certi criteri.

Abbiamo discusso le regole di elaborazione delle ACLs: dall’alto verso il basso; fermarsi una volta che viene fatta una corrispondenza. Abbiamo anche visto come le ACL possono essere applicate alle interfacce sia in entrata che in uscita. Infine, abbiamo visto un caso di studio sull’implementazione delle ACL sui dispositivi Cisco IOS insieme a suggerimenti utili.