17.3 Firewall and Network Monitoring Basics
A Firewall Is a Rule Engine Over Five Values
Every packet carries a five-tuple: source address, source port, destination address, destination port, and protocol. A firewall statefully compares that tuple against an ordered rule list and picks allow, deny, or drop. Statefulness matters: an inbound packet is normally admitted only because it is a reply to an outbound connection the firewall already saw, which is why "default deny inbound, allow established" works for laptops and clients. Rule order is the part beginners get wrong -- a broad allow placed above a narrow deny silently wins, and the audit trail for that mistake is the deny counter you never noticed was zero.
Reading Ingress and Egress Records
Flow records (NetFlow, IPFIX, sFlow, or cloud VPC flow logs) are metadata rather than payloads: who talked to whom, on which port, for how long, with how many packets and bytes, plus a start and end time. Because flows are small, you can keep months of them and ask historical questions. Read them in both directions. Ingress questions are classic -- who reached this database port, and should they have? Egress questions are more valuable for intrusions, because attackers must call home: a workstation initiating outbound connections on 4444 or 8443, repeated short sessions to the same external IP at a fixed interval (beaconing), DNS queries with unusually long labels or extreme subdomain counts (tunneling), or a print server suddenly speaking SMB outward to the internet.
Scan Patterns and Volume Baselines
Scanning has a shape. A vertical scan is one source touching many ports on one host; a horizontal scan is one source touching one port across many hosts, which is how worm-like and credential-reuse behavior looks; a slow scan stretches the same pattern over hours to hide under thresholds. The tell is low packet-to-byte ratio plus connection attempts that never complete a handshake, spread wider than any legitimate admin tool. The second lens is baselines: for each host and port pair, keep a normal band of daily bytes and connection counts, then alert on departures. Baselines make the impossible question answerable -- not "is this traffic malicious?" but "is this traffic weird for this host?" A domain controller that normally sends 200 MB a day outbound and suddenly sends 6 GB at 03:12 deserves a look even if nothing matched a signature.
Practical Defaults for a Small Team
Start narrow: block inbound by default except published services, log every deny, export flow records from the border and from cloud security groups, and build per-host baselines before writing any threshold rule. Log the five-tuple plus bytes for everything, keep full payloads only where you have a legal basis and a storage plan.
Architecture Diagram
Key Takeaways
- A firewall is an ordered five-tuple rule engine; rule order and the established-state rule decide most real outcomes.
- Flow records are cheap metadata, so keep months of them and ask historical questions in both directions.
- Egress beats ingress for intrusion work: beacon intervals, odd high ports, and long-label DNS are the classics.
- Scans have shape -- vertical, horizontal, or slow -- with uncompleted handshakes and low bytes per connection.
- Baseline each host and port, then alert on departure from the band instead of guessing at "malicious".