MikeDVB

Hello!
 
We're seeing a couple of very large attacks that are targeting a couple of our servers - S0 and S1.  While all client sites are online and operational the IPs used for cPanel, Webmail, and most email access are currently un-routed.  Due to a misconfiguration in our Anti-DDoS protection that we're working to fix we're not presently able to route those IPs through our Anti-DDoS services.  We expect this to be corrected within a couple of hours.
 
In the meantime you can make the following changes to access cPanel and Webmail.
 
To access cPanel you would want to access the "cpanel" subdomain on your primary domain. So if, for example, your cPanel's primary domain is "test.com" you would go to "cpanel.test.com" in your browser. You may get an SSL warning but you can safely accept it/pass it.

To access webmail would be similar to cPanel in that you would connect to the "webmail" subdomain of your primary domain. For example if your cPanel's primary domain is "test.com" you would go to "webmail.test.com" in your browser. You may get an SSL warning but you can safely accept it/pass it.

Email Clients [Mac Mail, Outlook, Thunderbird, etc] - if you have them configured to connect to "s0.supportedns.com" or "s1.supportedns.com" you can change this to point to the mail subdomain of your cPanel's primary domain. If, for example, your primary cPanel domain is "test.com" you would connect your mail client to "mail.test.com". You may get an SSL warning from your mail client which you can permanently accept.

FTP - in most cases you can simply connect to your domain name.  There are some situations where this wouldn't work such as if you're using CloudFlare or Sucuri CloudProxy in which case you can connect directly to your account IP address.  You can find the IP address in your cPanel under 'Server Information' or at CloudFlare or Sucuri.

We do expect this to be resolved within an hour or two so if you just want to wait it out you can.  If you do make any changes to your mail or FTP clients - you do not have to revert them.

Drupal announced an update to Drupal core today to address two critical vulnerabilities. Drupal recommends users update their core:

If you are using Drupal 8.6.x, upgrade to Drupal 8.6.6.
If you are using Drupal 8.5.x or earlier, upgrade to Drupal 8.5.9.
If you are using Drupal 7.x, upgrade to Drupal 7.62.
 
Note: Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage. Sites on 8.5.x will receive security coverage until May 2019.
 
The vulnerabilities are announced as
Drupal Core - Third-party libraries - SA-CORE-2019-001

Drupal Core - Remote code execution - SA-CORE-2019-002

We're going to be rebooting all servers to apply a security patch.  The reboot will take 2 minutes or less per server.

Hello!

It's been a while since we've seen a decent DDoS attack - something large enough that our facility would take any sort of proactive action against it.

A decently sized DDoS attack started hitting our network this morning on the order of 8 or 9 GBPS.  Our facility saw this traffic and began to proactively put blocks in place resulting in some IP addresses showing offline.  Only a few were affected by this due to the very targeted nature of this attack.

Our network is capable of absorbing attacks of this size so for now we've asked the facility to rescind the blocks so that we can just absorb this attack.  All services are online and operational at this time.

If there are any major changes we'll update this thread.

As many of you already know we experienced a major disaster at the end of September where we were forced to restore data from a backup server due to a misconfiguration of snapshots on our storage platform.  Since this disaster we resolved the snapshot issue and today we were able to use the snapshots to help a client and we couldn't be happier with the experience.

We had a client today that had an employee submit a cancellation for services that shouldn't have been canceled.  The result was 43 accounts terminated that shouldn't have been.

In the past normally what we'd have done is turned to our backup server, which takes backups once per day, and restored the latest point we could.  This could have been as far as 24 hours prior to the termination of services.

What we did as it would give more recent data to the client as well as give us a good test of working with snapshots - was to mount a snapshot of the server just prior to the termination of the services.  We booted the server up, generated backups for the accounts which was exceptionally fast due to the SSD storage, and then restored those backups to the live server.

In the event of an actual disaster we'd simply mount the snapshots and boot them up without doing any backups or restorations and services would immediately come back online as they were when the snapshot was taken.

All in all we're very happy with this as we were able to provide more recent data to the client than otherwise would have been possible much faster than normally would have been possible.

The process was extremely simple and straightforward.  While we don't ever plan on needing snapshots for disaster recovery it is good to know that if we did - they are available and work very well for that purpose.