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 firewall

  • python3 — 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