Ricerche IT

Panoramica

Può capitare, alle volte, di trovarci nella necessità di dover fare troubleshooting sulla nostra rete in conseguenza di un qualche malfunzionamento (software o hardware che sia); in alcuni casi, può essere estremamente utile “sniffare” il traffico di rete, cioé avere in una qualche forma comprensibile all’essere umano l’insieme (o, più spesso, un sottoinsieme) delle comunicazioni che avvengono sulla rete.

Per sniffare il traffico su una rete locale (o solo su alcuni hosts della stessa), bisogna innanzitutto avere uno switch che consenta tale attività (cioé uno switch managed), quindi utilizzare un software che consenta l’attività di sniffing vera e propria: il più famoso di questi è senza dubbio Wireshark.

Può succedere però che si debba verificare se il traffico transita o meno sul nostro firewall; in tal caso, è necessario che l’operazione di sniffing avvenga direttamente sul firewall, e a meno che il firewall non sia una macchina Windows o Linux, non è possibile utilizzare Wireshark o tcpdump. Se il firewall è un Cisco ASA, è possibile utilizzare IOS per poter sniffare il traffico, oppure è possibile utilizzare ASDM (ovvero l’interfaccia web di amministrazione), che non ho la più pallida idea di come funzioni; in genere sui firewall Cisco si utilizza la riga di comando.

Sniffing del traffico

Per i miei test su questa funzionalità dell’ASA, ho ripreso l’ambiente di test descritto nel precedente articolo riguardante la VPN IPSEC tra due ASA 5505.

Come prima prova, effettuerò lo sniffing del traffico ICMP dal client su LAN1 al firewall ASA-1. Per farlo dovrò utilizzare il comando capture di IOS; sia questo comando, sia i successivi, vengono eseguiti in privileged mode:

capture traffic_asa1_inside interface inside

dove capture indica il comando da utilizzare per istruire l’ASA sulla cattura del traffico di rete, traffic_asa1_inside è un nome da dare a piacere che indica la singola operazione di sniffing (serve perché potrei voler utilizzare diversi processi di cattura per diversi scopi), interface inside indica l’interfaccia del firewall sulla quale avviene il monitoraggio del traffico; da notare che dando queste indicazioni, viene catturato tutto il traffico di rete.

Fatto questo, pingo, dal client su LAN1, il firewall ASA-1, quindi dovrò vedere sul dispositivo se la cattura avviene correttamente; a questo scopo, devo digitare il seguente comando sull’ASA (dopo aver pingato il firewall, ovviamente):

show capture traffic_asa1_inside

una parte dell’output del comando sarà simile al seguente:

1
2
3
4
5
6
7
8

14: 11:36:14.393961 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
15: 11:36:14.394190 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
16: 11:36:15.399072 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
17: 11:36:15.399210 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
18: 11:36:16.412881 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
19: 11:36:16.413018 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
20: 11:36:17.426812 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
21: 11:36:17.426949 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply

Vorrei porre l’attenzione sul fatto che tutte le righe iniziano con un numero, ma questo numero, nel mio caso, non parte da 1, ma da 14. Questo avviene perché, prima delle mie richieste ICMP, viene loggata l’attività che svolgo sul firewall, in quanto sono loggato allo stesso via SSH, di conseguenza, il comando capture così indicato sniffa tutto il traffico di rete, rendendo più complicata la lettura dell’output restituito. Per ovviare a questo inconveniente, devo limitare il traffico catturato, interrompendo prima di tutto lo sniffing del traffico, con il comando:

no capture traffic_asa1_inside

in questo modo al firewall viene indicato di interrompere la cattura del traffico. Per poter limitare lo sniffing dei pacchetti di rete a determinati protocolli, è necessario utilizzare delle access-list che indichino il tipo di traffico da monitorare, per poi essere utilizzate col comando capture, come mostrato di seguito:

1
2
3
4

configure terminal
access-list test_icmp extended permit icmp any interface inside
exit
capture icmp_asa1_inside access-list test_icmp interface inside

le righe che ci interessano sono la 2 e la 4 (se il significato delle altre due righe non è conosciuto, consultare il precedente articolo riguardante la configurazione di base di un Cisco ASA), in particolare, la riga 2 rappresenta il comando per creare la access list chiamata test_icmp che consente il traffico ICMP tra la rete locale e l’ASA, mentre la riga 4 è la ripetizione del comando capture, con in più l’indicazione di monitorare esclusivamente il traffico consentito dall’access list test_icmp. Se dal mio PC vado a pingare il firewall ASA-1, posso poi dare il comando show capture per verificare il traffico ICMP sull’interfaccia inside:

show capture icmp_asa1_inside

il cui output è questo:

1
2
3
4

1: 12:41:30.148582 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
2: 12:41:31.151572 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
3: 12:41:32.154365 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
4: 12:41:33.155280 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request

In questo caso vedo solamente le richieste ICMP e non le relative risposte, ciò dipende dall’impostazione che ho dato precendentemente all’access-list; se voglio vedere anche le risposte alle richieste ICMP, modificherò l’access-list in questo modo:

1
2
3
4

configure terminal
access-list test_icmp extended permit icmp 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0
no access-list test_icmp extended permit icmp any interface inside
exit

Per testare il funzionamento dello sniffing basato sulla access-list cambiata, è meglio pulire tutti i risultati della cattura raccolti fino ad ora:

clear capture icmp_asa1_inside

ora, se pingo il firewall e digito di nuovo il comando show capture mostrato in precedenza, avrò questo output:

1
2
3
4
5
6
7
8

1: 12:48:34.685541 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
2: 12:48:34.685770 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
3: 12:48:35.687037 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
4: 12:48:35.687220 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
5: 12:48:36.688593 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
6: 12:48:36.688730 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
7: 12:48:37.690989 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
8: 12:48:37.691141 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply

In questo caso è decisamente semplice interpretare l’output mostrato dal firewall Cisco, ma se mi trovo a dover sniffare il traffico di diversi protocolli su un link di rete piuttosto trafficato, potrei trovarmi in difficoltà nel capire ciò che avviene. In tal caso, il Cisco ASA ci viene incontro con una simpaticissima funzionalità, che consiste nel poter scaricare un file rappresentante la cattura del traffico visualizzabile con Wireshark. Per poter sfruttare questa funzionalità, è necessario avere il server web abilitato; nel caso non lo fosse, bisogna indicare questi comandi:

1
2
3
4

configure terminal
http server enable
http 192.168.1.0 255.255.255.0 inside
exit

dove la riga 2 rappresenta il comando per abilitare il server web (che rimane in ascolto in modo predefinito in modalità https), mentre la riga 3 indica gli host che possono connettersi via https al firewall e su quale interfaccia, nel nostro caso, gli hosts della rete 192.168.1.0/24 sull’interfaccia inside.

