News & Updates

2008-04-25 New version: Engine 24, MDPlugin 6

This release is an upgrade more than a bug fix. Replace your SNFServer.exe or snfmdplugin.dll as appropriate.

No changes have been made to the configuration file.

This version improves memory management in the SNF Engine for improved performance, improves the header injection mechanism for improved reliability, and improves logging for IP scans done with the MDaemon plugin.

As usual you can get the latest distributions here:

http://kb.armresearch.com/index.php?title=Message_Sniffer. GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

Here is an excerpt from the change log (this time from the MDaemon plugin change log since it contains all changes from the last version):

20080424 - Version V2-9rc6.24.6

• Refactored snfScanData.clear() to reduce heap work and fragments.
• Added mutex to scanMessageFile() entry point just in case some app attempts to put multiple threads through a single engine handler. scanMessage() is already protected and fully wraped by the new scanMessageFile() mutex.
• Added non-specific runtime exception handling to XHDR injection code.
• Added 2 retries w/ 300ms delay to remove original message in XHDR inject code. If remove fails after 3 attempts the injector throws.
• Added 2 retries w/ 300ms delay to rename temp file to msg in XHDR inject code. If rename fails after 3 attempts the injector throws.
• Added IPTest logging.

2008-04-16 New Version: Engine 23 - fix for network bug on some win* systems.

This update fixes a bug that effects some Win* systems.

Please replace your SNFServer or snfmdplugin.dll and your SNFClient.

You can always get the latest distribution here:

http://kb.armresearch.com/index.php?title=Message_Sniffer. GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

Here is a snippet from the change log:

20080416 - Version V2-9rc2.23.6

• Fixed bug where SNCY open() would fail on some Win* platforms with WSAEINVAL instead of the standard EINPROGRESS or EALREADY which were expected. Also added WSAEWOULDBLOCK to cover other "ambiguities" in windows sockets implementations. InProgress() on Win* now test for any of:
  
  WSAEINPROGRESS, WSAEALREADY, WSAEWOULDBLOCK, WSAEINVAL

2008-04-13 New Version SYNC bug fix! SNFEngine 22

It seems that in our last update we introduced a bug that effects SYNC operations for some customers - particularly those with longer network transit times to our servers.

The bug could cause SYNC sessions to fail either consistently or intermittently depending on the transit time. If SYNC sessions consistently fail then the new UpdateReady feature will not fire. GBUdb collaboration is also diminished with failed SYNC sessions.

A new version has been posted that solves this problem. Please upgrade your SNFServer or snfmdplugin.dll files from the new distributions as soon as possible to avoid missing telemetry, UpdateReady information, and GBUdb collaboration traffic.

We have also included a new build of the SNFClient program since it uses the same networking library. Although it is unlikely this bug would cause a problem with the SNFClient program you should update to the newest build to be sure.

No configuration changes are necessary with this update.

Here is a description of the changes in this newest distribution:

20080413 - Version V2-9rc2.22.6

• Fixed bug in TCPHost.open() where [WSA]EALREADY was not counted as a version of [WSA]EINPROGRESS. This would cause open() to throw an unnecessary exception when a socket open() required extra time.

20080413 - Version V2-9rc2.21.6

• Extended timeout for SYNC session open() to the full session length. This way if a session takes a long time to open it still has a shot at success.

2008-04-11 Latest RC release SNFMulti 20, SNFServer 2, SNFClient 6, MDaemon 5

The newest RC release has been posted in the usual location:

http://kb.armresearch.com/index.php?title=Message_Sniffer. GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

There are NO changes to the configuration file. You need only replace SNFServer.exe and SNFClient.exe and/or snfmdplugin.dll (as appropriate to your system). This release resolves all known bugs / tweaks.

Snippets from the change log:

20080411 - Version V2-9rc2.20.6

• Adjusted snfNETmgr to use non-blocking open in SYNC sessions. Open timeout is 1/3 of the session timeout. Session timeout is 2 * Session pacing. Open polling uses golden spiral delay from 10ms to 340ms.

20080410 - Version V2-9rc2.19.6

• Adjusted XCI manager to use new snfCFGPacket paradigm in checkCFG().
• Adjusted snf_RulebaseHandler::addRulePanic() to use MyMutex and eliminated the AutoPanicMutex and waiting scheme.
• Refactored scanMessage() to use a ScopeMutex() rather than lock()/unlock().
• Refactored scanMessage() to use MyCFGPacket.isRulePanic() test.
• Redesigned snfCFGPacket handling to automate grab() / drop() functions.
• Fixed lock-up bug: Redesigned AutoPanic posting and checking mechanisms to eliminate potential dead-lock condition. Under some conditions a precisely timed auto-panic posting could cause the RulebaseHandler mutex and the AutoPanicMutex to become intertwined leading to a cascading deadlock. When this occurred all XCI processing threads and eventually the XCI listener thread would become blocked waiting to get the current configuration.

20080409 - Version V2-9rc2.18.6

