[RESOLU] addon snort et IPCOP V2.1.2

[Franck78]

Ailleurs dans le monde.....

Where $IFACE was IFACE=${IFACE:-any} in my rc.snort script. From the provided link SLL:
Quote:
This is the pseudo-protocol used by libpcap on Linux to capture from the "any" device and to capture on some devices where the native link layer header isn't available or can't be used.
I changed my script to IFACE=${IFACE:-eth0} and it works. Since this is the interface where all traffic goes through I don't think it needs to be any.


Franck

[Vehrsey]

Comme le dit Franck78, si tu veux le tester en ligne de commande il te manque l'interface comme paramètre, sinon il se produit une erreur.
Exemple :

/usr/sbin/snort -c /etc/snort/snort.conf -A full -i lan-1 (pour l'interface green)

/usr/sbin/snort -c /etc/snort/snort.conf -A full -i wan-1 (pout l'interface red)

Pour le reste de ton problème avec snort je ne vois pas.

[Bobm]

1) Je viens d'effectuer une nouvelle série de tests avec la version snort du 27/8 :
je rajoute dans le fichier /etc/snort/local.rules la ligne :
alert icmp any any -> any any (msg: "Test icmp snort"; sid:1000001;

TEST1A :

Je lance snort en manuel sur le réseau VERT
/usr/sbin/snort -c /etc/snort/snort.conf -A full -i lan-1

pas de message d'erreur : OK

Des ping vers IPCOP sur le réseau vert provoquent bien des alertes SNORT
--> OK ça marche !!!!!!!


TEST1B :

Je lance snort sur les réseaux VERT et ROUGE via le GUI

Des ping vers IPCOP sur le réseau vert provoquent bien des alertes SNORT
--> OK ça marche !!!!!!!

Des ping venant de l'exérieur vers IPCOP Rouge provoquent bien des alertes SNORT
--> OK ça marche !!!!!!!


2) j'enlève la ligne ajoutée précédemment dans le fichier /etc/snort/local.rules la ligne

Je lance snort sur le réseau ROUGE via le GUI

Aucune attaque de l'extérieur ne fait brocher snort ; quand on regarde le journal du pare-feu, on constate que les attaques semblent bloquées en amont par le pare-feu


Conclusion : pour l'instant, la seule chose dont je sois sûr c'est que la règle locale "alert icmp any any ..." est effective.
Je vais laisser tourner mon IPCOP (sans la règle snort locale) pour voir sa réaction ...
Je ne pourrai conclure qu'après

3) Sinon, j'ai enfin trouvé l'origine de mon autre problème (voir mon post du 9/4/2014) concernant le message d'erreur sur la console système
"other app is holding the xtable lock perhaps you want to use the w option" : il est du à Guardian.

A noter aussi que lors de ce problème le journal du pare-feu contient aussi des messages d'erreur du style "ERROR in puzzleFwRules: 1024 /sbin/iptables -A ..."

Le problème est du au fait que lors d'un redémarrage d'IPCOP, Guardian n'est pas correctement arrêté, du coup, lors de l'arrêt d'IPCOP, les iptables sont corrompues ...

Quand ce problème survient la seule manière de s'en sortie c'est de désinstaller Guardian.
Pour contourner le problème : il faut arrêter proprement Guardian (/usr/local/bin/guardianctrl stop) avant de redémarrer IPCOP

Je crois que pour corriger le problème, lors d'un redémarrage ou d'un arrêt d'IPCOP, il faudrait arrêter proprement Guardian avec les scripts qui vont bien ...

Merci de ton aide

[Vehrsey]

Il faudrait détailler comment tu as configuré Ipcop : matériel, schéma réseau,... . Parce que là je ne vois pas.

[Bobm]

Pour mon IPCOP de test, la configuration est la suivante :

- 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é

Après de nombreux essais, je crois qu'il y a 2 problèmes :

1) SNORT
La seule chose dont je sois sûr c'est que la règle locale "alert icmp any any ..." est effective.
Sinon j'ai beau attaquer mon IPCOP reseau ROUGE (sans la règle snort locale) depuis Internet : Snort ne détecte rien avec toutes les règles snort téléchargées.
Et pourtant, j'ai presque coché toutes les règles Snort ; pour moi ce n'est pas normal.
En effet, sur mon IPCOP de prod qui est en 2.0.6, snort n'a pas du tout ce comportement et réagit tout de suite ...


2) GUARDIAN

Dès lors qu'il y a AU MOINS 1 une règle Guardian d'activée et qu'ensuite on redémarre IPCOP :
- il y a un tas de messages d'erreur sur la console système :
"other app is holding the xtable lock perhaps you want to use the w option"

