IDS - Syst�me de D�tection d'Intrusion, Partie II

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

SystemAdministration

AuthorImage:[Here we need a little image from you]

[Photo of the Author]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in de Klaus Müller

de to en Jürgen Pohl

en to fr Jean-Etienne Poirrier

AboutTheAuthor:[A small biography about the author]

Pour le moment, Klaus Müller (aussi connu sous le nom de 'Socma') est toujours �tudiant. Il s'occupe avec de la programmation sous Linux et les sujets li�s � la s�curit�.

Abstract:[Here you write a little summary]

Dans la premi�re partie, nous nous sommes concentr�s sur les attaques types sur les Syst�mes de D�tection d'Intrusion (IDS, Intrusion Detection Systems). La seconde partie introduit les m�thodes pour les d�couvrir et nos r�ponses : l'application de signatures et de filtres sont parmi celles-ci. Finalement, nous introduirons Snort et LIDS.

ArticleIllustration:[One image that will end up at the top of the article]

[Illustration]

ArticleBody:[The main part of the article]

Les possibilit�s d'analyse

Pr�c�demment, nous nous sommes �tendus sur les attaques pour prot�ger les IDS et les diff�rents syst�mes pour les contrer. Nous avons ensuite couvert les m�thodes d'analyse et la mani�re dont un IDS d�termine si c'�tait une attaque ou pas; respectivement si l'attaque a �t� couronn�e de succ�s ou non.

� la base, nous faisons la diff�rence entre la D�tection d'Abus (Misuse Detection) et la D�tection d'Anomalie (Anomaly Detection). La D�tection d'Abus utilise des motifs d�finis sp�cifiques pour d�masquer une attaque. Ces motifs sont appel�s des � signatures �, elles seront d�taill�es dans une section d�di�e sp�cifique. Pour le moment, nous avons besoin de savoir que nous pouvons d�finir des signatures qui cherchent une certaine cha�ne (par exemple � /etc/passwd �) dans le trafic r�seau, refusent les demandes d'acc�s � des fichiers sp�cifiques et envoient une alerte. L'avantage de la D�tection d'Abus est la faible probabilit� de fausses alarmes puisque les crit�res de signatures peuvent �tre d�finis de mani�re pr�cise. Les d�savantages sont aussi �vidents : les nouvelles attaques passent fr�quemment sans �tre d�tect�es faute de d�finition (voir la section ... sur les signatures).