Ora possiamo connetterci tramite un browser all’indirizzo

https://192.168.1.254/capture/icmp_asa1_inside/pcap

dove al posto di icmp_asa1_inside andremo a mettere il nome che abbiamo assegnato alla cattura del traffico tramite il comando capture. Essendo la connessione di tipo https, verrà segnalata l’inaffidabilità del certificato, possiamo proseguire ignorando tranquillamente la segnalazione, dopodiché ci verranno richiesti nome utente e password, ed a quel punto bisogna inserire la password per entrare in privileged mode, senza indicare il nome utente; fatti questi passaggi, ci verrà richiesto di salvare il file pcap, a cui daremo un nome a scelta con estensione .pcap, visualizzabile direttamente con Wireshark. Nei miei test (decisamente poco esaustivi), ho notato come Wireshark mi apra perfettamente i file generati dall’ASA, escludendo però l’ultima riga e restituendo questo errore all’apertura del file .pcap: “The capture file appears to have been cut short in the middle of a packet”; questo errorino comunque non pregiudica una corretta visualizzazione del traffico sniffato.

Conclusioni

La funzionalità di sniffing integrata nel Cisco ASA può risultare molto utile quando si tratta di effettuare troubleshooting su determinate connessioni di rete. In questo articolo ho fatto alcuni test connettendomi al firewall via SSH, ma nel mondo reale, secondo me è caldamente raccomandabile sniffare il traffico connettendosi all’ASA direttamente in console, questo per evitare che eventuali comunicazioni di rete tra il proprio host e il firewall si vadano a sovrapporre al traffico vero e proprio che si vuole monitorare.

Link di riferimento

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807c35e7.shtml

Scenario

Si prenda in esame un’azienda con due sedi distinte e ad una certa distanza tra loro.

In questo caso, potrebbe non essere conveniente fare una connessione dedicata tra le due sedi aziendali, per cui, è possibile sfruttare la rete Internet per interconnettere le due sedi tra di loro; in tale situazione, si pongono ovvi problemi di sicurezza, poiché i dati transitano su una rete pubblica, e sono quindi tranquillamente sniffabili da chiunque sia un po’ troppo “curioso”. Per ovviare a questi problemi, è necessario criptare il traffico di rete fra le due sedi aziendali, anche se questo comporta un leggero calo delle prestazioni: tutte queste caratteristiche sono comprese in un tipo di connessione chiamato VPN (Virtual Private Network), che, come dice il nome, stabilisce un canale privato virtuale (tunnel) sulla rete pubblica (Internet).

Una VPN può essere di diversi tipi, in questa situazione, dovendo interconnettere tra loro due intere reti LAN distinte tra di loro, la VPN prende il nome di “site to site”; inoltre, una VPN può essere realizzata con diversi protocolli, in questo caso, utilizzeremo il protocollo IPSEC con due firewall Cisco ASA 5505 in un ambiente di test.

Ambiente di test

Per simulare la situazione prospettata nello scenario, ho creato un piccolo ambiente di test con due firewall Cisco ASA 5505, in cui, nella parte LAN, è collegato un notebook su entrambi i lati per simulare le due reti LAN (rispettivamente, LAN1 – 192.168.1.0/24 e LAN2 – 192.168.2.0/24), mentre la rete Internet è simulata utilizzando uno switch HP 1700-8, a cui sono collegate le due interfacce WAN (WAN1 – 172.16.3.1/24 e WAN2 – 172.16.3.2) del firewall. I due firewall prendono il nome rispettivamente di ASA-1 e ASA-2. Queste connessioni sono mostrate nello schema di rete in Figura 1.

Figura 1 - Ambiente di test per VPN IPSEC con Cisco ASA 5505

Cenni teorici su VPN IPSEC su Cisco ASA5505

Una connessione VPN IPSEC viene instaurata tra due apparati che supportano questo tipo di VPN in cinque passaggi. Il primo passaggio, consiste nel transito di “traffico interessante” tra i due firewall Cisco, dove per traffico interessante si intende quel tipo di traffico che deve essere protetto tramite IPSEC. A questo punto, avviene una negoziazione dei due apparati Cisco, i quali, a negoziazione avvenuta, instaurano una security association (SA) tra i due lati della VPN, utilizzando il protocollo IKE (chiamato anche ISAKMP).

La negoziazione di una SA avviene in due fasi (passaggio due e tre), Phase 1 e Phase 2: la Phase 1 stabilisce un primo tunnel che protegge i successivi messaggi di negoziazione ISAKMP, mentre la Phase 2 stabilisce il secondo tunnel che si occupa della cifratura vera e propria dei dati. Durante la Phase 2 bisogna specificare un transform set, cioè il livello di protezione richiesto per la sessione IPSEC, il quale combina un metodo di protezione ed un metodo di autenticazione; è importante che i parametri impostati con un transform set siano gli stessi su entrambi gli apparati responsabili della comunicazione sicura tra le due reti.

Quando si vuole stabilire una negoziazione ISAKMP tra due firewall, bisogna configurare su ogni dispositivo una policy ISAKMP, cioè un insieme di impostazioni che indicano come instaurare una SA; in particolare, una policy ISAKMP è composta da:

• un metodo di autenticazione, che serve per identificare l’identità dei peer; l’autenticazione può avvenire tramite preshared key (una sorta di password) oppure con l’utilizzo di certificati;
• un metodo di cifratura dei dati, usato per cifrare i dati in transito nel tunnel VPN;
• un algoritmo di hash usato per assicurare l’integrità dei dati;
• un tipo di gruppo Diffie-Hellman, che serve per scambiarsi in sicurezza la chiave segreta condivisa su un canale insicuro;
• un limite di tempo oltre il quale la SA deve essere ristabilita (un timeout, in parole povere), che prende il nome lifetime.

Ogni firewall invia le proprie policy ISAKMP all’altro firewall, e se le policy sono le stesse su entrambi i dispositivi, allora viene stabilita la SA, anche se per avere una connessione VPN funzionante sono necessari altri passaggi, come vedremo tra poco.

Instaurata una SA, su entrambi gli apparati deve essere presente una access list (ACL) che consenta il transito del traffico interessante che dalla rete LAN1 va verso la rete LAN2 e viceversa, sfruttando il canale instaurato tramite la VPN. Definita la ACL, deve essere presente anche una mappa (chiamata crypto map) che assembla i seguenti elementi della SA instaurata con i passaggi precedenti:

