Ricerche IT

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.

Windows Server 2003 R2 integra ed estende le funzionalità di Distributed File System (d’ora in poi DFS), il componente che permette di gestire file system distribuiti tra più host in una rete Windows. In particolare, quest’articolo tratta della creazione di uno spazio dei nomi DFS su due server domain controller (d’ora in poi DC) Windows Server 2003, della creazione di cartelle e relative sottocartelle, in modo da avere più share distribuite su due server, situati su due diverse LAN e nei relativi siti Active Directory (d’ora in poi AD), LAN connesse tra di loro tramite un collegamento geografico a bassa velocità; la situazione viene mostrata in figura 1:

Figura 1

Il primo DC è DCServer, che ha indirizzo IP 172.16.1.1 sulla rete 172.16.1.0/24, il secondo DC è Coriolis, che ha indirizzo IP 192.168.1.10 sulla rete 192.168.1.0/24; ognuno dei due server funge da Global Catalog per il proprio sito AD di appartenenza.

In breve, un namespace (spazio dei nomi) DFS consente di avere più cartelle condivise su più server che fanno parte di un unico contenitore, il namespace appunto, che sarà accessibile dagli host del dominio secondo una struttura che viene impostata dall’amministratore di rete; così facendo, gli utenti di rete non dovranno preoccuparsi di sapere su quale server è situata una risorsa condivisa, semplicemente, l’unica cosa che dovranno conoscere è la struttura del namespace, che diventa l’unico "repository" logico dell’intera struttura dati aziendale; nella situazione descritta all’inizio dell’articolo, si noterà la differenza tra cartelle residenti sulla propria LAN e le cartelle residenti sul server remoto, unicamente in funzione della velocità di accesso alle cartelle stesse, dove ovviamente il browsing delle cartelle poste sul server remoto sarà notevolmente più lento. Si comprenderanno meglio questi concetti una volta messo in funzione lo spazio dei nomi DFS.

Per attivare DFS, bisogna installare sui due server il ruolo "File Server", utilizzando lo strumento "Manage your server" che si apre dopo il logon e che è accessibile anche andando su Start -> Programs -> Administrative Tools; cliccare ora su "Add or remove a role", cliccare su Next e, nella lista dei ruoli, selezionare la voce "File Server", dopodiché cliccare due volte su Next; a questo punto compare un ulteriore wizard, "Add File Server Role Wizard", cliccare su Next e selezionare il ruolo (relativo al File Server) "Replicate data to and from this server", che installa il servizio "DFS Replication", come mostrato in figura 2.

Figura 2

Il servizio DFS Replication è una novità introdotta con Windows Server 2003 R2 che consente di replicare i file tra due o più server in presenza di link di rete a bassa velocità, tipici delle WAN. In questo articolo non verrà trattato in dettaglio DFS Replication (che sarà oggetto di un articolo a parte), si sappia che uno spazio dei nomi DFS non necessita obbligatoriamente di DFS Replication, il quale a sua volta non necessita di uno namespace DFS; DFS replication e i namespace DFS comunque sono studiati per integrarsi senza problemi, anzi, molto spesso si utilizzeranno insieme, se si ha l’esigenza di creare uno spazio dei nomi DFS. Giunti qui, cliccare su Next e completare l’installazione del ruolo; tenere presente che per installare il ruolo File Server con DFS Replication è necessario avere a disposizione il CD 2 di Windows Server 2003 R2, che verrà richiesto durante l’installazione.

