RUBRICHE. Server e desktop impenetrabili

Transcript

1 Di Marco Fioretti Server e desktop impenetrabili Per difendersi da attacchi e virus non è sufficiente aggiornare il software di sistema o installare un firewall generico. Ecco le strategie più efficaci. Iserver Open Source continuamente connessi a Internet sono di uso sempre più comune anche nelle famiglie o nelle piccole aziende, dove quasi sempre girano sugli stessi computer che ospitano altri server o i file privati dei vari utenti. Purtroppo utilizzare soltanto software Open Source stabile, aggiornarlo non appena viene scoperto qualche baco o anche attivare un firewall non basta CAD per garantire la sicurezza e la robustezza del sistema. Per stare davvero tranquilli è necessario anche isolare il più possibile fra loro e da Internet tutti i singoli componenti software e attività effettuate su ogni computer. Il modo più popolare per INCHIESTA ottenere questo risultato, soprattutto fra i fornitori di servizi Internet, è la virtualizzazione, con cui diversi sistemi operativi completi convivono, ignorandosi a vicenda, su uno stesso hardware. A volte però la virtualizzazione non è necessaria o INTERNET magari possibile, ad esempio quando ci si trova già all interno di una macchina virtuale o non si vogliono SVILUPPO diminuire troppo le prestazioni del computer. È in casi del genere che le tecniche descritte nel resto di questo articolo possono aumentare notevolmente la sicurezza, isolando fra loro le varie applicazioni o rendendo molto più difficile il semplice tentare di accedere a un computer Linux dall esterno. SELinux Storicamente, in Linux, la protezione da bachi nel software, attacchi esterni o errori degli utenti è sempre partita dal classico sistema di permessi Unix. Secondo questo schema ogni file, inclusi quelli che corrispondono a programmi eseguibili o periferiche hardware, appartiene solo a un utente. Il proprietario di un file può concedersi tre permessi diversi e indipendenti di accesso al file stesso: lettura, scrittura o modifica e infine esecuzione. Gli stessi tipi di permessi sono assegnabili anche a gruppi ristretti di altri utenti del sistema o a tutti, inclusi i visitatori esterni come nel caso di un sito Web. Questo modello non è più sufficiente. Non è abbastanza flessibile e nemmeno abbastanza robusto, in parte perché ogni utente può modificare i permessi dei suoi file come vuole. Se un pirata informatico riuscisse ad assumere l identità di un utente autorizzato potrebbe fare quello che vuole con tutti i file e i programmi accessibili a quell utente. Per questo e altri motivi il mondo Linux ha già iniziato la transizione a Security Enhanced Linux (SELinux), un meccanismo disponibile con il kernel 2.6 che potrebbe arrivare, stando alle dichiarazioni di vari fornitori, anche nei dispositivi consumer come telefonini o videoregistratori digitali che usano questo sistema operativo. SELinux è costruito intorno al concetto chiamato Mac (Mandatory Access Control o controllo obbligatorio degli accessi): per default, utenti e programmi del 280 computer non hanno alcun diritto o libertà d azione, tranne quelli esplicitamente concessi da un amministratore. Questi limiti sono applicabili anche al comportamento di singoli programmi e sono equivalenti alla creazione di tanti firewall specializzati: il risultato è un computer in cui ogni programma può comportarsi soltanto nei modi esplicitamente autorizzati dall amministratore, vedendo solo ciò che vuole l amministratore, indipendentemente da permessi dei file o privilegi dell utente che lo lancia. Sotto SELinux le falle di sicurezza in un qualsiasi applicativo non possono essere sfruttate per danneggiarne o bloccarne altri. L esempio più classico è la capacità di costringere un server Web a parlare soltanto con il database di cui ha effettivamente bisogno per Schema dei permessi Unix Permessi di tutti gli altri utenti Permessi del gruppo: solo lettura (r) ed esecuzione (x) Permessi del proprietario: lettura (r), scrittura (w), esecuzione (x) I tradizionali permessi di accesso Unix: proprietari, gruppi ristretti di utenti e utenti generici hanno diritti di accesso a file e programmi configurabili indipendentemente gli uni dagli altri.

