Re: [Ipaudit-devel] Compiled responses

"Jason R. Martin" <jrmartn1@...> writes:
> On a related note, has anyone tossed around the idea of Windows as well?
> Perhaps Chris could answer this: how terribly horrible and difficult
> is/was it to have snort run in Windows as well as *nix?
Daemon code initialization isn't too hard. We are fortunate to have a
win32 guy. The webfront end would have it's own set of issues like
abstracting out path notations and making sure that we stick to a good
set of includes.
Do a perplatform system include file and have one big ifdef based on
platforms. We've got a distributed #ifdef WIN32,,
> Just curious, since if it wasn't terribly difficult using Winpcap
> then it might be an interesting side venture.
The biggest part is that if someone has a bug only on windows, I can't
care because I don't have the resources to reproduce it.
WinPcap works well on ethernet.
--
Chris Green <cmg@...>
You now have 14 minutes to reach minimum safe distance.

Thread view

It's great to see that there's been substantial amounts of
activity on this list since our 'roadmap' post. We are thrilled
with the enthusiasm.
Straight to the point(s):
1) API - Yes, we plan to generate an API. That's what we
meant by 'modular plug interface specification'. We
apologize for any unclarity.
2) Configuration File - We plan to use an xml-based
configuration scheme. Chris: if you have any specific
ideas, please let us know, as nothing is set in stone (yet).
In terms of the API handling the configuration file, yes this
is planned. (Chris: I hope this is what you meant?) jh: We'll
take care of minimizing configuration files when we rewrite
portions of the core.
3) Priviledges - We initially wanted to drop the ipaudit user
and group for simplicity's sake, but have since
reconsidered. Any web interfaces will hopefully run as
apache so as to limit the chances of obtaining ipaudit
priviledges through cgi vulnerabilities.
4) Porting - Due to structural changes within ipaudit, it will
most likely break on other operating environments. Our
development environment is Gentoo Linux (gentoo.org). jh:
would you like to provide quality assurance for ipaudit on
other operating environments?
5) Packaging - jh: thanks for volunteering. (others: hint
hint).
6) Central Web Gui - Sounds like a great idea. We'll take
care of it.
7) PHP, MySQL - Jason: We're taking care of the MySQL
backend portion, and will be working on a web frontend,
although not necessarily in php. The web frontend is far
down the road for us, considering the structural changes
ahead. We will be making a uniform database structure
independent of database system implementation. This
way, people can write uniform interfaces to any SQL-
compatible database.
8) Multiple frontends: The whole idea behind the structural
changes in ipaudit is to allow for more customization on
both the output as well as the frontend levels.
That pretty much sums up the responses we had. On a
final note, as we are <em>poor</em> college students who
study by day and work underpaid techie jobs by night (so
as to be able to pay for college), we are realistically unable
to devote as much time as we'd all like to the project. Be
patient, we work on it when we can, and we will get back to
you eventually.
Regards,
Lina Pezzella && Hasan Khalil
P.S. If you can rectify the 'poor' part, the notion would be
much appreciated, and repaid in ipaudit code. Uh... Just
kidding... We think...

Lina C Pezzella <Lina.Pezzella@...> writes:
> 2) Configuration File - We plan to use an xml-based
> configuration scheme. Chris: if you have any specific
> ideas, please let us know, as nothing is set in stone (yet).
> In terms of the API handling the configuration file, yes this
> is planned. (Chris: I hope this is what you meant?) jh: We'll
> take care of minimizing configuration files when we rewrite
> portions of the core.
Yes, if you're going the full xml route, that's the right route.
> 7) PHP, MySQL - Jason: We're taking care of the MySQL backend
> portion, and will be working on a web frontend, although not
> necessarily in php. The web frontend is far down the road for us,
> considering the structural changes ahead. We will be making a
> uniform database structure independent of database system
> implementation. This way, people can write uniform interfaces to any
> SQL- compatible database.
A Long long time ago @uab, used an application called XNI which now
sseems to be http://www.inetd.com/. It wrote to an SQL backend and
then ran reports off it which seems to be the route that a lot of
effort is being looked at. It's probably much better now but ipaudit
was a clear superior replacement.
I'd do ipaudit -> [binary files] -> spooler to SQL software
-> Web Frontend
ipaudit's backend flatfiles ended up being so much better for
searching and reporting. I'd go for binary flatfiles with variable
size records depeding on the address famliy (ipv6 v ipv4 v ...) so
that the tokenization can be done by offset rather than by split().
What high level goals do you all have for ipaudit? In thinking about
the road map, I see modularization as a goal. What's the goal that
modularization is going to make easier to for continued development?
SQL loading seems to be one of the problems you are attempting to
solve. What else?
I think the Web GUI is the biggest attraction for ipaudit. I see that
Jason R Matin finds a PHP+SQL frontend attractive. Is there a lot of
requests for that in person?
The reason I ask is you could divide an esoteric crowd amongst a few
frontends that might be better served by all eating the same dog
food. I say this as a developer on a project with atleast 15 known
output plugins.
Perhaps Jason's problem could better be solved by having an API that
allows external requests so his "What did John Doe look at in the last
hour" be parsed into the Search/Reporting pages and putting a
templating system into the webpages.
Back to hiding :)
--
Chris Green <cmg@...>
This is my signature. There are many like it but this one is mine.

