Bene: è stato controllato il sistema, è sicuro per quanto possibile e si è pronti a metterlo in rete. Ci sono alcune cose che si dovrebbero fare ora per prepararsi ad un'intrusione, in modo da poter mettere fuori gioco velocemente l'aggressore e tornare alla piena funzionalità.
La discussione dei metodi di backup va oltre gli scopi di questo documento, ma vanno spese alcune parole su backup e sicurezza:
Se si hanno meno di 650mb di dati da salvare su una partizione, un CD-R è un'ottima strada (perché difficile da manomettere e molto durevole), ovviamente si ha bisogno di 650mb di spazio sul disco per creare l'immagine. Nastri e altri media riscrivibili dovrebbero essere protetti dalla scrittura non appena il backup è completo e quindi verificati per evitare la manomissione. Ci si assicuri di lasciare i backup in un'area sicura e off-line. Un buon backup darà un buon punto di riferimento da cui ripristinare il sistema.
Un ciclo di sei nastri è facile da mantenere. Prevede quattro nastri per la settimana, uno per i Venerdì pari e uno per quelli dispari. Si esegua un backup incrementale ogni giorno, e un backup completo sul nastro del Venerdì. Si dovrebbe fare un backup completo anche quando si apportano cambiamenti o si aggiungono dati particolarmente importanti al sistema.
Si dovrebbero controllare periodicamente i backup per verificare che funzionino come dovrebbero. Si dovrebbero recuperare regolarmente i files e confrontarli con i dati reali, controllare la dimensione e l'indice dei backup e rileggere quelli più vecchi.
Nel caso di un'intrusione, si può usare il proprio database di pacchetti come si userebbe tripwire, ma solo se si è sicuri che non è stato modificato. Si dovrebbe copiare il database RPM in un floppy e tenerlo sempre off-line. Probabilmente la Debian ha qualcosa di simile.
I file /var/lib/rpm/fileindex.rpm e /var/lib/rpm/packages.rpm probabilmente non entreranno in un solo floppy, ma se compressi dovrebbero entrare in un floppy ciascuno.
Ora, se il sistema viene compromesso si può usare il comando:
root# rpm -Va |
Questo significa che ogni volta che viene aggiunto al sistema un RPM, il database dovrà essere ri-archiviato. Sta a voi valutare i vantaggi contro gli svantaggi.
È molto importante che le informazioni che vengono da syslog non siano modificate. Rendere leggibili e scrivibili i files in /var/log solo da poche persone è un buon inizio.
Ci si assicuri di tenere d'occhio cosa viene scritto lì soprattutto in auth. La presenza di molti login falliti, per esempio, indica una tentata intrusione.
Dove cercare i log dipende dalla distribuzione. In un sistema Linux conforme al "Linux Filesystem Standard", come RedHat, si dovrà cercare in /var/log e controllare messages, mail.log, ed altri.
Si può capire dove il sistema tiene i log leggendo il file /etc/syslog.conf. Questo è il file che dice a syslogd (il demone dei log di sistema) dove tenere i messaggi dei log.
Si potrebbe anche voler configurare lo script o il demone che ruota i log per farglieli tenere più a lungo, così da avere tutto il tempo per esaminarli. Si dia un'occhiata al pacchetto logrotate su distribuzioni RedHat recenti. Altre distribuzioni hanno probabilmente un processo simile.
Se i log sono stati manomessi, bisogna cercare di capire quando è iniziata la manomissione e cosa sembra cambiato. Ci sono lunghi periodi di tempo che non hanno log? Controllare i nastri di backup in cerca di log intatti è un buon inizio.
I log, anche se di solito gli intrusi li modificano per coprire le loro tracce, dovrebbero comunque essere controllati. Si potrebbe notare l'intruso che cerca un accesso o sfrutta un programma per ottenere l'account di root. Si potrebbero vedere voci nei log che l'intruso non ha avuto il tempo di cambiare.
Ci si deve anche assicurare di separare auth dagli altri log, inclusi i tentativi di cambiare utente con su, i tentativi di login e altre informazioni sugli account.
Se possibile, si configuri syslog per mandare una copia dei log ad un sistema sicuro. Questo eviterà che un intruso copra le sue tracce cancellando i tentativi di login/su/ftp/ecc. Si legga la pagina man di syslog.conf e si cerchi l'opzione @.
Ci sono diversi altri programmi syslogd più avanzati. Si veda http://www.core-sdi.com/ssyslog/ a proposito di Secure Syslog. Secure Syslog permette di crittografare le voci del syslog per essere sicuri che nessuno le manometta.
Un altro syslogd con altre caratteristiche è syslog-ng. Permette molta flessibilità e crittografa i flussi remoti di syslog per evitare la manomissione.
Infine, i log sono inutili se nessuno li controlla. Ci si prenda del tempo ogni tanto per leggere i propri log e farsi un'idea di come devono essere in normali condizioni. Saperlo fa risaltare molte cose strane.
Molti utenti Linux installano da un CD-ROM. A causa della natura repentina degli aggiornamenti di sicurezza, vengono rilasciati continuamente nuovi programmi. Prima di connettere la macchina alla rete è bene controllare sul sito ftp della propria distribuzione e prendere tutti i pacchetti aggiornati da quando è stato installato il CD-ROM. Spesso questi pacchetti contengono molte soluzioni a problemi di sicurezza, quindi è una buona idea installarli.