|
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-connessim, la sicurezza diventa un problema sempre maggiore.
Il modo migliore per implementare la sicurezza è con un approccio “a cipolla”. In pratica, quello che vuoi fare è creare tanti livelli di sicurezza quanto è conveniente e poi tenere sotto controllo il sistema per vedere eventuali intrusioni. Non vuoi esagerare nella sicurezza o interferirai con l'individuazione e quest'ultima è una delle parti più importanti di ogni meccanismo di sicurezza. Per esempio, ha poco senso imopstare il flag schg (vedi chflags(1)) su ogni binario di sistema dato che questo potrà sì proteggere temporaneamente i binari, ma evita che l'attaccante faccia una modifica facilmente individuabile e potrebbe far in modo che il tuo meccanismo di sicurezza non individui l'attaccante del tutto.
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:
Attacchi che limitano la disponibilità dei servizi (“Denial of service” o, in breve, DoS).
Compromissione degli account utente.
Compromissione di root tramite server accessibili.
Compromissione di root tramite gli account utente.
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 ni genere non può nascondere le proprie tracce e può, alla peggio, rovinare i files dell'utente o mandaer la macchina in crash. La compromissione degli account utente è molto comune dato che gli utenti tendono a non prendere precauzioni tanto quanto i sysadmin.
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. If an attacker has found a way to break root on a machine, the attacker may not have a need to install a backdoor. Many of the root holes found and closed to date involve a considerable amount of work by the attacker to cleanup after himself, so most attackers install backdoors. A backdoor provides the attacker with a way to easily regain root access to the system, but it also gives the smart system administrator a convenient way to detect the intrusion. Making it impossible for an attacker to install a backdoor may actually be detrimental to your security, because it will not close off the hole the attacker found to break in the first place.
Security remedies should always be implemented with a multi-layered “onion peel” approach and can be categorized as follows:
Securing root and staff accounts.
Securing root -- root-run servers and suid/sgid binaries.
Securing user accounts.
Securing the password file.
Securing the kernel core, raw devices, and filesystems.
Quick detection of inappropriate changes made to the system.
Paranoia.
The next section of this chapter will cover the above bullet items in greater depth.
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Per domande su FreeBSD, leggi la documentazione prima di contattare <questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a <doc@FreeBSD.org>.