UNIVERSITÀ DEGLI STUDI DI TRIESTEDipartimento di Ingegneria e Architettura

Corso di Laurea Magistrale in Ingegneria Informatica

Tesi di Laurea in Reti di Calcolatori II

Compressione di insiemi di espressioniregolari tramite programmazione

genetica in sistemi di rilevazione delleintrusioni

LAUREANDO RELATORE

Simone Cumar Chiar.mo Prof. Alberto BartoliUniversità degli Studi di Trieste

CORRELATORE

Chiar.mo Prof. Eric MedvetUniversità degli Studi di Trieste

Anno Accademico 2012/2013

Indice

1 Introduzione 1

2 Contesto 32.1 Sistemi di Rilevazione delle Intrusioni . . . . . . . . . . . . 32.2 Espressioni Regolari . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Motori NFA vs DFA . . . . . . . . . . . . . . . . . 42.2.2 Implementazione su FPGA . . . . . . . . . . . . . 5

2.3 Programmazione Genetica . . . . . . . . . . . . . . . . . . 62.4 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Progettazione e Realizzazione 93.1 Esempi e Dataset . . . . . . . . . . . . . . . . . . . . . . . 103.2 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 Algoritmo Set Coverage . . . . . . . . . . . . . . . 113.3.2 Ruleset Completion . . . . . . . . . . . . . . . . . 12

3.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Dataset di Espressioni Regolari . . . . . . . . . . . . . . . 133.6 Generazione Dataset di Esempi da Espressioni Regolari . . 14

4 Valutazione Sperimentale 174.1 Parametri iniziali . . . . . . . . . . . . . . . . . . . . . . . 174.2 Ruleset Iniziali . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.1 Confronto . . . . . . . . . . . . . . . . . . . . . . . 224.3.2 Importanza Ruleset Completion . . . . . . . . . . . 224.3.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Analisi dell’Evoluzione . . . . . . . . . . . . . . . . . . . . 24

i

ii INDICE

5 Conclusioni 295.1 Considerazioni sui Risultati . . . . . . . . . . . . . . . . . 295.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.1 Metriche . . . . . . . . . . . . . . . . . . . . . . . . 295.2.2 Modifiche all’algoritmo di Set Coverage . . . . . . 305.2.3 Generazione dei Dataset di Esempi . . . . . . . . . 30

A Dettagli Implementativi 31A.1 RE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

B Approfondimenti 33B.1 Distanza di Edit . . . . . . . . . . . . . . . . . . . . . . . 33B.2 Set Cover . . . . . . . . . . . . . . . . . . . . . . . . . . . 33B.3 Quantificatori Greedy e Possessive . . . . . . . . . . . . . 34

Elenco delle figure 35

Elenco delle tabelle 37

Bibliografia 39

Capitolo 1

Introduzione

Un meccanismo di sicurezza informatico divenuto ormai dominante nelcampo delle reti di calcolatori è la classificazione dei pacchetti in baseall’analisi, non solo della tipologia di traffico trasportato (protocollo),ma anche del payload. Tale tecnica ricerca all’interno del traffico speci-fiche sequenze di byte, chiamate signature, che caratterizzano particolariattacchi.

Uno strumento molto versatile ed ampiamente utilizzato a tale sco-po è quello delle espressioni regolari. Esse permettono di descrivere unconsiderevole numero di signature diverse in maniera molto sintetica. Laloro implementazione richiede però un ingente quantitativo di memoriae di capacità di calcolo. Come conseguenza diretta un notevole nume-ro di lavori recenti ha indagato le possibilità di ridurre tali problema-tiche, concentrandosi prevalentemente sull’ottimizzazione dei motori divalutazione delle espressioni regolari [1, 2] e sulla loro realizzazione inhardware [3, 4, 5, 6, 7].

In questo lavoro di tesi, svolto all’interno del Machine Learning Labdell’Università di Trieste, è stato affrontato il problema dal punto di vistadella riduzione del numero di espressioni regolari da analizzare. In par-ticolare è stata sviluppata e valutata sperimentalmente una metodologiaper la compressione degli insiemi di espressioni regolari che descrivono ipattern di traffico da rilevare. La metodologia è basata su un paradigmadi calcolo evoluzionistico (genetic programming) ed è stata valutata suinsiemi di espressioni regolari adatti ai sistemi di intrusion detection edutilizzati in letteratura. I risultati dimostrano la possibilità di ridurrequesti insiemi dell’ordine del 70% sia per quanto riguarda il numero dielementi sia per quanto riguarda la lunghezza aggregata delle espressioni.

Di seguito saranno esposte le ricerche effettuate, il contesto nel quale

1

2 CAPITOLO 1. INTRODUZIONE

il lavoro si colloca e gli obiettivi preposti, la metodologia per raggiungerli,la modalità di valutazione della stessa ed i possibili sviluppi futuri.

Capitolo 2

Contesto

2.1 Sistemi di Rilevazione delle Intrusioni

I sistemi di rilevazione delle intrusioni (o NIDS, Network Intrusion De-tection System) sono degli strumenti estremamente utili ed impiegati nelcampo della sicurezza informatica. Il loro compito è quello di identificarepossibili minacce per il sistema stesso e permettere all’amministratore disistema di agire conseguentemente. È chiaro come tutto il traffico damonitorare debba essere scansionato alla ricerca degli attacchi informa-tici e come tutto ciò potrebbe portare ad un rallentamento della retestessa. È pertanto fondamentale curare le performance di tali sistemiaffinché incidano il meno possibile sull’andamento del sistema completo.Una delle parti più critiche dei NIDS è quella che si occupa della gestio-ne delle espressioni regolari; svilupperemo maggiormente il discorso delleespressioni regolari nella sezione 2.2.

Snort Tra i vari NIDS disponibili al momento ce n’è uno che spicca sututti, soprattutto come riferimento nel mondo scientifico dove è diventatopraticamente uno standard de facto per i set di espressioni regolari [1, 2,4, 5, 6, 8, 9]. Tale NIDS, Snort [10], verrà utilizzato come base duranteil proseguo del lavoro.

2.2 Espressioni Regolari

Le espressioni regolari 1 sono uno strumento matematico formato da unaserie di caratteri e meta-caratteri utilizzati per descrivere in modo com-patto insiemi di stringhe [11]. Essenzialmente i caratteri sono quelli

1Altre possibili diciture sono: Regular Expression, Regex, RE

3

4 CAPITOLO 2. CONTESTO

presenti nell’alfabeto delle stringhe, mentre i meta-caratteri rappresen-tano gli operatori di concatenazione ·, raggruppamento (), unione ∪ el’operatore stella *. L’insieme di stringhe identificate da un’espressioneregolare è detto linguaggio riconosciuto dall’espressione regolare ed ap-partiene alla classe dei linguaggi regolari. È inoltre dimostrato[11] cheespressioni regolari ed automi a stati finiti (sia deterministici che non de-terministici) descrivono le stesse classi di linguaggi, ossia che tali metodidi rappresentazione sono tra loro equivalenti.

Oltre a queste premesse matematiche, è importante sottolineare quan-to le espressioni regolari siano versatili ed utilizzate nel mondo reale peresprimere una notevole quantità di pattern in modo sintetico. Esse infat-ti sono presenti sia dove è opportuno riconoscere stringhe (appartenentio meno ad un certo linguaggio), sia dove è importante estrarre sotto-stringhe, sia dove è importante sostituire parti di stringhe. Solitamentepresentano maggiori elementi rispetto alle espressioni regolari pure edintroducono costrutti come le ancore per rappresentare l’inizio e la finedella stringa ed altri, quali le backreference, che aumentano le potenzia-lità (intesa come linguaggi descrivibili) delle espressioni stesse e che nonverranno considerate in questo lavoro.

