11.2 Firewall Deployments, Limits, and Log Analysis

11.2 Firewall Deployments, Limits, and Log Analysis

Network and web protection on the SAL1 training content covers firewalls and web application firewalls (WAF). This section is the network-firewall half: where the control is deployed, what it can and cannot detect, how basic rules are expressed, and how an L1 analyst reads allow and deny logs. The next section covers WAF rule creation. This independent OpenExamPrep material teaches those SAL1 topics as analyst skills, not as a vendor CLI course.

A firewall is a policy engine that decides whether a packet or connection may pass between network zones. The decision is almost always based on addressing and ports, sometimes on connection state, and on next-generation products on application identity. Payload inspection of encrypted user traffic is the exception, not the default — and that exception is the most important limitation you will use in SOC investigations.

Deployments you will meet in tickets

Perimeter (north-south). A border firewall sits between untrusted networks (the internet, a partner link) and a demilitarized zone (DMZ) or internal campus. It is the classic place for blocking inbound TCP/445 while allowing outbound TCP/443. Logs here explain how a host reached the internet, not how two internal servers talked to each other.

Internal segmentation (east-west). Firewalls or layer-3 access control lists (ACLs) between user VLANs, servers, payment zones, and industrial networks. Ransomware lateral movement often crosses these boundaries. An allow from a workstation VLAN to SMB on a file server may be expected; the same workstation to RDP on a domain controller may be a finding.

Host-based firewall. Windows Defender Firewall, nftables/iptables on Linux, or a cloud instance-local filter. These logs live on the endpoint or in EDR, not only on the network appliance. They matter when the network firewall never saw the traffic (same-subnet east-west, or an encrypted overlay that bypasses the campus edge).

Cloud security groups and network ACLs. In Infrastructure as a Service (IaaS), a security group is typically stateful and attached to an elastic network interface. A network ACL is often stateless and attached to a subnet, so you must allow both directions explicitly. Analysts who treat every cloud log like a campus hardware firewall miss that difference.

All of these are firewall deployments. The practical question is which log you open, not which brand shipped the box.

Basic configuration: default deny, 5-tuple, and NAT

A defensible baseline is default deny: traffic is dropped unless a rule allows it. Each allow rule is usually a 5-tuple plus an action and a name:

Network Address Translation (NAT), especially source NAT (SNAT) / port address translation, rewrites internal RFC1918 addresses to a public egress IP. The internet sees 192.0.2.15; the internal log still has 10.20.30.45. If you search SIEM only for the public IP, you will miss the workstation. If threat intel lists the public IP as C2, remember many users share that egress IP.

Stateful filtering versus next-generation firewalls

A stateless packet filter evaluates each packet alone. Return traffic needs its own rule. Cloud network ACLs often behave this way.

A stateful firewall tracks connection state. After an internal host completes a TCP three-way handshake to 203.0.113.10:443, return packets that belong to that established session are allowed even if no inbound rule would have permitted a new SYN from the internet. UDP is tracked with a shorter timeout. This is why an inbound packet is sometimes a reply to an outbound allow, not evidence that someone opened a hole.

A next-generation firewall (NGFW) still uses state, then adds application identification (the flow is HTTPS or DNS, not merely TCP/443 or UDP/53), user identity from directory integration, URL categories, and sometimes an intrusion prevention system (IPS) signature set. Those extras help. They do not magically decrypt every session.

Detection capabilities and the encrypted-traffic limit

Firewalls are strong at:

• Blocking entire ports and protocols (inbound SMB, telnet, forgotten databases).
• Enforcing zone boundaries (users cannot hit management interfaces).
• Geo or IP reputation blocks at the connection layer.
• Logging who talked to whom, when, and whether the policy allowed it.
• NGFW/IPS: matching known exploits on cleartext or inspected sessions.

Firewalls are weak at:

• Encrypted traffic. Without Transport Layer Security (TLS) inspection, the appliance sees IP, port, and at best Server Name Indication or other TLS metadata, plus ciphertext. It does not see the HTTP path, JSON body, or SQL.
• Allowed-but-malicious HTTPS. If outbound 443 is allowed (it almost always is), C2, exfiltration, and payload download can look like a user browsing the web. The ALLOW line is not a verdict of benign.
• Encrypted DNS (DNS over HTTPS) riding the same web allow.
• Traffic that never hits the device (same L2 segment, or a split-tunnel VPN that bypasses the campus firewall).

TLS inspection is a separate architectural choice with privacy, pinning, and performance costs. Do not assume the firewall in a SAL1 scenario is decrypting.

Worked log lines

Read these four lines the way an L1 would during an EDR-correlated case. Host 10.20.30.45 is FINANCE-WS07, user jpatel.

2026-09-18T14:02:11Z action=DENY proto=TCP src=10.20.30.45 sport=49152 dst=203.0.113.88 dport=4444 policy=OUTBOUND-DEFAULT nat=none
2026-09-18T14:02:12Z action=ALLOW proto=TCP src=10.20.30.45 sport=51200 dst=203.0.113.32 dport=443 policy=WEB-OUT nat=192.0.2.15:51200
2026-09-18T14:07:44Z action=DENY proto=UDP src=10.20.30.45 sport=5353 dst=224.0.0.251 dport=5353 policy=BLOCK-MDNS
2026-09-18T14:11:03Z action=ALLOW proto=TCP src=198.51.100.22 sport=443 dst=10.0.5.20 dport=443 policy=INBOUND-HTTPS nat_dst=10.0.5.20:443

Line 1. 5-tuple: TCP 10.20.30.45:49152 → 203.0.113.88:4444. DENY by the default outbound policy. Source port 49152 is ephemeral (typical client). Destination 4444 is a historically popular listener for reverse shells and some Metasploit payloads, but a port is not proof of malware — it is a reason to open EDR on that host and to ask why an application tried a non-web port. nat=none means this attempt never received a public translation because it was dropped first.

Line 2. One second later, the same internal host is ALLOWED to 203.0.113.32:443 under WEB-OUT, with SNAT to 192.0.2.15:51200. This is the allowed-but-malicious HTTPS problem in miniature. If EDR showed encoded PowerShell then rundll32 talking HTTPS, this ALLOW is the network corroboration, not a reason to close the case. External intel that lists 192.0.2.15 as suspicious may simply be listing the company's egress IP.

Line 3. Multicast mDNS blocked. Often benign noise from a workstation. Do not treat every DENY as an incident.

Line 4. Inbound HTTPS to a published server 10.0.5.20 from 198.51.100.22. Destination NAT (or a reverse proxy) publishes an internal app. This log cannot tell you whether the HTTP body was SQL injection; that is WAF and application-log territory (next section and chapter 9).

How L1 should use firewall logs in a case

1. Extract the 5-tuple and timestamps; do not quote only the destination IP.
2. Record the policy name (default deny versus an explicit business allow).
3. Translate NAT so SIEM, EDR, and threat intel use the same host.
4. Treat ALLOW on 443 as a lead to inspect, not a clean bill of health.
5. Escalate unusual DENYs that match EDR process trees (for example repeated 4444) and unusual ALLOWs that match C2 time patterns.

Firewalls remain essential. They are not EDR and they are not a WAF. Each control answers a different question.