• quale traffico deve essere protetto con IPSEC (traffico interessante), definito dalla ACL di cui sopra;
• l’indirizzo IP pubblico dell’altro lato della VPN al quale inviare il traffico tramite IPSEC (peer);
• quale tipo di sicurezza IPSEC è richiesto per questo traffico, definito dal transform set specificato precedentemente;
• a quale interfaccia dell’ASA va applicata la mappa.

Infine va definito un tunnel group su ognuno dei due apparati, dove per una connessione VPN Site to Site può essere sufficiente specificare il tipo di connessione (Lan to Lan) e il metodo di autenticazione.

Definiti questi parametri, e ammesso che tutto funzioni, le due reti sono connesse tra di loro a livello IP, per cui ogni protocollo che si poggia su IP può transitare tramite il tunnel e quindi viaggiare da una rete all’altra, posto che sia configurato il corretto instradamento sugli host di ogni rete.

Configurazione degli apparati

La configurazione dei parametri TCP/IP di base dei due apparati, secondo lo schema di Figura 1, è stata effettuata secondo le indicazioni fornite in un precedente articolo, per cui la diamo per scontata.

Come descritto in precedenza, per configurare la VPN IPSEC su ognuno dei due ASA bisogna impostare una ACL per consentire il traffico tra le due LAN, una policy ISAKMP, un transform set, una mappa crypto map e un tunnel group; la configurazione va effettuata su entrambi gli apparati perché il peer VPN IPSEC è unidirezionale.

Per prima cosa, impostiamo la ACL per il traffico IPSEC, in modo da abilitare il transito dalla rete LAN1 alla rete LAN2, e viceversa:

ASA-1

access-list lantolan extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

ASA-2

access-list lantolan extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0

Ora configuriamo il transform set, in cui andremo ad impostare un transform set che avrà come metodo di protezione la crittografia AES 128 bit, e come metodo di autenticazione esp-sha-hmac:

ASA-1

crypto ipsec transform-set VPNTest esp-aes esp-sha-hmac

ASA-2

crypto ipsec transform-set VPNTest esp-aes esp-sha-hmac

dove VPNTest è il nome dato arbitrariamente al transform set, esp-aes è il metodo di protezione e esp-sha-hmac è il metodo di autenticazione.

Adesso bisogna configurare la crypto map, secondo questa sintassi:

ASA-1

1
2
3
4

crypto map vpnTest 1 match address lantolan
crypto map vpnTest 1 set peer 172.16.3.2
crypto map vpnTest 1 set transform-set VPNTest
crypto map vpnTest interface outside

ASA-2

1
2
3
4

crypto map vpnTest 1 match address lantolan
crypto map vpnTest 1 set peer 172.16.3.1
crypto map vpnTest 1 set transform-set VPNTest
crypto map vpnTest interface outside

La configurazione, ovviamente, è praticamente identica in tutti e due i firewall. In questo caso, vpnTest è il nome assegnato alla mappa, identico per tutte e quattro le righe di configurazione della mappa; nella riga 1, indico qual è il traffico interessante per il mio peer IPSEC, identificato dalla ACL chiamata lantolan configurata in precedenza, nella riga 2 indico l’indirizzo del dispositivo col quale voglio instaurare il peer (nel mondo reale, l’IP pubblico del firewall posto sull’altro lato da collegare tramite VPN), nella riga 3 specifico il nome del transform set indicato in precedenza, in modo da specificare le impostazioni di protezione e autenticazione, ed infine nella riga 4 indico a quale interfaccia applicare la mappa.

Nelle righe da 1 a 3, la mappa vpnTest viene identificata col numero 1, che è un numero chiamato sequence number, utilizzato in caso si debbano applicare più mappe alla stessa interfaccia in presenza di più VPN sullo stesso apparato.

Configurata la mappa, bisogna impostare le policy ISAKMP in questo modo:

ASA-1

1
2
3
4
5
6
7

crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 43200

ASA-2

1
2
3
4
5
6
7

crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 43200

Com’è evidente, la configurazione è assolutamente identica su tutti e due i firewall, ed a parte l’impostazione del parametro lifetime, che può essere diverso su ognuno dei firewall, tutto deve essere identico su entrambi gli apparati, pena il mancato funzionamento della VPN.

La riga 1 indica l’abilitazione di isakmp sull’interfaccia outside, la riga 2 indica la configurazione dei parametri che compongono una policy isakmp identificata dal numero 1; indicando questo comando, si aprirà una nuova modalità di configurazione che riguarda l’impostazione della policy isakmp indicata, modalità che comporta anche il cambiamento del prompt, che assume una forma del tipo:

ASA-1(config-isakmp-policy)

La riga 3 indica il tipo di autenticazione (in questo caso preshared key, il tipo più semplice di autenticazione), la riga 4 rappresenta il metodo di protezione (crittografia AES), la riga 5 indica l’algoritmo di hash, la riga 6 indica il tipo di gruppo Diffie-Hellman, mentre la riga 7 indica il timeout della connessione IPSEC, trascorso il quale la SA deve essere rinegoziata.

Infine, rimane da configurare il tunnel group in questo modo:

ASA-1

1
2
3

tunnel-group 172.16.3.2 type ipsec-l2l
tunnel-group 172.16.3.2 ipsec-attributes
pre-shared-key ChiaveCondivisa

ASA-2

1
2
3

tunnel-group 172.16.3.1 type ipsec-l2l
tunnel-group 172.16.3.1 ipsec-attributes
pre-shared-key ChiaveCondivisa

La riga 1 indica a quale indirizzo connettersi per instaurare la connessione VPN e il tipo di connessione IPSEC (nel nostro caso l2l che sta per LAN to LAN), la riga 2 indica il comando per specificare gli attributi della connessione IPSEC, che sono indicati dai comandi successivi (anche in questo caso, cambia il prompt), nel nostro caso, l’unico parametro da digitare riguarda la riga 3 che rappresenta la preshared key che consente di autenticarci sull’altro dispositivo. Penso sia ovvio a questo punto che le preshared key indicate nei due firewall debbano essere identiche.

Aggiornamento 25/08/2009

Ho dimenticato di specificare una cosa. Perché i pacchetti transitino tra una rete e l’altra, se è applicato il natting sul firewall (come accade molto spesso, visto che in genere questi firewall non si occupano solo di fare da endpoint per la VPN), è necessario che il traffico interessante non venga nattato. Per evitare questa cosa, è necessario specificare questo comando su entrambi gli ASA:

nat (inside) 0 access-list lantolan

Se tutto è andato bene, è possibile provare a testare la connettività tra i due portatili con il comando ping. Se la VPN funziona, è possibile che il primo pacchetto vada perso a causa del tempo necessario ad instaurare la SA, ma i pacchetti successivi dovrebbero arrivare correttamente; inoltre, in caso di VPN correttamente funzionante, dovrebbe accendersi il led VPN posto in posizione frontale sull’ASA 5505.

