Manuale sulla sicurezza per Gentoo

Indice:

• Sicurezza del sistema
  Rendere le varie parti del sistema ancora più sicure.
  1. Considerazioni di pre-installazione
     Perchè la sicurezza è una parte importante per ogni amministratore di server?
  2. Tenere sotto controllo la sicurezza
     Tenere sotto controllo la sicurezza durante e dopo l'installazione.
  3. Logging
     Gentoo Linux offre la possibilità di scegliere tra 3 diversi logger.
  4. Montare le partizioni
     /etc/fstab fornisce molte opzioni per la sicurezza.
  5. Limitazioni per l'utente e per il gruppo
     Controllare l'uso delle risorse.
  6. Permessi per i file
     Rendere sicuri i file.
  7. PAM
     Pluggable Authentication Modules.
  8. TCP Wrappers
     Controllare l'accesso ai servizi.
  9. Sicurezza per il kernel
     Rendere sicuro il kernel.
  10. Sicurezza per i servizi
      Assicurarsi della sicurezza per i demoni.
  11. Il chroot e i server virtuali
      Isolare i server.
  12. Firewall
      Filtrare i pacchetti.
  13. Rilevare le intrusioni
      Rilevare gli intrusi.
  14. Aggiornare
      Assicurarsi di installare gli ultimi aggiornamenti per la sicurezza.

A. Sicurezza del sistema

1. Considerazioni di pre-installazione

1.a. Sicurezza fisica

Ogni opzione di sicurezza può essere facilmente scavalcata da un attaccante con l'accesso fisico al computer. Per questo, ci sono alcune misure da adottare per ottenere un buon grado di sicurezza. Mettere l'hardware in un posto sicuro evita all'attaccante di maneggiarlo e cambiare le impostazioni. E' una buona idea anche quella di tenere sicuro il proprio case, in modo da evitare che qualcuno possa estrarre l'hard disk. Per prevenire che un attaccante faccia il boot da un altro disco, evitando i permessi e le restrizioni del login, cercare di mettere nel BIOS l'hard disk come primo dispositivo di boot, e impostare una password per il BIOS. E' importante impostare una password di boot per LILO o GRUB, per prevenire che un utente pericoloso faccia il boot in single-mode e ottenga un accesso completo al sistema. Questo aspetto è trattato nel capitolo 3, in Impostare una password per GRUB e Impostare una password per LILO.

1.b. Pianificare il demone/servizio

Si parte con i servizi che la macchina dovrebbe eseguire. Questo aiuterà a fare un migliore schema di partizioni, e permetterà una migliore pianificazione delle misure di sicurezza. Non è necessario se il sistema ha una funzione di modalità singola, come un desktop, o se è un firewall. In questi casi non si dovrebbe eseguire nessun servizio, forse solo sshd.

Quello che segue può anche essere usato per supportare una amministrazione di sistema. Mantenendo un elenco di informazioni sulle versioni, sarà più facile tenere tutto aggiornato una volta scoperta una vulnerabilità remota in uno dei demoni.

1.c. Schemi di partizioni

Regole per le partizioni:

• Ogni directory in cui un utente dovrebbe potere scrivere (es /home, /tmp) dovrebbe essere su un partizione separata e dovrebbe usare alcune parti del disco. Si riduce il rischio che un utente possa riempire tutto il filesystem. Portage usa /var/tmp per compilare i file, così questa partizione dovrebbe essere grande.
• Ogni directory in cui si progetta l'installazione di software fuori della distribuzione, dovrebbe essere una partizione separata. Secondo il File Hierarchy Standard, questa è /opt o /usr/local. Se sono partizoni separate, non verranno cancellate se si deve reinstallare il sistema.
• Per una maggiore sicurezza, i dati statici possono essere messi in una partizione separata di sola lettura. Cercare di usare dispositivi di sola lettura come i CD-ROM per essere ancora più sicuri.

1.d. L'utente root

L'utente 'root' è quello più vitale sul sistema e non dovrebbe essere usato se non necessario. Se un attaccante ottiene l'accesso come root, l'unico modo di mantenere sicuro il sistema è quello di reinstallare.

Le regole d'oro per 'root'

• Creare sempre un utente per uso quotidiano e se questo utente ha bisogno dell'accesso come root, aggiungerlo al gruppo 'wheel'. E' così possibile per un utente normale di fare su per diventare root.
• Non usare mai X o altre applicazioni come root. root dovrebbe essere usato solo se necessario; se c'è una vulnerabilità in una applicazione che si esegue da utente, un attaccante può ottenere l'accesso come utente, ma se l'applicazione si esegue da root, l'attaccante ottiene l'accesso come root.
• Usare sempre i percorsi assoluti quando si è loggati come root (o usare sempre su -, che sostituisce le variabili di ambiente dell'utente con queste di root, e si assicura che il PATH di root include solo directory protette come /bin e /sbin). E' possibile ingannare root eseguendo una differente applicazione rispetto a quella che si vuole eseguire. Se il PATH di root è protetto o root usa solo path assoluti, si può esere sicuri che questo non succede.
• Se un utente deve eseguire solo pochi comandi da root, si può usare sudo. Attenzione a chi dare accesso e a che cosa.
• Non lasciare mai il terminale quando si è loggati come root.

Gentoo ha alcune protezioni di default per gli utenti normali che cercano di digitare su per diventare root. Le impostazioni di default di PAM richiedono che un utente sia un membro del gruppo "wheel" per poter digitare su e ottenere l'accesso da root.

1.e. Politiche di sicurezza

Ci sono molte ragioni per scrivere una politica di sicurezza per i sistemi o per le reti.

• Una buona politica di sicurezza permette di definire la sicurezza come un "sistema" e non come un insieme di diverse caratteristiche. Per esempio, senza una politica un amministratore potrebbe decidere di chiudere telnet, perchè trasmette password non criptate, ma lasciare l'accesso a FTP, che ha la stessa debolezza. Una buona politica di sicurezza permette di identificare quali misure sono utili e quali no.
• Per diagnosticare problemi, verificare il comportamento o rintracciare gli intrusi, potrebbe essere necessario intercettare il traffico di rete, ispezionare i login e i comandi degli utenti, guardare nelle directory home. Senza averlo specificato, e aver reso gli utenti consapevoli, queste azioni possono essere considerate illegali e possono mettere l'utente in pericolo dal punto di vista legale.
• Gli user account in mano ad altri sono una delle minacce più pericolose alla sicurezza del sistema. Senza spiegare agli utenti perchè è importante la sicurezza, e come metterla in pratica (come non scrivere password su post-it e metterli sulla scrivania), non si ha la speranza di avere user account sicuri.
• Sarà di supporto una disposizione di rete e di sistema ben documentata, così come sono di supporto gli ispettori quando si traccia una intrusione e si identifica la debolezza. Un banner sulla politica di sicurezza, che avverte che il proprio sistema è una rete privata e che tutti gli accessi non autorizzati sono vietati, potrà essere di aiuto quando si dovrà perseguire un intrusore, dopo averlo catturato.

La necessità di una buona politica di sicurezza è ora più chiara.

La politica stessa è un documento, o più documenti, che definisce le caratteristiche di rete e del sistema (quali servizi sono forniti), l'uso accettabile e quello proibito, le "migliori pratiche" di sicurezza e così via. Tutti gli utenti dovrebbero essere consapevoli della politica di sicurezza di una macchina, così come i cambiamenti che si fanno per mantenerla aggiornata. E' importante dedicare del tempo per aiutare gli utenti a capire la politica e perchè questa politica deve essere rispettata o cosa succede se si va contro essa. Questo dovrebbe essere ripetuto almeno una volta all'anno, poichè la politica può cambiare (ma anche come avviso all'utente di ricordare che esiste la politica).

Una politica di sicurezza dovrebbe contenere i seguente soggetti:

• Uso accettabile
  • Screen saver
  • Gestione password
  • Scaricare e installare software
  • Informazioni se gli utenti sono stati controllati
  • Uso di software anti virus
• Gestione di informazioni sensibili (ogni forma scritta, carta o digitale)
  • Pulire la scrivania e bloccare le informazioni classificate
  • Spegnere il pc prima di andarsene
  • Uso di crittografia
  • Gestione delle key da parte di colleghi sicuri
  • Gestione del materiale confidenziale quando si viaggia
• Gestione del computer quando si viaggia
  • Gestione del laptop durante i viaggi e dentro gli hotel

Differenti utenti possono richiedere differenti livelli o tipi di accesso, e la politica può variare per soddisfarli tutti.

La politica di sicurezza può diventare enorme, e informazioni vitali possono essere dimenticate. La politica dello staff IT può contenere informazioni confidenziali per gli utenti ordinari, così è meglio dividerla in politiche più piccole; es Politica di usi accettabili, Politica della password, Politica della email e Politica dell'accesso remoto.

Si trovano esempi di politiche in The SANS Security Policy Project. Se si ha una piccola rete e si pensa che queste politiche sono troppo grandi, si dovrebbe leggere Site Security Handbook.

2. Tenere sotto controllo la sicurezza

2.a. Flag USE

Il file make.conf contiene le flag USE definite dall'utente e /etc/make.profile/make.defaults contiene le flag USE di default per Gentoo Linux. Per lo scopo di questo manuale, le flag importanti sono pam (Pluggable Authentication Modules), tcpd (TCP wrappers), e ssl (Secure Socket Layer). Queste sono tutte nelle flag USE di default.

2.b. Proteggere la password di GRUB

GRUB supporta due modi differenti di aggiungere la protezione alla password. Il primo usa plain text, il secondo usa la crittografia md5+salt.

timeout 5
password changeme

Questo aggiunge la password changeme. Se nessuna password è digitata al boot, GRUB userà le impostazioni di boot di default.

Quando si aggiunge una password md5, si deve convertire la propria password nel formato cifrato, lo stesso usato in /etc/shadow. Per altre informazioni vedere man crypt. La password cifrata changeme, per esempio, può essere come questa: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

Si può crittografare la propria password direttamente nella shell di GRUB:

#/sbin/grub

GRUB version 0.92 (640K lower / 3072K upper memory)

   [ Minimal BASH-like line editing is supported. For the first word, TAB lists
     possible command completions. Anywhere else TAB lists the possible
     completions of a device/filename. ]

grub> md5crypt

Password: ********
(Digitare changeme al prompt)
Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

grub> quit

Tagliare e incollare la password in /boot/grub/grub.conf.

timeout 5
password --md5 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

I 5 secondi di timeout diventano utili se il sistema è remoto e si deve abilitare il riavvio senza una interazione con la tastiera. Altre informazioni su le password di GRUB sono nel comando info grub.

