It looks like our team was able to respond and get that re-enabled.
In case someone comes here for the same reason later, I do want to expand a bit on the potential for resolving these situations faster. I want to make sure that everyone knows what options they have available. For that reason, what I’m about to say is not necessarily to you, but to future readers.
In an event in which your server has been compromised and used to attack others on the internet, our top priority will be disabling that to prevent outages that stretch multiple customers, and to protect the internet as a whole. Reading your response to that situation, and re-enabling network will be secondary priorities. Your fastest and most reliable resolution will be to resolve the issue by creating a new droplet. This is just an example of how your workflow could go:
- Snapshot impacted droplet.
- Create new droplet from snapshot.
- Log in and instantly kill outbound traffic in the droplet’s firewall.
- Investigate the cause of the problem.
- Clean up the server.
- Re-enable your outbound traffic in the droplet’s firewall.
- Change your DNS to the new IP.
- Destroy the droplet, or if locked inform our team that you are ready to destroy the droplet.
While you can wait for us to re-enable networking, we provide a wealth of resources designed to help you get back on your feet without our intervention. Ideally we never enter into this situation anyway, but we understand that you might not be aware of vulnerabilities in the software that your droplet runs. We also understand that new vulnerabilities are discovered in software every day, and that sometimes these situations occur before you can reasonably be aware of it. We mean you no harm, we simply want to protect you and other customers from harm, and so we disable the networking to keep you safe.
After all, the data on that droplet could be of incredible value to you. If your droplet has been compromised, the protection of that data is extremely vital.