Amazon Elastic Compute Cloud (Ohio)

Update 2:08

*************

Starting at 9:57 AM PDT some EC2 instances and EBS volumes experienced a loss of power within a single Availability Zone in the US-EAST-2 Region. Power was restored at 10:19 AM PDT and EC2 instances and EBS volumes began to recover. By 10:23 AM PDT, the vast majority of EC2 instances and EBS volumes has fully recovered and by 11:37 AM PDT, all but a very small number of EC2 instances and EBS volumes had recovered. Elastic Load Balancing shifted traffic away from the affected area.

Update on Outages

We continue to see recovery of EC2 instances that were affected by the loss of power in a single Availability Zone in the US-EAST-2 Region. At this stage, the vast majority of affected EC2 instances and EBS volumes have returned to a healthy state and we continue to work on the remaining EC2 instances and EBS volumes. Elastic Load Balancing has shifted traffic away from the affected Availability Zone. Single-AZ RDS databases were also affected and will recover as the underlying EC2 instance…

US E2 – AZ1 Outages

We continue to see recovery of EC2 instances that were affected by the loss of power in a single Availability Zone in the US-EAST-2 Region. At this stage, the vast majority of affected EC2 instances and EBS volumes have returned to a healthy state and we continue to work on the remaining EC2 instances and EBS volumes. Elastic Load Balancing has shifted traffic away from the affected Availability Zone. Single-AZ RDS databases were also affected and will recover as the underlying EC2 instance…

Amazon Elastic Compute Cloud (Ohio)

Informational message: Instance Impairments
We can confirm that some instances within a single Availability Zone (USE2-AZ1) in the US-EAST-2 Region have experienced a loss of power. The loss of power is affecting part of a single data center within the affected Availability Zone. Power has been restored to the affected facility and at this stage the majority of the affected EC2 instances have recovered. We expect to recover the vast majority of EC2 instances within the next hour.

Communication Migration

If you are having trouble reaching us we are migrating to a new phone system on Tuesday the 10th between 12pm and 2pm PDT. Otherwise you may open a ticket as usual and we will be able to assist you that way. Thanks for your patience!

If you are having issues connecting to your E-mail or VPN, please continue reading.

Due to recent updates across the industry, security has been increased, which is good, but this has affected some of our Shared Hosting and Dedicated Hosting customers’ ability to log in and send/receive emails. Our Plesk Hosting Software and possibly your Windows Operating System have both updated their systems resulting in what you might notice as “Unable to connect” messages or just no mail sending out or being received. The resolution we have found, is to remove and add the mail account in the settings for your email client. This will regenerate the password cache and reissue the signature certificate that gets stored in your system. Please feel free to open a ticket if this does not work for you at https://portal.dynamic.com

For L2TP or IPSEC using the native Windows VPN Connections that have authentication issues, please see this article for an explanation and how to fix it: https://www.windowscentral.com/windows-update-introduces-vpn-issue-forcing-admins-pick-between-security-or-functionality

What you need to know about the new “Log4j” exploit

NOTE: Not everyone is affected, but for those who are we are already in the process of patching individual servers manually and will likely reach out to schedule a reboot of your server if necessary.

If you haven’t been following tech industry news lately then allow us to inform you about this pressing matter affecting millions of servers worldwide. Log4j is a very commonly used logging library in the Java programming language. Programmers use this to help indicate the state of various parts of their program.

Generally speaking, when processing inputs from the user, you always want to treat the input as just normal text, and not code that the program should execute. You do this due to the fact that if an attacker can inject their own code into a program, then the possibilities are endless for hacks/breaches. Now unfortunately if you construct a specific string of text, and are able to get the log4j library to log that string (which is pretty trivial because most programs will log user inputs), you are able to get the log4j library to reach out to other servers and execute any code that is returned.

This allows the attacker to execute code that they wrote on a remote server. This kind of breach is called remote code execution, and can lead to all kinds of issues.

Now that you understand what is at play here please let us know if you have any questions that this hasn’t already answered and be aware that a fix is either already implemented on those machines who are affected, or will be very shortly.

Further information: https://time.com/6128795/log4j-security-flaw/

Sincerely,
Your DCI support team