2.c. Proteggere la password di LILO

LILO supporta due modi di gestione delle password: il modo globale e quello per immagine, entrambi in testo.

La password globale è impostata all'inizio del file di configurazione, e applicata a ogni immagine di boot:

password=changeme
restricted
delay=3

La password per immagine è impostata nel seguente modo:

image=/boot/bzImage
      read-only
      password=changeme
      restricted

Se non si mette restricted, ogni volta c'è il prompt per la password.

Per immagazzinare le nuove informazioni in lilo.conf, si deve eseguire /sbin/lilo.

2.d. Restringere l'uso della console

Il file /etc/securetty permette di specificare su quale periferica tty (terminale), root ha il permesso di fare il login.

Si suggerisce di non commentare tutte le righe tranne vc/1 se si sta usando devfs e tutte le righe tranne tty1 se si sta usando udev. Questo assicura che solo il root può fare il login e solo su un terminale.

(Per devfs)
vc/1
(Per udev)
tty1

3. Logging

3.a. Introduzione

Si dovrebbe aggiungere un logging extra per catturare avvertimenti o errori che potrebbero indicare un attacco in corso o concluso con successo. Gli aggressori infatti spesso fanno dei controlli prima di attaccare.

È inoltre di vitale importanza che i file di log siano facilmente leggibili e gestibili. Gentoo Linux vi permette di scegliere tra 3 diversi loggers durante l'installazione.

3.b. Logging: Syslogd

Syslogd è il logger più comune per Linux e Unix in generale. Ha alcune funzioni di log rotation, ma usare /usr/sbin/logrotate in un cron job (logrotate è configurato in /etc/logrotate.conf) potrebbe rivelarsi più utile, visto che logrotate ha molte funzioni. Quanto spesso la log rotation dovrebbe essere eseguita, dipende dal carico del sistema.

Sotto si trova il file syslog.conf standard, con alcune funzioni aggiunte. Sono decommentate le righe cron e tty e si è aggiunto un logging server remoto. Per migliorare ulteriormente la sicurezza si può aggiungere il logging in due posti.

#  /etc/syslog.conf      Configuration file for syslogd.
#
#                       For more information see syslog.conf(5)
#                       manpage.
#                       This is from Debian, we are using it for now
#                       Daniel Robbins, 5/15/99

#
# First some standard logfiles.  Log by facility.
#

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          /var/log/mail.log
user.*                          -/var/log/user.log
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Logging for INN news system
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Some `catch-all' logfiles.
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Emergencies and alerts are sent to everybody logged in.
#
*.emerg                         *
*.=alert                        *

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

#Setup a remote logging server
*.*                        @logserver

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log

Gli aggressori probabilmente cercheranno di cancellare le loro tracce editando o cancellando i file di log. Si può rendere più difficile questa operazione salvando i log su uno o più server di logging remoti, su altre macchine. Per maggiori informazioni su syslogd eseguire man syslog.

3.c. Metalog

Metalog di Frank Dennis non è in grado di salvare i log su un server remoto, ma ha i suoi punti di forza nelle performance e nella flessibilità di logging. Può ordinare i log per nome del programma, urgenza e funzione (come syslogd), e utilizza espressioni regolari con le quali si possono lanciare script esterni quando vengono trovati specifici modelli. È molto buono per eseguire determinate azioni quando se ne presenta la necessità.

La configurazione standard di solito è sufficiente. Se si vuole essere avvertiti via email ogni volta che qualcuno sbaglia a digitare una password, usare uno dei seguenti script.

Per postfix:

#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root

Per netqmail:

#!/bin/sh
echo "To: root
Subject:Failure (Warning: $2)
$3
" | /var/qmail/bin/qmail-inject -f root

Ricordarsi di rendere eseguibile lo script eseguendo /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh

Poi decommentare la riga sotto "Password failures" in /etc/metalog/metalog.conf in questo modo:

command  = "/usr/local/sbin/mail_pwd_failures.sh"

3.d. Syslog-ng

Syslog-ng fornisce alcune delle funzioni di syslog e metalog, ma con una piccola differenza. Esso può filtrare i messaggi in base al livello e al contenuto (come metalog), e supporta il remote logging come syslog, gestisce i log di syslogd (anche i flussi da Solaris), scrive su TTY, esegue programmi, e può funzionare come logging server. In pratica, è il meglio di entrambi i logger con in più una configurazione avanzata.

Ecco un file di configurazione classico, leggermente modificato.

options {
        chain_hostnames(no);

        # The default action of syslog-ng is to log a STATS line
        # to the file every 10 minutes.  That's pretty ugly after a while.
        # Change it to every 12 hours so you get a nice daily update of
        # how many messages syslog-ng missed (0).
        stats_freq(43200);
};



source src {

    unix-stream("/dev/log" max-connections(256));

    internal();

};

source kernsrc { file("/proc/kmsg"); };

#define destinations
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };

# By default messages are logged to tty12...
destination console_all { file("/dev/tty12"); };

# ...if you intend to use /dev/console for programs like xconsole
# you can comment out the destination line above that references /dev/tty12
# and uncomment the line below.
#destination console_all { file("/dev/console"); };

#create filters
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { message("failed"); };
filter f_denied { message("denied"); };

#connect filter and destination
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

#default log
log { source(src); destination(console_all); };

Syslog-ng è molto facile da configurare, ma è anche molto facile dimenticarsi di qualcosa nel file di configurazione, dato che è molto grande. L'autore ancora promette alcune funzioni extra, come la criptazione, l'autenticazione, la compressione e il controllo MAC (Mandatory Access Control). Con queste opzioni sarà perfetto per il network logging, dato che l'aggressore non potrà spiare il log.

E syslog-ng ha un altro vantaggio: non ha bisogno di essere eseguito come root!

3.e. Analisi dei log con Logcheck

Certo, il solo tenere dei log non risolve i problemi. Una applicazione come Logcheck può rendere l'analisi regolare dei log molto più semplice. Logcheck è uno script, accompagnato da un binario chiamato logtail, che è eseguito dal demone cron e controlla i log in base a un set di regole, alla ricerca di attività sospette. Poi invia l'output alla casella di posta dell'utente root.

Logcheck e logtail fanno parte del pacchetto app-admin/logsentry.

Logcheck utilizza quattro file per filtrare le voci importanti dei log da quelle non importanti. Questi file sono logcheck.hacking, che contiene messaggi conosciuti di attacchi di hackers, logcheck.violations, che contiene modelli indicanti violazioni della sicurezza, logcheck.violations.ignore, che contiene parole chiave che dovrebbero ritrovarsi nel file delle violazioni, consentendo alle voci normali di essere ignorate, e logcheck.ignore, che contiene le voci da ignorare.

4. Montare le partizioni

4.a. Montare partizioni

Quando si monta una partizione ext2, ext3, o reiserfs, si hanno diverse opzioni che si possono applicare nel file /etc/fstab. Le opzioni sono:

• nosuid - Ignora il SUID bit e lo rende proprio come un file ordinario
• noexec - Impedisce l'esecuzione di file da questa partizione
• nodev - Ignora i dispositivi

Sfortunatamente queste impostazioni possono essere facilmente eluse eseguendo un percorso non diretto. Tuttavia, impostare /tmp a noexec bloccherà la maggior parte degli exploit progettati per essere eseguiti direttamente da /tmp.

/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp reiserfs notail,noatime,nodev,nosuid,noexec 0 0
/dev/sda5 /var reiserfs notail,noatime,nodev 0 0
/dev/sda6 /home reiserfs notail,noatime,nodev,nosuid 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0

5. Limitazioni per l'utente e per il gruppo

5.a. /etc/security/limits.conf

Controllare l'utilizzo delle risorse può essere molto utile quando si cerca di prevenire un Denial of Service locale o di limitare il numero massimo dei login consentiti per un gruppo o per un utente. Tuttavia, delle impostazioni troppo restrittive influirebbero negativamente sul comportamento del sistema, causando l'impossibilità di avviare taluni programmi, quindi assicurarsi di controllare accuratamente ogni impostazione.

*    soft core 0
*    hard core 0
*    hard nproc 15
*    hard rss 10000
*    -    maxlogins 2
@dev hard core 100000
@dev soft nproc 20
@dev hard nproc 35
@dev -    maxlogins 10

Se si vuole impostare nproc o maxlogins a 0, forse è meglio cancellare l'utente. L'esempio sopra imposta le opzioni dev del gruppo per i processi, il core file e maxlogins. Il resto è lasciato ai valori predefiniti.

5.b. /etc/limits

/etc/limits è molto simile al file dei limiti /etc/security/limits.conf. L'unica differenza sta nel formato e nel fatto che il primo funziona soltanto per gli utenti e per le wild cards (non per i gruppi). Si da un'occhiata a un esempio di configurazione:

*   L2 C0 U15 R10000
kn L10 C100000 U35

Qui si utilizzano le impostazioni predefinite e una impostazione specifica per l'utente kn. I limiti sono parte del pacchetto sys-apps/shadow. Non è necessario impostare alcun limite in questo file se è stato abilitata la USE pam in make.conf.

5.c. Quote

Mettere le quote ad un filesystem restringe l'uso del disco ad un singolo utente o gruppo. Le quote vengono abilitate nel kernel e sono aggiunte ad un punto di mount in /etc/fstab. L'opzione del kernel va attivata nella sezione File systems->Quota support. Applicare le impostazioni seguenti, ricompilare il kernel e riavviare usando il nuovo kernel.

Iniziare installando le quote con emerge quota. Poi modificare /etc/fstab aggiungendo usrquota e grpquota alle partizioni di cui si vuole restringere l'uso, come nell'esempio qui sotto.

/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp ext3 noatime,nodev,nosuid,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv=1 0 0
/dev/sda5 /var ext3 noatime,nodev,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda6 /home ext3 noatime,nodev,nosuid,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0

Su ogni partizione per cui si ha abilitato le quote, creare i file quota (aquota.user e aquota.group) e salvarli nella radice della partizione.

# touch /tmp/aquota.user
# touch /tmp/aquota.group
# chmod 600 /tmp/aquota.user
# chmod 600 /tmp/aquota.group

Questa operazione deve essere eseguita su ogni partizione per cui sono state attivate le quote. Dopo aver aggiunto e configurato i file quota, si deve aggiungere lo script quota al runlevel di boot.

# rc-update add quota boot

Il kernel Linux tiene traccia dell'uso delle quote mentre il sistema lavora. Se per qualche ragione il file quota si rovina o si ritiene che i dati non siano corretti, bisogna portare il sistema in modalità single-user (o almeno assicurarsi non si verifichino scrutture nel file system) ed esemguire quotacheck -avugm.

0 3 * * 0 /usr/sbin/quotacheck -avug.

Dopo aver riavviato la macchina, è il momento di configurare le quote per gli utenti e per i gruppi. edquota -u kn avvierà l'editor definito in $EDITOR (l'impostazione predefinita è nano), consentendo di modificare le quote dell'utente kn. edquota -g farà la stessa cosa per i gruppi.

Quotas for user kn:
/dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500)
         inodes in use: 356, limits (soft = 1000, hard = 1500)

Per maggiori dettagli leggere man edquota o il Quota mini howto.

5.d. /etc/login.defs

Se la propria politica di sicurezza prevede che gli utenti debbano cambiare la propria password ogni due settimane, cambiare il valore PASS_MAX_DAYS a 14 e PASS_WARN_AGE a 7. È consigliato utilizzare il password aging, dato che i metodi di forza bruta possono scoprire qualunque password, se hanno abbastanza tempo. Si raccomanda inoltre di impostare LOG_OK_LOGINS a yes.

5.e. /etc/security/access.conf

Anche il file access.conf è parte del pacchetto sys-libs/pam, che fornisce una tabella di controllo dei login. Questa tabella è usata per controllare chi può loggarsi e chi no, basandosi sul nome dell'utente, del gruppo o dell'host. Come impostazione predefinita a tutti gli utenti del sistema è consentito effettuare il login, quindi il file contiene solo commenti ed esempi. Sia che si stia mettendo in sicurezza un server oppure una workstation, si raccomanda di configurare questo file, cosicché nessun altro tranne il proprietario (l'amministratore) abbia accesso alla console.

-:ALL EXCEPT wheel sync:console
-:wheel:ALL EXCEPT LOCAL .gentoo.org

Questo configurerà gli accessi in modo che i membri del gruppo wheel possano loggarsi localmente o dal dominio gentoo.org. Forse è troppo paranoico, ma è meglio essere sicuri che dispiaciuti.

6. Permessi per i file

6.a. File leggibili da tutti

Gli utenti normali non dovrebbero avere accesso ai file di configurazione e alle password. Un aggressore può rubare le password da un database o da un sito web, utilizzandole poi per danneggiare, o ancora peggio per distruggere, dei dati. Ecco perché è importante che i permessi sui file siano impostati correttamente. Se si è sicuri che un file è utilizzato solo da root, assegnargli i permessi 0600 e assegnare il file al giusto utente con chown.

6.b. File scrivibili da tutti o da un gruppo

# find / -type f \( -perm -2 -o -perm -20 \) \ -exec ls -lg {} \; 2>/dev/null
>writable.txt
# find / -type d \( -perm -2 -o -perm -20 \) \ -exec ls -ldg {} \;2>/dev/null
>>writable.txt

Questi comandi creeranno un lungo file con i permessi di tutti i file aventi il permesso di scrittura impostato per un gruppo o per tutti. Controllare i permessi ed eliminare i file scrivibili da tutti, eseguendo il comando /bin/chmod o-w sui file in questione.

6.c. Files SUID/SGID

I file con il bit SUID o SGID impostato vengono eseguiti con i privilegi dell'utente proprietario o del suo gruppo, e non con quelli dell'utente che esegue il file. Normalmente questi bit vengono usati sui file che devono essere eseguiti come root per poter fare ciò per cui vengono eseguiti. Questi file possono compromettere la radice locale (se contengono buchi nella sicurezza). Ciò è pericoloso, e per questo i file con bit SUID o SGID impostati dovrebbero essere evitati ad ogni costo. Se non si usano questi file, usare chmod 0 su di essi o eseguire l'unmerge del pacchetto da cui essi provengono (controllare a quale pacchetto appartengono usando equery; se non lo si ha già installato digitare emerge gentoolkit). Altrimenti disattivare semplicemente il bit SUID con chmod -s.

# find / -type f \( -perm -004000 -o -perm -002000 \) \ -exec ls -lg {} \;2>/dev/null
>suidfiles.txt

Questo comando creerà un file contenente una lista di tutti i file SUID/SGID.

/bin/su
/bin/ping
/bin/mount
/bin/umount
/var/qmail/bin/qmail-queue
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/crontab
/usr/bin/chage
/usr/bin/expiry
/usr/bin/sperl5.6.1
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/procmail
/usr/bin/suidperl
/usr/lib/misc/pt_chown
/usr/sbin/unix_chkpwd
/usr/sbin/traceroute
/usr/sbin/pwdb_chkpwd

Come impostazione predefinita Gentoo Linux non ha molti file SUID (sebbene questo dipenda da che cosa si ha installato), è comunque possibile ottenere una lista come quella sopraelencata. La maggior parte dei comandi non dovrebbero essere eseguiti da utenti normali, ma solo da root. Togliere il SUID bit da ping, mount, umount, chfn, chsh, newgrp, suidperl, pt_chown e traceroute, eseguendo chmod -s su ogni file. Non rimuovere il bit da su, qmail-queue o unix_chkpwd. Rimuovere setuid da questi file impedirà di eseguire su e di ricevere la posta. Rimuovendo il bit (dove è sicuro farlo) si rimuove la possibilità che un utente normale (o un aggressore) conquisti i privilegi di root attraverso uno di questi file.

Gli unici file SUID che si hanno sul sistema di esempio sono su, passwd, gpasswd, qmail-queue, unix_chkpwd e pwdb_chkpwd. Tuttavia, se si sta eseguendo X se ne potrebbero trovare anche altri, dato che X ha bisogno dell'accesso elevato reso possibile da SUID.

6.d. Binari SUID/SGID e hard link

Un file è considerato cancellato solo quando non ci sono più link che puntano ad esso. Questo potrebbe sembrare strano, ma si consideri che un filename come /usr/bin/perl è in realtà un collegamento all'inode dove i dati sono memorizzati. Un numero potenzialmente infinito di link può puntare al file, e finché tutti questi non sono spariti, il file continua ad esistere.

Se gli utenti hanno accesso a una partizione che non è montata con nosuid o noexec (per esempio, se /tmp, /home, o /var/tmp non sono su partizioni separate) assicurarsi che gli utenti non creino hard links a binari SUID o SGID, altrimenti dopo gli aggiornamenti di Portage essi avranno ancora accesso alle vecchie versioni dei programmi.

Per verificare quanti link ha un file, si usa il comando stat.

$ stat /bin/su    
  File: `/bin/su'
  Size: 29350           Blocks: 64         IO Block: 131072 regular file
