Ricerche IT

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

Uno dei possibili utilizzi dell’Asus eeepc (il nuovo subnotebook di Asus con schermo da 7"), è quello di avere un pratico gingillo da portare sempre con sé e da utilizzare, se necessario, per brevi operazioni di amministrazione su server Linux (tramite ssh) o su server Windows, connettendosi con rdesktop su quei server Windows Server 2003 su cui è abilitato Remote Desktop.

Rdesktop è un’utilità già presente sull’installazione predefinita dell’eeepc, che consente appunto di connettersi ad un qualsiasi computer Windows con attivo il servizio RDP; la particolarità di rdesktop presente su eeepc è che… non funziona. Per essere più precisi, rdesktop non ha alcun problema in sé, ma se lanciamo dal terminale il comando:

$ rdesktop -a 16 -f nomeserver

cercando di connetterci ad un server Windows Server 2003, ci viene presentata la schermata di login dove, se inseriamo nome utente e password, ci butta fuori dando un errore "segmentation fault" nella finestra del terminale.

La ragione di quest’errore, è che, per impostazione predefinita, X.org montato sull’eeepc funziona con una profondità di colore di 16 bit, per cui bisogna modificare quest’impostazione lanciando da terminale il comando:

$ sudo kwrite /etc/X11/xorg.conf

e andando a modificare il valore della voce "DefaultDepth", portandolo da 16 a 24. Salvare il file modificato, quindi riavviare X, ad esempio con la combinazione di tasti (brutale ma veloce) CTRL+ALT+BACKSPACE, e, da una finestra di terminale, dare di nuovo il comando:

$ rdesktop -a 16 -f nomeserver

quindi immettere nome utente e password, ed amministrare il proprio server Windows Server 2003 alla risoluzione di 800×480 pixel, non comodissima ma utilizzabile per periodi non troppo lunghi.

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.

Leggendo questo post di Andrea Beggi, e proseguendo la lettura dei relativi commenti, viene descritta una situazione in cui si ha una rete che esce verso Internet tramite un router, e contestualmente si ha una VPN con un’altra sede che esce tramite un router separato, per cui bisogna lavorare bene con l’instradamento del traffico, facendo in modo che il traffico verso la VPN non esca tramite il router Internet, ma tramite il router VPN. Andrea Beggi propone una soluzione che consiste nel creare una route statica sul default gateway della rete locale, che sia in grado di reinstradare il traffico verso la VPN in modo trasparente all’utente; il problema potrebbe porsi nel traffico dalla sede remota ad un host della rete locale e ritorno, se infatti l’host non ha una valida configurazione di routing, la sede remota potrebbe comunque non comunicare con gli host della rete locale. In realtà normalmente ciò non accade, poiché il router, una volta configurato, utilizza il meccanismo chiamato ICMP Redirect Message per mandare messaggi ICMP ai vari host con le informazioni necessarie ad aggiornare la tabella di routing degli host, informandoli sul percorso più corretto da seguire per raggiungere la sottorete corrispondente alla sede remota connessa in VPN.

Nei commenti al post di Andrea Beggi, c’è chi ha proposto soluzioni alternative per raggiungere lo stesso fine, tra cui mi ha colpito la tecnica di distribuire una (o più) route statiche ai client della rete locale tramite server DHCP; il motivo principale per cui mi ha colpito è che ignoravo quest’opzione di DHCP. Al momento ho testato la soluzione solamente su un server Windows Server 2003 R2 SP1 e su un client Windows XP Professional SP2, e devo dire funziona senza problemi. In sostanza, l’obiettivo che vogliamo ottenere è fare in modo che i client della rete 172.16.1.0/24 possano raggiungere la rete 192.168.1.0/24 tramite il router 172.16.1.253; per raggiungere lo scopo, è necessario configurare nelle opzioni dell’ambito DHCP precedentemente configurato l’opzione “249 Classless Static Routes”, in cui indicare (tramite il tasto Add Route) la rete di destinazione, la subnet mask e il router tramite il quale raggiungere la sottorete in questione, come visibile dalla figura 1:

Fatto questo, dare conferma, riavviare il servizio DHCP e infine verificare che la distribuzione delle route statiche avvenga correttamente. Tenere presente che esiste un’altra opzione di DHCP che si occupa di distribuire route statiche ai client, la “033 Static Route Option”, che però non è applicabile nella nostra situazione, in quanto con questa route è possibile specificare solamente un host come destinazione e non un’intera sottorete.

Quando si gestisce un sistema informativo, bisogna fare in modo che questo sia protetto da attacchi più o meno subdoli. Una delle precauzioni principali da prendere riguarda la gestione delle credenziali d’accesso al sistema, che devono rispondere a specifici criteri di sicurezza che prevengano accessi non autorizzati, in ottemperanza alle elementari regole di sicurezza informatica ed al D. Lgs. 196 del 2003 conosciuto anche come "Testo Unico sulla Privacy". Pur esistendo dispositivi che permettono di fornire le proprie credenziali in modo sicuro, come ad esempio smart card e dispositivi biometrici, in realtà il metodo più usato consiste ancora nel fornire un’accoppiata Nome Utente - Password come credenziali d’accesso al sistema informativo. In particolare, è centrale il problema di come gestire le password associate ad ogni account, che rappresentano il punto debole e maggiormente attaccabile da parte di un malintenzionato, per cui è necessario prendere alcuni accorgimenti nella scelta e gestione delle password:

• segretezza della password: la password deve essere segreta, e nota solamente al legittimo utilizzatore di quelle determinate credenziali d’accesso ed al responsabile delle password, inoltre, l’utente non deve lasciare in giro appunti o post-it con in bella mostra la propria password, come troppo spesso succede;
• lunghezza della password: se un ipotetico "attaccante" cerca di scoprire la password di un utente tramite "tentativi" automatizzati (il cosidetto attacco a forza bruta), l’attacco avrà maggior successo se la password attaccata è breve, a differenza di una password lunga che, ovviamente, per essere indovinata necessita di un maggior numero di tentativi;
• complessità della password: l’utente, scegliendo una password, dovrà fare in modo che questa non contenga riferimenti a sé stesso o all’ambito familiare, infatti un malintenzionato, utilizzando eventualmente tecniche di ingegneria sociale, potrà scoprire riferimenti della vita privata dell’utente che riutilizzerà immediatamente come tentativo di accesso non autorizzato, se poi l’attaccante è un nostro collega di lavoro (cosa possibile anche se non frequente) non dovrà sforzarsi molto per conoscere particolari che ci riguardano; altro accorgimento in questo senso può essere quello di utilizzare caratteri non standard (come segni di interpunzione o spazi) nella composizione della password, misura utile anche nei casi di attacchi "brute force";
• durata della password: una password, per essere considerata sicura, dev’essere cambiata entro un periodo di tempo ragionevole, ciò rende la vita più difficile ad un malintenzionato che intende "rubare" la password, inoltre consente di "richiudere fuori" un attaccante venuto in possesso delle nostre credenziali, anche se in questo caso probabilmente il danno è già stato fatto

Considerata l’importanza di queste politiche di protezione, non si può delegarne l’osservanza alla buona volontà dell’utente finale, dev’essere l’amministratore di sistema ad imporre queste policy a livello centralizzato, in modo tale che l’utente possa solamente trovarsi a scegliere se autenticarsi sul sistema informativo secondo le regole impostate dal sysadmin o se mollare tutto e passare la giornata al bar.
Per quanto concerne una piattaforma Windows Server, in un dominio Active Directory è possibile definire e imporre una policy delle password valida a livello dell’intero dominio. Per definire i criteri relativi alle password, aprire la console "Active Directory Users and Computers", portarsi alla radice del dominio e quindi cliccare col tasto destro e scegliere la voce Properties, quindi andare sulla scheda "Group Policy", comparirà una finestra simile a quella mostrata nella figura sottostante (i passaggi saranno diversi se si utilizza lo snap-in di Group Policy Management, ma il punto d’arrivo è il medesimo):

Si può vedere che esiste già un criterio di gruppo per il dominio (Default Domain Policy), che però non sarà quello che andremo a modificare, poiché Microsoft consiglia di non utilizzare il criterio predifinito per queste operazioni, ma di creare un nuovo criterio di gruppo e modificare quello, per cui, tramite il pulsante New, creare un nuovo criterio di gruppo a cui assegnare il nome "Password Policy", quindi modificare il criterio appena creato cliccando il tasto Edit, che farà comparire l’editor del criterio di gruppo prescelto; i parametri che ci interessano sono quelli definiti in "Computer Configuration" - "Windows Settings", come mostrato nella seguente immagine:

In particolare, dovremo far riferimento, inizialmente, alla sezione "Security Settings" - "Account Policies", e lì scegliere la voce "Password Policy", in cui andranno impostate le seguenti opzioni:

• Enforce password history: serve per definire il numero di password "ricordate" dal server, ciò significa che prima di poter riutilizzare una password bisogna cambiare password (la quale ovviamente sarà sempre diversa) almeno x volte, dove per x si intende il valore impostato per questo parametro, che nella maggior parte dei casi secondo me può essere uguale a 10
• Maximum password age: indica il numero di giorni di validità della password, passato questo periodo, verrà imposto il cambio di password, pena l’impedimento all’accesso sul client da parte dell’utente finale; il valore consigliato non deve superare i 90 giorni, che è il limite massimo consentito dal Testo unico sulla privacy in caso di trattamento di dati sensibili, mentre Microsoft consiglia di non superare i 42 giorni di validità della password, che è anche l’impostazione predefinita in caso di attivazione di questa password policy
• Minimum password age: questa policy viene automaticamente attivata quando si attiva l’impostazione "Maximum password age" mettendo come impostazione predefinita 30 giorni; in realtà, questo settaggio consente di specificare la validità minima della password, cioé il numero minimo di giorni in cui non è consentito un cambio della password a partire dalla data di creazione della stessa, quindi è bene specificare un valore più basso per consentire un più tempestivo cambio della password che si può rendere necessario per diversi motivi, infatti Microsoft consiglia di impostare questo valore a 2
• Minimum password length: definisce la lunghezza minima della password intesa come numero di caratteri; secondo il Testo Unico sulla Privacy la lunghezza minima della password deve essere di otto caratteri, per cui ci possiamo attenere a questa prescrizione, in modo tale che l’utente non possa utilizzare password più corte di otto caratteri, ovviamente nessuno vieta di utilizzare password composte da più di 8 caratteri
• Password must meet complexity requirements: impostazione che obbliga l’utente ad immettere password utilizzando criteri di complessità in grado di rendere una password "sicura": in particolare, la password deve essere lunga almeno sei caratteri (precauzione superata dagli 8 caratteri specificati nel parametro "Minimum password length"), non deve contenere tre o più caratteri che fanno parte del nome utente, e deve includere almeno tre di cinque categorie di caratteri:
  • lettere dalla A alla Z maiuscole
  • lettere dalla a alla z minuscole
  • cifre comprese tra 0 e 9
  • segni di interpunzione e caratteri non alfanumerici (virgola, punto e virgola, $, %, ecc…)
  • caratteri unicode (simboli)

L’impostazione di queste opzioni consente di definire dei criteri di protezione validi per tutto il dominio, per cui, ogni utente che si autentica sul dominio, sarà "costretto" a seguire queste regole, ciò fa sì che, almeno da questo punto di vista, non ci siano utenti che mettono a rischio la sicurezza del sistema informativo semplicemente facendosi da sé le regole di accesso al sistema. Di importanza fondamentale rimane però la sensibilizzazione degli utenti riguardo queste tematiche, troppo spesso accade che l’utente finale comunichi le proprie credenziali ai colleghi con motivazioni del tipo "non ho nulla da nascondere", così come altrettanto spesso si vedono post-it appiccicati al monitor con in bella evidenza la propria password; ciò accade perché gli utenti non hanno ben chiaro che vanno protette non (solo) le informazioni personali, ma i dati personali o sensibili di terzi che si trattano col lavoro di tutti i giorni.

Link di riferimento: applicazione dell’utilizzo di password complesse nell’organizzazione

In una rete locale con un server Linux e n client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete, nonostante in linea teorica sia possibile utilizzare Samba come server WINS, che svolge grosso modo le stesse funzioni di un server DNS anche se ad un livello diverso. Siccome però, come detto precedentemente, lo strumento principe di risoluzione dei nomi host in ambiente Windows è DNS, occorre utilizzare un’architettura di rete con almeno un server DNS in grado di svolgere questo compito in rete locale. Linux risponde benissimo a quest’esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.

Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Linux), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l’intervento manuale dell’amministratore di sistema sia ridotto al minimo. Dulcis in fundo, il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.

Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux (la solita Debian Etch) e le relative utilità, col comando:

