Amazon AWS SysOps – Networking – VPC part 4

9. DNS Resolution Options & Route 53 Private Zones

Let’s quickly talk about DNS resolution. In a VPC there are two very important settings and the exam may ask you about them. The first one is Enable DNS Support and that is a DNS resolution setting and the default is true and it helps decide if the DNS resolution is supported for the Vpc. That means that if it’s true, there is an 80 s DNS server that will be queried automatically as a primary DNS at. There’s a second setting called Enable DNS Hostname which is a DNS hostname setting as we’ll see in the hands on. And by default it’s false when you create a new Vpc like we did, it’s true by default when you create a default Vpc. So when it comes with your accounts or if you use the Vpc wizard and it won’t do anything with setting unless you also have enabled DNS support equals True.

And if it’s true as well, then it will assign public host name to EC two instances if it has a public IP and if you use a custom DNS domain. The trick is if you have a private zone in route 53, then you must set both these attributes to True for your instances to resolve that private zone. So let’s have a look at the setting and their impact right now. So let’s go to our Vpc and we have our demo Vpc right here available. And if you right click and we edit DNS resolution, we can see that this setting is by default enabled. So this will basically resolve the AWS DNS for us. This is great. And if I look at the DNS host name by default it is disabled. So what happens when we enable it? I’ll show you in a second. But first let’s go to EC Two.

And if we look at our public instance that was created in our public subnet, it does have an iPV four public IP, but it does not have a public DNS. So this is what the setting does. If we do change the setting to enable and click on Save, DNS host names have been updated. And now if we go back to our EC Two management console and we wait just a little bit, as you can see now my instance has a public DNS that was assigned to it automatically. And so thanks to these things, now we could go into route 53 and this is where you would be able to create a private hosted zone. So you would go to hosted zones, create zone and then you would make this a private hosted zone so you have a domain of whatever you want. So we’ll just say Fubar internal, it’s just a random domain and I’ll call it internal domain.

And now we’ll say the type is a private hosted zone for Amazon Vpc and it says to use private zones you must set the following Amazon Vpc settings to True enable DNS Hostname and Enable DNS Support. And this is what we just did right here. So if we wanted to go with this, okay, we’ll select the Vpc ID we want to assign this private zone to. We’ll select our demo Vpc and click on Create. And this will cost you $0. 50 if you do create that zone. So just be aware we created that zone. So Foobar internal and now I’m going to create a record set. I’ll just call it demo. Fubar internal. And this is going to be a CNAME that points to say Google. com Www. google. com just for fun, we’re just creating a very simple record. Click on create. And so now let’s see if we can resolve that DNS directly from our EC two instances.

So let’s go to our EC two instance here’s one, and I’ll do a dig and on Fubar internal and here we get the answer section which is Google. com as a CNAME. So this worked. Now basically, thanks to these settings, we can have a private hosted zone in our Vpc, which is really cool because now we can create a bunch of records for domains we don’t necessarily own because this is a private zone and this is accessible within our Vpc. So it is a very common exam question when you do have private roads, 53 zones. And I think no one shows you how to do this. So I wanted to show you how to do this right now. This is how you would create a private zone on route 53 and have it resolved within your Vpc. So that’s it. I will see you in the next lecture.

10. NACL & Security Groups

Okay, in this lecture let’s talk about network Acls and security group. So it is super important for you to understand the distinction because it can come up very often in the exam to understand what’s the difference between the network sels and security group. Now for shortness purposes I will refer network sels and Knuckles sometimes and SEL. Alright? So we have an easy to instance and we know from a long time ago now that we have a security group around it. Now our each C two instance resides within a subnet. So left of the blue vertical bar is my subnet and so outside my subnet there is a network Access control list or knuckle and that’s as a subnet level, okay? So it sits before traffic even gets into our subnet to our EC two instance. So let’s evaluate an incoming request.

Say for example that our EC two is a web server and we expose an Apache application on port 22 and we want to see how the request works. So the incoming request will come from the right hand side and the first thing that will get evaluated is the network ACL inbound rules and we’ll see whether or not the inbound rule works. If the inbound rule passes, then it will get passed on to the security group in band roll because the traffic will go and we’ll pass the subnet edge, we’ll go into the security group firewall and we will evaluate the security group inbound role. If that rule passes, then our EC two instance receives the request on the web server and now he’s going to serve it. So it’s going to say here is my web page and now he has to send back the traffic to the requester.

