3.5 Controlling the Traffic: Firewalls and Filtering

Every network needs a way to decide who gets in, who gets out, and what kind of traffic is allowed to move around. That's the job of firewalls and filtering. In this topic, you'll see how MAC filtering locks down physical access at the switch level, and how firewall rules (organized into access control lists) decide which packets are permitted or denied as they travel across network segments. These tools are the front line against both accidental misuse and intentional attacks.

MAC Filtering and Switch Port Security

Every network device has a MAC address, a unique hardware identifier burned into its network card. MAC filtering uses those addresses to control which devices are allowed to connect. The idea is simple: the switch keeps a list of approved MAC addresses, and only those devices get access. Every other address is refused.

You can apply MAC filtering at the level of an individual switch port. A port can be configured to accept just one specific MAC address, or a small, limited group of them. Anything else that tries to plug in gets blocked. This matters because networks aren't only attacked over the internet. Someone could walk into a building and physically plug a rogue laptop into a wall jack. By capping both the number of MAC addresses allowed on a port and the range of which addresses are valid, you stop unauthorized devices from gaining physical access to the network.

How MAC Filtering Stops MAC Flooding

MAC filtering also defends against a specific attack called MAC flooding. To understand it, you need to know about the switch's CAM table (Content Addressable Memory table). This table is basically the switch's memory of which MAC addresses live on which ports. When the switch gets a frame, it checks the CAM table to figure out where to send it.

In a MAC flooding attack, an attacker sends a huge number of frames with different fake MAC addresses. The switch tries to record each one in the CAM table, but the table has limited memory. Once it's full, the switch can get pushed into a fail-open state. In this state, the switch stops making smart forwarding decisions. Instead, it broadcasts every bit of traffic out to every node on the network, kind of like a hub.

Two bad things happen:

• The network gets congested because every packet is going everywhere
• An attacker can now intercept data that was meant for other devices, since it's all being broadcast

MAC filtering helps prevent this because the switch only accepts a limited group of approved MAC addresses on each port. The flood of fake addresses gets refused before it can ever fill the CAM table.

Firewalls and Access Control Lists

A firewall is a device or software that decides which network traffic is allowed through. It works using rules, and those rules apply to both inbound (incoming) and outbound (outgoing) traffic. The full ordered list of rules that a firewall uses is called an access control list, or ACL.

How ACLs Are Evaluated

Here's the part that trips a lot of students up. An ACL is evaluated sequentially, from top to bottom. For any given piece of data, the firewall checks rule 1, then rule 2, then rule 3, and so on. The first rule whose criteria match the traffic is the one that gets carried out. Every rule after that is ignored for that particular packet.

That's why rule order matters so much. Rearranging the rules can completely change what traffic gets permitted or blocked, even if the rules themselves don't change.

What's in a Firewall Rule

A typical ACL entry has three main parts:

1. Direction: Whether the rule applies to inbound or outbound traffic on an interface
2. Filtering criterion: What the firewall looks at to decide if the rule matches. This can be an IP address, a logical port number, a service, or an application. Different firewalls support different criteria.
3. Action: What to do if the rule matches, either permit or deny

Common Ports and Services You Need to Know

Firewall rules often filter based on port numbers, since each port is tied to a specific service. These are the common, secure services you'll see permitted in ACLs:

• HTTPS on port 443: encrypted web traffic
• DNS on port 53: translates domain names (like fiveable.me) into IP addresses
• SSH on port 22: encrypted remote command-line (CLI) access to a device
• SFTP on port 22: secure file transfer that runs over SSH

And these are the vulnerable versions you usually want to block, because they send data without encryption:

• HTTP on port 80: unencrypted web traffic
• Telnet on port 23: unencrypted remote CLI access
• FTP on port 21: unencrypted file transfers

The pattern is pretty consistent: if a service has an encrypted version, block the unencrypted one whenever possible.

Building a Smart ACL

A good ACL reduces the chance of malicious traffic getting through. The general approach: shut down ports that are unused or vulnerable, and give priority to the services that are actually needed.

Here's a sample rule set that keeps needed services open and closes vulnerable ones. Imagine these are all inbound rules on the firewall's external interface:

</>Code
Rule 101: permit TCP, port 443, any source   (HTTPS allowed)
Rule 102: permit TCP, port 22,  any source   (SSH allowed)
Rule 103: deny   TCP, port 80,  any source   (HTTP blocked)
Rule 104: deny   TCP, port 23,  any source   (Telnet blocked)
Rule 105: permit UDP, port 53,  any source   (DNS allowed)

Walk through it: HTTPS and SSH get in because the network needs secure web and secure remote access. HTTP and Telnet get blocked because they're unencrypted. DNS is allowed because name resolution has to work.

Why Rule Order Is Everything

Specific rules go before broad, general ones. If you flip them, the general rule will match first and the specific rule will never get a chance to run.

Here's a second sample rule set that makes this super clear:

</>Code
Rule 101: permit TCP, port 22, any source     (SSH allowed)
Rule 102: deny   TCP, any port, any source    (block all other TCP)

In this order, SSH traffic hits rule 101 first and gets permitted. Everything else falls through to rule 102 and gets denied. That's exactly what you want.

Now swap them:

</>Code
Rule 101: deny   TCP, any port, any source    (block all TCP)
Rule 102: permit TCP, port 22, any source     (SSH allowed)

Now every TCP packet, including SSH on port 22, matches rule 101 first and gets blocked. Rule 102 is never reached. SSH is dead. Same two rules, different order, totally different outcome.

This is the single most important thing to remember about ACLs: first match wins, so specific rules go on top and broad rules go on the bottom.

Testing Your Firewall Rules

Once the rules are set up, you can't just assume they work. You need to verify two things:

• Intended access works: The services that are supposed to be reachable actually are reachable
• Unauthorized access is blocked: The services that are supposed to be closed stay closed

A common way to test is with the ping command. You can ping devices on other network segments to confirm connectivity, and you can try to access network resources (like opening an SSH session or loading a web page) to confirm that the permitted services keep working. If something that should be allowed gets blocked, or something that should be blocked gets through, the rule order or criteria need another look.

Filtering priorities matter here too. If two services compete (like needing SSH open but wanting to block everything else inbound), you have to decide which rule goes first based on what the network actually needs. The goal is always the same: let through what's needed, block what's vulnerable or unauthorized, and keep the order tight so the firewall does what you expect.