Archivi tag: ip inspect

Lavorare con le ACL Cisco

Premesso che di ACL Cisco ne esistono una miriade, le tre tipologie più utilizzate sono le seguenti:

1) standard;

2) estese;

3) nominali.

Esse si differenziano per le funzionalità che offrono e per il tipo di filtraggio che possono mettere in atto.

 

timthumb.php.png

Ad esempio, le ACL standard (il cui ID può essere compreso tra 1 e 99) consentono di filtrare il traffico relativo ad una determinata sorgente. Eccone un esempio:

access-list 1 permit 172.16.0.0 0.0.255.255

Le ACL estese (ID da 100 a 199), invece, consentono di specificare sorgente e destinazione del traffico, oltre al tipo di protocollo che deve essere filtrato. Ad esempio:

 access-list 101 deny tcp 172.16.2.0 0.0.0.255 172.16.4.0 0.0.0.255 eq 21
 access-list 101 permit ip 172.16.3.0 0.0.0.255 any

nega il traffico FTP (tcp eq 21) proveniente dalla net 172.16.2.0/24 e diretto alla net 172.16.4.0/24, permette tutto il traffico (ip) proveniente dalla net 172.16.3.0/24 e nega tutto il resto (il deny any any è implicito).

Infine, le ACL nominali offrono le stesse funzionalità delle ACL estese, ma anzichè essere caratterizzate da un ID, può essere assegnato loro un nome. Inoltre, se un’ACL nominale deve essere aggiornata, non è necessario rimuoverla completamente, ricrearla con le opportune modifiche e ricaricarla sul dispositivo Cisco, ma è sufficiente aggiungere la nuova regola in una posizione ben precisa. Ad esempio, date le seguenti regole associate all’ACL nominale chiamata inbound:

 access-list inbound line 1 permit tcp any host 192.168.1.1 eq 4662
 access-list inbound line 2 permit udp any host 192.168.1.1 eq 4666

se volessimo aggiungere una regola in posizione 2, basterebbe scrivere:

access-list inbound line 2 permit tcp any host 192.168.1.1 eq 6881

e dopo uno sh access-list inbound otterremo il seguente output:

 access-list inbound line 1 permit tcp any host 192.168.1.1 eq 4662
 access-list inbound line 2 permit tcp any host 192.168.1.1 eq 6881
 access-list inbound line 3 permit udp any host 192.168.1.1 eq 4666

La posizione delle regole è molto importante nelle ACL, in quanto esse seguono una logica top-down e si arrestano al primo hit.

Se ad esempio definissimo un’ACL del tipo:

 access-list inbound line 1 permit tcp any host 192.168.1.1 eq 4662
 access-list inbound line 2 deny tcp any host 192.168.1.1 eq 4662
 access-list inbound line 3 permit udp any host 192.168.1.1 eq 4666

il traffico tcp diretto alla porta 4662 dell’host 192.168.1.1 sarebbe consentito, e la entry immediatamente successiva verrebbe completamente ignorata.

Un’altra comodità delle ACL nominali è data dalla possibilità di cancellare solo una determinata regola. Ad esempio, mediante il comando:

no access-list inbound line 2 deny tcp any host 192.168.1.1 eq 4662

verrebbe rimossa solo la regola numero 2 e non l’intera ACL (come accadrebbe se utilizzassimo un’ACL standard o estesa).

Assegnazione dell’ACL ad un’interfaccia

Una volta creata l’ACL sarà necessario assegnarla ad un’interfaccia.

Il comando da utilizzare è il seguente:

Router(config-if)# ip access-group <ID o nome ACL> in

per filtrare il traffico in ingresso, oppure:

Router(config-if)# ip access-group <ID o nome ACL> out

per filtrare il traffico in uscita.

Esiste comunque una convenzione relativa al posizionamento delle ACL, ovvero:

1) le ACL standard devono essere posizionate il più vicino possibile alla destinazione del traffico;

2) le ACL estese devono essere posizionate il più vicino alla sorgente del traffico.

Visualizzazione delle ACL

Per avere l’intera lista delle ACL presenti sulla nostra macchina, basta digitare:

