Amazon AWS Certified Developer Associate – Virtual Private Cloud (VPC) Part 4

5. Access Control Lists (ACLs)

If you go to the Amazon VPC user guide, literally just type in Amazon VPC user guide into Google and then click on Security in your VPC. You can just have a quick read of this, but scroll down and they compare security groups with Network Access Control Lists.

So the very first point is the security group operates at the instance level first, and they call it the first layer of defense, whereas a network Access control list operates at at the subnet level and they call it a second layer of defense. Now, the great thing about network Access Control lists is they’re very fine grained. You can deny specific IP addresses from accessing specific ports, so it is a much better instrument to add increased security to your VPC.

Our security group supports allow rules only, so basically everything is denied by default and then you open up certain ports. So like port 80 or port four four three for SSL, or even port 22 for SSH or port 3389 for RDP. And with our network ACLs, it actually supports both allow and deny rules. So I can actually deny somebody from a specific IP address from Accessing or trying to SSH into my EC.

Two instance, for example, security groups are stateful, and that just simply means return traffic is allowed automatically. When you open up port 80, you’re opening up both inbound and outbound traffic or ingress and egress traffic. Whereas with network ACLs you have to specifically go in and add those inbound and outbound rules yourself.

So network ACLs are referred to as stateless. And if you’re going for a job interview and anyone is asking you AWS questions, you would be expected to know the difference between security groups and Network Access control is typically the people are always looking for one state for one stateless. And then in terms of the way the Firewall rules work, amazon evaluate the rules before deciding whether to allow traffic.

They evaluate all rules on a security group, whereas with a network ACL the rules are processed in numerical order when deciding to allow traffic. And we’re going to go through that in a practical example in a couple of minutes. And then finally, a security group only applies to an instance if you actually put that instance behind that security group.

So you have to actually put that instance into that security group, whereas with a network ACL it’s automatically applied to all instances in the subnet that it’s associated with. And we’re going to show you how to create custom network ACLs and do subnet associations in a couple of minutes as well. So here’s a VPC diagram of what our custom VPC currently looks like. I built mine in the European Central Region, and we’ve got two different subnets. We’ve got a public subnet and a private subnet. My public subnet is a 24 and it’s on 100 10 and my private subnet is on 100 20.

So in this lab, we’re actually just going to be playing around with the public subnets. And currently we have one network ACL. And when we create our VPC, if you remember, a network ACL was created by default. Now what’s cool about the default network ACL when you create it is that all inbound and outbound traffic is allowed automatically. So when you create your default network ACL, all inbound and outbound traffic is allowed automatically. However, when you create a custom network ACL, automatically, all inbound and outbound traffic is denied. And again, that’s a very good security concern. You don’t want to allow all inbound and outbound traffic automatically for custom network ACLs.

The reason they do it on the standard one is obviously just to stop people from getting confused and having to go in and do that extra step. So what we’re going to do now in this lab is we’re going to go and basically create a custom network ACL, and we’re going to leave our default network ACL associated with our private subnet, and then our custom network ACL we’re going to associate with our public subnet. And then we’re going to go ahead and do some funky things. Now obviously, Network ACLs and security groups can span Subnets and Availability Zones, but one thing you have to remember, again, going into any of the exams is that one subnet can only be associated with one network ACL. So you can’t have a subnet associated with two or three or four network ACLs. It just does not work. So one subnet always equals one Availability Zone and it will always be only associated with one network ACL. Okay, so let’s go into the AWS console.

Okay, so here I am in the AWS console and I want to go into my VPC. So go down to Networking and click on VPC and you can see our VPC wizards are here. And basically I want to go over to security and go to Network Access Control list. So now you can see automatically with my VPC we have our Network Access Control List. It’s associated with our two Subnets. And if we go to our Inbound rules, you can see rule number 100 automatically allows all traffic. So all traffic, all protocols, all ports and any source is allowed. And the same with our outbound rules. Again, it’s rule 100. All traffic, all protocols, all ports, and any destination is allowed. Now Amazon always recommend that you do your rule numbers in increments of 100. That way you can go in and change your rule numbers later. And rules are basically evaluated sequentially. So we’ll test that out as we go throughout this lab. So let’s go and create a new network access control list. I’m going to call it my Web Network ACL, and then I’m going to put it into my custom VPC. Go ahead and hit create.

And you’ll see once this has been created that by default. Here we go. All traffic is denied, both inbound and outbound. So right now we’ve created this new ACL. It’s not associated with any subnets at all, so it’s not currently taking effect. So what I’m going to do right now is do a demo for you. So if we go up here and go over to my tabs here’s, my little web page says Hello Cloud Gurus. I can go in and I can refresh it. I’ve got no problems refreshing the page, it’s still there.

