[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center

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

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.