Capitolo 12. Strategie per mantenere un server sicuro

Linux può essere certamente considerato come sicuro o almeno più sicuro di altri sistemi operativi. Il crescente interesse per Linux ha fatto sì che molti crackers spendessero molte energie nel tentativo di trovarvi delle falle. Ci sono stati,in tempi passati, alcuni exploit, ma la natura open di Linux ha permesso di porvi riparo molto rapidamente, con soluzioni temporanee o con aggiornamenti software.

Non pretendo di essere un esperto di questioni di sicurezza ma, quanto meno, me ne sono interessato dato che credo che siano fondamentali per rendere un sistema quanto più sicuro possibile.

Sebbene ci siano stati alcuni exploit, trovati in alcuni servizi, che avrebbero potuto permettere ai crackers di accedere ad un sistema (ad esempio quello del demone IMAP), credo sia più probabile che qualche cracker penetri un sistema dall'interno. Rispetto ai pochi servizi che comunicano con il mondo esterno, ci sono migliaia di comandi e di utilità, disponibili dalla shell, che probabilmente contengono bug che consentono di aggirare le misure di sicurezza (anche se devo ammettere di aver scoperto che uno dei server da me mantenuti è stato compromesso attraverso un servizio esterno).

Per questa ragioni, vi raccomando di dare account di shell agli utenti solo se assolutamente necessario. Anche se considerate i vostri utenti persone completamente affidabili, basta che uno di essi abbia una password molto facile. Un cracker esterno, sfruttando la debolezza di questa password, potrebbe agire con tutta calma cercando di scoprire poi altri punti deboli.

Fortunatamente potete far cose che aumenteranno sensibilmente la sicurezza del vostro sistema Linux. Poiché una discussione dettagliata sulle questioni di sicurezza esula dallo scopo di questa documentazione, la lista che segue fornisce brevi indicazioni su cosa fare per aumentare la sicurezza:

• Aggiornare gli strumenti di sistema, le applicazioni ed il kernel: la causa più comune di irruzione nei sistemi dipende dal mancato mantenimento di un server sempre aggiornato. Effettuare regolari aggiornamenti del kernel, degli strumenti e delle utilità garantisce l'eliminazione, dal vostro sistema, di elementi per i quali sono già noti degli exploit. Per informazioni su come mantenere un server sempre aggiornato, si veda la Sezione 4.9 e la Sezione 10.3.

• Shadow passwords: vi consiglio caldamente di utilizzare le Shadow password; passare a questo formato è davvero molto facile. Maggiori dettagli nella Sezione 6.6.

• Uso intelligente delle password: assicuratevi che le password, specialmente quelle degli utenti a cui fornite accesso alla shell, siano difficili da individuare e cambiate spesso. Inoltre, se usate server multipli, resistete alla tentazione di utilizzare sempre la stessa password (altrimenti, se un cracker accede ad un server dopo aver scoperto un password, potrebbe accedere facilmente anche a tutti gli altri).

• Usate la secure shell (ssh): passate a "ssh" invece di "telnet". Telnet non è sicuro per due ragioni: Primo, le sessioni non sono criptate, quindi tutto quello che viene trasmesso, compreso password e username, è in chiaro. Secondo, la prima cosa che fa un cracker è quella di provare a connettersi ad un porta telnet aperta.

  Ssh fornisce connessioni criptate e compresse, offre quindi più sicurezza rispetto a telnet. Potete utilizzare un server ssh (che permette connessioni sicure in entrata) anche come client (per connessioni, in uscita, sicure) sotto Linux. Potete reperire il pacchetti RPM su ftp://ftp.replay.com/pub/replay/redhat/i386/. Avrete bisogno dei seguenti file (è possibile che siano disponibili versioni più recenti al momento in cui state leggendo):

  • ssh-1.2.27-5i.i386.rpm Il pacchetto di base.

  • ssh-clients-1.2.27-5i.i386.rpm Client per connessioni verso l'esterno.

  • ssh-extras-1.2.27-5i.i386.rpm Alcuni pratici script Perl.

  • ssh-server-1.2.27-5i.i386.rpm Server per le connessioni in entrata.

  Il file RPM di SSH elencati sopra si riferiscono alla versione internazionale. Se abitate negli Stati Uniti o in Canada, potete scegliere di scaricare i pacchetti per gli U.S.A. (che potrebbero avere algoritmi di criptazione più robusti); questi pacchetti hanno il suffisso "us" invece di quello "i" subito dopo i numeri della versione. Per la legge U.S., è illegale esportare prodotti molto complessi per la criptazione fuori dagli Stati Uniti o dal Canada. Speriamo che un giorno gli imbecilli che fanno parte del dipartimento di giustizia degli U.S.A. escano dal tunnel e tolgano questa stupida restrizione. Red Hat non include SSH nella sua distribuzione appunto per questo motivo, infliggendo a tutti molta sofferenze).

  Se i vostri utenti Windows dovessero lamentarsi di non riuscire più a connettersi al vostro sistema, fategli sapere che esistono alcuni client ssh completamente gratuiti:

  "TeraTerm Pro" client software

  http://hp.vector.co.jp/authors/VA002416/teraterm.html

  "TTSSH" client software

  http://www.zip.com.au/~roca/download.html

  "Cryptlib" client software

  http://www.doc.ic.ac.uk/~ci2/ssh

  "Putty" client software

  http://www.chiark.greenend.org.uk/~sgtatham/putty.html

  Se decidete di passare a ssh assicuratevi di installarlo e usarlo su tutti i vostri server. Avere cinque server sicuri e uno no è solo un perdita di tempo, specialmente se siete abbastanza stupidi da usare la stessa password per più di un server.

