Suricata : méthodologie pour la compréhension des règles.
-
Bonjour,
J'essaye de suivre une méthodologie "classique" pour l'IDS.
Je laisse les règles "ETOpen Emerging Threats rules" par défaut en place.
J'attend Un peu de temps que mes logs d'alertes se remplissent.
J'analyse les alertes pour savoir si ce sont des faux positifs ou pas.
L'idéal est donc de comprendre chaque règle associé aux alertes.
La méthode google est ton amis est tres aléatoire.
Je suis surpris qu'il n'existe pas un référentiel qqpart qui explique ce que fait chaque règle (sans avoir à analyser le code de chaque règle).
Pouvez vous me conseiller dans ce sens ? -
Puisse que vous semblez réfléchir à un IDS
- un firewall est-il la bonne position pour un IDS ?
-
Bonjour,
Dans mon architecture oui c'est le but : Le firewall sépare toute les DMZ et l'IDS embarqué surveille tout activité associé aux flux circulant entre les zones. Typiquement si une zone est compromise , des flux anormaux visant les autres zones peuvent être détectés par l'IDS embarqué.
Pour en revenir à la question d'un référentiel des "ETOpen Emerging Threats rules", n'existe t'il pas un endroit ou l'on peut avoir l'expliquation des chacune des règles ?
Je ne me vois pas aller aller lire le code associé à chaque règle (ca peut être intéressant mais je vais manquer de temps avec potentiellement des centaines de règles) -
Vous êtes débutant ?
Un IDS ne devrait pas être placé sur un firewall !
Sinon il va réagir à toute tentative côté WAN, lesquelles seront majoritairement bloquées.
Il devrait être placé en copie de trafic sur les interfaces internes, en particulier la DMZ.Et comme addons, il risque d'affaiblir le firewall …
-
lol.
"Sinon il va réagir à toute tentative côté WAN, lesquelles seront majoritairement bloquées."
T'es sur que tu comprends bien l'intéret d'un IDS/IPS ? J'espere bien qu'il va réagir aux tentatives coté WAN , il manquerait plus que ca.
Dans mon cas le WAN est un VPN mais …bref....je suis en train de perdre mon temps.
Je reviendrai pas sur ce post, je veux pas faire du combat contre du troll.Tchao.
-
Je ne trolle absolument pas, ne vous en déplaise :
- il est parfaitement stupide de regarder les tentatives qui essaient d'entrer
- il est bien plus logique de regarder le trafic autorisé
Bien évidemment de nombreux imbéciles écrivent que la position idéale est le firewall : cela ne résiste pas une minute à une étude pratique !
A quoi bon regarder ce qui tente d'entrer si c'est bloqué par le firewall !!
Certes pour apprendre ? Soyez plutôt pragmatique : regardez s'il y a quelque chose dans le traffic autorisé, vous perdrez moins de temps ! -
J'espere bien qu'il va réagir aux tentatives coté WAN , il manquerait plus que ca.
Votre réaction est techniquement discutable au moins sur deux points.
1. Effectivement la détection sur l'interface wan n'est pas vraiment une bonne idée en terme d'efficacité. Quel intérêt de "faire sonner" l'ids sur un flux bloqué par le firewall ? Il y a un intérêt beaucoup plus important de surveiller le segment de réseau sensible pour y détecter des flux potentiellement malveillants qui auraient réussis à y pénétrer. Cela me semble beaucoup plus pertinent et plus efficace.
2. La placement de l'ids sur le firewall est lui aussi tout à fait discutable.
2.1 Les addons à Pfsense ne sont développés par l'équipe Pfsense, même si ils sont validés, mais par des tiers. Pour moi c'est un risque supplémentaire non négligeable. Malgrés le soin apporté par les développeurs de Pfsense celui-ci a connu des vulnérabilités significatives sur certaines versions pas si anciennes susceptibles de conduire à l'exploitation d'un reverse shell root. Donc les packages …
2.2 En matière de sécurité aujourd'hui le concept de défense en profondeur implique une règle de base : l’indépendance des moyens de protection. Le bon fonctionnement de l'un devant ne pas dépendre d'un autre. Dans votre configuration ce principe n'est pas respecté.
2.3 Une sonde réseau doit être invisible ou du moins la plus discrète possible, ce qui implique qu'elle ne possède pas d'adresse ip sur le réseau qu'elle surveille. Dans votre configuration ce n'est pas le cas.3. Enfin avant de mettre en œuvre ce type de produit il pourrait être intéressant de se pencher sur la façon dont vos zones réseaux sont protégées et isolées les unes des autres. Si votre besoin de sécurité justifie un ids, il est probable qu'il justifie un cloisonnement des zones rigoureux avec des firewalls multiples et où l’acheminement des flux par simple routage ne soit pas possible.
Ces quelques réflexions pour "perdre votre temps" utilement.