Archivi tag: cisco

Configurare un firewall Cisco PIX 501

Abbiamo già visto come configurare il router Cisco SOHO 77 (alias Cisco 827). Adesso vedremo come proteggere la nostra LAN configurando un firewall di casa Cisco, ovvero il PIX 501 (vedi immagine sottostante).

product-601333.jpg

Per prima cosa settiamo il nome ed il livello di sicurezza associato all’interfaccia esterna ed all’interfaccia interna che stiamo utilizzando (dopo essere entrati nella modalità di configurazione digitando i comandi ena e successivamente conf t):

pixfirewall(config)# nameif ethernet0 outside security0

pixfirewall(config)# nameif ethernet1 inside security100

Come potete facilmente notare, l’interfaccia ethernet0 l’abbiamo chiamata “outside” e ad essa abbiamo associato il livello di sicurezza “security0”. Discorso simile riguarda l’interfaccia ethernet1.

Impostiamo ora la velocità delle interfacce precedentemente menzionate:

pixfirewall(config)# interface ethernet0 auto

pixfirewall(config)# interface ethernet1 100full

Nella fattispecie, l’interfaccia esterna negozia automaticamente la velocità in base al dispositivo ad essa collegato, mentre l’interfaccia interna lavora alla velocità di 100 Mbit/sec in full duplex.

Impostiamo la password per la modalità enable:

pixfirewall(config)# enable password <vostrapass>

Tale password verrà salvata all’interno del file di configurazione in forma cifrata.

Definiamo l’hostname per il nostro firewall:

pixfirewall(config)# hostname <hostname_del_firewall>

Associamo all’interfaccia esterna ed a quella interna i rispettivi indirizzi IP e subnet mask:

pixfirewall(config)# ip address outside 192.168.100.2 255.255.255.252

pixfirewall(config)# ip address inside 172.30.4.1 255.255.255.0

Ovviamente la scelta della classe privata di indirizzi IP e della relativa maschera di sottorete è a vostra discrezione.

Definiamo adesso l’ARP timeout, ovvero ogni quanti secondi la tabella dei MAC address appartenente al nostro firewall deve essere svuotata:

pixfirewall(config)# arp timeout 14400

Definiamo, inoltre, la cosiddetta MTU, ovvero la massima dimensione dei pacchetti che possono transitare attraverso l’interfaccia:

pixfirewall(config)# mtu outside 1500

pixfirewall(config)# mtu inside 1500

Ora è necessario andare a mettere mano su una delle parti più delicate della nostra configurazione, ovvero il NAT. Tramite il NAT, infatti, sarà possibile tradurre un indirizzo privato appartenente alla nostra rete in un indirizzo pubblico, permettendoci di navigare ed accedere alle risorse dislocate su Internet. Per fare ciò occorre digitare:

pixfirewall(config)# global (outside) 1 interface

pixfirewall(config)# nat (inside) 1 172.30.4.0 255.255.255.0

In questo modo stiamo imponendo al firewall di tradurre gli indirizzi privati appartenenti alla LAN interna (172.30.4.0/24) nell’indirizzo associato all’interfaccia esterna, ovvero 192.168.100.2. Sarà il router, successivamente, ad effettuare un nuovo NAT sull’indirizzo privato dell’interfaccia outside, traducendolo nell’indirizzo pubblico assegnatoci dall’ISP.

Per poter uscire su Internet è inoltre necessario definire nell’ambito del firewall una rotta statica mediante il seguente comando:

pixfirewall(config)# route otuside 0.0.0.0 0.0.0.0 192.168.100.1

In questo modo stiamo dicendo al firewall di instradare tutto il traffico destinato ad un indirizzo non presente all’interno della sua tabella di routing verso l’indirizzo 192.168.100.1, ovvero il router. Sarà quindi compito del router, tramite una nuova default route, far si che il traffico venga indirizzato verso l’esterno.

Ora, supponiamo che all’interno della nostra LAN sia presente una risorsa (ad esempio un WEB server) che debba essere necessariamente contattabile dall’esterno. Ovviamente, la cosa migliore da fare in questo caso sarebbe quella di posizionare il server nella DMZ ma per semplicità tale server verrà dislocato nell’ambito della LAN stessa.

L’indirizzo IP del server è 172.30.4.2, quindi occorrerà digitare:

pixfirewall(config)# static (inside, outside) 192.168.100.2 172.30.4.2 netmask 255.255.255.0 0 0

dove l’indirizzo IP dell’interfaccia outside deve essere inserito sempre PRIMA dell’indirizzo privato associato al server.

Definiamo adesso il tipo di traffico che deve essere accettato in ingresso all’interfaccia esterna. E’ possibile fare ciò mediante un’ACL nominale:

pixfirewall(config)# access-list inbound permit tcp any host 192.168.100.2 eq 80