• Enhanced XCI exception handling and logging to provide additional detail.
• Added code to explicitely check for zero length files in scanMessagFile().Previously a zero length file would cause the CBFR module of the filter chain to throw an invalid buffer exception. Now if the message file is empty scanMessageFile() will throw a FileError stating FileEmpty!.

20080407 - Version V2-9rc2.17.6

• Enhanced exception reporting in snfXCImrg

2008-04-05 New Version Engine: 16, Client 6

The newest distributions for the Command Line (Std Test Package), MDaemon plugin, and Source have been posted. You can find them here as always:
http://kb.armresearch.com/index.php?title=Message_Sniffer.GettingStarted.Distributions

This update is important because it includes a bug fix to the networking library. This update also includes some tweaks intended to improve network performance under heavy traffic conditions.

Please upgrade to the new DLL, SNFClient, and SNFServer. There is no need to change your configuration file ;-)

A snippet from the change log:

20080405 - SNFServer V2-9rc2.16.6

• Reduced safety limits on status reports to 100K for status reports and 100K for samples. Previous values were 10M. Most full sessions from the busiest systems are < 50K total.
• Recoded sendDataTimeout() to break uploads into 512 byte chunks and insert delays only when a chunk is fragmented. This methodology improves reliability on Win* systems without any significant penalty on systems that don't need socket sends() to be in smaller chunks.
• Fixed TCPClient::transmit() and TCPHost::transmit() bug where returned byte count might be -1. Now returned byte counts can only be 0 or more.

2008-03-27 More progress SNF2-9 SNFMulti engine goes to version 15

Short version:

Here is a new beta/rc release. The changes are internal and should solve a bug that happens on a handfull of systems. You should upgrade so that you're on the latest version. If you're not having trouble you can put off upgrading until some later time (but not too long please).

Please find the newest release here:

http://kb.armresearch.com/index.php?title=Message_Sniffer. GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

The long version:

This release goes further to eliminate the "hanging" bug on those few systems that see it. One case should be solved completely by this revision and possibly all cases (we shall see).

This release also eliminates a minor bug (not worth a revision) that was in the previous release. It seems I failed to remove a line of code that forces the Debug mode in SNFServer before pushing out the last release -- so SNFServer in the previous release would be in debug mode no matter what -- thus creating extra monitor data on the screen (if not run as a service or piped to /dev/null).

The big change in this release is in the snfNETmgr module that handles SYNC operations (GBUdb & Telemetry). The previous version used blocking IO and a separate thread (TCPWatchdog) to kill off connections that lasted too long. The new version uses non-blocking IO and has been refactored to consolidate some of it's communications routines.

In one case the "hanging" bug presented as a loss of telemetry without errors or exceptions. It appeared from the debug data that the snfNETmgr thread had gotten stuck in an IO call and that even though the TCPWatchdog thread had killed the connection the function call never returned.

The theory supporting this change is that after some number of these TCPWatchdog events the TCP stack might become unstable on some systems and cause this kind of behavior. The new non-blocking methodology eliminates this possibility.

It is possible, if the above theory is true in any way, that this change will solve the other "hanging" cases also -- In those cases the snfXCImgr thread appears to get stuck while attempting to accept() another client. If the TCPWatchdog methodology used before did cause instability in some way to cause this, then this presentation of the "hanging" bug should also disappear.

If the new revision doesn't solve the XCI related "hanging" bug then the addition of very detailed status tracking in the snfXCImgr module should help us see more clearly where to look.

Excerpts from the change log:

20080326 - SNFServer V2-9rc2.15.4

• Refactored snfNETmgr::sync() to consolidate non-blocking io routines.
• Added detailed thread status data to XCI listener thread.
• Fixed minor bug in main (not changing revision), Debug flag for internal use was left on in the last build cycle. It is commented out now.

20080325 - SNFServer V2-9rc2.14.4

• Updated snfNETmgr with comprehensive thread status data.
• Refactored snfNETmgr::sync() to check a Timeout, removed TCPWatchdog.

20080325 - SNFServer V2-9rc2.13.4

• Upgraded TCPWatcher code to use new threading features (type, status).

2008-03-25 New 2-9rc Versions Posted Client - v2, Server - v4, MDaemon DLL v4, Engine v12

Three new releases today:

SNFv2-9rc2.12.4.StdTestPackage.zip
SNFv2-9rc4.12.4.MDaemon.zip
SNFv2-9rc2.12.4.source.zip

You can find them here as usual:
http://kb.armresearch.com/index.php?title=Message_Sniffer. GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

Some items of note:

There is an obscure, intermittent bug in SNFServer that has been reported on a handfull of systems. The vast majority of systems run normally (including our lab systems) for hundreds of days -- only stopping when we tell them to.

The bug manifests as either:

SNFServer stops listening for requests.
OR
SNFServer stops sending telemetry.

In both of the above cases there are no errors in the logs, no core dumps, no unhandled exceptions, no corruption of any kind--

