the next concept of our firewalls that we need to understand after our hardware versus software firewalls is our state full inspection versus our packet filtering firewalls. Now we're talking about state full in fact inspection. We're talking about a fire. Well, that is going to filter traffic. Just based on what's in the I P header,
the I P header is going to contain information just
such as our destination and source I p address our destination and sore sport and our type of protocol that we're using. And if we haven't a packet filtering firewall, it's just going to base its drop or allow based on those items that are in that packet header. So it's going to say, OK,
I'm don't allow traffic through this port
blocked. I don't allow traffic with this protocol blocked. I don't allow traffic from this from this location. From this I p block, I don't traffic to this I p blocked. So
our packet filtering is just going to be based off of our our pack of the header of our
state full for our state. Full firewall, however, is going to be a little bit different. Our state for firewall is actually going to inspect the traffic and it'll and allow initiated traffic back in. So if we have a
staple firewall and we have a inside computer so inside our private network and we have a server
out there on the network, then
our computer is going to try to talk to the server out on the Internet.
Now, the normal rule for this firewall
is to deny traffic over a certain port from this server.
So say this is a file. Say this is a file transfer protocol server and normally our firewall is to deny that traffic.
Normally, this firewall is going to deny file transfer protocol, sir, traffic over
over the Internet through its firewall. So if this server would have tried to send
FTP traffic, it would be blocked at the firewall by itself.
Now, let's say our outbound rule is different than our inbound rule.
Our outbound rule does allow initiating FTP traffic. So
are inside. Computer
goes out by itself to this server,
and it's allowed through the firewall because our outbound rule is different and it says, Hey, I want to initiate an FTP session.
This server women say OK, let me start talking back to you and sending the file
in a packet filtering firewall. It wouldn't matter that our computer went out and tried and initiated the session.
The rule doesn't change. We hit that port and it's blocked
on a state full inspection firewall. Our firewall read. This packet is it went through saw that we were initiating an FTP session with this server. So for a limited amount of time is going to allow the return traffic back in.
So it says Okay, I saw that you initiated a request. Let me listen and see if I can see the response back coming from the FTP server once it sees that it has that response back coming from the destination, the source that was the destination of that previous packet. It's going to allow this packet through,
and that's our state full inspection firewall,
our packet filtering firewall. We can configure it in certain ways, using things such as poor triggering, which we have talked about earlier to allow a semblance of a state full inspection. Port triggering essentially tells our firewall that if I send data out of this port,
I want you to temporarily allow data in this other port.
So if we just have a packet filtering firewall that allows us to dio port triggering, then we can tell it if I send an outbound FTP connection that I want you to temporarily allow FTP connections in for a limited amount of time. But that's still not a state full inspection firewall.
Our firewall is still on Lee inspecting the I P Header.
It's not actually inspecting the packet and seeing what type of data it iss
in a state full inspection firewall. Our firewall is not basing it necessarily just on port triggering, but is basing it off of actually looking at the packet, seeing that we're initiating a session and then allowing that session to talk back into us Now,
what's one of the downsides of a state for firewall?
Or if we don't have our outbound and inbound rules configured properly, a state bound firewall, a state full firewall can leave us vulnerable to attacks.
How so? Let's say that this this server is has now been infected and we're just browsing on this server were on the servers website, and this server is going to send us a malicious packet over a port that it is pretty sure is going to be allowed through the firewall. And that's port 80.
It's going to send it http packet of report 80 because http is Internet and Port 80 is the default port for http. So if this viral allows people to browse the Internet, then it's going to me to get that request back through, Port 80 is gonna need to be able to allow us to receive Web pages through that port
a packet through that port 80
Now, this pack it in and of itself isn't large enough for them to crew. Maybe this packet isn't large enough for them to create a remote session into our computer. It's not large enough it doesn't have all of the data that we need to transfer to them in orderto fully infect their computer.
What it does, however, is this packet causes the target computer to initiate a session back to us.
So essentially, we're reverse attacking this computer
because now this target computer will initiate a session back to us through the firewall through a particular port that we have specified and the through the act of initiating a session to us. This firewall now through state ful for state full inspection, it sees that
the other side initiated a new session. Tow us.
So our original session
And it was a small http
and a CT P Port 80 is commonly allowed,
but we need to send them a large file transfer protocol packet. We want to send them a larger file to their computer or we want to pull larger files from their computer
or we want already pee onto their computer. And this file does. This firewall does not allow inbound connections over any other port. It doesn't allow allow inbound FTP or rdp, but it does allow some outbound things.
So now this computer is going to send an outbound because we've hit it with a malicious packet.
And with that malicious packet, we've said, I want to send and out, I want this computer to send an outbound request, a report for 484
And then once I receive that outbound request, the firewall is going to say Okay, you're expecting to talk to you
Server a so I'm goingto let server a talk back to you over this same port.
And now I can now initiate The malicious server can now initiate a session back to me and send me whatever it wants to.
So the state full firewall, because of the state for firewall and because it inspected this is traffic. And it's thought that the inside computer knew what it was doing. It allowed an initiated session to come back into the computer.
this could be mitigated by
making sure that we don't have that original vulnerability in the first place. That allowed the computer that told the computer to talk back to us. So making sure that we're watching out for filtering idee S I. P s that were patching software and also that we keep an eye on outbound traffic just as much as we keep an eye on inbound traffic.
Typically, we have more outbound rules that we allow the inbound rules, but we need to make sure that we don't just say allow all to outbound rules. We don't just say allow all unusual traffic outbound to anywhere because that can cause issues. If something like that were to happen if in malicious computer.
If a malicious computer outside would affect an internal computer
and then that internal computer will try to start talking back out, we'll talk about inbound and outbound rules. Ah, little bit more
with our firewall rules. So our firewall rules when we're setting up the rules on our firewall, we typically have two main distinctions between traffic flow. We have inbound versus outbound
and redrawing our diagram that we just race
an inbound fire. World rule
is going to be a firewall rule that dictates what is allowed from the public network into our private network.
So we have this server out here on the Internet
that is trying to talk to us into our private network.
So any traffic that is coming from the private network into our public in tow, any traffic that is coming from our public network into our private network is inbound traffic.
Any traffic that is going from our private network out to the public network is outbound traffic.
We're configuring our firewall rules, was not only specifying allowed and disallowed ports allowed and just allowed protocols, but we're specifying
them based on whether they're inbound, outbound or both.
So if we say we want to allow FTP connections out, but we don't want to allow them in, we can do that. We can allow Port 80 requests out a CZ well, as in, so that we can talk over the Internet.
So we need to make sure that when we're setting up our firewall rules, we realize that if we're setting them as inbound or outbound, and that we also recognize that sometimes are, and quite often are outbound firewall rules are a little bit less are a bit less restrictive than are inbound firewall rules,
because we want the people inside of our environment to be able to talk out and make communications that they initiate
because we trust them more
possibly. Hopefully then we trust the people outside of our network, so we trust them more, and we trust the communications that they're initiating more than we trust by a lot the communications that are coming out from the public network because this could be anybody trying to connect into our network. So we trust the out. We trust our outbound rules more than are inbound rules.
we don't want to ignore these outbound rules, though we have something that
right here that will talk about called implicit, denying where
inbound rules typically have implicit deny at the end of the rule list. That says, If I don't know what any of this is, if I receive a packet that I don't have a rule for, I drop it.
If I don't. If I don't explicitly have an allow for this room that I'm going to deny it. It's an implicit deny. It's implied that we deny anything that we don't have a specifically written allow for. It's like a list to a club, our list to an exclusive club. If you're not on the list, you're not getting it.
It doesn't matter. It doesn't matter. I thought, If your name isn't on here, you're not getting in.
Are the converse to? That would be an implicit allowed, which is a which is a note, which would be a no fly list. Maybe you're allowed is long as you're not on this list.
If you're not on this list, then you can go through.
We may not want to do that with our outbound rules, because there because of that situation, we just talked about earlier where we may have inbound. We may have internal computers that are infected there, trying to talk out and send unusual traffic outbound. So just because it's an internal computer, trying to talk out
doesn't mean we need to automatically assume that it's it's good to go
and just allow it to have any outbound connections and just implicitly allow these Alabam connections. Typically, we would want to set toe, have that implicit, deny inbound and outbound, and then write specific rules for allowing traffic inbound and outbound that need to be on that list for the traffic to go through.
So now we have our block and allow now are Brock and allow our our two rules that essentially say, I'm goingto block this traffic. I'm going to drop it and not ford it along, or I'm going to allow this traffic, and I'm going to let it pass through now. This could be based on things such as the port number, the logical port number
of the computer, such as http Port 80.
This could be based on the protocols, such as http or as a sage or FTP. This can be based on the I p address of the outside computer. If we have a public computer that we identify as a malicious computer that has tried to attack us before, we could just block that I p address or block an I p address range
and say that no packets are allowed from this
particular I p address. Weaken blacklisted,
or we can identify it by Mac address. Weaken. Set certain rules for certain specific network interface nodes on the inside of our network going outbound so we can set these block in, allow rules based on ports and protocols and I p addresses and Mac addresses, and we set them on our inbound or outbound rules
so we block or allow
on an inbound or outbound rule based on a certain criteria.
And then, of course, we have our implicit deny that we just talked about that after we write our entire list after we have our inbound and outbound list and we have all of our block and allow rules at the bottom will have our implicit deny, which is a strong security pot, a stronger security posture, which says if
you're not on this list, you're not allowed,
it doesn't matter if it looks malicious, it doesn't matter if it looks like nothing, it doesn't matter if it's a one bit pack. It doesn't matter for the one bite packet. If you're not on this list. If you're not recognized traffic that I allow through, then you're you're implicitly denied. It's implied that you're not getting in unless you're on this list. So
that and that would be the last.
That would be the last rule on our list because our rules would go down would go down sequentially. So if the implicit deny was the first rule on our list, then nothing would get through because we would hit that first rule and it would say, deny all and everything would be blocked. But as we go down and we see if we say OK,
denying allowed and I allow allow allowed tonight
and then we had our last rule, which is deny all if our packet hasn't matched any of those rules as we go down. Our last rule is our catchall and we deny everything.
So that's why it's our last rule on our list
and then we have our access control lists are access control lists are going to be permitted or slash denied traffic and we can spit. Specify them based on our I p address. Port Mac address sort source your destination. Now we've talked about access control lists in our previous module, and when we say port here
were mostly talking about our physical port.
So we're specifying our access control. Lis Weir, specifying which hosts can talk who are allowed to talk out over ports, were specifying who is allowed, who is permitted to talk over this over this firewall and what in what
traffic they're allowed to send out Bound and who is allowed to send so host a host be and who is allowed to send data inbound over this port we've talked about. We talked about access control this in a couple a couple modules ago
S O. If you want a little bit more of an in depth explanation about them, check that check those out as well.
But again, just know that our access control lists are going to be allowed are going to allow us to specify based on actual hosts who is allowed and who was denied from sending traffic over certain ports