Le seuil de latence des règles mesure le temps écoulé, pas seulement le temps de traitement, afin de refléter plus précisément
le temps réel nécessaire à la règle pour traiter un paquet. Cependant, le seuil de latence est une implémentation logicielle
de la latence qui n’applique pas un calendrier strict.
Le compromis pour les avantages en matière de performance et de latence dérivés du seuil de latence est que les paquets non
inspectés pourraient contenir des attaques. Une minuterie mesure le temps de traitement chaque fois qu'un paquet est traité
selon un groupe de règles. Chaque fois que le temps de traitement de la règle dépasse un seuil de latence de règle spécifié,
le système incrémente un compteur. Si le nombre de dépassements de seuil consécutifs atteint un nombre déterminé, le système
effectue les actions suivantes :
-
suspend les règles pendant la période spécifiée
-
déclenche un événement indiquant que les règles ont été suspendues
-
réactive les règles à l’expiration de la suspension.
-
déclenche un événement indiquant que les règles ont été réactivées
Le système remet le compteur à zéro lorsque le groupe de règles a été suspendu ou lorsque les violations aux règles ne sont
pas consécutives. Autoriser certaines violations consécutives avant de suspendre les règles vous permet d’ignorer des violations
occasionnelles de règles qui pourraient avoir un impact négligeable sur les performances et de vous concentrer sur l’impact
plus important des règles qui dépassent à plusieurs reprises le seuil de latence des règles.
L'exemple suivant montre cinq temps de traitement de règle consécutifs qui n'entraînent pas la suspension de règle.
Dans l'exemple ci-dessus, le temps requis pour traiter chacun des trois premiers paquets dépasse le seuil de latence de la
règle de 1000 microsecondes, et le compteur de violations augmente à chaque violation. Le traitement du quatrième paquet ne
dépasse pas le seuil et le compteur des violations est réinitialisé à zéro. Le sixième paquet viole le seuil et le compteur
de violations redémarre à un.
L’exemple suivant montre cinq temps de traitement de règle consécutifs qui entraînent une suspension de règle.
Dans le deuxième exemple, le temps nécessaire pour traiter chacun des cinq paquets enfreint le seuil de latence de la règle
de 1 000 microsecondes. Le groupe de règles est suspendu, car le temps de traitement de la règle de 1100 microsecondes pour
chaque paquet dépasse le seuil de 1000 microsecondes pour les cinq violations consécutives spécifiées. Les paquets suivants,
représentés dans la figure par les paquets 6 à n, ne sont pas examinés en fonction des règles de suspension avant l’expiration
de la suspension. Si plus de paquets se produisent après la réactivation des règles, le compteur de violations recommence
à zéro.
Le seuil de latence des règles n’a aucun effet sur les incidents d'intrusion déclenchés par les règles qui traitent le paquet.
Une règle déclenche un événement pour toute intrusion détectée dans le paquet, que le temps de traitement de la règle dépasse
ou non le seuil. Si la règle qui détecte l’intrusion est une règle de suppression dans un déploiement en ligne, le paquet
est abandonné. Lorsqu’une règle de suppression détecte une intrusion dans un paquet qui entraîne la suspension de la règle,
la règle de suppression déclenche un incident d'intrusion, le paquet est abandonné et cette règle ainsi que toutes les règles
connexes sont suspendues.
Remarque
|
Les paquets ne sont pas évalués par rapport aux règles suspendues. Une règle suspendue qui aurait déclenché un événement ne
peut pas déclencher cet événement et, pour les règles de suppression, ne peut pas abandonner le paquet.
|
Le seuil de latence des règles peut améliorer les performances du système dans les déploiements passifs et en ligne, et peut
réduire la latence dans les déploiements en ligne, en suspendant les règles qui prennent le plus de temps à traiter les paquets.
Les paquets ne sont pas évalués à nouveau par rapport aux règles suspendues avant l’expiration d’un délai configurable, ce
qui donne au périphérique surchargé le temps de récupérer. Ces gains de performance peuvent se produire lorsque, par exemple :
-
des règles écrites à la hâte et en grande partie non testées nécessitent un temps de traitement excessif
-
une période de piètre performance du réseau, quand quelqu’un télécharge un fichier extrêmement volumineux, retarde l’inspection
des paquets
)
)
Commentaires