The firewall is a staple of IT security. In this video, you’ll learn about stateless vs. stateful firewalls, UTMs, next-generation firewalls, web application firewalls, and more.
If you’re connected to the internet at home or in your office, then you are using a firewall to help protect your network from whatever happens to be on the internet. This is a component that allows us to control the flow of traffic. This might be inbound traffic into your network, or it may be traffic that we’re sending out to the internet. This can be especially important in corporate environments where we want to be sure that anyone on the internet does not have access to the sensitive information that’s on the inside of our network.
Your firewall might also include content filtering. So there may be a way for your system administrator to define exactly what type of content you’re able to access on the internet. And with some firewalls, we have– antivirus, anti-malware, and other modes of detecting malicious software if it happens to flow through that firewall.
A traditional firewall is able to control traffic based on the IP address and port numbers that are in use. Some of the newer next-generation firewalls are able to go a step further and identify the applications that may be flowing across the network. Many firewalls can also act as a VPN endpoint for IP site tunnels or communication from end users. This allows you to configure the firewall as the central point of security for all of your remote access devices.
And it’s also very common for your firewall to act, as a layer 3 device can effectively replace the router that you’re using to connect to the internet. This also means that we have the ability to change addressing with network address translation so that you can have a group of internal private addresses. And all of those private addresses are able to communicate to the internet. And since this firewall is acting as a router, you’re able to have dynamic routing, route redistribution and other advanced routing functions.
We can think of the communication on our network as a flow of traffic. We might begin to query a web server from one device and the web server will return a response to our query to the original requester. That is a single flow of communication. And when we make that request to the web server, we naturally expect there’s going to be a response from that web server.
There is an older style of firewall called a stateless firewall that doesn’t have any idea about these flows of communication. A stateless firewall doesn’t know that when you make a request to a web server, that there is going to be a response from that web server, and all traffic going one direction through the firewall needs its own set of rules. Traffic coming the other direction through the firewall needs a completely different set of rules.
A stateless firewall is not able to determine that the response from a web server is being sent inbound because we originally made a request earlier to that web server. This means that the firewall is not going to keep track of any of these flows going back and forth. So it needs to have a rule base that covers all communication in both directions.
This rule base has a first rule which says, the source IP of 10.1.1.1 which is Jack’s workstation is able to communicate to 10.10.10.10 which is the SGC web server. It’s able to communicate to that device using TCP of the port 80 and that information is allowed. Since this firewall has no idea that a state of communication exists, it also needs a rule that allows traffic the other direction.
So we have a second rule in this firewall that allows 10.10.10.10, which is the SGC web server to communicate to 10.1.1.1, which is Jack’s workstation, using any TCP port and allowing that traffic to pass through the network. Let’s test the rules in this stateless firewall.
We’ll begin with Jack communicating to the web server. The firewall evaluates that traffic as 10.1.1.1 communicating to 10.10.10.10. It sees that that information is allowed if that’s TCP port 80. And in this case, it is. So that traffic is allowed through the firewall.
The SGC web server is going to respond to that communication and send the information back to the firewall. But since this is stateless, the firewall has no idea that this is the response to that earlier request. So it has to look into its rule base again and see that there is a rule that allows this traffic from to 10.10.10.10 to 10.1.1.1. Since that is allowed, that information continues to Jack’s workstation.
Let’s say an attacker now gains access to the SGC web server and wants to send some unprompted data into Jack’s workstation. So the SGC web server will send a packet of information. Since the firewall has no idea what the state of this flow might be, the only thing it can rely on is the firewall rule base. And this rule base does allow 10.10.10.10 to communicate to 10.1.1.1, which is Jack’s workstation. And that information even though it is something that could be malicious, is allowed through the firewall.
These days it would be very unusual to find a stateless firewall. Practically, all firewalls that you’ll find are stateful devices. Stateful devices are much more secure and are much more intelligent about how they allow traffic through the network.
Let’s take the same scenario where Jack is going to communicate to the SGC web server. With a stateful firewall, the set of rules is very different. We only need a single rule which would be 10.1.1.1, Jack’s workstation, communicating to 10.10.10.10 which is the SGC web server and that traffic is allowed using TCP port 80 through the firewall. Notice that there is not another rule that allows traffic the other direction. Since this is a stateful firewall, it knows that if a conversation is beginning from Jack that it’s going to allow the return communication through the firewall automatically.
So now let’s send this information from Jack’s computer. It hits the firewall, it’s evaluated, that particular traffic flow is And the firewall creates a state table. The session table is going to have information about this particular flow. This flow is from 10.1.1.1, has a source port of 15442, it is heading to 10.10.10.10 over port 80. And that information continues to the web server.
When the SGC web server responds to that request, the firewall will look through the rule base and see that a rule is not allowed for that traffic. However, it does show an active session table which does show that this is part of an active communication and therefore it allows that traffic back through to Jack’s computer.
If we have the same scenario where the attacker gains access to the web server and is sending information to Jack’s computer without a flow existing originally, when that hits the firewall, it won’t match any of the rule bases. It won’t match anything in the session table because this is using a different destination TCP port and therefore that information will be denied access through the firewall.
You can see that the stateful firewall is much more secure for these active flows. The rule bases are much simpler on a stateful firewall. Which is why the stateful firewall is most likely the default firewall type that you’ll use. Historically, we’ve continued to improve the capabilities of these firewalls and they’ve become more than simply a device that allows or disallows network flows.
We created a newer version of the firewalls called a UTM. This is a Unified Threat Management device or what some people call, a web security gateway. These devices include a number of additional features over simply being a firewall. For example, a UTM might include URL filtering or content inspection, it can look for malware communicating through the firewall, it can provide spam filtering in some cases.
Some of these UTMs have CSU/DSU connectivity for your wide area network serial connections. It could have routing and switching functionality built into interfaces that are on the UTM device. And of course they provide firewalling, IPs/IDS functionality, bandwidth shaping, VPN endpoints and even more.
One of the challenges we have with UTMs is that, there generally was never one single vendor that could provide all of this in a single device. And installing other manufacturer’s code into a third party device often created more problems than it actually solved. We needed a smarter way to include this functionality in a device that was really built to handle the loads of our modern networks.
That’s why most of our enterprise firewalls today are next-generation firewalls or NGFW devices. They are application layer devices that can see the application flows across all of the communication on our network. You might also hear of these called application layer gateways, stateful multilayer inspection devices, or deep packet inspection devices.
A next generation firewall is going to evaluate all of the traffic flowing through the network and it’s able to understand exactly what applications are in use regardless of what IP addresses or port numbers may be used. These are much more intelligent devices than a UTM or a traditional firewall. But every packet has to be analyzed and categorized so that it can then apply security rules to all of the traffic.
Next-generation firewalls are commonly network connected devices. They are able to look at all of the traffic going through and show how much web browsing, how much BitTorrent, how much Blackboard communication, and all of these other applications as well. These might also include intrusion prevention capabilities. There’s usually application-specific rules inside of the firewall that are able to recognize and react to any vulnerabilities that may exist for that application.
And since we’re looking at everything going by with the next-generation firewall, we can also apply rules relating to URL filters or categorizations of URLs. This newer style of security provides much more efficiency and provides more security on the network. Which is why you often see people now throwing out their UTMs and replacing them with next-generation firewalls.
If you’re responsible for securing web services and you want to provide additional security for the information that’s being input into those web service applications, then you need a web application firewall or a WAF. This is not like a traditional firewall that is able to allow or disallow traffic based on IP address or port number. And this is not like a next-generation firewall which is examining application flows. This is a firewall specifically built for web web-based applications. And it’s going to apply rules to the conversations that are taking place for your HTTP and HTTPS based applications.
Instead of allowing or disallowing traffic based on an IP address or port number, a WAF is going to allow or deny traffic based on the input to that particular application. For example, if an attacker sends information to a web server that exploits a SQL injection vulnerability, the WAF can recognize that a SQL injection has been attempted and block that traffic flow.
This is the type of security you would commonly see with very high end web-based applications. If you’re accepting credit card numbers to your website, then you must comply with the Payment Card Industry Data Security Standard or PCI DSS. And part of that compliance requires that you have in place a web application firewall.
Here’s a log file from a web application firewall. This particular firewall has caught some instances where there has been a cross site scripting attack. This particular attempt was denied by the firewall. We have another problem that was an error code four or five, where there was an error from the web server although the response to that error was suppressed so that the end user would not see the error and that information was logged. We also have a SQL injection that was attempted and in this case that particular SQL injection was denied by the web application firewall.
In this video, we’ve described the rule base within a firewall that allows or disallows traffic. You might see this referred to as a security policy or an access control list or ACL. This provides us with a list of rules that the firewall will follow to decide whether information should be allowed through the firewall or denied through the firewall.
The series of variables that you would choose are called tuples, and they are groupings of information. So your firewall can make these forwarding decisions based on the traffic itself. It can find whether there is a source IP a destination IP in use, a particular port number, the time of day, the application that’s being used, and other criteria as well. The firewall evaluates all of these different characteristics to see if it can match any of the rules within the access control list. And once it finds a rule that matches it looks at the disposition for that role to determine whether that information should be allowed or denied through the firewall.
Some firewalls have hundreds or even thousands of rules in the rule-base. So it’s important to understand which particular rule is evaluated first. On most firewalls, it’s done through a top to bottom approach. As the data is coming through the firewall, the firewall tries to match that data based on the information in the first rule at the very top of the rule base. If nothing matches in that rule, the firewall looks at the second rule in the rule base. If nothing matches in that rule we go to the third rule then the fourth and the fifth and so on.
Eventually, we will find a rule that does match the characteristics of that flow and we’ll know what the disposition is. This means we generally put the more specific rules at the top of this firewall list. So these very specific rules can be evaluated before any other rules in the rule base. If we go through this entire list of rules on the firewall and we have no matches to the data flow, you’ll find that most firewalls are configured with an implicit deny. Which means once you get to the bottom of the rule base and nothing matches, none of that data is allowed through the firewall by default.
Let’s step through a firewall rule base and see if we can determine what these particular rules are allowing our denying. We have a rule base that has a rule number, a remote IP address, remote port number, local port number, a protocol and an action. The first rule in the rule base looks for any remote IP address that we’re sending information to over any port number, and it allows us to send this traffic if the local port number is 22 using the TCP protocol. If our network traffic matches that rule, then that information will be allowed through the firewall.
The second rule also has all remote IP addresses. We are communicating to any remote port number. The local port number that’s being used is port 80 over TCP which would be web traffic and that traffic is allowed through the firewall.
Rule 3 is also, any remote IP from any port number is allowed through the firewall if it matches a local port of 443. Which would commonly be HTTPS communication over TCP ports. And again, we are allowing that traffic.
Rule number 4 allows any remote IP over any remote port number to communicate to port 3389 on our local network using the TCP protocol which would commonly be used for remote desktop. This is also allowed traffic. Rule 5 is a little bit different. We are allowing any remote IP but the remote port no that’s allowed is port 53. This would go to any local port number with the UDP protocol, which means we’re allowing DNS traffic into our network.
Rule 6 is a similar rule that allows any remote traffic using port number 123. So this would be the network time protocol for time synchronization. And that is UDP protocol that is allowed to our network.
Now normally, at the bottom of the rule-base, anything else that came through would be denied due to our implicit deny. But implicit denies are not commonly logged. We may decide that certain traffic should always be logged in our firewall. So we have a single rule at the bottom, that for all remote traffic that is communicating via the ICMP protocol into our network, we will deny any of that traffic. And because we have a specific rule written for that deny, that information will be logged in the firewall logs.
There are many different kinds of firewalls with many types of implementations, and those implementations have many different advantages and disadvantages. For example, you have the choice on whether you would like to use an open-source firewall versus a proprietary firewall. Open source firewalls tend to allow or disallow traffic based on the traditional firewall rules for an IP address or a port number.
It’s unusual to find an open-source firewall that has a large understanding of the different applications that can flow through the network. For that functionality, you may want to use a proprietary firewall which does have application control and visibility into all of the application flows on your network, and it’s usually built on hardware that’s designed for these high speed networks.
This is one of the big advantages for having a piece of hardware that has been purpose built. To be a firewall, is that it’s designed for speed. That firewall can provide very efficient traffic flows and provide different types of interfaces so that you’re connecting to not only ethernet networks but perhaps even wider area network or wireless networks as well.
You can also get software based firewalls that you might install on your own hardware. This would give you the flexibility to put these firewalls anywhere you’d like in your organization. And with so many services moving into a virtual environment, it’s important to understand the differences between using an appliance-based physical firewall versus a virtual software-based firewall.
An appliance often has the fastest throughput because there’s purpose-built hardware that’s designed for the speeds and connections that you would commonly find on an enterprise network. On servers and workstations, you can run a host-based firewall. Those devices, since they’re running as part of the operating system, can understand exactly what applications you’re running on that device and can make security decisions based on what applications are in use.
Since you’re also running this on your local machine, it can view information that has been decrypted once it comes off the network. And if you’re in an environment where there’s many different virtual systems, you might want to use a virtual firewall to provide security for all of the traffic within a single data center. We refer to that as East-West traffic. And having a virtual firewall in that environment can help you control exactly what application traffic moves between servers.