Windows 2000 e Windows 2003 in Profondit�

3. Amministrazione di rete

3.1 Architettura della TCP/IP Protocol Suite

La TCP/IP Protcol Suite fornisce un protcollo su come gli Host di una rete devono comunicare fra di loro e su come le reti devono venire interconnesse. Nel linguaggio della suite TCP/IP, gli host sono tutti quegli apparati di rete (come ad esempio computer o stampanti) che non sono in grado d'inviare Pacchetti TCP/IP a reti diverse da quella a cui sono collegati. La TCP/IP Protcol Suite segue delle regole basate su standard e soddisfa al Department of Defence Model (o più brevemente DOD Model). Il DOD Model è un modello composto da quattro livelli:

L'ente internazione OSI ha proposto un modello più generale con cui virtualizzare i protocolli di rete, la cosidetta Pila OSI. La Pila OSI si contraddistingue per avere sette livelli (sebbene esista un'omonimia con alcuni livelli del DOD Model, fra i livelli della Pila OSI e quelli del DOD Model non esiste alcuna relazione di corrispondenza, tant'è che per ogni livello del DOD Model corrispondono, dal punto di vista logico, uno o più livelli della Pila OSI):

Per maggiori informazioni sui protocolli della suite TCP/IP si consulti o il sito www.iana.org oppure si dia un'occhiata al documento Protocols.

Per maggiori informazioni sulle chiavi di registry dei protocolli di rete di Windows 2000, si può consulatare la Knowledge Base KB120642.

Per maggiori informazioni sull'architettura di rete di Windows 2000 si può consultare il documento Windows 2000 Network Architecture.

Terminologia

Di siguito riportiamo alcuni dei termini caratteristici del Linguaggio TCP/IP:

Comandi Utili

Di seguito vengono riportati alcuni dei comandi più utilizzati nella gestione della TCP/IP Suite in Windows 2000

Per avere informazioni su come svolgere test diagniostici sulla TCP/IP Suite e su NetBIOS si può consultare la Knowledge Base: KB300986.

3.2 Gli indirizzi di rete

Gli indirizzi di rete si dividono in quattro grandi categorie, caratterizzate dal loro Network ID.

Regole Genarali per gli Indirizzi di Rete

Esistono delle regole generali per l'assegnazione degli indirizzi di rete all'interno di una LAN o WAN. Più precisamente abbiamo:

3.3 I dispositivi di rete

In una maniera piuttosto gorssolana, possiamo classificare i vari dispositivi di rete nel modo seguente:

All'interno di una stessa sottorete si utilizzano solamente HUB o SWITCH, mentre per mettere in comunicazione due o più sottoreti si ricorre ai ROUTER. Tipicamente, mentre gli HUB e gli SWITCH vengono collegati di solito direttamente ai server o alle workstation di una LAN, i ROUTER sono di solito collegati ad HUB od agli SWITCH; pertanto, salvo casi particolari, un server o una workstation non viene collegata direttamente ad un ROUTER. Le macchine che sono direttamente collegate ad un ROUTER ricoprono, in genere, dei ruoli ben precisi all'interno della struttura della LAN (come ad esempio i Proxy Server o i Server Web).

Per aggiornare dinamicamente la Routing Table, i Router moderni utilizzano uno o entrambi i seguenti protocolli di comunicazione:

Per maggiori informazioni sui Router e più in generale sull'IP Routing si può consultare il documento Unicast IP Routing.

Connessioni Full Duplex

Sono particolari connessioni punto-a-punto, che consentono di ridurre al minimo le collissioni fra pacchetti IP, separando i percorsi d'ingresso e di uscita di un pacchetto all'interno dello stesso mezzo di comunicazione, consentendo in questo modo di raddoppiare la banda di trasmissione. Ad esempio portando una connessione da 10Mbps a 20Mbps. Le connessioni Full Duplex si rivelano particolarmente utili nelle seguenti circostanze:

Tipologie di connessione ad Internet

Per motivi di affidabilità della connessione ad Internet, conviene aprire più connessioni con diversi Internet Service Provider (in sigla ISP). A seconda della contiguità o meno degli indirizzi IP pubblici che si ottengono, si individuano due possibili tipologie di configurazione degli swtich:

Caratteristiche delle tipologie di connessione

Di seguito vengono riportate le caratteristiche principali delle varie tipologie di connessione presenti sul mercato.

Protocolli di rete

I protocolli vengono suddivisi e catalogati in base al loro utilizzo, pertanto:

Per maggiori informazioni sulle chiavi di registry dei protocolli di rete di Windows 2000, si può consulatare la Knowledge Base KB120642.

3.4 Accesso Remoto

Per Accesso Remoto s'intende un modo particolare per accedere alla LAN/WAN di una azienda. Di solito la connessione alla LAN/WAN di una azienda avviene in modo diretto, sfruttando come collegamento (Link) uno degli apparati di rete (HUB o Switch) che la LAN/WAN aziendale mette a disposizione. Può succedere, tuttavia, che uno o più server della LAN/WAN aziendale venga abilitato a ricevere connessioni, anche da collegamenti che non appartengono alla LAN/WAN aziendale stessa, come ad esempio la rete telefonica pubblica (PSTN) od Internet. Si parla in questi casi di Accesso Remoto alla LAN/WAN aziendale.

Esistono due tipi di Accesso Remoto, distinguibili in base al tipo di mezzo di collegamento che si utilizza:

Le Virtual Private Network si rivelano essere, rispetto alle Connessioni Dial-Up, più economiche e allo stesso tempo più efficienti, in quanto possono consentire accessi più veloci in confronto alle usuali connessioni via modem analogico o ISDN. Infatti, per la natura stessa della rete Public Switched Telephone Network (PSTN) la comunicazione Client-to-Server può raggiungere una velocità massima di 33.6Kbps, mentre la comunicazione Server-to-Client può raggiungere una velocità massima di 56Kbps, a patto però, di utilizzare dei modem moderni (a 56Kbps appunto) collegati digitalmente al server. Velocità maggiori, rispetto a quelle citate, si possono raggiungere se in luogo della rete PSTN si utilizza l'Integrated Services Digital Network (ISDN).