Dal punto di vista pratico esistono diversi metodi per valutare un’e-spressione regolare su di una stringa. Essenzialmente tali metodi sonosuddivisibili in due grandi filoni: i motori NFA (Nondeterministic FiniteAutomata) ed i motori DFA (Deterministic Finite Automata) [11, 12, 13].

2.2.1 Motori NFA vs DFA

I motori DFA, a partire da un’espressione regolare, producono un automaa stati finiti deterministico che ne riconosca la lingua, ossia che ricevendoin ingresso una stringa produca l’output appartiene/non-appartiene. Es-sendo un automa deterministico, esso può processare l’ingresso in modoestremamente efficiente; purtroppo però la sua costruzione introduce unoverhead non trascurabile. Inoltre esso è limitato alle espressioni regolaripure [14] e con particolari espressioni regolari patologiche può risultarein un’esplosione del numero di stati che lo rende praticamente non utiliz-zabile nel nostro lavoro 2. Non è però trascurabile il fatto che tentatividi ottimizzare la transizione da espressioni regolari a DFA sono presentianche recentemente [2] e che in futuro si possa optare per questa scelta.

I motori NFA non presentano i problemi descritti prima. Al con-trario essi vengono utilizzati in molti articoli [1, 6, 15] che propongono

2L’uso dei quantificatori greedy, illustrato nella sezione 3, può portare proprio aqueste conseguenze.

2.2. ESPRESSIONI REGOLARI 5

Figura 2.1: Comparazione Motori Espressioni Regolari

varie soluzioni per convertire insiemi di espressioni regolari in automi astati finiti non deterministici e per la loro implementazione su FPGA.Esistono diversi algoritmi per cercare di ottimizzare la transizione daespressione regolare ad NFA [12] tra i quali è opportuno citare l’algo-ritmo di Thompson [16] che risulta essere estremamente efficiente com-parato con altre implementazioni [17], comunque incredibilmente diffuse.Si può vedere in figura 2.1 una comparazione tra diverse implementazio-ni nella quale è raffigurato il tempo impiegato dall’espressione regolarea?nan per identificare il match con an 3. Bisogna però rilevare ancheun lato negativo dei motori NFA: la loro minimizzazione è un problemaPSPACE-completo [18, 19] quindi, attualmente 4, non affrontabile.

2.2.2 Implementazione su FPGA

I Field Programmable Gate Array sono dei dispositivi elettronici il cuicomportamento a livello fisico non è fissato a priori, come per gli ASIC,ma definibile al momento dell’utilizzo. Nel nostro campo di interessequesta caratteristica è molto importante e li rende preferibili ai circuitiASIC in quanto la base di espressioni regolari utilizzati da un NIDS èin continuo aggiornamento e pertanto il motore deve essere facilmentemodificabile. Durante lo svolgimento del lavoro si sono riscontrate molte

3Ad esempio la RE “a?a?a?aaa” e la stringa “aaa”4Alcune relazioni tra gli insiemi P, NP, PSPACE sono ancora oggetto di discussione.

Quella tra P ed NP è uno dei famosi Problemi del Millennio http://www.claymath.org/millennium-problems

6 CAPITOLO 2. CONTESTO

ricerche indirizzate all’implementazione su FPGA delle regole di Snortper aumentarne le prestazioni in termini di larghezza di banda [3, 4, 5, 6,15, 20, 21]. È importante sottolineare come in tutti questi lavori le risorsenecessarie ad un’implementazione completa siano consistenti e che quindila ricerca di metodi per ridurne l’utilizzo è tuttora un problema reale.

Per quanto riguarda un NFA, una stima dell’occupazione di risorse sipuò trovare in [15] e si basa essenzialmente su tre fattori:

1. State Count – Il numero di stati complessivo;

2. State Size – Il numero di stati con transizione libera verso unqualsiasi altro stato;

3. Fan Size – Il numero di stati con transizione libera da un qualsiasialtro stato.

Una buona stima dello State Count è la lunghezza dell’espressione rego-lare stessa, in quanto l’algoritmo di Thompson costruisce un automa astati finiti non deterministico il cui numero di stati è proporzionale allalunghezza dell’espressione regolare[22].

2.3 Programmazione Genetica

La programmazione genetica è un metodo automatico per creare pro-grammi utilizzando strumenti di evoluzione artificiale [23]. Ispirandosiprofondamente all’evoluzione naturale molta della nomenclatura riprendetermini utilizzati in biologia. Un programma che partecipa all’evoluzio-ne è infatti chiamato individuo; per valutare l’adattamento dell’indivi-duo al problema vengono definite delle metriche, dette fitness, che sonofortemente dipendenti dal problema.

L’evoluzione prosegue a step, ad ogni singolo step è presente un in-sieme di programmi che forma la generazione. Durante l’evoluzione, aseconda delle metriche definite, ogni individuo ha una certa probabilitàdi passare alla generazione successiva senza subire modifiche 5, oppuretramite degli operatori genetici come la mutazione ed il crossover :

• Mutazione – l’individuo subisce una modifica e l’individuo modifi-cato viene inserito nella generazione successiva;

• Crossover – presi due individui essi vengono mescolati per otteneredue nuovi individui per la generazione successiva.

5Questa tecnica è chiamata elitarismo.

2.4. OBIETTIVI 7

Inoltre, nuovi individui possono venire introdotti ad ogni generazione peraumentare l’esplorazione dello spazio delle soluzioni. La popolazione ini-ziale è tipicamente formata da individui generati in modo casuale, masono possibili diverse varianti a seconda del problema specifico affron-tato. Il processo prosegue fino al raggiungimento di un qualche criteriodi terminazione: se si raggiunge un ottimo, dopo un certo numero dievoluzioni, etc. Il primo, seppur sembri un criterio ideale, a volte non èutilizzabile in quanto può non essere possibile identificare una soluzioneottima. In figura 2.2 è rappresentato un processo tipico, con il ciclo dievoluzioni che si ripete.

Figura 2.2: Programmazione Genetica

2.4 Obiettivi

L’obiettivo ultimo di questo lavoro è quello di comprimere un insiemedi espressioni regolari. A tale scopo si cercherà di trovare un insieme diespressioni regolari diverso, ma equivalente a quello iniziale.

Riconoscimento di una stringa Definiamo che un insieme di espres-sioni regolari R riconosce una stringa s se esiste almeno un’espressione re-golare r contenuta in R che, applicata ad s, ne estragga una sotto-stringa,diversa dalla stringa vuota.

Equivalenza tra insiemi di espressioni regolari Definiamo cheun insieme di espressioni regolari R1 è equivalente ad un insieme diespressioni regolari R2 se R1 riconosce le stesse stringhe di R2 e viceversa.

8 CAPITOLO 2. CONTESTO

Compressione di un insieme di espressioni regolari L’obiettivofinale è quello di comprimere un insieme di espressioni regolari e consistenell’ottenere, a partire da un insieme di espressioni regolariR1, un insiemead esso equivalente R2 tale che la cardinalità di R2 sia inferiore allacardinalità di R1. In tal modo si cerca di diminuire la lunghezza aggregatadell’insieme che, come già accennato nella sezione 2.2.2, è una buonastima della complessità e dell’utilizzo di risorse FPGA.

