.. meta:: :language: it :description language=it: Networking Fundamentals: access control list :description language=en: Networking Fundamentals: access control list :keywords: Networking Fundamentals, access control list, acl :author: Luciano De Falco Alfano P2/7 Access Control List ========================= .. contents:: :local: 7.0 introduzione -------------------- 7.0.1 benvenuto ^^^^^^^^^^^^^^^^^^^^ **7.0.1.1 capitolo 7: Access Control Lists**. Nei router Cisco con le ACL è possibile configurare un semplice firewall che regola l'accesso al traffico dati. Le ACL permettono, o negano, il passaggio del pacchetto secondo regole definite. **7.0.1.2 scenario: permettimi di assisterti** 7.1 operatività delle ACL ----------------------------- 7.1.1 scopo delle ACL ^^^^^^^^^^^^^^^^^^^^^^ **7.1.1.1 cosa è una ACL**? una serie di comandi che controllano se un router inoltra o scarta pacchetti, in base ad informazioni presenti nell'header. Le ACL possono: * limitare il traffico di rete migliorando le prestazioni; * permettere il controllo del flusso del traffico [#]_; * fornire un livello base di sicurezza per l'accesso alla rete; * filtrare il traffico in base alla sua tipologia; * controllare l'accesso a determinati servizi di rete, ad es. permettere o negare l'accesso ad un determinato tipo di file. Oltre al controllo del traffico, le ACL possono effettuare anche altri tipi di azioni. Ad es. abilitare il processamento prioritario di pacchetti. **7.1.1.2 filtraggio dei pacchetti** (*packet filtering*). Una ACL è formata da un elenco di entries (*Access Control Entry*: ACL). Ognuna di queste è una affermazione che permette o nega una azione. Una ACL è processata in ingresso o in uscita di una interfaccia. Il router confronta il pacchetto che impegna l'interfaccia con la sequenza di ACE che formano la ACL. La prima ACE che viene riscontrata dal pacchetto viene eseguita, ignorando le ACE successive. Una ACL si conclude **sempre** con una ACE *implicita* che nega il processamento del pacchetto. Quindi una ACL senza almeno una ACE che permetta il traffico bloccherebbe completamente l'interfaccia cui è legata. Questo meccanismo, nel suo complesso, è detto *packet filtering*. Esistono due tipi di ACL: * **standard ACL**, in cui il meccanismo di riscontro consiste nel controllare l'indirizzo IP del mittente del pacchetto (layer 3); * **extended ACL**, il meccanismo di riscontro può essere sia a layer 3 ( IP del mittente e/o del destinatario) che a layer 4 (porta). In questo corso si studiano le *standard ACL*. **7.1.1.3 operatività di ACL**. Le ACL agiscono sui pacchetti in ingresso e uscita dal router, ma non su quelli generati dal router stesso. Una ACL, rispetto una interfaccia di rete, può essere configurata: * in **ingresso**, in tal caso è processata *prima* che il router effettui il routing del pacchetto; * in **uscita**, in questo caso viene processata dopo l'attività di routing. **7.1.1.4 packet tracer - dimostrazione di ACL** 7.1.2 *Wildcard masks* nelle ACL ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.1.2.1 introduzione al wildcard masking**. Una *wildcard mask* (wmask) ha la stessa struttura in un indirizzo IPv4: 32 bit. Nella mask i valori dei bit hanno i seguenti significati: * lo 0 indica che il corrispondente bit deve avere lo stesso valore; * l'1 indica che il corrispondente bit può avere un valore qualunque. Una *wildcard mask* viene usata insieme ad un indirizzo di rete per indicare quali parti dell'indirizzo devono essere considerate ai fini della positività del riscontro. Quindi se consideriamo l'indirizzo di rete 192.168.6.0 e la *wmask* 0.0.0.255, vogliamo considerare tutti gli indizzi IP da 192.168.6.0 a 192.168.6.255 Esistono ACL per IPv6. In questo caso non si usano le *wmask*, ma un prefix length. In questo corso le ACL per IPv6 non sono considerate. **7.1.2.2 Esempi di wmask** Nei seguenti esempi, la condizione richiede che le cifre in grassetto debbano corrispondere. +---------+-------------+---------------------------------------------+ | | dec | bin | +=========+=============+=============================================+ | IP | 192.168.1.1 | 1100 0000.1010 1000.0000 0001.0000 0001 | +---------+-------------+---------------------------------------------+ | wmask | 0.0.0.0 | 0000 0000.0000 0000.0000 0000.0000 0000 | +---------+-------------+---------------------------------------------+ | result | 192.168.1.1 | **1100 0000.1010 1000.0000 0001.0000 0001** | +---------+-------------+---------------------------------------------+ \ +--------------+-----------------+-----------------------------------------+ | | dec | bin | +==============+=================+=========================================+ | IP | 192.168.1.1 | 1100 0000.1010 1000.0000 0001.0000 0001 | +--------------+-----------------+-----------------------------------------+ | wmask | 255.255.255.255 | 1111 1111.1111 1111.1111 1111.1111 1111 | +--------------+-----------------+-----------------------------------------+ | result from | 0.0.0.0 | 0000 0000.0000 0000.0000 0000.0000 0000 | +--------------+-----------------+-----------------------------------------+ | result to | 255.255.255.255 | 1111 1111.1111 1111.1111 1111.1111 1111 | +--------------+-----------------+-----------------------------------------+ \ +--------------+---------------+---------------------------------------------+ | | dec | bin | +==============+===============+=============================================+ | IP | 192.168.1.1 | 1100 0000.1010 1000.0000 0001.0000 0001 | +--------------+---------------+---------------------------------------------+ | wmask | 0.0.0.255 | 0000 0000.0000 0000.0000 0000.1111 1111 | +--------------+---------------+---------------------------------------------+ | result from | 192.168.1.0 | **1100 0000.1010 1000.0000 0001**.0000 0000 | +--------------+---------------+---------------------------------------------+ | result to | 192.168.1.255 | **1100 0000.1010 1000.0000 0001**.1111 1111 | +--------------+---------------+---------------------------------------------+ \ +--------------+----------------+---------------------------------------------+ | | dec | bin | +==============+================+=============================================+ | IP | 192.168.16.0 | 1100 0000.1010 1000.0001 0000.0000 0000 | +--------------+----------------+---------------------------------------------+ | wmask | 0.0.15.255 | 0000 0000.0000 0000.0000 1111.1111 1111 | +--------------+----------------+---------------------------------------------+ | result from | 192.168.16.0 | **1100 0000.1010 1000.0001** 0000.0000 0000 | +--------------+----------------+---------------------------------------------+ | result to | 192.168.31.255 | **1100 0000.1010 1000.0001** 1111.1111 1111 | +--------------+----------------+---------------------------------------------+ \ +--------------+----------------+-----------------------------------------------------+ | | dec | bin | +==============+================+=====================================================+ | IP | 192.168.1.0 | 1100 0000.1010 1000.0000 0001.0000 0000 | +--------------+----------------+-----------------------------------------------------+ | wmask | 0.0.254.255 | 0000 0000.0000 0000.1111 1110.1111 1111 | +--------------+----------------+-----------------------------------------------------+ | result from | 192.168.1.0 | **1100 0000.1010 1000**.0000 000\ **1**\ .0000 0000 | +--------------+----------------+-----------------------------------------------------+ | note | . . . . . . | all networks 192.168.x.0 with x odd | +--------------+----------------+-----------------------------------------------------+ **7.1.2.4 come calcolare la wildcard mask** se il pattern da soddisfare è una subnet mask, la wmask si calcola sottraendo da 255.255.255.255 la subnet mask. Ad esempio, per dare accesso a tutti gli utenti di una rete /24, abbiamo:: 255.255.255.255 - 255.255.255. 0 = ----------------- 0. 0. 0.255 e si indica con il comando:: access-list 10 permit 192.160.10.0 0.0.0.255 Mentre con una rete /28 abbiamo:: 255.255.255.255 - 255.255.255.240 = ----------------- 0. 0. 0. 15 usando il comando:: access-list 10 permit 192.168.10.32 0.0.0.15 **7.1.2.4 parole chiave per la wildcard mask**. I seguenti pattern sono frequenti: * **0.0.0.0**, indica *solo questo* host, è abbreviabile con la parola chiave **host**; * **255.255.255.255** indica *qualunque* host, è abbreviabile con la parola chiave **any**. **7.1.2.5 esempi di parole chiave di wildcard mask**. Queste sono equivalenti:: access-list 10 permit 192.168.10.10 0.0.0.0 access-list 10 permit host 192.168.10.10 Così come sono equivalenti queste:: access-list 20 permit 0.0.0.0 255.255.255.255 access-list 20 permit any **7.1.2.6 attività - determinare la wildcard mask corretta**. **7.1.2.7 attività - determinare il permesso o la negazione**. 7.1.3 linee guida per la creazione di ACL ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.1.3.1 linee guida generali per la creazione di ACL**. Si può avere una sola ACL per: * **protocollo** (es. IPv4 o IPv6); * **interfaccia** (es. g0/0); * **direzione** (in o out). Quindi, ad es., un router con due interfacce, ognuna con due protocolli, può avere a bordo 8 ACL (2 * 2 * 2). Alcune indicazioni sono: * usa le ACL nei router firewall per proteggere la rete intera dalla esterna (Internet); * usa le ACL se devi proteggere parti della tua rete dall'accesso (o in uscita) rispetto altre parti della tua rete; * usa le ACL nei router di confine; * configura le ACL per tutti i protocolli di rete a bordo del router. **7.1.3.2 ACL best practices**: * basare le ACL sulle politiche di sicurezza dell'organizzazione; * preparare una descrizione di cosa si vuole che la ACL faccia; * usare un text editor per creare, modificare e salvare la ACL; * provare la ACL su una rete di sviluppo prima di implementarla in un ambiente di produzione. **7.1.3.3 attività - ACL operation** 7.1.4 linee guida per la disposizione delle ACL ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.1.4.1 dove mettere le ACL**. Vanno messe dove massimizzano l'efficacia operativa. In generale [#]_: * le *extended ACL* si solito vengono messe vicino la sorgente, per bloccare il traffico non permesso prima che impegni la rete; * le *standard ACL* di solito sono vicino la destinazione, perché queste riportano il solo indirizzo IP del mittente; perciò mettendole vicino al mittente, in caso di blocco, questo verrebbe tagliato fuori da *qualunque* destinazione. Altre considerazioni: * l'estensione del controllo dell'amministratore della rete (mettere una ACL in un router significa che se ne ha il controllo); * la banda passante delle reti coinvolte; * la facilità di configurazione (ad es.se si vuole schermare una sottorete da più sottoreti mittenti, ci si può mettere ficino alla destinazione, anche se così viaggiano in rete pacchetti che poi saranno scartati). **7.1.4.2 posizionamento delle standard ACL**. Nel mettere la standard ACL vicino alla destinazione, fare attenzione a non impedire l'accesso a sottoreti che devono essere raggiungibili. 7.2 standard IPv4 ACL ------------------------ 7.2.1 configurare ACL IPv4 standard ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.2.1.1 sintassi delle ACL IPv4 standard numerate**. Prima di attivare la ACL su una interfaccia, è necessario crearla con il comando:: R(config)# access-list acl-number { deny | permit | remark } source-addr [ source-wildcard ][ log ] dove *acl-number* è un numero da 1 a 99 e (da IOS rel.12.0.1 iin poi) da 1300 a 1999, per un totale di 798 ACL. Ad esempio:: R(config)# access-list 10 permit 192.168.10.0 0.0.0.255 permette la prosecuzione dei pacchetti provenienti dagli host della rete 192.168.10.0/24. L'opzione **remark** permette di commentare la ACL. Si può dare più di un comando per una ACL identificata con lo stesso numero. Una ACL si rimuove con il comando:: R(config)# no access-list acl-number. Le ACL si possono osservare con il comando:: R# show access-lists oppure con:: R# show running-config | include access-list acl-number **7.2.1.2 applicare ACL IPv4 standard alle interfacce**. Configurata una ACL, si applica ad una interfaccia con il comando:: R(config-if)# ip access-group {acl-number | acl-name} {in | out} si noti che si è nell'ambiente di configurazione dell'interfaccia voluta, ottenuto con il solito comando:: R(config)# interface interf-id Per rimuovere una ACL da una interfaccia si usa:: R(config-if)# no ip access group acl-number E per eliminare la ACL (dopo averla rimossa dall'interfaccia):: R(config)# no access-list acl-number Esempio di dichiarazione di una ACL e sua applicazione in uscita alla seriale *s0/0/0*:: R(config)# access-list 1 permit 192.168.10.0 0.0.0.255 R(config)# interface s0/0/0 R(config-if)# ip access-group 1 out **7.2.1.3 esempi di ACL IPv4 standard numerate**. **Bloccare un host e permettere una specifica sottorete**:: R(config)# no access-list 1 R(config)# access-list 1 deny host 192.168.10.10 R(config)# access-list 1 permit 192.168.10.0 0.0.0.255 R(config)# interface s0/0/0 R(config-if)# ip access-group 1 out Si noti: * l'host da bloccare è dichiarato prima del *permit* della sottorete; se non fosse così non verrebbe bloccato perché appartiene alla sottorete per cui vale il successivo *permit* [#]_; * ricordiamo che esiste sempre un implicito *deny any* alla fine della ACL, quindi qualunque altro host appartenente ad altre reti viene bloccato. **Bloccare un host**:: R(config)# no access-list 1 R(config)# access-list 1 deny host 192.168.10.10 R(config)# access-list 1 permit any R(config)# interface s0/0/0 R(config-if)# ip access-group 1 in **7.2.1.4 sintassi di ACL IPv4 standard con nome**. Si può identificare una ACL tramite un nome:: R(config)# ip access-list {standard | extended} acl-name R(config-std-nacl)# {permit | deny | remark} {source-addr [wildcard]} [log] Nota: * a differenza di una ACL individuata da un numero, questo comando comincia con **ip**; * il *acl-name* è alfanumerico, case sensitive, deve essere univoco e *non può cominciare* con un numero; * si entra in modalità di configurazione di una *standard* (std) *named acl* (nacl), come indicato dal prompt di sistema. Dopo di che, per legarla ad una interfaccia, si deve selezionare l'interfaccia e poi:: R(config-if)# ip access-group name {in | out} Ad esempio:: R(config)# ip access-list standard NO_ACCESS R(config-std-nacl)# deny host 192.168.11.10 R(config-std-nacl)# permit any R(config-std-nacl)# exit R(config)# interface g0/0 R(config-if)# ip access-group NO_ACCESS out **7.2.1.5 attività - configurare ACL IPv4 standard** **7.2.1.6 packet tracer - configurare ACL IPv4 Standard numerate** **7.2.1.7 packet tracer - configurare ACL IPv4 Standard con nome** 7.2.2 modificare ACL IPv4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.2.2.1 metodo 1 - usare un text editor**. Come segue: * visualizzare la ACL con *show running-config*; * copiarla dal terminale all'editor; * modificarla nell'editor [#]_; * copiarla dall'editor al terminale; * verificare le modifiche con *show running-config*. Nella fase di modifica/correzione nell'editor si metta in testa il comando *no access-list acl-num* perchè quando si copierà dall'editor al terminale, si dovrà creare la ACL ex novo. Il comando *no access-list acl-num* può essere gestito in modo diverso dalle diverse versioni di IOS. Se la ACL viene cancellata senza essere stata slegata dall'interfaccia, in alcuni casi IOS ignora la ACL permettendo il passaggio di tutti i pacchetti. In altri casi blocca il passaggio di tutti i pacchetti. Quindi è bene svincolare la ACL dall'interfaccia prima di cancellarla, in tal modo si avrà sempre omogeneamente il primo comportamento: passano tutti i pacchetti. **7.2.2.2 metodo 2 - usare i sequence number**. Come segue: * visualizzare la ACL con *show access-list acl-number* e prendere nota dei *sequence number* mostrati in testa alle righe da modificare; * eseguire *ip access-list standard acl-number* per entrare in modalità di configurazione della ACL, indicata dal prompt *config-std-nacl*; * cancellare gli statement da modificare con il comando *no seq-number* [#]_; * aggiungere gli statement voluti con il comando *seq-number {permit|deny} {source-addr [wildcard]}*. Esempio: modificare lo statement *10 deny 192.168.10.99* in *10 deny 192.168.10.10*:: R(config)# ip access-list standard 1 R(config-std-nacl)# no 10 R(config-std-nacl)# 10 deny host 192.168.10.99 R(config-std-nacl)# end **7.2.2.3 modificare ACL standard con nome**. Si utilizzano i *sequence number* come nel precedente 7.2.2.2. Ad esempio, per aggiungere uno statement che impedisca l'accesso a *192.168.11.11*:: R# show access-lists Standard IP access list NO_ACCESS 10 deny 192.168.11.10 20 permit 192.168.11.0, wildcard bits 0.0.0.255 R# conf t ... R(config)# ip access-list standard NO_ACCESS R(config-std-nacl)# 15 deny host 192.168.11.11 R(config-std-nacl)# do show access-lists Standard IP access list NO_ACCESS 10 deny 192.168.11.10 15 deny 192.168.11.11 20 permit 192.168.11.0, wildcard bits 0.0.0.255 **7.2.2.4 verificare le ACL standard**. Per verificare se ad una interfaccia è legata una ACL si utilizza il comando:: R# show ip interface intf-id Ad esempio:: R# show ip interface s0/0/0 Serial0/0/0 is up, line protocol is up Internet address is 10.1.1.1/30 ... Outgoing access list is 1 Inbound access list is not set ... Le linee *outgoing ...* e *inbound ...* indicano se vi sono ACL associate, e quali sono. Il comando:: R# show access-lists invece elenca tutte le ACL definite, sia *numbered* che *named*, e le loro definizioni. **7.2.2.5 Statistiche delle ACL**. Il comando:: R# show access-lists elenca le ACL configurate, visualizza le regole che le compongono, e visualizza anche le statistiche di utilizzo, intese come numero di match positivi. La regola implicita *deny any* sempre presente in coda ad una ACL non viene mostrata. Per visualizzare le sue statistiche andrebbe impostata esplicitamente. I contatori statistici possono essere azzerati con il comando:: R# clear access-list counters [acl-number] **7.2.2.6 lab - configurare e modificare ACL IPv4 standard** 7.2.3 Proteggere porte VTY con una ACL IPv4 standard ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.2.3.1 il comando access-class**. Si può aumentare la sicurezza delle porte VTY limitandone l'accesso ad indirizzi IP specifici tramite il comando:: R(config-line)# access-class acl-number {in [vrf-also] | aout} Ad esempio:: R(config)# access-list 21 permit 192.168.10.0 0.0.0.255 R(config)# access-list 21 deny any R(config)# line vty 0 15 R(config-line)# login local R(config-line)# transport input ssh R(config-line)# access-class 21 in oltre a imporre l'uso di ssh, limita l'accesso alle macchine appartenenti alla rete 192.168.10.0/24. Qundo si usa il comando *access-class*: * è possibile utilizzare sia ACL con nome che con numero; * è necessario imporre la stessa limitazione a tutte le VTY perché un utente può tentare un collegamento con una qualunque di esse; * una ACL non si applica a pacchetti generati nel router, quindi questa tecnica non limita connessioni remote iniziate dal router. **7.2.3.2 verificare che una porta VTY sia protetta**. Dopo avere applicato la protezione tramite ACL alla porta VTY, è necessario controllare che funzioni come previsto utilizzando indirizzi IP che possono accedere e indirizzi IP che non possono farlo. Per questo è utile consultare le statistiche mostrate dal comando *show access-lists*. **7.2.3.3 packet tracer - configurare una ACL IPv4 su linee VTY** **7.2.3.4 lab - configurare e verificare limitazioni VTY** 7.3 diagnosticare le ACL ------------------------- 7.3.1 Processare pacchetti con le ACL ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **7.3.1.1 Il deny any implicito**. Una ACL con sole *deny* blocca cmpletamente il traffico a causa del *deny any* implicito sempre presente in coda alla ACL. Vi deve essere almeno una *permit* nella ACL. **7.3.1.2 l'ordine delle ACE in una ACL**. L'ordine delle ACE che compongono una ACL è importante perché sono processate sequenzialmente. D'altro canto l'ordine delle ACE è stabilito secondo una logica imposta dal sistema operativo del router. Come prima regla: un subset di una rete non può essere successivo alla ACE che gestisce la rete. Aq esempio, questo non viene accettato: R(config)# access-list 3 deny 192.168.10.0 0.0.0.255 R(config)# access-list 3 permit host 192.168.10.10 perché la seconda regola riguarda un host (sottoinsieme) della rete 192.168.10.0/24 gestita nella regola che la precede. L'ordine inverso sarebbe accettabile. Così come lo sarebbe una regola riguardante un host appartenente ad una rete diversa. **7.3.1.3 Cisco IOS riordina le ACL standard**. L'ordine con cui le ACE sono inserite, può essere diverso da quello con cui sono memorizzate e processate. In generale, il *sequence number* di una ACE riflette l'ordine con cui una regola viene inserita. Ma l'ordine di esecuzione non è quello del *sequence number*. L'ordine di esecuzione viene indicato dall'output del comando *show access-lists acl-number*. E il Cisco IOS riordinerà mettendo in testa le regole riguardanti gli host, e secondo una apposita funzione di hash, e successivamente quelle delle reti. Queste ultime secondo l'ordine di inserimento. Per fare in modo che *sequence number* e ordine di esecuzione collimino, si può salvare la configurazione corrente in quella di startup e poi effettuare un *reload*. **7.3.1.4 Il processo di routing e le ACL** è illustrato nel seguente diagramma: .. image:: ./images/03_acl_routing.svg **7.3.2.1 Troubleshooting ACL IPv4 standard - esempio 1**. Gli errori più comuni consistono nell'inserire le ACE nell'ordine sbagliato, o specificare ACE non adeguate. Altri errori consistono nell'applicare la ACL nella direzione errata, o all'interfaccia errata, o sbagliare l'indirizzo sorgente. L'uso del comando *show access-list* è lo strumento principale per indagare questi problemi. **7.3.2.2 Troubleshooting ACL IPv4 standard - esempio 2**. Se il comando *show access-list* mostra una sequenza di ACE nell'ordine corretto e adeguate, allora è necessario investigare l'interfaccia con il comando:: R# show running-config | section interface per verificare se la ACL è applicata all'interfaccia e nel verso giusti. **7.3.2.3 Troubleshooting ACL IPv4 standard - esempio 3**. In ogni caso verificare con attenzione che non vi siano errori di digitazione o di scopo negli indirizzi che specificano le sorgenti. **7.3.2.4 packet tracer - Troubleshooting ACL IPv4 standard** 7.4 Sommario ------------- 7.4.1 conclusione ^^^^^^^^^^^^^^^^^^^^^^ **7.4.1.1 class activity - FTP negato** **7.4.1.2 packet tracer - sfida per l'integrazione degli skill** **7.4.1.3 capitolo 7: Access Control Lists** ----------------- .. [#] ad es. accettare update del routing solo da determinate sorgenti .. [#] queste sono le regole cui attenersi per il CCENT e il CCNA. .. [#] ricordiamo che il parser delle ACL si ferma alla prima regola che corrisponde, ignorando le successive. .. [#] Attenzione al fatto che la modifica nell'editor usualmente non si limita alla ACE da modificare. Tipicamente vi saranno anche una serie di comandi *spuri* che vanno eliminati. .. [#] la cancellazione dello statement prima della sua riscrittura è fondamentale: non si può modificare direttamente uno statement esistente.