Capitolo 12. Domande frequenti (FAQ)

Non ci sono davvero molte differenze fra le varie distribuzioni Linux, al di là dell'installazione di base e del sistema di gestione dei pacchetti; in genere, esse hanno in comune molti applicativi (ad esempio, il kernel, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc.), che si differenziano principalmente per la versione inclusa nella distribuzione stabile.

Red Hat è stata sfortunata nel rilasciare una versione contenente l'allora attuale foo 1.2.3., che aveva un difetto nella sicurezza, come si scoprì in un secondo momento; invece, Debian ha avuto miglior sorte nel rilasciare la propria con foo 1.2.4, in cui quel difetto era stato eliminato. L'identico caso si ripeté con http://www.cert.org/advisories/CA-2000-17.html, un paio di anni fa.

Fra i gruppi per la sicurezza delle maggiori distribuzioni Linux c'è molta collaborazione: raramente un distributore trascura di sistemare gli aggiornamenti in materia di sicurezza e le cognizioni sulla sua vulnerabilità non vengono mai nascoste agli altri, dato che le correzioni vengono coordinate già in fase di sviluppo, oppure dal http://cert.org. Ne consegue che gli aggiornamenti necessari vengono diffusi nello stesso momento e la relativa sicurezza delle diverse distribuzioni è molto simile.

Riguardo ad essa, uno dei maggiori vantaggi di Debian è il semplice sistema di aggiornamento mediante l'uso di apt; ma ecco altri aspetti da considerare:

La distribuzione Debian vanta un grande e crescente numero di pacchetti software, probabilmente più di quelli offerti da molti sistemi operativi proprietari. Maggiore è il numero dei pacchetti installati, maggiore il rischio di problemi di sicurezza in qualunque dato sistema.

Aumenta il numero di esaminatori del codice sorgente per cercare imperfezioni. Ci sono molti resoconti circa i controlli sul codice sorgente dei principali componenti software inclusi in Debian: qualora un controllo riveli dei difetti per la sicurezza, vi si ovvia e se ne manda un resoconto a liste come Bugtraq.

Di solito, i difetti presenti in Debian affliggono anche le altre distribuzioni. Controllate la sezione "Specifico di Debian: sì/no" all'inizio di ogni resoconto DSA (Debian Specific Advisory).

Risposta concisa: no.

Risposta lunga: la certificazione costa soldi (specialmente una certificazione di sicurezza seria), nessuno ha dedicato le risorse allo scopo di certificare Debian GNU/Linux ad alcun livello come, ad esempio, il http://niap.nist.gov/cc-scheme/st/. Se siete interessati ad avere una distribuzione GNU/Linux certificata in ambito sicurezza, provate a fornire prima di tutto le risorse per rendere possibile ciò.

There are currently at least two linux distributions certified at different http://en.wikipedia.org/wiki/Evaluation_Assurance_Level levels. Notice that some of the CC tests are being integrated into the http://ltp.sourceforge.net which is available in Debian in the ltp.

Yes. http://bastille-linux.sourceforge.net/, originally oriented toward other Linux distributions (Red Hat and Mandrake), it currently works also for Debian. Steps are being taken to integrate the changes made to the upstream version into the Debian package, named bastille.

Alcuni, tuttavia, ritengono che gli strumenti per avere maggiore sicurezza non possano eliminare l'esigenza di una buona amministrazione.

Un punto di forza di Debian è l'ampia varietà di scelta fra pacchetti che forniscono le stesse funzionalità (serventi di tipo DNS, ftp, di posta, web, etc.). Questo può confondere un amministratore inesperto nel determinare il pacchetto più adatto alle sue esigenze. La soluzione migliore dipende da un compromesso fra le esigenze di funzionalità e quelle della sicurezza. Per decidere fra pacchetti simili, bisogna rispondere ad alcune domande, come:

