Mechanisms of Authenticating to a Linux VM (EC2 Instance) on AWS
ACM.77 Considerations for how you access virtual machines in a cloud environment and the importance of non-repudiation
Part of my series on Automating Cybersecurity Metrics. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
I wrote about using developer VMs as a kind of bastion host to access AWS services over a private network using AWS VPC Endpoints in the last post.
We want to test using Private Link with CloudFormation in the developer VPC we created earlier, but in order to do that we need to first deploy and log into a VM (EC2 instance) in that network. And of course, we want to deploy our EC2 instance in an automated fashion.
We’re going to use an AWS Linux EC2 instance. There are multiple ways to login to an AWS Linux EC2 instance. We need to think about how we will grant a user access to the EC2 instance we deploy.
In this case, I’m creating an EC2 instance for a specific user who can log into it and deploy CloudFormation scripts.
I explained how individual bastion hosts may be beneficial for your cloud architecture, network design, security, development, and operations in my last post:
These are not exactly like your traditional bastion hosts which has some pros and cons explained in the above post.
Different ways to connect to a Linux EC2 instance
The tried and true way to connect to a Linux instance is using SSH and an SSH key to authenticate to the service. When we use this option we need to give the user an SSH key associated with the EC2 instance that allows them to login.
You could also use AWS SSM Session manager. This option allows you to connect to your instance in the AWS console.
Another option would be EC2 Instance Connect which involves deploying an agent on the host and logging in with AWS IAM credentials.
You can also integrate your systems with your corporate user directory so users can use the same user name and password they use everywhere else on your network to log into EC2 instances.
Pros and Cons to different methods of authentication
SSH
Pros: With SSH you have layers of security because you’re not using the same credentials to log into the host that you use to administer your cloud. You’re not wholly dependent on AWS IAM or Active Directory. If the primary directory has an issue, you can still log into the host.
Cons: You don’t get the instance access logs in CloudTrail the way you would with EC2 Instance Connect. With SSH you manage permissions to access a host through your system configuration. You’ll need to figure out how to rotate the SSH keys, monitor access and terminate them in the case of an incident, the same way you would with user names and passwords. If someone leaves the company you have to remember to terminate their SSH key as well as their credentials in your primary directory.
There’s no MFA by default though you can configure it as follows:
Integration with your corporate directory (often AD join)
Pros: Users use the same user name and password everywhere for ease of use. When a user leaves your organization you can terminate their access in one place. You don’t have to remember to go disable an SSH key.
Cons: Users use the same user name and password everywhere so once it’s stolen attackers can get into everything. MFA will be provided by the corporate directory, not AWS. With certain types of integrations you will not see the user name that took at action in the logs, you will see a generic IAM role used by every user who can use that role. You’ll need to find a way to track those actions back to the user that took them.
Note, if you are using SSH make sure you choose the the ECC algorithm (or whatever algorithm is currently recommended by NIST) as explained here:
SSM Session Manager
Pros: Same credentials you use for AWS so easier for users. Browser based access is easy. AWS provides MFA and logs track users by AWS IAM name.
Cons: Same credentials you use for AWS. If an attacker gets a handle on an active session they can do whatever the user can do in AWS. Access to an EC2 instance has the increased attack surface of a web browser and all the potential vulnerabilities that come with it as compared to a terminal window.
AWS IAM-based credentials
Pros: With the AWS-specific options you will be managing IAM permissions instead of the additional host-based permissions. This may be easier for some people. AWS IAM Provides MFA and users are tracked by AWS IAM username in logs.
Cons: You still will want to understand how to lock down the host to the appropriate user only. More people will be familiar with standard SSH key management so some time will need to be spent on a learning curve and new policies related to this new approach.
We’re going to stick with SSH for now and I’ll show you one way to deal with key management in an automated fashion in some upcoming posts (as it turns out it was more complex than I first imagined).
User name
If you do not add any additional accounts to your instances, the default AWS Linux name will be ec2-user.
This user has sudo access to make changes to the system configuration. If you don’t want that you should set up a separate user with limited permissions.
Many organizations integrate with a corporate directory. That’s a huge topic unto itself. I helped Capital One with AD join back when we they first moved to AWS. Hopefully it is easier now.
Password
Password options:
- Configure a user name and password. That’s not generally recommended.
- Use one of the IAM options above that works with IAM.
- SSH key. An SSH key, like a developer key, is a password. Store it securely and do not share it.
Security best practice: Disable the authentication methods you are not using.
Authorized keys
If you choose to use SSH to provide remote access to a Linux VM, then you’ll want to be aware of the authorized_keys file. A user provides their private SSH key when they want to connect to a host using SSH. The public key is stored on the host in the authorized_keys file on the host to which they are connecting.
AWS handles configuring SSH for you if you create an instance and provide a key at the time of deployment but you can also manually add SSH keys to EC2 instances for users as explained in this post.
Be aware that attackers may try to abuse your system but modifying the authorized keys. Restrict access to edit this file. Also ensure that your deployment process does not allow people to edit this file if you are using SSH.
Man-in-the-middle with SSH
Sometimes attackers will try to trick users into connecting to an intermediary host which then passes their connection on to the valid host. When you log into the attacker host, it breaks your end to end encryption (unbeknownst to you if you’re not paying attention to error messages) and the attacker can read all the data you send back and forth between the intended designation. That is known as a man-in-the-middle attack or sometimes called a monkey-in-the-middle attack.
There are many ways to perform a man-in-the-middle attack. When it occurs with an SSH connection, you may get a warning that the host your are logging into is not one you think you are logging into. Make sure you understand and resolve these error appropriately.
Do not simply turn off the validation of the host as initially explained in the first answer here, subsequently edited to include the security risk associated with this action.
Some of these complications with keys might make you want to lean towards another form of authentication, but always make sure your network traffic between the client and the host is encrypted any time you are sending credentials over a network — even on a private, internal network!
I have worked in organizations which shall remain unnamed that had developers logging into development systems internally on web pages with no TLS (SSL at the time) encryption. In other words, developers were accessing the host via HTTP to login instead of HTTPS. Anyone sniffing traffic on the network or on that host would be able to see any passwords going back and forth to that application. Both RDP and SSH provide encryption in transit and protect your traffic — unless you have been tricked into a man-in-the-middle attack. Web applications should be using valid TLS certificates and algorithms.
Non-repudiation
Non-repudiation means that when you have logs that indicate a user took a certain action, they cannot deny it because they are the only one who has those credentials. If your IAM team has access to the credentials assigned to a user, then that user could say in the even they took a malicious action that the IAM team could have done it since they too had access to the credentials. Your case would not hold up in court.
You can maintain non-repudiation by using automated processes that users cannot alter. The process should ensure that IAM administrators cannot access or login as the user to whom they are granting permissions and providing credentials to access your cloud accounts.
I already showed how you might create credentials for automation in a way that helps with non-repudiation.
In the next few posts we’ll explore creating SSH keys for remote access to AWS Linux hosts on AWS in a similar manner.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2022
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab