Avanti Indietro Indice

5. Sicurezza dei File e dei Filesystem

Alcuni minuti di preparazione e pianificazione prima di mettere in funzione i vostri sistemi può aiutare a proteggere loro e i loro dati.

5.1 Settaggi di Umask

Il comando umask può essere usato per stabilire la modalità standard di creazione dei file. È il complementare ottale della modalità desiderata. Se i file venissero creati senza tenere in conto i settaggi dei loro permessi, un utente potrebbe inavvertitamente dare permessi di lettura o scrittura a qualcuno che non li dovrebbe avere. I tipici settaggi di umask includono 022, 027, e 077 (che è il più restrittivo). Normalmente la umask viene impostata in /etc/profile, così che abbia effetto su tutti gli utenti sul sistema. La maschera di creazione dei file si calcola sottraendo da 777 il valore desiderato. In altre parole, una umask di 777 farebbe in modo che i file creati non contengano permessi di lettura, scrittura o esecuzione per nessuno. Una maschera di 666 creerebbe nuovi file con permessi 111. Per esempio, potreste avere una linea di questo genere:

                # Imposta la maschera di default degli utenti
                umask 033
In questo caso, le nuove directory avrebbero permesso 744, ottenuto dalla sottrazione di 033 da 777. I nuovi file avrebbero permesso 644. Siate sicuri che la umask di root sia 077, che impedirà la lettura, scrittura e esecuzione ad altri utenti, eccetto che per quei file che siano stati esplicitamente cambiati con chmod chmod.

Se usate RedHat, e aderite al loro schema di creazione di ID di utenti e gruppi (User Private Groups), sarà sufficiente usare 002 per la vostra umask. Questo è dovuto al fatto che la configurazione di default è di utente per gruppo.

5.2 Permessi dei File

È importante assicurarsi che i vostri file di sistema non siano aperti da utenti e gruppi che non dovrebbero fare manutenzione di sistema.

Unix separa il controllo di accesso ai file e alle directory secondo tre caratteristiche: proprietario, gruppo e altri. C'è sempre un solo proprietario, un numero variabile di membri del gruppo, e tutti gli altri.

Ecco un veloce spiegazione dei permessi di Unix:

Proprietà - Quale/i utente/i e gruppo/i ha controllo sui permessi del nodo.

Permessi - Bit che possono essere settati o resettati per concedere certi tipi di accesso. I permessi delle directory possono avere significati diversi dai corrispondenti permessi sui file.

Lettura:

Scrittura:

Esecuzione:

Attributo Save Text: (Per le directory)

Lo "sticky bit" ha anche un significato diverso quando applicato a directory e quando a file. Se lo sticky bit \ impostato per una directory, allora un utente può solo cancellare file di cui è proprietario o di cui ha espliciti permessi di scrittura, anche se ha accesso in scrittura alla directory. Ciò è stato progettato per directory come /tmp, che sono scrivibili a tutti, ma in cui si preferisce che non tutti possano cancellare file a volontà. Lo sticky bit è segnato come una t nel listato di una directory.

Attributo SUID: (Per i file)

Descrive permessi set-user-id sul file. Quando la modalità di accesso set user ID è impostata nei permessi del proprietario, e il file è eseguibile, i processi che lo eseguono hanno accesso alle risorse di sistema basati sul proprietario del file, invece che sull'utente che ha creato il processo. Questa è la causa di molti exploit basati sul buffer overflow.

Attributo SGID: (Per i file)

Se impostato nei permessi del gruppo, questo bit controlla lo stato "set group id" di un file. In pratica si comporta come SUID, escluso che si basa sul gruppo. Il file deve essere eseguibile perché questo abbia un effetto.

Attributo SGID: (Per le directory)

Se impostate il bit SGID su una directory (con chmod g+s directory), I file creati in quella directory avranno il gruppo impostato sul gruppo della directory.

Voi - Il proprietario del file

Gruppo - Il gruppo a cui appartenete

Tutti - Chiunque non sia il proprietario o membro del gruppo

File Esempio:

        -rw-r--r--  1 kevin  users         114 Aug 28  1997 .zlogin
        1 bit - directory?                       (no)
         2 bit - lettura per il proprietario?     (yes, per kevin)
          3 bit - scrittura per il proprietario?   (yes, per kevin)
           4 bit - esecuzione per il proprietario?  (no)
            5 bit - lettura per il gruppo?           (yes, per users)
             6 bit - scrittura per il gruppo?         (no)
              7 bit - esecuzione per il gruppo?        (no)
               8 bit - lettura per tutti?               (yes, per tutti)
                9 bit - scrittura per tutti?             (no)
                 10 bit - esecuzione per tutti?           (no)

Le seguenti linee sono esempi dei permessi minimi richiesti per l'accesso a lato. Forse vorrete dare più permessi di quanto vedete qui, ma questo mostra solo ciò che questi permessi minimi fanno:


-r--------  Permette accesso in lettura al file per il proprietario
--w-------  Permette al proprietario di modificare o cancellare il file
            (Notate che chiunque con permesso di scrittura alla directory
            in cui si trova il file ha lo stesso privilegio)
---x------  Il proprietario può eseguire questo programma, ma non script
            della shell, che hanno bisogno anche del permesso in lettura