# apt-get install bind9 dnsutils

A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev’essere delegata a sé stesso, editando opportunamente il file /etc/resolv.conf. Successivamente, bisogna modificare il file /etc/bind/named.conf, che è il file principale di configurazione di Bind, il quale indica dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare. Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato /etc/bind/db.test ed uno chiamato /etc/bind/db.192.168.1, che rappresenta il file in cui inserire i record PTR (quelli di ricerca inversa). Di seguito vediamo come impostare il file /etc/resolv.conf, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 /etc/bind/named.conf, ed infine esamineremo i file di zona /etc/bind/db.test e /etc/bind/db.192.168.1:

/etc/resolv.conf

search casa.lan
nameserver 127.0.0.1

/etc/bind/named.conf

include "/etc/bind/named.conf.options";

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
};

/etc/bind/db.test

$TTL 86400      ; 1 day
test.lan.       IN SOA  ns1.test.lan. hostmaster.test.lan. (
                                2007081501 ; serial
                                86400      ; refresh (1 giorno)
                                28800      ; retry (8 ore)
                                604800     ; expire (1 settimana)
                                86400      ; minimum (1 giorno)
                                );
                IN      NS      ns1.test.lan.
;
ns1             IN      A       192.168.1.1
client          IN      A       192.168.1.3

