[sniffer] Re: Message Sniffer question
It works for me. Thanks, Pete! I used the documentation here: http://www.armresearch.com/support/articles/software/snfServer/config/au toUpdates.jsp I wanted a simplified system that more closely reflected what the vendor ships, so I've stopped using my home-grown wget based script which was run hourly from the Windows Task Scheduler with a dedicated local user account. Andrew. From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Tuesday, April 21, 2009 3:25 PM To: Message Sniffer Community Subject: [sniffer] Re: Message Sniffer question Scott Fisher wrote: If I remember correctly... I have an email account with a Imail program alias, that when it gets a mail from Message Sniffer triggers an update. It's still getting mail and triggering updates. I'm thinking this isn't need with Sniffer v3 anymore? That's correct. Version 3 has an update script launcher that fires when SNF detects a newer rulebase is ready. If you have that configured properly then no other update mechanism is needed. If you want to disable update notifications then send a note to support@ and we will turn them off for you. Best, _M
[sniffer] overriding the GBUdb
I recently used snfclient.exe to whitelist the IP address (actually a whole /24) of a mailing list manager that my users deem to be trustworthy. snfclient.exe -set 64.62.197.53 good - - You might argue the merits of this IP address, but that's not why I'm writing... I deliberately left alone the last two parameters, so as to not disturb the counts, given that I'm whitelisting by forcing the good flag. I assume that this does not affect the GBU community at all, because it's the good and bad counts that are shared, not the flag. Is this correct? Does the ARMResearch support notice when an administrator does this, and research whether the findings are good? The Bad count and Good count I see when I do a: snfclient.exe -test 64.62.197.53 are results only on my own server, and not the GBU community. Is this correct? I assume that condensation affects the counts, and not the flag. So I will only lose this good flag if the GBUdb is dumped (or I build a new server). Is this correct? Andrew 8)
[sniffer] Re: overriding the GBUdb
Colbeck, Andrew wrote: I recently used snfclient.exe to whitelist the IP address (actually a whole /24) of a mailing list manager that my users deem to be trustworthy. snfclient.exe -set 64.62.197.53 good - - You might argue the merits of this IP address, but that's not why I'm writing... I deliberately left alone the last two parameters, so as to not disturb the counts, given that I'm whitelisting by forcing the good flag. I assume that this does not affect the GBU community at all, because it's the good and bad counts that are shared, not the flag. Is this correct? That is correct. Does the ARMResearch support notice when an administrator does this, and research whether the findings are good? No. We wouldn't know how to evaluate that anyway-- each system has it's own policies. GBUdb traffic consists only of good/bad counts at specific intervals. If the IP is not ugly it doesn't get evaluated in this way so we stop seeing data about that IP from that system. The Bad count and Good count I see when I do a: snfclient.exe -test 64.62.197.53 are results only on my own server, and not the GBU community. Is this correct? They were built up using primarily data from your server with some hinting from the cloud. The cloud's influence is diminished significantly as your system gains experience with a particular IP. I assume that condensation affects the counts, and not the flag. So I will only lose this good flag if the GBUdb is dumped (or I build a new server). Is this correct? If you wipe out your GBUdb data then it will be gone. Flags other than ugly are preserved in GBUdb. If you buid a new server and you want to preserve your GBUdb data then you can copy the .gbx file to the new server before you start it. The .gbx file is a binary snap-shot of your GBUdb data. By default it is created about once per hour so that your SNF node does not have to start learning again from scratch if it is abruptly restarted. Please let us know if you have other questions. Best, _M
[sniffer] Re: overriding the GBUdb
That will do! I've created a batch file in which I'll put my snfclient commands and my dated documentation/rationale for those, but I'll keep using the standard GBUdbIgnoreList.txt for documenting my gateways. I'll also suggest that in the online documentation, that a link in the GBU section goes back to the SNFClient section so that it's easier for an admin to find the right syntax for using the client to manipulate the GBUdb, e.g. http://www.armresearch.com/support/articles/technology/GBUdb/index.jsp perhaps directly here on on the Maintenance page that shows how to use the ignore parameter, a link would go back to: http://www.armresearch.com/support/articles/software/snfClient/commandLi ne.jsp which is where the detailed command line documentation is listed. And although it rarely comes up as a support issue, I'll also suggest that the quick help for SNFclient could be clarified. It currently is this: To update GBUdb records use: SNFClient.exe -set IP4Address flag bad good and my suggested easier-to-read version is this: To update GBUdb records use: SNFClient.exe -set IP4Address good|bad|ignore|ugly|- badcount|- goodcount|- Andrew. From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Thursday, April 30, 2009 1:14 PM To: Message Sniffer Community Subject: [sniffer] Re: overriding the GBUdb Colbeck, Andrew wrote: I recently used snfclient.exe to whitelist the IP address (actually a whole /24) of a mailing list manager that my users deem to be trustworthy. snfclient.exe -set 64.62.197.53 good - - You might argue the merits of this IP address, but that's not why I'm writing... I deliberately left alone the last two parameters, so as to not disturb the counts, given that I'm whitelisting by forcing the good flag. I assume that this does not affect the GBU community at all, because it's the good and bad counts that are shared, not the flag. Is this correct? That is correct. Does the ARMResearch support notice when an administrator does this, and research whether the findings are good? No. We wouldn't know how to evaluate that anyway-- each system has it's own policies. GBUdb traffic consists only of good/bad counts at specific intervals. If the IP is not ugly it doesn't get evaluated in this way so we stop seeing data about that IP from that system. The Bad count and Good count I see when I do a: snfclient.exe -test 64.62.197.53 are results only on my own server, and not the GBU community. Is this correct? They were built up using primarily data from your server with some hinting from the cloud. The cloud's influence is diminished significantly as your system gains experience with a particular IP. I assume that condensation affects the counts, and not the flag. So I will only lose this good flag if the GBUdb is dumped (or I build a new server). Is this correct? If you wipe out your GBUdb data then it will be gone. Flags other than ugly are preserved in GBUdb. If you buid a new server and you want to preserve your GBUdb data then you can copy the .gbx file to the new server before you start it. The .gbx file is a binary snap-shot of your GBUdb data. By default it is created about once per hour so that your SNF node does not have to start learning again from scratch if it is abruptly restarted. Please let us know if you have other questions. Best, _M
