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

Securing Debian Manual
Capitolo 11 - Domande frequenti (FAQ)


Questo capitolo introduce alcune delle domande più frequenti nella lista di discussione Debian sulla sicurezza (Debian security mailing list): bisogna leggerle, prima di spedire domande e rischiare la risposta, RTFM ("leggiti il fottuto manuale!").


11.1 La sicurezza nel sistema operativo Debian


11.1.1 Debian è più sicura di quella X?

Un sistema è sicuro in proporzione alla capacità del suo amministratore di renderlo tale. L'installazione predefinita di Debian mira alla sicurezza, ma può non essere paranoica come quelle di altri sistemi operativi che installano tutti i servizi predefinitamente esclusi. In ogni caso, ogni amministratore deve adattare la sicurezza del sistema alla politica di sicurezza di dov'è impiegato.

Per una raccolta di dati sulle vulnerabilità della sicurezza in molti sistemi operativi, vedete http://securityfocus.com/vulns/stats.shtml, sito che elenca parecchi fattori di cui tenere conto nell'interpretazione dei dati; notate che i medesimi dati non possono essere usati per confrontare le vulnerabilità di sistemi operativi diversi. [35]. Inoltre ricordate che alcune vulnerabilità di Debian scoperte da Bugtraq riguardano solamente la distribuzione unstable.


11.1.1.1 Debian è più sicura di altre distribuzioni Linux (Red Hat, SuSe...)?

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, ecc.), che si differenziano principalmente per la versione inclusa nella distribuzione stabile.

RedHat è 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 rpc.statd, un paio di anni fa.

Fra i gruppi della 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 sono coordinate già in fase di sviluppo, oppure dal CERT. Ne consegue che gli aggiornamenti necessari sono 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:


11.1.2 Bugtraq cita molti difetti di Debian: è forse molto vulnerabile?

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


11.1.3 Debian ha certificazioni di sicurezza?

Risposta concisa: no.

Risposta prolissa: le certificazioni costano e nessuno ha destinato risorse alla certificazione di Debian/GNU Linux nemmeno a livello di Criteri Comuni. Se siete interessati alla sua certificazione, fornite le risorse necessarie (grazie!).


11.1.4 Ci sono programmi per rendere Debian più sicura?

Sì. Bastille Linux, diretto, all'origine, ad altre distribuzioni Linux (RedHat e Mandrake), oggi funziona su Debian. Si sta procedendo a integrare i cambiamenti apportati sulla versione di sviluppo nel pacchetto Debian chiamato bastille.

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


11.1.5 Ho necessità di rendere disponibile il servizio XYZ, come sceglierlo?

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, di rete, ecc.). Questo può confondere un amministratore inesperto nel determinare il pacchetto più adatto per un utente. La soluzione migliore dipende da un compromesso fra le esigenze dell'utenza e quelle della sicurezza. Per decidere fra pacchetti simili, bisogna rispondere ad alcune domande, come:


11.1.6 Come rendere il servizio XYZ più sicuro in Debian?

In questo documento si troveranno informazioni sul modo di rendere alcuni servizi (FTP, Bind) più sicuri in Debian GNU/Linux (per quelli non trattati qui, vedete la documentazione del programma o le informazioni generali su 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).


11.1.7 Come posso rimuovere tutte le etichette per i servizi?

Se non si vuole che gli utenti si connettano ad un servizio ed ottengano informazioni sul sistema, probabilmente vorrete rimuovere o cambiare l'etichetta che quel servizio mostra all'utente [37] a seconda del software eseguito. Per esempio, in postfix si può impostare l'etichetta SMTP della cartella /etc/postfix/main.cf:

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

Altro software non è così semplice a modificarsi. OpenSSH richiederà una ricompilazione per modificare la versione mostrata; fate attenzione a non rimuovere la prima parte dell'etichetta (SSH-2.0), usata dai client per identificare il protocollo, ovvero i protocolli, che il pacchetto supporta.


11.1.8 Sono sicuri tutti i pacchetti Debian?

Il Security Team di Debian non può analizzare i potenziali punti deboli di tutti i pacchetti, perché mancano le risorse per i controlli dell'intero codice sorgente; Debian beneficia, però, di quelli svolti dagli sviluppatori, in fase progettuale o da altri progetti come Linux Kernel Security Audit Project (progetto di controllo della sicurezza del kernel Linux), o Linux Security-Audit Project (progetto di controllo della sicurezza di Linux).

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

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, in mancanza del necessario controllo del codice. 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.


