<chapt><heading>Domande frequenti (FAQ)</heading>

<p>
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!").</p>



<sect><heading>La sicurezza nel sistema operativo Debian</heading>



<sect1><heading>Debian  pi sicura di quella X?</heading>

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

<p>
Per una raccolta di dati sulle vulnerabilit della sicurezza in molti
sistemi operativi, vedete
<url id="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.

<footnote>
<p>Per esempio, stando ai dati di Securityfocus, sembrerebbe che Windows
NT sia pi sicuro di Linux; affermazione discutibile: in fondo, le
distribuzioni Linux offrono molti pi applicativi rispetto a Windows NT.
Questo problema del <em>conteggio delle vulnerabilit</em>
 meglio descritto nel
<url id="http://www.dwheeler.com/oss_fs_why.html#security" name="Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!">
di David A. Wheeler</p>
</footnote>.

Inoltre ricordate che alcune vulnerabilit di Debian scoperte da
Bugtraq riguardano solamente la distribuzione <em>unstable</em>.</p>


<sect2>
<heading>Debian  pi sicura di altre distribuzioni Linux (Red Hat, SuSe...)?</heading>

<p>
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.</p>

<p>
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 
<url id="http://www.cert.org/advisories/CA-2000-17.html" name="rpc.statd">,
un paio di anni fa.</p>

<p>
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 <url id="http://cert.org" name="CERT">. 
Ne consegue che
gli aggiornamenti necessari sono diffusi nello stesso momento e la relativa
sicurezza delle diverse distribuzioni  molto simile.</p>

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

<list>

<item>
<p>Rispetto ad altre distribuzioni, Debian offre maggiori strumenti per la
sicurezza, vedete in <ref id="sec-tools">.</p></item>
<item>
<p>L'installazione standard di Debian  pi leggera (minori funzionalit), ma
pi sicura. Altre distribuzioni, in nome dell'usabilit, tendono
all'installazione predefinita di molti servizi, talvolta non perfettamente
configurati - da ricordare i worm 
<url id="http://www.sans.org/y2k/lion.htm" name="Ramen o Lion ">. 
Non  un'installazione restrittiva come quella di Openbsd (nessun 
demone in modo predefinito attivo), ma  un buon compromesso. 

<footnote>
<p>Senza sminuire il fatto che alcune distribuzioni, come RedHat e Mandrake,
tengono conto della sicurezza nelle loro installazioni standard, facendo
scegliere all'utente i <em>profili di sicurezza</em>, o usando programmi di
configurazione guidata di <em>firewall personali</em>.</p>
</footnote></p></item>
<item>
<p>Debian documenta al meglio le pratiche di sicurezza, in scritti come questo.</p></item>

</list></p></sect2></sect1>


<sect1><heading>Bugtraq cita molti difetti di Debian:  forse molto vulnerabile?</heading>

<p>
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.</p>

<p>
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.</p>

<p>
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).</p></sect1>


<sect1><heading>Debian ha certificazioni di sicurezza?</heading>

<p>Risposta concisa: no.</p>

<p>
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!).</p></sect1>


<sect1><heading>Ci sono programmi per rendere Debian pi sicura?</heading>

<p>
S. <url id="http://www.bastille-unix.org" name="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 <package>bastille</package>.</p>

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


<sect1><heading>Ho necessit di rendere disponibile il servizio XYZ, come sceglierlo?</heading>

<p>
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:

<list>

<item>
<p>Il software continua a essere sviluppato? Quand' uscita l'ultima
versione?</p></item>
<item>
<p>Il pacchetto  obsoleto? Il numero di versione <em>non</em> ne indica 
l'et: cercate di tracciarne la storia.</p></item>
<item>
<p>Il programma  esente da difetti? Ci sono avvisi sulla sua sicurezza?</p></item>
<item>
<p>Il programma ha tutte le funzionalit cercate, o pi di quelle 
necessarie?</p></item>

</list></p></sect1>


<sect1><heading>Come rendere il servizio XYZ pi sicuro in Debian?
<!-- Changed to XYZ in order to avoid confusion :) jfs --></heading>

<p>
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).</p></sect1>


<sect1><heading>Come posso rimuovere tutte le etichette per i servizi?</heading>

<p>
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

<footnote>
<p>N.B.: ci significa "sicurezza tramite offuscamento" e a lungo 
termine, non paga.</p>
</footnote> 

