Analyse de comportement de pare-feu par

Analyse de comportement de pare-feu par
marquage de données
Olivier Paul ([email protected])*
Abstract: Dans cet article nous présentons les résultats préliminaires de l’utilisation d’un outil
d’analyse de comportement des systèmes de filtrage. Celui-ci fonctionne en utilisant un mécanisme
de marquage de données qui permet distinguer de manière plus ou moins grossière quelles parties
d'un paquet sont examinées par un pare feu en fonction de la configuration de celui-ci.
Keywords: filtrage, virtualisation, marquage de données.
1
Introduction
2
Etat de l’art
Les fonctions de filtrage sont aujourd'hui particulièrement répandues. On les trouve aussi bien
dans les équipements destinés à une utilisation personnelle (routeurs personnels, routeursmodems/cable-adsl) que professionnelle (pare-feu dédiés, IPS, routeurs d'entreprise), aussi bien
dans des équipements dédiés que dans des équipements dont ils viennent complémenter les
fonctions. Par ailleurs leur déploiement s'est accompagné d'une complexification croissante. Aux
fonctions de filtrage traditionnelles, se sont ajoutées au fil du temps des fonctions liées à la
détection d'intrusion, à la détection d'attaques de dénis de service. Malheureusement, comme
nous le montrons dans la section suivante, il n'est pas évident pour un utilisateur potentiel de
déterminer quelles fonctions sont réellement implantées par un pare-feu, ni si une configuration
donnée fonctionne de manière attendue. Dans cet article nous décrivons une ébauche de solution
pour résoudre ce problème. Nous espérons dans le futur combiner cette ébauche avec d'autres
techniques afin de permettre l'analyse de systèmes de filtrage de manière automatique. Notre
proposition est pour le moment manuelle, et permet à l'utilisateur d'un système de filtrage de
déterminer quelles données sont utilisées par un système de filtrage pour une configuration de
filtrage bien définie. Dans la suite de cet article nous présentons l'architecture que nous
proposons ainsi que des résultats de tests préliminaires.
2.1
Utilisation de manuels et de standards
La méthode la plus évidente pour déterminer les fonctionnalités de filtrage implantées par un
outil est de lire le manuel qui lui est associé. Cependant cette méthode est rarement suffisante
pour plusieurs raisons. D'une part certains outils ne possèdent pas de manuel. C'est par exemple
le cas de nombreux routeurs/modems personnels qui possèdent uniquement un manuel de mise
en route bien qu'ils implémentent des fonctions de filtrage [Pa07]. D'autres outils possèdent un
manuel mais celui-ci n'est pas en phase avec les fonctionnalités réellement implantées par l'outil
décrit. Dans certains cas, le manuel peut être optimiste vis à vis des fonctionnalités fournies
*
Institut Telecom Sud Paris, 9 rue Charles Fourier, 91000 Evry Cedex
Tel : 33 (0) 1 60 76 47 91 - Fax : 33 (0) 1 60 76 47 11
Submitted to SAR-SSI 2008
1
[Pa07]. Il est à noter que cette absence d'information n'est pas toujours dans le mauvais sens.
Ainsi il arrive parfois que certains outils fournissent des fonctionnalités plus perfectionnées que
celles annoncées par le manuel correspondant [Pa07]. Ce cas se produit fréquemment dans les
projets open-source ou l'objectif des développeurs est principalement l'avancement du code mais
également pour certains outils commerciaux. Une solution fréquemment utilisée par les
utilisateurs de systèmes open source pour palier ces problèmes est d'aller directement lire le code
source des outils afin de comprendre leur fonctionnement. Cette solution même si elle ne peut
qu'être bénéfique d'un point de vue de la sécurité est cependant assez fastidieuse et ne s'applique
de toute façon qu'à une catégorie limitée d'outils.
Une façon de remédier à ce manque d'information peut être l'utilisation de certifications. Au
cours des dix dernières années, plusieurs spécifications de critères de certifications pour les
outils de filtrage ont été réalisées par divers organismes tels que le CERT ou la NSA [CC]. Ces
critères de certifications appelés profils de protection (PP) décrivent les fonctionnalités
minimales qui doivent être implantées par un outil afin que celui-ci puisse être évalué.
Cependant, dans la pratique, la majorité des équipements ne sont pas certifiés vis à vis de PPs
standardisés parce que les constructeurs préfèrent faire valider leur produit vis à vis d'une
description des fonctionnalités adaptée à leur produit qu'ils fournissent alors eux même. Dans ce
cas la procédure de certification ne peut couvrir qu'une partie du PP, Une autre raison est tout
simplement qu'aujourd'hui, de nombreux produits ne sont pas certifiés. Ainsi fin 2007, moins de
90 produits étaient certifiés et parmi ceux-ci seulement 5 étaient certifiés vis à vis d'un PP
existant. Enfin les procédures de certification et de création de PPs étant relativement longues,
les produits sont souvent certifiés par rapport à des fonctionnalités qui ne sont plus en rapport
avec leurs véritables capacités.
2.2
Analyse par l'utilisation de batteries de tests
Afin de faciliter le travail des développeurs, la plupart des outils de filtrage possèdent une
batterie de tests permettant de déterminer si un outil de filtrage se comporte de manière similaire
au comportement qu'il avait avant l'introduction de nouvelles fonctionnalités (tests de non
régression). Ces tests se concentrent souvent sur la syntaxe des règles de configuration et
fonctionnent dans un cadre local, sans mettre en œuvre de fonction réseau par exemple en
utilisant une interface spécifique de test [Ipf]. Si ces tests permettent de s'assurer dans une
certaine mesure de la cohérence du fonctionnement d'un outil dans le temps, ils ne permettent
cependant pas à un utilisateur de comprendre la sémantique des règles de configuration. D'autre
part, ils testent un nombre de points précis et ne permettent en aucun cas de garantir la stabilité
du fonctionnement global de l'outil.
De nombreux outils permettent la génération de trafic afin de tester le fonctionnement d'un outil
de filtrage [hping]. Ils permettent au travers d'une description du trafic à générer de construire
les unités de données ayant les caractéristiques désirées. Le test de l'outil de filtrage se fait alors
une fois sa configuration réalisée en examinant les unités de données après traitement ainsi que
les logs produits par l'outil. Cependant ces tests demandent une connaissance préalable de la
sémantique des options de configuration et d'autre part l'analyse des logs et des unités de
données non bloquées ne fournissent qu'une vision partielle des opérations réellement réalisées
par un outil. Ainsi une règle de filtrage peut être examinée sans être appliquée, d'autre part des
fonctions sont souvent mises en œuvre par défaut sans nécessiter de configuration explicite. Le
problème de sémantique pourrait être réglé s'il existait une base publique de tests permettant de
distinguer les cas de fonctionnement les plus courants. Ainsi une solution approchante
concernant les NAT est proposée dans [Gu05]. Cependant les NATs sont des outils simples dont
le comportement est relativement homogène. A notre connaissance il n'existe pas d'outil
2
Submitted to SAR-SSI 2008
similaire pour les pare-feu.
Un certain nombre de travaux ont été réalisés afin de tester des points spécifiques des pare-feu
pour lesquels le comportement attendu est bien défini et connu à l’avance. Par exemple [Senn05]
présente une méthode permettant de tester les caractéristiques d’un automate de filtre à état TCP
pour ce protocole à partir de la définition formelle de TCP. Cependant ce type d'outil, en dehors
du fait qu'il se limite à une petite partie du fonctionnement d’un outil de filtrage (les problèmes
de temporisation ou de vérification de numéros de séquence sont par exemple ignorés)
présuppose comme dans les cas précédent la connaissance de la sémantique des commandes de
configuration.
2.3
Analyse de traces d'exécution
Au cours des cinq dernières années, de nombreuses propositions ont été faites concernant
l'analyse de comportement d'outils réseaux au travers de l'analyse de leurs traces d'exécution lors
de la réception/émission de données. Ainsi [Mut05] présente l'une des seules analyses à notre
connaissance d’un outil de sécurité. Celle-ci est réalisée à partir de traces d’exécution d’outils de
détection d’intrusion. Les auteurs se basent sur l’outil ptrace afin d’obtenir celles-ci. Les auteurs
montrent par la suite comment ces traces peuvent être utilisées pour déterminer les signatures
utilisées par des outils de détection d’intrusion. La limitation principale de cette approche est
qu’elle est limitée à l’étude de processus utilisateurs du fait de l’utilisation de ptrace et cela dans
un environnement d’exécution bien connu afin de pouvoir disposer de cette fonctionnalité.
D’autre part les auteurs donnent peu d’information sur la façon dont l’analyse des traces est
réalisée.
Plus récemment, un grand nombre de travaux se sont intéressés à caractériser le comportement
des logiciels réseaux par la construction de modèles de l’exécution d’un programme de manière
automatique et à partir de traces d’exécution. Ainsi [Bru07] présente une architecture qui à partir
de la trace d’exécution d’un programme et de son état final produit une formule symbolique de
son exécution appelée pré condition la plus faible. Celle-ci permet de définir quelles données en
entrée peuvent amener le programme à un état donné. Cet état est défini par les données
produites. Les auteurs utilisent cette approche pour réaliser la prise d’empreinte de logiciels.
Une limitation actuelle de cette approche est qu’elle semble pour le moment limitée à des
logiciels de petite taille dans lesquels les entrées-sorties sont bien définies.
[Yin07] présente une architecture associant un mécanisme de marquage de données au travers
d’un émulateur et un ensemble d’outils systèmes permettant de lier ces données teintées à leur
utilisation par un processus, une librairie ou un fichier particulier. Cette architecture permet de
détecter des attaques en repérant des anomalies dans le cheminement des données au travers
d’un système. Un des inconvénients de cette approche est qu’elle nécessite d’installer un
ensemble d’outils sur le système à surveiller. Ceci n’est pas toujours possible le cas dans le cadre
d’environnements propriétaires.
3
Architecture proposée
Dans cette partie, nous essayons de montrer l’utilité de utilisation du marquage de donnée dans
la compréhension d’un processus de filtrage. Dans le cas de produits commerciaux, l’accès aux
sources et au code exécutable du processus de filtrage est souvent impossible. De plus, parmi les
produits commerciaux, il est assez fréquent de ne pas pouvoir modifier le système d’exploitation
ou d’y introduire de nouvelles fonctions qui permettraient de comprendre le lien entre le
processus de filtrage et le reste du système. Un autre problème dans la compréhension du
comportement de ces processus est qu’ils sont souvent implantés comme une partie du système
d’exploitation. Il est donc difficile de distinguer leur comportement du reste du système que l’on
Submitted to SAR-SSI 2008
3
peut être alors contraint d’analyser dans sa globalité. Celui-ci étant souvent d’un degré de
complexité bien supérieur à celui d’un simple programme, cette tache n’est pas aisée. Enfin les
systèmes implantant ces fonctions étant multi-tâches, l’analyse du système peut se révéler plus
complexe que celle d’un simple programme dont l’exécution, du point de vue utilisateur, est
sans interruptions. Afin de résoudre ces problèmes nous proposons d’utiliser un émulateur afin
de réaliser les opérations de base de surveillance. Nous présentons par la suite Argos, l’outil sur
lequel se base notre système puis les extensions qui s’y rattachent. Celles-ci ont pour objectif de
présenter à l’utilisateur d’un système de filtrage la vision la plus synthétique des opérations
réalisées pour une configuration et un trafic de test donnés.
3.1
Argos
3.2
Extensions d’Argos
Notre architecture se base sur Argos [Por06]. Argos est un outil d'analyse d'exécutables qui
permet de repérer la mise en œuvre d'attaques au travers de l'analyse dynamique du code
exécuté. Argos est lui même basé sur un outil appelé Qemu [Bel05]. Qemu est un outil de
virtualisation qui permet l'émulation de différents types de machines (x86, Sparc, Mips, ARM,
PPC, Alpha,...). Dans ce cadre il permet l'exécution de code natif pour ces machine sur un
système cible au travers de machines virtuelles.
Lors de son exécution le code natif est traduit de manière dynamique pour pouvoir être exécuté
sur le système cible. L’unité de traduction dans Qemu est le bloc de traduction (Translation
block), une suite d’instructions terminée par une fonction modifiant le contrôle de l’exécution du
programme (saut, appel de fonction, ...). L’utilisation de tels blocs permet de limiter le coût de la
traduction en conservant un cache des blocs récemment utilisés et donc de conserver de bonnes
performances d'émulation. La traduction en elle-même est réalisée au travers d’un langage
intermédiaire comprenant un nombre réduit de fonctions simples. Il permet une portabilité plus
importante du traducteur ainsi qu’une modification plus aisées de ces fonctions. Les fonctions de
ce langage intermédiaire sont compilées préalablement à l’utilisation de l’émulateur. Celui-ci se
charge par la suite de composer le code cible associé à ces fonctions en fonction du code natif à
traduire à la manière d’un compilateur.
La capacité de traduction de Qemu est utilisée par Argos pour associer des fonctions de
marquage de données aux instructions traduites afin permettre à la machine virtuelle de
distinguer la provenance des données traitées. Argos étant construit pour la reconnaissance
d’attaques réseau, la seule source de données teintée dans Argos est l’interface réseau.
Notre intérêt pour Argos est lié à plusieurs de ses caractéristiques:
- C’est à notre connaissance le seul système de virtualisation supportant le marquage de
données dont le code source soit disponible publiquement.
- Il permet d’obtenir des informations d’exécution d’un système de filtrage sans avoir à
instrumenter celui-ci sous quelque forme que ce soit (code source, appels système, code
binaire).
- Il permet l’exécution d’une grande variété de systèmes de filtrage par le fait que Qemu
supporte l’émulation d’un grand nombre de systèmes. Ainsi des systèmes aussi divers
que JunOS ou QNX sont au moins partiellement supportés.
- Il permet d’associer les instructions exécutées à leur provenance des données qu'elles
manipulent.
Malgré toutes ses qualités, Argos ne répond pas totalement à nos besoins. En effet Argos est
conçu pour suivre le cheminement des données. Il utilise pour cela deux outils principaux :
- L’instrumentation des fonctions provoquant le transfert de données de ou vers un
4
Submitted to SAR-SSI 2008
espace mémoire (au sens large, c'est-à-dire mémoire principale, registres, ...) pour
suivre leur cheminement. Ceci est réalisé en modifiant la sémantique des fonctions du
langage intermédiaire utilisé par Qemu.
- La gestion d’un espace mémoire associé à la mémoire disponible pour la machine
virtuelle qui contient des étiquettes indiquant la provenance des données. Ces étiquettes
sont utilisées par les fonctions instrumentées pour propager cette information de
provenance lorsque cela est nécessaire et d’autre part pour rendre les services de
détection d’attaques fournis par Argos.
Cependant ces outils ne permettent pas de détecter l’utilisation, par d’autres fonctions, de
données teintées. D’autre part Argos n’a pas pour objectif de signaler l’utilisation de données
teintées d’une manière générale. Nous avons donc étendu d’une part les autres fonctions du
langage intermédiaire afin de pouvoir repérer l’utilisation de données teintées dans des fonctions
autres que celles liées au mouvement des données. D’autre part, nous avons muni Argos d’un
système permettant de mémoriser l’utilisation de ces données et de fournir à la demande une
trace d’utilisation.
Une autre limitation d’Argos est qu’il est conçu afin d’associer à chaque donnée, son origine,
c'est-à-dire si il provient du réseau ainsi qu’une approximation de sa localisation dans le flux de
données reçu par la carte réseau. Une telle information peut être stockée de manière économe
mais n’est cependant pas suffisamment précise pour nos besoins. Nous avons donc étendu Argos
afin de pouvoir conserver la position précise de chaque octet dans un paquet ainsi que l’identité
du paquet d’origine. L’utilisation dans Argos du système de pagination des informations de
marquage permet de limiter le coût d’une telle mesure. Cette information n'est cependant utile
que si l'on peut par la suite associer un type à chaque marque. Pour cela nous avons étendu le
système de sauvegarde de données présent dans Argos afin de sauver les trames reçues par les
cartes réseau sous une forme facilement analysable (format pcap).
Au cours de l’utilisation de notre version modifiée il est rapidement apparu que les informations
de marquage n’auraient d’intérêt qu’accompagnées d’informations liées aux instructions
exécutées. Fournir une telle information n’est pas possible au travers du système de conservation
des marques car celui-ci se place au niveau du langage intermédiaire et n’a donc pas accès au
code natif à traduire. Nous avons donc étendu les fonctions de conservation de logs présentes
dans Qemu afin de pouvoir conserver une trace exhaustive de l’exécution de toutes les
instructions. Afin de limiter l’impact en terme de performance d’un telle conservation, nous
avons développé un système d’automatisation du déclenchement des opérations de prise de log
en fonction des évènements se produisant dans la machine virtuelle (arrivée/départ de trames,
exécution de séquences d’instructions natives particulières, ...). Celui-ci permet par ailleurs
l’exécution de scripts dans le moniteur Qemu ainsi que sur la machine hôte. Cette interface entre
la machine virtuelle et la machine hôte permet de synchroniser l'utilisation des outils de
configuration d'outils de filtrage, de génération de trafic de test, de configuration des opérations
de capture de trace et d'analyse de ces traces. Enfin nous avons modifié Qemu afin qu’il
conserve une valeur de compteur programme (pc) valide lors de l’exécution de blocs (Dans
Qemu, le pc est uniquement mis à jour en fin d’exécution de bloc pour des raisons de
performance).
Au final, le système modifié fournit donc trois types de traces:
• Trace 1: la liste de toutes les instructions exécutées pendant un test.
• Trace 2: la position des instructions utilisant des données marquées et les marques
associées.
• Trace 3: Les trames correspondant aux données marquées.
Submitted to SAR-SSI 2008
5
3.3
Analyse des traces obtenues
Les modifications présentées dans la section précédente permettent d’associer à chaque
utilisation de donnée provenant d’une trame, l’instruction ayant utilisé cette donnée et le bloc de
traduction associé. Cette correspondance nous permet de faire plusieurs types d’opérations de
simplification sur les informations présentées à l’utilisateur. Ces opérations sont présentées Fig
1. Dans cette figure, les informations présentées à l'utilisateur à la fin de l'analyse sont indiquées
en gris foncé alors que les outils réalisant les opérations de simplification sont présentés en gris
clair. Ces opérations sont nécessaires car la quantité d’instructions exécutées lors d’un test même
simple est assez importante. Ainsi lors de nos tests, pour une seule règle de filtrage et un seul
paquet de test, le nombre d’instructions exécutées entre la réception du paquet et sa réémission
variait entre 1 et 2 millions. Même si une partie de ces instructions est due au ralentissement
engendré par les mécanismes de log (exécution d'interruptions supplémentaires par exemple), il
est nécessaire de distinguer ce qui provient du mécanisme de filtrage des autres fonctions mises
en œuvre par le système dans lequel il se place.
Un premier moyen de faire cette distinction est de limiter l’analyse dans le temps en déclenchent
les opérations de log lors d’évènements particuliers. Dans notre cas l’instrumentation des
fonctions de réception et d’émission des cartes réseau virtuelles permet de rendre cette fonction
étant donné que les filtres agissent principalement lorsque du trafic est présent dans le système
étudié.
Le marquage des données est un second moyen qui nous permet de distinguer les instructions
intéressantes. Le marquage par type utilise les traces 2 et 3 et permet de faire le lien entre les
données contenues dans les trames reçues, la position de ces données dans les trames et le type
des champs correspondants au travers d'un logiciel d'analyse réseau tel que tshark [tshark].
Celui-ci produit une description au format PDML (Packet Details Markup Language) [Bal05]
associant à chaque champ de chaque paquet son type (protocole, sémantique du champ) et sa
valeur. Cette description peut être par la suite utilisée par un utilisateur afin de limiter la
présentation des fonctions et instructions exécutées en fonction du type de donnée qu'il pense
être utilisé par la configuration de filtrage.
Cependant un grand nombre de fonctions manipulent les données réseau. Par exemple, en
environnement x86, les entrées-sorties dans Qemu se font en utilisant les instructions in et out.
Dans le cas de données provenant du réseau, ces instructions manipulent donc toutes les
données. La simplification réalisée par le marquage devrait donc être complété par d’autres
types de simplification se basant par exemple sur le type d’instructions.
Instructions
Argos/
Qemu
Analyseur
Marques
Données
instructions
par champs
utilisés
Filtre
graphe
d'appel
tshark
PDML
graphes
coloriés
graphes
antérieurs
Fig 1. Opérations réalisées à partir des traces.
6
Submitted to SAR-SSI 2008
synthèse
protocoles/
champs
utilisés
Un autre moyen de réduire l’information présentée à l’utilisateur est d’utiliser les différences
entre traces provenant de tests différents afin d’isoler de nouvelles instructions ou fonctions.
Afin de réaliser cette opération nous construisons lors de chaque test un graphe d’appel. Les
blocs d’instructions sont assemblés en fonction des instructions de contrôle de flux qui les
terminent de telle sorte à représenter les appels de fonctions pouvant exister dans le code natif
original. Chaque instruction de contrôle de flux est analysée de telle sorte à déterminer les
transitions possibles entre le bloc courant et les blocs suivants. Il est à noter que certaines
instructions ne permettent pas de déterminer la transition à réaliser à partir d’une trace
d’instruction seule (e.g. appel du contenu d’un espace mémoire). Dans ce cas nous estimons le
saut le plus probable en fonction des blocs apparaissant par la suite. La construction du graphe
d’appel par le fait qu’elle se base sur une trace d’exécution peut ne pas être complète. Cependant
en choisissant de manière appropriée les configurations de filtrage testées, il est possible de
construire des graphes croissants de manière incrémentale. Il est alors possible de calculer les
recouvrements entre graphes et d’extraire les fonctions non représentées dans le graphe original.
4
Résultats préliminaires
Dans cette partie nous décrivons un ensemble de tests réalisés sur l’outil de filtrage IPfilter
4.1.28 [ipf] sous FreeBSD 6.3. Nous montrons comment les outils présentés dans la section
précédente permettent de fournir à l’utilisateur une vision assez synthétique du processus de
filtrage. Nous utilisons IPfilter car il est à la fois assez complexe (le code source du filtre seul
sans les outils de configuration comprend environ 50 000 lignes de code) et son code source est
disponible ce qui nous permet de vérifier les informations fournies par nos outils.
4.1
Architecture de test
Lors des tests nous utilisons deux machines virtuelles communiquant au travers d’un VLAN
fourni par Qemu. Afin de synchroniser les opérations de configuration et de test entre les deux
systèmes sans utiliser les fonctions réseau nous utilisons deux disques virtuels partagés entre les
deux machines.
L’utilisateur du système possède un écran de configuration qui permet de saisir une série de test
à réaliser. Chacun est constitué des opérations de configuration du filtre, des commandes
permettant de tester le fonctionnement de celui-ci et d'une indication que le résultat du test en
question peut être utilisé comme base de comparaison avec les tests suivants pour la construction
des graphes. Une fois les tests sélectionnés, la configuration du filtre est réalisée et les
commandes de génération de trafic exécutées automatiquement.
A la réception de trafic, la carte réseau virtuelle du système de filtrage déclenche un évènement
qui met en route les fonctions de log et à l’émission de celui-ci déclenche un autre évènement
qui arrête les fonctions de log et exécute un script sur la machine hôte qui analyse les logs
obtenus en utilisant les mécanismes décrits dans la section précédente. Pour chaque type de
champ présent dans le trafic généré, une vue de la trace d’exécution est crée qui présente les
instructions assembleur utilisées, la fonction auquel appartient le bloc ainsi que les
caractéristiques du champ marqué (paquet, sémantique, provenance). L’utilisateur du système
peut par la suite consulter ces vues en fonction du type de champ qu’il pense être affecté par la
configuration de filtrage.
En dehors des analyses présentées ci-dessus, le script produit une description graphique des
résultats au format GXL (Graph Exchange Language) [Win01]. Ce graphe peut par la suite être
visualisé après transformation au travers d’un outil tel que Graphviz [Graphviz].
A l’heure actuelle l’exécution d’un test prend environ 20 secondes.
Submitted to SAR-SSI 2008
7
4.2
Exemple de résultats
Notre outil fournit une vision synthétique des champs utilisés dans le processus de filtrage. La
Fig 2 fournit ainsi la liste des champs manipulés par IPfilter lors de l’utilisation de la
configuration suivante. Celle-ci autorise un paquet ICMP de type echo et provenant de
l’interface ed0 à traverser le filtre en provenance de n’importe quelle adresse source vers
n’importe quelle destination.
pass in quick on ed0 proto icmp from any to any icmp-type echo
La sémantique des champs est obtenue à partir de la description PDML fournie par tshark alors
que l'utilisation est calculée à partir de la trace contenant les marques. Il est intéressant de noter
que le champ IP checksum n’est pas utilisé par IPfilter dans notre installation. Les adresses IP
sont vérifiées bien que la règle ne spécifie pas de condition à leur sujet. Le champ ICMP ident
semble être utilisé. Cependant une vérification rapide du code obtenu montre que ce champ est
copié en mémoire mais n’est pas utilisé pas la suite dans le processus de filtrage.
Field
Used
eth.dst
eth.src
eth.type
ip.version
X
ip.hdr_len
X
ip.dsfield
X
ip.len
X
ip.id
X
ip.flags
X
ip.frag_offset
X
ip.ttl
X
ip.proto
X
ip.checksum
ip.src
X
ip.dst
X
icmp.type
X
icmp.code
X
icmp.checksum
icmp.ident
X
icmp.seq
data
Fig 2. Graphe d’appel présentant l’exécution du traitement d’un paquet.
La Fig 3 présente un exemple de graphe d’appel de fonctions obtenu au travers de notre outil
lors de l’utilisation d’IPfilter pour la configuration précédente.
Chaque cercle représente une fonction utilisée lors du test. Les arcs entre cercles représentent les
appels de fonction. Lorsque plusieurs arcs existent entre deux cercles, ils indiquent que plusieurs
appels ont été réalisés à partir de positions différentes dans la fonction d'origine. La couleur
associée à chaque fonction est calculée automatiquement de la manière suivante. Parmi ces
cercles, les cercles orange indiquent les fonctions provenant de l’utilisation d’IPfilter. Ceux-ci
sont obtenus en calculant la différence entre le graphe d’exécution lorsqu'IPfilter est désactivé et
celui lorsque la commande présentée ci-dessus est configurée. Les cercles verts représentent
8
Submitted to SAR-SSI 2008
parmi ces fonctions, les fonctions manipulant le champ type ICMP dans le paquet IP traité par le
filtre. Ceux-ci sont obtenus au moyen des informations de marquage fournies par notre version
modifiée d’Argos. Après vérification du code source du filtre les procédures indiquées
(représentées dans le graphe par leur adresse) sont bien les seules dans IPfilter à manipuler ce
champ.
Proc _3 2 26 4 20 10 0
Proc _3 2 27 0 96 39 6
Proc _3 2 27 0 00 44 8
Proc _3 2 27 1 02 52 0
Proc _3 2 27 1 01 90 4
Proc _3 2 27 0 14 79 2
Proc _3 2 27 1 03 97 6
Proc _3 2 27 8 00 79 6
Proc _3 2 27 0 15 03 2
Proc _3 2 25 6 66 80 8
Proc _3 2 27 0 56 47 6
Proc _3 2 27 0 08 50 8
Proc _3 2 27 0 00 02 4
Proc _3 2 27 0 41 33 6
Proc _3 2 25 6 39 61 2
Proc _3 2 25 7 5 11 88
Proc _3 2 25 7 01 26 8
Proc _3 2 27 0 05 20 0
Proc _3 2 26 7 41 78 0
Proc _3 2 27 0 90 82 8
Proc _3 2 26 7 41 52 0
Proc _3 2 25 6 61 42 8
Proc _3 2 25 6 99 57 6
Proc _3 2 25 6 37 96 0
Proc _3 2 25 6 37 82 4
Proc _3 2 26 0 43 45 6
Proc _3 2 26 0 49 86 4
Proc _3 2 27 5 35 15 6
Proc _3 2 26 7 34 74 8
Proc _3 2 25 6 51 98 8
Proc _3 2 25 6 44 99 4
Proc _3 2 25 6 40 68 0
Proc _3 2 26 9 37 33 6
Proc _3 2 25 6 40 08 8
Proc _3 2 27 0 61 00 0
Proc _3 2 26 9 70 00 4
Proc _3 2 27 8 56 94 8
Proc _3 2 27 8 56 02 0
Proc _3 2 27 8 13 63 6
Proc _3 2 27 0 34 44 4
Proc _3 2 26 9 66 24 8
Proc _3 2 27 0 21 73 6
Proc _3 2 26 0 45 87 6
Proc _3 2 27 8 02 60 8
Proc _3 2 27 8 56 10 0
Proc _3 2 29 1 91 41 6
Proc _3 2 27 8 02 92 8
Proc _3 2 29 1 90 21 6
Proc _3 2 27 7 89 56 8
Proc _3 2 26 1 71 34 4
Proc _3 2 26 4 19 48 0
Proc _3 2 26 5 83 22 0
Proc _3 2 29 3 38 74 4
Proc _3 2 29 2 24 35 2
Proc _3 2 27 8 04 31 6
Proc _3 2 26 9 99 72 0
Proc _3 2 27 8 05 13 6
Proc _3 2 29 3 38 82 4
Proc _3 2 26 9 72 112
Proc _3 2 26 7 35 41 6
Proc _3 2 27 8 12 61 6
Proc _3 2 25 6 41 75 6
Proc _3 2 29 2 24 24 8
Proc _3 2 29 1 97 55 6
Proc _3 2 26 0 50 39 6
Proc _3 2 26 4 66 96 8
Proc _3 2 27 7 89 00 8
Proc _3 2 25 6 38 91 6
Proc _3 2 25 6 71 74 0
Proc _3 2 26 0 43 35 6
Proc _3 2 26 7 33 54 8
Proc _3 2 25 6 42 90 0
Proc _3 2 27 8 55 82 4
Proc _3 2 26 0 47 65 6
Proc _3 2 27 0 00 20 0
Proc _3 2 27 8 12 68 4
Proc _3 2 26 9 66 35 2
Proc _3 2 26 3 30 34 0
Proc _3 2 27 8 04 17 2
Proc _3 2 26 3 30 08 8
Proc _3 2 26 1 73 70 4
Proc _3 2 26 5 47 66 8
Proc _3 2 26 4 19 09 6
Proc _3 2 27 8 03 95 2
Proc _3 2 26 5 45 87 6
Proc _3 2 27 8 24 36 0
Proc _3 2 26 0 45 99 6
Proc _3 2 26 0 5 11 20
Proc _3 2 29 2 24 40 7
Proc _3 2 26 4 19 57 6
Proc _3 2 26 4 74 02 0
Proc _3 2 26 5 83 24 8
Proc _3 2 27 8 24 31 6
Proc _3 2 26 5 36 17 2
Proc _3 2 26 5 82 86 8
Proc _3 2 27 8 99 54 8
Proc _3 2 26 5 80 66 8
Proc _3 2 27 8 98 41 2
Proc _3 2 26 5 80 39 2
Proc _3 2 26 5 79 52 0
Proc _3 2 26 5 83 70 0
Proc _3 2 27 8 57 26 4
Proc _3 2 26 5 44 41 2
Proc _3 2 26 5 82 16 8
Proc _3 2 29 2 98 67 2
Proc _3 2 26 5 81 84 4
Proc _3 2 29 2 98 27 6
Proc _3 2 26 5 83 93 2
Proc _3 2 27 5 69 33 2
Proc _3 2 26 5 80 32 4
Proc _3 2 27 8 98 30 8
Proc _3 2 26 5 81 26 4
Proc _3 2 26 5 81 68 0
Proc _3 2 26 3 31 06 8
Proc _3 2 26 5 83 85 6
Fig 3. Graphe d’appel présentant l’exécution du traitement d’un paquet.
La Fig 4 présente un exemple de vue telle qu’elle est fournie à l’utilisateur lorsqu’il désire
obtenir les informations associées à un champ particulier. Notre exemple représente les fonctions
liées à la manipulation du champ Type ICMP pour la règle présentée ci-dessus. Elle indique que
les instructions movzbl, cmp et ja utilisent le champ type ICMP du paquet 54 (0x0036).
block[0xc043549a;0x00054d7f]={IN:
0xc043549a
mov
0x4(%edx),%ax
0xc043549e
mov
%ax,0x3e(%ebx)
0xc04354a2
movzbl (%edx),%eax
from 0x02650e54 [0x0036 icmp.type]
0xc04354a5
cmp
$0x12,%eax
from 0x02650e54 [0x0036 icmp.type]
0xc04354a8
ja
0xc0435530
from 0x02650e54 [0x0036 icmp.type]
}
Fig 4. Trace présentée à l’utilisateur.
4.3
Estimation de l’importance des opérations de simplification
Lors des tests nous nous sommes intéressés à deux aspects. Le premier concerne la justesse de la
simplification présentée à l’utilisateur. L’autre concerne le nombre d’instructions présentées à
l’utilisateur en fonction des techniques de simplification utilisées. Le tableau ci-dessous présente
Submitted to SAR-SSI 2008
9
plusieurs combinaisons. La simplification temporelle correspond au fait de ne conserver une
trace que lorsque un paquet est présent à l’intérieur du système de filtrage. Le marquage sans
type considère toutes les instructions manipulant les données d’un paquet. Le marquage avec
type considère les instructions manipulant le type donné en tête de colonne. L'utilisation du
graphe d'appel consiste à ne présenter que les instructions qui appartiennent à des fonctions qui
ne sont pas présentes dans un graphe original (ici le graphe original est obtenu lors d'une
exécution dans laquelle le module de filtrage n'est pas activé). Enfin la simplification par type
d’instruction supprime les instructions (utilisation de la pile, entrée/sorties, ...) dont la présence
n’est pas indispensable à la compréhension du code assembleur.
Type de simplification
Aucun
Temporel
Temporel, marquage sans type
Temporel, marquage avec type
Temporel, marquage, graphe d’appel
Temporel, marquage, graphe d’appel, type
d’instruction
Instructions
(Addr IP DST)
2.5.109
1.9.106
32.103
6825
180
87
Instructions
(Type ICMP)
2.5.109
1.8.106
31.103
87
67
41
Le tableau montre les résultats pour deux configurations de filtrage différentes. Vis à vis de
traces brutes, les différentes techniques de simplification permettent d’affiner considérablement
la vision fournie à l’utilisateur.
5
Conclusion
Dans cet article nous avons montré comment au travers de processus d’analyse automatique il
était possible pour l’utilisateur d’un système de filtrage de simplifier la vision qu’il pouvait
obtenir vis-à-vis d’une trace d’exécution brute. Cette simplification n’est pour le moment pas
directement utilisable dans la mesure où elle permet principalement d’indiquer à l’utilisateur
dans comment une configuration provoque un fonctionnement différent d’une autre
configuration de filtrage. Celui-ci a donc toujours besoin de comprendre la syntaxe des règles de
configuration et au moins une partie de leur sémantique afin de construire un trafic de test
approprié. Notre objectif est donc d’utiliser comme base ces outils afin de pouvoir construire un
modèle formel des opérations réalisées par un filtre à la manière de [Bru07] sans que celui-ci ne
soit de taille trop importante. Une telle approche nous permettrait de construire de manière
automatique des unités de données validant (ou ne validant pas) une configuration du pare-feu.
Cependant en l’état actuel notre outil permet déjà d’améliorer la compréhension que l’on peut
avoir d’un outil de filtrage sans se reposer sur la lecture de son code source.
References
[Pa07] Olivier Paul. There’s nothing like a firewall. Présentation au Workshop IEEE Monam 07.
2007.
[Gu05] Saikat Guha et Paul Francis. Characterization and Measurement of TCP Traversal
through NATs and Firewalls, Dans ACM Internet Measurement Conference, 2005.
10
Submitted to SAR-SSI 2008
[Mut05] Darren Mutz, Christopher Kruegel,, William Robertson, Giovanni Vigna, et Richard
Kemmerer. Reverse Engineering of Network Signatures. Dans Information Technology
Security Conference (AusCERT). Mai 2005.
[Senn05] Senn Diana, Basin David et Caronni Germano. Firewall Conformance Testing. Dans
IFIP TestCom 2005. LNCS 3502. 2005.
[Yin07] Heng Yin, Dawn Song, Manuel Egele, Christopher Kruegel, et Engin Kirda. Panorama:
Capturing System-wide Information Flow for Malware Detection and Analysis. Dans
ACM CCS 2007.
[Cab07] Juan Caballero, Heng Yin, Zhenkai Liang, Dawn Song. Polyglot: Automatic Extraction
of Protocol Message Format using Dynamic Binary Analysis. Dans ACM CCS 2007.
[Bel05] F. Bellard. Qemu, a fast and portable dynamic translator. Dans USENIX Annual
Technical Conference, FREENIX Track, 2005.
[Por06] Georgios Portokalidis, Asia Slowinska et Herbert Bos. Argos: an Emulator for
Fingerprinting Zero-Day Attacks ACM EuroSys 2006. 2006.
[Bru07] David Brumley, Juan Caballero, Zhenkai Liang, James Newsome, Dawn Song. Towards
Automatic Discovery of Deviations in Binary Implementations with Applications to
Error Detection and Fingerprint Generation. Dans Usenix Security 07. 2007.
[ipf] IP Filter - TCP/IP Firewall/NAT Software. Disponible à coombs.anu.edu.au/~avalon/.
[hping] Hping - Active Network Security Tool. Disponible à www.hping.org.
[CC] Common criteria Protection Profiles. Disponible à www.commoncriteriaportal.org.
[Win01] A. Winter, B. Kullbach, V. Riediger. An Overview of the GXL Graph Exchange
Language. Software Visualization, International Seminar Dagstuhl Castle. 2001.
[Graphviz] Graphfiz, Graph Visualization Software. Disponible à www.graphviz.org
[tshark] tshark, the wireshark network analyzer. Disponible à www.wireshark.org/docs/manpages/tshark.html
[Bal05] M. Baldi et F. Risso Using XML for Efficient and Modular Packet Processing. Dans
IEEE Globecom 05. 2005.
Submitted to SAR-SSI 2008
11