[Snort-devel] Thoughts on threads
jon at ...370...
Mon Apr 30 13:43:39 EDT 2001
> But the network can reorder, and the authors of the script-kiddie-scripts
> can reorder their code. Ergo, isn't any detection code that relies on
> delivery order already per se broken?
I'm not concerned about packet re-ordering on the network; I'm concerned
about granting Heisenberg access to my NIDS boxen. At best, I'm sure I can
name only four or five common situations right now where reordering by
SNORT is a bad thing, so perhaps we should just ignore this. However, I
am deeply concerned when a piece of analytical software distorts the very
thing it is trying to exhibit, and I'm not convinced things won't come up in
future where we'll need specific ordering. (If my SNORT box gets loaded
and one thread gets delayed by 200-300ms because of some hulking spp_* in
front of it, things could get tricky on postmortem.)
Just my two cents. I've spooled off a couple of current situations wherein
packet ordering was necessary for post-processing. I'm sure there are other
ways to doing it, but this is just what I have right now.
---- Meandering thoughts below ---
-One of our clients installed a formmail script, which somehow made its way
onto a list of open SMTP relays. A negative on such activity is defined as
visit to the HTML page _followed_by_ a visit to the script. A positive is
hit on the script sans visit to the HTML page.
-IPsec attacks often involve attacking the negotiation sequence. We watch
such activity, and try to catch it early.
-SSH [Tatu, your royalty cheque is in the mail] has the same type of
More information about the Snort-devel