Lab 14: Firewalls and IDS
🎯 Objective
Understand firewall rule logic, compare IDS/IPS/Firewall/WAF capabilities, analyze Snort rule syntax, and build a mental model of layered network defense architecture.
📚 Background
Firewalls are the foundational network security control — they inspect network traffic and permit or deny it based on rules. Traditional stateless firewalls filter based on IP addresses and ports alone. Stateful firewalls track connection state, while next-generation firewalls (NGFW) inspect application layer content, user identity, and threat intelligence.
Intrusion Detection Systems (IDS) monitor network or host activity for malicious patterns and generate alerts. Unlike firewalls, they don't block traffic by default — they observe and report. Intrusion Prevention Systems (IPS) take the next step, automatically blocking detected threats inline. Web Application Firewalls (WAF) specifically protect HTTP/HTTPS applications from application-layer attacks like SQL injection and XSS.
The key insight is that each security control has a different vantage point and capability. A network firewall doesn't understand HTTP session semantics. A WAF understands HTTP but not network-level attacks. An IDS understands both but generates alerts rather than blocks. Layering these controls creates defense-in-depth for network security.
⏱️ Estimated Time
40 minutes
📋 Prerequisites
Lab 08: Common Attack Vectors
Basic TCP/IP networking
🛠️ Tools Used
iptables— Linux firewallpython3— firewall logic simulation
🔬 Lab Instructions
Step 1: View Current Firewall Rules
📸 Verified Output:
💡 What this means: Default policy ACCEPT means all traffic is allowed unless a rule explicitly blocks it. This is the "default allow" model. Production firewalls should use "default deny" (DROP policy) and explicitly allow only needed traffic.
Step 2: Understanding Firewall Rule Processing
📸 Verified Output:
💡 What this means: Firewall rules are evaluated top-down. Order matters critically — if "ACCEPT all" appeared before "DROP mysql," the database would be exposed. Always put specific rules before broad ones, and end with "DROP all."
Step 3: IDS vs IPS vs Firewall vs WAF Comparison
📸 Verified Output:
💡 What this means: Layer your security controls. A firewall blocks unauthorized connections; a WAF inspects the HTTP content within those connections; an IDS/IPS detects attack patterns within allowed traffic. No single control covers everything.
Step 4: Snort Rule Syntax
📸 Verified Output:
💡 What this means: Snort rules combine protocol awareness (IP, TCP, UDP) with content matching. The content options can match strings in payloads, making them effective against known attack patterns. Modern variants like Suricata support multi-threading and additional protocols.
Step 5: Defense Architecture Diagram
📸 Verified Output:
💡 What this means: The DMZ (Demilitarized Zone) isolates internet-facing servers from the internal network. Even if an attacker compromises a web server in the DMZ, they face another firewall before reaching internal systems.
Step 6: Common Firewall Rules for a Web Server
📸 Verified Output:
💡 What this means: "Default deny" is the gold standard. Start with DROP all, then explicitly allow what's needed. This is fundamentally safer than "default allow + block bad things" — you can't block every possible threat, but you can enumerate what's legitimate.
Step 7: WAF Rule Examples and Evasion
📸 Verified Output:
💡 What this means: Simple WAF pattern matching is bypassed by attackers using URL encoding, case variation, or comment injection. This is why WAFs need multiple detection layers and regular rule updates. A WAF alone is not enough — fix the underlying vulnerability too.
Step 8: Testing Firewall Rules
📸 Verified Output:
💡 What this means: Only SSH is open (for admin access in this container). HTTP/HTTPS/MySQL are not running — minimal attack surface. In production, regularly verify your firewall rules match your intended policy using connection testing and port scanning.
✅ Verification
🚨 Common Mistakes
Default ALLOW policy: Always start with default DROP and explicitly allow needed traffic
Allowing SSH from anywhere: Restrict SSH to admin IP ranges or VPN — internet-exposed SSH invites brute force
WAF as sole defense: WAF is one layer; fix underlying vulnerabilities too
No logging: Without logging, you can't detect attacks or investigate incidents
Not testing rules: Apply rules in test environment first; a misconfigured firewall can lock you out
📝 Summary
Firewalls filter traffic based on IP/port (stateless) or connection state (stateful); NGFWs add application awareness
Default deny policy is the gold standard — whitelist what's allowed rather than blacklisting threats
IDS detects, IPS blocks: IDS is passive (alerts); IPS is inline (actively blocks matched traffic)
WAF inspects HTTP application layer specifically — essential for protecting web applications from SQLi, XSS, etc.
Layered architecture (DMZ + internal segmentation + WAF + IDS) means an attacker must defeat multiple independent controls
🔗 Further Reading
Last updated
