Securing Amazon EC2 Instances - Controlling Internal (Administration) Connectivity

Securing Amazon EC2 Instances

All the tutorials in this course:

• Introduction to EC2 Security
• The Basics
• Controlling External (Application) Access
• Controlling Internal (Administration) Connectivity

In this tutorial, we'll address the problem from three angles:

• the use of SSH for opening remote shell sessions on your instances
• the best - and safest - network carriers for those sessions, and
• some alternative AWS EC2-specific tools for getting your administration tasks done without having to open an actual SSH session.

In many ways, SSH is the accepted standard for secure remote work. After all, the data transferred back and forth during an SSH session is by default encrypted. That is the primary goal for these things. But even within that framework, there's room for some fine-tuning. For instance, password-based logins even through SSH are discouraged. This is mostly because passwords are, in general, a horrible approach to security controls. Making things happen through SSH public and private keys is far preferred. Well, at least until the moment a private key is exposed to an insecure transfer or host system, that is.

Therefore, you should ideally make sure that both the password login and root login settings are disabled on all your instances. As I mentioned in an earlier lesson, those will be the default settings on all mainstream EC2 Linux images.

You can actually configure your instance to permit logins without the need for even SSH keys. For Amazon Linux and Ubuntu instance types, you can use EC2 Instance Connect and IAM policies to connect. In this case, the Instance Connect package obviously came pre-installed. And the ec2-instance-connect.conf file appears to be workable, too. All that's left would be to create the related IAM policy and confirm that your instance security group contains the right rules.

The simplest way to open an SSH connection with your instance is across the open internet. Considering the quality of encryption used by SSH, that's really nothing to be ashamed of. But there can be benefits to using a more direct form of connection, like a VPN. Creating an AWS site-to-site VPN can allow you to directly connect resources running in your Amazon VPC with your local office network. This'll let you establish direct communication without necessarily having to build complex and sometimes expensive infrastructure like bastion instances.

Site-to-site VPNs work by providing AWS with information about your local network routing through a customer gateway and by creating a virtual private gateway to provide connectivity with your VPC. This can be as easy as giving your new gateway a name. Once my private gateway exists, I can choose an existing VPC to connect it to. Next, you would create a VPN connection that brings those elements together. In this example, I can select the simple private gateway I just defined from any that the system is aware of. Similarly, I can either choose an existing customer gateway or define a new one. Since I don't have a suitable local network, I won't bother actually creating anything here. But I will show you how you could define custom CIDR address blocks to ensure there's no overlap between local and VPC subnets.

When all that's done, you'll be given access to a sample configuration file you can download and use to configure your local routing devices. That'll guide you through the process of building a VPN connection.

If you're looking for a VPN-like connection between your office network and your AWS VPC, but you also need blinding speed, then you'll want to look into Direct Connect. Just be prepared for the extra expense. The idea is that you build a physical network connection between your office and a nearby third-party AWS Partner Network participant. APNs have their own fast, heavy bandwidth connections into AWS data centers that can be accessed through your hookup.