Concepts

Firewalls and Intrusion Detection

Two complementary jobs: a firewall decides what traffic is allowed to flow, and an intrusion detection or prevention system watches what does flow for signs of attack. Neither is enough alone, and both are only as good as their rules and the people reading their output.

01Enforce versus observe

A firewall enforces a policy at a boundary: traffic matching an allow rule passes, everything else is dropped. An IDS sits off to the side, copies traffic, and raises alerts. An IPS sits inline like a firewall but decides based on attack content rather than addresses and ports, so it can drop a malicious packet that a firewall rule would have allowed.

Internet Firewallwho may talk IPSinline · blocks Switch serverserverlaptop IDSpassive · alerts SPAN / tap copy headers & state payload & behavior
A failed IDS loses visibility; a failed inline device loses connectivity. That asymmetry drives how aggressively each is tuned.
Explore

02How deep does it look?

Firewall technology evolved by inspecting progressively more of each flow. Every step adds context and catches more, at the cost of throughput, memory, and configuration complexity.

IP hdrTCP hdrsession contextapplication payloaduser/app id Packet filterlate 1980s Stateful inspectionmid 1990s Application-layer / proxylate 1990s–2000s Next-generation (NGFW)2010s– bar length = how much of the flow each type can base decisions on
Later generations don't replace earlier ones; they add layers on top. Every NGFW still has a packet filter at its core.

03Packet filtering and rule order

A packet filter compares each packet's 5-tuple (source IP, destination IP, source port, destination port, protocol) against an ordered rule list. Most firewalls are first match wins: evaluation stops at the first rule that fits, so ordering is part of the policy, not a formatting detail.

Packet10.0.5.9 → web:443 1 allow any → web tcp/80,443 2 deny any → db any 3 deny 10.0.5.0/24 → any 4 allow app → db tcp/5432 5 deny any → any (default) matches rule 1 → allowed rule 3 never consulted, even though it intended to block this subnet rule 4 is shadowed by rule 2: it can never match
Specific rules go above general ones; a broad rule placed early silently disables everything beneath it that overlaps.

Default deny

End every policy with an explicit deny-all and allow only what is needed. Default allow means every forgotten service is exposed.

Egress filtering

Filter outbound traffic too. It stops infected hosts from beaconing out and data from leaving on arbitrary ports.

Rule hygiene

Large rulesets accumulate shadowed, redundant, and stale rules. More rules usually means more errors, not more security.

Explore

04Stateful inspection

A stateless filter judges each packet in isolation, so to let replies in you must open broad inbound port ranges. A stateful firewall remembers connections it has seen leave and admits only packets that belong to one of them.

Laptop10.0.0.7 Web server93.184.x.x Statefulfirewall SYN out reply matches → pass Attacker unsolicited → drop STATE TABLE tcp 10.0.0.7:51544 ↔ 93.184.x.x:443 ESTABLISHED timeout 3600s
The state table gives context, and is also a resource an attacker can exhaust with floods of half-open connections.

State tracking also lets the firewall enforce protocol sanity (a TCP packet with the ACK flag set but no prior SYN is suspicious) and handle protocols like FTP that open secondary connections on negotiated ports.

05Proxies and next-generation firewalls

Port numbers no longer identify applications: almost everything rides on 443. Application-aware firewalls parse the protocol itself to answer questions a packet filter cannot, such as "is this really HTTP?", "which SaaS app is this?", or "is this file a known malware sample?"

Proxy (application gateway)

Terminates the client's connection and opens a new one to the server, so no packet passes directly. Strong isolation and full content visibility; heavy per-connection cost.

Web application firewall

A reverse proxy specialized for HTTP that blocks attacks such as SQL injection and cross-site scripting in otherwise permitted requests.

NGFW

Combines stateful filtering, application identification, user identity, an IPS engine, threat-intelligence feeds, and optional TLS inspection in one platform.

The TLS inspection dilemma

Payload inspection is blind to encrypted traffic unless the firewall decrypts it, which means acting as a trusted man-in-the-middle with its own CA certificate on every client. That restores visibility but concentrates risk: a poorly implemented interception box can quietly weaken the encryption it replaces, and it breaks certificate pinning and privacy expectations.

Explore

06Architecture: DMZ and segmentation

Where firewalls sit matters as much as their rules. A DMZ (screened subnet) holds anything the internet must reach, so that a compromised public server still sits behind a second boundary before it can touch internal data.

Internet FW 1outer DMZ web servermail relaypublic DNS FW 2inner Internal databaseusersAD / files allow 443, 25, 53 to DMZ only web → db:5432 nothing else internet never reaches the internal zone directly
Two firewalls from different vendors add diversity; a single three-legged firewall with separate interfaces is the cheaper equivalent.

The same idea scales inward. Segmentation splits the internal network into zones (users, servers, OT, guests) so lateral movement must cross a policy point. Microsegmentation applies per-workload rules in hypervisors, cloud security groups, or host firewalls, which is the network half of zero-trust architecture.

Explore

07IDS and IPS

The difference is action. An IDS observes and reports; an IPS observes and intervenes. Think of a camera versus a guard at the door.

IDSIPS
PositionOut of band (SPAN port, network tap)Inline, traffic passes through it
ResponseAlert, log, hand off to analysts or SOARDrop, reset, rate-limit, quarantine automatically
Cost of a false positiveWasted analyst timeBlocked legitimate business traffic
Failure modeFails open; network unaffectedMust choose fail-open (risk) or fail-closed (outage)
Latency addedNoneSome, per packet

