| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] XenAccess Library: Introspection for Xen
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home