If we go back over to my VPC management console, I’m now going to associate the subnet that my web server is in to this new network ACL. So we go ahead and go Subnet association, go edit and then it’s this one. This is my publicly available subnet, go ahead and hit save. And of course what’s going to happen if you look up here, we’ve got two subnets and zero subnets that should change to one and one. And the reason for that is you can only associate one subnet with one network ACL. If you then move a subnet over to a new network ACL, it will automatically be associated with the default network ACL. So I’ve done that. If I go back over here and I run a refresh, it’s just going to if you look down here it says connecting and it’s basically just going to sit here and time out and say it’s unavailable. And the reason for that obviously is because currently our inbound and outbound rules are denying everything. So why don’t we go ahead and fix that? What I’m going to do now is I’m going to set up some inbound and outbound rules for web. So for Http for SSL, I’m going to do it for SSH and I’m going to do it for RDP. So it’s going to be a fairly standard internet facing network ACL. So go over here and go edit and we’re going to go in and add another rule. So we always start, we do it in increments of 100 as best practice. So my type is going to be Http.

My protocol is going to stay the same. My source is just going to be all sources and I’m just going to go ahead and hit save. So that has now allowed all inbound traffic over port 80 through my network ACL. Now if I click on outbound rules, you can see it hasn’t created automatically an outbound rule when I created an inbound rule and that’s because again, it is stateless. So you have to go through and create all your inbound rules as well as your outbound rules. So what I’m going to do now is I’m just going to pause the video and I’m going to create my inbound and outbound rules for http https for SSH and for RDP. So it would be a pretty standard network ACL for a publicly accessible subnet. And then once I’m done, I’m going to show you one little other step that we have to do before this will all start to work. Okay, so I’ve added in all my rules so they’re in increments of 100.

As is best practice, I’ve got Http, https, SSH, and RDP, allowing the source from anywhere, and it is being allowed. And my Inbound rules and my outbound rules are exactly the same. But if I’m actually going to go over here and run a refresh on this, you’ll see it still says connecting and it’s just not going to connect to my web server. And the reason for that is a thing called Ephemeral ports. So if you go over to the Amazon VPC User Guide and you click on Security in your VPC, you can actually click on Network Access Control List and then you’ll see a thing here called Ephemeral ports. They go into it in a little bit of detail. Not a lot of detail, but basically in practice, if you’re going to have clients that are initiating traffic to a public facing instance in your VPC, you should probably open Ephemeral ports one, two, four to 65535. So I’m just going to copy that port range in there, go back to my management console, go ahead and hit Edit. We’re going to add that as our fifth rule and a split beyond the scope of the three Associate certifications to really understand Ephemeral ports inside out.

But all you need to remember basically is you go in here and then just do a custom TCP rule and then you put your port range in. So we’re going to have 124 to 65535. And then we’re going to use the destination of O and we’re going to allow it. And we’re doing this on our outbound rules. I’m also going to do this on my Inbound rules. Sorry if I got that round in the wrong order. It doesn’t matter though. Go ahead and hit 500 custom TCP rule, put my port range in here and I’m going to, again, just paste sorry, put in O and go ahead and save. Now as soon as I do that, I should just be able to go over here and refresh the page and we should see there we go, there’s our web server. So it is all live. We can now access over Http and we’re able to traverse our network, our custom network ACL with no problems whatsoever.

Now, for a bit of fun, what you might want to do is try and block your own IP address. I like to do that. So what I’d do is just go over into Google and type in what’s my IP? So I’m over in Google in here. I’m just going to type what’s my IP? And then we click in here, or it’s just giving me my public IP address anyway. So it’s 31, 51, nine, six. So I’m going to go back over into my VPC management console. Now, if you remember from earlier on, the rules are evaluated in numerical order. So if I want to block Http traffic to my specific IP address. Do you think I should use rule 101 or should I use rule 99? Should I do it above or below or why don’t we just start with rule 101? So we’re going to add in another rule. Just test this out 101. I want Http just here and I want to block the source and I’m going to do it to my absolute IP address. And instead of saying allow, I’m going to hit deny.

So I’m going to go ahead and hit save and you’ll see here. So we’re going to allow Http access to everyone, but then we’re also going to deny it to my specific IP address. If I go back over here and hit refresh, absolutely nothing happens. And that’s because this rule is basically being ignored because there was a rule above it that says I’m going to allow Http traffic in to all sources. So what I want to do is just go in and edit and I want to go ahead and just change this. So now I’m going to say specifically I want to block it to my IP address, but allow it to all other sources. If I go back over here and do a refresh, you’ll see down here, it says connecting. It’s going to start timing out. And again, you can test this by using a VPN server or using a VPN connection to try and traverse it.

So when I log into my VPN access, effectively what’s going to happen is my IP address changes and now I can access the page. So I was able to get around the network ACL that way. So you can see, you can add very granular rules to your network access control list. A couple of key points to remember is that obviously a network access control list can only be rather a subnet can only be associated to one network access control list at a time.

And also that rules are evaluated in order. So if you’ve got a lower down rule and then you’ve got a rule that’s higher up and they conflict, the lower down rule will always take effect. So that’s the best way to remember it. Also another thing to remember, if we just go over to security groups and we try and block an IP address at the security group layer, obviously you can’t, all you can do is allow ports, everything’s denied by a default and all you can do is open up ports. You don’t have any way of blocking a port to a specific IP address, so network ACLs give you a much more granular level of control over your VPC and that’s why they used other.

• Category: Uncategorized