Je reviens à l'assaut, désolé d'être bête et discipliné, après la
lecture de http://www.certa.ssi.gouv.fr/site/CERTA-2002-INF-002/index.html
je veux installer un ids selon le shéma suivant. Mes moyens étant
limités, je n'ai pas la possibilé d'avoir une appliance en parefeu, elle
sera remplacée par un routeur avec FW SPI, selon ce shéma donc:
http://www.winsnort.com/data/images/ids.gif
Ma question 1 donc:
Que dois-je mettre comme matériel faisant slave sensor ?
Dans une autre discussion (sur fcre) on m'a parlé de hub ethernet, mais
difficile à trouver parait-il. Est-ce celà?:
<http://www.actn.fr/productlistgen.php?tsearch=FAMSEARCH&CAT=RE&FAM=004&SFA=001>
Ma question 2:
Pour l'utilisation de TCPDump, l'installer ainsi convient-il ?
BoxADSL --- PC + TCPDump --- Routeur --- Lan
Ma question 3:
J'ai une sortie DMZ sur mon routeur FW SPI, où je peux mettre un PC avec
un server WEB, FTP, etc, et bien sûr Snort. Est-ce que la totalité du
trafic envoyé vers mon IP va-t-il être reçu par ce PC ? Ou seulement
tout le trafic qui n'a pas été initié par 1 des PC de mon Lan ?
Comme vous le voyez je patauge, mais je veux comprendre/apprendre, et
n'hésitez pas à me reprendre si les termes que j'emploie ne sont pas
appropriés.
Merci pour vos éclaircissement éventuels.
--
Steph
Enlever l'.adressebidon.invalid pour m'écrire en privé
Quand un membre de la "core team" de Netfilter écrit "it's gone now", c'est que c'est vraiment parti. :-)
C'est clair que ça justifie sa disparition du pom, mais ils auraient pu le laisser en sources.list,
N'importe qui peut reprendre le patch à son compte et demander à ce qu'il soit ajouté au sources.list. C'est ce qui s'est passé pour les patches sortis du pom qui y sont listés.
ça ne fait pas de mal parfois les quicks&dirty tricks : quand tu veux juster tester un truc pendant un temps court et que ça prendrait trois plombes à faire proprement Remarque c'est comme ça en général que ça dégénère, quand le bidule bien cracra est finalement utile et finit par rester
Et après on finit par oublier et un jour on se demande pourquoi des paquets sont routés d'une certaine façon alors que rien dans les tables et règles de routage ne l'explique. Ou bien on modifie lesdites tables et règles de routage mais certains paquets y échappent mystérieusement.
ROUTE et TEE ont néanmoins un inconvénient : comme ils interviennent dans la couche réseau, ils ne prennent en compte que les paquets IPv4 et ne préservent pas les adresses MAC. Et si le suivi de connexion s'en mêle, la fragmentation n'est pas préservée non plus. Il faut voir si c'est gênant ou pas pour l'OP.
Au temps pour moi, l'OP parlait de mettre snort après le routeur, et dans ce cas effectivement il faut redescendre au moins d'un niveau s'il veut voir les trames ethernet passer.
Faut voir si c'est vraiment utile de voir les trames ethernet et pas seulement les paquets IP. Si j'ai bien compris, l'OP souhaite mettre une sonde entre une FAIbox ADSL et un routeur. Dans ce cas, sauf box en bridge avec PPPoE, les seules adresses MAC qu'on voit passer sont celles de la FAIbox et du routeur, donc pas forcément intéressant. D'autre part dans un environnement qui utilise seulement IP(v4), les seules trames ethernet non IP en jeu sont les trames ARP, et là encore sur le segment entre la FAIbox et le routeur ça a peu d'intérêt. Enfin si la FAIbox et le routeur font du NAT, ils font déjà le réassemblage des fragments, donc plus la peine de se préoccuper de préserver la fragmentation.
Cepandant toutes ces remarques deviennent caduques si la FAIbox fait du wifi.
Glups. Ca c'est du nettoyage.
Quand un membre de la "core team" de Netfilter écrit "it's gone now",
c'est que c'est vraiment parti. :-)
C'est clair que ça justifie sa disparition du pom, mais ils auraient pu
le laisser en sources.list,
N'importe qui peut reprendre le patch à son compte et demander à ce
qu'il soit ajouté au sources.list. C'est ce qui s'est passé pour les
patches sortis du pom qui y sont listés.
ça ne fait pas de mal parfois les
quicks&dirty tricks : quand tu veux juster tester un truc pendant un
temps court et que ça prendrait trois plombes à faire proprement
Remarque c'est comme ça en général que ça dégénère, quand le
bidule bien cracra est finalement utile et finit par rester
Et après on finit par oublier et un jour on se demande pourquoi des
paquets sont routés d'une certaine façon alors que rien dans les tables
et règles de routage ne l'explique. Ou bien on modifie lesdites tables
et règles de routage mais certains paquets y échappent mystérieusement.
ROUTE et TEE ont néanmoins un inconvénient : comme ils interviennent
dans la couche réseau, ils ne prennent en compte que les paquets IPv4 et
ne préservent pas les adresses MAC. Et si le suivi de connexion s'en
mêle, la fragmentation n'est pas préservée non plus. Il faut voir si
c'est gênant ou pas pour l'OP.
Au temps pour moi, l'OP parlait de mettre snort après le routeur, et dans
ce cas effectivement il faut redescendre au moins d'un niveau s'il veut
voir les trames ethernet passer.
Faut voir si c'est vraiment utile de voir les trames ethernet et pas
seulement les paquets IP. Si j'ai bien compris, l'OP souhaite mettre une
sonde entre une FAIbox ADSL et un routeur. Dans ce cas, sauf box en
bridge avec PPPoE, les seules adresses MAC qu'on voit passer sont celles
de la FAIbox et du routeur, donc pas forcément intéressant. D'autre part
dans un environnement qui utilise seulement IP(v4), les seules trames
ethernet non IP en jeu sont les trames ARP, et là encore sur le segment
entre la FAIbox et le routeur ça a peu d'intérêt. Enfin si la FAIbox et
le routeur font du NAT, ils font déjà le réassemblage des fragments,
donc plus la peine de se préoccuper de préserver la fragmentation.
Cepandant toutes ces remarques deviennent caduques si la FAIbox fait du
wifi.
Quand un membre de la "core team" de Netfilter écrit "it's gone now", c'est que c'est vraiment parti. :-)
C'est clair que ça justifie sa disparition du pom, mais ils auraient pu le laisser en sources.list,
N'importe qui peut reprendre le patch à son compte et demander à ce qu'il soit ajouté au sources.list. C'est ce qui s'est passé pour les patches sortis du pom qui y sont listés.
ça ne fait pas de mal parfois les quicks&dirty tricks : quand tu veux juster tester un truc pendant un temps court et que ça prendrait trois plombes à faire proprement Remarque c'est comme ça en général que ça dégénère, quand le bidule bien cracra est finalement utile et finit par rester
Et après on finit par oublier et un jour on se demande pourquoi des paquets sont routés d'une certaine façon alors que rien dans les tables et règles de routage ne l'explique. Ou bien on modifie lesdites tables et règles de routage mais certains paquets y échappent mystérieusement.
ROUTE et TEE ont néanmoins un inconvénient : comme ils interviennent dans la couche réseau, ils ne prennent en compte que les paquets IPv4 et ne préservent pas les adresses MAC. Et si le suivi de connexion s'en mêle, la fragmentation n'est pas préservée non plus. Il faut voir si c'est gênant ou pas pour l'OP.
Au temps pour moi, l'OP parlait de mettre snort après le routeur, et dans ce cas effectivement il faut redescendre au moins d'un niveau s'il veut voir les trames ethernet passer.
Faut voir si c'est vraiment utile de voir les trames ethernet et pas seulement les paquets IP. Si j'ai bien compris, l'OP souhaite mettre une sonde entre une FAIbox ADSL et un routeur. Dans ce cas, sauf box en bridge avec PPPoE, les seules adresses MAC qu'on voit passer sont celles de la FAIbox et du routeur, donc pas forcément intéressant. D'autre part dans un environnement qui utilise seulement IP(v4), les seules trames ethernet non IP en jeu sont les trames ARP, et là encore sur le segment entre la FAIbox et le routeur ça a peu d'intérêt. Enfin si la FAIbox et le routeur font du NAT, ils font déjà le réassemblage des fragments, donc plus la peine de se préoccuper de préserver la fragmentation.
Cepandant toutes ces remarques deviennent caduques si la FAIbox fait du wifi.
Pascal Hambourg
Tu ne m'as visiblement jamais vu souder! Tu sais les gros pâtés qui portent en plus le doux nom de soudures sèches ;) Bon, la pince à sertir ça va mieux quand même.
Il existe des embases RJ45 auto-dénudantes ne nécessitant ni pince ni fer à souder. En plus les couleurs des fils sont même marquées dessus.
Tu ne m'as visiblement jamais vu souder!
Tu sais les gros pâtés qui portent en plus le doux nom de soudures
sèches ;)
Bon, la pince à sertir ça va mieux quand même.
Il existe des embases RJ45 auto-dénudantes ne nécessitant ni pince ni
fer à souder. En plus les couleurs des fils sont même marquées dessus.
Tu ne m'as visiblement jamais vu souder! Tu sais les gros pâtés qui portent en plus le doux nom de soudures sèches ;) Bon, la pince à sertir ça va mieux quand même.
Il existe des embases RJ45 auto-dénudantes ne nécessitant ni pince ni fer à souder. En plus les couleurs des fils sont même marquées dessus.