/etc/bind/db.192.168.1

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     test.lan.       hostmaster.test.lan. (
                                2007081501   ; serial
                                604800       ; refresh
                                86400        ; retry
                                2419200      ; expire
                                604800       ; negative cache ttl
                                );
@       IN      NS      ns1.test.lan.
1       IN      PTR     ns1.test.lan.
3       IN      PTR     client.test.lan.

Fatta la configurazione, bisogna riavviare il demone bind9:

# /etc/init.d/bind9 restart

Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l’utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file /etc/bind/named.conf.options aggiungendo queste righe:

forwarders {
151.99.125.2;
151.99.250.2;
};

In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.

A questo punto prendiamo in considerazione l’ipotesi di necessitare dello stesso tipo di configurazione, ma per una rete locale di 20 (o più) host: in questo contesto, non è saggio mantenere un indirizzamento di rete con IP fissi, è sicuramente più indicato utilizzare un indirizzamento dinamico, servizio fornito da un server DHCP. Nella situazione indicata in precedenza però, i file di zona del dominio test.lan dovranno essere editati ogniqualvolta cambia l’assegnazione dell’indirizzo IP ad un host, per cui va a farsi benedire la comodità dell’utilizzo di un server DHCP; è evidente quindi che la situazione ideale consiste nell’assegnazione di indirizzi IP dinamici agli host e nel contestuale aggiornamento dinamico della corrispondenza indirizzo IP -> nome host. Per fortuna, in Linux ciò è possibile, poiché sarà il server DHCP, opportunamente configurato, ad effettuare gli aggiornamenti dinamici sul server DNS, il quale dev’essere configurato per accettare gli aggiornamenti inviati dal server DHCP.

