<chapt>Domande frequenti (FAQ)

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



<sect>La sicurezza nel sistema operativo Debian



<sect1>Debian è più sicura di quella X?

<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 quella di altri sistemi operativi che installano tutti i
servizi <em>predefinitamente disabilitati</em>. Comunque, ogni
amministratore deve adattare la sicurezza del sistema alla politica
di sicurezza di dov'è impiegato.

<p>Per una raccolta di dati sulle vulnerabilità della sicurezza in molti
sistemi operativi, vedete
<url id="http://www.cert.org/stats/cert_stats.html" name="US-CERT stats">
o i dati del <url id="http://nvd.nist.gov/statistics.cfm" 
name="National Vulnerability Database"> (ex ICAT). Sono dati utili?
Vi sono 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>
          Per esempio, stando ad alcuni dati, 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.
</footnote>.

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




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

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

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

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

<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>Rispetto ad altre distribuzioni, Debian offre maggiori strumenti per la
sicurezza, vedete in <ref id="sec-tools">.
<item>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.sophos.com/virusinfo/analyses/linuxlion.html" name="Lion"> e
<url id="http://www.sophos.com/virusinfo/analyses/linuxramen.html" name="Ramen">.
Non è un'installazione restrittiva come quella di Openbsd (nessun
demone in modo predefinito attivo), ma è un buon compromesso<footnote>
    Senza sminuire il fatto che alcune distribuzioni, come Red Hat e
    Mandrake, tengono conto della sicurezza nelle loro installazioni
    standard, facendo scegliere all'utente i
    <em>profili per la sicurezza</em>, o usando programmi di
    configurazione guidata di <em>firewall personali</em>.
    </footnote>.
<item>Debian documenta al meglio le pratiche di sicurezza, in scritti come questo.

</list>


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

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


<sect1>Debian ha certificazioni di sicurezza?

<p>Risposta concisa: no.

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

<p>Attualmente ci sono almeno due distribuzioni Linux certificate a 
differenti livelli 
<url id="http://en.wikipedia.org/wiki/Evaluation_Assurance_Level" 
name="EAL">. Notate che alcuni dei test CC stanno per essere integrati 
nel <url id="http://ltp.sourceforge.net" name="Linux Testing Project"> 
che è disponibile in Debian nel pacchetto <package>ltp</package>.



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

<p>Sì. <url name="Bastille Linux" id="http://www.bastille-unix.org">, 
diretto, all'origine, ad
altre distribuzioni Linux (Red Hat e Mandrake), oggi funziona su Debian. Si
sta procedendo ad integrare i cambiamenti apportati sulla versione di sviluppo
nel pacchetto Debian chiamato <package>bastille</package>.

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


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

<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, web, etc.). Questo può confondere un
amministratore inesperto nel determinare il pacchetto più adatto alle
sue esigenze. La soluzione migliore dipende da un compromesso fra le
esigenze di funzionalità e quelle della sicurezza. Per decidere fra
pacchetti simili, bisogna rispondere ad alcune domande, come:

<list>

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

</list>


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

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



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

<p>Se non volete che gli utenti si connettano al vostro demone POP3, 
per esempio, ed ottengano informazioni sul sistema, probabilmente 
vorrete rimuovere (o cambiare) l'etichetta che quel servizio mostra 
all'utente<footnote>
          Notate bene, ciò significa "sicurezza tramite offuscamento"
          e a lungo termine, non paga.
</footnote> e questo dipende dal software che esegue quel servizio.
Per esempio, in <prgn>postfix</prgn>
potete impostare l'etichetta SMTP modificando il file
<file>/etc/postfix/main.cf</file>:

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

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


<sect1>Sono sicuri tutti i pacchetti Debian?

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

<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> (<em>nessuna 
garanzia</em>).

<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 che 
non sia stato sottoposto ad un processo di revisione del codice sorgente. 
In ogni caso, quand'anche nella distribuzione sia introdotta una vulnerabilità 
della sicurezza, il processo di inclusione dei pacchetti assicura la 
riconducibilità finale allo sviluppatore (mediante le firme digitali). Il 
progetto Debian non sottovaluta il problema.


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

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

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

