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:
- BARE BYTE UNICODE ENCODING Annie Green (Jun 01)
- Re: BARE BYTE UNICODE ENCODING Adam Baldwin (Jun 02)
- Network Traffic Flow learning and Simulation Mayank-Bhatnagar (Jun 18)
- RE: BARE BYTE UNICODE ENCODING Omar Herrera (Jun 02)
- Re: BARE BYTE UNICODE ENCODING nick black (Jun 04)
- Re: BARE BYTE UNICODE ENCODING Martin Roesch (Jun 07)
- Re: BARE BYTE UNICODE ENCODING nick black (Jun 07)
- RE: BARE BYTE UNICODE ENCODING Omar Herrera (Jun 07)
- Re: BARE BYTE UNICODE ENCODING Nigel Houghton (Jun 08)
- Re: BARE BYTE UNICODE ENCODING nick black (Jun 04)
- Re: BARE BYTE UNICODE ENCODING Adam Baldwin (Jun 02)
- <Possible follow-ups>
- Re: BARE BYTE UNICODE ENCODING Annie Green (Jun 02)
- Re: BARE BYTE UNICODE ENCODING Adam Baldwin (Jun 02)