Today, “firewall” is a hot word. This isn’t a surprise, as firewalls are the masterpiece component of network security. A firewall is even more than that, it is the starting point of security. Because of that, anyone in IT should know a little bit about firewalls. Well, look no further – this article is just about understanding firewalls. Besides explaining what is a firewall and how does it work, we will see what happens inside the firewall.
Who does need to know firewalls?
Anyone – that’s the short answer. In fact, anyone can benefit from having a little bit of understanding of firewalls. Of course, the security engineer will need to know much more than the home user, but even the home user should know firewalls. This article will give all the knowledge a network engineer would need. Thus, it provides more than enough information for other roles in IT: developers, system engineers, and support engineers.
Understanding Firewalls
What is a Firewall?
If you have read the Free CCNA Course, you probably read Security in the Enterprise as well. In that article, we gave a quick introduction to firewalls, and for the home user that might be enough. Instead, here we are going to dig deeper.
A firewall is a device that let only authorized network traffic pass.
While this defines what a firewall is, we need to add something. To allow only the authorized traffic to pass, a firewall must intercept traffic. We can think about the firewall like a roadblock: vehicles move on the road, and the firewall let only a few of them through. At the roadblock, the police are going to inspect your documents and check if everything is alright. A firewall does exactly that, but with network messages. Here’s a clarifying picture.
As we can see, the Network A must pass through the firewall in order to reach Network B. The other way around is also true, the only way to get between the two networks is the firewall. As a result, each network will send traffic to the firewall, which will inspect it and send it on the other side if it looks ok.
How does a firewall look like?
Understanding firewalls means knowing firewalls. As we know, firewalls are devices – network devices to be more specific. This means that we can have two types of firewalls:
- Hardware – the firewall is a physical device, you can install it in a rack.
- Virtual Machine – it is a template running the firewall’s operating system that can be deployed as a virtual machine in VMWare and VirtualBox. Devices sending the traffic to the firewall won’t notice the difference.
No matter what you use, here we have a key takeaway: a firewall is a device. Even if it is virtual, it is still a virtual device. Don’t get yourself fooled by things like Windows Firewall. That’s not a real firewall, as it doesn’t connect multiple networks. Instead, it is an endpoint protection mechanism that implements some firewall-like rules.
Firewall’s Operation
The Zones
In order to allow or deny a given type of traffic, a firewall must use a set of rules. We will see these rules later in this article, but for now, we need to understand how the firewall applies them.
Each packet (network message) contains information about where it is headed, so the firewall immediately knows where to send it. Knowing where the packet is coming from, and where the packet is going, the firewall can apply a custom set of rules. Of course, a packet is coming on an interface (a network card) and going out of another. We could simply say “for all traffic coming from interface X and going to interface Y, apply this set of rules”. This works, and you will find firewalls structured with this approach.
Zones add flexibility. You create a zone, which is just a group of interfaces. Then, you create a custom set of policies from a zone to another. Therefore, you don’t need a custom set of policies for each pair of interfaces, only one per pair of zones.
Here we can clearly see that we grouped what is “inside the company” in a zone named Trust. Then, we put the Internet in a zone named Untrust and the company exposed services in the DMZ. These legs with the name of the zone are not interfaces, they are zone. The firewall may have a dedicated network card (and cable) going to the Campus, and another to the Datacenter. This is not a problem, you will configure both NICs to be part of the Trust zone.
Naming the zones
As a network administrator, you could name the zones whatever you want. Don’t do that: standard names exist, and you should use them. Specifically, we have four zones common to most deployments.
- Trust represents what you trust, the inside of your company. Some administrators may call it inside, but the most common name is just trust.
- Untrust, instead, is what you don’t trust. If the firewall is connecting to the Internet, the Internet is going to be here. Instead, if the firewall connects to a third-party supplier, it is not going to trust their network.
- DMZ Inside (Demilitarized Zone) is a part of your internal network which, that the firewall exposes to the Internet. This means that devices on the Internet (or Untrust in general) will be able to initiate a connection to your devices in this zone. However, these devices will have private IP addresses and the firewall will do NAT on them.
- DMZ Outside is identical to the DMZ Inside, but devices have public IP addresses, thus the firewall does not need to do NAT.
In case you have a custom deployment where you need to have zones that do not meet the purpose of the ones above, use your own names. For example, you could use MPLS or Extranet as a zone name if you are connecting to an MPLS network.
The Policies
By knowing the source and the destination zone, the firewall knows which set of rules to use. As an administrator, you can define a set of rules for each pair of zones.
When a packet comes in, the firewall will process all the rules (or policies) in the set with a top-down approach. This means it will look the first, then the second and so on – until we have a match. In fact, each rule contains two things: something to identify the traffic, and the action to take on the match.
In case the packet does not match against any rule, all firewalls have an implicit deny rule at the end. This rule will simply block all the traffic that didn’t match.
Anatomy of a Policy
A firewall rule will look something like the one below.
Firewall shows their set of rules in a table because all rules have the same fields – specified in the columns.
- Parts to identify the traffic
- The first column is the Source and identifies a network or group of networks. We use this field to identify the group of devices generating the traffic.
- After the source, we have the Destination. This identifies a network or group of networks as well, with the ultimate goal to identify the devices that will eventually receive this traffic.
- The key component here is the Service because it defines the type of traffic. A service is a combination of source and destination UDP/TCP ports, plus many firewalls have pre-defined services like FTP or HTTP.
- Parts to act
- The pivotal field is the Action, which can be permit or deny. Here we tell the firewall what to do in case we have a match.
- In some cases, we might need to rewrite the packet and change its source and destination. This is NAT, and we define some NAT rules in this special column. The firewall will apply them only to the permitted flows.
- Logging is always crucial, as we want to know what happens. We can log all sessions, or only the sessions violating a policy.
Understanding firewalls and policies
All modern firewalls are stateful. This means they store some information about the traffic which is going on, to make your life easier. Their ultimate goal is to automatically permit response traffic.
Imagine you, from the internal network, wants to browse in HTTP to a public website in the untrust. You may be allowed to reach the Untrust, but we don’t want Untrust traffic to get in. However, we want you to get your page, so we must let the response from the webserver in. A stateless firewall won’t do that, but on a stateful firewall, we have some magic. It will remember your request, and the traffic from the web server will pass. Even if you have just a deny any on your Untrust to Trust set of policies, the firewall will allow it. Isn’t this awesome?
With this in mind, we can say that our policies apply to the initiator of traffic. They will define which device can initiate a connection on a given service, toward which other devices.
Firewall Objects
So, in each policy, we are going to define networks and services. Are we going to write to them manually? Of course not! Modern firewalls have the concept of objects and groups. You define a network once, and you give it an self-explanatory name. Then, you can recall that object in all the policies you need by its name.
On top of that, you can define groups. A group is just a group of networks, that you can easily recall in your policies. For example, you may have one network on each floor of a building. You can group all of them into the building group, and then use that in the policies. This will save you a lot of time.
The same is true also for custom services, in case your clients need something different from standard services like HTTP, FTP, and SMTP.
Policy packages and centralized management
Some networks are going to have many firewalls. In a similar environment, you may benefit from a centralized management system. All vendors have something like that. Basically, you have a server that controls the deployment of policies to all the firewalls in your network.
This is awesome and introduces the concept of policy package. A policy package is a set of policies that you can install on a firewall, containing all the sets for each pair of zones. On the centralized servers, you define such packages and then push them to the devices. What is the advantage of that? You can push the same package to multiple firewalls.
This comes really handy in case you have many remote sites with identical policies. With this approach, you can deploy them easily.
Application Inspection
Modern firewalls can be more than a firewall. This will consume more resources, and reduce their throughput – but they will have more advanced features.
A common feature you can add is application inspection. Often, attackers disguise their traffic as innocent traffic (like DNS) to bypass the firewall. However, if you look inside the DNS packet, you will see information with no meaning. That’s because they are not DNS messages – if you read them like SSH or HTTP, you will see their content. All in all, an application is sent inside another. Modern firewalls can perform application inspection to detect that and block malicious traffic.
Flow Troubleshooting
One day we were troubleshooting an application flow. A device had to talk with another, yet they didn’t. At some point, one of the people in charge of setting up the application said something like that:
Yeah.. it must be the firewall, I’ve been told that if it doesn’t work it gotta be the firewall.
Surprisingly, many people have a similar feeling. If some application stream doesn’t work, the firewall in the middle must be blocking it. This is possible and can be easily verified. However, I’ve seen that this problem is often related to the following two points:
- The target is not listening – The firewall will let you pass, but is the receiver ready to listen and reply?
- Some ports and services are missing – A request is going to pass if the firewall has an explicit rule for it. In case the application is using some ports and services the firewall doesn’t know about, these will be blocked and the application won’t work.
If you are working as a developer or setting up systems and servers, remember that. This will save you a lot of time you would use in an endless troubleshooting instead.
Conclusion
Firewalls are great devices, they are the pillar of network security. If you have them, you can think about advanced network security like forensics, IPSs, and so on. Now that you understand them you can better see the whole picture and even make your policies in a firewall if you need to.
What are your thoughts? Do you use firewalls? What do you find most challenging in that? Let me know in the comments!