L'autre m�thode est la D�tection d'Anomalie. Cela signifie simplement qu'un profil des activit�s normales de l'utilisateur a �t� cr��. Si le comportement de l'utilisateur d�vie trop de ce profil, une alarme est d�clench�e. La premi�re �tape de cette analyse est la cr�ation de profils (base de donn�es) des activit�s � normales � de l'utilisateur. Un grand nombre d'�tapes peuvent �tre enregistr�es : Combien de fois l'utilisateur ex�cute-t-il des commandes sp�cifiques ? Quand ex�cute-t-il des commandes sp�cifiques ? Combien de fois ouvre-t-il des fichiers sp�cifiques ? ... Un petit exemple : l'utilisateur � Exemple � ex�cute /bin/su trois fois par jour (cette valeur sera dans le profil). De mani�re soudaine, un jour, l'utilisateur � Exemple � ex�cute su sept fois dans la journ�e, plus de deux fois plus souvent que la normale. La D�tection d'Anomalie d�tectera ce comportement � anormal � et avertira l'administrateur au sujet des sept ex�cutions de su de l'utilisateur � Exemple � alors que trois sont la moyenne � normale �. Les d�savantages de cette proc�dure me sont apparus clairement lorsque j'ai commenc� son impl�mentation (voir l'exemple de COLOID, � la fin). La m�thode pour installer la base de donn�es des activit�s de l'utilisateur, requiert des calculs intensifs. Nous surveillons, par exemple, combien de fois l'utilisateur a ouvert dix fichiers sp�cifiques. Avec chaque commande open(), on doit v�rifier si cela concerne un des dix fichiers sp�cifiques et si le r�sultat est positif, le compteur correspondant est incr�ment�. N�anmoins, c'est une belle opportunit� de d�couvrir de nouvelles techniques d'attaques puisqu'elles appara�tront tr�s probablement comme � anormales �. En outre, l'administrateur lui-m�me peut d�finir quelle d�viation doit �tre consid�r�e comme � anormale �, par exemple une d�viation de 10% ou m�me 75%... En utilisant cette m�thode, nous devons faire attention � g�n�rer les profils d'utilisateur dans un r�seau � sain �, sinon le comportement de l'attaquant sera consid�r� comme normal et la conduite d'un utilisateur l�gitime comme anormale.

En g�n�ral, la D�tection d'Anomalie inclut les proc�dures suivantes :
La D�tection � Heuristique � de Seuil, dans ce cas, signifie que le compteur (combien de fois a �t� ex�cut� ce qui peut l'�tre) n'est pas initialement d�fini � une valeur statique mais dynamique. Qu'un utilisateur ex�cute normalement /bin/login/ quatre fois, le compteur pourrait �tre d�fini alors � cinq ...
La D�tection d'Anomalie de Protocole repr�sente un sous-groupe de la D�tection d'Anomalie. C'est une technique relativement r�cente ; elle fonctionne, � la base, comme la D�tection d'Anomalie. Chaque protocole a une signature � pr�-d�finie � (voir les RFCs correspondantes). Le but de la D�tection d'Anomalie de Protocole est de trouver si le comportement du protocole est comme celui pr�-d�fini ou non. Plus d'attaques sont bas�es sur l'abus de protocole qu'on pourrait le croire ; ce sous-groupe est donc assez important pour les IDS. En regardant de nouveau la section sur le balayage (scanning), nous pouvons trouver quelques indicateurs pour la D�tection d'Anomalie de Protocole.
Dans les RFC correspondantes, nous trouverons les sp�cificit�s correctes ainsi que les types de comportements qui ne devrait pas se produire et quel type de comportement devrait avoir lieu en r�ponse � un �v�nement sp�cifique. En outre, il y a la D�tection d'Anomalie d'Application (qui fonctionne presque comme les IDS bas�s sur Application). Dans la litt�rature, j'ai trouv� plus d'indications sur le sujet et je l'ai approfondi. Bien s�r, un programme a un comportement � normal �, par exemple : comment r�agit-t-il � l'�v�nement X, Y ou si un utilisateur note quelque chose d'erron�. Souvent, les binaires existant (par exemple, ps, netstat, etc.) sont remplac�s par l'entr�e de l'utilisateur, pour cacher des processus sp�cifiques dans le cas de ps. Avec la D�tection d'Anomalie d'Application, il serait possible de d�tecter le comportement � anormal � d'un programme. Quelques IDS bas�s sur application fonctionnent ainsi, mais j'ai peu d'exp�rience avec eux.

Finalement, voici une autre nouvelle m�thode parmi les IDS : la Pr�vention d'Intrusion. Elle est appliqu�e par quelques nouveaux IDS et diff�re des pr�c�dentes m�thodes de d�tection d'intrusion d�crites pr�c�demment. A la place d'analyser les logfiles/ du trafic c'est-�-dire d�couvrir les attaques apr�s qu'elles se soient d�roul�es, la Pr�vention d'Intrusion essaie de pr�venir ces attaques.

Contrairement aux IDS classiques, aucune signature n'est utilis�e pour d�tecter les attaques. Ce qui suit est une courte explication sur la mani�re dont travaille ces IDS. Leurs fonctionnalit�s devraient devenir claires avec les exemples suivants :



La � surveillance du comportement d'application � se rapproche des IDS bas�s Application c'est-�-dire que le comportement de l'application est analys� et not� (quelles donn�es sont normalement demand�es, avec quels programmes elle interagit, quelles ressources sont requises...). Comme la D�tection d'Anomalie, elle essaie de trouver la mani�re dont un programme op�re normalement, ce qu'il est permis de faire.

La troisi�me fonctionnalit� (� Alerte suite aux violations �) ne n�cessite aucune explication : cela signifie qu'une alerte est envoy�e seulement en cas de d�viation (c'est-�-dire quand une attaque est d�tect�e). Cela peut r�sulter simplement en une entr�e dans un journal ou un blocage de ressources.

Avec la seconde fonctionnalit� (� Cr�ation de r�gles d'application �), ce qui est appel� une r�gle d'application est �tabli en se basant sur l'information r�sultant de l'analyse en premi�re partie (� Surveillance du comportement d'application �). Cet ensemble de r�gles donne des informations sur ce que peut faire une application (quelles ressources peut-elle demander ?) et ce qu'il n'est pas permis de faire � une application.

La � Corr�lation avec d'autres �v�nements � signifie un partage d'informations entre des senseurs coop�ratifs, cela donnant une meilleure protection contre les attaques. 
       Application
        |
        V
       Action
        |
        V
  --------------------------
  | D�cision en temps r�el |
  --------------------------
       /       \
    Refuser   Permettre
       /           \
   Alerte     Executer une Action


Ce diagramme simplifi� devrait clarifer une fois de plus le processus. Avant toute activit�, une � d�cision en temps r�el � est ex�cut�e (c'est-�-dire l'activit� est compar�e � l'ensemble de r�gles). Si l'activit� est ill�gale (c'est-�-dire si le programme demande des donn�es ou veut les changer m�me s'il ne lui est pas permis d'acc�der aux donn�es du syst�me), une alarme est donn�e. Dans la plupart des cas, les autres senseurs (ou une console centrale) en sera aussi inform�e. Cela devrait emp�cher les autres ordinateurs du r�seau d'ouvrir ou d'ex�cuter des fichiers sp�cifiques. Si l'activit� se conforme � l'ensemble de r�gles, la permission sera accord�e et l'activit� aura finalement lieu.

Finalement, voici le dernier item sur notre liste : � Interception d'appels au syst�me �. Manipuler les appels au syst�me (c'est-�-dire ce qu'on appelle les rootkits) sont fr�quennement d�tect�s. L'approche de l'interception des appels au syst�me est assez simple : avant qu'un appel au syst�me soit � accept� �, on le v�rifie compl�tement. Le v�rifier signifie, par exemple, se poser les questions suivantes (voir aussi [5]) :



Cela permet la surveillance des essais de changements d'importants fichiers du syst�me ou de la configuration. Nous n'avons qu'� v�rifier si l'appel syst�me satisfait l'ensemble de r�gles pr�d�fini ou non.

               Programme
                   |
                   V
             Appel Syst�me
                   |
                   V
       Interception de l'Appel Syst�me
                 /          \
             Refus        Permission
               |               |
        Ne pas effectuer     Noyau
        l'appel syst�me


Puisque la Pr�vention d'Intrusion est relativement nouvelle (par comparaison avec les autres m�thodes), plus d'informations sur le sujet seront disponibles.

En conclusion, un conseil pour OKENA, un IPS � fort potentiel. Dans la section des articles (white paper) sur www.okena.com, vous pourrez trouver plus d'informations sur Storm Watch. Pour avoir des informations au sujet des imperfections de Storm Watch, voyez [6].

Signatures



Maintenant, nous allons voir l'utilisation de signatures dans les IDS. La seconde partie va couvrir leurs faiblesses.

Concept

A l'aide des signatures, les attaques connues peuvent �tre reconnues, une signature correspondant � un certain motif dans les donn�es du traffic. Ce motif peut �tre une vari�t� d'�l�ments comme des cha�nes, un en-t�te remarquable (avec des combinaisons de drapeaux inhabituelles), des ports connus pour �tre utilis�s par des trojans. La plupart des attaques ont certaines caract�ristiques, par exemple des drapeaux sp�cifiques sont d�finis ou des cha�nes dans le corps. � travers les signatures, on essaie de d�couvrir les attaques � partir de ces caract�ristiques.

Je souhaiterais commencer avec ce qu'on appelle les Signatures de Charge Utile (� Payload Signatures �). Voici une partie d'un paquet de charge utile : 
00 00 00 00 E9 FE FE FF FF E8 E9 FF FF FF E8 4F    ...............
0 FE FF FF 2F 62 69 6E 2F 73  68 00 2D 63 00 FF FF .../bin/sh.-c...


Comme nous le verrons plus tard dans la description des r�gles de SNORT, il y a plusieurs options pour effectuer cela. On cherche g�n�ralement des cha�nes sp�cifiques (dans Snort, avec � content � ou � content-list �) dans le contenu de la charge utile. Admettons que quelqu'un veuille acc�der �, par exemple, un fichier de mot de passe (par exemple /etc/passwd), on peut chercher dans la charge utile (pour /etc/passwd) et, si le paquet contient cette cha�ne, des contre-mesures peuvent �tre entreprises comme : 

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80        \
 (msg:"WEB-MISC/etc/passwd";flags: A+; content:"/etc/passwd"; \
 nocase;classtype:attempted-recon; sid:1122; rev:1;)


Une autre possibilit� est la d�tection de paquets qui ne comportent pas une cha�ne sp�cifique.

Une autre approche pour se prot�ger d'un possible d�bordement de tampon est de contr�ler la taille des paquets sur un port sp�cifique. Il est en g�n�ral possible de d�finir le port source, le port de destination et les requ�tes �manant de ports sp�cifiques ou destin�s � des ports sp�cifiques peuvent �tre interdits. Les cha�nes signature sont en g�n�ral des signatures de corps, par exemple, la recherche d'une cha�ne sp�cifique dans la signature d'une cha�ne dans le corps.
Quoi d'autre peut �tre d�tect� � partir des signatures ? Chercher des cha�nes sp�cifiques dans la charge utile n'est pas toujours la meilleure solution. Une autre possibilit� est de laisser la recherche de signature pour une combinaison de drapeau dans l'en-t�te TCP. Si, dans un paquet, le bit SYN tout comme le bit FIN sont d�finis, cela repr�sente une anomalie qu'un attaquant pourrait utiliser pour trouver des fonctionnalit�s sp�cifiques du syst�me d'exploitation (ou le syst�me d'exploitation lui-m�me). Comme nous l'indiquions au d�but, il y a des ports sp�cifiques qui sont connus pour �tre pr�f�r�s par les trojans, par exemple les ports 31337 ou 27374.

Peut-�tre cela deviendra-t-il plus clair si j'explique le processus avec un exemple. Jetons un oeil aux indicateurs typiques d'une attaque synscan :



Dans des cas comme celui-ci, la fonction de la signature devrait �tre de pouvoir diff�rencier entre les fonctionnalit�s � normales � et � anormales � d'une connection. Quelques IDS tiennent des bases de donn�es sp�ciales avec l'information, comme montr� ci-dessus, il vont y chercher les correspondances.
En principe, les anomalies peuvent �tre d�tect�e dans l'exemple synscan avec la v�rification de signature :


Le d�veloppement de la signature pour la d�tection d'une attaque synscan doit prendre plus de crit�res que ceux mentionn�s ci-dessus. Le but de la signature devrait �tre la d�tection d'attaques existantes tout comme celle de nouvelles attaques. Pour cette raison, des caract�ristiques g�n�rales et sp�ciales devraient �tre combin�es pour augmenter la probabilit� de d�tecter une attaque. M�me s'il serait possible d'�crire une nouvelle signature pour chaque version d'une attaque, cela pourrait nous occuper pour longtemps, nous emp�chant de faire des choses plus importantes. Ainsi, nous devons faire attention aux signatures d�tectant le plus possible d'attaques (et leurs versions), sans n�cessit� de les �diter.

Les signatures devraient �tre �crites pour d�tecter les attaques sp�cifiques mais on a aussi besoin de signatures g�n�rales pour trouver les anomalies. Un exemple de signature pour la d�tection d'une attaque sp�cifique est montr� ci-dessus (l'attaque de synscan). Une signature plus g�n�rale, par exemple, pourrait �tre la v�rification pour les crit�res suivantes :



Les signatures qui, en g�n�ral, cherchent des anomalies dans les protocoles sont appel�es des � Signatures bas�es sur l'Analyse de Protocole � alors qu'un autre groupe est connu comme � Packet Grepping �.

Faiblesses


M�me si la m�thode des signatures de corps (y compris les signatures de cha�ne) semble �tre assez s�re, il y a moyen de les contourner. J'�crirai probablement un papier sur la mani�re de contourner les r�gles de Snort mais je vais me limiter ici � l'essentiel. Une signature, comme montr� plus haut, recherche � /etc/passwd �, avec la mise en majuscule nocase ignor�e. Cependant, si nous approchons /etc/passwd indirectement et pas directement (par exemple si l'attaquant utilise � /etc/blablabla/.../.../\passwd �), est-ce que la signature tirera quand m�me le signal d'alarme ? Non, parce qu'elle cherche pour /etc/passwd (et les autres versions en minuscule/majuscule). Une autre limite de ces signatures est la d�tection des attaques les plus connues et leur recherche des vuln�rabilit�s connues. Les nouvelles versions d'attaques sp�cifiques ne sont souvent pas d�couvertes ... D'autres signatures (qui sont sp�cialis�es pour des attaques sp�cifiques) ou les signatures g�n�ralis�es ont l'avantages de d�couvrir ces nouvelles attaques. Cependant, on doit faire attention lors de la cr�ation de r�gles de signature. Une signature qui est sp�cialis�e dans une attaque sp�cifique ne trouvera pas une variante l�g�rement modifi�e (par exemple : � la place d'une valeur d'ID d'IP de 39426, la nouvelle attaque a une valeur variable ...). En tra�ant les signatures g�n�rales (signatures bas�es sur l'analyse de protocole), nous devons �tre s�r que les r�gles sont r�ellement d�finies globalement, c'est-�-dire qu'elles doivent �tre autoris�es � montrer des anomalies qui ne peuvent ou ne devraient pas arriver.

Un autre �cueil appara�t � l'examen plus serr� de l'attaque Unicode (voir [4]). Voici une description typique d'un trou de s�curit� dans MS IIS qui a �t� permis par l'attaque Unicode :

� Synth�se :
Une faille existe dans Internet Information Server (IIS) de Microsoft ; elle permet aux utilisateurs distants de lister le contenu de r�pertoires, voir les fichiers, les effacer et d'ex�cuter des commandes arbitraires. Les attaquants pourraient utiliser l'ensemble de caract�res Unicode pour cr�er des URL afin d'acc�der, via IIS, aux ressources qui devraient �tre normalement inaccessibles. Toutes les versions r�centes d'IIS sont affect�es par cette vuln�rabilit�. L'exploitation de celle-ci est triviale. ISS X-Force est au courant de l'exploitation r�pandue de cette vuln�rabilit�. �

Un probl�me pour les IDS r�side dans le fait que les caract�res en UTF-8 ont plusieurs codes avec le m�me r�sultat, par exemple � A � : U+0041, U+0100, U+0102, U+0104, U+01CD, U+01DE, U+8721. Puisque MS IIS n'est pas sensible � la casse, il y a de nouveau de nombreuses possibilit�s d'afficher plusieurs caract�res (par exemple, il y a 83 060 640 possibilit�s diff�rentes d'afficher AEIOU).

Par exemple, si un attaquant appelle � http://victim/../../winnt/system32/cmd.exe �, IIS va g�n�rer une erreur. Cependant, en rempla�ant "../.." par son �quivalent en UTF-8, aucune erreur n'est g�n�r�e : � http://victim/..%C1%9C../winnt/system32/cmd.exe �. De plus, avec les codes UTF-8 appel�s � UN-escape �, il est possible d'ouvrir des pages auxquelles nous ne devrions pas avoir acc�s. Un NIDS a des difficult�s pour d�tecter ces attaques car ces �v�nements se passent au niveau applicatif (dans ce cas, l'application d'un HIDS serait plus appropri�). Le cryptage en g�n�ral repr�sente un probl�me pour les senseurs - ce fait est fr�quemment exploit� pendant ce temps. Les d�marches de quelques � producteurs d'IDS � montrent clairement les limites des signatures : les signatures d�tect�es disponibles connaissent quelques attaques Unicode mais, apr�s de petites modifications de l'attaque, les signatures deviennent de nouveau inutiles. Seul NetworkICE a d�velopp� avec succ�s des signatures qui d�couvrent ces types d'attaques (Snort et ISS Real Secure ont cependant d�velopp� des signatures qui ont d�tect� seulement les attaques Unicode connues).

R�ponses


Comme expliqu� pr�c�demment, les IDS analysent les activit�s sur le PC et sur le net. Mais � quel point serait utile un IDS s'il ne r�agirait pas et ne nous alerterait pas ? Un IDS serait sans valeur, juste un gaspillage de performance machine. � la base, la � r�ponse � peut �tre diff�renci�e entre R�ponse Active et R�ponse Passive. Nous allons expliquer les diff�rences dans une section sp�cifique.
Le lecteur int�ress� peut se r�ferrer � l' OPSEC.
S�curis�s par Check Point, les appareils sont des solutions de s�curit� qui
int�grent la technologie Check Point VPN-1/FireWall-1 sur les plates-formes
mat�rielles de nos partenaires.


Ce syst�me permet l'int�gration de syst�mes existants avec FireWall-1. Un avantage suppl�mentaire est sa reconnaissance mondiale (il a environ 300 partenaires). Si vous d�couvrez une attaque, vous pouvez bloquer l'adresse IP de l'attaquant (seulement comme une option de r�ponse possible)... Si vous �tes int�ress�s dans OPSEC, lisez la section � Deployment Platforms �, vous y trouverez aussi les conditions pour � joindre � le syst�me (pour devenir un partenaire).

R�ponse Active

Une R�ponse Active signifie une r�action automatique si l'IDS d�tecte une attaque (ou un essai d'attaque). En fonction de la s�v�rit� de l'attaque, la plupart des IDS offrent plusieurs options de r�ponse.
1) Agir contre l'intrus potentiel. 2) � Simplement � collecter des donn�es compl�mentaires (sur l'intrus et son attaque, ses implications). 3) Changer la configuration
La premi�re r�action possible serait le d�clenchement des �tapes contre l'intrus. Cela peut inclure une vari�t� d'�tapes comme bloquer l'acc�s de la personne ou d�clencher des attaques contre l'intrus. Comme nous l'expliquions en relation avec les pots-de-miel, il est souvent facile de diriger les attaques contre l'intrus mais c'est aussi ill�gal. Dans ce contexte, l'effet � Tierce Partie � se montre souvent. Mais qu'est-ce que cet effet ? Expliqu� graphiquement, l'effet Tierce Partie ressemble � ceci : 
 ----------           ------------           --------
 | Intrus | --------> | Innocent | --------> | VOUS |
 ----------           ------------           --------

L'effet de Tierce Partie signifie simplement qu'une personne innocente (ou un r�seau innocent) est attaqu� avec succ�s par l'intrus et, plus tard, l'intrus utilise ce r�seau pour attaquer le n�tre (et probablement d'autres r�seaux �galement). Mais quel est le probl�me ? Le probl�me est que notre r�seau va cat�goriser le r�seau � innocent � comme l'attaquant et contre-attaquer en cons�quence � innocent � en n�gligeant � l'intrus � ayant envahi ce r�seau pour lancer une attaque contre nous. R�sultant de notre attaque (sous la fausse supposition que nous n'attaquerons que les intrus), des dommages ind�termin�s peuvent �tre caus�s � � l'innocent �. Et si � l'intrus � a �t� assez intelligent pour cacher ses traces, nous serons consid�r�s comme responsables pour ces dommages, pas � l'intrus �.

La seconde option (collecter des informations compl�mentaires) est moins probl�matique. Qu'une attaque ou une intrusion potentielle soit d�tect�e et � seulement � des informations compl�mentaires sur l'utilisateur et son attaque seront collect�es. Si un IDS d�termine qu'un utilisateur sp�cifique a �tendu avec succ�s ses privil�ges (ou qu'un autre type d'attaque s'est pass�), l'observation de cet utilisateur peut �tre �tendue, par exemple, en enregistrant ses commandes (si cela n'�tait pas activ� auparavant), o� cet utilisateur s'introduit, combien de temps il reste, quand s'introduit-il, quand et � quelle fr�quence s'introduit-il dans les jours qui suivent, essaie-t-il de transf�rer (FTP) des binaires sp�cifiques... De cette mani�re, un profil de l'attaquant est cr��. Avec cela, nous avons l'avantage de pouvoir analyser les journaux (log) en d�tail, fermer les �chappatoires (loopholes) possibles et cela nous permettra aussi de prendre des mesures l�gales.
Comme troisi�me option, je vois la modification du syst�me, le pare-feu, etc. Si l'attaquant utilise des adresses IP sp�cifiques, nous pouvons emp�cher cet utilisateur de se connecter au r�seau avec ces adresses IP. Bien s�r, nous pouvons bloquer et noter les autres demandes d'acc�s d'origines suspectes. Dans certains cas sp�cifiques, nous pouvons simplement bloquer tout acc�s au r�seau lui-m�me (ou toute requ�te � des ports sp�cifiques, � partir d'interfaces r�seau sp�cifiques...). Une autre possibilit� de R�ponse Active est d'arr�ter une connection TCP (connu aussi sous le nom de � TCP kill �). Pour d�connecter un autre ordinateur, nous envoyons un RST (drapeau Reset) : cela � tue � la session. Normalement, RST est envoy� lorsqu'une erreur s'est produite dans la connection... dans ce cas, il peut �tre utilis� comme IDS (comme dans ISS RealSecure) pour terminer la session avec un autre ordinateur (pour MS-Windows NT, il existe un outil avec le m�me nom).

 " tcpkill - tue les connections TCP sur un r�seau LAN
   .......
   tcpkill tue les connections TCP en cours sp�cifi�es (utile pour les
   applications bas�es sur libnids qui requi�rent un TCP complet 3-whs pour la
   cr�ation de TCB). "