On Mon, Oct 13, Lina C Pezzella wrote:
> 3) Priviledges - We initially wanted to drop the ipaudit user
> and group for simplicity's sake, but have since
> reconsidered. Any web interfaces will hopefully run as
> apache so as to limit the chances of obtaining ipaudit
> priviledges through cgi vulnerabilities.
This doesn't really help any. We're just replacing "ipaudit privs"
with "other processes/cgi that apache is running." IE: Now we can diddle
with apache and other CGIs run as apache instead of Ipaudit. In a
perfect world (tm), why not:
user wants to run ipaudit - use the "ipaudit" user.
user wants to run web front end - use the "ipauditw" user.
or something like that. Personally, I think that if you're going to
only create one user, then just make the cgi *and* the daemon run as
that user. I don't think that allowing ipaudit cgi problems to affect
other processes outside of the ipaudit scope is the correct way to
handle this.
> 4) Porting - Due to structural changes within ipaudit, it will
> most likely break on other operating environments. Our
> development environment is Gentoo Linux (gentoo.org). jh:
> would you like to provide quality assurance for ipaudit on
> other operating environments?
I don't like the term "quality assurance." ;) I originally joined the
ipaudit project to make ipaudit and the CGIs portable - I have no
problems continuing to don the Portability hat.

> 4) Porting - Due to structural changes within ipaudit, it will
> most likely break on other operating environments. Our
> development environment is Gentoo Linux (gentoo.org). jh:
> would you like to provide quality assurance for ipaudit on
> other operating environments?
I have access to Gentoo, RedHat (7.3,9), Solaris (7,8,9), and HP-UX
(10.20,11.11) machines, and would be willing to donate a small amount
of time testing on these platforms.
On a related note, has anyone tossed around the idea of Windows as well?
Perhaps Chris could answer this: how terribly horrible and difficult
is/was it to have snort run in Windows as well as *nix? Just curious,
since if it wasn't terribly difficult using Winpcap then it might be an
interesting side venture.
> 7) PHP, MySQL - Jason: We're taking care of the MySQL
> backend portion, and will be working on a web frontend,
> although not necessarily in php. The web frontend is far
> down the road for us, considering the structural changes
> ahead. We will be making a uniform database structure
> independent of database system implementation. This
> way, people can write uniform interfaces to any SQL-
> compatible database.
Sounds good. I think spending a good deal of time hashing out the
database structure before doing any implementation is probably
worthwhile, as once it's implemented and anybody starts using it,
changing it would be a pain.
> 8) Multiple frontends: The whole idea behind the structural
> changes in ipaudit is to allow for more customization on
> both the output as well as the frontend levels.
Works for me. I will probably continue to work on the frontend I've
been using, since it works (somewhat) for what we need it to do.
Ipaudit has been one of the most useful pieces of network monitoring
software we've had here over the years, and it's very exciting to me
that development suddenly started back up! I've been slowly trying to
decide if I wanted to start hacking at it myself, and it's great to see
it's developers working on it some more.
Jason
--
_________________________________________________________________
Jason R. Martin | Network Administrator | Coordinated Science Lab

On Mon, Oct 13, Jason R. Martin wrote:
> > 4) Porting - Due to structural changes within ipaudit, it will
> > most likely break on other operating environments. Our
> > development environment is Gentoo Linux (gentoo.org). jh:
> > would you like to provide quality assurance for ipaudit on
> > other operating environments?
>
> I have access to Gentoo, RedHat (7.3,9), Solaris (7,8,9), and HP-UX
> (10.20,11.11) machines, and would be willing to donate a small amount
> of time testing on these platforms.
Ah, that's good news! I don't have access to HPUX, Solaris 7, or Gentoo.
Most of my problems are that I *think* something might work somewhere,
but I don't have access to the proper hardware to test. I'd be glad to
bounce things around with you.
I believe I've procured an Alpha - I/we can use that for Linux-Alpha.
> Ipaudit has been one of the most useful pieces of network monitoring
> software we've had here over the years, and it's very exciting to me
> that development suddenly started back up!
Well, to be fair, development never really went away. It was just Jon
and myself sending emails directly to each other about once a month. I
guess that's as close to "sorta breathing" as you can get. Lina and
Hasan are certainly that needed element to get us going again.

"Jason R. Martin" <jrmartn1@...> writes:
> On a related note, has anyone tossed around the idea of Windows as well?
> Perhaps Chris could answer this: how terribly horrible and difficult
> is/was it to have snort run in Windows as well as *nix?
Daemon code initialization isn't too hard. We are fortunate to have a
win32 guy. The webfront end would have it's own set of issues like
abstracting out path notations and making sure that we stick to a good
set of includes.
Do a perplatform system include file and have one big ifdef based on
platforms. We've got a distributed #ifdef WIN32,,
> Just curious, since if it wasn't terribly difficult using Winpcap
> then it might be an interesting side venture.
The biggest part is that if someone has a bug only on windows, I can't
care because I don't have the resources to reproduce it.
WinPcap works well on ethernet.
--
Chris Green <cmg@...>
You now have 14 minutes to reach minimum safe distance.