Confessions d'un testeur: comment j'ai fouillé dans un IDS concurrent

Aucune passerelle de sécurité réseau UTM qui se respecte ne peut se passer d'un système de détection d'intrusion (IDS). Une autre chose est que l'option est souvent indiquée par le fabricant pour une coche afin de suivre les concurrents. D'après mon expérience en tant que testeur, je sais comment cela se produit - il semble y avoir un IDS, mais en fait ce n'est pas bon. C'est pourquoi, quand on m'a proposé de tester un matériel UTM relativement peu coûteux, j'ai suggéré tout d'abord de «chasser» son OWL.


Pièce UTM de Traffic Inspector Next Generation S100 et Cisco 2960G Switch


Si vous avez de l'expérience avec IDS, il est intéressant de le lire dans les commentaires de l'article. Il est conseillé - pas de matériel coûteux (il est clair que certains Cisco NGFW pour un million fonctionnent bien), mais de solutions plus abordables. Je pense que les administrateurs de lokalka et les utilisateurs potentiels de passerelles réseau seront curieux de savoir qui travaille avec IDS et s'il vaut la peine d'acheter à un prix élevé, lorsque vous pouvez, après avoir dansé avec un tambourin, obtenir le même pour moins d'argent.

Dans ce test, nous parlons du modèle S100 - le prix le plus abordable de la gamme Traffic Inspector Next Generation (les chiffres signifient qu'il est conçu pour 100 abonnés). Voici sa description sur le site officiel >>> . En bref, le matériel contient, par exemple, un filtre réseau, un VPN, un bloqueur de ressources et, bien sûr, un IDS.

Je propose une méthodologie de test simple - nous vérifions le débit et établissons la dépendance du nombre de paquets abandonnés sur l'intensité du trafic par incréments de 50, 100, 150 et 200 Mb / s. Pourquoi prenons-nous de tels intervalles? Nous partons de 100 Mb / s - la demande client la plus populaire, et reportons le plus et le moins pour voir ce qui se passe en modes plus ou moins chargés, ainsi qu'en mode extrême 200 Mb / s.

L'expérience de vie me dit qu'avec toutes les règles actives, le S100 peut ne pas tirer, donc je suggère que la procédure décrite soit exécutée en trois modes: d'abord lorsque toutes les règles sont actives, puis avec la partie des règles désactivée (appelons-le Groupe n ° 1) et, enfin, seulement quand il est actif juste quelques règles (appelons-le groupe n ° 2). Nous formons les groupes de règles suivants:

- Groupe n ° 0: c'est compréhensible, toutes les règles sans exception.
- Groupe n ° 1: groupe de règles Emerging Threads (je connais les règles depuis le test d'IDS Snort, à l'exception des règles des jeux émergents).
- Groupe n ° 2: un ensemble de règles que je considère simplement contraignantes pour IDS (voir ci-dessous), y compris l'ajout de règles p2p, car d'après ma propre expérience, je sais à quel point les grandes entreprises sont négativement liées au fait que leurs employés utilisent activement l'entreprise réseau pour télécharger vos émissions de télévision préférées.

Le test est possible à l'aide de l' utilitaire tcpreplay . Cet utilitaire vous permet de lire le trafic réseau préenregistré à une vitesse spécifique. Commande: tcpreplay –i <interface> -l 0 testTI.pcap . Le fichier testTI.pcap contient 1 146 313 paquets (nous choisissons un tel volume pour que, d'une part, il y ait de bonnes statistiques, d'autre part, le temps de «s'exécuter» ne soit pas trop long, dans notre cas, pas plus de 15 minutes). En plus de cela, comme je l'ai dit, nous lançons un tracker torrent.

Disposition du banc d'essai:



Si quelqu'un a des questions sur la méthodologie de test, je suis prêt à répondre dans les commentaires.

Donc, les résultats.

Groupe 0

Les tests sur un ensemble complet impliquent le chargement de toutes les règles, et il y en a 30 305.

Lors des tests, nous utilisons les paramètres IDS par défaut:



Nous commençons à tester avec 100 Mb / s et nous comprenons que le morceau de fer peut à peine tirer: sur 114 000 paquets, 109 000 sont jetés! Il est donc inutile de tester à 150 et encore plus à 200 Mb / s. Au contraire, je propose de donner une chance à l'appareil et d'effectuer un test supplémentaire à 10 Mb / s. Le résultat dans le tableau:



Remarque:

kernel_packets - paquets envoyés;
kernel_drops - paquets perdus. Comme vous pouvez le voir, avec les paramètres par défaut et avec un ensemble complet de règles, de grandes pertes de paquets se produisent (> 30% par rapport aux kernel_packets). Espérons que l'optimisation des règles de paramétrage changera la situation;
decoder_packets - le nombre de paquets que le système a correctement traités;
detect_alerts - nombre d'attaques détectées. La plupart des attaques sont de type paquet fragmenté, mais les attaques de détection de traqueur de torrent ont également été identifiées.

Numéro de groupe 1

De toute évidence, le matériel n'est pas optimisé pour fonctionner comme un IDS puissant à part entière, mais il y a une marge de manœuvre, à savoir la possibilité de changer le mécanisme de recherche des itinéraires, de désactiver le téléchargement du contenu du package (charge utile) et de désactiver les groupes de règles et les groupes spécifiques de packages. Un peu d'expérimentation avec les paramètres - et nous arrivons à l'option que je présente dans la figure suivante.



La liste des règles actives que nous laissons:



Résultat du test:



Comme vous pouvez le voir, l'image s'est considérablement améliorée avec ce groupe de règles (le pourcentage de paquets abandonnés a diminué plusieurs fois). Une attaque telle que «Détection d'un traqueur de torrent» a été détectée avec succès (les attaques de «paquets fragmentés» n'apparaissent plus).

Numéro de groupe 2

Les paramètres sont les mêmes. Liste des règles actives:



Le résultat dans le tableau:


Ici, l'image du traitement des paquets est encore meilleure, ce qui est attendu.

Résumé

Le tableau de résultats final, exprimé en pourcentage de kernel_drops par rapport à kernel_packets, est présenté ci-dessous:



Graphiquement, le résultat est le suivant:



Comme vous pouvez le voir, le nombre de règles et de paramètres actifs affecte directement l'efficacité. Cela n'a pas de sens d'activer les paramètres au maximum et toutes les règles en même temps - les pertes descendent immédiatement de l'échelle même de 10 Mb / s. Dans les modes optimisés, le matériel semble normal jusqu'à 100 Mb / s, mais les pertes augmentent fortement sur un trafic plus intensif. Cependant, pour une utilisation «bureautique», 100 Mb / s suffisent. Si vous conduisez l'appareil à cette vitesse et sélectionnez les règles, vous pouvez obtenir un IDS tout à fait satisfaisant.

Peut-être, pour utiliser l'ensemble complet de règles, des améliorations sont nécessaires pour utiliser le mécanisme pf_ring (https://www.ntop.org/products/packet-capture/pf_ring/) comme mécanisme de transfert d'un paquet vers l'espace utilisateur à partir du tampon d'interface réseau. Pour ce faire, vous devrez utiliser plusieurs instances de Suricata, qui, bien sûr, prendront des ressources d'autres processus, mais peut-être que le jeu en vaut la chandelle.

Je répète qu'à mon avis, l'objectif principal de l'appareil testé est un pare-feu et que l'option IDS est auxiliaire. Honnêtement, j'étais prêt pour le fait que le matériel échoue. Il s'est avéré qu'avec une certaine perception gutta de l'administrateur système, le système de détection d'intrusion du S100 est pleinement opérationnel.

PS Comme je l'ai dit ci-dessus, j'exhorte les lecteurs à écrire sur leur expérience de l'utilisation d'IDS dans des solutions relativement peu coûteuses.

Le test PPS est publié dans le compte du fabricant, car je ne veux pas me «briller». Néanmoins, je suis prêt à répondre à toutes les questions et débats dans les commentaires, mais, encore une fois, pas en mon nom :)