In questo documento si troveranno informazioni sul modo per rendere alcuni servizi (FTP, Bind) più sicuri in Debian GNU/Linux. Per quelli non trattati qui, vedete la documentazione del programma o in generale le informazioni per quel software in GNU/Linux. La maggior parte delle linee guida per la sicurezza di Unix si applicano anche a Debian. Proteggere un servizio in Debian è come farlo in qualunque altra distribuzione Linux (o Un*x, per quell'argomento).

If you do not like users connecting to your POP3 daemon, for example, and retrieving information about your system, you might want to remove (or change) the banner the service shows to users. ^[74] Doing so depends on the software you are running for a given service. For example, in postfix, you can set your SMTP banner in /etc/postfix/main.cf:

 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

Other software is not as easy to change. ssh will need to be recompiled in order to change the version that it prints. Take care not to remove the first part (SSH-2.0) of the banner, which clients use to identify which protocol(s) is supported by your package.

Il Team Debian per la Sicurezza non può analizzare i potenziali punti deboli di tutti i pacchetti, perché mancano le risorse per revisionare l'intero codice sorgente; Debian beneficia, però, delle revisioni svolte dagli sviluppatori.

In effetti, uno sviluppatore Debian potrebbe benissimo distribuire un virus di tipo trojan in un pacchetto, senza che venga scoperto: anche se esperti in un ramo di Debian, sarebbe impossibile trattare tutte le possibili situazioni in cui il trojan potrebbe agire. Perciò, Debian ha una licenza "no guarantees" (nessuna garanzia).

Tuttavia, gli utenti Debian possono fidare nel fatto che il codice stabile abbia un vasto pubblico: la maggior parte dei problemi si manifesterebbe con l'uso. In un sistema molto importante, non è indicato installare software che non sia stato sottoposto ad un processo di revisione del codice sorgente. In ogni caso, quand'anche nella distribuzione sia introdotta una vulnerabilità della sicurezza, il processo di inclusione dei pacchetti assicura la riconducibilità finale allo sviluppatore (mediante le firme digitali). Il progetto Debian non sottovaluta il problema.

Naturalmente, nel proprio sistema, ognuno può cambiare i permessi predefiniti di Debian. Con l'attuale codice di condotta sui file di log e configurazione, ognuno li può leggere, salvo che contengano informazioni sensibili.

Si raccomanda prudenza, nel fare cambiamenti, dal momento che:

FIXME: Controllare se questo sia scritto nella Policy. Alcuni pacchetti (ad esempio i demoni ftp) sembrano imporre permessi differenti.

In effetti, l'identico problema riguarda qualunque altro utente. Siccome l'installazione di Debian non mette alcun file sotto quella directory, non vi sono informazioni importanti da proteggere; se ritenete che tali permessi siano troppo laschi per il sistema, li potete portare a 750. Per gli utenti, leggete in Sezione 4.11.19.1, «Limitare l'accesso alle informazioni di altri utenti».

This Debian security mailing list http://lists.debian.org/debian-devel/2000/11/msg00783.html has more on this issue.

Se riceveste messaggi in console ed aveste configurato /etc/syslog.conf, in modo da trasmetterli a dei file o ad uno speciale TTY, potreste vedere i messaggi direttamente sulla console.

Per ogni kernel, il livello predefinito per la trasmissione dei messaggi di log è 7 e quelli con priorità inferiore appariranno in console. Di solito i firewall (il regno dei LOG) ed altri strumenti per la sicurezza registrano log con priorità inferiore, che, quindi, vengono spediti direttamente in console.

To reduce messages sent to the console, you can use dmesg (-n option, see dmseg(8)), which examines and controls the kernel ring buffer. To fix this after the next reboot, change /etc/init.d/klogd from:

  KLOGD=""

a:

  KLOGD="-c 4"

Usate un numero inferiore per -c, se continuate a vederli; una descrizione dei vari livelli dei messaggi di log si trova in /usr/include/sys/syslog.h:

  #define LOG_EMERG       0       /* system is unusable */
  #define LOG_ALERT       1       /* action must be taken immediately */
  #define LOG_CRIT        2       /* critical conditions */
  #define LOG_ERR         3       /* error conditions */
  #define LOG_WARNING     4       /* warning conditions */
  #define LOG_NOTICE      5       /* normal but significant condition */
  #define LOG_INFO        6       /* informational */
  #define LOG_DEBUG       7       /* debug-level messages */

La linea di condotta di Debian prevede di assegnare ad ogni utente un proprio gruppo. Il tradizionale schema UN*X assegna tutti gli utenti al gruppo users. Ulteriori gruppi vengono creati ed utilizzati per limitare l'accesso a file condivisi associati a cartelle di progetti diverse. Siccome, all'atto della creazione, i file vengono associati al gruppo di prima appartenenza dell'autore, la loro gestione diventa difficile, se l'utente lavora su più progetti.

Lo schema Debian risolve questo problema, assegnando ad ogni utente un gruppo personale, sicché, con una corretta umask (0002) e con il bit per l'assegnazione del gruppo (SETGID) impostato su una data cartella di progetto, il gruppo viene assegnato automaticamente ed i file vengono creati in quella cartella. Ciò agevola chi lavora su più progetti, evitandogli di cambiare gruppo o umask quando lavora su file condivisi.

Tuttavia, dando il valore "no" alla variabile USERGROUPS, nel file /etc/adduser.conf, si può cambiare questo comportamento. In tal modo, quando si crea un nuovo utente, non si crea anche un nuovo gruppo. Le stesse considerazioni valgono per l'impostazione di USERS_GID al GID cui tutti gli utenti appartengono.

For example, if you want to set up a POP service, you don't need to set up a user account for each user accessing it. It's best to set up directory-based authentication through an external service (like Radius, LDAP or an SQL database). Just install the appropriate PAM library (libpam-radius-auth, libpam-ldap, libpam-pgsql or libpam-mysql), read the documentation (for starters, see Sezione 4.11.1, «Autenticazione degli utenti: PAM») and configure the PAM-enabled service to use the back end you have chosen. This is done by editing the files under /etc/pam.d/ for your service and modifying the

 
  auth   required    pam_unix_auth.so shadow nullok use_first_pass

in, per esempio, ldap:

  auth   required    pam_ldap.so

In caso di directory LDAP, alcuni servizi forniscono uno schema LDAP da includere nella directory allo scopo di usare l'autenticazione via LDAP. Se state usando un database relazionale, un trucco utile è usare l'espressione where quando configurate il modulo PAM. Per esempio, se avete un database con i seguenti campi:

  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

Prendendo i campi booleani degli attributi dei servizi, potrete usarli per abilitare o disabilitare i diversi servizi solamente inserendo la riga appropriata nei seguenti file:

Molti scanner per ricercare vulnerabilità trovano falsi positivi, quando vengono usati in sistemi Debian, usano solamente il controllo di versione per determinare se un dato pacchetto sia vulnerabile, ma non ne testano la vulnerabilità. Poiché Debian non cambia la versione del software quando corregge un pacchetto (molte volte una correzione rilasciata recentemente pare una vecchia versione) molti programmi tendono a "pensare" che un sistema Debian aggiornato sia vulnerabile, invece è vero il contrario.

Se pensate che il vostro sistema sia sicuro usando le patch di sicurezza, vi invito ad incrociare i vostri riferimenti con il database sulla sicurezza pubblicato con il DSAs (leggete in Sezione 7.2, «Avvisi di sicurezza Debian») per eliminare false sicurezze, sempre se il tool che usate include i riferimenti per CVE.

Un traccia di attacco non significa necessariamente che il sistema sia stato compromesso, dovreste compiere i comuni passaggi per determinare se il sistema è stato realmente compromesso (leggete in Capitolo 11, Dopo la compromissione (reazione agli incidenti)). Altresì, se avete visto dai log che è avvenuto un attacco, è possibile che il vostro sistema sia vulnerabile allo stesso tipo di attacco (un attaccante molto determinato può aver sfruttato molte altre falle di sicurezza).

Dovete ricercare le seguenti righe nei vostri log di sistema:

  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --

This does not indicate any kind of compromise, and users changing between Debian releases might find it strange. If your system does not have high loads (or many active services), these lines might appear throughout your logs. This is an indication that your syslogd daemon is running properly. From syslogd(8):

       -m interval
              The syslogd logs a mark timestamp  regularly.   The
              default interval between two -- MARK -- lines is 20
              minutes.  This can be  changed  with  this  option.
              Setting the interval to zero turns it off entirely.

Dovete ricercare delle righe simili alle seguenti nei vostri log:

  Apr  1 09:25:01 server su[30315]: + ??? root-nobody
  Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)

