11. Network ACL
Hey everyone, and welcome back. In today’s video, we will be discussing the network ACL. So let’s look into some of the important pointers for network ACL. The first one is that network ACLs are stateless in nature. The second is that they operate at the subnet level instead of the instance level like the security group. So this can be understood with the diagram here.
So you have an EC2 instance here, and the security group is basically associated with the network interface card that is attached to the EC2 instance. So the security group operates at the instance level. However, when you talk about network ACL, they do not operate at the instance level; they operate at the subnet level. Now, a specific subnet can contain hundreds of instances, and one rule in network KCL will affect all the hundred instances that are associated with that specific subnet. Now, the third important pointer is that all subnets in a VPC must be associated with the network KCl. So generally, whenever you create a new VPC, Aid this will automatically create a default network ACL for you. And the fourth one is that, by default, the networkable contains full inbound and outbound traffic as allowed. So these are the default network ACLs that will get generated when you create a VPC. So let’s get started on understanding why network ACL is important. So, let’s say that you have a company XYZ, and it is getting a lot of attacks from a random IP address, which is 128, 191, and 232.
Now, the company has more than 500 servers, and the security team has decided to block that specific IP in the firewall for all the servers. Now, how can you go ahead and achieve the goal? So generally, if you talk about the organization and if they have applications that are accessible over the Internet, then typically you’ll have something like four, four, three Allow, or 80 Allah all. Now, in such cases, you cannot block a specific IP; that is something that is not possible in terms of a security group. If you allow all the traffic and then want to block a specific IP, it is not really possible. And even if it were possible, it would have been difficult because, as you see, there are 500 servers, and you don’t want to add this blacklisted IP to all 500 security groups associated with those servers. So the better way would be the network ACL one. So what you do is that if those 500 servers are within the same subnet, you block that IP at the network level, and that’s about it. So let me show you how network KCl looks and how you can configure the rules there quickly. So this is the EC-2 instance, and I have one EC-2 instance.
So we’ll be doing a demo based on this EC2 instance. And if you look into this EC2 instance, it has the public IP before, and within the firewall rule, it has allowed 80 and 22. All right. Now, let’s say that I want to block only one IP from accessing my port 80. On the EC2 instance, it is technically possible with the help of the security group. So we need to take the route of network KCl. So in order to access network KCl, we need to go to the VPC console, and let’s select one VPC. So this is the VPC where our EC2 instance is currently created. Now, within here, if you go a bit down under the security, you have a network ACL, and there is one network ACL that is created, and it has a value of default that is equal to yes, which means this is the default network ACL that is created. And this network ACL is associated with the six subnets that are part of the VPC. So a single network ACL can be associated with the multiple subnets within the VPC. Now, within the network ACL, you have the inbound rules and the outbound rules. So within the inbound rule, you see there are two rules that are present, and within the outbound rule, there are also two rules that are present. Now, there is a rule number that is associated with them.
So the first one has a rule number of 100, and all the traffic has been allowed over here. And the second has the lead, and all traffic is blocked. One thing to keep in mind is that in the ACS network, the lower the number, the higher the priority. So, if traffic matches this specific rule, the network ACL will either allow or deny it, based on the configuration that you set over here. If the traffic matches here, then it will not look into the below rule; it will just follow what is present over here. All right? This is why 100 is slower, and all traffic is therefore permitted. Same with the outbound. You see, 100 is lower here, and this is the reason why all the traffic is allowed. So let’s look into whether the things I am saying are correct or not. So let’s do one thing. I’ll copy the public IP here. So I’m in my CLI, and let’s try to ping this specific EC2 instance. And currently, you see, you are getting the ping reply back. Great. So that means the connectivity is present. So now let’s do one thing. Let’s modify the inbound rule. I’ll add one more rule here. I’ll put the rule number as 99, and I’ll also associate all the traffic here, similar to the first rule. And this time we’ll put it in deny, and I’ll click on save. All right. So now you have two rules that are quite identical. One is denied, and the second is allowed. And the priority rules in terms of numbers are different.
So now, if you try to ping, you will see that the ping has been blocked over here. Now, this has been blocked because there is one rule over here that is denying all the traffic. And the rule has priority 99. So as soon as the network ACL receives the traffic from my network, it evaluates it against the rules that you have set. And since we are here, we have already specified all the traffic. So that means that this rule matches. And since this rule matches over here, the network ACL will block it; it will not look into the next rule altogether. All right. So now let’s do one thing. I’ll change this rule number from 99 to 101, and let’s click on save. So this time the “allow” rule has the higher priority. And here, as you can see, you are able to get the reply back. Great. So I hope you understand at a high level what the network ACL is all about. So one important part to remember is that a single-network ACL can be associated with the multiple subnets, and you can also create rules that are similar to this. Let me do one thing. So currently, this is my IP address. So let’s say, because we were discussing the use case, you have something like this where you are allowing traffic from everyone. And there is this one IP address that is trying to attack you all the time.
So you can create a rule, give it the number 99, specify the source IP, let’s say 32, and set it to deny, and then save. So now, any traffic that originates from this source address and matches rule number 99 will be blocked. Now, any other source other than the specific one that we have specified here does not match over here. So the network ACL will look into the second rule. Now, the second rule states that all traffic is permitted, so the traffic will be permitted. So this is the high-level overview of the ACL network ACL.Do remember that by default, when you create a network ACL, it will say “allow all.” However, when you create a custom network ACL, let me actually show you this. So let’s go ahead and create a network called KCl. I’ll call it “Kplabs hype and custom.” Now you can associate a network ACL with a VPC. Let me create a page here. All right, so this is the custom network ACL, and within the custom network ACL, you see, by default, the rule is denied. same for inbound and outbound. If the network ACL is default, as you have not created it in a custom way, then it will allow all. So that’s the high-level overview of the ACS network. I hope this video has been informative for you, and I look forward to seeing you in the next video.
12. Understanding Stateful vs Stateless Firewalls
Hey everyone, and welcome back. In today’s video, we will be discussing stateful versus stateless firewalls. Now, typically, if you look into the basics of TCPIP communication, let’s assume that you have one server here and that SSH is running on the server on port 22. And along with that, you have the client over here. So the client wants to connect via SSH to this specific server. As a result, he will send a request, and the server IP address is 190 to 168 101.
As a result, he will send the request to 190 to 168-10-1 on port 22. Now, when it sends the request to this server, it will need to have a source port. So this 22 is basically the destination port because the traffic is going towards the destination server. However, along with that, it needs to create a source port. So in this case, we are assuming that the source port is 55607. Now, when the server receives the request and wants to reply back, it will reply back on the source port that the client had opened, which is 55607. So this is how the basic TCP/IP communication works in terms of the source IP and source code. Now, let me quickly show you this in Wireshark so it becomes easier for us to understand. So I’ll quickly launch wireshark in Windows. Great. So this is the Wireshark console. And basically, since I’m connected to WiFi, you can see that there is a lot of traffic that is ongoing. So I’ll be capturing the WiFi interface. I’ll double-click on that, and you’ll see there are a lot of packets that are getting captured over here.
So let me take a random packet over here. So this is one random packet. Now, if you look at the IP protocol, it will basically have the source and the destination IP. So the source is 192, 106, 843135, and the destination is 542-39-3183.So if you just compare it here, So 192.168.0.1 is the source here, and the IP address, which was ranging from 52 to 53, is the destination over here. All right? So this is one part. So when you open up the TCP header, you see the source port and the destination port. So if my computer or if my browser wants to communicate with a website, it needs to have a source port. The destination port in this case is 4, 4, 3, and the source port is 6 3378. All right? And this is something that we were discussing. So, instead of 63378, we have 55607. Now in the second case, we have the firewall, which is involved over here. And this firewall is a stateless one. So now what really happens is that when the client sends the request to the server, the firewall will first check whether the inbound 22 port is allowed or not. So if the inbound 22 port is allowed, then the request from my client will reach the server end. Now the server also needs to respond back, so it tries to respond back to this client’s IP, which is 170 to 1015 seven, and on the client’s port, which is 55607.
However, before the server can send the data back in an outbound fashion, it will also have to verify whether the port is open or not. Because if the fifth is allowed in the outbound, the server will be unable to communicate back even if the inbound request was received. So this is the characteristic of the stateless firewall. Now, there are certain important points that we need to remember here. The first one is that the client typically initiates the request by choosing the FML port range. Now the ports from zero to 100:23 are also called the “well-known” or “reserved” ports. And this FML port range is something that the client decides. Now it depends on which operating system the client is on. So if you talk about the Linux kernel, it will typically choose the FML range from three to seven, six, eight, and 61,000 typically.Now, if the request origin is originating from ELB, it uses 102-426-5535, and Windows XP typically uses 10252 5000.
So the port I’m referring to is the one that the client uses. As a result, this is typically the source port of the client initiating the connection. So now, in terms of a stateless firewall, the problem is that, let’s say that the client has chosen 55607, So within the stateless firewall, we have to ensure that the outbound port 55607 is allowed. If a second client is running Windows XP, it might not use port 55607 at all; instead, it might use port 100:25. So again, in the stateless firewall, you have to make sure that outbound port 25 is allowed. So it really becomes very difficult because the stateless firewall does not really maintain any state. So you have to explicitly allow the ports to go outbound. So when you take the use case of stateful firewalls, stateful firewalls are quite intelligent. So let’s say that this is a stateful firewall.
So now the client is sending the request towards the server, and the server’s IP is 190 on port 22. Now the statement “firewall” here says that before it allows this specific request to reach the server, it will verify whether port 22 is allowed from this specific IP of the client. If it is allowed, then it will automatically allow the reply from the server back to the client. It will not investigate the outbound. The reason is because it is obvious that if the client is sending the request to the server and if the server’s inbound is allowed, then obviously the server will need to reply back to the client. And this is the reason why the stateful firewall will not really look into the outbound connection. It knows that the request originated from a specific client, so it will allow the outbound request. So the security group in AWS is of type stateful. So let’s look into how exactly this would really look like. So I am in my EC2 console, and I have one EC2 instance up and running. Now, this EC2 instance has a security group. Now, the security group is a stateful firewall. Now, if you look at the inbound and outbound traffic, it is allowing all the traffic. However, in outbound, it is not really allowing any traffic over here, all right? So let’s try and connect to this EC instance over here. So it has the IP from 20 two. So I’m in my CLI, and you can see I’m logged in if we try to log in. The reason I’m logged in here is because of the stateful firewall. Now, does the stateful firewall remember that? So the request came from a specific IP, and it was allowed inbound.
So if the request is allowed inbound and it was initiated by the client, then the server would typically need to reply back. And this is the reason why, irrespective of what you put in the outbound, the server will be able to respond back. So the session state is actually stored within the full firewall state. Now, let me quickly show you something interesting over here. So if I try to do a ping on Google.com, it will not be allowed over here, all right? Now, the reason why it is not allowed is, again, because of the firewall. You see, there are no security group rules in Outbound. And because this is a new request, this request for Google.com is a new request that originates from the server and is directed to the destination of Google.com. This is why it is not permitted over here in the session state. It did not appear that this connection was established. This is a new connection, and this is the reason why outbound is not allowed. So let’s do one thing. Let’s put the outbound here. Let me put outbound as all traffic, and I’ll put all right, so outbound is allowed to be full zero zero. And now if I try to do a ping on Google.com, I am able to do it perfectly well. So this is what the full firewall is all about. Now, we should also look into the stateless firewall, because otherwise, our understanding in terms of practicality will be incomplete. So in AWS, the network ACL is of type “stateless.” So let’s play around with that as well. So I’ll select the VPC where our EC2 instance is, and let’s go a bit down. I have a network ACL. So this is the network ACL. Generally, in AWS, whenever you create a VPC, the network ACL is created by default.
So this is the default network ACL over here, all right? Now this network ACL is of type “stateless.” So, even though the client sends the request to the server, it does not remember the state; if the outbound rule does not allow it, the traffic will not be able to reach the client. So let’s try this out. So, in the security group, I’ll make sure we have full permissions on both inbound and outbound traffic. So the security group will not come into play here. The only thing that will come into play here is the network ACL. So let’s do one thing: let’s edit the outbound room. So here, instead of “allow,” let me put “denied,” and I’ll click on “save” and let’s try to connect to the server yet again. So I’ll do SSS, which is easy to use, at the IP address of the server. And currently, as you can see, I have not been able to connect to the server. If you even try pinging, you will not be able to get a reply back.
Now, in this case, what is happening is that the data, if you talk about ping, from the echo request is successfully reaching the server. However, the server is not being able to reply back because, within the outbound rule of the network ACL, we have everything marked as denied. However, in a security group, even if you do not have an outbound rule here, if you do not have an outbound rule in a security group generally, it is default deny. Now, even if you do not have an outbound rule here, the security group will still allow because it knows that the client has initiated the request and that in the inbound case, traffic was allowed. So for that specific session, outbound will by default be allowed. All right, so now let’s remove this rule. I’ll just put it as “allowed yet again,” and now you see the traffic has been coming back. As we were discussing, one minor issue is that if you use network ACL, you cannot really specify port because different clients use different FML port ranges. So let’s say if you might use this port range in the outbound of the network ACL, and if someone from Windows Express tries to connect to your application, he’ll not be able to get the reply back. As a result, network ACLs typically allow all outbound traffic to be allowed. So this is the high-level overview. I hope you found this practical useful. Now again, let’s revise again. So there are two main types of firewalls. You have a state-full firewall and a stateless firewall. A stateful firewall basically maintains the connection state and knows which packets to allow outbound, even when the outbound is restricted. On the other hand, a stateless firewall does not maintain the connection state for each packet traversing inbound or outbound in a new separate packet. Now, generally, whenever I take interviews, the first question is typically, if it is a security interview, because I have been working in the security domain, one of the first questions that I ask is “stateful versus stateless firewall.” And this is actually one of the more basic things that, if you are working in security or the network security domain, you should be knowing. And I have seen that a lot of other interviewers from organisations also have similar question sets for the interviews. So this is it.
13. Understanding Networking Sockets
Hi everyone, and welcome back to the Knowledge Portal video series. Now, today we are going to speak about a very important topic in terms of TCPIP communication as well as firewalls. And the name of the topic is sockets. So let’s understand what sockets are.
Now, basically, a socket is an endpoint for sending or receiving data. Now, generally, if we take a look at a very, very simple example, let’s say this is a house. Now, in order to send something inside or take something outside from the house, there are three ways. One is through this door, and the second is through this window. And for the evil ones here, we also have the third one, which is the chimney. So basically, there are three ways in which we can take something out as well as get something inside. So if we talk about the “socket” in terms of this house, then the “socket” is the combination of the house number and the entry point. So this is the house number here. So let’s say 150 is the house number, plus the entry point, which can be the front door, front window, or chimney. So basically, in terms of a server, when we compare this to a server, a socket is basically the combination of an IP address and a port number.
Similarly, an IP address denotes the server where the server is located. Similar to a house number, it denotes which house it is and the entry point, which is the port number. So, for example, 192, one 6810, 00:22. So this is the combination of an IP address and colon 22, which is the port number, called a socket. Now, generally, you must be wondering why a socket is required. Most of you might already know, but we will revise it once again. Let’s consider that this is a server. Now, this server is running three applications. One is SSH, which is running on port number 22. The second is NGINX, which runs on port 803, and the third is the MySQL database, which runs on port 3306. Now, there is a client that is sending some data to this particular server. Now, how will the server know to which application it has to send the data to? Now, generally, the server is receiving the data from the client, but there are three applications over here. The server will not know to which application the data has to be sent. And this is the reason why, when sending data to the server, the client will include the full socket as well. That is, in addition to the IP address, the cloud will include the port to which the data is being sent.
So, looking at the example over here, the client will include 192, 168, 10, and dot 0, which is basically the IP address of the server, Colant 22. That means the data the client is sending has to be passed through the SSH application that is running. So including the socket name within the TCP/IP communication is extremely important. Now, again, one thing to remember is that the socket communication is both ways. For example, if a client sends data to server A, which is server A colon 22, the server will send the data to the application running on port 22 once it receives it. Now, before the client can send this data, the client also has to open a particular port, and the server will send that data to the same port. So by that, I mean that before the client has sent the data, the client has first opened this particular port, which is 55607 in the client machine. And from that port, it is sending the data to the server. Now, in response to this data, the server is sending data on this particular port on the client machine. So if you look at the example, the client opens port 55607, from which it will send the data to server A at port 22. Server A has to respond back to the same IP, which is the client B IP, on port 55607. So, on both sides, communication is very simple. So if you’re wondering, this is one of the TCP/IP communication packets. Now, we have already seen this in the previous lectures, but if you will see, this is the source IP and this is the destination IP. Now, this packet is what the client, or computer, is sending to a server. So in the source IP, you’ll see 170 to 21 55. This is the source IP, and it is also saying the source port, which is 552-5427. And it is sending this to the server, IP-followed by the port name, which is 80.
So this means it is some kind of HTTP traffic. Now, if you look into the second packet, the second packet is the response that the server is giving back to the client. Now for the second packet, the server on port 80 is sending data to the client on the same port from which the data originated, which is 55427. If you see 55427, this is the fundamental information about the sockets. So basically, this is one socket; this is the sending socket, as I can say, and this is the receiving socket. Now, if you’re wondering how this looks in practise, let me just show you because practise is always important. OK, let me just log into my Linux machines, so let’s do one thing. Let me open a new terminal, and let’s open the virtual. So if you have not used wireshark, I would really recommend that you use it. It will actually make your networking concepts amazing, so I’ll just open up the wireshark. Okay, let me do one thing. Let me do a curl on Kplabs, okay? And as soon as I did curl, some packets arrived; let me pause the packet capture. So we’ll ignore the DNS and start with the first packet, which is the sync packet. Now, if you’ll notice, the source is my Linux machine’s IP and the destination is my server’s IP. Now, if you look at the IP protocol over here, the IP protocol contains the source IP and the destination IP. So this is the same thing that you see over here. So this means that the packet has been sent from my Linux laptop to the server. Now, in the TCP protocol, remember, TCP deals with source code and a destination port. If you go here, you see the source port is 56739 and the destination port is 80.
So, as soon as I ran the curl, the source port (56739) was open, and the data was sent to port 80. Now, ideally, as of now, if you look into the second packet, which is the response packet over here, and let me see the response, So here, the source port will be 80. Remember, because the response is coming from port 80 and the destination port is 56739, which is this one. As a result, the port and IP combination is critical in TCP/IP-based communication. So generally, all the packets that have been sent, which you see over here, contain the port and the IP. So this is it for the basics of network sockets. I hope this has been informative for you. And there is one more thing that I really wanted to show you in the slide. One question that comes up is, “How are the ports decided?” Like we saw at 56739, how did the client decide which port to use? And the answer is that the client who initiates the request or the client who makes the request selects some FML Portrait Inc. So generally, one rule is that ports zero to 1023 are well-known or reserved ports. So generally, clients will not use these ports. However, after 102-426-5535, it is up to the client to choose which port they want to use. Now, basically, this really depends on which operating system you use. It, like many Linux kernels, will use portraits ranging from three to seven, six, eight, and 61,000. The request, which originates from ELB, uses 102425. One of these ports is used by any port between these and Windows XP. So generally, just by looking at the ports from which the traffic is coming, you can actually determine which operating system it is. So this is the basic information about the network sockets. I hope you have been informed.
14. Revising Security Groups
Hi everyone, and welcome back to the Knowledge Pool video series. So we’ve finally arrived at the point where we can begin working hands-on with the Amazon Security Group and understand how it works. So let’s go back in time a little bit. Initially, Linux servers were managed using Iptables, a command-line-based firewall. So in order to write the rule, we actually had to type “Iptables” or “Iptables”. I typed in the input command, and believe me, it was a pain. Specifically, if you’re managing hundreds of servers manually using Iptables, it’s a real pain. So this is one of the examples of Iptables where, if you really have like 40 or 50 rules, you’re evaluating them, and those things are really a big thing to work on. So, as discussed earlier, the firewall was managed by the Iptables utility. However, thanks to AWS, a GUI-based tool known as a Security Group can now easily manage a Firewall. So Security Group acts as a virtual firewall connected to the EC2 Instances interface.
So when we launch an EC2 instance, we have to associate it with one or more security groups. The best thing about Security Group is that you just click on Edit and do everything the Gui way, and everything starts to work. So there is no need to manually enter the command-line-based tool like Iptables. So, once again, one important thing to remember about the SecurityGroup is that it adheres to the drop-all approach that we discussed last time. As a result, Security Group will by default deny all and allow only some. So let me give you an example. So by default, this security group will deny all the connections except the ones that we specify in the Security Group table. So only the ones that you see over here are allowed to accept this particular connection. All the connections are dropped, and this is a very important thing to remember. So this is an easy instance, and this is the Security Group layer, which works on the deny all approach. And then we manually edit the security group and allow certain IP addresses to connect to the security group. So let’s open the AWS console and see how that works. So this is our public instance, and if we look into the security group, let’s open the security group over here, we can see that this security group has no value or is empty. So as we discussed, the AWS Security Group will follow the drop-all approach. So long as nothing is present over here, it will drop all the connections.
So let us try to connect to this instance via a public IP on port 22. So let me do a telnet on port 22, and you will see that it will not work. So let me close this connection and let’s do one thing: allow a particular IP address to connect to this particular security group. So I’ll add port 22 in the inbound and one 1675 dot zero slash 16 in the outbound. So I’ll click on “Save.” Okay? So now what we have done is explicitly allow this particular subnet to connect on port 22. Now, if I try to connect over here, you’ll see that I’ll be connected to this particular EC2 instance. So this is the basic information about the security group. One thing to remember is that the security group follows the “drop all” and “allow all” approaches that we had discussed in the earlier lecture. So this is the basic information about the security group. We’ll understand more in detail in the upcoming lecture. So I hope this has been informative for you, and good luck for the next lecture.
15. Connection of Security Group & NIC Cards
Hi everyone, and welcome back to the Knowledge Pool video series. Now, in the last lecture, we understood the basics about the security group and how the security group implements the “drop all and allow some” based approach. Now let’s understand this and more about the security group in today’s lecture. Now I have the KP labs. Two instances are running on Hyphen, Public EC. Going big down now. You’ll see there is one security group section, and in this section you will see the security group that is associated with this particular instance. So if I click on “view inbound rules,” it will show me which IPS are allowed on which port. Now, generally, one important thing to remember is that the security group is not associated with this particular instance. However, the security group is actually associated with the network interface connected to the instance. very important thing to remember. So let me give you one simple example.
Generally, a network interface is a hardware device that is present in all computers, servers, and even mobile devices. So if you are wondering what a network interface card is, it looks something like this. So generally, in laptops, as you must have seen, or even in desktops, there is one USB port. So you take that land wire and connect to that land port. So something similar to this exists inside the computer and is known as a network interface card. This card is now critical if you want to communicate both internally and with the Internet. So generally, let me show you my laptop. So, if you look over here, I’m not sure if you can see this specific land port. So, basically, what’s inside is a network interface card that we connect to the landport to enable communication via the internet or a local area network. So similarly, even the servers have a network interface. So if you look over here, there is a network interface, which is ETH 0, which is associated with this particular EC2 instance, and the security group is directly connected to or associated with this particular network interface. So what do I mean by this? Let me actually open this network interface card. Let me click over here. So basically, this is the interface card for my EC2 instance. And if you will see over here, it says that this interface card is associated with this particular security group.
So let’s do one thing. Let’s see if I can find the security group associated with Launch Hyphen Wizard Hyphen One by clicking here. Now let’s go to the interface card associated with this EC Two instance. I’ll right-click over and let me change the security group to testing. And now, if I click on this specific instance, the same instance, you’ll notice that the security group has changed from Launch Hyphen Wizard Hyphen One to Testing. So this clearly shows that the security groups are directly associated with the network interface card. Now, one important thing to remember is that a server can have multiple network interface cards, and when you migrate a network interface card from one server to another, the security group will also change. So this is one thing that is very important to remember. Now, what I mean by that is, let’s click on “network interface” and create a sample network interface. I’ll name it “sample.” I’ll attach it to the public subnet over here, and let’s make the security group the default. So this is our sample; I’ll just name it “sample” so we’ll know. So when I click here, I can basically attach it to any instance I want. I want to attach the public instance. Okay, let’s wait until it gets attached.
Okay, so it is done. If I click on the instance, you’ll notice that the network interface has two buttons. Now it’s Ethan and ETH’s turn. And along with that, there are two private IP addresses as well. The first is for ETH zero, and the second is for ETH one. Now each of these private IPs has a different security group associated with it. So if I click on the ETH One interface, which you’ll see over here, it has the default security group associated. However, if I click on the ETA zero interface, it has a testing security group associated with it. So, if we just detach this particular new interface that we connected, and once it is detached, we can attach it to any other machine, and the security group will move with it. So this is the basic information about the network interface card and how a security group is associated with it. So a very, very important thing to remember is to always remember this, and it will make things simpler in the long run. So this is about the basics of security groups as well as the network interface card, and I’ll see you in the next lecture.