11.1.9 Chiunque può leggere certi file di log/configurazione: non è insicuro?

Naturalmente, nel proprio sistema, ognuno può cambiare i permessi predefiniti di Debian. Con l'attuale linea 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 (cioè i demoni ftp) sembrano imporre permessi differenti.


11.1.10 Perché /root/ (o User X) ha i permessi impostati a 755?

In effetti, l'identico problema riguarda qualunque altro utente. Siccome l'installazione di Debian non mette alcun file in quella cartella, non vi sono informazioni importanti da proteggere; se si ritiene che tali permessi siano troppo ampi per il sistema, li potete restringere a 750. Per gli utenti, leggete in Limitare l'accesso alle informazioni di altri utenti, Sezione 4.10.13.1.

Questo tema è trattato più ampiamente nella Debian security mailing list, gruppo di discussione sulla sicurezza, in questo thread.


11.1.11 Rimozione dei messaggi che arrivano in console dopo l'installazione di un grsec/firewall

Se si ricevono messaggi in console e si è configurato /etc/syslog.conf, in modo da trasmetterli a dei file o ad uno speciale TTY, potreste assistere alla spedizione di messaggi sulla console.

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

Per ridurre il numero di tali messaggi, si può usare dmesg [con l'opzione -n, vedete dmesg(8)]), che esamina e controlla il kernel ring buffer. Per regolarlo dal prossimo riavvio, cambiate /etc/init.d/klogd da:

       KLOGD=""

a:

       KLOGD="-c 4"

Usate un numero inferiore con -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       /* sistema fuori uso */
       #define LOG_ALERT       1       /* agire immediatamente */
       #define LOG_CRIT        2       /* condizioni critiche */
       #define LOG_ERR         3       /* condizioni di errore */
       #define LOG_WARNING     4       /* condizioni di allerta */
       #define LOG_NOTICE      5       /* condizioni normali ma importanti */
       #define LOG_INFO        6       /* semplice informativa */
       #define LOG_DEBUG       7       /* messaggio a livello-debug */

11.1.12 Utenti e gruppi del sistema operativo


11.1.12.1 Tutti gli utenti di sistema sono necessari?

Sì e no: Debian arriva con alcuni utenti predefiniti (user id - (UID) < 99 come descritto in Debian Policy (Linee guida di Debian) o /usr/share/doc/base-passwd/README) per semplificare l'installazione di servizi che richiedano l'attivazione con un appropriato utente/UID. Se non si intende installare nuovi servizi, si possono rimuovere in sicurezza quegli utenti che non possiedano file nel sistema e non attivino nessun servizio. In ogni caso, per assetto predefinito le UID da 0 a 99 sono riservate a Debian, quelle da 100 a 999 sono create dai pacchetti all'atto dell'installazione (e cancellate quando il pacchetto viene "epurato").

Per scoprire facilmente gli utenti che non possiedono file, è possibile eseguire (da root, dato che agli utenti comuni potrebbero mancare i permessi necessari per potere esaminare alcune cartelle "delicate") il seguente comando:

       cut -f 1 -d : /etc/passwd | \
       while read i; do find / -user "$i" | grep -q . && echo "$i"; done

Tali utenti sono forniti da base-passwd; per maggiori informazioni sulla loro gestione in Debian, consultate la documentazione del pacchetto. Gli utenti predefiniti (con gruppo corrispondente) sono:

Altri gruppi senza utenti associati:


11.1.12.2 Qual è la differenza fra i gruppi adm e staff?

Gli appartenenti al gruppo "adm" sono, di solito, amministratori ai quali i permessi del gruppo consentono la lettura dei log senza dare il comando su. Al gruppo "staff", invece, appartengono i coadiutori/amministratori novizi, cui è permesso di lavorare in /usr/local e di creare cartelle in /home.


11.1.13 Perché c'è un nuovo gruppo per ogni nuovo utente? (Ovvero: perché Debian dà un gruppo ad ogni utente?)

La linea di condotta di Debian assegna ad ogni utente un proprio gruppo. Il tradizionale schema UN*X assegna tutti gli utenti al gruppo users. Ulteriori gruppi sono creati e utilizzati per limitare l'accesso a file condivisi associati a cartelle di progetti diverse. Siccome, all'atto della creazione, i file sono 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 questa condotta: 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.


11.1.14 Domande riguardanti i servizi e le porte aperte


11.1.14.1 Perché in installazione vengono attivati tutti i servizi?

È soltanto un compromesso tra l'essere da un lato attenti alla sicurezza e dall'altro user-friendly. Diversamente da OpenBSD, che disabilita tutti i servizi a meno che non siano esplicitamente attivati dall'amministratore, Debian GNU/Linux attiva tutti i servizi installati a meno che non vengano disattivati (vedete in Disabilitare i servizi attivi in modalità demone, Sezione 3.6.1 per maggiori informazioni). Dopo tutto siete stati voi ad installare il servizio, o no?

Ci sono state molte discussioni sulle mailing list Debian (sia su debian-devel che su debian-security) riguardo a quale sia il miglior compromesso per un'installazione standard. Comunque, al momento della stesura (marzo 2002) non si è ancora arrivati ad un accordo.


11.1.14.2 Posso rimuovere inetd?

Inetd non è semplice da rimuovere poiché netbase dipende dal pacchetto che lo fornisce (netkit-inetd). Se lo volete rimuovere, potete o disabilitarlo (vedete in Disabilitare i servizi attivi in modalità demone, Sezione 3.6.1) o rimuovere il pacchetto utilizzando il pacchetto equivs.


11.1.14.3 Perché ho la porta 111 aperta?

La porta 111 è quella del sunrpc portmapper e viene installata in maniera predefinita come parte dell'installazione Debian poiché non c'è bisogno di sapere quando un programma utente potrebbe aver bisogno di RPC che funzionino correttamente. In ogni caso, si usa principalmente per l'NFS. Se non vi serve, rimuovetelo come e' spiegato in Disabilitare i servizi RPC, Sezione 5.13.


11.1.14.4 A cosa serve identd (porta 113) ?

Il servizio identd serve per l'autenticazione che identifica il proprietario di una specifica connessione TCP/IP al server remoto che accetta la connessione. Tipicamente, quando un utente si connette a un host remoto, l'inetd dell'host remoto manda una query alla porta 113 per ottenere informazioni sull'utente. Spesso viene usato per la posta, i server FTP e IRC e può essere usato anche per tracciare chi, degli utenti del vostro sistema, stia tentando di attaccare un sistema remoto.

C'è stata lunga polemica sulla sicurezza di identd (vedete gli archivi della mailing list). In generale, identd è più utile su un sistema multiutente che sulla workstation di un singolo utente. Se non lo utilizzate, disabilitatelo, in modo da non lasciare aperto un servizio verso l'esterno. Se decidete di filtrare con un firewall la porta identd, per favore utilizzate una politica di reject e non di deny, altrimenti una connessione al server che utilizzi identd si bloccherà finché non scade il timeout. Per consultare questioni riguardanti reject or deny.


11.1.14.5 Ho dei servizi che usano le porte 1 e 6, cosa sono e come posso rimuoverli?

Se avete lanciato netstat -an e vi ha restituito:

       Active Internet connections (servers and established)
       Proto Recv-Q Send-Q Local Address           Foreign Address         State
       PID/Program name
       raw        0      0 0.0.0.0:1               0.0.0.0:*               7
       -
       raw        0      0 0.0.0.0:6               0.0.0.0:*               7
       -

Non significa che stiate vedendo processi in ascolto sulle porte TCP/UDP 1 e 6. Infatti, state vedendo processi che ascoltano su un socket raw i protocolli 1 (ICMP) e 6 (TPC). Un tale comportamento è comune sia ai trojan che a certi IDS come iipl, iplogger e portsentry. Se avete questi pacchetti, rimuoveteli. Se no, provate un netsta -p (processo) per vedere quale processo stia facendo girare questi demoni in attesa di connessione.


11.1.14.6 Ho trovato la porta XYZ aperta, posso chiuderla?

Si, naturalmente. Le porte che lasciate aperte debbono essere concordi con le linee guida del vostro sito riguardanti i servizi pubblici disponibili per le altre reti. Controllate se vengono avviati da inetd (vedete in Disabilitare i servizi gestiti da inetd, Sezione 3.6.2), o da altri pacchetti installati e prendete le misure appropriate (es., configurate inetd, rimuovete il pacchetto, evitate di lanciarlo al boot).


11.1.14.7 Rimuovere dei servizi da /etc/services può aiutarmi a rendere sicura la mia macchina?

No, /etc/services fornisce solo una mappatura tra un nome virtuale ed un dato numero di porta. Rimuovere nomi da questo file (solitamente) non eviterà che questi servizi vengano lanciati. Alcuni demoni potrebbero non partire se /etc/services viene modificato, ma non è la norma. Per disabilitare correttamente il servizio, vedete in Disabilitare i servizi attivi in modalità demone, Sezione 3.6.1.


11.1.15 Problemi comuni di sicurezza


11.1.15.1 Ho dimenticato la password e non posso accedere al sistema!

I passi che dovete fare per sistemare questo dipende se avete o meno applicato quanto suggerito per limitare l'accesso a lilo e al BIOS del vostro sistema.

Se avete limitato entrambi, dovete disabilitare l'impostazione del BIOS che permette il boot solo dal disco rigido prima di procedere. Se avete dimenticato anche la password del BIOS, dovrete annullare il BIOS aprendo la macchina e rimuovendo la batteria del BIOS.

Una volta che avete abilitato il boot da CD-ROM o da dischetto, tentate i passi seguenti:

Questo eliminerà la password di root dimenticata, contenuta nel primo campo separato dai due punti dopo il nome dell'utente. Salvate il file, riavviate il sistema e effettuate il login di root usando una password vuota. Ricordate di annullare la password. Questo funzionerà, a meno che non abbiate configurato il sistema in maniera più attenta, cioè se non permettete agli utenti di avere password vuote o root di effettuare il login dalla console.

Se avete introdotto queste funzionalità, dovrete entrare nel sistema in modalità utente singolo. Se LILO è stato ristretto, dovrete eseguire lilo subito dopo il reset di root di sopra. Questo è abbastanza furbo poiché il vostro /etc/lilo.conf dovrà essere aggiustato alla directory radice (/) del sistema essendo un ramdisk e non un disco rigido reale.

Una volta che LILO è senza restrizioni, provate i seguenti:


11.1.16 Come configurare un servizio per i miei utenti senza dare loro una shell?

Per esempio, se voleste configurare un servizio di POP, non è necessario creare un utente per ogni user che dovrà accedervi. Sarebbe meglio configurare un sistema di autenticazione basato su directory, attraverso un sistema esterno (come Radius, LDAP o un database SQL). Appena installate l'appropriata liberia per PAM (libpam-radius-auth, libpam-ldap, libpam-pgsql o libpam-mysql), leggete la documentazione (per chi inizia, vedete in Autenticazione degli utenti: PAM, Sezione 4.10.1) e configurate il servizio PAM-abilitato affinché usi il sistema da voi scelto. Questo viene fatto modificando i file in /etc/pam.d/ per il vostro servizio e modificando la

      
       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 è di usare l'espressione where quando si configura 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 degli attributi dei servizi booleani, potrete usarli per abilitare o disabilitare i diversi servizi solamente inserendo la riga appropriata nei seguenti file:


11.2 Il mio sistema è vulnerabile! (Ne sei sicuro?)


11.2.1 Una scansione per la ricerca delle vulnerabilità mi dice che il mio sistema Debian è vulnerabile!

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 Avvisi di sicurezza Debian, Sezione 7.2) per eliminare false sicurezze, sempre se il tool che usate includa i riferimenti per CVE.