Una volta fatte queste operazioni su entrambi i server, posizionarsi sul server che ospiterà il namespace (che prende l’ovvio nome "namespace server") e creare lo spazio dei nomi DFS andando sulla console di gestione del servizio da Start -> Programs -> Administrative Tools -> DFS Management; aperta la console MMC, creeremo un nuovo spazio dei nomi basato su dominio, pertanto, nella colonna di destra cliccare sulla voce "New Namespace…", si aprirà l’immancabile wizard, in cui dovremo scegliere il server che fungerà da "namespace server", in questo caso DCServer, andare avanti e dare un nome allo spazio dei nomi, ad esempio "Cartella", che rappresenta la condivisione radice, che "conterrà" (dal punto di vista logico) tutti i dati che rientrano nel namespace DFS; fatto questo, cliccare su Next e lasciare selezionata la voce "Domain-based namespace", che indica la creazione di uno spazio dei nomi basato su dominio, quindi andare avanti e cliccare sul pulsante Create e poi sul pulsante Close per completare la creazione del namespace DFS. Ora bisogna aggiungere il secondo DC nell’ambito del namespace, quindi selezionare nella colonna di sinistra lo spazio dei nomi "\\terminus.lan\Cartella", e cliccare sulla colonna di destra (pannello Actions) la voce "Add Namespace Server…" ed aggiungere il server Coriolis nella casella "Namespace server", infine cliccare su Ok per aggiungere Coriolis come server dello spazio dei nomi per il namespace "\\terminus.lan\Cartella", come indicato in figura 3, dove è possibile osservare che i due server sono su due siti AD diversi.

Figura 3

Creato il namespace, ora bisogna creare la struttura delle sottocartelle del namespace appena creato, sottocartelle che, in questa particolare casistica, risiederanno ognuna solamente su un server, visto che al momento non verrà presa in esame la replica dei dati tra i diversi server facenti parte dello spazio dei nomi. Su entrambi i server, abbiamo una cartella condivisa che prende il nome "Dati", in cui sono situati i dati dell’organizzazione, accessibili secondo la classica formula \\nomeserver\nomecondivisione, che nei due casi descritti diventa \\dcserver\dati e \\coriolis\dati; ora vedremo come poter creare due sottocartelle del namespace, in modo tale che le due risorse condivise siano raggiungibili passando sempre dallo spazio dei nomi, secondo la formula \\terminus.lan\cartella\dati_dcserver e \\terminus.lan\cartella\dati_coriolis. Per creare una cartella dipendente dallo spazio dei nomi, cliccare sulla colonna di sinistra sul namespace \\terminus.lan\cartella quindi cliccare sulla voce "New Folder…" presente nel pannello di destra Actions, si aprirà la finestra di creazione della nuova cartella, in cui bisogna specificare il nome della cartella, nel nostro caso dati_dcserver, quindi cliccare sul pulsante Add… per aggiungere la destinazione cartella (folder target), che nel nostro caso sarà \\dcserver\dati; ripetere ora gli stessi passaggi per creare la cartella dati_coriolis con destinazione cartella \\coriolis\dati. è possibile che all’atto della creazione della cartella ci venga proposto un messaggio in cui è sconsigliata la creazione di una cartella che ha come destinazione una cartella già esistente, noi possiamo comunque ignorare il messaggio e confermare l’operazione. Ora l’interfaccia di DFS Management avrà l’aspetto mostrato in figura 4:

Figura 4

Ora questa struttura di cartelle sarà disponibile su tutti i computer del dominio, a prescindere dalla LAN di appartenenza, infatti, se digitiamo il percorso \\terminus.lan\cartella (corrispondente, come noto, al namespace creato in DFS Management) da vari host presenti sia sul sito "Rete192", sia sul sito "Rete172", avremo una finestra simile a quella mostrata in figura 5:

Figura 5

Da questa finestra, è possibile vedere su quale server sono residenti le due cartelle (anche se il nome delle cartelle spiega tutto) cliccando col tasto destro su una cartella e selezionando la voce Proprietà, dove è presente la scheda DFS, che mostra appunto qual è il percorso "reale" della cartella.

Come indicato in precedenza, se da un host qualsiasi appartenente alla LAN 172.16.1.0/24 sfogliamo e cerchiamo di accedere ai dati presenti nella cartella dati_coriolis, avremo una velocità d’accesso limitata dalla banda disponibile sul collegamento in WAN. Per ovviare a questo problema, è consigliabile utilizzare il meccanismo di replica che in Windows Server 2003 prende il nome "Replica DFS", che sarà oggetto di un prossimo articolo.