Plus d'update snort?

[Plattypus]

Toujours pas de news pour remédier à ce probléme ?

[ahlala]

Hello

Bon hé bien les choses sont claires, on ne peut rien faire!! J'exagère mais à part mettre les mains dans le cambouis c'est çà, bon çà peut être rigolo mais va falloir se faire une procédure blindée pour les systèmes en prod, snon...

Je dis tout çà parce qu'un post du 20/07/09 de Guiterman est très clair, "voyez avec les devs d'Ipcop".. voici l'url :

http://forums.snort.org/users/mguiterman/posts

et copier/coller de son post pour les fainéants :

July 20
mguiterman
81 posts
Topic: Support / Getting error message when trying to update rules
This has been discussed here and on Snort-users a few times. IPCop 1.4.x ships with an outdated version of Snort. The VRT no longer provides rule updates for the 2.6.x version of Snort. Rule updates for that version were end of lifed in Nov. 2008. You should contact the IPcop devs and request that they update the version of Snort included in IPCop.


Bon be voilà quoi...

[leso]

Dans la version de dev , c'est la version 2.8 qui a été implémenté

[ahlala]

OK Leso, donc que suggères-tu? perso, voici la procédure comme je la vois, qui récapitule et je pense clot le sujet en attente d'infos supplémentaires:

1 -> Priorité aux systèmes en prod, donc aucune tentative d'upgrade du moteur SNORT sans l'avis officiel du Team IPCOP

2 -> Avis à toutes personnes de bonne volonté et dans l'esprit de partage de savoir à tester une Upgrade manuelle du moteur SNORT dans un environnement sous-réseau de type test et sans forcément simuler une connexion directe au NET (on se fout pour l'instant que l'ipcop de test prenne en charge la con NET, ce qui compte c'est le OINK et la pérennité des updates/upgrades du NIDS)

3 -> Suivant si on y arrive, envoyer nos retours d'expérience au TEAM IPCOP pour leurs dev pour la future RELEASE IPCOP

4 -> Si qqun est costaud ou membre du TEAM pour développer, compiler, et proposer un patch à intégrer, perso je trouve çà cool, moi je ne suis pas assez costaud, je suis un admin, pas un dev... mais je veux bien essayer si on m'explique, j'ai dev mais ya longtemps, je ne peux pas prétendre à çà... plus maintenant... donc voilà

5 -> le sujet intéresse et concerne du monde, donc c'est bien

6 -> A bientôt

[leso]

Je ne suggère rien, j'informe juste mais il faudrait voir du coté de endian s'il sont passés en snort 2.8

[ahlala]

ben ouais mais si tu vois bien le topic lancé depuis le début, là on est sur des ipcop en prod, impossible de changer sans grosses galères, injecter du code extérieur c'est risqué, et tout changer serait galère et très très chaud à gérer... faisable bien sur mais si on peut éviter

[leso]

oui oui je dis pas au boulot c est le même cas, a part desactiver snort et en installer un autre sur une machine de green , je vois pas trop d 'autre solution simple

[ccnet]

Cette aventure, qui s'étale sur plusieurs mois, ne fait que me convaincre un peu plus de l'ineptie qui consiste à installer Snort sur ipcop. Snort serait installé comme il se doit, sur une machine indépendante, connecté via la port span d'un switch vous ne seriez pas dans cette situation.
Par ailleurs l'arrêt de la mise à jour des règles pour cette version a été annoncé bien avant qu'elle se produise. C'est dire si l'exploitation de Snort est suivie dans la pratique quotidienne ! Il est évident qu'une exploitation cohérente de Snort nécessite une attention quotidienne (pour ne pas dire 24/24 - 7/7) autant en direction des logs produits par la sonde (en admettant qu'elle soit bien placée) que du site snort.org.
Je ne parle même pas de la mise au point du jeux de règles à effectivement activer pour éviter les faux positifs dans les logs puisque concernant des logiciels qui ne sont pas présent sur l'infrastructure à surveiller. Et puis surveiller quoi ?
Là aussi il y a sans doute 10, 20 ou 30 actions à entreprendre sur vos réseaux pour en améliorer la sécurité.

[ahlala]

Hello

ccnet-->

Juste une précision pour réponde à ton post.