Metriche L’approccio di questa tesi consiste nell’applicare una ricercaeuristica nello spazio degli insiemi di espressioni regolari basata su unparadigma evoluzionistico, il genetic programming. Come già descritto,il genetic programming necessita della definizione di alcune metriche 6 perpoter valutare le diverse soluzioni. Nel corso del lavoro saranno utilizzatele seguenti:

• Lunghezza stringa – la lunghezza dell’individuo deve venire mini-mizzata;

• Distanza di Edit – la distanza di edit 7 tra le sotto-stringhe estratteda un individuo e quelle desiderate (cioè quelle estratte dall’insiemedi partenza) deve essere minimizzata;

• Set Coverage – più individui insieme devono essere scelti cercan-do di formare un insieme il più possibile equivalente con quello dipartenza 8.

6Discusse maggiormente nelle sezioni 3.2 e 3.37Una metrica classica per la distanza tra stringhe [24]8Si tratta di un problema di Set Covering e pertanto è NP-Completo[25]

Capitolo 3

Progettazione e Realizzazione

In questo capitolo verranno esposti la metodologia basata sul geneticprogramming che si è utilizzata ed i vari metodi ausiliari necessari allastessa.

Come anticipato, la genetic programming esegue una ricerca di ottimofacendo evolvere gli individui. Ogni individuo costituisce una possibilesoluzione al problema e dev’essere valutato in funzione di alcune metriche.Nel nostro caso ogni individuo è un’espressione regolare descritta sottoforma di albero sintattico [26, 31].

Ogni foglia dell’albero appartiene ad un certo insieme predefinito det-to terminal set. Tale insieme contiene gli elementi delle espressioni rego-lari che hanno un significato a sé stante e non operano su altri elementidell’espressione regolare. Alcuni esempi sono le constanti e i range.

Ogni nodo interno dell’albero appartiene ad un insieme predefinitodetto functions set, contenente i vari operatori delle espressioni regolari.Gli operatori sono particolari elementi delle espressioni regolari che de-finiscono delle operazioni su altri elementi dell’espressione regolare. Unesempio è l’operatore condizionale ? : esso viene applicato ad un altroelemento per indicare che quell’elemento può essere presente o meno nel-la stringa da estrarre 1. Gli operatori considerati in questo lavoro sonoquelli già utilizzati in [26, 31] con l’eccezione dei quantificatori greedy chehanno sostituito i possessive; questa sostituzione si è resa necessaria per-ché i quantificatori greedy sono presenti nelle espressioni regolari raccolte,al contrario dei possessive (si veda l’appendice B.3 per una descrizionedelle differenze tra quantificatori greedy e possessive).

La figura 3.1 illustra con maggiore efficacia l’albero corrispondente adun’espressione regolare.

1L’espressione regolare ab?c riconosce sia la stringa ac che la stringa abc.

9

10 CAPITOLO 3. PROGETTAZIONE E REALIZZAZIONE

Figura 3.1: Albero relativo all’espressione regolare ab|c|d*

Sia functions set che terminal set utilizzati durante gli esperimentisaranno elencati nella sezione 4.1.

3.1 Esempi e Dataset

Per determinare l’adattamento di un individuo al problema, esso vienevalutato su delle stringhe di riferimento di cui è conosciuta la sotto-stringada estrarre. La coppia stringa di riferimento, sotto-stringa da estrarre èdetta esempio.

Si possono individuare due categorie: esempi positivi ed esempi ne-gativi. I primi sono gli esempi da cui si vuole estrarre qualcosa, ossia lasotto-stringa da estrarre non è nulla; i secondi sono quelli da cui non sivuole estrarre niente, ossia la sotto-stringa da estrarre è nulla.

Insiemi di esempi sono detti dataset. Per ognuna delle 3 fasi spiegatein seguito (Training, Validation, Testing) è necessario generare un datasetdiverso.

3.2 Training

L’evoluzione degli individui avviene tramite una fase di addestramentodetta Training in cui agli individui vengono applicati gli operatori geneticidi mutazione e crossover.

La strategia di training si basa su una ricerca di ottimo multi-obiettivo.Già nella sezione 2.4 si erano anticipate le metriche d’interesse; in par-

3.3. VALIDAZIONE 11

ticolare la strategia di Training si concentra sulle metriche: lunghezzaindividuo e distanza di Edit.

La lunghezza dell’individuo è semplicemente il numero di caratteri emeta-caratteri che compongono la RE ed è quindi da minimizzare. Ladistanza di Edit è invece considerata tra le stringhe estratte dall’individuoe le stringhe desiderate: più è grande tale distanza, meno l’individuo èadatto al problema, quindi anche questa metrica è da minimizzare. Sinoti come tali metriche siano relative al singolo individuo e non tenganoconto di un insieme di individui.

3.3 Validazione

Questa fase è successiva a quella di Training ed è quella che ricerca l’insie-me di individui minimo (se esiste) per ricoprire il dataset. In realtà verràeseguita questa fase anche durante l’evoluzione, ma solo per monitorarnel’andamento. Obiettivo di tale strategia è la ricerca dell’insieme di indi-vidui che massimizzi il numero di esempi correttamente riconosciuti suldataset di validazione. Tale ricerca avviene sugli individui ottenuti dallafase di training e si compone di due algoritmi:

1. Algoritmo Set Coverage;

2. Algoritmo Ruleset 2 Completion.

Il primo permette la riduzione dell’insieme di partenza ad un insiemepiù piccolo, cercando però di massimizzare il riconoscimento degli esem-pi. Il secondo cerca di migliorare ulteriormente il riconoscimento degliesempi aggiungendo all’insieme da ridurre anche le espressioni regolari dipartenza.

3.3.1 Algoritmo Set Coverage

L’algoritmo di Set Coverage è un algoritmo greedy, in quanto ricerca l’ot-timo globale effettuando, ad ogni passo, la migliore scelta locale. Si trattadi un algoritmo euristico 3, purtroppo algoritmi ottimi non sono utilizza-bili per la loro complessità non polinomiale. Gli input dell’algoritmo sonoun generico ruleset e due set di esempi: uno comprendente esempi solopositivi, l’altro esempi solo negativi. Chiameremo il ruleset R, l’insiemedegli esempi positivi P e quello dei negativi N . L’output dell’algoritmo è

2Per brevità chiameremo ruleset gli insiemi di espressioni regolari.3Non c’è nessuna garanzia che la scelta locale ottima porti ad un ottimo globale.

12 CAPITOLO 3. PROGETTAZIONE E REALIZZAZIONE

un sotto-insieme R′ di R che cerca di massimizzare gli esempi (positivi enegativi) correttamente riconosciuti. Chiameremo R′ Resulting CoverageSet.

Procedimento L’algoritmo è diviso in passi, ad ogni passo i si selezionauna nuova espressione regolare da aggiungere a R′, inizialmente vuoto.Chiameremo R′i l’insieme R′ al termine del passo i.

Definiamo inoltre Pi come il sotto-insieme di P correttamente ricono-sciuto da R′i e Ni l’insieme di esempi negativi correttamente riconosciutida R′i. È importante notare che la cardinalità di Pi può solo aumentare(al più rimanere costante) con i e la cardinalità di Ni può solo diminui-re (al più rimanere costante) con i. Questo perché aggiungendo nuoveespressioni regolari si possono correggere eventuali falsi negativi, ma nonsi possono correggere falsi positivi.

Per ogni ruleset definiamo il Set Coverage Index (SCI) come il numerodi esempi correttamente riconosciuti, siano essi positivi o negativi. Illimite superiore per SCI è dato dalla cardinalità di tutti gli esempi,ovvero |P |+ |N |. Inoltre definiamo SCIi come il valore di SCI associatoa R′i.

