You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

SNFServer_readme.txt 7.7KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198
  1. SNF_Server V3.0 installation brief
  2. This is a generalized guide. For specific platform guides see:
  3. http://www.armresearch.com/support/articles/installation/index.jsp
  4. Create a directory for SNF_Server. ( c:\SNF or /var/spool/snfilter )
  5. Copy all of the files to that directory.
  6. Make a copy of the SNFServer<version>.exe file and give it the name
  7. SNFServer.exe. Later on if newer versions are provided you will
  8. be able to keep track of them by name and swap newer versions into
  9. place by copying them over your SNFServer.exe file. If you decide
  10. you have to go back to a previous version then you will be able to
  11. do that easily by deleting your SNFServer.exe file and copying the
  12. version you wish to use into place.
  13. Modify the identity.xml file to match your SNF license ID and your
  14. authentication string.
  15. Download your .snf file and place that in the SNF_Server working
  16. directory.
  17. RULEBASE UPDATES (NEW!): The latest version of the SNFServer engine
  18. includes a mechanism that will run an a script when the rulebase file
  19. on our server is newer than the active file in SNF. By default this
  20. feature is configured to run the included getRulebase script. If
  21. the script is not successful it will be launched again every 3 minutes
  22. until the rulebase file is successfully updated.
  23. Be sure to modify the top of the getRulebase script to include
  24. your correct license ID, authentication string, and working directory.
  25. Be sure to verify that the <update-script/> section of your snf_engine
  26. file is correct (points to the correct location of getRulebase).
  27. getRulebase uses wget and gzip (included for your convenience in
  28. the Win* distribution. See About-Wget-and-Gzip.txt.). These are open
  29. source utilities for downloading files from web servers and unzipping
  30. those files -- in this case, SNF rulebase files.
  31. If you have any gateways or other internal systems that will relay
  32. mail to SNF then include their IPs in GBUdbIgnoreList.txt. The GBUdb
  33. component of SNF uses the IPs in this list to determine the actual
  34. source IP for a message by reviewing the Received headers. Each
  35. Received header is evaluated in turn. If the source (connect) IP is
  36. found in the Ignore list then that Received IP is considered to be
  37. part of your infrastructure and is ignored. The first Received IP
  38. found that is NOT in the Ignore list is selected as the source IP.
  39. The GBUdbIgnoreList is a "safety net" that ensures the listed IPs are
  40. present in your GBUdb with their Ignore flag set. It is loaded every
  41. time the configuration is changed, SNFServer is started, or a new
  42. rulebase is loaded. This way if your GBUdb database is lost then your
  43. critical infrastructure will be re-listed in the new .gbx file that
  44. is created.
  45. The ignore list allows only SINGLE IP ENTRIES. This can be a problem
  46. in some cases - such as when you want to ignore large blocks of network
  47. addresses.
  48. SNF can learn to Ignore large blocks of IPs using the <drilldown/>
  49. feature. For example if you want to ignore all of 12.34.56.0/24 then
  50. you can make an entry in the <drilldown/> training section like this:
  51. <training on-off='on'>
  52. ...
  53. <drilldown>
  54. <received ordinal='0' find='[12.34.56.'/>
  55. </drilldown>
  56. ...
  57. </training>
  58. GBUdb learns the behavior of source IPs so it is important that GBUdb
  59. knows any friendly sources that might send spammy messages to your
  60. server or else it will learn that those sources are not to be trusted.
  61. Since not all friendly spam sources can be identified by IP ahead of
  62. time, there are features in the <training/> section of snf_engine.xml
  63. that allow you to adjust the training scenarios to compensate. The
  64. most likely of these is that you may wish to bypass training for
  65. messages that are to your support addresses or spam submission
  66. addresses. For example:
  67. <training on-off='on'>
  68. ...
  69. <bypass>
  70. <header name='To:' find='support@example.com'/>
  71. <header name='To:' find='spam@example.com'/>
  72. </bypass>
  73. ...
  74. </training>
  75. Evaluate the snf_engine.xml file carefully. In most cases the
  76. default settings are appropriate, however you may want to alter
  77. some of the settings to match your system policies or particular
  78. installation.
  79. IMPORTANT: Be sure that any file paths / directories referenced in
  80. the configuration file exist on your system and that SNF has full
  81. access rights to these - especially the SNF working directory.
  82. ** If you selected a working directory for SNF other than c:\SNF\
  83. then be sure you have changed these paths in the top of your
  84. snf_engine.xml file. Pay close attentiont to these 5 elements:
  85. <node identity='c:/SNF/identity.xml'>
  86. <log path='c:/SNF/'/>
  87. <rulebase path='c:/SNF/'/>
  88. <workspace path='c:/SNF/'/>
  89. <update-script ... call='c:/SNF/getRulebase.cmd' ... />
  90. Once you are happy with your configuration and you have all of your
  91. files and directories in place (including your .snf file) then you
  92. can start SNF_Server.
  93. The command line (from inside the SNF workspace) is:
  94. SNFServer.exe snf_engine.xml
  95. That is: SNFServer <configuration>
  96. If you want to lauch SNFServer from some other location it would be
  97. best to use the entire path for both the SNFServer engine and the
  98. configuration file:
  99. c:\SNF\SNFServer.exe c:\SNF\snf_engine.xml
  100. You should begin by testing SNFServer by running it in a command line
  101. window where you can watch it's output.
  102. Once you are happy with it then you will probably want to run it as
  103. a service using a utility such as the srvany utility from the win2k
  104. toolkit, or detached as a daemon on *nix systems (snfctrl file example
  105. included).
  106. This section of our site might be helpful:
  107. http://www.armresearch.com/support/articles/installation/serviceSetup/index.jsp
  108. SNFServer is the server side of a client/server system. In order to
  109. scan messages you will need to use the client utility (SNFClient.exe
  110. or SNFIMailShim.exe) to scan messages.
  111. SNFClient.exe is a drop-in replacement for the production (2-3.x)
  112. SNF program when it is called from Declude or mxGuard or other similar
  113. software. There is no need to "brand" the SNFClient.exe
  114. program and it is not necessary to include the authentication string
  115. on the command line -- however, if you do it will be accepted and
  116. ignored without an error.
  117. SNFServer MUST be running for SNFClient to work. If SNFClient cannot
  118. reach SNFServer then it will wait for quite a while as it attempts to
  119. make contact.
  120. Here are a few ways to call SNFClient.exe:
  121. SNFClient.exe -shutdown
  122. Sends the Shutdown command to the SNF_Server.
  123. SNFClient.exe authenticationxx filetoscan
  124. Compatibility mode - ignores authenticationxx and scans filetoscan.
  125. SNFClient.exe filetoscan
  126. Normal scan mode - scans filetoscan.
  127. SNFClient.exe -xhdr filetoscan
  128. XHDR scan mode - scans filetoscan and returns X Headers.
  129. See the SNFClient_Readme.txt file for details.
  130. The SNF Client/Server pair communicate using short XML messages via a local
  131. TCP connection (typically to port 9001). Examples of SNF_XCI messages are
  132. included in snf_xci.xml (not a well formed xml file! - just some examples).
  133. It is possible to communicate directly with the SNF_Server engine via TCP
  134. from your software using the SNF_XCI (SNF XML Command Interface) protocol. The
  135. server expects to see one connection per request. The client sends an SNF_XCI
  136. request to the server. The server responds with an appropriate SNF_XCI
  137. formatted response and terminates the connection.
  138. Requests and responses are expected to terminate with a newline character.
  139. You can see the XCI protocol at work by running the SNFClient in debug mode
  140. (SNFdebugClient).
  141. If you run into trouble check out our web site: www.armresearch.com and/or
  142. contact us by email: support@armresearch.com
  143. ____________________
  144. For More Information
  145. See www.armresearch.com
  146. Copyright (C) 2007-2008 Arm Research Labs, LLC.