Ricerche IT

La corretta gestione dell’ora dei sistemi è molto importante in una rete con un dominio Active Directory, poiché il protocollo di autenticazione predefinito, Kerberos, richiede che l’ora di server e client sia sincronizzata, pena la possibile mancata autenticazione del client, il quale non sarà quindi in grado di fruire dei servizi erogati dal/dai server.

In primis, è buona norma configurare il domain controller che svolge il ruolo di master operazioni PDC in modo tale che prenda l’ora da un riferimento esterno; utilizzando il protocollo Network Time Protocol (NTP), il controllore di dominio sincronizza l’ora, tramite il servizio "Ora di Windows" (W32Time) , con uno o più server NTP, accessibili tramite la rete Internet. Per sincronizzare il controllore di dominio con una o più fonti esterne, è possibile utilizzare la metodica descritta in un precedente articolo. Il passo successivo riguarda la sincronizzazione dei client: se si tratta di postazioni Windows XP e, direi (ma non ho ancora avuto esperienza diretta), Windows Vista, che sono iscritte nel dominio, l’ora sarà sincronizzata automaticamente per impostazione predefinita, prendendo come riferimento il domain controller in questione. Lo stesso avviene per server membri e controller di dominio Windows 2003. Il protocollo utilizzato per questo tipo di sincronizzazione non è NTP ma NT5DS.

In alcuni casi, è possibile che il domain controller non riesca a sincronizzarsi con il/i server NTP, in tal caso, bisogna cercare di capire come mai questo avviene. Il primo passo da seguire, è verificare se non esiste già un’applicazione che utilizza la porta UDP 123, con il comando:

netstat -noa | find "123"

Se ci viene restituita una riga in cui compare un’applicazione che utilizza la porta UDP 123, bisogna segnarsi il PID (Process ID) del processo in questione (ad esempio, 4127), quindi, si utilizza il comando tasklist per identificare quale processo sta utilizzando la porta 123:

tasklist | find "4127"

e così sapremo quale applicazione utilizza la porta 123.

Se invece non risulta nessuna applicazione che utilizza la porta UDP 123, dovremo cercare di capire che avviene durante la sincronizzazione dell’ora. A tal fine, si può abilitare la registrazione del debug del servizio Ora di Windows, andando ad aggiungere alcuni parametri nella chiave del registro di sistema

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Questi parametri consistono nell’aggiunta di nuovi valori stringa chiamati FileLogSize, FileLogName e FileLogEntries, i cui dati valore sono indicati nella relativa pagina della Knowledge Base Microsoft. Dopo aver aggiunto questi valori, riavviare il servizio Ora di Windows col comando

net stop w32time && net start w32time

quindi digitare il comando

w32tm /resync

per forzare la sincronizzazione dell’ora. Fatto ciò, bisogna aprire con un editor di testo il file specificato precedentemente nel parametro FileLogName del servizio Ora di Windows, che ci mostrerà le varie operazioni svolte durante la sincronizzazione, sperando che ciò ci sia d’aiuto per risolvere i problemi di sincronizzazione dell’ora.

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.

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.

Se si gestisce un server Dell con installato Windows Server OEM (preinstallato da Dell), si potrà notare che nella fase precedente il logon viene caricato uno sfondo personalizzato di Dell. Il file di sfondo è un file BMP (dellwall.bmp) di quasi 2MB di dimensione presente all’interno della cartella “%systemroot%\system32\”. La cosa in sé non è fastidiosa, ma lo diventa se ci si connette tramite Remote Desktop su una linea lenta, come può essere una connessione VPN su linea ADSL; in questo caso, prima che compaia la finestra di logon, il nostro sistema dovrà “scaricare” quasi 2MB di immagine rappresentante un frontale di un server Dell, ed a parer mio, il sistemista che gestisce il server sa già che sta lavorando su un server Dell e non ha la minima intenzione di sprecare tempo e banda in questo modo.

Per risolvere il problema, basta modificare una voce di registro, e più precisamente impostare il valore della voce “Wallpaper” all’interno della chiave

HKEY_USERS\.DEFAULT\Control Panel\Desktop