C'�tait un extrait de 'man tcpkill' ...
Comme vous pouvez le voir, il y a de r�elles possibilit�s compl�tes de r�agir aux attaques. Lancer une contre-attaque parait attractif mais ne devrait pas �tre effectu�.

R�ponse Passive


En comparaison � la R�ponse Active, la plupart du temps, seuls les avertissements (warnings) sont not�s et ils doivent �tre surveill�s par l'administrateur / l'utilisateur. Voici les options de r�action :

1) avertissements, conseils... notation
2) g�n�ration de rapports qui surveillent les syst�mes pour un temps d�fini et produisent un compte-rendu.

Presque tout IDS est capable de g�n�rer des avertissements ou d'envoyer des indications � l'utilisateur / au navigateur. Si, par exemple, on essaie d'effacer un fichier syst�me important, de d�marrer des services sp�cifiques (ceux dont l'usage devrait �tre interdit)... un avertissement annon�ant l'incident peut �tre g�n�r�, indiquant �galement qui y a pris part et � quel moment. Entretemps, de plus en plus d'IDS ont l'option de g�n�rer ces rapports. Le statut d'un syst�me peut �tre surveill� sur une grande p�riode de temps, les activit�s peuvent �tre not�es et un rapport de statut peut �tre g�n�r�. Presque tous les IDS fournissent l'option de r�ponse passive.