- il y a un tas de messages d'erreur dans le journal système du style "ERROR in puzzleFwRules: 1024 /sbin/iptables -A ..."


Pour faire disparaitre le problème : il suffit de suprimer TOUTES les règles actives de Guardian et là tout redevient OK : aucun message d'erreur après un reboot.

[Vehrsey]

Cocher l'interface Rouge et Vert de Snort

En principe, Snort devrait détecter quelque chose.

[Bobm]

Sur mon IPCOP de test (V2.1.5) : j'ai suivi exactement ce que tu préconisais :
. interfaces Rouge et Vert activés pour SNORT
. wget du .pdf de la 307
Mon log Snort reste désespéremment vide.
J'ai fait aussi le test utilisateur via un navigateur et le lien Google que tu avais précédemment indiqué : il ne se passe rien non plus.

Du coup, j'ai changé de type de carte réseau pour le réseau ROUGE (comme ça pour voir si c'était pas lié à un type de carte) : il ne se passe rien non plus.

Sur mon IPCOP de prod (V2.0.6) , quand je fais des ping de mon IPCOP depuis Network Tools : OK snort le voit ; mais ce n'est pas le cas de mon IPCOP de test (V2.1.5).
En résumé, sur mon IPCOP de test (V2.1.5), tout se passe comme si Snort ne détectait rien avec les règles snort téléchargées (par contre c'est OK avec une règle du type alert icmp dans le fichier local).

[Vehrsey]

Peut-être quand rajoutant directement dans le fichier /etc/snort/snort.conf à la 567 lignes ceci :

include /etc/snort/rules/file-pdf.rules


Pour éditer en ligne de commande le fichier :
nano -c /etc/snort/snort.conf

CTRL + O pour enregistrer
CTRL + X pour quitter l'éditeur.

Ensuite tester le lien :

http://www.glinche-automobiles.com/noti ... ,139,1.pdf

[Bobm]

1) En suivant tes instructions et en activant Snort via le GUI sur les réseaux VERT et ROUGE :
malheureusement, c'est toujours pareil : jamais aucun log de snort en téléchargeant le lien vers le .pdf de la 307

Du coup, pour voir, j'ai désactivé snort via le GUI et j'ai lancé snort par la ligne de commande
/usr/sbin/snort -c /etc/snort/snort.conf -A full -i wan-1

et ensuite, j'ai regardé les traces du lancement manuel
Je constate que j'ai plein d'erreurs du type

WARNING: /etc/snort/rules/file-pdf.rules(ii) GID 1 SID jjjjj in rule duplicates previous rule. Ignoring old rule

et pour chaque message d'erreur le Numéro de SID jjjjj change ...
Du coup je pense que ce test n'est pas significatif

2) j'ai enlevé la ligne 567 = "include /etc/snort/rules/file-pdf.rules"

J'ai relancé snort par la ligne de commande
/usr/sbin/snort -c /etc/snort/snort.conf -A full -i wan-1

et j'ai regardé les traces du lancement manuel. Tout me semble OK sauf les lignes suivantes :

+-------------------[Rule Port Counts]---------------------------------------
| tcp udp icmp ip
| src 1375 5 0 0
| dst 1475 585 0 0
| any 39 1 0 0
| nc 14 0 0 0
| s+d 1 1 0 0

Verifying Preprocessor Configurations!
ICMP tracking disabled, no ICMP sessions allocated
IP tracking disabled, no IP sessions allocated


Pour tous mes tests sur mon IPCOP de test (V2.1.5), tout se passe comme si Snort ne détectait rien avec les règles snort téléchargées (par contre c'est OK avec une règle du type alert icmp dans le fichier local)
En fait je constate que la plupart des attaques externes sont arrêtées en amont par le pare-feu.
Cela explique peut-être qu'en V2.1.5, snort ne détecte rien ...
En résumé, soit il y a vraiment un problème de détection des attaques par Snort OU alors en V2.1.5, pour une raison que j'ignore (nouveau kernel ??), il ne peut plus les détecter ...

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 ?
Merci.

[jdh]

En fait je constate que la plupart des attaques externes sont arrêtées en amont par le pare-feu.

Cela parait évidemment TRES logique.

Personnellement,
- je ne vois AUCUN intérêt à utiliser Snort sur un firewall = il y est TRES mal placé ... comme expliqué dans les docs SNORT !
- je n'ai pas le temps de gérer un système comme SNORT (ou autres xDS) ... ni les compétences ! (Je considère comme perte de temps de me former ...)