pixfirewall(config)# access-list inbound permit icmp any host 192.168.100.2

In tal modo il nostro Web server potrà essere contattato attraverso la porta 80 e risponderà ai ping eseguiti dall’esterno. Non ci resta che associare l’ACL appena creata all’interfaccia di interesse:

pixfirewall(config)# access-group inbound in interface outside

Sarebbe utile, inoltre, consentire la gestione da remoto del firewall, senza doversi collegare necessariamente a tale dispositivo mediante cavo console (altrimenti conosciuto come rollover). Per fare ciò è necessario abilitare Telnet:

pixfirewall(config)# telnet 172.30.4.0 255.255.255.0 inside

ovvero stiamo imponendo al firewall di accettare esclusivamente le connessioni telnet provenienti dall’interfaccia interna, nella fattispecie dagli host della LAN.

pixfirewall(config)# telnet timeout 5

con questo comando il firewall chiuderà qualunque sessione Telnet dopo 5 minuti di inattività.

Occorre notare che il nostro firewall (per default) non permette il transito di echo-reply provenienti dall’interfaccia “outside” e dirette verso l’interfaccia “inside”. Ciò significa che qualunque ping originato dalla LAN e diretto verso l’esterno non potrà ricevere risposta. Per evitare ciò, basta insirire le seguenti regole all’ACL “inbound” precedentemente creata:

 access-list inbound permit icmp any any echo-reply
 access-list inbound permit icmp any any time-exceeded
 access-list inbound permit icmp any any unreachable
 access-list inbound permit icmp any any source-quench

Bene, salviamo la nostra configurazione ed il gioco è fatto:

write memory

La guida termina qui. Nei prossimi post vedremo come gestire il nostro firewall mediante PDM (PIX Device Manager). A presto.

 

Irrobustire le difese del nostro router Cisco SOHO

Abbiamo già visto nei precedenti post come configurare il nostro router per i protocolli PPPoA e PPPoE. Adesso vediamo quali sono le possibili tecniche per difenderlo da eventuali attacchi di bruteforce, IP spoofing o di tipo Denial of Service (DoS).

Messa in sicurezza delle connessioni Telnet

Il nostro router Cisco consente (per default) la connessione sulla porta 23 (Telnet) anche da host esterni alla nostra rete (ovvero da Internet), rendendolo soggetto ad eventuali attacchi di bruteforce.

Un modo per evitare che ciò avvenga è creare un ACL apposita che permetta la connessione al router via Telnet esclusivamente dagli host della nostra rete. Supponiamo quindi che la nostra LAN comprenda 6 indirizzi utilizzabili, ovvero 192.168.1.1 (il router), 192.168.1.2, 192.168.1.3, 192.168.1.4, 192.168.1.5, 192.168.1.6. Come avrete notato la subnet mask utilizzata è una /29 (255.255.255.248), la quale comprende in tutto 8 indirizzi di cui solo 6 possono essere assegnati agli host (il primo indirizzo indentifica la nostra rete, ovvero 192.168.1.0, mentre l’indirizzo 192.168.1.7 rappresenta il broadcast).

Detto ciò, non ci resta che definire l’ACL, digitando:

NightRouter(config)#access-list 1 permit 192.168.1.0 0.0.0.7

Tramite questo comando abbiamo creato l’ACL standard identificata dal numero 1 che permette l’accesso agli host appartenenti alla nostra LAN. Per fare ciò abbiamo dovuto specificare sia l’indirizzo di rete (192.168.1.0) che la wildmask (0.0.0.7). Quest’ultima rappresenta la parte fissa dell’indirizzo mediante degli zeri, mentre la parte variabile viene indicata attraverso il massimo valore intero rappresentabile dai bit che verranno utilizzati per formare l’indirizzo IP degli host.

Ad esempio, nel nostro caso, una /29 indica che su 32 bit (dimensione di un indirizzo IPv4) 29 costituiscono la maschera, mentre gli ultimi 3 concorrono a costituire gli indirizzi IP degli host. Sappiamo che il valore intero massimo rappresentabile mediante questi bit è pari a 7. Ergo la wildmask sarà pari a 0.0.0.7.

Discorso analogo va fatto per la classe A di indirizzi privati, ovvero la 10.0.0.0/8. In questo caso abbiamo 8 bit che costituiscono la subnet mask mentre gli altri 24 verranno utilizzati per assegnare gli indirizzi IP agli host. Dunque quale sarà la wildcard mask? Semplice: 0.255.255.255.

Per gli indirizzi di classe B privati, che vanno da 172.16.0.0/16 a 172.31.255.255/16 abbiamo la seguente wildcard: 0.15.255.255. Infine, per gli indirizzi privati di classe C, ovvero 192.168.1.0/24, 192.168.2.0/24 e così via possiamo utilizzare questa wildmask:

0.0.255.255

associata all’indirizzo 192.168.0.0, ovvero un indirizzo privato di classe C adattato a classe B, in modo tale che con una sola wildmask vengano interessate tutte le possibili reti private di classe C.

Questa spiegazione ci tornerà utilie quando andremo ad implementare le regole per difenderci dall’IP spoofing.

Tornando alla nostra ACL, è necessario che essa venga associata al servizio Telnet, che negli apparati Cisco prende il nome di vty. Per fare ciò basta digitare:

NightRouter(config)# line vty 0 4

NightRouter(config-line)# access-class 1 in

NightRouter(config-line)# exit

Come avrete facilmente intuito è il comando access-class che associa l’ACL standard 1 in ingresso al terminale Telnet.

Sicuramente a questo punto vi starete chiedendo: perchè ho definito un ACL che permette l’accesso via Telnet sul router agli host della mia LAN se poi non ho definito alcuna regola per vietare l’accesso a tutti gli altri host?

Semplice, ogni ACL nel momento in cui viene creata ha come regola implicita il deny any, quindi tutti gli altri host vengono automaticamente esclusi da ogni possibilità di accesso.

Misure contro L’IP Spoofing

Bene, il nostro terminale Telnet è finalmente al sicuro. Vediamo ora come fare per difenderci dall’IP spoofing, tecnica che prevede l’alterazione dell’IP sorgente presente all’interno dei pacchetti, in modo da aggirare i controlli effettuati dal router attraverso le ACL.

Una prima difesa contro questo attacco consiste essenzialmente nel creare un’ACL estesa in cui definire tutti gli indirizzi IP che non possono accedere al router mediante l’interfaccia connessa ad internet (Dialer0).

Passiamo quindi alla creazione dell’ACL:

NightRouter(config)# access-list 101 deny ip 10.0.0.0 0.255.255.255 any log

Mediante questo comando stiamo creando l’access list estesa (identificata dal numero 101) che nega qualsiasi pacchetto facente uso del protocollo IP proveniente dalla net 10.0.0.0/8 e diretto verso qualunque host della nostra rete.

Aggiungiamo altre regole alla nostra ACL:

NightRouter(config)# access-list 101 deny ip 172.16.0.0 0.15.255.255 any log

NightRouter(config)# access-list 101 deny ip 192.168.0.0 0.0.255.255 any log

NightRouter(config)# access-list 101 deny ip host 127.0.0.1 any log

NightRouter(config)# access-list 101 deny ip host 255.255.255.255 any log

NightRouter(config)# access-list 101 deny ip 224.0.0.0 15.255.255.255 any log

NightRouter(config)# access-list 101 permit ip any any log

Quest’ultima regola consente l’accesso a tutti gli altri host non esplicitamente negati nell’ambito delle regole precendenti.

Facciamo ora alcune piccole considerazioni:

1) Il termine “host” utilizzato nell’ambito delle regole 4 e 5 indica all’ACL che l’indirizzo da negare è soltanto uno, ovvero, rispettivamente, 127.0.0.1 (localhost) nel caso della regola numero 4 e 255.255.255.255 (broadcast) nel caso della regola numero 5. In alternativa avrei potuto usare la wildmask 0.0.0.0 immediatamente dopo l’indirizzo IP, ad esempio:

NightRouter(config)# access-list 101 deny ip 127.0.0.1 0.0.0.0 any log

NightRouter(config)# access-list 101 deny ip 255.255.255.255 0.0.0.0 any log

2) Per ciò che concerne, invece, la numerazione delle ACL, quelle standard vanno numerate da 1 a 99 e quelle estese da 101 a 199 (esistono comunque altri range utilizzabili per entrambe le tipologie di ACL).

3) Infine, è bene notare che le regole vengono applicate dal router in ordine sequenziale, ovvero dalla prima all’ultima. Quindi, se un dato pacchetto rispetta una regola, quelle immediatamente successive verranno ignorate. A tal proposito facciamo un piccolo esempio:

NightRouter(config)# access-list 101 permit ip any any

NightRouter(config)# access-list 101 deny 82.11.199.188 any any

Quest’ultima regola verrà palesemente ignorata dal router, in quanto abbiamo già permesso l’accesso indistinto a tutti i pacchetti.

PS: il termine log presente alla fine di ogni regola associata all’ACL indica al router di loggare tutti i pacchetti che sono stati scartati da essa.

Un piccolo trucco: quando definite il permit ip any any in un’ACL siate certi di aver negato tutti gli host ai quali non volete permettere l’accesso, anche perchè non è possibile (sia per le ACL standard che per quelle estese) andare a rimuovere una singola regola (se ad esempio digitiamo il comando no access-list 101 permit ip any any viene rimossa l’intera ACL).