Al passo iniziale si seleziona da R la regex che massimizza SCI0,ovvero quella che riconosce correttamente il più grande sottoinsieme diD = P ∪N , e la si aggiunge direttamente a R′.Al passo i si seleziona rei ∈ R−R′i−1 tale da riconoscere correttamente ilpiù grande sottoinsieme di D−Pi−1. Se R′i−1 ∪{rei} possiede un SCI >SCIi−1, allora si aggiunge rei a R′ e si prosegue col passo successivo,altrimenti l’algoritmo si interrompe immediatamente.

Nel caso peggiore tale algoritmo continua finché R − R′i−1 6= ∅, ossiafinché posso aggiungere nuove espressioni regolari a R′.

È importante sottolineare come gli esempi positivi e negativi sianotrattati in maniera differente.

3.3.2 Ruleset Completion

Una volta estratto il Resulting Coverage Set, possiamo cercare di miglio-rarne l’accuratezza aggiungendo ad esso l’insieme di espressioni regolari dipartenza, che sicuramente non peggiorano il riconoscimento degli esempiessendo le espressioni regolari utilizzate per classificarli, ed eseguire unaseconda volta l’algoritmo di Set Coverage. In tal modo si cercano di mi-gliorare le caratteristiche del ruleset senza intaccarne troppo la lunghezzacomplessiva.

3.4. TESTING 13

3.4 Testing

La fase di Testing serve a valutare i risultati ottenuti. Consiste nel sotto-porre al Resulting Coverage Set un dataset completamente nuovo (diversosia da quello di Training che da quello di Validation) e valutare il numerodi riconoscimenti corretti effettuati. Tale fase è fondamentale in quantofornisce delle indicazioni sulla generalità della soluzione.

3.5 Dataset di Espressioni Regolari

I dataset di espressioni regolari sono stati raccolti concentrandosi sulNIDS Snort, come descritto nella sezione 2.1, e recuperati grazie al pro-getto Netbench [27], creato per confrontare diversi algoritmi ed approccisullo studio delle espressioni regolari.

Da espressione regolare ad albero Il parsing dell’espressione rego-lare è stato realizzato grazie alla libreria PCREParser [28]: tale libreriapermette già di ottenere una discrezione ad albero della RE, ma a questopunto è necessario convertire questa descrizione in quella già adoperatain GP [26].

Limitazioni PCRE Non tutte le caratteristiche delle espressioni rego-lari sono state considerate. Alcune di esse, come le backreference, nonsono praticamente utilizzate in Snort e pertanto non influenzano il lavoro;altre, invece, sono presenti nei ruleset di riferimento, ma non sono stateanalizzate:

• Ancore (^, $) – Identificano l’inizio e la fine di una stringa e nonsono stati considerate;

• Modificatori – Non sono stati considerati i modificatori che alteranoil comportamento della stringa, ad esempio rendendo la ricerca case-insensitive. In alcuni casi sarebbero sostituibili agevolmente, adesempio il modificatore DOTALL aggiunge ai caratteri riconosciutidal metacarattere . anche i newline, altrimenti esclusi. Per ottenerelo stesso effetto si può effettuare la sostituzione di . in [.\n].

14 CAPITOLO 3. PROGETTAZIONE E REALIZZAZIONE

3.6 Generazione Dataset di Esempi da Espressio-ni Regolari

Lo scopo di questa sezione è quello di illustrare come sono stati generatii dataset di esempi da utilizzare durante l’evoluzione. Si ricorda che gliesempi sono composti da una stringa e da una sua sotto-stringa estrattada una regular expression nel ruleset. È chiaro che la stessa stringapotrebbe contenere più sotto-stringhe riconosciute anche da espressioniregolari diverse; nel caso questa eventualità dovesse verificarsi si sceglieuna sola delle sotto-stringhe in maniera arbitraria. La generazione ditali esempi ha seguito due strade diverse per poter generare sia esempinegativi che positivi.

Esempi Negativi Si è scelto di generare stringhe casualmente 4. Èassai probabile che tali stringhe non vengano riconosciute dalle espressioniregolari e pertanto che diventino degli esempi negativi. Il fatto che possacapitare non deve turbare, tali esempi positivi saranno comunque limitatie piccole modifiche al bilanciamento tra insiemi positivi e negativi nonsono rilevanti.

Esempi Positivi Per la generazione di esempi positivi si è dovuto pro-cedere in modo diverso; è stato ideato ed implementato un algoritmospecifico:

1. Trasforma le espressioni in un albero; l’albero in questione ha lastessa struttura di quello utilizzato nell’evoluzione.

2. Percorri l’albero con il metodo DFS 5; genera una stringa ogni voltache visiti un nodo e ritornala al nodo genitore;

3. Per ogni nodo, applica la corretta strategia:

• Quantificatori – Genera un intero N casualmente; per N voltevisita il nodo figlio generando una nuova stringa; ritorna laconcatenazione di tutti i risultati. L’intervallo in cui N puòricadere dipende dallo specifico quantificatore:

4Tale soluzione è ovviamente opinabile, possibili alternative saranno presentatenelle conclusioni.

5Depth-First Search.

3.6. GENERAZIONE DATASET DI ESEMPI DA ESPRESSIONI REGOLARI15

Quantificatore Intervallo* [0,∞]

+ [1,∞]

{a ,b} [a, b]

Per ovvie ragioni, nell’implementazione effettiva l’intervallo ètroncato;

• Character Class – Ottieni tutti i possibili caratteri dai nodifigli e ritornane uno scelto casualmente;

• Negated Character Class – Ottieni tutti i possibili caratteri dainodi figli e ritorna casualmente uno non contenuto all’internodell’insieme;

• Concatenazione – Concatena le stringhe generate dai figli;

• Disgiunzione –È un operatore binario e pertanto bisogna te-ner conto che disgiunzioni consecutive sono convertite in unacascata di disgiunzioni nell’albero. Per poter scegliere in mo-do più equo la stringa, ogni disgiunzione richiede le possibiliscelte ad entrambi i figli e la disgiunzione radice ne sceglie unacasualmente;

• Costante – Ritorna semplicemente il valore;

• Range – Sono presenti solo all’interno di classi di caratteri epertanto ritornano tutti i possibili caratteri.

Una volta generati tutti gli esempi, essi sono stati analizzati alla ri-cerca delle sotto-stringhe riconosciute dallo specifico ruleset. A seguito diquesto passaggio i dataset sono stati divisi in 3 diversi insiemi, uno perogni fase 6.

6Training, Validation, Testing.

Capitolo 4

Valutazione Sperimentale

Nel corso degli esperimenti sono stati monitorati diversi indici, utili pertrarre indicazioni sull’andamento delle generazioni. Tali indici sono rela-tivi al Resulting Coverage Set e sono valutati in riferimento al validationdataset durante l’evoluzione ed al testing dataset una volta terminata lastessa:

• Accuracy – La percentuale di match (positivi e negativi) corretta-mente riconosciuti;

• FPR – False Positive Rate, il rapporto tra il numero di falsi positivie negativi desiderati;

• FNR – False Negative Rate, il rapporto tra il numero di falsi nega-tivi e positivi desiderati;

• #regex – La cardinalità;

• Σ l – La somma delle lunghezze delle espressioni regolari.

Tutti gli esperimenti sono stati effettuati su un quad core Intel XeonE5-2440 (2.40GHz) con 4GB di RAM ed i tempi di esecuzione sono statidell’ordine delle 4/5 ore.

4.1 Parametri iniziali