sostituendo il percorso dello sfondo con una stringa vuota, in altre parole, basta cancellare il valore della voce “Wallpaper”.

Così facendo, elimineremo questo fastidioso contrattempo che nasce quando ci si connette ad un server Dell via RDP.

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

Quando si fa un backup su Windows Server 2003 utilizzando l’utilità integrata (ntbackup), può capitare che per qualche motivo non venga eseguito il backup; le cause possono essere varie, ed a questo proposito è bene controllare il log di ntbackup, che di solito descrive, seppur in modo striminzito, le ragioni del mancato salvataggio. Se il log dà un responso simile a questo:

Backup Status
The requested media failed to mount. The operation was aborted.

e nel log degli eventi compare un evento con Id 168 e l’origine Removable Storage Service, ciò significa che per qualche ragione il servizio Removable Storage non riesce a comunicare con l’unità di backup. In questo caso, una possibile soluzione consiste nel disinstallare da Gestione periferiche (Device manager) l’unità di backup e nel successivo riavvio del server, in modo tale che Windows reinstalli l’unità di backup appena disinstallata; fatto questo, se tutto va bene avremo di nuovo il nostro backup funzionante.

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.

Può capitare, avendo un sito web composto da diverse directory e/o sottodirectory, di dover consentire l’accesso ad una particolare directory solamente ad alcuni utenti. Avendo un web server come Apache su piattaforma Linux (le informazioni indicate di seguito le ho provate su una Debian Etch), è possibile utilizzare un file .htaccess, da creare nella directory a cui si vuole limitare l’accesso, per raggiungere lo scopo prefisso.

Il primo passo consiste appunto nella creazione del file .htaccess e nell’assegnazione dei corretti permessi al file stesso:

# touch /var/www/sito/dirProtetta/.htaccess
# chmod 644 /var/www/sito/dirProtetta/.htaccess

Fatto questo, editare il file .htaccess col proprio editor preferito inserendo queste righe:

AuthName "Area protetta"
AuthType Basic
AuthUserFile /var/www/sito/dirProtetta/.htpasswd
<Limit GET PUT POST>
Require valid-user
</Limit>

L’istruzione nella prima riga rappresenta il titolo della finestra di richiesta autenticazione, la seconda riga indica invece il tipo di autenticazione alla directory, cioé l’autorizzazione di tipo Basic, che consente il passaggio in chiaro del traffico di autenticazione, a differenza dell’autenticazione di tipo Digest; la terza riga specifica il percorso del file .htpasswd, che altri non è che il file contenente le accoppiate username -> password degli utenti a cui è consentito autenticarsi. Di seguito abbiamo il tag <Limit>, con gli attributi GET, PUT e POST che rappresentano le operazioni consentite in relazione alla directory (rispettivamente download, upload e invio informazioni tramite form), al cui interno vi è l’istruzione "Require valid-user" che dice ad Apache di consentire l’accesso alla directory solamente agli utenti riconosciuti come validi, cioé che hanno fornito le corrette credenziali d’accesso.

Eseguiti questi passaggi, bisogna creare gli utenti del caso tramite il comando htpasswd. La creazione del primo utente comporta anche la creazione del file .htpasswd, tramite questo comando:

# htpasswd -c /var/www/sito/dirProtetta/.htpasswd utente1

Digitato questo comando, verrà chiesta per due volte la password da assegnare all’utente, e contestualmente verrà creato il file .htpasswd nella directory specificata con l’opzione -c; a questo file vanno assegnati adeguate autorizzazioni, in particolare il gruppo www-data (il gruppo che contiene l’utente omonimo che esegue il demone apache2) dovrà poter accedere al file almeno in lettura:

# chown root:www-data /var/sito/dirProtetta/.htpasswd
# chmod 640 .htpasswd

Ora possiamo creare gli altri utenti in questo modo:

# htpasswd /var/www/sito/dirProtetta/.htpasswd utente2

