From: Yoann V. <yo...@pr...> - 2004-05-05 17:51:37
|
On Mon, 2004-05-03 at 21:09 +0200, DK wrote: [...] Hi, > The main problems I see for an easy integration are: > > - Monitor querys > Querying various ntop/opennms aspects is very important for us and > the correlation directives since they provide very useful input. Theses application could easily send alert to a prelude-manager, throught a script or by modifying the application directly, which don't allow you to query theses applications directly, but at least, you get the ability ti get the latest reported status of theses applications. > - Remote process status > We are able to start/stop, enable/disable plugins from within the > web-ui. The request goes through the server and the agent monitor > processes, stops and starts them and so on. Same as above, plus you should soon have the ability to control a Prelude sensors throught the administrative console (check: http://article.gmane.org/gmane.comp.security.ids.prelude.devel/65/match=administrative) > - P0f & arpwatch integration > It seems prelude p0f integration is a little bit outdated and I'm not > sure how we could get the ip-mac listing. (Prelude NIDS could provide > this but I think arpwatch is a little bit more, err, "lightweight"). I'm not sure what you mean with "ip-mac listing". If it's simply accessing it, it is in the database. > - DB querys > Our agent is able to query various things from remote DBs such as > risk levels, availability status, etc... libpreludedb implement that too... > - Missing agents > There are a couple of agents that would need to be ported to prelude > format because we rely heavily on them too (rrd anomaly, rrd > threshold). > > --- > > Server side problems. > > This is the greatest hurdle I see. Our server already implements a > strong DB integration writing both into ossim's own and acid/snort's > tables. We use a modified version of acid that provides risk, priority, > reliability and asset data and I think that will continue to be our > main event viewing platform. The server is able to log almost every > normalized data input into acid so we use it to show fw-1, iptables, > IIS, realsecure, p0f, etc... alerts too, each one with it's own > reliability, asset, etc. info. > Prelude also logs it's event into DB so, what could be done here ? This > is proving to be the most difficult thought. I'm drawing some visio > like diagrams in order to make it easier to discuss the matter. The > graphics on our site are outdated as is the roadmap (1.0 & 2.0 are > mixed alltogether and we haven't even reached 1.0). Implementing the database querying part shouldn't be too hard, thanks to libpreludedb. Basically the main problem would just be to enable ossim to have 2 differents database backends, and to arrange for every data available in an IDMEF message to be shown by ossim. -- Yoann Vandoorselaere <yo...@pr...> |