a seconda del software eseguito. Per esempio, in <prgn>postfix</prgn> 
si pu impostare l'etichetta SMTP della cartella 
<file>/etc/postfix/main.cf</file>:

<example> 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) 
</example></p>

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


<sect1><heading>Sono sicuri tutti i pacchetti Debian?</heading>

<p>
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 
<url id="http://kernel-audit.sourceforge.net/" name="Linux Kernel Security Audit Project (progetto di controllo 
           della sicurezza del kernel Linux)">, o 
<url id="http://www.lsap.org/" name="Linux Security-Audit Project (progetto di controllo della 
           sicurezza di Linux)">.</p>

<p>
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 <em>"no guarantees"</em>.</p>

<p>
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.</p></sect1>


<sect1><heading>Chiunque pu leggere certi file di log/configurazione: non  insicuro?</heading>

<p>
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, <em>salvo che</em> contengano informazioni sensibili.</p>

<p>Si raccomanda prudenza, nel fare cambiamenti, dal momento che:

<list>

<item>
<p>Se si limitano i permessi, certi processi potrebbero non 
riuscire a scrivere sui file di log.</p></item>
<item>
<p>Alcune applicazioni potrebbero non funzionare se non fosse leggibile il
file di configurazione da cui dipendono. Per esempio, se si rimuove il
permesso di libera leggibilit per <file>/etc/samba/smb.conf</file>, 
il programma <prgn>smbclient</prgn> non funzioner, se attivato 
da un utente normale.</p></item>

</list></p>

<p>
FIXME: Controllare se questo sia scritto nella Policy: Alcuni pacchetti 
(cio i demoni ftp) sembrano imporre permessi differenti.</p></sect1>


<sect1><heading>Perch /root/ (o User X) ha i permessi impostati a 755?</heading>

<p>
In effetti, l'identico problema riguarda qualunque altro utente. 
Siccome l'installazione di Debian non mette <em>alcun</em> 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 
<ref id="limit-user-perm">.</p>

<p>
Questo tema  trattato pi ampiamente nella Debian security mailing list,
gruppo di discussione sulla sicurezza, in questo
<url id="http://lists.debian.org/debian-devel/2000/debian-devel-200011/msg00783.html" name="thread">.</p></sect1>


<sect1>
<heading>Rimozione dei messaggi che arrivano in console dopo l'installazione
di un grsec/firewall</heading>

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

<p>
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.</p>

<p>
Per ridurre il numero di tali messaggi, si pu usare <prgn>dmesg</prgn> 
[con l'opzione <tt>-n</tt>, vedete <manref name="dmesg" section="8">]), 
che esamina e <em>controlla</em> il kernel ring buffer. Per regolarlo 
dal prossimo riavvio, cambiate <file>/etc/init.d/klogd</file> da:

<example>
  KLOGD=""
</example></p>

<p>a:

<example>
  KLOGD="-c 4"
</example></p>

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

<example>
  #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 */
</example></p></sect1>


<sect1><heading>Utenti e gruppi del sistema operativo</heading>


<sect2><heading>Tutti gli utenti di sistema sono necessari?</heading>

<p>
S e no: Debian arriva con alcuni utenti predefiniti (user id - (UID)
&lt; 99 come descritto in <url id="http://www.debian.org/doc/debian-policy/" name="Debian Policy (Linee guida di Debian)"> o
<file>/usr/share/doc/base-passwd/README</file>) 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").</p>

<p>
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:

<!-- Took the liberty to make this script more secure ... >:^) // era -->

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

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


<list>