I protocolli che consentono di realizzare Connessioni Dial-Up sono:

I protocolli che consentono di realizzare una VPN (Virtual Private Network), talvolta chiamati tunneling protocol, sono:

Lo scopo principale dei tunneling protocol è quello di assolvere le seguenti funzioni:

Le caratteristiche principali dei tunneling protocol sono:

Poichè il protocollo L2TP non supporta, nativamente, alcun meccanismo di criptazione, per poter rendere le comunicazioni fra il server che fornisce il servizio di accesso remoto ed i client sicure, si deve ricorrere ad un protocollo di criptazione esterno al L2TP, come ad esempio l' IPSec. Per poter criptare ed incapsulare interi pacchetti IP, l'IPSec si appoggia al protocollo Encapsulating Security Payload (ESP). Si osservi che solamente i client Windows 2000 o superiore possono utilizzare il protocollo L2TP. Per tutte le altre piattaforme si deve ricorrere al protocollo PPTP.

Per maggiori informazioni sull'Accesso Remoto si può leggere il documento Remote Access Server.

Per rendere una connessione remota più efficiente si possono utilizzare le seguenti due tecniche:

Se si desidera riservare una scheda di rete alla gestione esclusiva delle connessioni VPN bisogna abilitare degli Input, Output Filter sulla corrispondente interfaccia di rete all'interno del Routing and Remote Access tali da consentire l'accesso e l'uscita ai seguenti protocolli e l'apertura delle seguenti porte:

Installazione di un server per l'accesso remoto

Si distinguono due possibili scenari a seconda che la macchina sia stand-alone o appartenga ad un dominio di Active Directory:

Quando viene avviato per la prima volta il Routing and Remote Access, configurato come Remote Server, Windows 2000 crea cinque porte per il collegamento PPTP e cinque porte per il collegamento L2TP.

Se il Remote Access Server presenta solamente connessioni VPN e nessuna connessione Dial-In allora conviene cancellare la default Remote Access Policy, Allow Access If Dial-In Permission Is Enabled, sostituendola con le Remote Access Policy aziendali. Viceversa, se il Remote Access Server presenta anche connessioni PPP oltre a quelle VPN conviene far diventare l'Allow Access If Dial-In Permission Is Enabled l'ultima Remote Access Policy da controllare.

Un Remote Access Server basato su Windows 2000 può partecipare ad un ambiente SNMP come SNMP Agent installando il Windows 2000 SNMP Service. Il Remote Access Server registra le informazioni necessarie per la sua gestione in vari oggetti, come specificato nel Internet Management Information Base (o più semplicemente MIB) II. Per maggiori informazioni sul MIB II si consulti il documento RFC 1213.

Logging di un server RRAS e di client remoto

Per monitorare il funzionamento di un server RRAS o di un Client Remoto bisogna introdurre alcune chiavi di registry all'interno del Registry di Windows 2000. Di default, ovvero al termine dell'installazione di Windows 2000, queste chiavi non sono presenti all'interno del Registry (in quanto non esiste nessuna connessione in grado di sfruttarle), ma vengono aggiunte, automaticamente, non appena si crea la prima Network and Dial-up Connections, utilizzando il Network Connection Wizard, come indicato nel documento KB234025. Le chiavi vengono inserite all'interno della chiave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing

Per abilitare però il monitoraggio dei protocolli di un server RRAS o di Client Remoto, il metodo esposto nella Knoledgw Base KB234025 non è sufficiente. Per monitorare il funzionamento di server RRAS o di un Client Remoto si deve utilizzare il comando NetSH.exe (per maggiori informazioni sul comando NetSH.exe si può consultare il documento The Cable Guy - November 2001). Per attivare le chiavi create al momento dell'attivazione di una connessione dial-up, basta infatti aprire la Command Prompt e digitare il comando: netsh ras set tracing * enabled. Per disabilitare invece le chiavi, si può ricorrere al comando: netsh ras set tracing * disabled. Il simbolo * consente di attivare o disabilitare tutte le chiavi di registry che il servizio RRAS mette a disposizione. Più specificatamente, però, si possono utilizzare chiavi più mirate al tipo particolare di monitoraggio che si desidera attivare. Ad esempio, per attivare il controllo del protocollo PPP si può utilizzare il comando: netsh ras set tracing PPP enabled come riportato nella Knoledge Base KB234014. Alcuni valori che si possono inserire al posto del simbolo * sono:

Una volta attivato il logging dei vari protocolli di un server RRAS, vengono creati tanti file di log quanti sono i protocolli monitorati all'interno della cartella %WINDIR%\Tracing. Ad esempio, il file di log del protocollo PPP si chiama PPP.log.

Limitatamente ai soli server RRAS il monitoraggio del protocollo PPP e più in generale il livello di logging, può venire abilitato nel seguente modo:

Aumentare o dimunuire il livello di logging di un server RRAS, significa aumentare o dimunire la mole di eventi registrati nel System Log del Event Viewer.

Protocolli standard di autenticazione

Il Routing and Remote Access Services di Windows 2000 mette a disposizione degli amministratori di rete i seguenti protocolli di autenticazione:

Per maggiori informazioni sui protoclli di sicurezza e sulle VPN si può consultare il seguente documento Expanding and Securing Remote Client Access; mentre per le connessioni Dial-Up si può consultare il documento Providing Dial-Up Client Access.

Protocolli di Criptazione

Se si scelgono come protocolli di autenticazione uno dei protocolli seguenti:

allora risulta possibile criptare i pacchetti TCP/IP che il remote access client scambia col remote access server. La Data Encryption dei pacchetti TCP/IP avviene sfruttando una chiave di criptazione, nota sia al RAS Client sia al RAS Server. Questa chiave di criptazione viene generata durante il processo di autenticazione dell'utente remoto. Le tecnologie disponibili, nei sistemi operativi Windows 2000, per criptare i dati in una connessione dial-up basata sul protocollo PPP sono due:

Per le connessioni VPN il sistema operativo Windows 2000 utilizza una delle due seguenti soluzioni per criptare la comunicazione fra il VPN Client e il VPN Server:

Il processo di Data Encryption riportato si limita, però, allo scambio di pacchetti TCP/IP fra il remote access client e il remote access server, la comunicazione fra il remote access server e gli altri computer della LAN potrebbe avvenire tranquillamente in modo non criptato. Se si desidera realizzare una reale comunicazione punto-a-punto criptata, si deve utilizzare il protocollo IPSec.

Configurazione di un server per l'accesso remoto

Per configurare un server per l'accesso remoto bisogna:

All'interno delle Properties di un Server per l'accesso remoto troviamo le seguenti impostazioni:

Remote Access Policies

Sone le policies con cui vengono gestiti gli accessi remoti alla LAN a cui appartiene il Remote Access Server. Presentano le seguenti caratteristiche:

Il Profilo di una Remote Access Policies è composto dalle seguenti sezioni:

Quando si crea un Remote Access Server viene creata, di default, una particolare Remote Access Policies che si chiama Default Remote Access Policy. Questa policy contiene una Day-and-Time Restrictions che impedisce l'accesso degli utenti 24 ore su 24 e 7 giorni alla settimana su 7. In questo modo, se esiste solamente questa policy, non è possibile accedere remotamente alla LAN tramite il Remote Access Server. Quando si aggiungono delle Remote Access Policies queste vengono messe in coda alla Default Remote Access Policy, col risultato che se non si provvede a modificare l'ordine con cio vengono elaborate le Remote Access Policy o non si canclella la Default Remote Access Policy nessun utente potrà accedere remotamente alla LAN attraverso il Remote Access Server. Si ricordi infine che se un utente non soddisfa nessuna Remote Access Policy non può accedere remotamente alla LAN. Questo significa che, implicitamente, a tutti gli utenti è negato all'accesso remoto alla LAN. Il controllo dell'accesso alla LAN di un remote access client tramite Remote Access Policies è possibile solamente nelle seguenti due situazioni:

Per abilitare il controllo tramite Remote Access Policies bisogna selezionare la voce Control Access Through Remote Access Policy all'interno della sezione Dial-In delle Properties di un utente.

Le Remote Access Policy possono venire assegnate sia agli utenti sia ai gruppi, sfruttando l'opzione Windows Groups. Per quanto riguarda i VPN Server si possono utilizzare le seguenti tipologie di gruppi:

Per avere maggiori informazioni su come creare una Remote Access Policies si può consultare la Knowledge Base: KB313082.

Internet Authentication Service

Internet Authentication Service (IAS) consente, in combinazione con Routing Remote Access, di fornire il servizio di Remote Authentication Dial-In User Service (RADIUS). IAS consente:

Per simulare il compartamento di un RADIUS Server i componenti Routing and Remote Access e IAS si comportano come segue:

  1. Un utente si collega via Connessione Dial-Up o VPN al server che esegue il servizio Routing and Remote Access.
  2. Il server su cui gira il servizio Routing and Remote Access passa la richiesta di autenticazione allo IAS Server. Così facendo il server su cui opera il servizio Routing and Remote Access si comparta come un RADIUS Client.
  3. Lo IAS server interroga un Domain Controller per controllare le credenziali e i permessi dell'utente (procedura di autenticazione e di autorizzazione). Controllando in particolare che l'utente abbia le credenziali per accedere remotamente alla LAN. In questo modo lo IAS Server si comporta come un RADIUS Server.
  4. Se l'utente ha i permessi per accedere da remoto alla LAN e se non si presentano particolari problemi, la connessione remota viene stabilita.

Per poter attivare una struttura IAS-Route and Remote Access bisogna:

Le macchine con sistema operativo Windows NT 4.0 possono collegarsi allo IAS Server come RADIUS Client a patto che abbiano installato il programma Routing and Remote Access.

Conviene sempre specificare, per ovvi motivi di sicurezza, un Shared Secret fra lo IAS Server e il Route and Remote Access Server.

Risulta possibile impostare dei file di log. Si possono monitorare i seguenti eventi:

I file di log vengono inseriti nella cartella %SystemRoot\System32\LogFiles. I file di log vengono registrati utilizzando la codifica Unicode Translation Format 8 (UTF-8), separando ciascun dato con una virgola. I formati disponibili con cui creare i file di log sono due:

Per maggiori informazioni sul Internet Authentication Service si può consultare il documento Internet Authentication Service.

Remote Access Account Lockout

Il Remote Access Account Lockout è il processo con il quale viene bloccato l'accesso di un utente al Remote Access Server. Il Remote Access Account Lockout non ha nulla a che fare con l'Account Locked Out di un utente. Infatti un utente può ricevere un Remote Access Account Lockout ma continuare a fare Log On al suo dominio (di Active Directory) d'appartenenza. La gestione del Remote Access Account Lockout non è però integrata all'interno degli strumenti per la gestione degli accessi di Windows 2000, per attivare il processo di Remote Access Account Lockout bisogna modificare direttamente il Registry o del Remote Access Server o dello IAS Server, qualora questi fosse presente. Più in generale si può dire che bisogna modificare il Registry del server che si preoccupa d'autenticare gli utenti che tentato d'accedere da remoto. Le chiavi che bisogna modificare sono:

Per maggiori informazioni sulle chiavi di registry che gestiscono la Remote Access Account Lockout si consulti la Knowledge Base: KB310302.

DHCP e Accesso Remoto

L'assegnazione degli indirizzi IP ai Remote Client viene gestita dal IPCP (Internet Protocol Control Protocol). Quando si configura un server Windows 2000 col Routing and Remote Access per consentire l' accesso remoto alla LAN a cui il server appartiene; ai remote client viene assegnato dinamicamente un indirizzo IP. L'assegnazione dinamica dell'indirizzo IP può venire fatta o direttamente dal RRAS Server o da un DHCP Server. In questo secondo caso lo RRAS Server svolge il ruolo di DHCP Relay Agent. In questa modalità i remote client possono ricevere tutte le informazioni che un Server DHCP è in grado di rilasciare. Infatti, il protocollo PPP consente di fornire solamente le seguenti informazioni:

Per tutte le altre informazioni (come ad esempio il DNS Domain Name) c'è bisogno di un DHCP Server. Le informazioni fornite dal DHCP Server si trovano all'interno dei pacchetti DHCPInform che vengono inviati dai DHCP Server al Remote Client e viceversa, un volta che la fase di assegnazione degli indirizzi IP gestita dal IPCP si è conclusa. Le informazioni che possono venire fornite tramite i pacchetti DHCPInform ai Remote Client basati su Windows 98 e Windows 2000 sono:

I remote client possono venire raggruppati in un unica classe sfruttando la User Class chiamata Default Routing and Remote Access Class. In questo modo si possono realizzare degli Scope dedicati solamente ai remote client. Per ridurre il numero d'indirizzi IP utilizzati da questi scope, conviene ridurre al minimo la DHCP Lease di questi indirizzi (una DHCP Lease di 1 ora va più che bene nella maggior parte dei casi).

Per maggiori informazioni si consulti il documento How to DHCP to Provide RRAS Clients Addional DHCP Options.

Di solito il Remote Access Server preleva gli indirizzi IP dal DHCP Server a stock di 10 indirizzi IP per volta. Per modificare il numero di indirizzi IP che il Remote Access Server preleva di volta in volta dal DHCP Server, si deve modificare la chiave di registry seguente:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip\InitialAddressPoolSize

inserendovi il numero, espresso in decimale, d'indirizzi IP che il Remote Access Server può prelevare in un unica richiesta.

Comandi Utili

Il Resource Kit mette a disposizione degli amministratori di rete molti comandi utili per analizzare il comportamento del Routing and Remote Access Service:

3.5 Configurare Windows 2000/2003 come router

Per abilitare un server con sistema operativo Windows 2000 a funzionare come Router bisogna:

Un Windows 2000 Router (ovvero un server con sistema operativo Windows 2000 che funziona come router) è in grado d'instradare i seguenti protocolli di rete:

Le Static Route vengono inserite manualmente dagli amministratori di rete. Questo tipo particolare di route non gode di nessun automatismo.

Per aggiornare dinamicamente la Routing Table di un server Windows 2000 che svolge il ruolo di Router, bisogna configurare il protocollo RIP:

Per maggiori informazioni su come configurare il protocollo RIP col programma Routing and Remote Access si può consultare la Knowledge Base KB241545.

Per sapere come abilitare e configurare il Routing and Remote Access in Windows 2003 si possono leggere le seguenti KowledgeBase: KB323381, KB323441, KB816110 e KB837453.

Si ricordi che a differenza di quanto accade su Windows 2000, in Windows 2003 le regole di default presenti nell'interfaccia di amministrazione del Routing and Remote Access non consentono l'accesso remoto, pertanto o si creano delle nuove regole che lo abilitano esplicitamente, oppure bisogna modificare le regole di default per consentire l'accesso remoto da parte degli utenti.

Comandi Utili

Esistono diversi comandi utili per gestire RRAS tra questi il comando NetSH è sicuramente il più importante. Il comando NetSH presenta i seguenti contesti di utilizzo:

Per maggiori informazioni sul comando NetSH.exe si può consultare il documento The Cable Guy - November 2001.

Altri comandi utili sono:

3.6 Network Address Translation

I sistemi Windows 2000 e superiori mettono a disposizione degli amministratori di rete la possibilità di condividere l'accesso ad Internet tramite l'utilizzo del protocollo Network Address Translation o più brevemente NAT. Le caratteristiche dell'implementazione di NAT di Windows 2000 sono:

Dal punto di vista logico, il NAT di Windows 2000 è composto dai seguenti componenti:

Nei sistemi Windows 2000 e superiori esistono diversi metodi per implementare NAT, in particolare si possono utilizzare i seguenti strumenti:

Per attivare in Windows 2000 il protocollo NAT bisogna procedere come segue:

Il protocollo NAT utilizza delle mappe per collegare l'indirizzo IP privato di un computer della rete privata con l'IP pubblico di una macchina in Internet; queste mappe possono essere:

Il protocollo NAT è stato pensato per collegare una LAN, grande o piccola, ad Internet, pertanto non è in grado di assolvere ai seguenti compiti:

Come funziona NAT

Dal punto di vista logico, il protocollo NAT svolge le seguenti funzioni:

Nelle sue impostazioni di default, il protocollo NAT traduce solamente:

Queste modifiche comportano la modifica e la ricalibrazione dei seguenti campi del IP Header:

Questo significa che possono venire tradotti in modo trasparente solamente quei protocolli in cui l'Indirizzo IP e le informazioni sulla porta sono solamente nel IP e TCP/UDP Headers, come ad esempio lo HTTP. Per tutti quei protocolli che non consentono, basandosi sulle impostazioni di default di NAT, una traduzione trasparente, si deve utilizzare un NAT Editor che, nel limite del possibile, cerca di mettere a posto le cose onde poter consentire una traduzione trasparente di tali protocolli. I NAT Editors disponibili per Windows 2000 sono:

Sono poi disponibili i Proxy Software per i seguenti protocolli:

Tra i protocolli che non supportano NAT ricordiamo:

NAT con RRAS

Per mettere in piedi il servizio di NAT bisogna creare o installare:

All'interno delle Properties del Network Address Translation si possono impostare le seguenti voci:

Per sapere come configurare un client affinchè questi possa utilizzare il protocollo NAT si può consultare la Knowledge Base KB300851.

3.7 Public Key Infrastructure

Per Public Key Infrastructure, o più brevemente PKI, s'intende un sistema composto logicamente dai seguenti componeneti:

i quali hanno lo scopo di autenticare la validità di ciascuna parte coinvolta in una transazione elettronica attraverso l'uso di Public Key Cryptography. Le operazioni che disolito vengono svolte all'interno di una infrastruttura PKI sono due:

Per rendere le loro comunicazioni riservate l'architettura a Chiave Pubblica si basa sui cosidetti algortimi di criptazione chiamati Hash Alghorithms, i quali presentano la caratterisca che se anche un solo bit del documento originale viene alterato, lo Hash risultante è completamente diverso da quello dell'originale. In questo modo risulta possibile capire se un documento è stato manipolato.

Un'infrastruttura di PKI permette di rendere sicure le seguenti operazioni:

La gestione dei certificati all'interno delle implementazioni di IPSec ed Encrypting File System Recovery Agent avviene in modo autonomo, senza fare rifeirmento a Certification Authority esterne, ma utilizzando la generazione dei certificati in modo integrato all'interno della struttura stessa di IPSec od Encrypting File System Recovery Agent.

Viene chiamato Cryptographic Service Provider (o più brevemente CSP) quel software o hardware che si preoccupa di generare la coppia public key e private key che vengono utilizzate dalle varie Certification Authorities (CA). Il CSP standard di Windows 2000 fornisce, di default, chiavi da 40bit, ma può supportare chiavi di lunghezza compresa fra i 40bit e i 56bit. Per chiavi di lunghezza superiore o per performance migliori di quelle offerte da Windows 2000, bisogna utilizzare tool software o hardware di terze parti.

Per maggiori informazioni sul funzionamento di PKI si può consultare il documento Windows 2000 Certificate Services and PKI.

Struttura di un'infrastruttura PKI

Da dove arrivano le Public Key e le Private Key? La coppia di chiavi Public Key e Private Key viene gestita all'interno di un server, dotato di un programma opportuno (il Cryptographic Service Provider), che prende il nome di Certification Authority (o più brevemente CA). Compito di una CA è fornire, agli utenti o ai computer o alle organizzazioni che ne hanno diritto, una Public Key legata ad una e ben precisa Private Key. La Public Key viene fornita all'utente o al computer o all'organizzazione sotto forma di Digital Certificate. Un Digital Certificate contiene sia la Public Key sia tutta una serie di informazioni che caratterizzano il Digital Certificate stesso, ovvero (la struttura e le sintassi di un certificato sono di solito conformi alla specifica ITU-T Recommendation X.509):

In questo modo la Certification Authority (facendo riferimento a quanto elencato poco sopra, distingueremo la Certification Authority, al femminile, intesa come società che si occupa di sicurezza informatica, dai Certification Authority, al maschile, in quanto macchine che ospitano un programma in grado di rilasciare Digital Certificate) assume il ruolo di garante dell'autentiticità delle Public Key e Private Key utilizzate all'interno di una procedura di Key Exchange Operation o di Digital Signature Operation.

Di solito i server che svolgono il ruolo di Certification Authorities vengono organizzati in modo gerarchico, dando vita ad una struttura, che nella sua forma più completa, occupa tre livelli, ciò che lega fra loro i diversi livelli è una relazione di fiducia:

  1. Root CA. Rappresenta il primo livello composto di solito da un singolo member server (sebbene possa essere installata anche su di un domain controller) che, per motivi di sicurezza, viene tenuto off-line. All'interno della struttura gerarchica delle CA può esistere una e una sola root CA. Compito di un Root CA è quello di fornire i certificati ai server dei livelli inferiori, i cosidetti Subordinate CA. In questo modo la Root CA autentica le varie Subordinate CA se il certificato di una Subordinate CA viene revocato, allora la Subordinate CA non è in grado di rilasciare certificati.
  2. Certification Policy Rappresenta il secondo livello è composto da uno o più member server. Pure questi server, per motivi di sicurezza, vengono tenuti di solito off-line ed accesi solamente in caso di necessità. Contengono le policy con cui i certificati vengono rilasciati.
  3. Issuing CA. Rappresenta il terzo livello. Hanno il compito di fornire i certificati o agli utenti o ai computer che li richiedono. Anche questo livello è composta da uno o più member server.

I server che svolgono il ruolo di Certification Authorities possono venire installati seguendo due tipologie d'installazione distinte. L'adozione di una tipologia piuttosto che l'altra, dipende da chi dovrà usufruire dei certificati che queste Certification Authorities dovranno rilasciare. Se si decide di fornire i certificati solamente agli utenti di un'azienda (Intranet) allora bisogna installare i server come Enterprise CA, diversamente se si vuole assegnare i certificati a solamente gli utenti esterni ad un'azienda (Internet) si devono installare i server come Stand-alone CA. La distinzione verte sul fatto che:

Se si vuole usufruire della Certificate Services Web Pages si deve in precedenza installare sul server Internet Information Server (l'installazione di base va più che bene).

Si osservi infine che una volta installato il programma Certificate Services, il computer non può più essere rinominato o tolto dal dominio di Active Directory. L'installazione del Certificate Services prevede anche la creazione delle seguenti cartelle (quelle che riportiamo sono le impostazione di default ma possono venire modificate durante la fase di setup):

Al termine dell'installazione del Certificate Services sono disponibili i seguenti componenti:

I Digital Certificate possono venire rilasciati in modo automatico, andando ad abilitare, all'interno della Public Key Policies la voce Automatic Certificate. In questo modo tutti gli appartenenti di una Organization Unit a cui la Group Policy è stata applicata riceveranno in modo automatico i certificati a loro assegnati.

Per maggiori informazioni sull'installazione di una Certification Authority si può consultare il documento Guide to Setting Up a Certificate Authority.

Attivazione di un infrastruttura PKI

Per realizzare un'infrstruttura di Public Key Infrastructure bisogna utilizzare le seguenti tipologie di server:

Sebbene Windows Server 2003 Web Edition non offra alcun servizio di PKI può essere utilizzato come PKI Client.

A seconda di quale sistema operativo della famiglia Windows Server 2003 si utilizza, si possono avere più o meno funzionalità. In particolare:

Per installare un'Enterprise CA bisogna far parte dei seguenti gruppi di dominio:

Le Enterprise CA possono venire installate nelle seguenti tipologie di macchine:

Le Stand Alone CA possono venire installate nelle seguenti tipologie di macchine:

Per sapere come impostare la permission sul file system del server che ospita l'Enterprise CA ed all'interno di Active Directory, si può consultare la Knowledge Base KB239706. Per modificare le ACL all'interno della Enterprise CA, conviene utilizzare sempre e solamente la MMC chiamata Certification Authority questo per evitare problemi di consistenza fra il registry del server che ospita la CA ed Active Directory.

Per avere informazioni su come installare una CA con Windows 2003 si può consultare il documento Advanced Certificate Enrollment and Management.

Per installare una Standalone CA bisogna far parte del gruppo degli Administrators della macchina.

Per avere maggiori informazioni sulla messa in opera di una Public Key Infrastructure con Windows Server 2003 si può consultare i documenti Best Practice For Implementing a Windows 2003 PKI, Implementing the PKI, Planning Your PKI, Designing your PKI e Enterprise Design for Certificate Services.

Gestione dei certificati

Il ciclo di vita di un Digital Certificate è il seguente:

Affinchè una struttura di PKI possa gestire il ciclo di vita di un Digital Certificate, all'interno della struttura di PKI devono essere disponibili dei programmi in grado di assolvere i seguenti compiti:

I certificati sono gestiti dalle CryptoAPI Certificate Stores. Le CryptoAPI Certificate Stores sono dei siti in cui archiviare i certificati insieme alle proprietà a loro associate. Per convenzione le PKI definiscono cinque Standard Certificate Stores:

Import Export di un Certificato

Windows 2000 mette a disposizione i seguenti formati di file per importare o esportare un Digital Certificate:

Per maggiori informazioni sulla gestione dei certificati si può consultare il documento Guide to End User Certificate Management.

Certificate Template di Windows 2000

Se s'installa un Enterprise CA tramite il programma Certificate Services sono disponibili i seguenti Certificate Template:

Certificate Template di Windows 2003 (V2 Tempates)

Un certificarto che è stato distribuito in base ai V2 Templates non può venire rinnovato con un certificato basato sui V1 Templates, viceversa, un certificato distribuito con i V1 Templates può venire sostituito con un nuovo certificato basato sui V2 Templates.

Come legare un Account ad un Certificato

Per legare un account ad un certificato basta procedere come segue:

Per maggiori informazioni consultare il documento Guide to Mapping Certificate to User

Più in generale, all'interno delle Group Policy Object relativie alla gestione dei certificati, sono disponibili le seguenti sezioni (suddivise per utenti e computer):

Pubblicare Certificati Esterni in Active Directory

Talvolta si ha la necessità di pubblicare in Active Directory dei certificati che provengono da CA esterne a quelle messe in piedi all'interno di un'infrastruttura di PKI aziendale. Per associare questi certificati esterni alle user account degli utenti di Active Directory, si deve utilizzare lo Administrative Tools chiamato Active Directory Users and Computers. All'interno del programma Active Directory Users and Computers bisogna andare nella sezione Published Certificates.

Autenticazione basata su SSL

Per utilizzare il sistema di autenticazione Secure Sockets Layer (o più brevemente SSL) all'interno di un sito web, bisogna procedere nel seguente modo:

Questa tecnica vale anche per il sito di Outlook Web Access (OWA).

Autenticazione con Smart Card

Presenta le seguenti caratteristiche:

Qualified Subordination

Per poter essere utilizzata richiede che i client siano Windows XP e che le CA siano su Windows Server 2003 Enterprise Edition.

Comandi Utili

I sistemi operativi Windows 2000 e Windows 2003, insieme al Resource Kit di Windows 2000 e al Windows Server 2003 Administration Tools Pack mettono a disposizione dei programmi che aiutano nella manutenzione di un sistema PKI. Tra i comandi più utili vi sono:

3.8 Encrypting File System

L'Encription File System (o più brevemente EFS) è la possibilità che viene fornita agli utenti di un dominio di Active Directory o di un Workgroup di criptare digitalmente i propri file o cartelle. Il meccanismo di criptazione si basa sulla coppia Public e Private Keys. La gestione di questa coppia di chiavi si basa sull'archiettettura CryptoAPI di Windows 2000. L'architettura su cui si basa EFS è la seguente:

Per leggere o aprire un file criptato non è necessario prima decriptarlo: lo EFS procede in modo automatico all'operazione di decriptazione prelevando la chiave dal System's Key Store. Per prelevare la Symmetric Key con cui è stato criptato il file, utilizza la Private Key dell'utente. La necessità di decriptare il file o la cartella si presenta solamente se si desidera rendere disponibile il file o la cartella anche ad altri utenti.

Per maggiori informazioni sul Encrypting File System si può consultare il documento Guide to Encrypting File System. Per sapere invece qual'è il modo migliore d'impostare l'Encrypting File System si può consultare la Knowledge Base KB223316.

Caratteristiche di EFS

L'implementazione di EFS da parte di Windows 2000 presenta le seguenti caratteristiche:

EFS Recovery Policy

L'operazione di recupro di un file criptato viene eseguita da un amministratore di rete che gode del privilegio di Recovery Manager. L'istituzione di un Recovery Manager fa parte della strategia di realizzazione del EFS: l'EFS non può essere messo in piedi se non dopo avere specificato un Recovery Manager. Tecnicamente per Recovery Manager s'intende un'account di dominio o di un workgroup a cui resta associata la Recovery Agent Policy. Se la macchina in cui è stato abilitato l'EFS appartiene ad un Workgroup, per default il ruolo di Recovery Manager viene svolto dall'Administrator locale della macchina. Esiste però un'eccezzione a questa regola. Se s'installa una macchina Windows 2000 attivando le seguenti caratteristiche (per maggiori informazioni si consulti la KB255026):

Allora:

Quando s'installa il primo domian controller di dominio si definisce anche l'account (di solito è l'utente Administrator) che ricoprirà il ruolo di Recovery Manager. Una volta che è stata messa in piedi Active Directory, solamente i membri del gruppo dei Domain Admins possono modificare la Recovery Agent Policy. Per modificare l'impostazione di default della Recovery Agent Policy bisogna andare a operare sul Primo Domain Controller Installato. Se la macchina invece appartiene ad un semplice Workgroup, allora solamente i membri del gruppo degli Administrators possono modificare la Recovery Agent Policy. Compito del Recovery Manager è quello di recuperare i file criptati da un utente il quale ha in qualche modo compromesso irreversibilmente la propria Private Key. All'interno della Recovery Agent Policy viene inserita una Public Key (che è contenuta nel File Recovery Certificate) con la quale si possono decriptare tutti i file o cartelle criptati da qualunque utente del dominio di AD o del Workgroup. In nessun modo si riesce a conoscere la Private Key dell'utente che ha avuto bisogno della Recovery Agent Policy. La Recovery Agent Policy può venire implementata su un qualuque Domain Controller del dominio di AD e poi estesa a tutti i computer del dominio di AD. La Recovery Agent Policy può essere delegata a più di un utente sfruttando i meccanismi, nativi, di delega di Active Directory. Più precisamente, la Recovery Agent Policy viene assegnata al computer o ai computers su cui opera o operano i Recovery Manager. Se si utilizza la Default recovery Policy non c'è mai bisogno di richiedere un File Recovery Certificate. Se non si vuole però utilizzare la Default recovery Policy allora bisogna definire almeno un Recovery Manager e assegnargli un File recovery Certificate. Per poter però evitare di utilizzare la Default recovery Policy bisogna che siano soddisfatte le seguenti condizioni:

Per decriptare un file o una cartella di un utente che ha compromesso la propria Private Key si può prcedere nel seguente modo:

  1. Eseguire un backup del file o della cartella criptata attraverso il programma Backup che si trova nei System Tools di Windows 2000. Eseguire il job di salvataggio su di un file *.bkf.
  2. Copiare il file *.bkf all'interno del computer su cui opera il Recovery Manager. Si ricordi che la Recovery Agent Policy viene assegnata ai computer e non agli utenti. Per copiare il file *.bkf si possono utilizzare due metodi:
    • Copiare il file *.bkf prima su di un cdrom o floppy disk e poi, a partire da questi supporti, sul computer su cui opera il Recovery Manager.
    • Inviare via email il file *.bkf al Recovery Manager.
  3. Ripristinare il file o la cartella salvati all'interno del file *.bkf utilizzando il programma Backup che si trova nei System Tools di Windows 2000.
  4. Facendo uso dello snap-in Certificate recuperare dal file *.pfx che contiene il File Recovery Certificate, la Public Key con cui decriptare il file.
  5. Decriptare il file facendo uso o del programma Windows Explorer o del programma Cipher.exe.
  6. Inviare il file decriptato all'utente che ne aveva bisogno.

Si osservi che il ruolo di Recovery Manager è valido solamente all'interno dei confini di sicurezza rappresentati da un dominio di Active Directory, ciò significa che anche se due domini di Active Directory sono legati da un legame di parentela, i loro Recovery Manager possono essere diversi. Pertano non necessariamente il Recovery Manager del dominio padre è anche il Recovery Manager del dominio figlio. In quest'ottica, se su di una macchina Stand Alone s'attiva l'EFS e si criptano poi dei file e successivamente si unisce questa macchina ad un dominio Active Directory, i file criptati quando la macchina era ancora Stand Alone riconoscono come Recovery Manager solamente il Recovery Manager locale della macchina, prima che questa fosse unita al dominio.

Se si decide di gestire il ruolo di Recovery Manager tramite le Group Policy Object si devono tenere ben presente le seguenti regole:

Visto il ruolo importante che svolge il Recovery Manager, vista l'importanza strategica della Recovery Agent Policy, può risultare conveniente salvare il File Recovery Certificate. Per sapere come salvare e mettere al sicuro il File Recovery Certificate si può consultare la Knowledge Base KB241201.

Come assegnare il File Recovery Certificate

Per assegnare il File recovery Certificate ad un Domain Group di Active Directory si può procedere come segue (per rendere la spiegazione più semplice, supporremo di assegnare il File recovery Certificate ad un gruppo chiamato Domain Recovery Agents):

In questo modo, tutti gli utenti che appartengono al gruppo Domain Recovery Agents possono svolgere il ruolo di Recovery Manager. Per assegnare invece un EFS Recovery Manager localmente ad una macchina, sia Stand Alone o appartenente ad un Active Directory Domain, si deve utilizzare l'Add Recovery Key Agent Wizard che si trova all'interno delle Local Security Policy.

Comandi Utili

Alcuni comandi che possono tornare utili nella gestione di EFS sono:

3.9 Internet Protocol Security

Internet Protocol Security (o più brevemente IPSec) è una proposta, evidenziata dalle RFC 2411 e RFC 2401, di standard per risolvere i problemi di sicurezza di comunicazione fra due o più computer all'interno di una rete privata (ad esempio una LAN) o pubblica (ad esempio Internet). In particolare IPSec consente di creare comunicazioni autenticate e criptate fra due computer.

I sistemi operativi Windows 2000 o superiori mettono a disposizione dell'amministratore di rete una console amministrativa, chiamata IP Security Policy Management, con la quale impostare le policies di IPSec o a livello di dominio di Active Directory o a livello di singolo computer (relativamente a quei computer che non appartengono ad un dominio di Active Directory). Una volta realizzate le Policies di IPSec queste vengono assegnate o alle Organization Unit o ai computer o agli utenti tramite i soliti strumenti di gestione delle Group Policy.

La comunicazione tramite IPsec è una comunicazione bi-direzionale, pertanto entrambi i computer coinvolti devono decidere di utilizzarla. Ne segue che le politiche legate all'utilizzo di IPSec devono essere le medesime per entrambi i computer e pertanto esse vanno impostate su entrambi. Da quanto detto si deduce che IPSec non supporta sia indirizzi multicast sia indirizzi broadcast, al contrario supporta indirizzi unicast.

Il sistema operativo Windows 2000 contiene in se un'implementazione del Internet Key Exchange (o più brevemente IKE) realizzata dal IETF nella RFC 2409. Lo IKE ha il compito di negoziare, a beneficio delle parti, la tipologia di comunicazione che deve avvenire fra due computer, ovvero se la comunicazione deve utilizzare IPSec o meno.

Il computer che invia i dati li cripta prima che essi raggiungano il mezzo trasmissivo, il computer che riceve i dati li decripta una volta che essi hanno lasciato il mezzo trasmissivo. IPSec è del tutto trasparente all'utente. IPSec consente un'amministrazione centralizzata, in particolare permette, quando un computer di un dominio di Active Directory si accende, di far ricevere in modo automatico, le Gorup Policy di sicurezza IPSec relative al computer in parola, evitando in tal modo di configurare individualmente ogni singolo computer del dominio.

IPSec è processo routable, ovvero può passare attraverso un router e quindi fluire da una LAN ad un'altra. Non necessariamente il router che separa le due LAN deve supportare IPSec. IPSec opera a livello IP (ovvero al livello 3 della pila OSI, il Livello Network), in questo modo è in grado di proteggere tutti i livelli superiori a quello IP. Pertanto tutti protocolli che si basano sul livello IP, come ad esempio il TCP, l'UDP o lo HTTP, vengono in tal modo protetti. Da questo punto di vista, IPSec è una sorta di generalizzazione del protocollo SSL.

IPSec può essere utilizzato nei seguenti scenari:

Architettura di IPSec

IPSec, all'interno di Windows 2000, viene realizzato sfruttando i seguenti componenti:

Lo IPSec Policy Agent, quando parte, avvia i seguenti servizi:

Permessi

Per poter modificare, aggiungere o cancellare una ploicy di IPSec, bisogna godere o l'uno o l'altro dei seguenti privilegi:

IPSec Policies

I sistemi operativi Windows 2000 o superiori mettono a disposizione diverse IPSec Policies predefinite (di default nessuna di queste policy è attiva) per aiutare l'amministratore di sistema nel suo lavoro. Queste policies sono le stesse sia per i computer che apprtengono ad un dominio di Active Directory sia per quelli che non vi appartengono. Queste polices predefinite sono:

Le policies predefinite possono essere viste anche all'interno dello snap-in di MMC Group Policy, all'interno della sezione IP Security Policies on Active Directory:

Group Policy Object --> Computer Configuration --> Windows Settings --> Security Settings --> IP Security Policies on Active Directory

Il processo con cui due computer decidono di utilizzare o meno IPSec prende il nome di Security Association (SA). La Security Association si dice essere:

Le IPSec Policies sono composta da regole (IP Security Rules) che a seconda delle circostanze, vengono attivate. Queste regole sono il frutto di diverse impostazioni che riguardano:

Esistono due tipologie di regole a seconda che si desideri creare una comunicazione protetta fra due computer di una stessa LAN o una comunicazione protetta fra due LAN distinte. Nel primo caso si parla di IPSec in Transport Mode nel secondo di IPSec in Tunnel Mode:

All'interno di ciascuna regola si possono impostare i seguenti argomenti:

In generale, affinchè sia possibile utilizzare IPSec, deve valere almeno una delle seguenti considerazioni:

Quando si creano IP Filter conviene, se si desidera impostare configurazioni sicure, predisporre il filtro sia nel traffico IP in ingresso sia nel traffico IP in uscita.

Per avere maggiori informazioni su come configurare IPSec si può consultare il documento Step-by-Step Guide to End-to-End Security.

Caratteristiche di IPSec

IPSec presenta le seguenti caratteristiche:

Protocolli che non supportano IPSec

Per la sua natura, IPSec, non consente di rendere sicuri i seguenti protocolli:

Strumenti di diagniostica e gestione di IPSec

Il Resource Kit di Windows 2000 Server mette a disposizone diversi strumenti per gestire l'implementazione di IPSec. In particolare:

Per vedere se un computer sta utilizzando IPSec basta procedere come segue:

3.10 Simple Network Management Protocol

Il Simple Network Management Protocol, o più brevemente SNMP, è un protocollo standard di Internet, nato con lo scopo di monitorare lo stato di Hub e Router. L'implementazione del protocollo SNMP di Windows 2000 consente di monitorare i seguenti dispositivi:

Struttura logica di SNMP

Il Simple Network Management Protocol verte sullo scambio di informazioni fra il dispositivo che svolge il ruolo di SNMP Agent e quello che raccoglie le informazioni, chiamato SNMP Management System. Un SNMP Agent, prima d'inviare i suoi dati allo SNMP Management System l'immagaziona in una struttura ordinata di dati chiamata Management Information Base (più brevemente MIB). Per ogni tipologia d'informazione che lo SNMP Agent deve raccogliere, corrisponde un MIB. Quando s'installa il protocollo SNMP su una macchina Windows 2000, si trasforma questa macchina in un SNMP Agent.

Gli SNMP Agent e gli SNMP Management System vengono raggruppati in Comunità, solamente i membri di una stessa comunità possono scambiarsi informazioni fra di loro. Per raggiungere questo scopo viene implementato un meccanismo di autenticazione (piuttosto blando) fra lo SNMP Agent e lo SNMP Management System. Questo meccanismo di autenticazione verte sulla parola chiave che contraddistingue la comunità stessa. Uno stesso SNMP Management System o uno SNMP Agent possono appartenere, contemporanemante, a più comunità distinte fra loro. Di default sia gli SNMP Management System sia gli SNMP Agent appartengono alla comunità Public.

Parametri di un SNMP Agent

Un SNMP Agent viene caratterizato in base ai volori che assumone le seguenti variabili:

Comandi Utili

Il Windows 2000 Resource Kit mette a disposizione degli amministratori di rete il comando SNMPUtil.exe con cui eseguire operazioni di diagniostica sulla configurazione del SNMP Agent.

© 2020 Home Works - all rights reserved
Questo sito ha superato il test W3C Validator HTML e CSS