Only two cases show any kind of pattern so far:

• In one case SNFServer will stop sending telemetry after approximately 1 day give or take a few hours. Scanning and all other functions continue normally.
• In another case SNFServer appears to stop accepting requests via XCI after approximately one week give or take a few days.
• Other cases are completely random (est fewer than 5 cases total).

If you come across this scenario please let us know all of the data you can about the situation and then please run your SNFServer in debug mode (see next item) to help us track down this critter.

SNFServer now has a debug mode. If "debug" or "Debug" are found in the path to the SNFServer.exe then debug mode is turned. Most commonly to run SNFServer in debug mode rename it to SNFDebugServer.exe.

When in debug mode SNFServer will make a thread status report to the console once per second along with the usual activity information. The idea is to pipe all of this information to a log file so that when the above bug occurs we can record the status of all of the active threads at that time, before, and after.

For example:

/SNF/SNFServer.exe /SNF/snf_engine.xml > debuglog

---- now some good news ---

There is a new feature in SNFServer. When there is a new rulebase file available SNFServer can call a user-defined script to retrieve the new rulebase file. We've also provided that script and set up the default settings to call it ;-)

The script name is getRulebase.cmd on Win* systems and simply getRulebase on *nix systems. Please read the readme files and check your configuration files to make sure that the script is setup properly for your system. Wget and Gzip utilities are included in all of the above distributions for your convenience.

If the script fails to replace the rulebase file then it will be retried after 3 minutes (default). Retries will continue until the script is successful.

-- The feature can be turned off.

-- SNFServer still produces an UpdateReady.txt file so if you want to continue using that methodolgy nothing will break -- though you should turn off the in your config file.

-- If you write your own script or want to launch the script some other way (such as calling cmd or start with special options) then you can do that -- but be careful! The update-script engine runs in it's own thread and makes a system() call when triggered. If your script fails to return then the update-script thread will be stuck waiting for it to return. Remember: what you put into the call= attribute will be passed to system() when the feature is triggered. The best way to do anything special there is to write a script that does what you want and have the update-script mechanism call that script. It's probably not a good idea to put a lot of special switches and "other craziness" in the call= attribute --- If you need them, put them in your script and keep the call= simple :-)

2008-03-20 MDaemon Plugin SNFv2-9rc4.11.4 Posted

I have just posted the latest beta (release candidate) MDaemon plugin.

You can find the latest betas here:

http://kb.armresearch.com/index.php?title=Message_Sniffer. GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

This distribution includes an automated update utility that is triggered from the SNFServer engine running in the plugin. When a newer rulebase file is available an UpdateAvailable.txt file is created in the SNF directory. The getRulebase.cmd script can be scheduled to run once per minute. When the UpdateAvailable.txt file is present the script will download, validate, and install the latest rulebase file. Before using the getRulebase.cmd script be sure to edit the top of it to establish the correct working directory, license ID, and authentication string.

Engine improvements and updates to the SNFClient utility are also included...

A few excerpts from the change log:

20080319 - Version SNF2-9rc4.11

• Added IPScan on-off to snfmdplugin.xml. This allows users to turn off the IPScan feature without editing the Plugins.dat file as was previously required. The feature can now be enabled or disabled at will by editing the configuration file.
• Added Configuration editor options to snfmdplugin.xml. Previously the built- in configuration function was hard coded to start notepad with the config file. Now the system() call made by the ConfigFunc() can be edited in the configuration file. The configuration file name can be appended to the command optionally. The default is still to start notepad and append the configuration file path so that it is loaded automatically. It is hoped that GUI based configuration editors for the SNF plugin will be built by third parties and in the mean time folks can now configure their favorite XML file editor to modify their SNF plugin configuration.
• Modified API use fixed shutdown bug - The plugin used to initialize the SNF scanning engine when the DLL was loaded and would shut it down when the DLL was unloaded. Now the Startup and Shutdown functions in the MDaemon plugin API. This ensures that the engine components are started and shutdown in the proper sequence.
• Included new SNFEngine core (excerpts from that change log included).

20080318 - SNF2-9rc1.11.exe Consolidated several mods/fixes

• Corrected scan error logging bug. Was posting <s/> now posts <e/>.
• Updated scan error logging to be more uniform with non-scan errors.
• Enhanced error and exception reporting in SNFMulti.cpp scanMessageFile().
• Enhanced exception handling in networking module. All exceptions now throw descriptive runtime_error exceptions.

2008-03-07 Version 2-9rc1.8.2 Release Candidate (Std Test Package) Released

This is the first release candidate for what will become version 3 this quarter!

You can find the latest updates here as they arrive:

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 version 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.

2008-03-05 MX Uptime adds Fully Integrated SNF!

The newest version of Message Sniffer is now an integral component of MX Uptime's plugin for MailEnable. Anyone wishing to use SNF only needs to enter their license ID and authentication string, then check the box :-) Screenshot for integration.

Archive