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!").
Un sistema è sicuro in proporzione alla capacità del suo amministratore di renderlo tale. L'installazione predefinita di Debian mira alla sicurezza, ma può non essere paranoica come quelle di altri sistemi operativi che installano tutti i servizi predefinitamente esclusi. In ogni caso, ogni amministratore deve adattare la sicurezza del sistema alla politica di sicurezza di dov'è impiegato.
Per una raccolta di dati sulle vulnerabilità della sicurezza in molti sistemi
operativi, vedete http://securityfocus.com/vulns/stats.shtml
,
sito che elenca parecchi fattori di cui tenere conto nell'interpretazione dei
dati; notate che i medesimi dati non possono essere usati per confrontare le
vulnerabilità di sistemi operativi diversi. [35]. Inoltre ricordate che alcune vulnerabilità di Debian
scoperte da Bugtraq riguardano solamente la distribuzione unstable.
Non ci sono davvero molte differenze fra le varie distribuzioni Linux, al di là dell'installazione di base e del sistema di gestione dei pacchetti; in genere, esse hanno in comune molti applicativi (ad esempio, il kernel, Bind, Apache, OpenSSH, XFree, gcc, zlib, ecc.), che si differenziano principalmente per la versione inclusa nella distribuzione stabile.
RedHat è stata sfortunata nel rilasciare una versione contenente l'allora
attuale foo 1.2.3., che aveva un difetto nella sicurezza, come si scoprì in un
secondo momento; invece, Debian ha avuto miglior sorte nel rilasciare la
propria con foo 1.2.4.,in cui quel difetto era stato eliminato. L'identico
caso si ripeté con rpc.statd
, un
paio di anni fa.
Fra i gruppi della sicurezza delle maggiori distribuzioni Linux c'è molta
collaborazione: raramente un distributore trascura di sistemare gli
aggiornamenti in materia di sicurezza e le cognizioni sulla sua vulnerabilità
non vengono mai nascoste agli altri, dato che le correzioni sono coordinate già
in fase di sviluppo, oppure dal CERT
. Ne consegue che gli aggiornamenti
necessari sono diffusi nello stesso momento e la relativa sicurezza delle
diverse distribuzioni è molto simile.
Riguardo ad essa, uno dei maggiori vantaggi di Debian è il semplice sistema di
aggiornamento mediante l'uso di apt
; ma ecco altri aspetti da
considerare:
Ramen o
Lion
. Non è un'installazione restrittiva come quella di Openbsd
(nessun demone in modo predefinito attivo), ma è un buon compromesso. [36]
La distribuzione Debian vanta un grande e crescente numero di pacchetti software, probabilmente più di quelli offerti da molti sistemi operativi proprietari. Maggiore è il numero dei pacchetti installati, maggiore il rischio di problemi di sicurezza in qualunque dato sistema.
Aumenta il numero di esaminatori del codice sorgente per cercare imperfezioni. Ci sono molti resoconti circa i controlli sul codice sorgente dei principali componenti software inclusi in Debian: qualora un controllo riveli dei difetti per la sicurezza, vi si ovvia e se ne manda un resoconto a liste come Bugtraq.
Di solito, i difetti presenti in Debian affliggono anche le altre distribuzioni. Controllate la sezione "Specifico di Debian: sì/no" all'inizio di ogni resoconto DSA (Debian Specific Advisory).
Risposta concisa: no.
Risposta 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!).
Sì. Bastille Linux
,
diretto, all'origine, ad altre distribuzioni Linux (RedHat e Mandrake), oggi
funziona su Debian. Si sta procedendo a integrare i cambiamenti apportati
sulla versione di sviluppo nel pacchetto Debian chiamato bastille
.
Alcuni, tuttavia, ritengono che gli strumenti per avere maggiore sicurezza non possano eliminare l'esigenza di una buona amministrazione.
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:
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).
Se non si vuole che gli utenti si connettano ad un servizio ed ottengano
informazioni sul sistema, probabilmente vorrete rimuovere o cambiare
l'etichetta che quel servizio mostra all'utente [37] a seconda del software
eseguito. Per esempio, in postfix
si può impostare l'etichetta
SMTP della cartella /etc/postfix/main.cf
:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
Altro software non è così semplice a modificarsi. OpenSSH
richiederà una ricompilazione per modificare la versione mostrata; fate
attenzione a non rimuovere la prima parte dell'etichetta
(SSH-2.0), usata dai client per identificare il protocollo, ovvero
i protocolli, che il pacchetto supporta.
Il Security Team di Debian non può analizzare i potenziali punti deboli di
tutti i pacchetti, perché mancano le risorse per i controlli dell'intero codice
sorgente; Debian beneficia, però, di quelli svolti dagli sviluppatori, in fase
progettuale o da altri progetti come Linux Kernel Security Audit Project
(progetto di controllo della sicurezza del kernel Linux)
, o Linux Security-Audit Project (progetto di controllo
della sicurezza di Linux)
.
In effetti, uno sviluppatore Debian potrebbe benissimo distribuire un virus di tipo trojan in un pacchetto, senza che venga scoperto: anche se esperti in un ramo di Debian, sarebbe impossibile trattare tutte le possibili situazioni in cui il trojan potrebbe agire. Perciò, Debian ha una licenza "no guarantees".
Tuttavia, gli utenti Debian possono fidare nel fatto che il codice stabile abbia un vasto pubblico: la maggior parte dei problemi si manifesterebbe con l'uso. In un sistema molto importante, non è indicato installare software, in mancanza del necessario controllo del codice. In ogni caso, quand'anche nella distribuzione sia introdotta una vulnerabilità della sicurezza, il processo di inclusione dei pacchetti assicura la riconducibilità finale allo sviluppatore (mediante le firme digitali). Il progetto Debian non sottovaluta il problema.
Naturalmente, nel proprio sistema, ognuno può cambiare i permessi predefiniti di Debian. Con l'attuale linea di condotta sui file di log e configurazione, ognuno li può leggere, salvo che contengano informazioni sensibili.
Si raccomanda prudenza, nel fare cambiamenti, dal momento che:
/etc/samba/smb.conf
, il programma
smbclient
non funzionerà, se attivato da un utente normale.
FIXME: Controllare se questo sia scritto nella Policy: Alcuni pacchetti (cioè i demoni ftp) sembrano imporre permessi differenti.
In effetti, l'identico problema riguarda qualunque altro utente. Siccome l'installazione di Debian non mette alcun file in quella cartella, non vi sono informazioni importanti da proteggere; se si ritiene che tali permessi siano troppo ampi per il sistema, li potete restringere a 750. Per gli utenti, leggete in Limitare l'accesso alle informazioni di altri utenti, Sezione 4.10.13.1.
Questo tema è trattato più ampiamente nella Debian security mailing list,
gruppo di discussione sulla sicurezza, in questo thread
.
Se si ricevono messaggi in console e si è configurato
/etc/syslog.conf
, in modo da trasmetterli a dei file o ad uno
speciale TTY, potreste assistere alla spedizione di messaggi sulla console.
Per ogni kernel, il livello predefinito per la trasmissione dei messaggi di log è 7 (quindi, quelli con priorità inferiore appariranno in console). Di solito i firewall (il regno dei LOG) e altri accessori di sicurezza registrano log con priorità inferiore, che, quindi, sono spediti direttamente in console.
Per ridurre il numero di tali messaggi, si può usare dmesg
[con
l'opzione -n, vedete dmesg(8)
]), che esamina e
controlla il kernel ring buffer. Per regolarlo dal prossimo riavvio,
cambiate /etc/init.d/klogd
da:
KLOGD=""
a:
KLOGD="-c 4"
Usate un numero inferiore con -c, se continuate a vederli; una
descrizione dei vari livelli dei messaggi di log si trova in
/usr/include/sys/syslog.h
:
#define LOG_EMERG 0 /* sistema fuori uso */ #define LOG_ALERT 1 /* agire immediatamente */ #define LOG_CRIT 2 /* condizioni critiche */ #define LOG_ERR 3 /* condizioni di errore */ #define LOG_WARNING 4 /* condizioni di allerta */ #define LOG_NOTICE 5 /* condizioni normali ma importanti */ #define LOG_INFO 6 /* semplice informativa */ #define LOG_DEBUG 7 /* messaggio a livello-debug */
Sì e no: Debian arriva con alcuni utenti predefiniti (user id - (UID) < 99
come descritto in Debian Policy (Linee guida di
Debian)
o /usr/share/doc/base-passwd/README
) per
semplificare l'installazione di servizi che richiedano l'attivazione con un
appropriato utente/UID. Se non si intende installare nuovi servizi, si possono
rimuovere in sicurezza quegli utenti che non possiedano file nel sistema e non
attivino nessun servizio. In ogni caso, per assetto predefinito le UID da 0 a
99 sono riservate a Debian, quelle da 100 a 999 sono create dai pacchetti
all'atto dell'installazione (e cancellate quando il pacchetto viene
"epurato").
Per scoprire facilmente gli utenti che non possiedono file, è possibile eseguire (da root, dato che agli utenti comuni potrebbero mancare i permessi necessari per potere esaminare alcune cartelle "delicate") il seguente comando:
cut -f 1 -d : /etc/passwd | \ while read i; do find / -user "$i" | grep -q . && echo "$i"; done
Tali utenti sono forniti da base-passwd
; per maggiori informazioni
sulla loro gestione in Debian, consultate la documentazione del pacchetto. Gli
utenti predefiniti (con gruppo corrispondente) sono:
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.
/var/spool/cups
, però, sono di
proprietà del gruppo sys.
/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.
/var/cache/man
.
/var/mail
appartengono al guppo mail, come
esposto nelle Linee Guida. Utente e gruppo sono usati, ad altri fini, anche da
vari MTA.
suck
) impiegano l'utente e il gruppo in vari modi: spesso, i file
nello spool news appartengono ad entrambi. Programmi come inews
,
usati per spedire news, sono tipicamente impostati per il gruppo (SETGID) news.
pdnsd
, mentre squid
è attivo come utente proxy.
Majordomo
aveva un UID allocato in
modo statico, per ragioni storiche: non è installato nei nuovi.
Postgresql
appartengono a questo utente e
gruppo. Tutti i file di /var/lib/postgresql
appartengono a questo
utente per rafforzare la sicurezza.
ircd
, che all'avvio si imposta su di un dato
utente.
Altri gruppi senza utenti associati:
/var/log
e usare
xconsole. In passato, /var/log
era /usr/adm
(e poi,
/var/adm
), da cui il nome.
ppp
, dip
, wvdial
, ecc. per avviare
una connessione ed eseguire i programmi che utilizzano il modem, ma non possono
configurarlo.
sudo
. Vedete in /usr/share/doc/sudo/OPTIONS
.
/usr/src
compresi, è
usato per dare agli utenti la facoltà di gestire il codice sorgente presente
sul sistema.
/etc/shadow
, devono avere impostato il SETGID per il gruppo
shadow, che può leggerlo.
/var/run/utmp
e simili: programmi che
devono poter scrivere su di esso, devono avere impostato il SETGID per il
gruppo utmp.
/usr/local
, /home
) anche senza i privilegi di root.
Lo si confronti con il gruppo "adm", volto maggiormente a compiti di
monitoraggio e sicurezza.
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
.
La linea di condotta di Debian assegna ad ogni utente un proprio gruppo. Il tradizionale schema UN*X assegna tutti gli utenti al gruppo users. Ulteriori gruppi sono creati e utilizzati per limitare l'accesso a file condivisi associati a cartelle di progetti diverse. Siccome, all'atto della creazione, i file sono associati al gruppo di prima appartenenza dell'autore, la loro gestione diventa difficile, se l'utente lavora su più progetti.
Lo schema Debian risolve questo problema, assegnando ad ogni utente un gruppo personale, sicché, con una corretta umask (0002) e con il bit per l'assegnazione del gruppo (SETGID) impostato su una data cartella di progetto, il gruppo viene assegnato automaticamente ed i file vengono creati in quella cartella. Ciò agevola chi lavora su più progetti, evitandogli di cambiare gruppo o umask quando lavora su file condivisi.
Tuttavia, dando il valore "no" alla variabile USERGROUPS,
nel file /etc/adduser.conf
, si può cambiare questa condotta: in
tal modo, quando si crea un nuovo utente, non si crea anche un nuovo gruppo.
Le stesse considerazioni valgono per l'impostazione di USERS_GID al
GID cui tutti gli utenti appartengono.
È soltanto un compromesso tra l'essere da un lato attenti alla sicurezza e dall'altro user-friendly. Diversamente da OpenBSD, che disabilita tutti i servizi a meno che non siano esplicitamente attivati dall'amministratore, Debian GNU/Linux attiva tutti i servizi installati a meno che non vengano disattivati (vedete in Disabilitare i servizi attivi in modalità demone, Sezione 3.6.1 per maggiori informazioni). Dopo tutto siete stati voi ad installare il servizio, o no?
Ci sono state molte discussioni sulle mailing list Debian (sia su debian-devel che su debian-security) riguardo a quale sia il miglior compromesso per un'installazione standard. Comunque, al momento della stesura (marzo 2002) non si è ancora arrivati ad un accordo.
inetd
?
Inetd
non è semplice da rimuovere poiché netbase
dipende dal pacchetto che lo fornisce (netkit-inetd
). Se lo
volete rimuovere, potete o disabilitarlo (vedete in Disabilitare i servizi attivi in modalità
demone, Sezione 3.6.1) o rimuovere il pacchetto utilizzando il pacchetto
equivs
.
La porta 111 è quella del sunrpc portmapper e viene installata in maniera predefinita come parte dell'installazione Debian poiché non c'è bisogno di sapere quando un programma utente potrebbe aver bisogno di RPC che funzionino correttamente. In ogni caso, si usa principalmente per l'NFS. Se non vi serve, rimuovetelo come e' spiegato in Disabilitare i servizi RPC, Sezione 5.13.
identd
(porta 113) ?
Il servizio identd serve per l'autenticazione che identifica il proprietario di
una specifica connessione TCP/IP al server remoto che accetta la connessione.
Tipicamente, quando un utente si connette a un host remoto,
l'inetd
dell'host remoto manda una query alla porta 113 per
ottenere informazioni sull'utente. Spesso viene usato per la posta, i server
FTP e IRC e può essere usato anche per tracciare chi, degli utenti del vostro
sistema, stia tentando di attaccare un sistema remoto.
C'è stata lunga polemica sulla sicurezza di identd
(vedete gli
archivi
della mailing list
). In generale, identd
è più utile
su un sistema multiutente che sulla workstation di un singolo utente. Se non
lo utilizzate, disabilitatelo, in modo da non lasciare aperto un servizio verso
l'esterno. Se decidete di filtrare con un firewall la porta identd, per
favore utilizzate una politica di reject e non di deny, altrimenti una
connessione al server che utilizzi identd
si bloccherà finché non
scade il timeout. Per consultare questioni riguardanti reject or deny
.
Se avete lanciato netstat -an e vi ha restituito:
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name raw 0 0 0.0.0.0:1 0.0.0.0:* 7 - raw 0 0 0.0.0.0:6 0.0.0.0:* 7 -
Non significa che stiate vedendo processi in ascolto sulle porte
TCP/UDP 1 e 6. Infatti, state vedendo processi che ascoltano su un socket
raw i protocolli 1 (ICMP) e 6 (TPC). Un tale comportamento è comune
sia ai trojan che a certi IDS come iipl
, iplogger
e
portsentry
. Se avete questi pacchetti, rimuoveteli. Se no,
provate un netsta -p (processo) per vedere quale processo stia
facendo girare questi demoni in attesa di connessione.
Si, naturalmente. Le porte che lasciate aperte debbono essere concordi con le
linee guida del vostro sito riguardanti i servizi pubblici disponibili per le
altre reti. Controllate se vengono avviati da inetd
(vedete in Disabilitare i servizi gestiti da
inetd
, Sezione 3.6.2), o da altri pacchetti installati e
prendete le misure appropriate (es., configurate inetd, rimuovete il pacchetto,
evitate di lanciarlo al boot).
/etc/services
può aiutarmi a rendere sicura la mia macchina?
No, /etc/services
fornisce solo una mappatura tra un nome
virtuale ed un dato numero di porta. Rimuovere nomi da questo file
(solitamente) non eviterà che questi servizi vengano lanciati. Alcuni demoni
potrebbero non partire se /etc/services
viene modificato, ma non è
la norma. Per disabilitare correttamente il servizio, vedete in Disabilitare i servizi attivi in modalità
demone, Sezione 3.6.1.
I passi che dovete fare per sistemare questo dipende se avete o meno applicato
quanto suggerito per limitare l'accesso a lilo
e al BIOS del
vostro sistema.
Se avete limitato entrambi, dovete disabilitare l'impostazione del BIOS che permette il boot solo dal disco rigido prima di procedere. Se avete dimenticato anche la password del BIOS, dovrete annullare il BIOS aprendo la macchina e rimuovendo la batteria del BIOS.
Una volta che avete abilitato il boot da CD-ROM o da dischetto, tentate i passi seguenti:
ae
e Debian 3.0 con nano-tiny
che è simile a vi
)
/etc/shadow
e cambiate la linea:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)
in:
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 e effettuate il login di root usando una password vuota. Ricordate di annullare la password. Questo funzionerà, a meno che non abbiate configurato il sistema in maniera più attenta, cioè se non permettete agli utenti di avere password vuote o root di effettuare il login dalla console.
Se avete introdotto queste funzionalità, dovrete entrare nel sistema in
modalità utente singolo. Se LILO è stato ristretto, dovrete eseguire
lilo
subito dopo il reset di root di sopra. Questo è abbastanza
furbo poiché il vostro /etc/lilo.conf
dovrà essere aggiustato alla
directory radice (/) del sistema essendo un ramdisk e non un disco rigido
reale.
Una volta che LILO è senza restrizioni, provate i seguenti:
# mount -o remount,rw /
passwd
(poiché siete il
superuser non vi chiederà la precedente).
Per esempio, se voleste configurare un servizio di POP, non è necessario creare
un utente per ogni user che dovrà accedervi. Sarebbe meglio configurare un
sistema di autenticazione basato su directory, attraverso un sistema esterno
(come Radius, LDAP o un database SQL). Appena installate l'appropriata liberia
per PAM (libpam-radius-auth
, libpam-ldap
,
libpam-pgsql
o libpam-mysql
), leggete la
documentazione (per chi inizia, vedete in Autenticazione degli utenti: PAM, Sezione
4.10.1) e configurate il servizio PAM-abilitato affinché usi il sistema da
voi scelto. Questo viene fatto modificando i file in /etc/pam.d/
per il vostro servizio e modificando la
auth required pam_unix_auth.so shadow nullok use_first_pass
in, per esempio, ldap:
auth required pam_ldap.so
In caso di directory LDAP, alcuni servizi forniscono uno schema LDAP da includere nella directory allo scopo di usare l'autenticazione via LDAP. Se state usando un database relazionale, un trucco utile è di usare l'espressione where quando si configura il modulo PAM. Per esempio, se avete un database con i seguenti campi:
(user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
Prendendo i campi degli attributi dei servizi booleani, potrete usarli per abilitare o disabilitare i diversi servizi solamente inserendo la riga appropriata nei seguenti file:
/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".
Molti scanner per ricercare vulnerabilità trovano falsi positivi, quando vengono usati in sistemi Debian, usano solamente il controllo di versione per determinare se un dato pacchetto sia vulnerabile, ma non ne testano la vulnerabilità. Poiché Debian non cambia la versione del software quando corregge un pacchetto (molte volte una correzione rilasciata recentemente pare una vecchia versione) molti programmi tendono a "pensare" che un sistema Debian aggiornato sia vulnerabile, invece è vero il contrario.
Se pensate che il vostro sistema sia sicuro usando le patch di sicurezza, vi invito ad incrociare i vostri riferimenti con il database sulla sicurezza pubblicato con il DSAs (leggete in Avvisi di sicurezza Debian, Sezione 7.2) per eliminare false sicurezze, sempre se il tool che usate includa i riferimenti per CVE.
Un traccia di attacco non significa necessariamente che il sistema sia stato compromesso, dovreste compiere i comuni passaggi per determinare se il sistema è stato realmente compromesso (leggete in Dopo la compromissione (reazione agli incidenti), Capitolo 10). Altresì, se avete visto dai log che un attacco è avvenuto, è possibile che il nostro sistema sia vulnerabile allo stesso tipo di attacco (un attaccante molto determinato può aver sfruttato molte altre falle di sicurezza).
Dovete ricercare le seguenti linee nei vostri log di sistema:
Dec 30 07:33:36 debian -- MARK -- Dec 30 07:53:36 debian -- MARK -- Dec 30 08:13:36 debian -- MARK --
Questo non indica tutti i tipi di compromissione ed i cambi di utenze tra le
release di Debian, cercando anche eventuali stranezze. Se il vostro sistema
non supporta alti carichi di lavoro (oppure molti servizi attivi) queste linee
possono apparire nei vostri log. Questo è un sintomo che il vostro demone
syslogd
funziona perfettamente. Da syslogd(8)
:
-m intervallo I log vengono stampati da syslogd ad intervalli regolari. Il tempo di attesa tra due -- MARK -- è di 20 minuti. Questo comportamento può essere cambiato usando questa opzione. Impostando l'intervallo a zero syslogd viene disattivato.
Dovete ricercare delle linee simili alle seguenti nei vostri log:
Apr 1 09:25:01 server su[30315]: + ??? root-nobody Apr 1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)
Non preoccupatevi. Controllate se queste linee sono presenti nei jobs di
cron
(solitamente si trovano in /etc/cron.daily/find
oppure logrotate
):
$ grep 25 /etc/crontab 25 6 * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily $ grep nobody /etc/cron.daily/* find:cd / && updatedb --localuser=nobody 2>/dev/null
Se nei vostri log trovate delle linee come le seguenti:
May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies. May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies. May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies. May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.
Controllate se sono presenti molte connessioni attive sul server usando
netstat
, ad esempio:
linux:~# netstat -ant | grep SYN_RECV | wc -l 9000
Questo è un indice certo di un attacco denial of service (DoS) contro la porta X (molto spesso avvengono contro dei servizi pubblici come i server web od i server di posta). Vi invito ad attivate nel vostro kernel l'opzione TCD syncookies, leggete in Configurare Syncookies, Sezione 4.17.1.1. Attenzione, comunque, come un attacco DoS può saturare la vostra rete voi potete fermarlo mandando in crash il sistema (saturando i file descrittori, il sistema rimane inerte finché la connessione TCP non viene interrotta). Il solo modo efficace per fermare questo tipo di attacco è quello di contattare il vostro provider.
Potreste vedere questo tipo di immissioni nel vostro file
/var/log/auth.log
:
May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by (UID=0) May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root
Sono dovuti all'esecuzione di un processo cron
(nell'esempio, ogni
cinque minuti). Per stabilire quale programma è responsabile dei processi,
controllare le immissioni sotto: /etc/crontab
,
/etc/cron.d
, /etc/crond.daily
ed il
crontab
di root sotto /var/spool/cron/crontabs
.
Esistono diversi passaggi che potreste seguire in caso di intrusione:
20 maggiori vulnerabilità di sicurezza
della SAN
.
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à blackhat.
Osservando i log (se non sono stati alterati), utilizzando sistemi di
rilevamento intrusioni (vedete in Pianificare la ricerca di intrusi,
Sezione 9.2), traceroute
, whois
e strumenti
simili (inclusa analisi forense), potreste essere in grado di tracciare un
attacco alla fonte. Il modo in cui reagite a questa informazione dipende
unicamente dalla vostra politica di sicurezza, e da cosa voi
considerate un attacco. Uno scan remoto è un attacco? Un rilevamento di
vulnerabilità è un attacco?
Per prima cosa, controllate se la vulnerabilità è stata resa pubblica sulle
mailing list di sicurezza (come Bugtraq) o altri forum. Il Security Team di
Debian si tiene in contatto con queste liste, quindi potrebbero essere a
conoscenza del problema. Non procedete in nessun altro modo se vedete un
annuncio su http://security.debian.org
.
Se l'informazione non è stata resa nota, per favore, spedite un'e-mail per il
pacchetto affetto dalla vulnerabilità, descrivendola dettagliatamente
(mostrando il concetto di come dovrebbe essere il codice giusto) al team@security.debian.org
. Il
Security Team analizzerà la vostra segnalazione.
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.
proftpd
è vulnerabile ad attacchi Denial of Service.
Aggiungere DenyFilter \*.*/ al vostro file di configurazione e per
ulteriori informazioni vedete http://www.proftpd.org/critbugs.html
.
portsentry
ci sono molte porte aperte.
È solo il modo in cui funziona portsentry
. Apre circa
venti porte inutilizzate per rilevare i port scan.
Queste informazioni derivano dalla Debian Security
FAQ
. Includono informazioni fino al 19 novembre e rispondono ad
alcune altre comuni domande fatte sulla mailing list debian-security.
Sono informazioni spedite dal Security Team di Debian (vedere sotto) riguardo
alla scoperta e soluzione di una vulnerabilità trovata in un pacchetto
disponibile con Debian GNU/Linux. I DSA firmati vengono spediti alle mailing
list pubbliche (debian-security-announce) e postati sul sito Debian (sia in
prima pagina che nell'area
sicurezza
.
I DSA includono informazioni sul pacchetto interessato, la falla di sicurezza scoperta e dove trovare il pacchetto aggiornato (e il suo MD5 sum).
Molto probabilmente è un vostro problema. La lista debian-security-announce
ha un filtro che permette ai soli messaggi con la firma corretta e provenienti
da uno dei membri del Security Team di essere postati.
Probabilmente, qualche parte del vostro software di posta lo cambia lievemente, infrangendo così la firma. Assicuratevi che il vostro software non faccia nessuna codifica o decodifica MIME, o conversione dei tab in spazi.
Si conoscono software che si comportano così e sono fetchmail (con l'opzione mimedecode abilitata), formail (solo quello proveniente da procmail 3.14) ed evolution.
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.
La più importante linea guida nel fare un nuovo pacchetto che risolva un problema di sicurezza è di fare quanti meno cambiamenti possibili. I nostri utenti e sviluppatori si dedicano a controllare l'esatto funzionamento di una release una volta che viene fatta e così qualsiasi cambiamento facciamo potrebbe teoricamente sconvolgere il sistema di qualcun'altro. Ciò è particolarmente vero nel caso delle librerie: vi assicuriamo di non farvi mai cambiare l'Application Program Interface (API) o Application Binary Interface (ABI), non importa quanto piccolo sia il cambiamento.
Questo significa che spostarsi verso una nuova versione non è una buona soluzione e che invece i cambiamenti rilevanti saranno implementati anche nelle vecchie versioni. Generalmente i manutentori delle nuove versioni sono lieti di aiutarvi, se ne aveste bisogno, altrimenti potrebbe essere d'aiuto anche il Security Team di Debian.
In alcuni casi non è possibile implementare un backport dei fix di sicurezza, per esempio quando grosse quantità di codice devono essere modificate o riscritte. Se succedesse, potrebbe essere necessario spostarci su una nuova versione ma questo non ha bisogno di un preventivo coordinamento con il Security Team.
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.
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.
La risposta corta è: non lo è. Testing e Unstable cambiano rapidamente obbiettivi e il Security Team non ha le risorse necessarie per supportarli adeguatamente. Se desiderate avere un server sicuro (e stabile) siete vivamente incoraggiati ad utilizzare la stable. In ogni caso, gli addetti alla sicurezza cercheranno di risolvere i problemi di sicurezza nelle versioni testing e unstable dopo averli risulti nella versione stable.
In qualche caso, comunque, il ramo unstable mette le correzioni di sicurezza abbastanza velocemente, dal momento che queste correzioni sono disponibili più velocemente nelle nuove versioni (in quelle vecchie, come quelle del ramo stable, solitamente è necessario un aggiornamento di una versione meno recente).
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.
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.
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.
Informazioni sulla sicurezza possono essere mandate a security@debian.org
e sarà letta
da ogni sviluppatore Debian. Se disponete di informazioni sensibili siete
pregati di utilizzare team@security.debian.org
in
modo che solo i membri la leggano. Se volete, la email può essere
crittografata con la Debian Security Contact key (key ID 0x363CCD95
).
Quando si mandano messaggi a security@debian.org, questi sono inviati alla
mailing list degli sviluppatori (debian-private). Tutti gli sviluppatori
Debian sono iscritti a questa lista e gli interventi sono mantenuti privati
(cioè non sono accessibili dal sito web pubblico). La mailing list pubblica,
debian-security@lists.debian.org, è aperta a tutti coloro che si vogliono
iscrivere
ed
esistono archivi per ricerche disponibili qui
.
WNPP bug
richiedendo software che ritenete possa essere utile, ma che attualmente non è
disponibile in Debian.
Linux Kernel Security
Audit Project
o il Linux
Security-Audit Project
incrementano la sicurezza di Debian
GNU/Linux, dal momento che i loro contributi aiuteranno probabilmente anche
Debian.
In ogni caso, siete pregati di controllare ogni problema prima di riportarlo a ecurity@debian.org. Se ne siete in grado, fornite patch che aiutino ad accelerare la risoluzione del processo. Non inoltrate semplicemente le mail di Bugtraq, visto che vengono già ricevute. Fornire ulteriori informazioni, comunque, è sempre una buona idea.
Il Security Team di Debian attualmente è composto da cinque membri e due segretari. Lo stesso Security Team incoraggia ad unirsi a loro.
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.
Il Security Team di Debian lavora velocemente per spedire advisories e produrre
pacchetti corretti per il ramo stabile, una volta che una vulnerabilità è stata
scoperta. Un rapporto pubblicato
sulla mailing list debian-security
ha mostrato come, nell'anno 2001,
ci sia voluto al Security Team di Debian una media di 35 giorni per correggere
vulnerabilità relative alla sicurezza. Comunque, più del 50% delle
vulnerabilità sono state corrette nell'arco di 10 giorni e più del 15% di
queste sono state corrette lo stesso giorno in cui è stato rilasciato
l'advisory.
Comunque, nel porre la domanda, la gente tende a dimenticare che:
Se desideraste un'analisi più approfondita del tempo che ci vuole al Security
Team per lavorare sulle vulnerabilità, dovreste prendere in considerazione il
fatto che i nuovi DSA (vedete in Avvisi di
sicurezza Debian, Sezione 7.2) pubblicati sul sito web relativo alla
sicurezza
e i metadata
utilizzati per generarli, includono link a dei database di vulnerabilità.
Potreste scaricare i sorgenti dal server web (dal CVS
) o usare le pagine HTML per
determinare il tempo che ci vuole a Debian per correggere vulnerabilità e
sincronizzare questi dati con i database pubblici.
Securing Debian Manual
2.96 20 septiembre 2003Sabato, 30 Agosto 2003 18:27:45 +0200jfs@computer.org