Device: 900h/2304d      Inode: 2057419     Links: 1
Access: (4711/-rws--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2005-02-07 01:59:35.000000000 +0000
Modify: 2004-11-04 01:46:17.000000000 +0000
Change: 2004-11-04 01:46:17.000000000 +0000

Per trovare i file SUID e SGID con collegamenti multipli, si usa find.

$ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls

7. PAM

7.a. PAM

PAM è una serie di librerie condivise che forniscono una via alternativa per l'autenticazione dell'utente nei programmi. La flag USE pam è attivata in modo predefinito. Le impostazioni PAM su Gentoo Linux sono abbastanza ragionevoli, ma c'è sempre la possibilità di migliorare. Per prima cosa installare cracklib.

# emerge cracklib

auth     required pam_unix.so shadow nullok
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=-2 ocredit=-2 
password required pam_unix.so md5 use_authtok
session  required pam_unix.so

Questo aggiungerà cracklib, il quale assicurerà che le password degli utenti siano lunghe almeno 8 caratteri, contengano un minimo di 2 cifre e 2 altri caratteri, e che differiscano dall'ultima password per più di 3 caratteri. Questo costringe l'utente a scegliere una buona password (politica delle password). Consultare la documentazione PAM per ulteriori opzioni.

auth     required pam_unix.so nullok 
auth     required pam_shells.so
auth     required pam_nologin.so
auth     required pam_env.so
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=-2 ocredit=-2
use_authtok
password required pam_unix.so shadow md5
session  required pam_unix.so
session  required pam_limits.so

Ogni servizio non configurato con un file PAM in /etc/pam.d userà le regole in /etc/pam.d/other. I valori predefiniti sono impostati a deny, come dovrebbero essere. Ma in questo esempio si desidera avere molti log, e per questo si è aggiunto pam_warn.so. L'ultima opzione è pam_limits, che è controllata da /etc/security/limits.conf. Consultare la sezione /etc/security/limits.conf per maggiori dettagli su queste impostazioni.

auth     required pam_deny.so 
auth     required pam_warn.so 
account  required pam_deny.so 
account  required pam_warn.so 
password required pam_deny.so 
password required pam_warn.so 
session  required pam_deny.so 
session  required pam_warn.so

8. TCP Wrappers

8.a. TCP Wrapper

E' un modo di controllare l'accesso ai servizi eseguiti da inetd (che Gentoo non ha), ma può anche essere usato da xinetd e altri servizi.

ALL:PARANOID

ALL: LOCAL @wheel
time: LOCAL, .gentoo.org

Come si può vedere il formato è molto simile a quello in /etc/security/access.conf. Tcpd supporta un servizio specifico; non ha funzionalità in comune con /etc/security/access.conf. Queste impostazioni si applicano solo ai servizi con tcp wrapper.

E' anche possibile eseguire comandi quando si accede a un servizio (quando si attiva il rinvio delle chiamate entranti per gli utenti con modem) ma non è raccomandato, poichè le persone tendono a creare più problemi di quanti se ne provano a risolvere. Un esempio potrebbe essere quello di una configurazione di uno script per mandare e-mail ogni volta che qualcuno incontra un accesso negato, ma così un attaccante può lanciare un attacco DoS. Si creeranno molti I/O e e-mail e quindi non farlo. Leggere man 5 hosts_access per altre informazioni.

9. Sicurezza per il kernel

9.a. Rimuovere funzionalità

La regola base, quando si configura il kernel, è quella di rimuovere tutto ciò di cui non si ha bisogno. Questo non solo per rendere il kernel leggero, ma anche per rimuovere le vulnerabilità che potrebbero insinuarsi all'interno dei driver e delle altre funzionalità.

Considerare anche di disattivare il "loadable modules support". Sebbene sia possibile installare rootkit anche senza questa funzionalità, diventa sicuramente più difficile per un aggressore di capacità medie installare rootkit attraverso i moduli del kernel.

9.b. Il filesystem proc

Molti parametri del kernel possono essere alterati attraverso il filesystem /proc, oppure usando sysctl.

Per modificare al volo parametri del kernel e variabili, è necessario che CONFIG_SYSCTL sia definito nel kernel. Lo è in modo predefinito in un kernel 2.4 standard.

# /bin/echo "0" > /proc/sys/net/ipv4/ip_forward

Assicurarsi che l'IP forwarding sia disattivato. Questa funzione serve solo per un nodo avente più connessioni di rete. Si raccomanda di attivare o disattivare questa flag prima di tutte le altre, in quanto essa attiva/disattiva altre flag.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

Questo farà sì che il kernel ignori semplicemente tutti i messaggi di ping (conosciuti anche come messaggi ICMP di tipo 0). Il motivo è che un pacchetto IP che trasporta un messaggio ICMP può contenere informazioni diverse da quelle che ci si aspetta. Gli amministratori usano ping come strumento diagnostico e spesso si lamentano se esso è disattivato, ma non c'è ragione per permette ad una persona esterna di effettuare i ping sulla propria macchina. Tuttavia, poiché a volte può essere comodo per gli addetti avere la possibilità di effettuare i ping, si disattivano i messaggi ICMP di tipo 0 nel firewall (permettendo agli amministratori locali di continuare a usare questo strumento).

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Questo disattiva la risposta ai broadcast ICMP, prevenendo gli attacchi Smurf. L'attacco Smurf consiste nell'invio di un messaggio ICMP di tipo 0 (ping) all'indirizzo broadcast di una rete. Di solito l'aggressore utilizza un indirizzo sorgente contraffatto. Tutti i computer della rete risponderanno al messaggio ping, intasando l'host all'indirizzo sorgente contraffatto.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

Non accettare pacchetti da fonte instradata. Gli aggressori possono usare l'instradamento delle fonti per generare traffico che sembra avere origine all'interno della rete, ma che in realtà viene instradato all'indietro lungo il percorso da cui è venuto, cosicché gli aggressori possono compromettere la rete. L'instradamento delle fonti è usato raramente per scopi benevoli, quindi è meglio disattivarlo.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Non accettare pacchetti ICMP rediretti. Le redirezioni ICMP possono essere usate per alterare le tabelle di instradamento, con conseguenze potenzialmente negative.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Attivare la protezione contro le risposte a falsi messaggi di errore.

# for i in /proc/sys/net/ipv4/conf/*; do
        /bin/echo "1" > $i/rp_filter
done

Attivare il reverse filtering del percorso. Questo aiuta ad essere sicuri che i pacchetti utilizzino indirizzi sorgente regolari, rifiutando automaticamente i pacchetti in arrivo se la voce nella tabella di instradamento che indica il loro indirizzo sorgente non corrisponde all'interfaccia di rete su cui stanno essi arrivando. Questo è vantaggioso per la sicurezza in quanto impedisce l'IP spoofing. Si deve attivarlo per ogni net/ipv4/conf/*, altrimenti l'autenticazione delle fonti non sarà pienamente funzionante.

# /bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

Fare il log dei pacchetti contraffatti, dei pacchetti da fonte instradata e dei pacchetti rediretti.

Tutte queste impostazioni saranno resettate al riavvio della macchina. Si suggerisce di aggiungerle a /etc/sysctl.conf, che viene letto automaticamente dallo script di init /etc/init.d/bootmisc.

La sintassi di /etc/sysctl.conf è abbastanza semplice. Togliere /proc/sys/ dai percorsi sopra menzionati e sostituire / con .:

(Manualmente usando echo):
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward

(Automaticamente in sysctl.conf:)
net.ipv4.ip_forward = 0

9.c. Grsecurity

La patch di Grsecurity è presente in modo standard nel kernel sys-kernel/hardened-sources, ma è disattivata in modo predefinito. Configurare il kernel normalmente, e poi configurare le opzioni Grsecurity. Una spiegazione delle opzioni Grsecurity disponibili si trova nella pagina del progetto Gentoo Hardened.

Le versioni recenti di hardened-sources forniscono la versione 2.* di Grsecurity. Per maggiori informazioni su questo insieme migliorato di patch Grsecurity, consultare la documentazione disponibile sulla home page di Grsecurity.

9.d. Kerneli

Kerneli è una patch che aggiunge la criptazione al kernel. Applicando la patch al kernel si hanno nuove opzioni, come "cryptographic ciphers", "digest algorithms" e "cryptographic loop filters".

9.e. Altre patch per il kernel

• The OpenWall Project
• Linux Intrusion Detection System
• Rule Set Based Access Control
• NSA's security enhanced kernel
• Wolk

E probabilmente ce ne sono molte altre.

10. Sicurezza per i servizi

10.a. Apache

Apache ha un buon file di configurazione, ma si devono migliorare alcune cose, come legare Apache a un indirizzo e prevenire l'uscita di informazioni. Sotto ci sono le opzioni che si dovrebbero applicare al file di configurazione.

Se non si è disabilitato ssl nel /etc/make.conf quando è stato installato Apache, si dovrebbe avere l'accesso a un server abilitato ssl. All'interno di /etc/apache2/vhosts.d si possono trovare dei file di configurazione d'esempio. Ci sono degli esempi funzionanti ed è sicuramente meglio verificare quelli o disabilitarli.

È importante definire la/le propria/e configurazione/i in modo che ascolti(no) su un particolare indirizzo IP (piuttosto che su tutti gli indirizzi IP disponibili sul proprio sistema). Per esempio, per il file 00_default_vhost.conf:

#Fare in modo che ascolti sul proprio ip
Listen 127.0.0.1

Si raccomanda inoltre di disabilitare la visualizzazione al mondo intero di qualsiasi informazione riguardante la propria installazione di Apache. Come impostazione predefinita, la configurazione aggiungerà la versione del server ed il nome dell'host virtuale alle pagine generate lato server. Per disabilitare questo comportamento, cambiare la variabile ServerSignature in Off:

ServerSignature Off

Apache è compilato con --enable-shared=max e --enable-module=all. Ciò abilita in modo predefinito tutti i moduli, pertanto si dovrebbero commentare, nel file di configurazioe principale /etc/apache2/httpd.conf, tutti i moduli nella sezione LoadModule (LoadModule e AddModule) che non si usano. Riavviare il servizio con /etc/init.d/apache2 restart.

La documentazione è disponibile nel sito http://www.apache.org.

10.b. Bind

Si può trovare la documentazione in Internet Software Consortium. Il BIND 9 Administrator Reference Manual è anche in doc/arm.

I nuovi ebuild BIND supportano il chroot fuori dalla macchina. Emergere bind e seguire queste istruzioni:

# emerge --config bind
(Prima di eseguire il comando sopra, si potrebbe volere cambiare la
directory del chroot in /etc/conf.d/named. Altrimenti sarà usato /chroot/dns.)

10.c. Djbdns

Djbdns è una implementazione DNS sulla sicurezza il cui autore sta scommettendo soldi. Funziona in modo molto differente rispetto a Bind 9, ma vale la pena provarlo. Sono disponibili altre informazioni sul sito http://www.djbdns.org.

10.d. FTP

Generalmente, usare FTP (File Transfer Protocol) è una cattiva idea. Usa dati non criptati (es. le password sono trasmesse in chiaro), resta in ascolto su 2 porte (20 e 21), e gli attaccanti cercano login anonimi per scambiare warez. Poichè il protocollo FTP contiene molti problemi di sicurezza, si dovrebbe usare sftp o HTTP. Se questo non è possibile, rendere sicuri i servizi il più possibile e prepararsi ad eventuali problemi con la sicurezza.

10.e. Mysql

Se si ha bisogno solo di applicazioni locali per accedere al database mysql, non commentare le seguenti righe in /etc/mysql/my.cnf.

skip-networking

Disabilitare l'uso del comando LOAD DATA LOCAL INFILE. Serve per prevenire letture non autorizzate da file locali. È rilevante quando sono trovate nuove vulnerabilità SQL Injection nelle applicazioni PHP.

set-variable=local-infile=0

Si deve rimuovere il database di esempio (test) e tutti gli account tranne il root locale.

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host="localhost" and user="root");
mysql> flush privileges;

10.f. Proftpd

Proftpd ha avuto molti problemi di sicurezza, ma la maggior parte di questi sembra sia stata riparata. È una buona idea applicare alcuni miglioramenti:

ServerName "My ftp daemon"
#Don't show the ident of the server
ServerIdent on "Go away"

#Makes it easier to create virtual users
RequireValidShell off

#Use alternative password and group file (passwd uses crypt format)
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Permissions
Umask 077

# Timeouts and limitations
MaxInstances 30
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

#Chroot everyone
DefaultRoot ~

#don't run as root
User  nobody
Group nogroup

#Log every transfer
TransferLog /var/log/transferlog

#Problems with globbing
DenyFilter \*.*/

Si può trovare la documentazione in http://www.proftpd.org.

10.g. Pure-ftpd

Pure-ftpd è una parte di trollftpd, modificato per ragioni di sicurezza e per funzionalità da Frank Dennis.

Usare utenti virtuali (mai account di sistema) abilitando l'opzione AUTH. Impostare questa a -lpuredb:/etc/pureftpd.pdb e creare gli utenti con /usr/bin/pure-pw.

AUTH="-lpuredb:/etc/pureftpd.pdb"

## Misc. Others ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"

Configurare MISC_OTHER per non permettere login anonimi (-E), chroot per ognuno (-A), prevenire che utenti leggano o scrivano su file che iniziano con un . (punto) (-X), massimo tempo di occupazione (-I), ricorrenza di limite (-L), e ragionevole umask.

Si può trovare la documentazione in http://www.pureftpd.org.

10.h. Vsftpd

Vsftpd (very secure ftp) è un piccolo demone che esegue una configurazione predefinita. È semplice e non ha molte caratteristiche come pureftp e proftp.

anonymous_enable=NO
local_enable=YES

#read only
write_enable=NO

#enable logging of transfers
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO

Come si può vedere, non c'è un modo per questo servizio di avere permessi individuali, ma le impostazioni anonime sono buone. A volte può essere utile avere un ftp server anonimo (per condividere open source), e vsftpd va bene.

10.i. Netqmail

Netqmail è spesso considerato un mail server molto sicuro. È scritto tenendo in mente la sicurezza. Non permette come impostazione predefinita la trasmissione e non ha avuto un problema di sicurezza dal 1996. Dare un emerge netqmail e proseguire con la configurazione.

10.j. Samba

Samba è un protocollo per condividere file con le reti Microsoft/Novell e non dovrebbe essere usato in Internet. Ha bisogno di alcune opzioni di sicurezza.

[global]
  #Bind to an interface
  interfaces = eth0 10.0.0.1/32

  #Make sure to use encrypted password
  encrypt passwords = yes
  directory security mask = 0700

  #allow traffic from 10.0.0.*
  hosts allow = 10.0.0.

  #Enables user authentication
  #(don't use the share mode)
  security = user

  #Disallow privileged accounts
  invalid users = root @wheel

  #Maximum size smb shows for a share (not a limit)
  max disk size = 102400

  #Uphold the password policy
  min password length = 8
  null passwords = no

  #Use PAM (if added support)
  obey pam restrictions = yes
  pam password change = yes

Assicurarsi che i permessi siano corretti su ogni condivisione e ricordarsi di leggere la documentazione.

Riavviare il server e aggiungere gli utenti che dovrebbero aver accesso a questo servizio. Ciò viene fatto tramite il comando /usr/bin/smbpasswd ed il parametro -a.

10.k. ssh

La sola sicurezza di cui OpenSSH ha bisogno è avere una autenticazione forte basata sulla crittografia a chiave pubblica. Troppi siti (come http://www.sourceforge.net, http://www.php.net e http://www.apache.org) hanno sofferto di intrusioni non autorizzate dovute a perdite di (o cattive) password.

#Only enable version 2
Protocol 2

#Disable root login. Users have to su to root
PermitRootLogin no

#Turn on Public key authentication
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#Disable .rhost and normal password authentication
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

#Only allow userin the wheel or admin group to login
AllowGroups wheel admin

#In those groups only allow the following users
#The @<domainname> is optional but replaces the
#older AllowHosts directive
AllowUsers kn@gentoo.org bs@gentoo.org

#Logging
SyslogFacility AUTH
LogLevel INFO

(Cambiare questo con il proprio indirizzo)
ListenAddress 127.0.0.1

Verificare inoltre di non avere UsePAM yes nel file di configurazione poichè esclude il meccanismo di autenticazione delle chiavi pubbliche, oppure disabilitare una delle due voci PasswordAuthentication o ChallengeResponseAuthentication. Si possono trovare maggiori informazioni riguardo a queste opzioni nella pagina di manuale di sshd_config.

Tutti gli utenti devono creare una chiave (sulla macchina in cui vogliono loggarsi) con il seguente comando:

# /usr/bin/ssh-keygen -t dsa

E digitare la pass phrase.

Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Press enter]
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): [Enter passphrase]
Enter same passphrase again: [Enter passphrase again]
Your identification has been saved in /home/kn/.ssh/id_dsa.
Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
The key fingerprint is:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen

