Download, configurazione ed installazione di apache

Transcript

1 INDICE INDICE Introduzione Caratteristiche principali Breve descrizione dell architettura Download, configurazione ed installazione di apache Configurazione del sorgente ed installazione Tools aggiuntivi Configurazione del server Direttive ServerRoot KeepAlive, Timeout, MaxKeepAlive Request, KeepAlive Timeout IfModules StartServers, MaxClients, MinSpareThreads, MaxSpareThreads, ThreadsPerChild, MaxRequestPerChild Port e Listen User e Group ServerAdmin DocumentRoot Directory UserDir DirectoryIndex AccessFileName Files UseCanonicalName ErrorLog, LogLevel, CustomLog Alias ScriptAlias Start e stop del server apache Configurazione del sistema per lo start automatico Verifica del funzionamento di apache Direttive in dettaglio Direttive generali ErrorDocument Include Options LoadModule Direttive container <Directory> <Files> <Location> <DirectoryMatch>, <FilesMatch>, <LocationMatch> <VirtualHost> NameVirtualHost Server principale e e name-based virtual host ServerAlias Apache

2 Autenticazione e gestione degli utenti con il web server apache Differenze tra autenticazione ed autorizzazione AllowOverride AuthType <Limit> <LimitExcept> LimitRequestBody Require Autenticazione ed autorizzazione tramite il modulo mod_auth AuthUserFile AuthGroupFile Esempio di implementazione di autenticazione Esempio di accesso tramite il file.htaccess Raggruppamento di utenti ed accessi per directory Autenticazione ed autorizzazioni tramite hostname od IP address allow deny order Utilizzo combinato di autorizzazione ed autenticazione Il sistema di autenticazione ed i DB La cifratura dei dati tra il web server apache ed i browser Metodologie di implementazione del protocollo SSL Installazione e configurazione di SSL in apache tramite mod_ssl Verifica del funzionamento Apache

3 Introduzione Apache è un web server open source. Le caratteristiche principali di apache sono le seguenti: Apache ha una struttura modulare. Alcuni moduli possono essere abilitati o disabilitati; è dunque possibile configurare Apache in base alle proprie necessità e con le prestazioni migliori. Inoltre, chiunque, con conoscenze Perl o C, può scrivere dei moduli personalizzati. PHP supporta tutti i linguaggi di scripting più diffusi quali Perl, PHP, Python ed in generale tutti i linguaggi di scripting utilizzati per fare i CGI. Apache funziona su qualsiasi piattaforma Unix, quali Linux, Solaris, AIX, ecc. Apache funziona anche in ambiente Windows. Caratteristiche principali Apache ha le seguenti caratteristiche: È compatibile con HTTP 1.1 È compatibile con i CGI Supporta i virtual hosts Linguaggio Perl integrato Perfettamente integrato con PHP (ha un modulo dedicato) in concomitanza con il Database MySQL (ha un modulo dedicato) Supporto delle servlet e JSP Proxy server integrato Controllo dello stato del server e file di log completamente personalizzabili Supporto dei server side include (SSI) Supporto del protocollo di sicurezza SSL Breve descrizione dell architettura Come già detto in precedenza, l architettura di Apache è modulare. Più precisamente l architettura è MPM (Multi Processin Module). Precedentemente, fino alla versione 1.3 (ancora disponibile), invece del MPM, l architettura era di tipo preforking. Il preforking monitorava i processi children e ne creava o distruggeva (kill) un numero adeguato in base al carico del momento. Quest architettura non è compatibile con Windows. Per questo motivo, al fine di avere la piena compatibilità anche con Windows, è stato introdotto l MPM. Con l MPM, c è un numero prestabilito di processi di partenza (modificabile in base alle proprie esigenze). Ognuno di questi processi (children) può gestire un numero appropriato di threads. Viene creato un thread per ogni connessione, nascondendo a Window la proliferazione di processi children in funzione delle connessioni. Download, configurazione ed installazione di apache Apache può essere prelevato alla URL Apache, attualmente viene distribuito in due modalità: Apache

4 precompilato o in formato binario (solo per piattaforme windows), ed in codice sorgente (per Window e Unix.). Con il formato binario, è possibile installare Apache come un qualsiasi programma Windows, dove solitamente c è un Wizard con un tasto avanti ed eventuali dettagli da indicare. Con il codice sorgente, è necessario un compilatore C per poter generare e successivamente installare Apache. Sebbene apparentemente la prima modalità sembri più comoda, la compilazione permette di personalizzare il web server omonimo secondo le proprie necessità, permettendo quindi un ottimizzazione ed un miglioramento delle prestazioni. Configurazione del sorgente ed installazione La configurazione viene effettuata tramite il comando./configure (in Unix). Il comando viene seguito dalle opzioni che l installazione riterrà più appropriate. Alcuni esempi possono essere: --prefix=/usr/local/apache (indica il percorso di destinazione dove verrà installato apache) od ancora --enable=mod_ssl per abilitare l utilizzo del protocollo SSL. Per vedere tutte le possibili opzioni si consiglia di consultare la documentazione. Tra le varie opzioni, un altra molto importante è quella che permette di far funzionare apache con il caricamento dinamico dei moduli (questi vengono caricati nel server solo quando se ne presenta la necessità), oppure vengono direttamente integrati nel core di apache. Nel caso di caricamento dinamico, i moduli vengono compilati come DSO (Dynamic Shared Object). Per fare in modo che un modulo sia gestibile come dinamico è necessario utilizzare il parametro shared; ad esempio:./configure --prefix=/path/to/install --enable-foo=shared make install È anche possibile fare in modo che tutti i moduli esclusi quelli del core siano resi dinamici:./configure --enable-so make install Tuttavia, nel caso un modulo venga reso dinamico, è necessario che nel file dio configurazione di apache venga abilitato il caricamento di quest ultimo tramite il comando LoadModule (Vedi paragrafi successivi dove viene descritta questa direttiva) Successivamente, deve essere generato l eseguibile binario. Per effettuare ciò, si deve digitare il comando make. Infine, si deve impostare il comando make install affinché tutta la distribuzione ed i file di Apache vengano correttamene installati nelle relative directory di destinazione. Tools aggiuntivi Dopo aver installato Apache, oltre al server, vengono forniti anche alcuni applicativi di gestione. Tra i più importanti il comando ab, per verificare i benchmark del server, apachectl per fermare, far partire il server, apxs per gestire i moduli estesi, htpasswd per gestire le utenze e rotatelogs per gestire i file di log Apache