Filtrer

Les filtres sont utilis�s pour identifier les attaques par leur signature. Cette signature est indirectement reli�e aux signatures mentionn�es pr�c�demment ; ici, nous cherchons les caract�ristiques typiques d'une attaque (comme ports destination/source, IPs destination/source...). Dans une autre partie de cette section, je vais introduire et expliquer, au moyen de N-code, quelques exemples de filtres pour des attaques connues. � la fin de cet article, vous trouverez une page (le guide des utilisateurs avanc�s) qui offre les caract�ristiques de N-code, si vous n'�tes pas familier avec lui.
land : 
# Ceci est un exemple sur la mani�re de d�tecter
# une attaque land en N-code
 filter pptp ip () {
        if(ip.src == ip.dest)
        {
                record system.time,
                        eth.src, ip.src, eth.dst, ip.dest
                to land_recdr;
        }
 }
Puisque des variables inconnues ont �t� utilis�es, voici une courte explication :


Comme vous pouvez le voir, N-code connait aussi l'op�rateur == ; si vous lisez le Guide de l'Utilisateur Avanc�, vous trouverez d'autres similarit�s existantes (avec d'autres langages de haut niveau) comme, par exemple, le fait que N-code connaisse les op�rateurs +, -, * ou des op�rateurs d'assemblage comme >=, != ou ==, comme montr� ci-dessus
Scan Xmas :
Comme vous pourriez vous en souvenir de la section � Types d'Attaques �, dans un Scan Xmas, tous les drapeaux sont d�finis. Ainsi, il devient plausible de v�rifier s'ils sont tous d�finis ou non. Pour cela, nous avons besoin des valeurs des bits d�finis individuellement : 
 Bit                    Valeur
 --------------------------------------
 F-FIN                  1
 S-SYN                  2
 R-RST                  4
 P-PSH                  8
 A-ACK                  16
 U-URG                  32
---------------------------------------
filter xmas ip() { if(tcp.hdr) { $dabyte = byte(ip.blob,13); if(!($dabyte ^ 63)) { record system.time, ip.src,tcp.sport,ip.dest, \ tcp.dport, "UAPRSF" to xmas_recorder; return; } } }
Ici, de nouveau, il y a des variables inconnues. Laissez-moi vous les expliquer :

$dabyte est une variable locale assign�e � l'octet (ip.blob,13). Pour expliquer � l'expression byte �, voici une petite d�monstration de bits de code TCP : 
| Src Port | Dest Port | Seq Number | ACK Number | HDR Length | Flags |\
URG | ACK | PSH | RST | SYN | FIN | Win Size | Chksum | Urg Off | Opt |
Nous r�alisons pourquoi 13 octets dans bytes() ont �t� sp�cifi�s : parce que 13 octets sont suffisant pour contenir les drapeaux. Avant d'�tre capable de comprendre comment l'octet fonctionne, voici d'abord quelques remarques sur blob. Si vous vous r�f�rez au Chapitre 3 du Guide de l'Utilisateur Avanc�, blob est une � s�quence de taille arbitraire d'octets �. Un 'octet' retourne un octet de l'offset sp�cifi� d'un blob ; la syntaxe courante ressemble � ceci : byte (str blob_to_search, int offset). Le premier argument sp�cifie le blob dans lequel il faut chercher (ci-dessus : ip.blob), le second argument d�fini l'offset (dans 'blob_to_search') de l'octet que l'on recherche. Avec 'if(!($dabyte ^ 63))', on v�rifie si tous les drapeaux sont d�finis ; cela doit donner 63 si on additionne les valeurs de tous les drapeaux (32+16+8+4+2+1). Si quelqu'un souhaite savoir, avec ^, un XOR bit � bit est ex�cut�

Outre les options mentionn�es, N-code offre beaucoup de possibilit�s compl�tes. Il est par exemple possible de trouver :


Vous pourrez trouver des informations additionnelles sur N-code dans le Guide de l'Utilisateur Avanc� � : http://www.cs.columbia.edu/ids/HAUNT/doc/nfr-4.0/advanced/advanced- htmlTOC.html

Dans les version futures de ces articles, un bon nombre de filtres seront d�crits ; v�rifiez s'il n'y a pas de nouvelles versions � intervalles r�guliers ;-)

Standards


Dans cette section, je vais vous pr�senter divers � standards � tout comme des listes / accords qui sont partag�s par de nombreux outils � experts �.

CVE

CVE est l'abbr�viation de � Common Vulnerabilities and Exposures � (Exposition et Vuln�rabilit�s courantes) qui n'est rien de plus qu'une liste d'expositions et de vuln�rabilit�s. A premi�re vue, cela semble rigolo mais il peut devenir assez pratique plus tard. Diff�rents outils utilisent diff�rents termes pour les vuln�rabilit�s d�tect�es ; en utilisant CVE, une description uniforme des diff�rentes vuln�rabilit�s/expositions peut �tre utilis�e. Ainsi, il n'est plus n�cessaire d'utiliser le m�me outil que d'autres utilisateurs.

CVE fournit un nom pour une vuln�rabilit�/exposition sp�cifique et une description uniforme (et standardis�e), emp�chant les incompr�hensions entre les utilisateurs de diff�rents syst�mes. CVE d�finit une vuln�rabilit� comme � des probl�mes qui sont normalement regard�s comme des vuln�rabilit�s dans le contexte de toutes les r�gles de s�curit�s raisonnables � et une exposition comme � des probl�mes qui sont seulement des violations de quelques r�gles de s�curit� raisonnables �. Dans CVE, la diff�renciation entre vuln�rabilit� et exposition est fondamentale. Voici des exemples de vuln�rabilit�s : phf, les fichiers de mots de passe o� tout le monde peut �crire... Voici des exemples d'expositions : utilisation de programme pouvant �tre attaqu�s par force brute ou l'utilisation de services qui sont attaqu�s, en g�n�ral. Par d�finition et avec ces exemples, il devrait �tre possible de diff�rencier les vuln�rabilit�s et les expositions (dans CVE). La diff�rence fondamentale pourrait �tre la capacit� de l'attaquant d'appliquer des commandes comme un utilisateur diff�rent ou pouvoir lire/�crire dans des fichiers alors que cela ne devrait pas �tre possible (� cause des permissions du fichier). Par contre, les exposition permettent � un utilisateur d'extraire des informations suppl�mentaires � propos du syst�me (et son statut), ces activit�s tournant en t�che de fond... Les expositions appara�ssent suite � des r�glages de s�curit� fautifs qui peuvent �tre � r�par�s �. Les vuln�rabilit�s peuvent �tre comprises comme des trous de s�curit� dans le syst�me de s�curit� � normal � (qui devrait inclure la possibilit� de minimiser la menace d'attaquants potentiels gr�ce � la v�rification de permission). Cependant, cette liste doit rester � jour et chacune des vuln�rabilit�s ou expositions n'est pas imm�diatement � accept�e �. Apr�s qu'une vuln�rabilit� / exposition est d�tect�e, elle re�oit un � num�ro de candidat � tout d'abord (cela se passe � travers le CNA : Candidate Numbering Authority). De plus, il sera post� sur le Forum (par l'Editeur du CVE Editor) et discut� (est-ce que cette vuln�rabilit�/exposition doit �tre accept�e). Si le Forum d�cide de ne pas accepter le candidat (pour le moment), la raison de ce refus sera post�e sur le site web. Si le candidat est accept�, il sera ajout� � la liste (et devient une partie officielle de CVE). Maintenant, il devrait �tre clair que chaque vuln�rabilit� (potentielle) re�oit initialement un � num�ro de candidat � puisqu'elle doit �tre discut�e pour voir si elle est accept�e ou pas. La vuln�rabilit� re�oit le 'num�ro de candidat' pour la diff�rencier des entr�es officielles dans la liste. Chaque candidat poss�de 3 champs de base (ils � l'identifient �) :