Installer un IDS sur un firewall n'est pas une hérésie, je ne pense pas. Effectivemment un IDS/IPS à part c mieux, çà, personne ne dira le contraire, comme coupler 2 voire 3 firewalls, c sur que plus on blinde et plus on dispatche, mieux c'est! mais celà a un coût! J'ai à plusieurs reprises imlémenté des fw sous deb, à la mano, avec portsentry en IDS, et çà c'est radical!! il est actif, pas passif comme peut l'être snort sur le ipcop.
snort peut être actif, je dis pas, mais les add-ons à répét sur un fw, je ne suis pas pour. snort étant intégré par le Team officiel, pourquoi ne pas l'activer? il est évident que celà relève de notre compétence de surveiller et d'analyser, c kler! c notre boulot!
L'avantage est que ipcop peut aussi s'administrer simplement par des non-admins, après formation de base, sur un système relativement ergonomique.

Le pb évoqué quant aux upgrades d'un moteur IDS comme snort revient à peu de choses près (bn je tape large d'accord..) à évoquer une upgrade systématique du kernel!!! comment savoir? la pile TCP/IP a considérablement évolué entre les versions de kernels, et je ne parle pas que des y dns le x.y.z! même dans le z on a vu des améliorations notamment au niveau du conntrack!

Et surveiller quoi tu disais? ben suivant l'architecture, avoir des infos quant à des problèmes de latence çà aide à comprendre l'architecture, quand tu as des ralentissements, que les logs iptables suffisent pas, avoir une idée d'un DNS SPOOF ou autre peut aider à comprendre où çà coince et donc dépanner, c'est l'objectif aussi, la sécu à 100% n'existe pas, on n'a des infos, on en récupère un maxi pour améliorer la qualité de service, c'est tout... Enfin à mon sens.. Et çà aide justement à dépannner tel ou tel pb même en interne.
Le pire des hacks, c'est le social engineering...

Je partage ton opinion sur certains trucs mais pas sur tout

A +

[ccnet]

Revenons aux fondamentaux. Ipcop est une solution sérieuse, efficace et sûre. Elle est destinée à des réseaux relativement simples, donc le plus souvent à de petites structures. Structures qui n'ont ni les moyens, ni les compétences pour installer, mettre au point, exploiter, maintenir un IDS.

L'avantage est que ipcop peut aussi s'administrer simplement par des non-admins, après formation de base, sur un système relativement ergonomique.

IPcop seul n'est pratiquement pas concevable. Bot est indispensable. A ce niveau là (ipcop + BOT) , on ne peut déjà plus confier facilement le firewall à des "non-admins" comme vous dites. On peut le laisser fonctionner seul et intervenir ponctuellement pour prendre en charge une évolution. Il n'y aura donc personne pour lire et analyser avec la pertinence qui convient les logs de Snort.

Et surveiller quoi tu disais? ben suivant l'architecture ...

Ce que 95% des personnes qui fréquentent ce forum ne sont pas en mesure de déterminer. Au moins 80% (je suis optimiste peut être ...) ne savent pas que Snort utilise des jeux de règles qui concernent tel ou tel produit (IIS par exemple) et qu'il ne sert à rien d'activer ces règles si l'on n'a pas de serveur web ou IIS sur son réseau. Je n'ai pas de difficulté à déterminer ce qu'il faut surveiller sur un réseau. Ce que je dis c'est que l'immense majorité des utilisateurs d'ipcop n'en ont ni le temps ni les compétences pour le faire. Voilà pourquoi :

snort étant intégré par le Team officiel, pourquoi ne pas l'activer?

cela n' a pas grand sens sur ipcop.

Merci d'écrire en français.

[ahlala]

Revenons aux fondamentaux... Tout à fait Capitaine.. pardon, Amiral...

Je ne suis pas d'accord avec toi sur certains points et ne lancerait pas de trolls, cependant, j'estime devoir répondre.

Ipcop est sur? oui

Destiné aux petites structures? non, pas seulement. on ne parle pas de FW Nokia à 6 interfaces, d'accord ni de PIX ou de routeurs Cisco blindés en bundle, on est d'accord, mais ipcop tient bien la charge, et BOT n'est pas nécessaire, un petit tour dans le /etc/rc.d/rc.firewall te permet de faire beaucoup, beaucoup de choses...

Il faut du monde pour administrer? oui, la preuve c'est moi qui le fais, je suis leur prestataire. Habituellement je monte tous mes FWs à la mano sous Debian, mais là ils ont besoin de "voir".. çà les rassure si tu préfères...ils gardent à l'esprit qu'ils ont la main, et en cas de pbs savent à qui s'adesser, en l'occurence moi, c'est mon métier!
A ce titre j'assure donc la maintenance et surveille donc les logs!