<item><p>root: Root  (tipicamente) il Superutente.</p></item>
<item>
<p>daemon: Alcuni demoni sprovvisti di privilegi di sorta che devono scrivere
su file sono attivi come daemon.daemon (per esempio, 
<prgn>portmap</prgn>, <prgn>atd</prgn> e probabilmente, altri), invece, 
i demoni che non hanno bisogno di possedere file possono attivarsi 
come nobody.nogroup, mentre altri, pi rispettosi della sicurezza, lo
fanno come utenti dedicati. Il demone utente  utile anche per i demoni 
installati localmente.</p></item>
<item><p>bin: Mantenuto per ragioni storiche.</p></item>
<item>
<p>sys: Idem come sopra; /dev/vcs* e <file>/var/spool/cups</file>, per,  
sono di propriet del gruppo sys.</p></item>
<item>
<p>sync: La shell dell'utente sync  <file>/bin/sync</file>, cos, se la 
sua parola d'ordine  semplice da indovinare (una cosa tipo ""), 
chiunque pu sincronizzare il sistema da console, anche senza avere un 
account.</p></item>
<item>
<p>games: Molti giochi sono impostati per il gruppo (SETGID) games , s da
poter scrivere file coi migliori punteggi. Spiegazione nelle Linee Guida.</p></item>
<item>
<p>man: Il programma man (a volte)  attivo come utente man, in modo da poter
scrivere pagine in <file>/var/cache/man</file>.</p></item>
<item><p>lp: Usato dai demoni di stampa.</p></item>
<item>
<p>mail: Le caselle in <file>/var/mail</file> appartengono al guppo mail, 
come esposto nelle Linee Guida. Utente e gruppo sono usati, ad 
altri fini, anche da vari MTA.</p></item>
<item>
<p>news: Diversi serventi di news ed altri programmi associati 
(come <prgn>suck</prgn>) impiegano l'utente e il gruppo in vari 
modi: spesso, i file nello spool news appartengono ad entrambi. 
Programmi come <prgn>inews</prgn>, usati per spedire news,
sono tipicamente impostati per il gruppo (SETGID) news.</p></item>
<item>
<p>uucp: L'utente e il gruppo UUCP sono usati dal sottosistema UUCP, cui
appartengono i file di spool e di configurazione. Gli utenti del gruppo 
uucp possono eseguire uucico.</p></item>
<item>
<p>proxy: Come demone, questo utente e gruppo possono essere usati da demoni
(di tipo proxy, in particolare) sprovvisti di utente dedicato ma
che debbono essere proprietari di quei file. Per esempio, il gruppo 
proxy  usato da <prgn>pdnsd</prgn>, mentre <prgn>squid</prgn>  
attivo come utente proxy.</p></item>
<item>
<p>majordom: Nei sistemi Debian, <prgn>Majordomo</prgn> aveva un UID 
allocato in modo statico, per ragioni storiche: non  installato nei nuovi.</p></item>
<item>
<p>postgres: I database <prgn>Postgresql</prgn> appartengono a questo 
utente e gruppo. Tutti i file di <file>/var/lib/postgresql</file> 
appartengono a questo utente per rafforzare la sicurezza.</p></item>
<item>
<p>www-data: Alcuni browser vengono eseguiti come www-data. Il contenuto
di rete *non* dovrebbe essere posseduto da questo utente, o un server
danneggiato potrebbe riscrivere un sito web. I dati restituiti da un
server web, file di log compresi, appartengono a www-data.</p></item>
<item>
<p>backup: cos, le responsabilit del ripristino/recupero possono essere
date, localmente, ad una persona che non abbia i pieni permessi di root.</p></item>
<item>
<p>operator: Storicamente (e praticamente) operator  il solo accredito "user"
che possa autenticarsi da remoto senza dipendere da NIS/NFS.</p></item>
<item>
<p>list: Gli archivi dei gruppi di discussione (mailing list) appartengono a
questo utente e gruppo; alcuni appositi programmi girano come utente list.</p></item>
<item>
<p>irc: Usato dai demoni irc. Un utente allocato staticamente occorre solo per
via di un baco in <prgn>ircd</prgn>, che all'avvio si imposta su 
di un dato utente.</p></item>
<item><p>gnats.</p></item>
<item>
<p>nobody.nogroup: Demoni cui non occorre nessun file si eseguono come utente e
gruppo nobody; in tal modo, nessun file nel sistema  di loro propriet.</p></item>

</list></p>

<p>Altri gruppi senza utenti associati:

<list>

