INFN Sec. Group

Sicurezza nei sistemi UNIX

v 1.0 - 23/02/98 - P. Anelli


Indice

Introduzione
Password
Servizi di rete
Individuazione dell'hacker
Appendice
Crack
Tripwire
 

Introduzione

Nel definire dei criteri di comportamento per la sicurezza la prima cosa da considerare è da chi ci si deve difendere. L'attività di hacking sulla rete viene svolta da personaggi molto diversi, nella maggior parte dei casi si tratta di persone che non desiderano provocare danni ma semplicemente utilizzare risorse riservate. Purtroppo (o per fortuna) questo tipo di hacker è anche il meno esperto, il che da un lato può essere positivo perchè avendo una minore conoscenza dei sistemi dispongono di minori risorse per la "rottura" delle sicurezze; questa minore esperienza può però portare a fare danni seri sul sistema senza che questo sia lo scopo dell'intrusione. Questo documento affronta, senza pretesa di completezza, alcuni problemi relativi ai sistemi UNIX, proponendo comportamenti ed azioni in grado di aumentarne il livello di sicurezza.

Il primo obiettivo di un hacker è di ottenere accesso al sistema, questo può essere fatto cercando di indovinare la password di un utente, oppure sfruttando qualche bug di uno dei servizzi attivi sul sistema.

 

Password

Mantenere una corretta politica di gestione delle password è quindi il primo passo da compiere per incrementare la sicurezza di un sistema.
Ecco alcune regole da seguire:
  • Utilizzo del file shadow (dove possibile) per nascondere all'utente non privilegiato le informazioni relative alle password.
  • Attivazione (dove è possibile) della expiration date in modo da costringere gli utenti ad una modifica (più o meno frequente) della propria password.
  • Verifica della sicurezza delle password degli utenti attraverso l'eseguzione periodica di Crack sui file /etc/passwd o /etc/shadow. Spesso gli utenti utilizzano password semplici che possono essere facilmente (in breve tempo) individuate da software di pubblico dominio.
  • Evitare di utilizzare il file .netrc per eseguire un accesso ftp in modo automatico (questa operazione richiede l'inserimento della password dell'utente in chiaro)
  • Ridurre al minimo l'utilizzo del file /etc/host.equiv o .rhosts per dare accesso non autenticato. Utilizzare questi sistemi può provocare la propagazione della violazione di una macchina a tutte quelle collegate. È preferibile utilizzare ssh.
  • Evitare assolutamente di invianre la password di root sulla rete in chiaro. Per le connessioni con i privilegi dell'amministratore di sistema è opportuno utilizzare sempre ssh.
 

Servizi di rete

Ogni servizio messo a disposizione dal sistema sulla rete è fonte di rischi. Partendo però dal presupposto che "non mettere a disposizione" i servizi non è una soluzione praticabile, è comunque opportuno attivare su ogni sistema solo i servizi realmente necessari. È anche buona pratica isolare i servizi più vulnerabili (server web, server news, server mail, proxy server, server afs - in questo caso è consigliabile dedicare una macchina solo a questo servizio, ...) su sistemi dedicati non accessibili agli utenti.

X Server

Sono ben noti i problemi di sicurezza per quanto riguarda i server X dovuti alla consuetudine di disattivare completamente la sicurezza nell'accesso al server (Xterminal, Console grafica delle workstations ed emulatori X su PC o MAC). È nota l'esistenza di software di pubblico dominio in grado di visualizzare ogni tasto premuto sulla tastiera di un X server remoto che abbia disabilitato i controlli di sicurezza, in questo modo chiunque (non necessariamente dalla stessa rete locale) può intercettare un'operazione di telnet individuando la macchina di destinazione, lo username e relativa password. È quindi essenziale consigliare (meglio sarebbe costringere) agli utenti di non disattivare mai i controlli sulla sicurezza del server X, quindi evitare di fare "xhost +" nel caso di console grafiche o di mettere degli "*" nei criteri di selezione dei client autorizzati nel caso di Xterminal o emulatori su PC e MAC, nel caso di alcuni emulatori X l'assenza della specifica dei client autorizzati coincide alla disabilitazione del controllo. Naturalmente è tassativo seguire questa regola se si utilizzano account privilegiate! Sono anche disponibili software in grado di analizzare un insieme di macchine o anche un'intera rete, evidenziando i server X che hanno disabilitato la sicurezza (checkXuser), oppure software in grado di segnalere tutte le connessioni X provenienti dall'esterno.

NFS

È bene verificare che ogni sistema esporti esclusivamente i file system che deve esportare e che l'esportazione avvenga solo verso macchine note, qualificate con il nome completo compreso il dominio. È possibile verificare questa situazione attraverso il comando showmount -e nomehost che visualizza tutti i file system esportati e a chi vengono esportati. Bisogna anche ridurre al minimo (meglio se si elimina completamente) l'esportazione di file system con diritti di accesso come root. Naturalmente e' da evitare nel modo più assoluto l'esportazione di file system a everyone.

