Hi Pete, >> You can drop the record for the IP from GBUdb with SNFClient -drop <IP>, but if the system is not configured properly then the IP will quickly rise back into the truncate list. <<
The IP address in question was a third party IP address, not related to us, not a gateway. It was not in the ignore list and shouldn't be - does that qualify as "configured properly"? >> If that is being caused by a pattern rule then you need to discover the pattern rule from logs first and then panic that rule and report the FP.<< Hm - so if we have such a GBUdb FP issue, we would need to first go into the log for the message ID in question and locate the IP address. THEN, we have to search the log files to find where this IP address may have occurred (possibly several days of logs, before someone noticed legitimate email from being missing) in hopes of eventually still finding some log entry that relates to the original rule-ID, before we can add it to the panic list? I suppose it would be technically impossible to include the underlying rule in the GBUdb, so that it can be properly reported when messages are blocked? >> Are you reporting such an FP?<< Yes, your FP support identified the underlying rule and reported it back to me. Of course, I need to have a panic procedure in place that doesn't rely on outside assistance. Doesn't happen often, but better ask the questions now than when the brown matter hits to air circulation enhancer. Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, October 07, 2008 1:59 PM To: Message Sniffer Community Subject: [sniffer] Re: How to deal with False Positives and other Documentation Issues Hello Andy, Thanks for this -- I will address the documentation issues shortly. Regarding GBUdb FP issues-- to date we've not had a truncate (result code 20) false positive report from any system that was configured properly. Are you reporting such an FP? Depending upon the circumstances you may want to add the IP to your ignore list. You can drop the record for the IP from GBUdb with SNFClient -drop <IP>, but if the system is not configured properly then the IP will quickly rise back into the truncate list. If that is being caused by a pattern rule then you need to discover the pattern rule from logs first and then panic that rule and report the FP. Hope this helps, _M Remainder for reference... Tuesday, October 7, 2008, 12:58:43 PM, you wrote: > Hi, 1. I read this page: <http://www.armresearch.com/support/articles/procedures/falsePositives.jsp> http://www.armresearch.com/support/articles/procedures/falsePositives.jsp and it seems to be the same. However, should this chapter be expanded to contain information about what to do if some of the new technologies are responsible for the false positive? The "panic rule" instructions don't really apply in cases like this where there IS no rule: <s u='20081007153730' m='D:\IMail\spool\proc\work\D822c01990000026c.smd' s='20' r='0'> <p s='0' t='0' l='10306' d='0'/> <g o='0' i='207.45.161.16' t='u' c='0.226425' p='1' r='Truncate'/> </s> Instead you should have some ready-made sample that shows how to except an IP that has ended up on the Truncate list, or at least move it to the "caution" list? 2. The explanation of the Log files is incomplete: <http://www.armresearch.com/support/articles/software/snfServer/logFiles/act ivityLogs.jsp> http://www.armresearch.com/support/articles/software/snfServer/logFiles/acti vityLogs.jsp As you can see from the log snippet I posted, there is a node s:r=0. However, s:r is not in the documentation. Best Regards, Andy -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. 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]>
