MATHIEU COUTURE

D
´
ETECTION D’INTRUSIONS ET ANALYSE
PASSIVE DE R
´
ESEAUX
M´emoire pr´esent´e
`a la Facult´e des ´etudes sup´erieures de l’Universit´e Laval
dans le cadre du programme de maˆıtrise en informatique
pour l’obtention du grade de Maˆıtre `es sciences
D
´
EPARTEMENT D’INFORMATIQUE ET DE G
´
ENIE LOGICIEL
FACULT
´
E DES SCIENCES ET DE G
´
ENIE
UNIVERSIT
´
E LAVAL
QU
´
EBEC
juin 2005
c (Mathieu Couture, 2005
R´esum´e
Dans ce travail, nous proposons un nouveau langage d´edi´e `a la d´etection d’intru-
sions. Il s’agit d’un langage purement d´eclaratif, bas´e sur une logique temporelle lin´eaire
pass´ee avec pr´edicats du premier ordre. Apr`es avoir effectu´e une revue de treize lan-
gages de d´etection d’intrusions existant d´ej` a, nous donnons une liste de dix propri´et´es
souhaitables pour un langage de d´etection d’intrusions. Contrairement au langage que
nous proposons, aucun des langages ´etudi´es ne pr´esente `a la fois ces dix propri´et´es. En
plus d’ˆetre suffisamment expressif pour r´epondre aux besoins identifi´es, il vient avec un
algorithme de v´erification qui s’ex´ecute en temps lin´eaire avec la quantit´e d’information
analys´ee et utilise une quantit´e born´ee d’espace m´emoire. Ces deux propri´et´es per-
mettent de prot´eger le syst`eme de d´etection d’intrusions contre d’´eventuelles attaques
d’inondation.
Avant-propos
Je d´esire d’abord remercier ma m`ere, qui a su me donner le goˆ ut des ´etudes, ainsi
que mon p`ere, qui m’a appris l’importance de l’int´egrit´e et de la transparence. Je les
remercie tous les deux pour le support et les encouragements qu’ils m’ont donn´e tout
au long de mon cheminement, autant personnel qu’acad´emique.
Je remercie aussi mon directeur de recherches, le professeur B´echir Ktari, pour avoir
accept´e de me diriger dans un domaine aussi stimulant, et pour la confiance qu’il m’a
montr´ee tout au long de ces deux ann´ees de travail. J’adresse aussi mes remerciements
`a Fr´ed´eric Massicotte, ami et collaborateur au Centre de Recherches sur les Communi-
cations, qui a su `a plusieurs occasions me donner des critiques constructives sur mon
travail. Je le remercie aussi pour son sens aigu du bien-ˆetre d’autrui, qu’il a su en partie
me communiquer. Je tiens aussi `a exprimer ma reconnaissance envers les professeurs
Jos´ee Desharnais et Mohamed Mejri qui ont accept´e d’´evaluer ce m´emoire. Je remer-
cie le personnel administratif du d´epartement d’informatique, et plus particuli`erement
Lynda Goulet, pour sa bonne humeur et les nombreux services qu’elle m’a rendus.
Je remercie le Centre de Recherches sur les Communications, pour son support
mat´eriel et financier, le Gouvernement Fran¸cais, pour m’avoir accueilli et avoir financ´e
en partie mes recherches, de mˆeme que les professeurs Andr´e-Luc Beylot, Marc Boyer et
J´erˆ ome Ermont, pour leur chaleureux accueil `a l’ENSEEIHT, `a Toulouse. Je remercie
le Minist`ere des Relations Internationales du Qu´ebec, pour avoir rendu possible cet
´echange avec l’ENSEEIHT.
Merci `a Catherine et aux colocs du 22A, pour leur pr´esence chaleureuse et les nom-
breuses soir´ees que nous avons pass´ees ensemble. Merci `a Alexandre Lacasse, pour son
agr´eable compagnie au cours des deux voyages que nous avons faits en France, de mˆeme
que pour ses commentaires encourageants et constructifs. Finalement, je remercie toutes
celles et ceux de mes amies et amis qui m’ont encourag´e et support´e dans mes projets.
`
A ma m`ere, Nicole,
avec qui tout a commenc´e.
Imagination is more important than
knowledge.
Table des mati`eres
R´esum´e ii
Avant-propos iii
Table des mati`eres v
Liste des tableaux viii
Table des figures x
Introduction 1
1 Syst`emes de d´etection d’intrusions 5
1.1 Langages sp´ecifiques au domaine . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1 Panoptis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3 NeVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Langages imp´eratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 ASAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.2 BRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Syst`emes de transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.1 STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.2 IDIOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3.3 BSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4 Syst`emes experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.1 P-BEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4.2 LAMBDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.5 Logiques temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5.1 LogWeaver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.5.2 Monid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.5.3 Chronicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table des mati`eres vi
2 Logiques temporelles 55
2.1 Logiques temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.1.1 Logique temporelle lin´eaire . . . . . . . . . . . . . . . . . . . . . . 58
2.1.2 Logique temporelle lin´eaire pass´ee . . . . . . . . . . . . . . . . . . 60
2.1.3 Logique temporelle lin´eaire avec pass´e oubliable . . . . . . . . . . 63
2.1.4 µ-calcul lin´eaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2 Logiques temporis´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.2.1 Logique temporelle temporis´ee . . . . . . . . . . . . . . . . . . . . 67
2.2.2 Logique temporelle m´etrique . . . . . . . . . . . . . . . . . . . . . 70
2.2.3 TRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3 D´etection d’intrusions et analyse passive 74
3.1 Architecture du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.2 Langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3 Sc´enarios d’attaques complexes . . . . . . . . . . . . . . . . . . . . . . . 78
3.4 Acquisition passive d’information . . . . . . . . . . . . . . . . . . . . . . 80
3.4.1 Ports TCP ouverts et sessions actives . . . . . . . . . . . . . . . . 80
3.4.2 Ports TCP ferm´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.3 Sessions ferm´ees et balayage FIN . . . . . . . . . . . . . . . . . . 82
3.4.4 Vuln´erabilit´es et syst`emes d’exploitation . . . . . . . . . . . . . . 83
3.4.5 Adresses du routeur . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.4.6 Inf´erence de nouvelles connaissances . . . . . . . . . . . . . . . . 85
3.5 Pr´esentation formelle du langage . . . . . . . . . . . . . . . . . . . . . . 86
3.5.1 Mod`ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.5.2 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.5.3 S´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.5.4 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4 Logique d’acquisition de connaissances 97
4.1 Un paradigme pass´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.1 Mod`ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.1.2 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.1.3 S´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2 Unification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2.1 Mod`ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.2 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.3 S´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.3 R´ecursivit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.3.1 Approximants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table des mati`eres vii
4.3.2 Tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.4 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.4.1 Cas propositionnel . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.4.2 Cas du premier ordre . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5 Travaux futurs 132
5.1 Satisfiabilit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.2 Filtrage dynamique et s´emantique de symptˆome . . . . . . . . . . . . . . 134
5.3 Synth`ese de contrˆ oleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Conclusion 142
Bibliographie 144
Liste des tableaux
1.1 Algorithme d’apprentissage et de v´erification de Panoptis. . . . . . . . . 9
1.2 Syntaxe abstraite de RUSSEL. . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Syntaxe des patrons dans BSML. . . . . . . . . . . . . . . . . . . . . . . 33
1.4 Syntaxe du calcul d’´ev´enements utilis´e dans LAMBDA. . . . . . . . . . . 38
1.5 Syntaxe d’un sc´enario d’attaque LAMBDA. . . . . . . . . . . . . . . . . 39
1.6 Syntaxe de la premi`ere logique de LogWeaver. . . . . . . . . . . . . . . . 42
1.7 Syntaxe des sp´ecifications Eagle. . . . . . . . . . . . . . . . . . . . . . . . 45
1.8 Pr´edicats de r´eification de Chronicles. . . . . . . . . . . . . . . . . . . . . 48
1.9 Dix propri´et´es souhaitables d’un IDS. . . . . . . . . . . . . . . . . . . . . 52
1.10 Tableau r´ecapitulatif des IDS. . . . . . . . . . . . . . . . . . . . . . . . . 53
2.1 Familles de logiques temporelles et leur mod`ele. . . . . . . . . . . . . . . 57
2.2 Syntaxe de LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.3 S´emantique de LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4 Op´erateurs d´efinis de LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.5 Syntaxe de P-LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.6 S´emantique des op´erateurs particuliers `a P-LTL. . . . . . . . . . . . . . . 61
2.7 Op´erateurs d´efinis de P-LTL. . . . . . . . . . . . . . . . . . . . . . . . . 61
2.8 Syntaxe de N-LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.9 S´emantique de l’op´erateur particulier `a N-LTL. . . . . . . . . . . . . . . 64
2.10 Syntaxe du µ-calcul lin´eaire. . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.11 S´emantique de l’op´erateur particulier au µ-calcul lin´eaire. . . . . . . . . . 65
2.12 Op´erateurs d´efinis du µ-calcul lin´eaire. . . . . . . . . . . . . . . . . . . . 66
2.13 Syntaxe de T-LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.14 S´emantique des op´erateurs particuliers `a T-LTL. . . . . . . . . . . . . . . 69
2.15 Un op´erateur d´efini de T-LTL. . . . . . . . . . . . . . . . . . . . . . . . . 69
2.16 Syntaxe de MTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.17 S´emantique des op´erateurs particuliers `a MTL. . . . . . . . . . . . . . . . 70
2.18 Syntaxe de TRIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.19 S´emantique de l’op´erateur particulier `a TRIO. . . . . . . . . . . . . . . . 71
2.20 Quelques op´erateurs d´efinis de TRIO. . . . . . . . . . . . . . . . . . . . . 72
Liste des tableaux ix
3.1 Syntaxe du langage de signatures. . . . . . . . . . . . . . . . . . . . . . . 77
3.2 Syntaxe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.3 S´emantique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.4 Syntaxe du sous-ensemble associ´e au langage de signatures. . . . . . . . . 90
3.5 Algorithme de v´erification. . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.1 Syntaxe pour le cas propositionnel. . . . . . . . . . . . . . . . . . . . . . 99
4.2 S´emantique pour le cas propositionnel. . . . . . . . . . . . . . . . . . . . 100
4.3 Syntaxe pour le cas du premier ordre. . . . . . . . . . . . . . . . . . . . . 103
4.4 S´emantique op´erationnelle pour le cas du premier ordre. . . . . . . . . . 106
4.5 Approximants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.6 Approximants avec intervalles. . . . . . . . . . . . . . . . . . . . . . . . . 114
4.7 Algorithme de v´erification pour le cas propositionel. . . . . . . . . . . . . 116
4.8 Algorithme de v´erification pour le cas du premier ordre. . . . . . . . . . . 120
4.9 S´emantique d´enotationnelle pour le cas du premier ordre. . . . . . . . . . 121
5.1 Syst`eme de preuves `a base de tableaux. . . . . . . . . . . . . . . . . . . . 134
5.2 S´emantique de symptˆ ome. . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3 Syntaxe de l’alg`ebre des automates. . . . . . . . . . . . . . . . . . . . . . 137
5.4 S´emantique de l’alg`ebre des automates. . . . . . . . . . . . . . . . . . . . 137
5.5 Algorithme de synth`ese de contrˆoleur. . . . . . . . . . . . . . . . . . . . . 139
Table des figures
1.1 Exemple de fichier de configuration de Panoptis. . . . . . . . . . . . . . . 8
1.2 Exemple de fichier de planification de tˆaches de Panoptis. . . . . . . . . . 9
1.3 Exemple de fichier de sortie de Panoptis. . . . . . . . . . . . . . . . . . . 9
1.4 Structure de Snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Exemple de signature Snort. . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Exemple d’utilisation du module de r´eaction. . . . . . . . . . . . . . . . . 14
1.7 Exemple d’utilisation du module flowbits. . . . . . . . . . . . . . . . . . . 14
1.8 Exemple de signature NeVO. . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.9 D´etection d’une p´en´etration externe dans ASAX. . . . . . . . . . . . . . 21
1.10 Structure de Bro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.11 Exemple de script Bro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.12 Session `a demi ouverte dans NetSTAT. . . . . . . . . . . . . . . . . . . . 28
1.13 Session `a demi ouverte dans l’outil STATed. . . . . . . . . . . . . . . . . 29
1.14 Mod´elisation d’un r´eseau avec NetSTAT. . . . . . . . . . . . . . . . . . . 29
1.15 Session TCP dans IDIOT. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.16 Attaque TCP SYN-Flood dans BSML. . . . . . . . . . . . . . . . . . . . 34
1.17 Exemple de r`egle d’inf´erence dans P-BEST. . . . . . . . . . . . . . . . . 37
1.18 Mod´elisation du sc´enario d’acc`es ill´egal `a un fichier avec LAMBDA. . . . 40
1.19 Exemple de sp´ecification Eagle. . . . . . . . . . . . . . . . . . . . . . . . 45
1.20 Exemple de chronique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.1 Exemples de programmes. . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.1 Architecture du syst`eme d´evelopp´ee (` a droite), et celle de Snort (`a gauche). 76
3.2 Balayage SYN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3 Poign´ee de main TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.4 Ports TCP ferm´es. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5 Fermeture d’une session TCP. . . . . . . . . . . . . . . . . . . . . . . . . 81
3.6 D´etection d’un syst`eme d’exploitation FreeBSD 3.0 `a 4.3. . . . . . . . . . 83
3.7 R`egle Snort num´ero 343. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.8 R´eduction des faux-positifs `a l’aide de la d´etection de vuln´erabilit´es. . . . 84
3.9 Adresses du routeur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Table des figures xi
3.10 Inf´erence de nouvelles connaissances. . . . . . . . . . . . . . . . . . . . . 85
3.11 Exemple de trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.12 Formule repr´esentant une poign´ee de main TCP. . . . . . . . . . . . . . . 88
3.13 Sp´ecification associ´ee au sc´enario d’une poign´ee de main TCP. . . . . . . 91
3.14 Exemple de trace d’ex´ecution de l’algorithme. . . . . . . . . . . . . . . . 93
4.1 Attaque dans le contexte d’une session TCP active. . . . . . . . . . . . . 99
4.2 Exemple de trace pour le cas propositionnel. . . . . . . . . . . . . . . . . 101
4.3 Exemple de relations de satisfaction pour le cas propositionnel. . . . . . . 101
4.4 Exemple de trace du premier ordre. . . . . . . . . . . . . . . . . . . . . . 102
4.5 Suivi des sessions TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.6 Exemple de relations de satisfaction pour le cas du premier ordre. . . . . 107
4.7 Utilisation des approximants. . . . . . . . . . . . . . . . . . . . . . . . . 113
4.8 Utilisation des approximants avec intervalles. . . . . . . . . . . . . . . . . 114
4.9 Balayage de ports TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.1 Exemples de contradictions. . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.2 Exemple de conflit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.3 Automate TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.4 Contrˆoleur pour l’automate TCP relativement `a (rst ∧ [synack, ack]). . 138
5.5 Contrˆoleur universel pour (rst ∧ [synack, ack]). . . . . . . . . . . . . . . 140
Introduction
Contexte
La d´etection d’intrusions est un probl`eme inh´erent `a la nature abstraite d’un r´eseau
informatique. Il est plutˆ ot rare que l’on puisse dire, par un simple coup d’oeil aux
´equipements informatiques, que ceux-ci ont ´et´e ou sont pr´esentement utilis´es d’une
fa¸con non-souhaitable. Pour le savoir, il faut ´etudier attentivement des quantit´es la
plupart du temps astronomiques de fichiers d’audit et faire preuve d’une patience et
d’une capacit´e d’analyse hors du commun. Afin de nous all´eger cette tˆache ardue, les
informaticiens se sont mis `a d´evelopper des outils logiciels automatisant une partie du
travail. Ils les ont appel´es syst`emes de d´etection d’intrusions.
Les syst`emes de d´etection d’intrusions sont g´en´eralement class´es en deux cat´egories :
les d´etecteurs d’anomalies et les syst`emes `a base de sc´enarios. Les d´etecteurs d’anoma-
lies fonctionnent g´en´eralement en deux phases : une phase d’apprentissage et une phase
de d´etection. Au cours de la phase d’apprentissage, le syst`eme apprend `a reconnaˆıtre
ce qu’est un comportement normal, et au cours de la phase de d´etection, il identifie les
comportements anormaux. Les syst`emes pour lesquels la phase d’apprentissage continue
apr`es le d´ebut de la phase de reconnaissance sont dits adaptatifs. L’objectif des syst`emes
adaptatifs est de tenir compte de la nature changeante des r´eseaux informatiques. Les
syst`emes `a base de sc´enarios n’ont pas de phase d’apprentissage. Ils viennent avec une
base de sc´enarios d’attaque pr´ed´efinis qu’ils doivent reconnaˆıtre. L’avantage des d´etec-
teurs d’anomalies est donc de pouvoir d´etecter des sc´enarios d’attaque insoup¸conn´es,
au risque de g´en´erer des faux-positifs (fausses alarmes), alors que celui des syst`emes `a
base de sc´enarios est de g´en´erer moins de faux-positifs, au risque de laisser passer des
attaques encore inconnues. Dans ce cas, on parle de faux-n´egatifs. Le pr´esent travail
s’int´eresse surtout aux syst`emes `a base de sc´enarios.
Une autre fa¸con de classer les syst`emes de d´etection d’intrusions est selon le niveau
auquel ils interviennent : hˆote ou r´eseau. Au niveau hˆ ote, les fichiers d’audit analys´es
Introduction 2
sont des fichiers syst`emes : utilisation du processeur, du syst`eme de fichiers, du r´eseau,
traces d’ex´ecution de programmes, etc., alors qu’au niveau r´eseau, les fichiers d’audit
utilis´es sont des traces de trafic. Une trace de trafic est une copie de tout le trafic ayant
circul´e `a un endroit donn´e d’un r´eseau informatique. Il s’agit en fin de compte d’un cas
particulier de fichier d’audit, et c’est pourquoi certains syst`emes de d´etection pr´esentent
une approche g´en´erale permettant de regrouper les deux cas de cette classification.
Plusieurs paradigmes, auxquels nous reviendrons, ont ´et´e propos´es pour les lan-
gages de signatures des syst`emes de d´etection d’intrusions `a base de sc´enarios. Parmi
ceux-ci, se trouvent ceux bas´es sur des logiques temporelles. Les logiques temporelles,
en m´ethodes formelles, ont ´et´e utilis´ees pour s’attaquer `a trois cat´egories de probl`emes :
V´erification
´
Etant donn´e un programme, d´ecider, avant mˆeme de l’ex´ecuter, si toutes
ses ex´ecutions respecteront une propri´et´e donn´ee.
Synth`ese
´
Etant donn´ee une propri´et´e, g´en´erer un programme tel que toutes ses ex´e-
cutions respectent cette propri´et´e.
Validation
´
Etant donn´ee une ex´ecution d’un programme, d´ecider si cette ex´ecution
respecte une propri´et´e donn´ee.
Le pr´esent travail s’inscrit donc dans un contexte de validation. Dans notre cas, le
programme `a valider sera le r´eseau, et son ex´ecution sera mat´erialis´ee par les diff´erents
fichiers d’audit mis `a notre disposition. Bien que nous nous int´eressions particuli`erement
aux traces de trafic, la m´ethode que nous proposons s’adapte aussi bien aux autres
fichiers d’audit. Il convient de noter, avant d’aller plus loin, que la d´etection d’intrusions
a ceci de particulier que les ex´ecutions auxquelles on s’int´eresse sont de longueur infinie.
Les m´ethodes propos´ees pour des ex´ecutions finies de programmes ne sauraient donc
s’appliquer ici.
Objectifs et m´ethodologie
Nous nous sommes donn´e comme mandat de d´evelopper un langage de d´etection
d’intrusions qui soit bas´e sur un paradigme purement d´eclaratif. Pour ce faire, nous
avons d’abord dˆ u effectuer une revue des langages de d´etection d’intrusions existant
d´ej`a. Bien que plusieurs d’entre eux aient la pr´etention d’ˆetre d´eclaratifs, il s’est av´er´e
que le bien fond´e de cette affirmation ´etait dans la plupart des cas discutable. Ceux
´etant le plus pr`es de r´epondre `a ce crit`ere ´etant ceux bas´es sur un paradigme de logique
temporelle, nous avons privil´egi´e cette voie pour la poursuite de nos travaux.
Introduction 3
Nous avons donc dˆ u nous familiariser avec les logiques temporelles, et voir comment
celles-ci pouvaient ˆetre utilis´ees pour r´epondre `a nos besoins. Un de ces besoins ´etait
d’acqu´erir passivement de l’information sur un r´eseau informatique, de fa¸con `a faire une
d´etection d’intrusions plus accrue. En effet, un reproche ayant souvent ´et´e fait aux sys-
t`emes de d´etection d’intrusions est de ne pas tenir compte du contexte avant de signaler
des alarmes. Cette sauvegarde du contexte ne saurait cependant ˆetre faite sans un coˆ ut
additionnel, le pire cas, tout `a fait d´eraisonnable, constituant la sauvegarde compl`ete de
la trace de trafic. Au mieux, on ne sauvegarde que l’information n´ecessaire, pas un bit
de plus. La capacit´e `a traiter un fichier d’audit enregistrement par enregistrement sans
revenir en arri`ere est ce que nous appellerons traitement en ligne. Les trois objectifs
principaux de notre travail sont donc :
1. Paradigme d´eclaratif,
2. acquisition passive d’information,
3. et traitement en ligne.
Nous proposons deux approches pour s’attaquer `a ces probl`emes. La premi`ere est
une approche hybride o` u la s´eparation entre l’information acquise et les sc´enarios `a
reconnaˆıtre est claire, tant au niveau du langage que du logiciel d´evelopp´e, et la seconde
approche permet d’uniformiser l’acquisition d’information et la d´efinition de sc´enarios
`a reconnaˆıtre. Dans le premier cas, le langage utilis´e pour d´ecrire les sc´enarios est bas´e
sur une logique temporelle avec op´erateurs futurs, et dans le second cas, il est bas´e sur
une logique temporelle avec op´erateurs pass´es.
Organisation
La premi`ere partie de ce m´emoire est une revue de litt´erature en deux volets. Au
chapitre 1, nous dressons un ´etat de l’art d´etaill´e des langages de signatures utilis´es par
treize syst`emes de d´etection d’intrusions. Nous proposons une taxonomie divisant ces
langages en cinq cat´egories, selon les paradigmes utilis´es.
`
A la fin de ce chapitre, nous
dressons une liste de dix propri´et´es identifi´ees comme souhaitables pour un langage de
d´etection d’intrusions. Au chapitre 2, nous pr´esentons les logiques temporelles ayant le
plus influenc´e notre travail.
La seconde partie de ce m´emoire pr´esente le travail effectu´e. Au chapitre 3, nous
d´ecrivons un outil d’acquisition passive d’information et de d´etection d’intrusions que
nous avons d´evelopp´e. Cet outil utilise un langage de signatures qui permet de com-
Introduction 4
biner et d’effectuer les deux tˆaches dans un paradigme uniforme. Au chapitre 4, nous
pr´esentons un autre langage, d´evelopp´e en vue de combler les lacunes identifi´ees avec le
premier. Entre autres, ce langage a la propri´et´e d’ˆetre purement d´eclaratif. Pour cha-
cun de ces deux langages, nous pr´esentons les algorithmes de v´erification `a utiliser et
donnons les preuves de compl´etude et de coh´erence.
La troisi`eme partie constitue la conclusion. Au chapitre 5, nous donnons quelques
id´ees pour la continuation des travaux de recherche effectu´es dans le cadre de cette
maˆıtrise. Nous dressons un bilan des travaux effectu´es au dernier chapitre.
Chapitre 1
Syst`emes de d´etection d’intrusions
Un syst`eme de d´etection d’intrusions (ou IDS pour Intrusion Detection System) est
une composante logicielle responsable d’identifier une utilisation non-d´esirable d’une
ressource informatique. On peut classer les IDS selon plusieurs crit`eres. Les crit`eres
les plus g´en´eralement rencontr´es sont le type de sonde (r´eseau ou hˆote) et le type
d’algorithme (statistique ou `a base de signatures).
Les syst`emes bas´es sur des m´ethodes statistiques, aussi appel´es d´etecteurs d’anoma-
lies, pr´esentent l’avantage de pouvoir d´ecouvrir des attaques encore non-r´epertori´ees.
Ils fonctionnent g´en´eralement en deux phases : une phase d’apprentissage et une phase
de d´etection proprement dite. Pendant la phase d’apprentissage, le syst`eme dresse un
profil de ce qui sera par la suite consid´er´e comme un comportement normal. La phase
de reconnaissance, quand `a elle, consistera `a d´etecter des d´eviations du comportement
normal. Normalement, la phase d’apprentissage continue pendant la phase de recon-
naissance. Cette strat´egie permet de faire face `a la nature changeante du comportement
des utilisateurs et ainsi de s’adapter au changement. L’hypoth`ese derri`ere cette fa¸con
de faire est que le comportement normal d’un utilisateur change de fa¸con graduelle
et qu’une utilisation non-d´esir´ee du r´eseau entraˆınera un changement brusque dans le
comportement. Cette hypoth`ese entraˆıne `a la fois des faux-positifs (fausse alarme) et
des faux-n´egatifs (attaque non-d´etect´ee). Les faux positifs surviennent lorsque les uti-
lisateurs changent leur comportement de fa¸con brusque, par exemple en installant un
nouveau logiciel. Les faux n´egatifs, quand `a eux, surviennent lorsqu’un utilisateur mal-
veillant au courant de la strat´egie de d´etection change son comportement petit `a petit
de fa¸con `a exploiter la capacit´e d’adaptation du syst`eme.
Les IDS fonctionnant `a base de signatures, quand `a eux, engendrent moins de faux-
positifs car on leur sp´ecifie exactement ce qu’ils doivent d´etecter. Cependant, comme
Chapitre 1. Syst`emes de d´etection d’intrusions 6
on doit constamment tenir `a jour leur base de signatures, le risque de faux-n´egatifs
est plus ´elev´e. Le mod`ele de syst`eme de d´etection d’intrusions `a base de signatures le
plus simple que nous puissions imaginer est celui g´en´eralement utilis´e dans le domaine
des anti-virus : celui du patron de bits. L’hypoth`ese menant `a cette m´ethode de travail
est qu’un comportement non-d´esirable peut ˆetre d´etect´e `a partir d’un petit nombre de
bits physiquement situ´es `a proximit´e les uns des autres. Dans le cas des anti-virus, il
s’agit g´en´eralement des premiers bits du fichier, alors que dans les IDS r´eseaux tels
que Snort [1], il peut s’agir de quelques bits bien cibl´es d’un seul paquet. Bien que
na¨ıve en apparence, la strat´egie du patron de bits a men´e jusqu’` a date `a de tr`es bons
r´esultats, et ce pour deux raisons : premi`erement, la complexit´e algorithmique li´ee `a la
v´erification des signatures est des plus avantageuses (constante en m´emoire et lin´eaire en
temps) ; deuxi`emement, la simplicit´e du langage de signature encourage la communaut´e
d’utilisateurs `a participer `a l’enrichissement de la base de donn´ees de signatures.
Les IDS fonctionnant `a base de patrons de bits comportent cependant des faiblesses
au niveau de l’expressivit´e des signatures qui peuvent mener autant `a des faux-positifs
qu’`a des faux-n´egatifs. C’est pourquoi la communaut´e scientifique persiste `a mettre
tant d’efforts dans le d´eveloppement d’IDS pouvant d´etecter des patrons d’´ev´enements
s´epar´es dans le temps. Les signatures de ces syst`emes permettent de prendre en compte
le contexte avant de signaler une alarme. Par exemple, dans le cas d’un IDS r´eseau, ils
permettent de sp´ecifier que pour ˆetre valide, une attaque doit survenir dans le contexte
d’une session active. Diff´erents mod`eles th´eoriques ont ´et´e utilis´es dans le cadre du
d´eveloppement de ces syst`emes, et nous allons consacrer le reste de ce chapitre `a leur
´etude.
Dans [2], C´edric Michel et Ludovic M´e proposent une taxonomie des langages utilis´es
en d´etection d’intrusions divisant ceux-ci en six cat´egories : langages d’´ev´enements,
d’exploits, de rapports, de d´etection, de corr´elation et de rapports. Dans ce chapitre,
nous nous attaquons au cas particulier des langages de d´etection, que nous subdivisons
en cinq cat´egories.
Nous commencerons notre ´etude dans la section 1.1 par les langages les plus simples :
les langages sp´ecifiques au domaine. Ces langages ont l’avantage de pr´esenter une grande
simplicit´e, mais offrent souvent une faible expressivit´e et peu de souplesse. Par la suite,
dans la section 1.2, nous jetterons un oeil aux langages imp´eratifs ayant ´et´e d´evelopp´es
sp´ecialement pour la d´etection d’intrusions. Ce sont ceux qui se rapprochent le plus des
langages de programmation habituels. Ils pr´esentent l’avantage d’offrir des primitives
associ´ees au traitement d’´ev´enements et des syst`emes de types appropri´es `a la d´etection
d’intrusions. Les signatures d´evelopp´ees avec ces langages sont cependant souvent diffi-
ciles `a maintenir. Les langages bas´es sur les syst`emes de transition, que nous traiterons
Chapitre 1. Syst`emes de d´etection d’intrusions 7
dans la section 1.3, ont ´et´e mis au point afin de pouvoir sp´ecifier d’une fa¸con d´eclarative
les sc´enarios d’attaques. Ces langages comportent cependant une partie imp´erative dont
l’objectif est souvent d’emmagasiner une partie du contexte. Les syst`emes experts, dont
nous parlerons dans la section 1.4, sont sp´ecialis´es dans l’accumulation et, surtout, l’in-
f´erence d’information concernant le contexte. Afin d’´eviter les probl`emes de m´emoire,
cette information doit cependant ˆetre g´er´ee explicitement, et le niveau d’abstraction
d´esir´e n’est pas toujours atteint. Les syst`emes bas´es sur des logiques temporelles, dont
nous parlerons finalement dans la section 1.5, sont ceux qui se rapprochent le plus de
syst`emes `a base de signatures purement d´eclaratives.
1.1 Langages sp´ecifiques au domaine
Un langage sp´ecifique au domaine, tel que d´efini dans [3], est un langage de pro-
grammation sp´ecialement con¸cu pour capturer la s´emantique propre `a un domaine d’ap-
plication particulier. Des exemples de langages sp´ecifiques au domaine sont HTML et
SQL, respectivement con¸cus pour l’´edition d’hypertextes et la consultation de bases de
donn´ees. Dans le pr´esent chapitre, chacun des syst`emes de d´etection d’intrusions que
nous pr´esentons vient avec son propre langage permettant de le configurer et/ou de
sp´ecifier des signatures particuli`eres d’attaque. Ces langages, sp´ecialement con¸cus pour
la d´etection d’intrusions ou pour la surveillance de syst`emes en g´en´eral, tombent donc
tous dans la cat´egorie des langages sp´ecifiques au domaine. Cependant, dans la plupart
des cas, ces langages sont con¸cus avec un certain souci d’abstraction permettant des
les utiliser pour diff´erents types de fichiers d’audit. Par exemple, le langage STATL
peut ˆetre utilis´e autant pour une d´etection d’intrusions au niveau hˆ ote (dans le cas de
WinSTAT et USTAT), qu’au niveau r´eseau (dans le cas de NetSTAT).
Les trois syst`emes que nous pr´esentons dans cette section se distinguent de par le
fait que les langages qu’ils utilisent sont li´es d’encore plus pr`es au type de d´etection
particulier qu’ils permettent d’effectuer. Ils ne sont pas d´efinis sur une s´emantique abs-
traite de fichiers d’audit, mais sur des s´emantiques tr`es concr`etes reli´ees aux fichiers
d’audits de processus (dans le cas de Panoptis), au filtrage de paquets (dans le cas de
Snort), et `a l’identification passive de failles de s´ecurit´e (dans le cas de NeVO). Nous
pr´esentons d`es maintenant ces trois syst`emes.
Chapitre 1. Syst`emes de d´etection d’intrusions 8
#
# Configuration file for host pooh
#
# $ Id : poo.dsl 1.6 2000/05/30 12 :26 :58 dds Exp $
#
HZ = 100 # "Floating point" value divisor
bigend = FALSE # Set to TRUE for big endian (e.g. Sun), FALSE for
# little endian (e.g. VAX, Intel x86)
map = TRUE # Set to TRUE to map uid/tty numbers to names
EPSILON = 150 # New maxima difference threshold (%)
report = TRUE # Set to TRUE to report new/updated entries
unlink = FALSE # Set to TRUE to start fresh
# Reporting procedure
output = ’| /usr/bin/tee /dev/console | /bin/mail root’
# Databases and parameters to check
dbcheck(tty, minbmin, maxbmin, maxio, maxcount) # Terminals
dbcheck(comm, ALL) # Commands
dbcheck(uid, ALL) # Users
dbcheck(uidtty, maxcount) # Users on a terminal
dbcheck(uidcomm, minbmin, maxbmin, maxutime, # Users of a command
maxstime, maxmem, maxrw, maxcount, maxasu)
# Map users and terminals into groups
usermap(caduser, john, marry, jill)
usermap(admin, root, bin, uucp, mail, news)
termmap(room202, tty31, tty32, tty33, tty34, tty35)
termmap(ptys, ttyp01, ttyp02, ttyp03, ttyp04, ttyp05, ttyp06)
Fig. 1.1 – Exemple de fichier de configuration de Panoptis.
1.1.1 Panoptis
Panoptis [3] se distingue des autres syst`emes de d´etection d’intrusions pr´esent´es dans
ce chapitre par le fait qu’il s’agit du seul syst`eme bas´e sur une d´etection d’anomalies
que nous avons choisi de pr´esenter. Comme nos travaux se situent plutˆ ot dans le cadre
de reconnaissance de sc´enarios, nous avons mis le focus sur ces types de syst`emes, mais
nous avons tout de mˆeme jug´e utile, par souci de compl´etude, d’inclure au moins un
d´etecteur d’anomalies.
Comme nous l’avons d´ej` a dit, Panoptis est configurable `a l’aide d’un langage sp´eci-
fique au domaine. Ce domaine est celui des processus d’un syst`eme Unix, et Panoptis
prend donc en entr´ee des fichiers d’audits de processus. Les auteurs affirment que le
langage a quand mˆeme ´et´e con¸cu de fa¸con assez g´en´erale pour pouvoir fonctionner sur
n’importe quel syst`eme fournissant des fichiers d’audits de processus, dont Windows NT.
Panoptis maintient des tables contenant les profils d’activit´es pour diff´erents utilisa-
teurs, terminaux, processus, ou groupages et/ou couplage de ces entit´es. Par exemple,
il peut maintenir une table concernant l’utilisation d’un processus donn´e, pour trois
utilisateurs sp´ecifiques utilisant un mˆeme terminal. Les informations maintenues pour
Chapitre 1. Syst`emes de d´etection d’intrusions 9
#
# Panoptis crontab file for host pooh
#
# The format of this file is :
# Hour Minute Day-of-month Month Day-of-week Command
* 5,25,45 * * * panoptis pooh-quick.cfg pooh.20min 20m
8-18 05 * * * panoptis pooh-hour.cfg pooh.workhour 1h
19-7 05 * * * panoptis pooh-hour.cfg pooh.late 1h
4 50 * * 1-5 panoptis pooh-day.cfg pooh.workday 24h
4 50 * * 6,0 panoptis pooh-day.cfg pooh.weekend 24h
2 20 * * 0 panoptis pooh-full.cfg pooh.weekly 7d
/usr/adm/pacct ? /usr/adm/pacct
Fig. 1.2 – Exemple de fichier de planification de tˆaches de Panoptis.
read and parse the the domain-specific language configuration
while there are records in the specified accounting file
read and decode an accounting record
synthesise the derived quantities
substitute the name of entities belonging to a group with the group name
for every database table specified
look for an database entry matching the key of the record retrieved
if a matching entry is found
compare it with the entry read
if the accounting record value exceeds the amount stored in the database
produce a new maximum value alert and update the database
else (if no matching entry is found)
produce a new value alert and update the database
Tab. 1.1 – Algorithme d’apprentissage et de v´erification de Panoptis.
Database Users*Commands, key [dds/gcc] : New entry.
Command : gcc Terminal : ttyp0 User : dds
Executed from : 2001-01-13 01 :29 :32 to : 2001-01-13 01 :29 :33 (1.36 seconds)
Database Users*Commands, key [root/ls] :
New maximum average character input/output (204.8 / 64 ; 220%)
Command : ls Terminal : ttyp1 User : root
Executed from : 2001-01-13 01 :32 :13 to : 2001-01-13 01 :32 :13 (0.41 seconds)
Fig. 1.3 – Exemple de fichier de sortie de Panoptis.
Chapitre 1. Syst`emes de d´etection d’intrusions 10
chacune des entit´es surveill´ees sont param´etrables `a l’aide d’un fichier de configuration.
Un exemple de fichier de configuration utilis´e par Panoptis se trouve `a la figure 1.1. Ce
fichier se divise en quatre parties. En premier lieu, on trouve un ensemble de d´efinitions
de variables qui servent `a d´efinir le fonctionnement g´en´eral du programme. Ensuite, on
indique la m´ethode de rapport `a utiliser. La troisi`eme partie est celle o` u on sp´ecifie
ce que l’on veut surveiller. Pour chacune des cinq tables tty, comm, uid, uidtty et
uidcomm, on sp´ecifie les champs que l’on veut surveiller. Ces champs sont pr´ed´efinis et
font partie de la d´efinition du langage. Le mot-cl´e ALL signifie que l’on veut surveiller
tous les champs. Finalement, on trouve les options de groupage qui permettent de re-
grouper certains utilisateurs ou terminaux en un seul. Par exemple, `a la figure 1.1, les
utilisateurs john, marry et jill sont regroup´es sous l’utilisateur abstrait caduser.
Une fois ces options choisies, il reste `a configurer la fr´equence `a laquelle les fichiers
d’audits sont lus par le syst`eme. Panoptis peut soit les lire en continu, soit ˆetre ex´ecut´e
`a des intervalles pr´ed´efinis. Un exemple de fichier de planification de tˆaches se trouve
`a la figure 1.2. On voit que des intervalles diff´erents, de mˆeme que des fichiers de
configuration diff´erents, peuvent ˆetre utilis´es selon les p´eriodes de la journ´ee ou de la
semaine. Finalement, `a chaque fois que Panoptis est ex´ecut´e sur un fichier d’audit,
celui-ci compare les valeurs calcul´ees `a celles se trouvant dans les tables et rapporte les
entr´ees qui pr´esentent des diff´erences significatives.
`
A la table 1.1, on peut voir l’algorithme d’apprentissage et de v´erification utilis´e par
Panoptis. Apr`es avoir synth´etis´e les donn´ees du fichier d’audit, il compare, pour chaque
entr´ee, la valeur obtenue avec celle qu’il avait d´ej` a. Si aucune valeur n’´etait pr´esente, un
´ev´enement est g´en´er´e pour signaler une nouvelle entr´ee et la valeur est ins´er´ee dans la
table. Si, au contraire, une valeur ´etait d´ej` a pr´esente, les deux valeurs sont compar´ees
et si la diff´erence entre celles-ci d´epasse le seuil de tol´erance sp´ecifi´e dans le fichier de
configuration, un ´ev´enement est g´en´er´e. Ensuite, la nouvelle valeur obtenue est ins´er´ee
`a la place de l’ancienne. Panoptis est donc un syst`eme tol´erant `a des changements de
comportements graduels. D’un cˆot´e, cette caract´eristique pr´esente l’avantage de bien
refl´eter le fait que les utilisateurs changent petit `a petit leurs habitudes, mais d’un
autre cˆot´e, elle pr´esente aussi l’inconv´enient d’offrir ainsi `a un utilisateur malveillant
un moyen d’´echapper `a la d´etection de la modification de son comportement.
`
A la figure 1.3, se trouve un exemple de fichier de sortie de Panoptis. Il y a deux
sortes d’´ev´enements : ceux correspondant `a une nouvelle entr´ee dans une table et ceux
correspondant au d´epassement du seuil de tol´erance. Dans chacun des cas, on donne
le nom de la table concern´ee ainsi que la cl´e de l’entr´ee ayant g´en´er´e l’´ev´enement et
le moment o` u celui-ci est survenu. Dans le cas o` u il s’agit d’un d´epassement de seuil,
on donne aussi la nouvelle valeur. Le premier ´ev´enement de la figure 1.3 signifie donc
Chapitre 1. Syst`emes de d´etection d’intrusions 11
que l’utilisateur dds a utilis´e le compilateur gcc pour la premi`ere fois, alors que la
seconde signifie que l’utilisateur root, `a l’aide de la commande ls, a list´e le contenu de
r´epertoires contenant deux fois plus de fichiers qu’` a l’habitude.
En r´esum´e, Panoptis constitue un cas typique de syst`eme de d´etection d’intrusions
effectuant de la d´etection d’anomalies. Il est configurable `a l’aide d’un langage tr`es
simple et sp´ecifique `a l’analyse de fichiers d’audits de processus sur un syst`eme Unix.
Un tel outil fait partie des composantes essentielles `a une architecture de s´ecurit´e car
il permet d’avoir une vision r´esum´ee de fichiers d’audits qui, dˆ u `a leur grande taille,
seraient inutilisables sinon. Comme la plupart des syst`emes effectuant de la d´etection
d’anomalies, Panoptis est sujet `a un grand nombre de faux positifs et sa nature adap-
tative le rend vuln´erable aux utilisateurs qui modifieraient tranquillement leur profil
afin de ne pas se faire remarquer. Cependant, son mode de fonctionnement g´en´erique le
rend capable de d´etecter des attaques qu’un syst`eme fonctionnant `a base de signatures
aurait pu laisser passer.
1.1.2 Snort
Le syst`eme de d´etection d’intrusions Snort [1], originellement con¸cu pour ˆetre un
renifleur (sniffer) plus ´evolu´e que tcpdump [4], s’est av´er´e petit `a petit tr`es efficace
comme outil de d´etection d’intrusions. En effet, il dispose d’un langage de signatures
permettant de d´ecrire avec une grande pr´ecision les caract´eristiques des paquets of-
fensifs circulant sur le r´eseau
1
. L’hypoth`ese derri`ere le choix de Snort comme syst`eme
de d´etection d’intrusions est donc que les attaques sont rep´erables `a l’aide d’un seul
paquet. Bien que les efforts investis par la communaut´e pour d´evelopper des langages
de signatures permettant de tenir compte de plusieurs paquets - voir tout le reste du
pr´esent chapitre - incitent `a penser qu’un langage de signatures concernant un seul
paquet n’est pas suffisamment expressif, la pratique d´emontre qu’il est tout de mˆeme
possible de d´etecter un grand nombre d’attaques sur la base d’un tel langage (la base
de signatures de Snort contient, `a ce jour, plus de 2000 signatures d’attaques).
La structure logicielle de Snort se trouve `a la figure 1.4. Utilisant, tout comme
tcpdump, la librairie de capture de paquets LibPcap [5], Snort comporte un module de
d´ecodage de paquets permettant de d´ecoder un grand nombre de protocoles de diff´erents
niveaux. Au dessus de ce module de d´ecodage se situe un ensemble de pr´eprocesseurs,
dont la fonction originale ´etait de r´egulariser le format des paquets afin de faciliter la
1
Une autre approche consiste `a d´etecter les paquets r´esultants de l’attaque. Lorsqu’il est possible
de d´efinir de tels paquets, le nombre de faux positifs est alors diminu´e.
Chapitre 1. Syst`emes de d´etection d’intrusions 12
Modules d’affichage
Réseau
Libpcap
Module de décodage
Préprocesseurs
Module de détection
Fig. 1.4 – Structure de Snort.
tˆache de la base de r`egles.
Par exemple, si une politique de s´ecurit´e sp´ecifie que personne ne doit se connecter
au service Telnet en utilisant l’utilisateur root, on voudrait pouvoir sp´ecifier une r`egle
qui surveille les paquets contenant la chaˆıne de caract`eres user : root. Cependant, il
est possible d’´echapper `a cette r`egle en utilisant le caract`ere de retour en arri`ere <BS>.
En tapant user : roo<BS>ot, un utilisateur peut alors se connecter sous le compte
root sans se faire rep´erer. Des astuces similaires s’appliquent au trafic HTTP. Pour ces
raisons, Snort comporte des pr´eprocesseurs responsables de r´egulariser le trafic Telnet
et HTTP. Il est cependant possible d’´echapper au syst`eme de d´etection d’intrusions
autrement qu’en utilisant des astuces de formatage au niveau application. Une astuce
bien connue consiste `a fragmenter le paquet offensif en plusieurs petits paquets, de
fa¸con `a ce qu’aucun des paquets r´esultants ne soit alarmant. Une autre fa¸con de faire
est d’envoyer les paquets dans un ordre ne correspondant pas `a celui dans lequel ils
seront interpr´et´es par la machine qui les recevra. Les pr´eprocesseurs frag2 et stream4
ont donc ´et´e ajout´es afin de remettre ensemble les paquets fragment´es et de pr´esenter
les paquets au syst`eme de d´etection d’intrusions dans le mˆeme ordre que celui dans
lequel le syst`eme les recevant les interpr`etera. Il s’agit encore une fois d’un travail de
formatage visant `a ´eviter certaines attaques d’´evasion.
En plus de cette fonctionnalit´e, les pr´eprocesseurs sont aussi utilis´es `a deux autres
fins : d´etecter les sc´enarios d’attaques utilisant plusieurs paquets, ainsi que permettre
l’acquisition passive d’information. Un exemple simple de cat´egorie d’attaques n´ecessi-
tant la d´etection de plusieurs paquets est le balayage (scan). Qu’il s’agisse d’un balayage
TCP, UDP, ICMP ou autre, les attaques de balayage ont pour objectif de permettre
Chapitre 1. Syst`emes de d´etection d’intrusions 13
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg :"SCAN nmap TCP" ;
stateless ; flags :A,12 ; ack :0 ; reference :arachnids,28 ;
classtype :attempted-recon ; sid :628 ; rev :3 ;)
Fig. 1.5 – Exemple de signature Snort.
`a l’attaquant d’acqu´erir de l’information sur le r´eseau ou la machine victime afin de
mieux se pr´eparer `a son attaque. Les balayages peuvent s’effectuer en utilisant des
fonctionnalit´es tout `a fait normales de la pile TCP/IP, et la seule fa¸con de les d´etec-
ter consiste g´en´eralement en la d´etection de l’utilisation abusive de ces fonctionnalit´es.
Certains pr´eprocesseurs (par exemple portscan2) ont donc ´et´e ajout´es afin de compter,
par exemple, le nombre de connexions TCP demand´ees par un hˆ ote distant dans une
fenˆetre de temps donn´ee.
Effectuer un minimum d’acquisition est plus que souhaitable pour un syst`eme de
d´etection d’intrusions : il s’agit d’une fonctionnalit´e vitale. Un exemple de pr´eproces-
seur effectuant de l’acquisition passive d’information est le pr´eprocesseur flow, dont la
tˆache est de tenir `a jour une table des sessions TCP actives. Avant l’arriv´ee de flow, il
´etait possible d’exploiter le fait que Snort fonctionnait paquet par paquet pour g´en´erer
automatiquement des paquets correspondant aux signatures d’attaque [6], engorgeant
ainsi le syst`eme de d´etection d’intrusions de faux-positifs.
Au dessus de tous ces pr´eprocesseurs, se trouvent les modules de d´etection. Ces
derniers sont responsables de reconnaˆıtre les profils de paquets offensifs. La description
des paquets `a reconnaˆıtre se trouve dans un fichier texte qui est lu `a l’amor¸cage du
programme. Le langage utilis´e pour d´ecrire ces paquets est relativement simple, ce qui
explique en partie la popularit´e et la croissance rapide du nombre d’attaques que Snort
est maintenant capable de reconnaˆıtre. Typiquement, une signature Snort est une suite
de mots-cl´e suivis de z´ero ou plusieurs arguments. Certains mot-cl´es ne concernent pas
la d´etection, mais sont simplement ajout´es afin de documenter l’attaque. Une fois les
paquets reconnus, une s´erie de modules d’affichage et d’archivage sont responsables de
l’interaction avec l’usager. Lorsque les attaques sont identifi´ees, Snort peut, entre autres,
afficher un message `a l’´ecran, ajouter une ligne dans un fichier texte, une entr´ee dans
une base de donn´ees, envoyer un message via le protocole SNMP, etc.
`
A la figure 1.5, on pr´esente un exemple de signature Snort. L’interpr´etation de cette
signature se lit comme suit : si un paquet TCP provenant de l’ext´erieur ($EXTER-
NAL_NET) p´en`etre dans notre r´eseau ($HOME_NET), peu importe les ports (any), et que
ce paquet a le drapeau ACK activ´e, de mˆeme que les deux bits r´eserv´es (flags :A,12),
et que le num´ero d’acquiescement est 0 (ack :0), peu importe l’´etat de la session (sta-
Chapitre 1. Syst`emes de d´etection d’intrusions 14
alert tcp any any <> 192.168.1.0/24 80 (content : "sex" ;
msg : "Not for children !" ; react : block, msg ;)
Fig. 1.6 – Exemple d’utilisation du module de r´eaction.
alert tcp any 143 -> any any (msg :"IMAP login" ; content :"OK LOGIN" ;
flow :established,to_client ; flowbits :set,logged_in ; flowbits :noalert)
alert tcp any any -> any 143 (msg :"IMAP list overflow attempt" ;
flow :established,to_server ; flowbits :isset,logged_in ; content :"LIST" ;)
Fig. 1.7 – Exemple d’utilisation du module flowbits.
teless), il faut alors signaler un balayage TCP fait avec nmap [7] (msg :"SCAN nmap
TCP"). Le reste de la signature constitue la documentation de l’attaque.
Cette revue de Snort serait incompl`ete si aucune allusion n’´etait faite `a la nature
particuli`ere des modules de d´etection react et flowbits. Le module react fait de Snort
non plus un simple syst`eme de d´etection d’intrusions, mais un syst`eme de pr´evention
d’intrusions. Il permet de r´eagir en interrompant les sessions TCP jug´ees offensives. Il
permet, de plus, d’envoyer un message d’avertissement `a l’usager expliquant pourquoi la
communication a ´et´e interrompue.
`
A la figure 1.6, on voit comment ce module peut ˆetre
utilis´e pour empˆecher les enfants d’aller sur des sites pornographiques. Lorsqu’un usager
tente de consulter un site web contenant le mot sex, la session TCP correspondante
est interrompue et le message not for children est affich´e dans son navigateur. Cet
exemple est tir´e de [1].
Le module flowbits, quant `a lui, a ´et´e mis au point afin de r´epondre au besoin de
plus en plus grandissant de permettre `a Snort de tenir compte de l’´etat des sessions au
niveau application. Il permet de d´efinir des variables bool´eennes (drapeaux) servant `a
suivre l’´etat de la session en changeant la valeur de ces variables (set, unset, reset,
toggle) dans certaines r`egles, et en les lisant dans d’autres (isset, isnotset). Comme
ce module a ´et´e mis au point pour suivre l’´etat des sessions au dessus de TCP, ces
variables sont instanci´ees et initialis´ees `a chaque nouvelle session TCP. Il est `a noter
que les r`egles servant `a mettre `a jour les valeurs des drapeaux contiennent g´en´eralement
le mot-cl´e noalert, signifiant que mˆeme si la r`egle est activ´ee, aucune alerte ne doit
ˆetre g´en´er´ee.
`
A la figure 1.7, on peut voir comment l’utilisation du module de d´etection
flowbits permet de diminuer le nombre de faux positifs lors de la d´etection d’une attaque
de d´ebordement de tampon d’un serveur IMAP, un protocole s’ex´ecutant g´en´eralement
Chapitre 1. Syst`emes de d´etection d’intrusions 15
sur le port TCP num´ero 143. Cette attaque, exploitant une vuln´erabilit´e de certaines
versions de imapd, s’effectue en utilisant incorrectement la commande LIST, et ne peut
r´eussir que si l’usager est correctement connect´e (au niveau application). La premi`ere
signature de la figure 1.7 sert donc `a m´emoriser le fait que le mot de passe de l’usager a
´et´e accept´e. Ce sera le cas si on voit passer la chaˆıne de caract`eres OK LOGIN. Dans ce
cas, on active drapeau logged_in et on sp´ecifie que cette r`egle ne doit pas d´eclencher
d’alerte en utilisant le mot-cl´e noalert. L’utilisation du pr´eprocesseur flow nous permet,
d’une part, de v´erifier que le paquet survient bel et bien dans le contexte d’une session
TCP active, et d’autre part, qu’il provient bien du serveur. La seconde signature permet
la d´etection de l’attaque proprement dite. Il s’agit d’une version l´eg`erement modifi´ee
de la signature num´ero 2118. Une alerte sera lanc´ee si on voit passer le mot LIST en
direction du serveur dans le cadre d’une session TCP active appartenant `a un usager
ayant r´eussi `a se connecter.
En r´esum´e, Snort est un syst`eme de d´etection d’intrusions ouvert jouissant d’une
grande popularit´e. Il fonctionne au niveau r´eseau et sa base de signatures contient la
description d’un nombre consid´erable d’attaques. Il comporte plusieurs pr´eprocesseurs
qui permettent de faciliter le travail des modules de d´etection ainsi que de prot´eger le
syst`eme d’´evasions communes et d’attaques d’inondation de faux-positifs. Ces modules
devraient faire partie int´egrante de tout bon syst`eme de d´etection d’intrusions. Les
modules de d´etection, situ´es au-dessus des pr´eprocesseurs, permettent `a l’utilisateur
de d´efinir ses propres r`egles dans un langage simple. Certains moyens ont ´et´e mis en
oeuvre pour compenser les manques les plus importants reli´es `a la nature un paquet-
une signature de ce langage. Cependant, `a mesure que ces moyens sont mis en place, il
devient de plus en plus ´evident qu’un langage de sp´ecification id´eal devrait pouvoir tenir
compte de plusieurs paquets. Le reste de ce chapitre est donc consacr´e aux langages
permettant d’exprimer des signatures s’´etalant sur plusieurs paquets (ou ´ev´enements).
1.1.3 NeVO
NeVO [8] n’est pas un syst`eme de d´etection d’intrusions, mais un identificateur
passif de failles de s´ecurit´e. La raison pour laquelle nous le mentionnons ici est que
la connaissance des failles de s´ecurit´e du r´eseau fait partie des moyens ´etant souvent
mentionn´es pour r´eduire le nombre de faux positifs g´en´er´es par un syst`eme de d´etection
d’intrusions [9, 10]. Dans [9], on trouve une courte ´etude des diff´erentes fa¸cons dont les
identificateurs de failles de s´ecurit´e pourraient ou devraient, selon les besoins, coop´erer
avec les syst`emes de d´etection d’intrusions. Par exemple, la connaissance des failles de
s´ecurit´e peut ˆetre utilis´ee pour activer ou d´esactiver certaines r`egles du syst`eme de d´e-
tection d’intrusions, diminuant ainsi `a la fois le nombre de faux positifs et la demande
Chapitre 1. Syst`emes de d´etection d’intrusions 16
faite au processeur de la machine sur laquelle le syst`eme s’ex´ecute. D’autres pensent
plutˆot que toutes les attaques devraient continuer `a ˆetre surveill´ees, sauf que l’outil de
visualisation utilis´e pour consulter le journal d’attaques devrait permettre d’identifier
celles dont le succ`es est le plus vraisemblable ´etant donn´ees les vuln´erabilit´es identifi´ees.
R´eciproquement, un autre mod`ele de coop´eration envisageable serait de lancer l’identi-
ficateur de failles seulement au moment o` u les attaques surviennent, all´egeant ainsi le
travail de ce dernier plutˆ ot que celui du syst`eme de d´etection d’intrusions. Finalement,
on ne doit pas oublier, lors de l’´etude de ces diff´erents mod`eles, que les identificateurs
de failles sont autant sujets aux faux positifs et aux faux n´egatifs que les syst`emes de
d´etection d’intrusions.
NeVO, mis au point par la compagnie Tenable, est un identificateur passif de failles
de s´ecurit´e, ce qui signifie qu’il effectue son travail sans avoir `a injecter de trafic sur le
r´eseau. Il se pr´esente comme un compl´ement ou une alternative `a Nessus [11, 12, 13], qui
est un identificateur actif de failles de s´ecurit´e. Bien que l’identification active puisse
en g´en´eral fournir des rapports plus exhaustifs que l’identification passive, elle peut
souvent s’av´erer tr`es d´erangeante pour le r´eseau en cours d’audit, voire mˆeme mener `a
son instabilit´e. De plus, l’identification passive permet d’avoir acc`es `a une information
continuellement mise `a jour. Finalement, l’identification passive permet non-seulement
de trouver les failles sur les serveurs, mais aussi sur les clients. Pour toutes ces raisons,
l’identification passive s’impose comme un compl´ement essentiel `a l’identification active.
`
A premi`ere vue, un identificateur passif de failles de s´ecurit´e ne devrait pas fonction-
ner diff´eremment d’un syst`eme de d´etection d’intrusions. D’un point de vue abstrait, on
tente d’identifier un comportement caract´eristique de l’information `a laquelle on s’in-
t´eresse. Les auteurs de [8] citent cependant deux diff´erences notables entre le mode de
fonctionnement d’un identificateur de failles et celui d’un syst`eme de d´etection d’intru-
sions : la tol´erance `a l’´echantillonnage et le mod`ele d’acc`es `a l’information.
Tol´erance `a l’´echantillonnage : Alors que le fait de n’ˆetre pas capable de traiter
en temps r´eel tout le trafic circulant sur le r´eseau peut ˆetre consid´er´e, pour un
syst`eme de d´etection d’intrusions, comme une faiblesse majeure, cette particularit´e
est beaucoup plus tol´erable pour un identificateur passif de failles de s´ecurit´e.
L’hypoth`ese permettant de dire qu’un identificateur de failles peut fonctionner
aussi bien sur une base ´echantillonnale qu’en observant la totalit´e du trafic est
que le comportement caract´eristique de la faille sera observable pratiquement `a
chaque fois que le syst`eme d´efaillant entrera en communication. Si on n’identifie
pas la faille maintenant, on l’identifiera bien plus tard.
Mod`ele d’acc`es `a l’information : L’information acquise par un identificateur pas-
sif de failles de s´ecurit´e ne doit pas, contrairement `a celle acquise par un sys-
Chapitre 1. Syst`emes de d´etection d’intrusions 17
id=700018
nooutput
hs_sport=21
name=Anonymous FTP (login : ftp)
pmatch=^USER ftp
match=^331
NEXT #-------------------------------
id=700019
dependency=700018
timed-dependency=5
hs_sport=21
name=Anonymous FTP enabled
description=The remote FTP server has anonymous access enabled.
risk=LOW
pmatch=^PASS
match=^230
Fig. 1.8 – Exemple de signature NeVO.
t`eme de d´etection d’intrusions, ˆetre archiv´ee `a chaque fois qu’elle est d´etect´ee. Au
contraire, l’identificateur doit plutˆot tenir `a jour un mod`ele du r´eseau et le fournir
sur demande. Cette demande sera typiquement faite au moment de la consultation
du journal d’attaques du syst`eme de d´etection d’intrusions. L’information n’est
donc pas envoy´ee directement `a l’utilisateur, mais conserv´ee jusqu’` a ce qu’elle soit
demand´ee.
Ces deux diff´erences concernant l’architecture logicielle d’un identificateur passif de
failles ne justifient cependant pas le fait que le langage utilis´e pour d´ecrire les fa¸cons de
d´etecter les failles soit diff´erent de celui utilis´e par un syst`eme de d´etection d’intrusions,
et c’est pourquoi nous nous attarderons maintenant au langage de NeVO. Ce langage
est fortement d´edi´e `a l’acquisition passive d’information sur un r´eseau informatique. De
plus, l’acquisition d’information faite `a l’aide de ce langage se limite au niveau appli-
cation. Cela signifie que l’inspection faite sur les paquets se limite `a la partie donn´ees
de ceux-ci, et non aux diff´erents champs des diff´erents protocoles ni `a l’interaction de
ceux-ci. NeVO incorpore cependant un module permettant de d´etecter passivement les
syst`emes d’exploitation des machines communiquant sur le r´eseau en inspectant les
entˆetes des paquets SYN, mais ce module n’utilise pas le langage de NeVO.
Une signature NeVO concerne g´en´eralement un seul paquet. On sp´ecifie le contenu
recherch´e `a l’aide du mot-cl´e match. Cependant, il est possible de sp´ecifier, `a l’aide
du mot-cl´e pmatch, le contenu du paquet pr´ec´edent dans la mˆeme session. Par d´efaut,
le contenu est recherch´e en mode texte. Il est cependant possible de rechercher un
contenu binaire `a l’aide du mot-cl´e bmatch. Le mot-cl´e regex permet de rechercher des
expressions r´eguli`eres. Le mot-cl´e dependency permet de sp´ecifier qu’une signature ne
doit ˆetre consid´er´ee, pour un flux TCP donn´e, que si une autre signature a ´et´e activ´ee.
Chapitre 1. Syst`emes de d´etection d’intrusions 18
Le mot-cl´e time-dependency permet de limiter le d´elai d’attente entre l’activation des
deux signatures. Le mot-cl´e description permet de sp´ecifier le message a afficher et le
mot-cl´e nooutput signifie qu’il n’y a pas de message `a afficher. On trouve `a la figure 1.8
un exemple de signature NeVO (tir´e de [8]) responsable d’identifier les serveurs FTP
ayant un compte anonymous actif. Cette signature se divise en deux sous-signatures. La
premi`ere est responsable d’identifier les paquets contenant une demande de connexion
pour l’utilisateur ftp suivie d’une acceptation du nom d’utilisateur (code 331). La
seconde, activ´ee seulement dans les 5 secondes suivant l’activation de la premi`ere, est
responsable d’identifier l’envoi d’un mot de passe suivi de l’acceptation de ce mot de
passe (code 230).
En r´esum´e, NeVO est un exemple tr`es int´eressant d’identificateur passif de failles
de s´ecurit´e. Mˆeme s’il a ´et´e d´evelopp´e `a des fins commerciales (habituellement, la docu-
mentation disponible sur les outils commerciaux se limite aux aspects externes), on peut
trouver une documentation riche et pr´ecise sur son fonctionnement interne.
`
A premi`ere
vue, son langage d´edi´e `a l’identification de simples paquets au niveau application pour-
rait nous porter `a croire que le nombre de comportements observables est plutˆ ot limit´e,
mais la possibilit´e de sp´ecifier une notion de d´ependance entre les r`egles augmente sans
aucun doute l’expressivit´e du langage de fa¸con significative. Cependant, cette fa¸con ad
hoc de r´egler le probl`eme des sc´enarios complexes ne saurait amener toute l’expressivit´e
d´esirable. Entre autres, elle ne permet pas de reconnaˆıtre le fait qu’un paquet donn´e
n’arrive pas dans un certain d´elai, ou encore de compter le nombre d’occurrences d’un
paquet donn´e. De plus, il est dommage que la s´emantique du langage se limite au niveau
application. Le fait de pouvoir sp´ecifier des paquets au niveau des diff´erentes couches
de protocoles permettrait sans doute de d´etecter plus de failles et, sans n´ecessairement
se limiter aux failles, d’acqu´erir encore plus d’information.
1.2 Langages imp´eratifs
La distinction entre les langages imp´eratifs et les langages d´eclaratifs, dans la litt´e-
rature, n’est pas aussi nette que l’on pourrait le croire. G´en´eralement, on se contente
de d´efinir informellement un langage d´eclaratif comme ´etant un langage permettant de
d´efinir ce que l’on veut identifier, plutˆ ot que comment l’identifier. Les autres langages
tombent tous sous la cat´egorie des langages imp´eratifs. Sur la base de cette d´efinition,
le langage de signatures de Snort, par exemple, est clairement d´eclaratif.
`
A l’exception des langages pr´esent´es dans la pr´esente section, les langages que nous
pr´esentons dans ce chapitre ont tous la pr´etention d’ˆetre d´eclaratifs. Plus loin dans
Chapitre 1. Syst`emes de d´etection d’intrusions 19
ce chapitre, nous proposerons une d´efinition plus formelle permettant de d´epartager
les langages d´eclaratifs des langages imp´eratifs. Pour l’instant, nous pr´esentons deux
langages qui, peu importe la d´efinition utilis´ee, appartiennent certainement `a la cat´ego-
rie des langages imp´eratifs. RUSSEL, que nous pr´esentons dans un premier lieu, a ´et´e
con¸cu dans le but d’analyser s´equentiellement des fichiers d’audit, alors que Bro, que
nous pr´esentons par la suite, a ´et´e con¸ cu afin de pouvoir exprimer les signatures dans
un langage typ´e proche de celui utilis´e pour exprimer les politiques de s´ecurit´e dans un
contexte de d´etection d’intrusions au niveau r´eseau.
1.2.1 ASAX
ASAX [14, 15, 16] a ´et´e d´evelopp´e dans le but d’analyser des traces d’audit. La syn-
taxe de RUSSEL, le langage utilis´e pour ´ecrire les signatures, se trouve `a la table 1.2.
L’ex´ecution d’un programme RUSSEL implique l’analyse s´equentielle d’un fichier de
trace d’audit. Une trace d’audit est d´efinie comme ´etant une s´equence finie d’enregis-
trements, qui eux sont d´efinis comme ´etant une fonction partielle associant des valeurs
`a un ensemble d’´etiquettes, aussi appel´ees champs. Ces enregistrements sont pass´es `a
ASAX dans un format normalis´e (Normalized Audit Data Format), qui permet de faire
abstraction du type d’audit.
La notion centrale de ASAX est celle de contexte d’ex´ecution. Un contexte d’ex´e-
cution est entre autres caract´eris´e par trois ensembles de r`egles : Cur, Nxt et Cmp.
L’ensemble Cur contient les instances de r`egles qui doivent ˆetre ex´ecut´ees sur l’en-
registrement courant, l’ensemble Nxt contient les instances de r`egles qui doivent ˆetre
ex´ecut´ees sur l’enregistrement suivant, et l’ensemble Cmp contient l’ensemble des r`egles
qui doivent ˆetre ex´ecut´ees une fois que tous les enregistrements sont trait´es. L’utilit´e de
ce dernier ensemble est de permettre d’effectuer des traitements sur des valeurs ayant
´et´e accumul´ees tout au long du traitement de la trace d’audit. Par exemple, il permet
de calculer une moyenne et de la sauvegarder quelque part. Ces trois ensembles doivent
ˆetre maintenus `a jour explicitement par celui qui ´ecrit les r`egles via le mot-cl´e Trigger
off.
Une autre caract´eristique d’un contexte d’ex´ecution est l’ensemble des valeurs des
diff´erentes variables. Ces variables peuvent ˆetre de trois types : locales `a une r`egle, glo-
bales, ou correspondre aux champs d’un enregistrement. Comme l’ordre d’ex´ecution des
r`egles n’est pas sp´ecifi´e, l’utilisation de variables globales peut amener un certain non-
d´eterminisme. Aussi, pour palier aux probl`emes d´ecoulant du fait que certains champs
peuvent ˆetre absents de certains enregistrements, on a ajout´e un mot-cl´e present, per-
mettant de tester la pr´esence d’un champ. Lorsqu’un champ est absent, il est tout de
Chapitre 1. Syst`emes de d´etection d’intrusions 20
R : := rule Q ( . . . ; G; . . . ) ; . . . ; H; . . . ; A
G : := P : T
H : := V : T
A : := V := E [ Y ( . . . , E , . . . )
[ trigger off M Q ( . . . , E , . . . ) [ begin . . . ; A;. . . end
[ do . . . ; C → A; . . . od [ if . . . ; C → A; . . . fi
C : := true [ F present [ not C [ C B C [ E S E
E : := L [ V [ F [ P [ -E [ E O E [ X(. . . ,E,. . . )
B : := and [ or
O : := + [ - [ * [ div [ mod
S : := > [ < [ = [ = [ ≤ [ ≥
M : := for current [ for next [ at completion
T : := integer [ byte [ string
A actions O arithmetic operators
B logical operators P formal parameters
C conditions Q rule names
E expressions R rules
F field names S relational operators
G parameter declarations T types
H variable declarations V local variables
L literals X external function names
M triggering modes Y external procedure names
Tab. 1.2 – Syntaxe abstraite de RUSSEL.
mˆeme possible de lire sa valeur. La valeur lue est alors celle qui ´etait pr´esente la der-
ni`ere fois que le champ ´etait pr´esent, et les r´esultats obtenus sont susceptibles d’ˆetre
tr`es diff´erents de ceux escompt´es.
`
A la figure 1.9 se trouve un exemple de signature ´ecrit en RUSSEL pour ASAX. Cet
exemple a ´et´e copi´e tel quel de [14]. Les variables evt et res sont des champs qui sont
suppos´es faire partie de chaque enregistrement. Ensemble, les deux r`egles Failed_login
et Count_rule1 servent `a surveiller un utilisateur qui ´echouerait `a se connecter trop
souvent. On remarque que la r`egle Failed_login se r´eactive inconditionnellement (ligne
8). La r`egle Count_rule1 d´emontre la s´emantique particuli`ere d’un bloc if. . . fi. Ces
blocs renferment une s´erie de conditions, chacune suivie d’un bloc d’actions. D`es qu’une
condition est v´erifi´ee, le bloc correspondant est ex´ecut´e et le bloc if. . . fi est termin´e.
Chapitre 1. Syst`emes de d´etection d’intrusions 21
01.rule Failed login (maxtimes, duration : integer)
02.# This rule detects a first failed login and triggers off an accounting rule with an
03.# expiration time
04.begin
05.if evt=’login’ and res=’failure’ and is unsecure (terminal)
06. → Trigger off for next Count rule1 (maxtimes-1, timestp+duration)
07.fi;
08.Trigger off for next Failed login (maxtimes, duration)
09.end
10.
11.rule Count rule1 (countdown, expiration : integer)
12.# This rule counts the subsequent failed logins,
13.# it remains active until its expiration time or until the countdown becomes 0
14.if evt=’login’ and res=’failure’
15. and is unsecure(terminal) and timestp < expiration
16. → if countdown > 1
17. → Trigger off for next Count rule1(countdown-1, expiration) ;
18. countdown =1
19. → SendMessage (”too much failed login’s”)
20. fi;
21. timestp ≥ expiration
22. → Skip;
23. true
24. → Trigger off for next Count rule1 (countdown, expiration)
25.fi
Fig. 1.9 – D´etection d’une p´en´etration externe dans ASAX.
L’instruction skip est l’instruction qui ne fait rien. Donc, si le d´elai est ´ecoul´e (ligne 21),
la r`egle n’est pas r´eactiv´ee. Sinon, la condition true est v´erifi´ee et la r`egle est r´eactiv´ee
pour le prochain enregistrement.
En r´esum´e, RUSSEL est un langage de programmation imp´eratif comportant, en
plus des notions les plus communes, celles de contexte d’ex´ecution et de variables d’en-
registrement. Ces notions permettent d’automatiser certaines tˆaches communes au trai-
tement s´equentiel de fichier d’audit telles que la mise `a jour de la base de r`egles et la
mise `a jour des valeurs des champs des enregistrements. Cependant, il n’est pas du tout
clair que l’approche consistant `a d´evelopper un nouveau langage ait ´et´e ici la meilleure
`a adopter. Les notions particuli`eres au langage RUSSEL auraient tr`es bien pu ˆetre im-
plant´ees sans d´evelopper un nouveau langage. Par exemple, on aurait pu envisager une
approche orient´ee-objet dans un langage d´ej` a connu de la communaut´e (tel que C++),
et arriver `a des r´esultats semblables sinon meilleurs du point de vue de la facilit´e de
maintenance et de la courbe d’apprentissage.
Chapitre 1. Syst`emes de d´etection d’intrusions 22
Réseau
Libpcap
Module d ’événements
Interpréteur de scripts
Fig. 1.10 – Structure de Bro.
1.2.2 BRO
Bro [17] est un syst`eme de d´etection d’intrusions con¸cu sp´ecifiquement en vue de
d´etecter les attaques survenant au niveau r´eseau. Son architecture logicielle en couches,
que l’on peut voir `a la figure 1.10, est comparable `a celle de Snort.
`
A la base, se trouve la
mˆeme librairie de capture de paquets (libpcap). Le module d’´ev´enements fait un travail
relativement semblable `a celui auquel les pr´eprocesseurs de Snort, conjointement au
module de d´ecodage, ´etaient initialement destin´es : faire un premier travail de formatage
sur les paquets afin de simplifier la tˆ ache de l’interpr´eteur de scripts de politiques de
s´ecurit´e. Ce dernier est comparable au module de d´etection. Il n’y a pas, pour Bro,
d’´equivalent des modules d’affichage. Tout est archiv´e dans des fichiers en format texte.
Malgr´e le fait que les deux architectures puissent se ressembler au premier abord,
il y a tout de mˆeme deux diff´erences majeures entre les deux syst`emes : l’abstraction
cr´e´ee par le module d’´ev´enements et la nature imp´erative du langage de signatures.
Alors que les objets fournis par les pr´eprocesseurs de Snort au module de d´etection
sont des paquets, ceux fournis par le module d’´ev´enements de Bro `a l’interpr´eteur de
scripts sont d’un type plus abstrait : celui d’´ev´enement. Ceci implique qu’un processus
de filtrage est fait par le module d’´ev´enements, et que seulement les informations jug´ees
pertinentes sont pass´ees `a l’interpr´eteur de scripts. Un des objectifs de cette ´etape
de filtrage est de permettre au syst`eme de fonctionner en temps r´eel, malgr´e la grande
affluence de trafic pouvant circuler sur le r´eseau. Aussi, les politiques de s´ecurit´e v´erifi´ees
avec Bro sont normalement plus haut niveau que celles v´erifi´ees par Snort, voire mˆeme la
plupart des autres syst`emes de d´etection d’intrusions. En fait, il s’agit d’un des objectifs
poursuivis par les auteurs : permettre une s´eparation claire entre les m´ecanismes et les
politiques de s´ecurit´e. Les m´ecanismes, dans ce cas, sont les diff´erents moyens de g´en´erer
un ´ev´enement donn´e, alors que les politiques de s´ecurit´e sont les actions `a prendre
lorsque les ´ev´enements sont identifi´es. Les m´ecanismes sont donc g´er´es au niveau du
Chapitre 1. Syst`emes de d´etection d’intrusions 23
01.global hot_names = { "root", "lp", "uucp" } ;
02.global finger_log = open("finger.log") ;
03.event finger_request(c :connection, request : string, full : bool)
04.{
05. if ( byte_len(request) > 80 ) {
06. request = fmt("%s...", sub_bytes(request, 1, 80)) ;
07. ++c$hot ;
08. }
09. if ( request in hot_names )
10. ++c$hot ;
11. local req = request == "" ? "ANY" : fmt("`"%s`"", request) ;
12. if ( c$addl != "" )
13. # This is an additional request.
14. req = fmt("(%s)", req) ;
15. if ( full )
16. req = fmt("%s (/W)", req) ;
17. local msg = fmt("%s > %s %s", c$id$orig_h, c$id$resp_h, req) ;
18. if ( c$hot > 0 )
19. log fmt("finger : %s", msg) ;
20. print finger_log, fmt("%.6f %s", c$start_time, msg) ;
21. c$addl = c$addl == "" ? req : fmt("*%s, %s", c$addl, req) ;
22.}
Fig. 1.11 – Exemple de script Bro.
moteur d’´ev´enements, programm´e en C++, alors que les politiques de s´ecurit´e sont
mises en oeuvre par l’interpr´eteur de scripts. Ces derni`eres sont ´ecrites dans un langage
de signatures propre `a Bro.
Alors que le langage de signatures de Snort est un langage d´eclaratif d´ecrivant
certaines caract´eristiques bien cibl´ees des paquets circulant sur le r´eseau, celui de Bro est
un langage imp´eratif, quasi aussi expressif que le langage C (sa syntaxe en est d’ailleurs
en plusieurs points tr`es semblable), avec d´eclaration de variables (locales ou globales),
expressions compos´ees, inf´erence et v´erification de types, etc. Un des objectifs vis´e par le
d´eveloppement de ce langage est de permettre, au moment de la compilation, d’effectuer
un maximum de v´erification de types, de fa¸con `a ce qu’au moment de l’ex´ecution, le
type des variables r´ef´erenc´ees soit coh´erent. Pour ce faire, le langage de Bro dispose
de plusieurs types de variables propres `a la r´eseautique : port, adresse IP, nom r´eseau,
etc. Le langage dispose aussi de structures de donn´ees abstraites : ensemble, table
d’associations, enregistrement ; permettant d’exprimer naturellement des v´erifications
dans un langage proche des politiques de s´ecurit´e : si il y a une connexion Telnet
sur un des serveurs d’impression, alors. . . . Il est `a noter que bien que le langage de
Bro soit imp´eratif, celui-ci ne dispose pas de construction syntaxique it´erative. Cette
caract´eristique a ´et´e voulue par les concepteurs afin de minimiser le temps de traitement
d’un ´ev´enement. Cependant, comme la r´ecursivit´e est tout de mˆeme permise, l’it´eration
est toujours possible. Les concepteurs n’ont toutefois pas relev´e de cas ou son utilisation
se faisait ressentir.
Chapitre 1. Syst`emes de d´etection d’intrusions 24
`
A la figure 1.11, on peut voir un exemple de script de politique de s´ecurit´e ´ecrit
dans le langage de Bro. Cet exemple, tir´e de [17], montre comment on doit r´eagir `a
une requˆete finger. L’op´erateur $ sert `a acc´eder aux diff´erents champs des structures.
L’op´erateur in (ligne 9) sert `a v´erifier si un ´el´ement fait partie d’un ensemble. Le script
v´erifie en premier lieu si la requˆete est excessivement longue (ligne 5). Le cas advenant,
celle-ci est tronqu´ee et le champ hot est incr´ement´e. Ensuite, il v´erifie si la requˆete
concerne un nom sensible (ligne 9). Si tel est le cas, le champ hot est encore incr´ement´e.
La variable locale req est ensuite initialis´ee (lignes 11 `a 16) et, si le champ hot a ´et´e
incr´ement´e (ligne 18), une notification en temps r´eel est effectu´ee (ligne 19). Dans tous
les cas, la requˆete est archiv´ee (ligne 20). Finalement, la requˆete est enregistr´ee dans le
champ addl de la connexion (ligne 21). Advenant le cas o` u une autre requˆete a eu lieu
dans le contexte de la mˆeme connexion, ce qui peut ˆetre associ´e `a un comportement
malicieux, elle est ajout´ee `a celle s’y trouvant d´ej` a et un ast´erisque est ajout´e pour
attirer l’attention lors de l’inspection du fichier d’audit.
L’algorithme de v´erification en temps-r´eel de Bro fonctionne en une seule passe et
suivant un seul fil d’ex´ecution (thread). Lorsqu’un paquet est captur´e sur le r´eseau par
la librairie libpcap, il est pass´e au moteur d’´ev´enements. Celui-ci peut alors g´en´erer de
z´ero `a plusieurs ´ev´enements pour un seul paquet (r´eciproquement, un type d’´ev´enement
donn´e peut ˆetre g´en´er´e par plusieurs types de paquets diff´erents). Ces ´ev´enements sont
alors plac´es dans une file d’attente et, par la suite, trait´es par l’interpr´eteur de scripts de
politiques de s´ecurit´e. Pour un ´ev´enement donn´e, il peut y avoir plusieurs traitements `a
faire. Ceux-ci sont effectu´es dans l’ordre o` u ils apparaissent dans le fichier de script. Il
est `a noter que ces traitements peuvent, en plus de g´en´erer des alarmes, cr´eer d’autres
´ev´enements qui iront se placer `a la fin de la file et devront ˆetre trait´es avant de retourner
au moteur d’´ev´enements et de passer au paquet suivant.
Les travaux entourant Bro sont grandement motiv´es par la pratique et l’article [17]
traite de plusieurs probl`emes concrets devant ˆetre pris en compte lors de la concep-
tion d’un syst`eme de d´etection d’intrusions en temps r´eel. L’auteur parle entre autres
des diff´erentes fa¸cons d’attaquer le syst`eme lui-mˆeme et des moyens de s’en d´efendre,
des probl`emes reli´es `a la surveillance de r´eseaux haut-d´ebit (principalement en ce qui
concerne la perte de paquets), des diff´erentes fa¸cons de g´erer les chronom`etres, des
avantages et des inconv´enients de disposer d’un langage compil´e, des probl`emes reli´es
au red´emarrage du syst`eme (souvent n´ecessaire pour faire un nettoyage de la m´emoire),
etc. Quiconque s’engage dans des travaux reli´es `a la d´etection d’intrusions en temps
r´eel devrait au moins prendre quelques minutes pour jeter un oeil `a cet article.
En r´esum´e, Bro est un syst`eme de d´etection d’intrusions fonctionnant au niveau
r´eseau dont la conception a grandement ´et´e influenc´ee par des probl`emes pratiques. Il
Chapitre 1. Syst`emes de d´etection d’intrusions 25
vient avec un langage imp´eratif interpr´et´e qui permet d’exprimer des scripts v´erifiant
des politiques de s´ecurit´e `a un plus haut niveau que la plupart des autres syst`emes de
d´etection d’intrusions. Son architecture en couches, semblable `a celle de Snort, a ´et´e
con¸cu avec un souci d’extensibilit´e et permet d’ajouter des modules d’´ev´enements et
de d´efinir nos propres politiques de s´ecurit´e assez facilement. Le langage utilis´e pour
exprimer les politiques de s´ecurit´e reste cependant imp´eratif, ce qui implique que l’on
indique plutˆ ot comment v´erifier les politiques, que les politiques elle-mˆemes. Il faut
tout de mˆeme donner `a Bro le m´erite d’avoir eu l’id´ee de s´eparer les m´ecanismes des
politiques au niveau mˆeme de l’architecture du logiciel et d’avoir pr´evu deux modules
diff´erents pour g´erer ces deux aspects.
1.3 Syst`emes de transitions
Les syst`emes de transition jouissent d’une grande popularit´e en informatique lorsque
vient le temps de d´ecrire des programmes ou des processus de fa¸con abstraite. Les ob-
jectifs vis´es par ces descriptions varient de la simple communication entre les diff´erents
intervenants dans le processus de d´eveloppement `a la v´erification automatique de pro-
pri´et´es de programmes. Les syst`emes de d´etection d’intrusions que nous allons pr´esenter
dans cette section utilisent diff´erents formalismes bas´es sur des syst`emes de transitions
pour repr´esenter les attaques. STAT, dans un premier lieu, utilise les automates g´en´e-
ralis´es, qui diff`erent des automates traditionnels par la pr´esence de variables dans les
´etats permettant de relier les diff´erents symboles de l’alphabet (ou ´ev´enements) entre
eux. IDIOT, dans un second lieu, utilise les r´eseaux de Petri color´es, qui diff`erent des r´e-
seaux de Petri conventionnels de la mˆeme fa¸con. L’avantage des r´eseaux de Petri sur les
automates est de permettre une repr´esentation du synchronisme et du parall´elisme de
fa¸con plus naturelle. En troisi`eme et dernier lieu, nous pr´esenterons BSML, qui se base
sur les expressions r´eguli`eres pour les ´ev´enements, qui diff`erent elles aussi des expres-
sions r´eguli`eres par la pr´esence de variables du premier ordre, ainsi que de contraintes
de temps. Mˆeme si les expressions r´eguli`eres sont connues pour avoir le mˆeme pouvoir
de repr´esentation que les automates, BSML n’a pas exactement la mˆeme expressivit´e
que STATL. Ceci est dˆ u au fait que STATL, comme nous le verrons, utilise plusieurs
types de transitions pour sp´ecifier l’algorithme de v´erification reli´e `a l’automate, alors
que les expressions de BSML sont traduites en automates g´en´eralis´es avec seulement
des transitions classiques.
Chacun des syst`emes que nous pr´esentons dans cette section a ´et´e con¸ cu dans l’id´ee
de permettre la repr´esentation des signatures d’attaque de fa¸con d´eclarative. Les au-
teurs de ces travaux, surtout en ce qui concerne STATL et IDIOT, consid`erent que
Chapitre 1. Syst`emes de d´etection d’intrusions 26
les syst`emes de transition constituent un moyen de repr´esenter ce qui doit ˆetre d´etect´e
plutˆot que comment le d´etecter. Le dictionnaire en ligne Foldoc
2
propose, pour le terme
langage d´eclaratif, la d´efinition suivante :
D´efinition 1.1 (Langage d´eclaratif) Any relational language or functional language.
These kinds of programming language describe relationships between variables in terms
of functions or inference rules, and the language executor (interpreter or compiler)
applies some fixed algorithm to these relations to produce a result.
Declarative languages contrast with imperative languages which specify explicit ma-
nipulation of the computer’s internal state ; or procedural languages which specify an
explicit sequence of steps to follow.
The most common examples of declarative languages are logic programming lan-
guages such as Prolog and functional languages like Haskell.
Tous les langages ´etudi´es dans le reste de ce chapitre disposent d’un algorithme fixe
de v´erification, comme mentionn´e dans le premier paragraphe de la d´efinition. Cepen-
dant, comme nous le verrons, plusieurs sont aussi pourvus de constructions syntaxiques
qui permettent de modifier explicitement le contenu de la m´emoire. En se r´ef´erant au
second paragraphe de la d´efinition, on r´ealise alors que l’on se rapproche de la fronti`ere
entre langage d´eclaratif et langage imp´eratif.
Maintenant que nous avons une d´efinition plus claire de la diff´erence entre langage
d´eclaratif et imp´eratif, nous sommes prˆets `a ´etudier les syst`emes de d´etection d’intru-
sions bas´es sur les syst`emes de transition, qui sont `a la fronti`ere entre les deux types de
langages.
1.3.1 STAT
STAT (State Transition Analysis Technique) [18] utilise une approche qui se veut
d´eclarative. Le formalisme utilis´e pour sp´ecifier les signatures se base sur les automates
g´en´eralis´es. STAT fournit un langage g´en´eral, STATL (STAT Language), permettant de
sp´ecifier des automates. La s´emantique attribu´ee `a ces syst`emes d´epend de l’extension
utilis´ee. Les diff´erentes extensions permettent de faire diff´erents types de d´etection d’in-
trusions. Par exemple, les extensions USTAT [19] et WinSTAT permettent de sp´ecifier
des signatures au niveau hˆ ote pour les syst`emes d’exploitation Unix et Windows, alors
2
www.foldoc.org
Chapitre 1. Syst`emes de d´etection d’intrusions 27
que l’extension NetSTAT [20] permet de sp´ecifier des signatures au niveau r´eseau.
Les syst`emes de transition d´efinis `a l’aide du langage STATL sont constitu´es d’´etats
et de transitions. Les transitions, qui peuvent ˆetre activ´ees par les actions effectu´ees sur
le syst`eme, sont de trois types : consuming, non-consuming, et unwinding. Les transi-
tions de type consuming correspondent exactement aux transitions r´eguli`eres des auto-
mates finis : lorsque l’action correspondant `a l’´etiquette de la transition est effectu´ee,
le syst`eme change d’´etat. Les transitions non-consuming cr´eent une copie du syst`eme
avant de changer d’´etat. Les transitions consuming permettent donc de sp´ecifier des pro-
pri´et´es de la prochaine action telle que, alors les transitions non-consuming permettent
de sp´ecifier l’existence d’une prochaine action telle que. Finalement, les actions unwin-
ding permettent d’´eliminer des syst`emes. Plus sp´ecifiquement, ils permettent d’´eliminer
toutes les copies ayant ´et´e faites du syst`eme depuis qu’il a travers´e un ´etat donn´e. Ceci
permet de repr´esenter le fait qu’une action peut tout annuler.
`
A la figure 1.12, on peut voir un exemple, tir´e de [18], de sc´enario exprimable `a l’aide
du langage STATL. Ce sc´enario permet de d´etecter une session TCP `a demi ouverte. Une
session TCP est dite `a demi ouverte si le serveur a accept´e une demande de connexion
(le SYN et le SYN-ACK ont eu lieu) et est en attente de la confirmation (le dernier
ACK) de la part de l’hˆote ayant demand´e la connexion. Si, pour un serveur donn´e,
trop de connexions sont simultan´ement `a demi ouvertes, celui-ci peut cesser d’accepter
de nouvelles connexions. Il est possible d’exploiter ce fait pour effectuer une attaque
de d´eni de service, connue sous le nom de SYN-Flood. Le sc´enario de la figure 1.12
comporte donc trois ´etats : l’´etat initial (s0), l’´etat en attente de confirmation (s1), et
l’´etat final s2. Le sc´enario est param´etr´e par une variable, timeout, indiquant combien
de temps on doit attendre la confirmation. La premi`ere transition du sc´enario, SYN,
est activ´ee lorsqu’un paquet de type SYN (ayant le drapeau SYN activ´e et le drapeau
ACK d´esactiv´e) est identifi´e. Cette transition est de type non-consuming, signifiant que
lorsqu’elle est activ´ee, une copie du sc´enario est effectu´ee avant de passer `a l’´etat s1.
Aussi, lors de l’activation de cette transition, les variables locales du sc´enario servant
`a m´emoriser les adresses IP et les ports TCP de la victime et de l’attaquant sont
initialis´ees selon les valeurs contenues dans le paquet. On voit bien, avec la transition
SYN, les deux parties constituantes d’une transition : la condition d’activation et les
actions `a poser lors de l’activation. En arrivant dans l’´etat s1, le chronom`etre t0 est
d´emarr´e avec comme d´elai la valeur de la variable timeout fournie en param`etre. Si,
avant l’´ecoulement du d´elai, un paquet ACK ou un paquet RST sont vus pour les
adresses IP et les ports TCP correspondant au SYN (transitions ACK et RST), tout est
annul´e et le sc´enario retourne `a l’´etat original car ces transitions sont de type unwinding.
Si, au contraire, aucun de ces paquets n’est vu avant que le d´elai ne s’´ecoule, la transition
Timed_out est activ´ee et le sc´enario passe (sans duplication, puisque la transition est de
Chapitre 1. Syst`emes de d´etection d’intrusions 28
use netstat ;
scenario halfopentcp(int timeout)
{
IPAddress victim_addr ;
Port victim_port ;
IPAddress attacker_addr ;
Port attacker_port ;
timer t0 ;
initial state s0 {}
transition SYN (s0 -> s1) nonconsuming
{
[IP ip [TCP tcp]] :
(tcp.tcp_header.flags & TH_SYN) && !(tcp.tcp_header.flags & TH_ACK)
{
victim_addr=ip.header.dst ;
victim_port=tcp.header.dst ;
attacker_addr=ip.header.src ;
attacker_port=tcp.header.src ;
}
}
state s1
{
{ timer_start(t0, timeout) ; }
}
transition ACK (s1 -> s0) unwinding
{
[IP ip [TCP tcp]] :
(ip.header.dst==victim_addr) && (tcp.header.dst==victim_port) &&
(ip.header.src==attacker_addr) && (tcp.header.src==attacker_port) &&
!(tcp.header.flags & TH_SYN) && (tcp.header.flags & TH_ACK)
}
transition RST (s1 -> s0) unwinding
{
[IP ip [TCP tcp]] :
(ip.header.src==victim_addr) && (tcp.header.src==victim_port) &&
(ip.header.dst==attacker_addr) && (tcp.header.dst==attacker_port) &&
(tcp.header.flags & TH_RST)
}
transition Timed_out (s1 -> s2) consuming
{
timer t0 ;
}
state s2
{
{
HALFOPENTCP e ;
e = new HALFOPENTCP(attacker_addr, attacker_port, victim_addr,
victim_port, start) ;
enqueue_event(e, HALFOPENTCP, start) ;
}
}
}
Fig. 1.12 – Session `a demi ouverte dans NetSTAT.
Chapitre 1. Syst`emes de d´etection d’intrusions 29
Fig. 1.13 – Session `a demi ouverte dans l’outil STATed.
Fig. 1.14 – Mod´elisation d’un r´eseau avec NetSTAT.
Chapitre 1. Syst`emes de d´etection d’intrusions 30
type consuming) `a l’´etat s2. En arrivant dans cet ´etat, un nouvel ´ev´enement est cr´e´e,
signalant ainsi le fait qu’une session `a demi ouverte a ´et´e identifi´ee. Cet ´ev´enement peut
alors servir de condition d’activation aux transitions d’autres sc´enarios, servant ainsi `a
la d´etection, par exemple, d’une attaque SYN-Flood.
`
A la figure 1.13, on peut voir une
repr´esentation graphique de ce sc´enario, obtenue `a l’aide de l’outil STATed, un ´editeur
de sc´enarios t´el´echargeable avec STAT. Les conditions d’activation et les actions `a poser
peuvent ˆetre sp´ecifi´ees en cliquant sur les ´etats et les transitions.
Un aspect int´eressant de l’extension NetSTAT est qu’elle permet de sp´ecifier la topo-
logie du r´eseau afin d’am´eliorer la d´etection d’intrusions. On peut voir, `a la figure 1.14,
un exemple de telle mod´elisation. Un r´eseau est vu comme un ensemble d’interfaces,
alors que les hˆ otes et les liens de donn´ees sont vus comme deux partitions diff´erentes de
cet ensemble. La sp´ecification comprend en outre des renseignements sur ces hˆotes et ces
interfaces tels que leurs adresses mat´erielles et logicielles. Ces informations permettent,
par exemple, de d´etecter des attaques d’usurpation d’identit´e en calculant le chemin par
lequel deux hˆ otes sont suppos´es communiquer. Par exemple, `a la figure 1.14, Wilder ne
devrait pas voir passer de message en provenance de Carpenter pour Lang. Finalement,
la sp´ecification de la topologie permet, en fonction des attaques que l’on veut d´etecter,
de calculer l’emplacement des sondes et de les configurer pour qu’elles surveillent les
´ev´enements pertinents.
En bref, le syst`eme STAT, avec le langage STATL, constitue une avanc´ee en direction
d’un langage d´eclaratif. Cependant, avec ses trois types de transition, ses variables
partag´ees et ses actions `a ex´ecuter `a l’activation des transitions, le langage STATL
comporte encore une bonne part d’imp´erativit´e. Un aspect tr`es int´eressant de l’extension
NetSTAT est la prise en compte de la topologie pour sp´ecifier, am´eliorer et automatiser
une partie de la d´etection d’intrusions.
1.3.2 IDIOT
IDIOT [21, 22, 23], tout comme STAT, utilise une approche qui se veut d´eclarative.
Le formalisme employ´e pour sp´ecifier les signatures se base sur les r´eseaux de Petri
color´es. Cette approche pr´esente deux avantages. Premi`erement, les r´eseaux de Petri
permettent de bien repr´esenter le parall´elisme et le synchronisme, deux ph´enom`enes
bien pr´esents en d´etection d’intrusions. Avec STAT, le parall´elisme est sous-entendu par
l’ex´ecution parall`ele des syst`emes de transition, alors que le synchronisme est repr´esent´e
par l’utilisation des variables partag´ees. Le deuxi`eme avantage de l’approche choisie
r´eside dans le choix de r´eseaux color´es. Les r´eseaux color´es permettent, comme avec
STAT, de d´efinir des patrons d’´ev´enements reli´es les uns aux autres. Par exemple, ils
Chapitre 1. Syst`emes de d´etection d’intrusions 31
01. extern int RLOGIN PORT CLIENT, RLOGIN PORT SERV,
02. print tcp conn(int, int) ;
03. pattern TCP Conn Mon ”Monitor rlogin connections” priority 10
04. int FROM PORT, FROM HOST;
05. int TO PORT, TO HOST;
06. state start ;
07. nodup state after syn, after syn ack ;
08. state after ack ;
09. post action¦print tcp conn(FROM HOST, TO HOST) ;¦
10. neg invariant first inv
11. state inv start, inv final ;
12. trans rst(TCP)
13. <- inv start ;
14. -> inv final ;
15. [ ¦this[RST] = 1 && TO HOST = this[FROM HOST] &&
16. this[TO HOST] = FROM HOST;¦
17. end rst ;
18. end first inv
19. trans tcp 1(TCP) /* TCP is the event type of the transition */
20. <- start ;
21. -> after syn;
22. [ ¦this[SYN] = 1 && this[ACK] = 0 &&
23. FROM PORT = this[FROM PORT] &&
24. this[TO PORT] = RLOGIN PORT SERV &&
25. FROM HOST = this[FROM HOST] && TO HOST = this[TO HOST] ;¦
26. end tcp 1 ;
27. trans tcp 2(TCP)
28. <- after syn;
29. -> after syn ack ;
30. [ ¦ this[SYN] = 1 && this[ACK] = 1 &&
31. (this[FROM PORT] = RLOGIN PORT SERV)&&
32. (this[TO PORT] = FROM PORT) &&
33. (this[FROM HOST] = TO HOST) && (this[TO HOST] = FROM HOST) ;
34. ¦
35. end tcp 2 ;
36. trans tcp 3(TCP)
37. <- after syn ack ;
38. -> after ack ;
39. [ ¦ this[SYN] = 0 && this[ACK] = 1 &&
40. (this[FROM PORT] = FROM PORT) &&
41. (this[TO PORT] = RLOGIN PORT SERV) &&
42. (this[FROM HOST] = FROM HOST) && (this[TO HOST] = TO HOST) ;
43. ¦
44. end tcp 3 ;
45. end TCP Conn Mon;
Fig. 1.15 – Session TCP dans IDIOT.
Chapitre 1. Syst`emes de d´etection d’intrusions 32
permettent de sp´ecifier que deux paquets diff´erents doivent avoir les mˆemes adresses IP
sources et destination.
La documentation sur IDIOT est plutˆot rare, et il fait partie des syst`emes qu’il ne
nous a pas sembl´e possible de t´el´echarger. Ce que nous avons `a notre disposition est
un nombre assez restreint d’exemples tir´es d’articles. L’exemple de la figure 1.15 est
tir´e de [23]. Il montre comment on peut utiliser, dans le syst`eme IDIOT, les r´eseaux de
Petri color´es pour sp´ecifier l’´etablissement d’une session TCP. Aux lignes 6,7, et 8 se
trouvent les d´eclarations des ´etats. Comme l’´etablissement d’une session TCP se fait
en trois ´etapes, on a besoin de quatre ´etats pour la sp´ecifier. Le mot-cl´e nodup, `a la
ligne 7, signifie que lorsqu’une transition sortante est activ´ee, l’´etat n’est pas dupliqu´e.
On obtient donc ici un r´esultat semblable aux transitions consuming de STAT, sauf
que la sp´ecification se fait au niveau des ´etats plutˆot qu’au niveau des transitions. La
ligne 9 sp´ecifie quelle est l’action `a effectuer lorsque l’´etat final a ´et´e atteint. Les lignes
10 `a 18 sp´ecifient un invariant qui doit ˆetre v´erifi´e par le syst`eme. La notion d’invariant,
en IDIOT, s’apparente `a la notion de transition unwinding en STATL. La sp´ecification
d’un invariant prend la forme d’un r´eseau de Petri, avec ses propres ´etats et ses propres
transitions.
`
A chaque fois qu’un jeton sort de l’´etat initial, une copie en est plac´ee dans
l’´etat initial de l’invariant. Dans l’exemple qui nous occupe, l’invariant nous permet de
sp´ecifier qu’aucun paquet RST ne doit ˆetre envoy´e pendant l’´etablissement d’une session
TCP. Les lignes 19 `a 26, 27 `a 35, et 36 `a 45 sp´ecifient chacune des transitions. Les deux
premi`eres lignes indiquent les ´etats entrants et sortants de la transition, alors que le
reste sp´ecifie les conditions devant ˆetre respect´ees par le jeton pour que la transition
soit activ´ee.
En r´esum´e, le syst`eme IDIOT semble pr´esenter certains avantages au niveau de la
repr´esentation du parall´elisme et du synchronisme. Cependant, sa d´ependance envers un
autre langage, qui se mat´erialise par la pr´esence du mot-cl´e extern, en fait un syst`eme
incomplet qui devrait finalement plutˆ ot ˆetre vu comme une librairie compl´ementaire
`a un syst`eme d´ej`a existant. De plus, la pr´esence du mot-cl´e nodup nous am`ene au
mˆeme reproche que nous avons fait `a STAT quand `a la nature d´eclarative du langage.
Finalement, l’absence dans la litt´erature d’une documentation compl`ete du langage, ne
serait-ce que de sa syntaxe, nous empˆeche de porter un jugement ´eclair´e `a souhait sur
ses forces et ses faiblesses.
1.3.3 BSML
Le langage BSML (Behavioral Specification Monitoring Language) [24] tend lui aussi
vers une approche d´eclarative. Le formalisme utilis´e pour repr´esenter les comportements
Chapitre 1. Syst`emes de d´etection d’intrusions 33
p := e(x
1
, . . . , x
n
)[cond

!p

p
1
; p
2

p
1
[[p
2

p

p within [t
1
, t
2
]
Tab. 1.3 – Syntaxe des patrons dans BSML.
`a identifier est celui des expressions r´eguli`eres pour les ´ev´enements (ERE). Les diff´e-
rences entre les expressions r´eguli`eres conventionnelles et les ERE sont la pr´esence de
pr´edicats du premier ordre pour relier les ´ev´enements entre eux et la possibilit´e de
sp´ecifier des contraintes de temps-r´eel.
La syntaxe des ERE utilis´ees dans le langage BSML se trouve `a la table 1.3. Un
patron d’´ev´enements est soit un ´ev´enement primitif, param´etr´e par (x
1
, . . . , x
n
) et res-
pectant la condition cond, soit la non-occurrence d’un patron donn´e (!p), soit le patron
p
1
suivi imm´ediatement du patron p
2
(p
1
; p
2
), soit le patron p
1
ou bien le patron p
2
(p
1
[[p
2
), soit la r´ep´etition un nombre ind´etermin´e de fois du patron p (p

), soit le pa-
tron p devant survenir dans l’intervalle de temps [t
1
, t
2
] (p within [t
1
, t
2
]). L’expression
p..q est utilis´ee pour abr´eger p; (!(p[[q))

; q. Aussi, on utilise les expressions p over t et
p within t pour abr´eger respectivement p within [t, ∞] et p within [0, t].
Une sp´ecification BSML ne comporte cependant pas que des ERE. Une sp´ecification
BSML est un ensemble de d´eclarations de variables ainsi que de couples p → act, o` u act
est une action `a poser chaque fois que le patron p est reconnu. Cette action peut ˆetre
un simple archivage ou encore la manipulation (incr´ementation, d´ecr´ementation) d’un
compteur. Plusieurs compteurs peuvent aussi ˆetre regroup´es dans une table. La notion
de compteur en BSML est assez originale car elle permet de donner une valeur plus
´elev´ee aux ´ev´enements plus r´ecents. Les conditions d’activation des actions associ´ees
aux compteurs ne sont alors plus n´ecessairement d´efinies sur le nombre d’´ev´enements
identifi´es, mais sur le poids pond´er´e de ces ´ev´enements.
L’exemple de la figure 1.16 est tir´e de [24]. Cette signature sert `a d´etecter une inon-
dation TCP SYN. Aux lignes 1 `a 3, on d´efinit un pr´edicat sur deux paquets TCP servant
`a v´erifier si ceux-ci appartiennent `a la mˆeme session (dans des directions oppos´ees, i.e.
avec les adresses IP et les ports invers´es).
`
A la ligne 5, on d´efinit l’´ev´enement tcp_syn(p)
comme ´etant la r´eception d’un paquet (rx(p)) tel que le drapeau tcp_syn est activ´e,
mais pas le drapeau tcp_ack.
`
A la ligne 6, on d´efinit l’´ev´enement tcp_syn_ack(p,q)
comme ´etant l’envoi, en direction oppos´ee, d’un paquet ayant les drapeaux tcp_syn et
tcp_ack activ´es. Finalement, `a la ligne 7, on d´efinit l’´ev´enement tcp_ack(q, r) comme
´etant la r´eception, en direction oppos´ee au syn_ack, d’un paquet ayant seulement le
drapeau tcp_ack d’activ´e. Aux lignes 9 `a 13, on d´eclare la table neptune qui servira
Chapitre 1. Syst`emes de d´etection d’intrusions 34
01.same_session(p, q) =
02. p.daddr=q.saddr && p.tcp_dport=q.tcp_sport &&
03. p.saddr=q.daddr && p.tcp_sport=q.tcp_dport
04.
05.event tcp_syn(p) = rx(p)| p.tcp_syn && !p.tcp_ack
06.event tcp_synack(p, q) = tx(q)| same_session(p,q) && q.tcp_syn && q.tcp_ack
07.event tcp_ack(q, r) = rx(r)| same_session(q,r) && !r.tcp_syn && r.tcp_ack
08.
09.Table neptune(
10. (unsigned int, unsigned short) /*key : (IP address,port)*/
11. 1000, 120, /*size 1000, window 120 seconds */
12. 4, 1, neptuneBegin, neptuneEnd /* thresholds and associated functions*/
13.)
14.
15.(tcp_syn(p1)..tcp_synack(p1,p2)) ;(( !tcp_ack(p2,p3))* over 60) ->
16. neptune.inc((p1.daddr, p1.tcp_dport))
Fig. 1.16 – Attaque TCP SYN-Flood dans BSML.
`a compter les occurrences de poign´ees de main non-compl´et´ees. La cl´e de cette table
est le couple adresse-port destination du paquet syn. La fonction neptuneBegin est
appel´ee, par exemple pour lancer une alerte, chaque fois que 4 incr´ementations sur une
entr´ee de la table sont faites dans un intervalle de 120 secondes. Cette incr´ementation
est elle-mˆeme effectu´ee chaque fois que les deux premi`eres ´etapes d’une poign´ee de main
TCP sont effectu´ees mais que la troisi`eme ne survient pas dans les 60 secondes suivant
la deuxi`eme (lignes 15 et 16).
Le langage BSML est un langage compil´e, et les ERE sont transform´ees en machines
`a ´etats ´etendues. La diff´erence entre une machine `a ´etat ´etendue et une machine `a ´etats
conventionnelle est la mˆeme qu’entre des r´eseaux de Petri conventionnels et des r´eseaux
de Petri color´es : les ´etats de la machine contiennent des variables qui permettent de
relier entre eux les symboles lus par la machine. Bien entendu, les symboles de l’alphabet
(´ev´enements primitifs) sont donc eux aussi caract´eris´es par des variables.
Contrairement aux langages ´etudi´es jusqu’`a maintenant, le langage BSML permet
non-seulement de sp´ecifier les comportements qui ne doivent pas survenir, mais aussi les
comportements qui doivent survenir, lan¸cant ainsi des alarmes lorsque le comportement
observ´e d´evie de ce qui est attendu. Le langage BSML permet ainsi une certaine forme
de d´etection d’anomalies, non pas bas´ee sur des m´ethodes statistiques et l’´etablissement
empirique d’un profil normal, mais sur la sp´ecification explicite de ce profil. L’avantage
principal de cette d´emarche, selon les auteurs, est la d´etection d’attaques inconnues. Les
auteurs jugent aussi que cette d´emarche diff`ere suffisamment des d´emarches statistiques
et `a base de sc´enarios pour en faire une troisi`eme cat´egorie : d´etection d’intrusions `a
base de sp´ecifications. Dans [25], on trouve une sp´ecification compl`ete de ftpd faite avec
BSML. BSML peut donc servir non-seulement au niveau r´eseau, mais aussi au niveau
Chapitre 1. Syst`emes de d´etection d’intrusions 35
des applications s’ex´ecutant sur un syst`eme donn´e.
Les actions effectu´ees lors de la reconnaissance de patrons peuvent d´epasser le simple
archivage : il peut aussi s’agir d’instructions visant `a prot´eger le syst`eme qui se fait
attaquer. BSML permet ainsi non-seulement une d´etection d’intrusions en temps r´eel,
mais aussi une pr´evention d’intrusion.
En r´esum´e, BSML est un langage simple et concis bas´e sur un formalisme cou-
ramment utilis´e par les informaticiens : celui des expressions r´eguli`eres. Ce langage est
compil´e vers un autre formalisme qui le rend comparable `a STATL et `a IDIOT : ce-
lui des machines `a ´etat ´etendues. Il dispose de primitives permettant d’exprimer des
contraintes temps-r´eel pos´ees sur les ´ev´enements et de relier ceux-ci entre eux par la
valeur de leurs attributs. Parmi les trois langages ´etudi´es dans cette section, il est celui
qui se rapproche le plus d’un langage d´eclaratif car les actions pos´ees lors de la recon-
naissance de patrons n’influencent pas la reconnaissance ult´erieure d’autres patrons.
Cependant, les actions pos´ees par les compteurs indiquent qu’ils jouent eux aussi un
rˆole important dans l’expressivit´e du langage et que les expressions r´eguli`eres `a elles
seules ne sont pas suffisantes pour exprimer les propri´et´es voulues. Il s’agit cependant
d’un bon compromis entre expressivit´e et complexit´e algorithmique.
1.4 Syst`emes experts
Un syst`eme expert est un logiciel capable d’accumuler et d’inf´erer de la connais-
sance. De plus, les syst`emes experts sont souvent appel´es `a prendre des d´ecisions. Un
exemple c´el`ebre de syst`eme expert est celui de MYCIN, mis au point dans les ann´ees 70
afin d’aider les m´edecins `a poser des diagnostics sur les maladies infectieuses du sang.
Le syst`eme demande au m´edecin quels sont les symptˆomes de la maladie, et pose un
diagnostique `a l’aide d’une base de r`egles ayant pr´ealablement ´et´e ´etablie par d’autres
m´edecins. L’objectif d’un syst`eme expert est de simuler le raisonnement d’un expert
dans un domaine particulier de connaissance. Peu importe le domaine, l’hypoth`ese de
base faite sur les raisonnements effectu´es par les experts est que ceux-ci sont g´en´erale-
ment de la forme SI. . . ALORS. . . . Par exemple : SI il y a de la fum´ee ALORS il y a
du feu. Cette r`egle, ajout´ee `a la r`egle SI il y a du feu ALORS on doit sonner l’alarme
d’incendie, permet au syst`eme expert de recommander de sonner l’alarme d’incendie
lorsqu’il y a de la fum´ee.
Les syst`emes experts en d´etection d’intrusions sont int´eressants pour deux raisons :
leur capacit´e d’accumuler et d’inf´erer de la connaissance permet une d´etection plus pr´e-
Chapitre 1. Syst`emes de d´etection d’intrusions 36
cise, et leur capacit´e `a prendre des d´ecisions permet de r´eagir aux attaques identifi´ees de
fa¸con automatis´ee. Dans cette section, nous donnerons deux exemples de syst`emes ex-
perts employ´es en d´etection d’intrusions : P-BEST et Lambda. P-BEST est un syst`eme
expert ayant ´et´e employ´e pendant plusieurs ann´ees dans le domaine de la recherche
et de la d´etection d’intrusions, alors que LAMBDA a d’abord ´et´e con¸cu comme un
langage ayant pour objectif de permettre aux experts du domaine de transcrire leurs
connaissances dans un langage simple.
1.4.1 P-BEST
P-BEST (Production-Based Expert System Toolset) [26, 27, 28] est en fait un en-
semble d’outils permettant de d´evelopper un syst`eme expert. Il ne s’agit pas d’un sys-
t`emes expert au sens propre du terme car, en th´eorie, un syst`emes expert comporte
trois composantes principales : un moteur d’inf´erence, un moteur de d´ecision et une
base de connaissance (qui elle mˆeme se divise en faits et en r`egles d’inf´erences). P-
BEST ne comporte que les deux premi`eres composantes, qui d’un point de vue pratique
ne forment qu’une seule et mˆeme composante. Par abus de langage, nous dirons tout
de mˆeme que P-BEST est un syst`eme expert.
D’un point de vue algorithmique, P-BEST fonctionne en chaˆınage avant. Ceci signifie
que, `a chaque ajout d’un nouveau fait, l’ensemble des r`egles d’inf´erence est parcouru et
que toute l’information d´eductible de ce fait est ajout´ee `a la base de connaissance. La
base de faits contient donc `a la fois les faits de base et les faits calcul´es. Cette philosophie
s’oppose au chaˆınage arri`ere, qui consiste `a emmagasiner seulement les faits de base, et `a
inf´erer sur demande. En d´etection d’intrusions, o` u chaque ´ev´enement signal´e correspond
`a un fait, et o` u les conclusions critiques doivent ˆetre tir´ees aussitˆot que possible, le
chaˆınage avant s’impose donc comme la voie `a suivre. De plus, le chaˆınage avant permet
`a P-BEST de conserver un minimum d’information en ne conservant dans sa base de
faits que ceux qui ont ´et´e d´eduits et en ´eliminant ceux correspondant aux ´ev´enements.
P-BEST fournit un langage compil´e en C qui offre la possibilit´e de faire appel `a des
routines programm´ees dans ce langage, conservant ainsi une certaine simplicit´e tout en
permettant un maximum de souplesse. Un exemple de r`egle d’inf´erence utilis´ee par P-
BEST se trouve `a la figure 1.17. Aux ligne 1 `a 3, on voit comment le langage fourni par
P-BEST permet de d´eclarer des types d’´ev´enements. Les param`etres #10 ;* indiquent
le niveau de priorit´e de la r`egle et le fait que la mˆeme r`egle peut ˆetre appliqu´ee plusieurs
fois `a un mˆeme ´ev´enement. Les niveaux de priorit´e permettent de sp´ecifier que certaines
r`egles doivent ˆetre ex´ecut´ees avant d’autres. L’op´erateur *, indiquant que la r`egle peut
ˆetre rappel´ee plusieurs fois, peut causer des boucles infinies `a l’ex´ecution du syst`eme
Chapitre 1. Syst`emes de d´etection d’intrusions 37
01. ptype[event event_type :int, return_code :int,
02. username :string, hostname :string]
03. ptype[bad_login username :string, hostname :string]
04.
05. rule[Bad_Login(#10 ;*) :
06. [+e :event| event_type == login, return_code == BAD_PASSWORD]
07. ==>
08. [+bad_login| username = e.username, hostname = e.hostname]
09. [-|e]
10. [ !|printf("Bad login for user %s from host %s`n",
11. e.username, e.hostname)]
12. ]
Fig. 1.17 – Exemple de r`egle d’inf´erence dans P-BEST.
s’il n’est pas utilis´e correctement.
`
A chaque fois que cet op´erateur est utilis´e, on doit
s’assurer que l’´ev´enement sera d´etruit par au moins une des r`egles. L’op´erateur -, utilis´e
`a la ligne 9, permet justement d’effectuer cette tˆ ache. Il permet de retirer des faits de la
base de connaissances ; en particulier, il permet aussi de retirer des ´ev´enements. Chaque
´ev´enement doit normalement ˆetre soigneusement effac´e de la base de connaissance afin
d’´eviter un engorgement de la m´emoire utilis´ee. On doit aussi s’assurer que la r`egle
supprimant l’´ev´enement ait la priorit´e la plus basse, afin d’´eviter que celui-ci ne soit
supprim´e avant que toutes les r`egles en ayant besoin aient pu l’utiliser. Finalement,
l’op´erateur + doit ˆetre vu comme un quantificateur existentiel, l’op´erateur ! permet de
faire un appel `a une routine externe, et l’op´erateur ==> s´epare la pr´emisse des conclu-
sions. En conclusion, la r`egle de la figure 1.17 est donc activ´ee par les ´ev´enements de
type login ayant un code de retour ´egal `a la constante BAD_PASSWORD. Lorsqu’un tel
´ev´enement survient, celui-ci est d´etruit (ligne 9) apr`es avoir cr´e´e un nouvel ´ev´enement
de type bad_login (ligne 8), et un message, indiquant qu’une tentative de connexion a
´echou´e (ligne 10), est affich´e `a l’aide de la fonction externe printf.
D’autres op´erateurs sont aussi disponibles dans le langage de P-BEST. Par exemple,
il existe des op´erateurs permettant d’activer ou de d´esactiver dynamiquement des r`egles
d’inf´erence. P-BEST peut donc prendre des d´ecisions `a propos de son propre fonction-
nement. Le principal int´erˆet de cette fonctionnalit´e est de permettre une forme d’opti-
misation en d´esactivant des r`egles jug´ees temporairement non pertinentes. Il est aussi
possible, afin de simplifier l’´ecriture de certaines r`egles, de modifier les champs de cer-
tains faits. Ceci permet d’´emuler la notion de variable, facilitant ainsi, par exemple, la
d´efinition de compteurs. Finalement, le langage fournit des op´erateurs permettant de
marquer ou de d´emarquer des ´ev´enements, permettant ainsi `a certaines r`egles de laisser
des traces qui peuvent ˆetre utilis´ees par d’autres r`egles.
En r´esum´e, le syst`eme P-BEST permet de d´evelopper des syst`emes experts dans
Chapitre 1. Syst`emes de d´etection d’intrusions 38
e := a

0

e
1
; e
2

e
1
[e
2

e

e
1
?e
2

e
1
&e
2
Tab. 1.4 – Syntaxe du calcul d’´ev´enements utilis´e dans LAMBDA.
un langage compil´e qui permet une interop´erabilit´e simple et efficace avec d’autres lan-
gages, et par cons´equent d’autres syst`emes. D’un point de vue abstrait, les fonctionna-
lit´es de base d’un syst`eme expert, soient l’accumulation et l’inf´erence de connaissance,
de mˆeme que l’aide `a la prise de d´ecision, sont tout `a fait souhaitables en d´etection
d’intrusions et P-BEST les impl´emente tr`es bien. Cependant, le langage de P-BEST
n’est peut-ˆetre pas des plus appropri´es pour la gestion de flots d’´ev´enements. En effet,
l’association fait-´ev´enement respecte bien le paradigme des syst`emes experts, mais cer-
tains aspects du langage et de l’impl´ementation d´epassent le cadre des syst`emes experts
et demandent une connaissance des algorithmes utilis´es en arri`ere-plan. Par exemple,
le chaˆınage avant force l’utilisateur `a s’assurer de donner les bons niveaux priorit´e aux
diff´erentes r`egles. De plus, la suppression des ´ev´enements qu’il n’est plus n´ecessaire de
conserver en m´emoire doit ˆetre faite explicitement, ce qui complique (inutilement) la
r´edaction de r`egles. Finalement, les notions de r`egles r´ep´etables, de marquage d’´ev´ene-
ments, et d’activation/d´esactivation de r`egles donnent `a P-BEST des possibilit´es pra-
tiquement algorithmiques qui d´epassent le cadre strict des syst`emes experts. P-BEST
nous convainc donc que les caract´eristiques principales d’un syst`eme expert sont sou-
haitables en d´etection d’intrusions, mais l’impl´ementation sugg`ere que le paradigme pur
des syst`emes experts semble n’ˆetre pas parfaitement adapt´e `a la tˆache.
1.4.2 LAMBDA
LAMBDA est un langage abstrait permettant de d´ecrire des sc´enarios d’attaque sans
se soucier des d´etails de d´etection. La description qui en est donn´ee dans [29] est d´etach´ee
des d´etails d’impl´ementation, et repose sur l’hypoth`ese que d’autres outils d’audit (dont
des syst`emes de d´etection d’intrusions) fournissent un flux d’´ev´enements bas niveau `a
analyser. LAMBDA n’est pas d´ecrit par ses auteurs comme un langage de sp´ecification
de syst`eme expert, mais comporte tout de mˆeme les trois caract´eristiques que nous
avons identifi´ees comme ´etant d´esirables d’un syst`eme expert, soient l’accumulation
et l’inf´erence de connaissance, de mˆeme que la possibilit´e de prendre des d´ecisions et
de r´eagir automatiquement. De plus, comme LAMBDA est sp´ecialement con¸cu pour la
description d’attaques, il comporte des primitives sp´ecialement reli´ees `a ce domaine. Par
exemple, il permet de d´efinir un sc´enario d’attaque de deux points de vue diff´erents :
Chapitre 1. Syst`emes de d´etection d’intrusions 39
attack attack name(arg
1
, arg
2
, . . .)
pre : φ
pre
post : φ
post
scenario :
s
where : ψ
s
detection :
d
where : ψ
d
verification :
v
where : ψ
v
o` u φ
i
est une formule de la logique du deuxi`eme ordre
ψ
i
est une formule de la logique du premier ordre

i
est une formule du calcul des ´ev´enements
Tab. 1.5 – Syntaxe d’un sc´enario d’attaque LAMBDA.
celui de l’attaquant et celui du syst`eme de d´etection. Bien que les deux points de vue
soient en g´en´eral tr`es semblables, il arrive cependant que certaines actions effectu´ees
par l’attaquant puissent ne pas ˆetre d´etectables par le syst`eme attaqu´e. Par exemple, il
peut s’agir de certains calculs effectu´es `a l’interne.
Le langage LAMBDA offre une solution hybride pour exprimer les sc´enarios d’at-
taque, et repose sur trois langages diff´erents, d´ependamment du point de vue auquel on
se place. Pour repr´esenter la connaissance acquise, on utilise la logique du deuxi`eme
ordre. On utilise des pr´edicats du deuxi`eme ordre pour mod´eliser, par exemple, la
connaissance de l’attaquant : le pr´edicat knows(A, φ) exprime le fait que l’attaquant
A acquiert la connaissance φ. Pour repr´esenter les contraintes d’ordonnancement de-
vant ˆetre respect´ees par les diff´erentes ´etapes d’un sc´enario d’attaque, on utilise le
calcul d’´ev´enements [30], dont la syntaxe est donn´ee `a la table 1.4. Un ´ev´enement peut
ˆetre soit un ´ev´enement primitif (a), soit l’´ev´enement nul (0), soit une s´equence d’´ev´e-
nements (e
1
; e
2
), soit l’ex´ecution parall`ele de deux ´ev´enements (e
1
[e
2
), soit l’absence
d’´ev´enements (e), soit le choix non-d´eterministe d’´ev´enements (e
1
?e
2
), soit l’ex´ecution
synchronis´ee d’´ev´enements (e
1
&e
2
). L’action nulle, combin´ee au choix non-d´eterministe,
permet de repr´esenter un ´ev´enement facultatif [e]
def
= e ? 0. Il est `a noter que l’´ev´ene-
ment primitif a est d´efini sur un intervalle de temps [t
1
, t
2
], et non comme ´etant un
´ev´enement ponctuel. Pour les ´ev´enements ponctuels survenant `a l’instant t, l’intervalle
est [t, t]. Finalement, pour exprimer les contraintes autres que l’ordonnancement de-
vant ˆetre respect´ees par les diff´erents ´ev´enements du sc´enario, on utilise simplement la
logique du premier ordre.
La syntaxe d’un sc´enario d’attaque exprim´e en LAMBDA se trouve `a la table 1.5.
Chapitre 1. Syst`emes de d´etection d’intrusions 40
Action touch(Agent,File) Action block(Agent,Printer)
Pre : true Pre : printer(Printer),
Post : file(File), owner(Agent,File) physical access(Agent,Printer)
Post : blocked(Printer)
Action lpr-s(Agent,Printer,File) Action remove(Agent,File)
Pre : printer(Printer), file(File), Pre : owner(Agent, File)
authorized(Agent,read,File) Post : not(file(File))
Post : queued(File,Printer)
Action ln-s(Agent,Link,File) Action unblock(Agent,Printer)
Pre : not(file(Link)) Pre : printer(Printer), blocked(Printer),
Post : linked(Link,File) physical access(Agent,Printer)
Post : not(blocked(Printer))
Action print-process(Printer,Link) Action get-file(Agent,File)
Pre : queued(Link,Printer), Pre : printed(Printer,File),
linked(Link,File), physical access(Agent,Printer)
not(blocked(Printer)) Post : read access(Agent,File)
Post : printed(Printer,File),
not(queued(Link,Printer))
Fig. 1.18 – Mod´elisation du sc´enario d’acc`es ill´egal `a un fichier avec LAMBDA.
Le lien avec la base de connaissances se fait via les clauses pre et post. La clause pre
exprime les conditions devant ˆetre satisfaites par le syst`eme avant l’ex´ecution du sc´enario
afin que celui-ci puisse r´eussir. La clause post exprime l’´etat du syst`eme une fois que
l’ex´ecution du sc´enario a r´eussi. Les clauses scenario et detection donnent les d´etails
de l’attaque du point de vue de l’attaquant et de l’attaqu´e. La clause verification,
quand `a elle, indique comment valider l’effet de l’attaque. Les auteurs parlent aussi
d’ajouter une clause reaction, permettant d’indiquer comment r´eagir `a l’attaque pour
se prot´eger. Finalement, les clauses where donnent les relations entre les diverses ´etapes
des sc´enarios.
Les notions de post et de pre-conditions permettent, en plus de valider l’occurrence
d’attaques, de corr´eler les diff´erents sc´enarios entre eux. Deux sc´enarios sont corr´el´es si
les post-conditions de l’un correspondent aux pre-conditions de l’autre. Cette notion de
corr´elation permet d’une part de factoriser les sc´enarios d’attaques lorsqu’un objectif
interm´ediaire peut ˆetre atteint de diff´erentes fa¸cons, et d’autre part de d´ecouvrir des
sc´enarios d’attaques insoup¸conn´es.
Nous n’avons pas trouv´e, dans la litt´erature, d’exemple de sc´enario d’attaque ex-
prim´e avec LAMBDA utilisant le calcul des ´ev´enements. Tous les exemples sur lesquels
nous avons pu mettre la main n’utilisaient, dans la partie scenario, que des actions
simples. C’est le cas, entre autres, du sc´enario d’acc`es ill´egal `a un fichier, pr´esent´e `a la
figure 1.18. Ce sc´enario se d´eroule en huit ´etapes. Premi`erement (1), l’attaquant cr´ee
un fichier auquel il aura alors les droits d’acc`es. Ensuite (2), l’attaquant ayant un acc`es
physique `a une imprimante bloque celle-ci, par exemple en retirant le bac de papier. Il
lance alors la commande d’impression du fichier cr´e´e (3), et comme il a les droits d’acc`es
Chapitre 1. Syst`emes de d´etection d’intrusions 41
pour ce fichier, la commande est plac´ee dans la file d’impression. L’impression ne peut
avoir lieu imm´ediatement, car l’imprimante est bloqu´ee. Les prochaines ´etapes sont la
suppression du fichier pour lequel une commande d’impression a ´et´e lanc´ee (4), et la
cr´eation d’un lien logique vers le fichier cible ayant le mˆeme nom que le fichier supprim´e
(5). Il ne reste ensuite qu’` a d´ebloquer l’imprimante (6), pour que l’impression du fichier
puisse avoir lieu (7), donnant ainsi acc`es `a l’attaquant au fichier auquel il n’avait pas
droit (8).
En r´esum´e, LAMBDA est un langage qui offre les mˆemes avantages qu’un para-
digme bas´e sur un syst`eme expert : soient l’accumulation et l’inf´erence d’information,
de mˆeme qu’un support `a la d´ecision. De plus, l’approche hybride utilisant le calcul
d’´ev´enements permet d’exprimer des sc´enarios d’attaque selon une syntaxe claire et
concise qui semble au moins aussi satisfaisante sinon plus que celles employ´ees avec
les syst`emes de transition. Des aspects int´eressants de LAMBDA sont la s´eparation du
point de vue de l’attaquant et du point de vue de l’attaqu´e, de mˆeme que les notions de
v´erification et de r´eaction. Aussi, la description logique des effets et des pr´emisses d’une
attaque permet de faire un calcul de sc´enario d’attaque afin d’´elaborer de nouveaux
sc´enarios.
1.5 Logiques temporelles
Les trois derniers travaux que nous pr´esentons, LogWeaver, Monid, et Chronicles,
sont ceux qui se rapprochent le plus de ceux que nous avons effectu´es de par le fait que
les langages de sp´ecification utilis´es ont ´et´e d´evelopp´es `a partir de logiques temporelles.
LogWeaver utilise une logique temporelle future du premier ordre, alors que Monid
utilise une logique temporelle pass´ee et future du premier ordre avec points fixes nomm´ee
Eagle et que Chronicles se base sur une logique r´eifi´ee. Dans les trois cas, les algorithmes
utilis´es ont ´et´e con¸cus de fa¸con `a pouvoir travailler en ligne (online). Grossi`erement,
un algorithme est dit en ligne s’il peut traiter s´equentiellement sur un fichier d’audit
`a partir du d´ebut sans avoir `a m´emoriser tout le fichier. Un exemple d’algorithme qui
n’est pas en ligne est celui d´ecrit dans [31], o` u le traitement s’effectue `a partir de la fin
du fichier. Un tel algorithme est appel´e, dans la litt´erature anglaise, offline.
Chapitre 1. Syst`emes de d´etection d’intrusions 42
F ::= A [ F [ F
1
∧ F
2
[ F
1
∨ F
2
[ F
Tab. 1.6 – Syntaxe de la premi`ere logique de LogWeaver.
1.5.1 LogWeaver
L’article sur LogWeaver [32] est divis´e en deux parties. Premi`erement, les auteurs
montrent comment on peut utiliser une logique temporelle classique pour effectuer de
la d´etection d’intrusions sur des fichiers d’audits. Ils montrent ensuite les faiblesses de
cette logique et en proposent une autre moins orthodoxe, mais qu’ils consid`erent comme
plus appropri´ee. Nous focuserons ici sur la premi`ere logique, car elle est plus proche de
celles que nous avons d´ej`a vues et elle nous permet de voir comment on peut effectuer
de la v´erification sur une logique du premier ordre.
Le mod`ele sur lequel travaille LogWeaver est une s´equence finie ou infinie d’enre-
gistrements, appel´e indistinctement log, ou trace. Un enregistrement est d´efini comme
´etant une fonction d’un ensemble d’´etiquettes vers un ensemble de valeurs, lesquelles
sont consid´er´ees comme ´etant des chaˆınes de caract`eres.
La syntaxe des formules utilis´ees dans la premi`ere logique abord´ee est pr´esent´ee `a la
table 1.6.
`
A premi`ere vue, il s’agit d’un sous-ensemble de LTL, que nous ´etudierons plus
en d´etails `a la section 2.1.1. Les op´erateurs U (jusqu’`a ce que) et ( (imm´ediatement
apr`es) ont ´et´e omis car, selon les auteurs, ces derniers ne se r´ev`elent pas d’une grande
utilit´e pour la d´etection d’intrusions. Le seul op´erateur temporel ayant ´et´e conserv´e est
donc l’op´erateur , signifiant n´ecessairement. Il est `a noter que l’op´erateur utilis´e ici
exprime un futur strict. La principale diff´erence entre cette logique et LTL se trouve au
niveau du type de la relation de satisfaction et de la s´emantique attribu´ee aux formules
atomiques A, aussi appel´ees patrons d’´ev´enements. Un exemple de patron d’´ev´enements
est {id=X, action="creat", object="/usr/spool/mail/root$"}. Ce patron filtre
tous les ´ev´enements dont la valeur du champ id est ´egale `a celle de la variable X, et
dont les valeurs des champs action et object sont respectivement ´egales `a "creat" et
"/usr/spool/mail/root$".
´
Etant donn´e une trace σ et une formule F, l’ensemble des ´el´ements satisfaisant F
est alors d´efini non-pas seulement comme ´etant un sous-ensemble d’enregistrements de
σ, mais comme un ensemble de couples (s, ρ), o` u s est un enregistrement de σ et ρ
est un environnement. Un environnement est une fonction attribuant des valeurs aux
Chapitre 1. Syst`emes de d´etection d’intrusions 43
variables se trouvant dans les patrons d’´ev´enements d’une formule. C’est exactement
cette notion d’environnement qui justifie l’emploi d’une logique du premier ordre. Ce
sont les environnements qui permettent de relier les divers enregistrements entre eux en
unifiant les valeurs de certains de leurs champs.
L’algorithme de v´erification utilis´e pour cette logique est semblable `a celui utilis´e
pour RUSSEL (section 1.2.1). On travaille cependant avec deux ensembles plutˆ ot que
trois, l’ensemble Cmp n’ayant aucun sens ici. Pour v´erifier une formule F, on initialise
donc l’ensemble Cur `a ¦F¦ et l’ensemble Nxt `a ∅. Ensuite, pour chaque enregistrement,
on traite chacune des formules de l’ensemble Cur. Ce traitement peut soit amener `a
ajouter d’autres formules dans l’ensemble Cur (dans le cas de formules de la forme
F
1
∧ F
2
, F
1
∨ F
2
, ou F), soit `a ajouter des formules dans l’ensemble Nxt (dans le
cas des formules de la forme F). Il est `a noter que dans le dernier cas, on utilise
l’´equivalence F ⇔ (F ∨ ( F, signifiant que formule F sera satisfaite dans le futur
si et seulement si elle sera satisfaite `a l’´etat suivant ou si, `a partir de l’´etat suivant, elle
sera satisfaite dans le futur. En plus de manipuler ces ensembles, il faut aussi ajouter
les structures de donn´ees n´ecessaires au chaˆınage des formules et `a la manipulation des
environnements. Le lecteur int´eress´e aux d´etails de cet algorithme est r´ef´er´e `a [32].
Les probl`emes reli´es `a cette logique se divisent en deux cat´egories. La premi`ere
cat´egorie de probl`emes concerne le traitement des ´ev´enements r´ep´et´es, c’est-`a-dire la
reconnaissance d’un nombre d´etermin´e d’´ev´enements semblables. En plus de ralentir
consid´erablement l’algorithme de v´erification en augmentant rapidement et de fa¸con
d´emesur´ee le nombre de formules `a v´erifier, le nombre d’alarmes lanc´ees est lui aussi
beaucoup trop grand. Ceci est du au fait que la reconnaissance d’une suite de n ´ev´e-
nements sur une trace en contenant m lance (
m
n
) alarmes, alors qu’en fait une seule
pourrait suffire.
La deuxi`eme cat´egorie de probl`emes concerne l’expressivit´e de la logique, qui est
jug´ee `a la fois trop et pas assez expressive. Elle est trop expressive car elle permet
la combinaison bool´eenne de formules de la forme F, qui sont jug´ees par les auteurs
comme ´etant rarement utiles en pratique. De plus, la pr´esence de n´egations est jug´ee
comme ´etant superflue dans la plupart des cas. Ces deux familles de formules, de plus,
contribuent chacune `a leur fa¸con `a la complication de l’algorithme de v´erification. Elle
n’est pas suffisamment expressive car elle ne permet pas de sp´ecifier naturellement des
propri´et´es de comptage (autrement qu’en ´ecrivant des formules de la forme F ∧ (F ∧
(F ∧ . . . ∧ F))), ni de parit´e. Les propri´et´es de parit´e sont celles o` u une action peut
annuler temporairement l’effet d’une autre, comme dans le cas de l’ouverture et de la
fermeture d’une session TCP.
Chapitre 1. Syst`emes de d´etection d’intrusions 44
Pour r´esoudre ces probl`emes, les auteurs sugg`erent d’utiliser une autre logique, moins
classique, inspir´ee de ETL [33]. Nous ne nous ´etendrons pas ici sur les d´etails de ETL,
mais nous nous contenterons de dire que cette derni`ere a la particularit´e d’offrir la
possibilit´e d’inclure des automates dans la d´efinition des formules. Une partie de la
s´emantique des formules est donc d´efinie par la notion d’acceptation d’une chaˆıne par
un automate. Cette solution hybride pr´esente des avantages au niveau de l’expressi-
vit´e, mais les sp´ecifications obtenues, comme le remarquent les auteurs, commencent `a
ressembler ´etrangement `a celles de STATL.
En r´esum´e, le travail de M. Roger et J. Goubault-Larrecq est une mine d’or d’un
point de vue th´eorique. L’article [32] comportent plusieurs r´esultats th´eoriques qui n’ont
pas ´et´e cit´es ici, mais qui sont tout de mˆeme tr`es int´eressants. De plus, il repr´esente un
cas complet d’´etude d’utilisation d’une logique temporelle classique du premier ordre
pour r´esoudre un probl`eme de v´erification en ligne. Les algorithmes utilis´es sont pr´e-
sent´es en d´etails et les r´esultats obtenus sont comment´es avec objectivit´e. Plusieurs
probl`emes importants reli´es `a l’utilisation d’une logique classique ont ´et´e relev´es, et une
solution int´eressante a ´et´e propos´ee pour r´esoudre ces probl`emes. Cependant, comme
nous l’avons d´ej` a remarqu´e, cette solution nous fait tendre tranquillement vers un lan-
gage `a tendance imp´erative.
1.5.2 Monid
Le syst`eme de v´erification en ligne Monid se pr´esente comme ´etant une alternative
`a LogWeaver. Ce syst`eme utilise une logique temporelle du premier ordre pass´ee et
future avec points fixes nomm´ee Eagle [34, 35]. Les auteurs affirment que Eagle est plus
expressive que le fragment de LTL utilis´e par les auteurs de LogWeaver en ce qu’elle
permet d’exprimer des contraintes temps-r´eel et des propri´et´es statistiques.
La syntaxe des sp´ecifications Eagle se trouve `a la table 1.7. Il s’agit d’une syntaxe
plutˆot concr`ete, puisqu’on y sp´ecifie plus que la syntaxe des formules. Une sp´ecification
S consiste en une partie de d´eclarations D et une partie o` u on d´efinit des observateurs O.
D est constitu´e de z´ero ou plus d´efinitions de r`egles R, et O de z´ero ou plus moniteurs M.
Les r`egles et les moniteurs sont nomm´es N. Le nommage des r`egles permet la d´efinition
de r`egles r´ecursives. Le domaine lexical T repr´esente les types, qui sont utilis´es lors de
la d´efinition des r`egles. Finalement, x
i
repr´esente une variable, et exp est une expression
qui s’´evalue soit `a vrai soit `a faux `a chacun des ´etats de la trace.
Les op´erateurs (,

, d´esignent respectivement l’´ev´enement suivant et l’´ev´enement
pr´ec´edent, alors que les op´erateurs de points fixes min et max permettent de d´efinir des
Chapitre 1. Syst`emes de d´etection d’intrusions 45
S ::= D O
D ::= R

O ::= M

R ::= ¦max[min¦ N(T
1
x
1
, . . . , T
n
x
n
) = F
M ::= mon N = F
T ::= Form [ primitive type
F ::= exp [ true [ false [ F [ F
1
∧ F
2
[ F
1
∨ F
2
[ F
1
→ F
2
[ (F [

F [ F
1
F
2
[ N(F
1
, . . . , F
n
) [ x
i
Tab. 1.7 – Syntaxe des sp´ecifications Eagle.
max Always(Form F) = F ∧ (Always(F)
min EvTimedLogout(string k, double t, double δ) = (time - t ≤ δ)
∧ ((action = logout ∧ userid = k) ∨ (EvTimedLogout(k,t,δ))
mon M = Always(action = login → EvTimedLogout(userid,time,100))
Fig. 1.19 – Exemple de sp´ecification Eagle.
formules r´ecursivement. L’op´erateur de concat´enation permet de d´efinir des s´equences
d’´ev´enements. Notons aussi que bien que Eagle utilise des variables dans la d´efinition de
ses formules, aucune notion d’environnement n’est utilis´ee pour d´efinir la s´emantique.
On utilise cependant une notion de substitution textuelle pour d´efinir la s´emantique
des formules param´etr´ees N(F
1
, . . . , F
n
).
`
A la figure 1.19, se trouve un exemple de sp´ecification Eagle. Comme d’habitude, on
peut d´efinir l’op´erateur Always, souvent not´e 2, `a l’aide de l’op´erateur de plus grand
point fixe et de l’op´erateur (. La d´efinition de la r`egle EvTimedLogout montre comment
on peut sp´ecifier qu’un ´ev´enement doit survenir au plus δ unit´es de temps apr`es un autre.
On proc`ede exactement de la mˆeme fa¸con que lorsque l’on d´efinit l’op´erateur `a l’aide
des op´erateurs de plus petit point fixe et (, sauf que l’on exige en plus que les temps
associ´es aux deux ´ev´enements ne soient pas s´epar´es de plus de δ unit´es de temps. Aucun
caract`ere sp´ecial n’est donc donn´e au temps dans Eagle.
L’algorithme de v´erification utilis´e par Eagle Flier, le logiciel implantant Eagle,
fonctionne `a l’aide d’une fonction eval qui, ´etant donn´e une formule F et un ´etat σ(i),
donne une nouvelle formule F

telle que σ, i [= F si et seulement si σ, i + 1 [= F

.
`
A
Chapitre 1. Syst`emes de d´etection d’intrusions 46
la fin de la trace, on calcule une fonction bool´eenne value(F) qui s’´evalue `a vrai si et
seulement si le dernier ´etat de σ satisfait F. Donc, pour une trace σ de longueur n et une
formule F, on a σ, 1 [= F ssi value(eval(. . . eval(eval(F, σ(1)), σ(2)) . . . , σ(n))) = vrai.
On remarque ici une diff´erence importante entre les hypoth`eses faites sur le mod`ele
utilis´e par LogWeaver et celui de Eagle : les traces v´erifi´ees par Eagle sont de longueur
finie, alors que celles sur lesquelles travaille LogWeaver sont d´efinies comme ´etant finies
ou infinies. Il est `a noter que cette diff´erence reste tout de mˆeme tr`es mince car, d’une
part, les r´esultats th´eoriques sur l’algorithme employ´e par LogWeaver demandent une
trace finie, et d’autre part, les auteurs de [35] citent une m´ethode, appel´ee specifying-
bad prefixes [36], permettant d’exprimer la formule `a v´erifier de telle sorte que celle-ci
devient tˆot ou tard vraie ou fausse, peu importe le reste de la trace. L’int´erˆet de cette
technique r´eside dans le fait qu’elle ´evite d’avoir `a v´erifier la satisfiabilit´e ´eventuelle
d’une formule, probl`eme qui est ind´ecidable dans le cas de Eagle dˆ u `a l’utilisation de
pr´edicats du premier ordre.
En r´esum´e, les travaux effectu´es dans le cadre du d´eveloppement de Eagle sont plus
pr`es de la pratique que ceux effectu´es pour LogWeaver. Les propri´et´es int´eressantes pour
la d´etection d’intrusions telles que le comptage ou les propri´et´es de parit´e s’expriment
beaucoup plus naturellement dans Eagle que dans le sous-ensemble de LTL consid´er´e
par les auteurs de LogWeaver ou encore la seconde logique propos´ee, inspir´ee de ETL.
Les algorithmes de v´erification utilis´es par Eagle sont simples, mais semblent mieux
adapt´es au cas o` u la trace d’´ev´enements consid´er´ee est de longueur finie. Finalement,
on trouve dans [35] toute une s´erie d’exemples de sc´enarios d’attaque allant des plus
classiques `a d’autres plus originaux pouvant s’exprimer dans Eagle.
1.5.3 Chronicles
Les deux syst`emes que nous venons de pr´esenter ont ´et´e construits sur des para-
digmes provenant de la th´eorie de la v´erification formelle de mod`eles. Ils utilisent des
logiques qui ont ´et´e historiquement d´evelopp´ees dans l’intention de v´erifier automati-
quement certaines propri´et´es de programmes. La v´erification par ´evaluation de mod`ele
Model Checking en informatique peut ˆetre utile `a plusieurs phases du d´eveloppement,
tant `a la conception (v´erification d’algorithmes), `a la programmation (v´erification de
code), qu’` a la phase de tests (validation de logiciels). Le syst`eme Eagle, en particulier, a
d’abord ´et´e d´evelopp´e pour ce type d’usage. L’avantage d’utiliser une logique commune
dans un tel cadre d’utilisation est qu’`a chaque phase du processus de d´eveloppement,
on peut v´erifier `a nouveau les mˆemes propri´et´es avec un minimum d’ajustement. La
v´erification par ´evaluation de mod`ele est tr`es bien adapt´e aux probl`emes bool´eens :
Chapitre 1. Syst`emes de d´etection d’intrusions 47
est-ce que, oui ou non, telle propri´et´e est satisfaite ?. Les probl`emes du genre : dans
quelle mesure cette propri´et´e est-elle satisfaite ? ou encore quelles sont toutes les fa¸cons
dont cette propri´et´e est viol´ee ? pr´esentent peu d’int´erˆet dans ce domaine et c’est sans
doute pourquoi les tentatives d’y appliquer les logiques y ayant ´et´e d´evelopp´ees peuvent
parfois sembler artificielles et tordues.
En intelligence artificielle, les probl`emes auxquels on s’attaque sont traditionnelle-
ment diff´erents. La nature des probl`emes abord´es est beaucoup plus vaste, et souvent
plutˆot ´eloign´ee de ceux g´en´eralement rencontr´es par un informaticien. Par exemple, on
pourra ˆetre int´eress´e `a analyser les battements cardiaques d’un ˆetre humain. Ici, on a
un exemple int´eressant o` u tout ce qui compte est la fr´equence des ´ev´enements, ceux-ci
´etant indistinctibles les uns des autres. On sera int´eress´e au nombre de battements dans
une minute, `a l’acc´el´eration du rythme, aux moments o` u de l´eg`eres anomalies semblent
survenir, etc. Dans un tel contexte, le besoin de logiques o` u le comptage et les intervalles
de temps sont ´elev´es au rang de primitives du langage se fait bien sentir, et c’est dans
un tel contexte que les logiques r´eifi´ees ont ´et´e d´evelopp´ees. Les logiques r´eifi´ees sont des
logiques du deuxi`eme ordre o` u les pr´edicats du deuxi`eme ordre servent essentiellement
`a exprimer les instants ou les intervalles de temps o` u les faits exprim´es par les pr´edicats
du premier ordre sont vrais.
Chronicles, introduit dans [37], est un langage bas´e sur les logiques r´eifi´ees permet-
tant de reconnaˆıtre des chroniques dans un flot d’´ev´enements. Il vient avec CRS (Chro-
nicles Recognition System) un v´erificateur qui peut fonctionner en ligne. Informellement,
une chronique est un ensemble d’´ev´enements reli´es entre eux par des contraintes tempo-
relles. Dans la litt´erature, les chroniques sont reli´ees au calcul des ´ev´enements pr´esent´e
plus haut.
La repr´esentation du temps dans Chronicles est discr`ete et il est donc vu comme une
suite ordonn´ee d’instants dont la r´esolution est assez fine pour les besoins de l’analyse.
Deux ´ev´enements diff´erents peuvent survenir au mˆeme instant, mais lorsque deux ou
plusieurs ´ev´enements identiques surviennent au mˆeme instant (selon la r´esolution choi-
sie), ceux-ci sont fusionn´es en un seul ´ev´enement. En d´etection d’intrusions, o` u plusieurs
´ev´enements identiques peuvent survenir en peu de temps, le choix de la r´esolution doit
donc ˆetre fait avec pr´ecautions.
L’environnement est d´ecrit par les attributs du domaine. Un attribut du domaine est
un tuple P(a
1
, . . . , a
n
) : v, o` u P est le nom de l’attribut, a
1
, . . . , a
n
ses arguments, et v
sa valeur. Certains attributs peuvent ne pas avoir de valeur. Ces derniers sont appel´es
messages. Finalement, les ´ev´enements correspondent `a des changements de valeurs des
attributs du domaine.
Chapitre 1. Syst`emes de d´etection d’intrusions 48
hold(P : v; (t
1
; t
2
))
event(P : (v
1
; v
2
); t)
event(P; t)
noevent(P; (t
1
; t
2
))
occurs((n
1
; n
2
); P; (t
1
; t
2
))
Tab. 1.8 – Pr´edicats de r´eification de Chronicles.
1. chronicle exemple1 {
2. event(e1,t1) ;
3. event(e2,t2) ;
4. event(e3,t3) ;
5.
6. t1<t2<t3
7. t3-t2 <= 4
8. }
Fig. 1.20 – Exemple de chronique.
Les pr´edicats de r´eification de Chronicles sont pr´esent´es `a la table 1.8. Le pr´edicat
hold(P : v; (t
1
; t
2
)) signifie que l’attribut P conserve la valeur v sur l’intervalle [t
1
, t
2
[.
Le pr´edicat event(P : (v
1
; v
2
); t) signifie que l’attribut P a pass´e de la valeur v
1
`a v
2
`a
l’instant t. Le pr´edicat event(P; t) signifie que le message P est survenu `a l’instant t. Le
pr´edicat noevent(P; (t
1
; t
2
)) signifie qu’aucun changement de valeur de l’attribut P n’est
survenu durant l’intervalle [t
1
, t
2
[. Finalement, le pr´edicat occurs((n
1
; n
2
); P; (t
1
; t
2
))
permet de compter. Il signifie que sur l’intervalle [t
1
, t2[, l’´ev´enement P est survenu de
n
1
`a n
2
fois.
Un mod`ele de chronique est constitu´e de cinq ´el´ements : i) un ensemble d’instants,
ii) un ensemble de contraintes temporelles sur ces instants, iii) un ensemble de pa-
trons d’´ev´enements qui repr´esentent les changements de l’environnement auxquels on
s’int´eresse iv) un ensemble d’assertions qui repr´esentent le contexte dans lequel les ´ev´e-
nements surviennent, et v) un ensemble d’actions externes `a prendre lorsqu’une instance
de chronique est reconnue.
Un exemple de mod`ele de chronique est pr´esent´e `a la figure 1.20. Il sera reconnu `a
chaque fois que les messages e
1
, e
2
et e
3
surviendront dans cet ordre et que, de plus, le
message e
3
ne doit pas survenir plus de 4 unit´es de temps apr`es e
2
.
L’algorithme de reconnaissance des chroniques fonctionne de fa¸con semblable `a
d’autres que nous avons d´ej` a vus. Au d´ebut, un mod`ele vide est cr´e´e.
`
A chaque fois
Chapitre 1. Syst`emes de d´etection d’intrusions 49
qu’un ´ev´enement satisfaisant les contraintes exprim´ees par un mod`ele de chronique sur-
vient, celui-ci est ajout´e `a l’instance de chronique en cours apr`es duplication de cette
derni`ere. La duplication sert `a s’assurer de reconnaˆıtre toutes les instances possible.
Certaines instances en cours de reconnaissance peuvent ˆetre ´elimin´ees lorsque des as-
sertions sont viol´ees ou que les contraintes temporelles ne peuvent plus ˆetre satisfaites.
Il est important, lors de la sp´ecification de chroniques, de s’assurer de sp´ecifier de telles
assertions ou contraintes temporelles. Autrement, et particuli`erement dans un mode de
fonctionnement en ligne, certaines instances peuvent rester ind´efiniment en m´emoire et
mˆeme, ´eventuellement, faire exploser celle-ci.
Un aspect important de Chronicles est que l’action `a prendre lors de la reconnais-
sance d’une chronique n’est pas n´ecessairement une simple action d’archivage externe. Il
peut aussi s’agir de l’´emission d’un nouvel ´ev´enement, qui peut alors ˆetre utilis´e soit par
une autre chronique en cours de reconnaissance, soit par d’autres instances de la mˆeme
chronique. Cette fonctionnalit´e donne `a Chronicles une certaine forme d’acquisition de
connaissance, celle-ci pouvant ˆetre repr´esent´ee par certains attributs du domaine dont
les valeurs sont tenues `a jour par le m´ecanisme mˆeme de reconnaissance de chroniques.
Chronicles n’a pas ´et´e con¸cu sp´ecialement en vue de faire de la d´etection d’intru-
sions.
`
A ses d´ebuts, il a ´et´e appliqu´e `a l’analyse de journaux d’alarmes d’´equipements
de t´el´ecommunications. Il a par la suite ´et´e appliqu´e `a d’autres domaines tels que l’ana-
lyse de circulation routi`ere et on lui a mˆeme trouv´e quelques applications en m´edecine.
Dans [38], on a finalement sugg´er´e une fa¸con de l’utiliser en d´etection d’intrusions.
Bien qu’il soit possible d’utiliser Chronicles pour repr´esenter des sc´enarios d’attaque,
l’utilisation propos´ee par les auteurs tend vers d’autres objectifs. Principalement, ils
proposent d’utiliser Chronicles comme outil d’analyse des journaux d’alarmes de sys-
t`emes de d´etection d’intrusions afin i) de permettre une d´etection plus pr´ecise, ii) de
r´eduire le nombre d’alarmes et iii) d’am´eliorer la s´emantique des alarmes.
L’utilisation de Chronicles peut permettre une d´etection plus pr´ecise. Plus pr´eci-
s´ement, elle peut aider `a diminuer le nombre de faux-positifs en invalidant certaines
alarmes. L’invalidation d’alarmes avec Chronicles peut se faire en sp´ecifiant certains
contextes dans lesquels certains comportement ne doivent pas ˆetre consid´er´es comme
dangereux. Par exemple, l’initialisation d’une vid´eo-conf´erence entre plusieurs utilisa-
teurs peut sous certains aspects ressembler `a un balayage de ports, mais ne doit tout
de mˆeme pas d´eclencher d’alarme. L’utilisation de Chronicles peut r´eduire le nombre
d’alarmes, principalement en utilisant le pr´edicat occurs. Certaines attaques, telles que
la propagation de vers informatiques, se caract´erisent par la r´ep´etition `a outrance de
comportements identiques, et peuvent d´eclencher un nombre abrutissant et inutile-
ment ´elev´e d’alarmes. Chronicles peut fusionner ces diff´erents ´ev´enements en un seul.
Chapitre 1. Syst`emes de d´etection d’intrusions 50
Chronicles peut am´eliorer la s´emantique des alarmes en combinant les diff´erents symp-
tˆomes d’une mˆeme attaque. Mieux encore, certaines attaques ne doivent ˆetre consid´er´ees
comme r´eussies que si un ensemble bien d´etermin´e d’actions ont ´et´e effectu´ees. Certains
syst`emes de d´etection d’intrusions lanceront des alarmes `a chacune de ces actions, don-
nant ainsi l’impression que de nombreuses attaques ont eu lieu alors qu’il s’agit en fait
d’une seule. L’utilisation de Chronicles permet de ne d´eclencher qu’une seule alarme
rendant ainsi mieux compte du fait qu’une seule attaque a eu lieu.
Les auteurs de [38], en plus de donner plusieurs exemples o` u Chronicles peut s’av´erer
utile dans l’analyse de journaux d’alarme, montrent comment ce langage peut ˆetre
utilis´e de paire avec M2D2 [10] pour corr´eler les alarmes avec le contexte. M2D2 est un
mod`ele formel incluant celui de NetSTAT [20]. Il permet de repr´esenter non-seulement
la topologie physique du r´eseau, mais aussi toute sa configuration, les logiciels install´es
sur chacune des machines, les vuln´erabilit´es de ceux-ci de mˆeme que leurs effets, les
logiciels de s´ecurit´e install´es sur chacune des composantes, les attaques d´etectables par
chacun des syst`emes de d´etection d’intrusions, et bien encore. La fa¸con dont les alarmes
sont repr´esent´ees dans M2D2 sont de plus compatibles avec IDWG [39], un format
d’´echange d’alarmes standardis´e mis au point `a l’IETF. L’utilisation d’un tel mod`ele
permet, en plus de corr´eler diff´erentes alarmes entre elles, de tenir compte dans l’analyse
des caract´eristiques du syst`eme attaqu´e et mˆeme du syst`eme de d´etection d’intrusions
ayant signal´e l’attaque.
En r´esum´e, Chronicles est un langage de surveillance bas´e sur une logique r´eifi´ee
dont la s´emantique semble mieux adapt´ee `a la d´etection d’intrusions que les logiques
traditionnellement utilis´ees en Model Checking. L’ordonnancement des diff´erents ´ev´e-
nements est exprim´e par un ensemble de contraintes sur les instants leur ´etant associ´es
plutˆot que par des op´erateurs d´edi´es. Les op´erateurs sp´ecifiques `a Chronicles mettent
plutˆot le focus sur les diff´erents changements pouvant survenir pendant le processus
de reconnaissance d’une chronique. Un des ces op´erateurs permet mˆeme de compter
de fa¸con tr`es naturelle le nombre d’´ev´enements semblables. Chronicles a de plus ´et´e
utilis´e dans de nombreux domaines d’application `a premi`ere vue assez diff´erents les uns
des autres. Un des dangers reli´es `a l’utilisation de Chronicles est l’explosion de l’utili-
sation de la m´emoire lorsque les chroniques ne sont pas sp´ecifi´ees consciencieusement.
Finalement, des travaux ayant ´et´e effectu´es tendent `a d´emontrer que Chronicles peut
s’av´erer utile en corr´elation d’alarmes. La notion de corr´elation d’alarmes employ´ee par
les auteurs de [38] est cependant l´eg`erement diff´erente de celle utilis´ee par les auteurs
de [29]. Les premiers utilisent le mot corr´elation dans un sens plutˆ ot g´en´eral, d´esignant
par exemples diff´erentes alarmes symptomatiques d’un mˆeme ph´enom`ene, alors que les
deuxi`emes parlent plutˆot d’une corr´elation logique, voire mˆeme causale. Le v´erificateur
de chroniques CRS permet de g´en´erer des ´ev´enements en cours d’ex´ecution. Cette fonc-
Chapitre 1. Syst`emes de d´etection d’intrusions 51
tionnalit´e, jointe `a l’utilisation du mod`ele M2D2, permet de bien mettre les attaques
signal´ees en contexte.
1.6 Conclusion
Dans ce chapitre, nous avons ´etudi´e 13 syst`emes de d´etection d’intrusions diff´erents,
dont 12 sont `a base de sc´enarios. Les langages utilis´es pour exprimer les sc´enarios re-
posent sur 5 cat´egories de paradigmes : les langages sp´ecifiques au domaine, les langages
imp´eratifs, les syst`emes de transition, les syst`emes experts, et les logiques temporelles.
Nous avons identifi´e, pour chacun de ces langages, des avantages et des inconv´enients
qui leur sont propres. Nous donnons `a la table 1.9 la liste des dix caract´eristiques, parmi
celles que nous avons relev´ees, que nous jugeons les plus importantes pour un syst`eme de
d´etection d’intrusions `a base de sc´enarios. Il est `a noter que les deux derni`eres propri´e-
t´es ne concernent pas directement le langage, mais l’algorithme de v´erification utilis´e
pour le mettre en oeuvre. Cependant, nous avons jug´e bon de les mentionner car un
bon IDS ne doit pas seulement fournir un langage de signatures suffisamment expressif,
il doit aussi ˆetre capable de fonctionner `a un bon rythme. Autrement dit, l’expressivit´e
ne doit pas coˆ uter trop cher en complexit´e algorithmique.
`
A la table 1.10, nous indi-
quons, pour chacun des IDS ´etudi´es, quelles caract´eristiques il comporte. Nous n’avons
pas mentionn´e si le langage LAMBDA comporte les caract´eristiques 9 et 10 car nous
n’avons r´eussi `a mettre la main sur aucune documentation au sujet d’une ´eventuelle
implantation de LAMBDA.
La revue que nous avons faite mettait cependant l’accent sur les langages et les
paradigmes utilis´es pour exprimer les signatures dans un contexte de d´etection. D’autres
langages, comme ADeLe [2], NASL [40] et CASL [41] mettent plutˆ ot l’accent sur le cˆot´e
attaquant. ADeLe a ´et´e d´evelopp´e en parall`ele avec LAMBDA dans le but de d´evelopper
une base donn´ees d’attaques. Une des pr´eoccupations des auteurs ´etait de concevoir un
langage assez g´en´eral pour pouvoir repr´esenter, comme LAMBDA, les attaques `a la fois
du point de vue de l’attaquant et de l’attaqu´e, de mˆeme que de permettre une corr´elation
logique entre les diff´erentes attaques et de sp´ecifier comment r´eagir `a ces attaques. NASL
est un langage de scripts d´evelopp´e pour l’identificateur de failles de s´ecurit´e Nessus. Il
fournit des primitives permettant d’envoyer des paquets forg´es `a la main sur le r´eseau
et de recevoir d’autres paquets en vue d’effectuer des tests bien pr´ecis. CASL a ´et´e
d´evelopp´e avec des objectifs similaires et offre des fonctionnalit´es semblables, mais a
´et´e con¸cu avec l’objectif de r´ealiser des attaques plutˆ ot que de simplement tester les
failles.
Chapitre 1. Syst`emes de d´etection d’intrusions 52
1) sc´enarios `a plusieurs ´ev´enements Les diff´erents exemples que nous avons ´etudi´e
nous convainquent que le fait de pouvoir exprimer des sc´enarios comportant plu-
sieurs ´ev´enements est n´ecessaire pour effectuer une d´etection d’intrusions pr´ecise
et compl`ete.
2) non-occurrence d’´ev´enements Il arrive parfois que le fait de ne pas observer un
´ev´enement soit r´ev´elateur d’information.
3) contraintes temps-r´eel On doit ˆetre capable de sp´ecifier un d´elai entre les diff´e-
rents ´ev´enements d’un sc´enario.
4) comptage Dans certains cas, c’est la r´ep´etition d’un ´ev´enement ou d’un sc´enario
donn´e qui est porteur d’information.
5) acquisition de connaissance Le fait de pouvoir extraire et conserver de fa¸con dy-
namique de l’information des ´ev´enements observ´es aide `a r´eduire les faux positifs.
6) propri´et´es de parit´e Certaines conditions ne sont valides qu’entre deux ´ev´ene-
ments donn´es.
7) gestion des attributs absents ou multiples Le langage doit prendre automati-
quement en compte le fait que certains attributs peuvent ˆetre optionnels pour
certains ´ev´enements. Aussi, il est possible qu’un attribut ait une liste de valeurs.
8) approche d´eclarative Un paradigme d´eclaratif permet, en plus de faciliter la
maintenance de la base de signatures, d’effectuer un calcul de corr´elation entre
les diff´erents sc´enarios. Ce calcul n’est cependant possible que si le langage est
purement d´eclaratif, au sens de la d´efinition 1.1.
9) fonctionnement en ligne Il doit ˆetre possible d’´elaborer un algorithme de v´erifi-
cation capable de traiter les ´ev´enements dans l’ordre o` u ils surviennent, et de les
effacer automatiquement de la m´emoire d`es qu’ils sont trait´es.
10) utilisation born´ee de la m´emoire Il doit ˆetre possible d’´elaborer un algorithme
de v´erification capable de fonctionner avec une quantit´e fixe de m´emoire qui n’aug-
mente pas avec le nombre d’´ev´enements.
Tab. 1.9 – Dix propri´et´es souhaitables d’un IDS.
Chapitre 1. Syst`emes de d´etection d’intrusions 53
nom 1 2 3 4 5 6 7 8 9 10
Snort N N N N O O N O O O
NeVO O N O N O N N O O O
ASAX O N O O O O O N N N
Bro O N O O O O N N O O
STAT O O O O O O N N O N
IDIOT O N O O O O N N O N
BSML O O O O N N N N O O
P-BEST O N N N O O N N O N
LAMBDA O O O N O O N O - -
LogWeaver O O O N N N N O O N
Monid O O O O N N N O O N
Chronicles O O O O N N N O O N
Tab. 1.10 – Tableau r´ecapitulatif des IDS.
Une approche dont nous n’avons pas parl´e est celle de [42], bas´ee sur un paradigme
de grammaires. Les auteurs de cet article proposent un formalisme pour repr´esenter les
attaques comprenant entre autres des notions de filtre, de temps-r´eel, et de s´equence-
ment. Ce formalisme vient avec un algorithme de v´erification `a base de tableaux qui est
prouv´e complet et coh´erent. On trouve aussi dans cet article une discussion int´eressante
au sujet des probl`emes pratiques d´ecoulant de la compl´etude des algorithmes de v´erifi-
cation de signatures dans le cas des langages d´eclaratifs. Principalement, on soul`eve le
fait que la compl´etude, bien qu’int´eressante d’un point de vue th´eorique, engendre sou-
vent des probl`emes de complexit´e algorithmique et de surcharge d’alarmes. La m´ethode
propos´ee par les auteurs permet de r´egler l’algorithme de v´erification en d´efinissant une
relation d’´equivalence sur les alarmes de fa¸con `a r´eduire le nombre d’alarmes tout en
conservant celles qui sont consid´er´ees comme ´etant les plus significatives. Le syst`eme
ARMD [43], mis au point pour le langage MuSigs, bas´e sur l’alg`ebre relationnelle, offre
lui aussi la possibilit´e de r´egler l’algorithme de v´erification selon les besoins particuliers
de l’utilisateur.
Plusieurs approches issues de techniques d’intelligence artificielle ont aussi ´et´e propo-
s´ees pour attaquer le probl`eme de la d´etection d’intrusions. Dans [44], on propose une
m´ethode utilisant les algorithmes g´en´etiques pour apprendre, `a partir d’un ensemble
d’entraˆınement, `a reconnaˆıtre les patrons d’attaque. Cette m´ethode, bien que compor-
tant une phase d’apprentissage, pr´esente cependant deux diff´erences importantes avec
les m´ethodes bas´ees sur une d´etection d’anomalies (m´ethodes statistiques). Premi`ere-
ment, l’ensemble d’entraˆınement fourni `a l’algorithme doit ˆetre ´etiquet´e. Alors que les
m´ethodes bas´ees sur une d´etection d’anomalies ne prennent en entr´ee que des fichiers
Chapitre 1. Syst`emes de d´etection d’intrusions 54
d’audit, la m´ethode propos´ee a besoin, en plus, de savoir o` u se trouvent les attaques dans
ce fichier. Deuxi`emement, le r´esultat de la phase d’apprentissage ne donne pas un profil
qui doit ˆetre consid´er´e comme normal, mais un ensemble de signatures qui peut par la
suite ˆetre utilis´e par un algorithme de reconnaissance de sc´enarios. Dans [45] et [46], on
propose d’autres m´ethodes bas´ees sur la programmation g´en´etique. La programmation
g´en´etique peut ˆetre vue comme un cas particulier des algorithmes g´en´etiques o` u les
individus participant aux croisements sont des programmes, et les gˆenes sont des bouts
de code. Encore une fois, ces approches d´ependent de la disponibilit´e de fichiers d’au-
dits ´etiquet´es pour la phase d’apprentissage. Cette contrainte n’est pas des moindres
car, depuis les fichiers d’´evaluation cr´e´es par le laboratoire Lincoln du MIT en 1998 et
1999 [47, 48], peu d’autres fichiers d’audit ou de traces de trafic ont ´et´e fournis `a la
communaut´e pour permettre de tels travaux.
Chapitre 2
Logiques temporelles
Dans Le Bourgeois Gentilhomme, de Moli`ere, Monsieur Jourdain r´epond au maˆıtre
de philosophie qui lui propose de lui enseigner les trois op´erations de l’esprit : Cette
logique-l`a ne me revient point. Apprenons autre chose qui soit plus joli. Les int´erˆets
de Moli`ere, `a cette ´epoque, ´etaient probablement bien loin de ceux qui nous occupent
aujourd’hui. Cependant, il semblerait qu’il avait d´ej` a compris une v´erit´e fondamentale :
il existe plusieurs logiques. D’abord, qu’est-ce qu’une logique ? L’encyclop´edie Hachette
Multim´edia, sous l’onglet logique, nous donne un article qui commence par ces mots :
Un raisonnement est une activit´e de la pens´ee qui `a partir de certains
´etats de connaissance pris comme pr´emisses ou hypoth`eses permet d’arriver
`a un autre ´etat de connaissance obtenu dans la conclusion du raisonnement.
´
Etrangement, il faut attendre la seconde phrase pour retrouver le mot logique, et cette
phrase ne fait plus du tout r´ef´erence aux notions de raisonnement et de connaissance.
En allant sous l’onglet logique formelle, les r´esultats commencent `a ˆetre un peu plus
satisfaisants :
Branche maˆıtresse de la logique, la logique formelle n’´etudie la validit´e
des raisonnements qu’en vertu de leur forme, sans s’int´eresser `a leur contenu.
La logique semble ˆetre ici per¸cue comme une science, dont une des branches serait la
logique formelle. Si on d´efinit la logique comme une science, il semble alors difficile d’ad-
mettre qu’il puisse exister plusieurs logiques. En effet, on ne parle jamais de la physique
de Untel, ou de la biologie de monsieur Machin. Il y aurait alors, vraisemblablement,
logique et Logique. La Logique serait alors la science qui ´etudie les logiques, et il nous
resterait toujours `a trouver une d´efinition pour le mot logique avec un petit ’l’.
´
Etrange-
ment, d´ependamment du domaine dans lequel on se trouve, la d´efinition du mot logique
semble toujours implicite, comme si on avait peur de s’y mouiller, et chacun pr´esente
sa logique de la fa¸con qui lui convient.
Chapitre 2. Logiques temporelles 56
Mˆeme au sein d’un domaine comme l’informatique, la d´efinition semble diff´erente d´e-
pendamment de la branche qui nous int´eresse. Les deux domaines o` u l’int´erˆet semble le
plus marqu´e pour les logiques sont l’intelligence artificielle et la v´erification formelle. En
v´erification formelle, une logique est per¸cue comme un langage permettant d’exprimer
certaines propri´et´es d’un programme ou d’un autre objet abstrait. En intelligence arti-
ficielle, o` u on s’int´eresse davantage aux aspects d´eductifs et inductifs, la multiplication
des logiques semble un probl`eme moins important et lorsque l’on lit, par exemple, Mc-
Dermott [49], Allen [50], ou Bacchus [51], les formalismes utilis´es sont beaucoup moins
uniformes que celles que l’on rencontre en lisant Pnueli [52], Kozen [53], Wolper [33],
Emerson et Halpern [54, 55], ou Henzinger [56], qui eux s’int´eressent `a la v´erification
formelle.
Le pr´esent travail se situant dans un contexte de v´erification formelle, le formalisme
que nous allons employer sera celui de ces derniers auteurs. En v´erification formelle,
une logique est per¸cue comme un triplet 'M, L, [=`, o` u M est l’objet du discours, aussi
appel´e mod`ele, L est le langage du discours, et [= est la s´emantique du discours, c’est-`a-
dire un ensemble de r`egles permettant de d´ecider, ´etant donn´e φ un ´el´ement du langage
et m une instance de mod`ele, si l’affirmation faite par φ est vraie `a propos de m. En
termes ensemblistes, M et L sont des ensembles, et [= est un sous-ensemble de M L.
G´en´eralement, l’ensemble L est g´en´er´e par un ensemble de r`egles r´ecursives que l’on
appelle la syntaxe du langage. Souvent, quand on pense `a une logique en particulier, on
pense d’abord `a sa syntaxe. Cependant, il ne faut pas n´egliger l’importance du choix
du mod`ele. Entre autres, si on veut comparer deux logiques en termes d’expressivit´e,
on demandera que celles-ci s’appliquent au mˆeme mod`ele. Une logique L
1
est dite aussi
expressive qu’une logique L
2
si, pour chaque formule φ
2
de L
2
, il existe une formule φ
1
de
L
1
telle que pour tous les ´el´ements m de M, m [= φ
1
si et seulement si m [= φ
2
. Elle est
dite plus expressive que L
2
si il elle est aussi expressive que L
2
et qu’il existe une formule
φ
1
de L
1
telle qu’il n’existe pas de formule φ
2
de L
2
telle que pour tous les ´el´ements m
de M, m [= φ
1
si et seulement si m [= φ
2
. Une logique est donc plus expressive si elle
permet de discerner avec plus de finesse les ´el´ements du mod`ele. Ceci implique donc,
entre autres, que si deux logiques ne sont pas d´efinies `a partir du mˆeme mod`ele, alors
il est par d´efinition impossible de comparer leur expressivit´e. Notons au passage qu’il
se peut fort bien que deux logiques ne soient pas comparables en expressivit´e, mˆeme si
elles sont d´efinies `a partir du mˆeme mod`ele.
La pr´esentation des logiques temporelles que nous ferons dans ce chapitre sera donc
faite d’abord en fonction des mod`eles utilis´es, puis en fonction des diff´erentes syntaxes
et s´emantiques. Les principaux mod`eles utilis´es pour les logiques temporelles sont pr´e-
sent´es `a la table 2.1. La premi`ere ligne, ainsi que la quatri`eme, sont les mod`eles statiques
de base, c’est-`a-dire intemporels. La logique propositionnelle, telle quelle, ne comprend
Chapitre 2. Logiques temporelles 57
Famille de logiques Mod`ele
Logique propositionnelle I ∈ 2
P
Logiques lin´eaires propositionelles σ : N → 2
P
Logiques temporis´ee propositionnelles σ : N → 2
P
T
Logique du premier ordre I ∈ ¦P → ¦X → V ¦¦
Logiques lin´eaires du premier ordre σ : N → ¦P → ¦X → V ¦¦
Logiques temporis´ees du premier ordre σ : N → ¦P → ¦X → V ¦¦ T
Logiques r´eifi´ees σ : T → ¦P → ¦X → V ¦¦
Tab. 2.1 – Familles de logiques temporelles et leur mod`ele.
aucune notion de temps. On suppose qu’il existe un nombre fini de constantes pro-
positionnelles, regroup´ees dans un ensemble P qui sont toutes soit vraies soit fausses.
L’attribution du caract`ere de v´erit´e `a ces constantes est ce qu’on appelle une interpr´e-
tation, ou encore une valuation, et l’ensemble de ces interpr´etations constitue le mod`ele
de la logique propositionnelle. Dans le cas de la logique du premier ordre, l’ensemble
primitif P n’est plus un ensemble de constantes propositionnelles, mais un ensemble de
pr´edicats, c’est-` a-dire un ensemble d’objets de la forme p(x
1
, . . . , x
n
). Une interpr´eta-
tion sera alors vue comme un ensemble de fa¸cons d’attribuer des valeurs aux variables
x
1
, . . . , x
n
, lesquelles valeurs seront choisies dans un ensemble V .
Vient alors la question de la temporisation de ces mod`eles. Dans le cas du premier
ordre, une avenue possible est de consid´erer que tous les pr´edicats sont de la forme
p(t, x
1
, . . . , x
n
). Autrement dit, chaque attribution de valeurs aux variables d’un pr´edicat
est associ´ee `a un temps. Cette strat´egie est celle qui est parfois utilis´ee dans les bases
de donn´ees. Les r`egles permettant de manipuler de tels objets ne sont cependant pas
des plus nettes, et d’autres fa¸con de mod´eliser le temps ont ´et´e sugg´er´ees. Une premi`ere
fa¸con, la plus couramment utilis´ee, est de dire que les mod`eles que nous consid´erions
comme statiques ´evoluent de fa¸con discr`ete dans le temps et que celui-ci s’´ecoule `a
intervalles r´eguliers t
0
, t
1
, t
2
, . . ..
`
A chaque instant t
n
on retrouve donc une nouvelle
interpr´etation. Le terme logique temporelle r´ef`ere habituellement aux logiques utilisant
ce type de mod`ele. Un peu plus tard, on a ressenti le besoin de tenir compte du fait
que le temps ne s’´ecoulait peut-ˆetre pas `a intervalles r´eguliers. On a alors ajout´e, `a
chaque instant t
n
, un temps auquel le changement de valuation s’effectue. Ces logiques
sont habituellement d´esign´ees sous le vocable de logiques temporis´ees (timed temporal
logics). Finalement, lorsque les changements s’effectuent de fa¸con possiblement continue
dans le temps, la notion d’instant est supprim´ee, `a chaque point de la ligne du temps
se trouve une nouvelle interpr´etation. Ce mod`ele est g´en´eralement celui qui est sous-
entendu lors de la d´efinition de logiques r´eifi´ees, qui ne seront pas trait´ees ici. Une
excellente revue des logiques r´eifi´ees se trouve cependant dans [57]. Dans les sections
Chapitre 2. Logiques temporelles 58
qui suivent, nous traitons d’abord les logiques temporelles, puis les logiques temporis´ees.
2.1 Logiques temporelles
Toutes les logiques temporelles que nous pr´esentons dans cette section sont des
logiques dites lin´eaires, qui se d´efinissent par opposition aux logiques dites arbores-
centes, telles que CTL, CTL

[58], ou le µ-calcul modal [53]. La diff´erence entre une
logique lin´eaire et une logique arborescente se situe d’abord au niveau du mod`ele.
´
Etant
donn´e l’ensemble des ex´ecutions possibles d’un programme, une logique lin´eaire permet
d’exprimer les propri´et´es de chacune de ces ex´ecutions, prises s´epar´ement, alors qu’une
logique arborescente permet de tenir compte des liens entre ces diverses ex´ecutions. Prin-
cipalement, une logique arborescente permet d’exprimer la propri´et´e `a partir d’un cer-
tain moment, il sera possible d’aller vers un chemin d’ex´ecution ayant la propri´et´e. . . .
La pertinence de telles propri´et´es a fait l’objet d’une guerre de clochers pendant un
certain temps [55], et il semblerait que le succ`es technologique de l’outil de v´erification
SPIN [59] ait fait pencher la balance du cˆot´e des logiques lin´eaires. Peu importe, la
raison pour laquelle les logiques arborescentes ne sont pas pr´esent´ees ici est qu’´etant
donn´e que, dans le contexte de notre travail, nous ne consid´erons qu’un seul chemin
d’ex´ecution (celui en cours), la notion d’arborescence ne pr´esente aucun int´erˆet pour
nous.
2.1.1 Logique temporelle lin´eaire
φ ::= p [ φ [ φ
1
∨ φ
2
[ (φ [ φ
1 U
φ
2
Tab. 2.2 – Syntaxe de LTL.
De toutes les logiques pr´esent´ees dans ce chapitre, la logique temporelle lin´eaire est
celle qui historiquement est apparue en premier [60, 52]. La majorit´e des autres logiques
que nous pr´esentons dans ce chapitre sont des variantes de celles-ci ou s’y r´ef`erent. Le
mod`ele sur lequel LTL est d´efinie, comme toutes les autres logiques pr´esent´ees dans cette
section, est celui de la deuxi`eme ligne de la table 2.1, c’est-`a-dire une s´equence infinie
d’´etats, aussi appel´ee trace, que l’on note σ. Les ´etats de la trace sont des ensembles de
constantes propositionnelles. Par σ(i), on d´enote le i
eme
´etat de σ.
Chapitre 2. Logiques temporelles 59
σ(i) [= p ssi p ∈ σ(i)
σ(i) [= φ ssi σ(i) [= φ
σ(i) [= φ
1
∨ φ
2
ssi σ(i) [= φ
1
ou σ(i) [= φ
2
σ(i) [= (φ ssi σ(i + 1) [= φ
σ(i) [= φ
1 U
φ
2
ssi ∃k ≥ i.σ(k) [= φ
2
et ∀i ≤ j < k.σ(j) [= φ
1
Tab. 2.3 – S´emantique de LTL.
La syntaxe de LTL est donn´ee `a la table 2.2. Les formules de LTL sont les mˆemes
que celles du calcul propositionnel, auxquelles on ajoute les op´erateurs temporels (
et
U
. Il s’agit d’op´erateurs temporels futurs, au sens o` u ils permettent d’exprimer
des propri´et´es concernant les ´etats `a venir. L’op´erateur ( est l’op´erateur prochain
permettant d’exprimer une propri´et´e du prochain ´etat, et l’op´erateur
U
est l’op´erateur
jusqu’`a ce que, permettant d’exprimer qu’une propri´et´e qui doit ˆetre respect´ee jusqu’` a
ce qu’une autre propri´et´e le soit.
`
A la table 2.3, se trouve la s´emantique formelle de LTL. La formule ´el´ementaire p
est satisfaite par un ´etat σ(i) si et seulement si celui-ci contient p. La formule φ est
satisfaite par un ´etat σ(i) si et seulement si celui-ci ne satisfait pas φ. La formule φ
1
∨φ
2
est satisfaite par un ´etat σ(i) si et seulement si celui-ci satisfait φ
1
ou φ
2
. La formule
(φ est satisfaite par un ´etat σ(i) si et seulement si son successeur imm´ediat σ(i + 1)
satisfait φ. Finalement, la formule φ
1 U
φ
2
est satisfaite un ´etat σ(i) si et seulement si
il a un successeur σ(k) (pas n´ecessairement imm´ediat) satisfaisant φ
2
et dont tous les
´etats σ(j) entre σ(i) et σ(k) satisfont φ
1
.
φ
def
= vrai
U
φ
φ
def
= φ
φ
1
U φ
2
def
= (φ
1 U
φ
2
) ∨ φ
1
Tab. 2.4 – Op´erateurs d´efinis de LTL.
Outre les op´erateurs ∧, →, et ↔, que l’on peut d´efinir comme d’habitude `a l’aide des
op´erateurs ∨ et , la logique temporelle lin´eaire comporte d’autres op´erateurs d´efinis,
dont la d´efinition se trouve `a la table 2.4. Le premier op´erateur, φ, se lit n´ecessairement,
φ se produira. Notons au passage qu’en anglais, cet op´erateur se lit eventually. Le lecteur
francophone doit donc faire attention, ici, `a la confusion linguistique entre le mot fran¸ cais
Chapitre 2. Logiques temporelles 60
lire i lire i
si i < 0 alors si i < 0 alors
i := −i i := −i
lire j lire j
k := i + j k := i + j
Fig. 2.1 – Exemples de programmes.
´eventuellement et le mot anglais eventually. En anglais, si quelque chose se produit
eventually, nous sommes certains que cela finira par arriver, alors qu’en fran¸cais, le mot
´eventuellement laisse place `a l’incertitude, et c’est pourquoi nous traduisons eventually
par n´ecessairement. L’op´erateur φ, quand `a lui, doit se lire toujours φ. Il est d´efini
comme il est faux de dire que φ sera fausse. Finalement, l’op´erateur φ
1 U
φ
2
est le faible
jusqu’`a ce que, qui permet que φ
2
ne soit jamais satisfaite.
La logique temporelle lin´eaire a ´et´e con¸ cue pour permettre la v´erification statique
de propri´et´es de programmes. Par exemple, si v est une variable utilis´ee dans un pro-
gramme, les constantes propositionnelles write(v) et read(v) peuvent repr´esenter l’acc`es
en ´ecriture et en lecture de cette variable. Alors, la formule read(v)
U
write(v) signifie
que la variable v ne doit pas ˆetre utilis´ee tant qu’elle n’a pas ´et´e initialis´ee. On utilise
l’op´erateur
U
plutˆ ot que
U
car si la variable n’est jamais lue, alors il n’est nullement
besoin qu’elle soit initialis´ee. Consid´erons, par exemple, les deux programmes montr´es
`a la figure 2.1, o` u l’indentation est utilis´ee pour d´elimiter les blocs d’instructions. Ces
deux programmes comportent chacun deux chemins d’ex´ecution, d´ependamment de la
valeur i fournie par l’usager. Le premier ´etat de chacun de ces quatre chemins respecte la
propri´et´e read(i)
U
write(i), alors que le premier ´etat d’un des chemins du programme
de gauche ne respecte pas la propri´et´e read(j)
U
write(j).
2.1.2 Logique temporelle lin´eaire pass´ee
φ ::= p [ φ [ φ
1
∨ φ
2
[ (φ [ φ
1 U
φ
2
[

φ [ φ
1 S
φ
2
Tab. 2.5 – Syntaxe de P-LTL.
Les op´erateurs temporels de LTL, comme nous l’avons d´ej` a dit, sont des op´erateurs
Chapitre 2. Logiques temporelles 61
σ(i) [=

φ ssi i > 0 et σ(i −1) [= φ
σ(i) [= φ
1 S
φ
2
ssi ∃0 ≤ k ≤ i.σ(k) [= φ
2
et ∀i ≥ j > k.σ(j) [= φ
1
Tab. 2.6 – S´emantique des op´erateurs particuliers `a P-LTL.
temporels futurs, au sens o` u leur s´emantique ne r´ef`ere qu’` a des ´etats se trouvant apr`es
l’´etat consid´er´e. Il est alors naturel de se demander s’il serait possible d’augmenter
l’expressivit´e de LTL en lui ajoutant des op´erateurs faisant r´ef´erence au pass´e. La logique
obtenue en ajoutant les ´equivalents pass´es de
U
et ( `a LTL s’appelle P-LTL (Past-
LTL).
La syntaxe de P-LTL est donn´ee `a la table 2.5. Il s’agit de la mˆeme syntaxe que
pour LTL, `a laquelle on a ajout´e des op´erateurs temporels pass´es
S
et

. L’op´erateur
S
doit se lire depuis, et l’op´erateur

doit se lire juste avant.
La s´emantique de ces op´erateurs est donn´ee `a la table 2.6. La formule φ
1 S
φ
2
est
satisfaite par un ´etat σ(i) si et seulement si celui-ci est pr´ec´ed´e d’un ´etat σ(k) satisfaisant
φ
2
tel que tous les ´etats σ(j) entre σ(k) et σ(i) satisfont φ
1
. La formule

φ, quand
`a elle, est satisfaite par un ´etat σ(i) si et seulement si il dispose d’un pr´ed´ecesseur
imm´ediat et que celui-ci satisfait φ.
φ
def
= vrai
S
φ
φ
def
= φ
Tab. 2.7 – Op´erateurs d´efinis de P-LTL.
Comme dans le cas de LTL, il est possible de d´efinir de nouveaux op´erateurs `a l’aide
de ces op´erateurs. Quelques exemples de ces op´erateurs sont donn´es `a la table 2.7. Les
op´erateurs et sont les ´equivalents pass´es de et . La formule φ est satisfaite par
un ´etat σ(i) si et seulement si celui-ci est pr´ec´ed´e d’un ´etat satisfaisant φ, et la formule
φ est satisfaite un ´etat σ(i) si et seulement si tous ses pr´ed´ecesseurs satisfont φ.
Pour reprendre l’exemple que nous d´ej`a ´etudi´e, la formule (read(v) → write(v))
signifie alors que si une variable v est lue, alors avant cela, elle a ´et´e initialis´ee. Cette
formule est satisfaite, pour une variable v et une trace σ donn´ees, par les mˆemes ´etats
que la formule read(v)
U
write(v). En effet, cette formule signifie que l’on ne doit pas
Chapitre 2. Logiques temporelles 62
lire la variable v avant de l’avoir initialis´ee. Ceci nous am`ene alors `a douter du fait que
l’ajout d’op´erateurs pass´es `a LTL a vraiment augment´e son expressivit´e.
Pour r´epondre `a cette question, nous devons d’abord nous demander de quelle ex-
pressivit´e on parle. En effet, dans les exemples ´etudi´es jusqu’` a maintenant, nous n’avons
consid´er´e que l’´etat initial des chemins d’ex´ecution. En effet, dans plusieurs cas d’ap-
plication, il est sous-entendu qu’un programme donn´e satisfait une propri´et´e si son ´etat
initial la satisfait. La relation d’´equivalence entre des formules obtenue en ne consid´e-
rant que l’´etat initial est diff´erente de celle obtenue si on regarde la trace en entier. On
distingue donc deux relations d’´equivalence distinctes :
D´efinition 2.1 (
´
Equivalence de formules) Deux formules φ
1
et φ
2
sont dites ´equi-
valentes si, pour toute trace σ et pour tout i ∈ N, σ(i) [= φ
1
ssi σ(i) [= φ
2
. Elles sont
dites initialement ´equivalentes si, pour toute trace σ, σ(0) [= φ
1
ssi σ(0) [= φ
2
.
Exemple 2.2 Les formules p ∧

q et p ∧

q sont initialement ´equivalentes, mais
ne sont pas ´equivalentes.
En raisonnant un peu, on voit que toute formule purement pass´ee (n’utilisant pas les
op´erateurs
U
et () de la forme

φ est initialement ´equivalente `a faux, et que toute
formule purement pass´ee de la forme φ
1 S
φ
2
est initialement ´equivalente `a φ
1
∧ φ
2
.
Donc, si on ´etait capable de sortir les op´erateurs pass´es d’une formule combinant des
op´erateurs pass´es et futurs, de fa¸con `a obtenir une combinaison bool´eenne de formules
purement pass´ees et purement futures, on serait capable de lui trouver une formule
purement future qui lui serait initialement ´equivalente.
Le r´esultat suivant, d´emontr´e dans [61], nous dit que tel est le cas. La d´emonstration
´etant un peu longue et hautement technique, nous ne la reproduirons pas ici.
Lemme 2.3 (S´eparation) Toute formule de P-LTL peut ˆetre exprim´ee comme une
combinaison bool´eenne de formules purement futures et purement pass´ees.
Ce r´esultat nous permet alors d’arriver au th´eor`eme suivant, dont le d´etail de la
d´emonstration se trouve lui aussi dans [61].
Th´eor`eme 2.4 (Expressivit´e de P-LTL) Pour toute formule de P-LTL, il existe
une formule de LTL initialement ´equivalente.
Il ne faut cependant pas tomber dans le pi`ege de croire que les op´erateurs pass´es
n’apportent rien `a la logique temporelle lin´eaire. En fait, en plus de permettre d’exprimer
Chapitre 2. Logiques temporelles 63
certaines propri´et´es de fa¸con plus intuitive et, comme nous le verrons sous peu, plus
succincte, il existe des cas d’utilisation o` u les algorithmes de v´erification `a utiliser sont
significativement plus efficaces. Par exemple, dans le cas o` u on ne v´erifie qu’un seul
chemin d’ex´ecution en temps r´eel, si la formule `a v´erifier est de la forme φ, o` u φ ne
comporte que les op´erateurs pass´es, il a d´ej` a ´et´e d´emontr´e, dans [62], qu’il est possible
d’utiliser des algorithmes de v´erification qui s’ex´ecutent en temps lin´eaire et n’utilisent
qu’une quantit´e de m´emoire constante en fonction de la taille du chemin v´erifi´e. En
fait, il est aussi possible d’arriver au mˆeme r´esultat si on se limite aux op´erateurs
futurs [31], mais comme les algorithmes utilis´es partent alors de la fin de la trace, on
est forc´e d’attendre que le programme ait termin´e son ex´ecution avant de passer `a la
v´erification. En plus de ne fonctionner que dans le cas o` u le programme `a v´erifier n’a
pas de chemin d’ex´ecution infini, cette m´ethode oblige `a sauvegarder toute la trace
d’ex´ecution, plutˆ ot que de simplement la v´erifier en mˆeme temps qu’elle se cr´ee. Pour
ces raisons, l’introduction d’op´erateurs pass´es en logique temporelle repr´esente donc un
grand int´erˆet.
2.1.3 Logique temporelle lin´eaire avec pass´e oubliable
φ ::= p [ φ [ φ
1
∨ φ
2
[ (φ [ φ
1 U
φ
2
[

φ [ φ
1 S
φ
2
[
N
φ
Tab. 2.8 – Syntaxe de N-LTL.
Lorsque l’on permet de m´elanger les op´erateurs de pass´e et de futur, il se peut
que certaines sp´ecifications n’aient pas exactement le sens attendu. Consid´erons, par
exemple, la formule (reset → (alarm → problem)), signifiant qu’` a chaque fois
qu’une remise `a z´ero est effectu´ee, l’alarme n’est pas d´eclench´ee tant qu’il n’y a pas eu
un probl`eme (l’alarme ne sonne pas pour rien). Alors, cette formule est satisfaite par la
trace :
reset, problem, alarm, alarm, . . .
mais aussi par la trace :
reset, problem, alarm, reset, alarm, . . .
on se retrouve alors aux prises avec le probl`eme suivant : l’alarme continue de sonner
apr`es la remise `a z´ero. On voudrait ˆetre capable de dire que le probl`eme est survenu
depuis la remise `a z´ero. Autrement dit, on voudrait ˆetre capable d’oublier le pass´e. Pour
r´egler ce probl`eme, certains auteurs [63, 64] ont propos´e d’ajouter `a P-LTL l’op´erateur
Chapitre 2. Logiques temporelles 64
σ(i) [=
N
φ ssi σ
i
(0) [= φ
Tab. 2.9 – S´emantique de l’op´erateur particulier `a N-LTL.
N
, qui se lit `a partir de maintenant, et dont l’objectif est justement de permettre
d’oublier le pass´e. La logique obtenue alors s’appelle N-LTL, et sa syntaxe est donn´ee
`a la table 2.8. La s´emantique de l’op´erateur
N
est donn´ee `a la table 2.9. La notation σ
i
d´esigne le i
eme
suffixe de σ. Il s’agit de la trace obtenue en coupant les i premiers ´etats
de σ. C’est-` a-dire que σ
i
(j) = σ(j + i).
Avec ce nouvel op´erateur, il est alors en mesure d’exprimer la propri´et´e voulue `a
l’aide de la formule : (reset →
N
((alarm → problem))).
Cependant, on remarque aussi que la formule de LTL (reset → alarm
U
problem)
exprime la propri´et´e voulue, et que cet exemple ne nous convainc pas tellement de la n´e-
cessit´e, du point de vue de l’expressivit´e, de l’op´erateur
N
. En fait, les introducteurs de
N-LTL ne pr´etendent nullement ajouter `a l’expressivit´e de P-LTL. Ils montrent mˆeme,
dans [63], que toute formule de N-LTL peut ˆetre traduite en une formule de LTL qui lui
est ´equivalente. D’apr`es eux, le principal avantage li´e `a son utilisation r´eside au niveau
de la taille des formules n´ecessaires pour exprimer certaines propri´et´es. Dans [64], ils
montrent les deux r´esultats suivants, qui ensemble justifient l’introduction de P-LTL et
N-LTL, malgr´e le fait qu’elles n’apportent rien du point de vue de l’expressivit´e :
Th´eor`eme 2.5 (Succintet´e de P-LTL) P-LTL peut ˆetre exponentiellement plus suc-
cinte que LTL.
Th´eor`eme 2.6 (Succintet´e de N-LTL) N-LTL peut ˆetre exponentiellement plus suc-
cincte que P-LTL.
Une logique L
1
est dite exponentiellement plus succincte qu’une logique L
2
si il
existe une propri´et´e ψ tel que si φ
1
et φ
2
sont les plus petites formules de L
1
et L
2
exprimant ψ, alors [φ
2
[ ∈ Ω([φ
1
[). C’est-`a-dire que le nombre d’op´erateurs de φ
2
est au
moins exponentiellement plus grand que celui de φ
1
. Ce r´esultat est int´eressant pour au
moins deux raisons. Premi`erement, du point de vue de la v´erification, cela signifie que le
temps de v´erification peut ˆetre exponentiellement plus court. Deuxi`emement, du point
de vue de la facilit´e d’utilisation, cela signifie que les sp´ecifications peuvent s’´ecrire `a
l’aide de formules exponentiellement plus courtes.
Chapitre 2. Logiques temporelles 65
2.1.4 µ-calcul lin´eaire
φ ::= X [ p [ φ [ φ
1
∨ φ
2
[ (φ [

φ [ µX.φ
Tab. 2.10 – Syntaxe du µ-calcul lin´eaire.
σ(i) [= µX.φ ssi ∃j.σ(i) [= µ
j
X.φ
avec µ
0
X.φ
def
= faux
et pour j = 0, µ
j
X.φ
def
= φ[µ
j−1
X.φ/X]
Tab. 2.11 – S´emantique de l’op´erateur particulier au µ-calcul lin´eaire.
Une autre fa¸con de percevoir le d´eroulement du temps est de ne prendre que les
op´erateurs de pass´e et de futur imm´ediats, et de permettre de d´efinir des formules
r´ecursivement. Par exemple, on pourrait d´efinir l’op´erateur φ de la fa¸con suivante :
σ(i) [= φ si et seulement si σ(i) [= φ ou σ(i) [= ( φ.
Par induction, cette formule serait alors satisfaite par σ(i) si et seulement si il existe
un ´etat `a partir de σ(i) satisfaisant la formule φ.
L’op´erateur permettant de d´efinir de fa¸con g´en´erale des formules de fa¸con r´ecursive
est l’op´erateur µ, appel´e op´erateur de plus petit point fixe. Lorsque l’on ajoute l’op´era-
teur de point fixe `a une logique d´ej` a existante, on dit que l’on obtient un µ-calcul. Par
exemple, si on ajoute l’op´erateur de point fixe `a la logique modale, on obtient le µ-calcul
modal. Le µ-calcul dont il est question ici est le µ-calcul lin´eaire, dont la syntaxe est
donn´ee `a la table 2.10. Avec cette syntaxe, on peut d´efinir la formule φ de la fa¸con
suivante : φ
def
= µX.(φ ∨(X). Informellement, φ se trouve alors `a ˆetre d´efinie comme
la formule X satisfaite si et seulement si φ est satisfaite ou X est satisfaite par l’´etat
suivant.
La s´emantique formelle de l’op´erateur de point fixe est donn´ee `a la table 2.11. Il
s’agit d’une s´emantique bas´ee sur la notion d’approximants. Pour X une variable libre
(n’apparaissant pas sous la port´ee d’un op´erateur µX) apparaissant dans φ, le premier
approximant de φ selon X est tout simplement la formule faux. Ensuite, on d´efinit
le i
`eme
approximant r´ecursivement `a partir du i − 1
`eme
de la fa¸con suivante : le i
`eme
approximant selon X est la formule φ, dans laquelle on a textuellement substitu´e la
Chapitre 2. Logiques temporelles 66
νX.φ
def
= µX.φ[X/X]
φ
1 U
φ
2
def
= µX.φ
2
∨ (φ
1
∧ (X)
φ
1 S
φ
2
def
= µX.φ
2
∨ (φ
1

X)
Tab. 2.12 – Op´erateurs d´efinis du µ-calcul lin´eaire.
variable X par le i −1
`eme
approximant selon X. La formule µX.φ est alors satisfaite par
σ(i) si et seulement si il existe un approximant selon X satisfait par σ(i). Par exemple,
dans le cas de la formule φ, la suite des approximants selon X est faux, φ ∨ (faux,
φ ∨ ((φ ∨ (faux),. . . .
On peut aussi d´efinir, `a partir de l’op´erateur de plus petit point fixe, l’op´erateur
ν, qui est l’op´erateur de plus grand point fixe. Sa d´efinition formelle est donn´ee `a la
table 2.12. L’approximant de base devient alors true, et la formule νX.φ est alors
satisfaite si et seulement si elle est satisfaite par tous ses approximants selon X. Par
exemple, il permet de d´efinir φ comme ´etant νX.(φ ∧ (X).
Il est facile de voir que le µ-calcul lin´eaire est au moins aussi expressif que LTL ou
P-LTL.
`
A la figure 2.12, on montre comment on peut d´efinir les op´erateurs de LTL et
P-LTL `a l’aide des op´erateurs du µ-calcul lin´eaire. Il est cependant moins facile de voir
si celui-ci est strictement plus expressif. En fait, le lemme suivant [33], que nous ne
d´emontrerons pas ici, nous permet de conclure que le µ-calcul lin´eaire est strictement
plus expressif que LTL :
Lemme 2.7 Il n’existe pas de formule de LTL satisfaite par tous les ´etats σ(i) d’une
trace si et seulement si ∀i.p ∈ σ(i) ssi i est pair.
Alors, comme la formule du µ-calcul lin´eaire νX.p ∧ (p ∧ ((X exprime exac-
tement cette propri´et´e, on arrive au r´esultat suivant :
Th´eor`eme 2.8 Le µ-calcul lin´eaire est strictement plus expressif que LTL.
Nous terminons cette section en remarquant que nous n’avons pas justifi´e l’emploi
du terme point fixe pour d´esigner les op´erateurs µ et ν. Ceci est dˆ u au choix que
nous avons fait de pr´esenter leur s´emantique `a l’aide de la notion d’approximant. Une
autre fa¸con de faire est de voir une formule φ comportant une variable libre X comme
une fonction prenant en entr´ee un ensemble d’´etats et donnant en sortie l’ensemble
Chapitre 2. Logiques temporelles 67
des ´etats satisfaisant φ sous l’hypoth`ese que ceux-ci satisfont d´ej`a X. L’ensemble des
´etats satisfaisant µX.φ (νX.φ) est alors le plus petit (le plus grand) point fixe de
cette fonction. L’existence de ce point fixe est garantie `a condition que la fonction
soit monotone (ce qui sera le cas si on pose les restrictions n´ecessaires sur l’imbrication
des n´egations ou mieux encore, si on ne permet de ne les appliquer qu’aux constantes
propositionnelles). L’existence de ce point fixe a ´et´e d´emontr´ee par Tarski [65] en 1955
dans un contexte plus g´en´eral : celui des treillis. Nous nous arrˆetons ici sur cette fa¸con
de d´efinir la s´emantique des op´erateurs de point fixe, mais sachons seulement qu’il est
possible de les d´emontrer comme ´etant ´equivalentes [53].
2.2 Logiques temporis´ees
Les quatre logiques que nous venons de pr´esenter ´etaient toutes comparables du point
de vue de l’expressivit´e car elles ´etaient toutes d´efinies `a partir du mˆeme mod`ele : celui
de la deuxi`eme ligne de la table 2.1. Les logiques que nous pr´esentons dans cette section
ne leur sont pas comparables car elles sont d´efinies `a partir de mod`eles temporis´es.
Les deux premi`eres logiques que nous pr´esentons sont des logiques propositionnelles,
et leur mod`ele est celui de la troisi`eme ligne.
`
A chaque ´ev´enement on associe, en plus
d’un ensemble de constantes propositionnelles, un instant t pris dans un domaine tem-
porel T. Les ´el´ements σ(i) d’une trace σ sont donc des couples, dont la premi`ere compo-
sante, σ
1
(i), est l’ensemble de constantes propositionnelles, et la seconde composante,
σ
2
(i), est le temps qui lui est associ´e. Si l’ensemble T choisi pour repr´esenter le temps
est R, on dispose d’une repr´esentation du temps qui est continue, et s’il s’agit de N,
on dispose d’une repr´esentation discr`ete. Dans le cas de ces deux premi`eres logiques,
l’ensemble choisi par les auteurs est N.
La troisi`eme logique que nous pr´esentons se distingue des deux autres de par le fait
que le mod`ele sur lequel elle est d´efinie est celui d’une logique temporis´ee du premier
ordre (avant-derni`ere ligne de la table 2.1). Aussi, le choix du domaine temporel (continu
ou discret) est laiss´e libre `a l’utilisateur.
2.2.1 Logique temporelle temporis´ee
Les premiers articles sur la v´erification de syst`emes temps-r´eel datent de la fin des
ann´ees 80. Il ne faut pas confondre ce probl`eme avec celui de la v´erification de syst`emes
Chapitre 2. Logiques temporelles 68
π ::= x + c [ c
φ ::= p [ π
1
≤ π
2
[ π
1

d
π
2
[ x.φ [ φ [ φ
1
∨ φ
2
[ (φ [ φ
1 U
φ
2
Tab. 2.13 – Syntaxe de T-LTL.
en temps r´eel (qui est celui qui nous int´eresse dans le cadre du pr´esent m´emoire). Un
syst`eme temps-r´eel est un syst`eme dont la sp´ecification comporte des aspects temporels
exprim´es en unit´es de temps. Par exemple, au lieu de s’int´eresser `a ce que la porte du
garage se ferme apr`es que l’auto y soit entr´ee, on s’int´eressera `a ce qu’elle se ferme pas
plus de une minute apr`es que l’auto y soit entr´ee.
De la mˆeme fa¸con que plusieurs formalismes ont ´et´e propos´es pour d´ecrire les sys-
t`eme non-temporis´es (automates, alg`ebres de processus, r´eseaux de Petri, structures de
Kripke, syst`emes de transition ´etiquet´es) plusieurs formalismes ont aussi ´et´e propos´es
pour repr´esenter les syst`emes temps-r´eel (automates temporis´es, alg`ebres de processus
temporis´ees, etc.). Une des caract´eristiques les plus importantes des syst`emes temporis´es
est que les diff´erentes actions pouvant ˆetre effectu´ees par le syst`eme ne sont plus consi-
d´er´ees comme pouvant ˆetre effectu´ees en un simple tic d’horloge, mais en un certaine
nombre de tics d’horloge. Par exemple, si un syst`eme peut effectuer la suite d’actions
ouvrir−entrer−fermer, et que ces actions prennent respectivement 5,10 et 5 secondes,
alors le syst`eme peut effectuer l’action fermer apr`es avoir effectu´e l’action ouvrir, mais
il ne peut pas l’effectuer dans un d´elai de 2 secondes, car il doit entre temps effectuer
l’action entrer, qui elle prend 10 secondes.
Nous ne nous ´etendrons pas ici sur les diff´erents formalismes ayant ´et´e propos´es
pour repr´esenter les syst`emes temps-r´eel, mais sachons seulement que c’est dans ce
contexte que les logiques temporis´ees sont d’abord apparues. Un des auteurs ayant le
plus particip´e au d´eveloppement de la v´erification des syst`emes temps-r´eel est sans
doute Thomas A. Henzinger qui, dans sa th`ese de doctorat [66], a propos´e tout une
m´ethodologie pour repr´esenter et v´erifier les syst`emes temps-r´eel.
Une de ses contributions, du point de vue des logiques temporelles, est d’avoir pro-
pos´e d’ajouter aux diverses logiques temporelles d´ej`a existantes (LTL [56], CTL [67],
µ-calcul modal [67], et mˆeme ETL [66], dont nous ne parlons pas ici) la notion de chrono-
m`etre. Un chronom`etre est une variable qui s’unifie avec le temps de certains ´ev´enements
`a l’aide d’un op´erateur sp´ecial, appel´e op´erateur d’initialisation (reset). Une fois initia-
lis´e, un chronom`etre peut ˆetre utilis´e pour sp´ecifier les contraintes temporelles devant
ˆetre v´erifi´ees entre diverses actions.
Chapitre 2. Logiques temporelles 69
σ(i) [=
ε
x.φ ssi σ(i) [=
ε[σ
2
(i)/x]
φ
σ(i) [=
ε
π
1
≤ π
2
ssi ε(π
1
) ≤ ε(π
2
)
σ(i) [=
ε
π
1

d
π
2
ssi ε(π
1
) ≡
d
ε(π
2
)
avec ε(x + c)
def
= ε(x) + c et ε(c)
def
= c
Tab. 2.14 – S´emantique des op´erateurs particuliers `a T-LTL.

t
φ
def
= x.(true
U
y.(φ ∧ y < x + t))
Tab. 2.15 – Un op´erateur d´efini de T-LTL.
Dans le cas de LTL, l’ajout de chronom`etres donne la logique T-LTL [56], dont la
syntaxe est donn´ee `a la table 2.13. La construction π repr´esente une r´ef´erence temporelle.
Le cas c est une r´ef´erence temporelle absolue, et le cas x+c est une r´ef´erence temporelle
relative (c unit´es de temps apr`es x). La construction x.φ est celle permettant d’unifier
la variable x avec l’instant pr´esent. Finalement, les constructions π
1
≤ π
2
et π
1

d
π
2
sont des contraintes temporelles. La premi`ere signifie que π
1
est plus petite ou ´egale `a
π
2
, alors que la seconde signifie que π
1
est congrue `a π
2
modulo d. On remarque que
si T-LTL ´etait d´efinie pour un domaine temporel continu, cette derni`ere construction
n’aurait aucun sens.
La s´emantique des op´erateurs ainsi ajout´es `a LTL est donn´ee `a la table 2.14. On
remarque qu’il s’agit de la seule logique parmi celles pr´esent´ees dans ce chapitre pour
laquelle on a besoin d’une notion d’environnement. Un environnement ε est une fonc-
tion partielle associant des instants `a certains des chronom`etres de la formule. Ceux-ci
sont mis `a jour `a l’aide de l’op´erateur d’initialisation. La formule x.φ est donc satis-
faite par σ(i) sous un environnement ε si et seulement si φ est satisfaite par σ(i) sous
l’environnement ε mis `a jour de fa¸con `a associer au chronom`etre x l’instant de σ(i).
Les contraintes temporelles, quand `a elles, sont satisfaites sous ε si les relations qu’elles
expriment sont vraies en rempla¸cant les chronom`etres par les valeurs auxquelles ils sont
associ´es dans ε.
Nous ne pousserons pas plus loin cette pr´esentation de T-LTL. Nous terminons en
pr´esentant comment on peut d´efinir, `a l’aide des op´erateurs de T-LTL, l’op´erateur
t
φ.
Chapitre 2. Logiques temporelles 70
Cette d´efinition se trouve `a la figure 2.15. Elle signifie que si x est l’instant associ´e `a
l’´ev´enement pr´esent, alors, `a un certain instant y situ´e `a moins de t unit´es de temps
dans le futur, φ doit ˆetre satisfaite.
2.2.2 Logique temporelle m´etrique
I ::= [m, n] [ ≡
d
c
φ ::= p [ φ [ φ
1
∨ φ
2
[ (
I
φ [ φ
1 UI
φ
2
[

I
φ [ φ
1 SI
φ
2
Tab. 2.16 – Syntaxe de MTL.
σ(i) [= (
I
φ ssi σ(i + 1) [= φ et σ
2
(i + 1) ∈ σ
2
(i) + I
σ(i) [= φ
1 UI
φ
2
ssi ∃k ≥ i.σ(k) [= φ
2
et σ
2
(k) ∈ σ
2
(i) + I
et ∀i ≤ j < k.σ(j) [= φ
1
σ(i) [=

I
φ ssi σ(i −1) [= φ et σ
2
(i + 1) ∈ σ
2
(i) −I
σ(i) [= φ
1 SI
φ
2
ssi ∃k ≤ i.σ(k) [= φ
2
et σ
2
(k) ∈ σ
2
(i) −I
et ∀i ≥ j > k.σ(j) [= φ
1
σ
2
(i) ±[m, n]
def
= [m±σ
2
(i), n ±σ
2
(i)]
σ
2
(i) ±(≡
d
c)
def
= =
d

2
(i) ±c)
σ
2
(i) ∈ [m, n] ssi m ≤ σ
2
(i) ≤ n
σ
2
(i) ∈ ≡
d
c ssi σ
2
(i) =
d
c
Tab. 2.17 – S´emantique des op´erateurs particuliers `a MTL.
Pour exprimer les contraintes de temps-r´eel, Henzinger a choisi d’ajouter `a LTL cer-
tains op´erateurs. D’autres auteurs [68], contemporains `a Henzinger, ont plutˆ ot propos´e
de modifier les op´erateurs temporels d´ej` a pr´esents dans LTL, en les indexant direc-
tement par les contraintes. La logique ainsi obtenue s’appelle MTL (Metric Temporal
Logic).
La syntaxe de MTL est donn´ee `a la table 2.16. Les contraintes temporelles sont de
deux types : intervalles ([m, n]) et relations de congruence (≡
d
). Par exemple, l’op´erateur

t
, est d´efini dans MTL de la fa¸con suivante :
t
φ
def
= true
U[0,t]
φ.
La s´emantique des op´erateurs de MTL est donn´ee `a la table 2.17. Ils s’interpr`etent
Chapitre 2. Logiques temporelles 71
tous de la mˆeme fa¸con que pour LTL, sauf que les ´etats concern´es sont restreints `a la
contrainte temps-r´eel I. Par exemple, si σ
2
(i) = 7, alors (
[0,5]
φ est satisfaite par σ(i)
ssi σ(i + 1) [= φ et σ
2
(i + 1) ∈ [7, 12]. Mˆeme chose pour la relation de congruence. Si
σ
2
(i) = 7, alors (

5
φ est satisfaite par σ(i) ssi σ(i + 1) [= φ et σ
2
(i + 1) ≡
5
12.
Dans sa th`ese, Henzinger affirme que les deux fa¸cons d’exprimer les contraintes
temps-r´eel sont ´equivalentes. Il affirme aussi que MTL, du point de vue de la d´ecidabilit´e,
se prˆete mieux aux contraintes pass´ees que T-LTL. Historiquement, il semblerait que
MTL ait gagn´e la pr´ef´erence de la communaut´e, car au cours des recherches que nous
avons faites, nous avons trouv´e un plus grand nombre d’auteurs utilisant MTL que
T-LTL.
2.2.3 TRIO
φ ::= ∀x
i
.φ [ p(x
1
, . . . , x
n
) [ φ [ φ
1
∨ φ
2
[ Dist(φ, t)
Tab. 2.18 – Syntaxe de TRIO.
σ(i) [= Dist(φ, t) ssi ∃j.σ(j) [= φ et σ
2
(j) = σ
2
(i) + t
Tab. 2.19 – S´emantique de l’op´erateur particulier `a TRIO.
Nous terminons ce chapitre avec une br`eve description de TRIO [69], une logique
temporelle du premier ordre avec quantificateurs. Nous verrons que lorsque l’on dispose
de la puissance d’expression de la logique du premier ordre, le nombre d’op´erateurs
temporels dont on a besoin chute rapidement.
La syntaxe de TRIO est donn´ee `a la table 2.18. Cette logique ne comporte qu’un
seul op´erateur temporel, Dist, dont la s´emantique est donn´ee `a la table 2.19. La formule
Dist(φ, t) est vraie pour les ´etats σ(i) ayant un ´etat situ´e `a une distance t (positive ou
n´egative, finie ou infinie) satisfaisant φ.
Grˆace `a la pr´esence du quantificateur existentiel ∀, l’op´erateur Dist permet d’expri-
mer toutes les relations temporelles de LTL, P-LTL, T-LTL ou MTL.
`
A la table 2.20, on
Chapitre 2. Logiques temporelles 72

def
= Dist(φ, t) ∧ ∀d.Dist(true, d) → d > t

φ
def
= Dist(φ, −t) ∧ ∀d.Dist(true, −d) → d > t

t
φ
def
= ∀d.0 ≤ d < t → Dist(φ, d)
φ
1 U
φ
2
def
= ∃t.Dist(φ
2
, t) ∧
t
φ
1

t
φ
def
= ∀d.0 ≥ d > −t → Dist(φ, d)
φ
1 S
φ
2
def
= ∃t.Dist(φ
2
, −t) ∧
t
φ
1
Tab. 2.20 – Quelques op´erateurs d´efinis de TRIO.
voit quelques exemples d’op´erateurs temporels que l’on peut d´efinir `a partir de l’op´era-
teur Dist. Il est sous-entendu, dans ces d´efinitions, que les variables t et d sont positives.
Par exemple, l’op´erateur (φ signifie qu’il existe un ´etat situ´e `a une distance positive t
satisfaisant φ, et que tous les ´etats situ´es `a une distance positive sont situ´es plus loin.
Les autres op´erateurs sont d´efinis de fa¸con semblable.
2.3 Conclusion
Dans ce chapitre, nous avons donn´e une pr´esentation de sept logiques temporelles
d´efinies `a partir de trois mod`eles diff´erents. Le premier choix `a faire, face `a un probl`eme
de v´erification, est celui du mod`ele. Une fois que celui-ci est choisi, on se penche alors
sur celui de la logique.
Dans les deux chapitres suivants, nous verrons comment le choix du mod`ele et de la
logique peut influencer la qualit´e du travail. D’une part, le mod`ele choisi doit `a la fois col-
ler le mieux possible `a la vision que nous avons du probl`eme auquel nous nous attaquons,
et d’autre part, la logique doit comporter des op´erateurs appropri´es non-seulement aux
propri´et´es v´erifi´ees, mais aussi au contexte de la v´erification. Au chapitre 3 comme au
chapitre 4, le mod`ele que nous choisirons est un mod`ele du premier ordre. Des hypo-
th`eses diff´erentes sont cependant faites par rapport aux interpr´etations (la fonction I
de la table 2.1) faites de chaque ´etat. De plus, la logique utilis´ee au chapitre 3 est
une logique temporis´ee, alors que celle du chapitre 4 peut ˆetre temporis´ee, mais n’a
absolument pas besoin de l’ˆetre pour pouvoir l’utiliser telle que nous la d´ecrivons. Fi-
nalement, la principale diff´erence entre les deux logiques que nous pr´esentons est que
celle du chapitre 3 dispose d’op´erateurs temporels futurs, alors que celle du chapitre 4
dispose d’op´erateurs temporels pass´es. Nous verrons que dans un contexte de v´erifica-
Chapitre 2. Logiques temporelles 73
tion en temps-r´eel, une logique d´efinie `a partir d’op´erateurs pass´es est non-seulement
plus intuitive, mais aussi algorithmiquement avantageuse.
Chapitre 3
D´etection d’intrusions et analyse
passive
L’analyse passive de r´eseaux regroupe un ensemble de techniques heuristiques per-
mettant d’acqu´erir passivement - c’est-`a-dire sans g´en´erer de trafic - de l’information sur
un r´eseau informatique. L’acquisition passive s’oppose `a l’acquisition active, qui consiste
en un ensemble de techniques permettant d’acqu´erir de l’information en injectant du
trafic sur le r´eseau et en attendant de voir sa r´eaction. Un exemple simple de technique
d’analyse active est l’utilisation du programme ping, qui permet de savoir si un hˆote
donn´e est branch´e au r´eseau et prˆet `a communiquer. Le programme ping utilise de fa-
¸con tout `a fait normale le protocole ICMP, en envoyant `a l’hˆ ote concern´e une requˆete
de type echo, `a laquelle il doit normalement r´epondre en envoyant un paquet de type
reply. La r´eception du paquet reply permet, de fa¸con g´en´erale, de conclure que l’hˆ ote
distant est en ligne et prˆet `a recevoir de l’information. Il est `a noter cependant que le
protocole ICMP n’est qu’un protocole de contrˆole, n’ayant aucunement ´et´e con¸cu avec
des consid´erations de s´ecurit´e, et que rien ne permet de conclure que le paquet echo
n’a pas ´et´e intercept´e par un tiers, qui pourrait soit avoir bloqu´e le paquet, soit avoir
envoy´e un faux paquet reply.
Le protocole ICMP permet aussi, en plus de tester la connectivit´e avec un hˆote
distant, de tester la qualit´e de la connection. Pour ce faire, le protocole pr´evoit un
champ donn´ees, de longueur variable et de contenu non-sp´ecifi´e. L’hˆote envoyant la
requˆete echo remplit ce champ avec des valeurs arbitraires, et l’hˆote r´epondant doit
recopier les valeurs qu’il a re¸cues dans le paquet reply. Si, `a l’arriv´ee, les valeurs du
champ donn´ees sont diff´erentes de celles envoy´ees au d´epart, il faut conclure que la
connection entre les deux hˆ otes est de pi`etre qualit´e et que la communication est par
cons´equent non-fiable. Cette fonctionnalit´e du protocole ICMP permet de l’utiliser afin
Chapitre 3. D´etection d’intrusions et analyse passive 75
de d´etecter passivement le syst`eme d’exploitation de l’hˆ ote envoyant la requˆete echo.
En effet, comme le protocole ne sp´ecifie aucunement quel doit ˆetre le contenu du champ
donn´ees, celui-ci est laiss´e `a la fantaisie du programmeur et il est possible de recon-
naˆıtre le syst`eme d’exploitation, ou du moins une famille de syst`emes d’exploitation, en
inspectant la valeur de ce champ. Par exemple, certains programmeurs peuvent avoir
choisi d’envoyer abcdefg, alors que d’autres peuvent avoir choisi qwertyu. L’ensemble
des techniques permettant de d´etecter, activement ou passivement, le syst`eme d’exploi-
tation d’un hˆote donn´e s’appelle, dans la litt´erature, la prise d’empreintes digitales de
syst`eme d’exploitation (Operating System Fingerprinting) [70, 71].
Il existe ainsi un bon nombre de techniques heuristiques permettant d’acqu´erir de
l’information sur un r´eseau informatique simplement en observant les particularit´es
d’implantation et les comportements, normaux ou non, des diff´erents protocoles y cir-
culant. Cette information peut ˆetre utilis´ee soit malicieusement par un utilisateur mal
intentionn´e afin de mieux pr´eparer son attaque, soit judicieusement par un analyste en
s´ecurit´e afin de mieux prot´eger un r´eseau informatique. En effet, cette information peut
entre autres, comme nous l’avons vu au chapitre 1 avec le logiciel NeVO, permettre
de d´ecouvrir des failles insoup¸conn´ees dans le r´eseau et d’y r´em´edier avant qu’elles ne
soient exploit´ees par un utilisateur mal intentionn´e. Dans ce chapitre, nous pr´esente-
rons une premi`ere approche intuitive permettant de mettre `a profit l’analyse passive
en vue d’am´eliorer la d´etection d’intrusions. En fait, la d´etection d’intrusions sera ici
per¸cue comme un cas particulier d’analyse passive, o` u les intrusions ne seront qu’un cas
particulier d’information `a acqu´erir.
Dans la section 3.1, nous donnons un aper¸cu g´en´eral de la structure logicielle d’un
syst`eme de d´etection d’intrusions et d’analyse passive que nous avons d´evelopp´e. Dans
la section 3.2, nous pr´esentons la syntaxe du langage de signatures du syst`eme d´eve-
lopp´e. Dans la section 3.3, nous montrons comment le langage peut ˆetre utilis´e pour
d´etecter des sc´enarios d’attaque se d´eroulant sur plusieurs paquets. Dans la section 3.4,
nous montrons comment le langage peut ˆetre utilis´e pour acqu´erir passivement de l’in-
formation sur un r´eseau informatique. Dans la section 3.5, nous pr´esentons le langage
de signatures d’une fa¸con formelle de mˆeme que l’algorithme de v´erification en ligne
lui ´etant associ´e. Finalement, nous concluons en critiquant le syst`eme et le langage
d´evelopp´es en les comparant `a ceux analys´es au chapitre 1.
Chapitre 3. D´etection d’intrusions et analyse passive 76
Réseau
Libpcap
Module de décodage
Préprocesseurs
Module de détection
Modules d’affichage
Réseau
Libpcap
Module de décodage
Préprocesseurs
Module de détection
Modules d’affichage
Base de connaissances
Module de scénarios
Fig. 3.1 – Architecture du syst`eme d´evelopp´ee (` a droite), et celle de Snort (`a gauche).
3.1 Architecture du syst`eme
Nous avons con¸cu et implant´e un syst`eme de d´etection d’intrusions bas´e sur un lan-
gage simple qui, dans le style de LAMBDA, permet de tenir `a jour et d’utiliser une
base de connaissances en vue d’effectuer une d´etection plus pr´ecise. Ce syst`eme r´euti-
lise une partie de l’architecture logicielle de Snort - principalement les pr´eprocesseurs
effectuant un travail de formattage sur les paquets - mais utilise un nouvel engin de
d´etection permettant, en plus de d´etecter les paquets pouvant ˆetre consid´er´es comme
offensifs, de d´etecter des suites de paquets pouvant ˆetre consid´er´ees comme offensives.
Nous avons aussi ajout´e `a l’architecture du syst`eme une base de connaissances qui
permet, en plus d’accumuler les connaissances acquises, d’inf´erer de nouvelles connais-
sances. Les r`egles d’inf´erence de cette base de connaissances sont sp´ecifi´ees en Prolog,
ce qui fait que le syst`eme d´evelopp´e peut ˆetre vu comme un syst`eme `a deux niveaux,
avec un engin permettant de d´etecter les suites de paquets, et un autre permettant d’in-
f´erer les connaissances. La base de connaissances, en plus de permettre une d´etection
d’intrusions plus pr´ecise, peut ˆetre consult´ee directement par l’administrateur r´eseau en
cas de besoin. Par exemple, il pourrait l’utiliser afin de savoir quels sont les hˆotes du
r´eseau offrant le service Telnet. Finalement, elle permet aussi de v´erifier des politiques
de s´ecurit´e haut niveau, telles que il ne doit y avoir qu’un seul routeur dans le r´eseau.
Chapitre 3. D´etection d’intrusions et analyse passive 77
3.2 Langage
Nous commen¸cons par pr´esenter de fa¸con informelle le langage que nous avons d´e-
velopp´e, de fa¸con `a mettre en ´evidence les objectifs poursuivis et l’intuition derri`ere les
choix que nous avons faits. Les aspects formels ne sont trait´es qu’`a partir de la sec-
tion 3.5. La grammaire du langage d´evelopp´e, sous la forme BNF (Backus Naur Form),
est donn´ee `a la table 3.1.
'specification` ::= 'scenario`*
'scenario` ::= 'step`('step`'timeout`)*
'step` ::= 'header`'filter`'output`*
'header` ::= step 'id` : 'snortsig`
'filter` ::= match : 'matchrule`*
'matchrule` ::= 'id`.'field`'op`'id`.'field` ; [ 'prolog` ;
'op` ::= < [ ≤ [ > [ ≥ [ =
'output` ::= output : 'prolog`
'timeout` ::= timeout : 'id`.timestamp + 'time`'output`*
'time` ::= 'number`'timeunit`
'timeunit` ::= sec [ hours [ days [ weeks [ years
Tab. 3.1 – Syntaxe du langage de signatures.
Une sp´ecification (non-terminal 'specification`) est constitu´ee d’un ensemble de sc´e-
narios (non-terminal 'scenario`) qui doivent ˆetre vus comme des suites d’´etapes (non-
terminal 'step`) `a franchir. Comme nous nous situons dans un contexte de d´etection
d’intrusions au niveau r´eseau, chaque ´etape doit ˆetre vue comme un paquet, identifi´e
dans l’entˆete de l’´etape (non-terminal 'header`) par son nom ('id`) et par une signature
Snort ('snortsig`) permettant d’identifier certaines de ses caract´eristiques (par exemple,
contenir une chaˆıne de caract`eres donn´ee, ˆetre un paquet SYN, etc.). Comme les si-
gnatures Snort ne s’appliquent qu’`a un seul paquet, on doit ajouter une construction
syntaxique suppl´ementaire permettant de lier ceux-ci entre eux (non-terminal 'filter`).
Les filtres sont un ensemble de r`egles d’appariement (non-terminal 'matchrule`) per-
mettant, dans un premier lieu, de comparer entre elles les valeurs de certains champs
(non-terminal 'field`) des diff´erents paquets constituant le scenario, et dans un second
lieu, de consulter la base de connaissances. En plus des conditions exprim´ees par les
r`egles d’appariement, chaque ´etape doit se produire dans un d´elai donn´e, relatif aux
´etapes pr´ec´edentes. Ce d´elai est exprim´e par la clause 'timeout`, permettant de sp´eci-
fier le d´elai d’attente maximal entre deux ´etapes. Comme la notion de d´elai ne peut pas
s’appliquer au premier paquet d’un sc´enario, la premi`ere ´etape n’est pas suivie d’une
Chapitre 3. D´etection d’intrusions et analyse passive 78
clause 'timeout`. Finalement, `a chaque ´etape, il est possible de faire des ajouts ou des
retraits dans la base de connaissances. Cette interaction peut se faire soit `a l’identi-
fication d’un paquet (dans le cas o` u le non-terminal 'output` suit imm´ediatement le
non-terminal 'filter`), soit `a l’´ecoulement d’un d´elai (dans le cas o` u le non-terminal
'output` suit imm´ediatement le non-terminal 'timeout`). Dans l’implantation que nous
proposons, la base de connaissances est programm´ee en Prolog, car ce langage per-
met de traiter et de relier entre elles les connaissances. Le mot-cl´e output indique une
instruction qui doit ˆetre transmise telle quelle `a la base de connaissances.
Les symboles 'snortsig` et 'prolog` ne sont pas d´efinis car ils r´ef`erent `a des langages
existants que nous nous dispenserons de d´ecrire `a nouveau ici [1, 72]. La syntaxe du
symbole 'id` est la mˆeme que celle d’une variable dans le langage de programmation
C. Le symbole 'field` devrait ˆetre d´ecrit par ´enum´eration. Il d´esigne explicitement un
champ d’une entˆete donn´ee. Par exemple, les mots sip, dip, sport, dport d´esignent res-
pectivement les adresses IP de mˆeme que les ports source et destination. Dans le cas
d’un paquet ARP, les mots opcode, thdradr, tprotoadr, shdradr, sprotoadr d´esignent res-
pectivement : le type de paquet (requˆete ou r´eponse), les adresses mat´erielle et logicielle
de la cible de mˆeme que celles de la source.
3.3 Sc´enarios d’attaques complexes
Le balayage de ports est souvent une des premi`eres ´etapes `a effectuer pour attaquer
un syst`eme. Il permet de savoir quels sont les services offerts et de se faire ainsi une
premi`ere id´ee de l’approche `a utiliser. En fait, bien que non-dommageable pour la vic-
time, le balayage des ports constitue tout de mˆeme une attaque en soi car il permet
`a l’attaquant d’acqu´erir des informations privil´egi´ees. Une des difficult´es reli´ees `a sa
d´etection rel`eve du fait qu’il peut se faire en utilisant le protocole TCP de fa¸con tout
`a fait normale. C’est pourquoi un syst`eme `a base de r`egles tel que Snort, fonctionnant
un paquet `a la fois, ne peut `a la base d´etecter ce type d’attaque. Pour ce faire, on
doit y aller par programmation, par exemple `a l’aide des pr´eprocesseurs, passant ainsi
par dessus le syst`eme de r`egles. Bien que tr`es efficace, cette fa¸con de faire ne donne
cependant pas beaucoup de souplesse `a l’usager qui voudrait d´efinir lui-mˆeme ce qu’il
consid`ere comme un balayage.
Dans cette section, nous montrons comment le langage que nous proposons permet
de d´efinir de fa¸con claire et concise ce que nous consid´erons comme un balayage. Nous
voyons aussi comment notre approche permet de d´efinir rapidement de nouveaux types
de balayages, une tˆache autrement plus ardue lorsque l’on utilise les pr´eprocesseurs.
Chapitre 3. D´etection d’intrusions et analyse passive 79
step syn1 : tcp any any -> any any (flags :S ;)
step syn2 : tcp any any -> any any (flags :S ;)
match : syn1.sip=syn2.sip ; syn1.dip=syn2.dip ; syn1.dport !=syn2.dport ;
timeout : syn1.timestamp + 2sec ;
step syn3 : tcp any any -> any any (flags :S ;)
match : syn1.sip=syn3.sip ; syn1.dip=syn3.dip ;
syn1.dport !=syn3.dport ; syn2.dport !=syn3.dport ;
output : assert(alert(portscan,syn1.sip,syn1.dip)).
timeout : syn2.timestamp + 2sec ;
Fig. 3.2 – Balayage SYN.
La m´ethode de balayage TCP connect() est sans doute la plus r´epandue et la plus
facile. L’attaquant n’a qu’`a effectuer une tentative de connection sur le port cible et
simplement v´erifier si elle est accept´ee ou pas. Bien que pr´esentant certains avantages
de rapiditi´e et de simplicit´e, cette m´ethode n’est cependant pas `a privil´egier car elle se
d´etecte assez facilement par consultation des fichiers de log [7]. Pour ´eviter ce dernier
probl`eme, on privil´egiera une m´ethode plus subtile, comme par exemple le balayage
SYN. Dans un balayage SYN, en cas de r´eception d’un SYN-ACK, on enverra sim-
plement un RST au lieu d’un ACK comme on devrait le faire pour finir d’´etablir la
connection. Le syst`eme ne gardera ainsi g´en´eralement pas trace de la connection.
Dans un cas comme dans l’autre, dans les situations o` u l’attaquant voudra balayer
plusieurs ports sur une mˆeme machine, la signature montr´ee `a la figure 3.2 devrait ˆetre
en mesure de d´etecter le comportement malicieux de l’attaquant. Elle sp´ecifie que si trois
demandes de connection, address´ees au mˆeme hˆ ote et provenant du mˆeme hˆote, mais
faites sur des ports cibles diff´erents, survenaient `a moins de deux secondes d’intervalle,
il faudrait alors ajouter `a la base de connaissances qu’une attaque de portscan vient
d’avoir lieu.
La limite de trois connections, de mˆeme que le d´elai de deux secondes, sont tout `a
fait arbitraires. En fait, il faut faire un compromis entre la possibilit´e de faux n´egatifs
et l’engorgement de la m´emoire. L’important ici est de remarquer qu’une modification
mineure du fichier de signatures permet d’ajuster rapidement notre politique de s´ecurit´e.
Par exemple, on peut modifier la signature pr´ec´edente afin de red´efinir la notion de
balayage de ports au niveau r´eseau. Certains attaquants peuvent en effet ne pas ˆetre
int´eress´es `a attaquer une machine en particulier, mais plutˆ ot un service donn´e, comme
dans le cas de certains serveurs warez qui exploitent des comptes FTP anonymous
laiss´es n´egligemment actifs par certains administrateurs r´eseau lors de l’installation du
syst`eme. Dans ce cas, la politique ne sera pas d’interdire la connection sur diff´erents
Chapitre 3. D´etection d’intrusions et analyse passive 80
ports du mˆeme hˆ ote, mais plutˆot sur le mˆeme port de diff´erents hˆotes.
De la mˆeme fa¸con, on pourrait aussi d´efinir un balayage Ping comme ´etant une
certaine quantit´e de requˆetes ICMP echo provenant du mˆeme hˆ ote vers des hˆ otes
diff´erents dans un court laps de temps.
3.4 Acquisition passive d’information
Comme nous l’avons d´ej`a dit, l’analyse passive regroupe un ensemble de techniques
permettant d’acqu´erir de l’information sur un r´eseau seulement en ´ecoutant le trafic
circulant `a quelques endroits strat´egiques, par exemple `a la sortie du routeur principal.
D’une certaine fa¸con, on peut la consid´erer comme une g´en´eralisation de la d´etection
d’intrusions au niveau r´eseau. En d´etection d’intrusions, on est seulement int´eress´e `a
savoir si oui ou non un certain type de comportement, consid´er´e comme malicieux, sur-
vient. En analyse passive, on sera plutˆot int´eress´e `a d´eduire le maximum d’information
du trafic (normal aussi bien que malicieux) que l’on voit circuler sur le r´eseau. Cette
information peut concerner autant la configuration des hˆ otes que l’activit´e se d´eroulant
en g´en´eral sur le r´eseau, comme par exemple les sessions TCP actives.
Encore une fois, chacune des techniques mentionn´ees dans cette section peut se faire
aussi par programmation. Par exemple, dans le cas de Snort, la d´etection des sessions
actives est d´ej`a prise en compte par le pr´eprocesseur Flow. Cependant, il ne faut pas
perdre de vue que l’id´ee ici est de se munir d’un langage de sp´ecification qui soit assez
g´en´eral pour : minimiser le plus possible le temps de d´eveloppement, maximiser le plus
possible la lisibilit´e et la r´eutilisation, et permettre un maximum de corr´elation entre
les composantes, via la base de connaissances.
3.4.1 Ports TCP ouverts et sessions actives
Les ports TCP ouverts des hˆotes, de mˆeme que leurs sessions actives, constituent un
exemple simple mais important d’information qu’il est int´eressant d’acqu´erir de fa¸con
passive. En effet, on ne peut pas toujours se fier `a la fa¸con dont l’on croit avoir configur´e
les hˆotes de notre r´eseau, et cela pour plusieurs raisons. Il se peut (1) qu’un utilisateur
malveillant ou insouciant ait lui-mˆeme install´e une application qui va `a l’encontre de
nos politiques de s´ecurit´e, comme par exemple Kazaa, (2) qu’un utilisateur ait re¸cu par
courriel un virus ayant pour effet de d´emarrer un serveur illicite (cheval de Troie), (3)
Chapitre 3. D´etection d’intrusions et analyse passive 81
step syn : tcp any any -> any any (flags :S ;)
step synack : tcp any any -> any any (flags :SA ;)
match : syn.sip=synack.dip ; syn.dip=synack.sip ;
syn.sport=synack.dport ; syn.dport=synack.sport ;
output : assert(port(syn.dip,syn.dport,"open")).
timeout : syn.timestamp+2sec ;
step ack : tcp any any -> any any (flags :A ;)
match : syn.sip=ack.sip ; syn.dip=ack.dip ; syn.sport=ack.sport ; syn.dport=ack.dport ;
output : assert(session(syn.sip,syn.dip,syn.sport,syn.dport)),
assert(session(syn.dip,syn.sip,syn.dport,syn.sport)).
timeout : synack.timestamp+2sec ;
output : assert(alert("syncan",syn.sip,syn.dip)).
Fig. 3.3 – Poign´ee de main TCP.
step syn : tcp any any -> any any (flags :S ;)
step rst : tcp any any -> any any (rst :R ;)
match : syn.sip=rst.dip ; syn.dip=rst.sip ; syn.sport=rst.dport ; syn.dport=rst.sport ;
output : assert(port(syn.dip,syn.dport,closed)).
timeout : syn.timestamp+2sec ;
Fig. 3.4 – Ports TCP ferm´es.
step fin : tcp any any -> any any (flags :F ;)
output : not(session(fin.sip,fin.dip,fin.sport,fin.dport)),
assert(alert("finscan",fin.sip)).
output : retract(session(fin.sip,fin.dip,fin.sport,fin.dport)).
step rst : tcp any any -> any any (flags :R ;)
output : retract(session(rst.sip,rst.dip,rst.sport,rst.dport)).
output : retract(session(rst.dip,rst.sip,rst.dport,rst.sport)).
Fig. 3.5 – Fermeture d’une session TCP.
Chapitre 3. D´etection d’intrusions et analyse passive 82
qu’un visiteur avec un ordinateur portable, en dehors de notre contrˆ ole, ne respecte pas
notre politique de s´ecurit´e.
Pour d´ecouvrir passivement quels sont les ports TCP ouverts sur nos hˆ otes, on n’a
qu’`a ´ecouter les demandes de connection. Lorsque les demandes sont accept´ees par le
serveur, on peut conclure que le port est ouvert. Ce n’est cependant qu’` a la troisi`eme
´etape de la connection, lors de la r´eception de confirmation, que l’on peut conclure que
r´eellement il y a une connection en cours. Dans le cas o` u cette confirmation n’a pas
lieu, il y a fortement lieu de penser qu’une attaque de type synscan est en cours.
`
A la
figure 3.3, on peut voir comment notre langage supporte ces techniques d’acquisition
d’information. On remarque que l’ajout, dans la base de connaissances, de l’attaque
synscan se fait apr`es l’´ecoulement du d´elai (timeout).
3.4.2 Ports TCP ferm´es
Pour d´etecter quels sont les ports TCP ferm´es, la technique est relativement sem-
blable `a celle utlis´ee pour les ports ouverts. Dans ce cas-ci, c’est cependant le RST, au
lieu du SYN-ACK, qui nous permettra de conclure. Le sc´enario correspondant `a cette
technique se trouve `a la figure 3.4.
3.4.3 Sessions ferm´ees et balayage FIN
Nous venons de montrer comment il est possible de d´etecter qu’une session est
active entre deux hˆotes. Pour la consid´erer comme ´etant termin´ee, il faut attendre
qu’un paquet FIN soit envoy´e par un des deux hˆotes. La connection sera alors ferm´ee
dans une direction, et il faudra attendre l’envoi d’un autre paquet FIN pour fermer
l’autre direction. Dans le cas o` u il n’y avait aucune connection active, il faut signaler
une alerte de finscan. En effet, la m´ethode de balayage FIN est encore plus subtile que
celles pr´ec´edemment mentionn´ees. Il s’agit d’envoyer un paquet de fin de connection
sans en avoir ´etablie auparavant. Le comportement normal d’un port ouvert est de ne
pas r´epondre, alors que celui d’un port ferm´e sera d’envoyer un paquet RST. Aussi, il
ne faut pas oublier que certaines connections peuvent aussi se terminer par un RST.
Dans ce cas, les deux sens de la connection sont ferm´es en mˆeme temps. Le sc´enario de
la figure 3.5 implante ces techniques d’acquisition.
Chapitre 3. D´etection d’intrusions et analyse passive 83
step syn : tcp any any -> any any (flags :S ; tcpopts :MTW)
step synack : tcp any any -> any any (flags :SA ; tcpopts :M ; ttl :64 ; window :12)
match : syn.sip=synack.dip ; syn.dip=synack.sip ;
syn.sport=synack.dport ; syn.dport=synack.sport ;
output :assert(os(syn.dip, "Free BSD 3.0")),
assert(os(syn.dip, "FreeBSD 3.1")),
...
assert(os(syn.dip, "FreeBSD 4.3")).
timeout : syn.timestamp + 2sec ;
Fig. 3.6 – D´etection d’un syst`eme d’exploitation FreeBSD 3.0 `a 4.3.
3.4.4 Vuln´erabilit´es et syst`emes d’exploitation
La prise en compte du contexte dans lequel survient une attaque permet de dimi-
nuer le nombre de faux-positifs g´en´er´es par un syst`eme de d´etection d’intrusions. Par
exemple, dans le cas de Snort, l’ajout du pr´eprocesseur Flow a permis de diminuer
le nombre de faux-positifs en sp´ecifiant que certains attaques doivent survenir dans
le contexte d’une session TCP active pour r´eussir. La prise en compte du contexte
peut cependant aller beaucoup plus loin que la simple v´erification des sessions TCP.
Par exemple, la plupart des attaques utilisent des vuln´erabilit´es connues de certains
syst`emes. La connaissance de la pr´esence ´eventuelle de ces vuln´erabilit´es peut alors per-
mettre de diminuer le nombre de faux-positifs en v´erifiant que le syst`eme attaqu´e est
bel et bien vuln´erable `a l’attaque identifi´ee.
La prise d’empreintes de syst`emes d’exploitation regroupe un ensemble de techniques
exploitant les diff´erences entre les diff´erentes implantations de la suite de protocoles
TCP/IP dans le but d’identifier le syst`eme d’exploitation des machines connect´ees `a un
r´eseau. Le logiciel nmap [71] utilise huit tests actifs (g´en´erant du trafic) diff´erents per-
mettant de diff´erencier plus de 500 syst`emes d’exploitation diff´erents. D’autres logiciels,
tels que POF [70] (pour Passive OS Fingerprinting) utilisent des tests comparables dans
un contexte passif (ne g´en´erant pas de trafic). Les tests utilis´es par POF fonctionnent
tous sur la base d’un unique paquet, ne profitant ainsi pas de l’information contextuelle
permettant d’effectuer une d´etection plus pr´ecise.
`
A la figure 3.6, on montre comment on peut d´etecter, `a l’aide du langage que nous
avons d´evelopp´e, un syst`eme d’exploitation FreeBSD. Cette signature a ´et´e r´edig´ee `a
partir d’une base de donn´ees de signatures [73] ayant ´et´e mise au point au Centre de
Recherches sur les Communications. La deuxi`eme ´etape du sc´enario (le SYN-ACK) est
Chapitre 3. D´etection d’intrusions et analyse passive 84
alert tcp any any -> any 21 (msg :"FTP EXPLOIT wu-ftpd 2.6.0 site
exec format string overflow FreeBSD" ; flow :to_server,established ;
content :"1|C0|PPP|B0| |CD 80|1|DB|1|C0|" ; reference :bugtraq,1387 ;sid :343 ;)
Fig. 3.7 – R`egle Snort num´ero 343.
step exploit : tcp any any -> any 21 (content :"1|C0|PPP|B0| |CD 80|1|DB|1|C0|" ;)
match : session(exploit.sip,exploit.dip,exploit.sport,exploit.dport) ;
os(exploit.dip, "Free BSD 4.3") ;
output :assert(alert("FTP EXPLOIT", exploit.sip, exploit.dip)).
Fig. 3.8 – R´eduction des faux-positifs `a l’aide de la d´etection de vuln´erabilit´es.
un paquet pouvant ˆetre envoy´e par 27 syst`emes d’exploitation diff´erents. Cependant,
lorsque le SYN-ACK est envoy´e en r´eponse au SYN correspondant `a la premi`ere ´etape,
seulement 11 des 27 syst`emes d’exploitation continuent d’envoyer ce SYN-ACK. Le
langage que nous avons d´evelopp´e permet donc une d´etection de syst`eme d’exploitation
plus pr´ecise que celle faite par les outils n’utilisant qu’un seul paquet.
`
A la figure 3.7, se trouve une version simplifi´ee d’une r`egle Snort permettant de
d´etecter une tentative d’exploiter une vuln´erabilit´e du serveur FTP de certaines versions
du syst`eme d’exploitation FreeBSD. Cette vuln´erabilit´e est r´ef´erenci´ee (entre autres) par
l’organisme Bugtraq [74] par le num´ero 1387. En consultant le site web de Bugtraq, on
peut savoir quelles sont les versions de FreeBSD qui sont vuln´erables `a cette attaque.
Il est alors possible, comme on le montre `a la figure 3.8, d’utiliser la connaissance
que nous avons du syst`eme d’exploitation de la machine attaqu´ee pour v´erifier s’il
est vraisemblable que l’attaque ait r´eussi. On voit aussi comment on peut replacer
l’utilisation du pr´eprocesseur Flow pour v´erifier la pr´esence d’une session TCP active.
3.4.5 Adresses du routeur
Lorsque l’on voit passer plusieurs paquets ayant la mˆeme adresse MAC source, mais
des adresses IP source diff´erentes, on peut conclure que l’hˆote ayant cette adresse MAC
agit comme routeur. Une fois que l’on connaˆıt l’adresse MAC du routeur, on peut d´e-
duire son adresse IP en regardant les r´eponses aux requˆetes ARP qui lui sont adress´ees.
Ces techniques sont illustr´ees `a la figure 3.9.
Chapitre 3. D´etection d’intrusions et analyse passive 85
step anyip1 : ip any any -> any any
step anyip2 : ip any any -> any any
match : anyip1.smac=anyip2.smac ; anyip1.sip !=anyip2.sip ;
timeout : anyip1.timestamp + 10sec ;
step anyip3 : ip any any -> any any
match : anyip1.smac=anyip3.smac ; anyip1.sip !=anyip3.sip ; anyip2.sip !=anyip3.sip ;
output : assert(gatewaymac(anyip1.smac)).
timeout : anyip2.timestamp + 10sec ;
step arpreply : arp any any -> any any (opcode=2 ;)
match : gatewaymac(arpreply.smac) ;
output : assert(gatewayip(arpreply.tprotoadr)).
Fig. 3.9 – Adresses du routeur.
step arpreply : arp (opcode=2 ;)
output : assert(macip(arpreply.thdradr,arpreply.tprotoadr)).
gatewayip(ip) :- macip(X,ip),gatewaymac(X).
Fig. 3.10 – Inf´erence de nouvelles connaissances.
3.4.6 Inf´erence de nouvelles connaissances
L’exemple que nous venons tout juste de voir est g´en´eralisable. On peut le formuler
ainsi : si on sait que la machine ayant l’adresse MAC X a la caract´eristique c, et que la
machine ayant l’adresse IP Y a l’adresse MAC X, alors la machine ayant l’adresse IP
Y a aussi la caract´eristique c. Il s’agit presque d’une lapalissade, mais dans un contexte
o` u l’on a besoin de rechercher de l’information `a partir de diff´erentes cl´es, comme c’est
le cas lorsque l’on doit utiliser le peu d’information qui se trouve dans un paquet donn´e,
il est souhaitable d’avoir le plus de transparence possible. C’est pourquoi, au lieu de
la r`egle que nous avons d´efinie ci-haut, il serait pr´ef´erable, par exemple, d’utliser les
r´eponses aux requˆetes ARP pour emmagasiner les associations entre les adresses IP et
les adresses MAC.
Par la suite, on peut d´efinir l’adresse IP d’un routeur comme ´etant une adresse IP
associ´ee `a l’adresse MAC d’un routeur. Cette inf´erence est faite au niveau de la base de
connaissances, et c’est pourquoi la derni`ere ligne de la figure 3.10 est ´ecrite en Prolog,
Chapitre 3. D´etection d’intrusions et analyse passive 86
et non dans notre langage de signatures. Cette signature consitue une version am´elior´ee
de la seconde signature pr´esent´ee `a la figure 3.9. En effet, la seconde signature de la
figure 3.9 implique que la d´etection de l’adresse MAC du routeur doit ˆetre faite avant
de d´etecter quelle est l’adresse IP lui ´etant associ´ee. Avec la signature de la figure 3.10,
l’ordre dans lequel les deux connaissances sont acquises n’a pas d’importance.
Cependant, on voit que cette r`egle d’inf´erence n’est pas encore assez g´en´erale, car il
faudrait la red´efinir pour chacun des types d’information. Comme on le voit, la struc-
turation et la repr´esentation de l’information `a acqu´erir, dans une optique o` u on veut
en inf´erer de nouvelles, est une ´etape tr`es importante et qui, en fait, constitue en soi un
d´efi s´erieux `a relever.
3.5 Pr´esentation formelle du langage
Maintenant que nous avons une meilleure intuition des objectifs poursuivis par le
langage que nous avons d´evelopp´e, nous allons voir comment il est possible d’en faire
une ´etude formelle `a l’aide des notions que nous avons vues au chapitre 1. Cette ´etude
nous permettra de mieux percevoir les limites de notre langage, et de le critiquer en
regard des crit`eres dont nous avons donn´e la liste `a la table 1.9. Quatre aspects du
langage seront donc trait´es dans cette section, soit le mod`ele sur lequel il travaille, sa
syntaxe, sa s´emantique, et son algorithme de v´erification.
3.5.1 Mod`ele
Le mod`ele sur lequel nous travaillons, celui d’une trace de trafic, est g´en´eralisable
`a celui de trace d’enregistrements. Il s’agit essentiellement du mˆeme mod`ele que celui
utilis´e par ASAX et LogWeaver. Le concept d’enregistrement se distingue de celui d’´etat,
utilis´e par exemple avec LTL, de par le fait qu’il permet d’associer des valeurs `a des
´etiquettes, et ainsi de comparer les valeurs associ´ees aux ´etiquettes de diff´erents ´etats.
Avec le concept d’´etat traditionnellement utilis´e, qui consiste en un sous-ensemble d’un
ensemble de constantes propositionnelles P, la comparaison entre les diff´erents ´etats se
fait beaucoup moins naturellement (bien que th´eoriquement possible).
Notre mod`ele se distingue cependant de ceux de ASAX et LogWeaver par deux
hypoth`eses importantes que nous faisons relativement au temps : (1) il est toujours
possible d’associer un temps `a un enregistrement donn´e, et (2) le temps est toujours
Chapitre 3. D´etection d’intrusions et analyse passive 87
i τ sip dip tcpsport tcpdport syn ack
0 2.0 192.168.0.100 192.168.0.101 45678 23 1 0
1 3.5 192.168.0.101 192.168.0.100 23 45678 1 1
2 4.9 192.168.0.100 192.168.0.101 45678 23 0 1
3 7.0 192.168.0.108 192.168.0.109 56789 21 1 0
4 7.5 192.168.0.109 192.168.0.108 21 56789 1 1
5 9.7 192.168.0.112 192.168.0.114 22 34567 0 0
. . . . . . . . . . . . . . . . . . . . . . . .
Fig. 3.11 – Exemple de trace.
croissant, c’est-`a-dire que les enregistrements se situent dans la trace dans le mˆeme
ordre que celui des ´ev´enements qu’ils repr´esentent. Ces id´ees se formalisent donc dans
la d´efinition suivante :
D´efinition 3.1 Un enregistrement est une fonction dont le domaine est un ensemble
d’´etiquettes, aussi appel´ees champs, et dont le codomaine est un ensemble de valeurs
num´eriques (par exemple N). Une de ces ´etiquettes, τ, repr´esente le temps. Une trace
σ est une suite infinie d’enregistrements. Par σ(i), on d´esigne le i
eme
enregistrement, et
par σ
i
, on d´esigne le suffixe de σ commen¸cant `a σ(i). Le temps est croissant, c’est-`a-dire
que ∀i.σ(i).τ < σ(i + 1).τ.
`
A la figure 3.11, on peut voir un exemple de trace. La premi`ere colonne repr´esente
l’index de l’enregistrement, la deuxi`eme le temps qui lui est associ´e, les quatre suivantes
les adresses et les ports source et destination, et les deux derni`eres repr´esentent les
drapeaux syn et ack. En r´ealit´e, un paquet peut contenir beaucoup plus de champs,
mais ceux-ci sont suffisants pour l’´etude des exemples qui suivent.
3.5.2 Syntaxe
La syntaxe abstraite de notre langage se trouve `a la table 3.2. La premi`ere partie
de la syntaxe permet d’exprimer des sc´enarios comme des s´equences d’´ev´enements. Le
sc´enario le plus simple est celui o` u il ne se passe rien de sp´ecial (tt). Le sc´enario
'id, φ`
t
ψ d´ebute par un paquet id ayant la caract´eristique φ, et se poursuit par le
sc´enario ψ. Le sc´enario ψ est celui o` u le sc´enario ψ ne survient pas, et le sc´enario
ψ
1
∧ψ
2
est celui o` u les sc´enarios ψ
1
et ψ
2
surviennent tous les deux. La deuxi`eme partie
de la syntaxe concerne les caract´eristiques propres `a un paquet. Il s’agit essentiellement
du calcul propositionnel, sauf que les constantes p (que nous appellerons d´esormais
Chapitre 3. D´etection d’intrusions et analyse passive 88
ψ ::= tt [ 'id, φ`
t
ψ [ ψ [ ψ
1
∧ ψ
2
(Formules pour traces)
φ ::= p [ φ [ φ
1
∧ φ
2
(Formules pour paquets)
t ::= id.τ + δ [ ∞ (D´elais)
Tab. 3.2 – Syntaxe.
expressions) peuvent, comme nous le verrons, contenir des variables faisant r´ef´erence aux
diff´erents champs des enregistrements consituant les sc´enarios. La troisi`eme partie de la
syntaxe permet d’exprimer des d´elais. Un d´elai peut ˆetre relatif `a un ´ev´enement id pass´e
(id.τ +δ), ou infini (∞). D’un point de vue expressivit´e, l’ajout de ces d´elais n’apporte
rien, car il aurait ´et´e possible de les repr´esenter par une expression p. Cependant,
comme ils jouent un rˆole crucial dans l’algorithme de v´erification en ligne que nous
pr´esenterons plus loin, nous avons jug´e bon de sp´ecifier ceux-ci au niveau mˆeme de
la syntaxe. Finalement, remarquons que les op´erateurs temporels que nous utilisons
constituent des cas particuliers de ceux utilis´es avec MTL.
'syn, φ
1
`

'synack, φ
2
`
syn.τ+2sec
'ack, φ
3
`
synack.τ+2sec
tt
avec
φ
1
:= snort(”tcp (flags :S;)”)
φ
2
:= snort(”tcp (flags :SA;)”) ∧syn.sip = synack.dip ∧ syn.dip = synack.sip
∧syn.sport = synack.dport ∧ syn.dport = synack.sport
φ
3
:= snort(”tcp (flags :A;)”) ∧syn.sip = ack.sip ∧ syn.dip = ack.dip
∧syn.sport = ack.sport ∧ syn.dport = ack.dport
Fig. 3.12 – Formule repr´esentant une poign´ee de main TCP.
`
A la figure 3.12, on peut voir comment le sc´enario repr´esentant une poign´ee de
main TCP, ´etudi´e plus tˆot dans le pr´esent chapitre, se traduit dans la syntaxe abstraite
du langage. Il s’agit d’une suite de trois enregistrements, dont les caract´eristiques sont
donn´ees par les formules φ
1
, φ
2
et φ
3
. La formule snort(sig) s’´evalue `a vrai pour σ(i) si et
seulement si l’engin de d´etection de Snort ´evalue `a vrai la signature sig dans le contexte
du paquet σ(i). On remarque que chacun des ´el´ements du sc´enario ont ´et´e traduits
dans la formule, exception faite des clauses output :.... Ceci est dˆ u au fait que la
s´emantique de cette partie des sc´enarios est de nature imp´erative, et non d´eclarative.
On la retrouvera donc au niveau de l’algorithme de v´erification du langage, mais elle
n’est pas directement traductible en logique temporelle.
Chapitre 3. D´etection d’intrusions et analyse passive 89
σ [= tt
σ [= 'id, φ`
t
ψ ssi ∃i.σ(i).τ <Eval(t) et Eval(φ[σ(i).n/id]) =vrai
et σ
i+1
[= ψ[σ(i).n/id]
σ [= ψ ssi σ [= ψ
σ [= ψ
1
∧ ψ
2
ssi σ [= ψ
1
et σ [= ψ
2
Eval(p) ∈ ¦vrai,faux¦
Eval(φ) = Eval(φ)
Eval (φ
1
∧ φ
2
) = Eval(φ
1
)∧Eval(φ
2
)
Tab. 3.3 – S´emantique.
3.5.3 S´emantique
La s´emantique du langage est donn´ee `a la table 3.3. Les quatres premi`eres r`egles
d´efinissent la r`egle de satisfiabilit´e qui pr´ecise quand est-ce qu’une trace σ satisfait une
formule ψ. Toute trace satisfait la formule tt. Une trace σ satisfait la formule 'id, φ`
t
ψ
si elle admet, avant que le d´elai t ne soit ´ecoul´e, un paquet σ(i) qui, une fois substitu´ees
toutes les occurrences de la variable id par σ(i).n (le nom de σ(i)) satisfait φ, et que le
reste de la trace `a partir de ce paquet, σ
i+1
, satisfait la formule ψ dans laquelle toutes
les occurrences de la variable id sont aussi substitu´ees par σ(i).n. Une trace satisfait la
formule ψ si elle ne satisfait pas la formule ψ. Elle satisfait la formule ψ
1
∧ ψ
2
si elle
satisfait `a la fois ψ
1
et ψ
2
.
Les trois derni`eres r`egles ´etendent la relation de satisfiabilit´e pour pr´eciser comment
´evaluer, `a l’aide de la fonction Eval, une formule de paquets φ. Le cas int´eressant est
celui d’une expression p. Comme cette expression contient des variables s’identifiant `a
des paquets, comme par exemple syn.sip = synack.dip, la fonction Eval substitue les
variables par les valeurs contenues dans le mod`ele, et ´evalue l’expression obtenue en
fonction des op´erateurs (par exemple, des op´erateurs de comparaison) de l’expression.
Les cas de la n´egation et de la conjonction se traitent comme d’habitude. L’´evaluation
de la n´egation d’une formule retourne la valeur oppos´ee de l’´evaluation de cette formule,
et l’´evaluation d’une conjonction de formules retourne la conjonction de l’´evaluation de
ces formules.
Par exemple, la trace montr´ee `a la figure 3.11 satisfait la formule de la figure 3.12
car, apr`es substitution de syn par σ(0), de synack par σ(1) et de ack par σ(2), les
formules de paquet φ
1
, φ
2
et φ
3
deviennent :
Chapitre 3. D´etection d’intrusions et analyse passive 90
φ
1
:= snort(”tcp (flags :S;)”)
φ
2
:= snort(”tcp (flags :SA;)”) ∧192.168.0.100 = 192.168.0.100
∧192.168.0.101 = 192.168.0.101 ∧ 45678 = 45678 ∧ 23 = 23
φ
3
:= snort(”tcp (flags :A;)”) ∧192.168.0.100 = 192.168.0.100
∧192.168.0.101 = 192.168.0.101 ∧ 45678 = 45678 ∧ 23 = 23
3.5.4 Algorithme
ψ ::= 'id, φ`
t
tt [ 'id, φ`
t
tt [ 'id, φ`
t
ψ (Formules pour traces)
φ ::= p [ φ [ φ
1
∧ φ
2
(Formules pour paquets)
t ::= id.τ + δ [ ∞ (D´elais)
Tab. 3.4 – Syntaxe du sous-ensemble associ´e au langage de signatures.
Le langage de sc´enarios que nous avons d´ecrit `a la section 3.2 ne permet pas de
repr´esenter toutes les formules du langage abstrait que nous venons de d´efinir. Plus
pr´ecis´ement, il permet seulement de repr´esenter le sous-ensemble engendr´e par la syn-
taxe de la table 3.4. Les deux sc´enarios de base sont ceux o` u un paquet donn´e survient
('id, φ`
t
tt) ou ne survient pas ('id, φ`
t
tt) avant un d´elai t donn´e. On compose en-
suite les sc´enarios plus complexes en leur ajoutant des ´etapes pr´ealables ('id, φ`
t
ψ). Il
n’est pas possible, `a l’aide du langage de sc´enarios, de repr´esenter une conjonction de
sc´enarios ou encore l’absence de toute une suite de paquets.
Les variables id correspondent aux ´el´ements 'id` du langage de sc´enarios identifiant
les diff´erentes ´etapes. Les formules de paquets φ correspondent aux clauses match. La
pr´esence d’une clause output apr`es une clause match indique que le sc´enario de base
utilis´e est la pr´esence d’un paquet ('id, φ`
t
tt), et la pr´esence d’une clause output apr`es
une clause timeout indique que le sc´enario de base utilis´e est l’absence d’un paquet
('id, φ`
t
tt). Les clauses output ne correspondent `a rien dans le langage abstrait.
Elles interviennent seulement au niveau de l’algorithme de v´erification, en nous disant
quelles sont les actions qui doivent ˆetre pos´ees lorsque l’occurrence d’un sc´enario donn´e
a ´et´e identifi´ee.
´
Etant donn´e un fichier contenant plusieurs signatures, nous g´en´erons
une sp´ecification. C’est cette sp´ecification que l’on donnera en entr´ee `a l’algorithme de
v´erification.
D´efinition 3.2 Une sp´ecification est un ensemble de couples de la forme 'ψ ⇒ act`,
o` u ψ est une formule engendr´ee par la syntaxe de la table 3.4, et act est une action
repr´esentant l’ajout ou le retrait d’une information dans la base de connaissances. Cette
action est pos´ee `a chaque fois que l’on se rend compte que ψ est satisfaite par la trace.
Chapitre 3. D´etection d’intrusions et analyse passive 91
'syn, φ
1
`

'synack, φ
2
`
syn.τ+2sec
tt
⇒ assert(port(syn.dip, syn.dport, ”open”))
'syn, φ
1
`

'synack, φ
2
`
syn.τ+2sec
'ack, φ
3
`
synack.τ+2sec
tt
⇒ assert(session(syn.sip, syn.dip, syn.sport, syn.dport)),
assert(session(syn.dip, syn.sip, syn.dport, syn.sport))
'syn, φ
1
`

'synack, φ
2
`
syn.τ+2sec
'ack, φ
3
`
synack.τ+2sec
tt
⇒ assert(alert(”syncan”, syn.sip, syn.dip))
avec
φ
1
:= snort(”tcp (flags :S;)”)
φ
2
:= snort(”tcp (flags :SA;)”) ∧syn.sip = synack.dip ∧ syn.dip = synack.sip
∧syn.sport = synack.dport ∧ syn.dport = synack.sport
φ
3
:= snort(”tcp (flags :A;)”) ∧syn.sip = ack.sip ∧ syn.dip = ack.dip
∧syn.sport = ack.sport ∧ syn.dport = ack.dport
Fig. 3.13 – Sp´ecification associ´ee au sc´enario d’une poign´ee de main TCP.
Il est `a noter qu’`a un sc´enario donn´e peuvent correspondre plusieurs couples 'ψ ⇒
act`. Par exemple, le sc´enario repr´esentant l’´etablissement d’une session TCP (figure 3.3,
page 81) donne les trois couples que nous pouvons voir `a la figure 3.13.
L’algorithme de v´erification, pour une trace et une sp´ecification donn´ees, est montr´e
`a la table 4.8. Les op´erateurs + et − repr´esentent l’ajout et le retrait d’un ´el´ement
d’un ensemble. L’ensemble k repr´esente la base de connaissances, et e l’ensemble des
sc´enarios `a reconnaˆıtre. Ce dernier ´evolue `a mesure que les pr´efixes des formules φ de
la sp´ecification originale sont reconnus.
Au d´ebut, le nombre de sc´enarios `a reconnaˆıtre est donc ´egal au nombre d’´el´ements
de la sp´ecification, mais comme la reconnaissance des enregistrements `a la tˆete des sc´e-
narios entraˆıne la duplication de ceux-ci (comme dans le cas des actions non-consuming
de STAT) la taille de l’ensemble augmente en cours de route. Les ´el´ements de e sont
cependant retir´es `a mesure que les d´elais sont ´ecoul´es (lignes 8, 12 et 16).
La substitution textuelle, `a mesure que les ´etapes sont reconnues, est appliqu´ee
non-seulement au reste de la formule, comme sp´ecifi´e par la s´emantique, mais aussi
aux actions `a prendre lors de la reconnaissance (lignes 9 et 13). Par exemple, l’action
assert(session(syn.sip, . . .) se transforme ainsi en assert(session(192.168.0.100, . . .).
`
A la figure 3.14, on peut voir un exemple de trace d’ex´ecution de l’algorithme dans
le cas ou la trace utilis´ee est celle de la figure 3.11 (page 87) et la sp´ecification est
Chapitre 3. D´etection d’intrusions et analyse passive 92
01.proc´edure verif(ψ, act, s, k, e)
02.entr´ees : ψ : une formule, act : une action `a prendre,
03. s : un enregistrement, k : la base de connaissances, e : un ensemble
04.sorties : k : la connaissance mise `a jour, e : l’ensemble des sc´enarios mis `a jour
05.d´ebut
06.selon la forme de φ :
07.cas 'id, φ`
t
tt :
08. si s.τ >Eval(t) alors e := e −'ψ ⇒ act`
09. sinon si Eval
k
(φ[s/id]) alors k := act[s/id](k)
10.cas 'id, φ`
t
tt :
11. si s.τ >Eval(t) alors
12. e := e −'ψ ⇒ act`
13. k := act(k)
14. sinon si Eval
k
(φ[s/id]) alors e := e −'ψ ⇒ act`
15.cas 'id, φ`
t
ψ
1
:
16. si s.τ >Eval(t) alors e := e −'ψ ⇒ act`
17. sinon si Eval
k
(φ[s/id]) alors e := e +'ψ
1
[s/id] ⇒ act[s/id]`
18.fin
19.
20.proc´edure moniteur(σ,spec)
21.entr´ees : σ : une trace, spec : une sp´ecification
22.sortie : k : la connaissance acquise `a partir de σ
23.d´ebut
24. k := ∅
25. e

:= ∅
26. pour chaque 'ψ ⇒ act` ∈ spec
27. e

:= e

+'ψ ⇒ act`
28. pour i allant de 0 `a [σ[
29. e := e

30. pour chaque 'ψ ⇒ act` ∈ e
31. verif(ψ, act, σ(i), k, e

)
32.fin
Tab. 3.5 – Algorithme de v´erification.
Chapitre 3. D´etection d’intrusions et analyse passive 93
i actions pos´ees [e[
0 6
1 assert(port(192.168.0.101, 23, ”open”)) 8
2 assert(session(192.168.0.100, 192.168.0.101, 45678, 23)), 4
assert(session(192.168.0.101, 192.168.0.100, 23, 45678))
3 6
4 assert(port(192.168.0.108, 21, ”open”)) 8
5 assert(alert(”syncan”, 192.168.0.108, 192.168.0.109)) 3
. . . . . . . . .
Fig. 3.14 – Exemple de trace d’ex´ecution de l’algorithme.
celle de la figure 3.13. Dans la colonne du centre sont affich´ees les actions pos´ees sur
la base de connaissances pendant le traitement de chaque paquet, et dans celle de
droite le nombre de sc´enarios en cours de reconnaissance. Au paquet 0, une demande de
connection TCP, ne provoque aucun changement sur la base de connaissances. Chacun
des sc´enarios est cependant dupliqu´e, en subsituant id
1
par σ(0). L’ensemble e contient
donc six ´el´ements. Lorsque, au paquet 1, la connection est accept´ee, on acqui`ere la
connaissance que le port 23 de la machine 192.168.0.101 est ouvert. Seulement deux
sc´enarios sont dupliqu´es, pour un total de 8. Au paquet 2, la connection est compl´et´ee
et la session est ouverte dans chacune des directions. Le d´elai des trois premiers sc´enarios
copi´es est ´ecoul´e, et ils sont donc retir´es de la base de l’ensemble e. De plus, la condition
pour un synscan ayant ´et´e viol´ee, la copie du sc´enario correspondant est aussi retir´ee.
Aucun sc´enario n’est dupliqu´e, on se retrouve donc avec un ensemble e de taille 4.
Le paquet 3 n’am`ene aucun changement sur la base de connaissances. Cependant, la
demande de connection fait en srte que les trois sc´enarios de base sont dupliqu´es. Le
d´elai du sc´enario de reconnaissance d’une poign´ee de main TCP pendant ´etant ´ecoul´e,
celui-ci est retir´e de e, qui se retrouve de nouveau avec 6 ´el´ements. Au paquet 4, la
connection est accept´ee. Deux sc´enarios sont ainsi dupliqu´es, et on apprend que le port
21 de la machine 192.168.0.109 est ouvert. Au paquet 5, tous les d´elais sont ´ecoul´es. On
apprend ainsi qu’une attaque de type synscan vient d’avoir lieu. Aucun sc´enario n’est
dupliqu´e.
Nous terminons cette section par la formulation et la d´emonstration du th´eor`eme
de validit´e de l’algorithme de v´erification. Par version de act, nous entendons l’action
act `a laquelle l’op´erateur de substitution textuelle peut avoir ´et´e appliqu´e.
Chapitre 3. D´etection d’intrusions et analyse passive 94
Th´eor`eme 3.3 (Validit´e de l’algorithme de v´erification) Si pour toute expression
p et pour toutes bases de connaissances k
1
et k
2
, Eval
k
1
(p) = Eval
k
2
(p), alors, pour tout
couple 'ψ, act` d’une sp´ecification donn´ee, σ [= ψ si et seulement si lors du traitement
(appel de la proc´edure verif) d’un certain σ(i), l’action act (ou une de ses versions) est
commise.
La condition Eval
k
1
(p) = Eval
k
2
(p) provient du fait que l’´evaluation d’une expres-
sion p peut d´ependre du contenu de la base de connaissances. Comme nous n’avons
pas tenu compte de la base de connaissances dans la d´efinition de la syntaxe et de la
s´emantique abstraites du langage, nous devons ´enoncer le th´eor`eme de validit´e comme
si celle-ci n’avait aucun effet sur l’ex´ecution de l’algorithme. Si pour toute expression p
et pour toutes bases de connaissances k
1
et k
2
, Eval
k
1
(p) = Eval
k
2
(p), alors l’expression
Eval(p) est bien d´efinie. On peut maintenant passer `a la d´emonstration du th´eor`eme.
D´emonstration :
On proc`ede par induction sur la forme de φ :
cas 'id, φ`
t
tt :
⇒Supposons que ∃i.σ(i).τ <Eval(t) et [= φ[σ(i)/id]. Alors, par l’hypoth`ese de crois-
sance pos´ee sur le mod`ele, act est commise (ligne 9) avant que le couple 'ψ ⇒ act` ne
soit retir´e de e (ligne 8).
⇐R´eciproquement, si il n’existe pas de tel j, le couple 'φ ⇒ act` est retir´e de e (ligne 8)
sans que act ne soit commise (ligne 9).
cas 'id, φ`
t
tt :
⇒Supposons que i.σ(i).τ <Eval(t) et Eval(φ[σ(i)/id]). Encore une fois, par l’hypo-
th`ese de croissance, act sera commise (ligne 13) avant que le couple 'ψ ⇒ act` ne soit
retir´e de e (ligne 14).
⇐Si, au contraire, il existe un tel i, alors la ligne 13 est ex´ecut´ee avant la ligne 14.
L’action act ne sera donc pas commise.
cas 'id, φ`
t
ψ :
⇒Supposons que ∃i.σ(j).τ <Eval(t) et Eval(φ[σ(i)/id]) = vrai et σ(i +1) [= φ[σ(j)/id].
Alors, comme dans les autres cas, la ligne 17 sera ex´ecut´ee avant la ligne 16. L’hypoth`ese
Chapitre 3. D´etection d’intrusions et analyse passive 95
d’induction termine le travail.
⇐ Deux cas sont possibles. Soit que ∃i.σ(i).τ <Eval(t) et Eval(φ[σ(i)/id]) = vrai, soit
qu’un tel i existe, mais que σ(i+1) [= ψ[σ(i)/id]. Dans le premier cas, la ligne 16 est ex´e-
cut´ee avant la ligne 17, et dans le second cas, c’est l’hypoth`ese d’induction qui entre en
jeu, ce qui termine la d´emonstration.
3.6 Conclusion
Dans ce chapitre, nous avons vu comment il est possible d’am´eliorer la structure lo-
gicielle et le langage de signatures d’un syst`eme de d´etection d’intrusions tel que Snort
de fa¸con `a ajouter la possibilit´e de reconnaˆıtre des sc´enarios d’attaque se d´eroulant
sur plusieurs paquets et `a pouvoir passivement acqu´erir de l’information. L’information
acquise peut ˆetre, en retour, utilis´ee par le syst`eme de d´etection d’intrusions pour ef-
fectuer une d´etection plus pr´ecise (moins de faux positifs, et moins de faux n´egatifs).
Elle peut aussi ˆetre consult´ee directement par l’administrateur r´eseau en cas de besoin.
Avec le langage actuel de Snort, la reconnaissance de sc´enarios impliquant plusieurs
paquets et l’acquisition passive d’information sont deux tˆ aches impossibles, et doivent
ˆetre effectu´ees par programmation au niveau des pr´eprocesseurs.
Un d´esavantage majeur, comparativement `a Snort, est le temps de traitement d’une
trace et la quantit´e de m´emoire utilis´ee. Avec son algorithme de reconnaissance de
patrons relativement simple, fonctionnant sur la base d’un seul paquet, Snort travaille
en temps lin´eaire en fonction de la taille de la trace et l’utilisation de la m´emoire est
pratiquement constante. Notre algorithme de reconnaissance de sc´enarios pr´esente le
mˆeme inconv´enient que ceux de LogWeaver, Chronicles, Eagle, STAT, IDIOT et ASAX :
la reconnaissance d’´etapes d’un sc´enario engendre (dans certain cas) une duplication de
celui-ci, et le nombre de sc´enarios en cours de reconnaissance peut donc, dans les cas
pathologiques, augmenter exponentiellement avec la taille de la trace (doubler `a chaque
paquet ou enregistrement).
Le langage de signatures que nous avons propos´e est bas´e sur une logique temporelle
avec des op´erateurs temporels futurs. Comme l’ont fait les concepteurs de LogWeaver,
nous avons seulement conserv´e l’op´erateur ♦, laissant ainsi tomber
U
et (. Une diff´e-
rence importante entre notre logique et celle de LogWeaver est que nous avons restreint,
comme le proposaient les auteurs, la syntaxe aux sc´enarios purement lin´eaires, c’est-` a-
dire ceux de la forme ♦p
1
(∧♦p
2
(∧♦p
3
(∧. . .))). Cette restriction pr´esente l’avantage de
simplifier l’algorithme de v´erification, tout en offrant suffisamment d’expressivit´e pour
Chapitre 3. D´etection d’intrusions et analyse passive 96
les besoins li´es `a la d´etection d’intrusions. Nous avons cependant laiss´e la possibilit´e
d’exprimer le fait qu’il s’´ecoule, une fois une certaine suite d’´ev´enements reconnue, un
certain d´elai (de longueur finie) durant lequel un ´ev´enement donn´e ne survient pas.
Le fait de pouvoir exprimer la non-occurence d’un ´ev´enement donn´e durant un certain
laps de temps est un besoin courant en d´etection d’intrusions auquel il ´etait possible de
subvenir `a moindre coˆ ut. Dans un mˆeme ordre d’id´ees, une autre diff´erence avec Log-
Weaver est le statut particulier que nous avons donn´e au temps. Nous avons travaill´e
sous l’hypoth`ese qu’`a chaque ´ev´enement il ´etait possible d’associer un temps et que ces
temps sont croissants suivant le fichier d’audit (ou la trace de trafic).
Un manque important au niveau de l’expressivit´e du langage de signatures est l’im-
possibilit´e de sp´ecifier simplement des comportements r´ep´etitifs tels que, par exemple,
ceux associ´es `a des attaques de balayage. Toutes les r´ep´etitions doivent ˆetre sp´ecifi´ees
une `a une, et si, par exemple, le nombre de tentatives de connections TCP `a observer
avant de conclure `a une attaque de balayage est 50, on doit sp´ecifier un sc´enario de 50
´etapes. Si on exige, de plus, que les ports destinations soient diff´erents pour chacune
des tentatives de connection, le nombre total d’expressions de la forme port
1
= port
2
sera de l’ordre de 50
2
/2 = 1250.
De plus, outre les inconv´enients d´ej`a cit´es, se trouvent aussi ceux reli´es au choix d’une
suite d’enregistrements comme mod`ele de trace. Bien que ce choix de mod`ele pr´esente
l’avantage, comparativement au mod`ele propositionnel, de permettre de comparer les
diff´erents ´ev´enements entre eux, il ne refl`ete cependant pas ad´equatement, comme nous
l’avons d´ej` a remarqu´e pour ASAX et LogWeaver, le fait que certains champs peuvent
ˆetre absents de certains enregistrements ou encore avoir des valeurs multiples.
Finalement, notre architecture `a deux niveaux, logique temporelle pour exprimer
les sc´enarios et base de connaissances pour stocker les connaissances et en d´eduire de
nouvelles, nous am`ene `a faire les mˆemes reproches que nous avons faits `a STAT, IDIOT,
BSML et P-BEST quand `a la nature d´eclarative du langage. Les clauses output sont
de nature clairement imp´erative, et c’est pourquoi nous n’en avons pas tenu compte
dans notre pr´esentation formelle du langage. En y pensant bien, le rˆole de la base de
connaissances est entre autres de servir de m´emoire pour les sc´enarios ayant d´ej`a ´et´e
reconnus. Elle sert donc `a regarder ce qui s’est pass´e avant. Au chapitre suivant, nous
verrons comment l’utilisation d’op´erateurs temporels pass´es permet d’arriver `a un lan-
gage purement d´eclaratif, et ainsi de faire abstraction, du point de vue du langage de
signatures, de la base de connaissances. Nous verrons aussi comment l’introduction de
l’unification, de mˆeme que des tableaux et des op´erateurs d’approximants (une ver-
sion faible des op´erateurs de points fixes) permet de r´egler la plupart des probl`emes
mentionn´es tout en conservant les avantages acquis.
Chapitre 4
Logique d’acquisition de
connaissances
Dans le chapitre pr´ec´edent, nous avons vu comment il est possible de d´efinir et de
d´etecter des sc´enarios d’attaque complexes en utilisant un langage de signatures bas´e
sur une logique temporelle future. Nous avons aussi vu comment, lors de l’implantation,
il est possible d’utiliser une base de connaissances afin d’acqu´erir passivement de l’infor-
mation sur le r´eseau et ainsi d’am´eliorer la d´etection d’intrusions. L’ajout de cette base
de connaissances impliquait cependant de faire un compromis sur la nature d´eclarative
du langage de d´etection, en ajoutant des clauses output correspondant `a des actions `a
prendre lors de la d´etection de certains sc´enarios ou certaines parties de sc´enarios. Dans
la section 4.1, nous verrons comment l’op´erateur temporel pass´e
S
permet de rendre
purement d´eclaratif le langage de signatures et ainsi de faire abstraction de la base de
connaissances. Mieux encore, nous verrons qu’avec cet op´erateur, l’utilisation de l’op´e-
rateur devient superflue. Dans la section 4.2, nous verrons comment l’introduction de
l’unification permet de r´egler le probl`eme des champs absents ou `a valeurs multiples.
Dans la section 4.3, nous verrons comment l’introduction de tableaux, de mˆeme que
d’op´erateurs d’approximants, permet d’exprimer de fa¸con concise des sc´enarios `a com-
portement r´ep´etitif. Finalement, dans la section 4.4, nous pr´esenterons l’algorithme de
v´erification en ligne pour la logique d´evelopp´ee dans ce chapitre et le d´emontrerons
comme ´etant complet et coh´erent.
Chapitre 4. Logique d’acquisition de connaissances 98
4.1 Un paradigme pass´e
Au chapitre pr´ec´edent, nous avons vu comment il est possible d’utiliser une logique
temporelle future pour exprimer des sc´enarios d’attaque se d´eroulant sur plusieurs pa-
quets. L’utilisation d’op´erateurs temporels futurs comporte cependant un inconv´enient
majeur en ce qui regarde la v´erification en ligne : comme nous ne savons jamais ce que
l’avenir nous r´eserve, nous sommes pratiquement toujours face `a une formule en cours
de v´erification, ce qui nous am`ene, au niveau de l’algorithme, `a construire des ensembles
de formules partiellement satisfaites et `a tenir `a jour ces ensembles du mieux que l’on
peut. De plus, `a mesure que les sc´enarios ´evoluent, nous devons dupliquer les sc´enarios
(lignes 17 et 20 de l’algorithme de la table 4.8, page 120), utilisant ainsi une quantit´e
de m´emoire sans cesse grandissante. Un autre inconv´enient de l’utilisation d’op´erateurs
temporels futurs dans un contexte de v´erification en ligne r´eside au niveau de la s´e-
mantique donn´ee `a ces op´erateurs et de la d´ecidabilit´e des formules exprimables. Que
penser, par exemple, de la d´ecidabilit´e de la formule p, qui dit qu’` a un certain mo-
ment dans le futur, la proposition p doit ˆetre satisfaite ? Si, effectivement, p survient,
on peut affirmer que p est satisfaite, mais tant qu’elle ne survient pas, on ne peut rien
dire. De ce point de vue, la formule p est donc ind´ecidable dans un contexte en ligne
(`a moins de travailler sous l’hypoth`ese que les traces sont finies, comme l’ont fait les
auteurs de [31]). Au chapitre pr´ec´edent, nous avons contourn´e le probl`eme en utilisant
l’op´erateur
t
p, permettant de sp´ecifier que p doit survenir avant que le d´elai t ne se
soit ´ecoul´e. Nous avons cependant ´et´e oblig´es de permettre que, au moins `a la premi`ere
´etape, le d´elai t soit de valeur infinie afin que la v´erification puisse toujours continuer.
Par exemple, pour exprimer que il ne doit pas y avoir de p suivi, dans les 2 secondes,
d’un q, on doit utiliser la formule

(p∧
2
q). Cette permission sp´eciale laisse un bien
mauvais arri`ere goˆ ut et nous aimerions bien ˆetre capables de nous en sortir autrement.
Ces probl`emes, engendr´es par l’utilisation d’op´erateurs futurs, se r´esolvent tous en
utilisant des op´erateurs temporels pass´es. De plus, l’utilisation de l’op´erateur
S
, plutˆot
que de l’op´erateur , permet de r´esoudre les probl`emes li´es `a l’utilisation imp´erative
de la base de connaissances. En fait, plutˆot que d’utiliser tel quel l’op´erateur
S
, nous
utiliserons la construction [φ
1
, φ
2
] qui, par d´efinition, est ´equivalente `a φ
2 S
φ
1

1
a
´et´e vraie dans le pass´e, et φ
2
n’a pas ´et´e vraie depuis).
Dans cette section, la pr´esentation que nous donnons de la logique temporelle que
nous proposons d’utiliser pour le langage de signatures se borne au mod`ele proposition-
nel. Le passage au premier ordre se fera `a la section suivante.
Chapitre 4. Logique d’acquisition de connaissances 99
φ ::= p [ φ [ φ
1
∧ φ
2
[ [φ
1
, φ
2
]
Tab. 4.1 – Syntaxe pour le cas propositionnel.
4.1.1 Mod`ele
Pour le cas propositionnel, le mod`ele `a utiliser est des plus conventionnels :
D´efinition 4.1 (Trace)
´
Etant donn´e un ensemble P de constantes propositionnelles,
un ´ev´enement (ou un ´etat) est un sous-ensemble de P. Une trace, habituellement not´ee
σ, est une suite, finie ou infinie, d’´ev´enements. Par σ(i), on d´enote le i
eme
´ev´enement
de la trace.
4.1.2 Syntaxe
La syntaxe de la logique est pr´esent´ee `a la table 4.1. Le seul op´erateur temporel
qu’elle comporte est l’op´erateur [φ
1
, φ
2
], utilis´e pour repr´esenter des connaissances qui
ne sont vraies que pour une certaine p´eriode de temps. Cette p´eriode est caract´eris´ee par
son d´ebut (φ
1
) et par sa fin (φ
2
). La formule [φ
1
, φ
2
] doit donc ˆetre interpr´et´ee comme
´etant vraie entre φ
1
et φ
2
. Si φ
2
n’est jamais vraie, alors [φ
1
, φ
2
] est vraie `a partir du
moment o` u φ
1
est vraie.
Un cas particulier important est celui de [φ
1
, ff], o` u ff est d´efinie comme ´etant une
constante propositionnelle qui n’est jamais vraie. La formule [φ
1
, ff] doit donc ˆetre com-
prise comme φ
1
a d´ej`a ´et´e vraie. Il est alors possible de sp´ecifier des s´equences d’´ev´ene-
ments, en utilisant des formules de la forme r ∧ [q ∧ [p, ff], ff]. Cette formule sera vraie
aux ´ev´enements pour lesquels non-seulement r est vraie, mais aussi q a d´ej` a ´et´e vraie,
et avant cela p. Elle sp´ecifie donc la s´equence p −q −r.
HandShake := ack ∧ [synack ∧ [syn, ff], ff]
Session := [HandShake, fin ∨ rst]
V alidAttack := Attack ∧ Session
Fig. 4.1 – Attaque dans le contexte d’une session TCP active.
Chapitre 4. Logique d’acquisition de connaissances 100
σ(i) [=
σ
p ssi p ∈ σ(i)
σ(i) [=
σ
φ ssi σ [=
σ
φ
σ(i) [=
σ
φ
1
∧ φ
2
ssi σ(i) [=
σ
φ
1
et σ(i) [=
σ
φ
2
σ(i) [=
σ

1
, φ
2
] ssi ∃j.j < i et σ(j) [=
σ
φ
1
et ∃k.j < k < i.σ(k) [=
σ
φ
2
Tab. 4.2 – S´emantique pour le cas propositionnel.
`
A la figure 4.1, on voit comment un tel s´equencement peut ˆetre utilis´e pour sp´ecifier
une poign´ee de main TCP. La formule doit se lire de l’int´erieur vers l’ext´erieur. Le
premier ´ev´enement qui doit survenir est un paquet syn. Une fois que l’on a vu ce paquet
syn, on doit voir un paquet synack. La poign´ee de main n’est compl´et´ee que lorsque le
dernier acquiescement, ack, est envoy´e. La deuxi`eme formule montre comment on peut
utiliser cette poign´ee de main pour sp´ecifier une session TCP active. Elle dit qu’une
session TCP est active `a partir du moment o` u la poign´ee de main est compl´et´ee, jusqu’au
moment o` u on voit passer un paquet fin ou un paquet rst. Finalement, on peut utiliser
cette information pour valider l’occurrence d’une attaque donn´ee survenant au-dessus
de TCP, comme le fait le pr´eprocesseur Flow de Snort. Si la formule Attack repr´esente la
compl´etion d’une attaque au-dessus de TCP, alors la formule Attack ∧Session signifie
qu’une poign´ee de main doit avoir ´et´e compl´et´ee avant que l’attaque n’ait ´et´e observ´ee,
et que la session ne doit pas avoir ´et´e close par un paquet rst ou un paquet fin.
4.1.3 S´emantique
La s´emantique de la logique propos´ee, pour le cas propositionnel, est pr´esent´ee `a
la table 4.2. Elle dit comment, ´etant donn´e un ´etat σ(i) appartenant `a une trace σ,
doivent ˆetre ´evalu´ees les formules. La premi`ere ligne, comme d’habitude, dit que σ(i)
satisfait une constante propositionnelle p ssi p appartient `a σ(i) (on se souvient que, par
d´efinition, un ´ev´enement est un ensemble de constantes propositionnelles). La deuxi`eme
ligne dit que σ(i) satisfait la n´egation d’une formule ssi celle-ci n’est pas satisfaite par
σ(i). La troisi`eme ligne dit que σ(i) satisfait une conjonction de formules ssi σ(i) satisfait
les deux propositions conjointes. La quatri`eme ligne, la plus importante, dit que σ(i)
satisfait [φ
1
, φ
2
] ssi φ
1
a ´et´e satisfaite par un ´ev´enement pr´ec´edent σ(i), et qu’aucun
autre ´ev´enement n’a satisfait φ
2
depuis.
Remarquons que la relation de satisfaction n’est d´efinie que pour les diff´erents ´etats
de la trace, et non pour la trace au complet. Informellement, nous pouvons dire qu’une
trace satisfait une formule si et seulement si tous ses ´etats la satisfont. Cependant, ´etant
Chapitre 4. Logique d’acquisition de connaissances 101
donn´e le probl`eme auquel nous nous attaquons, le fait de savoir si une trace satisfait ou
non une formule ne pr´esente que peu d’int´erˆet. Ce qui nous int´eresse vraiment, c’est de
savoir quels sont les paquets (´etats) qui doivent ˆetre consid´er´es comme offensifs. C’est
pourquoi la s´emantique est d´efinie par rapport `a ces derniers plutˆot que par rapport `a
la trace au complet.
Aux figures 4.2 et 4.3, se trouve un exemple de relation de satisfaction pour la
formule Session d´efinie `a la figure 4.1. Les lignes repr´esentent les ´ev´enements de la
trace, et les colonnes les formules.
`
A la figure 4.2, se trouvent les diff´erentes constantes
propositionnelles (constituant la trace), et `a la figure 4.3, les formules compos´ees. Le
symbole

indique que la formule `a la tˆete de la colonne est satisfaite par l’´ev´enement i.
i syn synack ack fin rst
0

1

2

3
4
5

6
. . . . . . . . . . . . . . . . . .
Fig. 4.2 – Exemple de trace pour le cas propositionnel.
i [syn, ff] [synack ∧ [syn, ff], ff] HandShake Session
0
1

2
√ √
3

4

5

6
. . . . . . . . . . . . . . .
Fig. 4.3 – Exemple de relations de satisfaction pour le cas propositionnel.
Chapitre 4. Logique d’acquisition de connaissances 102
i p(x, y) q(v)
0 p(2, 3) q(3)
p(2, 4) q(0)
1 p(5, 4)
2
. . . . . . . . .
Fig. 4.4 – Exemple de trace du premier ordre.
4.2 Unification
Dans la section pr´ec´edente, nous avons pr´esent´e une version propositionnelle de la
logique que nous proposons d’utiliser pour sp´ecifier les sc´enarios d’attaque et d’acqui-
sition d’information. Comme nous l’avons d´ej`a dit, une logique propositionnelle est, en
g´en´eral, insuffisante pour exprimer des sc´enarios d’attaque car elle ne permet pas de
comparer les ´ev´enements (ou les paquets, dans le cas d’une trace de trafic) entre eux.
Il est cependant int´eressant, avant de passer `a l’´etude du cas du premier ordre, de
remarquer ce que les programmeurs de Snort ont r´ecemment fait avec le module de
d´etection flowbits. Il s’agit d’un module permettant de d´efinir, pour chaque flot TCP,
un ensemble de drapeaux qui peuvent ˆetre soit vrais, soit faux. Il est alors possible de
sp´ecifier, lors de la reconnaissance d’une signature donn´ee, des actions `a prendre sur
les valeurs des drapeaux. Explicitement, dans la version 2.1.2 de Snort, il est possible
de prendre les actions set, unset et toggle, donnant respectivement aux drapeaux
la valeur vrai, faux, et contraire de celle actuelle. Les mots-cl´es isset et isnotset
permettent, par la suite, de v´erifier les valeurs attribu´ees aux drapeaux. Bien que sim-
pliste en apparence, ce m´ecanisme donne `a Snort exactement la mˆeme expressivit´e que
le cas propositionnel de la logique que nous proposons. La formule φ
1
correspond `a la
signature donnant la valeur vrai au drapeau (set), et la formule φ
2
`a celle lui donnant
la valeur faux (unset). La formule [φ
1
, φ
2
] est donc vraie si et seulement si le drapeau
correspondant a la valeur vrai. Ce qu’il faut conclure de cette observation est le fait
suivant : lorsque des hypoth`eses sont faites sur les relations entre les ´ev´enements (par
exemple, appartenir au mˆeme flot TCP), le cas propositionnel peut tout de mˆeme se
r´ev´eler d’une certaine utilit´e.
Chapitre 4. Logique d’acquisition de connaissances 103
φ ::= p(x
1
, . . . , x
n
) [ φ
1
[ φ
1
∧ φ
2
[ [φ
1
, φ
2
]
Tab. 4.3 – Syntaxe pour le cas du premier ordre.
4.2.1 Mod`ele
Au chapitre pr´ec´edent, nous avons remarqu´e que le mod`ele consistant en une suite
d’enregistrements est insuffisant pour les besoins de la d´etection d’intrusions. En fait,
le probl`eme est le suivant : ´etant donn´e un pr´edicat p(x), le mod`ele d’enregistrements
nous force `a consid´erer qu’il existe une et une seule valeur de x telle que p(x) est vraie,
alors qu’en r´ealit´e, il peut n’y en avoir aucune ou plusieurs. C’est pour rem´edier `a ce
probl`eme que nous introduisons la notion d’unification au coeur mˆeme du mod`ele et de
la s´emantique.
D´efinition 4.2 (Trace)
´
Etant donn´es P, un ensemble de pr´edicats du premier ordre,
et V , un ensemble de valeurs, un ´ev´enement est une fonction associant `a chaque pr´e-
dicat p(x
1
, . . . , x
n
) un sous-ensemble de V
n
(c’est-`a-dire un ensemble de n-tuples `a
valeurs dans V ). Une trace, habituellement not´ee σ, est une suite, finie ou infinie,
d’´ev´enements. Par σ(i), on d´enote le i
eme
´ev´enement de la trace.
Par abus de langage, si le tuple 'v
1
, . . . , v
n
` fait partie de l’ensemble associ´e `a
p(x
1
, . . . , x
n
) par σ(i), nous dirons parfois que p(v
1
, . . . , v
n
) est dans σ(i).
`
A la figure 4.4,
on peut voir un exemple de trace selon cette nouvelle d´efinition.
`
A chacun des ´ev´ene-
ments de la trace, chacun des pr´edicats peut ˆetre vrai pour un nombre ind´etermin´e de
tuples. Par exemple, `a l’´ev´enement 0, le pr´edicat p(x, y) est vrai pour deux tuples, `a
l’´ev´enement 1, il est vrai pour un seul tuple, et `a l’´ev´enement 2, il n’est vrai pour aucun
tuple.
4.2.2 Syntaxe
La syntaxe de la logique avec pr´edicats du premier ordre se trouve `a la table 4.3. Il
s’agit essentiellement de la mˆeme syntaxe que dans le cas propositionnel, sauf qu’au lieu
d’une constante propositionnelle p, on retrouve un pr´edicat du premier ordre p(x
1
, . . . , x
n
).
La suppression de la notion d’enregistrement nous lib`ere du mˆeme coup du besoin
d’utiliser une variable id pour r´ef´erer aux diff´erents champs d’un ´ev´enement. Tout se fait
Chapitre 4. Logique d’acquisition de connaissances 104
maintenant par unification. Par exemple, dans le cas de la formule [p(s, t)∧q(t), p(5, t)],
la variable t est unifi´ee lors de l’´ev´enement satisfaisant la sous-formule p(s, t) ∧ q(t).
Pour satisfaire l’autre sous-formule, p(5, t), on doit attendre de voir un ´ev´enement per-
mettant d’associer la mˆeme valeur `a la variable t.
La notion de d´elai, dans le cadre de cette logique, s’introduit comme au chapitre
pr´ec´edent, avec l’utilisation d’un pr´edicat τ(x). Cependant, comme l’algorithme de v´e-
rification que nous pr´esenterons n’utilise pas explicitement les temps associ´es aux ´ev´e-
nements, et que ceux-ci ne sont pas non-plus utilis´es dans la s´emantique, l’hypoth`ese de
croissance n’est ici plus n´ecessaire. Elle le sera cependant lorsque viendra le temps de
s’assurer que les sp´ecifications que l’on r´edige expriment bien ce que l’on veut exprimer.
Remarquons enfin que mˆeme l’existence du temps n’est plus n´ecessaire pour que les
algorithmes que nous pr´esenterons fonctionnent et que la th´eorie que nous d´eveloppons
soit utile.
La formule τ(x) signifie donc que l’´ev´enement courant est survenu au temps x. Alors,
la formule [φ ∧ τ(x
1
), τ(x
2
) ∧ x
2
− x
1
> δ] est vraie pour une p´eriode de δ unit´es de
temps apr`es que φ ait ´et´e vraie. Cette formule ´etant souvent utilis´ee, nous l’abr´egerons
par
[φ, δ].
La formule q ∧ [p, 3] est donc vraie pour les ´ev´enements o` u q est vraie apr`es que p ait
´et´e vraie, et que la p´eriode entre les deux n’est pas plus longue que 3 unit´es de temps.
`
A la figure 4.5, on montre comment on peut utiliser cette fa¸con de sp´ecifier des
d´elais pour donner une meilleure sp´ecification d’une poign´ee de main TCP que celle
de la figure 4.1. Un probl`eme important avec cette sp´ecification est qu’elle permet aux
trois ´etapes d’ˆetre arbitrairement s´epar´ees dans le temps. Par exemple, le ack pourrait
survenir une heure apr`es le synack. En pratique, on sait que le syst`eme d’exploitation de
la machine ayant ´emis le synack aurait abandonn´e l’attente du ack depuis longtemps,
et que le fait de consid´erer la poign´ee de main comme ´etant r´eussie serait alors une
erreur. De plus, comme nous l’avons d´ej` a dit, si cet acquiescement ne survient toujours
pas apr`es une p´eriode de temps raisonnable, il y a lieu de penser que le paquet syn ´etait
falsifi´e [7] et qu’une attaque de balayage est en cours.
De fa¸con g´en´erale, la formule exprimant le fait que si une formule φ
1
vient `a ˆetre
vraie, alors une autre formule φ
2
doit ˆetre vraie dans un d´elai de δ unit´es de temps est
la suivante :

1
∧ τ(x
1
), ff] ∧ τ(x
2
) ∧ x
2
−x
1
> δ ⇒ [φ
2
∧ τ(x
3
), ff] ∧ x
3
−x
1
< δ
Elle dit que si φ
1
a ´et´e vraie `a plus de δ unit´es de temps dans le pass´e, alors, durant la
Chapitre 4. Logique d’acquisition de connaissances 105
tcpFlow(sa,sp,da,dp) :=
ip.sadr(sa) ∧ tcp.sport(sp) ∧ ip.dadr(da) ∧ tcp.dport(dp)
handShake(sa,sp,da,dp) :=
ack ∧ tcpFlow(sa,sp,da,dp) ∧
[synack ∧ tcpFlow(da,dp,sa,sp) ∧
[syn ∧ tcpFlow(sa,sp,da,dp),
3sec],
2sec]
sessionClosing(sa,sp,da,dp) :=
(fin ∨ rst) ∧ (tcpFlow(sa,sp,da,dp) ∨ tcpFlow(da,dp,sa,sp))
session(sa,sp,da,dp) :=
[handShake(sa,sp,da,dp),
sessionClosing(sa,sp,da,dp)]
Fig. 4.5 – Suivi des sessions TCP.
p´eriode de δ unit´es de temps suivant le moment o` u φ
1
a ´et´e vraie, φ
2
doit avoir ´et´e vraie.
´
Etant donn´e que cette formule peut ˆetre un peu lourde `a utiliser, nous l’abr´egerons par
un nouvel op´erateur d´efini, not´e
φ
1
δ
→φ
2
,
dont la d´efinition est exactement la formule ci-haut. Il est alors possible d’utiliser cet
op´erateur pour sp´ecifier, par exemple, que lorsque les deux premi`eres ´etapes d’une
poign´ee de main TCP ont ´et´e observ´ees, la troisi`eme doit suivre dans un d´elai de 2
unit´es de temps. En version simplifi´ee, cela pourrait s’´ecrire de la fa¸con suivante :
synack ∧ [syn, 3]
2
→ack,
ce qui signifie que si un synack a ´et´e observ´e dans les trois unit´es de temps suivant un
syn, et que 2 unit´es de temps se sont ´ecoul´ees depuis, alors on doit avoir observ´e un
ack apr`es ce synack.
Chapitre 4. Logique d’acquisition de connaissances 106
σ(i) [=
σ,e
p(x
1
, . . . , x
n
) ssi ¦x
1
, . . . , x
n
¦ ⊆ dom(e) et p(e(x
1
), . . . , e(x
n
)) ∈ σ(i)
σ(i) [=
σ,e
φ
1
ssi var(φ
1
) ⊆ dom(e) et σ(i) [=
σ,e
φ
1
σ(i) [=
σ,e
φ
1
∧ φ
2
ssi σ(i) [=
σ,e
φ
1
et σ(i) [=
σ,e
φ
2
σ(i) [=
σ,e

1
, φ
2
] ssi ∃j < i.σ(j) [=
σ,e
φ
1
et
j < k < i, e

e[
var(φ
1
)
.σ(k) [=
σ,e
φ
2
var(p(x
1
, . . . , x
n
)) = ¦x
1
, . . . , x
n
¦
var(φ
1
) = var(φ
1
)
var(φ
1
∧ φ
2
) = var(φ
1
) ∪ var(φ
2
)
var([φ
1
, φ
2
]) = var(φ
1
)
Tab. 4.4 – S´emantique op´erationnelle pour le cas du premier ordre.
4.2.3 S´emantique
Maintenant que nous avons cette banque d’exemples en main, nous pouvons d´etailler
la s´emantique de la version du premier ordre de la logique, pr´esent´ee `a la table 4.4. Cette
s´emantique repose d’abord sur la notion d’environnement :
D´efinition 4.3 (Environnement)
´
Etant donn´e X un ensemble de variables et V un
ensemble de valeurs, un environnement est une fonction partielle e : X → V . L’en-
semble des environnements est muni d’un ordre partiel , d´efini de la fa¸con suivante :
e

e ssi dom(e

) ⊇ dom(e) et, ∀x ∈ dom(e).e

(x) = e(x).
La premi`ere ligne de la table 4.4 indique qu’un pr´edicat p(x
1
, . . . , x
n
) est satisfait, par
un ´ev´enement σ(i) donn´e, sous les environnements e tels que le n-tuple 'e(x
1
), . . . , e(x
n
)`
est un ´el´ement de l’ensemble associ´e `a p(x
1
, . . . , x
n
) dans σ(i). La seconde ligne dit que la
n´egation d’une formule est satisfaite par un ´etat σ(i) sous les environnements qui, bien
que comportant la d´efinition des variables n´ecessaires, ne satisfont pas la formule don-
n´ee. La troisi`eme ligne dit qu’une conjonction est satisfaite, par un ´ev´enement σ(i), sous
les environnements sous lesquels σ(i) satisfait chacune des deux propositions conjointes.
Finalement, la quatri`eme ligne nous dit qu’une formule temporelle est satisfaite, par un
´ev´enement σ(i), sous les environnements sous lesquels φ
1
a d´ej`a ´et´e satisfaite, et que
depuis il a ´et´e impossible d’´etendre de fa¸con `a satisfaire φ
2
.
La notation e[
S
(e restreint `a S) d´esigne l’environnement e

tel que dom(e

) =
dom(e) ∩ S et ∀x ∈ dom(e

).e

(x) = e(x). La restriction aux variables de φ
1
, pour
la d´esactivation d’une formule temporelle, est introduite pour r´epondre au fait intuitif
qu’une connaissance ne peut ˆetre retir´ee de la base de connaisances que sur la base de ce
qui a ´et´e appris au moment de l’acquisition de cette connaissance. Cet aspect particulier
Chapitre 4. Logique d’acquisition de connaissances 107
i p(s, t) q(t) p(s, t) ∧ q(t) [p(s, t) ∧ q(t), p(5, t)]
0 ¦s → 2, t → 3¦ ¦t → 3¦ ¦s → 2, t → 4¦
¦s → 2, t → 4¦ ¦t → 0¦
1 ¦s → 5, t → 4¦ ¦s → 5, t → 4¦ ¦s → 2, t → 4¦
2 ¦s → 5, t → 4¦
. . . . . . . . . . . . . . .
Fig. 4.6 – Exemple de relations de satisfaction pour le cas du premier ordre.
de la s´emantique de la logique, joint au fait que nous n’utilisons pas de quantificateurs
universels ou existentiel, nous am`ene `a faire quelques commentaires sur la port´ee des
diff´erentes variables utilis´ees dans une formule. Si ce n’´etait de la pr´esence de l’op´era-
teur de restriction dans la s´emantique de l’op´erateur temporel, les formules devraient
toutes ˆetre vues comme ´etant simplement encadr´ees par des quantificateurs universels
s’appliquant `a toutes les variables. Cependant, l’op´erateur de restriction a pour effet de
d´equantifier, dans les formules de la forme [φ
1
, φ
2
], les variables de φ
2
n’apparaissant
pas dans φ
1
. Par exemple, dans la formule [p(x), q(y)] ∧ r(y), les deux occurences de
la variable y n’ont aucunement besoin d’ˆetre associ´ees `a la mˆeme valeur. Pour ne pas
commettre d’erreur, il est plus simple de consid´erer que pour les formules φ ayant une
sous-formule de la forme [φ
1
, φ
2
], toutes les occurrences des variables apparaissant φ
2
mais non dans φ
1
doivent ˆetre dans φ
2
. Cette restriction syntaxique ne diminue en rien
l’expressivit´e de la logique. La formule [p(x), q(y)] ∧ r(y), par exemple, peut ˆetre rem-
plac´ee par la formule ´equivalente [p(x), q(y)] ∧ r(z). En se pliant `a cette restriction, il
est alors possible d’ignorer l’op´erateur de restriction et de consid´erer que les formules
sont encadr´ees par des quantificateurs universels.
`
A la figure 4.6, on voit un exemple de relation de satisfaction, dans le cas o` u la
trace σ est celle de la figure 4.4, (page 102). Chaque case du tableau contient les plus
petits environnements sous lesquels la formule `a la tˆete de la colonne est satisfaite
par l’´ev´enement σ(i). Pour les pr´edicats primitifs, les environnements sont ceux pour
lesquels les tuples form´es des valeurs associ´es aux variables de ces pr´edicats font partie
de l’ensemble associ´e `a ce pr´edicat dans σ(i).
`
A l’´ev´enement 0, le pr´edicat p(s, t) est
satisfait sous l’environnement ¦s → 2, t → 3¦, mais pas la formule q(t), car q(3) est
dans σ(0). La conjonction n’est donc satisfaite que sous l’environnement ¦s → 2, t → 4¦.
Comme cette conjonction active la formule temporelle, celle-ci est donc satisfaite `a partir
de σ(1) sous cet environnement. Comme, `a σ(1), on retrouve un couple o` u la premi`ere
valeur d’un tuple associ´e `a p(x, y) est unifiable avec 5 et la seconde avec la valeur associ´ee
`a t, la formule temporelle n’est plus satisfaite sous l’environnement ¦s → 2, t → 4¦ `a
partir de σ(2). Elle l’est cependant sous l’environnement ¦s → 5, t → 4¦.
Chapitre 4. Logique d’acquisition de connaissances 108
Nous terminons cette section avec la pr´esentation de trois r´esultats nous donnant une
meilleure intuition de ce que repr´esente l’ensemble var(φ). Le premier nous dit qu’un
environnement doit absolument d´efinir toutes les variables contenues dans var(φ) pour
pouvoir satisfaire φ. Le second nous dit que ces variables sont suffisantes, et que le fait
d’en ajouter plus ne change rien. Le troisi`eme nous fournit un cas particulier du second
dont nous aurons besoin plus loin dans ce chapitre.
Proposition 4.4 Si σ(i) [=
σ,e
φ, alors var(φ) ⊆ dom(e).
D´emonstration :
On proc`ede par induction sur φ. Les cas p(x
1
, . . . , x
n
) et φ
1
d´ecoulent directement de
la s´emantique. Si σ(i) [=
σ,e
φ
1
∧ φ
2
, alors σ(i) [=
σ,e
φ
1
et σ(i) [=
σ,e
φ
2
. Par induction,
var(φ
1
) ⊆ dom(e) et var(φ
2
) ⊆ dom(e), donc, var(φ
1
) ∪var(φ
2
) ⊆ dom(e), c’est-` a-dire,
d’apr`es la d´efinition de var, var(φ
1
∧ φ
2
) ⊆ dom(e). Si σ(i) [=
σ,e

1
, φ
2
], alors il existe
j < i.σ(j) [=
σ,e
φ
1
. Par l’hypoth`ese d’induction, dom(e) ⊇ var(φ
1
) = var([φ
1
, φ
2
]).
Proposition 4.5 Soit e
1
tel que var(φ) = dom(e
1
). Pour tout e
2
e
1
, σ(i) [=
σ,e
1
φ si
et seulement si σ(i) [=
σ,e
2
φ.
D´emonstration :
On proc`ede par induction sur φ.
cas p(x
1
, . . . , x
n
) :
(⇒)
σ(i) [=
σ,e
1
p(x
1
, . . . , x
n
)
⇒ ' d´efinition de la relation [= `
¦x
1
, . . . , x
n
¦ ⊆ dom(e
1
) et p(e
1
(x
1
), . . . , e
1
(x
n
)) ∈ σ(i)
⇒ ' par d´efinition de la relation ,
¦x
1
, . . . , x
n
¦ ⊆ dom(e
2
), et e
2
(x
k
) = e
1
(x
k
) `
¦x
1
, . . . , x
n
¦ ⊆ dom(e
2
) et p(e
2
(x
1
), . . . , e
2
(x
n
)) ∈ σ(i)
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
2
p(x
1
, . . . , x
n
)
(⇐)
Chapitre 4. Logique d’acquisition de connaissances 109
σ(i) [=
σ,e
2
p(x
1
, . . . , x
n
)
⇒ ' d´efinition de la relation [= `
¦x
1
, . . . , x
n
¦ ⊆ dom(e
2
) et p(e
2
(x
1
), . . . , e
2
(x
n
)) ∈ σ(i)
⇒ ' par hypoth`ese sur e
1
, ¦x
1
, . . . , x
n
¦ ⊆ dom(e
1
),
et par d´efinition de la relation , e
1
(x
k
) = e
2
(x
k
) `
¦x
1
, . . . , x
n
¦ ⊆ dom(e
1
) et p(e
1
(x
1
), . . . , e
1
(x
n
)) ∈ σ(i)
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1
p(x
1
, . . . , x
n
)
cas φ
1
:
(⇒)
premi`erement,
σ(i) [=
σ,e
1
φ
1
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1
φ
1
⇒ ' direction ⇐ de l’hypoth`ese d’induction `
σ(i) [=
σ,e
2
φ
1
deuxi`emement,
e
2
e
1
et var(φ) = dom(e
1
)
⇒ ' d´efinition de l’ensemble var `
e
2
e
1
et var(φ
1
) = dom(e
1
)
⇒ ' d´efinition de la relation `
dom(e
2
) ⊆ dom(e
1
) et var(φ) = dom(e
1
)
⇒ ' th´eorie des ensembles `
var(φ
1
) ⊆ dom(e
2
)
donc,
σ(i) [=
σ,e
2
φ
1
et var(φ
1
) ⊆ dom(e
2
)
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
2
φ
1
Chapitre 4. Logique d’acquisition de connaissances 110
(⇐)
premi`erement
σ(i) [=
σ,e
2
φ
1
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
2
φ
1
⇒ ' direction ⇒ de l’hypoth`ese d’induction `
σ(i) [=
σ,e
1
φ
1
deuxi`emement,
var(φ) ⊆ dom(e
1
)
⇒ ' d´efinition de l’ensemble var, var(φ) = var(φ
1
) `
var(φ
1
) ⊆ dom(e
1
)
donc,
σ(i) [=
σ,e
1
φ
1
et var(φ
1
) ⊆ dom(e
1
)
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1
φ
1
cas φ
1
∧ φ
2
:
(⇒)
σ(i) [=
e
1
φ
1
∧ φ
2
⇒ ' definition de la relation [= `
σ(i) [=
σ,e
1
φ
1
et σ(i) [=
σ,e
1
φ
2
⇒ ' direction ⇐ de l’hypoth`ese d’induction,
en posant e
3
= e
1
[
var(φ
1
)
et e
4
= e
1
[
var(φ
2
)
`
σ(i) [=
σ,e
3
φ
1
et σ(i) [=
σ,e
4
φ
2
⇒ ' direction ⇒ de l’hypoth`ese d’induction `
σ(i) [=
σ,e
2
φ
1
et σ(i) [=
σ,e
2
φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
2
φ
1
∧ φ
2
Chapitre 4. Logique d’acquisition de connaissances 111
(⇐)
σ(i) [=
σ,e
2
φ
1
∧ φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
2
φ
1
et σ(i) [=
σ,e
2
φ
2
⇒ ' direction ⇒ de l’hypoth`ese d’induction,
en posant e
3
= e
1
[
var(φ
1
)
et e
4
= e
1
[
var(φ
2
)
`
σ(i) [=
σ,e
3
φ
1
et σ(i) [=
σ,e
4
φ
2
⇒ ' direction ⇐ de l’hypoth`ese d’induction `
σ(i) [=
σ,e
1
φ
1
et σ(i) [=
σ,e
1
φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1
φ
1
∧ φ
2
cas [φ
1
, φ
2
] :
(⇒)
σ(i) [=
σ,e
1

1
, φ
2
]
⇒ ' d´efinition de la relation [= `
∃j < i.σ(j) [=
σ,e
1
φ
1
et ∃j < k < i, e

1
e
1
[
var(φ
1
)
.σ(k) [=
σ,e

1
φ
2
⇒ ' direction ⇒ de l’hypoth`ese d’induction `
∃j < i.σ(j) [=
σ,e
2
φ
1
et ∃j < k < i, e

1
e
1
[
var(φ
1
)
.σ(k) [=
σ,e

1
φ
2
⇒ ' var(φ
1
) = dom(e
1
) et e
2
e
1
impliquent e
2
[
var(φ
1
)
= e
1
[
var(φ
1
)
`
∃j < i.σ(j) [=
σ,e
2
φ
1
et ∃j < k < i, e

2
e
2
[
var(φ
1
)
.σ(k) [=
σ,e

2
φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
2

1
, φ
2
]
(⇐)
σ(i) [=
σ,e
2

1
, φ
2
]
⇒ ' d´efinition de la relation [= `
∃j < i.σ(j) [=
σ,e
2
φ
1
et ∃j < k < i, e

2
e
2
[
var(φ
1
)
.σ(k) [=
σ,e

2
φ
2
⇒ ' direction ⇐ de l’hypoth`ese d’induction `
∃j < i.σ(j) [=
σ,e
1
φ
1
et ∃j < k < i, e

2
e
2
[
var(φ
1
)
.σ(k) [=
σ,e

2
φ
2
⇒ ' var(φ
1
) = dom(e
1
) et e
2
e
1
impliquent e
2
[
var(φ
1
)
= e
1
[
var(φ
1
)
`
∃j < i.σ(j) [=
σ,e
1
φ
1
et ∃j < k < i, e

1
e
1
[
var(φ
1
)
.σ(k) [=
σ,e

1
φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1

1
, φ
2
]
Chapitre 4. Logique d’acquisition de connaissances 112
Ce dernier cas termine l’´etape d’induction sur i et compl`ete la d´emonstration.
Corollaire 4.6 Si e
1
e
2
et σ(i) [=
σ,e
2
φ, alors σ(i) [=
σ,e
1
φ.
D´emonstration :
Par d´efinition de l’op´erateur de restriction, dom(e
2
[
var(φ)
) = var(φ) ∩dom(e
2
). Comme,
par la proposition 4.4, var(φ) ⊆ dom(e
2
), on a dom(e
2
[
var(φ)
) = var(φ). Donc, par la
proposition 4.5, en posant e
1
= e
2
[
var(φ)
, on obtient σ(i) [=
σ,e
2
φ. Maintenant, comme
e
1
e
2
e
2
[
var(φ)
, par la transitivit´e de la relation , on a e
1
e
2
[
var(φ)
. On peut finalement
appliquer l’autre direction de la proposition 4.5 pour conclure que σ(i) [=
σ,e
1
φ.
4.3 R´ecursivit´e
4.3.1 Approximants
Comme nous l’avons d´ej` a remarqu´e, il existe certains types de sc´enarios d’attaque
ou d’acquisition d’information pour lesquels la notion de r´ep´etition est fondamentale.
On n’a qu’` a penser, par exemple, aux attaques de balayage, de force brute, ou encore
`a certaines attaques de d´eni de service. Les formules exprimant de tels comportements
r´ep´etitifs sont de la forme :
φ := [φ
1
∧ [φ
1
∧ [φ
1
∧ [. . .], φ
2
], φ
2
], φ
2
]
signifiant que φ
1
est satisfaite un certain nombre de fois, sans que φ
2
ne le soit. Dans le
cas d’une attaque de force brute ayant pour objectif de deviner un mot de passe Telnet,
par exemple, φ
1
pourrait repr´esenter une demande de connexion suivie d’un refus, alors
que φ
2
pourrait repr´esenter l’´ecoulement d’un d´elai.
On sent alors que la formule φ
1
dont on a besoin devrait en quelque sorte respecter
la propri´et´e :
φ := [φ
1
∧ φ, φ
2
]
et nous voudrions ˆetre capables d’´ecrire de telles formules. Pour r´epondre `a ce besoin,
nous introduisons la notation montr´ee `a la table 4.5, inspir´ee des approximants. Nor-
malement, les approximants sont d´efinis pour introduire les points fixes, ceux-ci ´etant
d´efinis comme des approximants limites, mais il s’av`ere que dans le cas qui nous occupe,
les points fixes ne sont pas n´ecessaires et que les approximants suffisent.
Chapitre 4. Logique d’acquisition de connaissances 113
ν
0
X.φ
def
= tt
ν
n
X.φ
def
= φ[ν
n−1
X.φ/X]
Tab. 4.5 – Approximants.
ν
3
X.syn ∧ [X, 2]
def
= syn ∧ [ν
2
X.syn ∧ [X, 2], 2]
def
= syn ∧ [syn ∧ [ν
1
X.syn ∧ [X, 2], 2], 2]
def
= syn ∧ [syn ∧ [syn ∧ [tt, 2], 2], 2]
Fig. 4.7 – Utilisation des approximants.
`
A la figure 4.7, on voit comment on peut utiliser les approximants pour ´ecrire la
formule ν
3
X.syn ∧ [X, 2], repr´esentant 3 demandes de connexion TCP s´epar´ees par au
plus 2 unit´es de temps.
4.3.2 Tableaux
Les approximants ne sont cependant pas seulement utiles pour exprimer des com-
portements r´ep´etitifs. Ils peuvent aussi servir `a exprimer toutes sortes de formules o` u la
r´ecursivit´e peut intervenir. Supposons par exemple, que l’on d´efinisse un nouveau type
tableau, tel que si tab est une variable de type tableau, alors tab[0], tab[1], tab[2],
. . . sont des variables ordinaires, et supposons que l’on veuille d´efinir une formule all-
Different(tab,i) qui s’´evalue `a vrai si et seulement si les i premiers ´el´ements du
tableau tab sont diff´erents. Ce sera vrai si tab[0] est diff´erent de tous les autres (de 1
`a i-1), et si tab[1] est diff´erent de tous ceux qui restent (de 2 `a i-1), et ainsi de suite.
`
A la table 4.6, on voit comment il est possible de g´en´eraliser la notion d’approximant
de fa¸con `a pouvoir les d´efinir sur un intervalle donn´e. La formule
ν
j:[0,i]
X.(X ∧ ν
k:[j+1,i]
Y.(Y ∧ tab[j] = tab[k]))
signifie alors que les i premiers ´el´ements du tableau tab ont des valeurs deux `a deux
diff´erentes.
`
A la figure 4.8, on voit comment interpr´eter cette formule dans le cas o` u
i = 3.
`
A la figure 4.9, on voit comment il est possible de d´efinir un balayage de ports en
Chapitre 4. Logique d’acquisition de connaissances 114
ν
i:[f,f]
X.φ
def
= tt
ν
i:[d,f]
X.φ
def
= φ[ν
i:[d+1,f]
X.φ/X, i/d] (d < f)
Tab. 4.6 – Approximants avec intervalles.
ν
j:[0,3]
X.(X ∧ ν
k:[j+1,3]
Y.(Y ∧ tab[j] = tab[k]))
def
=
ν
j:[1,3]
X.(X ∧ ν
k:[j+1,3]
Y.(Y ∧ tab[j] = tab[k]) ∧ ν
k:[1,3]
Y.(Y ∧ tab[0] = tab[k])
def
=
. . .
def
=
ν
j:[1,3]
X.(X ∧ ν
k:[j+1,3]
Y.(Y ∧ tab[j] = tab[k]) ∧ tab[0] = tab[2] ∧ tab[0] = tab[1]
def
=
. . .
def
=
tab[1] = tab[2] ∧ tab[0] = tab[2] ∧ tab[0] = tab[1]
Fig. 4.8 – Utilisation des approximants avec intervalles.
utilisant la r´ecursivit´e et les tableaux. Il est particuli`erement int´eressant de remarquer
comment la variable d’it´eration i et les tableaux sont utilis´es pour sp´ecifier que les ports
destination des demandes de connexion doivent ˆetre tous diff´erents. Lorsque le premier
syn est identifi´e, la variable dp[0] est unifi´ee `a son port destination, et la taille du
tableau dp est alors de 1. Lorsque le second syn est identifi´e, la variable dp[1] est unifi´ee
`a son port destination, et dp devient alors un tableau de taille 2.
`
A chaque it´eration, la
formule allDifferent, que nous avons d´ej` a d´efinie, est utilis´ee pour v´erifier que tous
les ports destination sont bel et bien diff´erents. Il n’y a aucune restriction sur les ports
source. Cependant, ceux-ci doivent toujours ˆetre emmagasin´es dans un tableau plutˆ ot
que dans une simple variable, sinon la formule signifierait que tous les ports source
doivent ˆetre ´egaux, l’unification ayant ´et´e faite une fois pour toutes `a la r´eception de la
premi`ere demande de connexion.
4.4 Algorithmes
Bien que la s´emantique de la logique permette que l’op´erateur [φ
1
, φ
2
] r´ef`ere `a un
´etat qui soit arbitrairement loin dans le pass´e, l’algorithme que nous pr´esentons ne
n´ecessite pas de m´emoriser la trace, et encore moins de parcourir celle-ci autrement
Chapitre 4. Logique d’acquisition de connaissances 115
portScan(sa,da) :=
ν
i:[0,5]
X.
syn ∧
tcpFlow(sa,sp[i],da,dp[i]) ∧
allDifferent(dp,i) ∧
[X, 2sec]
Fig. 4.9 – Balayage de ports TCP.
qu’´ev´enement par ´ev´enement, dans l’ordre o` u ils surviennent. De plus, la s´emantique
de la logique ´etant purement pass´ee, apr`es chaque traitement d’un ´ev´enement σ(i), il
est possible de dire si oui ou non σ(i) [= φ. Nul n’est besoin d’attendre `a l’´ev´enement
suivant, ou encore de tenir `a jour une liste de sc´enarios partiels. En ce sens, l’algorithme
que nous pr´esentons est donc en ligne (voir table 1.9, page 52).
Nous pr´esentons deux versions de l’algorithme, une pour le cas propositionnel, et
une pour le cas du premier ordre. Il s’agit essentiellement du mˆeme algorithme, la seule
diff´erence se situant au niveau des m´ecanismes d’unification.
Nous donnons aussi, dans chacun des cas, une d´emonstration de la validit´e (com-
pl´etude et coh´erence) de l’algorithme, ainsi qu’une analyse de complexit´e. Entre autres,
dans le cas propositionnel, nous verrons que l’espace m´emoire n´ecessaire ne d´epasse pas
quelques bits. La validit´e, dans le cas du premier ordre, ne sera obtenue qu’` a condition
de faire quelques concessions sur la forme des formules `a v´erifier. Ces concessions ne
sont cependant pas plus restrictives que celles qui doivent ˆetre faites lors de l’utilisation
du langage de programmation Prolog.
4.4.1 Cas propositionnel
L’algorithme de v´erification, pour le cas propositionnel, est montr´e `a la table 4.7. La
boucle principale de l’algorithme, verification, prend en entr´ee une formule φ et une
trace σ de longueur finie. Pour le cas infini, l’algorithme fonctionne exactement de la
mˆeme fa¸con, il faut juste pr´evoir un acc`es en lecture au tableau sat en cours d’ex´ecution
(puisque l’instruction retourner sat ne sera jamais ex´ecut´ee).
Les ensembles k et k

mat´erialisent l’acquisition d’information. L’ensemble k re-
pr´esente la connaissance acquise jusqu’`a maintenant, et l’ensemble k

repr´esente cette
connaissance, en cours de modification par le traitement de l’´etat courant. La connais-
Chapitre 4. Logique d’acquisition de connaissances 116
fonction verif(φ, s, k, k

)
entr´ees : φ : une formule, s : un ´etat, k : la connaissance pass´ee
sortie : k

: la connaissance mise `a jour
valeur de retour : un bool´een indiquant si s [= φ dans le contexte k
variables locales : v
1
, v
2
: des bool´eens
d´ebut
selon la forme de φ :
cas p :
retourne p ∈ s
cas φ
1
:
retourne verif(φ
1
, s, k, k

)
cas φ
1
∧ φ
2
:
v
1
:=verif(φ
1
, s, k, k

)
v
2
:=verif(φ
2
, s, k, k

)
retourne v
1
∧ v
2
cas [φ
1
, φ
2
] :
v
1
:=verif(φ
1
, s, k, k

)
v
2
:=verif(φ
2
, s, k, k

)
si v
1
alors k

:= k

∪ ¦φ¦
sinon si v
2
alors k

:= k

` ¦φ¦
retourne φ ∈ k
fin
fonction verification(φ, σ)
entr´ees : φ : une formule, σ : une trace
sortie : sat, un tableau de bool´eens tel que sat[i] ssi σ(i) [= φ
variables locales : k,k

: des ensembles
d´ebut
k

:= ∅
pour i allant de 0 `a [σ[
k := k

sat[i] :=verif(φ, σ(i), k, k

)
retourner sat
fin
Tab. 4.7 – Algorithme de v´erification pour le cas propositionel.
Chapitre 4. Logique d’acquisition de connaissances 117
sance est mise `a jour juste avant le traitement de chaque ´ev´enement. Il aurait ´et´e
possible d’optimiser en n’ayant qu’un seul ensemble, en s’assurant que les sous-formules
sont trait´ees dans le bon ordre, mais il ´etait plus commode, du point de vue de l’analyse,
de garder deux ensembles.
Th´eor`eme 4.7 (Validit´e) Apr`es chaque appel de verif(φ, σ(i), k, k

), l’ensemble
k

est l’ensemble de toutes les sous-formules de φ de la forme [φ
1
, φ
2
] qui sont telles que
σ(i + 1) [= [φ
1
, φ
2
]. De plus, la fonction retourne vrai ssi σ(i) [= φ.
D´emonstration :
On proc`ede par induction sur i :
Pour i = 0, on proc`ede par induction sur φ :
cas p : l’expression p ∈ s concorde exactement avec la s´emantique.
cas φ
1
: Par l’hypoth`ese d’induction sur φ, verif(φ
1
, σ(i), k, k

) retourne vrai
si et seulement si σ(i) [= φ
1
. On retourne donc vrai si et seulement si σ(i) [= φ
1
.
cas φ
1
∧ φ
2
: Comme dans le cas pr´ec´edent, on utilise l’hypoth`ese d’induction sur φ
pour les deux sous-formules et le reste concorde avec la s´emantique.
cas [φ
1
, φ
2
] : Comme k = ∅, on retourne faux, ce qui est correct car comme il n’existe
pas de j < 0, σ(0) [= [φ
1
, φ
2
]. Pour ce qui est de la mise `a jour de k, par d´efinition de
la s´emantique, σ(1) [= [φ
1
, φ
2
] si et seulement si σ(0) [= φ
1
. Par l’hypoth`ese d’induction
sur φ, [φ
1
, φ
2
] est ajout´e `a k

si et seulement si σ(0) [= φ
1
.
Pour i > 0, les trois premiers cas d’induction sur φ sont identiques au cas o` u i = 0.
Pour le cas [φ
1
, φ
2
], par l’hypoth`ese d’induction sur i, la valeur retourn´ee est correcte.
Il reste `a montrer que k est mis `a jour correctement. Par d´efinition de la s´emantique,
σ(i + 1) [= [φ
1
, φ
2
] si et seulement si σ(i) [= φ
1
ou (σ(i) [= [φ
1
, φ
2
] et σ(i) [= φ
2
).
1
Si σ(i) [= φ
1
, alors, par l’hypoth`ese d’induction sur φ, [φ
1
, φ
2
] sera dans k

(il y est
ajout´e s’il n’y est pas d´ej`a).
Si, au contraire, σ(i) [= φ
1
, alors par l’hypoth`ese d’induction sur i, [φ
1
, φ
2
] ∈ k

si et
seulement si σ(i) [= [φ
1
, φ
2
]. Par l’hypoth`ese d’induction sur φ, [φ
1
, φ
2
] est retir´e de k

si et seulement si σ(i) [= φ
2
, ce qui termine la d´emonstration.
1
La forme du reste de la d´emonstration est (p ⇔ q ∨ r) ⇔ ((q ⇒ p) ∧ (q ⇒ (p ⇔ r))).
Chapitre 4. Logique d’acquisition de connaissances 118
Nous venons donc de d´emontrer que l’algorithme de la table 4.7 est complet et coh´e-
rent. Il est complet car pour chaque i tel que σ(i) [= φ, l’appel de la fonction verif(φ,
σ(i), k, k

) retourne vrai, et il est coh´erent car si la valeur vrai est retourn´ee, alors
σ(i) [= φ.
Avant de passer `a l’analyse de la complexit´e, nous avons besoin de d´efinir [φ[, la taille
d’une formule. Intuitivement, la taille d’une formule est son nombre de sous-formules.
D´efinition 4.8 (Taille d’une formule)
[p[
def
= 1
[φ[
def
= 1 +[φ[

1
∧ φ
2
[
def
= 1 +[φ
1
[ +[φ
2
[
[[φ
1
, φ
2
][
def
= 1 +[φ
1
[ +[φ
2
[
Une propri´et´e int´eressante de notre algorithme est que l’espace m´emoire qu’il utilise
est constant en fonction de [σ[, et que le temps qu’il met `a s’ex´ecuter est lin´eaire en
fonction de [σ[.
Proposition 4.9 (Complexit´e) La taille de k ne d´epasse jamais [φ[, et le nombre
d’appels de la fonction verif est [φ[[σ[.
D´emonstration :
L’analyse de la taille de k est directe : comme cet ensemble ne contient que des sous-
formules de φ, celui-ci ne peut ˆetre plus grand que le nombre de sous-formules. Le nombre
d’appels de la fonction verif, pour chaque ´ev´enement, est ´egal `a φ (peu importe i). Le
nombre total d’appels est donc [φ[[σ[.
4.4.2 Cas du premier ordre
L’algorithme de v´erification, pour le cas du premier ordre, est pr´esent´e `a la table 4.8.
Le tableau sat, au lieu de contenir des variables bool´eennes, contient un ensemble d’en-
vironnements sous lesquels chaque ´ev´enement de la trace satisfait la formule φ. Dans le
cas g´en´eral, sat ne contient pas tous ces environnements, mais nous verrons dans cette
section qu’il est possible de d´efinir un ensemble de formules pour lequelles σ(i) [=
σ,e
φ
ssi il existe e

∈ sat[i] tel que e e

. De mˆeme l’ensemble k ne contient plus des sous-
formules de φ, mais des environnements sous lesquels les sous-formules de φ de la forme
Chapitre 4. Logique d’acquisition de connaissances 119

1
, φ
2
] sont satisfaites. L’expression |p(x
1
, . . . , x
n
)|
E
s
est consid´er´ee comme une primi-
tive qui, ´etant donn´e un ensemble d’environnements E, retourne l’ensemble minimal
d’environnements e

´etendant un environnement de E tels que σ(i) [=
σ,e
p(x
1
, . . . , x
n
).
Formules croissantes
Ce qui complique particuli`erement l’analyse de cet algorithme est (entre autres)
le cas de la conjonction, o` u on calcule d’abord les environnements sous lesquels φ
1
est satisfaite, et ensuite les environnements ´etendant ces derniers sous lesquels φ
2
est
satisfaite. Cette s´equentialit´e n’est pas toujours possible, et nous passerons pratiquement
le reste de ce chapitre `a d´eterminer dans quels cas elle l’est. En fait, nous verrons que
c’est au moins le cas pour les formules croissantes, que nous d´efinissons `a l’instant :
D´efinition 4.10
´
Etant donn´e un ensemble X de variables, on d´efinit r´ecursivement
l’ensemble des formules croissantes pour X de la fa¸con suivante :
1. p(x
1
, . . . , x
n
) est croissante pour X,
2. φ
1
est croissante pour X si var(φ
1
) ⊆ (X)
et φ
1
est croissante pour X,
3. φ
1
∧ φ
2
est croissante pour X si φ
1
est croissante pour X
et φ
2
est croissante pour X ∪ var(φ
1
),
4. [φ
1
, φ
2
] est croissante pour X si φ
1
est croissante pour X
et φ
2
est croissante pour var(φ
1
).
Une formule φ est dite croissante si elle est croissante pour ∅.
La clause 1 de la d´efinition nous dit qu’un pr´edicat seul est toujours croissant. La
clause 2 peut paraˆıtre surprenante au premier abord, mais elle prend tout son sens
lorsqu’on la met en lien avec la clause 3. La clause 2 nous dit, entre autres, que toutes
les variables de φ
1
doivent ˆetre dans X pour que φ
1
puisse ˆetre consid´er´ee comme
croissante, et la 3 nous dit que φ
2
doit ˆetre croissante au moins pour les variables de
φ
1
. Par exemple, les formules p(x) ∧ q(x) et p(x) ∧ q(x) sont croissantes, mais les
formules p(x) ∧q(x), p(x) ∧q(x) et (p(x) ∧q(x)) ne le sont pas. Ces deux clauses,
ensemble, proviennent du fait que nous avons l’intention d’effectuer une unification de
gauche `a droite. Comme dans le cas d’une unification faite avec Prolog (du moins avec
l’impl´ementation de Amzi 7.11), les pr´edicats situ´es le plus `a gauche servent `a construire
des environnements candidats, et les n´egations situ´ees `a droite servent `a ´ecarter les
Chapitre 4. Logique d’acquisition de connaissances 120
fonction verif(φ, s, k, E, k

)
entr´ees : φ : une formule, s : un ´etat, k : la connaissance pass´ee,
E : un ensemble d’environnements
sortie : k

: la connaissance mise `a jour
valeur de retour : un ensemble d’environnements
variables locales : v
1
, v
2
: des ensembles d’environnements
d´ebut
selon la forme de φ :
cas p(x
1
, . . . , x
n
) :
retourne |p(x
1
, . . . , x
n
)|
E
s
cas φ
1
:
E
1
:=verif(φ
1
, s, k, E, k

)
pour chaque e ∈ E
si ∃e

∈ E
1
.e

e alors E := E −e
retourne E
cas φ
1
∧ φ
2
:
E
1
:=verif(φ
1
, s, k, E, k

)
E
2
:=verif(φ
2
, s, k, E
1
, k

)
retourne E
2
cas [φ
1
, φ
2
] :
E
2
:=verif(φ
2
, s, k, E, k

)
pour chaque e tel que 'φ, e` ∈ k
si ∃e

∈ E
2
.e

e alors k

:= k

` ¦'φ, e`¦
E
1
:=verif(φ
1
, s, k, ∅, k

)
pour chaque e ∈ E
1
k

:= k

∪ ¦'φ, e[
var(φ
1
)

retourne ¦e
1
∪ e
2
tels que 'φ, e
1
` ∈ k, e
2
∈ E
et ∃x ∈ dom(e
1
) ∩ dom(e
2
).e
1
(x) = e
2
(x)¦
fin
fonction verification(φ, σ, sat)
entr´ees : φ : une formule, σ : une trace
sortie : sat, un tableau d’ensembles d’environnements
variables locales : k,k

: des ensembles
d´ebut
k

:= ∅
pour i allant de 0 `a [σ[
k := k

sat[i] :=verif(φ, σ(i), k, ¦∅¦, k

)
fin
Tab. 4.8 – Algorithme de v´erification pour le cas du premier ordre.
Chapitre 4. Logique d’acquisition de connaissances 121
|p(x
1
, . . . , x
n
)|
e
σ,i
= ¦e

e.p(e

(x
1
), . . . , e

(x
n
)) ∈ σ(i) et
x ∈ dom(e

) ⇒ x ∈ dom(e) ou x ∈ ¦x
1
, . . . , x
n
¦¦

1
|
e
σ,i
= ¦e¦ si |φ
1
|
e
σ,i
= ∅, ∅ sinon

1
∧ φ
2
|
e
σ,i
= |φ
2
|
E
1
σ,i
avec E
1
= |φ
1
|
e
σ,i
|[φ
1
, φ
2
]|
e
σ,0
= ∅
|[φ
1
, φ
2
]|
e
σ,i
(i > 0) = |φ
1
|
e
σ,i−1
∪ ¦e

∈ [φ
1
, φ
2
]|
e
σ,i−1
tels que |φ
2
|
e

|
var(φ
1
)
σ,i−1
= ∅¦
Tab. 4.9 – S´emantique d´enotationnelle pour le cas du premier ordre.
candidats construits. Dans notre cas, les candidats sont cependant aussi construits par
les formules temporelles, qui repr´esentent la base de connaissances. La clause 4 de la
d´efinition dit que pour qu’une formule temporelle soit croissante, la formule d’activation
doit ˆetre croissante, mais la formule de d´esactivation, elle, ne doit ˆetre croissante que
par rapport aux variables de la formule d’activation. Encore une fois, ce renforcement
(plus X est petit, plus il est difficile d’ˆetre croissant pour X) de la contrainte provient
du fait, que nous avons d´ej` a not´e lors de la pr´esentation de la s´emantique, que le retrait
d’une connaissance ne doit ˆetre effectu´e que sur la base des connaissances acquises lors
de l’acquisition de cette connaissance.
Avant de passer `a la pr´esentation de la s´emantique d´enotationnelle, notons que
certaines pr´ecautions doivent ˆetre prises lors des comparaisons faites avec le langage
Prolog. La principale pr´ecaution `a faire est la suivante : la base de faits de Prolog ne
doit pas ˆetre associ´ee `a notre base de connaissances, mais plutˆot `a chaque ´ev´enement.
Dans Prolog, l’unification des pr´edicats se fait avec la base de faits, et dans notre cas,
elle se fait avec chacun des ´ev´enements. C’est donc comme si nous ´etions en train de
d´efinir un Prolog dont la base de faits change `a chaque ´ev´enement.
S´emantique d´enotationnelle
Pour nous aider dans notre analyse, nous avons extrait de l’algorithme pr´esent´e `a la
table 4.8 une s´emantique d´enotationnelle abstraite, pr´esent´ee `a la table 4.9. D´esormais,
c’est `a partir de cette s´emantique que nous raisonnerons.
´
Etant donn´e une formule φ,
une trace σ et un environnement e, on montre comment calculer |φ|
e
σ,i
, un ensemble
d’environnements e

tels que e

´etend e juste ce qu’il faut pour pouvoir pr´etendre `a
satisfaire φ dans l’´etat i de la trace σ. Le juste ce qu’il faut en question est celui de
la proposition 4.5, qui nous dit qu’il suffit que l’environnement soit d´efini sur var(φ).
Chapitre 4. Logique d’acquisition de connaissances 122
Prenons, par exemple, la premi`ere ligne de la table 4.9. Pour un pr´edicat p(x
1
, . . . , x
n
),
l’ensemble |p(x
1
, . . . , x
n
)|
e
σ,i
est l’ensemble des environnements ´etendant e en d´efinis-
sant exactement les variables qui lui manquent pour pouvoir satisfaire p(x
1
, . . . , x
n
). Si
aucune telle extension n’est possible, alors l’ensemble |p(x
1
, . . . , x
n
)|
e
σ,i
est ∅. Dans le
cas de la n´egation, aucune extension n’est n´ecessaire pour pouvoir pr´etendre `a satisfaire
φ
1
. Au contraire, dans le cas o` u il est possible de calculer une extension permettant de
satisfaire φ
1
, alors l’ensemble retourn´e est ∅. Si il n’est pas possible de calculer une telle
extension, alors e peut pr´etendre `a satisfaire φ
1
et l’ensemble retourn´e est seulement
le singleton ¦e¦. Le cas de la conjonction est le plus d´elicat. Les tentatives d’unifica-
tion sont faites de gauche `a droite, sans retour en arri`ere. L’exploration de tous les
arbres possibles nous semblait un gruge-temps additionnel non-n´ecessaire du point de
vue de l’expressivit´e (souvenons-nous que nous travaillons dans un contexte en-ligne).
On commence donc par calculer les extensions pouvant pr´etendre `a satisfaire φ
1
, puis
on regarde comment il est possible d’´etendre ces extensions de fa¸con `a satisfaire φ
2
.
Lorsque E est un ensemble d’environnements, l’expression |φ|
E
σ,i
est un raccourci pour

e∈E
|φ|
e
σ,i
. Finalement, on traite le cas de la formule [φ
1
, φ
2
] par d´eploiement r´ecursif.
Les extensions pr´etendant `a satisfaire [φ
1
, φ
2
] sont celles, premi`erement, qui dans l’´etat
pr´ec´edent pr´etendaient `a satisfaire φ
1
, et deuxi`emement, qui, en plus de d´ej` a pr´etendre
`a satisfaire [φ
1
, φ
2
] dans l’´etat pr´ec´edent, ne pr´etendaient en aucune fa¸con pouvoir me-
ner `a la satisfaction de φ
2
(toujours en se restreignant aux variables de φ
1
).
Nous avons maintenant les outils n´ecessaires pour ´enoncer tout de suite le th´eor`eme
de validit´e, que nous d´emontrerons plus loin :
Th´eor`eme 4.13 (Validit´e) Si φ est une formule croissante pour dom(e) et e
1
e,
alors σ(i) [=
σ,e
1
φ si et seulement si il existe e
2
∈ |φ|
e
σ,i
tel que e
1
e
2
.
Pour illustrer la n´ecessit´e de l’hypoth`ese de croissance, prenons, par exemple, la
formule p(x) ∧ q(x) dans un ´etat σ(i) = ¦p(1), q(2)¦, nous avons
|p(x)|
{∅}
σ,i
= ¦¦x → 1¦¦, et
|q(x)|
{{x→1}}
σ,i
= ¦¦x → 1¦¦
par contre, si on consid`ere la formule (´equivalente) q(x) ∧p(x), l’unification de gauche
`a droite donne
|q(x)|
{∅}
σ,i
= ∅, et
|p(x)|

σ,i
= ∅
Une fois que nous aurons d´emontr´e ce thor`eme, nous pourrons en d´eduire le corollaire
Chapitre 4. Logique d’acquisition de connaissances 123
suivant, qui est le cas particulier qui nous int´eresse. Il nous dit que si la formule `a
v´erifier respecte les conditions syntaxiques d’une formule croissante, alors il est possible
de calculer, pour chaque ´ev´enement, un ensemble d’environnements repr´esentant tous
les environnements sous lesquels φ est satisfaite.
Corollaire 4.14 Si φ est croissante, alors pour tout environnement e, σ(i) [=
σ,e
si et
seulement si il existe e

∈ |φ|
{∅}
σ,i
tel que e e

.
Les deux lemmes dont nous avons besoin pour la d´emonstration du th´eor`eme servent
`a justifier la d´efinition que nous avons donn´e des formules croissantes. Le lemme 4.11
nous dit que la v´erification d’une formule croissante par rapport `a un environnement
donn´e nous donne un ensemble d’environnements dont le domaine contient les variables
de cette formule, et le lemme 4.12 nous dit que ces environnements sont des extensions
du premier environnement.
Lemme 4.11 Si φ est croissante pour dom(e) et e

∈ |φ|
e
σ,i
, alors dom(e

) = dom(e) ∪
var(φ).
D´emonstration :
On proc`ede par induction sur i :
Pour le cas i = 0, on proc`ede par induction sur φ :
Cas p(x
1
, . . . , x
n
) : Cons´equence directe de la d´efinition de la s´emantique d´enotation-
nelle.
Cas φ
1
: Si φ
1
est croissante pour dom(e), alors var(φ
1
) ⊆ dom(e), et par d´efi-
nition de la s´emantique d´enotationnelle, e

∈ |φ
1
|
e
σ,i
implique e

= e. Donc, dom(e

) =
dom(e) = dom(e) ∪ var(φ
1
) = dom(e) ∪ var(φ
1
).
Cas φ
1
∧ φ
2
: Soit e

∈ |φ
1
|
e
σ,i
tel que e

∈ |φ
2
|
e

σ,i
(un tel e

existe par d´efinition de la
s´emantique d´enotationnelle). Comme φ
1
est croissante pour dom(e), on peut appliquer
l’hypoth`ese d’induction pour dire que dom(e

) = dom(e) ∪ var(φ
1
). Alors, par d´efini-
tion d’une formule croissante, φ
2
est croissante pour dom(e

), et on peut appliquer une
seconde fois l’hypoth`ese d’induction sur φ pour dire que dom(e

) = dom(e

)∪var(φ
2
) =
dom(e) ∪ var(φ
1
) ∪ var(φ
2
) = dom(e) ∪ var(φ
1
∧ φ
2
).
Cas [φ
1
, φ
2
] : Comme il n’existe pas de e

∈ |[φ
1
, φ
2
]|
e
σ,0
, la condition du lemme ne
s’applique pas et ce cas est d´emontr´e.
Chapitre 4. Logique d’acquisition de connaissances 124
Pour le cas i > 0, les trois premiers cas d’induction sur φ sont identiques. Pour le
cas [φ
1
, φ
2
], soit que e

∈ |φ
1
|
e
σ,i−1
, soit que e

∈ |[φ
1
, φ
2
]|
e
σ,i−1
. Dans le premier cas,
c’est l’hypoth`ese d’induction sur φ qui permet de conclure, et dans le second cas, c’est
celle sur i qui finit le travail, compl´etant ainsi la d´emonstration du lemme.
Lemme 4.12 Si e

∈ |φ|
e
σ,i
, alors e

e.
D´emonstration :
On proc`ede par induction sur i :
Pour le cas i = 0, on proc`ede par induction sur φ :
Cas p(x
1
, . . . , x
n
) : Cons´equence directe de la d´efinition de la s´emantique d´enotation-
nelle.
Cas φ
1
: Cons´equence directe de la r´eflexivit´e de et de la d´efinition de la s´emantique
d´enotationnelle.
Cas φ
1
∧ φ
2
: Cons´equence directe de la transitivit´e de et de la d´efinition de la
s´emantique d´enotationnelle.
Cas [φ
1
, φ
2
] : Comme il n’existe pas de e

∈ |[φ
1
, φ
2
]|
e
σ,0
, la condition du lemme ne
s’applique pas et ce cas est d´emontr´e.
Pour le cas i > 0, les trois premiers cas d’induction sur φ sont identiques. Pour le
cas [φ
1
, φ
2
], soit que e

∈ |φ
1
|
e
σ,i−1
, soit que e

∈ |[φ
1
, φ
2
]|
e
σ,i−1
. Dans le premier cas,
c’est l’hypoth`ese d’induction sur φ qui permet de conclure, et dans le second cas, c’est
celle sur i qui finit le travail, compl´etant ainsi la d´emonstration du lemme.
Nous avons maintenant tous les outils n´ecessaires pour passer `a la d´emonstration
du th´eor`eme de validit´e.
σ(i) [=
σ,e
1
φ si et seulement si il existe e
2
∈ |φ|
e
σ,i
tel que e
1
e
2
D´emonstration du th´eor`eme:
On proc`ede par induction sur i.
Cas i = 0 : On proc`ede par induction sur φ.
Chapitre 4. Logique d’acquisition de connaissances 125
Cas p(x
1
, . . . , x
n
) :
(⇒)
σ(i) [=
σ,e
1
p(x
1
, . . . , x
n
)
⇒ ' d´efinition de la relation [= `
¦x
1
, . . . , x
n
¦ ⊆ dom(e
1
) et p(e
1
(x
1
), . . . , e
n
(x
n
)) ∈ σ(i)
⇒ ' d´efinition de la s´emantique d´enotationnelle et e
1
e `
e ∪ e
1
[
{x
1
,...,x
n
}
∈ |φ|
e
σ,i
⇒ ' e
1
e ⇒ e
1
e ∪ e
1
[
{x
1
,...,xn}
,
on peut donc poser e
2
= e ∪ e
1
[
{x
1
,...,x
n
}
`
∃e
2
∈ |φ|
e
σ,i
.e
1
e
2
(⇐)
e
1
e
2
et e
2
∈ |p(x
1
, . . . , x
n
)|
e
σ,i
⇒ ' d´efinition de la s´emantique d´enotationnelle `
e
1
e
2
et ¦x
1
, . . . , x
n
¦ ⊆ dom(e
2
) et p(e
2
(x
1
), . . . , e
2
(x
n
)) ∈ σ(i)
⇒ ' d´efinition de la relation `
¦x
1
, . . . , x
n
¦ ⊆ dom(e
2
) ⊆ dom(e
1
) et e
1
(x
l
) = e
2
(x
l
) pour l = 1 . . . n
et p(e
2
(x
1
), . . . , e
2
(x
n
)) ∈ σ(i)
⇒ ' th´eorie des ensembles `
p(e
1
(x
1
), . . . , e
1
(x
n
)) ∈ σ(i)
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1
p(x
1
, . . . , x
n
)
Cas φ
1
:
(⇒)
σ(i) [=
σ,e
1
φ
1
⇒ ' Par d´efinition d’une formule croissante, φ
1
est croissante pour dom(e).
On peut donc appliquer la direction ⇐ de l’hypoth`ese d’induction sur
φ. `
∃e

1
∈ |φ
1
|
e
σ,i
.e
1
e

1
⇒ ' e
1
e `
e ∈ |φ
1
|
e
σ,i
Chapitre 4. Logique d’acquisition de connaissances 126
⇒ ' Comme var(φ
1
) ⊆ dom(e), le lemme 4.11 nous dit que e

∈ |φ|
e
σ,i
implique dom(e

) = dom(e). D’autre part, le lemme 4.12 nous dit que
e

∈ |φ|
e
σ,i
implique e

e. Comme dom(e

) = dom(e) et e

e ´equivaut
`a e

= e, on a donc e

∈ |φ|
e
σ,i
implique e

= e. `

1
|
e
σ,i
= ∅
⇒ ' d´efinition de la s´emantique d´enotationnelle `

1
|
e
σ,i
= ¦e¦
⇒ ' e
1
e (e est donc le e
2
voulu) `
∃e
2
∈ |φ|
e
σ,i
.e
1
e
2
(⇐)
e
1
e
2
et e
2
∈ |φ
1
|
e
σ,i
tel que
⇒ ' d´efinition de la s´emantique d´enotationnelle `

1
|
e
σ,i
= ∅
⇒ ' Par d´efinition d’une formule croissante, φ
1
est croissante pour dom(e).
On peut donc appliquer la direction ⇒ de l’hypoth`ese d’induction sur
φ. `
∃e

e.σ(i) [=
σ,e
φ
1
⇒ ' e
1
e `
σ(i) [=
σ,e
1
φ
1
⇒ ' var(φ
1
) ⊆ dom(e
1
) et d´efinition de la relation [= `
σ(i) [=
σ,e
1
φ
1
Cas φ
1
∧ φ
2
:
(⇒)
σ(i) [=
σ,e
1
φ
1
∧ φ
2
⇒ ' Comme φ
1
est croissante pour dom(e), σ(i) [=
σ,e
1
φ
1
, et e
1
e, on
peut appliquer la direction ⇒ de l’hypoth`ese d’induction sur φ. `
∃e

1
∈ |φ
1
|
e
σ,i
.e
1
e

1
⇒ ' Comme σ(i) [=
σ,e
1
φ
2
, que e
1
e

1
, et que par le lemme 4.11, φ
2
est
croissante pour dom(e

1
), on peut appliquer la direction ⇒ de l’hypo-
th`ese d’induction sur φ. `
∃e
2
∈ |φ
2
|
e

1
σ,i
.e
1
e
2
⇒ ' d´efinition de la s´emantique d´enotationnelle `
∃e
2
∈ |φ
1
∧ φ
2
|
e
σ,i
.e
1
e
2
Chapitre 4. Logique d’acquisition de connaissances 127
(⇐)
e
1
e
2
et e
2
∈ |φ
1
∧ φ
2
|
e
σ,i
⇒ ' d´efinition de la s´emantique d´enotationnelle `
e
1
e
2
et ∃e

1
∈ |φ
1
|
e
σ,i
.e
2
∈ |φ
2
|
e

1
σ,i
⇒ ' Comme φ
1
∧ φ
2
est croissante pour dom(e), par d´efinition, φ
1
est
croissante pour dom(e). On peut donc appliquer la direction ⇐ de
l’hypoth`ese d’induction. `
e
1
e
2
et σ(i) [=
σ,e

1
φ
1
et e
2
∈ |φ
2
|
e

1
σ,i
⇒ ' Par le lemme 4.11, φ
2
est croissante sous dom(e

1
). On peut donc
appliquer encore une fois la direction ⇐ de l’hypoth`ese d’induction. `
e
1
e
2
et σ(i) [=
σ,e

1
φ
1
et σ(i) [=
σ,e
2
φ
2
⇒ ' Par le lemme 4.12, e
2
e

1
, on peut donc appliquer le corollaire 4.6. `
e
1
e
2
et σ(i) [=
σ,e
2
φ
1
et σ(i) [=
σ,e
2
φ
2
⇒ ' d´efinition de la relation [= `
e
1
e
2
et σ(i) [=
σ,e
2
φ
1
∧ φ
2
⇒ ' corollaire 4.6 `
σ(i) [=
σ,e
1
φ
1
∧ φ
2
Cas [φ
1
, φ
2
] :
(⇔) Par d´efinition de la s´emantique op´erationnelle, comme il n’existe pas de j < 0,
il n’existe pas de e
1
tel que σ(i) [=
σ,e
1

1
, φ
2
]. Comme la condition ne s’applique pas,
ce cas du th´eor`eme est v´erifi´e.
Cas i > 0 : Les trois premiers cas de l’induction sur φ sont identiques au cas o` u i = 0.
Il reste `a montrer le cas o` u φ = [φ
1
, φ
2
].
(⇒) Si σ(i) [=
σ,e
1

1
, φ
2
], alors, par d´efinition de la s´emantique op´erationnelle, soit
que σ(i −1) [=
σ,e
1
φ
1
, soit que σ(i −1) [=
σ,e
1

1
, φ
2
] et ∃e

1
e
1
[
var(φ
1
)
.σ(i −1) [=
σ,e

1
φ
2
.
Premier cas :
σ(i −1) [=
σ,e
1
φ
1
⇒ ' Comme φ
1
est croissante par rapport `a dom(e
1
), on peut appliquer
la direction ⇒ de l’hypoth`ese d’induction sur φ. `
∃e
2
∈ |φ
1
|
e
σ,i−1
.e
1
e
2
⇒ ' d´efinition de la s´emantique d´enotationnelle `
Chapitre 4. Logique d’acquisition de connaissances 128
∃e
2
∈ |[φ
1
, φ
2
]|
e
σ,i
.e
1
e
2
Second cas :
σ(i −1) [=
σ,e
1

1
, φ
2
] et ∃e

1
e
1
[
var(φ
1
)
.σ(i −1) [=
σ,e

1
φ
2
⇒ ' direction ⇒ de l’hypoth`ese d’induction sur i `
∃e
2
∈ |[φ
1
, φ
2
]|
e
σ,i−1
.e
1
e
2
et ∃e

1
e
1
[
var(φ
1
)
.σ(i −1) [=
σ,e

1
φ
2
⇒ ' Comme, par le lemme 4.11, var(φ
1
) ⊆ dom(e
2
), et que φ
2
est crois-
sante pour var(φ
1
), φ
2
est croissante pour dom(e
2
)[
var(φ
1
)
. Alors, ´etant
donn´e que e
2
[
var(φ
1
)
= e
1
[
var(φ
1
)
, on peut appliquer la direction ⇐ de
l’hypoth`ese d’induction sur φ. `
∃e
2
∈ |[φ
1
, φ
2
]|
e
σ,i−1
.e
1
e
2
et |φ
2
|
e
2
|
dom(φ
1
)
σ,i−1
= ∅
⇒ ' d´efinition de la s´emantique d´enotationnelle `
∃e
2
∈ |[φ
1
, φ
2
]|
e
σ,i
.e
1
e
2
(⇐) Si e
2
∈ |[φ
1
, φ
2
]|
e
σ,i
, alors e
2
∈ |φ
1
|
e
σ,i−1
ou e
2
∈ [φ
1
, φ
2
]|
e
σ,i−1
et est tel que

2
|
e
2
|
var(φ
1
)
σ,i−1
= ∅.
Premier cas :
e
1
e
2
et e
2
∈ |φ
1
|
e
σ,i−1
⇒ ' Par d´efinition d’une formule croissante, φ
1
est croissante pour dom(e),
on peut donc appliquer la direction ⇐ de l’hypoth`ese d’induction sur
φ. `
σ(i −1) [=
σ,e
1
φ
1
⇒ ' i −1 < i et k.i −1 < k < i `
∃j < i.σ(j) [=
σ,e
1
φ
1
et j < k < i, e

1
e
1
[
var(φ
1
)
.σ(k) [=
σ,e

1
φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1

1
, φ
2
]
Second cas :
e
1
e
2
et e
2
∈ |[φ
1
, φ
2
]|
e
σ,i−1
et |φ
2
|
e
2
|
var(φ
1
)
σ,i−1
= ∅
⇒ ' direction ⇒ de l’hypoth`ese d’induction sur i (deux fois) `
e
1
e
2
et σ, i −1 [=
σ,e
1

1
, φ
2
] et e

2
e
2
[
var(φ
1
)
.σ(i −1) [=
σ,e

2
φ
2
⇒ ' e
1
e
2
e
2
[
var(φ
1
)
et transitivit´e de `
Chapitre 4. Logique d’acquisition de connaissances 129
σ, i −1 [=
σ,e
1

1
, φ
2
] et e

1
e
1
.σ(i −1) [=
σ,e

1
φ
2
⇒ ' d´efinition de la relation [= `
σ(i) [=
σ,e
1

1
, φ
2
]
Les deux cas ´etant d´emontr´es, on peut utiliser le corollaire 4.6 pour conclure que
σ(i) [=
σ,e
1

1
, φ
2
]. Ceci compl`ete le dernier cas d’induction et par le fait mˆeme la
d´emonstration du th´eor`eme.
4.5 Conclusion
Dans ce chapitre, nous avons vu comment l’utilisation d’une logique pass´ee permet
de mod´eliser l’acquisition passive d’information dans un paradigme qui soit compl`ete-
ment d´eclaratif. Le probl`eme, avec une logique future, est que l’on ne peut pas expri-
mer la condition si tel comportement a d´ej`a ´et´e observ´e. Au chapitre pr´ec´edent, nous
avons r´esolu ce probl`eme en permettant de g´erer, au niveau de l’implantation, une base
de connaissances `a laquelle il ´etait possible de dynamiquement ajouter et retirer des
connaissances. Ces ajouts et ces retraits, dans le contexte d’une logique pass´ee, sont
mod´elis´es par l’utilisation de l’op´erateur [φ
1
, φ
2
]. De plus, nous avons vu que cet op´era-
teur permet aussi bien de mod´eliser les sc´enarios `a reconnaˆıtre que ceux d’une logique
future, les rendant ainsi superflus. Nous avons donc vu que l’op´erateur [φ
1
, φ
2
] est suf-
fisant pour mod´eliser `a la fois l’acquisition de connaissances et les sc´enarios d’attaque
s’´etendant sur plusieurs paquets.
Nous avons aussi vu comment un mod`ele et une s´emantique bas´es sur un concept
d’unification permettent de mieux mod´eliser le fait que diff´erents paquets contiennent
diff´erentes entˆetes de protocoles, que certains champs puissent ˆetre optionnels, ou encore
ˆetre associ´es `a plusieurs valeurs diff´erentes. De plus, l’utilisation du concept d’unifica-
tion, li´e `a l’ajout d’op´erateurs pass´es, permet d’oublier une fois pour toutes le concept de
formule en cours de reconnaissance, qui non-seulement ´etait pr´esent dans l’approche que
nous avons propos´ee utilisant une logique future, mais aussi dans LogWeaver, Eagle et
Chronicles. De plus, les autres approches, utilisant d’autres formalismes pour les sc´ena-
rios, tels que les syst`emes de transition avec STATL, ou les r´eseaux de Petri avec IDIOT,
ont eux aussi cette notion de sc´enario en cours de reconnaissance. En fusionnant les
concepts de sc´enario et de connaissance, tout devient de la connaissance acquise. On
n’a plus besoin de tenir `a jour un ensemble de formules partiellement satisfaites, mais
simplement une base de connaissances. Nous croyons qu’une impl´ementation judicieuse
des algorithmes que nous avons pr´esent´es devrait tenir compte de la nature globale de
Chapitre 4. Logique d’acquisition de connaissances 130
la connaissance acquise pour offrir une factorisation efficace `a la fois du code ex´ecutable
et des sp´ecifications.
L’ajout d’op´erateurs d’approximants dans la syntaxe nous a permis d’exprimer sim-
plement des propri´et´es de r´ep´etition. Comme ces op´erateurs peuvent ˆetre d´efinis syn-
taxiquement `a partir des op´erateurs existant d´ej`a, cet ajout ne complique en rien les
algorithmes de v´erification. Aussi, le langage que nous avons d´evelopp´e permet d’expri-
mer assez simplement des contraintes de temps-r´eel sans faire d’hypoth`ese particuli`ere
sur le mod`ele des donn´ees ni modifier en quelque fa¸con que ce soit l’algorithme de
v´erification.
Finalement, nous avons vu que dans le cas propositionnel, il existe un algorithme
de v´erification dont le temps d’ex´ecution augmente lin´eairement avec la taille de la
trace `a analyser, et utilise une quantit´e constante d’espace m´emoire. Nous avons aussi
prouv´e que cet algorithme est complet et coh´erent par rapport `a la s´emantique de la
logique. De plus, il s’agit d’un algorithme en-ligne, c’est-`a-dire qui n’a jamais besoin
de retourner en arri`ere pour consulter les ´ev´enements pass´es. Dans le cas du premier
ordre, l’algorithme que nous avons pr´esent´e est lui aussi en-ligne, ainsi que complet
et coh´erent, `a condition de respecter certaines conditions syntaxiques sur les formules
`a v´erifier. Cependant, nous ne croyons pas que ces conditions soient particuli`erement
restrictives.
L’analyse de ce dernier algorithme n’a pas encore ´et´e faite. L’analyse de la com-
plexit´e en espace est le cas le moins compliqu´e. En fait, on peut tout de suite dire
qu’elle est de l’ordre de [φ[[var(φ)[[1[, o` u 1 est le domaine des valeurs unifiables `a une
variable. Le raisonnement `a effectuer pour arriver `a ce r´esultat est le mˆeme que dans le
cas propositionnel. L’analyse en temps ne s’av`ere cependant pas aussi simple. Le pro-
bl`eme est qu’il nous semble difficile, ´etant donn´ee la fa¸con dont l’algorithme est d´ecrit,
de s’arrˆeter sur le choix d’une instruction ´el´ementaire. Pour le cas propositionnel, nous
avons choisi le nombre d’appels `a la fonction verif.
´
Etant donn´e que les op´erations
effectu´ees `a l’int´erieur de chacun de ces appels ´etaient facilement associables `a des op´e-
rations pouvant s’effectuer en temps constant, cette mesure nous semblait raisonnable.
Dans le cas du premier ordre, les op´erations effectu´ees `a l’int´erieur de chaque appel sont
des op´erations d’unification, et nous n’avons donn´e que la sp´ecification de celles-ci, sans
entrer dans les d´etails. Mˆeme si la taille des ´ev´enements (le nombre de tuples associ´es `a
chaque pr´edicat ´el´ementaire) ´etait toujours la mˆeme, ou du moins toujours born´ee par
une certaine constante (ce qui est tout de mˆeme une hypoth`ese raisonnable) le probl`eme
se poserait toujours. En fait, le probl`eme se situe au niveau de la base de connaissances.
Il est clair qu’`a mesure que le temps avance, la quantit´e d’information accumul´ee avance
elle aussi et que les tentatives d’unification avec la base de connaissances prendront de
Chapitre 4. Logique d’acquisition de connaissances 131
plus en plus de temps. D’un autre cˆot´e, en supposant born´e le domaine des valeurs
auxquelles les variables sont unifiables, il est raisonnable de penser que la taille de la
base de connaissances viendra `a se stabiliser. Comme nous l’avons d´ej` a dit, d’un point
de vue th´eorique, le mˆeme raisonnement que pour le cas propositionnel nous am`ene
`a dire que la quantit´e d’espace m´emoire utilis´e est born´ee. Cependant, d’un point de
vue pratique, une base de connaissance pleine `a craquer, bien que ne demandant pas un
temps d’ex´ecution grandissant, peut tout de mˆeme demander un temps qui soit inaccep-
tablement trop grand. Autrement dit, dire que l’algorithme s’ex´ecute en temps O([σ[)
est th´eoriquement correct, mais nous savons bien que la constante cach´ee peut ˆetre, en
pire cas, d’une taille assomante. D’un autre cˆot´e, avec des sp´ecifications bien choisies, il
est fort possible que le pire cas n’arrive pas si souvent que ¸ca. Pour ces raisons, et aussi
`a cause du fait que nous ne disposons pas d’une op´eration ´el´ementaire `a utiliser comme
mesure, l’analyse de l’algorithme dans le cas du premier ordre n’a pas ´et´e faite.
Chapitre 5
Travaux futurs
Dans ce travail, nous avons d´evelopp´e un nouveau langage de signatures pour les
syst`emes de d´etection d’intrusions. Le focus a principalement ´et´e mis sur l’expressivit´e
de ce langage, de mˆeme que sur les aspects algorithmiques reli´es `a son impl´ementation.
L’utilisation d’un paradigme bas´e sur une logique temporelle nous a permis, dans le
cadre du travail effectu´e, de d´evelopper un langage qui soit purement d´eclaratif, au sens
o` u l’utilisateur n’a pas `a se soucier de la fa¸con dont l’algorithme de v´erification s’ex´ecute
pour sp´ecifier ses signatures. L’utilisation d’une logique temporelle pr´esente cependant
d’autres avantages, et ouvre la voie pour nos futurs travaux de recherche. Dans cette
section, nous donnons quelques exemples de directions de recherche que nous pr´evoyons
explorer dans les mois `a venir.
5.1 Satisfiabilit´e
Un des avantages reli´es `a l’utilisation d’un paradigme bas´e sur une logique est de
permettre la v´erification de la coh´erence de la base de r`egles. La s´emantique du langage
d´evelopp´e s’applique aux ´etats d’une trace, et il est sous-entendu qu’une trace σ satisfait
une politique φ donn´ee si et seulement si pour chaque ´ev´enement σ(i), on a σ(i) [=
σ
φ.
Il existe cependant des formules qui ne sont satisfaites par aucune trace. De telles
formules sont appel´ees contradictions.
`
A la figure 5.1, on trouve quatre exemples de
contradictions. La premi`ere est une contradiction au niveau propositionnel, c’est-`a-
dire que non-seulement n’est-elle pas satisfiable par aucune trace, mais elle ne l’est
pas non-plus pour aucun ´etat d’aucune trace. La deuxi`eme formule est un exemple de
contradiction qui se situe au niveau temporel. Elle est satisfaite par les ´etats qui ont ´et´e
Chapitre 5. Travaux futurs 133
p ∧ p
[p, faux]
[vrai, p]
p → [q, faux] ∧ q → [p, faux] ∧ (p ∨ q)
Fig. 5.1 – Exemples de contradictions.
pr´ec´ed´es par un ´etat o` u p ´etait vrai. Certainement, cette formule n’est jamais satisfaite
par le premier ´etat d’une trace. Cons´equemment, elle n’est satisfiable par aucune trace
et il s’agit d’une contradiction. La troisi`eme est une contradiction pour la mˆeme raison.
Bien que la formule vrai soit satisfaite par tous les ´etats, il n’existe pas d’´etat pr´ec´edent
le premier ´etat d’une trace. En particulier, aucun ´etat pr´ec´edent σ(0) ne satisfait vrai.
La quatri`eme formule est une contradiction au niveau des contraintes temporelles. Elle
dit que q doit survenir avant p, et que p doit survenir avant q. Sans la partie p ∨q, cette
formule pourrait ˆetre satisfaite par les traces o` u p et q ne surviennent jamais.
Dans un mˆeme ordre d’id´ees, les formules qui sont satisfaites par tous les ´etats de
toutes les traces sont appel´ees des tautologies.
`
A priori, les tautologies et les contradic-
tions ne sont pas des politiques de s´ecurit´e pertinentes, puisque l’on sait `a l’avance si
elles seront satisfaites. Il serait donc utile de pouvoir les d´etecter `a l’avance. Une telle
d´etection constituerait une premi`ere ´etape en vue de la validation d’une politique.
`
A la
table 5.1, on peut voir un syst`eme de preuves `a base de tableaux permettant de v´erifier
si un ´etat d’une trace donn´ee satisfait une formule. Les trois premi`eres r`egles d’inf´e-
rence sont celles du calcul propositionnel, et les trois derni`eres concernent l’op´erateur
temporel [φ
1
, φ
2
]. Ce syst`eme de preuves ne permet cependant pas de v´erifier si une
formule donn´ee est une tautologie, une contradiction, ou ni l’une ni l’autre. Une avenue
possible pour la d´etection des tautologies et des contradictions pourrait ˆetre d’´etendre
ou de modifier ce syst`eme de preuves de fa¸con `a tenir compte des noeuds d´ej` a travers´es
dans l’arbre de preuves.
Un peu plus loin dans ce chapitre, nous proposerons cependant une autre fa¸con de
d´etecter les tautologies et les contradictions qui utilise seulement les trois premi`eres
r`egles de ce syst`eme de preuves. Juste avant, nous verrons comment il pourrait ˆetre
possible d’am´eliorer la s´emantique du langage que nous avons d´evelopp´e de fa¸con `a en
faire non-pas un simple langage de d´etection, mais aussi un langage de contrˆole. Nous
utilisons les terme contrˆole plutˆ ot que r´eaction pour mettre en ´evidence le fait que la
seule r´eaction permise par l’extension que nous proposons est de bloquer les actions
malicieuses. L’extension ne permet pas, telle quelle, d’engendrer des actions.
Chapitre 5. Travaux futurs 134
p ∈ σ(i)
p, σ(i)

φ, σ(i)
φ, σ(i)
φ
1
, σ(i) φ
2
, σ(i)
φ
1
∧ φ
2
, σ(i)


1
, φ
2
], σ(0)
φ
1
, σ(i −1)

1
, φ
2
], σ(i)

1
, φ
2
], σ(i −1) φ
2
, σ(i −1)

1
, φ
2
], σ(i)
Tab. 5.1 – Syst`eme de preuves `a base de tableaux.
5.2 Filtrage dynamique et s´emantique de symptˆome
Une tendance dans l’implantation de syst`emes de d´etection d’intrusions au niveau
r´eseau est d’incorporer ceux-ci `a des composantes du r´eseau qui ont le contrˆole du trafic
pouvant entrer et sortir du r´eseau [75, 76, 77, 78]. Les routeurs et les pare-feux sont
des exemples de telles composantes. Par exemple, on peut int´egrer Snort au syst`eme
d’exploitation d’un routeur et bloquer tous les paquets g´en´erant une alarme.
Le bien-fond´e d’une telle m´ethode de travail repose cependant sur l’hypoth`ese que
les signatures repr´esentent bel et bien les attaques, et non l’effet de celles-ci. En effet,
une tendance en d´etection d’intrusions est d’´ecrire des signatures qui ne lanceront des
alarmes que si l’effet de l’attaque est d´etect´e, et non l’attaque elle-mˆeme. Cette tech-
nique est principalement motiv´ee par le besoin de diminuer le nombre de faux positifs.
Prenons, par exemple, la propagation d’un vers dans un r´eseau local. Supposons qu’un
utilisateur A re¸coive par un courrier ´electronique envoy´e par son meilleur ami un petit
jeu rigolo permettant la fois de punir son politicien pr´ef´er´e `a l’aide d’un tue-mouche et
d’infecter son ordinateur d’un virus qui essayera alors de se propager aux stations de
travail avoisinantes. Le virus utilise alors chaque machine infect´ee comme relais pour
en infecter d’autres, et ainsi de suite. Supposons, de plus, que ce virus exploite une
vuln´erabilit´e du syst`eme d’exploitation Windows contre laquelle 117 stations des 120
du r´eseau local sont pr´emunies. Une signature concernant le comportement offensif g´e-
n´ererait alors des alarmes pour les 120 machines attaqu´ees, alors qu’une signature pour
l’effet de l’attaque ne g´en`ere des alarmes que pour les trois machines qui sont r´eellement
affect´ees. Le responsable de la s´ecurit´e du r´eseau peut alors r´eagir plus efficacement car
il sait exactement quelles sont les machines infect´ees.
Dans le cas du langage que nous avons d´evelopp´e, certaines des signatures que nous
Chapitre 5. Travaux futurs 135
Φ ::=

(attack[symptom)φ
j
σ [= Φ ssi σ(0) [=
σ
Φ
σ(i) [=
σ
Φ ssi ∀j.σ(i) [=
σ
φ
j
et si ∃φ
j
de type attack tel que σ(i) [=
σ
φ
j
alors σ(i + 1) [=
σ−σ(i)
Φ
et si ∃φ
j
de type attack tel que σ(i) [=
σ
φ
j
alors σ(i + 1) [=
σ
Φ
Tab. 5.2 – S´emantique de symptˆome.
avons propos´ees, notamment celles o` u on exprime l’´ecoulement d’un d´elai, l’´ev´enement
permettant de d´etecter l’attaque n’est pas du tout li´e `a celui correspondant au compor-
tement offensif en tant que tel. Prenons, par exemple, la formule synack∧[syn, 3]
2
→ack
dont nous avons discut´e `a la page 105. L’´ev´enement permettant la d´etection de l’attaque
est le premier suivant l’´ecoulement du d´elai, et cet ´ev´enement ne doit en aucun cas ˆetre
consid´er´e comme offensif. Il n’est qu’un symptˆome permettant la d´etection de l’attaque,
et ne fait pas partie l’attaque elle-mˆeme. C’est pourquoi un syst`eme de d´etection d’in-
trusions muni de fonctionnalit´es de contrˆ ole bloquant cet ´ev´enement commettrait alors
une erreur.
Une avenue possible pour s’attaquer `a ce probl`eme pourrait ˆetre de typer les formules
constituant une politique de s´ecurit´e de fa¸con `a diff´erencier les symptˆomes des attaques.
Dans le cas du langage LAMBDA [29], Cuppens et al. ont propos´e de partitionner
les actions en actions malicieuses et suspicieuses. Les actions suspicieuses ne sont pas
offensives en tant que telles, mais peuvent contribuer au succ`es d’une attaque. Les
actions malicieuses, elles, entrent directement en conflit avec la politique de s´ecurit´e.
L’approche que nous proposons ici a en commun avec celle de Cuppens le fait qu’elle
permet de mieux d´ecider quelles sont les actions qui doivent ˆetre bloqu´ees.
`
A la table 5.2, on voit comment on peut formaliser la r´edaction de politiques de
s´ecurit´e pour un syst`eme de d´etection d’intrusions avec capacit´es de contrˆ ole en utilisant
la dichotomie attaques/symptˆomes. Une politique de s´ecurit´e Φ est une conjonction de
r`egles φ
j
qui sont soit de type attack, soit de type symptom. Les r`egles φ
j
sont r´edig´ees
dans le langage que nous avons d´ej` a d´evelopp´e. Une trace d’´ev´enements satisfait la
politique Φ si elle est satisfaite depuis le premier ´ev´enement. Un ´ev´enement de la trace
satisfait la politique Φ si, en premier lieu, il satisfait toutes les r`egles. En second lieu, si
une r`egle de type attack a ´et´e viol´ee, l’´ev´enement courant doit ˆetre retir´e de la trace
Chapitre 5. Travaux futurs 136
q → [p, faux] ∧ r → [q, faux] p, q, r, . . .
Fig. 5.2 – Exemple de conflit.
avant de continuer la d´etection `a partir de l’´ev´enement suivant. Dans le cas o` u aucune
attaque n’a ´et´e rep´er´ee, l’´ev´enement courant est conserv´e dans la trace et on continue la
d´etection `a partir de l’´ev´enement suivant. L’action de retrait d’un ´ev´enement de la trace
mod´elise la capacit´e de contrˆole du syst`eme de d´etection d’intrusions. Si l’´ev´enement
est retir´e de la trace, alors son effet ne doit pas ˆetre pris en compte dans la poursuite
de la d´etection.
Une telle s´emantique permet de g´erer certains conflits au niveau de la politique
de s´ecurit´e. Oublions-la pour quelques instants et consid´erons la formule montr´ee `a la
figure 5.2. Elle dit que si q survient, alors il ne doit pas y avoir eu de p auparavant,
et que si r survient, alors il doit y avoir eu un q auparavant. La trace p, q, r, . . . ne
satisfait pas cette formule, car elle pr´esente un q pr´ec´ed´e d’un p. En supprimant ce q,
on obtient la trace p, r, . . ., qui ne satisfait pas non-plus la formule, car elle pr´esente
un r qui n’est pas pr´ec´ed´e d’un q. On a donc un conflit entre la satisfaction de la
sous-formule q → [p, faux] et la sous-formule r → [q, faux]. Maintenant, revenons `a
notre s´emantique de symptˆomes et supposons que l’on ait la chance de travailler dans
un contexte o` u la premi`ere sous-formule repr´esente un symptˆome et la seconde une
attaque. En conservant l’´ev´enement q, on obtient une trace o` u seulement un ´ev´enement
contrevient `a la politique, alors qu’en supprimant cet ´ev´enement, la politique ´etait viol´ee
`a deux endroits. De plus, nous sommes certains que nous avons bien fait de conserver q
puisque sa s´emantique n’est pas offensive.
5.3 Synth`ese de contrˆ oleur
Au chapitre d’introduction de ce m´emoire, nous avons dit que le travail que nous
allions effectuer s’inscrivait dans un contexte de validation, au sens o` u le probl`eme
auquel nous nous attaquions concernait la v´erification de certaines traces d’ex´ecution
d’un syst`eme donn´e, et non celle de toutes ses traces d’ex´ecution possibles. Cependant,
lorsque l’on commence `a donner la possibilit´e au programme de v´erification de modifier
le mod`ele en cours d’ex´ecution, il ne s’agit plus d’un probl`eme de validation tant que
d’un probl`eme de synth`ese. Un tel programme de v´erification, que l’on appellera d`es
lors contrˆoleur, peut ˆetre vu comme partie int´egrante du syst`eme en cours de validation,
Chapitre 5. Travaux futurs 137
et le probl`eme de la synth`ese du contˆoleur pourra alors s’´enoncer comme suit :
Probl`eme 5.1
´
Etant donn´e un programme P, une propri´et´e φ, et une loi de composi-
tion de programmes , g´en´erer un programme C tel que C P [= φ.
Ce probl`eme a d´ej` a ´et´e largement explor´e dans la litt´erature [79, 80, 81, 82], et
son niveau de difficult´e varie d´ependemment de l’alg`ebre utilis´ee pour repr´esenter P
et C et de la logique utilis´ee pour exprimer φ. Or, il y a fortement lieu de penser que
lorsque φ est exprim´ee avec le cas propositionnel de la logique que nous avons utilis´ee
pour d´evelopper notre langage, et que l’alg`ebre utilis´ee est celle des automates finis, la
r´esolution de ce probl`eme d´epend uniquement de φ.
A ::= 0 [ a.A
1
[ A
1
+ A
2
[ A
1
A
2
Tab. 5.3 – Syntaxe de l’alg`ebre des automates.

(0) = ¦stop¦

(a.A
1
) = a.

(A
1
)

(A
1
+ A
2
) =

(A
1
) ∪

(A
1
)

(A
1
A
2
) =

(A
1
) ∩

(A
2
)
avec a.

(A) = ¦a.σ [ σ ∈

(A)¦
Tab. 5.4 – S´emantique de l’alg`ebre des automates.
Avant d’aller plus loin dans l’annonce des conjectures auxquelles nous comptons
nous attaquer, d´efinissons pr´ecis´ement de quels automates nous parlons. La syntaxe de
l’alg`ebre des automates est pr´esent´ee `a la table 5.3. Un automate est soit l’automate ne
pouvant faire aucune action (0), soit un automate pouvant faire une action a avant de
devenir un autre automate (a.A
1
), soit un automate pouvant arbitrairement adopter le
comportement de deux autres automates (A
1
+ A
2
), soit le produit synchrone de deux
automates (A
1
A
2
). Nous n’avons pas besoin, pour la port´ee de notre propos, de d´efinir
le parall´elisme entre deux automates ni de s’attarder `a d´efinir une relation d’´equiva-
lence. C’est pourquoi nous ne parlons pas ici d’alg`ebre de processus, mais simplement
d’automates. Aussi, comme tout notre int´erˆet tourne autour des traces d’ex´ecution de
ces automates, la s´emantique que nous leur accordons est directement exprim´ee en fonc-
tion de ces traces. L’automate 0 ne peut faire que l’action stop et s’arrˆeter. L’automate
Chapitre 5. Travaux futurs 138
TCP ::= rst.TCP + syn.S
2
S
2
::= rst.TCP + synack.S
3
S
3
::= rst.TCP + ack.Session
Session ::= rst.TCP + fin.TCP
Fig. 5.3 – Automate TCP.
Contr ::= rst.Contr + syn.C
2
C
2
::= synack.C
3
C
3
::= rst.Contr + ack.Session
Session ::= rst.Contr + fin.Contr
Fig. 5.4 – Contrˆoleur pour l’automate TCP relativement `a (rst ∧ [synack, ack]).
a.A
1
peut faire l’action a, suivie de toutes les traces que peut effectuer l’automate A
1
.
L’automate A
1
+ A
2
peut faire toutes les traces de A
1
, de mˆeme que toutes celles de
A
2
. Finalement, l’automate A
1
A
2
peut faire les traces que A
1
et A
2
peuvent faire.
`
A la figure 5.3, on voit comment on peut utiliser cette alg`ebre pour repr´esenter une
version tr`es simplifi´ee de l’automate TCP. Cet automate peut compl´eter une poign´ee de
main (syn.synack.ack) pour devenir l’automate repr´esentant une session. Une session
peut se terminer en posant une action fin avant de retourner `a l’´etat initial. Aussi, peu
importe dans quel ´etat il se trouve, l’action rst retourne `a l’´etat initial. On remarque
que cet automate est d´eterministe, mais pas compl`etement d´efini. Il aurait aussi bien
pu ne pas ˆetre d´eterministe.
Maintenant que nous avons d´efini notre alg`ebre, nous sommes en mesure de d´efinir
ce qu’est, dans notre cas, un contrˆoleur pour un automate relativement `a une formule φ :
D´efinition 5.2 Un automate A
1
contrˆ ole un automate A
2
relativement `a une formule
φ si pour toute trace σ ∈

(A
2
), σ ∈

(A
1
A
2
) ⇔ σ [= φ.
Supposons, par exemple, que l’on veuille contrˆ oler la propri´et´e : l’action rst ne doit
pas ˆetre pos´ee entre un synack et un ack. Dans notre logique, cette propri´et´e se formule
Chapitre 5. Travaux futurs 139
S := 2
[φ]
, avec [φ] = ¦[φ
1
, φ
2
] ∈ sub(φ)¦
Act := 2
P
s
0
:= ∅
s
1
a
→s
2
ssi ϕ(s
1
) ∧ ϕ(a) ¬ φ
et σ(i) [= ϕ(s
1
) ∧ ϕ(a) implique σ(i + 1) [= ϕ(s
2
)
ϕ(s) :=

φ
i
∈s
1
φ
i


φ
i
∈s
1
φ
i
ϕ(a) :=

p∈a
p ∧

p∈a
p
Tab. 5.5 – Algorithme de synth`ese de contrˆ oleur.
de la fa¸con suivante : (rst ∧ [synack, ack]). En effet, cet automate engendre toutes
les mˆemes traces que celui de l’automate TCP, sauf celles o` u un rst survient entre un
synack et un ack.
Nous avons construit cet automate de fa¸con ad-hoc, sans vraiment suivre de m´ethode
particuli`ere. Rien ne nous pousse `a croire que cette solution ´etait l’unique solution. En
particulier, si le contrˆoleur que nous avons d´efini avait ´et´e capable d’engendrer des traces
que l’automate TCP n’´etait pas capable d’engendrer, celle-ci auraient ´et´e supprim´ees
par l’op´eration de produit. Donc, si on ´etait capable, ´etant donn´ee une formule φ, de
donner un automate engendrant toutes les traces σ telles que σ [= φ, le probl`eme de la
synth`ese du contrˆ oleur tel que nous l’avons ´enonc´e serait r´esolu une fois pour toutes.
Ceci nous am`ene `a d´efinir la notion de contrˆ oleur universel :
D´efinition 5.3 Un automate A est un contrˆoleur universel pour une formule φ si pour
toute trace σ, σ ∈

(A) ⇔ σ [= φ. Si A est un contrˆoleur universel pour φ, on dit que
A impl´emente φ.
Comme nous avons d´ej`a donn´e un algorithme de v´erification pour notre logique, on
devrait s’attendre `a pouvoir transformer cet algorithme en automate et ainsi de pouvoir
d´efinir un contrˆoleur universel pour n’importe quelle formule φ. Cette transformation
donne exactement l’automate d´efini `a la table 5.5. L’ensemble des ´etats correspond
exactement `a l’ensemble des valeurs pouvant ˆetre prises par l’ensemble k de l’algorithme
Chapitre 5. Travaux futurs 140
L(C) = ∅
L(C
1
) = ¦[synack, ack]¦
C := synack.C
1
+ ack.C + rst.C
+syn.C + fin.C
C
1
:= synack.C
1
+ ack.C
+syn.C
1
+ fin.C
1
Fig. 5.5 – Contrˆ oleur universel pour (rst ∧ [synack, ack]).
de v´erification pr´esent´e `a la table 4.7 (page 116). L’ensemble des actions pouvant ˆetre
pos´ees correspond `a l’ensemble des ´ev´enements (une action ou un ´ev´enement est un
ensemble de constantes propositionnelles). Une action a effectu´ee `a partir d’un ´etat
s
1
m`ene `a un ´etat s
2
si le fait de poser cette action, dans l’´etat s
1
, ne m`ene pas `a
une violation de la propri´et´e φ et si, une fois l’action pos´ee, la connaissance accumul´ee
correspond `a celle repr´esent´ee dans l’´etat s
2
. Comme l’´evolution de la connaissance est
d´efinie de fa¸con unique, il ne peut y avoir qu’un seul ´etat s
2
d´efini pour s
1
et a. De plus,
comme toute l’information pertinente concernant les actions pos´ees jusqu’` a maintenant
est accumul´ee dans l’´etat s
1
, les r`egles d’inf´erences du calcul propositionnel (les trois
premi`eres de la table 5.1) suffisent pour d´ecider si le fait de poser l’action a viole le
propri´et´e φ. Finalement, si le fait de poser l’action a m`ene `a une violation de φ, l’´etat
s
1
n’a pas de transition sortante pour a.
`
A la figure 5.5, se trouve un contrˆoleur universel pour la formule (rst∧[synack, ack]).
Il poss`ede deux ´etats, celui o` u la formule [synack, ack] est vraie, et celui o` u elle ne l’est
pas. Les actions synack et ack font passer d’un ´etat `a l’autre. Lorsque la formule
[synack, ack] est vraie, il est impossible de poser l’action rst. Toutes les autres actions
sont possibles et ne changent pas l’´etat courant.
Nous ´enon¸cons maintenant deux r´esultats que nous contons d´emontrer dans les mois
`a suivre. Le premier dit que l’automate d´efini `a la table 5.5 impl´emente bien la propri´et´e
φ pour laquelle il est d´efini, et le second nous dit comment on peut utiliser cet automate
pour trouver des tautologies et des contradictions.
Conjecture 5.4 Pour toute formule φ, l’automate d´efini `a la table 5.5 impl´emente φ.
Conjecture 5.5 Une formule φ est une contradiction (n’est pas satisfiable) si l’auto-
mate d´efini `a la table 5.5 n’engendre pas de traces, et elle est une tautologie si il est
compl`etement d´efini.
Chapitre 5. Travaux futurs 141
Une fois ces r´esultats d´emontr´es, il faudra voir comment on peut adapter ces id´ees
`a la logique du premier ordre de la logique que nous avons utilis´ee pour notre langage.
Aussi, il faudra voir comment on peut incorporer les concepts de symptˆ ome et d’attaque
au probl`eme de synth`ese du contrˆoleur. Certainement, l’alg`ebre des automates, avec son
produit compl`etement synchrone, ne suffira plus. Il faudra voir comment on peut d´efinir
une loi de composition permettant un contrˆole partiel, au sens o` u la violation d’un
certain sous-ensemble de la politique ne bloque pas compl`etement le syst`eme contrˆol´e,
mais seulement certaines de ses actions. Certains travaux ont d´ej` a ´et´e effectu´es dans
cette direction dans [83].
Conclusion
Dans ce travail, nous avons ´etabli les bases d’un nouveau langage de signatures
d’attaques pour un syst`eme de d´etection d’intrusions et d’acquisition passive d’infor-
mation. Nous avons commenc´e par effectuer un ´etat de l’art des langages de signatures
d´ej`a existants. Nous avons donn´e un nouveau syst`eme de classification des langages
de signatures, que nous avons r´epartis en cinq cat´egories, en fonction des paradigmes
utilis´es pour d´efinir les langages. Nous avons aussi, suite `a cette ´etude, dress´e une liste
de dix propri´et´es identifi´ees comme souhaitables pour le langage de signatures d’un
syst`eme de d´etection d’intrusions.
Une des cinq cat´egories selon lesquelles nous avons class´e les langages des syst`emes `a
base de signatures est celle de ceux bas´es sur des logiques temporelles. Comme cette voie
nous semblait ˆetre la plus prometteuse, nous avons ensuite approfondi nos connaissances
en logiques temporelles. Nous avons trouv´e que plusieurs logiques avaient ´et´e d´evelop-
p´ees pour r´epondre `a plusieurs besoins. Les diff´erences les plus importantes entre ces
logiques, ´etant donn´es nos besoins, sont la direction des op´erateurs temporels (pass´es
ou futur), et la capacit´e d’exprimer des contraintes de temps-r´eel.
Une fois r´ealis´ee l’´etude des logiques, nous avons d´efini et impl´ement´e un langage de
signatures ayant la capacit´e d’acqu´erir passivement de l’information dans le principal
but d’effectuer une d´etection d’intrusions plus pr´ecise. Le syst`eme r´esultant pr´esentait
une architecture `a deux niveaux, avec une s´eparation claire entre les sc´enarios et la
connaissance acquise. La partie du langage servant `a repr´esenter les sc´enarios pouvait
ˆetre vus comme un sous-ensemble d’une logique temporelle future, `a laquelle nous avons
ajout´e la capacit´e de r´ef´erer `a certains ´ev´enements pass´es. Bien que le syst`eme mis
en oeuvre ne comportait pas encore toutes les caract´eristiques recherch´ees, le langage
d´evelopp´e a permis de clarifier nos id´ees quand `a la fa¸con dont devrait se formaliser
l’acquisition passive d’information.
Nous avons alors d´efini un second langage, cette fois bas´e sur une logique temporelle
pass´ee. Il s’est av´er´e qu’en plus que d’ˆetre beaucoup mieux adapt´e `a la surveillance de
Conclusion 143
syst`eme en temps-r´eel et `a l’acquisition passive d’information, la syntaxe du langage
obtenu ´etait beaucoup plus simple (du moins de notre point de vue) et surtout, beau-
coup plus souple au niveau des diff´erentes fa¸cons de composer les op´erateurs entre eux.
Nous avons aussi, dans cette seconde partie du travail, r´ealis´e l’importance du choix du
mod`ele. Il ´etait clair depuis le d´ebut qu’un mod`ele propositionnel ne pourrait pas suffire
`a la tˆache. Nous avons alors opt´e pour un mod`ele d’enregistrements, mod`ele souvent
utilis´e dans les syst`emes que nous avons ´etudi´es. Ce mod`ele imposait cependant une
certaine vision de la r´ealit´e : tous les ´ev´enements sont caract´erisables par un ensemble
donn´e de champs attribut-valeur. Nous avons r´ealis´e apr`es coup que cette vision ne col-
lait pas d’assez pr`es `a la r´ealit´e, et nous avons dˆ u red´efinir un mod`ele bas´e cette fois sur
un principe d’unification. Bien que les m´ecanismes d’unification alourdissent quelque
peu les algorithmes de v´erification, nous trouvons qu’il vaut la peine d’opter pour ce
choix, puisqu’il permet de r´ediger des signatures sans se soucier de la pr´esence ou non
de certains attributs.
Finalement, nous avons vu comment le choix d’un langage bas´e sur une logique
temporelle ouvrait la voie `a d’autres travaux de nature th´eorique orient´es vers l’appli-
cation. Entre autres, ce choix permet de d´efinir un algorithme permettant de v´erifier
la coh´erence de la base de signatures, il permet aussi d’´etendre le langage de fa¸con `a
permettre au syst`eme de d´etection d’intrusions de bloquer uniquement les actions ma-
licieuses, et il permet finalement de g´en´erer automatiquement un contrˆoleur pour une
politique donn´ee.
Au moment de la r´edaction de ce m´emoire, l’impl´ementation d’une version inter-
pr´et´ee du second langage que nous avons sp´ecifi´e est en cours de d´eveloppement en
collaboration avec le Centre de Recherches sur les Communications. Nous pr´evoyons
faire fonctionner ce prototype de pair avec le syst`eme de d´etection d’intrusions Snort
et le logiciel de capture et de d´ecodage de paquets Ethereal. Nous envisageons aussi
d’impl´ementer une version compil´ee de ce langage. Les signatures seront traduites vers
un autre langage, probablement C ou C++. Finalement, une autre voie d’extension sera
de la faire fonctionner au niveau hˆ ote, en utilisant comme source d’´ev´enements un outil
tel que strace.
Bibliographie
[1] C. Green and M. Roesch, “Snort users manual 2.1.0 - the snort project,” Dec. 2003.
[2] C. Michel and L. M´e, “Adele : an attack description language for knowledge-based
intrusion detection,” in Proceedings of the 16th International Conference on
Information Security (IFIP/SEC 2001), June 2001, pp. 353–365. [Online].
Available : citeseer.ist.psu.edu/michel01adele.html
[3] D. Spinellis and D. Gritzalis, “Panoptis : Intrusion detec-
tion using a domain-specific language,” Journal of Compu-
ter Security, vol. 10, pp. 159–176, 2002. [Online]. Available :
http://www.dmst.aueb.gr/dds/pubs/jrnl/2002-JCS-Panoptis/html/paper.html
[4] V. Jacobson, C. Leres, and S. McCanne, “tcpdump man page,”
http://www.tcpdump.org/tcpdump man.html.
[5] ——, “libpcap man page,” http://www.tcpdump.org/pcap3 man.html, Nov. 2003.
[6] C. Giovanni, “Fun with packets : Designing a stick,”
http://packetstormsecurity.nl/distributed/stick.htm.
[7] Fyodor, “The art of port scanning,”http://www.insecure.org/nmap/nmap doc.html,
1997.
[8] R. Deraison, R. Gula, and T. Hayton, “Passive vulnerability scanning- an intro-
duction to nevo,” http://www.tenablesecurity.com/papers.html, august 2003.
[9] R. Gula, “Correlating ids alerts with vulnerability information,”
http://www.tenablesecurity.com/papers.html, december 2002.
[10] H. D. B. Morin, L. M´e and M.Ducass´e, “M2d2 : A formal data model for ids
alert correlation,”in 5th International Conference on Recent Advances in Intrusion
Detection (RAID 2002), ser. LNCS, vol. 2516. Zurich : Springer, October 2002,
pp. 177–198.
[11] H. Anderson, “Introduction to nessus,”http://www.securityfocus.com/infocus/1741,
october 2003.
[12] ——, “Nessus, part 2 : Scanning,”http://www.securityfocus.com/infocus/1753, de-
cember 2003.
Bibliographie 145
[13] ——, “Nessus, part 3 : Analysing reports,”
http://www.securityfocus.com/infocus/1759, february 2004.
[14] N. Habra, B. L. Charlier, A. Mounji, and I. Mathieu, “ASAX : Software
architecture and rule- based language for universal audit trail analysis,” in
European Symposium on Research in Computer Security (ESORICS), 1992, pp.
435–450. [Online]. Available : citeseer.ist.psu.edu/habra92asax.html
[15] ——, “Preliminary report on advanced security audit trail analysis on unix
(asax also called satx),” Institut D’Informatique, FUNDP, rue Grangagnage
21, 5000 Namur, Belgium, Tech. Rep., September 1994. [Online]. Available :
citeseer.ist.psu.edu/366932.html
[16] A. Mounji, “Languages and tools for rule-based distributed intrusion detection,”
Ph.D. dissertation, Facult´es Universitaires Notre-Dame de la Paix, Namur, Bel-
gique, 1997.
[17] V. Paxson, “Bro : a system for detecting network intruders in real-time,” Computer
Networks (Amsterdam, Netherlands : 1999), vol. 31, no. 23–24, pp. 2435–2463,
1999. [Online]. Available : citeseer.ist.psu.edu/paxson98bro.html
[18] S. Eckmann, G. Vigna, and R. Kemmerer, “Statl : An attack lan-
guage for state-based intrusion detection,” 2000. [Online]. Available :
citeseer.ist.psu.edu/article/eckmann00statl.html
[19] K. Ilgun, “USTAT : A real-time intrusion detection system for UNIX,” in Procee-
dings of the 1993 IEEE Symposium on Research in Security and Privacy, Oakland,
CA, 1993, pp. 16–28. [Online]. Available : citeseer.ist.psu.edu/ilgun92ustat.html
[20] G. Vigna and R. A. Kemmerer, “Netstat : A network-based intrusion
detection approach,” in ACSAC, 1998, pp. 25–. [Online]. Available :
citeseer.ist.psu.edu/vigna98netstat.html
[21] S. Kumar and E. Spafford, “An Application of Pattern Matching in Intrusion
Detection,” Department of Computer Sciences, Tech. Rep. 94-013, 1994. [Online].
Available : citeseer.ist.psu.edu/article/kumar94application.html
[22] S. Kumar, “Classification and detection of computer intru-
sions,” Ph.D. dissertation, Purdue, IN, 1995. [Online]. Available :
citeseer.ist.psu.edu/kumar95classification.html
[23] S. Kumar and E. Spafford, “A software architecture to support misuse intrusion
detection,” in Proceedings of the 18th National Information Security Conference,
1995, pp. 194–204. [Online]. Available : citeseer.ist.psu.edu/kumar95software.html
[24] R. Sekar, Y. Guang, S. Verma, and T. Shanbhag, “A high-
performance network intrusion detection system,” in ACM Symposium
on Computer and Communication Security, 1999. [Online]. Available :
http://seclab.cs.sunysb.edu/seclab/pubs/papers.htm
Bibliographie 146
[25] R. Sekar and P. Uppuluri, “Synthesizing fast intrusion detection/prevention
systems from high-level specifications,” in USENIX Security Symposium, 1999.
[Online]. Available : http://seclab.cs.sunysb.edu/seclab/pubs/papers.htm
[26] U. Lindqvist and P. A. Porras, “Detecting computer and network misuse through
the production-based expert system toolset (p-best),” in Proceedings of the
1999 IEEE Symposium on Security and Privacy. Oakland, California : IEEE
Computer Society Press, Los Alamitos, California, may 1999, pp. 146–161.
[Online]. Available : http://www.sdl.sri.com/papers/pbest-sp99-cr/
[27] Anderson, Lunt, Javits, Tamaru, and Valdes, “NIDES : software
users manual — beta-update release,” dec 1994. [Online]. Available :
http://www.sdl.sri.com/papers/7sri/
[28] Anderson, Frivold, and Valdes, “NIDES : A summary,” may 1995. [Online].
Available : http://www.sdl.sri.com/papers/4sri/
[29] F. Cuppens and R. Ortalo, “Lambda : A language to model a database for detection
of attacks,”in Proceedings of the Third International Workshop on Recent Advances
in Intrusion Detection. Springer-Verlag, 2000, pp. 197–216.
[30] F. Sadri and R. A. Kowalski, “Variants of the event calculus,” in International
Conference on Logic Programming, 1995, pp. 67–81. [Online]. Available :
citeseer.ist.psu.edu/522892.html
[31] G. Rosu and K. Havelund, “Synthesizing dynamic programming algorithms from
linear temporal logic formulae,” 2000.
[32] M. Roger and J. Goubault-Larrecq, “Log auditing through model checking,” in
Proc. 14th IEEE Computer Security Foundations Workshop (CSFW’01), Cape
Breton, Nova Scotia, Canada, June 2001. IEEE Comp. Soc. Press, 2001, pp.
220–236. [Online]. Available : citeseer.ist.psu.edu/article/roger01log.html
[33] P. Wolper, “Temporal logic can be more expressive,” Information and Control, vol.
56(1–2), pp. 72–99, 1983.
[34] H. Barringer, A. Goldberg, K. Havelund, and K. Sen, “Rule-based runtime verifi-
cation,” 2004. [Online]. Available : citeseer.ist.psu.edu/barringer04rulebased.html
[35] P. Naldurg, K. Sen, and P. Thati, “A temporal logic based framework for intrusion
detection.” [Online]. Available : citeseer.ist.psu.edu/naldurg04temporal.html
[36] K. Sen, G. Rosu, and G. Agha, “Online efficient predictive sa-
fety analysis of multithreaded programs,” 2004. [Online]. Available :
citeseer.ist.psu.edu/sen04online.html
[37] C. Dousson, “Suivi d’´evolutions et reconnaissance de chroniques,” Ph.D.
dissertation, Universit´e Paul Sabatier de Toulouse, september 1994. [Online].
Available : http://dli.rd.francetelecom.fr/abc/diagnostic/
Bibliographie 147
[38] B. Morin and H. Debar, “Correlation of intrusion symptoms : an application of
chronicles,” in 6th International Conference on Recent Advances in Intrusion De-
tection (RAID 2003), ser. LNCS, vol. 2820. Pittsburg : Springer, September 2003.
[39] H. Debar, D. Curry, and B. Feinstein, “Intrusion detection exchange format,”
http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-12.txt, july 2004,
internet-Draft.
[40] R. Deraison, “The nessus attack scripting language reference guide,”
http://www.nessus.org/doc/nasl.html, april 2000.
[41] I. Secure Networks, “Custom attack simulation language (casl),”
http://www.sockpuppet.org/tqbf/casl.html, 1997.
[42] J.-P. Pouzol and M. Ducass´e, “Formal specification of intrusion signatures and
detection rules,” in Proceedings of the 15th IEEE Computer Security Foundations
Workshop (CSFW’02). IEEE Computer Society, 2002, p. 64.
[43] Lin, Wang, and Jajodia, “Abstraction-based misuse detection : High-level
specifications and adaptable strategies,” in PCSFW : Proceedings of The 11th
Computer Security Foundations Workshop. IEEE Computer Society Press, 1998.
[Online]. Available : citeseer.ist.psu.edu/lin98abstractionbased.html
[44] L. M´e, “Gassata, a genetic algorithm as an alternative tool for security audit trails
analysis,”First International Workshop on Recent Advances in Intrusion Detection
(RAID ’98), 1998.
[45] M. Crosbie and E. H. Spafford, “Applying genetic programming to intrusion
detection,” in Working Notes for the AAAI Symposium on Genetic Programming,
E. V. Siegel and J. R. Koza, Eds. MIT, Cambridge, MA, USA : AAAI, 10–12
1995, pp. 1–8. [Online]. Available : citeseer.ist.psu.edu/crosbie95applying.html
[46] D. Song, M. I. Heywood, and A. N. Zincir-Heywood, “A linear genetic program-
ming approach to intrusion detection,”in Genetic and Evolutionary Computation –
GECCO-2003, ser. LNCS, vol. 2724. Chicago : Springer-Verlag, 12-16 July 2003,
pp. 2325–2336.
[47] R. Lippmann, D. Fried, I. Graf, J. Haines, K. Kendall, D. McClung, D. Weber,
S. Webster, D. Wyschogrod, R. Cunningham, and M. Zissman, “Evaluating
intrusion detection systems : The 1998 DARPA off-line intrusion detection
evaluation,” in Proceedings of the DARPA Information Survivability Conference
and Exposition. Los Alamitos, CA : IEEE Computer Society Press, 2000.
[Online]. Available : citeseer.ist.psu.edu/lippmann00evaluating.html
[48] R. Lippmann, J. W. Haines, D. J. Fried, J. Korba, and K. Das, “The 1999 darpa off-
line intrusion detection evaluation,” Comput. Networks, vol. 34, no. 4, pp. 579–595,
2000.
[49] D. V. McDermott, “A temporal logic for reasoning about processes and plans,”
Cognitive Science, pp. 101–155, 1982.
Bibliographie 148
[50] J. F. Allen and G. Ferguson, “Actions and events in interval temporal logic, Tech.
Rep. TR521, 1994. [Online]. Available : citeseer.ist.psu.edu/allen94actions.html
[51] F. Bacchus, J. Tenenberg, and J. Koomen, “A non-reified temporal logic,” in Pro-
ceedings of the First International Conference on Principles of Knowledge Repre-
sentation and Reasoning, R. Brachman, H. Levesque, and R. Reiter, Eds. Toronto,
Ontario, Canada : Morgan Kaufmann, May 1989, pp. 2–10.
[52] O. Lichtenstein and A. Pnueli, “Checking that finite state concurrent programs sa-
tisfy their linear specification,”in Proceedings of the 12th ACM SIGACT-SIGPLAN
symposium on Principles of programming languages, 1985.
[53] D. Kozen, “Results on the propositional mu-calculus,” Theoretical Computer
Science, vol. 27, pp. 333–354, 1983.
[54] E. A. Emerson and J. Y. Halpern, “Sometimes and not never revisited : on bran-
ching versus linear time temporal logic,” Journal of the ACM, vol. 33, no. 1, pp.
151–178, 1986.
[55] E. A. Emerson and C. L. Lei, “Modalities for model checking : Branching time
logics strikes back,” in Proceedings of the First Symposium on Logic in Computer
Science, Cambridge, June 1986, pp. 267–278.
[56] R. Alur and T. A. Henzinger, “A really temporal logic,” in IEEE Symposium on
Foundations of Computer Science, 1989.
[57] J. Ma and B. Knight, “Reified temporal logics : An overview,”Artificial Intelligence
Review, vol. 15, no. 3, pp. 189–217, May 2001.
[58] T. Wilke, “Ctl+ is exponentially more succinct than ctl,” in 19th Conf. Found.
of Software Technology and Theor. Comp. Sci., ser. Lecture Notes in Computer
Science, vol. 1738. Springer, 1999, pp. 110–121.
[59] G. J. Holzmann, “The model checker SPIN,” IEEE Trans. Softw. Eng., vol. 23,
no. 5, pp. 279–295, 1997.
[60] Z. Manna and A. Pnueli, “Verification of concurrent programs : The temporal
framework, in the correctness problem in computer science,” International Lecture
Series in Computer Science, 1981.
[61] D. M. Gabbay, “The declarative past and imperative future : Executable temporal
logic for interactive systems,” in Conference on Temporal Logic in Specification,
ser. Lecture Notes in Computer Science, H. B. Behnam Banieqbal and A. Pnueli,
Eds., vol. 398. Springer, 1989, pp. 409–448.
[62] P. Thati and G. Ro¸su, “Monitoring algorithms for metric temporal logic specifica-
tions,” in Runtime Verification 2004 (RV04), 2004.
[63] F. Laroussine and P. Schnoebelen, “A hierarchy of temporal logics with past,”
Theoritical Computer Science, vol. 48, no. 2, pp. 303–324, 1995.
Bibliographie 149
[64] N. M. Fran¸cois Laroussine and P. Schnoebelen, “Temporal logic with forgettable
past,” in Proceeding of the 17th Symposium on Logic in Computer Science (LICS
2002), I. C. S. Press, Ed., Copenhagen, Denmark, July 2002, pp. 383–392.
[Online]. Available : http://www.lsv.ens-cahan.fr/Publis/
[65] A. Tarski, “A lattice-theoretical fixpoint theorem and its applications,” Pacific
Journal of Mathematics, vol. 5, pp. 285–309, 1955.
[66] T. Henzinger, “The temporal specification and verification of real-time systems,”
Ph.D. dissertation, Stanford University, 1991.
[67] T. A. Henzinger, X. Nicollin, J. Sifakis, and S. Yovine, “Symbolic model checking
for real-time systems,” in 7th. Symposium of Logics in Computer Science, 1992.
[68] R. Koymans, “Specifying real-time properties with metric temporal logic,” Real-
Time Syst., vol. 2, no. 4, pp. 255–299, 1990.
[69] C. Ghezzi, D. Mandrioli, and A. Morzenti, “Trio : A logic language for executable
specifications of real-time systems,” J. Syst. Softw., vol. 12, no. 2, pp. 107–123,
1990.
[70] M. Zalewski, “Passive os fingerprinting,” http://lcamtuf.coredump.cx/p0f.shtml,
2000–2003.
[71] Fyodor, “Remote os detection via tcp/ip stack fingerprinting,”
http://www.insecure.org/nmap/nmap-fingerprinting-article.html, 1998.
[72] S. Stevenson, “Bibliography on prolog,”Department of Computer Science, Clemson
University, Clemson, SC 29634-1906, USA.
[73] A. DeMontigny-Leboeuf, “A multi-packet signature approach to passive opera-
ting system detection,” CRC/DRDC joint Technical Report CRC-TN-2005-001 /
DRDC-Ottawa-TM-2005-018, December 2004.
[74] “Bugtraq homepage,” http://www.securityfocus.org/.
[75] The NSS Group, “Intrusion prevention systems (ips),”
http://www.nss.co.uk/WhitePapers/intrusion prevention systems.htm, january
2004.
[76] Cisco Systems, “Cisco ios ips,” http://www.cisco.com/, 2004.
[77] Top Layer, “Network intrusion prevention solutions for the enterprise,”
http://www.toplayer.com/pdf/sbEnterprise.pdf.
[78] J. Buzbee, “Snort on the wrt54g,”http://www.batbox.org/wrt54g.html, September
2003.
[79] H. Bherer, “Synth`ese de contrˆoleurs,” D´epartement d’informatique, Universit´e La-
val,” Rapport d’examen de synth`ese, july 2001.
[80] R. Kh´edri, “Concurrence, bisimulations et ´equation d’interface : une approche rela-
tionnelle,”th`ese de doctorat, D´epartement d’informatique, Universit´e Laval, august
1998.
Bibliographie 150
[81] M. Barbeau, F. Kabanza, and R. St.-Denis, “A method for the synthesis of control-
lers to handle safety, liveness, and real-time constraints,” IEEE Transactions on
Automatic Control, vol. 43, no. 11, pp. 1543–1559, Novembre 1998.
[82] R. St-Denis, “Designing reactive systems : integration of abstraction techniques
into a synthesis procedure,” J. Syst. Softw., vol. 60, no. 2, pp. 103–112, 2002.
[83] A. Lacasse, M. Mejri, and B. Ktari, “Formal implementation of network security
policies,”in Second Annual Conference on Privacy, Security and Trust,, Wu Centre,
University of New Brunswick, Fredericton, New Brunswick, Canada, October 2004.

R´sum´ e e
Dans ce travail, nous proposons un nouveau langage d´di´ ` la d´tection d’intrue e a e sions. Il s’agit d’un langage purement d´claratif, bas´ sur une logique temporelle lin´aire e e e pass´e avec pr´dicats du premier ordre. Apr`s avoir effectu´ une revue de treize lane e e e gages de d´tection d’intrusions existant d´j`, nous donnons une liste de dix propri´t´s e ea ee souhaitables pour un langage de d´tection d’intrusions. Contrairement au langage que e nous proposons, aucun des langages ´tudi´s ne pr´sente ` la fois ces dix propri´t´s. En e e e a ee plus d’ˆtre suffisamment expressif pour r´pondre aux besoins identifi´s, il vient avec un e e e algorithme de v´rification qui s’ex´cute en temps lin´aire avec la quantit´ d’information e e e e analys´e et utilise une quantit´ born´e d’espace m´moire. Ces deux propri´t´s pere e e e ee mettent de prot´ger le syst`me de d´tection d’intrusions contre d’´ventuelles attaques e e e e d’inondation.

Avant-propos
Je d´sire d’abord remercier ma m`re, qui a su me donner le goˆt des ´tudes, ainsi e e u e que mon p`re, qui m’a appris l’importance de l’int´grit´ et de la transparence. Je les e e e remercie tous les deux pour le support et les encouragements qu’ils m’ont donn´ tout e au long de mon cheminement, autant personnel qu’acad´mique. e Je remercie aussi mon directeur de recherches, le professeur B´chir Ktari, pour avoir e accept´ de me diriger dans un domaine aussi stimulant, et pour la confiance qu’il m’a e montr´e tout au long de ces deux ann´es de travail. J’adresse aussi mes remerciements e e ` Fr´d´ric Massicotte, ami et collaborateur au Centre de Recherches sur les Communia e e cations, qui a su ` plusieurs occasions me donner des critiques constructives sur mon a travail. Je le remercie aussi pour son sens aigu du bien-ˆtre d’autrui, qu’il a su en partie e me communiquer. Je tiens aussi ` exprimer ma reconnaissance envers les professeurs a Jos´e Desharnais et Mohamed Mejri qui ont accept´ d’´valuer ce m´moire. Je remere e e e cie le personnel administratif du d´partement d’informatique, et plus particuli`rement e e Lynda Goulet, pour sa bonne humeur et les nombreux services qu’elle m’a rendus. Je remercie le Centre de Recherches sur les Communications, pour son support mat´riel et financier, le Gouvernement Fran¸ais, pour m’avoir accueilli et avoir financ´ e c e en partie mes recherches, de mˆme que les professeurs Andr´-Luc Beylot, Marc Boyer et e e J´rˆme Ermont, pour leur chaleureux accueil ` l’ENSEEIHT, ` Toulouse. Je remercie eo a a le Minist`re des Relations Internationales du Qu´bec, pour avoir rendu possible cet e e ´change avec l’ENSEEIHT. e Merci ` Catherine et aux colocs du 22A, pour leur pr´sence chaleureuse et les noma e breuses soir´es que nous avons pass´es ensemble. Merci ` Alexandre Lacasse, pour son e e a agr´able compagnie au cours des deux voyages que nous avons faits en France, de mˆme e e que pour ses commentaires encourageants et constructifs. Finalement, je remercie toutes celles et ceux de mes amies et amis qui m’ont encourag´ et support´ dans mes projets. e e

e Imagination is more important than knowledge. Nicole. e avec qui tout a commenc´. .` A ma m`re.

. . . . . . . . . . . . .6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. . . . . . . . . . . . . . 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . . . . .3 Syst`mes de transitions . . . 1.2 LAMBDA . . . . . . . . 1. . . . . . . . .1 Langages sp´cifiques au domaine . . . . . . . . 1. . . 1. . . 1. . . . . . . . . . . . . . . . . . 1. e 1. . . . . . .2 Monid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. . . . .1 STAT . . . . . . . .1. . . .3.3 BSML . . . . . . . . . .3 NeVO .2 BRO . . . . . . . . . . . . . . . . . . . 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table des mati`res e R´sum´ e e Avant-propos Table des mati`res e Liste des tableaux Table des figures Introduction 1 Syst`mes de d´tection d’intrusions e e 1. . . . . . . . . . . . . . . . . . . . .2. . . .1 Panoptis . .2 IDIOT . . . . . . . . . . . ii iii v viii x 1 5 7 8 11 15 18 19 22 25 26 30 32 35 36 38 41 42 44 46 51 .4. . . . . . . . . . . . . . . . . . .3. .5. . . . . . . . . . . . . . . . . . . . . . 1. . . . .5 Logiques temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 1. . . . . . . . .5. 1. . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . .3. . . . . . e 1. . . . . . . . . . . . . . . . . . . . .2 Langages imp´ratifs . . . . . . . . . . .1 ASAX . . . . . . . . . . . . . .2 Snort . . . . . . . . . . . . . . e 1. . . . . . . . . . . . . . . . . .4 Syst`mes experts . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . 1. . .5. . . . . .3 Chronicles . . . . . . . . . . 1. .1 LogWeaver . . . . . . .1 P-BEST . . . . . . . . . . . . . . . . . . . . . . . .

. e 3. . . . .4. . . . . . .4. . . . . .3 Logique temporelle lin´aire avec pass´ oubliable e e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . e 3. . . . . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . . . e 2. . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . .6 Inf´rence de nouvelles connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 4. . e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . e 4. . . . . . . . . . . . . . .5 Pr´sentation formelle du langage . . . . . .3 S´mantique . . . . . . . . . . . . . . . . . . 3. . . . . .4. . e 4. . . . . . . . . . .2 Syntaxe . . . . . . . . . . . . e 3. . . . . . . . . . . . . . . . . . . .1.1 Un paradigme pass´ . . . e 4. . . . . . . .1 Mod`le . . . . . .2. . . .1. . . . . . . . . . . . .1. . . . . . . . . . . . . . .4 Acquisition passive d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Sc´narios d’attaques complexes . . . . . . . . . . . . . . . .1.2 Syntaxe . . . . .1. . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 µ-calcul lin´aire . . . . . 4. . . . . . . . . . . . .2 Syntaxe . . . . .2. . . . . . . . . . e 3. . . . . . . . . .4. . . .2. . . . . . . . . . . .Table des mati`res e 2 Logiques temporelles 2. . . . . . . . 4. . 3. . .2 Ports TCP ferm´s . . . . . . . . . . . . . . . . . . . e 3. . . .2 Unification . . .3 Sessions ferm´es et balayage FIN . . . . .5. . . . . .3. . . . . . . . . . . . . . . 3. . . . 2. . . . . . . .2 Langage . . . . . . . . . . . . . . . .5. . . . . . . . . . .6 Conclusion . . . . . . . . . . . . . . . .1 Approximants . . . . . . . . . e e 2. . . . . . . . . . . . . . e 2. . . . . .3 S´mantique . . . . . . . . . . . . . . . . . 3. . . . . . . . .4. . . . . . . . . . . . . .4 Vuln´rabilit´s et syst`mes d’exploitation e e e 3. . . . . . . . .1. . .1 Ports TCP ouverts et sessions actives . . . . . . . . . . . . . e 3. . . . . . . .4. . . .3 S´mantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Logique temporelle lin´aire pass´e . . . . . . .1. . . . . . . . . . .1 Logique temporelle lin´aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . .3 R´cursivit´ . . . . . . . . . . . . . . . . .1 Architecture du syst`me . . . . . . . . .2. . . . . . . . . . . e 3. . .3 TRIO .4 Algorithme . .2 Logique temporelle m´trique . . .1 Logiques temporelles . . . . . . . . . vi 55 58 58 60 63 65 67 67 70 71 72 74 76 77 78 80 80 82 82 83 84 85 86 86 87 89 90 95 97 98 99 99 100 102 103 103 106 112 112 . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . 3. .1 Logique temporelle temporis´e . . .3 Conclusion . . . 4 Logique d’acquisition de connaissances 4. . . . . . . . . . .1 Mod`le . . . . . e 2. . . . . . . . . .5. . . 4. . . . . . . . . .1 Mod`le . . . . . . . . . . . . . . . . . . . . . e e 4. . . . . . e 4. . . . .5 Adresses du routeur . . . . . . e 3. . . . 3 D´tection d’intrusions et analyse passive e 3. . . . . . . . . . . . . . . . . . . . .2 Logiques temporis´es .

. . .2 Filtrage dynamique et s´mantique de symptˆme . . . . . . . . . . . . . . . . . . . 134 e o 5. . . . . . . . . .4. . 132 e 5. . . . . . . . . . . . . . . . . . . . . . . .2 Tableaux . . . . . . . . . . .3 Synth`se de contrˆleur . . . . . . . . . . . . . . . . . . . . . . . vii 113 114 115 118 129 4. . . . . . . . . . . 136 e o Conclusion Bibliographie 142 144 . . . . . . . . . . . . . . . . . . . . Algorithmes . . . . . . . . . . . . . . . . . . . .1 Satisfiabilit´ . . . . . .1 Cas propositionnel . . . . . . . . . . . . . . . . .Table des mati`res e 4. . . . . . . . . . . . . . 4. . . . . . . . . . .2 Cas du premier ordre Conclusion . . . . .4. . . . . . . . . . . . . . .3. .5 5 Travaux futurs 132 5. . . . . . . . . . . . . . .4 4. . . 4. . . . . . . . .

. . . . . . . . . . . . . . . S´mantique de l’op´rateur particulier ` TRIO. . . . . . .7 1. . . . . . . .20 Algorithme d’apprentissage et de v´rification de Panoptis. . . . . . . . . . . . . . . . . . . . . . . . . . . e Familles de logiques temporelles et leur mod`le. .1 2. . . . e e a Un op´rateur d´fini de T-LTL. . . . . . . . . . . . . . . . . . . . . . . . . .12 2. . . . . . . e Syntaxe abstraite de RUSSEL. . . . . .9 1. . . . . .4 1. . . . . . . . . . . . e e Syntaxe de N-LTL. . . . . . S´mantique de l’op´rateur particulier ` N-LTL. . . . . . . . . . . . . . . . e e a Syntaxe du µ-calcul lin´aire. . . . . . . . . . . . . .17 2. . .8 2. . . . . . . . . . . . . . . . . . . . . . . e e Syntaxe de MTL. . . . ee Tableau r´capitulatif des IDS. .5 2. . . . . . . . . e e Dix propri´t´s souhaitables d’un IDS. . . . . Syntaxe du calcul d’´v´nements utilis´ dans LAMBDA. . . . . .8 1. . . . . . . . . . . .3 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Syntaxe des sp´cifications Eagle. . . . . . . . . . . . . . . . .15 2. . . .3 1. . . . . . . . . .14 2. .11 2. . . . . . . . . . . . . e e a Quelques op´rateurs d´finis de TRIO. . e S´mantique de l’op´rateur particulier au µ-calcul lin´aire. . . . . . . . . .Liste des tableaux 1. . . . . . . . . . . S´mantique des op´rateurs particuliers ` P-LTL. . Syntaxe des patrons dans BSML. . . . . . . . . . . . . . . .6 2. . . . . . . . . . . . . . . . . . e e Syntaxe de P-LTL. . . . . . .1 1. . . .5 1. . . . . . . . . . . . . . .18 2. . . . . . . . . . . . . . . . . . . e e e Op´rateurs d´finis du µ-calcul lin´aire.10 2. e e . . . . . . . . . . . . . . . . . . . . . 9 20 33 38 39 42 45 48 52 53 57 58 59 59 60 61 61 63 64 65 65 66 68 69 69 70 70 71 71 72 .9 2. . . . . . . . . . . . . . . . . . . . . . . . e e a Syntaxe de TRIO. . . . .19 2. . . . e e a Op´rateurs d´finis de P-LTL. . . . . . . . . . . . . . . . . . . . e Pr´dicats de r´ification de Chronicles. . . . . . . . .13 2. . . . e Op´rateurs d´finis de LTL. . . . . e e e Syntaxe d’un sc´nario d’attaque LAMBDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Syntaxe de la premi`re logique de LogWeaver. . .2 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 1. . . . . . . . . .2 1. . . . . . . . . . . . . S´mantique des op´rateurs particuliers ` MTL. . e e e Syntaxe de T-LTL. . . . . . . . . . . . . . . . . . e Syntaxe de LTL. . . . . . . . . . . . . . . S´mantique de LTL. . . . . . . . . . . . . . . . . . . . . . . . . . . .4 2. . . . . . .16 2. . . . . . . . . . . . . . . . . . . . . . .7 2. S´mantique des op´rateurs particuliers ` T-LTL. .10 2. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .3 4. . . . . . . . . . . Syntaxe. . . . . . . . . . . . . S´mantique. . . . . . . . . . . . .2 5. . . . . . . . . . . . . . . . .Liste des tableaux 3. . . . . e o . . . . . . e . . . . . . . e Algorithme de v´rification pour le cas du premier ordre. . . . . . . . . . e Syntaxe du sous-ensemble associ´ au langage e Algorithme de v´rification. . . . . . . . . . . .3 3. . . . . . . . .5 4. . Approximants avec intervalles. . . . .4 4. . . . .2 3. . . . . . . . . . . . . . . . . . . . . . . . . Algorithme de v´rification pour le cas propositionel. . . . S´mantique op´rationnelle pour le cas du premier ordre. . . .7 4. . . . . .3 5. . . .4 5. . . . . . .4 3. . . .2 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de signatures. . . . . e e Algorithme de synth`se de contrˆleur.1 5. e o Syntaxe de l’alg`bre des automates.5 Syntaxe du langage de signatures. . . . . . . . . .1 4. . . . . e Syntaxe pour le cas du premier ordre. . . . . . e e Approximants. . . . e S´mantique de l’alg`bre des automates. S´mantique pour le cas propositionnel. . . . . . . e a S´mantique de symptˆme. . . . . . . . . . . . . . . . . .9 5. . . . . . . e e Syst`me de preuves ` base de tableaux. . . . . . . . . . . . ix 77 88 89 90 92 99 100 103 106 113 114 116 120 121 134 135 137 137 139 Syntaxe pour le cas propositionnel. . . . . .8 4. . . . . . . . . . . . . . .1 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 4. . . . . . . . . . . . . . e S´mantique d´notationnelle pour le cas du premier ordre.5 4. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .6 1. . . . . . . . . . . . . . . Exemple d’utilisation du module de r´action. .1 1. . . . . . . . . . . . . . . . . . . . e e e Structure de Bro. . . e e R´duction des faux-positifs ` l’aide de la d´tection de vuln´rabilit´s. D´tection d’un syst`me d’exploitation FreeBSD 3. . . . . . . . . . . . . . . . . Exemple de signature Snort. . . . Structure de Snort. . . . . . . . e Exemple d’utilisation du module flowbits. . . . . Session ` demi ouverte dans NetSTAT. . . . . . . . . e Ports TCP ferm´s. . . . . . . . Exemple de fichier de planification de tˆches de Panoptis. . . . . . . .6 3. . . . . . . . . . . . . . . . . . . . . . . .2 1. . . . . . . . . . . . . . . . . e Fermeture d’une session TCP. D´tection d’une p´n´tration externe dans ASAX. . . . . . . . a Mod´lisation d’un r´seau avec NetSTAT. . . .13 1. . . . . . . . . . . . .4 3. . . . . . . . . . . e a e e e Adresses du routeur. . . . . .8 1. . . . . . . e Exemple de chronique. . . . . . . . . . . . . .Table des figures 1. . . . . . . . . . . . . . . . Exemple de script Bro. . . . . . . . . . . . . . . . . . . . . . . . . .3 1. . . . . . . . .4 1.9 1. . . .15 1. . . . . . e e a R`gle Snort num´ro 343. .14 1. . . . . . . . . . . . . . . .16 1.2 3. . . . . . . . . . . . . . . . . . . . . .9 Exemple de fichier de configuration de Panoptis. . . . . . . . . . . . . . . . . . et celle de Snort (` gauche). . . . . .7 3. . .7 1. . . . . . . . . . . . . . .3 3. . . . . . . . . . . . . . . e e Session TCP dans IDIOT. . . e e e e a Exemple de sp´cification Eagle. . . . . . . . . . . . . . . . 60 Architecture du syst`me d´velopp´e (` droite).5 3. . . . . . . . . . . . . . . a Session ` demi ouverte dans l’outil STATed. . . . . . . .5 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Poign´e de main TCP. . . . . . . . . . . .19 1. . .20 2. . . . . . 76 79 81 81 81 83 84 84 85 . . . . . . . . . . . . . . . . . . e e Mod´lisation du sc´nario d’acc`s ill´gal ` un fichier avec LAMBDA. . . e e e a a Balayage SYN. . . Exemple de r`gle d’inf´rence dans P-BEST. . . . . . . . . . . .17 1. . . . . . . . . . . . . . 8 9 9 12 13 14 14 17 21 22 23 28 29 29 31 34 37 40 45 48 Exemples de programmes. . . . . .8 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . .10 1. . a Exemple de fichier de sortie de Panoptis. . .1 3. . . . . . . . . . .12 1. . . . . . . . . . . Exemple de signature NeVO. . . . . .18 1. . . . . . . . . . . . . . . Attaque TCP SYN-Flood dans BSML. . . . . . . . . . . . . . . . . . . . . . . . . . .0 ` 4. .1 3. . . . . . . . . . . .11 1. . . . . . .

. . . . . . . . . . . . . . Exemple de conflit. . . . . . . o a Contrˆleur universel pour ¬(rst ∧ [synack. . . .4 4. Formule repr´sentant une poign´e de main TCP. . . . . . . . . . . . . . . . . . . . . . . ack]). . . . xi 85 87 88 91 93 99 101 101 102 105 107 113 114 115 133 136 138 138 140 Attaque dans le contexte d’une session TCP active. . . . . Exemple de trace du premier ordre. . . . . .9 5. . . . Utilisation des approximants avec intervalles. . . . . . . . e e e e Exemple de trace d’ex´cution de l’algorithme. . . . . Suivi des sessions TCP. o . . . . . . .1 4. . . . . . . . . . .13 3. . .3 5. .11 3. . . . . . . . . Balayage de ports TCP. .12 3. . . . . . . . . . .8 4. Exemple de relations de satisfaction pour le cas propositionnel. . . . . . . . . . . . . . . .5 4. . .Table des figures 3. . . . .4 5.2 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Sp´cification associ´e au sc´nario d’une poign´e de main TCP. .6 4. . .2 4. . . . . . . .10 3. . . . Exemple de trace pour le cas propositionnel. . . . . . . . . . . . . . . Utilisation des approximants. . . . . . . . . Exemples de contradictions. . . . . . . . . . . . . . . ack]). . . . . . Automate TCP. . . . . . . . . . . . . .1 5. . . . . . . . . . . . . . .5 Inf´rence de nouvelles connaissances. . . Contrˆleur pour l’automate TCP relativement ` ¬(rst ∧ [synack. . . . . . . . . . . . . .7 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e . . . . e Exemple de trace. . . . . . . . Exemple de relations de satisfaction pour le cas du premier ordre. . . . . . . . . . .3 4. . . . . . . . . . . . . . .14 4. .

Ils viennent avec une e a e base de sc´narios d’attaque pr´d´finis qu’ils doivent reconnaˆ e e e ıtre. Dans ce cas. Le pr´sent travail e e s’int´resse surtout aux syst`mes ` base de sc´narios. et au cours de la phase de d´tection. e e c e au risque de g´n´rer des faux-positifs (fausses alarmes). L’avantage des d´tece teurs d’anomalies est donc de pouvoir d´tecter des sc´narios d’attaque insoup¸onn´s. au risque de laisser passer des e e e attaques encore inconnues. Afin de nous all´ger cette tˆche ardue. les fichiers d’audit analys´s o e o e . on parle de faux-n´gatifs. il faut ´tudier attentivement des quantit´s la c e e plupart du temps astronomiques de fichiers d’audit et faire preuve d’une patience et d’une capacit´ d’analyse hors du commun. e e e Les syst`mes de d´tection d’intrusions sont g´n´ralement class´s en deux cat´gories : e e e e e e les d´tecteurs d’anomalies et les syst`mes ` base de sc´narios. Les syst`mes pour lesquels la phase d’apprentissage continue e apr`s le d´but de la phase de reconnaissance sont dits adaptatifs. Pour le savoir. e e a e Une autre fa¸on de classer les syst`mes de d´tection d’intrusions est selon le niveau c e e auquel ils interviennent : hˆte ou r´seau. Il est plutˆt rare que l’on puisse dire. le syst`me apprend ` reconnaˆ e e a ıtre ce qu’est un comportement normal. Les e syst`mes ` base de sc´narios n’ont pas de phase d’apprentissage. que ceux-ci ont ´t´ ou sont pr´sentement utilis´s d’une e ee e e fa¸on non-souhaitable. par un simple coup d’oeil aux o ´quipements informatiques. alors que celui des syst`mes ` e e e a base de sc´narios est de g´n´rer moins de faux-positifs. Les d´tecteurs d’anomae e a e e lies fonctionnent g´n´ralement en deux phases : une phase d’apprentissage et une phase e e de d´tection. il identifie les e comportements anormaux. Ils les ont appel´s syst`mes de d´tection d’intrusions. Au cours de la phase d’apprentissage. les e e a informaticiens se sont mis ` d´velopper des outils logiciels automatisant une partie du a e travail. L’objectif des syst`mes e e e adaptatifs est de tenir compte de la nature changeante des r´seaux informatiques.Introduction Contexte La d´tection d’intrusions est un probl`me inh´rent ` la nature abstraite d’un r´seau e e e a e informatique. Au niveau hˆte.

et son ex´cution sera mat´rialis´e par les diff´rents a e e e e e fichiers d’audit mis ` notre disposition. si toutes e e e e e ses ex´cutions respecteront une propri´t´ donn´e. Pour ce faire. Bien que nous nous int´ressions particuli`rement a e e aux traces de trafic. et c’est pourquoi certains syst`mes de d´tection pr´sentent e e e une approche g´n´rale permettant de regrouper les deux cas de cette classification. du syst`me de fichiers. Objectifs et m´thodologie e Nous nous sommes donn´ comme mandat de d´velopper un langage de d´tection e e e d’intrusions qui soit bas´ sur un paradigme purement d´claratif. nous e e avons d’abord dˆ effectuer une revue des langages de d´tection d’intrusions existant u e d´j`. e e e traces d’ex´cution de programmes. e e Plusieurs paradigmes. auxquels nous reviendrons. avant d’aller plus loin. le e programme ` valider sera le r´seau. e e Les m´thodes propos´es pour des ex´cutions finies de programmes ne sauraient donc e e e s’appliquer ici.. Les logiques temporelles. ee ´ Validation Etant donn´e une ex´cution d’un programme. Une trace de trafic est une copie de tout le trafic ayant e circul´ ` un endroit donn´ d’un r´seau informatique. Il s’agit en fin de compte d’un cas ea e e particulier de fichier d’audit. les fichiers d’audit e e utilis´s sont des traces de trafic.Introduction 2 sont des fichiers syst`mes : utilisation du processeur. ont ´t´ propos´s pour les lanee e gages de signatures des syst`mes de d´tection d’intrusions ` base de sc´narios. etc. Dans notre cas. que la d´tection d’intrusions e a ceci de particulier que les ex´cutions auxquelles on s’int´resse sont de longueur infinie. il s’est av´r´ ea e e e ee que le bien fond´ de cette affirmation ´tait dans la plupart des cas discutable. ont ´t´ utilis´es pour s’attaquer ` trois cat´gories de probl`mes : e ee e a e e ´ V´rification Etant donn´ un programme. g´n´rer un programme tel que toutes ses ex´e e ee e e e cutions respectent cette propri´t´. d´cider si cette ex´cution e e e e respecte une propri´t´ donn´e. se trouvent ceux bas´s sur des logiques temporelles. Bien que plusieurs d’entre eux aient la pr´tention d’ˆtre d´claratifs. du r´seau. e e . e ee e ´ Synth`se Etant donn´e une propri´t´. nous avons privil´gi´ cette voie pour la poursuite de nos travaux. la m´thode que nous proposons s’adapte aussi bien aux autres e fichiers d’audit. Parmi e e a e ceux-ci. Il convient de noter. e en m´thodes formelles. ee e Le pr´sent travail s’inscrit donc dans un contexte de validation. alors qu’au niveau r´seau. avant mˆme de l’ex´cuter. d´cider. Ceux e e ´tant le plus pr`s de r´pondre ` ce crit`re ´tant ceux bas´s sur un paradigme de logique e e e a e e e temporelle.

et voir comment u celles-ci pouvaient ˆtre utilis´es pour r´pondre ` nos besoins. le pire cas. et dans le second cas. nous pr´sentons les logiques temporelles ayant le e e plus influenc´ notre travail. Au e e e e e e e chapitre 1. Nous proposons deux approches pour s’attaquer ` ces probl`mes. le langage utilis´ pour d´crire les sc´narios est bas´ e e e e sur une logique temporelle avec op´rateurs futurs. et traitement en ligne. A la fin de ce chapitre. Un de ces besoins ´tait e e e a e d’acqu´rir passivement de l’information sur un r´seau informatique. Cet outil utilise un langage de signatures qui permet de come e . selon les paradigmes utilis´s. Les trois objectifs e principaux de notre travail sont donc : 1. un reproche ayant souvent ´t´ fait aux syse ee t`mes de d´tection d’intrusions est de ne pas tenir compte du contexte avant de signaler e e des alarmes. 3. La capacit´ ` traiter un fichier d’audit enregistrement par enregistrement sans ea revenir en arri`re est ce que nous appellerons traitement en ligne. e e Organisation La premi`re partie de ce m´moire est une revue de litt´rature en deux volets. nous e e ` dressons une liste de dix propri´t´s identifi´es comme souhaitables pour un langage de ee e d´tection d’intrusions. e La seconde partie de ce m´moire pr´sente le travail effectu´. La premi`re est a e e une approche hybride o` la s´paration entre l’information acquise et les sc´narios ` u e e a reconnaˆ est claire. Au mieux. En effet. Nous proposons une taxonomie divisant ces e e langages en cinq cat´gories. et la seconde ıtre e e approche permet d’uniformiser l’acquisition d’information et la d´finition de sc´narios e e ` reconnaˆ a ıtre. nous dressons un ´tat de l’art d´taill´ des langages de signatures utilis´s par treize syst`mes de d´tection d’intrusions. Au chapitre 2. e 2. on ne sauvegarde que l’information n´cessaire. Au chapitre 3. de fa¸on ` faire une e e c a d´tection d’intrusions plus accrue. tout ` fait d´raisonnable. il est bas´ sur e e une logique temporelle avec op´rateurs pass´s. tant au niveau du langage que du logiciel d´velopp´. acquisition passive d’information. nous e e e d´crivons un outil d’acquisition passive d’information et de d´tection d’intrusions que e e nous avons d´velopp´. Cette sauvegarde du contexte ne saurait cependant ˆtre faite sans un coˆt e u additionnel. Dans le premier cas. Paradigme d´claratif.Introduction 3 Nous avons donc dˆ nous familiariser avec les logiques temporelles. pas un bit e de plus. constituant la sauvegarde compl`te de a e e la trace de trafic.

Introduction 4 biner et d’effectuer les deux tˆches dans un paradigme uniforme. Entre autres. nous a pr´sentons un autre langage. e . Pour chaee e e cun de ces deux langages. e e La troisi`me partie constitue la conclusion. Au chapitre 4. d´velopp´ en vue de combler les lacunes identifi´es avec le e e e e premier. Au chapitre 5. nous donnons quelques e id´es pour la continuation des travaux de recherche effectu´s dans le cadre de cette e e maˆ ıtrise. ce langage a la propri´t´ d’ˆtre purement d´claratif. Nous dressons un bilan des travaux effectu´s au dernier chapitre. nous pr´sentons les algorithmes de v´rification ` utiliser et e e a donnons les preuves de compl´tude et de coh´rence.

Normalement. surviennent lorsqu’un utilisateur male a veillant au courant de la strat´gie de d´tection change son comportement petit ` petit e e a de fa¸on ` exploiter la capacit´ d’adaptation du syst`me. Cette strat´gie permet de faire face ` la nature changeante du comportement e a des utilisateurs et ainsi de s’adapter au changement. L’hypoth`se derri`re cette fa¸on e e c de faire est que le comportement normal d’un utilisateur change de fa¸on graduelle c et qu’une utilisation non-d´sir´e du r´seau entraˆ e e e ınera un changement brusque dans le comportement. quand ` eux. engendrent moins de fauxa a positifs car on leur sp´cifie exactement ce qu’ils doivent d´tecter. c a e e Les IDS fonctionnant ` base de signatures. Cette hypoth`se entraˆ ` la fois des faux-positifs (fausse alarme) et e ıne a des faux-n´gatifs (attaque non-d´tect´e). e e e e Ils fonctionnent g´n´ralement en deux phases : une phase d’apprentissage et une phase e e de d´tection proprement dite. consistera ` d´tecter des d´viations du comportement a a e e normal.Chapitre 1 Syst`mes de d´tection d’intrusions e e Un syst`me de d´tection d’intrusions (ou IDS pour Intrusion Detection System) est e e une composante logicielle responsable d’identifier une utilisation non-d´sirable d’une e ressource informatique. On peut classer les IDS selon plusieurs crit`res. la phase d’apprentissage continue pendant la phase de reconnaissance. comme e e . La phase ee de reconnaissance. par exemple en installant un c nouveau logiciel. Les faux n´gatifs. quand ` eux. Pendant la phase d’apprentissage. pr´sentent l’avantage de pouvoir d´couvrir des attaques encore non-r´pertori´es. Cependant. quand ` elle. le syst`me dresse un e e profil de ce qui sera par la suite consid´r´ comme un comportement normal. Les faux positifs surviennent lorsque les utie e e lisateurs changent leur comportement de fa¸on brusque. Les crit`res e e les plus g´n´ralement rencontr´s sont le type de sonde (r´seau ou hˆte) et le type e e e e o d’algorithme (statistique ou ` base de signatures). aussi appel´s d´tecteurs d’anomae e e e e lies. a Les syst`mes bas´s sur des m´thodes statistiques.

la strat´gie du patron de bits a men´ jusqu’` date ` de tr`s bons ıve e e a a e r´sultats. nous jetterons un oeil aux langages imp´ratifs ayant ´t´ d´velopp´s e ee e e sp´cialement pour la d´tection d’intrusions. et ce pour deux raisons : premi`rement. Les langages bas´s sur les syst`mes de transition. de d´tection. Les signatures de ces syst`mes permettent de prendre en compte e e e le contexte avant de signaler une alarme. Ce sont ceux qui se rapprochent le plus des e e langages de programmation habituels. Dans ce chapitre. de rapports. que nous traiterons a e e . Ils pr´sentent l’avantage d’offrir des primitives e associ´es au traitement d’´v´nements et des syst`mes de types appropri´s ` la d´tection e e e e e a e d’intrusions. de corr´lation et de rapports. la complexit´ algorithmique li´e ` la e e e e a v´rification des signatures est des plus avantageuses (constante en m´moire et lin´aire en e e e temps) . Diff´rents mod`les th´oriques ont ´t´ utilis´s dans le cadre du e e e ee e d´veloppement de ces syst`mes. a a e Les IDS fonctionnant ` base de patrons de bits comportent cependant des faiblesses a au niveau de l’expressivit´ des signatures qui peuvent mener autant ` des faux-positifs e a qu’` des faux-n´gatifs. e e dans la section 1. L’hypoth`se menant ` cette m´thode de travail e a e est qu’un comportement non-d´sirable peut ˆtre d´tect´ ` partir d’un petit nombre de e e e ea bits physiquement situ´s ` proximit´ les uns des autres. Par la suite. Dans le cas des anti-virus. il e a e s’agit g´n´ralement des premiers bits du fichier. Le mod`le de syst`me de d´tection d’intrusions ` base de signatures le e e e e e a plus simple que nous puissions imaginer est celui g´n´ralement utilis´ dans le domaine e e e des anti-virus : celui du patron de bits. e e e e Dans [2]. Ces langages ont l’avantage de pr´senter une grande e e simplicit´. Par exemple. une attaque doit survenir dans le contexte e e d’une session active. et nous allons consacrer le reste de ce chapitre ` leur e e a ´tude. Les signatures d´velopp´es avec ces langages sont cependant souvent diffie e ciles ` maintenir. alors que dans les IDS r´seaux tels e e e que Snort [1]. C´dric Michel et Ludovic M´ proposent une taxonomie des langages utilis´s en d´tection d’intrusions divisant ceux-ci en six cat´gories : langages d’´v´nements. la simplicit´ du langage de signature encourage la communaut´ e e e d’utilisateurs ` participer ` l’enrichissement de la base de donn´es de signatures. Bien que e na¨ en apparence. e e e e d’exploits. C’est pourquoi la communaut´ scientifique persiste ` mettre a e e a tant d’efforts dans le d´veloppement d’IDS pouvant d´tecter des patrons d’´v´nements e e e e s´par´s dans le temps.Chapitre 1. mais offrent souvent une faible expressivit´ et peu de souplesse. deuxi`mement.1 par les langages les plus simples : e les langages sp´cifiques au domaine. il peut s’agir de quelques bits bien cibl´s d’un seul paquet. que nous subdivisons e en cinq cat´gories. le risque de faux-n´gatifs a e est plus ´lev´. Syst`mes de d´tection d’intrusions e e 6 on doit constamment tenir ` jour leur base de signatures. e e nous nous attaquons au cas particulier des langages de d´tection. ils e permettent de sp´cifier que pour ˆtre valide. dans le cas d’un IDS r´seau. e Nous commencerons notre ´tude dans la section 1.2.

Dans le pr´sent chapitre. dans la plupart e e des cas. e e e e cette information doit cependant ˆtre g´r´e explicitement. ces langages sont con¸us avec un certain souci d’abstraction permettant des c les utiliser pour diff´rents types de fichiers d’audit.1 Langages sp´cifiques au domaine e Un langage sp´cifique au domaine. sont ceux qui se rapprochent le plus de syst`mes ` base de signatures purement d´claratives. Nous a e e pr´sentons d`s maintenant ces trois syst`mes. Ces langages comportent cependant une partie imp´rative dont e e l’objectif est souvent d’emmagasiner une partie du contexte. le langage STATL e peut ˆtre utilis´ autant pour une d´tection d’intrusions au niveau hˆte (dans le cas de e e e o WinSTAT et USTAT). l’ine e f´rence d’information concernant le contexte. Syst`mes de d´tection d’intrusions e e 7 dans la section 1. et ` l’identification passive de failles de s´curit´ (dans le cas de NeVO). ont ´t´ mis au point afin de pouvoir sp´cifier d’une fa¸on d´clarative ee e c e les sc´narios d’attaques. tombent donc e e e e tous dans la cat´gorie des langages sp´cifiques au domaine. Les syst`mes bas´s sur des logiques temporelles. Ils ne sont pas d´finis sur une s´mantique abse e traite de fichiers d’audit. Les syst`mes experts. sp´cialement con¸us pour e e e c la d´tection d’intrusions ou pour la surveillance de syst`mes en g´n´ral.5. chacun des syst`mes de d´tection d’intrusions que e e e e nous pr´sentons vient avec son propre langage permettant de le configurer et/ou de e sp´cifier des signatures particuli`res d’attaque.3. est un langage de proe e grammation sp´cialement con¸u pour capturer la s´mantique propre ` un domaine d’ape c e a plication particulier. dont e nous parlerons dans la section 1. e e e . au filtrage de paquets (dans le cas de Snort). Afin d’´viter les probl`mes de m´moire. surtout. tel que d´fini dans [3]. Des exemples de langages sp´cifiques au domaine sont HTML et e SQL. dont e e e e nous parlerons finalement dans la section 1. respectivement con¸us pour l’´dition d’hypertextes et la consultation de bases de c e donn´es. e Les trois syst`mes que nous pr´sentons dans cette section se distinguent de par le e e fait que les langages qu’ils utilisent sont li´s d’encore plus pr`s au type de d´tection e e e particulier qu’ils permettent d’effectuer. et le niveau d’abstraction e ee d´sir´ n’est pas toujours atteint. qu’au niveau r´seau (dans le cas de NetSTAT).4.Chapitre 1. e a e 1. Par exemple. Cependant. mais sur des s´mantiques tr`s concr`tes reli´es aux fichiers e e e e d’audits de processus (dans le cas de Panoptis). sont sp´cialis´s dans l’accumulation et. Ces langages.

nous avons mis le focus sur ces types de syst`mes. ALL) # Users dbcheck(uidtty. root. FALSE for # little endian (e. 1. processus.Chapitre 1.dsl 1. Ce domaine est celui des processus d’un syst`me Unix. Les auteurs affirment que le e langage a quand mˆme ´t´ con¸u de fa¸on assez g´n´rale pour pouvoir fonctionner sur e ee c c e e n’importe quel syst`me fournissant des fichiers d’audits de processus.1 Panoptis Panoptis [3] se distingue des autres syst`mes de d´tection d’intrusions pr´sent´s dans e e e e ce chapitre par le fait qu’il s’agit du seul syst`me bas´ sur une d´tection d’anomalies e e e que nous avons choisi de pr´senter. tty31. Les informations maintenues pour e e . ttyp03. mais e e nous avons tout de mˆme jug´ utile. maxbmin. pour trois e utilisateurs sp´cifiques utilisant un mˆme terminal. maxio. Sun). e Comme nous l’avons d´j` dit. Panoptis est configurable ` l’aide d’un langage sp´ciea a e fique au domaine. mail. maxrw. tty33.1. maxbmin. e Panoptis maintient des tables contenant les profils d’activit´s pour diff´rents utilisae e teurs. john. Syst`mes de d´tection d’intrusions e e 8 # # Configuration file for host pooh # # $ Id : poo. tty34. et Panoptis e prend donc en entr´e des fichiers d’audits de processus. maxmem. terminaux. ttyp06) Fig.6 2000/05/30 12 :26 :58 dds Exp $ # HZ = 100 # "Floating point" value divisor bigend = FALSE # Set to TRUE for big endian (e.g. maxutime. bin. 1. Comme nos travaux se situent plutˆt dans le cadre e o de reconnaissance de sc´narios. ou groupages et/ou couplage de ces entit´s. maxcount) # Users on a terminal dbcheck(uidcomm. minbmin. tty32. jill) usermap(admin. Intel x86) map = TRUE # Set to TRUE to map uid/tty numbers to names EPSILON = 150 # New maxima difference threshold (%) report = TRUE # Set to TRUE to report new/updated entries unlink = FALSE # Set to TRUE to start fresh # Reporting procedure output = ’| /usr/bin/tee /dev/console | /bin/mail root’ # Databases and parameters to check dbcheck(tty. d’inclure au moins un e e e d´tecteur d’anomalies.g. maxcount. par souci de compl´tude.1 – Exemple de fichier de configuration de Panoptis. marry. ttyp01. ttyp02. VAX. ttyp05. Par exemple. news) termmap(room202. # Users of a command maxstime. ALL) # Commands dbcheck(uid. uucp. ttyp04. e il peut maintenir une table concernant l’utilisation d’un processus donn´. maxasu) # Map users and terminals into groups usermap(caduser. maxcount) # Terminals dbcheck(comm. tty35) termmap(ptys. dont Windows NT. minbmin.

workday 4 50 * * 6.25.cfg pooh.20min 8-18 05 * * * panoptis pooh-hour. key [dds/gcc] : New entry.36 seconds) Database Users*Commands.8 / 64 .3 – Exemple de fichier de sortie de Panoptis. e Database Users*Commands. key [root/ls] : New maximum average character input/output (204.2 – Exemple de fichier de planification de tˆches de Panoptis. a read and parse the the domain-specific language configuration while there are records in the specified accounting file read and decode an accounting record synthesise the derived quantities substitute the name of entities belonging to a group with the group name for every database table specified look for an database entry matching the key of the record retrieved if a matching entry is found compare it with the entry read if the accounting record value exceeds the amount stored in the database produce a new maximum value alert and update the database else (if no matching entry is found) produce a new value alert and update the database Tab.Chapitre 1. 1.cfg pooh.workhour 19-7 05 * * * panoptis pooh-hour.weekly /usr/adm/pacct ? /usr/adm/pacct 20m 1h 1h 24h 24h 7d Fig. 220%) Command : ls Terminal : ttyp1 User : root Executed from : 2001-01-13 01 :32 :13 to : 2001-01-13 01 :32 :13 (0.weekend 2 20 * * 0 panoptis pooh-full.cfg pooh.45 * * * panoptis pooh-quick.late 4 50 * * 1-5 panoptis pooh-day.41 seconds) Fig. 1. 1.1 – Algorithme d’apprentissage et de v´rification de Panoptis.cfg pooh. Syst`mes de d´tection d’intrusions e e 9 # # Panoptis crontab file for host pooh # # The format of this file is : # Hour Minute Day-of-month Month Day-of-week Command * 5. .0 panoptis pooh-day. Command : gcc Terminal : ttyp0 User : dds Executed from : 2001-01-13 01 :29 :32 to : 2001-01-13 01 :29 :33 (1.cfg pooh.cfg pooh.

1. e a e ` A la figure 1. Pour chacune des cinq tables tty.2. Ensuite. pour chaque e e e e entr´e.3. un e ea e e ´v´nement est g´n´r´ pour signaler une nouvelle entr´e et la valeur est ins´r´e dans la e e e ee e ee table.1. Panoptis est donc un syst`me tol´rant ` des changements de a e e a comportements graduels. Un exemple de fichier de planification de tˆches se trouve a e e a e e ` la figure 1. Ce e a fichier se divise en quatre parties. un ´v´nement est g´n´r´. Si aucune valeur n’´tait pr´sente. la valeur obtenue avec celle qu’il avait d´j`. les a utilisateurs john. Par exemple.1. Panoptis peut soit les lire en continu. une valeur ´tait d´j` pr´sente. uid. Dans chacun des cas. Le premier ´v´nement de la figure 1. on peut voir l’algorithme d’apprentissage et de v´rification utilis´ par e e Panoptis. a e e celui-ci compare les valeurs calcul´es ` celles se trouvant dans les tables et rapporte les e a entr´es qui pr´sentent des diff´rences significatives. les deux valeurs sont compar´es e ea e e et si la diff´rence entre celles-ci d´passe le seuil de tol´rance sp´cifi´ dans le fichier de e e e e e configuration. au contraire. u u e on donne aussi la nouvelle valeur. e e e a Un exemple de fichier de configuration utilis´ par Panoptis se trouve ` la figure 1. la nouvelle valeur obtenue est ins´r´e e e e ee ee ` la place de l’ancienne. En premier lieu. e e e ` A la table 1. peuvent ˆtre utilis´s selon les p´riodes de la journ´e ou de la e e e e e semaine. D’un cˆt´. on trouve les options de groupage qui permettent de regrouper certains utilisateurs ou terminaux en un seul. on donne e e le nom de la table concern´e ainsi que la cl´ de l’entr´e ayant g´n´r´ l’´v´nement et e e e e ee e e le moment o` celui-ci est survenu. on trouve un ensemble de d´finitions e de variables qui servent ` d´finir le fonctionnement g´n´ral du programme. On voit que des intervalles diff´rents. Finalement. cette caract´ristique pr´sente l’avantage de bien oe e e refl´ter le fait que les utilisateurs changent petit ` petit leurs habitudes. elle pr´sente aussi l’inconv´nient d’offrir ainsi ` un utilisateur malveillant oe e e a un moyen d’´chapper ` la d´tection de la modification de son comportement. Le mot-cl´ ALL signifie que l’on veut surveiller e e tous les champs. de mˆme que des fichiers de a configuration diff´rents. soit ˆtre ex´cut´ e e e e ` des intervalles pr´d´finis. il reste ` configurer la fr´quence ` laquelle les fichiers a e a d’audits sont lus par le syst`me. Ensuite. La troisi`me partie est celle o` on sp´cifie e a e u e ce que l’on veut surveiller. ` la figure 1. Syst`mes de d´tection d’intrusions e e 10 chacune des entit´s surveill´es sont param´trables ` l’aide d’un fichier de configuration. on a e e e indique la m´thode de rapport ` utiliser. ` chaque fois que Panoptis est ex´cut´ sur un fichier d’audit. e Une fois ces options choisies. il compare. Dans le cas o` il s’agit d’un d´passement de seuil. on sp´cifie les champs que l’on veut surveiller. marry et jill sont regroup´s sous l’utilisateur abstrait caduser. uidtty et uidcomm. Apr`s avoir synth´tis´ les donn´es du fichier d’audit. comm. se trouve un exemple de fichier de sortie de Panoptis.3 signifie donc e e . Si. Il y a deux sortes d’´v´nements : ceux correspondant ` une nouvelle entr´e dans une table et ceux e e a e correspondant au d´passement du seuil de tol´rance. Ces champs sont pr´d´finis et e e e font partie de la d´finition du langage. Finalement.Chapitre 1. mais d’un e a autre cˆt´.

plus de 2000 signatures d’attaques). En effet.incitent ` penser qu’un langage de signatures concernant un seul e a paquet n’est pas suffisamment expressif. Cependant. a La structure logicielle de Snort se trouve ` la figure 1. e e 1 . e a En r´sum´. Il est configurable ` l’aide d’un langage tr`s e a e simple et sp´cifique ` l’analyse de fichiers d’audits de processus sur un syst`me Unix. e e dont la fonction originale ´tait de r´gulariser le format des paquets afin de faciliter la e e Une autre approche consiste ` d´tecter les paquets r´sultants de l’attaque. Snort comporte un module de d´codage de paquets permettant de d´coder un grand nombre de protocoles de diff´rents e e e niveaux. le nombre de faux positifs est alors diminu´. dˆ ` leur grande taille. s’est av´r´ petit ` petit tr`s efficace e e ee a e comme outil de d´tection d’intrusions. Lorsqu’il est possible a e e de d´finir de tels paquets. Syst`mes de d´tection d’intrusions e e 11 que l’utilisateur dds a utilis´ le compilateur gcc pour la premi`re fois. L’hypoth`se derri`re le choix de Snort comme syst`me e de d´tection d’intrusions est donc que les attaques sont rep´rables ` l’aide d’un seul e e a paquet.2 Snort Le syst`me de d´tection d’intrusions Snort [1]. Au dessus de ce module de d´codage se situe un ensemble de pr´processeurs. alors que la e e seconde signifie que l’utilisateur root. ` l’aide de la commande ls. a list´ le contenu de a e r´pertoires contenant deux fois plus de fichiers qu’` l’habitude. Utilisant. e e u a seraient inutilisables sinon. il dispose d’un langage de signatures e permettant de d´crire avec une grande pr´cision les caract´ristiques des paquets ofe e e 1 e e e fensifs circulant sur le r´seau . 1.voir tout le reste du pr´sent chapitre . son mode de fonctionnement g´n´rique le e e rend capable de d´tecter des attaques qu’un syst`me fonctionnant ` base de signatures e e a aurait pu laisser passer. la librairie de capture de paquets LibPcap [5].4.Chapitre 1. Panoptis constitue un cas typique de syst`me de d´tection d’intrusions e e e e effectuant de la d´tection d’anomalies. ` ce jour. tout comme a tcpdump. la pratique d´montre qu’il est tout de mˆme e e possible de d´tecter un grand nombre d’attaques sur la base d’un tel langage (la base e de signatures de Snort contient. Panoptis est sujet ` un grand nombre de faux positifs et sa nature adapa tative le rend vuln´rable aux utilisateurs qui modifieraient tranquillement leur profil e afin de ne pas se faire remarquer. Bien que les efforts investis par la communaut´ pour d´velopper des langages e e de signatures permettant de tenir compte de plusieurs paquets . e a e Un tel outil fait partie des composantes essentielles ` une architecture de s´curit´ car a e e il permet d’avoir une vision r´sum´e de fichiers d’audits qui. Comme la plupart des syst`mes effectuant de la d´tection e e d’anomalies. originellement con¸u pour ˆtre un e e c e renifleur (sniffer ) plus ´volu´ que tcpdump [4].1.

tˆche de la base de r`gles. UDP. Il est cependant possible d’´chapper au syst`me de d´tection d’intrusions e e e autrement qu’en utilisant des astuces de formatage au niveau application. Une autre fa¸on de faire c a e c est d’envoyer les paquets dans un ordre ne correspondant pas ` celui dans lequel ils a seront interpr´t´s par la machine qui les recevra. un utilisateur peut alors se connecter sous le compte root sans se faire rep´rer. de a fa¸on ` ce qu’aucun des paquets r´sultants ne soit alarmant. e a e e e En tapant user : roo<BS>ot. les attaques de balayage ont pour objectif de permettre . Qu’il s’agisse d’un balayage e TCP. Il s’agit encore une fois d’un travail de e e formatage visant ` ´viter certaines attaques d’´vasion. il ıne e est possible d’´chapper ` cette r`gle en utilisant le caract`re de retour en arri`re <BS>. on voudrait pouvoir sp´cifier une r`gle e e qui surveille les paquets contenant la chaˆ de caract`res user : root. Des astuces similaires s’appliquent au trafic HTTP. Snort comporte des pr´processeurs responsables de r´gulariser le trafic Telnet e e et HTTP.Chapitre 1. Pour ces e raisons. Les pr´processeurs frag2 et stream4 ee e ont donc ´t´ ajout´s afin de remettre ensemble les paquets fragment´s et de pr´senter ee e e e les paquets au syst`me de d´tection d’intrusions dans le mˆme ordre que celui dans e e e lequel le syst`me les recevant les interpr`tera.4 – Structure de Snort. Un exemple simple de cat´gorie d’attaques n´cessie e tant la d´tection de plusieurs paquets est le balayage (scan). ae e En plus de cette fonctionnalit´. ainsi que permettre e e l’acquisition passive d’information. Cependant. a e Par exemple. si une politique de s´curit´ sp´cifie que personne ne doit se connecter e e e au service Telnet en utilisant l’utilisateur root. Une astuce bien connue consiste ` fragmenter le paquet offensif en plusieurs petits paquets. Syst`mes de d´tection d’intrusions e e 12 Modules d’affichage Module de détection Préprocesseurs Module de décodage Libpcap Réseau Fig. ICMP ou autre. 1. les pr´processeurs sont aussi utilis´s ` deux autres e e e a fins : d´tecter les sc´narios d’attaques utilisant plusieurs paquets.

le nombre de connexions TCP demand´es par un hˆte distant dans une e o fenˆtre de temps donn´e. il a a e ´tait possible d’exploiter le fait que Snort fonctionnait paquet par paquet pour g´n´rer e e e automatiquement des paquets correspondant aux signatures d’attaque [6].28 . e e e e et que le num´ro d’acquiescement est 0 (ack :0). e e Au dessus de tous ces pr´processeurs. e ` A la figure 1. Le langage utilis´ pour d´crire ces paquets est relativement simple. envoyer un message via le protocole SNMP. e e Effectuer un minimum d’acquisition est plus que souhaitable pour un syst`me de e d´tection d’intrusions : il s’agit d’une fonctionnalit´ vitale. une s´rie de modules d’affichage et d’archivage sont responsables de e l’interaction avec l’usager.) Fig. rev :3 . une signature Snort est une suite de mots-cl´ suivis de z´ro ou plusieurs arguments. Certains mot-cl´s ne concernent pas e e e la d´tection. e afficher un message ` l’´cran. de mˆme que les deux bits r´serv´s (flags :A. La description ıtre des paquets ` reconnaˆ a ıtre se trouve dans un fichier texte qui est lu ` l’amor¸age du a c programme. engorgeant ainsi le syst`me de d´tection d’intrusions de faux-positifs. Snort peut. ack :0 . 1. une entr´e dans a e e une base de donn´es. ce qui e e explique en partie la popularit´ et la croissance rapide du nombre d’attaques que Snort e est maintenant capable de reconnaˆ ıtre. ` l’attaquant d’acqu´rir de l’information sur le r´seau ou la machine victime afin de a e e mieux se pr´parer ` son attaque. Les balayages peuvent s’effectuer en utilisant des e a fonctionnalit´s tout ` fait normales de la pile TCP/IP. Lorsque les attaques sont identifi´es. Avant l’arriv´e de flow. dont la e tˆche est de tenir ` jour une table des sessions TCP actives.12 . reference :arachnids. flags :A. e ee e par exemple. mais sont simplement ajout´s afin de documenter l’attaque. Un exemple de pr´procese e e seur effectuant de l’acquisition passive d’information est le pr´processeur flow. se trouvent les modules de d´tection. entre autres.12). et la seule fa¸on de les d´tece a c e ter consiste g´n´ralement en la d´tection de l’utilisation abusive de ces fonctionnalit´s. peu importe l’´tat de la session (stae e . etc. ajouter une ligne dans un fichier texte. peu importe les ports (any). Une fois les e e paquets reconnus. classtype :attempted-recon . e e e e Certains pr´processeurs (par exemple portscan2) ont donc ´t´ ajout´s afin de compter. Ces e e derniers sont responsables de reconnaˆ les profils de paquets offensifs. L’interpr´tation de cette e e signature se lit comme suit : si un paquet TCP provenant de l’ext´rieur ($EXTERe NAL_NET) p´n`tre dans notre r´seau ($HOME_NET). stateless . sid :628 . et que e e e ce paquet a le drapeau ACK activ´. Syst`mes de d´tection d’intrusions e e 13 alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg :"SCAN nmap TCP" .Chapitre 1. on pr´sente un exemple de signature Snort. Typiquement.5.5 – Exemple de signature Snort.

logged_in . de plus.0/24 80 (content : "sex" . content :"OK LOGIN" .) Fig. e Le module flowbits. Il e e permet. quant ` lui. ces ee e variables sont instanci´es et initialis´es ` chaque nouvelle session TCP. un protocole s’ex´cutant g´n´ralement e e e e . d’envoyer un message d’avertissement ` l’usager expliquant pourquoi la a ` la figure 1. unset. il faut alors signaler un balayage TCP fait avec nmap [7] (msg :"SCAN nmap TCP"). Syst`mes de d´tection d’intrusions e e 14 alert tcp any any <> 192. mais un syst`me de pr´vention e e e e d’intrusions. react : block. A ee utilis´ pour empˆcher les enfants d’aller sur des sites pornographiques.to_server . e toggle) dans certaines r`gles. on voit comment ce module peut ˆtre e communication a ´t´ interrompue.6 – Exemple d’utilisation du module de r´action. isnotset). A e e ee e flowbits permet de diminuer le nombre de faux positifs lors de la d´tection d’une attaque e de d´bordement de tampon d’un serveur IMAP. e alert tcp any 143 -> any any (msg :"IMAP login" . Le module react fait de Snort e e non plus un simple syst`me de d´tection d’intrusions. Le reste de la signature constitue la documentation de l’attaque.7 – Exemple d’utilisation du module flowbits. flowbits :isset. flowbits :set. teless). et en les lisant dans d’autres (isset.6.168. flow :established. flow :established. Il permet de r´agir en interrompant les sessions TCP jug´es offensives.logged_in .1.to_client . msg . Il est ` noter e e a a que les r`gles servant ` mettre ` jour les valeurs des drapeaux contiennent g´n´ralement e a a e e le mot-cl´ noalert. Comme e ce module a ´t´ mis au point pour suivre l’´tat des sessions au dessus de TCP. content :"LIST" . Il permet de d´finir des variables bool´ennes (drapeaux) servant ` e e a suivre l’´tat de la session en changeant la valeur de ces variables (set.7. la session TCP correspondante est interrompue et le message not for children est affich´ dans son navigateur.Chapitre 1. a ´t´ mis au point afin de r´pondre au besoin de a ee e plus en plus grandissant de permettre ` Snort de tenir compte de l’´tat des sessions au a e niveau application. reset.) Fig. flowbits :noalert) alert tcp any any -> any 143 (msg :"IMAP list overflow attempt" . Lorsqu’un usager e e tente de consulter un site web contenant le mot sex. 1. aucune alerte ne doit e e e e ` la figure 1. signifiant que mˆme si la r`gle est activ´e. Cette revue de Snort serait incompl`te si aucune allusion n’´tait faite ` la nature e e a particuli`re des modules de d´tection react et flowbits. Cet e exemple est tir´ de [1]. on peut voir comment l’utilisation du module de d´tection ˆtre g´n´r´e. msg : "Not for children !" . 1.

Dans [9]. on active drapeau logged_in et on sp´cifie que cette r`gle ne doit pas d´clencher e e e d’alerte en utilisant le mot-cl´ noalert. mais un identificateur passif de failles de s´curit´. e e d’une part. s’effectue en utilisant incorrectement la commande LIST. Le reste de ce chapitre est donc consacr´ aux langages e permettant d’exprimer des signatures s’´talant sur plusieurs paquets (ou ´v´nements). e a En r´sum´. Ce sera le cas si on voit passer la chaˆ de caract`res OK LOGIN. qu’il provient bien du serveur. coop´rer e e e avec les syst`mes de d´tection d’intrusions. il a devient de plus en plus ´vident qu’un langage de sp´cification id´al devrait pouvoir tenir e e e compte de plusieurs paquets. situ´s au-dessus des pr´processeurs. La seconde signature permet la d´tection de l’attaque proprement dite.3 NeVO e e NeVO [8] n’est pas un syst`me de d´tection d’intrusions. Snort est un syst`me de d´tection d’intrusions ouvert jouissant d’une e e e e grande popularit´. Il comporte plusieurs pr´processeurs e e qui permettent de faciliter le travail des modules de d´tection ainsi que de prot´ger le e e syst`me d’´vasions communes et d’attaques d’inondation de faux-positifs. Cette attaque. la connaissance des failles de e e s´curit´ peut ˆtre utilis´e pour activer ou d´sactiver certaines r`gles du syst`me de d´e e e e e e e e tection d’intrusions.7 sert donc ` m´moriser le fait que le mot de passe de l’usager a a e ´t´ accept´. Ces modules e e devraient faire partie int´grante de tout bon syst`me de d´tection d’intrusions. on trouve une courte ´tude des diff´rentes fa¸ons dont les e e c identificateurs de failles de s´curit´ pourraient ou devraient. Certains moyens ont ´t´ mis en e e ee oeuvre pour compenser les manques les plus importants reli´s ` la nature un paquete a une signature de ce langage. La premi`re e e e signature de la figure 1. diminuant ainsi ` la fois le nombre de faux positifs et la demande a .Chapitre 1. ` mesure que ces moyens sont mis en place. Cependant. Par exemple. permettent ` l’utilisateur e e e a de d´finir ses propres r`gles dans un langage simple. et ne peut r´ussir que si l’usager est correctement connect´ (au niveau application). exploitant une vuln´rabilit´ de certaines e e e versions de imapd. La raison pour laquelle nous le mentionnons ici est que e e la connaissance des failles de s´curit´ du r´seau fait partie des moyens ´tant souvent e e e e mentionn´s pour r´duire le nombre de faux positifs g´n´r´s par un syst`me de d´tection e e e ee e e d’intrusions [9. de v´rifier que le paquet survient bel et bien dans le contexte d’une session e TCP active. Les e e e modules de d´tection. Une alerte sera lanc´e si on voit passer le mot LIST en e e direction du serveur dans le cadre d’une session TCP active appartenant ` un usager a ayant r´ussi ` se connecter.1. et d’autre part. selon les besoins. Dans ce ee e ıne e cas. 10]. Il fonctionne au niveau r´seau et sa base de signatures contient la e e description d’un nombre consid´rable d’attaques. L’utilisation du pr´processeur flow nous permet. Il s’agit d’une version l´g`rement modifi´e e e e e de la signature num´ro 2118. Syst`mes de d´tection d’intrusions e e 15 sur le port TCP num´ro 143. e e e 1.

all´geant ainsi le u e travail de ce dernier plutˆt que celui du syst`me de d´tection d’intrusions. lors de l’´tude de ces diff´rents mod`les. 13]. Syst`mes de d´tection d’intrusions e e 16 faite au processeur de la machine sur laquelle le syst`me s’ex´cute. ce qui signifie qu’il effectue son travail sans avoir ` injecter de trafic sur le e e a r´seau. o e e on ne doit pas oublier. un autre mod`le de coop´ration envisageable serait de lancer l’identie e e ficateur de failles seulement au moment o` les attaques surviennent. qui e e e a est un identificateur actif de failles de s´curit´. Il se pr´sente comme un compl´ment ou une alternative ` Nessus [11. e e e e e e R´ciproquement. Mod`le d’acc`s ` l’information : L’information acquise par un identificateur pase e a sif de failles de s´curit´ ne doit pas. contrairement ` celle acquise par un syse e a . e e e L’hypoth`se permettant de dire qu’un identificateur de failles peut fonctionner e aussi bien sur une base ´chantillonnale qu’en observant la totalit´ du trafic est e e que le comportement caract´ristique de la faille sera observable pratiquement ` e a chaque fois que le syst`me d´faillant entrera en communication. e NeVO. Bien que l’identification active puisse e e en g´n´ral fournir des rapports plus exhaustifs que l’identification passive. que les identificateurs e e e de failles sont autant sujets aux faux positifs et aux faux n´gatifs que les syst`mes de e e d´tection d’intrusions. cette particularit´ e e e est beaucoup plus tol´rable pour un identificateur passif de failles de s´curit´. Finalement.Chapitre 1. voire mˆme mener ` e e e e e a son instabilit´. l’identification passive permet d’avoir acc`s ` une information e e a continuellement mise ` jour. e a ` A premi`re vue. Finalement. pour un e e e ee syst`me de d´tection d’intrusions. Les auteurs de [8] citent cependant deux diff´rences notables entre le mode de e fonctionnement d’un identificateur de failles et celui d’un syst`me de d´tection d’intrue e sions : la tol´rance ` l’´chantillonnage et le mod`le d’acc`s ` l’information. on e e e tente d’identifier un comportement caract´ristique de l’information ` laquelle on s’ine a e t´resse. Si on n’identifie e e pas la faille maintenant. Pour toutes ces raisons. mais aussi sur les clients. est un identificateur passif de failles de s´curit´. 12. elle peut e e souvent s’av´rer tr`s d´rangeante pour le r´seau en cours d’audit. l’identification passive s’impose comme un compl´ment essentiel ` l’identification active. D’autres pensent e e plutˆt que toutes les attaques devraient continuer ` ˆtre surveill´es. De plus. l’identification passive permet non-seulement a de trouver les failles sur les serveurs. mis au point par la compagnie Tenable. un identificateur passif de failles de s´curit´ ne devrait pas fonctione e e ner diff´remment d’un syst`me de d´tection d’intrusions. on l’identifiera bien plus tard. e a e e e a Tol´rance ` l’´chantillonnage : Alors que le fait de n’ˆtre pas capable de traiter e a e e en temps r´el tout le trafic circulant sur le r´seau peut ˆtre consid´r´. D’un point de vue abstrait. comme une faiblesse majeure. sauf que l’outil de o ae e visualisation utilis´ pour consulter le journal d’attaques devrait permettre d’identifier e celles dont le succ`s est le plus vraisemblable ´tant donn´es les vuln´rabilit´s identifi´es.

ˆtre archiv´e ` chaque fois qu’elle est d´tect´e. e Ces deux diff´rences concernant l’architecture logicielle d’un identificateur passif de e failles ne justifient cependant pas le fait que le langage utilis´ pour d´crire les fa¸ons de e e c d´tecter les failles soit diff´rent de celui utilis´ par un syst`me de d´tection d’intrusions. Syst`mes de d´tection d’intrusions e e 17 id=700018 nooutput hs_sport=21 name=Anonymous FTP (login : ftp) pmatch=^USER ftp match=^331 NEXT #------------------------------id=700019 dependency=700018 timed-dependency=5 hs_sport=21 name=Anonymous FTP enabled description=The remote FTP server has anonymous access enabled. e ee e ee e . mais conserv´e jusqu’` ce qu’elle soit e a e a demand´e. ` l’aide e a e e a du mot-cl´ pmatch. risk=LOW pmatch=^PASS match=^230 Fig. De e ea e plus. que si une autre signature a ´t´ activ´e. Le mot-cl´ regex permet de rechercher des a e e expressions r´guli`res. l’identificateur doit plutˆt tenir ` jour un mod`le du r´seau et le fournir o a e e sur demande. e e e e e et c’est pourquoi nous nous attarderons maintenant au langage de NeVO. t`me de d´tection d’intrusions. Par d´faut. et non aux diff´rents champs des diff´rents protocoles ni ` l’interaction de e e a ceux-ci. mais ce module n’utilise pas le langage de NeVO. il est possible de sp´cifier. l’acquisition d’information faite ` l’aide de ce langage se limite au niveau applia cation. Cela signifie que l’inspection faite sur les paquets se limite ` la partie donn´es a e de ceux-ci. pour un flux TCP donn´. NeVO incorpore cependant un module permettant de d´tecter passivement les e syst`mes d’exploitation des machines communiquant sur le r´seau en inspectant les e e entˆtes des paquets SYN. Le mot-cl´ dependency permet de sp´cifier qu’une signature ne e e e e doit ˆtre consid´r´e. Cependant. 1. Au e e e e a e e contraire.Chapitre 1. Cette demande sera typiquement faite au moment de la consultation du journal d’attaques du syst`me de d´tection d’intrusions. L’information n’est e e donc pas envoy´e directement ` l’utilisateur.8 – Exemple de signature NeVO. le contenu du paquet pr´c´dent dans la mˆme session. On sp´cifie le contenu e e e recherch´ ` l’aide du mot-cl´ match. Ce langage est fortement d´di´ ` l’acquisition passive d’information sur un r´seau informatique. e Une signature NeVO concerne g´n´ralement un seul paquet. e e e e e le contenu est recherch´ en mode texte. Il est cependant possible de rechercher un e contenu binaire ` l’aide du mot-cl´ bmatch.

Syst`mes de d´tection d’intrusions e e 18 Le mot-cl´ time-dependency permet de limiter le d´lai d’attente entre l’activation des e e deux signatures. son langage d´di´ ` l’identification de simples paquets au niveau application poure ea rait nous porter ` croire que le nombre de comportements observables est plutˆt limit´. Le mot-cl´ description permet de sp´cifier le message a afficher et le e e mot-cl´ nooutput signifie qu’il n’y a pas de message ` afficher. e ` A l’exception des langages pr´sent´s dans la pr´sente section. Le fait de pouvoir sp´cifier des paquets au niveau des diff´rentes couches e e de protocoles permettrait sans doute de d´tecter plus de failles et.2 Langages imp´ratifs e La distinction entre les langages imp´ratifs et les langages d´claratifs. a o e mais la possibilit´ de sp´cifier une notion de d´pendance entre les r`gles augmente sans e e e e aucun doute l’expressivit´ du langage de fa¸on significative.Chapitre 1. ou encore de compter le nombre d’occurrences d’un e paquet donn´. est e e responsable d’identifier l’envoi d’un mot de passe suivi de l’acceptation de ce mot de passe (code 230). Sur la base de cette d´finition. la docue e e ee e ea mentation disponible sur les outils commerciaux se limite aux aspects externes). e e e le langage de signatures de Snort. elle ne permet pas de reconnaˆ le fait qu’un paquet donn´ e ıtre e n’arrive pas dans un certain d´lai. G´n´ralement. Entre autres. n’est pas aussi nette que l’on pourrait le croire. les langages que nous e e e pr´sentons dans ce chapitre ont tous la pr´tention d’ˆtre d´claratifs. NeVO est un exemple tr`s int´ressant d’identificateur passif de failles e e e e de s´curit´. dans la litt´e e e rature. De plus. sans n´cessairement e e se limiter aux failles. Cependant. La premi`re est responsable d’identifier les paquets contenant une demande de connexion e pour l’utilisateur ftp suivie d’une acceptation du nom d’utilisateur (code 331). on peut ` trouver une documentation riche et pr´cise sur son fonctionnement interne. e 1. d’acqu´rir encore plus d’information. Cette signature se divise en deux sous-signatures. On trouve ` la figure 1. par exemple. plutˆt que comment l’identifier. il est dommage que la s´mantique du langage se limite au niveau e e application. est clairement d´claratif. Les autres langages e o tombent tous sous la cat´gorie des langages imp´ratifs. A premi`re e e vue. En r´sum´.8 e a a un exemple de signature NeVO (tir´ de [8]) responsable d’identifier les serveurs FTP e ayant un compte anonymous actif. activ´e seulement dans les 5 secondes suivant l’activation de la premi`re. cette fa¸on ad e c c hoc de r´gler le probl`me des sc´narios complexes ne saurait amener toute l’expressivit´ e e e e d´sirable. on se contente e e de d´finir informellement un langage d´claratif comme ´tant un langage permettant de e e e d´finir ce que l’on veut identifier. Plus loin dans e e e e . Mˆme s’il a ´t´ d´velopp´ ` des fins commerciales (habituellement. La seconde.

2.1 ASAX ASAX [14. Ces variables peuvent ˆtre de trois types : locales ` une r`gle. Syst`mes de d´tection d’intrusions e e 19 ce chapitre. e e e L’ensemble Cur contient les instances de r`gles qui doivent ˆtre ex´cut´es sur l’ene e e e registrement courant. La notion centrale de ASAX est celle de contexte d’ex´cution. 16] a ´t´ d´velopp´ dans le but d’analyser des traces d’audit. peu importe la d´finition utilis´e. ou correspondre aux champs d’un enregistrement. on a ajout´ un mot-cl´ present. l’utilisation de variables globales peut amener un certain none e e d´terminisme. l’ensemble Nxt contient les instances de r`gles qui doivent ˆtre e e ex´cut´es sur l’enregistrement suivant. alors que Bro. Une autre caract´ristique d’un contexte d’ex´cution est l’ensemble des valeurs des e e diff´rentes variables. qui permet de faire e abstraction du type d’audit. appartiennent certainement ` la cat´goe e a e rie des langages imp´ratifs. e e a L’ex´cution d’un programme RUSSEL implique l’analyse s´quentielle d’un fichier de e e trace d’audit. Aussi. Ces trois ensembles doivent ˆtre maintenus ` jour explicitement par celui qui ´crit les r`gles via le mot-cl´ Trigger e a e e e off. Une trace d’audit est d´finie comme ´tant une s´quence finie d’enregise e e trements. Un contexte d’ex´e e cution est entre autres caract´ris´ par trois ensembles de r`gles : Cur. e e 1. il permet ee e de calculer une moyenne et de la sauvegarder quelque part. Lorsqu’un champ est absent. RUSSEL. 15.Chapitre 1.2. L’utilit´ de e e e e e ce dernier ensemble est de permettre d’effectuer des traitements sur des valeurs ayant ´t´ accumul´es tout au long du traitement de la trace d’audit. a ´t´ con¸u afin de pouvoir exprimer les signatures dans e ee c un langage typ´ proche de celui utilis´ pour exprimer les politiques de s´curit´ dans un e e e e contexte de d´tection d’intrusions au niveau r´seau. le langage utilis´ pour ´crire les signatures. il est tout de e . pere e e mettant de tester la pr´sence d’un champ. se trouve ` la table 1. Par exemple. aussi appel´es champs. nous proposerons une d´finition plus formelle permettant de d´partager e e les langages d´claratifs des langages imp´ratifs. pour palier aux probl`mes d´coulant du fait que certains champs e e e peuvent ˆtre absents de certains enregistrements. a ´t´ e e ee con¸u dans le but d’analyser s´quentiellement des fichiers d’audit. que nous pr´sentons dans un premier lieu. que c e nous pr´sentons par la suite. Comme l’ordre d’ex´cution des e r`gles n’est pas sp´cifi´. gloe e a e bales. nous pr´sentons deux e e e langages qui. qui eux sont d´finis comme ´tant une fonction partielle associant des valeurs e e ` un ensemble d’´tiquettes. Nxt et Cmp. Pour l’instant. et l’ensemble Cmp contient l’ensemble des r`gles e e e qui doivent ˆtre ex´cut´es une fois que tous les enregistrements sont trait´s. La synee e e taxe de RUSSEL. Ces enregistrements sont pass´s ` a e e e a ASAX dans un format normalis´ (Normalized Audit Data Format).

. . . le bloc correspondant est ex´cut´ et le bloc if . . E .. . . C → A . C → A . . . od | if . E . . . . . .E. La r`gle Count_rule1 d´montre la s´mantique particuli`re d’un bloc if . On remarque que la r`gle Failed_login se r´active inconditionnellement (ligne e e 8).Chapitre 1.2 – Syntaxe abstraite de RUSSEL. . ) | begin . chacune suivie d’un bloc d’actions. . e e e ` A la figure 1. . les deux r`gles Failed_login e e et Count_rule1 servent ` surveiller un utilisateur qui ´chouerait ` se connecter trop a e a souvent. 1. end | do . ) | trigger off M Q ( . et les r´sultats obtenus sont susceptibles d’ˆtre e e e e e tr`s diff´rents de ceux escompt´s. . .| * | div | mod >|<|=|=|≤|≥ for current | for next | at completion integer | byte | string A B C E F G H L M actions logical operators conditions expressions field names parameter declarations variable declarations literals triggering modes O P Q R S T V X Y arithmetic operators formal parameters rule names rules relational operators types local variables external function names external procedure names Tab. .. Cet e exemple a ´t´ copi´ tel quel de [14]. . . H . La valeur lue est alors celle qui ´tait pr´sente la dere e e ni`re fois que le champ ´tait pr´sent.9 se trouve un exemple de signature ´crit en RUSSEL pour ASAX. D`s qu’une e e condition est v´rifi´e. . . . . . . . . . A . . . . . . . Ensemble. . ) . . . . . G . Syst`mes de d´tection d’intrusions e e 20 R G H A : : : : := := := := C E B O S M T : : : : : : : := := := := := := := rule Q ( . . mˆme possible de lire sa valeur. . . Ces e e e e blocs renferment une s´rie de conditions. fi. . ) and | or + | . . Les variables evt et res sont des champs qui sont ee e suppos´s faire partie de chaque enregistrement. . . . fi est termin´. fi true | F present | not C | C B C | E S E L | V | F | P | -E | E O E | X(. A P:T V:T V := E | Y ( . . e e e e e . . .

Par exemple.fi Fig. → Trigger off for next Count rule1(countdown-1. il n’est pas du tout a clair que l’approche consistant ` d´velopper un nouveau langage ait ´t´ ici la meilleure a e ee ` adopter.if evt=’login’ and res=’failure’ and is unsecure (terminal) 06.Chapitre 1. 1. Ces notions permettent d’automatiser certaines tˆches communes au traia tement s´quentiel de fichier d’audit telles que la mise ` jour de la base de r`gles et la e a e mise ` jour des valeurs des champs des enregistrements. 08. 13.# it remains active until its expiration time or until the countdown becomes 0 14. and is unsecure(terminal) and timestp < expiration 16. true 24. la condition true est v´rifi´e et la r`gle est r´activ´e e e e e e e e e pour le prochain enregistrement. 21.# expiration time 04.begin 05. → Skip .rule Count rule1 (countdown.if evt=’login’ and res=’failure’ 15. Cependant. e ea e et arriver ` des r´sultats semblables sinon meilleurs du point de vue de la facilit´ de a e e maintenance et de la courbe d’apprentissage.9 – D´tection d’une p´n´tration externe dans ASAX. countdown =1 19. timestp+duration) 07. duration) 09. e e e L’instruction skip est l’instruction qui ne fait rien. Les notions particuli`res au langage RUSSEL auraient tr`s bien pu ˆtre ima e e e plant´es sans d´velopper un nouveau langage.end 10. duration : integer) 02. RUSSEL est un langage de programmation imp´ratif comportant. 11. → SendMessage (”too much failed login’s”) 20. 23. .# This rule detects a first failed login and triggers off an accounting rule with an 03. 18. → Trigger off for next Count rule1 (countdown. en e e e plus des notions les plus communes. → Trigger off for next Count rule1 (maxtimes-1. expiration) 25. → if countdown > 1 17. on aurait pu envisager une e e approche orient´e-objet dans un langage d´j` connu de la communaut´ (tel que C++). Donc. si le d´lai est ´coul´ (ligne 21).# This rule counts the subsequent failed logins.Trigger off for next Failed login (maxtimes. expiration) . timestp ≥ expiration 22. e e e la r`gle n’est pas r´activ´e. Syst`mes de d´tection d’intrusions e e 21 01. celles de contexte d’ex´cution et de variables d’ene registrement. En r´sum´. expiration : integer) 12. Sinon.rule Failed login (maxtimes. fi .fi .

les politiques de s´curit´ v´rifi´es e e e e e avec Bro sont normalement plus haut niveau que celles v´rifi´es par Snort. dans ce cas. 1. Syst`mes de d´tection d’intrusions e e 22 Interpréteur de scripts Module d ’événements Libpcap Réseau Fig. Ceci implique qu’un processus e e de filtrage est fait par le module d’´v´nements. Les m´canismes sont donc g´r´s au niveau du e e e e ee .10 – Structure de Bro. ceux fournis par le module d’´v´nements de Bro ` l’interpr´teur de e e a e scripts sont d’un type plus abstrait : celui d’´v´nement. Ce dernier est comparable au module de d´tection.Chapitre 1. e e Malgr´ le fait que les deux architectures puissent se ressembler au premier abord. Un des objectifs de cette ´tape e a e e de filtrage est de permettre au syst`me de fonctionner en temps r´el. ee e e e Alors que les objets fournis par les pr´processeurs de Snort au module de d´tection e e sont des paquets. est comparable ` celle de Snort. Son architecture logicielle en couches. Le module d’´v´nements fait un travail e e e relativement semblable ` celui auquel les pr´processeurs de Snort. 1. Aussi. A la base. et que seulement les informations jug´es e e e pertinentes sont pass´es ` l’interpr´teur de scripts. e e e d’´quivalent des modules d’affichage.10.2 BRO e e c e Bro [17] est un syst`me de d´tection d’intrusions con¸u sp´cifiquement en vue de d´tecter les attaques survenant au niveau r´seau. il s’agit d’un des objectifs e e poursuivis par les auteurs : permettre une s´paration claire entre les m´canismes et les e e politiques de s´curit´. Il n’y a pas. malgr´ la grande e e e affluence de trafic pouvant circuler sur le r´seau. En fait. sont les diff´rents moyens de g´n´rer e e e e e e un ´v´nement donn´. Les m´canismes. e e ` que l’on peut voir ` la figure 1. e il y a tout de mˆme deux diff´rences majeures entre les deux syst`mes : l’abstraction e e e cr´´e par le module d’´v´nements et la nature imp´rative du langage de signatures. alors que les politiques de s´curit´ sont les actions ` prendre e e e e e a lorsque les ´v´nements sont identifi´s. ´taient initialement destin´s : faire un premier travail de formatage e e e sur les paquets afin de simplifier la tˆche de l’interpr´teur de scripts de politiques de a e s´curit´.2. conjointement au a e module de d´codage. Tout est archiv´ dans des fichiers en format texte. voire mˆme la e e e plupart des autres syst`mes de d´tection d’intrusions. pour Bro. se trouve la a a mˆme librairie de capture de paquets (libpcap).

if ( full ) 16. Ces derni`res sont ´crites dans un langage e e e de signatures propre ` Bro. 21. 07. d’effectuer e un maximum de v´rification de types. . Les concepteurs n’ont toutefois pas relev´ de cas ou son utilisation e se faisait ressentir. celui de Bro est e e e un langage imp´ratif. req) . c$addl = c$addl == "" ? req : fmt("*%s. 18. moteur d’´v´nements. request) . c$id$orig_h.log") . quasi aussi expressif que le langage C (sa syntaxe en est d’ailleurs e en plusieurs points tr`s semblable). adresse IP. e e expressions compos´es. 14. 12. avec d´claration de variables (locales ou globales). 80)) .{ 05. . programm´ en C++. 11. 15. Cependant. Syst`mes de d´tection d’intrusions e e 23 01. 17. req = fmt("(%s)".6f %s". celui-ci ne dispose pas de construction syntaxique it´rative. nom r´seau.11 – Exemple de script Bro. log fmt("finger : %s". 08.event finger_request(c :connection. sub_bytes(request. Pour ce faire. comme la r´cursivit´ est tout de mˆme permise. local msg = fmt("%s > %s %s". c$id$resp_h. } 09. msg) . alors que les politiques de s´curit´ sont e e e e e mises en oeuvre par l’interpr´teur de scripts. .global finger_log = open("finger. alors. # This is an additional request. req) . 03. %s". request = fmt("%s. permettant d’exprimer naturellement des v´rifications e dans un langage proche des politiques de s´curit´ : si il y a une connexion Telnet e e sur un des serveurs d’impression. ++c$hot . local req = request == "" ? "ANY" : fmt("\"%s\"". req = fmt("%s (/W)". request : string.Chapitre 1. enregistrement . 02.. if ( c$hot > 0 ) 19.". Le langage dispose aussi de structures de donn´es abstraites : ensemble.} Fig. Un des objectifs vis´ par le e e e e d´veloppement de ce langage est de permettre. inf´rence et v´rification de types. if ( request in hot_names ) 10. ++c$hot . a Alors que le langage de signatures de Snort est un langage d´claratif d´crivant e e certaines caract´ristiques bien cibl´es des paquets circulant sur le r´seau.global hot_names = { "root". msg) . etc. 1. fmt("%. au moment de la compilation.. le langage de Bro dispose ee e e de plusieurs types de variables propres ` la r´seautique : port. a e e etc. if ( byte_len(request) > 80 ) { 06. 22. . "uucp" } . 20. de fa¸on ` ce qu’au moment de l’ex´cution. table e d’associations. print finger_log. Il est ` noter que bien que le langage de a Bro soit imp´ratif. l’it´ration e e e e e e est toujours possible. 1. c$addl. req) . "lp". req) . le e c a e type des variables r´f´renc´es soit coh´rent. Cette e e caract´ristique a ´t´ voulue par les concepteurs afin de minimiser le temps de traitement e ee d’un ´v´nement. c$start_time. full : bool) 04. if ( c$addl != "" ) 13.

des probl`mes reli´s e e e e au red´marrage du syst`me (souvent n´cessaire pour faire un nettoyage de la m´moire). il est pass´ au moteur d’´v´nements. le champ hot est encore incr´ment´. Ensuite. trait´s par l’interpr´teur de scripts de e e e politiques de s´curit´. Il e ee e e . si le champ hot a ´t´ e a ee incr´ment´ (ligne 18). Syst`mes de d´tection d’intrusions e e 24 ` A la figure 1. Cet exemple. Ces ´v´nements sont e e e ee e e e alors plac´s dans une file d’attente et. la requˆte est enregistr´e dans le e e e e champ addl de la connexion (ligne 21). Quiconque s’engage dans des travaux reli´s ` la d´tection d’intrusions en temps e a e r´el devrait au moins prendre quelques minutes pour jeter un oeil ` cet article.Chapitre 1. Lorsqu’un paquet est captur´ sur le r´seau par e e e la librairie libpcap. e e a e e L’op´rateur in (ligne 9) sert ` v´rifier si un ´l´ment fait partie d’un ensemble. Le script e a e ee v´rifie en premier lieu si la requˆte est excessivement longue (ligne 5). tir´ de [17]. montre comment on doit r´agir ` e e a une requˆte finger. e e Les travaux entourant Bro sont grandement motiv´s par la pratique et l’article [17] e traite de plusieurs probl`mes concrets devant ˆtre pris en compte lors de la concepe e tion d’un syst`me de d´tection d’intrusions en temps r´el. il v´rifie si la requˆte e e e e e concerne un nom sensible (ligne 9). e e La variable locale req est ensuite initialis´e (lignes 11 ` 16) et. L’auteur parle entre autres e e e des diff´rentes fa¸ons d’attaquer le syst`me lui-mˆme et des moyens de s’en d´fendre. L’algorithme de v´rification en temps-r´el de Bro fonctionne en une seule passe et e e suivant un seul fil d’ex´cution (thread). une notification en temps r´el est effectu´e (ligne 19). Le cas advenant. e e celle-ci est tronqu´e et le champ hot est incr´ment´. Bro est un syst`me de d´tection d’intrusions fonctionnant au niveau e e e e r´seau dont la conception a grandement ´t´ influenc´e par des probl`mes pratiques. Advenant le cas o` une autre requˆte a eu lieu u e dans le contexte de la mˆme connexion. elle est ajout´e ` celle s’y trouvant d´j` et un ast´risque est ajout´ pour e a ea e e attirer l’attention lors de l’inspection du fichier d’audit. Ceux-ci sont effectu´s dans l’ordre o` ils apparaissent dans le fichier de script.11. des diff´rentes fa¸ons de g´rer les chronom`tres. cr´er d’autres a e e e ´v´nements qui iront se placer ` la fin de la file et devront ˆtre trait´s avant de retourner e e a e e au moteur d’´v´nements et de passer au paquet suivant. Si tel est le cas. L’op´rateur $ sert ` acc´der aux diff´rents champs des structures. un type d’´v´nement e a e e e e e donn´ peut ˆtre g´n´r´ par plusieurs types de paquets diff´rents). e a En r´sum´. on peut voir un exemple de script de politique de s´curit´ ´crit e e e dans le langage de Bro. des e c e e avantages et des inconv´nients de disposer d’un langage compil´. Celui-ci peut alors g´n´rer de e e e e e z´ro ` plusieurs ´v´nements pour un seul paquet (r´ciproquement. ce qui peut ˆtre associ´ ` un comportement e e ea malicieux. e c e e e des probl`mes reli´s ` la surveillance de r´seaux haut-d´bit (principalement en ce qui e e a e e concerne la perte de paquets). il peut y avoir plusieurs traitements ` e e e e e a faire. Pour un ´v´nement donn´. Il e u est ` noter que ces traitements peuvent. Dans tous e e e e les cas. Finalement. par la suite. la requˆte est archiv´e (ligne 20). e e e e etc. en plus de g´n´rer des alarmes.

qui diff`rent des automates traditionnels par la pr´sence de variables dans les e e e ´tats permettant de relier les diff´rents symboles de l’alphabet (ou ´v´nements) entre e e e e eux. nous pr´senterons BSML.3 Syst`mes de transitions e Les syst`mes de transition jouissent d’une grande popularit´ en informatique lorsque e e vient le temps de d´crire des programmes ou des processus de fa¸on abstraite. dans un premier lieu. e e 1. Ceci est dˆ au fait que STATL. Les syst`mes de d´tection d’intrusions que nous allons pr´senter ee e e e dans cette section utilisent diff´rents formalismes bas´s sur des syst`mes de transitions e e e pour repr´senter les attaques. Les aue c e teurs de ces travaux. qui diff`rent des r´e e e e seaux de Petri conventionnels de la mˆme fa¸on. Il faut o e e tout de mˆme donner ` Bro le m´rite d’avoir eu l’id´e de s´parer les m´canismes des e a e e e e politiques au niveau mˆme de l’architecture du logiciel et d’avoir pr´vu deux modules e e diff´rents pour g´rer ces deux aspects. utilise plusieurs u types de transitions pour sp´cifier l’algorithme de v´rification reli´ ` l’automate. utilise les r´seaux de Petri color´s. Les obe c jectifs vis´s par ces descriptions varient de la simple communication entre les diff´rents e e intervenants dans le processus de d´veloppement ` la v´rification automatique de proe a e pri´t´s de programmes. STAT. BSML n’a pas exactement la mˆme expressivit´ e e e que STATL. utilise les automates g´n´e e e ralis´s. Chacun des syst`mes que nous pr´sentons dans cette section a ´t´ con¸u dans l’id´e e e ee c e de permettre la repr´sentation des signatures d’attaque de fa¸on d´clarative. consid`rent que e . alors e e ea que les expressions de BSML sont traduites en automates g´n´ralis´s avec seulement e e e des transitions classiques. IDIOT. L’avantage des r´seaux de Petri sur les e c e automates est de permettre une repr´sentation du synchronisme et du parall´lisme de e e fa¸on plus naturelle. En troisi`me et dernier lieu. Son architecture en couches. qui diff`rent elles aussi des exprese e e e e sions r´guli`res par la pr´sence de variables du premier ordre. Syst`mes de d´tection d’intrusions e e 25 vient avec un langage imp´ratif interpr´t´ qui permet d’exprimer des scripts v´rifiant e ee e des politiques de s´curit´ ` un plus haut niveau que la plupart des autres syst`mes de e ea e d´tection d’intrusions. qui se base c e e sur les expressions r´guli`res pour les ´v´nements. a ´t´ e a ee con¸u avec un souci d’extensibilit´ et permet d’ajouter des modules d’´v´nements et c e e e de d´finir nos propres politiques de s´curit´ assez facilement. comme nous le verrons. dans un second lieu.Chapitre 1. surtout en ce qui concerne STATL et IDIOT. Le langage utilis´ pour e e e e exprimer les politiques de s´curit´ reste cependant imp´ratif. ainsi que de contraintes e e e de temps. que les politiques elle-mˆmes. semblable ` celle de Snort. ce qui implique que l’on e e e indique plutˆt comment v´rifier les politiques. Mˆme si les expressions r´guli`res sont connues pour avoir le mˆme pouvoir e e e e de repr´sentation que les automates.

comme mentionn´ dans le premier paragraphe de la d´finition. e e These kinds of programming language describe relationships between variables in terms of functions or inference rules.3. or procedural languages which specify an explicit sequence of steps to follow. The most common examples of declarative languages are logic programming languages such as Prolog and functional languages like Haskell.Chapitre 1. on r´alise alors que l’on se rapproche de la fronti`re e e e entre langage d´claratif et langage imp´ratif. comme nous le verrons.org . la d´finition suivante : e e D´finition 1.1 (Langage d´claratif ) Any relational language or functional language. permettant de e e e e e sp´cifier des automates. les extensions USTAT [19] et WinSTAT permettent de sp´cifier e des signatures au niveau hˆte pour les syst`mes d’exploitation Unix et Windows. Tous les langages ´tudi´s dans le reste de ce chapitre disposent d’un algorithme fixe e e de v´rification. plusieurs sont aussi pourvus de constructions syntaxiques qui permettent de modifier explicitement le contenu de la m´moire. La s´mantique attribu´e ` ces syst`mes d´pend de l’extension e e e a e e utilis´e. STATL (STAT Language). En se r´f´rant au e ee second paragraphe de la d´finition. and the language executor (interpreter or compiler) applies some fixed algorithm to these relations to produce a result. Le formalisme utilis´ pour sp´cifier les signatures se base sur les automates e e e g´n´ralis´s. Les diff´rentes extensions permettent de faire diff´rents types de d´tection d’ine e e e trusions.foldoc. Le dictionnaire en ligne Foldoc propose. STAT fournit un langage g´n´ral. Syst`mes de d´tection d’intrusions e e 26 les syst`mes de transition constituent un moyen de repr´senter ce qui doit ˆtre d´tect´ e e e e e 2 plutˆt que comment le d´tecter. nous sommes prˆts ` ´tudier les syst`mes de d´tection d’intrue e e ae e e sions bas´s sur les syst`mes de transition. pour le terme o e langage d´claratif. e e Maintenant que nous avons une d´finition plus claire de la diff´rence entre langage e e d´claratif et imp´ratif. Declarative languages contrast with imperative languages which specify explicit manipulation of the computer’s internal state . Par exemple. Cepene e e dant. alors o e 2 www. qui sont ` la fronti`re entre les deux types de e e a e langages. 1.1 STAT STAT (State Transition Analysis Technique) [18] utilise une approche qui se veut d´clarative.

la transition e e Timed_out est activ´e et le sc´nario passe (sans duplication. Finalement. Il est possible d’exploiter ce fait pour effectuer une attaque de d´ni de service. pour un serveur donn´. tir´ de [18]. avec la transition e SYN. e e est activ´e lorsqu’un paquet de type SYN (ayant le drapeau SYN activ´ et le drapeau e e ACK d´sactiv´) est identifi´. une copie du sc´nario est effectu´e avant de passer ` l’´tat s1. l’´tat en attente de confirmation (s1). En arrivant dans l’´tat s1. puisque la transition est de e e . La premi`re transition du sc´nario.12 e e comporte donc trois ´tats : l’´tat initial (s0). a e e le syst`me change d’´tat. et e e e l’´tat final s2. On voit bien. Le sc´nario de la figure 1. indiquant combien e e e e de temps on doit attendre la confirmation. ils permettent d’´liminer e e e e toutes les copies ayant ´t´ faites du syst`me depuis qu’il a travers´ un ´tat donn´. Plus sp´cifiquement.12. e e e e avant l’´coulement du d´lai. le chronom`tre t0 est a e e d´marr´ avec comme d´lai la valeur de la variable timeout fournie en param`tre. Si. au contraire. e e Les syst`mes de transition d´finis ` l’aide du langage STATL sont constitu´s d’´tats e e a e e et de transitions. qui peuvent ˆtre activ´es par les actions effectu´es sur e e e le syst`me. e e a e Si. non-consuming. lors de l’activation de cette transition. les actions unwine ding permettent d’´liminer des syst`mes. Les transitions non-consuming cr´ent une copie du syst`me e e e e avant de changer d’´tat. les deux parties constituantes d’une transition : la condition d’activation et les actions ` poser lors de l’activation. Syst`mes de d´tection d’intrusions e e 27 que l’extension NetSTAT [20] permet de sp´cifier des signatures au niveau r´seau. e ` A la figure 1.Chapitre 1. connue sous le nom de SYN-Flood. Une e e a session TCP est dite ` demi ouverte si le serveur a accept´ une demande de connexion a e (le SYN et le SYN-ACK ont eu lieu) et est en attente de la confirmation (le dernier ACK) de la part de l’hˆte ayant demand´ la connexion. Ceci ee e e e e permet de repr´senter le fait qu’une action peut tout annuler. celui-ci peut cesser d’accepter e a de nouvelles connexions. Les transie tions de type consuming correspondent exactement aux transitions r´guli`res des autoe e mates finis : lorsque l’action correspondant ` l’´tiquette de la transition est effectu´e. un paquet ACK ou un paquet RST sont vus pour les e e adresses IP et les ports TCP correspondant au SYN (transitions ACK et RST). Le sc´nario est param´tr´ par une variable. signifiant que e e e lorsqu’elle est activ´e. aucun de ces paquets n’est vu avant que le d´lai ne s’´coule. de sc´nario exprimable ` l’aide e e a du langage STATL. sont de trois types : consuming. Si. Cette transition est de type non-consuming. les variables locales du sc´nario servant e ` m´moriser les adresses IP et les ports TCP de la victime et de l’attaquant sont a e initialis´es selon les valeurs contenues dans le paquet. on peut voir un exemple. e e e a e Aussi. o e e trop de connexions sont simultan´ment ` demi ouvertes. Les transitions. alors les transitions non-consuming permettent ee de sp´cifier l’existence d’une prochaine action telle que. tout est annul´ et le sc´nario retourne ` l’´tat original car ces transitions sont de type unwinding. Ce sc´nario permet de d´tecter une session TCP ` demi ouverte. Les transitions consuming permettent donc de sp´cifier des proe e pri´t´s de la prochaine action telle que. et unwinding. timeout. SYN.

victim_addr. Syst`mes de d´tection d’intrusions e e 28 use netstat . } state s2 { { HALFOPENTCP e .header.flags & TH_RST) } transition Timed_out (s1 -> s2) consuming { timer t0 .header.header.header. timer t0 . 1.header. start) .header. e = new HALFOPENTCP(attacker_addr. } } state s1 { { timer_start(t0. } } } Fig.header. scenario halfopentcp(int timeout) { IPAddress victim_addr .header.dst . a .dst==victim_addr) && (tcp.dst .Chapitre 1.flags & TH_ACK) } transition RST (s1 -> s0) unwinding { [IP ip [TCP tcp]] : (ip.header. attacker_port=tcp.header. initial state s0 {} transition SYN (s0 -> s1) nonconsuming { [IP ip [TCP tcp]] : (tcp.header.src==attacker_addr) && (tcp.flags & TH_ACK) { victim_addr=ip. attacker_port.src . Port attacker_port .src==attacker_port) && !(tcp. enqueue_event(e.src==victim_addr) && (tcp.flags & TH_SYN) && (tcp.header.tcp_header. timeout) . start) .dst==attacker_port) && (tcp.header. victim_port.header.src .12 – Session ` demi ouverte dans NetSTAT.dst==victim_port) && (ip. HALFOPENTCP. IPAddress attacker_addr . Port victim_port . attacker_addr=ip.header.tcp_header. victim_port=tcp.src==victim_port) && (ip. } } transition ACK (s1 -> s0) unwinding { [IP ip [TCP tcp]] : (ip.flags & TH_SYN) && !(tcp.dst==attacker_addr) && (tcp.

Chapitre 1. Syst`mes de d´tection d’intrusions e e 29 Fig.13 – Session ` demi ouverte dans l’outil STATed. 1. 1. a Fig.14 – Mod´lisation d’un r´seau avec NetSTAT. e e .

14. Le deuxi`me avantage de l’approche choisie e e r´side dans le choix de r´seaux color´s. la sp´cification de la topologie permet. Le formalisme employ´ pour sp´cifier les signatures se base sur les r´seaux de Petri e e e color´s.2 IDIOT e IDIOT [21. Cette approche pr´sente deux avantages. comme avec e e e e e STAT. le langage STATL e a e a comporte encore une bonne part d’imp´rativit´. en fonction des attaques que l’on veut d´tecter. Wilder ne o e a devrait pas voir passer de message en provenance de Carpenter pour Lang. d’une attaque SYN-Flood. A e repr´sentation graphique de ce sc´nario. Un aspect tr`s int´ressant de l’extension e e e e NetSTAT est la prise en compte de la topologie pour sp´cifier. e e En bref. 22. le syst`me STAT. avec ses trois types de transition. Par exemple. avec le langage STATL. Cependant.Chapitre 1. les r´seaux de Petri e e e e permettent de bien repr´senter le parall´lisme et le synchronisme. obtenue ` l’aide de l’outil STATed. e e e e Un aspect int´ressant de l’extension NetSTAT est qu’elle permet de sp´cifier la topoe e logie du r´seau afin d’am´liorer la d´tection d’intrusions. de d´tecter des attaques d’usurpation d’identit´ en calculant le chemin par e e lequel deux hˆtes sont suppos´s communiquer. e par exemple.14. ` la figure 1. alors que le synchronisme est repr´sent´ e e e e e par l’utilisation des variables partag´es. servant ainsi ` e a ` la figure 1. on peut voir une la d´tection. En arrivant dans cet ´tat. ils e e e e . La sp´cification comprend en outre des renseignements sur ces hˆtes et ces e o interfaces tels que leurs adresses mat´rielles et logicielles. On peut voir. un ´diteur e e a e de sc´narios t´l´chargeable avec STAT. a e e e e ee signalant ainsi le fait qu’une session ` demi ouverte a ´t´ identifi´e. tout comme STAT.13. e e alors que les hˆtes et les liens de donn´es sont vus comme deux partitions diff´rentes de o e e cet ensemble. utilise une approche qui se veut d´clarative. Les r´seaux color´s permettent. Premi`rement. un nouvel ´v´nement est cr´´. par exemple. 23]. ses variables e partag´es et ses actions ` ex´cuter ` l’activation des transitions. Les conditions d’activation et les actions ` poser e ee a peuvent ˆtre sp´cifi´es en cliquant sur les ´tats et les transitions. ` la figure 1. deux ph´nom`nes e e e e bien pr´sents en d´tection d’intrusions. e e de calculer l’emplacement des sondes et de les configurer pour qu’elles surveillent les ´v´nements pertinents. am´liorer et automatiser e e une partie de la d´tection d’intrusions. de d´finir des patrons d’´v´nements reli´s les uns aux autres. Ces informations permettent. Un r´seau est vu comme un ensemble d’interfaces. Finalement. Cet ´v´nement peut a ee e e e alors servir de condition d’activation aux transitions d’autres sc´narios. constitue une avanc´e en direction e e d’un langage d´claratif. e 1. Par exemple. e e e a un exemple de telle mod´lisation. le parall´lisme est sous-entendu par e e e l’ex´cution parall`le des syst`mes de transition.3. Avec STAT. Syst`mes de d´tection d’intrusions e e 30 type consuming) ` l’´tat s2.

neg invariant first inv state inv start. extern int RLOGIN PORT CLIENT. 17. 27. 15. pattern TCP Conn Mon ”Monitor rlogin connections” priority 10 04. end tcp 3 . 25. 38.} end rst .} end tcp 1 . <. . 31. trans tcp 3(TCP) 37. 24. 21.start . 45. -> inv final . | {this[SYN] = 1 && this[ACK] = 0 && FROM PORT = this[FROM PORT] && this[TO PORT] = RLOGIN PORT SERV && FROM HOST = this[FROM HOST] && TO HOST = this[TO HOST] . post action{print tcp conn(FROM HOST. inv final . 23. 16. nodup state after syn. 30. int FROM PORT. (this[TO PORT] = RLOGIN PORT SERV) && 42. 02. 39. Fig. 28. (this[FROM PORT] = FROM PORT) && 41. 05. 14. state after ack .Chapitre 1. FROM HOST . 1. trans rst(TCP) <. 35. 36. int) . } 44.inv start . TO HOST) . 29. 08. 32. (this[FROM HOST] = FROM HOST) && (this[TO HOST] = TO HOST) . 07. 19. 26. | { this[SYN] = 0 && this[ACK] = 1 && 40. | {this[RST] = 1 && TO HOST = this[FROM HOST] && this[TO HOST] = FROM HOST .after syn .} 10.15 – Session TCP dans IDIOT. 20. int TO PORT. | { this[SYN] = 1 && this[ACK] = 1 && (this[FROM PORT] = RLOGIN PORT SERV)&& (this[TO PORT] = FROM PORT) && (this[FROM HOST] = TO HOST) && (this[TO HOST] = FROM HOST) . 09. RLOGIN PORT SERV. after syn ack . trans tcp 2(TCP) <. 12. 13. -> after ack . 11. print tcp conn(int. Syst`mes de d´tection d’intrusions e e 31 01. 18. } end tcp 2 . 33. -> after syn . TO HOST .after syn ack . end first inv trans tcp 1(TCP) /* TCP is the event type of the transition */ <. end TCP Conn Mon . -> after syn ack . 22. 43. state start . 06. 34. 03.

alors que le e e reste sp´cifie les conditions devant ˆtre respect´es par le jeton pour que la transition e e e soit activ´e. l’absence dans la litt´rature d’une documentation compl`te du langage. l’invariant nous permet de e sp´cifier qu’aucun paquet RST ne doit ˆtre envoy´ pendant l’´tablissement d’une session e e e e TCP.7. et il fait partie des syst`mes qu’il ne o e nous a pas sembl´ possible de t´l´charger. Le mot-cl´ nodup. qui se mat´rialise par la pr´sence du mot-cl´ extern. sa d´pendance envers un e e e autre langage. Cependant. 27 ` 35. Ce que nous avons ` notre disposition est e ee a un nombre assez restreint d’exemples tir´s d’articles. e e e On obtient donc ici un r´sultat semblable aux transitions consuming de STAT. La notion d’invariant. Les deux a a a e premi`res lignes indiquent les ´tats entrants et sortants de la transition. et 8 se e e e trouvent les d´clarations des ´tats.3. e En r´sum´. ne e e serait-ce que de sa syntaxe. La documentation sur IDIOT est plutˆt rare. Les lignes 19 ` 26.15 est e tir´ de [23].Chapitre 1. a e e e e e en IDIOT. Comme l’´tablissement d’une session TCP se fait e e e en trois ´tapes. une copie en est plac´e dans transitions. nous empˆche de porter un jugement ´clair´ ` souhait sur e e ea ses forces et ses faiblesses. Syst`mes de d´tection d’intrusions e e 32 permettent de sp´cifier que deux paquets diff´rents doivent avoir les mˆmes adresses IP e e e sources et destination. La e e o ligne 9 sp´cifie quelle est l’action ` effectuer lorsque l’´tat final a ´t´ atteint. ` la e e e e a ligne 7. e a a e Finalement. on a besoin de quatre ´tats pour la sp´cifier. signifie que lorsqu’une transition sortante est activ´e. s’apparente ` la notion de transition unwinding en STATL. Il montre comment on peut utiliser. Aux lignes 6. avec ses propres ´tats et ses propres e e ` chaque fois qu’un jeton sort de l’´tat initial. en fait un syst`me e e e e incomplet qui devrait finalement plutˆt ˆtre vu comme une librairie compl´mentaire o e e ` un syst`me d´j` existant. sauf e que la sp´cification se fait au niveau des ´tats plutˆt qu’au niveau des transitions. dans le syst`me IDIOT. L’exemple de la figure 1.3 BSML Le langage BSML (Behavioral Specification Monitoring Language) [24] tend lui aussi vers une approche d´clarative. et 36 ` 45 sp´cifient chacune des transitions. l’´tat n’est pas dupliqu´. le syst`me IDIOT semble pr´senter certains avantages au niveau de la e e e e repr´sentation du parall´lisme et du synchronisme. Dans l’exemple qui nous occupe. Le formalisme utilis´ pour repr´senter les comportements e e e . De plus. la pr´sence du mot-cl´ nodup nous am`ne au a e ea e e e mˆme reproche que nous avons fait ` STAT quand ` la nature d´clarative du langage. Les lignes e a e ee 10 ` 18 sp´cifient un invariant qui doit ˆtre v´rifi´ par le syst`me. A e e l’´tat initial de l’invariant. La sp´cification a e d’un invariant prend la forme d’un r´seau de Petri. les r´seaux de e e e Petri color´s pour sp´cifier l’´tablissement d’une session TCP. 1.

16 est tir´ de [24]. on d´clare la table neptune qui servira e a e . soit la r´p´tition un nombre ind´termin´ de fois du patron p (p∗ ). soit le patron p1 ou bien le patron p2 e (p1 ||p2 ). soit le pae e e e tron p devant survenir dans l’intervalle de temps [t1 . La notion e e de compteur en BSML est assez originale car elle permet de donner une valeur plus ´lev´e aux ´v´nements plus r´cents. . on d´finit l’´v´nement tcp_syn(p) e ` e e e comme ´tant la r´ception d’un paquet (rx(p)) tel que le drapeau tcp_syn est activ´. (!(p||q))∗ . t]. soit la non-occurrence d’un patron donn´ (!p). 1. soit le patron e p1 suivi imm´diatement du patron p2 (p1 . . . on utilise les expressions p over t et e e p within t pour abr´ger respectivement p within [t. Un e a patron d’´v´nements est soit un ´v´nement primitif. . Aussi. t2 ]). .Chapitre 1. Aux lignes 9 ` 13. Les conditions d’activation des actions associ´es e e e e e e aux compteurs ne sont alors plus n´cessairement d´finies sur le nombre d’´v´nements e e e e identifi´s. mais sur le poids pond´r´ de ces ´v´nements. Aux lignes 1 ` 3. xn )|cond !p p1 . .q est utilis´e pour abr´ger p. Une sp´cification e e BSML est un ensemble de d´clarations de variables ainsi que de couples p → act.q) e e e comme ´tant l’envoi. t2 ] Tab. t2 ] (p within [t1 . e ee e e e a e L’exemple de la figure 1.. L’expression p. e e La syntaxe des ERE utilis´es dans le langage BSML se trouve ` la table 1. ` identifier est celui des expressions r´guli`res pour les ´v´nements (ERE). q. . o` act e u est une action ` poser chaque fois que le patron p est reconnu. i. A la ligne 5. ` la ligne 7. p2 p1 ||p2 p∗ p within [t1 . Cette signature sert ` d´tecter une inondation TCP SYN. ∞] et p within [0. en direction oppos´e au syn_ack. a e a e e avec les adresses IP et les ports invers´s). on d´finit l’´v´nement tcp_syn_ack(p. xn ) et rese e e e e e pectant la condition cond.3. d’un paquet ayant les drapeaux tcp_syn et e e tcp_ack activ´s. . en direction oppos´e.e. d´cr´mentation) d’un e e e compteur. on d´finit un pr´dicat sur deux paquets TCP servant a e e ` v´rifier si ceux-ci appartiennent ` la mˆme session (dans des directions oppos´es. d’un paquet ayant seulement le e e e drapeau tcp_ack d’activ´. Les diff´a e e e e e rences entre les expressions r´guli`res conventionnelles et les ERE sont la pr´sence de e e e pr´dicats du premier ordre pour relier les ´v´nements entre eux et la possibilit´ de e e e e sp´cifier des contraintes de temps-r´el. Cette action peut ˆtre a e un simple archivage ou encore la manipulation (incr´mentation. p2 ). Finalement. Syst`mes de d´tection d’intrusions e e 33 p := e(x1 . Plusieurs compteurs peuvent aussi ˆtre regroup´s dans une table. e e e ` mais pas le drapeau tcp_ack. A la ligne 6. e Une sp´cification BSML ne comporte cependant pas que des ERE. param´tr´ par (x1 . on d´finit l’´v´nement tcp_ack(q. r) comme e a e e e ´tant la r´ception.3 – Syntaxe des patrons dans BSML.

p1.tcp_dport)) Fig. neptune. les symboles de l’alphabet (´v´nements primitifs) sont donc eux aussi caract´ris´s par des variables.saddr=q. chaque fois que 4 incr´mentations sur une e e entr´e de la table sont faites dans un intervalle de 120 secondes.inc((p1.daddr.p3))* over 60) -> 16.tcp_sport=q. neptuneBegin. La diff´rence entre une machine ` ´tat ´tendue et une machine ` ´tats ae e e ae e ae conventionnelle est la mˆme qu’entre des r´seaux de Petri conventionnels et des r´seaux e e e de Petri color´s : les ´tats de la machine contiennent des variables qui permettent de e e relier entre eux les symboles lus par la machine.saddr && p. q) = 02. e Le langage BSML est un langage compil´.tcp_syn && r. /*size 1000. BSML peut donc servir non-seulement au niveau r´seau. 05.. 1.r) && !r.Chapitre 1. Syst`mes de d´tection d’intrusions e e 34 01. Dans [25].) 14. neptuneEnd /* thresholds and associated functions*/ 13. p. mais aussi au niveau e . L’avantage e principal de cette d´marche. r) = rx(r)| same_session(q. par exemple pour lancer une alerte. mais aussi les e comportements qui doivent survenir.daddr=q. window 120 seconds */ 12. Les e e auteurs jugent aussi que cette d´marche diff`re suffisamment des d´marches statistiques e e e et ` base de sc´narios pour en faire une troisi`me cat´gorie : d´tection d’intrusions ` a e e e e a base de sp´cifications.tcp_syn && q. 4. non pas bas´e sur des m´thodes statistiques et l’´tablissement e e e e empirique d’un profil normal.tcp_sport && 03.tcp_synack(p1.event tcp_syn(p) = rx(p)| p. on trouve une sp´cification compl`te de ftpd faite avec e e e BSML. La cl´ de cette table a e ee e est le couple adresse-port destination du paquet syn. 09.p2)) . 120. Bien entendu.tcp_dport=q. La fonction neptuneBegin est appel´e. le langage BSML permet e e a non-seulement de sp´cifier les comportements qui ne doivent pas survenir.Table neptune( 10. q) = tx(q)| same_session(p.same_session(p.event tcp_synack(p. (unsigned int.event tcp_ack(q. Cette incr´mentation e e est elle-mˆme effectu´e chaque fois que les deux premi`res ´tapes d’une poign´e de main e e e e e TCP sont effectu´es mais que la troisi`me ne survient pas dans les 60 secondes suivant e e la deuxi`me (lignes 15 et 16).port)*/ 11. est la d´tection d’attaques inconnues. ` compter les occurrences de poign´es de main non-compl´t´es. selon les auteurs. e e e e Contrairement aux langages ´tudi´s jusqu’` maintenant.tcp_ack 07.tcp_syn && !p.tcp_dport 04. 1000.16 – Attaque TCP SYN-Flood dans BSML.(( !tcp_ack(p2. p.tcp_ack 08. unsigned short) /*key : (IP address.q) && q.(tcp_syn(p1). 1. lan¸ant ainsi des alarmes lorsque le comportement c observ´ d´vie de ce qui est attendu.tcp_ack 06. 15.daddr && p. mais sur la sp´cification explicite de ce profil. et les ERE sont transform´es en machines e e ` ´tats ´tendues. Le langage BSML permet ainsi une certaine forme e e de d´tection d’anomalies.

.4 Syst`mes experts e Un syst`me expert est un logiciel capable d’accumuler et d’inf´rer de la connaise e sance. . Par exemple : SI il y a de la fum´e ALORS il y a e du feu. De plus. Peu importe le domaine. Ce langage est e e e compil´ vers un autre formalisme qui le rend comparable ` STATL et ` IDIOT : cee a a lui des machines ` ´tat ´tendues. mis au point dans les ann´es 70 ee e e afin d’aider les m´decins ` poser des diagnostics sur les maladies infectieuses du sang. e En r´sum´. e a Le syst`me demande au m´decin quels sont les symptˆmes de la maladie.Chapitre 1. ajout´e ` la r`gle SI il y a du feu ALORS on doit sonner l’alarme e e a e d’incendie. il est celui e e qui se rapproche le plus d’un langage d´claratif car les actions pos´es lors de la recone e naissance de patrons n’influencent pas la reconnaissance ult´rieure d’autres patrons. e e 1. Parmi les trois langages ´tudi´s dans cette section. BSML est un langage simple et concis bas´ sur un formalisme coue e e ramment utilis´ par les informaticiens : celui des expressions r´guli`res. e e e 35 Les actions effectu´es lors de la reconnaissance de patrons peuvent d´passer le simple e e archivage : il peut aussi s’agir d’instructions visant ` prot´ger le syst`me qui se fait a e e attaquer. e Les syst`mes experts en d´tection d’intrusions sont int´ressants pour deux raisons : e e e leur capacit´ d’accumuler et d’inf´rer de la connaissance permet une d´tection plus pr´e e e e . les syst`mes experts sont souvent appel´s ` prendre des d´cisions. permet au syst`me expert de recommander de sonner l’alarme d’incendie e lorsqu’il y a de la fum´e. Il s’agit cependant ee d’un bon compromis entre expressivit´ et complexit´ algorithmique. BSML permet ainsi non-seulement une d´tection d’intrusions en temps r´el. . Cette r`gle. . et pose un e e o diagnostique ` l’aide d’une base de r`gles ayant pr´alablement ´t´ ´tablie par d’autres a e e eee m´decins. l’hypoth`se de e base faite sur les raisonnements effectu´s par les experts est que ceux-ci sont g´n´ralee e e ment de la forme SI. Un e e a e exemple c´l`bre de syst`me expert est celui de MYCIN. e Cependant. les actions pos´es par les compteurs indiquent qu’ils jouent eux aussi un e rˆle important dans l’expressivit´ du langage et que les expressions r´guli`res ` elles o e e e a seules ne sont pas suffisantes pour exprimer les propri´t´s voulues. Il dispose de primitives permettant d’exprimer des a e e contraintes temps-r´el pos´es sur les ´v´nements et de relier ceux-ci entre eux par la e e e e valeur de leurs attributs. Syst`mes de d´tection d’intrusions e e des applications s’ex´cutant sur un syst`me donn´. e e mais aussi une pr´vention d’intrusion. L’objectif d’un syst`me expert est de simuler le raisonnement d’un expert e e dans un domaine particulier de connaissance. ALORS. .

* indiquent e e e e le niveau de priorit´ de la r`gle et le fait que la mˆme r`gle peut ˆtre appliqu´e plusieurs e e e e e e fois ` un mˆme ´v´nement. Par abus de langage. Les param`tres #10 . le a u e e o chaˆ ınage avant s’impose donc comme la voie ` suivre. nous donnerons deux exemples de syst`mes exc e e perts employ´s en d´tection d’intrusions : P-BEST et Lambda. alors que LAMBDA a d’abord ´t´ con¸u comme un e ee c langage ayant pour objectif de permettre aux experts du domaine de transcrire leurs connaissances dans un langage simple. Syst`mes de d´tection d’intrusions e e 36 cise. ` chaque ajout d’un nouveau fait.Chapitre 1. Cette philosophie a e s’oppose au chaˆ ınage arri`re. en th´orie. 28] est en fait un ensemble d’outils permettant de d´velopper un syst`me expert. on voit comment le langage fourni par a a P-BEST permet de d´clarer des types d’´v´nements. un syst`mes expert comporte e e e trois composantes principales : un moteur d’inf´rence. Les niveaux de priorit´ permettent de sp´cifier que certaines a e e e e e r`gles doivent ˆtre ex´cut´es avant d’autres. Il ne s’agit pas d’un syse e t`mes expert au sens propre du terme car.4. et o` les conclusions critiques doivent ˆtre tir´es aussitˆt que possible. et leur capacit´ ` prendre des d´cisions permet de r´agir aux attaques identifi´es de ea e e e fa¸on automatis´e.17. Aux ligne 1 ` 3. Un exemple de r`gle d’inf´rence utilis´e par Pe e e BEST se trouve ` la figure 1. o` chaque ´v´nement signal´ correspond e e u e e e ` un fait.1 P-BEST P-BEST (Production-Based Expert System Toolset) [26. 1. et ` e a a inf´rer sur demande. ee e e e e P-BEST fournit un langage compil´ en C qui offre la possibilit´ de faire appel ` des e e a routines programm´es dans ce langage. Ceci signifie que. l’ensemble des r`gles d’inf´rence est parcouru et a e e que toute l’information d´ductible de ce fait est ajout´e ` la base de connaissance. nous dirons tout e de mˆme que P-BEST est un syst`me expert. De plus. peut causer des boucles infinies ` l’ex´cution du syst`me e e a e e . P-BEST est un syst`me e e e expert ayant ´t´ employ´ pendant plusieurs ann´es dans le domaine de la recherche ee e e et de la d´tection d’intrusions. Pe e e BEST ne comporte que les deux premi`res composantes. indiquant que la r`gle peut e e e e e e ˆtre rappel´e plusieurs fois. 27. qui d’un point de vue pratique e ne forment qu’une seule et mˆme composante. le chaˆ a ınage avant permet ` P-BEST de conserver un minimum d’information en ne conservant dans sa base de a faits que ceux qui ont ´t´ d´duits et en ´liminant ceux correspondant aux ´v´nements. L’op´rateur *. qui consiste ` emmagasiner seulement les faits de base. e e D’un point de vue algorithmique. un moteur de d´cision et une e e base de connaissance (qui elle mˆme se divise en faits et en r`gles d’inf´rences). En d´tection d’intrusions. La e e a base de faits contient donc ` la fois les faits de base et les faits calcul´s. P-BEST fonctionne en chaˆ ınage avant. conservant ainsi une certaine simplicit´ tout en e e permettant un maximum de souplesse. Dans cette section.

e e e En r´sum´.17 est donc activ´e par les ´v´nements de e type login ayant un code de retour ´gal ` la constante BAD_PASSWORD. 09. facilitant ainsi. username :string. en particulier. e e l’op´rateur + doit ˆtre vu comme un quantificateur existentiel. 02. Le principal int´rˆt de cette fonctionnalit´ est de permettre une forme d’optiee e misation en d´sactivant des r`gles jug´es temporairement non pertinentes. et un message. P-BEST peut donc prendre des d´cisions ` propos de son propre fonctione e a nement. hostname = e. 11. On doit aussi s’assurer que la r`gle e e e e supprimant l’´v´nement ait la priorit´ la plus basse. le syst`me P-BEST permet de d´velopper des syst`mes experts dans e e e e e . on doit e e e s’assurer que l’´v´nement sera d´truit par au moins une des r`gles. 08. permettant ainsi ` certaines r`gles de laisser e e e a e des traces qui peuvent ˆtre utilis´es par d’autres r`gles. le langage fournit des op´rateurs permettant de e e marquer ou de d´marquer des ´v´nements. Chaque e e ´v´nement doit normalement ˆtre soigneusement effac´ de la base de connaissance afin e e e e d’´viter un engorgement de la m´moire utilis´e. Syst`mes de d´tection d’intrusions e e 37 01.username. 12. utilis´ e e e e e e ` la ligne 9.*) : [+e :event| event_type == login. par exemple. indiquant qu’une tentative de connexion a ´chou´ (ligne 10). Finalement. L’op´rateur -. Ceci permet d’´muler la notion de variable. 03.17 – Exemple de r`gle d’inf´rence dans P-BEST.hostname)] ] Fig. Il est aussi e e e possible. et l’op´rateur ==> s´pare la pr´misse des conclua e e e e e e sions. e e ea D’autres op´rateurs sont aussi disponibles dans le langage de P-BEST. celui-ci est d´truit (ligne 9) apr`s avoir cr´´ un nouvel ´v´nement e e e e ee e e de type bad_login (ligne 8). 04. Il permet de retirer des faits de la a a base de connaissances . la r`gle de la figure 1. A chaque fois que cet op´rateur est utilis´. 10. de modifier les champs de cere e tains faits. e e ` s’il n’est pas utilis´ correctement. e. 05. 06. ptype[event event_type :int. l’op´rateur ! permet de e e e faire un appel ` une routine externe. hostname :string] ptype[bad_login username :string. En conclusion. est affich´ ` l’aide de la fonction externe printf. Finalement. Lorsqu’un tel e a ´v´nement survient. e il existe des op´rateurs permettant d’activer ou de d´sactiver dynamiquement des r`gles e e e d’inf´rence. afin d’´viter que celui-ci ne soit e e e e supprim´ avant que toutes les r`gles en ayant besoin aient pu l’utiliser. permet justement d’effectuer cette tˆche.username. afin de simplifier l’´criture de certaines r`gles. il permet aussi de retirer des ´v´nements. 07.hostname] [-|e] [ !|printf("Bad login for user %s from host %s\n". e. 1.Chapitre 1. hostname :string] rule[Bad_Login(#10 . la e d´finition de compteurs. return_code == BAD_PASSWORD] ==> [+bad_login| username = e. Par exemple. return_code :int.

Finalement.4. mais cere e e tains aspects du langage et de l’impl´mentation d´passent le cadre des syst`mes experts e e e et demandent une connaissance des algorithmes utilis´s en arri`re-plan. e e e de mˆme que l’aide ` la prise de d´cision. e2 e1 |e2 e e1 ?e2 e1 &e2 Tab. mais l’impl´mentation sugg`re que le paradigme pur e e e des syst`mes experts semble n’ˆtre pas parfaitement adapt´ ` la tˆche. e e le chaˆ ınage avant force l’utilisateur ` s’assurer de donner les bons niveaux priorit´ aux a e diff´rentes r`gles. de marquage d’´v´nee e e e e e e ments. P-BEST e e nous convainc donc que les caract´ristiques principales d’un syst`me expert sont soue e haitables en d´tection d’intrusions. les notions de r`gles r´p´tables. Par e e a exemple. le langage de P-BEST e e n’est peut-ˆtre pas des plus appropri´s pour la gestion de flots d’´v´nements. 1. les fonctionnae e lit´s de base d’un syst`me expert. e e e un langage compil´ qui permet une interop´rabilit´ simple et efficace avec d’autres lane e e gages. soient l’accumulation et l’inf´rence de connaissance. Syst`mes de d´tection d’intrusions e e 38 e := a 0 e1 . LAMBDA n’est pas d´crit par ses auteurs comme un langage de sp´cification e e de syst`me expert. mais comporte tout de mˆme les trois caract´ristiques que nous e e e avons identifi´es comme ´tant d´sirables d’un syst`me expert. sont tout ` fait souhaitables en d´tection e a e a e d’intrusions et P-BEST les impl´mente tr`s bien.2 LAMBDA LAMBDA est un langage abstrait permettant de d´crire des sc´narios d’attaque sans e e e e se soucier des d´tails de d´tection. En effet. De plus.4 – Syntaxe du calcul d’´v´nements utilis´ dans LAMBDA. il comporte des primitives sp´cialement reli´es ` ce domaine. Par exemple. il permet de d´finir un sc´nario d’attaque de deux points de vue diff´rents : e e e . e e ea a 1. Cependant. soient l’accumulation e e e e et l’inf´rence de connaissance. ce qui complique (inutilement) la e e r´daction de r`gles. la suppression des ´v´nements qu’il n’est plus n´cessaire de e e e e e conserver en m´moire doit ˆtre faite explicitement. de mˆme que la possibilit´ de prendre des d´cisions et e e e e de r´agir automatiquement. D’un point de vue abstrait. comme LAMBDA est sp´cialement con¸u pour la e e c description d’attaques. et par cons´quent d’autres syst`mes. De plus.Chapitre 1. e e e e l’association fait-´v´nement respecte bien le paradigme des syst`mes experts. et repose sur l’hypoth`se que d’autres outils d’audit (dont e e e des syst`mes de d´tection d’intrusions) fournissent un flux d’´v´nements bas niveau ` e e e e a analyser. et d’activation/d´sactivation de r`gles donnent ` P-BEST des possibilit´s prae e a e tiquement algorithmiques qui d´passent le cadre strict des syst`mes experts. La description qui en est donn´e dans [29] est d´tach´e e e e des d´tails d’impl´mentation.

soit le choix non-d´terministe d’´v´nements (e1 ?e2 ). . t2 ]. arg2 .) pre : φpre post : φpost scenario : s where : ψs detection : d where : ψd verification : v where : ψv o` φi est une formule de la logique du deuxi`me ordre u e ψi est une formule de la logique du premier ordre e e i est une formule du calcul des ´v´nements Tab.5. Un ´v´nement peut e e ˆtre soit un ´v´nement primitif (a). 1. soit l’ex´cution parall`le de deux ´v´nements (e1 |e2 ). soit l’´v´nement nul (0). on utilise le e e e e e e a e e calcul d’´v´nements [30]. l’intervalle e e e e a est [t. soit une s´quence d’´v´e e e e e e e e nements (e1 . par exemple. Finalement.4. on utilise la logique du deuxi`me e e ordre. Syst`mes de d´tection d’intrusions e e 39 attack attack name(arg1 . la e e e connaissance de l’attaquant : le pr´dicat knows(A. combin´e au choix non-d´terministe. pour exprimer les contraintes autres que l’ordonnancement devant ˆtre respect´es par les diff´rents ´v´nements du sc´nario. d´pendamment du point de vue auquel on e e se place. on utilise simplement la e e e e e e logique du premier ordre. Pour les ´v´nements ponctuels survenant ` l’instant t. t]. Il est ` noter que l’´v´nee e e a e e ment primitif a est d´fini sur un intervalle de temps [t1 . e celui de l’attaquant et celui du syst`me de d´tection. Bien que les deux points de vue e e soient en g´n´ral tr`s semblables. .Chapitre 1. e e e e e def permet de repr´senter un ´v´nement facultatif [e] = e ? 0. L’action nulle. Pour repr´senter la connaissance acquise. Par exemple. φ) exprime le fait que l’attaquant e A acquiert la connaissance φ. e a Le langage LAMBDA offre une solution hybride pour exprimer les sc´narios d’ate taque. et non comme ´tant un e e ´v´nement ponctuel. il e e e e peut s’agir de certains calculs effectu´s ` l’interne. soit l’absence e e e e d’´v´nements (e). e e a . La syntaxe d’un sc´nario d’attaque exprim´ en LAMBDA se trouve ` la table 1. On utilise des pr´dicats du deuxi`me ordre pour mod´liser. dont la syntaxe est donn´e ` la table 1. et repose sur trois langages diff´rents. Pour repr´senter les contraintes d’ordonnancement dee vant ˆtre respect´es par les diff´rentes ´tapes d’un sc´nario d’attaque. e2 ). il arrive cependant que certaines actions effectu´es e e e e par l’attaquant puissent ne pas ˆtre d´tectables par le syst`me attaqu´.5 – Syntaxe d’un sc´nario d’attaque LAMBDA. . soit l’ex´cution e e e e e e synchronis´e d’´v´nements (e1 &e2 ).

et d’autre part de d´couvrir des e e e c e sc´narios d’attaques insoup¸onn´s.Printer) Pre : printer(Printer).Printer. La clause post exprime l’´tat du syst`me une fois que e e e l’ex´cution du sc´nario a r´ussi. e e e e a Le lien avec la base de connaissances se fait via les clauses pre et post. e Les notions de post et de pre-conditions permettent. blocked(Printer). Les auteurs parlent aussi a d’ajouter une clause reaction.18. dans la litt´rature.Printer)) Action block(Agent.File) Pre : not(file(Link)) Post : linked(Link. Il a lance alors la commande d’impression du fichier cr´´ (3). La clause verification. d’exemple de sc´nario d’attaque exe e e prim´ avec LAMBDA utilisant le calcul des ´v´nements. not(queued(Link. Premi`rement (1). 1. permettant d’indiquer comment r´agir ` l’attaque pour e a se prot´ger.Printer). physical access(Agent. authorized(Agent.Printer) Post : not(blocked(Printer)) Action get-file(Agent.File) Pre : owner(Agent. physical access(Agent.File) Pre : printed(Printer. par exemple en retirant le bac de papier. et comme il a les droits d’acc`s ee e .File) Action print-process(Printer. not(blocked(Printer)) Post : printed(Printer. owner(Agent.File) Pre : printer(Printer). l’attaquant cr´e e e e e e un fichier auquel il aura alors les droits d’acc`s.Link) Pre : queued(Link. que des actions simples.18 – Mod´lisation du sc´nario d’acc`s ill´gal ` un fichier avec LAMBDA. Deux sc´narios sont corr´l´s si e e e e ee les post-conditions de l’un correspondent aux pre-conditions de l’autre.File). Cette notion de corr´lation permet d’une part de factoriser les sc´narios d’attaques lorsqu’un objectif e e interm´diaire peut ˆtre atteint de diff´rentes fa¸ons.File). e c e Nous n’avons pas trouv´.File) Action lpr-s(Agent. l’attaquant ayant un acc`s e e physique ` une imprimante bloque celle-ci. entre autres. e quand ` elle. File) Post : not(file(File)) Action unblock(Agent. Ensuite (2).Printer) Post : blocked(Printer) Action remove(Agent. Les clauses scenario et detection donnent les d´tails e e e e de l’attaque du point de vue de l’attaquant et de l’attaqu´. file(File).File) Pre : true Post : file(File). dans la partie scenario. en plus de valider l’occurrence d’attaques. physical access(Agent.File). indique comment valider l’effet de l’attaque. C’est le cas.File) Fig. Ce sc´nario se d´roule en huit ´tapes. de corr´ler les diff´rents sc´narios entre eux. Tous les exemples sur lesquels e e e nous avons pu mettre la main n’utilisaient.Printer) Pre : printer(Printer).Printer) Action ln-s(Agent.Printer) Post : read access(Agent. La clause pre exprime les conditions devant ˆtre satisfaites par le syst`me avant l’ex´cution du sc´nario e e e e afin que celui-ci puisse r´ussir.read. linked(Link. du sc´nario d’acc`s ill´gal ` un fichier. Syst`mes de d´tection d’intrusions e e 40 Action touch(Agent.Link.Chapitre 1.File) Post : queued(File. Finalement. pr´sent´ ` la e e e a e ea figure 1. les clauses where donnent les relations entre les diverses ´tapes e e des sc´narios.

De plus. e e ee e e a LogWeaver utilise une logique temporelle future du premier ordre. et Chronicles. Aussi. e e e de mˆme qu’un support ` la d´cision. LAMBDA est un langage qui offre les mˆmes avantages qu’un parae e e digme bas´ sur un syst`me expert : soient l’accumulation et l’inf´rence d’information. les algorithmes e e utilis´s ont ´t´ con¸us de fa¸on ` pouvoir travailler en ligne (online). donnant ainsi acc`s ` l’attaquant au fichier auquel il n’avait pas e a droit (8).Chapitre 1. e sont ceux qui se rapprochent le plus de ceux que nous avons effectu´s de par le fait que e les langages de sp´cification utilis´s ont ´t´ d´velopp´s ` partir de logiques temporelles. Grossi`rement. Monid. Syst`mes de d´tection d’intrusions e e 41 pour ce fichier. et la ee e cr´ation d’un lien logique vers le fichier cible ayant le mˆme nom que le fichier supprim´ e e e (5). Il ne reste ensuite qu’` d´bloquer l’imprimante (6). car l’imprimante est bloqu´e. la commande est plac´e dans la file d’impression. e e . offline. Des aspects int´ressants de LAMBDA sont la s´paration du e e e point de vue de l’attaquant et du point de vue de l’attaqu´. dans la litt´rature anglaise. l’approche hybride utilisant le calcul e a e d’´v´nements permet d’exprimer des sc´narios d’attaque selon une syntaxe claire et e e e concise qui semble au moins aussi satisfaisante sinon plus que celles employ´es avec e les syst`mes de transition. Les prochaines ´tapes sont la e e e suppression du fichier pour lequel une commande d’impression a ´t´ lanc´e (4). En r´sum´. pour que l’impression du fichier a e puisse avoir lieu (7). Un tel algorithme est appel´. L’impression ne peut e avoir lieu imm´diatement. e ee c c a e un algorithme est dit en ligne s’il peut traiter s´quentiellement sur un fichier d’audit e ` partir du d´but sans avoir ` m´moriser tout le fichier. alors que Monid utilise une logique temporelle pass´e et future du premier ordre avec points fixes nomm´e e e Eagle et que Chronicles se base sur une logique r´ifi´e. e 1. LogWeaver. la description logique des effets et des pr´misses d’une e e e attaque permet de faire un calcul de sc´nario d’attaque afin d’´laborer de nouveaux e e sc´narios. de mˆme que les notions de e e v´rification et de r´action.5 Logiques temporelles Les trois derniers travaux que nous pr´sentons. o` le traitement s’effectue ` partir de la fin e du fichier. Dans les trois cas. Un exemple d’algorithme qui a e a e u a n’est pas en ligne est celui d´crit dans [31].

5. il s’agit d’un sous-ensemble de LTL. A premi`re vue. ´ Etant donn´ une trace σ et une formule F . action="creat". car elle est plus proche de e e celles que nous avons d´j` vues et elle nous permet de voir comment on peut effectuer ea de la v´rification sur une logique du premier ordre. Ce patron filtre tous les ´v´nements dont la valeur du champ id est ´gale ` celle de la variable X. ces derniers ne se r´v`lent pas d’une grande e ee e e utilit´ pour la d´tection d’intrusions. e Le mod`le sur lequel travaille LogWeaver est une s´quence finie ou infinie d’enree e gistrements. lesquelles e e sont consid´r´es comme ´tant des chaˆ ee e ınes de caract`res.1 LogWeaver L’article sur LogWeaver [32] est divis´ en deux parties. Un enregistrement est d´fini comme e e ´tant une fonction d’un ensemble d’´tiquettes vers un ensemble de valeurs.1. Nous focuserons ici sur la premi`re logique. ρ).Chapitre 1.6 – Syntaxe de la premi`re logique de LogWeaver. l’ensemble des ´l´ments satisfaisant F e ee est alors d´fini non-pas seulement comme ´tant un sous-ensemble d’enregistrements de e e σ. Le seul op´rateur temporel ayant ´t´ conserv´ est e e e ee e donc l’op´rateur . e 1. e La syntaxe des formules utilis´es dans la premi`re logique abord´e est pr´sent´e ` la e e e e e a ` table 1. Ils montrent ensuite les faiblesses de e cette logique et en proposent une autre moins orthodoxe. mais qu’ils consid`rent comme e plus appropri´e. signifiant n´cessairement. Un environnement est une fonction attribuant des valeurs aux . Les op´rateurs U (jusqu’` ce que) et e a e a (imm´diatement e apr`s) ont ´t´ omis car.1. Premi`rement. object="/usr/spool/mail/root$"}. aussi appel´es patrons d’´v´nements. o` s est un enregistrement de σ et ρ u est un environnement. Syst`mes de d´tection d’intrusions e e 42 F ::= A | ¬F | F1 ∧ F2 | F1 ∨ F2 | F Tab. appel´ indistinctement log. selon les auteurs. les auteurs e e montrent comment on peut utiliser une logique temporelle classique pour effectuer de la d´tection d’intrusions sur des fichiers d’audits. La principale diff´rence entre cette logique et LTL se trouve au e niveau du type de la relation de satisfaction et de la s´mantique attribu´e aux formules e e atomiques A. ou trace. que nous ´tudierons plus e e en d´tails ` la section 2. Un exemple de patron d’´v´nements e e e e e est {id=X. 1. Il est ` noter que l’op´rateur utilis´ ici e e a e e exprime un futur strict. mais comme un ensemble de couples (s.6. et e e e a dont les valeurs des champs action et object sont respectivement ´gales ` "creat" et e a "/usr/spool/mail/root$".

Ces deux familles de formules. la pr´sence de n´gations est jug´e e e e e comme ´tant superflue dans la plupart des cas. Elle est trop expressive car elle permet e a la combinaison bool´enne de formules de la forme F . En plus de manipuler ces ensembles. . Les propri´t´s de parit´ sont celles o` une action peut e ee e u annuler temporairement l’effet d’une autre. De plus. Elle a c a e n’est pas suffisamment expressive car elle ne permet pas de sp´cifier naturellement des e propri´t´s de comptage (autrement qu’en ´crivant des formules de la forme F ∧ (F ∧ ee e (F ∧ . Pour v´rifier une formule F . soit ` ajouter des formules dans l’ensemble N xt (dans le a cas des formules de la forme F ). Ce traitement peut soit amener ` a ajouter d’autres formules dans l’ensemble Cur (dans le cas de formules de la forme F1 ∧ F2 . signifiant que formule F sera satisfaite dans le futur si et seulement si elle sera satisfaite ` l’´tat suivant ou si. ∧ F ))). comme dans le cas de l’ouverture et de la fermeture d’une session TCP. F1 ∨ F2 . e contribuent chacune ` leur fa¸on ` la complication de l’algorithme de v´rification. . L’algorithme de v´rification utilis´ pour cette logique est semblable ` celui utilis´ e e a e pour RUSSEL (section 1. ou ¬F ). La premi`re e e a e e cat´gorie de probl`mes concerne le traitement des ´v´nements r´p´t´s. Ensuite. e e e eeea Les probl`mes reli´s ` cette logique se divisent en deux cat´gories. qui est e e e e jug´e ` la fois trop et pas assez expressive. La deuxi`me cat´gorie de probl`mes concerne l’expressivit´ de la logique.1). C’est exactement e e cette notion d’environnement qui justifie l’emploi d’une logique du premier ordre. a a on traite chacune des formules de l’ensemble Cur. l’ensemble Cmp n’ayant aucun sens ici. Ce sont les environnements qui permettent de relier les divers enregistrements entre eux en unifiant les valeurs de certains de leurs champs. . il faut aussi ajouter les structures de donn´es n´cessaires au chaˆ e e ınage des formules et ` la manipulation des a environnements. pour chaque enregistrement. Ceci est du au fait que la reconnaissance d’une suite de n ´v´e e m nements sur une trace en contenant m lance (n ) alarmes. qui sont jug´es par les auteurs e e comme ´tant rarement utiles en pratique. alors qu’en fait une seule pourrait suffire. elle a e a e sera satisfaite dans le futur. Il est ` noter que dans le dernier cas.Chapitre 1. En plus de ralentir e e e e consid´rablement l’algorithme de v´rification en augmentant rapidement et de fa¸on e e c d´mesur´e le nombre de formules ` v´rifier.2. On travaille cependant avec deux ensembles plutˆt que o trois. ni de parit´. de plus. le nombre d’alarmes lanc´es est lui aussi e e a e e beaucoup trop grand. on initialise e donc l’ensemble Cur ` {F } et l’ensemble N xt ` ∅. c’est-`-dire la e e e e e ee a reconnaissance d’un nombre d´termin´ d’´v´nements semblables. Syst`mes de d´tection d’intrusions e e 43 variables se trouvant dans les patrons d’´v´nements d’une formule. ` partir de l’´tat suivant. on utilise a l’´quivalence F ⇔ F ∨ e F . Le lecteur int´ress´ aux d´tails de cet algorithme est r´f´r´ ` [32].

Chapitre 1. Syst`mes de d´tection d’intrusions e e

44

Pour r´soudre ces probl`mes, les auteurs sugg`rent d’utiliser une autre logique, moins e e e classique, inspir´e de ETL [33]. Nous ne nous ´tendrons pas ici sur les d´tails de ETL, e e e mais nous nous contenterons de dire que cette derni`re a la particularit´ d’offrir la e e possibilit´ d’inclure des automates dans la d´finition des formules. Une partie de la e e s´mantique des formules est donc d´finie par la notion d’acceptation d’une chaˆ par e e ıne un automate. Cette solution hybride pr´sente des avantages au niveau de l’expressie vit´, mais les sp´cifications obtenues, comme le remarquent les auteurs, commencent ` e e a ressembler ´trangement ` celles de STATL. e a En r´sum´, le travail de M. Roger et J. Goubault-Larrecq est une mine d’or d’un e e point de vue th´orique. L’article [32] comportent plusieurs r´sultats th´oriques qui n’ont e e e pas ´t´ cit´s ici, mais qui sont tout de mˆme tr`s int´ressants. De plus, il repr´sente un ee e e e e e cas complet d’´tude d’utilisation d’une logique temporelle classique du premier ordre e pour r´soudre un probl`me de v´rification en ligne. Les algorithmes utilis´s sont pr´e e e e e sent´s en d´tails et les r´sultats obtenus sont comment´s avec objectivit´. Plusieurs e e e e e probl`mes importants reli´s ` l’utilisation d’une logique classique ont ´t´ relev´s, et une e e a ee e solution int´ressante a ´t´ propos´e pour r´soudre ces probl`mes. Cependant, comme e ee e e e nous l’avons d´j` remarqu´, cette solution nous fait tendre tranquillement vers un lanea e gage ` tendance imp´rative. a e

1.5.2

Monid

Le syst`me de v´rification en ligne Monid se pr´sente comme ´tant une alternative e e e e ` LogWeaver. Ce syst`me utilise une logique temporelle du premier ordre pass´e et a e e future avec points fixes nomm´e Eagle [34, 35]. Les auteurs affirment que Eagle est plus e expressive que le fragment de LTL utilis´ par les auteurs de LogWeaver en ce qu’elle e permet d’exprimer des contraintes temps-r´el et des propri´t´s statistiques. e ee La syntaxe des sp´cifications Eagle se trouve ` la table 1.7. Il s’agit d’une syntaxe e a plutˆt concr`te, puisqu’on y sp´cifie plus que la syntaxe des formules. Une sp´cification o e e e S consiste en une partie de d´clarations D et une partie o` on d´finit des observateurs O. e u e D est constitu´ de z´ro ou plus d´finitions de r`gles R, et O de z´ro ou plus moniteurs M . e e e e e Les r`gles et les moniteurs sont nomm´s N . Le nommage des r`gles permet la d´finition e e e e de r`gles r´cursives. Le domaine lexical T repr´sente les types, qui sont utilis´s lors de e e e e la d´finition des r`gles. Finalement, xi repr´sente une variable, et exp est une expression e e e qui s’´value soit ` vrai soit ` faux ` chacun des ´tats de la trace. e a a a e Les op´rateurs , , d´signent respectivement l’´v´nement suivant et l’´v´nement e e e e e e pr´c´dent, alors que les op´rateurs de points fixes min et max permettent de d´finir des e e e e

Chapitre 1. Syst`mes de d´tection d’intrusions e e

45

S D O R M T F

::= ::= ::= ::= ::= ::= ::=

DO R∗ M∗ {max|min} N (T1 x1 , . . . , Tn xn ) = F mon N = F Form | primitive type exp | true | false | ¬F | F1 ∧ F2 | F1 ∨ F2 | F1 → F2 | F | F | F1 · F2 | N (F1 , . . . , Fn ) | xi Tab. 1.7 – Syntaxe des sp´cifications Eagle. e

max Always(Form F) = F ∧ Always(F) min EvTimedLogout(string k, double t, double δ) = (time - t ≤ δ) ∧ ((action = logout ∧ userid = k) ∨ EvTimedLogout(k,t,δ)) mon M = Always(action = login → EvTimedLogout(userid,time,100))

Fig. 1.19 – Exemple de sp´cification Eagle. e formules r´cursivement. L’op´rateur de concat´nation · permet de d´finir des s´quences e e e e e d’´v´nements. Notons aussi que bien que Eagle utilise des variables dans la d´finition de e e e ses formules, aucune notion d’environnement n’est utilis´e pour d´finir la s´mantique. e e e On utilise cependant une notion de substitution textuelle pour d´finir la s´mantique e e des formules param´tr´es N (F1 , . . . , Fn ). e e ` A la figure 1.19, se trouve un exemple de sp´cification Eagle. Comme d’habitude, on e peut d´finir l’op´rateur Always, souvent not´ 2, ` l’aide de l’op´rateur de plus grand e e e a e point fixe et de l’op´rateur . La d´finition de la r`gle EvTimedLogout montre comment e e e on peut sp´cifier qu’un ´v´nement doit survenir au plus δ unit´s de temps apr`s un autre. e e e e e On proc`de exactement de la mˆme fa¸on que lorsque l’on d´finit l’op´rateur ` l’aide e e c e e a des op´rateurs de plus petit point fixe et , sauf que l’on exige en plus que les temps e associ´s aux deux ´v´nements ne soient pas s´par´s de plus de δ unit´s de temps. Aucun e e e e e e caract`re sp´cial n’est donc donn´ au temps dans Eagle. e e e L’algorithme de v´rification utilis´ par Eagle Flier, le logiciel implantant Eagle, e e fonctionne ` l’aide d’une fonction eval qui, ´tant donn´ une formule F et un ´tat σ(i), a e e e ` donne une nouvelle formule F telle que σ, i |= F si et seulement si σ, i + 1 |= F . A

Chapitre 1. Syst`mes de d´tection d’intrusions e e

46

la fin de la trace, on calcule une fonction bool´enne value(F ) qui s’´value ` vrai si et e e a seulement si le dernier ´tat de σ satisfait F . Donc, pour une trace σ de longueur n et une e formule F , on a σ, 1 |= F ssi value(eval(. . . eval(eval(F, σ(1)), σ(2)) . . . , σ(n))) = vrai. On remarque ici une diff´rence importante entre les hypoth`ses faites sur le mod`le e e e utilis´ par LogWeaver et celui de Eagle : les traces v´rifi´es par Eagle sont de longueur e e e finie, alors que celles sur lesquelles travaille LogWeaver sont d´finies comme ´tant finies e e ou infinies. Il est ` noter que cette diff´rence reste tout de mˆme tr`s mince car, d’une a e e e part, les r´sultats th´oriques sur l’algorithme employ´ par LogWeaver demandent une e e e e e trace finie, et d’autre part, les auteurs de [35] citent une m´thode, appel´e specifyingbad prefixes [36], permettant d’exprimer la formule ` v´rifier de telle sorte que celle-ci a e devient tˆt ou tard vraie ou fausse, peu importe le reste de la trace. L’int´rˆt de cette o ee technique r´side dans le fait qu’elle ´vite d’avoir ` v´rifier la satisfiabilit´ ´ventuelle e e a e e e d’une formule, probl`me qui est ind´cidable dans le cas de Eagle dˆ ` l’utilisation de e e ua pr´dicats du premier ordre. e En r´sum´, les travaux effectu´s dans le cadre du d´veloppement de Eagle sont plus e e e e pr`s de la pratique que ceux effectu´s pour LogWeaver. Les propri´t´s int´ressantes pour e e ee e la d´tection d’intrusions telles que le comptage ou les propri´t´s de parit´ s’expriment e ee e beaucoup plus naturellement dans Eagle que dans le sous-ensemble de LTL consid´r´ ee par les auteurs de LogWeaver ou encore la seconde logique propos´e, inspir´e de ETL. e e Les algorithmes de v´rification utilis´s par Eagle sont simples, mais semblent mieux e e adapt´s au cas o` la trace d’´v´nements consid´r´e est de longueur finie. Finalement, e u e e ee e e on trouve dans [35] toute une s´rie d’exemples de sc´narios d’attaque allant des plus classiques ` d’autres plus originaux pouvant s’exprimer dans Eagle. a

1.5.3

Chronicles

Les deux syst`mes que nous venons de pr´senter ont ´t´ construits sur des parae e ee digmes provenant de la th´orie de la v´rification formelle de mod`les. Ils utilisent des e e e logiques qui ont ´t´ historiquement d´velopp´es dans l’intention de v´rifier automatiee e e e quement certaines propri´t´s de programmes. La v´rification par ´valuation de mod`le ee e e e Model Checking en informatique peut ˆtre utile ` plusieurs phases du d´veloppement, e a e tant ` la conception (v´rification d’algorithmes), ` la programmation (v´rification de a e a e code), qu’` la phase de tests (validation de logiciels). Le syst`me Eagle, en particulier, a a e d’abord ´t´ d´velopp´ pour ce type d’usage. L’avantage d’utiliser une logique commune ee e e dans un tel cadre d’utilisation est qu’` chaque phase du processus de d´veloppement, a e on peut v´rifier ` nouveau les mˆmes propri´t´s avec un minimum d’ajustement. La e a e ee v´rification par ´valuation de mod`le est tr`s bien adapt´ aux probl`mes bool´ens : e e e e e e e

La nature des probl`mes abord´s est beaucoup plus vaste. ceux-ci e u e e e ´tant indistinctibles les uns des autres. a1 . Finalement. Informellement. les chroniques sont reli´es au calcul des ´v´nements pr´sent´ e e e e e e plus haut. e e e Chronicles. o` P est le nom de l’attribut. etc. En d´tection d’intrusions. On sera int´ress´ au nombre de battements dans e e e une minute. on o e e e e e pourra ˆtre int´ress´ ` analyser les battements cardiaques d’un ˆtre humain. Les probl`mes du genre : dans ee e quelle mesure cette propri´t´ est-elle satisfaite ? ou encore quelles sont toutes les fa¸ons ee c dont cette propri´t´ est viol´e ? pr´sentent peu d’int´rˆt dans ce domaine et c’est sans ee e e ee doute pourquoi les tentatives d’y appliquer les logiques y ayant ´t´ d´velopp´es peuvent ee e e parfois sembler artificielles et tordues. . ceux-ci sont fusionn´s en un seul ´v´nement. Par exemple. . Un attribut du domaine est e un tuple P (a1 . La repr´sentation du temps dans Chronicles est discr`te et il est donc vu comme une e e suite ordonn´e d’instants dont la r´solution est assez fine pour les besoins de l’analyse. . le besoin de logiques o` le comptage et les intervalles u de temps sont ´lev´s au rang de primitives du langage se fait bien sentir. Ces derniers sont appel´s e messages. les probl`mes auxquels on s’attaque sont traditionnellee ment diff´rents. ` l’acc´l´ration du rythme. En intelligence artificielle. aux moments o` de l´g`res anomalies semblent a ee u e e survenir. les ´v´nements correspondent ` des changements de valeurs des e e a attributs du domaine. Dans un tel contexte. . oui ou non. Ici. . Dans la litt´rature. . mais lorsque deux ou e e e e plusieurs ´v´nements identiques surviennent au mˆme instant (selon la r´solution choie e e e sie). telle propri´t´ est satisfaite ?. et souvent e e e plutˆt ´loign´e de ceux g´n´ralement rencontr´s par un informaticien. Il vient avec CRS (Chroıtre e e nicles Recognition System) un v´rificateur qui peut fonctionner en ligne. introduit dans [37]. e une chronique est un ensemble d’´v´nements reli´s entre eux par des contraintes tempoe e e relles. Syst`mes de d´tection d’intrusions e e 47 est-ce que. e e Deux ´v´nements diff´rents peuvent survenir au mˆme instant.Chapitre 1. . et c’est dans e e un tel contexte que les logiques r´ifi´es ont ´t´ d´velopp´es. Les logiques r´ifi´es sont des e e ee e e e e logiques du deuxi`me ordre o` les pr´dicats du deuxi`me ordre servent essentiellement e u e e ` exprimer les instants ou les intervalles de temps o` les faits exprim´s par les pr´dicats a u e e du premier ordre sont vrais. e e L’environnement est d´crit par les attributs du domaine. et v u sa valeur. le choix de la r´solution doit e e e donc ˆtre fait avec pr´cautions. on a e e ea e un exemple int´ressant o` tout ce qui compte est la fr´quence des ´v´nements. . est un langage bas´ sur les logiques r´ifi´es permettant de reconnaˆ des chroniques dans un flot d’´v´nements. o` plusieurs e e e e u ´v´nements identiques peuvent survenir en peu de temps. Certains attributs peuvent ne pas avoir de valeur. an ses arguments. an ) : v. .

5.t3) . A ea e e ee . t) signifie que le message P est survenu ` l’instant t.t1) . (t1 . t2 [. t2[.20. 6. t3-t2 <= 4 8. t) event(P . Syst`mes de d´tection d’intrusions e e 48 hold(P : v. chronicle exemple1 { 2. v2 ). de plus. (t1 . Il sera reconnu ` e e ea chaque fois que les messages e1 . event(e3. iii) un ensemble de patrons d’´v´nements qui repr´sentent les changements de l’environnement auxquels on e e e s’int´resse iv) un ensemble d’assertions qui repr´sentent le contexte dans lequel les ´v´e e e e nements surviennent.8.20 – Exemple de chronique. (t1 . v2 ). event(e1. Il signifie que sur l’intervalle [t1 . e e ee ii) un ensemble de contraintes temporelles sur ces instants. Au d´but. Finalement.8 – Pr´dicats de r´ification de Chronicles. (t1 . t2 )) event(P : (v1 . P . t2 [. (t1 . P . } Fig. e e L’algorithme de reconnaissance des chroniques fonctionne de fa¸on semblable ` c a ` chaque fois d’autres que nous avons d´j` vus. event(e2. et v) un ensemble d’actions externes ` prendre lorsqu’une instance a de chronique est reconnue. t2 )) e permet de compter. t2 )) occurs((n1 . le message e3 ne doit pas survenir plus de 4 unit´s de temps apr`s e2 . Les pr´dicats de r´ification de Chronicles sont pr´sent´s ` la table 1. a Un exemple de mod`le de chronique est pr´sent´ ` la figure 1. n2 ). 1. 3. t) signifie que l’attribut P a pass´ de la valeur v1 ` v2 ` e e a a l’instant t. t) noevent(P .t2) . a Un mod`le de chronique est constitu´ de cinq ´l´ments : i) un ensemble d’instants. t2 )) Tab. n2 ). Le pr´dicat event(P : (v1 . Le e a pr´dicat noevent(P . 4. t2 )) signifie qu’aucun changement de valeur de l’attribut P n’est e survenu durant l’intervalle [t1 . l’´v´nement P est survenu de e e n1 ` n2 fois. un mod`le vide est cr´´. t2 )) signifie que l’attribut P conserve la valeur v sur l’intervalle [t1 . t1<t2<t3 7. le pr´dicat occurs((n1 . e e 1. Le pr´dicat event(P . (t1 . Le pr´dicat e e e e a e hold(P : v. 1. e2 et e3 surviendront dans cet ordre et que.Chapitre 1.

e e l’utilisation propos´e par les auteurs tend vers d’autres objectifs. on a finalement sugg´r´ une fa¸on de l’utiliser en d´tection d’intrusions. Chronicles peut fusionner ces diff´rents ´v´nements en un seul. Syst`mes de d´tection d’intrusions e e 49 qu’un ´v´nement satisfaisant les contraintes exprim´es par un mod`le de chronique sure e e e vient. Il a par la suite ´t´ appliqu´ ` d’autres domaines tels que l’anaee ee ea lyse de circulation routi`re et on lui a mˆme trouv´ quelques applications en m´decine. e e e L’utilisation de Chronicles peut permettre une d´tection plus pr´cise. Certaines attaques. A e ee ea e de t´l´communications. mais ne doit tout a de mˆme pas d´clencher d’alarme. et particuli`rement dans un mode de e fonctionnement en ligne. qui peut alors ˆtre utilis´ soit par e e e e e une autre chronique en cours de reconnaissance. a e e Chronicles n’a pas ´t´ con¸u sp´cialement en vue de faire de la d´tection d’intruee c e e ` ses d´buts. ils e proposent d’utiliser Chronicles comme outil d’analyse des journaux d’alarmes de syst`mes de d´tection d’intrusions afin i) de permettre une d´tection plus pr´cise. faire exploser celle-ci. celui-ci est ajout´ ` l’instance de chronique en cours apr`s duplication de cette ea e derni`re. Principalement. il a ´t´ appliqu´ ` l’analyse de journaux d’alarmes d’´quipements sions. telles que e la propagation de vers informatiques. celle-ci pouvant ˆtre repr´sent´e par certains attributs du domaine dont e e e les valeurs sont tenues ` jour par le m´canisme mˆme de reconnaissance de chroniques. soit par d’autres instances de la mˆme e chronique. Cette fonctionnalit´ donne ` Chronicles une certaine forme d’acquisition de e a connaissance. et peuvent d´clencher un nombre abrutissant et inutilee ment ´lev´ d’alarmes. e e Un aspect important de Chronicles est que l’action ` prendre lors de la reconnaisa sance d’une chronique n’est pas n´cessairement une simple action d’archivage externe. lors de la sp´cification de chroniques. elle peut aider ` diminuer le nombre de faux-positifs en invalidant certaines e a alarmes. e e Il est important. Plus pr´cie e e s´ment. Bien qu’il soit possible d’utiliser Chronicles pour repr´senter des sc´narios d’attaque. e e e e e . Autrement. Certaines instances en cours de reconnaissance peuvent ˆtre ´limin´es lorsque des ase e e sertions sont viol´es ou que les contraintes temporelles ne peuvent plus ˆtre satisfaites. Par exemple. ii) de e e e e r´duire le nombre d’alarmes et iii) d’am´liorer la s´mantique des alarmes.Chapitre 1. L’utilisation de Chronicles peut r´duire le nombre e e e d’alarmes. de s’assurer de sp´cifier de telles e e assertions ou contraintes temporelles. se caract´risent par la r´p´tition ` outrance de e e e a comportements identiques. e e e e ee c e Dans [38]. l’initialisation d’une vid´o-conf´rence entre plusieurs utilisae e teurs peut sous certains aspects ressembler ` un balayage de ports. Il e peut aussi s’agir de l’´mission d’un nouvel ´v´nement. L’invalidation d’alarmes avec Chronicles peut se faire en sp´cifiant certains e contextes dans lesquels certains comportement ne doivent pas ˆtre consid´r´s comme e ee dangereux. certaines instances peuvent rester ind´finiment en m´moire et e e mˆme. principalement en utilisant le pr´dicat occurs. La duplication sert ` s’assurer de reconnaˆ e a ıtre toutes les instances possible. ´ventuellement.

voire mˆme causale. mais aussi toute sa configuration. e En r´sum´. d´signant e o e e e par exemples diff´rentes alarmes symptomatiques d’un mˆme ph´nom`ne. Les premiers utilisent le mot corr´lation dans un sens plutˆt g´n´ral. Syst`mes de d´tection d’intrusions e e 50 Chronicles peut am´liorer la s´mantique des alarmes en combinant les diff´rents sympe e e tˆmes d’une mˆme attaque. done e a nant ainsi l’impression que de nombreuses attaques ont eu lieu alors qu’il s’agit en fait d’une seule. L’utilisation d’un tel mod`le e e a e permet. La notion de corr´lation d’alarmes employ´e par e e e e e e e e les auteurs de [38] est cependant l´g`rement diff´rente de celle utilis´e par les auteurs de [29]. en plus de donner plusieurs exemples o` Chronicles peut s’av´rer utile dans l’analyse de journaux d’alarme. La fa¸on dont les alarmes e e c sont repr´sent´es dans M2D2 sont de plus compatibles avec IDWG [39]. Chronicles est un langage de surveillance bas´ sur une logique r´ifi´e e e e e e dont la s´mantique semble mieux adapt´e ` la d´tection d’intrusions que les logiques e e a e traditionnellement utilis´es en Model Checking. de tenir compte dans l’analyse e e des caract´ristiques du syst`me attaqu´ et mˆme du syst`me de d´tection d’intrusions e e e e e e ayant signal´ l’attaque.Chapitre 1. et bien encore. montrent comment ce langage peut ˆtre e utilis´ de paire avec M2D2 [10] pour corr´ler les alarmes avec le contexte. Mieux encore. M2D2 est un e e mod`le formel incluant celui de NetSTAT [20]. des travaux ayant ´t´ effectu´s tendent ` d´montrer que Chronicles peut ee e a e s’av´rer utile en corr´lation d’alarmes. L’ordonnancement des diff´rents ´v´e e e e nements est exprim´ par un ensemble de contraintes sur les instants leur ´tant associ´s e e e plutˆt que par des op´rateurs d´di´s. un format e e d’´change d’alarmes standardis´ mis au point ` l’IETF. les logiciels install´s e e sur chacune des machines. alors que les e e e e deuxi`mes parlent plutˆt d’une corr´lation logique. Chronicles a de plus ´t´ c e e e ee utilis´ dans de nombreux domaines d’application ` premi`re vue assez diff´rents les uns e a e e des autres. Un des dangers reli´s ` l’utilisation de Chronicles est l’explosion de l’utilie a sation de la m´moire lorsque les chroniques ne sont pas sp´cifi´es consciencieusement. u e Les auteurs de [38]. Il permet de repr´senter non-seulement e e la topologie physique du r´seau. L’utilisation de Chronicles permet de ne d´clencher qu’une seule alarme e rendant ainsi mieux compte du fait qu’une seule attaque a eu lieu. Un des ces op´rateurs permet mˆme de compter e e de fa¸on tr`s naturelle le nombre d’´v´nements semblables. les e e e logiciels de s´curit´ install´s sur chacune des composantes. Certains e e e ee e syst`mes de d´tection d’intrusions lanceront des alarmes ` chacune de ces actions. Le v´rificateur e o e e e de chroniques CRS permet de g´n´rer des ´v´nements en cours d’ex´cution. les vuln´rabilit´s de ceux-ci de mˆme que leurs effets. les attaques d´tectables par e e e e chacun des syst`mes de d´tection d’intrusions. e e e Finalement. certaines attaques ne doivent ˆtre consid´r´es o e e ee comme r´ussies que si un ensemble bien d´termin´ d’actions ont ´t´ effectu´es. Les op´rateurs sp´cifiques ` Chronicles mettent o e e e e e a plutˆt le focus sur les diff´rents changements pouvant survenir pendant le processus o e de reconnaissance d’une chronique. Cette fonce e e e e . en plus de corr´ler diff´rentes alarmes entre elles.

Syst`mes de d´tection d’intrusions e e 51 tionnalit´. comme LAMBDA. pour chacun des IDS ´tudi´s. les langages e e imp´ratifs. nous avons jug´ bon de les mentionner car un e bon IDS ne doit pas seulement fournir un langage de signatures suffisamment expressif.10. e 1. D’autres e e langages. A u e quons. Il est ` noter que les deux derni`res propri´e a e a e e t´s ne concernent pas directement le langage. nous avons ´tudi´ 13 syst`mes de d´tection d’intrusions diff´rents.9 la liste des dix caract´ristiques. de mˆme que de permettre une corr´lation e e e logique entre les diff´rentes attaques et de sp´cifier comment r´agir ` ces attaques. comme ADeLe [2]. Nous n’avons e e e pas mentionn´ si le langage LAMBDA comporte les caract´ristiques 9 et 10 car nous e e n’avons r´ussi ` mettre la main sur aucune documentation au sujet d’une ´ventuelle e a e implantation de LAMBDA. nous indine doit pas coˆter trop cher en complexit´ algorithmique. NASL [40] et CASL [41] mettent plutˆt l’accent sur le cˆt´ o oe attaquant. CASL a ´t´ e ee d´velopp´ avec des objectifs similaires et offre des fonctionnalit´s semblables. des avantages et des inconv´nients e e qui leur sont propres. pour chacun de ces langages. parmi a e celles que nous avons relev´es. l’expressivit´ e a e ` la table 1. mais a e e e ´t´ con¸u avec l’objectif de r´aliser des attaques plutˆt que de simplement tester les ee c e o failles. Nous donnons ` la table 1. les syst`mes experts. il doit aussi ˆtre capable de fonctionner ` un bon rythme. e e e e e dont 12 sont ` base de sc´narios. Cependant. les syst`mes de transition. et les logiques temporelles. e e e Nous avons identifi´. La revue que nous avons faite mettait cependant l’accent sur les langages et les paradigmes utilis´s pour exprimer les signatures dans un contexte de d´tection. . NASL e e e a est un langage de scripts d´velopp´ pour l’identificateur de failles de s´curit´ Nessus. Les langages utilis´s pour exprimer les sc´narios rea e e e posent sur 5 cat´gories de paradigmes : les langages sp´cifiques au domaine. quelles caract´ristiques il comporte.Chapitre 1. ADeLe a ´t´ d´velopp´ en parall`le avec LAMBDA dans le but de d´velopper ee e e e e une base donn´es d’attaques. permet de bien mettre les attaques e a e signal´es en contexte. que nous jugeons les plus importantes pour un syst`me de e e d´tection d’intrusions ` base de sc´narios.6 Conclusion Dans ce chapitre. Autrement dit. les attaques ` la fois e e e a du point de vue de l’attaquant et de l’attaqu´. Il e e e e fournit des primitives permettant d’envoyer des paquets forg´s ` la main sur le r´seau e a e et de recevoir d’autres paquets en vue d’effectuer des tests bien pr´cis. jointe ` l’utilisation du mod`le M2D2. Une des pr´occupations des auteurs ´tait de concevoir un e e e langage assez g´n´ral pour pouvoir repr´senter. mais l’algorithme de v´rification utilis´ e e e pour le mettre en oeuvre.

Aussi. e 7) gestion des attributs absents ou multiples Le langage doit prendre automatiquement en compte le fait que certains attributs peuvent ˆtre optionnels pour e certains ´v´nements. ee .Chapitre 1. en plus de faciliter la e e maintenance de la base de signatures. e e 9) fonctionnement en ligne Il doit ˆtre possible d’´laborer un algorithme de v´rifie e e cation capable de traiter les ´v´nements dans l’ordre o` ils surviennent. e e 8) approche d´clarative Un paradigme d´claratif permet. Syst`mes de d´tection d’intrusions e e 52 1) sc´narios ` plusieurs ´v´nements Les diff´rents exemples que nous avons ´tudi´ e a e e e e e nous convainquent que le fait de pouvoir exprimer des sc´narios comportant plue sieurs ´v´nements est n´cessaire pour effectuer une d´tection d’intrusions pr´cise e e e e e et compl`te. Ce calcul n’est cependant possible que si le langage est e e purement d´claratif.1. et de les e e u effacer automatiquement de la m´moire d`s qu’ils sont trait´s. e e e a e 6) propri´t´s de parit´ Certaines conditions ne sont valides qu’entre deux ´v´nee e e e e ments donn´s. e 2) non-occurrence d’´v´nements Il arrive parfois que le fait de ne pas observer un e e ´v´nement soit r´v´lateur d’information. e e e 10) utilisation born´e de la m´moire Il doit ˆtre possible d’´laborer un algorithme e e e e de v´rification capable de fonctionner avec une quantit´ fixe de m´moire qui n’auge e e mente pas avec le nombre d’´v´nements. e e Tab. il est possible qu’un attribut ait une liste de valeurs. 1. e e e 4) comptage Dans certains cas. e 5) acquisition de connaissance Le fait de pouvoir extraire et conserver de fa¸on dyc namique de l’information des ´v´nements observ´s aide ` r´duire les faux positifs. e e e e 3) contraintes temps-r´el On doit ˆtre capable de sp´cifier un d´lai entre les diff´e e e e e rents ´v´nements d’un sc´nario. c’est la r´p´tition d’un ´v´nement ou d’un sc´nario e e e e e donn´ qui est porteur d’information. au sens de la d´finition 1.9 – Dix propri´t´s souhaitables d’un IDS. d’effectuer un calcul de corr´lation entre e les diff´rents sc´narios.

Dans [44]. bien que compora ıtre e tant une phase d’apprentissage. offre lui aussi la possibilit´ de r´gler l’algorithme de v´rification selon les besoins particuliers e e e de l’utilisateur. Alors que les a e e e m´thodes bas´es sur une d´tection d’anomalies ne prennent en entr´e que des fichiers e e e e . pr´sente cependant deux diff´rences importantes avec e e les m´thodes bas´es sur une d´tection d’anomalies (m´thodes statistiques). on soul`ve le e e fait que la compl´tude. bas´ sur l’alg`bre relationnelle. Cette m´thode. bas´e sur un paradigme e e de grammaires. et de s´quencee e ment. 1. mis au point pour le langage MuSigs. on propose une e e e m´thode utilisant les algorithmes g´n´tiques pour apprendre. engendre soue e e vent des probl`mes de complexit´ algorithmique et de surcharge d’alarmes. ` partir d’un ensemble e e e a d’entraˆ ınement. Plusieurs approches issues de techniques d’intelligence artificielle ont aussi ´t´ propoee s´es pour attaquer le probl`me de la d´tection d’intrusions. de temps-r´el. On trouve aussi dans cet article une discussion int´ressante e e e au sujet des probl`mes pratiques d´coulant de la compl´tude des algorithmes de v´rifie e e e cation de signatures dans le cas des langages d´claratifs. Premi`ree e e e e ment.Chapitre 1. e Une approche dont nous n’avons pas parl´ est celle de [42]. Le syst`me ee e e e e ARMD [43]. La m´thode e e e propos´e par les auteurs permet de r´gler l’algorithme de v´rification en d´finissant une e e e e relation d’´quivalence sur les alarmes de fa¸on ` r´duire le nombre d’alarmes tout en e c a e conservant celles qui sont consid´r´es comme ´tant les plus significatives. Syst`mes de d´tection d’intrusions e e 53 nom Snort NeVO ASAX Bro STAT IDIOT BSML P-BEST LAMBDA LogWeaver Monid Chronicles 1 N O O O O O O O O O O O 2 N N N N O N O N O O O O 3 N O O O O O O N O O O O 4 N N O O O O O N N N O O 5 O O O O O O N O O N N N 6 O N O O O O N O O N N N 7 N N O N N N N N N N N N 8 O O N N N N N N O O O O 9 O O N O O O O O O O O 10 O O N O N N O N N N N Tab. ` reconnaˆ les patrons d’attaque. Principalement. l’ensemble d’entraˆ ınement fourni ` l’algorithme doit ˆtre ´tiquet´. bien qu’int´ressante d’un point de vue th´orique. Ce formalisme vient avec un algorithme de v´rification ` base de tableaux qui est e a prouv´ complet et coh´rent. Les auteurs de cet article proposent un formalisme pour repr´senter les e attaques comprenant entre autres des notions de filtre.10 – Tableau r´capitulatif des IDS.

Syst`mes de d´tection d’intrusions e e 54 d’audit. la m´thode propos´e a besoin. La programmation e e e e g´n´tique peut ˆtre vue comme un cas particulier des algorithmes g´n´tiques o` les e e e e e u individus participant aux croisements sont des programmes. 48]. et les gˆnes sont des bouts e de code. on e e e propose d’autres m´thodes bas´es sur la programmation g´n´tique. peu d’autres fichiers d’audit ou de traces de trafic ont ´t´ fournis ` la ee a communaut´ pour permettre de tels travaux. e .Chapitre 1. Encore une fois. Dans [45] et [46]. mais un ensemble de signatures qui peut par la e ee suite ˆtre utilis´ par un algorithme de reconnaissance de sc´narios. le r´sultat de la phase d’apprentissage ne donne pas un profil e e qui doit ˆtre consid´r´ comme normal. ces approches d´pendent de la disponibilit´ de fichiers d’aue e dits ´tiquet´s pour la phase d’apprentissage. en plus. de savoir o` se trouvent les attaques dans e e u ce fichier. Deuxi`mement. depuis les fichiers d’´valuation cr´´s par le laboratoire Lincoln du MIT en 1998 et e ee 1999 [47. Cette contrainte n’est pas des moindres e e car.

on ne parle jamais de la physique de Untel. comme si on avait peur de s’y mouiller. D’abord. ee En allant sous l’onglet logique formelle. la d´finition du mot logique e e semble toujours implicite. Monsieur Jourdain r´pond au maˆ e e ıtre de philosophie qui lui propose de lui enseigner les trois op´rations de l’esprit : Cette e logique-l` ne me revient point. Etrangea e ment. d´pendamment du domaine dans lequel on se trouve. et il nous e ´ resterait toujours ` trouver une d´finition pour le mot logique avec un petit ’l’. e a La logique semble ˆtre ici per¸ue comme une science. logique et Logique. Il y aurait alors. sans s’int´resser ` leur contenu. vraisemblablement. de Moli`re. qu’est-ce qu’une logique ? L’encyclop´die Hachette e Multim´dia. nous donne un article qui commence par ces mots : e Un raisonnement est une activit´ de la pens´e qui ` partir de certains e e a ´tats de connaissance pris comme pr´misses ou hypoth`ses permet d’arriver e e e ` un autre ´tat de connaissance obtenu dans la conclusion du raisonnement. Apprenons autre chose qui soit plus joli. il semble alors difficile d’ade mettre qu’il puisse exister plusieurs logiques. ` cette ´poque. et chacun pr´sente e sa logique de la fa¸on qui lui convient. c . dont une des branches serait la e c logique formelle. la logique formelle n’´tudie la validit´ e e des raisonnements qu’en vertu de leur forme. En effet. Les int´rˆts a ee de Moli`re. Cependant. sous l’onglet logique. Si on d´finit la logique comme une science. a e ´ Etrangement. il semblerait qu’il avait d´j` compris une v´rit´ fondamentale : ea e e il existe plusieurs logiques. les r´sultats commencent ` ˆtre un peu plus e a e satisfaisants : Branche maˆ ıtresse de la logique.Chapitre 2 Logiques temporelles Dans Le Bourgeois Gentilhomme. il faut attendre la seconde phrase pour retrouver le mot logique. La Logique serait alors la science qui ´tudie les logiques. ´taient probablement bien loin de ceux qui nous occupent e a e e aujourd’hui. ou de la biologie de monsieur Machin. et cette phrase ne fait plus du tout r´f´rence aux notions de raisonnement et de connaissance.

e a e e La pr´sentation des logiques temporelles que nous ferons dans ce chapitre sera donc e faite d’abord en fonction des mod`les utilis´s. si on veut comparer deux logiques en termes d’expressivit´. c’est-`e e e a dire un ensemble de r`gles permettant de d´cider. Elle est ee dite plus expressive que L2 si il elle est aussi expressive que L2 et qu’il existe une formule φ1 de L1 telle qu’il n’existe pas de formule φ2 de L2 telle que pour tous les ´l´ments m ee de M . L. Mce Dermott [49]. Allen [50]. l’ensemble L est g´n´r´ par un ensemble de r`gles r´cursives que l’on e e e ee e e appelle la syntaxe du langage. que si deux logiques ne sont pas d´finies ` partir du mˆme mod`le. on a pense d’abord ` sa syntaxe. aussi c u appel´ mod`le. ee e entre autres. M et L sont des ensembles. Les principaux mod`les utilis´s pour les logiques temporelles sont pr´e e e e e e e sent´s ` la table 2. la d´finition semble diff´rente d´e e e e pendamment de la branche qui nous int´resse. m |= φ1 si et seulement si m |= φ2 . puis en fonction des diff´rentes syntaxes e e e et s´mantiques. Logiques temporelles 56 Mˆme au sein d’un domaine comme l’informatique. e e on demandera que celles-ci s’appliquent au mˆme mod`le. une logique est per¸ue comme un langage permettant d’exprimer e c certaines propri´t´s d’un programme ou d’un autre objet abstrait. |= . ou Bacchus [51]. o` M est l’objet du discours. Cependant. et |= est la s´mantique du discours. alors e a e e il est par d´finition impossible de comparer leur expressivit´. G´n´ralement. il ne faut pas n´gliger l’importance du choix a e du mod`le. Le pr´sent travail se situant dans un contexte de v´rification formelle. qui eux s’int´ressent ` la v´rification e a e formelle. Kozen [53]. par exemple. Ceci implique donc.Chapitre 2. il existe une formule φ1 de L1 telle que pour tous les ´l´ments m de M . En e e v´rification formelle. La premi`re ligne. ´tant donn´ φ un ´l´ment du langage e e e e ee et m une instance de mod`le. mˆme si e e elles sont d´finies ` partir du mˆme mod`le. En e a termes ensemblistes.1. Souvent. e une logique est per¸ue comme un triplet M. En v´rification formelle. 55]. Une logique est donc plus expressive si elle permet de discerner avec plus de finesse les ´l´ments du mod`le. Wolper [33]. L est le langage du discours. quand on pense ` une logique en particulier. m |= φ1 si et seulement si m |= φ2 . ne comprend a . sont les mod`les statiques e a de base. En intelligence artiee ficielle. la multiplication u e e des logiques semble un probl`me moins important et lorsque l’on lit. Notons au passage qu’il e e se peut fort bien que deux logiques ne soient pas comparables en expressivit´. si l’affirmation faite par φ est vraie ` propos de m. o` on s’int´resse davantage aux aspects d´ductifs et inductifs. le formalisme e e que nous allons employer sera celui de ces derniers auteurs. c’est-`-dire intemporels. telle quelle. et |= est un sous-ensemble de M × L. Les deux domaines o` l’int´rˆt semble le e u ee plus marqu´ pour les logiques sont l’intelligence artificielle et la v´rification formelle. les formalismes utilis´s sont beaucoup moins e uniformes que celles que l’on rencontre en lisant Pnueli [52]. ainsi que la quatri`me. Entre autres. pour chaque formule φ2 de L2 . La logique propositionnelle. Une logique L1 est dite aussi e e expressive qu’une logique L2 si. ou Henzinger [56]. Emerson et Halpern [54.

et d’autres fa¸on de mod´liser le temps ont ´t´ sugg´r´es. regroup´es dans un ensemble P qui sont toutes soit vraies soit fausses. . . . ` e e a e e a chaque instant tn . e L’attribution du caract`re de v´rit´ ` ces constantes est ce qu’on appelle une interpr´e e ea e tation. Un peu plus tard. . . la plus couramment utilis´e. une avenue possible est de consid´rer que tous les pr´dicats sont de la forme e e p(t. A e interpr´tation. Ce mod`le est g´n´ralement celui qui est souse e e e entendu lors de la d´finition de logiques r´ifi´es. mais un ensemble de pr´dicats. Dans les sections e e . est de dire que les mod`les que nous consid´rions c e e e comme statiques ´voluent de fa¸on discr`te dans le temps et que celui-ci s’´coule ` e c e e a ` chaque instant tn on retrouve donc une nouvelle intervalles r´guliers t0 . Le terme logique temporelle r´f`re habituellement aux logiques utilisant e ee ce type de mod`le. chaque attribution de valeurs aux variables d’un pr´dicat e est associ´e ` un temps. xn ). xn . un temps auquel le changement de valuation s’effectue.1 – Familles de logiques temporelles et leur mod`le. lesquelles valeurs seront choisies dans un ensemble V . t1 . . On a alors ajout´. . 2. On suppose qu’il existe un nombre fini de constantes propositionnelles. . Dans le cas du premier e ordre.Chapitre 2. Finalement. Ces logiques sont habituellement d´sign´es sous le vocable de logiques temporis´es (timed temporal e e e logics). x1 . . la notion d’instant est supprim´e. Autrement dit. . . et l’ensemble de ces interpr´tations constitue le mod`le e e de la logique propositionnelle. Une premi`re c e ee ee e fa¸on. Vient alors la question de la temporisation de ces mod`les. c’est-`-dire un ensemble d’objets de la forme p(x1 . Cette strat´gie est celle qui est parfois utilis´e dans les bases e a e e de donn´es. . Une e e e e excellente revue des logiques r´ifi´es se trouve cependant dans [57]. on a ressenti le besoin de tenir compte du fait e que le temps ne s’´coulait peut-ˆtre pas ` intervalles r´guliers. . e aucune notion de temps. xn ). l’ensemble primitif P n’est plus un ensemble de constantes propositionnelles. Logiques temporelles 57 Famille de logiques Logique propositionnelle Logiques lin´aires propositionelles e Logiques temporis´e propositionnelles e Logique du premier ordre Logiques lin´aires du premier ordre e Logiques temporis´es du premier ordre e Logiques r´ifi´es e e Mod`le e I ∈ 2P σ : N → 2P σ : N → 2P × T I ∈ {P → {X → V }} σ : N → {P → {X → V }} σ : N → {P → {X → V }} × T σ : T → {P → {X → V }} Tab. ou encore une valuation. lorsque les changements s’effectuent de fa¸on possiblement continue c dans le temps. Les r`gles permettant de manipuler de tels objets ne sont cependant pas e e des plus nettes. Une interpr´tae a e tion sera alors vue comme un ensemble de fa¸ons d’attribuer des valeurs aux variables c x1 . Dans le cas de la logique du premier ordre. . qui ne seront pas trait´es ici. t2 .. . ` chaque point de la ligne du temps e a se trouve une nouvelle interpr´tation.

ou le µ-calcul modal [53]. nous traitons d’abord les logiques temporelles. Prine cipalement. Par σ(i). alors qu’une ee e e e logique arborescente permet de tenir compte des liens entre ces diverses ex´cutions.2 – Syntaxe de LTL. la notion d’arborescence ne pr´sente aucun int´rˆt pour e e ee nous.Chapitre 2. Le e ee mod`le sur lequel LTL est d´finie. et il semblerait que le succ`s technologique de l’outil de v´rification e e oe e SPIN [59] ait fait pencher la balance du cˆt´ des logiques lin´aires. nous ne consid´rons qu’un seul chemin e e d’ex´cution (celui en cours).1 Logique temporelle lin´aire e φ ::= p | ¬φ | φ1 ∨ φ2 | φ | φ1 U φ2 Tab. 2. la raison pour laquelle les logiques arborescentes ne sont pas pr´sent´es ici est qu’´tant e e e donn´ que. e e . la logique temporelle lin´aire est e e e celle qui historiquement est apparue en premier [60. Peu importe. telles que CTL. CTL [58]. prises s´par´ment.1. 52]. Les ´tats de la trace sont des ensembles de e e e constantes propositionnelles. est celui de la deuxi`me ligne de la table 2. . Etant e e ´ donn´ l’ensemble des ex´cutions possibles d’un programme. La majorit´ des autres logiques e que nous pr´sentons dans ce chapitre sont des variantes de celles-ci ou s’y r´f`rent. 2. puis les logiques temporis´es. dans le contexte de notre travail. on d´note le ieme ´tat de σ.1 Logiques temporelles Toutes les logiques temporelles que nous pr´sentons dans cette section sont des e logiques dites lin´aires. qui se d´finissent par opposition aux logiques dites arborese e ∗ centes. aussi appel´e trace. . que l’on note σ. La diff´rence entre une e logique lin´aire et une logique arborescente se situe d’abord au niveau du mod`le. e ee La pertinence de telles propri´t´s a fait l’objet d’une guerre de clochers pendant un ee certain temps [55]. Logiques temporelles 58 qui suivent.1. comme toutes les autres logiques pr´sent´es dans cette e e e e section. c’est-`-dire une s´quence infinie e a e d’´tats. il sera possible d’aller vers un chemin d’ex´cution ayant la propri´t´. . e 2. une logique lin´aire permet e e e d’exprimer les propri´t´s de chacune de ces ex´cutions. une logique arborescente permet d’exprimer la propri´t´ ` partir d’un cereea tain moment. De toutes les logiques pr´sent´es dans ce chapitre.

2. ee ` A la table 2. Il s’agit d’op´rateurs temporels futurs. →. e e e e dont la d´finition se trouve ` la table 2. au sens o` ils permettent d’exprimer e u des propri´t´s concernant les ´tats ` venir. la logique temporelle lin´aire comporte d’autres op´rateurs d´finis. ici.3. et ↔.4. Le lecteur e francophone doit donc faire attention. e def φ φ φ1 U φ2 = = = vrai U φ ¬ ¬φ (φ1 U φ2 ) ∨ φ1 def def Tab. la formule φ1 U φ2 est satisfaite un ´tat σ(i) si et seulement si e il a un successeur σ(k) (pas n´cessairement imm´diat) satisfaisant φ2 et dont tous les e e ´tats σ(j) entre σ(i) et σ(k) satisfont φ1 .σ(k) |= φ2 et ∀i ≤ j < k. se lit n´cessairement. et l’op´rateur U est l’op´rateur ee e e e jusqu’` ce que. Logiques temporelles 59 σ(i) |= p σ(i) |= ¬φ σ(i) |= φ1 ∨ φ2 σ(i) |= φ σ(i) |= φ1 U φ2 ssi ssi ssi ssi ssi p ∈ σ(i) σ(i) |= φ σ(i) |= φ1 ou σ(i) |= φ2 σ(i + 1) |= φ ∃k ≥ i.Chapitre 2.2. se trouve la s´mantique formelle de LTL. Notons au passage qu’en anglais. permettant d’exprimer qu’une propri´t´ qui doit ˆtre respect´e jusqu’` a ee e e a ce qu’une autre propri´t´ le soit. e e Outre les op´rateurs ∧. La formule ´l´mentaire p e ee est satisfaite par un ´tat σ(i) si et seulement si celui-ci contient p. Finalement.4 – Op´rateurs d´finis de LTL.3 – S´mantique de LTL.σ(j) |= φ1 Tab. La formule e φ est satisfaite par un ´tat σ(i) si et seulement si son successeur imm´diat σ(i + 1) e e satisfait φ. auxquelles on ajoute les op´rateurs temporels e et U. Les formules de LTL sont les mˆmes e a e que celles du calcul propositionnel. e La syntaxe de LTL est donn´e ` la table 2. L’op´rateur ee e a e est l’op´rateur prochain e permettant d’exprimer une propri´t´ du prochain ´tat. e a e e φ se produira. que l’on peut d´finir comme d’habitude ` l’aide des e e a op´rateurs ∨ et ¬. 2. cet op´rateur se lit eventually. La formule ¬φ est e satisfaite par un ´tat σ(i) si et seulement si celui-ci ne satisfait pas φ. ` la confusion linguistique entre le mot fran¸ais a c . La formule φ1 ∨ φ2 e est satisfaite par un ´tat σ(i) si et seulement si celui-ci satisfait φ1 ou φ2 . Le premier op´rateur. φ.

Ces a deux programmes comportent chacun deux chemins d’ex´cution. L’op´rateur φ. ´ventuellement et le mot anglais eventually. 2. sont des op´rateurs e ea e . qui permet que φ2 ne soit jamais satisfaite. 2.Chapitre 2. On utilise e e ee e l’op´rateur U plutˆt que U car si la variable n’est jamais lue. Par exemple.1. quand ` lui. le mot c ´ventuellement laisse place ` l’incertitude. si quelque chose se produit e eventually. ee 2. les deux programmes montr´s e e e u e e ` la figure 2. nous sommes certains que cela finira par arriver. alors que le premier ´tat d’un des chemins du programme ee e de gauche ne respecte pas la propri´t´ ¬read(j) U write(j). d´pendamment de la e e valeur i fournie par l’usager.1 – Exemples de programmes.5 – Syntaxe de P-LTL. les constantes propositionnelles write(v) et read(v) peuvent repr´senter l’acc`s e e en ´criture et en lecture de cette variable. si v est une variable utilis´e dans un proee e gramme. Logiques temporelles 60 lire i si i < 0 alors i := −i lire j k := i + j lire i si i < 0 alors i := −i lire j k := i + j Fig. la formule ¬read(v) U write(v) signifie e que la variable v ne doit pas ˆtre utilis´e tant qu’elle n’a pas ´t´ initialis´e. En anglais. Le premier ´tat de chacun de ces quatre chemins respecte la e propri´t´ ¬read(i) U write(i). Alors. doit se lire toujours φ. l’op´rateur φ1 U φ2 est le faible e jusqu’` ce que. Finalement.1. comme nous l’avons d´j` dit. a La logique temporelle lin´aire a ´t´ con¸ue pour permettre la v´rification statique e ee c e de propri´t´s de programmes. Les op´rateurs temporels de LTL. Consid´rons. et c’est pourquoi nous traduisons eventually e a par n´cessairement.2 Logique temporelle lin´aire pass´e e e φ ::= p | ¬φ | φ1 ∨ φ2 | φ | φ1 U φ2 | φ | φ1 S φ2 Tab. alors qu’en fran¸ais. Il est d´fini e e a e comme il est faux de dire que φ sera fausse. alors il n’est nullement e o besoin qu’elle soit initialis´e. par exemple. o` l’indentation est utilis´e pour d´limiter les blocs d’instructions.

La formule φ1 S φ2 est e e e a satisfaite par un ´tat σ(i) si et seulement si celui-ci est pr´c´d´ d’un ´tat σ(k) satisfaisant e e e e e φ2 tel que tous les ´tats σ(j) entre σ(k) et σ(i) satisfont φ1 .5.6 – S´mantique des op´rateurs particuliers ` P-LTL. L’op´rateur a e e e e e doit se lire juste avant. e e e Pour reprendre l’exemple que nous d´j` ´tudi´. Il s’agit de la mˆme syntaxe que e a e pour LTL. La formule φ est satisfaite par e e e un ´tat σ(i) si et seulement si celui-ci est pr´c´d´ d’un ´tat satisfaisant φ. S doit se lire depuis.7 – Op´rateurs d´finis de P-LTL. par les mˆmes ´tats e e e que la formule ¬read(v) U write(v). cette formule signifie que l’on ne doit pas . Il est alors naturel de se demander s’il serait possible d’augmenter e ee l’expressivit´ de LTL en lui ajoutant des op´rateurs faisant r´f´rence au pass´. Cette ee e formule est satisfaite. est satisfaite par un ´tat σ(i) si et seulement si il dispose d’un pr´d´cesseur a e e e imm´diat et que celui-ci satisfait φ. et la formule e e e e e φ est satisfaite un ´tat σ(i) si et seulement si tous ses pr´d´cesseurs satisfont φ.Chapitre 2. La formule e φ. La logique e e ee e obtenue en ajoutant les ´quivalents pass´s de U et e e ` LTL s’appelle P-LTL (Pasta LTL). e φ φ def = vrai S φ ¬ ¬φ def = Tab. il est possible de d´finir de nouveaux op´rateurs ` l’aide e e a de ces op´rateurs. La syntaxe de P-LTL est donn´e ` la table 2. 2. e e Comme dans le cas de LTL. quand ` elle. alors avant cela. la formule (read(v) → write(v)) eae e signifie alors que si une variable v est lue. au sens o` leur s´mantique ne r´f`re qu’` des ´tats se trouvant apr`s u e ee a e e l’´tat consid´r´. pour une variable v et une trace σ donn´es. Quelques exemples de ces op´rateurs sont donn´s ` la table 2. et l’op´rateur La s´mantique de ces op´rateurs est donn´e ` la table 2.σ(k) |= φ2 et ∀i ≥ j > k.σ(j) |= φ1 Tab. Logiques temporelles 61 σ(i) |= φ σ(i) |= φ1 S φ2 ssi i > 0 et σ(i − 1) |= φ ssi ∃0 ≤ k ≤ i. ` laquelle on a ajout´ des op´rateurs temporels pass´s S et .7. e e a temporels futurs. Les e e e a op´rateurs et sont les ´quivalents pass´s de et . 2.6. elle a ´t´ initialis´e. En effet.

nous ne la reproduirons pas ici. dont le d´tail de la e e e e d´monstration se trouve lui aussi dans [61].3 (S´paration) Toute formule de P-LTL peut ˆtre exprim´e comme une e e e combinaison bool´enne de formules purement futures et purement pass´es. nous devons d’abord nous demander de quelle exe a pressivit´ on parle. dans plusieurs cas d’apee e e plication. mais e En raisonnant un peu. e Th´or`me 2. nous dit que tel est le cas. on voit que toute formule purement pass´e (n’utilisant pas les e op´rateurs U et ) de la forme e φ est initialement ´quivalente ` faux. on serait capable de lui trouver une formule e purement future qui lui serait initialement ´quivalente. il existe e e e une formule de LTL initialement ´quivalente. Elles sont dites initialement ´quivalentes si. nous n’avons e e e a consid´r´ que l’´tat initial des chemins d’ex´cution. On e e distingue donc deux relations d’´quivalence distinctes : e ´ D´finition 2. e e Le r´sultat suivant. En effet. e e a Donc. pour toute trace σ. En fait. En effet.4 (Expressivit´ de P-LTL) Pour toute formule de P-LTL. dans les exemples ´tudi´s jusqu’` maintenant. e Lemme 2.2 Les formules p ∧ ne sont pas ´quivalentes. e Il ne faut cependant pas tomber dans le pi`ge de croire que les op´rateurs pass´s e e e n’apportent rien ` la logique temporelle lin´aire. σ(i) |= φ1 ssi σ(i) |= φ2 . e e Ce r´sultat nous permet alors d’arriver au th´or`me suivant.Chapitre 2. d´montr´ dans [61]. e q et p ∧ ¬q sont initialement ´quivalentes.1 (Equivalence de formules) Deux formules φ1 et φ2 sont dites ´quie e valentes si. de fa¸on ` obtenir une combinaison bool´enne de formules e e c a e purement pass´es et purement futures. Logiques temporelles 62 lire la variable v avant de l’avoir initialis´e. et que toute e a formule purement pass´e de la forme φ1 S φ2 est initialement ´quivalente ` φ1 ∧ φ2 . σ(0) |= φ1 ssi σ(0) |= φ2 . La relation d’´quivalence entre des formules obtenue en ne consid´e e rant que l’´tat initial est diff´rente de celle obtenue si on regarde la trace en entier. Ceci nous am`ne alors ` douter du fait que e e a l’ajout d’op´rateurs pass´s ` LTL a vraiment augment´ son expressivit´. e e a e e Pour r´pondre ` cette question. en plus de permettre d’exprimer a e . il est sous-entendu qu’un programme donn´ satisfait une propri´t´ si son ´tat e ee e initial la satisfait. e Exemple 2. si on ´tait capable de sortir les op´rateurs pass´s d’une formule combinant des e e e op´rateurs pass´s et futurs. pour toute trace σ et pour tout i ∈ N. La d´monstration e e e ´tant un peu longue et hautement technique.

On voudrait ˆtre capable de dire que le probl`me est survenu e a e e e depuis la remise ` z´ro. . 2. dans le cas o` on ne v´rifie qu’un seul u e chemin d’ex´cution en temps r´el. 64] ont propos´ d’ajouter ` P-LTL l’op´rateur e e e a e . cette m´thode oblige ` sauvegarder toute la trace e e a d’ex´cution. ee 2. alarm. o` φ ne e e a e u comporte que les op´rateurs pass´s. Autrement dit. En e e e e fait. dans [62]. Lorsque l’on permet de m´langer les op´rateurs de pass´ et de futur. qu’il est possible e e eaee e e d’utiliser des algorithmes de v´rification qui s’ex´cutent en temps lin´aire et n’utilisent e e e qu’une quantit´ de m´moire constante en fonction de la taille du chemin v´rifi´. mais aussi par la trace : reset. alarm. problem. par e e exemple. Pour e o e e e ces raisons. Alors. on est forc´ d’attendre que le programme ait termin´ son ex´cution avant de passer ` la e e e a v´rification. il a d´j` ´t´ d´montr´. plus ee c succincte. on se retrouve alors aux prises avec le probl`me suivant : l’alarme continue de sonner e apr`s la remise ` z´ro. il est aussi possible d’arriver au mˆme r´sultat si on se limite aux op´rateurs e e e e futurs [31]. problem. signifiant qu’` chaque fois a qu’une remise ` z´ro est effectu´e. Logiques temporelles 63 certaines propri´t´s de fa¸on plus intuitive et. Pour a e e e r´gler ce probl`me. En plus de ne fonctionner que dans le cas o` le programme ` v´rifier n’a e u a e pas de chemin d’ex´cution infini.1. il existe des cas d’utilisation o` les algorithmes de v´rification ` utiliser sont u e a significativement plus efficaces. comme nous le verrons sous peu. il se peut e e e que certaines sp´cifications n’aient pas exactement le sens attendu. Consid´rons. alarm. . plutˆt que de simplement la v´rifier en mˆme temps qu’elle se cr´e. .3 Logique temporelle lin´aire avec pass´ oubliable e e φ ::= p | ¬φ | φ1 ∨ φ2 | φ | φ1 U φ2 | φ | φ1 S φ2 | N φ Tab. on voudrait ˆtre capable d’oublier le pass´. l’alarme n’est pas d´clench´e tant qu’il n’y a pas eu a e e e e un probl`me (l’alarme ne sonne pas pour rien). . si la formule ` v´rifier est de la forme φ. reset. l’introduction d’op´rateurs pass´s en logique temporelle repr´sente donc un e e e grand int´rˆt.8 – Syntaxe de N-LTL.Chapitre 2. mais comme les algorithmes utilis´s partent alors de la fin de la trace. . alarm. certains auteurs [63. Par exemple. . la formule (reset → (alarm → problem)). cette formule est satisfaite par la e trace : reset.

de l’op´rateur N. Cependant. C’est-`-dire que σ (j) = σ(j + i). C’est-`-dire que le nombre d’op´rateurs de φ2 est au a e moins exponentiellement plus grand que celui de φ1 . D’apr`s eux. Deuxi`mement. malgr´ le fait qu’elles n’apportent rien du point de vue de l’expressivit´ : e e Th´or`me 2. Ce r´sultat est int´ressant pour au e e moins deux raisons. alors |φ2 | ∈ Ω(|φ1 |). e a e e e dans [63].9. du point e e e de vue de la facilit´ d’utilisation. La notation σ i a e e e a eme d´signe le i e suffixe de σ. cela signifie que les sp´cifications peuvent s’´crire ` e e e a l’aide de formules exponentiellement plus courtes. et que cet exemple ne nous convainc pas tellement de la n´ee e cessit´. le principal avantage li´ ` son utilisation r´side au niveau e e ea e de la taille des formules n´cessaires pour exprimer certaines propri´t´s. du point de vue de la v´rification. La s´mantique de l’op´rateur N est donn´e ` la table 2. et sa syntaxe est donn´e e e ` la table 2. qui se lit ` partir de maintenant. qui ensemble justifient l’introduction de P-LTL et e N-LTL. 2. et dont l’objectif est justement de permettre d’oublier le pass´. La logique obtenue alors s’appelle N-LTL.6 (Succintet´ de N-LTL) N-LTL peut ˆtre exponentiellement plus suce e e e cincte que P-LTL. e e a a N. du point de vue de l’expressivit´.Chapitre 2.9 – S´mantique de l’op´rateur particulier ` N-LTL. on remarque aussi que la formule de LTL (reset → ¬alarm U problem) exprime la propri´t´ voulue. Ils montrent mˆme. Une logique L1 est dite exponentiellement plus succincte qu’une logique L2 si il existe une propri´t´ ψ tel que si φ1 et φ2 sont les plus petites formules de L1 et L2 ee exprimant ψ. ils e ee montrent les deux r´sultats suivants. Premi`rement. . Logiques temporelles 64 σ(i) |= N φ ssi σ i (0) |= φ Tab.5 (Succintet´ de P-LTL) P-LTL peut ˆtre exponentiellement plus suce e e e cinte que LTL. Il s’agit de la trace obtenue en coupant les i premiers ´tats e i de σ. cela signifie que le e e temps de v´rification peut ˆtre exponentiellement plus court. Th´or`me 2.8. Dans [64]. a Avec ce nouvel op´rateur. les introducteurs de e e e N-LTL ne pr´tendent nullement ajouter ` l’expressivit´ de P-LTL. En fait. que toute formule de N-LTL peut ˆtre traduite en une formule de LTL qui lui est ´quivalente. il est alors en mesure d’exprimer la propri´t´ voulue ` e ee a l’aide de la formule : (reset → N( (alarm → problem))).

e a L’op´rateur permettant de d´finir de fa¸on g´n´rale des formules de fa¸on r´cursive e e c e e c e est l’op´rateur µ. La s´mantique formelle de l’op´rateur de point fixe est donn´e ` la table 2. φ se trouve alors ` ˆtre d´finie comme ae e la formule X satisfaite si et seulement si φ est satisfaite ou X est satisfaite par l’´tat e suivant. Ensuite.4 µ-calcul lin´aire e φ ::= X | p | ¬φ | φ1 ∨ φ2 | φ| φ | µX. 2. Par induction. 2. Pour X une variable libre e e (n’apparaissant pas sous la port´e d’un op´rateur µX) apparaissant dans φ.φ avec µ0 X.(φ ∨ X). si on ajoute l’op´rateur de point fixe ` la logique modale.φ ssi ∃j. on peut d´finir la formule φ de la fa¸on e a e c def suivante : φ = µX.φ def = = faux φ[µj−1 X.11. et de permettre de d´finir des formules e e e e r´cursivement.1. Lorsque l’on ajoute l’op´rae e e e teur de point fixe ` une logique d´j` existante. Par a ea exemple. cette formule serait alors satisfaite par σ(i) si et seulement si il existe un ´tat ` partir de σ(i) satisfaisant la formule φ. Par exemple.10. on obtient le µ-calcul e a modal. Logiques temporelles 65 2.σ(i) |= µj X. Informellement. dans laquelle on a textuellement substitu´ la e . Avec cette syntaxe.φ/X] def Tab.φ et pour j = 0. e σ(i) |= µX. Il e e e a s’agit d’une s´mantique bas´e sur la notion d’approximants. on dit que l’on obtient un µ-calcul. µj X. appel´ op´rateur de plus petit point fixe.φ Tab. e e e Une autre fa¸on de percevoir le d´roulement du temps est de ne prendre que les c e op´rateurs de pass´ et de futur imm´diats. on pourrait d´finir l’op´rateur φ de la fa¸on suivante : e e e c σ(i) |= φ si et seulement si σ(i) |= φ ou σ(i) |= φ.Chapitre 2. dont la syntaxe est e donn´e ` la table 2.10 – Syntaxe du µ-calcul lin´aire. Le µ-calcul dont il est question ici est le µ-calcul lin´aire. le premier e e approximant de φ selon X est tout simplement la formule faux. on d´finit e `me e `me e e le i approximant r´cursivement ` partir du i − 1 e a de la fa¸on suivante : le i`me c approximant selon X est la formule φ.11 – S´mantique de l’op´rateur particulier au µ-calcul lin´aire.

Sa d´finition formelle est donn´e ` la e e e a table 2. 2. l’op´rateur e a e e ν. e e e Nous terminons cette section en remarquant que nous n’avons pas justifi´ l’emploi e du terme point fixe pour d´signer les op´rateurs µ et ν.φ2 ∨ (φ1 ∧ µX. . dans le cas de la formule φ. e e Il est facile de voir que le µ-calcul lin´aire est au moins aussi expressif que LTL ou e ` la figure 2. On peut aussi d´finir.Chapitre 2. Il est cependant moins facile de voir a e e si celui-ci est strictement plus expressif.φ est alors satisfaite par σ(i) si et seulement si il existe un approximant selon X satisfait par σ(i). Une e e a autre fa¸on de faire est de voir une formule φ comportant une variable libre X comme c une fonction prenant en entr´e un ensemble d’´tats et donnant en sortie l’ensemble e e .φ est alors satisfaite si et seulement si elle est satisfaite par tous ses approximants selon X. φ ∨ faux. on arrive au r´sultat suivant : ee e ¬p ∧ X exprime exac- Th´or`me 2. Logiques temporelles 66 νX. on montre comment on peut d´finir les op´rateurs de LTL et P-LTL. e e e e variable X par le i − 1`me approximant selon X. Par exemple. nous permet de conclure que le µ-calcul lin´aire est strictement e e plus expressif que LTL : Lemme 2. .12. Ceci est dˆ au choix que e e u nous avons fait de pr´senter leur s´mantique ` l’aide de la notion d’approximant. la suite des approximants selon X est faux.φ2 ∨ (φ1 ∧ X) X) def def = Tab.p ∈ σ(i) ssi i est pair. qui est l’op´rateur de plus grand point fixe. φ ∨ (φ ∨ faux). Alors.. En fait.12. Par exemple. . comme la formule du µ-calcul lin´aire νX.φ φ1 U φ2 φ1 S φ2 def = = ¬µX. le lemme suivant [33].φ[¬X/X] µX. L’approximant de base devient alors true. il permet de d´finir φ comme ´tant νX. La formule µX. et la formule νX.8 Le µ-calcul lin´aire est strictement plus expressif que LTL.p ∧ e tement cette propri´t´.7 Il n’existe pas de formule de LTL satisfaite par tous les ´tats σ(i) d’une e trace si et seulement si ∀i.12 – Op´rateurs d´finis du µ-calcul lin´aire.(φ ∧ X). que nous ne d´montrerons pas ici. A e e P-LTL ` l’aide des op´rateurs du µ-calcul lin´aire. ` partir de l’op´rateur de plus petit point fixe.

si on ne permet de ne les appliquer qu’aux constantes e propositionnelles).2. Il ne faut pas confondre ce probl`me avec celui de la v´rification de syst`mes e e e e . e e e 2. Les ´l´ments σ(i) d’une trace σ sont donc des couples. on dispose d’une repr´sentation du temps qui est continue. Aussi. et la seconde composante. le choix du domaine temporel (continu e ou discret) est laiss´ libre ` l’utilisateur.φ) est alors le plus petit (le plus grand) point fixe de e cette fonction.1 Logique temporelle temporis´e e Les premiers articles sur la v´rification de syst`mes temps-r´el datent de la fin des e e e ann´es 80. L’ensemble des e e ea ´tats satisfaisant µX. e on dispose d’une repr´sentation discr`te. dont la premi`re compoee e sante. Logiques temporelles 67 des ´tats satisfaisant φ sous l’hypoth`se que ceux-ci satisfont d´j` X. e e ` et leur mod`le est celui de la troisi`me ligne.φ (νX. L’existence de ce point fixe a ´t´ d´montr´e par Tarski [65] en 1955 ee e e dans un contexte plus g´n´ral : celui des treillis. et s’il s’agit de N.2 Logiques temporis´es e Les quatre logiques que nous venons de pr´senter ´taient toutes comparables du point e e de vue de l’expressivit´ car elles ´taient toutes d´finies ` partir du mˆme mod`le : celui e e e a e e e de la deuxi`me ligne de la table 2. e e e l’ensemble choisi par les auteurs est N. mais sachons seulement qu’il est e e e possible de les d´montrer comme ´tant ´quivalentes [53].1). Les logiques que nous pr´sentons dans cette section e ne leur sont pas comparables car elles sont d´finies ` partir de mod`les temporis´s. un instant t pris dans un domaine temporel T. est le temps qui lui est associ´. A chaque ´v´nement on associe. e a e e Les deux premi`res logiques que nous pr´sentons sont des logiques propositionnelles. La troisi`me logique que nous pr´sentons se distingue des deux autres de par le fait e e que le mod`le sur lequel elle est d´finie est celui d’une logique temporis´e du premier e e e ordre (avant-derni`re ligne de la table 2. e a 2. est l’ensemble de constantes propositionnelles.Chapitre 2. σ1 (i).1. en plus e e e e d’un ensemble de constantes propositionnelles. Dans le cas de ces deux premi`res logiques. Nous nous arrˆtons ici sur cette fa¸on e e e c de d´finir la s´mantique des op´rateurs de point fixe. σ2 (i). L’existence de ce point fixe est garantie ` condition que la fonction a soit monotone (ce qui sera le cas si on pose les restrictions n´cessaires sur l’imbrication e des n´gations ou mieux encore. Si l’ensemble T choisi pour repr´senter le temps e e est R.

Logiques temporelles 68 π ::= x + c | c φ ::= p | π1 ≤ π2 | π1 ≡d π2 | x.13 – Syntaxe de T-LTL.). Une des caract´ristiques les plus importantes des syst`mes temporis´s e e e e est que les diff´rentes actions pouvant ˆtre effectu´es par le syst`me ne sont plus consie e e e d´r´es comme pouvant ˆtre effectu´es en un simple tic d’horloge. et que ces actions prennent respectivement 5. Un chronom`tre est une variable qui s’unifie avec le temps de certains ´v´nements e e e e ` l’aide d’un op´rateur sp´cial. mais e e e il ne peut pas l’effectuer dans un d´lai de 2 secondes. dans sa th`se de doctorat [66]. syst`mes de transition ´tiquet´s) plusieurs formalismes ont aussi ´t´ propos´s e e e ee e pour repr´senter les syst`mes temps-r´el (automates temporis´s. si un syst`me peut effectuer la suite d’actions e ouvrir−entrer−f ermer. e ea µ-calcul modal [67]. est d’avoir propos´ d’ajouter aux diverses logiques temporelles d´j` existantes (LTL [56]. a propos´ tout une e m´thodologie pour repr´senter et v´rifier les syst`mes temps-r´el. e e e . mais sachons seulement que c’est dans ce e e e contexte que les logiques temporis´es sont d’abord apparues.φ | ¬φ | φ1 ∨ φ2 | φ | φ1 U φ2 Tab. etc. et mˆme ETL [66]. on s’int´ressera ` ce qu’elle se ferme pas e e e a plus de une minute apr`s que l’auto y soit entr´e. dont nous ne parlons pas ici) la notion de chronoe m`tre. e e De la mˆme fa¸on que plusieurs formalismes ont ´t´ propos´s pour d´crire les syse c ee e e t`me non-temporis´s (automates. mais en un certaine ee e e nombre de tics d’horloge. Nous ne nous ´tendrons pas ici sur les diff´rents formalismes ayant ´t´ propos´s e e ee e pour repr´senter les syst`mes temps-r´el.Chapitre 2. alg`bres de processus. Par exemple. Henzinger qui. CTL [67]. qui elle prend 10 secondes. du point de vue des logiques temporelles. Une fois initiaa e e e e lis´. structures de e e e e Kripke. e e e e e Une de ses contributions. au lieu de s’int´resser ` ce que la porte du e e e a garage se ferme apr`s que l’auto y soit entr´e. Un e e e e syst`me temps-r´el est un syst`me dont la sp´cification comporte des aspects temporels e e e e exprim´s en unit´s de temps. un chronom`tre peut ˆtre utilis´ pour sp´cifier les contraintes temporelles devant e e e e e ˆtre v´rifi´es entre diverses actions. Par exemple. alors le syst`me peut effectuer l’action f ermer apr`s avoir effectu´ l’action ouvrir. en temps r´el (qui est celui qui nous int´resse dans le cadre du pr´sent m´moire). Un des auteurs ayant le e plus particip´ au d´veloppement de la v´rification des syst`mes temps-r´el est sans e e e e e e doute Thomas A. car il doit entre temps effectuer e l’action entrer. alg`bres de processus e e e e e temporis´es. 2. appel´ op´rateur d’initialisation (reset).10 et 5 secondes. r´seaux de Petri.

On e e e a e a remarque qu’il s’agit de la seule logique parmi celles pr´sent´es dans ce chapitre pour e e laquelle on a besoin d’une notion d’environnement.φ σ(i) |=ε π1 ≤ π2 σ(i) |=ε π1 ≡d π2 def ssi σ(i) |=ε[σ2 (i)/x] φ ssi ε(π1 ) ≤ ε(π2 ) ssi ε(π1 ) ≡d ε(π2 ) def avec ε(x + c) = ε(x) + c et ε(c) = c Tab. e e Dans le cas de LTL. quand ` elles. Ceux-ci a e sont mis ` jour ` l’aide de l’op´rateur d’initialisation. 2. cette derni`re construction e e e n’aurait aucun sens.(true U y. les constructions π1 ≤ π2 et π1 ≡d π2 e sont des contraintes temporelles. e Nous ne pousserons pas plus loin cette pr´sentation de T-LTL. Nous terminons en e pr´sentant comment on peut d´finir.14 – S´mantique des op´rateurs particuliers ` T-LTL. l’op´rateur t φ. Logiques temporelles 69 σ(i) |=ε x. Un environnement ε est une fonction partielle associant des instants ` certains des chronom`tres de la formule. Finalement.φ est celle permettant d’unifier e e la variable x avec l’instant pr´sent. dont la e syntaxe est donn´e ` la table 2. La construction π repr´sente une r´f´rence temporelle.13. l’ajout de chronom`tres donne la logique T-LTL [56]. alors que la seconde signifie que π1 est congrue ` π2 modulo d. La premi`re signifie que π1 est plus petite ou ´gale ` e e a π2 .φ est donc satisa a e faite par σ(i) sous un environnement ε si et seulement si φ est satisfaite par σ(i) sous l’environnement ε mis ` jour de fa¸on ` associer au chronom`tre x l’instant de σ(i). a c a e Les contraintes temporelles. sont satisfaites sous ε si les relations qu’elles a expriment sont vraies en rempla¸ant les chronom`tres par les valeurs auxquelles ils sont c e associ´s dans ε. La formule x.14. On remarque que a si T-LTL ´tait d´finie pour un domaine temporel continu. e e a e e .15 – Un op´rateur d´fini de T-LTL.(φ ∧ y < x + t)) Tab. La s´mantique des op´rateurs ainsi ajout´s ` LTL est donn´e ` la table 2.Chapitre 2. et le cas x + c est une r´f´rence temporelle ee ee relative (c unit´s de temps apr`s x). e e a tφ def = x. e a e ee Le cas c est une r´f´rence temporelle absolue. ` l’aide des op´rateurs de T-LTL. La construction x. 2.

Chapitre 2. e e a Pour exprimer les contraintes de temps-r´el.16.17. σ(i) |= I φ σ(i) |= φ1 UI φ2 σ(i) |= I φ σ(i) |= φ1 SI φ2 σ2 (i) ± [m. Elle signifie que si x est l’instant associ´ ` e a ea l’´v´nement pr´sent. est d´fini dans MTL de la fa¸on suivante : t φ = true U[0. La logique ainsi obtenue s’appelle MTL (Metric Temporal Logic). n] | ≡d c φ ::= p | ¬φ | φ1 ∨ φ2 | I φ | φ1 UI φ2 | I φ | φ 1 SI φ 2 Tab.σ(j) |= φ1 def = [m ± σ2 (i). Logiques temporelles 70 Cette d´finition se trouve ` la figure 2.σ(k) |= φ2 et σ2 (k) ∈ σ2 (i) − I et ∀i ≥ j > k.2. ` un certain instant y situ´ ` moins de t unit´s de temps e e e a ea e dans le futur.16 – Syntaxe de MTL. n]) et relations de congruence (≡d ).σ(k) |= φ2 et σ2 (k) ∈ σ2 (i) + I et ∀i ≤ j < k. Par exemple. D’autres auteurs [68]. La syntaxe de MTL est donn´e ` la table 2.2 Logique temporelle m´trique e I ::= [m. contemporains ` Henzinger. 2. Les contraintes temporelles sont de e a deux types : intervalles ([m.t] φ. alors. e La s´mantique des op´rateurs de MTL est donn´e ` la table 2. n ± σ2 (i)] def = =d (σ2 (i) ± c) ssi m ≤ σ2 (i) ≤ n ssi σ2 (i) =d c Tab.17 – S´mantique des op´rateurs particuliers ` MTL. n] σ2 (i) ± (≡d c) σ2 (i) ∈ [m. 2.15. n] σ2 (i) ∈ ≡d c ssi σ(i + 1) |= φ et σ2 (i + 1) ∈ σ2 (i) + I ssi ∃k ≥ i. φ doit ˆtre satisfaite. en les indexant direce ea e tement par les contraintes. ont plutˆt propos´ e a o e de modifier les op´rateurs temporels d´j` pr´sents dans LTL. e 2. Ils s’interpr`tent e e e a . l’op´rateur e def e c t . Henzinger a choisi d’ajouter ` LTL cere a tains op´rateurs.σ(j) |= φ1 ssi σ(i − 1) |= φ et σ2 (i + 1) ∈ σ2 (i) − I ssi ∃k ≤ i.

Chapitre 2. Logiques temporelles

71

tous de la mˆme fa¸on que pour LTL, sauf que les ´tats concern´s sont restreints ` la e c e e a contrainte temps-r´el I. Par exemple, si σ2 (i) = 7, alors [0,5] φ est satisfaite par σ(i) e ssi σ(i + 1) |= φ et σ2 (i + 1) ∈ [7, 12]. Mˆme chose pour la relation de congruence. Si e σ2 (i) = 7, alors ≡5 φ est satisfaite par σ(i) ssi σ(i + 1) |= φ et σ2 (i + 1) ≡5 12. Dans sa th`se, Henzinger affirme que les deux fa¸ons d’exprimer les contraintes e c temps-r´el sont ´quivalentes. Il affirme aussi que MTL, du point de vue de la d´cidabilit´, e e e e se prˆte mieux aux contraintes pass´es que T-LTL. Historiquement, il semblerait que e e MTL ait gagn´ la pr´f´rence de la communaut´, car au cours des recherches que nous e ee e avons faites, nous avons trouv´ un plus grand nombre d’auteurs utilisant MTL que e T-LTL.

2.2.3

TRIO

φ ::= ∀xi .φ | p(x1 , . . . , xn ) | ¬φ | φ1 ∨ φ2 | Dist(φ, t)

Tab. 2.18 – Syntaxe de TRIO. σ(i) |= Dist(φ, t) ssi ∃j.σ(j) |= φ et σ2 (j) = σ2 (i) + t Tab. 2.19 – S´mantique de l’op´rateur particulier ` TRIO. e e a

Nous terminons ce chapitre avec une br`ve description de TRIO [69], une logique e temporelle du premier ordre avec quantificateurs. Nous verrons que lorsque l’on dispose de la puissance d’expression de la logique du premier ordre, le nombre d’op´rateurs e temporels dont on a besoin chute rapidement. La syntaxe de TRIO est donn´e ` la table 2.18. Cette logique ne comporte qu’un e a seul op´rateur temporel, Dist, dont la s´mantique est donn´e ` la table 2.19. La formule e e e a Dist(φ, t) est vraie pour les ´tats σ(i) ayant un ´tat situ´ ` une distance t (positive ou e e ea n´gative, finie ou infinie) satisfaisant φ. e Grˆce ` la pr´sence du quantificateur existentiel ∀, l’op´rateur Dist permet d’expria a e e ` mer toutes les relations temporelles de LTL, P-LTL, T-LTL ou MTL. A la table 2.20, on

Chapitre 2. Logiques temporelles

72

φ φ

def

=

Dist(φ, t) ∧ ∀d.Dist(true, d) → d > t Dist(φ, −t) ∧ ∀d.Dist(true, −d) → d > t ∀d.0 ≤ d < t → Dist(φ, d) ∃t.Dist(φ2 , t) ∧ ∃t.Dist(φ2 , −t) ∧
t φ1

def

= = =

def

= =

φ1 U φ2

def def def

∀d.0 ≥ d > −t → Dist(φ, d)
t φ1

φ1 S φ2

Tab. 2.20 – Quelques op´rateurs d´finis de TRIO. e e

voit quelques exemples d’op´rateurs temporels que l’on peut d´finir ` partir de l’op´rae e a e teur Dist. Il est sous-entendu, dans ces d´finitions, que les variables t et d sont positives. e Par exemple, l’op´rateur φ signifie qu’il existe un ´tat situ´ ` une distance positive t e e ea satisfaisant φ, et que tous les ´tats situ´s ` une distance positive sont situ´s plus loin. e e a e Les autres op´rateurs sont d´finis de fa¸on semblable. e e c

2.3

Conclusion

Dans ce chapitre, nous avons donn´ une pr´sentation de sept logiques temporelles e e d´finies ` partir de trois mod`les diff´rents. Le premier choix ` faire, face ` un probl`me e a e e a a e de v´rification, est celui du mod`le. Une fois que celui-ci est choisi, on se penche alors e e sur celui de la logique. Dans les deux chapitres suivants, nous verrons comment le choix du mod`le et de la e logique peut influencer la qualit´ du travail. D’une part, le mod`le choisi doit ` la fois cole e a ler le mieux possible ` la vision que nous avons du probl`me auquel nous nous attaquons, a e et d’autre part, la logique doit comporter des op´rateurs appropri´s non-seulement aux e e propri´t´s v´rifi´es, mais aussi au contexte de la v´rification. Au chapitre 3 comme au ee e e e chapitre 4, le mod`le que nous choisirons est un mod`le du premier ordre. Des hypoe e th`ses diff´rentes sont cependant faites par rapport aux interpr´tations (la fonction I e e e de la table 2.1) faites de chaque ´tat. De plus, la logique utilis´e au chapitre 3 est e e une logique temporis´e, alors que celle du chapitre 4 peut ˆtre temporis´e, mais n’a e e e absolument pas besoin de l’ˆtre pour pouvoir l’utiliser telle que nous la d´crivons. Fie e nalement, la principale diff´rence entre les deux logiques que nous pr´sentons est que e e celle du chapitre 3 dispose d’op´rateurs temporels futurs, alors que celle du chapitre 4 e dispose d’op´rateurs temporels pass´s. Nous verrons que dans un contexte de v´rificae e e

Chapitre 2. Logiques temporelles

73

tion en temps-r´el, une logique d´finie ` partir d’op´rateurs pass´s est non-seulement e e a e e plus intuitive, mais aussi algorithmiquement avantageuse.

en plus de tester la connectivit´ avec un hˆte e o distant. Si.de l’information sur e a e e un r´seau informatique. qui consiste e a en un ensemble de techniques permettant d’acqu´rir de l’information en injectant du e trafic sur le r´seau et en attendant de voir sa r´action. L’hˆte envoyant la e e e o requˆte echo remplit ce champ avec des valeurs arbitraires.Chapitre 3 D´tection d’intrusions et analyse e passive L’analyse passive de r´seaux regroupe un ensemble de techniques heuristiques pere mettant d’acqu´rir passivement . et que rien ne permet de conclure que le paquet echo e e e n’a pas ´t´ intercept´ par un tiers. les valeurs du c a e champ donn´es sont diff´rentes de celles envoy´es au d´part. il faut conclure que la e e e e connection entre les deux hˆtes est de pi`tre qualit´ et que la communication est par o e e cons´quent non-fiable. Le programme ping utilise de fae e e e a ¸on tout ` fait normale le protocole ICMP. Un exemple simple de technique e e d’analyse active est l’utilisation du programme ping. ` laquelle il doit normalement r´pondre en envoyant un paquet de type a e reply.c’est-`-dire sans g´n´rer de trafic . qui permet de savoir si un hˆte o donn´ est branch´ au r´seau et prˆt ` communiquer. e Le protocole ICMP permet aussi. Il est ` noter cependant que le e a a protocole ICMP n’est qu’un protocole de contrˆle. n’ayant aucunement ´t´ con¸u avec o ee c des consid´rations de s´curit´. ` l’arriv´e. de longueur variable et de contenu non-sp´cifi´. de tester la qualit´ de la connection. La r´ception du paquet reply permet. et l’hˆte r´pondant doit e o e recopier les valeurs qu’il a re¸ues dans le paquet reply. de fa¸on g´n´rale. en envoyant ` l’hˆte concern´ une requˆte c a a o e e de type echo. qui pourrait soit avoir bloqu´ le paquet. Pour ce faire. Cette fonctionnalit´ du protocole ICMP permet de l’utiliser afin e e . de conclure que l’hˆte e c e e o distant est en ligne et prˆt ` recevoir de l’information. soit avoir ee e e envoy´ un faux paquet reply. le protocole pr´voit un e e champ donn´es. L’acquisition passive s’oppose ` l’acquisition active.

3. nous concluons en critiquant le syst`me et le langage e e e d´velopp´s en les comparant ` ceux analys´s au chapitre 1.2. des diff´rents protocoles y cire culant. ou du moins une famille de syst`mes d’exploitation. dans la litt´rature. Dans la section 3. permettre de d´couvrir des failles insoup¸onn´es dans le r´seau et d’y r´m´dier avant qu’elles ne e c e e e e soient exploit´es par un utilisateur mal intentionn´. Cette information peut ˆtre utilis´e soit malicieusement par un utilisateur mal e e intentionn´ afin de mieux pr´parer son attaque. nous donnons un aper¸u g´n´ral de la structure logicielle d’un syst`me de d´tection d’intrusions et d’analyse passive que nous avons d´velopp´. le syst`me d’exploie e tation d’un hˆte donn´ s’appelle. nous pr´sentee e e rons une premi`re approche intuitive permettant de mettre ` profit l’analyse passive e a en vue d’am´liorer la d´tection d’intrusions. o` les intrusions ne seront qu’un cas c u particulier d’information ` acqu´rir. nous pr´sentons le langage e e de signatures d’une fa¸on formelle de mˆme que l’algorithme de v´rification en ligne c e e lui ´tant associ´. e e e nous montrons comment le langage peut ˆtre utilis´ pour acqu´rir passivement de l’ine e e formation sur un r´seau informatique. cette information peut e e e e entre autres. En effet.4. e e o e En effet. Dans la section 3. Finalement. D´tection d’intrusions et analyse passive e 75 de d´tecter passivement le syst`me d’exploitation de l’hˆte envoyant la requˆte echo. a e c e e Dans la section 3.1. soit judicieusement par un analyste en e e s´curit´ afin de mieux prot´ger un r´seau informatique. la prise d’empreintes digitales de o e e syst`me d’exploitation (Operating System Fingerprinting) [70. la d´tection d’intrusions sera ici e e e per¸ue comme un cas particulier d’analyse passive.5. en ıtre e e inspectant la valeur de ce champ. e e a e . certains programmeurs peuvent avoir choisi d’envoyer abcdefg. comme le protocole ne sp´cifie aucunement quel doit ˆtre le contenu du champ e e donn´es. nous pr´sentons la syntaxe du langage de signatures du syst`me d´velopp´. Dans e e e e e e e la section 3. alors que d’autres peuvent avoir choisi qwertyu. Dans ce chapitre. normaux ou non. Par exemple. En fait. Dans la section 3. celui-ci est laiss´ ` la fantaisie du programmeur et il est possible de recone e a naˆ le syst`me d’exploitation. L’ensemble des techniques permettant de d´tecter. activement ou passivement. e Il existe ainsi un bon nombre de techniques heuristiques permettant d’acqu´rir de e l’information sur un r´seau informatique simplement en observant les particularit´s e e d’implantation et les comportements.Chapitre 3. nous montrons comment le langage peut ˆtre utilis´ pour e e e d´tecter des sc´narios d’attaque se d´roulant sur plusieurs paquets. 71]. comme nous l’avons vu au chapitre 1 avec le logiciel NeVO.

et celle de Snort (` gauche). en plus de permettre une d´tection e e d’intrusions plus pr´cise. de d´tecter des suites de paquets pouvant ˆtre consid´r´es comme offensives. en plus d’accumuler les connaissances acquises. La base de connaissances. D´tection d’intrusions et analyse passive e 76 Modules d’affichage Base de connaissances Modules d’affichage Module de scénarios Module de détection Module de détection Préprocesseurs Préprocesseurs Module de décodage Module de décodage Libpcap Libpcap Réseau Réseau Fig. 3. e e e a a 3.1 Architecture du syst`me e Nous avons con¸u et implant´ un syst`me de d´tection d’intrusions bas´ sur un lanc e e e e gage simple qui. elle permet aussi de v´rifier des politiques e e de s´curit´ haut niveau.mais utilise un nouvel engin de d´tection permettant. Finalement. e e e e ce qui fait que le syst`me d´velopp´ peut ˆtre vu comme un syst`me ` deux niveaux. e e e e e a avec un engin permettant de d´tecter les suites de paquets. telles que il ne doit y avoir qu’un seul routeur dans le r´seau. Les r`gles d’inf´rence de cette base de connaissances sont sp´cifi´es en Prolog. et un autre permettant d’ine f´rer les connaissances.principalement les pr´processeurs e effectuant un travail de formattage sur les paquets . permet de tenir ` jour et d’utiliser une a base de connaissances en vue d’effectuer une d´tection plus pr´cise. Par exemple. e e e . d’inf´rer de nouvelles connaise sances.Chapitre 3. Ce syst`me r´utie e e e lise une partie de l’architecture logicielle de Snort . en plus de d´tecter les paquets pouvant ˆtre consid´r´s comme e e e ee offensifs.1 – Architecture du syst`me d´velopp´e (` droite). e e ee Nous avons aussi ajout´ ` l’architecture du syst`me une base de connaissances qui e a e permet. il pourrait l’utiliser afin de savoir quels sont les hˆtes du o r´seau offrant le service Telnet. dans le style de LAMBDA. peut ˆtre consult´e directement par l’administrateur r´seau en e e e e cas de besoin.

1 – Syntaxe du langage de signatures. chaque ´tape doit se produire dans un d´lai donn´. dans un premier lieu. e a specification scenario step header filter matchrule op output timeout time timeunit ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= scenario * step ( step timeout )* header filter output * step id : snortsig match : matchrule * id . Comme nous nous situons dans un contexte de d´tection a e d’intrusions au niveau r´seau. 3. identifi´ e e e e dans l’entˆte de l’´tape (non-terminal header ) par son nom ( id ) et par une signature e e Snort ( snortsig ) permettant d’identifier certaines de ses caract´ristiques (par exemple.timestamp + time output * number timeunit sec | hours | days | weeks | years Tab. e e est donn´e ` la table 3.5. | prolog . et dans un second e lieu. la premi`re ´tape n’est pas suivie d’une e e e . e contenir une chaˆ de caract`res donn´e. field op id . Ce d´lai est exprim´ par la clause timeout . La grammaire du langage d´velopp´. En plus des conditions exprim´es par les e r`gles d’appariement. D´tection d’intrusions et analyse passive e 77 3.).Chapitre 3. field . ˆtre un paquet SYN. Une sp´cification (non-terminal specification ) est constitu´e d’un ensemble de sc´e e e narios (non-terminal scenario ) qui doivent ˆtre vus comme des suites d’´tapes (none e terminal step ) ` franchir. Les aspects formels ne sont trait´s qu’` partir de la sece a tion 3. chaque ´tape doit ˆtre vue comme un paquet. de comparer entre elles les valeurs de certains champs (non-terminal field ) des diff´rents paquets constituant le scenario. Comme la notion de d´lai ne peut pas e e e s’appliquer au premier paquet d’un sc´nario. permettant de sp´cie e e e e e fier le d´lai d’attente maximal entre deux ´tapes. de consulter la base de connaissances. sous la forme BNF (Backus Naur Form). on doit ajouter une construction a syntaxique suppl´mentaire permettant de lier ceux-ci entre eux (non-terminal filter ).1. <|≤|>|≥|= output : prolog timeout : id . e Les filtres sont un ensemble de r`gles d’appariement (non-terminal matchrule ) pere mettant. etc. relatif aux e e e e ´tapes pr´c´dentes. Comme les siıne e e e gnatures Snort ne s’appliquent qu’` un seul paquet.2 Langage Nous commen¸ons par pr´senter de fa¸on informelle le langage que nous avons d´c e c e velopp´. de fa¸on ` mettre en ´vidence les objectifs poursuivis et l’intuition derri`re les e c a e e choix que nous avons faits.

Dans l’implantation que nous e proposons. Le symbole field devrait ˆtre d´crit par ´num´ration. bien que non-dommageable pour la vice e a time. Une des difficult´s reli´es ` sa a e e e e e a d´tection rel`ve du fait qu’il peut se faire en utilisant le protocole TCP de fa¸on tout e e c ` fait normale. D´tection d’intrusions et analyse passive e 78 clause timeout . Le mot-cl´ output indique une e instruction qui doit ˆtre transmise telle quelle ` la base de connaissances. sprotoadr d´signent rese pectivement : le type de paquet (requˆte ou r´ponse). dip. fonctionnant a e a e un paquet ` la fois. les adresses mat´rielle et logicielle e e e de la cible de mˆme que celles de la source. car ce langage pere met de traiter et de relier entre elles les connaissances. sport. dport d´signent rese e e pectivement les adresses IP de mˆme que les ports source et destination. shdradr. cette fa¸on de faire ne donne e e e c cependant pas beaucoup de souplesse ` l’usager qui voudrait d´finir lui-mˆme ce qu’il a e e consid`re comme un balayage. ne peut ` la base d´tecter ce type d’attaque. En fait. Cette interaction peut se faire soit ` l’identia fication d’un paquet (dans le cas o` le non-terminal output suit imm´diatement le u e non-terminal filter ). a e . thdradr. une tˆche autrement plus ardue lorsque l’on utilise les pr´processeurs. Pour ce faire. Finalement. passant ainsi a e par dessus le syst`me de r`gles. e a Les symboles snortsig et prolog ne sont pas d´finis car ils r´f`rent ` des langages e ee a existants que nous nous dispenserons de d´crire ` nouveau ici [1. les mots opcode. soit ` l’´coulement d’un d´lai (dans le cas o` le non-terminal a e e u output suit imm´diatement le non-terminal timeout ). Il permet de savoir quels sont les services offerts et de se faire ainsi une e premi`re id´e de l’approche ` utiliser. Bien que tr`s efficace. La syntaxe du e a symbole id est la mˆme que celle d’une variable dans le langage de programmation e C. ` chaque ´tape. il est possible de faire des ajouts ou des a e retraits dans la base de connaissances. par exemple ` l’aide des pr´processeurs. tprotoadr. 72]. Dans le cas e d’un paquet ARP. Nous e c e voyons aussi comment notre approche permet de d´finir rapidement de nouveaux types e de balayages. e Dans cette section.3 Sc´narios d’attaques complexes e Le balayage de ports est souvent une des premi`res ´tapes ` effectuer pour attaquer e e a un syst`me. Par exemple. C’est pourquoi un syst`me ` base de r`gles tel que Snort. les mots sip. le balayage des ports constitue tout de mˆme une attaque en soi car il permet e ` l’attaquant d’acqu´rir des informations privil´gi´es. on a a e doit y aller par programmation. la base de connaissances est programm´e en Prolog.Chapitre 3. Il d´signe explicitement un e e e e e champ d’une entˆte donn´e. nous montrons comment le langage que nous proposons permet de d´finir de fa¸on claire et concise ce que nous consid´rons comme un balayage. e 3.

on enverra sime plement un RST au lieu d’un ACK comme on devrait le faire pour finir d’´tablir la e connection. survenaient ` moins de deux secondes d’intervalle. syn1.) match : syn1.dip)).dport .syn1.2 devrait ˆtre e e a en mesure de d´tecter le comportement malicieux de l’attaquant. comme e e a o e dans le cas de certains serveurs warez qui exploitent des comptes FTP anonymous laiss´s n´gligemment actifs par certains administrateurs r´seau lors de l’installation du e e e syst`me. mais e e o e o faites sur des ports cibles diff´rents. syn2. La m´thode de balayage TCP connect() est sans doute la plus r´pandue et la plus e e facile. e e Par exemple. de mˆme que le d´lai de deux secondes.dport .dport !=syn2. e e e Dans un cas comme dans l’autre. Dans ce cas. syn1.dip=syn3. En fait.dip . Fig. Elle sp´cifie que si trois e e demandes de connection.) step syn2 : tcp any any -> any any (flags :S . en cas de r´ception d’un SYN-ACK. L’important ici est de remarquer qu’une modification e mineure du fichier de signatures permet d’ajuster rapidement notre politique de s´curit´. il faut faire un compromis entre la possibilit´ de faux n´gatifs e e et l’engorgement de la m´moire. Certains attaquants peuvent en effet ne pas ˆtre e e int´ress´s ` attaquer une machine en particulier. syn1. La limite de trois connections. on privil´giera une m´thode plus subtile.Chapitre 3. Bien que pr´sentant certains avantages e e e de rapiditi´ et de simplicit´.timestamp + 2sec .dport .dip=syn2.syn1. 3. la politique ne sera pas d’interdire la connection sur diff´rents e e . la signature montr´e ` la figure 3. syn1.sip. sont tout ` e e a fait arbitraires. Pour ´viter ce dernier e probl`me. timeout : syn1. L’attaquant n’a qu’` effectuer une tentative de connection sur le port cible et a simplement v´rifier si elle est accept´e ou pas.dport !=syn3. cette m´thode n’est cependant pas ` privil´gier car elle se e e e a e e d´tecte assez facilement par consultation des fichiers de log [7].sip=syn2. Le syst`me ne gardera ainsi g´n´ralement pas trace de la connection.) match : syn1.dport !=syn3.sip .2 – Balayage SYN. Dans un balayage SYN. e a il faudrait alors ajouter ` la base de connaissances qu’une attaque de portscan vient a d’avoir lieu.dip .sip=syn3.timestamp + 2sec .sip . D´tection d’intrusions et analyse passive e 79 step syn1 : tcp any any -> any any (flags :S . dans les situations o` l’attaquant voudra balayer u e plusieurs ports sur une mˆme machine. output : assert(alert(portscan. comme par exemple le balayage e e e SYN. step syn3 : tcp any any -> any any (flags :S . address´es au mˆme hˆte et provenant du mˆme hˆte. mais plutˆt un service donn´. timeout : syn2. on peut modifier la signature pr´c´dente afin de red´finir la notion de e e e balayage de ports au niveau r´seau.

mais plutˆt sur le mˆme port de diff´rents hˆtes. Cependant. e e e Encore une fois. on sera plutˆt int´ress´ ` d´duire le maximum d’information o e ea e du trafic (normal aussi bien que malicieux) que l’on voit circuler sur le r´seau. (2) qu’un utilisateur ait re¸u par e e c courriel un virus ayant pour effet de d´marrer un serveur illicite (cheval de Troie).Chapitre 3. on peut la consid´rer comme une g´n´ralisation de la d´tection c e e e e d’intrusions au niveau r´seau. D´tection d’intrusions et analyse passive e ports du mˆme hˆte. Cette e information peut concerner autant la configuration des hˆtes que l’activit´ se d´roulant o e e en g´n´ral sur le r´seau. on est seulement int´ress´ ` e e e ea savoir si oui ou non un certain type de comportement. En effet.4 Acquisition passive d’information Comme nous l’avons d´j` dit. maximiser le plus e e e possible la lisibilit´ et la r´utilisation. consid´r´ comme malicieux. e o o e e o 80 De la mˆme fa¸on. il ne faut pas ea e perdre de vue que l’id´e ici est de se munir d’un langage de sp´cification qui soit assez e e g´n´ral pour : minimiser le plus possible le temps de d´veloppement. suree vient. par exemple ` la sortie du routeur principal. constituent un o e exemple simple mais important d’information qu’il est int´ressant d’acqu´rir de fa¸on e e c passive.4. En analyse passive. via la base de connaissances. on pourrait aussi d´finir un balayage Ping comme ´tant une e c e e certaine quantit´ de requˆtes ICMP echo provenant du mˆme hˆte vers des hˆtes e e e o o diff´rents dans un court laps de temps. e 3. 3. on ne peut pas toujours se fier ` la fa¸on dont l’on croit avoir configur´ a c e les hˆtes de notre r´seau. En d´tection d’intrusions. dans le cas de Snort. Par exemple. et cela pour plusieurs raisons. et permettre un maximum de corr´lation entre e e e les composantes. comme par exemple les sessions TCP actives.1 Ports TCP ouverts et sessions actives Les ports TCP ouverts des hˆtes. chacune des techniques mentionn´es dans cette section peut se faire e aussi par programmation. Il se peut (1) qu’un utilisateur o e malveillant ou insouciant ait lui-mˆme install´ une application qui va ` l’encontre de e e a nos politiques de s´curit´. l’analyse passive regroupe un ensemble de techniques ea permettant d’acqu´rir de l’information sur un r´seau seulement en ´coutant le trafic e e e circulant ` quelques endroits strat´giques. de mˆme que leurs sessions actives. (3) e . la d´tection des sessions e actives est d´j` prise en compte par le pr´processeur Flow. comme par exemple Kazaa. a e a D’une certaine fa¸on.

syn.dip . output : assert(port(syn. D´tection d’intrusions et analyse passive e 81 step syn : tcp any any -> any any (flags :S .sport)).sport .sip .sip. Fig.dip.sport.) step synack : tcp any any -> any any (flags :SA .dport)).rst.rst.sport .sip)).dport)). assert(session(syn. syn.dip. timeout : syn. . step ack : tcp any any -> any any (flags :A .sip. timeout : synack. syn.dip.sport."open")).) match : syn.dport.sip.fin.syn.syn. syn.) output : retract(session(rst. output : assert(alert("syncan".timestamp+2sec .syn.sip=rst.syn.sip .sip .dip=synack. output : assert(session(syn.dport)).rst. Fig.sport=synack.dip. e step fin : tcp any any -> any any (flags :F .fin.dip=rst.dport. syn.sport)).dip.dport .sport.sport .dport.dip .Chapitre 3.dip=ack. syn.dport=rst.fin. output : retract(session(fin.syn.dip)). 3. syn.timestamp+2sec .5 – Fermeture d’une session TCP.sip=synack.dport .closed)).rst. syn.sip.dport.sport. output : retract(session(rst. syn. 3.dport .sip.sip.dip .dport=ack. timeout : syn.sport=ack. Fig.sip. output : assert(port(syn. assert(alert("finscan".timestamp+2sec . 3. e step syn : tcp any any -> any any (flags :S .syn.) match : syn.dip. step rst : tcp any any -> any any (flags :R .sport=rst.dport=synack.dport)).fin.fin.syn.fin.) match : syn.) step rst : tcp any any -> any any (rst :R .) output : not(session(fin.3 – Poign´e de main TCP.rst.rst.syn.sip=ack.dip.fin.dip. syn.4 – Ports TCP ferm´s.syn.

Aussi.4. On remarque que l’ajout. lors de la r´ception de confirmation. c’est cependant le RST. Dans ce cas. Lorsque les demandes sont accept´es par le ae e serveur. la m´thode de balayage FIN est encore plus subtile que e celles pr´c´demment mentionn´es. D´tection d’intrusions et analyse passive e 82 qu’un visiteur avec un ordinateur portable.5 implante ces techniques d’acquisition. les deux sens de la connection sont ferm´s en mˆme temps. et il faudra attendre l’envoi d’un autre paquet FIN pour fermer l’autre direction. on peut voir comment notre langage supporte ces techniques d’acquisition d’information.Chapitre 3. que l’on peut conclure que e e r´ellement il y a une connection en cours. Il s’agit d’envoyer un paquet de fin de connection e e e sans en avoir ´tablie auparavant. e e Pour d´couvrir passivement quels sont les ports TCP ouverts sur nos hˆtes. alors que celui d’un port ferm´ sera d’envoyer un paquet RST. La connection sera alors ferm´e e o e dans une direction.2 Ports TCP ferm´s e Pour d´tecter quels sont les ports TCP ferm´s. qui nous permettra de conclure. Le sc´nario correspondant ` cette e a technique se trouve ` la figure 3. A la figure 3. dans la base de connaissances. . ne respecte pas o notre politique de s´curit´.3. la technique est relativement seme e blable ` celle utlis´e pour les ports ouverts. a 3. Ce n’est cependant qu’` la troisi`me a e ´tape de la connection. il e e ne faut pas oublier que certaines connections peuvent aussi se terminer par un RST. on peut conclure que le port est ouvert. e e e 3.4. de l’attaque synscan se fait apr`s l’´coulement du d´lai (timeout). Le comportement normal d’un port ouvert est de ne e pas r´pondre. Dans le cas o` cette confirmation n’a pas e u ` lieu. il faut signaler u une alerte de finscan. il y a fortement lieu de penser qu’une attaque de type synscan est en cours.4. Le sc´nario de e e e la figure 3. Pour la consid´rer comme ´tant termin´e.3 Sessions ferm´es et balayage FIN e Nous venons de montrer comment il est possible de d´tecter qu’une session est e active entre deux hˆtes. Dans ce cas-ci. il faut attendre o e e e qu’un paquet FIN soit envoy´ par un des deux hˆtes. on n’a e o qu’` ´couter les demandes de connection. Dans le cas o` il n’y avait aucune connection active. En effet. au a e lieu du SYN-ACK. en dehors de notre contrˆle.

3. e e ` A la figure 3.3")). on montre comment on peut d´tecter.dip. window :12) match : syn. Fig. syn.dport=synack.dip . Le logiciel nmap [71] utilise huit tests actifs (g´n´rant du trafic) diff´rents pere mettant de diff´rencier plus de 500 syst`mes d’exploitation diff´rents.sip . e e a 3. ` l’aide du langage que nous e a avons d´velopp´. syn.dip. tcpopts :MTW) step synack : tcp any any -> any any (flags :SA . Par e ee e e exemple. syn. un syst`me d’exploitation FreeBSD.sport=synack. e e e tels que POF [70] (pour Passive OS Fingerprinting) utilisent des tests comparables dans un contexte passif (ne g´n´rant pas de trafic).dip=synack.0 ` 4. Les tests utilis´s par POF fonctionnent e e e tous sur la base d’un unique paquet. la plupart des attaques utilisent des vuln´rabilit´s connues de certains e e syst`mes.6.dport . "Free BSD 3. "FreeBSD 4.sip=synack.. ne profitant ainsi pas de l’information contextuelle permettant d’effectuer une d´tection plus pr´cise. output :assert(os(syn. La deuxi`me ´tape du sc´nario (le SYN-ACK) est e e e . tcpopts :M . timeout : syn. 3. D´tection d’intrusions et analyse passive e 83 step syn : tcp any any -> any any (flags :S . assert(os(syn. assert(os(syn. . La connaissance de la pr´sence ´ventuelle de ces vuln´rabilit´s peut alors pere e e e e mettre de diminuer le nombre de faux-positifs en v´rifiant que le syst`me attaqu´ est e e e bel et bien vuln´rable ` l’attaque identifi´e.6 – D´tection d’un syst`me d’exploitation FreeBSD 3. ttl :64 .1")). Cette signature a ´t´ r´dig´e ` e e e ee e e a partir d’une base de donn´es de signatures [73] ayant ´t´ mise au point au Centre de e ee Recherches sur les Communications. e a e La prise d’empreintes de syst`mes d’exploitation regroupe un ensemble de techniques e exploitant les diff´rences entre les diff´rentes implantations de la suite de protocoles e e TCP/IP dans le but d’identifier le syst`me d’exploitation des machines connect´es ` un e e a e e e r´seau.timestamp + 2sec .dip. D’autres logiciels. "FreeBSD 3.4..Chapitre 3. e Par exemple.4 Vuln´rabilit´s et syst`mes d’exploitation e e e La prise en compte du contexte dans lequel survient une attaque permet de diminuer le nombre de faux-positifs g´n´r´s par un syst`me de d´tection d’intrusions. dans le cas de Snort.sport . La prise en compte du contexte e peut cependant aller beaucoup plus loin que la simple v´rification des sessions TCP.0")). l’ajout du pr´processeur Flow a permis de diminuer e le nombre de faux-positifs en sp´cifiant que certains attaques doivent survenir dans e le contexte d’une session TCP active pour r´ussir.

e e e e lorsque le SYN-ACK est envoy´ en r´ponse au SYN correspondant ` la premi`re ´tape. 3. on peut d´ıt e duire son adresse IP en regardant les r´ponses aux requˆtes ARP qui lui sont adress´es.exploit. e a e e e un paquet pouvant ˆtre envoy´ par 27 syst`mes d’exploitation diff´rents. exploit. e e a e e seulement 11 des 27 syst`mes d’exploitation continuent d’envoyer ce SYN-ACK. mais e des adresses IP source diff´rentes. 3. Cette vuln´rabilit´ est r´f´renci´e (entre autres) par e e e ee e l’organisme Bugtraq [74] par le num´ro 1387.dip. On voit aussi comment on peut replacer e l’utilisation du pr´processeur Flow pour v´rifier la pr´sence d’une session TCP active.) match : session(exploit. e ` e e A la figure 3.sip. flow :to_server.dip.9. e e step exploit : tcp any any -> any 21 (content :"1|C0|PPP|B0| |CD 80|1|DB|1|C0|" . Cependant. "Free BSD 4. on e peut savoir quelles sont les versions de FreeBSD qui sont vuln´rables ` cette attaque. d’utiliser la connaissance a que nous avons du syst`me d’exploitation de la machine attaqu´e pour v´rifier s’il e e e est vraisemblable que l’attaque ait r´ussi.8.established . Fig. se trouve une version simplifi´e d’une r`gle Snort permettant de d´tecter une tentative d’exploiter une vuln´rabilit´ du serveur FTP de certaines versions e e e du syst`me d’exploitation FreeBSD. output :assert(alert("FTP EXPLOIT". reference :bugtraq.5 Adresses du routeur Lorsque l’on voit passer plusieurs paquets ayant la mˆme adresse MAC source. e e e Ces techniques sont illustr´es ` la figure 3. os(exploit.exploit. Le e langage que nous avons d´velopp´ permet donc une d´tection de syst`me d’exploitation e e e e plus pr´cise que celle faite par les outils n’utilisant qu’un seul paquet.sip. exploit.8 – R´duction des faux-positifs ` l’aide de la d´tection de vuln´rabilit´s. e a .) Fig.sid :343 .3") .1387 . D´tection d’intrusions et analyse passive e 84 alert tcp any any -> any 21 (msg :"FTP EXPLOIT wu-ftpd 2. on peut conclure que l’hˆte ayant cette adresse MAC e o agit comme routeur. e e e 3.0 site exec format string overflow FreeBSD" .Chapitre 3. Une fois que l’on connaˆ l’adresse MAC du routeur.7.sport. e a Il est alors possible. content :"1|C0|PPP|B0| |CD 80|1|DB|1|C0|" . En consultant le site web de Bugtraq.6.7 – R`gle Snort num´ro 343.4.dip)).dport) . comme on le montre ` la figure 3.exploit.

smac)). Par la suite. output : assert(gatewaymac(anyip1. d’utliser les e e ee r´ponses aux requˆtes ARP pour emmagasiner les associations entre les adresses IP et e e les adresses MAC.10 est ´crite en Prolog. comme c’est u a e e le cas lorsque l’on doit utiliser le peu d’information qui se trouve dans un paquet donn´.timestamp + 10sec .) match : gatewaymac(arpreply.sip !=anyip2.ip). anyip1. step arpreply : arp any any -> any any (opcode=2 .gatewaymac(X). et que la e machine ayant l’adresse IP Y a l’adresse MAC X.4.6 Inf´rence de nouvelles connaissances e L’exemple que nous venons tout juste de voir est g´n´ralisable. 3.) output : assert(macip(arpreply.smac=anyip3.smac=anyip2.sip . Il s’agit presque d’une lapalissade.smac .sip !=anyip3. anyip2.sip . C’est pourquoi. Fig.arpreply. On peut le formuler e e ainsi : si on sait que la machine ayant l’adresse MAC X a la caract´ristique c. gatewayip(ip) :. step arpreply : arp (opcode=2 . timeout : anyip1. D´tection d’intrusions et analyse passive e 85 step anyip1 : ip any any -> any any step anyip2 : ip any any -> any any match : anyip1. timeout : anyip2. par exemple. on peut d´finir l’adresse IP d’un routeur comme ´tant une adresse IP e e associ´e ` l’adresse MAC d’un routeur.9 – Adresses du routeur. Fig. au lieu de la r`gle que nous avons d´finie ci-haut. step anyip3 : ip any any -> any any match : anyip1.macip(X. e 3.tprotoadr)).timestamp + 10sec . il serait pr´f´rable.10 – Inf´rence de nouvelles connaissances. e e . mais dans un contexte e o` l’on a besoin de rechercher de l’information ` partir de diff´rentes cl´s. output : assert(gatewayip(arpreply.Chapitre 3. et c’est pourquoi la derni`re ligne de la figure 3.smac) .tprotoadr)). Cette inf´rence est faite au niveau de la base de e a e connaissances. anyip1.sip !=anyip3.thdradr. e il est souhaitable d’avoir le plus de transparence possible. alors la machine ayant l’adresse IP Y a aussi la caract´ristique c. 3.sip .smac .

nous allons voir comment il est possible d’en faire e e une ´tude formelle ` l’aide des notions que nous avons vues au chapitre 1. dans une optique o` on veut e a e u en inf´rer de nouvelles. on voit que cette r`gle d’inf´rence n’est pas encore assez g´n´rale. et (2) le temps est toujours a e . D´tection d’intrusions et analyse passive e 86 et non dans notre langage de signatures. Le concept d’enregistrement se distingue de celui d’´tat. Avec la signature de la figure 3. Cependant. sa s´mantique. qui consiste en un sous-ensemble d’un e e ensemble de constantes propositionnelles P . Quatre aspects du e e a langage seront donc trait´s dans cette section. et son algorithme de v´rification. Il s’agit essentiellement du mˆme mod`le que celui a e e utilis´ par ASAX et LogWeaver.9. et de le critiquer en regard des crit`res dont nous avons donn´ la liste ` la table 1. sa e e syntaxe. En effet. est g´n´ralisable e e e ` celui de trace d’enregistrements. et ainsi de comparer les valeurs associ´es aux ´tiquettes de diff´rents ´tats. est une ´tape tr`s importante et qui. la seconde signature de la e e a figure 3. e e e l’ordre dans lequel les deux connaissances sont acquises n’a pas d’importance. e Notre mod`le se distingue cependant de ceux de ASAX et LogWeaver par deux e hypoth`ses importantes que nous faisons relativement au temps : (1) il est toujours e possible d’associer un temps ` un enregistrement donn´. Comme on le voit.Chapitre 3.1 Mod`le e Le mod`le sur lequel nous travaillons. e e a 3.9.5. e e 3. en fait.9 implique que la d´tection de l’adresse MAC du routeur doit ˆtre faite avant e e de d´tecter quelle est l’adresse IP lui ´tant associ´e. e e utilis´ par exemple avec LTL. constitue en soi un e e e d´fi s´rieux ` relever. Cette signature consitue une version am´lior´e e e de la seconde signature pr´sent´e ` la figure 3.5 Pr´sentation formelle du langage e Maintenant que nous avons une meilleure intuition des objectifs poursuivis par le langage que nous avons d´velopp´. de par le fait qu’il permet d’associer des valeurs ` des e a ´tiquettes. Cette ´tude e a e nous permettra de mieux percevoir les limites de notre langage. la comparaison entre les diff´rents ´tats se e e fait beaucoup moins naturellement (bien que th´oriquement possible).10. soit le mod`le sur lequel il travaille. la struce turation et la repr´sentation de l’information ` acqu´rir. celui d’une trace de trafic. car il e e e e faudrait la red´finir pour chacun des types d’information. e e e e e Avec le concept d’´tat traditionnellement utilis´.

0.168.0.168. c’est-`-dire e c a a que ∀i.168.168. et le sc´nario e e u e e ψ1 ∧ ψ2 est celui o` les sc´narios ψ1 et ψ2 surviennent tous les deux..9 7.112 . croissant.0.100 192.0. la deuxi`me le temps qui lui est associ´. Il s’agit essentiellement e a du calcul propositionnel..1 Un enregistrement est une fonction dont le domaine est un ensemble e d’´tiquettes. sauf que les constantes p (que nous appellerons d´sormais e .114 .0.109 192. D´tection d’intrusions et analyse passive e 87 i 0 1 2 3 4 5 .168.0.. Le sc´nario ¬ψ est celui o` le sc´nario ψ ne survient pas..168. La premi`re colonne repr´sente l’index de l’enregistrement. La premi`re partie a de la syntaxe permet d’exprimer des sc´narios comme des s´quences d’´v´nements.7 .5.168.101 192. 3... ack 0 1 1 0 1 0 .11.0. et les deux derni`res repr´sentent les e e drapeaux syn et ack.5 9. φ t ψ d´bute par un paquet id ayant la caract´ristique φ. les quatre suivantes e e les adresses et les ports source et destination. repr´sente le temps. Fig..0 7. tcpdport 23 45678 23 21 56789 34567 .168.Chapitre 3.2.109 192. ` e e A la figure 3. on d´signe le ieme enregistrement.101 192. sip 192. e 3..100 192. τ 2.0 3.. Une trace e e e σ est une suite infinie d’enregistrements.0.τ . et e i par σ .168. e e mais ceux-ci sont suffisants pour l’´tude des exemples qui suivent.. Par σ(i).. et dont le codomaine est un ensemble de valeurs e e num´riques (par exemple N). dip 192. τ .11 – Exemple de trace.108 192..108 192..168. Le temps est croissant. on d´signe le suffixe de σ commen¸ant ` σ(i).σ(i). c’est-`-dire que les enregistrements se situent dans la trace dans le mˆme a e ordre que celui des ´v´nements qu’ils repr´sentent.0.5 4. aussi appel´es champs. on peut voir un exemple de trace.100 192.0.0. En r´alit´. Le e e e e sc´nario le plus simple est celui o` il ne se passe rien de sp´cial (tt).τ < σ(i + 1).0.168.2 Syntaxe e La syntaxe abstraite de notre langage se trouve ` la table 3. et se poursuit par le e e sc´nario ψ. La deuxi`me partie u e e de la syntaxe concerne les caract´ristiques propres ` un paquet.101 192.. syn 1 1 0 1 1 0 . tcpsport 45678 23 45678 56789 21 22 . un paquet peut contenir beaucoup plus de champs.168. Ces id´es se formalisent donc dans e e e e la d´finition suivante : e D´finition 3. Une de ces ´tiquettes... Le sc´nario e u e e id.

e e e e On la retrouvera donc au niveau de l’algorithme de v´rification du langage.sip ∧syn.dport ∧ syn. mais elle e n’est pas directement traductible en logique temporelle. ee e comme ils jouent un rˆle crucial dans l’algorithme de v´rification en ligne que nous o e pr´senterons plus loin.. φ2 ack.sport ∧ syn. exception faite des clauses output :. φ1 avec φ1 := φ2 := φ3 := snort(”tcp (flags :S .dport = ack.2 – Syntaxe. dont les caract´ristiques sont e donn´es par les formules φ1 .)”) ∧syn.12. expressions) peuvent. remarquons que les op´rateurs temporels que nous utilisons e constituent des cas particuliers de ceux utilis´s avec MTL. on peut voir comment le sc´nario repr´sentant une poign´e de e e e main TCP.)”) ∧syn. nous avons jug´ bon de sp´cifier ceux-ci au niveau mˆme de e e e e la syntaxe. Il s’agit d’une suite de trois enregistrements.τ +2sec tt ∞ syn. Finalement. contenir des variables faisant r´f´rence aux ee diff´rents champs des enregistrements consituant les sc´narios. Un d´lai peut ˆtre relatif ` un ´v´nement id pass´ e e e a e e e (id. D´tection d’intrusions et analyse passive e 88 ψ φ t ::= tt | id. On remarque que chacun des ´l´ments du sc´nario ont ´t´ traduits ee e ee dans la formule. 3. Cependant..τ + δ | ∞ (Formules pour traces) (Formules pour paquets) (D´lais) e Tab.τ +2sec Fig. car il aurait ´t´ possible de les repr´senter par une expression p. e syn.dip ∧syn.12 – Formule repr´sentant une poign´e de main TCP. et non d´clarative. La formule snort(sig) s’´value ` vrai pour σ(i) si et e e a seulement si l’engin de d´tection de Snort ´value ` vrai la signature sig dans le contexte e e a du paquet σ(i). φ2 et φ3 . comme nous le verrons.)”) snort(”tcp (flags :SA .dip = synack. . ´tudi´ plus tˆt dans le pr´sent chapitre.dip ∧ syn.sport = ack. φ3 synack. 3. D’un point de vue expressivit´.dport synack.dip = ack.sport = synack. Ceci est dˆ au fait que la u s´mantique de cette partie des sc´narios est de nature imp´rative. φ t ψ | ¬ψ | ψ1 ∧ ψ2 ::= p | ¬φ | φ1 ∧ φ2 ::= id.τ + δ).dport = synack.. La troisi`me partie de la e e e syntaxe permet d’exprimer des d´lais. ou infini (∞).sip ∧ syn.sip = ack.Chapitre 3. e e ` A la figure 3. se traduit dans la syntaxe abstraite e e o e du langage.sip = synack.sport snort(”tcp (flags :A . l’ajout de ces d´lais n’apporte e e rien.

apr`s substitution de syn par σ(0).dip. les e formules de paquet φ1 . une formule de paquets φ. avant que le d´lai t ne soit ´coul´. Le cas int´ressant est e a e celui d’une expression p. et ´value l’expression obtenue en e e fonction des op´rateurs (par exemple. un paquet σ(i) qui. satisfait la formule ψ dans laquelle toutes a les occurrences de la variable id sont aussi substitu´es par σ(i). σ i+1 . Toute trace satisfait la formule tt. Comme cette expression contient des variables s’identifiant ` a des paquets.τ <Eval(t) et Eval(φ[σ(i). Elle satisfait la formule ψ1 ∧ ψ2 si elle satisfait ` la fois ψ1 et ψ2 .5. des op´rateurs de comparaison) de l’expression.sip = synack. e e e et l’´valuation d’une conjonction de formules retourne la conjonction de l’´valuation de e e ces formules.faux} ¬Eval(φ) Eval(φ1 )∧Eval(φ2 ) Tab. φ2 et φ3 deviennent : .n. Une trace σ satisfait la formule id. e 3.n/id] ssi σ |= ψ ssi σ |= ψ1 et σ |= ψ2 ∈ = = {vrai.12 e a car. comme par exemple syn. Une trace satisfait la e formule ¬ψ si elle ne satisfait pas la formule ψ. L’´valuation e e de la n´gation d’une formule retourne la valeur oppos´e de l’´valuation de cette formule. D´tection d’intrusions et analyse passive e 89 σ |= tt σ |= id.n/id]) =vrai et σ i+1 |= ψ[σ(i). 3.3.3 – S´mantique. ` l’aide de la fonction Eval. φ t ψ si elle admet. φ t ψ σ |= ¬ψ σ |= ψ1 ∧ ψ2 Eval(p) Eval(¬φ) Eval (φ1 ∧ φ2 ) ssi ∃i. la fonction Eval substitue les variables par les valeurs contenues dans le mod`le.3 S´mantique e La s´mantique du langage est donn´e ` la table 3.n (le nom de σ(i)) satisfait φ. Par exemple. de synack par σ(1) et de ack par σ(2).Chapitre 3. une fois substitu´es e e e e toutes les occurrences de la variable id par σ(i).σ(i). a Les trois derni`res r`gles ´tendent la relation de satisfiabilit´ pour pr´ciser comment e e e e e ´valuer. la trace montr´e ` la figure 3. Les quatres premi`res r`gles e e a e e d´finissent la r`gle de satisfiabilit´ qui pr´cise quand est-ce qu’une trace σ satisfait une e e e e formule ψ. et que le reste de la trace ` partir de ce paquet.11 satisfait la formule de la figure 3. e e Les cas de la n´gation et de la conjonction se traitent comme d’habitude.

100 = 192.168. Etant donn´ un fichier contenant plusieurs signatures.5. On compose ene e suite les sc´narios plus complexes en leur ajoutant des ´tapes pr´alables ( id.0. φ t tt) ou ne survient pas (¬ id.0.4 – Syntaxe du sous-ensemble associ´ au langage de signatures.101 ∧ 45678 = 45678 ∧ 23 = 23 3. Les deux sc´narios de base sont ceux o` un paquet donn´ survient e u e ( id.4. e Les variables id correspondent aux ´l´ments id du langage de sc´narios identifiant ee e les diff´rentes ´tapes. C’est cette sp´cification que l’on donnera en entr´e ` l’algorithme de e e e a v´rification.0.168.168. φ t tt). Les clauses output ne correspondent ` rien dans le langage abstrait.0. e Le langage de sc´narios que nous avons d´crit ` la section 3.2 ne permet pas de e e a repr´senter toutes les formules du langage abstrait que nous venons de d´finir.4.4 Algorithme ψ φ t ::= id. e D´finition 3. e a . de repr´senter une conjonction de a e e sc´narios ou encore l’absence de toute une suite de paquets.2 Une sp´cification est un ensemble de couples de la forme ψ ⇒ act . φ t tt) avant un d´lai t donn´. φ t tt | ¬ id.168. Plus e e pr´cis´ment.101 = 192. il permet seulement de repr´senter le sous-ensemble engendr´ par la syne e e e taxe de la table 3. ` l’aide du langage de sc´narios. 3. D´tection d’intrusions et analyse passive e 90 φ1 := φ2 := φ3 := snort(”tcp (flags :S . φ t ψ). et act est une action u e repr´sentant l’ajout ou le retrait d’une information dans la base de connaissances.100 ∧192.Chapitre 3.0. φ t tt | id.168. nous g´n´rons ee e e e e une sp´cification. Il e e e n’est pas possible. Les formules de paquets φ correspondent aux clauses match. e e o` ψ est une formule engendr´e par la syntaxe de la table 3.101 ∧ 45678 = 45678 ∧ 23 = 23 snort(”tcp (flags :A .100 ∧192. φ t ψ ::= p | ¬φ | φ1 ∧ φ2 ::= id. en nous disant e quelles sont les actions qui doivent ˆtre pos´es lorsque l’occurrence d’un sc´nario donn´ e e e e ´ a ´t´ identifi´e. a Elles interviennent seulement au niveau de l’algorithme de v´rification.101 = 192.τ + δ | ∞ (Formules pour traces) (Formules pour paquets) (D´lais) e Tab. Cette e action est pos´e ` chaque fois que l’on se rend compte que ψ est satisfaite par la trace.100 = 192. et la pr´sence d’une clause output apr`s e e e e une clause timeout indique que le sc´nario de base utilis´ est l’absence d’un paquet e e (¬ id.0.0.0.168.168.)”) ∧192.)”) snort(”tcp (flags :SA .)”) ∧192. φ t tt).168. La e e pr´sence d’une clause output apr`s une clause match indique que le sc´nario de base e e e utilis´ est la pr´sence d’un paquet ( id.

.)”) snort(”tcp (flags :SA .sport. φ3 synack.sport snort(”tcp (flags :A .dip. e a e e e La substitution textuelle.τ +2sec ack. pour une trace et une sp´cification donn´es. syn.sip ∧ syn. ` A la figure 3.11 (page 87) et la sp´cification est e e .sip.0.sport ∧ syn. mais comme la reconnaissance des enregistrements ` la tˆte des sc´e a e e narios entraˆ la duplication de ceux-ci (comme dans le cas des actions non-consuming ıne de STAT) la taille de l’ensemble augmente en cours de route. .)”) ∧syn. syn. syn. . e Au d´but. ”open”)) syn. D´tection d’intrusions et analyse passive e 91 syn. on peut voir un exemple de trace d’ex´cution de l’algorithme dans e le cas ou la trace utilis´e est celle de la figure 3.100.τ +2sec tt ⇒ assert(alert(”syncan”.8.dip.).sip = ack. φ1 ∞ synack. comme sp´cifi´ par la s´mantique. e e e page 81) donne les trois couples que nous pouvons voir ` la figure 3.sip. ` mesure que les ´tapes sont reconnues. l’action a assert(session(syn. 3. Par exemple.sip = synack.) se transforme ainsi en assert(session(192. Les op´rateurs + et − repr´sentent l’ajout et le retrait d’un ´l´ment a d’un ensemble.Chapitre 3. Par exemple. syn.τ +2sec ¬ ack.sip.168.dip = ack.τ +2sec tt ⇒ assert(port(syn. φ2 syn.dport)).dip ∧ syn. le nombre de sc´narios ` reconnaˆ est donc ´gal au nombre d’´l´ments e e a ıtre e ee de la sp´cification. 12 et 16). .dip = synack.sip ∧syn.14. Les ´l´ments de e sont ee cependant retir´s ` mesure que les d´lais sont ´coul´s (lignes 8. syn. est appliqu´e a e e non-seulement au reste de la formule.dip ∧syn.3. syn.)”) ∧syn.sport)) syn.sport = synack.dport = ack. L’ensemble k repr´sente la base de connaissances.dport. le sc´nario repr´sentant l’´tablissement d’une session TCP (figure 3. et e l’ensemble des e sc´narios ` reconnaˆ e a ıtre. φ1 ∞ synack. mais aussi e e e aux actions ` prendre lors de la reconnaissance (lignes 9 et 13). syn.dip)) avec φ1 := φ2 := φ3 := snort(”tcp (flags :S .dport ∧ syn. syn.τ +2sec tt ⇒ assert(session(syn. φ3 synack. φ2 syn. a L’algorithme de v´rification. Ce dernier ´volue ` mesure que les pr´fixes des formules φ de e a e la sp´cification originale sont reconnus. φ2 syn.dport. . .13.13 – Sp´cification associ´e au sc´nario d’une poign´e de main TCP. assert(session(syn. syn. e e e e Il est ` noter qu’` un sc´nario donn´ peuvent correspondre plusieurs couples ψ ⇒ a a e e act .dport Fig.dip. est montr´ e e e e e e ee ` la table 4.sip.sport = ack.dport = synack. φ1 ∞ synack.

D´tection d’intrusions et analyse passive e 92 01. k. si s.spec) e 21. e := e 30.proc´dure verif(ψ. φ t ψ1 : 16. s.τ >Eval(t) alors e := e − ψ ⇒ act 17. pour i allant de 0 ` |σ| a 29. e : un ensemble 04. e := e − ψ ⇒ act 13. pour chaque ψ ⇒ act ∈ e 31. k : la base de connaissances. verif(ψ. si s.d´but e 06. e) e 02. 20.d´but e 24. e ) 32. e .τ >Eval(t) alors 12.τ >Eval(t) alors e := e − ψ ⇒ act 09.cas ¬ id. e a 03.fin Tab. φ t tt : 08.proc´dure moniteur(σ. act.fin 19. act : une action ` prendre.entr´es : ψ : une formule. spec : une sp´cification e e 22. 3.sortie : k : la connaissance acquise ` partir de σ a 23.cas id.cas id. φ t tt : 11. s : un enregistrement. σ(i). si s. sinon si ¬Evalk (φ[s/id]) alors e := e − ψ ⇒ act 15. act.selon la forme de φ : 07.Chapitre 3. e := ∅ 26.sorties : k : la connaissance mise ` jour. sinon si Evalk (φ[s/id]) alors k := act[s/id](k) 10. e := e + ψ ⇒ act 28. pour chaque ψ ⇒ act ∈ spec 27. k := act(k) 14.entr´es : σ : une trace. k := ∅ 25. sinon si Evalk (φ[s/id]) alors e := e + ψ1 [s/id] ⇒ act[s/id] 18. e : l’ensemble des sc´narios mis ` jour a e a 05. k.5 – Algorithme de v´rification.

Chapitre 3. D´tection d’intrusions et analyse passive e

93

i 0 1 2 3 4 5 ...

actions pos´es e assert(port(192.168.0.101, 23, ”open”)) assert(session(192.168.0.100, 192.168.0.101, 45678, 23)), assert(session(192.168.0.101, 192.168.0.100, 23, 45678)) assert(port(192.168.0.108, 21, ”open”)) assert(alert(”syncan”, 192.168.0.108, 192.168.0.109)) ... Fig. 3.14 – Exemple de trace d’ex´cution de l’algorithme. e

|e| 6 8 4 6 8 3 ...

celle de la figure 3.13. Dans la colonne du centre sont affich´es les actions pos´es sur e e la base de connaissances pendant le traitement de chaque paquet, et dans celle de droite le nombre de sc´narios en cours de reconnaissance. Au paquet 0, une demande de e connection TCP, ne provoque aucun changement sur la base de connaissances. Chacun des sc´narios est cependant dupliqu´, en subsituant id1 par σ(0). L’ensemble e contient e e donc six ´l´ments. Lorsque, au paquet 1, la connection est accept´e, on acqui`re la ee e e connaissance que le port 23 de la machine 192.168.0.101 est ouvert. Seulement deux sc´narios sont dupliqu´s, pour un total de 8. Au paquet 2, la connection est compl´t´e e e ee et la session est ouverte dans chacune des directions. Le d´lai des trois premiers sc´narios e e copi´s est ´coul´, et ils sont donc retir´s de la base de l’ensemble e. De plus, la condition e e e e pour un synscan ayant ´t´ viol´e, la copie du sc´nario correspondant est aussi retir´e. ee e e e Aucun sc´nario n’est dupliqu´, on se retrouve donc avec un ensemble e de taille 4. e e Le paquet 3 n’am`ne aucun changement sur la base de connaissances. Cependant, la e demande de connection fait en srte que les trois sc´narios de base sont dupliqu´s. Le e e d´lai du sc´nario de reconnaissance d’une poign´e de main TCP pendant ´tant ´coul´, e e e e e e celui-ci est retir´ de e, qui se retrouve de nouveau avec 6 ´l´ments. Au paquet 4, la e ee connection est accept´e. Deux sc´narios sont ainsi dupliqu´s, et on apprend que le port e e e 21 de la machine 192.168.0.109 est ouvert. Au paquet 5, tous les d´lais sont ´coul´s. On e e e apprend ainsi qu’une attaque de type synscan vient d’avoir lieu. Aucun sc´nario n’est e dupliqu´. e Nous terminons cette section par la formulation et la d´monstration du th´or`me e e e de validit´ de l’algorithme de v´rification. Par version de act, nous entendons l’action e e act ` laquelle l’op´rateur de substitution textuelle peut avoir ´t´ appliqu´. a e ee e

Chapitre 3. D´tection d’intrusions et analyse passive e

94

Th´or`me 3.3 (Validit´ de l’algorithme de v´rification) Si pour toute expression e e e e p et pour toutes bases de connaissances k1 et k2 , Evalk1 (p) = Evalk2 (p), alors, pour tout couple ψ, act d’une sp´cification donn´e, σ |= ψ si et seulement si lors du traitement e e (appel de la proc´dure verif) d’un certain σ(i), l’action act (ou une de ses versions) est e commise. La condition Evalk1 (p) = Evalk2 (p) provient du fait que l’´valuation d’une exprese sion p peut d´pendre du contenu de la base de connaissances. Comme nous n’avons e pas tenu compte de la base de connaissances dans la d´finition de la syntaxe et de la e s´mantique abstraites du langage, nous devons ´noncer le th´or`me de validit´ comme e e e e e si celle-ci n’avait aucun effet sur l’ex´cution de l’algorithme. Si pour toute expression p e et pour toutes bases de connaissances k1 et k2 , Evalk1 (p) = Evalk2 (p), alors l’expression Eval(p) est bien d´finie. On peut maintenant passer ` la d´monstration du th´or`me. e a e e e D´monstration : e On proc`de par induction sur la forme de φ : e cas id, φ t tt : ⇒Supposons que ∃i.σ(i).τ <Eval(t) et |= φ[σ(i)/id]. Alors, par l’hypoth`se de croise sance pos´e sur le mod`le, act est commise (ligne 9) avant que le couple ψ ⇒ act ne e e soit retir´ de e (ligne 8). e ⇐R´ciproquement, si il n’existe pas de tel j, le couple φ ⇒ act est retir´ de e (ligne 8) e e sans que act ne soit commise (ligne 9). cas ¬ id, φ t tt : ⇒Supposons que i.σ(i).τ <Eval(t) et Eval(φ[σ(i)/id]). Encore une fois, par l’hypoth`se de croissance, act sera commise (ligne 13) avant que le couple ψ ⇒ act ne soit e retir´ de e (ligne 14). e ⇐Si, au contraire, il existe un tel i, alors la ligne 13 est ex´cut´e avant la ligne 14. e e L’action act ne sera donc pas commise. cas id, φ t ψ : ⇒Supposons que ∃i.σ(j).τ <Eval(t) et Eval(φ[σ(i)/id]) = vrai et σ(i + 1) |= φ[σ(j)/id]. Alors, comme dans les autres cas, la ligne 17 sera ex´cut´e avant la ligne 16. L’hypoth`se e e e

Chapitre 3. D´tection d’intrusions et analyse passive e d’induction termine le travail.

95

⇐ Deux cas sont possibles. Soit que ∃i.σ(i).τ <Eval(t) et Eval(φ[σ(i)/id]) = vrai, soit qu’un tel i existe, mais que σ(i+1) |= ψ[σ(i)/id]. Dans le premier cas, la ligne 16 est ex´e cut´e avant la ligne 17, et dans le second cas, c’est l’hypoth`se d’induction qui entre en e e jeu, ce qui termine la d´monstration. e

3.6

Conclusion

Dans ce chapitre, nous avons vu comment il est possible d’am´liorer la structure loe gicielle et le langage de signatures d’un syst`me de d´tection d’intrusions tel que Snort e e de fa¸on ` ajouter la possibilit´ de reconnaˆ c a e ıtre des sc´narios d’attaque se d´roulant e e sur plusieurs paquets et ` pouvoir passivement acqu´rir de l’information. L’information a e acquise peut ˆtre, en retour, utilis´e par le syst`me de d´tection d’intrusions pour efe e e e fectuer une d´tection plus pr´cise (moins de faux positifs, et moins de faux n´gatifs). e e e Elle peut aussi ˆtre consult´e directement par l’administrateur r´seau en cas de besoin. e e e Avec le langage actuel de Snort, la reconnaissance de sc´narios impliquant plusieurs e paquets et l’acquisition passive d’information sont deux tˆches impossibles, et doivent a ˆtre effectu´es par programmation au niveau des pr´processeurs. e e e Un d´savantage majeur, comparativement ` Snort, est le temps de traitement d’une e a trace et la quantit´ de m´moire utilis´e. Avec son algorithme de reconnaissance de e e e patrons relativement simple, fonctionnant sur la base d’un seul paquet, Snort travaille en temps lin´aire en fonction de la taille de la trace et l’utilisation de la m´moire est e e pratiquement constante. Notre algorithme de reconnaissance de sc´narios pr´sente le e e mˆme inconv´nient que ceux de LogWeaver, Chronicles, Eagle, STAT, IDIOT et ASAX : e e la reconnaissance d’´tapes d’un sc´nario engendre (dans certain cas) une duplication de e e celui-ci, et le nombre de sc´narios en cours de reconnaissance peut donc, dans les cas e pathologiques, augmenter exponentiellement avec la taille de la trace (doubler ` chaque a paquet ou enregistrement). Le langage de signatures que nous avons propos´ est bas´ sur une logique temporelle e e avec des op´rateurs temporels futurs. Comme l’ont fait les concepteurs de LogWeaver, e nous avons seulement conserv´ l’op´rateur ♦, laissant ainsi tomber U et . Une diff´e e e rence importante entre notre logique et celle de LogWeaver est que nous avons restreint, comme le proposaient les auteurs, la syntaxe aux sc´narios purement lin´aires, c’est-`e e a dire ceux de la forme ♦p1 (∧♦p2 (∧♦p3 (∧ . . .))). Cette restriction pr´sente l’avantage de e simplifier l’algorithme de v´rification, tout en offrant suffisamment d’expressivit´ pour e e

par exemple. Un manque important au niveau de l’expressivit´ du langage de signatures est l’ime possibilit´ de sp´cifier simplement des comportements r´p´titifs tels que. se trouvent aussi ceux reli´s au choix d’une e ea e e suite d’enregistrements comme mod`le de trace. du point de vue du langage de e signatures. IDIOT. nous am`ne ` faire les mˆmes reproches que nous avons faits ` STAT. nous a e verrons comment l’utilisation d’op´rateurs temporels pass´s permet d’arriver ` un lane e a gage purement d´claratif. comme nous e e e e e l’avons d´j` remarqu´ pour ASAX et LogWeaver. comparativement au mod`le propositionnel. de plus. une autre diff´rence avec Loga u e e e Weaver est le statut particulier que nous avons donn´ au temps. le nombre de tentatives de connections TCP ` observer a a avant de conclure ` une attaque de balayage est 50. e Finalement. le nombre total d’expressions de la forme port1 = port2 sera de l’ordre de 502 /2 = 1250. le fait que certains champs peuvent ea e ˆtre absents de certains enregistrements ou encore avoir des valeurs multiples. Au chapitre suivant. D´tection d’intrusions et analyse passive e 96 les besoins li´s ` la d´tection d’intrusions. e a e a BSML et P-BEST quand ` la nature d´clarative du langage. et ainsi de faire abstraction. le rˆle de la base de e o connaissances est entre autres de servir de m´moire pour les sc´narios ayant d´j` ´t´ e e eaee reconnus. e . e e e e ceux associ´s ` des attaques de balayage. par exemple. Bien que ce choix de mod`le pr´sente e e e l’avantage. Nous verrons aussi comment l’introduction de l’unification. Nous avons cependant laiss´ la possibilit´ e a e e e d’exprimer le fait qu’il s’´coule.Chapitre 3. un e e e certain d´lai (de longueur finie) durant lequel un ´v´nement donn´ ne survient pas. on doit sp´cifier un sc´nario de 50 a e e ´tapes. notre architecture ` deux niveaux. et si. de mˆme que des tableaux et des op´rateurs d’approximants (une vere e sion faible des op´rateurs de points fixes) permet de r´gler la plupart des probl`mes e e e mentionn´s tout en conservant les avantages acquis. e e e e Le fait de pouvoir exprimer la non-occurence d’un ´v´nement donn´ durant un certain e e e laps de temps est un besoin courant en d´tection d’intrusions auquel il ´tait possible de e e subvenir ` moindre coˆt. Les clauses output sont a e de nature clairement imp´rative. Nous avons travaill´ e e sous l’hypoth`se qu’` chaque ´v´nement il ´tait possible d’associer un temps et que ces e a e e e temps sont croissants suivant le fichier d’audit (ou la trace de trafic). Dans un mˆme ordre d’id´es. outre les inconv´nients d´j` cit´s. Si on exige. et c’est pourquoi nous n’en avons pas tenu compte e dans notre pr´sentation formelle du langage. De plus. En y pensant bien. de la base de connaissances. Toutes les r´p´titions doivent ˆtre sp´cifi´es e a e e e e e une ` une. il ne refl`te cependant pas ad´quatement. logique temporelle pour exprimer a les sc´narios et base de connaissances pour stocker les connaissances et en d´duire de e e nouvelles. que les ports destinations soient diff´rents pour chacune e e des tentatives de connection. de permettre de comparer les e diff´rents ´v´nements entre eux. Elle sert donc ` regarder ce qui s’est pass´ avant. une fois une certaine suite d’´v´nements reconnue.

de mˆme que e d’op´rateurs d’approximants. nous pr´senterons l’algorithme de e e e v´rification en ligne pour la logique d´velopp´e dans ce chapitre et le d´montrerons e e e e comme ´tant complet et coh´rent. permet d’exprimer de fa¸on concise des sc´narios ` come c e a portement r´p´titif. Nous avons aussi vu comment.3. Dans la section 4. l’utilisation de l’op´e e rateur devient superflue. e e a Dans la section 4. nous verrons comment l’introduction de tableaux. lors de l’implantation. nous verrons qu’avec cet op´rateur.4. e e .2. L’ajout de cette base e e e de connaissances impliquait cependant de faire un compromis sur la nature d´clarative e du langage de d´tection.1. il est possible d’utiliser une base de connaissances afin d’acqu´rir passivement de l’infore mation sur le r´seau et ainsi d’am´liorer la d´tection d’intrusions. Dans e e e e e la section 4. nous avons vu comment il est possible de d´finir et de e e e d´tecter des sc´narios d’attaque complexes en utilisant un langage de signatures bas´ e e e sur une logique temporelle future. en ajoutant des clauses output correspondant ` des actions ` e a a prendre lors de la d´tection de certains sc´narios ou certaines parties de sc´narios. Finalement. dans la section 4. nous verrons comment l’introduction de l’unification permet de r´gler le probl`me des champs absents ou ` valeurs multiples. nous verrons comment l’op´rateur temporel pass´ S permet de rendre purement d´claratif le langage de signatures et ainsi de faire abstraction de la base de e connaissances. Mieux encore.Chapitre 4 Logique d’acquisition de connaissances Dans le chapitre pr´c´dent.

Au chapitre pr´c´dent. comme l’ont fait les a e e e e e auteurs de [31]). Que e a e e e penser. Logique d’acquisition de connaissances 98 4.Chapitre 4. permettant de sp´cifier que p doit survenir avant que le d´lai t ne se e e e soit ´coul´. on doit utiliser la formule ¬ ∞ (p ∧ 2 q). engendr´s par l’utilisation d’op´rateurs futurs. e u e Ces probl`mes. e on peut affirmer que p est satisfaite.8. qui dit qu’` un certain moe e a ment dans le futur. ce qui nous am`ne. De plus. l’utilisation de l’op´rateur S. De plus. De ce point de vue. est ´quivalente ` ¬φ2 S φ1 (φ1 a e e a ´t´ vraie dans le pass´. au moins ` la premi`re e e ee e a e ´tape. L’utilisation d’op´rateurs temporels futurs comporte cependant un inconv´nient e e majeur en ce qui regarde la v´rification en ligne : comme nous ne savons jamais ce que e l’avenir nous r´serve. se r´solvent tous en e e e e utilisant des op´rateurs temporels pass´s. utilisant ainsi une quantit´ e de m´moire sans cesse grandissante. e e e Par exemple. d’un q. φ2 ] qui. mais tant qu’elle ne survient pas. plutˆt e e e o que de l’op´rateur . le d´lai t soit de valeur infinie afin que la v´rification puisse toujours continuer. la proposition p doit ˆtre satisfaite ? Si. page 120). ` mesure que les sc´narios ´voluent. pour exprimer que il ne doit pas y avoir de p suivi. permet de r´soudre les probl`mes li´s ` l’utilisation imp´rative e e e e a e de la base de connaissances. a . ` construire des ensembles e e a de formules partiellement satisfaites et ` tenir ` jour ces ensembles du mieux que l’on a a peut. par d´finition. effectivement. de la d´cidabilit´ de la formule p. Cette permission sp´ciale laisse un bien e mauvais arri`re goˆt et nous aimerions bien ˆtre capables de nous en sortir autrement. et φ2 n’a pas ´t´ vraie depuis). nous avons contourn´ le probl`me en utilisant l’op´rateur t p. plutˆt que d’utiliser tel quel l’op´rateur S. au niveau de l’algorithme. Nous avons cependant ´t´ oblig´s de permettre que. p survient. par exemple. nous avons vu comment il est possible d’utiliser une logique e e temporelle future pour exprimer des sc´narios d’attaque se d´roulant sur plusieurs pae e quets. on ne peut rien dire. nous sommes pratiquement toujours face ` une formule en cours e a de v´rification.1 Un paradigme pass´ e Au chapitre pr´c´dent. la formule p est donc ind´cidable dans un contexte en ligne e (` moins de travailler sous l’hypoth`se que les traces sont finies. dans les 2 secondes. la pr´sentation que nous donnons de la logique temporelle que e nous proposons d’utiliser pour le langage de signatures se borne au mod`le propositione nel. nous o e utiliserons la construction [φ1 . Un autre inconv´nient de l’utilisation d’op´rateurs e e e temporels futurs dans un contexte de v´rification en ligne r´side au niveau de la s´e e e mantique donn´e ` ces op´rateurs et de la d´cidabilit´ des formules exprimables. En fait. nous devons dupliquer les sc´narios a e e e (lignes 17 et 20 de l’algorithme de la table 4. ee e ee Dans cette section. Le passage au premier ordre se fera ` la section suivante.

le mod`le ` utiliser est des plus conventionnels : e a ´ D´finition 4. mais aussi q a d´j` ´t´ vraie.1. ff] doit donc ˆtre come prise comme φ1 a d´j` ´t´ vraie. Le seul op´rateur temporel e e a e qu’elle comporte est l’op´rateur [φ1 . 4. alors [φ1 . u Un cas particulier important est celui de [φ1 . φ2 ] doit donc ˆtre interpr´t´e comme e e ee ´tant vraie entre φ1 et φ2 .1. Il est alors possible de sp´cifier des s´quences d’´v´neeaee e e e e ments. Logique d’acquisition de connaissances 99 φ ::= p | ¬φ | φ1 ∧ φ2 | [φ1 .2 Syntaxe La syntaxe de la logique est pr´sent´e ` la table 4. habituellement not´e e e e e eme σ. 4. La formule [φ1 . φ2 ]. 4.1 – Attaque dans le contexte d’une session TCP active.1. Si φ2 n’est jamais vraie. e e un ´v´nement (ou un ´tat) est un sous-ensemble de P . ff].1 Mod`le e Pour le cas propositionnel.1 – Syntaxe pour le cas propositionnel. 4. utilis´ pour repr´senter des connaissances qui e e e ne sont vraies que pour une certaine p´riode de temps. o` ff est d´finie comme ´tant une u e e constante propositionnelle qui n’est jamais vraie. ff]. ff]. Cette p´riode est caract´ris´e par e e e e son d´but (φ1 ) et par sa fin (φ2 ).Chapitre 4. ff]. on d´note le i e e e ´v´nement e e de la trace. en utilisant des formules de la forme r ∧ [q ∧ [p. Elle sp´cifie donc la s´quence p − q − r. e e HandShake Session V alidAttack := := := ack ∧ [synack ∧ [syn. fin ∨ rst] Attack ∧ Session Fig. e e eaee et avant cela p. φ2 ] Tab. d’´v´nements. Cette formule sera vraie aux ´v´nements pour lesquels non-seulement r est vraie. . ff] [HandShake. Une trace. La formule [φ1 . Par σ(i).1 (Trace) Etant donn´ un ensemble P de constantes propositionnelles. φ2 ] est vraie ` partir du e a moment o` φ1 est vraie. est une suite. finie ou infinie.

Elle dit comment. La premi`re ligne. et qu’aucun ee e e e e autre ´v´nement n’a satisfait φ2 depuis. doivent ˆtre ´valu´es les formules. e e Remarquons que la relation de satisfaction n’est d´finie que pour les diff´rents ´tats e e e de la trace. Logique d’acquisition de connaissances 100 σ(i) |=σ σ(i) |=σ σ(i) |=σ σ(i) |=σ p ¬φ φ1 ∧ φ2 [φ1 .3 S´mantique e La s´mantique de la logique propos´e. ´tant donn´ un ´tat σ(i) appartenant ` une trace σ. pour le cas propositionnel.1. comme le fait le pr´processeur Flow de Snort. par a d´finition. Si la formule Attack repr´sente la e e compl´tion d’une attaque au-dessus de TCP. La troisi`me ligne dit que σ(i) satisfait une conjonction de formules ssi σ(i) satisfait e les deux propositions conjointes. La poign´e de main n’est compl´t´e que lorsque le e ee dernier acquiescement. Elle dit qu’une e e session TCP est active ` partir du moment o` la poign´e de main est compl´t´e. 4. dit que σ(i) e satisfait [φ1 . on doit voir un paquet synack. Finalement. La quatri`me ligne. dit que σ(i) e e e e satisfait une constante propositionnelle p ssi p appartient ` σ(i) (on se souvient que. est envoy´. la plus importante. ´tant e e . Une fois que l’on a vu ce paquet e e syn.2. La deuxi`me e e e e ligne dit que σ(i) satisfait la n´gation d’une formule ssi celle-ci n’est pas satisfaite par e σ(i). comme d’habitude. Le e e e premier ´v´nement qui doit survenir est un paquet syn. φ2 ] ssi φ1 a ´t´ satisfaite par un ´v´nement pr´c´dent σ(i). La deuxi`me formule montre comment on peut e e utiliser cette poign´e de main pour sp´cifier une session TCP active.j < k < i. est pr´sent´e ` e e e e a e e e a la table 4. on peut utiliser u cette information pour valider l’occurrence d’une attaque donn´e survenant au-dessus e de TCP.σ(k) |=σ φ2 Tab. Informellement. jusqu’au a u e ee moment o` on voit passer un paquet fin ou un paquet rst. φ2 ] ssi ssi ssi ssi p ∈ σ(i) σ |=σ φ σ(i) |=σ φ1 et σ(i) |=σ φ2 ∃j.1. nous pouvons dire qu’une trace satisfait une formule si et seulement si tous ses ´tats la satisfont. La formule doit se lire de l’int´rieur vers l’ext´rieur. et non pour la trace au complet. alors la formule Attack ∧ Session signifie e qu’une poign´e de main doit avoir ´t´ compl´t´e avant que l’attaque n’ait ´t´ observ´e. on voit comment un tel s´quencement peut ˆtre utilis´ pour sp´cifier e e e e une poign´e de main TCP.j < i et σ(j) |=σ φ1 et ∃k. un ´v´nement est un ensemble de constantes propositionnelles). e ee ee ee e et que la session ne doit pas avoir ´t´ close par un paquet rst ou un paquet fin.2 – S´mantique pour le cas propositionnel. Cependant. ee 4.Chapitre 4. ack. e ` A la figure 4.

[syn..2 – Exemple de trace pour le cas propositionnel.. 4. .Chapitre 4. syn synack ack fin rst √ √ √ √ .. .2. les formules compos´es.. Le a e √ symbole indique que la formule ` la tˆte de la colonne est satisfaite par l’´v´nement i.. . et ` la figure 4.3. Fig... .. ff]...2 et 4... se trouve un exemple de relation de satisfaction pour la formule Session d´finie ` la figure 4.3 – Exemple de relations de satisfaction pour le cas propositionnel. Session Fig. . Les lignes repr´sentent les ´v´nements de la e a e e e ` la figure 4. a e e e i 0 1 2 3 4 5 6 . i 0 1 2 3 4 5 6 . ff] [synack ∧ [syn. A propositionnelles (constituant la trace). Ce qui nous int´resse vraiment. c’est de e ee e savoir quels sont les paquets (´tats) qui doivent ˆtre consid´r´s comme offensifs...1.3. Logique d’acquisition de connaissances 101 donn´ le probl`me auquel nous nous attaquons. . le fait de savoir si une trace satisfait ou e e non une formule ne pr´sente que peu d’int´rˆt. .. 4... C’est e e ee pourquoi la s´mantique est d´finie par rapport ` ces derniers plutˆt que par rapport ` e e a o a la trace au complet...... . et les colonnes les formules. se trouvent les diff´rentes constantes e trace. Aux figures 4. ff] HandShake √ √ √ √ √ √ .

.2 Unification Dans la section pr´c´dente. insuffisante pour exprimer des sc´narios d’attaque car elle ne permet pas de e e e comparer les ´v´nements (ou les paquets.. en ea g´n´ral. dans la version 2. 4. Ce qu’il faut conclure de cette observation est le fait suivant : lorsque des hypoth`ses sont faites sur les relations entre les ´v´nements (par e e e exemple. y) p(2. unset et toggle. Bien que sime e pliste en apparence.2 de Snort. de v´rifier les valeurs attribu´es aux drapeaux. nous avons pr´sent´ une version propositionnelle de la e e e e logique que nous proposons d’utiliser pour sp´cifier les sc´narios d’attaque et d’acquie e sition d’information. soit faux. et la formule φ2 ` celle lui donnant a la valeur faux (unset). Il s’agit d’un module permettant de d´finir. lors de la reconnaissance d’une signature donn´e. ce m´canisme donne ` Snort exactement la mˆme expressivit´ que e a e e le cas propositionnel de la logique que nous proposons. e e Il est cependant int´ressant. une logique propositionnelle est. 3) p(2. faux. Il est alors possible de e sp´cifier. il est possible de prendre les actions set. 4) p(5. le cas propositionnel peut tout de mˆme se e e r´v´ler d’une certaine utilit´. avant de passer ` l’´tude du cas du premier ordre. pour chaque flot TCP. Explicitement. q(v) q(3) q(0) .Chapitre 4. La formule φ1 correspond ` la a signature donnant la valeur vrai au drapeau (set). Comme nous l’avons d´j` dit. 4.. donnant respectivement aux drapeaux la valeur vrai. φ2 ] est donc vraie si et seulement si le drapeau correspondant a la valeur vrai. e e un ensemble de drapeaux qui peuvent ˆtre soit vrais. de e a e remarquer ce que les programmeurs de Snort ont r´cemment fait avec le module de e d´tection flowbits. Les mots-cl´s isset et isnotset e permettent. par la suite.. p(x... e e e . La formule [φ1 .1.4 – Exemple de trace du premier ordre. appartenir au mˆme flot TCP). et contraire de celle actuelle. Logique d’acquisition de connaissances 102 i 0 1 2 . des actions ` prendre sur e e a les valeurs des drapeaux. Fig. 4) . dans le cas d’une trace de trafic) entre eux.

A la figure 4. . finie ou infinie. il n’est vrai pour aucun e e a e e tuple.1 Mod`le e Au chapitre pr´c´dent. est une suite. .3. a e alors qu’en r´alit´. e le probl`me est le suivant : ´tant donn´ un pr´dicat p(x).2 Syntaxe La syntaxe de la logique avec pr´dicats du premier ordre se trouve ` la table 4. . . . on retrouve un pr´dicat du premier ordre p(x1 . il peut n’y en avoir aucune ou plusieurs. . . .2. sauf qu’au lieu e d’une constante propositionnelle p. nous avons remarqu´ que le mod`le consistant en une suite e e e e d’enregistrements est insuffisant pour les besoins de la d´tection d’intrusions. . φ2 ] Tab. e e Par abus de langage. chacun des pr´dicats peut ˆtre vrai pour un nombre ind´termin´ de e e e e tuples. . un ´v´nement est une fonction associant ` chaque pr´e e a e n dicat p(x1 . ` on peut voir un exemple de trace selon cette nouvelle d´finition. Une trace. vn fait partie de l’ensemble associ´ ` e a ` p(x1 . . et ` l’´v´nement 2. Tout se fait ee e e e . ` l’´v´nement 0. si le tuple v1 . . y) est vrai pour deux tuples. vn ) est dans σ(i). . e e e et V . habituellement not´e σ. 4. xn ) un sous-ensemble de V (c’est-`-dire un ensemble de n-tuples ` a a valeurs dans V ). Par σ(i).Chapitre 4. il est vrai pour un seul tuple.2 (Trace) Etant donn´s P .4. 4. . nous dirons parfois que p(v1 . A chacun des ´v´nee e e ments de la trace. . le pr´dicat p(x. Logique d’acquisition de connaissances 103 φ ::= p(x1 . C’est pour rem´dier ` ce e e e a probl`me que nous introduisons la notion d’unification au coeur mˆme du mod`le et de e e e la s´mantique. xn ) | ¬φ1 | φ1 ∧ φ2 | [φ1 . En fait. . . . un ensemble de pr´dicats du premier ordre. Il e a s’agit essentiellement de la mˆme syntaxe que dans le cas propositionnel. ` a e e e a l’´v´nement 1. e eme d’´v´nements. e La suppression de la notion d’enregistrement nous lib`re du mˆme coup du besoin e e d’utiliser une variable id pour r´f´rer aux diff´rents champs d’un ´v´nement. . . on d´note le i e e e ´v´nement de la trace. . . un ensemble de valeurs. xn ) par σ(i). Par exemple. 4.2. .3 – Syntaxe pour le cas du premier ordre. le mod`le d’enregistrements e e e e e nous force ` consid´rer qu’il existe une et une seule valeur de x telle que p(x) est vraie. xn ). e ´ D´finition 4. .

Elle le sera cependant lorsque viendra le temps de e s’assurer que les sp´cifications que l’on r´dige expriment bien ce que l’on veut exprimer. dans le cadre de cette logique. t). δ]. comme l’algorithme de v´e e e e rification que nous pr´senterons n’utilise pas explicitement les temps associ´s aux ´v´e e e e nements. t) ∧ ¬q(t). e a La notion de d´lai. Alors. l’hypoth`se de e e e croissance n’est ici plus n´cessaire. e e Remarquons enfin que mˆme l’existence du temps n’est plus n´cessaire pour que les e e algorithmes que nous pr´senterons fonctionnent et que la th´orie que nous d´veloppons e e e soit utile. e e et que le fait de consid´rer la poign´e de main comme ´tant r´ussie serait alors une e e e e erreur. De plus. ee e e ` c e A la figure 4.5. p(5. dans le cas de la formule [p(s. alors une autre formule φ2 doit ˆtre vraie dans un d´lai de δ unit´s de temps est e e e la suivante : [φ1 ∧ τ (x1 ). e e la formule [φ ∧ τ (x1 ). Par exemple. alors. nous l’abr´gerons e ee e e e par [φ. Logique d’acquisition de connaissances 104 maintenant par unification. il y a lieu de penser que le paquet syn ´tait e e e falsifi´ [7] et qu’une attaque de balayage est en cours. e De fa¸on g´n´rale. p(5. s’introduit comme au chapitre e pr´c´dent. durant la ee a e e .Chapitre 4. et que la p´riode entre les deux n’est pas plus longue que 3 unit´s de temps. Cette formule ´tant souvent utilis´e. Par exemple. et que ceux-ci ne sont pas non-plus utilis´s dans la s´mantique.1. τ (x2 ) ∧ x2 − x1 > δ] est vraie pour une p´riode de δ unit´s de e e temps apr`s que φ ait ´t´ vraie. on doit attendre de voir un ´v´nement pere e mettant d’associer la mˆme valeur ` la variable t. ff] ∧ x3 − x1 < δ Elle dit que si φ1 a ´t´ vraie ` plus de δ unit´s de temps dans le pass´. La formule q ∧ [p. la variable t est unifi´e lors de l’´v´nement satisfaisant la sous-formule p(s. 3] est donc vraie pour les ´v´nements o` q est vraie apr`s que p ait e e u e ´t´ vraie. t)∧¬q(t). t)]. En pratique. e e e Pour satisfaire l’autre sous-formule. le ack pourrait e e e e survenir une heure apr`s le synack. la formule exprimant le fait que si une formule φ1 vient ` ˆtre c e e ae vraie. si cet acquiescement ne survient toujours ea pas apr`s une p´riode de temps raisonnable. Cependant. comme nous l’avons d´j` dit. on sait que le syst`me d’exploitation de e e la machine ayant ´mis le synack aurait abandonn´ l’attente du ack depuis longtemps. La formule τ (x) signifie donc que l’´v´nement courant est survenu au temps x. ff] ∧ τ (x2 ) ∧ x2 − x1 > δ ⇒ [φ2 ∧ τ (x3 ). avec l’utilisation d’un pr´dicat τ (x). Un probl`me important avec cette sp´cification est qu’elle permet aux trois ´tapes d’ˆtre arbitrairement s´par´es dans le temps. on montre comment on peut utiliser cette fa¸on de sp´cifier des d´lais pour donner une meilleure sp´cification d’une poign´e de main TCP que celle e e e e e de la figure 4.

sp.sa.da.da. cela pourrait s’´crire de la fa¸on suivante : e e e c synack ∧ [syn.da.dport(dp) handShake(sa.dp) := (fin ∨ rst) ∧ (tcpFlow(sa.da.sadr(sa) ∧ tcp.sp.sp.da.sp.5 – Suivi des sessions TCP. dont la d´finition est exactement la formule ci-haut. par exemple. 2sec] sessionClosing(sa. alors on doit avoir observ´ un e e e e ack apr`s ce synack.dp) ∨ tcpFlow(da.dp)] Fig.dadr(da) ∧ tcp.sp. 3sec]. nous l’abr´gerons par e e a e un nouvel op´rateur d´fini.dp) := ip.sp. φ2 doit avoir ´t´ vraie.Chapitre 4.sa. p´riode de δ unit´s de temps suivant le moment o` φ1 a ´t´ vraie.sp) ∧ [syn ∧ tcpFlow(sa. sessionClosing(sa. En version simplifi´e. et que 2 unit´s de temps se sont ´coul´es depuis.dp).dp) := ack ∧ tcpFlow(sa.da. Il est alors possible d’utiliser cet e op´rateur pour sp´cifier.dp) ∧ [synack ∧ tcpFlow(da. e 2 δ .dp.sp.sp. ce qui signifie que si un synack a ´t´ observ´ dans les trois unit´s de temps suivant un ee e e syn. 4. not´ e e e φ1 → φ2 .dp.dp) := [handShake(sa.sp)) session(sa. que lorsque les deux premi`res ´tapes d’une e e e e poign´e de main TCP ont ´t´ observ´es.dp).da. e e u ee ee ´ Etant donn´ que cette formule peut ˆtre un peu lourde ` utiliser.da. la troisi`me doit suivre dans un d´lai de 2 e ee e e e unit´s de temps. Logique d’acquisition de connaissances 105 tcpFlow(sa. 3] → ack.sp.sport(sp) ∧ ip.da.

. . par e un ´v´nement σ(i) donn´. . .e φ1 σ(i) |=σ. Cette e e e a s´mantique repose d’abord sur la notion d’environnement : e ´ D´finition 4. . pour la d´sactivation d’une formule temporelle. sous les environnements sous lesquels φ1 a d´j` ´t´ satisfaite. Cet aspect particulier ee . . La restriction aux variables de φ1 . Finalement. ee e c a La notation e|S (e restreint ` S) d´signe l’environnement e tel que dom(e ) = a e dom(e) ∩ S et ∀x ∈ dom(e ). . . . . La troisi`me ligne dit qu’une conjonction est satisfaite. et que e e ea ee depuis il a ´t´ impossible d’´tendre de fa¸on ` satisfaire φ2 . . . e(xn ) e e e est un ´l´ment de l’ensemble associ´ ` p(x1 . La seconde ligne dit que la ee ea n´gation d’une formule est satisfaite par un ´tat σ(i) sous les environnements qui. sous les environnements e tels que le n-tuple e(x1 ). . . .4 indique qu’un pr´dicat p(x1 . sous e e e e les environnements sous lesquels σ(i) satisfait chacune des deux propositions conjointes. par un e ´v´nement σ(i).e φ1 et j < k < i. .Chapitre 4.e p(x1 . . Logique d’acquisition de connaissances 106 σ(i) |=σ. . . xn ) dans σ(i).e σ(i) |=σ. par un ´v´nement σ(i). . e e|var(φ1 ) . la quatri`me ligne nous dit qu’une formule temporelle est satisfaite. 4. . φ2 ]) {x1 . e(xn )) ∈ σ(i) var(φ1 ) ⊆ dom(e) et σ(i) |=σ.e σ(i) |=σ. . xn } ⊆ dom(e) et p(e(x1 ). xn ) ¬φ1 φ1 ∧ φ2 [φ1 . . .e σ(i) |=σ. xn )) var(¬φ1 ) var(φ1 ∧ φ2 ) var([φ1 .2. . bien e e que comportant la d´finition des variables n´cessaires. . e La premi`re ligne de la table 4. . .4 – S´mantique op´rationnelle pour le cas du premier ordre. ne satisfont pas la formule done e n´e.σ(j) |=σ. est introduite pour r´pondre au fait intuitif e e qu’une connaissance ne peut ˆtre retir´e de la base de connaisances que sur la base de ce e e qui a ´t´ appris au moment de l’acquisition de cette connaissance. nous pouvons d´tailler e la s´mantique de la version du premier ordre de la logique. .3 S´mantique e Maintenant que nous avons cette banque d’exemples en main. d´fini de la fa¸on suivante : e c e e ssi dom(e ) ⊇ dom(e) et.e φ1 et σ(i) |=σ. .e φ2 ∃j < i. .3 (Environnement) Etant donn´ X un ensemble de variables et V un e e ensemble de valeurs. un environnement est une fonction partielle e : X → V . xn } var(φ1 ) var(φ1 ) ∪ var(φ2 ) var(φ1 ) Tab.e φ2 {x1 . φ2 ] ssi ssi ssi ssi = = = = var(p(x1 .σ(k) |=σ. . L’ensemble des environnements est muni d’un ordre partiel .e (x) = e(x).e (x) = e(x). xn ) est satisfait. ∀x ∈ dom(e).4. pr´sent´e ` la table 4. e e 4.

` σ(1). q(y)] ∧ r(y). t) ∧ ¬q(t) [p(s. Cette restriction syntaxique ne diminue en rien e l’expressivit´ de la logique. dans les formules de la forme [φ1 . t → 4} {t → 0} {s → 5. on voit un exemple de relation de satisfaction. φ2 ]. celle-ci est donc satisfaite ` partir a de σ(1) sous cet environnement. La formule [p(x). La conjonction n’est donc satisfaite que sous l’environnement {s → 2. φ2 ].6. on retrouve un couple o` la premi`re a u e valeur d’un tuple associ´ ` p(x. q(y)] ∧ r(z). t → 4} {s → 5.. t → 4} ` a a partir de σ(2). dans la formule [p(x). .. Comme. par exemple. les variables de φ2 n’apparaissant e pas dans φ1 . le pr´dicat p(s. t → 3} {s → 2. il e e a est alors possible d’ignorer l’op´rateur de restriction et de consid´rer que les formules e e sont encadr´es par des quantificateurs universels. t)] {t → 3} {s → 2. de la s´mantique de la logique. joint au fait que nous n’utilisons pas de quantificateurs e universels ou existentiel. Cependant.4. En se pliant ` cette restriction. t → 4}. t) {s → 2. A l’´v´nement 0. Elle l’est cependant sous l’environnement {s → 5.6 – Exemple de relations de satisfaction pour le cas du premier ordre.. Chaque case du tableau contient les plus petits environnements sous lesquels la formule ` la tˆte de la colonne est satisfaite a e par l’´v´nement σ(i). Fig. Si ce n’´tait de la pr´sence de l’op´rae e e e e teur de restriction dans la s´mantique de l’op´rateur temporel. Pour les pr´dicats primitifs. Pour ne pas e e a e commettre d’erreur. 4. mais pas la formule ¬q(t). nous am`ne ` faire quelques commentaires sur la port´e des e a e diff´rentes variables utilis´es dans une formule. p(5.Chapitre 4. les formules devraient e e toutes ˆtre vues comme ´tant simplement encadr´es par des quantificateurs universels e e e s’appliquant ` toutes les variables. t → 4} .... les deux occurences de la variable y n’ont aucunement besoin d’ˆtre associ´es ` la mˆme valeur. car q(3) est dans σ(0).. t → 3}. t → 4}. toutes les occurrences des variables apparaissant φ2 mais non dans φ1 doivent ˆtre dans φ2 . il est plus simple de consid´rer que pour les formules φ ayant une e sous-formule de la forme [φ1 . (page 102). p(s. la formule temporelle n’est plus satisfaite sous l’environnement {s → 2. Logique d’acquisition de connaissances 107 i 0 1 2 . q(t) p(s. Par exemple. t) ∧ ¬q(t). les environnements sont ceux pour e e e lesquels les tuples form´s des valeurs associ´s aux variables de ces pr´dicats font partie e e e ` e e de l’ensemble associ´ ` ce pr´dicat dans σ(i). l’op´rateur de restriction a pour effet de a e d´quantifier. t → 4} {s → 5. peut ˆtre reme e plac´e par la formule ´quivalente [p(x). . t) est ea e e satisfait sous l’environnement {s → 2. y) est unifiable avec 5 et la seconde avec la valeur associ´e ea e ` t. t → 4} {s → 2. t → 4} .. e ` u A la figure 4.. dans le cas o` la trace σ est celle de la figure 4. q(y)] ∧ r(y). .. Comme cette conjonction active la formule temporelle.

. . Logique d’acquisition de connaissances 108 Nous terminons cette section avec la pr´sentation de trois r´sultats nous donnant une e e meilleure intuition de ce que repr´sente l’ensemble var(φ). . σ(i) |=σ. e1 (xn )) ∈ σ(i) ⇒ par d´finition de la relation . . . Le troisi`me nous fournit un cas particulier du second e dont nous aurons besoin plus loin dans ce chapitre. . xn ) ⇒ d´finition de la relation |= e {x1 . φ2 ]. Le second nous dit que ces variables sont suffisantes. D´monstration : e On proc`de par induction sur φ. . . e var(φ1 ) ⊆ dom(e) et var(φ2 ) ⊆ dom(e). . var(φ1 ) ∪ var(φ2 ) ⊆ dom(e). D´monstration : e On proc`de par induction sur φ. Par induction. e {x1 .e φ2 .e2 φ. . Le premier nous dit qu’un e environnement doit absolument d´finir toutes les variables contenues dans var(φ) pour e pouvoir satisfaire φ. e2 (xn )) ∈ σ(i) ⇒ d´finition de la relation |= e σ(i) |=σ. . .5 Soit e1 tel que var(φ) = dom(e1 ). xn ) (⇐) e1 . alors var(φ) ⊆ dom(e). xn } ⊆ dom(e1 ) et p(e1 (x1 ). . Les cas p(x1 .e2 p(x1 . .4 Si σ(i) |=σ.e1 p(x1 . . c’est-`-dire. . Pour tout e2 et seulement si σ(i) |=σ. xn ) et ¬φ1 d´coulent directement de e e la s´mantique. . .σ(j) |=σ. .e φ1 ∧ φ2 . et que le fait d’en ajouter plus ne change rien. .e φ. donc.e φ1 et σ(i) |=σ.e [φ1 . xn ) : (⇒) σ(i) |=σ. Si σ(i) |=σ. e Proposition 4. e cas p(x1 . alors σ(i) |=σ. . alors il existe e e j < i. . . . . Par l’hypoth`se d’induction. . . . xn } ⊆ dom(e2 ) et p(e2 (x1 ). xn } ⊆ dom(e2 ). Si σ(i) |=σ.e1 φ si .e φ1 . et e2 (xk ) = e1 (xk ) {x1 . var(φ1 ∧ φ2 ) ⊆ dom(e). . φ2 ]). .Chapitre 4. dom(e) ⊇ var(φ1 ) = var([φ1 . . Proposition 4. . a d’apr`s la d´finition de var. . . . .

e1 ⇒ σ(i) |=σ. . e et par d´finition de la relation . . e σ(i) |=σ. .e2 φ1 et var(φ1 ) ⊆ dom(e2 ) ⇒ d´finition de la relation |= e σ(i) |=σ. . xn ) cas ¬φ1 : (⇒) premi`rement. . e1 (xk ) = e2 (xk ) e {x1 . . . . . e e2 e1 et var(φ) = dom(e1 ) ⇒ d´finition de l’ensemble var e e2 e1 et var(φ1 ) = dom(e1 ) ⇒ d´finition de la relation e dom(e2 ) ⊆ dom(e1 ) et var(φ) = dom(e1 ) ⇒ th´orie des ensembles e var(φ1 ) ⊆ dom(e2 ) donc. . .e2 ¬φ1 ¬φ1 d´finition de la relation |= e φ1 direction ⇐ de l’hypoth`se d’induction e φ1 . .e1 ⇒ σ(i) |=σ. {x1 . e2 (xn )) ∈ σ(i) ⇒ par hypoth`se sur e1 . .e2 p(x1 . . . . . xn } ⊆ dom(e1 ). e1 (xn )) ∈ σ(i) ⇒ d´finition de la relation |= e σ(i) |=σ. . Logique d’acquisition de connaissances 109 σ(i) |=σ. . . . . . xn ) ⇒ d´finition de la relation |= e {x1 . xn } ⊆ dom(e1 ) et p(e1 (x1 ). .Chapitre 4. . . . xn } ⊆ dom(e2 ) et p(e2 (x1 ). . σ(i) |=σ.e2 deuxi`mement.e1 p(x1 .

e4 φ2 ⇒ direction ⇒ de l’hypoth`se d’induction e σ(i) |=σ. Logique d’acquisition de connaissances 110 (⇐) premi`rement e σ(i) |=σ.e3 φ1 et σ(i) |=σ.Chapitre 4. σ(i) |=σ.e1 φ1 et σ(i) |=σ.e2 φ1 et σ(i) |=σ. e en posant e3 = e1 |var(φ1 ) et e4 = e1 |var(φ2 ) σ(i) |=σ. var(φ) = var(φ1 ) e var(φ1 ) ⊆ dom(e1 ) donc.e1 φ1 et var(φ1 ) ⊆ dom(e1 ) ⇒ d´finition de la relation |= e σ(i) |=σ.e2 φ1 ∧ φ2 ¬φ1 d´finition de la relation |= e φ1 direction ⇒ de l’hypoth`se d’induction e φ1 .e1 φ2 ⇒ direction ⇐ de l’hypoth`se d’induction.e2 ⇒ σ(i) |=σ.e2 ⇒ σ(i) |=σ.e2 φ2 ⇒ d´finition de la relation |= e σ(i) |=σ. e var(φ) ⊆ dom(e1 ) ⇒ d´finition de l’ensemble var.e1 deuxi`mement.e1 ¬φ1 cas φ1 ∧ φ2 : (⇒) σ(i) |=e1 φ1 ∧ φ2 ⇒ definition de la relation |= σ(i) |=σ.

σ(j) |=σ.e1 φ1 et ∃j < k < i. e2 e2 |var(φ1 ) .σ(k) |=σ.e3 φ1 et σ(i) |=σ.e2 φ2 ⇒ direction ⇒ de l’hypoth`se d’induction.e2 [φ1 . e1 e1 |var(φ1 ) .e1 φ2 ⇒ d´finition de la relation |= e σ(i) |=σ.σ(j) |=σ.e1 [φ1 .e2 φ2 ⇒ var(φ1 ) = dom(e1 ) et e2 e1 impliquent e2 |var(φ1 ) = e1 |var(φ1 ) ∃j < i.σ(k) |=σ. φ2 ] (⇐) σ(i) |=σ.e2 φ2 ⇒ d´finition de la relation |= e σ(i) |=σ.e2 φ1 et ∃j < k < i. Logique d’acquisition de connaissances 111 (⇐) σ(i) |=σ.σ(k) |=σ.σ(j) |=σ.e2 φ1 et ∃j < k < i.σ(k) |=σ.σ(k) |=σ. e1 e1 |var(φ1 ) .e2 φ1 ∧ φ2 ⇒ d´finition de la relation |= e σ(i) |=σ.σ(j) |=σ. φ2 ] .e1 φ2 ⇒ direction ⇒ de l’hypoth`se d’induction e ∃j < i.e1 φ1 et ∃j < k < i.e1 φ2 ⇒ var(φ1 ) = dom(e1 ) et e2 e1 impliquent e2 |var(φ1 ) = e1 |var(φ1 ) ∃j < i.e1 φ2 ⇒ d´finition de la relation |= e σ(i) |=σ.e1 φ1 et ∃j < k < i. e1 e1 |var(φ1 ) . e en posant e3 = e1 |var(φ1 ) et e4 = e1 |var(φ2 ) σ(i) |=σ.e2 φ2 ⇒ direction ⇐ de l’hypoth`se d’induction e ∃j < i. φ2 ] : (⇒) σ(i) |=σ.e2 φ1 et σ(i) |=σ. e2 e2 |var(φ1 ) . e2 e2 |var(φ1 ) . φ2 ] ⇒ d´finition de la relation |= e ∃j < i.e1 φ1 et σ(i) |=σ.e1 [φ1 .e1 φ1 ∧ φ2 cas [φ1 .σ(k) |=σ.e2 [φ1 .σ(j) |=σ.σ(j) |=σ. φ2 ] ⇒ d´finition de la relation |= e ∃j < i.Chapitre 4.e2 φ1 et ∃j < k < i.e4 φ2 ⇒ direction ⇐ de l’hypoth`se d’induction e σ(i) |=σ.

Les formules exprimant de tels comportements a e r´p´titifs sont de la forme : e e φ := [φ1 ∧ [φ1 ∧ [φ1 ∧ [.4. par exemple. sans que φ2 ne le soit. φ2 ].]. mais il s’av`re que dans le cas qui nous occupe.5. par la transitivit´ de la relation . alors e que φ2 pourrait repr´senter l’´coulement d’un d´lai. φ2 ]. e . φ2 ] et nous voudrions ˆtre capables d’´crire de telles formules. e e e a nous introduisons la notation montr´e ` la table 4.e2 φ. e e e On sent alors que la formule φ1 dont on a besoin devrait en quelque sorte respecter la propri´t´ : ee φ := [φ1 ∧ φ.5. de force brute. par la proposition 4.e2 φ. comme e1 e2 e2 |var(φ) . . e e les points fixes ne sont pas n´cessaires et que les approximants suffisent. Pour r´pondre ` ce besoin. φ2 ] signifiant que φ1 est satisfaite un certain nombre de fois. Donc. φ1 pourrait repr´senter une demande de connexion suivie d’un refus. e e On n’a qu’` penser. Nore a e malement.3. ceux-ci ´tant e e d´finis comme des approximants limites. on a e1 e2 |var(φ) . on a dom(e2 |var(φ) ) = var(φ). aux attaques de balayage. il existe certains types de sc´narios d’attaque ea e e ou d’acquisition d’information pour lesquels la notion de r´p´tition est fondamentale.3 4.e1 φ.6 Si e1 e2 et σ(i) |=σ. par exemple.5 pour conclure que σ(i) |=σ.Chapitre 4. . dom(e2 |var(φ) ) = var(φ) ∩ dom(e2 ). alors σ(i) |=σ. les approximants sont d´finis pour introduire les points fixes. Logique d’acquisition de connaissances Ce dernier cas termine l’´tape d’induction sur i et compl`te la d´monstration. e e par la proposition 4. Comme.1 R´cursivit´ e e Approximants Comme nous l’avons d´j` remarqu´. Maintenant. D´monstration : e 112 Par d´finition de l’op´rateur de restriction. ou encore a ` certaines attaques de d´ni de service. Dans le cas d’une attaque de force brute ayant pour objectif de deviner un mot de passe Telnet. e e e Corollaire 4. inspir´e des approximants. en posant e1 = e2 |var(φ) . var(φ) ⊆ dom(e2 ). On peut finalement e appliquer l’autre direction de la proposition 4. on obtient σ(i) |=σ. 4.e1 φ.

φ ν n X.i) qui s’´value ` vrai si et seulement si les i premiers ´l´ments du e a ee tableau tab sont diff´rents. et ainsi de suite. que l’on d´finisse un nouveau type e e e tableau.φ/X] def Tab. 2]. et si tab[1] est diff´rent de tous ceux qui restent (de 2 ` i-1). ` A la figure 4. on voit comment il est possible de g´n´raliser la notion d’approximant de fa¸on ` pouvoir les d´finir sur un intervalle donn´. Supposons par exemple. 2] def def def = syn ∧ [syn ∧ [ν 1 X. La formule c a e e ν j:[0. on voit comment interpr´ter cette formule dans le cas o` diff´rentes. tab[1]. 4. a e a ` e e A la table 4. A e . e 4. 2] = syn ∧ [syn ∧ [syn ∧ [tt.(Y ∧ tab[j] = tab[k])) signifie alors que les i premiers ´l´ments du tableau tab ont des valeurs deux ` deux ee a ` la figure 4.syn ∧ [X. .φ def = = tt φ[ν n−1 X. et supposons que l’on veuille d´finir une formule alle Different(tab. tab[2]. on voit comment on peut utiliser les approximants pour ´crire la e 3 formule ν X. 2] = syn ∧ [ν 2 X. A e e u ` la figure 4.6. Ils peuvent aussi servir ` exprimer toutes sortes de formules o` la e e a u r´cursivit´ peut intervenir. . alors tab[0]. Ce sera vrai si tab[0] est diff´rent de tous les autres (de 1 e e ` i-1).i] X.syn ∧ [X. . sont des variables ordinaires.8.syn ∧ [X. 2].2 Tableaux Les approximants ne sont cependant pas seulement utiles pour exprimer des comportements r´p´titifs. repr´sentant 3 demandes de connexion TCP s´par´es par au e e e plus 2 unit´s de temps.7. tel que si tab est une variable de type tableau. 2]. Logique d’acquisition de connaissances 113 ν 0 X. 2]. ν 3 X.5 – Approximants.Chapitre 4.3.syn ∧ [X.(X ∧ ν k:[j+1.i] Y. 2] Fig.7 – Utilisation des approximants. on voit comment il est possible de d´finir un balayage de ports en i = 3. 4. 2]. 2].9.

= ν j:[1.. que nous avons d´j` d´finie.. la ` son port destination.f ] X.8 – Utilisation des approximants avec intervalles.3] Y. et encore moins de parcourir celle-ci autrement e e . ceux-ci doivent toujours ˆtre emmagasin´s dans un tableau plutˆt e e o que dans une simple variable.(Y ∧ tab[j] = tab[k]) ∧ tab[0] = tab[2] ∧ tab[0] = tab[1] = . Il est particuli`rement int´ressant de remarquer e e e e comment la variable d’it´ration i et les tableaux sont utilis´s pour sp´cifier que les ports e e e destination des demandes de connexion doivent ˆtre tous diff´rents.. Logique d’acquisition de connaissances 114 ν i:[f. Lorsque le premier e e syn est identifi´.(X ∧ ν k:[j+1. i/d] (d < f ) def Tab..f ] X.3] X. ν j:[0.(Y ∧ tab[j] = tab[k]) ∧ ν k:[1.f ] X. la variable dp[1] est unifi´e e e ` chaque it´ration.φ ν i:[d. Lorsque le second syn est identifi´. l’unification ayant ´t´ faite une fois pour toutes ` la r´ception de la e e ee a e premi`re demande de connexion. e 4. Il n’y a aucune restriction sur les ports e source. Cependant. sinon la formule signifierait que tous les ports source doivent ˆtre ´gaux.3] Y. et la taille du e e a tableau dp est alors de 1. l’algorithme que nous pr´sentons ne e e e n´cessite pas de m´moriser la trace.(Y ∧ tab[0] = tab[k]) = . et dp devient alors un tableau de taille 2.(X ∧ ν k:[j+1. def def def def def utilisant la r´cursivit´ et les tableaux. φ2 ] r´f`re ` un e e ee a ´tat qui soit arbitrairement loin dans le pass´.4 Algorithmes Bien que la s´mantique de la logique permette que l’op´rateur [φ1 .(X ∧ ν k:[j+1.3] Y.3] X.φ def = = tt φ[ν i:[d+1. 4.6 – Approximants avec intervalles.3] X. 4. = tab[1] = tab[2] ∧ tab[0] = tab[2] ∧ tab[0] = tab[1] Fig.(Y ∧ tab[j] = tab[k])) = ν j:[1.φ/X. la variable dp[0] est unifi´e ` son port destination. A a e formule allDifferent. est utilis´e pour v´rifier que tous ea e e e les ports destination sont bel et bien diff´rents.3] Y.Chapitre 4.

la s´mantique e e e e u e de la logique ´tant purement pass´e. il e e e e e est possible de dire si oui ou non σ(i) |= φ. e e Les ensembles k et k mat´rialisent l’acquisition d’information. en cours de modification par le traitement de l’´tat courant.9. la seule e diff´rence se situant au niveau des m´canismes d’unification. l’algorithme fonctionne exactement de la mˆme fa¸on. Ces concessions ne a e sont cependant pas plus restrictives que celles qui doivent ˆtre faites lors de l’utilisation e du langage de programmation Prolog.4. La validit´. L’ensemble k ree pr´sente la connaissance acquise jusqu’` maintenant.i) ∧ [X. il faut juste pr´voir un acc`s en lecture au tableau sat en cours d’ex´cution e c e e e (puisque l’instruction retourner sat ne sera jamais ex´cut´e). apr`s chaque traitement d’un ´v´nement σ(i). La connaise . une d´monstration de la validit´ (come e pl´tude et coh´rence) de l’algorithme. nous verrons que l’espace m´moire n´cessaire ne d´passe pas e e e quelques bits.dp[i]) ∧ allDifferent(dp. et e une pour le cas du premier ordre. qu’´v´nement par ´v´nement.da. est montr´ ` la table 4. une pour le cas propositionnel.Chapitre 4. pour le cas propositionnel. l’algorithme a e que nous pr´sentons est donc en ligne (voir table 1. dans le cas du premier ordre. 2sec] Fig. e e Nous donnons aussi.da) := ν i:[0. e e e dans le cas propositionnel. 4. Nul n’est besoin d’attendre ` l’´v´nement a e e suivant. ainsi qu’une analyse de complexit´. verification.sp[i]. prend en entr´e une formule φ et une e trace σ de longueur finie. La e ea boucle principale de l’algorithme. ou encore de tenir ` jour une liste de sc´narios partiels.7. Pour le cas infini. dans l’ordre o` ils surviennent. Il s’agit essentiellement du mˆme algorithme. 4.5] X. En ce sens. De plus.1 Cas propositionnel L’algorithme de v´rification. page 52). ne sera obtenue qu’` condition e a de faire quelques concessions sur la forme des formules ` v´rifier. Logique d’acquisition de connaissances 115 portScan(sa.9 – Balayage de ports TCP. Entre autres. et l’ensemble k repr´sente cette e a e connaissance. e Nous pr´sentons deux versions de l’algorithme. dans chacun des cas. syn ∧ tcpFlow(sa.

e . σ(i). k ) cas φ1 ∧ φ2 : v1 :=verif(φ1 . σ : une trace e sortie : sat. s. un tableau de bool´ens tel que sat[i] ssi σ(i) |= φ e variables locales : k. k. k ) retourner sat fin Tab. s. s. k ) si v1 alors k := k ∪ {φ} sinon si v2 alors k := k \ {φ} retourne φ ∈ k fin fonction verification(φ.Chapitre 4. s : un ´tat. s. k ) v2 :=verif(φ2 . k. k. v2 : des bool´ens e d´but e selon la forme de φ : cas p : retourne p ∈ s cas ¬φ1 : retourne ¬verif(φ1 . φ2 ] : v1 :=verif(φ1 . k : la connaissance pass´e e e e sortie : k : la connaissance mise ` jour a valeur de retour : un bool´en indiquant si s |= φ dans le contexte k e variables locales : v1 . k ) v2 :=verif(φ2 . 4. k ) entr´es : φ : une formule. k. k ) retourne v1 ∧ v2 cas [φ1 . k.k : des ensembles d´but e k := ∅ pour i allant de 0 ` |σ| a k := k sat[i] :=verif(φ. s. σ) entr´es : φ : une formule. k. k. Logique d’acquisition de connaissances 116 fonction verif(φ. s.7 – Algorithme de v´rification pour le cas propositionel.

De plus. φ2 ] est ajout´ ` k si et seulement si σ(0) |= φ1 . Par l’hypoth`se d’induction e e sur φ. k. φ2 ] ∈ k si et e seulement si σ(i) |= [φ1 . mais il ´tait plus commode. σ(1) |= [φ1 . φ2 ]. On retourne donc vrai si et seulement si σ(i) |= φ1 . φ2 ] si et seulement si σ(i) |= φ1 ou (σ(i) |= [φ1 . ce qui termine la d´monstration. [φ1 . φ2 ] et σ(i) |= φ2 ). Par l’hypoth`se d’induction sur φ. en s’assurant que les sous-formules sont trait´es dans le bon ordre. [φ1 . φ2 ] : Comme k = ∅. la fonction retourne vrai ssi σ(i) |= φ. σ(0) |= [φ1 . Logique d’acquisition de connaissances 117 sance est mise ` jour juste avant le traitement de chaque ´v´nement. [φ1 . u Pour le cas [φ1 . σ(i). φ2 ].7 (Validit´) Apr`s chaque appel de verif(φ. on retourne faux. D´monstration : e On proc`de par induction sur i : e Pour i = 0. φ2 ] qui sont telles que σ(i + 1) |= [φ1 . ce qui est correct car comme il n’existe pas de j < 0. φ2 ]. cas φ1 ∧ φ2 : Comme dans le cas pr´c´dent. du point de vue de l’analyse. Par d´finition de la s´mantique. e . alors. Th´or`me 4. φ2 ] si et seulement si σ(0) |= φ1 . alors par l’hypoth`se d’induction sur i. a a e e σ(i + 1) |= [φ1 . k. Il aurait ´t´ a e e ee possible d’optimiser en n’ayant qu’un seul ensemble. e cas ¬φ1 : Par l’hypoth`se d’induction sur φ. e 1 La forme du reste de la d´monstration est (p ⇔ q ∨ r) ⇔ ((q ⇒ p) ∧ (¬q ⇒ (p ⇔ r))). σ(i). verif(φ1 . σ(i) |= φ1 . φ2 ] sera dans k (il y est e ajout´ s’il n’y est pas d´j`).1 Si σ(i) |= φ1 . φ2 ]. on proc`de par induction sur φ : e cas p : l’expression p ∈ s concorde exactement avec la s´mantique. par l’hypoth`se d’induction sur i. au contraire. e ea Si.Chapitre 4. [φ1 . par d´finition de a e la s´mantique. e e Il reste ` montrer que k est mis ` jour correctement. par l’hypoth`se d’induction sur φ. on utilise l’hypoth`se d’induction sur φ e e e pour les deux sous-formules et le reste concorde avec la s´mantique. k ) retourne vrai e si et seulement si σ(i) |= φ1 . φ2 ] est retir´ de k e e si et seulement si σ(i) |= φ2 . e cas [φ1 . Pour ce qui est de la mise ` jour de k. la valeur retourn´e est correcte. les trois premiers cas d’induction sur φ sont identiques au cas o` i = 0. k ). ea Pour i > 0. l’ensemble e e e e k est l’ensemble de toutes les sous-formules de φ de la forme [φ1 . e e de garder deux ensembles.

est ´gal ` φ (peu importe i). 4.9 (Complexit´) La taille de k ne d´passe jamais |φ|. au lieu de contenir des variables bool´ennes. φ2 ]| def = = = 1 1 + |φ| 1 + |φ1 | + |φ2 | 1 + |φ1 | + |φ2 | def def def = Une propri´t´ int´ressante de notre algorithme est que l’espace m´moire qu’il utilise ee e e est constant en fonction de |σ|. D´monstration : e L’analyse de la taille de k est directe : comme cet ensemble ne contient que des sousformules de φ. la taille d’une formule est son nombre de sous-formules.Chapitre 4. Intuitivement. contient un ensemble d’ene vironnements sous lesquels chaque ´v´nement de la trace satisfait la formule φ. est pr´sent´ ` la table 4.7 est complet et coh´e e rent. l’appel de la fonction verif(φ.4. Le e e e a nombre total d’appels est donc |φ||σ|.2 Cas du premier ordre L’algorithme de v´rification.e φ e ssi il existe e ∈ sat[i] tel que e e . et il est coh´rent car si la valeur vrai est retourn´e. pour le cas du premier ordre. pour chaque ´v´nement. Le nombre e d’appels de la fonction verif. De mˆme l’ensemble k ne contient plus des souse formules de φ. alors e e σ(i) |= φ. celui-ci ne peut ˆtre plus grand que le nombre de sous-formules. sat ne contient pas tous ces environnements. mais des environnements sous lesquels les sous-formules de φ de la forme .8. Avant de passer ` l’analyse de la complexit´. D´finition 4. e e ea Le tableau sat. Il est complet car pour chaque i tel que σ(i) |= φ. la taille a e e d’une formule. nous avons besoin de d´finir |φ|.8 (Taille d’une formule) e |p| |¬φ| |φ1 ∧ φ2 | |[φ1 . σ(i). Dans le e e cas g´n´ral. k. Proposition 4. mais nous verrons dans cette e e section qu’il est possible de d´finir un ensemble de formules pour lequelles σ(i) |=σ. Logique d’acquisition de connaissances 118 Nous venons donc de d´montrer que l’algorithme de la table 4. et que le temps qu’il met ` s’ex´cuter est lin´aire en a e e fonction de |σ|. k ) retourne vrai. et le nombre e e d’appels de la fonction verif est |φ||σ|.

e p(x1 . Ces deux clauses. 2. proviennent du fait que nous avons l’intention d’effectuer une unification de gauche ` droite. L’expression p(x1 . Cette s´quentialit´ n’est pas toujours possible. Une formule φ est dite croissante si elle est croissante pour ∅. nous verrons que a e c’est au moins le cas pour les formules croissantes. p(x1 .11). . . . ensemble. ¬φ1 est croissante pour X si var(φ1 ) ⊆ (X) et φ1 est croissante pour X. xn ). mais les formules ¬p(x) ∧ q(x). . on d´finit r´cursivement e e e e l’ensemble des formules croissantes pour X de la fa¸on suivante : c 1. entre autres. les pr´dicats situ´s le plus ` gauche servent ` construire e e e a a des environnements candidats. φ2 ] sont satisfaites. retourne l’ensemble minimal e e d’environnements e ´tendant un environnement de E tels que σ(i) |=σ. En fait.10 Etant donn´ un ensemble X de variables. La e e clause 2 peut paraˆ ıtre surprenante au premier abord. et les n´gations situ´es ` droite servent ` ´carter les e e a a e . φ1 ∧ φ2 est croissante pour X si φ1 est croissante pour X et φ2 est croissante pour X ∪ var(φ1 ). La clause 2 nous dit. mais elle prend tout son sens lorsqu’on la met en lien avec la clause 3. . que toutes les variables de φ1 doivent ˆtre dans X pour que ¬φ1 puisse ˆtre consid´r´e comme e e ee croissante. ´tant donn´ un ensemble d’environnements E. 4. . . [φ1 . et la 3 nous dit que φ2 doit ˆtre croissante au moins pour les variables de e φ1 . ¬p(x) ∧ ¬q(x) et ¬(p(x) ∧ q(x)) ne le sont pas. et nous passerons pratiquement e e le reste de ce chapitre ` d´terminer dans quels cas elle l’est. Logique d’acquisition de connaissances 119 [φ1 . 3. xn ) E est consid´r´e comme une primiee s tive qui. les formules p(x) ∧ q(x) et p(x) ∧ ¬q(x) sont croissantes. que nous d´finissons ` l’instant : e a ´ D´finition 4. xn ) est croissante pour X. et ensuite les environnements ´tendant ces derniers sous lesquels φ2 est e satisfaite. e Formules croissantes Ce qui complique particuli`rement l’analyse de cet algorithme est (entre autres) e le cas de la conjonction.Chapitre 4. . La clause 1 de la d´finition nous dit qu’un pr´dicat seul est toujours croissant. . . Comme dans le cas d’une unification faite avec Prolog (du moins avec a l’impl´mentation de Amzi 7. φ2 ] est croissante pour X si φ1 est croissante pour X et φ2 est croissante pour var(φ1 ). o` on calcule d’abord les environnements sous lesquels φ1 u est satisfaite. Par exemple. . .

s. . s. k. . k ) retourne E2 cas [φ1 . . k. xn ) : retourne p(x1 . σ. s. E1 . e1 ∈ k. k. k ) fin Tab. k ) pour chaque e ∈ E si ∃e ∈ E1 . s : un ´tat. s. σ : une trace e sortie : sat. E.e e alors E := E − e retourne E cas φ1 ∧ φ2 : E1 :=verif(φ1 . k ) pour chaque e ∈ E1 k := k ∪ { φ. . σ(i). k. s. . sat) entr´es : φ : une formule. E.Chapitre 4. . k. e } E1 :=verif(φ1 .e1 (x) = e2 (x)} fin fonction verification(φ. k. k ) pour chaque e tel que φ. e2 ∈ E et ∃x ∈ dom(e1 ) ∩ dom(e2 ). un tableau d’ensembles d’environnements variables locales : k. 4. e .k : des ensembles d´but e k := ∅ pour i allant de 0 ` |σ| a k := k sat[i] :=verif(φ. {∅}. . k. k ) E2 :=verif(φ2 . φ2 ] : E2 :=verif(φ2 . E. E. e|var(φ1 ) } retourne {e1 ∪ e2 tels que φ. xn ) E s cas ¬φ1 : E1 :=verif(φ1 . ∅. s. e e e E : un ensemble d’environnements sortie : k : la connaissance mise ` jour a valeur de retour : un ensemble d’environnements variables locales : v1 .e e alors k := k \ { φ. k ) entr´es : φ : une formule. k : la connaissance pass´e. v2 : des ensembles d’environnements d´but e selon la forme de φ : cas p(x1 . Logique d’acquisition de connaissances 120 fonction verif(φ.8 – Algorithme de v´rification pour le cas du premier ordre. e ∈ k si ∃e ∈ E2 . .

Logique d’acquisition de connaissances 121 p(x1 . qui nous dit qu’il suffit que l’environnement soit d´fini sur var(φ). e e e e a e ´ c’est ` partir de cette s´mantique que nous raisonnerons.8 une s´mantique d´notationnelle abstraite. .i−1 tels que φ2 e |var(φ1 ) σ. que nous avons d´j` not´ lors de la pr´sentation de la s´mantique.i−1 = ∅} Tab. . que le retrait ea e e e d’une connaissance ne doit ˆtre effectu´ que sur la base des connaissances acquises lors e e de l’acquisition de cette connaissance. φ2 ] [φ1 . ce renforcement (plus X est petit.i = ∅ φ1 e σ. . Encore une fois.i σ. . plus il est difficile d’ˆtre croissant pour X) de la contrainte provient e du fait. e a e e S´mantique d´notationnelle e e Pour nous aider dans notre analyse. La clause 4 de la e d´finition dit que pour qu’une formule temporelle soit croissante.Chapitre 4. la formule d’activation e doit ˆtre croissante. e (xn )) ∈ σ(i) et x ∈ dom(e ) ⇒ x ∈ dom(e) ou x ∈ {x1 . Avant de passer ` la pr´sentation de la s´mantique d´notationnelle. ne doit ˆtre croissante que e e e par rapport aux variables de la formule d’activation. on montre comment calculer φ e .i−1 (i > 0) = ∪ {e ∈ [φ1 .9. mais la formule de d´sactivation.i e σ. pr´sent´e ` la table 4. a e e une trace σ et un environnement e. un ensemble σ. xn }} = {e} si φ1 e = ∅.0 e σ.i = φ2 E1 avec E1 = φ1 e σ. les candidats sont cependant aussi construits par les formules temporelles. et dans notre cas. mais plutˆt ` chaque ´v´nement. φ2 ] e σ. e elle se fait avec chacun des ´v´nements. e e candidats construits.5. La principale pr´caution ` faire est la suivante : la base de faits de Prolog ne e a doit pas ˆtre associ´e ` notre base de connaissances. e e a o a e e Dans Prolog.i = {e e. . D´sormais. φ2 ] e σ. . . e .i d’environnements e tels que e ´tend e juste ce qu’il faut pour pouvoir pr´tendre ` e e a satisfaire φ dans l’´tat i de la trace σ. l’unification des pr´dicats se fait avec la base de faits.i e σ. xn ) ¬φ1 e σ. . C’est donc comme si nous ´tions en train de e e e d´finir un Prolog dont la base de faits change ` chaque ´v´nement.p(e (x1 ). . . ∅ sinon σ. 4. Le juste ce qu’il faut en question est celui de e la proposition 4. nous avons extrait de l’algorithme pr´sent´ ` la e ea table 4. . Etant donn´ une formule φ. notons que a e e e certaines pr´cautions doivent ˆtre prises lors des comparaisons faites avec le langage e e Prolog. . elle. Dans notre cas.i φ1 ∧ φ2 [φ1 . qui repr´sentent la base de connaissances.9 – S´mantique d´notationnelle pour le cas du premier ordre.

en plus de d´j` pr´tendre e e e a e ea e ` satisfaire [φ1 . aucune extension n’est n´cessaire pour pouvoir pr´tendre ` satisfaire e e e a ¬φ1 . . q(2)}. et {{x → 1}} par contre.i e. σ.Chapitre 4.13 (Validit´) Si φ est une formule croissante pour dom(e) et e1 e e e alors σ(i) |=σ. si on consid`re la formule (´quivalente) ¬q(x) ∧ p(x). Pour un pr´dicat p(x1 . σ. a Nous avons maintenant les outils n´cessaires pour ´noncer tout de suite le th´or`me e e e e de validit´. alors e peut pr´tendre ` satisfaire ¬φ1 et l’ensemble retourn´ est seulement e a e le singleton {e}. xn ) e est ∅. Pour illustrer la n´cessit´ de l’hypoth`se de croissance.i est un raccourci pour e e ∪ φ e . e c a E Lorsque E est un ensemble d’environnements. alors l’ensemble p(x1 . on traite le cas de la formule [φ1 .i p(x) ∅ σ. nous pourrons en d´duire le corollaire e e e e . l’unification de gauche e e ` droite donne a ¬q(x) σ. Si aucune telle extension n’est possible. ne pr´tendaient en aucune fa¸on pouvoir mea e e e e c ner ` la satisfaction de φ2 (toujours en se restreignant aux variables de φ1 ). qui.i {∅} = = {{x → 1}}. Au contraire. φ2 ] sont celles. xn ). . . premi`rement. qui dans l’´tat e a e e pr´c´dent pr´tendaient ` satisfaire φ1 . . xn ) σ.i e∈E Les extensions pr´tendant ` satisfaire [φ1 . Les tentatives d’unificae tion sont faites de gauche ` droite. prenons. et ∅ Une fois que nous aurons d´montr´ ce thor`me. Dans le σ.i {{x→1}} ¬q(x) σ. φ2 ] dans l’´tat pr´c´dent. e On commence donc par calculer les extensions pouvant pr´tendre ` satisfaire φ1 . nous avons e p(x) σ. .i cas de la n´gation. puis e a on regarde comment il est possible d’´tendre ces extensions de fa¸on ` satisfaire φ2 . . l’expression φ σ. par exemple. φ2 ] par d´ploiement r´cursif. la e e e formule p(x) ∧ ¬q(x) dans un ´tat σ(i) = {p(1). que nous d´montrerons plus loin : e e Th´or`me 4. dans le cas o` il est possible de calculer une extension permettant de u satisfaire φ1 . Finalement.i est l’ensemble des environnements ´tendant e en d´finise e sant exactement les variables qui lui manquent pour pouvoir satisfaire p(x1 . Si il n’est pas possible de calculer une telle e extension. Logique d’acquisition de connaissances 122 Prenons. e e e l’ensemble p(x1 .9. alors l’ensemble retourn´ est ∅. .e1 φ si et seulement si il existe e2 ∈ φ e tel que e1 e2 . sans retour en arri`re. xn ). . la premi`re ligne de la table 4.i {∅} = = ∅. et deuxi`mement. L’exploration de tous les a e arbres possibles nous semblait un gruge-temps additionnel non-n´cessaire du point de e vue de l’expressivit´ (souvenons-nous que nous travaillons dans un contexte en-ligne). . . . . . . par exemple. Le cas de la conjonction est le plus d´licat. . .

φ2 ] : Comme il n’existe pas de e ∈ [φ1 .i implique e = e. Il nous dit que si la formule ` e a v´rifier respecte les conditions syntaxiques d’une formule croissante. xn ) : Cons´quence directe de la d´finition de la s´mantique d´notatione e e e nelle.i s´mantique d´notationnelle).14 Si φ est croissante. dom(e ) = e e dom(e) = dom(e) ∪ var(φ1 ) = dom(e) ∪ var(¬φ1 ). D´monstration : e On proc`de par induction sur i : e Pour le cas i = 0.11 a e e nous dit que la v´rification d’une formule croissante par rapport ` un environnement e a donn´ nous donne un ensemble d’environnements dont le domaine contient les variables e de cette formule. φ2 est croissante pour dom(e ). Alors.0 .12 nous dit que ces environnements sont des extensions du premier environnement. e ∈ ¬φ1 σ. Cas φ1 ∧ φ2 : Soit e ∈ φ1 e tel que e ∈ φ2 e (un tel e existe par d´finition de la e σ.e si et {∅} seulement si il existe e ∈ φ σ.i .Chapitre 4. pour chaque ´v´nement. par d´finie e tion d’une formule croissante. σ(i) |=σ. Lemme 4. .i σ. et par d´fie e nition de la s´mantique d´notationnelle. Corollaire 4. Donc. Les deux lemmes dont nous avons besoin pour la d´monstration du th´or`me servent e e e ` justifier la d´finition que nous avons donn´ des formules croissantes. on peut appliquer e e l’hypoth`se d’induction pour dire que dom(e ) = dom(e) ∪ var(φ1 ). alors dom(e ) = dom(e) ∪ la condition du lemme ne . Le lemme 4.i tel que e e . qui est le cas particulier qui nous int´resse. Cas ¬φ1 : Si ¬φ1 est croissante pour dom(e). . Comme φ1 est croissante pour dom(e). alors pour tout environnement e. et on peut appliquer une seconde fois l’hypoth`se d’induction sur φ pour dire que dom(e ) = dom(e ) ∪ var(φ2 ) = e dom(e) ∪ var(φ1 ) ∪ var(φ2 ) = dom(e) ∪ var(φ1 ∧ φ2 ). Cas [φ1 . et le lemme 4. Logique d’acquisition de connaissances 123 suivant. . e σ. φ2 ] s’applique pas et ce cas est d´montr´. alors il est possible e de calculer.11 Si φ est croissante pour dom(e) et e ∈ φ var(φ). un ensemble d’environnements repr´sentant tous e e e les environnements sous lesquels φ est satisfaite. e e e σ. on proc`de par induction sur φ : e Cas p(x1 . . alors var(φ1 ) ⊆ dom(e).

i−1 c’est l’hypoth`se d’induction sur φ qui permet de conclure.i−1 σ.i−1 c’est l’hypoth`se d’induction sur φ qui permet de conclure. Pour le cas [φ1 . φ2 ] : Comme il n’existe pas de e ∈ [φ1 . . . les trois premiers cas d’induction sur φ sont identiques. φ2 ] e . e e Lemme 4.12 Si e ∈ φ D´monstration : e On proc`de par induction sur i : e Pour le cas i = 0. e e e σ. soit que e ∈ φ1 e . soit que e ∈ [φ1 . e Cas i = 0 : On proc`de par induction sur φ.i−1 σ. compl´tant ainsi la d´monstration du lemme. σ. Logique d’acquisition de connaissances 124 Pour le cas i > 0. φ2 ] e . c’est e celle sur i qui finit le travail. e e Nous avons maintenant tous les outils n´cessaires pour passer ` la d´monstration e a e du th´or`me de validit´.i tel que e1 e2 . c’est e celle sur i qui finit le travail. Cas ¬φ1 : Cons´quence directe de la r´flexivit´ de e e e d´notationnelle. σ. e e e σ(i) |=σ. e e Cas [φ1 . Dans le premier cas.e1 φ si et seulement si il existe e2 ∈ φ D´monstration du th´or`me: e e e On proc`de par induction sur i. φ2 ]. et dans le second cas. compl´tant ainsi la d´monstration du lemme. xn ) : Cons´quence directe de la d´finition de la s´mantique d´notatione e e e nelle. . on proc`de par induction sur φ : e Cas p(x1 . Cas φ1 ∧ φ2 : Cons´quence directe de la transitivit´ de e e s´mantique d´notationnelle. φ2 ]. les trois premiers cas d’induction sur φ sont identiques. Dans le premier cas.0 . φ2 ] s’applique pas et ce cas est d´montr´. Pour le cas [φ1 . soit que e ∈ φ1 e . et de la d´finition de la e la condition du lemme ne Pour le cas i > 0.Chapitre 4. soit que e ∈ [φ1 . e e σ. e et de la d´finition de la s´mantique e e e σ. . et dans le second cas. alors e e.i .

. φ1 est croissante pour dom(e). .. .. n et p(e2 (x1 ). . .. e1 (xn )) ∈ σ(i) ⇒ d´finition de la relation |= e σ(i) |=σ. . . xn } ⊆ dom(e2 ) et p(e2 (x1 ). .. . on peut donc poser e2 = e ∪ e1 |{x1 .. ...xn } ∈ φ σ. . .i ⇒ d´finition de la s´mantique d´notationnelle e e e e1 e2 et {x1 .. .. en (xn )) ∈ σ(i) ⇒ d´finition de la s´mantique d´notationnelle et e1 e e e e e e ∪ e1 |{x1 .. . xn ) e σ. xn } ⊆ dom(e1 ) et p(e1 (x1 ).xn } ∃e2 ∈ φ e . .i .i ⇒ e1 e e ∈ φ1 e σ. xn ) ⇒ d´finition de la relation |= e {x1 . . .i (⇐) e1 e2 et e2 ∈ p(x1 . . e2 (xn )) ∈ σ(i) ⇒ th´orie des ensembles e p(e1 (x1 ). . . . e On peut donc appliquer la direction ⇐ de l’hypoth`se d’induction sur e φ. .e1 e2 σ. . . . ∃e1 ∈ φ1 e . . . e2 (xn )) ∈ σ(i) ⇒ d´finition de la relation e {x1 . . . Logique d’acquisition de connaissances 125 Cas p(x1 . .e1 e1 σ. xn } ⊆ dom(e2 ) ⊆ dom(e1 ) et e1 (xl ) = e2 (xl ) pour l = 1 . . . . .xn } . .i ⇒ e1 e ⇒ e1 e ∪ e1 |{x1 . .e1 p(x1 . .Chapitre 4.. . . .e1 p(x1 . . . . xn ) : (⇒) σ(i) |=σ. . xn ) Cas ¬φ1 : (⇒) σ(i) |=σ. . . .e1 ¬φ1 ⇒ Par d´finition d’une formule croissante.

e1 e2 ⇒ d´finition de la s´mantique d´notationnelle e e e e ∃e2 ∈ φ1 ∧ φ2 σ.e1 φ1 ⇒ var(φ1 ) ⊆ dom(e1 ) et d´finition de la relation |= e σ(i) |=σ.e1 e2 . le lemme 4.i implique e = e. e e ∃e1 ∈ φ1 σ.12 nous dit que e ∈ φ e implique e e.e1 φ2 .i = ∅ ⇒ d´finition de la s´mantique d´notationnelle e e e e ¬φ1 σ. que e1 e1 .e1 e1 ⇒ Comme σ(i) |=σ. le lemme 4.e1 φ1 ∧ φ2 ⇒ Comme φ1 est croissante pour dom(e). e e1 ∃e2 ∈ φ2 σ. φ1 est croissante pour dom(e).i implique dom(e ) = dom(e). φ2 est croissante pour dom(e1 ).i . e On peut donc appliquer la direction ⇒ de l’hypoth`se d’induction sur e φ.σ(i) |=σ.e1 φ1 . et que par le lemme 4.Chapitre 4. ∃e e.i = ∅ ⇒ Par d´finition d’une formule croissante.i e ` e = e. σ(i) |=σ.i .11 nous dit que e ∈ φ e σ.e1 ¬φ1 Cas φ1 ∧ φ2 : (⇒) σ(i) |=σ. on peut appliquer la direction ⇒ de l’hypoth`se d’induction sur φ.i ⇒ d´finition de la s´mantique d´notationnelle e e e e φ1 σ.i = {e} ⇒ e1 e (e est donc le e2 voulu) e ∃e2 ∈ φ σ.e φ1 ⇒ e1 e σ(i) |=σ. a e φ1 σ.e1 e2 (⇐) e1 e2 et e2 ∈ ¬φ1 e tel que σ. on a donc e ∈ φ σ. et e1 e.i .11. D’autre part. on peut appliquer la direction ⇒ de l’hypoth`se d’induction sur φ. Comme dom(e ) = dom(e) et e e ´quivaut e σ.i . Logique d’acquisition de connaissances 126 ⇒ Comme var(φ1 ) ⊆ dom(e).

e ∃e2 ∈ φ1 e .e1 [φ1 . Comme la condition ne s’applique pas.i .e2 φ2 ⇒ d´finition de la relation |= e e1 e2 et σ(i) |=σ. φ2 ]. par d´finition de la s´mantique op´rationnelle.e2 φ1 ∧ φ2 ⇒ corollaire 4. soit e e e que σ(i − 1) |=σ. e e1 e1 e2 et σ(i) |=σ.e1 [φ1 .12. φ2 ].σ(i − 1) |=σ. φ2 est croissante sous dom(e1 ). e1 e2 et σ(i) |=σ. e e1 e2 et σ(i) |=σ. Premier cas : σ(i − 1) |=σ.e1 φ1 et e2 ∈ φ2 σ.i ⇒ Comme φ1 ∧ φ2 est croissante pour dom(e).e1 [φ1 . Logique d’acquisition de connaissances 127 (⇐) e1 e2 et e2 ∈ φ1 ∧ φ2 e σ. on peut appliquer a la direction ⇒ de l’hypoth`se d’induction sur φ.Chapitre 4. comme il n’existe pas de j < 0.6 σ(i) |=σ.e1 φ1 ∧ φ2 Cas [φ1 . a u (⇒) Si σ(i) |=σ.11.i−1 ⇒ d´finition de la s´mantique d´notationnelle e e e . par d´finition.e1 φ1 . φ2 ] et ∃e1 e1 |var(φ1 ) .i ⇒ Par le lemme 4. on peut donc appliquer le corollaire 4. φ2 ]. u Il reste ` montrer le cas o` φ = [φ1 .6. alors. φ1 est e croissante pour dom(e).e2 φ2 ⇒ Par le lemme 4. e e e il n’existe pas de e1 tel que σ(i) |=σ.e1 φ1 ⇒ Comme φ1 est croissante par rapport ` dom(e1 ). On peut donc appliquer la direction ⇐ de l’hypoth`se d’induction. e2 e1 .i ⇒ d´finition de la s´mantique d´notationnelle e e e e1 e e1 e2 et ∃e1 ∈ φ1 σ. soit que σ(i − 1) |=σ. On peut donc appliquer encore une fois la direction ⇐ de l’hypoth`se d’induction. ce cas du th´or`me est v´rifi´.e2 φ1 et σ(i) |=σ.e1 φ1 et σ(i) |=σ.e1 e2 σ. φ2 ] : (⇔) Par d´finition de la s´mantique op´rationnelle.e1 φ2 . e e e e Cas i > 0 : Les trois premiers cas de l’induction sur φ sont identiques au cas o` i = 0.e2 ∈ φ2 σ.

φ2 ] et ∃e1 e1 |var(φ1 ) . ´tant e donn´ que e2 |var(φ1 ) = e1 |var(φ1 ) . var(φ1 ) ⊆ dom(e2 ).i−1 . e e2 |dom(φ e ∃e2 ∈ [φ1 . Logique d’acquisition de connaissances 128 ∃e2 ∈ [φ1 . par le lemme 4.e1 φ2 ⇒ Comme. φ2 ] e =∅ σ. σ(i − 1) |=σ.σ(j) |=σ. φ2 ] σ.11.σ(i − 1) |=σ. on peut appliquer la direction ⇐ de e l’hypoth`se d’induction sur φ.Chapitre 4.i−1 1 ) [φ1 .i . φ2 ] σ.e1 e2 (⇐) Si e2 ∈ e2 |var(φ φ2 σ.e1 φ2 ⇒ direction ⇒ de l’hypoth`se d’induction sur i e e ∃e2 ∈ [φ1 .i .i−1 ⇒ direction ⇒ de l’hypoth`se d’induction sur i (deux fois) e e1 e2 et σ.e1 [φ1 .i .i−1 et est tel que = ∅. φ2 ] e σ.σ(k) |=σ. φ2 ] σ.e1 φ1 et j < k < i.e1 [φ1 .i−1 ⇒ Par d´finition d’une formule croissante.e1 e2 et φ2 σ.σ(i − 1) |=σ. φ2 est croissante pour dom(e2 )|var(φ1 ) . φ2 ] e σ.e1 φ1 ⇒ i − 1 < i et k.i−1 1 ) = ∅ ⇒ d´finition de la s´mantique d´notationnelle e e e e ∃e2 ∈ [φ1 .i − 1 < k < i ∃j < i.e1 e2 et ∃e1 e1 |var(φ1 ) .e1 e2 σ(i − 1) |=σ.σ(i − 1) |=σ. alors e2 ∈ φ1 e σ. e1 e1 |var(φ1 ) . φ2 ] et e2 e2 |var(φ1 ) .i−1 . et que φ2 est croissante pour var(φ1 ).e2 φ2 ⇒ e1 e2 e2 |var(φ1 ) et transitivit´ de e e2 | . Alors. i − 1 |=σ. φ2 ] Second cas : var(φ1 ) e1 e2 et e2 ∈ [φ1 .i−1 et φ2 σ. φ2 ] Second cas : e σ.e1 φ2 ⇒ d´finition de la relation |= e σ(i) |=σ. Premier cas : e1 e2 et e2 ∈ φ1 e σ. e on peut donc appliquer la direction ⇐ de l’hypoth`se d’induction sur e φ.i−1 ou e2 ∈ [φ1 .e1 [φ1 . φ1 est croissante pour dom(e).

Le probl`me. dans le contexte d’une logique pass´e.Chapitre 4. ou encore e e e ˆtre associ´s ` plusieurs valeurs diff´rentes. mais a simplement une base de connaissances. e Nous avons aussi vu comment un mod`le et une s´mantique bas´s sur un concept e e e d’unification permettent de mieux mod´liser le fait que diff´rents paquets contiennent e e diff´rentes entˆtes de protocoles. φ2 ]. ou les r´seaux de Petri avec IDIOT.e1 φ2 ⇒ d´finition de la relation |= e σ(i) |=σ. Nous croyons qu’une impl´mentation judicieuse e des algorithmes que nous avons pr´sent´s devrait tenir compte de la nature globale de e e . que certains champs puissent ˆtre optionnels. utilisant d’autres formalismes pour les sc´nae rios.σ(i − 1) |=σ. on peut utiliser le corollaire 4. En fusionnant les e concepts de sc´nario et de connaissance. φ2 ] Les deux cas ´tant d´montr´s. au niveau de l’implantation. φ2 ] est sufe fisant pour mod´liser ` la fois l’acquisition de connaissances et les sc´narios d’attaque e a e s’´tendant sur plusieurs paquets. nous avons vu que cet op´rae e e e teur permet aussi bien de mod´liser les sc´narios ` reconnaˆ que ceux d’une logique e e a ıtre future. avec une logique future. li´ ` l’ajout d’op´rateurs pass´s. nous ea ee e e e avons r´solu ce probl`me en permettant de g´rer. i − 1 |=σ.e1 [φ1 . est que l’on ne peut pas exprie e mer la condition si tel comportement a d´j` ´t´ observ´. Nous avons donc vu que l’op´rateur [φ1 . De plus. Ceci compl`te le dernier cas d’induction et par le fait mˆme la e e d´monstration du th´or`me. φ2 ] et e1 e1 . mais aussi dans LogWeaver. e e ont eux aussi cette notion de sc´nario en cours de reconnaissance. sont e mod´lis´s par l’utilisation de l’op´rateur [φ1 .6 pour conclure que e e e σ(i) |=σ. permet d’oublier une fois pour toutes le concept de ea e e formule en cours de reconnaissance. l’utilisation du concept d’unificae e a e tion. Eagle et e Chronicles. qui non-seulement ´tait pr´sent dans l’approche que e e nous avons propos´e utilisant une logique future. nous avons vu comment l’utilisation d’une logique pass´e permet e de mod´liser l’acquisition passive d’information dans un paradigme qui soit compl`tee e ment d´claratif. tout devient de la connaissance acquise. De plus. On e n’a plus besoin de tenir ` jour un ensemble de formules partiellement satisfaites. une base e e e de connaissances ` laquelle il ´tait possible de dynamiquement ajouter et retirer des a e connaissances. Au chapitre pr´c´dent. Ces ajouts et ces retraits.e1 [φ1 . les autres approches. De plus. tels que les syst`mes de transition avec STATL. φ2 ].5 Conclusion Dans ce chapitre. Logique d’acquisition de connaissances 129 σ. e e e 4.e1 [φ1 . les rendant ainsi superflus.

Dans le cas du premier e e e e ordre. Aussi. ´tant donn´e la fa¸on dont l’algorithme est d´crit. ou du moins toujours born´e par e ee e e e une certaine constante (ce qui est tout de mˆme une hypoth`se raisonnable) le probl`me e e e se poserait toujours. En fait. Dans le cas du premier ordre. L’analyse de la comee plexit´ en espace est le cas le moins compliqu´. le probl`me se situe au niveau de la base de connaissances. et utilise une quantit´ constante d’espace m´moire. Comme ces op´rateurs peuvent ˆtre d´finis synee e e e e e taxiquement ` partir des op´rateurs existant d´j`.Chapitre 4. L’analyse de ce dernier algorithme n’a pas encore ´t´ faite. Logique d’acquisition de connaissances 130 la connaissance acquise pour offrir une factorisation efficace ` la fois du code ex´cutable a e et des sp´cifications. ainsi que complet e e et coh´rent. Le raisonnement ` effectuer pour arriver ` ce r´sultat est le mˆme que dans le a a e e cas propositionnel. nous e ee ´ avons choisi le nombre d’appels ` la fonction verif. Etant donn´ que les op´rations a e e effectu´es ` l’int´rieur de chacun de ces appels ´taient facilement associables ` des op´e a e e a e rations pouvant s’effectuer en temps constant. l’algorithme que nous avons pr´sent´ est lui aussi en-ligne. le langage que nous avons d´velopp´ permet d’exprie e e mer assez simplement des contraintes de temps-r´el sans faire d’hypoth`se particuli`re e e e sur le mod`le des donn´es ni modifier en quelque fa¸on que ce soit l’algorithme de e e c v´rification. En fait. il s’agit d’un algorithme en-ligne. Le proe bl`me est qu’il nous semble difficile. on peut tout de suite dire e e qu’elle est de l’ordre de |φ||var(φ)||V|. nous ne croyons pas que ces conditions soient particuli`rement a e e restrictives. et nous n’avons donn´ que la sp´cification de celles-ci. De plus. c’est-`-dire qui n’a jamais besoin a de retourner en arri`re pour consulter les ´v´nements pass´s. e e e c e de s’arrˆter sur le choix d’une instruction ´l´mentaire. la quantit´ d’information accumul´e avance a e e elle aussi et que les tentatives d’unification avec la base de connaissances prendront de . sans e e e entrer dans les d´tails. ` condition de respecter certaines conditions syntaxiques sur les formules e a ` v´rifier. il existe un algorithme de v´rification dont le temps d’ex´cution augmente lin´airement avec la taille de la e e e trace ` analyser. cet ajout ne complique en rien les a e ea algorithmes de v´rification. nous avons vu que dans le cas propositionnel. Mˆme si la taille des ´v´nements (le nombre de tuples associ´s ` e e e e e a chaque pr´dicat ´l´mentaire) ´tait toujours la mˆme. e Il est clair qu’` mesure que le temps avance. L’analyse en temps ne s’av`re cependant pas aussi simple. Pour le cas propositionnel. e L’ajout d’op´rateurs d’approximants dans la syntaxe nous a permis d’exprimer sime plement des propri´t´s de r´p´tition. e Finalement. Nous avons aussi a e e prouv´ que cet algorithme est complet et coh´rent par rapport ` la s´mantique de la e e a e logique. o` V est le domaine des valeurs unifiables ` une u a variable. Cependant. cette mesure nous semblait raisonnable. les op´rations effectu´es ` l’int´rieur de chaque appel sont e e a e des op´rations d’unification.

Pour ces raisons. Logique d’acquisition de connaissances 131 plus en plus de temps. ee . D’un autre cˆt´. dire que l’algorithme s’ex´cute en temps O(|σ|) e est th´oriquement correct. une base de connaissance pleine ` craquer. d’une taille assomante. il est raisonnable de penser que la taille de la base de connaissances viendra ` se stabiliser. le mˆme raisonnement que pour le cas propositionnel nous am`ne e e e ` dire que la quantit´ d’espace m´moire utilis´ est born´e. mais nous savons bien que la constante cach´e peut ˆtre. Autrement dit. il oe e est fort possible que le pire cas n’arrive pas si souvent que ¸a. D’un autre cˆt´. d’un point a ea de vue th´orique. l’analyse de l’algorithme dans le cas du premier ordre n’a pas ´t´ faite. en e e e pire cas.Chapitre 4. Cependant. avec des sp´cifications bien choisies. et aussi c ` cause du fait que nous ne disposons pas d’une op´ration ´l´mentaire ` utiliser comme a e ee a mesure. Comme nous l’avons d´j` dit. d’un point de a e e e e vue pratique. en supposant born´ le domaine des valeurs oe e auxquelles les variables sont unifiables. bien que ne demandant pas un a temps d’ex´cution grandissant. peut tout de mˆme demander un temps qui soit inaccepe e tablement trop grand.

Chapitre 5 Travaux futurs
Dans ce travail, nous avons d´velopp´ un nouveau langage de signatures pour les e e syst`mes de d´tection d’intrusions. Le focus a principalement ´t´ mis sur l’expressivit´ e e ee e de ce langage, de mˆme que sur les aspects algorithmiques reli´s ` son impl´mentation. e e a e L’utilisation d’un paradigme bas´ sur une logique temporelle nous a permis, dans le e cadre du travail effectu´, de d´velopper un langage qui soit purement d´claratif, au sens e e e o` l’utilisateur n’a pas ` se soucier de la fa¸on dont l’algorithme de v´rification s’ex´cute u a c e e pour sp´cifier ses signatures. L’utilisation d’une logique temporelle pr´sente cependant e e d’autres avantages, et ouvre la voie pour nos futurs travaux de recherche. Dans cette section, nous donnons quelques exemples de directions de recherche que nous pr´voyons e explorer dans les mois ` venir. a

5.1

Satisfiabilit´ e

Un des avantages reli´s ` l’utilisation d’un paradigme bas´ sur une logique est de e a e permettre la v´rification de la coh´rence de la base de r`gles. La s´mantique du langage e e e e d´velopp´ s’applique aux ´tats d’une trace, et il est sous-entendu qu’une trace σ satisfait e e e une politique φ donn´e si et seulement si pour chaque ´v´nement σ(i), on a σ(i) |=σ φ. e e e Il existe cependant des formules qui ne sont satisfaites par aucune trace. De telles ` formules sont appel´es contradictions. A la figure 5.1, on trouve quatre exemples de e contradictions. La premi`re est une contradiction au niveau propositionnel, c’est-`e a dire que non-seulement n’est-elle pas satisfiable par aucune trace, mais elle ne l’est pas non-plus pour aucun ´tat d’aucune trace. La deuxi`me formule est un exemple de e e contradiction qui se situe au niveau temporel. Elle est satisfaite par les ´tats qui ont ´t´ e ee

Chapitre 5. Travaux futurs

133

p ∧ ¬p [p, faux] [vrai, p] p → [q, faux] ∧ q → [p, faux] ∧ (p ∨ q) Fig. 5.1 – Exemples de contradictions.

pr´c´d´s par un ´tat o` p ´tait vrai. Certainement, cette formule n’est jamais satisfaite e e e e u e par le premier ´tat d’une trace. Cons´quemment, elle n’est satisfiable par aucune trace e e et il s’agit d’une contradiction. La troisi`me est une contradiction pour la mˆme raison. e e Bien que la formule vrai soit satisfaite par tous les ´tats, il n’existe pas d’´tat pr´c´dent e e e e le premier ´tat d’une trace. En particulier, aucun ´tat pr´c´dent σ(0) ne satisfait vrai. e e e e La quatri`me formule est une contradiction au niveau des contraintes temporelles. Elle e dit que q doit survenir avant p, et que p doit survenir avant q. Sans la partie p ∨ q, cette formule pourrait ˆtre satisfaite par les traces o` p et q ne surviennent jamais. e u Dans un mˆme ordre d’id´es, les formules qui sont satisfaites par tous les ´tats de e e e ` priori, les tautologies et les contradictoutes les traces sont appel´es des tautologies. A e tions ne sont pas des politiques de s´curit´ pertinentes, puisque l’on sait ` l’avance si e e a elles seront satisfaites. Il serait donc utile de pouvoir les d´tecter ` l’avance. Une telle e a ` d´tection constituerait une premi`re ´tape en vue de la validation d’une politique. A la e e e e a e table 5.1, on peut voir un syst`me de preuves ` base de tableaux permettant de v´rifier si un ´tat d’une trace donn´e satisfait une formule. Les trois premi`res r`gles d’inf´e e e e e rence sont celles du calcul propositionnel, et les trois derni`res concernent l’op´rateur e e temporel [φ1 , φ2 ]. Ce syst`me de preuves ne permet cependant pas de v´rifier si une e e formule donn´e est une tautologie, une contradiction, ou ni l’une ni l’autre. Une avenue e possible pour la d´tection des tautologies et des contradictions pourrait ˆtre d’´tendre e e e ou de modifier ce syst`me de preuves de fa¸on ` tenir compte des noeuds d´j` travers´s e c a ea e dans l’arbre de preuves. Un peu plus loin dans ce chapitre, nous proposerons cependant une autre fa¸on de c d´tecter les tautologies et les contradictions qui utilise seulement les trois premi`res e e r`gles de ce syst`me de preuves. Juste avant, nous verrons comment il pourrait ˆtre e e e possible d’am´liorer la s´mantique du langage que nous avons d´velopp´ de fa¸on ` en e e e e c a faire non-pas un simple langage de d´tection, mais aussi un langage de contrˆle. Nous e o utilisons les terme contrˆle plutˆt que r´action pour mettre en ´vidence le fait que la o o e e seule r´action permise par l’extension que nous proposons est de bloquer les actions e malicieuses. L’extension ne permet pas, telle quelle, d’engendrer des actions.

Chapitre 5. Travaux futurs

134

p ∈ σ(i) p, σ(i)

⊥ φ, σ(i) ¬φ, σ(i)

φ1 , σ(i) φ2 , σ(i) φ1 ∧ φ2 , σ(i)

φ1 , σ(i − 1) [φ1 , φ2 ], σ(i − 1) ¬φ2 , σ(i − 1) ⊥ [φ1 , φ2 ], σ(0) [φ1 , φ2 ], σ(i) [φ1 , φ2 ], σ(i)

Tab. 5.1 – Syst`me de preuves ` base de tableaux. e a

5.2

Filtrage dynamique et s´mantique de symptˆme e o

Une tendance dans l’implantation de syst`mes de d´tection d’intrusions au niveau e e r´seau est d’incorporer ceux-ci ` des composantes du r´seau qui ont le contrˆle du trafic e a e o pouvant entrer et sortir du r´seau [75, 76, 77, 78]. Les routeurs et les pare-feux sont e des exemples de telles composantes. Par exemple, on peut int´grer Snort au syst`me e e d’exploitation d’un routeur et bloquer tous les paquets g´n´rant une alarme. e e Le bien-fond´ d’une telle m´thode de travail repose cependant sur l’hypoth`se que e e e les signatures repr´sentent bel et bien les attaques, et non l’effet de celles-ci. En effet, e une tendance en d´tection d’intrusions est d’´crire des signatures qui ne lanceront des e e alarmes que si l’effet de l’attaque est d´tect´, et non l’attaque elle-mˆme. Cette teche e e nique est principalement motiv´e par le besoin de diminuer le nombre de faux positifs. e Prenons, par exemple, la propagation d’un vers dans un r´seau local. Supposons qu’un e utilisateur A re¸oive par un courrier ´lectronique envoy´ par son meilleur ami un petit c e e jeu rigolo permettant la fois de punir son politicien pr´f´r´ ` l’aide d’un tue-mouche et eeea d’infecter son ordinateur d’un virus qui essayera alors de se propager aux stations de travail avoisinantes. Le virus utilise alors chaque machine infect´e comme relais pour e en infecter d’autres, et ainsi de suite. Supposons, de plus, que ce virus exploite une vuln´rabilit´ du syst`me d’exploitation Windows contre laquelle 117 stations des 120 e e e du r´seau local sont pr´munies. Une signature concernant le comportement offensif g´e e e n´rerait alors des alarmes pour les 120 machines attaqu´es, alors qu’une signature pour e e l’effet de l’attaque ne g´n`re des alarmes que pour les trois machines qui sont r´ellement e e e affect´es. Le responsable de la s´curit´ du r´seau peut alors r´agir plus efficacement car e e e e e il sait exactement quelles sont les machines infect´es. e Dans le cas du langage que nous avons d´velopp´, certaines des signatures que nous e e

si e une r`gle de type attack a ´t´ viol´e. En second lieu. en premier lieu. et cet ´v´nement ne doit en aucun cas ˆtre e e e e e consid´r´ comme offensif. 3] → ack e e e dont nous avons discut´ ` la page 105.σ(i) |=σ φj et si ∃φj de type attack tel que σ(i) |=σ φj alors σ(i + 1) |=σ−σ(i) Φ et si ∃φj de type attack tel que σ(i) |=σ φj alors σ(i + 1) |=σ Φ Tab. l’´v´nement courant doit ˆtre retir´ de la trace e ee e e e e e . e e L’approche que nous proposons ici a en commun avec celle de Cuppens le fait qu’elle permet de mieux d´cider quelles sont les actions qui doivent ˆtre bloqu´es. Les e actions malicieuses. soit de type symptom. la formule synack∧[syn. e o avons propos´es. Une trace d’´v´nements satisfait la ea e e e e politique Φ si elle est satisfaite depuis le premier ´v´nement.2 – S´mantique de symptˆme. Une avenue possible pour s’attaquer ` ce probl`me pourrait ˆtre de typer les formules a e e constituant une politique de s´curit´ de fa¸on ` diff´rencier les symptˆmes des attaques. Prenons. 5. L’´v´nement permettant la d´tection de l’attaque ea est le premier suivant l’´coulement du d´lai. Cuppens et al. ont propos´ de partitionner les actions en actions malicieuses et suspicieuses. Une politique de s´curit´ Φ est une conjonction de o e e r`gles φj qui sont soit de type attack.2. Les r`gles φj sont r´dig´es e e e e dans le langage que nous avons d´j` d´velopp´. il satisfait toutes les r`gles. entrent directement en conflit avec la politique de s´curit´. l’´v´nement e u e e e e permettant de d´tecter l’attaque n’est pas du tout li´ ` celui correspondant au compore ea 2 tement offensif en tant que tel. Les actions suspicieuses ne sont pas offensives en tant que telles. Un ´v´nement de la trace e e e e satisfait la politique Φ si. par exemple. ee o e et ne fait pas partie l’attaque elle-mˆme. Travaux futurs 135 Φ σ |= Φ σ(i) |=σ Φ ::= (attack|symptom)φj ssi σ(0) |=σ Φ ssi ∀j. Il n’est qu’un symptˆme permettant la d´tection de l’attaque. on voit comment on peut formaliser la r´daction de politiques de s´curit´ pour un syst`me de d´tection d’intrusions avec capacit´s de contrˆle en utilisant e e e e e o la dichotomie attaques/symptˆmes. e e c a e o e Dans le cas du langage LAMBDA [29]. e e e ` e A la table 5. C’est pourquoi un syst`me de d´tection d’ine e e trusions muni de fonctionnalit´s de contrˆle bloquant cet ´v´nement commettrait alors e o e e une erreur.Chapitre 5. mais peuvent contribuer au succ`s d’une attaque. notamment celles o` on exprime l’´coulement d’un d´lai. elles.

e e e e on obtient la trace p. Dans le cas o` aucune e a e e u attaque n’a ´t´ rep´r´e. q. . . e Une telle s´mantique permet de g´rer certains conflits au niveau de la politique e e de s´curit´. on obtient une trace o` seulement un ´v´nement e e u e e contrevient ` la politique. Si l’´v´nement e e o e e e e est retir´ de la trace. 5. On a donc un conflit entre la satisfaction de la e e e sous-formule q → ¬[p. e 5. car elle pr´sente e un r qui n’est pas pr´c´d´ d’un q. . r. De plus. . e e e lorsque l’on commence ` donner la possibilit´ au programme de v´rification de modifier a e e le mod`le en cours d’ex´cution. En conservant l’´v´nement q. nous sommes certains que nous avons bien fait de conserver q a puisque sa s´mantique n’est pas offensive. faux]. alors qu’en supprimant cet ´v´nement. avant de continuer la d´tection ` partir de l’´v´nement suivant. . Travaux futurs 136 q → ¬[p. que l’on appellera d`s e e e e lors contrˆleur. Cependant. faux] p. La trace p. revenons ` a notre s´mantique de symptˆmes et supposons que l’on ait la chance de travailler dans e o un contexte o` la premi`re sous-formule repr´sente un symptˆme et la seconde une u e e o attaque. En supprimant ce q. Elle dit que si q survient. Oublions-la pour quelques instants et consid´rons la formule montr´e ` la e e e e a figure 5. qui ne satisfait pas non-plus la formule. car elle pr´sente un q pr´c´d´ d’un p. au sens o` le probl`me u e auquel nous nous attaquions concernait la v´rification de certaines traces d’ex´cution e e d’un syst`me donn´. Un tel programme de v´rification. l’´v´nement courant est conserv´ dans la trace et on continue la ee ee e e e d´tection ` partir de l’´v´nement suivant. la politique ´tait viol´e a e e e e ` deux endroits.2. L’action de retrait d’un ´v´nement de la trace e a e e e e mod´lise la capacit´ de contrˆle du syst`me de d´tection d’intrusions. . Fig. .Chapitre 5.. peut ˆtre vu comme partie int´grante du syst`me en cours de validation. o e e e . q. ne satisfait pas cette formule. et que si r survient. Maintenant. faux] ∧ r → [q. . faux] et la sous-formule r → [q. r. r. et non celle de toutes ses traces d’ex´cution possibles. alors il ne doit pas y avoir eu de p auparavant. nous avons dit que le travail que nous e allions effectuer s’inscrivait dans un contexte de validation.2 – Exemple de conflit.3 Synth`se de contrˆleur e o Au chapitre d’introduction de ce m´moire. alors son effet ne doit pas ˆtre pris en compte dans la poursuite e e de la d´tection. . il ne s’agit plus d’un probl`me de validation tant que e e e d’un probl`me de synth`se. alors il doit y avoir eu un q auparavant.

82]. mais simplement e d’automates. la s´mantique que nous leur accordons est directement exprim´e en fonce e tion de ces traces.A1 ) (A1 + A2 ) (A1 × A2 ) avec a. g´n´rer un programme C tel que C × P |= φ. (A1 ) = (A1 ) ∪ = (A1 ) ∩ (A1 ) (A2 ) (A)} (A) = {a.A1 | A1 + A2 | A1 × A2 Tab. d´finissons pr´cis´ment de quels automates nous parlons. la e e e r´solution de ce probl`me d´pend uniquement de φ. 5. Or. il y a fortement lieu de penser que e lorsque φ est exprim´e avec le cas propositionnel de la logique que nous avons utilis´e e e pour d´velopper notre langage. C’est pourquoi nous ne parlons pas ici d’alg`bre de processus. L’automate 0 ne peut faire que l’action stop et s’arrˆter. e e Avant d’aller plus loin dans l’annonce des conjectures auxquelles nous comptons nous attaquer. soit un automate pouvant faire une action a avant de devenir un autre automate (a. 81. Un automate est soit l’automate ne e e e a pouvant faire aucune action (0). soit un automate pouvant arbitrairement adopter le comportement de deux autres automates (A1 + A2 ).Chapitre 5. Nous n’avons pas besoin.A1 ). e (0) (a. et e ea ee e e son niveau de difficult´ varie d´pendemment de l’alg`bre utilis´e pour repr´senter P e e e e e et C et de la logique utilis´e pour exprimer φ. 5. une propri´t´ φ. pour la port´e de notre propos. Aussi. comme tout notre int´rˆt tourne autour des traces d’ex´cution de ee e ces automates. de d´finir e e le parall´lisme entre deux automates ni de s’attarder ` d´finir une relation d’´quivae a e e lence. 80. e e Ce probl`me a d´j` ´t´ largement explor´ dans la litt´rature [79. L’automate e .1 Etant donn´ un programme P . et une loi de composie e ee tion de programmes ×.3.σ | σ ∈ Tab. Travaux futurs et le probl`me de la synth`se du contˆleur pourra alors s’´noncer comme suit : e e o e 137 ´ Probl`me 5. soit le produit synchrone de deux automates (A1 ×A2 ). et que l’alg`bre utilis´e est celle des automates finis.4 – S´mantique de l’alg`bre des automates. La syntaxe de e e e l’alg`bre des automates est pr´sent´e ` la table 5. e e e A ::= 0 | a.3 – Syntaxe de l’alg`bre des automates. = {stop} = a.

3. dans notre cas. ` A la figure 5. mais pas compl`tement d´fini. L’automate A1 + A2 peut faire toutes les traces de A1 . un contrˆleur pour un automate relativement ` une formule φ : o a D´finition 5. 5.Session rst. Finalement.T CP rst. Dans notre logique.Contr + syn.Contr + f in. Supposons.S3 + ack. Il aurait aussi bien e e e pu ne pas ˆtre d´terministe. Travaux futurs 138 T CP S2 S3 Session ::= ::= ::= ::= rst. Contr C2 C3 Session ::= ::= ::= ::= rst. suivie de toutes les traces que peut effectuer l’automate A1 . Cet automate peut compl´ter une poign´e de e e e e main (syn. l’automate A1 × A2 peut faire les traces que A1 et A2 peuvent faire.2 Un automate A1 contrˆle un automate A2 relativement ` une formule e o a φ si pour toute trace σ ∈ (A2 ). Une session e peut se terminer en posant une action f in avant de retourner ` l’´tat initial. e e Maintenant que nous avons d´fini notre alg`bre.Contr Fig.C3 rst.synack. l’action rst retourne ` l’´tat initial.T CP + syn.T CP rst.Contr + ack. cette propri´t´ se formule e e ee .T CP rst. que l’on veuille contrˆler la propri´t´ : l’action rst ne doit o ee pas ˆtre pos´e entre un synack et un ack.Session + f in. Aussi. on voit comment on peut utiliser cette alg`bre pour repr´senter une e e version tr`s simplifi´e de l’automate TCP. ack]).3 – Automate TCP.Chapitre 5. peu a e importe dans quel ´tat il se trouve.A1 peut faire l’action a.4 – Contrˆleur pour l’automate TCP relativement ` ¬(rst ∧ [synack.C2 synack. σ ∈ (A1 × A2 ) ⇔ σ |= φ. On remarque e a e que cet automate est d´terministe. o a a. 5.ack) pour devenir l’automate repr´sentant une session.S2 + synack. nous sommes en mesure de d´finir e e e ce qu’est. de mˆme que toutes celles de e A2 . par exemple.T CP Fig.

si on ´tait capable. e o e e e Ceci nous am`ne ` d´finir la notion de contrˆleur universel : e a e o D´finition 5. avec [φ] = {[φ1 . e o de la fa¸on suivante : ¬(rst ∧ [synack. 5.5 – Algorithme de synth`se de contrˆleur. En effet.5. de e e e e donner un automate engendrant toutes les traces σ telles que σ |= φ. σ ∈ (A) ⇔ σ |= φ. e Comme nous avons d´j` donn´ un algorithme de v´rification pour notre logique. cet automate engendre toutes c les mˆmes traces que celui de l’automate TCP. L’ensemble des ´tats correspond e a e exactement ` l’ensemble des valeurs pouvant ˆtre prises par l’ensemble k de l’algorithme a e .Chapitre 5. Si A est un contrˆleur universel pour φ. ´tant donn´e une formule φ. on ea e e devrait s’attendre ` pouvoir transformer cet algorithme en automate et ainsi de pouvoir a d´finir un contrˆleur universel pour n’importe quelle formule φ. Travaux futurs 139 S Act s0 s1 → s2 a := := := 2[φ] . Rien ne nous pousse ` croire que cette solution ´tait l’unique solution. Donc. si le contrˆleur que nous avons d´fini avait ´t´ capable d’engendrer des traces o e ee que l’automate TCP n’´tait pas capable d’engendrer. En e a e particulier. ack]). celle-ci auraient ´t´ supprim´es e ee e par l’op´ration de produit. sauf celles o` un rst survient entre un e u synack et un ack.3 Un automate A est un contrˆleur universel pour une formule φ si pour e o toute trace σ. le probl`me de la e synth`se du contrˆleur tel que nous l’avons ´nonc´ serait r´solu une fois pour toutes. Nous avons construit cet automate de fa¸on ad-hoc. φ2 ] ∈ sub(φ)} 2P ∅ ssi ϕ(s1 ) ∧ ϕ(a) φ et σ(i) |= ϕ(s1 ) ∧ ϕ(a) implique σ(i + 1) |= ϕ(s2 ) := φi ∈s1 ϕ(s) ϕ(a) φi ∧ φi ∈s1 ¬φi ¬p := p∈a p∧ p∈a Tab. Cette transformation e o donne exactement l’automate d´fini ` la table 5. sans vraiment suivre de m´thode c e particuli`re. on dit que o A impl´mente φ.

C + f in.5 Une formule φ est une contradiction (n’est pas satisfiable) si l’automate d´fini ` la table 5. et elle est une tautologie si il est e a compl`tement d´fini. Lorsque la formule e a [synack. e Nous ´non¸ons maintenant deux r´sultats que nous contons d´montrer dans les mois e c e e ` suivre. De plus. ne m`ne pas ` e a e e e a une violation de la propri´t´ φ et si. ack]).5 impl´mente φ.C1 + f in. ack] est vraie. Travaux futurs 140 L(C) L(C1 ) C C1 = = ∅ {[synack. une fois l’action pos´e. Conjecture 5. ack] est vraie. 5. si le fait de poser l’action a m`ne ` une violation de φ. l’´tat ee e a e s1 n’a pas de transition sortante pour a. celui o` la formule [synack. ack]} := synack. et le second nous dit comment on peut utiliser cet automate e pour trouver des tautologies et des contradictions. l’automate d´fini ` la table 5.C := synack. L’ensemble des actions pouvant ˆtre e e ea e pos´es correspond ` l’ensemble des ´v´nements (une action ou un ´v´nement est un e a e e e e ensemble de constantes propositionnelles).5 – Contrˆleur universel pour ¬(rst ∧ [synack. il est impossible de poser l’action rst. se trouve un contrˆleur universel pour la formule ¬(rst∧[synack. Finalement.C + rst. les r`gles d’inf´rences du calcul propositionnel (les trois e e e e e premi`res de la table 5. et celui o` elle ne l’est e e u u pas.C +syn.7 (page 116). il ne peut y avoir qu’un seul ´tat s2 d´fini pour s1 et a. Les actions synack et ack font passer d’un ´tat ` l’autre. ` A la figure 5.C1 + ack.C1 Fig. dans l’´tat s1 . o de v´rification pr´sent´ ` la table 4. o Il poss`de deux ´tats.Chapitre 5. Une action a effectu´e ` partir d’un ´tat e a e s1 m`ne ` un ´tat s2 si le fait de poser cette action.C1 + ack.C +syn.1) suffisent pour d´cider si le fait de poser l’action a viole le e propri´t´ φ. Le premier dit que l’automate d´fini ` la table 5. la connaissance accumul´e ee e e correspond ` celle repr´sent´e dans l’´tat s2 .5. ack]).5 n’engendre pas de traces. e c e e comme toute l’information pertinente concernant les actions pos´es jusqu’` maintenant e a est accumul´e dans l’´tat s1 . e e . Toutes les autres actions sont possibles et ne changent pas l’´tat courant.4 Pour toute formule φ. Comme l’´volution de la connaissance est a e e e e d´finie de fa¸on unique. e a e Conjecture 5.5 impl´mente bien la propri´t´ a e a e ee φ pour laquelle il est d´fini.

Certains travaux ont d´j` ´t´ effectu´s dans ea ee e cette direction dans [83]. . ne suffira plus. il faudra voir comment on peut adapter ces id´es e e e e ` la logique du premier ordre de la logique que nous avons utilis´e pour notre langage. e e oe mais seulement certaines de ses actions. Certainement. il faudra voir comment on peut incorporer les concepts de symptˆme et d’attaque o au probl`me de synth`se du contrˆleur.Chapitre 5. au sens o` la violation d’un o u certain sous-ensemble de la politique ne bloque pas compl`tement le syst`me contrˆl´. Travaux futurs 141 Une fois ces r´sultats d´montr´s. avec son e e o e produit compl`tement synchrone. a e Aussi. Il faudra voir comment on peut d´finir e e une loi de composition permettant un contrˆle partiel. l’alg`bre des automates.

en fonction des paradigmes e e utilis´s pour d´finir les langages. cette fois bas´ sur une logique temporelle e e pass´e. Nous avons alors d´fini un second langage. Le syst`me r´sultant pr´sentait e e e e e une architecture ` deux niveaux. dress´ une liste e e a e e de dix propri´t´s identifi´es comme souhaitables pour le langage de signatures d’un ee e syst`me de d´tection d’intrusions. e e Une des cinq cat´gories selon lesquelles nous avons class´ les langages des syst`mes ` e e e a base de signatures est celle de ceux bas´s sur des logiques temporelles.Conclusion Dans ce travail. que nous avons r´partis en cinq cat´gories. avec une s´paration claire entre les sc´narios et la a e e connaissance acquise. e e Une fois r´alis´e l’´tude des logiques. Il s’est av´r´ qu’en plus que d’ˆtre beaucoup mieux adapt´ ` la surveillance de e ee e ea . Les diff´rences les plus importantes entre ces e e a e logiques. Nous avons commenc´ par effectuer un ´tat de l’art des langages de signatures e e d´j` existants. Nous avons aussi. Bien que le syst`me mis e e ee a e e e e en oeuvre ne comportait pas encore toutes les caract´ristiques recherch´es. suite ` cette ´tude. ` laquelle nous avons e a ajout´ la capacit´ de r´f´rer ` certains ´v´nements pass´s. le langage e e d´velopp´ a permis de clarifier nos id´es quand ` la fa¸on dont devrait se formaliser e e e a c l’acquisition passive d’information. La partie du langage servant ` repr´senter les sc´narios pouvait a e e ˆtre vus comme un sous-ensemble d’une logique temporelle future. ´tant donn´s nos besoins. Comme cette voie e nous semblait ˆtre la plus prometteuse. Nous avons trouv´ que plusieurs logiques avaient ´t´ d´velope ee e p´es pour r´pondre ` plusieurs besoins. et la capacit´ d’exprimer des contraintes de temps-r´el. sont la direction des op´rateurs temporels (pass´s e e e e ou futur). nous avons ensuite approfondi nos connaissances e en logiques temporelles. nous avons d´fini et impl´ment´ un langage de e e e e e e signatures ayant la capacit´ d’acqu´rir passivement de l’information dans le principal e e but d’effectuer une d´tection d’intrusions plus pr´cise. Nous avons donn´ un nouveau syst`me de classification des langages ea e e de signatures. nous avons ´tabli les bases d’un nouveau langage de signatures e d’attaques pour un syst`me de d´tection d’intrusions et d’acquisition passive d’infore e mation.

Ce mod`le imposait cependant une e e e e e certaine vision de la r´alit´ : tous les ´v´nements sont caract´risables par un ensemble e e e e e donn´ de champs attribut-valeur. Finalement. la syntaxe du langage e e a obtenu ´tait beaucoup plus simple (du moins de notre point de vue) et surtout. e Au moment de la r´daction de ce m´moire. beaue coup plus souple au niveau des diff´rentes fa¸ons de composer les op´rateurs entre eux. et il permet finalement de g´n´rer automatiquement un contrˆleur pour une e e o politique donn´e. ce choix permet de d´finir un algorithme permettant de v´rifier e e la coh´rence de la base de signatures. Les signatures seront traduites vers e e un autre langage. Bien que les m´canismes d’unification alourdissent quelque e peu les algorithmes de v´rification. nous avons vu comment le choix d’un langage bas´ sur une logique e temporelle ouvrait la voie ` d’autres travaux de nature th´orique orient´s vers l’applia e e cation. Nous envisageons aussi e d’impl´menter une version compil´e de ce langage. Nous avons r´alis´ apr`s coup que cette vision ne cole e e e lait pas d’assez pr`s ` la r´alit´. r´alis´ l’importance du choix du e e mod`le. probablement C ou C++. il permet aussi d’´tendre le langage de fa¸on ` e e c a permettre au syst`me de d´tection d’intrusions de bloquer uniquement les actions mae e licieuses. et nous avons dˆ red´finir un mod`le bas´ cette fois sur e a e e u e e e un principe d’unification. puisqu’il permet de r´diger des signatures sans se soucier de la pr´sence ou non e e de certains attributs. Entre autres. Il ´tait clair depuis le d´but qu’un mod`le propositionnel ne pourrait pas suffire e e e e ` la tˆche. . une autre voie d’extension sera de la faire fonctionner au niveau hˆte. Nous avons alors opt´ pour un mod`le d’enregistrements. Nous pr´voyons e faire fonctionner ce prototype de pair avec le syst`me de d´tection d’intrusions Snort e e et le logiciel de capture et de d´codage de paquets Ethereal.Conclusion 143 syst`me en temps-r´el et ` l’acquisition passive d’information. en utilisant comme source d’´v´nements un outil o e e tel que strace. dans cette seconde partie du travail. mod`le souvent a a e e e utilis´ dans les syst`mes que nous avons ´tudi´s. nous trouvons qu’il vaut la peine d’opter pour ce e choix. l’impl´mentation d’une version intere e e pr´t´e du second langage que nous avons sp´cifi´ est en cours de d´veloppement en ee e e e collaboration avec le Centre de Recherches sur les Communications. e c e Nous avons aussi. Finalement.

Michel and L. pp.” Dec.tenablesecurity. Nov. M´ and M. 10.”http://www.the snort project. ser.” http://www.org/nmap/nmap doc. Hayton. [2] C.” [5] ——.dmst. “tcpdump man page.html. Gritzalis.com/infocus/1741. Designing a stick.aueb. “Correlating ids alerts with vulnerability http://www. Green and M. [12] ——.0 .gr/dds/pubs/jrnl/2002-JCS-Panoptis/html/paper. D. 159–176. august 2003. . 2002. Available : http://www.” in 5th International Conference on Recent Advances in Intrusion Detection (RAID 2002).” [10] H. 353–365.org/pcap3 man.psu.1. Anderson.html. pp. “Adele : an attack description language for knowledge-based e intrusion detection.html [3] D. 177–198. [6] C. pp.Ducass´. part 2 : Scanning.Bibliographie [1] C.tenablesecurity.insecure.htm. Roesch. 2003. “Snort users manual 2. “Panoptis : Intrusion detection using a domain-specific language. december 2002. Morin. Leres.” http://www. vol. Deraison. B.an introduction to nevo. R. “M2d2 : A formal data model for ids e e alert correlation. december 2003.com/papers.com/infocus/1753.com/papers.” Journal of Computer Security. and S.org/tcpdump man. Gula. June 2001. 2003. and T. Giovanni. 1997. [11] H. information.html. Spinellis and D.” http://www. Available : citeseer. Jacobson. LNCS. Gula. [8] R. vol.tcpdump.” in Proceedings of the 16th International Conference on Information Security (IFIP/SEC 2001). 2516.edu/michel01adele. october 2003.tcpdump. “Fun with packets : http://packetstormsecurity. M´. [Online]. October 2002. “Passive vulnerability scanning. “Nessus.”http://www.“Introduction to nessus.” [7] Fyodor.html. [9] R.“The art of port scanning. [Online]. C.html.ist.html [4] V. Zurich : Springer. http://www. McCanne.securityfocus.securityfocus. L. “libpcap man page.nl/distributed/stick.

Paxson. G. Sekar. Rep. [Online]. Available : citeseer. Bele gique. Available : citeseer. [Online]. Namur. [Online].psu.based language for universal audit trail analysis. pp. Spafford. 23–24. Mounji. 1995. Kumar and E. Vigna.psu. rue Grangagnage 21. “Classification and detection of computer intrusions. “An Application of Pattern Matching in Intrusion Detection. Mathieu.html [18] S. 25–.psu.” 2000. Kemmerer. [Online]. 1997. Charlier.html [15] ——.psu. “Preliminary report on advanced security audit trail analysis on unix (asax also called satx).ist. dissertation. and T. dissertation.ist. [Online].edu/habra92asax.psu. Vigna and R. S.edu/ilgun92ustat.psu. [Online]. A.ist. 1993. Kemmerer. “A highperformance network intrusion detection system.edu/paxson98bro. A.D. 5000 Namur. Available : citeseer.psu. Ilgun. Available : citeseer.securityfocus. Purdue.” Ph.html [19] K. Belgium.edu/366932. Rep. [17] V.sunysb. Available : citeseer.edu/kumar95software. 94-013.ist.edu/article/kumar94application. “Statl : An attack language for state-based intrusion detection. 16–28. 1995. 31. Kumar and E.” Ph. Oakland. “Bro : a system for detecting network intruders in real-time. FUNDP.ist. “Nessus. Mounji. September 1994. Available : citeseer. 435–450. “A software architecture to support misuse intrusion detection.ist.html [23] S.ist.edu/article/eckmann00statl. Guang. [Online]. 1999.ist. pp.psu.” [14] N.htm . february 2004.” Department of Computer Sciences. 194–204.” in ACSAC.” Computer Networks (Amsterdam.” in ACM Symposium on Computer and Communication Security. Spafford. Habra.” in Proceedings of the 1993 IEEE Symposium on Research in Security and Privacy. Available : citeseer.” Institut D’Informatique. reports. Tech. 1994. part 3 : Analysing http://www. “Languages and tools for rule-based distributed intrusion detection. Shanbhag.edu/vigna98netstat. vol. 1992. Netherlands : 1999). [Online]. [Online]. “ASAX : Software architecture and rule.html [20] G. Y. 1998.edu/seclab/pubs/papers.ist.” in European Symposium on Research in Computer Security (ESORICS). IN. Kumar. 1999.com/infocus/1759. pp. Tech. L. pp. Eckmann. B.html [21] S.” in Proceedings of the 18th National Information Security Conference. Available : citeseer. and I. pp. CA.html [24] R. Verma. no. “Netstat : A network-based intrusion detection approach. Available : http://seclab.html [16] A. and R.psu. Facult´s Universitaires Notre-Dame de la Paix.html [22] S.. “USTAT : A real-time intrusion detection system for UNIX.Bibliographie 145 [13] ——.edu/kumar95classification. Available : citeseer. [Online]. 2435–2463.D.cs.

” in Proceedings of the 1999 IEEE Symposium on Security and Privacy. e Available : http://dli. Barringer.” [Online]. and P.edu/522892. pp. pp.” Ph.html [36] K. Available : http://www.francetelecom.edu/sen04online.html [33] P. Kowalski. Rosu and K.D. pp. 197–216. Roger and J. [Online]. september 1994. Rosu. Available : citeseer. may 1999. “Detecting computer and network misuse through the production-based expert system toolset (p-best). and K.” in Proc.psu. Available : http://www.ist. Dousson.edu/barringer04rulebased. pp. Agha.psu.html [35] P.com/papers/7sri/ [28] Anderson. California : IEEE Computer Society Press.com/papers/4sri/ [29] F. pp. Thati. [Online]. and Valdes. Naldurg.html [37] C.” in International Conference on Logic Programming.edu/seclab/pubs/papers.ist.” Information and Control. Uppuluri. “Online efficient predictive safety analysis of multithreaded programs. Springer-Verlag. “Synthesizing fast intrusion detection/prevention systems from high-level specifications.html [31] G. Frivold. 1995. Nova Scotia. Available : http://www. 146–161.ist. [Online]. K. 1999. [Online]. Goldberg. 72–99. IEEE Comp. “Variants of the event calculus.psu.psu. and Valdes. Sekar and P. “Temporal logic can be more expressive. “NIDES : software users manual — beta-update release. Available : citeseer. A. Canada. California.fr/abc/diagnostic/ . 2000. June 2001.ist.Bibliographie 146 [25] R. [32] M.” dec 1994.sdl.cs.sdl.sdl. Sen.rd.com/papers/pbest-sp99-cr/ [27] Anderson. 67–81.edu/article/roger01log.” in USENIX Security Symposium. Available : citeseer. Available : http://seclab. K. Wolper. [34] H. “Lambda : A language to model a database for detection of attacks. Porras. “A temporal logic based framework for intrusion detection.ist.” 2004. Universit´ Paul Sabatier de Toulouse. [Online]. e dissertation. 1983. Oakland. 2001. 14th IEEE Computer Security Foundations Workshop (CSFW’01). Cuppens and R. Lunt. Tamaru. Los Alamitos. A.htm [26] U. “NIDES : A summary.sri. “Log auditing through model checking. [30] F. Sen.sri. vol.edu/naldurg04temporal.sunysb. Ortalo. [Online].” may 1995.” in Proceedings of the Third International Workshop on Recent Advances in Intrusion Detection. “Synthesizing dynamic programming algorithms from linear temporal logic formulae. Javits. [Online]. “Suivi d’´volutions et reconnaissance de chroniques. [Online]. [Online]. Havelund. Available : citeseer. Soc. Goubault-Larrecq. Havelund.psu. Press.” 2004. G. Available : citeseer. Lindqvist and P.sri. Sen. and G. 56(1–2). Sadri and R. 220–236. Cape Breton. “Rule-based runtime verification. A.” 2000.

Debar. N.edu/lin98abstractionbased. D. “Custom attack simulation http://www. ser.ietf. vol. 579–595. Koza. 1998. Feinstein. Song.psu.txt. J. Available : citeseer. “Applying genetic programming to intrusion detection. and M.” in 6th International Conference on Recent Advances in Intrusion Detection (RAID 2003). 1997. Networks. [Online]. Lippmann.psu. 1982. Eds. J. “Evaluating intrusion detection systems : The 1998 DARPA off-line intrusion detection evaluation. pp. “Formal specification of intrusion signatures and e detection rules. Debar. “The 1999 darpa offline intrusion detection evaluation. D. Cambridge. Haines. and Jajodia. E. Los Alamitos.” Comput. Pittsburg : Springer. 2325–2336. vol. LNCS. MIT. 4. Lippmann.edu/crosbie95applying. Fried.org/tqbf/casl. Deraison.sockpuppet.” First International Workshop on Recent Advances in Intrusion Detection (RAID ’98).html [44] L. 12-16 July 2003. IEEE Computer Society. Crosbie and E.html [48] R. D. I. M. D. . Weber. and K. [39] H. “Gassata. Heywood. Pouzol and M. LNCS. [49] D. “The nessus attack scripting http://www. Ducass´. Kendall. 2000. a genetic algorithm as an alternative tool for security audit trails e analysis.ist. R. 34.” in Proceedings of the DARPA Information Survivability Conference and Exposition.” [41] I. pp. “A linear genetic programming approach to intrusion detection. D. 2000. M´. Morin and H. Zincir-Heywood. V. Das. Available : citeseer. 2002. Secure Networks.Bibliographie 147 [38] B. 1–8. Cunningham. Fried.nessus.ist.html [46] D. Available : citeseer. Spafford. S. H. D. [45] M. ser.-P. Siegel and J. J. “Correlation of intrusion symptoms : an application of chronicles. and A. vol.” http://www. 10–12 1995. September 2003. “Intrusion detection exchange format.” in Proceedings of the 15th IEEE Computer Security Foundations Workshop (CSFW’02). pp. 64. W. IEEE Computer Society Press. J. Wang. V. USA : AAAI. Curry. Graf. no. [Online]. [Online]. july 2004.” in Working Notes for the AAAI Symposium on Genetic Programming. McDermott. MA. internet-Draft. Haines. Zissman. [47] R.ist. [43] Lin. Webster. [40] R. 101–155. language reference language guide. K.edu/lippmann00evaluating.html. [42] J.” (casl). and B. “Abstraction-based misuse detection : High-level specifications and adaptable strategies.org/internet-drafts/draft-ietf-idwg-idmef-xml-12.org/doc/nasl.” Cognitive Science. Chicago : Springer-Verlag. Korba.” in PCSFW : Proceedings of The 11th Computer Security Foundations Workshop.psu. I. R. “A temporal logic for reasoning about processes and plans.” in Genetic and Evolutionary Computation – GECCO-2003. CA : IEEE Computer Society Press. 2820. McClung. Wyschogrod. p. april 2000. pp. 1998.html. 2724.

no. Sci. [57] J. A. J. Emerson and J. Eds. Kozen. no.Bibliographie 148 [50] J. 1989. A. 1. Laroussine and P. [59] G. “Sometimes and not never revisited : on branching versus linear time temporal logic. Rep. Lecture Notes in Computer Science. Lei. Emerson and C. vol. Springer. “Actions and events in interval temporal logic. “Reified temporal logics : An overview. Cambridge.” Artificial Intelligence Review. L.” IEEE Trans. [54] E. Pnueli. Tenenberg. Brachman. Found.” Theoretical Computer Science. 1989. vol. Bacchus. Tech. Koomen. pp. 189–217. A.. R. Schnoebelen. [60] Z. TR521. pp. Alur and T. 303–324. Gabbay.. Knight. May 2001. 1985.ist. [58] T. 33.” in Proceedings of the 12th ACM SIGACT-SIGPLAN symposium on Principles of programming languages. pp. 1999. Wilke. Henzinger. vol. Reiter. and J. 1994. Springer. Thati and G. 1738. 151–178. pp. 1986. 27. [62] P. “The model checker SPIN.” Theoritical Computer Science. [56] R.” in IEEE Symposium on Foundations of Computer Science. vol. [63] F. [53] D. 2. “Verification of concurrent programs : The temporal framework. 279–295.html [51] F. ser. no. Ontario. “Results on the propositional mu-calculus. Holzmann. Pnueli.” in Proceedings of the First Symposium on Logic in Computer Science. F. vol. Comp. Y. Lichtenstein and A. “Modalities for model checking : Branching time logics strikes back. 1997.edu/allen94actions.” International Lecture Series in Computer Science. 1983. ser. 1981. 15. [Online].psu. H. “Monitoring algorithms for metric temporal logic specificas tions. J. Halpern. pp. Canada : Morgan Kaufmann. Levesque. 5.. 2004. 3. “A really temporal logic.” Journal of the ACM. [55] E. pp. M. [61] D. of Software Technology and Theor. Available : citeseer. pp. May 1989. 409–448. vol. Allen and G. 398. Softw. Toronto. Eng.” in Conference on Temporal Logic in Specification. 2–10. 267–278. “A non-reified temporal logic. 1995. 333–354. pp. Pnueli. and R.” in 19th Conf. pp. [52] O. June 1986. Behnam Banieqbal and A. Eds. 48. no. . Ro¸u. “Ctl+ is exponentially more succinct than ctl. 23. Ma and B. vol. 110–121. “Checking that finite state concurrent programs satisfy their linear specification. B. Lecture Notes in Computer Science. “A hierarchy of temporal logics with past. Ferguson. in the correctness problem in computer science. H. “The declarative past and imperative future : Executable temporal logic for interactive systems.” in Runtime Verification 2004 (RV04). Manna and A.” in Proceedings of the First International Conference on Principles of Knowledge Representation and Reasoning.

[69] C. Syst. [71] Fyodor. vol. 2.” http://www. July 2002. [77] Top Layer.” http://www. Ghezzi. “Network intrusion prevention solutions for the enterprise. Clemson University.nss.” D´partement d’informatique. [79] H.insecure. Clemson. Henzinger. e [80] R. Universit´ Lae o e e val.. September 2003. [Online]. pp. pp. C. 255–299. 107–123.pdf. Mandrioli. 5. 1955. Morzenti. 1990. Stanford University.lsv.html. [76] Cisco Systems.org/nmap/nmap-fingerprinting-article. [73] A. and A.com/. 2004.htm. I.” Rapport d’examen de synth`se. X. D.. D´partement d’informatique.” http://www.uk/WhitePapers/intrusion prevention systems. Nicollin. Press. [67] T.” Ph. Kh´dri. 383–392. 12. no.cisco. [75] The NSS Group. “The temporal specification and verification of real-time systems.. “Passive os fingerprinting.ens-cahan. December 2004. vol.” J. “Temporal logic with forgettable c past.” in Proceeding of the 17th Symposium on Logic in Computer Science (LICS 2002).securityfocus.com/pdf/sbEnterprise.Bibliographie 149 [64] N. Henzinger.toplayer. pp. Fran¸ois Laroussine and P.” th`se de doctorat.org/wrt54g.” Pacific Journal of Mathematics. “Cisco ios ips. dissertation. Denmark. Softw. SC 29634-1906. august e e e 1998.batbox. “Intrusion prevention systems http://www. “Bibliography on prolog.D. Sifakis.fr/Publis/ [65] A. 1990. 1991. “Specifying real-time properties with metric temporal logic. A. Copenhagen. “Concurrence. 285–309.” http://www. Ed. [74] “Bugtraq homepage.cx/p0f. [70] M. Symposium of Logics in Computer Science. M. 2. 2000–2003. Zalewski. Buzbee. Stevenson. Tarski.coredump. 2004. Koymans. “Remote os detection via tcp/ip stack fingerprinting.” http://lcamtuf.html. “Snort on the wrt54g.” RealTime Syst. july 2001. Available : http://www. “Symbolic model checking for real-time systems. vol. 1992. J. [68] R. Schnoebelen. [72] S. USA.” http://www. [78] J.org/. 4. and S. “Trio : A logic language for executable specifications of real-time systems. no. 1998. “A lattice-theoretical fixpoint theorem and its applications. pp.co.” january .shtml. Bherer. “A multi-packet signature approach to passive operating system detection. DeMontigny-Leboeuf. Yovine. bisimulations et ´quation d’interface : une approche relae e tionnelle. S.” CRC/DRDC joint Technical Report CRC-TN-2005-001 / DRDC-Ottawa-TM-2005-018. (ips). “Synth`se de contrˆleurs.” in 7th. Universit´ Laval. [66] T.” Department of Computer Science.

Softw. Security and Trust.-Denis. F. Lacasse. Syst. pp. Barbeau. liveness. no. St. “A method for the synthesis of controllers to handle safety. 2.”in Second Annual Conference on Privacy. 11. University of New Brunswick... 43. 103–112. 2002. vol. [83] A. Ktari.Bibliographie 150 [81] M. M. Kabanza.” J. October 2004. New Brunswick. and R. [82] R. and real-time constraints. no. pp. Novembre 1998. Wu Centre. vol. St-Denis. Fredericton. 60.” IEEE Transactions on Automatic Control. Mejri. “Formal implementation of network security policies. 1543–1559. and B. “Designing reactive systems : integration of abstraction techniques into a synthesis procedure. . Canada.

Sign up to vote on this title
UsefulNot useful