Comunque, per sopperire a tale limitazione, le IOS più recenti hanno introdotto le ACL nominali, in cui è prevista la cancellazione di una o più regole specifiche.

Associamo tale ACL in ingresso all’interfaccia Dialer0, ovvero quella direttamente connessa ad Internet:

NightRouter(config)# int dia0

NightRouter(config-if)# ip access-group 101 in

Difesa contro gli attacchi di tipo DoS (Smurfing)

smurf-attack.jpg

 

Bene, ora non ci resta che difendere il nostro router dagli attacchi di tipo DoS. Per prima cosa occorre prendere delle contromisure contro lo smurfing. Tale tecnica coinvolge almeno tre tipi di attori: l’host dell’attaccante (A), uno o più host della nostra LAN (B) e l’host vittima (C). Nella fattispecie, l’host dell’attaccante, ovvero A, invia delle richieste di broadcast ad uno o più host della nostra LAN (B), contenenti come indirizzo IP sorgente quello dell’host vittima (C). Tali richieste di livello 3 (255.255.255.255) vengono convertite in richieste di livello 2 (FF:FF:FF:FF:FF:FF) (solitamente dal router) in modo tale che tutti gli host della LAN possano rispondere, generando un elevato ammontare di traffico. A questo punto, tutte le risposte così generate verranno inoltrate sotto forma di pacchetti ICMP verso l’host vittima, congestionandolo di conseguenza.

Per fare in modo che gli host della nostra LAN non vengano utilizzati come testa di ponte per attacchi di questo tipo basta lanciare il comando:

NightRouter(config)# int e0

NightRouter(config-if)# no ip directed-broadcast

Così facendo, le richieste di broadcast  (di livello 3) contenenti indirizzo sorgente fasullo, inoltrate da un attacker mediante l’interfaccia del router connessa ad internet (Dialer0) oppure attraverso un’interfaccia di rete interna (E0), non verranno tradotte in richieste di broadcast di livello 2 e non subiranno quindi il processo di amplificazione che sta alla base del successo di questo tipo di attacco.

NB: nei router che utilizzano IOS maggiori o uguali alla 12.0 tale comando è abilitato per default. Per indentificare la versione di IOS installata sul vostro router basta digitare:

NightRouter# sh ver

Difesa contro gli attacchi di tipo DoS (diretti verso i servizi di diagnostica)

Un altro tipo di attacco, di tipo DoS, a cui sono soggetti i router Cisco, consiste nell’invio di un grande numero di pacchetti  spuri UDP e TCP verso le porte echo, chargen, discard e daytime (quest’ultima si basa esclusivamente sul protocollo TCP). Tali porte vengono adoperate per operazioni di diagnostica sul router ed un attacco di questo tipo potrebbe causare la congestione della CPU, fino a portare allo stallo del dispositivo.

Per prevenire questa tipologia di attacco basta disabilitare i servizi di diagnostica sopra citati, attraverso i comandi:

NightRouter(config)# no service udp-small-servers

NightRouter(config)# no service tcp-small-servers

Difesa contro gli attacchi di tipo DoS (Land)

Un attacco di tipo “land” permette di inoltrare pacchetti TCP SYN (tipici dell’inizio di una connessione) con indirizzo IP sorgente e porta modificati e posti uguali all’indirizzo ed alla porta dell’host di destinazione, causando in alcuni casi anche il blocco del router.

Il problema è stato risolto nelle versioni più recenti di IOS, ma negli altri casi è necessario applicare un filtro che blocchi per ogni interfaccia la ricezione di questi pacchetti. Vediamo come fare (utilizzando delle ACL estese):

NightRouter(config)# access-list 102 deny ip <indirizzo della scheda ethernet0> 0.0.0.0 <indirizzo della scheda ethernet0> 0.0.0.0

Associamo dunque tale ACL all’intercaccia ethernet0:

NightRouter(config)# int e0

NightRouter(config-if)# ip access-group 102 in

Come avrete notato, non ho associato tale ACL anche all’interfaccia Dialer0, in quanto la maggior parte di noi utilizza IP dinamici che ci vengono assegnati direttamente dall’ISP. Nel caso in cui, però, usufruite di IP statico basta digitare:

NightRouter(config)# access-list 102 deny ip <indirizzo della scheda Dialer0> 0.0.0.0 <indirizzo della scheda Dialer0> 0.0.0.0

NightRouter(config)# int dia0

NightRouter(config-if)# ip access-group 102 in

Cifratura delle password

L’ultima parte di questa guida riguarda la cifratura delle password, in modo che uno sh run non permetta di visualizzarle in chiaro.

Per abilitare la cifratura occorre digitare:

NightRouter(config)# service password-encryption

Bene, ora il nostro router dovrebbe essere al sicuro contro gli attacchi più comuni. A presto.