Troubleshooting di base sulle connessioni VPN IPSEC

In caso di mancato funzionamento, è possibile effettuare un po’ di troubleshooting cercando di capire per quale motivo la VPN non funziona; in questi casi, può essere utile digitare i due comandi indicati di seguito:

debug crypto ipsec
debug crypto isakmp

Con questi due comandi, in caso di problemi compaiono un sacco di messaggi sullo schermo, sta a noi isolare quei messaggi che possono realmente aiutarci a capire che sta avvenendo. Quando i messaggi diventano troppi (ed in genere succede presto), è possibile interrompere il logging a video coi comandi

no debug crypto ipsec
no debug crypto isakmp

oppure, più semplicemente, col comando

no debug all

Tenere presente che, se ci sono dei problemi, spesso accade che le policy isakmp non sono identiche su entrambi i firewall.

Può anche accadere che la configurazione dei due ASA sia corretta ma che il traffico non arrivi a destinazione, in questi casi bisogna verificare che l’instradamento dei pacchetti verso l’altra rete avvenga correttamente, impostando il corretto router negli host della rete locale oppure utilizzando le opportune route statiche.

Link di riferimento

https://www.cisco.com/web/learning/le31/le46/cln/qlm/CCNP/iscw/Site-to-Site-IPsec-VPN-Operation_3/player.html

http://www.openskill.info/infobox.php?ID=806

http://www.assint.org/content/view/71/44/

Tempo fa mi è capitato di avere per le mani un firewall Cisco PIX 506e che non completava la fase di boot, praticamente, collegandosi in console al dispositivo, arrivava a mostrare quella che chiama la “PCI Device Table”, che dovrebbe essere l’elenco di alcuni componenti del firewall (tra cui le interfacce di rete) e si piantava in quel punto, senza che fosse possibile andare oltre.

Per fortuna, cercando sul Web, ho trovato una soluzione piuttosto semplice anche se “curiosa”, che consiste nello spegnere l’aggeggio (il Pix), aprirlo, e trovare un jumper presente nel bel mezzo della scheda madre; tale jumper fa da ponticello su due piedini, lasciandone un terzo libero, consentendo quindi di posizionare il jumper su due diverse posizioni, per cui, seguendo il consiglio trovato sul Web, ho spostato il jumper nell’unica altra posizione possibile, ho chiuso il firewall, quindi ho avviato il dispositivo, ottenendo il risultato sperato, cioé il corretto funzionamento della macchina.

Link di riferimento

http://www.velocityreviews.com/forums/t56103-cisco-pix-506e-wont-boot.html
http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_23316894.html

Se abbiamo configurato un firewall Cisco ASA 5505 in una piccola rete locale in cui non esiste un server di dominio, possiamo impostare il firewall in modo tale che funga da server DHCP; ovviamente, l’ASA può fornire il servizio DHCP anche se abbiamo un server di rete, ma penso che, normalmente, sia preferibile impostare come server DHCP lo stesso server di rete.

Prima di procedere alla configurazione del servizio DHCP, dobbiamo pianificare le modalità di assegnazione degli indirizzi IP. Se siamo in una rete piccola, e si ritiene inverosimile un deciso incremento dei client della rete locale, non è necessario specificare un range di indirizzi pari a tutta la classe di appartenenza della sottorete assegnata, poiché, con molta probabilità, vi sarà la necessità di dover mettere in rete dispositivi (tipicamente print server o server) che necessitano di indirizzi IP statici, per cui è bene prevedere fin da subito un range di indirizzi da assegnare staticamente, in modo tale da non dover gestire indirizzi riservati sul DHCP.

Ipotizziamo di avere un firewall ASA su una rete configurata nel modo seguente (la stessa del precedente articolo sul firewall Cisco):

in questa situazione, faremo in modo che ai client della rete venga assegnato un indirizzo IP compreso nel range 192.168.40.50 - 192.168.40.100; oltre agli indirizzi IP, assegneremo dinamicamente anche il server DNS ed il default gateway della rete locale.

Il primo passaggio consiste nel configurare il pool degli indirizzi IP assegnati agli host:

(config)# dhcpd address 192.168.40.50-192.168.40.100 inside

Ora dobbiamo assegnare dinamicamente ai client della rete locale i server DNS per la risoluzione dei nomi:

(config)# dhcpd dns 151.99.125.2 151.99.250.2

Il passaggio successivo consiste nell’indicare qual è il router predefinito per gli host della LAN, che altri non è, nel nostro caso, che il nostro firewall:

(config)# dhcpd option 3 ip 192.168.40.254

Arrivati qui, siamo quasi a posto per una configurazione minimale del servizio DHCP sul firewall; l’ultimo passo da compiere riguarda la durata dei parametri assegnati ai client, cioé la durata del lease, specificata in millisecondi. Il valore predefinito del servizio DHCP sull’ASA è di un’ora,un valore un po’ bassino; possiamo allungare la durata del lease ad una settimana, con questo comando:

(config)# dhcpd lease 604800

Ora la configurazione è completa, rimane solamente l’attivazione del servizio DHCP:

(config)# dhcpd enable inside

A questo punto il servizio DHCP è attivo e funzionante, quindi per non perdere la configurazione al riavvio successivo del firewall digitare il comando:

# write memory

che consente di memorizzare in modo permanente la configurazione del Cisco ASA.

Link di approfondimento: http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/dhcp.html

N.B. Sono un principiante nella configurazione di firewall Cisco, per cui è possibile che abbia scritto delle imprecisioni: se così fosse, potete lasciare un commento per correggere le eventuali imprecisioni.

In una rete medio-piccola, una configurazione abbastanza diffusa quando si ha un collegamento ad Internet con più IP pubblici, prevede la messa in funzione di un firewall, il quale consente di:

• separare la rete pubblica dalla rete privata;
• proteggere la rete privata da intrusioni indesiderate;
• utilizzare un unico indirizzo IP pubblico (a parte il router), tramite NAT, per consentire l’accesso verso Internet alla LAN interna;
• monitorare e limitare il traffico in uscita;
• pubblicare servizi come Web server e Mail server;
• eventualmente connettere in VPN sedi remote.

Un firewall funzionale e robusto che si presta bene per questi scopi in infrastrutture non troppo "impegnative" è il Cisco ASA 5505. L’ ASA 5505 è il prodotto di fascia bassa dei firewall marchiati Cisco, che va a sostituire il PIX 501, ed è dotato di otto porte Ethernet, di una porta console, e di tre porte USB riservate per usi futuri. All’interno della confezione del firewall sono presenti il cavo console (da collegare ad un PC via porta seriale) e due cavi di rete. In questo articolo verrà descritto come compiere una configurazione di base del firewall, che avrà la funzione di connettere la rete LAN alla rete Internet, non aprendo nessuna porta verso l’esterno e consentendo a tutto il traffico di uscire dall’interno verso l’esterno. Lo schema di rete è il seguente, in cui sono mostrati anche gli indirizzi IP della rete locale e degli apparati di rete:

