Lesson 3.18: Egress filtering and blocklists
Inbound rules keep attackers out; outbound rules decide what a compromised server can do next: reach its C2, download tools, send data away. Most servers need very few outbound destinations, so a default-deny output chain is realistic and powerful. In the lab you block the indicators from section 1 with an nftables set (instantly, without reloading), make the change survive a reboot, then switch web03's outbound traffic to default deny with an allow-list, and verify both what still works and what no longer does.
17 min
You will learn to
- Explain why egress filtering matters
- Use nftables sets for blocklists
- Persist runtime changes
- Write a default-deny output chain
- Verify allowed and denied paths
Key terms
- Egress filtering
- Controlling which outbound connections are allowed.
- Allow-list
- Only listed destinations are permitted; everything else is denied.
- Blocklist
- Listed destinations are denied; everything else follows the policy.
- nftables set
- A named collection of addresses or ports referenced by rules as @name; elements change without reloading.
- reject vs drop
- reject sends an error back so the sender fails fast; drop stays silent.
- Persistence (of rules)
- Saving the live ruleset so it's loaded again at boot.
← Private addresses, NAT and port forwarding · All lessons · Fewer services, smaller attack surface →