On 10/11/07, Nelson Brito <[EMAIL PROTECTED]> wrote: > > > This is always something that exists as a threat by stateless > > protocols, it matters not that it is a null payload or a real payload, > > the result is the same, as is the reality that this is malicious > > traffic on the wire. I would argue that using a null payload is > > actually falling short of the goal of resource exhaustion in so far as > > the analyst can easily eliminate it. Sourcefire (Creators of Snort) > > also provides more automatic methods to do this work for the analyst > > by determining if the payload has any chance of affecting the target > > and adjusting the events accordingly. This serves to highlight the > > important events that need review and lower the relevance of the rest > > of the events. > > That is the point here. NULL bytes shouldn't fire any event, due to the fact > that the end-point - the vulnerable server - ignore the NULL bytes, i.e., > the SQL Server will respond as a valid request showing you the information > you have requested, but in this scenario the SNORT or any other that doesn't > check correctly the payload and the content will fire an attack event - > false positive. That is so old school, since the release of the evasion, > insertion and DoS bible, that any IDS/IPS mjust have protection against this > kind of attack.
It is trivial to filter out post fact and is not normally occurring, I consider the alert successful at detecting nefarious activity. Simple, practical, effective. > > As I said, and that is my last reply for this thread, if you cannot see or > see more than you should, you are not able to protect your network. Some of > the IDS/IPS has a protection "threshold" that when you reach the # the > IDS/IPS will shutdown the signature. Is that good? Can we consider an > IDS/IPS technology that protects itself instead of your network? > > > There are several classes of thresholds available within Snort, which > > one used depends entirely on the need. From > > http://www.snort.org/docs/snort_htmanuals/htmanual_280/node330.html#Event_ > > Thresholding > > > > There are 3 types of thresholding: > > > > * limit > > > > Alerts on the 1st m events during the time interval, then > > ignores events for the rest of the time interval. > > > > * threshold > > > > Alerts every m times we see this event during the time interval. > > > > * both > > You are missing the real thing here... You cannot fix this using thresholds, > because doing this you will fix the result when you should consider to > attack the cause of this: the signature. We are talking right past each other here. So what if it is a null payload, if your goal is resource exhaustion then use a real payload. You have achieved absolutely nothing using the null payload, except perhaps to make it easily filtered out of your result set. Have you met Caswell? http://www.shmoo.com/~bmc/ ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw to learn more. ------------------------------------------------------------------------
