SNF_Server V3.0 installation brief Copyright (c) 2010 ARM Research Laboratories This is a generalized guide. For specific platform guides see: http://www.armresearch.com/support/articles/installation/index.jsp Create a directory for SNF_Server. ( c:\SNF or /var/spool/snfilter ) Copy all of the files to that directory. Make a copy of the SNFServer.exe file and give it the name SNFServer.exe. Later on if newer versions are provided you will be able to keep track of them by name and swap newer versions into place by copying them over your SNFServer.exe file. If you decide you have to go back to a previous version then you will be able to do that easily by deleting your SNFServer.exe file and copying the version you wish to use into place. Modify the identity.xml file to match your SNF license ID and your authentication string. Download your .snf file and place that in the SNF_Server working directory. RULEBASE UPDATES (NEW!): The latest version of the SNFServer engine includes a mechanism that will run an a script when the rulebase file on our server is newer than the active file in SNF. By default this feature is configured to run the included getRulebase script. If the script is not successful it will be launched again every 3 minutes until the rulebase file is successfully updated. Be sure to modify the top of the getRulebase script to include your correct license ID, authentication string, and working directory. Be sure to verify that the section of your snf_engine file is correct (points to the correct location of getRulebase). getRulebase uses wget and gzip (included for your convenience in the Win* distribution. See About-Wget-and-Gzip.txt.). These are open source utilities for downloading files from web servers and unzipping those files -- in this case, SNF rulebase files. If you have any gateways or other internal systems that will relay mail to SNF then include their IPs in GBUdbIgnoreList.txt. The GBUdb component of SNF uses the IPs in this list to determine the actual source IP for a message by reviewing the Received headers. Each Received header is evaluated in turn. If the source (connect) IP is found in the Ignore list then that Received IP is considered to be part of your infrastructure and is ignored. The first Received IP found that is NOT in the Ignore list is selected as the source IP. The GBUdbIgnoreList is a "safety net" that ensures the listed IPs are present in your GBUdb with their Ignore flag set. It is loaded every time the configuration is changed, SNFServer is started, or a new rulebase is loaded. This way if your GBUdb database is lost then your critical infrastructure will be re-listed in the new .gbx file that is created. The ignore list allows only SINGLE IP ENTRIES. This can be a problem in some cases - such as when you want to ignore large blocks of network addresses. SNF can learn to Ignore large blocks of IPs using the feature. For example if you want to ignore all of 12.34.56.0/24 then you can make an entry in the training section like this: ... ... GBUdb learns the behavior of source IPs so it is important that GBUdb knows any friendly sources that might send spammy messages to your server or else it will learn that those sources are not to be trusted. Since not all friendly spam sources can be identified by IP ahead of time, there are features in the section of snf_engine.xml that allow you to adjust the training scenarios to compensate. The most likely of these is that you may wish to bypass training for messages that are to your support addresses or spam submission addresses. For example: ...
... Evaluate the snf_engine.xml file carefully. In most cases the default settings are appropriate, however you may want to alter some of the settings to match your system policies or particular installation. IMPORTANT: Be sure that any file paths / directories referenced in the configuration file exist on your system and that SNF has full access rights to these - especially the SNF working directory. ** If you selected a working directory for SNF other than c:\SNF\ then be sure you have changed these paths in the top of your snf_engine.xml file. Pay close attentiont to these 5 elements: Once you are happy with your configuration and you have all of your files and directories in place (including your .snf file) then you can start SNF_Server. The command line (from inside the SNF workspace) is: SNFServer.exe snf_engine.xml That is: SNFServer If you want to lauch SNFServer from some other location it would be best to use the entire path for both the SNFServer engine and the configuration file: c:\SNF\SNFServer.exe c:\SNF\snf_engine.xml You should begin by testing SNFServer by running it in a command line window where you can watch it's output. Once you are happy with it then you will probably want to run it as a service using a utility such as the srvany utility from the win2k toolkit, or detached as a daemon on *nix systems (snfctrl file example included). This section of our site might be helpful: http://www.armresearch.com/support/articles/installation/serviceSetup/index.jsp SNFServer is the server side of a client/server system. In order to scan messages you will need to use the client utility (SNFClient.exe or SNFIMailShim.exe) to scan messages. SNFClient.exe is a drop-in replacement for the production (2-3.x) SNF program when it is called from Declude or mxGuard or other similar software. There is no need to "brand" the SNFClient.exe program and it is not necessary to include the authentication string on the command line -- however, if you do it will be accepted and ignored without an error. SNFServer MUST be running for SNFClient to work. If SNFClient cannot reach SNFServer then it will wait for quite a while as it attempts to make contact. Here are a few ways to call SNFClient.exe: SNFClient.exe -shutdown Sends the Shutdown command to the SNF_Server. SNFClient.exe authenticationxx filetoscan Compatibility mode - ignores authenticationxx and scans filetoscan. SNFClient.exe filetoscan Normal scan mode - scans filetoscan. SNFClient.exe -xhdr filetoscan XHDR scan mode - scans filetoscan and returns X Headers. See the SNFClient_Readme.txt file for details. The SNF Client/Server pair communicate using short XML messages via a local TCP connection (typically to port 9001). Examples of SNF_XCI messages are included in snf_xci.xml (not a well formed xml file! - just some examples). It is possible to communicate directly with the SNF_Server engine via TCP from your software using the SNF_XCI (SNF XML Command Interface) protocol. The server expects to see one connection per request. The client sends an SNF_XCI request to the server. The server responds with an appropriate SNF_XCI formatted response and terminates the connection. Requests and responses are expected to terminate with a newline character. You can see the XCI protocol at work by running the SNFClient in debug mode (SNFdebugClient). If you run into trouble check out our web site: www.armresearch.com and/or contact us by email: support@armresearch.com ____________________ For More Information See www.armresearch.com Copyright (C) 2007-2008 Arm Research Labs, LLC.