Make a deny rule fail by its position, then rate-limit a flood

short · 45 min · Objective 4.1

Task

Write a rule set where a specific deny sits below a broad permit, prove from the counters that the deny never fires, then reorder and prove that it does. Then add a rate limit in front of a second service and watch it refuse a burst of perfectly ordinary requests that no allow or deny rule could tell apart.

Steps

  1. On the Linux VM start two test services, python3 -m http.server 8080 and python3 -m http.server 8081, and confirm the other lab VM can fetch a page from both.
  2. Add rules in the WRONG order: first a broad permit, sudo iptables -A INPUT -s 10.99.0.0/24 -j ACCEPT, then a specific deny, sudo iptables -A INPUT -p tcp --dport 8080 -s 10.99.0.20 -j REJECT.
  3. Fetch port 8080 from the other VM and record that it still succeeds with the deny rule present.
  4. Read the counters with sudo iptables -L INPUT -v -n --line-numbers and note that the deny rule's packet count is zero: it has never matched anything.
  5. Reorder: delete the deny (-D with the same specification) and insert it at the top with sudo iptables -I INPUT 1 -p tcp --dport 8080 -s 10.99.0.20 -j REJECT. Fetch again, confirm it is refused, and confirm the counter is now non-zero. Write both counter readings into /tmp/ruleorder.md.
  6. Now the flood a rule cannot see. Insert a rate limit for new connections to port 8081 above the broad permit: sudo iptables -I INPUT 1 -p tcp --dport 8081 --syn -m hashlimit --hashlimit-name lab --hashlimit-mode srcip --hashlimit-above 10/minute -j REJECT.
  7. From the Windows guest send thirty requests to port 8081 in a quick loop -- a PowerShell loop around Invoke-WebRequest with a short timeout does it -- and count how many succeed. Record the count in /tmp/ruleorder.md, with a sentence on why the same thirty requests spread across thirty source addresses would pass this per-address limit, and what limiting per account would change on a real login page.

Verify

sudo iptables -L INPUT -v -n --line-numbers
sudo iptables -L INPUT -v -n | awk '$3=="REJECT" && /dpt:8080/ {print $1" packets matched the deny rule"}'
sudo iptables -L INPUT -v -n | awk '/limit: above/ {print $1" packets refused by the rate limit"}'
grep -ciE "distributed|per.account|many addresses|thirty" /tmp/ruleorder.md

The counters are the verification, which is why this lab does not rely on a connection test alone. The deny rule must now show a non-zero count; before you moved it, the same rule read zero, which tells you the problem was order rather than syntax. The rate-limit rule must also be non-zero: those packets were well-formed requests to a service the rule base permits, refused only because there were too many of them from one address.

Notes

Reading rule counters is the fastest firewall diagnostic there is, and almost nobody does it. A rule that looks right and has never matched is either unreachable behind an earlier rule or written for traffic that does not exist, and the counter tells the two apart in one command. The rate limit shows the other half of the lesson: some attacks are nothing but allowed traffic, in volume, and only a control that counts can see them.

This is an independent study companion for CompTIA Security+ SY0-801 and is not produced by or endorsed by CompTIA.