In questi tempi la parola "sicurezza" viene spesa da molte bocche a vario titolo.
Non di rado lo si fa semplicemente perchè è un argomento "caldo", per cui può essere fonte e opportunità di profitto.
In questo capitolo si cerca di affrontare le problematiche di sicurezza reali che un amministratore di sistema deve affrontare nel momento in cui installa e rende pubblico un server web con Apache.
Non verranno trattati argomenti che si riferiscono alla sicurezza in termini di servizio, ma solo quelli che lo fanno in termini di implementazione specifica.
Spiegamoci:
Gli argomenti relativi alla criptazione dei dati che vengono scambiati fra client e server web (SSL e mod_ssl) o quelli relativi all'accesso alle risorse web (autenticazione degli utenti o access list basate su IP) li consideriamo dei servizi, che riguardano il mondo della sicurezza in genere, ma che in se non servono a rendere sicuro un server Web. Questi vengono trattati altrove.
Qui si affrontano le problematiche reali che un sysadmin deve affrontare per proteggere il suo sistema da un uso improprio: configurazioni di Apache e direttive che possono essere sfruttate da un intrusore o un webmaster non fidato, patch e buchi di siscurezza noti, utilizzo di pagine dinamiche e problematiche relative alle singole implementazione di script dinamici, hardening del sistema su cui gira il web server, design di una infrastruttura che garantisca sicurezza e confidenzialità dei dati.
Il modo stesso di affrontare le problematiche di sicurezza dipende fortemente dal tipo di servizio che il nostro server deve offrire: se è destinato ad un utilizzo privato, in una rete locale e a non essere pubblicamente raggiungibile, si può considerare un approccio meno stringente, la protezione dell'integrità e della riservatezza dei dati possono non essere un problema di primaria importanza e le possibilità di interazione fornite agli utenti (sia quelli che navigano che quelli che uploadano sul server i contenuti) più ampie.
Su un server destinato ad avere un utilizzo pubblico su Internet, invece, possono riscontrarsi casi e problematiche diverse:
- Se l'aggiornamento delle pagine è fatto da personale fidato, si possono prevedere meno restrizioni sulle possibilità di accesso e di utilizzo delle risorse del sistema da parte delle pagine web e ci si può concentrare sulla difesa dei servizi pubblici;
- Se il server contiene più domini virtuali, gestiti da diverse persone, di diverse provenienze e non certa affidabilità, ci si deve preoccupare non soltanto di cosa può fare l'utente navigatore, ma anche di come restringere il campo d'azione dell'utente webmaster, che potrebbe sfruttare in modo improprio dei permessi troppo lassi sul sistema (per esempio la possibilità di eseguire comandi locali tramite SSI o PHP).
Breve rassegna della security history, problematiche attuali. Security e siti dinamici.