IDS mailing list archives

RE: BARE BYTE UNICODE ENCODING


From: Omar Herrera <oherrera () prodigy net mx>
Date: Sat, 05 Jun 2004 10:15:49 -0600

  
 What's the upshot of all this?  If you wish to specify that "this
should
 only be tested against TCP payloads", specify that, and design your
 signature language so the exact concept is expressible.  The blight
of
 "flags: A+;" tests permeating snort's rulesets have always struck me
as
 a misguided attempt to lazily optimize rule evaluation at the expense
 of correctness and clarity.  I'd love to be educated otherwise [0].

The upshot is that this lady is receiving alerts from a snort signature
embedded deep into the programming logic of snort (BARE BYTE UNICODE
ENCODING), it is not defined on the rule set files and you can only
change its behavior through configuration parameters in the snort.conf.
Yet, you cannot change the rule itself. You wouldn't be suggesting her
to go right into snort's source code and change this to conform to all
norms you listed, do you? Turning off this rule will suffice if it is a
false positive (which could be the case).

After all, what she wants is to understand why does this rule triggers
and what does the ACK flag in these particular packets mean. She didn't
ask if the logic on their IDS is RFC compliant but your insight is
useful though.

In the end, all the wealth of information that you kindly shared with
us, the explanation is still that snort will trigger on ACK packets for
this rule (actually ACK+PSH now that demand correctness, since the only
relevant packets to this signature are the ones coming from the client
to the web server), whether we like the logic behind their
implementation or not.

And now that you put this discussion here, bear in mind that keeping all
packets related to a connection from the 3-way-handshake to the end
a-la-stateful might also generate some DoS vectors. It is not an easy
problem to decide what to keep and what to let out after individual
analysis of packets.

Would you share with us some suggestions on this behalf that are
actually practical without letting in a DoS capability?

Regards,

Omar



---------------------------------------------------------------------------

---------------------------------------------------------------------------


Current thread: