Study guide
11.2 Firewall Deployments, Limits, and Log Analysis
TryHackMe Security Analyst Level 1 SAL1
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy
2 SOC Simulator Exam Skills
2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes
3 Network Essentials
3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission
4 Operating System Basics
4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity
5 Cryptography, Cloud, Web and Scripting Basics
5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs
6 Cybersecurity Fundamentals and MITRE ATT&CK
6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques
7 Kill Chain, NIST CSF, and Attack Indicators
7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain
8 Social Engineering and Network Attacks
8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns
9 Web Exploitation and Endpoint Attacks
9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd
10 Command and Control, Malware, and LOLBAS
10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS
11 EDR, Firewalls, and WAF
11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation
12 SIEM and SOAR
12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration
13 Threat Intelligence and Vulnerability Scanning
13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning
14 SOC Team, Activities, and Alert Triage
14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts
15 SOC Metrics, Escalation, and Communication
15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication
11.2 Firewall Deployments, Limits, and Log Analysis
Key Takeaways Explain This Topic AI
A firewall allow or deny decision is recorded against a 5-tuple: source IP, source port, destination IP, destination port, and protocol, plus the policy name and any NAT translation.
Stateful firewalls track TCP connection state so return packets for an established session are allowed; next-generation firewalls add application and user context but still do not see HTTPS payloads unless TLS is inspected.
An ALLOW to destination port 443 does not prove the session is benign; malware commonly beacons over allowed HTTPS.
Perimeter, internal segmentation, host-based, and cloud security-group deployments are all firewalls an analyst may need to log-correlate.
Last updated: September 2026
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 ExamFinch 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:
- Field Meaning in a log line
- Source IP Who started the packet (before or after NAT — see below)
- Source port Ephemeral high port on clients; service port on servers
- Destination IP Intended target
- Destination port Service (22, 53, 80, 443, 3389, 4444, and so on)
- Protocol TCP, UDP, ICMP, or another IP protocol number
- Action ALLOW or DENY (some vendors say permit or drop)
- Policy / rule name Which line in the rulebase fired
- NAT addresses Translated source or destination after Network Address Translation
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
Extract the 5-tuple and timestamps; do not quote only the destination IP.
Record the policy name (default deny versus an explicit business allow).
Translate NAT so SIEM, EDR, and threat intel use the same host.
Treat ALLOW on 443 as a lead to inspect, not a clean bill of health.
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.