Dans ce contexte, le num�ro est le nom r�el du candidat, compos� de � l'ann�e d'apparition �, un nombre suppl�mentaire r�v�lant quel candidat il repr�sente dans la s�quence d'une ann�e : 
        CAN-Ann�e-s�quence candidat de l'ann�e

Comme indiqu� pr�c�demment, un candidat accept� est ajout� � la liste. Il en r�sulte que la s�quence 'CAN-ANNEE-Num�ro de candidat' devient 'CVE-Ann�e-Num�ro de candidat'. Un exemple : 'CAN-2001-0078' devient 'CVE-2001-0078' dans la liste.

C'est tout ; pour plus d'information, consultez la page web officielle de CVE.

Exemples


Dans cette derni�re partie, quelques IDS vont �tre pr�sent�s.

Snort

Puisque Snort est tr�s bien connu et qu'il offre beaucoup d'options, je vais le d�crire avec plus de d�tails que les autres IDS pris en exemple. Fondamentalement, Snort peut �tre dans un de ces trois modes : Sniffer (Renifleur), Packet Logger (Log de paquets) et Network Intrusion Detection System (Syst�me de D�tection d'Intrusion de R�seau). Dans le mode Sniffer, Snort g�n�re des paquets sur la console. Dans le mode Packet Logger, il les note sur le disque dur. Et le mode Network Intrusion Detection permet d'analyser les paquets. Je vais me concentrer principalement sur le dernier mode mais voici une courte introduction aux modes Sniffer et Packer Logger :
En mode Sniffer, une vari�t� d'information sur le paquet peut �tre lue, comme l'en-t�te TCP/IP : 
 [Socma]$ ./snort -v

En sortie, nous aurons seulement l'en-t�te IP/TCP/ICMP/UDP. Il y a de nombreuses options, seules quelques unes seront mentionn�es ici. 
 -d = va livrer le paquet de donn�es
 -e = montre le Data Link Layer

Mode Packet Logger :
A la diff�rence du mode Sniffer, le mode Packet Logger peut �crire les paquets sur le disque dur. Nous devons seulement assigner un r�pertoire dans lequel Snort peut les �crire et il va automatiquement passer en mode Packet Logger : 
 #le repertoiredelogging doit exister :
 [Socma]$ ./snort -dev -l ./repertoiredelogging
Lorsqu'on entre � -l �, Snort r�cup�re parfois l'adresse de l'ordinateur distant et l'utilise comme nom de r�pertoire (dans lequel se trouvent les logs), d'autres fois, il prend l'adresse de l'h�te local. Pour noter le r�seau maison (home network), nous devons sp�cifier ce r�seau dans la ligne de commande : 
[Socma]$ ./snort -dev -l ./repertoiredelogging -h 192.168.1.0./24
Une autre possibilit� est de noter le log en format TCP-DUMP : 
 [Socma]$ ./snort -l ./repertoiredelogging -b
Maintenant, le paquet tout entier sera �crit, pas seulement des sections sp�cifiques ; cela �limine la n�cessit� de sp�cifier des commandes additionnelles. Il est possible d'utiliser des programmes comme tcpdump pour traduire les fichiers en texte ASCII mais Snort peut faire cela aussi : 
 [Socma]$ ./snort -dv -r paquetaverifier.log
Mode Network Intrusion Detection : Pour basculer en mode NIDS, nous pouvons utiliser une commande comme celle-ci : 
 [Socma]$ ./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf
Dans ce cas, snort.conf est le fichier de configuration. Il est utilis� pour faire savoir � Snort o� il peut trouver ses � r�gles � pour d�terminer s'il y a une attaque ou pas, si la requ�te doit �tre permise... Les r�gles, telles que d�finies dans snort.conf, seront alors appliqu�es au paquet pour l'analyser. Si aucun r�pertoire de sortie sp�cifique n'a �t� �tabli, le r�pertoire par d�faut /var/log/snort est utilis�. Le r�sultat de sortie de Snort d�pend du mode d'alerte - bas� sur ceci, l'information est disponible l�g�rement plus t�t ou plus tard. 
 ----------------------------------------------------------------
 |      Mode    |  Comment/Ce qui est affich�                   |
 ----------------------------------------------------------------
 | -A fast      |  Temps, IPs/ports Source et Destination,      |
 |              |  le Message d'Alerte                          |
-----------------------------------------------------------------
 | -A full      |  Param�trage par D�faut                       |
-----------------------------------------------------------------
 | -A unsock    |  Envoi l'avertissement vers un socket         |
 |              |  UNIX                                         |
-----------------------------------------------------------------
 | -A none      |  Arr�te les alertes                           |
-----------------------------------------------------------------

Comme nous l'avons vu, avec l'option -b, nous pouvons noter ce qui se passe en mode binaire et avec l'option -N, la notation de paquets est compl�tement cess�e. Mais ce n'est pas la limite ; par exemple, Snort est capable d'envoyer des messages � syslog. Le r�glage par d�faut pour cela est LOG_AUTHPRIV et LOG_ALERT. Pour envoyer des messages � syslog, nous devons seulement entrer � -s � (des exemples suivent). En outre, nous avons la possibilit� d'envoyer des messages au client smb ou un avertissement pop-up Windows � un ordinateur sous MS-Windows. Pour utiliser cette � fonctionnalit� �, nous devons entrer � -enable-smbalerts � lors de la configuration de Snort. 
 [Socma]$ ./snort -c snort.conf -b -M MASTATIONWINDOWS
Voici un exemple d'application des modes d'alerte : 
 [Socma]$ ./snort -b -A fast -c snort.conf
Outre les options d�crites, il en existe d'autres comme celles-ci : 
 -D = d�marre Snort en mode daemon
 -u utilisateursnort = d�marre Snort avec l'UID � utilisateursnort �
 -g groupesnort = d�marre Snort avec le GID � groupesnort �
 -d = note aussi les donn�es de la couche d'applications


Snort offre de nombreuses options ; si vous rencontrez un probl�me, entrez juste � snort -h � ou regardez dans les mailing lists si votre probl�me �tait apparu autre part. La section suivante couvre les r�gles de Snort ; si vous n'�tes pas int�ress�s par la compr�hension des r�gles existantes ou par l'�criture de vos propres r�gles, vous pouvez passer cette section. Comme je l'indiquais � la fin de cette partie (sur Snort), vous pouvez t�l�charger le Manuel des Utilisateurs de Snort sur www.snort.org : c'est notre vraie source.

Les r�gles de Snort :
Pour une meilleure compr�hension de Snort, il est obligatoire de conna�tre les R�gles de Snort. Snort utilise parfois des variables sp�cifiques qui peuvent �tre d�finies avec l'utilisation de � var � : 
   var: <name> <wert>      var

   MON_REZO [192.168.1.0/24,10.1.1.0/24]
   alert tcp any any -> $MON_REZO any (flags:S;msg: "paquet SYN";)
Il y a d'autres mani�res d'entrer le nom d'une variable : 
$variable = d�finit la variable M�ta
$(variable) = ici, la valeur de la variable � variable � est entr�
$(variable:-default) = si � variable � est d�fini, sa valeur est entr�e ici ; si
"variable" n'est pas d�fini, la valeur � default � est entr�e
$(variable:?msg) = entre la valeur de la variable � variable � ou, si ind�finie,
affiche le message � msg �

Si vous avez �t� confront� � la programmation shell auparavant, ce qui suit ne devrait pas vous �tre �tranger :
 [Socma]$ shelltest=we
 [Socma]$ echo hello $shelltestlt
 hello
 [Socma]$ echo hello ${shelltest}lt
 hello world
L'application de $(variable) dans Snort et de ${variable} dans le shell est identique. Il y a d'autres �quivalents (ou termes semblables) dans la programmation du shell : 
 [Socma]$ shelltest = bash
 [Socma]$ echo ${shelltest:-nobash}
 bash
 [Socma]$ echo ${notdefined:-nobash}
 nobash
L'application du terme � $(variable:-default) � diff�re seulement dans le fait que le shell utilise { et } � la place de ( et ). Le dernier terme existe aussi dans le shell : 
 [Socma]$ shelltest = bash
 [Socma]$ echo ${shelltest:?"then csh"}
 bash
 [Socma]$ echo ${variablenondefinie:?"pas definie ou nulle"}
 pas definie ou nulle

Le but de cette courte excursion �tait � d'associer les connaissances � : j'ai �t� capable de m�moriser la syntaxe de Snort plus vite en me r�ferrant mentalement aux termes du shell dont je me rappellais.
De nombreuses options de la ligne de commande peuvent �tre d�finies dans les fichiers de configuration. Pour cela, � config � est utilis� :
        config <directive> [: <valeur> ]

Les � directives � les plus importantes sont :
alertfile = change le fichier dans lequel les alertes sont enregistr�es
daemon = d�marre le processus comme daemon ( -D)
reference_net = d�fini le r�seau maison (-h)
logdir = d�finit le r�pertoire pour les logs (-l)
nolog = ferme la cr�ation de logs
set_gid = change le GID (-g)
chroot = chroot� dans le r�pertoire sp�cifi� (-t)
set_uid = d�fini l'UID (-U)


Si, par exemple, vous voulez changer le fichier d'alerte en, par exemple, � meslogs �, vous devez proc�der comme suit : 
        config alertfile : meslogs

Retour aux r�gles actuelles (ici un extrait de r�gles pour le ftp) :
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT overflow";\
flags: A+; content:"|5057 440A 2F69|";\
classtype:attempted-admin; sid:340;rev:1;)

A la base, les r�gles de Snort consistent en deux parties : l'en-t�te de la r�gle et ses options. L'en-t�te de la r�gle nous informe de trois choses :

Dans la r�gle ftp ci-dessus, l'en-t�te est la partie suivante :
 Action       ip source         ip destination
    |              |                |
 alert tcp $EXTERNAL_NET any -> $HOME_NET 21
         |                |               |
        Protocole     de tous ports     Port

Comme vous pouvez le voir, l'en-t�te de la r�gle se termine � la premi�re � ( � et, apr�s ��, les options de la r�gles commencent. Il y a plusieurs actions possibles (� alert � dans ce cas) qui peuvent �tre lanc�es lorsque les r�gles de Snort d�couvrent quelque chose de suspect :

Le second champ (protocole ; tcp ici) sp�cifie quel protocole n�cessite une analyse. Les possibilit�s sont : tcp, udp, icmp et ip (dans le futur, il pourrait en avoir d'autres ... comme ARP, GRE).
En relation avec le champ suivant (ip source), nous trouvons fr�quemment l'op�rateur � ! � (op�rateur de n�gation).
 alert tcp !$REZO_EXTERNE any -> $REZO_MAISON 21

Il r�sulte de cet op�rateur de n�gation que chaque paquet qui n'arrive pas du $REZO_EXTERNE est trac�. Il y a des possibilit� additionnelles pour entrer un nombre d'adresses IP (c'est-�-dire une liste d'adresses IP). Les adresses doivent �tre s�par�es par une virgule et entour�es par [ ].
        alert tcp ![addresse ip,addresse ip] any -> ....

Une autre alternative est l'utilisation de � any � qui inclut toutes les adresses IP.
        log tcp any any -> ...

La derni�re partie de l'en-t�te de la r�gle est la sp�cification des ports, ftp dans notre exemple. Il n'est pas seulement possible de surveiller un port sp�cifique mais �galement une gamme de ports (plusieurs ports). Voici les options :
 :numeroport                     -> tous les ports plus petits ou �gaux au numeroport
 numeroport:                     -> tous les ports plus grands ou �gaux au numeroport
 debutnumeroport:finnumeroport   -> tous les ports entre debutnumeroport � 
                                   finnumeroport (ceux-ci inclus)
Bien s�r, il est possible d'utiliser les op�rateurs de n�gations, avec la cons�quence que tous les ports seront surveill�s � l'exception de celui entr�, par exemple. 
       !:21            -> tous les ports qui ne sont pas plus petits ou �gal � 21
Quelque chose qui n'a pas �t� expliqu� mais qui a �t� utilis� tout le temps est l'op�rateur de direction � -> �. 
                "source" -> "destination"
Cependant, il existe une autre variante <> : 
                 "source" <> "destination"
Cela signifie que Snort va rechercher la source aussi bien que la destination, pour l'adresse.
Comme je l'ai mentionn�, il y a l'�tape � activate � : elle g�n�re une alerte et retourne vers une autre r�gle dynamique de Snort.
Si une r�gle sp�cifique a compl�t� ses actions, elle peut activer une autre r�gle. A la base, la diff�rence entre les r�gles normales et les � r�gles activ�es � est le fait que seulement un champ sp�cifique doit �tre sp�cifi� : "activates". Les r�gles dynamiques, d'autre part, fonctionnent comme des logs (voir ci-dessus) ; seule diff�rence : � activate_by � doit �tre entr�. Un champ suppl�mentaire doit encore �tre entr� : � count �. Apr�s que la � r�gle activ�e � ait fait son boulot, la r�gle dynamique est �voqu�e mais seulement pour � count � paquets (ce qui signifie � pour 40 paquets � lorsque count = 40).
activate tcp !$REZO_MAISON any -> $REZO_MAISON 143 (flags : PA;  \
  content : "|E8C0FFFFFF|\bin|;activates : 1; msg : "IMAP buf!";)
dynamic tcp !$REZO_MAISON any -> $REZO_MAISON 143 (activated_by : 1; \
  count : 50;)

Quelques unes des options, comme les options � une r�gle, n'ont pas encore �t� pr�sent�es. Je vais les expliquer maintenant mais cela prendra plus de sens pour vous plus tard. Veuillez noter que les champs activates et activated_by (r�gle dynamique) dans notre exemple plus haut. La premi�re r�gle invoque une r�gle dynamique apr�s qu'elle ait fini son travail ; cela est �galement indiqu� par l'assertion � activated_by = 1 � de la r�gle dynamique.

Maintenant, voici la seconde partie des r�gles de Snort : les options � la r�gle. Utilisons encore une fois la premi�re r�gle (ftp) :

alert tcp $REZO_EXTERNE any -> $REZO_MAISON 21 (msg:"FTP EXPLOIT
overflow"; flags: A+;\
content:"|5057 440A 2F69|";classtype:attempted-admin;\
sid:340; rev:1;)


L'option de r�gle, dans ce cas (l'en-t�te de r�gle s'arr�te � la premi�re � ) �) est :

 (msg:"FTP EXPLOIT overflow";\
flags: A+; content:"|5057 440A 2F69|";\
classtype:attempted-admin; sid:340; rev:1;)


Il y a 34 mots cl�s, je vais limiter mes explications aux plus importantes et/ou aux plus usit�es. Pour ceux qui souhaitent avoir un aper�u de tous les mots cl�s possibles, veuillez jeter un oeil dans le Manuel des Utilisateurs de Snort.

msg - affiche les messages d'alerte et les trace dans le Packet Logger Mode
logto - trace les paquets dans un fichier sp�cifique
dsize - compare la taille du paquet avec une valeur diff�rente v
flags - v�rifie les drapeaux TCP pour des valeurs sp�cifiques
content - recherche un motif/une cha�ne sp�cifique dans un paquet
content-list - recherche un motif/une cha�ne sp�cifique dans un paquet
nocase - la casse (majuscule et minuscule) est n�glig�e dans la cha�ne recherch�e
react - r�ponse active (bloque les sites web)
sid - ID de r�gle Snort
classtype - trie les attaques potentielles dans des groupes
priority - d�fini la sensibilit�
Jusqu'ici, tout va bien mais comment fonctionne les r�gles individuelles ?
msg:
Nous trouvons souvent � msg � lorsque nous parcourons les r�gles. Cette option est responsable de la g�n�ration des alertes et leur tra�age.
    msg:"<texte>";
Le "<texte>" est le message qui est �crit/affich� dans le fichier d'alerte (alertfile)
logto:
Chaque paquet pour lequel la r�gle est d'application est trac� dans un fichier sp�cifique 
    logto: "<nomdefichier>";
Dans ce cas, "<nomdefichier>" est le fichier dans lequel les fichiers applicables sont trac�s.
dsize:
Ceci est utilis� pour sp�cifier la taille d'un paquet. Si nous connaissons la taille du tampon d'un service sp�cifique, cette option peut �tre utilis�e pour se d�fendre contre les d�bordement de tampon possible. Compar� � � content �, elle est un peu plus rapide ; c'est pourquoi elle est utilis�e plus fr�quemment pour tester les d�bordements de tampon. 
     dsize: [>|<] <taille>;
Les deux op�rateur optionnels > et < indiquent que la taille du paquet devrait �tre respectivement plus grande et plus petite que la valeur sp�cifi�e 
    value flags:
Cela v�rifie quels sont les drapeaux d�finis. � pr�sent, 9 drapeaux sont disponibles dans Snort : 
 F      FIN
 S      SYN
 R      RST
 P      PSH
 A      ACK
 U      URG
 2      Bit 2 assign�
 1      Bit 1 assign�
 0      pas de drapeau TCP d�fini

Il existe des op�rateurs logiques suppl�mentaires pour sp�cifer les crit�res de test des drapeaux :
 + ALL flag     = Marche pour tous les drapeaux (flag) sp�cifi�s (aussi bien
 que les autres).
 * ANY flag     = Marche pour tous les drapeaux sp�cifi�s.
 ! NOT flag     = Si les drapeaux sp�cifi�s ne sont pas d�finis.

En g�n�ral, le mot cl� � flags � est utilis� comme ceci :
        flags: <valeur_drapeau>;

Les bits r�serv�s peuvent �tre utilis�s pour d�tecter un comportement inhabituel ; par exemple, des essais d'IP stack fingerprinting.
content:
Un des mots cl�s les plus utilis�s (except� � msg �) est � content �. Il peut �tre utilis� pour chercher dans la masse de paquets pour un contenu particulier. Si le contenu sp�cifi� est d�tect�, des �tapes pr�d�finies sont lanc�es contre l'utilisateur. Apr�s la d�tection du contenu dans la charge d'un paquet, le reste des r�gles de Snort va �tre ex�cut�. Sans appliquer � nocase � (voir ci-dessous), la casse sera consid�r�e. Le contenu de la charge devrait �tre fouill�e pour des binaires comme pour du texte. Les donn�es binaires sont plac�es entre || et mont�es comme du byte code. Le byte code montre l'information binaire sous forme de nombres hexad�cimaux. En rapport avec ce mot cl�, l'op�rateur de n�gation (!) peut �tre appliqu�, par exemple, nous pouvons �mettre une alerte si un paquet contient un texte sp�cifique.
        content: [!] "<contenu>";

La d�claration de ! n'est pas obligatoire.
 alert tcp any any -> 192.168.1.0/24 143 \
(content: "|90C8 C0FF FFFF|/bin/sh";\
msg: "IMAP buffer overflow";)

Comme d�montr� dans cette r�gle, les donn�es binaires sont entour�es dans || ; � la suite de quoi, du texte normal peut �tre appliqu�. Regardez la description de � offset � et � depth � dans le Manuel des Utilisateurs de Snort : ils sont fr�quemment utilis� dans ce contexte avec � context �.

content-list:

Ce mot cl� fonctionne de mani�re similaire � � content � avec la diff�rence qu'un nombre de cha�nes (utilis�es pour chercher dans les paquets) peut �tre entr�. Nous entrons les nombres hexad�cimaux, les cha�nes, etc. dans un fichier. Ce fichier, contenant les cha�nes � trouver, sera sp�cifi� dans l'application de � content list �. Nous ne devons pas oublier d'�crire les lignes espac�es verticalement (chaque cha�ne sur une ligne). Par exemple :

        "kinderporno"
        "warez"
        .....

A la suite de quoi, nous pouvons chercher pour le contenu de ce fichier (par application de "content-list: [!] "<filename>" "). Bien s�r, ! est optionnel ; il a le m�me effet que dans � content �.

nocase:
Cette r�gle joue un r�le important dans un contexte avec les mots cl�s � content �. D'habitude, la casse est respect�e ; en utilisant � nocase �, elle est ignor�e :

 alert tcp any any -> 192.168.1.0/24 21 (content: "USER root";\
  nocase; msg: "FTP root user access attempt";)


Sans l'utilisation de � nocase �, seule la cha�ne � USER root � va �tre r�pertori�e ; ici, puisque � nocase � a �t� sp�cifi�, la casse ne sera pas appliqu�e.
Si la recherche d'un contenu sp�cifique (application de � content � ou � content_list �) dans un paquet donne un r�sultat, � react � peut �tre utilis� pour y r�pondre. Comme r�ponse g�n�rale, les pages sp�cifiques demand�es par l'utilisateur seront bloqu�es (pages pornographiques...). En appliquant � Flex Resp �, les connections peuvent �tre coup�es ou des avertissements envoy�s au navigateur. Les options suivantes sont possibles/l�gales :

block - d�connecte et envoie une notification.
warn - envoie un avertissement visible (bient�t disponible)
Ces � arguments de base � peuvent �tre compl�t�s par des arguments additionnels (aussi appel�s � modificateurs additionels �) :

msg - le texte � envoyer (par le mot cl� � msg �) est inclus dans la notification allant �tre envoy�e � l'utilisateur
proxy : <nnumerodeport> - le proxy est utilis� pour envoyer la notification (bient�t disponible) 
        react : <argument de base [, modificateur additionel ]>;

Le mot cl� � react � est ajout� � la fin des options d'une r�gle. Il peut �tre utilis� comme ceci :
 alert tcp any any <> 192.168.1.0/24 80 (content-list: "adults"; \
   msg: "Cette page n'est pas pour les enfants !"; react: block, msg;)
sid:
'sid' ou r�gles d'IDentification de Snort (Snort rules IDentification) est utilis� pour identifier des r�gles � sp�ciales � de Snort. Cela rend l�gal/possible l'utilisation de � plugins de sortie � pour identifier chaque r�gle. Il y a de nombreux groupes sid : 
 < 100 = r�serv� pour un usage futur
 100-1 000 000 = r�gles qui viennent avec Snort
 > 1 000 000 = utilis� pour les r�gles locales
sid-msg.map contient une carte des tags msg pour les sid. C'est utilis� par le post-traitement d'�tranger pour assigner un avertissement � une identit�
sid: <snort rules id>; 
 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80  \
  (msg: "WEB-IIS file permission canonicalization"; uricontent:\
  "/scripts"..%c1%9c../"; flags: A+;nocase;sid: 983;rev:1;)
classtype:
En utilisant � classtype �, nous pouvons trier les attaques dans divers groupes. Dans les r�gles, nous pouvons d�terminer la priorit� d'une attaque potentielle et dans quel groupe elle appartient. Les r�gles qui sont cat�goris�es dans le fichier de configuration seront automatiquement attribu�e � une priorit� standard.

 classtype: <class name>;

Les cat�gories de r�gles doivent �tre d�finies dans classification.config. La syntaxe suivante est utilis�e :
 config classification: <class name>,<class description>,\
       <standard priority>

Dans le prochain paragraphe (la description de � priority �), nous apprendrons quel type de groupes d'attaque existent.
priority:
Ce mot cl� est utilis� pour assigner des � priorit�s de s�curit� � � nos r�gles, signifiant combien endommageante pourrait �tre une attaque potentielle. Plus la priorit� est �lev�e, plus le risque de s�curit� potentiel est dommageable. En rapport avec les � class types � expliqu� plus t�t, les priorit�s sont plus faciles � comprendre :
Class type                    Description                      Priorit�
------------------------------------------------------------------------
 not-suspicious               Tout traffic "non suspect"           0
 unknown                      Traffic inconnu                      1
 bad-unknown                  Traffic potentiellement "mauvais"    2
 attempted-recon              Essai de fuite d'information         3
 successful-recon-limited     Fuite d'information                  4
 successful-recon-largescale  Fuite d'information � grande �chelle 5
 attempted-dos                Essai d'attaque de d�ni de service   6
 successful-dos               Attaque de d�ni de service r�ussie   7
 attempted-user               Essai d'obtention des privil�ges
                                            utilisateur            8
 unsuccessful-user            Essai d'obtention des privil�ges
                                            utilisateur non r�ussi
 successful-user              Essai d'obtention des privil�ges
                                            utilisateur r�ussi
 attempted-admin              Essai d'obtention des privil�ges
                                            administrateur         10
 successful-admin             Essai d'obtention des privil�ges
                                            administrateur r�ussi

Comme mentionn� pr�c�demment, les priorit� plus �lev�es repr�sentent de plus grands risques de s�curit�. Un utilisateur re�evant des privil�ges d'administrateur serait l'attaque la plus s�rieuse.
 alert tcp any any -> any 80 (msg: "WEB-MISC phf Versuch";\
        flags: A+;content: "/cgi-bin/bash";priority:10;)

Le sujet des � r�gles � est certainement assez complexe mais pas si difficile. Etudiez quelques r�gles, cherchez dans le manuel ce qu'elles sont et, apr�s quelques temps, le � monstre des r�gles � prendra sens ;-) Des ressources pour Snort et la documentation peuvent �tre trouv�s sur http://www.snort.org. Vous y trouverez des PDF de valeur (par exemple, le Manuel des Utilisateurs de Snort) qui ont �t� la source principale pour cette description.

LIDS


Depuis le papier (et les sources) de Stealth et le LIDS-Hacking-HOWTO, nous savons que LIDS n'augmente pas r�ellement la s�curit� de l'ordinateur mais il tient plus du � root kit � dans certains cas ;-)

Penchons-nous sur le concept et, ensuite, � la force (imaginaire) de LIDS et ses faiblesses. Il a �t� d�velopp�, � l'origine, pour prot�ger, par exemple, des syst�mes de fichier importants et pour cacher des processus sp�cifiques � l'utilisateur. De plus, il n'est pas autoris� � simplement lier des modules : les modules n�cessaires seront li�s avec le d�marrage du syst�me. Pr�c�demment, j'ai mentionn� le LIDS-Hacking-HOWTO et les papiers de Stealth, tous deux expliquant le travail et les faiblesses de LIDS. Je vais me limiter aux fonctionnalit�s les plus importantes. Vous trouverez un lien vers ces deux textes � la fin de cette section.

Le travail principal de LIDS est la protection du syst�me de fichier. Pour �tre capable de les prot�ger, les fichiers/r�pertoires importants sont tri�s en groupes :


Pour une protection � r�elle �, quelques appels syst�me sont manipul�s pour �tre s�r que les protections sont maintenues (par exemple : sys_open(), sys_mknod(), ...).
De plus, LIDS emp�che des processus sp�cifiques d'�tre tu�s (ou de devenir invisibles). Le but de cette proc�dure est d'emp�cher l'attaquant de voir des processus sp�cifiques qui le tracerait. Un appel de � ps -ax � ne devrait pas non plus r�v�ler nos processus. Pour v�ritablement cacher le processus, il est marqu� comme � PF_HIDDEN �. Dans le cas o� ps travaille pour g�n�rer l'information sur les processus, il va �tre emp�ch� de le faire sur les processus qui sont marqu�s � PF_HIDDEN �. Cela, en soi, n'est pas suffisant pour cacher de mani�re s�re un processus parce qu'il a toujours temporairement une entr�e dans le syst�me de fichier proc (/proc). En cons�quence, LIDS manipule �galement cette fonction pour emp�cher le processus de se montrer dans le r�pertoire /proc. A part cela, il y a la possibilit� de restreindre les privil�ges d'un processus avec capacit�s. Si, par exemple, CAP_ROOT est d�fini � 0, le processus est emp�ch� d'utiliser chroot (voir /usr/src/linux/include/linux/capatibilites.h).
De plus, LIDS a la possibilit� de faire tourner une des deux options de s�curit� : � security � ou � none_security �. Pour d�finir la diff�rence entre � security � et � none_security �, la variable globale � lids_load � est utilis�e. Sa valeur par d�faut est � 1 �, ce qui signifie que LIDS tourne en mode � s�curit� � (c'est-�-dire que les restrictions sont d'application). Si � security=0 � est d�fini au d�marrage (invite LILO), � none_security � est activ�. Il en r�sulte que toutes les v�rifications de s�curit�, toutes les restrictions... sont d�sactiv�es. Avec � lids_load=0 �, l'ordinateur fonctionne comme si LIDS n'�tait pas install�. Une autre possibilit� de changer les options de s�curit� est l'application en ligne de � lidsadm -S � (pour cela, un mot de passe doit �tre fourni).

LIDS offre �galement la possibilit� de prot�ger les r�gles de pare-feu en activant CONFIG_LIDS_ALLOW_CHANGE_ROUTES et d�sactivant CAP_NET_ADMIN. Si quelqu'un veut modifier les r�gles du pare-feu, CAP_NET_ADMIN doit �tre activ� pour emp�cher n'importe de changer les r�gles. En plus de cela, Sniffer peut �tre d�sactiv� et un scanner de port peut �tre int�gr� dans le noyau.


LIDS offre aussi plusieurs � options de r�ponse � (voyez la section sur la r�ponse) par exemple, pour envoyer des notifications avec un pager, par SMS (texto), � l'administrateur.

En g�n�ral, il y a de nombreuses options ; Stealth explique, dans son papier, comment abuser LIDS : http://www.securitybugware.org/Linux/4997.html. Le LIDS Howto peut �tre trouv� sur : http://www.lids.org/lids-howto/lids-hacking-howto.html.

COLOID


COLOID est l'acronyme de � Collection of LKMs for Intrusion Detection � (collection de LKMs pour la d�tection d'intrusion) et il a �t� cr�� par moi-m�me, il y a quelques temps.
Depuis qu'on a appris que des parties du projet ne fonctionnaient pas bien, le projet a �t� temporairement arr�t�. Cependant, je voudrais m'�tendre un peu sur les fonctionnalit�s pr�vues initialement : avec le premier module (prev_exec), nous voulions - entre autres - emp�cher temporairement l'ex�cution de binaires sp�cifiques � des moments d�finis (dans mes sources, j'utilisait le compilateur GNU GCC). Il est d�fini dans les sources quand une ex�cution doit �tre emp�ch�e (le temps peut �tre sp�cifi� en minutes). Si un utilisateur veut ex�cuter GCC � ce moment, il sera bloqu� : GCC ne va pas s'ex�cuter. Si un utilisateur veut ex�cuter GCC � un moment � autoris� �, les arguments vont �tre v�rifi�s et une recherche pour les fichiers .c prend place. La raison de cette proc�dure est la recherche, dans les sources (ici, quelqu'un veut compiler), des � fonctions dangereuses �. Par d�faut, il y avait � scanf � et � strcpy �, etc. ; il est possible d'ajouter plus de fonctions. Comme je l'ai indiqu� plus t�t, le LKM cherche dans le code source ; s'il d�tecte une des fonctions, l'ex�cution de GCC est interdite. De plus, un fichier de log est �crit et un � beep � est produit.


Jusqu'ici, le module fonctionnait mais le concept n'�tait pas assez g�n�ral et pouvait facilement �tre contourn�.

Le second module �tait 'anom_detection' qui utilisait la D�tection d'Anomalie mentionn�e auparavant. En fait, deux LKM appartenaient � cette section :
1) Anomaly_Detection.c qui g�n�re la base de donn�es des activit�s normales de l'utilisateur
et
2) Misuse_Detect.c qui v�rifie si le comportement d'un utilisateur s'�carte de la normale (d�crite dans la base de donn�es) en utilisant cette base de donn�es comme rep�re.