In tutte le sessioni di ottimizzazione, la popolazione iniziale è formata da500 individui, di cui una parte è composta dalle espressioni regolari daridurre, l’altra da espressioni generate casualmente. Per ogni sessione so-no stati effettuati 4 differenti job, ossia 4 diverse evoluzioni inizializzando

17

18 CAPITOLO 4. VALUTAZIONE SPERIMENTALE

in maniera differente il generatore di numeri pseudo-casuale; in tal modosi è potuto aumentare l’esplorazione. Come criterio di terminazione, si èposto un limite di generazioni pari a 500.

Inoltre è necessario definire anche i due insiemi (terminal set e func-tions set) con cui si descrivono gli individui:

• Il terminal set – range a-z e A-Z, lettere maiuscole e minuscole,cifre, le classi di caratteri \d, \w, \s, \D, \W, \S ed i caratteri ‘-’,‘?’, ‘(’, ‘)’, ‘{’, ‘}’, ‘.’, ‘@’, ‘#’, ‘_’, ‘ ’.

• Function set – (•), [•], [ˆ•], •·•, •∗, •+, •?, •{a, b}, •|•.

Per uno degli esperimenti, ossia per quello relativo al policy.rules.pcre,si sono aggiunti anche i caratteri appartenenti al range \x00 - \x07,presenti tra le costanti del ruleset.

Evoluzione Durante l’evoluzione, la generazione della popolazione suc-cessiva segue le regole:

• I 5 migliori individui di una generazione vengono introdotti senzamodifiche in quella successiva;

• Il 60% degli individui restanti sono generati tramite crossover;

• Il 20% degli individui restanti sono generati tramite mutation;

• Il restante 20% è generato casualmente.

4.2 Ruleset Iniziali

Per questioni sia di tempo che di cardinalità dei ruleset iniziali, tra tutti idiversi gruppi disponibili presenti nel framework Netbench [27], sono statiselezionati i seguenti: chat.rules.pcre, pop3.rules.pcre, policy.rules.pcre eweb-php.rules.pcre. Nella tabella 4.1 sono riportate alcune caratteristichecome il numero di espressioni regolari e la somma delle loro lunghezze.

Nello specifico le espressioni regolari da ridurre sono:

• Ruleset chat.rules.pcre

1 [a-zA-Z]+\s+\x2Findex\x2Ejsp\x3Flogout\x3Dtrue.*\x2E\x2E\x2F

2 [a-zA-Z]+\s+\x2Flogin\x2Ejsp.*\x2E\x2E\x2F3 [a-zA-Z]+\s+\x2Fsetup\x2Findex\x2Ejsp.*\x2E\x2E\x2F4 [a-zA-Z]+\s+\x2Fsetup\x2Fsetup-.*\x2E\x2E\x2F

4.2. RULESET INIZIALI 19

Ruleset #regex Σl

chat.rules.pcre 14 307policy.rules.pcre 10 260pop3.rules.pcre 16 265

web-php.rules.pcre 16 400

Tabella 4.1: Ruleset Stats

5 [a-zA-Z]+\s+\x2F\x2Egif.*\x2E\x2E\x2F6 [a-zA-Z]+\s+\x2F\x2Epng.*\x2E\x2E\x2F7 http\x3A\x2F\x2F[^\s]8 \s*JOIN9 \s*NICK

10 \s*NOTICE11 \s*PRIVMSG12 \s*USERHOST13 \x3c(REQIMG|RVWCFG)\x3e

• Ruleset policy.rules.pcre

1 Cookie\x3A.*s_sq=aolsnssignin2 GET\s+[^\x20]*\x2Ewm[zd]3 mstshash\s*\x3d\s*Administr4 SILC\x2d\d\x2e\d5 User-Agent\x3A[^\n\r]+Google[^\n\r]+Desktop6 [\x01|\x02|\x03|\x04|\x05|\x06|\x07]\x00.{4}\x43\x007 [\x05|\x06|\x07]\x00.{6}[SS|DS]8 [\x05][bcdfghjklmnpqrstvwxyz]{5,32}\x02cn9 [\x05][bcdfghjklmnpqrstvwxyz]{5,32}\x02ru

10 X-LINK2STATE\s+CHUNK

• Ruleset pop3.rules.pcre

1 APOP\s[^\n]{256}2 APOP\s+USER\s[^\n]{256}3 AUTH\s[^\n]{50}4 CAPA\s[^\n]{10}5 DELE\s+-\d6 DELE\s[^\n]{10}7 LIST\s[^\n]{10}8 PASS\s[^\n]{50}9 PASS\s+[^\n]*?%

10 RSET\s[^\n]{10}11 STAT\s[^\n]{10}

20 CAPITOLO 4. VALUTAZIONE SPERIMENTALE

12 TOP\s[^\n]{50}13 UIDL\s+-\d14 USER\s[^\n]{50}[^\n]*15 USER\s+[^\n]*?%16 XTND\s[^\n]{50}

• Ruleset web-php.rules.pcre

1 admin_root=(https?|ftps?|php)2 b2inc=(https?|ftps?|php)3 cache_lastpostdate\[[^\]]+\]=[^\x00\x3B\x3D]{30}4 comment=[^\x26\s]*[\x2f\x5c]5 forum=.*’6 GALLERY_BASEDIR=(https?|ftps?|php)7 page=(https?|ftps?|php)8 path=(https?|ftps?|php)9 pm_path=(https?|ftps?|php)

10 POST\s11 Server\x5bpath\x5d=(https?|ftps?|php)12 systempath=(https?|ftps?|php)13 template=(https?|ftps?|php)14 template\s*=\s*\x7b\x2415 [\?\x20\x3b\x26]module=[a-zA-Z0-9]*[^\x3b\x26]16 \x22method\x22\s*\x3a\s*\x22[A-Z]\w*[^\x22]

Per ogni ruleset iniziale sono stati generati gli esempi necessari all’evolu-zione. La tabella 4.2 riporta il numero di esempi generati per ogni ruleset.

Ruleset Positive/Regex Positive Examples Random Exampleschat.rules.pcre 105 1470 1470pop3.rules.pcre 105 1680 1680policy.rules.pcre 105 1050 1050

web-php.rules.pcre 105 1680 1680

Tabella 4.2: Dataset examples

4.3 Risultati

In questa sezione saranno esposti i risultati ottenuti cercando di ottimiz-zare i quattro ruleset iniziali. Per ognuno dei 4 job relativi all’ottimiz-zazione di un singolo problema si è scelto quello che forniva il Resulting

4.3. RISULTATI 21

Coverage Set con minore lunghezza aggregata dopo l’applicazione dell’al-goritmo Ruleset Completion. Per ognuno dei Resulting Coverage Set sonostate calcolate delle statistiche complessive, riportate nella tabella 4.3.

• Ruleset chat.rules.pcre

1 .*\.\./2 \s*USERHOST3 \s*PRIVMSG4 \s*NOTICE5 \s*NICK6 \s*JOIN7 http://[^\s]8 \<(REQIMG|RVWCFG)\>

• Ruleset policy.rules.pcre

1 (?:[\D][\D]\w\w.\w(?:[\D].*s\w)*(?:\x02)*[\.\w].[\D]*( )*[\D]*)*

2 GET\\s+[^ ]*\\.wm[zd]3 [\x01\|\x02\|\x03\|\x04\|\x05\|\x06\|\x07]\x00.{4,4}

C\x004 [\x05\|\x06\|\x07]\x00.{6,6}[SS\|DS]

• Ruleset pop3.rules.pcre

