Tu me pose une colle…
Je n’en sais rien… je pense que c’est le mode par défaut quand le forwarding est activé.
Je me souviens en effet avoir vu dans les logs des messages de ce genre (entering et leaving promiscuous mode…)…
Mais comme ma passerelle est sous pfSense maintenant je ne peux pas vérifier…
En admettant qu’on puisse (d’ailleurs je ne vois pas pourquoi on ne pourrait pas), si j’ai des machines A, B et C derrière mon switch, si ma machine A veut communiquer avec la C, est-ce que je verrai l’intégralité de ce trafic au niveau de mon serveur ?
merci 
Grosso modo, il y a deux approches :
L’inconvénient du routeur, c’est qu’il segmente le réseau en deux (donc nécessité de définir deux sous-réseaux IP distincts de chaque côté, et reconfiguration des équipements voisins d’un côté au moins. Inversement le pont est transparent au niveau IP pour les équipements voisins.
Sans la coopération volontaire ou involontaire du switch, non.
C’est quoi, le “serveur” ? La machine B ?
Bah voilà… 
Oui je n’avais pas pensé au bridging…
J’allais dire non à la question précédente, ça passe par le switch (et si c’est un matériel passif, je ne crois pas qu’il y ait de possibilité de “capter” les paquets).
Bon, le maladroit cède volontier la place…
Je n’ai pas écrit que tu étais maladroit !
Le côté maladroit de ta réponse, c’est les règles iptables qui selon le contexte ne sont pas forcément nécessaires (notamment le masquerading) ni suffisantes (renumérotation d’un des sous-réseaux et possible ajout de routes en plus).
Le serveur est en fait ce projet sur lequel j’ai déjà écrit : un serveur d’écoute (snort, tcpdump, etc…).
Je voudrais pouvoir poser ma tour entre mon firewall et mon switch et trouver un moyen d’être capable d’écouter ce qui passe même derrière le switch (par exemple ici entre ma machine A et C).
Le problème que je rencontre dans mon dispositif, c’est que le switch ne va transmettre que de la machine A vers la C, le port du switch sur lequel sera connecté mon serveur d’écoute ne verra pas ce trafic…
J’ai beau retourner le problème dans tous les sens, je vois pas comment faire autrement qu’en activant le port mirroring sur le switch, malheureusement, c’est ma principale contrainte : Je dois pouvoir être capable d’écouter tout ce qui passe sur mon vlan sans avoir à toucher à la configuration du switch. Contrainte client oblige…
Je dois arriver avec mon petit serveur d’écoute, et être capable de me poser sur le réseau switché, d’en écouter l’intégralité, sans avoir à toucher à la conf du switch. Sachant que j’ai 3 interfaces ethernet sur mon serveur. Est-ce possible ?
edit : j’ai chopé ce schéma sur le site de snort, mais dans le schéma présent, je ne vois pas comment Snort peut voire tout le trafic entre 2 machines.
Tu as bien appréhendé la problématique. Pour intercepter le trafic entre A et C, il faut se placer en coupure entre A et C. Autrement, il y a bien des méthodes à base d’attaque de type ARP spoofing/poisoning (contre les machines à écouter, et qui ne concerne que le trafic IP) ou MAC flooding (contre le switch, qui concerne tout type de trafic), mais les résultats sont aléatoires, autant en terme d’interception que d’effets secondaires sur le réseau.
Autrement dit, sans avoir à toucher à la configuration du switch, il est impossible de faire une écoute propre sur un réseau switché, vous êtes catégorique là-dessus ?
Et en admettant que j’ai accès à un petit hub ? Mettons un hub 6 ports, avec un réseau switché de 3 machines (soyons fou…), il faudrait que je mette toute mes machines sur le hub, que je mette également un port de mon snort et que je branche ensuite le hub sur un des ports du switch. Là ça marcherait certainement.
Le problème est que c’est pas 3 machines que j’ai à écouter, mais 10 fois plus par réseau, au bas mot…
Aucune autre idée ?
Sans port miroir sur le switch, je ne vois pas comment ce serait théoriquement possible.
Quant à l’idée d’intercaler un hub, autant utiliser à la place un switch avec port miroir, ce sera bien meilleur pour les performances.
Quant à l’idée d’intercaler un hub, autant utiliser à la place un switch avec port miroir, ce sera bien meilleur pour les performances.[/quote]
Dans le cas où on ne voudrait capturer que le trafic d’une machine, là port mirroring du port de cette machine vers le port de mon snort. Je ne maitrise pas bien le port mirroring et part du principe qu’on réplique l’activité d’un seul port vers un autre. Maintenant si on peut répliquer l’activité d’un groupe de port vers un seul port, ton idée me plait bien, car l’idée est de pouvoir détecter toute activité suspecte sur un ensemble de machines.
Après j’ai réfléchie à la solution du bridging, dont tu me parlais plus haut et qui se rapproche de l’idée d’origine. Finalement je me plaignais qu’avec cette solution je ne pouvais pas voire l’activité d’une machine A vers une machine C, mais après, c’est pas forcément grave dans la mesure où on veut surveiller toute activité suspecte venant de l’extérieur du réseau vers l’intérieur. Un ver ou botnet sera visible dans ce cas là, vu qu’il générera du trafic entre ma machine A et internet, non ? En revanche, s’il y a du trafic suspect de la machine A et vers la C (cas peu probable quand même), je ne le verrai pas.
Ma priorité et mon besoin est avant tout là : détecter un trafic suspect qui transite entre mon LAN et le WAN. La solution du bridging est donc bonne. Corrige moi si j’ai faux dans ma logique.
On peut répliquer plusieurs ports vers un seul port, comme décrit sur la page en anglais de Wikipedia consacrée au port mirroring. Cela peut dépendre des modèles de commutateurs.
Une sonde située en coupure entre internet et le LAN verra forcément tout le trafic des machines avec internet (sauf accès internet parallèle via wifi/hotspot, modem 3G ou autre).
Quant au trafic suspect entre machines du LAN, il ne faut pas oublier que certains vers ou virus se font une spécialité d’attaquer en premier leur voisinage direct.
L’attaque et la propagation se font en quelques minutes, voire quelques secondes.
Une analyse humaine des logs est bien trop lente pour stopper ce type de propagation, et une analyse automatique efficace est extrêmement complexe à mettre en place (les créateurs de malware sont très imaginatifs).
Pour le trafic WAN-LAN suspect, comment compte tu le détecter ?
Si tu as plusieurs dizaines de machines sur ton LAN, ça risque de faire un quantité phénoménale de données à traiter.
A moins de mettre en place un truc du style “tout ce qui n’est pas autorisé est interdit”, la mise en place de la détection automatique d’un trafic suspect peut faire l’objet de plusieurs sujets de thèse!
Sans oublier l’aspect légal …
unixgarden.com/index.php/sec … formatique
unixgarden.com/index.php/sec … age-reseau
Re,
Je ne vois pas trop l’intérêt de sniffer les paquets entre des machines de ton propre réseau.
Chaque machine est protégée par un pare feu, les utilisateurs sont connus…
Comme le dit piratebab c’est une masse d’info colossale à traiter… Y’a intérêt d’avoir un /var/log conséquent…
Il suffit généralement de surveiller le trafic “Wan to Lan” (c’est déjà pas mal…); Éventuellement filtrer “Lan to Wan” s’il y a des restrictions à appliquer et/ou s’assurer que des machines du Lan ne soient pas infectées par des bots/spywares/malwares qui font des accès au net…
En fait, je comptais sur Snort pour analyser ça. Un ver lambda va se propager comment ? En scannant par exemple des range d’ip ? Donc ma machine infectée A, va peut-être d’abord scanner d’autres machines autour d’elles, mais après, elle va chercher à scanner des range ip sur internet, et ça, Snort le verra.
Dans l’autre sens aussi, des requête X ou Y mal formées (pour tout type d’attaque) venant de l’extérieur seront également vues par Snort.
Là, il faut jouer avec la conf de snort, bien mettre à jour la base de signature etc… et systématiquement ça ressort dans les logs. J’avais fait quelques tests avec un snort virtualisé sur un vlan qu’avec des machines virtuelles. J’avais virtualisé un pont et je voyais toutes les VM qui étaient derrière ce pont, mon Snort compris, et après quelques tests depuis une machine exterieur au hub, toutes mes tentatives (ou presque) étaient vues par Snort. De tentatives que je n’aurais pas pu voire rien qu’en analysant du log brut.
J’utilise snort sur ma passerelle (sous pfSense).
Côté Wan, les alertes sont à 99% dues à des scans de port, les attaques sous d’autres formes sont extrêmement rares - enfin celles que je détecte… 
Pour ce qui est du Lan, j’ai eu à faire une fois à un spambot, que snort n’a pas repéré… Mais je n’ai pas beaucoup de machines non plus (les grands jours 25/30 - dont 10 sous Linux…).
L’idée de mon truc là, c’est d’intervenir avec une petite station portable quand justement j’ai un client (d’où ma contrainte de ne pas avoir à toucher à la conf du FW/passerelle ou au switch) qui me relève des problèmes de débits/bande passante, qui sont inexpliqués. Je ne veux pas faire du monitoring snort comme ça pour le plaisir Cette intervention s’inscrit dans un processus qui commence d’abord par la détection d’une anomalie quant aux performances du réseau.
Pas évident ton histoire. Si ce n’est pas un bot mais un humain que ralenti le réseau d’une manière ou d’une autre (P2P, youtube, téléchargement de shareware…), tu va avoir du mal si la surveillance n’est pas permanente…
On en vient à ce que je disais au début. Cela à du sens lorsqu’on suspecte quelque chose, et qu’on sait déja à peu prêt ce qu’on cherche.
Dans ce cas je préfère analyser des captures wiresharck à froid.
Pour le P2P, je pense qu’il doit y avoir une signature de trafic dans Snort, au pire ça se paramètre assez facilement. Pour le reste, youtube & co, là effectivement Snort est inefficace et rien d’autre qu’un contrôle poste par poste pourra faire ce travail. Ce cas est quand même hautement improbable dans la mesure où quand on fait appel à ce service, ces causes sont déjà éliminées.
Des simples stats sur les paquets (IP,port origine et IP,port destination) permettent en général d’avoir une idée du pbm et du coupable. Ensuite tu peux faire une écoute ciblée.
