There are two reasons you might want to configure host-based firewalls. First, a host-based firewall provides an additional layer of defense should there be a configuration error or breach at the perimeter firewall. Second, a host-based firewall can help prevent lateral movement within your environment. A host-based firewall can be configured to prevent a compromised VM from accessing other VMs on the same network segment.
Host-based firewalls configured to limit communication between VMs on the same network segment is a precursor to data center micro-segmentation. I don’t want to digress too far from the current topic, so I’ll save a full discussion of micro-segmentation for another blog post. For now I will just say it is possible to use the virtual firewall that comes standard with iland’s cloud to reduce the effort of configuring host-based firewalls and glean some of the benefits of micro-segmentation today.
Back to Jim; a standard firewall rule he configures limits the source IP addresses which can access the remote desktop or SSH services. By limiting management access to a few trusted IPs, he reduces the risk of a remote attacker accessing his systems’ management interfaces. Mistakes in the host-based firewall configuration or unplanned IP address changes can leave the VM in a state where it is blocking all incoming remote desktop or SSH clients. Although Jim is diligent in making changes to his firewall configurations, mistakes do happen.
Normally, when you accidentally isolate the VM due to a host-based firewall rule misconfiguration you can remote console into that VM, fix the mistake, and move on. But in Azure, you cannot turn to the remote console. There are some tools Azure provides which can potentially correct errors within your VM to restore remote access. If the provided tools and workarounds do not work you are left with two options: Delete the VM and start over; or download the VM, load it up into your Hyper-V environment, fix the error, and upload the VM back into Azure. I am not surprised by the angry comments regarding Azure’s lack of support for remote console access.
What happened to poor Jim? He had to delete his VM and start over. It is good that Jim thoroughly documents his server build process and keeps local copies of all his configuration files just in case. He only lost a few hours rebuilding his VM and putting all the configuration files back in place. It’s also fortunate that this disruption happened before Jim’s servers were in production. If Jim’s servers been in production, then deleting the VM would not have been an option. He would have been left with no solution other than downloading the VM to his local system, installing Hyper-V since his local data center is built upon VMware, fixing the issue, and uploading the fixed VM back to Azure.
At iland, we recognized remote console access as a critical feature for an Enterprise Cloud. Our developers built remote console access for your VMs into the iland Secure Cloud Console℠. Our console does not even require you to install a browser add-on. If you’re using a modern web browser, you’ve got remote console access to your VMs.
If the iland Secure Cloud Console℠ is not enough to get your VM working, the iland Support team is a phone call away to help you with troubleshooting. We also provide daily VM back-ups with 7-day retention at no additional charge. If a VM were in such a state that it was effectively unrecoverable even with the remote console you’d be able to go back to a prior VM state and get your application services restored. Don’t learn your lessons the hard way like Jim had to – remote control access is just one of the features that can mean the difference between a cloud that delivers value and one that causes admin headaches and untold frustrations.