16.3 ACLs

Introduction

Access Control Lists, usually called ACLs, are a basic tool that control which traffic is allowed or denied through a network device, most often a router or firewall. In security, ACLs are one of the simplest ways to enforce the rules you decide for your network, for example which devices can talk to which servers, or which users can reach the internet.

In this chapter the focus is on ACLs as they are used in IP networks, not on every possible meaning of the term in computing. You will see how ACLs think about traffic, how rules are applied, and what typical mistakes to avoid.

What an ACL Does

An ACL is a list of rules that compares each packet against some conditions, then decides what to do with that packet. Each rule says something like “if the packet matches these characteristics, then permit it” or “if the packet matches these characteristics, then deny it.”

At a high level, an ACL answers a single question for every packet that passes through a device:

This “first match wins” behavior is the most important thing to understand about ACLs.

Where ACLs Are Used

ACLs appear in several places in networking devices. On routers, ACLs often filter traffic that passes between interfaces, for example between a local network and the internet. On firewalls, ACLs define which flows are allowed through different security zones. Switches can also use ACLs to limit traffic on specific ports or VLANs.

The same basic idea is used in all of these cases. There is a list of ordered rules, the rules examine packet fields like IP addresses and ports, and the device decides whether to forward or drop the traffic based on the ACL.

Matching Criteria in ACL Rules

Each ACL rule looks at some combination of fields that exist in the packet headers. Common criteria include source IP address, destination IP address, transport protocol such as TCP or UDP, and sometimes port numbers such as 80 for HTTP or 443 for HTTPS.

You can think of an ACL rule as a set of “if” conditions. For example:

If source IP is 192.168.1.10 and destination IP is 10.0.0.5 and protocol is TCP and destination port is 443, then permit.

The device compares these fields in the packet to the rule. If every field that is defined in the rule matches, then the rule matches the packet. If any defined field does not match, the device moves to the next rule in the list.

To make ACLs practical, rules usually support ranges or groups of addresses. The exact formats such as wildcards or masks belong to later configuration focused study, but the important idea is that a single ACL rule can target a single IP, a whole subnet, or any source or destination.

Ordered Processing and the First Match Principle

An ACL is not just a set of rules. It is an ordered list. The position of a rule in that list can completely change the behavior of the network.

When a packet arrives, the device starts at the top rule and works downward. As soon as it finds a rule that matches, it stops and applies that rule. It never looks at rules that are farther down the list.

Consider a simple logical table for an ACL that is attached to some interface:

If a packet comes from 10.0.0.5 and is going to 192.168.1.10, rule 1 matches first and the packet is denied. Rule 2 would have permitted it, but it is never checked because of the first match principle.

If a packet comes from 172.16.0.1 and goes to 192.168.1.10, rule 1 does not match, but rule 2 does, so the packet is permitted. Rule 3 is only applied to packets that did not match rules 1 or 2.

The order of rules is often the source of configuration mistakes. A very broad rule placed too early can “shadow” more specific rules that follow and make them ineffective.

Implicit Deny and the End of the ACL

An ACL always has a logical end. In most implementations, any packet that reaches the end of the ACL with no match is denied automatically. This behavior is often called the “implicit deny” or “deny any” at the end.

This has two important consequences. First, you must explicitly permit any traffic that should be allowed, otherwise it will be blocked when it reaches the end. Second, you need to be careful when reading ACLs, because missing permit statements can be just as dangerous as explicit deny statements.

In many designs, administrators add an explicit final rule such as “deny all” with logging. This does not change the behavior, but it gives visibility when packets fall through to the end.

Direction of ACL Application

ACLs are often applied to an interface with a direction, usually described as incoming or outgoing. The exact meaning of these terms depends on the device, but the general idea is simple. An incoming ACL filters packets as they enter an interface. An outgoing ACL filters packets as they leave an interface.