• Accesso limitato ai servizi esterni: successivamente, dovete editare i file "/etc/hosts.allow" e "/etc/hosts.deny" per limitare l'accesso a servizi su host esterni. Di seguito vi fornisco un esempio di come limitare l'accesso telnet e ftp. Innanzitutto il file "/etc/hosts.allow":

  # hosts.allow in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name

  Questo permetterà connessioni telnet e ftp a tutti gli host con classi IP 123.12.41.* e 126.27.18.*, oltre che ai domini mydomain.name e another.name.

  Quindi, il file "/etc/hosts.deny":

  # hosts.deny in.telnetd: ALL in.ftpd: ALL

• Chiudete e disinstallate ogni servizio non necessario: Editate il file "/etc/inetd.conf" e disabilitate (cioè decommentate con il carattere "#") ogni servizio non necessario (se state usando ssh, come raccomandato sopra, potreste voler disabilitare il servizio telnet). Fatto ciò, digitate come root "/etc/rc.d/init.d/inet restart" per riavviare il demone inetd con le nuova impostazioni.

• Installate un security detection system: Considerate l'idea di installare programmi di sicurezza come "Tripwire" (http://www.tripwiresecurity.com/) che può scoprire eventuali intrusioni, e "Abacus Sentry" (http://www.psionic.com/abacus/) che può aiutare a prevenirle.

• Normale diligenza: Tenete gli occhi aperti sul vostro sistema effettuando, a caso, controlli sulla sicurezza (esaminando ad esempio i file delle password, la lista dei vostri processi, oppure controllando i file di log per verificare la presenza di dati sospetti). In più riferite, alla autorità preposte, ogni tentativo di irruzione. Lo so che potrebbe essere una scocciatura, soprattutto se il vostro sistema riceve molti attacchi in una settimana, ma questi report servono a scoraggiare, con la prospettiva di dover scontare una pena, i possibili cracker. Inoltre, assicurano maggior sicurezza anche a sistemi di altre persone (che potrebbe essere stati a loro volta compromessi).

• Posto che installiate e aggiorniate i vostri strumenti di sistema e le vostre applicazioni ricorrendo all'uso dell'utilità "RPM", potreste volere controllare l'integrita dei pacchetti installati con il seguente comando:

  rpm --verify -a > /tmp/rpm-audit.txt

  Il comando sopra confronterà tutti i file importanti con il database RPM del vostro sistema e indicherà, con un '5', tutti i file che sono stati modificati. Di seguito un esempio di un possibile output:

  S.5....T /bin/ls S.5....T /usr/bin/du ......G. /dev/tty5 .....U.. /dev/vcs5 .....U.. /dev/vcsa5 S.5....T c /etc/lynx.cfg S.5....T c /etc/sendmail.cf

  Nell'esempio, potete vedere una lista di sette file, quattro dei quali sono stati modificati. Naturalmente ci saranno, con tutta probabilità, molti file modificati se avete provveduto a personalizzare il vostro sistema secondo le vostre necessità. Un breve controllo dei file /etc/lynx.cfg e /etc/sendmail.cf, a vista o da backup, potrebbero rivelare i cambiamenti legittimi che avete apportato al vostro sistema.

  Notate, comunque, che due dei file modificati dell'esempio sono eseguibili binari. È probabile che questi due binari, i comandi "ls" e "du", siano adesso dei trojan che un cracker ha installato per scopi malevoli. L'uso del comando "diff" tra i binari modificati e quelli recuperati da un backup o da RPM potrebbe rivelare differenze di dimensione oppure altro; ulteriori evidenze della presenza di trojan.

  (Per maggiori informazioni sugli "RPM", si veda la Sezione 10.1)

Per ulteriori informazioni su questioni di sicurezza, una risorsa eccellente, intitolata "Securing RedHat 5.x" è disponibile su http://redhat-security.ens.utulsa.edu/. Una eccellente risorsa sulla criptazione con Linux, e sui i software relativi, su http://replay.com/redhat/.