Non preoccupatevi. Controllate se queste righe sono presenti nei job di cron (solitamente si trovano in /etc/cron.daily/find oppure logrotate):

  $ grep 25 /etc/crontab
  25 9    * * *   root    test -e /usr/sbin/anacron || run-parts --report
  /etc/cron.daily
  $ grep nobody /etc/cron.daily/*
  find:cd / && updatedb --localuser=nobody 2>/dev/null

Se nei vostri log trovate delle righe come le seguenti:

  May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

Controllate se sono presenti molte connessioni attive sul server usando netstat, ad esempio:

  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000

Questo è un indice certo di un attacco denial of service (DoS) contro la porta X (molto spesso avvengono contro dei servizi pubblici come i server web o i server di posta). Vi invito ad attivare nel vostro kernel l'opzione TCD syncookies, leggete in Sezione 4.18.2, «Configurare i Syncookies». Attenzione comunque, come un attacco DoS può saturare la vostra rete, al tempo stesso potete fermarlo mandando in crash il sistema (saturando i file descrittori, il sistema rimane inerte finché la connessione TCP non viene interrotta). Il solo modo efficace per fermare questo tipo di attacco è quello di contattare il vostro provider.

Potreste vedere queste righe nel vostro file /var/log/auth.log:

  May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
  May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
  May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
  (UID=0)
  May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

Sono dovuti all'esecuzione di un processo cron (nell'esempio, ogni cinque minuti). Per stabilire quale programma è responsabile dei processi, controllare le immissioni sotto: /etc/crontab, /etc/cron.d, /etc/crond.daily ed il crontab di root sotto /var/spool/cron/crontabs.

Esistono diversi passaggi che potreste seguire in caso di intrusione:

Osservando i log (se non sono stati alterati), utilizzando sistemi di rilevamento di intrusioni (vedete in Sezione 10.3, «Pianificare la ricerca di intrusi»), traceroute, whois e strumenti simili (inclusa analisi forense), potreste essere in grado di tracciare un attacco fino alla fonte. Il modo in cui reagite a questa informazione dipende unicamente dalla vostra politica di sicurezza, e da cosa voi considerate un attacco. Uno scan remoto è un attacco? Un rilevamento di vulnerabilità è un attacco?

Per prima cosa, controllate se la vulnerabilità è stata resa pubblica sulle mailing list di sicurezza (come Bugtraq) o altri forum. Il Team per la sicurezza di Debian si tiene in contatto con queste liste, quindi potrebbero essere a conoscenza del problema. Non procedete in modo diverso se vedete un annuncio su http://security.debian.org, da quanto suggerito per correggere la vulnerabilità.

If no information seems to be published, please send e-mail about the affected package(s), as well as a detailed description of the vulnerability (proof of concept code is also OK), to mailto:[email protected]. This will get you in touch with Debian's security team.

Invece di aggiornare ad un nuovo rilascio, Debian riporta gli aggiornamenti di sicurezza alla versione che è stata distribuita con la versione stabile. Il motivo è assicurarsi che i rilasci stabili cambino il meno possibile, così che le cose non cambino o si interrompano inaspettatamente a causa di un aggiornamento di sicurezza. Potete controllare se sta girando una versione sicura di un pacchetto dal changelog package, o confrontando il numero di versione (versione corrente -slash- rilascio Debian) con la versione indicata nel Debian Security Advisory.