If you have a network connection or operating system, then you certainly have a firewall. In this video, you’ll learn about firewall states, application-aware firewalls, and how to evaluate a firewall ruleset.
<< Previous Video: Vulnerability Types Next: VPN Concentrators >>
What is a more ubiquitous security technology than the firewall? We use it everywhere. We use it on our workstations. We use it at home. We use it at our offices. It seems to be everywhere we’re connecting to the internet, we’re using a firewall.
And why not? It’s used to control the flow of traffic, to prevent bad traffic from coming to the inside of your network, and in some cases, to keep bad traffic from leaving your network.
If you’re in a corporate or organization that needs to control this traffic flow, you’ve probably got a firewall in place that’s handling all of those rule sets for you. This is another place where you can also control the type of content that’s going back and forth– not just who you’re talking to, but what is inside the content that you’re sending to that other device.
And some firewalls will even let you filter bad traffic. So you can have the firewall prevent viruses, malware, adware, spyware from coming into your environment and infecting your systems.
Traditional network-based firewalls filter traffic by TCP or UDP port number. That’s OSI layer 4, the transport layer of the OSI stack, although, these days, next-generation firewalls and modern technologies allow us to filter based on the application. That allows us to filter all the way up to OSI layer 7.
These devices also make very good VPN concentrators. They are very often used as the endpoint to a VPN that’s connecting to a remote site. And some firewalls even have proxy capabilities built into them so they can manage traffic flows by application type.
And most commonly, our network-based firewalls are layer 3 devices. It’s very common to route from the inside of your network to the other. And very often, we’ll perform a network address translation in the middle of that communication.
You can think of a stateless firewall as a packet filter. It doesn’t keep track of any of the sessions that are currently active. It’s simply looking at the traffic going by, comparing it to a list of access controls, and then either allowing or disallowing that traffic.
A good example is Jack, who is communicating to this web server. Because he’s communicating through a stateless firewall, we not only need rules to allow the outbound traffic– we also need rules to allow the inbound traffic, as well.
You see, Jack’s IP address is 10.1.1.1. And rule one says that if the source is 10.1.1.1 communicating to 10.10.10.10, the web server, over TCP port 80, to allow that traffic. But because this is stateless, we also need a rule in the other direction that will allow traffic from the web server to communicate back to Jack over any TCP port number.
So when Jack sends that traffic, it is checked against that rule base. If it matches any of those rules, it’s allowed through. When the traffic comes back the other direction from the web server, the rule base has to be checked again. And as long as a rule is in place, this stateless firewall will allow that traffic to flow.
Stateful firewalls are a bit more intelligent. They can allow traffic flows to be built. And they will keep track of what traffic flows are active and only allow that traffic to pass through the firewall.
You can see on a staple firewall, our access control list is a little bit different. We only have a single rule that allows Jack to communicate out to the web server. And the destination protocol is TCP port 80. So that would be web traffic going to that server.
When traffic passes through the firewall, the firewall makes a note of this active session and designates the IP addresses and the port numbers for both the source and the destination. When the web server replies to that traffic within the same traffic flow, the firewall checks the session table, determines that that is an active flow and that traffic is currently allowed, and continues to forward that traffic on to Jack’s workstation.
If there was traffic that came from the web server, destined to Jack, that was not part of one of those active flows, the firewall would recognize that it was not part of the session table. And it would drop that traffic at the firewall.
That’s a unique capability that you’ll find in a stateful firewall. That’s one of the biggest reasons why, these days, most of the firewalls that you’ll find are stateful devices.
Today’s modern firewalls go well beyond looking at a TCP or a UDP port number. Instead, they identify traffic flows based on the type of application that’s going by. You may see these firewalls referred to as application layer gateways, deep packet inspection, next generation firewalls. But the key is that these devices are watching traffic at the packet level and examining the data that’s within all of these packets. They’re able to do a decode of that information and determine exactly what application is flowing within those data frames.
This means that a network-based firewall can look at traffic and determine, immediately, if that’s traffic from Microsoft SQL Server, if that’s Twitter traffic, if that’s going to Facebook. And it might have thousands of different applications that it recognizes.
We also see this application-level visibility helping for modern intrusion prevention systems. If an IP can identify the application that’s in use, then it can use a subset of signatures and become more focused at finding vulnerabilities for a particular application. This also keeps down the number of false positives that you might get from an IPS.
And a host-based firewall is already on an operating system. It already knows what applications you’re using. And you can define rules within your host-based firewall to allow or disallow specific executables from running and communicating across the network.
Firewalls determine whether traffic is allowed or not allowed through the firewall, based on a series of rules. We call these rules access control lists. You might also see them referred to as security policies. But effectively, they are a group of variables that you compare against the traffic going by. And then it makes a determination of whether that traffic is allowed or not.
Sometimes, you’ll see this grouping of variables referred to as tuples. An example of a tuple might be a source IP address, destination IP address, the time of day, a port number that’s in use, or anything else that firewall can use to start comparing different characteristics of traffic.
Firewall rule lists are usually examined from the top of the list, down through the bottom. Firewall will look at the first rule, see if anything matches in that particular rule. If it doesn’t, it goes to the next rule and see if that rule matches the traffic, and so on.
As soon as all of the tuples of a rule match the traffic that’s going by, the firewall takes action, based on what the disposition is for that particular rule. These firewall rules can be very generalized. Maybe you’d like to allow all traffic through the firewall that is communicating over port 80. Or you’d like to be very specific with your rules, maybe only allow traffic between two devices that are communicating with a particular port number, using a particular application during a particular time of the day.
On most firewalls, once you have gone through the entire list and examined every rule, at the bottom of the list may not be a rule that’s visible, but it is an implied deny. This means that if the traffic coming through the firewall doesn’t match any of these rules, it is dropped by the firewall.
Here’s an example of rules set for a port-based firewall that is in front of a web server. Rule number one on the firewall says that if traffic is coming from any remote IP address across any port number, and it’s communicating to our web server over local port TCP 22, we’re going to allow that traffic to the server. That’s obviously going to allow SSH console traffic to our web server.
Rule number two says that any IP address is sending traffic on any port number to port 80 over TCP on our server, then we’re going to allow that traffic. And that’s obviously going to allow our nonencrypted HTTP traffic.
Rule number three is a similar rule. This one allows TCP traffic over port 443 to our server. So that would allow our SSL traffic to our web server.
Rule number four also allows traffic. But this allows any traffic using TCP 3389. Obviously, someone here is doing remote desktop traffic to that web server.
Rule number five is a little bit different. This one is going to allow all remote IP traffic from port 53 to communicate to any local port number over UDP. This is going to allow DNS traffic to communicate to our web server.
And we’re also going to allow inbound traffic over port 123, using the UDP protocol to our server. Our server must also be acting as NTP server because that’s the port number used by NTP.
And lastly, we have a rule 7 that says for any traffic coming inbound that is using the ICMP protocol, we’re going to deny that traffic. That means if somebody does try to ping our web server, we will not allow that ICMP traffic to traverse the firewall.