Firewall rules don’t just block traffic; they actively shape the network conversation by deciding who gets to speak, who has to be quiet, and who is simply ignored.
Let’s watch a packet get processed. Imagine a firewall with these rules:
1. ALLOW tcp from 192.168.1.10 to any port 80
2. DENY tcp from any to 10.0.0.5 port 22
3. DROP udp from any to any port 53
A TCP packet arrives destined for 192.168.1.50 on port 80, originating from 192.168.1.10.
- Rule 1 matches:
tcpfrom192.168.1.10toany(which192.168.1.50is) onport 80. The packet isALLOWed. Processing stops.
Now, a TCP packet from 192.168.1.10 arrives for 10.0.0.5 on port 22.
- Rule 1 does not match.
- Rule 2 matches:
tcpfromany(which192.168.1.10is) to10.0.0.5onport 22. The packet isDENYed. The firewall sends back a TCP RST (reset) packet to the sender, indicating the connection is refused. Processing stops.
Finally, a UDP packet from 192.168.1.10 arrives for 192.168.1.50 on port 53.
- Rule 1 does not match.
- Rule 2 does not match.
- Rule 3 matches:
udpfromany(which192.168.1.10is) toany(which192.168.1.50is) onport 53. The packet isDROPped. The firewall silently discards the packet. No response is sent back to the sender. Processing stops.
If none of the rules matched, the firewall would typically hit a default policy, often DENY or DROP for security.
The core problem firewalls solve is controlling network access – who can talk to whom, and about what. This is crucial for security, preventing unauthorized access to sensitive systems, and for network management, ensuring critical services have the bandwidth they need. The logic ALLOW, DENY, and DROP provides distinct ways to enforce these controls. ALLOW explicitly permits traffic. DENY explicitly forbids traffic and signals the refusal to the sender, which is useful for preventing scans or quickly closing connections. DROP silently discards traffic, making it harder for attackers to map out your network by preventing them from receiving any feedback.
The order of rules is paramount. Firewalls process rules sequentially from top to bottom. The first rule that matches a packet determines its fate. This allows for very specific exceptions to broader policies. For instance, you might have a general DENY rule for all SSH traffic, but a specific ALLOW rule before it for your administrator’s IP address.
What most people don’t grasp is that DENY and DROP are not interchangeable from an attacker’s perspective. A DENY rule, which usually results in a TCP RST or ICMP Port Unreachable, tells the sender "I see you, and I’m not letting you connect." This can be useful for actively rejecting unwanted connections. A DROP rule, however, is like the packet vanished into a black hole. The sender gets no response and typically times out. This silence is often preferred for blocking traffic from the internet because it doesn’t reveal the presence of your firewall or its internal IP addresses. It makes your network appear non-existent to probes.
Understanding the nuances between DENY and DROP is key to both securing your network and understanding how others might probe it.
The next logical step is to explore stateful inspection, where the firewall tracks active connections.