[Snort-devel] Thoughts on threads

Jon Bentley 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
the
future where we'll need specific ordering.  (If my SNORT box gets loaded
down
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.

-jb

---- 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
a
 visit to the HTML page _followed_by_ a visit to the script.  A positive is
a
 hit on the script sans visit to the HTML page.

-IPsec attacks often involve attacking the negotiation sequence.  We watch
for
 such activity, and try to catch it early.

-SSH [Tatu, your royalty cheque is in the mail] has the same type of
negotiation
 issues.






More information about the Snort-devel mailing list