Le plan �tait de laisser le LKM v�rifier les crit�res suivants :

A quelle fr�quence l'utilisateur ex�cute-t-il les commandes suivantes :

Quand l'utilisateur a-t-il ex�cut� les commandes suivantes :

Ou quand l'utilisateur a d�marr� normalement le PC et quand a-t-il lanc� un shutdown.
Autre :
Combien de fois a-t-il ouvert (essay� d'ouvrir) les fichiers suivants :


Combien de fois ex�cute-t-il des programmes avec le bit SUID d�fini ?
Nous devons faire attention aux fichiers � surveiller (combien de fois l'utilisateur l'ouvre-t-il). Si nous choisissons trop de fichiers, la performance du PC en prendra un coup et un travail raisonnable et d�cent ne sera plus possible.

Il existait d'autres LKM plus petits sans toutes les sources ; les sources des deux modules mentionn�s ci-dessus sont disponibles sur ma page web. Peut-�tre que quelqu'un fera quelque chose de cela, un jour, ...


Le mot de la fin

Si quelqu'un a plus d'id�es pour le contenu de cet article, s'il vous pla�t, envoyez-moi une note � Socma(Q)gmx.net. Pour les stimulations, louanges, critiques, ... suppl�mentaire, envoyez-moi �galement un e-mail
R�f�rences (outre celles mentionn�es dans le texte) :
  1. http://online.securityfocus.com/infocus/1524
  2. http://online.securityfocus.com/infocus/1534
  3. http://online.securityfocus.com/infocus/1544
  4. http://online.securityfocus.com/infocus/1232
  5. http://www.entercept.com/products/entercept/ whitepapers/downloads/systemcall.pdf
  6. http://www.computec.ch/dokumente/intrusion_detection/ angriffsmoeglichkeiten_auf_okenas_stormwatch/ angriffsmoeglichkeiten_auf_okenas_stormwatch.doc