Mises à jour Snort…
-
Bonjour à tous…
Je viens d'installer le paquet Snort, pour la version 1.2.2 de pfSense... Lors de la première mise à jour des bases j'obtiens un message d'erreur m'indiquant que je ne posède pas les autorisations d'accès sur le serveur distant pour récupérer l'archive tar.gz.... :-[
Au bout de plusieurs tentatives le téléchargement c'est bien effectué localement sur le firewall, dans le dossier "tmp" : 81 Mo téléchargé... Mes aucunes mises à jour disponibles depuis l'interface Web "Services", "Snort"... Je n'accède seulement qu'a la page du menu "Général" de la config Snort... LEs autres onglets m'indiquent toujours un éventuel téléchargement actif... Bref je ne vais pas plus loin avec Snort même si les bases sont totalement récupérées... pfSense ne fais aucune mise à jour de son interface Web...Là je nage... merci pour votre aide... ;D
-
Pas de réponse à votre problème précis mais une mise en garde. Snort n'a pas sa place sur le firewall, comme d'une façon générale un ids sur un firewall pour des raisons de sécurité. Ensuite l'exploitation d'un ids est un travail considérable qui demande des ressources humaines importantes, en volume et en qualification. En d'autres termes des choses qui ne sont pas à la portée d'une PME, même importante.
-
Merci pour ta réponse CCNET.
J'imaginais Snort comme un IPS et non un IDS. Un service supplémentaire permettant une analyse protocolaire plus fine des paquets. Un complèment aux règles de filtrage pour rendre le firewall plus efficace… -
Snort peut fonctionner en IDS(N) ou en IPS.
CCNET, et moi même, avons notre vue et nos arguments sur le placement des équipements de détection/prévention d'intrusion. Nous ne considérons pas comme la solution idéale l'activation d'un IDS/IPS sur un firewall. Nous sommes favorable à l'IDS sur port de réplication (ou autre technique de réplication de trafic) et à l'IPS réalisé par les différents proxy protocolaires devant êter mis en place lors de la publication de service.
Il est vrai que dans certains cas on peut être amené à activer quelque règle d'IPS sur la brique firewall mais c'est rare. -
Bonjour Juve et merci encore d'apporter, tout comme CCNET, un discourt pro à ma question qui vient de se transformer en débat "pour ou contre un IPS ou IDS sur un firewall" ;D.
Je suis actuellement certifié Admin et Expert sur les firewalls NetASQ, que j'installe maintenant depuis plus de six ans… Perso en étant passé par IPcop, Smoothwall, Endian Firewall et autre produits open source... C'est avec pfSense que je retrouve le plus de similitudes avec les produits NetASQ, normal basé sur FreeBSD aussi, donc utilise PF... NetASQ à développé son module ASQ (IPS), détection d'intrusion, analyse protocolaire et contextuelle. C'est à ce titre que je voulais ajouter Snort aux règles de filtrage pfSense (analyses et détections complémentaires au filtrage...). Mais apparemment Snort serai plutôt à installer en temps que sonde sur un réseau ou entre le réseau et le firewall tout en alimentant une base de donnée SQL pour consolider l'information. Et donc à déconseiller son installation sur un firewall... au détriment d'un IPcop ou Smoothwall qui peuvent l'utiliser nativement... :) -
Sur Ipcop c'est aussi snort qui est utilisé, la seule différence est que le module est dans le package de base. Peu importe. Je rapelle brièvement pour ceux qui sont interessé par le sujet pourquoi je ne suis pas partisant de la présence de Snort sur le firewall.
1. La probabilité de failles exploitables est directement lié aux nombres de process qui tourne sur une machine et au nombre de lignes de code présentes.
2. Il est important qu'un IDS (ou un IPS) soit le plus invisible possible depuis l'extérieur. L'utilisation d'un port "span" (port de copie) est donc souhaitable enutilisant une interface réseau avec l'ip 0.0.0.0.
3. L'IDS devant être protégé son insterface d'dministration sera distincte de préférence.
4. La saturation d'un IDS n'est "que gênante" sur une machine indépendante mais qu'en est il t il sur le firewall ? Cela devient très risqué.
5. En IPS, le risque lié aux faux positifs est grand. En dehors de cas spécifiques non équivoques pourquoi pas. La généralisation comporte trop de risques.S'agissant de l'amélioration de la sécurité pour les services accessibles depuis internet, je suis plutôt partisant de solution du type "firewall applicatif", reverse proxy, passerelles, etc … permettant une défense en profondeur et un cloisonnement strict des trafics. Le tout sans exposer en première ligne la machine qui fourni le service.
Voilà en quelques lignes ce que sont, et sur la même ligne que Juve, mes motivations en faveur de la sonde "externe".
-
Merci encore pour les précisions apportées sur le sujet. Je partage pleinement cette idée de ne pas ajouter inutilement des services type proxy ou IDS/IPS sur un firewall, au risque de voir son efficacité initiale diminuer. Il doit rester à sa fonction initiale, routage et filtrage entre interfaces. Permettre une segmentation réseau physique fine de type, bridge, hybride ou avancée. Création de Lan virtuels (Vlan) "optionnel". Gestion de la qualité de service. Création de tunnels VPN IPsec. Possibilité d'être mis en Haute Dispo. Cela afin de ne pas augmenter le risque de vulnérabilité. A mon sens je n'utilise même pas les services réseaux , tel que le DHCP, fourni avec eux… Tous autres services comme le filtrage URLs, Spam doit être impérativement hébergés sur une autre machine en zone neutre type DMZ et n'ont donc pas leur place sur un firewall... Dans un cadre purement professionnel, il va de soit...
-
Dans une une situtation small office, il est courant de voir ce type de boitier sachant tout faire. Soyons honnête, dans ce genre de situation c'est la meilleurs solution en terme de prix/perf/fonctionnalités.
Mes propos sont à retenir sur des infrastructures de taille significative et sur les projets ou le budget alloué à la sécurité permet de mettre en place une solution issue d'une réflexion profonde sur les flux et leur contrôle..
Pour ma part j'intègre également des solutions Juniper…qui réalisent la fonction IDS/IPS sur la partie firewall, dans ce cas, je limite au stricte nécessaire les analyses requises.