Questo aggiungerà due file nella directory ~/.ssh/, chiamati id_dsa e id_dsa.pub. Il file id_dsa è la chiave privata e non dovrebbe essere vista da altri utenti. Il file id_dsa.pub va distribuito a ogni server in cui si ha accesso. Aggiungere la chiave nella directory home dell'utente in ~/.ssh/authorized_keys e l'utente dovrebbe poter loggarsi:

$ scp id_dsa.pub other-host:/var/tmp/currenthostname.pub
$ ssh other-host
password:
$ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys

Gli utenti dovrebbero proteggere la chiave privata. Metterla in un dispositivo che si porta sempre con sè o tenerla nella workstation (mettere questo nella politica delle password).

Per altre informazioni andare nel sito web OpenSSH.

10.l. Usare xinetd

xinetd è un rifacimento di inetd (che Gentoo non ha), il demone di servizi Internet. Supporta controllo di accesso basato sull'indirizzo dell'host remoto e il tempo di accesso. Fornisce varie possibilità di login, incluso il tempo di avvio del server, indirizzo dell'host remoto, il nome dell'utente remoto, il tempo di esecuzione del server, e azioni richieste.

Come per tutti gli altri servizi è importante avere una buona configurazione predefinita. Poichè xinetd è eseguito da root e supporta protocolli di cui si potrebbe non conoscere il funzionamento, si raccomanda di non usarlo. Ma se comunque lo si volesse provare, ecco alcune opzioni di sicurezza:

# emerge xinetd tcp-wrappers

Modificare il file di configurazione:

defaults
{
 only_from = localhost
 instances = 10
 log_type = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps = 25 30
}

# This will setup pserver (cvs) via xinetd with the following settings:
# max 10 instances (10 connections at a time)
# limit the pserver to tcp only
# use the user cvs to run this service
# bind the interfaces to only 1 ip
# allow access from 10.0.0.*
# limit the time developers can use cvs from 8am to 5pm
# use tpcd wrappers (access control controlled in
# /etc/hosts.allow and /etc/hosts.deny)
# max_load on the machine set to 1.0
# The disable flag is per default set to no but I like having
# it in case of it should be disabled
service cvspserver
{
 socket_type = stream
 protocol = tcp
 instances = 10
 protocol = tcp
 wait = no
 user = cvs
 bind = 10.0.0.2
 only_from = 10.0.0.0
 access_times = 8:00-17:00
 server = /usr/sbin/tcpd
 server_args = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
 max_load = 1.0
 log_on_failure += RECORD
 disable = no
}

Per altre informazioni leggere man 5 xinetd.conf.

10.m. X

Come impostazione predefinita Xorg è configurato per essere un Xserver. Può essere pericoloso poichè X usa connessioni TCP non criptate e resta all'ascolto di xclient.

Ma se si usa la workstation come Xserver, usare il comando /usr/X11R6/bin/xhost con cautela. Questo comando permette ai client di altri host di connettersi e di usare il proprio display. Può essere di aiuto se si fa uso di un'applicazione X da una macchina differente e il solo modo è usare la rete, ma può anche essere sfruttato da un attaccante. La sintassi di questo comando è /usr/X11R6/bin/xhost +hostname

Una soluzione più sicura è disabilitare questa caratteristica avviando X con startx -- -nolisten tcp o disabilitarla nella configurazione.

defaultserverargs="-nolisten tcp"

Per assicurarsi che startx non sia sovrascritto quando si emerge una nuova versione di Xorg, si deve proteggerlo. Aggiungere la seguente riga a /etc/make.conf:

CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"

Se si usa un login manager grafico, serve un metodo diverso.

Per gdm (Gnome Display Manager)

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Per xdm (X Display Manager) e kdm (Kde Display Manager)

:0 local /usr/bin/X11/X -nolisten tcp

11. Il chroot e i server virtuali

11.a. Il chroot

Il chroot per un servizio è un modo di limitare l'ambiente del servizio stesso (o dell'utente) per potere accedere solo dove si ha il permesso, e di non ottenere l'accesso (o le informazioni) che potrebbero portare all'accesso come root. Eseguendo il servizio come utente non root (nobody, apache, named) un attaccante può accedere solo ai file con i permessi di quell'utente. Questo significa che un attaccante non può ottenere l'accesso come root anche se i servizi dovessero avere un problema di sicurezza.

Alcuni servizi come pure-ftpd e bind hanno delle proprie caratteristiche per il chroot, e altri servizi non le hanno. Se il servizio le supporta, si devono usare, altrimenti si devono creare. Segue come creare un chroot con un esempio base, e lo si farà con bash (per una facile comprensione).

Creare la directory /chroot con mkdir /chroot. Trovare le librerie dinamiche con le quali è compilato bash (se è compilato con -static questo passo non è necessario):

Il seguente comando crea un elenco di librerie usate da bash.