Server WEB

FTP

Ecco alcune regole da seguire nella configurazione del server FTP:
  • Nelle directory tipo ~ftp/bin, ~ftp/sbin, ~ftp/usr/bin, non deve comparire nessun interprete di comandi (come shell o perl), in quanto questi comandi risultano eseguibili da un SITE EXEC.
  • Alla entry relativa ad ftp nel file /etc/passwd non deve essere associata una password ne una shell, quello che segue è un esempio di come potrebbe apparire:
    ftp:*:200:200:Anonymous FTP:/home/ftp:/bin/false
    
  • I permessi sui file nella dirctory ~ftp/ devono essere settati a 555 (read nowrite execute) e l'owner deve essere root (NON ftp).
  • Evitare di mettere in ~ftp/etc/passwd una copia reale del file /etc/passwd. Gli unici utenti che devono comparire in ~ftp/etc/passwd sono root e ftp, naturalmente senza riportare la password:
    root:*:0:0:Ftp maintainer::
    ftp:*:200:200:Anonymous FTP::
    
    i privilegi di accesso a questo file devono essere settati a 444.
  • Anche il file ~ftp/etc/group deve essere ricreato e non deve coincidere con /etc/group. I privilegi di accesso devono essere 444.
  • I file ~ftp/.rhosts e ~ftp/.forward non devono esistere.
  • Le directory di sistema ~ftp/etc e ~ftp/bin ei file ~ftp/bin/* devono avere i permessi di accesso settati a 111 e devono essere di proprietà di root.


In ogni caso è consigliabile mantenere aggiornate le versioni del software di ogni servizio, in modo da garantirsi l'assenza dei bugs noti.

Una volta ottenuto accesso al sistema il passo successivo è di carpire i privilegi di root e divenire padrone di tutte le funzionalità del sistema. Le tecniche seguite sono diverse ma fanno affidamento, nella maggior parte dei casi a bugs del sistema operativo. Qui si gioca la "guerra" delle patches, i bugs dei sistemi operativi sono noti sia agli hackers che ai produttori dei sistemi stessi; il punto cruciale è la velocità di produzione delle patches rispetto alla velocità degli hackers nell'individuazione e nella divulgazione dei bugs. Va comunque sottolineato che la quasi totalità degli hackers sono utilizzatori di queste informazioni e solo pochissimi dispongono di conoscenze così approfondite da poter individuare nuovi bugs. In ogni caso la partecipazione a questa "guerra" da parte del gestore del sistema può essere fatta mantenendo aggiornato il sistema operativo sulle proprie macchine, sia facendo attenzione alle patches prodotte e distribuite dalla casa costruttrice che installando, per quanto possibile, le nuove versioni dei sistemi operativi. In questo modo si riduce drasticamente la probabilità che le informazioni a disposizione di un hacker gli consentano di violare la sicurezza del sistema.

 

Individuazione dell'hacker

Essere in grado di accorgersi in tempo che il proprio sistema è stato violato è essenziale per impedire che il sistema venga compromesso in modo irrimediabile. La prima cosa da fare è attivare e analizzare regolarmente i file di log, in modo da poter avere un rapporto preciso di ciò che accade sul sistema, di chi si collega e da dove. Attenzione, i file di log del sistema e i file utmp e wtmp sono editabili (una volta ottenuti i privilegi di root) quindi un hacker esperto è in grado di nascondere le tracce del proprio passaggio. Come contromisura si può redirigere i log anche su un server oltre che nei file locali, basta modificare la configurazione del syslogd nel file /etc/syslogd.conf aggiungendo linee di questo genere:
auth.notice	@loghost
dove loghost è il nome della macchina destinata a fare da server per i messaggi di log (Attenzione: la stringa @loghost deve essere separata da auth.notice con dei TAB). In questo modo resterà sempre traccia di ciò che accade sul sistema, sempre che il loghost sia "inespugnabile".
Per avere maggiori informazioni sulle connessioni via rete al sistema si può attivare un tcp wrapper sui servizi di rete lanciati attraverso inetd (come telnet ed ftp). Dirottando anche in questo caso una copia dei log sul loghost.

Una volta che gli hackers hanno ottenuto i privilegi di root sono soliti spargere nelle directory di sistema alcuni programmi con il bit SETUID settato in modo da poter riguadagnare tali privilegi anche in futuro. In pratica un file eseguibile di proprietà di root se ha il bit SETUID settato quando viene eseguito assegna al processo che lo esegue l'identità di root anche se ad eseguirlo è un utente qualunque. Quindi per l'hacker è sufficiente lasciare una shell di proprietà di root con il SETUID settato e con permessi di esecuzione per tutti. Il sistema del SETUID è molto utilizzato da Unix per consentire agli utenti di accedere a risorse riservate, esistono molti comandi di uso comune che sfruttano questo sistema (ps, at, lp, ecc.), quindi molto spesso per nascondere la presenza di una shell con queste proprietà all'eseguibile viene dato il nome di uno dei comandi di sistema e sostituito ad esso, per mascherare la situazione è sufficiente che il programma simuli il comportameno del comando sostituio in condizioni normali ed esegua invece una shell in condizioni particolari (ad esempio dando un parametro particolare). Questo comportamento degli hackers può essere utilizzato per segnalare un'intrusione, è sufficiente verificare che nulla sia cambiato nelle aree di sistema in quei files che hanno il bit SETUID settato. Un modo molto semplice è di creare un elenco di questi file con relative proprietà (path, data e dimensione) attraverso dei find e confrontare periodicamente questo elenco con una versione che consideriamo affidabile, se ci sono delle differenze significa che qualche cosa è stato modificato, si tratta allora di capire cosa e perchè. Di seguito viene riportato un esempio di script che può eseguire queste operazioni e manda un mail a root nel caso vengano individuate modifiche ai files di sistema.


#!/bin/sh
#
find /home/unix -type f -xdev -perm -4000 -print > /tmp/filecheck
find /usr/local  -type f -xdev -perm -4000 -print >> /tmp/filecheck
find /usr        -type f -xdev -perm -4000 -print >>/tmp/filecheck
find /           -type f -xdev -perm -4000 -print >> /tmp/filecheck
#
diff  /tmp/filecheck /etc/default/filecheck > /tmp/filecheck2
#
if test -s  /tmp/filecheck2
then
mail -s FScheck root < /tmp/filecheck2
fi
rm /tmp/filecheck /tmp/filecheck2

Naturalmente l'affidabilità di questo sistema dipende drasticamente dall'affidabilità del file di riferimento, se l'hacker è in grado di accorgersi che è attivo un sistema di questo genere e riesce a modificare il file di riferimento tutto diventa inutile, è pertanto consigliabile produrre copie di backup nascoste di questo file e provvedere periodicamente ad un suo controllo. Esistono anche pacchetti software in grado di automatizzare e rendere più sicura questa procedura (ad es. TRIPWIRE).
Un'altra attività tipica degli hacker, che può quindi essere utilizzata per individuare la violazione del sistema, è di attivare sulle macchine nelle quali sono riusciti ad ottenere i privilegi di root degli sniffer di rete. In questo modo vengono catturate le password che passano in chiaro sulla rete, e raccolte in file nascosti con nomi che iniziano con il carattere "." (come ad esempio ".. ", uno spazio dopo i due punti, oppure un punto seguito da caratteri non stampabili "..^G"). Per verificare la presenza di file di questo genere si può utilizzare il seguente comando:
find / -name ".*" -print | cat -v
Il cat -v visualizza i nomi dei files evidenziando i caratteri non stampabili.

 

Appendice

Crack

Si tratta di un tool che cerca di indovinare le password criptate contenute nel file /etc/passwd, utilizzando come base un dizionario multilingue al quale applica una serie di regole di trasformazione e composizione delle parole. La sequenza delle operazioni da eseguire è la seguente (come riportato in dettaglio nel file manual.txt):

./Crack -makeonly (configura e crea gli eseguibili)

./Crack -makedict (crea il dizionario)

./Crack -nice 10 /etc/passwd (Attiva il Crack per indovinare le password contenute nel file /etc/passwd)

./Reporter (visualizza un report dell'attività del Crack contenente le password individuate, anche mentre Crack è ancora in esecuzione).

Tripwire

Tripwire è un tool in grado di verificare l'integrità di una serie di files o directory confrontandoli con una base di dati precedentemente memorizzata, in modo da segnalare ogni variazione. Può essere utilizzato per verificare che non ci siano variazioni nei file di sistema con SETUID settato. Il programma utilizza un file di configurazione (/etc/trip/tw.config) nel quale vengono elencati i file e le directory da controllare. Un modo per generare questo file è di cercare nelle directory di sistema tutti i file con il SETUID settato:


find /usr/bin/ -type f -xdev -perm -4000 -print > /etc/trip/tw.config
find /sbin/ -type f -xdev -perm -4000 -print >> /etc/trip/tw.config
...

se si desidera effettuare il controllo su tutta la directory è sufficiente inserire nel file tw.config una linea contente tale directory e il controllo avverrà su tutti i file contenuti nella directory e nell'albero sottotstante (senza però attraversare i file system). Il sistema dei controlli è configurabile abbastanza finemente, per dettagli si veda tw.config.8
A questo punto bisogna inizializzare il database di riferimento con il comando:

tripwire -initialize

che genererà il file database/tw.db_nomemacchina che dovrà essere spostato in /etc/trip/. Ora è possibile eseguire tripwire in modalità checking, inserendo ad esempio il comando nel crontab per eseguire automaticamente e con regolarità il test:


0 2 * * * /usr/local+/bin/tripwire 2>&1 | /usr/bin/mailx -s "TW Report" root@decux1.pv.infn.it

in questo modo il tripwire viene lanciato tutti giorni alle 2 di notte e manda a root via mail il proprio output nel quale viene evidenziata ogni variazione nei file elencati in /etc/trip/tw.config.