Router# sh access-list

mentre se volessimo listare le regole che costituiscono una determinata ACL, occorre lanciare il comando:

Router# sh access-list <ID o nome ACL>

Con questi comandi sarà anche possibile visualizzare il numero di pacchetti che hanno matchato l’ACL (ovvero il cosiddetto hit count, e non hitch count come ho sentito dire a qualche pseudo sistemista).

Eccone un esempio:

 Router#sh access-list 101
 Extended IP access list 101
 10 deny ip host 255.255.255.255 any log
 20 deny ip 10.0.0.0 0.255.255.255 any log (33 matches)
 30 deny ip 172.16.0.0 0.15.255.255 any log
 40 deny ip 192.168.0.0 0.0.255.255 any log (7298 matches)
 50 deny ip 224.0.0.0 15.255.255.255 any log

Logging del traffico matchato dalle ACL

Abilitare il logging delle delle regole ACL matchate è banale. Basta infatti aggiungere il suffisso log alla regola stessa:

access-list 101 deny tcp 172.16.2.0 0.0.0.255 172.16.4.0 0.0.0.255 eq 21 log

Operazioni sulle ACL

Se si lavora con le ACL standard o estese è opportuno fare molta attenzione. La prima regola consiste nel disassociare l’ACL all’interfaccia, in modo da non rischiare di perdere la connettività verso il dispositivo Cisco (se stiamo interagendo con una sessione vty).

Il comando da utilizzare è il seguente:

Router(config-if)#no ip access-group <ID o nome ACL> in

In secondo luogo, conviene copiare tutto il contenuto dell’ACL ed incollarlo in un editor di testo, in modo da avere piena visione delle regole e poterle modificare con un basso margine di errore.

Logica di creazione delle ACL

Le ACL possono essere create seguendo due logiche:

1) negare esplicitamente il traffico vietato e consentire tutto il resto;

2) negare esplicitamente il traffico vietato, consentire quello lecito e negare tutto il resto.

Inutile dire che la seconda logica è molto più sicura ma implica un maggiore numero di regole. Di seguito un esempio di ACL che nega tutto il traffico non esplicitamente consentito:

 access-list 101 deny ip host 255.255.255.255 any log
 access-list 101 deny ip 10.0.0.0 0.255.255.255 any log
 access-list 101 deny ip 172.16.0.0 0.15.255.255 any log
 access-list 101 deny ip 192.168.0.0 0.0.255.255 any log 
 access-list 101 deny ip 224.0.0.0 15.255.255.255 any log
 access-list 101 permit tcp any any eq 2283 
 access-list 101 permit tcp any any eq 443 
 access-list 101 permit tcp any any eq 3000
 access-list 101 permit tcp any any eq 6881
 access-list 101 permit tcp any any eq 6882
 access-list 101 permit tcp any any eq 4662 
 access-list 101 permit udp any any eq 4666 
 access-list 101 permit udp any any eq 20
 access-list 101 permit tcp any any eq ftp 
 access-list 101 permit tcp any any eq 123
 access-list 101 permit tcp any any eq 5002
 access-list 101 permit udp any any eq 5002
 access-list 101 permit tcp any eq www any log 
 access-list 101 permit tcp any eq 443 any log
 access-list 101 permit tcp any eq ftp any log 
 access-list 101 permit udp any eq 20 any log
 access-list 101 permit tcp any eq 22 any log 
 access-list 101 permit tcp any eq 2283 any log 
 access-list 101 permit tcp any eq telnet any log 
 access-list 101 permit tcp any eq smtp any log 
 access-list 101 permit tcp any eq 465 any log 
 access-list 101 permit tcp any eq 995 any log 
 access-list 101 permit tcp any eq 993 any log 
 access-list 101 permit tcp any eq pop3 any log 
 access-list 101 permit tcp any eq domain any log
 access-list 101 permit udp any eq domain any log 
 access-list 101 permit tcp any gt 1023 any log 
 access-list 101 permit icmp any any echo-reply log

Prima nego il traffico IP spoofing, successivamente consento il traffico da Internet verso alcuni servizi della LAN, consento anche alcuni tipi di traffico della LAN verso Internet e nego tutto il resto (come già detto, il deny any any è implicito).