5 Configurazione del server Con la sezione precedente, abbiamo configurato il server (includendo i moduli che si ritengono più opportuni all interno del file eseguibile) ed abbiamo effettuato l installazione. Ora è necessario configurare il funzionamento vero e proprio del server (nome del server, privilegi, utenti e le varie modalità di funzionamento). Sebbene i file di configurazione del server siano diversi, il più importante è il file httpd.conf Questo file è uguale, sia per le piattaforme Unix che per quelle Windows. Vi sono due tipi di informazioni all interno di questo file: direttive e commenti. Le direttive possono a loro volta essere globali (riguardano il funzionamento dell intero server) oppure relative al singolo virtual host. Inoltre i virtual hosts possono essere anche in file separati. Figura 1 Direttive Analizziamo ora le direttive più importanti per configurare il server e farlo partire in una moalità di base. Relativamente alla configurazione globale del server abbiamo: Apache

6 ServerRoot Questa direttiva indica la directory radice (root) dell intero web server. Rappresenta la directory dove sono presenti file ed ulteriori sottodirectory relative ai file binary del web, file di configurazione, log, tools di supporto, ecc. Figura 2 Sotto la directory logs, normalmente c è anche un file chiamato httpd.pid il quale contiene l ID del processo del web server. KeepAlive, Timeout, MaxKeepAlive Request, KeepAlive Timeout Questi parametri normalmente non dovrebbero essere modificati. Sono un insieme di parametri che definiscono, i tempi di sconnessione se quest ultima non è stata ulteriormente utilizzata, e tempi di refresh della stessa, per permettere che la connessione non termini entro un determinato periodo. IfModules Questo parametro, definisce altri parametri, qualora uno specificato modulo sia stato caricato. Ad esempio <IfModule threaded.c> StartServers 3 MaxClients 8 MinSpareThreads 5 MaxSpareThreads 10 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule> Apache