<item>
<p>adm: Gruppo usato per compiti di monitoraggio del sistema, i suoi membri
possono leggere i file di log della cartella <file>/var/log</file> e 
usare xconsole. In passato, <file>/var/log</file> era <file>/usr/adm</file> 
(e poi, <file>/var/adm</file>), da cui il nome.</p></item>
<item>
<p>tty: Gruppo titolare dei dispositivi TTY (TeleTYpe, telescrivente), usati
come strumento di comunicazione per scrivere verso TTY altrui.</p></item>
<item>
<p>disk: Accesso "grezzo" ai dischi, per lo pi equivalente all'accesso come root.</p></item>
<item>
<p>kmem: Questo gruppo legge /dev/kmem e file similari:  principalmente una
reliquia di BSD, ma si possono impostare per esso (SETGID) quei programmi
che richiedano un accesso diretto, in lettura, alla memoria di sistema.</p></item>
<item>
<p>dialout: I suoi membri hanno pieno e diretto accesso alle porte seriali e
possono riconfigurare il modem, fare chiamate verso qualunque posto, ecc. ...</p></item>
<item>
<p>dip: Acronimo di "Dial-up IP", i suoi membri possono usare strumenti come
<prgn>ppp</prgn>, <prgn>dip</prgn>, <prgn>wvdial</prgn>, ecc. per 
avviare una connessione ed eseguire i programmi che utilizzano il 
modem, ma non possono configurarlo.</p></item>
<item><p>fax: Consente ai membri l'uso del fax in emissione/ricezione.</p></item>
<item>
<p>voice: Posta vocale, utile per sistemi che usano il modem come segreteria.</p></item>
<item>
<p>cdrom: Usato localmente per dare agli utenti un accesso all'unit CDROM.</p></item>
<item>
<p>floppy: Usato localmente per dare agli utenti un accesso all'unit floppy.</p></item>
<item>
<p>tape: Usato localmente per dare agli utenti un accesso alle unit nastro.</p></item>
<item>
<p>sudo: I membri di questo gruppo non devono digitare la password per usare
<prgn>sudo</prgn>. Vedete in <file>/usr/share/doc/sudo/OPTIONS</file>.</p></item>
<item>
<p>audio: Usato localmente per dare agli utenti l'accesso ai dispositivi audio.</p></item>
<item>
<p>src: Proprietario di codice sorgente, file in <file>/usr/src</file> compresi, 
 usato per dare agli utenti la facolt di gestire il codice sorgente 
presente sul sistema.</p></item>
<item>
<p>shadow: I programmi che necessitano di accedere al file 
<file>/etc/shadow</file>, devono avere impostato il SETGID per 
il gruppo shadow, che pu leggerlo.</p></item>
<item>
<p>utmp: Pu scrivere sul file <file>/var/run/utmp</file> e simili: 
programmi che devono poter scrivere su di esso, devono avere impostato il 
SETGID per il gruppo utmp.</p></item>
<item>
<p>video: Usato localmente per dare agli utenti l'accesso ai dispositivi video.</p></item>
<item>
<p>staff: Consente agli utenti modifiche locali del sistema (in 
<file>/usr/local</file>, <file>/home</file>) anche senza i privilegi 
di root. Lo si confronti con il gruppo "adm",  volto maggiormente a 
compiti di monitoraggio e sicurezza.</p></item>
<item>
<p>users: Mentre i sistemi Debian usano il sistema predefinito di creare un
gruppo personale per ogni utente, alcuni preferiscono un sistema di gruppi
pi tradizionale, in cui ogni utente sia membro del gruppo "users".</p></item>

</list></p></sect2>


<sect2><heading>Qual  la differenza fra i gruppi adm e staff?</heading>

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


<sect1>
<heading>Perch c' un nuovo gruppo per ogni nuovo utente? (Ovvero: perch Debian 
d un gruppo ad ogni utente?)</heading>

<p>
La linea di condotta di Debian assegna ad ogni utente un proprio gruppo.
Il tradizionale schema UN*X assegna tutti gli utenti al gruppo <em>users</em>.
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.</p>

<p>
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.</p>

<p>
Tuttavia, dando il valore "no" alla variabile <em>USERGROUPS</em>, nel file
<file>/etc/adduser.conf</file>, 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 
<em>USERS_GID</em> al GID cui tutti gli utenti appartengono.</p></sect1>


<sect1><heading>Domande riguardanti i servizi e le porte aperte</heading>


<sect2><heading>Perch in installazione vengono attivati tutti i servizi?</heading>

<p>
&Egrave; 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 <ref id="disableserv"> per maggiori
informazioni).
Dopo tutto siete stati voi ad installare il servizio, o no?</p>

<p>
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.</p></sect2>


<sect2><heading>Posso rimuovere <prgn>inetd</prgn>?</heading>