<list>

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

</list>

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





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

<p>In effetti, l'identico problema riguarda qualunque altro utente. 
Siccome l'installazione di Debian non mette <em>alcun</em> file
sotto quella directory, non vi sono informazioni importanti da
proteggere; se ritenete che tali permessi siano troppo laschi per il 
sistema, li potete portare a 750. Per gli utenti, leggete in 
<ref id="limit-user-perm">.

<p>Questo tema viene 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">.


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

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

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

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

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

<p>Usate un numero inferiore per <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>



<sect1 id="faq-os-users">Utenti e gruppi del sistema operativo


<sect2>Tutti gli utenti di sistema sono necessari?

<p>Sì e no: Debian arriva con alcuni utenti predefiniti (user id - 
(UID) &lt; 99 come descritto nelle <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 intendete installare nuovi servizi, 
potete rimuovere in sicurezza quegli utenti che non possiedano 
file nel sistema e non attivino nessun servizio. In ogni caso, 
il comportamento predefinito del sistema prevede che le UID da 
0 a 99 vengano riservate a Debian, quelle da 100 a 999 vengano 
create dai pacchetti all'atto dell'installazione (e cancellate 
quando il pacchetto viene rimosso completamente).

<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<footnote>
      Attenzione, perché questo metterà in pericolo l'intero
      sistema. Se avete parecchio spazio disco e molte partizioni, 
      potreste voler ridurre il campo di applicazione.
</footnote>:


<!-- 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>Tali utenti vengono 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>root: root è (tipicamente) il superutente.
<item>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.
<item>bin: mantenuto per ragioni storiche.
<item>sys: idem come sopra; /dev/vcs* e <file>/var/spool/cups</file>, però,  
sono di proprietà del gruppo sys.
<item>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.
<item>games: molti giochi vengono impostati per il gruppo (SETGID) games , sì da
poter scrivere file coi migliori punteggi. Spiegazione nelle Linee Guida.
<item>man: il programma man (a volte) è attivo come utente man, in modo da poter
scrivere pagine in <file>/var/cache/man</file>.
<item>lp: usato dai demoni di stampa.
<item>mail: le caselle in <file>/var/mail</file> appartengono al gruppo mail,
come descritto nelle Linee Guida. Utente e gruppo vengono usati, ad
altri fini, anche da vari MTA.
<item>news: diversi serventi di news ed altri programmi associati
(come <prgn>suck</prgn>) impiegano l'utente ed il gruppo in vari
modi: spesso, i file nello spool news appartengono ad entrambi.
Programmi come <prgn>inews</prgn>, usati per spedire news,
vengono tipicamente impostati per il gruppo (SETGID) news.
<item>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.
<item>proxy: come demone, questo utente e gruppo possono essere usati
da alcuni 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.
<item>majordom: nei sistemi Debian, <prgn>Majordomo</prgn> aveva un UID
allocato staticamente, per ragioni storiche, adesso non è più installato.
<item>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.
<item>www-data: alcuni browser vengono eseguiti come www-data. Il contenuto
di rete <em>non</em> dovrebbe essere posseduto da questo utente, altrimenti 
un server compromesso potrebbe riscrivere un sito web. I dati restituiti da 
un server web, file di log compresi, appartengono a www-data.
<item>backup: così, le responsabilità del ripristino/recupero possono essere
date, localmente, ad una persona che non abbia i pieni permessi di root.
<item>operator: storicamente (e praticamente) operator è il solo accredito a
livello utente che possa autenticarsi da remoto senza dipendere da NIS/NFS.
<item>list: gli archivi dei gruppi di discussione (mailing list) appartengono a
questo utente e gruppo; alcuni appositi programmi girano come utente list.
<item>irc: usato dai demoni irc. Un utente allocato staticamente
occorre solo per via di un baco in <prgn>ircd</prgn>, che imposta con
SETUID() un determinato UID all'avvio.
<item>gnats.
<item>nobody.nogroup: demoni che non fanno uso di alcun file vengono
eseguiti come utente e gruppo nobody; in tal modo, nessun file nel
sistema è di loro proprietà.

</list>

<p>Altri gruppi senza utenti associati:

<list>

<item>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. Storicamente, <file>/var/log</file> era <file>/usr/adm</file> 
(e poi, <file>/var/adm</file>), da cui il nome del gruppo.
<item>tty: gruppo titolare dei dispositivi TTY (TeleTYpe, telescrivente), usati
come strumento di comunicazione per scrivere su TTY altrui.
<item>disk: accesso "grezzo" ai dischi, perlopiù equivalente all'accesso come root.
<item>kmem: questo gruppo legge /dev/kmem e file similari: è principalmente una
reliquia di BSD, ma se i programmi richiedono un accesso diretto, in 
lettura, alla memoria di sistema si può impostare kmem SETGID.
<item>dialout: i suoi membri hanno pieno e diretto accesso alle porte seriali e
possono riconfigurare il modem, fare chiamate verso qualunque posto, etc. ...
<item>dip: acronimo di "Dial-up IP", i suoi membri possono usare strumenti come
<prgn>ppp</prgn>, <prgn>dip</prgn>, <prgn>wvdial</prgn>, etc. per 
avviare una connessione ed eseguire i programmi che utilizzano il 
modem, ma non possono configurarlo.
<item>fax: consente ai membri l'uso del fax in emissione/ricezione.
<item>voice: posta vocale, utile per sistemi che usano il modem come segreteria.
<item>cdrom: usato localmente per dare agli utenti un accesso all'unità CDROM.
<item>floppy: usato localmente per dare agli utenti un accesso all'unità floppy.
<item>tape: usato localmente per dare agli utenti un accesso alle unità a nastro.
<item>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>.
<item>audio: usato localmente per dare agli utenti l'accesso ai dispositivi audio.
<item>src: proprietario di codice sorgente, file in 
<file>/usr/src</file> compresi, viene usato per dare agli utenti la 
facoltà di gestire il codice sorgente presente sul sistema.
<item>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.
<item>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.
<item>video: usato localmente per dare agli utenti l'accesso ai dispositivi video.
<item>staff: consente agli utenti modifiche locali del sistema (in 
<file>/usr/local</file>, <file>/home</file>) anche senza i privilegi 
di root. Confrontatelo con il gruppo "adm",  volto maggiormente a 
compiti di monitoraggio e sicurezza.
<item>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 è membro del gruppo "users".

</list>



<sect2>Ho rimosso un utente di sistema! Come posso rimediare?

<p>Se è stato rimosso un utente di sistema e non è stato fatto un
backup dei file <file>password</file> e <file>group</file>, potete
provare a rimediare a questo inconveniente usando il programma
<prgn>update-passwd</prgn> (consultate
<manref name="update-passwd" section="8">).



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

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


<sect1>Perché c'è un nuovo gruppo per ogni nuovo utente? (Ovvero: 
perché Debian assegna un gruppo ad ogni utente?)

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

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


