FW: Snort and Netfilter (Linux)

[Didier CONTIS]

I am forwarding to the netfilter mailing list a set
of messages I had on the snort mailing list regarding
a direct interfacing of the Network IDS snort with netfilter.

I would like to check before starting to code if someone is already
working of the extension described below of the LOG module (or a new
module / target).

I am also asking for comments regarding the creation of a new device
called /dev/firewall or /dev/nids which will be used to pass packets
from netfilter to snort.

Thanks in advance for any comments.

Regards, Didier.

-----Original Message-----
From: Didier CONTIS [mailto:dcontis@bellsouth.net]
Sent: Tuesday, January 25, 2000 11:21 PM
To: snort@bofh.kyrnet.kg
Cc: discussion@incident.org
Subject: RE: Snort and Netfilter (Linux)

Marty,

I am going to go for it. In the same time I am going to check with
Rusty Russel if someone is working on something similar or not (I am going
to do a post on the netfilter mailing list this evening).

The best way to start I guess is to extend the LOG module (or write a new
one based on it) that can write packets first to a file using the tcpdump
binary format
and then to a device (like the /dev/firewall of Jed). At this point it
should not be
too difficult to add a switch to snort telling it to read directly from
/dev/firewall (or
/dev/nids).

Regarding the call of snort plugin from the iptable rule, I must admit I
have not studied
deeply yet the plugin interface of snort. Would it be possible to extend
snort in order to be able
to pass the packet to be analysed ( throught the device /dev/nids ) with a
list of plugins
to be used on it ?

Finally, regarding the integration between snort and a database, I will
refer to the comment
of Jed in his answer (attached below).

I guess that's it, and it is just a matter now of "just do it".

Any comments (flames ??) are welcome.

Didier.

PS: I have added at end the answer of Jed Pickel + my initial messages

-----Original Message-----
From: roesch@feynman.hiverworld.com
[mailto:roesch@feynman.hiverworld.com]On Behalf Of Martin Roesch
Sent: Tuesday, January 25, 2000 2:32 AM
To: Didier CONTIS
Subject: Re: Snort and Netfilter (Linux)


Woah, sounds pretty involved.  FYI, snort has an active response
(connection termination) module in the current beta version.  As for
integration with the firewall, if you're motivated to proceed with the
work I'd say go for it.  Be aware that Snort is integrating new
functionality rapidly, including automated port scan detection, active
response, IP defragmentation, and possibly TCP stream reassembly,
through the plugin interface in Snort.

As for MySQL integration, that sounds like it would be pretty excellent
if you could make it happen.  Be aware that I'm in the midst of writing
a modular plugin infrastructure for the output/alerting subsystem, so
once that's done integrating with a database shouldn't be a big problem.

Let me know what you think of all this...

--
Martin Roesch                      <roesch@hiverworld.com>
Senior Software Engineer         http://www.hiverworld.com
Hiverworld, Inc.               Enterprise Network Security
Network Forensics, Intrusion Detection and Risk Assessment

============================================================================
==========

From: Jed Pickel [jed@pickel.net]

> To sum up the relevant part of this message: I am looking
> on my side on how to send to snort or to a database IP packets treated by
> the netfilter mechanism of the 2.3 Linux kernel.

I had a look through your messages and I like what you are trying to do.
I have done some very similar things with ipchains in the past. You can
take a look at www.incident.org to see what I have done there. I am
currently working on snort to use it as a sensor for incident.org.

I even have some code somewhere I used to read /dev/firewall which is
the logging device I created for use with ipchains. Perhaps we could
have the same application reading data from snort unsock alerts and
various firewall fifos.

> I would like to know if you have already worked on the side of the
database.
> Have
> you thought about MySQL ? Have you already designed table structures,
> indexes ?

I have done a bit of work with this but I would not consider anything
I have done thus far to be worthy of anything standard. MySQL will end
up killing you because there is no support for transactions. I am
currently migrating everything I have done to Postgres.

> The reason I am asking this is for interoperability purposes. If you have
> already
> a format, I would like to try to follow it in order to avoid the re-invent
> the wheel pb.

Hmmm... Well. I guess the way you design a database is heavily dependent
on the goals you are trying to acomplish by storing that data. Out of
curiosity, what are your goals? After a considerable amount of work I
think we could come up with a standard way to store this sort of data
in a DB. There are many things to think about here. For example take a
look at some of the work the IDWG is doing (www.ietf.org).

[..........]

Regards,

* Jed

> -----Original Message-----
> From: Didier CONTIS [mailto:dcontis@bellsouth.net]
> Sent: Sunday, January 23, 2000 7:18 PM
> To: The Roesch's
> Subject: RE: Snort and Netfilter (Linux)
>
>
> Thanks marty for your answer.
>
> First, I do not want to have snort completely integrated into the linux
> kernel.
>
> By the term integration, I am thinking about being able to "feed" directly
> snort from
> netfilter rather than from the libpcap / promiscuous mode.
>
> Instead of a netfilter chain (rule):
>
> iptables -A MyRules --proto tcp --syn --dst ip_my_www_server --dport 80 -j
> ACCEPT
>
> which accept packet destinated a web server, I would like to have the
> following
>
> iptables -A MyRules --proto tcp --syn --dst ip_my_www_server --dport 80 -j
> SNORT_WWW
>
> where SNORT_WWW is a chain like:
>
> iptable -A SNORT_WWW -m snort_www_plugin --action <inspect/filter>
> (-m call a netfilter extension ).
>
> This mechanism would allow to send all incoming http traffic directly to
the
> www snort plugin. The plugin perform at this point do his job of IDS. One
> advantage
> is such scheme allow not only to detect a www "intrusion" but to block the
> IP packet.
>
> I think this will make possible to block application type DoS.
>
> The same can be done for ftp, dns ... This can bring both a better
> flexibility and performance,
> especially with the mechanism of plugin being implemented in snort.
>
> An additionnal advantage is to take benefits of the fact that netfilter
can
> reassemble
> IP fragments (no reason to do the job twice, especially on a linux based
> firewall).
>
> Such scheme allows to treat differently, from an IDS point of view, the
> traffic which is
> allowed from the traffic dropped. I think the real time IDS task must be
> performed first
> on the traffic going through the firewall.
>
> Dropped/rejected packets can then be sent to Snort (with a wider set of
> rules)
> directly from by netfilter or to a storage area for a delayed treatment.
> This storage
> can either be a tcpdump binary type file that is read every x minutes by
> snort or TO a database.
>
> By the way, is anyone working on an hook between Snort and MySQL ? I think
> the idea of having
> snort being able to run from a database is great, especially in order to
be
> able to detect
> slow, random network scan.
>
> Let me know what you think.
>
> Regards, Didier.
>
> -----Original Message-----
> From: root [mailto:root]On Behalf Of The Roesch's
> Sent: Saturday, January 22, 2000 12:56 AM
> To: Didier CONTIS
> Subject: Re: Snort and Netfilter (Linux)
>
>
> Hi Didier,
>      I'm not aware of anyone doing anything like that, but it's a pretty
> major undertaking.  I don't think it'd necessarily be a problem, but you
> should be aware that the Snort code is somewhat in flux right now with
> me in the process of adding a major piece of internal infrastructure to
> the program (output plugins).  Besides some performance improvements,
> what are the specific benefits of moving it into the kernel that you're
> expecting to see?
>
>      -Marty
>
>
> Martin & Anna Roesch
> roesch@md.prestige.net
> http://www.clark.net/~roesch