Firewall (computing) Study Guide

📖 Core Concepts Firewall – a security system that monitors and controls traffic between a trusted (internal) network and an untrusted (external) network according to configurable rules. Deployment models – Network‑based: protects whole network segments; can be software, hardware, or virtual appliances. Host‑based: runs as a daemon/agent on a single device and filters its local traffic. Types of firewalls – Packet‑filtering: inspects each packet’s IP address, port, and protocol against an ACL; default action is silently discard. Circuit‑level (stateful) gateways: track the state of a TCP/UDP “conversation” and allow packets that belong to an established session. Application‑layer: understands specific application protocols (HTTP, DNS, FTP) and can filter based on application‑level data. Next‑generation: adds deep‑packet inspection, web filtering, IPS, user‑identity, TLS inspection, etc. Firewall policies & rules – each rule defines: Direction (inbound/outbound) Source (IP, range, zone, or user) Destination (IP, range, zone) Port / service (e.g., 80 = HTTP) Transport protocol (TCP, UDP, ICMP) Optional application‑layer criteria Action (allow, deny, drop, inspect) Zones – logical groups of devices with a common trust level (LAN, WAN, DMZ, Public, Private, etc.). Rules are typically written per‑zone rather than per‑IP. Rule evaluation – firewall scans rules top‑to‑bottom; the first matching rule decides the fate of the packet. Configuration & management – includes careful documentation, change‑control, ongoing verification/testing, and monitoring for drift. --- 📌 Must Remember Default packet‑filtering action = discard (silent drop unless a reset/ICMP response is configured). Stateful firewalls remember the conversation (source IP + port ↔ destination IP + port). Rule order matters – first match wins; a later “allow” never overrides an earlier “deny”. Typical default zone rule: allow all LAN → WAN, drop all WAN → LAN. Service identification = port + protocol (e.g., HTTP = TCP 80, HTTPS = TCP 443). User‑ID integration maps AD/LDAP usernames to IPs so rules can be written for users instead of just addresses. Pinhole = temporary, narrowly scoped rule that expires after a set time or event. Distributed firewall = firewall policy enforced on every host, not just at a perimeter. --- 🔄 Key Processes | Process | Steps (concise) | |---|---| | Rule Definition & Ordering | 1. Identify traffic to control (direction, source, destination, service). 2. Write rule with explicit action. 3. Place rule above any broader catch‑all rule that could override it. | | Verification & Testing | 1. Generate test traffic covering each rule scenario. 2. Confirm that packets are allowed/blocked as intended. 3. Use logs or a packet capture to validate state tracking. | | Change Management | 1. Propose rule change → review. 2. Document purpose, affected zones, and rollback plan. 3. Apply change in a maintenance window. 4. Update documentation & re‑run verification tests. | | Deploying a New Zone | 1. Define zone purpose and trust level. 2. Assign interfaces/IP ranges to the zone. 3. Create baseline allow/deny rules (usually deny inbound, allow outbound). 4. Test inter‑zone traffic. | --- 🔍 Key Comparisons Packet‑filtering vs. Circuit‑level Packet‑filtering: checks each packet individually; no memory of prior packets. Circuit‑level: tracks session state; allows only packets that belong to an established connection. Network‑based vs. Host‑based Network‑based: protects entire segments; sits at routers/switches. Host‑based: protects a single device; runs as an OS service. Application‑layer vs. Next‑generation Application‑layer: understands specific protocols (HTTP, DNS). Next‑gen: adds deep packet inspection, IPS, user‑ID, TLS decryption, web filtering, etc. Zone vs. IP‑address rule Zone: groups many IPs under a logical label → easier policy management. IP rule: precise but can become unwieldy in large networks. Static rule vs. Pinhole Static rule: permanent, part of baseline policy. Pinhole: temporary, time‑limited, often used for troubleshooting or short‑term services. --- ⚠️ Common Misunderstandings “Firewalls block all inbound traffic.” Only the default action is to block; explicit allow rules (e.g., for a web server in a DMZ) are required. “Packet‑filtering inspects payload.” It only looks at header fields (IP, ports, protocol). Payload inspection needs an application‑layer or NGFW. “Stateful means “allow everything once a connection is opened.” The firewall still checks that each packet matches the stored state; malformed or out‑of‑order packets are dropped. “User‑ID replaces IP‑based rules.” It augments them; most policies still need IP/zone context for devices that cannot be mapped to users. “DMZ is a firewall.” DMZ is a network segment; a firewall enforces the rules that isolate the DMZ from internal LAN. --- 🧠 Mental Models / Intuition Security Guard Analogy – the firewall is a guard standing at a door, checking ID (IP), purpose (port/service), and behavior (state) before letting someone in or out. Layered Onion – think of zones as onion layers: the inner core (trusted LAN) is surrounded by DMZ, then WAN. Traffic must pass through each layer’s rules. First‑Match Highway – rules are like highway toll booths in a line; the first booth that recognizes your car (packet) decides whether you can continue. --- 🚩 Exceptions & Edge Cases Default “allow LAN → WAN” can be overridden by a more specific deny rule placed higher. Encrypted traffic (TLS) may bypass application‑layer inspection unless the firewall performs TLS decryption. Distributed firewall policies must be synchronized; a missed host leaves a security gap. Pinhole rules automatically expire; forgetting to remove them can leave an unintended opening. User‑ID mapping fails for devices that don’t authenticate (e.g., IoT), forcing fallback to IP‑based rules. --- 📍 When to Use Which | Situation | Recommended Firewall Type / Feature | |---|---| | High‑throughput core network with simple allow/deny needs | Packet‑filtering (fast, low overhead) | | Need to allow only established sessions (e.g., remote access) | Circuit‑level (stateful) gateway | | Must filter based on application commands (e.g., block specific FTP commands) | Application‑layer firewall | | Protecting against malware, zero‑day exploits, and need user‑based policies | Next‑generation firewall with IPS, User‑ID, TLS inspection | | Securing a single laptop or server on a public Wi‑Fi | Host‑based firewall | | Enforcing a uniform policy across many servers, containers, and VMs | Distributed firewall | | Isolating public‑facing services (web, mail) from internal network | Place services in a DMZ and use zone‑based rules | | Temporary service (e.g., a one‑time file transfer) | Create a pinhole with a tight time limit | --- 👀 Patterns to Recognize “Allow LAN → WAN, deny WAN → LAN” – classic default trust model. Rules that reference a zone rather than a concrete IP → easier to spot mis‑configurations. Port 80/443 appearing in both inbound and outbound rules → indicates web traffic is permitted both ways. User‑ID rule followed by a group name (e.g., “Students”) → look for “deny social‑media” patterns. Stateful inspection flag (often labeled “established/related”) appears near the top of rule sets – ensures return traffic isn’t blocked. --- 🗂️ Exam Traps Distractor: “Application‑layer firewalls can only filter based on port numbers.” Why wrong: they examine application data (e.g., HTTP headers) and can block non‑standard ports. Distractor: “Circuit‑level gateways are stateless.” Why wrong: they are explicitly stateful, tracking conversations. Distractor: “A DMZ is a firewall device.” Why wrong: DMZ is a network segment; the firewall enforces the isolation. Distractor: “All inbound traffic is denied by default on any firewall.” Why wrong: default behavior depends on the configured rule set; many default configs allow LAN → WAN. Distractor: “User‑ID eliminates the need for IP‑based rules.” Why wrong: many devices (IoT, printers) lack user credentials, so IP/zone rules remain necessary. Distractor: “A pinhole is a permanent rule.” Why wrong: pinholes are temporary and usually have an expiration. ---