Firewalls and access control lists

With the bakery's zones drawn on paper, the next job was to decide what traffic each zone could send to the others. Dev Anand set Jordan an exercise before letting him near the real firewall: write the rules in plain sentences first, one rule per line, starting with "allow" or "deny". Jordan's first draft had 31 lines. Dev crossed out a third of them, merged others, and added one line at the bottom that Jordan had forgotten: deny everything else. "That last line is the most important rule you will ever write," Dev said. "Everything above it is an exception."

A firewall is a device or program that controls network traffic according to rules. An access control list, or ACL, is an ordered list of those rules. This lesson explains the kinds of firewall, how rules are evaluated, how Cisco devices express ACLs, where to place filters, and how to keep a rule set clean. The exam expects you to read a short rule list and work out what it will do to a given packet.

Kinds of firewall

A packet-filtering firewall examines each packet on its own and decides based on information in its headers: source and destination IP addresses, the protocol such as TCP, UDP or ICMP, and source and destination port numbers. It is fast and simple, but it has no memory. It cannot tell whether an incoming packet is a reply to something a user inside asked for, so rules must be written to allow replies explicitly, which tends to open more than intended. Router ACLs are the most common example of stateless packet filtering.

A stateful firewall keeps a table of active connections. When a user inside opens a connection to a website, the firewall records it, and it allows the website's replies back in because they belong to a known connection. Unsolicited packets from outside that match no connection are dropped. This makes rules simpler and safer: you write rules for who may start a connection, and replies are handled automatically. Almost every modern firewall, including the ones in small office appliances, is stateful.

An application-layer firewall, or proxy firewall, understands specific protocols such as HTTP and can inspect the content of requests, not just their headers. A next-generation firewall combines stateful filtering with application identification, so that a rule can say "allow the accounting application, block file-sharing applications" regardless of the port they use, and adds user identity, intrusion prevention and often web filtering. A web application firewall sits in front of a web application and inspects requests for attacks such as injection. A host-based firewall runs on an individual computer, such as the firewalls built into Windows, macOS and Linux, and protects that one device wherever it is.

How rules are evaluated

Rule lists are processed from the top down, and the first rule that matches a packet decides what happens to it. Later rules are never checked for that packet. This simple principle has two consequences. First, order matters: a broad "allow" near the top can make a careful "deny" further down useless, because packets never reach it. Specific rules usually go above general ones. Second, every list needs a decision for packets that match nothing. On Cisco devices and most firewalls, that decision is an implicit deny at the end of the list: anything not explicitly allowed is dropped.

The principle of default deny, sometimes called deny by default or an allow list approach, says that traffic should be blocked unless there is a known reason to allow it. The opposite approach, allow everything and block known bad things, is easier at first and fails badly, because attackers simply use something that has not been blocked yet. Dev's crossed-out draft reflected this: many of Jordan's lines were denies for things that the final deny-everything rule already covered.

rules = [  # (action, source zone, destination zone, port)
    ("allow", "pos",   "processor", 443),
    ("allow", "staff", "internet",  443),
    ("allow", "staff", "internet",  80),
    ("deny",  "guest", "staff",     None),
    ("allow", "guest", "internet",  443),
]
def decide(src, dst, port):
    for n, (act, s, d, p) in enumerate(rules, 1):
        if s == src and d == dst and p in (None, port):
            return f"{act} (rule {n})"
    return "deny (implicit)"
for pkt in [("pos", "processor", 443), ("guest", "staff", 445),
            ("guest", "internet", 443), ("pos", "internet", 443)]:
    print(pkt, "->", decide(*pkt))

('pos', 'processor', 443) -> allow (rule 1)
('guest', 'staff', 445) -> deny (rule 4)
('guest', 'internet', 443) -> allow (rule 5)
('pos', 'internet', 443) -> deny (implicit)

