Re: [Xen-users] XenAccess Library: Introspection for Xen

["Bryan D. Payne" <bryan@xxxxxxxxxxxx>]

> Sounds like a great idea.
Thanks :-)

> I can see this being useful for IDS, for system monitoring, live  
> problem
> diagnosis (e.g. trying to figure out what's going on in a machine  
> that's
> become unresponsive), etc.
>
> Eventually you could extend this with the ability to interpose on  
> disk /
> network IO using the tap drivers (these are a bit out of date at  
> the moment,
> but I understand Andy is intending to work on them again at some  
> point).
Yes, all good ideas.  My primary interest in introspection is in the  
potential for developing new and interesting security applications.   
IDS / monitoring applications, as you mentioned, fit in very nicely  
here.  So do intrusion response applications since you are sitting in  
a powerful position to control and modify the domain in question.
Other uses that I've imagined include system management and  
debugging.  In fact, I've already used it on several occasions for  
simple kernel debugging (e.g., viewing the contents of a kernel data  
structure).  And I'm sure that there's plenty more that I haven't  
thought of yet as well.
> It would be very nice to see Open Source IDS solutions based on  
> this.  Had you
> considered porting an existing in-host IDS to use your  
> introspection library
> to monitor another domain instead?
Yes, I think that this would be great.  My focus right now will be on  
further development of XenAccess.  But, as time permits, I would be  
interested in looking into that and/or supporting others that want to  
use XenAccess for that purpose.
The other thing to consider is non-traditional host-based IDS.   
Through introspection, you need not be limited by the presentation of  
information that you normally get inside the operating system.   
Perhaps viewing memory "through a different lens" could lead to some  
interesting new techniques?  Something to think about.
> Actually, we can achieve several levels of monitoring now if we want:
> 1) IDS within a domain, either or both user and kernelspace.
> 2) IDS based on introspection in another domain on the same system.
> 3) IDS monitoring network traffic, either or both on the same  
> system, or
> another host on the network.
>
> Another thing I've been thinking would be neat is to feed all this  
> data (in
> some standard format) into an IDS aggregator.  I've heard of such  
> things, I
> think, but I don't know what the current state of the art is.  It  
> should be
> possible to get quite accurate pinpointing and diagnosis of both  
> virtualised
> and non-virtualised servers across an enterprise this way.
Indeed.  And, in addition to data aggregation, comparing the data  
from in the host to data from introspection to data on the network  
could lead to some interesting analysis.  For example, what if you  
saw conflicting information about the same system from two sensor  
locations?  Perhaps you just detected stealthy malware?
I'm excited about the possibilities.  Within the XenAccess project,  
I'm looking forward to collecting more data (including the driver  
taps that you mentioned and cpu context information), and adding more  
features such as instruction-level replay of a domain's execution  
environment.  So keep watching and hopefully there will be some more  
interesting stuff coming down the pipe.
Cheers,
bryan


-
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users