So the first thing is that the outbound will be allowed no matter what because security groups are stateful. That means that if an inbound request passes then the outbound request will pass as well. Even if there is a rule to deny any traffic out of the EC two instance an inbound rule passes, then the outbound rule passes as well. And then because the outbound rule passed, we go into the network SEL rules and we evaluate the knackle outbound rules and that is stateless. That means that outbound rule will get evaluated. So that’s the structure of an incoming request. The really cool thing to note here is that for our network SCL, this is stateless. So both the inbound rules and the outbound rules will get evaluated, whereas for a security group, if the inbound rule allowed the traffic to go in, then the security group will allow the traffic to go out for that request.

Super important. Let’s do it again, but for an outgoing request. Now with the same, we have our EC two instance with the security group and it’s behind a subnet and we have a knackle at the subnet level and now we’re looking at outgoing request. So this time our EC two instance is making a request, an outgoing one. So we’re going to evaluate the security group outbound rules to make sure that they can leave the EC two instance. Then it’s going to get into the naco outbound rules to make sure it works. So now we’ve requested maybe Google. com to respond to us. Google. com gives us a reply. We receive a request back from Google. So it’s an inbound rule this time that will get evaluated and that is stateless. So it will get evaluated and then it goes back into our city to instance.

But inbound will be allowed no matter what because this is stateful, okay? And we’ve seen that very often. If we query Google. com, the rule comes, the request comes back to us, even though we haven’t opened any ports on our EC Two instance. I guess that makes sense now. So this is really important for you to understand and see because this matters a lot. We’ll see this in the hands on just to test out a few use cases. So what are network sels? Well, they like a firewall that control access from and to a subnet. So it’s at a subnet level and the default knackle allows everything outbound and everything inbound. So it does not restrict anything, which is great when you want to get started and you define one naco per subnet and new subnets will be assigned the default naco by default.

Now, to define naco rules, you basically assign a number between one and 32,766. And basically if the rule has a low number, then they have a higher precedence. That means that as soon as there’s a match, the rule is being evaluated and it’s the highest number that wins. So if you define, for example, 100 allow IP and 200 deny IP, then the IP will be allowed overall because 100 is less than 200. Last rule will be an Asterisk, and that means that all the requests will be denied if there’s no rule match. And you can’t change that. And overall, when you start adding rules, AWS recommends adding rules by increment of 100 just in case you want to add rules later in between. Now, if you create a new neckl, then it will deny everything.

And overall, what’s the use case of knuckle? Well, they’re a great way, for example, of blocking a specific IP at the subnet level. So let’s have a play with those right now to understand exactly how they work. So I’m going to my network sels right here in the bottom left. And as we can see, if I select a VPC to be the demo Vpc, I have one network SEL, and that’s the default knackle. This one that was created by default and it’s associated with four subnets. Okay, excellence. So if you look at inbound rules, we see that all traffic on all ports, all protocols from anywhere is allowed. And that’s rule number 100, whereas all traffic from anywhere else is denied. So that’s the rule in Asterisk. That means that if there is no rule match, then deny it. And for outbound rules again, all outbound traffic is allowed.

And that’s rule number 100. And then if it doesn’t match any rules, then the star will say deny. All right. So now let’s have a play. So what I’m going to do is that I’m going to go on my EC two instance, the public one, and I’m going to run a small Apache server. So I’m going to modify the inbound rules for this one. So I’m going to my launch wizard inbound and I’m going to edit and add an Http rule to allow from anywhere to connect to my EC two instance. So I’ll say, okay, great. Now let’s ssh into this instance. Actually it’s already done. So if I just disconnect from my private instance, here I am, I’m in my public one, but you can just ssh again using your command. So we’re back into my public instance.

Now I’m going to do pseudo sum install Httpd, yes, systemctl. So systemctl enable Httpd, then systemctl start Httpd. And then we’re going to heckle lod into VAR dub HTML index HTML. Okay, so now if we go to our public instance, public IP, so this one and we open a new window, then we get hellod back. Excellent. So this is just the basics. So right now our knackle allows every traffic in and then obviously we get back to this hello page. So now if we edit our inbound rules and we want to add a rule, for example, the rule number is going to be 80 just to have a rule that will have higher precedence. And I will say, okay, inbound rules Http, I’m going to just deny it from anywhere. So here I say denied http traffic on my inbound, as you can see, well, it looks like it’s denied. So if I refresh my page right here, you see it starts to time out there’s like an ever loading thing.

So right now it shows that, yes, I cannot access my instance on port 80, even though my security group has not changed. You see, port 80 is still allowed, but my knuckle is actually stopping my request right now. So if I change this rule and now make this 200 instead of making it 80, because 200 is more than 100, then basically what do you think will happen? Well, because all traffic will be matched first as a rule, then this will never be matched. And so our traffic should be allowed. So if we stop this and refresh this page now, we get the hello world back. Excellent, right. So now to have a look at the state fulness of our EC two instance, for example, right now let’s go to our launch, to our security group. As we can see outbound, it allows all traffic, but I’m just going to remove this.