Il primo passaggio della messa in opera della configurazione appena esaminata consiste nell’installazione ed attivazione del server DHCP, senza per il momento prendere in esame l’aggiornamento dinamico del server DNS; per installare il pacchetto dhcp3, utilizzare il solito apt:

# apt-get install dhcp3-common dhcp3-server

quindi, fare una copia di salvataggio del file di configurazione di esempio, crearne uno nuovo vuoto ed editarlo:

# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.old
# touch /etc/dhcpd3/dhcpd.conf
# nano /etc/dhcp3/dhcpd.conf

Ora, aggiungere un ambito DHCP con le opzioni del caso che ci permetta di distribuire i parametri della configurazione TCP/IP ai client della LAN, operazioni che si traducono nel seguente contenuto del file dhcpd.conf:

server-identifier 192.168.1.1;
ignore client-updates;

subnet 192.168.1.0 netmask 255.255.255.0
        {
        range 192.168.1.100 192.168.1.150;
        option subnet-mask 255.255.255.0;
        default-lease-time 604800;
        max-lease-time 2592000;
        option broadcast-address 192.168.1.255;
        option routers 192.168.1.254;
        option domain-name-servers 192.168.1.1;
        option domain-name "test.lan";
        option netbios-name-servers 192.168.1.1;
        option netbios-node-type 8;
        }

