(:title ESP - Lezione del 5 fiorile 216 (24 aprile 2008):)
:: ESP - Lezione del 5 fiorile 216 (24 aprile 2008) ::
Torna alla pagina di ESP
Apache
Vediamo ora come si gestisce la sicurezza nel webserver Apache.
In ogni cartella che il server servirà può essere contenuto un file .htaccess (sì, c'è un puntino davanti, che vuol dire che è un file nascosto). Questo file fa testo per la dir in cui è contenuto. Altrimenti, si usa l'.htaccess della cartella superiore etc.
Il modulo mod-access supporta sia i permessi (allow) che le negazioni (deny). Permessi o negazioni possono essere supportati da direttive host-based, cioè che si applicano a tutto il sito, oppure a direttive user-based, ovvero basate sull'utente che si identifica.
Host-based
- allow from host-or-network/all
- deny from host-or-network'/all
Al posto di host-or-network devo mettere gli indirizzi di chi voglo alloware o denyare. Posso usare tutte le simpatiche forme che abbiamo visto con il Damiani: CIDR, maschere e così via.
Altrimenti, posso usare le forme
- allow from env = env-variable
- deny from env = env-variable
env-variable è una variabile che viene recuperata dall'header http. Il modulo mod-setenvif è in grado di controllare queste variabili.
Per esempio:
SetEnvIf Referer www.swappa.it internal_site
Allow from env = internal_site
Queste due righe mi dicono
- che considero www.swappa.it come internal_site quando appare nel campo referer dell'header http
- che tutti quelli in cui env = internal_site sono allowati
Il referer, nella fattispecie, è la pagina da cui sono arrivato alla pagina attuale. Questo vuol dire che se accedo da www.swappa.it, ok, altrimenti no.
User-based
Sono di 3 tipi:
- require user username username ...
- require group group group ...
- require valid-user
Nel primo caso, richiedo che l'utente sia uno che compare nella mia lista.
Nel secondo, voglio che il gruppo dell'utente compaia nella lista.
Nel terzo caso, voglio che l'utente si sia loggato con successo nel sistema.
Satisfy & order
Comunque le direttive host- e user-based non sono mutuamente esclusive. Anzi, la direttiva satisfy mi serve per stabilire come queste debbano interagire
- satisfy all = tutte due devono essere soddisfatte
- satisfy any = almeno una deve essere soddisfatta
Inoltre, c'è la direttiva order che dice l'ordine di valutazione di allow e deny
- order deny, allow = prima valuto le deny, poi le allow => realizzo di fatto una politica aperta
- order allow, deny = prima allow, poi deny => politica chiusa
- order mutual-failure = una richieste deve NON soddisfare deny, e SODDISFARE allow: in pratica non sono ammessi conflitti, se ci sono non va bene e non permetto l'accesso.
Granularità
La granularità mi dice a che livello di risorse controllo gli accessi. Posso controllare a livello di file o di metodo.
Il controllo a livello di file imposta direttive su un singolo file:
<FileMatch reg-exp>
...direttive...
</FileMatch>
Quello che succede è che tutti i file il cui nome soddisfa l'espressione regolare (reg-exp) indicata, saranno soggetti alle direttive scritte in mezzo.
A livello di metodo, invece, controllo in base a quale metodo l'utente utilizza. I metodi sono i vari GET, POST, PUT etc. di HTTP.
<limit GET POST PUT>
...direttive...
</limit>
Gerarchia di controllo
Come dicevamo all'inizio, posso mettere un file .htaccess in ogni dir, e farà testo per il contenuto di quella dir. Se non è presente, ci si rifà alla dir superiore e così via.
In pratica si applica una politica mstp, in cui si parte dalla directory principale che ospita il server, e si scende via via fino a trovare l'elemento più specifico vicino all'oggetto che voglio controllare.
...continua...
Torna alla pagina di ESP
