14.2 Introduzione

La sicurezza è una funzione che inizia e finisce con l'amministratore di sistema. Nonostante ogni sistema multi-utente UNIX® BSD abbia della sicurezza insita, il lavoro di costruire e mantenere meccanismi di sicurezza aggiuntivi in modo da mantenere “onesti” gli utenti è probabilmente uno dei maggiori lavori di un amministratore di sistema. La macchine sono sicure solo quanto le si rende e le richieste di sicurezza si scontrano sempre con l'umana necessità per la comodità. I sistemi UNIX, in generale, sono capaci di eseguire un gran numero di processi contemporanei e ognuno di questi processi opera come server — nel senso che entità esterne possono connettersi e parlarci. Mentre i mini e i mainframe di ieri diventano i desktop di oggi, mentre i computer diventano interconnessi e internet-connessi, la sicurezza diventa un problema sempre maggiore.

La sicurezza di un sistema riguarda anche il gestire varie forme di attacco, compresi attacchi che tentano di bloccare, o comunque rendere inusabile, il sistema, anche se non necessariamente cercano di compromettere l'account di root root (“rompere root”). I problemi di sicurezza possono essere suddivisi in svariate categorie:

1. Attacchi che limitano la disponibilità dei servizi (“Denial of service” o, in breve, DoS).

2. Compromissione degli account utente.

3. Compromissione di root tramite server accessibili.

4. Compromissione di root tramite gli account utente.

5. Crazione di backdoor (letteralmente “porte sul retro”, ovvero accessi secondari personalizzati).

Un attacco DoS è un'azione che priva la macchina di risorse. Tipicamente un attacco DoS è un meccanismo a forza-bruta che tenta di bloccare e comunque rendere inusabile una macchina travolgendo di richieste i server che rende disponibili o direttamente lo stack di rete. Alcuni attacchi DoS tentano di trarre vantaggio da bug nello stack di rete per bloccare la macchina con un singolo pacchetto. Questo genere di attacchi può evitato solo mettendo a posto il bug direttamente nel kernel. Gli attacchi sui server possono spesso essere evitati specificando con attenzione dei limiti sul carico che i server stessi devono accettare in caso che il sistema lavori in condizioni avverse. Gli attacchi a forza-bruta generati da un'intera rete di attaccanti sono più difficili da gestire. Ad esempio un attacco con pacchetti in spoof (ovvero con il campo mittente falsato) è praticamente impossibile da fermare, a meno di staccare del tutto il sistema da Internet. Potrà anche non fermare la tua macchina, ma sicuramente può saturare la tua connessione Internet.

La compromissione di un account utente è ancora più comune di un attacco DoS. Molti sysadmin usano ancora i server standard telnetd, rlogind, rshd e ftpd sulle loro macchine. Questi programmi, normalmente, non usano connessioni crittate. Il risultato è che quando hai una base utenti di medie dimensioni, uno o più degli utenti connessi al tuo sistema da remoto (il modo più comune e conveniente per collegarsi a un sisetma) avrà una password compromessa da un'operaizone di sniffing. Gli amministratori di sistema attenti controllano i registri degli accessi remoto cercando indirizzi sospetti anche tra gli accessi permessi.

Bisogna sempre dare per scontato che una volta che un attaccante ha accesso ad un account utente, può rompere anche root. In realtà, comunque, in un sistema ben configurato e mantenuto, questo non è necessariamente vero. La distinzione è importante perché senza accesso a root l'attaccante in genere non può nascondere le proprie tracce e può, alla peggio, rovinare i file dell'utente o mandare la macchina in crash. La compromissione degli account utente è molto comune dato che gli utenti tendono a non prendere precauzioni tanto quanto gli amministratori di sistema.

Gli amministratori di sistema devono ricordare che su una macchina ci sono potenzialmente molti modi per rompere root. L'attaccante potrebbe conoscere la password di root, potrebbe trovare un bug in un programma server in esecuzione con diritti di root e sfruttarlo per entrare da remoto, oppure una volta ottenuto un account utente potrebbe fare lo stesso con un bug in un programma con suid root. Se un attaccante rompe root su una macchina, potrebbe non aver bisogno di installare una backdoor. Molti dei buchi per l'accesso come root trovati (e chiusi) fino ad oggi richiedono un considerevole lavoro da parte dell'attaccante per pulire le tracce lasciate, quindi molti attaccanti installano delle backdoor. Una backdoor dà all'attaccante un modo semplice per riottenere accesso root al sistema, ma danno anche un modo semplice per individuare l'intrusione, all'amministratore di sistema furbo. Rendere impossibile installare backdoor all'attaccante potrebbe in realtà diminuire la sicurezza del sistema, dato che comunque non chiuderà il buco che l'attaccante ha trovato la prima volta.

Le soluzioni di sicurezza devono sempre essere implementate con un approccio multi-strato a “cipolla” e possono essere categorizzate come segue:

1. Rendere sicuro root e gli account dello staff.

2. Rendere sicuri i server e i binari suid/sgid in esecuzione come root.

3. Rendere sicuri gli account utente.

4. Rendere sicuro il file delle password.

5. Rendere sicuro il nucleo del kernel, i device raw e il file system.

6. Individuazione rapida delle modifiche non appropriate fatte al sistema.

7. Paranoia.

La prossima sezione di questo capitolo coprirà questi punti in maggior dettaglio.