Transcription
If you're managing rules in a firewall, what you'll find is the rules themselves are based on something called tuples. A tuple is a type of variable; it's a grouping of things. For instance, you're setting up a rule in a firewall to allow one certain IP to talk to a destination IP. That source IP and that destination IP are good examples of a tuple.
In a firewall, you might have a source and destination IP address. There might be a port number associated with that rule. There may be a time of day tuple associated with that firewall rule, or maybe even an application name if it's one of the newer types of firewalls. Firewalls can have other types of tuples inside of them, but generally, it's things that are relatively obvious that will allow or disallow traffic from flowing through that firewall.
If you look at the firewall rules, they take a very logical path. They start at the top of the list and they work their way down. So, as traffic is coming into the firewall, the firewall begins looking at the list of rules that it has and examines the traffic coming in to see if it matches their first rule. If it doesn't, then it goes to the second rule. It examines that rule and sees if it matches. If it doesn't match any of those tuples, it goes to the third rule and so on. As soon as it matches one of those firewall rules, it reacts to whatever the disposition is for that rule. We allow the traffic through, or we don't allow the traffic through. So, the firewall simply starts at the top of the list and works its way to the bottom of the list for every flow coming through the firewall.
With all of these tuples, you can create some very, very specific security rules. You might have a rule that says, "If you are sourced from a particular IP address, using a particular port number, and you're going to another IP address to a different port number, then allow that traffic through, as long as it's after five o'clock in the afternoon." That's a very, very specific rule.
There may be another rule that's much broader that says, "Anybody that is on the inside of the network can communicate out to the outside of the network." If that's the case, you want to have your very specific rules near the top of your list because if everybody hits that first rule and it's very broad, it will never get lower in the list for that second rule or more specific rule to fire. So, you want to have the more specific rules generally at the top of the list of rules in your firewall.
These days, almost every firewall has at the very bottom of the list an implicit deny. That means that we will allow traffic through as long as it matches anything in the list of access rules in the firewall. If it's not specifically listed in a rule to allow that traffic through, we're going to implicitly deny everything else. This is something you don't see, but you can imagine it. Once all of these rules go through their entire list and finally hit the bottom, you can imagine an extra rule at the bottom that says, "Deny everything else."
Sometimes people will put a physical deny all rule at the bottom of the firewall. Sometimes they like to be able to see that and confirm indeed it is hitting this rule at the bottom. Some people also like to log this traffic. So, by having a rule, they can also say, "Log every time this particular rule fires." That way, they can see all the traffic that's allowed through the firewall, and they can see all the traffic that was denied access through the firewall.
Let's step through a very simple firewall rule base so you get an idea of what these might look like. This is from a very simple rule set that is created for a Linux web server, and you can see, just as we mentioned, the default policy on this particular list is to deny everything.
The first rule says, "If traffic is coming from any remote IP address, from any remote port, and it's coming into our server on port 22 TCP, then we're going to allow that traffic." That means if somebody's going to SSH into this device, we're going to allow it because the default port for SSH is TCP port 22.
The next rule, number two, says, "If traffic's coming from any remote IP address on any remote port number, allow port 80 TCP." That's obviously our unencrypted web traffic communication.
The next rule says, "We will allow traffic from anywhere to port 443," and that's the other part of our web server that is encrypted web traffic.
This next rule is using a port number you don't often see. This is from any location using any port number communicating to our local server / port 8443. Well, you'd have to go to the server to really understand this, but that is a port that's open so that an administrator can do remote administration of that web server, and it uses port 8443. In reality, it's really sending back and forth HTTP or encrypted web traffic.
The next rule was built specifically for DNS. It says that if it's from any IP address and the remote port number is 53, then we're going to allow access into our server over UDP.
The next rule is for NTP. You can see port 123 is also allowed as remote communication.
And the last rule here allows us to ping this particular web server because ICMP is enabled to this device.
A firewall rule base as small as this is relatively easy to understand and manage. Some organizations have hundreds and hundreds and hundreds of rules, so it becomes very important that you're able to manage and clearly define how people can communicate through your firewall.