Je suis d'accord avec toi sur la difficulté d'appréhender les résultats de snort ou d'iptables, mais dans le cas qui m'intéresse, je dispose de srvs en entreprise et hélas, trois fois hélas, mais trois fois merci, il y a du microsoft derrière, donc çà me donne du taf, çà me fait vivre.. tu comprends je présume que je ne suis pas un fana de microsoft, mais c'est comme çà, ils sont partout, ceci dit les clients ont eu l'intelligence de confier leur sécurité à du Unix* donc çà compense

Je ne suis pas d'accord quand tu dis qu'activer snort n'a pas grand sens sur ipcop. il y aurait portsentry, ce serait mieux, c'est systématiquement comme çà que j'installe mes fws, mais çà n'est pas le cas, et rajouter un IDS n'est pas idiot sur un système central qui gère la sécurité des réseaux.

N'oublie pas une chose, le souhait des clients est d'être le plus autonome possible, sans avoir à payer les prestas d'un admin comme moi, donc installer un fw avec interface histoire qu'ils sentent qu'ils sont indépendants, çà les rassure. il n'empêche que notre métier à nous est d'assumer et d'assurer, tu le sais aussi bien que moi.

Je te prie de m'excuser si je me suis mal exprimé, tant en français, anglais, ainsi qu'en informatique, comme je te prie de m'excusr si mes propos te déplaisent.

Bonne soirée

[jdh]

Je plussoie ccnet encore une fois sur le sujet ids : il s'agit typiquement d'une fausse-bonne idée.


Pour qu'un IDS soit utile, il faut la conjonction de plusieurs choses :
- (BIEN evidemment) ne pas le placer sur le firewall,
- connaitre/comprendre les alarmes,
- avoir le temps nécessaire à l'analyse.
- (j'allais oublier) être dans un contexte où cela a du sens (je n'ai pas écrit "où cela se justifie").

Snort sur IPCOP est déjà une erreur pour le premier point.
Avoir la compétence et le temps est une estimation personnelle.
Il suffit de demander au patron ce qu'il en pense et il devrait y avoir un certain écart.

AMHA dans de grandes structures, qui disposent de ressources financières et humaines conséquentes, cela peut être, sans doute, mis en place.

Bref peu de chances que l'on utilise le couple IPCOP/Snort ...

J'ajoute que le rôle d'un professionnel "qui se respecte" n'est pas de conseiller un addons inutile à des gens qui n'ont pas les compétences pour l'exploiter.
Dire Snort c'est bien, c'est utile alors qu'il ne sera pas exploité est parfaitement ridicule.
Le pire en sécurité, c'est bien de faire croire que la sécurité cela s'ajoute en empilant les addons ... et que l'expertise peut être acquise en quelques heures de formation !


(NB : sur pfSense, il y a aussi des problèmes à downloader les rules Snort ! Etonnant, non ?)
(NB : il serait temps de passer à une firewall plus puissant qu'IPCOP ... Et perso, cela fait longtemps que j'ai arrêté de faire des firewalls sous Debian ... à la main !)

[ccnet]

Je te prie de m'excuser si je me suis mal exprimé, tant en français, anglais, ainsi qu'en informatique, comme je te prie de m'excusr si mes propos te déplaisent.

Nous ne faisons qu'échanger en termes civilisés des idées. C'est une discussion sans problème.

Destiné aux petites structures? non, pas seulement. on ne parle pas de FW Nokia à 6 interfaces, d'accord ni de PIX ou de routeurs Cisco blindés en bundle, on est d'accord, mais ipcop tient bien la charge, et BOT n'est pas nécessaire, un petit tour dans le /etc/rc.d/rc.firewall te permet de faire beaucoup, beaucoup de choses...

