Re: [Os-sim-devel] OSIM arquitecture: too many components?

[DK <dk...@ip...>]

Hi JV,

First of all thanks for the input.

I'll answer to your questions / appointments below.

El 9/26/03 16:27, "Jose Vicente Nunez Zuleta"
<jo...@us...> escribi=F3:

> Greetings,
>=20
> I saw the project and i think is definitely worth the effort; If you
> have a medium to large network under you control you will notice pretty
> soon than without the appropiate tools you will not be able to correlate
> and investigate event the most basic events.

Os-sim is growing very fast and at this point I agree with you, we have to
be careful about what direction we want take. This is why we stopped
development for a few days so we can decide what, when and how we want to
integrate tools, what DB / languages to use and how to glue everything
together.

>=20
> The idea of using readily available tools like Snort, OpenNMS, NMAP etc
> is very attractive because a large number of sites are already using
> them so a 'glue' that ties all that information together is more than
> welcome.
>=20
> Still, there are some points related with the arquitecture of the
> project that doesn't seem to fit appropriately.
>=20
> All my comments are based on the information contained on the
> arquitecture diagram published by the os-sim developers
> (http://os-sim.sourceforge.net/docs/ossim3.jpg) and the tools mentioned
> on their web site (http://os-sim.sourceforge.net/home.html)

Again I have to ask you to excuse us for the lack of documentation. I hope
this will change soon, we are working on it so we are able to transmit our
thoughts and ideas about how everything should work.


Then next four questions (except PHP vs. Java) should be answered soon.
Please have a look at my diary
(http://sourceforge.net/developer/diary.php?diary_id=3D14122&diary_user=3D82558=
0
) where I posted some thoughts today. I didn't want to show them on the mai=
n
site because they are personal thoughts and I would like to discuss them
whit the rest of the team so we can come up with some good documentation /
todo list / roadmap.

Resuming what I wrote related to your questions:

- We want to get rid of MRTG. We don't need it.
- We have to decide between mysql & postgresql. Both have its pro's and
con's.
- Of course nessus-opennms integration would be done after talking with
Opennms's creators.
- We have to write a data consolidator which accepts input from many more
devices.
- C is needed. Perl isn't but can solve temporary problems. At the end, the
whole core should be written in C.

We want to make use a lot of opennms's many good features but we think some
of them are better kept separated because there are already very good
programs out there that do their specific job.

I don't think it is such a good idea to rewrite ntop entirely only to get a
tighter integration with opennms.

As of network discovery, at this moment we use nmap only for a couple of
things. It's planned to add service discovery but I think its better to
compare and complement NMS data with nmaps input rather than to rely
entirely on its own network discovery, mainly because many times we don't
want the full set of opennms's discovery and poller related features.

Again thank you very much.

Greetings,

DK

>=20
> 1) Too many OpenSource tools, some overlapping: For example NTOP could
> be replaced with custom OpenNMS graphs and custom polling of SNMP OIDS
> on the target machines; MGRT could be replaced directly with RRDD tool
> and again OpenNMS can show the custom graphs too; You mention NMAP for
> network discovery, but OpenNMS already does that job.
>=20
> Two databases? PostgreSQL can do the job of MySQL (and OpenNMS already
> uses it). Snort can log events directly to PostgreSQL. MySQL probably is
> too simple for an enterprise solution like this one.
>=20
> Sortova consulting was doing some works to integrate Nessus with OpenNMS
> (currently nobody is working on that tough). Maybe is better to
> contribute code to integrate them than reinventing the wheel here.
>=20
> 2) Too many languajes and platforms to maintain: The arquitecture itself
> is composed of at least two databases (PostgreSQL and MySQL), at least
> two web presentation layers (PHP, JSP), several programming languajes
> (Perl, PHP, Java, C). This is a mainteinance disaster waiting to happen
> unless a hughe team of developers with a large skillset is ready to
> maintain all the pieces that tie together the application.
>=20
> The team should reconsider to rewrite at least some of the analisys
> components. Also only one database shold be used.
>=20
> 3) What about other devices like switches, firewalls that doesn't even
> speak SNMP but Syslog?. What about machine that run only Syslog deamons?
> A custom Syslog listener could be a very good glue to gather information
> from several places like Snort sensors, IPTables firewalls, Switches.
> One problem with SNMP traps is than they are not very secure and once
> you know the password you can tamper the contents or even flood the SNMP
> trap daemon.
>=20
> 4) PHP and JSP, which one is better? My Opinion is that PHP is not
> prepared for the enterprise. PHP doesn't have the optimizations than
> Java do on the server side and also ties the presentation too close with
> the logic. It's true than Java takes more time to master, but is also
> true than is much more flexlible and standarized than PHP (PHP doesn't
> have a common database layer AFIK). The team should try to replace tools
> like ACID (wich source code is freely available) and maybe thing about
> integrating those changes with OpenNMS (as a custom web app) or
> developing the tool using Java as a separate web app.
>=20
> In my opinion, a tigher integration with OpenNMS will solve many of
> these issues;
>=20
> What do you think about this?
>=20
> JV.