Approche par scénario - 1

L’approche par scénario (misuse detection) consiste à détecter une intrusion en fonction du comportement actuel de l’utilisateur, indépendamment de ses actions passées. La terminologie « approche par scénario » vient du fait que l’on s’appuie sur la connaissance des techniques utilisées par les attaquants pour déduire des scénarios typiques.
La plupart des méthodes utilisées s’appuient sur la notion de signature d’attaque. Le terme signature est ambigu car il est souvent assimilé uniquement à des techniques de recherche de motifs dans des paquets (pattern matching) alors qu’il est bien plus générique que cela. De manière générale, une signature désigne un ensemble de caractéristiques permettant d’identifier une activité intrusive : il peut s’agir d’une chaîne alphanumérique, d’une taille de paquet inhabituelle, d’une trame formatée de manière suspecte, etc.

1- Recherche de motif (pattern matching)

Le pattern matching est sans doute la méthode la plus connue et la plus facile à comprendre. Elle se base sur la recherche de motifs caractéristiques d’une attaque au sein d’un flux de données, ce motif étant représenté par une chaîne alphanumérique.

Avantages de cette méthode :

Simplicité de la mise en œuvre
Dans la mesure où on recherche des motifs spécifiques, la qualité de la détection est bonne (si les patterns sont bien écrits !)
Cette méthode peut être facilement adaptée à tous les protocoles

Inconvénients de cette méthode :

Les patterns doivent être de bonne qualité pour éviter de déclencher des fausses alertes
Un pirate expérimenté peut déguiser son attaque de manière à ce qu’elle ne soit pas détecté (faux négatif), ce qui peut conduire parfois à la multiplication du nombres de signatures pour détecter une attaque unique.
Cette technique peut s’avérer consommatrice en termes de mémoire et de temps processeur si le nombre de signatures est important
L’analyse séquentielle des paquets se fait de manière individuelle sans notion d’état de la session. Pour remédier à cette situation, certains éditeurs implémentent un mode dit statefull pattern matching. Celui-ci consiste à considérer globalement tous les paquets liés à une même session plutôt que d’effectuer une analyse atomique de chaque paquet. Il ne s’agit pas à proprement parler d’une nouvelle technique mais d’une amélioration du pattern matching simple. Pour bien comprendre la nuance, prenons l’exemple où un pirate sépare une requête en deux blocs (get /cgi- d’une part et bin/phf d’autre part par exemple). Une requête simple de motif risque de ne déclencher aucune alerte. En utilisant le statefull pattern matching, les paquets sont identifiés comme faisant partie de la même session et une opération de reconstruction de la session aura lieu avant d’effectuer la recherche du motif. La plupart des solutions du marché travaillent selon ce mode de fonctionnement.

2- Analyse des protocoles

On a souvent tendance à opposer l’analyse de protocoles au pattern matching alors qu’il s’agit d’une méthode complémentaire.

Cette technique analyse les flux selon deux axes :

Vérification de la conformité du trafic avec les RFCV liées aux différents protocoles utilisés
Observation des champs et paramètres suspects liés à certains protocoles de façon à s’assurer que ceux-ci ne sont pas utilisés à des fins malicieuses par un attaquant. Ceci est à distinguer de la vérification de conformité car il est bien rare que les éditeurs et constructeurs respectent à la lettre les RFC et autres normes. Les nombreuses améliorations apportées par ces éditeurs découlent souvent d’une interprétation des RFC !

La détection peut être faite en utilisant des techniques à base de pattern matching (pour détecter l’exploitation de valeurs interdites dans certains champs ou pour contrôler la longueur de certains champs) ou de règles d’analyse implémentées dans une préprocesseur spécifique à chaque protocole (contrôle du nombre d’arguments passés en paramètres par exemple).
Supposons qu’un pirate souhaite exploiter un buffer overflow au sein d'un serveur FTP en se connectant en tant qu'utilisateur anonyme avec un mot de passe de 500 caractères. Un moteur d'analyse protocolaire classifiera ceci comme événement suspect lié au protocole FTP avec une probabilité relativement bonne (à moins que l'on soit paranoïaque et que notre politique de sécurité impose des mots de passe très longs).

Il faut être toutefois prudent quand on associe les termes analyse de protocoles et conformité aux RFC. Certains IDS sont capables de détecter le buffer overflow et prétendent utiliser des techniques d'analyse protocolaire sans pour autant implémenter des vérifications de conformité aux RFC décrivant le protocole FTP.

Avantages de cette méthode :

L'analyse protocolaire permet de détecter des attaques inconnues
De plus, elle ne nécessite pas de développer de signatures spécifiques

Inconvénients de cette méthode :

