NinerNet Communications™
System Status

Server and System Status

Virus update 3

12 August 2020 05:41:35 +0000

As we approach a week with this issue, we are forced to make a decision. We continue to evaluate a number of options, and we’ll implement more than one, but the bottom line for us is a usable email system for our clients, or at least the vast majority of you.

In order to allow the vast majority of our clients to carry on business as usual, at 04:15 UTC today, 12 August 2020, we removed the attachment restriction we put in place late last week. According to reports, this will result in difficulty for one, or possibly two clients who have been overwhelmed recently by spam email that contained these attachments. On the other hand, we have heard those clients that have told us that their businesses have been stalled by these restrictions.

However, that isn’t the last or only action we have taken or will take on this matter. These are others:

  • The lack of speed with which our anti-virus vendor (ClamAV) has picked up this virus means we will be looking at options for either internal or external secondary virus scanning of our incoming and outgoing email streams. If this was something we already had in place, this disruption would have been hardly noticed by more than a few clients. This is the priority with which we are currently seized.
  • We continue to look into ways to apply certain restrictions to some domains and not others in a virtual-hosting environment.
  • Virus samples have been submitted to ClamAV and we anticipate that they will add the recently received viruses to their virus-detection database in due course.
  • We will make an offer to the client most affected by this virus outbreak to move their hosting to a virtual private server of their own.
  • We have blocked several thousand IP addresses that have been the sources of the problem attachments over the last week, and we will block more.
  • Server NC036 is approaching its scheduled replacement time frame. Had our plans been further along when this happened we’d have executed them immediately. However, there are always potential issues when implementing half-baked plans too far ahead of schedule, so we didn’t.

There are potential issues that you need to be aware of:

  • Some anti-virus scanners, not the least of which is ClamAV, are not detecting some of the recent viruses we have seen. You must ensure that you have anti-virus software installed on all of your machines and devices, and you must ensure that this software is automatically updated at least daily. Please remember that the responsibility for the safety of your computer(s) and your data is ultimately yours.
  • You and your employees need to be aware of the risks of opening attachments, and need to be aware of how to evaluate that risk. The risks are to both your machines and devices, and to your organisation and employees.

What have we learned from this experience? Other than our surprise at the degree to which some businesses rely significantly on Microsoft Word documents flying around the Internet, we have learned that the anti-virus vendor on which we have relied without issue for about a decade is not, in fact, infallible. We need, and will obtain, redundancy in this area.

Something else we have decided to act on is SPF (Sender Policy Framework) records. All domains we host have SPF records that tell all mail servers on the Internet that they should accept email only from our servers. The records have all ended with “~all”, but this weekend we will update all records to read “-all”. The difference is that the old records with the tilde (~) allowed receiving servers to act with some leeway, a so-called softfail; the hyphen (-) will enforce that all mail received from domains we host must come from our servers, or any others that are designated in the domain’s SPF record. What will this accomplish? One of the things we have seen is the domain of one of our clients being extensively and aggressively “spoofed”. This is when emails are sent purporting to come from a domain other than their real origin. SPF is designed to prevent this, but the directive with the tilde allows leeway that, it seems, can be too easily abused.

If you believe this may be an issue for you, or if you have any questions at all, please contact NinerNet support and we will assist.

Thank-you very much for your patience.

NinerNet home page

Systems at a Glance:


Loc.SystemStatusPing
Server NC023, London, United Kingdom (Relay server), OPERATIONAL.NC023OperationalUp?
Server NC028, Vancouver, Canada (Monitoring server), INTERNAL.NC028InternalUp?
Server NC031, New York, United States of America (Web server), INTERNAL.NC031InternalUp?
Server NC033, Toronto, Canada (Primary nameserver), OPERATIONAL.NC033OperationalUp?
Server NC034, Lusaka, Zambia (Phone server), INTERNAL.NC034InternalUp?
Server NC035, Sydney, Australia (Secondary nameserver), OPERATIONAL.NC035OperationalUp?
Server NC036, Amsterdam, Netherlands (Mail server), OPERATIONAL.NC036OperationalUp?
Server NC040, Toronto, Canada (Web server), INTERNAL.NC040InternalUp?
Server NC041, New York, United States of America (Web server), OPERATIONAL.NC041OperationalUp?
Server NC042, Seattle, United States of America (Status website), OPERATIONAL.NC042OperationalUp?

Subscriptions:

RSS icon. RSS

Twitter icon. Twitter

Search:

 

Recent Posts:

Archives:

Categories:

Links

Tags:

.co.zm domains .com.zm domains .zam.co domains back-up bounce messages browser warnings configuration connection issues control panel database dns dos attack dot-zm domains down time email email delivery error messages ftp hardware imap mail mailing lists mail relay mail server microsoft migration nameservers network networking outlook performance php phplist pop reboot smtp spam spamassassin ssl ssl certificate tls tls certificate viruses webmail web server

Resources:

On NinerNet: