Alcuni minuti di preparazione e pianificazione prima di mettere in funzione i vostri sistemi può aiutare a proteggere loro e i loro dati.
nosuid
/etc/fstab per partizioni scrivibili da chi non è root. Forse
vorrete anche usare nodev e noexec sulle partizioni home
degli utenti e su /var, proibendo così l'uso di programmi
e la creazioni di character o block device, che comunque non dovrebbe mai
essere necessaria. /etc/exports con l'accesso più restrittivo possibile. Questo
significa non usare wildcard, non permettere accesso in scrittura di root,
e esportare solo in lettura quando è possibile.umask di creazione dei file dei vostri utenti in modo
che sia più restrittiva possibile.
Cfr.
settaggi di umask.illimitato
come di default. Potete controllare i limiti per utente usando il modulo
PAM per la limitazione delle risorse e /etc/pam.d/limits.conf.
Per esempio, i limiti per il gruppo users potrebbero essere:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
Così si proibisce la creazione di file core, si limita il numero di processi a 50 e la memoria disponibile ad ogni utente a 5 MB.
/var/log/wtmp e /var/run/utmp contengono i record
di login per tutti gli utenti del sistema. La loro integrità deve
essere conservata perché possono essere usati per determinare quando
e da dove un utente (o un potenziale intrusore) è entrato nel sistema.
Questi file dovrebbero avere i permessi 644, senza limitare il
normale uso del sistema.
/etc/passwd
o /etc/shadow).
Cfr. la man page chattr(1) per informazioni sul bit immutable.
Trovate tutti i programmi SUID/SGID sul vostro sistema, e tenete appunti su cosa sono, così da essere al corrente di qualsiasi cambiamento che potrebbe indicare un eventuale intrusore. Usate questo comando per trovare tutti i programmi con SUID/SGID sul vostro sistema:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
La distribuzione Debian esegue un job ogni sera per determinare quali file con
SUID esistano. Quindi li compara con quelli della sera precedente. Potete
cercare questo log in /var/log/setuid*.
Potete togliere i permessi SUID o SGID da un programma sospetto con chmod,
quindi rimetterli se pensate che siano assolutamente necessari.
root# find / -perm -2 ! -type l -ls
/dev,
e i link simbolici, da cui il ! -type l
che li esclude dal comando find.
Dei file senza un proprietario possono indicare che qualcuno è entrato nel vostro sistema. Potete trovare i file senza proprietario, o senza gruppo, col comando:
root# find / -nouser -o -nogroup -print
.rhosts dovrebbe essere uno dei vostri compiti di
amministratore , visto che questi file non dovrebbero essere permessi sul
vostro sistema. Ricordate che a un cracker basta un solo account insicuro
per poter avere accesso a tutta la rete. Potete trovare tutti i file
.rhosts sul vostro sistema col seguente comando:
root# find /home -name .rhosts -print
Per finire, prima di cambiare i permessi su un qualsiasi file di sistema, siate certi di sapere quello che fate. Non cambiate mai i permessi di un file perché sembra la via più facile di far funzionare le cose. Determinate sempre la ragione per cui quel file ha quei permessi prima di cambiarli.
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
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.
È 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:
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.
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.
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.
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)
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.
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
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
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/.
"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.