Webb.it 2002 Fabio Busatto Linux Startup: configurazione sicura post installazione

Sicurezza locale e sicurezza di rete Cosa pensiamo quando diciamo che la nostra macchina e` sicura? la sicurezza deve essere relazionata all'ambito in cui siamo modello workstation vs. modello server la paranoia non e` sempre una buona alleata di chi ci possiamo fidare *veramente*? togliamoci dalla mente l'esistenza della *sicurezza assoluta*! Quale puo` essere il giusto compromesso?

Il nostro cervello come miglior difesa Il modo migliore per garantire la sicurezza di una macchina e` quello di padroneggiare pienamente tutto quello che avviene su di essa. Questo implica alcune riflessioni: avere la coscienza di come vengono avviati e gestiti tutti i servizi dal sistema operativo controllare che effettivamente ci siano tutti e solo i processi che servono e che sono consentiti saper interagire con il software utilizzato in modo da poterlo adattare ad hoc per ogni nostra esigenza

Processi e porte Gli aspetti piu` importanti nell'ambito della sicurezza di rete sono ovviamente le porte che vengono bindate dal sistema e che possono essere usate come ponte per comunicare con l'esterno. Appena terminata l'installazione bisogna controllare che i processi in esecuzione e le porte che questi eventualmente bindano siano effettivamente quelle di cui necessitiamo, imponendo gia` delle policy di sicurezza di rete (firewall, wrapper, binding su interfacce multiple). PROGRAMMI: ps(1), netstat(8), fuser(1), ipchains/iptables(8)

Se proprio vogliamo farci del male.. :) Per avere una visione completa (anche se spesso non molto human readable), possiamo andare a cercare all'interno del filesystem montato solitamente in /proc tutte le informazioni dei processi e delle porte che necessitiamo, e da dove possiamo settare tutti i parametri relativi alla configurazione del nostro sistema per ottimizzare e aumentare la sicurezza di rete della nostra installazione. PROGRAMMI: cat(1), echo(1)

Rendere definitive le modifiche: rcfiles Per evitare di dover riconfigurare ad ogni avvio la macchina, la cosa migliore e` di individuare le procedure di startup del sistema (normalmente identificare in una serie di rcfiles), e di modificare questi script in modo da far eseguire loro solamente quello che e` necessario per portare il sistema dalla condizione di boot (appena viene lanciato il demone init), alla configurazione ottimale che abbiamo raggiunto con le nostre personalizzazioni. In questo modo avremo un boot ottimizzato sia dal punto di vista della velocita` che da quello della sicurezza di rete.

init per cominciare dal principio Per capire il funzionamento del sistema analizziamo la procedura di avvio partendo dall'inizio. Il demone che si occupa di caricare gli script e` init(8), il quale viene lanciato dal kernel subito dopo il boot (a meno che non si specifichi diversamente); la divisione in runlevel ci permette di specificare diversi stati nel quale il nostro sistema si puo` trovare, e configurare un comportamento adeguato dei servizi. Il contenuto del file /etc/inittab(5) ci identifica per ogni runlevel come agire, fornendo servizi base come la gestione delle tty, e definendo gli script da eseguire ad ogni cambio di stato.

BSD e SysV: diversi ma non cosi` tanto Queste sono le due principali branche usate dai sistemi linux moderni. Il primo usa una configurazione con pochi file che gestiscono intere aree della configurazione, mentre il secondo usa una struttura piu` complessa per identificare gli script da eseguire ad ogni runlevel, attraverso un sistema di symlink. I due sistemi sono interoperanti in alcuni casi particolari. BSD: slackware, debian (update-rc.d) SysV: mandrake, redhat (chkconfig per facilitare la gestione)

Qualcuno ha detto "MD5"? Nonostante la maggior parte della configurazione iniziale si possa fare attraverso l'editing dei file di avvio, e` importante anche ritoccare i file di configurazione dei singoli servizi (ad esempio quelli presenti in /etc), in modo da essere sicuri che tutto quello che viene lanciato sia conforme con le nostre politiche di sicurezza. Ad esempio possiamo configurare la sicurezza degli accessi in /etc/securetty(5), oppure attraverso /etc/login.defs(5) definire molte opzioni sui login degli utenti del nostro sistema, come ad esempio l'algoritmo MD5 per l'hashing delle password.

La sicurezza non e` solamente remota Spesso bisogna controllare anche le politiche di sicurezza locali, e non solo quando molti utenti hanno accesso alla macchina, ma anche per impedire ad esempio la scalata dei privilegi verso root da parte di un intruso esterno con privilegi inferiori. I programmi suidati costituiscono un problema di sicurezza locale molto grave, bisogna quindi: localizzarli all'interno del sistema analizzare se sono realmente necessari eventualmente eliminare la flag s dai permessi PROGRAMMI: find(1), chmod(1)

A ognuno il suo Uno dei modi migliori per cercare di limitare i danni dovuti ad un'intrusione e` quello di fornire ad ogni processo il minimo di permessi che gli servono per svolgere con successo il suo compito, impedendogli di poter fare altro. Far girare quindi demoni che non richiedono privilegi di root e` un'ottima pratica, o esternamente all'atto del lancio (attraverso il comando su(1)), oppure da codice attraverso chiamate come setuid(2), seteuid(2), setgid(2) e setegid(2). Il dropping dei privilegi va associato ad una attenta gestione dei permessi dei file del nostro sistema.

chroot come soluzione radicale Uno dei modi piu` sicuri per limitare l'ambito di azione di un processo e' quello di ricorrere ad un ambiente chrootato all'interno del quale viene ricreata l'area di funzionamento dell'applicazione. Questo puo` essere effettuato sia a livello esterno, attraverso l'apposito comando, oppure chiamando all'interno del codice la funzione chroot(2), cambiando cosi` la root directory vista dal programma ed impedendo ogni accesso al resto del sistema. Purtroppo non sempre e` cosi` semplice come sembra. PROGRAMMI: chroot(1)

Crearsi i programmi Chiaramente, non scriversi da soli tutti i programmi di cui necessitiamo (e anche in questo caso, potremmo davvero garantirne la sicurezza?), ma fare piccole modifiche ai codici di quelli gia` esistenti al fine di renderli migliori. Possiamo individuare diverse tipologie di patch: Patch al codice del kernel linux Grsec Kerneli Patch al codice dei programmi applicativi Indirizzamento dello stack Binding su interfacce multiple

E se proprio dobbiamo.. Quella che normalmente viene vista come la prima linea di difesa contro gli hacker deve essere invece lasciata come ultima scappatoia, e aggiunta ad una saggia politica di configurazione sicura. Mettere un firewall, senza sapere che cosa si sta difendendo, e` una cosa inutile e spesso anche pericolosa, in quanto fornisce un falso senso di sicurezza che puo` tradirci in maniera completa. Anche nella stesura delle regole di firewalling utilizziamo il nostro cervello, pianificando con saggezza la configurazione.

Domande? :)

Grazie dell'attenzione Fabio Busatto -