Pas vraiment de contradiction mais quelques observations.
1. Ipcop pour petites structures à mon sens, non pas pour des problèmes de tenues en charges, il suffit de mettre hardware en conséquence, mais surtout pour des raisons fonctionnels. De quoi s'agit t il ?
Ip ipcop ne gère pas via son interface :
- Les ip multiples sur red.
- Nat statique, dynamique ou 1:1.
- Load balancing.
- Redondance.
- Policy routing (routage en donction d'un protocole par exemple).
- Dmz Multiples
- Interfaces en pont
- Ip virtuelles
- Proxy arp
- Vlans
- Plus de 4 interfaces physiques ou logiques (et encore avec des rôles très précis)
- Nombre maxi de Syn/seconde et par règles
- Nombre d'entré par ip dans la table d'état
- Nombre maxi de connexion par client
- Les alias ou groupe (ip, proto, ...)

La liste n'est pas exhaustive. Voilà pourquoi dans une structure un peu étoffé ipcop ne suffit pas. Si ces fonctions couvrent les besoins alors tout va bien.

BOT n'est pas nécessaire. Il est juste indispensable. le trafic sortant est pratiquement aussi dangereux que le trafic entrant.
Il est indéniable que l'on peut faire beaucoup de chose dans /etc/rc.d/rc.firewall. Je l'ai fait mais là où je ne saisi plus la cohérence de votre propos :

mais là ils ont besoin de "voir".. çà les rassure si tu préfères...ils gardent à l'esprit qu'ils ont la main

Je le comprend parfaitement, mais en ce cas pourquoi modifier /etc/rc.d/rc.firewall à la main ? Que se passera t il lors d'une mise à jour ou d'un oubli dans la documentation ? Je ne conteste pas l'efficacité de la méthode mais sa cohérence avec le propos. Cela nous ramène directement à l'origine de ce fil.

A ce titre j'assure donc la maintenance et surveille donc les logs!

Tout les combien de temps ? Il faut 1mn 30 pour mettre en oeuvre l'exploit sur la dernière faille trouvé sur le FTP de microsoft. Avec le bon outil c'est vrai aussi pour des centaines de failles. Plutôt que de mettre un ids qui, si il n'est pas à jour laissera passer l'exploit, il est plus efficace de recourir à des firawalls applicatifs et ne pas laisser du Microsoft en face à face direct avec internet. Ce n'est d'ailleurs pas limité à Microsoft. La durée de vie d'un serveur Apache dans sa configuration par défaut est assez limité.
Si on évoque le problème des connexions SSL, que peut faire votre ids face à ce trafic ? Rien ! J'ai pourtant une admiration certaine pour un outil comme Snort mais il faut se rendre à l'évidence : il y a mieux à faire avant de l'utiliser.

Je ne suis pas d'accord quand tu dis qu'activer snort n'a pas grand sens sur ipcop. il y aurait portsentry, ce serait mieux, c'est systématiquement comme çà que j'installe mes fws, mais çà n'est pas le cas, et rajouter un IDS n'est pas idiot sur un système central qui gère la sécurité des réseaux.

Je persiste et je signe. Dans cette configuration l'ids est détectable et partant de là on peut l'éluder. Il ne reste plus beaucoup de son efficacité.
Il peut être utile de blacklister une ip source qui vient de faire un scan de port de 1 à 10 000 ... mais ce n'est pas l'agresseur que je crains le plus.

Dans les nuits de samedi à dimanche, ou entre vendredi 18h et lundi 9h, vous regardez combien de fois les logs des systèmes de vos clients ?

Maintenant vous menez votre barque comme vous le souhaitez. Je ne vous conteste rien sur ce point.

[Vehrsey]

Il suffit de mettre à jour votre Ipcop et de passer à la dernière version 1.4.23
Snort 2.8.4 fonctionne bien ainsi que la mise à jour par Oinkmaster.

Pour obtenir la dernière version Ipcop 1.4.23, il vous faudra, pour rappel, compiler la source.
Faire la mise à jour par CVS :

cvs -z3 -d:pserver:anonymous@ipcop.cvs.sourceforge.net:/cvsroot/ipcop co -r IPCOP_v1_4_0 ipcop

Ensuite, vous mettre dans le répertoire ipcop puis "./make.sh build" pour compiler et obtenir un .ISO

http://www.ipcop.org/index.php?module=p ... ldingHowto

[Vehrsey]

(Mise à jour au 17/04/10)
Voici le patch que j'ai fais pour que Snort 2.8.5.3 fonctionne sur Ipcop 1.4.21 (I386/I686/I586/I486). Vous pouvez l'obtenir sur ce ou ces liens :

http://dl.free.fr/qj1tG3gd1 (Obsolète : mettre à jour en Snort 2.9.0.0, voir ci-dessous les pages suivantes)

MD5: c1c4c043a8594a4dbc2f9a231e164de7

Transférer le fichier sur Ipcop :
Activer SSL sur Ipcop à l'aide de votre navigateur, puis transférer le fichier sur Ipcop à l'aide de la commande SCP.

scp -P 222 /home/votre_user/ipcop-1.4.21-snort2853-update.i386.tar.gz root@VOTRE_IP_IPCOP:/home

Sur Ipcop 1.4.21 se loger en root, décompresser le fichier puis installer le patch :

# cd /home
# tar zxvf ipcop-1.4.21-snort2853-update.i386.tar.gz
# ./setup