[Snort-devel] spo_database & fragments
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
ipsrc,ipdst,proto, port (where available)
when there's a frag - theres atleast the iphdr which would be useful
Aggregates that don't have a single packet associated with them
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
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?
> 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