1 (([A-Z][A-Z]+\s[^\n]*)*)2 APOP\s[^\n]{256,256}

• Ruleset web-php.rules.pcre

1 (?:(?:(?:(?:[P]+[\w])+[\w])+[^a-z]*|(?:[^5]?[a-zz])?(?:[\w]*=)?[a-zz][a-zVN](?:(?:[a-z]([^w]*)|&|&))+))*

2 path=(https?|ftps?|php)

Ruleset Acc (%) 1-FPR (%) 1-FNR (%) #regex Σl

chat.rules.pcre 100.00 100.00 100.00 8 82policy.rules.pcre 98.29 96.57 100.00 4 134pop3.rules.pcre 100.00 100.00 100.00 2 42

web-php.rules.pcre 99.55 99.11 100.00 2 127

Tabella 4.3: Resulting Coverage Set valutati sui validation dataset

22 CAPITOLO 4. VALUTAZIONE SPERIMENTALE

4.3.1 Confronto

I Resulting Coverage Set ottenuti dalle varie ottimizzazioni possono essereconfrontati con i ruleset iniziali in termini di numero di espressioni regolarie lunghezza delle espressioni regolari.

Numero di espressioni regolari Nella tabella 4.4 sono confrontate lecardinalità dei ruleset (Rs) e dei Resulting Coverage Set (Rf ). Rf risultacontenere, mediamente, un numero di espressioni regolari pari al 30.5%di quelle contenute in Rs.

Ruleset |Rs| |Rf | |Rf |/|Rs|

chat.rules.pcre 14 8 0.57policy.rules.pcre 10 4 0.40pop3.rules.pcre 16 2 0.13

web-php.rules.pcre 16 2 0.13

Tabella 4.4: Confronto sul numero delle espressioni regolari

Lunghezze espressioni regolari Nella tabella 4.5 si sono confrontatele somme delle lunghezze delle espressioni regolari contenute nei rule-set iniziali (Rs) con quelle contenute nel Resulting Coverage Set (Rf ).Mediamente il rapporto tra le due sommatorie è pari a 0.32.

Ruleset Σsl Σf l Σf l/Σsl

chat.rules.pcre 307 82 0.27policy.rules.pcre 260 134 0.52pop3.rules.pcre 265 42 0.16

web-php.rules.pcre 400 127 0.32

Tabella 4.5: Confronto sulla lunghezza delle espressioni regolari

4.3.2 Importanza Ruleset Completion

Il confronto tra prima e dopo l’applicazione dell’algoritmo Ruleset Com-pletion (tabelle 4.6 e 4.3) mostra quanto questo algoritmo possa incideresulla definizione della soluzione. Basti vedere il ruleset chat.rules.pcre a

4.3. RISULTATI 23

cui sono state aggiunte ben 7 espressioni regolari. In altri casi, le modifi-che sono limitate e solo una regular expression è necessaria per concluderela ricerca.

Ruleset Acc (%) 1-FPR (%) 1-FNR (%) #regex Σl

chat.rules.pcre 75.00 100.00 50.00 1 7policy.rules.pcre 85.43 96.57 74.29 1 61pop3.rules.pcre 96.88 100.00 93.75 1 23

web-php.rules.pcre 93.30 99.11 87.50 1 104

Tabella 4.6: Resulting Coverage Set prima dell’applicazione del RulesetCompletion

È molto interessante notare come nel ruleset chat.rules.pcre sia risul-tata vincente quella che presentava accuracy peggiore prima dell’applica-zione dell’algoritmo di Ruleset Completion, ma decisamente la più cortatra tutte, come si vede dalla tabella 4.7.

Evolution Acc (%) 1-FPR (%) 1-FNR (%) #regex Σl

0 89.39 98.16 80.61 2 1651 99.39 98.78 100.00 1 862 96.22 92.45 100.00 1 833 75.00 100.00 50.00 1 7

Tabella 4.7: I quattro job eseguiti per il ruleset chat.rules.pcre

4.3.3 Testing

Gli stessi ruleset sono stati applicati al testing dataset ed i risultati sonoriportarti nelle tabelle 4.8. Si può notare come i risultati ottenuti sianomolto simili alla fase di validazione. Tale considerazione fornisce delleindicazioni sia sulla bontà della generalizzazione della soluzione, sia sullasomiglianza dei dataset di validazione e testing. In particolare si puònotare come il numero di falsi negativi si mantenga nullo in tutti e 4 gliesperimenti.

24 CAPITOLO 4. VALUTAZIONE SPERIMENTALE

Ruleset Acc (%) 1-FPR (%) 1-FNR (%)chat.rules.pcre 100.00 100.00 100.00policy.rules.pcre 97.14 94.27 100.00pop3.rules.pcre 99.82 99.64 100.00

web-php.rules.pcre 99.29 98.57 100.00

Tabella 4.8: Resulting Coverage Set valutati sul testing dataset

4.4 Analisi dell’Evoluzione

Qui di seguito verranno esposti i diversi andamenti degli indici monitoratidurante le evoluzioni e relativi al validation dataset, molto utili per intuirel’andamento dell’evoluzione. Per brevità analizziamo in modo più detta-gliato solo una delle rilevazioni, quella relativa al ruleset chat.rules.pcre:in ogni immagine sono rappresentati l’andamento delle 4 differenti evolu-zioni sulle 500 generazioni. Si noti già dal primo grafico come una dellequattro non riesca a raggiungere un buon valore, mentre 2 ottengano unaaccuracy maggiore del 95%.

75

80

85

90

95

100

0 50 100 150 200 250 300 350 400 450 500

Figura 4.1: Accuracy in percentuale

Dai grafici 4.2 e 4.3 si può notare come mediamente tutte le diverse

4.4. ANALISI DELL’EVOLUZIONE 25

evoluzioni tendano a migliorare sia FPR che FNR. Una sola si comportain modo differente e tende a rimanere costante sui propri valori.

50

60

70

80

90

100

0 50 100 150 200 250 300 350 400 450 500

Figura 4.2: 1-FPR in percentuale

Il grafico 4.4 è molto rappresentativo, in quanto mostra come l’evolu-zione tenda ad ottenere un’unica soluzione che risolva tutti gli esempi 1. Èimportante sottolineare che il parametro maggiormente interessante, os-sia la sommatoria delle lunghezze delle espressioni regolari (grafico 4.5),dopo un iniziale picco, tenda a scendere.

1Questo è dovuto alla strategia di Training scelta. Verrà dato maggiore risalto aquesto fatto nelle conclusioni.

26 CAPITOLO 4. VALUTAZIONE SPERIMENTALE

60

65

70

75

80

85

90

95

100

0 50 100 150 200 250 300 350 400 450 500

Figura 4.3: 1-FNR in percentuale

0

2

4

6

8

10

12

14

0 50 100 150 200 250 300 350 400 450 500

Figura 4.4: Numero di Regex

4.4. ANALISI DELL’EVOLUZIONE 27

0

50

100

150

200

250

300

350

0 50 100 150 200 250 300 350 400 450 500

Figura 4.5: Sommatoria delle lunghezze delle RE

Capitolo 5

Conclusioni

5.1 Considerazioni sui Risultati

I risultati ottenuti si sono rivelati soddisfacenti nella fase di testing e quin-di la generalizzazione ottenuta può dirsi accettabile. È importante notarecome l’algoritmo di Ruleset Completion fornisca un contributo rilevanteper il miglioramento degli indici. Considerando la novità dell’approccio,si può considerare terminata con successo questa fase iniziale ed esplora-tiva che però lascia dei problemi ancora aperti, ma sui quali si possonogià definire delle ipotesi di lavoro.

