Snort + Xen

Support Debian
#1

Hello,

Voici ma conf :

[quote]eth0 Link encap:Ethernet HWaddr 00:16:3e:ed:6e:3b
inet addr:10.0.128.116 Bcast:10.0.128.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:feed:6e3b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10544 errors:0 dropped:0 overruns:0 frame:0
TX packets:4176 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:887739 (866.9 KiB) TX bytes:731721 (714.5 KiB)[/quote]

[quote]
Linux virt-1128-116 2.6.26-2-xen-686 #1 SMP Fri Sep 17 00:54:08 UTC 2010 i686 GNU/Linux[/quote] (oui, c’est du virtualisé, peut être que ça vient de là ?)

Et snort se lance ainsi :

Dans BASE, je vois tout ce qui ressemble de près ou de loin à une attaque dirigée vers la machine sur laquelle est SNORT, j’ai vu également 2 petites requêtes ping d’une adresse exterieur vers 2 machines virtualisées, mais c’est tout.

Quand je fais un scan depuis mon poste vers un autre poste physique sur le même réseau, SNORT ne voit rien.

Pouvez-vous m’aider ?

#2

Snort ne peut voir que les paquets qui arrivent sur l’interface sur laquelle il écoute.
Les switches et autres ponts aiguillent les trames uniquement sur les ports concernés. Par conséquent dans un environnement ethernet commuté classique, une interface reçoit essentiellement le trafic unicast et multicast qui lui est spécifiquement destiné et le trafic broadcast (ou géré comme tel, comme le multicast si pas géré explicitement).

#3

[quote=“PascalHambourg”]Snort ne peut voir que les paquets qui arrivent sur l’interface sur laquelle il écoute.
Les switches et autres ponts aiguillent les trames uniquement sur les ports concernés. Par conséquent dans un environnement ethernet commuté classique, une interface reçoit essentiellement le trafic unicast et multicast qui lui est spécifiquement destiné et le trafic broadcast (ou géré comme tel, comme le multicast si pas géré explicitement).[/quote]
en fait, sur mon serveur Xen, il y a une interface (eth0) qui est reliée à un port d’un switch qui est en agrégat. J’utilise cette interface dans Xen pour les vlans de mes machines virtuelles, et pour chaque vlan j’ai un bridge.
Donc j’ai ceci : mon switch => eth0 => bridge_du_vlan_concerné => interface_virtuelle_rattachée_au_bridge => eth0 (sur ma machine virtuelle)

Bref, il y a donc pas mal de monde entre l’interface qui écoute et mon switch.

Partant de ce constat, si je comprends bien ce que tu me dis, il est impossible (en l’état), que snort (écoutant derrière eth0 de ma VM) voit le trafic 10.0.128.0/24, tant qu’il s’agit d’un trafic qui ne lui est pas directement destiné ?

/edit : voici les logs dont je parlais :

[quote] #46-(1-14) [snort] ICMP superscan echo 2010-12-07 23:02:21 64.88.168.9 10.0.128.87 ICMP
#47-(1-13) [snort] ICMP superscan echo 2010-12-07 23:02:21 64.88.168.9 10.0.128.87 ICMP[/quote]
Ma VM snort est en 10.0.128.116. Donc rien dans ces logs ne lui était directement concerné, pour snort l’a quand même vu… Une explication ?

#4

En gros, sous un DomU, impossible d’écouter l’ensemble d’un /24, juste le trafic concernant le DomU et rien d’autre ? :017

edit:

Si j’en crois ce qui est dit ici, ça semble quand même possible. Mais impossible de sortir cette commande xe. J’ai un bon vieux xen-3.2-1.

Sinon j’avance à pas de loup… mon peth0 (le eth0 physique de mon serveur xen) est bien en écoute (bon, pas bien dur…), je vois tout le trafic que je veux. Maintenant, il faut que je fasse en sorte que xenbr1128 (mon bridge) le fasse voire à l’interface virtuelle vif53.0 qui pointe vers le eth0 de mon petit DomU.

Help :frowning:

#5

Tu peux essayer la solution proposée, à savoir réduire à 0 le délai d’expiration des adresses MAC dans la table d’apprentissage du pont. Cf. man brctl, option setageingtime, et man bridge-utils-interfaces, option bridge_ageing. Cela devrait plus ou moins se faire comporter comme un simple hub, diffusant tout le trafic reçu par un port vers tous les autres ports sans faire de filtrage en fonction de l’adresse MAC de destination.

#6

J’ai trouvé d’où vient mon problème. Même sur eth1 (donc directement sur l’interface physique utilisée par xen) les trames 8021q sont tronquées, précisément par xen. Du coup, je ne peux ni écouter sur eth1 et encore moins depuis une interface virtuelle.

Comme je l’ai dis dans un autre topic, il me faut trouver comment faire en sorte que Xen laisse intacte les trames 8021q. Et là, en faisant comme tu dis (simulant un hub), ça devrait marcher.

#7

bon, je continue mon monologue…

Voilà où j’en suis :

brctl show =>

eth0 8000.0019b9ebcd29 no peth0
vif58.0
vif7.0
xenbr1128 8000.0019b9ebcd2b no eth1.1128
vif28.0
vif29.0
vif30.0
vif53.0
xenbr1176 8000.0019b9ebcd2b no eth1.1176

donc, mes trames doivent faire ce chemin : eth1 => xenbr1128 (le bridge du vlan concerné) => vif53.0 => eth0 => mon snort virtualisé.

La bonne nouvelle, c’est que toutes mes trames arrivent enfin jusqu’à vif53.0, l’interface virtuelle juste avant celle de ma machine virtuelle. Quand je me place sur mon serveur xen, que j’écoute ce que vif53.0 a à me dire, je vois tout le trafic qui me manquait. Maintenant, il ne me reste plus qu’à l’acheminer correctement jusqu’à eth0 de ma VM. Et c’est là que ça coince, car là où vif53.0 est bavard, eth0 est muet…
Question, quelles sont les différences entre ces 2 interfaces… hormis que l’une est “côté serveur” et l’autre “côté VM” :

[quote]vif53.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff
adr inet6: fe80::fcff:ffff:feff:ffff/64 Scope:Lien
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:71569 errors:0 dropped:0 overruns:0 frame:0
TX packets:533104 errors:0 dropped:4 overruns:0 carrier:0
collisions:0 lg file transmission:32
RX bytes:4829325 (4.6 MiB) TX bytes:64345096 (61.3 MiB)[/quote]

[quote]eth0 Link encap:Ethernet HWaddr 00:16:3e:ed:6e:3b
inet addr:10.0.128.116 Bcast:10.0.128.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:feed:6e3b/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1812 errors:0 dropped:0 overruns:0 frame:0
TX packets:431 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:167717 (163.7 KiB) TX bytes:70570 (68.9 KiB)[/quote]

On voit déjà clairement une différence au niveau du compteur RX… les trames n’arrivent pas jusqu’à Eth0. Pourquoi ?

Hum, l’une a une adresse ip (la eth0) l’autre n’en a pas… Ne faudrait-il pas que je créé sur ma VM une interface virtuelle, sans ip, en promisc, qui me serve justement à récupérer tout le trafic ?
Si mon eth0 a une adresse ip, elle va récupérer tout le trafic lui étant destiné et seulement ce trafic. Si à côté je créé une interface virtuelle (sans ip, comme si elle était physiquement connecté derrière un port en aggrégat de lien) DANS ma machine virtuelle et que j’écoute sur celle-ci, ne devrais-je pas récupérer tout le trafic qu’il me manque ?

SVP, un petit signe là… :017