Hello Sniffer Folks, Today I'm releasing the first release candidate for what will become version 3 this quarter!
You can find the latest here as it arrives: http://kb.armresearch.com/index.php?title=Message_Sniffer.GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta Over the next few days we will be updating the MDaemon DLL with the new engine and a new feature or two. Then we will update the source distribution for *nix & OEM systems. Then we will be launching two SDKs -- one is a .SO for *nix systems and the other is a DLL for Win* systems. Along the way we will be launching a new web site with documentation for the new version. Then later this year (Q2 - Q3 perhaps) we'll be launching DNS based IP reputation services. For now -- back to this moment in time and the new SNFServer and SNFClient release. There are extensive updates to both the client and server programs. Be sure to go through the readme files if you are upgrading. Also - if you are upgrading you will want to update your snf_engine.xml file to cover the new features. (GHASP! What if I forget to do that?!!) -- If you don't get to it right away then your existing snf_engine.xml file will work fine... but do get the update process on your to-do list so you can take advantage of the new features and improved default settings. Here is a chunk of the change log to show you what is new since verion 2-9b1.5.1: 20080306 - SNF2-9rc1.8.exe (FIRST RELEASE CANDIDATE for VERSION 3!) Added Drilldown Header Directive Functions - When the candidate source IP comes from a header matching a drilldown directive the IP is marked "Ignore" in GBUdb and the candidate is no longer eligible to be the source for that message. This allows SNF to follow the trusted chain of devices (by IP) down to the actual source of the message. It is handy for ignoring net blocks because it can match partial IPs but it is designed to allow SNF to learn it's way through the servers at large ISPs so that the original source for each message can be evaluated directly. Added Source Header Directive Functions - This feature allows SNF to acquire the source IP for a message from a specific header rather than searching through the Received headers in the message. This is useful when the original source for a message is not represented in Received headers. For example: Hotmail places the originating source IP in a special header and does not provide a Received header for that IP. This feature is protected from abuse by a "Context" feature which only activates the source header directive when specific content is found in a specific received header. Using the above example, this feature can be configured so that a Hotmail source header would only be read if the top Received header contained "hotmail.com [" indicating that the ptr lookup for the header matched the hotmail domain. Note: When a source is pulled from a header directive that source is put into a synthetic Received header and injected into the scanning stream (not the message) as the first Received header. Added forced source IP to XCI - It is now possible to "inject" or "force" the source IP for any message by providing that IP in the XCI request or directly in a scan...() function call. This allows the calling application to provide the source IP for a message ahead of any Received headers that might be in the message. This is useful when the calling application knows the original source IP for the message but that IP is not represented in the Received headers and it is not desireable to use the Source Header Directive mechanism. Added forced source IP mode to SNFClient - It is now possible to call the SNFClient utility with an IP4Address using the syntax: SNFClient -source=12.34.56.78 The -source mode of SNFClient exercises the forced source IP feature in the XCI (see above) Added Status Report features to SNFClient and XCI - It is now possible to request the latest status.second, status.minute, or status.hour data via the XCI and SNFClient. The syntax for requesting a status report using the SNFClient is: SNFClient -status.second SNFClient -status.minute SNFClient -status.hour In addition to providing status reports the SNFClient in this mode will return a nonzero value (usually 99) if it is unable to get a status report from SNFServer. This feature can be used to verify that SNFServer is up and responding. If SNFServer is OK then the result code returned is 0. Added result codes to SNFClient -test and XCI IP test functions - The XCI engine has been upgraded to provide the range value for the IP under test as well as the symbolic result code associated with that range. This allows the -test function to provide results that are consistent with the GBUdb configuration without additional processing: For example, if the IP falls in the Caution range then the Caution result code will be returned just as if a message had been scanned with the same IP and no pattern match occurred. The same is true for Truncate and Black range hits. Added Timestamp and Command Line Parameter data to SNFClient.exe.err - When an error occurs with SNFClient that may not appear in the SNFServer logs an entry is appended to the SNFClient.exe.err file. That in itself is not new. The new feature is that the entries added to the SNFClient.exe.err file now include timestamp and command line data to aid in debugging. Added BIG-ENDIAN Conversion - When the SNFServer program is compiled on a system that uses a BIG-ENDIAN processor (such as a power-mac) the rulebase load process now includes a routine to convert the token matrix from it's native LITTLE-ENDIAN format to a BIG-ENDIAN format. This solves a bug where Power-Mac (and presumably other BIG-ENDIAN systems) could compile and run the SNF* software but were unable to capture spam because the token matrix in the rulebase file was misinterpreted. Note: The BIG-ENDIAN Conversion feature is still considered experimental because it has not yet been thoroughly tested. Updated the Configuration Log to include all of the current configuration features and to improve it's readability. 20080207 - SNF2-9b1.7.exe SYNC Timeout now 2x SYNC Schedule SNFServer now produces an UpdateReady.txt file when the UTC timestamp on the SYNC server is newer than the UTC timestamp of the active rulebase. It is presumed that a suitable update script or program will run periodically and download a fresh rulebase file if the UpdateReady.txt file is present. The update script should remove the UpdateReady.txt file when it completes a successful download of the new rulebase file. Added available rulebase UTC in status reports <udate utc.../> Added Automatic path fixup for ending / or \ Added option to use local time in log rotation <rotation localtime='no'/> The default is still utc. 20071102 - SNF2-9b1.6.exe Increased MAX_EVALS from 1024 to 2048. Adjusted defult range envelopes in snf_engine.xml to be more conservative. -- 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]>