<sect1>Domande riguardanti i servizi e le porte aperte


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

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


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

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


<sect2>Perché ho la porta 111 aperta?

<p>La porta 111 è quella del portmapper sunrpc e viene installata in
maniera predefinita come parte dell'installazione Debian poiché
non c'è bisogno di sapere quando un programma utente potrebbe
aver bisogno che l'RPC che funzioni correttamente.
In ogni caso, si usa principalmente per l'NFS, se non vi serve,
rimuovetelo com'è spiegato in <ref id="rpc">.

<p>Fino alle versioni 5-5 del pacchetto <package>portmap</package>
vi ritroverete il portmapper in ascolto, ma solo su localhost
(modificando <file>/etc/default/portmap</file>).


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

<p>Il servizio identd serve per l'autenticazione, che
tra l'altro 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>C'è stata una 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 o deny">.


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


<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><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. Altrimenti provate un <tt>netstat -p</tt> (processo)
per vedere quale processo stia facendo girare questi demoni in
attesa di connessione.


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

<p>Naturalmente! Le porte  che lasciate aperte debbono essere concordi con le
linee guida del vostro host per quanto riguarda 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).


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

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


<sect1>Problemi comuni di sicurezza


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

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

<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>Una volta che avete abilitato il boot da CD-ROM o da dischetto,
tentate i passi seguenti:

