Secure an AWS EC2 instance with BlastShield™ in 6 steps.
Time to read: 8 minutes.
Time to implement: 5 minutes.
This is the first in a series of Blogs to explain how to use BlastShield for securing and connecting workloads in virtual machines and containers. In this blog I’m going to explain how to secure your AWS EC2 instance, enable secure remote access with end-to-end encryption, and authenticate users with multi-factor authentication using a BlastShield™ Agent. For this example, I’ll be using Ubuntu Linux on my EC2 instance.
Amazon’s Elastic Compute Cloud, also referred to as EC2, provides virtual servers on the Amazon Web Services (AWS) infrastructure. EC2 is sold as a service and comes in different types (CPU, memory, storage, OS) which are suitable for running various types of workloads. An EC2 instance is created from an Amazon Machine Image (AMI) which is a template for the instance’s root volume and includes the OS and applications, permissions, and storage.
Amazon gives you various ways to remotely connect to an EC2 instance, including SSH, RDP and via the Systems Management session manager. For EC2 instances running in private subnets, AWS also offers the Instance Connect feature that uses their Identity and Management (IAM) service and one-time SSH keys. This can be complex to configure and can often require writing JSON for the IAM configurations.
However, if you want a solution to protect your EC2 instances which is simple to configure and gives you integrated password-less multi-factor authentication, micro-segmentation, and the ability to securely connect your EC2 instance to other cloud instances using encrypted transport, then read on, as I’m going to show how to protect the remote access from a remote client to an EC2 instance using a BlastShield™ Agent.
BlastShield™ will protect the connections between protected virtual instances and the remote user in an encrypted tunnel. To access the encrypted network, the remote user will authenticate via the BlastShield™ mobile authenticator app which uses multi-factor authentication with no passwords. Encrypted connections between protected instances and users are created on a direct peer-to-peer basis and you can also add virtual instances from AWS, GCP, Azure, VMware and Docker containers to extend the protected network just by adding more Agents. BlastShield™ will manage any NAT traversal required, and no changes to routing or access control are necessary.
Setup with BlastShield is very quick and you should be able to get connectivity working in about 5 minutes. Before you start, your connection to the EC2 instance should look like the figure below. If you want, you could use multiple clients and multiple EC2 instances. I am using one of each for this example.
To create and setup the BlastShield™ Agent, use the following steps:
Step 1: Add a new Agent in the Orchestrator
The BSI file contains a temporary registration token which is used to register the Agent with the Orchestrator.
You can see how to add a new Agent here: https://vimeo.com/658532418
Step 2: Install and register the Agent
Open a terminal session on the Linux server where you are going to install the Agent.
"Installation successful, the agent IP address is <Agent IP address>."
Step 3: View the status of the Agent
Now that the installation and registration processes have completed, your Agent is up and running.
You can verify the status as follows:
sudo systemctl status blastshield
The status of the new Agent on your server should appear as "Online" in the Orchestrator.
Step 4: Configure policy to allow access to the Agent
BlastShield™ is a zero-trust access solution. You must provision a policy to authorize access to the Agent on the EC2 instance. You can do this from the Orchestrator. The process is as follows:
You can see how to do this here: https://vimeo.com/650080278
Step 5: Remove any AWS inbound security group rules for the EC2 instance
Login to your EC2 console and go to the security groups configuration for your instance. Select the security group/Edit Inbound rules and delete the inbound rules so that there are no open ports, so that your inbound rules look like the picture below. Setup of any inbound connections to the protected EC2 instance is managed by BlastShield™.
Step 6: Smile and Enjoy Your Accomplishment
You are now set up to securely login to the protected EC2 instance. You can connect to the protected IP address of the Agent which you configured in Step 1. You may also use the hostname provisioned to the Agent for connection if you prefer; the default DNS suffix is “blastshield.io” although you can change this. The diagram below shows how BlastShield™ makes the secure connection.
It’s also possible to add a service to the access policy to restrict the protocols allowed to connect to the instance. If you wish to read more about connecting to the BlastShield network and using multi-factor authentication, then check out this link on our Knowledge Base.
In future posts I will talk about securely connecting workloads in different cloud providers, connecting with Docker, connecting an IoT device, secure RDP and Kubernetes.