Il carattere universale delle applicazioni web ha aiutato la loro proliferazione. Spesso ne sono in esecuzione parecchie in parallelo: webmail, wiki, sistemi collaborativi, gallerie di foto, blog e così via. Molte di queste applicazioni si basano sullo stack «LAMP» (Linux, Apache, MySQL, PHP). Sfortunatamente, molte di queste applicazioni sono state anche scritte senza sufficiente considerazione dei problemi di sicurezza. I dati provenienti dall'esterno vengono, troppo spesso, acquisiti con poca o nessuna validazione. Possono essere forniti valori creati appositamente per stravolgere l'invocazione di un comando in modo tale che un altro venga eseguito al suo posto. La maggior parte dei problemi più comuni sono stati risolti col passare del tempo, ma regolarmente se ne presentano di nuovi.

Risulta d'obbligo quindi l'aggiornamento delle applicazioni web su base regolare, affinché nessun cracker (che sia un autore di attacchi professionista oppure un principiante) possa sfruttare una vulnerabilità conosciuta. Il rischio effettivo dipende dai casi, e spazia dalla perdita dei dati all'esecuzione di codice arbitrario, incluso il defacing di un sito web.

Una vulnerabilità in un'applicazione web è spesso usata come punto di partenza per un tentativo di attacco. Quello che segue è una breve rassegna delle possibili conseguenze.

Le conseguenze di un'intrusione hanno vari livelli di evidenza a seconda delle intenzioni di chi fa l'attacco. Un principiante («script-kiddy») applica alla lettera ricette che trova sui siti web; molto spesso deturpa una pagina web o distrugge dati. In casi particolari, aggiunge contenuti invisibili alle pagine web per aumentare i riferimenti ai suoi siti web nei motori di ricerca.

Un attaccante più esperto va oltre. Uno scenario disastroso può presentarsi nella seguente maniera: chi attacca acquisisce la capacità di eseguire comandi come utente www-data, ma l'esecuzione di un comando richiede molte manipolazioni. Per avere vita più facile, installa altre applicazioni web progettate appositamente per eseguire da remoto varie tipologie di comandi, ad esempio l'esplorazione del file system, la gestione delle autorizzazioni, il caricamento o lo scaricamento di file, l'esecuzione di comandi, e talvolta l'apertura di una shell di rete. Spesso, la vulnerabilità permette di lanciare il comando wget per scaricare un qualche tipo di malware in /tmp/, per poi eseguirlo. Di solito il malware viene scaricato da un sito web esterno che è stato precedentemente compromesso, per far perdere le tracce e rendere più arduo individuare la reale provenienza dell'attacco.

A questo punto, chi attacca ha sufficiente libertà di movimento spesso per poter installare un bot IRC (un automa che si connette ad un server IRC e può essere controllato attraverso questo canale). Questo bot viene talvolta usato per condividere file illegali (copie non autorizzate di film o software e così via). Un autore di attacchi ben determinato potrebbe voler spingersi oltre. L'account www-data non permette l'accesso completo alla macchina, così chi attacca potrebbe provare a ottenere i privilegi di amministratore. Ora, ciò non dovrebbe essere possibile, ma se l'applicazione web non è aggiornata, può essere che il kernel oppure altri programmi siano anch'essi non aggiornati; questo può essere conseguenza della decisione dell'amministratore che, nonostante sia a conoscenza della vulnerabilità, ha trascurato di aggiornare il sistema dal momento che non sono presenti utenti locali. Chi attacca, quindi, può avvantaggiarsi di questa seconda vulnerabilità per ottenere l'accesso come root.

Ora chi attacca ha il controllo sulla macchina; cercherà di mantenere questo accesso privilegiato per il maggior tempo possibile. Questo può comprendere l'installazione di un rootkit, un programma che rimpiazza alcuni componenti del sistema per permettere all'autore dell'attacco di ottenere i privilegi di amministratore nuovamente le volte successive; il rootkit tenta anche di mascherare la propria esistenza così come ogni traccia di intrusione. Un programma ps alterato ometterà di elencare alcuni processi, netstat non elencherà alcune delle connessioni attive e così via. Sfruttando i permessi di root, l'autore dell'attacco è stato in grado di osservare l'intero sistema, ma non ha trovato dati importanti; così tenterà di accedere ad altre macchine nella rete aziendale. Analizzando l'account dell'amministratore e i file della cronologia, l'autore dell'attacco scopre a quali macchine vengono fatti accessi frequenti. Sostituendo sudo oppure ssh con un programma contraffatto, chi attacca può intercettare alcune delle password di amministrazione, che possono essere usate nei server rilevati… e l'intrusione da lì si può propagare.

Questo è uno scenario da incubo che può essere evitato attraverso numerose misure. Le prossime sezioni ne descrivono alcune.

Una volta che i potenziali problemi di sicurezza sono noti, devono essere presi in considerazione a ciascun passo del processo di distribuzione di un servizio, specialmente quando si sceglie il software da installare. Molti siti web, come SecurityFocus.com, mantengono un elenco delle vulnerabilità riscontrate di recente, che danno un'idea dei precedenti per ciò che riguarda la sicurezza prima che qualche software particolare venga distribuito. Sicuramente questa informazione dev'essere messa in relazione con la popolarità del suddetto software: un programma ampiamente diffuso è un obiettivo più allettante, e di conseguenza dev'essere esaminato più attentamente. D'altro canto, un programma di nicchia potrebbe presentare molti buchi di sicurezza che non vengono mai pubblicizzati a causa della mancanza di interesse nelle verifiche di sicurezza.

