10. [SAA] NACL & Security Groups
Okay, in this lecture let’s talk about network sels 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. All right?
So we have an easy to instance and we know from long time ago 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 Nickel, 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 bandroll 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 in bandroll.
If that rule passes, then our EC Two instance receives the request on the web server and now it’s going to serve it. So it’s going to say, here’s 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 NACO outbound rules and that is stateless.
So 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 ACL, 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 requests. 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 it can leave the EC two instance. Then it’s going to get into the NACO outbound rules to make sure that it works. So now we’ve requested maybe Google. com to respond to us. Google. com gives us the 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 C two 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 request comes back to us even though we haven’t opened any port 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 knuckle per subnet and new subnets will be assigned the default NACO by default. Now, to define knuckle 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 has been 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 knackle, then it will deny everything. And overall, what’s the use case of knuckle? Well, there is 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, excellent. 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 within 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 go hello into VAR 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 statefulness 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 is stateful, we also get the response back no matter what. So this works still even though there is no outbound rules 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, you could play it a little bit and see what happens. Basically if you change the network sels where you deny Http traffic, etc, etc. But the really cool thing is that now you can start editing your rules and choose whatever you want. So you could 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, slash 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 well, my EC two instance got 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 SEL 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 is YL 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 sels 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 associated 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 SDL. 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 ACL as an example of it. So if you look at it, for example, here inbound allows anything on port 84, 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, 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, etc, etc. 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 SEL 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 knuckle 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 selves are versus security groups. And I will see you in the next lecture.
11. [SAA] VPC Peering
Okay, in this lecture let’s talk about network sels 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. All right? So we have an easy to instance and we know from long time ago 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 Nickel, 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 bandroll 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 in bandroll. If that rule passes, then our EC Two instance receives the request on the web server and now it’s going to serve it. So it’s going to say, here’s 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 NACO outbound rules and that is stateless. So 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 ACL, 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 requests. 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 it can leave the EC two instance. Then it’s going to get into the NACO outbound rules to make sure that it works. So now we’ve requested maybe Google. com to respond to us. Google. com gives us the 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 C two 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 request comes back to us even though we haven’t opened any port 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 knuckle per subnet and new subnets will be assigned the default NACO by default. Now, to define knuckle 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 has been 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 knackle, then it will deny everything. And overall, what’s the use case of knuckle? Well, there is 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, excellent. 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 within 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 go hello into VAR 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 statefulness 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 is stateful, we also get the response back no matter what. So this works still even though there is no outbound rules 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, you could play it a little bit and see what happens. Basically if you change the network sels where you deny Http traffic, etc, etc.
But the really cool thing is that now you can start editing your rules and choose whatever you want. So you could 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, slash 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 well, my EC two instance got 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 SEL 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 is YL 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 sels 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 associated 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 SDL.
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 ACL as an example of it. So if you look at it, for example, here inbound allows anything on port 84, 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, 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, etc, etc.
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 SEL 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 knuckle 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 selves are versus security groups. And I will see you in the next lecture.