5.2 Sviluppi futuri

5.2.1 Metriche

Uno dei punti cruciali riguarda la tendenza ad ottenere un unico indivi-duo che risolva il problema nella sua interezza. Questo è essenzialmentedovuto alla scelta della strategia di Training.

Un’alternativa potrebbe essere quella di definire una metrica aggiun-tiva che cerchi di conservare la biodiversità degli individui e che potrebbederivare dall’algoritmo di Set Coverage estendendolo affinché fornisca unordinamento tra le espressioni regolari.

Un’altra possibile alternativa è quella di usare un modello ad isole perl’evoluzione: in tal modo popolazioni diverse possono evolvere in manieradiscorde e fornire soluzioni più sparse e possibilmente complementari. Giàne si nota l’utilità confrontando i 4 job eseguiti per ogni ruleset e pertantoesplorare maggiormente questa strada sembra promettente.

29

30 CAPITOLO 5. CONCLUSIONI

5.2.2 Modifiche all’algoritmo di Set Coverage

Attualmente l’algoritmo non tiene conto della lunghezza delle stringhe equindi una RE estremamente lunga può venire aggiunta al Resulting Setanche se il suo apporto è minimo. Sarebbe opportuno inserire qualchecriterio che ne tenga conto.

5.2.3 Generazione dei Dataset di Esempi

Uno dei possibili nodi da sciogliere, forse il più importante, riguarda lagenerazione del dataset di esempi. La generazione casuale degli esempinegativi è da un certo punto di vista più equa, da un altro punto di vistanon è ben rappresentativa del traffico generale che si può riscontrare sullarete. Per ovviare a questo inconveniente si potrebbero aggiungere degliesempi più significativi, a tal fine sono state ipotizzate due strade:

1. Raccolta di traffico internet reale. Tale soluzione sarebbe ottima,ma non è facile ottenere dataset di traffico reale aggiornato e conun buona quantità di traffico maligno;

2. Sintetizzare del traffico come discusso in [9]. È da notare che loscopo di tale articolo è quello di generare il più possibile stringheche contengano solo dei match parziali in modo da poter eseguiredei test di carico il più stressanti possibile. Un’altra ipotesi, peralcuni versi simile, riguarda la possibilità di perturbare le espres-sioni regolari in modo da generare stringhe non riconosciute, ma chepotrebbero essere maggiormente significative nella fase di training.

Appendice A

Dettagli Implementativi

Per la realizzazione del software ci si è basati sul precedente lavoro [26] ilquale è stato integrato con i nuovi algoritmi descritti durante tutto il corsodel lavoro. Il linguaggio utilizzato in entrambi i lavori è principalmenteJava versione 6. Tra le librerie utilizzate durante tale progetto si possonocitare:

• SuperCSV 1 – Libreria per la lettura e la scrittura di file in formatoCSV. Tutti i dataset di esempi ed i file di statistiche utilizzanoquesto formato;

• Apache Commons 2 – Di questa libreria è stata utilizzata solo lacomponente Lang che predispone dei metodi per convertire strin-ghe in diversi formati; grazie a queste funzionalità si sono potutiagevolmente inserire nei file CSV anche caratteri non stampabili equindi problematici.

A.1 RE2

La scelta del motore NFA è ricaduta su RE2 [29], progetto scritto in C++.Per tale ragione è stata necessaria un’implementazione dell’interfacciaJNI per il suo utilizzo all’interno del progetto Java. È da tenere contoche è stata trovata una soluzione già esistente 3, ma che presentava alcunibachi nella conversione della stringa tra Java e C++, essenzialmente perla gestione del carattere null, ed è pertanto stata modificata per sopperireal problema.

1http://supercsv.sourceforge.net/2http://commons.apache.org/3RE2-Java: https://github.com/logentries/re2-java

31

Appendice B

Approfondimenti

B.1 Distanza di Edit

La distanza di edit, o distanza di Levenshtein, è una metrica tra stringhe esi definisce come il numero minimo di modifiche necessarie per trasformareuna stringa in un’altra. Esistono 3 diversi tipi di modifiche introducibili:

1. Inserimento – Un carattere può essere inserito nella stringa in po-sizione qualsiasi;

2. Cancellazione – Un carattere della stringa può venir cancellato;

3. Sostituzione – Un carattere della stringa può venire sostituito conun altro carattere.

La complessità dell’algoritmo per il calcolo di tale distanza è proporzio-nale al prodotto delle lunghezze delle stringhe.

B.2 Set Cover

Il problema di Set Cover è il seguente: dato un insieme U ed una collezionedi suoi sotto-insiemi S, individuare una sotto-collezione S′ di S che copratutto l’insieme U , ovvero che ∪s∈S′ = U , e che renda minima una funzionedi costo, tipicamente la cardinalità di S.

L’individuazione di tale insieme è un problema NP-Completo [25] equindi la ricerca di una soluzione ottima non è praticabile. Per unatrattazione della complessità di un problema si può fare riferimento a[30].

33

34 APPENDICE B. APPROFONDIMENTI

B.3 Quantificatori Greedy e Possessive

I quantificatori greedy e possessive sono dei particolari operatori delleespressioni regolari; entrambi sono operatori di ripetizione ed indicanoche un certo elemento può presentarsi all’interno della stringa ripetuto.La differenza tra quantificatori greedy e possessive risiede nel fatto chei quantificatori possessive consumano la stringa mentre la analizzano; alcontrario i quantificatori greedy possono tornare ad analizzare caratterigià valutati.

Come esempio si prenda l’operatore greedy stella * 1 e due espressio-ni regolari a*ab (greedy) e a*+ab (possessive) da applicare alla stringaaaab: entrambi gli operatori cercano di ripetere il carattere a più voltepossibile (3 volte in questo caso), a questo punto tentano di comparareab con la restante parte della stringa b, fallendo; a seguito di questo falli-mento l’operatore possessive finisce immediatamente la valutazione dellastringa non estraendo nulla (avendo consumato tutti i caratteri), mentrel’operatore greedy tenta di ripetere il carattere a per un numero inferioredi volte (2 volte) e riesce ad estrarre aaab.

1L’operatore stella indica che l’elemento a cui viene applicato può non esserepresente od essere presente un numero indefinito di volte.

Elenco delle figure

2.1 Comparazione Motori Espressioni Regolari . . . . . . . . . 52.2 Programmazione Genetica . . . . . . . . . . . . . . . . . . 7

3.1 Albero relativo all’espressione regolare ab|c|d* . . . . . . . 10

4.1 Accuracy in percentuale . . . . . . . . . . . . . . . . . . . 244.2 1-FPR in percentuale . . . . . . . . . . . . . . . . . . . . . 254.3 1-FNR in percentuale . . . . . . . . . . . . . . . . . . . . . 264.4 Numero di Regex . . . . . . . . . . . . . . . . . . . . . . . 264.5 Sommatoria delle lunghezze delle RE . . . . . . . . . . . . 27

35

Elenco delle tabelle

4.1 Ruleset Stats . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Dataset examples . . . . . . . . . . . . . . . . . . . . . . . 204.3 Resulting Coverage Set valutati sui validation dataset . . 214.4 Confronto sul numero delle espressioni regolari . . . . . . 224.5 Confronto sulla lunghezza delle espressioni regolari . . . . 224.6 Resulting Coverage Set prima dell’applicazione del Ruleset

Completion . . . . . . . . . . . . . . . . . . . . . . . . . . 234.7 I quattro job eseguiti per il ruleset chat.rules.pcre . . . . . 234.8 Resulting Coverage Set valutati sul testing dataset . . . . 24

