Access control lists are used as packet filtering mechanisms on our enterprise networks. In this video, you’ll learn about ACLs and how they can be used to protect services on our networks.
<< Previous Video: Network Address Translation Next: Circuit Switching and Packet Switching >>
An access control list is a packet filter. It’s a way to allow or disallow traffic from blowing through a certain part of the network. You might also see access control lists used in conjunction with network address translation to be able to determine what IP addresses need to be translated. Or maybe we’re using access control lists with quality of service so we’ll know exactly what type of traffic flows need to have what type of priority.
It’s common to see ACLs configured on a router interface, and you can configure that access control list to apply to ingress traffic, egress traffic, or both. Some ACLs can be very specific. They may be examining a source IP address, destination IP address, TCP port numbers, UDP port numbers, ICMP, or anything else within that particular packet the may allow you to make a decision on whether you’re going to allow or deny that traffic. So we might define an access control list that consists of an IP address range or a series of TCP ports, and if the traffic flow happens to match that particular combination, we’ll decide to either deny or permit that traffic to flow through that router interface.
Different devices and different manufacturers’ equipment will provide different capabilities for access control lists, and as these devices become more intelligent, you’ll find that you have more options to be able to define an ACL. The rule base that’s inside of a firewall could also be considered an access control list. We’re usually using multiples of these different variables to determine if traffic is allowed or disallow through the firewall. This combination of variables is called a tuple. We may combine many different tuples together to create a very specific access control rule.
Normally, the logic of a firewall starts with the first rule, and if your traffic matches that rule, then the firewall doesn’t have to look any further down that rule base. But if it doesn’t match it, goes to the second rule to see if there’s a match there, and then to the third rule, and so on. These rules can be very specific or very general, but as a rule of thumb we usually put the most specific rules at the top of the rule base.
Most access control lists and most firewall rule bases are written with an implicit deny. This means if you’ve gone through every single rule in this access control list and none of them have matched this particular access flow, the default option is to deny this traffic going through the network. Even if you didn’t put a rule at the bottom this firewall that said all other traffic deny, most default options are to provide this denial implicitly without you having to put a specific rule in the access control list.
Let’s look through a series of access control lists that might be installed in a firewall to allow traffic to communicate to a web server. In this particular firewall, we have a number of tuples. We have the rule number, we have a remote IP address, a remote port number, a local port number, a protocol, and an action that the firewall will take. The first rule will allow all traffic from a remote IP and a remote port number that is communicating to a local port number, a port 22. This port 22 over TCP is probably for SSH traffic and the firewall is set to allow that traffic.
The second role will look for all traffic coming through from any remote IP address and any port number that may be communicating to port 80 over TCP. That’s most likely our HTTP web traffic. So we’ll certainly want to allow that through the firewall.
Rule three is the other part of the HTTP traffic, which is coming from any device communicating to port 443 over TCP, which would be HTTPS, and we certainly want to allow that to our web server.
We may be providing remote administration to this server using Microsoft’s Remote Desktop protocol. In that case, we’ll need to configure a rule in the firewall that will allow TCP port 3389 to also communicate to the server.
And on this network, our server may need to communicate outbound from the firewall, so to perform DNS lookups, we have a remote port of 53 that is allowed through the firewall, and to perform network time synchronization, we have port 123 available to pass through the firewall.
And our seventh rule is configured to deny all ICMP traffic to the server so that someone would not be able to ping the server from across the network. And, of course, if none of these rules apply, there is an implicit deny at the bottom so anything not matching these specific rules would automatically be dropped at the bottom of this access control list.