11.2.2 Ho notato traccia di un attacco nei miei log di sistema. Il mio sistema è compromesso?

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 Dopo la compromissione (reazione agli incidenti), Capitolo 10). Altresì, se avete visto dai log che un attacco è avvenuto, è possibile che il nostro sistema sia vulnerabile allo stesso tipo di attacco (un attaccante molto determinato può aver sfruttato molte altre falle di sicurezza).


11.2.3 Nei miei log ho trovato una strana linea "MARK": sono stato attaccato?

Dovete ricercare le seguenti linee 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 --

Questo non indica tutti i tipi di compromissione ed i cambi di utenze tra le release di Debian, cercando anche eventuali stranezze. Se il vostro sistema non supporta alti carichi di lavoro (oppure molti servizi attivi) queste linee possono apparire nei vostri log. Questo è un sintomo che il vostro demone syslogd funziona perfettamente. Da syslogd(8):

            -m intervallo
              I log  vengono  stampati da  syslogd  ad intervalli regolari.
     	 Il tempo di attesa tra due -- MARK -- è di 20 minuti. Questo
     	 comportamento  può  essere  cambiato usando  questa  opzione.
     	 Impostando l'intervallo a zero syslogd viene disattivato.

11.2.4 Ho trovato nei miei log un utente che può usare il comando "su": sono compromesso?