Come descritto nello schema, dobbiamo posizionare il firewall tra le rete locale ed il router Internet, per cui dobbiamo configurare il router cambiando gli indirizzi IP delle interfacce di rete, in questo caso Ethernet0/0 e Ethernet0/1 (corrispondenti alle porte 0 e 1 dell’ASA); per farlo, il primo passaggio è quello di connettere, tramite il cavo console, la porta seriale del PC con la porta console del firewall, quindi utilizzare un emulatore di terminale per poter interagire con l’IOS (il sistema operativo Cisco presente sull’ASA) del firewall. Come descritto tempo fa, è possibile utilizzare Putty per svolgere questa funzione, ed è consigliabile utilizzare l’ultimo rilascio del programma, poiché, per quanto mi riguarda, lo ritengo molto più stabile per questo compito rispetto alle release precedenti. Una volta connessi in console, ci si presenterà un prompt del tipo

ciscoasa>

e, giunti qui, non rimane che configurare il firewall! Per prima cosa, controlliamo le caratteristiche del firewall, le porte presenti e la versione di IOS installata con il comando

> show version

Ora possiamo entrare in privileged exec mode, quella modalità che ci dà un accesso completo al firewall ed alla sua configurazione. Per entrare in questa modalità, digitare il comando

> enable

quindi premere il tasto Invio alla richiesta di password. Se la password non viene accettata, significa che la configurazione predefinita del firewall è stata modificata, quindi bisognerà effettuare una operazione di recovery password del dispositivo per poterne rientrare in possesso. Entrati in priviliged exec mode, è possibile, anche per semplice curiosità, dare un’occhiata alla configurazione corrente, digitando il comando

# show running-config