Network-based (NIDS)

Watches traffic on a segment. Sees many hosts at once; blind to encrypted payloads and host-internal activity.

Host-based (HIDS)

Runs on the endpoint: logs, file integrity, process behavior. Sees decrypted data; must be deployed and trusted on every host. EDR is its modern descendant.

Explore

08Detection methods

Signature-based Anomaly-based GET /login?u=admin' OR '1'='1 pattern: ' OR '1'='1 match → alert precise, explainable, low false positives blind to anything not yet in the database timeoutbound MB learned baseline 3 a.m. spike can catch novel attacks; noisy, hard to explain
Most production systems combine both, plus protocol and specification checks.

Signature

Matches known byte patterns or behaviors. The basis of Snort and Suricata rule sets. Defeated by zero-days and simple obfuscation.

Anomaly

Models normal (statistically or with machine learning) and flags deviations. Finds the unknown, but "unusual" is not the same as "malicious."

Specification / protocol

Flags violations of what a protocol or application should do: malformed headers, impossible state transitions, policy breaches.

Explore

09Accuracy and the base-rate problem

Every alert is one of four outcomes. Tuning trades false positives against false negatives; you cannot drive both to zero.

Actually malicious? yesno Alert raised? yesno True positivecaught it False positivealert fatigue False negativesilent breach True negativequiet, correct 1,000,000 events · 10 real attacks detector: 99% detection, 0.1% false-alarm rate true alerts ≈ 10 false alerts ≈ 1,000 ≈ 1 in 100 alerts is real
When attacks are rare, even an excellent detector produces mostly false alarms. That is why triage and context matter more than raw detection rate.
Explore

10Reading a rule and an alert

A signature rule has a header that scopes which traffic it applies to and options that describe what to look for. This illustrative rule flags an SSH login attempt burst from outside:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (
  msg:"possible SSH brute force";
  flow:to_server; flags:S;
  detection_filter:track by_src, count 20, seconds 60;
  classtype:attempted-admin; sid:1000001; rev:1;)
What fired?rule, signature id Who and what?src, dst, asset value Is it real?pcap, logs, context Did it work?response, host evidence Actescalate, block, tune an attempted attack against a patched server is low priority; the same alert against an unpatched one is not
Severity comes from the alert plus the target's context, not from the signature alone.
Explore

11Limits, evasion, and failures

Attackers aim at the gap between what the sensor reconstructs and what the target actually receives: fragmented or overlapping packets reassembled differently, low TTLs that reach the sensor but not the host, payload encoding, and above all encryption.

Allowed-path attacks

SQL injection over 443, malware in permitted email, or a stolen VPN credential all pass a correctly configured firewall.

Air gaps and insiders

Stuxnet reached isolated industrial networks on removable media, never crossing a perimeter firewall. Host and behavior monitoring were the only chance.

Alerts nobody acts on

In the 2013 Target breach, detection tools reportedly flagged the malware, but the alerts were not escalated. Detection without response is just logging.

Common misconceptions

MythA firewall provides complete protection.
RealityIt controls flows, not intent. Attacks inside permitted traffic, encrypted payloads, and social engineering go straight through.
MythAn IDS catches every attack.
RealitySignatures miss the unknown, anomalies miss the subtle, and encryption hides payloads. Every detector has false negatives.
MythMore rules mean better security.
RealityBloated rulesets hide shadowed, conflicting, and stale rules and slow the device. Smaller, reviewed policies are safer.
MythIDS and IPS are the same product.
RealityOften the same engine, but placement and response differ. Inline blocking raises the stakes of every false positive.
Explore

—References

Peer-reviewed

  1. Al-Shaer, E. & Hamed, H. (2004). Discovery of policy anomalies in distributed firewalls. IEEE INFOCOM. doi:10.1109/INFCOM.2004.1354680
  2. Arp, D. et al. (2022). Dos and don'ts of machine learning in computer security. USENIX Security. usenix.org
  3. Axelsson, S. (2000). The base-rate fallacy and the difficulty of intrusion detection. ACM TISSEC, 3(3). doi:10.1145/357830.357849
  4. Denning, D. (1987). An intrusion-detection model. IEEE TSE, SE-13(2). doi:10.1109/TSE.1987.232894
  5. Durumeric, Z. et al. (2017). The security impact of HTTPS interception. NDSS. doi:10.14722/ndss.2017.23456
  6. García-Teodoro, P. et al. (2009). Anomaly-based network intrusion detection. Computers & Security, 28(1–2). doi:10.1016/j.cose.2008.08.003
  7. Handley, M., Paxson, V. & Kreibich, C. (2001). Network intrusion detection: evasion, traffic normalization, and end-to-end protocol semantics. USENIX Security. usenix.org
  8. Paxson, V. (1999). Bro: a system for detecting network intruders in real-time. Computer Networks, 31(23–24). doi:10.1016/S1389-1286(99)00112-7
  9. Roesch, M. (1999). Snort: lightweight intrusion detection for networks. USENIX LISA. usenix.org
  10. Sommer, R. & Paxson, V. (2010). Outside the closed world. IEEE S&P. doi:10.1109/SP.2010.25
  11. Wool, A. (2004). A quantitative study of firewall configuration errors. IEEE Computer, 37(6). doi:10.1109/MC.2004.2

Standards and guidance