Nel mondo del Software Libero, c'è generalmente ampio spazio di manovra, e la scelta di un pezzo di software rispetto ad un altro dovrebbe essere una decisione basata su criteri locali. Maggiori funzionalità implicano un maggiore rischio di una vulnerabilità nascosta nel codice; scegliere il programma più avanzato per svolgere un'attività può effettivamente essere controproducente, e spesso utilizzare il programma più semplice che soddisfa i requisiti è il migliore approccio.

La maggior parte delle distribuzioni Linux installano per impostazione predefinita un certo numero di servizi Unix e svariati strumenti. I molti casi, questi servizi e strumenti non sono necessari per gli effettivi scopi per cui l'amministratore configura la macchina. Come linea guida generale in termini di sicurezza, è meglio disinstallare il software non necessario. Infatti, non ha senso mettere in sicurezza un server FTP, se può essere sfruttata la vulnerabilità di un altro servizio inutilizzato per ottenere i privilegi di amministratore sull'intera macchina.

Seguendo lo stesso ragionamento, i firewall sono spesso configurati per permettere l'accesso solo ai servizi che sono destinati ad essere disponibili pubblicamente.

Gli attuali computer sono sufficientemente potenti da permettere di offrire numerosi servizi sulla stessa macchina fisica. Da un punto di vista economico, tale possibilità è interessante: solo un computer da amministrare, minor consumo energetico e così via. Dal punto di vista della sicurezza, invece, questa scelta può diventare un problema. Un solo servizio compromesso può permettere l'accesso all'intera macchina, che a sua volta può compromettere gli altri servizi offerti. Il rischio può essere limitato isolando i servizi. Ciò si ottiene sia con la virtualizzazione (ogni servizio viene ospitato in una macchina virtuale dedicata o contenitore), sia con AppArmor/SELinux (assegnando ad ogni servizio demone un insieme adeguatamente progettato di permessi).

Discutere di sicurezza porta immediatamente alla mente la protezione contro gli attacchi da parte di cracker anonimi che si nascondono nella giungla di Internet; ma un fatto spesso dimenticato è che i rischi vengono anche dall'interno: un dipendente che sta per lasciare l'azienda potrebbe scaricare file sensibili relativi a progetti importanti e venderli alla concorrenza, un venditore negligente potrebbe allontanarsi dalla propria scrivania senza bloccare la sessione durante un meeting con un nuovo potenziale cliente, un utente maldestro potrebbe eliminare la directory sbagliata per errore e così via.

La risposta a questi rischi può richiedere soluzioni tecniche: bisogna concedere agli utenti solo i permessi necessari, inoltre è d'obbligo pianificare backup regolari. Ma nella maggior parte dei casi, per evitare i rischi la giusta protezione implica insegnare agli utenti come evitare i rischi.

Non ha senso mettere in sicurezza i servizi e le reti se i computer stessi non sono protetti. Dati importanti meritano di essere memorizzati su dischi fissi hot-swap in configurazione RAID, perché i dischi fissi prima o poi si guastano e la disponibilità dei dati è d'obbligo. Ma se qualsiasi ragazzo della pizza può entrare nell'edificio, intrufolarsi nella stanza del server e scappare con alcuni dischi rigidi prescelti, allora un importante aspetto di sicurezza non è soddisfatto. Chi può entrare nella stanza del server? È presente un controllo degli accessi? Queste domande meritano una considerazione (e una risposta) quando viene valutata la sicurezza fisica.

La sicurezza fisica include anche prendere coscienza dei rischi derivanti da incidenti, come ad esempio gli incendi. Questo rischio in particolare è ciò che giustifica l'archiviazione dei supporti di backup in un edificio separato, o almeno in una cassaforte ignifuga.

Un amministratore è, per i suoi utenti così come per gli utenti della rete in generale, una persona più o meno implicitamente fidata. Dovrebbe pertanto evitare qualsiasi negligenza che persone ostili potrebbero sfruttare.

Un autore di un attacco che prende il controllo della nostra macchina per poi usarla come base di lancio (conosciuto come «sistema ripetitore») e dalla quale effettua altre attività malvagie potrebbe crearci problemi legali, dal momento che la parte sotto attacco ne vedrebbe inizialmente la provenienza dal nostro sistema, e perciò ci considererebbe come l'autore dell'attacco (o un suo complice). In molti casi, chi attacca userà il nostro server come ripetitore per inviare spam, che non dovrebbe avere molto impatto (è da aspettarsi la probabile registrazione sulle black list che potrebbe limitare la nostra abilità di inviare email legittime), ma non sarà comunque piacevole. In altri casi, la nostra macchina potrebbe causare danni più seri, per esempio attacchi di tipo «denial of service». Questo talvolta porterà a mancati ricavi, dal momento che i servizi legittimi non saranno disponibili e i dati potrebbero andare distrutti; a volte questo implicherà anche un costo reale, perché la parte che è sotto attacco può iniziare un'azione legale contro di noi. I detentori dei diritti possono citarci in giudizio se nel nostro server viene condivisa la copia di un lavoro protetto da copyright, così come possono fare altre aziende legate da contratti di qualità del servizio se sono tenute al pagamento di penalità a causa dell'attacco alla nostra macchina.

Quando si presentano queste situazioni, dichiararsi innocenti di solito non basta; per lo meno, sarà necessaria una prova convincente che dimostra un'attività sospetta sul sistema proveniente da un determinato indirizzo IP. Ciò non sarà possibile se si trascurano le raccomandazioni di questo capitolo e si concede all'autore dell'attacca di ottenere l'accesso ad un account privilegiato (in particolare root) per cancellare le proprie tracce.