[Completion] All but one of the dedicated clusters are upgraded, all 2016+ non-HV servers are upgraded, and the upgrade process can be left unattended at this point.  

If you have your own fully managed hypervisors, or a fully managed server on its own domain, and would like us to manage your updates, please contact us for update scheduling as soon as is feasible, to ensure these vulnerabilities are patched.


[Update 3, Tue Aug 20 20:12:10 MDT 2019] As announced yesterday, Fully managed windows server patching and automatic reboots for certain servers on our domain will resume for 2016 build 1703 to 2019 servers (and windows 10 hosts on those builds), starting now.

As before, this will exclude managed clients' standalone hypervisors.  Hypervisors in failover clusters will have rolling updates applied manually where not already done, tonight.

Fully managed windows servers not joined to any domain (including ours) will be updated (and manually configured to use our WSUS) on a case-by-case basis.


[Update 2, Tue Aug 20 00:46:33 MDT 2019] All pending updates have been confirmed to have been applied or initiated for fully managed windows servers on our domain, with OS levels of baseline 2016 and below.

As covered in the previous update, newer servers will have these updates applied tomorrow night, once all pending updates have downloaded to the WSUS server.

[Update, Mon Aug 19 22:02:58 MDT 2019] Due to a required option to get WSUS to download the relevant updates for Server 2019 (and some newer builds of Windows 10) not having been set yet, said OS versions will likely not be updated until tomorrow evening.

Normal updates of all Windows versions from 2008 R2 up to 2016 (for non-hypervisors) are occurring now.  Reboots may occur shortly.


Purpose of Work:
Several pre-authentication vulnerabilities targeting Remote Desktop Protocol in servers running Windows Server 2008 R2 or newer have been discovered; all of which allow for Remote Code Execution.

Because the vulnerability requires absolutely no authentication, it could be spread rapidly within a network via use of 'Worm' style malware, at which point the exploiter would effectively have full control of all infected hosts.


Due to the ease of exploitation, and the impact of exploitation, we will be patching and rebooting all affected, fully-managed hosts overnight. 

Hypervisors would be a general exception to this, and customer-owned Windows HVs that host unmanaged VMs should have their maintenance scheduled with us, separately.


You can read more about the exploit (and patches mitigating it), here: https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/

The following patches are among those that will be applied:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1226
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1222
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1182
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1181

We will update you as maintenance begins.

Impact of Work:
All affected hosts will be rebooted automatically / ASAP to propagate fixes, starting at 8PM MDT on Monday the 19th.  

Internal systems (such as the management portal) may be temporarily impacted in the time it takes to reboot them.

Hypervisors will be done last.  Hypervisors in a failover cluster will have rolling reboots done, in order to eliminate VPS downtime on said clusters.

Any hosts not on our fully-managed domain (usually because they have their own domain) will not be impacted; the controlling organizations will be notified separately.


Please contact us with any questions / comments / concerns.

1. Restore redundancy to our dist3.denver2 switch stack.
   
   
2. Upgrade JunOS on our dist3.denver2 switch stack to the latest JTAC recommended JunOS.  

1. If you are hosted on a virtualized environment on the WEHOSTVPS2 Hyper-V cluster, we will be shutting down all virtual machines within this environment at the start of the network maintenance.  This cluster is most dramatically impacted by minimal network disruptions, and when things go sideways, they require hours of manual intervention to bring hundreds of VMs online, which are generally in an unclean state, require chkdsk/fsck, or have severe file system corruption.
   
   
2. If you are a private cloud, colocation, or dedicated server customer, you will experience network disruptions up to 15 minutes in duration during this maintenance window. Theoretically, it should be possible to do the work we need to do with very little network impact, but after the events which transpired on Monday, it's hard to say that with any level of confidence.

Update 1:10 AM MT, August 13, 2019

Revised Timeline

• At 10:42 am, a customer reported to us that this virtual machine was not responsive. Our technical team investigated the issue and determined the virtual machine required a reboot.
  
  
• At 10:44 am, a virtual machine on the “WEHOST2-VPS” Hyper-V cluster is rebooted because it is non-responsive. Upon reboot, it begins sending anomalous network traffic, which has a cascading impact.
  
  
• At 10:47:43 am, the hypervisor hosting this virtual machine begins throwing memory allocation errors, related to vRss network queues. By 10:55:56 am, the hypervisor has over 53GB of memory allocated.
  
  
• At 10:51:30 am, the hypervisor that was providing service to the virtual machine crashed.
  
  
• At 10:55 am, the hypervisor recovers, and continues to fill up vRss network queues.
  
  
• At 10:56:56 am, fpc1 on dist3.denver2 indicates it is in alarm for DDOS protocol violations. (Note: dist3.denver2 is a Juniper QFX 5100 virtual chassis, which should N+1 redundancy and high availability. Each node is referred to as an fpcX.)
  
  
• At 10:57:21 am, our primary switch stack – dist3.denver2 - reports interface states between fpc0 and fpc1 are unstable.
  
  
• At 10:57:33 am, fpc0 goes into DDOS alarm as well.
  
  
• At 10:58:15, fpc1 crashes.
  
  
• At 10:59:15, fpc0 crashes. At this time, both of nodes of our redundant distribution switch cluster are offline and network access is impacted for all clients.
• Within 3-4 minutes, we have senior engineers in front of the switch stack which is crashed, and also remotely connecting to other switches via our OOB network to determine their status.
  
  
• Over the next 30 or so minutes, fpc0 and fpc1 crash repeatedly. fpc0 crashed at 11:02 am, 11:12 am, 11:16 am and fpc1 crashed at 11:06 am, 11:15 am, and 11:30 am. During these periods, there was some intermittent network connectivity for some impacted clients.
  
  
• Our review of the logs from both fpc0 and fpc1 during this time indicates that virtual chassis never fully converged, which resulted in spanning tree loops on our network.
  
  
• At approximately 11:35 am, we powered down both fpc0 and fpc1 and brought them back online. Unfortunately, they did not come up cleanly.
  
  
• At 11:40 am, we began to physically isolate (both power and network) fpc1.
  
  
• At 11:45 am, once fpc1 was isolated, we reboot fpc0.
  
  
• fpc0 came back online at 11:55 am, but was stuck in “linecard” mode, requiring us to manually remove low level config files and restart certain processes.
  
  
• At 12:03 pm we completed this process.
  
  
• At 12:04 pm we see interfaces physically coming back online.
  
  
• At 12:06 pm we begin receiving UP alerts from our monitoring system.

After Action Plan