[RESOLU] addon snort et IPCOP V2.1.2

[Vehrsey]

- IPCOP 2.1.5 + 2 addons = Snort + Guardian (dernières version téléchargées sur sourceforge)
- 4 réseaux : RED en statique, GREEN + ORANGE + BLUE
- serveur mandataire configuré ; pas d'URLfilter
- aucune règle de configurée dans le pare-feu (pour l'instant) ; pour simplifier les tests, je laisse tout en natif
- SNORT activé pour réseau ROUGE
- GUARDIAN activé

Faire une simple configuration pour le test :
- Pas de Guardian
- Pas de Proxy
- uniquement RED + GREEN
- Snort activé sur Rouge et Green

De ton côté, peux tu me confirmer que tu as pu constater en V2.1.5 que Snort détecte bien les attaques associées aux règles snort téléchargées ?

Snort a été testé avec Kali Linux + Metasploit en local. Snort détecte la plupart les attaques en fonction des règles activées.
Il est normal que le firewall bloque les attaques sur l'interface rouge. Pour faire des testes directement sur l'interface rouge il faut ouvrir d'abord des ports et des services... .

[Bobm]

Personnellement,
- je ne vois AUCUN intérêt à utiliser Snort sur un firewall ...

En effet snort tout seul n'a aucun intérêt. Par contre couplé à l'addon Guardian, il prend tout son sens car ce dernier bloque automatiquement les attaques détectées par Snort ...
On transforme alors IPCOP en IPS ; de mon point de vue, on sécurise encore mieux IPCOP car les adresses IP qui attaquent sont bloquées en amont.

J'ai configuré mon IPCOP de test (V2.1.5) avec une simple configuration :
- Pas de Guardian
- Pas de Proxy
- uniquement RED + GREEN
- Snort activé sur Rouge et Green
- pare-feu avec des règles activées (tel port TCP accepté, icmp accepté ...)

1) Tous les tests d'attaques depuis l'extérieur (ping, nmap ...) ont le même comportement :

• dans le journal du pare-feu : on voit les refus ou les acceptation
• dans le journal IDS : rien

2)je modifie le fichier /etc/snort/local.rules
En mettant par exemple (j'ai fait plusieurs essais) uniquement la ligne suivante :
alert tcp any any -> any 21 (msg: "Test port 21 snort"; sid:1000001;)

• dans le journal du pare-feu : on voit les refus ou les drop ou les acceptation selon les règles configurées dans le pare-feu
• dans le journal IDS : l'attaque qui est configurée localement dans snort est toujours détectée par ce dernier !!!!! et ce que le pare-feu ait refusé, droppé ou accepté le paquet entrant.

--> C'est le fonctionnement de snort que je connais sur mon IPCOP de prod qui est en V2.0.6 cad que le paquet est toujours analysé par snort, indépendamment du traitement du pare-feu

Conclusion de ces tests :
- avec un IPCOP en V2.1.5, snort ne détecte les attaques que si elles sont configurées en local.
En d'autres termes, les règles snort téléchargées semblent ne pas être prises en compte.

- IPCOP V2.0.6 : le fonctionnement de snort est OK

[Vehrsey]

Pour le test :

- pas de proxy
- activer uniquement les interfaces Rouge ou Vert
- pas de Guardian pour le test (pas utile pour le moment).

Si tu le souhaites, tu peux m'envoyer des messages privés sur le forum cela évitera de trop monopoliser et remonter ce sujet en tête de topique du forum.

[jdh]

(Je n'aurais pas du ...)

J'ai écrit

je ne vois AUCUN intérêt à utiliser Snort sur un firewall = il y est TRES mal placé ... comme expliqué dans les docs SNORT !

Merci de ne pas couper ce que j'écris car cela en dénature le sens !

Autrefois dans les docs SNORT, on trouvait un document sur le positionnement de Snort.
On peut, en cherchant sur G / images + "snort deployment", voir que Snort est sur une machine distincte du firewall, et placé en deça du firewall (à l'intérieur).

Par ailleurs, utiliser Snort suppose une expertise et une disponibilité pour la réaction.
De mon point de vue, il y a contradiction entre l'install de Snort sur le firewall (= mauvais placement, moyen limité) et l'objet (intérêt) de Snort (= architecture, compétence, ...)

Je renvoie à l'excellent lien : http://www.oreilly.de/catalog/snortids/chapter/ch06.pdf (Deploy NIDS with your eyes open)

NB : je ne dénigre pas le (long) travail de Vehrsey car il est sans doute utile pour celui qui souhaite déployer Snort "normalement" !

[ccnet]

Snort est une sorte de serpent de mer, de monstre du Loch Ness, qui refait surface périodiquement. Non sans un travail important parfois d'utilisateurs potentiels. Je ne peux que confirmer la pertinence du post précédent. Je connais des structures qui déploient et exploitent des ids. Les moyens humains mis en place pour cela sont considérables. 24/7, astreinte, répartition géographique, expertise ...

[Bobm]

La dernière version de Snort (7/10/2014) corrige tous les problèmes ; elle apporte notamment un gros plus qui est emerging-scan.rules
La dernière version de Guardian (17/10/2014) corrige tous les problèmes.

Pour ceux que cela intéresse, j'utilise le couple Snort + Guardian pour me protéger facilement et efficacement contre les attaques externes :

c'est IPCOP qui fait tout et une fois que tout est bien installé et configuré, l'admin réseau n'a pas besoin de télécharger de nouvelles règles Snort (au contraire, il vaut mieux laisser une version stable des règles de Snort et ne plus y toucher) ; Guardian bloque automatiquement les adresses IP associées aux alertes Snort ; l'admin peut bloquer (en plus) manuellement via Guardian les adresses ou plages d'adresses IP désirées ; de plus, en cas de reboot, les adresses IP bloquées automatiquement par Guardian sont enlevées (donc, si on reboot tous les jours = peu de risque de bloquer malencontreusement et durablement une adresse IP qui en fait serait saine). Il n'y a donc aucune charge de travail suplémentaire pour l'admin ; en tout cas, dans notre cas, cela complète et protège efficacement notre firewall IPCOP.