<p>
<prgn>Inetd</prgn> non  semplice da rimuovere poich 
<package>netbase</package> dipende dal pacchetto che lo fornisce 
(<package>netkit-inetd</package>). Se lo volete rimuovere, potete o
disabilitarlo (vedete in <ref id="disableserv">) o rimuovere il
pacchetto utilizzando il pacchetto <package>equivs</package>.</p></sect2>


<sect2><heading>Perch ho la porta 111 aperta?</heading>

<p>
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 <ref id="rpc">.</p></sect2>


<sect2><heading>A cosa serve <prgn>identd</prgn> (porta 113) ?</heading>

<p>
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'<prgn>inetd</prgn> 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.</p>

<p>
C' stata lunga polemica sulla sicurezza di <prgn>identd</prgn> (vedete 
gli  <url id="http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html" name="archivi della mailing list">).
In generale, <prgn>identd</prgn>  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, <em>per favore</em> utilizzate una politica di reject
e non di deny, altrimenti una connessione al server che utilizzi 
<prgn>identd</prgn> si bloccher finch non scade il timeout.
Per consultare questioni riguardanti 
<url id="http://logi.cc/linux/reject_or_deny.php3" name="reject or deny">.</p></sect2>


<sect2><heading>Ho dei servizi che usano le porte 1 e 6, cosa sono e come posso
rimuoverli?</heading>


<p>Se avete lanciato <tt>netstat -an</tt> e vi ha restituito:

<example>
  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
  -
</example></p>

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


<sect2><heading>Ho trovato la porta XYZ aperta, posso chiuderla?</heading>

<p>
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 <prgn>inetd</prgn> 
(vedete in <ref id="inetd">), o da altri pacchetti installati e
prendete le misure appropriate (es., configurate inetd, rimuovete il
pacchetto, evitate di lanciarlo al boot).</p></sect2>


<sect2>
<heading>Rimuovere dei servizi da <file>/etc/services</file> pu aiutarmi a rendere
sicura la mia macchina?</heading>

<p>
<em>No</em>, <file>/etc/services</file> 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 <file>/etc/services</file> 
viene modificato, ma non  la norma. Per disabilitare
correttamente il servizio, vedete in <ref id="disableserv">.</p></sect2></sect1>


<sect1><heading>Problemi comuni di sicurezza</heading>


<sect2><heading>Ho dimenticato la password e non posso accedere al sistema!</heading>

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

<p>
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.</p>

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

<list>

<item><p>Eseguite il boot da un disco di salvataggio e fate partire il kernel</p></item>
<item><p>Passate sulla console virtuale (Alt+F2)</p></item>
<item><p>Montate il disco dove risiede la partizione /root</p></item>
<item>
<p>Modificate (il disco di rescue di Debian 2.2 contiene l'editor
<prgn>ae</prgn> e Debian 3.0 con <prgn>nano-tiny</prgn> che  simile a 
<prgn>vi</prgn>) <file>/etc/shadow</file> e cambiate la linea:

<example>
  root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)
</example></p>

<p>in:

<example>
  root::XXXX:X:XXXX:X:::
</example></p></item>

</list></p>

<p>
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.</p>

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

<p>Una volta che LILO  senza restrizioni, provate i seguenti:

<list>

<item>
<p>Premete i tasti Alt, Shift o Control appena prima che il vostro
BIOS finisca, e dovreste ottenere un prompt di LILO.</p></item>
<item>
<p>Digitate <tt>linux single</tt>, <tt>linux init=/bin/sh</tt> o 
<tt>linux 1</tt> al prompt.</p></item>
<item>
<p>Questo vi dar un prompt di shell in modalit utente singolo, vi
chieder una password, ma la conoscete gi</p></item>
<item>
<p>Rimontate in lettura/scrittura la partizione di root (/), usando
il comando mount.

<example>
  # mount -o remount,rw / 
</example></p></item>

<item>
<p>Cambiate la password del superuser con <prgn>passwd</prgn> (poich 
siete il superuser non vi chieder la precedente).</p></item>

</list></p></sect2></sect1>


<sect1><heading>Come configurare un servizio per i miei utenti senza dare loro
una shell?</heading>

<p>
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 
(<package>libpam-radius-auth</package>, <package>libpam-ldap</package>,
<package>libpam-pgsql</package> o <package>libpam-mysql</package>),
leggete la documentazione (per chi inizia, vedete in <ref id="auth-pam">) 
e configurate il servizio PAM-abilitato affinch usi il sistema da 
voi scelto. Questo viene fatto modificando i file in 
<file>/etc/pam.d/</file> per il vostro servizio e modificando la

