It is absolutely necessary to secure resources in the cloud. Moving your resources to the cloud does not make your data 100% secure. You are actually moving to a shared security responsibility model in which you share responsibilities with the service provider, such as Amazon, and not abandoning your cares. This model reduces the operational burden for securing the infrastructure that supports the cloud, but we are still responsible for securing whatever we put in the cloud.
Moving applications to the cloud changes the attack surface, but the vulnerabilities at application, database, and network level still persist. To address these issues, setting up the perimeter is critical. You might have plenty of experience with on-premises data centers but the cloud is different. Let’s dive deeper into securing your cloud with an instance of Amazon’s Elastic Compute Cloud (EC2):
Reduce the attack surface
The basic principles don’t change. Run a port scan using a tool such as Nmap specific to an instance IP and lock down all the unnecessary open ports. This is the first step in the defense-in-depth approach. For example, to scan all the TCP ports open on a host:
nmap -p 1-65535 –t4 –A –v 54.187.225.8
All the traffic to an instance can be controlled by a security group, a virtual firewall that controls the inbound and outbound traffic. It can be configured from an EC2 dashboard. By default, the security group attached has limited protocols/ports open to allow traffic from the Internet. However, these can be modified depending on user requirements that could make them vulnerable. To edit a security group, follow these steps:
Running instances -> select any instance -> security groups from description
Private subnet instances are accessible only internally. So creating security group rules that allow inbound connections publicly (0.0.0.0/0) doesn’t make sense. Identify those settings and get rid of those rules.
Remove password-based authentication
To secure the authentication mechanism, disable password-based authentication. Amazon disabled this option by default for Ubuntu/Linux instances. We recommend leaving those default settings for added security. Public/private key–based authentication should be used to log into an application via SSH. Amazon provides a good reference on how to create key pairs. If you are using customized Amazon Machine Images (AMIs), make sure to disable the password-based authentication from the SSH daemon configuration file. For critical systems, allowing SSH ports to the entire Internet is not a good practice; restrict them to specific IPs through whitelisting.
Meta and user data: lock it down
Instance metadata is information about your EC2 instance that can be used to configure or manage a running instance. You can attach scripts to configure AMIs during launch to make more generic instances. This instance metadata can be available from your running instance in multiple ways. To view all categories of instance metadata from a running instance, use the following URI:
http://169.254.169.254/latest/meta-data/
Amazon Web Services (AWS) attaches a metadata server to each running instance and the preceding server IP address is common for any instance. This advice just touches the surface; there are many resources available online on how to add and retrieve metadata. You can use a tool such as cURL to retrieve the metadata of an instance:
curl http://169.254.169.254/latest/meta-data/
The metadata contains sensitive information such as private IPs, instance IDs, host names, etc. Similarly, user data can be accessed from a running instance. That data can be exploited if an application sitting on EC2 is vulnerable to HTTP request proxying. (A paper from Andres Riancho explains this attack surface in great detail.) Because data theft can cause a severe impact, let’s look at securing meta and user data.
Tighten the security to access the metadata/userdata folder to only root-owned processes with permissions set to 400 upon launching an instance. The routing service can be turned off once data has been collected, with the following command:
route add –host 169.254.169.254 reject
This step will prevent nonroot users from accessing the data. To access the data, the root account would have to be compromised and the preceding configured route settings deleted.
Alternatively, configure the iptables that predefine the firewall rules to allow connections only to root.
iptables –A OUTPUT –m owner ! –uid-owner root –d 169.254.169.254 –j DROP
Conclusion
The default setup of EC2 is always insecure. Configure AWS settings to industry standards to better secure your instance. At any cost you should protect user data. The security of an API is such that it checks only the origin of calls. If somehow, an attacker gets control over that data or your application allows code execution on your instance, you need to be prepared to block that access.
The post Secure Your Instance of Amazon’s Elastic Compute Cloud appeared first on McAfee.