CBAC ed ip inspect

Alcuni device di casa Cisco possiedono un firewall embedded che crea automaticamente delle ACL (CBAC) per consentire il traffico proveniente dalla LAN e diretto all’esterno (Internet), realizzando inoltre dei meccanismi di stateful inspection. Inutile dire che tale funzionalità è molto comoda, in quanto riduce notevolmente il numero di regole ACL da dichiarare (almeno per ciò che concerne il traffico rete interna -> Internet).

Il comando per abilitare il CBAC è ip inspect (come illustrato in questo post) e per farlo funzionare occorre associarlo all’interfaccia del router che si affaccia alla rete interna (ed esempio e0), in modo da controllare il traffico in uscita:

Router(config-if)# ip inspect <nome dell'insieme delle regole di firewalling> out

Fine del post, alla prossima.

Configurazione del firewall embedded di un Cisco 827v4

Affinchè si possa realizzare la configurazione che sto per descrivere, è necessario che la IOS del nostro Cisco 827v4 supporti le funzionalità tipiche di un firewall (anche se MOLTO ridotte).

827.jpg

Nello specifico, il nome della IOS deve contenere la sigla o oppure o3, dove o sta appunto per firewall ed o3 sta per firewall/IDS. Nel mio caso, posso dirvi che ho a disposizione una IOS che supporta solo il firewall, quindi tale configurazione si limita a ciò che ho potuto effettivamente testare.

Per prima cosa accediamo alla modalità enable del router:

NightRouter>ena
Password:
NightRouter#conf t

entriamo nel menù di configurazione:

NightRouter#conf t

e creiamo le policy del nostro firewall:

NightRouter(config)#ip inspect name fw http
NightRouter(config)#ip inspect name fw ftp
NightRouter(config)#ip inspect name fw icmp
NightRouter(config)#ip inspect name fw smtp
NightRouter(config)#ip inspect name fw fragment
NightRouter(config)#ip inspect name fw rcmd

in questo modo, il nostro router terrà d’occhio i pacchetti relativi ai protocolli specificati. Esistono altri protocolli che possono essere monitorati, basta lanciare il comando:

NightRouter(config)#ip inspect name <nomepolicy> ?

per averne una lista completa.

In particolare, l’output di tale comando sarà il seguente:

  cuseeme      CUSeeMe Protocol
  fragment     IP fragment inspection
  ftp          File Transfer Protocol
  h323         H.323 Protocol (e.g, MS NetMeeting, Intel Video Phone)
  http         HTTP Protocol
  icmp         ICMP Protocol
  netshow      Microsoft NetShow Protocol
  rcmd         R commands (r-exec, r-login, r-sh)
  realaudio    Real Audio Protocol
  rpc          Remote Prodedure Call Protocol
  rtsp         Real Time Streaming Protocol
  sip          SIP Protocol
  skinny       Skinny Client Control Protocol
  smtp         Simple Mail Transfer Protocol
  sqlnet       SQL Net Protocol
  streamworks  StreamWorks Protocol
  tcp          Transmission Control Protocol
  tftp         TFTP Protocol
  udp          User Datagram Protocol
  vdolive      VDOLive Protocol

Successivamente, si dovrà associare la policy di firewalling all’interfaccia dia0, ovvero quella direttamente esposta su Internet.

Il comando da utilizzare è il seguente:

NightRouter(config)#int dia0
NightRouter(config-if)#ip inspect fw in

Infine, salviamo la configurazione con il classico copy run start:

NightRouter(config)#exit
NightRouter#copy run start

ed abbiamo finito.

A presto.

NB: dai test che ho effettuato sembrerebbe che il router non riesca a gestire correttamente una grande mole di traffico dopo aver abilitato il firewall. Proprio per questo motivo, vi consiglio di non ispezionare il payload dei pacchetti ma soltanto l’header degli stessi, evitando ad esempio delle policy del tipo:

NightRouter(config)#ip inspect name fw tcp

oppure

NightRouter(config)#ip inspect name fw udp