<example> 
  auth   required    pam_unix_auth.so shadow nullok use_first_pass 
</example> 
in, per esempio, ldap: 
<example>
  auth   required    pam_ldap.so 
</example>

<!-- FIXME: check if this i right (jfs) --></p>

<p>
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 <em>where</em> quando si configura il modulo PAM. 
Per esempio, se avete un database con i seguenti campi:

<example>
  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
</example></p>

<p>
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:

<list>

<item><p><file>/etc/pam.d/imap</file>:<tt>where=imap=1</tt>.</p></item>
<item><p><file>/etc/pam.d/qpopper</file>:<tt>where=pop=1</tt>.</p></item>
<item><p><file>/etc/nss-mysql*.conf</file>:<tt>users.where_clause =
user.sys = 1;</tt>.</p></item>
<item><p><file>/etc/proftpd.conf</file>:<tt> SQLWhereClause "ftp=1"</tt>.</p></item>

</list></p></sect1></sect>

<sect id="vulnerable-system"><heading>Il mio sistema  vulnerabile! (Ne sei sicuro?)</heading>


<sect1 id="vulnasses-false-positive"><heading>Una scansione per la ricerca 
delle vulnerabilit mi dice che il mio sistema Debian  vulnerabile!</heading>

<p>
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.</p>

<p>
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 <ref id="dsa">) per eliminare false 
sicurezze, sempre se il tool che usate includa i riferimenti per CVE.</p></sect1>


<sect1><heading>Ho notato traccia di un attacco nei miei log di sistema. Il mio
sistema  compromesso?</heading>

<p>
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
<ref id="after-compromise">).
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).</p></sect1>


<sect1><heading>Nei miei log ho trovato una strana linea "MARK": sono stato
attaccato?</heading>

<p>Dovete ricercare le seguenti linee nei vostri log di sistema:

<example>
  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --
</example></p>

<p>
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 <prgn>syslogd</prgn> 
funziona perfettamente. Da <manref name="syslogd" section="8">:

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

</example></p></sect1>

<sect1><heading>Ho trovato nei miei log un utente che pu usare il comando
"su": sono compromesso?</heading>

<p>Dovete ricercare delle linee simili alle seguenti nei vostri log:

<example>
  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)
</example></p>

<p>
Non preoccupatevi. Controllate se queste linee sono presenti nei 
jobs di <prgn>cron</prgn> (solitamente si trovano in 
<file>/etc/cron.daily/find</file> oppure <prgn>logrotate</prgn>):

<example>
  $ 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
</example></p></sect1>

<sect1><heading>Nei miei log ho trovato un possibile "SYN flooding":sono sotto attacco?</heading>

<p>Se nei vostri log trovate delle linee come le seguenti:

<example>
  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.
</example></p>

<p>
Controllate se sono presenti molte connessioni attive sul server
usando <prgn>netstat</prgn>, ad esempio:

<example>
  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000
</example></p>

<p>
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 <ref id="tcp-syncookies">.
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.</p></sect1>


<sect1><heading>Ho trovato strane sessioni di root nei miei log: sono compromesso?</heading>

<p>
Potreste vedere questo tipo di immissioni nel vostro file
<file>/var/log/auth.log</file>:

<example>
  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
</example></p>

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


<sect1><heading>Ho subito un'intrusione, cosa devo fare?</heading>

<p>Esistono diversi passaggi che potreste seguire in caso di intrusione:

<list>

<item>
<p>Controllare che il vostro sistema sia aggiornato con patch di sicurezza per
le vulnerabilit pubbliche. Se il sistema  vulnerabile, le possibilit che 
sia di fatto compromesso sono incrementate. Le possibilit aumentano ancora 
se la vulnerabilit  nota da tempo, dato che esiste solitamente pi 
attivit relativa alle vulnerabilit datate. Qui c' un link alle 
<url id="http://www.sans.org/top20.htm" name="20 maggiori vulnerabilit di sicurezza della SAN">.</p></item>
<item><p>Leggere questo documento, specialmente il <ref id="after-compromise">.</p></item>
<item>
<p>Chiedere assistenza. Potete usare la mailing list debian-security e 
chiedere consigli su come ripristinare/riparare il vostro sistema.</p></item>
<item>
<p>Segnalare al <url id="http://www.cert.org" name="CERT"> locale 
(se esiste, altrimenti potreste contattare il CERT direttamente). 
Questo potrebbe o non potrebbe aiutarvi ma, almeno, informa il 
CERT di attacchi in corso. Questa informazione  preziosa per
determinare quali strumenti e attacchi vengono utilizzati dalla 
comunit <em>blackhat</em>.</p></item>

