Linux Server per l'amministratore di rete 8850329873, 9788850329878 [PDF]

Zitiervorschau

---

LINUX SERVER PER L'AMMINISTRATORE DI RETE Quarta edizione

Silvio Umberto Zanzi

© Apogeo s.r.l. - socio unico Giangiacomo Feltrinelli Editore s.r.l. ISBN edizione cartacea: 978-88-50-32987-8

Il presente file può essere usato esclusivamente per finalità di carattere personale. Tutti i contenuti sono protetti dalla Legge sul diritto d'autore. Nomi e marchi citati nel testo sono generalmente depositati o registrati dalle rispettive case produttrici.

L'edizione cartacea è in vendita nelle migliori librerie.

~

Seguici su Twitter @apogeonline

Introduzione È passato molto tempo da quando Linus Torvalds annunciò su comp.os.minix che stava scrivendo un sistema operativo e che era curioso di ricevere qualche commento da parte di chiunque utilizzasse Minix. Secondo le parole di Torvalds doveva essere “solo un hobby, non sarà né grande, né professionale come GNU”. Linus Torvalds non avrebbe certamente pensato in quella sera d’agosto del 1991 che, solo pochi anni dopo, il suo hobby sarebbe invece diventato molto importante. Oggi, infatti, Linux rappresenta uno strumento di business miliardario per un numero incalcolabile di aziende in tutto il mondo. Per Linux si costruiscono multinazionali, si realizzano campagne pubblicitarie a copertura mondiale, si eseguono fusioni, si scrivono milioni di righe di codice ogni anno, si pubblicano libri e riviste, si creano strategie aziendali globali, si aprono cause e si realizzano migrazioni colossali. Tutte operazioni che muovono grandi quantità di denaro e creano opportunità, posti di lavoro e sviluppo. Se Linux fosse solo questo non ci sarebbe però nulla di speciale. Molte aziende in tutto il mondo e in tempi differenti hanno creato ricchezza materiale e sviluppo nei vari settori dello scibile umano. Quello che fa realmente la differenza è il fatto che Linux non è un’azienda o un prodotto commerciale, ma piuttosto un bene comune. Il codice è infatti aperto, libero e del tutto gratuito. Chiunque può scaricarlo da Internet, esaminarlo, apportarvi modifiche, espanderlo in base alle proprie esigenze e distribuirlo. Questo aspetto rende Linux molto più che un sistema operativo. Si tratta piuttosto di un ambiente dove ognuno è libero di imprimere la propria impronta e fornire un contributo alla comunità di specialisti e di utilizzatori. Giungere a Linux non è però necessariamente semplice. Io ci sono arrivato dopo un percorso tortuoso, iniziato verso la metà degli anni Ottanta quando ho cominciato a interessarmi di computer a livello del tutto amatoriale. Il mio primo sistema è stato uno ZX Spectrum 48K della Sinclair. Su questa macchina ho trascorso tante ore a programmare in Basic e a fare esperimenti con l’Assembly dello Z80. Qualche anno dopo sono passato ai 16 bit con un Amiga 500. Devo molto a questo sistema, che nasceva già dalla prima versione con il multitasking preemptive, con un ambiente a icone e un hardware modulare basato su chip dedicati. Su questa macchina ho imparato i rudimenti dell’architettura dei sistemi operativi, la programmazione in C e soprattutto il concetto di freeware, fenomeno molto vivo su Amiga. Il passo successivo naturale avrebbe dovuto essere un NeXT, che allora era probabilmente il miglior personal computer mai realizzato. I costi non erano però giustificabili per un uso hobbistico e sono perciò passato a un PC con Windows 3.1. Nel frattempo avevo cominciato a lavorare per un’azienda di informatica ed ero nel gruppo che curava l’assistenza tecnica ai clienti per le attività sistemistiche. Mi serviva quindi una macchina che potesse essermi di aiuto a livello professionale. Da allora ho sempre lavorato come sistemista e ho progettato, implementato e curato l’assistenza per soluzioni client-server basate su Windows. Pur lavorando a tempo pieno su Windows, continuavo privatamente a seguire le vicende dell’informatica e a monitorare lo sviluppo di Linux. Ero affacciato alla finestra, intento a guardare quello che avveniva, cercando di capire se questo mondo pieno di promesse e di ideali potesse diventare qualcosa di praticabile per i miei clienti, che dall’informatica si aspettavano nulla di più che soluzioni a problemi di lavoro. La svolta avvenne verso la fine degli anni Novanta, merito (paradossalmente) della bolla speculativa della New Economy. In quel periodo si fece moltissima pubblicità a Linux, forse anche a sproposito, diffondendone il nome. Nacque così grande curiosità, anche nelle aziende più piccole dove non c’era una cultura informatica solida oppure un reparto CED strutturato. Ho allora sfruttato il momento per iniziare a proporre soluzioni Linux, anche se inizialmente in ruoli defilati come, per esempio, nei firewall perimetrali. La risposta positiva da parte dei miei clienti e i benefici tangibili di

Linux mi spinsero a continuare su quella strada. Ogni azione Linux era svolta sempre in maniera pragmatica, presentando i vantaggi che la soluzione poteva portare al lavoro di tutti i giorni nelle singole realtà in cui ero chiamato a fornire risposte e assistenza. Ho cercato di essere molto obiettivo, realistico e cauto. Questo mio approccio è stato certamente apprezzato dai clienti e ha contribuito ad aumentare la mia base di installazioni professionali su Linux. Oggi utilizzo Linux con molta frequenza e una parte significativa del mio lavoro si svolge su questo sistema operativo. Subisco ancora il fascino dei suoi ideali e della sua libertà, ma continuo a essere molto pratico. Penso che la diffusione capillare di tale sistema potrà avvenire solo se gli utenti non informatici troveranno in Linux risposte migliori per le loro esigenze quotidiane. Non esistono però solo gli utenti finali. Anche i tecnici devono vedere in Linux opportunità e vantaggi tali da giustificare l’adozione di un ambiente operativo così diverso dagli strumenti commerciali tradizionali. Questa affermazione può sembrare banale, ma i professionisti sono probabilmente le persone che nutrono più dubbi e che hanno più timori ad avventurarsi in territori nuovi. Non è infatti semplice staccarsi dagli ambiti che si conoscono bene, sviluppati con anni di studio, di esperienza, di fatiche e di investimenti. Questo libro vuole essere di aiuto per tali persone. Ho scritto questo volume pensando alla fisionomia delle piccole e medie imprese italiane, realtà che operano quotidianamente con uno o più server centralizzati e con una serie di client basati su Windows. Ho cercato di isolare le esigenze informatiche più comuni e per ognuna di queste ho scritto un capitolo. Ogni capitolo spiega come configurare un particolare servizio su Linux e come renderlo funzionante rapidamente, senza scendere in troppi particolari. Ho posto l’accento sulla possibilità di lavorare subito. Una volta che il servizio è in funzione diventa più semplice approfondire l’argomento, magari con documentazione tecnica mirata. In nessun caso viene suggerito di sostituire le postazioni e i server Windows con macchine Linux. Viene piuttosto consigliato di affiancare le macchine esistenti con un sistema Linux ad hoc. Tutti i servizi trattati in questo volume riguardano il server centrale e i servizi da esso erogati, come per esempio un’area comune dove salvare i file, il sistema di posta elettronica, il fax di rete, il firewall, il sistema di groupware, il meccanismo di accesso in VPN e così via. Questo volume è quindi una sorta di “ricettario” per risolvere con Linux molte esigenze comuni. Ogni capitolo è in tal senso autonomo e contiene tutte le informazioni per installare e configurare rapidamente la soluzione. In fondo al capitolo è presentata una checklist riepilogativa da cui si può rapidamente verificare di aver eseguito tutti i passi necessari. Per comprendere questo libro è richiesta solamente un’esperienza basilare su Linux. Quanto basta per installare una distribuzione, per accedere al sistema e utilizzare i comandi di manipolazione del file system (copiare file, cancellare file, creare directory, editare file di testo e così via). Tutti gli esempi sono stati implementati su CentOS e Ubuntu LTS Server Edition, considerando Windows XP Professional come client periferico. Ho cercato infine di utilizzare un linguaggio e un taglio espositivo chiaro e alla portata di una persona con una cultura informatica media. Questo non è un libro accademico o di tecnica avanzata. Per tali esigenze esistono molti altri ottimi volumi. Spero con questo mio lavoro di contribuire all’incremento della base di utenti di Linux e di aumentare la sua diffusione. Questo è il mio piccolo apporto al movimento!

I cambiamenti e le novità della quarta edizione Questo volume è la quarta edizione di Linux Server per l’amministratore di rete, originariamente pubblicato da Apogeo nel 2004.

Il successo commerciale delle prime tre edizioni e i commenti positivi dei lettori ci hanno spinto ad attualizzare nuovamente il testo e a espanderlo con nuovi contenuti. Ogni capitolo è stato riveduto e aggiornato per meglio rappresentare la fisionomia attuale delle soluzioni esposte. In questa edizione si è scelto di usare per gli esempi due distribuzioni e non più una sola, utilizzando una distribuzione basata su Red Hat (CentOS) e una basata su Debian (Ubuntu Server Edition). Gli utilizzatori di Fedora Core potranno ancora fruire di questo libro seguendo gli esempi per CentOS, del tutto compatibili. Tutti i capitoli sono stati aggiornati utilizzando l’ultima versione dei pacchetti disponibili al momento della stesura del libro. Alcuni capitoli inoltre hanno subito miglioramenti in termini di nuovi contenuti. Nel Capitolo 3 sui print server sono stati indicati alcuni dettagli per abilitare l’accesso al pannello di CUPS dai client della rete locale. Il Capitolo 5 sul DHCP è stato espanso e migliorato in merito all’aggiornamento dinamico del DNS. Il Capitolo 10 sugli antivirus è stato aggiornato per trattare il prodotto “AVG Server Edition per Linux/FreeBSD”. Viene naturalmente ancora trattata la soluzione aperta ClamAV. Il Capitolo 11 sul backup con Amanda contempla anche la possibilità di simulare i nastri su disco, aprendo la strada a backup su sistemi di storage NAS e SAN. Il Capitolo 12 è stato aggiornato all’ultima versione del mailserver di Kerio, rinominato dalla casa madre in “Kerio Connect”. Viene anche spiegato come eseguire un restore dai backup automatici generati dal prodotto. Nel Capitolo 14, dedicato al fax di rete, è stato inserito un paragrafo con le indicazioni per installare un semplice front-end web per la gestione dei fax tramite il pacchetto HylaFAX. Il Capitolo 17, dedicato a MySQL, comprende ora alcune note su come assegnare nuovi utenti ai singoli database e impostare i diritti di accesso. Viene utilizzata la versione 3 di phpMyAdmin. Il Capitolo 18 su PHProjekt ha subito una profonda rivisitazione, in quanto il prodotto è stato riscritto e reso conforme agli standard attuali. Il pacchetto è praticamente nuovo e incentrato sui progetti. Non si tratta quindi più solamente di una soluzione di groupware. È stato aggiunto un nuovo capitolo dedicato alla virtualizzazione con Citrix XenServer, uno strumento di fascia professionale con licenza gratuita. Come sempre i commenti, i suggerimenti e le critiche costruttive sono molto ben accette e saranno pubblicate nel mio sito www.informazione.biz, luogo dove sarà possibile ottenere anche aggiornamenti e informazioni sul libro.

Ringraziamenti È per me importante ringraziare alcune persone che sono state fondamentali per la riuscita di questo progetto. Per cominciare, tutti i lettori delle edizioni precedenti di questo volume e tutti coloro che mi hanno inviato commenti e critiche sulla mia casella di posta elettronica o che hanno inserito commenti sui gruppi di discussione italiani. Senza il loro apporto non esisterebbe, ora, questa nuova edizione. Un ringraziamento ad Alberto Mari, editor per la prima edizione del volume. Aurelia Costa, addetta stampa di Apogeo, per la pazienza, la simpatia e l’amicizia. Quindi un ringraziamento particolare a Fabio Brivio di Apogeo per il modo efficace in cui ha coordinato la seconda, la terza e la quarta di edizione e a Federico Facca per il prezioso lavoro di redazione. Non posso dimenticare Marco Mariani, Gabriele D’Angelo e Stefano Bracalenti per tutto l’entusiasmo con cui mi hanno parlato di Linux negli anni e per l’aiuto fornito in numerose occasioni su questa piattaforma. Luciano Lombardi, Alessandro Degli Occhi, Alfredo Di Stefano e Brunetta Pieraccini per le opportunità offerte in ambito editoriale. Il Professor Ivan Galassi per avermi dato fiducia in tempi difficili, Antonio Pasini per avermi offerto la prima opportunità professionale in ambito informatico, Barbara Valli per avermi indicato la giusta via e Pixel, Ettore, Margherita e Maia che hanno allietato le lunghe sessioni al computer durante la stesura delle quattro edizioni di questo libro. Un ringraziamento anche agli amici di sempre: Massimiliano Strazzari, Giovanni Bandini, Marco Brandolini, Luca Fortunato, Devis Bombardini, Chiara Calmanti, Pier Giorgio Spisni, Marco Zambrini, Olivia Chiesi e Alessandro Galassi che si ricordano che esisto anche se il mio lavoro mi rende sempre assente. Ringraziamenti anche a Marco Daghia, Sara Berti (la mia migliore fan!), Massimiliano Zagaglia, Cristian Castellari, i piccoli Sebastiano e Bianca (che nel frattempo hanno cominciato a usare senza difficoltà la tecnologia, come se fosse sempre esistita!), Luciana Grementieri e Renato Bombardini per la vicinanza in alcuni particolari momenti, Mara, Barbara, Rita e Paola e i miei genitori. Un caro ringraziamento anche a Gianna Gherardi, Rina Cialdai e Adriano Gherardi. Un saluto speciale ad Antonio Carlos, Nilze, Angela, Everson, Eduardo, Carla, Rogelio e la piccola Maria Eduarda che mi hanno fatto sentire a casa in un luogo molto speciale. Vorrei ricordare ancora Laura e i bei momenti di amicizia legati inesorabilmente al passato. Infine un ringraziamento speciale a Raffaella Gherardi: ti ho certamente sottratto tempo e ti ho trascurato oltre il dovuto per la quarta volta! Un grazie di cuore per la tua pazienza, il tuo appoggio e i tuoi incoraggiamenti continui durante la realizzazione di tutte le edizioni (e di tante imprese che abbiamo compiuto insieme). Questo libro è anche merito tuo! Silvio Umberto Zanzi [email protected]

Imola, Settembre 2010

Capitolo 1

Capitolo 1 - Condivisione delle risorse con Samba Chiunque abbia seguito l’andamento del settore informatico negli ultimi anni avrà notato come la curva delle vendite dei personal computer si sia progressivamente appiattita. Il fenomeno non dipende in maniera diretta dalla congiuntura economica internazionale, ma dal fatto che il boom determinato dalla prima informatizzazione da parte delle imprese si è oramai esaurito. Negli anni Novanta il settore informatico era infatti alimentato da una miriade di aziende che per la prima volta acquistavano mezzi informatici (computer, accessori, software, periferiche, materiale didattico e così via). Vi era perciò un grande impulso economico nel comparto IT. Oggi si assiste invece a un più pacato fenomeno di aggiornamenti a lungo ciclo, in cui le macchine obsolete vengono sostituite con nuovi sistemi. Vengono naturalmente acquisite anche macchine per nuove postazioni, ma si tratta di percentuali limitate. Questa tendenza non è però omogenea in tutti i segmenti di mercato. Oggi, per esempio, il settore dei portatili è molto florido, come pure quello dei server. I portatili sono diventati popolari perché possono sostituire in maniera efficace le postazioni fisse. Non esiste più un gap nelle prestazioni e nelle potenzialità dei sistemi portatili rispetto ai desktop tradizionali. Il vantaggio della portabilità sta quindi alimentando le vendite. Risulta invece peculiare il boom dei server. In questo caso la spinta è data da un’evoluzione culturale del management delle piccole e medie imprese, che riconosce l’utilità di un sistema centrale per l’archiviazione di grandi volumi di dati, la condivisione degli archivi in rete e la razionalizzazione di risorse come stampanti e plotter. In questo modello gli applicativi continuano a girare sui singoli PC, tipicamente attraverso sistemi operativi Windows XP Professional, Windows 2000 Professional oppure su qualche versione di Windows 7. I server basati su sistemi operativi commerciali sfruttano invece versioni specifiche di Windows come Windows Server 2003 o Windows Server 2008. La casa di Redmond propone infatti da anni protocolli di rete ad alto livello che permettono di condividere facilmente file e stampanti e queste funzionalità sono disponibili sul mercato fin dai tempi di Windows 3.1. La semplicità della visione di Microsoft nelle reti, unita al costo accessibile, hanno di fatto cancellato tutta la concorrenza… almeno fino a quando Linux è diventata una valida alternativa. In questo capitolo si vedrà come configurare un sistema Linux per fare in modo che sia in grado di condividere file e stampanti, erogando così servizi a una rete composta da client basati su Windows, Mac OS X o Linux.

Reti Windows Il modo più semplice per realizzare una rete Windows consiste nella messa in opera di un workgroup (gruppo di lavoro). Si tratta di un modello in cui ogni macchina ha lo stesso ruolo di tutte le altre postazioni presenti in rete: non esiste la distinzione tra server e client, in quanto ogni computer può svolgere al contempo entrambe le veci. Quando viene condivisa una cartella su Windows XP, il computer agisce come server. Questo però non impedisce all’utente su quel sistema di accedere a directory e stampanti di altri computer, agendo come client per servizi erogati da altre macchine. Come per ogni realtà connessa, gli accessi alle risorse sono regolati da user-id e da password, ma in un

workgroup non esiste un sistema centralizzato che gestisca gli accessi. Ogni computer che fornisce risorse in un workgroup possiede un proprio elenco di user-id e di password abilitate. È l’utente presso quella specifica macchina a stabilire chi può accedere alle condivisioni locali, aggiornando l’elenco degli utenti autorizzati. Per farlo bisogna andare nella sezione Utenti di Gestione computer presente in Pannello di controllo > Strumenti di amministrazione. L’assegnazione degli utenti alle risorse avviene invece selezionando una directory, premendo il tasto destro del mouse, selezionando Proprietà, attivando la scheda Condivisione e infine attivando Condividi la cartella in rete. All’interno delle piccole realtà è comune che non venga applicato alcun tipo di accesso regolamentato tramite password e che le risorse siano semplicemente visibili a tutti. È altresì comune che le cartelle e i file condivisi vengano per comodità concentrati su un unico computer. In questo modo è più semplice reperire il materiale di lavoro, è più facile organizzare i dati e il backup risulta più agevole da gestire. Di fatto si viene a simulare un sistema server. Si sconsiglia però di utilizzare una normale postazione di lavoro per questa finalità. Non è infatti auspicabile che uno dei beni più importanti di un’azienda, l’informazione, sia contenuta in un sistema utilizzato come postazione di lavoro. Chiunque abbia un po’ di dimestichezza con i sistemi informatici di largo consumo sa quanto sia semplice alterare il funzionamento di una postazione per incuria o per scarse conoscenze dell’utente. È altresì noto quanto sia facile contrarre virus o spyware, anche mantenendo un buon comportamento informatico. In una postazione usata come server non è inoltre difficile che, per errore o per distrazione, vengano cancellate intere directory, porzioni dell’archivio o file di grande importanza. Sono tutti rischi seri per l’integrità dei dati aziendali. C’è poi il fatto che le postazioni sono spesso macchine economiche, con garanzie limitate. Si tende infatti a concepire il PC come un mero strumento di lavoro, da sfruttare fino al limite e da cambiare con un’altra macchina altrettanto economica non appena questa smette di funzionare. Questa filosofia può essere valida per le postazioni di lavoro, ma è diametralmente opposta alla mentalità che si dovrebbe tenere nella scelta di un server. L’affidabilità e la stabilità dovrebbero essere i valori cardine per un sistema che raccoglie e smista tutti i file aziendali. Oltre alle considerazioni hardware bisogna anche rilevare che un sistema operativo client non è dotato delle funzionalità e dei meccanismi di sicurezza presenti in un sistema operativo server. È possibile risolvere questo problema senza affrontare costi di licenza mediante l’utilizzo di Linux. Configurando opportunamente il “pinguino” si può dialogare in un workgroup Windows e condividere file, cartelle e stampanti, come se si trattasse di un sistema Windows a tutti gli effetti. Può suonare strano il fatto che sia possibile simulare un ambiente di rete Windows con macchine che girano con sistemi operativi non Microsoft. Il merito è da attribuirsi all’apertura dei protocolli e alla loro stratificazione funzionale. Nello specifico esiste un protocollo preposto a proiettare sulla rete locale alcune entità, quali i file, le cartelle e le stampanti. Il nome di questo protocollo è SMB (Short Message Block). Qualunque sistema operativo che implementi questo protocollo è in grado di accedere a risorse in una rete Windows o a esporre le proprie risorse a una rete di computer preesistenti. Linux dispone di un’ottima implementazione SMB all’interno di un pacchetto denominato Samba (www.samba.org), un nome che altro non è che la sigla SMB con l’aggiunta di due vocali. Il progetto è nato per la piattaforma Unix e, nel tempo, ha acquisito sempre maggiore importanza, diventando oggi uno dei pacchetti Open Source più importanti.

Struttura base di Samba Il pacchetto Samba può essere scaricato dal sito ufficiale del progetto dalla sezione di download. Si

consiglia però di fare uso di un pacchetto predisposto appositamente per la propria distribuzione. Questo semplifica notevolmente le operazioni di installazione, automatizzando molti passaggi. La versione corrente di Samba, la 3.5, include molte caratteristiche importanti, elencate di seguito. Condivisione di cartelle e stampanti in rete. Possibilità di accedere a risorse condivise da altre macchine che usano SMB. Supporto ai workgroup. Supporto per l’autenticazione su un dominio Windows. Gestione della master browser list. Funzioni WINS. Supporto per Active Directory in qualità di membro. Autenticazione Kerberos. Supporto al protocollo LDAP. Pubblicazione degli attributi delle stampanti in Active Directory. Relazioni di fiducia tra server NT4 e Samba. Supporto IPv6. Relazioni di fiducia tra server NT4 e Samba. Supporto alle relazioni di fiducia transitive e unidirezionali. Samba funziona grazie a due servizi (comunemente denominati “demoni” in ambito Unix). Si tratta di nmbd e smbd. Il primo si occupa di tutte le operazioni di risoluzione dei nomi (anche con il protocollo WINS) e della gestione della master browser list. Il secondo demone si occupa più nello specifico della gestione delle risorse condivise. È bene comprendere meglio alcuni degli aspetti appena elencati, in particolare il servizio di master browser list. Quando si fa clic su Risorse di rete e si ottengono le icone dei computer presenti si sta in realtà leggendo un elenco mantenuto da un computer assegnato a questo scopo. Non avviene cioè alcuna scansione della rete. Questo è il motivo per cui, quando si accende un nuovo computer, è necessario un po’ di tempo prima che questo compaia in Risorse di rete anche se la macchina è collegata in rete correttamente. La macchina appena accesa deve infatti cercare il gestore dell’elenco e segnalargli la propria presenza. Allo stesso modo, quando si spegne il computer, questo rimane ancora visibile nell’elenco per un certo periodo di tempo. Durante lo spegnimento non viene eseguita una notifica al gestore e quindi il nome rimane attivo nell’elenco per un certo numero di minuti, prima di essere cancellato. Il gestore dell’elenco dei computer è definito Master Browser List. Il ruolo viene assegnato a una delle macchine presenti in rete, attraverso un meccanismo di elezione. Durante questa fase sono presi in considerazione diversi parametri tra cui il periodo di uptime, la versione dei protocolli usati, il sistema operativo utilizzato (client o server) e così via. Il migliore sistema diventa il master browser list fino a quando viene spento o fino a quando vengono indette nuove elezioni e l’attuale master risulta inferiore a un nuovo sistema. Questo può succedere se in una rete di client Windows si attiva, per esempio, un sistema Linux con Samba. Tale macchina ha numeri migliori, se non altro perché è un server, e vince le elezioni acquisendo la gestione della master browser list. Il master browser list mantiene semplicemente un elenco di macchine e non svolge necessariamente altri compiti vitali in una rete locale, per esempio la traduzione da un nome macchina esteso (per esempio pc4) nel suo corrispondente indirizzo IP (per esempio 192.168.100.14). Questa funzione di “risoluzione dei nomi” potrebbe essere erogata da un altro computer. La risoluzione dei nomi è un aspetto basilare in una rete locale. Bisogna sempre tenere presente che l’accesso a un sistema in rete può avvenire solamente tramite indirizzo IP numerico. I nomi testuali devono

sempre essere tradotti in un indirizzo IP prima di poter accedere alla macchina. Il servizio storico di risoluzione dei nomi su Windows è denominato WINS. Si tratta di un archivio in cui è memorizzato il nome dei computer in LAN con i relativi indirizzi IP. Scorrendo questo elenco alla ricerca del nome del computer si ottiene immediatamente l’indirizzo IP. Se questo non è disponibile in rete, per esempio se non c’è un server, la risoluzione avviene tramite un meccanismo di broadcast: il computer interroga tutti i sistemi connessi in LAN per scoprire quale macchina dispone del nome di rete ala quale si vuole accedere. L’operazione comporta però carico inutile sulla LAN e genera ritardi. Il servizio WINS è molto simile al DNS: anche quest’ultimo eroga un indirizzo IP a seguito di un’interrogazione per nome. Sussistono però alcune differenze sostanziali. Il DNS è un servizio gerarchico concepito per funzionare in reti geograficamente distribuite, come Internet. Ogni sistema DNS contiene i dati dei soli sistemi della rete a cui fa capo. Il sistema DNS è però collegato ad altri server che hanno competenza per altre zone e, quando viene cercato l’indirizzo di un computer non presente nell’elenco locale, viene percorsa tutta la struttura DNS fino a quando non viene trovato il server che contiene le informazioni sulla macchina ricercata. I singoli DNS restano così efficienti, ma comunque in grado di eseguire ricerche globali. WINS non è in grado di fare tutto questo. L’archivio è un semplice elenco di macchine e indirizzi, senza alcuna struttura gerarchica. Ogni WINS deve perciò contenere la totalità dell’elenco. Questa scelta è inefficiente per reti di grandi dimensioni, ma è del tutto adatta per servire reti locali. WINS ha però il vantaggio di costruire dinamicamente la tabella di risoluzione, attraverso una serie di strategie. Il DNS richiede invece, nella sua fisionomia tradizionale, che un amministratore compili manualmente la tabella. La risoluzione efficiente dei nomi è un aspetto talmente importante che Samba contiene al proprio interno un’implementazione completa di WINS. Questo e altri aspetti saranno chiariti da un punto di vista pratico nelle prossime pagine, dove sarà spiegato come configurare Samba per ottenere un server Linux in grado di erogare funzionalità di rete pienamente compatibili con Windows.

Configurazione generale di Samba I due demoni di Samba, nmbd e smbd, possono essere lanciati attraverso uno script apposito. Su CentOS e su molte distribuzioni basate su Red Hat (per esempio Fedora Core) si deve digitare il seguente comando: /etc/init.d/smb start

Su Ubuntu lo script ha un nome differente: /etc/init.d/samba4 start

I demoni dovrebbero essere attivati durante la fase di startup del sistema. All’avvio di Samba, viene letto il file smb.conf presente in /etc/samba, una configurazione di esempio. Molti utenti aprono questo file e tentano di personalizzarlo per creare la prima installazione. Si sconsiglia questo approccio, in quanto Samba è un pacchetto molto complesso e ricco di opzioni. Il riciclaggio di un file di configurazione generico e prolisso, scritto più che altro per scopi dimostrativi, non è il modo migliore per cominciare. Si rischia di rimanere confusi e di perdere il controllo della situazione. Molto meglio partire da capo e scrivere una configurazione corta e mirata. Prima di tutto bisogna fermare il servizio Samba e mettere al sicuro il file di configurazione iniziale salvandolo con un altro nome: /etc/init.d/smb stop cd /etc/samba mv smb.conf smb.conf.old

A questo punto si può creare un nuovo file di configurazione: vi smb.conf

Il file di configurazione di Samba ha una struttura lineare e precisa. È presente una sezione generale global, in cui è contenuta una serie di indicazioni che regolano il funzionamento del servizio, come, per

esempio, il nome del server, il tipo di server, la visibilità in rete, i criteri di sicurezza e così via. La sezione global è seguita da una serie di descrizioni più specifiche, che forniscono dettagli sulle risorse che si vogliono condividere nel proprio sistema. Un file di configurazione di Samba può contenere anche solo la sezione generale, ma questo non ha molto senso, perché, in tal caso, non si avrebbero risorse condivise nella rete locale. Si vuole invece utilizzare Samba per creare un file server e fornire servizi di condivisione agli utenti. Per imparare a configurare Samba in modalità workgroup si prenderà come esempio un piccolo studio professionale che ha la necessità di creare un’area file comune dove salvare i file di gruppo e un’area file per contenere le utilità di uso generale (per esempio le patch del sistema operativo, l’ultima versione del browser, il software per comprimere archivi e così via). L’area dei file comuni viene chiamata comune, è di libero accesso e chiunque può leggervi e scrivervi dati. L’area con i file di utilità generale è invece gestita dall’amministratore locale, si chiama software ed è accessibile unicamente in lettura. Per cominciare si deve configurare la sezione generale: Listato 1.1

[global] workgroup = GRUPPOLAVORO netbios name = SERVER1 server string = file server Linux security = SHARE

La sezione comincia con l’etichetta [global] presente sulla prima riga. Tale indicazione deve essere riportata fedelmente. La riga seguente workgroup = GRUPPOLAVORO indica a Samba il nome del workgroup della rete. Se le macchine Windows presenti fanno già parte di un gruppo di lavoro, bisogna riportare a destra della direttiva workgroup il nome di quest’ultimo. Se si decide di utilizzare anche un altro nome, sfogliando l’icona di Risorse di rete si vedranno due gruppi di lavoro diversi. Se si sta configurando la rete per la prima volta, bisogna verificare che i client di rete, per esempio le macchine con Windows XP o Windows 7, siano configurati per far parte dello stesso gruppo di lavoro del server (Figura 1.1).

Figura 1.1 Assegnazione del gruppo di lavoro su un client W indow s XP.

La terza riga del file, netbios name = SERVER1, indica il nome con cui il server Linux sarà visibile quando si andranno a sfogliare le Risorse di rete dei client. Facendo cioè clic sul link Risorse di rete, poi sulle voci Tutta la rete e infine Rete di Microsoft Windows, si potrà accedere al workgroup GRUPPOLAVORO. Al suo interno ci sarà un’icona di computer seguita dal nome SERVER1. Questa è la macchina Linux che si sta configurando. Di seguito all’indicazione del nome netbios compare la direttiva server string. Questa contiene il commento a testo libero che viene associato al nome del server in rete. Sfogliando la rete si vedrà così la macchina SERVER1 con a fianco il commento file server Linux. È possibile omettere questa indicazione. Samba includerà in tal caso come commento il proprio numero di versione. I nomi usati nella seconda e nella terza riga del file di configurazione sono di libera scelta, anche se devono soddisfare alcuni criteri. Il nome del gruppo di lavoro deve essere privo di spazi e non può superare la lunghezza di 15 caratteri. Anche il nome NetBIOS del computer non deve superare i 15 caratteri di lunghezza. La quarta riga contiene una direttiva che indica il tipo di sicurezza che si vuole implementare per l’accesso al server da parte dei client. Le opzioni base sono due: SHARE e USER. Nella modalità SHARE l’accesso alle condivisioni avviene semplicemente fornendo una password, se richiesta. Non è richiesta alcuna altra forma di autenticazione. Questa modalità è simile alle condivisioni di directory che si possono creare in Windows 98 o Windows XP, dove si ha l’opzione di assegnare una password per l’accesso (Figura 1.2). La modalità USER è invece più articolata e richiede anche una user id durante la fase di autenticazione.

Figura 1.2 La scheda Condivisione relativa ad ua cartella su W indow s XP.

Per cominciare a lavorare con Samba si prenderà in considerazione la modalità SHARE, impostando le direttive necessarie per creare una delle due cartelle condivise dello studio professionale. Si apra nuovamente il file di configurazione precedente e in fondo si aggiungono le seguenti righe: Listato 1.2

[comune] comment = cartella comune path = /home/comune public = YES writable = YES

L’etichetta scritta tra parentesi quadre corrisponde al nome della condivisione in rete per la directory indicata più in basso. In pratica si stanno definendo le proprietà della condivisione comune. La direttiva comment è a testo libero e rappresenta il commento che può comparire di fianco al nome della condivisione quando si visualizzano i dettagli di file e directory. La direttiva path indica la posizione nel file system di Linux dove è ubicata la directory. In questo caso è stata scelta la directory comune dentro home. Per garantire l’accesso a questa condivisione da parte degli utenti della rete locale, bisogna verificare che i permessi di accesso siano corretti. Trattandosi di una directory a libero accesso si possono usare i diritti 777: chmod 777 /home/comune

Le due direttive seguenti indicano rispettivamente che la cartella è di pubblico accesso e che è possibile

scrivere all’interno della directory condivisa. Si prosegue ora realizzando la cartella software, accessibile in sola lettura dagli utenti comuni. La configurazione è molto simile a quella della directory comune: Listato 1.3

[software] comment = file di utilita' path = /home/software public = YES writable = NO

L’unica differenza rilevante tra le due configurazioni è il fatto che la direttiva writable è impostata a NO, impedendo la scrittura all’interno della configurazione da parte degli utenti della LAN. Anche in questo caso, come nel precedente, occorre assicurarsi che la directory /home/software abbia i diritti d’accesso impostati correttamente. Si darà per scontato questo dettaglio nelle configurazioni successive. Ogni volta che si apporta una modifica nel file di configurazione di Samba bisogna ricordarsi di riavviare il servizio per fare in modo che i cambiamenti vengano immediatamente applicati. Samba ricarica a intervalli regolari il file generale di configurazione, ma l’intervallo è relativamente lungo e le nuove modifiche non vengono perciò applicate in tempo reale. Per riavviare manualmente il servizio basta utilizzare questa sintassi su CentOS: /etc/init.d/smb restart

Su Ubuntu: /etc/init.d/samba4 restart

Prima di questa operazione è bene verificare che la sintassi del file di configurazione sia corretta. Per farlo si può impartire il seguente comando: testparm

Questa utility fa parte della suite Samba ed è preposta a verificare la correttezza del file di configurazione. Il comando legge il file smb.conf, esegue una scansione delle sezioni e rileva eventuali errori. Se la configurazione risulta corretta, verrà indicato il ruolo del server configurato (in questo caso ROLE_STANDALONE). Premendo Invio si vedrà il dump dei parametri principali della configurazione realizzata: Listato 1.4

Load smb config files from /etc/samba/smb.conf Processing section "[comune]" Processing section "[software]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions # Global parameters [global] workgroup = GRUPPOLAVORO server string = file server Linux security = SHARE [comune] comment = cartella comune

path = /home/comune read only = No guest ok = Yes [software] comment = file di utilita' path = /home/software guest ok = Yes

Questa fase di diagnosi è molto importante, perché i demoni di Samba leggono il file di configurazione in fase di avvio, ma non segnalano eventuali errori presenti. L’amministratore di sistema potrebbe essere così indotto a pensare che la configurazione realizzata sia corretta, quando invece sono presenti errori di sintassi. Il comando testparm accetta alcune opzioni. Una di queste è -v, tramite la quale è possibile visualizzare il valore di tutte le direttive che non sono state impostate manualmente nel file di configurazione, ma che hanno valori di default assegnati automaticamente da Samba. È così possibile vedere come queste variabili sono state gestite dal sistema. Un ulteriore strumento di diagnosi e analisi del server è l’utility smbclient. Si tratta di un’interfaccia testuale verso i servizi di Samba. Le funzionalità incluse sono numerose. Si consiglia, a tal proposito, di leggere il manuale del comando, tramite man smbclient. Una di queste opzioni, -L, visualizza lo stato del servizio smb sul sistema indicato. La sintassi da usare è smbclient -L nomeserver, per esempio: smbclient -L 127.0.0.1

Questo è l’output di un server Linux che gestisce il workgroup GRUPPOLAVORO e che si trova in una rete locale dove è presente anche un altro gruppo di lavoro denominato SEDE: Listato 1.5

Domain=[GRUPPOLAVORO] OS=[Unix] Server=[Samba 3.4.7] Sharename Type Comment --------- ---- ------IPC$ IPC IPC Service (file server Linux) software Disk file di utilita' comune Disk cartella comune Domain=[GRUPPOLAVORO] OS=[Unix] Server=[Samba 3.4.7] Server Comment> --------- ------SERVER1 file server Linux Workgroup Master --------- ------GRUPPOLAVORO SERVER1 SEDE TECRA-M1

Gestione degli utenti Le esigenze di gestione dei file dello studio professionale sono state pienamente risolte con la configurazione precedentemente presentata. Col tempo però le esigenze possono cambiare e potrebbe sorgere la necessità di realizzare accessi differenziati per i diversi utenti. Lo studio professionale, a seguito di un incremento del giro di affari, potrebbe, per esempio, aver bisogno di un software gestionale da far utilizzare ad alcuni dei dipendenti. Il database comune di questo gestionale è memorizzato in una directory condivisa e accessibile dalle postazioni client presenti in rete tramite il nome

gestionale.

Questi dati, per motivi di privacy, non devono essere visibili a tutti, ma solo al personale dell’amministrazione, più precisamente agli utenti amm1, amm2 e amm3. Per soddisfare questo requisito bisogna modificare alcuni aspetti sostanziali della configurazione precedente (SHARE). Innanzitutto non è più adeguata la protezione a livello di condivisione, ma bisogna piuttosto adottare la sicurezza a livello utente (USER). Non si vuole inoltre una semplice password di protezione, ma si intende fare in modo che solo gli account amm1, amm2 e amm3 possano accedere a questi dati, usando le relative credenziali. La configurazione del blocco global deve essere modificata come nel seguente listato: Listato 1.6

[global] workgroup = GRUPPOLAVORO netbios name = SERVER1 server string = file server Linux security = USER smb passwd file = /etc/samba/smbpasswd encrypt passwords = YES

L’aspetto importante è che il tipo di security è stato impostato a USER. Ora l’autenticazione avviene tramite la coppia di valori user id/password, fornita all’accesso delle condivisioni. Sotto l’opzione security sono state inserite due direttive supplementari. La prima indica dove si trova il file che conserva le password di accesso per gli utenti di Samba e la seconda determina che si stanno utilizzando password cifrate per accedere a Samba. In tal caso bisogna tener presente che macchine Windows 95, NT 3 e NT4 pre-SP3 potrebbero aver problemi di accesso per via dell’uso di password trasmesse in chiaro. Si consiglia, per motivi di sicurezza, di aggiornare il sistema operativo di questi computer. Le definizioni per le condivisioni comune e software restano invariate, mentre va aggiunta la definizione per la condivisione gestionale: Listato 1.7

[gestionale] comment = area supporto software gestionale path =/home/gestionale valid users = amm1 amm2 amm3 writable = YES

La direttiva importante è valid users, all’interno della quale è possibile elencare gli utenti abilitati ad accedere alla directory /home/gestionale, condivisa con il nome gestionale. Eventualmente è possibile inserire una direttiva invalid users ed elencare gli account che non possono accedere a gestionale, per esempio tutti i restanti utenti della rete: Listato 1.8

[gestionale] comment = area supporto software gestionale path =/home/gestionale valid users = amm1 amm2 amm3 invalid users = ufftec1 ufftec2 ufftec3 ufftec5 marketing reception comm1 comm2 writable = YES

Indicare gli utenti nel file di configurazione non è sufficiente. Bisogna anche creare gli stessi account sul server Linux. Samba si appoggia infatti sul sistema degli utenti di Linux per funzionare. Il primo passaggio consiste nel creare gli utenti sulla macchina Linux, avvalendosi degli strumenti standard del sistema: useradd amm1 useradd amm2 useradd amm3

In seguito bisogna impostare le password per ogni singolo utente: Listato 1.9

[root@server1 samba]# passwd amm1 Changing password for user amm1. New password: ******** Retype new password: ******** passwd: all authentication tokens updated successfully.

La stessa procedura deve essere seguita per amm2 e amm3. Il server dispone ora dei nuovi account con tanto di directory utente in /home e di password di accesso al sistema. Samba utilizza gli account di Linux per identificare gli utenti, ma usa un proprio file di password per regolare l’accesso alle risorse. La password di accesso a Linux e quella di Samba per un dato account potrebbero quindi essere differenti. Si sconsiglia però questo approccio per motivi di omogeneità della configurazione di sistema. L’utility di Samba per l’impostazione delle password si chiama smbpasswd e non fa altro che aggiungere nel file delle password la riga /etc/samba/smbpasswd, con la user id e la password cifrata. La sintassi di base è molto semplice, in quanto basta digitare il comando seguito dall’opzione -a e dal nome utente. Poi si inserisce la password e si conferma: Listato 1.10

[root@server1 samba]# smbpasswd -a amm1 New SMB password: ******** Retype new SMB password: ******** Added user amm1.

Ora l’utente è correttamente definito all’interno del server Linux e di Samba. Le copie di user id e password utilizzate in fase di configurazione dovrebbero essere le stesse adottate nei sistemi Windows client presenti in rete. In questo modo tutta la procedura di accesso dalle postazioni utente è automatica, in quanto Windows comunicherà le credenziali al momento dell’accesso alle directory. Se le credenziali di Windows e quelle di Samba/Linux sono differenti comparirà una finestra con la richiesta di inserimento manuale delle credenziali.

Directory utente Fino a questo punto della trattazione si è osservato come realizzare ogni singola condivisione scrivendo manualmente il relativo blocco di configurazione. Si è per esempio visto come creare due condivisioni

attraverso i blocchi comune e gestionale scritti dentro il file di configurazione generale di Samba. Questo modo di procedere è del tutto corretto, ma può risultare scomodo in alcune situazioni, per esempio se si hanno decine di utenti e si vogliono creare delle home directory per ognuno di essi. Si dovrebbe infatti realizzare un blocco di configurazione specifico per ciascun utente. È possibile risolvere questo problema ricorrendo al blocco homes, che provvede alla creazione automatica di una condivisione personale per ogni utente correttamente configurato in Samba. Da un punto di vista pratico viene letto l’elenco degli utenti di Samba e vengono condivise automaticamente le relative directory utente Linux presenti in /home. La configurazione necessaria è molto semplice. Basta aprire il file smb.conf e inserire il blocco homes di seguito alla sezione global: [homes] comment = cartella utente writable = YES

Il blocco contiene il commento a testo libero e l’indicazione che la risorsa è accessibile in lettura. A questo punto basta salvare la configurazione, riavviare Samba e verificare l’esito dell’operazione Aprendo le Risorse di rete e accedendo al server Linux si vedranno le cartelle generali, la cartella personale dell’utente e una cartella denominata homes. La cartella personale dell’utente avrà lo stesso nome dell’account di login usato, per esempio amm1. Il contenuto sarà liberamente accessibile e si potranno apportare tutte le modifiche necessarie. La cartella homes visibile nell’elenco delle condivisioni è semplicemente un alias che punta alla propria cartella utente personale. Si tratta di una scelta progettuale di Samba. Volendo è possibile fare in modo che la condivisione homes non sia visibile. Basta che la direttiva browsable sia impostata a NO. La direttiva browsable = NO impedisce che la condivisione in oggetto sia visibile (pur rimanendo presente). È la versione Samba delle condivisioni nascoste di Windows. La direttiva può essere usata nella definizione di qualunque condivisione come prima misura di sicurezza. Il file di configurazione assume ora questo aspetto: Listato 1.11

[homes] comment = cartella utente writable = YES browsable = NO

Variabili È bene precisare che la configurazione realizzata per le cartelle home è debole sul versante della riservatezza. Se l’utente amm1 vuole accedere alla cartella personale di amm4 può semplicemente scrivere questo percorso sulla barra dell’indirizzo di qualunque finestra di Windows: \\server1\amm4

Premendo Invio si aprirà la finestra relativa con il contenuto della home di amm4. Non si tratta di un problema di funzionamento di Samba come molti amministratori sono indotti a pensare. Si tratta, ancora una volta, di una scelta progettuale ben precisa. Spetta infatti al gestore della rete applicare opportuni diritti alle cartelle oppure impiegare ulteriori direttive sul file di configurazione di Samba per blindare le directory.

Si potrebbe, per esempio, limitare l’accesso tramite la direttiva valid users e le variabili. Samba permette infatti di specificare nei campi di configurazione alcune informazioni variabili che sono gestite dinamicamente durante il funzionamento del sistema. Le variabili in Samba iniziano sempre con il carattere %, alcune di queste sono elencate in Tabella 1.1. Tabella 1.1 Variabili di uso comune in Samba.

Variabili che riguardano il client che esegue il login %a Tipo di sistema operativo client (esempio Samba, WinNT, WfWg, Win95 o UNKNOWN). %I Indirizzo IP. %m Nome NetBIOS. %M Nome DNS.

Variabili che riguardano l’utente %u User id Unix corrente. %U User id del client che ha richiesto l’accesso. %g Gruppo dell’utente %u. %H Directory utente di %u.

Variabili che riguardano le condivisioni %S Nome della condivisione corrente. %P Radice della condivisione corrente.

Variabili che riguardano il server %h Nome DNS del server Samba. %L Nome NetBIOS del server Samba. %v Versione di Samba.

Per risolvere il problema, appena illustrato, di accesso alle condivisioni si può utilizzare la variabile %S, che contiene il nome della condivisione corrente. Dal momento che la directory utente personale ha il medesimo nome dell’id utente di login è possibile usare la variabile come vincolo di accesso: valid users = %S

Riavviando il demone di Samba si potrà accedere alla propria cartella utente amm1, ma non a quelle di altri

utenti. Questo perché gli utenti validi per le cartelle ufftec1, ufftec2, ufftec3 e così via saranno rispettivamente solo l’utente ufftec1, ufftec2, ufftec3 e così via. Durante l’implementazione delle directory utente potrebbero verificarsi alcuni problemi come, per esempio, l’impossibilità di accedere o scrivere nelle aree utente, pur avendo inserito correttamente le direttive di Samba. L’accesso alle home directory di Linux da parte di Samba avviene con lo stesso user id con cui il client ha eseguito il login. Se si è autenticati come amm1 dalla postazione Windows, l’accesso alle cartelle condivise avverrà attraverso l’utente amm1. Occorre quindi verificare che le singole directory utente dentro /home siano di proprietà del rispettivo utente. La directory amm1 deve appartenere all’utente amm1, la directory amm2 deve appartenere all’utente amm2 e così via. A tale proposito si deve usare il comando chown: chown amm1 amm1 chown amm2 amm2 chown amm3 amm3

Alle singole cartelle si dovrebbero anche assegnare i diritti 770, per fare in modo che solo l’utente e il proprio gruppo possano accedere alla cartella. Questo è utile anche come misura di sicurezza su Linux. Se si preferisce, è possibile creare le directory utente in una posizione alternativa a /home, evitando così di intaccare la struttura delle cartelle utente di Linux. Questa scelta può essere utile anche per evitare che gli utenti Windows vedano i file di supporto che vengono creati automaticamente da Linux per un nuovo utente. Per creare le directory utente in un altro punto del file system si utilizza la seguente sintassi: path = /usr/local/sambahome/%S

In questo caso, si sta istruendo Samba a considerare la radice delle directory utente in /usr/local/sambahome. I percorsi verso le singole cartelle sono generati con la variabile %S. Bisogna naturalmente avere l’accortezza di creare la radice (/usr/local/sambahome), le singole cartelle

utente e impostare i diritti e i proprietari nel modo indicato in precedenza.

Condivisione dell’unità CD-ROM Un caso particolare di condivisione è l’unità CD-ROM, in quanto l’ambiente Linux richiede che questa sia montata prima dell’utilizzo. Se si intende condividere un particolare disco CD-ROM in maniera permanente, per esempio un elenco telefonico, si può accedere al sistema Linux come amministratore (root), montare l’unità con il comando mount (per esempio mount/dev/cdrom) e creare un blocco simile a quelli precedenti: Listato 1.12

[cdrom] comment = Elenco telefonico browsable = YES read only = YES path = /mnt/cdrom

Se invece si vuole cambiare liberamente il disco CD-ROM sull’unità condivisa è necessario ricorrere a due parametri specifici, che eseguono il mounting automatico all’accesso della risorsa condivisa e l’operazione di unmounting all’uscita: Listato 1.13

[cdrom] comment = Unita' cdrom browsable = YES read only = YES path = /mnt/cdrom root preexec = mount /dev/cdrom root postexec = umount /mnt/cdrom

Il comando root preexec esegue le operazioni indicate a destra del simbolo = durante l’accesso alla condivisione. Le operazioni sono eseguite dall’utente root. Il comando root postexec esegue l’operazione indicata all’uscita dalla condivisione. In questo caso sono indicati i comandi per la gestione dei dispositivi, ma è possibile inserire qualunque altro comando o script si riveli necessario ai propri scopi. Queste direttive non si limitano alle definizioni per unità CD-ROM, ma possono essere impiegate in qualunque blocco di definizione delle condivisioni.

Sicurezza di Samba Esistono alcune semplici direttive che permettono di incrementare la sicurezza della propria installazione di Samba. Queste possono essere incluse in un blocco di definizione di una singola condivisione oppure nel blocco global. Per cominciare è possibile discriminare gli accessi in base agli indirizzi IP: hosts allow = 127.0.0.1 192.168.100.0/24 hosts deny = 192.168.100.13

La prima direttiva permette di specificare quali nodi o sottoreti possono accedere alla condivisione. In questo caso il sistema locale 127.0.0.1 e la sottorete 192.168.100.0. È possibile indicare anche solo stringhe parziali, come 192.168.200. e 127. oppure nomi simbolici risolvibili dal server, come localhost o server1. La direttiva host deny esegue la procedura opposta: specifica quali nodi o reti non possono accedere. È bene sapere che Samba risponde alle richieste provenienti da tutte le interfacce fisiche e logiche attivate sul server locale. Questo significa che se è presente un modem ADSL connesso, anche gli utenti esterni potranno accedere al sistema Samba e sfogliare le condivisioni. Si tratta di una situazione molto pericolosa. Per risolvere il problema occorre usare la direttiva interfaces nel blocco global e indicare le interfacce abilitate a inoltrare richieste a Samba: interfaces = eth0 eth1 lo bind interfaces = yes

Vengono in questo esempio abilitate le due schede di rete presenti nel sistema (eth0 e eth1) e l’interfaccia di loopback locale (lo). La seconda riga abilita il traffico solo sulle interfacce indicate nella direttiva interfaces. Queste direttive non esimono l’amministratore dall’implementazione di un firewall perimetrale sulla rete oppure sul computer che ospita Samba (si veda il Capitolo 7). Le porte di servizio usate dal protocollo SMB/CIFS sono le 137, 138, 139 e 445. Queste devono essere chiuse dall’esterno e disponibili solo alla rete interna. All’interno delle cartelle utente potrebbero essere presenti file con link simbolici che puntano a file e a directory presenti in altri punti del file system. Per impedire la possibilità di seguire i link simbolici si può usare

la seguente direttiva: follow symlinks = no

Per quanto riguarda la registrazione degli eventi è presente un meccanismo di logging attivato per default. Eventualmente è possibile modificare le impostazioni, inserendo nel blocco global la direttiva log: log file = /var/log/samba/%m.log max log size = 100 log level = 3

La prima direttiva indica il percorso dove salvare i messaggi di log. Si noti che è stata usata una variabile per fare in modo che ci sia un file di log differente per ogni sistema che accede a Samba. Con max log size si indica la dimensione massima per il file di log. Superato questo limite il file di log corrente viene rinominato aggiungendo .old al suo nome e viene creato un nuovo file. Il valore 0 sta a indicare nessun limite. Con log level si stabilisce il livello di dettaglio del file di log. Il valore 3 è molto elevato e fornisce un output particolarmente dettagliato, utile per le operazioni di debugging o di verifica delle configurazioni. Non si consiglia questo livello, come pure il 2, in quanto comporta un carico elevato sul sistema Samba con un conseguente calo delle prestazioni. Meglio usare il livello 1 in produzione e passare a livelli superiori solo in caso di necessità.

Configurazione dei client La configurazione dei client è rapida: basta portare il puntatore del mouse sull’icona Risorse del computer di Windows XP, fare clic con il tasto destro del mouse e selezionare Proprietà. Compare una finestra da cui bisogna selezionare la scheda Nome computer, poi si deve premere il pulsante Cambia. Nella finestra che si apre, indicare il nome GRUPPOLAVORO per il gruppo di lavoro, confermare e riavviare il computer. All’avvio seguente di Windows, la macchina farà parte del workgroup indicato. Per velocizzare le operazioni di accesso in rete è importante attivare un sistema DNS, inserire le generalità del server e di tutti i client e poi configurare ogni macchina dalle proprietà di Risorse di rete per utilizzare questo DNS. Informazioni sulla creazione di un sistema DNS con Linux vengono fornite nel Capitolo 4. Qui di seguito è riportato il contenuto del file di configurazione smb.conf di Samba, così come è stato costruito nel corso di questo capitolo. Listato 1.14

[global] workgroup = GRUPPOLAVORO netbios name = SERVER1 server string = file server Linux security = USER smb passwd file = /etc/samba/smbpasswd encrypt passwords = YES log file = /var/log/samba/%m.log max log size = 100 log level = 1 [homes] comment = cartella utente writable = YES

browsable = NO valid users = %S # path = /usr/local/sambahome/%S [comune] comment = cartella comune path =/home/comune public = YES writable = YES [software] comment = file di utilita' path =/home/software public = YES writable = NO [gestionale] comment = area supporto software gestionale path =/home/gestionale valid users = amm1 amm2 writable = YES [cdrom] comment = Elenco telefonico browsable = YES read only = YES path = /mnt/cdrom root preexec = mount /dev/cdrom root postexec = umount /mnt/cdrom

Checklist 1. Verificare che il pacchetto Samba sia installato sul proprio sistema, digitando il comando testparm. Se compare un messaggio d’errore, significa che Samba non è presente e bisogna procedere alla sua installazione. 2. Salvare in un luogo sicuro il file di configurazione di default di Samba, quindi creare un nuovo file smb.conf nella directory /etc/samba. 3. Aprire il file smb.conf e creare la sezione global. 4. Inserire nella sezione global le direttive workgroup, netbios name e server string.

Cartelle condivise di accesso pubblico 1. Impostare nella sezione global il livello di sicurezza della condivisione con la direttiva security = SHARE. 2. Impostare una condivisione, creando nel file di configurazione una sezione contenente almeno le direttive comment e path. 3. Inserire la direttiva public = YES per rendere pubblica la condivisione. 4. Inserire la direttiva writable = YES per rendere accessibile in scrittura la condivisione. 5. Impostare correttamente i permessi Linux nella directory che si sta condividendo. 6. Impostare le direttive di sicurezza. 7. Verificare la correttezza della configurazione, usando il comando testparm.

8. Avviare i demoni di Samba e fare in modo che vengano sempre lanciati a ogni avvio del sistema. 9. Configurare i client.

Cartelle condivise protette da user id e password 1. Impostare nella sezione global il livello di sicurezza dell’utente con la direttiva security = USER. 2. Impostare il file delle password tramite la direttiva smb passwd file. 3. Indicare la gestione delle password cifrate, tramite la direttiva encrypt passwords = YES. 4. Impostare una condivisione, creando nel file di configurazione una sezione contenente le direttive comment e path. 5. Indicare l’elenco degli utenti autorizzati ad accedere alla condivisione, con la direttiva valid users. 6. Specificare gli eventuali utenti non autorizzati, utilizzando la direttiva invalid users. 7. Inserire la direttiva writable = YES per rendere accessibile in scrittura la condivisione. 8. Impostare correttamente i permessi della directory condivisa. 9. Ripetere i passaggi dal 4 al 8 per tutte le ulteriori condivisioni. 10. Verificare la correttezza della configurazione richiamando il comando testparm. 11. Creare sul sistema Linux gli account degli utenti Windows che potranno accedere alle condivisioni. 12. Creare le password di Samba per gli account appena creati; con il comando smbpasswd. 13. Avviare i demoni di Samba e fare in modo che vengano sempre lanciati a ogni avvio del sistema. 14. Configurare i client.

Nel caso siano necessarie directory utente 1. Creare nel file di configurazione di Samba il blocco homes. 2. Impostare la direttiva comment. 3. Rendere le directory accessibili in scrittura, utilizzando la direttiva writable = YES. 4. Inserire la direttiva browsable = NO per fare in modo che le condivisioni non siano visibili nei sistemi Windows. 5. Fare in modo che ogni utente possa accedere solo alla propria directory, sfruttando le variabili di Samba. 6. Verificare nel sistema Linux che a ogni utente corrisponda un profilo e una directory in /home. 7. Verificare che i proprietari e i permessi delle cartelle utente presenti nella directory /home siano corretti. 8. Se si vuole fare in modo che le directory utente non corrispondano alle directory home di Linux, specificare nella direttiva path un percorso alternativo, all’interno del quale devono essere presenti le directory utente. 9. Verificare la correttezza della configurazione, utilizzando il comando testparm. 10. Riavviare i demoni di Samba.

Capitolo 2

Capitolo 2 - Realizzazione di un dominio con Samba Nel capitolo precedente si è visto quanto sia veloce condividere delle risorse attraverso la modalità di workgroup. Basta il pacchetto Samba su una macchina Linux e una semplice configurazione per ottenere un file server in grado di supportare un numero arbitrario di client. Sulle postazioni Windows la configurazione è ancora più semplice: è sufficiente che il workgroup di riferimento del client coincida con quello impostato su Samba. La configurazione presentata ha però alcuni limiti. In un workgroup non esiste una vera distinzione tra client e server, in quanto ogni macchina può ricoprire entrambi i ruoli. Qualunque postazione può infatti condividere cartelle locali e diventare server nel workgroup per tali risorse. Allo stesso tempo queste macchine possono accedere a condivisioni di altri sistemi e agire come client. Per questo motivo, in un workgroup non è neppure necessario avere un computer server. Anche soli due computer Windows XP possono infatti costituire un gruppo di lavoro a tutti gli effetti. La facilità con cui si può creare e utilizzare un workgroup è il fattore chiave che ha permesso a Microsoft negli anni Novanta di battere importanti aziende nel settore del networking. Microsoft non ha però limitato la propria presenza nel campo delle piccole LAN, ma ha supportato attivamente una seconda modalità di rete più sicura e articolata, che si contrappone al workgroup e si chiama dominio. In un dominio esiste almeno una macchina principale che svolge la funzione di PDC (Primary Domain Controller). Questo sistema esegue diverse attività chiave, tra cui l’autenticazione di utenti e di computer e la gestione delle autorizzazioni per le risorse condivise. Ogni utente che desidera aver accesso alla rete deve prima autenticarsi sul PDC. Gli utenti abilitati che hanno fornito credenziali corrette possono effettuare il logon, caricare dal server il proprio profilo personale e sfruttare risorse comuni. Si potrà così accedere a directory condivise sul server, ma anche condividere le cartelle presenti sul proprio sistema locale, come accadeva nel workgroup. La condivisione è regolata però da permessi più rigidi: quando si esegue una condivisione viene caricato dal server l’elenco degli utenti abilitati del dominio e il proprietario del computer può attivare la condivisione per uno o più di questi utenti abilitati. Il server è quindi sempre l’elemento centrale, anche quando si lavora con risorse locali. In un workgroup non esiste niente di tutto questo. Gli utenti compiono log-in distinti sulle varie macchine della LAN da cui desiderano utilizzare delle risorse condivise. Ogni macchina dispone perciò di un elenco privato di utenti abilitati e di relative autorizzazioni per le risorse locali. Nessuna funzione è centralizzata e per questo motivo si perde molto tempo a replicare elenchi utenti e diritti su tutti i client in LAN. La possibilità di errori e dimenticanze è molto alto in questo modello. Per questi motivi è sempre meglio istituire un dominio, anche quando si ha una rete di piccole dimensioni.

Esempio pratico In questo capitolo si prenderà in considerazione il caso di una piccola industria che ha la necessità di creare un ambiente di rete ordinato. L’azienda dispone di cinque postazioni in amministrazione (amm1, amm2, amm3, amm4 e amm5), di dieci postazioni in ufficio tecnico (ufftec1, ufftec2, ufftec3 e così via), di due postazioni commerciali (comm1 e

comm2) e di un computer in direzione (dir). Tutte le postazioni, basate su Windows XP Professional, devono

autenticarsi sul PDC. Durante il logon dovranno essere collegate al client locale una serie di cartelle condivise quali l’area comune, l’area con i file di utilità, l’area di supporto per il gestionale e l’area riservata all’ufficio tecnico. Ogni utente dovrà inoltre trovare in Risorse del computer una propria cartella personale privata ubicata sul server. I profili personalizzati dei singoli computer, come lo sfondo, lo screen saver, la disposizione delle icone, le impostazioni del browser, le impostazioni del desktop, la configurazione di Office e così via, dovranno essere memorizzate sul server. Questa funzionalità, denominata “roaming profiles” (profili mobili), permette agli utenti di trovare il proprio ambiente di lavoro su qualunque macchina utilizzino per il logon. All’accesso nel dominio, tutte le impostazioni personalizzate saranno scaricate automaticamente in locale e applicate sulla macchina. L’utente potrà lavorare normalmente sul computer e all’uscita dal dominio tutte le modifiche apportate saranno salvate sul server. I profili mobili sono molto comodi, ma si limitano alle personalizzazioni. Ossia non permettono la condivisione dei programmi. Office, per fare un esempio, dovrà essere regolarmente installato su tutte le postazioni in cui è necessaria la presenza della suite. Durante la configurazione di Samba come PDC si daranno per scontati i concetti espressi nel Capitolo 1. Le configurazioni applicate in questo capitolo rappresentano inoltre un’estensione della configurazione di base realizzata nel capitolo precedente. Non resta che procedere con il lavoro. Prima di tutto si deve fermare il servizio Samba, rinominare il vecchio file di configurazione e creare un nuovo file smb.conf. La sezione global comincerà con le seguenti direttive: Listato 2.1

[global] workgroup = INCIPIT netbios name = SERVER1 server string = PDC Linux security = USER smb passwd file = /etc/samba/smbpasswd encrypt passwords = YES log file = /var/log/samba/%m.log max log size = 100 log level = 1

Non ci sono modifiche sostanziali rispetto a quanto si è visto nella prima parte del Capitolo 1, a parte il modello di sicurezza che in questo caso è impostato a livello utente (security = USER) e le password che sono gestite in modalità cifrata. La configurazione della sezione global deve ora proseguire indicando esplicitamente l’intenzione di impostare il sistema Samba come PDC: Listato 2.2

os level = 255 preferred master = YES local master = YES domain master = YES wins support = YES

Il PDC di una rete è anche il sistema che svolge le funzionalità di Master Browser List. Si tratta cioè della macchina che si preoccupa di mantenere aggiornato l’elenco di sistemi che appare in Risorse di rete. Quando

si fa un doppio clic su Risorse di rete si interroga in realtà il Master Browser List e si scarica l’elenco da questo sistema. Il ruolo di Master Browser List non è assegnato a priori a un computer designato dall’amministratore. Sono i sistemi presenti a stabilirlo attraverso un meccanismo automatico di elezioni. Nel farlo vengono considerati molti criteri, tra cui il tempo di uptime e il tipo di sistema operativo. In Samba è però possibile sembrare migliori di quello che si è e tentare così di “vincere le elezioni”. Con la direttiva preferred master = YES si forza un’elezione e tramite la direttiva os level = 255 si pone il sistema corrente in cima a tutte le preferenze. Questo valore indica infatti la tipologia del sistema operativo (i client hanno valori bassi, mentre i server ne hanno di più alti). Maggiore è il numero e migliori sono le possibilità di vincita. Il valore di default è 20. Con la direttiva local master = YES si comunica alla rete che il server Samba intende diventare il Master Browser List per il dominio INCIPIT. La direttiva seguente è molto simile, ma opera su un contesto più ampio, ossia quando un dominio è sparso su più sottoreti. In queste situazioni potrebbero esserci diversi sistemi a gestire gli elenchi per le singole sottoreti. La direttiva domain masters = yes opera come collante e fa in modo che il server Samba riceva gli elenchi di tutte le sottoreti. Questi elenchi saranno unificati sul server Samba e il risultato complessivo sarà distribuito a tutte le sottoreti. Gli utenti, sfogliando Risorse di rete, potranno vedere un elenco che comprende tutti i sistemi presenti in tutti i segmenti della struttura della rete. Ora che il server Samba è il Master Browser List del dominio INCIPIT, si può inserire una direttiva di compatibilità per le macchine Windows 95/98. Per limiti progettuali, questi sistemi operativi non sono infatti in grado di accedere al dominio a tutti gli effetti. È quindi necessario utilizzare la seguente direttiva per attivare la compatibilità: domain logons = YES

Il sistema Samba può agire anche da server WINS e fornire così servizi di risoluzione per i client Windows presenti. È sufficiente un’unica direttiva per attivare la funzionalità: wins support = YES

Per accedere a questo server WINS bisogna andare sui singoli client e specificare l’indirizzo IP del server nell’apposita finestra di configurazione delle proprietà di rete. Prima di attivare la funzionalità WINS bisogna controllare bene che non ve ne siano altri sulla sottorete locale, in quanto si potrebbero avere comportamenti erronei.

Abilitazione delle directory utente È possibile fare in modo che ogni utente della rete disponga di una propria directory personale privata. Questa cartella può essere assegnata in fase di logon a una lettera di unità ben precisa, per esempio U. Per attivare questa funzionalità si utilizza la seguente sintassi: logon home = \\server1\homedir logon drive = U:

La prima direttiva esplicita che le cartelle utente si trovano nella condivisione \\server1\homedir. Attenzione al fatto che non si tratta di un percorso all’interno del sistema Linux, ma di un percorso di rete. In tal caso si fa riferimento a una condivisione chiamata homedir presente sulla macchina server1. La cartella utente sarà legata alla lettera U sul client locale grazie alla seconda direttiva. La condivisione è definita più in basso sul file di configurazione, in un apposito blocco:

Listato 2.3

[homedir] path = /home/%u read only = NO writable = YES browsable = NO create mask = 0600 directory mask = 0700 hide dot files = YES

La configurazione del blocco non si discosta molto da quanto si è visto nel Capitolo 1. Ci sono comunque alcuni punti su cui è interessante soffermarsi. Prima di tutto il percorso è specificato tramite una variabile. Questo fa in modo che l’utente amm2 abbia come cartella utente il percorso /home/amm2, l’utente amm4 abbia /home/amm4 e così via. Sono state impiegate le cartelle utente di Linux per ottenere un ambiente omogeneo, dove gli utenti fruiscono della stessa directory home sia su Linux, sia su Windows. Ci sono però alcune direttive che non sono state presentate nel Capitolo 1. La prima di queste è create mask, che assegna a tutti i file creati sulla condivisione i diritti 0600. La direttiva successiva svolge la stessa funzionalità, ma questa volta sulle nuove directory create. La direttiva hide dot files = YES forza il bit nascosto su tutti i file che iniziano per punto. Questo è utile per nascondere agli utenti Windows i file di configurazione di Linux presenti nella directory /home, come per esempio .bashrc, .bash_profile e .bash_logout. La direttiva rende invisibili i file, ma se l’utente ha attivato su Windows la visualizzazione dei file nascosti vedrà comunque tutti i file che iniziano per punto.

Profili mobili I profili mobili (roaming profile) permettono di salvare sul server i profili di tutti gli utenti della rete e fare in modo che ci si possa spostare di postazione e disporre sempre del proprio ambiente di lavoro tra cui la cartella Documenti, i preferiti del browser, il desktop, l’elenco dei file recenti, la struttura del menu Avvio, la posta elettronica e così via. Oltre alla comodità di poter avere la propria scrivania su qualunque computer della rete, si ha anche una funzione di accentramento sul server di molte informazioni che generalmente vengono salvate solo localmente. Si pensi per esempio alla posta. Sono poche le piccole e medie imprese che eseguono un backup di queste informazioni, tipicamente memorizzate sui singoli client. In caso di rottura del disco locale o di danno al file system si perde tutta la base di messaggi personali archiviati nel corso degli anni. Lo svantaggio maggiore comportato dai roaming profile consiste nel carico di rete. Ogni volta che si entra o si esce avviene un’operazione di sincronizzazione con il server e questo comporta un utilizzo della banda locale. Nel caso si abbiano migliaia di messaggi archiviati, magari con allegati o si disponga di una cospicua cartella documenti, si sperimenterà una lentezza apprezzabile. Se questo aspetto può risultare problematico si consiglia di evitare l’uso dei profili mobili e di saltare al prossimo paragrafo. logon path = \\server1\profili\%u

Questa direttiva attiva i profili mobili segnalando a Samba che la directory dove memorizzare i profili si trova nella condivisione \profili\%u di server1. Ancora una volta non si tratta di un riferimento al file system di Linux, ma di una condivisione di rete.

Anche in questo caso viene impiegata una variabile per fare in modo che sia utilizzata una directory separata per ogni utente. La condivisione profili è definita più in basso, in un apposito blocco: Listato 2.4

[profili] path = /usr/local/samba/profili read only = NO writable = YES browsable = NO create mask = 0600 directory mask = 0700

È importante rilevare che si è scelto di rendere questa condivisione non visibile da Risorse di rete, utilizzando la direttiva browsable = NO. Durante la configurazione dei profili mobili si deve prestare attenzione ai diritti impostati sulla directory /usr/local/samba/profili del server Linux. Tutti gli utenti devono potervi accedere, leggere e scrivere. Per farlo si deve usare il comando chmod: chmod 777 /usr/local/samba/profili

Windows 95 e 98 utilizzano un meccanismo differente per gestire i profili mobili. In tal caso non viene utilizzata la direttiva logon path, ma la direttiva logon home per specificare la cartella utente. La documentazione ufficiale di Samba consiglia di specificare questa sintassi nel caso di Windows 95 e 98: logon home = \\server1\%U\profile

Samba gestirà questo percorso in maniera dinamica. Nel caso cioè di assegnamento di una lettera alla home directory, verrà considerata solo la porzione \\server1\%U. Nel caso invece di utilizzo dei profili mobili sarà usato il percorso completo e il profilo sarà memorizzato dentro la directory profile.

Script di logon Quando il client accede al PDC può ricevere automaticamente dal server un file batch con una serie di comandi da eseguire. In questo batch possono essere presenti diversi comandi, come la sincronizzazione dell’orologio del computer locale con il server e l’attivazione di un certo numero di condivisioni. Si tratta di un buon sistema per rendere omogeneo l’ambiente di rete ed evitare di dover visitare tutte le postazioni ogni volta che si crea una nuova condivisione aziendale. Basta infatti aggiungere una riga al batch e in questo modo tutte le macchine attiveranno le nuove condivisioni all’ingresso. Per attivare gli script di logon basta indicare la direttiva seguente: logon script = logon.bat

Durante il logon, il file logon.bat sarà automaticamente scaricato dal server ed eseguito. Non viene indicato alcun percorso per individuare il file, in quanto esiste una condivisione di Windows dedicata a questo scopo. Si tratta di netlogon, che viene creata di default sui server Windows. Su Samba, invece, è necessario replicare tale comportamento creando un opportuno blocco di definizione per la condivisione: Listato 2.5

[netlogon] path = /usr/local/samba/netlogon read only = YES write list = root

La directory è di sola lettura e solo l’utente root ha la facoltà di scrivere in questa condivisione (direttiva write list = root). La directory è visibile da Risorse di rete, come avviene con i PDC basati su

Windows. Dentro la condivisione netlogon è contenuto il file logon.bat, che deve essere scritto su una macchina Windows e poi salvato su Linux, in quanto questi due sistemi operativi gestiscono in maniera differente l’invio a capo. Un batch scritto su Linux potrebbe avere problemi di funzionamento sulle macchine Windows. Un file batch di logon potrebbe avere la fisionomia seguente: NET TIME \\server1 /SET /YES NET USE G: \\server1\comune NET USE M: \\server1\gestionale

La prima riga sincronizza l’ora locale con l’orario del server. Le righe seguenti si limitano invece ad agganciare alcune condivisioni a due lettere di unità. Tutte le macchine vedranno così l’area comune e l’area gestionale rispettivamente come G: e M:. Naturalmente è necessario scrivere sul file di configurazione di Samba due blocchi con le relative definizioni delle condivisioni: Listato 2.6

[comune] comment = cartella comune path =/home/comune public = YES writable = YES [gestionale] comment = area supporto software gestionale path =/home/gestionale public = YES writable = YES

Durante la costruzione degli script di logon bisogna prestare attenzione ai limiti imposti alle singole condivisioni nel file di configurazione di Samba. Se, per esempio, si fa in modo che solo le postazioni in amministrazione possano vedere l’area gestionale, gli utenti dell’ufficio tecnico vedranno un messaggio d’errore durante l’accesso, in quanto lo script di logon tenterà di agganciarsi a una directory a cui l’utente non ha accesso. Per risolvere questi problemi bisogna ricorrere a programmi di scripting più complessi, dotati di clausole condizionali. In questo modo è possibile specificare, per esempio, che se l’utente fa parte del gruppo dell’ufficio tecnico dovrà vedere la condivisione ufftec, ma non l’area gestionale mentre, viceversa, gli utenti del gruppo Amministrazione vedranno la condivisione gestionale e non ufftec. Kixtart (http:/www.kixtart.org) è una soluzione di scripting in grado di gestire queste situazioni ed è inoltre ben documentata e corredata da esempi. Se non si vuole qualcosa di così complesso, si può semplicemente creare un file batch per ogni utente. Ogni file di login sarà in questo modo dedicato e conterrà solo le condivisioni rilevanti per l’utente in oggetto. In questo caso si devono creare tanti file batch quanti sono gli utenti e salvarli con il nome dell’utente seguito dall’estensione .bat, per esempio amm1.bat, amm2.bat, ufftec1.bat, dir.bat e così via. Per fare in modo che Samba scarichi il file corretto si deve usare una direttiva dotata di variabile, simile a

quella riportata di seguito: logon script = %u.bat

Attraverso la variabile %u sarà composto dinamicamente il nome del file batch da caricare dalla condivisione netlogon.

Abilitazione di utenti e computer La configurazione di Samba può considerarsi conclusa. Il file di configurazione smb.conf può diventare difficile da leggere nel caso raggiunga una dimensione cospicua. Per facilitarne la comprensione si possono inserire alcuni commenti al suo interno. I commenti testuali vanno preceduti dal cancelletto (#). Questo è il nuovo file di configurazione: Listato 2.7

[global] workgroup = INCIPIT netbios name = SERVER1 server string = PDC Linux security = USER smb passwd file = /etc/samba/smbpasswd encrypt passwords = YES log file = /var/log/samba/%m.log max log size = 100 log level = 1 # impostazione del server come domain master browser os level = 255 preferred master = YES local master = YES domain master = YES # abilitazione dei logon W95/W98 domain logons = YES # attivazione supporto WINS wins support = YES # impostazione homedir logon home = \\server1\homedir logon drive = U: # impostazione profili mobili logon path = \\server1\profili\%u # impostazione script di logon logon script = logon.bat #logon script = %u.bat [netlogon] path = /usr/local/samba/netlogon read only = YES write list = root [profili] path = /usr/local/samba/profili read only = NO writable = YES browsable = NO create mask = 0600

directory mask = 0700 [homedir] path = /home/%u read only = NO writable = YES browsable = NO create mask = 0600 directory mask = 0700 hide dot files = YES [comune] comment = cartella comune path =/home/comune public = YES writable = YES [gestionale] comment = area supporto software gestionale path =/home/gestionale public = YES writable = YES [software] comment = file di utilita' path =/home/software public = YES writable = NO

Come per la configurazione di un workgroup, è necessario creare sia gli utenti abilitati al dominio all’interno di Linux, sia un utente con lo stesso nome sul sistema Samba tramite l’utility smbpasswd. Ma su un dominio, anche i computer devono essere autenticati per poter accedere alla rete. Tale scelta garantisce una maggiore sicurezza, in quanto ogni singola macchina è dotata di una chiave di protezione univoca. Questo impedisce che qualcuno possa accedere al dominio cambiando nome alla propria macchina e fingendosi una macchina abilitata. L’abilitazione di un computer è una procedura molto simile a quella eseguita per abilitare gli utenti. Prima di tutto è necessario creare un utente sul sistema Linux con lo stesso nome della macchina digitando questa sintassi: useradd -g domaincomputers -d /dev/null -s /bin/false nomemacchina$

Il parametro -g indica che il nuovo utente apparterrà al gruppo domaincomputers. Questo gruppo dovrà essere stato preventivamente creato con il seguente comando: groupadd domaincomputers

Il parametro -d specifica la directory home che Linux assocerà all’utente. Ogni utente è sempre dotato di una propria cartella sul sistema, ma in questo caso la cosa è del tutto superflua. Non si sta infatti creando un utente, ma piuttosto un profilo per un computer. Tale profilo non accederà mai al sistema Linux dalla shell interattiva e perciò non ci sarà mai bisogno della directory home. Si specifica allora /dev/null, una sorta di sinonimo per indicare nessuna posizione sul file system. Il parametro -s indica la shell di login per l’utente. Anche in questo caso non ne serve alcuna, perché si tratta di un computer e non di un utente. Si specifica allora /bin/false. Questo eseguibile non svolge alcuna attività e si limita a uscire appena viene invocato. Si ha infine il nome della macchina che si sta abilitando, seguito dal simbolo obbligatorio di $ (convenzione NetBIOS). Il nome della macchina deve essere ricavato da Windows XP trascinando il puntatore sopra Risorse del

computer, facendo clic sul tasto destro del mouse e selezionando la voce Proprietà. Dalla finestra relativa si deve fare clic sulla scheda Nome computer (Figura 2.1). Il nome della macchina è indicato in Nome completo computer. È fondamentale che il nome su Windows XP coincida con quello su Samba.

Figura 2.1 La scheda Nome computer contiene informazioni per l’identificazione del PC all’interno della rete locale.

Ora bisogna utilizzare il comando smbpasswd e creare un riferimento alla macchina sul file delle password di Samba: smbpasswd -a -m nomemacchina

Il parametro -a indica che si tratta di un nuovo riferimento e che il nome deve essere aggiunto al file delle password di Samba. Il parametro -m indica che si sta aggiungendo l’account di un computer e non di un utente ed è seguito dal nome del computer, questa volta senza il simbolo di $. Premendo Invio si procede alla registrazione della entry nel file delle password di Samba. Se ora si accede alla directory /etc/samba e si apre il file passwd, in fondo a esso si potrà notare l’account appena creato. Durante le operazioni di abilitazione delle macchine è importante evitare che i nomi dei computer coincidano con i nomi degli utenti abilitati in Samba.

Aggiunta del client al dominio

Il sistema è pronto: non resta che aggiungere al dominio la macchina Windows. Si deve nuovamente portare il puntatore del mouse su Risorse del computer, fare clic con il tasto destro del mouse e selezionare la voce Proprietà. Dalla finestra che si apre si dovrà fare clic sulla scheda Nome computer e premere il pulsante ID di rete, per attivare la procedura guidata di annessione al dominio. Al primo passaggio, nella finestra Identificazione guidata rete bisogna fare clic nella casella di selezione presente in alto, per indicare che il computer fa parte di una rete aziendale (Figura 2.2).

Figura 2.2 Nella configurazione guidata di rete, prima di tutto, si deve indicare che il sistema fa parte di una rete aziendale.

Nel passaggio seguente bisogna ancora selezionare la voce in alto per indicare che la propria azienda utilizza un dominio (Figura 2.3).

Figura 2.3 Successivamente bisogna specificare il tipo di rete.

Al passaggio seguente si deve indicare un nome utente abilitato in Samba (per esempio amm1), la password relativa e il dominio (INCIPIT), come mostra la Figura 2.4.

Figura 2.4 Dettagli relativi all’account che si sta abilitando.

Confermando potrebbe essere necessario indicare manualmente il nome del computer e il dominio di appartenenza (Figura 2.5).

Figura 2.5 Dettagli relativi al computer che si sta abilitando.

Bisogna infine indicare un account di amministrazione con autorizzazione di accesso al dominio (Figura 2.6).

Figura 2.6 Per concludere si devono sempre fornire le credenziali di un account di amministrazione.

In questo passaggio bisogna indicare l’utente root di Samba, la relativa password e nuovamente il dominio. Attenzione a non fare confusione, perché si deve usare la password per l’utente root specificata in Samba, non quella di Linux. Se si è dimenticata la parola chiave si può usare nuovamente il comando smbpasswd -a root per sostituire la vecchia password di Samba con una nuova. Premendo il tasto Invio si conclude la procedura. Le modifiche non vengono applicate subito, ma è

necessario eseguire un riavvio del computer. Completato il caricamento si dovrà digitare il dominio INCIPIT nella finestra di logon, inserire il nome utente e la password: quest’ultima sarà verificata sul server e in caso di successo, verrà creato il profilo mobile, sarà collegata la directory home e lanciato lo script di login. A questo punto si farà parte del dominio. Si potrà immediatamente notare il modo in cui viene gestita la sicurezza in un dominio quando si cercherà di condividere una cartella: sarà infatti richiesto a quali degli utenti presenti sul server concedere l’accesso alla cartella in oggetto. A questo punto potrebbero verificarsi problemi nella condivisione della cartella o l’impossibilità di eseguire anche le più semplici operazioni amministrative, come cambiare la pagina iniziale del browser, selezionare lo sfondo, cambiare IP e così via. Il nuovo utente creato potrebbe non avere un profilo sufficientemente alto sulla macchina locale ed essere un semplice utente, pur essendo a pieno titolo membro del dominio. Bisogna tenere sempre a mente che le macchine Windows collegate a un dominio hanno comunque bisogno di un profilo locale specifico. Se si dimentica questo passaggio si potrebbe essere poco più che un guest, un utente con diritti minimi. Questo non è necessariamente un fatto negativo, anzi: tale soluzione può andare bene in un ambiente di lavoro, in quanto impedisce che gli utenti possano riconfigurare le postazioni. Se però si desidera dare pieno accesso, bisogna entrare in Windows come administrator specificando come dominio il nome della macchina. Si deve andare nel Pannello di controllo e fare clic sull’icona Account utente. Dovrebbero comparire in elenco due righe con lo stesso nome utente; una riga specifica il dominio locale (il nome del dominio locale è il nome del PC) e l’altra il dominio di rete. Qualora manchi l’account di dominio, si deve procedere alla sua creazione specificando il nome utente (lo stesso di quello di dominio) e il dominio corretto. Poi si deve fare clic sul pulsante Avanti. Nella finestra successiva bisogna specificare il livello (usare administrator per conferire il massimo accesso) e fare clic su Fine. Potrebbe essere necessario eseguire un riavvio. Completato il caricamento del sistema operativo si può rientrare nel dominio e l’utente avrà piena libertà sulla macchina locale. Sul dominio resteranno validi i diritti impostati nel server.

Checklist 1. Verificare che il pacchetto Samba sia installato nel proprio sistema, digitando il comando testparm. Se compare un messaggio d’errore, significa che Samba non è presente e bisogna procedere alla sua installazione. 2. Salvare in un luogo sicuro il file di configurazione di default di Samba, quindi creare un nuovo file smb.conf nella directory /etc/samba. 3. Aprire il file smb.conf e creare la sezione global. 4. Inserire nella sezione global le direttive workgroup, netbios name e server string. 5. Impostare nella sezione global il livello di sicurezza dell’utente, aggiungendo la direttiva security = USER. 6. Impostare il file delle password tramite la direttiva smb passwd file. 7. Indicare la gestione delle password cifrate tramite la direttiva encrypt passwords = YES. 8. Inserire le direttive necessarie per specificare le funzionalità di log. 9. Impostare la macchina Samba come Master Browser List e come Domain Master, utilizzando le direttive os level, preferred master, local master e domain master. 10. Attivare il servizio WINS di Samba con la direttiva wins support = YES. 11. Aggiungere la direttiva domain logons = YES solo nel caso in cui sia necessario unire al dominio

sistemi Windows 95/98/ME. 12. Abilitare le directory utente, se necessario. 13. Abilitare i roaming profile, se necessario. 14. Abilitare lo script di logon e creare su una macchina Windows il file batch. 15. Impostare una condivisione, creando nel file di configurazione una sezione contenente almeno le direttive comment e path. 16. Indicare l’elenco degli utenti autorizzati ad accedere alla condivisione, con la direttiva valid users. 17. Specificare gli eventuali utenti non autorizzati, utilizzando la direttiva invalid users. 18. Inserire la direttiva writable = YES per rendere accessibile in scrittura la condivisione. 19. Impostare correttamente i permessi Linux sulla directory che si sta condividendo. 20. Ripetere i passaggi da 15 al 19 per creare eventuali altre condivisioni. 21. Creare sul sistema Linux gli account degli utenti Windows che potranno accedere alle condivisioni. 22. Creare le password di Samba per gli account appena creati, usando il comando smbpasswd. 23. Abilitare i computer che potranno accedere al dominio di Samba. Si deve creare sulla macchina Linux un utente con lo stesso nome del computer, poi bisogna impostare una password utilizzando il comando smbpassswd. 24. Impostare le direttive di sicurezza per il sistema. 25. Verificare la correttezza della configurazione utilizzando il comando testparm. 26. Avviare i demoni di Samba e fare in modo che siano sempre lanciati a ogni avvio del sistema. 27. Aggiungere le postazioni al dominio.

Capitolo 3

Capitolo 3 - Creazione di un print server con Samba Un print server è un elemento preposto ad accogliere le richieste di stampa inoltrate dai client presenti in rete e di indirizzarle a una o più stampanti fisicamente collegate al sistema. Il print server permette in sostanza di condividere in LAN una stampante che originariamente è nata come unità locale da collegarsi a un singolo computer tramite la porta USB o parallela. Si tratta di una funzionalità utile e molto apprezzata dalle aziende, soprattutto quelle più piccole, dal momento che le stampanti dotate di porte di rete Ethernet hanno costi più alti. Fortunatamente è molto semplice ed economico realizzare un print server attraverso Linux e risolvere le necessità di condivisione. Nelle prossime pagine si vedrà come mettere in pratica questa soluzione. Il prerequisito è la disponibilità di un sistema Linux dotato di Samba e configurato in modalità workgroup o dominio. A tal proposito si daranno per messi in atto i concetti e le tecniche di cui si sono occupati i Capitoli 1 e 2. Le configurazioni presentate in quei capitoli saranno arricchite con i blocchi e le direttive necessarie per la gestione della stampa. C’è però un concetto da tenere bene in considerazione: Samba è preposto unicamente alla gestione della condivisione della stampante e della relativa coda di stampa in rete. Il pacchetto non ha la capacità di interagire direttamente con la stampante o di eseguire alcun tipo di elaborazione sui dati. Queste operazioni sono invece svolte da un componente software denominato “sistema di stampa”. Samba si appoggia completamente a questo servizio, inoltrandogli il flusso di dati ricevuti dai client presenti in rete. Il sistema di stampa catturerà i dati e provvederà alla comunicazione con la stampante per realizzare la stampa fisica dei lavori. Il sistema di stampa è un aspetto cruciale e prima di eseguire qualunque configurazione su Samba è necessario dare uno sguardo a questo elemento.

La stampa su Unix La stampa è una delle aree in cui Linux è stato storicamente considerato debole. Fino a qualche tempo fa si aveva infatti un supporto limitato, riservato a stampanti a modo testo o a costose unità dotate di una scheda interprete per il PostScript. Non si poteva in questo scenario pensare di recarsi in un centro commerciale e comprare una stampante scegliendola, come si fa abitualmente, in base alle proprie esigenze di velocità, risoluzione, qualità e costo. Nella maggior parte dei casi questa stampante non avrebbe funzionato su Linux. Per questo motivo la stampa di lavori complessi su Linux era qualcosa di riservato alle organizzazioni più facoltose, in grado di permettersi stampanti laser di buon livello. Ora la situazione è ben diversa, grazie a un sistema di stampa Open Source denominato CUPS (Common UNIX Printing System), disponibile all’indirizzo www.cups.org (Figura 3.1). Si tratta di un progetto un tempo indipendente, diventato nel 2007 proprietà di Apple. L’acquisizione non ha alterato la diffusione e la disponibilità di CUPS e non si sono verificati gli scenari di chiusura che molti avevano prospettato.

Figura 3.1 Sito ufficiale di CUPS.

CUPS fornisce ai costruttori di hardware e agli sviluppatori un supporto completo per la stampa. Qualunque costruttore può in questo modo creare driver Linux per le proprie stampanti, mentre i programmatori possono agganciarsi a CUPS per trasportare su carta i documenti elaborati sugli applicativi. Linux pareggia così la distanza con Windows, sistema operativo storicamente dotato di un sistema di stampa di buona qualità e ben documentato. CUPS non è l’unico sistema di stampa disponibile per Linux, ma è quello che ha certamente maggiore successo e diffusione. Gran parte delle distribuzioni integra infatti questo meccanismo in maniera nativa. Il successo è dato in buona misura dalla scelta di aderire al protocollo IPP, uno standard promosso da IEEE (Institute of Electrical and Electronics Engineers) per la stampa aperta in ambienti di rete. Samba supporta pienamente il sistema di stampa CUPS e nelle prossime pagine si vedrà come usufruirne.

Configurazione della stampante con CUPS Per cominciare occorre verificare che il sistema CUPS sia presente sul sistema Linux. Per farlo si può utilizzare il sistema di gestione dei pacchetti e verificare la presenza del pacchetto. Su un sistema basato su Red Hat, come per esempio CentOS o Fedora Core, si può usare la sintassi seguente: rpm -q cups

Su Ubuntu si può invece usare questa sintassi: dpkg -l cups

Se il pacchetto è disponibile, dovrebbe comparire una riga con un messaggio di conferma. Nel caso CUPS non sia presente si deve procedere alla sua installazione attraverso i meccanismi messi a disposizione dalla propria distribuzione. Si tratta comunque di una situazione poco comune nelle distribuzioni oggi

disponibili: tutte le installazioni di default, anche quelle “light”, includono CUPS nell’elenco dei pacchetti base. Verificata la presenza del sistema di stampa si può procedere alla sua configurazione. Si prenderà come esempio il caso di un piccolo ufficio con alcuni impiegati che hanno tutti bisogno di stampare. I volumi di stampa in questo ufficio sono modesti e non sussiste l’esigenza di fornire una stampante a ogni utente. Si punterà piuttosto al risparmio condividendo una piccola unità. Per cominciare si deve lanciare il demone di CUPS: /etc/init.d/cups start

La configurazione prosegue ora attraverso un pannello web per l’impostazione guidata della stampante. Nel browser del server Linux si deve digitare l’indirizzo web http://127.0.0.1:631. CUPS risponderà con il pannello principale di gestione e configurazione del sistema (Figura 3.2).

Figura 3.2 Pannello w eb per la configurazione di CUPS.

Su alcune distribuzioni, per motivi di sicurezza è possibile lanciare il pannello di configurazione web solo dal server locale. Se si desidera accedere anche dalla LAN, si deve editare il file di configurazione principale /etc/cups/cupsd.conf, cercare la direttiva Listen e operare alcune modifiche. La direttiva indica a CUPS su quali schede di rete restare in ascolto e su quali porte. L’esempio seguente, default in molte distribuzioni, permette l’accesso al solo traffico proveniente dall’interfaccia di loopback locale, quindi solo dal server stesso: Listen 127.0.0.1:631

Se la scheda eth0 è configurata con l’indirizzo 192.168.100.20, si può permettere l’accesso a tutta la sottorete IP relativa indicando questa direttiva: Listen 192.168.100.20:631

Il comando segnala a CUPS di ascoltare le richieste sulla scheda di rete agganciata all’IP

192.168.100.20, sulla porta 631.

Non è però sufficiente. Si deve anche indicare quali indirizzi della LAN sono abilitati all’accesso. Per farlo bisogna cercare la direttiva e abilitare per esempio la propria sottorete IP, come in questo esempio:

Order allow, deny Allow 192.168.0.0/24

È stata aggiunta la riga Allow 192.168.0.0/24 per abilitare l’accesso a tutta la sottorete 192.168.0.0. Si dovrà ripetere l’abilitazione anche per le sezioni /admin e /admin/conf. Ora qualunque computer della LAN può puntare con un browser l’IP del sistema Linux con CUPS e accedere alla porta 631. Si vedrà così in apertura la pagina mostrata in Figura 3.2.

Impostazione guidata di una stampante USB La configurazione della stampante con il pannello web di CUPS è una procedura rapida. Inizialmente non dovrebbe essere presente alcuna configurazione. Bisogna quindi scegliere Aggiungi stampante (oppure Add Printer se si dispone di una versione inglese del sistema di stampa). Comparirà un pannello specifico per la configurazione. Nella riga Name si deve inserire il nome della coda di stampa. Deve essere una stringa corta e senza spazi, cancelletti o barre (/), per esempio Canon. In Location e in Description vanno inseriti testi liberi per indicare il luogo in cui si trova l’unità (per esempio Ufficio tecnico) e la descrizione estesa dell’unità (per esempio Canon Pixma iP6000D) (Figura 3.3). Inserite queste informazioni si fa clic su Continua (oppure Continue se si dispone di una versione inglese del sistema di stampa).

Figura 3.3 Aggiunta di una nuova stampante nel sistema CUPS.

Nella sezione seguente si deve indicare il device di sistema che rappresenta la stampante. Nel caso di connessione USB dovrebbe comparire una riga che identifica la stampante. Se si tratta di una stampante che usa un altro tipo di connessione, per esempio la porta parallela, si deve indicare la voce corretta, per esempio LPT #1. In questo esempio viene utilizzata una stampante Canon connessa tramite una porta USB (Figura 3.4).

Figura 3.4 La stampante USB Canon si aggancia attraverso l’apposito device di sistema.

Il passo seguente richiede il modello della stampante. Bisogna scorrere la lista, selezionarlo e confermare la scelta. Difficilmente però la lista comprenderà tutti i modelli commercializzati dal produttore. In tal caso bisogna aggiungere nel sistema il driver specifico, se fornito dal produttore, oppure selezionare un modello compatibile. Le stampanti sono infatti realizzate per famiglie che condividono la stessa logica di stampa. Basta individuare il modello compatibile corretto tramite il sito del produttore o consultando i gruppi di discussione Linux. La stampante Canon Pixma iP6000D non è presente nell’elenco predefinito. L’unità è però compatibile con il driver per la BJC7100, a patto che si imposti in seguito la risoluzione a 1200x600 DPI. Si seleziona quindi la BJC7100 in questo passaggio (Figura 3.5) e si conferma la scelta. Potrebbe essere richiesto di indicare le credenziali di amministratore del sistema Linux. La coda sarà creata solo a seguito del corretto inserimento di queste informazioni.

Figura 3.5 Selezione del modello di stampante.

Altre stampanti potrebbero avere il driver già incluso in CUPS oppure avere driver scaricabili dal sito del produttore. La coda creata potrà essere usata da Samba, ma anche dagli applicativi presenti sul server Linux stesso.

Configurare una stampante parallela Se si utilizza una vecchia stampante parallela, si deve percorrere la stessa procedura di configurazione esaminata in precedenza. Dopo aver indicato il nome della stampante, l’ubicazione e il commento, si deve specificare, al secondo passaggio, l’intenzione di usare il device parallelo (Figura 3.6) e poi confermare la scelta.

Figura 3.6 Selezione del device LPT per una stampante parallela.

Al passaggio seguente viene richiesta la marca della stampante. Si può anche evitare di selezionare il nome del produttore, ma scorrere l’elenco alla ricerca della modalità Raw (Figura 3.7). In questo modo si chiede al sistema di stampa di non compiere alcuna forma di elaborazione sul processo di stampa e di inoltrare tutto il flusso direttamente alla stampante. Saranno i driver presenti sulle singole macchine Windows a realizzare la conversione del lavoro in un flusso di dati compatibile con la stampante utilizzata. Si conferma la scelta facendo clic sul pulsante di avanzamento in fondo.

Figura 3.7 La modalità Raw è consigliabile per le stampanti laser collegate tramite la porta parallela.

Nel pannello seguente si deve scegliere il modello di stampante. Avendo scelto Raw si avrà un unico modello, ancora una volta di tipo Raw. Basta semplicemente confermare la scelta e fare clic su Aggiungi stampante (oppure Add Printer se si usa una versione inglese del pacchetto). Ora la stampante di tipo Raw è presente nel sistema ed è pronta per essere utilizzata da Samba. Se c’è bisogno di stampare da applicazioni che girano sulla macchina Linux locale è necessario configurare una seconda coda di stampa, ma questa volta nella sezione Marca è necessario specificare il produttore della stampante e in Modello il modello specifico o uno compatibile.

Ritoccare la configurazione di CUPS Completate le configurazioni guidate è importante eseguire alcune verifiche manuali sui file di configurazione, per essere sicuri che tutto sia impostato correttamente. Bisogna andare in /etc/cups e aprire il file mime.types. In fondo c’è un parametro denominato application/octet-stream: bisogna assicurarsi che non sia preceduto dal carattere # (commento). Questo impedirebbe la stampa in formato raw. Occorre poi aprire il file mime.convs e verificare nuovamente che non ci sia il commento per la riga in che inizia con application/octet-stream. Se sono state eseguite delle modifiche bisogna riavviare il sistema CUPS: /etc/init.d/cups restart

Le impostazioni appena implementate permettono ai job in formato raw di essere gestiti correttamente da CUPS.

Configurazione della stampante in SAMBA Ora è il momento di configurare Samba. Non si deve realizzare una nuova configurazione, ma bisogna piuttosto continuare da un’impostazione di workgroup o di dominio già funzionante. Nell’eventualità che questa operazione non sia stata eseguita, si devono prima di tutto seguire le indicazioni presenti nei Capitoli 1 o 2. Il file di configurazione di Samba per il dominio o il workgroup deve essere arricchito con alcuni parametri che indicano l’utilizzo del sistema CUPS per la stampa. Questo dettaglio va indicato nella sezione global tramite due direttive: printing = CUPS printcap = CUPS

Ora bisogna creare una sezione denominata printers e specificare alcuni aspetti relativi alla stampa: Listato 3.1

[printers] comment = stampanti sul server path = /var/spool/samba printable = YES use client driver = YES

Il nome della sezione, ovvero printers, è obbligatorio e indica a Samba che si stanno specificando

informazioni relative alle stampanti da condividere. La riga comment contiene un’indicazione a testo libero. La direttiva path si riferisce al percorso sul file system del server Linux dove verrà eseguito lo spooling dei job di stampa. I dati in arrivo dai client e destinati alla stampa saranno salvati in questo punto e poi inoltrati alla stampante. L’operazione non è però necessariamente diretta. CUPS utilizza di default una propria area di spooling, generalmente /var/spool/cups. Ogni job di stampa potrebbe quindi transitare in due directory di spooling prima di giungere alla stampante. La direttiva printable = YES permette ai client di scrivere sullo spooler. L’ultima direttiva, use client driver = YES, serve per informare i client Windows collegati al server Samba che dovranno usare i driver installati localmente per eseguire la stampa. Configurando in maniera avanzata CUPS è possibile installare i driver di stampa sul server Linux e fare in modo che questi siano prelevati automaticamente dal server. In tal caso la direttiva sarà use client driver = NO. Questa funzionalità può essere molto utile quando si hanno molti client che accedono alle stampanti condivise. Attraverso un’opportuna configurazione sul server si può evitare di configurare ogni singolo client. Per maggiori dettagli su come configurare CUPS e Samba per abilitare questa funzionalità si consulti la guida “The Official Samba 3.5.x HOWTO and Reference Guide”, sezione CUPS, disponibile online all’indirizzo http://samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-printing.html. A questo punto si può salvare il file di configurazione di Samba e riavviare il servizio. Samba caricherà automaticamente le stampanti precedentemente configurate e le farà comparire in Risorse di rete (Figura 3.8).

Figura 3.8 Stampanti configurate con CUPS e visualizzate in Risorse di rete.

Bisogna tenere ben presente che se si eseguono modifiche alle configurazioni delle stampanti tramite il pannello di amministrazione di CUPS bisogna riavviare il servizio Samba per usufruire delle nuove stampanti.

Installazione dei driver sui client Windows Il lavoro sul versante server è concluso. Non resta che caricare i driver di stampa sui client Windows. Si deve andare in Pannello di controllo, selezionare l’icona Stampanti e fax e fare clic su Aggiungi stampante.

Al primo passaggio bisogna specificare che si sta installando una stampante di rete (Figura 3.9).

Figura 3.9 Al primo passaggio si deve indicare che la stampante si trova in rete.

Ora occorre selezionare l’opzione Connetti alla stampante (Figura 3.10) e poi fare clic su Avanti. Comparirà l’elenco dei sistemi presenti in rete. Si deve scegliere il print server Samba, in questo caso server1, selezionare la stampante impostata e poi fare clic su Avanti (Figura 3.11).

Figura 3.10 Al passaggio seguente si deve indicare che si desidera cercare la stampante in rete.

Figura 3.11 Selezione del print server e dell’unità di stampa.

A questo punto occorre selezionare il driver dall’elenco presente in Windows (Figura 3.12) oppure indicare il percorso del driver scaricato dal sito del produttore.

Figura 3.12 Scelta del driver di stampa in W indow s.

Per concludere la fase di installazione della stampante, bisogna specificare se l’unità è predefinita o meno. Eseguita la scelta si fa clic su Avanti. Ora si può cominciare a stampare sul server di stampa. Da un punto di vista pratico non sussiste alcuna differenza tra una stampante locale e la stampante di rete appena realizzata. Non bisogna quindi cambiare alcun aspetto del proprio modo di lavorare. Di seguito è riportata la configurazione completa di Samba che è stata realizzata in questo capitolo usando un modello di rete a dominio. Listato 3.2

#Configurazione della sezione di stampa per un dominio [global] workgroup = INCIPIT netbios name = SERVER1 server string = PDC Linux security = USER smb passwd file = /etc/samba/smbpasswd encrypt passwords = YES log file = /var/log/samba/%m.log max log size = 100 log level = 1 # impostazione del server come domain master browser os level = 255 preferred master = YES local master = YES domain master = YES # abilitazione dei logon W95/W98 domain logons = YES # attivazione supporto WINS

wins support = YES # impostazione homedir logon home = \\server1\homedir logon drive = U: # impostazione profili mobili logon path = \\server1\profili\%u # impostazione script di logon logon script = logon.bat #logon script = %u.bat # impostazione stampa printing = CUPS printcap = CUPS [netlogon] path = /usr/local/samba/netlogon read only = YES write list = root [profili] path = /usr/local/samba/profili read only = NO writable = YES browsable = NO create mask = 0600 directory mask = 0700 [homedir] path = /home/%u read only = NO writable = YES browsable = NO create mask = 0600 directory mask = 0700 hide dot files = YES [comune] comment = cartella comune path =/home/comune public = YES writable = YES [gestionale] comment = area supporto software gestionale path =/home/gestionale public = YES writable = YES [software] comment = file di utilità path =/home/software public = YES writable = NO [printers] comment = stampanti sul server path = /var/spool/samba printable = YES use client driver = YES

Checklist 1. Utilizzare una configurazione Samba precedentemente creata per operare su un workgroup oppure su

un dominio. 2. Verificare che il pacchetto CUPS sia installato sul sistema. 3. Controllare gli indirizzi IP abilitati alla configurazione di CUPS via browser. 4. Collegarsi al pannello web di CUPS, specificando l’indirizzo locale e la porta 631. 5. Configurare su CUPS una nuova stampante, facendo attenzione a impostare la modalità di elaborazione RAW. 6. Aprire il file /etc/cups/mime.types ed eliminare, se presente, il simbolo di commento dalla riga che inizia con #application/octet in fondo al file. 7. Aprire il file /etc/cups/mime.convs ed eliminare, se presente, il simbolo di commento dalla riga che inizia con #application/octet. 8. Aprire il file di configurazione di Samba e nella sezione global, inserire le direttive printing = CUPS e printcap = CUPS. 9. Creare una sezione printers nel file di configurazione di Samba. 10. Inserire la direttiva comment. 11. Indicare nella direttiva path il percorso della directory di spooling. Questa deve ovviamente essere una directory esistente e accessibile. 12. Inserire la direttiva printable = YES per poter effettuare le operazioni di spooling. 13. Inserire la direttiva use client driver = YES per usare i driver di stampa locali sui sistemi Windows NT/2000/XP/Vista/7. 14. Verificare la correttezza della configurazione di Samba utilizzando il comando testparm. 15. Riavviare i demoni di Samba. 16. Configurare i client.

Capitolo 4

Capitolo 4 - Realizzazione di un DNS con Bind La semplicità di Internet è un fenomeno recente, frutto della capillare diffusione creatasi a seguito della trasformazione da strumento governativo a mezzo disponibile al largo pubblico privato e commerciale. La Grande Rete, prima di questo passaggio epocale, era un ambiente molto specialistico, realizzato da tecnici e per tecnici. Percorrendo la storia a ritroso si arriva a un tempo in cui, per accedere a qualunque sistema, era necessario conoscere l’indirizzo numerico che identificava in maniera certa il server. L’immediatezza del www seguito da un nome facile da ricordare era qualcosa ancora lungi da venire. Con l’aumentare della complessità della Rete e del numero di utenti, cominciarono a essere chiari i limiti di un sistema che imponeva alle persone di ricordare gli indirizzi IP numerici o di sfruttare elenchi statici con le destinazione on-line abituali abbinate ai relativi indirizzi. Serviva una buona soluzione e una proposta dei primi anni Ottanta si rivelò efficace: fornire a ogni computer connesso un nome testuale facile da ricordare, per esempio apogeonline.com e creare un elenco on-line, liberamente accessibile, che associasse a ogni nome esteso l’indirizzo IP corrispondente. Per accedere a un server sarebbe bastato digitare il nome mnemonico e fare in modo che un automatismo eseguisse la conversione in indirizzo numerico tramite l’elenco pubblico. Questa soluzione non imponeva un cambiamento radicale della struttura tecnica di Internet: gli indirizzi numerici rimanevano alla base della Rete. Era solamente necessaria l’aggiunta di un server in grado di eseguire la conversione dal nome esteso al valore numerico IP corrispondente. Tale soluzione è valida ancora oggi, se pur con alcune modifiche e gli utenti di Internet ne fanno uso costantemente. Il nome di questo meccanismo è DNS (Domain Name Server).

Generalità sul DNS Il DNS è un servizio di rete che viene installato su un server raggiungibile. Il suo scopo è quello di ricevere interrogazioni dai client (per esempio www.apogeonline.com) e fornire in risposta il relativo indirizzo IP (nel caso precedente, 67.207.132.167). Per comprendere l’utilità pratica del DNS si consideri il caso di un’azienda che intenda attivare un sistema web per la vendita dei propri prodotti. Il primo passo consiste nel prendere in abbonamento una certa quantità di banda passante. Una compagnia deve cioè fornire un cavo dati ad alta velocità connesso alla rete Internet mondiale. Generalmente questa fornitura viene offerta da qualche carrier, per esempio Telecom Italia, che ha creato una rete dati ramificata nel territorio, connessa a tutti i punti di interscambio nazionali e internazionali. Ottenuta la connessione full time, bisogna richiedere l’assegnazione di un indirizzo IP fisso: si deve avere un valore univoco e permanente che identifichi il proprio server in modo che chiunque possa sempre accedervi semplicemente digitando quel numero. Gli indirizzi IP sono assegnati da un organismo internazionale preposto alla distribuzione secondo regole ben precise. Purtroppo non si tratta di una risorsa illimitata, ma bisogna piuttosto razionalizzare la distribuzione di questo bene. Secondo gli standard attuali si hanno circa due miliardi di indirizzi unici, buona parte dei quali già impegnati. Gli indirizzi non vengono quasi mai rilasciati all’utente finale, bensì ad aziende che operano nel settore delle telecomunicazioni o di Internet e dotate di comprovati requisiti tecnici. L’utente finale riceve in genere uno o più

indirizzi statici solo a seguito della stipula di un contratto di connettività con uno di questi operatori. Le connessioni professionali, anche quelle più accessibili basate su ADSL, sono generalmente corredate di pacchetti di indirizzi statici proprio per andare incontro a coloro che intendono pubblicare servizi online. Ottenuta la connessione veloce e l’indirizzo IP è possibile procedere con il negozio on-line. Il servizio di vendita può essere connesso a Internet a tempo pieno e reso accessibile da qualunque browser. Basta digitare l’indirizzo numerico assegnato dal provider. Difficilmente però si avrà successo se i potenziali acquirenti dovranno ricordarsi un lungo indirizzo numerico quando vorranno fare shopping. Bisogna quindi acquistare un nome di dominio attraverso un’apposita struttura di rilascio, per esempio Network Solutions (www.netsol.com). L’operazione è facile e permette di ottenere il dominio entro pochi minuti (Figura 4.1) a un costo di pochi dollari.

Figura 4.1 Netw ork Solutions è uno dei più famosi servizi internazionali di registrazione di domini.

Ora entra in gioco il DNS per l’associazione tra il nome simbolico acquistato e l’indirizzo numerico assegnato. L’obiettivo viene raggiunto installando un apposito servizio sulla stessa macchina che opera come server web oppure su un server a parte, purché raggiungibile dal mondo esterno. Si sceglie per questo esempio la seconda soluzione. L’elenco delle associazioni deve essere compilato manualmente dall’amministratore di sistema. Nel caso esaminato bisogna inserire una riga per l’indirizzo esteso acquistato (nella forma www.example.com) e abbinare l’indirizzo IP relativo. Con lo stesso principio si dovranno indicare eventuali altri servizi o nomi che si vogliono rendere pubblici. Il DNS dovrà infine essere collegato ad altri sistemi DNS per fare in modo che l’elenco dei nomi delle proprie macchine sia consultabile da tutto il mondo; in caso contrario sarà visibile solo localmente. Per farlo, si deve tornare nuovamente su Network Solutions, entrare nel pannello di gestione dell’account e indicare che il DNS che gestisce il dominio acquistato non è più il server di Network Solutions, ma un computer sotto la

propria gestione, di cui si deve fornire l’indirizzo. Per default è il server di Network Solutions che “traduce” i nomi di dominio acquistati, facendoli puntare a una generica pagina di parcheggio. Confermando la nuova configurazione si attiva una procedura di aggiornamento a livello internazionale e nel giro di alcune ore le nuove impostazioni saranno diffuse in tutti gli angoli del pianeta. Quando un utente digiterà sul browser l’indirizzo mnemonico del negozio online otterrà l'indirizzo numerico dalla gerarchia di server DNS presenti sulla rete Internet mondiale. A questo punto il browser eseguirà un accesso diretto a questo indirizzo in maniera trasparente, visualizzando le pagine. L’utilità del DNS non è limitata alle applicazioni Internet, quando è necessario pubblicare a tutto il mondo un server di contenuti o di servizio. Il DNS viene impiegato anche quando si gestisce una rete di computer o di server locali che devono essere accessibili dalla LAN tramite nomi estesi. All’interno del DNS saranno presenti in tal caso i nomi estesi delle macchine (per esempio amm1, amm2, ufftec, server01 e così via) e gli indirizzi numerici relativi (per esempio 192.168.100.10, 192.168.100.11, 192.168.100.15 e 192.168.100.5).

Utilità del DNS in una rete Windows L’esempio del negozio on-line dimostra l’importanza di un sistema DNS quando esiste la necessità di pubblicare un servizio per il largo pubblico. Non tutte le realtà hanno però le risorse necessarie per gestire internamente i servizi pubblicati su Internet. Spesso viene evitata la gestione locale del DNS e del server web. In tal caso tutti i problemi di setup e di gestione sono demandati a qualche azienda esterna, per esempio il fornitore di connettività, un’agenzia web o una società di servizi informatici. Purtroppo, però, il sistema DNS non è necessario solo quando si vogliano pubblicare risorse Internet. Lo strumento risulta vitale anche nel caso in cui si abbia una normale rete Microsoft, con Windows XP o 7 al suo interno. Anche Windows ha infatti bisogno di un meccanismo di risoluzione dei nomi. Le reti Microsoft, come quelle Internet, sono composte da computer che hanno nomi simbolici descrittivi, per esempio Amministrazione, UffTec1, ServerCentrale e così via. I computer funzionano però in rete locale per mezzo di indirizzi IP numerici. Nasce quindi nuovamente l’esigenza di un sistema in grado di convertire i nomi estesi in valori numerici. In passato, nelle reti dotate di Windows 95, 98, ME o server Windows NT, sussisteva un meccanismo di conversione molto semplice. Se UffTec1 aveva bisogno di accedere al pc Amministrazione per leggere un file di Excel, veniva prima di tutto cercato un server WINS. Si tratta di un componente di sistema su Windows NT 4 Server che è in grado di memorizzare in maniera automatica i nomi dei computer e i relativi indirizzi numerici. È un servizio molto simile al DNS, ma limitato all’ambito della rete locale Windows e aggiornato automaticamente dal server stesso. UffTec1 eseguiva allora un accesso al server dove era installato il WINS e interrogava il sistema per conoscere l’indirizzo di Amministrazione. Il sistema WINS verificava il proprio database e forniva la risposta a UffTec1. Come faceva però UffTec1 a sapere dove si trovava il server WINS? Ogni computer ha un campo di configurazione nel pannello del TCP/IP con l’indirizzo di questo servizio. UffTec1 avrebbe quindi eseguito un accesso al WINS attraverso l’IP indicato dall’amministratore in fase di configurazione. Non è però obbligatorio disporre di un server NT 4 o di un sistema WINS per ottenere la risoluzione dei nomi. Le reti Windows basate su Windows 9x/ME o NT4 sfruttavano anche altri meccanismi. Se non c’era il sistema WINS, veniva fatta la ricerca all’interno del file hosts, localizzato dentro la directory di sistema. Questo non è altro che un file di testo con un elenco di associazioni tra nomi simbolici e indirizzi numerici. Se non era presente neppure il file hosts, veniva impiegata una politica drastica: si effettuava il broadcast. UffTec1 mandava una comunicazione a tutti i computer presenti in rete, richiedendo ad Amministrazione di

fornire il proprio indirizzo. È un metodo efficace, che però crea traffico inutile sulla rete locale. Non è infatti molto sensato interpellare tutti i computer se si vuole in realtà “parlare” con uno solo di questi.

Cambiamenti in Windows 2000 La situazione è cambiata in maniera significativa a partire da Windows 2000, quando è divenuta necessaria la presenza di un server DNS per l’implementazione di una rete Windows. A partire da questa versione si risolvono i nomi estesi primariamente con il DNS e solo in seguito con i vecchi meccanismi WINS, file hosts e broadcast (nel caso il nome non sia presente nel DNS o non vi sia addirittura un server DNS). In pratica la risoluzione avviene con un meccanismo a quattro fasi, in cui il sistema operativo cerca di ottenere l’indirizzo usando strategie differenti. Molti tecnici di rete hanno però frainteso questo meccanismo. Se il DNS non è presente, verrà comunque utilizzato uno dei meccanismi convenzionali in maniera automatica. Perché allora darsi la pena di implementare un DNS interno? Non bisogna dimenticare che i membri di una rete locale dispongono di un indirizzo DNS per gli accessi a Internet. Se manca un DNS per la risoluzione interna sarà interrogato questo server DNS esterno ogni volta che si dovrà accedere per nome a un computer della rete locale. Naturalmente sui DNS mondiali non ci saranno indicazioni sulla macchina interna denominata Amministrazione. L’interrogazione restituirà un messaggio di host non trovato. Questa procedura non è istantanea e richiede un tempo relativamente alto per essere portata a termine. Solo dopo questo lasso di tempo verranno eseguiti tentativi di risoluzione interni. Gli utenti sperimenteranno in tal caso una notevole lentezza nell’uso dei servizi della LAN e si creerà un disservizio misurabile. In alcuni casi si possono avere ripercussioni anche economiche. In molte città non sono disponibili accessi a Internet flat. Il problema della connettività viene allora risolto con un accesso on-demand, per esempio un accesso UMTS che si attiva ogni qualvolta serve l’accesso a una risorsa Internet. La connessione rimarrà attiva per un lasso di tempo e poi verrà interrotta automaticamente. In un simile contesto ogni accesso a un computer interno comporterà l’accesso a Internet tramite rete cellulare per l’interrogazione di un DNS esterno. I tempi di accesso alle risorse saranno elevati e i costi in bolletta cresceranno inutilmente. Per risolvere tutti questi problemi è necessario installare un server DNS locale. Se si hanno però pochi client Windows non risulterà conveniente acquistare una licenza server di Windows. Il problema può essere allora risolto con una soluzione Linux e il pacchetto Bind, disponibile in tutte le distribuzioni ma comunque scaricabile dall’indirizzo http://www.isc.org/software/bind (Figura 4.2).

Figura 4.2 Sito ufficiale di Bind.

Bind permette di gestire un sistema DNS in maniera completamente standard e può essere di aiuto sia nel caso in cui si voglia rendere operativo un servizio pubblico su Internet, sia quando serve un’infrastruttura di risoluzione dei nomi per una rete locale basata su Windows.

Gestione di una rete Windows Si immagini di voler gestire con Bind la risoluzione degli indirizzi per una rete locale composta da tre client Windows XP Professional, un print server e una connessione a Internet tramite ADSL. Le macchine si chiamano PC1, PC2 e PC3 e hanno indirizzi IP interni, rispettivamente 192.168.100.10, 192.168.100.11 e 192.168.100.12. Il print server è invece configurato per rispondere all’indirizzo IP 192.168.100.50. Come si può notare, gli indirizzi sono impostati manualmente e non rilasciati con meccanismi di assegnazione automatica come DHCP. È stata operata questa scelta perchè il servizio DNS è di tipo statico e perciò tutte le macchine listate nel DNS devono mantenere lo stesso IP nel tempo. Se una macchina cambia indirizzo, bisogna aggiornare manualmente anche il DNS. In caso contrario, Bind fornirebbe il vecchio indirizzo a qualunque sistema che ne facesse richiesta.

Il sistema Linux può essere installato su una macchina di recupero, purché dotata di sufficiente memoria RAM e di un disco rigido veloce. Anche questo server avrà un indirizzo IP statico, 192.168.100.4 (Figura 4.3).

Figura 4.3 Schema delle rete locale dell’esempio trattato.

Configurazione del DNS Per personalizzare Bind bisogna innanzitutto cercare il file di configurazione principale che, a seconda delle distribuzioni, può trovarsi dentro la directory /etc oppure in /etc/bind con il nome named.conf. Il file contiene una configurazione generica di default applicata in fase di installazione della distribuzione. Probabilmente si avrà un file molto simile al seguente: Listato 4.1

## named.conf - configuration for bind # # Generated automatically by redhat-config-bind, alchemist et al. # Any changes not supported by redhat-config-bind should be put # in /etc/named.custom # controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; include "/etc/named.custom"; include "/etc/rndc.key"; zone "0.0.127.in-addr.arpa" { type master; file "0.0.127.in-addr.arpa.zone"; }; zone "localhost" {

type master; file "localhost.zone"; };

In alternativa si potrebbe avere un file molto stringato, con una serie di direttive include che non fanno altro che caricare altri file di configurazione. Si tratta di un modo per mantenere le configurazioni più modulari e ordinate. Il file named.conf può essere idealmente suddiviso in due parti: una sezione contenente impostazioni generali di funzionamento e una sezione contenente le definizioni delle “zone”. Le impostazioni generali (in Ubuntu nel file named.conf.options richiamato come include da named.conf) possono essere ignorate ai fini pratici, in quanto servono per il funzionamento base del server DNS e sono già impostate di default in un modo soddisfacente. Quello che interessa per questa trattazione è invece la sezione sulle zone (in Ubuntu nei file named.conf.local e named.conf.default-zones). Una zona è un insieme di computer raggruppati secondo un criterio arbitrariamente scelto dall’amministratore. Nelle piccole realtà si sceglie generalmente di identificare una zona con il dominio stesso. In pratica, se si ha un dominio per la propria azienda, si può creare una zona DNS con tutti i computer aziendali raggruppati con questo nome. Solitamente, come si può appurare osservando la configurazione di questo esempio, si hanno due zone: localhost e 0.0.127.in-addr.arpa. Sono nomi standard che si riferiscono al sistema locale, il primo per le ricerche dirette e il secondo per le ricerche inverse (l’etichetta in-addr.arpa è una formula storica che rappresenta sempre un dominio di ricerca inversa). Una ricerca diretta è un’interrogazione che punta a determinare l’indirizzo IP a partire dal nome esteso, per esempio fornendo il nome www.apogeonline.com. Ogni volta che si scrive un indirizzo mnemonico nel browser e si preme il tasto Invio della tastiera si genera un’interrogazione diretta al DNS per ottenere l’indirizzo IP del sistema che si vuole raggiungere. La ricerca inversa si ha invece quando si vuole sapere quale nome è associato a un determinato IP. Per convenzione il sistema locale è sempre associato all’IP 127.0.0.1. Questo valore, detto indirizzo di loopback, è stato introdotto per fare in modo che ogni macchina possieda sempre un indirizzo valido, anche se l’amministratore non ne imposta uno. L’utilizzo del loopback è rigorosamente interno. Non si troverà cioè mai un computer esterno con questo IP. Un ping verso 127.0.0.1 genererà un “anello” locale: la richiesta sarà gestita dal sistema TCP/IP del proprio computer, senza uscire dalla scheda di rete. Questa operazione è molto utile per verificare che lo stack TCP/IP stia funzionando correttamente. L’indirizzo nel tempo è diventato anche un modo comune per fare riferimento alla macchina stessa. Molte applicazioni e servizi di rete usano questo indirizzo per funzionare. In questo modo non hanno bisogno di sapere l’indirizzo IP che è stato assegnato dall’amministratore di sistema alla macchina locale. Molte configurazioni di default risultano così funzionanti appena installate nel sistema. La configurazione della zona localhost del file nel Listato 4.1 contiene un riferimento al file localhost.zone, mentre la specifica di zona 0.0.127.in-addr.arpa contiene un riferimento al file 0.0.127.in-addr.arpa.zone. Questi file si trovano in /etc/bind e sono la parte centrale del sistema DNS. Il file localhost.zone è così strutturato: Listato 4.2

$TTL 86400 @ IN SOA @ root.localhost ( 1 ; serial 28800 ; refresh

7200 ; retry 604800 ; expire 86400 ; ttl ) IN NS localhost. @ IN A 127.0.0.1

Il file inizia con una chiave $TTL 86400, che non deve essere cambiata, e un preambolo contraddistinto da SOA (Start Of Authority). Questo inizia con il simbolo @, finisce alla chiusura della prima parentesi tonda e contiene alcuni dettagli necessari al funzionamento del sistema DNS. Il simbolo @ è un sinonimo per quella che si chiama origine. Il file localhost.zone che si sta esaminando è stato specificato in named.conf nella zona localhost. L’origine è perciò localhost, il nome di zona specificato in named.conf. La prima riga del preambolo viene quindi tradotta in questo modo: localhost. IN SOA localhost. root.localhost (

Il punto alla fine di localhost indica che l’indirizzo è assoluto e letterale. Se non c’è il punto, si ha invece un indirizzo relativo, costruito aggiungendo in fondo il nome di zona. Ricapitolando, localhost. significa semplicemente localhost, mentre localhost (senza punto) viene automaticamente espanso in localhost.localhost ogni volta che viene usato. Questa scelta sintattica permette alcuni automatismi in Bind e serve per rendere più corti i file di configurazione, evitando di dover sempre scrivere la zona per esteso nel caso in cui i nomi siano molto lunghi. Niente infatti vieta di avere una zona chiamata ufftec.bologna.italia.incipit.biz. Sarebbe però scomodo riscrivere questa stringa di testo ogni volta che si volesse inserire un indirizzo nel DNS. Invece di scrivere per esempio pc1.ufftec.bologna.italia.incipit.biz è sufficiente scrivere pc1 (senza il punto). Il sistema espanderà automaticamente il nome. Le righe seguenti contengono indicazioni importanti ai fini della sincronizzazione del server DNS locale con server DNS esterni. Questo è utile quando sono definite zone che sono in realtà specificate in altri server DNS esterni. In questo caso servono alcune informazioni di servizio, come un numero di serie che venga incrementato a ogni modifica dei record DNS, un tempo di refresh che indichi ogni quanto tempo i DNS devono aggiornarsi, un tempo di retry per i tentativi seguenti in caso di mancata sincronizzazione e un tempo di expire oltre il quale il DNS perde validità se non riesce più a connettersi con il DNS esterno. Subito prima dell’apertura della tonda compare l’indicazione root.localhost. Qui dovrebbe apparire l’indirizzo e-mail del gestore del DNS in una notazione priva di @ (se usato, il simbolo sarebbe interpretato come nome di origine, causando un errore). Al suo posto compare invece un punto. Questo indirizzo rappresenta in realtà root@localhost. Nella riga successiva compare NS che sta per nameserver. Qui è indicato che il DNS si trova sul sistema locale localhost. Di seguito si ha la specifica A che sta per Address. Questa è un’associazione nome/indirizzo che segnala che localhost (abbreviato come @) è presente all’indirizzo 127.0.0.1. In ogni riga di specifica compare IN, una convenzione sintattica che deve essere rispettata.

Esempio pratico Le configurazioni esaminate fin qui sono estremamente generiche e regolano semplicemente il funzionamento del proprio sistema Linux dopo un’installazione del tutto standard. Per servire la rete locale è necessario specificare i nomi dei computer, i relativi indirizzi e creare una zona di pertinenza. Per fare questo si deve andare nel file di configurazione generale named.conf e inserire una nuova zona:

Listato 4.3

zone "incipit.biz" { type master; file "incipit.biz.zone"; };

In Ubuntu si consiglia di inserire la zona nel file named.conf.local. In questo caso si sta specificando che esiste una nuova zona denominata incipit.biz dentro il file incipit.biz.zone. Il tipo è definito master perché tutte le informazioni sulla zona sono presenti in maniera esaustiva dentro il file incipit.biz.zone. Si sta in pratica affermando che questo DNS ha la piena autorità sulla zona. In alternativa esiste anche il tipo slave. In tal caso si afferma che la zona è specificata in un altro DNS e che il sistema locale deve trarre tutte le informazioni sulla zona da un preciso DNS esterno. Viene così creato un file locale con le informazioni tratte in remoto. Questo file ha una scadenza, dopo la quale sarà nuovamente aggiornato con un nuovo accesso al DNS di riferimento. Questo permette ai due sistemi DNS di rimanere sempre sincronizzati. Il file incipit.biz.zone dovrà contenere riferimenti ai sistemi presenti nel proprio ufficio. Sono pc1, pc2, pc3 e printserver: Listato 4.4

$TTL 86400 @ IN SOA @ info.incipit.biz ( 4 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire 86400 ; ttl ) IN NS 127.0.0.1. pc1 IN A 192.168.100.10 pc2 IN A 192.168.100.11 pc3 IN A 192.168.100.12 printserver IN A 192.168.100.50

Si può notare che il preambolo contiene la forma standard vista in precedenza, ma con l’indirizzo dell’amministratore locale info.incipit.biz (notazione per [email protected]). La specifica NS punta al sistema locale, come nel caso precedente. Poi si hanno una serie di specifiche A (address), una per ogni sistema da registrare. Qui diventa finalmente chiara l’associazione tra i nomi estesi e gli indirizzi IP numerici. Quando un client scriverà per esempio ping pc1 dalla shell dei comandi, il computer interrogherà questo archivio DNS, scandirà la lista delle specifiche A, troverà la riga pc1, otterrà l’indirizzo IP numerico e potrà così eseguire effettivamente la richiesta con un ping a 192.168.100.10. Lo stesso meccanismo accade quanto si visita un qualunque sito web. Quando si digita, per esempio, www.linux.org il proprio computer esamina un archivio DNS che fa riferimento a linux.org e scorre i record A per trovare la voce www. Una volta individuata, legge l’IP corrispondente e lo fornisce al browser per la connessione. La configurazione precedente può essere arricchita con il riferimento per il server Linux locale e il gateway Internet:

server IN A 192.168.100.1 gateway IN A 192.168.100.5

A questo punto i file di configurazione risultano creati. Per renderli operativi bisogna attivare il demone DNS o procedere al riavvio nel caso il servizio sia già in funzione. Per attivare il demone, digitare il seguente comando: /etc/init.d/named start

Se il demone è stato lanciato in fase di boot bisogna semplicemente riavviare il servizio per attivare le modifiche appena inserite. Su CentOS: /etc/init.d/named restart

A questo punto non bisogna dimenticare di fare in modo che il servizio DNS sia attivato automaticamente all’avvio del sistema. In alcune distribuzioni, lo script di avvio ha un nome differente. Per avviare Bind su una distribuzione Ubuntu si utilizza questa sequenza: /etc/init.d/bind9 start

Il DNS è pronto e attivo. Ora occorre configurare il server locale per fare in modo che usi il DNS interno appena creato. Prima di tutto bisogna tornare nella directory /etc e aprire il file host.conf. Questo file specifica l’ordine con cui viene eseguita la risoluzione dei nomi. Di default si ha la configurazione seguente: order hosts, bind

Questo significa che viene prima esaminato il file hosts, presente anch’esso dentro /etc e poi il sistema DNS. Il file hosts è un elenco che associa i nomi estesi agli indirizzi IP ed è molto simile al DNS, ma estremamente più semplice e privo della strutturazione gerarchica del DNS. Di default contiene la riga seguente: 127.0.0.1 localhost.localdomain localhost

Si tratta dell’associazione dell’indirizzo di loopback locale al nome localhost, un alias comunemente usato dalle applicazioni Linux per fare riferimento al sistema locale. Un ping a localhost equivale a un ping a 127.0.0.1. La configurazione di default di host.conf e di hosts può essere lasciata inalterata anche se alcuni utenti preferiscono invertire l’ordine di ricerca in host.conf per avere prima l’interrogazione sul DNS e poi quella nel file hosts: order bind, hosts

Per concludere, bisogna controllare un ulteriore file di sistema: /etc/resolv.conf. Questo file contiene gli indirizzi dei server DNS che il computer locale deve interrogare per risolvere i nomi. Bisogna semplicemente specificare che si vuole usare il DNS appena configurato: nameserver 127.0.0.1

Questa operazione attiva il DNS per le operazioni locali. Un ping dalla shell di Linux a pc2.incipit.biz sarebbe correttamente risolto nell’indirizzo 192.168.100.11.

Sussiste però un problema. Sono stati specificati unicamente i sistemi locali. Se si tentasse di accedere con il browser a qualunque sito esterno o a qualunque altro tipo di servizio si verificherebbe un errore. Il DNS non contiene infatti riferimenti al mondo esterno. Il problema può essere risolto in maniera molto rapida aggiungendo nuove righe in resolv.conf con gli indirizzi dei DNS del proprio provider o altri DNS pubblici, come quelli di Google: nameserver 127.0.0.1 nameserver 8.8.8.8 nameserver 8.8.4.4

Se la ricerca sul primo DNS fallisce, viene interrogato il server DNS seguente e poi quelli successivi fino a quando il nome viene risolto o quando l’elenco dei DNS viene visitato completamente senza esito.

Gabbie chroot Potrebbe succedere che le impostazioni sul DNS non abbiano effetto e qualunque operazione porti a errori o a comportamenti del tutto inaspettati. Questo avviene se nella propria distribuzione il DNS è implementato all’interno di quella che si definisce una gabbia chroot. Si tratta in sostanza di un file system in piccola scala, isolato dal resto del sistema per motivi di sicurezza. Se un utente malintenzionato riuscisse a violare il DNS non potrebbe alterare il sistema, in quanto si troverebbe confinato nella gabbia chroot, un’area con un numero estremamente limitato di comandi critici. Se il DNS funziona all’interno di una gabbia chroot, significa che il file di configurazione principale non è localizzato in /etc e le specifiche di zona non sono in /var/named. La struttura operativa è in realtà altrove. Fedora Core e CentOS, per esempio, creano una gabbia chroot per Bind e qualunque configurazione sui file in /etc non porterebbe ad alcun risultato. Bisogna piuttosto accedere a /var/named/chroot (la gabbia chroot) e utilizzare il file named.conf presente in /etc. È importante verificare questo aspetto per non perdere ore cercando di configurare i file sbagliati. Dentro una gabbia chroot, i percorsi devono essere indicati come se si lavorasse dentro le directory “ordinarie” del sistema. Per esempio, il file di zona incipit.biz.zone che viene creato dentro /var/named/chroot/etc, sarà specificato nel file di configurazione di Bind con questo formato: zone "incipit.biz" { type master; file "/etc/incipit.biz.zone"; allow-update { key SERVERKEY; }; };

Come si può notare, viene indicato /etc/incipit.biz.zone e non l’intero percorso.

Configurazione dei client Windows Per configurare i client Windows occorre andare in Pannello di Controllo > Rete e aprire la configurazione del protocollo TCP/IP. In basso, nella configurazione DNS, bisogna specificare l’indirizzo del sistema Linux, 192.168.100.4. Come indirizzi secondari bisogna invece mettere i DNS del proprio provider. In questo modo si ha il proprio DNS per gli indirizzi interni e i DNS pubblici del provider per tutti gli altri indirizzi Internet (Figura 4.4).

Figura 4.4 Configurazione di rete in W indow s XP.

Per verificare che stia tutto funzionando a dovere si può aprire una shell dei comandi andando in Start > Esegui e digitando cmd seguito da Invio.Si provi a digitare il comando nslookup e a premere nuovamente Invio. Il programma dovrebbe partire indicando il server DNS di riferimento interno 192.168.100.4 (Figura 4.5).

Figura 4.5 Output di nslookup durante i test sul DNS locale.

Digitando i nomi estesi delle macchine interne si dovrebbe ottenere automaticamente l’indirizzo. Scrivendo per esempio pc2 si dovrebbe ottenere come risposta 192.168.100.11. Inserendo invece un indirizzo esterno come www.apogeonline.com si dovrebbe ottenere il corretto indirizzo IP prelevato dal sistema DNS del proprio provider. Un punto chiave da tenere in considerazione è il suffisso che viene aggiunto ai nomi. I nomi Internet sono infatti composti da un host e da un dominio. pc2 è, per esempio, il nome dell’host, mentre incipit.biz è il dominio. Windows XP e 7 aggiungono automaticamente il suffisso ai nomi digitati. Digitando pc2 in nslookup dovrebbe venire automaticamente aggiunto il dominio per completare in maniera corretta l’indirizzo. Per verificare il suffisso di default bisogna trascinare il mouse sopra Risorse del computer di Windows XP, fare clic sul tasto destro del mouse, scegliere dal menu la voce Proprietà e selezionare la scheda Nome computer. Nella parte centrale della finestra si trova la voce Dominio, in cui è indicato il suffisso di default. Quest’ultimo dovrà risultare equivalente al nome della zona del DNS, per esempio incipit.biz. Per uscire da nslookup basta digitare exit e poi scrivere nuovamente exit per chiudere la shell di comandi.

Checklist 1. Installare il pacchetto bind dai CD-ROM di installazione del proprio sistema operativo o dal repository on-line. 2. Verificare se il sistema DNS è installato in una gabbia chroot. In caso affermativo, i file di configurazione indicati di seguito saranno memorizzati dentro la gabbia anziché in /etc. 3. Aprire il file named.conf, che si può trovare all’interno della directory /etc oppure in /etc/bind oppure dentro la gabbia chroot.

4. Creare le specifiche di ricerca necessarie per la propria realtà, prevedendo una zona di ricerca diretta e una di ricerca inversa. 5. Creare, all’interno della directory /etc/bind, i file per le zone specificate in named.conf. 6. Riavviare il servizio con il comando /etc/init.d/named restart oppure /etc/init.d/bind9 restart.

7. Aprire il file /etc/host.conf e modificare l’ordine con cui il sistema risolve gli indirizzi, specificando prima bind e poi hosts. 8. Aprire il file /etc/resolv.conf e indicare l’indirizzo IP del DNS appena configurato: è sufficiente l’indirizzo di loopback locale 127.0.0.1. 9. Configurare i client, inserendo l’indirizzo IP del sistema DNS appena creato. Come indirizzi secondari si possono specificare gli indirizzi IP dei DNS del provider.

Capitolo 5

Capitolo 5 - Distribuzione di indirizzi e di parametri di rete con DHCP Nei primi anni Novanta le reti locali si basavano in larga misura su protocolli proprietari o su soluzioni commerciali realizzate appositamente per gli ambienti interni. Nel tempo, però, queste strade chiuse sono state progressivamente abbandonate in favore del TCP/IP, un protocollo aperto, efficiente, veloce e flessibile. Surclassare le visioni tecnologiche “provinciali” è stato un passaggio cruciale nel mondo dell’informatica, anche se la scelta del TCP/IP è stata valutata sproporzionata da alcuni. Questa suite è stata concepita per operare su scala planetaria e risultava quindi curioso confinare il protocollo in una piccola LAN, applicando una sorta di scalabilità “rovesciata”. La visione si è presto dimostrata vincente sul piano tecnico, ma anche su quello commerciale dal momento che non vi erano obblighi di licenze o royalty da versare. La tecnologia era di fatto libera e i maggiori produttori di software abbracciarono progressivamente TCP/IP, compresa Microsoft, che addirittura iniziò a sconsigliare l’utilizzo dei protocolli di rete locale che aveva contribuito a creare e che aveva supportato per anni. Oggi tutte le postazioni connesse in LAN sfruttano TCP/IP e usufruiscono della robustezza di un protocollo con decenni di servizio alle spalle, collaudato su milioni di macchine di ogni tipo e dotazione.

Configurazione di TCP/IP Il TCP/IP non è un protocollo “automatico”. Bisogna piuttosto compiere alcuni passi di configurazione nel sistema locale per renderlo operativo. Per cominciare, ogni macchina deve possedere un indirizzo univoco, ossia un valore numerico espresso nella forma di quattro gruppi di byte separati da un punto. Per essere più espliciti, un indirizzo nella forma nnn.nnn.nnn.nnn, dove ogni nnn è un numero compreso tra 0 e 255. L’indirizzo di per sé non ha significato se non è corredato dalla maschera di sottorete (subnet mask), un valore, sempre nella forma nnn.nnn.nnn.nnn, che permette di suddividere l’intero spazio di indirizzi in reti più piccole, logicamente autonome. Si possono così avere reti con indirizzi IP indipendenti sullo stesso cavo dati Ethernet. Gli indirizzi IP sono rilasciati da un organismo internazionale a operatori di telecomunicazioni, a compagnie che operano nel settore di Internet o ad aziende che necessitano di ampie sottoreti. I provider e gli operatori di telecomunicazioni affittano poi questi indirizzi agli utenti finali secondo politiche commerciali di propria scelta. Riferendosi all’Italia, ci sono molte compagnie che forniscono connessioni ADSL professionali dotate di una sottorete di 8 o 16 IP statici. L’utente si troverà in tal caso una serie di indirizzi contigui associati a un valore di subnet mask. In realtà gli indirizzi utilizzabili sono in numero inferiore, perché il primo e l’ultimo indirizzo della sottorete sono dedicati a funzioni particolari. Il primo è l’indirizzo di rete, una sorta di “nome numerico” per il gruppo di IP assegnati, mentre l’ultimo è l’identificativo di broadcast. Effettuando, per esempio, un ping su questo indirizzo si dovrebbe ottenere una risposta da tutti i nodi attivi della sottorete. Gli indirizzi IP sono di due tipi: pubblici e privati. Ogni server presente in rete, ma anche ogni singola postazione connessa al provider, dispone di un indirizzo pubblico univoco (anche se rilasciato dinamicamente). Nessun’altra macchina presente su Internet in quel momento disporrà dello stesso indirizzo. Si tratta di

un’ovvia necessità di funzionamento. Non sarebbe possibile raggiungere una macchina ben precisa, se gli indirizzi fossero duplicati in luoghi differenti del pianeta. Gli indirizzi IP privati, di cui la Tabella 5.1 elenca i tre gruppi disponibili (tecnicamente chiamati classi), sono invece insiemi di valori che possono essere usati internamente in una rete locale senza la necessità di richiedere un’autorizzazione o di dover acquistare un pacchetto commerciale da un operatore di telecomunicazioni. Questi valori sono totalmente liberi, ma non possono varcare i confini della propria rete locale. Eventuali pacchetti con indirizzi privati inviati su Internet sarebbero automaticamente scartati. Tabella 5.1 Gamma di indirizzi utilizzabili per reti interne.

Classe Indirizzi Classe A Da 10.0.0.0 a 10.255.255.255 Classe B Da 172.16.0.0 a 172.31.255.255 Classe C Da 192.168.0.0 a 192.168.255.255 Indirizzo IP e subnet mask sono due parametri di configurazione che bisogna specificare nel pannello del TCP/IP prima di ottenere un sistema in grado di comunicare. Non sono però gli unici dati da inserire. Bisogna anche specificare l’indirizzo IP del router e del DNS. Se non si specifica l’indirizzo del router, i pacchetti destinati a macchine esterne non sarebbero recapitati: serve infatti l’indicazione dell’IP del dispositivo che esegue l’instradamento verso Internet. Gli indirizzi del DNS sono gli IP dei server che eseguono la traduzione dal nome esteso (per esempio www.incipit.biz) all’indirizzo numerico. Non bisogna mai dimenticare che qualsiasi operazione su Internet può avvenire solo tramite indirizzi numerici. Tutti i nomi estesi devono obbligatoriamente subire una conversione tramite un servizio DNS. Informazioni più dettagliate sul DNS e sui sistemi router possono essere reperite nei Capitoli 4 e 6, dedicati a questi argomenti. Fino a questo momento, la configurazione del TCP/IP consta di quattro parametri ma, a seconda del tipo di rete locale, ci possono essere altre impostazioni fondamentali, per esempio l’indirizzo del server WINS, il nome del dominio e così via (Figura 5.1).

Figura 5.1 Proprietà del protocollo TCP/IP su un client W indow s XP.

Coloro che seguono la gestione dei sistemi in reti locali conoscono bene questi parametri e sanno quanti problemi possono sorgere a seguito dell’erroneo inserimento di questi valori nelle macchine della propria organizzazione. I tecnici sanno anche quanto tempo possa richiedere l’attività di configurazione manuale del TCP/IP in reti con centinaia o migliaia di client. è facile spendere giorni interi in un’attività estremamente ripetitiva, noiosa e soggetta a errori. La questione diventa poi critica se sorge l’esigenza di modificare frequentemente lo schema di indirizzi: altro lavoro per reimpostare i pannelli TCP/IP di tutte le postazioni.

Distribuzione degli indirizzi di rete Esiste un servizio standard in grado di risolvere questo problema e che si occupa della distribuzione automatica degli indirizzi IP e dei parametri di rete. Questo strumento si chiama DHCP (Dynamic Host Configuration Protocol) ed è documentato nell’RFC 1541 (http://www.cse.ohio-state.edu/cgibin/rfc/rfc1541.html). DHCP è un servizio che viene installato su un server e configurato dall’amministratore per contenere i parametri di rete necessari al funzionamento dei client. All’interno della configurazione va inserita innanzitutto la gamma di IP che la rete interna dovrà usare. Se si hanno, per esempio, 50 client si può creare un gruppo di indirizzi che inizia da 192.168.0.50 e termina a 192.168.0.100 con maschera di sottorete 255.255.255.0. Gli indirizzi dei PC non dovranno così essere impostati manualmente, perché arriveranno automaticamente dal server DHCP (Figura 5.2).

Figura 5.2 La configurazione automatica della rete su W indow s XP si attiva impostando entrambi i campi in automatico.

Durante l’avvio del sistema operativo, sarà effettuata una richiesta da parte del client verso il server DHCP. Questo replicherà fornendo un indirizzo IP non ancora utilizzato, che la macchina locale imposterà automaticamente nella propria configurazione di rete. Sfruttando questo meccanismo automatico è possibile configurare tutti i PC per ottenere gli indirizzi tramite DHCP, evitando così di dover impostare (o reimpostare) questo dato su ogni macchina. Basterà inserire le opzioni sul server e il problema di gestione della rete sarà notevolmente semplificato. DHCP non distribuisce solamente indirizzi IP, ma una moltitudine di possibili opzioni di rete, tra cui l’indirizzo del gateway di default, gli indirizzi DNS, il nome di dominio locale, l’indirizzo WINS e così via. Tutta la gestione della rete locale può in questo modo essere automatizzata. L’elenco può comprendere decine di opzioni, ma naturalmente non tutte devono essere usate. Il servizio è infatti nato per servire ambienti molti differenti tra loro e per questo sono presenti molte opzioni specifiche o dedicate ad ambienti particolari. In un ambito di rete aziendale standard, l’elenco si riduce a pochi elementi utili. Per comprendere l’utilità di DHCP si prenderà in considerazione una rete composta da cinquanta client basati su sistemi Windows XP Professional e Windows 7 Professional. È presente un file server basato su Linux e un accesso a Internet ADSL tramite un router. Sono inoltre connessi tre print server (Figura 5.3).

Figura 5.3 Schema della LAN dell’esempio esposto.

Il server, il router e i print server vengono configurati dal sistemista interno con indirizzi IP impostati manualmente, mentre le cinquanta postazioni sono tutte configurate per ricevere gli indirizzi e le opzioni di rete tramite il servizio DHCP. Per quale motivo alcuni sistemi continuano ad avere impostazioni di rete manuali, pur esistendo un servizio DHCP? Si sconsiglia di configurare automaticamente il pannello di rete dei sistemi che svolgono servizi critici per la rete locale come appunto server, router e print server. L’assegnazione degli indirizzi da parte di DHCP non è infatti vincolante. Una macchina ottiene un indirizzo IP dal DHCP e lo possiede in esclusiva solo per un periodo di tempo ben determinato, per esempio un mese. Scaduto questo tempo, si attiva una procedura di rinnovo dell’indirizzo per il client in oggetto. A seguito del rinnovo si potrebbe anche avere lo stesso IP, ma non ci sono garanzie in merito. L’indirizzo usato fino a quel momento potrebbe infatti essere assegnato a un’altra macchina. Non si hanno perciò indirizzi riservati e l’IP smette di essere un valore identificativo per una specifica macchina. Questo non è un problema per i client, perché non è quasi mai necessario conoscere l’indirizzo IP delle postazioni di lavoro e generalmente non sussiste la necessità di collegarsi alle macchine dei colleghi. Diversa è invece la situazione per un router, che deve essere individuato in maniera certa e univoca, pena l’impossibilità di comunicare con l’esterno. Questo elemento deve essere mappato manualmente con un indirizzo che non vari nel tempo. Lo stesso vale per le stampanti di rete, che probabilmente non sarebbero più accessibili se avessero indirizzi locali dinamici gestiti da DHCP, e per il server. Riassumendo, il DHCP viene utilizzato per ridurre il tempo di configurazione di rete sui client. Gli elementi critici di infrastruttura come server, NAS, switch gestiti, router, stampanti di rete e così via devono però avere indirizzi statici ben documentati.

Attivazione del servizio L’implementazione più utilizzata di DHCP su Linux è dhcpd di Internet Systems Consortium Inc. (http://www.isc.org/sw/dhcp/).

Il prodotto è integrato come pacchetto in gran parte delle distribuzioni disponibili e per verificare la sua presenza si può digitare dhcpd -t nel prompt dei comandi di CentOS oppure dhcpd3 -t su Ubuntu. Se l’esecuzione restituisce un errore di comando non trovato significa che il pacchetto non è disponibile. In tal caso si deve procedere all’installazione con gli strumenti standard messi a disposizione dalla distribuzione in uso. Su Ubuntu, il pacchetto si chiama dhcp3-server mentre su CentOS si chiama dhcpd. A questo punto bisogna verificare che la porta 67 UDP non sia bloccata dal firewall. Su questa porta arrivano infatti le richieste da parte dei client. È fondamentale anche controllare che il demone DHCP venga lanciato in fase di avvio del sistema. Si può quindi procedere alla fase di setup. Tutta la configurazione è contenuta all’interno del file dhcpd.conf presente dentro /etc su CentOS oppure dentro /etc/dhcpd3 su Ubuntu. In alcune distribuzioni viene fornito un file di configurazione di esempio. In ogni caso si consiglia di crearne uno nuovo. Il file è composto da comandi generali e da specifiche di sottorete. Una specifica di sottorete è semplicemente una rete che si vuole servire con DHCP. Le reti DHCP iniziano con la parola chiave subnet, seguita dall’indirizzo della rete e dalla sua maschera. Viene poi aperta una parentesi graffa e al suo interno sono presenti una o più opzioni separate dal simbolo di punto e virgola (;). Si conclude poi la sezione con la parentesi graffa chiusa. Questa è la struttura generale: Listato 5.1

comando generale 1; comando generale 2; comando generale n; subnet nnn.nnn.nnn.nnn netmask nnn.nnn.nnn.nnn { comando subnet 1; comando subnet 2; comando subnet n; }

I comandi inseriti dentro una specifica di sottorete agiranno solamente sulla sottorete in oggetto. È possibile però inserire gli stessi comandi nella sezione generale e renderli validi per tutte le sottoreti eventualmente definite. I comandi sono di due tipi: specifici di dhcpd e standard del protocollo DHCP. Questi ultimi iniziano sempre con la parola chiave option. Il file di configurazione viene letto all’avvio del demone e ricaricato a cadenza regolare. Ogni volta che si modifica la configurazione, conviene verificare che la nuova impostazione sia corretta dal punto di vista sintattico. Questo può essere fatto impartendo il comando dhcpd -t su Centos o dhcpd3 -t su Ubuntu. Il file verrà letto e saranno segnalati gli eventuali errori presenti. Se non ci sono problemi, si può procedere a riavviare il servizio. Su CentOS: /etc/init.d/dhcpd restart

Mentre su Ubuntu: /etc/init.d/dhcp3-server restart

Configurazione del servizio

Per comprendere i rudimenti della configurazione di dhcpd si consiglia di creare un nuovo file dhcpd.conf e di applicare la configurazione seguente: Listato 5.2

ddns-update-style none; subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.100 192.168.0.200; option subnet-mask 255.255.255.0; default-lease-time 604800; max-lease-time 2592000; option broadcast-address 192.168.0.255; option routers 192.168.0.1; option domain-name-servers 8.8.8.8, 8.8.4.4; option domain-name "incipit.biz"; option netbios-name-servers 192.168.0.20; option netbios-node-type 8; option ip-forwarding off; }

La prima riga contiene il comando generale ddns-update-style, richiesto dalle ultime versioni di dhcpd. In questa fase bisogna limitarsi a copiare questa riga di configurazione. Si procederà alla sua trattazione più avanti in questo capitolo. Viene di seguito creata una sottorete 192.168.0.0 con maschera 255.255.255.0. In pratica si sta indicando che la rete locale ha indirizzi compresi tra 192.168.0.1 e 192.168.0.254. Il primo comando del blocco, range, è il più importante. Specifica infatti la gamma di indirizzi IP che saranno assegnati in automatico ai client di rete. In questo caso si tratta di indirizzi compresi tra 192.168.0.100 e 192.168.0.200. Pur avendo solo cinquanta macchine in rete è bene prevedere una sottorete più ampia, per riservare un po’ di margine. Questo evita di dover mettere mano alle configurazioni nel caso in cui il numero delle macchine interne aumenti oltre la capacità configurata. Si può abbondare con serenità, in quanto gli indirizzi sono assegnati in maniera efficiente: il sistema è sempre a conoscenza di quali sono gli indirizzi liberi e quali invece i valori impegnati. Quindi, non si avranno sprechi. Seguono la subnet mask dei client e due comandi per la specifica dei tempi di lease. Come già accennato, gli indirizzi forniti dal server DHCP non sono riservati in maniera definitiva alle macchine, ma vengono dati in prestito (lease) per un periodo di tempo specificato dall’amministratore in queste due righe. Il tempo è specificato in secondi e significa in pratica che l’IP è concesso per un periodo di sette giorni (default-lease-time) con un tempo massimo di un mese (max-lease-time). Questi tempi sono relativamente bassi e significa che dopo sette giorni gli indirizzi saranno rinegoziati. è una scelta valida soprattutto se la rete accoglie sistemi portatili, magari di utenti di passaggio. Un basso tempo di lease garantisce che gli IP prestati a queste macchine saranno nuovamente disponibili dopo poco tempo, liberando l’archivio dalle assegnazioni per macchine che, in realtà, non accederanno più alla propria rete. Se vengono prevalentemente impiegate postazioni desktop, è invece ragionevole dilatare questi tempi. L’opzione seguente, option broadcast-address, serve per specificare l’indirizzo di broadcast della rete. Segue l’opzione routers, in cui si specifica il valore del gateway predefinito per entrare in Internet, in pratica l’indirizzo del router interno. In domain-name-servers vengono indicati invece gli indirizzi dei DNS pubblici separati da un virgola.

L’opzione domain-name contiene una stringa con il nome DNS della rete locale, in questo caso incipit.biz. Questo dominio sarà aggiunto a tutte le richieste di rete incomplete. Se si accede alla console di PC7 e si esegue un ping su PC16, la richiesta sarà tradotta in pc16.incipit.biz e passata al comando ping. Non bisogna dimenticare che le recenti versioni di Windows lavorano in rete utilizzando un sistema DNS e le relative convenzioni. Ogni computer è quindi dotato di un nome di host, per esempio PC16, e di un nome di rete, come appunto incipit.biz. L’opzione netbios-name-servers contiene gli indirizzi IP dei server WINS presenti sulla LAN. WINS è un altro meccanismo utilizzato per tradurre i nomi estesi in valori numerici. Questo protocollo è però dedicato alle reti locali basate su Windows e funziona in maniera dinamica (a differenza invece del DNS che è un archivio statico aggiornato manualmente da un amministratore di sistema). Se si dispone di una rete moderna, composta da client Windows 2000 Professional, Windows XP Professional o 7, legati a un sistema Windows Server, non è necessario utilizzare questo sistema. Si può quindi omettere questa riga di configurazione. Un DNS può infatti svolgere meglio tutte le funzionalità di risoluzione dei nomi. Se invece si dispone di sistemi più datati, si consiglia di utilizzare WINS tramite un server Windows o un sistema Linux con Samba (si veda il Capitolo 2). Bisogna ricordarsi in tal caso di inserire l’opzione netbios-name-servers sul DHCP. La riga netbios-node-type contiene il valore che rappresenta la sequenza di operazioni che porterà alla risoluzione dei nomi estesi in una rete Windows. Il parametro è del tutto inutile se non si hanno macchine Windows. La Tabella 5.2 descrive le modalità di risoluzione dei nomi nelle reti Windows. Tabella 5.2 Modalità di risoluzione dei nomi nelle reti NetBIOS.

B-node (broadcast node) con valore DHCP: 0x1

La registrazione e la risoluzione dei nomi avviene attraverso un broadcast sulla rete locale. Si tratta di una modalità semplice da mettere in atto, ma che aumenta la quantità di traffico presente sulla LAN. Nell’implementazione Microsoft viene eseguito un controllo preventivo sulla cache di LMHOSTS prima di eseguire il broadcast.

P-node (peer to peer node) con valore DHCP: 0x2

La risoluzione avviene unicamente cercando un sistema che contiene gli elenchi delle macchine attive, per esempio un server WINS. Non vengono in alcun modo usati broadcast. Se non è disponibile il sistema WINS o non si conosce il suo indirizzo, non è possibile ottenere alcun servizio di risoluzione.

M-node (mixed Si tratta di una combinazione del B-Node e del P-Node, in cui vengono usati i broadcast per la node) con ricerca, oppure un server di risoluzione nel caso sia presente in rete. È una modalità utile, ma valore che comporta traffico per via dei broadcast DHCP: 0x4 H-node (hybrid node) con valore DHCP: 0x8

In questa modalità viene eseguita la ricerca di un sistema per la risoluzione dei nomi come un server DNS oppure un sistema WINS, anche in sequenza. Viene eseguita una lettura anche del file LMHOSTS. In questa modalità il broadcast è considerata l’ultima risorsa. H-node è certamente il metodo migliore con cui configurare una rete locale, in quanto riduce il traffico dei broadcast al minimo indispensabile. Microsoft consiglia la modalità H-node nelle reti Windows

L’ultima opzione è inserita come misura di sicurezza: disattiva, infatti, la possibilità che pacchetti di dati possano transitare da una scheda di rete verso un’altra nelle macchine con più connessioni attive. Una volta inserite queste regole, si può riavviare il servizio. Da questo momento, il server potrà distribuire indirizzi IP e parametri di rete a tutte le macchine che ne faranno richiesta. Tutti i lease saranno annotati nel file dhcpd.leases presente in /var/lib/dhcpd su CentOS o in /var/lib/dhcp3 su Ubuntu. Qui di seguito viene riportato l’esempio di richiesta indirizzo da parte di una postazione Ubuntu: Listato 5.3

# All times in this file are in UTC (GMT), not your local timezone. This is # not a bug, so please don't ask about it. There is no portable way to # store leases in the local timezone, so please don't request this as a # feature. If this is inconvenient or confusing to you, we sincerely # apologize. Seriously, though - don't ask. # The format of this file is documented in the dhcpd.leases(5) manual page. # This lease file was written by isc-dhcp-V3.0.5-RedHat lease 192.168.0.200 { starts 2 2010/08/03 20:47:58; ends 2 2010/08/10 20:47:58; tstp 2 2010/08/10 20:47:58; binding state active; next binding state free; hardware ethernet 00:0c:29:2a:c3:46; client-hostname "Ubuntu"; }

L’attività del demone sarà registrata su /var/log/messages. Per avere una registrazione molto più dettagliata, magari su un file a parte, è possibile specificare un’opzione d’avvio. Su CentOS si deve aprire /etc/sysconfig/dhcpd, mentre su Ubuntu bisogna fare riferimento a /etc/default/dhcp3-server: # Command line options here DHCPDARGS="eth0 -tf /var/log/dhcpd.log"

L’opzione per il log esteso è -tf, seguito dal nome del file per la registrazione. Si può notare che è presente anche l’indicazione di un’interfaccia di rete. Questa si rivela necessaria quando nel sistema ci sono più schede di rete. In tali situazioni bisogna indicare su quale scheda deve rimanere in ascolto il demone. In questo specifico caso, si tratta di eth0. La scheda eth1 potrebbe, per esempio, essere connessa direttamente a Internet attraverso un modem ADSL. Sarebbe sbagliato cercare di servire eventuali richieste in arrivo da questa scheda di rete.

Assegnazione statica degli indirizzi Pur avendo un servizio di distribuzione degli indirizzi, potrebbe risultare utile riservare in maniera statica un indirizzo a una o più macchine particolari. Di seguito è illustrato come realizzare questo obiettivo estendendo la configurazione precedente: Listato 5.4

ddns-update-style none;

subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.100 192.168.0.200; option subnet-mask 255.255.255.0; default-lease-time 604800; max-lease-time 2592000; option broadcast-address 192.168.0.255; option routers 192.168.0.1; option domain-name-servers 8.8.8.8, 8.8.4.4; option domain-name "incipit.biz"; option netbios-name-servers 192.168.0.20; option netbios-node-type 8; option ip-forwarding off; } host prod15 { hardware ethernet 00:08:0d:60:16:33; fixed-address 192.168.0.170; }

Il portatile prod15 sarà assegnato in maniera statica all’indirizzo 192.168.0.170 dal DHCP. In che modo però il servizio riesce a capire quale è effettivamente il portatile giusto, evitando di assegnare per errore il valore statico a qualche altra macchina? La scelta viene eseguita in base all’indirizzo MAC presente sulla scheda di rete. Questo valore è inserito di fabbrica e al mondo non esistono due schede di rete con lo stesso MAC. Un organismo internazionale provvede a distribuire questi valori e a coordinare i produttori di schede di rete in modo che non vi siano duplicati. Quando si crea una regola di assegnamento statica, bisogna quindi estrarre il valore MAC della macchina e inserirlo nella riga hardware ethernet nel file di configurazione. Per ottenere questo valore, si può andare nella shell dei comandi della macchina in oggetto, digitare arp a e cercare il valore MAC in corrispondenza dell’IP del computer. Sarà visualizzato l’elenco dei sistemi con cui si hanno avuto recenti relazioni di rete, come in questo esempio su Windows: Listato 5.5

C:\>arp -a Interfaccia: 192.168.0.10 --- 0x10004 Indirizzo Internet Indirizzo fisico Tipo 192.168.0.170 00:08:0d:60:16:33 dinamico

In precedenza si è visto che i log generati da dhcp contengono molti dati riguardanti i lease registrati. Tra le varie informazioni disponibili vi sono anche i MAC address delle schede cui è stato assegnato un indirizzo IP dinamico. È possibile quindi, anziché usare arp, recuperare tutte le informazioni necessarie dai log e creare una configurazione statica per i computer della propria rete.

Aggiornamenti dinamici Il servizio DNS, nella sua accezione classica, è un archivio statico che associa nomi estesi a indirizzi IP. Tutta la manutenzione e l’aggiornamento dei record avviene manualmente per opera dell’amministratore. Questa persona inserisce diligentemente gli IP statici dei client e dei server, digitando il loro nome esteso. Se si usa un sistema DHCP, diventa però impossibile impiegare il DNS, in quanto gli indirizzi delle

macchine varieranno nel tempo. Questo può creare problemi nelle reti con sistemi operativi Windows 2000 o superiori, perché il DNS è il meccanismo principale di risoluzione dei nomi. L’assenza di questo elemento può rallentare parecchio le operazioni in rete, per via di un maggior tempo di risoluzione degli IP a partire dal nome. Per gestire queste condizioni esiste un’estensione del protocollo che permette l’aggiornamento dell’archivio DNS da parte di un client generico (RFC 2136). Questo sistema generico potrebbe, per esempio, essere un demone DHCP in grado di aggiornare il DNS dopo aver erogato un indirizzo IP a un host della LAN. Si tratta di una notevole caratteristica tecnica, spesso non presente nei server DHCP concorrenti. Il demone dhcpd esaminato in questo capitolo può operare sia in maniera classica, sia in modalità dinamica, aggiornando un DNS che aderisca alle specifiche descritte nella RFC 2136. Nel primo caso, ossia se non si intende aggiornare il DNS, si deve inserire la riga seguente in dhcpd.conf: ddns-update-style none;

Se invece si intende aggiornare il sistema DNS interno, si utilizza la seguente opzione: ddns-update-style interim;

Esiste anche una terza modalità, definita ad hoc, ma non è più valida e va ignorata. La modalità interim possiede questo nome in quanto non sono ancora stati standardizzati completamente i protocolli di interazione tra DHCP e il DNS dinamico. Il demone dhcpd usa quindi una serie di specifiche che aderiscono alle bozze di standard, sufficientemente complete, ma non ancora definitive. Lavorando in ambito Linux, si evitano molti problemi di compatibilità, perché il demone dhcpd e il sistema DNS Bind sono sponsorizzati dalla stessa organizzazione, che ha armonizzato i due pacchetti rendendoli in grado di interagire tra loro e di gestire l’aggiornamento dinamico.

Sicurezza prima di tutto L’aggiornamento dinamico di un DNS comporta alcuni problemi di sicurezza. Non si può permettere a qualunque client, compreso il server DHCP, di inoltrare aggiornamenti liberamente. Qualcuno potrebbe infatti usare questa opportunità per corrompere l’archivio DNS o alterarlo ai fini di attacchi più complessi. Il problema si risolve imponendo che tutte le richieste di aggiornamento verso il DNS dinamico siano possibili solo tramite una chiave segreta comune, usata per cifrare le richieste. Se un client tenta di aggiornare il DNS tramite una richiesta non firmata con questa chiave, ottiene un messaggio di errore. Questa chiave è il fulcro della sicurezza del DNS dinamico e come tale va custodita con estrema cura. La sua creazione avviene con uno strumento presente nel pacchetto di Bind, denominato dnssec-keygen, che è in grado di generare chiavi sfruttando diversi algoritmi, quali RSA, DSA, DH e HMACMD5, elencati nella tabella che segue. La chiave può essere generata secondo lunghezze differenti, dipendenti dal tipo di algoritmo scelto (Tabella 5.3). Bind supporta attualmente solo l’algoritmo HMAC-MD5 e per questo motivo la documentazione ufficiale consiglia di generare la chiave usando la sintassi seguente: dnssec-keygen -a HMAC-MD5 -b 128 -n USER SERVERKEY Tabella 5.3

Algoritmo

Nome in dnssec-keygen (opzione -a)

Lunghezza chiave supportata (opzione -b)

Rivest-Shamir-Adleman

RSAMD5

Comprese tra 512 e 2048 bit

Diffie-Hellman

DH

Comprese tra 128 e 4096 bit

Digital Signature Algorithm

DSA

Comprese tra 512 e 1024 bit

Hashed Message Authentication Code-MD5

HMAC-MD5

Comprese tra 1 e 512 bit

Il parametro -a indica il tipo di protocollo, mentre -b specifica la lunghezza della chiave. Il parametro -n USER specifica che la chiave è legata a un utente e non a una zona specifica del DNS o a un host (maggiori informazioni sono ottenibili con il comando man dnssec-keygen). La dicitura finale (in questo caso SERVERKEY) è un’etichetta libera usata come base per i nomi dei due file che sono generati: Kserverkey.+157+58192.key Kserverkey.+157+58192.private

I contenuti dei file sono rispettivamente: SERVERKEY. IN KEY 0 2 157 v8cI2NZImPk8rUCher+www==

e: Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: v8cI2NZImPk8rUCher+www==

A questo punto si deve andare nel file named.conf presente in /etc o in /etc/bind e aggiungere tali specifiche: Listato 5.6

key SERVERKEY { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret "v8cI2NZImPk8rUCher+www=="; }; zone "incipit.biz" { type master; file "incipit.biz.zone"; allow-update { key SERVERKEY; }; };

Rispetto a quanto visto nel capitolo relativo al DNS, è stata aggiunta una specifica key con i relativi dettagli e si è aggiunta la direttiva allow-update nella zona incipit.biz. La direttiva key deve essere seguita dall’etichetta usata nella generazione delle chiavi. Il primo campo, algorithm, va copiato letteralmente e indica il tipo di algoritmo usato per la chiave. In secret deve essere copiata la chiave generata precedentemente. Bisogna ovviamente copiare la sequenza in maniera letterale e racchiuderla tra apici. Il parametro allow-update, dentro la direttiva zone, indica che la zona è di tipo dinamico e che gli aggiornamenti possono avvenire solo se le richieste sono firmate con la chiave SERVERKEY. Nel caso sia presente una zona inversa per gestire incipit.biz o altre zone da aggiornare

dinamicamente, bisogna aggiungere la stessa specifica allow-update. Il file di zona incipit.biz.zone non dovrà essere modificato manualmente, in quanto Bind provvederà agli aggiornamenti dinamici della zona in base alle informazioni fornite dai client. Eventuali modifiche manuali potrebbero essere scartate. L’unico modo certo per modificare la zona è tramite un client di aggiornamento del DNS dinamico, come per esempio dhcpd o il software di rete dei sistemi operativi client. Ogni zona dinamica è corredata da un file binario avente lo stesso nome della zona, ma con estensione .jnl (per esempio incipit.biz.zone.jnl). Questo file è gestito direttamente da Bind e non deve essere cancellato o alterato. È fondamentale che Bind abbia i diritti di scrittura sulle directory delle configurazioni, altrimenti non sarà in grado di generare e gestire i file .jnl. In questo modo non si avrà un sistema di gestione dinamico del DNS funzionante. Per verificare questo aspetto si deve visionare il file di log /var/log/messages e controllare che, nel punto dove è registrato l’avvio del demone, non compaia la seguente riga: Aug 8 02:36:21 vCentos named[7017]: the working directory is not writable

Questa riga evidenzia un problema, che va risolto immediatamente, assegnando i diritti di scrittura corretti alla directory di lavoro di Bind. Si deve poi rilanciare il demone e verificare nei log che la segnalazione non compaia più. Si deve anche controllare l’eventuale presenza di un errore analogo: Aug 8 02:11:29 vCentos named[5403]: /etc/incipit.biz.zone.jnl: create: permission denied

Anche questo messaggio indica un problema di diritti di scrittura nel tentativo di creare il file binario per la gestione dinamica del dominio incipit.biz. Il log è uno strumento di analisi molto importante. È possibile ottenere log dettagliati degli aggiornamenti dinamici sul DNS, aggiungendo questi comandi nel file di configurazione di Bind: Listato 5.7

logging { channel update_debug { file "/var/log/update-debug.log"; severity debug 3; print-category yes; print-severity yes; print-time yes; }; channel security_info { file "/var/log/named-auth.info"; severity info; print-category yes; print-severity yes; print-time yes; }; category update { update_debug; }; category security { security_info; }; };

I file update-debug.log e named-auth.info andrebbero creati manualmente prima di avviare il

servizio (per farlo si può usare il comando touch seguito dal nome del file che si vuole creare). Si può salvare la configurazione e riavviare il servizio DNS (/etc/init.d/named restart su CentOS oppure /etc/init.d/bind9 restart su Ubuntu) in modo che utilizzi la nuova configurazione. A questo punto, l’attenzione deve essere concentrata sul file dhcpd.conf. Per cominciare bisogna aggiungere in testa la direttiva per la modalità di aggiornamento dinamico del DNS: ddns-update-style interim;

Si deve anche inserire l’indicazione della chiave cifrata comune, come nel caso del DNS: Listato 5.8

key SERVERKEY { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret v8cI2NZImPk8rUCher+www==; };

Infine bisogna comunicare a dhcpd l’indirizzo IP dove si trova il server DNS dinamico da aggiornare: Listato 5.9

zone incipit.biz. { primary 127.0.0.1; key SERVERKEY; }

Bisogna tenere in considerazione il fatto che in fondo a incipit.biz è presente un punto. Si tratta di una scelta sintattica per conformarsi allo stile del DNS. La direttiva primary indica l’indirizzo IP del DNS da aggiornare. Questo si trova sullo stesso server dov’è in esecuzione il DHCP e quindi si può semplicemente scrivere l’indirizzo del localhost (127.0.0.1). Di seguito è presente la direttiva key, che si riferisce al blocco SERVERKEY indicato più in alto. Si consiglia di aggiungere anche questo parametri generali: allow client-updates; ddns-updates on; ddns-domainname "incipit.biz";

I primi due parametri, attivi comunque per default, permettono gli aggiornamenti dinamici da parte dei client. Il terzo comando specifica quale dominio sarà appeso ai nomi dei client che richiedono un aggiornamento dinamico. La configurazione è conclusa. Si può salvare, riavviare dhcpd e cominciare a usufruire delle funzionalità dinamiche. Le transazioni e i messaggi d’errore potranno essere osservati nel file di log /var/log/messages. NOTA

Potrebbe succedere che le impostazioni sul DNS non abbiano effetto e qualunque operazione porti a errori o a comportamenti del tutto inaspettati. Si invita a tal proposito a consultare il paragrafo "Gabbie chroot" nel Capitolo 4.

Configurazione dei client Conclusa la parte di configurazione server si può cominciare a lavorare sui client Windows. Su Windows XP si deve portare il mouse sopra Risorse di rete, fare clic con il tasto destro del mouse e scegliere Proprietà. Qui bisogna selezionare l’icona che rappresenta la connessione Ethernet, fare nuovamente clic con il tasto destro e scegliere Proprietà. Infine occorre eseguire un doppio clic su Protocollo Internet (TCP/IP). Nella finestra di dialogo si deve mettere il segno di spunta su Ottieni automaticamente un indirizzo IP e su Ottieni indirizzo server DNS automaticamente. Poi si deve fare clic sul pulsante Avanzate e selezionare la scheda DNS. Bisogna sincerarsi che sia disattivata la casella di selezione Registra nel DNS gli indirizzi di questa connessione (Figura 5.4). Non deve essere infatti Windows XP o Windows 7 ad aggiornare il DNS Dinamico sul server Linux, bensì il servizio DHCP.

Figura 5.4 Configurazione dei parametri DNS in W indow s XP.

Sul lato client è possibile forzare in qualsiasi momento l’aggiornamento degli indirizzi dal server DHCP. Bisogna andare nella shell di comandi di Windows e digitare: ipconfig /release

Grazie a tale operazione verrà annullata la configurazione corrente. A questo punto si può impartire:

ipconfig /renew

Il comando inoltrerà la richiesta al DHCP, caricando la nuova configurazione. Per controllare se la configurazione è corretta, si può invece usare il comando: ipconfig /all

Per verificare l’attività degli aggiornamenti dinamici si può esaminare il file di log /var/log/messages. Al suo interno dovrebbero essere visibili, in fondo, tutte le operazioni eseguite da dhcpd e da named per esaudire la richiesta del client. È interessante infine rilevare che un sistema DHCP, come quello appena impostato, viene usato dai provider per assegnare indirizzi dinamici agli utenti che si collegano tramite modem ADSL domestici o chiavette UMTS. Da qualche parte sulla rete del fornitore sono presenti uno o più server DHCP e questi assegnano gli indirizzi IP e i valori di DNS alle connessioni temporanee. È per questo motivo che non è necessario impostare alcuna configurazione TCP/IP quando si usano modem e chiavette.

Checklist 1. Verificare la presenza del pacchetto dhcpd sul sistema, utilizzando dhcpd -t o dhcpd3 -t. Se compare un messaggio di errore, significa che il pacchetto non è presente e bisogna procedere alla sua installazione. 2. Rinominare il file di configurazione di default /etc/dhcpd.conf e conservarlo come riferimento. 3. Creare un nuovo file di configurazione /etc/dhcpd.conf vuoto. 4. Copiare al suo interno la configurazione generale di dhcpd. 5. Inserire la configurazione specifica di una o più sottoreti. 6. Verificare la correttezza della configurazione realizzata con il parametro -t. 7. Riavviare il servizio, per caricare la nuova configurazione, digitando il comando /etc/init.d/dhcpd restart o /etc/init.d/dhcpd3 restart. 8. Decidere se serve aggiornare dinamicamente il DNS. In caso negativo, passare al punto 17 di questa checklist. 9. Indicare nel file di configurazione di dhcpd l’opzione ddns-update-style interim. 10. Installare il servizio DNS e configurarlo. 11. Creare le chiavi di sicurezza con la direttiva dnssec-keygen. 12. Creare la configurazione dinamica sul servizio DNS. 13. Applicare la chiave di sicurezza alla configurazione del servizio DNS. 14. Riavviare il servizio DNS. 15. Applicare la chiave di sicurezza alla configurazione del servizio DHCP. 16. Riavviare il servizio DHCP. 17. Configurare i client.

Capitolo 6

Capitolo 6 - Creazione di un router software Un router è un dispositivo che permette a due reti indipendenti di comunicare tra loro. Il caso più comune riguarda la rete locale della propria azienda e la rete Internet, due entità autonome, gestite da organizzazioni diverse e configurate con hardware e software completamente differenti tra loro. Il router rende possibile l’interconnessione tra questi mondi, risolvendo diversi problemi pratici. La prima difficoltà riguarda la differente architettura fisica delle reti. La propria LAN e il provider non usano lo stesso mezzo per veicolare le informazioni. Le reti aziendali sono generalmente cablate con cavi Ethernet, mentre il provider potrebbe fornire una connessione ADSL tramite un doppino telefonico. In altre realtà potrebbe esserci un connettore in fibra, un collegamento satellitare oppure una connessione seriale per l’HDSL. Il router risolve questo problema integrando due porte, una Ethernet per la LAN e una per l’accesso esterno. A bordo dell’apparato è inoltre presente un software di sistema, in grado di veicolare le informazioni tra l’ambiente locale e quello esterno impiegando protocolli specifici, per esempio il PPPoE o il PPPoA su un accesso ADSL. Il router si occupa anche della gestione degli indirizzi. Una rete locale dispone di una sottorete di indirizzi privati, per esempio 192.168.100.0, mentre il provider utilizza un proprio insieme di indirizzi IP pubblici assegnati da un ente internazionale preposto alla distribuzione di questa risorsa, per esempio il RIPE (www.ripe.net). Queste sottoreti IP sono tra loro isolate da un punto di vista logico e non è possibile accedere direttamente a una rete dall’altra. Non si tratta però di una carenza tecnica, bensì di una scelta progettuale che permette il funzionamento senza conflitti di reti differenti all’interno dello stesso mezzo fisico. Due aziende presenti in uno stesso edificio potrebbero per esempio stendere un solo cablaggio e creare due LAN indipendenti impiegando semplicemente due sottoreti di indirizzi differenti (per esempio 192.168.100.0 e 192.168.200.0). Si dimezzano così i costi di stesura dei cavi, pur mantenendo un isolamento logico. Questo vantaggio comporta però il problema che la propria rete locale interna 192.168.100.0 e la rete pubblica di Internet non possono comunicare direttamente. Qualunque tentativo di inviare dati da una rete all’altra andrebbe a vuoto e anche le operazioni più banali, come aprire una pagina web, fallirebbero. Il problema si risolve impiegando un router opportunamente configurato.

Generalità sui router Il router è un dispositivo molto complesso. A dispetto di quello che pensano in molti, non si tratta di una sorta di “supermodem”. Piuttosto può essere considerato un computer a tutti gli effetti, visto che è dotato di un microprocessore, di memoria e di porte di I/O per il dialogo con il mondo esterno. Tale componentistica elettronica è coordinata da un sistema operativo e da un software di controllo, il quale pilota le operazioni del dispositivo in base alle istruzioni fornite dall’utente in fase di configurazione. Il sistema operativo è un componente vitale e la qualità complessiva del router è in larga misura frutto di questo elemento, allo stesso modo in cui un computer ha una usabilità migliore se corredato da un buon sistema operativo. Molti produttori di apparati di networking, per esempio Cisco, realizzano il sistema operativo

internamente, impiegando considerevoli risorse economiche e staff numerosi. Un numero crescente di altri operatori ha invece deciso di adottare una strada alternativa e utilizza Linux come sistema operativo per i propri router. Il kernel Linux è infatti molto flessibile e può essere adattato per funzionare all’interno di architetture hardware limitate. Il kernel è inoltre modulare. Questo permette di eliminare le parti non pertinenti e di inserire agevolmente nuovi elementi necessari al funzionamento della soluzione di rete. Si ha inoltre un’implementazione nativa completa del TCP/IP e dell’interfaccia software per controllarne tutti gli aspetti. Gli sviluppatori possono così evitare lo sviluppo di un componente vitale che richiederebbe una fase di debug e di test estremamente lunga e costosa. Il compito per i costruttori di router è quindi molto facilitato. La maggior parte del problema si concentra nello sviluppo dell’hardware e nella costruzione di un’interfaccia utente di tipo Web per la configurazione del prodotto da parte dell’utente. Tutto il resto è disponibile o può essere realizzato da uno staff limitato di tecnici con competenza di reti. A questi vantaggi si aggiunge la stabilità del sistema e il fatto che Linux è collaudato da anni su milioni di computer in tutto il mondo.

Router e Internet box Linux svolge molto bene le funzioni di router all’interno delle Internet box. Milioni di utenti ne fanno un uso inconsapevole ogni giorno con prodotti di varie marche. La qualità risulta evidente e il funzionamento si rivela ottimale nonostante la scarsa quantità di memoria, le CPU limitate e nessun disco a supporto. Se il sistema è funzionale in “gabbie” così piccole, perché non pensare di liberare il pinguino dalla “scatola proprietaria” e portarlo su un PC ordinario per le attività di smistamento della propria rete? Questo è fattibile con una distribuzione Linux standard, ottenendo molta flessibilità e controllo. Il risparmio non risulta invece evidente nelle piccole installazioni (dove i router tipici oramai costano poche decine di Euro), mentre può essere evidente se si esegue lo smistamento di diverse reti, attraverso molte interfacce. Bisogna comunque tenere conto che lo spazio di un cabinet PC è superiore a quello degli apparati di rete odierni e che l’affidabilità è inferiore, a meno di non comprare un sistema costoso con ventole ridondanti, due alimentatori, dischi allo stato solido, schemi in RAID e così via. Vanno inoltre calcolate varie ore di lavoro per la costruzione iniziale della soluzione. A prescindere dagli aspetti pratici, risulta comunque molto istruttivo realizzare un router. Per cominciare bisogna recuperare un vecchio computer. Non servono grandi risorse: basta addirittura un Pentium III, almeno 256 MB di RAM e un disco da 40 GB. Serve anche una scheda di rete compatibile con Linux. Funzionano molte bene le Intel, le 3Com e le schede basate su Realtek, un chip ampiamente supportato e oggi molto affidabile. Altri prodotti economici con processori poco noti andrebbero evitati, perché potrebbero non essere compatibili. Linux va installato in modalità base, senza X, gli ambienti grafici come Gnome e KDE e gli applicativi di produttività. Proprio perché le funzioni di router sono integrate sul kernel, non si ha bisogno di software aggiuntivo. Anzi è preferibile disporre dell’installazione più compatta possibile, per alleggerire il sistema e non incidere troppo sull’hardware limitato. Come accennato nella parte iniziale del capitolo, il router svolge una funzione di ponte tra due reti con topologie differenti. Bisogna di conseguenza fare in modo che il router sia in grado di accedere fisicamente a entrambe. Uno degli adattatori sarà una scheda di rete Ethernet, grazie alla quale si accederà alla propria LAN. Il secondo adattatore varierà in base alla tecnologia usata per il collegamento a Internet: modem analogico, adattatore ISDN, modem ADSL e così via. In alcuni casi il secondo adattatore potrà anche essere una scheda di rete. Alcune reti cittadine in Italia terminano presso l’utenza finale tramite un cavo Ethernet. Non si richiede in questo caso alcun tipo di apparato di conversione per il mezzo fisico.

Configurazione del router Si prenderà in considerazione una rete di uno studio professionale dotato di alcune postazioni client, di un file server e di una connessione a Internet basata su ADSL (Figura 6.1). Questa connessione deve essere condivisa tra tutti gli utenti. La rete locale è configurata con gli indirizzi 192.168.200.n e la maschera di sottorete 255.255.255.0. Le macchine sono numerate secondo le indicazioni presenti nello schema rappresentato in figura e il router dovrà essere configurato come 192.168.200.1. Per dialogare con la rete locale interna si ha una normale scheda di rete, mentre per l’accesso ADSL si usa un modem fornito dal provider. In questi casi si devono evitare i modem USB e optare sempre per le soluzioni Ethernet. Un prodotto USB richiederebbe infatti un driver apposito per Linux. Non tutti i prodotti hanno driver specifici e, nel caso siano disponibili, è richiesta una mole di lavoro di configurazione e test non indifferente. In fase contrattuale è sempre bene specificare la scelta della porta Ethernet per l’accesso ADSL. Servirà quindi anche una seconda scheda di rete per connettere il computer al modem in modalità punto a punto. Conviene installare l’interfaccia Ethernet prima dell’installazione della distribuzione. Il processo di installazione iniziale rende automatiche molte operazioni che dovrebbero altrimenti essere portate a termine manualmente. Bisogna poi specificare l’indirizzo IP sulla scheda di rete, 192.168.200.1 e la subnet mask, in questo caso 255.255.255.0. Come DNS è bene inserire l’IP dei server forniti dal proprio provider. Questi valori devono essere impostati manualmente ed è perciò bene sincerarsi che eventuali servizi DHCP siano disattivati. Bisogna ricordarsi, in fase di installazione, di inibire le funzioni di firewall integrate in molte distribuzioni. Queste potrebbero interferire con le impostazioni iniziali del router. È infatti bene fare i test a sistema aperto e solo in seguito attivare la protezione. Il secondo adattatore va invece configurato per operare con il modem ADSL collegato. I dettagli per la configurazione sono riportati nell’Appendice B di questo volume.

Impostazione delle regole Completate le operazioni preliminari, bisogna procedere all’inserimento delle regole di funzionamento del router. Ossia immettere alcuni comandi per comunicare al kernel di Linux che si desidera inoltrare i pacchetti tra due reti differenti, una LAN interna con indirizzo 192.168.200.n e una rete Internet pubblica accessibile tramite il modem ADSL. Si tratta di comandi che possono essere immessi nella shell di sistema manualmente oppure eseguiti automaticamente ogni volta che il sistema viene avviato. In quest’ultimo caso si deve modificare il file rc.local presente, a seconda delle distribuzioni, nella directory /etc/rc.d oppure direttamente su /etc. Questo file viene eseguito nella fase finale di ogni procedura di avvio ed è il luogo preposto all’inserimento dei comandi che l’utente desidera lanciare automaticamente all’accensione.

Figura 6.1 Schema di rete di un piccolo studio professionale.

Attenzione al fatto che questo file è presente nelle distribuzioni che hanno un legame evolutivo con Red Hat. Altre distribuzioni potrebbero non supportare rc.local. Una volta aperto il corretto file di avvio bisogna posizionarsi in fondo a esso e inserire le seguenti righe: Listato 6.1

echo 1 > iptables iptables iptables iptables iptables iptables iptables

/proc/sys/net/ipv4/ip_forward -F -P INPUT ACCEPT -P OUTPUT ACCEPT -P FORWARD DROP -A FORWARD -o eth0 -j ACCEPT -A FORWARD -o ppp0 -j ACCEPT -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Come si può notare, la configurazione è molto breve, a riprova del fatto che tutto ciò che serve è già presente nel kernel di sistema. La prima riga dello script, echo 1 > /proc/sys/net/ipv4/ip_forward, attiva l’inoltro dei pacchetti tra interfacce differenti. Di default, per motivi di sicurezza, i dati non possono transitare da una scheda di rete all’altra. In tal caso i dati arrivati a una determinata periferica, per esempio ppp0, non avrebbero la possibilità di accedere a eth0 e la comunicazione tra le due reti risulterebbe quindi impossibile. La riga in oggetto scrive un carattere “1” all’interno del file ip_forward in /proc/sys/net/ipv4, attivando di fatto la funzionalità. L’operazione è istantanea e non serve quindi un riavvio. Le righe seguenti utilizzano iptables. Questo comando è l’interfaccia verso Netfilter, il modulo del kernel preposto alla gestione delle comunicazioni sullo stack di rete TCP/IP. Il comando permette di scrivere regole di valutazione sui pacchetti che interessano il sistema locale, permettendo di prendere decisioni in merito. Si possono per esempio scartare pacchetti che provengono da particolari indirizzi o sottoreti, inibire determinate porte, impedire che il traffico transiti da una scheda di rete all’altra, chiudere completamente l’accesso dall’esterno e così via.

A tale scopo, il sistema opera prima di tutto un raggruppamento logico dei pacchetti che interessano il sistema. Questi sono inseriti in tre catene distinte, denominate INPUT, OUTPUT e FORWARD. Nella catena INPUT passano tutti i pacchetti che arrivano dal mondo esterno; nella catena OUTPUT transitano i pacchetti che partono dal sistema locale e sono indirizzati all’esterno; in FORWARD ci sono quelli che passano da una scheda di rete e procedono verso un altro adattatore, per esempio un pacchetto arrivato dall’esterno sulla scheda ADSL e poi inoltrato sulla rete locale tramite l’interfaccia Ethernet. Ogni singolo pacchetto viene valutato in base a regole scritte dall’amministratore con il comando iptables. Le regole sono valutate in maniera sequenziale, una di seguito all’altra. Se una regola si applica al pacchetto, viene eseguito un comportamento ben preciso. Il pacchetto può essere accettato oppure scartato. In quest’ultimo caso non raggiungerà gli strati applicativi del sistema, di fatto “scomparendo”. La volontà di eliminare un pacchetto viene indicata in iptables con il termine tecnico DROP, mentre i pacchetti accettati subiscono il comportamento di ACCEPT. Se nessuna regola soddisfa il pacchetto, viene applicato un comportamento di default stabilito inizialmente. Appena un pacchetto è soddisfatto da una regola, questo viene tolto dalle catene di valutazione e le regole seguenti non possono più agire su di esso. Grazie alle opzioni di iptables è possibile applicare una serie di regole che condizioneranno il comportamento del modulo di comunicazione del kernel. In questo modo si può personalizzare il sistema nei dettagli e perfino realizzare un firewall per la protezione del sistema o di una rete. La seconda riga, iptables -F, cancella ogni configurazione sulle catene predefinite. Una sorta di reset per evitare problemi dovuti a regole precedentemente inserite. In seguito si hanno le regole di default. Queste sono le ultime a essere eseguite in fase di valutazione dei pacchetti, ma sono le prime che vengono indicate in fase di configurazione: iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP

Viene indicato che di default i pacchetti in ingresso e in uscita sono accettati, mentre i pacchetti in FORWARD sono sistematicamente scartati. È possibile cioè comunicare verso l’esterno, ricevere comunicazioni dal mondo esterno, ma il transito dalla LAN verso il modem ADSL e viceversa sono vietati. Questa è una configurazione di sicurezza che impedisce che un utente malintenzionato possa inoltrare dall’esterno pacchetti verso il sistema locale. Questo però impedisce anche qualsiasi tipo di operazione tra la rete locale e Internet, impossibilitando di fatto il routing tra le reti. Si vuole invece che i nodi interni possano comunicare all’esterno e ricevere risposte attraverso la connessione ADSL, quindi si opera come di seguito: iptables -A FORWARD -o eth0 -j ACCEPT iptables -A FORWARD -o ppp0 -j ACCEPT

Con -A si inserisce una nuova riga di valutazione in una catena ben precisa. In questo caso si stanno inserendo due regole nella catena di FORWARD. L’opzione -o indica un’interfaccia d’uscita, nel primo caso la scheda di rete (eth0) e nel secondo caso il modem ADSL (ppp0). L’opzione -j serve invece per specificare il comportamento, in questo caso ACCEPT. Le righe specificano che i pacchetti in uscita sull’interfaccia eth0 possono essere inoltrati a ppp0 e viceversa. Un esempio pratico può essere utile per chiarire. Quando un utente della LAN vorrà aprire una pagina web, partirà una richiesta dalla scheda interna eth0 della macchina Linux. Il pacchetto di richiesta non sarà però indirizzato al sistema locale, ma dovrà transitare verso la porta di uscita ppp0 per raggiungere la destinazione esterna. Questa comunicazione è abilitata a uscire. Le risposte dal server web arriveranno dal mondo esterno sulla porta ppp0, in transito verso eth0. Da

questa scheda la comunicazione sarà recapitata al computer finale per mezzo dello switch aziendale. Anche tale traffico viene abilitato. Le due righe precedenti attivano in pratica il transito nelle due direzioni. Più tecnicamente parlando, ogni pacchetto che transiterà sulla catena di FORWARD sarà prima di tutto valutato in base alle regole precedenti. Se soddisferà le regole, sarà accettato e quindi attraverserà le interfacce di rete. In caso contrario, si applicherà il comportamento predefinito indicato più in alto (iptables -P FORWARD DROP) e il pacchetto sarà eliminato. Seguendo questo ragionamento si può implementare un numero arbitrario di regole, incrementando anche di molto la complessità delle catene.

Attivazione del masquerading A questo punto le regole sui pacchetti sono impostate: il sistema risulta aperto in ingresso e in uscita, ma solamente i pacchetti che hanno origine nella rete locale possono essere inoltrati da una scheda di rete verso l’altra. Ora bisogna risolvere il problema di comunicazione tra sottoreti diverse e fare in modo che i computer dotati di indirizzi privati di tipo 192.168.200.n possano comunicare su Internet usando il solo IP pubblico fornito dinamicamente dal provider nel momento della connessione. Non bisogna mai dimenticare che non è possibile comunicare su Internet usando indirizzi privati. Un tentativo da parte di un nodo privato, per esempio 192.168.200.24, sarebbe immediatamente scartato dal primo router presente sulla rete del provider. Il problema si risolve con il masquerading, operazione che provvede a convertire in modo trasparente gli indirizzi privati interni con l’IP pubblico sulla scheda connessa al modem ADSL. Le comunicazioni interne potranno così uscire e raggiungere i server su Internet. I server esterni risponderanno alle richieste (per esempio l’accesso a una pagina web, un trasferimento FTP, una sessione di gioco online e così via) inviandole al router Linux. A questo punto potrebbe sorgere un problema: visto che tutte le risposte sono indirizzate all’unico IP pubblico dinamico, in che modo il router Linux riuscirà a smistare senza errori le comunicazioni ai client? Il protocollo NAT, responsabile del masquerading, mantiene una tabella in cui associa ogni comunicazione a una macchina ben precisa. Ogni volta che un client esegue una comunicazione, la porta di origine viene modificata e registrata in una tabella che abbina questo valore al computer che ha originato la richiesta. Quando arriveranno i pacchetti di risposta, questi saranno abbinati alla porta di origine. Esaminando la tabella NAT e scorrendo l’elenco delle porte, sarà possibile sapere quale computer aveva iniziato quella precisa comunicazione. Il pacchetto sarà riscritto, sostituendo l’indirizzo del router con l’IP interno della macchina. La riga che attiva il masquerading è la seguente: iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Il comando iptables è stato fino a questo momento utilizzato per creare regole in grado di accettare o scartare pacchetti. Si è in pratica creato un firewall minimale. Iptables va però oltre le funzioni di sicurezza, svolgendo anche un numero elevato di funzioni di mascheramento e di manipolazione dei pacchetti. Di fatto è possibile specificare se le regole che si stanno scrivendo devono agire come regole di sicurezza o come regole di mascheramento. A tal proposito, basta usare il parametro -t. Finora non è stato usato questo parametro, in quanto di default i comandi agiscono sul meccanismo di filtro dei pacchetti e sulle relative tabelle INPUT, OUTPUT e FORWARD. Nulla però vieta di esplicitare che si vuole agire sulla sezione di filtro dei pacchetti, ovvero nella modalità firewall. Per capire tutto questo basta esaminare nuovamente l’esempio precedente, in particolare la riga seguente: iptables -P INPUT ACCEPT

Questa può anche essere scritta in questo modo: iptables -t filter -P INPUT ACCEPT

Le due righe sono assolutamente equivalenti. Subito a destra di -t compare la scritta filter. Questo è il nome del sistema di filtraggio dei pacchetti (la sezione di firewall) di iptables. Per creare, invece, regole di mascheramento si specifica la parola chiave nat di seguito a -t, abilitando le relative catene PREROUTING, POSTROUTING e OUTPUT. La catena di POSTROUTING permette di alterare un indirizzo tramite il protocollo NAT appena prima che il pacchetto esca dalla macchina Linux. Questo è utile per tradurre gli indirizzi di una rete interna in uno o più indirizzi pubblici, come in questo esempio: iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 111.111.111.2-111.111.111.10

In questo caso si sta eseguendo la traduzione dell’indirizzo dei pacchetti in uscita sulla scheda eth0 agli IP compresi tra 111.111.111.2 e 111.111.111.10 (gli indirizzi sono del tutto fittizi). L’opzione -j SNAT attiva il comportamento di traduzione dell’indirizzo sorgente agli indirizzi che obbligatoriamente devono essere specificati con l’opzione --to. Nel caso in cui si abbia un solo indirizzo pubblico assegnato dinamicamente dal provider, come nel caso di un accesso ADSL domestico, conviene invece usare un altro obiettivo. Al posto di -j SNAT, utile se si hanno sottoreti, si digita invece -j MASQUERADE. In questo caso non bisogna specificare l’indirizzo IP. Basta infatti indicare il nome della periferica di comunicazione e il valore sarà automaticamente utilizzato: iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Riepilogando i concetti esposti, l’opzione -t specifica il gruppo di tabelle che si vogliono usare: filter per le tabelle di firewall o nat per le tabelle di conversione indirizzi. Ci possono essere altre tabelle, vista la struttura modulare di iptables, ma la trattazione esula da questo contesto. L’opzione -A serve per aggiungere una regola a una catena, in questo caso POSTROUTING. L’opzione -o indica l’interfaccia di uscita, mentre -j specifica il comportamento (o più tecnicamente obiettivo), in questo caso MASQUERADE. Si tenga presente che nella tabella di POSTROUTING non è possibile usare l’opzione –i (scheda di INPUT).

Tabella PREROUTING La tabella opposta a POSTROUTING è PREROUTING, che permette di eseguire trasformazioni di indirizzi o di porte sui pacchetti in ingresso, prima che siano inoltrati. Le applicazioni più comuni per questo tipo di operazioni sono due: il port forwarding e il trasparent proxy. Con il port forwarding è possibile attivare un sito web pubblico installato all’interno della LAN con un indirizzo privato e fare in modo che gli utenti esterni possano accedervi usando l’indirizzo pubblico del router. Il sistema provvederà a smistare i pacchetti verso il nodo interno: iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to 192.168.200.40

In questo caso i pacchetti con protocollo TCP (-p tcp), destinati alla porta web (--dport 80) e in arrivo sulla scheda di rete esterna eth1 (-i eth1) subiranno una trasformazione e l’indirizzo di destinazione sarà cambiato in 192.168.200.40. Si tenga presente che l’opzione --to è obbligatoria dopo -j DNAT e che nelle regole di PREROUTING non

si può specificare una scheda di uscita (-o), ma solo di ingresso (-i). I l proxy trasparente è invece un’operazione per cui gli accessi eseguiti da client interni verso, per esempio, siti web, non siano inoltrati direttamente al mondo esterno. Questi saranno invece deviati, a insaputa degli utenti, a un proxy interno in maniera trasparente. Non servirà in questo modo specificare l’indirizzo del proxy dal pannello di configurazione dei singoli browser. In tal modo si potrà effettuare il caching dei contenuti, ridurre il traffico e operare controlli sugli utenti per capire le abitudini interne. Per meglio capire l’utilizzo della catena di PREROUTING si consideri il caso di un proxy che si trova all’indirizzo 192.168.200.50 e che risponda alla porta 8080. Per fare in modo che tutti gli accessi web siano inoltrati automaticamente a questo proxy si deve usare questo tipo di regola: iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.200.50:8080

La sintassi è simile al caso del port forwarding; quello che cambia è il fatto che viene considerata la scheda di rete eth0, che è interfacciata con la LAN e che la destinazione comprende anche la porta, separata dall’indirizzo tramite il carattere “:”, come in 192.168.200.50:8080. Nel caso in cui il proxy fosse installato sulla stessa macchina che esegue la funzione di router, si potrebbe ottenere lo stesso tipo di comportamento usando -J REDIRECT: iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Il traffico web (-p tcp --dport 80) in arrivo sulla scheda interna eth0 viene semplicemente rediretto verso la porta 8080, dove è in ascolto il proxy. Il parametro --to-port è obbligatorio dopo l’uso di REDIRECT. Prima di proseguire nella trattazione è interessante far presente che quando si specifica un intervallo di indirizzi per le operazioni di nat, il sistema sceglie l’indirizzo meno utilizzato per inoltrare il pacchetto. Questo permette di costruire applicazioni di ottimizzazione delle risorse. In caso di siti web molto affollati, si potrebbero creare due server identici e costruire un router Linux in grado di alternare a ripetizione l’accesso all’una o all’altra macchina. Il carico sarà così ripartito tra le due macchine, evitando di sovraccaricare i sistemi e migliorando i tempi di risposta. Dall’esterno non si noterà alcuna differenza, in quanto le operazioni saranno gestite in modo trasparente.

Funzionamento del router A questo punto non resta che riavviare il sistema e rendere operativo il router. Bisogna poi andare sui client e specificare l’indirizzo del router. Su Windows XP si seleziona Risorse di rete dal desktop, si fa clic con il tasto destro del mouse, si sceglie Proprietà e si fa doppio clic su Protocollo Internet (TCP/IP). In Gateway predefinito (Figura 6.2) bisogna inserire l’indirizzo del sistema appena configurato. Come DNS si devono invece indicare i dati forniti dal provider. Confermando il tutto, il client dovrebbe essere pronto per l’accesso a Internet.

Figura 6.2 Finestra di configurazione della rete in W indow s.

Il router, appena installato, risulta efficace per le comunicazioni su Internet, ma è debole sul lato della sicurezza. Non sono infatti impostate regole di alcun tipo per la protezione delle comunicazioni e per impedire che utenti esterni possano accedere al router stesso. Oggi è molto pericoloso affacciarsi su Internet in questo modo. Bisogna perciò procedere all’aggiunta di regole dedicate alla sicurezza. Prima di implementare il router è quindi importante leggere il Capitolo 7 dedicato al firewall e applicare le informazioni di sicurezza presenti.

Se il provider fornisce IP fissi mascherati In Italia vi sono provider che forniscono a costi aggressivi piccole sottoreti di IP statici pubblici per l’utenza di tipo professionale basata su ADSL. Si tratta di reti da 4, 8 o 16 IP da utilizzarsi per l’attivazione di servizi online entro le mura della propria attività lavorativa. Alcuni provider forniscono gli IP reali attestati direttamente sul router usato per l’accesso a Internet. In questi casi non ci sono problemi pratici da risolvere: basta assegnare gli IP pubblici ai propri sistemi configurando la scheda di rete e si è online. Altri provider forniscono invece gli IP pubblici attraverso un meccanismo di NAT. Il cliente può cioè accedere alla rete del provider unicamente tramite gli IP locali abilitati sul router del provider. Gli indirizzi pubblici sono inoltrati al router che il provider ha lasciato presso l’utente finale e l’utente finale deve predisporre un sistema che associ un IP pubblico a un IP locale abilitato dal provider. La macchina con i servizi da pubblicare non ha quindi un indirizzo pubblico assegnato alla propria scheda di rete, ma comunica con il mondo esterno tramite un sistema intermedio. Questo elemento esegue funzionalità di mascheramento, in modo che sia eseguita la traduzione degli indirizzi in maniera trasparente. Così facendo, il

mondo esterno sarà in grado di accedere alle macchine con i servizi e viceversa. Linux può eseguire perfettamente questa funzione, evitando di affrontare i costi di un apparato dedicato. Per capire meglio questa condizione si consideri una piccola azienda dotata di un servizio ADSL con quattro indirizzi pubblici da usare liberamente per i propri servizi online. Questi indirizzi sono però forniti in modalità NAT e l’azienda può unicamente comunicare sulla linea ADSL tramite gli indirizzi 192.168.100.1, 192.168.100.2, 192.168.100.3 e 192.168.100.4. L’azienda ha deciso di usare l’indirizzo 192.168.100.4 per far comunicare le postazioni interne su Internet. Allo scopo verrà configurato un meccanismo NAT su un router per fare in modo che tutte le postazioni usino quest’unico IP abilitato per comunicare su Internet. I due server che fanno girare i servizi pubblici non saranno collegati alla sottorete privata indicata in alto ma, per motivi di sicurezza, saranno configurati su una nuova sottorete con gli indirizzi 192.168.10.10 e 192.168.10.11. Il mondo esterno raggiungerà i due server usando due IP pubblici forniti dal provider. In questo caso si useranno a titolo di esempio due indirizzi fittizi: 111.111.111.1 e 111.111.111.2 (questi indirizzi dovranno essere sostituiti con gli IP forniti dal provider). Una macchina Linux, posta subito dopo il router del provider eseguirà la traduzione degli indirizzi. La macchina avrà a tale scopo due schede di rete. La prima, eth0, avrà indirizzo 192.168.100.13 e sarà collegata con un cavo al router. Il sistema sarà opportunamente configurato per comunicare su Internet, impostando correttamente il default gateway (il router del provider) e i DNS. La seconda scheda, eth1, avrà invece l’indirizzo 192.168.10.1 e sarà collegata a uno switch su cui saranno presenti e attivi i due server applicativi. Si deve a questo punto creare una configurazione per lo scopo, inserita all’interno dello script di avvio del sistema Linux: Listato 6.2

echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Attivazione server web iptables -t nat -A POSTROUTING -s 192.168.10.10 -j SNAT --to 111.111.111.1 iptables -t nat -A PREROUTING -d 111.111.111.1 -j DNAT --to 192.168.10.10 # Attivazione server mail iptables -t nat -A POSTROUTING -s 192.168.10.11 -j SNAT --to 111.111.111.2 iptables -t nat -A PREROUTING -d 111.111.111.2 -j DNAT --to 192.168.10.11

La prima riga attiva il forward tra le schede di rete, mentre la seconda abilita il masquerading. Il blocco seguente, dedicato al server web, fa in modo che gli indirizzi locali siano tradotti in indirizzi pubblici e viceversa. La stessa configurazione, ma con gli indirizzi appositi, è applicata al server mail. Se vi sono altri server (e avanzano degli indirizzi pubblici) è possibile andare avanti creando semplicemente nuovi blocchi di traduzione.

Opzioni di iptables Il sistema netfilter è estremamente potente. Vale la pena di esaminare con più attenzione le opzioni di iptables maggiormente utilizzate.

Regole presenti in una catena

In ogni momento è possibile ottenere la visualizzazione delle regole presenti in una determinata catena con l’opzione -L: iptables -L input

Questo è il risultato su un sistema configurato come firewall: Listato 6.3

Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:pop3 flags:SYN,RST,ACK/SYN ACCEPT tcp -- anywhere anywhere tcp dpt:smtp flags:SYN,RST,ACK/SYN ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN ACCEPT tcp -- server.incipit.biz/29 anywhere tcp dpt:44337 flags: SYN,RST,ACK/SYN ACCEPT udp -- server.incipit.biz /29 anywhere udp dpt:44337 ACCEPT tcp -- server.incipit.biz /29 anywhere tcp dpt:8004 flags: SYN,RST,ACK/SYN ACCEPT udp -- dns.interbusiness.it anywhere udp spt:domain REJECT tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable REJECT udp -- anywhere anywhere udp reject-with icmp-port-unreachable

La catena di ingresso ha la policy di default ACCEPT. Viene accettato il traffico esterno pop3, smtp, http e ssh, qualunque sia l’indirizzo di origine. L’accesso alle porte tcp e udp 44337 è permesso solo a server.incipit.biz, come per l’accesso alla porta 8004. Si tratta in questo caso di porte di controllo per servizi server, accessibili per motivi di sicurezza solo alla rete incipit.biz. È permesso l’accesso dalla porta domain per il solo indirizzo del DNS di Interbusiness. Sono infine scartate le comunicazioni TCP che provengono dall’esterno e le comunicazioni UDP. È possibile utilizzare l’opzione -L per visualizzare l’elenco di tutte le catene presenti.

Inserimento di una regola in una catena Per inserire una regola si utilizza -A (append) con la sintassi seguente: iptables -A catena target -j comportamento

Per esempio: iptables -A INPUT -s 82.106.143.4/255.255.255.248 -j DROP

Si è specificato che la regola sarà inserita nella catena di INPUT, avrà come target l’indirizzo di sorgente 82.106.143.4, maschera 255.255.255.248 e avrà il comportamento di DROP. Questo significa che tutto quello che proviene dall’indirizzo 82.106.143.4 sarà scartato. L’opzione -s indica l’indirizzo sorgente. Eventualmente è possibile specificare un indirizzo di destinazione con l’opzione -d: iptables -A OUTPUT -d 82.106.143.4/255.255.255.248 -j DROP

Si applica una regola nella catena di OUTPUT a specificare che i pacchetti destinati al nodo 82.106.143.4

saranno interdetti. Per creare una regola in base al protocollo si usa invece l’opzione -p: iptables -A INPUT -p icmp -s 82.106.143.4/255.255.255.248 -j DROP

Il comando scarta i pacchetti ICMP provenienti dall’indirizzo 82.106.143.4, che non potrà quindi usare il comando ping verso il sistema che si sta configurando. iptables -A OUTPUT -p tcp -d 192.168.200.3 -j DROP

Questa regola vieta a qualunque pacchetto TCP di uscire dal sistema e andare al nodo 192.168.200.3. Pacchetti TCP per altri indirizzi risulteranno ancora abilitati. I parametri possibili per l’opzione -p sono tcp, udp, icmp oppure la chiave all, per specificare qualunque protocollo. Si possono indicare anche i protocolli elencati nel file /etc/protocols oppure inserire il valore numerico che rappresenta il protocollo. Un elenco ufficiale è disponibile all’indirizzo http://www.iana.org/assignments/protocol-numbers. Anche le porte possono essere usate per la costruzione delle regole. L’opzione --dport (destination port) oppure --sport (source port) deve però essere inserita di seguito all’indicazione del protocollo (-p): iptables -A OUTPUT -p tcp -d 192.168.200.3 --dport 80 -j DROP

La regola scarta i pacchetti TCP indirizzati alla porta 80 del sistema 192.168.200.3. È possibile specificare anche un intervallo di porte tramite il segno di due punti, come riportato di seguito: iptables -A OUTPUT -p tcp -d 192.168.200.3 --dport 80:1024 -j DROP

La regola scarta i pacchetti TCP indirizzati al sistema 192.168.200.3 sulle porte dalla 80 alla 1024. Per specificare una porta sorgente si usa invece --sport. Nella compilazione delle regole è possibile usare il segno di negazione “!” per invertire la logica dell’espressione, come nell’esempio seguente: iptables -P INPUT DROP iptables -A INPUT -p tcp --dport ! 1:1024 -j ACCEPT

La seconda regola permette l’accesso ai pacchetti TCP che sono destinati a porte superiori alla 1024. I pacchetti verso le porte comprese tra la 1 e la 1024 saranno scartati. Le regole possono agire anche sugli adattatori di rete. L’opzione -i blocca il traffico in ingresso sulla scheda di rete specifica, mentre -o blocca il traffico in uscita sulla scheda: iptables -A INPUT -i eth2 -j DROP

Il traffico in ingresso sull’interfaccia eth2 viene scartato. Tutte le opzioni presentate in questo paragrafo possono essere combinate tra loro. Con l’opzione -A le regole sono inserite in fondo alla catena. È anche possibile inserire una regola in un punto ben preciso della catena tramite l’opzione -I: iptables -I INPUT 2 -i eth2 -j DROP

La regola sarà così inserita nella seconda posizione della catena di INPUT. Per sostituire una regola presente in una determinata posizione con un’altra regola si usa invece l’opzione -

R: iptables -R INPUT 2 -i eth2 -j DROP

La regola presente nella seconda posizione sarà sostituita con la nuova regola in oggetto.

Cancellazione di una regola La cancellazione viene effettuata con l’opzione -D (delete). Vi sono due modi per usarla. Nel primo caso si può specificare il numero sequenziale della regola in catena da cancellare. Se si vuole eliminare la prima regola della catena di OUTPUT si usa questo formato: iptables -D OUTPUT 1

Per vedere la sequenza di regole si può usare l’opzione -L e contare manualmente la posizione. È facile però confondersi. In alternativa si può cancellare la regola semplicemente riscrivendo il comando di creazione, digitando però -D al posto di -A: iptables -D INPUT -s 82.106.143.4 /255.255.255.248 -j DROP

Cancellazione del contenuto di una catena Per vuotare completamente una catena è possibile cancellare manualmente ogni regola con l’opzione -D oppure utilizzare -F (flush). Tutte le regole saranno eliminate in un solo comando: iptables –F

È possibile cancellare anche singole catene: iptables -F INPUT

Creazione di una catena personalizzata Il sistema gestisce un certo numero di catene standard: INPUT, OUTPUT e FORWARD. È però possibile creare nuove catene per le proprie specifiche necessità. L’opzione -N provvede a questo scopo: iptables -N miacat

Se si richiede di elencare le catene con l’opzione -L, sarà presentata anche la nuova catena miacat, ovviamente vuota. Ora è possibile aggiungere regole nella nuova catena miacat utilizzando i comandi tradizionali: iptables -A miacat -d 192.168.150.3 -j DROP

La regola di interdizione sui pacchetti destinati al nodo 192.168.150.3 sarà inserito in miacat. Stando a queste regole, l’utilità della nuova catena è molto limitata: si tratta infatti di una catena isolata dai flussi di dati controllati dalle catene INPUT, OUTPUT e FORWARD. Bisogna allora provvedere a collegare la

catena personalizzata a una delle tabelle standard: iptables -A INPUT -j miacat

In fondo alla sequenza di regole della catena INPUT saranno allegate le regole presenti nella catena miacat, come se le regole presenti in miacat fossero state inserite direttamente in INPUT. L’utilizzo delle liste personalizzate si rivela comodo per ordinare le regole in maniera funzionale, invece di inserirle alla rinfusa direttamente sulla catena principale. Diventa inoltre agevole inserire o disinserire blocchi di regole, a seconda delle esigenze. Si potrebbe, per esempio, immaginare di avere una catena personalizzata vpn1 per gestire una VPN e una catena webdmz per gestire un server web (Figura 6.3) protetto da una DMZ.

Figura 6.3 Router Linux con tre schede di comunicazione, una delle quali dedicata alla DMZ.

Queste due catene personalizzate vengono collegate alla catena INPUT nel modo seguente:

iptables -A INPUT -j vpn1 iptables -A INPUT -j webdmz

Si supponga che in webdmz ci siano le regole per permettere il traffico da Internet solo verso i servizi web oltre che una serie di altre regole per proteggere il server da attacchi esterni di varia natura. Si ipotizzi però di voler eseguire la manutenzione del sistema e dover disattivare l’accesso al server dall’esterno, mantenendolo comunque accessibile dall’interno della propria LAN. Il modo più rapido per raggiungere lo scopo è scollegare la catena webdmz: iptables -D INPUT -j webdmz

Subito dopo è importante collegare una seconda catena personale con una serie di regole per bloccare l’accesso a DMZ. Tale catena potrebbe essere denominata nodmz. Bisogna fare attenzione al fatto che, nel lasso di tempo tra l’eliminazione della catena webdmz e l’inserimento di nodmz, si è di fatto esposti completamente a eventuali attacchi e interferenze: non è una buona situazione in termini di sicurezza. Meglio allora invertire l’ordine e inserire prima la catena nodmz e poi eliminare webbdmz. Per cancellare completamente una catena personalizzata si usa l’opzione -X: iptables -X vpn1

Prima di cancellare una catena personalizzata bisogna procedere a eliminarne il contenuto: iptables -F vpn1

Non è possibile cancellare una catena personalizzata se si fa riferimento ad essa da qualche parte in una catena standard. Una catena può anche essere rinominata, tramite l’opzione -E con la sintassi seguente: iptables -E

Generazione di un file di log dei pacchetti È possibile registrare in un file di log particolari tipi di pacchetto che si vogliono monitorare. Può risultare molto utile registrare le occorrenze di alcuni eventi interdetti, per valutare il grado in cui i propri sistemi sono stati presi di mira da cracker esterni. Per esempio si potrebbe disattivare qualunque tipo di accesso esterno alla shell di sistema tramite il servizio Telnet (porta 23) e memorizzare tutte le volte che qualcuno, dall’esterno, tenta di connettersi a questa porta. Tale registrazione diventa così l’elenco dei tentativi di accesso al sistema. La registrazione avviene usando un particolare tipo di comportamento, denominato LOG: iptables -A INPUT -s 0.0.0.0/0.0.0.0 -p tcp --dport 23 -j LOG

In questo caso, saranno registrati tutti i pacchetti tcp alla porta 23. Se si vogliono eliminare i pacchetti destinati a Telnet bisogna aggiungere un’ulteriore riga: iptables -A INPUT -s 0.0.0.0/0.0.0.0 -p tcp --dport 23 -j DROP

A differenza degli altri comportamenti, LOG non toglie il pacchetto che ha soddisfatto la condizione dalla catena di valutazione. Una regola successiva, come quella appena riportata, potrà così agire sul medesimo

pacchetto. Il luogo in cui saranno appese le registrazioni varia a seconda dalle distribuzioni, ma il comportamento viene regolato dal demone syslogd. Bisogna andare in /etc, aprire il file syslog.conf e verificare a quale file punta il livello kern.info. I messaggi log di iptables saranno memorizzati all’interno del file puntato da kern.info. Di default questo file potrebbe essere /dev/console, ovvero il terminale. Per avere la registrazione su file conviene modificare l’impostazione aggiungendo per esempio /var/log/kernel. Qui di seguito viene riportato il file syslog.conf per una distribuzione standard: Listato 6.4

# Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Everybody gets emergency messages, plus log them on another # machine. *.emerg * # Save mail and news errors of level err and higher in a # special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log *.* /dev/tty12

Come si può notare, il livello di interesse è il primo e in questo caso punta alla console.

Visualizzazione di statistiche È possibile visualizzare informazioni statistiche sulle catene di iptables tramite l’opzione -v: iptables -v -L INPUT

L’output di questo comando mostra quanti pacchetti sono stati sottoposti alle regole presenti e quanti kilobyte complessivi hanno interessato. Può essere, per esempio, utile sapere quanti kilobyte vengono sprecati per scartare pacchetti non regolari in connessioni fatturate a traffico. Gli indirizzi IP di questa visualizzazione sono convertiti in formato esteso tramite un’interrogazione al DNS. Per visualizzare gli indirizzi si può usare l’opzione -n: iptables -v -n -L INPUT

In ogni momento è possibile azzerare i contatori specificando il comando seguente: iptables -Z INPUT

Checklist 1. Reperire un computer e installare due schede di rete. 2. Installare Linux senza ambiente grafico, applicativi e qualunque altro elemento superfluo. L’installazione infatti deve essere di base. 3. Configurare le schede di rete, preferibilmente in fase di installazione. 4. Abilitare l’accesso a Internet tramite una delle schede di rete. 5. Disattivare il firewall, se la distribuzione lo prevede. 6. Attivare il forwarding tra le schede di rete. 7. Impostare le regole di filtro con iptables. 8. Attivare il NAT/Masquerading con iptables. 9. Configurare i client Windows.

Capitolo 7

Capitolo 7 - Firewall perimetrale con iptables e SmoothWall Il termine “firewall” è entrato nella cultura informatica collettiva a seguito della diffusione di massa di “Codice Rosso” nell’estate del 2001. In quella occasione, la comunità internazionale si rese conto della vulnerabilità degli strumenti informatici così largamente utilizzati. Questa prima grande “infezione” fu resa possibile da una falla presente all’interno del server web di Microsoft, Internet Information Server (Figura 7.1). Sfruttando una serie di bug noti era possibile trasferire programmi dall’esterno e farli eseguire senza il consenso dell’amministratore.

Figura 7.1 Pannello di amministrazione di una vecchia versione di Microsoft IIS.

Il problema era reso ancora più serio dal fatto che Internet Information Server era installato di default nei sistemi operativi server. Molti utenti e molte aziende avevano adottato la piattaforma server di Microsoft apprezzando la semplicità del prodotto e la somiglianza con l’interfaccia utente di Windows 95 e 98. Una considerevole fascia di questi utenti si era però limitata a installare il prodotto tralasciando completamente la fase imprescindibile di messa in sicurezza del sistema. Questa leggerezza da parte degli utenti comportò l’infezione di milioni di computer e un incremento del traffico Internet mondiale per via dell’attività esplorativa del worm. Microsoft rese disponibile una correzione in tempi molto rapidi e pubblicò una serie di note tecniche per la protezione dei sistemi. Eppure, ad anni di distanza, esiste ancora un rumore di fondo su Internet, dato dall’attività di esemplari di Codice Rosso radicati su computer tuttora privi di patch. Normalmente si attribuisce la colpa dell’insicurezza informatica ai produttori di software e ai gruppi di sviluppo, ma anche gli utenti finali hanno le loro responsabilità. Nell’estate del 2003 si è verificato un problema analogo. Sfruttando una vulnerabilità del componente RPC di Windows era infatti possibile trasferire codice dall’esterno per far eseguire programmi di qualunque tipo.

Il meccanismo RPC (Remote Procedure Call) permette a un computer di eseguire programmi presso un altro computer ubicato nella rete locale. Si tratta di un componente disponibile in tutte le versioni di Windows, ma su 2000/XP/2003 e NT4 era presente un bug di programmazione. Qualcuno sfruttò il problema per scrivere MSBlast. Il worm entrava nel sistema attraverso la connessione Internet e procedeva a radicarsi nel sistema locale per poi eseguire una serie di attività indesiderate. Ma in che modo un worm “entra” nel sistema? Per dare una riposta a questa domanda chiave è bene esaminare qualche dettaglio tecnico sulle comunicazioni in Internet.

Generalità sugli standard di comunicazione Ogni comunicazione in Internet avviene attraverso l’uso di protocolli che stabiliscono i dettagli della connessione e il modo in cui i dati sono trasmessi tra due sistemi. I protocolli sono stratificati in modo preciso e organizzati in modo da gestire tutti gli aspetti complessi delle comunicazioni, compresi i dettagli specifici del mezzo impiegato, sia esso cablato o senza fili. Si devono quindi avere regole per accedere al mezzo, per gestire le comunicazioni in un ambiente dove vi è un numero imprecisato di sistemi che possono comunicare in qualunque istante e per realizzare un sistema univoco di indirizzamento dei nodi. Vi sono poi regole per lo scambio effettivo delle informazioni, per il modo in cui i dati vengono cifrati e per gestire l’interazione con l’utente. Dando per scontati gli aspetti basilari delle comunicazioni e il fatto che ai sistemi vengono assegnati indirizzi numerici univoci denominati “indirizzi IP”, si può approfondire l’analisi dei protocolli UDP e TCP, fondamentali per comprendere il problema della sicurezza. UDP (User Datagram Protocol) è un protocollo che ha la peculiarità di essere rapido e semplice da implementare nelle applicazioni. Questo permette di creare un flusso di dati tra due sistemi, per esempio un server e un client, e di trasferire le informazioni in tempo reale. Manca però un meccanismo per la correzione dei dati. Se, durante la comunicazione, si perdono informazioni o si verificano errori, non esiste la possibilità di ripristinare l’informazione. Questo non è un limite, perché molte applicazioni non hanno la necessità di avere l’integrità di tutte le informazioni, ma hanno piuttosto bisogno di essere veloci. Un buon esempio è rappresentato dalla videoconferenza. Se si perde sporadicamente un fotogramma, non si hanno conseguenze sulla comunicazione complessiva. Questa caratteristica non è invece adatta per il trasferimento dei file o nelle sessioni di assistenza in remoto. In queste situazioni serve un grado elevato di affidabilità. Viene quindi utilizzato TCP, un protocollo più strutturato e in grado di ripristinare l’integrità delle informazioni a seguito di errori. Entrambi i protocolli suddividono i dati complessivi in unità più piccole, denominate “pacchetti”. Ogni pacchetto non contiene solamente i dati, ma anche una serie di informazioni utili alla gestione della comunicazione in atto. Questi dati di servizio prendono il nome di “intestazioni”. Una delle attività più frequenti su Internet è la consultazione di pagine web. L’accesso a queste informazioni avviene tramite un browser sul lato client, che si connette a un server remoto che eroga le informazioni richieste. Il protocollo utilizzato in questo tipo di comunicazione è il TCP. Non è pensabile recapitare pagine con errori o mancanze, quindi i progettisti del World Wide Web hanno optato per un protocollo dotato di meccanismi di correzione. La comunicazione non è però esclusiva. In quello stesso istante, il server che gestisce il sito può essere impegnato a servire le richieste di decine o migliaia di altri utenti interessati alle pagine memorizzate al suo interno. Contemporaneamente potrebbe erogare anche altre comunicazioni come, per esempio, lo scambio di file tramite FTP o la trasmissione di filmati video. Uno stesso utente potrebbe avere diverse finestre con flussi separati provenienti dallo stesso server. Se si dispone di una buona connettività, si può scaricare un file tramite FTP da un sito che pubblica software e allo

stesso tempo leggere i commenti lasciati dagli utenti sul forum. In questa situazione si hanno due flussi di dati che originano dal proprio computer, indirizzati allo stesso server. Come si evita in tal caso che i dati del servizio web possano finire per errore nel flusso FTP generando caos? La soluzione risiede nel concetto di porta. Si tratta di un valore compreso tra 1 e 65.535 che identifica in maniera univoca un tipo di servizio. A ogni servizio è assegnato un valore ben preciso di porta. I servizi web, per esempio, usano la porta 80 del server, mentre il flusso FTP è gestito in una delle sue modalità con le porte 20 e 21. Quando un client accede esternamente, deve specificare l’indirizzo del server cui fare riferimento e il numero di porta cui intende collegarsi. Le comunicazioni restano così ben identificate e non c’è alcun rischio che avvengano “scambi” di dati. Ogni sistema ha un numero variabile di porte aperte. Tutto dipende dai servizi attivi e da quali specifici applicativi di rete sono stati installati sul computer. Le altre porte rimangono invece chiuse, in quanto non c’è alcun programma a gestirle. Di base, un’installazione di Windows ha diverse porte aperte, tra cui le porte 135, 136, 137 e 445 dedicate allo sharing sulla LAN (Figura 7.2). La condivisione dei file e l’elenco dei computer presentati in Risorse di rete sono possibili proprio perché i sistemi Windows rispondono a queste porte e comunicano in base a protocolli di rete ben precisi. Installando Internet Information Server si avranno attive anche le porte 80 (servizio web), 20 e 21 (servizio FTP).

Figura 7.2 In W indow s, la condivisione delle risorse funziona attraverso le porte 135, 136, 137 e 445.

Ci saranno poi altre porte attive: l’elenco si allungherà ogni volta che si installerà un programma che eroga servizi Internet, come sistemi di telecontrollo, applicazioni peer to peer, tool di messaggistica istantanea e così via. Le porte non applicano una distinzione tra rete locale e Internet. Le porte aperte sono quindi accessibili a chiunque sia presente sulla LAN, come a tutta l’utenza Internet mondiale. È grazie a questo dettaglio che avvengono molti attacchi verso il sistema locale. Se si naviga su Internet con le condivisioni attive, chiunque

può potenzialmente accedere alle risorse locali e utilizzarle liberamente. Allo stesso modo un server web installato di default può essere usato da chiunque. Qualche anno fa era comune che gli utenti meno esperti non fossero a conoscenza di ricevere visite dall’esterno verso la pagina di default di Internet Information Server presente sulla propria macchina Windows NT o Windows 2000 Workstation (Figura 7.3).

Figura 7.3 Pagina di default per una installazione di IIS non configurata.

Se dietro una porta aperta su Internet risponde un servizio con bachi, i problemi si amplificano notevolmente e diventa possibile qualunque tipo di scenario, compresa la diffusione di worm come Codice Rosso o MSBlast. La soluzione al problema è il firewall. Questo sistema costringe tutti i pacchetti che entrano o che escono a transitare da un passaggio obbligato, dove subiranno una serie di verifiche e controlli. Il firewall provvede inoltre a schermare la rete locale interna, occultando le porte al mondo esterno. In genere sono chiuse dall’esterno tutte le porte fino alla 1024. Queste sono infatti dedicate ad applicazioni di sistema potenzialmente pericolose. Tra queste il servizio web, FTP, il Telnet, i meccanismi di condivisione di Windows, il sistema RPC, i protocolli SMTP e POP3 oppure il meccanismo SNMP per la gestione degli avvisi dei dispositivi in rete. Il fatto che la porta 80 relativa al servizio web sia bloccata in ingresso non implica una restrizione nella direzione opposta. Le regole di filtro sul firewall devono infatti sempre indicare la direzione della comunicazione. Non è infatti pericoloso che gli utenti della LAN accedano a pagine web, mentre può essere rischioso che qualcuno, da fuori, cerchi di accedere ai servizi web della rete interna (per esempio l’intranet aziendale). In alcuni casi l’interdizione a tutte le porte dall’esterno può risultare un po’ troppo restrittiva. Per esempio, se è necessario pubblicare un server web, si deve attivare il servizio abilitando questa precisa porta sul firewall. I firewall permettono una configurazione molto granulare e non sono fortunatamente limitati a comportamenti del tipo “tutto aperto” o “tutto chiuso”. Un altro controllo di sicurezza che si opera sul firewall consiste nella verifica degli indirizzi interni sulla porta esterna. Si deve impedire che un pacchetto proveniente dall’esterno utilizzi l’indirizzo privato di un nodo

interno della LAN. Qualcuno potrebbe, infatti, aver contraffatto il proprio indirizzo IP con l’intento di entrare nella rete locale e apparire come un nodo interno autorizzato. Tecnicamente questa operazione di mascheramento si chiama spoofing. Questi e altri controlli tipici saranno implementati nelle prossime sezioni di questo capitolo.

Firewall con Linux Qualunque sia il tipo di controllo che si voglia eseguire, bisogna partire alterando la topologia della propria rete e inserendo il firewall in una posizione ben precisa. Questo deve infatti trovarsi tra la rete locale interna e l’accesso a Internet, divenendo una tappa obbligata per qualunque pacchetto in transito da una rete all’altra. Questa struttura viene tecnicamente definita a “bastione” (Figura 7.4).

Figura 7.4 Schema di una rete locale protetta da un firew all in modalità bastione.

Il firewall è in questo caso un normale PC dotato di Linux e configurato con un certo numero di regole di protezione. Sul PC dovranno essere installate due schede di rete. Il primo adattatore sarà collegato alla rete interna con un cavo Ethernet che si innesterà sullo switch aziendale. La seconda scheda di rete sarà invece direttamente connessa al router che provvede alla comunicazione su Internet. In questo modo, le due reti sono isolate fisicamente e solo il software del firewall può fare in modo che i pacchetti possano fluire da una scheda all’altra, attraversando così le reti. Per esempio, se il firewall è programmato per non far entrare nessuna comunicazione originata da Internet, tutti i pacchetti in arrivo sulla scheda esterna saranno eliminati. La LAN non riceverà così tali comunicazioni. Contestualmente si può programmare il firewall per autorizzare il traffico dall’interno verso l’esterno. Alternativamente si può permettere che dall’esterno entrino solo le comunicazioni richieste dai sistemi interni della rete locale. Si tratta di una modalità comune oggi per i firewall. Il firewall è quindi un controllore che esamina ogni pacchetto, autorizzando solo le comunicazioni ritenute regolari. Linux contempla un meccanismo molto efficace per la costruzione di firewall. Il kernel dispone infatti di un modulo di comunicazione completo basato sul protocollo TCP/IP. Non solo è possibile gestire pienamente le comunicazioni, ma si può anche filtrare i pacchetti in base a regole ben stabilite.

Questi elementi di controllo non sono opzioni o pacchetti che devono essere installati appositamente su Linux, bensì componenti di sistema presenti nel kernel e disponibili in qualunque distribuzione. Si tratta di Netfilter, che si trova molto in basso nella gerarchia di sistema e con cui l’utente non ha un contatto diretto. Tutte le operazioni di controllo e configurazione avvengono invece con un comando di sistema, denominato iptables. L’infrastruttura di sicurezza su Linux ha subito diversi miglioramenti nel tempo e la fisionomia attuale è stata fissata con il rilascio del kernel 2.4. La novità certamente più interessante riguarda la presenza di un meccanismo di controllo basato sullo stato. In precedenza era possibile fare controlli sui singoli pacchetti basandosi su indirizzi, reti, porte e protocolli. A partire dal kernel 2.4 si può anche verificare se il pacchetto esterno esaminato in un dato istante appartiene a una sessione aperta dall’interno e autorizzata in precedenza o se, per esempio, è una sessione aperta dal mondo esterno, sintomo di un potenziale attacco. Il controllo diventa quindi più ampio e dettagliato. I firewall in grado di operare controlli sullo stato delle comunicazioni nel tempo sono denominati stateful inspection. Al contrario quando il firewall è in grado di controllare solamente il singolo pacchetto si chiama packet filter. Le distribuzioni Linux che usano il Kernel 2.4 o 2.6 dispongono di default di un firewall di tipo stateful inspection, mentre i sistemi Linux con Kernel 2.2 beneficiano unicamente di un firewall di tipo packet filter. In questi ultimi sistemi l’interfaccia testuale di controllo del kernel si chiama ipchains. Il comando iptables è un’evoluzione di ipchains, di cui eredita la filosofia operativa e buona parte della sintassi di funzionamento.

Realizzazione del firewall Per capire i passaggi di costruzione di un firewall, si farà riferimento al caso di una piccola azienda dotata di dieci postazioni, un server e un accesso a Internet tramite una rete cittadina. Questa rete metropolitana funziona su fibra ottica, ma nella parte terminale, all’interno dei fabbricati degli utenti finali, vi è un trasduttore che converte il segnale ottico in un segnale elettrico compatibile con Ethernet. Non è però consigliabile collegare alla rete locale il plug fornito dal provider. Sussiste un serio rischio, dal momento che non vi è alcun filtro di sicurezza tra le due reti. Poi ci saranno certamente anche alcuni problemi pratici da risolvere quali l’instradamento tra due sottoreti IP differenti. Serve prima di tutto un router in grado di smistare le comunicazioni tra la LAN e Internet. Si tratta tipicamente di un apparato hardware, ma è possibile in questo caso usare la stessa macchina Linux come firewall e router. Si risparmia sui costi e si incrementa efficienza e sicurezza (Capitolo 6). Non serve un sistema particolarmente prestante. Basta anche una postazione dimessa, con un processore di qualche anno, 2 GB di RAM, disco fisso da 20 GB e CD-ROM. Su questo sistema va installata la distribuzione Linux in modalità base, senza ambiente grafico, applicazioni di produttività e servizi server: niente FTP, server web, newsgroup, mail e così via. Un firewall è tanto più sicuro quanto meno servizi sono in esecuzione nel sistema. Sul computer dovranno essere montate due schede di rete che saranno gestite da Linux come eth0 ed eth1. Su eth0 sarà collegata la rete locale interna, mentre su eth1 sarà collegato il cavo dati verso Internet. Conviene inserire queste due schede prima della fase di installazione di Linux. La scheda connessa alla rete locale dovrà avere un IP appartenente alla LAN. La scheda connessa a Internet dovrà avere l’IP pubblico e il gateway assegnato dal provider. Eventualmente queste informazioni potrebbero essere fornite tramite il DHCP del provider. Le regole di sicurezza sono invece realizzate inserendo sequenze di comandi iptables all’interno di un file che viene eseguito automaticamente a ogni avvio del computer (questo problema era stato esaminato nel capitolo relativo ai router).

Prima di iniziare a digitare i comandi bisogna conoscere qualche dettaglio tecnico sul funzionamento del firewall di sistema di Linux. Innanzitutto si deve sapere che il meccanismo opera inserendo tutti i pacchetti in tre catene distinte, denominate INPUT, OUTPUT e FORWARD. Nella catena di INPUT passano tutti i pacchetti che arrivano dall’esterno e che sono destinati al sistema locale. Nella catena OUTPUT passano invece i pacchetti che partono dal sistema locale e sono indirizzati verso il mondo esterno. Nella catena FORWARD sono inseriti i pacchetti in transito da una scheda di rete verso un’altra: per esempio un pacchetto arrivato dall’esterno su una scheda di rete e poi inoltrato sulla rete locale tramite un’altra scheda di rete. Ogni singolo pacchetto viene valutato in base alle regole inserite su queste catene dall’amministratore. Le regole sono valutate in sequenza, una dopo l’altra. Quando il pacchetto soddisfa una regola, viene applicato il comportamento specificato. Ci sono tipicamente due comportamenti: ACCEPT e DROP. Il pacchetto può cioè essere accettato o scartato. Se nessuna regola si applica al pacchetto, viene applicata una regola di default, che ancora una volta può essere ACCEPT o DROP. Sfruttando queste nozioni di base è già possibile la costruzione di qualche regola. Prima di tutto conviene azzerare preventivamente le catene ed evitare di avere malfunzionamenti per via di regole avanzate da qualche configurazione o test precedente: iptables –F

L’opzione -F, da digitare in maiuscolo, esegue il cosiddetto flushing, ovvero la cancellazione di tutte le regole precedentemente impostate. Si può affiancare questo comando di cancellazione a un secondo che elimina eventuali catene personalizzate create dall’utente. Oltre alle catene standard è infatti possibile crearne delle proprie per motivi di ordine o necessità. Per evitare che qualcuna di queste catene resti attiva per errore si deve digitare il seguente comando: iptables –X

In seguito si deve decidere che politica usare nella costruzione del firewall. Vi sono due strade. In un caso è possibile lasciare aperto ogni passaggio e impostare alcune regole per stabilire che cosa non ha il permesso di attraversare le due reti. È possibile anche l’approccio inverso, chiudere cioè tutte le vie di accesso e specificare quale tipo di traffico può attraversare il firewall. Il primo metodo è certamente più pericoloso perché non è detto che si conoscano a priori tutti i pericoli che si intende fronteggiare. È molto meglio chiudere tutto e abilitare solamente ciò che realmente serve per la propria realtà. La politica del firewall può essere implementata attraverso i comandi che regolano il comportamento di default della catena: iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP

L’opzione -P serve per stabilire il comportamento predefinito di ogni catena. Si può notare che tutti i pacchetti in ingresso (INPUT) e quelli in transito (FORWARD) vengono bloccati (DROP). È invece permesso il traffico dall’interno (OUTPUT con regola ACCEPT). Nella creazione delle regole è importante ricordare che i comportamenti di default sono i primi da indicare nel file di configurazione, ma sono gli ultimi a essere considerati dal sistema in fase di funzionamento. Prima di tutto, infatti, si valutano in sequenza tutte le regole impostate dall’amministratore. Se una di queste regole si applica al pacchetto in esame, viene applicato il relativo comportamento, altrimenti si esegue il comportamento

predefinito. Le tre regole precedenti impediscono qualunque tipo di traffico in ingresso o in transito da una scheda all’altra. Nulla potrà quindi entrare nel sistema o attraversarlo. A questo punto bisogna stabilire se è permesso qualche tipo di accesso dall’esterno. Nell’esempio considerato non esiste alcun server interno che debba essere visibile esternamente. Può invece risultare utile la possibilità di accedere da remoto alla macchina Linux per eseguire manutenzione tramite SSH. Bisogna quindi aprire la porta 22, protocollo TCP: iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Il parametro dport richiede il simbolo -- e deve seguire l’opzione –p per la specifica del protocollo. Eventualmente si possono scrivere regole che tengano in considerazione anche la porta sorgente tramite -sport. Un’altra porta da attivare è la 53, usata dal servizio DNS per rispondere alle richieste di risoluzione nomi: iptables -A INPUT -p tcp --dport 53 -j ACCEPT

A questo punto bisogna permettere alla rete locale di dialogare con il firewall, altrimenti la LAN risulterebbe del tutto isolata: iptables -A INPUT -i eth0 -j ACCEPT

Bisogna invece interdire qualunque tentativo di contatto dal mondo esterno con pacchetti che hanno come indirizzi di origine un valore appartenente alla propria rete locale privata. È facile riconoscere questa condizione, perché gli standard prevedono tre gruppi di indirizzi che possono essere usati solamente per le reti interne. Si tratta di valori che non possono appartenere al mondo esterno. I router sulla rete Internet mondiale sono programmati per scartare questi pacchetti. Nessun indirizzo privato può circolare all’esterno di una LAN. Tabella 7.1 Classi di indirizzi privati per uso interno.

Classe A Da 10.0.0.0 a 10.255.255.255. Classe B Da 172.16.0.0 a 172.31.255.255 Classe C Da 192.168.0.0 a 192.168.255.255 Perché controllare una condizione che in realtà non può verificarsi in base agli standard? Questo perché su Internet potrebbero esserci router configurati in maniera errata, ma anche utenti malintenzionati, intenti a inoltrare in LAN pacchetti con indirizzo sorgente contraffatto. L’obiettivo in tal caso è ingannare la rete locale con pacchetti apparentemente regolari, che in realtà provengono dall’ambiente esterno. La contraffazione dell’indirizzo, denominato spoofing, è la base di molti tipi di attacco. Per eliminare questo problema è sufficiente inserire una serie di regole che scartino i pacchetti provenienti dall’esterno dotati di un indirizzo interno: Listato 7.1

# classe iptables iptables # classe iptables iptables

A -A -A B -A -A

INPUT -s 10.0.0.0/8 -i eth1 -j DROP FORWARD -s 10.0.0.0/8 -i eth1 -j DROP INPUT -s 172.16.0.0/12 -i eth1 -j DROP FORWARD -s 172.16.0.0/12 -i eth1 -j DROP

# classe C iptables -A INPUT -s 192.168.0.0/16 -i eth1 -j DROP iptables -A FORWARD -s 192.168.0.0/16 -i eth1 -j DROP

Il parametro -s serve per indicare l’indirizzo o la rete sorgente. Per la destinazione si utilizza invece il parametro -d. Con il parametro -i si indica invece l’interfaccia di input (valido nelle catene INPUT e FORWARD). Il suo opposto, per indicare l’interfaccia di output, è -o (valido in OUTPUT e FORWARD). Per sicurezza si dovrebbero scartare anche gli indirizzi delle classi speciali D (ambito multicast) ed E (ambito riservato): iptables -A INPUT -s 224.0.0.0/3 -j DROP iptables -A FORWARD -s 224.0.0.0/3 -j DROP

Seguendo lo stesso principio, si devono scartate i pacchetti che arrivano dall’esterno con l’indirizzo sorgente uguale al loopback: iptables -A INPUT -s 127.0.0.1 -i eth1 -j DROP iptables -A FORWARD -s 127.0.0.1 -i eth1 -j DROP

Questo indirizzo è standard e viene applicato di default dal sistema operativo all’interfaccia di rete locale. Si tratta di un IP che rimanda alla macchina stessa. Bisogna ora aprire in ingresso le porte necessarie al funzionamento degli applicativi sui client presenti in rete. Quando un browser su un client interno desidera accedere a un sito esterno, per esempio www.incipit.biz, lancerà la richiesta all’indirizzo IP del sito puntando alla porta di destinazione 80. Il pacchetto non contiene però solo una porta di destinazione, ma anche una di sorgente, compresa tra 1024 e 65.535 (la gamma di porte applicative generiche). Serve infatti una porta per le risposte dal server web al client locale. Questa porta non può essere la numero 80, perché il sistema locale potrebbe a sua volta avere un server web attivo. Viene quindi scelta una porta tra la gamma di porte applicative generiche. Questa porte devono essere aperte sul firewall: iptables -A INPUT -i eth1 -p tcp --dport 1024:65535 -j ACCEPT iptables -A INPUT -i eth1 -p udp --dport 1024:65535 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -j ACCEPT

Le prime due righe attivano il traffico in ingresso su TCP e UDP, mentre la terza abilita il protocollo di controllo ICMP. Questo non ha il concetto di porte e quindi non deve essere specificato il parametro -dport. Devono invece essere chiuse le porte entro la 1023, perché sono utilizzate da servizi critici di sistema come Telnet, FTP, Web, condivisione Windows e così via. Dal momento che la regola di default per l’ingresso prevede che il traffico sia chiuso, le porte critiche sono quindi protette. Un ulteriore controllo consiste nel determinare se un particolare flusso di dati è stato attivato dall’interno (per esempio da un utente che ha lanciato una sessione Telnet su un server esterno) o dall’esterno (per esempio quando un nodo remoto tenta di accedere mediante il servizio FTP a una macchina della propria rete). Si deve in tal caso controllare lo stato del flag syn del pacchetto TCP. Questo bit è attivo quando viene instaurata una nuova connessione. Impedendo a questi pacchetti di accedere si impedisce che possano essere attivate connessioni TCP sulla scheda di rete connessa a Internet. Questa è la sintassi: iptables -A INPUT -i eth1 –p tcp --syn -j DROP

Il parametro --syn non ha senso in protocolli che non siano TCP. Si noti che attraverso la riga precedente si potrà comunque instaurare connessioni TCP verso l’esterno.

Stateful inspection Una delle novità più importanti introdotte su iptables è la possibilità di verificare un pacchetto in base al suo stato. Il protocollo TCP durante il funzionamento instaura una sessione. Viene cioè attivato un canale tra due punti (il mittente e la destinazione) e questo canale è costantemente controllato da una serie di flag di stato. Ogni pacchetto TCP in arrivo o in transito sul sistema può quindi essere abbinato a una precisa connessione. In questo modo è possibile costruire regole che, per esempio, tengano conto del verso della comunicazione e fare in modo che i pacchetti in ingresso possano accedere a qualunque macchina o a qualunque porta, purché la connessione sia originata dall’interno. Questa categoria di controlli non è standard, ma eseguibile tramite una sorta di plug-in. Il sistema firewall di Linux dispone infatti di un’architettura estensibile, grazie alla quale è possibile aggiungere moduli per la realizzazione di compiti specifici. Molti di questi moduli sono già disponibili nel pacchetto base di iptables. È possibile scorrere la lista dei moduli e conoscere le relative funzionalità nelle pagine man del comando (man iptables dalla linea di comando) alla sezione MATCH EXTENSIONS. Il controllo sullo stato della connessione avviene con un modulo di iptables denominato state. Basta quindi comporre una riga di controllo attivando questo modulo con l’opzione -m: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

In questo caso si permette a un pacchetto TCP di attraversare la catena INPUT, nel caso in cui faccia parte di una sessione già aperta (ESTABLISHED) o che abbia relazione con questa sessione (RELATED), per esempio una segnalazione di errore sul flusso TCP tramite il protocollo ICMP. Esistono altre due condizioni che possono essere testate dal modulo state: NEW, per indicare una nuova connessione, e INVALID, per pacchetti che non possono essere identificati. È importante eseguire il controllo di sessione all’interno di un firewall perché esistono forme di attacco in cui l’utente malintenzionato esterno cerca di veicolare pacchetti sulla LAN mascherandoli come pacchetti che fanno parte di flussi dati regolarmente abilitati.

Misure contro i DoS Un altro modulo iptables prevede la possibilità di conteggiare certe condizioni e di attivare allarmi o azioni specifiche in base al numero di occorrenze della condizione stessa. Il campo di applicazione di questo modulo riguarda gli attacchi di tipo DoS (Denial of Service), dove si cerca di esaurire qualche tipo di risorsa locale intasando il sistema con un numero elevato di richieste. Il caso più comune è il flood di ping, una vera e propria “inondazione” di pacchetti ICMP che comporta consumo di banda e di risorse del server intento a rispondere. Un’altra forma di attacco DoS riguarda l’apertura di un numero elevato di sessioni TCP senza però far seguire alcuna transazione o il completamento della stessa. Il server allocherà in tal caso risorse per ogni singola connessione, consumando progressivamente la memoria disponibile per le operazioni di rete. Queste situazioni si risolvono con il modulo limit e un esempio renderà subito chiaro l’utilizzo: iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 2/s -j ACCEPT

Il comando controlla la catena INPUT e verifica il protocollo ICMP alla ricerca di un pacchetto di tipo echo-request. Si tratta in sostanza di un ping in arrivo dall’esterno. Ping è infatti il nome comune per un pacchetto echo-request del protocollo di segnalazione ICMP. La risposta al ping si chiama invece tecnicamente echo-reply. L’opzione -m attiva il modulo limit con l’opzione --limit 2/s per indicare due pacchetti al secondo. Fino a quando si opera entro il limite di due pacchetti al secondo la regola è soddisfatta e il pacchetto viene accettato. Superato il limite la regola smette di essere soddisfatta. Si può quindi aggiungere una regola successiva di DROP per eliminare tutti i pacchetti ping successivi: iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Questo permette al sistema locale di rispondere ai ping e di terminare ogni attività in caso di flood. Bisogna però puntualizzare un fatto importante. Il server non risponderà ai ping in caso di flood, ma sarà comunque attaccato, in quanto vi sarà ugualmente il traffico sul confine del firewall e il sistema in qualche modo gestirà la situazione a livello del kernel. Questa protezione si rivela invece efficace quando il controllo viene fatto sulla catena FORWARD. In questo modo si evita che il flood entri sulla LAN e sui server presenti all’interno. Solo il firewall sarà oggetto dell’attacco e non i sistemi interni. Altri attacchi di tipo flood possono invece essere fronteggiati in maniera più efficace sulla scheda esterna del firewall. Per esempio il bloccaggio di un numero elevato di sessioni TCP in ingresso può efficacemente impedire l’esaurimento delle risorse locali. Prima di proseguire bisogna fare una valutazione pratica. Considerando il modo in cui sono state inserite le regole sulla macchina Linux, le righe di protezione per il flood da ping non avranno alcun effetto. Precedentemente, nella catena INPUT è stata infatti inserita la seguente regola: iptables -A INPUT -i eth1 -p icmp -j ACCEPT

Questa farà passare tutti i ping invalidando qualunque regola seguente. Non si deve mai dimenticare che appena un pacchetto soddisfa una regola, questo viene tolto dalle catene di valutazione, rendendo inutili le eventuali righe successive che possono essere soddisfatte dallo stesso pacchetto. Se si vuole eseguire il controllo del ping flood, bisogna prima eliminare dalla memoria la regola precedente, con l’opzione -D: iptables -D INPUT -i eth1 -p icmp -j ACCEPT

Masquerading Fino a questo punto sono state inserite diverse regole di protezione, ora bisogna fare in modo che le due sottoreti possano comunicare. La rete locale è infatti definita attraverso un indirizzamento di classe C, mentre l’accesso a Internet avviene con un indirizzo pubblico. Queste reti non possono dialogare tra loro, in quanto si trovano in sottoreti differenti. C’è poi un secondo problema: si ha un numero variabile di indirizzi IP privati interni, mentre si possiede un unico indirizzo pubblico per accedere a Internet. Tutte le richieste emanate dalle macchine interne verso Internet dovranno essere prima tradotte nell’unico indirizzo pubblico disponibile. Servirà anche un meccanismo che tenga traccia di tutte le comunicazioni e faccia in modo che le risposte di ritorno da Internet siano recapitate ai giusti client interni. Questa operazione si chiama masquerading. Il kernel di Linux fornisce i meccanismi per l’istituzione del masquerading e tutte le operazioni di configurazione avvengono tramite iptables. Fino a questo momento si è usato iptables per la gestione delle regole di firewall. Queste regole sono state

scritte agendo sulle catene INPUT, OUTPUT e FORWARD. Queste fanno parte dell’insieme di tabelle definite filter. L’impiego di queste tabelle è di default, ma se si ha la necessità di usare iptables per gestire il masquerading bisogna specificare la volontà di utilizzare le tabelle NAT. Queste sono PREROUTING, POSTROUTING e OUTPUT. Per specificare comandi che agiscono su tabelle diverse da filter bisogna usare il parametro -t: iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Questo comando fa in modo che tutti i pacchetti in uscita verso Internet assumano l’indirizzo della scheda di rete in uscita eth1 tramite il meccanismo del masquerading. Prima di impartire questo comando bisogna però aggiungere due regole per abilitare il transito sulla catena di FORWARD, altrimenti i pacchetti non potrebbero provenire da eth0 (LAN) e poi uscire su eth1 (Internet) e viceversa: iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

La prima riga permette il forward dall’esterno verso l’interno solo a pacchetti di sessioni già stabilite dall’interno. La seconda riga permette il transito dall’interno verso l’esterno a tutte le connessioni. È importante, infine, aggiungere anche questo comando: echo 1 > /proc/sys/net/ipv4/ip_forward

Questa riga non ha nulla a che fare con Netfilter, iptables e il firewall. È semplicemente un comando che attiva il routing tra le schede di rete sul kernel. Si tratta di una funzionalità che dovrebbe essere già attiva sul sistema, ma che si consiglia di specificare in fondo al file di startup del sistema. Maggiori informazioni sull’uso di iptables per le funzioni di router sono contenute nel Capitolo 6.

Un metodo più semplice: SmoothWall Le regole di filtro impostate finora sono sufficienti per mettere in opera un piccolo firewall, ma bisogna ammettere che il lavoro è impegnativo e tecnico. Risulta anche molto semplice tralasciare qualcosa di importante o commettere errori. Prima di procedere, sarebbe bene eseguire il comando man iptables per prendere visione delle numerose opzioni disponibili ed è anche utile leggere l’howto scritto dall’autore di Netfilter all’indirizzo web http://www.netfilter.org/documentation/HOWTO/it/packet-filtering-HOWTO.html, con particolare attenzione alla sezione relativa al firewall. Si consiglia anche di leggere http://www.netfilter.org/documentation/HOWTO/it/NAT-HOWTO.html per comprendere meglio le funzioni di NAT. Le difficoltà non finiscono comunque nella comprensione di NetFilter e iptables. Usando distribuzioni generiche non è semplice regolare tutti i parametri di sistema. Una distribuzione commerciale installa inoltre centinaia di pacchetti e decine di servizi. Un firewall non ha bisogno di tutto questo codice in esecuzione; piuttosto viene danneggiato da tale quantità di programmi. Ognuno di questi rischia infatti di essere il bersaglio di qualche cracker alla ricerca di falle di sicurezza. Bisogna quindi puntare ad avere un ambiente con il numero minimo di applicazioni in esecuzione. Non è però sensato procedere a “ripulire” manualmente un’installazione generica. È piuttosto meglio rivolgersi a una distribuzione specifica per le funzioni di firewall, come il progetto SmoothWall, www.smoothwall.org (Figura 7.5).

Figura 7.5 Pagina w eb ufficiale di Smoothw all Express.

SmoothWall è una distribuzione che esegue le funzioni di firewall e routing. L’implementazione è minimale e nel sistema sono installati solamente i moduli e i programmi strettamente necessari alla protezione. La configurazione del sistema avviene con semplici menu in fase di installazione e poi attraverso un’interfaccia web per le operazioni successive di configurazione e messa a punto. Tutta la configurazione delle regole di sicurezza e degli schemi di routing è costruita automaticamente da SmoothWall. L’utente può così tralasciare tutti i dettagli tecnici e concentrarsi unicamente sulla struttura di rete che intende realizzare. Il progetto è attivo da molti anni e vanta oggi una forte stabilità e una base utenti estremamente ampia. Il gruppo di sviluppo provvede inoltre a mantenere il sistema sempre aggiornato e a rilasciare le patch di sicurezza ogni volta che vengono pubblicati bollettini di sicurezza critici. SmoothWall richiede un PC dedicato allo scopo. Durante l’installazione, tutti i dati precedentemente presenti saranno infatti eliminati. Il PC può essere anche molto modesto, ma servono due schede di rete: una connessa alla rete interna, denominata Green, e una connessa a Internet, denominata RED. La prima operazione da compiere è scaricare l’ultima versione del prodotto presso il sito di SmoothWall all’indirizzo http://www.smoothwall.org/get. SmoothWall viene distribuito in formato ISO nelle versioni a 32 e a 64 bit, pronto per essere masterizzato. Si inserisce il disco nel drive e si riavvia la macchina. Il sistema eseguirà il boot con una versione minimale di Linux in memoria e comincerà la procedura di installazione. Un messaggio richiederà che venga inserito il CD-ROM. Bisogna quindi premere Invio nuovamente per confermare. La procedura è distruttiva, in quanto il disco fisso sarà ripartizionato e poi formattato in modalità EXT3. I

dati in esso presenti saranno irrimediabilmente persi. Un messaggio segnalerà questo fatto, richiedendo una conferma (Figura 7.6).

Figura 7.6 L’installazione di SmoothWall azzererà il contenuto del disco fisso.

Premendo Invio i file di sistema saranno copiati nel computer locale. La procedura è estremamente rapida e richiede pochi istanti. Una finestra di congratulazioni segnala il completamento della fase iniziale di configurazione e il CD-ROM viene espulso. Ora bisogna configurare il firewall. Prima viene richiesto se si vuole ripristinare un’installazione precedente di SmoothWall. Il sistema permette infatti di creare un floppy o un file immagine con tutta la configurazione. In caso di guasto al computer è così possibile ripristinare il sistema in maniera estremamente rapida. Trattandosi di una nuova installazione non si ha alcuna configurazione precedente da ripristinare. Si deve quindi scegliere No. La configurazione del sistema avviene per passaggi. Prima di tutto viene richiesta la mappa di tastiera utilizzata. Si deve scorrere la lista e scegliere la mappa in uso. Il passaggio seguente riguarda l’inserimento del nome della macchina (hostname). Si consiglia di usare nomi minuscoli che non inizino con numeri. È ammesso il segno meno nel nome, ma non altri simboli. Una volta impostato il nome, viene richiesto se si vuole avere il firewall aperto (con tutte le comunicazioni ammesse), chiuso (con tutte le comunicazioni interdette) oppure se si desidera una soluzione intermedia, con una politica di blocco in ingresso sui servizi critici. Si consiglia quest’ultima impostazione, confermando con Ok. Il passaggio seguente è molto importante e riguarda gli aspetti di rete. Prima di tutto si deve andare in Network Configuration Type e selezionare il tipo GREEN + RED. Si ritorna automaticamente al menu principale. Si deve quindi scegliere la voce Drivers and card assignments e poi il pulsante Probe per attivare il riconoscimento dell’hardware. Dopo alcuni istanti saranno visualizzati i risultati dell’operazione, con il nome dei driver che saranno caricati. Si dovrà scegliere Ok per confermare. I driver dovranno essere associati alle schede GREEN e RED attraverso la schermata successiva. Infine un messaggio indicherà che tutte le schede di rete sono state allocate. È fondamentale che le schede di rete siano compatibili con Linux. I chip Realtek, Intel e 3Com sono generalmente supportati. Completata questa fase si ritorna sul menu di configurazione di rete e si sceglie Address Setting per impostare i dati delle schede di rete. La scheda GREEN dovrà avere un IP compatibile con la rete locale. Questa scheda sarà il default gateway per le macchine interne. La scheda RED dovrà invece avere i dettagli IP per

accedere su Internet tramite un router oppure una connessione broadband. Completata l’assegnazione degli indirizzi si seleziona Done, ritornando nel menu di configurazione di rete. Per concludere, si deve andare nel menu DNS and Gateway settings per impostare i valori dei DNS pubblici e del gateway verso Internet. Completata la configurazione di rete si deve scegliere Ok e poi Done. Compare un nuovo menu, da cui è possibile impostare i parametri per un eventuale proxy, per l’eventuale accesso ISDN verso Internet, per l’eventuale accesso ADSL verso Internet e per impostare il DHCP. SmoothWall è in grado di funzionare con adattatori ISDN o con modem ADSL. La macchina diventa in tal caso il router per questi tipi di connessione. Nel caso in esame si ha una seconda scheda di rete connessa direttamente a Internet e quindi non si deve operare alcuna configurazione in merito. Nel caso di accesso ADSL si sconsiglia di usare un modem e di optare sempre per un router. I costi sono oggi accessibili e si risolvono diversi problemi di compatibilità su Linux. La procedura di installazione è completata. Scegliendo Finished ci si troverà a un nuovo pannello di configurazione, dove sono richieste le password per gli utenti admin e root. L’utente root è standard di Linux e può eseguire qualunque operazione nel sistema, mentre l’utente admin è in grado di accedere al pannello web di SmoothWall e alterare le configurazioni del firewall. Completato l’inserimento della password si avrà il riavvio del sistema e la sua prima attivazione.

Schede per impostare le opzioni di funzionamento La procedura testuale eseguita ha permesso di creare un firewall in pochi minuti. Tutte le operazioni di manutenzione e di configurazione possono ora essere eseguite via Web (Figura 7.7). Nell’ipotesi che il firewall si trovi all’indirizzo 192.168.0.100 basta andare su una qualunque delle macchine interne e digitare nel browser http://192.168.0.100:81 (il firewall per ragioni di sicurezza non risponde all’indirizzo web standard, ma alla porta 81 oppure alla porta 441 nel caso si acceda con HTTPS).

Figura 7.7 Schermata principale di SmoothWall Express 3.0.

SmoothWall Express è totalmente configurabile via Web attraverso una serie di pannelli intuitivi richiamabili da menu. Tutte le azioni eseguite sull’interfaccia grafica influenzano in maniera automatica le configurazioni del sistema Linux sottostante e dei pacchetti di contorno. Non diventa più necessario accedere direttamente alla macchina e quindi si potrebbe scollegare monitor e tastiera e anche sistemare l’unità in un luogo poco accessibile: dentro un armadio, in uno sgabuzzino e così via. Accedendo a SmoothWall saranno richieste le credenziali per l’utente admin precedentemente specificate e sarà visualizzata una schermata riepilogativa corrispondente al menu Control. Questa evidenzia la banda istantanea e il livello di utilizzo del canale dati nel corso della giornata e del mese. La banda passante in ingresso e in uscita è visualizzata anche in forma grafica.

About Il menu about contiene molte schede informative. La sezione Status evidenzia i servizi in esecuzione, la sezione Advanced mostra un numero elevato di informazioni di sistema (memoria, dischi, inode, uptime, utenti, interfacce, routing, elementi hardware, moduli e versione del kernel), la sezione Trafic graphs presenta un riepilogo sul traffico in formato numerico e grafico, la sezione Bandwidth bars visualizza grafici in tempo reale relativamente all’utilizzo della banda, la sezione Traffic Monitor visualizza in tempo reale grafici sul traffico presso gli adattatori presenti (Figura 7.8). L’ultima sezione, My smoothwall contiene informazioni riassuntive.

Figura 7.8 I dati sul traffico sono aggiornati in tempo reale.

Services La scheda services contempla molte voci. È possibile sia attivare un proxy e avere il caching locale dei contenuti, come pure impostare i parametri del proxy relativamente all’instant messaging, il POP3 e il protocollo di telefonia su IP SIP. Il proxy sul POP3 è interessante, perché permette di attivare un meccanismo antivirus per la ricerca di minacce sulla posta elettronica. Sono inoltre disponibili i servizi DHCP e DNS, quest’ultimo in modalità statica e dinamica. Si consiglia vivamente di usare il sistema IDS e beneficiare così di funzionalità aggiuntive di sicurezza. Il sistema integrato su SmoothWall si basa su Snort (www.snort.org) e permette di avere un controllo di sicurezza sulla semantica della comunicazione. Snort dispone di una serie di firme che rappresentano un certo numero di forme comuni di attacchi strutturati. Tutto il traffico viene verificato in base a queste firme ed eventuali attacchi vengono automaticamente rilevati. Sui log sarà possibile visualizzare l’attività di questo componente. SmoothWall non include le firme di Snort, che dovranno essere richieste presso il sito di Snort. È molto importante andare in Remote Access e attivare SSH. Solo in questo modo sarà possibile accedere dall’esterno in modalità terminale e avere pieno accesso alla macchina. Questa impostazione non è però sufficiente. Bisogna infatti eseguire anche un’impostazione nella scheda networking. Con la scheda Time è possibile sincronizzare l’orologio di SmoothWall con una fonte oraria certa.

Networking La scheda networking è una delle più importanti per la configurazione di SmoothWall perché stabilisce il modo in cui le comunicazioni possono attraversare le due schede di rete. Bisogna prestare attenzione alle linguette Incoming e Outgoing. La prima permette di impostare regole di forward, ovvero inoltri di traffico originati dall’esterno e indirizzati verso un nodo IP interno della LAN. Questo

è necessario se si dispone, per esempio, del server web sulla LAN (invece che all’esterno, con un IP pubblico) e si vuole fare in modo che il traffico verso la porta 80 in arrivo sul firewall venga inoltrato verso questa macchina. Per costruire una regola si deve specificare il protocollo di comunicazione (TCP o UDP), la porta in External source IP, l’indirizzo IP della macchina interna che ospita il servizio in Destination IP e l’eventuale porta rimappata (se per esempio il servizio web gira sulla porta 8080 invece che sulla 80) in Destination Port. Poi si fa clic su Add. La scheda Outgoing permette di specificare il modo in cui è gestito il traffico dall’interno verso l’esterno. Si può specificare se tutto il traffico è permesso, a esclusione di alcune eccezioni, oppure il contrario, se tutto il traffico in uscita è bloccato, a meno di particolare eccezioni. La modalità prescelta si specifica con la prima tendina dall’alto. Una volta scelta la politica, si deve procedere con l’eccezione, specificando per esempio quale porta è bloccata oppure permessa. Si può così regolare in maniera molto precisa quale tipo di attività è permessa su Internet. In fondo alla scheda è presente una sezione dove indicare le macchine che possono comunque accedere all’esterno a prescindere dalle regole (Figura 7.9).

Figura 7.9 Pannello Outgoing di SmoothWall Express.

La sezione Internal si utilizza quando si dispone di una DMZ e si vuole specificare quale traffico è abilitato

ad attraversare la zona protetta della LAN. In External Access vanno indicate le porte dei servizi che possono accedere all’area interna. Non basta infatti specificare una regola di forward, ma bisogna anche aprire la porta sul firewall da questa sezione (Figura 7.10).

Figura 7.10 Pannello per l’apertura delle porte esterne sul firew all.

In IP Block si può interdire l’accesso a particolari sistemi. Basta inserire l’indirizzo IP e questo non potrà più comunicare. È possibile, in tale evenienza, scartare i pacchetti (drop) oppure respingerli al mittente (reject), eventualmente registrando l’evento sui log. Il pannello Timed access è una novità della versione 3.0 di SmoothWall e permette di impostare le fasce orarie in cui gli utenti interni possono accedere a Internet. Anche il pannello QoS è una novità attraverso cui implementare un sistema di traffic shapping, ovvero di prenotazione della banda passante per protocolli specifici. Si può indicare nella parte superiore la banda ammessa in ingresso e in uscita e poi, sotto, specificare un livello di priorità per i servizi indicati. I servizi a priorità maggiore avranno più banda rispetto ai servizi a priorità inferiore. Il pannello Advanced ospita alcune funzionalità evolute di sicurezza (Figura 7.11) attraverso cui filtrare particolari tipi di traffico. Tramite Block ICMP ping si impedisce a SmoothWall di rispondere ai ping, Block and ignore IGMP packets ignora tutti i messaggi IGMP, Enable SYN cookies impedisce che un utente malintenzionato possa sferrare un attacco di tipo DoS aprendo un grande numero di sessioni TCP. Si tratta di una forma comune di attacco volto a esaurire le risorse, annullando la capacità del sistema di smistare ulteriori comunicazioni.

Figura 7.11 Nella scheda Advanced si possono impostare alcune funzionalità avanzate di sicurezza.

Block and ignore multicast traffic impedisce il transito di pacchetti multicast, mentre Enable UPnP attiva il supporto al protocollo Universal Plug’n’Play. Con la tendina in basso a destra si specifica se ignorare questi eventi (drop) o se inoltrare una comunicazione al mittente (reject). Prima di uscire è necessario fare clic su Save. La scheda PPP permette di impostare le regole di accesso alle connessioni in dial-up o eseguite con modem ISDN o ADSL (Figura 7.12). L’ultima scheda, Interfaces, è molto utile e permette di cambiare gli indirizzi IP e le maschere delle schede di rete, oltre che impostare il default gateway sulla RED e gli indirizzi dei DNS.

Figura 7.12 Pannello per la configurazione degli accessi in PPP.

VPN Le schede control e connections permettono di realizzare il tunneling VPN in IPSec tra due installazioni SmoothWall, al fine di realizzare una rete geografica (Figura 7.13). Al loro interno è possibile specificare i dettagli tecnici delle due estremità del tunnel e quelli necessari per attivare la comunicazione. Questi dettagli saranno tratti nel prossimo capitolo.

Figura 7.13 Pannello per la configurazione delle VPN IPSec.

Logs Il pannello permette di visionare i log di sistema (per esempio i messaggi del kernel o del PPP), del proxy, del firewall, del sistema IDS, dell’instant messaging e della mail (Figura 7.14). È interessante la sezione del Firewall, in quanto è possibile richiedere la risoluzione di un indirizzo IP in nome (tramite il pulsante di lookup) o aggiungere direttamente un indirizzo visualizzato sul log nella lista degli IP da bloccare. I log vengono ruotati quotidianamente.

Figura 7.14 Pannello dei log.

Tools

Tramite il pannello Tools è possibile fare una ricerca nel database whois e avere informazioni su un particolare dominio oppure fare ping o traceroute (Figura 7.15). È molto interessante la scheda shell, da cui è possibile disporre di un terminale SSH Java e accedere alla shell del proprio firewall dalla finestra.

Figura 7.15 Pannello w eb con una shell per l’accesso a SmoothWall in modalità SSH.

Maintenance La più importante scheda di maintenance è updates. Qui è possibile scoprire se sono disponibili patch correttive facendo clic su Check for updates. Ogni riga di update contiene la descrizione della correzione, la data di rilascio, la dimensione e il link al sito di SmoothWall dove la patch è memorizzata (Figura 7.16). È così possibile scaricare il file e inserirlo immediatamente nel sistema tramite Sfoglia e poi upload. Bisogna ricordarsi di riavviare il sistema dopo l’inserimento delle patch. La scheda Modem permette di impostare le stringhe per i modem analogici e IDSN, mentre la scheda successiva permette di caricare il firmware dei modem SpeedTouch di Alcatel/Thompson nella SmoothWall. In questo modo il firewall può utilizzare uno di questi modem come interfaccia di uscita. Nella scheda passwords è possibile cambiare la password degli utenti admin e dial, credenziale usata nelle connessioni standard a Internet. Con backup si può invece salvare su un floppy formattato tutta la configurazione di SmoothWall. Il floppy deve essere inserito nel computer che ospita SmoothWall, non nel computer con cui si sta visualizzando la scheda del firewall. Nel caso in cui non si abbia accesso fisico al computer che ospita la SmoothWall, si può utilizzare Create backup floppy image file per salvare il file image nel computer locale. Bisogna in tal caso ricordarsi che questa immagine dovrà comunque essere scritta su un floppy nel caso in cui sia necessario recuperare un’installazione. Per trasferire l’immagine si può usare

RawWriteWin, disponibile all’indirizzo http://www.chrysocome.net/rawwrite. La scheda Preferences permette di specificare se si vogliono avere i menu a tendina nell’interfaccia utente della SmoothWall. Il pannello Shutdown permette di spegnere o riavviare il sistema. Tutte le schede di configurazione web sono corredate di help in linea, ma esistono anche alcuni file PDF che illustrano le operazioni di installazione e di gestione del sistema. Questa documentazione, molto ben realizzata, è disponibile all’indirizzo http://www.smoothwall.org/get.

Figura 7.16 Pagina per la gestione degli aggiornamenti di SmoothWall Express.

Configurazione dei client La configurazione dei client Windows è estremamente semplice. Basta accedere alle proprietà di rete, scheda Generale del TCP/IP e indicare che il gateway predefinito per la propria rete è l’ indirizzo interno (Green) della macchina SmoothWall (Figura 7.17). Nessun’altra operazione è necessaria e si può iniziare a utilizzare le risorse Internet in piena sicurezza.

Figura 7.17 Pannello di configurazione di rete del client W indow s.

Checklist Firewall con una distribuzione standard di Linux 1. Recuperare un PC e installare due schede di rete. 2. Collegare una scheda di rete allo switch della propria rete locale e l’altra al router per l’accesso esterno. Verificare in questa fase di usare i cavi corretti (alcune connessioni potrebbero richiedere un cavo di rete cross-over). 3. Aprire lo script di avvio della propria distribuzione. 4. Scrivere le regole predefinite per le catene di default (INPUT, OUTPUT e FORWARD). 5. Abilitare le porte relative ai servizi che si vogliono pubblicare (per esempio SSH). 6. Scrivere le regole per scartare i pacchetti esterni che abbiano come origine gli indirizzi interni (regole antispoofing). 7. Scrivere le regole per scartare pacchetti esterni che abbiano l’indirizzo di loopback 127.0.0.1 (regole antispoofing). 8. Scrivere le regole per permettere l’accesso dall’esterno alle porte di servizio dalla 1024 alla 65.535. 9. Scrivere la regola per abilitare i ping. 10. Scrivere la regola per impedire transazioni TCP attivate dall’esterno.

11. Scrivere le regole per impedire gli attacchi DoS e Flood. 12. Abilitare il masquerading. 13. Abilitare il routing tra le schede di rete. 14. Configurare i client in modo che usino il firewall come gateway di accesso esterno.

Firewall con SmoothWall 1. Recuperare un PC e installare due schede di rete. 2. Collegare una scheda di rete allo switch della propria rete locale e l’altra al router per l’accesso esterno. Verificare in questa fase di usare i cavi corretti (alcune connessioni potrebbero richiedere un cavo di rete cross-over). 3 . Scaricare l’immagine iso della distribuzione SmoothWall all’indirizzo www.smoothwall.org e masterizzare il CD-ROM. 4. Inserire il CD-ROM nel computer, riavviarlo e installare la distribuzione. 5. Seguire la procedura per completare l’installazione della distribuzione. Durante l’installazione si deve scegliere la tipologia di rete green+red. 6. Accedere al pannello web del programma, all’indirizzo http://indirizzoserver:81, immettere la user id admin e la relativa password. 7. Attivare l’accesso SSH dall’esterno. 8. Attivare il sistema IDS. 9. Abilitare il forwarding delle porte, nel caso in cui i server interni abbiano servizi pubblici da fornire all’esterno. 10. Andare in Maintenance e verificare le patch da installare. 11. Scaricare dal sito SmoothWall tutte le patch e applicarle al sistema in maniera sequenziale. 12. Riavviare il sistema per attivare le patch caricate. 13. Salvare su floppy la configurazione appena realizzata. 14. Configurare i client in modo che usino il firewall come gateway di accesso esterno.

Capitolo 8

Capitolo 8 - Accesso a reti remote in VPN A partire dalla seconda metà degli anni Novanta si è assistito a un abbattimento significativo e progressivo dei costi per la realizzazione di reti locali. Questo fenomeno ha permesso a realtà modeste e con risorse economiche limitate di implementare una LAN. Condividere dati e risorse smetteva così di essere un privilegio riservato a grandi aziende ed enti governativi. Il pubblico si dimostrò molto ricettivo e gli ordinativi per materiale di networking segnarono punte elevate, generando ritorni superiori alle aspettative dei più ottimisti analisti di mercato. L’avvento commerciale di Internet amplificò questo processo, diffondendo il concetto di elaborazione “client-server” e ispirando la produzione di programmi di uso generale da installare su un server e da interrogare con un client leggero tramite protocolli aperti. Questa diffusione capillare delle LAN, unita alla cultura di Internet, ha modificato lentamente gli equilibri tecnologici, togliendo centralità al PC. Il personal computer si trasformava lentamente in terminale, un attrezzo informatico con un ciclo di vita limitato e una scarsa importanza strategica in azienda. Tutto il valore venne invece trasferito sugli apparati, sui server e sul software orientato alla rete presente sui sistemi centrali. Anche i budget IT vengono sempre più indirizzati verso quest’area: nuovi apparati e server, formazione, consulenza specializzata, outsourcing e così via. Tutto questo nell’ottica che un ambiente di rete ben concepito e con una corretta manutenzione permette al personale interno di lavorare in maniera più efficace, veloce, produttiva e soprattutto più coordinata. Il modello non è però perfetto: se le risorse sono tutte erogate dalla rete, l’utilizzo di un portatile, disconnesso durante le attività fuori sede, diventa una situazione problematica. Oggi però è facile avere connettività mobile: con costi limitati è possibile avere accesso a Internet usando la rete cellulare e una chiavetta UMTS. Si può allora pensare di mettere in piedi una VPN e ottenere accesso alla rete aziendale anche quando si è fuori per lavoro. La rete locale esce così dalle mura aziendali e segue il personale, ovunque si sposti.

Introduzione alle VPN Il termine VPN (Virtual Private Network) indica una serie di tecnologie che permettono l’accesso a una rete privata usando una rete pubblica. Lo scopo è quello di allargare i confini della LAN oltre le mura fisiche della propria organizzazione e fare in modo che sia possibile connettersi dall’esterno. Ci sono generalmente due motivazioni pratiche che portano alla creazione di una VPN. La prima è quella di far accedere i dipendenti fuori sede, per esempio gli agenti commerciali o i tecnici che sono presso clienti. Questo tipo di accesso VPN può essere definito host to network oppure, nella terminologia Cisco, remote access: si tratta di un singolo computer che si collega direttamente in VPN alla rete della sede. La seconda motivazione è invece più ampia e consiste nel mettere in comunicazione con la sede, le divisioni o le filiali locali della propria organizzazione e disporre di un’unica rete comune. Gli utenti che si trovano, per esempio, nella filiale di Firenze potranno accedere al database del magazzino centrale di Bologna e conoscere le giacenze per un particolare pezzo che è stato richiesto da un cliente. Questo tipo di connessione VPN è definito network to network oppure site to site. Qualunque sia il tipo di VPN che si intende mettere in atto, è necessario prima di tutto individuare una rete pubblica disponibile presso la sede centrale e presso la località remota.

L’unica rete dati che vanta attualmente una presenza diffusa a costi limitati è Internet. Questa è perciò la scelta di rito per la costruzione di praticamente tutte le VPN oggi in uso. La sede deve essere collegata in maniera permanente a Internet tramite banda larga e deve disporre di almeno un indirizzo IP statico. Se si sta realizzando una VPN host to network, il personale mobile non avrà invece bisogno di un IP fisso. Basterà l’indirizzo fornito dinamicamente dal provider all’atto della connessione. Sarà sufficiente a questo punto aprire una connessione VPN da Risorse di rete, fornire alcuni dati, selezionare l’IP della sede ed entrare. Una volta instaurata la connessione, è come se il portatile fosse collegato a una presa di rete nella propria azienda. Si avrà un indirizzo IP interno, si verrà autenticati dal server centrale remoto e si avranno i diritti che normalmente si hanno all’interno dell’azienda. Non si noterà alcuna differenza, se non una velocità inferiore data, dal tipo di connessione a Internet e dalla qualità del collegamento. L’accesso alla propria LAN è possibile perché la VPN instaura un canale dati stabile tra il proprio sistema e il server remoto. Il canale è mantenuto attraverso un protocollo di comunicazione specifico per le VPN, realizzando una sorta di “tubo” tra le due estremità (il proprio computer e il server della rete remota). Dentro questo “tubo” può essere immesso qualunque tipo di traffico, compreso il protocollo NetBIOS usato da Microsoft per l’accesso alle risorse di una rete locale basata su Windows. Si viene perciò a creare una rete dentro la rete o un “tunnel” per usare un termine più tecnico. Il tunnel non è altro che una comunicazione punto a punto realizzata tramite un protocollo concepito in maniera specifica per le VPN. Dentro i pacchetti di questo protocollo viene incapsulato il traffico di rete ordinario, quello cioè che si avrebbe se si fosse direttamente collegati con un cavo Ethernet allo switch della rete aziendale. Andando più nello specifico, si ha, a livello più alto, NetBIOS, il protocollo usato da Microsoft per condividere risorse come computer, cartelle e file in una rete. Questo protocollo viene inserito all’interno di un pacchetto TCP, che viene a sua volta inserito dentro un pacchetto IP, in modo che possa essere inoltrato in una rete e giungere a destinazione tramite indirizzamento univoco. Se si fosse collegati con un cavo di rete, a questo punto si avrebbe un’altra operazione di incapsulamento. Il pacchetto IP sarebbe inserito dentro una trama Ethernet, in modo da poter essere veicolato all’interno della LAN. In realtà non c’è alcun collegamento Ethernet, in quanto il computer dell’esempio si trova fuori sede: il pacchetto viene allora incapsulato nel protocollo specifico della VPN utilizzata, che a sua volta viene inserito su un pacchetto IP e quindi instradato su Internet. Una volta giunti a destinazione, i pacchetti subiscono il trattamento opposto: vengono cioè estratti dal protocollo VPN, “aperti” e poi immessi nella rete della sede. La stratificazione dei protocolli permette un inoltro trasparente: il sistema operativo e gli applicativi non sono a conoscenza del fatto che il client non è fisicamente connesso al cavo di rete locale. Non serve inoltre alcun driver e nessun tipo di componente software particolare. Basta il protocollo VPN attivo e configurato presso i sistemi interessati. Le valutazioni tecniche appena espresse sono del tutto analoghe in comunicazioni network to network. In questo caso, però, i due punti devono essere connessi stabilmente su Internet e disporre entrambi di un IP statico. Si deve poi istituire una doppia connessione: una dalla filiale verso la sede e una dalla sede verso la filiale. Questo permetterà la corretta costruzione delle regole di routing per l’inoltro trasparente dei pacchetti da una sede all’altra.

VPN per il personale fuori sede La realizzazione di una VPN in grado di mettere in contatto un dipendente fuori sede richiede alcuni prerequisiti in termini di infrastruttura. Prima di tutto si richiede la presenza di una connessione a Internet in banda larga disponibile ventiquattro ore al giorno. Nel contratto di connessione deve poi essere prevista la fornitura di una sottorete di indirizzi IP

privati. Un IP fisso sarà assegnato al router. Il secondo indirizzo statico sarà invece assegnato alla scheda di rete Red di un firewall realizzato in base alle indicazioni presentate nell’apposito capitolo di questo libro. In alternativa, se si ha a disposizione un solo indirizzo pubblico (quello del router), è possibile impostare il forward del traffico VPN in ingresso sull’IP del router verso le corrispondenti porte del firewall. Per sapere se il proprio router permette questa opzione e come sia possibile modificare la sua configurazione, occorre fare riferimento alla documentazione fornita con il prodotto. In genere sulle caratteristiche stampate sulla scatola e sulle brochure è indicato se è fornito o meno il supporto “VPN passthrough”. È necessario, inoltre, un sistema server in grado di gestire la connessione VPN. Nel caso di una soluzione Microsoft, si presume almeno Windows Server 2003 o Windows Server 2008. Come protocollo VPN verrà utilizzato PPTP per via della facilità di configurazione e la disponibilità nativa su un vasto numero di sistemi operativi client, compreso Windows 98. Prima di tutto si deve andare sul server, accedere a Strumenti di amministrazione dal Pannello di Controllo e aprire l’icona Routing e Accesso Remoto. Di default il servizio non è attivo. Si deve fare clic sul nome del server, fare clic con il tasto destro del mouse e scegliere Configura e abilita Routing e Accesso remoto. In questo modo verrà lanciata una procedura guidata per la configurazione del servizio. La prima scheda è autoesplicativa e si deve semplicemente selezione Avanti. Si ottiene così una scheda in cui viene richiesto il tipo di configurazione che si intende realizzare. Bisogna in questo caso specificare Configurazione personalizzata (Figura 8.1) e poi selezionare Avanti.

Figura 8.1 Configurazione della connessione in ingresso.

Nella scheda successiva si deve indicare Accesso VPN (Figura 8.2) e poi bisogna fare clic su Avanti. Compare una schermata riassuntiva, dove si deve fare clic su Fine (Figura 8.3). La configurazione è terminata. Il sistema Windows Server chiede se si desidera attivare immediatamente il servizio (Figura 8.4). Si deve confermare questa scelta. Dopo alcuni istanti si vedrà il pannello dei servizi di

accesso remoto con l’icona del server con una freccia verde a indicare che il servizio è in funzione (Figura 8.5).

Figura 8.2 Scelta dei servizi da abilitare sul server.

Figura 8.3 Schermata riassuntiva dei servizi attivati.

Figura 8.4 Il servizio VPN può essere immediatamente attivato.

Figura 8.5 Strumento di controllo degli accessi remoti.

Il pannello del servizio permette di visualizzare lo stato delle VPN e configurarne gli aspetti principali. Sono diverse le opzioni che possono essere impostate sul pannello delle VPN. È molto importante selezionare il nome del server, fare clic con il tasto destro del mouse e poi scegliere Proprietà. Compare una finestra da cui bisogna scegliere la scheda IP su Windows Server 2003 oppure IPv4 su Windows Server 2008. Qui si può stabilire la politica di gestione degli indirizzi. Durante l’accesso alla rete locale in VPN si acquisisce un indirizzo IP della LAN per tutta la durata del collegamento. Se si dispone di un servizio DHCP sul server Windows, si può selezionare la voce relativa, altrimenti bisogna fare clic su Pool di indirizzi statici e specificare l’intervallo degli indirizzi interni che saranno riservati per i client che accederanno in PPTP dall’esterno (Figura 8.6). Completata la configurazione, si fa clic su Ok per confermare.

Figura 8.6 È necessario specificare la modalità con cui saranno distribuiti gli IP interni agli utenti che accederanno in VPN. Si può usare il DHCP interno o un pool impostato in questo pannello.

Tornando sul pannello di configurazione di Routing e Accesso Remoto è importante visionare la voce Porte. Questo permette di impostare il numero massimo di connessioni VPN contemporanee. Di default sono presenti 128 porte PPTP e 128 porte L2TP (un altro tipo di protocollo VPN per le connessioni host to network). Questi valori possono essere modificati facendo clic con il tasto destro del mouse e inserendo nuovi numeri. Si può, per esempio, disabilitare l’accesso L2TP e indicare un numero inferiore di accessi PPTP. Se si hanno solo cinque dipendenti fuori sede, non ha molto senso avere 128 porte attive. Un numero inferiore di porte occupa meno risorse sul server e risulta più facile da amministrare. Tramite la voce sottostante, Client di Accesso Remoto, è possibile visualizzare in tempo reale l’elenco dei client connessi. Facendo clic su uno di questi sistemi si ottiene un pannello con le statistiche di trasmissione. Sullo stesso pannello è disponibile un pulsante tramite il quale si può interrompere immediatamente la sessione

remota. Facendo clic sulla voce sottostante Criteri di accesso remoto su Windows Server 2003 è invece possibile definire delle regole di comportamento e sicurezza per l’accesso remoto. Di default è presente un unico criterio di sicurezza. Analizzandolo si scopre che di default l’accesso è interdetto tutti i giorni e a tutte le ore del giorno, come mostrato nella finestra riportata nella Figura 8.7. È infatti selezionato il criterio Non consentire l’accesso remoto.

Figura 8.7 Criteri di accesso remoto predefiniti in W indow s Server 2003.

Bisogna modificare questo criterio, impostandolo inizialmente su Consenti l’accesso remoto. È però consigliabile limitare l’accesso, restringendolo ai soli orari in cui i dipendenti hanno il permesso di accedere, per esempio dal lunedì al venerdì dalle 8.00 alle 19.30. Così facendo si evita che la connessione resti aperta tutta la notte, dando a eventuali malintenzionati tutto il tempo di tentare attacchi, mentre i sistemi non sono presidiati (Figura 8.8).

Figura 8.8 L’accesso VPN è permesso solo nelle giornate lavorative, durante i normali orari di servizio.

È possibile aggiungere un numero arbitrario di criteri di sicurezza. Basta fare clic sul pulsante Aggiungi e configurare la nuova regola che si intende impiegare. Su Windows Server 2008 la procedura è leggermente differente. La voce, per cominciare, si chiama Criteri e registrazione di accesso remoto. Bisogna portare il mouse su di essa e fare clic con il tasto destro del mouse, poi selezionare Avvia server dei criteri di rete. Compare così una finestra dove è possibile visionare e regolare i criteri.

Figura 8.9 Scheda per la configurazione dei criteri di accesso in W indow s Server 2008.

Il server è ora pronto per accogliere connessioni PPTP. Bisogna solo specificare quali utenti possono avere accesso. Di default tutti gli utenti sono interdetti. Si deve andare nella Pannello di controllo, Strumenti di amministrazione e aprire Utenti e computer di Active Directory. Si deve scorrere la lista degli account, selezionare con il mouse l’utente specifico da abilitare, fare clic con il tasto destro e scegliere dal menu la voce

Proprietà. La scheda che regola le attività VPN è Chiamate in ingresso. Bisogna verificare che nella sezione Autorizzazione di accesso remoto (Chiamata in ingresso o VPN) sia specificato Consenti accesso (Figura 8.10).

Figura 8.10 Scheda per l’abilitazione degli accessi in ingresso sul server.

Le operazioni sul server sono concluse. Ora bisogna occuparsi della macchina che ospita il firewall. Il sistema Smoothwall Express non prevede di default la possibilità di veicolare VPN di tipo PPTP. Il problema risiede in due aree specifiche. Prima di tutto è necessario che la porta specifica di PPTP (TCP 1723) sia rediretta al server che mantiene la VPN, in questo caso la macchina con Windows Server 2003. In secondo luogo bisogna fare in modo che il protocollo GRE (Generic Route Encapsulation) sia anch’esso inoltrato al server Windows Server 2003. Il GRE è il protocollo utilizzato da PPTP per creare il tunnel VPN tra il client e il server. All’interno di questi pacchetti è incapsulato tutto il traffico di rete generato tra il client e la LAN presso la sede. Per fare in modo che SmoothWall Express gestisca correttamente questo traffico, è necessario avere accesso alla shell di sistema e intervenire manualmente sui file di configurazione. In particolare bisogna aprire /etc/rc.d/rc.firewall.up, portarsi in fondo al file e aggiungere le seguenti righe, rispettando maiuscole e minuscole: Listato 8.1

iptables -N pptp

iptables -A pptp -p tcp --destination-port 1723 --dst 192.168.100.5 -j ACCEPT iptables -A pptp -p 47 --dst 192.168.100.5 -j ACCEPT iptables -I FORWARD -j pptp iptables -t nat -N pptp iptables -t nat -A pptp -i $RED_DEV -p tcp --dport 1723 -j DNAT --to 192.168.100.5:1723 iptables -t nat -A pptp -i $RED_DEV -p 47 -j DNAT --to 192.168.100.5 iptables -t nat -A PREROUTING -j pptp

Questa modifica è suddivisa in due blocchi. Nel primo blocco viene creata una nuova catena denominata pptp e al suo interno vengono inserite due regole: la prima (nella seconda riga) permette il flusso di pacchetti TCP verso la porta 1723 del server Windows che gestisce la VPN (in questo esempio 192.168.100.5); la seconda regola (nella terza riga) autorizza il passaggio del traffico GRE (protocollo 47) verso il server Windows; nella quarta riga viene collegata la catena utente pptp alla catena di sistema FORWARD. Nel secondo blocco viene eseguito qualcosa di analogo, ma questa volta nelle tabelle nat. Si fa cioè in modo che il traffico TCP 1723 e GRE sia effettivamente rediretto al server Windows tramite un meccanismo di NAT. Nello specifico, viene creata una nuova catena pptp (riga 1) e al suo interno vengono inserite le regole per inoltrare il traffico TCP porta 1723 (riga 2) e GRE (riga 3) al server Windows presente all’indirizzo 192.168.100.5. Nella quarta riga viene collegata la tabella nat nella catena PREROUTING, comportando l’effettiva operazione di redirect. Per rendere operative le modifiche definite nei due blocchi appena esaminati è necessario riavviare il firewall. L’unico problema in questa operazione manuale di configurazione consiste nel fatto che il contenuto del file rc.firewall.up potrebbe essere alterato nel caso in cui si eseguano configurazioni a livello dell’interfaccia utente di SmoothWall Express. In tal caso, la configurazione potrebbe essere completamente eliminata. Conviene allora inserire le direttive in un file a parte, da richiamare all’interno di rc.firewall.up. In caso di modifiche automatiche da parte di SmoothWall Express, sarà sufficiente inserire nuovamente il rimando al file appena creato per avere la VPN nuovamente operativa. Se si opta per questa soluzione, bisogna fare in modo che la variabile $RED_DEV sia sostituita con l’indirizzo IP della scheda di rete affacciata al mondo esterno. Ora non resta che configurare i client. Nel caso di una macchina con Windows XP si deve andare in Risorse di rete, fare clic su Visualizza connessioni di rete (tra le opzioni elencate a sinistra) e poi su Crea nuova connessione. Comparirà la prima finestra della procedura guidata per la configurazione della nuova connessione. Nella prima pagina bisogna scegliere Connessione alla rete aziendale e al passaggio seguente specificare Connessione VPN (Figura 8.11).

Figura 8.11 Configurazione del client VPN di W indow s XP.

Confermando, compare un riquadro dove è necessario indicare un’etichetta per questa connessione (per esempio VPN aziendale). Nella pagina successiva si può indicare quale connessione a Internet deve essere attivata per l’accesso VPN in questione. In questo modo si attiverà automaticamente la connessione a Internet. Il passaggio seguente è molto importante: si deve infatti digitare l’indirizzo pubblico del firewall SmoothWall Express della propria organizzazione (Figura 8.12).

Figura 8.12 Indicazione dell’indirizzo pubblico del firew all della sede. Una regola di routing inoltrerà il traffico VPN al server W indow s.

Seguendo la procedura, viene chiesto se la connessione è di uso esclusivo del profilo corrente o se sarà disponibile a tutti gli utenti. Facendo clic su Avanti si conclude l’operazione e si avrà una nuova icona tra le connessioni di rete. Per accedere alla rete della propria azienda non resta che collegarsi a Internet e fare clic sull’icona della nuova connessione appena realizzata. Verranno richieste alcune credenziali. Bisogna fornire il nome utente e la password con cui si esegue normalmente il login alla propria rete locale. Se l’organizzazione è strutturata come un dominio, bisogna indicare anche il nome relativo. Se la configurazione è stata eseguita correttamente, si dovrebbe avere pieno accesso alla rete remota. Su Windows 7 la procedura di configurazione è del tutto simile. Bisogna però accedere al Pannello di controllo, selezionare Rete e Internet e poi la voce Visualizza stato della rete e attività. Poi si deve scegliere in basso Configura nuova connessione o rete, scegliere Connessione a una rete aziendale e infine Usa connessione Internet esistente. Ora i passaggi sono simili a quanto esposto per Windows XP. Nel caso si stia utilizzando come modem un telefono cellulare o una chiave UMTS, bisogna tenere in considerazione il fatto che nei contratti base alcuni gestori filtrano il traffico VPN, prevedendolo solo con contratti specifici, più costosi. È bene verificare questo dettaglio tramite l’help desk del gestore. Si potrebbe infatti essere indotti a credere in un problema con la propria configurazione, quando il traffico in realtà viene del tutto scartato sulla rete dell’operatore mobile. Si deve anche tenere conto dell’aspetto sicurezza. Il meccanismo di cifratura usato in PPTP dispone di un grado di robustezza limitato e può essere violato con meccanismi a forza bruta non troppo complessi. Si raccomanda quindi di usare questo protocollo solamente nei casi in cui si debbano compiere collegamenti spot, cioè per periodi di tempo limitati. PPTP non dovrebbe quindi essere usato per mantenere perennemente collegate due sedi di un’organizzazione. La presenza continua del tunnel VPN potrebbe attirare i malintenzionati. Si dovrebbe fare in modo che solo un numero ristretto di utenti possa avere accesso VPN alla propria rete e costruire idonei criteri di sicurezza all’interno del server. Le password di login per questi utenti non devono

essere banali e andrebbero cambiate con una certa frequenza, per evitare sorprese.

VPN per filiali remote Se sussiste la necessità di mettere in comunicazione continua una filiale distaccata con la sede centrale è bene fare uso di configurazioni più adeguate. Il firewall SmoothWall Express permette di realizzare velocemente questa operazione tramite una funzionalità di VPN network to network basata sul più robusto protocollo IPSec. Per mettere in atto questo tipo di configurazione è necessario che ogni sede abbia un collegamento a Internet a banda larga disponibile 24 ore al giorno. Entrambi i contratti di accesso dovranno prevedere una sottorete di indirizzi IP statici. Su ogni sede si dovranno assegnare due IP statici: uno al router e l’altro alla scheda Red di SmoothWall Express. Ogni sede sarà inoltre dotata di un nome simbolico tratto dalla terminologia di SmoothWall Express. Per esempio, una sarà chiamata left e l’altra right. Non esiste alcun motivo particolare nella scelta di questi nomi. Si tratta unicamente di una convenzione di SmoothWall Express, per distinguere in maniera univoca una sede dall’altra. Per essere più pratici, si deciderà che la sede di Milano è right, mentre la filiale a Bologna è left. La Figura 8.13 schematizza questa configurazione.

Figura 8.13 Schema di collegamento VPN tra la sede principale a Milano e una filiale a Bologna.

Si comincia lavorando sulla rete right, ovvero la sede centrale a Milano, entrando nella finestra di configurazione web di SmoothWall Express. Nella scheda vpn si sceglie la linguetta connections. Compare così una serie di campi da compilare per intero (Figura 8.14). In Name si deve inserire un’etichetta a testo libero, per esempio MilanoBologna.

Figura 8.14 Configurazione di una VPN tra la sede centrale e una filiale remota. Gli IP di left e right sono a titolo di esempio. Nella realtà si deve inserire l’IP della scheda RED del firew all.

Nella riga sottostante bisogna indicare le generalità della rete di Bologna: in Left deve essere indicato l’IP statico della scheda Red di SmoothWall Express e in Left Subnet bisogna specificare la rete privata interna. Nel caso si usi una famiglia di indirizzi del tipo 192.168.200.n si deve digitare in questo box 192.168.200.0/24. Si tratta dell’indirizzo della rete (da cui lo zero finale) comprensivo della subnet mask in formato compatto. La sottorete /24 corrisponde infatti a 255.255.255.0. Se si hanno sottoreti particolari e non si sa come ottenere la conversione in formato compatto, si può fare riferimento al convertitore presente all’indirizzo http://www.subnet-calculator.com. Nella riga sottostante bisogna indicare le generalità della rete della sede: in Right bisogna specificare l’IP della scheda Red del firewall SmoothWall Express di Milano, mentre in Right subnet vanno inserire le generalità della rete privata interna a Milano. Attenzione però al fatto che le reti interne devono avere sottoreti differenti. Se Bologna ha una rete del tipo 192.168.200.n, Milano dovrà funzionare su un’altra rete, per esempio 192.168.100.n. In caso contrario potrebbero esserci seri problemi di routing dei pacchetti. In Secret bisogna inserire una password che sarà utilizzata per le operazioni di cifratura della VPN. Si consiglia di usare una lunga sequenza di caratteri, composta da numeri, lettere e simboli. In Again si deve ripetere per conferma la password inserita. Nella riga sottostante, il controllo Enabled è impostato di default. Questo significa che la VPN, una volta confermata, sarà subito attivata. È possibile attivare Compression, in alto a destra e avere la compressione automatica dei dati in transito. Si deve ponderare bene questa scelta, in quanto si tende a installare la distribuzione SmoothWall Express su macchine obsolete. Molti di questi PC potrebbero non essere in grado di sostenere il carico computazionale della compressione, comportando problemi nella comunicazione o rallentamenti. Completata questa fase di configurazione, si deve fare clic su Add per rendere attiva la VPN sulla sede di Milano. Questa non è però funzionante, perché manca ancora la configurazione della filiale di Bologna. Questo processo può essere reso automatico, evitando la compilazione manuale della relativa scheda web

di SmoothWall Express. Basta fare clic sul pulsante Export per fare in modo che SmoothWall Express generi un file con la configurazione della VPN. Il file può essere inviato per e-mail a un responsabile tecnico presente a Bologna. Questa persona non dovrà fare altro che andare nel pannello della VPN, sezione Connections, fare clic sul pulsante Sfoglia, scegliere il file appena recapitato e fare clic su Import. La configurazione sarà automaticamente importata. Ora entrambi gli operatori devono andare nella sezione Control della sezione VPN e fare clic su Restart per stabilire la connessione tra i due punti. Se non sono stati compiuti errori di configurazione, si dovrebbe ottenere la connessione completa tra le due sottoreti private e dovrebbe essere possibile effettuare il ping verso qualunque sistema di entrambe le località. Si ha quindi un’unica rete comune, costituendo una base infrastrutturale per qualsiasi tipo di attività distribuita. La VPN network-to-network appena realizzata fornisce anche un buon grado di sicurezza, in quanto è basata sul più robusto protocollo IPSec. Tutto il traffico veicolato subisce a tal proposito un processo di cifratura attraverso l’algoritmo 3DES. La sicurezza non è però mai un dato di fatto quando la comunicazione avviene tramite una rete pubblica. Per questo motivo, non si può pensare di creare una VPN e dimenticarsene. Si deve piuttosto svolgere un’attività di amministrazione continuativa, per evitare attacchi o accessi non autorizzati. Per esempio, la password di sessione utilizzata da SmoothWall Express dovrebbe essere cambiata con frequenza. Si dovrebbe inoltre controllare bollettini di sicurezza e verificare la presenza di patch per il firmware del router, per la SmoothWall e per i sistemi operativi in uso. Le VPN sono infatti prede ambite da parte dei cracker disseminati su Internet e non bisogna quindi abbassare la guardia. Non si può neppure dimenticare la propria VPN per il semplice fatto che funziona bene. Eventualmente, è possibile investire nella versione commerciale di SmoothWall. Questa fornisce un’infrastruttura VPN ancora più robusta, con protocolli di cifratura migliori (AES, Twofish, Blowfish e CAST) e sistemi di autenticazione più articolati. Informazioni sul prodotto sono reperibili all’indirizzo http://www.smoothwall.net.

Checklist VPN per il personale fuori sede (remote access) 1. Andare sul server Windows, aprire Risorse di rete, icona Strumenti di amministrazione e fare doppio clic su Routing e Accesso Remoto. 2. Selezionare il nome del server, fare clic con il tasto destro del mouse e selezionare la voce di menu Configura e abilita Routing e Accesso remoto. 3. Seguire la procedura guidata per configurare il servizio. 4. Ridurre il numero di connessioni VPN al valore strettamente necessario. 5. Modificare il criterio di sicurezza predefinito. 6. Attivare l’accesso VPN nei profili utente tramite l’applicazione Utenti e computer di Active Directory da Strumenti di amministrazione. La scheda è Chiamate in ingresso e l’opzione è Autorizzazione di accesso. 7. Applicare la configurazione in /etc/rc.d/rc.firewall.up su SmoothWall Express allo scopo di permettere il passaggio del protocollo PPTP. 8. Riavviare la macchina che ospita SmoothWall Express. 9. Configurare il client.

VPN per filiali remote (network to network) 10. Installare due macchine SmoothWall Express, una in ogni sede. 11. Chiedere al provider una sottorete di indirizzi statici per ognuna delle due sedi. 12. Accedere al pannello di configurazione web di uno dei due SmoothWall Express, andare nella scheda VPN e selezionare Connections. 13. Realizzare la configurazione per la sottorete left (la sede centrale) e per la sottorete right (la filiale locale). 14. Inserire una password per la cifratura. 15. Attivare la compressione (solo se le macchine SmoothWall Express sono sufficientemente veloci). 16. Attivare la configurazione facendo clic su Add. 17. Esportare la configurazione e inviarla alla seconda sede. Un operatore dall’altra parte dovrà semplicemente importare questa configurazione per configurare la propria macchina SmoothWall Express. 18. Entrambi gli operatori devono andare nella scheda Control e fare clic su Restart.

Capitolo 9

Capitolo 9 - Gestione dell’accesso a Internet con il proxy Squid Accedere a Internet è oggi semplice e vantaggioso. Con un abbonamento mensile dal costo accessibile è possibile avere connessioni ADSL di tipo full-time e poter così fruire della Grande Rete senza limiti di tempo. Si tratta di una grande opportunità per gli utenti privati e per le imprese. Il personale aziendale può infatti navigare per ottenere informazioni inerenti il lavoro e scambiare volumi arbitrari di mail senza porsi troppi problemi sulla dimensione degli allegati. Questa situazione è funzionale in realtà di piccole dimensioni, dove il numero degli utenti è limitato. In organizzazioni con centinaia di utenti connessi e magari con i servizi on-line gestiti internamente, la banda ADSL mostra tutti i suoi limiti. Presto si percepiranno i vincoli del canale in upload asimmetrico (generalmente fissato a 256 Kbit/s) e non passerà molto tempo prima che anche il canale in ricezione risulti saturo. Non si potrà in questo caso fare altro che abbandonare l’ADSL e usare linee simmetriche ad alta capacità, per esempio servizi HDSL o reti cittadine in fibra. Questi servizi sono fatturati in base al traffico generato oppure hanno un costo flat molto alto, lontano dalla portata delle piccole imprese. Vi sono poi i costi nascosti, dati dalla perdita di produttività causati dall’accesso libero a siti che hanno poco a fare con le attività produttive. Si pensi al social network, al gioco on-line, alle chat e così via. Ecco quindi che diventa necessario regolamentare la risorsa per evitare che questa voce di spesa vada fuori controllo. Una soluzione che può essere adottata rapidamente consiste nell’installazione di un sistema proxy all’interno della propria organizzazione. In questa modalità, gli utenti non hanno accesso diretto al gateway e non possono quindi raggiungere Internet. Tutte le comunicazioni verso il mondo esterno passano attraverso il proxy. Questo sistema non è un semplice punto di passaggio, ma piuttosto un meccanismo attivo, funzionante in base a regole di accesso stabilite dall’amministratore di sistema. È quindi possibile regolamentare il modo in cui i singoli utenti o i gruppi di utenti possono utilizzare il gateway e si può stabilire quali siti o quali categorie di siti sono accessibili. Il tutto è documentato da un log degli accessi preciso e puntuale. Il proxy fornisce inoltre funzionalità di cache, immagazzinando i dati dei siti utilizzati frequentemente. Questo dovrebbe ridurre il traffico effettivo sul canale dati esterno, riducendo i costi della connessione.

Dove installare il proxy Per fare in modo che una rete locale possa accedere a Internet è necessario disporre di un dispositivo chiamato router. Questo sistema svolge diverse attività, tra cui una conversione del segnale tra una rete interna basata su Ethernet e una rete esterna che è veicolata su un mezzo differente, quale, per esempio, un doppino di rame, una connessione seriale, una fibra ottica e così via. In secondo luogo avviene una traduzione tra indirizzi locali interni e l’indirizzamento pubblico presente su Internet. Qualunque sistema abbia la necessità di accedere a Internet dovrà fare riferimento a questo elemento, tecnicamente denominato gateway. Sul pannello di configurazione del TCP/IP è presente un campo così denominato su cui impostare l’indirizzo interno dell’apparato. Spesso il ruolo di gateway è ricoperto da un firewall. I client interni si riferiscono al firewall come gateway e questo a sua volta avrà come gateway un router.

Il router o il firewall sono però elementi poco regolamentabili, in quanto hanno solamente la visibilità degli strati più bassi della gerarchia ISO OSI, ovvero sono in grado di svolgere attività di controllo solo in base a indirizzi IP o a porte. Non è possibile quindi impostare politiche di controllo in base al nome utente e neppure limitare in maniera più granulare l’accesso a Internet, per esempio permettendo l’accesso a un numero ristretto di siti o in base al traffico scambiato in un determinato periodo di tempo. Il proxy può invece svolgere tutto questo proprio perché opera a un livello alto della gerarchia OSI, dove ha piena visibilità dei diversi protocolli, come per esempio il protocollo HTTP. Quando si impiega un proxy è necessario fare in modo che gli utenti non abbiamo accesso al gateway. Questo deve essere di fatto invisibile alla LAN e risultare accessibile unicamente dal proxy. I riferimenti al gateway dovranno essere tolti dai singoli computer e sul gateway stesso saranno applicate delle regole di filtraggio, per fare in modo che solo il sistema proxy possa accedervi. Eventualmente si può approntare un sistema proxy dotato di due schede di rete, ognuna configurata su una sottorete interna differente (per esempio 192.168.100.0 e 192.168.200.0). Una scheda di rete sarà collegata allo switch aziendale e quindi accessibile alla sottorete della LAN (per esempio 192.168.100.5). Grazie a questa scheda di rete, tutti i sistemi interni potranno comunicare con il proxy. La seconda scheda di rete (per esempio 192.168.200.5) sarà invece collegata direttamente con il gateway tramite un allacciamento fisico. Solo il proxy sarà così fisicamente connesso a Internet (Figura 9.1).

Figura 9.1 Schema di una rete dotata di un sistema proxy.

Qualunque sistema desideri accedere a Internet, dovrà usare il proxy. Questo non sarà però usato come gateway e di fatto non vi sarà una indicazione del gateway nel pannello IP dei singoli computer. Saranno invece i singoli applicativi Internet a fare log-in sul proxy e a ottenere eventualmente il permesso alla comunicazione in base alla politica stabilita dall’amministratore. Dal momento che il gateway è nascosto, nessun utente potrà utilizzare il canale Internet senza sottoporsi alla regolamentazione stabilita all’interno dell’organizzazione.

Installazione Si consiglia di utilizzare come sistema proxy una macchina dedicata, scegliendo un computer moderno dotato di molta memoria RAM, di dischi veloci e di un microprocessore attuale.

Il proxy deve gestire un numero elevato di comunicazioni contemporaneamente, controllando le informazioni di alto livello dei protocolli e verificando che il traffico sia compatibile con la politica di accessi. Si tratta di operazioni di controllo e smistamento onerose, che potrebbero avere un impatto negativo su macchine obsolete. Gli utenti percepirebbero in tal caso un forte calo delle prestazioni di Internet. Non si deve poi dimenticare che il proxy esegue funzioni di cache, memorizzando i contenuti richiesti. Servono pertanto dischi veloci e capienti. Il sistema deve contenere un’installazione Linux minimale, con i soli servizi strettamente necessari. Questa misura ha ancora una volta lo scopo di minimizzare il carico, eliminando i servizi privi di utilità. La macchina deve essere collegata alla rete locale e deve avere accesso a Internet. Si deve a tal proposito impostare lo schema di rete indicato in Figura 9.1, utilizzando la stessa sottorete interna per la connessione LAN (in questo caso 192.168.100.n) e una sottorete IP differente per il collegamento al router (in questo caso 192.168.200.n). Anche il router deve essere riconfigurato, in quanto non dovrà appartenere alla sottorete della LAN, ma alla sottorete della seconda scheda di rete del computer che svolge funzioni di proxy. È importante verificare l’accesso a Internet. Se il sistema che si sta configurando non è in grado di dialogare su Internet non sarà possibile avere un proxy funzionante. Bisogna perciò soffermarsi su questo problema e risolverlo prima di proseguire. Si consiglia di fare riferimento ai capitoli dedicati al router e al firewall. Una volta soddisfatte queste condizioni, si può procedere al download del software. In questo capitolo verrà utilizzato Squid (http://www.squid-cache.org), il progetto Open Source di riferimento per chiunque intenda implementare un proxy HTTP e FTP con funzionalità avanzate di controllo e caching dei contenuti (Figura 9.2).

Figura 9.2 Sito ufficiale di Squid.

Squid è presente in tutte le distribuzioni più diffuse. Nel caso non fosse disponibile nei dischi di installazione o nei repository è possibile ottenerlo dal sito ufficiale facendo clic su Download in alto e selezionando poi Official source code release (Squid è in tal caso fornito in formato sorgente). La stessa pagina contiene un link a versioni binarie già pacchettizzate. Basta fare clic su Binary package of Squid. È tutto più semplice se la propria distribuzione prevede già il pacchetto, come per esempio CentOS e Fedora Core. Basta quindi usare i comandi di sistema: yum install squid

Su Ubuntu si usa invece questo comando: apt-get install squid

Il file di configurazione principale di Squid si trova in /etc/squid/squid.conf. Questo è estremamente lungo e ricco di opzioni. La sua analisi può risultare disarmante per un utente alle prime esperienze con questo prodotto. Fortunatamente le impostazioni di default sono già funzionali e sono sufficienti poche operazioni per rendere operativo il programma. La prima attività da compiere è quella di cercare l’opzione visible_hostname, togliere eventualmente il commento e inserire al suo posto il nome del proprio host. Si presuppone che il nome di host sia stato

assegnato correttamente al proprio computer. visible_hostname linuxserver

Si può salvare il file, uscire e verificare che la sintassi generale del file di configurazione sia corretta. Basta impartire questo comando: squid -k parse

Viene così eseguito un controllo, ed eventuali errori sono segnalati a video. Se tutto è corretto si può attivare il demone: /etc/init.d/squid start

Il proxy dovrebbe risultare attivo e pronto per l’uso. Al momento non sono però impostate regole particolari di accesso, se non quelle generali e permissive di default. Il vantaggio del sistema configurato in questa maniera risiede nella presenza della cache dei contenuti. Già in questo modo si riesce a ridurre il traffico esterno e a velocizzare l’accesso a risorse Internet cui hanno già acceduto altri utenti della LAN. I client non possono però usare il proxy senza una configurazione specifica. Non si deve dimenticare che il gateway è stato occultato e che il proxy agisce a livello applicativo. Bisogna a questo punto aprire il browser, accedere al pannello delle impostazioni, sezione delle connessioni e impostare il proxy. Si deve indicare l’IP interno del sistema Linux che ospita il proxy e la porta usata. Di default è la 3128. Confermando si otterrà la connettività web. Il primo accesso a una risorsa esterna potrebbe risultare lento. Questo dipende dal fatto che il sistema sta eseguendo il caching dei contenuti. Gli accessi successivi dovrebbero risultare più veloci.

Liste di accesso La creazione delle regole di accesso avviene con la stesura di comandi specifici all’interno del file di configurazione principale di Squid, nella sezione ACL (Access Control List). È possibile specificare un numero arbitrario di regole. Ogni volta che un client eseguirà un accesso al Web, Squid leggerà in maniera sequenziale le regole configurate. Verrà applicata la prima regola che soddisferà il tipo di accesso. Se la comunicazione risulta permessa dalla regola, questa potrà essere portata a termine sul client e l’utente vedrà il sito o la pagina. In caso contrario l’accesso sarà interdetto. Quando viene attivata e applicata una regola di Squid, la lettura delle regole seguenti del file di configurazione viene saltata. La creazione della regola avviene con il comando acl, usando la seguente sintassi: acl nome_lista_accesso tipo stringa_di_decisione

La prima parola, acl, è riservata e serve a indicare a Squid che si sta specificando una regola di accesso. Il campo seguente, nome_lista_accesso, è un’etichetta a testo libero che rappresenta la regola che si sta creando. Dovrebbe essere breve, esplicativa e priva di spazi. Il campo tipo indica la tipologia di regola che si sta creando, per esempio se si vuole discernere l’accesso in base all’indirizzo del richiedente, all’ora in cui è stata eseguita la richiesta, in base al dominio oppure all’utente che ha eseguito la richiesta. L’ultimo campo, stringa_di_decisione, contiene il limite che si impone, per esempio una fascia oraria del giorno, una sottorete di indirizzi e così via. Un esempio può risultare chiarificatore:

i

acl lan_aziendale src 192.168.100.0/24

Si è creata una regola o più precisamente, un’ACL, denominata lan_aziendale, di tipo sorgente (src), vincolata alla sottorete locale 192.168.100.0. L’acl da sola non è però sufficiente, deve sempre essere richiamata da un comando http_access, come in questo caso: http_access allow lan_aziendale

i sistemi della sottorete 192.168.100.0. Viceversa, se si usa il comando seguente, si interdice l’accesso alla stessa sottorete: http_access deny lan_aziendale

È possibile creare un numero arbitrario di direttive acl e http_access. Non bisogna però dimenticare che il primo comando http_access a essere soddisfatto termina la valutazione. Squid cioè eseguirà l’accesso (allow) o lo bloccherà (deny) senza procedere con le regole successive. In questi esempi le direttive acl e http_access sono scritte in maniera consecutiva, ma nel file di configurazione di Squid le acl e le direttive http_access sono raggruppate. Prima si hanno cioè tutte le acl e poi tutte le http_access. Bisogna prestare attenzione a continuare a raggruppare ACL e direttive in questo modo. Il file di configurazione di default di Squid contiene già un certo numero di acl e di direttive http_access. Queste righe sono idonee alla maggior parte delle installazioni e possono essere lasciate al loro posto. Bisogna però ricordarsi di inserire le nuove acl dopo quelle presenti e di inserire le direttive http_access prima di quelle esistenti. Questo per evitare che le direttive preesistenti possano soddisfare le comunicazioni, impedendo così l’azione delle nuove regole appena inserite. Squid supporta molti tipi di analisi all’interno delle direttive acl, ma solo alcuni di questi sono di uso comune. Per una trattazione più completa si consiglia di accedere al wiki http://www.deckle.co.za/squid-users-guide e in particolare alla sezione Access Control and Access Control Operators.

Oltre all’indirizzo e alla sottorete di provenienza è molto utile eseguire valutazioni in base all’orario della giornata o al giorno della settimana: Listato 9.1

acl lavorativi M T W H F 9:00-18:30 acl weekend A S 0:00-24:00 http_access deny weekend http_access allow lavorativi

La prima acl definisce le giornate lavorative, mentre la seconda i week-end. Le lettere indicano il giorno della settimana, in base alla Tabella 9.1: Tabella 9.1

M Monday

Lunedì

T Tuesday

Martedì

W Wednesday Mercoledì

H Thursday

Giovedì

F Friday

Venerdì

A Saturday

Sabato

S Sunday

Domenica

I numeri seguenti sono l’orario del giorno nel formato 24 ore. L’intervallo orario si riferisce al giorno corrente e non copre quindi più giornate. Le direttive http_access dell’esempio precedente permettono l’accesso durante i giorni lavorativi e lo impediscono nei week-end. I controlli possono essere eseguiti anche in base al dominio cui l’utente sta cercando di accedere, come nel seguente esempio: acl siti_interdetti dstdomain "/usr/local/etc/siti_interdetti.squid" http_access deny siti_interdetti

Come parametro per il tipo di controllo dstdomain non si inserisce un valore specifico, ma un percorso a un file di testo che contiene l’elenco dei siti cui gli amministratori hanno reputato di non permettere più l’accesso. Su ogni riga deve essere indicato un solo sito e nella stesura del file si deve prestare attenzione a usare un formato ASCII standard. Con lo stesso principio si può creare una lista di siti permessi e fare in modo che gli utenti utilizzino solo questi: acl siti_permessi dstdomain "/usr/local/etc/siti_permessi.squid" http_access allow siti_permessi

In questo caso, in fondo alle direttive http_access dovrà essere presente una regola di default che impedisca qualunque accesso, per esempio: http_access deny lan_aziendale

I file di testo con l’elenco dei siti permessi e interdetti devono avere i giusti diritti, per esempio: chmod 755 /usr/local/etc/siti_interdetti.squid chmod 755 /usr/local/etc/siti_permessi.squid

Accesso al proxy con password Fino a questo momento le regole di accesso al proxy sono state create basandosi su criteri quali sottoreti di IP, indirizzi univoci, orari del giorno oppure indirizzi web. È possibile affiancare questi criteri a un sistema di autenticazione degli utenti, imponendo una user name e una password come condizione necessaria per avere accesso al proxy. In questo scenario, l’utente esegue il normale log-in al sistema e alla LAN e poi, appena apre il browser, deve inserire ulteriori credenziali. È possibile creare password di gruppo oppure realizzare password differenziate per singoli utenti. Qualunque sia la strategia scelta, le password saranno memorizzate all’interno di un file binario cifrato, scelto dall’amministratore. Questo file conterrà tutte le informazioni di accesso. Per memorizzare le credenziali in questo file è necessario usare il programma htpasswd. Questo tool è un

componente di Apache ed è usato in tale contesto per attivare il meccanismo di autenticazione delle aree ad accesso ristretto dei siti web. Questo stesso strumento permette di creare degli account per Squid. Il file delle password dovrebbe essere memorizzato all’interno di /etc/squid, con il nome convenzionale squid_passwd. Il programma htpasswd non è però in grado di funzionare se il file non è già presente. Quindi la prima volta che lo si utilizza deve essere usato il parametro -c per forzare la creazione del file: htpasswd –c /etc/squid/squid_passwd szanzi

Premendo il tasto Invio sarà richiesta la password per due volte e poi, se coincidono, comparirà un messaggio per segnalare l’esito positivo dell’operazione: New password: Re-type new password: Adding password for user szanzi

Se si creano nuovi utenti bisogna evitare il parametro –c, perché cancellerebbe il file precedentemente creato. Ora si può ritornare al file di configurazione di Squid e cercare la sezione auth_param. Al suo interno si deve inserire la seguente sequenza: auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd

In questo modo viene specificata una metodologia di autenticazione per Squid tramite un programma esterno. La voce basic è una parola riservata che indicata la modalità standard di autenticazione esterna. Di seguito si inserisce il percorso del programma autenticatore e gli eventuali parametri. In questo caso sarà il programma ncsa_auth a operare l’autenticazione usando il file delle password presente in /etc/squid/squid_passwd. Completata questa fase si deve andare nella sezione delle ACL, portarsi in fondo e creare questa regola: acl autenticati proxy_auth REQUIRED

La regola si chiama autenticati e impone l’autenticazione forzata al proxy. Ora bisogna portarsi in cima alla sezione http_access e aggiungere questa riga: http_access allow autenticati

Viene così permesso l’accesso solo ai sistemi che supereranno la fase di autenticazione, inserendo una delle credenziali create in precedenza con htpasswd. Dopo questa direttiva si possono aggiungere altre direttive http_access per regolamentare ulteriormente gli utenti autenticati.

Configurazione dei client Una volta che il proxy è in funzione, è necessario specificare su ogni browser che la connessione è mediata da un sistema proxy. Nel caso di Mozilla Firefox si deve andare nel menu Strumenti, voce Opzioni, pulsante Avanzate, scegliere la scheda Rete e poi fare clic su Impostazioni. Compare una finestra dove occorre selezionare Configurazione manuale del proxy e poi specificare l’indirizzo IP del proxy http e la porta (Figura 9.3).

Figura 9.3 Impostazione del proxy in Mozilla Firefox.

Su Internet Explorer bisogna andare nel menu Strumenti, scegliere Opzioni Internet, selezionare la scheda Connessioni e poi premere in basso il pulsante Impostazioni LAN. Si attiva la sezione Server Proxy e si digita ancora una volta indirizzo e porta. Si consiglia di selezionare anche Ignora server proxy per indirizzi locali (Figura 9.4).

Figura 9.4 Impostazione del proxy in Internet Explorer.

Filtrare per categorie di siti La configurazione realizzata fino a questo punto permette di regolamentare l’accesso a Internet con un meccanismo di credenziali e tramite l’enumerazione dei siti permessi e di quelli vietati. È una buona soluzione, però non esaustiva in realtà dove è necessario filtrare intere categorie non inerenti le attività produttive, come i siti di gioco d’azzardo o quelli a luci rosse. Si tratta di un numero immenso di indirizzi da escludere, in evoluzione quotidiana, materialmente impossibili da bloccare con l’editing manuale della configurazione di Squid. Per risolvere il problema si devono utilizzare blacklist professionali e filtri avanzati da collegare a Squid. Esistono alcuni filtri compatibili, la maggior parte dei quali di tipo commerciale. Vi è però una soluzione di buona qualità fornita gratuitamente. Si tratta di SquidGuard, disponibile all’indirizzo http://www.squidguard.org. Anche per quanto riguarda le blacklist ci sono diverse soluzioni, la maggior parte delle quali commerciali. Queste contengono migliaia di siti, catalogati in maniera minuziosa e aggiornate costantemente. Vista la complessità dell’operazione di mantenimento, è normale che la maggior parte di questi prodotti sia a pagamento. Vi sono però alcune soluzioni gratuite altrettanto buone. Nelle prossime pagine si vedrà come impiegare un meccanismo di filtro e come utilizzare una blacklist.

Figura 9.5 Sito ufficiale di SquidGuard.

Per cominciare si deve acquisire il filtro utilizzando il gestore dei pacchetti per la propria distribuzione. Su una distribuzione compatibile RedHat, come esempio CentOS, si usa questa sintassi: yum install squidguard

Su una distribuzione basata su Debian, per esempio Ubuntu, si usa questo comando: apt-get install squidguard

Questa operazione installa solamente il sistema di filtro. Non è ancora presente alcuna blacklist. Bisogna quindi procedere al download di questo elemento. La pagina http://www.squidguard.org/blacklists.html elenca diverse blacklist compatibili, indicando anche quali sono a pagamento e quali sono gratuite. In questo esempio si utilizzerà l’elenco realizzato dal MESD, un’organizzazione americana preposta allo sviluppo di servizi e soluzioni per il settore dell’istruzione infantile. Si deve scaricare l’archivio compresso presente all’indirizzo http://squidguard.mesd.k12.or.us/blacklists.tgz. Questo deve essere espanso all’interno di una directory preposta a contenere le blacklist e i relativi file di supporto per Squid. La directory in questione è /var/lib/squidguard/db. Una volta espanso l’archivio, si avrà una directory denominata blacklists con una serie di altre directory al suo interno. È necessario che queste directory interne siano tutte presenti dentro la directory db. Per farlo si può entrare nella directory db con questo comando: cd /var/lib/squidguard/db

e poi impartire un comando move: mv ./blacklists/* .

A questo punto si può cancellare la directory blacklists, vuota e l’archivio compresso. Come si può osservare, ogni directory dell’archivio del MESD corrisponde a una categoria di siti: Listato 9.2

root@linuxcage:/var/lib/squidguard/db# ls -la total 64 drwxrws--- 16 proxy proxy 4096 2008-07-29 08:10 . drwxr-xr-x 4 root root 4096 2008-07-29 05:27 .. drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 ads drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 aggressive drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 audio-video drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 drugs drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 gambling drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 hacking drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 mail drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 porn drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 proxy drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 redirector drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 spyware drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 suspect drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 violence drwxr-sr-x 2 root proxy 4096 2008-07-29 08:04 warez

Ora bisogna concentrare la propria attenzione sulla configurazione del sistema di filtro. Per cominciare si deve cercare la posizione nel file system in cui si trova il file di configurazione di SquidGuard. Tipicamente si trova dentro la directory di configurazione di Squid, /etc/squid. Il file si chiama squidGuard.conf, ma potrebbe anche chiamarsi con il nome completamente minuscolo: squidguard.conf. In questo esempio si farà riferimento al primo nome, squidGuard.conf. Aprendo il file con un editor di testi si noterà la complessità della configurazione di default presente. È bene cominciare con una versione semplificata del file, utilizzando la configurazione di base suggerita dal sito ufficiale di SquidGuard. Si consiglia perciò di rinominare il file di configurazione di default e crearne uno nuovo: Listato 9.3

# # CONFIG FILE FOR SQUIDGUARD # dbhome /var/lib/squidguard/db logdir /var/log/squid dest porn { domainlist porn/domains urllist porn/urls } acl { default { pass !porn all redirect http://localhost/block.html } }

È importante osservare le prime due righe. La prima indica la posizione nel file system dove si trovano le blacklist. La riga successiva stabilisce invece la posizione del file di log. Il file per default si chiama squidGuard.log. Se non è presente, si consiglia di creare un file vuoto. Di seguito si incontrano due blocchi. Il primo stabilisce il tipo di categoria e i relativi file di supporto. In questo esempio è definita la categoria porn relativa ai siti a luci rosse. Il secondo blocco realizza l’ACL, ovvero il controllo di accesso, attraverso la riga seguente: pass !porn all

Questa indica che è interdetto l’accesso alla categoria porn per tutti. Per farlo viene usata una sintassi inversa. La parola chiave pass permette di fatto l’accesso alla categoria indicata sulla destra della parola chiave stessa. Il simbolo di punto esclamativo (!) indica però una negazione logica. Quindi si sta permettendo l’accesso a tutti i siti che non appartengono alla categoria porn. La riga seguente indica invece la pagina che dovrà essere visualizzata ogni volta che un utente tenterà di accedere a uno dei siti presenti nella categoria porn. Con lo stesso principio si possono interdire altre categorie, come nel seguente esempio: Listato 9.4

# # CONFIG FILE FOR SQUIDGUARD # dbhome /var/lib/squidguard/db logdir /var/log/squid dest gambling { domainlist gambling/domains urllist gambling/urls } dest porn { domainlist porn/domains urllist porn/urls } dest warez { domainlist warez/domains urllist warez/urls } dest violence { domainlist violence/domains urllist violence/urls } acl { default { pass !gambling !porn !warez !violence all redirect http://localhost/block.html } }

Ora che la configurazione di SquidGuard è realizzata si deve procedere alla compilazione delle blacklist in un formato indicizzato. Si utilizza questo comando: squidGuard -C all

La procedura potrebbe richiedere tempo su macchine datate. Attenzione al fatto che su alcune distribuzioni il nome del comando potrebbe essere tutto minuscolo: squidguard -C all

Bisogna poi impostare correttamente l’utente di Squid sui file del database delle blacklist: chown -R utente_squid /var/lib/squidguard/db/*

Al posto di utente_squid si deve inserire l’utente di sistema per il demone di Squid. Potrebbe essere squid oppure proxy a seconda della distribuzione utilizzata. Su Ubuntu è proxy, mentre su CentOS è squid. Ora non resta che collegare SquidGuard con Squid. Per farlo si deve aprire il file di configurazione di Squid e aggiungere la seguente riga: redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

Non resta che riavviare il proxy: /etc/init.d/squid restart

Se le operazioni sono state eseguite correttamente, grazie alla configurazione del Listato 9.4 non sarà possibile navigare nelle categorie interdette.

Checklist Squid 1. Configurare la rete in modo che il gateway sia occultato. 2. Configurare una macchina dotata di una buona dotazione hardware e installare una distribuzione Linux minimale, con i soli servizi essenziali. 3. Configurare due schede di rete, una sulla LAN e l’altra fisicamente connessa al gateway. 4. Verificare che la macchina che ospiterà il proxy acceda a Internet. 5. Scaricare e installare Squid. 6. Applicare la configurazione base di Squid. 7. Stabilire una policy di accesso. 8. Creare le acl e le direttive http_access. 9. Nel caso sia necessario un accesso utente mediato da credenziali, bisogna verificare la presenza del tool httpasswd e si deve creare l’elenco delle credenziali. In seguito si deve configurare Squid in modo che sia in grado di interfacciarsi con questo meccanismo di autenticazione. 10. Configurare i client.

SquidGuard 1. Scaricare SquidGuard e installare il pacchetto nel sistema.

2. Scaricare il file di blacklist ed espandere il file nella directory preposta a contenere gli elenchi. 3. Aprire la configurazione di SquidGuard e configurare le categorie da gestire e le relative ACL. 4. Compilare le blacklist. 5. Cambiare il proprietario dei file della directory di blacklist. 6. Aprire il file di configurazione di Squid e inserire il collegamento a SquidGuard.

Capitolo 10

Capitolo 10 - Protezione antivirus con ClamAV e AVG È molto difficile stabilire quando sia stato messo in circolazione il primo virus per i sistemi informatici di ampia diffusione. Il fenomeno può essere probabilmente fatto risalire agli inizi degli anni Ottanta,, con i primi esperimenti sugli Apple II e su altri sistemi che adottavano i floppy per il caricamento di software in autoboot. La grande diffusione si è avuta solo in seguito, con il successo commerciale dei PC compatibili e del DOS. L’interesse verso tale piattaforma e il crescente scambio di programmi attraverso i dischetti incrementavano la circolazione di queste minacce. I “virus informatici” smettono di essere una curiosità tecnologica e diventano un problema con un impatto economico misurabile solo più tardi, negli anni Novanta. I computer iniziavano in quei anni a diffondersi nelle imprese e molti aspetti della vita aziendale venivano per la prima volta realizzati unicamente su mezzi digitali. La perdita di dati e i fermo-macchina comportavano danni economici notevoli. Evenienza tutt’altro che rara in un contesto generalizzato privo di cultura della sicurezza e dove i mezzi di backup erano estremamente costosi e rari. Perfino ottenere assistenza tecnica qualificata era un compito non banale. Di virus si cominciò a parlare anche in TV con toni apocalittici. Michelangelo è stato probabilmente il primo malware a finire sul piccolo schermo nei telegiornali italiani dell’epoca. I passi successivi sono stati Internet e le mail. Non serviva più un floppy, bastava un accesso alla Grande Rete. Ecco che sul finire degli anni Novanta i virus si diffondevano già alla velocità della luce, spostandosi ovunque ci fosse un computer connesso. Da quel momento in poi il fenomeno diventava epidemico. Prendeva corpo anche la strategia del cambiamento, con virus che venivano plasmati in modi sempre diversi, per meglio adattarsi ai nuovi sistemi operativi, per colpire più efficientemente gli applicativi di massa, per conformarsi alle mutevoli abitudini degli utenti e per aggirare subdolamente le protezioni. Oggi i virus sono veicolati quasi unicamente attraverso la posta elettronica, sfruttando i bug dei client email, gli antivirus scaduti e la buona fede degli utenti. Il problema è particolarmente serio sui sistemi basati su Windows. Ciò è dovuto alla grande diffusione della piattaforma e all’elevato numero di malintenzionati intenti a cercare falle nel sistema. Esiste inoltre un problema legato al fatto che una percentuale significativa di utenti Windows non possiede nemmeno una minima alfabetizzazione informatica. Sono perciò terreno fertile per gli autori di virus. Gli utenti di sistemi Linux e Mac risultano più protetti da queste minacce, ma l’aumento di interesse verso queste piattaforme non potrà che incrementare la possibilità che possano essere creati virus pericolosi anche per questi sistemi. Forse l’ambiente Linux risulta meno a rischio rispetto ad Apple, in quanto vi è una diffusione preponderante nell’ambito server. Si presume che in questi casi che vi siano tecnici competenti ad amministrare il sistema e che comunque il computer non venga usato come postazione personale. Questa consapevolezza non deve però essere causa di leggerezza, soprattutto se il server Linux eroga servizi ad altri computer, per esempio la posta elettronica. In questi casi è molto probabile che i fruitori più numerosi siano client Windows. È perciò importante avere un sistema antivirus funzionante e aggiornato. Linux dispone a tal proposito di un prodotto di qualità completamente gratuito: ClamAV (www.clamav.net).

Caratteristiche del prodotto

ClamAV è un virus scanner a riga di comando. Non esiste cioè nella sua forma nativa un’interfaccia grafica di alcun genere, ma solo comandi impartiti da tastiera, da cui derivano risultati stampati sulla shell in forma testuale. Questo non ha comunque impedito lo sviluppo di add-on grafici e di porting completi per Windows o Mac OS X. Il programma è in grado di eseguire scansioni programmate e di effettuare controlli in tempo reale sui file system Linux e FreeBSD tramite un’apposita estensione. È disponibile inoltre una libreria, grazie alla quale qualunque programma può interfacciarsi con ClamAV e richiedere operazioni di scansione. Diventa così possibile usare ClamAV per eseguire la scansione dei messaggi e-mail in arrivo su un server di posta elettronica (la soluzione commerciale Kerio Connect descritta nel Capitolo 12 annovera anche ClamAV per le operazioni di verifica degli allegati). L’antivirus è in grado tra l’altro di analizzare molti tipi di formati archivio tra cui RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet, MS CHM (HTML compresso) e MS SZDD. Il prodotto, alla stregua di tutta la concorrenza commerciale, è dotato di un meccanismo di aggiornamenti via Internet. Vi sono rilasci giornalieri che possono essere scaricati e applicati in maniera molto veloce. Tutto questo per garantire che il database delle firme sia allineato con il panorama antivirus mondiale. Il motore antivirus segue anch’esso un ciclo continuo di aggiornamenti, anche se con una frequenza inferiore (Figura 10.1).

Figura 10.1 Sito ufficiale di ClamAV.

Le caratteristiche di ClamAV sono interessanti e allineate con i prodotti commerciali tradizionali. Vi è però un aspetto distintivo in questo progetto: il modo in cui sono raccolti i campioni dei nuovi virus individuati. Viene impiegato uno schema comunitario, in cui chiunque è libero di inoltrare un nuovo virus compilando un semplice modulo on-line presente sul sito all’indirizzo http://www.clamav.net/lang/en/sendvirus. Un gruppo principale di coordinamento verifica i contributi inoltrati dagli utenti, esegue i dovuti test e provvede in seguito ad aggiornare il database delle firme. Questa strategia è risultata vincente e ha permesso al progetto di acquisire credibilità in un mercato dove sono necessari investimenti cospicui per mantenere un laboratorio con tecnici quotidianamente intenti a individuare nuovi virus, isolare le firme, includerle nel database ed eseguire il necessario testing.

Installazione ClamAV è oggi disponibile in forma pacchettizzata per molte distribuzioni di larga diffusione. Per scaricare l’antivirus in una distribuzione Fedora Core si devono usare questi comandi: yum install clamav yum install clamav-update

Il primo pacchetto installa il sistema antivirus, mentre il secondo installa il programma necessario per gli aggiornamenti delle firme antivirus. ClamAV non viene in genere distribuito su un singolo pacchetto, come si può osservare in questo esempio. Si deve quindi verificare quali pacchetti scaricare per avere il sistema antivirus completo sul proprio computer. Capita infatti molto spesso di leggere sui forum di persone che non riescono ad aggiornare il file delle firme perché non sanno che tutto il meccanismo di update si trova su un altro pacchetto! Se ClamAV non è incluso nei CD della propria distribuzione è possibile scaricare la versione sorgente all’indirizzo http://www.clamav.net/download/sources oppure cercare i binari per la propria distribuzione all’indirizzo http://www.clamav.net/download/packages/packages-linux. In questo caso però si scaricano file realizzati da terze parti. Il gruppo di sviluppo del prodotto rilascia ufficialmente solo i sorgenti. Se si utilizza una distribuzione CentOS, il pacchetto non è disponibile nei repository ufficiali. Si consiglia di aggiungere il repository di Dag Wieers alla propria configurazione (si veda a tal proposito l’Appendice F per le indicazioni sulla configurazione). In seguito sarà sufficiente digitare il seguente comando per l’installazione: yum install clamav

Il software per l’aggiornamento delle firme si trova all’interno di questo pacchetto. Non serve quindi l’installazione di niente altro. Se si utilizza Ubuntu Server Edition, basta impartire il comando seguente per installare l’antivirus e il sistema di aggiornamento: apt-get install clamav

Scansioni manuali del filesystem Usare ClamAV è molto semplice, in quanto basta utilizzare questo comando: clamscan

Usando questa sintassi si esegue il controllo dei file presenti nella directory corrente, senza però scendere nelle sottocartelle. Si ha cioè una scansione a un singolo livello del filesystem. Per avere un controllo completo si deve usare questa sintassi: clamscan -r

In questo modo verrà attivata una scansione ricorsiva in profondità a partire dalla directory in cui si è posizionati. Non verrà quindi eseguito un controllo completo di tutto il file system a partire dalla radice. Per richiedere una scansione di tutto il sistema si deve specificare il percorso di root: clamscan -r /

Con lo stesso principio è possibile eseguire scansioni a richiesta su qualunque percorso del proprio sistema. Il comando clamscan esegue però solamente un’operazione di ricerca. Se viene individuato un virus, questo sarà solo segnalato e non eliminato. Per ottenere l’eliminazione automatica dei virus è necessario un ulteriore comando: clamscan -r --remove /home/szanzi

L’opzione --remove attiva la funzionalità di rimozione virus sulla ricerca ricorsiva operata a partire della directory /home/szanzi. Per testare il corretto funzionamento del sistema antivirus si consiglia di usare il file di test EICAR. Si tratta di un file contenente una stringa riconosciuta da tutti gli antivirus moderni. Il file è del tutto innocuo, ma viene individuato dagli antivirus, attivando la stessa reazione che si avrebbe con un virus reale. Per ottenere questo file si può accedere direttamente al sito http://www.eicar.org/anti_virus_test_file.htm e scaricare uno dei file presenti in fondo alla pagina (Figura 10.2).

Figura 10.2 File di test EICAR per la verifica dell’antivirus.

Aggiornamenti Fino a questo punto il sistema antivirus ClamAV è stato utilizzato nella forma in cui è stato incluso nella propria installazione. I file delle firme non saranno certamente aggiornati o in alcuni casi potrebbero addirittura non essere presenti. In questo caso compare un messaggio d’errore eloquente, a indicare la mancanza del database virale. Nel caso in cui le definizioni siano semplicemente obsolete si avrà questo messaggio di avvertimento: Listato 10.1

LibClamAV LibClamAV LibClamAV LibClamAV

Warning: Warning: Warning: Warning:

************************************************** *** The virus database is older than 7 days. *** *** Please update it IMMEDIATELY! *** **************************************************

Non resta che eseguire manualmente l’update delle firme. Prima però si deve eseguire un controllo all’interno del file /etc/freshclam.conf. Questo è dotato di una “sicura” che impedisce l’aggiornamento di

ClamAV in alcune installazioni di default. Questa impostazione va rimossa aprendo il file e cercando, subito all’inizio, questo blocco: # Comment or remove the line below. Example

Occorre semplicemente commentare o rimuovere la voce Example. A questo punto si può impartire il seguente comando: freshclam

L’output che si otterrà sarà molto simile a questo: Listato 10.2

[root@giove home]# freshclam ClamAV update process started at Sat Jul 17 17:08:58 2010 main.cvd is up to date (version: 52, sigs: 704727, f-level: 44, builder: sven) Downloading daily-11389.cdiff [100%] daily.cld updated (version: 11389, sigs: 102988, f-level: 53, builder: guitar) bytecode.cld is up to date (version: 31, sigs: 7, f-level: 53, builder: nervous) Database updated (807722 signatures) from db.it.clamav.net (IP: 213.92.8.5)

Gli aggiornamenti devono essere eseguiti con una cadenza almeno giornaliera. Intervalli più lunghi invaliderebbero la qualità del prodotto. Il team di ClamAV addirittura suggerisce di eseguire un controllo ogni ora. Vi sono due modi per automatizzare il download degli aggiornamenti. Il sistema più semplice da implementare consiste nell’utilizzo del cron di sistema. Basta aprire il file /etc/crontab e inserire un job di programmazione. La documentazione di ClamAV suggerisce questa sintassi: N * * * * /usr/local/bin/freshclam --quiet

Al posto di N si deve inserire un valore che indica il minuto di ogni ora in cui tentare l’aggiornamento, possibilmente evitando i multipli di 10, particolarmente usati dall’utenza. Scegliendo altri slot temporali si distribuisce meglio il carico sui server del progetto ClamAV. Le firme antivirus non sono l’unico elemento a richiedere aggiornamenti costanti. Il team di ClamAV rilascia anche update del motore di scansione. Un apposito messaggio di avvertimento segnalerà l’obsolescenza del motore e inviterà l’utente a scaricare la nuova versione. Il sistema continuerà comunque a funzionare regolarmente, pur mantenendo il motore obsoleto. Si perde ovviamente in tal caso il vantaggio di usare un sistema aggiornato.

Un’alternativa commerciale: AVG ClamAV è un buon prodotto per il controllo antivirus su Linux, ma non si tratta dell’unica soluzione disponibile. Esiste infatti un ecosistema ricco di prodotti, alcuni dei quali di grande fama. Uno di questi è AVG Antivirus, un nome che si sta facendo strada nel settore della scansione virale su Windows per via della qualità, della buona politica dei prezzi e dell’alto tasso di individuazione dei virus, in molti casi rivelatosi superiore a quanto offerto dai grandi nomi storici del settore. AVG permette di valutare il prodotto tramite chiavi demo a tempo perfettamente funzionanti. Una volta concluso il test è possibile acquistare una licenza annuale o biennale, quest’ultima dal costo paragonabile a

quanto i concorrenti richiedono per la licenza di un singolo anno.

Figura 10.3 Pagina di AVG Server Edition per Linux/FreeBSD.

Dal momento che si sta configurando un server, si mostrerà in questa sede la messa in opera della versione “AVG Server Edition per Linux/FreeBSD”. La pagina del prodotto si trova all’indirizzo http://www.avg.com/it-it/product-avg-serveredition-for-linux. Questa versione di AVG Antivirus gira in maniera specifica su Linux (oppure su FreeBSD) e offre una protezione per i servizi erogati sul server, per esempio un’area file condivisa in rete con Samba oppure la posta elettronica (i sistemi supportati ufficialmente sono PostFix, QMail, SendMail ed Exim). Per cominciare si deve eseguire il download del prodotto dalla pagina http://www.avg.com/itit/product-avg-server-edition-for-linux. Si fa clic su Download Now sul box a destra e si sceglie il pacchetto RPM, per le distribuzioni basate su RedHat, come CentOS, oppure la pacchettizzazione DEB, per le distribuzioni basate su Debian, come Ubuntu. Sono anche disponibili un pacchetto binario e un pacchetto compresso tar.gz. Una volta scaricato il file di distribuzione, si lancia l’installazione. Per la CentOS basta digitare questo comando: rpm -ivh avg85lms-r812-a3371.i386.rpm

Su Ubuntu, invece, si utilizza questa sequenza: dpkg -i avg85lms-r812-a3371.i386.deb Il nome del pacchetto varia continuamente. L’esempio di cui sopra è quindi puramente indicativo.

Prima di utilizzare il prodotto è necessario applicare la chiave di attivazione ottenuta al momento dell’acquisto oppure usufruire della trial. Il file di documentazione presente in /opt/avg/avg8/doc/README contiene una chiave che può essere impiegata per le prove. La chiave viene applicata attraverso questo comando: avgctl --register XX-XXXXXX-XX-XXX-XXX-XXXXXX-XXX-XXXX Al posto della sequenza di caratteri X si deve inserire la chiave trial o la licenza effettiva recapita per posta elettronica. Si dovrebbe ottenere una conferma simile a quanto illustrato qui di seguito: Listato 10.3

AVG command line controller Copyright (c) 2010 AVG Technologies CZ License was successfully changed. Operation successful. Ora non resta che avviare il demone dell’antivirus con /etc/initd/avgd start e aggiornare le firme con il relativo comando avgupdate: Listato 10.4

[root@vCentos software]# avgupdate AVG command line update Copyright (c) 2010 AVG Technologies CZ Running update. Initializing... Downloading file: avg9infoavi.ctf Downloading file: avg9infolx.ctf Analyzing... Downloading file: u9iavi3011u2755bf.bin 1 / 1 5.04 M Analyzing... Preparing installation... Updating... 100% [========================================================================>] Update Manager component is active. Update was successfully completed.

Come per ClamAV è necessario creare una pianificazione, per scaricare gli aggiornamenti almeno una volta al giorno e avere il sistema sempre in linea con l’ultimo file delle definizioni disponibile. Ora è possibile eseguire scansioni sul filesystem locale, per esempio sulla directory corrente, impiegando il punto (.): avgscan .

In alternativa è possibile specificare qualunque percorso del file system al posto del punto (.). Per avere anche la rimozione dei virus si deve includere il parametro -clean: avgscan -clean .

Il demone dovrebbe partire automaticamente durante l’avvio del sistema. Si consiglia di verificare questo aspetto con il relativo strumento di gestione dei demoni, come per esempio ntsysv sulle distribuzioni basate du Red Hat.

Checklist ClamAV 1. Scaricare e installare il pacchetto principale di ClamAV e, se fornito a parte, il pacchetto con il sistema di aggiornamento delle firme. 2. Aggiornare immediatamente il file delle firme. 3. Creare una pianificazione oraria per la ricerca degli aggiornamenti attraverso cron.

AVG 1. Scaricare e installare il pacchetto di AVG. 2. Registrare il prodotto tramite l’apposita sequenza da riga di comando. 3. Avviare il demone avgd. 4. Aggiornare immediatamente il file delle firme. 5. Creare una pianificazione oraria per la ricerca degli aggiornamenti attraverso cron.

Capitolo 11

Capitolo 11 - Backup centralizzato con Amanda Creare copie di sicurezza dei dati importanti è una delle esigenze primarie in qualunque realtà che abbia a che fare con i computer. La perdita, l’alterazione o la manomissione delle informazioni è purtroppo un’eventualità che può interessare tutti. Le normative in merito alla gestione dei dati personali impongono tra l’altro questa pratica tra i requisiti tecnici minimi (come richiesto dal Dlgs. 30 giugno 2003, n. 196 e in particolare nel relativo Allegato B: http://www.garanteprivacy.it/garante/doc.jsp?ID=488497). È quindi fondamentale scegliere una soluzione adeguata per portare a termine tale compito. In ambiente Linux esistono molte soluzioni per il backup dei dati, comprese alcune commerciali di alto livello. Nel campo delle soluzioni liberamente disponibili primeggia Amanda, un progetto completo e ben sviluppato, mantenuto all’indirizzo http://www.amanda.org (Figura 11.1).

Figura 11.1 Pagina principale del progetto Amanda.

Amanda è stato originariamente sviluppato da James da Silva all’interno del dipartimento di Scienze dell’Informazione dell’Università del Maryland, nei primi anni Novanta, con lo scopo di salvare tramite un unico server di backup il contenuto di un numero arbitrario di workstation connesse. Si veniva così a costituire un modello centralizzato in cui il server provvedeva ad acquisire i dati dalle postazioni remote e a gestire la

copia fisica sulle unità a nastro. Il progetto Amanda è presto uscito dal suo ambito originario e, nel corso degli anni, ha raccolto un numero crescente di utenti e sviluppatori attivi.

Installazione e configurazione Amanda è un prodotto ormai storico nel panorama Unix/Linux e come tale è presente come pacchetto standard in quasi tutte le principali distribuzioni. Per verificare se il pacchetto Amanda è installato nel proprio computer si possono usare gli strumenti di gestione dei pacchetti oppure digitare il comando amcheck dalla linea di comando. Questo verifica la correttezza del file di configurazione del programma e la sua presenza indica che Amanda è installato nel sistema. Se la shell segnala che il comando è sconosciuto, bisogna installare il programma dai dischi della distribuzione o dall’archivio online dei pacchetti, sfruttando apt-get su Ubuntu o yum su CentOS. Amanda è composto da due pacchetti: amanda-server e amanda-client. Il primo contiene il sistema di backup da installare presso il server centrale, mentre il secondo pacchetto è il componente client da installare su ogni macchina che sarà protetta dal backup. I file di configurazione di Amanda si trovano in /etc/amanda, ma a differenza della maggior parte dei pacchetti presi in considerazione in questo libro, non esiste all’interno di questa directory un file di configurazione principale. Su Amanda si ha infatti un file di configurazione per ogni job specifico di backup che si è deciso di mettere in atto. Dentro la directory /etc/amanda dovranno essere create una serie di directory, ognuna dedicata a un job e all’interno di ognuna di queste vi sarà un file amanda.conf. Il file di configurazione di Amanda è composto da un certo numero di direttive, corredate da una spiegazione riassuntiva. Chi desideri approfondire può consultare il manuale del programma, considerando però che questo non è di semplice lettura, almeno all’inizio. Per prendere confidenza con Amanda si consiglia un approccio graduale, mettendo in pratica una configurazione basilare, per poi vagliare nel tempo le caratteristiche avanzate del programma. Si parte ragionando per job di lavoro, decidendo quanti processi di backup si vogliono creare, quali elementi si devono salvare e con quale frequenza. Per esempio si potrebbe effettuare un backup giornaliero e uno settimanale pianificato per ogni domenica. Il backup giornaliero potrebbe includere le cartelle personali e le cartelle generali di lavoro presenti sul server. Quello settimanale potrebbe invece comprendere l’intero contenuto del server, comprese le directory di sistema. In questo modo ci si assicura la possibilità di ripristinare tutto il server e il lavoro svolto il giorno precedente in caso di crash dei dischi fissi. In questo caso ci saranno due file di configurazione all’interno di Amanda, uno dedicato al backup giornaliero e l’altro a quello settimanale. Il primo processo verrà eseguito tutte le notti alle 23:00, dal lunedì al sabato, mentre il secondo processo verrà eseguito tutte le domeniche alle ore 20:00. Per gestire questi due processi di salvataggio si creeranno altrettante directory all’interno di /etc/amanda. La prima si chiamerà “giornaliero”, mentre la seconda “settimanale”. All’interno di entrambe le directory si creerà una copia del file di configurazione di esempio di Amanda. Prima però bisognerà modificare questo file e specificare alcuni dettagli che risultano comuni a tutti i job di backup, in particolare la definizione del tipo di unità di backup che è montata sul proprio server. Bisogna aprire il file di configurazione e scorrerlo fino a quando non si troverà una serie di blocchi di definizione di questo tipo: Listato 11.1

define tapetype QIC-60 { comment "Archive Viper" lenght 60 mbytes filemark 100 kbytes # don't know a better value speed 100 kbytes # dito } define tapetype DEC-DLT2000 { comment "DEC Differential Digital Linear Tape 2000" lenght 15000 mbytes filemark 8 kbytes speed 1250 kbytes } define tapetype HP-DAT { comment "DAT tape drives" # data provided by Rob Browning length 1930 mbytes filemark 111 kbytes speed 468 kbytes }

Ogni blocco contiene la definizione delle caratteristiche per uno specifico modello di unità a nastro, con l’indicazione per esempio della capacità o della velocità dell’unità. Qui, in particolare, sono presenti le definizioni per un’unità QIC-60, per un sistema DLT e per un più comune DAT. Il file di configurazione prosegue poi con altri blocchi di definizione per le unità a nastro. È però molto facile che la propria unità a nastro non sia contemplata tra i pochi esemplari presenti nel file di configurazione predefinito. In questi casi si può andare nel sito di Amanda (http://www.amanda.org) e fare clic sul link laterale Tape Type List. Se non si trova alcuna informazione utile si può utilizzare il comando amtapetype, che esegue una scansione dell’unità a nastro presente e fornisce in output i parametri da inserire nel file di configurazione. La sintassi del comando è la seguente per le versioni precedenti la 2.6.1: amtapetype -f nomedevice

Per nomedevice si intende il device che in Linux rappresenta l’unità a nastro montata nel computer. Dalla versione 2.6.1 le opzioni del comando sono state modificate e si deve usare questa sintassi: amtapetype nomedevice

L’opzione -f non è più usata per indicare il device di sistema. Basta quindi scrivere il percorso del dispositivo in fondo al comando. Ottenute le informazioni sulla propria unità si può creare un nuovo blocco tapetype da inserire nel file di configurazione generale. Per avere un file di configurazione ordinato si consiglia di cancellare le definizioni di esempio presenti e ottenere così un file più compatto e calibrato sulle proprie esigenze. Un passaggio cruciale nella configurazione di Amanda è stato portato a termine. Ci sono però altri dettagli da mettere a punto. Prima di tutto bisogna cambiare il parametro mailto e indicare l’indirizzo della propria casella di posta elettronica dove saranno recapitati i messaggi di segnalazione del sistema di backup. Più in basso è presente il parametro dumpuser che contiene l’utente attraverso il quale girerà il processo principale. Il nome cambia a seconda della distribuzione, in alcuni casi viene usato l’utente “amanda”, ma potrebbe essere anche “backup” oppure “amandabackup”. È importante verificare il nome con cui Amanda funziona, in modo da impostare correttamente i diritti di accesso alle directory del programma. Più in basso ci sono due parametri che permettono di ottimizzare il carico sul server e sulla rete durante il funzionamento di Amanda:

inparallel 4 netusage 600 kbps

La prima direttiva indica il numero massimo di processi simultanei che possono girare in parallelo per l’esecuzione delle attività di backup. La seconda indica invece la banda massima che sarà consumata in rete nel caso di backup di file che si trovano al di fuori del server locale. Più in basso si trovano altre impostazioni importanti: runtapes 1

Specifica il numero di unità a nastro usate per le operazioni: generalmente 1 per le unità singole; in caso di tape library si deve inserire il valore adeguato. tapedev "/dev/nst0"

In questo punto della configurazione si deve inserire il nome che, nella cartella dev, rappresenta l’unità a nastro installata nel proprio sistema. Questo stesso parametro è stato usato in precedenza con il comando amtapetype per scoprire le generalità del dispositivo. Segue un altro parametro fondamentale: tapetype HP-DAT

Attraverso questa direttiva si indica quale unità è effettivamente presente nel proprio sistema. Questa stringa deve corrispondere con l’etichetta inserita in testa alla definizione tapetype realizzata in precedenza. In questo caso si è indicato che il sistema utilizza un’unità specificata dal blocco di definizione HP-DAT.

Configurazione di un job Ora si può usare il file di configurazione generale modificato in precedenza per copiarlo nelle directory "Giornaliero" e "Settimanale".

Si deve poi andare nella directory "Giornaliero", aprire il file di configurazione amanda.conf e impostare alcuni parametri specifici per il job in oggetto: org "Giornaliero"

Questo parametro dovrebbe includere il nome della propria organizzazione, ma in genere viene inserito il nome del job di lavoro, in quanto l’etichetta viene utilizzata per generare i rapporti di funzionamento di Amanda. Questa stringa comparirà per esempio nelle e-mail di segnalazione degli eventi di backup. Meritano particolare attenzione i parametri indicati di seguito e riportati con le impostazioni di default: dumpcycle 4 weeks runspercycle 4 weeks tapecycle 25 tapes

Il primo parametro indica ogni quanto tempo deve essere eseguito almeno un backup completo. In questo esempio è indicato che il backup completo deve essere eseguito almeno una volta ogni quattro settimane. Amanda provvederà in questo modo a gestire i job di lavoro per rispettare questo limite, “dosando” i backup in maniera che vengano eseguiti il maggior numero possibile di backup incrementali. In questo modo le singole procedure di copia impiegheranno meno tempo per l’esecuzione. Si mantiene comunque la sicurezza di avere almeno un backup completo nei tempi indicati in dumpcycle.

Mettendo il valore a zero si ottiene un backup completo a ogni esecuzione. Se si impone dumpcycle a 0 bisogna impostare anche runspercycle a 0. Questo parametro indica quante volte deve essere eseguito il backup all’interno del ciclo imposto in dumpcycle. Il parametro tapecycle indica quanti nastri sono previsti nel ciclo di copia. Una volta usati i nastri previsti nel ciclo, il primo nastro del gruppo verrà nuovamente sovrascritto. Un esempio potrà chiarire meglio il significato di questi parametri. Se si desidera avere un backup completo ogni settimana e un backup incrementale ogni giorno lavorativo (dal lunedì al venerdì), si deve usare la configurazione seguente: dumpcycle 1 week runspercycle 5 days tapecycle 7 tapes

Si può semplificare la configurazione eliminando la pianificazione delle procedure di copia di Amanda e facendo in modo che sia eseguito un backup completo a ogni lancio. La configurazione dei parametri per l’esecuzione della copia giornaliera sarà la seguente: dumpcycle 0 days runspercycle 0 days tapecycle 7 tapes

In questo modo, il programma esegue il backup e poi esce. Per disporre delle copie anche nei giorni seguenti bisogna usare il meccanismo delle attività pianificate di Linux. Si vedranno i dettagli in seguito. Un errore in cui incorrono molti utenti nuovi al sistema Amanda riguarda la riga seguente di configurazione: labelstr "^giornaliero-[0-9][0-9]*$" # label constraint regex: all tapes must match

Ogni nastro inserito nel sistema Amanda deve disporre di un nome di etichetta precedentemente assegnato con un apposito comando, che sarà esaminato più avanti. Amanda accetta però solamente i nastri che hanno un’etichetta compatibile con l’espressione regolare indicata nella riga labelstr precedente. In questo caso i nastri dovranno chiamarsi, per esempio, giornaliero-01, giornaliero-02 e così via. Un nastro con nome settimanale-1 sarebbe pertanto scartato da questo job di lavoro. L’ultimo aspetto rilevante per la configurazione del job di backup è il seguente blocco di configurazione: Listato 11.2

holdingdisk hd1 { comment "main holding disk" directory "/var/tmp" use 1200 Mb chunk 512 Mb }

Questa è la definizione dell’area temporanea di lavoro utilizzata da Amanda per gestire i backup prima che questi siano trasferiti fisicamente sui nastri. Viene specificata la directory nel file system di Linux con il parametro directory e lo spazio massimo che può essere utilizzato tramite il parametro use. Indicando uno zero verrà usato tutto lo spazio disponibile. Si può inserire anche un valore negativo, per esempio -2 GB. In questo caso sarà usato tutto lo spazio sul disco meno 2 GByte. Il parametro chunk fa in modo che l’immagine di backup sia spezzata in tanti file della dimensione specificata. Questo non ha influenza sul backup finale, che in ogni caso è gestito in maniera contigua. Il parametro ha invece importanza sul file system, per esempio per evitare che il file di backup possa superare la

dimensione massima di file prevista dal sistema operativo (in alcuni sistemi è limitata a 2 GB). È importante impostare anche i parametri seguenti: infofile "/var/lib/amanda/giornaliero/curinfo" logdir "/var/lib/amanda/giornaliero" indexdir "/var/lib/amanda/giornaliero/index"

La prima riga imposta il file che contiene le informazioni storiche del job, la seconda il nome del file di log, mentre la terza indica la directory dove memorizzare gli indici della procedura di backup. Bisogna naturalmente avere l’accortezza di creare queste directory e impostare i diritti corretti prima di lanciare Amanda.

Selezione dei file La configurazione generale del job è pronta. Ora bisogna stilare l’elenco delle directory da salvare. Questo deve trovarsi nella stessa directory della configurazione di Amanda e deve chiamarsi disklist. Il file è organizzato per tre colonne: la prima indica il nome del sistema da cui saranno copiati i dati, la seconda contiene il percorso che si intende copiare, mentre la terza fa riferimento a dumptype. Qui di seguito viene presentato un esempio: localhost /home comp-high localhost /root comp-high

In questo elenco di backup viene indicato che si vogliono salvare le informazioni che si trovano sul server locale, vengono elencati i percorsi /home e /root per la copia e infine viene usato il dumptype comp-high. Trattandosi di un backup di rete, si potevano specificare anche indirizzi e percorsi verso macchine raggiungibili dal server. Il dumptype è una direttiva che segnala ad Amanda come gestire la copia per quanto riguarda i parametri di compressione, la priorità del processo ed eventuali file da escludere dal backup. Vi sono diversi dumptype impostati per default nel file principale di configurazione di Amanda e raccolti nella parte finale del file. Qui di seguito sono riportati a titolo di esempio alcuni di questi dumptype: Listato 11.3

define dumptype nocomp-root { comp-root comment "Root partitions without compression" compress none } define dumptype comp-high { global comment "very important partitions on fast machines" compress client best priority high } define dumptype nocomp-high { comp-high comment "very important partitions on slow machines" compress none } define dumptype nocomp-test {

global comment "test dump without compression, no /etc/dumpdates recording" compress none record no priority medium }

In questo estratto, in seconda posizione, è presente anche la definizione per il dumptype comp-high, utilizzata nell’esempio precedente. Si applica la massima compressione ai dati e la massima priorità di esecuzione. Le definizioni di dumptype sono completamente personalizzabili e se ne possono creare di nuove per le proprie necessità, come in questo ulteriore esempio: Listato 11.4

define dumptype tar-high { program "GNUTAR" comment "tar dump" options exclude-list "/etc/amanda/giornaliero/excludelist" priority high }

Viene creato un dumptype denominato tar-high, che esegue la compressione attraverso il comando tar e che opera con priorità high. Qui è interessante notare che è stato anche inserito un elenco di esclusioni, tramite options excludelist. Questo file ha una struttura molto semplice: contiene l’elenco di directory e file che si vogliono escludere dalla copia. I percorsi indicati possono contenere anche caratteri jolly, per esempio: *.log *.tmp /cfg/*/*.conf

La fase di configurazione è terminata. Prima di procedere è bene verificare la funzionalità delle configurazioni con il comando amcheck. Questo analizza la configurazione creata e segnala eventuali errori. La sintassi è la seguente: amcheck directoryconfigurazione

Si deve cioè indicare la directory dove è contenuto il file di configurazione da controllare. Non è necessario preporre la radice di Amanda (/etc/amanda) e neppure il nome del file di configurazione (amanda.conf), perché vengono inseriti automaticamente. Per l’esempio esposto in questo capitolo si deve usare questa sequenza: amcheck giornaliero

Saranno eseguiti parecchi controlli e segnalati tutti i problemi. In particolare si devono controllare gli errori di percorso, le directory assenti e i diritti utenti assegnati alle cartelle di Amanda.

Funzionamento Ora si può passare alla fase operativa. Prima di tutto si deve verificare che i servizi di Amanda siano attivi

sui sistemi client interessati dal backup. Il server stesso potrebbe fungere anche da client di Amanda nel caso si voglia eseguire backup di file. Su CentOS si consiglia di lanciare ntsysv e da questo strumento attivare amanda, amandaidx e amidxtaped. Su Ubuntu dovrebbero essere state attivate automaticamente le configurazioni di xineted e del file /etc/services durante l’installazione del pacchetto client di Amanda. A prescindere dalla distribuzione usata, si deve controllare che esista nel sistema l’utente usato dal componente client e che questo abbia diritto di accesso alle directory che saranno copiate attraverso il backup. I file dei servizi di Amanda sono presenti in /usr/lib/amanda oppure in /usr/lib64/amanda. Completate le operazioni sui client bisogna impostare le giuste etichette ai nastri del set appena configurato. Bisogna inserire il primo nastro nell’unità, attendere qualche istante e digitare il seguente comando sulla macchina server: amlabel -f directoryconfigurazione etichetta

per esempio: amlabel -f giornaliero giornaliero-01

Potrebbe essere visualizzato un errore che segnala l’assenza del file tapelist. Si tratta di un file di supporto di Amanda impiegato per memorizzare l’elenco dei nastri utilizzati. Per risolvere l’errore si può creare un file di testo nullo con tale nome all’interno di /etc/amanda/giornaliero. L’operazione di etichettatura è immediata. Concluso il primo nastro si deve procedere con i nastri successivi e fornire un nome progressivo a tutte le cartucce (giornaliero-02, giornaliero-03 e così via). Il salvataggio avviene con un meccanismo client-server. Il server cioè provvede a recuperare tutti i file da salvare dai dischi o dai percorsi indicati nel file disklist. Come visto in precedenza, la prima riga del file contiene il nome della macchina nella quale reperire i file (nell’esempio localhost). È possibile salvare dati da un numero arbitrario di client distribuiti nella rete locale. Nell’esempio trattato vi è un unico client da prendere in considerazione per il backup: il server stesso. Anche in questo caso Amanda lavorerà in modalità client-server. Il componente server si collegherà al componente client locale e preleverà tutti i file necessari alla procedura di backup. Questa funzione è però regolata da un meccanismo di privilegi. Esiste cioè su ogni client un file in cui è contenuto l’elenco degli utenti e delle macchine server autorizzate a prelevare i file presenti localmente. Se non ci fosse questa protezione, chiunque potrebbe fare backup non autorizzati dei dati. Si deve entrare nella home di Amanda, aprire con un editor il file .amandahosts e inserire alcune righe di configurazione per autorizzare il componente server di Amanda a prelevare file sul sistema locale: cd ~amanda vi .amandahosts

Su alcune distribuzioni potrebbe non esistere un utente di default e una home directory per Amanda. Ubuntu ne è un esempio: in questa distribuzione l’elenco degli host autorizzati si trova in /var/backups, un link al file /etc/amandahosts. Dentro il file vi saranno alcune righe impostate di default, alle quali bisogna aggiungerne altre. Il risultato finale dovrà essere il seguente: Listato 11.5

localhost amanda localhost.localdomain amanda localhost root

localhost.localdomain root server1 root server1 amanda

Si è così autorizzato l’utente root e l’utente amanda provenienti dagli host localhost, localhost.localdomain e server1 (il nome assegnato al server locale) ad accedere ai file locali. Ora si può lanciare il backup con questa semplice sintassi: amdump directoryconfigurazione

per esempio: amdump giornaliero

Per capire l’andamento della procedura di backup bisogna controllare con attenzione i file di log. Questi sono molto chiari e descrittivi ed è quindi facile capire gli errori che stanno impedendo il corretto funzionamento del processo di salvataggio.

Pianificazione Il job appena creato è pronto per essere inserito in un processo di pianificazione attraverso gli strumenti di Linux. L’installazione standard di Amanda fornisce un buon esempio di configurazione del servizio cron. Questo esempio è riportato qui di seguito con le opportune modifiche: Listato 11.6

# This is an example for a crontab entry for automated backup with amanda # With these cron lines, Amanda will check that the correct tape is in # the drive every weekday afternoon at 4pm (if it isn't, all the # operators will get mail). At 12:45am that night the dumps will be run. # # This should be put in user operator's crontab # 30 16 * * 1-5 /usr/sbin/amcheck -m giornaliero 0 23 * * 1-5 /usr/sbin/amdump giornaliero

Le righe significative sono ovviamente le ultime due, che devono essere riportate fedelmente nel file crontab presente in /etc, dopo le righe già esistenti. Si ricorda che il formato del file crontab è il seguente:

In ogni colonna si può specificare un valore numerico, un intervallo, un elenco, una frequenza oppure un asterisco per indicare qualunque occorrenza. La prima riga lancia il comando amcheck alle ore 16:30 del pomeriggio di ogni giorno di ogni mese, dal lunedì al venerdì (intervallo 1-5, perché la settimana inizia il lunedì e finisce la domenica). Il parametro -m di amcheck fa in modo che non venga stampato alcun output. Questa operazione verifica la presenza della cartuccia dentro l’unità a nastro. In caso di assenza viene generato un errore, inoltrato immediatamente per posta elettronica all’amministratore di sistema. Dal momento che il test viene lanciato in orario lavorativo, il responsabile dei backup riceve la notifica quando è ancora in

azienda e ha così l’opportunità di inserire la cassetta ed evitare che il backup fallisca più tardi. La seconda riga lancia invece il backup alle ore 23:00, dal lunedì al venerdì. Passando ora al backup settimanale si deve prevedere la seguente riga di crontab: 0 20 * * 7 /usr/sbin/amdump settimanale

Il job viene cioè lanciato alle ore 20:00 di ogni domenica.

Ripristino La procedura di ripristino con Amanda avviene tramite l’utility interattiva amrecover. Per lanciarla è sufficiente specificare il job da cui si intende recuperare i file, per esempio: amrecover giornaliero

A questo punto il client carica tutte le informazioni relative alla struttura delle directory per questo processo, fornendo un file system virtuale. È così possibile navigare all’interno di questo volume virtuale con comandi quali cd, ls, pwd e così via. Bisogna quindi selezionare il disco o il percorso che si intende recuperare tra quelli indicati nel file disklist relativo a questo processo: setdisk /home

Ora basta indicare gli elementi da ripristinare con il comando add, seguito dall’elemento da recuperare. È naturalmente possibile selezionare tutti gli elementi desiderati, digitando i relativi comandi add, uno di seguito all’altro. Quando la selezione è conclusa, basta impartire extract per attivare la procedura. Verrà richiesto il nastro dove sono presenti i file e il materiale richiesto verrà recuperato all’interno della directory corrente. Bisogna perciò ricordarsi di spostarsi in una directory di appoggio prima di lanciare il ripristino, evitando di sovrascrivere le aree di lavoro. Conclusa la procedura si può uscire dal client digitando exit. In caso di necessità è possibile digitare in qualsiasi momento dentro il client il punto interrogativo, per ottenere una breve pagina di testo con l’elenco dei comandi supportati. Questo client di ripristino è comodo per estrarre un numero limitato di elementi. Se sussiste la necessità di recuperare un intero backup è meglio usare il comando amrestore, con la seguente sintassi: amrestore nomeprocesso

Verrà così estratto dal nastro inserito nell’unità tutto il materiale relativo al processo specificato. Il materiale verrà estratto in una directory con il formato hostname.diskname.datestamp.dumplevel.

Affidabilità Per migliorare l’affidabilità del sistema è bene pianificare giornalmente il comando amverify a seguito del backup. Questo esegue una verifica di coerenza del backup eseguito, controllando che sia leggibile dallo strumento restore di Amanda e dal programma di compattazione utilizzato per il processo (per esempio tar). A fine procedura viene segnalato il successo o il fallimento dell’operazione.

La coerenza si verifica facendo seguire al comando il nome del processo: amverify giornaliero

La configurazione di Amanda è quasi conclusa. Prima però di affidare il proprio server di produzione ai backup su Amanda bisogna compiere alcuni test per controllare che la configurazione sia corretta e che i job siano stati definiti in maniera regolare. A tal proposito, si deve eseguire un certo numero di backup su nastro e provare a ripristinare alcuni file scelti a campione, per accertarsi che il salvataggio venga effettivamente eseguito. Un controllo dei file di log è molto utile per scoprire eventuali anomalie. Superata questa fase bisogna programmare i backup tramite il file crontab e far funzionare il sistema per qualche giorno. Ancora una volta bisogna fare test di recupero dai nastri salvati e accertarsi che i file siano stati effettivamente memorizzati e che siano recuperabili. Solo a seguito di questa fase di test si può considerare il sistema affidabile e pronto per la fase operativa. A regime bisogna comunque esaminare con cura i messaggi inviati da Amanda e controllare i file di log. A intervalli regolari bisogna anche tentare qualche recupero, per accertarsi che il sistema stia funzionando regolarmente. I controlli non si fermano comunque alla parte software. Le unità di backup a nastro sono sistemi molto delicati, costituiti da numerose parti meccaniche in movimento. Sono quindi soggetti a usura e a rotture, a volte anche frequenti. Le testine tendono inoltre ad accumulare detriti, che possono degradare il segnale durante le operazioni di lettura e scrittura. Bisogna perciò utilizzare con regolarità un nastro di pulizia. Infine si deve continuare nel tempo a fare procedure di recupero a campione per controllare che i backup siano coerenti e che tutto stia funzionando a dovere. La presenza di un backup non deve essere un alibi per abbassare la guardia e tralasciare i controlli.

Cancellare un nastro È possibile azzerare completamente il contenuto di un nastro attraverso l’uso di un’utility esterna ad Amanda, denominata mt. Si tratta di uno strumento che svolge diverse funzioni di basso livello. Per verificare la presenza del programma è sufficiente digitare mt e osservare l’output. Se è simile a quanto illustrato di seguito, il programma è presente nel proprio sistema. Listato 11.7

root@linuxcage:~# mt Usage: mt [-V] [-f device] [--file=device] [--rsh-command=command] [--help] [--version] operation [count] root@linuxcage:~#

Se viene visualizzato un errore di shell, è necessario installare il software con i tool di gestione pacchetti messi a disposizione dalla propria distribuzione. Il nome del pacchetto è mt-st. Ora non resta che inserire il nastro nell’unità e impartire il seguente comando: mt -f /dev/nst0 erase

L’opzione -f serve per specificare il device di sistema cui corrisponde l’unità nastro installata (in questo esempio /dev/nst0), mentre l’opzione erase esegue la cancellazione completa del nastro. Attenzione al fatto che l’operazione potrebbe richiedere molto tempo.

Backup su disco È possibile simulare i nastri su normali dischi rigidi e avere così l’opportunità di sfruttare sistemi di storage di rete, come soluzioni NAS o ancora meglio ambienti SAN. In molti casi si tratta di una strada obbligata, visti i limiti di spazio dei nastri e il costo elevato di questi sistemi. Simulare i nastri sul disco non richiede di stravolgere le configurazioni di Amanda precedentemente realizzate. Si tratta piuttosto di applicare alcuni parametri specifici ed eseguire una serie di operazioni preliminari. Per cominciare si deve allocare lo spazio su disco che sarà dedicato al backup. Si può usare una directory locale, si può agganciare un nuovo disco al filesystem oppure si può montare un disco di rete. Se il filesystem è in grado di “vedere” lo storage, questo può essere usato per i backup. Per questo esempio si suppone di aver collegato l’area disco in /vtape. Ora è possibile simulare un’unità nastro tradizionale. Si tratta però di una modalità limitativa e scomoda. Si consiglia piuttosto di simulare un tape changer con un certo numero di nastri all’interno, che saranno utilizzati a rotazione. Per farlo è necessario usare Amanda in versione 2.6.1 o superiore. Si deve verificare questo requisito prima di procedere. Il primo passo consiste nello specificare un tapetype specificando le dimensioni del nastro: define tapetype HARD-DISK { comment "Backup su disco" length 2048 mbytes }

In questo caso si useranno nastri su disco da 2 GB. Tale definizione deve essere agganciata alla configurazione generale con la seguente direttiva: tapetype HARD-DISK

Si elimina cioè ogni riferimento attivo alle unità nastro tradizionali, in favore dello spazio su disco. Ora si può attivare la modalità tapechanger tramite questo parametro nel file di configurazione: tpchanger "chg-disk:/vtape"

Occorre specificare il percorso dell’unità simulata nel filesystem subito dopo chg-disk:, senza spazi. Dentro la directory /vtape si deve creare un certo numero di slot per simulare gli alloggiamenti nastri del tape changer. Per farlo è sufficiente creare un certo numero di directory con il nome slotn, dove n è un numero progressivo, per esempio: /vtape/slot1 /vtape/slot2 /vtape/slot3 /vtape/slot4 /vtape/slot5 /vtape/slot6 /vtape/slot7 /vtape/slot8

Bisogna infine assegnare un nome ai nastri negli slot, con una sequenza di comandi simili a questo: amlabel giornaliero giornaliero-01 slot 1

Viene etichettato il nastro presente nello slot 1 con il nome giornaliero-01 usando come riferimento il job giornaliero. Ora si è pronti per procedere. La configurazione e la pianificazione dei job, come pure le modalità operative di Amanda, restano identiche a quanto esaminato per i nastri tradizionali. Come sempre, prima di proseguire, si consiglia di verificare tutta la configurazione con il comando amcheck: amcheck giornaliero

Checklist 1. Verificare la presenza di Amanda digitando il comando amcheck. Se il comando restituisce un errore, il pacchetto non è presente e bisogna procedere a installare Amanda dai dischi della propria distribuzione, dal sito ufficiale (www.amanda.org) o dai repository. 2. Stabilire il piano di backup che si intende mettere in atto. 3. Entrare nella directory /etc/amanda e creare una directory per ogni processo di backup che si intende mettere in atto. 4. Aprire il file di configurazione di default di Amanda e specificare alcuni dettagli comuni a tutti i processi di backup. 5. Specificare, tramite la direttiva define tapetype, il tipo di unità a nastro montato sul proprio sistema. Se non è possibile reperire la definizione per la propria unità si può usare il comando amtapetype. 6. Inserire nella direttiva mailto l’indirizzo di posta elettronica dell’amministratore. 7. Verificare l’utente con cui funzionerà Amanda, controllando la direttiva dumpuser e controllare che l’utente abbia i diritti per accedere alle directory di Amanda sul server e sulle aree da copiare sui client. 8. Ottimizzare il carico che Amanda comporterà sul server e sulla rete (direttive inparallel e netusage). 9. Indicare il numero di unità a nastro (direttiva runtapes). 10. Specificare il nome Linux della periferica cui è associata l’unità a nastro (direttiva tapedev) e il tipo di unità a nastro che Amanda utilizzerà (direttiva tapetype). 11. Copiare il file di configurazione generale di Amanda in ognuna delle cartelle create al punto 3 per gestire i singoli processi. 12. Entrare nella directory di processo, aprire il file di configurazione e impostare nella direttiva org il nome del processo. 13. Indicare i dettagli del backup (direttive dumpcycle, runspercycle e tapecycle). 14. Impostare il formato delle etichette dei nastri nella direttiva labelstr. 15. Impostare la directory di appoggio di Amanda (blocco holdingdisk). 16. Verificare i parametri infofile, logdir e indexdir. 17. Creare il file disklist con l’elenco delle directory che si intendono salvare. Se necessario, creare anche il file di esclusione per togliere elementi dalle directory specificate in disklist. 18. Verificare la correttezza della configurazione tramite il comando amcheck. 19. Ripetere i punti dal 12 al 18 per ogni processo di backup. 20. Impostare i nomi sui nastri con il comando amlabel.

21. Aprire il file di autorizzazione .amandahosts sui client e indicare gli utenti e i sistemi autorizzati a prelevare file per il backup. 22. Verificare sui client che i servizi di Amanda siano attivati all’avvio del sistema. 23. Programmare i processi di backup modificando il file /etc/crontab. 24. Eseguire una sessione di test e di ripristino prima di utilizzare Amanda in produzione.

Capitolo 12

Capitolo 12 - Gestione della posta elettronica con Kerio Connect La posta elettronica è l’applicazione Internet di maggiore successo e costituisce oggi un servizio mission critical anche per le realtà più piccole. Un black-out sul servizio mail può infatti generare una serie di effetti spiacevoli. Non si vorrebbe infatti che una comunicazione importante, inviata magari da un cliente strategico, venga persa o resti in attesa in qualche punto indefinito della Rete. In caso di problemi non è poi detto che sia possibile avvertire tutti i propri contatti e dirottare le comunicazioni su altri mezzi. Ordini e missive importanti potrebbero in tal caso rimanere del tutto ignorati senza che l’azienda sia a conoscenza della loro esistenza. Si tratta di una situazione non accettabile. Molte aziende si affidano a provider esterni per l’intera gestione della posta elettronica, a volte sfruttando una delle tante offerte gratuite disponibili. Queste soluzioni possono essere valide, ma dimostrano dei limiti quando aumentano le necessità di velocità, flessibilità e controllo. Per risolvere tutti questi problemi e avere una soluzione estremamente gestibile è possibile installare un server di posta elettronica all’interno della propria organizzazione.

Linux come mail server Un sistema Linux può svolgere il compito di mailserver aziendale in maniera brillante, a patto di configurare correttamente il servizio e di dedicare nel tempo le dovute risorse per la gestione e la manutenzione. Le soluzioni Open Source disponibili in ambito Linux sono di qualità elevata, ma la loro configurazione risulta difficile. È infatti necessario assimilare molti concetti specifici prima di essere in grado di mettere in pratica una configurazione funzionante. Non esiste poi un unico prodotto Open Source in grado di svolgere tutte le funzioni richieste a un mail server. Piuttosto si devono armonizzare più pacchetti, nati in maniera del tutto indipendente. Bisogna infine lavorare molto sulla sicurezza, aspetto cruciale per evitare che il proprio server diventi un amplificatore di spam e phishing. Tutto questo è di difficile gestione per un utente alle prime esperienze con Linux. Per questo motivo, in questo capitolo si farà riferimento a una soluzione commerciale di buon livello, facile da installare e dotata di tutti i protocolli necessari per l’erogazione dei servizi di posta elettronica. Trattandosi di una soluzione commerciale si deve però sostenere un costo di licenza, come contropartita per la facilità di installazione e gestione. Nel prossimo capitolo sarà invece illustrato il modo per mettere in funzione un sistema di posta elettronica con strumenti Open Source. Non si avranno costi per il software, a discapito però della facilità di installazione e di gestione nel tempo.

Kerio Connect Il programma utilizzato in questo capitolo si chiama Kerio Connect ed è disponibile all’indirizzo http://www.kerio.com/connect (Figura 12.1). Qui di seguito sono elencate le funzionalità principali del

prodotto:

protocollo SMTP (versione standard e sicura); protocollo POP3 (versione standard e sicura); protocollo IMAP (versione standard e sicura); protocollo NNTP (versione standard e sicura); protocollo LDAP (versione standard e sicura); doppio sistema web mail, uno avanzato in stile Ajax e uno standard HTML per i client leggeri; supporto per groupware (rubriche, calendari, note e attività) con tool di migrazione da Exchange; groupware con base dati centralizzata, compatibile con Outlook e basato sul protocollo di Exchange; supporto per smartphone iPhone, Windows Mobile, Symbian e Android, con sincronizzazione OTA in tempo reale; integrazione con BlackBerrys Enterprise e BlackBerry Enterprise Express per la gestione e sincronizzazione OTA di dispositivi BlackBerry; filtro antispamming bayesiano, greylisting e black list dinamiche; supporto antivirus commerciale; meccanismi di protezione contro l’open relay; supporto per la gestione di mailing list e gruppi di discussione; supporto per un numero illimitato di domini; sistema grafico di amministrazione; sistema di rapporti sia testuali sia grafici sull’andamento del server, con generazione di allarmi in caso di emergenza; backup automatici della configurazione e della base dati; supporto per i servizi di directory. Kerio Connect è un prodotto multipiattaforma, compatibile con i sistemi operativi Windows, Linux e Mac OS X. Su Linux sono supportate le distribuzioni RedHat, SuSE e CentOS tramite pacchetti RPM e Debian e Ubuntu tramite pacchetti DEB.

Figura 12.1 Pagina ufficiale di Kerio Connect.

Un aspetto interessante connesso alla natura multipiattaforma di questo gestore della posta è che non dipende in maniera specifica da alcun sistema operativo. La sua configurazione, in particolare, è interamente contenuta in due file di testo di piccole dimensioni, situati nella directory del programma. È possibile salvare questi due file su una chiavetta USB e trasportare la configurazione da una macchina a un’altra semplicemente sostituendoli. Non importa quale sia il sistema operativo usato: la configurazione realizzata per Windows continuerà a funzionare allo stesso modo su una macchina con Linux come su una con Mac OS X (si devono ovviamente modificare i percorsi, differenti su ogni sistema operativo). Kerio Connect, inoltre, funziona attraverso un unico demone che integra tutte le funzionalità elencate precedentemente. Usando soluzioni tradizionali su Linux sarebbe stato necessario installare e configurare almeno sette pacchetti differenti. Questa integrazione semplifica la fase iniziale di installazione e di configurazione e facilita l’amministrazione dei servizi.

Installazione del prodotto La prima fase del processo di installazione consiste nel disabilitare qualunque servizio di posta elettronica installato sul server. Bisogna controllare i demoni attivi tramite ntsysv oppure chkconfig e disattivare eventuali servizi SMTP e POP3 presenti, come Sendmail, Postfix, QMail, Exim e così via. La sintassi del comando chkconfig è la seguente: chkconfig sendmail off

Completata questa fase, si può scaricare l’archivio di distribuzione per la versione Linux dal sito di Kerio all’indirizzo http://www.kerio.com/connect/download. Oltre al pacchetto principale, in questa pagina si trovano il Kerio Active Directory Extension (per mappare gli utenti mail da un sistema Active Directory di Windows), Kerio Open Directory Extensions (per mappare gli utenti da Open Directory su Mac) e il Kerio Connector for BlackBerry (per collegare il sistema di mail a BlackBerry Enterprise). Una volta scaricato il pacchetto principale, bisogna verificare le dipendenze. Kerio Connect necessita del pacchetto compat-libstdc++. Se questo non è presente bisogna procedere alla sua installazione dai dischi della distribuzione del sistema operativo o ricorrendo ai servizi di aggiornamento on-line. Completato questo passaggio, si può lanciare l’installazione di Kerio Connect tramite il seguente comando: rpm -i kerio-connect-versione-linux.rpm

Al posto di versione si dovrà scrivere il numero di release del pacchetto scaricato. Se la procedura è stata eseguita correttamente, si otterrà un output simile al seguente: [root@vCentos ~]# rpm -i kerio-connect-7.1.0-1792-linux.rpm Thank you for installing Kerio Connect 7.1.0! Please consult LINUX-README file for essential instructions on how to operate Kerio Connect in Linux operating environment. To view the README file, type less /opt/kerio/mailserver/doc/LINUX-README

La procedura di installazione è molto veloce e crea la directory /opt/kerio/mailserver, all’interno della quale vengono copiati i file del programma. Tra questi file è presente anche l’eseguibile cfgwizard, una procedura guidata per le principali operazioni di configurazione da lanciare subito dopo l’installazione. Questa è la sequenza da digitare: cd /opt/kerio/mailserver ./cfgwizard

La prima schermata della procedura richiede il nome del dominio principale che sarà gestito dal sistema di posta elettronica, per esempio incipit.biz, e un nome per il server, per esempio mailserver. Se non si possiede un dominio, ma per la posta elettronica si usa un provider gratuito è possibile adottare un dominio interno di propria scelta, per esempio incipit.local. La seconda schermata richiede l’inserimento delle generalità dell’amministratore. Di default la user-id è Admin, mentre la password deve essere indicata manualmente. Al passaggio successivo viene chiesto di indicare in quale posizione salvare i messaggi di posta elettronica gestiti dal server. Viene proposto un percorso di default, che può essere confermato. A questo punto non resta che fare clic sul pulsante Finish per completare la procedura di configurazione iniziale del sistema. La procedura guidata di prima configurazione provvede anche a inserire il demone di Kerio tra i servizi avviati automaticamente all’accensione del sistema. Al riavvio, il sistema di posta elettronica sarà dunque già pronto per l’uso. A questo punto è possibile accedere al pannello di amministrazione del prodotto. Questo è di tipo web e non richiede l’installazione di alcun componente binario. È sufficiente aprire il browser e indirizzarlo verso la porta 4040 in HTTPS, come nell’esempio seguente: https://192.168.0.210:4040/admin

L’indirizzo IP dovrà naturalmente essere modificato per essere compatibile con la propria installazione.

Se si vuole amministrare il mailserver dall’esterno è necessario impostare il router e il firewall in modo che rendano la porta 4040 accessibile da Internet.

Configurazione generale La configurazione del sistema inizia con alcuni dettagli di natura generale. Bisogna aprire il pannello web di amministrazione (Figura 12.2) e scegliere Configurazione/Servizi.

Figura 12.2 Schermata di log-in al pannello di configurazione di Kerio Connect.

Nell’area di destra della schermata compariranno i servizi di Kerio. I protocolli principali, da tenere sempre attivi, sono SMTP, POP3 e HTTP. I primi due gestiscono la posta in uscita e in entrata, mentre il terzo presiede al funzionamento della webmail (Figura 12.3). È possibile fare clic su ogni protocollo e specificare un elenco di indirizzi IP autorizzati ad accedere al servizio, il numero massimo di connessioni simultanee consentite ed eventualmente un numero di porta di riferimento diverso da quello di default.

Figura 12.3 Pannello dei servizi di Kerio Connect.

Di tutti i protocolli è presente anche una versione sicura, veicolata cioè tramite un canale cifrato. È consigliabile mantenere attivi questi servizi, per consentire di rapportarsi anche con i sistemi e gli utenti più attenti alla sicurezza. Per quanto riguarda gli altri protocolli, IMAP permette di gestire caselle di posta elettronica centralizzate, NNTP gestisce il servizio newsgroup, LDAP fornisce i servizi di directory; quest’ultimo, in particolare, serve nel caso in cui si utilizzino funzioni di groupware. Ogni protocollo può essere fermato, riavviato e anche disattivato, in modo che non venga più lanciato automaticamente all’avvio del demone di Kerio. Tutti i protocolli non utilizzati andrebbero disattivati in maniera stabile, per evitare di esporre il sistema ad attacchi lasciando in attività servizi che in realtà non vengono utilizzati. Completata l’attivazione dei protocolli, si può passare alla sezione Domini. In alto, in una barra testuale blu allineata a sinistra, compare il nome del server, sotto il quale viene riportato l’elenco dei domini configurati. Durante la prima fase della configurazione è presente un solo dominio: quello indicato nella procedura guidata iniziale. Facendo clic sul dominio in oggetto è possibile visualizzarne le proprietà, che compaiono all’interno di una finestra di dialogo esaustiva (Figura 12.4). Le impostazioni di default sono sufficienti per il normale funzionamento del programma.

Figura 12.4 Pannello di configurazione delle proprietà dei domini.

A ogni dominio è possibile associare una frase descrittiva, uno o più alias, una nota a piè pagina da applicare a tutte le mail, delle regole di inoltro (forwarding), un servizio di directory e impostare meccanismi di autenticazione avanzati. Tutte queste funzionalità possono essere impostate in questa finestra, attraverso apposite schede. La Nota a piè pagina è un testo che è possibile apporre in fondo a ogni messaggio che transita per il sistema. Può essere utile per indicare gli estremi della propria azienda, una nota sulla privacy oppure un messaggio pubblicitario. In questo modo, tutte le mail conterranno il blocco di testo stabilito dall’amministratore. La funzionalità di Inoltro permette di smistare a un altro server di posta le e-mail indirizzate a caselle inesistenti nel dominio che si sta configurando. La scheda Servizi directory permette di agganciarsi a Microsoft Active Directory oppure ad Apple Open Directory e trarre l’elenco degli utenti da tali database. In questo modo non sarà necessario riscrivere a mano l’elenco degli utenti, perché questo sarà generata a partire dagli elenchi presenti nei sistemi centrali aziendali. Nella scheda Avanzata è possibile attivare eventuali meccanismi di autenticazione avanzati del programma. Come indicato in precedenza, Kerio Connect supporta un numero arbitrario di domini. Per aggiungere un nuovo dominio basta fare clic sul pulsante Aggiungi presente in fondo all’area principale. Tra i vari domini configurati deve comunque esistere sempre un dominio principale, che di default è quello impostato dalla procedura di configurazione iniziale. È tuttavia possibile cambiare il dominio primario, tramite il pulsante Imposta come primario. Un dominio può essere locale o distribuito. I domini distribuiti sono una funzionalità recente, che permette di avere più installazioni di Kerio Connect interconnesse. In questa struttura si ha un server master e una serie di server slave che condividono informazioni con il server master. Le informazioni condivise sono gli elenchi utenti e i gruppi, le risorse, l’elenco utenti globale e le mailing list. In questa struttura, il server master è in grado di girare le mail ai server slave, dove, per esempio, possono essere configurati dei domini di posta specifici per le unità remote.

Se si desidera usare dei domini distribuiti, è però necessario utilizzare un sistema di directory per gestire gli utenti. Non è possibile utilizzare l’elenco utenti locale. Al momento, vi sono comunque delle limitazioni: non si possono distribuire cartelle pubbliche e calendari condivisi. Il sistema, inoltre, non deve essere inteso come sistema di failover o di bilanciamento. Completata la fase di configurazione del dominio si deve spostare l’attenzione sull’opzione Recapito scheda Connessione Internet (Figura 12.5), per specificare se la connessione a Internet è permanente, come nel caso di una linea ADSL o di una connessione in banda larga. Nel caso si utilizzi un collegamento dial-up di tipo analogico o ISDN, bisogna attivare la voce Offline.

Figura 12.5 Pannello di configurazione della connessione Internet.

In tal caso il server dovrà attivare la connessione a Internet a intervalli regolari per accedere alle caselle esterne o per inoltrare la posta accumulata. L’intervallo di connessione viene regolato tramite la scheda Pianificazione. Dopo aver premuto il pulsante Aggiungi, comparirà la finestra Aggiungi azione programmata (Figura 12.6) dove si potrà specificare la frequenza dell’evento e le operazioni che devono essere compiute (invio dei messaggi, download in POP3 o trasferimento esterno tramite ETRN).

Figura 12.6 Impostazione della programmazione per una connessione dial-up.

A questo punto si può passare alla voce Opzioni avanzate dell’albero delle opzioni, per impostare alcune opzioni evolute. Questa sezione contiene varie schede, ciascuna dedicata a una specifica funzione. Inizialmente bisogna accedere alla scheda Directory di memorizzazione (Figura 12.7), dove è possibile verificare il percorso di base per tutte le directory dati di Kerio Connect. Il dato di default è corretto, ma si potrebbe, per esempio, voler gestire la directory di lavoro su un’altra unità di storage. Dallo stesso pannello bisogna regolare, più in basso, alcuni livelli di guardia per la directory dove sono salvati i messaggi. Questi parametri sono di facile comprensione: se viene superato il primo limite (soft), parte una segnalazione mail all’amministratore. A questo punto il sistema si mette in verifica del secondo limite (hard). Se anche questo viene superato, il servizio di posta viene fermato per impedire che il disco possa essere completamente occupato dall’attività del mailserver, dalla coda messaggi e dalla base di dati.

Figura 12.7 Impostazione del percorso dell’area di lavoro di Kerio Connect e dei limiti di guardia.

Se la rete è protetta da un sistema proxy, è necessario indicare nella scheda Proxy HTTP i parametri del servizio. La scheda Aggiorna controllo permette di cercare periodicamente nuove versioni di Kerio Connect: nel caso sia disponibile una nuova versione, all’amministratore verrà presentato un messaggio di avviso. La scheda Webmail (Figura 12.8) è utile per la gestione del servizio webmail. Si possono specificare le dimensioni massime dei messaggi che si possono scrivere con la webmail, la durata della sessione web e indicare un logo grafico. Per default compare il logo di Kerio, ma è possibile installarne uno personalizzato: basta creare un’immagine gif di 200×40 pixel e caricarla in questa schermata. Il nuovo logo sarà immediatamente disponibile nel sistema di webmail.

Figura 12.8 Impostazione dei parametri della w ebmail.

Definizione degli utenti A questo punto si dispone di una buona configurazione generale ed è il momento di dedicarsi alla creazione degli utenti. Gli utenti che possono accedere a Kerio vengono definiti mediante la voce Utenti presente nell’albero di sinistra sotto Account. Da questa sezione è possibile importare gli utenti presenti in un servizio di directory usando il pulsante Importaz. ed esportaz., oppure aggiungere manualmente gli utenti tramite il pulsante Aggiungi. Prima, però, occorre verificare di aver selezionato il dominio corretto: gli utenti vengono infatti inseriti nel dominio indicato nel box Dominio, presente in alto. La creazione di un utente avviene tramite la procedura guidata descritta di seguito. 1. Indicare le generalità dell’utente: username, nome completo, descrizione, metodo di autenticazione e password (Figura 12.9), poi fare clic su Ok.

Figura 12.9 Aggiunta di un nuovo utente.

2. Specificare gli indirizzi di posta dell’utente tramite la scheda Indirizzi email. 3. Specificare tramite la scheda Inoltro un’eventuale regola di inoltro e fare in modo, per esempio, che tutti i messaggi inviati all’indirizzo di posta che si sta configurando vengano inoltrati a un’altra casella, locale o esterna. In tal caso si può anche stabilire se una copia del messaggio dovrà comunque memorizzata in locale. 4. Indicare il gruppo di appartenenza dell’utente tramite la scheda Gruppi. Bisogna naturalmente aver preventivamente creato dei gruppi tramite la voce Gruppi presente sotto la sezione Account dell’albero di opzioni a sinistra. In questo modo si possono raggruppare gli utenti per aree funzionali (UffTec, Amministrazione, Magazzino, Direzione e così via) o per qualunque altro criterio. 5. Stabilire i diritti dell’utente (Figura 12.10) tramite la scheda Diritti. Questo passaggio serve principalmente per indicare se l’utente è un amministratore. Se l’utente non è un amministratore, si deve attivare l’opzione Nessuna autorizzazione. Agli amministratori deve invece corrispondere uno degli altri diritti, rispettivamente se può amministrare solo il dominio in oggetto, l’intero server, ma solo in lettura oppure l’intero server in lettura e scrittura. In fondo si può specificare se l’utente in oggetto può amministrare le cartelle pubbliche del sistema di groupware.

Figura 12.10 Assegnazione dei diritti utente.

6. Specificare le quote disco, cioè lo spazio che può essere occupato dall’account in oggetto e indicare il numero massimo di messaggi che la casella di posta dell’utente può contenere e/o lo spazio massimo a disposizione dell’utente (Figura 12.11).

Figura 12.11 Impostazione della quota massima di memorizzazione.

7. Specificare se le azioni dell’utente sono limitate al proprio dominio e se vi è un limite per le dimensioni

dei messaggi inviati da questo utente (Figura 12.12). Si possono poi creare delle politiche di cancellazione automatica delle cartelle: del cestino, della raccolta spam e delle cartelle ordinarie.

Figura 12.12 Tramite il primo controllo in alto è possibile limitare l’attività mail dell’utente al solo dominio locale.

La creazione di un utente è una procedura articolata e lunga. Se occorre creare molti utenti, la procedura potrebbe richiedere molto tempo. Per velocizzare le operazioni si può impostare un modello standard di account, dotato di una configurazione comune a tutti gli utenti della propria organizzazione. Questo modello potrà poi essere usato come base per creare i nuovi utenti, impostando manualmente solo i pochi elementi personali (nome, descrizione, password e così via). Per creare un modello si deve scegliere Configurazione > Definizioni > Modelli utente nel pannello di sinistra. Facendo clic sul pulsante Aggiungi comparirà una finestra dove configurare le opzioni comuni a tutti gli utenti.

Scambio dei messaggi Gli utenti creati sono immediatamente disponibili e quindi pronti per ricevere posta dagli utenti locali e dal mondo esterno. In questo caso il record MX del proprio dominio Internet deve essere opportunamente configurato con l’indirizzo IP statico del server che ospita Kerio Connect. Il server deve ovviamente essere raggiungibile su Internet. Se non si vuole esporre il proprio server in Internet, oppure se non c’è interesse ad avere un sistema di posta autonomo, si può fare riferimento al proprio provider, dove sono probabilmente allocate una o più caselle di posta accessibili con il protocollo POP3. Si potranno così scaricare i messaggi e smistarli nelle singole caselle di Kerio Connect. Questa modalità è diffusa in quanto comoda, sicura ed evita parecchi problemi di configurazione e gestione. Permette inoltre di spegnere il server durante le ferie o nei week-end, in quanto la posta sarà comunque accumulata dal provider.

Tale scelta non preclude inoltre il passaggio al modello autonomo: in qualunque momento è possibile abbandonare il proprio provider e gestire autonomamente la posta elettronica con poche modifiche alla configurazione. La definizione delle caselle POP3 da scaricare dal provider avviene nella sezione Configurazione, voce Recapito, scheda Download POP3. Nella sezione in alto, denominata Account (Figura 12.13), bisogna aggiunger con il relativo pulsante le singole caselle da scaricare. Compare una finestra dove immettere i parametri della casella POP3, come l’indirizzo del server e i dati dell’account presso il provider. Nella zona sottostante, Ordinamento e recapito, si deve specificare la casella interna di Kerio Connect alla quale inoltrare il messaggio. Nella scheda Avanzato si può indicare se per la comunicazione si vuole usare il protocollo sicuro SSL, se ci sono dei limiti per le dimensioni dei messaggi da scaricare e se si vuole lasciare una copia del messaggio sul server remoto.

Figura 12.13 Configurazione di un account POP3.

Manca ancora la configurazione del protocollo di invio dei messaggi. Questo aspetto si imposta tramite la sezione Configurazione, voce Server SMTP, dell’albero di sinistra. Per cominciare si deve indicare nella scheda Recapito SMTP (Figura 12.14) se si vogliono inoltrare le email direttamente a destinazione, oppure se si preferisce consegnare la posta al server del proprio provider e delegare a quest’ultimo la consegna del messaggio.

Figura 12.14 Pannello per la configurazione dei parametri di uscita di SMTP.

Nel primo caso si deve attivare l’opzione Recapita direttamente tramite record DNS MX, che richiede la presenza di un sistema DNS funzionante nel server Linux. In questa modalità, Kerio estrarrà il dominio di destinazione di ogni messaggio, consulterà il sistema DNS e ricaverà l’indirizzo IP statico del server di posta del destinatario, stabilendo con esso una comunicazione diretta. Se si preferisce usare un provider esterno si deve invece attivare la voce Usa server relay SMTP, specificando l’indirizzo del server SMTP del proprio provider.

Impostazioni di sicurezza Il server è pronto per funzionare. Tuttavia è molto rischioso mettere in produzione un server così configurato, in quanto mancano i dettagli di sicurezza. Curare questo aspetto è fondamentale, visto che i server di posta elettronica sono costantemente nel mirino degli utenti malintenzionati di tutto il mondo. Un numero imprecisato di cracker esegue continue scansioni automatiche di Internet alla ricerca di nuovi server e, statisticamente parlando, un nuovo server di posta elettronica viene scoperto nel suo primo giorno di funzionamento. Se la macchina non è protetta, quasi sicuramente subirà qualche forma di attacco. La prima operazione da compiere è configurare correttamente il firewall. Il sistema che ospita Kerio Connect dovrebbe essere accessibile dall’esterno solo attraverso le porte 25/TCP (SMTP) e 80/TCP (webmail). Dalla rete interna devono invece essere accessibili tutte le porte precedenti più la 110/TCP (POP3) e la 53/UDP (DNS). Si consiglia di usare le versioni protette dei protocolli e aprire le porte relative: 465/TCP per SSMTP, 995/TCP per SPOP3 e 443/TCP per webmail in HTTPS. Se si è deciso di ricorrere a un provider esterno, evitando che il proprio server sia il gestore principale

della posta elettronica del dominio, è sufficiente che dall’esterno sia accessibile la porta 80 e la 443, destinate ai servizi di webmail. La configurazione del firewall è solo il punto di partenza. Bisogna effettuare ulteriori operazioni, soprattutto quando il server di posta elettronica gestisce autonomamente la posta per il proprio dominio. In questa modalità operativa il servizio SMPT è pubblicamente disponibile su Internet, condizione necessaria per il recapito dei messaggi scritti dal mondo esterno. Gli spammer sono alla continua ricerca di server SMTP allo scopo di veicolare posta indesiderata. Una volta individuato un nuovo server (evento che, come si è puntualizzato, si verifica mediamente al primo giorno di servizio), verrà aperta una sessione e saranno recapitati uno o più messaggi. Questi messaggi non saranno però indirizzati a un utente interno al dominio, ma a centinaia o a migliaia di utenti esterni a esso: il proprio server comincerà così a recapitare una copia del messaggio a ogni destinatario indicato, contribuendo alla diffusione dello spam. È molto comune, in casi come questo, che il server venga inserito nelle liste nere mondiali e che sia bandito. Il proprio provider potrebbe in tal caso sconnettere la propria sottorete da Internet, isolando la rete aziendale. La facoltà di inoltrare messaggi liberamente da parte di chiunque si chiama open relay. L’operazione fondamentale di sicurezza da compiere è evitare che il proprio server funzioni proprio in questa modalità. Per realizzare questo scopo, si deve selezionare Configurazione, voce Server SMTP e scegliere la scheda Controllo Relay (Figura 12.15). Si deve evitare categoricamente di selezionare il controllo Apri Relay. Bisogna piuttosto selezionare Consenti solo relay per e specificare una delle tre modalità. La migliore di queste è la prima.

Figura 12.15 È fondamentale verificare che l’open relay sia disattivato.

Dopo aver selezionato la prima modalità, fare clic sul pulsante Modifica e poi su Aggiungi. Compare così

la finestra di dialogo riportata nella Figura 12.16, dove si possono indicare gli indirizzi o le sottoreti abilitate a inoltrare messaggi di posta elettronica attraverso il server. Si consiglia, prima di tutto, di scegliere come tipo Intervallo indirizzi e specificare il range degli indirizzi IP che fanno parte della sottorete interna, per esempio da 192.168.0.50 a 192.168.0.100.

Figura 12.16 Definizione di un intervallo di indirizzi IP.

Nel campo Descrizione si può scrivere un testo libero, per esempio Utenti LAN interna. Confermando e salvando l’impostazione si segnala a Kerio Connect che solo le richieste provenienti dagli indirizzi indicati hanno il permesso di inoltrare messaggi di posta all’esterno; eventuali tentativi provenienti da computer esterni saranno immediatamente interdetti, impedendo così l’inoltro dello spam. Qualora siano presenti filiali remote servite dallo stesso server di posta, si dovranno definire altre sottoreti abilitate, in modo da permettere l’inoltro di posta elettronica. Sempre a proposito di spamming, è interessante analizzare la scheda Blacklist, presente nell’albero delle opzioni di sinistra sotto Filtro contenuti/Filtro spam. Qui sono presenti dei riferimenti ad alcuni database pubblici (SORBS, SpamCop, SpamHaus ecc.) costantemente aggiornati con gli IP indirizzi delle macchine che generano spam nel mondo. Facendo clic su uno dei servizi elencati si attiverà un controllo ulteriore che scarterà automaticamente qualsiasi messaggio in arrivo dai sistemi presenti in tali liste nere. Si tratta di una buona soluzione, non priva di controindicazioni. I provider potrebbero infatti finire in questi elenchi per colpa di alcuni clienti scorretti (o addirittura criminali) che utilizzano la connettività per veicolare grandi quantità di spam. I curatori delle blacklist inseriranno prontamente in archivio i gruppi di IP da cui si è rilevato spam. Se questi IP venissero in seguito assegnati ad altri clienti, questa volta regolari, il loro traffico mail verrebbe interdetto. Gli indirizzi saranno ancora in blacklist nonostante gli IP siano passati ad altri fruitori. Questo problema è evidente con i provider più popolari: con il passare del tempo, negli elenchi finiscono blocchi sempre più consistenti di indirizzi IP. Statisticamente ci saranno infatti più spammer e più attività criminali presso i provider con maggiore successo commerciale. Abilitando le blacklist si rischia così di scartare messaggi validi provenienti dai propri interlocutori. Forse inizialmente è meglio fare doppio clic sul server che si intende impiegare e usare l’opzione Aumenta punteggio, assegnando un valore basso, per esempio 1. In questo modo la presenza in blacklist non comporterà l’interdizione di qualunque traffico mail, ma solo un aumento del punteggio durante la valutazione antispam dei messaggi da parte di Kerio Connect. Si comprenderà meglio il concetto del punteggio nel

prossimo paragrafo. Una funzionalità molto valida contro lo spam è la voce Ritarda risposta SMTP per [secondi] presente nella scheda Anti spam (Figura 12.17).

Figura 12.17 Kerio Connect comprende funzionalità di greylisting.

Questa funzione introduce a ogni sessione SMTP un ritardo della lunghezza specificata nel campo stesso. Questo ritardo è del tutto permesso dagli standard e risulta privo di conseguenze pratiche. Gli spammer non possono però permettersi di aspettare 25 secondi, in quanto devono smistare migliaia di messaggi nel minor tempo possibile e tipicamente faranno terminare la sessione evitando l’inoltro dello spam. Questa misura, denominata greylisting riduce in maniera significativa il quantitativo di spam recapitato. Se si impiega questa misura, si deve però creare una lista di sottoreti a cui non sarà sottoposto il ritardo, compresa la propria sottorete. In caso contrario si avrebbe una pausa a ogni download della posta elettronica aziendale. Questa configurazione si applica nella voce seguente Non applicare ritardo per le connessioni da. Ai fini della sicurezza sono molto interessanti le opzioni presenti nella scheda Opzioni di protezione, presente sull’albero delle opzioni sotto Configurazione/Server SMTP. Questa permette di impostare dei limiti operativi sullo smistamento dei messaggi. Per esempio, è possibile fare in modo che un indirizzo IP non possa inviare più di un certo numero di messaggi per ora, che non venga superato un numero prefissato di connessioni simultanee, che non siano ammessi più di un certo numero di destinatari sconosciuti, che non venga superata una determinata soglia di destinatari e così via. La voce che limita il numero di destinatari sconosciuti è utile perché esiste una tecnica molto in voga tra gli spammer, che consiste nell’inondare un determinato dominio con messaggi indirizzati a caselle di posta i cui identificativi sono scelti in maniera casuale. Verificando quanti messaggi sono respinti con l’errore di mittente sconosciuto e quali invece vengono inoltrati, gli spammer possono costruire un elenco di account esistenti nel dominio attaccato, ai quali poi inoltrare pubblicità non richiesta. Generalmente si pone il numero dei destinatari

sconosciuti uguale a zero, in modo da imporre al server di non rispondere ai messaggi contenenti destinatari sconosciuti.

Antivirus e antispam Kerio Connect dispone di un meccanismo antispam basato sull’algoritmo SpamAssassin (http://spamassassin.apache.org). Il controllo di questa funzionalità avviene tramite la voce Configurazione > Filtro contenuti > Filtro spam dell’albero presente nel pannello di sinistra della schermata di amministrazione. Il sistema è abilitato per default e controlla tutti i messaggi assegnando un punteggio in base a un certo numero di criteri che accomunano le comunicazioni spam. Se viene superata la soglia specificata nella scheda Classificazione spam, voce Punteggio tag, il messaggio è considerato spam e subisce il destino indicato nella sezione sottostante, denominata Azione limite punteggio tag raggiunta. La soglia di punteggio fissata per considerare un messaggio come spam è 5. Questo valore può comunque essere modificato in modo da calibrare l’accuratezza del meccanismo antispam in base alle proprie esigenze. I messaggi ritenuti spam sono marchiati con la stringa **SPAM**, in modo che siano riconoscibili e che si possano costruire regole di filtro sul client di posta elettronica. Attenzione però che nelle ultime versioni di Kerio Connect i messaggi marchiati non sono più inoltrati all’utente, ma rimangono confinati nella casella Posta indesiderata del sistema di webmail. Per ottenere l’inoltro al client bisogna disattivare questa funzione dalle Impostazioni della webmail. È anche possibile scartare il messaggio. Questa azione si regola nella sezione Azione limite punteggio blocco raggiunta. Bisogna regolare bene questo valore, perché esiste un margine di errore e una mail regolare potrebbe essere erroneamente classificata come spam. Si consiglia di impostare una soglia molto alta, intorno a 9.5. Si può anche respingere il messaggio al mittente. La pratica è sconsigliabile, perché in questo modo si comunica agli spammer l’esistenza della casella di posta elettronica o peggio si manda una comunicazione a un destinatario del tutto ignaro che il suo indirizzo è usato a fini di spam. È interessante invece l’opzione Inoltra il messaggio all’indirizzo di quarantena, grazie alla quale è possibile convogliare tutto lo spamming in una casella di raccolta. Si consiglia di attivare la funzione solo se la casella di quarantena è costantemente monitorata e gestita. Il volume di spam potrebbe rapidamente esaurire lo spazio su disco. Nella scheda Personalizza regole è possibile creare regole per marcare come spam, per esempio, tutti i messaggi provenienti da un particolare dominio: basta fare clic sul pulsante Aggiungi e creare la regola basandosi sui vari elementi che compongo un messaggio. È anche possibile istituire regole che aumentano o abbassano il punteggio assegnato dall’antispam, per calibrare meglio il comportamento in casi particolari. L’antispam non è comunque uno strumento statico, ma deve essere sottoposto a un periodo di “addestramento” per migliorarne le prestazioni. Per farlo si devono marcare manualmente i messaggi di spam che sono usciti indenni dal filtro automatico o “liberare” i messaggi regolari erroneamente marchiati. Il sistema userà questo input per adattare il proprio comportamento e per incrementare l’accuratezza della valutazione dei messaggi di posta. Questa funzionalità è però possibile solo utilizzando il servizio webmail, quindi per un certo periodo di tempo è necessario collegarsi alla propria casella con regolarità tramite il browser e dedicare un po’ di tempo all’attività di marcatura dei messaggi. Nel giro di qualche giorno l’accuratezza del sistema dovrebbe migliorare notevolmente, catturando una buona percentuale dei messaggi di spam. La sezione Configurazione > Filtro contenuti > Antivirus opera in maniera analoga, eseguendo un controllo antivirus su tutti i messaggi in transito. Eventuali messaggi infetti possono essere eliminati, collezionati in un’area di raccolta o rispediti al mittente.

Il pacchetto dispone internamente del motore di scansione Sophos, dotato anche di un meccanismo automatico di aggiornamento dei file di definizione dei virus. È comunque possibile disattivare questa funzionalità se non si intende sostenere il costo della licenza dell’antivirus o se si desidera usare uno degli altri antivirus supportati come ClamAV, AVG Server Edition for Linux o NOD32. ClamAV è un antivirus gratuito, trattato nel Capitolo 10. Può rappresentare una buona scelta per la scansione antivirus. È possibile avere anche un doppio controllo eseguito dal motore Sophos integrato e da uno degli altri antivirus supportati.

Certificati digitali Se si è deciso di utilizzare i protocolli sicuri, può essere una buona scelta acquistare un certificato digitale presso una certification authority riconosciuta e fare in modo che le transazioni sicure siano protette e certificate. Questo importante aspetto è regolato dalla voce Configurazione > Certificati SSL. Di default è installato un certificato autofirmato, generato in fase di installazione. È possibile creare un certificato autofirmato personalizzato facendo clic sul pulsante Nuovo e selezionando Nuovo certificato (Figura 12.18). Comparirà così una finestra di dialogo, in cui indicare i dettagli della propria organizzazione. Una volta realizzato il certificato, si deve procedere alla sua attivazione tramite il pulsante Imposta come attivo presente in basso a destra.

Figura 12.18 Generazione di un certificato autofirmato.

Questo certificato è funzionale e permette le operazioni cifrate per i protocolli di scambio di posta elettronica, ma non fornisce garanzie all’interlocutore, in quanto è stato rilasciato dalla propria organizzazione e non da un ente esterno accreditato. L’interlocutore non può cioè avere certezze sull’identità del mailserver. Per fornire tutte le garanzie è necessario richiedere un certificato a un ente pubblicamente riconosciuto, come per esempio Thawte (http://www.thawte.com), VeriSign (http://www.verisign.com), Trust Italia (http://www.trustitalia.it) e così via, che garantirà l’identità del servizio. Per effettuare questa operazione si deve fare clic sul pulsante Nuovo, scegliere Richiesta di nuovo certificato e compilare i campi richiesti all’interno della finestra di dialogo che appare. La richiesta dovrà essere esportata tramite l’apposito pulsante presente in basso e recapitata all’ente di certificazione, che invierà il certificato definitivo. Quest’ultimo dovrà essere importato tramite il pulsante Importa e reso attivo con il pulsante Imposta come attivo.

Controllo e gestione delle attività Tutto il controllo dell’attività di Kerio Connect avviene tramite le voci presenti nel gruppo Stato del pannello di amministrazione web del programma. È possibile visualizzare la coda dei messaggi e gestirla, visualizzare le connessioni attive per tutti i protocolli supportati da Kerio Connect e il traffico nel tempo, nonché ottenere un resoconto statistico della situazione generale del servizio di posta elettronica. Più in basso si trova invece il gruppo Registri, da cui è possibile reperire informazioni tecniche su tutto quello che avviene nel sistema. Particolarmente interessante è la voce Debug: posizionandosi sull’area messaggi a destra, facendo clic con il tasto destro del mouse e selezionando l’opzione Messaggi è possibile richiedere la registrazione di eventi specifici (Figura 12.19) e controllare in maniera dettagliata il funzionamento dei protocolli.

Figura 12.19 Il pannello dei log contiene una ricca sezione di debug che permette di ricavare molte informazioni a scopo di debug e monitoring.

Tutte le sezioni di log possiedono delle proprietà modificabili: per visualizzarle, bisogna posizionarsi nel pannello di destra, fare clic con il tasto destro del mouse e scegliere Impostazioni log. Si può così modificare la frequenza di rotazione dei log in base al tempo o ai kbyte e il numero massimo di file di log che devono essere tenuti in memoria. Questa impostazione è importante, in quanto è bene conservare tutte le registrazione del traffico in caso di eventuali controlli o richieste da parte degli organi dello Stato. I log possono essere conservati localmente, oppure possono essere gestiti tramite un server syslog. Per impostare questa scelta si deve usare la scheda Registrazione esterna. Sempre riguardo alla conservazione delle informazioni sul traffico generato, è possibile mantenere una copia dei messaggi transitati nel sistema: basta andare nell’albero del pannello di sinistra, scegliere la voce Configurazione > Archiviazione e Backup e indicare nella scheda Archiviazione quali informazioni mantenere. La frequenza di archiviazione si regola nella sezione Azione. È bene, a tal proposito, indicare nella scheda Comprimi vecchie cartelle di archiviazione che gli archivi devono essere compressi: salvare tutti i messaggi è infatti un’operazione onerosa in termini di spazio su disco. La scheda Backup esegue invece una copia di sicurezza utile a fini sistemistici (la funzione precedente è invece utile come archiviazione). Abilitando la funzione e facendo clic sul pulsante Aggiungi si può specificare la periodicità e il tipo del backup (completo o differenziale) che interesserà l’area dati e i file di configurazione. Le copie saranno memorizzate nella directory /opt/kerio/mailserver/store/backup. Per eseguire il restore si usa un semplice strumento a riga di comando, denominato kmsrecover, da utilizzarsi solamente se il servizio di Kerio Connect è disattivo. Il comando è nella directory di Kerio Connect (/opt/kerio/mailserver). La sintassi per il recupero di una casella è la seguente: ./kmsrecover -d -u /opt/kerio/mailserver/store/backup/

Al posto di si deve inserire il dominio di cui si vuole eseguire un ripristino, in il nome della casella da recuperare, mentre in va indicato il file di backup che si vuole utilizzare, per esempio C20100625T084856Z.zip. Il comando di cui sopra recupera la casella sovrascrivendo la cartella attuale presente sul server. Quindi si riporta tutta la gerarchia utente allo stato del backup, compresi quindi note, rubriche, agende e così via. Usando lo switch -f si può scegliere un singolo folder, per esempio “Calendario”. Si recupera così solo questa entità e non si alterano le altre cartelle:

./kmsrecover -d incipit.biz -u szanzi -f Calendario –v /opt/kerio/mailserver/store/backup/C20100625T084856Z.zip

Il comando di cui sopra va scritto in un’unica riga. Si noti che è stato usato anche lo switch –v per ottenere un output più prolisso dell’andamento del restore. Per recuperare l’intero sistema a seguito di un crash, è sufficiente reinstallare Kerio Connect e poi fare un restore completo: ./kmsrecover /backup/C20100625T084856Z.zip

In questo esempio il file di restore si trova in /backup, mappato per esempio in una unità di storage differente dal filesystem dove si trova lo store di Kerio Connect. Se non si utilizzano le funzionalità di groupware e non si hanno quindi dati in Kerio Connect (le mail sono scaricate sui computer degli utenti finali) è possibile usare strategie di backup più semplici. È sufficiente in tal caso salvare i file di configurazione manualmente. Basta andare nella directory /opt/kerio/mailserver e copiare tutti i file con estensione cfg: mailserver.cfg (la configurazione generale) e users.cfg (la configurazione degli utenti). Si tratta di file di testo leggibili che contengono tutta la configurazione di Kerio. In caso di crash completo del computer o di danno al mail server è sufficiente reinstallare il software, copiare questi file e avviare il servizio. Si avrà immediatamente la vecchia configurazione funzionante. Mancheranno naturalmente i messaggi presenti sulla coda del server al momento del crash. Un’ulteriore utile funzione di sicurezza è costituita da Configurazione > Impostazioni di amministrazione. Di default, qualunque client può accedere dall’esterno al pannello di amministrazione, a patto di fornire le opportune credenziali. Il furto di credenziali è però un’evenienza tutt’altro che rara e perciò è opportuno selezionare l’opzione Consenti amministrazione da host remoto e anche Solo da questo gruppo di indirizzi IP. In questo modo si può specificare da quali indirizzi statici è possibile accedere al pannello di amministrazione, limitando l’accesso a pochi sistemi autorizzati. Per concludere, sembra opportuno puntualizzare alcuni aspetti, primo fra tutti la licenza d’uso. Il software descritto in questo capitolo è pienamente funzionante per 30 giorni, in modo che l’utente possa provarlo in piena libertà. Trascorso questo periodo sarà necessario acquistare una licenza dal sito del produttore o da uno dei rivenditori elencati all’indirizzo http://www.kerio.it/reseller_it.html. La licenza non è altro che un certificato digitale che abilita il software per un certo numero di utenti e attiva eventualmente il sistema antivirus Sophos. Questo file deve essere caricato facendo clic sulla prima voce dell’albero del pannello di sinistra, denominata Kerio Connect e facendo clic sull’apposito link presente. La licenza include un anno di abbonamento: questo significa che, nel corso dell’anno, è possibile effettuare tutti gli aggiornamenti del prodotto, anche a versioni successive. Concluso l’abbonamento il programma resta pienamente funzionante, ma non è più possibile aggiornarlo. Per poter continuare a installare gli aggiornamenti è necessario rinnovare l’abbonamento prima della sua scadenza annuale (al costo di circa un terzo della licenza originale). La frequenza degli aggiornamenti è elevata in quanto Kerio ha compiuto la scelta di aggiornare mensilmente il prodotto con le correzioni ai bug segnalati dagli utenti. L’aggiornamento implica la reinstallazione del software, quindi conviene sempre salvare i file di configurazione prima di compiere questa operazione. Prima di aggiornare il programma bisogna arrestare il demone di Kerio Connect sul server Linux. Il manuale è disponibile online in formato PDF, all’indirizzo http://www.kerio.com/connect/manual. C’è anche la versione consultabile sul Web. Il supporto tecnico online, di buona qualità, è invece disponibile all’indirizzo http://support.kerio.com.

Checklist 1. Scaricare Kerio Connect dal sito del produttore. 2. Disattivare eventuali altri sistemi di posta elettronica presenti nel sistema. 3. Verificare la presenza del pacchetto compact-libstdc++, necessario per il funzionamento di Kerio Connect. 4. Installare Kerio Connect. 5. Andare nella directory /opt/kerio/mailserver e lanciare la procedura guidata di prima configurazione con ./cfgwizard. 6. Seguire la procedura fornendo le indicazioni basilari richieste (dominio principale, generalità dell’amministratore e directory di salvataggio). 7. Dal pannello di amministrazione web collegarsi al server che ospita Kerio Connect indicando l’indirizzo della macchina e la porta 4040. 8. Eseguire la configurazione generale del programma. 9. Definire gli utenti. 10. Se il server di posta elettronica gestisce in modo autonomo la posta elettronica per il proprio dominio, passare al punto 12. 11. Definire le caselle POP3 da scaricare dal proprio provider. 12. Definire il meccanismo di invio scegliendo se usare il proprio provider o i record MX. 13. Applicare i criteri di sicurezza sul firewall. 14. Controllare che il sistema SMTP non sia in modalità open relay. 15. Regolare il sistema antispam in base alle proprie esigenze. 16. Attivare il sistema antivirus nel caso si disponga della licenza Sophos oppure usare gratuitamente ClamAV. 17. Acquistare, se lo si desidera, un certificato da un ente certificatore oppure generare un certificato autofirmato. 18. Configurare i client.

Capitolo 13

Capitolo 13 - Gestione della posta elettronica con strumenti gratuiti Nel capitolo precedente è stato illustrato come realizzare un sistema completo di posta elettronica attraverso un prodotto commerciale dotato di tutti i servizi integrati e gestibile tramite un semplice pannello di amministrazione. In questo capitolo si vedrà come installare un sistema per lo scambio della posta elettronica attraverso strumenti distribuiti in forma gratuita. In ambito Linux non esiste alcun problema di disponibilità di software e quindi è molto semplice reperire gli elementi necessari allo scopo. Più problematica è invece la loro messa in opera. Non esiste infatti un unico prodotto in grado di ricevere la posta esterna in SMTP, eseguire il filtering antivirus e antispam, prelevare mail da account POP3 esterni, fornire l’accesso mail ai client tramite POP3 o IMAP ed erogare anche un’interfaccia webmail. Bisogna piuttosto usare diversi programmi, tutti realizzati da gruppi di sviluppo differenti, operare una corretta configurazione sui singoli pacchetti, ognuno di questi basati su convenzioni e sintassi del tutto differenti, armonizzare tutti i componenti e infine amministrare il sistema nel tempo, gestendo diversi file di log e applicando patch e upgrade su un gran numero di elementi. Non si tratta certo di un lavoro semplice, soprattutto per chi si avvicina a Linux. Fortunatamente cominciano ad affiorare sul panorama Linux alcuni prodotti gratuiti per la gestione della posta elettronica, che integrano al loro interno buona parte dei componenti necessari. Queste soluzioni non sono programmi autonomi scritti ad hoc, come è per esempio Kerio MailServer, ma sono piuttosto delle integrazioni ben realizzate di prodotti tradizionali Linux. Più precisamente si tratta di ambienti che eseguono un’installazione controllata dei pacchetti, applicano una serie di configurazioni ben collaudate ed espongono un pannello intuitivo di gestione, da cui è possibile eseguire molte attività amministrative. In questo capitolo si utilizzerà la versione community di Scalix (www.scalix.com), un prodotto in grado di erogare servizi SMTP, POP3, IMAP, groupware, webmail, integrazione con directory service e così via, dotato di un pannello grafico per l’installazione e l’amministrazione (Figura 13.1). Il prodotto dispone inoltre di un’eccezionale documentazione tecnica, disponibile all’indirizzo http://www.scalix.com/community/downloads/documentation.php.

Figura 13.1 Sito ufficiale di Scalix.

Di Scalix esiste anche una versione commerciale, che include il supporto MAPI per Outlook, migliori funzionalità di groupware (calendari di gruppo, pianificazioni e cartelle pubbliche) e meccanismi di tolleranza ai guasti. La credibilità del prodotto è in crescita e la forza commerciale si è recentemente consolidata grazie all’acquisizione da parte di Xandros, un nome in ascesa nel panorama Linux.

Installazione Il prodotto è disponibile per varie distribuzioni Linux, tra le quali Red Hat Enterprise Linux, CentOS, SUSE Linux Enterprise Server, Fedora Core, OpenSuSE, CentOS e Debian. La versione Debian non è supportata da Scalix ufficialmente. A differenza di altri prodotti, è molto importante che la distribuzione in uso sul proprio server coincida con una delle distribuzioni supportate ed elencate sul sito ufficiale. È necessario anche che la versione della propria distribuzione sia supportata.

Scalix non è infatti un demone autonomo, ma una collezione ben integrata di molti pacchetti tradizionali Linux. L’alto livello di integrazione è stato raggiunto analizzando la fisionomia delle singole distribuzioni e delle relative versioni. Ogni distribuzione e ogni versione presenta differenze sostanziali, di cui bisogna tenerne conto per avere il perfetto funzionamento di Scalix. Il rispetto della distribuzione e della versione è obbligatorio. Scalix verifica il sistema locale e attiva la procedura di installazione solo se il sistema operativo rientra nella rosa dei sistemi supportati. In caso contrario l’installazione termina immediatamente. Per fare un esempio concreto, la versione 11 di Scalix supporta Fedora Core 9. Se si sta usando una versione precedente della distribuzione, la procedura di installazione uscirà subito. In questo capitolo si farà riferimento a una distribuzione CentOS in versione 5. Per cominciare le operazioni di installazione è necessario scaricare il pacchetto dall’area di download, scegliendo accuratamente la versione. Si copia il file in una directory temporanea e si lancia il binario, come in questo esempio: ./scalix-11.4.6-GA-community-rhel5-intel.bin

Viene subito presentato l’accordo di licenza, da accettare. Poi viene scompattato l’archivio di distribuzione e infine viene richiesto se si vuole avviare l’installazione del prodotto: Do you want to run the package that was unpacked automatically? (yes/no) [yes]

differenza di gran parte dei pacchetti di installazione su Linux, Scalix è dotato di un sistema completamente grafico, che ricorda molto le installazioni in ambito Windows. Per questo motivo si consiglia di avviare l’installazione di Scalix da una sessione di X (Figura 13.2).

Figura 13.2 Per beneficiare dell’ottimo installer grafico di Scalix si deve usare un ambiente X.

Il comando appena impartito attiverà una procedura guidata, come evidenziato in Figura 13.3. In questa fase si deve semplicemente fare clic su Avanti. Parte così un check del sistema (Figura 13.4). In particolare viene controllato se la distribuzione e il numero di versione sono compatibili. Se non lo sono, l’installazione

uscirà immediatamente.

Figura 13.3 L’installazione di Scalix è guidata e basata su un’interfaccia grafica.

Figura 13.4 Controllo dei requisiti di sistema.

Se il controllo non rileva problemi di alcun genere, si passa alla fase successiva. In uno stile che ricorda molto Windows, viene chiesto quale tipo di installazione si vuole eseguire (Figura 13.5).

Figura 13.5 L’installatore di Scalix ha un’impostazione che ricorda molto le analoghe procedure su W indow s.

In questo esempio viene scelta la prima opzione (installazione tipica). È anche possibile eseguire un’installazione personalizzata. In seguito, quando Scalix sarà installato, si potrà lanciare nuovamente la procedura di installazione per riconfigurare Scalix o per disinstallarlo. Facendo clic su Avanti viene presentata una schermata riassuntiva, in cui compare l’elenco dei componenti che saranno installati nel sistema (Figura 13.6). È possibile tornare indietro per modificare le scelte oppure fare ancora clic su Avanti e procedere con l’installazione.

Figura 13.6 Riepilogo dei componenti che saranno installati.

Si giunge così a un punto critico dell’installazione, dove sono controllati aspetti come l’ambiente, il filesystem, la configurazione di rete, le dipendenze e i servizi. Tutti i dettagli dell’elenco devono superare il controllo, altrimenti l’installazione non potrà proseguire. Se ci sono dei problemi, compare una finestra di segnalazione (Figura 13.7) con l’indicazione dell’area che ha generato il blocco. Facendo clic su View log è possibile ottenere una finestra di riassunto (Figura 13.8).

Figura 13.7 Il controllo del sistema ha rilevato problemi nell’area della rete e delle dipendenze.

Figura 13.8 Il pulsante View Log permette di richiamare una finestra di dettaglio dei problemi rilevati.

Per cominciare è necessario soddisfare alcuni prerequisiti a livello dei pacchetti. Nel sistema devono essere installati infatti questi pacchetti: cyrus-sasl-md5 postgresql postgresql-server compat-libstdc++.

Ognuno di questi pacchetti deve essere scaricato e installato con gli strumenti di sistema. A seconda della distribuzione usata e del modo in cui è stata installata, potrebbero essere richiesti altri pacchetti. L’elenco dei pacchetti mancanti è visibile tramite il pulsante View log della finestra di installazione. È fondamentale che anche i dettagli di rete siano corretti. Si deve innanzitutto fare in modo che il nome del computer non sia “localhost”, come da configurazione di default. Bisogna piuttosto fornire alla macchina un nome ben preciso, per esempio mail01. Questo nome deve essere applicato al sistema in fase di boot. Gli script di avvio provvedono a questo compito. Nel caso di CentOS e Fedora Core, il nome della macchina viene assegnato dallo script /etc/sysconfig/network. Al suo interno esiste una direttiva hostname che assegna il nome. Qui di seguito viene riportato il contenuto:

NETWORKING=yes NETWORKING_IPV6=no HOSTNAME=mail01.incipit.biz GATEWAY=82.106.143.2

Il DNS locale deve essere attivo e deve contenere gli opportuni rimandi alla macchina locale. Dentro la zona incipit.biz deve essere presente il record mail01, abbinato all’IP pubblico della macchina. Deve inoltre essere presente una zona di ricerca inversa. È fondamentale anche aprire il file hosts e verificare che la sua configurazione sia corretta e contenga sia il rimando a localhost sia al nome di host: 127.0.0.1 localhost.localdomain localhost 82.106.143.4 mail01.incipit.biz mail01

L’indirizzo IP pubblico inserito in questo esempio è del tutto indicativo. Se invece il sistema è installato dentro i confini della LAN, si deve usare una denominazione differente. Il file /etc/sysconfig/network avrà, per esempio, questa fisionomia: NETWORKING=yes NETWORKING_IPV6=no HOSTNAME=mail01.localdomain GATEWAY=192.168.100.1

Mentre invece il file hosts sarà così composto: 127.0.0.1 localhost.localdomain localhost 192.168.100.150 mail01.localdomain mail01

Come si può osservare, viene impiegato il dominio interno localdomain al posto di un dominio Internet standard. Il nome del sistema è in questo esempio mail01. Le zone del DNS dovranno essere impostate di conseguenza. Se tutto è stato configurato nel modo corretto, il controllo sarà superato senza errori e si potrà proseguire. Saranno così installati i componenti di Scalix e verrà visualizzata una finestra di riepilogo. Si deve fare ancora clic sul pulsante Avanti. Comparirà una nuova finestra in cui viene chiesto il nome del mailnode. Nel caso di un singolo server si può lasciare l’impostazione suggerita, che coincide con il nome della macchina (Figura13.9).

Figura 13.9 Impostazione del nome del nodo.

Al passaggio seguente bisogna specificare il dominio, per esempio incipit.biz o localdomain nel caso di installazione all’interno della LAN. Si deve anche specificare la metodologia con cui saranno composti i nomi delle caselle, per esempio iniziale del nome unito al cognome per intero. In questo modo basterà indicare il nome e il cognome per esteso dell’utente e ottenere così la relativa username in automatico. Si tratta di una funzionalità originale che induce alla realizzazione di un ambiente di lavoro omogeneo (Figura 13.10).

Figura 13.10 Impostazione del dominio e della modalità con cui sono composti i nomi e le caselle.

Proseguendo viene richiesto di specificare i dettagli dell’account di amministrazione. Confermando viene creato il mailstore, ovvero l’area nel filesystem dove saranno conservati tutti i dati. La procedura può richiedere diversi minuti. Saranno anche configurati alcuni componenti del sistema. Proseguendo ancora, con il pulsante Avanti verrà richiesto di installare i file di licenza. Come si è puntualizzato in apertura, Scalix è rilasciato in modalità community e quindi utilizzabile in forma gratuita. È però possibile acquistare le licenze commerciali e avere il supporto Outlook e le funzionalità avanzate di groupware. In questa fase dell’installazione è perciò possibile installare le licenze eventualmente acquistate. Se si decide di usare la modalità community è sufficiente proseguire e poi confermare la finestra che compare. A questo punto, sul sistema locale viene installata la Java Virtual Machine, prerequisito per il funzionamento di Scalix (Figura 13.11). Al passaggio seguente viene richiesto il percorso della macchina virtuale appena installata.

Figura 13.11 Installazione della Java Virtual Machine.

È bene puntualizzare che questo elemento è necessario, in quanto il pannello di amministrazione di Scalix è scritto in Java. Se si desidera amministrare Scalix da una macchina differente, magari Windows o Mac OS X, sarà necessario installare la Java Virtual Machine sul relativo computer. Proseguendo viene richiesta la password di autenticazione che i componenti useranno per accedere al server. Scalix armonizza diversi programmi e questi devono poter accedere al server applicativo tramite una password. In questa fase della configurazione si indica appunto questa parola d’ordine (Figura 13.12).

Figura 13.12 Impostazione della passw ord di accesso che i componenti useranno per accedere al server di Scalix.

Proseguendo l’installazione viene richiesto l’indirizzo della macchina dove è in funzione il sistema database PostgreSQL precedentemente installato. In questo caso si tratta della stessa macchina. Bisogna anche indicare la password di accesso. È la parola indicata nel passaggio precedente (Figura 13.13).

Figura 13.13 Indirizzo del server database e indicazione della passw ord dell’utente Scalix.

Confermando la scelta sarà avviata la configurazione del database e in seguito saranno attivati tutti i servizi. La procedura dovrebbe così risultare conclusa! (Figura 13.14). Non resta che verificare che i servizi di Scalix (scalix, scalix-postgres e scalix-tomcat) siano attivi e che partano automaticamente all’avvio del sistema. Bisogna altresì verificare i demoni di supporto, quali

httpd, postgresql e sendmail.

Figura 13.14 La procedura di installazione è conclusa.

Amministrazione Per accedere al pannello di amministrazione di Scalix si deve aprire il browser e digitare l’indirizzo http://indirizzo/sac, dove indirizzo è il nome registrato nel DNS della macchina su cui è installato

Scalix. Il pannello utilizza le finestre pop-up e quindi bisogna abilitare la funzionalità sul browser, almeno per l’indirizzo in oggetto. All’apertura si deve indicare user-id e password (Figura 13.15).

Figura 13.15 Log-in al pannello di amministrazione di Scalix.

Se non si usa una connessione sicura basata su HTTPS bisogna anche fare clic sul controllo presente sotto la casella della password (Not using a secure https connection. Click to continue). Il pannello di amministrazione contiene alcune icone che rimandano direttamente alle aree operative. Queste sono Users, Groups, Resources, Plugins, Server info, Settings e Help (Figura 13.16).

Figura 13.16 Pannello di amministrazione di Scalix.

Facendo clic su Settings compaiono sulla sinistra due voci. La prima è l’indirizzo del server appena installato (ed eventuali altri server in caso di installazioni distribuite), mentre la seconda si chiama Administration. Si consiglia di partire da Administration e di inserire sulla destra le informazioni sulla propria organizzazione (nome, città, provincia, CAP e così via). Più in basso invece si possono aggiungere eventuali altri domini locali, da amministrare attraverso il pulsante Add domain (Figura 13.17).

Figura 13.17 Impostazioni generali sull’installazione locale.

Se invece si esegue un doppio clic sul nome del proprio server, sulla parte destra compaiono diverse voci di configurazione. La scheda General contiene la configurazione che è stata specificata durante la fase di installazione del programma. Più interessante quindi è la funzione Mail, dove si può specificare una soglia massima per le caselle e stabilire una politica di gestione dello spazio. È anche possibile stabilire una soglia percentuale di warning e di reject. Raggiunte queste soglie, saranno inviate delle segnalazioni da parte di Scalix. Eventualmente è possibile anche rifiutare le mail in caso di superamento della soglia e avvertire l’utente circa la situazione. La scheda Password permette di stabilire una policy per le password. Per esempio la lunghezza, il modo in cui è composta, la durata, la possibilità di riciclare le vecchie password, il numero dei tentativi di immissione in caso di errore e così via. Nella scheda License Keys si gestiscono le chiavi di attivazione. Tornando alle icone sulla barra superiore si deve analizzare Server Info. Questa icona fornisce un albero di opzioni composto dal nome della macchina, da un sottoalbero denominato Services e da un sottoalbero denominato Queues. Con un doppio clic sull’indirizzo completo della macchina, sulla destra compare un pannello, da cui si possono ricavare diverse informazioni sul funzionamento del mail server. È interessante la scheda Services, che mostra lo stato dei singoli servizi (IMAP, gateway, LDAP, POP3 e così via) e che permette di fermarli e riavviarli. La scheda General mostra i componenti installati, Queues fornisce un quadro riassuntivo delle code del programma, Active Users mostra gli utenti che sono attualmente collegati con Scalix, Mailnodes mostra un riassunto dei nodi di posta presenti, mentre storage fornisce un grafico generale dello stato di occupazione dei dischi e delle caselle.

Alcune di queste informazioni possono essere ottenute in forma diretta tornando sull’albero di sinistra e controllando le voci dentro i sottoalberi Services e Queues. Services contiene tutti i servizi del programma e permette di accedere ai relativi log (Figura 13.18).

Figura 13.18 Gestione dei servizi in Scalix.

Queues mostra più in dettaglio le code del programma. Selezionandole è possibile avere informazioni circa i messaggi accodati ed elaborati. È anche possibile modificare il criterio di filtro e analizzare in maniera più efficace la coda. Questo è molto utile quando si deve gestire un volume di posta molto elevato (Figura 13.19).

Figura 13.19 Pannello per la gestione delle code, in questo caso Local delivery.

L’icona Plugins, nella barra delle icone presente in alto, permette di gestire eventuali plug-in installati in Scalix. L’icona Resources permette invece di creare entità condivise all’interno del sistema di groupware. Inizialmente l’elenco è vuoto, ma è possibile fare clic sul pulsante Create Resource(s) e poi compilare i campi richiesti dalla procedura di autocomposizione (Figura 13.20).

Figura 13.20 Pannello per la creazione di una risorsa di groupw are.

Sono interessanti infine le icone Groups e Users della barra delle icone presenti sulla parte superiore dell’interfaccia. Con Users si creano gli account del sistema di posta elettronica, eventualmente organizzabili in gruppi tramite l’icona Groups. Per quanto concerne gli utenti, inizialmente si ha solamente l’utente di amministrazione creato durante la procedura di installazione. Per aggiungere nuovi utenti si deve fare clic sul pulsante Create User(s), presente in basso e riempire la finestra con le indicazioni (Figura 13.21).

Figura 13.21 Finestra per la creazione di un nuovo utente per i servizi mail e groupw are di Scalix.

Per aggiungere un utente è sufficiente riempire la finestra indicata in Figura 13.21 e poi fare clic su Finish, ma è possibile anche fare clic su Next e avere un nuovo pannello dove inserire una serie di dettagli sulla persona in oggetto (Figura 13.22).

Figura 13.22 Ogni utente può essere specificato con un alto grado di dettaglio.

Facendo ancora clic su Next si può inserire l’utente in uno dei gruppi preesistenti (Figura 13.23).

Figura 13.23 Abbinamento dell’utente ai gruppi definiti in Scalix.

Completata l’operazione, l’utente compare immediatamente nell’elenco a sinistra. Selezionandolo è possibile ottenere, sulla destra, delle informazioni sull’account e avere una serie di comandi per la gestione dell’utente.

Criterio di funzionamento Scalix è in grado di funzionare appena completata l’installazione e può anche eseguire il relay della mail. Gli utenti interni appartenenti allo stesso dominio locale possono inoltrare mail a utenti del proprio dominio e a qualunque dominio esterno. Come unica accortezza è necessario configurare il pannello SMTP dei client di posta elettronica (Thunderbird, Outlook e così via) con l’autenticazione tramite user-id e password. Bisognerà pertanto inserire le credenziali configurate nel pannello utenti di Scalix. Gli utenti esterni che accedono in SMTP possono inviare mail solamente al dominio locale. Questo significa che è già attiva la protezione contro l’open relay. Utenti malintenzionati esterni non potranno quindi usare il server appena configurato come amplificatore di spam. Grazie a Scalix si riesce a mettere in atto un sistema di posta gratuito in tempi estremamente rapidi. Ci sono però alcuni limiti da tenere in considerazione. Manca un componente in grado di scaricare le mail presenti su server POP3 esterni. Scalix, per default, non dispone inoltre di meccanismi integrati antivirus e antispam. È però veloce installarli, soprattutto se si decide di usare ClamAV come antivirus e Spam-Assassin come sistema antivirus. Per capire come installare questi elementi si consiglia di scaricare il manuale “Scalix Setup and Configuration Guide” presente all’indirizzo http://www.scalix.com/community/downloads/documentation.php e copiare la configurazione

suggerita. Per la parte antivirus si deve fare riferimento alla pagina 13 e seguenti del manuale PDF (in versione 11.3 al momento della stesura del libro), mentre per l’antispam si deve fare riferimento alla pagina 23 del manuale (sempre riferito alla versione 11.3). Un aspetto interessante di Scalix è la webmail integrata, disponibile all’indirizzo http://indirizzo/webmail, dove indirizzo punta al server locale appena installato (Figura 13.24). Da questo pannello web è possibile scrivere e leggere posta, gestire un calendario, i contatti e le note e avere accesso alle cartelle pubbliche.

Figura 13.24 Webmail e groupw are integrato di Scalix, erogato in modalità w eb.

Checklist Scaricare il prodotto facendo attenzione a scegliere l’archivio adatto alla propria distribuzione e alla specifica versione installata. Configurare correttamente il DNS e il file hosts. Verificare che siano rispettati i requisiti minimi e che siano presenti tutti i pacchetti di supporto necessari, tra cui il database PostgreSQL. Attivare la procedura guidata di configurazione. Seguire la procedura fornendo le indicazioni basilari richieste (il nome del mail server, la password di accesso tra servizi e server, i dati di accesso al database e così via). Installare la Java Virtual Machine sul computer dove sarà eseguita l’amministrazione di Scalix. Verificare che i servizi di Scalix partano automaticamente al boot della macchina. Lanciare il pannello di amministrazione e configurare gruppi e utenti. Configurare i client di posta elettronica. Eventualmente applicare le configurazioni per attivare antivirus e antispam. Se ci sono caselle di posta gestite su provider esterni, si deve attivare il forward automatico della mail

verso gli account di Scalix. Applicare i criteri di sicurezza sul firewall.

Capitolo 14

Capitolo 14 - Fax di rete con HylaFAX Sarebbe un passo in avanti se ci si potesse astenere da uno dei rituali più celebrati nella vita da ufficio: l’invio dei fax. Questa è infatti una cerimonia che comporta una certa perdita di tempo e lo spreco di carta che finisce nel cestino o accumulata in giro per l’ufficio. La situazione è del tutto analoga sul versante della ricezione: solo una piccola percentuale della carta in arrivo è effettivamente utile. Tutto il resto finisce ancora una volta nel cestino o dentro raccoglitori. Sarebbe molto meglio avere questo materiale in formato digitale e decidere agevolmente che cosa cancellare, archiviare o stampare. Questa aspirazione può essere realizzata con un fax server. Sono sufficienti un computer centrale, un modem e un pacchetto software adeguato. Tutti i fax in arrivo saranno memorizzati sul server come file e tutte le postazioni potranno spedire fax da qualunque programma tramite un componente client. Non c’è nulla di innovativo in tutto questo. Prodotti software di questa categoria esistono da anni, anche se non tutte le soluzioni riescono a soddisfare le aspettative. Il problema più serio riguarda l’affidabilità: molti programmi non sono in grado di funzionare correttamente per tempi prolungati e finiscono per creare disservizi. Molto presto questi problemi faranno rimpiangere il collaudato fax manuale. Diversi pacchetti hanno ottenuto nel tempo una fama invidiabile, conquistando notevoli quote di mercato. La qualità però si paga, a meno che non si decida di utilizzare una soluzione open-source. La piattaforma Linux dispone di un ottimo prodotto fax distribuito in maniera gratuita. Non è richiesto alcun costo di licenza per server o per numeri di telefono, né licenze da pagare per ogni postazione su cui si decide di installare il client fax. Il prodotto si chiama HylaFAX (www.hylafax.org) ed è copyright di Silicon Graphics e di Sam Leffler. HylaFAX utilizza un modello client-server: il componente principale risiede su una macchina centrale e resta in ascolto di eventuali client presenti sulla rete. Questi accedono al sistema fax attraverso un software leggero che comunica con il server tramite un protocollo specifico. Eventuali fax in arrivo dall’esterno vengono gestiti autonomamente dal sistema, che provvederà a rispondere alla chiamata, a gestire la comunicazione e a salvare in formato TIFF o PDF il fax appena arrivato. Questi potranno poi essere spediti automaticamente via e-mail a una persona preposta allo smistamento oppure a un interno ben preciso, in base alle regole di gestione dei fax in arrivo. HylaFAX gestisce un numero arbitrario di modem, provvedendo anche al bilanciamento delle risorse. In questo modo è possibile utilizzare una batteria di modem e smistare volumi consistenti di comunicazioni in arrivo.

Requisiti hardware HylaFAX deve essere installato in un computer accessibile da tutte le postazioni che necessitano del servizio fax, tipicamente un server. Su questo computer devono essere installati uno o più modem con supporto fax, possibilmente esterni. I prodotti interni sono più problematici da configurare in un ambiente Linux e non sempre il funzionamento è garantito. Si consiglia di evitare i cosiddetti host based modem, che per poter funzionare hanno bisogno di un driver software specifico, in quanto, per ridurre i costi, non integrano parte dell’elettronica di controllo. Questi circuiti sono simulati via software. Non sempre però è disponibile un driver per Linux e si rischia di trovarsi con un modem inservibile. Sarebbe meglio orientarsi verso un modem seriale esterno: basta collegarli e sono già pronti

per l’uso. La connessione seriale è perfettamente adeguata per dispositivi lenti come i modem ed evita i problemi di configurazione e reperimento di driver. Comincia però a essere difficile trovare in commercio modem seriali. Si consiglia eventualmente di fare una ricerca nel mercato dell’usato o nei siti di vendita on-line. Il tempo impiegato nella ricerca sarà certamente ripagato in fase di configurazione. Il server che ospiterà HylaFAX dovrà naturalmente possedere almeno una porta seriale, un dettaglio che oggi è bene verificare. Molti sistemi escono di fabbrica privi di questa connessione. Oramai la connettività è universalmente realizzata tramite USB e questa sarà la scelta obbligata se non sarà possibile reperire un modem seriale. In questo caso si dovrà verificare la compatibilità con Linux e la disponibilità di un driver.

Installazione HylaFAX può essere scaricato dalla sezione download del sito www.hylafax.org (Figura 14.1), sia in formato sorgente sia in formato binario. Le distribuzioni ufficialmente supportate sono Debian, Ubuntu, Fedora Core, Mandriva, Red Hat, CentOS e SuSE.

Figura 14.1 Sito ufficiale di HylaFAX.

Esiste un pacchetto HylaFAX ufficiale per Ubuntu. L’installazione in questa distribuzione risulta quindi molto semplice:

apt-get install hylafax-server

Su CentOS la procedura è più lunga. Prima di installare il programma è necessario risolvere alcune dipendenze. I pacchetti elencati di seguito sono necessari per il funzionamento del software e devono essere installati dall’amministratore di sistema con il tool yum: sharutils, per la gestione dei programmi shell archiver; libtiff, una libreria per leggere, scrivere e manipolare file grafici TIFF; ghostscript, l’interprete dei file Postscript e PDF; ghostscript-fonts, i font per Ghostscript; mgetty, il componente che risponde alle chiamate via modem e può trasferire la comunicazione a

un’altra applicazione. Completata questa fase è possibile installare il prodotto attraverso il gestore dei pacchetti di CentOS: yum install hylafax

Se il pacchetto non fosse disponibile, è possibile aggiungere un repository di terze parti nella configurazione di sistema. Si veda a tal proposito l’Appendice E. Durante l’installazione di HylaFAX potrebbe essere segnalata l’assenza del pacchetto metamail necessario per alcune funzioni di conversione che si vedranno più in dettaglio nei prossimi paragrafi. Alcune distribuzioni contemplano il pacchetto metamail, mentre altre non comprendono questo pacchetto nel loro elenco. In questi casi si può scaricare il pacchetto per una versione precedente della propria distribuzione oppure ignorare completamente il fatto e porvi rimedio più avanti. In questo capitolo si utilizzerà la seconda strada. La procedura di installazione creerà le directory necessarie e copierà tutti i file di HylaFAX nelle posizioni corrette. I file principali si troveranno in /var/spool/hylafax, mentre i file di configurazione si troveranno in /etc/hylafax. All’interno di questa directory potrebbero essere presenti altre directory molto importanti c o m e etc e log. Queste sono in realtà link verso /var/spool/hylafax/etc e /var/spoll/hylafax/log.

Configurazione La procedura di configurazione di HylaFAX è articolata e consta di molti passaggi. Per cominciare bisogna verificare che i percorsi verso i font di Ghostscript siano corretti. Ghostscript è un noto interprete per il linguaggio PostScript e PDF e viene usato da HylaFAX per generare i font nelle operazioni di visualizzazione del testo. HylaFAX si aspetta di trovare questi font in /usr/share/ghostscript/fonts. Qualora i font non fossero presenti in questo percorso è necessario creare un link simbolico verso il percorso corretto, utilizzando il comando che segue: ln -s /usr/share/ghostscript/8.15/lib /usr/share/ghostscript/fonts

Il comando crea una directory “fittizia” fonts all’interno della directory /usr/share/ghostscript/, instaurando un collegamento verso /usr/share/ghostscript/8.15/lib. Quando si apre la directory fonts si sta in realtà accedendo a /usr/share/ghostscript/fonts.

Al posto della directory denominata 8.15 indicata nell’esempio precedente, si dovrà usare il nome di directory corrispondente alla versione di Ghostscript installata nel proprio sistema. La presenza del nuovo link simbolico può essere verificata visualizzando la directory ghostscript. Il risultato dovrebbe apparire come il seguente: Listato 14.1

[root@linuxcage ghostscript]# ls -la totale 24 drwxr-xr-x 3 root root 4096 4 gen 05:22 . drwxr-xr-x 195 root root 4096 4 gen 01:07 .. drwxr-xr-x 5 root root 4096 9 nov 22:18 8.15 lrwxrwxrwx 1 root root 31 4 gen 05:22 fonts -> /usr/share/ghostscript/8.15/lib

Il collegamento della cartella fonts è evidenziato con una freccia nell’ultima riga del listato precedente. Le operazioni preliminari sono concluse. Si può procedere alla configurazione di HylaFAX richiamando il programma faxsetup.

Faxsetup su CentOS All’avvio della procedura potrebbero comparire messaggi di warning. Si tratta di problemi non critici che possono essere trascurati, sempre a patto di aver installato scrupolosamente i pacchetti indicati in precedenza e di aver seguito le procedure finora descritte. Le indicazioni di warning sono seguite da una serie di domande. Faxsetup è infatti una procedura guidata che configura HylaFAX in base alle risposte fornite dall’utente. Su CentOS potrebbe prima di tutto essere segnalato che non esiste un utente fax e viene chiesto se lo si vuole creare. Bisogna rispondere affermativamente a questa domanda e anche alla richiesta di creare l’alias FaxMaster. La domanda successiva richiede il nome dell’utente che riceverà le e-mail relative al servizio fax. Di default viene indicato root. Se l’amministratore riceve la posta elettronica di servizio su un altro account, è necessario specificarne il nome in questo passaggio. A questo punto viene visualizzato uno schema relativo ai servizi per il fax che saranno attivati all’avvio del sistema. Di default il sistema viene configurato per attivare all’avvio i demoni faxq e hfaxd. Questa configurazione è corretta e va confermata. A questo punto potrebbero essere richiesti alcuni parametri telefonici, come il country code (39 per l’Italia), l’area code (ovvero il prefisso locale, per esempio 0542), il prefisso per le chiamate su lunghe distanze (va lasciato inalterato in quanto non supportato in Italia), il prefisso internazionale (lasciato anch’esso di default, in quanto non impiegato) e il nome del file con le regole di composizione (va lasciato il default). Le due domande seguenti riguardano il tracciamento del server e delle sessioni di spedizione e ricezione. Si tratta, in sostanza, del livello di dettaglio che si vuole nei file di log per le operazioni fax. Si consiglia di lasciare i valori suggeriti di default e alterarli in seguito in caso di necessità precise. Seguono diverse domande relative al servizio fax. Si consiglia di confermare i valori suggeriti, fino ad arrivare al punto in cui viene visualizzato il riepilogo per i parametri inseriti differenti dai valori di default. A questo punto basta confermare, e verrà generato il file di configurazione /var/spool/hylafax/etc/config; verrà chiesto se si vuole attivare subito il servizio. Se si verifica qualche problema di configurazione è possibile richiamare nuovamente faxsetup oppure modificare manualmente il file config. In tal caso bisogna ricordarsi di riavviare i servizi di HylaFAX per applicare la nuova configurazione. Si deve usare questo comando:

/etc/init.d/hylafax restart

Il file hylafax è uno script che provvede a riavviare i due demoni hfaxd e faxq. La configurazione prosegue con la parte relativa ai modem. Questo aspetto verrà trattato dopo la sezione dedicata a Ubuntu.

Faxsetup su Ubuntu Anche su Ubuntu potrebbero comparire messaggi di warning all’avvio della procedura di configurazione. Anche in questo caso si tratta di messaggi non critici, che possono essere tralasciati. Viene subito presentato uno schema con i servizi che saranno avviati al lancio del sistema: Listato 14.2

HylaFAX configuration parameters are: [1] Init script starts faxq: yes [2] Init script starts hfaxd yes [3] Start paging protocol: no Are these ok [yes]?

Il resto della configurazione è eseguito in maniera automatica, generando il file di configurazione /var/spool/hylafax/etc/config. Si passa alla configurazione del modem.

Configurazione del modem Giunti a questa fase si è terminata la configurazione generale e si hanno i servizi di HylaFAX attivi nel sistema. Ora si deve provvedere alla configurazione del modem. È lo stesso programma faxsetup che attiverà la procedura di configurazione tramite la domanda seguente: Do you want to run faxaddmodem to configure a modem [yes]?

Rispondendo affermativamente verrà lanciata l’utility faxaddmodem preposta all’aggiunta di un nuovo modem nel sistema fax. Per cominciare, bisogna specificare la porta alla quale è collegato il modem, indicando il nome del device Linux della periferica: per com1 sarà ttyS0 mentre per com2 sarà ttyS1 (attenzione al fatto che la “S” deve essere maiuscola). Confermando si dovranno inserire il country code (39), l’area code (per esempio 0542) e il numero del proprio fax, nel formato +39.0542.12345678. È importante la domanda relativa alla stringa di identificazione (Local identification string (for TSI/CIG)), in quanto si tratta della riga di identificazione che compare in cima a ogni fax in uscita. Si può inserire il nome della propria organizzazione. Si può rispondere alle domande seguenti con il valore di default suggerito. È utile invece prestare attenzione a Protection mode for received facsimile?. Si devono indicare quali permessi saranno attribuiti ai fax in arrivo. Di default viene proposto il diritto 600, ovvero lettura e scrittura per l’utente proprietario del file generato (l’utente fax). Questi privilegi sono un po’ restrittivi: sarebbe meglio specificare 644, in modo che chiunque possa leggere il fax arrivato.

Una domanda analoga viene posta per le modalità di protezione per il log di sessione e di protezione per la periferica Linux (ttyS0 o ttyS1 per esempio). I diritti 600 suggeriti sono idonei. È importante anche Rings to wait before answering?. Specifica quanti squilli devono essere rilevati prima che il sistema risponda alla chiamata. Di default è indicato uno squillo. Come scelta predefinita, nella domanda seguente viene indicato che l’altoparlante del modem deve rimanere spento. È possibile specificare on e sentire i segnali acustici del modem, una scelta consigliabile per capire come HylaFAX sta usando il dispositivo. Seguono altre domande: i comandi passati a getty possono essere lasciati di default, si consiglia il default anche per la domanda relativa al percorso per il file di controllo degli accessi sui fax in ingresso (TSI control list). Questo file permette di limitare l’accesso al sistema fax a un numero ristretto di utenti. A questo punto si possono accettare le impostazioni di default fino a Percent good lines to accept during copy quality checking?. Il valore, impostato di default a 95, indica il numero di linee corrette per avere un fax definito “buono”. Max consecutive bad lines to accept during copy quality checking? indica il numero massimo di linee consecutive ricevute male che possono essere accettate. La domanda seguente fissa il numero massimo di pagine che possono essere ricevute per comunicazione fax, impostato di default a 25. Per semplificare la fase di configurazione iniziale si consiglia ancora una volta di accettare le impostazioni di default suggerite fino alla schermata di riepilogo e poi confermare. A questo punto verrà eseguita una scansione del modem. Il sistema cercherà di contattare il modem per valutare la velocità massima della comunicazione seriale. Una volta individuato il valore migliore, sarà attivato il dialogo con l’apparato. La prima verifica riguarderà le capacità fax, in particolare si controllerà il supporto Class 1, Class 2 o Class 2.0. Sarebbe meglio usare il supporto 2.0, ma bisogna verificare che il proprio modem gestisca correttamente lo standard. Alcuni prodotti, anche di marche note, hanno problemi in tal senso e nel dubbio si consiglia di usare lo schema Class 1, considerato uno standard universale. Confermando viene presentato il nome del modem (se la stringa è memorizzata nel firmware del prodotto) e vengono richiesti alcuni parametri di funzionamento. Se la configurazione interna del modem non è stata alterata si consiglia di utilizzare valori di default suggeriti, fino ad arrivare alla schermata di riepilogo. Confermando, viene eseguito un controllo finale, in cui si confronta la configurazione appena realizzata per il modem in oggetto con la configurazione generale di HylaFAX realizzata in precedenza. Vengono messi in rilievo eventuali parametri in conflitto e si possono apporre eventuali modifiche. La configurazione è conclusa. Viene chiesto se si vuole usare faxaddmodem per configurare un altro modem. Se si hanno altri modem bisogna rispondere yes e ripetere l’operazione di configurazione. Una volta conclusa la configurazione di tutti i modem si risponde no. Resta in tal caso solo una domanda: Should I run faxmodem for each configured modem?. Il programma di installazione sta chiedendo se deve attivare immediatamente la coda di spedizione e fare in modo che si possano già spedire fax. Questo viene fatto attraverso il comando faxmodem, che ha la funzione di segnalare al demone faxq, preposto alle operazioni di invio, la presenza del nuovo modem configurato. Occorre rispondere affermativamente. La fase di configurazione generale è ora conclusa. Il sistema è già in grado di spedire fax, mentre per la ricezione è necessario eseguire ancora alcune operazioni. Bisogna infatti aggiungere allo script di avvio di Linux un comando per fare in modo che i modem restino in attesa di chiamate esterne e siano in grado di gestirle. Bisogna andare in /etc/rc.d e aprire il file rc.sysinit o meglio il file rc.local, se supportato dalla propria distribuzione. Questo file è preposto a contenere i comandi utente e viene lanciato dopo che tutti gli altri script di avvio hanno concluso l’esecuzione. Questo file non viene inoltre modificato dai tool di configurazione (automatici o manuali) di sistema ed è il punto migliore dove inserire le configurazioni personalizzate. Questo è il comando da inserire in fondo allo script di avvio:

faxgetty /dev/ttyS1 &

Viene cioè attivato un modem connesso alla seconda porta seriale, ttyS1 (dev/ttyS1) di Linux, tramite il comando faxgetty. Il comando occupa una shell di Linux, rendendola inutilizzabile per altri scopi ed è per questo motivo che faxgetty viene richiamato con il parametro &. Questo attiva il processo in background, liberando la shell da cui è stato richiamato. Subito di seguito bisogna aggiungere una seconda riga: faxmodem /dev/ttyS1

Il comando faxmodem serve per la spedizione e informa il demone faxq della presenza del modemfax sulla porta ttyS1. Questo comando era stato attivato alla fine del processo di configurazione con un’apposita domanda. Il suo effetto verrebbe però “perso” al riavvio e bisogna fare in modo che venga lanciato a ogni avvio del sistema. Qualora vi siano altri modem collegati a HylaFAX, bisogna aggiungere altrettante righe di faxgetty e di faxmodem, con le relative indicazioni del nome Linux della periferica.

Se manca metamail Durante la fase di installazione si era puntualizzato che il pacchetto metamail non è presente in tutte le distribuzioni Linux. Non si tratta di un dettaglio da poco, in quanto il programma viene usato da HylaFAX per trasformare i fax appena arrivati in allegati e-mail. Gli allegati vengono automaticamente inseriti all’interno di un’e-mail e inoltrati a una casella di posta elettronica, che di solito appartiene a una persona in azienda che smista le comunicazioni fax. Se manca metamail, questa operazione di conversione non va a buon fine. Bisogna quindi verificare la propria distribuzione Linux e installare il pacchetto, se disponibile. Se invece il pacchetto non è presente nei dischi di installazione, bisogna porvi rimedio in qualche modo. È possibile accedere al motore di ricerca di pacchetti RPM www.rpmfind.net e inserire la stringa metamail nel campo di ricerca. Si possono trovare vari link a pacchetti metamail per versioni precedenti della propria distribuzione o per distribuzioni compatibili. Installando uno di questi pacchetti si può risolvere il problema. È comunque possibile evitare di installare un pacchetto non supportato, modificando un file di configurazione di HylaFAX. Si tratta di FaxDispatch, localizzato in /var/spool/hylafax/etc. Se non è presente lo si può creare da zero con un editor di testi. Le prime righe di FaxDispatch riportano queste indicazioni: SENDTO=FaxMaster; FILETYPE=pdf;

Queste righe devono essere sostituite con le seguenti: SENDTO=FaxMaster; MIMENCODE=bin/uuencode_it; FILETYPE=pdf;

La prima riga specifica la persona preposta allo smistamento delle comunicazioni fax in arrivo. Ogni volta che arriva un fax, questo verrà inoltrato nella casella di posta indicata a destra di SENDTO. Di default è FaxMaster, ma dovrebbe essere cambiato con un account di posta elettronica effettivo. La seconda riga specifica il comando o lo script che gestisce la trasformazione degli allegati binari in un formato compatibile con gli standard di posta elettronica. Non bisogna dimenticare che la posta elettronica può

veicolare unicamente testi. Qualunque allegato binario (come programmi, immagini o file PDF) deve prima essere convertito in formato testo. In HylaFAX questo processo di conversione dovrebbe essere affidato a metamail, ma se è assente occorre trovare un sostituto. L’operazione viene affidata a uuencode_it, un comando che in realtà non esiste. È piuttosto uno script che deve essere creato manualmente dentro la directory bin di HylaFAX (/var/spool/hylafax/bin). Per generare questo script si deve aprire un editor di testo e trascrivere fedelmente il contenuto che segue: #!/bin/sh uuencode -m $1 $1 | grep -E -v "^begin|^====$" 2>/dev/null

Il file deve essere salvato con il nome uuencode_it e i suoi diritti cambiati in modo che possa essere eseguito: chmod 777 uuencode_it

I diritti 777 assicurano lettura, scrittura ed esecuzione da qualunque utente o gruppo. A questo punto i problemi dovrebbero essere risolti.

Configurazione degli utenti di HylaFAX La configurazione generale è conclusa. Ora si può rivolgere l’attenzione ai client e fare in modo che tutte le macchine possano inviare fax utilizzando il server centrale. Questa funzionalità è regolata da un meccanismo di credenziali interno a HylaFAX. Ogni client che intende spedire fax deve fornire a HylaFAX uno user name e una password preimpostata dall’amministratore. Questi utenti non hanno comunque relazione con gli utenti di Linux e possono essere scelti in piena libertà. Si può decidere di creare un account di HylaFAX per ogni utente abilitato a inviare fax oppure creare un account unico e usarlo su tutte le macchine. Questa è probabilmente la scelta più pratica per le piccole realtà. Per creare un utente di HylaFAX si usa la sintassi indicata di seguito: faxadduser -p

Per esempio: faxadduser -p vp126 szanzi

Si è creato l’utente szanzi con password vp126. Tutti gli utenti creati saranno inseriti nel file hosts.hfaxd presente in /var/spool/hylafax/etc. Al suo interno sono presenti gli indirizzi IP dei sistemi abilitati e le credenziali degli utenti che possono usare HylaFAX. La password viene salvata in maniera cifrata.

Client fax su Windows La parte server è conclusa e si può pensare alle postazioni periferiche. Esistono vari componenti client per HylaFAX per le piattaforme Unix, Windows e Mac. Molte soluzioni sono gratuite, ma esistono anche ottimi pacchetti commerciali. L’elenco dei client è disponibile all’indirizzo

http://www.hylafax.org/content/Desktop_Client_Software.

Un client Windows leggero, veloce da configurare e intuitivo è WHFC di Ulrich Eckhardt, disponibile all’indirizzo http://whfc.uli-eckhardt.de e rilasciato con licenza GNU. Il prodotto supporta Windows 95, 98, NT 4.0, 2000, XP e Vista. WHFC permette di gestire spedizioni multiple, rubriche, copertine, allarmi e visualizza in maniera grafica le code del server fax, mostrando lo stato e dando la possibilità di cancellare eventuali fax in attesa di spedizione. Il client permette inoltre di controllare molti parametri di invio, come il numero dei tentativi, i modem usati per la spedizione e così via. L’invio dei fax avviene tramite la normale funzione di stampa, utilizzando una stampante virtuale PostScript agganciata alla porta di WHFC. Qualunque programma in grado di stampare è perciò abilitato a spedire fax. Una volta scaricato l’archivio di distribuzione si deve procedere all’installazione tramite un doppio clic sull’icona. L’unico requisito è la presenza della libreria Microsoft odbc32.dll. Questa è generalmente disponibile in tutti i sistemi, ma se necessario è possibile scaricarla dal sito di Microsoft all’indirizzo http://msdn.microsoft.com/en-us/data/aa937730.aspx facendo riferimento al pacchetto MDAC. Completata l’installazione si deve andare in Start > Programmi > WHFC e lanciare WHFC (Figura 14.2).

Figura 14.2 Schermata del pannello principale di W HFC.

Il primo passo è andare nel menu Fax, fare clic su Opzioni di sistema e specificare l’indirizzo del server HylaFAX in Nome host. In questa fase, le altre voci possono essere lasciate di default (Figura 14.3).

Figura 14.3 Finestra per le opzioni di sistema.

Dopo aver confermato, si passa in Impostazioni Utente (Figura 14.4). Bisogna inserire il nome esteso dell’utente e l’user-id specificato con il comando faxadduser utilizzato in precedenza. In questa scheda si deve anche precisare se si vuole una e-mail di segnalazione a ogni spedizione, una copertina e indicare il formato della carta. Si devono anche specificare i dati che compariranno nella prima riga in alto su ogni fax spedito (ora, numero di pagine, numero di fax e così via).

Figura 14.4 Finestre per le impostazioni dei dati utente.

Si consiglia di abilitare Auto aggiorna per fare in modo che le code siano aggiornate in tempo reale; fare

clic su OK per concludere. Viene subito richiesta la password dell’utente appena configurato. Se non si riesce a entrare, nonostante i dati siano corretti, significa che l’indirizzo IP del client non è stato inserito nel file hosts.hfaxd presente in /var/spool/hylafax/etc. Se non si accede automaticamente al server si può fare clic sull’icona che rappresenta un connettore che si collega a una porta. Questa icona mette in contatto il client locale con il server di HylaFAX. Se tutti i dati sono corretti si dovrebbe vedere la coda di HylaFAX nell’area centrale. Tramite i tasti In uscita, Ricevuti e Inviati è possibile visualizzare le code di trasmissione, di ricezione e dei fax andati a buon fine. Il client WHFC mantiene aggiornati questi elenchi, consultando le directory sendq, recvq e doneq presenti in /var/spool/hylafax sul server. Ogni job elencato è rappresentato da un file TIFF nominato progressivamente. I file presenti in coda possono essere cancellati, se i permessi impostati consentono questa operazione. Eliminando un file all’interno della coda in uscita si evita che il fax in oggetto venga effettivamente inoltrato da HylaFAX. Da un punto di vista pratico viene cancellato un file dalla directory sendq, evitando che il server lo gestisca. Per visualizzare in maniera grafica i fax presenti in coda è necessario aprire le configurazioni di sistema (menu Opzioni di sistema). Nella sezione Sistema si deve inserire la seguente riga nella casella di testo Programma e argomenti per la visualizzazione dei file ricevuti: rundll32.exe C:\WINDOWS\System32\shimgvw.dll,ImageView_Fullscreen %s

In questo modo viene richiamato il visualizzatore integrato in Windows XP. Ora non resta che installare il driver di stampa necessario per spedire effettivamente i fax. Bisogna andare nel Pannello di controllo di Windows, scegliere l’icona Stampanti e Fax e aggiungere una nuova stampante. La stampante da creare deve essere locale e collegata alla porta WHFCFAX (Figura 14.5).

Figura 14.5 Si deve creare una stampante locale collegata alla porta di W HFCFAX.

Per scegliere il driver stampante si deve scorrere l’elenco, selezionare Apple sull’albero di sinistra e fare

clic su Apple LaserWriter 16/600 PS. Viene scelto questo modello specifico per via del supporto PostScript necessario a HylaFAX. Si consiglia di rinominare la stampante appena creata in HylaFAX (al posto del nome esteso standard della stampante). Ogni volta che si stamperà su questa unità verrà visualizzata una finestra dove inserire il numero del destinatario, il tipo di pagina, la possibilità di inviare in modalità Fine, di specificare una copertina in formato HylaFAX e molte altre opzioni di invio (Figura 14.6).

Figura 14.6 Finestra per la spedizione di un fax.

Il fax verrà subito immesso nella coda di invio e poi spedito. Conclusa la spedizione, il fax sarà posto nella coda dei fax inoltrati. In caso di problemi verranno eseguiti ulteriori tentativi. Il numero di volte è specificato in Opzioni di sistema, alle voci Numero massimo di chiamate e Numero massimo di tentativi (Figura 14.7).

Figura 14.7 Il numero di tentativi di spedizione è regolato dalle opzioni di sistema.

Qualora vi fossero problemi a contattare il server dal proprio client, bisogna verificare che la porta 4559/TCP sul sistema che ospita HylaFAX sia aperta e che siano anche aperte le porte dalla 1024 alla 65535. La porta 4559/TCP è dedicata al controllo di HylaFAX, mentre le altre sono porte standard utilizzate per le comunicazioni tra il sistema centrale e i computer periferici. Questo dialogo tra server e client avviene tramite il protocollo FTP. Il client è ora operativo. Si consiglia di usare questo prodotto, prendere dimestichezza con HylaFAX e in seguito sperimentare altri client per farsi una panoramica dell’offerta software per questo gestore di fax. Un prodotto valido quanto WHFC è Frog Fax@Mail disponibile all’indirizzo http://www.frogfax.com. Si tratta di un programma commerciale che è diventato recentemente freeware.

Stampa automatica dei fax ricevuti Il sistema HylaFAX è costruito in maniera modulare. Il demone principale hfaxd non svolge infatti tutte le operazioni, ma utilizza altri moduli software per eseguire i vari compiti. Molti di questi moduli sono in realtà script di shell, che a loro volta richiamano altri programmi. Gli script si trovano nella directory /var/spool/hylafax/bin e possono essere liberamente modificati per alterare il comportamento del programma a seguito di particolari eventi. Lo script faxrcvd è invocato da HylaFAX ogni volta che arriva un fax. Si può allora modificare questo script e aggiungere una serie di istruzioni per fare in modo che ogni fax ricevuto venga stampato automaticamente. Basta posizionarsi in fondo e aggiungere la riga seguente:

tiff2ps -a $FILE | lpr

Si utilizza questo comando perchè i fax gestiti da HylaFAX sono in formato tiff. La scelta è dettata dal fatto che tiff supporta di default un numero elevato di codifiche, compresa quella per i fax gruppo 4. Questo formato grafico non è però idoneo per la stampa, almeno in ambito Linux, e bisogna tradurlo in PostScript. tiff2ps svolge questo lavoro eseguendo proprio la conversione del file che contiene l’ultimo fax arrivato (variabile $FILE) dal formato tiff al formato PostScript. Il parametro -a indica che si vogliono stampare tutte le pagine della comunicazione fax. Bisogna a tal proposito sapere che il file tiff è sempre unico, anche quando il fax ricevuto è composto da più fogli. In tal caso le varie pagine sono codificate all’interno dello stesso file grafico. Questa interessante modalità multipagina per la codifica fax è supportata dalla maggior parte dei visualizzatori di immagini. Aprendo un fax appartenente al gruppo 4 con un programma di visualizzazione moderno compariranno i pulsanti di avanti e indietro, per sfogliare le pagine. La parte finale del comando, | lpr, concatena l’output di tiff2ps alla coda di stampa di default. Naturalmente la coda di stampa deve essere stata configurata in maniera corretta. Maggiori informazioni sulla gestione delle code possono essere reperite nel Capitolo 3, relativo ai print server. Esaminando lo script faxrcvd si può scoprire che questo controlla anche la spedizione delle e-mail contenenti in allegato i fax arrivati. Manipolando questo script è possibile cambiare il formato delle e-mail oppure i testi di default (per esempio traducendoli in italiano).

Regole di chiamata Un altro file interessante è dialrules, in /var/spool/hylafax/etc, che controlla il modo in cui vengono composti i numeri di telefono. Il formato del file è abbastanza complesso, ma è possibile operare semplici modifiche per risolvere il problema comune del numero da anteporre per ottenere la linea. Negli uffici non si ha quasi mai un accesso telefonico diretto all’esterno, ma è piuttosto necessario comporre un numero specifico per ottenere la linea dal centralino, per esempio digitando 0 prima del numero da chiamare. Si può inserire questa regola nel file di composizione di HylaFAX. Si deve aprire dialrules, andare in fondo e portare il cursore prima dell’ultima parentesi quadra chiusa. Bisogna premere il tasto Invio per creare una riga vuota, poi si deve digitare la sequenza seguente (rispettando spazi e maiuscole): ^[0-9]{lunghezza,}$ =numeroEsterno,&

Al posto di lunghezza bisogna inserire un numero per indicare dopo quante cifre si deve applicare la regola. Un esempio renderà tutto più chiaro. Gli interni della propria azienda potrebbero essere gestiti con tre cifre. Componendo questi numeri si accede al telefono delle persone presenti in altri uffici, eventualmente anche apparecchi fax interni. Si può allora inserire la cifra 4 al posto di lunghezza e indicare così a HylaFAX che i numeri telefonici esterni hanno almeno 4 cifre. In tali casi si applica la regola indicata a destra e cioè anteporre sempre numeroEsterno seguito da una pausa (carattere ,) e dal numero telefonico indicato dall’utente in fase di spedizione (carattere &). Per questo esempio, la riga da inserire in fondo a dialrules è la seguente: ^[0-9]{4,}$ =0,&

Se non serve tutta questa flessibilità è possibile optare per una strada più semplice. Si può andare in /var/spool/hylafax/etc/ e aprire il file relativo alla porta configurata, per esempio config.ttyS0.

Scorrendo questo file si dovrebbe trovare la seguente riga: ModemDialCmd: ATDT%s # T for tone dialing

Questa contiene la stringa Hayes da usare per attivare la chiamata sul modem. AT è il parametro da anteporre ogni volta che si interroga il modem. D indica una chiamata (Dial) . T specifica la richiesta della chiamata a toni ed è seguito da %s, che rappresenta il numero da chiamare. Se non esiste la necessità di mandare fax verso numeri interni, si può inserire lo 0 direttamente nella stringa di chiamata del modem e risolvere il problema. Tutte le chiamate sarranno precedute da uno 0. La riga di configurazione diventa la seguente: ModemDialCmd: ATDT0,%s # T for tone dialing

La virgola dopo lo 0 serve per richiedere una pausa prima di comporre il numero. Alcuni centralini sono lenti e potrebbero perdere qualche numero se non si inserisce una pausa dopo l’accesso alla linea esterna.

Copertine HylaFAX fornisce la possibilità di aggiungere una copertina all’invio di ogni fax. Purtroppo, però, non è così semplice crearne una personalizzata. Prima di tutto bisogna impostare il modello di copertina tramite un programma di composizione, per esempio Word. All’interno del documento vanno inserite stringhe di testo di propria scelta nei punti in cui posizionare le variabili per il destinatario, l’oggetto, il commento e così via. La copertina deve essere stampata su file tramite una stampante PostScript. Si deve a tal proposito andare nel Pannello di controllo e creare una nuova stampante locale. Come porta si deve specificare FILE: e come modello di stampante si può utilizzare la Apple LaserWriter 16/600 PS. Bisogna però ricordarsi di andare in Proprietà, scegliere la scheda Generale, fare clic su Preferenze di stampa e poi su Avanzate. In Opzioni PostScript alla voce Opzione output PostScript bisogna scegliere Encapsulated PostScript (EPS) (Figura 14.8).

Figura 14.8 Impostazione dell’output PostScript per la gestione della copertina.

Ora si può stampare salvando il risultato in un file. Questo file deve poi essere aperto su un editor di testo. Bisogna cercare le stringhe che si erano inserite in precedenza e racchiuderle tra parentesi tonde. Le stringhe (parentesi comprese) devono essere cancellate e sostituite con una delle variabili di HylaFAX. Le variabili possibili e il loro significato sono elencate nella Tabella 14.1. Durante l’invio, HylaFAX sostituirà automaticamente le variabili con i dati inseriti nella finestra di spedizione. Sostituite le variabili, si può salvare nuovamente il file in formato rigorosamente testuale e utilizzare questo modello come copertina all’interno del client di invio fax. Tabella 14.1

Variabile

Significato

to

Destinatario

from

Mittente

to-company

Azienda del destinatario

from-company

Azienda del mittente

to-location

Città del destinatario

from-location

Città del mittente

to-voice-number

Numero di casella vocale del destinatario

from-voice-number Numero di casella vocale del mittente to-fax-number

Numero fax del destinatario

from-fax-number

Numero fax del mittente

comments

Commento

commentsX

x-esima linea di commento

regarding

Oggetto della comunicazione

pageWidth_

Larghezza pagina in millimetri

page-count

Numeri di pagine, esclusa la copertina

pageLength

Lunghezza pagina in millimetri

todays-date

Data e ora correnti

Ora si può importare la copertina nel client di spedizione. Basta andare nella finestra di spedizione dei fax e specificare il nome del file nella riga Copertina. Bisogna anche fare clic sul controllo Usa copertina per attivare la funzione (Figura 14.9).

Figura 14.9 La copertina si specifica nell’omonima sezione del client di spedizione.

Come si può notare, la procedura è complessa, in quanto non è facile modificare manualmente un file PostScript senza incontrare problemi. Anche riuscendoci, non è detto che i risultati siano all’altezza delle aspettative: è facile commettere errori o gestire male le variabili. Si consiglia di creare una copertina Word da anteporre alle proprie trasmissioni.

Se è necessario un controllo migliore sulle copertine, si consiglia di scaricare e provare uno dei tanti client commerciali per HylaFAX.

Client web Esiste un approccio differente alla gestione dei fax. Invece di installare un componente binario su ogni client è possibile impiegare un semplice front-end web, raggiungibile da tutti i computer della rete con un normale browser. Non si deve eseguire alcuna installazione locale e non si devono compiere noiose configurazioni su ogni singola macchina. Esistono diversi prodotti; uno di più lineari da installare è Faxy, disponibile all’indirizzo http://sourceforge.net/projects/faxy. L’unico requisito del prodotto è avere un sistema Apache dotato di PHP, configurato nella macchina dove è presente HylaFAX. Non serve altro, neppure un supporto database, requisito tanto comune nelle applicazioni web di oggi. Si deve scaricare l’archivio di distribuzione, scompattarlo e poi copiare la directory faxy nella document root di Apache. All’interno di questa directory è presente un file denominato config.php, di piccole dimensioni. Bisogna verificare che i parametri siano corretti, come l’indirizzo assoluto del server, il nome della directory per Faxy, la directory dove HylaFAX conserva i fax in arrivo, l’area di spool di HylaFAX, il tempo di refresh della coda di arrivo e il riferimento al file di localizzazione di Faxy. Sono campi semplici da capire e da gestire: si tratta sostanzialmente di indicare alcuni percorsi relativi all’installazione di HylaFAX appena realizzata. Ultimate le configurazioni non resta che aprire il browser su qualunque macchina della rete e accedere a http://indirizzo/faxy (dove indirizzo è l’IP del computer dove è presente HylaFAX). Il front-end è semplice e intuitivo. Sulla sinistra compare un breve menu dove richiamare l’archivio fax, ottenere la lista dei fax arrivati, inviare un fax oppure gestire le cartelle fax. Se si sceglie di spedire un fax, viene visualizzata una pagina dove caricare il PDF da spedire e dove indicare il numero di telefono (Figura 14.10). Il PDF è l’unico formato disponibile, si devono quindi sempre salvare i documenti da spedire in questo formato.

Figura 14.10 Spedizione di un fax tramite il client w eb Faxy.

Checklist 1. Installare un modem/fax seriale esterno nel computer. 2. Controllare la presenza di HylaFAX nel sistema e presso i repository della propria distribuzione. Qualora sia assente si deve scaricare il pacchetto di distribuzione dal sito ufficiale del progetto all’indirizzo www.hylafax.org. 3. Verificare le dipendenze e installare i pacchetti necessari. 4. Nel caso metamail non sia supportato dalla propria distribuzione, procedere all’installazione di Hylafax ignorando le dipendenze. Gli altri pacchetti accessori come sharutils, libtiff, ghostscript e mgetty devono comunque essere presenti nel sistema. 5. Creare in /usr/share/ghostscript/fonts il link simbolico per i font di Ghostscript. 6. Lanciare il programma faxsetup e rispondere alle domande della procedura guidata di installazione. 7. Procedere alla configurazione del modem con il comando faxmodem. Questa procedura viene generalmente lanciata a conclusione della configurazione tramite faxsetup. La configurazione avviene attraverso una procedura guidata. 8. Se si hanno più modem collegati al computer, ripetere l’operazione di configurazione modem tramite faxmodem. 9. Aprire lo script di avvio del sistema e aggiungere in fondo il comando faxgetty con gli opportuni parametri. 10. Aggiungere allo script di avvio il comando faxmodem con gli opportuni parametri. 11. Se la propria distribuzione non supporta metamail, bisogna procedere alla modifica dello script FaxDispatch (presente in /var/spool/ hylafax/etc), creando nel contempo lo script uuencode_it (in /var/spool/hylafax/bin). 12. Applicare i diritti 777 al file uuencode_it. 13. Creare con il comando faxadduser gli utenti che useranno Hylafax. 14. Scaricare e installare il client fax per Windows. L’operazione potrebbe richiedere l’installazione di un driver PostScript (per esempio Apple LaserWriter 16/600 PS). 15. Configurare il client fax su Windows oppure usare un client web. 16. Se si desidera la stampa automatica dei fax in arrivo sul server, si deve modificare lo script faxrcvd in /var/spool/hylafax/bin. 17. Applicare le eventuali regole di chiamata nello script dialrules (presente in /var/spool/hylafax/etc) oppure nel file di configurazione del modem (var/spool/hylafax/etc/config.ttyS0) nel caso basti una configurazione più semplice. 18. Realizzare la copertina standard per le spedizioni.

Capitolo 15

Capitolo 15 - Server web con Apache Secondo le stime di Netcraft (www.netcraft.com) sono risultati attivi durante il mese di Agosto 2010 più di 213 milioni di siti web in tutto il mondo. Un numero notevole, lungi dall’essere definitivo. Basti pensare che soli quattro anni prima i siti attivi registrati da Netcraft erano circa 105 milioni. Questi valori dimostrano il successo del World Wide Web come mezzo di comunicazione di massa ed evidenziano la rivoluzione digitale oggi in atto. Più difficile è stimare con precisione il numero di pagine che compongono questi siti, ma certamente il valore si attesta sull’ordine dei miliardi. Una collezione immensa, scritta usando tutte le lingue del mondo e che nell’insieme formano un patrimonio inestimabile di notizie, informazioni, conoscenze, esperienze, opinioni ed emozioni dell’umanità. Una biblioteca libera costruita sulle fondamenta dell’universale linguaggio HTML e del protocollo di trasporto HTTP. Il protocollo HTTP definisce le regole con cui un client deve richiedere le pagine web a un server remoto e il modo con cui questo provvede a recapitare correttamente le informazioni al richiedente. Il server, costantemente connesso a Internet tramite un indirizzo IP fisso, dispone di una implementazione del protocollo HTTP e pubblica una o più pagine realizzate in HTML o generate in tempo reale con sistemi di scripting. Il software web server maggiormente utilizzato su Internet è Apache, della Apache Software Foundation (www.apache.org). Si tratta di una soluzione Open Source che ha incontrato negli anni favori crescenti, raggiungendo oggi un indice di gradimento intorno al 56%. Il secondo contendente raccoglie un gradimento del 25% circa, ed è Internet Information Server di Microsoft. Le posizioni seguenti, riportate in Tabella 15.1, rappresentano oggi soluzioni nuove emergenti, da tenere in osservazione. In particolare si deve prestare attenzione a Lighttpd (http://www.lighttpd.net), un software aperto e leggero utilizzato da nomi imponenti come YouTube e Wikipedia. Tabella 15.1

Sviluppatore Luglio 2010 Percentuale Agosto 2010 Percentuale Variazione Apache

112.945.968 54,90%

119.664.128

56,06%

1,16

Microsoft

53.217.620

25,87%

53.434.586

25,03%

-0,84

Google

15.849.853

7,70%

15.526.781

7,27%

-0.43

Nginx

11.474.696

5.58%

11.713.607

5.49%

-0.09

Lighttpd

1.258.800

0,61%

1.821.824

0,85%

0,24

Fonte: Netcraft (www.netcraft.com), Agosto 2010 Il gradimento dei server web è monitorato continuamente da Netcraft, che ogni mese pubblica i dati aggiornati all’indirizzo http://news.netcraft.com/archives/web_server_survey.html. Apache trae le sue origini dal programma httpd, sviluppato originariamente presso NCSA (lo stesso centro dove è stato sviluppato il primo browser grafico Mosaic). Il progetto è stato curato inizialmente da programmatori indipendenti, fino a quando si è optato per la creazione di una fondazione in grado di garantire

al progetto supporto logistico e continuità. La Fondazione Apache nasce nel 1999 puntando su un modello aperto e meritocratico, senza perseguire scopi di lucro. L’accesso è riservato alle persone che hanno dimostrato un ruolo attivo in uno dei progetti della Fondazione. Questa scelta garantisce qualità, chiarezza e contrasta fenomeni di frammentazione, di dispersione o di fork, tipici dei progetti Open Source poco coordinati o privi di un gruppo centrale affiatato. Il server web è rilasciato secondo la licenza Apache, i cui termini sono disponibili all’indirizzo http://www.apache.org/licenses/LICENSE-2.0. La licenza garantisce un uso libero senza costi e nessuna royalty da corrispondere.

Installazione Apache è uno degli applicativi Open Source di maggior successo ed è presente in tutte le distribuzioni Linux di utilizzo generale. Il prodotto è molto spesso installato di default, in quanto serve come supporto per una miriade di applicativi che offrono un’interfaccia utente in modalità web. Si ha perciò un sistema Apache già pronto per l’uso a seguito dell’installazione di Linux. È possibile che l’utente abbia optato per un’installazione Linux minimale, caratterizzata da pochi componenti server. In questo caso Apache potrebbe risultare assente e si deve procedere all’installazione tramite il meccanismo messo a disposizione dalla propria distribuzione. Per verificare se Apache è presente nel sistema si può impartire dalla linea di comando la seguente sequenza su CentOS: httpd -t

Su Ubuntu invece: apache2 -t

Il comando serve per verificare la correttezza della sintassi della configurazione di Apache, ma può essere anche usato per accertarsi che il server web sia presente nel sistema. Se il comando è dato come sconosciuto dalla shell di sistema, significa che Apache non è installato. Per verificare la presenza di Apache si può anche sfruttare il tool per l’installazione dei pacchetti previsto dalla propria distribuzione e appurare se il pacchetto httpd oppure apache2 (dipende dalla distribuzione) risulta presente. Nel caso di CentOS si può usare questa sintassi: rpm -qa | grep httpd rpm -qa stampa sullo schermo l’elenco completo dei pacchetti installati. Questo output viene passato al comando grep, che provvederà a visualizzare solo le righe contenenti la stringa httpd. Bisogna controllare la presenza dei seguenti pacchetti base:

httpd (pacchetto base) httpd-manual (documentazione) httpd-devel (materiale per lo sviluppo, facoltativo) Si deve anche controllare la presenza di un certo numero di moduli aggiuntivi di fondamentale importanza: mod_python (supporto per l’ambiente Python) mod_perl (supporto per il linguaggio Perl)

mod_ssl (supporto SSL per le transazioni web sicure) Su Ubuntu si usa invece il gestore dei pacchetti dpkg, con questa sintassi: dpkg -l apache*

Il comando -l elenca i pacchetti che hanno il nome compatibile con la stringa inserita sulla parte destra, in questo caso tutti i pacchetti il cui nome inizia con apache. L’asterisco (*) è il simbolo jolly. In output si avrà l’elenco dei pacchetti, con l’indicazione in prima colonna dello stato, per esempio se il pacchetto risulta installato o meno. Completata l’installazione si dovrebbe avere una server root, ovvero una directory contenente i file di configurazione (di solito /etc/httpd oppure /etc/apache2) e una document root, ovvero la directory che contiene le pagine web da pubblicare (generalmente /var/www/html oppure /var/www). Apache deve essere inserito tra i servizi da attivare nella fase di avvio del sistema. Ogni distribuzione mette a disposizione uno strumento specifico per la scelta dei servizi da attivare al momento dell’avvio del sistema. Le distribuzioni basate su Red Hat, per esempio, usano ntsysv. Per verificare che il processo di Apache sia in esecuzione si può usare il comando seguente: ps aux | grep httpd oppure, in Ubuntu: ps aux | grep apache2

Si potranno notare un certo numero di righe relative al server web. Apache utilizza infatti un processo principale che, a sua volta, richiama un certo numero di processi secondari. Questo permette di distribuire le richieste su più processi, evitando di accodare tutte le attività a un unico processo. È possibile avere una raffigurazione grafica dei processi in esecuzione tramite il comando pstree -p . Si potrà in questo modo evidenziare la presenza del processo principale e dei relativi figli: Listato 15.1

httpd(11901)httpd(11904) httpd(11905) httpd(11906) httpd(11907) httpd(11908) httpd(11909) httpd(11910) httpd(11911)

Opzioni per la configurazione generale Le distribuzioni Linux di utilizzo generale comprendono un’installazione di Apache in grado di funzionare fin dal primo avvio di sistema. Questo è possibile grazie a una configurazione generica del servizio web che permette di realizzare test, di far funzionare applicativi con interfaccia web e di pubblicare siti generici. Risulta particolarmente comodo poter utilizzare subito il servizio web, ma non si deve ingenuamente credere di poter mettere in produzione il server senza aver applicato alcuni criteri minimi di sicurezza. Per cominciare ci si deve occupare del file di configurazione principale di Apache, denominato, a seconda

delle distribuzioni, /etc/httpd/conf/httpd.conf oppure /etc/apache2/apache2.conf. Questo file è organizzato in tre sezioni distinte: global environment, main server configuration e virtual hosts. Queste possono essere presenti nello stesso file oppure segmentate in file differenti, collegati al file principale attraverso direttive di inclusione. La sezione global environment contiene opzioni che regolano il funzionamento generale del server Apache; main server configuration raggruppa opzioni che gestiscono il funzionamento del sito di default; virtual hosts regola il funzionamento dei siti virtuali. Le sezioni sono chiaramente distinte da stringhe di testo come la seguente: ### Section 2: 'Main' server configuration

L’attività di configurazione inizia generalmente con uno sguardo alla sezione 1, global environment, che contiene parametri che influenzano il comportamento generale del sistema. I principali parametri sono discussi qui di seguito, prendendo in considerazione una distribuzione CentOS. Su Ubuntu bisogna tenere conto della diversa posizione dei file nel sistema. Ogni volta che si mette mano alla configurazione di Apache è necessario riavviare il servizio. La strada più veloce consiste nel richiamare la sequenza /etc/init.d/httpd restart su CentOS oppure/etc/init.d/apache2 restart su Ubuntu. Prima è sempre bene verificare che la sintassi del file di configurazione sia corretta tramite il comando httpd –t su CentOS oppure apache2 -t su Ubuntu.

ServerTokens OS Quando un browser riceve risposta alle proprie interrogazioni da un server Apache, ottiene anche alcune informazioni supplementari come il nome del server web, la versione, il sistema operativo su cui sta girando, la distribuzione specifica, le estensioni installate e così via. Il livello di dettaglio delle informazione fornite dal server web è regolato dal qualificatore inserito a destra dell’opzione ServerTokens. I qualificatori e le risposte che ne derivano sono descritti nella Tabella 15.2. Tabella 15.2

Qualificatore Significato

Esempio di risposta ServerTokens

Prod

Nome server

Apache

Major

Versione maggiore di Apache

Apache/2

Minor

Versione maggiore e minore di Apache

Apache/2.0

Min

Output minimo

Apache/2.0.41

OS

Sistema operativo

Apache/2.0.41 (Unix)

Full

Output massimo

Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

Si consiglia di usare il qualificatore Min: meno informazioni vengono pubblicate e maggiore sarà la sicurezza della propria installazione.

ServerRoot “/etc/httpd” La radice del server è, per default, /etc/httpd oppure /etc/apache2. È possibile modificare questo percorso, se necessario, e farlo puntare a un’altra posizione del file system. Bisogna ricordarsi di non mettere mai la barra finale in questo parametro: sarebbe considerato un errore sintattico.

PidFile run/httpd.pid Il parametro indica il file dove sarà memorizzato il numero di identificazione del processo principale di Apache. Andando in /var/run e leggendo con un editor di testo il file httpd.pid si potrà vedere il numero del processo principale. Usando questo numero come opzione di pstree si potrà visualizzare l’albero dei processi di Apache, come è stato illustrato in precedenza.

Server-Pool Size Regulation (MPM specific) Questa non è propriamente un’opzione di Apache, bensì una istruzione secondaria che regola il numero di server Apache presenti nel sistema. Apache non gestisce infatti le richieste dei client tramite un unico processo monolitico, ma piuttosto attraverso un certo numero di processi che si “dividono” il carico di lavoro complessivo. Il meccanismo funziona attraverso un processo principale attivato in fase di avvio, il quale genera un certo numero di processi figli in base alle istruzioni presenti in questa sezione. Tale scelta garantisce maggiore efficienza, anche perché la gestione dei processi è demandata a un meccanismo che non è integrato in Apache, ma che è modulare. Si hanno cioè moduli di gestione dei processi differenti a seconda delle esigenze specifiche, per esempio situazioni di alto carico o ambienti basati su hardware particolari. Nelle installazioni base di Linux è possibile scegliere tra il modulo prefork MPM (attivo di default) o worker MPM ideato per installazioni a elevato carico. Apache su Windows utilizza invece un modulo di gestione dei processi denominato MPM winnt, specifico per la struttura del sistema operativo di Microsoft (nelle precedenti versioni non modularizzate di Apache si aveva un meccanismo unico per la gestione dei processi, indipendentemente dal sistema operativo, e questo comportava prestazioni peggiori). Ogni modulo dispone di parametri molto specifici. Nel caso di impiego del modulo prefork si avranno i parametri riportati di seguito. StartServers: il numero di processi che saranno attivati all’avvio del servizio Apache. MinSpareServers: il numero di processi in attesa che devono essere presenti in un dato istante. Se le

richieste esterne diventano intense, il numero di server in attesa diminuisce, in quanto molti dei processi di Apache saranno impegnati a gestire le richieste. Se il numero di server utilizzati per gestire richieste scende in un dato istante sotto MinSpareServers, vengono attivati nuovi server. MinSpareServers rappresenta una soglia di sicurezza, la quale impedisce che si possano esaurire le risorse in situazioni di picco. MaxSpareServer: regola il numero massimo di processi liberi presenti in un dato istante. Se il valore sale oltre questa soglia, i processi in eccesso vengono eliminati, per risparmiare risorse. È un meccanismo utile per ottimizzare il sistema dopo un picco ed evitare che siano impegnate risorse

inutilmente. MaxClients: il numero massimo di processi che possono essere creati per gestire le risorse. MaxRequestPerChild: numero massimo di richieste che un processo può elaborare nel corso della

propria esistenza. All’avvio del processo viene creato un contatore impostato a zero e a ogni richiesta esterna viene incrementato questo contatore. Raggiunto il valore impostato in questo parametro, il processo viene eliminato automaticamente. Questo a meno che non si inserisca lo 0 per indicare nessun limite. Si tratta di una funzionalità utile per eliminare i processi in eccesso accumulati in memoria dopo un picco.

Listen 80 La porta su cui il server si pone in ascolto, è di default la 80. È possibile anche inserire diverse occorrenze della direttiva Listen, indicando porte differenti, in modo che Apache ascolti tutte le porte specificate. Nel caso si abbiano più schede di rete, si può stabilire quale scheda ascoltare, indicando semplicemente l’indirizzo IP relativo: Listen 192.168.10.1:80 Listen 192.168.20.1:8080

In questo esempio Apache ascolta la porta 80 sulla scheda di rete a cui è stato assegnato l’indirizzo 192.168.10.1, mentre ascolta la porta 8080 sulla scheda con IP 192.168.20.1. Su Ubuntu questo parametro di configurazione si trova nel file /etc/apache2/ports.conf.

LoadModule Apache è in grado di caricare moduli binari allo scopo di incrementare le proprie funzionalità. Per farlo basta inserire una direttiva LoadModule seguita dal nome del modulo e dalla posizione del file relativo all’interno della directory module, per esempio: LoadModule cgi_module modules/mod_cgi.so

Di default viene caricato un certo numero di moduli. È comunque possibile eliminare i moduli ritenuti non pertinenti alle proprie necessità ottimizzando l’installazione. Su Ubuntu queste direttive si trovano in /etc/apache2/mods-enabled.

Include La configurazione di Apache non è contenuta completamente all’interno del file principale. È infatti possibile caricare ulteriori configurazioni da file esterni specificati dalla direttiva Include, per esempio Include conf.d/*.conf. In questo caso vengono caricati tutti i file di configurazione con estensione .conf presenti nella directory conf.d. Questa possibilità è molto utilizzata. Un buon esempio è rappresentato dal supporto PHP, regolato dal file di configurazione esterno php.conf e non attraverso il file di configurazione principale di Apache.

Il file php.conf provvede a caricare il modulo di gestione dei PHP e ad aggiungere il nuovo tipo di dato al sistema Apache. Ogni volta che il server incontrerà un file con estensione PHP attiverà così il relativo interprete.

Sito predefinito La seconda sezione del file di configurazione di Apache è estremamente importante, in quanto regola il funzionamento del sito web di default. Per sito di default si intende la collezione di pagine che si possono visualizzare semplicemente digitando l’indirizzo del server sul browser. Questo dettaglio può sembrare scontato, ma è bene fare questa precisione, in quanto una singola installazione di Apache è in grado di gestire un numero arbitrario di siti web. Oltre al sito di default si possono servire vari altri siti virtuali e un certo numero di siti utente. Tali caratteristiche saranno esaminate più avanti in questo stesso capitolo. Prima di arrivare a tutto questo è importante capire bene il funzionamento di alcune direttive presenti nella seconda sezione del file di configurazione di Apache. L’analisi si limiterà alle direttive più rilevanti, in quanto una trattazione esaustiva richiederebbe un volume dedicato, vista la quantità e la complessità delle opzioni disponibili. Occorre innanzitutto verificare le direttive User e Group, che indicano l’utente e il gruppo utilizzati dal servizio web per funzionare all’interno del sistema. Durante l’installazione del pacchetto vengono creati un utente Apache e un gruppo Apache dotati di diritti limitati di accesso e dei quali bisogna accertare che siano impostati sulla configurazione. In molte installazioni si compie la scelta sbagliata di inserire l’utente root. Questo è estremamente pericoloso, perché in caso di violazione del servizio web si ha la facoltà di attaccare il sistema con il ruolo dei superuser. Questa è un’evenienza sempre reale, perché Apache, come ogni prodotto software, può contenere bug di programmazione che possono essere scoperti e usati per compiere attacchi. Il processo di rilascio delle patch è estremamente veloce, ma nel frattempo si è potenzialmente vulnerabili. Subito dopo la verifica dei diritti utente bisogna controllare il parametro ServerAdmin e verificare che contenga l’indirizzo di posta elettronica dell’amministratore. A questa casella saranno infatti inoltrati tutti i messaggi generati dal servizio web. È molto importante anche la direttiva ServerName. Molto spesso all’avvio di Apache si ha il messaggio di avviso “Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName”. Questo avviene perché non è stato specificato il nome del server nella configurazione di Apache. La direttiva ServerName deve infatti contenere il nome valido del sito web (per esempio www.sistemisicuri.com). Questo nome deve cioè essere risolvibile attraverso il DNS. Se non è possibile ottenere la risoluzione del nome tramite DNS si può sempre usare l’indirizzo IP della macchina che ospita Apache. Se non si immette alcuna informazione viene usato di default l’indirizzo di loopback 127.0.0.1, ma, in tal caso, a ogni avvio apparirà il messaggio appena citato. Il parametro ServerName è direttamente collegato a UseCanonicalName. Questa direttiva imposta un flag che può contenere On oppure Off e specifica il modo in cui sono costruiti gli indirizzi che si riferiscono al proprio sito. Se è impostato a On, gli indirizzi vengono costruiti usando la stringa specificata in ServerName. A questa saranno accodati i percorsi digitati dall’utente (per esempio www.sistemisicuri.com/analisi/rap2010.html). Se il parametro è impostato a Off verranno usati letteralmente l’indirizzo e la porta scritti dall’utente sul browser durante la richiesta. Il parametro DocumentRoot specifica invece la posizione sul file system dove sono contenuti i file relativi ai siti. Di default è /var/www/html su Centos e /var/www su Ubuntu. Il sito predefinito può essere salvato dentro questa directory. Nel caso non sia presente, viene visualizzata

una pagina di test di Apache (Figura 15.1). Il nome del file principale è stabilito dalla direttiva DirectoryIndex, impostata di default su index.html.

Figura 15.1 Sito predefinito di Apache su CentOS.

Protezione delle directory Il contenuto delle directory presenti dentro la document root può essere visualizzato dagli utenti esterni semplicemente digitando l’indirizzo sul browser. Apache supporta però modalità di accesso più evolute, impostabili nel blocco che inizia con : Listato 15.2

direttiva-1 opzione direttiva-2 opzione direttiva-n opzione

Il blocco viene aperto con l’indicazione del percorso che sarà interessato dalle specifiche elencate all’interno del blocco stesso. Seguono le direttive, una su ogni riga e alla fine il blocco viene chiuso con .

Una delle direttive più utili è Options e specifica quali operazioni sono permesse nella directory in oggetto. Questo è un elenco delle opzioni possibili per questa direttiva. ExecCGI. L’esecuzione degli script CGI è permessa tramite il modulo mod_cgi. FollowSymLinks. Apache segue i link simbolici presenti nella directory e mostra i file puntati anche se

questi non si trovano nella document root. Includes. Permette l’esecuzione dei server side includes. IncludesNOEXEC. I server side includes sono ammessi a esclusione dei comandi #exec cmd e #exec cgi. Indexes. Nel caso in cui non sia presente il file HTML predefinito all’interno della directory verrà mostrato l’elenco dei file presenti. In sostanza, se non c’è un file HTML da interpretare e visualizzare, sarà eseguito il listing della directory. L’utente vedrà così l’elenco dei file e delle directory presenti. MultiViews. Apache è in grado di gestire il meccanismo di content negotiation, attraverso il quale può selezionare i contenuti da mostrare in base alle richieste specifiche del browser. Il browser potrebbe per esempio comunicare al server web la preferenza per la lingua italiana e Apache potrebbe in tal caso selezionare i contenuti da visualizzare in base a questa richiesta, nel caso fossero presenti più lingue dentro la stessa directory. Una valida pagina informativa su questa opzione è presente all’indirizzo http://httpd.apache.org/docs/content-negotiation.html. SymLinksIfOwnerMatch. Il server segue i link simbolici della directory solo nel caso in cui il file o la directory puntata appartengano allo stesso utente del link simbolico. All. Opzione di default che permette tutte le funzionalità tranne Multiview e None. None. Nessuna funzionalità evoluta è permessa all’interno della directory in oggetto. La risorsa selezionata dal browser sarà semplicemente visualizzata. Un’altra direttiva utilizzabile in un blocco è AllowOverride, che permette di trasferire parte della configurazione delle directory al di fuori del file di configurazione principale di Apache. Questo risulta molto comodo quando si rivende spazio web ai propri clienti, ma non si desidera che questi possano accedere alla configurazione generale del server web. Basta che il cliente inserisca un file .htaccess dentro il proprio spazio e specifichi le direttive al suo interno. Queste avranno peso rispetto al file di configurazione principale di Apache. La direttiva AllowOverride deve essere seguita da un’opzione. Indicando l’opzione None si istruisce Apache a ignorare il file .htaccess. Viceversa indicando All si segnala che tutte le direttive presenti in .htaccess avranno una maggiore priorità rispetto alla configurazione di Apache. Se si desidera invece implementare una configurazione granulare, si dovranno indicare quali direttive presenti nel file .htaccess avranno priorità rispetto al file di configurazione principale di Apache. Per un dettaglio maggiore di queste opzioni si può consultare la pagina http://httpd.apache.org/docs2.0/mod/core.html#allowoverride. Il nome di file .htaccess è predefinito, ma può essere cambiato in favore di qualunque nome l’amministratore decida di usare. Basta specificare una stringa differente all’interno della direttiva AccessFileName. All’interno del blocco si può implementare anche una politica di accesso alla directory. Questo aspetto di Apache è gestito in maniera molto simile a quella di un firewall. Si utilizzano i comandi allow (permetti) o deny (impedisci) per regolare l’accesso discriminando l’host di provenienza, l’indirizzo IP completo, parte di un indirizzo oppure una sottorete. È anche possibile specificare chiunque (all). Prima di utilizzare queste regole bisogna però specificare la priorità di valutazione. In sostanza si deve specificare se Apache dovrà prima verificare le regole allow o deny. Questo aspetto si realizza tramite la

direttiva Order. Le modalità possibili sono due: Order allow,deny oppure Order deny,allow. Un esempio sarà utile per chiarire il concetto: Order allow,deny Allow from all

Nella prima riga si indica che verranno valutate prima le regole allow e poi quelle deny. La riga introduce però anche un effetto collaterale: nel caso di allow,deny si ottiene il blocco di accesso alla directory a tutti gli utenti, mentre nel caso di deny,allow si ottiene invece l’accesso alla directory a tutti. Dal momento che la prima riga dell’esempio precedente vieta l’accesso a chiunque, è necessario introdurre la seconda riga che esplicita il permesso di accesso a chiunque. Il fatto che Apache possa valutare prima le regole di allow e poi quelle di deny (e viceversa) può creare qualche problema se non si presta attenzione alla stesura delle regole. Per rendersene conto può essere utile esaminare un esempio presente nella documentazione tecnica di Apache: Order allow,deny Allow from apache.org Deny from foo.apache.org

Stando alla prima riga vengono valutate per prime le regole allow e poi quelle deny. La regola chiude anche implicitamente l’accesso a chiunque. Le due righe successive fanno in modo che l’accesso alla directory sia permessa ai visitatori provenienti da apache.org e che l’accesso sia interdetto da coloro che provengono da foo.apache.org. Viene infatti interpretata per prima la riga Allow e poi quella Deny. Tutto risulta molto chiaro. A questo punto è interessante valutare cosa succederebbe se venisse invertito l’ordine di valutazione da allow,deny a deny,allow: Order deny,allow Allow from apache.org Deny from foo.apache.org

In questo modo viene valutata per prima la terza riga, che impedisce l’accesso da foo.apache.org. Questa regola viene però subito invalidata da Allow from apache.org (seconda riga) che apre l’accesso a tutti gli utenti del dominio apache.org. È ora chiaro come una semplice modifica all’ordine di valutazione delle regole possa modificare in maniera radicale i diritti di accesso. Quando si esaminano configurazioni complesse, bisogna anche tenere in considerazione il fatto che i blocchi vengno valutati in maniera sequenziale e che le direttive dei blocchi successivi possono invalidare le direttive dei blocchi precedenti, come in questo esempio tratto dal file di configurazione generale di Apache: Listato 15.3

Options FollowSymLinks AllowOverride None

Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all

Nel primo blocco vengono specificate delle direttive che si applicano a tutte le directory (percorso /). Nel secondo blocco si esplicitano invece le caratteristiche di una singola directory, in questo caso /var/www/html, che fa comunque parte di /.

Alias e redirect Le directory possono contenere alias. Se si ha un percorso molto lungo per una pagina o per una directory, per esempio http://www.incipit.biz/progetti/bozze/2009/schemi/pdf, si può creare un alias più corto, per esempio /pdf. In questo caso l’utente potrà accedere ai file della directory digitando il percorso abbreviato http://www.incipit.biz/pdf. Per realizzare la scorciatoia si utilizza la direttiva Alias: Alias /pdf "/var/www/html/incipit.biz/progetti/bozze/2009/schemi/pdf"

Bisogna stare attenti al fatto che, se si chiude un alias con la barra (slash), allora anche il percorso completo presente sulla destra deve finire in slash. Si può naturalmente disporre di un numero arbitrario di direttive Alias, elencate una di seguito all’altra. Un’operazione di manipolazione sugli indirizzi simile agli alias è il cosiddetto redirezionamento (Redirect), che si effettua quando si è spostato parte del proprio sito in un nuovo indirizzo e si vuole fare in modo che gli utenti possano essere inoltrati automaticamente al nuovo indirizzo. Se, per esempio, i progetti pdf del 2009 sono stati spostati da http://www.incipit.biz/progetti/bozze/2009/schemi/pdf a http://www.sistemisicuri.com/pdf, si può costruire la seguente regola: Redirect permanent /progetti/bozze/2009/schemi/pdf http://www. sistemisicuri.com/pdf

Se l’utente ha specificato sul browser un nome file in fondo al percorso, questo sarà aggiunto automaticamente all’indirizzo in redirect. Le direttive Alias e Redirect possono essere combinate, ma Redirect ha la priorità su Alias.

Protezione dei file Apache prevede un blocco simile a , concepito per applicare criteri di protezione a livello dei file. Il blocco è indicato con . I blocchi vengono letti dopo e possono riguardare un singolo file, specificato direttamente tramite il nome, o gruppi di file, specificati con il carattere jolly * (per esempio, per indicare tutti i file JPG si usa la dicitura *.jpg): Listato 15.4

Order allow,deny Deny from all

In questo esempio, nessun utente può avere accesso ai file con estensione JPG. È supportato anche il carattere jolly sulla singola posizione, tramite il simbolo di punto interrogativo (?). Si possono in questo modo indicare, per esempio, tutti i file che hanno un nome di sei caratteri che iniziano con par, finiscono per 05 e che hanno il quarto carattere variabile (par?05). I blocchi possono essere scritti all’interno dei blocchi per fare in modo che la limitazione sui file sia relativa alla sola porzione di file system specificata dal blocco .

Log di Apache Le attività di Apache vengono registrate in alcuni file di log memorizzati nella directory /var/log/httpd su CentOS oppure /var/log/apache2 su Ubuntu. Il file certamente più interessante è access_log. Al suo interno sono registrati i singoli accessi eseguiti dagli utenti esterni sul server Apache. Si possono così vedere tutte le risorse richieste, gli indirizzi IP dei relativi utenti, la data e l’ora dell’accesso. Da questo file di registrazione si possono trarre varie informazioni sul gradimento del proprio sito e molti sistemi di statistiche leggono proprio questo log per generare grafici sull’andamento. Un altro file importante è error_log, in quanto raccoglie tutti gli errori generati dal server web e le richieste che gli utenti hanno inoltrato nei confronti di pagine inesistenti o risorse protette. È sicuramente il punto di partenza per avere un’idea sui possibili tentativi di abuso verso il proprio sistema o sugli errori nei file HTML. Esiste un file di log per gli accessi e per gli errori anche per le transazioni in SSL. In tal caso i nomi dei file sono preceduti dal prefisso ssl. I nomi dei file di log non sono rigidi, ma modificabili dal file di configurazione di Apache. Il nome del file degli errori è controllato dal parametro ErrorLog e il dettaglio delle informazioni viene regolato dalla direttiva LogLevel. Il file di log degli accessi è regolato invece dalla direttiva CustomLog. Questo file raccoglie un ampio ventaglio di informazioni, ma se lo si desidera è possibile scorporare i gruppi di informazioni e avere file di log separati per gli accessi, i riferimenti e gli agenti, usando le specifiche common, referer e agent. Un esempio di configurazione per generare un file di log chiamato access_log dotato di tutte le informazioni è il seguente: CustomLog logs/access_log combined

Di seguito viene invece riportato un esempio di configurazione per la generazione di file di log separati: CustomLog logs/access_log common CustomLog logs/referer_log referer CustomLog logs/agent_log agent

Nei file di log vengono registrati gli accessi esterni attraverso l’indirizzo IP. Eventualmente è possibile avere la risoluzione dell’IP e ottenere in questo modo un nome esteso. Basta impostare a On la direttiva HostnameLookups.

Siti utente Linux è un sistema multiutente. Ogni utente del server è dotato di credenziali univoche che permettono un

accesso regolamentato al sistema e l’accesso a un certo numero di risorse, tra cui una directory utente. Tutte le directory utente sono memorizzate all’interno di /home e all’atto della creazione di un utente (per esempio con il comando useradd) viene generata la relativa cartella e vengono creati alcuni file di configurazione di base, per esempio il profilo della shell dei comandi. È possibile fare in modo che ogni utente possa crearsi anche un proprio sito web all’interno della propria home e che Apache ne pubblichi automaticamente il contenuto. Per accedere alle singole home page degli utenti sarà sufficiente digitare l’indirizzo http://www.incipit.biz/~nomeutente. Apache riconoscerà il tentativo di accesso alla home page utente e aprirà il file index.html presente in /home/nomeutente/public_html. Il nome Public_html è stabilito dalla direttiva UserDir: UserDir public_html

Ogni cartella utente dovrà in questo caso includere una directory public_html, al cui interno saranno memorizzate le pagine web. La pagina di accesso principale è index.html. Prima di far funzionare i siti utente bisogna verificare i diritti di accesso alle directory. Le singole cartelle utente dentro /home dovranno possedere diritti 711, come pure le directory public_html presenti nelle home degli utenti. I file del sito personale dovranno invece avere diritti 744. Questo è necessario per permette all’utente Apache di percorrere il file system all’interno delle cartelle utente e leggere i file. Se lo si desidera, è possibile inserire nel file di configurazione di Apache il blocco , per regolare in maniera più fine i criteri di accesso da parte degli utenti. La configurazione di Apache contiene un buon esempio di criterio per i diritti di accesso: Listato 15.5

AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

Order allow,deny Allow from all

Order deny,allow Deny from all

La direttiva si applica a tutti i siti utente e svolge alcune importanti funzioni di sicurezza. Va notata la direttiva Options, in cui compare l’opzione Indexes SymLinksIfOwnerMatch. Questa istruzione impedisce che possa essere visualizzato un link simbolico verso file presenti all’esterno della directory web e non appartenente all’utente in questione. La direttiva Limit presente all’interno del blocco serve per limitare l’accesso secondo i metodi elencati. Nell’esempio si intende limitare i metodi GET, POST e OPTIONS con le restrizioni indicate nelle righe sottostanti. Gli altri metodi non elencati saranno interdetti. Gli utenti generici possono così accedere unicamente in lettura e non possono inviare file con il metodo PUT oppure cancellarli con il metodo DELETE. La direttiva LimitExcept serve per esplicitare maggiormente i criteri di sicurezza e funziona in maniera contraria a Limit. La direttiva impone il criterio di sicurezza inserito al suo interno a tutti i metodi tranne quelli indicati. Nell’esempio si indica il divieto a tutti di usare i metodi al di fuori di GET, POST e OPTIONS.

Un altro esempio interessante di direttiva Limit è presente nella documentazione ufficiale di Apache:

Require valid-user

In questo caso si permette l’invio e la cancellazione di materiale ai soli utenti validati. I meccanismi di validazione saranno esaminati più avanti in questo capitolo. Durante la compilazione della direttiva Limit si deve ricordare di scrivere i metodi in maiuscolo. Per disabilitare la funzionalità dei siti utente si può utilizzare la sintassi: UserDir DISABLED

Eventualmente è possibile impedire l’uso della directory web a utenti ben precisi: UserDir DISABLE root

In questo caso l’utente root non avrà la possibilità di pubblicare un sito personale. Si tratta di una buona misura di sicurezza. Per quanto riguarda la sicurezza, non va dimenticato che la funzione di directory utente può essere usata da un eventuale utente malintenzionato per capire se un determinato utente è presente nel sistema. Basta fare qualche innocua prova di accesso al Web. Una volta trovata la pagina si ottiene infatti anche la user id di accesso: basta leggere il percorso ed estrarre la id dalla parte finale (per esempio se la directory di Paolo Rossi è www.incipit.biz/~prossi allora è probabile che la sua user id su Linux sia prossi). A questo punto il malintenzionato potrebbe collegarsi in shell remota e tentare password che hanno attinenza con l’utente, allo scopo di ottenere l’accesso al sistema. La tecnica può andare certamente in porto nel caso di utenti poco accorti in fatto di sicurezza.

Siti virtuali Apache è in grado di gestire un numero arbitrario di siti e questa funzionalità è utile quando si intende servire più domini con un’unica installazione del server. Il meccanismo è del tutto trasparente: l’utente digita sul browser l’indirizzo del sito che vuole visualizzare, Apache riconosce il dominio digitato e in base alle regole di configurazione visualizza il sito di pertinenza tra tutti i siti presenti nel server. Per cominciare si deve creare all’interno della document root una directory per ogni sito che si vuole gestire, come in questo esempio su CentOS: Listato 15.6

mkdir mkdir mkdir mkdir

/var/www/html/sito_cliente1 /var/www/html/sito_cliente2 /var/www/html/sito_cliente3 /var/www/html/sito_cliente4

All’interno delle directory si carica il materiale relativo ai singoli clienti. Poi si apre il file di configurazione di Apache posizionandosi nella terza sezione (Virtual Hosts) e si specifica la configurazione per il primo sito virtuale:

Listato 15.7

ServerName dominio_cliente1.com DocumentRoot /var/www/html/sito_cliente1 ServerAdmin [email protected] ErrorLog logs/cliente1_error_log CustomLog logs/cliente1_access_log common

Nella prima riga, subito a destra di VirtualHost, bisogna indicare su quale indirizzo e su quale porta si vuole ascoltare. In questo caso si stanno ascoltando tutti gli indirizzi sulla porta 80. Questa specifica è utile perché un singolo server potrebbe avere diversi IP statici ed è possibile fare in modo che le attività Web siano ammesse solo su alcuni di questi indirizzi. ServerName è il dominio DNS del cliente senza l’indicazione www. Se si sta cioè gestendo il sito www.dominio_cliente1.com si deve indicare dominio_cliente1.com. Subito sotto si deve segnalare la directory che contiene il sito per cliente1 tramite la direttiva DocumentRoot. ServerAdmin contiene l’indirizzo dell’amministratore di sistema. A questa casella saranno inoltrati i messaggi di errore per questo sito. Le due direttive seguenti indicano dove si vogliono generare i file di log per gli errori e gli accessi. Dentro il blocco è possibile specificare i criteri di accesso per le directory del sito virtuale in oggetto. Conclusa l’operazione si procede realizzando la configurazione per gli altri siti virtuali. Su Ubuntu la configurazione dei siti virtuali è specificata nella directory /etc/apache2/sites-enabled su singoli file, uno per ogni dominio. Sul file di configurazione principale è infatti presente una direttiva di inclusione: Include /etc/apache2/sites-enabled/

Autenticazione Apache dispone di un meccanismo per la validazione di utenti. È possibile cioè fare in modo che alcune directory del file system o specifici file siano accessibili solo dopo aver fornito una user id e una password. Quando si desidera accedere a una zona protetta, verranno in questo modo chieste le credenziali. C’è però un problema: ogni singolo file richiesto da questa zona dovrebbe essere validato singolarmente mediante user id e password e questo è evidentemente molto scomodo. Fortunatamente esiste la possibilità di specificare le credenziali solo la prima volta, con un metodo che verrà descritto più avanti. Attenzione però alle funzionalità di autoriempimento dei moduli (e delle password!) presenti nei browser. Questa caratteristica poco orientata alla sicurezza può invalidare il meccanismo di richiesta delle credenziali di Apache. Un estraneo potrebbe accedere fisicamente al computer di utenti poco attenti alla sicurezza e avere così libero ingresso a tutte le aree web riservate. Bisogna poi tenere presente che tutte le transazioni tra client e server avvengono in chiaro e un utente malintenzionato posto tra sorgente e destinazione potrebbe carpire le password e usarle. Meglio quindi non generare credenziali web uguali a quelle usate per accedere alla shell, scongiurando così l’eventualità che una password web rubata diventi un passepartout per una miriade di accessi critici. Per creare i profili di Apache si usa il comando htpasswd, con la sintassi seguente: htpasswd nomefilepassword è il file che contiene l’elenco degli utenti e delle password. Questo file deve essere

creato la prima volta con il parametro -c: htpasswd -c

Il file viene generato di default all’interno di /root, ma questo non va bene, in quanto Apache non ha diritto di accesso a tale directory. Bisogna sempre specificare il percorso completo dentro una directory di Apache, per esempio /etc/httpd/conf/pass su CentOS: htpasswd -c /etc/httpd/conf/pass szanzi

Premendo Invio verrà chiesta la password per szanzi due volte e all’interno del percorso specificato verrà generato il file pass. Il file pass creato è un normale file di testo con all’interno una serie di righe con i nomi degli utenti e le relative password cifrate. Attenzione a non usare nuovamente il parametro -c quando si creano gli utenti successivi. Si cancellerebbe ogni volta il file delle credenziali, a favore di un nuovo file di accessi vergine con solo l’ultimo account creato. In ogni momento è possibile cambiare la password di un utente esistente con la stessa sintassi: htpasswd

Ora è possibile creare un blocco o modificarne uno già esistente, inserendo le seguenti righe: Listato 15.8

AuthType Basic AuthName "Riservato" AuthUserFile /etc/httpd/conf/pass Require valid-user

La direttiva AuthType Basic indica che le password sono veicolate in chiaro. In alternativa è possibile utilizzare Digest nel caso si usi il modulo mod_auth_digest. In questo modo le password sono veicolate in maniera cifrata, ma non tutti i browser supportano la funzionalità e si rischia di perdere in compatibilità. La direttiva AuthName è seguita da una stringa di testo libero, che costituisce il dominio di autenticazione. Al primo accesso saranno richieste le credenziali, che non dovranno essere più richieste per tutte le directory contrassegnate dallo stesso dominio Riservato. Si possono avere in questo modo più aree protette che condividono le stesse credenziali. La direttiva AuthUserFile contiene il percorso del file di password. L’ultima direttiva segnala che solo gli utenti indicati nel file delle password possono avere accesso. In alternativa è possibile riservare l’accesso a una singola persona, tramite la sintassi seguente: Listato 15.9

AuthType Basic AuthName "Riservato" AuthUserFile /etc/httpd/conf/pass Require user szanzi

Si può concedere l’accesso anche a gruppi di utenti. In tal caso si deve creare un file di testo con la sintassi seguente:

nomegruppo: utente1 utente2 utente3

per esempio: tecnici: szanzi arossi bverdi cbianchi

Il file va salvato in un luogo del file system accessibile da Apache, in genere lo stesso punto dove sono presenti i file delle password. Le direttive di autenticazione per il gruppo tecnici devono essere scritte nel modo seguente: Listato 15.10

AuthType Basic AuthName "Riservato" AuthUserFile /etc/httpd/conf/pass AuthGroupFile /etc/httpd/conf/gruppi Require group tecnici

Così solo gli utenti del gruppo tecnici potranno accedere alla directory in oggetto.

Listing delle directory Un aspetto che viene spesso ignorato nei siti web realizzati con Apache è il listing delle directory. Quando si accede a un sito, viene visualizzata la pagina di default index.html e tutto il contenuto multimediale relativo. Che cosa succede però se si compone un indirizzo web con riferimenti a directory che non contengono pagine HTML? Apache in questi casi esegue il listing, ovvero mostra l’elenco dei file presenti. Questa non è una buona pratica, perché permette a un utente malintenzionato di esaminare il contenuto delle directory presenti nel sistema e navigare nel file system. Bisogna ricordarsi di cancellare l’opzione Indexes da tutte le direttive Options dei blocchi , sia per quanto riguarda la radice sia per le directory specifiche, come nell’esempio seguente: Listato 15.11

Options FollowSymLinks AllowOverride None

Questa configurazione, da evitare, permette invece il listing della root: Listato 15.12

Options FollowSymLinks Indexes AllowOverride None

Se si usano i file .htaccess bisogna impedire che si possa inserire al suo interno l’opzione Indexes. In questo modo a ogni tentativo di listing dovrebbe apparire un messaggio d’errore.

In aggiunta a questa misura di sicurezza è bene verificare che sia presente la seguente direttiva: IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

Questa impedisce che in caso di listing siano visualizzati i tipi di file elencati. In questo caso non saranno mostrati i file che hanno estensione di almeno due caratteri, i file che finiscono con la tilde, quelli che finiscono con il carattere # (cancelletto), i file che iniziano con HEADER e README e altri file che hanno scopi particolari o critici all’interno del sistema. Esistono molte altre misure che si possono prendere in considerazione per rendere il sistema più sicuro. È consigliabile, a tal proposito, leggere la documentazione ufficiale di Apache 2.0 all’indirizzo http://httpd.apache.org/docs-2.0/ oppure consultare l’indice delle direttive all’indirizzo http://httpd.apache.org/docs-2.0/mod/directives.html. Un valido testo specifico può inoltre essere molto utile per padroneggiare alcuni aspetti avanzati di Apache.

Checklist 1. Verificare la presenza del pacchetto Apache digitando httpd -t oppure apache2 –t. Se il comando risulta sconosciuto, Apache probabilmente non è presente e bisogna procedere all’installazione dai dischi della propria distribuzione. 2. Prima di installare Apache bisogna verificare le dipendenze e fare in modo che i pacchetti mod_python, mod_perl e mod_ssl siano presenti. 3. Aprire il file di configurazione principale e verificare la configurazione generale. 4. Andare nella document root (generalmente /var/www/html o /var/www) e creare il sito principale. La pagina di partenza è index.html. 5. Applicare un livello minimo di protezione dei contenuti attraverso i blocchi e . 6. Verificare la configurazione dei log e la loro presenza dentro /var/log/httpd o /var/log/apache2. 7. Attivare se necessario le funzioni multiutente. Informare in tal caso gli utenti circa il nome di default per la directory web personale. Gli utenti dovranno creare tale directory e applicare i diritti corretti. 8. Attivare se necessario i siti virtuali. In tal caso bisogna inserire le pagine HTML all’interno delle directory specificate nella configurazione dei siti virtuali. 9. Attivare, se necessario, i meccanismi di validazione per le directory da proteggere. 10. Alla fine del processo di configurazione, riavviare il servizio tramite il comando /etc/init.d/httpd restart oppure /etc/init.d/apache2 restart. 11. Verificare che il servizio parta automaticamente all’avvio del sistema

Capitolo 16

Capitolo 16 - Monitorare la rete con tcpdump, IPTraf e MRTG Quando si ha a che fare con una rete locale sorge prima o poi l’esigenza di verificare che cosa stia effettivamente succedendo “dentro” i cavi. Potrebbe essere necessario risolvere un problema, per esempio capire il motivo della lentezza su certi nodi o scoprire perché la connessione cada sistematicamente su certe tratte. Possono però anche esserci motivazioni meno urgenti, come il desiderio di ottimizzare le comunicazioni o semplicemente di capire quale genere di traffico si ha in punti particolari della rete. Tutte queste attività possono essere portate a termine con un analizzatore di rete. Si tratta tipicamente di uno strumento hardware da collegare con un normale cavo Ethernet alla rete locale usando una porta dello switch aziendale. Il dispositivo si pone passivamente in ascolto e registra quanto viene veicolato sulla rete locale. L’amministratore ottiene tutte le informazioni di cui ha bisogno esaminando l’output sul display LCD del dispositivo. Alcuni strumenti più sofisticati sono dotati di un server web interno a cui ci si può connettere con un browser per configurare l’analizzatore e ottenere tutte le informazioni che servono in un formato grafico e intuitivo. Questo tipo di apparecchi è particolarmente utilizzato dal personale che svolge attività di verifica di rete locali, in quanto sono comodi, maneggevoli, piccoli, non richiedono l’installazione di componenti software e non interferiscono con i programmi installati sui sistemi collegati alla rete. Si tratta, cioè, di una forma di analisi non invasiva, ovvero che non altera l’ambiente che si vuole studiare. Questi apparecchi hanno però lo svantaggio di essere molto costosi e risultano così giustificabili solo in grandi organizzazioni o in aziende che operano nel settore dell’assistenza alle reti. Esistono anche altri approcci, altrettanto validi, nell’analisi della rete: si può installare un componente centrale sul server e una serie di agenti sui punti che si vogliono monitorare. Gli agenti analizzeranno la tratta di rete locale di loro competenza, raccoglieranno le informazioni e le spediranno al server che aggregherà i dati in una serie di quadri riassuntivi facilmente leggibili. Ancora una volta però ci si imbatte in alti costi, che non possono essere affrontati in realtà composte da un numero limitato di postazioni. Per risolvere questo problema e disporre comunque di una soluzione di qualità si può fare uso di uno degli strumenti più utili presenti nella totalità delle distribuzioni Linux. Si tratta di tcpdump (www.tcpdump.org).

Tcpdump in azione Il pacchetto è generalmente presente nell’installazione di Linux. Per verificare la sua presenza basta digitare tcpdump e premere Invio. Nel caso fosse assente si deve procedere all’installazione tramite gli strumenti

standard di installazione previsti dalla propria distribuzione. Tutta l’interazione con tcpdump avviene tramite un’interfaccia a riga di comando. Le opzioni sono specificate usando la tastiera e l’output relativo è generato sul terminale. Nella sua forma più semplice, il programma può essere attivato senza alcuna opzione. In tal caso basteranno pochi secondi per ottenere le prime informazioni (Figura 16.1).

Figura 16.1 Output di tcpdump.

Ogni riga visualizzata rappresenta un pacchetto di dati rilevato in rete, per esempio: 16:07:06.167932 192.168.100.11.2953 > www.incipit.biz.www: . ack 44582 win 64240 (DF)

Il primo campo indica l’ora in cui il pacchetto è stato rilevato, prendendo in considerazione l’orologio locale del computer su cui il monitor sta girando. Il secondo campo contiene invece l’indirizzo del sistema che ha eseguito la comunicazione. Si avrà un indirizzo IP numerico o il nome risolto nel caso questo sia presente nel DNS o nel file hosts locale. Nel caso in oggetto, la comunicazione proviene dal sistema locale 192.168.100.11, porta 2953 ed è indirizzato a www.incipit.biz, porta www (ovvero 80). Si tratta quindi di una comunicazione instaurata da un browser locale verso il sito web www.incipit.biz. Tra l’indicazione del sito che ha originato la richiesta e quello a cui è destinata la trasmissione, è presente un segno di maggiore >. Si tratta del verso della comunicazione. In questo caso parte da 192.168.100.11 ed è indirizzata a www.incipit.biz. Il segno potrebbe essere opposto, < per indicare il verso contrario della comunicazione, da incipit.biz al nodo locale. Dopo queste informazioni di base sono presenti alcune indicazioni più tecniche che riguardano i flag relativi al protocollo di comunicazione che è stato catturato. In questo caso, dopo l’indicazione www.incipit.biz.www si può rilevare il valore ack che il nodo di origine si aspetta per la comunicazione (44582), una sorta di valore progressivo controllato dal sistema per evitare che pacchetti di informazioni possano perdersi. win rappresenta invece la finestra di ricezione, ovvero la grandezza del buffer allocato per la ricezione dei dati: in questo caso è di 64.240 byte. Nella comunicazione registrata è possibile notare che subito dopo l’indirizzo e prima del valore di ack è presente un punto. Questo significa che non è stata rilevata alcuna opzione relativa al pacchetto TCP. In tale posizione potrebbe infatti apparire S (SYN), F (FIN), P (PUSH), R (RST) o un punto, per indicare l’assenza di questi flag. Per apprezzare appieno l’output di tcpdump bisogna avere un buon grado di conoscenza dei protocolli che vengono monitorati. In questo caso particolare, si tratta del protocollo TCP, specificato nel RFC 793

(http://www.faqs.org/rfcs/rfc793.html). Spesso non è necessario approfondire le conoscenze dei protocolli in maniera così minuziosa, perché nella maggior parte dei casi basta sapere che cosa sta avvenendo a grandi linee per risolvere problemi di comunicazioni o capire come vengono utilizzate le risorse di rete. In questi casi è sufficiente verificare gli indirizzi sorgente e destinazione, le relative porte usate e la direzione della trasmissione.

Analisi nel tempo Per fare una buona analisi non ci si può limitare a una singola riga dell’output di tcpdump. Questa rappresenta infatti solo un’istantanea di un momento preciso e fornisce poche informazioni su quanto sta avvenendo nel complesso. Si deve perciò porre attenzione a più righe di tcpdump, come nell’esempio seguente, e cercare di ottenere uno schema generale: Listato 16.1

16:55:17.496295 192.168.100.3.1198 > dns.interbusiness.it.domain: 6272+[|domain] 16:55:17.590060 dns.interbusiness.it.domain > 192.168.100.3.1198: 6272[|domain] (DF) 16:55:17.591980 192.168.100.11.3195 > gluck.debian.org.www: S 288187215:288187215(0) win 64240 (DF) 16:55:17.823698 gluck.debian.org.www > 192.168.100.11.3195: S 3920803322:3920803322(0) ack 288187216 win 5840 (DF) 16:55:17.823972 192.168.100.11.3195 > gluck.debian.org.www: . ack 1 win 64240 (DF) 16:55:17.824409 192.168.100.11.3195 > gluck.debian.org.www: P 1:356(355) ack 1 win 64240 (DF) 16:55:18.083602 gluck.debian.org.www > 192.168.100.11.3195: . ack 356 win 6432 (DF) 16:55:18.131490 gluck.debian.org.www > 192.168.100.11.3195: . 1:1461(1460) ack 356 win 6432 (DF) 16:55:18.160813 192.168.100.3.1198 > dns.interbusiness.it.domain: 4236+[|domain] 16:55:18.177141 gluck.debian.org.www > 192.168.100.11.3195: . 1461:2921(1460) ack 356 win 6432 (DF) 16:55:18.177764 192.168.100.11.3195 > gluck.debian.org.www: . ack 2921 win 64240 (DF) 16:55:18.311731 dns.interbusiness.it.domain > 192.168.100.3.1198: 4236[|domain] (DF) 16:55:18.333818 192.168.100.11.3194 > 216.239.41.104.www: P 357:738(381) ack 175 win 64066 (DF) 16:55:18.347074 192.168.100.11.3196 > gluck.debian.org.www: S 288437167:288437167(0) win 64240 (DF) 16:55:18.455167 gluck.debian.org.www > 192.168.100.11.3195: . 2921:4381(1460) ack 356 win 6432 (DF)

Nella prima riga si nota che un nodo interno, 192.168.100.3, sta inoltrando una richiesta al DNS dns.interbusiness.it, presente esternamente su Internet. L’utente ha probabilmente digitato un indirizzo esteso e il computer ha bisogno di conoscere l’indirizzo IP relativo. Alla riga seguente si può osservare che il DNS ha risposto all’interrogazione, probabilmente fornendo il valore numerico di cui si aveva bisogno. Nella terza riga si nota che un altro nodo interno, questa volta il 192.168.100.11 sta comunicando con gluck.debian.org e la comunicazione prosegue nelle righe seguenti con un intenso scambio di pacchetti.

Pur non conoscendo i dettagli tecnici del protocollo TCP si è già scoperto che un utente ha digitato un indirizzo esteso e che un altro sta ricevendo traffico da debian.org. In un flusso successivo si individuano le righe seguenti: Listato 16.2

17:26:55.510594 17:26:55.511544 64860 17:26:55.511780 win 65423 (DF) 17:26:55.512445 64860 17:26:55.512618 win 65400 (DF)

192.168.100.6.3501 > pop.incipit.biz.pop3: . ack 1 win 65535 (DF) pop.incipit.biz.pop3 > 192.168.100.6.3501: P 1:113(112) ack 1 win 192.168.100.6.3501 > pop.incipit.biz.pop3: P 1:34(33) ack 113 pop.incipit.biz.pop3 > 192.168.100.6.3501: P 113:136(23) ack 34 win 192.168.100.6.3501 > pop.incipit.biz.pop3: P 34:48(14) ack 136

Un nodo interno, il 192.168.100.6 sta comunicando con l’indirizzo pop.incipit.biz alla porta pop3. Nella riga seguente si ha una risposta dal server POP3 e la comunicazione continua nelle righe seguenti. Queste sei righe sono l’istantanea di una sessione di download della posta elettronica da parte di un sistema interno. Qualche minuto dopo viene formulata un’altra operazione importante: 17:30:18.562699 arp who-has 192.168.100.1 tell 192.168.100.21

Si tratta di una richiesta eseguita dal sistema 192.168.100.21 per conoscere l’indirizzo MAC della scheda di rete che ha l’indirizzo IP 192.168.100.1. Questa richiesta serve perché i protocolli di rete sono stratificati: al livello più basso si ha lo strato fisico, costituito da una serie di standard che stabiliscono il modo in cui le comunicazioni sono veicolate da un punto di vista elettrico, più in alto (al livello 2) si ha Ethernet, che funziona usando indirizzi di rete univoci (definiti MAC) impressi su ogni scheda di rete in fase di fabbricazione. Lo schema di numerazione è stabilito a livello internazionale e non dovrebbero esistere due schede di rete con lo stesso valore. Ogni interfaccia di rete diventa così univocamente riconoscibile. Al livello 3 si ha il protocollo IP, con i noti indirizzi a quattro campi come 192.168.200.15. Durante le operazioni di instradamento è però necessario sapere quale indirizzo MAC veicola un determinato IP. Non è detto che tutti i nodi della rete conoscano questa informazione, soprattutto se si accendono nuovi computer in LAN. Con un’apposita richiesta, denominata tecnicamente arp, si può conoscere l’abbinamento tra indirizzo IP e indirizzo MAC. La riga catturata da tcpdump e riportata qui in alto evidenza questa operazione. Qualche secondo più tardi, tcpdump cattura questa riga: 17:31:05.558518 arp reply 192.168.100.1 is-at 0:4:ac:b9:1a:d1

È la risposta alla richiesta arp. Questa rivela che la macchina 192.168.100.1 si trova all’indirizzo MAC 0:4:ac:b9:1a:d1.

Un altro tipo di pacchetti che potrebbero essere presenti con una certa frequenza sono mostrati nelle righe seguenti: 18:14:26.425402 host165-236.pool8172.interbusiness.it > 213.174.166.3: icmp: echo request 18:14:26.425449 213.174.166.3 > host165-236.pool8172.interbusiness.it: icmp: echo reply

Questa è la rappresentazione di un ping proveniente da host165-236.pool8172.interbusiness.it, una connessione ADSL di Telecom Italia e indirizzato al nodo pubblico 213.174.166.3. Subito dopo i due

punti si vede la sigla icmp (il nome del protocollo preposto ai messaggi di controllo della rete), seguita dal tipo di richiesta: la prima è echo request, in pratica un ping proveniente dal nodo remoto, mentre la riga seguente registra una comunicazione dal nodo locale verso il sistema remoto, è di tipo echo reply e significa che sistema locale ha risposto alla richiesta.

Tcpdump e il protocollo UDP Il protocollo TCP è utilizzato quando si devono veicolare informazioni in maniera affidabile, per esempio durante il trasferimento di un file. In questi casi non è pensabile perdere neanche un bit di informazione e serve un controllo completo della trasmissione. Ci sono però molti casi in cui tutto questo non è necessario e può andare bene un protocollo più leggero, privo di tutti questi controlli. È il caso di UDP. I pacchetti UDP sono rappresentati da tcpdump in maniera simile alle registrazioni del protocollo TCP osservati in precedenza. Un output tipico è questo: 17:32:36.116034 192.168.100.7.netbios-dgm > 192.168.100.255.netbios-dgm: NBT UDP PACKET(138)

Si tratta del sistema interno 192.168.100.7 che sta comunicando sulla porta netbios-dgm (138) con l’indirizzo 192.168.100.255, sempre sulla stessa porta. Il valore 255 indica un broadcast. La comunicazione non è, cioè, indirizzata a un computer specifico, ma a tutti i sistemi che sono in ascolto sul mezzo. Si tratta in questo caso di una macchina Windows che sta aggiornando le proprie informazioni di rete. Potrebbe per esempio trattarsi dell’aggiornamento dell’elenco dei computer che si possono osservare facendo clic su Risorse di rete (Figura 16.2).

Figura 16.2 I computer elencati in Risorse di rete di W indow s XP vengono aggiornati attraveso dei broadcast in rete.

La richiesta è indirizzata a tutti i sistemi, perché potrebbe essere necessario conoscere quali computer risultano accesi e disponibili e quali sono stati spenti. Un altro esempio di output UDP riguarda la richiesta della risoluzione di un nome simbolico a un indirizzo IP. Un utente ha aperto il browser e ha digitato l’indirizzo www.redhat.com. Il comando tcpdump ha registrato questo evento nella riga seguente: 17:42:10.078279 192.168.100.3.1198 > dns.interbusiness.it.domain: 2404+[|domain]

La richiesta proviene dal nodo 192.168.100.3 ed è diretta al server dns.interbusiness.it sulla porta domain. Questo è già sufficiente per capire che cosa sta accadendo, ma se si desidera andare più a fondo è possibile esaminare i flag e scoprire che la richiesta ha come id il valore 2404. Il segno + indica che è stata richiesta la ricorsione per questo tipo di interrogazione al DNS. La risposta viene registrata poco dopo: 17:42:10.196316 dns.interbusiness.it.domain > 192.168.100.3.1198: 2404[|domain] (DF)

Come si può osservare, tcpdump ha fornito dati molto precisi sui pacchetti coinvolti nella transazione DNS, ma non ha mostrato alcun tipo di contenuto. Questo è normale, perché la visualizzazione dei dati renderebbe l’output del programma estremamente ingombrante e difficile da seguire. Nella maggior parte dei casi serve capire come sta evolvendo il traffico e in tal caso i contenuti sono del tutto superflui. In fase di analisi si consiglia anche di non concentrarsi troppo sul singolo pacchetto e sui dettagli, ma piuttosto di seguire la comunicazione nel tempo. Si tratta di un approccio di alto livello, che permette di capire come i sistemi stanno usando la rete. Gli indirizzi di origine e destinazione, le porte e il verso della comunicazione sono sufficienti per lavorare da subito in maniera proficua con tcpdump.

Opzioni di tcpdump Lo strumento tcpdump è molto complesso e permette un elevato grado di controllo tramite opzioni impartite dalla riga di comando. L’elenco completo è accessibile digitando man tcpdump oppure consultando l’ultima versione online del manuale, disponibile all’indirizzo http://www.tcpdump.org/tcpdump_man.html. Nei prossimi paragrafi sarà presentato un sottoinsieme dei suoi comandi, ponendo attenzione sulle funzioni di utilizzo più comune.

Scelta della scheda di rete L’opzione certamente più usata è -i, che permette di specificare quale adattatore di rete monitorare, per esempio tcpdump -i eth1 per visualizzare il traffico sulla seconda scheda di rete installata nel computer oppure tcpdump -i ppp0 per l’attività sulla connessione a Internet via modem. Questa opzione si rivela molto utile in macchine Linux adibite, per esempio, a firewall. In questi casi si dispone di due schede di rete, una su Internet e l’altra sulla rete interna alla LAN. Tramite l’opzione -i è possibile spostare la propria attenzione sul traffico interno oppure vedere tutto ciò che transita (o cerca di transitare) dall’esterno verso il firewall.

Aumento del livello di dettaglio

L’output di tcpdump è ottimizzato per un livello di visualizzazione medio. Usando l’opzione -v è possibile incrementare il grado di dettaglio e avere un numero maggiore di informazioni. È curioso notare che scrivendo -vv si ottiene un grado ulteriore di informazioni, incrementabile ancora con -vvv. Va comunque rilevato che ogni pacchetto ha comunque un grado massimo di dettagli. Per esempio il traffico TCP non esibisce differenze apprezzabili tra il livello -vv e quello -vvv.

Diminuzione del livello di dettaglio È possibile limitare il numero di informazioni visualizzate da tcpdump. Si avranno così solo gli indirizzi di origine e destinazione, la porta in oggetto e il protocollo usato. La sintassi da adottare è la seguente: tcpdump -q -i eth0

L’output che risulta avrà questo formato: Listato 16.3

18:46:43.615130 host165-236.pool8172.interbusiness.it.61541 > 194.185.22.168.pop3: tcp 0 (DF) 18:46:43.616855 194.185.22.168.pop3 > host165-236.pool8172.interbusiness.it.61541: tcp 0 (DF) 18:46:43.617223 host165-236.pool8172.interbusiness.it.61541 > 194.185.22.168.pop3: tcp 0 (DF) 18:46:43.690121 194.185.22.168.pop3 > host165-236.pool8172.interbusiness.it.61541: tcp 0 (DF) 18:47:03.067677 arp who-has host166-236.pool8172.interbusiness.it tell host165-236. pool8172.interbusiness.it 18:47:03.068078 arp reply host166-236.pool8172.interbusiness.it is-at 0:30:a:6:fb:70

Cattura di un numero prefissato di pacchetti È possibile limitare il numero di pacchetti che si intende monitorare e fare in modo che tcpdump esca automaticamente dopo aver raggiunto questa soglia. Il comando in questo caso è tcpdump -c più il relativo valore, per esempio: tcpdump -c 10 -i eth1

Si avranno solo i primi dieci pacchetti catturati dalla scheda di rete eth1.

Stampa dell’ indirizzo MAC su ogni riga È possibile visualizzare l’indirizzo MAC della scheda di rete a ogni riga di cattura. Per farlo si deve usare la seguente sintassi: tcpdump -e -i eth1

Si avrà un output simile al seguente: Listato 16.4

18:37:22.195034 0:30:84:9d:e0:14 0:30:a:6:fb:70 ip 54: host165-236.pool8172. interbusiness.it.61517 > ns5.widhost.net.domain: . ack 37 win 64205 (DF) 18:37:26.395248 0:30:84:9d:e0:14 0:30:a:6:fb:70 ip 93: host165-236.pool8172. interbusiness.it.61513 > HA-server-b.cs.interbusiness.it.domain: 6760+[|domain] 18:37:26.476992 0:30:a:6:fb:70 0:30:84:9d:e0:14 ip 155: HA-server-b.cs. interbusiness. it.domain > host165-236.pool8172.interbusiness.it.61513: 6760 NXDomain[|domain] (DF) 18:37:31.047671 0:30:84:9d:e0:14 0:30:a:6:fb:70 arp 42: arp who-has host166-236. pool8172.interbusiness.it tell host165-236.pool8172.interbusiness.it 18:37:31.048108 0:30:a:6:fb:70 0:30:84:9d:e0:14 arp 60: arp reply host166-236. pool8172.interbusiness.it is-at 0:30:a:6:fb:70

Cattura dei pacchetti in un file Come per ogni comando Linux è possibile dirottare l’output di tcpdump su un file in modo da poter salvare una particolare sessione di monitoraggio della rete. La sintassi è la seguente: tcpdump -i eth1 > sessione_12005.txt

Questo permette di ottenere una cattura in formato testuale, leggibile in un secondo momento con qualsiasi editor di testo o visualizzatore. tcpdump permette però di andare oltre e disporre della cattura binaria su file di una sessione. In seguito sarà possibile caricare il file di dati nuovamente su tcpdump e ottenerne la decodifica a video. Si tratta di un utilizzo differito di tcpdump. Questo metodo di salvataggio permette di visualizzare la sessione salvata come se fosse generata in tempo reale e tutte le opzioni di tcpdump sono in tal caso utilizzabili. Si può per esempio variare il livello di dettaglio o filtrare i protocolli. La cattura su un file di testo è invece una procedura statica, che non permette di cambiare in alcun modo la visualizzazione. Per catturare i pacchetti in formato binario si usa la sintassi seguente: tcpdump -w sessione_12005.tcpdump

Per visualizzare il file sessione_12005.tcpdump si dovrà invece digitare: tcpdump -r sessione_12005.tcpdump

Visualizzazione di sequenze TCP complete Il comando tcpdump visualizza le sequenze dei pacchetti TCP in formato relativo rispetto al valore precedente. È disponibile anche un’opzione per la visualizzazione dei valori assoluti. Basta digitare -s: tcpdump -s

Esclusione di un protocollo

È possibile utilizzare espressioni logiche per limitare i pacchetti visualizzati dall’output di tcpdump in base a criteri sui nodi di origine e di destinazione, le porte, il protocollo e così via. Tale funzionalità è molto utile per esempio quando ci si connette a una Linux box remota in SSH e si ha bisogno di monitorare il traffico Internet su quella macchina. Normalmente si avrebbe un elevato grado di disturbo, dato dal protocollo SSH stesso. In mezzo al traffico Internet è presente infatti anche il traffico della sessione remota attiva e verrebbe perciò visualizzato un gran numero di pacchetti non importanti. Il numero di queste righe potrebbe essere superiore al traffico che si vuole analizzare, rendendo difficile la verifica del traffico. È pertanto possibile istruire tcpdump per scartare il traffico della propria sessione di telecontrollo. Qualora si stia usando SSH e si voglia filtrare questo protocollo, si deve usare la sintassi che segue: tcpdump -i eth1 not port 22

Il parametro not rappresenta la negazione logica, port è la parola chiave che indica la porta e 22 è la porta standard di SSH. In sostanza si sta chiedendo a tcpdump di escludere (not) dalla visualizzazione tutto il traffico che interessa la porta 22. Gli operatori logici possono essere combinati tra loro per avere filtri più selettivi. Si pensi per esempio all’esigenza di dover monitorare il traffico di pacchetti POP3, escludendo tutto il disturbo arrecato dagli accessi al Web e dalla sessione SSH attiva. Basta impiegare una sintassi combinata: tcpdump -i eth1 not port 22 and not port 80

In questo modo passerà tutto il traffico, tranne quello che interessa le porte 22 (SSH) e 80 (Web). È comunque preferibile una sintassi più precisa, perché nel caso precedente si avrà ancora l’output di traffico estraneo e sarà ancora difficile seguire le attività POP3. Si può quindi istruire tcpdump e mostrare solo la porta pop3: tcpdump -i eth1 port pop3

Nel prossimo esempio si vuole invece filtrare il traffico della porta SSH e il traffico che origina dal nodo 192.168.100.11. Il traffico che è invece destinato al nodo .11 sarà visibile. tcpdump -i eth1 not src host 192.168.100.11 and not port 22

L’espressività ammessa da tcpdump è molto ampia. Per visualizzare l’elenco completo delle variabili utilizzabili, si consiglia di consultare la sezione expression delle pagine man di questo comando.

Dove installare tcpdump Lo strumento tcpdump è in grado di monitorare e visualizzare il traffico presente unicamente sul punto in cui è collegato il computer. Il programma non ha cioè la facoltà di “vedere” tutta la rete ed è quindi importante scegliere con cura il luogo in cui installare il sistema di monitoraggio. La situazione ideale si ha nei casi in cui si utilizza un computer Linux per espletare le funzioni di router e firewall (Figura 16.3). In questo caso il controllo avviene nel punto di scambio tra la rete interna e il mondo esterno. Si può quindi visualizzare tutto il traffico che gli utenti interni generano verso Internet e viceversa. È sufficiente, in questo caso, selezionare la scheda di rete esterna (eth1 in questo esempio).

Figura 16.3 Tcpdump è installato nel punto di confine tra la rete interna e la rete esterna. In questo modo è possibile monitorare l’attività su Internet.

Se si ha un file server su Windows e si vuole controllare il traffico che interessa questo sistema, la situazione diventa più complessa. Si dovrebbe infatti configurare un router Linux utilizzando un computer con due schede di rete e posizionarlo in corrispondenza del server Windows (Figura 16.4).

Figura 16.4 Tcpdump è installato tra i server W indow s e il resto della LAN. In questo modo è possibile monitorare tutto il traffico verso il sistema centrale.

Il router svolgerà la funzione di “passaggio obbligato” per tutti coloro che vorranno accedere al server. In questo modo rimarrà una traccia, visualizzabile con il comando tcpdump di qualunque attività. La configurazione del router è simile a quella di un firewall, ma con la differenza che non ci sono le regole di filtraggio. La soluzione ha però un aspetto molto complesso. Bisogna infatti dividere la rete locale in due sottoreti e usare due schemi di indirizzo, uno per i client e l’altro per il server. Su ogni client dovrà essere presente una

regola di routing che istruisce il computer a inoltrare i pacchetti al server passando per il router. Analogamente il server dovrà avere una regola per fare in modo che i pacchetti per i client vengano inoltrati al router. Nell’esempio illustrato, i client Windows dovranno avere una regola di questo genere: route add 192.168.200.0 mask 255.255.255.0 192.168.100.1 mask 255.255.255.0

È possibile fare un batch all’avvio oppure usare l’opzione -p, per memorizzare la regola staticamente sul registro di Windows. Il server avrà invece la regola: route -p add 192.168.100.0 mask 255.255.255.0 192.168.200.1 mask 255.255.255.0

All’interno del router vi saranno regole per lo smistamento dei pacchetti tra le schede fisiche: route add -net 192.168.100.0 netmask 255.255.255.0 dev eth1 route add -net 192.168.200.0 netmask 255.255.255.0 dev eth0

Tecnicamente la struttura funziona, ma potrebbero verificarsi problemi con protocolli o applicazioni particolari e comunque si tratta di un grado di complessità superfluo che può introdurre malfunzionamenti. È molto meglio risolvere il problema usando uno switch evoluto. I modelli professionali hanno la possibilità di replicare il traffico che interessa una porta specificata dall’utente verso un’altra porta dell’apparato. È possibile quindi realizzare una Linux box, collegarla allo switch, per esempio alla porta 13, e fare in modo che su questa porta sia replicato tutto il traffico che interessa il file server. Il problema è risolto senza complicazioni! Con lo stesso principio si possono poi aggiungere altri sistemi da tenere sott’occhio. La funzionalità di replica si chiama SPAN. Bisogna però fare attenzione perché non è disponibile nei modelli economici. Servono apparati professionali, denominati managed switch, in grado di essere configurati da un pannello software. Lavorando invece su reti più semplici, per risolvere il problema potrebbe bastare l’uso di un hub. È forse utile ribadire la differenza tra un hub e uno switch. Entrambi i dispositivi svolgono la stessa funzione di collegamento tra i computer, ma nell’hub il canale è condiviso e tutte le porte “vedono” il traffico delle altre porte. Nello switch le comunicazioni sono invece isolate porta a porta. Se tcpdump è presente su un computer collegato a un hub, sarà allora possibile controllare tutto il traffico sulla rete. Si tratta della condizione ideale per il monitoraggio della LAN. Lo stesso computer con tcpdump, se installato invece su una rete con switch, vedrà solo il traffico indirizzato al proprio sistema e i broadcast degli apparati e del sistema operativo. Si perde in questo caso ogni possibilità di controllo. Meglio quindi un hub? In realtà no: gli hub sono apparati obsoleti, in quanto meno efficienti e meno sicuri. Sono inoltre praticamente introvabili oggi.

IPTraf, uno strumento di analisi intuitivo tcpdump è uno strumento di analisi molto ricco e completo oltre che essere considerato uno dei tool basilari in qualsiasi distribuzione Linux. Lo strumento risulta però complesso per coloro che si avvicinano per la prima volta a Linux per via dell’interfaccia utente testuale e per l’enorme quantità di opzioni. Anche l’output può risultare di difficile interpretazione per coloro che cominciano. Inutile dire che questi stessi aspetti sono considerati punti di forza dagli utenti con più esperienza. Questo significa semplicemente che tcpdump si apprezza nel tempo, una volta acquisita una certa conoscenza del programma e dei protocolli. Fortunatamente esistono molte alternative in ambito Linux ed è possibile eseguire attività di monitoraggio

con strumenti più intuitivi. Uno di questi è IPTraf, mantenuto presso http://iptraf.seul.org. Questo strumento permette di visualizzare con un’interfaccia a caratteri le attività che interessano le schede di rete configurate presso il sistema in cui gira. Il traffico non viene però visualizzato in maniera sequenziale, riga per riga, ma organizzato per indirizzi IP. Si può così avere un colpo d’occhio migliore su quanto sta avvenendo nel sistema. Per attivare il programma si deve digitare iptraf da riga di comando. Se la shell mostra un messaggio d’errore, significa che il pacchetto non è installato. Bisogna quindi procedere alla sua installazione dai dischi della distribuzione oppure dal sito ufficiale. Una volta lanciato, il programma mostra una schermata informativa. Premendo un tasto si entra nel menu principale (Figura 16.5).

Figura 16.5 Menu principale di IPTraf.

Il programma è già configurato di default per essere operativo e quindi si possono usare subito le voci operative. Premendo Invio su IP Trafic Monitor compare un nuovo menu dove viene richiesta quale scheda di rete si intende monitorare. Bisogna selezionare la scheda e premere nuovamente Invio (Figura 16.6).

Figura 16.6 Selezione dell’interfaccia di rete da monitorare.

Compare così la schermata operativa del programma, dove viene visualizzato il traffico in tempo reale sulla scheda. Come si può notare, le righe di traffico sono visualizzate a coppie. In questo modo l’indirizzo sorgente viene abbinato all’indirizzo di destinazione. Sulla destra sono invece presenti dei contatori in tempo reale, che visualizzano il numero di pacchetti scambiati, i byte trasmessi e lo stato dei flag. Premendo il tasto M si possono visualizzare informazioni aggiuntive, quali la dimensione dei pacchetti e la dimensione della finestra. Premendo invece il tasto W si può cambiare la zona attiva. La finestra è infatti divisa in due zone, entrambe consultabili con i tasti cursore. Con il tasto W non si fa altro che selezionare una delle due zone. Solo la zona selezionata può essere consultata con i cursori. Con il tasto S infine si può riordinare la visualizzazione in base a un criterio basato sul numero dei pacchetti o sulla dimensione complessiva dei pacchetti scambiati (Figura 16.7).

Figura 16.7 Dettaglio dell’attività con IPTraf.

Conclusa l’operazione di monitoraggio, si preme il tasto X per tornare al menu principale. La voce General interface statistics permette invece di ottenere una schermata riassuntiva dell’attività sulle schede di rete. Dal momento in cui viene selezionata, partono dei contatori che segnalano il numero di pacchetti scambiati e la banda impiegata. Non ci sono in questo caso altre opzioni selezionabili (Figura 16.8).

Figura 16.8 Pannello General interface statistcs.

Premendo il tasto X si esce e si torna nuovamente al menu principale. La voce seguente, Detailed interface statistics, permette invece di visualizzare informazioni più dettagliate sul traffico in corso sulla macchina. In particolare si può conoscere in tempo reale il numero dei pacchetti e il quantitativo in byte dei dati scambiati, suddivisi per protocolli (Figura 16.9).

Figura 16.9 Pannello Detailed interface statistics.

Premendo il tasto X si esce e si torna nel menu principale. Selezionando la voce di menu seguente, Statistical breakdowns, si entra in un sottomenu che richiede se visualizzare le informazioni secondo un criterio di dimensione o di porte. Nel primo caso compare un elenco suddiviso per gruppi di dimensioni in byte (da 1 a 75 byte, da 76 a 150 byte, da 151 a 225 byte e così via). Ogni riga contiene un contatore che indica il numero di pacchetti scambiati entro la dimensione (Figura 16.10).

Figura 16.10 Statistiche dei pacchetti scambiati, divise per byte.

Nel caso si scelga la seconda opzione, per porta, si ottiene il dettaglio dei pacchetti e dei byte scambiati, suddivisi per porta. L’elenco può essere ordinato secondo vari criteri tramite il tasto S. Questa visualizzazione

è molto utile per capire quali servizi vengono maggiormente usati e con quale impatto in termini di banda (Figura 16.11).

Figura 16.11 Statistiche del traffico, suddivise per porta.

Premendo il tasto X si ritorna al menu principale. L’opzione seguente, LAN station monitor, visualizza informazioni su tutti gli indirizzi MAC che hanno scambiato traffico con il sistema monitorato. Le voci successive del menu principale consentono di configurare il comportamento del programma. La prima voce, Filters, permette di alterare la visualizzazione delle informazioni. Selezionando l’opzione compare un menu per la scelta del protocollo (IP, ARP, RARP e non-IP). Selezionando IP compare un ulteriore menu in cui si può definire un filtro e poi gestirlo (applicarlo, scollegarlo, editarlo e rimuoverlo). Selezionando Define new filter, viene chiesto di specificare un nome per il filtro. Confermando compare una finestra con l’elenco dei filtri, inizialmente vuoto. Si deve premere il tasto I per inserire una nuova regola. Come si può osservare dalla Figura 16.12, le possibilità sono ampie. È possibile filtrare per indirizzi, per subnet mask, per porte e per protocolli.

Figura 16.12 Finestra per la definizione di una nuova regola di filtro.

Una volta concluso si preme il tasto invio per inserire la regola nella lista dei filtri. Ora è possibile inserire altre regole oppure editare la regola appena realizzata. La regola appena inserita non è però operativa. Bisogna prima selezionare la voce Apply filter e scegliere il filtro che si intende abilitare. A questo punto, tornando nelle voci operative, si vedrà solo il traffico filtrato dalle regole appena create. Quando il filtro avrà esaurito la sua utilità si deve selezionare Detach filter per scollegarlo. I filtri su ARP, RARP e Non-IP sono più semplici da gestire in quanto sono semplici “interruttori”. Si può cioè semplicemente stabilire se vedere o meno il traffico ARP, RARP e Non-IP. Tornando al menu principale e selezionando Configure si apre un pannello dove è possibile variare i parametri di funzionamento del programma (Figura 16.13).

Figura 16.13 Pannello di configurazione di IPTraf.

I filtri impostati e le configurazioni vengono salvate in maniera stabile e verranno applicati automaticamente la prossima volta che si entrerà nel programma. Bisogna quindi gestire con attenzione i filtri, per evitare di perdere informazioni importanti sul traffico. È infatti facile dimenticare dei filtri attivi tra una sessione e l’altra.

Monitorare le periferiche SNMP Fino a questo momento si è visto come monitorare con uno strumento di cattura il traffico che interessa le schede di rete montate nel sistema. Il mondo del software open-source mette però a disposizione molte altre possibilità di controllo che vale la pena di prendere in considerazione. Una delle più usate è MRTG (acronimo per Multi Router Traffic Grapher), uno strumento open-source per la gestione dei dispositivi dotati di protocollo SNMP. SNMP (simple network management protocol) è un protocollo aperto nato con lo scopo di fornire agli amministratori informazioni e allarmi sui dispositivi presenti in rete. Tramite SNMP è possibile, per esempio, conoscere il quantitativo di traffico rilevato sulle interfacce di un router, misurare il carico sulla CPU del dispositivo, capire se ci sono allarmi attivi e molte altre informazioni. Il grado e il numero di informazioni ottenibili dipende dal dispositivo stesso: una stampante fornirà ovviamente informazioni differenti da quelle generate da uno switch o da un server. Tutte le misurazioni vengono eseguite dal dispositivo stesso attraverso il proprio firmware. Non servono quindi meccanismi esterni di cattura o sonde software da installare. Questo differenzia il monitoraggio SNMP dai due sistemi descritti in precedenza in questo capitolo. Prima di poter eseguire il monitoraggio con MRTG devono verificarsi alcune condizioni. Servono innanzitutto dei dispositivi dotati di un agente SNMP. Devono cioè essere presenti una o più periferiche con un’implementazione del protocollo e con la capacità di comunicare le informazioni interne. Questa condizione è tutt’altro che scontata. Solo i dispositivi di fascia medio-alta dispongono di un’implementazione SNMP. I router o gli switch economici sono in genere privi di questa funzionalità. È necessario consultare la documentazione tecnica a corredo del prodotto per capire se il protocollo è presente. I dispositivi dotati di agenti SNMP sono in grado di comunicare informazioni interne di funzionamento, ma

hanno bisogno di un sistema centrale che raccolga questi dati e che li visualizzi in un formato leggibile dall’amministratore di rete. Senza tale elemento, l’utilità di SNMP è del tutto vana. Questa situazione è in realtà più comune di quanto si pensi. Molti ambienti di lavoro, anche piccoli, dispongono oggi di periferiche SNMP quali firewall, stampanti di rete o sistemi server, ma non hanno un sistema centrale in grado di raccogliere i dati SNMP. In questo modo vengono ignorate informazioni che costituiscono un grande valore nella gestione della rete e nella diagnosi di situazioni di errore. La carenza appena evidenziata deriva dal fatto che le implementazioni di SNMP sulle periferiche sono in qualche modo “gratuite”, nel senso che vengono fornite direttamente in fabbrica con il prodotto. I sistemi centrali di cattura e monitoraggio sono invece sempre componenti software opzionali, che vengono forniti con un costo di licenza non indifferente. La maggior parte dell’utenza preferisce evitare questo costo e rinunciare al monitoraggio SNMP. Qui di seguito si vedrà come risolvere il problema dei costi installando MRTG, un monitor SNMP del tutto gratuito. SNMP è un protocollo client-server. Gli agenti presenti sulle periferiche operano come server, mentre il sistema centrale di raccolta agisce da client. Gli agenti sulle periferiche vengono attivati all’accensione della periferica e restano in attesa di richieste da parte del pannello centrale. È compito dell’amministratore decidere quali dettagli delle periferiche controllare configurando il software centrale di monitoraggio. Questo non farà altro che interrogare a cadenza regolare gli agenti per leggere le informazioni richieste dall’amministratore. Esiste anche una comunicazione SNMP che opera nel senso opposto. È possibile cioè impostare le periferiche in modo che mandino automaticamente degli allarmi se si verificano situazioni particolari. In questo caso è il dispositivo che inizia una comunicazione con il software centrale di monitoraggio. Questa modalità è definita SNMP Trap. Ogni periferica abilitata SNMP può fornire un numero prefissato di informazioni, come il traffico, il carico sulla CPU, il numero di errori di comunicazione e così via. La lista di queste informazioni, o meglio variabili, è organizzata all’interno di una struttura dati standardizzata chiamata MIB (Management Information Base) e condivisa tra gli agenti e i software di controllo. In questo modo qualsiasi pannello può monitorare qualsiasi dispositivo periferico senza problemi di compatibilità. I software di controllo possono così funzionare subito dopo essere stati installati, senza la necessità che l’amministratore fornisca i dettagli precisi sulle periferiche. Basterà fornire l’indirizzo IP del dispositivo, una stringa di accesso e la variabile che si vuole monitorare. Il MIB può essere espanso dai produttori di hardware e software per gestire informazioni più specifiche sulle periferiche, ma in questo caso è necessario che anche il pannello centrale sia a conoscenza dell’estensione del MIB.

Configurare MRTG Questa breve fase teorica è già sufficiente per poter lavorare in maniera proficua con MRTG. Per passare alla fase pratica si prenderà in esame il caso di un piccolo ufficio dotato di tre postazioni di lavoro basate su Windows XP Professional, di due stampanti di rete, di un firewall Cisco e di un server Windows. Le postazioni con Windows XP dispongono di un agente SNMP. Questo è attivabile andando in Pannello di controllo > Installazione applicazioni > Installazione componenti di Windows. Compare una finestra da cui si deve scegliere Strumenti di gestione e controllo e poi SNMP (Figura 16.14).

Figura 16.14 W indow s XP Professional dispone di un agente SNMP.

Le due stampanti di rete sono anch’esse dotate di un agente SNMP (una terza stampante USB personale ne risulta invece priva), come pure ne sono dotati il firewall e il server. Non viene invece considerato il router, in quanto si trova oltre il firewall e quindi non accessibile dalla rete interna. Tutti gli agenti SNMP delle periferiche presenti sulla rete locale risultano abilitati e funzionanti di default. Non resta che pensare al sistema centralizzato di raccolta dati. Per cominciare si deve verificare che il pacchetto MRTG sia installato nel sistema Linux. Nel caso non lo sia è necessario usare il sistema di gestione dei pacchetti della propria distribuzione oppure scaricare il prodotto dal sito ufficiale (http://oss.oetiker.ch/mrtg) (Figura 16.15).

Figura 16.15 Sito ufficiale di MRTG.

MRTG non è un programma autonomo, ma ha bisogno di un server web correttamente configurato e funzionante. Si darà per scontato che il server Apache sia attivo. Nel caso non lo sia, si consiglia di consultare il Capitolo 15. Visto il legame stretto con Apache, la procedura di installazione di MRTG su CentOS crea un file di configurazione specifico per Apache dentro /etc/httpd/conf.d. Il file si chiama mrtg.conf ed è così strutturato: Listato 16.5

# # This configuration file maps the mrtg output (generated daily) # into the URL space. By default these results are only accessible # from the local host. # Alias /mrtg /var/www/mrtg

Order deny,allow Deny from all Allow from 127.0.0.1 Allow from ::1 # Allow from .example.com

La prima riga realizza un alias. Viene cioè stabilito che il collegamento web /mrtg si trova nel file system del server Linux in /var/www/mrtg. Questo significa che se il proprio server Linux ha l’indirizzo 192.168.100.1, sarà sufficiente scrivere http://192.168.100.1/mrtg sul browser per accedere alle informazioni raccolte da MRTG. Se si prova ad accedere, l’operazione molto probabilmente fallirà, a meno che

non si stia usando il browser presente sul server web stesso. Questo avviene perché la configurazione predefinita è estremamente limitativa e permette l’ingresso unicamente dal server dove è installato MRTG. Bisogna modificare le direttive Allow from inserendo l’indirizzo IP del client interno abilitato ad accedere alle pagine di monitoraggio, tipicamente la macchina dell’amministratore di sistema, per esempio 192.168.100.100. Questa è la configurazione riveduta: Listato 16.6

# This configuration file maps the mrtg output (generated daily) # into the URL space. By default these results are only accessible # from the local host. # Alias /mrtg /var/www/mrtg

Order deny,allow Deny from all Allow from 192.168.100.100

Su Ubuntu viene applicata una configurazione differente e l’area web di MRTG è disponibile a tutti gli utenti. Completata la fase di impostazione dei diritti di accesso dell’area web si deve riavviare Apache e poi procedere con la configurazione specifica di MRTG. Il sistema funziona attraverso i parametri operativi presenti in /etc/mrtg/mrtg.cfg su CentOS oppure in /etc/mrtg.cfg su Ubuntu. Si tratta di un file testuale liberamente editabile con parecchie opzioni che è necessario conoscere. MRTG offre però una scorciatoia per essere subito operativi: un meccanismo per la configurazione automatica. Basta utilizzare il comando cfgmaker e una sintassi molto semplice, come nell’esempio seguente su CentOS: cfgmaker --global 'WorkDir: /var/www/mrtg' --output /etc/mrtg/mrtg.cfg [email protected]

Nel caso di utilizzo su Ubuntu si dovrà semplicemente cambiare il percorso del file di configurazione. Gli esempi seguenti saranno realizzati sempre su CentOS. Per riportarli su Ubuntu sarà sufficiente cambiare il percorso del file di configurazione mrtg.cfg in /etc/mrtg.cfg. Nell’esempio si indica che la directory di lavoro è /var/www/mrtg e che l’output del commando deve essere memorizzato in /etc/mrtg/mrtg.cfg. La directory di lavoro è il punto dove sono salvati i file HTML e i dati sugli apparati che si stanno monitorando, mentre la directory di output è il luogo dove sarà generato il file di configurazione di MRTG. L’ultima porzione del comando, [email protected], indica che il dispositivo da monitorare si trova all’indirizzo 192.168.100.11. Prima dell’indirizzo è presente la parola public. Si tratta di un’informazione molto importante. Tutti gli agenti SNMP sono accessibili previa fornitura di una sorta di password di accesso, chiamata community name. La comunity di default è public. La presenza di una password è una buona politica di sicurezza, ma il modello che è stato implementato in SNMP è stato a lungo criticato per via della facilità con cui è possibile violare la sicurezza. Le password sono infatti veicolate in chiaro sul canale e non ci sono livelli di protezione. La maggior parte degli apparati viene inoltre fornita direttamente dalla fabbrica con il protocollo attivo e con la password public. Molti amministratori disattenti accendono questi apparati su tratte pubbliche di Internet senza verificare lo stato di SNMP e utenti malintenzionati possono così accedere ai registri informativi degli apparati e carpire informazioni semplicemente usando le impostazioni di default. La situazione è stata risolta nelle release seguenti del protocollo, ora arrivato alla versione 3. Molti prodotti

si limitano comunque ancora a integrare versioni precedenti del protocollo nei dispositivi.

Configurazioni per apparati multipli Nell’esempio pratico precedente si è visto come realizzare in automatico la configurazione per un singolo dispositivo da monitorare. In questo caso si trattava di una postazione con Windows XP Professional. È possibile anche indicare un elenco di dispositivi da monitorare e fare in modo che il comando cfgmaker realizzi un file di configurazione unico per tutti questi dispositivi, come in questo esempio su CentOS: cfgmaker --global 'WorkDir: /var/www/mrtg' --output /etc/mrtg/mrtg.cfg [email protected] [email protected] [email protected] [email protected]

In questo caso sono state inserite due stampanti di rete (192.168.100.8 e 192.168.100.9), il client Windows XP precedente (192.168.100.11) e il server centrale (192.168.100.3). Tutti questi dispositivi saranno in questo modo monitorati da MRTG. Ora che il file di configurazione è stato realizzato in maniera automatica è necessario lanciare un altro comando, denominato indexmaker. Questo realizza l’ossatura HTML dei dati che vengono raccolti da MRTG. Così si avranno delle pagine navigabili dal browser senza dover scrivere neanche una riga di codice: indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/mrtg.cfg

Come parametri si indica la directory HTML dove sarà creato il file index.html e il punto dove si trova la configurazione di MRTG. A questo punto l’infrastruttura è realizzata. Non resta che cominciare a raccogliere i dati. La procedura non è automatica, ma bisogna piuttosto richiamare a cadenza regolare il comando mrtg seguito dal percorso dove si trova il file di configurazione, come in questo esempio su CentOS: mrtg /etc/mrtg/mrtg.cfg

Su Ubuntu è sufficiente cambiare i percorsi: mrtg /etc/mrtg.cfg

La prima volta si consiglia di digitare il comando dalla shell e vedere se ci sono dei problemi. Potrebbe succedere che il comando segnali un errore sulla variabile d’ambiente LANG. Questa potrebbe, per esempio, essere impostata su UTF8, interferendo con il funzionamento del programma: Listato 16.7

----------------------------------------------------------------------ERROR: Mrtg will most likely not work properly when the environment variable LANG is set to UTF-8. Please run mrtg in an environment where this is not the case. Try the following command to start: env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg ----------------------------------------------------------------------In tal caso bisogna inserire in uno degli script di avvio del sistema questo comando:

export LANG=C

Potrebbe essere visualizzato un altro errore la prima volta che si lancia il programma, ma questo non rappresenta un problema. Si tratta di un avvertimento circa lo stato dei buffer usati da MRTG per funzionare. Lanciando nuovamente il comando, l’errore non dovrebbe più essere visualizzato. Ora si dovrebbero avere delle pagine corredate da dati. Basta aprire il browser e digitare l’indirizzo http://192.168.100.1/mrtg per apprezzare il risultato. Il comando mrtg deve essere lanciato a cadenza regolare e deve quindi essere inserito nel file di configurazione di cron. Basta aprire il file /etc/crontad e inserire la seguente riga su CentOS: */5 * * * * /usr/bin/mrtg /etc/mrtg/mrtg.cfg --logging /var/log/mrtg.log Su Ubuntu è necessario cambiare i percorsi: */5 * * * * /usr/bin/mrtg /etc/mrtg.cfg --logging /var/log/mrtg.log

In questo modo si avrà l’esecuzione del comando ogni 5 minuti. Verrà usato il file di configurazione standard mrtg.cfg, mentre le attività saranno registrate nel file di log /var/log/mrtg.log.

Impostazioni avanzate di MRTG Il comando cfgmaker è molto comodo, in quanto permette di avere un meccanismo di monitoraggio senza conoscere troppi dettagli di MRTG. È un ottimo modo per cominciare, ma non può certo essere considerato un punto di arrivo. Questa modalità operativa è infatti limitata: i file di configurazione generati monitoreranno solamente il traffico sulle interfacce di comunicazione, tralasciando le innumerevoli altre variabili presenti nel dispositivo. Per avere il pieno controllo di MRTG bisogna aprire il file di configurazione e inserire manualmente le specifiche delle variabili che si intendono controllare. Questo lavoro non è in realtà semplice in quanto bisogna conoscere con precisione il nome della variabile oppure una sorta di indirizzo numerico che indica la posizione della variabile nella gerarchia del dispositivo. Ogni dispositivo abilitato SNMP dispone in memoria di una struttura dati chiamata MIB. La struttura dati è organizzata ad albero e ogni foglia dispone di un nome esteso ben preciso e di un insieme di coordinate numeriche separate da punti che identificano la sua posizione all’interno della struttura (per esempio 1.7.4.9.14). Le “mappe” MIB sono in buona misura standard e in parte estese dal produttore per contenere informazioni specifiche sul prodotto. Il produttore della periferica dovrebbe fornire nella documentazione del prodotto gli schemi MIB, in modo che gli amministratori possano reperire le informazioni necessarie. Per monitorare un preciso dettaglio della periferica bisogna semplicemente inserire il nome esteso o la coordinata MIB all’interno della configurazione di MRTG. Il comando cfgmaker non fa altro che reperire le coordinate per le interfacce di rete e scrivere una riga di configurazione apposita. L’esempio seguente mostra la porzione del file mrtg.cfg ottenuta con cfgmaker per l’interfaccia esterna di un firewall Cisco PIX 501: Listato 16.8

### Interface 1 >> Descr: 'PIX-Firewall-'outside'-interface' | Name: '' | Ip: '82.106.143.3' | Eth: '00-13-c4-3b-30-d3' ### Target[192.168.100.1_1]: 1:[email protected]: SetEnv[192.168.100.1_1]: MRTG_INT_IP="82.106.143.3" MRTG_INT_DESCR="PIX-Firewall'outside'-interface"

MaxBytes[192.168.100.1_1]: 12500000 Title[192.168.100.1_1]: Traffic Analysis for 1 -- fw01.incipit.biz PageTop[192.168.100.1_1]: Traffic Analysis for 1 -- fw01.incipit.biz

System:	fw01.incipit.biz in Imola
Maintainer:	Silvio Umberto Zanzi
Description:	PIX-Firewall-'outside'-interface
ifType:	ethernetCsmacd (6)
ifName:
Max Speed:	12.5 MBytes/s
Ip:	82.106.143.3 (host3-143.pool82106.interbusiness.it)

La riga da osservare è la seguente: Target[192.168.100.1_1]: 1:[email protected]:

Subito prima di public c’è il simbolo di due punti (:) e il numero 1. Questo valore indica la scheda di rete esterna del firewall. Se si volesse monitorare l’interfaccia interna si dovrebbe usare un target differente: Target[192.168.100.1_2]: 2:[email protected]:

Le coordinate non sono sempre così semplici, generalmente sono molto più articolate. Per sapere quali variabili SNMP sono gestite da un particolare dispositivo è utile un comando Linux denominato snmpwalk. Questo è in grado di scandire le tabelle MIB di un dispositivo e stampare a video le variabili disponibili. Il comando non è presente di default in tutte le distribuzioni, ma si trova all’interno di un pacchetto denominato Net-SNMP mantenuto ufficialmente presso http://www.net-snmp.org (Figura 16.16). Nelle distribuzioni basate su RPM il pacchetto si chiama net-snmp-utils, mentre su Ubuntu il programa si trova dentro il pacchetto snmp.

Figura 16.16 Sito ufficiale di Net-SNMP.

Una volta installato è possibile interrogare subito un dispositivo fornendo semplici dettagli, come in questo esempio: snmpwalk -v1 -c public 192.168.100.11

La prima opzione, -v1, indica la versione di SNMP che si intende usare. In tutti gli esempi di questo libro si è fatto riferimento alla versione 1. Con l’opzione -c si fornisce la comunity name e infine si indica l’indirizzo IP del sistema da sondare. Premendo Invio si avrà una pagina con l’elenco delle variabili presenti, come nel caso seguente, che mostra la parte iniziale delle variabili di un sistema basato su Windows XP Professional: Listato 16.9

SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 7 AT/AT COMPATIBLE - Software: Windows 2000 Version 5.1 (Build 2600 Uniprocessor Free) SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.311.1.1.3.1.1 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (784387) 2:10:43.87 SNMPv2-MIB::sysContact.0 = STRING: SNMPv2-MIB::sysName.0 = STRING: SZANZI SNMPv2-MIB::sysLocation.0 = STRING: SNMPv2-MIB::sysServices.0 = INTEGER: 76 IF-MIB::ifNumber.0 = INTEGER: 2 IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.65539 = INTEGER: 65539 IF-MIB::ifDescr.1 = STRING: MS TCP Loopback interface IF-MIB::ifDescr.65539 = STRING: 3Com EtherLink XL 10/100 PCI For Complete PC Management NIC (3C905C-TX) IF-MIB::ifType.1 = INTEGER: softwareLoopback(24)

IF-MIB::ifType.65539 = INTEGER: ethernetCsmacd(6) IF-MIB::ifMtu.1 = INTEGER: 1520 IF-MIB::ifMtu.65539 = INTEGER: 1500 IF-MIB::ifSpeed.1 = Gauge32: 10000000 IF-MIB::ifSpeed.65539 = Gauge32: 100000000 IF-MIB::ifPhysAddress.1 = STRING: IF-MIB::ifPhysAddress.65539 = STRING: 0:a:5e:5f:58:ac IF-MIB::ifAdminStatus.1 = INTEGER: up(1) IF-MIB::ifAdminStatus.65539 = INTEGER: up(1) IF-MIB::ifOperStatus.1 = INTEGER: up(1) IF-MIB::ifOperStatus.65539 = INTEGER: up(1) IF-MIB::ifLastChange.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifLastChange.65539 = Timeticks: (0) 0:00:00.00 IF-MIB::ifInOctets.1 = Counter32: 834618

Ogni riga contiene una variabile. L’informazione è costituita dal nome della tabella MIB, seguita dal nome della variabile e dal suo valore. Per essere più chiari si consideri una riga estratta con il comando snmpwalk: IP-MIB::icmpOutDestUnreachs.0 = Counter32: 14

La variabile si chiama icmpOutDestUnreachs.0, appartiene alla tabella IP-MIB, è un contatore a 32 bit e contiene il valore 14. Se si volesse monitorare questo valore con MRTG, a questo punto si dovrebbe aprire il file di configurazione mrtg.cfg e modificare la riga che contiene il target in questo modo: Target[192.168.100.11_65539]: icmpOutDestUnreachs.0&icmpOutDestUnreachs.0:[email protected]:

Il nome della variabile deve essere indicato due volte, separato dal simbolo & in quanto MRTG cerca di mettere in relazione due valori quando genera i grafici (per esempio un valore in ingresso e uno in uscita). Se il valore è unico, è sufficiente indicarlo due volte. Lanciando il comando mrtg o programmandolo ogni 5 minuti si dovrebbe cominciare a vedere i nuovi dati. Le variabili da monitorare possono essere indicate anche in formato numerico, come in questo esempio di monitoraggio di carico della CPU su un Cisco PIX 501 (Figura 16.17): Target[pix_cpu]: 1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6&1.3.6.1.4.1.9.9.109.1.1.1.1.5.1: [email protected]:

Figura 16.17 Risultato del monitoraggio del carico CPU su un Cisco PIX.

Il file di configurazione di MRTG contiene molti aspetti che possono essere alterati. Per avere una comprensione dettagliata si consiglia di consultare la documentazione ufficiale del prodotto. In questa sede verranno esposti solo alcuni dei parametri. Per cominciare è importate rilevare che il file di configurazione contiene molti dettagli formattati in HTML. Tutti questi aspetti possono essere modificati liberamente come se si trattasse di un file html ordinario. Ogni oggetto monitorato dispone poi di una serie di opzioni. Ogni opzione è presente su una riga ed è costituita da una parola chiave, dall’indicazione dell’oggetto a cui fa riferimento e dalla sua specifica, come in questo esempio: Title[192.168.100.11_65539]: Traffic Analysis for 65539 -- SZANZI

L’opzione in questo caso si chiama Title ed è seguita dalle parentesi quadre. All’interno delle parentesi c’è l’indicazione dell’oggetto monitorato. I due punti separano il nome dell’opzione dal suo valore, in questo caso un testo libero. Qui di seguito sono elencate altre opzioni di uso comune: YLegend[id] Legenda per l’asse Y del grafico. Legend1[id] Legenda per i dati in ingresso (valore 1 del target). Legend2[id] Legenda per i dati in uscita (valore 2 del target). LegendI[id] Legenda per i dati in ingresso. LegendO[id] Legenda per i dati in uscita. MaxBytes Valore limite che sarà disegnato sul grafico.

Un’opzione importante è Options[id]. Questa modifica l’aspetto dei grafici in base al valore inserito: growright Il grafico si sviluppa nel tempo verso destra.

nopercent Disabilita la visualizzazione in percentuale dei dati. bitsConverte la visualizzazione dei dati in bit (per dati in byte). perminute Converte la visualizzazione dei dati in minuti (per dati in secondi). gauge Segnala che si stanno usando dati di tipo gauge.

Checklist 1. Tcpdump e IPTraf non richiedono operazioni particolari di configurazione. Viene perciò indicata la Checklist solo per MRTG. 2. Verificare la presenza di MRTG. Nel caso non sia disponibile, procedere alla sua installazione, utilizzando i dischi della propria distribuzione o il sito ufficiale. 3. Attivare il server web. 4. Modificare i criteri di sicurezza impostati nel file /etc/httpd/conf.d/mrtg.conf su CentOS. 5. Creare la configurazione di MRTG con il comando cfgmaker. 6. Inserire manualmente eventuali opzioni aggiuntive oppure modificare le opzioni esistenti. 7. Realizzare gli indici delle pagine web con il comando indexmaker. 8. Inserire il comando mrtg dentro una programmazione di sistema, per esempio dentro il crontab. 9. Accedere ai dati con il browser.

Capitolo 17

Capitolo 17 - Database relazionali con MySQL Un numero sempre crescente di applicazioni viene oggi realizzata con i paradigmi del Web. I programmi risiedono cioè su server centralizzati, accessibili agli utenti attraverso un normale browser. Sui client non è necessario installare alcun programma, evitando problemi di compatibilità con il sistema operativo, conflitti software e procedure di setup. Questa è certamente un’enorme comodità quando si intende essere capillari e raggiungere potenziali utenti privi di conoscenze, anche basilari, di informatica. Il lato client è perciò tutto all’insegna della semplicità, a differenza del lato server, che raccoglie invece la complessità sistemistica del progetto. È infatti necessario un ambiente idoneo, dotato almeno di un web server, come Apache, di un sistema di generazione dinamica delle pagine, per esempio PHP e di un database. I primi due elementi sono già stati trattati in questo volume. Non resta che installare il database e configurarlo come supporto per i dati di un generico applicativo web. Sarà anche illustrato come amministrare correttamente il sistema. Non sarà invece esposta la teoria dei database relazionali e la gestione dei dati, argomenti che esulano dagli scopi di questo volume.

Installazione di MySQL La piattaforma Linux è ricca di soluzioni database di qualità, alcune sviluppate in maniera professionale da aziende leader nel settore. Tra tutti spicca un prodotto che ha riscosso consensi in tutto il mondo e che vanta oggi clienti come VMware, LinkedIn, Nasa, Deutsche Post, New York Times, YouTube, Wikipedia e molti altri. Si tratta di MySQL, un database relazionale prodotto originariamente dalla svedese MySQL AB (www.mysql.com), ora parte di Oracle a seguito dell’acquisizione di Sun (Figura 17.1). Il valore di questo prodotto risiede nella qualità del software, nella sua diffusione e nella disponibilità di servizi commerciali per la consulenza e l’assistenza specialistica. Si tratta perciò di una soluzione capace di rispondere alle esigenze professionali.

Figura 17.1 Pagina ufficiale di MySQL.

MySQL è disponibile secondo due modelli di licenza: community e commerciale. La versione community del prodotto è fornita con licenza GPL e può essere usata liberamente per qualunque progetto personale o commerciale. Se però MySQL viene inglobato o compilato all’interno di un prodotto commerciale, sarà necessario acquistare una licenza d’uso o versare royalty. Questo vincolo riguarda però solamente le aziende che sviluppano soluzioni chiuse basate su MySQL e non gli utilizzatori, neppure quelli commerciali. Le versioni commerciali di MySQL hanno meccanismi di supporto e assistenza professionale e sono realizzate per operare in ambienti mission critical o che richiedono elevate prestazioni. In questo libro verrà sempre usata la versione GPL di MySQL, fornita senza alcun costo. MySQL può essere definito un database multipiattaforma: sul sito ufficiale è possibile scaricare il prodotto per i sistemi operativi Linux, Windows, Mac OS X, Solaris, FreeBSD, HP-UX, IBM i5/O e IBM AIX. Per Linux sono disponibili diverse versioni, a copertura delle distribuzioni più diffuse. Individuata la propria piattaforma, si può procedere alla fase di download, installazione e configurazione. L’installazione manuale di MySQL può essere un’impresa complessa e per questo si consiglia di usare la versione pacchettizzata adatta alla propria distribuzione. Questo semplifica notevolmente le operazioni, in quanto molte procedure critiche vengono eseguite automaticamente, mediante script di installazione. MySQL è generalmente presente nei dischi di installazione di Linux. Qualora non lo fosse o se la versione non risultasse aggiornata, è possibile collegarsi al sito ufficiale di MySQL, alla pagina web http://www.mysql.com/downloads/mysql e scaricare il prodotto.

Qualunque sia la modalità di installazione scelta (versione pacchettizzata o installazione manuale), bisogna ricordarsi di installare tutti i componenti. In alcune distribuzioni non basta il pacchetto mysql, in quanto la parte server si trova in un pacchetto a parte denominato mysql-server. Il sistema MySQL consta di diversi componenti, riportati in Tabella 17.1: Tabella 17.1

Componente

Contenuto

server

Componente server principale

client

Componente client

bench

Strumenti di becnhmark

devel

Librerie e header file

shared

Librerie dinamiche per il client

shared-compat Librerie dinamiche per il client delle versioni precedenti, fornite per compatibilità

L’installazione di MySQL crea le directory di servizio e copia i file necessari al funzionamento del programma. Il file principale di configurazione si trova in /etc/my.cnf nella CentOS e nelle distribuzioni basate su RedHat e in /etc/mysql/my.cnf su Ubuntu. All’interno di questo file sono specificati principalmente dei percorsi. Per cominciare può essere utile verificare la directory che contiene i dati (per default /var/lib/mysql) e la posizione dei file di log (/var/log/mysqld.log su CentOS, mentre su Ubuntu viene usato un demone Syslog per la raccolta dei log del database). Per attivare il servizio si deve digitare il comando seguente su CentOS: /etc/init.d/mysqld start

Su Ubuntu lo script di avvio del demone ha un nome differente, privo della d finale e si utilizza questa sequenza: /etc/init.d/mysql start

Se questo comando produce un errore, significa che non è installato il pacchetto server di MySQL. Come ulteriore verifica si può impartire il comando: mysqladmin version

Se tutto è configurato correttamente, si dovrebbe ottenere un output simile a questo: Listato 17.1

mysqladmin Ver 8.42 Distrib 5.1.41, for debian-linux-gnu on x86_64 Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license Server version 5.1.41-3ubuntu12.6 Protocol version 10

Connection Localhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 8 min 17 sec Threads: 1 Questions: 194 Slow queries: 0 Opens: 227 Flush tables: 1 Open tables: 55 Queries per second avg: 0.390

Per verificare il funzionamento del demone è anche possibile richiedere semplicemente lo stato al sistema: /etc/init.d/mysqld status

L’esempio è per CentOS. Su Ubuntu è possibile digitare questa sequenza per ottenere lo stesso risultato: service mysql status

Il demone di MySQL funziona all’interno del sistema operativo in base alle credenziali di un utente che viene creato in fase di installazione del pacchetto. Questo utente è denominato mysql ed è indicato anche nel file di configurazione. Per rendersene conto basta aprire il file /etc/my.cnf e controllare la voce user. Assieme all’utente mysql viene creato anche un gruppo denominato mysql. Il demone di MySQL deve essere attivato in fase di avvio del sistema tramite gli strumenti di gestione o con l’inserimento negli script di avvio.

Gestione degli utenti di MySQL I servizi di MySQL sono erogati a chiunque ne faccia richiesta, purché sia dotato di un account utente abilitato dall’amministratore e dotato di diritti ben precisi. Questo meccanismo di autenticazione permette di avere un numero elevato di utenze, ognuna con insiemi di dati indipendenti e protetti da password. Un unico sistema MySQL può in questo modo contenere dati relativi all’amministrazione dell’azienda, alle giacenze del magazzino, alle news relative a una web application, ai banner di un sistema pubblicitario online, all’agenda aziendale condivisa e così via. Ognuno di questi insiemi di dati risulta logicamente distinto e accessibile in maniera autonoma da utenti ben definiti. L’accesso completo a tutte le informazioni è riservato unicamente all’amministratore, che è la figura preposta alla gestione di MySQL, al controllo degli utenti del database e all’erogazione dei diritti di accesso. Questo utente si chiama root. È importante precisare che la gestione degli utenti e dei diritti di MySQL non si basa su meccanismi di autenticazione propri del sistema operativo, ma si avvale di un meccanismo interno: l’utente root del database non coincide con l’utente root di Linux e, viceversa, gli utenti creati in MySQL non corrispondono ad alcun utente di Linux. Il processo di installazione di MySQL provvede a creare due account di amministrazione, due account anonimi e alcune tabelle di prova. Gli account anonimi non hanno diritti amministrativi, ma possono accedere alle tabelle di test create di default dal programma. Questi account permettono di rendere immediatamente operativo ogni sistema MySQL. È quindi possibile eseguire subito dei test oppure installare applicativi che necessitano del database per funzionare. Non è tuttavia sicuro operare in questa maniera, poiché gli account di amministrazione predefiniti non possiedono password: chiunque potrebbe dunque accedere a MySQL e avere pieni poteri. In alcune distribuzioni il sistema viene installato con una password di default. In Ubuntu si ha come password la parola password. Si tratta chiaramente di una password debole che deve in ogni caso essere cambiata. Gli accessi non sono regolati solo in base al nome dell’utente. È infatti possibile stabilire politiche di accesso differenti in base all’host da cui l’utente si sta collegando: l’utente root connesso da localhost

potrebbe avere pieni poteri, mentre i diritti dell’utente root connesso da un’altra ubicazione potrebbero essere limitati. Questa forma di controllo avviene associando al nome utente l’indicazione dell’host di provenienza, per esempio root@localhost. È anche possibile configurare forme di accesso di tipo anonimo al database, in cui si permette l’ingresso a chiunque, qualunque sia il suo dominio di origine.

Sicurezza di base Per cominciare è bene proteggere l’account superuser di MySQL con una password. L’utente superuser è denominato root, ma non ha alcuna attinenza con l’omonimo utente di sistema Linux. Il comando per impostare la password è il seguente: mysqladmin -u root password

La nuova parola d’accesso dovrà essere inserita al posto di . Premendo Invio si applicherà subito la modifica. È possibile specificare anche l’host di provenienza a cui si riferisce l’utente, usando l’opzione -h, come nel seguente esempio: mysqladmin -u root -h localhost password

È possibile modificare una password impostata precedentemente indicando la vecchia password e la nuova da riga di comando: mysqladmin -u root -p

Verrà richiesta la password corrente prima di poter eseguire la modifica. È consigliabile impedire l’accesso anonimo al database. Per farlo si può utilizzare il client testuale di MySQL, eliminando le credenziali degli utenti anonimi. Il client testuale si chiama mysql e costituisce il modo più diretto e veloce per gestire il server del database. Per usarlo si deve digitare mysql seguito da alcuni parametri, come si può vedere di seguito: mysql -u root -p mysql

Il parametro -u indica l’utente che si vuole usare per l’accesso, mentre il parametro -p segnala l’intenzione di specificare la password. La stringa che segue -p non è la password, ma il nome del database che si vuole aprire. In questo caso il database mysql, che contiene informazioni sul sistema come gli utenti di MySQL e i loro privilegi, gli host e così via. In precedenza si era specificato che la gestione degli utenti è interna a MySQL: ora si può verificare dove sono effettivamente memorizzati i dati di servizio e i profili utente. Premendo Invio verrà richiesta la password per l’utente root, che è stata impostata in precedenza: se la password digitata è corretta, si entrerà in una shell da cui sarà possibile impartire comandi per lavorare con il database. Per eliminare gli utenti anonimi si usa la seguente sintassi: DELETE FROM user WHERE User = ''; FLUSH PRIVILEGES;

Attenzione a utilizzare due virgolette singole ('') e non le virgolette doppie ("), nella direttiva DELETE. Per uscire dal client mysql e tornare nella shell di Linux si deve digitare il comando exit e premere Invio. Per garantire un livello minimo di sicurezza, bisogna controllare anche che MySQL venga sempre eseguito

sul sistema operativo da un utente di Linux differente da root. In caso contrario, un utente definito in MySQL con accesso ai file sarebbe abilitato a modificare qualsiasi file del computer che ospita MySQL. Tutti i file di MySQL dovrebbero essere protetti, assegnando diritti tali per cui solo root e gli utenti del gruppo mysql possano avere accesso a essi; questo impedisce che altri utenti del server che ospita MySQL possano modificare le configurazioni del database.

Gestione del database Il client testuale mysql permette di svolgere molte operazioni, tra cui elencare i database attivi sul sistema: show databases;

L’output, per una nuova installazione, sarà il seguente: +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | test | +--------------------+ 3 rows in set (0.00 sec)

Per passare da un database a un altro, scegliendo per esempio mysql, si usa il comando USE: USE mysql;

L’elenco delle tabelle presenti può essere visualizzato con il comando SHOW TABLES: SHOW TABLES;

In una nuova installazione, l’output si presenta come segue: +---------------------------+ | Tables_in_mysql | +---------------------------+ | columns_priv | | db | | func | | help_category | | help_keyword | | help_relation | | help_topic | | host | | proc | | procs_priv | | tables_priv | | time_zone | | time_zone_leap_second | | time_zone_name | | time_zone_transition | | time_zone_transition_type | | user |

+---------------------------+ 17 rows in set (0.00 sec)

Per visualizzare gli utenti, gli host e le password presenti nella tabella user si utilizza il comando SELECT: SELECT user,host,password FROM user;

Si avrà un output simile a questo: +------+-----------+------------------+ | user | host | password | +------+-----------+------------------+ | root | localhost | 79665ea20ea26c16 | | root | linuxcage | | | root | 127.0.0.1 | | +------+-----------+------------------+ 3 rows in set (0.00 sec)

Per motivi di sicurezza, le password presenti nella tabella sono memorizzate in maniera cifrata. In questo caso si può notare che non è stata impostata alcuna password per l’utente root proveniente dall’host linuxcage e 127.0.0.1. Si deve subito provvedere utilizzando il comando mysqladmin visto in precedenza, impiegando l’opzione -h per specificare l’host. Per creare un nuovo database si usa la direttiva CREATE DATABASE: CREATE DATABASE rubrica;

Sul nuovo database è possibile inserire tabelle e dati, dopo aver comunicato a MySQL l’intenzione di usare il database rubrica: USE rubrica;

Se si vuole creare una tabella chiamata contatti, per realizzare una rubrica telefonica, si dovranno prevedere le colonne per inserire il nome, il cognome e il numero di telefono di ogni persona: CREATE TABLE contatti (nome_id TEXT, cognome_id TEXT NOT NULL, numero_id TEXT NOT NULL);

All’interno delle parentesi sono specificate le righe che si vogliono creare: nome_id, cognome_id e numero_id, tutte di tipo text; cognome_id e numero_id non possono essere vuoti (da cui la specifica NOT NULL). Durante la digitazione di comandi si può andare a capo su più righe. Il client mysql riconosce la conclusione di un singolo comando su più righe tramite il segno di punto e virgola (;). Solo a seguito di questo carattere il tasto Invio provoca l’esecuzione della sequenza inserita. A questo punto si può riempire la tabella contatti, sempre dall’interno della shell del client mysql. Ci sono diversi modi per farlo, ma per tabelle piccole la sintassi utilizzata di seguito è la più rapida: INSERT INTO contatti VALUES ('Paolo ','Rossi ', '0123-123456');

Nel caso non si voglia riempire una colonna si può inserire l’indicazione NULL. Nell’esempio che segue, in rubrica viene inserito solo il cognome e il numero di telefono: INSERT INTO contatti

VALUES (NULL, 'Verdi', '0123-654321');

Per visualizzare il contenuto della tabella contatti si può creare una query: SELECT * FROM contatti;

Si avrà l’output indicato si seguito: +---------+------------+-------------+ | nome_id | cognome_id | numero_id | +---------+------------+-------------+ | Paolo | Rossi | 0123-123456 | | NULL | Verdi | 0123-654321 | +---------+------------+-------------+ 2 rows in set (0.00 sec)

L’accesso fino a questo punto è stato eseguito attraverso il superuser root di MySQL. Questo è corretto per le operazioni di amministrazione, ma non si può pensare di creare database per scopi aziendali o come supporto per altri programmi e fornire le credenziali di root per l’accesso e l’uso ordinario. Si devono piuttosto creare utenze specifiche e impostare i soli diritti di accesso ai database di pertinenza. Per assegnare pieni diritti al database rubrica all’utente ufftec1 che si connette al database da localhost, si usa questa sequenza: grant all privileges on rubrica.* to ufftec1@localhost identified by 'password';

La password va indicata tra singoli apici. La parola chiave all privileges assegna tutti i diritti previsti da MySQL. In alternativa è possibile inserire i privilegi in maniera granulare, come in questo esempio: grant select, insert, update, create, delete on rubrica.* to ufftec1@localhost identified by 'password';

I privilegi possibili sono all privileges, file, reload, alter, index, select, create, insert, shutdown, delete, process, update, drop, references e usage. Una volta impostati i diritti bisogna invocare questo comando: flush privileges;

Per cancellare un privilegio assegnato si usa invece questo comando: revoke all privileges on rubrica.* from uffetec1@localhost; flush privileges;

In questo caso sono stati revocati tutti i privilegi di ufftec1 che si collega da localhost al database rubrica.

Attenzione al fatto che la sequenza di cui sopra non elimina l’utente dalla tabella user del database di sistema di MySQL. Bisognerà provvedere all’esplicita cancellazione. delete from user where user = 'ufftec1';

Conclusi i test si possono cancellare la tabella contatti e il database rubrica: DROP TABLE contatti; DROP DATABASE rubrica;

Questi esempi evidenziano che l’amministrazione del database attraverso il client testuale comporta l’utilizzo di comandi specifici di MySQL e di direttive del linguaggio SQL, lo standard per l’interrogazione dei database. Se si è interessati ad approfondire l’argomento, si consiglia l’acquisto di un libro specifico sul linguaggio SQL e la consultazione del manuale di MySQL all’indirizzo web http://dev.mysql.com/doc/mysql/en/index.html. Va puntualizzato che è possibile usare MySQL come supporto di memorizzazione dei dati per le applicazioni pur non conoscendo i dettagli tecnici dei database. I programmi di terze parti che usano MySQL come infrastruttura dispongono di procedure di installazione che provvedono alla creazione dei database e delle tabelle necessarie al loro funzionamento. Le impostazioni principali saranno quindi a carico del pacchetto di installazione o di script realizzati appositamente per questo scopo. Tutte le operazioni di accesso ai dati, in fase di funzionamento dell’applicativo, saranno realizzate tramite comandi codificati all’interno di pagine web dinamiche, quindi in maniera trasparente all’utente. L’amministratore del server potrà in tal caso limitarsi ad assegnare le password agli account di default, a gestire gli utenti, a provvedere all’aggiornamento del sistema e a visionare i bollettini di sicurezza per controllare la presenza di nuovi bug o falle critiche. Non si tratta della soluzione ottimale, in quanto è sempre meglio conoscere gli strumenti che si utilizzano, ma in questo modo si garantisce un livello minimo di servizio e di protezione dagli attacchi più banali. Ci sono infine alcuni dettagli importanti da tenere in considerazione. Ogni volta che si installa un’applicazione basata su MySQL bisogna controllare che gli eventuali nuovi utenti creati non abbiano privilegi “eccessivi”: i programmi di terze parti dovrebbero in realtà avere accesso solamente al database che utilizzano. Gli altri database e la tabella user del database mysql dovrebbero invece essere interdetti. Attenzione anche alle porte: se MySQL si trova sullo stesso server in cui è installato Apache è possibile impedire l’accesso a MySQL dall’esterno, impostando sul firewall un filtro in ingresso alla porta 3306. Molti di questi problemi di sicurezza possono essere evitati ricorrendo a un servizio di hosting esterno per le proprie applicazioni web; in tal caso il sistema sarà protetto da sistemisti esperti, che provvederanno a limitare l’accesso ai soli database personali e ad applicare gli aggiornamenti con regolarità.

Eseguire il backup di un database MySQL dispone di un meccanismo per la copia su file di tutti i dati presenti all’interno di un database. Questa operazione avviene sulla shell dei comandi di Linux usando il comando mysqldump, fornito con i pacchetti ufficiali di MySQL. La sintassi è molto semplice, come si può evincere da questo esempio: mysqldump contab -u root -p > filebackup.txt

Il nome contab è indicato a titolo di esempio. Al suo posto si deve scrivere il nome del database che si desidera salvare. Il parametro -u serve a indicare l’utente attraverso cui connettersi a MySQL, in questo caso root, mentre con -p si indica che la password verrà inserita manualmente dopo l’invio. La riga prosegue con un segno di maggiore (>). Si tratta di una sintassi standard di Linux per richiedere il redirect dell’output. Si vuole cioè trasferire sul file filebackup.txt tutto l’output testuale generato dal comando mysqldump. Il comando non genera infatti un backup binario del database, ma una sequenza di comandi SQL che, se eseguiti, sono in grado di ricreare la struttura del database salvato e il relativo contenuto. È sufficiente, a questo punto, mettere al riparo il file filebackup.txt per avere una copia di sicurezza del database. In caso di crash del sistema o di danno al database è possibile rigenerare i dati in maniera molto veloce. Si deve partire da una situazione vergine, ovvero da un’installazione nuova di MySQL oppure da un’installazione

priva di dati. Si deve entrare con il client testuale mysql e bisogna creare con i comandi visti in precedenza un database vuoto avente lo stesso nome del database che si ha la necessità di ripristinare: CREATE DATABASE contab;

A questo punto si esce con il comando quit e si carica il file testuale salvato in precedenza con la seguente sintassi: mysql contab -u root -p < filebackup.txt

Il client testuale mysql entrerà come utente root e riceverà in ingresso, per via dell’uso del carattere minore ( open (to) ftp.incipit.biz Connected to ftp.incipit.biz. 220 Welcome to Incipit S.r.l. FTP service 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type Name (ftp.incipit.biz:root): szanzi 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 227 Entering Passive Mode 150 Here comes the directory listing. drwxr-xr-x 2 0 0 4096 Sep 28 10:05 configurazioni -rw-r--r-- 1 0 0 252 Sep 28 10:05 manuale_res.txt -rw-r--r-- 1 0 0 252 Sep 28 10:04 res1.src -rw-r--r-- 1 0 0 252 Sep 28 10:05 res10.zip drwxr-xr-x 2 0 0 4096 Sep 28 10:05 sviluppo drwxrwxr-x 2 500 500 4096 Feb 03 2006 test 226 Directory send OK. ftp> binary 200 Switching to Binary mode. ftp> get (remote-file) res10.zip (local-file) /home/szanzi/res10.zip local: /home/szanzi/res10.zip remote: res10.zip 227 Entering Passive Mode 150 Opening BINARY mode data connection for res10.zip (252 bytes). 226 File send OK. 252 bytes received in 7.6e-05 seconds (3.2e+03 Kbytes/s) ftp> quit 221 Goodbye.

In questa sessione viene eseguito il log-in al sistema FTP, vengono fornite le credenziali dell’utente szanzi, viene visualizzata la lista dei file con ls e infine è richiesto il trasferimento di res10.zip dal file system remoto al sistema locale. La sessione viene infine chiusa con il comando quit. Si può notare la scelta dei progettisti di FTP di creare una shell specifica e di dotare il sistema di un ampio insieme di comandi. Questi comandi sono standardizzati su tutti i sistemi FTP, ma gli implementatori possono arricchire il sistema attraverso comandi aggiuntivi. In altri casi viene eseguita un’operazione inversa, riducendo il numero dei comandi disponibili per semplificare l’implementazione o per renderla più veloce da sviluppare. Qui di seguito è riportato l’elenco dei comandi per un’implementazione FTP su Unix. Listato 20.2

ftp> ? Commands may be abbreviated. Commands are: ! cr mdir proxy send $ delete mget sendport site account debug mkdir put size append dir mls pwd status ascii disconnect mode quit struct bell form modtime quote system binary get mput recv sunique bye glob newer reget tenex case hash nmap rstatus trace ccc help nlist rhelp type cd idle ntrans rename user cdup image open reset umask chmod lcd passive restart verbose clear ls private rmdir ? close macdef prompt runique cprotect mdelete protect safe

Modalità operative FTP utilizza il protocollo TCP per operare, impiegando la porta 20 per il trasferimento dei dati e la porta 21 per lo scambio dei comandi. Le operazioni iniziano sul lato client, quando viene invocato il protocollo dall’utente. Il client si collega alla porta comandi (21/TCP) del server FTP specificato, usando una porta locale alta, oltre la 1023. Tra le prime informazioni scambiate vi è la porta dati scelta dal client, generalmente la porta successiva alla porta comandi dati aperta dal client. Il server utilizzerà questa informazione per istituire una connessione TCP verso il client. A questo punto vi saranno due canali attivi, uno per la gestione dei comandi e un altro per l’inoltro dei dati. In questo modo il sistema FTP è attivato ed è possibile trasferire file. Questa modalità è definita attiva ed è la modalità classica con sui si gestisce una comunicazione FTP tra client e server. Vi è però una difficoltà con questa modalità operativa. Il client inizia la comunicazione aprendo un canale comandi verso il server remoto. Il secondo canale, dedicato ai dati, è invece inizializzato dal server, il quale apre una connessione verso il client usando la porta comunicata all’inizio della sessione. Questo scenario non è in genere compatibile con le policy applicate sui firewall perimetrali o sui firewall installati a protezione dei client. Oggi è una consuetudine diffusa interdire qualunque comunicazione TCP che sia iniziata dal mondo esterno. Si presume infatti che le uniche comunicazioni in ingresso verso un client debbano essere state inizializzate dal client stesso. Le postazioni utente, a differenza dei server, non dovrebbero offrire servizi al mondo esterno. Un tentativo di accesso iniziato dall’esterno potrebbe quindi rappresentare un attacco. Questa politica di protezione è ragionevole e dovrebbe essere impiegata di default, ma comporta problemi per FTP. Dal momento che non è possibile iniziare una connessione dall’esterno, il canale dati non sarà mai istituito e non sarà possibile eseguire alcun trasferimento dati. L’utente osserverà l’istituzione del canale comandi e sperimenterà un’attesa prolungata prima che un contatore di timeout resetti la connessione FTP con un messaggio d’errore. Il problema è stato risolto con l’estensione dello standard FTP introducendo una nuova modalità operativa definita passiva. All’inizio della sessione FTP, il client apre due porte consecutive, nel range superiore alla porta 1023. Una porta è dedicata ai comandi, mentre l’altra ai dati. Subito dopo, il client attiva una comunicazione TCP verso la porta 21 del server, per lo scambio dei comandi. Il server risponde comunicando il numero di porta aperto sul server per lo scambio dei dati per la sessione in corso. Questa non sarà la 20/TCP, ma una porta alta, superiore alla 1023. Il client utilizzerà questa informazione per aprire il canale tra la porta 20/TCP locale e il server. In questo modo entrambi i canali risulteranno inizializzati dal client e non vi saranno problemi nelle politiche del firewall locale. Il server rileverà invece due connessioni TCP iniziate dall’esterno, ma si tratterà in tal caso di una situazione normale per un server. I server erogano servizi ed è naturale che ricevano connessioni dalla Rete. Per quanto riguarda il firewall a protezione del server si dovranno chiudere le porte basse, inferiori o uguali alla 1023, tranne quelle che svolgono servizi pubblicati all’esterno. In questo esempio dovranno essere attive le porte 20/TCP e 21/TCP (FTP in modalità attiva), oltre alle porte di altri eventuali servizi attivi, per esempio un server web. Dovranno essere aperte anche le porte generiche dalla 1024 in su, attraverso cui arriveranno le comunicazioni dati per la modalità FTP passiva. Se questo aspetto risulta eccessivo e si preferisce chiudere tutte le porte che non erogano servizi, si dovrà limitare la funzionalità FTP alla modalità attiva, consci del fatto che molti client non saranno in grado di accedere. I client sono configurati di default per operare in una delle due modalità e non esiste un passaggio automatico da una all’altra. Questa deve essere attivata, se necessario, con uno specifico comando o da un’impostazione di configurazione del client.

Installare il server FTP Il sistema server che ha acquisito fama negli anni per via delle prestazioni e la sicurezza (Figura 20.1).

FTP

Figura 20.1 Sito ufficiale di vsftpd.

L’aspetto della sicurezza è talmente centrale nello sviluppo di questo progetto, che il nome stesso del prodotto intende sottolineare questo concetto. Le prime due lettere, “vs”, sono la riduzione di “very secure”. Il prodotto ha effettivamente un buon record in termini di sicurezza, soprattutto se comparato con alcuni diretti concorrenti che hanno evidenziato invece una serie di problemi di architettura o di programmazione, tali da comportare intrusioni o utilizzo fraudolento del file system ospite. Non si tratta di un problema di poco conto. Si pensi solo all’eventualità che un utente malintenzionato possa ottenere accesso al sistema FTP per memorizzare materiale collegabile alla pedofilia, sistemi per il furto di credenziali oppure opere protette da copyright. Se l’utente malintenzionato si comporta in maniera sufficientemente “silenziosa” potrebbe sfruttare il server FTP per mesi prima di essere individuato. I risultati in termini di sicurezza sono stati ottenuti attraverso una progettazione attenta e uno sviluppo con tecniche idonee a limitare le vulnerabilità tipiche di molti prodotti, come i buffer overflow. Viene inoltre limitato l’uso dell’utente root durante il funzionamento del demone e si fa largo utilizzo di metodologie sistemistiche, quali le gabbie chroot. Un ulteriore aspetto interessante è il fatto che l’autore, Chris Evans, è un ricercatore nell’ambito della sicurezza informatica, con un interessante curriculum di scopritore di bachi critici in software di terze parte. vsftpd è perciò una buona scelta per chiunque intenda mettere in atto un sistema di distribuzione file basato su FTP. Naturalmente il prodotto non può essere ritenuto intrinsecamente sicuro. È importante, come sempre, realizzare buone configurazioni e aggiornare il software con tutti gli update messi a disposizione dall’autore. Il software vsftpd è presente all’interno dei CD-ROM e dei repository delle distribuzioni di maggiore diffusione. Per installare il sistema su una distribuzione basata su Red Hat, come per esempio CentOS, è sufficiente eseguire questa sequenza: yum install vsftpd

Mentre su una distribuzione basata Debian, come Ubuntu, si utilizza questo comando: apt-get install vsftpd

L’operazione risulta molto veloce per via della leggerezza del software.

Configurazione di vsftpd La configurazione del server FTP avviene tramite il file vsftpd.conf presente in /etc su Ubuntu e in /etc/vsftpd su CentOS. Questo ha la struttura tipica di un file di configurazione su Unix, con una serie di parole chiave intramezzate da una breve descrizione delle voci. Il file contiene una serie non esaustiva di opzioni, sufficiente per avere una installazione funzionante. In realtà vi sono molte più opzioni, utili per situazioni particolari o per attivare funzionalità evolute. Per un elenco completo si consiglia di visionare il manuale all’indirizzo http://vsftpd.beasts.org/vsftpd_conf.html. Si ricorda inoltre che vsftpd utilizza valori di default per le opzioni di configurazione. Tutte le voci non impostate nel file di configurazione assumeranno quindi i valori prescelti dallo sviluppatore. Qui di seguito sono indicati i parametri che andrebbero impostati per ottenere un buon livello di sicurezza. # Allow anonymous FTP? (Beware - allowed by default if you comment this out). anonymous_enable=NO

Gli anonymous sono utenti che possono accedere all’area FTP senza fornire credenziali precedentemente impostate dall’amministratore. Questa possibilità andrebbe disabilitata, a meno che non si voglia esplicitamente creare un’area file pubblica. # Uncomment this to allow local users to log in. local_enable=YES

Questa è una “sicura” per impedire che gli utenti possano collegarsi al sistema FTP appena questo è installato. Ciò significa che è sempre necessario editare il file di configurazione almeno una volta e togliere il commento da questo parametro per abilitare l’accesso. # Uncomment this to enable any form of FTP write command. write_enable=YES

È possibile interdire la scrittura nell’area FTP da parte degli utenti. Questo può essere utile nel caso si stia creando un’area pubblica dove sia possibile eseguire solo il download di software. Non avrebbe senso in questo caso fornire la possibilità di scrittura nel file system. Se invece sussiste la necessità di modificare il contenuto dell’area FTP da parte degli utenti abilitati, si deve togliere il commento da questa riga. # Default umask for local users is 077. You may wish to change this to 022, # if your users expect that (022 is used by most other ftpd's) local_umask=077

Il parametro local_umask serve per specificare la maschera di bit da utilizzare per la scrittura di file sul file system da parte degli utenti connessi. # Uncomment this to allow the anonymous FTP user to upload files. This only # has an effect if the above global write enable is activated. Also, you will # obviously need to create a directory writable by the FTP user. #anon_upload_enable=YES

Se si è attivata la possibilità di accesso anonimo, si può specificare se gli utenti hanno il diritto di inviare file. In tal caso si deve togliere il commento da questa riga e abilitare l’opzione write_enable esaminata in precedenza. # Uncomment this if you want the anonymous FTP user to be able to create # new directories. #anon_mkdir_write_enable=YES

Quest’opzione si riferisce sempre agli utenti anonimi e permette, se si toglie il commento, la creazione di nuove directory da parte di questi utenti. # Activate logging of uploads/downloads. xferlog_enable=YES

L’opzione in oggetto mantiene una traccia delle operazioni di trasferimento avvenute all’interno del server FTP presso /var/log/vsftpd. Si consiglia di attivare questa funzionalità. # It is recommended that you define on your system a unique user which the # ftp server can use as a totally isolated and unprivileged user. #nopriv_user=ftpsecure

Per default, vsftpd utilizza l’utente nobody durante il funzionamento. È consigliabile creare un utente privo di privilegi specifici, da dedicare esclusivamente al funzionamento del servizio FTP. Una volta creato questo utente, è possibile specificare il nome in vsftpd.conf tramite questa voce di opzione. # You may fully customise the login banner string: ftpd_banner=Welcome to Incipit S.r.l. FTP service

Questa voce di configurazione è puramente informativa e permette di specificare la riga di testo che comparirà ogni volta che un utente otterrà accesso al sistema FTP. # You may specify an explicit list of local users to chroot() to their home # directory. If chroot_local_user is YES, then this list becomes a list of # users to NOT chroot(). #chroot_list_enable=YES # (default follows) #chroot_list_file=/etc/vsftpd/chroot_list

Una funzionalità interessante di vsftpd consiste nella possibilità di eseguire in automatico la funzione di chroot degli utenti. Questa opzione confina cioè gli utenti all’interno delle rispettive home dir di Unix impedendo che questi possano risalire la gerarchia del file system e visitare il sistema. Eliminando il commento dall’opzione chroot_list_enable=YES si può specificare l’elenco degli utenti da “ingabbiare” dentro il file indicato dall’opzione successiva chroot_list_file. In alternativa è possibile utilizzare un’opzione più generica: chroot_local_user=YES

In questo modo tutti gli utenti saranno confinati in chroot dentro le rispettive directory utente. È possibile specificare quali utenti possono collegarsi e quali hanno l’accesso negato a FTP, a prescindere dallo stato del loro account Linux. Questo può essere utile per interdire utenti indesiderati o per incrementare la sicurezza, impedendo, per esempio, che l’utente root possa accedere. Il fatto che le credenziali siano scambiate in chiaro in FTP dovrebbe essere un fattore sufficiente per impedire qualunque accesso al superuser. Un utente malintenzionato in ascolto passivo potrebbe carpire facilmente la password di sistema e violare la macchina. Per attivare questa funzionalità si utilizza il comando seguente: userlist_enable=YES

Il demone vsftpd caricherà quindi il file di testo specificato nella riga userlist_file, contenente l’elenco degli utenti interdetti. È fondamentale verificare che l’opzione sia specificata nel file di configurazione di vsftpd e che il file sia presente nel percorso indicato. In molte distribuzioni il file è già preimpostato, come nell’esempio seguente: Listato 20.3

# vsftpd userlist # If userlist_deny=NO, only allow users in this file # If userlist_deny=YES (default), never allow users in this file, and # do not even prompt for a password. # Note that the default vsftpd pam config also checks /etc/vsftpd/ftpusers # for users that are denied. root bin daemon adm lp sync shutdown halt mail news uucp operator games nobody

utilizzato

in

questo

capitolo

è vsftpd

(http://vsftpd.beasts.org),

un

prodotto

È interessante notare che il meccanismo di interdizione funziona subito dopo l’inserimento dello user-name. Se l’id non è autorizzato, non sarà richiesta la password e la connessione sarà subito terminata, prevenendo l’invio di una password in chiaro sulla rete. È possibile invertire la logica di funzionamento dell’opzione userlist_enable utilizzando questa sequenza: userlist_deny=NO

In questo modo tutti gli utenti saranno interdetti, tranne quelli specificati nel file indicato dal comando userlist_file. La configurazione generale è terminata e si può avviare il servizio usando questa sintassi: /etc/init.d/vsftpd start

Gestire correttamente gli utenti A questo punto potranno accedere gli utenti anonimi, se abilitati, e gli utenti definiti sul sistema Linux locale e che non sono indicati nel file di interdizione. Per attivare nuovi utenti è sufficiente definirli all’interno del sistema Linux attraverso i comandi di sistema, come nell’esempio seguente: useradd szanzi passwd szanzi

Il primo comando crea l’utente nel sistema, mentre il secondo imposta la password. È fondamentale che le password non siano banali, che non siano identiche allo username e che non siano parole comuni. Su Internet esiste un rumore di fondo costituito da sistemi automatici che tentano di accedere ai sistemi Unix remoti inserendo continuamente username e password banali. Se nel proprio sistema è attivato un account debole (per esempio user-id test e password test), si potrà essere certi che qualcuno tenterà di accedervi sfruttando questa leggerezza. Si deve anche considerare che se è attivo un accesso SSH dall’esterno, gli account creati per accedere in FTP potranno anche essere usati per fare log-in alla shell di sistema. L’esempio qui seguente è l’estratto del log di sicurezza di un server Linux connesso a Internet. Questa è solo una minima parte del log, ma evidenzia chiaramente il tentativo di accesso da parte di utenti malintenzionati esterni usando user-id e password banali. I tentativi sono distribuiti su tutta la giornata, sette giorni alla settimana, settimana dopo settimana fino a coprire l’intero anno. È difficile mantenere l’integrità del server in un simile contesto se non si hanno password sicure. L’indirizzo IP di provenienza è stato oscurato con la stringa xxx.xxx.xxx.xxx. Listato 20.4

Sep 28 13:53:58 marte sshd[12645]: Invalid user gnuworld from ::ffff:xxx.xxx.xxx.xxx Sep 28 13:54:00 marte sshd[12647]: Invalid user brian from ::ffff:xxx.xxx.xxx.xxx Sep 28 13:54:00 marte sshd[12645]: Failed password for invalid user gnuworld from ::ffff:xxx.xxx.xxx.xxx port 50862 ssh2 Sep 28 13:54:02 marte sshd[12647]: Failed password for invalid user brian from ::ffff:xxx.xxx.xxx.xxx port 54306 ssh2 Sep 28 13:54:03 marte sshd[12650]: Invalid user gnuworld from ::ffff:xxx.xxx.xxx.xxx Sep 28 13:54:05 marte sshd[12652]: Invalid user brian from ::ffff:xxx.xxx.xxx.xxx Sep 28 13:54:05 marte sshd[12650]: Failed password for invalid user gnuworld from ::ffff:xxx.xxx.xxx.xxx port 50985 ssh2 Sep 28 13:54:07 marte sshd[12652]: Failed password for invalid user brian from ::ffff:xxx.xxx.xxx.xxx port 40573 ssh2 Sep 28 13:54:08 marte sshd[12654]: Invalid user testuser from ::ffff:xxx.xxx.xxx.xxx Sep 28 13:54:10 marte sshd[12656]: Invalid user balloon from ::ffff:xxx.xxx.xxx.xxx Sep 28 13:54:10 marte sshd[12654]: Failed password for invalid user testuser from ::ffff:xxx.xxx.xxx.xxx port 55216 ssh2 Sep 28 13:54:12 marte sshd[12656]: Failed password for invalid user balloon from ::ffff:xxx.xxx.xxx.xxx port 40699 ssh2 Sep 28 13:54:59 marte sshd[12700]: Invalid user router from ::ffff: xxx.xxx.xxx.xxx Sep 28 13:55:02 marte sshd[12700]: Failed password for invalid user router from ::ffff: xxx.xxx.xxx.xxx port 56479 ssh2 Sep 28 13:56:15 marte sshd[12759]: Invalid user ircd from ::ffff: xxx.xxx.xxx.xxx Sep 28 13:56:17 marte sshd[12759]: Failed password for invalid user ircd from ::ffff: xxx.xxx.xxx.xxx port 43755 ssh2 Sep 28 13:56:19 marte sshd[12761]: Failed password for ftp from ::ffff: xxx.xxx.xxx.xxx port 58372 ssh2

È consigliabile configurare opportunamente il servizio SSH per limitarlo a una rosa di utenti ben definita oppure creare gli utenti con la seguente sintassi: useradd szanzi -s /sbin/noshell

Il comando crea l’utente szanzi, ma senza una shell di default grazie al parametro -s /sbin/noshell. I tentativi di accesso in locale al terminale o in SSH non saranno in questo modo soddisfatti, mentre si potrà accedere in FTP.

Checklist 1. Verificare che vsftpd sia installato nel sistema. Nel caso non lo sia, si deve eseguire l’installazione utilizzando il sistema di gestione dei pacchetti della propria distribuzione. 2. Aprire il file vsftpd.conf ed eseguire le opportune configurazioni, ricordandosi di attivare la funzionalità di chroot. 3. Creare l’elenco degli utenti interdetti. 4. Creare col commando useradd gli utenti abilitati ad accedere nel sistema in FTP. 5. Attivare il demone vsftpd. 6. Aprire sul firewall a protezione del server FTP le porte 20/TCP, 21/TCP e le porte TCP superiori alla 1023 per lo scambio dei dati in modalità passiva.

Capitolo 21

Capitolo 21 - Virtualizzazione con XenServer Nel corso degli anni Novanta e di buona parte dei primi anni di questo secolo l’industria ha profuso ampi sforzi per materializzare tecnologie in grado di dare potenza e centralità al personal computer, la singola postazione in grado di far girare programmi sempre più potenti, possibilmente in concomitanza con altri programmi altrettanto ricchi e complessi. L’obiettivo era quello di emancipare l’utente, in quanto individuo fruitore e renderlo indipendente come mai era capitato nei decenni precedenti, quando l’elaborazione era per necessità centralizzata. In quel periodo, non si poteva fare altro che usare un terminale “stupido” per accedere al nodo di elaborazione e ai dati. Vi era talmente poca potenza di calcolo, erogata paradossalmente da un hardware con un’impronta fisica così voluminosa, che non si poteva certo pensare di avere macchine di tipo personale. Non era solo un problema di costi “iniziali”. Quasi nessuno al mondo poteva permettersi di impegnare una palazzina intera per un singolo computer, bollette dell’elettricità e fattura della manutenzione a parte. Questo contesto tecnologico aveva creato colossi industriali di grande potenza finanziaria, impossibili da rovesciare con uno scontro diretto. È in un panorama industriale così consolidato e irraggiungibile che inizia la rivoluzione dei piccoli, nei garage di casa, negli uffici sparsi a sud della baia di San Francisco e nei sogni di tante persone uscite dalle vitali università della California. In poco tempo questa energia prende forma e convince i primi utenti, i quali innescano un effetto domino che porterà un flusso crescente di nuovi acquirenti. Nel giro di trent’anni si passa da un pugno di entusiasti dell’elettronica a un pubblico globale e variegato. Il risultato è sotto gli occhi di tutti: informatica di alto livello, spinta dentro volumi fisici minimali. Macchine con potenze immense a costi bassi e accessibili e la promessa di prestazioni raddoppiate ogni diciotto mesi. Informatica ovunque: sulla scrivania, in salotto, in auto e in un numero crescente di oggetti. Perfino i mouse da pochi euro contengono un microprocessore, della memoria e un programma di funzionamento. Così tanta potenza sulle scrivanie, sulle ginocchia dei pendolari in treno, negli zaini oppure nelle tasche di chi si muove sempre con uno smartphone e poi sui nuovi tablet, nelle console sempre più avanzate e nei luoghi dove non si pensa neppure che vi sia un computer. C’è talmente tanta di potenza di calcolo che si è creato un nuovo paradosso, quasi un loop temporale che sta riportando il mondo al modello del terminale. Oggi non solo è possibile far girare contemporaneamente più programmi su un computer, ma perfino far girare più astrazioni di computer sulla stessa macchina. Il motivo è evidente: il numero di operazioni che si potevano eseguire al secondo in un computer da tavolo negli anni Novanta, può oggi essere eseguita in una frazione di secondo con la stessa categoria di PC. Se si escludono applicazioni intensive sul piano computazionale, rare in ambienti di lavoro comuni (anche se del tutto frequenti nelle case dove si videogioca con il computer) si giunge alla curiosa conclusione che oggi i computer trascorrono la maggior parte del loro tempo a… fare nulla! Tra la battitura di un tasto e quello successivo nella barra del browser ci sono interminabili frazioni di secondo, che vengono di fatto sprecate senza attività. Questo è vero anche in ambito server. I sistemi centrali aziendali erogano funzioni molto importanti, ma generalmente poco impegnative sul piano computazionale. La maggior parte dei server svolge funzioni di raccolta file, oppure di supporto per la memorizzazione di dati gestionali, di magazzino e così via, oppure funzionalità di rete. Se i server sono basati su Linux il carico sul microprocessore è inferiore, in quanto non c’è neppure l’impatto dell’interfaccia grafica e degli innumerevoli servizi che girano nei sistemi concorrenti. I microprocessori multicore montati su queste unità sono di fatto sottoutilizzati.

È su questo “spreco” computazionale che si basa il concetto di virtualizzazione. Un singolo computer può ospitare più macchine virtuali. Si possono così far girare più server Windows o Linux sullo stesso computer, proprio perché la maggior parte di questi sistemi trascorre una parte preponderante del proprio tempo a fare nulla. Le aziende stanno abbracciando questa filosofia con interesse, in quanto possono consolidare più server fisici in un’unica macchina e risparmiare sull’hardware, sulla manutenzione, sulle dimensioni fisiche della sala macchine e sui costi elettrici. Si ritorna quindi alla visione centralizzata con poche macchine dotate di enorme importanza strategica e produttiva, in quanto portatrici delle funzionalità di più macchine, un tempo dotate di una fisicità autonoma e indipendente, ora totalmente astratte. I dati di mercato evidenziano una tendenza in crescita e un allargamento del pubblico che si interessa a queste tecnologie. Se all’inizio erano solo grandi organizzazioni, con ampie risorse economiche, ora vi sono anche piccole e medie imprese, attratte dai vantaggi e dai costi di ingresso in diminuzione. La virtualizzazione è evidentemente il futuro. Ora l’attenzione è puntata sulla virtualizzazione dei server, ma vi sarà una seconda fase in cui anche i client saranno oggetto di questo fenomeno e si tornerà ai terminali stupidi, con poca potenza e costi ridotti, completando così il ritorno ai terminali. Il piatto ambito è la possibilità di evitare gli enormi costi di manutenzione dei client, che regolarmente devono essere sottoposti a operazioni di assistenza a seguito di problemi di ogni genere, la possibilità di avere gli applicativi installati centralmente e la capacità di ripartire meglio le risorse hardware. In definitiva, rinnegare tutto ciò che è stata l’informatica personale degli ultimi due decenni.

Definire la tecnologia Attraverso la virtualizzazione è possibile consolidare più macchine in un unico server dotato di risorse hardware sufficienti. Il numero di macchine che possono essere virtualizzate su un server dipende dal carico richiesto alle singole macchine. Tipicamente è necessario abbondare sul lato della memoria RAM. Vi sono invece meno vincoli sui microprocessori: i modelli multicore presenti oggi sul mercato sono in grado di far funzionare fluidamente più server, a meno che non si tratti di ambienti computazionalmente intensivi. In tal caso è necessario utilizzare altre strategie di consolidamento dell’hardware, che esulano dagli scopi di questo libro. La virtualizzazione non implica una rivoluzione nel modo di lavorare. Viene “semplicemente” smaterializzato l’hardware, mantenendo l’importanza del software. Gli utenti non percepiranno neppure questo cambio di paradigma e il sistemista svolgerà le stesse attività di sempre. Dovrà ancora installare il sistema operativo, configurarlo, caricare il software applicativo e i dati e poi amministrare i sistema nel tempo. Avrà in più l’onere di amministrare lo strato di virtualizzazione. Un server fisico con un meccanismo di virtualizzazione è, da un punto di vista funzionale, equivalente a un insieme di server reali tradizionali. L’equivalenza sussiste in quanto la virtualizzazione opera un’astrazione fedele e completa dell’hardware e permette il funzionamento di più istanze dell’astrazione sulla stessa macchina. Grazie all’equivalenza, non sono richieste modifiche ai sistemi operativi o al software applicativo, che funzioneranno in maniera indistinguibile. I sistemi di virtualizzazione di massa operano su microprocessori Intel o AMD e virtualizzano macchine PC compatibili. Si virtualizza cioè la stessa architettura su cui sta funzionando il software di virtualizzazione. Questo perché vengono usate alcune funzionalità offerte dal microprocessore per creare un numero arbitrario di contesti indipendenti. Questo significa che il sistema di virtualizzazione non deve emulare il microprocessore, ma lo utilizza direttamente per eseguire il codice delle macchine virtuali. È importante, a tal proposito, disporre di microprocessori recenti, dotati di specifiche estensioni. Le estensioni per la virtualizzazione sono in genere evidenziate nelle specifiche della CPU. In particolare si

devono cercare le estensioni VT sui microprocessori Intel e le estensioni AMD-V sui microprocessori AMD. A volte queste funzionalità sono presenti nel microprocessore, ma lasciate inattive. Si consiglia di controllare nel BIOS del computer se la funzionalità è attiva. Queste estensioni svolgono diverse funzionalità di assistenza alla virtualizzazione, alcune di natura fondamentale. Molti sistemi operativi funzionano utilizzando set di istruzioni privilegiate del microprocessore, che non sono accessibili agli applicativi che girano all’interno del sistema operativo. Se si virtualizza un sistema operativo di questo genere, si realizza un paradosso, dal momento che questo diventa in realtà un programma in esecuzione sul sistema di virtualizzazione, l’unico vero sistema operativo sulla macchina. In questo modo non può accedere alle istruzioni privilegiate del microprocessore, accessibili solo al software di virtualizzazione. Attraverso le estensioni alla virtualizzazione è possibile gestire questo problema e rendere i sistemi operativi funzionanti in ambito virtualizzato senza la necessità di modifiche. La vitualizzazione, come già puntualizzato, prevede la possibilità di avere più istanze dello stesso hardware su cui sta girando il sistema di virtualizzazione. L’uso di hardware differente viene chiamato “emulazione”. In questo caso si tratta di un programma che ricrea un sistema completamente differente, simulando l’hardware, il microprocessore e l’architettura generale. All’interno di questo ambiente simulato può funzionare il software del sistema che si sta emulando. Questo approccio è generalmente “unitario”. Si ha cioè una sola istanza dell’ambiente simulato, fornito in genere come compatibilità con il passato. È una prassi comune nel settore delle console per videogame. Ogni nuova versione di console è realizzata con hardware completamente differente rispetto al modello precedente. Viene però incluso un emulatore in grado di simulare l’hardware precedente, in modo che gli utenti non perdano l’investimento in termini di software acquistato. È un’ottima tecnica commerciale per invogliare gli utenti a comprare il nuovo modello garantendo la possibilità di giocare ancora con la propria biblioteca di titoli.

Virtualizzazione di tipo 1 e di tipo 2 I sistemi di virtualizzazione si suddividono in due categorie. I sistemi di tipo 1 prevedono che la macchina reale abbia solamente il sistema di virtualizzazione, mentre nei sistemi di tipo 2 si ha una macchina con un sistema operativo tradizionale, per esempio Linux, Mac OS o Linux. All’interno del sistema operativo girano gli applicativi tradizionali e un sistema di virtualizzazione, anch’esso un’applicazione. Questa seconda categoria è comoda quando si ha una macchina client e si desidera usare sporadicamente un altro sistema operativo per qualche scopo. In sostanza un utilizzo saltuario di un numero estremamente limitato di macchine virtuali. Considerando infatti il carico del sistema operativo e degli applicativi tradizionali, non si può pensare di usare più di una o due macchine virtuali, a meno di non essere disposti a subire il collo di bottiglia imposto dalla limitata memoria RAM. In questo capitolo si tratterà dei sistemi di virtualizzazione di tipo 1. Si installerà cioè l’hypervisor direttamente sull’hardware e non si avrà alcun altro sistema operativo nativo. L’hypervisor è il meccanismo software di virtualizzazione, l’elemento che rende possibile il funzionamento delle macchine virtuali sull’hardware sottostante. Quando si decide di intraprendere la via della virtualizzazione di tipo 1, in genere si comprano macchine nuove, con microprocessori di ultima generazione, dotati delle estensioni per la virtualizzazione. Bisogna categoricamente scartare l’idea di usare hardware obsoleto o di recupero. Si devono infatti far funzionare più macchine su un singolo hardware. È necessario quindi avere computer multicore, ampi spazi di memoria RAM e unità di storage veloci. Prima di acquistare l’hardware è necessario consultare gli elenchi di compatibilità pubblicati dal produttore del sistema di virtualizzazione. Solo pochi elementi hardware sono supportati, tipicamente i prodotti professionali. Le soluzioni di fascia bassa non vengono in genere considerate. In particolare si deve porre attenzione allo storage. Tutte le soluzioni RAID di tipo software non sono supportate, come pure eventuali

schede mirror di fascia bassa. È necessario invece avere controller che gestiscano il RAID a livello hardware. I dischi SATA connessi localmente sono invece supportati. Quando si esegue la virtualizzazione di tipo 1, si tende però a non utilizzare lo storage locale. Si punta invece ad avere le macchine virtuali memorizzate su dischi accessibili attraverso una rete dedicata allo storage, tecnicamente definita SAN (Storage Area Network). In questo modo qualunque macchina reale potrà eseguire qualunque macchina virtuale. Memorizzando le macchine virtuali sui dischi locali di un server reale specifico si crea invece un isolamento. Un server reale non può infatti accedere alle macchine virtuali memorizzate sul disco locale di un altro server reale.

Lo storage di rete Creare una rete SAN era fino a poco tempo fa una velleità per poche organizzazioni con ampie disponibilità finanziarie. L’hardware aveva costi proibitivi e la configurazione di attrezzature così avanzate era un’impresa tutt’altro che semplice. Oggi il panorama è cambiato parecchio ed è possibile creare uno storage di rete con un investimento limitato grazie alle unità NAS di ultima generazione. Un NAS è un’unità hardware dotata di un certo numero di dischi organizzati secondo uno schema RAID (mirror, striping, striping con parità o una combinazione di questi). Questa tecnologia permette di avere un grado elevato di protezione (con il mirror) o velocità (con lo striping). Il NAS è collegabile alle rete locale tramite una connessione Ethernet. In questo modo qualunque nodo della rete è in grado di accedere al sistema per sfruttare i dischi presenti all’interno del NAS. Tipicamente l’accesso ai dati di un NAS avviene grazie a condivisioni Windows (CIFS/SMB) create sul pannello di amministrazione dell’oggetto. Queste condivisioni sono ottime per lo scambio di file in gruppi di lavoro, ma del tutto inefficaci per un ambiente di virtualizzazione. Le macchine virtuali sono infatti memorizzate come file contigui che rappresentano il disco, più una serie di file di gestione. Si tratta quindi di file dell’ordine delle decine o delle centinaia di gigabyte. Le dimensioni dei file e le modalità di accesso non sono adatte ai protocolli di condivisione, nati con scopi completamente differenti. Bisogna allora optare per i NAS dotati del protocollo iSCSI. Si tratta dell’estensione del protocollo SCSI, molto in voga fino a metà degli anni 2000 per i server di fascia alta. iSCSI estende il protocollo, permettendo il funzionamento di SCSI sulla rete locale. Un computer può quindi utilizzare un disco fisicamente montato altrove, purché accessibile in rete. Il cavo piatto che in passato collegava il disco SCSI al controller montato sul computer è simulato da iSCSI sulla LAN. Tutti i sistemi di virtualizzazione prevedono iSCSI come protocollo di base per la gestione dello storage. iSCSI funziona all’interno del TCP/IP. Si parte quindi assegnando al NAS un indirizzo IP compatibile con la propria LAN. Poi si crea, dal pannello di gestione, una serie di spazi che saranno i dischi per i server virtuali. Per esempio, in un NAS da 4 terabyte si possono creare più spazi da 500 gigabyte. Questi spazi sono tecnicamente definiti LUN, un termine dello standard SCSI. Ogni LUN è identificata da un ID univoco. La macchina reale che esegue l’hypervisor potrà agganciarsi in iSCSI al NAS e usare una delle LUN create come disco per una delle macchine virtuali. Per il sistema operativo virtualizzato non vi sarà alcuna differenza tra un disco reale e la LUN. Naturalmente le prestazioni dipendono dalla qualità della rete locale. Si consiglia perciò di avere almeno un ambiente Gigabit Ethernet.

Il server reale I server di fascia media e medio/alta per la virtualizzazione non hanno dischi rigidi locali. Montano piuttosto dischi flash di piccole dimensioni dove è installato l’hypervisor. Nelle installazioni con meno risorse si punta a replicare questa situazione con una veloce chiave USB da pochi gigabyte (la maggior parte dei sistemi è oggi in

grado di eseguire il boot da una chiave USB). Si elimina così un elemento soggetto a guasti frequenti e si aumenta l’affidabilità. Nulla comunque vieta di usare dischi tradizionali per l’installazione dell’hypervisor. Nelle prossime pagine si vedrà come installare un sistema di virtualizzazione di tipo 1. Per il funzionamento dell’hypervisor sarà utilizzato un computer di ultima generazione, scelto tenendo conto dei requisiti di compatibilità del produttore dell’hypervisor. Il microprocessore è di marca Intel, velocità 2.6 GHz, a due core e con estensioni per la virtualizzazione. Il computer è dotato di un disco locale di piccole dimensioni per l’installazione del sistema di virtualizzazione. Le schede di rete sono Gigabit Ethernet. Il computer è collegato a uno switch Gigabit Ethernet a cui è connesso anche un sistema NAS. Computer e NAS sono stati configurati sulla stessa sottorete IP con indirizzi univoci, assegnati manualmente. Vista la centralità di questi sistemi si evita l’uso di DHCP. Il NAS è dotato di quattro dischi organizzati in RAID 5 (striping con parità). Il NAS supporta iSCSI ed è stato configurato per esportare una serie di LUN da 150 gigabyte. Queste LUN saranno i dischi per le macchine virtuali. Le LUN sono state attivate con una protezione di accesso. Il protocollo iSCSI prevede due modalità di accesso alle risorse. Nella prima modalità l’accesso è libero. Chiunque cioè può connettersi alla LUN e agganciare il disco virtuale senza alcun livello di protezione. Nella seconda modalità è necessario indicare username e password. Si consiglia sempre di impiegare questo secondo meccanismo, a protezione dei dati. Un dettaglio importante da tenere in considerazione è che, per motivi di integrità dei dati, le LUN non possono essere utilizzate contemporaneamente da più computer virtuali. Sarebbe come collegare un disco rigido fisico a più computer. Ogni LUN sarà quindi assegnata in maniera esclusiva a un sistema. Questa semplice configurazione è sufficiente per avere un sistema di virtualizzazione funzionante. Si tratta però di un’architettura con molte criticità. Un guasto a qualunque elemento hardware renderebbe inaccessibili un certo numero di server virtuali. Nelle installazioni dove è richiesta alta continuità si tende invece a duplicare tutte le risorse. Si usano cioè almeno due server reali collegati in rete con due schede di rete, ognuna connessa a uno switch differente. Lo storage impiegato prevede almeno due controller a bordo, con due schede di rete ognuno. In questo modo ogni controller è collegato alla rete tramite due switch differenti. Tutto è quindi ridondante e vi sono percorsi doppi tra tutti gli elementi.

La soluzione Citrix Esistono molte soluzioni per la virtualizzazione, sia commerciali, sia di natura open. Una soluzione interessante è XenServer, prodotto dall’americana Citrix e basato sull’hypervisor aperto Xen. XenServer è disponibile gratuitamente, anche per usi commerciali. Si ha così la possibilità di installare l’hypervisor sui propri server e sfruttare un sistema di virtualizzazione molto robusto e collaudato. Il sistema impiega tecniche di paravirtualizzazione, grazie alle quali si riducono gli strati software che separano l’applicativo dalla macchina reale. Il sistema operativo e gli applicativi virtualizzati possono così sfruttare l’accelerazione offerta dall’hardware. Citrix offre gratuitamente una funzionalità di grande valore che è fornita a pagamento in praticamente tutte le soluzioni commerciali concorrenti: il “motion”. Questo termine indica la possibilità di spostare una macchina virtuale da un server reale a un altro senza alcuna interruzione per gli utenti connessi sulle macchine virtuali. Di fatto utenti e applicazioni non si accorgeranno di essere stati spostati su un hardware differente. Si tratta di una funzionalità notevole per l’ottimizzazione delle risorse e per gestire operazioni di manutenzione o di emergenza. Questa tecnologia impone alcuni vincoli hardware. Innanzitutto le macchine reali devono avere microprocessori di medesimo tipo, stepping compreso. Le immagini disco delle macchine virtuali devono essere presenti in uno storage di rete e non sui dischi locali. Il motion non sposta infatti sulla rete le immagini disco (operazione di fatto impossibile considerando dischi di diversi gigabyte o terabyte), ma solamente lo

stato della macchina e l’immagine della memoria RAM, più limitate e quindi trasferibili agevolmente in LAN. Acquistando le versioni commerciali di XenServer è possibile utilizzare il motion come base per metodologie di continuità, come per esempio lo spostamento automatico dei server in caso di crash di una macchina reale. Nella versione gratuita si deve invece eseguire lo spostamento manualmente tramite il pannello di controllo software. Per iniziare l’attività è necessario scaricare l’immagine ISO di XenServer dall’area di download presso http://www.xenserver.com. Allo scopo si deve creare un profilo. Gli elementi da scaricare sono tre: XenServer Base Installation ISO, XenServer Linux Supplemental e XenCenter Windows Management Console. Il primo disco contiene il sistema di virtualizzazione, il secondo contiene una serie di template per la virtualizzazione di Linux e l’ultimo download contiene la console di gestione, funzionante solo su Windows. I template permettono di sfruttare la paravirtualizzazione sulle distribuzioni Linux più diffuse senza la necessità di installare manualmente alcun elemento specifico.

Installazione del nodo di virtualizzazione Per cominciare si inserisce il disco scaricato dal sito di Citrix sul computer e si riavvia la macchina. Il sistema eseguirà il boot da CD-ROM e comincerà la procedura di installazione. Attenzione al fatto che il contenuto del disco rigido del computer sarà irrimediabilmente perduto. A fine operazione la macchina sarà completamente dedicata alle attività di virtualizzazione e non potrà essere usata per altri scopi. La fase iniziale è simile all’installazione di un sistema Linux. Viene caricato in memoria un kernel, che viene poi reso operativo. Dopo alcuni attimi compare il logo del prodotto e poi comincia la breve procedura di installazione. Il primo dettaglio che viene richiesto è la mappa della tastiera, da scegliere dall’elenco proposto. Completata questa operazione viene visualizzata una finestra di benvenuto, da confermare con Ok. Compaiono in questo modo i termini di licenza del prodotto, da accettare facendo clic su Accept EULA. A questo punto viene mostrato un avvertimento circa la natura distruttiva dell’operazione. Il disco subirà un reset completo e tutti i dati precedenti saranno eliminati irrimediabilmente. Confermando si visualizza una schermata che richiede la sorgente di installazione. In questo caso si deve selezionare Local media per utilizzare il CD-ROM inserito nel drive. La procedura potrebbe comunque essere effettuata anche attraverso la rete. Viene poi richiesto di confermare se ci sono dischi supplementari da utilizzare, i quali saranno richiesti in seguito. In questo caso si sta effettuando un’installazione di base della versione gratuita, senza componenti supplementari. Prima di eseguire l’installazione si può attivare una verifica del disco dall’apposita schermata di check. Viene così controllata l’integrità del CD-ROM masterizzato, prima di procedere con le operazioni. Completata questa fase viene richiesta la password di root per il server reale che si sta installando e poi i dati di rete. Nella prima schermata dovranno essere inseriti IP, netmask e gateway. Nel pannello seguente il nome del nodo e i dettagli del DNS. Si prosegue con la selezione della zona temporale (Europa) e della città più vicina (per esempio Roma). Poi viene richiesta la modalità di sincronizzazione dell’orologio: manuale oppure attraverso un server NTP esterno da specificare. La configurazione iniziale è completata. Se i dati sono stati inseriti correttamente si può fare clic su Install XenServer e procedere con il caricamento. L’operazione risulterà molto veloce e a fine procedura il sistema verrà riavviato per eseguire il boot dell’hypervisor. Si potrà notare che il sistema fornisce un’interfaccia a caratteri da cui configurare una serie di dettagli di base. La navigazione avviene con i tasti cursore, il tasto Invio per confermare ed Esc per uscire. Vi sono diverse voci presenti.

Status permette di verificare lo stato del sistema. Authentication permette di modificare i dati di autenticazione al server. Virtual machines permette di verificare le macchine virtuali in funzionamento e misurare le performance. Disks and storage repositories permette di gestire le aree di memorizzazione da dedicare alle macchine virtuali. Uno storage repository potrebbe essere il disco locale, un altro potrebbe essere composto dalle LUN esportate in rete dal NAS tramite il protocollo iSCSI. Da questo menu è possibile creare nuovi repository, collegarli, sospenderli e così via. Resource pool configuration permette di configurare i resource pool, ovvero gli insiemi di risorse, come per esempio un certo numero di computer reali che sono raggruppati per gestire il motion delle macchine virtuali in esecuzione. Il motion è infatti possibile solo previa configurazione di un pool di server. Hardware and bios configuration, per il controllo dei dati circa l’hardware in uso. Keyboard and timezone, per la configurazione della tastiera e della gestione del tempo. Remote service configuration, per la gestione di servizi remoti, come per esempio l’abilitazione della shell da remoto o per configurare un server Syslog. Backup, restore and update, per il backup delle informazioni di supporto per le macchine virtuali e l’update del sistema. Technical support, per generare rapporti tecnici di funzionamento o di crash utili in caso di supporto tecnico. Reboot or shutdown, per lo spegnimento e il riavvio della macchina. Local comand shell, per accedere alla shell dei comandi, da cui impartire eventuali comandi da tastiera. La documentazione tecnica elenca tutti i comandi testuali disponibili. La console testuale è utile per amministrare rapidamente il nodo di virtualizzazione quando si ha accesso locale alla console. Generalmente però la configurazione e la gestione delle macchine virtuali avviene con il pannello di amministrazione software, funzionante su Windows.

Pannello grafico di amministrazione Il pannello grafico di amministrazione è denominato XenCenter Windows Management Console e si scarica dal sito del produttore. L’installazione è estremamente semplice. All’avvio bisogna solo aggiungere un nuovo server, specificando l’indirizzo IP del nodo e le credenziali di accesso. La prima volta verrà chiesto di applicare la licenza per il nuovo nodo. Tutti i nodi hanno bisogno di una licenza valida rilasciata da Citrix, anche le versioni gratuite. È sufficiente eseguire la registrazione per ottenere il certificato da installare sul nodo di virtualizzazione e avere il funzionamento illimitato per le funzionalità previste dall’edizione gratuita. All’apertura della console comparirà una serie di menu, un albero sulla sinistra e una zona a destra con una serie di schede per la gestione delle risorse (Figura 21.1).

Figura 21.1 Pannello grafico di gestione e controllo di XenServer. Sono presenti due nodi di virtualizzazione: “Nettuno” e “xenserver1”.

Selezionando il nodo di virtualizzazione e facendo clic sulle schede è possibile ottenere parecchie informazioni sulla memoria, lo storage, la rete e le performance. È anche possibile accedere in remoto alla shell testuale del nodo di virtualizzazione. Il pannello delle performance è interessante in quanto visualizza il carico complessivo della CPU, della memoria e delle schede di rete del nodo di virtualizzazione. Esplorando i dati raccolti in tempo reale e memorizzati, è possibile verificare se il nodo è in grado di sopportare le macchine virtuali installate oppure se le risorse sono sottodimensionate per lo scopo. Il pannello visualizza anche i reboot della macchina nel tempo. Prima di eseguire l’installazione di una macchina virtuale Linux è necessario configurare lo storage repository. Se si fa clic sulla scheda Storage si potrà notare che è elencato lo storage locale, l’unità ottica ed eventuali unità rimovibili (Figura 21.2).

Figura 21.2 Pannello di gestione degli storage repository con visualizzazione per il nodo “xenserver1”.

Non si intende usare lo storage locale, ma piuttosto il NAS, accedendo in iSCSI alle LUN configurate in precedenza. Non si vuole precludere la possibilità di usare caratteristiche evolute come il motion. Ora si fa clic sul pulsante New SR. Compare una finestra dove specificare il tipo di storage che si intende collegare (Figura 21.3).

Figura 21.3 XenServer prevede diversi sistemi per la connessione a storage repository esterni.

Bisogna selezionare la modalità Software iSCSI. Compare un ulteriore pannello dove indicare i dettagli dello storage di rete. Si deve inserire un’etichetta descrittiva, l’indirizzo IP dello storage e le credenziali di accesso. Facendo clic sul pulsante Discover IQNs viene visualizzato l’indirizzo iSCSI dello storage. Questi indirizzi sono denominati IQN e sono una stringa avente il seguente formato: iqn..: I n viene utilizzato il dominio Internet di primo e di secondo livello del produttore della soluzione iSCSI, mentre in viene indicato l’anno e il mese in cui il dominio precedente è stato acquisito dal proprietario. Dopo i due punti (:) è possibile inserire una stringa libera. Per lo storage utilizzato in questo esempio l’indirizzo IQN è il seguente: iqn.1992-04.com.emc:storage.storage.lun1

Facendo clic sul pulsante Discover LUNs è possibile visualizzare le LUN presenti e sceglierne una per creare lo storage repository (Figura 21.4).

Figura 21.4 Configurazione di uno storage repository iSCSI.

Il sistema segnalerà che l’attivazione dello storage repository sulla LUN indicata cancellerà tutti i dati presenti. Si deve confermare questa intenzione. In tal modo verrà avviata la creazione dello storage repository. La nuova area sarà subito evidenziata nel pannello di configurazione (Figura 21.5).

Figura 21.5 Il nodo di virtualizzazione xenserver1.

Ora è possibile creare una nuova macchina virtuale. Basta accedere al menu VM e scegliere New VM. Compare una finestra dove specificare il tipo di sistema operativo che si intende installare, in questo caso Linux CentOS. Sono previste diverse tipologie di Windows, Debian, Oracle Enterprise Linux, RedHat Enterprise Linux, SuSE Linux Enterprise Server e così via (Figura 21.6).

Figura 21.6 Scelta del sistema operativo da installare.

Nel passaggio seguente si deve assegnare un nome alla macchina virtuale. È possibile inserire commenti liberi, molto utili quando il numero delle macchine virtuali diventa molto ampio. Al passaggio successivo si deve indicare il supporto da cui eseguire l’installazione. Può essere il CD-ROM presente sul nodo di virtualizzazione, un URL esterno oppure un template di XenServer. Al passaggio successivo si deve indicare il server fisico a cui è assegnata questa macchina. In questo caso si ha solo il nodo xenserver1. Se si hanno altre macchine fisiche identiche è possibile creare un pool attraverso l’apposito menu della console di amministrazione e stabilire quale delle macchine è il server principale per la macchina virtuale che si sta creando. Proseguendo si deve specificare il numero di vCPU e la quantità di memoria assegnati alla macchina virtuale (Figura 21.7). Ogni core del microprocessore rappresenta una vCPU. È importante non superare il numero di core reali tra le macchine virtuali presenti. Se si ha un microprocessore a due core, si potranno ragionevolmente far funzionare contemporaneamente due macchine virtuali, ognuna su una vCPU. Se si supera il numero di core, le prestazioni saranno degradate, in quanto le macchine virtuali si contenderanno i core disponibili. La RAM deve essere assegnata suddividendo la memoria effettivamente presente. Non è possibile che la somma della memoria assegnata alle macchine virtuali sia superiore alla RAM presente fisicamente sul server. L’unica alternativa è incrementare la memoria RAM disponibile. Si deve considerare che anche l’hypervisor consuma una parte della memoria fisica disponibile.

Figura 21.7 Assegnazione di CPU e memoria.

Nel passaggio successivo si deve specificare lo storage. Lo storage repository ricavato dall’unità NAS può essere suddiviso in parti e usato per far funzionare un numero arbitrario di macchine virtuali. In questo passaggio si specifica lo spazio da assegnare al disco virtuale che si sta creando, nello specifico 20 gigabyte da uno spazio massimo di 150 gigabyte (Figura 21.8).

Figura 21.8 La macchina virtuale Linux CentOS utilizzerà circa 20 gigabyte di spazio tratto dal target iSCSI di 150 gigabyte.

Il passaggio seguente è dedicato al networking. Si possono creare fino a quattro schede di rete virtuali da

assegnare alla macchina. Naturalmente si dovranno assegnare a queste schede di rete degli indirizzi IP regolari, per fare in modo che funzionino sulla rete. Completata l’operazione, nell’albero a sinistra comparirà una nuova voce, a rappresentare la nuova macchina virtuale creata. Facendo clic sulla voce e sfogliando le schede dell’area centrale è possibile avere varie informazioni sulla macchina. È presente anche una scheda Console dove è disponibile la console della macchina, ovvero il monitor e la tastiera della macchina virtuale. Non resta che lanciare la macchina facendo clic sul pulsante Start presente sulla barra in alto. Si potrà osservare il boot, del tutto standard e subito dopo il caricamento della procedura di installazione di CentOS. Di fatto non c’è alcuna differenza tra l’installazione su un computer reale e su una macchina virtuale (Figura 21.9).

Figura 21.9 Installazione di CentOS tramite la console di XenServer.

L’installazione procederà quindi in maniera del tutto naturale. Completata l’installazione è fondamentale installare i XenServer Tools, estensioni per il supporto nativo della virtualizzazione. In poche parole, una serie di driver per ottimizzare le prestazioni delle macchine virtuali. Per verificare se i tool sono già presenti, si deve selezionare il nome della macchina virtuale dall’albero a sinistra e poi selezionare la scheda General. Se compare un messaggio di avvertimento rosso relativo all’assenza dei tool, è necessario procedere all’installazione. Altrimenti significa che è già stato inserito nel sistema. Per installare i XenServer Tools si deve selezionare la macchina virtuale, andare nel menu VM e scegliere la voce Install XenServer Tools. Poi si deve andare nella console di Linux e digitare questi comandi come root: mount /dev/xvdd /mnt sh /mnt/Linux/install.sh

Una volta completata l’operazione si esegue un reboot della macchina virtuale. I XenServer Tools sono necessari anche per installazioni di macchine virtuali Windows. Attivando la voce Install XenServer Tools dal menu VM, nelle Risorse del computer comparirà un’unità da cui eseguire l’installazione.

Manutenzione È possibile eseguire alcune operazioni interessanti, utili per la manutenzione del sistema di virtualizzazione. Fermando una macchina virtuale è possibile accedere al menu VM e usare le opzioni Copy VM e Move VM. La prima esegue una copia identica della macchina virtuale. In questo modo è possibile creare dei cloni utili a fini di test o quando si devono fare operazioni potenzialmente distruttive. La seconda opzione sposta la macchina virtuale su un altro storage repository. L’opzione Export as Backup permette di scaricare sul client locale che si sta usando per l’amministrazione un’immagine della macchina virtuale. In questo modo si salva una copia locale, utile per scopi di backup. L’operazione risulta però lunga in quanto l’ordine di grandezza dei dischi oggi è almeno delle decine di gigabyte, con un networking mediamente ancorato ai 100 megabit per secondo. Molto interessante è la voce Take Snapshot che permette, a macchina virtuale funzionante, di fissare il momento in cui si richiama l’opzione. In qualunque momento futuro sarà possibile riportare la macchina allo stato dello snapshot (Figura 21.10).

Figura 21.10 Finestra per la realizzazione di uno snapshot dello stato della macchina virtuale.

Gli snapshot realizzati sono evidenziati nella scheda Snapshots del pannello di amministrazione (Figura 21.11).

Figura 21.11 Pannello con la sequenza temporale degli snapshot per la macchina virtuale selezionata.

Da uno snapshot è possibile creare una nuova macchina virtuale oppure esportare un backup. Altrimenti è possibile semplicemente tornare indietro a uno snapshot usando l’opzione Revert to. Di fatto si ritorna indietro nel passato della macchina virtuale. Gli snapshot consumano spazio sullo storage repository. Si deve quindi sempre prevedere margine per le operazioni di snapshot. Un’altra operazione interessante ai fini della manutenzione è la possibilità di eseguire un backup della configurazione del server reale. Selezionando il nome del server reale dall’albero a sinistra e scegliendo la voce Back Up Server dal menu Server si ottiene un file che rappresenta l’intera configurazione della macchina reale, utile per ripristinare l’ambiente in caso di crash del server reale.

Pool di risorse Se si hanno più computer con hardware identico è possibile creare un pool usando il relativo menu del pannello di amministrazione. Si deve scegliere la voce New Pool e specificare un nome per il pool e le macchine che si vogliono inserire. Le macchine devono essere state amministrate almeno una volta dalla console di amministrazione di XenServer. In qualunque momento è possibile aggiungere o rimuovere macchine dal pool. Una volta che il pool è in funzione, è possibile usare il motion e le funzionalità avanzate, se previste dalla licenza usata, come per esempio il bilanciamento della risorse oppure l’alta disponibilità.

Checklist 1. Individuare una o più macchine server conformi ai requisiti di compatibilità di Citrix XenServer. 2. Individuare un sistema per la memorizzazione dei dischi virtuali, preferibilmente un’unità NAS dotata di protocollo iSCSI.

3. Collegare i server e l’unità NAS con una tratta Gigabit Ethernet. 4. Installare XenServer sulle macchine reali, configurando con attenzione la rete. 5. Configurare i parametri di rete del NAS in modo che sia accessibile ai server. 6. Configurare un certo numero di LUN sul NAS. 7. Impostare le LUN in modo che siano accessibili dalla rete solo attraverso una password di accesso. 8. Installare il pannello di amministrazione di XenServer su una macchina Windows. 9. Aggiungere le macchine XenServer installate sul pannello di amministrazione. 10. Installare il file di licenza sui sistemi appena installati con XenServer. 11. Se si hanno più macchine reali, creare un pool di server su XenServer. 12. Configurare uno o più storage repository sulle macchine XenServer accedendo alle LUN del NAS precedentemente configurate. 13. Creare le macchine virtuali per i sistemi che si vogliono installare. Fare attenzione, durante la creazione delle macchine virtuali, a non usare un numero di CPU virtuali superiore al numero di core reali. Se si hanno due core sul server, si potranno ragionevolmente avere due macchine virtuali. Una terza macchina creerebbe una competizione per l’uso delle risorse reali. Assegnare la RAM con cura, tenendo conto che non si può usare un valore superiore alla RAM reale del server. Si possono assegnare fino a quattro schede di rete virtuali per server. 14. Installare i sistemi operativi virtuali sulle macchine virtuali in maniera del tutto standard. I dischi delle macchine virtuali saranno creati sulle LUN precedentemente configurate e importati come storage repository. Se si hanno computer reali in produzione, si può tentare una conversione da fisico a virtuale con il tool XenConvert disponibile dall’area di download di Citrix. Eseguire comunque un backup a scopo cautelativo prima dell’operazione. 15. Impostare indirizzi di rete sulle macchine virtuali in maniera compatibile con la configurazione LAN esistente. 16. Installare, se necessario, i XenServer Tools.

Appendice A

Appendice A - Riferimenti bibliografici e link di approfondimento Siti di notizie su Linux e il movimento open Slashdot (http://slashdot.org) - Sito di news sull’informatica e le nuove tecnologie più seguito al mondo (in inglese). Digg (http://digg.com) - Sito di news dove le notizie sono selezionate e votate dai lettori (in inglese). ZioBudda (http://www.ziobudda.net) - Il più seguito portale italiano su Linux. Linux Today (http://linuxtoday.com) - Uno dei più aggiornati siti di news su Linux (in inglese). OSNews (http://www.osnews.com) - News e articoli riguardanti i sistemi operativi. Tratta regolarmente le novità su Linux (in inglese).

Siti di documentazione tecnica e riferimenti Italian Linux Documentation Project (http://it.tldp.org) - Raccolta di documentazione tecnica in italiano su Linux. Appunti di Informatica Libera (http://a2.pluto.it) - Un lavoro enciclopedico di introduzione a Linux e a tutti i suoi aspetti. Webopedia (http://www.webopedia.com) - Dizionario italiano dei termini e delle sigle in informatica. Internet RFC Index (http://www.faqs.org/rfcs) - Un archivio dei documenti RFC (in inglese). Wikipedia (http://www.wikipedia.org) - L’enciclopedia libera contiene ottimi riferimenti per i termini informatici.

Libri tecnici e di riferimento Silvio Umberto Zanzi, Usare Linux, Apogeo - Una comoda guida per chi si avvicina a Linux. Mark Wilding e Dan Behman, Self Service Linux, Apogeo - Per chi cerca un volume in italiano che condensi informazioni, trucchi e segreti su Linux. B. Mako Hill, Jono Bacon, Corey Burger, Jonathan Jesse e Ivan Krstic, Linux Ubuntu - La guida ufficiale, Apogeo – In italiano, il manuale ufficiale di Ubuntu, la distribuzione Linux oggi più famosa. Daniel J. Barret, Linux - Guida Pocket, Tecniche Nuove - Guida concisa, pratica e ben realizzata dei comandi di Linux e della shell. Pete Loshin, TCP/IP Clearly Explained (fourth edition), Morgan Kaufmann Publishers - Trattazione aggiornata e completa sul protocollo TCP/IP. W. Richard Stevens, TCP/IP Illustrated (Volume 1), Addison-Wesley - Trattazione sul TCP/IP

attraverso l’output di tcpdump.

Riferimenti per i Capitoli 1 e 2 Manuale

di smb.conf (http://us1.samba.org/samba/docs/man/manpages3/smb.conf.5.html) - Elenco, in ordine alfabetico, delle direttive del file di configurazione di Samba (in inglese). The Official Samba-3 HOWTO and Reference Guide (http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/) - Guida ufficiale a Samba 3.5 (in inglese). Using Samba, 2nd Edition (http://us1.samba.org/samba/docs/using_samba/toc.html) - Un libro per gli amministratori che devono supportare client Windows (in inglese). Ubuntu Server 7.10: OpenLDAP + SAMBA Domain Controller (http://ubuntuforums.org/showthread.php?t=640760) - Un tutorial per la configurazione di un controller di domino Samba con autenticazione LDAP (in inglese).

Riferimenti per il Capitolo 3 Printing In Linux With CUPS (http://www.hlug.org/presentations/cups/printing.html) Guida passo a passo sulla stampa con CUPS (in inglese). CUPS Software Administrators Manual (http://www.cups.org/sam.html) - Manuale ufficiale dell’amministratore di un sistema CUPS (in inglese). An Overview of the Common UNIX Printing System (http://www.cups.org/overview.html) Descrizione generale di CUPS (in inglese). LinuxPrinting.org (http://www.linuxprinting.org) - Il sito di riferimento per la stampa su Linux, BSD e Unix con una importante collezione di risorse e documenti (in inglese).

Riferimenti per il Capitolo 4 DNS Howto (http://langfeldt.net/DNS-HOWTO/BIND-9) - Una guida veloce a Bind (in inglese). BIND 9 Administrator Reference Manual (http://unbound.sourceforge.net/manual/Bv9ARM.html) - Manuale esaustivo su Bind 9 per gli amministratori (in inglese).

Riferimenti per il Capitolo 5 Ralph E. Droms e Ted Lemon, The DHCP Handbook second edition, Pearson Education - Guida ufficiale a dhcpd (in inglese). The Arda.Home-unix.Net DNS & DHCP Setup (http://www.arda.homeunix.net/dnssetup.html) - Esempio di integrazione di Bind con il servizio DHCP (in inglese).

Riferimenti per il Capitolo 6 Michael D. Bauer, Server Linux Sicuri, HOPS - Guida per costruire server sicuri con Linux. Linux IP Masquerade HOWTO (http://en.tldp.org/HOWTO/IP-MasqueradeHOWTO/index.html) -Esaustivo how-to sul servizio di masquerading su Linux (in inglese). Netfilter.org (http://www.netfilter.org) - Home page del modulo netfilter del kernel Linux con una interessante sezione di documentazione (in inglese).

Riferimenti per il Capitolo 7 IANA Well Known Port Numbers (http://www.iana.org/assignments/port-numbers) Elenco ufficiale delle porte note (in inglese). Documentazione ufficiale di SmoothWall Express (http://www.smoothwall.org/get) - Installation Guide e Administration Guide (in inglese).

Riferimenti per il Capitolo 8 Linux VPN Masquerade HOWTO (http://www.tldp.org/HOWTO/VPN-MasqueradeHOWTO.html) - Configurazione di una VPN attraverso una combinazione router/firewall Linux, con masquerade (in inglese).

Riferimenti per il Capitolo 9 Transparent Proxy with Linux and Squid mini-HOWTO (http://tldp.org/HOWTO/TransparentProxy.html) - Una guida per configurare Squid in modalità transparent proxy (in inglese).

Riferimenti per il Capitolo 10 ClamAV Virus Database Search (http://clamav-du.securesites.net/cgi-bin/clamgrok) Database delle minacce riconosciute da ClamAV (in inglese).

Riferimenti per il Capitolo 11 Unix Backup and RecoveryUsing Amanda (http://safari.oreilly.com/1565926420) - Unix Backup and Recovery di W. Curtis Preston, edito da O’Reilly e disponibile presso Safari Books Online (in inglese).

Riferimenti per il Capitolo 12 Kerio Connect Manual (http://www.kerio.com/connect/manual) - Manuale ufficiale di Kerio Connect (in inglese). Open mail relay (http://en.wikipedia.org/wiki/Open_mail_relay) - Descrizione del concetto di open relay tratto da Wikipedia (in inglese).

Riferimenti per il Capitolo 13 Scalix documentation (http://www.scalix.com/community/downloads/documentation.php) Documentazione tecnica ufficiale di Scalix (in inglese).

Riferimenti per il Capitolo 14 The HylaFAX Administrator’s Handbook (http://www.hylafax.org/content/Handbook) Guida ufficiale di HylaFAX per l’amministratore di reti (in inglese).

Riferimenti per il Capitolo 15 Apache HTTP Server Version 2.2 Documentation (http://httpd.apache.org/docs/2.2/) Indice della documentazione ufficiale relativa ad Apache HTTP Server (in inglese). Directive Quick Reference (http://httpd.apache.org/docs/2.2/mod/quickreference.html) - Indice delle direttive di configurazione (in inglese). Securing Apache 2: Step-by-Step (http://www.securityfocus.com/infocus/1786) - Una guida di Artur Maj per installare e configurare Apache minimizzando i rischi di sicurezza (in inglese).

Riferimenti per il Capitolo 16 Manuale di tcpdump (http://www.tcpdump.org/tcpdump_man.html) - Manuale ufficiale on-line di tcpdump (in inglese). Definizione SNMP (http://it.wikipedia.org/wiki/Simple_Network_Management_Protocol) - Definizione del protocollo SNMP da Wikipedia in italiano. Mrtg-reference (http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html) - Reference ufficiale per MRTG (in inglese). IPTraf User’s Manual (http://iptraf.seul.org/2.7/manual.html) - Manuale ufficiale di IPTraf.

Riferimenti per il Capitolo 17 Mark Wand Schneider, Sviluppare applicazioni web con PHP e MySQL, Apogeo - Guida al PHP e alla sua interazione con MySQL.

Riferimenti per il Capitolo 18 PHProjekt MediaWiki (http://docs.phprojekt.com/index.php/User) - Documentazione ufficiale di PHProjekt (in inglese).

Riferimenti per il Capitolo 19 Joomla 1.5 Installation Manual (http://help.joomla.org/content/category/48/268/302/) - Manuale per l’installazione di Joomla! 1.5 (in inglese). Joomla User Documentation Forum (http://forum.joomla.org) - Forum per gli utenti di Joomla! (in inglese).

Riferimenti per il Capitolo 20 Active FTP vs. Passive FTP, a Definitive Explanation (http://slacksite.com/other/ftp.html) - Una chiara spiegazione delle differenze tra la modalità attiva e passiva di FTP (in inglese).

Riferimenti per il Capitolo 21 Hypervisor (http://en.wikipedia.org/wiki/Hypervisor) - Definizione di Hypervisor, tratto da Wikipedia (in inglese). XenServer Documentation (http://docs.vmd.citrix.com/XenServer/5.6.0/1.0/en_gb/) Documentazione ufficiale di XenServer (in inglese).

Appendice B

Appendice B - Configurazione di un modem ADSL Se non si dispone di un router per l’accesso ADSL, ma solamente di un modem, è necessario eseguire alcuni passi specifici per connettere il sistema Linux a Internet. I modem ADSL si suddividono in due categorie in base alla porta di connessione al computer: Ethernet oppure USB. Si sconsiglia di usare i modem USB in quanto sono più problematici da configurare in ambito Linux, vista la necessità di un driver specifico. Per questa tipologia di prodotti è bene verificare la compatibilità con il “pinguino” prima dell’acquisto, magari consultando il sito del produttore o i forum tecnici dedicati a Linux. In questa appendice si vedranno i passaggi necessari per rendere operativo un modem ADSL Ethernet. Prima di tutto il modem deve essere collegato alla porta Ethernet del computer attraverso un cavo di rete. Bisogna verificare a tal proposito che si disponga di un cavo corretto. A seconda dei modelli di modem potrebbe essere necessario un cavo “normale” oppure un cavo invertito (cross). Il manuale del prodotto può fornire informazioni precise in merito. In seguito, bisogna installare il pacchetto RP-PPPoE (Roaring Penguin PPPoE), che è l’implementazione più diffusa del protocollo PPPoE in Linux. Su molte distribuzioni RPPPPoE è preinstallato di default oppure si trova nei dischi di installazione o nei repository. Basterà installarlo con il gestore dei pacchetti della propria distribuzione e digitare il seguente comando: pppoe-setup

Partirà immediatamente una procedura guidata per la configurazione dell’accesso ADSL (in alcune distribuzioni il file di setup potrebbe chiamarsi adsl-setup). Se non è disponibile una versione binaria di RP-PPPoE per la propria distribuzione, si deve puntare alla pagina web http://www.roaringpenguin.com/products/pppoe e scaricare l’archivio sotto forma di sorgente. Quindi si deve spostare l’archivio in una directory temporanea e scompattarlo: tar -xzvf rp-pppoe-3.10.tar.gz

Il nome del file varierà a seconda della versione disponibile presso il sito del produttore. Si deve entrare nella directory appena creata per lanciare lo script automatico di compilazione: ./go

Alla fine del processo di compilazione partirà automaticamente la procedura di configurazione del sistema.

Configurazione di RP-PPPoE Il processo di prima configurazione è veloce e guidato. Verrà richiesta la user-id di accesso al provider, il nome di device dell’interfaccia Ethernet su cui è collegato il modem (eth0 nel caso ci sia una sola scheda di rete), se si vuole che la connessione sia permanente o che venga attivata solo su richiesta (dial on demand), gli indirizzi DNS, la password di accesso al provider e la modalità del firewall. Quest’ultimo aspetto è cruciale: usando un modem si è direttamente esposti a Internet e un utente esterno potrebbe essere in grado di accedere

ai servizi disponibili (condivisioni di Samba, pagine web, servizi di rete e così via). È quindi fondamentale attivare il firewall per evitare inconvenienti di questo tipo. Una volta inserite tutte le indicazioni richieste, comparirà una schermata di riepilogo. Confermando si salveranno le impostazioni su un apposito file di configurazione, concludendo la procedura. A questo punto disponibili saranno i seguenti comandi. pppoe-start: per attivare la connessione ADSL. pppoe-stop: per chiudere la connessione ADSL. pppoe-status: per verificare lo stato della connessione.

In alcune distribuzioni, questi comandi potrebbero chiamarsi rispettivamente adsl-start, adsl-stop e adsl-status.

Appendice C

Appendice C - Trasferimento dati utilizzando una chiavetta USB Le chiavi di memoria USB sono strumenti formidabili per trasferire dati tra computer. Il loro utilizzo su Linux è semplice, ma è necessario configurare alcuni aspetti del sistema. Per cominciare, si deve inserire la chiavetta in uno slot USB: il kernel riconoscerà immediatamente l’unità, stampando sulla shell un messaggio informativo. Esaminando queste informazioni si noterà che la chiavetta viene riconosciuta dal sistema come unità SCSI e subito associata a una periferica della directory /dev, per esempio sda. A questo punto bisogna individuare il nome della partizione, impartendo il seguente comando: fdisk –l

L’output sarà l’elenco di tutte le partizioni presenti. Tra queste dovrebbe essere visibile una riga con le generalità della partizione presente nella chiavetta USB. Questo, per esempio, è l’output relativo a una chiavetta da 2 gigabyte: Device Boot Start End Blocks Id System /dev/sda1 * 1 249 1999749+ b W95 FAT32

Si può notare che alla periferica corrisponde, nella directory /dev, il nome sda1, informazione che servirà più avanti. Ora si deve entrare nella cartella /mnt e creare la directory di appoggio per la chiavetta USB; per esempio, la si può chiamare key: cd /mnt mkdir key

Le operazioni preliminari sono concluse e non resta che configurare il file /etc/fstab. Questo file di sistema è dedicato alla raccolta delle informazioni sui file system che possono essere montati sul sistema Linux locale. Il file contiene già delle informazioni relative ai file system e ai dispositivi di memoria presenti sul sistema. Bisogna scorrere questo elenco e, in fondo, aggiungere una nuova riga per descrivere la chiavetta USB, per esempio: /dev/sda1 /mnt/key auto noauto

Il primo campo contiene il nome del device associato alla chiavetta e individuato in precedenza con il comando fdisk. Il secondo campo contiene il mount point, la directory, cioè, da cui partirà l’albero della chiavetta USB. Questa è stata creata in precedenza: /mnt/key. Nel terzo campo si deve indicare il tipo di file system. Generalmente le chiavette sono preformattate in modalità fat, ma per evitare problemi si può indicare auto e fare in modo che Linux determini il file system sull’unità. Il quarto campo contiene le opzioni. Bisogna indicare noauto per fare in modo che l’unità non venga montata automaticamente al momento del boot. Si avrebbe infatti un errore nel caso la chiavetta non fosse

inserita in una porta USB durante l’attivazione del sistema operativo. Ora si può salvare il file fstab e accedere al contenuto della chiavetta. Basta collegarla e digitare: mount /dev/sda1

Andando in /mnt/key si potrà accedere al contenuto della chiavetta. Finite le operazioni sulla chiavetta USB non è possibile staccare semplicemente l’unità dalla porta, come si fa abitualmente su Windows. Bisogna prima eseguire l’unmounting impartendo il comando: umount /mnt/key

È opportuno prestare attenzione a non impartire il comando mentre si è all’interno di una directory della chiavetta. In tal caso si avrebbe un messaggio d’errore, dal momento che non è possibile smontare un’unità quando si è dentro l’unità stessa. Prima dell’unmounting è bene impartire il comando sync per salvare sui dischi tutti i dati presenti nei buffer in memoria.

Appendice D

Appendice D - Trasferimento dati utilizzando floppy disk Tutte le unità rimovibili che si usano con Linux devono essere montate e poi smontate con gli appositi comandi di sistema mount e umount. Fortunatamente è possibile evitare tutto questo con i floppy disk sfruttando il pacchetto mtools. Si tratta di una collezione di strumenti che permettono di manipolare i file e le directory presenti su dischetti formattati in modalità fat. La seguente tabella elenca i comandi disponibili. Comando mtools Corrispettivo DOS Descrizione mattrib

attrib

Cambiamento di attributi DOS.

mcd

cd

Cambiamento directory corrente.

mcopy

copy

Copia di file DOS da o verso Linux.

mdel

del

Cancellazione di file.

mdeltree

deltree

Cancellazione ricorsiva di una directory.

mdir

dir

Visualizzazione del contenuto di una directory.

mlabel

label

Applicazione di un nome di volume.

mmd

md

Creazione di una directory.

mmove

move

Spostamento di file DOS da o verso Linux.

mrd

rd

Cancellazione di una directory DOS.

mren

ren

Ridenominazione di un file DOS.

mtype

type

Visualizzazione di un file testuale DOS.

La sintassi dei comandi simula l’ambiente DOS, come si può evincere dai comandi descritti di seguito. mdir a:

Visualizza l’elenco delle directory presenti nel floppy. mcopy /home/szanzi/listino.txt a:

Copia nel floppy presente nel drive il file listino.txt presente nella directory Linux /home/szanzi. mdel nota4.txt

Cancella il file nota4.txt presente nella radice del floppy. mmd test

Crea la directory test nella radice del floppy. mcopy /home/amm5/frame1.jpg a:/test

Copia il file frame1.jpg della directory Linux /home/amm5 nella directory test del floppy. mdir a:/test

Visualizza il contenuto della directory test del floppy. mcopy a:/test/21.jpg /home/amm1

Copia il file 21.jpg presente nella directory test del floppy nella directory Linux /home /amm1. In tutti questi esempi non è stato necessario usare i comandi mount e umount ed è stato possibile inserire o togliere liberamente i floppy dal drive.

Appendice E

Appendice E - Formati e installazione di pacchetti Il formato con cui si è storicamente distribuito il software in ambiente Unix è il sorgente. Lo sviluppatore rendeva cioè disponibile il codice ed era compito dell’utente compilare il programma in formato binario attraverso gli strumenti di sviluppo presenti nella propria piattaforma. Questa modalità ha un certo numero di vantaggi, ma rende la distribuzione del software estremamente complicata, se non impossibile, per gli utenti che non hanno alcuna formazione informatica e che usano i computer come meri strumenti. Per sopperire a questa carenza sono state sviluppate modalità per distribuire il codice in maniera già compilata, come avviene normalmente nelle altre piattaforme come Windows, Mac OS X e così via. Il compito non è così semplice in ambito Unix, dal momento che esistono parecchie varianti del sistema operativo e molte piattaforme hardware, del tutto incompatibili tra loro. Unix è probabilmente il sistema operativo più plurale mai esistito e questa apertura si paga con una minor facilità nella gestione di programmi già compilati. Il problema è stato affrontato anche da una delle più famose varianti di Unix: Linux. Tra i vari approcci tentati, quelli che hanno ottenuto maggiore seguito sono le visioni di Red Hat e di Debian. Questi due nomi hanno realizzato uno standard per definire il modo in cui un applicativo compilato deve essere “impachettato” per poter essere distribuito e le modalità che gli utenti devono seguire per installare il software nel sistema e per gestire il ciclo di vita del programma.

I pacchetti su Red Hat Il formato RPM promosso da Red Hat ha un’ampia diffusione per via della quantità di distribuzioni derivate di successo, come SuSE, CentOS, Fedora Core, Mandriva e così via. Il software compilato viene impacchettato sfruttando una fase di compressione e di gestione dell’integrità. Viene inoltre incluso uno script di shell per la gestione del pacchetto. Al pacchetto viene fornito un nome che dovrebbe identificare il software e la piattaforma a cui è destinato. Non è infatti detto che un pacchetto sviluppato per una determinata distribuzione possa funzionare anche su una distribuzione completamente differente, nonostante entrambe derivino da Red Hat. Per installare un pacchetto RPM all’interno di un sistema basato su Red Hat si utilizza questa sintassi: rpm - i

Difficilmente si riuscirà a installare attraverso questo comando un pacchetto appena scaricato o prelevato dal CD-ROM dell’installazione. Ogni pacchetto necessita infatti di altri pacchetti per poter funzionare, quali librerie di sistema, strumenti di gestione, demoni specifici, componenti di sistema e così via. Ogni sviluppatore crea un prodotto presupponendo la presenza di un particolare ambiente, che magari non tutti gli utenti hanno nel proprio sistema. È quindi sempre necessario allinearsi ai requisiti minimi. In fase di installazione saranno elencati i pacchetti mancanti e sarà compito dell’amministratore acquisirli e installarli nel sistema, per poi ritentare l’installazione del pacchetto originario. Purtroppo però anche i pacchetti richiesti avranno a loro volta delle richieste di dipendenze. L’installazione di un pacchetto potrebbe portare a una fase “esponenziale” di procedure di installazione di pacchetti dipendenti. Questo grande limite è stato

mitigato dai gestori di dipendenze, in grado di verificare le relazioni e di scaricare e installare automaticamente tutto il software necessario. In ambito Red Hat è particolarmente famoso lo strumento yum. La procedura precedente di installazione diventa quindi la seguente: yum install

L’installazione avverrà sfruttando un repository, ovvero una risorsa online contenente i pacchetti della distribuzione, svincolandosi dai CD-ROM. Il comando yum è molto comodo anche per mantenere aggiornato il sistema. È sufficiente infatti digitare il comando seguente per avere il sistema sempre allineato alle ultime versioni dei pacchetti presenti: yum update

La rimozione di un pacchetto avviene utilizzando nuovamente il comando RPM: rpm -e

Durante l’operazione potrebbe essere evidenziato che il pacchetto che si intende rimuovere è necessario per il funzionamento di altri pacchetti installati. La rimozione impedirebbe in questo caso il funzionamento dei pacchetti in oggetto.

I pacchetti su Debian Debian ha una filosofia di gestione dei pacchetti che è stata sempre acclamata per via della sua pulizia implementativa e per una migliore gestione del problema delle dipendenze. Il formato, denominato DEB, è presente su tutte le distribuzioni derivate, per esempio Ubuntu. L’installazione di un pacchetto avviene tramite il comando dpkg: dpkg -i

La procedura inversa si ottiene con la seguente sintassi: dpkg -r

Normalmente si utilizzerà però il gestore dei pacchetti apt-get. Questo programma è in grado di scaricare da un repository il pacchetto richiesto e di gestire le dipendenze. Per installare un pacchetto si utilizza questa sintassi: apt-get install

La rimozione avviene invece con questa sintassi: apt-get remove

Il sistema potrà invece essere mantenuto aggiornato tramite questa sequenza: apt-get upgrade

Appendice F

Appendice F - Repository Un repository è un archivio online contenente i pacchetti di una specifica distribuzione. Tutte le distribuzioni moderne hanno repository ufficiali, suddivisi per versione della distribuzione e mantenuti aggiornati in base alle politiche della casa madre o del gruppo che promuove la distribuzione. I repository ufficiali possono essere affiancati da repository di terze parti, gestiti da aziende, da gruppi o da singoli utenti, con lo scopo di fornire pacchetti che non sono previsti nei repository ufficiali. Il repository intende essere una risorsa utile per gestire una postazione Linux, svincolandosi dai CD-ROM di distribuzione o dalla necessità di cercare e scaricare manualmente i pacchetti che si intendono installare.

Repository su CentOS Sulla distribuzione CentOS i repository utilizzati dal gestore dei pacchetti yum sono elencati nei file presenti dentro il percorso /etc/yum.repos.d. I file presenti all’interno di questa directory contengono le informazioni necessarie a yum per accedere ai repository. Aprendo in lettura il file CentOS-Base.repo si possono osservare un certo numero di blocchi di definizione contenenti il percorso del repository e le informazioni di gestione, come in questo esempio: [base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

La prima riga contiene un tag identificativo racchiuso tra parentesi. Segue il nome del repository e il percorso espresso in questo caso come lista di mirror (comando mirrorlist) e non come indirizzo assoluto (comando baseurl, commentato). Seguono due comandi per la gestione dell’integrità dei pacchetti tramite una chiave crittografica. Il primo di questi attiva la gestione mentre il secondo contiene l’indirizzo della chiave GPG. È possibile aggiungere nuovi repository rispettando questa sintassi. Un repository RPM molto famoso è DAG, gestito da Dag Wieërs presso l’indirizzo http://dag.wieers.com. Questo repository contiene una moltitudine di software pacchettizzato per le distribuzioni basate su Red Hat. Per abilitare questo repository è sufficiente andare in fondo al file CentOS-Base.repo e aggiungere queste righe: [dag] name=Dag RPM Repository for Red Hat Enterprise Linux baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag/ gpgcheck=1 gpgkey=http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt enabled=1

Per maggiori informazioni si può consultare la FAQ messa a disposizione dal gestore del repository

all’indirizzo http://dag.wieers.com/rpm/FAQ.php.

Repository su Ubuntu Su Ubuntu l’elenco dei repository si trova nel file /etc/apt/sources.list. Si tratta di un elenco di risorse, come evidenziato dall’esempio seguente, estratto da una distribuzione Ubuntu: deb http://security.ubuntu.com/ubuntu hardy-security main restricted deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted deb http://security.ubuntu.com/ubuntu hardy-security universe deb-src http://security.ubuntu.com/ubuntu hardy-security universe

La prima parola chiave indica se si tratta di un archivio di file binari (deb) oppure di file sorgenti (debsrc), segue il percorso del repository e una serie di indicazioni circa la versione della distribuzione e i rami da considerare. Una volta aggiunto un nuovo repository è necessario aggiornare l’indice dei file con il seguente comando: apt-get update

Come per la CentOS è possibile aggiungere repository di terze parti semplicemente aggiungendo in fondo a questo file le indicazioni relative.

Linux Server per l'amministratore di rete Silvio Umberto Zanzi EAN: 9788850311941

Licensed to:

Questo libro è stato acquistato da Gary Clark [email protected] il 04/12/2011 21:39 Codice della transazione: y1sEWcVU3MAAAE0EMM9FwrN Numero dell ordine: 00151441 Date of purchase: December 04, 2011 through LibreriaRizzoli.it Customer identifier: GfusEWcV5FAAAAE01MM9FwrF Transaction number: y1-sEWcVU3MAAAE0EMM9FwrN The contents and components of this eBook, including but not limited to all text, images, graphics, video, pictures and trademarks, are protected by national and international intellectual property laws, and are entirely owned by its publisher. You are granted a non-exclusive non-transferable limited personal license to download and view the contents for your personal, non-commercial, private use. The download and use of the eBook does not grant any ownership in or to any of that content. The modification, editing, republication, resale, renting, distribution or transfer, by any means or in any manner, of all or part of the eBook, to any other party are strictly forbidden without prior written consent from the publisher. The seller declines all responsibility regarding the contents of the eBook. In no event shall the seller or the publisher be liable for any direct or indirect damages arising out of the use of, or inability to use the eBook. The publisher reserves all rights not expressly granted hereby.