<list>

<item>Eseguite il boot da un disco di salvataggio e fate partire il kernel.
<item>Passate sulla console virtuale (Alt+F2).
<item>Montate il disco dove risiede la partizione /root.
<item>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 riga:

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

<p>in:

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

</list>

<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 ed effettuate il login da root usando una
password vuota. Ricordate di annullare la password. Questo funzionerà,
a meno che non abbiate configurato il sistema in maniera più attenta,
ovvero se avete impedito agli utenti di avere password vuote o a root
di effettuare il login dalla console.

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

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

<list>

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

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

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

</list>


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

<p>Per esempio, se voleste configurare un servizio POP, non è
necessario creare un utente per ogni utente che dovrà accedervi. 
Sarà meglio configurare un sistema di autenticazione basato su 
directory, attraverso un sistema esterno (come Radius, LDAP o un 
database SQL).
Appena installata l'appropriata libreria 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
riga

<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>In caso di directory LDAP, alcuni servizi forniscono uno schema LDAP
da includere nella directory allo scopo di usare l'autenticazione
via LDAP. Se state usando un database relazionale, un trucco utile è
usare l'espressione <em>where</em> quando configurate 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>Prendendo i campi booleani degli attributi dei servizi, potrete
usarli per abilitare o disabilitare i diversi servizi solamente
inserendo la riga appropriata nei seguenti file:

<list>

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

</list>

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


<sect1 id="vulnasses-false-positive">Sa scansione per la ricerca
delle vulnerabilità risulta che il mio sistema Debian è vulnerabile!

<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>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 include i riferimenti per CVE.


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

<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 è avvenuto un attacco, è possibile
che il vostro sistema sia vulnerabile allo stesso tipo di attacco
(un attaccante molto determinato può aver sfruttato molte altre
falle di sicurezza).


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

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

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

<p>Dovete ricercare delle righe 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>Non preoccupatevi. Controllate se queste righe sono presenti nei
job 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>

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

<p>Se nei vostri log trovate delle righe 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>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>Questo è un indice certo di un attacco denial of service (DoS)
contro la porta X (molto spesso avvengono contro dei servizi pubblici
come i server web o i server di posta).
Vi invito ad attivare nel vostro kernel l'opzione TCD syncookies,
leggete in <ref id="tcp-syncookies">.
Attenzione comunque, come un attacco DoS può saturare la vostra rete,
al tempo stesso potete fermarlo mandando in crash il sistema
(saturando i file descrittori, il sistema rimane inerte finché la
connessione TCP non viene interrotta).
Il solo modo efficace per fermare questo tipo di attacco è quello
di contattare il vostro provider.


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

<p>Potreste vedere queste righe 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>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>.


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

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

<list>

<item>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">.
<item>Leggere questo documento, specialmente il <ref id="after-compromise">.
<item>Chiedere assistenza. Potete usare la mailing list debian-security e 
chiedere consigli su come ripristinare/riparare il vostro sistema.
<item>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, informate il
CERT degli attacchi in corso. Questa informazione è preziosa per
determinare quali strumenti ed attacchi vengono utilizzati dalla
comunità <em>blackhat</em>.

</list>

<sect1>Come posso tracciare un attacco?

<p>Osservando i log (se non sono stati alterati), utilizzando sistemi di
rilevamento di 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 fino 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?


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

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

<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 Team Debian per la Sicurezza analizzerà la vostra segnalazione.


<sect1 id="version-backport">Il numero di versione di un pacchetto
indica che sta girando una versione vulnerabile!

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


<sect1>Software specifico

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

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


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

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


<sect id="debian-sec-team-faq">Domande sul Team per la sicurezza di Debian

<p>Queste informazioni derivano dalla 
<url id="http://www.debian.org/security/faq.en.html" name="Debian Security FAQ">. 