---s------  Il file verrà eseguito con User ID = utente
--------s-  Il file verrà eseguito con Group ID = gruppo
-rw------T  Non viene segnata l'ultima modifica. Usato spesso per file di swap
---t------  Nessun effetto.  (Era lo sticky bit)
Esempio di directory:

        drwxr-xr-x  3 kevin  users         512 Sep 19 13:47 .public_html/
        1 bit - directory?                       (si, contiene molti file)
         2 bit - lettura per il proprietario?      (si, per kevin)
          3 bit - scrittura per il proprietario?   (si, per kevin)
           4 bit - esecuzione per il proprietario?  (si, per kevin)
            5 bit - lettura per il gruppo?           (si, per users)
             6 bit - scrittura per il gruppo?         (no)
              7 bit - esecuzione per il gruppo?        (si, per users)
               8 bit - lettura per tutti?               (si, per tutti)
                9 bit - scrittura per tutti?             (no)
                 10 bit - esecuzione per tutti?            (si, per tutti)

Le seguenti linee sono esempi dei permessi minimi richiesti per l'accesso a lato. Forse vorrete dare più permessi di quanto vedete qui, ma questo mostra solo ciò che questi permessi minimi fanno:


dr--------  I contenuti possono essere listati, ma gli attributi dei file non
            possono essere letti
d--x------  La directory può essere aperta e usata nei percorsi di
            esecuzione
dr-x------  Gli attributi dei file possono essere letti dal proprietario
d-wx------  I file possono essere creati/cancellati, anche se la directory non
            è quella corrente
d------x-t  Impedisce che i file siano cancellati da chi ha i permessi in 
            scrittura. Usato su /tmp
d---s--s--  Nessun effetto

I file di configurazione del sistema (di solito in /etc) sono in genere in modo 640 (-rw-r-----), e proprietà di root. A seconda delle necessità di sicurezza del vostro sistema potreste cambiare questa impostazione. Non lasciate mai che dei file di sistema siano scrivibili da un gruppo o da tutti. Alcuni file di configurazione, incluso /etc/shadow, dovrebbero essere leggibili solo da root, e le directory in /etc non dovrebbero essere accessibili da altri.

Script della Shell con SUID

Gli script della shell con SUID sono un serio rischio per la sicurezza, per cui il kernel non li considererà. A prescindere da quanto pensate che lo script sia sicuro, può essere sfruttato per dare a un cracker una shell di root

5.3 Controllo dell'Integrità

Un altro ottimo modo per rilevare attacchi locali (e anche di rete) è eseguire un programma che faccia un controllo d'integrità come Tripwire, Aide o Osiris. Questi programmi eseguono una serie di controlli su tutti i vostri binari importanti e sui file di configurazione e li compara con un database di valori precedenti che si presumono corretti. In questo modo, ogni cambiamento nei file verrà segnalato.

È una buona idea installare questo tipo di programmi in un floppy e quindi proteggerlo fisicamente dalla scrittura. Così degli intrusori non potranno sabotare il programma per il controllo o cambiare i database. Una volta che avrete impostato una programma del genere, è una buona idea eseguirlo come parte dei vostri compiti amministrativi di routine per vedere se qualcosa è cambiato.

Potreste persino aggiungere un elemento al crontab per eseguire il controllo ogni notte e inviarvi un e-mail con i risultati al mattino. Qualcosa come:

                # imposta mailto
                MAILTO=kevin
                # esegui Tripwire
                15 05 * * * root /usr/local/adm/tcheck/tripwire 
vi spedirà un rapporto ogni mattina alle 5:15.

I controlli d'integrità possono essere una manna dal cielo per rilevare in tempi brevi un intrusore. Visto che molti file cambiano su un sistema normale, fate attenzione a cosa è l'attività di un cracker e cosa è la vostra attività.

Potete trovare la versione open source e gratuita di Tripwire presso http://www.tripwire.org. Manuali e supporto sono invece a pagamento.

Aide si trova presso http://www.cs.tut.fi/~rammer/aide.html.

Osiris si trova presso http://www.shmoo.com/osiris/.

5.4 Cavalli di Troia

"Cavalli di Troia" prende il nome dal famoso inganno nell'Iliade di Omero. Il concetto è che un cracker distribuisce un programma o un binario che sembra attraente, e incita altre persone a scaricarlo ed eseguirlo come root. A quel punto il programma può compromettere il loro sistema mentre non se lo aspettano. Mentre pensano che il programma che hanno preso faccia una cosa (e magari la fa davvero), compromette anche la sicurezza del sistema.

Dovreste controllare quali programmi installate sulla vostra macchina. RedHat fornisce checksum MD5 e firme PGP sui suoi pacchetti RPM perché possiate verificare ciò che installate. Altre distribuzioni hanno metodi simili. Non dovreste mai eseguire binari che non conoscete, di cui non avete il sorgente, come root! Ovviamente pochi intrusori rilasciano il codice sorgente al pubblico.

Per quanto può essere complesso, prendete sempre i sorgenti di un programma dal suo vero sito di distribuzione. Se il programma deve essere eseguito da root, controllate i sorgenti o fateli controllare da qualcuno di cui vi fidate.


Avanti Indietro Indice