</list></p></sect1>

<sect1><heading>Come posso tracciare un attacco?</heading>

<p>
Osservando i log (se non sono stati alterati), utilizzando sistemi di
rilevamento intrusioni (vedete in <ref id="intrusion-detect">),
<prgn>traceroute</prgn>, <prgn>whois</prgn> 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 <em>voi</em>
considerate un attacco. Uno scan remoto  un attacco? Un rilevamento di
vulnerabilit  un attacco?</p></sect1>


<sect1><heading>Il programma X in Debian  vulnerabile, cosa devo fare?</heading>

<p>
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 <url id="http://security.debian.org">.</p>

<p>
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 
<url id="mailto:team@security.debian.org" name="team@security.debian.org">.
Il Security Team analizzer la vostra segnalazione.</p></sect1>
 

<sect1><heading>Il numero di versione di un pacchetto indica che sta girando una
versione vulnerabile!</heading>

<p>
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.</p></sect1>


<sect1><heading>Software specifico</heading>

<sect2><heading><package>proftpd</package>  vulnerabile ad attacchi Denial of Service.</heading>

<p>
Aggiungere <tt>DenyFilter \*.*/</tt> al vostro file di configurazione 
e per ulteriori informazioni vedete 
<url id="http://www.proftpd.org/critbugs.html">.</p></sect2>


<sect2><heading>Dopo l'installazione di <package>portsentry</package> ci 
sono molte porte aperte.</heading>

<p>
&Egrave; solo il modo in cui funziona <prgn>portsentry</prgn>.
Apre circa venti porte inutilizzate per rilevare i port scan.</p></sect2></sect1></sect>


<sect id="debian-sec-team-faq"><heading>Domande sul Security Team di Debian</heading>

<p>
Queste informazioni derivano dalla 
<url id="http://www.debian.org/security/faq.en.html" name="Debian Security FAQ">. 
Includono informazioni fino al 19 novembre e rispondono ad alcune 
altre comuni domande fatte sulla mailing list debian-security.

<!-- FIXME: should this be included in the FAQ? --></p>


<sect1><heading>Cos' un Debian Security Advisory (DSA)?</heading>

<p>
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'<url id="http://www.debian.org/security/" name="area sicurezza">.</p>

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

<!-- FIXME: update from web page automatically --></p></sect1>



<sect1><heading>La firma degli advisory Debian non viene verificata come corretta!</heading>

<p>
Molto probabilmente  un vostro problema. La lista 
<url id="http://www.debian.org/security/faq.en.html" name="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.</p>

<p>
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.</p>

<p>
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.</p></sect1>


<sect1><heading>Com' gestita la sicurezza in Debian?</heading>

<p>
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.</p></sect1>



<sect1><heading>Perch rimaneggiate una vecchia versione di un dato pacchetto?</heading>

<p>
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.</p>

<p>
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.</p>

<p>
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.</p></sect1>


<sect1><heading>Qual' il codice di condotta secondo il quale un pacchetto corretto 
appare in security.debian.org?</heading>

<p>
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.</p></sect1>


<sect1><heading>Il numero di versione di un pacchetto indica che ho ancora una 
versione vulnerabile!</heading>

<p>
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.</p></sect1>


<sect1 id="sec-unstable"><heading>Come viene gestita la sicurezza in 
<tt>testing</tt> ed <tt>unstable</tt>?</heading>

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

<!-- Note: the following paragraph is not in the FAQ (jfs) --></p>

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

<!-- The following section is not on the FAQ --></p></sect1>


<sect1 id="sec-older"><heading>Utilizzo una vecchia versione di Debian, 
                       supportata dal Security Team di Debian?</heading>

<p>
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.</p></sect1>


<sect1><heading>Perch non ci sono mirror ufficiali per security.debian.org?</heading>

<p>
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.</p></sect1>