A questo punto, far partire (o ripartire) il demone dhcp3-server per attivare la configurazione:

# /etc/init.d/dhcp3-server start

Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all’aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l’aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all’installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file /etc/bind/named.conf per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:

include "/etc/bind/rndc.key";

controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};

Un’ulteriore modifica da fare al file /etc/bind/named.conf è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l’aggiornamento solamente tramite l’utilizzo della chiave segreta:

zone "test.lan" {
        type master;
        file "/etc/bind/db.test";
        allow-update { key rndc-key; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
        allow-update { key rndc-key; };
};

Fatto questo, far ripartire il demone bind9. Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta /etc/bind/rndc.key. Ciò si traduce nell’aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf:

ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "in-addr.arpa.";
include "/etc/bind/rndc.key";
authoritative;

zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.29;
        key rndc-key;
        }

L’ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l’utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l’aggiornamento di Bind da parte del server DHCP:

# chmod 775 /etc/bind

Ora, un riavvio del demone dhcp3-server completerà l’opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull’intera rete locale. Il vantaggio di questa soluzione è l’elevata automatizzazione dei processi descritti, che comporta un intervento dell’amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.

Aggiornamento: ringrazio Croccobiscotto per avermi segnalato tramite un suo articolo una mia dimenticanza che riguarda l’aggiunta della direttiva "authoritative;" alla configurazione del server DHCP, la quale, da quel che ho letto, va indicata se il server DHCP è quello "ufficiale" della rete locale. Devo dire che al momento ho in "produzione" un solo server DHCP con Linux su cui avevo inserito a suo tempo la direttiva, facendo qualche prova a casa non ho inserito la direttiva ed il server DHCP e gli aggiornamenti dinamici funzionavano comunque bene, certo è che le prove che posso fare a casa non sono molto significative.

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.

In una rete con un server di dominio Windows Server 2003 è indispensabile un corretto funzionamento del servizio DNS, onde evitare problemi nell’utilizzo dei servizi di autenticazione e dei normali servizi di rete erogati su una LAN, poiché Active Directory (da ora in poi AD) si basa su DNS per il proprio funzionamento, senza contare che la risoluzione dei nomi host dei PC in rete viene realizzata sempre tramite DNS. Per evitare di dover gestire a mano tutte le corrispondenze nome host -> indirizzo IP, il servizio DNS integrato in Windows Server 2003 supporta gli aggiornamenti dinamici dei record di risorse dell’host (A) - cioè dei record memorizzati nelle zone di ricerca diretta - e dei record di risorse del puntatore (PTR) - i record memorizzati nelle zone di ricerca inversa - da parte dei client della rete a partire da Windows 2000. In questo modo, quando avvengono dei cambi di nomi host o dei cambi di PC sulla rete locale, non è necessario cambiare a mano i record presenti sul server DNS, poiché gli aggiornamenti sono automatici.

