dr at ...40...
Sat Sep 23 16:54:11 EDT 2000
On Sat, 23 Sep 2000, Fyodor wrote:
> ~ :
> ~ :The other fix for this might be to send on packets that are not part of an
> ~ :established TCP stream, e.g. they have a SYN, SYN/FIN, or otherwise don't
> ~ :look to be data packets. Packets which are regular session traffic could
> ~ :then have p->tcph set to NULL. This should prevent them from traversing
> well, yep, in the current source packet will not be processed if p->tcph
> is NULL, even if p->iph->ip_proto is IPPROTO_TCP. But we would have to
> make sure that we will not miss any data in this case. Having extra-false
> positives (or doubled positives in this case) is better than having any
This was my initial base assumption with the defragger as well.
I feed the fragments _and_ the reassembled packets back into
snort main. I was contemplating making it a rules file option
to turn this feature on or off... and then it could either leave
the fragments from a reassembly to pass through the main loop
or it could keep them in the "holding tree" and pass the
fragment back with a null ptr for the IP hdr?
This would also mean that the garbage sweeper would have
to fire the packets back into snort main on cleanup...
By making it a rules file option you let the user decide if he
want the false positives and additional CPU time cost. And
the default behaviour can be the concensus opinion of the
safest configuration... This may be giving users enough
rope to hang themselves on slow boxes, but I like erring
on the side of more flexibility, imho.
The additional CPU may not be a huge hit on efficiency...
For me the answer lies in good complete benchmarks of
just how much processing overhead these additional packets
can induce. Right now once you get the packets into
mem... depending on your working set and caches
you can sometimes have a lot of time on today's
CPU heavy architectures to play with the packets...
I keep hoping that people who run snort on loaded
public links could give me some feedback about CPU
utilization with fragmentation on and off (peak, mean)....
And now with beta20 running solidly for a couple of
days straight.... Maybe I will get some, as more dare
enable it... But it looks like I have to run with some
"synthetic" test data for now...
In general I like this pass the packet data back, but
pass a null ptr to the header when plug-ins take
responsibility for the packet. I would request one
more thing, one or more levels of alarm flags (how
about, one 32 bit word full of flags?) that can be
set on a packet by a plug-in and snort-main when
that packet has triggered the respective alarm or
condition.... Maybe, initially this can be used for
the alarm severity and varied alarm output plug-ins
to get multiple reporting paths (two bit flags for
Dragos Ruiu <dr at ...9...> dursec.com ltd. / kyx.net - we're from the future
gpg/pgp key on file at wwwkeys.pgp.net
More information about the Snort-devel