Il contesto Consentire l’accesso ad Internet da tutti i computer di una scuola è ormai diventato l’obiettivo minimo di ogni responsabile di laboratori e reti informatiche. Un numero crescente di insegnanti è consapevole del valore aggiunto che i servizi della Rete possono apportare alla didattica: ricerche sul web, comunicazioni sincrone e asincrone, esperienze di apprendimento e collaborazione a distanza, formazione in servizio, attività amministrative, e l’elenco si potrebbe allungare. Una volta realizzato il collegamento, tuttavia, emergono numerosi fattori di rischio, che spostano l’attenzione dell’amministratore della rete scolastica dal problema dell’accesso a quelli della sicurezza. Il "senso comune informatico" è in generale consapevole della possibilità che una rete locale aperta in modo stabile al mondo esterno, come avviene per esempio con i diffusi collegamenti ADSL, sia oggetto di attacchi finalizzati a trafugare dei dati, o a inficiare servizi e funzionalità interni. Altrettanto ovvia è la preoccupazione che gli alunni, a qualunque fascia d’età appartengano, possano abusare della possibilità loro offerta di navigare liberamente nel web per reperire risorse non consentite. Forse un po’ meno ovvio è il fatto che i computer della rete locale scolastica potrebbero essere utilizzati come basi di attacchi ad altre strutture informatiche interne o esterne, o volontariamente da alcuni studenti particolarmente smaliziati, o (come è forse più probabile) perché involontariamente sono stati scaricati ed installati in alcune macchine dei cavalli di troia o dei worms che aprono porte e servizi dall’interno senza che gli utenti e lo stesso amministratore di rete ne siano consapevoli. Oppure che il download intensivo di contenuti multimediali, o la realizzazione di connessioni peer to peer possono rapidamente esaurire anche la banda più generosa, e danneggiare lo svolgimento di attività didattiche o amministrative legittime. Se non bastasse il senso comune, la nuova normativa in materia di privacy (D.lgs. 196/2003), pone la sicurezza informatica e delle comunicazioni al centro delle preoccupazioni del legislatore, e di conseguenza di tutte le organizzazioni che - come le scuole - trattano dati riferiti a persone, i quali necessitano a vario titolo di trattamento riservato. Le circostanze appena accennate fanno intendere che la figura dell’amministratore di una rete scolastica potrebbe essere caricata di una responsabilità oggettiva per gli usi e gli abusi che vengono fatti delle strutture informatiche dell’Istituto. Tale responsabilità potrebbe precisarsi, inoltre, in vista della previsione, sempre a norma del D.lgs. 196/2003, che la scuola si doti di un Documento programmatico sulla Sicurezza, nel quale, tra l’altro, deve essere definita "la distribuzione dei compiti e delle responsabilità nell’ambito delle strutture preposte al trattamento dei dati", il che lascia prevedere un coinvolgimento diretto o indiretto, tra gli altri, dell’amministratore dei sistemi informativi negli adempimenti previsti dalla normativa (v., a questo proposito, anche il documento dell’OTE sulla Privacy). Di conseguenza, se l’obiettivo di collegare tutti i computer della scuola alla rete locale e ad Internet appare raggiunto, potrebbe ancora rimanere da realizzare il compito complementare di garantire la protezione di questo collegamento. Anche le Linee guida per la sicurezza informatica nelle scuole, nelle quali vengono offerte delle utili indicazioni di carattere generale riguardanti i diversi aspetti della confidenzialità, integrità e disponibilità dei dati, sottolineano (al par. 4) che uno degli ambiti nei quali vanno implementate con maggiore attenzione delle politiche di sicurezza è quello della sicurezza perimetrale, sia rispetto a rischi che provengono dall’esterno, sia rispetto a rischi che provengono dall’interno. Per realizzare questa finalità è possibile ricorrere a diverse soluzioni, le quali prevedono come loro pare integrante la realizzazione di servizi di firewall, logging, caching, content filtering. In questo articolo intendo discutere Microsoft Intenet Security and Acceleration Server 2000 (d’ora in poi, ISA Server), uno dei software con delle caratteristiche che lo rendono interessante ai fini che ci proponiamo. Vorrei però precisare che non intendo suggerire che questa è l’unica soluzione possibile, o la migliore. Le possibili risposte alle esigenze sopra descritte sono molte, e vanno dalla installazione di componenti hardware dedicati, alla realizzazione degli stessi servizi con software open source o altri software proprietari. Qui concentrerò l’attenzione su ISA Server in quanto è una soluzione che si propone come ben integrata con la disponibilità, nella maggior parte delle scuole, di server con sistema operativo Windows 200x, senza escludere o pregiudicare altre soluzioni, le quali potranno essere oggetto di analisi successive. E’ appena il caso di sottolineare che le informazioni qui contenute intendono proporsi come una guida tecnica alla realizzazione di specifiche funzionalità, e non sono esaustive né di tutte le caratteristiche del software esaminato, né tantomeno di tutti gli adempimenti previsti dalla normativa in materia.
Caratteristiche di ISA Server Come molti software analoghi, ISA Server offre diverse funzionalità, tra le quali:
ISA Server svolge queste funzioni suddividendo i segmenti di rete ai quali è collegato in una zona interna ed una esterna: tipicamente, da una parte la rete LAN, dall’altra Internet, e collegando queste due zone mediante tre servizi:
Come Server NAT, ISA Server effettua il Network Address Translation. Questo è un aspetto importante della sicurezza. Un server NAT consente di aprire la rete locale al "mondo esterno", concentrando in un singolo punto tutto il traffico. Realizza questo risultato convertendo gli indirizzi privati della rete locale in un indirizzo pubblico. Quando un client della rete interna cerca di collegarsi ad un server Internet, ISA Server effettua il collegamento sostituendo, nell’intestazione del pacchetto IP, l’indirizzo del client con il proprio indirizzo esterno. In Internet viene esposto solo l’IP del server NAT. Una volta reperita la risorsa, il server NAT la restituirà al client dal quale era provenuta la richiesta originaria, riscrivendo, nell’intestazione IP dei paccheti in entrata, l’indirizzo IP del client. Senza questa traduzione, ciascun computer della rete interna dovrebbe aver un IP pubblico; ma ciò non è consigliabile, innanzitutto perché per il numero di IP pubblici a disposizione degli ISP è limitato ed in via di esaurimento; in secondo luogo in quanto è più prudente evitare di esporre lo schema di indirizzamento e le risorse condivise della propria rete locale su Internet. Come Proxy Server, ISA Server compie tutte le operazioni sulla rete Internet impersonando il computer della LAN che ha effettuato la richiesta, ed effettua il caching delle risorse reperite in Internet a vantaggio dei propri client: quando un client richiede una pagina, ISA Server intercetta la richiesta, e la inoltra al server web. Prima di restituire la risorsa web trovata, ISA Server ne salva una copia sul disco fisso locale. Se un altro client richiede la risorsa, il servizio proxy, piuttosto che reperire la pagina in Internet, la recupererà dal proprio disco fisso (o, in determinati casi, dalla propria RAM), e la restituirà al client molto più velocemente e lasciando banda disponibile per altre richieste. E’ possibile definire dei criteri di scadenza delle pagine web presenti nella cache di ISA, in modo da ottenere una appropriato bilanciamento tra l’esigenza di reperire la risorsa velocemente, e quella di consegnare ai client delle risorse aggiornate. Come Firewall, Isa Server ispeziona tutti i pacchetti in entrata e in uscita, decidendo, sulla base di criteri definiti dall’amministratore, quali di essi possono attraversare il firewall e quali no. Questa operazione può avvenire a diversi livelli, che possono essere così schematizzati:
Molti sono gli altri aspetti di Isa Server che meriterebbero attenzione nel nostro contesto. Per fare solo un paio di esempi: la sua capacità di fungere da server per le comunicazioni VPN potrebbe giovare nel caso di scuole dislocate su più plessi che hanno bisogno di condividere le loro risorse; oppure la possibilità di creare delle Zone demilitarizzate potrebbe consentire ad una scuola, che avesse una connessione ad Internet con banda in uscita sufficientemente ampia, di pubblicare un proprio server. In questo articolo ci atterremo però alle informazioni necessarie per dare al server e ai suoi client una configurazione di base accettabile nei casi più comuni che si possono presentare in una rete scolastica.
Installare e configurare ISA Server e i suoi client In questa sezione vedremo: Come si installa ISA Server Come si realizza una configurazione di base del server Come si possono configurare i client per la navigazione in Internet Ipotizzeremo uno scenario molto semplice:
Installare ISA Server a) Preparazione del server ISA Server si installa su Windows 2000 Server o Windows Server 2003. Innanzitutto è sempre bene aggiornare il Sistema operativo all’ultimo service pack disponibile, ed eseguire Windows update per installare le ultime patch. In secondo luogo, bisogna configurare le schede di rete. Alla scheda esterna assegneremo come gateway predefinito l’indirizzo IP interno del router (192.168.1.254), in modo che ISA Server instradi verso il router tutti i pacchetti destinato ad indirizzi diversi da quelli delle due sottoreti a cui appartiene (tipicamente, i pacchetti con IP pubblico). Sulla scheda esterna dovremo pure configurare gli IP dei server DNS del nostro ISP, nel caso in cui configurassimo i client per chiedere ad ISA Server la risoluzione dei nomi (come vedremo dopo, questo accadrà se configureremo i client come Web proxy clients).
Inoltre, sulla scheda esterna dovremo disabilitare i servizi Client for Microsoft networks, File and printer sharing for Microsoft networks: e disabilitare Netbios su TCP/IP. Non vogliamo che il server risponda su queste porte a richieste provenienti da Internet: sarebbe un grosso fattore di vulnerabilità. In generale, è bene disabilitare o disinstallare tutti i servizi non strettamente indispensabili al funzionamento del server. Ma nel nostro scenario c’è un solo server; e questo probabilmente dovrà fungere da server DNS, Domain controller, file e print server, web server interno e così via. In questo caso - che non è certo quello ideale - bisogna fare in modo che ciascun servizio venga configurato per ascoltare solo sulla scheda interna, come abbiamo appena fatto per i servizi Workstation, Server e NetBT. Sulla scheda esterna dovremo pure disabilitare l’opzione di registrare l’indirizzo presso il server DNS: il nostro provider non gestisce, di solito, un server Dynamic DNS, né a noi per ora ciò potrebbe servire: Per quanto riguarda la scheda interna, lasciamo in bianco il default gateway. Possiamo lasciare pure in bianco le impostazioni relative al DNS, a meno di non aver installato sul server altri servizi che ne richiedano uno interno (per esempio, un Domain controller).
b) Installazione di ISA Server Il processo di installazione di ISA Server non differisce, per molti aspetti, da quello di qualunque altro software; vi è però qualche passaggio su cui vorrei attirare l’attenzione:
La cache, in ISA Server, è una parte del dico fisso nella quale vengono salvati i file visitati di recente, per renderli disponibili più velocemente ai clients ad una successiva visita. In questa fase si può scegliere la dimensione della cache (a partire dal minimo consigliato di 100 MB), e il disco in cui collocarla. Se si hanno più dischi fisici, è opportuno disporre la cache su un disco diverso da quello di usato dal Sistema operativo o da ISA Server, o meglio ancora distribuirla su più dischi, in quanto le operazioni di lettura/scrittura sulla cache possono essere piuttosto intense, a seconda del traffico Internet generato dalla nostra LAN. Le partizioni in cui va memorizzata la cache devono comunque essere formattate con file system NTFS.
Si tratta di una tabella nella quale vanno indicati tutti gli indirizzi che ISA server può considerare "interni", cioè appartenenti ai computer serviti da ISA. Nel nostro scenario basterà specificare manualmente l’intervallo di indirizzi 192.168.0.0/24. Oppure potremo lasciare che ISA Server costruisca da solo la LAT: in questo caso (a) potranno essere inserite le classi di indirizzi privati (10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16); oppure (b) potremo assegnare alla LAT la classe di indirizzi corrispondenti all’indirizzo specificato per la scheda di rete interna; se si opta per quest’ultima soluzione bisogna indicare al setup quale scheda va considerata interna. Nel nostro esempio, andrà tolta la spunta dalla prima casella, in quanto la scheda di indirizzo 192.168.1.1, pur avendo un indirizzo privato, va considerata "esterna" (è quella che si interfaccia con il router che dà l’accesso ad Internet). Andrà invece spuntata la scheda con l’indirizzo interno: Ecco come si presenta la LAT, costruita dal programma di setup in base alle impostazioni che avremo scelto: Una volta completata l’installazione, sarà buona norma aggiornare anche ISA Server con l’ultimo Service Pack disponibile (ad oggi, il Service Pack 2). Nota sull’installazione su Sistema operativo Windows Server 2003 La procedura è ancora quella descritta. Tuttavia, durante e alla fine dell’installazione l’utente verrà informato che per attivare ISA sarà necessario installare il Service Pack: Inoltre bisognerà disabilitare Internet Connection Firewall dalla scheda Servizi. Iniziare a configurare il server Un’analisi dettagliata delle diverse funzionalità del server è, come ho già sottolineato, oltre lo scopo di questo breve articolo. Qui daremo solo un esempio particolare, personalizzando le cui indicazioni l’amministratore della rete dovrebbe poter realizzare in modo rapido un collegamento ad Internet condiviso attraverso ISA Server. Supponiamo di voler dare l’accesso ad internet, per il solo scopo di navigare sul web e con esclusione di altri protocolli (SMTP, POP3, FTP ecc.), alle macchine di un laboratorio informatico della nostra rete scolastica, i cui indirizzi IP siano, poniamo, 192.168.0.200 - 192.168.0.215. Per realizzare questo obiettivo dovremo configurare ISA Server per filtrare i pacchetti
Innanzitutto dovremo accertarci di avere i "mattoni" con i quali costruiremo le nostre regole di accesso ad Internet. Apriamo lo snap-in di ISA Server ed esaminiamo il contenuto del ramo Policy elements. Alcuni di questi elements sono già presenti: se apriamo la cartella Protocol definitions, possiamo scorrere l’elenco di una serie di protocolli già definiti in ISA Server: Oltre ai protocolli preconfigurati, l’utente può definirne di nuovi. Ma i protocolli che ci serviranno per l’operazione richiesta sono già presenti:
Altri Policy elements, dovremo invece crearli noi: aprendo la cartella Client Address Sets, la troveremo vuota. Per inserire il range di indirizzi a cui dovremo concedere l’accesso ad Internet, facciamo click destro su Client Address Sets, ed impostiamo il voluto intervallo di indirizzi, dandogli come nome "Laboratorio Informatico": Il risultato sarà il nuovo Policy element qui visualizzato: Adesso passiamo a costruire le nostre regole di accesso. Appena installato, ISA Server è configurato per bloccare tutti i pacchetti. Per rendercene conto, esaminiamo un altro dei rami dello snap-in di "ISA Management": Access policy. Il primo sotto-ramo si chiama Site and content rules. E’ utile per specificare l’indirizzo di siti web o ftp la cui visita può essere consentita o negata agli utenti. Per default, durante l’installazione viene creata una regola chiamata Allow rule, che è molto permissiva: essa "consente" a "tutti i client" di visitare "qualunque sito" e scaricare "qualunque contenuto" in "qualsiasi momento". Ovviamente, si possono impostare regole (molto) meno permissive, che delimitano in tutte le combinazioni possibili le opzioni che ho virgolettato. Ma per il nostro esempio così va bene. Il secondo insieme di regole, le Protocol rules, è invece vuoto: Quando viene avviata la richiesta di una risorsa internet da un client interno, se è definita una Protocol rule corrispondente, ISA Server apre una porta in modo "dinamico" per inoltrare la richiesta al server esterno, e la richiude subito dopo. In ISA Server, ciò che non è esplicitamente consentito è vietato: quindi, se non vi sono protocol rules già definite, il server non farà passare nessuna richiesta tra la schede interna ed esterna, impedendo la navigazione e qualunque altra attività in Internet ai client. Nel nostro esempio, vediamo come si fa a creare una Protocol rule che consenta ai client di navigare sul web. Facendo clic destro su "Protocol rules", selezioniamo "New" e poi "Rule"; parte una wizard che ci guiderà nella costruzione della regola di accesso. Diamo alla regola un nome, per esempio "Navigazione Web", e facciamo clic su "Avanti". Nella seconda schermata, lasciamo "Allow" (dobbiamo "consentire" qualcosa). Nella terza schermata, selezioniamo "Selected protocol" (non vogliamo consentire il passaggio di tutti i protocolli); quindi scegliamo: HTTP e HTTPS: La schermata successiva ci chiede di specificare gli orari nei quali vorremo consentire questi collegamenti: possiamo lasciare "Always". La prossima è una schermata che ci permette di definire i client e gli utenti ai quali si applica la regola. Qui possiamo decidere di consentire, o non consentire, ad alcuni client o utenti l’uso di determinati protocolli. Nel nostro esempio dovremo selezionare un determinato Client address set: Adesso selezioniamo il Client address set "Laboratorio informatico", creato prima: Ma non abbiamo ancora finito. Per ora i client potranno "navigare" solo utilizzando gli indirizzi IP degli host di destinazione: se sono configurati per risolvere le URL utilizzando un server dns pubblico (come è nel caso dei client SecureNat: v. sotto), non potranno utilizzare gli FQDN: le query DNS passano su una porta che non abbiamo ancora aperto. Per farlo, creiamo una nuova protocol rule, diciamo Risoluzione DNS, nella quale selezioniamo l’appropriato protocollo: Ecco come si presenta adesso la cartella Protocol rules: È buona prassi, per attivare le modifiche, riavviare i servizi rilevanti. Sotto Monitoring, apriamo il ramo Services. Facciamo click destro su Web proxy, e selezioniamo Stop. Facciamo la stessa cosa con Firewall. Ripetiamo la procedura per riavviare i servizi scegliendo Start. Adesso, per quanto riguarda ISA Server, i client potranno navigare.
Configurare i client Per vedere se la configurazione funziona, dovremo spostarci su un client: per default la possibilità di accedere ad internet direttamente dal server ISA è disabilitata per ragioni di sicurezza. Affinché un client della rete interna possa accedere ad internet deve essere opportunamente configurato. Isa Server può avere tre tipi di client:
Client SecureNAT Qualunque sistema operativo esegua, un client può essere configurato in modo da avere come gateway predefinito l’indirizzo IP interno del server ISA, e come DNS gli indirizzi dei server DNS gestiti dall’ISP: Quando sul client si attiva il browser web per aprire una pagina ad un’URL specificata dall’utente, la richiesta di risoluzione del nome verrà inviata al server DNS definito per la sua scheda di rete. Trattandosi di un’indirizzo su una sottorete diversa da quella di appartenenza, la richiesta verrà inviata al gateway, cioè al server ISA; quest’ultimo, disponendo di una potocol rule che lo consente (la nostra Risoluzione DNS), inoltrerà la richiesta al server di destinazione, e restituirà la risposta (cioè l’indirizzo IP del server web richiesto) al client. Questi cercherà di connettersi alla porta 80 del server web, ovviamente passando per il proprio gateway, cioè per il server ISA; il quale provvederà a reperire la risorsa e a restituirgliela. Se è possibile, ISA server effettuerà il caching della pagina, in modo da poter servire una successiva richiesta più velocemente. I client SecureNAT sono facili da implementare, e possono utilizzare qualsiasi protocollo per i quali siano stati definiti in ISA Server dei criteri che ne permettono l’uso. Tuttavia, vanno incontro ad alcune limitazioni, la più importante delle quali è che non possono passare al server ISA informazioni di autenticazione. In altre parole, quando definiamo una protocol rule, ad un certo punto la wizard ci chiede se la vogliamo applicare a tutti i client, oppure solo ad un gruppo di client (che dovremo specificare utilizzando i loro indirizzi IP: è quello che abbiamo fatto) oppure a utenti o gruppi di utenti (registrati sul database locale del server o, se si dispone di un dominio, in Active Directory): quest’ultima opzione non può essere applicata a client SecureNAT. Se vorremo poter filtrare gli accessi dei client in base agli account degli utenti dovremo configurare i client in uno dei due modi seguenti. Client Web proxy In questo caso ad essere configurata non è la scheda di rete del client (i cui campi "default gateway" e "server DNS" possono anche rimanere vuoti), ma il software che cerca di connettersi ad Internet, come il browser, o un’altra "applicazione web" (per esempio: Symantec Live Update). Qualunque computer della LAN che esegua un’applicazione web può essere quindi configurato come Web proxy Client. Basta impostare il browser per connettersi alla porta 8080 su cui il server ISA ascolta le richieste di questo tipo:
Anche l’opzione "Usa HTTP 1.1 con connessioni tramite proxy" può in molti casi migliorare le prestazioni, perchè consente di fruire della compressione dei dati e delle connessioni persistenti: Il vantaggio di questo tipo di client è che sono facili da configurare (è possibile anche impostare la configurazione automatica, ma non ne parleremo qui), non richiedono software aggiuntivo, e soprattutto potranno inviare le informazioni di autenticazione al server proxy. Tuttavia, i protocolli utilizzabili per questo tipo di connessione sono solo HTTP, HTTPS, FTP (e Gopher). Ad esempio, se cerciamo di collegarci ad un server Realaudio per scaricare un video in streaming mantenendo le impostazioni di default del Realplayer (protocollo RTSP, porta 554), non ci riusciremo, anche se in ISA avremo definito la appropriata Protocol rule. Per usare protocolli diversi da quelli elencati bisogna configurare i client come SecureNAT, oppure Firewall client. Firewall Client Richiede un software aggiuntivo, i cui file di installazione vengono copiati e condivisi sul server al momento del setup di ISA Server, che può essere installato solo su client Microsoft (Windows 95 e seguenti). Anche il Firewall Client delega la responsabilità per la risoluzione dei nomi al sever ISA,come il Web proxy client. E’ però adatto ad eseguire applicazioni che utilizzano protocolli diversi da quelli riconosciuti da questi ultimi. Oltre alla limitazione dovuta alla piattaforma che lo supporta, il Firewall client richiede un po’ di lavoro in più per l’installazione, che deve essere effettuata su ogni client della rete (a meno di non avere Active directory e utilizzare le Group policies per distribuirlo: ma questo è possibile solo con client Windows 2000 e Xp Professional). La configurazione del client è, per il resto, automatica. Per installarlo basta collegarci dal client alle risorse condivise dal server ISA. Tra le cartella condivise, ve ne è una che ha il nome Mspclnt. Apriamo la cartella e lanciando il setup si avvierà una wizard nella quale non avremo quasi nulla da decidere. Alla fine dell’installazione, constatiamo che
Nota conclusiva Scopo di questo articolo è di introdurre alcuni concetti e alcune procedure di base, sufficienti a mettere chi lo legge in condizioni essere subito operativo con Microsoft Internet Security and Acceleration Server e di comprenderne i principi generali di funzionamento. Un approfondimento di ciascuno degli argomenti affrontati è oltre gli scopi di questo scritto, in quanto ognuna delle funzionalità illustrate, e le molte cui qui non si è neanche accennato, meriterebbero un articolo a parte. A chi vuole sviluppare queste tematiche, consiglio di esplorare i siti web: e di interrogare la Knowledge base della Microsoft impostando il campo "Seleziona un prodotto" a "Internet Security and Accelaration Server". 24 maggio 2004 |