Notare che il prompt ha l’ultimo carattere trasformato in cancelletto (#) rispetto al precedente simbolo di maggiore (>), ciò indica il passaggio in privileged mode. Ora è possibile entrare nella modalità in cui inserire i comandi IOS di configurazione effettiva del firewall con il comando

# configure terminal

Il prompt cambia di nuovo forma, mettendo dopo il nome host la dicitura (config)# per indicare che siamo nella modalità di inserimento dei comandi di configurazione del firewall. Giunti qui, impostiamo il nome host del firewall, utile per identificare in un attimo su quale dispositivo stiamo lavorando, col comando

(config)# hostname firewalltest

Adesso è possibile assegnare gli indirizzi IP alle interfacce di rete dell’ASA, e qui è necessario fare una premessa: come già esposto, l’ASA 5505 ha otto interfacce ethernet, che compongono uno switch Layer 2, quindi non c’è una separazione fisica tra le porte di rete, cosa che in un firewall è da evitare; il Cisco ASA risolve il "problema" assegnando ogni interfaccia di rete ad una VLAN, in modo da separare logicamente le porte ethernet. Tenere presente che con una licenza base, l’ASA 5505 consente di creare al massimo tre VLAN nella modalità routed (la modalità predefinita), così da poter configurare il firewall che separa la rete LAN, la rete Internet ed eventualmente una DMZ. Esaminando la configurazione di default, si può notare che sono previste due VLAN già configurate, Vlan1 e Vlan2, dove Vlan1 rappresenta l’interfaccia di rete sulla LAN, con un contesto di sicurezza 100 (porta sicura) e con indirizzo IP 192.168.1.1, mentre Vlan2 rappresenta l’interfaccia di rete sulla WAN, con un contesto di sicurezza 0 (interfaccia non sicura) e un indirizzo IP assegnato dal server DHCP del provider Internet. Nella configurazione proposta, non cambieremo le impostazioni di base, per cui sfrutteremo la configurazione esistente che prevede due VLAN con due diversi contesti di sicurezza, ma cambieremo gli indirizzi IP come mostrato nello schema di rete; per far questo però, occorre tenere presente che nella configurazione predefinita è attivo un server DHCP, per cui non possiamo cambiare l’indirizzo dell’interfaccia Vlan1 se prima non modifichiamo la configurazione del server DHCP, cambiano l’ambito o eliminandolo, personalmente preferisco tenere il server DHCP della LAN su un server di rete e non sul router, per cui, disattiviamo il server DHCP:

(config)# no dhcpd address 192.168.1.2-192.168.1.254 inside
(config)# no dhcpd enable inside

Ora possiamo configurare l’interfaccia Vlan1 come segue:

(config)# interface vlan1
(config-if)# ip address 192.168.40.254 255.255.255.0
(config-if)# exit

Configurata Vlan1, passiamo alla configurazione di Vlan2. Come esposto prima, Vlan2 cerca un server DHCP del provider Internet, poiché evidentemente Cisco presuppone che il firewall sia connesso ad Internet tramite modem Ethernet, mentre in realtà, nella nostra configurazione, l’ASA è connesso direttamente al router, per cui l’indirizzo IP di Vlan2 è fisso. A tal proposito, per prima cosa disabiliteremo l’assegnazione dei valori dei server DNS e WINS sull’interfaccia outside (Vlan2), quindi procederemo all’assegnazione dell’indirizzo IP prestabilito:

(config)# no dhcpd auto_config outside
(config)# interface vlan2
(config-if)# ip address 111.1.1.2 255.255.255.248
(config-if)# exit

Ora possiamo controllare se la configurazione di rete, almeno dal punto di vista della LAN, è corretta, semplicemente pingando da un PC in LAN l’indirizzo IP del firewall:

ping 192.168.40.254

Se riceviamo la risposta dal firewall, significa che questa prima parte della configurazione è andata a buon fine. Per fare la stessa prova sull’interfaccia outside, o abbiamo un PC sulla stessa rete del firewall (e quindi con un IP pubblico), oppure dobbiamo provare a pingare l’ASA dal router; in genere, tutti i router hanno una sezione di diagnostica dov’è possibile effettuare un ping verso un host, in caso di router Cisco, è possibile effettuare il ping direttamente con il comando ping, che esiste anche su IOS.

Giunti fin qui, dobbiamo completare la configurazione di rete indicando al firewall il proprio gateway predefinito, nel nostro caso il router che consente il collegamento alla rete Internet:

(config)# route outside 0.0.0.0 0.0.0.0 111.1.1.1 1

dove indichiamo che, partendo dall’interfaccia outside, per tutte le destinazioni che non appartengono alla nostra rete, il firewall inoltrerà le richieste verso il router 111.1.1.1 con metrica 1. Eseguito questo comando, è possibile effettuare un ping verso l’indirizzo IP 66.102.9.99 (Google), che ci dovrebbe rispondere senza problemi, se così non è, c’è un errore nella progettazione della rete, o nella programmazione del firewall, o nella connessione fisica tra gli apparati. Arrivati a questo punto, è bene ricordare che i comandi di configurazione fin qui impartiti hanno un effetto immediato sulla configurazione dell’ASA, configurazione però che non viene mantenuta in caso di riavvio dell’apparato, poiché non viene modificata la configurazione di startup presente sulla memoria flash del firewall; per salvare in modo permanente la configurazione, utilizzare il comando

# write memory

Per impartire questa direttiva, sono uscito dal privileged exec mode, ma il comando ha effetto anche in privileged mode; quando si configura il firewall, ricordarsi di dare questo comando di tanto in tanto, giusto per non perdere d’un botto la configurazione già fatta.

A questo punto i client della rete locale possono navigare sul web, poiché il natting è già preconfigurato sull’apparto, per cui la configurazione di rete sarebbe terminata… ma in realtà, sempre dai PC in LAN, non è possibile pingare o fare un traceroute verso host presenti sulla rete Internet, poiché l’ASA non permette in modo predefinito al protocollo ICMP di attraversare le due diverse interfacce; per ovviare al problema (problema fastidioso, che limita molto la possibilità di fare troubleshooting di base in caso di problemi), è necessario configurare una access list (ACL) che consenta il traffico ICMP da qualsiasi sorgente verso qualsiasi destinazione, quindi bisogna applicare l’ACL sull’interfaccia outside dell’ASA:

(config)# access-list acl_icmp extended permit icmp any any
(config)# access-group acl_icmp in interface outside

Ora possiamo considerare terminata la configurazione di rete del firewall, rimangono però da sistemare alcuni aspetti legati alla sicurezza, l’accesso via ssh al firewall, e la riconfigurazione dell’accesso via http(s) all’ASA. Per prima cosa, assegniamo una password per entrare in privileged exec mode con il comando

(config)# enable password testopassword

dove al posto di testopassword va indicata la password scelta per entrare in privileged mode. Ora bisogna assegnare una password per l’accesso via telnet o ssh, che ci servirà per proteggere l’accesso via ssh all’ASA:

(config)# passwd testopassword

dove al posto di testopassword va indicata la password per l’accesso via rete al firewall. Assegnate queste password, vediamo come abilitare l’accesso via ssh, da preferirsi all’accesso via telnet, poiché quest’ultimo non prevede la possibilità di crittografare le connessioni, col traffico quindi perfettamente sniffabile, password comprese:

(config)# crypto key generate rsa modulus 1024
(config)# ssh 192.168.40.0 255.255.255.0 inside
(config)# ssh timeout 30
(config)# ssh version 2

Il primo comando serve per creare le chiavi di sicurezza richieste da SSH con una crittografia a 1024 bit, il secondo comando serve per abilitare l’accesso via SSH all’intera rete locale (giocando con le subnet è possibile restringere ulteriormente l’accesso al firewall), il terzo comando indica il timeout espresso in minuti, mentre il quarto comando serve per forzare l’utilizzo del protocollo ssh versione 2. Utilizzando un qualsiasi client SSH (come Putty), è ora possibile, se l’host appartiene alla rete LAN, connettersi all’ASA utilizzando l’utente pix e la password indicata con il comando passwd.

Ora rimane da vedere l’accesso via http(s) al firewall. La configurazione predefinita abilita questo tipo di accesso alla rete 192.168.1.0/24, rete che non esiste più, quindi si tratta di eliminare l’impostazione precedente e ricrearla utilizzando l’indirizzamento di rete corretto:

(config)# no http 192.168.1.0 255.255.255.0 inside
(config)# http 192.168.40.0 255.255.255.0 inside

Siamo arrivati al termine della configurazione di base del firewall, quindi la nostra rete locale ha ora il pieno accesso alla rete Internet, situazione che presenta diversi svantaggi, visto che sarebbe il caso di restringere ulteriormente l’accesso ad Internet agli utenti della rete locale, argomento che esula dagli scopi di quest’articolo.

Se si dispone di uno o più indirizzi IP pubblici statici con la propria connessione ad Internet, è abbastanza consueto che si voglia approfittarne per pubblicare un proprio server Web, un proprio server di posta, o altri servizi che necessitano di un IP pubblico statico, come una VPN. In questi casi, una buona politica di sicurezza è far passare tutto il traffico diretto verso uno di questi servizi pubblicati attraverso un firewall, che poi ridirigerà le richieste verso un server posto verso la rete "interna", che prenderà il nome di DMZ (zona demilitarizzata), una rete "intermedia" che è posta tra la rete pubblica (Internet) e la rete locale e su cui saranno posti solamente quei server che devono pubblicare servizi verso Internet, oltre ad un eventuale firewall che connetta LAN e DMZ.

Per fare in modo che il firewall "esterno" rediriga le richieste verso il/i server in DMZ, esiste un meccanismo chiamato "port forwarding", che dal firewall esterno riceve la comunicazione in ingresso su una determinata porta con un determinato protocollo di trasporto, e la "rimbalza" verso il server in DMZ con lo stesso protocollo di trasporto e su una porta che spesso è identica a quella della richiesta originaria, ma che può anche cambiare.

Se si utilizza un firewall Linux, il port forwarding è impostato tramite iptables, che oltre a fungere da firewall è perfettamente in grado di gestire anche la redirezione del traffico. In particolare, si prenda in esame una configurazione di iptables come quella mostrata qui, dove la cosa di cui tenere conto quando si configura il port forwarding, è che il comportamento predefinito relativo alla catena di FORWARD consiste nel blocco del traffico, per cui, oltre all’istruzione necessaria per indicare la redirezione vera e propria, è necessario impostare una regola di FORWARD  che abilita il traffico dall’interfaccia esterna (eth1) alla DMZ (la cui interfaccia di rete definita sul firewall Linux è eth0) solamente per il tipo di richiesta necessaria. Si consideri la pubblicazione di un server Web che risponde alla canonica porta 80, e la cui interfaccia di rete in DMZ ha indirizzo IP 192.168.20.1; questa esigenza viene soddisfatta scrivendo queste due righe di configurazione di iptables:

iptables -A FORWARD -i eth1 -o eth0 -p tcp –dport 80 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -i eth1 –dport 80 -j DNAT –to 192.168.20.1:80

A questo punto, se dall’esterno si digita in un browser l’indirizzo IP (o il corrispondente nome host) dell’interfaccia eth1, si vedrà il sito pubblicato tramite il port forwarding di iptables.

E’ ormai una pratica consolidata, in una rete aziendale, quella di avere un firewall perimetrale attraverso cui passa tutto il traffico in uscita della rete locale, e che regola il traffico in arrivo dall’esterno. La situazione ideale è quella di permettere il traffico in uscita verso Internet e di bloccare tutto il traffico in ingresso da Internet ad eccezione delle risposte alle richieste generate all’interno della rete locale, poi ovviamente succede sempre che devi aprire una porta per il tal servizio, poi l’altro vuole l’accesso remoto, quindi magari pensi che ci starebbe bene una VPN, ecc…

Esistono diversi firewall hardware che svolgono ottimamente questo compito, ma se abbiamo già disponibile un vecchio PC con due schede di rete, possiamo costruirci in modo autonomo un firewall utilizzando una qualsiasi distribuzione Linux. Un’ottima distribuzione da utilizzare per questo scopo è una Debian con installato solamente il sistema di base, infatti tutto ciò che serve per gestire il firewall è compreso nel kernel e più precisamente nel componente Netfilter, che permette appunto di gestire firewall e natting sulla propria macchina Linux tramite diverse regole che vengono definite dall’amministratore tramite il programma iptables.

Iptables raggruppa logicamente i pacchetti in transito sul firewall in base al loro "comportamento" e li suddivide in tre catene generali: INPUT (i pacchetti in ingresso), OUTPUT (i pacchetti in uscita) e FORWARD (i pacchetti in transito tra una scheda di rete e l’altra), quindi, all’interno di queste tre catene, è possibile regolare il traffico di rete in modo anche molto sofisticato. Nel nostro caso invece dovremo semplicemente creare un firewall e non avremo bisogno di un elevato grado di sofisticazione.

Il nostro firewall si posiziona tra la rete locale ed il router Internet che avrà un indirizzo IP pubblico, per cui, il firewall avrà un’interfaccia di rete chiamata eth0 con un indirizzo IP valido sulla LAN, ed un’interfaccia di rete eth1 connessa direttamente col router e con un indirizzo IP pubblico assegnato in grado di comunicare con il router; a questo punto possiamo cominciare con la definizione delle regole del nostro firewall.

Per farlo, creiamo un piccolo script che posizioniamo nella directory /etc/default/ (in realtà penso si possa posizionare più o meno ovunque, io lo metterei comunque dentro /etc) chiamato semplicemente firewall (o comunque lo vogliamo chiamare), quindi lo rendiamo eseguibile e lo andiamo ad editare:

# touch /etc/default/firewall
# chmod 755 /etc/default/firewall
# nano /etc/default/firewall

Come primo passo, dobbiamo abilitare il "routing" tra le due schede di rete, scrivendo all’interno del file l’istruzione

echo 1 > /proc/sys/net/ipv4/ip_forward # abilita il routing tra le due schede di rete

Ora dobbiamo cancellare qualsiasi altra impostazione precedente data a Netfilter e specificare il comportamento predefinito delle tre catene principali:

iptables -F #cancella le impostazioni delle tre catene principali
iptables -X #cancella eventuali catene personalizzate
iptables -P INPUT DROP #rifiuta le connessioni in ingresso
iptables -P OUTPUT DROP #rifiuta le connessioni in uscita
iptables -P FORWARD DROP #rifiuta le connessioni in transito

Trattandosi di un firewall, dobbiamo grossolanamente specificare che le connessioni in uscita sono abilitate mentre non lo sono quelle in ingresso ed in transito, per evitare che le connessioni richieste dalla rete Internet verso la rete LAN possano essere accettate; in questo modo però non sono accettate nemmeno le richieste di connessione dalla rete LAN verso il firewall, ed anche se fossero accettate, non riuscirebbero ad arrivare all’interfaccia eth1 a causa del comportamento predefinito della catena FORWARD, si tratta quindi di raffinare il comportamento del firewall. Inoltre, in questo caso, blocchiamo anche le connessioni in uscita, che non è quel che ci serve, ma come politica predefinita è più sicura, poiché se un pacchetto in uscita non sa come comportarsi, viene scartato. Come prima cosa, accettiamo le connessioni in ingresso su eth0 provenienti dalla nostra LAN, non strettamente necessario ma sicuramente molto utile per amministrare il firewall:

iptables -A INPUT -s 192.168.10.0/24 -i eth0 -j ACCEPT #accetta le connessioni in ingresso dalla propria LAN

ora dobbiamo permettere che i pacchetti in transito da eth0 a eth1 non vengano filtrati dal firewall, quindi dobbiamo fare in modo che i pacchetti di ritorno di connessioni generate dalla nostra rete locale possano transitare nella direzione opposta, cioè da eth1 a eth0:

iptables -A FORWARD -s 192.168.10.0/24 -i eth0 -o eth1 -j ACCEPT #permette il transito di pacchetti provenienti dalla nostra rete locale con destinazione il mondo esterno
iptables -A FORWARD -i eth1 -o eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente ai pacchetti di ritorno di transitare da eth1 a eth0 solo se la connessione era stata già stabilita

Così facendo, i client possono accedere ad Internet ma il firewall non può, cosa che non è positiva visto che di tanto in tanto è necessario aggiornare la nostra distribuzione, quindi vanno aggiunte queste due righe, di cui la seconda ha effetto anche per :

iptables -A INPUT -i eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente ai pacchetti generati direttamente dal firewall di tornare indietro
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #abilita il natting in modo tale che tutti gli IP mittente vengano cambiati con l’IP di eth1

A questo punto, bisogna fare due operazioni, la prima permettere che i pacchetti che arrivano in ingresso su eth0 possano tornare verso la rete locale (operazione necessaria essendo la catena OUTPUT impostata su DROP come comportamento predefinito), quindi, per fare uscire il firewall verso Internet, bisogna che l’interfaccia eth1 sia abilitata in uscita:

iptables -A OUTPUT -d 192.168.10.0/24 -o eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente l’invio dei pacchetti di risposta generati in seguito a richieste della rete locale
iptables -A OUTPUT -o eth1 -j ACCEPT #consente il transito dei pacchetti in uscita da eth1

Ora i nostri client e il nostro firewall sono in grado di navigare, ovviamente però i client dovranno avere come default gateway l’indirizzo IP di eth0 del firewall. Per rendere attive queste impostazioni, è sufficiente lanciare lo script appena creato, il problema è che così facendo le modifiche andrebbero perse al successivo riavvio del firewall, per cui, è possibile richiamare questo script dal file /etc/network/interfaces in modo da applicare le regole di iptables ad ogni riavvio della rete, e quindi ad ogni riavvio del firewall; per farlo, è sufficiente aggiungere al file /etc/network/interfaces questa riga:

pre-up /etc/default/firewall

ed a questo punto abbiamo il nostro firewall pronto per entrare in funzione.

Possiamo vedere un’ultima casistica, e cioè quella dell’apertura di porte al mondo esterno sul nostro firewall. Ad esempio, potrebbe essere utile aprire la porta 22 del nostro firewall per consentirne l’amministrazione tramite SSH, quindi aggiungere la seguente riga al nostro script

iptables -A INPUT -s 1.1.1.1 -i eth0 -p tcp –dport 22 -j ACCEPT #consente l’accesso via SSH al nostro firewall esclusivamente all’indirizzo IP 1.1.1.1

che consente di accedere ad SSH sul firewall solo all’indirizzo IP 1.1.1.1, se limitare l’accesso SSH per indirizzo IP non è possibile, allora va levata l’opzione -s.

AGGIORNAMENTO

Questa configurazione dà alcuni problemi se si cerca di iniziare una sessione FTP dall’interno della nostra rete locale verso un server FTP esterno, in particolare, connessione ed autenticazione funzionano senza problemi, ma non si riesce ad aprire la sessione dati col server FTP; per ovviare a questo inconveniente, basta mettere nel nostro script contenente le regole di iptables l’istruzione:

modprobe ip_nat_ftp

a questo punto basta far ripartire lo script e sarà possibile effettuare il normale trasferimento di file via FTP.

Link utili
http://guide.debianizzati.org/index.php/Condividere_la_connessione_a_internet
http://it.wikipedia.org/wiki/Netfilter/iptables

Site and Content Rules in ISA Server 2000 consente di definire le applicazioni ed i siti che è possibile utilizzare durante la propria navigazione sul Web, ma soprattutto, è possibile applicare queste regole ad utenti e/o gruppi definiti in Active Directory, rendendo possibile una gestione delle autorizzazioni semplice ed al tempo stesso efficiente. Ad esempio, è possibile creare una regola che impedisca ad un determinato gruppo di utenti di scaricare file video o audio, così com’è possibile limitare un altro gruppo di utenti consentendo loro di visitare solamente siti con determinati URL.

Su ISA Server 2000 però, quando si crea una regola in Site and Content Rules, bisogna prestare attenzione alle regole già create, infatti, a differenza di ISA Server 2004, non si può indicare un ordine preciso di applicazione, ma è ISA Server 2000 ad applicare un suo ordine specifico, in particolare:

1. regole di negazione (deny) applicate ad ogni richiesta (accesso anonimo)
2. regole di approvazione (allow) applicate ad ogni richiesta (accesso anonimo)
3. regole di negazione (deny) applicate ad utenti o gruppi
4. regole di approvazione (allow) applicate ad utenti o gruppi

Da qui si può capire che, se ho una regola che consente di navigare sul Web a chiunque, e successivamente creo una regola che impedisce ad un gruppo di utenti di navigare su alcuni siti, quest’ultima regola non verrà applicata, in quanto in precedenza avevo già consentito la navigazione anonima a tutti gli utenti. Per ovviare al problema e consentire l’applicazione della regola di negazione, dovrò cambiare la regola in cui consento la navigazione indiscriminata consentendo l’accesso Web solamente agli utenti autenticati (ad esempio il gruppo Domain Users).

Quando ci si trova a lavorare con router e firewall Cisco utilzzando la riga di comando (CLI), in genere si utilizza, in ambiente Windows, Hyperterminal per lavorare tramite console, oppure direttamente il comando telnet se si lavora tramite rete, oppure Putty se si accede tramite SSH. Soprattutto se si deve lavorare più o meno contemporaneamente su più dispositivi, è molto comodo utilizzare un unico programma, e ciò è possibile utilizzando Putty.

Putty è un software di emulazione terminale piuttosto completo, quindi permette di connettersi ad un dispositivo sia tramite porta seriale sia utilizzando diversi protocolli di rete. Putty mi piace molto di più di Hyperterminal quando ci si deve connettere ad un dispositivo Cisco tramite console, soprattutto quando si deve fare copia-incolla delle configurazioni degli apparati. Bisogna però dire che, almeno nelle connessioni seriali, ho riscontrato una certa instabilità di Putty, anche se ancora non mi sono dato la briga di giocare un po’ con le opzioni di connessione.

Per utilizzare Putty per connettersi ad un dispositivo tramite porta seriale, all’apertura del programma scegliere l’opzione "Serial" (l’ultima della lista di fianco a SSH), che è stata introdotta da non molto (credo). Da lì, nel campo "Serial line" scegliere la porta seriale su cui connettersi (COM1 è quella predefinita) e la velocità (9600 bit/s quella predefinita, adatta per connettersi ai dispositivi Cisco), quindi, eventualmente, dal menu ad albero sulla sinistra (Category), andare sulla voce Connection e quindi su Serial per specificare ulteriori opzioni di collegamento. A questo punto, cliccando su Open, ci si ritrova connessi alla porta seriale e possiamo agire sul nostro apparato.

Oltre a qualche pecca di stabilità via seriale (che però appunto potrebbe dipendere da una non corretta configurazione dei parametri di connessione), con Putty non funziona la combinazione di tasti CTRL+BREAK, utile quando si vuole fare un recovery della password di un router Cisco; per ovviare al problema, una volta avviata la connessione cliccare sull’iconcina di Putty in alto a sinistra sulla barra del titolo, scegliere la voce "Special command" quindi scegliere la voce "Break", in modo da ottenere un effetto equivalente alla pressione dei tasti CTRL+BREAK

Per gestire la configurazione di un firewall PIX di Cisco può essere utile l’accesso via telnet, invece del più scomodo accesso via console. Siccome i dati scambiati tramite protocollo telnet non sono criptati, il firewall PIX normalmente non permette l’accesso via telnet sull’interfaccia esterna (outside) del firewall, considerata poco sicura, per cui è possibile abilitare l’accesso via telnet solamente sull’interfaccia interna (inside).

Assumendo che il nostro firewall abbia un indirizzo IP sull’interfaccia inside uguale a 192.168.0.254, per abilitare il protocollo telnet diamo i seguenti comandi:

telnet 192.168.0.254 255.255.255.0
telnet timeout 5

In questo modo tutti i PC della rete locale potranno accedere al firewall, che richiederà una password per l’autenticazione; se non diamo altri comandi riguardo alla configurazione dell’accesso via telnet, la password predefinita per connettersi al firewall è "cisco", anche se poi dobbiamo conoscere la password per entrare in privileged mode per poter configurare il firewall.

Se vogliamo cambiare password di accesso e non lasciare la password predefinita per l’accesso via telnet, dobbiamo utilizzare il comando

passwd password

dove per password si intende la password che sceglieremo per l’accesso via telnet al nostro firewall.