Hi all, From another post on this list, it seems that the only way to monitor all traffic to guests in a host is to bind to the peth interface that is bound to the bridge that serves the guests. Is this the only way of doing it? Ideally, I''d like to have one guest running Snort that monitors everything else. I''ve tried using tcpdump to monitor traffic on various interfaces, but I''ve never had a completely satisfactory result. On guest interfaces, I can only see traffic for that guest (this seems to be a feature); on Dom0 I get a long pause (10-20s), then I start to see packets. Also, with the Dom0 monitoring, I can only seem to see traffic on the peth interface. Binding to vif0.0 gives me nothing interesting. At the moment, I''m researching the use of tc (traffic control) to mirror traffic to another device to get the effect of a monitor port on the xen-bridge. Any help on this would be very appreciated. Mark C. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Chandler wrote:> Hi all, > > From another post on this list, it seems that the only way to monitor > all traffic to guests in a host is to bind to the peth interface that > is bound to the bridge that serves the guests. Is this the only way of > doing it? Ideally, I''d like to have one guest running Snort that > monitors everything else.ebtables is probably your friend. Something like ebtables -t broute -A BROUTING -s <dom0 MAC> -j ACCEPT ebtables -t broute -A BROUTING -d <dom0 MAC> -j ACCEPT ebtables -t broute -A BROUTING -s <domU MAC> -j ACCEPT ebtables -t broute -A BROUTING -d <domU MAC> -j ACCEPT ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp -j dnat --to-dst <domU MAC> --dnat-target ACCEPT Where <domU MAC> is the MAC address of the guest you want to run snort on. The first four rules ensure that traffic from dom0 and the monitoring domU pass unimpeded through the bridge, the last rule redirects all traffic TCP traffic to or from any other guest through the monitoring domU. Of course, it doesn''t have to be a domU on this machine, it can be any machine, virtual or otherwise, on the LAN since you''re just redirecting traffic at the layer 2 level. You''ll probably want to do more with the last rule as well, as you''ll probably want some (or all) UDP traffic redirected to the monitor but you might want to draw the line at ICMP, ARP and Appletalk :-) jch _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John Haxby wrote:> Mark Chandler wrote: >> Hi all, >> >> From another post on this list, it seems that the only way to monitor >> all traffic to guests in a host is to bind to the peth interface that >> is bound to the bridge that serves the guests. Is this the only way >> of doing it? Ideally, I''d like to have one guest running Snort that >> monitors everything else. > ebtables is probably your friend. Something like > > ebtables -t broute -A BROUTING -s <dom0 MAC> -j ACCEPT > ebtables -t broute -A BROUTING -d <dom0 MAC> -j ACCEPT > ebtables -t broute -A BROUTING -s <domU MAC> -j ACCEPT > ebtables -t broute -A BROUTING -d <domU MAC> -j ACCEPT > ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp -j dnat > --to-dst <domU MAC> --dnat-target ACCEPT > > Where <domU MAC> is the MAC address of the guest you want to run snort > on. The first four rules ensure that traffic from dom0 and the > monitoring domU pass unimpeded through the bridge, the last rule > redirects all traffic TCP traffic to or from any other guest through > the monitoring domU. > > Of course, it doesn''t have to be a domU on this machine, it can be any > machine, virtual or otherwise, on the LAN since you''re just > redirecting traffic at the layer 2 level. You''ll probably want to do > more with the last rule as well, as you''ll probably want some (or all) > UDP traffic redirected to the monitor but you might want to draw the > line at ICMP, ARP and Appletalk :-) > > jch >Many thanks, John. I''ll give that a go. At the very least it''ll be fun to experiment with ebtables! :-) Mark C. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> From another post on this list, it seems that the only way to monitor > all traffic to guests in a host is to bind to the peth interface thatis> bound to the bridge that serves the guests.That will only catch traffic that goes via peth. Anything from DomU to DomU will be missed. That is probably acceptable though if you are only interested in traffic from external to DomU. I don''t think there is an option in the Linux bridge code to have a ''mirror'' port that sees everything, unless maybe you can run snort on the xenbrX interface itself? James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Well, I''m not familiar with SNORT, but you can tcpdump on a bridge interface, so I don''t know why snort wouldn''t work. This should allow you to pick up all traffic that goes across the bridge. -Nick>>> On Tue, Apr 29, 2008 at 6:45 AM, "James Harper" <james.harper@bendigoit.com.au> wrote:> From another post on this list, it seems that the only way to monitor > all traffic to guests in a host is to bind to the peth interface thatis> bound to the bridge that serves the guests.That will only catch traffic that goes via peth. Anything from DomU to DomU will be missed. That is probably acceptable though if you are only interested in traffic from external to DomU. I don''t think there is an option in the Linux bridge code to have a ''mirror'' port that sees everything, unless maybe you can run snort on the xenbrX interface itself? James This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users