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 detto “script kiddy“) 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 (deturpazione) 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.

The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. “Script-kiddies“ only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines. In others, they simply install crypto-miners and use the compromised system to fill their crypto wallets.

Another very common scenario nowadays is a ransomware attack. The attackers will encrypt the data on the machine and leave a note with instructions how to pay ransom to get the key to decrypt the data. Of course, it is not for certain that even after paying, the data can be recovered or be sure it hasn't been stolen (and sold) as well.

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.

L'attaccante ha ora il controllo della macchina; cercherà di mantenere questo accesso privilegiato il più a lungo possibile. Per raggiungere questo risultato può installare un rootkit, un programma che rimpiazza alcuni componenti del sistema per ripermettergli di ottenere i privilegi di amministratore successivamente (vedere anche SGUARDO VELOCE I pacchetti checksecurity e chkrootkit/rkhunter); il rootkit tenta anche di mascherare la propria esistenza così come ogni traccia d'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'attaccante è 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, l'attaccante può intercettare alcune delle password di amministrazione, che possono essere usate nei server rilevati… e l'intrusione da lì si può propagare ulteriormente.

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 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 installato. Sicuramente questa informazione dev'essere bilanciata con la popolarità del suddetto software: un programma ampiamente diffuso è un bersaglio più allettante, e di conseguenza sarà 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 per controlli di sicurezza.

Nel mondo del Software Libero, c'è generalmente ampio spazio di scelta, 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 aggressore che prende il controllo della vostra macchina, potrebbe usarla come base (conosciuta come "sistema ripetitore") dalla quale effetture altre attività malevoli: ciò potrebbe crearvi problemi legali, dal momento che la parte sotto attaccata vedrebbe l'attacco provenire dal vostro sistema e quindi vi considererebbe come l'aggressore (o come un complice). In molti casi, l'attaccante userà il vostro server come ripetitore per inviare spam, che non dovrebbe avere molto impatto (è da aspettarsi la probabile registrazione sulle black list che potrebbe limitare la possibilità di inviare email legittime), ma non sarà comunque piacevole. In altri casi, problemi più seri potrebbero essere causati dalla vostra macchina, 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ò avviare un procedimento legale contro di voi. I detentori dei diritti possono citarvi in giudizio se nel vostro 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 partito dalla vostra 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.