# ldd /bin/bash
  libncurses.so.5 => /lib/libncurses.so.5 (0x4001b000)
  libdl.so.2 => /lib/libdl.so.2 (0x40060000)
  libc.so.6 => /lib/libc.so.6 (0x40063000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Ora si crei l'ambiente per bash.

# mkdir /chroot/bash
# mkdir /chroot/bash/bin
# mkdir /chroot/bash/lib

Copiare i file usati da bash (/lib) nella lib del chroot e copiare il comando bash nella directory bin del chroot. Questo crea lo stesso ambiente, con meno funzionalità. Dopo provare: chroot /chroot/bash /bin/bash. Se si ottiene un prompt con /, funziona. Altrimenti si otterrà il nome del file che manca. Alcune librerie condivise dipendono le une dalle altre.

Si noti che dentro al chroot non funziona niente tranne echo. Non ci sono altri comandi nell'ambiente del chroot oltre a bash, e echo è una funzionalità build-in.

Questo è praticamente lo stesso modo con cui si può creare un chroot per un servizio. La sola differenza è che i servizi a volte dipendono dai dispositivi e dai file di configurazione in /etc. Si deve copiarli (i dispositivi possono essere copiati con cp -a) nell'ambiente del chroot, modificare l'init script per poter usare il chroot prima di eseguirlo. Può essere difficile trovare quali dispositivi e file di configurazione sono necessari a un servizio. Viene in aiuto il comando strace. Avviare il servizio con /usr/bin/strace e cercare open, read, stat e forse connect. Si troverà un aiuto su quali file devono essere copiati. Ma nella maggior parte dei casi basta copiare il file passwd (modificare la copia e rimuovere gli utenti che non hanno niente a che fare con il servizio), /dev/zero, /dev/log e /dev/random.

11.b. User Mode Linux

Un altro modo per creare un ambiente più sicuro è quello di eseguire una macchina virtuale. Questa, come dice il nome, è un processo che si esegue all'inizio del sistema operativo reale, e fornisce un ambiente hardware e del sistema operativo che sembra essere quello dell'unica macchina. Il beneficio per la sicurezza è che se il server che si esegue sulla macchina virtuale viene compromesso, sarà interessato solo il server virtuale e non l'installazione reale.

Per ulteriori informazioni su come impostare il User Mode Linux consultare la guida User Mode Linux.

12. Firewall

12.a. Un firewall

Le persone spesso pensano che un firewall fornisce la massima sicurezza, ma non è così. Nella maggior parte dei casi un firewall configurato male fornisce meno sicurezza che non averne uno installato. Un firewall inoltre è una parte di software e tale dovrebbe essere trattato, perchè può benissimo contenere bug.

Quindi è consigliato pensarci prima di installare un firewall. Se ne ha veramente bisogno? Se si pensa che è necessario, allora scrivere da una parte per cosa dovrebbe funzionare, quale tipo di firewall e chi se ne dovrebbe occupare. Ma prima si legga questa guida.

I firewall sono usati per due scopi:

• Per tenere (worm/attaccanti) fuori
• Per tenere (impiegati/bambini) dentro

Ci sono tre tipi di firewall:

• Filtraggio di pacchetti
• Circuit relay
• Gateway di applicazione

Un firewall dovrebbe essere un sistema dedicato, che non esegue servizi (o che esegue solo sshd), come consigliato da questa guida.

12.b. Filtraggio di pacchetti

Tutto il traffico di rete è mandato sotto forma di pacchetti. Una grande quantità di traffico è divisa in piccoli pacchetti per facilitare la gestione, e poi riassemblata quando arriva a destinazione. Nell'intestazione di ogni pacchetto ci sono informazioni su come e dove dovrebbe essere portato. E queste informazioni sono quelle che usa un filtraggio di pacchetti. Il filtraggio è basato su:

• Accettare o meno pacchetti basati sull'indirizzo IP sorgente o di destinazione
• Accettare o meno pacchetti basati sulla porta sorgente o di destinazione
• Accettare o meno pacchetti basati sul protocollo
• Accettare o meno pacchetti basati sulle flag con un protocollo specifico

In altre parole, questo filtraggio è basato su tutti i dati con una intestazione del pacchetto e non sul loro contenuto.

Svantaggi:

• L'informazione di un indirizzo in un pacchetto può essere un indirizzo IP falso (o come si dice spoofed dal mittente).
• I dati o le richieste in un pacchetto che ha avuto il permesso, possono contenere dati non desiderati che l'attaccante può usare per sfruttare bug nei servizi o nel firewall
• Un suo fallimento può generare gravi problemi al sistema

Vantaggi:

• Semplice e facile da installare
• Può dare avvisi di un possibile attacco prima che questo accada (per esempio port scan)
• Buono per fermare attacchi SYN

Esempi di filtraggio di pacchetti su Linux:

• Iptables
• Ipchains
• SmoothWall

12.c. Circuit relay

Un circuito di livello gateway è un firewall che convalida le connessioni prima che sia accettato lo scambio dati. Non accetta o nega solo pacchetti basati sull'intestazione del pacchetto, ma determina se la connessione è valida secondo le regole di configurazione, prima che si apre una sessione di scambio di dati. Il filtraggio è basato su:

• Indirizzo IP sorgente o di destinazione
• Porta sorgente o di destinazione
• Un periodo di tempo
• Protocollo
• Utente
• Password

Tutto il traffico è convalidato e monitorato, e il traffico non desiderato può essere eliminato.

Svantaggi:

• Opera sul Transport Layer e può richiedere modifiche sostanziali del programma che fornisce le funzioni di trasporto.

12.d. Gateway di applicazione

L'applicazione di livello gateway è un proxy per applicazioni, scambio di dati con sistemi remoti sulla parte dei client. E' tenuta non pubblica da un DMZ (De-Militarized Zone: la parte di una rete privata visibile con il firewall) o da un firewall che non permette connessioni da fuori. Il filtraggio è basato su:

• Accettare o meno indirizzi IP sorgenti o di destinazione
• Contenuto del pacchetto
• Limitare l'accesso ai file basati sul tipo di file o estensione

Vantaggi:

• Può fare la cache ai file, e aumentare le performance della rete
• Logging dettagliati di tutte le connessioni
• Scalare bene (alcuni server proxy possono "condividere" dati nella cache)
• Nessun accesso diretto da fuori
• Può anche alterare il contenuto del pacchetto al volo

Svantaggi:

• La configurazione è complessa

I gateway di applicazione sono considerati la soluzione più sicura poichè non devono essere eseguiti come root e i loro host non sono raggiungibili da Internet.

Esempi di gateway di applicazione:

• Squid

12.e. Iptables

Per poter usare iptables, deve essere abilitato il kernel. Qui si sono aggiunti iptables come moduli (il comando iptables li caricherà poichè necessari) e si è ricompilato il kernel (ma si potrebbe volere iptables compilato, se si vuole disabilitare Loadable Kernel Modules come discusso precedentemente). Per ulteriori informazioni su come configurare il kernel per iptables andare in Iptables Tutorial Chapter 5: Preparations. Dopo aver compilato il nuovo kernel (o mentre lo si sta compilando), si deve aggiungere il comando iptables. Un emerge iptables dovrebbe funzionare.

Per testare il suo funzionamento, digitare iptables -L. Se non funziona, ricontrollare la propria configurazione.

Iptables è il nuovo e migliorato filtro di pacchetti nel kernel 2.4.x. E' il successore di ipchains nel kernel 2.2.x. Uno dei maggiori miglioramenti è che iptables può effettuare un completo filtraggio di pacchetti. E grazie a questo, è possibile tenere traccia di ogni connessione TCP stabilita.

Una connessione TCP è una serie di pacchetti che contiene informazioni sull'indirizzo IP sorgente, l'indirizzo IP di destinazione, la porta sorgente, quella di destinazione, e una sequenza di numeri, così che il pacchetto può essere riassemblato senza perdere dati. TCP è un protocollo orientato alla connessione, in contrasto con UDP, che è senza connessione.

Esaminando l'intestazione del pacchetto TCP, un completo filtro di pacchetti può determinare se un pacchetto TCP ricevuto è parte di una connessione già stabilita o meno e decidere se accettare o no il pacchetto.

E' possibile ingannare un non completo filtro di pacchetti quando si accettano pacchetti che si dovrebbero eliminare, manipolando l'intestazione del pacchetto TCP. Può essere fatto con la manipolazione della flag SYN o di altre flag nell'intestazione TCP, per far sembrare un pacchetto pericoloso come parte della connessione stabilita (poichè il filtro di pacchetti non fa una traccia delle connessioni). Con un completo filtro di pacchetti è possibile ridurre questi pacchetti poichè non sono parte di una connessione già stabilita. Questo fermerà anche la possibilità di "stealth scans", un tipo di port scan con il quale si manda pacchetti con flag che sono più probabili di essere loggati da un firewall che da pacchetti ordinari SYN.

Iptables fornisce molte altre caratteristiche come NAT (Network Address Translation) e il rate limiting. Quest'ultimo è utile quando si cerca di prevenire attacchi DoS (Denial of Service) come SYN flood.

Una connessione TCP è stabilita in tre tempi (three-way handshake). Quando si stabilisce la connessione TCP il client manda un pacchetto al server con la flag SYN. Quando il server riceve il pacchetto SYN, risponde mandando un pacchetto SYN+ACK al client. Quando riceve SYN+ACK, il client risponde con un terzo pacchetto ACK che riconosce la connessione.

Un attacco SYN flood è effettuato con il mandare un pacchetto SYN e con una mancata risposta al pacchetto SYN+ACK. Il client può fare un pacchetto con un indirizzo IP sorgente falso perchè non ha bisogno di una replica. Il server aggiungerà una voce a una queue di connessioni metà aperte, quando riceve il pacchetto SYN e poi aspetta il pacchetto finale ACK prima di eliminare la voce dalla queue. La queue ha un numero limitato di slot e se tutti gli slot sono pieni, non si può aprire un'altra connessione. Se il pacchetto ACK non è ricevuto prima di un tempo specificato, la voce sarà eliminata dalla queue. Le impostazione del tempo specificato variano, ma sono di solito 30-60 secondi o più. Il client inizia l'attacco con molti pacchetti SYN con indirizzi IP di diversa sorgente, e li manda agli indirizzi IP da colpire e riempiono la queue delle connessioni metà aperte e non fanno stabilire a altri client una connessione con il server.

In questi casi diventa di aiuto il rate limit. E' possibile limitare una parte di pacchetti SYN accettati con -m limit --limit 1/s. Limita il numero di pacchetti SYN accettati a uno per secondo e restringe il SYN flood nelle risorse.

Alcuni esempi pratici.

Quando iptables è caricato nel kernel, ha cinque sezioni in cui si possono elencare le regole, e sono INPUT, OUTPUT, FORWARD, PREROUTING e POSTROUTING. Ognuna di queste è chiamata chain e consiste in un elenco di regole. Ogni regola indica come è fatta l'intestazione del pacchetto, e poi che cosa fare con il pacchetto. Se la regola non coincide con il pacchetto, si cosulta la prossima regola nella chain.

Si possono mettere le regole direttamente nelle 5 chain principali o creare nuove chain e aggiungerle come regole di una esistente chain. Iptables supporta le seguenti opzioni.

Iniziare con bloccare tutti i pacchetti ICMP nella propria macchina, per familiarizzare con iptables.

# iptables -A INPUT -p icmp -j DROP

Si specifica la chain nella quale dovrebbe essere aggiunta la regola, poi il protocollo del pacchetto coincidente e l'obiettivo. Quest'ultimo può essere il nome di una chain specificata dall'utente o uno degli obiettivi speciali ACCEPT, DROP, REJECT, LOG, QUEUE o MASQUERADE. In questo caso si usa DROP, che ignora il pacchetto senza la risposta al client.

Dare un ping localhost. Non si ottiene nessun messaggio di risposta, poichè iptables ignora tutti i messaggi ICMP in arrivo. Non si possono pingare altre macchine, perchè si ignora anche il pacchetto ICMP reply. Si elimina la chain.

# iptables -F

Si pone in rilievo il filtraggio di pacchetti completo in iptables. Se si vuole abilitare una ispezione completa dei pacchetti in arrivo su eth0, si digiti il comando:

# iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Nel comando sopra, si accettano pacchetti da una connessione già stabilita o associata nella chain INPUT. E si potrebbero eliminare i pacchetti che non sono nella tabella con iptables -A INPUT -i eth0 -m state --state INVALID -j DROP prima del comando precedente. Si abilita il filtraggio di pacchetti completo in iptables caricando l'estensione "state". Se si vuole permettere a altri di connettersi alla propria macchina, si potrebbe usare la flag --state NEW. Iptables contiene alcuni moduli per scopi differenti. Alcuni di questi sono:

Cercare di creare una chain definita dall'utente e applicarla a una chain esistente:

(Creare una nuova chain con una regola)
# iptables -X mychain
# iptables -N mychain
# iptables -A mychain -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
(Tutto il traffico in uscita è accettato. Quello in entrata no.)
# iptables -P OUTPUT ACCEPT
# iptables -P INPUT DROP
(Aggiungerla alla chain INPUT)
# iptables -A INPUT -j mychain

Applicando la regola alla chain input si ottiene: Tutti i pacchetti in uscita sono accettati e quelli in entrata no.

Si può trovare documentazione in Netfilter/iptables documentation.

Si vede un esempio completo.

• Connessioni al firewall sono accettate solo attraverso SSH (porta 22)
• La rete locale dovrebbe avere accesso a HTTP, HTTPS e SSH (anche a DNS)
• Il traffico ICMP può contenere payload e non dovrebbe essere accettato. Solo certo traffico ICMP deve essere accettato.
• Port scan dovrebbero essere rilevati e loggati
• Attacchi SYN dovrebbero essere evitati
• Tutto il traffico rimanente dovrebbe essere eliminato e loggato

#!/sbin/runscript
IPTABLES=/sbin/iptables
IPTABLESSAVE=/sbin/iptables-save
IPTABLESRESTORE=/sbin/iptables-restore
FIREWALL=/etc/firewall.rules
DNS1=212.242.40.3
DNS2=212.242.40.51
#inside
IIP=10.0.0.2
IINTERFACE=eth0
LOCAL_NETWORK=10.0.0.0/24
#outside
OIP=217.157.156.144
OINTERFACE=eth1

opts="${opts} showstatus panic save restore showoptions rules"

depend() {
  need net
}

rules() {
  stop
  ebegin "Setting internal rules"

  einfo "Setting default rule to drop"
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP

  #default rule
  einfo "Creating states chain"
  $IPTABLES -N allowed-connection
  $IPTABLES -F allowed-connection
  $IPTABLES -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT
  $IPTABLES -A allowed-connection -i $IINTERFACE -m limit -j LOG --log-prefix \ 
      "Bad packet from ${IINTERFACE}:"
  $IPTABLES -A allowed-connection -j DROP

  #ICMP traffic
  einfo "Creating icmp chain"
  $IPTABLES -N icmp_allowed
  $IPTABLES -F icmp_allowed
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ 
      time-exceeded -j ACCEPT
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ 
      destination-unreachable -j ACCEPT
  $IPTABLES -A icmp_allowed -p icmp -j LOG --log-prefix "Bad ICMP traffic:"
  $IPTABLES -A icmp_allowed -p icmp -j DROP

  #Incoming traffic
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  #Flood protection
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

  #outgoing traffic
  einfo "Creating outgoing ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-out
  $IPTABLES -F allow-ssh-traffic-out
  $IPTABLES -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT

  einfo "Creating outgoing dns traffic chain"
  $IPTABLES -N allow-dns-traffic-out
  $IPTABLES -F allow-dns-traffic-out
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \ 
      -j ACCEPT
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \ 
     -j ACCEPT

  einfo "Creating outgoing http/https traffic chain"
  $IPTABLES -N allow-www-traffic-out
  $IPTABLES -F allow-www-traffic-out
  $IPTABLES -A allow-www-traffic-out -p tcp --dport www -j ACCEPT
  $IPTABLES -A allow-www-traffic-out -p tcp --dport https -j ACCEPT

  #Catch portscanners
  einfo "Creating portscan detection chain"
  $IPTABLES -N check-flags
  $IPTABLES -F check-flags
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \ 
      --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:" 
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit \ 
      5/minute -j LOG --log-level 1 --log-prefix "XMAS:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \ 
      -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -m limit \ 
      --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit \ 
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \ 
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

  # Apply and add invalid states to the chains
  einfo "Applying chains to INPUT"
  $IPTABLES -A INPUT -m state --state INVALID -j DROP
  $IPTABLES -A INPUT -p icmp -j icmp_allowed
  $IPTABLES -A INPUT -j check-flags
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A INPUT -j allow-ssh-traffic-in
  $IPTABLES -A INPUT -j allowed-connection

  einfo "Applying chains to FORWARD"
  $IPTABLES -A FORWARD -m state --state INVALID -j DROP
  $IPTABLES -A FORWARD -p icmp -j icmp_allowed
  $IPTABLES -A FORWARD -j check-flags
  $IPTABLES -A FORWARD -o lo -j ACCEPT
  $IPTABLES -A FORWARD -j allow-ssh-traffic-in
  $IPTABLES -A FORWARD -j allow-www-traffic-out
  $IPTABLES -A FORWARD -j allowed-connection

  einfo "Applying chains to OUTPUT"
  $IPTABLES -A OUTPUT -m state --state INVALID -j DROP
  $IPTABLES -A OUTPUT -p icmp -j icmp_allowed
  $IPTABLES -A OUTPUT -j check-flags
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  $IPTABLES -A OUTPUT -j allow-ssh-traffic-out
  $IPTABLES -A OUTPUT -j allow-dns-traffic-out
  $IPTABLES -A OUTPUT -j allow-www-traffic-out
  $IPTABLES -A OUTPUT -j allowed-connection

  #Allow client to route through via NAT (Network Address Translation)
  $IPTABLES -t nat -A POSTROUTING -o $OINTERFACE -j MASQUERADE 
  eend $?
}

start() {
  ebegin "Starting firewall"
  if [ -e "${FIREWALL}" ]; then
    restore
  else
    einfo "${FIREWALL} does not exists. Using default rules."
    rules
  fi
  eend $?
}

stop() {
  ebegin "Stopping firewall"
  $IPTABLES -F
  $IPTABLES -t nat -F
  $IPTABLES -X
  $IPTABLES -P FORWARD ACCEPT
  $IPTABLES -P INPUT   ACCEPT
  $IPTABLES -P OUTPUT  ACCEPT
  eend $?
}

showstatus() {
  ebegin "Status"
  $IPTABLES -L -n -v --line-numbers
  einfo "NAT status"
  $IPTABLES -L -n -v --line-numbers -t nat
  eend $?
}

panic() {
  ebegin "Setting panic rules"
  $IPTABLES -F
  $IPTABLES -X
  $IPTABLES -t nat -F
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  eend $?
}

save() {
  ebegin "Saving Firewall rules"
  $IPTABLESSAVE > $FIREWALL
  eend $?
}

restore() {
  ebegin "Restoring Firewall rules"
  $IPTABLESRESTORE < $FIREWALL
  eend $?
}

restart() {
  svc_stop; svc_start
}

showoptions() {
  echo "Usage: $0 {start|save|restore|panic|stop|restart|showstatus}"
  echo "start)      will restore setting if exists else force rules"
  echo "stop)       delete all rules and set all to accept"
  echo "rules)      force settings of new rules"
  echo "save)       will store settings in ${FIREWALL}"
  echo "restore)    will restore settings from ${FIREWALL}"
  echo "showstatus) Shows the status" 
}

Alcuni consigli sulla creazione di firewall:

1. Creare le indicazioni che il firewall deve seguire prima di installarlo
2. Farlo semplice
3. Sapere come funziona ogni protocollo (leggere RFC(Request For Comments))
4. Un firewall è una parte di software che si esegue da root.
5. Testarlo

Se si pensa che iptables è difficile da capire o richiede un lungo setup, si può usare Shorewall. Usa iptables per generare le regole, e si concentra su esse e non su specifici protocolli.

12.f. Squid

Squid è un server proxy potente. Può filtrare il traffico basato sul tempo, espressioni regolari su path/URI, indirizzo IP sorgente e di destinazione, dominio, browser, user name autenticato, MIME type, e numero della porta (protocollo).

Nel seguente esempio si è aggiunto un filtro per i banner invece di uno basato sui siti porno. Gentoo.org non dovrebbe essere elencato tra i siti porno, e non si vuole perdere tempo a cercarne alcuni.

Le indicazioni:

• Navigare sul web (HTTP/HTTPS) è permesso durante le ore lavorative (lun-ven 8-17 e sab 8-13), ma se gli impiegati sono al lavoro dopo queste ore, dovrebbero lavorare, non navigare
• Non è permesso scaricare file (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg, etc)
• Non piacciono i banner, e sono filtrati e sostituiti con una gif trasparente.
• Tutte le altre connessioni verso e da Internet sono negate.

Quattro sono i semplici passi.

# Bind to a ip and port
http_port 10.0.2.1:3128

# Standard configuration
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

# Add basic access control lists
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

# Add who can access this proxy server
acl localnet src 10.0.0.0/255.255.0.0

# And ports
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl purge method PURGE

# Add access control list based on regular
# expressions within urls
acl archives urlpath_regex "/etc/squid/files.acl"
acl url_ads url_regex "/etc/squid/banner-ads.acl"

# Add access control list based on time and day
acl restricted_weekdays time MTWHF 8:00-17:00
acl restricted_weekends time A 8:00-13:00

acl CONNECT method CONNECT

#allow manager access from localhost
http_access allow manager localhost
http_access deny manager

# Only allow purge requests from localhost
http_access allow purge localhost
http_access deny purge

# Deny requests to unknown ports
http_access deny !Safe_ports

# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports

# My own rules

# Add a page do be displayed when
# a banner is removed
deny_info NOTE_ADS_FILTERED url_ads

# Then deny them
http_access deny url_ads

# Deny all archives
http_access deny archives

# Restrict access to work hours
http_access allow localnet restricted_weekdays
http_access allow localnet restricted_weekends

# Deny the rest
http_access deny all

Mettere i tipi di file che non si vuole che siano scaricati dagli utenti, qui si sono aggiunti zip, viv, exe, mp3, rar, ace, avi, mov, mpg, mpeg, au, ra, arj, tar, gz e z.

\.[Zz][Ii][pP]$
\.[Vv][Ii][Vv].*
\.[Ee][Xx][Ee]$
\.[Mm][Pp]3$
\.[Rr][Aa][Rr]$
\.[Aa][Cc][Ee]$
\.[Aa][Ss][Ff]$
\.[Aa][Vv][Ii]$
\.[Mm][Oo][Vv]$
\.[Mm][Pp][Gg]$
\.[Mm][Pp][Ee][Gg]$
\.[Aa][Uu]$
\.[Rr][Aa]$
\.[Aa][Rr][Jj]$
\.[Tt][Aa][Rr]$
\.[Gg][Zz]$
\.[Zz]$

Si aggiungono le espressioni regolari per identificare i banner.

/adv/.*\.gif$
/[Aa]ds/.*\.gif$
/[Aa]d[Pp]ix/
/[Aa]d[Ss]erver
/[Aa][Dd]/.*\.[GgJj][IiPp][FfGg]$
/[Bb]annerads/
/adbanner.*\.[GgJj][IiPp][FfGg]$
/images/ad/
/reklame/
/RealMedia/ads/.*
^http://www\.submit-it.*
^http://www\.eads.*
^http://ads\.
^http://ad\.
^http://ads02\.
^http://adaver.*\.
^http://adforce\.
adbot\.com
/ads/.*\.gif.*
_ad\..*cgi
/Banners/
/SmartBanner/
/Ads/Media/Images/
^http://static\.wired\.com/advertising/
^http://*\.dejanews\.com/ads/
^http://adfu\.blockstackers\.com/
^http://ads2\.zdnet\.com/adverts
^http://www2\.burstnet\.com/gifs/
^http://www.\.valueclick\.com/cgi-bin/cycle
^http://www\.altavista\.com/av/gifs/ie_horiz\.gif

E come ultima parte si vuole che sia mostrato questo file quando è rimosso un banner. E' un file metà HTML con una immagine gif 4x4 trasparente.

<HTML>
<HEAD>
<META HTTP-EQUIV="REFRESH" CONTENT="0; URL=http://localhost/images/4x4.gif">
<TITLE>ERROR: The requested URL could not be retrieved</TITLE>
</HEAD>
<BODY>
<H1>Add filtered!</H1>

Come si può vedere, Squid ha molte possibilità e funziona bene come filtro e proxy. Possono essere usati proxy alternativi Squid per funzionare bene con una grande rete. La configurazione elencata va bene per una piccola rete di 1-20 utenti.

Usare il filtro di pacchetti (iptables) e il gateway di applicazione (Squid) è la migliore soluzione, anche se nessuno può accedere a Squid da fuori. Fare attenzione agli attacchi da dentro.

Si deve configurare il browser per usare il server proxy. Il gateway non permette il contatto con l'esterno agli utenti, a meno che si usi il proxy.

Si può usare iptables per mandare tutto il traffico outbound a un proxy Squid. Si aggiunge una regola forwarding/prerouting sul gateway:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to proxyhost:3128
# iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128

12.g. Lezioni imparate

Si è imparato che:

1. Un firewall può essere un rischio. Un firewall configurato male è peggio che non averne uno.
2. Come impostare un gateway di base e un proxy.
3. Per avere un buon firewall si deve conoscere il protocollo che si vuole permettere.
4. Che il traffico IP non sempre contiene dati sicuri, esempio pacchetti ICMP, che possono contenere pericolosi payload.
5. Come prevenire un attacco SYN.
6. Filtrare il traffico HTTP con la cancellazione di immagini offensive e scaricamenti di virus.
7. Combinare filtri di pacchetti e gateway di applicazione fornisce un migliore controllo.

Se si è pronti, creare un firewall che corrisponda alle proprie esigenze.

13. Rilevare le intrusioni

13.a. AIDE (Advanced Intrusion Detection Environment)

AIDE è un sistema Host-Based per il rilevamento delle intrusioni (HIDS), una alternativa libera a Tripwire (se si conosce già Tripwire non si ha difficoltà con il file di configurazione di AIDE). Gli HIDS sono usati per rilevare cambiamenti ad importanti file di configurazione del sistema e binari, e generalmente funzionano producendo un hash crittografico unico per i file da controllare, che poi custodiscono in un luogo sicuro. A intervalli regolari (ad esempio una volta al giorno), l'hash memorizzato, ritenuto buono, viene comparato con quello generato dalla copia attuale di ogni file, per determinare se il file sia stato modificato. Gli HIDS sono un ottimo strumento per rilevare modifiche non autorizzate al sistema, ma necessitano di un po' di lavoro per essere configurati in modo da poter funzionare al meglio.

Il file di configurazione è basato su espressioni regolari, macro e regole per i file e le directory. Si hanno le seguenti macro:

Queste macro diventano molto comode se si ha più di una macchina Gentoo e si vuole usare AIDE su ognuna di esse. Ma non tutte le macchine eseguono gli stessi servizi, e spesso non hanno neppure gli stessi utenti.

Poi si hanno una serie di flag per controllare i file e le directory. Esse sono una combinazione di permessi, proprietà dei file e hash crittografici (es. checksums).

Se AIDE è compilato con il supporto mhash, avrà alcune funzioni aggiuntive:

Ora si possono creare le regole personali, combinando le flag elencate sopra. Ecco un esempio:

All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

L'ultima cosa di cui si ha bisogno per creare il file di configurazione personale è sapere come aggiungere una regola a un file o a una directory. Per inserire una regola, combinare il nome del file o della directory e la regola. AIDE aggiungerà tutti i file ricorsivamente, a meno che non si specifica una regola diversa.

Vediamo un esempio completo:

@@ifndef TOPDIR
@@define TOPDIR /
@@endif

@@ifndef AIDEDIR
@@define AIDEDIR /etc/aide
@@endif

@@ifhost smbserv
@@define smbactive
@@endif

# La posizione del database da leggere.
database=file:@@{AIDEDIR}/aide.db

# La posizione del database da scrivere.
database_out=file:aide.db.new

verbose=20
report_url=stdout

# Definizione regola
All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

@@{TOPDIR} Norm
!@@{TOPDIR}etc/aide
!@@{TOPDIR}dev
!@@{TOPDIR}media
!@@{TOPDIR}mnt
!@@{TOPDIR}proc
!@@{TOPDIR}root
!@@{TOPDIR}sys
!@@{TOPDIR}tmp
!@@{TOPDIR}var/log
!@@{TOPDIR}var/run
!@@{TOPDIR}usr/portage
@@ifdef smbactive
!@@{TOPDIR}etc/smb/private/secrets.tdb
@@endif
=@@{TOPDIR}home Norm

Nell'esempio sopra si è specificato con alcune macro dove inizia la directory superiore e dove si trova la directory AIDE. AIDE controlla il file /etc/aide/aide.db quando controlla l'integrità di un file. Ma quando aggiorna o crea un nuovo file, salva le informazioni in /etc/aide/aide.db.new. Questo serve a far sì che il vecchio file db non venga sovrascritto automaticamente. L'opzione report_URL non è ancora implementata, ma l'intenzione dell'autore è che essa sia in grado di inviare script via e-mail, o forse perfino di eseguirli.

L'ebuild di AIDE comprende un file di configurazione di default funzionante, uno script di aiuto e uno script crontab. Lo script di aiuto esegue automaticamente un gran numero di operazioni e fornisce un'interfaccia un po' più amichevole. Per vedere tutte le opzioni disponibili, provare con aide --help. Per iniziare, tutto ciò che si deve fare è aide -i, e lo script crontab dovrebbe rilevare il database e inviare ogni giorno le email appropriate. Si raccomanda di rivedere il file /etc/aide/aide.conf, per assicurarsi che la configurazione rifletta accuratamente le caratteristiche del sistema.

In verità c'è qualche rischio nel salvare i file db localmente, in quanto chi vuole compiere un attacco probabilmente cercherà (se sa che AIDE è installato) di alterare o aggiornare il file db, oppure modificherà /usr/bin/aide. Per questo si deve creare un cd o un altro supporto contenente una copia del file .db e i binari di AIDE.

Si possono trovare informazioni nella pagina del progetto AIDE.

13.b. Snort

Snort è un sistema di rilevamento di intrusioni da rete (NIDS). Per installarlo e configurarlo usare i seguenti esempi:

PIDFILE=/var/run/snort_eth0.pid
MODE="full"
NETWORK="10.0.0.0/24"
LOGDIR="/var/log/snort"
CONF=/etc/snort/snort.conf
SNORT_OPTS="-D -s -u snort -dev -l $LOGDIR -h $NETWORK -c $CONF"

(Passo 1)
var HOME_NET 10.0.0.0/24
var EXTERNAL_NET any
var SMTP $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var DNS_SERVERS [10.0.0.2/32,212.242.40.51/32]
var RULE_PATH ./

(Passo 2)
preprocessor frag2
preprocessor stream4: detect_scans detect_state_problems detect_scans disable_evasion_alerts
preprocessor stream4_reassemble: ports all
preprocessor http_decode: 80 8080 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor bo: -nobrute
preprocessor telnet_decode

(Passo 3)
include classification.config

(Passo 4)
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/porn.rules
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
# include $RULE_PATH/experimental.rules
include $RULE_PATH/local.rules

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1

# NEW CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: kickass-porn,SCORE! Get the lotion!,1

Maggiori informazioni sul sito di Snort.

13.c. Rilevare malware con chkrootkit

Gli HIDS come AIDE sono un ottimo strumento per rilevare le modifiche al sistema, ma avere un'altra linea di difesa non guasta mai. chkrootkit è una utility che analizza i comuni file di sistema cercando la presenza di rootkit--software progettati per nascondere l'azione di un intruso, consentendogli di mantenere l'accesso al sistema--e scandaglia il sistema alla ricerca di tracce di key loggers e altri "malware". Sebbene chkrootkit e altri programmi, come rkhunter, siano strumenti utili, sia per la manutenzione del sistema che per rilevare le tracce di un intruso dopo un attacco, essi non possono garantire la sicurezza del sistema.

Il modo migliore di usare chkrootkit per rilevare un'intrusione è quello di eseguirlo regolarmente da cron. Per iniziare, emergere app-forensics/chkrootkit. chkrootkit può essere eseguito dalla linea di comando con lo stesso nome, oppure da cron in questo modo:

0 3 * * * /usr/sbin/chkrootkit

14. Aggiornare

14.a. Mantenere aggiornato il sistema

Dopo aver installato il sistema e assicurato un buon livello di sicurezza, ancora non è finito il tutto. La sicurezza è un processo in evoluzione; la grande maggioranza delle intrusioni arriva da vulnerabilità conosciute in sistemi non patchati. Mantenere il sistema aggiornato è il passo più importante per ottenere la maggiore sicurezza.

Se si è installata una versione recente di portage, si può prima dare un emerge --sync e poi digitare il comando glsa-check --list per controllare se il proprio sistema è aggiornato in base agli accorgimenti di sicurezza. glsa-check è parte di app-portage/gentoolkit.

# glsa-check -l
WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

[A] means this GLSA was already applied,
[U] means the system is not affected and
[N] indicates that the system might be affected.

200406-03 [N] sitecopy: Multiple vulnerabilities in included libneon ( net-misc/sitecopy )
200406-04 [U] Mailman: Member password disclosure vulnerability ( net-mail/mailman )
.......

Tutte le righe con una [A] e [U] possono essere ignorate poichè il sistema non è affetto da questa GLSA.

(Controllare se il proprio sistema è affetto da GLSA)
# glsa-check -t all
WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

This system is affected by the following GLSA:
200504-06
200510-08
200506-14
200501-35
200508-12
200507-16

(Vedere quali pacchetti sono da emergere
# glsa-check -p $(glsa-check -t all)
     (output parziale)
Checking GLSA 200504-06
The following updates will be performed for this GLSA:
     app-arch/sharutils-4.2.1-r11 (4.2.1-r10)

     **********************************************************************

     Checking GLSA 200510-08
     The following updates will be performed for this GLSA:
          media-libs/xine-lib-1.1.0-r5 (1.1.0-r4)

(Applicare le correzioni richieste)
# glsa-check -f $(glsa-check -t all)

Se si è aggiornato un servizio in esecuzione, non dimenticare di riavviarlo.

E' raccomandato anche mantenere aggiornato il proprio kernel.

Se si desidera ricevere una email ogni volta che si rilascia una GLSA, iscriversi alla mailing list gentoo-announce. Le istruzioni per l'iscrizione a questa e a altre mailing list, sono in Gentoo Linux Mailing List Overview.

Un'altra grande risorsa sulla sicurezza è Bugtraq mailing list.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.