AWS EC2 is Amazon’s complicated name for their virtual machine service. With EC2, businesses can easily create servers for a variety of use cases. From starting a micro server with a measly 1 GB of RAM to servers that are dedicated and can have 100s of GBs of RAM.
”If you are keen to try out you can start a u-24tb1.metal with 24 Terabytes of RAM!”
Along with the numerous hardware options, you can get licensed operating systems installed servers ready to use.
Like any other physical server that connects to the internet, the AWS EC2 instances/servers need to be kept secure too. And this is a responsibility you share with AWS to keep the servers secure from all kinds of threats.
While there are many weaknesses that arise due to misconfigurations, here are four most common across security gaps when using Amazon EC2 services.
Servers hosted in the cloud need to be managed remotely over the network. One of the most popular and secure ways to do this is to use Secure Shell Access (SSH). While AWS recommends using SSH keys for a password less experience and even defaults to it, there are many who end up creating multiple users and passwords on the servers.
The problem starts when the TCP port 22 which is the default port for OpenSSH server is left open for anyone to connect from the whole wide world. Typically within a few minutes of doing so, this action attracts hundreds of automated attacker programs (known as bots or SSH bots) who try different username-password combinations to login.
The problem is exacerbated when users reuse passwords, even if the passwords are not weak. Attackers combine and collate leaked passwords into lists to use for such attacks. Commonly known as credentials stuffing, it is a remarkably low-tech but effective attack against human fallibility.
The old world traditional defense to stop SSH brute-forcing is to install network monitoring software on the server to block multiple login attempts. That isn’t very practical for cloud based servers that we get with EC2. Golden images may work but they reduce flexibility.
The secure cloud native way to never have this configuration issue is to use AWS Systems Manager service. It lets you tunnel through an internal-facing SSH server without having to expose the SSH port to the world.
Software that powers the modern applications are large complex code bases. As with any complex system they can have bugs and weaknesses. Some of these weaknesses are exploited by attackers.
Attackers are always on the lookout for server softwares running older versions with known vulnerabilities to compromise. Some of these are hacked for stealing AWS IAM keys and some for cryptomining.
Vulnerability and patch management processes have been a pillar of security activities undertaken by operations teams. In the cloud world where a server can be started by a developer using Cloud APIs they may not be particular about patching and keeping up with version updates.
Attackers have realized that during the transition from the old world to the new cloud native world many such practices have been discontinued. Operations teams need to know about internet facing software their servers are running on and their versions. They also need to keep track of vulnerabilities being announced for the software they use
Applications created for and hosted in the cloud use various cloud services. To be able to use other cloud services the applications require IAM access keys and secret keys. Especially when these applications are hosted on EC2 servers, they may be using IAM Instance Roles. The advantage of the IAM Instance Roles is that these can be attached to multiple EC2 servers.
While this gives incredible flexibility for developers to connect to various cloud services, this does mean that if there are any application level security weaknesses around Service Side Request Forgery, they can be exploited by attackers to steal IAM access keys and secret keys.
If care has been taken to provide limited access to the IAM role, the overall compromise can be limited, but many times this isn’t the case.
Security teams should have an updated inventory of all instances in use, not in use and have an idea of which roles are being used for which applications.
EC2 servers are virtual machines but as far as software is concerned they are just like regular servers. They have Random Access Memory, Network Interface, CPU and for persistent storage they have hard disks known as Elastic Block Store (EBS).
Security compliance standards dictate that all EBS disks are fully encrypted for data stored at rest. Since EBS disks can exist outside of the EC2 virtual machines and they can be made public, it is critical that the disks are fully encrypted at all times.
The good news is even if you didn’t start with encrypting the disks, you can always do that later. The way to do that is to create snapshots of EBS disks. Once snapshots are ready, you can encrypt those snapshots. For additional security you can use your own encryption keys (Customer Managed Encryption Keys) if you want.
Misconfigurations can have devastating consequences in AWS cloud. Due to the shared responsibility model followed by AWS and others maintaining EC2 configurations are customers’ responsibilities. According to the Verizon Data Breach Incident Response report from 2021 around 74% of breaches in the cloud were caused due to misconfigurations.
As your cloud usage increases, you need to be vigilant about misconfigurations creeping in your cloud account. Following best practices as described by AWS Security Pillar from their Well Architected Framework will keep your configurations secure and your data and business safe.