So now all traffic is denied. So if I go back to my EC two instance, actually it’s blocked because actually all traffic is denied, right? I can’t even touch anything right here. But if we still access the URL, it will work. So even though all outbound traffic is denied, then because we can access it through this inbound rule on port 80, then because the security group it’s is stateful, we also get the response back no matter what. So this works still even though there is no outbound rule right here. So for sake, I’m just going to allow all traffic again from anywhere. So anywhere, here we go, just to put it back as normal. But so this just showed the statefulness of our security group. So here you could play it a little bit and see what happens. Basically if you change the network sels where you deny Http traffic, etc, etca.

But the really cool thing is that now you can start editing your rules and choose whatever you want. So you can block a specific IP. For example, you would say rule number 80 and you will say okay, all traffic, all traffic. And then you would have to put your IP. So you put 1122-3344 or whatever your IP is 32 and deny. And this will effectively block your IP from accessing any of your resources in your network SEL. So this could be quite interesting. What you can do with it, and this would be the primary usage of a network SEL is to basically deny all traffic. Now, outbound rules, you have to be very careful because they also get evaluated. So if I go and edit my outbound rule right now, let’s see, this website works it’s just fine, but if I go back to my network Sdl and remove this outbound rule so for example, I will say deny, deny all traffic from anywhere.

Let’s do this, deny all traffic from anywhere. And if I try to refresh, will my EC two instance get my request? And then it went back through the security group. But then because the network ACL outbound rules denied me from doing this request, then the request is not coming back to me and I get a timeout. So it’s very important for you to see that the network Acls are stateless. That means that both the inbound rules and the outbound rules get evaluated at every request. So click on save and we’re back to normal. So, super important, right? So here is a very handy comparison between network Acls and security group. So, security group is at the instance level, whereas network Sdl is at the subnet level.

Security groups supports allow rules only, whereas this supports allow and explicit deny rules is stateful. So that means that the return traffic is automatically allowed regardless of any rules in which has demonstrated this, whereas network SL is stateless. So the return traffic must be explicitly allowed by the rules. Then for security group, all the rules are evaluated before deciding whether to allow traffic. Whereas for network Acls we look at the rule number, and the one with the lowest number that matches the traffic wins. And then this security group applies to an instance only if someone specifies security group when launching the instance or associate it later on, whereas this one automatically applies to all instances in the subnet associated with.

So we don’t have to rely to users to specify the security group. And that gives you another line of defense. Finally, if you’re wondering what a strict network SEL looks like, have a look at this link. So let’s look at it together. So in this example we have a network SEL and if we scroll down it shows us a default network SEL. This is one we have from before, where everything is allowed and then the rest is denied. And then if we scroll down, we get a custom network Sdl, an example of it. So if you look at it, for example, here inbound allows anything on port 80 for Http, anything on portfolio three for https ssh only from a very small Cider, that is a private home network Cider, and RDP, which is the Ssh for Windows as well on the same Cider.

And then there is a custom TCP inbound for these ports which are very high ports and they’re called Ephemeral ports and they’re basically ports that can be selected and we’ll see what that means. This is basically how the network connections on the internet work when there’s a request and response and then every traffic else is denied. So this is quite a restrictive network SEL. And then on the outbound, let’s have a look. It allows port 80, port four, three, and then it allows all these Ephemeral ports again to be allowed. And we’ll see what Ephemeral ports are in right now. So if we scroll down, you’re finding that Ephemeral ports are defined in this example to be this range.

But basically, let’s look at it why a client that initiates a request chooses the Ephemeral port range which is in this range, and then the responding system gives us back the answer at this port. So we need to open these ports, but basically, if you use Linux kernel, they will be this range. If you lose an elb, it will be a much wider range, so 124 to 65,535. And if you use Windows Server, it will be a smaller range, 125 to 5000, et cetera, et cetera. So based on the operating system that you choose, the Ephemeral port that comes back into your infrastructure may be different. And so in practice it says to cover the different types of content that might initiate traffic to public facing instances in your Vpc, you can open Ephemeral ports 124 to 65,535. So this is very important for you to see.

And then it says you can add rules explicitly to deny traffic on any malicious port within that range. So this is super important for you to understand. Again, not something we have to implement right now, but Ephemeral ports must be opened in a network sels if you have a very strict one. Finally, last thing, promise. If you create a new network SEL so if you create a new network CL for your Vpc, by default everything will be denied. So if we look at this new neckl inbound rules, everything is denied. In outbound rules, everything is denied. So we need to manually add our rules and then we could associate that with different subnets. So that’s it for this lecture. I hope you enjoyed it. I know that was really long, but I hope it makes sense into what network sels are versus security groups. And I will see you in the next lecture.