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 <[email protected]>. > 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]>
############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. 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]>