Se nella rete abbiamo un server DHCP (come accade nella stragrande maggioranza delle reti, pratica comunque sempre condivisibile a mio parere), dobbiamo accertarci che questo supporti gli aggiornamenti dinamici dei record DNS, ovviamente, se usiamo il server DHCP integrato in Windows Server, non avremo problemi, visto che per impostazione predefinita, quando rilascia un lease ad un client, si occupa di aggiornare le zone diretta ed inversa del dominio AD coi corrispondenti record (A) e (PTR); a tal riguardo, bisogna fare attenzione a non avere attivo un server DHCP su altri dispositivi presenti in rete (come un router) che potrebbe creare conflitti con il server DHCP installato sul server, infatti in questi casi la cosa migliore è utilizzare l’accoppiata server DNS - server DHCP già presenti sul Windows Server 2003.

Quando un client cambia il proprio nome oppure quando viene registrato nel dominio, il servizio DHCP Client fa una query di tipo SOA al proprio server DNS primario, e se riceve una risposta affermativa, tenta di contattare il server DNS restituito come risultato dell’interrogazione per fornirgli un aggiornamento dinamico che includa il nuovo valore dell’accoppiata nome host -> indirizzo IP come record (A) e (PTR), ed inoltre, contestualmente e se necessario, rimuova la vecchia accoppiata nome host -> indirizzo IP dalla "forward zone" e dalla "reverse lookup zone" di AD.

Se in una rete è attivo un server DHCP su un controller di dominio, allora può essere lo stesso server DHCP a farsi carico di aggiornare dinamicamente il server DNS per conto dei client; ciò è indispensabile in quanto può succedere in qualsiasi momento che un server DHCP cambi l’assegnazione dell’indirizzo IP ad un client, ed è quindi di fondamentale importanza che vengano aggiornati i record (A) e (PTR) relativi al client sul server DNS, altrimenti la macchina non sarà contattabile in rete locale. Per forza di cose quindi il server DHCP di Windows Server 2003 è configurato per aggiornare dinamicamente il server DNS in modo predefinito, ma solamente per quei client che richiedono in modo predefinito l’aggiornamento dinamico, cioé che hanno come sistema operativo Windows 2000, Windows XP o Windows Server 2003 (e presumo anche Windows Vista). Come comportamento predefinito, quando un client riceve un lease dal server DHCP, il client cercherà di aggiornare il record di risorse dell’host (A), mentre il server DHCP tenterà di aggiornare il record di risorse del puntatore (PTR). Per controllare le impostazioni concernenti gli aggiornamenti dinamici da parte di client e server DHCP, cliccare col tasto destro sul server DHCP in MMC e andare su Properties, quindi cliccare sulla scheda DNS, comparirà una schermata come quella di figura 1.

Sempre parlando della configurazione predefinita dei server DNS e DHCP in Windows Server 2003, bisogna considerare che gli aggiornamenti dinamici del server DNS avvengono per default in modalità protetta per le zone integrate in AD, ciò significa che solamente i client ed i server facenti parte del dominio AD possono effettuare aggiornamenti dinamici sul server DNS. In questa situazione, è necessario creare un account utente di AD che verrà utilizzato dal servizio DHCP server per aggiornare dinamicamente il server DNS, ed impostarlo effettivamente per questo compito, andando sempre in console MMC di DHCP, quindi cliccando col tasto destro sul server, Properties, Advanced, cliccare sul pulsante Credentials, e comparirà la maschera mostrata in figura 2 dove inserire il nome utente dell’account di cui sopra, il dominio di appartenenza e la relativa password. Tenere presente inoltre che l’account dedicato va creato anche quando il servizio DHCP è attivo su un controller di dominio (situazione tipica presente su piccole reti) e quando è il servizio DHCP che registra gli aggiornamenti dinamici per conto dei client, in parole povere, questo account va impostato nelle situazioni più comuni di funzionamento di Windows Server 2003.

