[sniffer] Re: Bad rule alert: 1940812
Hello Andrew, Tuesday, June 17, 2008, 5:03:25 PM, you wrote: > Thanks, Pete. > I had four actual false positives on one server, versus 324 unique hits > for the bad rule. > So yes, I'd say that the autopanic feature worked quite well. It's a little odd to say this under the circumstances, but congratulations on the success of the first live test of auto-panic. (all previous tests were in the lab) :-) _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Bad rule alert: 1940812
Thanks, Pete. I had four actual false positives on one server, versus 324 unique hits for the bad rule. So yes, I'd say that the autopanic feature worked quite well. Andrew. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, June 17, 2008 1:47 PM To: Message Sniffer Community Subject: [sniffer] Re: Bad rule alert: 1940812 Hello Andrew, Tuesday, June 17, 2008, 4:41:41 PM, you wrote: > Thanks, Pete. > I had very few actual hits; I have lots of lines that indicate the rule > panic in place, but the number of actual hits is quite small. > How I found my hits: > cd /d C:\MessageSniffer > gawk "($6 == \"Final\") && ($7 == 1940812)" *.20080617.log I haven't checked telemetry yet -- still very busy here battling the stock-push spam & other storms. However, you were likely protected by the Auto-Panic feature in the new SNF. The first time the bad rule hit a message with an IP source in the white range it would have been automatically added to your node's internal panic list rendering it inert. That probably explains why you have very few hits. Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Bad rule alert: 1940812
Hello Andrew, Tuesday, June 17, 2008, 4:41:41 PM, you wrote: > Thanks, Pete. > I had very few actual hits; I have lots of lines that indicate the rule > panic in place, but the number of actual hits is quite small. > How I found my hits: > cd /d C:\MessageSniffer > gawk "($6 == \"Final\") && ($7 == 1940812)" *.20080617.log I haven't checked telemetry yet -- still very busy here battling the stock-push spam & other storms. However, you were likely protected by the Auto-Panic feature in the new SNF. The first time the bad rule hit a message with an IP source in the white range it would have been automatically added to your node's internal panic list rendering it inert. That probably explains why you have very few hits. Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Bad rule alert: 1940812
Thanks, Pete. I had very few actual hits; I have lots of lines that indicate the rule panic in place, but the number of actual hits is quite small. How I found my hits: cd /d C:\MessageSniffer gawk "($6 == \"Final\") && ($7 == 1940812)" *.20080617.log Andrew. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, June 17, 2008 1:31 PM To: Message Sniffer Community Subject: [sniffer] Re: Bad rule alert: 1940812 Hello Andrew, Tuesday, June 17, 2008, 4:21:49 PM, you wrote: > Pete, if we have a significant number of hits, they'll be from all kinds > of IP sources. > Should we dump the GBUdb? If so, how? It is unlikely that good IPs will be moved to into the black ranges with a short event like this-- so you should not need to dump GBUdb unless you see GBUdb false positives. The design of GBUdb is such that there is significant inertia for well known IPs -- if they are known to be good -- or at least solidly not bad, then the IPs will not be easily moved into the black ranges. > The documentation is perfectly clear on how to tweak an IP or dump > an IP in the GBUdb, but doesn't mention a wholesale clearing of it. If you do decide to dump your GBUdb then follow this procedure: Stop SNFServer Delete the .gbx file in the SNF working directory. Restart SNFServer That procedure will cause SNF to build a new GBUdb file from scratch based on what it is learning from that point on. Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Bad rule alert: 1940812
Hello Andrew, Tuesday, June 17, 2008, 4:21:49 PM, you wrote: > Pete, if we have a significant number of hits, they'll be from all kinds > of IP sources. > Should we dump the GBUdb? If so, how? It is unlikely that good IPs will be moved to into the black ranges with a short event like this-- so you should not need to dump GBUdb unless you see GBUdb false positives. The design of GBUdb is such that there is significant inertia for well known IPs -- if they are known to be good -- or at least solidly not bad, then the IPs will not be easily moved into the black ranges. > The documentation is perfectly clear on how to tweak an IP or dump > an IP in the GBUdb, but doesn't mention a wholesale clearing of it. If you do decide to dump your GBUdb then follow this procedure: Stop SNFServer Delete the .gbx file in the SNF working directory. Restart SNFServer That procedure will cause SNF to build a new GBUdb file from scratch based on what it is learning from that point on. Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Bad rule alert: 1940812
Pete, if we have a significant number of hits, they'll be from all kinds of IP sources. Should we dump the GBUdb? If so, how? The documentation is perfectly clear on how to tweak an IP or dump an IP in the GBUdb, but doesn't mention a wholesale clearing of it. Andrew. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, June 17, 2008 12:46 PM To: Message Sniffer Community Subject: [sniffer] Re: Bad rule alert: 1940812 Hello, --- following up. Intended to make the original post with a high priority flag. Also - the rule was removed at approximately 15:10:00 EDT Hope this helps, _M Tuesday, June 17, 2008, 3:35:47 PM, you wrote: > Hello Message, > Rule 1940812 has already been removed from the core rulebase. > You can render the rule inert immediately by adding it to your rule > panics list. > Rule was coded at 13:03:17 EDT > The rule was coded for an obfuscated version of the word Tuesday and > was coded with a bad abstraction character. > We sincerely apologize for the inconvenience. > Best, > _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Bad rule alert: 1940812
Hello, --- following up. Intended to make the original post with a high priority flag. Also - the rule was removed at approximately 15:10:00 EDT Hope this helps, _M Tuesday, June 17, 2008, 3:35:47 PM, you wrote: > Hello Message, > Rule 1940812 has already been removed from the core rulebase. > You can render the rule inert immediately by adding it to your rule > panics list. > Rule was coded at 13:03:17 EDT > The rule was coded for an obfuscated version of the word Tuesday and > was coded with a bad abstraction character. > We sincerely apologize for the inconvenience. > Best, > _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
