[sniffer] Re: Beta
Hello John, Wednesday, October 17, 2007, 1:41:18 AM, you wrote: Our SYNC server software rejects connections by default. If an SNF node follows the expected connection protocols and authenticates properly and consistently then it will be allowed to communicate with the system. If it fails to do any of these things or looks suspicious in any way then it will be automatically black listed for increasingly extended periods and potentially null routed by our fire-walls. The security mechanisms are fully automatic and constantly monitored. If something goes wrong on my server, either by a mistake I make in a configuration file or a bug or whatever, and my server in connecting to the SYNC server should be rejected and subsequently black listed, is there a notification that takes place that some one will review to see if that sniffer license is otherwise valid and otherwise no known problems are seen so that I will then be notified saying hey there is a problem contact us so that the problem can be resolved? Yes. The system is completely automated and reliable. There is nothing to be concerned about. Quite simply, nothing can go wrong, go wrong, go wrong... go.. Seriously though-- In order to be black-listed by our system you would have to be abusing the SNF software or using some alternative software to attempt to gain access or deny access to the SYNC servers. Otherwise the most you could do would be to loose contact for some time. That said, if any system does something to become black-listed then you can be sure it will have our attention. It is basically impossible for you to cause a properly functioning SNF node to become black-listed by altering the configuration file. It is far more likely that your SNF node would simply fail to connect. Chances are that if you were making an adjustment that could cause this you would also be watching to make sure that things were working correctly when you finished. In case you did cause the system to lose it's connection with us, the system is designed so that SNF nodes will remain reliable and effective for extended periods even if they are unable to contact the SYNC server. It is also designed to recover gracefully when the problem is corrected. The GBUdb system is highly effective even when it does not share it's information with the other SNF nodes. Each GBUdb node learns first about it's local traffic. As long as your SNF rulebase file is up to date - or even close to being up to date, your system is likely to be very effective at filtering spam. If your SNF/GBUdb node becomes detached from the main system for an extended period, it will degrade in it's performance. Once the problem is corrected it should recover in a very short time. In the event we detect any IPs being black listed or acting suspiciously we will be watching closely so that we can analyze any potential threats and take appropriate actions. If we can identify a customer involved in such a case we will contact them to investigate and correct the problem. Locally, your status reports indicate when the last sync event occurred. This is one of the ways you can check the status of your system. Consider this example from recent telemetry: timers run started=20070928174736 elapsed=1620714/ sync latest=20071017115919 elapsed=11/ save latest=20071017111334 elapsed=2756/ condense latest=20071017081746 elapsed=13304/ /timers You can see when the last sync event occurred (about 11 seconds ago in this case): sync latest=20071017115919 elapsed=11/ We plan to encourage the development of third party tools for monitoring and analyzing SNF system data. In addition we plan to build monitoring and analysis services of our own to include features that will notify system administrators when something doesn't look quite right. If you (anyone) develop something nice for displaying and/or monitoring SNF status data then please share it with the SNF community. In the mean time - we have done extensive testing and monitoring throughout the development process. High availability is (has always been) a design requirement and we're confident SNF can deliver that. Hope this helps, _M -- 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]
[sniffer] Re: Beta
Thanks as always Pete for a great explination. John T -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, October 17, 2007 5:35 AM To: Message Sniffer Community Subject: [sniffer] Re: Beta Hello John, Wednesday, October 17, 2007, 1:41:18 AM, you wrote: Our SYNC server software rejects connections by default. If an SNF node follows the expected connection protocols and authenticates properly and consistently then it will be allowed to communicate with the system. If it fails to do any of these things or looks suspicious in any way then it will be automatically black listed for increasingly extended periods and potentially null routed by our fire-walls. The security mechanisms are fully automatic and constantly monitored. If something goes wrong on my server, either by a mistake I make in a configuration file or a bug or whatever, and my server in connecting to the SYNC server should be rejected and subsequently black listed, is there a notification that takes place that some one will review to see if that sniffer license is otherwise valid and otherwise no known problems are seen so that I will then be notified saying hey there is a problem contact us so that the problem can be resolved? Yes. The system is completely automated and reliable. There is nothing to be concerned about. Quite simply, nothing can go wrong, go wrong, go wrong... go.. Seriously though-- In order to be black-listed by our system you would have to be abusing the SNF software or using some alternative software to attempt to gain access or deny access to the SYNC servers. Otherwise the most you could do would be to loose contact for some time. That said, if any system does something to become black-listed then you can be sure it will have our attention. It is basically impossible for you to cause a properly functioning SNF node to become black-listed by altering the configuration file. It is far more likely that your SNF node would simply fail to connect. Chances are that if you were making an adjustment that could cause this you would also be watching to make sure that things were working correctly when you finished. In case you did cause the system to lose it's connection with us, the system is designed so that SNF nodes will remain reliable and effective for extended periods even if they are unable to contact the SYNC server. It is also designed to recover gracefully when the problem is corrected. The GBUdb system is highly effective even when it does not share it's information with the other SNF nodes. Each GBUdb node learns first about it's local traffic. As long as your SNF rulebase file is up to date - or even close to being up to date, your system is likely to be very effective at filtering spam. If your SNF/GBUdb node becomes detached from the main system for an extended period, it will degrade in it's performance. Once the problem is corrected it should recover in a very short time. In the event we detect any IPs being black listed or acting suspiciously we will be watching closely so that we can analyze any potential threats and take appropriate actions. If we can identify a customer involved in such a case we will contact them to investigate and correct the problem. Locally, your status reports indicate when the last sync event occurred. This is one of the ways you can check the status of your system. Consider this example from recent telemetry: timers run started=20070928174736 elapsed=1620714/ sync latest=20071017115919 elapsed=11/ save latest=20071017111334 elapsed=2756/ condense latest=20071017081746 elapsed=13304/ /timers You can see when the last sync event occurred (about 11 seconds ago in this case): sync latest=20071017115919 elapsed=11/ We plan to encourage the development of third party tools for monitoring and analyzing SNF system data. In addition we plan to build monitoring and analysis services of our own to include features that will notify system administrators when something doesn't look quite right. If you (anyone) develop something nice for displaying and/or monitoring SNF status data then please share it with the SNF community. In the mean time - we have done extensive testing and monitoring throughout the development process. High availability is (has always been) a design requirement and we're confident SNF can deliver that. Hope this helps, _M -- 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]
[sniffer] Re: Beta
Pete, one of the questions I had right away when I looked at the documentation accompanying the software package was about the communication channel. The documentation clearly pointed out that ports 25 is the default and that 80 is selectable, but didn't go further. I just answered my own question by sniffing the traffic... The question was: Ok, so I can govern the port, but will my stateful firewall like it? The answer is yes and no; if my firewall is expecting SMTP application layer traffic outbound on port 25/TCP then it won't like Sniffer's GBU/synch traffic. Which means that a firewall: * That does outbound packet filtering will be fine if it lets out 25/TCP. * That does stateful inspection will be fine if it lets out 25/TCP. * That does application layer filtering of SMTP on 25/TCP will not be fine. I suspect that the same would be true of 80/TCP if Sniffer is so configured. I doubt that this is a problem for most environments, but it is an important point for environments that have application layer filtering. These environments would be able to update their Sniffer database, but not participate in GBU, nor would they be able to use the synch system to report their logs or spam samples. Presumably, the affected environment could implement a new rule or override the application inspection and drop down their security to just allowing outbound 25/TCP without applying SMTP application layer inspection. Andrew. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, October 17, 2007 5:35 AM To: Message Sniffer Community Subject: [sniffer] Re: Beta Hello John, Wednesday, October 17, 2007, 1:41:18 AM, you wrote: Our SYNC server software rejects connections by default. If an SNF node follows the expected connection protocols and authenticates properly and consistently then it will be allowed to communicate with the system. If it fails to do any of these things or looks suspicious in any way then it will be automatically black listed for increasingly extended periods and potentially null routed by our fire-walls. The security mechanisms are fully automatic and constantly monitored. If something goes wrong on my server, either by a mistake I make in a configuration file or a bug or whatever, and my server in connecting to the SYNC server should be rejected and subsequently black listed, is there a notification that takes place that some one will review to see if that sniffer license is otherwise valid and otherwise no known problems are seen so that I will then be notified saying hey there is a problem contact us so that the problem can be resolved? Yes. The system is completely automated and reliable. There is nothing to be concerned about. Quite simply, nothing can go wrong, go wrong, go wrong... go.. Seriously though-- In order to be black-listed by our system you would have to be abusing the SNF software or using some alternative software to attempt to gain access or deny access to the SYNC servers. Otherwise the most you could do would be to loose contact for some time. That said, if any system does something to become black-listed then you can be sure it will have our attention. It is basically impossible for you to cause a properly functioning SNF node to become black-listed by altering the configuration file. It is far more likely that your SNF node would simply fail to connect. Chances are that if you were making an adjustment that could cause this you would also be watching to make sure that things were working correctly when you finished. In case you did cause the system to lose it's connection with us, the system is designed so that SNF nodes will remain reliable and effective for extended periods even if they are unable to contact the SYNC server. It is also designed to recover gracefully when the problem is corrected. The GBUdb system is highly effective even when it does not share it's information with the other SNF nodes. Each GBUdb node learns first about it's local traffic. As long as your SNF rulebase file is up to date - or even close to being up to date, your system is likely to be very effective at filtering spam. If your SNF/GBUdb node becomes detached from the main system for an extended period, it will degrade in it's performance. Once the problem is corrected it should recover in a very short time. In the event we detect any IPs being black listed or acting suspiciously we will be watching closely so that we can analyze any potential threats and take appropriate actions. If we can identify a customer involved in such a case we will contact them to investigate and correct the problem. Locally, your status reports indicate when the last sync event occurred. This is one of the ways you can check the status of your system. Consider this example from recent telemetry: timers
[sniffer] Re: SNF V2-9b1.5 Released - Please Upgrade
Pete, So still in Beta right? Not being a beta tester I'll patiently wait till you go Golden Master. Just wanted to make sure this was not the GM version On Oct 17, 2007, at 3:57 PM, Pete McNeil wrote: Hello Sniffer folks, Please find the latest SNF V2-9 distribution files here: http://kb.armresearch.com/index.php? title=Message_Sniffer.GettingStarted.Distributions#NEW_SNF_V2-9_Wide_B eta If you are running a previous version of SNF V2-9, please upgrade as soon as possible. The newest version includes some bug fixes. From the change log: 20071017 - SNF2-9b1.5.exe Added a missing #include directive to the networking.hpp file. The missing #include was not a factor on Linux and Windows systems but caused compiler errors on BSD systems. Corrected a bug in the GBUdb White Range code where any message with a white range source IP was being forced to the white result code. The engine now (correctly) only forces the result and records the event when a black pattern rule was matched and the White Range IP causes that scan result to be overturned. If the scan result was not a black pattern match then the original scan result is allowed to pass through. Corrected a bug in the Header Analysis filter chain module that would cause the first header in the message to be ignored in some cases. Corrected an XML log format problem so that s/ elements are correctly open ended s or closed (empty) s/ according to whether they have subordinate elements. Adjusted the GBUdb header info format. The order of the Confidence figure and Probabilty figure is now the same as in the XML log files (C then P). The confidence and probability figures are now preceeded with c= and p= respectively so that it's easy to tell which is which. Thanks! _M -- 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 sniffer- [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] Regards, Steve Guluk SGDesign (949) 661-9333 ICQ: 7230769
