[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ successivo ]

Securing Debian Manual
Capitolo 4 - Dopo l'installazione


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).


4.1 Modificare il BIOS (ancora)

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.


4.2 Impostazione della password in LILO o GRUB

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.


4.3 Rimuovere il prompt root nel kernel

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.


4.4 Disabilitare il boot da floppy

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.


4.5 Circoscrivere l'accesso alla console

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:

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

4.6 Circoscrivere la possibilità di riavviare da console

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.


4.7 Montare le partizioni nel modo giusto

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

4.7.1 Impostare /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)

4.7.2 Impostare /usr in sola lettura

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.


4.8 Eseguire un security update

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:

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

4.9 Iscrizione alla mailing list Debian security announce

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?


4.10 Fornire un accesso sicuro per gli utenti


4.10.1 Autenticazione degli utenti: PAM

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).


4.10.2 Limitare le risorse usate: il file 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:

È consigliabile configurare opportunamente il file limits.conf come sopra.


4.10.3 Procedura di autenticazione degli utenti: modificare /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.


4.10.4 Restrizioni ftp: modificare il file /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).


4.10.5 Utilizzo di su

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.


4.10.6 Utilizzo di sudo

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.


4.10.7 Non permettere accessi per amministrazione remota

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

4.10.8 Restrizioni agli utenti per l'accesso

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.


4.10.9 Verifica manuale degli utenti

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).


4.10.10 Esame completo degli utenti

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.


4.10.11 Uno sguardo ai profili utente

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.


4.10.12 Impostare delle umask per gli utenti

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.


4.10.13 Porre limiti a ciò a cui gli utenti possono accedere

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:

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.


4.10.13.1 Limitare l'accesso alle informazioni di altri utenti

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.


4.10.14 Generare password per gli 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.


4.10.15 Controllare le password degli utenti

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.


4.10.16 Disconnettere gli utenti inattivi

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:

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:

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.


4.11 Usare i tcpwrapper

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:

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.


4.12 L'importanza di log e avvisi

È 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.


4.12.1 Usare e personalizzare 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).


4.12.2 Configurare il file dove vengono spediti gli avvisi

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.


4.12.3 Usare un loghost

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.


4.12.4 Permessi dei file di log

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.


4.13 Includere le patch nel kernel

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:

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:


4.14 Protezione contro i buffer overflow

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:

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.


4.15 Trasferire file in sicurezza

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).


4.16 Limitazioni e controllo del File System


4.16.1 Usare le quote

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:

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).


4.16.2 Specifici attributi del filesystem ext2 (chattr/lsattr)

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:

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:

  1. Impostare gli attributi "a" ed "i" sui file desiderati;
  1. Aggiungere il comando lcap CAP_LINUX_IMMUTABLE (o anche, come in Difesa proattiva, Sezione 9.3.2.1, lcap CAP_SYS_MODULE) a uno degli script di avvio;
  1. Impostare l'attributo "i" su tale script e su altri file di avvio, o anche sullo stesso binario lcap;
  1. Eseguire manualmente detto comando (o riavviare il sistema, per assicurarsi che tutto funzioni a dovere).

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!


4.16.3 Controllare l'integrità del file system

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.


4.16.4 Impostare il controllo di setuid

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.


4.17 Rendere sicuro l'accesso alla rete

FIXME. Servono più contenuti (specifici per Debian)


4.17.1 Configurare le caratteristiche di rete del kernel

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].


4.17.1.1 Configurare Syncookies

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.


4.17.2 Rendere sicura la rete al momento del boot

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).


4.17.3 Configurare le caratteristiche di un firewall

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.


4.17.4 Disabilitare weak-end host

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?


4.17.5 Proteggersi dagli attacchi di tipo ARP

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:


4.18 Una fotografia del sistema

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".


4.19 Ulteriori raccomandazioni


4.19.1 Non usare software che dipende dalle librerie SVGA (svgalib)

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.


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ successivo ]

Securing Debian Manual

2.96 20 septiembre 2003Sabato, 30 Agosto 2003 18:27:45 +0200

Javier Fernández-Sanguino Peña jfs@computer.org
Per la traduzione si veda l'Appendice I