Menu
▾
▴
[Os-sim-devel] Re: [prelude-devel] prelude/ossim thoughts
|
From: DK <dk...@os...> - 2004-05-03 19:10:57
|
Hi Gene, After reading the replies I think pros and cons is little misleading. As I delve deeper into prelude I like it more and more and it ratifies my first impression: ossim can learn a lot from it. So rather than pros and cons it should say "possible problems / hurdles such and integration would mean", mainly modifications that would need to be done to both. Ah, most of my impressions are based on the Prelude Architecture Guide. From ossim's point of view, I think the main benefits would be: - IDMEF communication. The protocol we use for internal communication (sensor-server, server-webui) is similar, and now I regret not implementing IDMEF right from the start. We were too lazy... - SSL. Until today we needed to tunnel everything through an external ciphered layer or run all the components on a trusted network. I think libprelude solves this in a good way. - Failover No effort has been made yet by ossim to provide agent/server failover. I like the pseudo-routing done with relay managers. - Timeout and retransmission. Sync & Async. That's something we already have implemented but again, I think libpreludes approach looks robuster. - Native syslog server. If I did understand it right prelude-lml implements a pseudo syslog server (only processing logs, not storing them). That's a feature we needed too, i.e. for fw-1 input. - HIDS. At this time we don't accept input from HIDS and urgently need to change this. - New data input Prelude's sensor list is impressive. If we could correlate all that input... ;-) --- 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. - 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. - 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"). - DB querys Our agent is able to query various things from remote DBs such as risk levels, availability status, etc... - 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). Did you have similar thoughts? Any useful input ? Hopefully I get some time to finish the diagrams and we can talk more on this as soon as possible. Greetings, Dominique PD: Jascha, thanks for the papers, I will have a look at them tonight. The University of Leon, Spain, has some very interesting working code involving neural networks applied to IDSs. They were interested on building something on top of ossim's correlation engine but sadly we didn't have much contact these last months... Am 03.05.2004 um 18:56 schrieb Gene R Gomez: > Hi Dominique, > I'm glad to see that you're evaluating the pros and cons of > integration. > One thing that I wanted to mention before you get too heavy into it is > that my initial plan was to base any integration off of the 0-9 Prelude > branch (currently in the late stages of development), rather than 0-8. > Two reasons: > 1. While Prelude has always been oriented towards IDMEF, 0-9 is fully > IDMEF-compliant. IDMEF will become more and more important after its > final version is ratified and made an official standard for IDS data > exchange. > 2. 0-9 implements libpreludedb, a database abstraction API that makes > integration of other tools much easier. All we'd need to do is write > up > libpreludedb calls and then the API would take care of doing the > neccessary SQL manipulations so that you wouldn't have to worry about > what > backend was being used or how the schema was designed. In fact, I > think > it's likely that a libpreludedb plugin could be written for the current > OSSIM database so that future data exchange would be easier (a series > of > SELECTs from one database and INSERTs to the other made via the API > would > be easy to pull off). > Anyway, let us know if you have any additional questions, or if there > is > some way we can help with the development of your pro/con list. > > Thanks! > Gene R Gomez > >> -----Original Message----- >> From: pre...@pr... >> [mailto:pre...@pr...]On Behalf Of DK >> Sent: Monday, May 03, 2004 4:54 AM >> To: pre...@pr... >> Cc: os-...@li... >> Subject: [prelude-devel] prelude/ossim thoughts >> >> >> Hi, >> >> first of all I want to say hello since this is the first time I post >> to >> the prelude-devel list. I'm CCing os-sim-devel too. >> >> A couple of weeks ago we (at ossim.net) were approached by Gener R. >> Gomez and Krzysztof Zaraska regarding the benefits of a possible >> prelude/ossim integration. We've been quite busy in the last weeks but >> finally got some time and had a look into it. >> >> My first impression is that, as Gene stated earlier, both projects >> could >> benefit from such an integration / collaboration. Prelude >> provides a strong sensor-manager architecture, much better collection >> mecanisms than ossim and a lot of interesting features that ossim >> lacks. Ossim's focus on the other hand is the integration of tools, >> their interoperability and the presentation layer that glues >> everything >> together and, of course, the correlation stuff we're heavily working >> on. I think prelude could benefit from them too. >> >> I'm writing down all the pros and cons (and possible problems) of such >> an integration and will send it to this list as soon as possible. If >> this isn't the right place to discuss such matter please tell me >> where / >> whom to write. >> >> BTW, reading the lists archives I saw a mention to CALM. CALM, as used >> in ossim has nothing to do with http://www.kung-foo.tv/calmapi.php. We >> didn't know of the existence of the calm correlation api (but it's >> interesting read...). Ossim's CALM is a simple event accumulation >> algorithm that tries to come up with a realtime measurement of a >> hosts/nets/global risk. >> >> Greetings, >> >> Dominique >> >> _______________________________________________ >> Prelude-devel site list >> Pre...@pr... >> http://www.prelude-ids.org/mailman/listinfo/prelude-devel >> >> _______________________________________________ >> Prelude-devel site list >> Pre...@pr... >> http://www.prelude-ids.org/mailman/listinfo/prelude-devel > > |