The same ACL rules can have very different practical effects depending on which direction they are attached to. For example, if you attach an incoming ACL to your local network interface, you can control what traffic from inside your network is allowed to leave. If you attach an incoming ACL to your internet facing interface, you can control what traffic from the internet is allowed to enter.

Designing where and in which direction to place ACLs is a planning decision that must consider performance, security goals, and ease of management.

Types of Network ACLs

Within network devices, ACLs are usually categorized based on which fields they examine. The most common distinction is between ACLs that only look at IP addresses and ACLs that also consider protocols and ports.

Some ACLs only examine the source or destination IP addresses, or perhaps both. These are suitable when you only care about which hosts or networks are involved, regardless of application. Other ACLs allow you to match on protocol type, such as TCP, UDP, or ICMP, and on port numbers. These are used when you want to permit or deny specific applications, for example only allowing web traffic or blocking file sharing ports.

There are also ACLs that operate at the device level outside of regular forwarding. For example, a device can have an ACL that controls who can manage it through SSH or a web interface, separate from ACLs that control traffic passing through the device. These are often called management or control plane ACLs.

ACLs and the Principle of Least Privilege

ACLs are closely related to the principle of least privilege that is central in security. This principle says that any user or system should have only the minimum access it needs to perform its role, and no more.

When you design ACLs, you usually start by defining what must be allowed. For example, maybe your web server in a DMZ only needs to accept HTTP and HTTPS from the internet and connect to a database server on a specific port. With that knowledge, you can create rules that permit exactly those flows, and then rely on the implicit deny at the end to block everything else.

Using ACLs in this way reduces the attack surface of your network. It prevents accidental access, limits the lateral movement of an attacker, and makes it easier to understand and audit who can talk to whom.

Logging and Auditing with ACLs

Many ACL implementations let you attach logging behavior to rules. When a packet matches a logged rule, the device writes an entry into a log. This log may include the rule that was matched, the source and destination, the time, and other information.

Logging is useful for both security and troubleshooting. For security, you can detect unwanted connection attempts or scanning behavior. For troubleshooting, you can see if legitimate traffic is being blocked by a deny rule or if your rules are not matching as expected.

However, logging every match on a very busy rule can overload the device or the logging system. It is usually better to log only what is necessary, for example denies for sensitive areas or permit rules during a test period.

Common Pitfalls and Misconfigurations

Several typical mistakes appear again and again when ACLs are used. One frequent problem is placing a broad permit rule too early in the ACL. As a result, that rule matches a large amount of traffic before it can ever reach the more specific deny rules below. This reduces security and may hide the fact that the denies are never actually used.

Another mistake is forgetting how the implicit deny works. If you only add deny rules for a few things you want to block and never write permit rules for what should pass, you might accidentally block everything when the traffic reaches the end of the ACL. In practice, many ACLs are written as “permit lists” where you explicitly allow what you want, then rely on the implicit deny for everything else.

Direction misunderstandings are also common. For example, an administrator adds a rule to block incoming traffic from the internet, but applies the ACL on the inside interface in the wrong direction, so it never affects the traffic it was meant to control.

Lastly, ACLs can become very long and complicated over time. Without good documentation and periodic cleanup, it becomes difficult to understand what each rule does and why it exists. This complexity itself introduces risk, because it is easier to make mistakes when modifying or extending the list.

ACLs as a Building Block in Network Security

ACLs by themselves do not provide complete security, but they form one of the basic building blocks. They are often combined with firewalls, VPNs, intrusion detection systems, and other tools.

In many environments, ACLs protect the borders between network segments, such as between user networks and server networks, or between internal networks and the internet. They can also enforce policies around special systems, for example allowing only certain IP addresses to manage routers or switches.

Because ACLs are simple and predictable once you understand their rules, they are often the first security mechanism that new network engineers learn to use. With careful planning, clear documentation, and respect for their ordered nature, ACLs become a reliable way to enforce who is allowed to communicate with whom inside your network.