Angular
Securing Amazon EC2 Instances - Controlling External (Application) Access
  •  

Working With Security Groups

PRO
Outline

Creating a new group is easy. You can reach the Security Group dashboard through either the EC2 or VPC pages. Either will work fine. I'll click Create new group and give the group a name. I won't worry about a description right now and, instead, I'll scroll right down and add an Inbound rule for SSH access to the instance. The Type drop down offers a nice list of pre-set profiles. SSH will default to TCP and port 22. I'll restrict access to permit only requests coming from my own IP address. If it makes sense for your organization, I could also enter an IP address block that covers a set of IP addresses used by people working in a single building.

Next I'll create an HTTPS rule that'll default to port 443. Because we're imagining that we're building a web server, this one should be open for everyone on earth. Next, I'll add a custom rule to demonstrate something we discussed earlier. When I click the Source drop-down on this one, I'm given options that include existing security groups in my account. As we mentioned, selecting one of those gives instances using this group access to instances using the other.

That should work. Let me scroll down and create the group. Oh. Well I guess I did have to include a description up above. I'll go back to add something silly...and this time the Create should happen.

Now, to create a new security group, you'll need the ID for your target VPC. This describe-vpcs command would normally output the full profiles of all the VPCs in my account's default region. But because I'm using grep to filter for just lines containing the characters VpcId, we'll only get the IDs themselves. I'll take any one of those - for this simple demo, I don't care which one I use - and include it in the next create command. Just as we did in the GUI, I'll give the group a name, a description, and the VPC ID. That'll create the group and return the new group's ID.

aws ec2 describe-vpcs | grep VpcId
    "VpcId": "vpc-4205b327",

aws ec2 create-security-group \
   --group-name newtest \
   --description "My new test security group" \
   --vpc-id vpc-4205b927

"GroupId": "sg-0a5acd24d254a042a"

This authorize-security-group-ingress command will add a new rule. After using that ID we just got to identify the group I want to edit, I'll specify TCP as the protocol, port 443, and the source CIDR as anything. This will create a rule permitting all inbound traffic looking for encrypted web pages. To confirm it worked, I'll describe my security groups, but filter for just this group. Yup. There's my new rule.

aws ec2 authorize-security-group-ingress \
   --group-id sg-0a5acd24d254a042a \
   --protocol tcp \
   --port 443 \
   --cidr 0.0.0.0/0

aws ec2 describe-security-groups --group-ids sg-0a5acd24d543a042a

Finally, let's add an SSH rule that'll only permit remote sessions from a single IP address. Notice how I use a netmask of 32 rather than zero. That tells us that we want to include only that single IP address, and not a larger block. With that, we should have a security group that's identical to the one we created in the GUI. And admit it, we for sure had much more fun in the process. I've included all these code snippets with the resources included in the lesson. Feel free to cut and paste...but make sure you replace my IDs with the ones that'll work for your environment.

aws ec2 authorize-security-group-ingress \
   --group-id sg-0a5acd24d543a042a \
   --protocol tcp \
   --port 22 \
   --cidr 142.110.98.45/32
 

I finished! On to the next chapter