Sebek est un outil de capture de données destiné à être mis sur un
/honeypot/ afin de transmettre les activités d'un pirate (méchant, bien
entendu) sur un serveur. Vous pouvez en savoir plus sur la page de
Sebek, justement (la vie est bien faite...) :
http://www.honeynet.org/tools/sebek/
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un
groupe d'étudiant dont je fais partie essaie de porter le client pour
FreeBSD, dans le cadre d'un projet scolaire. Nous aimerions avoir vos
avis, commentaires et critiques à ce sujet, alors si vous êtes
intéressés, n'hésitez pas à le tester.
Vous pouvez trouver le code source du projet, ainsi que notre
documentation, sur la page /tools/ du French Honeynet Project :
http://honeynet.rstack.org/tools.php
Pierre
PS: si vous préférez, vous pouvez nous faire part de vos remarques par mail.
--
Pierre LALET -- Droids Corporation
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
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
MLC
Bonjour ,
"Pierre LALET" a écrit dans le message news: bo9qdo$h3b$
[...]
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un
Il existe un client Solaris également !
groupe d'étudiant dont je fais partie essaie de porter le client pour FreeBSD, dans le cadre d'un projet scolaire. Nous aimerions avoir vos avis, commentaires et critiques à ce sujet, alors si vous êtes intéressés, n'hésitez pas à le tester.
Je viens de lire le doc .pdf contenu dans le paquet .tar.gz, je ne connais rien à FreeBSD et je n'ai pas lu votre code. Par contre, au §4.2 je ne comprends pas vraiment pourquoi vous avez mis en place une fonction de filtrage des paquets ICMP soit disant envoyés par le serveur Sebek (fonction activée par le paramètre FILTER_IN). Si le serveur Sebek est sur le même réseau local switché ou non que le ou les clients Sebek il est recommandé de supprimer la couche IP de l'interface Ethernet du serveur Sebek. Et dans ce cas seule l'adresse MAC destination est utile et il n'y aura pas de paquet ICMP en retour à cause du port UDP qui est en principe fermé sur le serveur. Par contre, si le serveur Sebek ne se trouve pas sur le même réseau Ethernet et qu'il se situe à un ou plusieurs sauts des clients Sebek, dans ce cas les routeurs ou pare-feu intermédiaires peuvent être configurés pour filtrer ces paquets ICMP. Es ce que je me trompe ?
Sinon, le fait d'avoir pensé au MTU et à la fragmentation IP est intéressant !
Marc
Bonjour ,
"Pierre LALET" <lalet@enseirb.fr> a écrit dans le message news:
bo9qdo$h3b$1@news.u-bordeaux.fr...
[...]
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un
Il existe un client Solaris également !
groupe d'étudiant dont je fais partie essaie de porter le client pour
FreeBSD, dans le cadre d'un projet scolaire. Nous aimerions avoir vos
avis, commentaires et critiques à ce sujet, alors si vous êtes
intéressés, n'hésitez pas à le tester.
Je viens de lire le doc .pdf contenu dans le paquet .tar.gz, je ne connais
rien à FreeBSD et je n'ai pas lu votre code. Par contre, au §4.2 je ne
comprends pas vraiment pourquoi vous avez mis en place une fonction de
filtrage des paquets ICMP soit disant envoyés par le serveur Sebek (fonction
activée par le paramètre FILTER_IN).
Si le serveur Sebek est sur le même réseau local switché ou non que le ou
les clients Sebek il est recommandé de supprimer la couche IP de l'interface
Ethernet du serveur Sebek. Et dans ce cas seule l'adresse MAC destination
est utile et il n'y aura pas de paquet ICMP en retour à cause du port UDP
qui est en principe fermé sur le serveur.
Par contre, si le serveur Sebek ne se trouve pas sur le même réseau Ethernet
et qu'il se situe à un ou plusieurs sauts des clients Sebek, dans ce cas les
routeurs ou pare-feu intermédiaires peuvent être configurés pour filtrer ces
paquets ICMP.
Es ce que je me trompe ?
Sinon, le fait d'avoir pensé au MTU et à la fragmentation IP est intéressant
!
"Pierre LALET" a écrit dans le message news: bo9qdo$h3b$
[...]
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un
Il existe un client Solaris également !
groupe d'étudiant dont je fais partie essaie de porter le client pour FreeBSD, dans le cadre d'un projet scolaire. Nous aimerions avoir vos avis, commentaires et critiques à ce sujet, alors si vous êtes intéressés, n'hésitez pas à le tester.
Je viens de lire le doc .pdf contenu dans le paquet .tar.gz, je ne connais rien à FreeBSD et je n'ai pas lu votre code. Par contre, au §4.2 je ne comprends pas vraiment pourquoi vous avez mis en place une fonction de filtrage des paquets ICMP soit disant envoyés par le serveur Sebek (fonction activée par le paramètre FILTER_IN). Si le serveur Sebek est sur le même réseau local switché ou non que le ou les clients Sebek il est recommandé de supprimer la couche IP de l'interface Ethernet du serveur Sebek. Et dans ce cas seule l'adresse MAC destination est utile et il n'y aura pas de paquet ICMP en retour à cause du port UDP qui est en principe fermé sur le serveur. Par contre, si le serveur Sebek ne se trouve pas sur le même réseau Ethernet et qu'il se situe à un ou plusieurs sauts des clients Sebek, dans ce cas les routeurs ou pare-feu intermédiaires peuvent être configurés pour filtrer ces paquets ICMP. Es ce que je me trompe ?
Sinon, le fait d'avoir pensé au MTU et à la fragmentation IP est intéressant !
Marc
Pierre LALET
Bonjour
MLC wrote:
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un Il existe un client Solaris également !
En effet, merci pour cette correction.
Je viens de lire le doc .pdf contenu dans le paquet .tar.gz, je ne connais rien à FreeBSD et je n'ai pas lu votre code. Par contre, au §4.2 je ne comprends pas vraiment pourquoi vous avez mis en place une fonction de filtrage des paquets ICMP soit disant envoyés par le serveur Sebek (fonction activée par le paramètre FILTER_IN). Si le serveur Sebek est sur le même réseau local switché ou non que le ou les clients Sebek il est recommandé de supprimer la couche IP de l'interface Ethernet du serveur Sebek. Et dans ce cas seule l'adresse MAC destination est utile et il n'y aura pas de paquet ICMP en retour à cause du port UDP qui est en principe fermé sur le serveur. Par contre, si le serveur Sebek ne se trouve pas sur le même réseau Ethernet et qu'il se situe à un ou plusieurs sauts des clients Sebek, dans ce cas les routeurs ou pare-feu intermédiaires peuvent être configurés pour filtrer ces paquets ICMP.
Supprimer la couche IP est recommandé, mais pas toujours possible (à titre personnel, je préfère même que la machine serveur ne puisse vraiment pas parler sur un réseau ouvert, comme expliqué dans la documentation). Cette fonction est utile pour le cas où l'utilisateur ne supprime pas la couche IP, ou si on ne maitrise pas les routeurs situés sur le chemin entre le(s) client(s) et le serveur : le paquet Sebek arrivant sur le serveur (la machine) est récupéré par la libpcap et interprété par le serveur (le programme), mais remonte aussi à la couche UDP du système qui, voyant que son port est fermé, renvoie un paquet ICMP pour en avertir l'expéditeur. Et là, c'est le drame.
Es ce que je me trompe ?
En fait, non. Ou plutôt, un peu : il est à mon avis utile de conserver cette possibilité. Par contre, c'est une très bonne idée que de rajouter une option FILTER_IN_ICMP pour laisser l'utilisateur choisir s'il veut ou non l'utiliser. D'ailleurs, ça coute tellement pas cher que je vais le faire tout de suite.
Sinon, le fait d'avoir pensé au MTU et à la fragmentation IP est intéressant !
Merci.
A+
pierre
-- Pierre LALET -- Droids Corporation -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Bonjour
MLC wrote:
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un
Il existe un client Solaris également !
En effet, merci pour cette correction.
Je viens de lire le doc .pdf contenu dans le paquet .tar.gz, je ne connais
rien à FreeBSD et je n'ai pas lu votre code. Par contre, au §4.2 je ne
comprends pas vraiment pourquoi vous avez mis en place une fonction de
filtrage des paquets ICMP soit disant envoyés par le serveur Sebek (fonction
activée par le paramètre FILTER_IN).
Si le serveur Sebek est sur le même réseau local switché ou non que le ou
les clients Sebek il est recommandé de supprimer la couche IP de l'interface
Ethernet du serveur Sebek. Et dans ce cas seule l'adresse MAC destination
est utile et il n'y aura pas de paquet ICMP en retour à cause du port UDP
qui est en principe fermé sur le serveur.
Par contre, si le serveur Sebek ne se trouve pas sur le même réseau Ethernet
et qu'il se situe à un ou plusieurs sauts des clients Sebek, dans ce cas les
routeurs ou pare-feu intermédiaires peuvent être configurés pour filtrer ces
paquets ICMP.
Supprimer la couche IP est recommandé, mais pas toujours possible (à
titre personnel, je préfère même que la machine serveur ne puisse
vraiment pas parler sur un réseau ouvert, comme expliqué dans la
documentation). Cette fonction est utile pour le cas où l'utilisateur ne
supprime pas la couche IP, ou si on ne maitrise pas les routeurs situés
sur le chemin entre le(s) client(s) et le serveur : le paquet Sebek
arrivant sur le serveur (la machine) est récupéré par la libpcap et
interprété par le serveur (le programme), mais remonte aussi à la couche
UDP du système qui, voyant que son port est fermé, renvoie un paquet
ICMP pour en avertir l'expéditeur. Et là, c'est le drame.
Es ce que je me trompe ?
En fait, non. Ou plutôt, un peu : il est à mon avis utile de conserver
cette possibilité. Par contre, c'est une très bonne idée que de rajouter
une option FILTER_IN_ICMP pour laisser l'utilisateur choisir s'il veut
ou non l'utiliser. D'ailleurs, ça coute tellement pas cher que je vais
le faire tout de suite.
Sinon, le fait d'avoir pensé au MTU et à la fragmentation IP est intéressant
!
Merci.
A+
pierre
--
Pierre LALET -- Droids Corporation
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Pour l'instant, seul un serveur et un client Linux sont disponibles. Un Il existe un client Solaris également !
En effet, merci pour cette correction.
Je viens de lire le doc .pdf contenu dans le paquet .tar.gz, je ne connais rien à FreeBSD et je n'ai pas lu votre code. Par contre, au §4.2 je ne comprends pas vraiment pourquoi vous avez mis en place une fonction de filtrage des paquets ICMP soit disant envoyés par le serveur Sebek (fonction activée par le paramètre FILTER_IN). Si le serveur Sebek est sur le même réseau local switché ou non que le ou les clients Sebek il est recommandé de supprimer la couche IP de l'interface Ethernet du serveur Sebek. Et dans ce cas seule l'adresse MAC destination est utile et il n'y aura pas de paquet ICMP en retour à cause du port UDP qui est en principe fermé sur le serveur. Par contre, si le serveur Sebek ne se trouve pas sur le même réseau Ethernet et qu'il se situe à un ou plusieurs sauts des clients Sebek, dans ce cas les routeurs ou pare-feu intermédiaires peuvent être configurés pour filtrer ces paquets ICMP.
Supprimer la couche IP est recommandé, mais pas toujours possible (à titre personnel, je préfère même que la machine serveur ne puisse vraiment pas parler sur un réseau ouvert, comme expliqué dans la documentation). Cette fonction est utile pour le cas où l'utilisateur ne supprime pas la couche IP, ou si on ne maitrise pas les routeurs situés sur le chemin entre le(s) client(s) et le serveur : le paquet Sebek arrivant sur le serveur (la machine) est récupéré par la libpcap et interprété par le serveur (le programme), mais remonte aussi à la couche UDP du système qui, voyant que son port est fermé, renvoie un paquet ICMP pour en avertir l'expéditeur. Et là, c'est le drame.
Es ce que je me trompe ?
En fait, non. Ou plutôt, un peu : il est à mon avis utile de conserver cette possibilité. Par contre, c'est une très bonne idée que de rajouter une option FILTER_IN_ICMP pour laisser l'utilisateur choisir s'il veut ou non l'utiliser. D'ailleurs, ça coute tellement pas cher que je vais le faire tout de suite.
Sinon, le fait d'avoir pensé au MTU et à la fragmentation IP est intéressant !
Merci.
A+
pierre
-- Pierre LALET -- Droids Corporation -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
