[Snort-devel] spo_database & fragments

Chris Green cmg at ...81...
Thu Jan 18 13:44:55 EST 2001


That would be very useful if done correctly but I don't immediately
see how to cram aggregates like portscan and tiny frags into the same
table.

ipsrc,ipdst,proto, port (where available)

when there's a frag - theres atleast the iphdr which would be useful
to log.

Aggregates that don't have a single packet associated with them
already have

the event, table, signature, and timestamp

suppose "UDP Scan" and src/dst ip, protocol, ports and scantype

SPADE would have it's own unique table format as well.

A catchall type table that is a cid / text field would atleast allow
centralized sql logging from new plugins.

To have a fancy table type for a plugin, there needs to be a mecahnism
to know what generated the alert so that the appropriate logic can be
followed.  


Martin Roesch <roesch at ...48...> writes:

> I'm beginning to think that the DB should include a table to handle
> non-packet alerts, stuff that's part of an aggregate or partial packet
> match (like tiny frags).  Thoughts?
> 
>     -Marty
> 
> Chris Green wrote:
> > 
> > /* We do not log fragments! They are assumed to be handled
> >     by the fragment reassembly pre-processor */
> > 
> > The minfrag preprocessor will cause the output plugin to record an
> > alert but there will be no iphdr/opts/data field associated with the
> > packet.  Its not fun to have an alert that no one can find.
> > Reassembled packets shouldn't get to the output stage as a fragment
> > packet alert AFAICT and instead will appear as a full packet to the
> > output.  If nothing else, this should make the spo_database work with
> > the same semantics as the spo_alert_fast.c
> > 
> > The quick fix is to move the if(p->frag_flag) check around and let the
> > other fields be created.
> > 
-- 
Chris Green <cmg at ...81...>
"When the going gets weird, the weird turn pro..."
                            -- Hunter S. Thompson




More information about the Snort-devel mailing list