Dovete ricercare delle linee 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 linee sono presenti nei jobs di cron (solitamente si trovano in /etc/cron.daily/find oppure logrotate):

       $ grep 25 /etc/crontab
       25 6    * * *   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

11.2.5 Nei miei log ho trovato un possibile "SYN flooding":sono sotto attacco?

Se nei vostri log trovate delle linee 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 od i server di posta). Vi invito ad attivate nel vostro kernel l'opzione TCD syncookies, leggete in Configurare Syncookies, Sezione 4.17.1.1. Attenzione, comunque, come un attacco DoS può saturare la vostra rete voi 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.


11.2.6 Ho trovato strane sessioni di root nei miei log: sono compromesso?

Potreste vedere questo tipo di immissioni 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.


11.2.7 Ho subito un'intrusione, cosa devo fare?

Esistono diversi passaggi che potreste seguire in caso di intrusione:


11.2.8 Come posso tracciare un attacco?

Osservando i log (se non sono stati alterati), utilizzando sistemi di rilevamento intrusioni (vedete in Pianificare la ricerca di intrusi, Sezione 9.2), traceroute, whois e strumenti simili (inclusa analisi forense), potreste essere in grado di tracciare un attacco 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?


11.2.9 Il programma X in Debian è vulnerabile, cosa devo fare?

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

