[Snort-users] spp_portscan and database schema

Florin Andrei florin at ...3506...
Fri Jul 19 16:09:42 EDT 2002

On Fri, 2002-07-19 at 11:56, Erek Adams wrote:
> On 19 Jul 2002, Florin Andrei wrote:
> >
> > If i understand this correctly, Marty basically says "turn on logging if
> > you want that info in the database" (correct me if i'm wrong).
> > I cannot do that, the traffic is way too high. I don't have multiple
> > multi-terabyte RAID arrays available. :-)
> No, not quite.  ;)  If you want to see portscan alerts in your DB, make the
> change listed in the ACID faq.  The reason is that spp_portscan uses the

I do see portscan alerts already. Re-read my first message. I'm running
my database plugin with the "alert" option.

> 'alert' facility, instead of the 'log' facility.  By 'log' it doesn't mean
> "log every packet", it means "send this packet thru the 'log' facility".
> 'Alert' will "send this packet thru the alert facility, generate an alert, and
> then 'log' the packet for later examination."
> Since spp_portscan uses 'alert' to send the data back into snort, you must
> tell snort to send 'alerts' to the DB.  It still gets logged, but as an alert
> and not just a 'logged packet'.

But i did that already. In fact, my configuration was exactly like that
to begin with:

preprocessor portscan: $HOME_NET X Y portscan.log
output database: alert, mysql, user=...

$portscan_file = "/some/path/portscan.log";

And i'm 50% happy with what i have in ACID. Sure, the layout might be
better, and the fact that the data comes from two different places shows
up in the functionality of the interface. But i can live with that.

But... ACID is not the only thing that taps into the database, and
that's where my problem begins.

Of course, i can feed portscan.log into the database via a Perl script
or something, and i'm afraid that's what i'm going to do, but i hate
that kind of non-standard, uglier-than-hell quick hacks... And that
means modifying other tools, including ACID... :-(

The purpose of the database is to make easy and fast corelations. And,
in case of portscans, the things you use to corelate things are
addresses, ports, etc.

Florin Andrei

Don't break things that don't need to be broken
while you're fixing things that really need fixing.

More information about the Snort-users mailing list