Ubuntu, insicuro di default
aprile 23, 2009
Negli ultimi anni Ubuntu si è fatta strada fra molte altre distro, per essere la la più semplice e veloce da installare, e facile da utilizzare. Infatti può essere utilizzata anche da chi non ha mai avuto esperienze con Linux prima d’ora, e permette di avere un sistema operativo completo e funzionante in breve tempo.
Ecco i punti principali del suo meritato successo, ma a volte, concentrandosi troppo sulla facilità d’uso, si tende a trascurare aspetti riguardanti la sicurezza del sistema.
Questa è un po’ la filosofia di molte distro, concentrandosi più sull’usabilità, puntando a ridurre i tempi di boot, a pensare ad una interfaccia grafica un po’ più accattivante, aggiungendo tool che semplificano la vita agli utenti alle prime armi, e puntando sull’usabilità in generale. Ma spesso ci si dimentica della sicurezza, soprattutto in distro pensate per un utilizzo Server. In questo articolo infatti voglio mettere in evidenza alcuni dei principali problemi di sicurezza che caratterizzano Ubuntu, prendendo in esame la versione 8.10 Server. Vulnerabilità presenti nel sistema installato di default, ma che si possono comunque risolvere in un secondo momento.
Premetto che non è mio intento criticare tale distribuzione, scatenare flames o guerre d’opinione. Voglio solo mettere in risalto alcuni aspetti che magari alcuni utenti non conoscono, ed aiutarli nel migliorare la sicurezza della propria distro.
Cominciamo ora ad analizzarne gli aspetti. Iniziamo con la creazione del proprio utente, e conseguentemente della directory Home. Ci si presenta tale schermata:
Come si legge in fase di installazione, “The contents of your home directory will normally be visible to all users on the system”. Quindi qualsiasi altro utente può leggere ed eseguire tutti i file contenuti nella mia directory Home, che spesso contiene documenti privati.
Lo si può verificare:
drwxr-xr-x 56 matteo matteo 4096 2009-04-23 21:10 matteo
Inoltre, qualsiasi utente creato usando il comando useradd avrà gli stessi permessi, essendo impostata la variabile DIR_MODE=0755 nel file /etc/adduser.conf
Una decisione utile a facilitare la condivisione di materiale tra più utenti, ma assai pericoloso in una versione Server, decisamente multiutente.
Continuiamo ora durante la fase di selezione software, in cui vengono marcati per l’installazione i seguenti componenti: DNS Server, LAMP server, mail server, OpenSSH server e un Virtual Machine host. Procedendo, il sistema chiede di modificare la password di root per mysql. Una buona prassi, se non per il fatto che l’installer permette di lasciare vuoto tale campo, non forzando l’utente ad inserire una password. Conseguentemente non opera neanche alcun filtro di lunghezza minima sulla password, o di qualche regola particolare per imporre una password forte e robusta, a difesa dell’account root di mysql.
Altro punto debole di sicurezza, la cui colpa ricade sull’amministratore, ma un sistema server dovrebbe effettuare alcuni controlli per garantire la massima sicurezza.
La via più semplice per un hacker per entrare nel sistema, è sfruttare i vari servizi caricati, che tengono porte aperte e di cui poi ci si dimentica. Ubuntu permette all’amministratore di selezionare quale software desidera installare ed utilizzare. Nonostante ciò, una analisi minimale di netstat mostra alcuni servizi avviati dal sistema, che probabilmente non serviranno all’amministratore:
root@sparky:~# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:pop3 *:* LISTEN
tcp 0 0 *:imap2 *:* LISTEN
udp 0 0 *:bootps *:*
udp 0 0 *:bootpc *:*
I primi due servizi sono proprio Post Office Protocol 3 (pop3) e Message Access Protocol 2 (imap2), nonostante Ubuntu abbia installato la versione più sicura di questi protocolli. Entrambi questi protocolli erano necessari in passato per poter garantire l’interoperabilità con vecchi programmi email. Ma attualmente tutti i principali client email supportano le versioni più sicure e recenti. (il principale problema di queste vecchie versioni è l’utilizzo di password in chiaro).
I servizi bootps e bootpc invece servono per fornire l’indirizzamento dinamico tramite BOOTP e DHCP, però vengono attivati di default anche se si utilizza un indirizzamento statico.
Esistono quindi dei servizi attivati di default senza averli richiesti, e senza che fossero necessari, potenzialmente sfruttabili da malintenzionati.
Il modo migliore per garantire la sicurezza nella gestione dell’accesso remoto, è quello di limitare gli accessi remoti via shell soltanto agli account che ne hanno reale bisogno.
Diamo un’occhiata al file di gestione degli account:
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
sshd:x:107:65534::/var/run/sshd:/usr/sbin/nologin
Ad eccezione di sshd, tutti gli account di sistema sono forniti di una sessione di shell interattiva. Così quando qualcuno di questi account viene compromesso, per esempio tramite un buffer overload di qualche processo, l’attaccante ha accesso al login via shell. La cosa migliore da fare sarebbe quella di impostare a questi account l’opzione nologin.
Un altra considerazione potrebbe anche essere fatta su account attivi di default anche se non richiesti esplicitamente, e non utilizzati. Tale account potrebbero benissimo essere disattivati.
Per concludere, gli sforzi di Ubuntu per semplificare al massimo l’installer sono da apprezzare, e per rendere semplice l’utilizzo dell’intero sistema, ma invece di concentrarsi un po’ troppo sulle prestazioni in fase di boot, a mio modesto parere potrebbe cercare di concentrarsi leggermente di più anche sulla sicurezza della distribuzione, a maggior ragione visto che i test sono stati effettuati sulla versione Server.
Spesso gli utenti finali sottovalutano quest’aspetto pensando in modo a volte un po’ superficiale “si tratta di Linux, quindi è per forza sicuro”.
Ad ogni modo, sono tutti difetti che possono essere risolti in fase di post-installazione, prima di rendere il server accessibile al web.
E la vostra distro? Presenta gli stessi problemi? Condividete le vostre esperienze, anche con distribuzioni diverse!
Comments
2 Responses to “Ubuntu, insicuro di default”
Got something to say?
You must be logged in to post a comment.
Archlinux non presenta nessuno di questi problemi.
Tutti gli account tranne root e utenti comuni hanno come shell o /bin/false oppure /sbin/nologin.
Tuttavia bisogna usare pesi diversi. Archlinux non ha lo stesso target di utenza come Ubuntu.
Si presume che gli arcieri siano più esperti e sappiano quello che fanno.
Non sapevo tutto questo…articolo interessante. Complimenti.
Speriamo che giunga alle orecchie degli sviluppatori di Ubuntu.
Non dimentichiamo che Ubuntu è una delle distribuzioni per masse.
E tutto questo è cattiva pubblicità.
Beh, la versione per server di solito dovrebbe essere destinata ad amministratori, che dovrebbero sapere ciò che fanno. Ma chissà quanti di loro mettono mano per risolvere questi problemi.
E non sono pochi i server gestiti da Ubuntu. A memoria so che c’è Wikipedia, e alcuni hoster di spazio web.