WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Help with monitoring outgoing network traffic

To: "Xen Developers" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Help with monitoring outgoing network traffic
From: "raghunathan srinivasan" <raghunathansrinivas@xxxxxxxxx>
Date: Wed, 24 Oct 2007 13:34:35 -0700
Delivery-date: Wed, 24 Oct 2007 13:35:19 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=5Z/d1ub5Zy1WzzhVBIpddNKRwb9QsZt7examh5i5i0c=; b=Yd6yIuDYHLavub+vn4ZevJSlOFno6dhsnxKnO4mz4WhKPgZ0sMknMUmfJ8PW3PtWafJDyd28fizJw1QnsKW9uM75gYGNGP4gmrQ7yQEWqDua4M4AGpP+TnFt/w2ZZt/2cFr7BpKfrKIAG/n1qK1RylX8CfWf8zM/awv0KQzEYVc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RO3lNUengWKFgoBqKu/VstGFdBPjlHqCgD6Y/3vyxhtAjtR8KDXlq7VZPdTSW4YtZzjnR6rNkTppG7YrWMqBfJd0qFh9bafIqdVtRNL07pkMjzkgUQ4tdiXthmGWN5ZL3+M5thmuAs0N4OQk9jHEYupzs0rJG2Xt9E2o7n6HBhg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1193187567.32093.37.camel@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <ef65ab0d0710231703o674539d1sf8abd620cb1d17a9@xxxxxxxxxxxxxx> <1193187567.32093.37.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

thanks for the reply. Actually what I am trying to do is like a firewall yes. I understand that a Linux OS already provides it. I am trying to address a threat model where the host OS can be compromised by rootkits and viruses. And the VMM is not uncompromisable. Basically i want to incorporate basic packet filtering ability inside the VMM. So that even if a rootkit tires to open a backend to a remote machine - so its not really facebook that I am worried about. It cannot do it because the VMM traps that call.

Can someone please help me out on this?

thanks

Raghu

On 10/23/07, Daniel Stodden <stodden@xxxxxxxxxx > wrote:

On Tue, 2007-10-23 at 17:03 -0700, raghunathan srinivasan wrote:

> I saw a folder called drivers\xen\netfront.
> I guess it interacts with the backend driver. Do I make changes in it?

the answers are "yes, ", and "NO."

without the intend to kill all the joy in your venture: what you're
looking for is a customary firewall. with xen, i'd suggest to use linux
to do it. no coding required (except, maybe, tricky stuff in the
facebook-specific aspect, that depends). just grep the web for iptables.

the reason is because xen is not much about networking, as it's not
really about specific classes of devices, including network interfaces.
the VMM itself, as is all xen-specific things inside a linux guest, is
rather about raw resources: cpus, memory, interrupts, and only *very*
basic support in the area of domain intercommunciation.

your network interface is driven by dom0, the initial VM you find in on
the screen once you've booted your system. that is basically a linux
kernel with all the features, including a fairly comprehensive
firewalling solution, which does logging and filtering and part of it
even delegated to userland if you want to code custom tricks in a sane
fashion.

dom0 typically drives your network card. that's (typically) the eth0
device you see in your network setup. all traffic, including any
additional nonprivileged domain, passes dom0.

any other domain X gets a 'netfront' interface ethY, which is
conceptually connected to a 'netback' device vifX.Y via what you may
think of, in network lingo, as a virtual crossover cable:

    dom0: eth0   <-- bridging/nat --> vif1.0 <--- x ---> domU: eth0

the trick is to get the firewall to filter packets as they pass from
eth0 to vifX.Y to the ethY inside the domain you want to restrict -- and
vice versa.
you'll maybe need to learn a little about topics like NAT and/or 802.1d
bridging, depending on your preferred network setup. then check out
network filtering on linux.

neither is a thing to learn about on xen-devel. for the xen-specific
parts of the equation above, i'd suggest to turn to the xen-users list,
as it hosts more people who are dealing with such issues on a regular
basis.

regards,
daniel

--
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B





--
http://www.public.asu.edu/~rsriniv8/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>