Re bonjour...
cette fois-ci, j'ai essayé de tout lire avant de poser une question....
alors bien entendu, j'ai des pbs avec snort-inline...
j'ai positionné les variables var home_net....toutes sur any.
j'ai un iptables 1.2.6a
j'ai le module qui permet le dialogue entre iptables et snort-inline activé,
mon iptables n'est pas en bridge...et tous les exemples vus sur le net
utilisaient le mode bridge...
est-ce le problème ?
sinon :
- je reçois bien les alertes lorsque je passe dans une URL des choses
horribles du genre dir c:\ et autres
- mais les connections ne sont pas droppées car avec Ethereal, je vois le
GET HTTP contenant "dir c:\" arriver sur mon serveur.
qui peut m'aider ?
merci par avances chers amis de la sécurité.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
simon marechal
j3CubL4H wrote:
- mais les connections ne sont pas droppées car avec Ethereal, je vois le GET HTTP contenant "dir c:" arriver sur mon serveur.
C'est normal le sniffer doit voir les paquets avant tout traitement pas le noyau (bon ce n'est pas toujours le cas mais normalement c'est ça). Il ne devrait pas contre pas y avoir la suite de la conversation tcp dans ethereal si le filtre est bien configuré.
j3CubL4H wrote:
- mais les connections ne sont pas droppées car avec Ethereal, je vois le
GET HTTP contenant "dir c:" arriver sur mon serveur.
C'est normal le sniffer doit voir les paquets avant tout traitement pas
le noyau (bon ce n'est pas toujours le cas mais normalement c'est ça).
Il ne devrait pas contre pas y avoir la suite de la conversation tcp
dans ethereal si le filtre est bien configuré.
- mais les connections ne sont pas droppées car avec Ethereal, je vois le GET HTTP contenant "dir c:" arriver sur mon serveur.
C'est normal le sniffer doit voir les paquets avant tout traitement pas le noyau (bon ce n'est pas toujours le cas mais normalement c'est ça). Il ne devrait pas contre pas y avoir la suite de la conversation tcp dans ethereal si le filtre est bien configuré.
j3CubL4H
comment puis-je voir si le noyau traite ou pas le paquet... peut-on sniffer l'activité du noyau...?
JM
"simon marechal" a écrit dans le message de news: c8bgjh$ce2$
j3CubL4H wrote:
- mais les connections ne sont pas droppées car avec Ethereal, je vois le
GET HTTP contenant "dir c:" arriver sur mon serveur.
C'est normal le sniffer doit voir les paquets avant tout traitement pas le noyau (bon ce n'est pas toujours le cas mais normalement c'est ça). Il ne devrait pas contre pas y avoir la suite de la conversation tcp dans ethereal si le filtre est bien configuré.
comment puis-je voir si le noyau traite ou pas le paquet...
peut-on sniffer l'activité du noyau...?
JM
"simon marechal" <simon@nospam-banquise.net> a écrit dans le message de
news: c8bgjh$ce2$1@news-reader1.wanadoo.fr...
j3CubL4H wrote:
- mais les connections ne sont pas droppées car avec Ethereal, je vois
le
GET HTTP contenant "dir c:" arriver sur mon serveur.
C'est normal le sniffer doit voir les paquets avant tout traitement pas
le noyau (bon ce n'est pas toujours le cas mais normalement c'est ça).
Il ne devrait pas contre pas y avoir la suite de la conversation tcp
dans ethereal si le filtre est bien configuré.
comment puis-je voir si le noyau traite ou pas le paquet... peut-on sniffer l'activité du noyau...?
JM
"simon marechal" a écrit dans le message de news: c8bgjh$ce2$
j3CubL4H wrote:
- mais les connections ne sont pas droppées car avec Ethereal, je vois le
GET HTTP contenant "dir c:" arriver sur mon serveur.
C'est normal le sniffer doit voir les paquets avant tout traitement pas le noyau (bon ce n'est pas toujours le cas mais normalement c'est ça). Il ne devrait pas contre pas y avoir la suite de la conversation tcp dans ethereal si le filtre est bien configuré.
Cedric Blancher
Le Tue, 18 May 2004 08:04:17 +0000, j3CubL4H a écrit :
comment puis-je voir si le noyau traite ou pas le paquet... peut-on sniffer l'activité du noyau...?
D'abord en arrêtant de quoter comme un goret.
http://www.giromini.org/usenet-fr/repondre.html
Si Snort Inline te remonte des alertes, alors il voit les paquets, mais ne les traite pas comme des erreurs, ce qui pose un problème évidemment. Cela vient probablement du fait (RTFM) que tu n'a pas mis en place les drop-rules (commencent par "drop"), c'est à dire les règles qui jettent les paquets, mais que tu as celle de base qui ne font que générer des alertes (commencent par "alert").
Dans le répertoire des sources de Snort Inline, tu as plusieurs répertoires avec les jeux de règles adhoc :
. rules pour les règles Snort classiques . replace-rules pour les règles visant à modifier des paquets . drop-rules pour les règles visant à droper un paquet (cf. DROP) . reject-rules pour les règles visant à rejeter un paquet (cf. REJECT)
Pour être sûr du jeu de règles utilisé, tu regardes la variable RULE_PATH dans le snort_inline.conf et tu vérifies que ça envoie bien sur les drop-rules.
-- Je suis en train de me tater (pas devant tout le monde bien sur) sur la passage a testing au lieu de stable. -+- WM sur debian-french: "masturbation mentale d'une queue de cerise" -+-
Le Tue, 18 May 2004 08:04:17 +0000, j3CubL4H a écrit :
comment puis-je voir si le noyau traite ou pas le paquet...
peut-on sniffer l'activité du noyau...?
D'abord en arrêtant de quoter comme un goret.
http://www.giromini.org/usenet-fr/repondre.html
Si Snort Inline te remonte des alertes, alors il voit les paquets, mais
ne les traite pas comme des erreurs, ce qui pose un problème évidemment.
Cela vient probablement du fait (RTFM) que tu n'a pas mis en place les
drop-rules (commencent par "drop"), c'est à dire les règles qui jettent
les paquets, mais que tu as celle de base qui ne font que générer des
alertes (commencent par "alert").
Dans le répertoire des sources de Snort Inline, tu as plusieurs
répertoires avec les jeux de règles adhoc :
. rules pour les règles Snort classiques
. replace-rules pour les règles visant à modifier des paquets
. drop-rules pour les règles visant à droper un paquet (cf. DROP)
. reject-rules pour les règles visant à rejeter un paquet (cf. REJECT)
Pour être sûr du jeu de règles utilisé, tu regardes la variable
RULE_PATH dans le snort_inline.conf et tu vérifies que ça envoie bien
sur les drop-rules.
--
Je suis en train de me tater (pas devant tout le monde bien sur) sur la
passage a testing au lieu de stable.
-+- WM sur debian-french: "masturbation mentale d'une queue de
cerise" -+-
Le Tue, 18 May 2004 08:04:17 +0000, j3CubL4H a écrit :
comment puis-je voir si le noyau traite ou pas le paquet... peut-on sniffer l'activité du noyau...?
D'abord en arrêtant de quoter comme un goret.
http://www.giromini.org/usenet-fr/repondre.html
Si Snort Inline te remonte des alertes, alors il voit les paquets, mais ne les traite pas comme des erreurs, ce qui pose un problème évidemment. Cela vient probablement du fait (RTFM) que tu n'a pas mis en place les drop-rules (commencent par "drop"), c'est à dire les règles qui jettent les paquets, mais que tu as celle de base qui ne font que générer des alertes (commencent par "alert").
Dans le répertoire des sources de Snort Inline, tu as plusieurs répertoires avec les jeux de règles adhoc :
. rules pour les règles Snort classiques . replace-rules pour les règles visant à modifier des paquets . drop-rules pour les règles visant à droper un paquet (cf. DROP) . reject-rules pour les règles visant à rejeter un paquet (cf. REJECT)
Pour être sûr du jeu de règles utilisé, tu regardes la variable RULE_PATH dans le snort_inline.conf et tu vérifies que ça envoie bien sur les drop-rules.
-- Je suis en train de me tater (pas devant tout le monde bien sur) sur la passage a testing au lieu de stable. -+- WM sur debian-french: "masturbation mentale d'une queue de cerise" -+-
j3CubL4H
merci pour ta réponse Cédric. en effet, j'ai vu tous ces fichiers . j'ai pris un fichier d'alerte standard et j'ai fait un cat | sed dessus pour remplacer alert par drop un peu à la manière du fichier convert.sh car comme j'ai (RTFM).. j'ai vu que les fichiers drop servaient dans une config honeypot et qu'il fallait donc tout inverser certaines choses dedans..
à présent tout semble correct, snort-inline envoie des alertes, mais iptables quant à lui reste silencieux.... est-ce normal ? par contre, du côté du apache que je titille , le log accèss ne me donne rien...ce qui tend à prouver que iptables bloque bien....
donc tout semble OK non..? tu vois que j'ai un peu lu le manuel...
merci pour votre aide à tous.
JM et son IE pas à jour...
"Cedric Blancher" a écrit dans le message de news:
comment puis-je voir si le noyau traite ou pas le paquet... peut-on sniffer l'activité du noyau...?
D'abord en arrêtant de quoter comme un goret.
http://www.giromini.org/usenet-fr/repondre.html
Si Snort Inline te remonte des alertes, alors il voit les paquets, mais ne les traite pas comme des erreurs, ce qui pose un problème évidemment. Cela vient probablement du fait (RTFM) que tu n'a pas mis en place les drop-rules (commencent par "drop"), c'est à dire les règles qui jettent les paquets, mais que tu as celle de base qui ne font que générer des alertes (commencent par "alert").
Dans le répertoire des sources de Snort Inline, tu as plusieurs répertoires avec les jeux de règles adhoc :
. rules pour les règles Snort classiques . replace-rules pour les règles visant à modifier des paquets . drop-rules pour les règles visant à droper un paquet (cf. DROP) . reject-rules pour les règles visant à rejeter un paquet (cf. REJECT)
Pour être sûr du jeu de règles utilisé, tu regardes la variable RULE_PATH dans le snort_inline.conf et tu vérifies que ça envoie bien sur les drop-rules.
-- Je suis en train de me tater (pas devant tout le monde bien sur) sur la passage a testing au lieu de stable. -+- WM sur debian-french: "masturbation mentale d'une queue de cerise" -+-
merci pour ta réponse Cédric.
en effet, j'ai vu tous ces fichiers .
j'ai pris un fichier d'alerte standard et j'ai fait un cat | sed dessus pour
remplacer alert par drop un peu à la manière du fichier convert.sh
car comme j'ai (RTFM).. j'ai vu que les fichiers drop servaient dans une
config honeypot et qu'il fallait donc tout inverser certaines choses
dedans..
à présent tout semble correct, snort-inline envoie des alertes, mais
iptables quant à lui reste silencieux....
est-ce normal ?
par contre, du côté du apache que je titille , le log accèss ne me donne
rien...ce qui tend à prouver que iptables bloque bien....
donc tout semble OK non..?
tu vois que j'ai un peu lu le manuel...
merci pour votre aide à tous.
JM et son IE pas à jour...
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news: pan.2004.05.18.08.23.10.291952@cartel-securite.fr...
comment puis-je voir si le noyau traite ou pas le paquet...
peut-on sniffer l'activité du noyau...?
D'abord en arrêtant de quoter comme un goret.
http://www.giromini.org/usenet-fr/repondre.html
Si Snort Inline te remonte des alertes, alors il voit les paquets, mais
ne les traite pas comme des erreurs, ce qui pose un problème évidemment.
Cela vient probablement du fait (RTFM) que tu n'a pas mis en place les
drop-rules (commencent par "drop"), c'est à dire les règles qui jettent
les paquets, mais que tu as celle de base qui ne font que générer des
alertes (commencent par "alert").
Dans le répertoire des sources de Snort Inline, tu as plusieurs
répertoires avec les jeux de règles adhoc :
. rules pour les règles Snort classiques
. replace-rules pour les règles visant à modifier des paquets
. drop-rules pour les règles visant à droper un paquet (cf. DROP)
. reject-rules pour les règles visant à rejeter un paquet (cf. REJECT)
Pour être sûr du jeu de règles utilisé, tu regardes la variable
RULE_PATH dans le snort_inline.conf et tu vérifies que ça envoie bien
sur les drop-rules.
--
Je suis en train de me tater (pas devant tout le monde bien sur) sur la
passage a testing au lieu de stable.
-+- WM sur debian-french: "masturbation mentale d'une queue de
cerise" -+-
merci pour ta réponse Cédric. en effet, j'ai vu tous ces fichiers . j'ai pris un fichier d'alerte standard et j'ai fait un cat | sed dessus pour remplacer alert par drop un peu à la manière du fichier convert.sh car comme j'ai (RTFM).. j'ai vu que les fichiers drop servaient dans une config honeypot et qu'il fallait donc tout inverser certaines choses dedans..
à présent tout semble correct, snort-inline envoie des alertes, mais iptables quant à lui reste silencieux.... est-ce normal ? par contre, du côté du apache que je titille , le log accèss ne me donne rien...ce qui tend à prouver que iptables bloque bien....
donc tout semble OK non..? tu vois que j'ai un peu lu le manuel...
merci pour votre aide à tous.
JM et son IE pas à jour...
"Cedric Blancher" a écrit dans le message de news:
comment puis-je voir si le noyau traite ou pas le paquet... peut-on sniffer l'activité du noyau...?
D'abord en arrêtant de quoter comme un goret.
http://www.giromini.org/usenet-fr/repondre.html
Si Snort Inline te remonte des alertes, alors il voit les paquets, mais ne les traite pas comme des erreurs, ce qui pose un problème évidemment. Cela vient probablement du fait (RTFM) que tu n'a pas mis en place les drop-rules (commencent par "drop"), c'est à dire les règles qui jettent les paquets, mais que tu as celle de base qui ne font que générer des alertes (commencent par "alert").
Dans le répertoire des sources de Snort Inline, tu as plusieurs répertoires avec les jeux de règles adhoc :
. rules pour les règles Snort classiques . replace-rules pour les règles visant à modifier des paquets . drop-rules pour les règles visant à droper un paquet (cf. DROP) . reject-rules pour les règles visant à rejeter un paquet (cf. REJECT)
Pour être sûr du jeu de règles utilisé, tu regardes la variable RULE_PATH dans le snort_inline.conf et tu vérifies que ça envoie bien sur les drop-rules.
-- Je suis en train de me tater (pas devant tout le monde bien sur) sur la passage a testing au lieu de stable. -+- WM sur debian-french: "masturbation mentale d'une queue de cerise" -+-
Cedric Blancher
Le Tue, 18 May 2004 10:14:29 +0000, j3CubL4H a écrit :
à présent tout semble correct, snort-inline envoie des alertes, mais iptables quant à lui reste silencieux....
Qu'est-ce que tu veux qu'il te dise Netfilter ? Une fois qu'il a envoyé le paquet à Snort, il a fini son job, jusqu'à ce que Snort lui dise de le jeter ou de le laisser passer. Si tu veux, c'est un peu comme si tu avais une règle dont la cible changerait selon ce qu'en dirait Snort. Netfilter te dira la même chose que ce qu'il aurait dit si tu avais eu la même règle avec un DROP au lieu d'un QUEUE, ou un ACCEPT dans le cas d'un paquet valide.
par contre, du côté du apache que je titille , le log accèss ne me donne rien...ce qui tend à prouver que iptables bloque bien....
Donc ça marche alors.
--
Je n'arrive pas à lancer refexion x de mon poste windows sur mon serveur Linux. Y a t'il qqe chose de particulier à configurer coté Linux T'arrives pas à lancer Reflexion X ? Quelle bite !
-+- MK in Guide du Fmblien Assassin : "X ? C'est classé !" -+-
Le Tue, 18 May 2004 10:14:29 +0000, j3CubL4H a écrit :
à présent tout semble correct, snort-inline envoie des alertes, mais
iptables quant à lui reste silencieux....
Qu'est-ce que tu veux qu'il te dise Netfilter ? Une fois qu'il a envoyé
le paquet à Snort, il a fini son job, jusqu'à ce que Snort lui dise de
le jeter ou de le laisser passer.
Si tu veux, c'est un peu comme si tu avais une règle dont la cible
changerait selon ce qu'en dirait Snort. Netfilter te dira la même chose
que ce qu'il aurait dit si tu avais eu la même règle avec un DROP au
lieu d'un QUEUE, ou un ACCEPT dans le cas d'un paquet valide.
par contre, du côté du apache que je titille , le log accèss ne me
donne rien...ce qui tend à prouver que iptables bloque bien....
Donc ça marche alors.
--
Je n'arrive pas à lancer refexion x de mon poste windows sur mon serveur
Linux. Y a t'il qqe chose de particulier à configurer coté Linux
T'arrives pas à lancer Reflexion X ? Quelle bite !
-+- MK in Guide du Fmblien Assassin : "X ? C'est classé !" -+-
Le Tue, 18 May 2004 10:14:29 +0000, j3CubL4H a écrit :
à présent tout semble correct, snort-inline envoie des alertes, mais iptables quant à lui reste silencieux....
Qu'est-ce que tu veux qu'il te dise Netfilter ? Une fois qu'il a envoyé le paquet à Snort, il a fini son job, jusqu'à ce que Snort lui dise de le jeter ou de le laisser passer. Si tu veux, c'est un peu comme si tu avais une règle dont la cible changerait selon ce qu'en dirait Snort. Netfilter te dira la même chose que ce qu'il aurait dit si tu avais eu la même règle avec un DROP au lieu d'un QUEUE, ou un ACCEPT dans le cas d'un paquet valide.
par contre, du côté du apache que je titille , le log accèss ne me donne rien...ce qui tend à prouver que iptables bloque bien....
Donc ça marche alors.
--
Je n'arrive pas à lancer refexion x de mon poste windows sur mon serveur Linux. Y a t'il qqe chose de particulier à configurer coté Linux T'arrives pas à lancer Reflexion X ? Quelle bite !
-+- MK in Guide du Fmblien Assassin : "X ? C'est classé !" -+-