Netshell è un utilità a riga di comando (richiamata dal file netsh.exe) che permette la visualizzazione e la modifica di diversi parametri relativi alla configurazione di rete del PC. Quest’utilità è presente da Windows 2000 in poi, ma i comandi seguenti sono testati esclusivamente su Windows XP.

Netshell può essere molto utile per eseguire dei batch che cambino la configurazione di rete, oppure che siano in grado di ripristinare la configurazione di rete perduta per un qualsiasi motivo. Ad esempio, se col nostro portatile dobbiamo spostarci su diverse reti, è possibile avere una serie di batch che configurano automaticamente la rete; ciò si rende necessario se il servizio DHCP non è presente su tutte le reti in cui ci muoviamo, altrimenti questo accorgimento sarebbe inutile. Prima di vedere come utilizzare Netshell, è bene compiere un passaggio, e cioé rinominare la connessione di rete locale, che generalmente prende il nome di "Connessione alla rete locale (LAN)", trasformandola in qualcosa di più semplice, tipo "Rete Locale" (senza virgolette).

Fatto ciò, vediamo come impostare la configurazione di rete (cioè il settaggio di indirizzo IP, subnet mask, default gateway, server DNS senza usufruire di un server DHCP) su un client Windows XP:

> netsh interface ip set address name="Rete Locale" source=static addr=192.168.0.11 mask=255.255.255.0 gateway=192.168.0.254 gwmetric=1
> netsh interface ip set dns name="Rete Locale" source=static addr=192.168.0.1

Come si può facilmente intuire, bisogna utilizzare due comandi distinti: il primo per impostare la configurazione di indirizzo IP, subnet mask, default gateway, ed il secondo per impostare la configurazione del server DNS. Analizzando più nel dettaglio i due comandi, abbiamo come prima cosa l’ambito su cui va ad agire il comando netsh, ovvero "interface ip", quindi, abbiamo l’istruzione "set", che indica la riconfigurazione dell’interfaccia di rete, ciò significa che le vecchie impostazioni vengono sostituite da quelle indicate nel comando netsh. Di seguito, andiamo ad indicare cosa andiamo a riconfigurare, nel primo comando "address" e nel secondo "dns", poi si specifica il nome della connessione della rete locale (name="Rete Locale") e quindi si indica se i parametri sono statici o dinamici (se sono dinamici, i dati riguardanti la configurazione di rete verranno assegnati al client da un server DHCP), infine si specificano i parametri veri e propri, ma solo nel caso in cui questi vengano assegnati staticamente.

Nel caso in cui si voglia aggiungere un secondo server DNS, è possibile utilizzare il comando:

> netsh interface ip add dns name="Rete Locale" addr=192.168.0.2 index=2

Le differenze col comando precedente sono minime, e si limitano all’istruzione "add" che sostituisce "set", in quanto il server DNS impostato precedentemente viene mantenuto, ed all’istruzione "index=2", che indica che il server DNS impostato è il secondo nell’ordine di ricerca e viene chiamato in causa solamente quando il primo server DNS non risponde.

Il comando netsh è molto utile anche per effettuare il salvataggio delle impostazioni TCP/IP della propria scheda di rete, impostazioni che possono quindi essere ripristinate in caso di bisogno. Per effettuare il salvataggio eseguire il seguente comando:

> netsh interface ip dump > c:\rete.txt

In questo modo le impostazioni di rete vengono salvate nel file "c:\rete.txt", e possono essere richiamate per un ripristino tramite il comando:

> netsh -c "interface ip" -f c:\rete.txt

L’opzione -c "interface ip" serve per indicare a netsh che deve accettare i comandi contenuti nel file "c:\rete.txt" nel contesto "interface ip", mentre con l’opzione -f indichiamo il percorso del file in cui abbiamo salvato le impostazioni di rete. Dopo aver lanciato questo comando, le impostazioni del protocollo TCP/IP verranno riportate alla loro condizione originaria, cosa utile, come detto, in caso di problemi con la configurazione di rete.

Netshell è presente anche su Windows Vista, e da quel poco che ho potuto vedere ha alcune opzioni in più che non ho ancora provato.