|
|
|
Made in |
| DESCRIPTION | Restringere l'accesso alle risorse web tramite le direttive deny e allow | Live Discussion - Skill: 3- INTERMEDIATE |
| Per determinare se un dato client può accedere ad una risorsa, Apache esegue una serie di controlli divisa in più fasi: 1- Apache tramite il modulo mod_access verifica se l'IP del client può accedere alla risorsa richiesta 2- Si richiedono informazioni aggiuntive al client come username e password. |
||||
| Il modulo mod_access viene comunemente utilizzato per l'host-based authentication ed è possibile eseguire il matching delle regole per il controllo degli accessi tramite alcuni parametri come ip, hostname e HTTP headers. Le direttive gestite dal modulo sono allow, deny e order. Controllo dell'accesso tramite il nome di un host Abilita l'accesso ad uno specifico host openskills.info allow from openskills.infoAbilita l'accesso a tutti gli host del dominio openskills.info allow from .openskills.infoNega l'accesso a tutti gli host del dominio openskills.info deny from .openskills.infoLe direttive allow e deny, rispettivamente, permettono o negano l'accesso alle risorse quando l'host client matcha il criterio per cui è valida la direttiva. Nel caso in cui si debbano includere nella configurazione entrambe le direttive per gestire l'accesso alla stessa risorsa bisogna affiancarle alla direttiva order per determinare l'ordine con cui vengono lette le direttive allow e deny. Per esempio: Implementa policy permissive: lascia accedere tutti gli Host tranne quelli del dominio openskills.info: order allow,denyImplementa policy restrittive: blocca tutti gli accessi tranne quelli di host del dominio openskills.info order deny,allowControllo dell'accesso tramite IP Soluzione ideale rispetto all'utilizzo dei nomi, poichè non obbliga il web server a eseguire reverse lookup DNS per ottenere i nomi di host dall'IP. Nell'esempio che segue viene permesso l'accesso solo dai range di IP specificati: <Directory />E' possibile specificare un singolo IP oppure una network intera o una subnet, in questi due ultimi casi occorre specificare la netmask, è permesso utilizzare la nomenclatura in cui si specificano semplicemente i bit che identificano l'indirizzo di rete (permessi solo 8 16 24) o semplicemnte evitando di scrivere gli zeri (192.168) oppure scrivendo la netmask in formato esteso (255.255.255.0). Controllo degli accessi tramite i HTTP header Una possibile alternativa è quello di affiancare alle direttive allow e deny le direttive BrowserMatch e SetEnvIf per negare o abilitare l'accesso ad una risorsa a seconda di una definibile variabile d'ambiente. BrowserMatch ^Mozilla*Questa funzionalità apre un universo di possibilità che permettono operazioni piuttosto sofisticate come permettere l'accesso solo se il Referrer è di un certo tipo, impedire l'accesso a robot che si presentano con User Agent identificabili, a spider/crawler/site grabbers ecc. |
||||
| DESCRIPTION | Autenticazione degli utenti | Live Discussion - Skill: 3- INTERMEDIATE |
| L'user authentication è un modo avanzato per eseguire un controllo degli accessi via web a determinati file o directory sulla base di login e password configurabili. | ||||
| Tramite moduli autonomi, Apache supporta diversi metodi per gestire i dati relativi a login e password, che si basano su basi date diverse. Moduli standard - mod_auth : Autenticazione base con file di testo - mod_auth_anon : Autenticazione anonima - mod_auth_dbm : Autenticazione con DBM database - mod_auth_db : Per i sistemi che DB database - mod_digest : Digest Authentication con file Moduli sviluppati da terze parti - mod_auth_msql : Autenticazione base con supporto di MSQL - mod_auth_mysql : Autenticazione base con supporto di MYSQL - mod_auth_ldap : Autenticazione base con supporto di LDAP - mod_auth_kerberos : Autenticazione base con supporto di kerberos - mod_auth_radius : Autenticazione base con supporto di radius - mod_auth_smb : Autenticazione base con Windows - mod_auth_oracle : Autenticazione base con supporto di Oracle Per avere una lista completa si può fare riferimento al sito ufficiale http://modules.apache.org/ Da tenere conto che i moduli sviluppati da terze parti, cioè non sviluppati dal core team di Apache, non sono stati testati a fondo e richiedono a volte un'intervento massiccio per l'installazione causa dipendenze con librerie che nell'installazione standard di Linux e di Apache sono escluse. Qualunque sia il modulo utilizzato vengono sempre richieste le seguenti direttive per abilitare l'user authentication: AuthName Il nome o il realm che Apache invia al modulo che si occupa dell'autenticazione per definire le varie "zone" che richiedono l'autenticazione. E' una stringa di testo definibile arbitrariamente, che viene visualizzata nella finestra di richiesta Nome Utente e Password del browser. AuthName "Area Clienti"AuthType E' la direttiva che si occupa di inviare username e password, può acquisire due valori Basic e Digest, la differenza primaria è che la configurazione "Digest", a differenza di quella "Basic", invia username e password criptati utilizzando MD5, sfortunatamente non è del tutto supportata. AuthType BasicAuth???UserFile Ogni modulo ha una specifica direttiva per indicare dove Apache troverà le informazioni per eseguire il check su password ed utente. Per il modulo mod_auth avremo AuthUserFile /usr/local/apache/private/passwdOppure per il modulo mod_auth_dbm AuthDBMUserFile /usr/local/apache/private/passwd.dbmDirettiva opzionale per definire il gruppo E' possibile tramite la direttiva Auth???GroupFile aggiungere un ulteriore check per l'autenticazione, aggiungendo il criterio del gruppo di appartenenza. Come sopra avremo una direttiva specifica per ogni modulo (non tutti i moduli la supportano) Per il modulo mod_auth avremo AuthGroupFile /usr/local/apache/private/groupOppure per il modulo mod_auth_dbm AuthDBMGroupFile /usr/local/apache/private/group.dbm Require Direttiva che permette di determinare quale criterio è assolutamento valido per abilitare l'accesso alla risorsa: require valid-user Auth???Authoritative Altra direttiva opzionale che permette di determinare quale tipo di autenticazione è autoritativa rispetto ad un altra, quando si hanno più tipi di autenticazioni attive sulla stessa risorsa. Genericamente tutti i tipi di autenticazione seguono il seguente schema: <Location /private>Anche nel caso dell'user authentication è possibile utilizzare il file .htaccess, anche se non è abilitato di default. Per abilitare tutte le direttive per l'autenticazione occorre appoggiarsi ad AllowOverride: AllowOverride AuthConfig
|
||||
| DESCRIPTION | Basic Authentication | Live Discussion - Skill: 2- JUNIOR |
| L'autenticazione "Base" è quella più comunemente utilizzata più che altro per il fatto che è supportata da tutti i browser. Di fatto tutti i moduli tranne mod_digest utilizzano l'autenticazione base anche se richiedono di specificarla tramite la direttiva AuthType. |
||
| Quando un Browser richiede una risorsa protetta, Apache replica con un messaggio di mancata autorizzazione per accedere alla risorsa (status code 401) che contiene l'header WWW-Authentificate: ed il nome della zona (o realm) configurata tramite la direttiva AuthName: WWW-Authentification: Basic realm="Area Clienti" Quando il client riceve la risposta, apre un pop-up in cui e' possibile inserire user e password e reinvia la richiesta al server aggiungendo le informazioni aggiuntive (pwd e user) nell'Authorization header. Prima parte dell'header Authorization: BASIC kheSrkSlrJflvbFvaFfsgHhl Seconda parte dell'header contenente user e pwd (in chiaro) user:password A livello di configurazione su httpd.conf si trova: <Location /private>Se al posto dell'autenticazione basata su normale file di testo, ci si basa un un DBM (tramite il mod_auth_dbm) la sintassi in httpd.conf diventa: <Location /private> |
||
| DESCRIPTION | Anonymous Authentication | Live Discussion - Skill: 3- INTERMEDIATE |
| Gestita dal modulo mod_auth_anon richiede parametri aggiuntivi rispetto ad altri moduli. E' paragonabile ad un accesso FTP anonimo, ma rimane comunque una soluzione poco utilizzata. |
||
| Le direttive disponibili sono: Anonymous [list of user] Lista di utenti che possono accedere alla risorsa. Questa direttiva disabilitata di default e non può essere utilizzata se la direttiva Anonymous_NoUserID è settata ad on Anonymous_MustGiveEmail on | off Se settata ad on (valore di default), richiede una e-mail come password Anonymous_VerifyEmail on | off Se settata ad on verifica l'esistenza dei caratteri "." e "@" nell'e-mail inserita. Di Default è disabilitata Anonymous_LogEmail on | off Se settata ad on, viene loggato l'indirizzo e-mail nell'access log ad ogni login effettuato con successo. Di default è disabilitata Anonymous_NoUserID on |off Se settata ad on il campo user può essere lasciato in bianco, disabilitata di default. Esempio di configurazione: <Location /private> |
||
| DESCRIPTION | Gestione utenti e password per l'autenticazione | Live Discussion - Skill: 3- INTERMEDIATE |
| Il passo successivo alla configurazione del proprio server web con un accesso tramite login e password è quello di creare un file di password e, eventualmente uno di gruppi. | ||
| A seconda del tipo di autenticazione utilizzata (Basic o Digest) e dal modulo che gestice il check esistono varie utility, già presenti nel pacchetto base di Apache. htpasswd Utility per creare e gestire i file (plain-text no db o dbm) che contengono la corrispondenza user e password per l'autenticazione Basic. L'uso è molto simile al comando passwd: Creazione del file passwd con l'inserimento del primo utente pippo htpasswd -c /usr/local/apache/auth/passwd pippoAggiunta dell'utente paperino ad un file esistente htpasswd /usr/local/apache/auth/passwd paperinodbmmanage Script in perl che permette di gestire i file (o meglio database) db e dbm: Creazione dell'utente pippo con dbmmanage dbmmanage password.dbm adduser pippohtdigest Utility equivalente a htpasswd (in piu' occorre specificare il realm) ma per l'autenticazione digest: Creazione del file passwd con l'inserimento del primo utente htdigest -c /usr/local/apache/auth/passwd "area clienti" pippo |
||
| DESCRIPTION | Direttiva require | Live Discussion - Skill: 3- INTERMEDIATE |
| La direttiva require permette di specificare per la singola area protetta, quali utenti ci possono accedere, l'authentication stage si preoccupa solo di verificare la corrispondenza user e password ma tramite questa direttiva si può avere un ulteriore filtro, permettendo così di utilizzare un singolo file di password per più aree (scelta sconsigliata). | ||
La sintassi è la seguente:require [user | group | valid-user] [lista di utenti o lista di gruppi]Consente l'accesso solo all'utente pluto, dopo che ha superato con successo l'authentication stage, altri utenti, anche se correttamente autenticati, non possono accedere: require user plutoConsente l'accesso solo agli utenti pluto, pippo e admin dopo che hanno superato con successo l'authentication stage: require user pippo pluto adminConsente l'accesso a tutti gli utenti, dopo che hanno superato con successo l'authentication stage: require user valid-userConsente l'accesso a tutti gli utenti che appartengono al gruppo admin ovviamente solo dopo che ha superato con successo l'authentication stage: require group admin |
||
| TIPS | Host-based e User Authentification | Live Discussion - Skill: 3- INTERMEDIATE |
| Se host-based e User authentification sono applicati alla stessa risorsa bisogna specificare se dovranno essere soddisfatte entrambe o solo una delle due per accedere la risorsa. | ||
| Questo è possibile tramite la direttiva Satisfy Per accedere alla risorsa occorre soddisfare entrambe le direttive Satisfy allPer accedere alla risorsa occorre soddisfare solo una delle direttive Satisfy anySegue un esempio di configurazione che permette libero accesso da IP specificati (una rete interna) e richiede username e password per client esterni. <Location /user/> |
||
| TIPS | Overriding Host-Based Access | Live Discussion - Skill: 2- JUNIOR |
| Apache permette l'utilizzo delle direttive order,allow,deny e Satisfy nella configurazione per-directory e tramite il file .htaccess se la direttiva Limit override è abilitata (di default lo è). | ||
Per abilitare le direttive relative all'accesso:AllowOverrides +LimitPer disabilitare le direttive: AllowOverrides -LimitTecnicamente la direttiva Satisfy è comunque permessa poichè non viene gestita dal modulo mod_access ma dal core di Apache, ma questo fa ben poca differenza se le direttive allow e deny sono disabilitate. |
||
| TIPS | Sintassi del file group per l'autenticazione tramite Apache | Live Discussion - Skill: 2- JUNIOR |
| La sintassi delle entry del file contenente le correlazioni gruppo/utente, sono simili al file /etc/group, con la differenza che i singoli utenti di uno stesso gruppo non sono separati da un virgola ma da uno spazio. | ||
| Esempio delle entry del file /etc/group [neo@dido neo]$ head -3 /etc/grouproot:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon Esempio delle entry del file group da specificare con la direttiva Auth???GroupFile neo@dido neo]$ head -2 /usr/local/apache/auth/groupadmin: webmaster pippo webmaster operator: operator pluto neo |
||
| COMMANDS | htpasswd | Live Discussion - Skill: 3- INTERMEDIATE |
| Per creare e gestire i file per l'autenticazione utente Basic di Apache. | ||
Per la creazione di un nuovo passwd filehtpasswd -c [opzioni] passwdfile usernamePer aggiungere semplicemente un utente ad un passwd esistente htpasswd [opzioni] passwdfile usernamePer printare in stdout quello che verrebbe scritto nel passwd file, utile se si deve copiare il risultato in un db come mysql htpasswd -nb [opzioni] username password-b Abilita il batch mode, la password viene presa dalla linea di comando, con tutti gli incovenienti del caso.-c Crea il passwd file se non esiste, altrimenti lo sovrascrive.-n Mostra il risultato del comando in stdout, non può essere combinata con l'opzione -c |
||
| COMMANDS | htdigest | Live Discussion - Skill: 2- JUNIOR |
| Utility per la creazione e management del file contenente la correlazione password e utente per l'autenticazione di tipo Digest di Apache. | ||
htdigest [ -c ] passwdfile realm username-c crea il file passwd, se esiste lo sovrascrive. |
||
| COMMANDS | dbmmanage | Live Discussion - Skill: 3- INTERMEDIATE |
| Perl script per la gestione e creazione dei file dbm, utilizzati, fra le altre cose, per l'autenticazione utente tramite Apache. | ||
dbmmanage filename-db [ command ] [ username [ encpasswd ] ]Comandi: add Aggiunge un utente ed è l'unico comando che permette di specificare la password cryptata e i gruppi a cui appartiene il nuovo utenteadduser Aggiunge un utente, viene richiesto di inserire la password check Esegue il check della password inserita nel db con quella fornita da noi per un utente esistentedelete Cancella un utenteimport Legge "User:password" dallo stdinupdate Esegue un update della passwordview Mostra il contenuto del db |
||
| STDOUT | Creazione di un file passwd per l'autenticazione base di apache | Live Discussion - Skill: 3- INTERMEDIATE |
| Prassi per la creazione di un passwd per Apache con htpasswd. | ||
[root@morpheus /root]# cd /usr/local/apache/auth/[root@morpheus auth]# ls -ltotale 0 Creazione del file passwd e inserimento del primo utente pippo [root@morpheus auth]# htpasswd -c passwd pippoNew password: Re-type new password: Adding password for user pippo [root@morpheus auth]# ls -ltotale 4 -rw-r--r-- 1 root root 20 nov 15 13:14 passwd Visualizzazione del contenuto del file passwd [root@morpheus auth]# cat passwd pippo:50JjuGahgWGg2 |
||
| STDOUT | Utilizzo di dbmmanage | Live Discussion - Skill: 3- INTERMEDIATE |
| Utilizzi più comuni del comando dbmmanage. | ||
[root@morpheus auth]# ls -ltotale 0 Creazione dell'utente pippo, se il db non esiste viene creato [root@morpheus auth]# dbmmanage passwd.dbm adduser pippoNew password: Re-type new password: User pippo added with password encrypted to E73kpaKh4du3I using crypt [root@morpheus auth]# ls -ltotale 8 -rw-r--r-- 1 root root 8192 nov 15 13:49 passwd Visualizzazione della entry relativa all'utente pippo [root@morpheus auth]# dbmmanage passwd.dbm view pippo pippo:E73kpaKh4du3I Creazione dell'utente tramite il comando adduser [root@morpheus auth]# dbmmanage passwd.dbm adduser pluto New password: Re-type new password: User pluto added with password encrypted to C5tErlEabAsUw using crypt Cancellazione dell'utente [root@morpheus auth]# dbmmanage passwd.dbm delete pluto `pluto' deleted Inserimento definitivo specificando i gruppi: [root@morpheus auth]# dbmmanage passwd.dbm add pluto C5tErlEabAsUw:user,admin User pluto added with password encrypted to C5tErlEabAsUw:user,admin using crypt Verifica della password dell'utente pluto [root@morpheus auth]# dbmmanage passwd.dbm check pluto Enter password: crypt password ok Visualizzazione di tutto il db [root@morpheus auth]# dbmmanage passwd.dbm viewpippo:E73kpaKh4du3I pluto:C5tErlEabAsUw:user,admin |
||
| Openskills LiveBook: Apache - Installazione e configurazione | (C)oresis Srl | GNU FDL licence | Generated: 23/10/2003 |