How does a firewall know which traffic is good, and which traffic is bad? In this video, you’ll learn about the fundamentals of firewall rules and you’ll step through an actual firewall rule set.
<< Previous Video: Application-Aware Security DevicesNext: VLAN Management >>
When you work in technology, and especially in security with technology, there’s a lot of rules involved. These rules are procedural rules, they’re rules about the way that our devices operate, they’re rules about allowing people access to different things. A lot of the things that we do, really, are procedural. They’re both technical and non-technical in nature.
You need policies and procedures, and what happens when somebody walks into your building and they don’t have their badge? You need policies and procedures when a new person is hired. What is the process for getting them the proper credentials to the network?
And of course, there’s technical procedures as well. When somebody is asking for those credentials, how do you provide those credentials? There’s got to be a way that you provide that into your system.
They’re for environments that are dealing with finances or medical or other sensitive types of data. There are also a lot of very specific rules as well. Some of these rules are things that you’ve created internally, some of these rules have been created by third parties and are required of you to maintain because of the types of environments that you have. If you’re someone who has medical information– that’s very private information– there are certain rules and requirements that you must follow to be able to protect your patients’ data.
When we look at our technical devices like firewalls, there’s packet filters, even email systems have filtering rules within them. These are, in some cases, very very technical rules. We’re dealing with bits and bytes, and so we also have to apply those rules to what we’re doing as well. Sometimes, in fact almost all the time, our technical rules are going to follow the procedural rules that we set up.
When somebody is asking for credentials to be able to log into the network they might fill out a form, they might visit a web page and add their information, and then you’ve now got to provide the technical back end to provide them that data. So you’re almost always spending a lot of time– before you even touch a keyboard– determining what the process is going to be. Determining what somebody has to provide you in order for you to get them the access that they need.
These are things that, hopefully, you’re figuring out based on your requirements for your business or your organization. But very often you’re taking into account a lot of different requirements from a lot of different people and putting that all together to create the technical answer that you might need.
Let’s start a technical discussion of rules dealing with firewall rules, because as a security professional you are going to be using firewalls quite a bit, and you’re going to be going through the rule bases to allow or deny people access to certain resources. And as we look at the rules of the firewall, we’re usually making the decisions on what people can do based on a number of different tuples.
These are different categorizations of data that we’ll then add information to. So we may decide if somebody is coming from a certain source IP address, they may be going to a certain destination IP address, maybe using a certain kind of port number. It may be a certain time of the day, they may be using a certain application, and on and on and on.
Different firewalls have different tuples that you could use to make this determination. And we’ll group that together and say if you match all of these put together, then you are either allowed or denied access to certain resources. Usually, there is also a logical path that you follow with firewall rules. Almost always, you start at the top of a rule base and you work your way down.
It’s not that way with every firewall, however. You’ll need to look at your particular firewall and how it operates to find out exactly the path that it follows, to be able to determine whether somebody has access to the internet or not. These rules can also be very generalized. Maybe you might want to set a rule that says if you’re anybody inside the network, you can surf the internet. That’s a very general rule.
Or it might be very specific, that says if you are in the marketing department and you are coming from a particular source IP address, then you have access to this particular resource on the internet that is that another IP address. That’s a very specific role. So you tend to put those specific rules at the top of your firewall list so that they’re fired on first if it applies, and then other more general rules are at the bottom.
In almost all firewalls– this is not always the case– but a good firewall, anyway, I like to think that there is something called an implicit deny at the very bottom of that list. And that means that if it goes through your list of rules and at the very bottom of the list it hasn’t hit any of those rules, we’re just going to drop the traffic. It is implicitly denied traffic at the bottom.
Some people will put an explicit deny at the bottom. They’ll create a rule at the bottom of their firewall that says if it’s any-to-any type traffic at the bottom, deny everything. Sometimes that’s useful just so you can see it, and know that that rule is being fired on. Sometimes they’re doing it so that it gets logged, because usually implicit denies don’t log traffic.
Can you imagine logging everything that comes in from an internet connection that’s not intended to come inside of your network? It would be an enormous amount of traffic. Some people, however, would like to see that information. So they may put an explicit deny down at the bottom of the rule base, just so they can capture and log some of that information coming by. If you don’t put a rule, then it’s probably the case that your firewall has an implicit deny, and it’s going to drop all that traffic anyway.
Let’s step through a very simple firewall rule base, and let’s see what’s really involved here. I grabbed this rule set directly from an internet service provider. This is their default configuration for their web servers on their Linux host. And you can see they’re numbered one through seven, all in order. In fact, they start from the top and work their way down.
And you can see there is a default policy here. This particular rule set has an implicit deny, which means unless you’re allowing it in this list, it gets denied.
So let’s start with rule number one, which says if you’re coming from any remote IP address on any remote port number, and you’re connecting to this particular web server on port 22 with the TCP protocol, we’re going to allow that. If you’re a really good person about documenting your particular firewall rules– there may be one of these fields that’s a description field– and you may put in here that this rule allows anybody to be able to SSH to our particular firewall.
This is how you take those well-known port numbers and apply them back to certain applications that are used. Now that that matches, we’ll then allow an SSH. So let’s go down to the next one, let’s say the traffic coming through doesn’t match that, then we’ll examine this rule. It says from any remote IP to any remote port number over port 80 that’s running TCP, allow that traffic.
And of course, port 80 TCP is HTTP based traffic, usually. That’s our web service traffic. So if we’re running a web server on this machine, somebody’s trying to connect to it with a browser, it is the firewall rule number two that will allow that traffic to connect to this server.
Let’s do one more. Rule number three is remote IP is any talking to any remote port number over port 443. That is the TCP protocol. Allow it, and of course, port 443 is HTTPS. And you would step through this list and make sure that everything here is what you would like it to be.
In fact, the next rule that says allow all IPs from any port number to local port 8443 over the TCP protocol, allow it. That’s not one you often see. 8443 is not usually a well known protocol. That is a protocol that is used– a port number that’s used– to open up access to the management part of the web server. So if you don’t want people managing your web server with that front-end web based management that you’ve created, you may want to deny traffic if it’s coming from any remote IP address.
So that’s a good example of how you can allow or disallow the traffic based on any of these port numbers coming through. And we’re simply following the rules of our firewall, one after the other, until it either fires or gets to the bottom where traffic is implicitly denied.