AWS NACL and Security Groups | Ephemeral Ports | Visual Explanations

this is the kingdom of a very famous king but the king is worried about the security of the castle he has guards to protect his castle from within but recently there have been problems with some of the people entering the castle when we speak to the guard he tells us that if someone has permissions to enter the castle why should i frisk him or her the way out and the king now wants to have a better solution for security before it reaches the castle itself so let's find the solution [Music] with the growing demand for security the king now appointed a special task force at the entrance of the kingdom so that all the people entering the castle will be allowed or denied access at the entrance itself and that too before it reaches the second stage of security and the best part is that this new guard will check the permission for both in and out before the person enters the kingdom but we are not here to talk about the kings and castles right in aws we have our instances that are being protected by the security groups for that let's talk about knuckles or what we call as network access control lists which is going to be a very special task force and in this session we will be talking about what is nacl or network access control list how can we configure knuckles and what are the differences between nacls and security groups and all the timelines are in the description for your convenience but before moving forward to knuckles or network access control lists let's understand the problem statement i know this cannot be termed as a problem but it's more of an enhanced security measure when it comes to security groups let's check the case one where we have no access restrictions in the security group for the inbound traffic we have port 80 and 22 and it's allowed for all ipv4 addresses and the same goes for outbound traffic where it has all traffic allowed as well so the instances in our subnet with the security group as my security group can be accessed and it's a free flow of request and response now let's take the case 2 for security groups and let us remove the access for all ips from the outgoing traffic and the outbound rules the general logic here dictates that it should prevent the connectivity to the instances with this type of security group configurations but that's not the case isn't it because the security groups are stateful and because of the property of connection tracking if the inbound rule allows all traffic to access the network or the instance by default the outbound rule holds no value and that is the reason why if we block the outbound rules it still works now let's bring in our special task force and let's place it in front of our vpc subnet just like a firewall and configure it to block all traffic from the sider 192.168.0.1.28 and let's see what happens and yes it doesn't even allow the traffic to enter or reach the security group itself even if the inbound and the outbound rules for security groups allow this ip set that is the enhanced level of security we needed isn't it let's suppose we have a target and we want to restrict it from a list of six subnets and that could be more than 25 security groups in that so how will you restrict all that in one shot yes by using a network access control list so let's understand more about that so what is nacl or knuckle or network access control list if i say knuckle or nacl please don't get confused i'll be using these terms as and when it comes to my mouse so please forgive me for that so knuckle or network access control list so it's an optional layer of security for your vpc that acts as a firewall for controlling traffic in and out of one or more subnets so we need to understand clearly that nacl or knuckle is the optional layer which works for controlling the traffic with the subnet and security group works at the instance level and not the subnet level so with this analogy tell me which takes higher precedence yes you're right it's knuckle and there are a few rules and basic concepts that we need to understand before we can use knuckles properly so the first point is the default vpc automatically comes with a modifiable default network acl and by default it allows all inbound and outbound ipv4 traffic and the next point is you can create a custom network acl and associate it with a subnet with the default one that you have if you don't want to use it or if you want to use a specific target measure then you can create your own knuckles as well and attach that to your subnets so that's a very good thing and each subnet in your vpc must be associated with a network acl even if it allows all traffic and yes for the fourth point it's yes that you can associate a network acl with multiple subnets but a subnet can be associated with only one network acl at a time okay so you can associate a network acl with multiple subnets but a subnet can be associated with only one network acl at a time just as security groups have inbound rules and outbound rules and they work on the principle of ciders or ip address and the port we can route here the network acls has its numbered list of rules and these rules are evaluated in order of the number of the rule and the highest number that you can use for a rule is three two seven six six and what aws recommend says like you can create like 100 150 200 250 or you can have it like 100 110 120 130 in that particular order and it's ordered with the lowest number first and network acl has separate inbound and upon rules and each rule can either allow or deny traffic and this is one of the most important differences as well with security groups the network acls has separate inbound and outbound rules and each rule can either allow or deny traffic and network acls are stateless and i know you might want to understand what that means we will understand that don't worry and you might ask me like how many network acrs we can have what is the quota so per vpc you can have up to 200 knuckles and each network acl can have up to a maximum of 20 rules and this quota can be increased up to a maximum of 40 rules and this is the one-way quota for a single network acl now so per vpc you can have a maximum of 200 network acls so a network acl rule contains a pool of resources that we have to add to create a network acl so let's understand that so the first one is rule number as you can see the table here all the terms that we have in the columns will be discussed here so don't worry about that so starting off with the rule number the rule are evaluated starting with the lowest number rule which means if there is a rule let's suppose 150 and it denies 443 but you have a rule with the lesser number for example 100 which allows it then the network acl would allow it considering the lowest number rule allows the request made for the 443 port and the next is type so this is the type of traffic we expect like ssh or https or http or icmp and you can also specify all traffic or a custom range so next is protocol this is quite simple we can specify the protocol type such as tcp and the port range we can specify the listening board or port range like 443 2280 or https ssh and http respectively and source which is for inbound rules only the source of the incoming traffic you can specify the ip or the side of range the same goes for the destination which is for the outbound rules only the destination for the outgoing traffic so that it can be a so that can be aside a block as well and allow and deny if you wish to allow a rule you can specify a law else you can deny that now that we know what are the parts of the rules let's check how does a default rule look like so this is the default network acl that you get when you create a new network acl just like the security groups we have inbound and outbound rules for network acls if we reiterate this once again network acl is like a firewall or security enhancement for your subnets and security groups are meant for your instances so when you create a new network acl the default network acl is configured to allow all traffic to flow in and out of the subnet so now let's understand how we can read the network acl rule set so here for both inbound and outbound check the entries for the type of the request here rule number 100 that you see allows all type of traffic in and out of the subnet for all protocols and port ranges if the source is 0.0.0.0 0 which covers all the ipv4 addresses remember to check both entries of inbound and outbound but this rule allows all the ips but in case you have ip ranges that are specified then there might be a situation that a set of ip may not match any rule set that is defined for the same reason the asterisk or the star that you see here ensures that if a packet does not match any of the ordered numbers or the other numbered rules it actually gets denied and unlike security groups if you have a rule set that allows inbound traffic and denies outbound traffic then it's not going to work because network acls are stateless and that is the most important thing that we wanted to understand isn't it so unlike security groups if you have a rule set that allows inbound traffic and denies the outbound traffic then it is not going to work it should be allowed both the ways in and out then only the network acls work otherwise they don't work so that is why they are termed as stateless and along with the default nacl or network acls you can also customize the main network acl as well or we can create our own network acl for our subnets and we have to understand this point very clearly that the rule numbers in the custom network acls are really important and we have to understand them thoroughly so when you see the custom network acl inbound rule you see the column of rule numbers isn't it where you see a list of numbers like 100 110 120 130 140 the only rule when adding rule numbers is that the highest number that you can use for a rule is 3 32766 and if you start from 100 aws tells that it's advisable to increment it by 10 and add your rules and the rules will be evaluated from the lowest order so what does it mean so we start from the first number then we make our way to the bottom to evaluate if the request is allowed or denied starting from the lowest number so it's a bit tricky isn't it but we have to understand this so let's take an example here so we have a user here that you can see who wants to access our instances over https with 443. so let's see what are the inbound rules and our bond rules for 443 so we have an entry here in the inbound rule for 443 that's on the second row which allows all the ipv4 addresses to enter the subnet with rule number 110 now let's see the outbound rule set we have the rule 110 here which allows outgoing traffic for https o43 from the subnet so now let's see what happens when the request comes from so it tries to match the rule number 100 which is http 80. so we don't have a match here then it moves to the next higher number 110 which has https 443 allow rule set so we have a match now that it has a match it will check for the ephemeral ports and then if it allows the set of fml ip block it will move on to the outbound traffic so the rule number 100 has no match for https in the outbound traffic then it moves to the next one rule number 110 has a match and then it checks for the ephemeral ips for its permission levels and if it is allowed then you have a successful connection but i'm sure that you might be asking a lot of questions to yourself right now and we have learned about the flow of information and the packets but you might be thinking what is a femoral port don't worry i haven't missed that out but before that i want you to carefully look at the rule set and observe that we don't have an allow all traffic for all ipv4 addresses and just for a moment rethink why we have allowed custom tcp for these ephemeral ports that is six 32768 two six five five three five and if i tell you that if i remove the rule number 120 from the outbound traffic your ports 80 and port 443 won't work so if i say this will you agree with me on this one of course you should not isn't it until and unless you watch it from your own eyes so let's understand the importance of ephemeral ports so what are ephemeral ports ephemeral in english means short-lived and here as well an ephemeral port is a short-lived transport protocol port for ip communication it looks very short and simple but it's not that simple and we have to ask that if the definition tells us that it is a short-lived transport protocol port for ip communication why is it short-lived so these ports are short-lived because ephemeral ports are assigned on a temporary basis or making or handling requests by the operating system that is the host for the same reason the client that initiates the request chooses the ephemeral port range and depending on the client's operating system whether it is unix or windows or linux or whatever it is it assigns an ip from its ephemeral ip range so here as it is already mentioned for unix or linux or for that matter amazon linux kernels use ports three two seven six eight two six one triple zero and requests which are originating from the elastic load balancing users ports one zero two four two six five five three five and for the windows operating system through windows server 2003 users one zero two five to five thousand and for windows server 2008 and later versions they use four nine one five two six five five three five and the net gateway uses ports from one zero two four two six five five three five the same way actually lambda functions also use ports from one zero two four two six five five three five so these are their ephemeral port ranges and whenever they initiate a request they will choose one of these ports from the port ranges and they will make the request so based on your operating system there will be an auto assignment of authorial ports and that's the port number that will act as a source port for the packet header yes that's true i know it sounds very strange but let's see this example of what happened when a client sends an https request so when a client makes a request with 443 the destination ip is 421210 and the destination port is 443 remember this very carefully that the destination port is 443 next the source ip is 32.12.22.11 obviously because it has come from the source but the source port is 32770 it's the ephemeral port not 443 remember that and the most important thing that you need to understand is that when you make a 443 request your source port will not be 443 your destination port will be 443 your communication board will be the ephemeral port similarly the way the response header has the source port as 443 because it is the response so the source port will be 443 the source ip will be 42.1.2.10 because it has come from the source now as a part of the response now the destination port will be 32770 that is the ephemeral port and the destination ip is the one that made the request that is 32.12.22.11 that is our client and that's the same reason why if we don't have a rule set in our inbound or outbound rule with all the traffic allow we need to have a rule set for the ephemeral ports i know this might be a bit confusing but don't worry we will get the clarification in the demo but you have to remember that the most important thing that you need to understand is that when you make a 443 request your source port will not be 443 but your destination port will be 443 your communication port will be the ephemeral port so this is our vpc console and as you can see we have the myvpc demo that is our demo vpc that we had created last time and here we have subnets and we have two subnets for our new vpc that is private and public and if you have been following the series then you know that we have a public subnet which is attached to our internet gateway that is why we are able to access the instances and on ec2 i have hosted an instance here on my subnet on my public subnet that i have so this is the public subnet i had and this is a vpc id myvpc demo and that instance can be accessed by me publicly so what i can do i can just copy the public ipv4 address and i can just paste it so this is the output that i am getting right now from the instance i have set up a nginx server i think everyone has already seen the video where i have set up the engineering server if you haven't then please go back in time and check the video out so that we can have instance like this so if you go to the vpc console you can go to either security and go to network acls or you can as well go to your vpcs and click on your vpc and you can just click on this vpc id and you will see the network acl here so this is the one that is attached to your vpc if you click on this you will see the subnet association so this will be both for your private and public subnet that i have created and here you will find the inbound rules so this is the default inbound rule and you have the rule number 100 which allows all type of traffic all protocols all port ranges or any ip that we have and it allows everything and start so other than that other than this rule if anything that comes i know that it won't come then it will deny that and in the outbound rule we have the same like 100 for all traffic that allows it and we have a star that actually denies it so we have a matching inbound and outbound rule that is why it works and if i refresh this i'm able to connect to the instance and if you want to see the security group that i have for this instance i have everything allowed like port 80 and port 22. anyone can access it from any public ip so this should not be a problem for us so there is no restriction from the security group side but we have to restrict some things in our subnet isn't it that is why we are using the network acls so to understand this problem we have to first of all see if suppose i make any changes to the outbound rule the general convention that we have and what we have understood is that it should not work so i'll edit the outbound rule and i'll change it to custom protocol that i have custom tcp and i'll change it to port 80 because that is one that i'm currently using so rule number 100 port 80 and just will allow this so let's save it and let us see if it works so i have allowed only port 80 and i have denied everything on my outbound rule and the inbound rule all of them are allowed so let's see if it works i'll refresh this no it does not no it does not work isn't it even though our inbound traffic allows all the traffic but it does not match the http 80 port isn't it how is it even possible that is what we learned just now isn't it about the ephemeral ports so if i edit this and i add a rule about like 1 1 0 and if i give it a tcp custom tcp rule and if i allow the port number from 3 to 766 to 65400 or any range that i want and i keep it in the allow state and save it will see and refresh the page here see it works because this is one of the port ranges from which our operating system is picking up the ip address and the port number and it is forwarding the request so now it is clear that the one who is sending the request is not using the port 80 he is using a femoral port so now let's delete this i don't think so we need it right now let's suppose i allow this allow all traffic and i just save it right now so now also it should work because we have both the inbound and outbound rules as equal now let's see what happens if i delete all the rules and save it it will not work obviously and let's suppose i just add a rule per 100 and i just add the ephemeral port range 32700 hyphen 655 v5 now can i allow this itself not even port 80 save it will it work yes it will so what about your theory about allowing port 80 then which is basically what the security group is allowing right now isn't it so that is the same reason why we have to understand the importance of the ephemeral port range so even though i haven't allowed any outbound rules and the inbound rule allows all traffic and the outbound rule does not even allow port 80 it still works so what if i edit this inbound rule and i just change it to custom tcp that i have and i mark it as three two seven zero zero four six five five three five will it work let's see no it doesn't you know why what happened here because the incoming traffic has to allow for port 80 because that is the one that we have as the destination port so this is what we saw here the destination ipv was 42.1.2.10 but the destination port had to be allowed because it was 443 that is what we wanted to access which was our destination but having the source port at 32770 that had to be allowed from the outbound because that is a destination port for the server that is going to serve the request so even though we did not have a source vote in the response or the outbound traffic it does not matter but it has to be there in the inbound traffic or the one that has to make the request so here if i'll just go back and edit it to https 80 and i'll just save it it works okay so i hope you got the idea this is very interesting because you can try a whole set of permutations and combination and try yourself on how actually you can trick network acls and play around with it i can have any number of rules that i want but it is maximum of 20 but you can increase it to 40 so it doesn't matter but this is actually how you play with the network acls and this is the main network acl i haven't created a new one as of now i'm using the same the main acl that has come by default with the vpc but if i have to create one then i can just click on create network acl and i can give a name tag to this mine my new nacl and i can just attach it to one of the vpcs so and i can create one so this is the one that i created just now and by default if you see it comes with all deny but the default one actually comes so we'll see the default one default one actually comes with everything one allow and one deny if you create a custom one the first rule that you see here is all denying so now let's check some of the differences between the network acls and the security groups the first and foremost important difference is that security groups actually operate at the instance level and network acls operate at the subnet level so this is quite most important because you have to understand this very carefully that whenever we have a question related to securing our subnets then you have to understand that we have to talk about network acls and if we want to secure the instance at the instance level then we must talk about the security groups there are various other ways but i am talking in perspective of what we are discussing right now and security groups actually support allow rules only because you make a rule that you want to grant access like for ssh or http and there is no option to have deny as a rule in security groups but for network acls actually they support both allow rules and deny rules as we just saw right now and security group it is stateful so the return traffic is automatically allowed regardless of any rules and in network acls it is stateless so for that reason written traffic must be explicitly allowed by the rules as we saw and security groups actually we evaluate all rules before deciding whether to allow traffic or not and in the network acls we process rules in order starting with the lowest number rule when deciding whether to allow traffic because you can have multiple rules with the same set of protocols but with different rule numbers when security groups actually applies to an instance only if someone specifies the security group when launching the instance or associates the security group with the instance later on so you can attach a security group when you're creating it and you can allow one of the rules that you want or you can specify it after you have created also if you already have some security groups you can attach them after you have created the instance as well the network acyl actually automatically applies to all instances in the subnet that it's associated with and therefore it provides an additional layer of defense in the security group rules that are too permissive that are too open in other words so now let's create the replica of the example that we saw at that time so i'll just add some of the inbound rules now so so now i have added the inbound rule and the outbound rules refresh this page it will obviously work because it is connecting so what happens here is it will first check whether the 100 number rule actually matches or not if not then it comes to 1 1 0 and then it comes to 120 then 130 and that actually finds a match for port 80 and here even if i don't give three two four five five it'll work but i have given it so not a problem so when you go back to the outbound rules it will match here for the hundredth rule number it will check there is no match then it will come back to one one zero and it will see that yeah it is a match but that's not the port number that i am trying to access so i'll go ahead and and we'll check the rule number 120 that we have the custom tcp rule then it will check the port range and yes yeah we have this port number that i want to access isn't it so that is the one that will allow it so that is why it works so that is why it is termed as lowest order rule that is why it checks 100 then 110 then 120 then 130 then 140 and just like that it goes to start so that's all for today's session i hope you enjoyed this and make sure you check out all the other parts of vpc if you haven't all the links are in the description below and if you wish to support me then the links to instamojo paypal and patreon are right in the description as well so until next time it's pytholic signing off

Channel: Pythoholic

Views: 4,166

Keywords: RoadToAWS, SAA-C02, Pythoholic, amazon web services, aws nacl, aws nacl vs security group, aws nacl best practices, aws nacl ephemeral ports, aws nacl and security groups, aws nacl configuration, create nacl aws, aws, vpc, nacl, security groups, network access control list, ephemeral port explanation, ephemeral port meaning, what does ephemeral port stand for, ephemeral port, aws nacl vs route table, aws security group vs network acl, aws security group vs nacl

Id: p0XCg5VhKQA

Length: 30min 19sec (1819 seconds)

Published: Thu Oct 29 2020