The program simulates first-match processing for a few of the bakery's planned rules. The last packet, a point-of-sale terminal trying to reach an arbitrary website, matches no rule and is dropped by the implicit deny. That is exactly the behaviour the bakery wants: card terminals should talk to the payment processor and nothing else.

Cisco access control lists

Cisco routers and switches use ACLs to filter traffic on interfaces. A standard ACL matches only the source IP address. An extended ACL can match source and destination addresses, protocol, and source and destination ports. ACLs can be identified by number or, more readably, by name. Each ACL is applied to an interface in one direction: inbound, for packets arriving on that interface, or outbound, for packets leaving it. Only one ACL per interface, per direction and per protocol is allowed.

Cisco ACLs describe address ranges with a wildcard mask rather than a subnet mask. A wildcard mask is the inverse of a subnet mask: a 0 bit means the address bit must match, and a 1 bit means it does not matter. To match the subnet 10.20.20.0 with subnet mask 255.255.255.0, the wildcard is 0.0.0.255. A quick way to find it is to subtract each octet of the subnet mask from 255. The keyword host matches a single address, the same as a wildcard of 0.0.0.0, and any matches every address.

ip access-list extended POS-OUT
 remark Card terminals may reach only the payment processor over HTTPS
 permit tcp 10.20.20.0 0.0.0.255 host 203.0.113.10 eq 443
 deny   ip  10.20.20.0 0.0.0.255 any log
!
interface GigabitEthernet0/1.20
 ip access-group POS-OUT in

Reading the example: the first line allows TCP from any address in 10.20.20.0/24 to the single host 203.0.113.10, the payment processor, on port 443. The second line denies everything else from that subnet and logs it. Even without the explicit deny, the implicit deny would drop the traffic, but writing it with the log keyword makes blocked attempts visible, which helps troubleshooting and detection. The remark line documents the purpose, which Marisol would approve of.

Host-based firewalls

The firewalls built into Windows, macOS and Linux are often overlooked. On a laptop that travels, they are the only firewall that is always present. Brightline's standard laptop build turns the host firewall on for every network profile, blocks inbound connections by default, and allows only the management agent's traffic from Brightline's tools. A common support mistake is to turn the host firewall off to fix an application problem and forget to turn it back on. The better fix is a specific rule for the application, with a ticket explaining why.

Where to place filters

Cisco's traditional guidance is to place extended ACLs as close as possible to the source of the traffic being filtered, so that unwanted packets are dropped before they cross the network, and to place standard ACLs as close as possible to the destination, because a standard ACL matches only the source address and placing it near the source could block that source from reaching everything. On a zone-based firewall, the question becomes which zone pair the rule belongs to, and the rule is written for traffic from one zone to another.

Placement also includes the internet edge. Inbound rules at the edge should deny traffic that claims to come from addresses that should never appear on the internet, such as the organization's own internal ranges and private address ranges, which blocks a class of spoofing. Outbound rules matter too. Egress filtering, limiting what internal devices may send out, makes it harder for malware to contact its controllers or send stolen data, and stops the bakery's thermostat from being used to attack someone else.

Keeping rule sets healthy

Firewall rule sets tend to grow. Each new request adds a rule, and nobody wants to remove an old one in case something breaks. Over time the list fills with rules that are too broad, rules for servers that no longer exist, and rules that duplicate or shadow each other. A shadowed rule is one that can never match because an earlier rule already catches every packet it would match. Overly broad rules, such as allowing any source to reach any destination on any port, are the most dangerous, because they undo segmentation entirely.

Good practice includes a change process with a ticket for every rule, a stated business reason and an owner; a remark or description on each rule; least privilege, allowing only the specific source, destination and port needed; a regular review, often every six or twelve months, to remove rules that are no longer needed; logging of denied traffic and of important allowed traffic; and backups of the configuration. Brightline's plan for the bakery includes a rule review in March 2027, three months after the new zones go live, to remove temporary rules added during the cutover.