martedì, Aprile 23, 2024

ACL: esercizio di laboratorio

Paolo Impellizzeri
Paolo Impellizzeri
Trentanove anni, diplomato in elettronica con specializzazione in sistemi di automazione, nell'arco di quasi venti anni ha maturato esperienze lavorative nel campo dell' informatica e delle telecomunicazioni presso diverse aziende palermitane. Attualmente è System & Network Administrator presso un'azienda che si occupa di progettazione, realizzazione e manutenzione di reti LAN e sistemi di telecomunicazioni e sicurezza. Ha conseguito la certificazione CCNA nel 2007.

In questo esercizio si vogliono implementare politiche di sicurezza nella rete in figura tramite l’utilizzo di access list (ACL).
Si tenga presente che le seguenti soluzioni non sono le uniche applicabili: come spesso accade nel mondo dell’informatica e delle telecomunicazioni, possono esistere diverse soluzioni allo stesso problema.

ACL: esercizio di laboratorio

Utilizzo di access list estese

RTD(config)#access-list 100 permit tcp 192.25.0.0 0.0.0.127 192.168.1.1 0.0.0.0 eq telnet
RTD(config)#access-list 100 deny tcp 192.25.0.0 0.0.0.255 any eq telnet
RTD(config)#access-list 100 permit ip any any
RTD(config)#interface Ethernet0
RTD(config-if)#ip access-group 100 in

Una convenzione Cisco prevede che le access list estese siano applicate quanto più possibile vicino alla sorgente del traffico da controllare.
In questo caso si vuole che alla metà inferiore della rete 192.25.0.0/24 sia consentito il telnet solo verso RTC. Ecco perchè la access list viene applicata all’interfaccia Ethernet 0 di RTD tramite il comando ip access-group 100 in.
Nel primo statement si consente l’impegno dell’interfaccia Ethernet 0 del router in ingresso al traffico telnet originato dalla metà inferiore della network (da 192.25.0.1 a 192.25.0.127) verso RTC.
Nel secondo statement il resto del traffico telnet (quello generato dalla metà inferiore della rete ma indirizzato a direzioni diverse da RTC e quello generato dalla metà superiore della rete) viene bloccato.
Il terzo statement consente il restante traffico IP.
N. B.
A questo punto il traffico telnet è stato filtrato, ma il sistema ha una falla di sicurezza: nulla impedisce ad un host facente parte della metà inferiore della rete 192.25.0.0 di connettersi in telnet a RTC e da questo eseguire terminali remoti verso gli altri router. Una soluzione a questo problema viene proposta nella sezione Utilizzo di access list standard.

Per consentire l’accesso al server TFTP 192.168.0.31 solo a RTC, è necessario in questo caso contravvenire alla convenzione Cisco di cui sopra; infatti se, come vuole la convenzione, l’access-list venisse applicata in uscita sulla interfaccia seriale di RTC verso RTB, sia RTA ch RTB potrebbero accedere al server TFTP.

In questo caso quindi è necessario applicare una access list estesa (in modo da poter controllare il protocollo e la destinazione) sull’interfaccia Ethernet 0 di RTA che permetta il traffico TFTP solo con source IP address 15.0.0.2 (l’interfaccia seriale di RTC) e destination IP address 192.168.0.31 (il server TFTP):

RTA(config)#access-list 100 permit udp host 15.0.0.2 host 192.168.0.31 eq tftp
RTA(config)#access-list 100 deny udp any any eq tftp
RTA(config)#access-list 100 permit ip any any
RTA(config)#interface Ethernet0
RTA(config-if)#ip access-group 100 out

Utilizzo di access list standard

Tramite l’utilizzo del comando access-class è possibile applicare una access-list non ad una interfaccia, bensì ai terminali virtuali di un router:

RTA(config)#access-list 1 deny any
RTA(config)#line vty 0 4
RTA(config-line)#access-class 1 in

Applicando questa access list su RTA, RTB ed RTD è possibile risolvere il problema di sicurezza precedentemente discusso.

Articoli correlati

Non perdere il lancio online della Community GDPR Day: 26 marzo 2024

La sicurezza dei dati e delle informazioni non è più un'opzione, ma una necessità imprescindibile. Lo dimostrano i tanti attacchi informatici che, con frequenza...

Digital Transformation


 

Noleggia una Tesla per il tuo evento ICT!

Categorie