7 Qualora sia stato caricato il modulo threaded.c, automaticamente i parametri inclusi in IfModule assumono i valori sopraindicati. StartServers, MaxClients, MinSpareThreads, MaxSpareThreads, ThreadsPerChild, MaxRequestPerChild Questi parametri regolano il funzionamento dell MPM; definiscono il numeri di processi dedicati al singolo client, quanti threads possono essere definiti per ogni processo, ecc. Port e Listen Questi parametri indicano la porta su cui funziona il server. Il default naturalmente è 80. Port indica la porta di default su cui gira il web server principale e fa riferimento all indirizzo IP principale del sistema operativo. Qualora il SO abbia più indirizzi IP su una o più interfacce e siano siti creati più virtualhosts (più siti web gestiti da un unico apache server), è necessario specificare gli indirizzi IP tramite il comando Listen, eventualmente seguiti dal numero di porta separato dal carattere :. Quindi ad esempio se la macchina ha come secondo (o superiore) indirizzo IP e si voglia utilizzare questo per un virtualhost sulla porta 8080, sarà necessario inserire la riga Listen :8080 In alcune versioni non viene più utilizzata la direttiva Port ma esclusivamente la direttiva Listen. Infatti Port 80 equivale a scrivere Listen 80. User e Group Questi due parametri indicano con quale utenza Unix devono essere attivi i processi del server. Normalmente viene indicato nobody e nogroup (oppure la coppia -1, -1) per entrambi i parametri. Quest utenza viene utilizzata qualora il root effettua lo start dei processi. Questi ultimi non funzioneranno con l utenza root (come normalmente accada per un processo lanciato da root) ma con l utenza definita dai due parametri in esame. In questo modo si evitano problemi di sicurezza. Infatti, qualora un malintenzionato riuscisse a prendere il controllo dei processi del web server, troverebbe dei processi nobody anziché root, quindi senza alcun privilegio particolare di accesso al sistema. Utilizzando root come utenza per fare lo start dei processi di apache, è possibile fare in modo che questi funzionino sulla porta 80 che è la porta di default per il protocollo HTTP, sebbene i processi risultino appartenenti a nobody e nogorup. Un utente senza privilegi di root, non può lanciare processi su porte con valori inferiori a Qualora si voglia eseguire un processo su porte maggiori di 1024 (la URL sarà ad esempio è possibile utilizzare un utenza diversa da root (non stiamo parlando di nobody e nogroup ma dell utenza effettivamente utilizzata dalla persona che vuole far partire il processi, ad esempio rossi ). In questo modo i parametri User e Group non verranno presi in considerazione dal processo che funzionerà come appartenete all utenza che è stata utilizzata per fare lo start Apache

8 ServerAdmin Questo parametro indica un indirizzo di . Questo indirizzo compare in eventuali pagine di errore relative al malfunzionamento del server, per indicare la persone di riferimento a cui rivolgersi. DocumentRoot Questo parametro indica un percorso. Più precisamente indica la directory radice della pagina HTML di default del web server. Quindi supponendo di indicare: DocumentRoot C:/Documenti/Sito/Home (si noti che anche in un sistema operativo Windows, il percorso viene indicato con lo slash / anziché il backslash \ come dovrebbe essere normalmente) si potrebbe ad esempio avere la URL In questo caso, il file prova.html sarebbe proprio nella directory Home indicata, che sarebbe totalmente invisibile all utente. Eventuali sottodirectory invece, saranno indicate nella URL. Se per esempio si vuole utilizzare il file prova2.html nella directory C:/Documenti/Sito/Home Home/cars, la URL sarà Normalmente, in un ISP, un web server gestisce più siti. Può essere utili effettuare un albero di questo tipo: Figura Apache

9 Directory Questa direttiva viene utilizzata tramite tag: <Directory /> Optinon FollowSymLinks AllowOverride None </Directory> Questa direttiva agisce sulla directory radice (si noti il carattere / ); se volessimo agire su /usr/local, il tag di apertura sarebbe <Directory /usr/local>. All interno del tag vengono visualizzati i parametri che si vogliono applicare alla directory in esame. Poiché agiamo sulla directory root, questa direttiva verrà applicata anche su tutte le sue sottodirectory relative ad uno specifico sito (se abbiamo più siti la direttiva non agirà sugli altri). Qualora sia necessario, in una sottodirecoty, effettuare delle direttive diverse dalla root, queste potranno essere impostaste sempre tramite il tag in esame. Il parametro Option indica nel nostro esempio il parametro FollowSymLinks, cioè abilita l utilizzo di link simbolici Unix (ovvero il web li utilizza come file o directory se questi esistono ed indipendentemente da dove essi puntano). Naturalmente possono essere inclusi altri parametri. Infine AllowOverride None disabilita la possibilità, da parte degli utenti, di definire una propria configurazione di accesso web alle proprie directory contenti le pagine HTML. Ciò verrà visto in maggior dettaglio nei paragrafi successivi. UserDir Questo parametro indica la directory in cui il singolo utente Unix può inserire le proprie pagine HTML. Normalmente al di sotto della propria home directory, viene definita la directory public_html in cui porre le pagine. La corrispondente URL sarà il nome del sito seguito dal carattere ~ e quindi dall utenza Unix: DirectoryIndex Questo parametro indica la o le pagine di default, che non devono essere indicate nella URL ma che vengono caricate ugualmente. Per esempio se si vuole che la URL carichi in modo automatico la pagine index.html, questa dovrà essere indicata nel parametro in esame. Possono essere indicate più pagine che verranno cercate nell ordine indicato. Se nessuna di queste viene trovata, il web server farà vedere il contenuto della directory: Apache

10 Figura 4 AccessFileName Questo parametro indica il nome del file che l utente può mettere nelle proprie directory dove ha le pagine HTML, in modo da gestire le modalità di accesso, username, password, e definire direttive personalizzate, indipendentemente dalla configurazione generale del web server. Normalmente il nome è.htaccess In altre parole, l'amministratore può configurare il web server in modo che tutti gli utenti proprietari di una o più directory, possano utilizzare il file.htaccess. Questo file sostituisce alcune direttive impostate dall amministratore del web server con quelle indicate in esso. Può essere utile se l'amministratore di sistema vuole demandare ai propri clienti come gestire nelle loro directory i diritti di accesso ad esse. Files Questa direttiva è un tag che può ad esempio essere applicata nel seguente modo: <Files ~ ^\.ht > Order allow, deny Deny from all </Files> In questo caso la direttiva viene applicata a tutti i file che iniziano con.ht (quindi i file.htaccess) e applica le regole che sono contenute nel tag. In questo casi si nega l accesso ai file Apache

11 UseCanonicalName Se non indicati diversamente, quando compare un nome di file in un link HTML, automaticamente il server associa il nome del sito ad esso. ErrorLog, LogLevel, CustomLog La prima direttiva indica il nome dei file dove vengono salvati i messaggi di errori, la seconda direttiva indica il livello di dettaglio con cui si vogliono i messaggi e la terza direttiva permette di personalizzare il formato dei messaggi. Alias Questa direttiva permette di modificare i path nelle URL con degli alias. Per esempio il percorso /usr/local/icons potrebbe essere trasformato semplicemente in /icons. Quest ultima compare nella URL senza che l utente ne veda la vera struttura ad albero. ScriptAlias Questa direttiva permette, in analogia precedente di ridefinire il percorso dei CGI, in modo da nascondere la vera collocazione sul filesystem del server. Esistono svariate altre direttive descritte sui manuali a cui rimandiamo per maggiori dettagli. Start e stop del server apache Per far partire il server si utilizza il comando apachectl start Diversamente per fermarlo si utilizza il comando apachectl stop Dopo aver modificato il file di configurazione del server è sempre necessario fare il restart del server. Prima di fare ciò, è bene effettuare apachectl configtest. Qualora vi siano dei problemi con la nuova configurazione tale comando lo indica, evitando un eventuale fermo del servizio troppo lungo. Infatti se la configurazione è errata, può succedere che il server non riesca a partire. È quindi bene, prima di effettuare lo stop del servizio, verificare che la configurazione è corretta. Dopo che il server è partito, per verificarne la corretta funzionalità e che l utenza con cui è partito è quella corretta, si può utilizzare il comando ps auxw grep http Configurazione del sistema per lo start automatico Bisogna prevedere che il web server parta in modo automatico. Sarà quindi necessario modificare gli script di partenza nel sistema Unix, oppure in Windows, verificare la partenza automatica del servizio, tramite l'icona Servizi Apache

12 Relativamente ad Unix, il comando apachectl è già uno script compatibile con i file di startup dei sistemi Unix System V, infatti accetta i parametri start, stop, restart, ecc. Dunque sarà sufficiente effettuare i link del file nelle directory rc.n dove n è il livello di startup del sistema Unix. Verifica del funzionamento di apache Molto utile per vedere l andamento in tempo reale del server, è utilizzare il comando tail f applicato al file di log del server. È possibile vedere i log che vengono introdotto in tempo reale. I file di log risiedono nella directory logs di apache. Gli errori vengono inviati nel file error.log Direttive in dettaglio Abbiamo già visto in parte le direttive che è necessario conoscere per fare lo start del server. Analizziamo in dettaglio ulteriori direttive per effettuare configurazioni più sofisticate. Le direttive si dividono in tre classi: Direttive generali per il server. Queste definiscono il funzionamento generale del server. Direttive container. Queste sono direttive che si applicano a directory od a file specifici. Direttive per singola directory per utenti. Queste direttive vengono inserite e gestite dagli utenti, tramite il file.htaccess che agisce nella directory in cui esso è contenuto. Direttive generali Alcune delle direttive sono già state analizzate in precedenza. Vediamo ulteriori dettagli ErrorDocument Questa direttiva permette, per ogni errore generato dal server, di associare un messaggio od una pagina web. Ad esempio per il noto errore 404, si può effettuare la seguente configurazione: ErrorDocument 404 Richiesta non valida oppure ErrorDocument 404 /errors/404_error.html Include Questo parametro permette di includere file di configurazione esterni al file httpd.conf Per esempio i virtual host, se si desidera, possono essere gestiti a parte. Include virtual_host1.conf Include virtual_host2.conf Apache

13 Options Il parametro Options viene utilizzato per definire delle regole di funzionamento del server, all interno di una specifica directory. La sintassi generale è la seguente: Options [+ -]opzione [+ +]opzione [+ -]opzione I simboli + e - abilitano o disabilitano rispettivamente l opzione che li segue. Le opzioni indicate sono riportate nella seguente tabella: Un esempio di applicazione è la seguente: <Directory /www/customer> Options Indexes +FollowSymLinks </Directory> LoadModule Come visto in precedenza, i moduli vanno inseriti nel momento di compilazione del server oppure si può attivare il DSO che implica un caricamento dinamico dei moduli. Tuttavia non è sufficiente effettuare questa operazione. Nel file di configurazione del server è necessario attivare i moduli. Per fare ciò si utilizza LoadModule seguito dal nome dei moduli che si desidera attivare. Ad esempio: LoadModule access_module modules/mod_access.so Direttive container Le direttive di tipo container sono le seguenti: Apache

14 <Directory> e <Files>. Queste direttive contengono ulteriori direttive che vengono applicate alle directory ed ai file indicati dalla direttive in questione. Queste direttive non possono essere utilizzate nei file.htaccess che già sono dedicati alla directory che li contiene <Location>. Queste direttive vengono applicate alle URTL indicate. Non possono essere quindi utilizzate nei file.htaccess <DirectoryMatch>, <FilesMatch>, <LocationMatch>. Vengono utilizzate in modo particolare se si usano le espressioni regolari. <VirtualHost>. Direttive che vengono utilizzate per definire i virtual host. <Directory> Questa direttiva è già stata vista in precedenza. Essa applica alla directory indicata, quanto contenuto all interno dei tag. È possibile utilizzare anche i wildcard come? e * Dunque ad esempio, è possibile scrivere <Directory /sito?> </Directory> Questa directory verrà applicata a tutte le directory sotto la ServerRoot di nome sito seguite da un carattere qualsiasi, ad esempio sito1, sito2, ecc. È anche possibile utilizzare le espressioni regolari (regex). Quindi ad esempio <Directory ~ ^/www(.* > </Directory> Individua tutte le directory che iniziano con www. <Files> È analoga a quanto vista nel paragrafo precedente ma viene applicata al singolo file anziché alla singola directory. <Location> Questa direttiva viene applicata alle URL a cui accede l utente. Quindi ad esempio <Location </Location> applicherà le regole indicate all interno dei tag, per la URL in esame Apache

15 <DirectoryMatch>, <FilesMatch>, <LocationMatch> Queste direttive sono uguali alle precedenti, con l unica differenza che non è necessario utilizzare il simbolo ~ nell impostazione delle regex. <VirtualHost> Come già detto in precedenza, un web server apache supporta la possibilità di gestire più siti (in gergo virtual host). Questo è molto utile per chi come gli ISP devono gestire più siti, senza dover necessariamente utilizzare più macchine o sovraccaricare quest ultime con la presenza contemporanea di più server. Molte delle direttive che abbiamo utilizzato fino ad ora sono applicabili ai virtual hosts, naturalmente escluse quelle relative al funzionamento generale del web server. Esistono due modalità di definizione dei virtual host, la cosiddetta configurazione address-based o IP-based e la configurazione name-based. Mentre la IP-based prevede che per ogni virtual hosts, al computer che contiene il web server venga assegnato un indirizzo IP ed uno per ogni sito ( sulla singola o su diverse interfacce di rete), con la modalità name-based, all unico indirizzo IP della macchina, vengono associati più nomi (uno per ogni sito). Vediamo alcuni casi di definizione di virtual host: Un IP address. <VirtualHost >... </VirtualHost> An IP address with a port number. <VirtualHost :8080>... </VirtualHost> Multiple IP addresses. <VirtualHost >... </VirtualHost> Multiple IP addresses with port numbers. <VirtualHost : :10000>... </VirtualHost> Vediamo ora le direttive necessarie per configurare le due modalità di virtual host. Per definire un sito name-based bisogna utilizzare la seguente direttiva prima del tag <VirtualHost>: Apache

16 NameVirtualHost Questa direttiva è seguita dall indirizzo IP (può anche essere utilizzato il nome del sito ma è preferibile l indirizzo IP) eventualmente seguito da un carattere : e dall eventuale numero di porta. Si ricorda che se la porta non è indicata, per default si intende che venga utilizzata la porta 80. Una configurazione name-based potrebbe essere la seguente: ServerName NameVirtualHost <VirtualHost > ServerName DocumentRoot "C:/Apache/siti_clienti/sito" </VirtualHost> oppure ancora: ServerName NameVirtualHost * <VirtualHost *> ServerName DocumentRoot "C:/Apache/siti_clienti/sito1" </VirtualHost> <VirtualHost *> ServerName DocumentRoot "C:/Apache/siti_clienti/sito2" </VirtualHost> In questo caso, il simbolo * indica di utilizzare le regole all interno del tag VirtualHost per tutti gli indirizzi che ha il computer. Un altro esempio potrebbe essere il seguente: <VirtualHost *> ServerName DocumentRoot /www/htdocs ErrorDocument 404 /site_list.html </VirtualHost> Invece, un esempio di sito IP-based potrebbe essere: ServerName <VirtualHost > ServerName DocumentRoot "C:/Apache/siti_clienti/sito1" </VirtualHost> <VirtualHost > ServerName Apache

17 DocumentRoot "C:/Apache/siti_clienti/sito2" </VirtualHost> Infine possiamo avere un esempio di configurazione mista: ServerName NameVirtualHost NameVirtualHost <VirtualHost > ServerName DocumentRoot "C:/Apache/siti_clienti/sito1" </VirtualHost> <VirtualHost > ServerName DocumentRoot "C:/Apache/siti_clienti/sito2" </VirtualHost> <VirtualHost > ServerName DocumentRoot "C:/Apache/siti_clienti/sito3" </VirtualHost> <VirtualHost > ServerName DocumentRoot "C:/Apache/siti_clienti/sito4" </VirtualHost> Affinché tutto questo funzioni, è necessario attivare i vari server tramite il comando Listen, ad esempio Listen Listen Qualora si vogliano porre dei virtualhost su porte diverse dalla porta 80 è possibile digitare: <VirtualHost :8080> </VirtualHost> Così come, se si utilizza il name-based, è necessario specificare NameVirtualHost :8081 Anche in questi ultimi due casi è necessario definire: Listen :8080 Listen :8081 Naturalmente per definire questi server è necessario apportare alcune modifiche al DNS: Apache

18 File db.sito1.it IN A File db.sito2.it IN A File db.sito3.it IN A per i relative file di reverse sarà necessario impostare una configurazione simile a : File reverse db IN PTR File reverse db IN PTR File reverse db.10 1 IN PTR Server principale e e name-based virtual host Come visto fino ad ora, è possibile configurare dei parametri globali di funzionamento del server (che chiameremo main server) senza virtualhost, oppure come visto nel paragrafo precedente è possibile definire dei virtuahost. È necessario comprendere come le richieste provenienti dai browser vengono inviate ai virtualhost eventualmente definiti all interno del server. Le direttive del main server verranno utilizzate solo se le direttive dei virtualhost non si sovrappongo alle prime. Dunque un virtualhost definito con lo stesso nome od indirizzo IP del main server si sovrapporrà a quest ultimo. A fronte della provenienza di una richiesta da un browser, il server verifica se questa soddisfa l'indirizzo indicato nella direttiva NameVirtualHost. In caso positivo, il server verifica per ogni tag <VirtualHost> quelli che contengono lo stesso indirizzo IP indicato nella richiesta, e tra tutti quelli individuati, seleziona quello con il parametro ServerName uguale a quello indicato nella richiesta. Se nessuno soddisfa il ServerName, viene selezionato il primo VirtualHost con l indirizzo IP corretto. Conseguentemente, il primo VirtualHost della lista è il default VirtualHost. La direttive DocumentRoot del main server non verrà,ai utilizzata se un indirizzo IP soddisfa la direttiva NameVirtualHost. ServerAlias È possibile, per il singolo virtual host, definire uno o più alias Per verificare le direttive che possono essere utilizzate nei virtual host, si rimanda alla documentazione del server Apache

19 Autenticazione e gestione degli utenti con il web server apache Il responsabile del web server ed i responsabili dei vari virtual hosts, possono avere la necessità di gestire come gli utenti accedono ai rispetti siti. Per questo motivo è necessario implementare delle procedure di autorizzazione ed autenticazione degli utenti. Differenze tra autenticazione ed autorizzazione L'autenticazione consiste nella fase di riconoscimento dell utente. Normalmente, per quanto riguarda un sito web, questo consiste nel dover digitare, da parte dell utente che vuole accedervi, una username ed una password. L'autenticazione Basic di HTTP può essere schematizzata nella seguente figura: Figura 5 Nel punto (1) il browser si connette al web server. Il web server (2) invia una richiesta di autorizzazione al web browser. Quest ultima viene visualizzata dal browser(3) con un pannello Pop Up dove l'utente deve inserire la propria username e password.. Il web server riceve(4) i parametri indicati dall utente e verifica se username e password sono corretti. Se lo sono, autorizza l'utente ad accedere al web server (5a) oppure ne, se l'autenticazione non ha avuto successo ripropone il pannello di autenticazione (5b). L'apertura del Pop Up avviene tramite l'intestazione WWW-Authenticate nell header dell HTTP. L'autorizzazione invece nei criteri per accedere in particolari zone del sito, con particolari modalità (ad esempio l'indirizzo IP od il nome della macchina di provenienza), l'orario di access e così via Apache

20 Vediamo ora le direttive che permettono di gestire l'accesso degli utenti. Le direttive che seguono devono essere contenute all interno delle direttive <Directory>, <Files>, <Location> ovvero saranno valide per le aree del web identificate da questi tag. AllowOverride Questa direttiva stabilisce sei i file.htaccess definiti dagli utenti, possono sovrapporsi e ridefinire le regole di sicurezza definite nella configurazione globale del server La configurazione di questa direttiva è la seguente: AllowOverride opzione1 opzione2 Nel caso si definisca AllowOverride None, il server non legge più i file.htaccess presenti nelle relative directory. Le opzioni possibili e che in parte vedremo in dettaglio nei paragrafi successivi sono le seguenti: AuthConfig: permette l utilizzo delle direttive di autorizzazione come AuthDBMGroupFile, AuthGroupFile, AuthName, AuthUserFile, AuthType, Require) FileInfo: Permette l utilizzo e la ridefinizione delle direttive ErrorDocument, AddLanguage, AddEncoding, DefaultType, ecc. Indexes: Permette l utilizzo delle direttive che gestiscono l indexing delle directory, quali AddIcon, AddDescrption, DirectoryIndex, HeaderName, ecc.) Limit: permettono l utilizzo delle direttive che controllano l accesso all host quale Deny, Allow e Order Options. Permette l utilizzo delle direttive Options. Vediamo le più importanti: AuthType Questo parametro definisce il sistema di autenticazione da applicare. Al momento l'unica possibilità è Basic, in quanto molti browser non supportato altri sistemi di autenticazione. Esiste anche l'opzione Digest (basato su md5) ma al momento molti browser non lo supportano. <Limit> Limita l'utilizzo dei metodi HTTP quali GET, POST, DELETE, PUT, CONNECT e OPTIONS Quindi ad esempio <Limit GET> </Limit> <LimitExcept> Funziona al contrario del comando precedente. Abilita tutti i metodi eccetto quello indicato Apache

21 LimitRequestBody Definisce la dimensione massima in byte del body HTML. Require Questo parametro definisce gli utenti ed i gruppi di utenti che possono accedere al sito. Quindi ad esempio Require mario paolo jenny autorizza solo questi utenti ad entrare nel sito, oppure Require gruppo gruppo1 gruppo2 Autorizza solo gli utenti appartenenti ai gruppi indicati possono avere un accesso. Abbiamo ancora la possibilità di impostare Require valid-user che permetterà di accedere agli utenti valicati tramite un file di username e password individuato tramite altre direttive (AuthUserFile e AuthGroupFile). Un esempio completo potrebbe essere: AuthType Basic AuthName Finestra di autenticazione AuthUserFile /www/sito1/users AuthGroupFile /www/sito1/group <Limit GET> Require group </Limit> Autenticazione ed autorizzazione tramite il modulo mod_auth Il modulo mod_auth è quello usato normalmente di default per gestire le autenticazioni sul server apache. Più precisamente permette di definire utenti, gruppi e password per accedere a specifiche sezioni del web. Analizziamo ora le direttive per gestire l autenticazione degli utenti. AuthUserFile Questa direttiva individua il file che contiene username e password da applicare ad una zona specifica del web server. Ad esempio AuthUserFile /www/accessoristretto/.htpasswd Apache

22 indica il file che contiene username e password Per definire il file.htpasswd (che può avere un nome qualsiasi) si utilizza il comando htpasswd fornito insieme ai tool di apache. AuthGroupFile Questa direttiva individua i gruppi di utenti (in analogia al sistema Unix) che possono accedere una zona del web server. AuthGroupFile gruppo1 Esempio di implementazione di autenticazione Vediamo ora un esempio di implementazione di protezione di una directory: Supponiamo di voler proteggere la directory /www/sito1/noaccess in modo che solo alcune persone autorizzate vi possano accedere. Per semplificare la configurazione e non utilizzare un percorso così lungo, conviene definire un alias: Alias /noaccess/ /www/sito1/noaccess Definito l alias il codice per effettuare l autenticazione sarà: <Location /noaccess/> AuthName Accesso riservato ai clienti AuthType Basic AuthUserFile /www/utenti/utenti require valid-user </Location> In questo modo, qualsiasi accesso alla directory in esame, comporterà la richiesta da parte del server di introdurre username e password. Queste informazioni sono presenti nel file utenti Per creare username e password all interno di questo file è necessario utilizzare il tool htpasswd: /usr/local/apache/bin/htpasswd -c percorso_del_file username L opzione c server per creare il file la prima volta, nelle volte successive non è più necessaria. Quindi nel nostro caso potrebbe essere: /usr/local/apache/bin/htpasswd -c /www/utenti/utenti rossi È necessario ora fare il restart del server tramite il commando apachectl restart Ora, connettendosi al sito deve comparire un prompt che richiede username e password. L'intestazione della finestra è il testo indicato in AuthName Apache

23 Esempio di accesso tramite il file.htaccess La configurazione del meccanismo di autenticazione vista nel paragrafo precedente è utile se il web master deve gestire un numero ridotto di accessi. Tuttavia, presso un ISP con un numero elevato di siti web, la gestione delle autenticazioni può diventare onerosa ed inoltre alcuni clienti, potrebbero richiedere di gestire autonomamente gli accessi sul proprio sito. Per questo motivo, apache permette di demandare ad ogni utente la gestione degli accessi. Ciò viene effettuato tramite l'utilizzo del file.htaccess. Per autorizzare gli utenti ad utilizzare il file, è necessario porre in httpd.conf la direttiva: AcessFileName.htaccess Inoltre, supponendo di autorizzare tutto il sito gestire in modo autonomo le proprie directory, è necessario agire sulla directory root dell intero server, quindi la direttiva di default <Directory /> Options FollowSymLinks AllowOverride None </Directory> deve essere riscritta come: <Directory /> Options FollowSymLinks AllowOverride AuthConfig </Directory> In questo modo si abilita, all interno di ogni file.htaccess, l'utilizzo delle direttive AuthGoupFile, AuthName, AuthDBMGroupFile, AuthUserFile, Require, ecc. Dopo la modifica del file httpd.conf, come sempre è necessario effettuare un restart del server tramite apachectl restart. In questo modo, in ogni directory del web server, appartenente ad un sito qualsiasi di un utente generico, può essere utilizzato il file.htaccess. La configurazione di base del file in questione è: AuthName Testo della finestra PopUP AuthType Basic AuthUserFile percorso_al_file_con_le_password Require valid-user Per esempio, supponendo di voler effettuare un controllo degli accessi alla directory /www/mysite/htdocs/asb utilizzando degli utenti definiti nel file /www/mysite/secrets/users.pwd. Il file.htaccess sarà quindi: AuthName Accesso riservato AuthType Basic AuthUserFile /www/mysite/secrets/users.pwd Require valid-user Apache

24 Gli accessi al file possono essere configurati solo di lettura oppure in scrittura in base alle proprie necessità, tramite il comando Unix chmod. Naturalmente, prima, il file deve diventare di proprietà dell utente che ne avrà la gestione tramite il comando chown. Raggruppamento di utenti ed accessi per directory È anche possibile autorizzare gruppi differenti ad accedere differenti directory. <Location /segreteria> AuthName Accesso per utenti del settore segerteria AuthType Basic AuthUserFile /www/sito/dir_sicura/userspass require bianchi rossi </Location> <Location /vendite> AuthName Accesso per utenti del settore vendite AuthType Basic AuthUserFile /www/sito/dir_sicura/userspass require verdi blu </Location> In questo modo, solo gli utenti bianchi e rossi possono accedere la directory segreteria e solo gli utenti verdi e blu possono accedere la directory vendite. Anche se questa configurazione è valida ed utilizzabile, potrebbe essere utile fare due file di password differenti, anziché utilizzare solo userspass Ciò dipende dalle proprie necessità e gusti. Infine si possono utilizzare i gruppi di utenti. Vediamo la seguente configurazione: <Location /segreteria> AuthName Accesso per utenti del settore segerteria AuthType Basic AuthUserFile /www/sito/dir_sicura/userspass AuthGroupFile /www/sito/dir_sicura/grpsegr require group grpsegr </Location> <Location /vendite> AuthName Accesso per utenti del settore vendite AuthType Basic AuthUserFile /www/sito/dir_sicura/userspass AuthGroupFile /www/sito/dir_sicura/grvendite require group grpvendite </Location> In questo modo, il file degli utenti è lo stesso, tuttavia esiste ora un file di gruppi utenti che specifica per ciascuno di essi, il relativo gruppo di appartenenza. Il contenuto del file di gruppi potrebbe essere: segreteria: bianchi rossi Apache

25 vendite: Verdi blu C è poi la direttiva require group che individua il gruppo autorizzato tramite username e password ad accedere alla directory. Si ricorda che dopo ogni modifica ai file.htaccess, ai file di password ed ai file di gruppo utenti, non è necessario effettuare il restart del web server. Solo le modifiche al file httpd.conf richiedono questa operazione. Autenticazione ed autorizzazioni tramite hostname od IP address È possibili anche autorizzare gli accessi ad alcune zone del web server, tramite il riconoscimento dell hostname o dell indirizzo IP di provenienza. allow La direttiva allow permette di specificare l'elenco dei nomi, dei domini, degli IP da cui è permesso accedere ad una directory del file. Riportiamo una tabella riassuntiva ed alcuni esempi: Apache

26 Continua Apache

27 deny La direttiva deny è esattamente l'opposto della direttiva allow. Nega quindi quanto viene indicato. Le modalità sono esattamente uguali a quelle riportate nella tabella precedente. order Questa direttiva indica al server se prima deve valutare le direttive deny e poi le direttive allow, oppure viceversa. Quindi è possibile scrivere order deny,allow oppure order deny,allow Un ultima opzione può anche essere order mutual-failure, il quale indica che solo gli hosts presenti in allow ma che non compaiono in deny, sono autorizzate ad accedere al sito. Un esempio potrebbe quindi essere: <Directory /mysite/myboss/rants> order deny, allow deny from myboss.mycompany.com allow from all </Directory> Utilizzo combinato di autorizzazione ed autenticazione Tutte le direttive di autenticazione ed autorizzazione analizzate fino ad ora possono essere utilizzate insieme per poter raffinare il meccanismo di accesso al web server. Vediamo il seguente esempio: Alias /aolbuddies/ /path/to/web/directory/for/aolbuddies/ <Location /aolbuddies/> Deny from all Allow from.aol.com AuthName AOL Buddies Only AuthType Basic AuthUserFile /path/to/.myusers.pwd Apache

28 AuthGroupFile /path/to/.mygroups require group aolbuddies Satisfy all </Location> In questo esempio si vuole autorizzare l accesso alla directory aolbuddies solo per gli utenti che provengono da una connessione effettuata tramite AOL. La direttiva Satisfy all indica al web server di permettere l accesso alla directory solo se entrambi, il processo di autenticazione ed il processo di autorizzazione è avvenuto con successo. Il sistema di autenticazione ed i DB Apache prevede anche che l'autenticazione degli utenti venga supportata da DB quali MySQL od altri DB. Sostanzialmente utenti, password ed autorizzazioni sono contenute in un DB ed il web server interroga il DB per tutte le informazioni che deve gestire. Questo argomento esula da questo manuale. La cifratura dei dati tra il web server apache ed i browser La sicurezza nella gestione di un web server è fondamentale. In queste sezione ci occuperemo nella definizione di connessioni cifrate. Tali connessioni sono particolarmente utili nel caso l'utente debba trasmettere informazioni riservate, quali ad esempio numeri di carte di credito. Una connessione cifrata fa si che, qualora nel percorso intermedio tra client e server, un malintenzionato intercetti i dati trasmessi, questi risultano illeggibili proprio perché criptati. Solo client e server, tramite meccanismo di cifratura basati su chiavi e certificati digitali, sono in gradi di interpretare correttamente le informazioni trasmesse. Per far ciò, si utilizza il protocollo SSL (Secured Socket Layer). Metodologie di implementazione del protocollo SSL Apache di base non supporta il protocollo SSL, ma quest ultimo deve essere installato e/o integrato successivamente. Al momento esistono due metodologie per realizzare connessioni sicure tramite SSL: 1. L'utilizzo del modulo mod_ssl 2. L'implementazione di Apache-ssl Entrambe queste metodologie si fondano su OpenSSL, un progetto opensource per l'implementazione del protocollo SSL. OpenSSL fornisce un motore di creazione e gestione di certificati digitali tramite chiavi asimmetriche (chiave pubblica e chiave privata). Il modulo mod_ssl è uno dei tanti moduli da compilare in apache. In particolare questo modulo fornisce all apache server la possibilità di interagire con OpenSSL ed utilizzare certificati digitali per stabilire connessioni sicure tramite tunnel SSL con i browser che visitano i nostri siti. Mentre il mod_ssl prevede l'installazione ed integrazione di quest ultimo all interno di apache, con il secondo metodo, si utilizza un server totalmente separato da apache. Entrambe le metodologie al momento funzionano solo con la versione di apache ma non con apache 2.0 e successive. In questo manuale utilizzeremo la prima metodologia Apache

29 Nella figura seguente riportiamo il modello OSI con l'implementazione del protocollo SSL: Figura 6 Come si può notare SSL è posto al disopra del protocollo TCP/IP e sotto al livello applicativo. Dunque tutti i servizi quali http, FTP, TELNET, LDAP, SMTP, IMAP possono essere cifrati. Poiché l'uitlizzo di apache-ssl e di facile installazione, ci dedicheremo all utilizzo di mod_ssl che richiede un installazione un po più complessa. Installazione e configurazione di SSL in apache tramite mod_ssl Per prima cosa è necessario installare OpenSSL. Questo può essere reperito al sito Poiché il prodotto è di facile installazione, non ci dilungheremo nel descriverlo. È sufficiente leggere il file INSTALL contenuto nella distribuzione sorgente. Dopo aver installato OpenSSL, è necessario prelevare il modulo mod_ssl dal sito Anche questo è di facile installazione. Dopo aver estratto tutto il sorgente i entra nella directory di installazione. Si deve utilizzare il comando./configure come descritto nel file INSTALL. In particolare è importante utilizzare le opzioni --with-apache, --with-ssl indicando le directory dove sono stati espansi i tarball di OpenSSL e apache. Infine deve ancora essere indicato il parametro --prefix che indica la directory di destinazione diverrà installato il web server. Infine è necessario andare nella directory di installazione (ottenuta dal relativo tarball) di apache, ed effettuare un make. Terminato questo, si deve effettuare un make certificate seguito da l'opzione TYPE=test (se si devono solo effettuare alcune prove) oppure TYPE=custom (se si sta effettuano Apache

30 un installazione definitiva). Il comando make certificate serve per generare i certificati del web server che quest ultimo dovrà utilizzare per scambiare informazioni con i browser che ne richiederanno l'utilizzo. Quindi ad esempio il comando potrebbe essere make certificate TYPE=test. I certificati verranno depositati automaticamente nelle directory ssl. presenti nella directory conf di apache. Infine si deve effettuare un make install. Al termine, il server è pronto. Per farlo funzionare in modalità normale si utilizza come al solito il comando apachectl start mentre per utilizzarlo in modalità mista si utilizza il comando apachectl startssl. Il server SSL viene gestito come virtualhost di quello principale anche se la cosa non è obbligatoria. Il virtualhost funziona sulla porta 443 dedicata all SSL. Il virutalhost SSL possiede una propria DocumentRoot, che dunque conterrà tutte le pagine HTML che si desiderano essere cifrate prima dell invio ai browser. Verifica del funzionamento Contrariamente alla notazione all interno della URL, in questo caso si dovrà utilizzare Visitando il proprio sito con la notazione https, dovrebbe essere possibile accedere ad una pagina protetta. Un altro mod per verificare la corretta funzionalità del sito è effettuare un telnet all indirizzo del web sulla porta 443. In questo caso il comando GET / non dovrebbe effettuare alcun output, in quanto la connessione avviene tramite SSL, e come noto, nella fase iniziale avviene una sorta di handshaking tra server e browser per lo scambio dei certificati digitali Apache