We often use rules to allow or prevent access to important resources. In this video, you’ll learn about access control lists, firewall rules, content filtering, screened subnets, and security zones.
One common way to limit the type of traffic that can traverse the network is by using an ACL, or an access control list. This is a generic term that describes a list of traffic that is allowed and traffic that is disallowed. It’s often grouped with different categories so that you can create very complex combinations. For example, you might want to use source IP address, destination IP address, a port number, a time of day, or an application, and combine all of those together to create a rule where traffic may be allowed or disallowed.
ACLs can also refer to a group of these criteria. For example, you can have a group of IP addresses, and some of those IP addresses would be allowed access to the system and another group of IP addresses would be denied. Access control lists can be found on many different devices, including routers, firewalls, operating systems and anything that needs to make a decision about access.
The security policies we often see in a firewall are a very complex form of an access control list. This access control list or a set of security policies includes the name of the rule, a source and destination zone, a source and destination address, a destination port, a username, and so on. As you can see from this console, you can make some very specific and very fine-grained security controls using the security policy list.
Most firewall rules are interpreted by starting with the first rule number and working down through the list until it finds a match. This top-to-bottom approach is very common on most firewalls that you’ll run into. This can be a very specific set of rules or they may be very generalized. We tend to put the more specific rules on the top of this list, so they’ll be matched first before it ever gets to the more general rules.
And with most firewalls, if you get all the way through the rule base and none of those rules are matching the data that’s flowing through the firewall, that data is automatically denied. We refer to this as an implicit deny. Although there is not a specific rule denying that traffic, the lack of any other rule matching that traffic means that we implicitly deny that traffic. In this rule set, there is an implicit deny at the bottom. You can imagine a rule eight at the bottom of this firewall rule set that denies all other traffic that didn’t match any of the rules from rule number one through seven.
Let’s step through this firewall rule set and see what each line is providing us for security. Rule number one allows any IP address from any port number to connect to port number 22 on this particular device over protocol TCP. You can see the Allow action is the disposition at the end of this particular rule. Port 22 is commonly associated with SSH, so this would allow anyone to connect to this device over that SSH port.
Rule two is a similar rule to port one. It has a remote IP of All and a remote port number of Any, so anyone can connect to this device over local port number 80 running the TCP protocol. We know that port 80 is commonly used for web traffic, and all of that traffic would be allowed. Well, if we’re allowing port 80 for our web server, then we’re probably also going to allow port 443. And the next rule in the rule set is port 443, and it is allowed to this service.
Port four allows any remote IP and port number to connect to TCP port 3389 on this device. All of these are allowed. And, of course, port 3389 is commonly associated with the Microsoft Remote Desktop Protocol, or RDP. This server must also make DNS requests, because in rule five, we’re able to connect to any remote IP address over port 53 from any local port on this device using UDP. You can see that action is indeed to allow that traffic.
And very similarly, we have rule six where we can connect to any remote IP address using port 123 over UDP from any local port that is allowed traffic. At port 123, of course, would be the network time protocol, or NTP. And then lastly, our network administrator has decided not to allow someone to ping this device or use any other aspect of the Internet Control Management Protocol, or ICMP. This is rule seven. And it says that any remote IP address using ICMP is denied.
Being able to filter traffic based on an IP address or port number is important, but it’s only part of the security posture that we might want to present. There are other ways to filter traffic, one of these is through URL filtering. This allows you to specify either a specific uniform resource locator, URL, or you can specify a category of URL. Sometimes you’ll see this referred to as a uniform resource identifier, or URI. And often, this is put into an Allow list or a Block list for an organization.
We could, of course, specify individual URLs that people are able to visit, but we might have to put 100 or even thousands of URLs in a database to be able to make that happen. It’s much easier if we could roll all of those URLs up into a very broad category, and that’s what most URL filtering devices will do. They might allow you to allow or disallow access to auction sites, hacking sites, travel sites, recreation sites, and many other categories.
Users often try to find ways around URL filtering or find different ways to access those websites without having to go through this filter. For that reason, we often combine URL filtering with a firewall rule set so that we can prevent any type of circumvention of our security rules. And most next generation firewalls have URL filtering already built into the software, so you can simply enable or disable these categories and include them in an existing firewall rule.
URL filtering is a type of content filtering. We are choosing what content inside of the data is allowed or disallowed through the network. But other types of data may be used for content filtering as well. We might have internal documents inside of our company that we don’t want to get out, or there might be financial details. We might have content filtering software or hardware that is looking for that data. And if it finds any of that data inside of our network traffic, it can allow or prevent that traffic from traversing the network.
Some organizations will use content filtering to prevent any nonsafe for work type content being shown on the screen, or you might use it at home for your parental controls. And one of the most common types of content filtering are built into our antivirus and antimalware software. We’re looking for malicious software being transferred across the network, and this software will filter any of that bad content.
One of the challenges we have is making services available to the public over our network, but we don’t want that public to have access to our internal network. One of the ways we can accomplish this is through the use of a screened subnet. This allows us to create a separate area of the network that is specifically designed for visitors to our network.
This allows them to access services that we’d like to make public, such as public web servers or public email servers. But all of that traffic is going to this separate screened subnet. We still have our internal network, and anybody on that network can communicate out to the internet. But anyone who needs to visit our web server will be directed to the screen subnet and away from our internal services.
On the firewall console we saw earlier, you might have noticed that there were zones referenced as part of the firewall rule. These zones can be used to create very broad references inside of our firewall rules. Instead of using an IP address range, you can simply use a security zone. You would first need to separate the network into different zones. There might be two zones on your network; a trusted zone and an untrusted zone. Or, you might have an internal zone and an external zone.
And if you wanted to have additional zones for additional granularity, you might have an inside zone, an internet zone, a server zone, a databases zone, and a screen subnet zone. This allows us to simplify all of these security policies that we’re building inside of our firewall, so we can create one rule that says, if you’re on the trusted zone, you can communicate to the untrusted zone. You don’t have to add any IP addresses. There’s no port numbers. There’s no specific applications. You’re simply saying that all traffic in one part of the network is able to communicate to a different part of the network.
The same thing might apply from the internet or from the untrusted zone, you may allow that traffic to visit your screened subnet. Or, perhaps, you’d like to prevent anyone from an untrusted part of the network from being able to communicate to the trusted part of the network. And we could create a firewall rule that denies that traffic based on those two zones.
Visually, we can overlay some zones onto our existing network design. We have an internet connection coming into a firewall. There’s a router with another firewall. That firewall takes some traffic and sends it over to honey pots, and the rest of that traffic is sent inside to our normal network.
We can overlay some security zones on top of this. For example, we can make a security zone where the internet is first connecting to our firewall, and then everything else on the network can be another security zone. We can then name these zones. One of them might be the untrusted zone, which is where the internet lives, and the other would be the trusted zone, which is the inside of our network.
If you need more granularity with your firewall rules, you could break this into other zones. For example, we can have an internet zone at the top. You might have a screen subnet, where people are connecting, and then there may be an internal network that is separated by a separate firewall. If you’d like to have more control over the firewall rules and you’d like more granularity, you might want to add more security zones to your zone-based firewall.