firecmp Loadable Kernel Module A u t h o r : Giuseppe Gottardi (overet) <gottardi@ailinux.org>

Transcript

1 firecmp Loadable Kernel Module A u t h o r : Giuseppe Gottardi (overet) <gottardi@ailinux.org> Version: 1.0 Giuseppe Gottardi (overet), laureando in Ingegneria Elettronica presso l Università Politecnica delle Marche. Creatore del progetto firecmp e sviluppatore in ambiente Free Software della rac. ITU-R.BS.1387, PEAQ (Perceptual Evaluation of Audio Quality). I suoi interessi sono particolarmente focalizzati sulle problematiche security related. Partecipa al progetto AILinux.

2 firecmp Loadable Kernel Module A u t h o r : Giuseppe Gottardi (overet) <gottardi@ailinux.org> Uno dei principi basilari di security a cui un SysAdmin dovrebbe sempre attenersi è quello che suona come: tutto ciò che non serve deve essere escluso, con questo ci si riferisce ovviamente ai servizi di rete, i cosiddetti demoni. La motivazione di ciò è lampante se si pensa che un Cracker (colui che penetra nei sistemi informatici) sfrutta proprio questi servizi, spesso affetti da qualche bug del tipo Buffer Overflow o Format String per fare un code inject nei processi residenti dell host vittima e prendere il controllo della macchina. Partendo da questo presupposto escludiamo tutti i servizi che non ci interessano così da limitare le possibili porte di ingresso al Cracker, non possiamo comunque eliminare i demoni utili, cioè quelli per cui è stato dedicato il server, anche perché un server senza servizi sarebbe l ideale dal punto di vista della sicurezza ma non avrebbe più scopo di esistere. Il principio di funzionamento di firecmp è proprio quello di offrire la possibilità di escludere tutti i servizi e di poterli riattivare da remoto. Questa utility è pensata per tutte le situazioni in cui ci sono servizi usati raramente in un sistema (come SSH, FTP, SMTP ecc.), per accedere ad essi si deve garantire l accesso nella policy del firewall di sistema e questo potrebbe rappresentare un rischio per la sicurezza poiché i servizi potrebbero essere exploitati. Questo LKM permette un apertura dinamica delle porte e dei protocolli con l ausilio di una semplice ICMP_ECHO_REQUEST che contiene un cookie opportunamente strutturato (da cui il nome), in modo che i servizi possano essere lasciati attivi e la policy del firewall impostata per garantire loro accesso, ma al tempo stesso impedire gli accessi non autorizzati alle porte settate in un opportuno file di configurazione. 1

3 --== How firecmp Works ==-- firecmp lavora ad un livello più basso del comune iptables, quindi non modifica ne reimposta le normali regole del firewall di sistema, ne aggiunge di nuove che peraltro vengono rimosse con la rimozione del LKM dal kernel. Come già detto, tutti i protocolli possono essere bloccati dal netfilter, perfino il protocollo ICMP, poiché, essendo firecmp ad un livello più basso, riceve comunque tutti i pacchetti e può elaborarli alla ricerca dell ICMP autorizzato all apertura/chiusura delle porte, per poi passarli ai livelli superiori. Specifiche Il funzionamento del modulo è molto semplice: quando arriva un packetto ICMP, viene analizzato alla ricerca di un determinato cookie contenente password+porta, se la password contenuta è corretta si controlla nella port list del file di configurazione se quella porta è una candidata a poter essere sbloccata e se lo è avviene l apertura; la porta resta in questo stato per 60 sec. durante i quali deve avvenire la connessione TCP/UDP, se allo scadere nessuna connessione è avvenuta la porta viene richiusa automaticamente. La porta viene richiusa al rilascio della connessione. Bugs Le possibili falle nella sicurezza di questo sistema possono essere dovute al fatto che chiunque potrebbe inviare un pacchetto ICMP opportunamente formattato per aprirsi un varco nel nostro server, così un primo livello di sicurezza è fornito dalla password contenuta nel cookie. Questo primo livello è assolutamente insicuro in rete locale poiché basterebbe un attacco di tipo Man In The Middle, uno sniffer piazzato nello stesso segmento di rete intercetterebbe il pacchetto e la nostra password verrebbe usata dall attacker. Conclusione è che in rete locale l uso di una password in chiaro è totalmente inutile, più utile è se si inquadra il problema da remoto e si considera la rete locale sicura nel senso che non deve essere considerata come base di partenza dell attacker. Da remoto infatti il pacchetto dovrebbe essere intercettato con una modifica alle tabelle di instradamento (route mangling), e questo risulta un po più difficile e laborioso per l attacker. Poiché nulla è impossibile ipotizziamo che il nostro ICMP venga intercettato, e adottiamo eventuali contromisure di sicurezza usando delle ACL (Access Control List). Nelle ACL definiamo una lista di host autorizzati all apertura delle porte, e una lista di porte candidate ad essere aperte; in questo modo se l attacker inviasse un pacchetto con l esatto cookie non verrebbe accettato se il suo IP non è tra quelli 2