2 creare pagine Web dinamiche. Anche se cadesse sotto il controllo di un cracker, quel server Web non potrebbe comunque lanciare un qualsiasi altro programma o scambiare informazioni con esso, qualunque sia l utente proprietario del server Web o quello che richiede una pagina. Tipi, ruoli e identità I permessi Unix standard continuano a valere anche sotto SELinux, che interviene soltanto quando i permessi stessi permetterebbero l operazione richiesta da un utente. In generale, SELinux decide quali operazioni permettere e quali bloccare in base a tipi, policy (normative), ruoli e identità. I tipi sono attributi di sicurezza assegnabili a qualsiasi oggetto del sistema, dai file ai processi software o alle porte Ethernet. Gli attributi di un file sono visibili sulla linea di comando con il programma showctx menzionato nell articolo SELinux from scratch (vedi box Risorse). Le policy definiscono come i processi possono interagire fra di loro o con altri oggetti, in base al loro tipo. Quanto agli utenti, ognuno di loro può avere diversi ruoli che specificano quali tipi di oggetti e domini di lavoro sono accessibili. In SELinux esistono anche delle identità, costanti per ogni sessione di lavoro, a ognuna delle quali si può associare un insieme di ruoli. Tutte le distribuzioni che includono SELinux forniscono anche delle policy preconfezionate che aggiungono una notevole protezione al sistema, pur rimanendo invisibili o quasi agli utenti finali. Per modificarle, individuare errori o aumentare la sicurezza stanno cominciando a diffondersi utility come SETrouble- Shoot ( che controllano costantemente la presenza di messaggi d errore nei log file, li confrontano con quelli contenuti in un database e informano l amministratore di quali soluzioni sono già disponibili per eliminarne la causa. Procedura di controllo SELinux Soggetto (utente o programma) Database delle policy di SELinux Accesso consentito? Server SELinux Log file Messaggio d errore Si File o server a cui si vuole accedere Cosa accade quando un programma cerca di accedere a un file o a un altro programma sotto SELinux? L accesso è permesso se compatibile con le policy definite dall amministratore, indipendentemente dai privilegi del programma. Identità, ruoli e domini SELinux Identità Mario Giorgio Franco Bloccare i tentativi d ingresso al computer Comunicazioni e attacchi attraverso Internet avvengono tramite pacchetti Ip indirizzati a specifiche porte, definite dal protocollo Tcp, di ogni computer. Ogni porta Tcp è distinguibile dal suo numero e associata, staticamente o dinamicamente, a un programma diverso, che è l unico in ogni momento a poter ricevere o trasmettere pacchetti con quel numero di porta. È così che i server Web o di posta elettronica ricevono e soddisfano le richieste degli utenti: rimanendo sempre in attesa di Ruoli SELinux amministratore supervisore impiegato Domini Riconfigurazione di sistema Controlli periodici Ordinaria amministrazione SELinux associa a ogni identità o account di sistema uno o più ruoli che gli è permesso assumere. A ogni ruolo sono concesse modalità diverse di accesso pacchetti Ip destinati alla porta a loro assegnata, e rispondendo nello stesso modo a tentativi di login o altri comandi degli utenti remoti. Questo vale anche per i protocolli telnet (ormai di fatto in disuso su Internet) e Ssh (Secure Shell), con cui i computer Unix e Linux sono completamente controllabili in remoto dai loro amministratori. È per questo che i pirati informatici cercano continuamente di individuare, con script di scansione e login automatici, porte Ssh aperte su tutti gli indirizzi Ip che riescono a raggiungere. Queste pratiche sono particolarmente 281

3 In Linux, la protezione da bachi nel software, attacchi esterni o errori degli utenti parte dal classico sistema di permessi Unix. pericolose in quei momenti in cui si scoprono bachi non ancora risolti da nessuna nuova versione dei programmi compromessi (zero-day vulnerability). L approccio più comune per proteggere un server, o meglio la sua porta Tcp, da questi problemi è configurare il sistema standard di filtraggio Ip su Linux iptables, in modo che per default rifiuti qualsiasi tentativo di connessione dall esterno. Le porte che servono vengono temporaneamente aperte per effettuare il login, solo per un breve intervallo di tempo, solo a certe condizioni e solo a un indirizzo Ip alla volta. L apertura avviene solo per quegli indirizzi Ip e relativi utenti che si sono già identificati in qualche altro modo. In questo modo le utility di scansione automatica delle porte non rilevano nessun server in ascolto e non ha più importanza se esistono delle zero-day vulnerability. Grazie ai meccanismi di tracciamento delle connessioni contenuti in iptables, le connessioni legittime rimangono aperte anche quando, scaduto un time-out, la regola iptables che ne aveva permesso l avvio viene cancellata. Il port knocking Il primo meccanismo largamente utilizzato per aprire porte Tcp ondemand è stato il port knocking ( Grazie a uno speciale client, l utente che vuole connettersi a un server bussa alle sue porte, cioè trasmette una serie di pacchetti Tcp/Ip in cui l informazione necessaria per farsi riconoscere è Rendere più sicura Ssh Le connessioni cifrate Ssh (Secure Shell) hanno ormai definitivamente rimpiazzato per ragioni di sicurezza i vecchi protocolli telnet ed ftp per lavorare in modalità terminale su computer remoti o caricare file su di essi. Oggi la maggior parte dei fornitori di hosting su Gnu/Linux offre pannelli di controllo grafici per amministrare i propri siti Web via browser. È comunque importante conoscere almeno i rudimenti dell uso di Ssh, per poter accedere al proprio sito quando il pannello non è disponibile. Anche quando si usa soltanto il pannello, è essenziale controllare che Ssh sia configurata in modo da ridurre al minimo possibile l impatto sul server, sia dal punto di vista della sicurezza sia da quello delle prestazioni. Ogni server Ssh può e dovrebbe essere protetto imponendo l uso della versione 2 di Ssh, più sicura della 1, vietando connessioni dirette con l account root e definendo esplicitamente un elenco, più ristretto possibile, di utenti conosciuti. In pratica, questo equivale a controllare che nel file di configurazione del daemon Ssh, normalmente /etc/ssh/sshd_config, siano presenti queste istruzioni: Protocol 2 PermitRootLogin no AllowUsers mario giorgio Un altra misura eccellente, quando si è sicuri di potersi sempre connettere al server dallo stesso computer, è disabilitare completamente i login tramite password: in questo caso Ssh permetterà l ingresso solo a chi si connette da computer che contengono delle chiavi crittografiche già conosciute. Comunque sia configurata Ssh, molti programmi robot per attacchi automatici via Internet cercano continuamente di violarla, tentando di indovinare nome utente e password. Impedire ai cracker di effettuare questi attacchi a valanga è essenziale, se non altro per ridurre il carico sul server e sulla sua velocità di connessione a Internet: purtroppo però Ssh non ha alcun meccanismo di protezione incorporato per queste situazioni. Una prima, facile contromisura per limitare il problema è attivare Ssh su una porta diversa da quella di default (la 22), con l istruzione: Port 2000 Questo accorgimento non impedisce affatto a un pirata informatico competente di individuare la porta giusta con un qualsiasi programma di scansione automatica: i suoi principali vantaggi sono eludere i programmi di attacco più semplici, risparmiando banda del server, e impedire a migliaia di messaggi di avvertimento irrilevanti di inquinare i log file, facilitando l analisi di questi ultimi quando necessario. Le porte Ssh si possono proteggere da tentativi continui di accesso anche con script come denyhosts, sshdfilter o fail2ban. DenyHosts ( è uno script che analizza continuamente il log file di Ssh per individuare tutti i tentativi falliti di accesso dovuti a computer sotto il controllo dei cracker e ne aggiunge l indirizzo Ip a una lista nera (/etc/hosts.deny) di host a cui non si deve più rispondere. Il numero massimo di login che devono fallire prima di essere aggiunti alla lista nera e molti altri parametri sono configurabili dall amministratore. La lista viene periodicamente ripulita dai record più vecchi. Sshdfilter ( svolge la stessa funzione, ma anziché gestire una lista nera di host crea continuamente nuove regole di iptables, che scadono dopo un periodo predefinito, per far bloccare dal kernel i pacchetti Ip provenienti da quegli host. Fail2ban ( infine, lavora come sshdfilter ma ha il grande vantaggio di saper proteggere anche altri server (Web, ftp eccetera) oltre a Ssh. Esiste anche un tutorial dettagliato all indirizzo 282

4 nel tipo, nell ordine e nei numeri di porta dei pacchetti stessi. Si potrebbero ad esempio trasmettere quattro pacchetti Tcp Syn a una serie predefinita di porte, per esempio quelle 97, 459, 29, Quando riconosce una sequenza valida di pacchetti, il server riconfigura immediatamente iptables per permettere al client che le ha spedite di connettersi via Ssh. Il port knocking limita grandemente i tentativi di accesso illecito ma non è privo di problemi, almeno per un uso generalizzato senza personalizzazione. Innanzitutto le sequenze possono essere cifrate, ma in pratica questo ne L uso e la personalizzazione delle policy SELinux stanno diventando sempre più facili grazie a interfacce grafiche come systemconfig-selinux, incluso in Red Hat Enterprise (Fonte: Red Hat Magazine). aumenta le dimensioni e corrisponde a dover trasmettere parecchie centinaia di byte, ovvero parecchi pacchetti Ip, per ogni singola sequenza. Inoltre se anche uno solo di quei pacchetti venisse perso o non ricevuto nello stesso ordine con cui è stato trasmesso, l intera sequenza diverrebbe inutilizzabile. È da notare che il secondo problema si presenta anche quando non si ricorre alla crittografia. Per ridurre la probabilità di questi eventi, il client deve trasmettere abbastanza lentamente da garantire che i pacchetti verranno ricevuti nello stesso ordine con cui sono stati trasmessi. Per Risorse Una introduzione alla Single Packet Authorization si trova nell articolo Un seguito dello stesso autore spiega come applicare la tecnica al servizio Ssh è in Il tutorial è un altra introduzione a Spa, però più focalizzata sul funzionamento del programma fwknop. Per imparare a cifrare i pacchetti Spa con GnuPG conviene invece leggere la pagina Per quanto riguarda SELinux, conviene partire dalla Guida veloce a SELinux per principianti ( guide.pdf) o da quella per configurarlo con la distribuzione Gentoo Gli utenti esperti che volessero invece aggiungere SElinux a una distribuzione personalizzata possono invece consultare l articolo SELinux from scratch ( 105AGX99&S_CMP=CP). Un tutorial di Red Hat Magazine ( spiega infine come costruire un modulo SELinux con una policy personalizzata. avere questa certezza occorre non spedire più di uno o due pacchetti al secondo per connessione, con ovvi problemi di prestazioni soprattutto quando con il port knocking si vuole garantire l accesso a parecchi utenti. Un altro serio limite del port knocking, indipendentemente dalla sua velocità, è la vulnerabilità a eventuali malintenzionati in ascolto fra client e server. Chiunque riuscisse ad ascoltare le sequenze di knocking mentre viaggiano dal client al server potrebbe farne cattivo uso in almeno due modi. Il primo è quello di ritrasmettere la seguenza per intero, cambiando soltanto l indirizzo di origine dei pacchetti, per farsi aprire le stesse porte. Nello stesso modo, cioè osservando il traffico in transito, è assai facile bloccare l accesso agli utenti autorizzati. Per impedire a questi utenti di farsi riconoscere basta infatti rovinare le loro sequenze mentre sono ancora in fase di trasmissione. Inviare al server anche un solo pacchetto extra con gli stessi valori di indirizzo IP sorgente e una qualsiasi porta Tcp di destinazione renderebbe irriconoscibile la sequenza originaria. Single Packet Authorization Esistono diversi modi per ottenere lo stesso effetto del port knocking senza incorrere nei rischi appena descritti. Quello che al momento sta riscuotendo più interesse è la Single Packet Authorization (Spa), normalmente applicata su Linux tramite il programma fwknop ( Con Spa si spediscono anche centinaia di byte di informazioni e comandi in un solo pacchetto Ip, cifrato con algoritmo simmetrico (Rijndael con chiave a 128 bit) o asimmetrico (ElGamal con chiavi fino a 2048 bit). Grazie a questa capacità di trasmissione molto maggiore si possono risolvere molti problemi del port 283

5 knocking. Dei pacchetti isolati possono passare inosservati molto più facilmente di una lunga sequenza. Inoltre la parte iniziale di un pacchetto Spa è composta da 16 byte assolutamente casuali, che rendono ogni pacchetto unico, anche quando contiene lo stesso comando. I pacchetti contengono anche una checksum che, dopo essere stata usata per verificare l integrità del messaggio, viene conservata in una cache. In questo modo, se un cracker ritrasmettesse un pacchetto Spa intercettato, per cercare di entrare, il duplicato verrebbe riconosciuto come tale e completamente ignorato, vanificando così questo tipo di attacchi. Dopo i byte casuali si trovano nome dell utente che richiede la connessione, ora della richiesta e versione di fwknop utilizzata. Conoscere il nome di chi ha spedito la richiesta Spa consente di concedere livelli diversi di accesso a utenti diversi sullo stesso computer. La parte finale dei pacchetti Spa contiene il nome del servizio a cui si decidera accedere (Ssh, ftp, VoIp...) o altri comandi generici di cui si desidera l esecuzione. Imprigionare server o utenti con chroot Oltre a quelli descritti nell articolo principale di questo mese esiste un altro modo, forse meno conosciuto ma comunque utile, per proteggere un computer da attacchi effettuati attraverso i suoi server o da errori degli utenti. La soluzione consiste nell imprigionare quei server o quegli utenti, cioè farli lavorare confinati all interno di una parte più piccola possibile del file system, senza alcuna visibilità di tutte le altre cartelle. Nel mondo Unix e Linux non esistono lettere per i vari dischi come A:, C: e così via. Tutti i file, non importa su quale disco interno, esterno o rimovibile si trovino fisicamente, hanno una posizione precisa all interno di un unica struttura gerarchica (file system). Il punto di partenza di ogni file system è la directory /, chiamata root (radice) proprio perché è quella in cui sono contenute tutte le altre. È possibile rinchiudere un server all interno di una cartella con il comando o la funzione C chiamati chroot. Il loro effetto è quello di cambiare la directory vista come root del programma a cui vengono applicate e di tutti gli altri da esso lanciati. Dopo aver definito una nuova root con chroot qualsiasi posizione nel file system verrà calcolata, in maniera invisibile alle varie applicazioni, a partire dalla nuova root. In pratica, quindi, se dopo aver digitato il comando: chroot/home/utente/ venisse eseguito quest altro: rm/archivio.zip si effettuerebbe la rimozione ( rm ) di quello che prima era il file /home/utente/archivio.zip. Queste porzioni ridotte del file system vengono normalmente chiamate prigioni chroot, proprio perché un programma che lavora al loro interno non può spostarsi, cioè evadere, in nessuna cartella al di sopra o al di fuori della nuova root. Normalmente il comando chroot è utile solo agli amministratori di server, professionisti o meno, ma potrebbe essere utile anche agli utenti finali, se non altro per provare in sicurezza nuovi programmi senza rischiare di danneggiare il resto del sistema. A parte la sicurezza, c è un altro vantaggio nel configurare un server in questo modo. Poiché, per definizione, una prigione chroot deve contenere tutti i file di cui il server ha bisogno per lavorare, essa si può spostare o duplicare senza problemi da un disco rigido all altro con la certezza che continuerà a funzionare. Un altro uso, forse meno frequente ma assai utile, delle prigioni chroot è il rendere deliberatamente accessibile ai propri utenti soltanto una parte, diversa per ognuno di loro, dell intero file system. Questo è assai comodo quando l unica ragione di concedere un account è caricare file su un server. Nel caso di utenti che possono connettersi soltanto in remoto con protocollo Ssh, esiste una patch scaricabile da Internet ( per chiuderli automaticamente in una prigione chroot all atto stesso del login. Prigioni a prova di fuga Per essere veramente efficace, oltre a lasciare visibile il meno possibile dell intero file system, una prigione chroot dovrebbe contenere il minor numero possibile di file e programmi, ovvero solo e soltanto quelli necessari allo scopo per cui è stata costruita la prigione. La prigione di un mail server, ad esempio, dovrebbe contenere soltanto le caselle di posta, il mail server vero e proprio, le librerie di sistema di cui ha bisogno se non è stato compilato staticamente, script e altre utility necessari per la manutenzione e i file di configurazione. Il principio di fondo rimane quello di limitare il più possibile i danni che un intruso nella prigione potrebbe causare, sia dentro sia fuori dalla prigione stessa. Per lo stesso motivo, i file chiusi nella prigione dovrebbero essere vere e proprie copie, non link a file esterni, altrimenti potrebbero permettere a un cracker di evadere. File e programmi dovrebbero inoltre appartenere all utente root ogni volta che è possibile e avere solo i permessi di accesso indispensabili per compiere il proprio lavoro. Per saperne di più sulle prigioni chroot è utile leggere l articolowww.unixwiz.net/techtips/chrootpractices.html, che contiene parecchi consigli pratici sia per costruire una prigione sia per sviluppare applicativi in grado di lavorare correttamente al suo interno. 284