In this tip, the fifth in our series of technical tips on cloud security, we focus on how poor credentials, protocol exposures and implementation flaws in remote management solutions can threaten the security of Infrastructure as a Service (IaaS) models.
Now that we've discussed how threats in underlying operating system and services can affect IaaS offerings, we can deal with threats from remote management mechanisms. General remote management options include virtual private networks (VPNs), remote desktop, remote shell and Web console user interfaces (UIs). As a level set, we are discussing IaaS as defined by the National Institute of Standards and Technology:
"The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls)."
IaaS remote management options
By definition, IaaS resources are remote. Thus, you will need some type of remote management mechanism. The most popular mechanisms used for remote functions are:
- VPN: Provides a secure connection (i.e., tunnel) to the IaaS resource. Typically used when the remote management application does not have the ability to secure data in transit. Common solutions are PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol), IPSEC (Internet Protocol Security) or SSL/TLS (Secure Sockets Layer or Transport Layer Security).
- Remote desktop: Provides an interface that supports graphical user interface (GUI)-based tools. Typically used when the system does not lend itself to command-line based administration (i.e., Microsoft Windows). Common solutions are Windows Remote Desktop or Virtual Network Computing (VNC).
- Remote shell: Provides a command-line based interface for system management and is the most efficient in terms of performance. The most common solution is Secure Shell (SSH).
- Web console UI: Provides a custom remote management interface. This is usually a custom interface developed by the provider (i.e., the RightScale interface for managing Amazon services).
One threat to rule them all
Poor credentials are the main threat affecting the remote management solutions mentioned above, and weak authentication, mostly due to poor credentials, is the most common way your information will become exposed on the Internet. We've already talked about issues with weak credentials in our second tech tip, and those issues rear their ugly head again in relation to IaaS. Remote management solutions that use reusable usernames and passwords or long-term shared keys are the main threat that must be mitigated.
The two other major threats
The other main threats that affect remote management solutions are exposures related to protocols and implementations. The vast numbers of those exposures can be attributed to implementation flaws. As far as protocol exposures, these differ for the types of services we are talking about:
- VPNs: At this point in time, protocol exposures are mostly theoretical. This means that although they are often discussed, non-lab environment exploits are very rare. The only mitigation for protocol exposures is to change protocols (i.e., IPSEC over PPTP) or update to the "fixed" version of the protocol (i.e., SSLv3 or TLSv1 vs SSLv2).
- Remote desktop: The two main remote desktop protocols are RDP (remote desktop protocol), used by Microsoft's Remote Desktop, or Terminal Services client and RFB (remote frame buffer), used by VNC. To my knowledge, neither of the protocols' current versions has known security exposures. The best mitigation for future remote desktop protocol exposures is to run them inside a secure channel (i.e., VPN).
- Remote shell: The main remote shell protocols at this time are Secure Shell (SSH) and Telnet. Telnet is insecure and should not be used in the Cloud. As with the remote desktop protocols, the current version of SSH has no security issues I am aware of.
- Web console: Typically Web-based, the protocols are HTTP typically over SSL/TLS, so exposures in HTTP or SSL/TLS apply here.
How to mitigate these threats
Now that you know the problems, here are my recommendations for mitigating them:
- The best mitigation for authentication threats is the use of two-factor authentication, or a shared key process that is dynamic and short-term. You will likely need to coordinate with your provider to get this functioning properly, but it will be worth the effort.
- Do not rely on reusable usernames and passwords only.
- Ensure that security fixes are applied in a timely manner.
- For the following programs:
- SSH: Use RSA keys for authentication.
- Microsoft's Remote Desktop: Use strong encryption and require server authentication.
- VNC: Run it over an SSH or SSL/TLS tunnel.
- Telnet: Do not use it, but if you must, run it over a VPN.
- For any program that does not supply its own ability to secure data in transit, you should use a VPN or secure tunnel (SSL/TLS or SSH). I would recommend IPSEC first, then SSLv3 or TLSv1.
In our next tip
We have now covered IaaS threats related to both operating systems and services and remote management. In our next tip, we'll cover threats related to the domain name server (DNS) and how they affect IaaS services.
ABOUT THE AUTHOR:
Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.
His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).
Phil holds a BS in Computer Science from the College of Charleston