|
|
|
|
|
|
|
|
|
|
|
|
|
• IPNetSentry |
||||||||
|
IPNetSentry - Latest Bulletin
Due to the continued introduction of new Internet worms, we have put up this new bulletin page which describes new IPNetSentry features and commands. This page also contains a link to the latest candidate version of IPNetSentry which contains new feature additions and bug fixes.
Please note: we are doing our best to ensure that the candidate software is solid and stable. But as with any candidate software, you may run into specific circumstances where the software does not exactly behave as expected. This iterative process of running software in very diverse real-world environments is what refines a candidate version. We sincerely thank you for your understanding and greatly appreciate your feedback.
No new candidate software at this time.
Download IPNetSentry Official Release v1.3.
October 30, 2001 v1.3
Officially released as IPNetSentry v1.3
October 9, 2001, 4:30 PM EDT v1.3.0c3
Fixed a problem where an aged filter may not properly be removed (by automatically timing out).
October 9, 2001, 11:00 AM EDT v1.3.0c2
IMPORTANT: Fixed a payload matching bug with OTModl$Proxy. Please install v1.3.0c2. Includes OTModl$Proxy v2.1.7c2. You MUST restart your machine after installing this version in order to invoke the new OTModl$Proxy module.
October 8, 2001 v1.3.0c1
IMPORTANT: Performed a major rewrite of how IPNetSentry handles the payload inspection function. This should result in better performance and reliability when detecting worm type intrusions.This change will be transparent to users, but users should inspect their IPNetSentry Config file to make sure their payload inspection commands now look similar to the following:
Note the "1" added to the end of each payload inspection line. This tells IPNetSentry to "tear down" the TCP connection after inserting the block filter. Setting this to "0" (zero) tells IPNetSentry to let the TCP connection to disconnect as normal. We recommend that users normally set the TCP Disconnect flag to "1" so that IPNetSentry actively tears down these unwanted connections.
Technical speak: we moved the payload inspection function from the IPNetSentry application down to the OTModl$Proxy module. This means that payload inspection is now done at system interrupt time and not just when IPNetSentry received enough background task time to complete its activities. In heavily hit systems it appeared that IPNetSentry may have not received enough CPU time in order to complete its filtering activities (for payload inspection). Moving this function to OTModl$Proxy, which operates at system interrupt time, removes this limitation.
October 2, 2001
Fixed two potential problems whereby IPNetSentry could possibly stop receiving new payload inspection messages (thereby appearing to go "deaf" to Code Red and Nimda type intrusions).
September 27, 2001
A bug has been fixed which may have resulted in some servers going "deaf" to new incoming TCP connections. This fix is included with IPNetSentry v1.2.1c4 and later.
Details: some worm agents have apparently been keeping TCP connections open even after the intruding IP address has been blocked by IPNetSentry. This could result in a server going deaf to new incoming connections after some period of time.
Solution: IPNetSentry now actively closes ALL TCP connections which meet any payload inspection parameters. This closure is immediate, and frees the listener for new incoming connections.
September 25, 2001
A bug has been fixed which caused the Aged Filter file to periodically rewrite itself IF the command
saved_aged_filter_file_interval
variable was not set. Example:
#set\saved_aged_filter_file_interval\60
This bug was introduced with v1.2.1c1 which gives users the option of how long an interval should be used between saving the aged filter file.
September 24, 2001
IMPORTANT: We have discovered a 48 byte memory leak each time the Notification routine is called. After thousands of Nimda type hits, this was causing IPNetSentry to use all available system memory.
IPNetSentry v1.2.1c2 and later addresses this problem.
It is recommended that ALL IPNetSentry users who are trying to thwart Nimda type intrusions immediately download and install v1.2.1c2.
September 21, 2001
The Nimda worm seems to be playing havoc on networks all over the world. Many Mac users who are running web servers (e.g. WebStar) report their logs being filled with "cmd.exe", "root.exe", etc. page requests.
The new payload inspection facility released in IPNetSentry v1.2, which was developed to impede the Code Red worm, works very well in many environments where the following additional commands are added to the IPNetSentry Config file: (click here for more information about manually editing the IPNetSentry Config file).
In high-speed network environments, however, the above payload inspection commands may not be enough.
IPNetSentry v1.2.1 augments the above payload inspection commands with an additional argument: the age filter time. Here are the same commands above with the age filter time (60 seconds) being specified:
The purpose of adding an aged filter time to these payload inspection commands is to get an aged filter off of the Aged Filter table as soon as possible. This still lets the filter serve its purpse of blocking addtional connection attempts from the same infected Windows IIs web server, since almost all Nimda intrusion attempts from a single IP address occur over about a 10 second period.
By keeping the Aged Filter table lean, it is becomes much more efficient. Our recommendation of a 60 second aged filter time for these specific commands comes from our examination of the detailed web server logs that many of you provided (thank you!).
In addtion to the above new argument to the payload inspection command, we added the following commands which may be needed in very high-speed network environments (e.g. direct T1 - T3, 100 MB/sec NICs).
Aged Filter Save Interval
When a filter is added or removed from the Aged Filter table, a signal is set which tells IPNetSentry that the Aged Filter table has changed, and that this table should be saved to disk. Before, this saving operation occurred at for every change (i.e. event driven). We have now made the saving of the Aged Filter table to be interval driven. You can now set this interval with the following command:
The above command will tell IPNetSentry to save the Aged Filter file on a 60 second interval, and only if the Aged Filter table has changed. While this can result in better performance, it will also mean that the IPNetSentry Companion application may not always display the latest state of the Aged Filter table since it reads this file from disk. We will attempt to work to fix this in a later version.
IF you set the value to -1, saving of the Aged Filter table is completely disabled. This may be desired for use of IPNetSentry in extremely high-speed network environments.
IF, you do not specify this command in the IPNetSentry Config file, then the default value of 0 is used, essentially making this saving operation event driven.
Log Save Interval
Similar to controlling the Aged Filter interval, we had also planned a way to save the log at preset intervals. It is not yet clear, however, how much benefit this might be. It will also entail a bit more recoding of our logging mechanism.
At this time the only value which impacts the Log Save Interval is -1. This essentially turns OFF all logging (none saved to disk, none written to the Companion application). This is simply a way for us to test IPNetSentry in extremely high-speed network environments where any disk activity could impede performance.
Set Maximum Aged Filter Table Size
Many users have requested that we expand the Aged Filter table. We have had some reservations due to performance reasons. As the filter table fills, each new incoming datagrams must be matched against an entry in the filter table. At some point, searching the filter table will become as processing intensive as actually moving the data. At this point a user will experience significant performance degradation.
Previously , the filter table was limited to 250 entries. IPNetSentry kept this table even smaller so that it would not "bump" out filters installed by other applications, such as IPNetRouter.
With this candidate, we have increased the POSSIBLE table size to 2000 entries, 1900 of which are available to be used by IPNetSentry. This not only involved a change in the IPNetSentry.PPC FBA extension, but also in the OTModl$Proxy module. This is why you MUST restart your system after installing this candidate version of IPNetSentry.
Even though IPNetSentry now has the capacity to hold up to 1900 Aged Filter entries, we offer you the flexibility of specifying how large this table can really get. This is done with the following command:
The above command would set the maximum number of aged filters to 200 (actually 199). When the 200th aged filter is put on the table, the first entry of the table is rolled off, and the table completely shifted.
If this command is not used in your IPNetSentry Config file, then the value of 150 entries is used.
WE NEED YOUR INPUT and EXPERIENCES!
Please forward any experiences and/or
suggestions directly to me at "">
".
Manualy Editing the IPNetSentry Config file
The IPNetSentry Config file is just a regular text file which resides in your Preferences folder:
If you wish to make any changes to this file you can simply edit this file with any text editor (such as SimpleText). Please see our IPNetSentry Command Syntax document for further details on editing this file.
After making any changes to the IPNetSentry Config document you will need to first turn off IPNetSentry then turn it back on in order to invoke the new configuration.
Copyright 2001 by
Sustainable Softworks.