Intervista di Vincenzo Ciaglia a Luca Deri per Linux Magazine (numero 66, Agosto 2006).
Abito a Pisa anche se nel recente passato ho lavorato a Londra ed a Zurigo. Uso da sempre il Mac e dal 1995 uso anche Linux quando un mio amico mi installò uno delle prime Slackware sul portatile che usavo a quel tempo. Erano gli anni in cui MacOS crashava molto, il BeOS era una promessa ma non una realtà, ed ero alla ricerca di un sistema operativo Unix-like su cui poter sviluppare e divertirmi. Da lì ho continuato sempre ad usarlo e sono entrato nell'ottica della GNU. Infatti essendo utente Mac (contrariamente al mondo Windows) per me era facile trovare programmi gratuiti per gestire le necessità quotidiane, me quando ho iniziato pensatemente a programmare ho sentito la necessità di accedere anche al codice sorgente cosa che di solito in quegli anni non era possibile. Non ho mai preso in considerazione seriamente sistemi operativi BSD-like perchè a mio modo di vedere sono troppo "religiosi" e chiusi in sè stessi con comunità troppo frammentate e litigiose, divise tra la casta dei committers e quella del resto del mondo; ti ricordo che si sono viste fork di sistemi operativi perchè uno aveva perso il diritto di fare commit nel CVS :-). Insomma programmare deve essere un divertimento e la possibilità di poter creare q.cosa che sia utile ad altri. Negli ultimi 10-15 anni mi sono sempre occupato di networking, sviluppando applicazioni per il monitoraggio di rete (prima basate su OSI, poi SNMP) e negli ultimi 3 anni ho iniziato a sviluppare nel kernel di Linux per implementare quello che in user space non è possibile fare, come la cattura ed il filtraggio di pacchetti su reti veloci (1-10 Gbit). Diciamo che sono partito con i linguaggy ad alto livello, poi sono passato a scrivere nel kerne implementando nuovi moduli, quindi ho iniziato a scrivere driver ed adesso ho come passione le FPGA (Field Programmable Gate Array) che dovrebbero permettere a gente che ha sempre scritto software (come me) di poter mettere le mani sull'hardware in modo da programmarlo a piacere. I miei passatempi informatici sono la programmazione, il networking ed i sistemi embedded. Il prossimo progetto è sicuramente software ma molto vicino all'hardware.
In breve ntop è un tool per l'analisi passiva del traffico di rete. Ovvero è uno strumente che permette di analizzare i pacchetti ricevuti su una scheda di rete e di catalogarli secondo vari criteri (protocollo, utente, ora del giorno etc.). ntop è fondamentamente un demone di rete che raccoglie i pacchetti e li presenta tramite un web server embedded. Essendo io un utente Mac, per me la semplicità e fondamentale e quindi ho scelto di creare ntop in modo che fosse completo in se stesso. Ovvero, una volta fatto partire ntop non volevo che ci fosse nulla da configurare o che si utilizzassero programmi esterni (es. apache) per implementare parti del programma. Tramite l'interfaccia web è possibile accedere a tutte le informazioni cheha in pancia ntop senza bisogno di linea di comando o altro.
Perchè a quel tempo (era il 1998) avevo un piccolo contratto con l'università di Pisa dove analizzavo il traffico di rete. Ogni volta che c'era un rallentamento ero accusato del problema in quanto smanettavo con le reti. Ero quindi alla ricerca di un programma che mi facesse capire cosa non funzionava e soprattutto che dimostrasse che io con quei problemi non c'entravo nulla. Siccome tale strumento non esisteva così come lo avevo in mente, ho iniziato a scrivere ntop. Nella mia idea iniziale mi sarebbe stato utile per quel piccolo contratto che avevo, ma poi man mano che la gente ha iniziato ad utilizzarlo ho provato a farlo uscire dalla nicchia in cui l'avevo fatto nascere e quindi è nato ntop, pian piano anno dopo anno.
E' semplice da usare, non intrusivo, può essere utilizzato da chiunque sa utilizzare un browser web, è integrato con protocolli commerciali (Cisco NetFlow e InMon sFlow), e gira un po' su tutte le piattaforme, incluso Windows, con lo stesso look & feel.
Nella versione post 3.2 (la 3.2 è stata rilasciata alla fine dello scorso anno) attualmente in CVS, ho deciso di affrontare un piccolo problema di stabilità di cui risentivano le versioni precedenti. Inoltre ho aggiunto il support SQL così che è possibile tener traccia in MySQL di tutto quanto accade in rete. Questo perchè fino alla 3.2 ntop manteneva uno storico salvando i dati in formato RRD, formato intelligente e compatto, ma che non teneva traccia delle attività. Mi spiego meglio: se c'è un'intrusione o un problema di rete, RRD mi fa vedere con i picchi di traffico che c'è q.cosa che non va ma non mi dice chi lo ha causato. Con MySQL spero di andare oltre in maniera da sapere nel recente passato cosa è successo. Un altro punto che vorrei sviluppare è di creare un mini-portale su ntop che permetta di creare dei report personalizzati. Vediamo se ci sarà posto per questo nella 3.3 o in una release successiva
Su Unix (Solaris, OSX, Linux, *BSD) e Windows. Non so se gira su altri sistemi (es. QNX) perchè non ho provato. I problemi sono stati all'inizio quando era necessario rendere il codice portatile. Adesso c'è solo da fare attenzione quando di scrive il codice di far si che non si usino strumenti dipendenti dalla piattaforma (es. la fork che su Windows non c'è)
Ho iniziato in C perchè era il giusto mix tra basso livello (necessario per manipolare i pacchetti) e velocità di esecuzione. Col tempo quando ntop è cresciuto sarebeb stato forse meglio usare il C++, quanto meno per modularizzare meglio il codice. Solo che ormai era troppo tardi e quindi ntop è ancora ora scritto in C.
Ho creato nProbe, che è un probe netflow (in altre parole cattura pacchetti e invece di generare statistiche come fa ntop, genera dei flussi che sono conformi allo standard Cisco NetFlow che è uno dei protocolli commerciali per l'analisi del traffico di rete) software di sicuro tra i più avanzati sul mercato. Poi è seguito PF_RING che è un modulo per il kernel di Linux per la accelerare la cattura dei pacchetti e che viene utilizzato dentro distribuzioni per router embedded (es. Linksys). Per finire c'è nBox che è una distribuzione basata su Debian che include ntop/nProbe/PF_RING e che permette di trasformare un (vecchio) PC in un probe di rete. Ti invito a visitare la pagina web di ntop per maggiori informazioni
Un po' ne ho già parlato sopra. Adesso stò lavorando ad un nuovo progetto chiamato CBM (Consumer Broadband Monitoring) assieme al RIPE. Ci partecipo assieme ad alcuni studenti che quest'anno hanno seguito il corso che tengo al dipartimento di informatica dell'unviersità di Pisa. L'idea è di riuscire a monitorare la rete utilizzando i router comunemente usati per andare su internet (es. i router ADSL) per il mercato consumer. In altre parole vogliamo dare all'utente una vista di quello che accade nella sua rete dal punto di vista utente e non dal punto di vista dell'ISP. Attualmente stà finendo la prima fase, e tra poco partirà la seconda. Contiamo di finire il progetto per questo autunno e di rilasciare tutto il software sotto GPL, incluso il firmware per i router.
Forse dirò una cosa che diventerà un boomerang, ma io credo che nel 2006 sia il tempo di lasciare la sicurezza e lavorare ad altro. Ormai tutti gli OS (forse a parte alcune versioni di Windows) sono abbastanza robusti da questo punto di vista, i firewall ce ne sono di tutti i tipi e vengono gratis dentro prodotti anche per il mercato consumer. Se continuano ad esserci virus o bachi, questa è una conseguenza dell'utilizzo di sistemi operativi obsoleti o di cattive configurazioni. Insomma è tempo di smetterla con la sicurezza: chi ha voglia di avere un sistema sicuro non usi Windows, chi lo vuol continuare ad utilizzare sa bene che avrà da divertirsi con antivirus e altro ben consapevole di non riuscire a risolvere il problema.
Basta utilizzare software ben scritto, mettere in piedi un minimo di sicurezza (es. utilizzare un router ADSL invece del modem per non essere esposti direttamente su Internet) e non configurare i sistemi troppo male. Tools come snort e tripwire non fanno per me.
Uso la Fedora perchè è il giusto mix tra innovazione, compatibilità con le distribuzioni commerciali (es. RedHat), e facilità d'uso.
Il corso (SGR) insegna i fondamenti della gestione di rete, da SNMP al monitoraggio del traffico alla varie problematiche che ci si trova ad affrontare quando si vuol sapere cosa passa nel cavo ethernet connesso alla nostra rete. E' un corso ufficiale con tanto di esame e crediti, ma da un certo punto di vista è un po' diverso da molti altri perchè cerco di essere disponibile nel possibile e moderno utilizzando mailing list, appunti del corso in formato MP3 e libertà massima per gli esami, compatibilmente con le regole d'ateneo. In sostanza per me è più importante che gli studenti siano attratti dal corso perchè sanno che impareranno q.cosa che gli tornerà utile più che per il voto finale.
Suggerisco di leggere libri ma soprattutto di lavorare alla tastiera. Infatti non si può capire come gestire una rete senza averci mai messo le mani. Mi ricordo sempre uno dei primi manuali di Linux che definiva un network come "a hacker with a modem". Inoltre dico sempre ai miei studenti di non perdere mai di vista il problema da risolvere senza impantanarsi nelle mode. Un po' di anni fa andava di moda java, adesso se non si usa l'XML o il C# sei out. La verità è che le mode informatiche ci sono e sempre ci saranno, ma che bisogna risolvere i problemi. All'università le persone raccontano troppo spesso di mode e poco di sostanza. Questa non è una critica ma un dato di fatto, questo perchè molti degli insegnanti usa la tastiera per scrivere articoli piuttosto che codice. E quindi non si può pretendere che l'università formi degli hacker (nel senso buono del termine) se chi insegna non è mai stato tale, con il risultato che la maggior parte dei neo laureati parla di informatica come si fa in salotto o al bar, senza averne mai fatto conoscenza. Forse sono stato troppo diretto, ma spero di aver chiarito il concetto, senza aver fatto arrabbiare nessuno dei lettori :-).
Come ti ho detto il progetto CBM prende parte del tempo anche se è più un progetto di sviluppo che di ricerca. Adesso stò lavorando sul filtraggio dei pacchetti al alta velocità. Grazie ai filtri di Bloom sono riuscito ad implementare nel kernel di Linux la possibilità di avere centinaia/migliaia di filtri di tipo (protocollo,indirizzo IP, porta) in maniera da andare oltre il concetto di filtro BPF dove hai un solo filtro, maari molto complesso. Adesso è in uno stadio di prototipo avanzato ma su un dual Xeon riesco a filtrare oltre 1.7 Mpps senza perdite. L'idea è che sulle reti veloci (1-10 Gbit) non si può/vuole analizzare tutto ma solo quello che ci interessa. Immagina di mettere ntop su un backbone di rete a 10 Gbit e di dirgli di analizzare solo il traffico di alcuni PC senza considerare quindi il 99.9% del traffico. E' una bella sfida. Devo ancora capire cosa si riesce a fare in software e qual'è il limite oltre il quale occorre per forza utilizzare un hardware come l'FPGA. Non mancherò di informare la comunità su quanto riuscirò a produrre.
Grazie tante per avermi dato la possibilità di parlare dei miei interessi. Spero che questa intervista susciti un po' di interesse nei lettori e magari faccia venire la voglia a qualcuno(a) di darmi una mano con il codice visto che lavoro praticamente da solo. Aspetto le vostre mail e suggerimenti.