Cette technique a tendance à générer plus de faux positifs. Cela est d'autant plus vrai que l'implémentation se contente de vérifier la conformité aux RFC; en effet, de nombreux constructeurs et éditeurs (Cisco et Microsoft en tête) ont souvent tendance à améliorer les fonctionnalités des RFC afin de mieux les adapter à leur offre.
Cette méthode nécessite l'écriture de décodeurs spécifiques à chaque protocole
Les performances sont souvent moins bonnes que le pattern matching du fait des préprocesseurs qui doivent effectuer des tâches complexes en amont
Ces méthodes manquent de granularité dans la mesure où elles fournissent peu de données liées à l'intrusion, ce qui rend difficile l'évaluation de l'impact. Par exemple, un système pourra générer une alarme de type « Attention : votre trafic SNMP paraît anormal » qui pourra paniquer un exploitant inexpérimenté.

Comparaison entre analyse de protocoles et pattern matching

Pour bien comprendre la différence entre analyse de protocoles et pattern matching, on peut utiliser l'analogie suivante:

Dans le cadre de l'analyse par pattern matching, on détecte tout ce que l'on sait comme explicitement suspect, ce qui implique l'utilisation d'une base d'attaques connues.
Avec l'analyse protocolaire, les flux à analyser sont considérés comme surs quand ils sont construits selon des normes et standards connus et on estime que tout ce qui sort de ce cadre est suspect (champ dont la longueur dépasse celle qui est définie, mauvaise utilisation d'une requête, etc...)

Pour illustrer ce qui précède, examinons de plus près l'implémentation de méthodes de pattern matching et d'analyse protocolaire dans le cas de la détection du ver Slammer.
Une signature basée sur une méthode de pattern matching figure ci-dessous (il s'agit d'une règle utilisée par Snort):

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (\
 msg :  « W32.SQLEXP.Worm propagation »; \
 content : « |68 2E  64 6C 68 65 6C 33 32 68 6B 65 72 6E| »; \
content :  « |04 »; offset : 0; depth : 1;)

Si on observe l'implémentation de RealSecure, qui utilise essentiellement des méthodes d'analyse protocolaire, la règle prend la forme suivante :

SQL_SSRP_StackBo is
(
udp.dst = 1434
ssrp.type = 4
ssrp.name.length > 97
)
where ssrp.type is first-byte of packet
where ssrp.name is nul-terminated  string starting at second byte

Les deux méthodes commencent d'abord par analyser les flux à destination du port UDP 1434. Dans les deux cas, la première vérification consiste à s'assurer que le premeir octet de données est « 04 ». Les similarités s'arrêtent ici : alors que la règle Snort recherche une chaîne spédcifique (mentionnée après le champ content), la règle de RealSecure teste plutôt une condition anormale décrite dans la signature.
RealSecure peut ainsi détecter une anomalie liée à des flux SQL sans connaître au préalable l'existence de l'att que Slammer. Il sera en revanche incapable de donner à l'analyste des informations plus précises qui pourraient l'aider à établir un diagnostic. C'est la raison pour laquelle ISS a développé une seconde signature Slammer après que l'attaque fut rendue publique afin de fournir plus d'informations aux exploitants :

SQL_SSRP_SlammerWorm is
(
SQL_SSRP_StackBo
Pattern-search[offset  = 97] = DCC9B042EB0E010101010101
)

D'un autre côté, Snort n'était pas capable de détecter l'attaque Slammer avant qu'elle ne soit découverte, la signature correspondant n'existant pas encore. En revanche, Snort fut capable après la mise à jour d'identifier et de communiquer de manière précise la nature de l'attaque de l'analyste.

REMARQUE

Le fait de disposer au préalable de la signature appropriée pour détecter une attaque est un faux problème. L'attaque Slammer en est une bonne illustration : le ver Slammer exploite une vulnérabilité de la base MS-SQL que microsoft avait identifiée et corrigée plus de 6 mois auparavant! Cela signifie que si l'administrateur du réseau n'a pas eu le temps d'appliquer le correctif dans ce laps de 6 mois, il est probable qu'il n'ait pas les ressources nécessaires pour gérer l'intrusion « en temps réel ». La mise à jour de la base de signature de l'IDS a posteriori ne pose donc pas de problèmes dans ce cas tant que l'éditeur est suffisamment réactif pour fournir la signature manquante. Et si on se base toujours sur l'exemple de Slammer, l'utilisateur a du procéder à une mise à jour des bases de signature de l'IDS après l'attaque, aussi bien avec des produits utilisant majoritairement l'analyse protocolaire (RealSecure) que ceux implémentant de préférence la comparaison de chaînes (Snort).