<sect1><heading>Ho visto DSA 100 e DSA 102, che  successo a DSA 101?</heading>

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

<!--
<p>In some cases, the Debian Security Team prepares advisories in
advance, and holds the advisory number until the advisory can be
released. Hence, the gaps in DSA numbers.
--></p></sect1>

<sect1><heading>Come si pu contattare il Security Team?</heading>

<p>
Informazioni sulla sicurezza possono essere mandate a
<url id="mailto:security@debian.org" name="security@debian.org"> e sar 
letta da ogni sviluppatore Debian. Se disponete di informazioni sensibili 
siete pregati di utilizzare 
<url id="mailto:team@security.debian.org" name="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 
<url id="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&amp;exact=on&amp;search=0x363CCD95" name="0x363CCD95">).</p></sect1>


<sect1><heading>Quali sono le differenze tra security@debian.org e
debian-security@lists.debian.org?</heading>

<p>
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 
<url id="http://www.debian.org/MailingLists/" name="iscrivere"> ed 
esistono archivi per ricerche disponibili 
<url id="http://lists.debian.org/search.html" name="qui">.

<!-- The following items are not included in the Debian Security Team FAQ --></p></sect1>


<sect1><heading>Come si pu contribuire al Security Team di Debian?</heading>

<p>
<list>

<item>
<p>Cotribuendo a questo documento, correggendo i vari FIXME o
fornendo nuovi contenuti. La documentazione  importante e riduce il
sovraccarico di rispondere a domande comuni. La traduzione di questa
documentazione in altre lingue  di grande aiuto.</p></item>
<item>
<p>Pacchettizzando applicazioni che sono utili per testare o
migliorare la sicurezza in un sistema  Debian GNU/Linux. Se siete
sviluppatori, riempite un 
<url id="http://www.debian.org/devel/wnpp/" name="WNPP bug">
richiedendo software che ritenete possa essere utile, ma che
attualmente non  disponibile in Debian.</p></item>
<item>
<p>Verificando le applicazioni in Debian, aiutando a risolvere
bug di sicurezza e riportando i problemi a security@debian.org. Il
lavoro di altri progetti come il 
<url id="http://kernel-audit.sourceforge.net/" name="Linux Kernel Security Audit Project"> o il 
<url id="http://www.lsap.org/" name="Linux Security-Audit Project">
incrementano la sicurezza di Debian GNU/Linux,
dal momento che i loro contributi aiuteranno probabilmente anche Debian.</p></item>

</list></p>

<p>
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.</p></sect1>


<sect1><heading>Da chi e' composto il Security Team di Debian?</heading>

<p>
Il Security Team di Debian attualmente  composto da cinque 
membri e due segretari. Lo stesso Security Team incoraggia 
ad unirsi a loro.</p></sect1>


<sect1><heading>Il Security Team di Debian controlla ogni nuovo pacchetto 
di Debian?</heading>

<p>
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.</p></sect1>


<sect1><heading>Quanto occorrer a Debian per correggere la vulnerabilit XXXX?</heading>

<p>
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 
<url id="http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257.html" name="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 <em>lo stesso giorno</em> in cui  
stato rilasciato l'advisory.</p>

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

<list>
<item><p>I DSA non vengono mandati finch:

<list>

<item>
<p>Sono disponibili pacchetti per <em>tutte</em> le architetture 
supportate da Debian (il che implica un po' di tempo per i 
pacchetti che sono parte del cuore del sistema, considerato poi 
il numero delle architetture supportate nella release stabile).</p></item>
<item>
<p>I nuovi pacchetti siano stati testati pi e pi volte, per 
assicurarsi che non siano stati introdotti dei nuovi bug.</p></item>

</list></p></item>

<item>
<p>I pacchetti potrebbero essere disponibili prima che sia 
mandato il DSA (in incoming o sui mirror).</p></item>
<item><p>Debian  un progetto basato sui volontari.</p></item>
<item><p>Debian viene distribuita con una clausola "senza garanzie".</p></item>

</list></p>

<p>
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 <ref id="dsa">) pubblicati sul sito web relativo 
alla <url id="http://security.debian.org" name="sicurezza"> e i 
metadata utilizzati per generarli, includono link a dei database 
di vulnerabilit. Potreste scaricare i sorgenti dal server web 
(dal <url id="http://cvs.debian.org" name="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.</p></sect1></sect></chapt>