Dopo aver installato il sistema, bisogna renderlo sicuro; molti esempi descritti in questo capitolo puntano ad ottenere tale risultato. Questo dipende dal vostro setup ma per la prevenzione dagli accessi siete invitati a leggere i seguenti paragrafi: Modificare il BIOS (ancora), Sezione 4.1,Impostazione della password in LILO o GRUB, Sezione 4.2,Rimuovere il prompt root nel kernel, Sezione 4.3, Disabilitare il boot da floppy, Sezione 4.4, Circoscrivere l'accesso alla console, Sezione 4.5, e Circoscrivere la possibilità di riavviare da console, Sezione 4.6.
Dopo essersi connessi a qualsiasi rete, specialmente se pubblica, effettuate un aggiornamento di sicurezza (vedete Eseguire un security update, Sezione 4.8). Opzionalmente potete fare un backup del vostro sistema (in merito guardate Una fotografia del sistema, Sezione 4.18).
Ricordate il paragrafo Scegliere una password per il BIOS, Sezione 3.1? Bene, fatelo ora, se non avete bisogno che l'avvio della macchina avvenga da un supporto removibile modificate il BIOS della stessa per renderla avviabile solamente dall'hard disk. Ponete attenzione a non perdere la password del BIOS, altrimenti in caso di fallimento non potrete entrare nel BIOS e cambiare media, ad esempio per avviare da CD-ROM.
Un altro piccolo accorgimento potrebbe essere quello di cambiare la configurazione del BIOS, permettendo al sistema di partire dall'hard disk e se questo fallisce provare con un supporto removibile. A proposito, molte persone non usano la password per il BIOS ed è quindi facile dimenticarsene.
Chiunque può molto facilmente eseguire il login come root e cambiare la vostra password digitando <nome-della-vostra-immagine di avvio> init=/bin/sh al prompt di boot. Dopo aver cambiato la password e aver riavviato il sistema, questa persona ha un accesso illimitato come root e puo impedire l'accesso al sistema. Con questa procedura, non avrete più l'accesso al sistema come root, perché non ne conoscete la password.
Per essere sicuri di evitare di trovarsi in questa situazione dovete impostare una password per il vostro boot loader. Potete scegliere se impostare la password globalmente, oppure per un'immagine precisa.
Per LILO occorre modificare il file /etc/lilo.conf
e aggiungere
una password e la linea restricted come nell'esempio
seguente.
image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted
Fatto questo, bisogna rieseguire lilo. Omettendo la direttiva
restricted lilo vi inviterà nuovamente ad inserire la password,
nonostante abbiate inserito quella giusta. I permessi predefiniti per il file
/etc/lilo.conf
garantiscono a root i permessi di scrittura e
lettura, mentre danno solamente il permesso di lettura di
lilo.conf
al gruppo root.
Se al posto di LILO usate GRUB, modificate /boot/grub/menu.lst
e
aggiungete le seguenti due linee all'inizio (sostituite hackme con
la vostra password). Questo previene che si modifichi la configurazione di
avvio. La direttiva timeout 3 istruisce grub
ad
attendere 3 secondi prima di avviare il sistema.
timeout 3 password hackme
Per conservare l'integrità delle password, si può generare una password
cifrata.Il programma grub-md5-crypt
genera una password
compatibile con l'algoritmo di cifratura di grub (md5). Per specificare in
grub
che si intende usare il sistema di criptazione md5, bisogna
usare la seguente direttiva:
timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
Il parametro --md5, istruisce grub
a usare il processo di
autenticazione md5. L'esempio riporta la versione cifrata con md5 della parola
hackme. Usare il metodo di cifratura delle password md5 è preferibile che
lasciare il testo pienamente leggibile. Potete trovare altre informazioni
sull'uso delle password con grub
nel pacchetto
grub-doc
.
I kernel Linux della versione 2.4 forniscono la possibilità di accedere ad una
shell da superutente durante il boot di sistema subito dopo il caricamento del
file system cramfs. Apparirà un messaggio che permetterà all'amministratore di
accedere ad una shell con privilegi di superutente, questa può essere usata per
caricare manualmente i moduli qualora il riconoscimento automatico fallisca.
Questo è il comportamento predefinito per gli initrd
e per
linuxrc
. Apparirà il seguente messaggio:
Press ENTER to obtain a shell (waits 5 seconds)
Per rimuovere questo comportamento dovrete modificare
/etc/mkinitrd/mkinitrd.conf
e impostare:
# DELAY The number of seconds the linuxrc script should wait to # allow the user to interrupt it before the system is brought up DELAY=0
Quindi rigenerare l'immagine del ramdisk. Lo potete fare con:
# cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
Oppure (preferito):
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
Notate che Debian 3.0 woody consente agli utenti di installare i kernel 2.4
(selezionare flavors) ma il kernel predefinito è il 2.2 (per
preservare alcune architetture su cui il 2.4 non è stato portato). Se lo
ritenete un bug prima di segnalarlo considerate il Bug 145244
.
L' MBR predefinito di Debian prima della versione 2.2 non si comportava come un normale master boot record e lasciava aperto un metodo per entrare abusivamente in un sistema:
Questo comportamento può essere modificato digitando:
lilo -b /dev/hda
Adesso LILO è stato inserito nell' MBR. Un altro modo per eseguire la modifica
è quello di inserire boot=/dev/hda in lilo.conf
.
Esiste anche un' altra soluzione che disabiliterà completamente il prompt MBR:
install-mbr -i n /dev/hda
D'altro canto, questa "backdoor", di cui molta gente non è a conoscenza, potrebbe salvarvi la pelle nel caso andaste incontro a grossi problemi di qualsiasi natura sulla vostra installazione.
FIXME controllare che sia effettivamente vero sulla 2.2 o era la 2.1? INFO: I dischi di boot di Debian 2.2 NON installano l'MBR ma solo LILO.
Alcune politiche di sicurezza potrebbero forzare l'amministratore ad
autenticarsi nel sistema tramite console con le proprie username e password e
successivamente diventare super utente (tramite su
o
sudo
). Questa politica viene implementata in Debian modificando
il file /etc/login.defs
oppure /etc/securetty
se
viene utilizzato PAM:
login.defs
, modificando la variabile CONSOLE che definisce un file
o una lista di terminali su cui è consentito l'accesso come superutente.
securetty
aggiungendo/rimuovendo i terminali su cui sarà
consentito l'accesso come root.
Quando viene utilizzato PAM, altre modifiche al processo di autenticazione,
comprese restrizioni a livello utente e gruppo durante orari prestabiliti,
possono essere configurate in /etc/pam.d/login
. Un' interessante
caratteristica è quella di poter disabilitare l'autenticazione con password
nulle. Questa caratteristica può essere abilitata rimuovendo nullok
dalla linea:
auth required pam_unix.so nullok
Se il vostro sistema ha una tastiera, chiunque (si, chiunque) può
riavviare il sistema senza neanche fare il login. Questo potrebbe o non
potrebbe essere conforme alla vostra policy di sicurezza. Se volete evitarlo,
dovete controllare se nel file /etc/inittab
la linea che include
ctrlaltdel chiama shutdown
con lo switch
-a (ricordatevi di lanciare init q dopo aver
apportato qualsiasi modifica a questo file). In Debian questo switch è
preimpostato:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Ora, per permettere ad alcuni utenti di spengere il sistema, come
spiega la pagina man shutdown(8)
, dovete creare il file
/etc/shutdown.allow
e includere lì i nomi degli utenti che possono
fare un reboot. Quando si fa il saluto delle tre dita (conosciuto
anche come ctrl+alt+del) il programma controlla che sia loggato almeno
uno degli utenti della lista. Se non ce n'è nemmeno uno, shutdown
non eseguirà il riavvio.
Quando si monta una partizione ext2 ci sono diverse opzioni aggiuntive che si
possono applicare all'invocazione di mount o all'/etc/fstab
. Per
esempio, questa è la riga del mio fstab per la partizione /tmp
:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Potete vedere le differenze nella sezione delle opzioni. L'opzione nosuid ignora completamente i bit setuid e setgid, mentre noexec impedisce l'esecuzione di qualsiasi programma su quel mount point e nodev ignora i device. Sembra fantastico, ma
l'opzione noexec evita l'esecuzione diretta dei file binari, ma viene aggirata facilmente:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
Comunque, molti script kiddie hanno exploit che tentano di creare ed eseguire
file in /tmp
. Se non ci riescono, cadranno nel trabocchetto. In
altri termini, un utente non può essere ingannato ed eseguire un binario
trojanizzato in /tmp
, ad esempio aggiungendo /tmp
al
suo PATH.
Siete inoltre avvisati, che l'esecuzione di alcuni script dipende dal fatto che
/tmp
sia eseguibile. In particolare, questa cosa riguarda alcuni
aspetti di Debconf, per maggiori informazioni vedete il Bug 116448
.
Il seguente è un altro esempio. Una nota: /var
può essere
impostata noexec, ma certo software [5] mette i propri eseguibili in /var
. Lo stesso si
applica all'opzione nosuid.
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev,nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev,nosuid,noexec 0 0
/tmp
come noexec
State attenti a impostare /tmp
come noexec quando volete
installare nuovo software, poiché alcuni programmi potrebbero usarla per
l'installazione. Apt
è uno di questi programmi (vedete http://bugs.debian.org/116448
)
se non è configurata correttamente APT::ExtractTemplates::TempDir
(vedete apt-extracttemplates(1)
). Potete impostare questa
variabile in /etc/apt/apt.conf
in modo che punti ad un'altra
directory diversa da /tmp
con privilegi di esecuzione.
Riguardo a noexec, fate attenzione poiché potrebbe non offrire tutta questa sicurezza. Per esempio:
$ cp /bin/date /tmp $ /tmp/date (does not execute due to noexec) $/lib/ld-linux.so.2 /tmp/date (works since date is not executed directly)
Se si imposta /usr
in sola lettura non si potrà più installare
nuovi pacchetti sul proprio sistema Debian GNU/Linux. Si dovrà prima
rimontarla in lettura-scrittura, installare i pacchetti e poi rimontarla in
sola lettura. L'ultima versione di apt
(in Debian 3.0
"woody") può essere configurato per eseguire comandi prima e dopo
l'installazione, così può essere configurato allo scopo.
Per farlo modificare /etc/apt/apt.conf
e aggiungere:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Notate che Post-Invoke può fallire con un messaggio d'errore "/usr busy". Questo succede principalmente quando si stanno usando alcuni file durante l'update che vengono aggiornati. È fastidioso ma non è un vero problema. Appena si è sicuri che non si stanno usando più questi file si esegua manualmente il Post-Invoke.
Non appena nuovi bug di sicurezza vengono scoperti nei pacchetti, i manutentori
di Debian e gli autori dei programmi generalmente li correggono in pochi giorni
o addirittura ore. Dopo di che il bug è risolto, un nuovo pacchetto è reso
disponibile su http://security.debian.org
.
Se state installando una release Debian bisogna tenere a mente che potrebbero essere usciti nel frattempo dei security updates da quando si è scoperto che un dato pacchetto è vulnerabile. Ci potrebbero essere comunque delle minor release (ce ne sono state sette in Debian 2.2 potato) che includono questi aggiornamenti dei pacchetti.
Si deve poi annotare la data in cui i supporti removibili (se li avete usati) sono stati preparati e controllare il sito di security per controllare se ci sono stati aggiornamenti. Se ce sono e non potete scaricare i pacchetti dal sito della sicuezza su un altro sistema (non siete ancora connessi a Internet? o si?) prima di connettervi alla rete potreste pensare (se non siete protetti da un firewall per esempio) di aggiungere regole al firewall per fare in modo che il sistema si possa connettere solo a security.debian.org e poi eseguire l'aggiornamento. Una configurazione di esempio è mostrata in Aggiornamenti di sicurezza protetti da un firewall, Appendice F.
Note: a partire da Debian woody 3.0, dopo l'installazione si ha l'opportunità di aggiungere al sistema gli aggiornamenti di sicurezza. Rispondendo "yes" a questa domanda, il sistema d'installazione provvederà ad aggiungere alla sorgente dei pacchetti gli aggiornamenti di sicurezza del codice sorgente e, se disponete di un collegamento a Internet, a scaricare e installare gli aggiornamenti realizzati dopo la creazione del CD d'installazione. Se state aggiornando una precedente versione di Debian, o avete chiesto al sistema d'installazione di non farlo, agite come spiegato più avanti.
Per aggiornare manualmente il sistema, inserite la seguente riga nel vostro
sources.list
e avrete l'aggiornamento dal ramo security updates
automaticamente, ogni volta che aggiornerete il vostro sistema.
deb http://security.debian.org/ stable/updates main contrib non-free
Fatto ciò, per l'aggiornamento potete usare apt
o
dselect
:
apt
date, da root, il comando:
# apt-get update # apt-get upgrade
dselect
, prima date il comando [U]pdate
(aggiorna), quindi [I]nstall (installa) e infine, [C]onfigure (configura) i
pacchetti installati/aggiornati.
Se volete, potete aggiungere anche la riga deb-src a
/etc/apt/sources.list
. Vedete in apt(8)
per
ulteriori dettagli.
Note: Dal momento che security.debian.org è ospitato in una località non-US e non ha un archivio separato non-US, non c'è bisogno di aggiungere la seguente linea:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
Per ricevere informazioni sugli aggiornamenti di sicurezza disponibili dovreste
iscrivervi alla mailing list debian-security-announce per ricevere i Debian
Security Advisories (DSA). Leggete Il
Security Team in Debian, Sezione 7.1 per maggiori informazioni su come
lavora la squadra di Debian security. Per informazioni su come iscriversi alle
mailing list Debian leggete http://lists.debian.org
.
I DSA sono firmati con la chiave del Team di Debian Security che può essere
ottenuta da http://security.debian.org
.
Si dovrebbe considerare anche l'iscrizione alla mailing list debian-security per discussioni generali su problemi di sicurezza nel sistema operativo Debian.
FIXME: aggiungere qui la chiave?
PAM (Pluggable Authentication Modules) permette agli amministratori di sistema
di scegliere come le applicazioni autenticano gli utenti. Si noti che PAM non
funziona se un'applicazione non è stata compilata con il supporto per PAM.
Molte delle applicazioni fornite con Debian 2.2 hanno questo supporto
integrato. Inoltre Debian non ha il supporto PAM per versioni precedenti alla
2.2. L'attuale configurazione predefinita per un qualsiasi servizio abilitato
PAM è di emulare l'autenticazione UNIX (leggete in
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz
per ulteriori
informazioni su come i servizi PAM dovrebbero funzionare in Debian).
Ogni applicazione con supporto PAM ha un file di configurazione in
/etc/pam.d/
che può essere usato per modificare il suo
comportamento:
La seguente descrizione è lontana dall'essere completa, per ulteriori
informazioni potete leggere The
Linux-PAM System Administrator's Guide
(sul sito primario della
distribuzione PAM
), questo documento è fornito anche dal pacchetto
libpam-doc
.
PAM offre la possibilità di passare attraverso diversi fasi di autenticazione
in una volta sola, senza che l'utente se ne accorga. Si potrebbe autenticare
con un database Berkeley e con un normale file passwd
e l'utente
riuscirebbe a loggarsi se autenticato correttamente da entrambi. Si possono
effettuare molte restrizioni con PAM, così come spalancare le porte del
sistema. Perciò siate prudenti. Una tipica linea di configurazione ha un
campo di controllo come secondo elemento. Generalmente dovrebbe essere
impostata a requisite, in modo che ritorni un messaggio di login
fallita se un modulo fallisce nell'autenticazione.
La prima cosa che mi piace fare è aggiungere alle applicazioni PAM il supporto
MD5, poiché ciò protegge da dictionary cracks (le password possono essere più
lunghe se si usa MD5). Le due linee seguenti dovrebbero essere aggiunte a
tutti i file in /etc/pam.d/
che forniscono un accesso alla
macchina, come login e ssh.
# Siate sicuri di aver già installato libpam-cracklib o non si riuscirà a loggarsi password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
Ma cosa fanno queste linee? La prima carica il modulo PAM cracklib, che
fornisce un controllo sulla qualità delle password, chiede una nuova password
con una lunghezza minima di 12 caratteri, con una differenza di almeno 3
caratteri da quella vecchia e permette un massimo di 3 tentativi. La seconda
linea inserisce il modulo standard di autenticazione con password MD5 e
permette password di lunghezza nulla. La direttiva use_authtok è
necessaria per il passaggio della password dal modulo precedente. Il pacchetto
dipende da una lista di parole (come wenglish
,
wspanish
, wbritish
...), accertatevi che sia
installata quella appropriata per la lingua desiderata (altrimenti potrebbe non
essere affatto utile). [6]
Per essere sicuri che l'utente root possa solo loggarsi nel sistema da
terminali locali, si dovrebbe aggiungere in /etc/pam.d/login
la
seguente linea:
auth requisite pam_securetty.so
Poi si dovrebbe aggiungere in /etc/security/access.conf
i
terminali dai quali l'utente root può loggarsi nel sistema. Ed infine la
seguente linea dovrebbe essere aggiunta se si vogliono stabilire dei limiti per
gli utenti.
session required pam_limits.so
Questa linea riduce le risorse di sistema che gli utenti possono usare (si
guardi oltre in Limitare le risorse usate: il file
limits.conf
, Sezione 4.10.2). Per esempio, si potrebbe
ridurre il numero di login concorrenti (di un certo gruppo di utenti, o
globalmente) ammesse, il numero di processi, la dimensione della memoria...
Ora aprite /etc/pam.d/passwd
e cambiate la prima riga. Dovreste
aggiungere l'opzione "md5" per usare le password MD5, cambiare la
lunghezza minima delle password da 4 a 6 (o più) e stabilire una lunghezza
massima, se lo desiderate. La linea che ne risulta dovrebbe essere simile a:
password required pam_unix.so nullok obscure min=6 max=11 md5
Se si vuole una protezione per il comando su, in modo che solo alcune persone
possano usarlo per diventare root sul sistema, è necessario aggiungere un nuovo
gruppo "wheel" al sistema (questo è il modo più pulito, poiché nessun
file ha permessi relativi a quel gruppo). Aggiungete root e gli altri utenti
che dovrebbero poter usare il comando su
a questo gruppo. Quindi
aggiungete la seguente linea a /etc/pam.d/su
:
auth requisite pam_wheel.so group=wheel debug
Questo garantisce che solo le persone del gruppo "wheel" possano
usare su
per diventare root. Gli altri utenti non saranno in
grado di diventare root. Infatti otterranno un messaggio di errore se
cercheranno di diventarlo.
Se si vuole che solo certi utenti siano autenticati da un servizio PAM, ciò è
ottenibile abbastanza facilmente usando file contenenti gli utenti a cui è
permesso loggarsi. Immaginate di volere che solo l'utente "ref"
possa loggarsi tramite ssh
. Allora dovreste inserirlo in
/etc/sshusers-allowed
e scrivere la linea seguente in
/etc/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Infine, create /etc/pam.d/other
e inserite le seguenti linee:
auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so
Queste linee forniranno una buona configurazione di default per tutte le applicazioni che supportano PAM (l'accesso è negato per default).
limits.conf
È buona norma verificare questo file. Qui si possono definire le
risorse che un'utente può occupare. Se si usa PAM, il file
/etc/limits.conf
è ignorato e si dovrà usare invece
/etc/security/limits.conf
.
Se non si danno limitazioni alle risorse in uso, ogni utente con una
shell valida sul sistema (oppure anche un qualsiasi intruso che voglia
compromettere il sistema tramite un servizio) può usare tutta la CPU, la
memoria e lo stack che il sistema può fornire. Il problema
dell'esaurimento delle risorse può essere risolto con l'uso di PAM.
Notate che esistono dei modi per aumentare i limiti delle risorse in alcune
shell (per esempio, bash
ha ulimit
, vedete
bash(1)
), ma dal momento che non tutte le shell forniscono gli
stessi limiti e visto che l'utente può cambiare shell (vedete
chsh(1)
) è meglio porre dei limiti nei moduli PAM.
Per maggiori informazioni:
Seifried's
Securing Linux Step by Step (Linux sicuro passo passo
sezione
Limiting users overview.
LASG
sezione
Limiting and monitoring users.
È consigliabile configurare opportunamente il file
limits.conf
come sopra.
/etc/login.defs
Il prossimo passo è modificare la configurazione di base e le azioni dopo l'autenticazione degli utenti.
FAIL_DELAY 10
Questa variabile è preferibile impostarla con un valore alto in modo da rendere
difficile l'uso di un terminale per autenticarsi con un attacco a forza bruta.
Se una password viene digitata in modo errato, il possibile attaccante (o
l'utente) dovranno attendere 10 secondi per riavere un nuovo prompt di
autenticazione, questa pausa può essere usata per testare (manualmente) la
password. Attenzione, questa precauzione è inutile se si usano altri programmi
al posto di getty
come ad esempio mingetty
.
FAILLOG_ENAB yes
Se si abilita questa variabile, la fallita autenticazione sarà riportata nei log. Questo è fondamentale per tenere traccia di chiunque provi degli attacchi a forza bruta.
LOG_UNKFAIL_ENAB yes
Se si imposta la variabile FAILLOG_ENAB su yes , allora si dovebbe impostare su yes anche questa variabile. Questa registrerà username sconosciuti se l'autenticazione fallisce. In questo caso, assicuratevi che i file di log abbiano gli opportuni permessi (il 640 ad esempio, con un appropriato gruppo come l'adm) perché spesso gli utenti digitano casualmente la loro password come username e quindi è consigliabile non permettere ad altri di consultare questi file.
SYSLOG_SU_ENAB yes
Questo abiliterà il logging dei tentativi di esecuzione del comando
su
nel syslog
. Questione molto importante su una
macchina seria ma attenzione che può creare dei problemi con la privacy.
SYSLOG_SG_ENAB yes
È la stessa di SYSLOG_SU_ENAB ma si applica al programma
sg
.
MD5_CRYPT_ENAB yes
Come detto in precedenza, le password di tipo MD5 riducono notevolmente il problema di attacchi da dizionario, poiché si possono usare password più lunghe. Se state usando slink, si leggete la documentazione di MD5 prima di abilitare questa opzione. Altrimenti questa sarà regolato in PAM.
PASS_MAX_LEN 50
Se sono attive le password di tipo MD5 nella configurazione PAM, allora questa variabile dovrebbe essere impostata con lo stesso valore di cui sopra.
/etc/ftpusers
Il file /etc/ftpusers
contiene la lista degli utenti che non sono
autorizzati ad autenticarsi all'host usando il servizio ftp. Solo usando
questo metodo potete autorizzare gli utenti ad accedere all'ftp (solitamente
questo è sconsigliato poiché usa le password in chiaro). Se tra i demoni
attivi c'è PAM, si può anche usare questo metodo per autorizzare o negare agli
utenti l'accesso ai servizi.
FIXME (BUG): Questo è un bug di Debian, di default non include negli
ftpusers
tutti gli utenti amministratori (in
base-passwd
).
Se veramente gli utenti hanno la necessità di diventare super user sul vostro
sistema, ad esempio per installare dei pacchetti o aggiungere utenti, potete
utilizzare il comando su
per cambiare la vostra identità. Si
dovrebbe tentare di evitare ogni accesso come utente root e utilizzare al suo
posto su
. Al momento, la soluzione migliore è rimuovere
su
e passare a sudo
, che ha più possibilità di
su
. Ad ogni modo, su
è più comune visto che è
utilizzato su numerosi altri Unix.
sudo
permette agli utenti di eseguire determinati comandi sotto
l'identità di un altro utente, perfino come root. Se l'utente é aggiunto a
/etc/sudoers
e si autentica correttamente, é in grado di eseguire
comandi che sono stati definiti in /etc/sudoers
. Violazioni, come
una password non corretta o il tentativo di eseguire un programma non permesso,
sono registrati e notificati via mail a root.
Si dovrebbe modificare /etc/security/access.conf
per impedire il
login da remoto per l'amministrazione. In questo modo gli utenti devono usare
su
(o sudo
) cosicché rimarrà sempre una traccia che
un utente locale vuole usare i privilegi di amministratore.
Si deve aggiungere la seguente riga a /etc/security/access.conf
,
il file di configurazione di default di Debian ha una riga simile commentata:
-:wheel:ALL EXCEPT LOCAL
A volte si potrebbe pensare di avere la necessità di creare utenti nel proprio sistema locale per fornire un determinato servizio (pop3 mail o ftp). Prima di fare ciò, ricordate prima che l'implementazione di PAM in Debian GNU/Linux permette di validare utenti con un'ampia varietà di servizi di directory esterni (radius, ldap, ecc.) forniti dai pacchetti libpam.
Se gli utenti devono essere creati ed è possibile accedere al sistema da remoto
tenete presente che gli utenti potranno effettuare il login nel sistema.
Potete rimediare a questo assegnando agli utenti una shell vuota
(/dev/null
) (dovrebbe essere nella lista di
/etc/shells
). Se volete permettere agli utenti di accedere al
sistema limitando i loro movimenti, potete utilizzare /bin/rbash
,
equivalente ad aggiungere l'opzione -r a bash
(RESTRICTED SHELL, vedete bash(1)
). Notate che persino
con una shell ristretta, un utente che accede a un programma interattivo (che
potrebbe permettere l'esecuzione di una sotto shell) potrebbe aggirare i limiti
della shell.
Debian attualmente fornisce nella versione unstable (e dovrebbe essere incluso
nelle prossime versioni stabili) il modulo pam_chroot
(in
libpam-chroot
). Un'alternativa è usare chroot
sul
servizio che fornisce il login remoto (ssh
, telnet
).
[7]
Se si desidera limitare il quando gli utenti possono accedere il
sistema si dovrà configurare /etc/security/access.conf
per i
propri bisogni.
Informazioni su come ingabbiare con chroot
gli utenti che accedono
al sistema attraverso il servizio ssh
è descritto in Ambiente Chroot
per
SSH
, Appendice G.
Se siete paranoici potreste voler aggiungere un /etc/profile
di
sistema che imposti l'ambiente in modo che gli utenti non possano rimuovere le
capacità di verifica dalla shell (i comandi sono scritti in
$HISTFILE). Il file /etc/profile
dovrebbe essere
impostato come segue:
HISTFILE=~/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 readonly HISTFILE readonly HISTSIZE readonly HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE
Perché questo funzioni, l'utente può solo aggiungere informazioni al
.bash_history
. Dovete anche impostare l'opzione
append-only usando il programma chattr
a
.bash_history
per tutti gli utenti. [8].
Notate che si potrebbe fare ciò per il .profile
di ciascun utente.
Ma poi dovreste impostare i permessi correttamente: con le home directory degli
utenti che non appartengano a loro ma abilitare gli utenti a leggere
la configurazione in .profile
e scrivere in
.bash_history
. Potrebbe essere buona cosa impostare il flag
inmutable (sempre usando chattr
) per
.profile
anche se si procede in questo modo.
Se siete completamente paranoici e volete controllare ogni comando dell'utente,
potete prendere il codice sorgente di bash
e modificarlo perché
registri tutto ciò che l'utente scrive su un altro file. O avere
ttysnoop
che costantemente monitora ogni nuova tty e scrive
l'output in un file. Un altro programma utile è snoopy
che è
trasparente all'utente e si insinua come una libreria fornendo un wrapper per
le chiamate execve(), ogni comando eseguito é registrato con
syslogd
usando la direttiva authpriv (solitamente
registrato in /var/log/auth.log
).
Notate che non si può usare il comando script
per questo poiché
non funzionerà come shell (perfino se lo si aggiunge in
/etc/shells
).
L'esempio precedente è un modo semplice per configurare l'esame degli utenti ma
potrebbe essere di dubbia utilità nei sistemi complessi. Se è il vostro caso,
dovete dare un'occhiata a acct
, le utility per l'accounting.
Queste utility registreranno tutti i comandi impartiti dagli utenti a spese
dello spazio su disco.
Quando si attiva l'accounting, tutte le informazioni sui processi e gli utenti
sono mantenute sotto /var/account/
, più specificamente in
pacct
. Il pacchetto di accounting include degli strumenti
(sa
e ac
) per analizzare questi dati.
Se volete vedere cosa facciano solitamente gli utenti, quando si
connettono potete usare il database wtmp
che include tutte le
informazioni di login. Il file può essere processato con diverse utility, tra
cui sac
che può restituire un profilo per ogni utente che mostra
in quale arco di tempo solitamente si connettono.
Nel caso in cui abbiate attivato l'accounting, potete anche utilizzare gli strumenti da esso forniti per determinare quando gli utenti accedono al sistema e cosa eseguano.
In base alla vostra linea di condotta riguardo agli utenti, potreste voler
cambiare il modo in cui gli utenti si scambiano informazioni, ossia quali siano
i permessi predefiniti dei nuovi file creati dagli utenti. Questo viene fatto
impostando una propria umask per ogni utente. Potete cambiare
l'impostazione UMASK in /etc/limits.conf
,
/etc/profile
, /etc/csh.cshrc
,
/etc/csh.login
, /etc/zshrc
e probabilmente anche
altri (a seconda delle shell che avete installato sul vostro sistema). Di
tutti questi, l'ultimo ad essere caricato ottiene la precedenza. L'ordine è:
il limits.conf
di PAM, la configurazione standard di sistema per
la shell utente, la shell utente (i suoi ~/.profile
,
~/.bash_profile
...)
L'impostazione predefinita di Debian per l'umask è 022
che significa che i file (e le directory) possono essere letti e visitati dai
membri del gruppo dell'utente e da qualsiasi altro utente nel sistema. Se
questo risultasse troppo permissivo per il vostro sistema, dovrete cambiare le
impostazioni dell'umask per tutte le shell (e per il PAM). Non dimenticatevi
di modificare i file sotto /etc/skel/
poiché saranno questi i
nuovi default degli utenti creati con il comando adduser
.
Da notare, comunque, che gli utenti possono modificare la loro umask se lo vogliono, rendendola più permissiva o più restrittiva.
FIXME. Spiegare le conseguenze del cambiare i permessi dei pacchetti quando si
aggiornano (ed un admin paranoico dovrebbe mettere in chroot
i
suoi utenti, comunque).
Se dovete dare accesso shell agli utenti, pensateci bene. Un utente, a meno che non sia in un ambiente pieno di restrizioni (come una prigione chroot), può carpire molte informazioni sul sistema, tra cui:
/etc
. Comunque i permessi di
default per file contenenti informazioni sensibili, in Debian (per esempio file
contenenti password), prevengono l'accesso a informazioni critiche. Per vedere
quali file sono accessibili solo da root basta un find /etc -type f -a
-perm 600 -a -uid 0 eseguito da superuser.
/usr/share/doc
o tirando a indovinare guardando gli eseguibili e
le librerie.
/var/log
. Notate inoltre che alcuni file di
log sono accessibili solo da root e dal gruppo adm (provate un
find /var/log -type f -a -perm 640) e alcuni sono perfino
disponibili solo a root (provate un find /var/log -type f -a -perm 600 -a
-uid 0).
Cosa può visualizzare un utente nel vostro sistema? Probabilmente un sacco di cose, provate questo (fate un respiro profondo):
find / -type f -a -perm +006 2>/dev/null find / -type d -a -perm +007 2>/dev/null
L'output è la lista dei file che un utente può vedere e le directory a cui ha accesso.
Se permettete l'accesso tramite shell da parte degli utenti potrebbe essere desiderabile limitare quali informazioni di altri utenti possano vedere. Gli utenti con accesso alla shell tendono a creare un gran numero di file nella loro $HOME: caselle di posta, documenti personali, configurazioni di applicazioni per X/GNOME/KDE...
In Debian ogni utente è creato con un gruppo associato e due utenti non appartengono mai allo stesso gruppo. Questo è il comportamento predefinito: quando l'utente X viene creato, un gruppo di nome X viene creato e l'utente è assegnato ad esso. Questo evita il concetto di gruppo di utenti che renderebbe più difficile per gli utenti nascondere informazioni agli altri.
Tuttavia, le directory $HOME degli utenti sono create con permessi 0755 (leggibili dal gruppo e da tutti gli altri). I permessi di gruppo non sono un problema perché solo l'utente appartiene a quel gruppo, ma i permessi globali potrebbero (ma anche no) essere un problema, in relazione alle scelte locali.
Questo comportamento può essere cambiato in modo che la creazione di un utente
fornisca permessi diversi su $HOME. Per cambiare il comportamento
per i nuovi utenti quanto sono creati, nel file di configurazione
/etc/adduser.conf
cambiate DIR_MODEin 0750 (nessun
permesso globale).
Gli utenti possono ancora condividere informazioni, ma non direttamente nelle loro directory $HOME, a meno che non cambino i loro permessi.
Notate che questo impedirà agli utenti di creare la loro pagina web personale
(~utenteX
) se è installato un web server, poiché quest'ultimo non
sarà in grado di leggere la directory $HOME e di conseguenza neanche
la directory sottostante public_html
. Se volete permettere agli
utenti di pubblicare pagine HTML nei loro ~userX/public_html
,
modificate DIR_MODE per avere permessi 0751. Questo consentirà al
server web di accedere a quella directory (che dovrebbe avere permessi 0755) e
fornire il contenuto pubblicato dagli utenti.
Ci sono molti casi in cui un amministratore ha necessità di creare molti
account e di fornire password per ognuno di essi. Ovviamente l'amministratore
potrebbe semplicemente scegliere come password il nome scelto dall'utente per
l'account, ma ciò non sarebbe molto furbo per quanto riguarda la sicurezza. Un
approccio migliore consiste nell'usare un programma per generare password.
Debian offre i pacchetti makepasswd
, apg
e
pwgen
, che forniscono programmi (con nome uguale a quello del
pacchetto) che possono essere usati per questo scopo. Makepasswd
genererà password totalmente casuali, con enfasi sulla sicurezza piuttosto che
sulla pronunciabilità, mentre pwgen
cercherà di creare password
senza senso ma pronunciabili (ovviamente questo dipende dalla lingua madre).
Apg
ha algoritmi per entrambi (per questo programma esiste una
versione client/server ma non è inclusa nel pacchetto Debian).
Passwd
non permette assegnamento non interattivo di password
(poiché usa direttamente l'accesso tty). Se volete cambiare password mentre
state creando un gran numero di utenti, potete creare quest'ultimi usando
adduser
con l'opzione --disabled-login e poi usando
chpasswd
[9]
(incluso nel pacchetto passwd
, che è già installato). Se si vuole
usare un file contenente tutte le informazioni per creare gli utenti come un
processo batch può essere utile usare newusers
.
Le password degli utenti possono talvolta diventare il componente più
debole nella sicurezza di un sistema. Ciò è dovuto alla scelta da parte
degli utenti di password di scarsa qualità per i loro account (e più utenti
hanno accesso più le possibilità che questo accada crescono). Anche se sono
stati impostati controlli con il modulo PAM cracklib e limiti descritti nella
Autenticazione degli utenti: PAM, Sezione 4.10.1 gli
utenti saranno comunque in grado di usare password deboli. Poiché l'accesso
per gli utenti potrebbe includere accesso da shell remote (si spera tramite
ssh
) è importante che una persona che attacchi il sistema da
remoto non sia in grado di indovinare le password degli utenti (dopo aver
ottenuto la lista degli utenti con altri mezzi).
Un amministratore di sistema deve, ipotizzando un gran numero di utenti,
controllare se le password scelte sono consistenti con le scelte di sicurezza
locali. Come effettuare questo controllo? Provando a forzarle come farebbe
una persona che attacca il sistema se avesse accesso alle password crittate (il
file /etc/shadow
).
Un amministratore di sistema può usare john
o crack
(entrambi sono crackatori di password brute force) insieme ad una appropriata
lista di parole [10] per
controllare le password degli utenti e prendere provvedimenti appropriati
quando si trova una password debole.
Solitamente gli utenti inattivi sono un problema per la sicurezza. Un utente potrebbe essere inattivo perché è fuori a pranzo o perché una connessione remota interrotta non è stata ristabilita. Qualunque sia la ragione, gli utenti inattivi possono essere causa di problemi:
telnet
).
Alcuni sistemi remoti sono stati compromessi attraverso uno screen
inattivo (distaccato).
La disconnessione automatica degli utenti inattivi di solito è una parte della politica di sicurezza che occorre rafforzare. Ci sono molti modi per realizzarla:
bash
, l'amministratore di sistema può
impostare un valore di default per la variabile TMOUT (vedete
bash(1)
) che fa sì che la shell disconnetta automaticamente gli
utenti inattivi. Notate che la variabile va impostata con l'opzione
-o altrimenti gli utenti saranno in grado di modificarla o
rimuoverla.
timeoutd
e configurare /etc/timeouts
secondo la propria politica di sicurezza locale. Il demone controllerà se ci
sono utenti inattivi e manderà in time out le loro shell secondo la
configurazione impostata.
autolog
e configurarlo per disconnettere gli utenti
inattivi.
I demoni timeoutd
e autolog
sono i metodi
consigliati, dal momento che gli utenti possono cambiare la loro shell di
default o passare ad un'altra shell (non controllata) dopo aver avviato la loro
shell predefinita.
I TCP wrapper sono stati sviluppati quando ancora non erano disponibili dei
veri filtri di pacchetti ed era necessario controllare gli accessi. I TCP
wrapper permettono di consentire o negare un servizio ad un host o ad un
dominio e di definire una regola predefinita per consentire o meno l'accesso.
Se desiderate maggiori informazioni al riguardo, date un'occhiata a
hosts_access(5)
.
Molti servizi installati in Debian sono:
tcpd
)
In un caso, per i servizi configurati in /etc/inetd.conf
(inclusi
telnet
, ftp
, netbios
, swat
e finger
) si può notare che il file di configurazione esegue prima
/usr/sbin/tcpd
. Nell'altro, anche se il servizio è lanciato dal
superdemone inetd
, il supporto per le regole dei tcp wrapper può
essere compilato al suo interno. In Debian, tra i servizi compilati con il
supporto ai tcp wrapper ci sono ssh, portmap, in.talk, rpc.statd,
rpc.mountd, gdm, oaf
(il demone di attivazione GNOME),
nessus
e molti altri.
Per vedere quali pacchetti usano i tcpwrapper provate con:
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \ sed 's/,libwrap0$//;s/^[[:space:]]\+//'
Occorre tenerne conto quando si usa tcpchk
. I servizi compilati
col supporto alla libreria wrapper possono essere aggiunti ai file
hosts.deny
e hosts.allow
ma tcpchk
avviserà che non è in grado di trovare questi servizi, perché li cerca in
/etc/inetd.conf
(la manpage non è molto chiara su questo punto).
Di seguito riportiamo un trucchetto; probabilmente il più piccolo sistema di
rivelazione di intrusione possibile. In generale dovreste avere una buona
politica di firewall come prima linea di difesa ed i tcp wrapper come seconda
linea. Un trucchetto è quello di impostare un comando SPAWN [11] in
/etc/hosts.deny
che spedisce una mail all'utente root ogni volta
che un servizio viene negato attraverso i wrapper:
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /usr/bin/mail -s "Connection to %d blocked" root) &
Attenzione: L'esempio sopra è esposto a attacchi di tipo DoS stabilendo molte connessioni in un breve periodo di tempo. Molte email causano un elevato I/O di file spedendo solo pochi pacchetti.
È evidente che il modo di trattare log e avvisi è una questione importante in un sistema sicuro. Supponiamo che un sistema sia perfettamente configurato e sicuro al 99%. Se viene portato un attacco al restante 1% e non ci sono misure di sicurezza pronte, innanzitutto a rilevarlo e poi ad attivare allarmi, il sistema non è per nulla sicuro.
Debian GNU/Linux fornisce alcuni strumenti per svolgere l'analisi dei log, in
particolare swatch
, [12] logcheck
o log-analysis
(tutti
questi avranno bisogno di un po' di personalizzazione per rimuovere le cose
superflue dal rapporto). Potrebbe anche essere utile, se il sistema si trova
nelle vicinanze, avere i log di sistema stampati su una console virtuale.
Questo è utile perché si può (da lontano) vedere se il sistema sta funzionando
correttamente. In Debian, il file /etc/syslog.conf
ha già in
partenza una configurazione predefinita commentata; per abilitarla, togliete i
commenti dalle linee e riavviate syslogd
(/etc/init.d/syslogd restart):
daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8
C'è molto altro a proposito dell'analisi dei log che non può essere trattato
qui, una buona fonte di informazioni sono le Risorse sull'analisi dei
log di Counterpane
. In ogni caso, anche gli strumenti automatizzati
nulla possono contro il miglior strumento di analisi: il vostro cervello.
logcheck
Il pacchetto logcheck
in Debian è diviso in due parti:
logcheck
(il programma vero e proprio) e
logcheck-database
(un database di espressioni regolari per il
programma). In Debian è predefinito (in /etc/cron.d/logcheck
) che
logcheck
venga eseguito giornalmente alle 2 AM e una volta dopo
ogni riavvio.
Questo strumento, se propriamente configurato, può essere molto utile per
segnalare all'amministratore gli eventi inusuali del sistema.
Logcheck
può essere completamente personalizzato in modo da
mandare mail a proposito di eventi registrati nei log che sembrano degni di
attenzione. L'installazione predefinita include profili (per gli eventi da
ignorare e le violazioni delle politiche adottate) per tre diverse
configurazioni (workstation, server e paranoide). Il pacchetto Debian include
un file di configurazione /etc/logcheck/logcheck.conf
, generato
dal programma, che definisce a quale utente vengono spedite le verifiche.
Inoltre fornisce, ai pacchetti che offrono servizi, un modo per implementare
nuove politiche nelle cartelle:
/etc/logcheck/hacking.d/_packagename_
,
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
e
/etc/logcheck/ignore.d.workstation/_packagename_
. Tuttavia, al
momento, non molti pacchetti ne fanno uso. Se avete una politica che può
essere utile ad altri utenti, per favore speditela come rapporto bug per il
pacchetto appropriato (come wishlist bug). Per ulteriori informazioni
leggere /usr/share/doc/logcheck/README.Debian
.
Il miglior modo di configurare logcheck
è installarlo (chiederà a
quale utente spedire i rapporti e genererà
/etc/logcheck/logcheck.logfiles
dalle voci di syslog). Se si
desidera aggiungere nuovi file di log, aggiungerli in
/etc/logcheck/logcheck.logfiles
. Le dipendenze dei pacchetti
forzeranno anche l'installazione di logcheck-database
; durante
l'installazione verrà chiesto il livello di sicurezza desiderato: workstation,
server o paranoia. Questo farà sì che /etc/logcheck/ignore.d
punti alle cartelle appropriate (per mezzo di collegamenti simbolici). Per
modificare ciò eseguire dpkg-reconfigure -plow logcheck-database.
Poi, creare /etc/ignore.d/local
; questo file conterrà tutte le
regole per escludere i messaggi che non dovrebbero essere riportati. Per il
momento, lasciatelo vuoto (un semplice cp /dev/null
/etc/ignore.d/local sarà sufficiente).
Una volta fatto questo, forse vorrete controllare per i primi
giorni/settimane/mesi le email che vengono spedite. Se vengono spediti
messaggi che non desiderate ricevere, aggiungete le espressioni regolari
(vedete regex(7)
) che corrispondono a questi messaggi in
/etc/ignore.d/local
. È un processo di taratura al quale si
deve dedicare il tempo necessario; Quando i messaggi spediti saranno sempre
rilevanti la messa a punto potrà considerarsi conclusa. Notate che, anche se
logcheck
è in esecuzione, se non trova nulla di rilevante nel
sistema non spedirà email (così potrete ricevere un solo messaggio a settimana,
con un po' di fortuna).
Debian nasce con una configurazione standard per syslog (in
/etc/syslog.conf
) che registra i messaggi in file appropriati a
seconda della configurazione del sistema. Dovreste avere dimestichezza con
questo; date un'occhiata al file syslog.conf
e alla
documentazione. Se intendete mantenere un sistema sicuro dovreste fare
attenzione a dove i messaggi di log vengono spediti cosicché non passino
inosservati.
Per esempio, mandare i messaggi su una console è una configurazione utile per sistemi di diversi livelli di produzione. Ma per altri sistemi è ugualmente importante aggiungere una nuova macchina che faccia da loghost (cioè riceva i log da tutte le altre macchine del sistema).
Si dovrebbe considerare anche la posta di root, molti programmi per il
controllo della sicurezza (come snort
) mandano gli avvisi a root
via posta. Questa mailbox di solito punta al primo utente creato nel sistema
(controllare /etc/aliases
). Preoccupatevi di mandare la posta di
root in qualche posto dove verrà letta (localmente o remotamente).
Ci sono altri account di ruolo ed alias nel tuo sistema. In un piccolo sistema é, probabilmente, più facile far sì che tutti gli alias puntino a root e che la posta di root venga inoltrata alla casella personale dell'amministratore di sistema.
FIXME: sarebbe interessante spiegare come un sistema Debian possa
spedire/ricevere SNMP traps riguardanti problemi di sicurezza (jfs).
Controllare: snmptraglogd
, snmp
e snmpd
.
Un loghost è un host che raccoglie i dati di syslog remoti dalla rete. Se una
delle vostre macchine viene compromessa, l'intruso non é in grado di coprire le
sue tracce, a meno che non penetri anche nella macchina loghost. Perciò, il
loghost dovrebbe essere particolarmente sicuro. Rendere una macchina un
loghost è semplice. Basta avviare syslogd
con syslogd
-r e un nuovo loghost è nato. Perché questa azione sia permanente, in
Debian, modificate /etc/init.d/sysklogd
e cambiate la riga
SYSLOGD=""
in
SYSLOGD="-r"
Successivamente, configurate le altre macchine perché spediscano i dati al
loghost. Aggiungete una riga simile alla seguente al file
/etc/syslog.conf
:
facility.level @your_loghost
Guardate la documentazione per cosa usare al posto di facility e level (non dovrebbero contenere queste parole). Se volete registrare ogni cosa remotamente, scrivete:
*.* @your_loghost
nel vostro syslog.conf
. La registrazione dei log sia remota che
locale è la migliore soluzione (l'attaccante potrebbe pensare di aver coperto
le sue tracce dopo la cancellazione dei log locali). Vedete la pagine di
manuale di syslog(3)
, syslogd(8)
e
syslog.conf(5)
per ulteriori informazioni.
Non è solo importante decidere come gli vengono usati gli avvisi, ma anche chi ha accesso in lettura/modifica dei file di log (se non si usa un loghost remoto). Gli avvisi di sicurezza che l'attaccante può cambiare o disabilitare non sono il peggiore danno di un'intrusione. Infatti, dovete tenere a mente che questi file di log possono rivelare molte informazioni riguardo il proprio sistema ad un attaccante che ne abbia libera lettura.
Alcuni permessi sui file di log non sono perfetti dopo una installazione (ma
questo ovviamente dipende dalla propria politica di sicurezza locale). Per
prima cosa /var/log/lastlog
e /var/log/faillog
non
necessitano di essere letti dagli utenti normali. Nel file
lastlog
potete vedere chi ha effettuato un login recentemente e in
faillog
potete vedere un riassunto dei login falliti. L'autore
raccomanda chmod 660
per entrambi. Date una rapida occhiata ai
vostri file di log e decidete molto attentamente quali rendere
leggibili/scrivibili per utenti con UID diversi da 0 e gruppi che non siano
"adm" o "root". Si può facilmente controllare quanto
descritto nel proprio sistema con:
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u (see to what users do files in /var/log belong) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (see to what groups do files in /var/log belong) # find /var/log -perm +004 (files which are readable by any user) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (files which belong to groups not root or adm)
Per personalizzare come i file di log vengono creati probabilmente si dovrebbe
modificare il programma che li genera. Se i file di log vengono ruotati (vgs.
logrotate
), ad ogni modo, dovreste personalizzare il comportamento
di creazione e rotazione.
FIXME: Aggiungere ulteriori contenuti. spiegare come queste specifiche patch possono essere installate in Debian usando i pacchetti kernel-2.x.x-patch-XXX.
Debian GNU/Linux è provvista di molte patch per il Kernel di Linux per migliorarne la sicurezza. Queste includono:
lids-2.2.19
), di Huagang
Xie e Philippe Biondi. Questa modifica del kernel semplifica il processo di
protezione di un sistema Linux, permettendo la limitazione, l'occultamento e la
protezione di processi e di determinati file, in modo che nemmeno l'utente root
possa intervenire su di essi. Per di più, si possono anche impostare
funzionalità per alcuni processi: imperdibile, per l'amministratore di sistema
paranoico. Pagina di riferimento: http://www.lids.org
kernel-patch-acl
). Questa modifica del kernel aggiunge delle
liste di controllo degli accessi, un metodo avanzato per limitare e controllare
l'accesso a file ed a cartelle; è stato aggiunto al kernel di sviluppo 2.5 e
sarà incluso in modo predefinito nel futuro kernel 2.6. Pagina di riferimento:
http://acl.bestbits.at/
trustees
). Questa modifica del
kernel aggiunge un sistema avanzato di gestione dei permessi del kernel Linux.
Oggetti speciali, chiamati trustees (curatori) sono uniti ad ogni file o
cartella e riposti nella memoria del kernel, questo permette un rapido
controllo di tutti i permessi. Pagina di riferimento: http://trustees.sourceforge.net/
selinux
si può anche trovare sul sito degli sviluppatori
)
kernel-patch-2.2.18-openwall
, della Solar Designer, utile insieme
di restrizioni relative al kernel, come restrizioni ai collegamenti, FIFO in
/tmp
, un file system con cartella /proc
ad accesso
ristretto, un approccio speciale nei descrittori dei file, un divieto di
esecuzione nell'area dello stack dell'utente e altro ancora. Pagina web di
riferimento: http://www.openwall.com/linux/
kernel-patch-2.2.19-harden
kernel-patch-freeswan
). Se si
vuole usare il protocollo IPsec con Linux, occorre questa patch, con la quale
si possono creare delle VPN, anche per macchine Windows, in modo molto
semplice, dal momento che IPsec è uno standard comune. Le funzionalità IPSec
sono state aggiunte al kernel di sviluppo 2.5 e questa caratteristica sarà
inclusa in modo predefinito nel futuro kernel 2.6. Pagina web di riferimento:
http://www.freeswan.org
cryptoapi-core-source
. Questa patch aggiunge al kernel delle
funzioni di crittografia, come la cifratura e il sommario delle funzioni. Gli
usi più comuni per queste funzioni sono la codifica dei filesystem o delle
partizioni di swap. Notate che dalla versione 2.5.45 del kernel sono state
aggiunte delle funzioni simili, talmente simili che dai kernel 2.6 non avrete
bisogno di queste patch. Nota: questo pacchetto non esiste in
versioni di Debian precedenti a Sarge
. Sito di
riferimento: http://www.kerneli.org/
cryptoloop-source
. Queste migliorie permettono di usare le
funzioni che si trovano nel pacchetto crytoapi-core-source
per
creare dei filesystem cifrati usando il device di loopback.
kernel-patch-int
. Questa patch estende le funzioni di criptazione
del kernel e può essere usata dalle versioni Debian fino a Potato. Woody non è
supportata da questo, e se usate sarge o una nuova versione vi invito ad usare
il più recente cryptoapi-core-source
.
Sebbene molte patch non siano ancora in Debian. Se avete bisogno che siano
incluse chiedete di loro al gruppo Work
Needing and Prospective Packages
. Alcuni di questi sono:
chroot
, si propone come più semplice da configurare e più
flessibile. Pagina principale: http://www.immunix.org/subdomain.html
http://ramses.smeyers.be/useripacct
.
Buffer overflow è il nome di un comune attacco al software che approfitta di un controllo insufficiente (un comune errore di programmazione) in seguito all'esecuzione di codice da un input. Questo attacco, contro i server che rimangono in attesa di una connessione remota e contro il software che gira localmente, ma che permette degli alti privilegi agli utenti (grazie ai setuid e setgid attivi) può compromettere ogni sistema.
Esistono quattro metodi principali per proteggersi dai buffer overflow:
questo
documento
).
Debian GNU/Linux, dalla versione 3.0, include programmi che permettono di
implementare il primo e l'ultimo di questi metodi (patch e strumenti per
scovare i possibili buffer overflow). L'uso di questi programmi richiede una
certa esperienza nel applicare le patch (e ricompilare) il codice. Debian ad
esempio mette a disposizione: bfbtester
(un programma che serve a
verificare l'esistenza di buffer overflow) e njamd
.
Come per le patch per il kernel (descritte nel paragrafo Includere le patch nel kernel, Sezione 4.13),
Openwall si occupa della protezione contro i buffer overflow per i kernel 2.2.
Invece per quanto riguarda i kernel della serie 2.4 si deve usare la Grsecurity
patch (inclusa nel pacchetto kernel-patch-2.4-grsecurity
, che
include Openwall e molte altre funzionalità
(che
includono ACL per rendere difficoltoso ottenere informazioni da un sistema
operativo remoto) oppure i moduli di sicurezza linux (sono presenti nei
pacchetti: kernel-patch-2.4-lsm
e
kernel-patch-2.5-lsm
).
In ogni caso questi consigli non prevengono i buffer overflow poiché esistono
dei modi per aggirare queste precauzioni, metodi descritti nel numero
58
del phrack's magazine.
Durante la normale amministrazione, solitamente si ha bisogno di importare o di
esportare dei file dal sistema installato. Si può riuscire a copiare i file da
un host ad un altro in maniera sicura, usando il pacchetto server
sshd
. Un'altra possibilità è l'impiego di ftpd-ssl
,
un server ftp che adotta il Secure Socket Layer per cifrare le
trasmissioni.
Naturalmente, tutti questi metodi necessitano di client speciali e Debian ne
offre alcuni: per esempio, con ssh
fornisce scp
, che
funziona come rcp
ma è completamente cifrato, cosicché i
cattivi ragazzi non possano nemmeno capire CHE COSA si stia copiando.
C'è anche un pacchetto cliente ftp-ssl
per il server
corrispettivo. Per questi programmi, si trovano client anche di altri sistemi
operativi (non-UNIX); per copiare in sicurezza, putty
e
winscp
forniscono un'implementazione adatta a qualsiasi versione
del sistema operativo della Microsoft.
Notate che usare scp
consente a tutti gli utenti l'accesso
all'intero file-system, a meno che non sia stato dato il comando
chroot
, come spiegato nella Chroot di ssh, Sezione 5.1.1.
Si può configurare l'accesso FTP, attraverso chroot
, in modo anche
più semplice, a seconda del demone scelto, come illustrato nella Rendere sicuro FTP, Sezione
5.3. Se si teme che gli utenti sfoglino i file locali e si vuole avere una
comunicazione cifrata, si può utilizzare un demone ftp con supporto SSL, o
abbinare un ftp che trasmette testo in chiaro e un'impostazione VPN (cfr. Rete privata virtuale (VPN), Sezione
8.5).
Avere un buon criterio di assegnazione delle quote è importante, poiché evita che gli utenti riempiano gli o l'hard disk.
Si possono avere due differenti sistemi di quote: la quota d'utente e la quota di gruppo. Come si intuisce, la quota per utente limita la quantità di spazio di cui un utente può disporre e la quota di gruppo fa lo stesso, ma verso i gruppi. Ricordatene quando decidete la dimensione delle quote.
Nell'impostare un sistema di quote, bisogna tenere conto di alcuni punti importanti:
/home
come su /tmp
.
Ogni partizione o cartella a cui gli utenti abbiano pieno accesso in scrittura dovrebbe essere organizzata in quote. Il calcolo e l'assegnazione di una quota su cui si possa lavorare, unisce utilizzabilità e sicurezza.
Supponiamo che vogliate usare il sistema quote: prima di tutto, bisogna
controllare che il supporto per le quote sia abilitato nel kernel (se non lo è,
va ricompilato); dopo di che, controllate che il pacchetto quota
sia installato (se non lo è, bisogna fare anche questo).
Per abilitare le quote per i rispettivi file system basta modificare
l'impostazione nel file /etc/fstab
da defaults a
defaults,usrquota. Se c'è bisogno delle quote di gruppo a,
sostituite grpquota a usrquota. Si possono
utilizzare entrambe le opzioni. Quindi, basta creare due file vuoti quota.user
e quota.group nella root del file system dove si vogliono usare le quote (ad
esempio, per un file system /home
, date il comando touch
/home/quota.user /home/quota.group).
Riavviare quota lanciando: /etc/init.d/quota stop;/etc/init.d/quota start. A questo punto, dovrebbe funzionare e potete impostare le dimensioni delle quote.
Per modificare le quote di un particolare utente (di "giorgio", per esempio) basta dare il comando edquota -u giorgio; per quelle di un gruppo, invece, edquota -g <gruppo>. Infine impostate il modo quota fissa o variabile e/o le quote inode, a piacere.
Per maggiori informazioni sulle quote, leggere le relative pagine man ed il
quota mini-HOWTO (/usr/share/doc/HOWTO/en-html/mini/Quota.html
)
(mini guida su quota).
Può darsi che lshell
non piaccia, dal momento che viola il FHS:
ebbene, tenete presente che pam_limits.so potrebbe svolgere le medesime
funzioni e che lshell
è attualmente orfana
(senza manutentore).
Oltre ai soliti permessi di tipo Unix, i filesystem ext2 ed ext3 offrono un
insieme di attributi specifici per dare un maggiore controllo sui file del
sistema. A differenza dei permessi di base, questi non vengono mostrati con il
comando ls -l
o modificati mediante chmod
; per
amministrarli, occorrono altre due utilità: lsattr
e
chattr
(nel pacchetto e2fsprogs
). Notate che ciò
significa che tali attributi non saranno salvati con la copia di sicurezza del
sistema; così, qualora se ne modifichi uno qualsiasi, sarebbe meglio salvare in
uno script i successivi comandi chattr
, così da poterli
reimpostare in un secondo momento, all'atto di un eventuale ripristino.
Fra tutti gli attributi disponibili, i due più importanti, nell'aumentare la sicurezza sono richiamati dalle lettere "i" e "a" e possono essere impostati o rimossi dal superutente:
/var/log/
, anche se si dovrebbe considerare che,
talvolta, questi vengono spostati, per via degli script di rotazione dei log.
Si possono impostare questi attributi anche per le cartelle; in tal caso nessuno può modificarne i contenuti, rinominando o rimuovendo dei file. Applicato ad una cartella, l'attributo append permette la sola creazione di file.
Si vede bene come l'attributo "a" aumenti la sicurezza, permettendo
ai programmi non eseguiti dal superutente l'aggiunta di dati ad un file, senza
poterne modificare il contenuto preesistente. Invece, l'attributo
"i" sembra meno interessante: dopotutto, per limitare l'accesso a un
file, il superutente può già usare i permessi di base di Unix, mentre un
intruso che riesca ad assumere la qualità di superutente potrebbe sempre usare
il programma chattr
per rimuovere l'attributo: inizialmente
potrebbe confondersi, vista l'impossibilità di spostare un file, ma non si può
pensare che sia cieco - in fondo, è pur entrato nel sistema! Per aumentarne la
sicurezza, alcuni manuali (compresa una precedente versione di questo
documento) suggeriscono semplicemente di rimuovere dal sistema i programmi
chattr
e lsattr
, ma questo tipo di strategia, nota
come "sicurezza mediante oscurità" deve essere evitata in assoluto,
in quanto fornisce un falso senso di sicurezza.
Un modo sicuro di risolvere questo problema è usare una funzionalità del kernel Linux, chiamata CAP_LINUX_IMMUTABLE, come mostrato in Difesa proattiva, Sezione 9.3.2.1: eliminandola dalle serie delle limitazioni alle funzionalità (per esempio, col comando lcap CAP_LINUX_IMMUTABLE) non sarà più possibile, nemmeno al superutente, modificare qualunque attributo "a" o "i"! Un strategia completa potrebbe essere questa:
lcap
;
Ora che la funzionalità è stata tolta dal sistema, un intruso non può cambiare alcun attributo dei file protetti, né, quindi, modificarli o eliminarli. Se forza il riavvio della macchina (unico modo per ripristinare la serie di limitazioni alle funzionalità), sarà facilmente scoperto e comunque quella funzionalità sarà nuovamente rimossa appena il sistema si sarà riavviato. Il solo sistema di modificare un file protetto sarebbe inizializzare il sistema nel modo singolo-utente o usando una altro disco di avvio, due operazioni che richiedono un accesso fisico alla macchina!
Siete sicuri che /bin/login
sul disco fisso è ancora il binario
installato qualche mese fa? Cosa accadrebbe se fosse una versione modificata,
che registra le password inserite in un file nascosto o le spedisce in chiaro
per tutta Internet?
Il solo modo per avere qualche forma di protezione è controllare i file ogni
ora/giorno/mese (preferibile quotidianamente) confrontando gli md5sums attuali
di un file con quelli vecchi. Due file non possono avere lo stesso md5sums
(l'MD5 digest è 128 bits, quindi le possibilità che due diversi file abbiano lo
stesso md5sum sono approssimativamente una su 3.4e3803), perciò è il metodo più
sicuro, a meno che qualcuno non abbia modificato l'algoritmo che crea l'md5sums
sulla macchina che comunque è piuttosto complicato e improbabile. Bisogna
considerare la verifica di questi binari molto importante, poiché è un modo
semplice di riconoscere le modifiche ai binari. Strumenti comunemente
utilizzati a questo scopo sono sXid
, AIDE
(Advanced
Intrusion Detection Environment), TripWire
(non libero; la nuova
versione sarà GPL), integrit
e samhain
.
Installare debsums
può aiutare a controllare l'integrità del file
system, confrontando l'md5sums di ogni file con quello usato nell'archivio dei
pacchetti di Debian. Ma attenzione, questi file possono facilmente essere
modificati.
Inoltre si può sostituire locate
con slocate
.
Slocate è una versione avanzata per la sicurezza di GNU locate. Quando si usa
slocate, l'utente vede solo i file a cui ha realmente accesso e si può
escludere qualsiasi file o directory del sistema.
FIXME: inserire riferimenti alle immagini prese dopo l'installazione.
FIXME: aggiungere una nota relativa ai pacchetti che non forniscono debsums per tutte le applicazioni installate.
Debian fornisce un processo cron
che lavora quotidianamente in
/etc/cron.daily/standard
. Questo processo cron
lancerà lo script /usr/sbin/checksecurity
che registra le
informazioni su queste modifiche.
Per rendere possibili questi controlli bisogna impostare
CHECKSECURITY_DISABLE="FALSE" in
/etc/checksecurity.conf
. Nota: questa è l'impostazione
predefinita, quindi finché non si apportano modifiche, questa opzione sarà
impostata su "FALSE".
L'impostazione predefinita non invia questa informazione al super utente ma
conserva invece copie giornaliere delle modifiche in
/var/log/setuid.changes
. Dovreste impostare CHECKSECURITY_EMAIL
(in /etc/checksecurity.conf
) su "root" per spedirgli
questa informazione. Confrontate checksecurity(8)
per maggiori
dettagli sulla configurazione.
FIXME. Servono più contenuti (specifici per Debian)
FIXME: Contenuto mancante
Molte caratteristiche del kernel possono essere cambiate quando questo è in
esecuzione, effettuando un echo all'interno del filesystem /proc
o
usando sysctl
. Eseguendo /sbin/sysctl -A potete
vedere cosa è possibile configurare e quali sono le opzioni, è possibile
modificarlo eseguendo /sbin/sysctl -w variable=value (vedete
sysctl(8)
). Solo in rari casi è necessaria questa modifica ma
potete comunque incrementare la sicurezza in questo modo. Per esempio:
net/ipv4/icmp_echo_ignore_broadcasts = 1
Questo è un emulatore di Windows perché funziona come Windows in broadcast ping, se questa opzione è impostata ad 1. In pratica, le richieste ICMP_ECHO vengono ignorate. Altrimenti, non succede nulla.
Se desiderate bloccare tutte le richieste sul sistema, abilitate questa opzione di configurazione:
net/ipv4/icmp_echo_ignore_all = 0
Per loggare dei pacchetti destinati ad indirizzi inesistenti (errore dovuto ad instradamenti sbagliati) sulla propria rete, utilizzate:
/proc/sys/net/ipv4/conf/all/log_martians = 1
Per maggiori informazioni su ciò che può essere fatto con
/proc/sys/net/ipv4/*
leggete
/usr/src/linux/Documentation/filesystems/proc.txt
. Tutte le
opzioni sono descritte in maniera esauriente in
/usr/src/linux/Documentation/networking/ip-sysctl.txt
[13].
Questa opzione è un'arma a doppio taglio. Da un lato, protegge il sistema contro il syn flooding, dall'altro viola degli standard definiti (le RFC).
net/ipv4/tcp_syncookies = 1
Se desiderate cambiare questa opzione, ogni volta che il kernel è in esecuzione, allora dovrete modificare /etc/network/options impostando syncookies=yes. Questo cambiamento avrà l'effetto di eseguire ogni volta lo script contenuto in /etc/init.d/networking (come farlo al boot), mentre la seguente opzione avrà effetto solamente con il kernel in esecuzione.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Questa opzione è disponibile solamente se il kernel è stato compilato con l'opzione CONFIG_SYNCOOKIES. Tutti i kernel Debian sono compilati con questa opzione all'interno del kernel, potete verificarlo eseguendo:
$ sysctl -A |grep syncookies net/ipv4/tcp_syncookies = 1
Per maggiori informazioni sui syncookies TCP leggete http://cr.yp.to/syncookies.html
.
Quando impostate le opzioni del kernel relative al networking, dovete configurarle in maniera tale che siano caricate ogni volta che il sistema viene riavviato. L'esempio seguente abilita molte delle precedenti opzioni che avete visto, insieme ad altre utili opzioni.
Create lo script in /etc/network/interface-secure
(il nome è dato
a titolo di esempio) e chiamatelo da /etc/network/interfaces
, come
segue:
auto eth0 iface eth0 inet static address xxx.xxx.xxx.xxx netmask 255.255.255.xxx broadcast xxx.xxx.xxx.xxx gateway xxx.xxx.xxx.xxx pre-up /etc/network/interface-secure
# Script-name: /etc/network/interface-secure # Modifies some default behaviour in order to secure against # some TCP/IP spoofing & attacks # # Contributed by Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # broadcast echo protection enabled echo 0 > /proc/sys/net/ipv4/ip_forward # ip forwarding disabled echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log packets with impossible addresses # but be careful with this on heavy loaded web servers echo 1 > /proc/sys/net/ipv4/ip_always_defrag # defragging protection always enabled echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # bad error message protection enabled # now ip spoofing protection for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # and finally some more things: # Disable ICMP Redirect Acceptance for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Disable Source Routed Packets for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
È anche possibile creare uno script init.d e farlo eseguire
all'avvio del sistema (usando update-rc.d
per creare i
collegamenti rc.d appropriati).
Per avere un firewall, sia per proteggere il sistema locale o tutto quello che
si trova dietro, dovete compilare nel kernel le funzionalità del
firewall. Il kernel standard per Debian 2.2 (anch'esso 2.2) comprende il
packet filter ipchains
come firewall, in Debian 3.0 è presente
anche il kernel della serie 2.4 che è invece provvisto di stateful
packet filter, iptables
(netfilter) come firewall. Per le vecchie
distribuzioni di Debian bisogna procurarsi le appropriate patch per il kernel
(Debian 2.1 adotta il kernel 2.0.34).
In tutti i casi è vantaggioso e facile usare un kernel differente tra quelli
che Debian mette a disposizione. Potete cercare dei pacchetti che contengano
il kernel precompilato ed è semplice installarlo in un sistema Debian. Potete
anche scaricare i sorgenti del kernel usando kernel-source-X
e poi
realizzare un pacchetto usando make-kpkg
.
La configurazione del firewall sarà ampiamente trattata in Aggiungere funzionalità al firewall, Sezione 5.14.
I sistemi con più di un'interfaccia in differenti reti possono avere configurati servizi come se avessero solamente un indirizzo IP convenuto. Normalmente ciò previene il fatto che vengano richiesti dati servizi da un indirizzo prestabilito. Comunque, questo non è un trucco (sebbene sia un normale malinteso), il servizio si limita a delimitare l'indirizzo hardware (scheda ethernet). [14]
Questa non è un problema di ARP e altresì non è una violazione RFC (è chiamata
weak end host dalla RFC1122
, la trovate
nel paragrafo 3.3.4.2). Ricordate, gli indirizzi IP non hanno nulla da
spartire con le interfacce fisiche.
Nelle versione 2.2 del kernel ed anche nelle precedenti è possibile porre rimedio con:
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden .....
Nei kernel più recenti si può ottenere lo stesso con:
Nel corso di questo documento ci saranno occasioni per configurare molti servizi (server sshd, apache, servizi di stampa...) secondo l'ordine in cui si trovano, ascoltano ogni possibile indirizzo, il lettore può trovare l'account in questo momento, senza sistemare i servizi, le riparazioni non prevengono l'accesso al sistema dalla medesima rete. [17]
FIXME: i commenti tratti da bugtraq sono metodi specifici per proteggere un data interfaccia in Linux.
FIXME: sottoporre un bug nei confronti di netbase in modo che la riparazione della tabella di routing sia il comportamento standard per Debian?
Quando non c'è piena fiducia verso le altre postazioni sulla propria LAN (dovrebbe essere sempre così, è l'atteggiamento più sicuro), ci si dovrebbe proteggere dai diversi possibili attacchi di tipo ARP.
Il protocollo ARP è usato per collegare indirizzi IP a indirizzi MAC - per
tutti i dettagli vedere la RFC826
. Ogni volta che
si spedisce un pacchetto a un indirizzo IP si verifica una risoluzione ARP per
trovare l'indirizzo dell'hardware interessato (in primo luogo, consultando la
cache locale di ARP; poi, se l'IP non è presente nella cache, diffondendo
un'interrogazione ARP). Tutti gli attacchi ARP mirano a far credere ad una
postazione che il proprio indirizzo IP sia associato all'indirizzo MAC di
quello dell'intruso.
Quegli attacchi (Cache poisonning, ARP spoofing - avvelenamento di cache,
falsificazioni ARP) permettono all'attaccante di intercettare il traffico anche
su reti staccate, di dirottare facilmente delle connessioni, di disconnettere
un host qualunque dalla rete... Gli attacchi ARP sono potenti e semplici da
porre in esecuzione, essendovi parecchi strumenti: arpspoof (presente nel
pacchetto dsniff
), arpmim
,
arpoison
...
Tuttavia, una soluzione c'è sempre:
arp -s host_name hdwr_addr
Impostando voci statiche per ciascun host importante presente nella rete, ci si assicura che nessuno crei/modifichi per detti host una voce (falsa) - le voci statiche non hanno scadenza e non possono essere modificate -, cosicché le repliche ARP falsificate saranno ignorate.
arpwatch
, karpski
o un più generico IDS che possa
anche svolgere tale compito (introduzione a snort
, http://www.mandrakelinux.com/prelude
...).
Prima di mettere il sistema in produzione se ne può fotografare l'attuale stato: il risultato dell'operazione può tornare utile in caso di compromissione (vedete il Dopo la compromissione (reazione agli incidenti), Capitolo 10). Questo procedimento dovrebbe essere ripetuto ad ogni aggiornamento del sistema, specialmente se si aggiorna a una nuova versione Debian.
A tale scopo si può usare un medium scrivibile e rimovibile che possa essere impostato in sola lettura, come un floppy disk, se protetto da scrittura dopo l'uso, o un CD aperto da un unità CD-ROM - si può usare un CD riscrivibile, in modo da poter conservare copie di ripristino di tipo md5 (md5sums) create in date differenti.
Il seguente listato consente la fotografia del sistema:
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy /bin/cp /usr/bin/md5sum /mnt/floppy echo "Calculating md5 database" >/mnt/floppy/md5checksums.txt for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ do find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt done /bin/umout /dev/fd0 echo "post installation md5 database calculated"
Notate che il binario md5sum punta alla periferica del floppy, così da poterlo utilizzare, in seguito, per il controllo dei file binari del sistema (solo nel caso di un'infezione da virus di tipo trojan).
La fotografia non comprende i file della cartella
/var/lib/dpkg/info
, che racchiude le tabelle hash dei file md5,
riportanti (in file con estensione .md5sums
) l'elenco dei
pacchetti installati; si potrebbero copiare anche queste informazioni, ma
bisogna considerare che:
Una volta fatta la fotografia, accertatevi di impostare il medium in sola
lettura; a quel punto, si può accantonarlo per un futuro ripristino o inserirlo
nella periferica per un controllo periodico mediante cron
, che
confronti gli attuali file md5sum con quelli precedentemente
"fotografati".
SVGAlib è molto carina per gli amanti della console come me, ma è stato provato
diverse volte, in passato, che è molto insicura. Sono stati rilasciati exploit
contro zgv
ed era semplice utilizzarli per diventare root.
È meglio che evitiate di usare programmi che fanno uso della SVGAlib,
quando possibile.
Securing Debian Manual
2.96 14 febrero 2004Sabato, 30 Agosto 2003 18:27:45 +0200jfs@computer.org