37

Bibliografia

[1] V. Kosar and J. Korenek. Reduction of fpga resources for regularexpression matching by relation similarity. In Design and Diagno-stics of Electronic Circuits Systems (DDECS), 2011 IEEE 14th In-ternational Symposium on, pages 401–402, April 2011. [citato a p. 1, 3,

4]

[2] Michela Becchi and Patrick Crowley. An improved algorithm toaccelerate regular expression evaluation. In Proceedings of the 3rdACM/IEEE Symposium on Architecture for Networking and Com-munications Systems, ANCS ’07, pages 145–154, New York, NY,USA, 2007. ACM. [citato a p. 1, 3, 4]

[3] R. Sidhu and V.K. Prasanna. Fast regular expression matching usingfpgas. In Field-Programmable Custom Computing Machines, 2001.FCCM ’01. The 9th Annual IEEE Symposium on, pages 227–238,March 2001. [citato a p. 1, 6]

[4] João Bispo, Ioannis Sourdis, João M. P. Cardoso, and StamatisVassiliadis. Synthesis of regular expressions targeting fpgas: Cur-rent status and open issues. In Proceedings of the 3rd Internatio-nal Conference on Reconfigurable Computing: Architectures, Toolsand Applications, ARC’07, pages 179–190, Berlin, Heidelberg, 2007.Springer-Verlag. [citato a p. 1, 3, 6]

[5] Yi-Hua E. Yang, Weirong Jiang, and Viktor K. Prasanna. Com-pact architecture for high-throughput regular expression matchingon fpga. In Proceedings of the 4th ACM/IEEE Symposium on Archi-tectures for Networking and Communications Systems, ANCS ’08,pages 30–39, New York, NY, USA, 2008. ACM. [citato a p. 1, 3, 6]

[6] Y.-H.E. Yang and V.K. Prasanna. High-performance and compactarchitecture for regular expression matching on fpga. Computers,

39

40 BIBLIOGRAFIA

IEEE Transactions on, 61(7):1013–1025, July 2012. [citato a p. 1, 3, 4,

6]

[7] Johnny Tsung Lin Ho. Perg-rx: An fpga-based pattern-matchingengine with limited regular expression support for large patterndatabases. Master’s thesis, The University of British Columbia(Vancouver), september 2009. [citato a p. 1]

[8] Abhishek Mitra, Walid Najjar, and Laxmi Bhuyan. Compiling pcreto fpga for accelerating snort ids. In Proceedings of the 3rd AC-M/IEEE Symposium on Architecture for Networking and Commu-nications Systems, ANCS ’07, pages 127–136, New York, NY, USA,2007. ACM. [citato a p. 3]

[9] M. Becchi, M. Franklin, and P. Crowley. A workload for evaluatingdeep packet inspection architectures. In Workload Characterization,2008. IISWC 2008. IEEE International Symposium on, pages 79–89,Sept 2008. [citato a p. 3, 30]

[10] Snort. Open source network intrusion prevention and detectionsystem (IDS/IPS) http://www.snort.org/. [citato a p. 3]

[11] M. Sipser. Introduction To The Theory Of Computation. AdvancedTopics Series. Thomson Course Technology, 2006. [citato a p. 3, 4]

[12] Hugo Gouveia, Nelma Moreira, and Rogério Reis. Small nfas from re-gular expressions: Some experimental results. CoRR, abs/1009.3599,2010. [citato a p. 4, 5]

[13] Keith Ellul, Bryan Krawetz, Jeffrey Shallit, and Ming wei Wang.Regular expressions: New results and open problems. Journalof Automata, Languages and Combinatorics, 9(2/3):233–256, 2004.[citato a p. 4]

[14] Asiri Rathnayake and Hayo Thielecke. Regular expression matchingand operational semantics. In Structural Operational Semantics2011, September 2011. http://www.cs.bham.ac.uk/~hxt/research/reg-exp-sos.pdf. [citato a p. 4]

[15] Jiacun Wang. Handbook of Finite State Based Models and Ap-plications. Chapman & Hall/CRC, 1st edition, 2012. [citato a p. 4,

6]

BIBLIOGRAFIA 41

[16] Ken Thompson. Programming techniques: Regular expressionsearch algorithm. Commun. ACM, 11(6):419–422, June 1968.[citato a p. 5]

[17] RussCox. http://swtch.com/~rsc/regexp/regexp1.html. [citato a p. 5]

[18] Tao Jiang and B. Ravikumar. Minimal nfa problems are hard. SIAMJ. Comput., 22(6):1117–1141, December 1993. [citato a p. 5]

[19] Gregor Gramlich and Georg Schnitger. Minimizing nfa’s and regularexpressions. J. Comput. Syst. Sci., 73(6):908–923, September 2007.[citato a p. 5]

[20] J. Harwayne-Gidansky, D. Stefan, and I. Dalal. Fpga-based soc forreal-time network intrusion detection using counting bloom filters. InSoutheastcon, 2009. SOUTHEASTCON ’09. IEEE, pages 452–458,March 2009. [citato a p. 6]

[21] Yi-Hua E. Yang and Viktor K. Prasanna. Software toolchain forlarge-scale re-nfa construction on fpga. Int. J. Reconfig. Comput.,2009:2:1–2:10, January 2009. [citato a p. 6]

[22] Gonzalo Navarro and Mathieu Raffinot. Flexible Pattern Matching inStrings: Practical On-line Search Algorithms for Texts and BiologicalSequences. Cambridge University Press, New York, NY, USA, 2002.[citato a p. 6]

[23] John R Koza. Genetic Programming: On the Programming of Com-puters by Means of Natural Selection (Complex Adaptive Systems).1992. [citato a p. 6]

[24] VI Levenshtein. Binary Codes Capable of Correcting Deletions,Insertions and Reversals. Soviet Physics Doklady, 10:707, 1966.[citato a p. 8]

[25] R. Karp. Reducibility among combinatorial problems. In R. Millerand J. Thatcher, editors, Complexity of Computer Computations,pages 85–103. Plenum Press, 1972. [citato a p. 8, 33]

[26] Alberto Bartoli, Giorgio Davanzo, Andrea De Lorenzo, Marco Mau-ri, Eric Medvet, and Enrico Sorio. Automatic generation of regularexpressions from examples with genetic programming. In Proceedingsof the Fourteenth International Conference on Genetic and Evolutio-nary Computation Conference Companion, GECCO Companion ’12,

42 BIBLIOGRAFIA

pages 1477–1478, New York, NY, USA, 2012. ACM. [citato a p. 9, 13,

31]

[27] Viktor Pus, Jiri Tobola, Vlastimil Kosar, Jan Kastil, and JanKorenek. Netbench: Framework for evaluation of packet proces-sing algorithms. Symposium On Architecture For Networking AndCommunications Systems, pages 95–96, 2011. [citato a p. 13, 18]

[28] PCREParser. An ANTLR grammar for PCRE https://github.com/bkiers/PCREParser. [citato a p. 13]

[29] RE2 - NFA RE engine http://code.google.com/p/re2/. [citato a p. 31]

[30] Sanjeev Arora and Boaz Barak. Computational Complexity: A Mo-dern Approach. Cambridge University Press, New York, NY, USA,1st edition, 2009. [citato a p. 33]

[31] A. Bartoli, G. Davanzo, A. De Lorenzo, E. Medvet, and E. Sorio. Au-tomatic synthesis of regular expressions from examples. Computer,PP(99):1–1, 2013. [citato a p. 9]