12.1.1. Debian è più sicura di quella X?
A system is only as secure as its administrator is capable of making it. Debian's default installation of services aims to be secure, but may not be as paranoid as some other operating systems which install all services disabled by default. In any case, the system administrator needs to adapt the security of the system to the local security policy.
For a collection of data regarding security vulnerabilities for many operating systems, see the
http://www.cert.org/stats/cert_stats.html or generate stats using the
http://nvd.nist.gov/statistics.cfm (formerly ICAT) Is this data useful? There are several factors to consider when interpreting the data, and it is worth noticing that the data cannot be used to compare the vulnerabilities of one operating system versus another.
Also, keep in mind that some reported vulnerabilities regarding Debian apply only to the
unstable (i.e. unreleased) branch.
12.1.1.1. Debian è più sicura di altre distribuzioni Linux (Red Hat, SuSe...)?
Non ci sono davvero molte differenze fra le varie distribuzioni Linux, al di là dell'installazione di base e del sistema di gestione dei pacchetti; in genere, esse hanno in comune molti applicativi (ad esempio, il kernel, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc.), che si differenziano principalmente per la versione inclusa nella distribuzione stabile.
Red Hat è stata sfortunata nel rilasciare una versione contenente l'allora attuale foo 1.2.3., che aveva un difetto nella sicurezza, come si scoprì in un secondo momento; invece, Debian ha avuto miglior sorte nel rilasciare la propria con foo 1.2.4, in cui quel difetto era stato eliminato. L'identico caso si ripeté con
http://www.cert.org/advisories/CA-2000-17.html, un paio di anni fa.
Fra i gruppi per la sicurezza delle maggiori distribuzioni Linux c'è molta collaborazione: raramente un distributore trascura di sistemare gli aggiornamenti in materia di sicurezza e le cognizioni sulla sua vulnerabilità non vengono mai nascoste agli altri, dato che le correzioni vengono coordinate già in fase di sviluppo, oppure dal
http://cert.org. Ne consegue che gli aggiornamenti necessari vengono diffusi nello stesso momento e la relativa sicurezza delle diverse distribuzioni è molto simile.
Riguardo ad essa, uno dei maggiori vantaggi di Debian è il semplice sistema di aggiornamento mediante l'uso di
apt; ma ecco altri aspetti da considerare:
12.1.1.2. Bugtraq cita molti difetti di Debian: è forse molto vulnerabile?
La distribuzione Debian vanta un grande e crescente numero di pacchetti software, probabilmente più di quelli offerti da molti sistemi operativi proprietari. Maggiore è il numero dei pacchetti installati, maggiore il rischio di problemi di sicurezza in qualunque dato sistema.
Aumenta il numero di esaminatori del codice sorgente per cercare imperfezioni. Ci sono molti resoconti circa i controlli sul codice sorgente dei principali componenti software inclusi in Debian: qualora un controllo riveli dei difetti per la sicurezza, vi si ovvia e se ne manda un resoconto a liste come Bugtraq.
Di solito, i difetti presenti in Debian affliggono anche le altre distribuzioni. Controllate la sezione "Specifico di Debian: sì/no" all'inizio di ogni resoconto DSA (Debian Specific Advisory).
12.1.1.3. Debian ha certificazioni di sicurezza?
Risposta concisa: no.
Risposta lunga: la certificazione costa soldi (specialmente una certificazione di sicurezza
seria), nessuno ha dedicato le risorse allo scopo di certificare Debian GNU/Linux ad alcun livello come, ad esempio, il
http://niap.nist.gov/cc-scheme/st/. Se siete interessati ad avere una distribuzione GNU/Linux certificata in ambito sicurezza, provate a fornire prima di tutto le risorse per rendere possibile ciò.
12.1.1.4. Ci sono programmi per rendere Debian più sicura?
Yes.
http://bastille-linux.sourceforge.net/, originally oriented toward other Linux distributions (Red Hat and Mandrake), it currently works also for Debian. Steps are being taken to integrate the changes made to the upstream version into the Debian package, named
bastille.
Alcuni, tuttavia, ritengono che gli strumenti per avere maggiore sicurezza non possano eliminare l'esigenza di una buona amministrazione.
12.1.1.5. Ho necessità di rendere disponibile il servizio XYZ, come sceglierlo?
Un punto di forza di Debian è l'ampia varietà di scelta fra pacchetti che forniscono le stesse funzionalità (serventi di tipo DNS, ftp, di posta, 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:
Il software continua a essere sviluppato? Quand'è uscita l'ultima versione?
Il pacchetto è obsoleto? Il numero di versione non ne indica l'età: cercate di tracciarne la storia.
Il programma è esente da difetti? Ci sono avvisi sulla sua sicurezza?
Il programma ha tutte le funzionalità cercate? Ne ha addirittura più di quelle necessarie?
12.1.1.6. Come rendere il servizio XYZ più sicuro in Debian?
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).
12.1.1.7. Come posso rimuovere tutte le etichette per i servizi?
If you do not like users connecting to your POP3 daemon, for example, and retrieving information about your system, you might want to remove (or change) the banner the service shows to users.
Doing so depends on the software you are running for a given service. For example, in
postfix, you can set your SMTP banner in
/etc/postfix/main.cf:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
Other software is not as easy to change. ssh will need to be recompiled in order to change the version that it prints. Take care not to remove the first part (SSH-2.0) of the banner, which clients use to identify which protocol(s) is supported by your package.
12.1.1.8. Sono sicuri tutti i pacchetti Debian?
Il Team Debian per la Sicurezza non può analizzare i potenziali punti deboli di tutti i pacchetti, perché mancano le risorse per revisionare l'intero codice sorgente; Debian beneficia, però, delle revisioni svolte dagli sviluppatori.
In effetti, uno sviluppatore Debian potrebbe benissimo distribuire un virus di tipo trojan in un pacchetto, senza che venga scoperto: anche se esperti in un ramo di Debian, sarebbe impossibile trattare tutte le possibili situazioni in cui il trojan potrebbe agire. Perciò, Debian ha una licenza "no guarantees" (nessuna garanzia).
Tuttavia, gli utenti Debian possono fidare nel fatto che il codice stabile abbia un vasto pubblico: la maggior parte dei problemi si manifesterebbe con l'uso. In un sistema molto importante, non è indicato installare software che non sia stato sottoposto ad un processo di revisione del codice sorgente. In ogni caso, quand'anche nella distribuzione sia introdotta una vulnerabilità della sicurezza, il processo di inclusione dei pacchetti assicura la riconducibilità finale allo sviluppatore (mediante le firme digitali). Il progetto Debian non sottovaluta il problema.
12.1.1.9. Chiunque può leggere certi file di log/configurazione: non è insicuro?
Naturalmente, nel proprio sistema, ognuno può cambiare i permessi predefiniti di Debian. Con l'attuale codice di condotta sui file di log e configurazione, ognuno li può leggere, salvo che contengano informazioni sensibili.
Si raccomanda prudenza, nel fare cambiamenti, dal momento che:
Se si limitano i permessi, certi processi potrebbero non riuscire a scrivere sui file di log.
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 /etc/samba/smb.conf, il programma smbclient non funzionerà, se attivato da un comune utente.
FIXME: Controllare se questo sia scritto nella Policy. Alcuni pacchetti (ad esempio i demoni ftp) sembrano imporre permessi differenti.
12.1.1.10. Perché /root/ (o User X) ha i permessi impostati a 755?
In effetti, l'identico problema riguarda qualunque altro utente. Siccome l'installazione di Debian non mette
alcun file sotto quella directory, non vi sono informazioni importanti da proteggere; se ritenete che tali permessi siano troppo laschi per il sistema, li potete portare a 750. Per gli utenti, leggete in
Sezione 4.11.19.1, «Limitare l'accesso alle informazioni di altri utenti».
12.1.1.11. Rimozione dei messaggi che arrivano in console dopo l'installazione di un grsec/firewall
Se riceveste messaggi in console ed aveste configurato /etc/syslog.conf, in modo da trasmetterli a dei file o ad uno speciale TTY, potreste vedere i messaggi direttamente sulla console.
Per ogni kernel, il livello predefinito per la trasmissione dei messaggi di log è 7 e quelli con priorità inferiore appariranno in console. Di solito i firewall (il regno dei LOG) ed altri strumenti per la sicurezza registrano log con priorità inferiore, che, quindi, vengono spediti direttamente in console.
To reduce messages sent to the console, you can use
dmesg (
-n option, see
dmseg(8)), which examines and
controls the kernel ring buffer. To fix this after the next reboot, change
/etc/init.d/klogd from:
KLOGD=""
Usate un numero inferiore per
-c, se continuate a vederli; una descrizione dei vari livelli dei messaggi di log si trova in
/usr/include/sys/syslog.h:
#define LOG_EMERG 0 /* system is unusable */
#define LOG_ALERT 1 /* action must be taken immediately */
#define LOG_CRIT 2 /* critical conditions */
#define LOG_ERR 3 /* error conditions */
#define LOG_WARNING 4 /* warning conditions */
#define LOG_NOTICE 5 /* normal but significant condition */
#define LOG_INFO 6 /* informational */
#define LOG_DEBUG 7 /* debug-level messages */
12.1.1.12. Utenti e gruppi del sistema operativo
12.1.1.12.1. Tutti gli utenti di sistema sono necessari?
Yes and no. Debian comes with some predefined users (user id (UID) < 99 as described in
http://www.debian.org/doc/debian-policy/ or
/usr/share/doc/base-passwd/README) to ease the installation of some services that require that they run under an appropriate user/UID. If you do not intend to install new services, you can safely remove those users who do not own any files in your system and do not run any services. In any case, the default behavior is that UID's from 0 to 99 are reserved in Debian, and UID's from 100 to 999 are created by packages on install (and deleted when the package is purged).
Per scoprire facilmente gli utenti che non possiedono file, è possibile eseguire (da root, dato che agli utenti comuni potrebbero mancare i permessi necessari per potere esaminare alcune cartelle "delicate") il seguente comando
:
cut -f 1 -d : /etc/passwd | \
while read i; do find / -user "$i" | grep -q . || echo "$i"; done
These users are provided by
base-passwd. Look in its documentation for more information on how these users are handled in Debian. The list of default users (with a corresponding group) follows:
root: root è (tipicamente) il superutente.
daemon: alcuni demoni sprovvisti di privilegi di sorta che devono scrivere su file sono attivi come daemon.daemon (per esempio, portmap, atd 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.
bin: mantenuto per ragioni storiche.
sys: idem come sopra; /dev/vcs* e /var/spool/cups, però, sono di proprietà del gruppo sys.
sync: la shell dell'utente sync è /bin/sync, 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.
games: molti giochi vengono impostati per il gruppo (SETGID) games , sì da poter scrivere file coi migliori punteggi. Spiegazione nelle Linee Guida.
man: il programma man (a volte) è attivo come utente man, in modo da poter scrivere pagine in /var/cache/man.
lp: usato dai demoni di stampa.
mail: le caselle in /var/mail appartengono al gruppo mail, come descritto nelle Linee Guida. Utente e gruppo vengono usati, ad altri fini, anche da vari MTA.
news: diversi serventi di news ed altri programmi associati (come suck) impiegano l'utente ed il gruppo in vari modi: spesso, i file nello spool news appartengono ad entrambi. Programmi come inews, usati per spedire news, vengono tipicamente impostati per il gruppo (SETGID) news.
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.
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 pdnsd, mentre squid è attivo come utente proxy.
majordom: nei sistemi Debian, Majordomo aveva un UID allocato staticamente, per ragioni storiche, adesso non è più installato.
postgres: i database Postgresql appartengono a questo utente e gruppo. Tutti i file di /var/lib/postgresql appartengono a questo utente per rafforzare la sicurezza.
www-data: alcuni browser vengono eseguiti come www-data. Il contenuto di rete non 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.
backup: così, le responsabilità del ripristino/recupero possono essere date, localmente, ad una persona che non abbia i pieni permessi di root.
operator: storicamente (e praticamente) operator è il solo accredito a livello utente che possa autenticarsi da remoto senza dipendere da NIS/NFS.
list: gli archivi dei gruppi di discussione (mailing list) appartengono a questo utente e gruppo; alcuni appositi programmi girano come utente list.
irc: usato dai demoni irc. Un utente allocato staticamente occorre solo per via di un baco in ircd, che imposta con SETUID() un determinato UID all'avvio.
gnats.
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à.
Altri gruppi senza utenti associati:
adm: gruppo usato per compiti di monitoraggio del sistema, i suoi membri possono leggere i file di log della cartella /var/log e usare xconsole. Storicamente, /var/log era /usr/adm (e poi, /var/adm), da cui il nome del gruppo.
tty: gruppo titolare dei dispositivi TTY (TeleTYpe, telescrivente), usati come strumento di comunicazione per scrivere su TTY altrui.
disk: accesso "grezzo" ai dischi, perlopiù equivalente all'accesso come root.
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.
dialout: i suoi membri hanno pieno e diretto accesso alle porte seriali e possono riconfigurare il modem, fare chiamate verso qualunque posto, etc. ...
dip: acronimo di "Dial-up IP", i suoi membri possono usare strumenti come ppp, dip, wvdial, etc. per avviare una connessione ed eseguire i programmi che utilizzano il modem, ma non possono configurarlo.
fax: consente ai membri l'uso del fax in emissione/ricezione.
voice: posta vocale, utile per sistemi che usano il modem come segreteria.
cdrom: usato localmente per dare agli utenti un accesso all'unità CDROM.
floppy: usato localmente per dare agli utenti un accesso all'unità floppy.
tape: usato localmente per dare agli utenti un accesso alle unità a nastro.
sudo: i membri di questo gruppo non devono digitare la password per usare sudo. Vedete in /usr/share/doc/sudo/OPTIONS.
audio: usato localmente per dare agli utenti l'accesso ai dispositivi audio.
src: proprietario di codice sorgente, file in /usr/src compresi, viene usato per dare agli utenti la facoltà di gestire il codice sorgente presente sul sistema.
shadow: i programmi che necessitano di accedere al file /etc/shadow, devono avere impostato il SETGID per il gruppo shadow, che può leggerlo.
utmp: può scrivere sul file /var/run/utmp e simili: programmi che devono poter scrivere su di esso, devono avere impostato il SETGID per il gruppo utmp.
video: usato localmente per dare agli utenti l'accesso ai dispositivi video.
staff: consente agli utenti modifiche locali del sistema (in /usr/local, /home) anche senza i privilegi di root. Confrontatelo con il gruppo "adm", volto maggiormente a compiti di monitoraggio e sicurezza.
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".
12.1.1.12.2. Ho rimosso un utente di sistema! Come posso rimediare?
If you have removed a system user and have not made a backup of your password and group files you can try recovering from this issue using update-passwd (see update-passwd(8)).
12.1.1.12.3. Qual è la differenza fra i gruppi adm e staff?
Gli appartenenti al gruppo "adm" sono, di solito, amministratori ai quali i permessi del gruppo consentono la lettura dei log senza dare il comando su. Al gruppo "staff", invece, appartengono i coadiutori/amministratori novizi, cui è permesso di lavorare in /usr/local e di creare cartelle in /home.
12.1.1.13. Perché c'è un nuovo gruppo per ogni nuovo utente? (Ovvero: perché Debian assegna un gruppo ad ogni utente?)
La linea di condotta di Debian prevede di assegnare ad ogni utente un proprio gruppo. Il tradizionale schema UN*X assegna tutti gli utenti al gruppo users. Ulteriori gruppi vengono creati ed utilizzati per limitare l'accesso a file condivisi associati a cartelle di progetti diverse. Siccome, all'atto della creazione, i file vengono associati al gruppo di prima appartenenza dell'autore, la loro gestione diventa difficile, se l'utente lavora su più progetti.
Lo schema Debian risolve questo problema, assegnando ad ogni utente un gruppo personale, sicché, con una corretta umask (0002) e con il bit per l'assegnazione del gruppo (SETGID) impostato su una data cartella di progetto, il gruppo viene assegnato automaticamente ed i file vengono creati in quella cartella. Ciò agevola chi lavora su più progetti, evitandogli di cambiare gruppo o umask quando lavora su file condivisi.
Tuttavia, dando il valore "no" alla variabile USERGROUPS, nel file /etc/adduser.conf, si può cambiare questo comportamento. In tal modo, quando si crea un nuovo utente, non si crea anche un nuovo gruppo. Le stesse considerazioni valgono per l'impostazione di USERS_GID al GID cui tutti gli utenti appartengono.
12.1.1.14. Domande riguardanti i servizi e le porte aperte
12.1.1.14.1. Perché in installazione vengono attivati tutti i servizi?
È soltanto un compromesso tra l'essere da un lato attenti alla sicurezza e dall'altro user-friendly. Diversamente da OpenBSD, che disabilita tutti i servizi a meno che non siano esplicitamente attivati dall'amministratore, Debian GNU/Linux attiva tutti i servizi installati a meno che non vengano disattivati (vedete in
Sezione 3.5.1, «Disabilitare i servizi attivi in modalità demone» per maggiori informazioni). Dopo tutto siete stati voi ad installare il servizio, o no?
Ci sono state molte discussioni sulle mailing list Debian (sia su debian-devel che su debian-security) riguardo a quale sia il miglior compromesso per un'installazione standard. Comunque, al momento della stesura (marzo 2002) non si è ancora arrivati ad un accordo.
12.1.1.14.2. Posso rimuovere inetd?
12.1.1.14.3. Perché ho la porta 111 aperta?
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
Sezione 5.13, «Rendere sicuri i servizi RPC».
In versions of the portmap package later than 5-5 you can actually have the portmapper installed but listening only on localhost (by modifying /etc/default/portmap)
12.1.1.14.4. A cosa serve identd (porta 113) ?
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'inetd dell'host remoto manda una query alla porta 113 per ottenere informazioni sull'utente. Spesso viene usato per la posta, i server FTP e IRC e può essere usato anche per tracciare chi, degli utenti del vostro sistema, stia tentando di attaccare un sistema remoto.
There has been extensive discussion on the security of
identd (See
http://lists.debian.org/debian-security/2001/08/msg00297.html). In general,
identd is more helpful on a multi-user system than on a single user workstation. If you don't have a use for it, disable it, so that you are not leaving a service open to the outside world. If you decide to firewall the identd port,
please use a reject policy and not a deny policy, otherwise a connection to a server utilizing
identd will hang until a timeout expires (see
http://logi.cc/linux/reject_or_deny.php3).
12.1.1.14.5. Ho dei servizi che usano le porte 1 e 6, cosa sono e come posso rimuoverli?
Se avete lanciato
netstat -an e vi ha restituito:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
raw 0 0 0.0.0.0:1 0.0.0.0:* 7
-
raw 0 0 0.0.0.0:6 0.0.0.0:* 7
-
You are not seeing processes listening on TCP/UDP port 1 and 6. In fact, you are seeing a process listening on a raw socket for protocols 1 (ICMP) and 6 (TCP). Such behavior is common to both legitimate software like intrustion detection systems, such as iplogger and portsentry, but some trojans have also been known yo use them. If you have the mentioned packages simply remove them to close the port. If you do not, try netstat's -p (process) option to see which process is running these listeners.
12.1.1.14.6. Ho trovato la porta XYZ aperta, posso chiuderla?
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
inetd (vedete in
Sezione 3.5.2, «Disabilitare i servizi gestiti da inetd») o da altri pacchetti installati e prendete le misure appropriate (es., configurate inetd, rimuovete il pacchetto, evitate di lanciarlo al boot).
12.1.1.14.7. Rimuovere dei servizi da /etc/services può aiutarmi a rendere sicura la mia macchina?
No,
/etc/services fornisce solo una mappatura tra un nome virtuale ed un dato numero di porta. Rimuovere nomi da questo file (solitamente) non eviterà che questi servizi vengano lanciati. Alcuni demoni potrebbero non partire se
/etc/services viene modificato, ma non è la norma. Per disabilitare correttamente il servizio, vedete in
Sezione 3.5.1, «Disabilitare i servizi attivi in modalità demone».
12.1.1.15. Problemi comuni di sicurezza
12.1.1.15.1. Ho dimenticato la password e non posso accedere al sistema!
I passi che dovete fare per sistemare questo problema dipende dall'avere o meno applicato quanto suggerito per limitare l'accesso a lilo e al BIOS del vostro sistema.
Se avete limitato entrambi, dovete disabilitare l'impostazione del BIOS che permette il boot solo dal disco rigido prima di procedere. Se avete dimenticato anche la password del BIOS, dovrete annullare il BIOS aprendo la macchina e rimuovendo la batteria del BIOS.
Una volta che avete abilitato il boot da CD-ROM o da dischetto, tentate i passi seguenti:
Eseguite il boot da un disco di salvataggio e fate partire il kernel.
Passate sulla console virtuale (Alt+F2).
Montate il disco dove risiede la partizione /root.
Modificate (il disco di rescue di Debian 2.2 contiene l'editor
ae e Debian 3.0 con
nano-tiny che è simile a
vi)
/etc/shadow e cambiate la riga:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)
a:
root::XXXX:X:XXXX:X:::
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.
Se avete introdotto queste funzionalità, dovrete entrare nel sistema in modalità utente singolo. Se LILO è stato limitato, dovrete eseguire lilo subito dopo il reset di root di cui sopra. Questo è abbastanza furbo poiché il vostro /etc/lilo.conf dovrà essere configurato alla directory radice (/) del sistema essendo un ramdisk e non un disco rigido reale.
Una volta che LILO è senza restrizioni, provate i seguenti:
Premete i tasti Alt, Shift o Control appena prima che il vostro BIOS finisca, dovreste ottenere un prompt di LILO.
Digitate linux single, linux init=/bin/sh o linux 1 al prompt.
Questo vi farà ottenere un prompt di shell in modalità utente singolo e vi chiederà una password, ma la conoscete già.
Rimontate in lettura/scrittura la partizione di root (/), usando il comando mount:
# mount -o remount,rw /
Cambiate la password del superuser con passwd (poiché siete il superuser non vi chiederà la precedente).
12.1.1.16. Come configurare un servizio per i miei utenti senza dare loro una shell?
For example, if you want to set up a POP service, you don't need to set up a user account for each user accessing it. It's best to set up directory-based authentication through an external service (like Radius, LDAP or an SQL database). Just install the appropriate PAM library (
libpam-radius-auth,
libpam-ldap,
libpam-pgsql or
libpam-mysql), read the documentation (for starters, see
Sezione 4.11.1, «Autenticazione degli utenti: PAM») and configure the PAM-enabled service to use the back end you have chosen. This is done by editing the files under
/etc/pam.d/ for your service and modifying the
auth required pam_unix_auth.so shadow nullok use_first_pass
in, per esempio, ldap:
auth required pam_ldap.so
In caso di directory LDAP, alcuni servizi forniscono uno schema LDAP da includere nella directory allo scopo di usare l'autenticazione via LDAP. Se state usando un database relazionale, un trucco utile è usare l'espressione
where quando configurate il modulo PAM. Per esempio, se avete un database con i seguenti campi:
(user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
Prendendo i campi booleani degli attributi dei servizi, potrete usarli per abilitare o disabilitare i diversi servizi solamente inserendo la riga appropriata nei seguenti file:
/etc/pam.d/imap:where=imap=1.
/etc/pam.d/qpopper:where=pop=1.
/etc/nss-mysql*.conf:users.where_clause = user.sys = 1;.
/etc/proftpd.conf: SQLWhereClause "ftp=1".
12.1.2. Il mio sistema è vulnerabile! (Ne sei sicuro?)
12.1.2.1. Sa scansione per la ricerca delle vulnerabilità risulta che il mio sistema Debian è vulnerabile!
Molti scanner per ricercare vulnerabilità trovano falsi positivi, quando vengono usati in sistemi Debian, usano solamente il controllo di versione per determinare se un dato pacchetto sia vulnerabile, ma non ne testano la vulnerabilità. Poiché Debian non cambia la versione del software quando corregge un pacchetto (molte volte una correzione rilasciata recentemente pare una vecchia versione) molti programmi tendono a "pensare" che un sistema Debian aggiornato sia vulnerabile, invece è vero il contrario.
Se pensate che il vostro sistema sia sicuro usando le patch di sicurezza, vi invito ad incrociare i vostri riferimenti con il database sulla sicurezza pubblicato con il DSAs (leggete in
Sezione 7.2, «Avvisi di sicurezza Debian») per eliminare false sicurezze, sempre se il tool che usate include i riferimenti per CVE.
12.1.2.2. Ho notato traccia di un attacco nei miei log di sistema. Il mio sistema è compromesso?
Un traccia di attacco non significa necessariamente che il sistema sia stato compromesso, dovreste compiere i comuni passaggi per determinare se il sistema è stato realmente compromesso (leggete in
Capitolo 11, Dopo la compromissione (reazione agli incidenti)). Altresì, se avete visto dai log che è avvenuto un attacco, è possibile che il vostro sistema sia vulnerabile allo stesso tipo di attacco (un attaccante molto determinato può aver sfruttato molte altre falle di sicurezza).
12.1.2.3. Nei miei log ho trovato una strana riga "MARK": sono stato attaccato?
Dovete ricercare le seguenti righe nei vostri log di sistema:
Dec 30 07:33:36 debian -- MARK --
Dec 30 07:53:36 debian -- MARK --
Dec 30 08:13:36 debian -- MARK --
This does not indicate any kind of compromise, and users changing between Debian releases might find it strange. If your system does not have high loads (or many active services), these lines might appear throughout your logs. This is an indication that your
syslogd daemon is running properly. From
syslogd(8):
-m interval
The syslogd logs a mark timestamp regularly. The
default interval between two -- MARK -- lines is 20
minutes. This can be changed with this option.
Setting the interval to zero turns it off entirely.
12.1.2.4. Ho trovato nei miei log un utente che può usare il comando "su": sono compromesso?
Dovete ricercare delle righe simili alle seguenti nei vostri log:
Apr 1 09:25:01 server su[30315]: + ??? root-nobody
Apr 1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)
Non preoccupatevi. Controllate se queste righe sono presenti nei job di
cron (solitamente si trovano in
/etc/cron.daily/find oppure
logrotate):
$ grep 25 /etc/crontab
25 9 * * * root test -e /usr/sbin/anacron || run-parts --report
/etc/cron.daily
$ grep nobody /etc/cron.daily/*
find:cd / && updatedb --localuser=nobody 2>/dev/null
12.1.2.5. Nei miei log ho trovato un possibile "SYN flooding":sono sotto attacco?
Se nei vostri log trovate delle righe come le seguenti:
May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.
Controllate se sono presenti molte connessioni attive sul server usando
netstat, ad esempio:
linux:~# netstat -ant | grep SYN_RECV | wc -l
9000
Questo è un indice certo di un attacco denial of service (DoS) contro la porta X (molto spesso avvengono contro dei servizi pubblici come i server web o i server di posta). Vi invito ad attivare nel vostro kernel l'opzione TCD syncookies, leggete in
Sezione 4.18.2, «Configurare i Syncookies». Attenzione comunque, come un attacco DoS può saturare la vostra rete, al tempo stesso potete fermarlo mandando in crash il sistema (saturando i file descrittori, il sistema rimane inerte finché la connessione TCP non viene interrotta). Il solo modo efficace per fermare questo tipo di attacco è quello di contattare il vostro provider.
12.1.2.6. Ho trovato strane sessioni di root nei miei log: sono compromesso?
Potreste vedere queste righe nel vostro file
/var/log/auth.log:
May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
(UID=0)
May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root
Sono dovuti all'esecuzione di un processo cron (nell'esempio, ogni cinque minuti). Per stabilire quale programma è responsabile dei processi, controllare le immissioni sotto: /etc/crontab, /etc/cron.d, /etc/crond.daily ed il crontab di root sotto /var/spool/cron/crontabs.
12.1.2.7. Ho subito un'intrusione, cosa devo fare?
Esistono diversi passaggi che potreste seguire in caso di intrusione:
12.1.2.8. Come posso tracciare un attacco?
Osservando i log (se non sono stati alterati), utilizzando sistemi di rilevamento di intrusioni (vedete in
Sezione 10.3, «Pianificare la ricerca di intrusi»),
traceroute,
whois e strumenti simili (inclusa analisi forense), potreste essere in grado di tracciare un attacco fino alla fonte. Il modo in cui reagite a questa informazione dipende unicamente dalla vostra politica di sicurezza, e da cosa
voi considerate un attacco. Uno scan remoto è un attacco? Un rilevamento di vulnerabilità è un attacco?
12.1.2.9. Il programma X in Debian è vulnerabile, cosa devo fare?
Per prima cosa, controllate se la vulnerabilità è stata resa pubblica sulle mailing list di sicurezza (come Bugtraq) o altri forum. Il Team per la sicurezza di Debian si tiene in contatto con queste liste, quindi potrebbero essere a conoscenza del problema. Non procedete in modo diverso se vedete un annuncio su
http://security.debian.org, da quanto suggerito per correggere la vulnerabilità.
If no information seems to be published, please send e-mail about the affected package(s), as well as a detailed description of the vulnerability (proof of concept code is also OK), to
mailto:team@security.debian.org. This will get you in touch with Debian's security team.
12.1.2.10. Il numero di versione di un pacchetto indica che sta girando una versione vulnerabile!
Invece di aggiornare ad un nuovo rilascio, Debian riporta gli aggiornamenti di sicurezza alla versione che è stata distribuita con la versione stabile. Il motivo è assicurarsi che i rilasci stabili cambino il meno possibile, così che le cose non cambino o si interrompano inaspettatamente a causa di un aggiornamento di sicurezza. Potete controllare se sta girando una versione sicura di un pacchetto dal changelog package, o confrontando il numero di versione (versione corrente -slash- rilascio Debian) con la versione indicata nel Debian Security Advisory.