Creati gli utenti, abbiamo fatto quasi tutto; l’ultimo passaggio consiste nel modificare la configurazione di Apache in modo tale che sia consentito l’accesso ai file .ht per la directory che vogliamo proteggere, infatti, almeno in Debian (non so se è così anche con altre distribuzioni), l’accesso ai file .ht è inibito per default, quindi bisogna dire ad Apache che vogliamo sovrascrivere questa impostazione limitatmente alla directory specifica. In particolare, cercare all’interno del file /etc/apache2/apache2.conf il tag <Files> in modo tale che la configurazione finale sia questa:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

<Directory /var/www/sito/dirProtetta/>
    AllowOverride AuthConfig Limit
</Directory>

dove il tag <Directory> rappresenta appunto la sovrascrittura delle impostazioni date all’interno del tag <Files>.

E’ tutto, ora quando un utente accede a questa particolare directory del sito si ritroverà davanti alla richiesta di inserimento di username e password che Apache dovrà autenticare o meno.

SQL Server 2005 Express è il database gratuito di Microsoft appartenente alla serie SQL Server 2005, e si pone quindi come successore di MSDE, il database rilasciato gratuitamente da Microsoft fino alla serie SQL Server 2000. Questa versione di SQL è liberamente scaricabile dal sito Microsoft e richiede il framework .NET 2.0, altrimenti non si installa.

Il grosso limite di SQL Express è che non ha un’interfaccia visuale di gestione, per cui andrà gestito da linea di comando (a meno di non avere un’altra installazione di SQL Server attiva sulla rete o di altri tool che al momento non conosco), ma soprattutto, in modo predefinito, SQL Express non accetta connessioni da altri host.

Per permettere a SQL Express di accettare connessioni da altri host, è necessario per prima cosa aprire il tool di configurazione di SQL Express che prende il nome di SQL Configuration Manager, quindi da lì andare in "SQL Server 2005 Network Configuration", poi su "Protocols for SQLEXPRESS", quindi abilitare il protocollo TCP/IP. Fatto questo, andare nel registro di configurazione e impostare il valore HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\SQL Browser\Ssrplistener a 1, dopodiché bisogna abilitare l’avvio automatico del servizio "SQL Server Browser", poi bisogna avviarlo ed infine riavviare il servizio "SQL Server (SQLEXPRESS). Ora, oltre a rendere possibile l’accesso ad altri host, è possibile anche amministrare la nostra installazione di SQL col tool da riga di comando SQLCMD, tramite il comando:

sqlcmd -E -S nomeserverSQL\nomeistanzaSQL,1434

dove per nomeserverSQL si intende il nome host del PC su cui è installato SQL Express, per nomeistanzaSQL si intende il nome che si è dato all’istanza in fase d’installazione (il nome dell’istanza predefinita è MSSQL$EXPRESS) e per 1434 si intende la porta TCP su cui risponde SQL Express.

A questo punto, è abbastanza probabile che si vogliano riutilizzare database utilizzati in precedenza con SQL Server 2000 o con MSDE; se abbiamo i file del database (.mdf e .ldf), è possibile metterli nella cartella predefinita in cui sono contenuti i database di sistema di SQL Express e quindi, tramite T-SQL, creare un nuovo database facendo un attach dei file già esistenti:

> CREATE DATABASE nuovoDB ON
> (FILENAME = ‘c:\program files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\nomefileDB.mdf’) FOR ATTACH;

in questo modo SQL Express crea il nuovo database agganciando i vecchi dati in nostro possesso, facendo una conversione nel nuovo formato se stiamo facendo l’attach di un database SQL Server 2000

E’ inoltre possibile che esistano applicazioni distribuite sulla rete locale che devono accedere al database SQL Express presente su un server, per cui in questo caso possono servire i driver nativi per accedere al database via ODBC o via OLE DB. Questi driver sono installati con un pacchetto messo a disposizione di Microsoft e chiamato "Microsoft SQL Server Native Client", scaricabile ovviamente dal sito Microsoft.

Per amministrare la nostra installazione di SQL Express 2005, è possibile anche scaricare ed installare SQL Server Management Studio Express, che altro non è che l’erede di Enterprise Manager, ovvero la console MMC di gestione visuale di SQL Server, in questo modo non siamo legati per forza all’amministrazione di SQL Express da riga di comando.