Se l'informazione non è stata resa nota, per favore, spedite un'e-mail per il pacchetto affetto dalla vulnerabilità, descrivendola dettagliatamente (mostrando il concetto di come dovrebbe essere il codice giusto) al team@security.debian.org. Il Security Team analizzerà la vostra segnalazione.


11.2.10 Il numero di versione di un pacchetto indica che sta girando una versione vulnerabile!

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.


11.2.11 Software specifico


11.2.11.1 proftpd è vulnerabile ad attacchi Denial of Service.

Aggiungere DenyFilter \*.*/ al vostro file di configurazione e per ulteriori informazioni vedete http://www.proftpd.org/critbugs.html.


11.2.11.2 Dopo l'installazione di portsentry ci sono molte porte aperte.

È solo il modo in cui funziona portsentry. Apre circa venti porte inutilizzate per rilevare i port scan.


11.3 Domande sul Security Team di Debian

Queste informazioni derivano dalla Debian Security FAQ. Includono informazioni fino al 19 novembre e rispondono ad alcune altre comuni domande fatte sulla mailing list debian-security.


11.3.1 Cos'è un Debian Security Advisory (DSA)?

Sono informazioni spedite dal Security Team di Debian (vedere sotto) riguardo alla scoperta e soluzione di una vulnerabilità trovata in un pacchetto disponibile con Debian GNU/Linux. I DSA firmati vengono spediti alle mailing list pubbliche (debian-security-announce) e postati sul sito Debian (sia in prima pagina che nell'area sicurezza.

I DSA includono informazioni sul pacchetto interessato, la falla di sicurezza scoperta e dove trovare il pacchetto aggiornato (e il suo MD5 sum).


11.3.2 La firma degli advisory Debian non viene verificata come corretta!

Molto probabilmente è un vostro problema. La lista debian-security-announce ha un filtro che permette ai soli messaggi con la firma corretta e provenienti da uno dei membri del Security Team di essere postati.

Probabilmente, qualche parte del vostro software di posta lo cambia lievemente, infrangendo così la firma. Assicuratevi che il vostro software non faccia nessuna codifica o decodifica MIME, o conversione dei tab in spazi.

Si conoscono software che si comportano così e sono fetchmail (con l'opzione mimedecode abilitata), formail (solo quello proveniente da procmail 3.14) ed evolution.


11.3.3 Com'è gestita la sicurezza in Debian?

Ogni volta che il Security Team riceve notifica di un incidente, uno o più membri controllano e valutano il suo impatto sulla release stabile di Debian (ossia se la rende vulnerabile o no). Se il nostro sistema è reso vulnerabile, lavoriamo per chiudere la falla. Il manutentore del pacchetto viene contattato, se non avesse già contattato lui il Security Team. Infine, il fix viene testato e vengono preparati nuovi pacchetti, che poi vengono ricompilati su tutte le architetture stabili e successivamente caricati sul sito. Dopo tutto ciò, viene pubblicato un advisory.


11.3.4 Perché rimaneggiate una vecchia versione di un dato pacchetto?

La più importante linea guida nel fare un nuovo pacchetto che risolva un problema di sicurezza è di fare quanti meno cambiamenti possibili. I nostri utenti e sviluppatori si dedicano a controllare l'esatto funzionamento di una release una volta che viene fatta e così qualsiasi cambiamento facciamo potrebbe teoricamente sconvolgere il sistema di qualcun'altro. Ciò è particolarmente vero nel caso delle librerie: vi assicuriamo di non farvi mai cambiare l'Application Program Interface (API) o Application Binary Interface (ABI), non importa quanto piccolo sia il cambiamento.

Questo significa che spostarsi verso una nuova versione non è una buona soluzione e che invece i cambiamenti rilevanti saranno implementati anche nelle vecchie versioni. Generalmente i manutentori delle nuove versioni sono lieti di aiutarvi, se ne aveste bisogno, altrimenti potrebbe essere d'aiuto anche il Security Team di Debian.

In alcuni casi non è possibile implementare un backport dei fix di sicurezza, per esempio quando grosse quantità di codice devono essere modificate o riscritte. Se succedesse, potrebbe essere necessario spostarci su una nuova versione ma questo non ha bisogno di un preventivo coordinamento con il Security Team.


11.3.5 Qual'è il codice di condotta secondo il quale un pacchetto corretto appare in security.debian.org?

Falle di sicurezza nella distribuzione stabile fanno sì che sicuramente appaia un pacchetto su security.debian.org. Altre cose no. Il problema, qui, non è la dimensione della falla. Di solito il Security Team prepara pacchetti insieme ai relativi manutentori. Posto che qualcuno (di fidato) tracci il problema e ricompili tutti i pacchetti necessari mandandoli al Security Team, anche delle correzioni di base delle falle di sicurezza finiranno su security.debian.org. Leggete oltre.


11.3.6 Il numero di versione di un pacchetto indica che ho ancora una versione vulnerabile!

Invece di aggiornare ad una nuova release, riportiamo le correzioni nella versione distribuita con la release stabile. Il motivo è quello di assicurarci che una release cambi il meno possibile e quindi le cose non cambino o smettano di funzionare improvvisamente come risultato di un security fix. Potete controllare se state usando una versione sicura del pacchetto guardando il changelog del pacchetto stesso, o confrontando il suo esatto numero di versione con quello indicato sul Debian Security Advisory.


11.3.7 Come viene gestita la sicurezza in testing ed unstable?

La risposta corta è: non lo è. Testing e Unstable cambiano rapidamente obbiettivi e il Security Team non ha le risorse necessarie per supportarli adeguatamente. Se desiderate avere un server sicuro (e stabile) siete vivamente incoraggiati ad utilizzare la stable. In ogni caso, gli addetti alla sicurezza cercheranno di risolvere i problemi di sicurezza nelle versioni testing e unstable dopo averli risulti nella versione stable.

In qualche caso, comunque, il ramo unstable mette le correzioni di sicurezza abbastanza velocemente, dal momento che queste correzioni sono disponibili più velocemente nelle nuove versioni (in quelle vecchie, come quelle del ramo stable, solitamente è necessario un aggiornamento di una versione meno recente).


11.3.8 Utilizzo una vecchia versione di Debian, è supportata dal Security Team di Debian?

No. Sfortunatamente, il Security Team di Debian non può prendersi cura sia della release stable (e non ufficialmente, anche della unstable) che delle release più vecchie. Comunque, ci si può aspettare aggiornamenti di sicurezza per un limitato periodo di tempo (usualmente diversi mesi) immediatamente dopo il rilascio di una nuova distribuzione Debian.


11.3.9 Perché non ci sono mirror ufficiali per security.debian.org?

Il proposito di security.debian.org è quello di rendere disponibili gli aggiornamenti di sicurezza il più velocemente e facilmente possibile. Mirror aggiungerebbero ulteriori, inutili complessità e potrebbero causare frustrazione se non fossero aggiornati.


11.3.10 Ho visto DSA 100 e DSA 102, che è successo a DSA 101?

Diversi venditori (principalmente di GNU/Linux, ma anche di eredi BSD) si coordinano gli avvisi di sicurezza per alcuni incidenti e concordano per un particolare momento in modo che tutti i venditori siano in grado di rilasciare un avviso nello stesso momento. Questo è stato deciso per non discriminare alcuni venditori che necessitano di più tempo (per esempio quando il venditore deve passare i pacchetti attraverso lenti test "QA" (accertamenti qualitativi) o devono fornire supporto a diverse architetture o distribuzioni di binari). Il nostro Security Team prepara l'avviso in anticipo. Ogni tanto, altri problemi di sicurezza devono essere trattati prima che l'avviso in attesa possa essere rilasciato, è per questo che vengono temporaneamente tralasciati uno o più numeri di avvisi.


11.3.11 Come si può contattare il Security Team?

Informazioni sulla sicurezza possono essere mandate a security@debian.org e sarà letta da ogni sviluppatore Debian. Se disponete di informazioni sensibili siete pregati di utilizzare team@security.debian.org in modo che solo i membri la leggano. Se volete, la email può essere crittografata con la Debian Security Contact key (key ID 0x363CCD95).


11.3.12 Quali sono le differenze tra security@debian.org e debian-security@lists.debian.org?

Quando si mandano messaggi a security@debian.org, questi sono inviati alla mailing list degli sviluppatori (debian-private). Tutti gli sviluppatori Debian sono iscritti a questa lista e gli interventi sono mantenuti privati (cioè non sono accessibili dal sito web pubblico). La mailing list pubblica, debian-security@lists.debian.org, è aperta a tutti coloro che si vogliono iscrivere ed esistono archivi per ricerche disponibili qui.


11.3.13 Come si può contribuire al Security Team di Debian?

In ogni caso, siete pregati di controllare ogni problema prima di riportarlo a ecurity@debian.org. Se ne siete in grado, fornite patch che aiutino ad accelerare la risoluzione del processo. Non inoltrate semplicemente le mail di Bugtraq, visto che vengono già ricevute. Fornire ulteriori informazioni, comunque, è sempre una buona idea.


11.3.14 Da chi e' composto il Security Team di Debian?

Il Security Team di Debian attualmente è composto da cinque membri e due segretari. Lo stesso Security Team incoraggia ad unirsi a loro.


11.3.15 Il Security Team di Debian controlla ogni nuovo pacchetto di Debian?

No, il Security Team di Debian non controlla ogni nuovo pacchetto e non c'è un controllo automatico (lintian) per scovare nuovi pacchetti maliziosi, poiché è pressoché impossibile effettuare questi controlli automaticamente. Comunque, i manutentori sono pienamente responsabili dei pacchetti che introducono in Debian e tutti i pacchetti vengono preventivamente firmati da uno o più sviluppatori autorizzati. Lo sviluppatore ha il compito di analizzare la sicurezza di tutti i pacchetti che mantiene.


11.3.16 Quanto occorrerà a Debian per correggere la vulnerabilità XXXX?

Il Security Team di Debian lavora velocemente per spedire advisories e produrre pacchetti corretti per il ramo stabile, una volta che una vulnerabilità è stata scoperta. Un rapporto pubblicato sulla mailing list debian-security ha mostrato come, nell'anno 2001, ci sia voluto al Security Team di Debian una media di 35 giorni per correggere vulnerabilità relative alla sicurezza. Comunque, più del 50% delle vulnerabilità sono state corrette nell'arco di 10 giorni e più del 15% di queste sono state corrette lo stesso giorno in cui è stato rilasciato l'advisory.

Comunque, nel porre la domanda, la gente tende a dimenticare che:

Se desideraste un'analisi più approfondita del tempo che ci vuole al Security Team per lavorare sulle vulnerabilità, dovreste prendere in considerazione il fatto che i nuovi DSA (vedete in Avvisi di sicurezza Debian, Sezione 7.2) pubblicati sul sito web relativo alla sicurezza e i metadata utilizzati per generarli, includono link a dei database di vulnerabilità. Potreste scaricare i sorgenti dal server web (dal CVS) o usare le pagine HTML per determinare il tempo che ci vuole a Debian per correggere vulnerabilità e sincronizzare questi dati con i database pubblici.


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

Securing Debian Manual

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

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