4 autorizzati. Semplice soluzione per l attacker sarebbe quella di inviare l ICMP con l indirizzo IP sorgente spoofato, questo è relativamente facile e se accadesse il nostro modulo riconoscerebbe il cookie del pacchetto come valido ed aprirebbe la porta indicata (a patto che questa sia una delle porte autorizzate, possono essere aperte solo le porte listate nella port list). Una soluzione a questo problema sarebbe quella di adottare un metodo di codifica del cookie, ed è quello che verrà si farà con la prossima release stable del kernel 2.6 che prevede già molti algoritmi per la cifratura dei dati. In questa versione dunque la sicurezza del nostro server sembrerebbe compromessa, ma non è così (o meglio non del tutto), supponendo che l attacker riuscisse ad aprire una porta intercettando il pacchetto e ricostruendone uno uguale con l indirizzo sorgente spoofato, il modulo accetterebbe una connessione solo dall indirizzo IP da cui gli è arrivato il pacchetto, e dato che praticamente tutte le connessioni relative a servizi di rete usano il protocollo TCP, non sarebbe facile per l attacker effettuare uno spoofing cieco della comunicazione sul questo protocollo. Quindi giungiamo alla conclusione che questo metodo per l apertura dinamica dei servizi è già abbastanza sicuro, ancor più lo sarà con la codifica dei dati. Uno schema riassuntivo di tutto il processo descritto lo troviamo nella figura seguente in cui l host B è l attacker, l host A è l host autorizzato e il SERVER è la macchina su cui è installato firecmp. SERVER IP: NET HOST A IP: ICMP autorizzato ICMP spoofato Comunicazione TCP avvenuta Comunicazione TCP fallita Host B IP:

5 --== Cookie ==-- L'ICMP è un protocollo che permette ai router di inviare messaggi di errore o di controllo ad altri router o agli host. Esso può essere considerato un protocollo per lo scambio di informazioni nella gestione della rete. I messaggi ICMP viaggiano attraverso la rete nella parte dati del datagramma IP. Vediamo quest ultimo in dettaglio nella seguente figura: Esistono molti tipi di messaggi ICMP e ognuno ha un proprio formato. Tutti cominciano con un campo TYPE di 8 bit che specifica il tipo di messaggio secondo la tabella riportata in figura. Type Field ICMP Message Type 0 Echo Reply 3 Destination Unreachable 4 Source Quench 5 Redirect (change a route) 8 Echo Request 11 Time Exceeded for a Datagram 12 Parameter Problem on a Datagram 13 Timestamp Request 14 Timestamp Reply 15 Information Request (obsolete) 16 Information Reply (obsolete) 17 Address Mask Request 18 Address Mask Reply 4

6 0 Fra i messaggi ICMP più utilizzati troviamo i messaggi Echo Request e Echo Reply. Una macchina invia un Echo Request ad un'altra macchina; questa genera un Echo Reply e la invia alla prima. La più nota implementazione di questa procedura è quella dell'applicazione ping, che troviamo in ogni sistema operativo. Viene usata di solito per verificare che la destinazione sia raggiungibile e attiva, nel nostro caso la useremo per l incapsulamento del cookie (opzione [-p] su Linux), che ci permetterà di inviare i messaggi al LKM presente nel nostro server. L incapsulamento è eseguito in modo molto semplice come segue: 0 x x+2 PASSWORD PORTA ovviamente inserito nel campo DATA del datagram ICMP riportato in figura. 5

7 --== Socket Kernel Buffers ==-- TCP/IP è un set di protocolli organizzato a livelli. Questo significa che il kernel deve usare ordinatamente diverse funzioni per processare i diversi livelli del pacchetto e capire a quale tipo appartiene per collegarlo poi al socket relativo. Per primo elabora l header a Data Link layer e lo processa, poi passa alle routines a livello IP, a quelle del livello di trasporto e così via. La comunicazione tra i vari livelli nel kernel di Linux avviene attraverso il socket kernel buffer (sk_buff), che viene quindi usato per passare i dati tra i diversi livelli e i network device drivers. Una rappresentazione grafica di questo buffer è la seguente: sk_buff{} next prev dev head data tail end Packet being handled next: puntatore al sk_buff{} successivo. prev: puntatore al sk_buff{} precedente. dev: device che stiamo usando. head: puntatore all inizio del buffer che contiene il nostro pacchetto. data: puntatore all inizio del campo data del protocollo in esame (dipende dal livello in cui ci troviamo). tail: puntatore alla fine del campo data del protocollo in esame (dipende dal livello in cui ci troviamo). end: puntatore alla fine del buffer contenente il nostro pacchetto. 6

8 Sostanzialmente quando si riceve un pacchetto il kernel compie i seguenti passi: il network device riceve il pacchetto. il network device converte i dati ricevuti e li mette nella struttura sk_buff. la struttura viene aggiunta alla Backlog Queue in attesa di essere processata. lo Scheduler determina a quale protocollo passare il pacchetto ricevuto. Lo scheduler sceglie il protocollo in base a quelli registrati nella struttura packet_type{} ; questa struttura contiene le informazioni relative al tipo di protocollo, al network device, al puntatore alla routine di elaborazione di quel protocollo e al puntatore alla prossima struttura packet_type{}. Il network handler del kernel processa i tipi di protocollo dei pacchetti in ingresso uno ad uno nelle varie strutture packet_type{}, ed è qui che agisce firecmp. Il modulo, attraverso la funzione dev_add_pack(), registra una nuova struttura del tipo packet_type{} che viene inserita tra il device driver e l ultima struttura registrata (che era la prima ad essere chiamata dallo scheduler). In questo modo firecmp si pone appena dopo il network device driver e tutti i pacchetti in ingresso vengono passati prima alla routine di servizio del nostro modulo e poi alle successive, così riusciamo ad elaborare tutti i dati senza disturbare gli altri processi di networking. 7