Azure promises to guard virtual machines against migration dangers

Security on the road

Remember the password

How an attacker gains access to hidden services is where post-mortem happy fun time starts. But it happens.

Password hygiene is thus significantly more important in the cloud than in your on-premises network. Security through obscurity is sneered at, but your on-premises network is one among millions. Azure is a great big fat target, so creating a password policy and enforcing it is critical.

Host-based intrusion detection is an important concept. RDPGuard will detect attempts to brute-force RDP and ban the IPs of the culprits.

Another option is ts_block. The project hasn't received an update in two years, but it was written by Evan Anderson who has a reputation for writing good tools.

QaasWall is a far more active project which addresses more services than just RDP and comes a lot closer to the desired goal of a proper Fail2Ban for Windows.

Syspeace doesn't offer quite the same depth of coverage as QaasWall, but it is better geared towards automation and sharing of blacklists among your virtual machines. IPBan is also worthy of an honourable mention.

Having detected a market opportunity, Cyberarms has jumped into the void and provides a commercial tool openly marketed as Fail2Ban for Windows. I haven't had a chance to really start on it, but initial tests indicate that it does what it says on the tin.

Hide and seek

The traditional concept of security through obscurity is flawed. Take something that is relatively insecure, hide it and hope nobody finds it: that doesn't work so well when the bad guys have millions of robots scouring the internet every second of every day looking for something to exploit.

Still, obscurity is part of proper defence in depth. It is great to have intrusion detection systems, honeypots, tar pits and so forth, but how much better if your defences didn't actually have to be tested at all.

Obscurity is in fact now a default for Microsoft's IaaS virtual machines. Creation of a virtual machine through the portal does not allow you to use common passwords or many common names such as “administrator”.

Additionally, the portal generates a random port for RDP, instead of assigning the default 3389.

Combined with other positive steps such as encrypting the links between its data centres, Microsoft is doing a great deal towards making security the default. But we the customers must still play our part.

Firewalls on each host could be configured to respond only to a specific whitelist of IP addresses that correspond to your corporate network and perhaps designated disaster recovery sites.

You can create a gateway virtual machine that allows you to open a connection to virtual machines secured behind it via VPN, SSH, SSL or what have you. You can then use that virtual machine to proxy your management requests to virtual machines that are exposing only interfaces such as SSH or RDP to the internal private network.

If we want to get more paranoid than this – and oh, we do – we can automate obscurity by changing the ports for services like SSH and RDP on a regular basis. These could either be changed to rotate through a preset pattern at preset times, or set up to change the port to something random and send the information about what the ports were changed to back to your network.

As a backup, I tend to have a script somewhere that will run every 15 minutes or so and poll an XML file that simply contains a 1 or a 0. If the 0 turns into a 1, it means I broke the collection website and all the virtual machines should revert their management interfaces back to a preconfigured obscure port.

The art of self defence

Some of this might seem excessive but starting to think along these lines is just good practice. IPV4's days are numbered, and In an IPV6 world everything has a public IP address.

Defending each and every host has to become second nature, as we can't hide behind non-routable IP addresses forever. Any edge security system could be compromised and turned against the very virtual machines it was created to protect.

To take full advantage of the cloud, you will eventually want to have workloads in different data centres, some perhaps isolated for security reasons or to address privacy concerns.

What's more, in a cloud environment, the defences we mount need to be automated. To be economical, workloads have to be dynamic. That means their configuration, defence and obfuscation must be equally so.

Just as we must readjust our thinking to make dynamic workloads the default if we wish to realise the economies of the cloud, we need to give the same careful consideration to data movement in the hybrid cloud.

What data needs to move between your premises and Azure? What data needs to move between different Azure zones? Do the data connections need to be persistent or can they (like the virtual machines they service) be dynamic, automated and ultimately obfuscated?

Sysadmins the world over cheer IaaS offerings like those Microsoft is offering through Azure because they allow us to be mentally lazy. Assuming we can convince someone to foot the bill, we can carry on doing in the cloud what we are doing in our own data centres and not think too hard about it.

For a while, this is probably true. Microsoft has done a fine job of automating security, setting good defaults and carefully nudging sysadmins towards security best practice. ®