About two months ago we brought on a new Tier I analyst who absolutely crushed the interview. Great energy, solid resume, clearly knew the theory. Fast forward to his second week on the job and an alert hit his queue at about 2 PM on a Tuesday. Pretty standard stuff for us, a firewall log showing a series of denied connections from an external IP. He stared at his screen for close to twenty minutes, then walked over to my desk and asked me what the "action" field meant. He did not know if the traffic had been allowed or blocked. That is when it clicked for me that we have a major gap in how people are preparing for SOC analyst roles right now.

People are studying for certifications, building home labs, spinning up SIEMs in their cloud environments, and all of that is great. But somewhere along the way, the most fundamental skill a SOC analyst needs is getting skipped over entirely. Firewall log analysis. Not the concept of it, not the definition you would put on a flashcard, but the actual ability to look at a raw log entry and immediately understand what happened. This is not an advanced skill. This is what your entire first few months on the job revolves around.

I run the Cybersecurity Engineering team at my current org. I have hired SOC analysts at two different companies now and I sit in on nearly every technical interview we conduct. The number one thing that separates people who thrive in their first 90 days from people who struggle is whether they can look at log data and interpret it without hand holding. So that is what this article is about. I am going to walk you through how to read firewall logs the way a working analyst does, with real log examples, real threat patterns, and the exact process I train my team to follow when an alert lands in their queue.

What Fields Are in a Firewall Log Entry?

Regardless of whether your organization runs Palo Alto, FortiGate, Cisco ASA, Check Point, or even an open source solution like pfSense or iptables, every firewall log entry contains the same core data. The field names and formatting will change depending on the vendor, but the information is universal. Once you understand these fields, you can read logs from any vendor on the planet.

Let me give you a generic example of what a firewall log entry looks like:

2024-03-15 14:23:45 ALLOW TCP 10.0.0.50:49832 >> 93.184.216.34:443
Rule: Web-Access-Out Zone: Trust > Untrust
Bytes Sent: 1,245 Bytes Received: 45,678 Duration: 32s

Now let me break this down the way I would expect a candidate to walk me through it during an interview.

Timestamp: This tells you when the event occurred. Sounds obvious but timezone issues cause more confusion in investigations than almost anything else I have seen. Your firewall might log in UTC while your SIEM displays in local time. Always confirm the timezone before you start building a timeline.

Action: This is the very first thing you should look at. Did the firewall allow this traffic or did it deny it? If it says deny or drop, something tried to connect and got blocked. If it says allow, the connection actually went through. Allowed traffic to a suspicious destination is always more concerning than denied traffic because it means the firewall did not stop it.

Protocol: TCP, UDP, or ICMP are going to be the most common. TCP is your connection oriented traffic like web browsing, email, SSH. UDP is connectionless, think DNS and DHCP. ICMP is your ping and traceroute. If you see unusual protocols or unexpected protocol and port combinations, that could indicate tunneling.

Source IP: Where did the traffic come from? If it is an internal IP like 10.x.x.x or 192.168.x.x, that is one of your machines. If it is an external IP as the source and the action is allow going to your internal network, you need to investigate immediately.

Destination IP and Port: Where is the traffic going and what service is it trying to reach? Port 443 is HTTPS, 22 is SSH, 3389 is RDP, 445 is SMB. If you see traffic to port 4444, that is the default Meterpreter reverse shell port and should always be treated as suspicious until proven otherwise.

Rule Name: This tells you which firewall rule matched and why the traffic was allowed or denied. If traffic is being permitted by a rule you do not recognize or by some default catch all rule, that is a problem worth flagging.

Zone Direction: Trust to Untrust is outbound traffic, which is normal for web browsing. Untrust to Trust is inbound, meaning something from the internet is reaching your internal network. DMZ to Trust is a potential lateral pivot from a compromised public facing server. The zone context immediately tells you how worried you should be.

Bytes Sent and Received: This is one of the most underrated fields in my opinion. Normal web browsing typically has much more data received than sent because you are downloading pages. If an internal machine is sending significantly more data than it is receiving to an external IP, especially after hours, that is a red flag for data exfiltration.

Duration: How long the session lasted. Very short sessions could indicate scanning. Very long sessions could indicate C2 channels or tunneling. Consistent durations at regular intervals almost always indicate automated beaconing.

How to Identify Threats in Firewall Log Data

Knowing the fields is step one. Step two is being able to recognize what bad traffic looks like when you see it in a log. Let me walk you through a few of the most common patterns because these are the exact scenarios that come up during investigations and during interviews.

Port Scanning

This is the most common reconnaissance activity you will see hitting your firewall. An attacker sends packets to a bunch of different ports on a target to see what services are running. Here is what it looks like:

14:23:01 DENY 198.51.100.10:45001 >> 10.0.0.5:21 TCP SYN
14:23:01 DENY 198.51.100.10:45002 >> 10.0.0.5:22 TCP SYN
14:23:01 DENY 198.51.100.10:45003 >> 10.0.0.5:23 TCP SYN
14:23:01 DENY 198.51.100.10:45004 >> 10.0.0.5:80 TCP SYN
14:23:01 DENY 198.51.100.10:45005 >> 10.0.0.5:443 TCP SYN

One source IP, one destination, a bunch of different ports, all within the same second, and all denied. That is a textbook vertical port scan. The attacker is mapping what services are running on that specific host. If you see a single source hitting the same port across many different destinations, that is a horizontal scan. They are looking for a specific service across your entire network.

During an interview on my team, if I show you this pattern and you can immediately identify it as a port scan and tell me the difference between vertical and horizontal, you are already ahead of most candidates I talk to.

C2 Beaconing

This one is critical and it is something a lot of newer analysts miss entirely. C2 stands for Command and Control, which is the communication channel between malware on a compromised machine and the attacker's server. Here is what it looks like:

14:00:00 ALLOW 10.0.0.50:49001 >> 198.51.100.99:443 TCP Duration:2s Bytes:500
14:05:00 ALLOW 10.0.0.50:49002 >> 198.51.100.99:443 TCP Duration:2s Bytes:500
14:10:00 ALLOW 10.0.0.50:49003 >> 198.51.100.99:443 TCP Duration:2s Bytes:500
14:15:00 ALLOW 10.0.0.50:49004 >> 198.51.100.99:443 TCP Duration:2s Bytes:500

See the pattern? Exact five minute intervals. Same destination IP every time. Same byte count. Same duration. Normal human web browsing is random. You click around, you read a page for a few minutes, you click something else. Automated malware does not behave like that. It checks in at regular intervals like clockwork. If you see connections to the same external IP at consistent intervals with consistent data sizes, that is C2 beaconing until proven otherwise.

The tricky part is that attackers often use port 443 for their C2 traffic specifically because it blends in with normal HTTPS traffic. A traditional firewall just sees port 443 and lets it through. This is actually where next generation firewalls earn their keep because they can identify the actual application at Layer 7 and flag when the traffic on port 443 is not actually legitimate HTTPS.

Data Exfiltration

If C2 is the attacker's command channel, exfiltration is where they actually steal the data. Here is what it looks like:

02:15:00 ALLOW 10.0.0.50:60001 >> 198.51.100.200:443 TCP Sent:50MB Recv:1KB
02:20:00 ALLOW 10.0.0.50:60002 >> 198.51.100.200:443 TCP Sent:50MB Recv:1KB
02:25:00 ALLOW 10.0.0.50:60003 >> 198.51.100.200:443 TCP Sent:50MB Recv:1KB

Two o'clock in the morning. Fifty megabytes sent per session. Almost nothing received back. Regular intervals. Unknown external destination. Every single one of those details is a red flag on its own. All of them together is basically a giant neon sign saying data is leaving your network.

Remember what I said about the bytes sent versus bytes received ratio? Normal web browsing downloads way more than it uploads. When uploads massively exceed downloads to an external IP, especially at weird hours, that is one of the strongest indicators of exfiltration you can find in firewall logs.

Brute Force Attacks

This pattern is a bit different because the firewall cannot see the actual login attempts. What it can see is the connection pattern that results from them:

14:23:01 ALLOW 198.51.100.10:41001 >> 10.0.0.5:22 TCP Duration:1s Bytes:200
14:23:02 ALLOW 198.51.100.10:41002 >> 10.0.0.5:22 TCP Duration:1s Bytes:200
14:23:03 ALLOW 198.51.100.10:41003 >> 10.0.0.5:22 TCP Duration:1s Bytes:200
14:23:05 ALLOW 198.51.100.10:41005 >> 10.0.0.5:22 TCP Duration:30s Bytes:5000

Many short connections, one or two seconds each, low byte counts, followed by a single long connection with significantly more data. The short connections are failed login attempts. The longer connection at the end with more data transfer is almost certainly a successful login. The firewall does not tell you the password was cracked, but the connection pattern tells the exact same story if you know what to look for.

Make sure to checkout my 81 page reference / cheat sheet / study guide for $4.99 for more in-depth coverage too! I linked it here as well as at the end of the article.

Firewall Log Formats by Vendor: Palo Alto, FortiGate, Cisco ASA, and More

I mentioned earlier that the core data is universal across vendors but the formatting changes. Let me give you a quick rundown because this trips up analysts who only ever studied one platform.

Palo Alto logs are comma delimited and extremely detailed. They separate traffic logs from threat logs, and they include a session end reason field that tells you if the session ended normally, timed out, or was killed by the IPS. They also log both pre-NAT and post-NAT addresses by default which is very helpful for tracing traffic back to internal machines.

FortiGate uses a key value pair format that is actually pretty human readable once you know the field names. One thing to watch out for is that FortiGate uses numeric protocol numbers in logs. So instead of seeing "TCP" you will see "proto=6". You need to know that 6 equals TCP, 17 equals UDP, and 1 equals ICMP. It sounds minor but it can throw you off during a live investigation if you are not expecting it.

Cisco ASA uses a message based format with numbered message IDs. Each ID corresponds to a specific event type. For example, %ASA-6–302013 means a new outbound TCP connection was built. %ASA-4–106023 means traffic was denied by an access list. Once you learn the key message IDs, ASA logs are very informative. Also important to know, ASA severity levels go the opposite direction from what most people expect. Level 0 is Emergency, the most severe. Level 7 is Debug, the least severe. So %ASA-2 is Critical, not minor.

For iptables on Linux, logs show up in the kernel log with a custom prefix you set. The fields use abbreviations like SRC for source IP, DST for destination, SPT for source port, and DPT for destination port. If you are studying for the CySA+ exam, iptables is specifically referenced in the official CompTIA study material so you definitely need to be comfortable with this format.

Cloud firewalls like AWS VPC Flow Logs and Azure NSG Flow Logs use positional or JSON formats and only capture metadata, no payload. AWS uses epoch timestamps that you need to convert. Azure uses letter codes for protocol (T for TCP, U for UDP) and action (A for allowed, D for denied).

What Is the Difference Between Firewall Drop and Deny?

This is a question I have asked in almost every SOC analyst interview I have conducted, and it is surprising how many people get it wrong. What is the difference between drop and deny on a firewall?

When a firewall denies traffic, it sends a response back to the source. An ICMP unreachable or a TCP RST telling the source that the connection was refused. When a firewall drops traffic, it silently discards the packet and sends absolutely nothing back. The source just sits there waiting for a response that never comes.

From a security perspective, drop is almost always preferred for external traffic because it does not reveal any information to the attacker. If you deny, the attacker knows something is listening at that IP address. If you drop, they cannot even tell if the IP exists. However, deny is sometimes used for internal traffic so legitimate users get immediate error feedback rather than sitting around waiting for a timeout.

If you are in an interview and someone asks you which action reveals the least information to an attacker, the answer is drop. Every time.

Why Network Segmentation Matters for Firewall Log Analysis

I want to touch on this because it directly relates to how useful your firewall logs actually are. If your network is flat, meaning everything lives in one zone on the same subnet, then traffic between internal machines never crosses the firewall. That means you get zero firewall log visibility into lateral movement. An attacker could be hopping from machine to machine using RDP or SMB and your firewall would have no idea because the traffic never touches it.

When your network is properly segmented into zones, lateral movement has to cross the firewall to get from one segment to another. This creates log entries that you can detect. For example, if a DMZ web server suddenly starts trying to reach your internal network on port 445, that is likely a compromised server attempting to pivot. With segmentation, the firewall blocks it and logs it. Without segmentation, you are completely blind to it.

This is also why correlating firewall logs with other data sources is so important. Firewall logs tell you what happened at the network level, but they do not tell you who did it or what process initiated the connection. For that, you need endpoint logs, EDR data, and Windows Event Logs. The best investigations use all of these data sources together.

How to Prepare for SOC Analyst Firewall Log Questions

If you are preparing for a SOC analyst interview, here is what I would focus on. Be able to read a raw firewall log entry and walk through each field. Know the difference between drop and deny. Be able to spot a port scan, C2 beaconing, and brute force patterns when you see them. Understand what zone direction means and why inbound allowed traffic from Untrust to Trust should always be investigated.

You do not need to memorize every single vendor's format, but you should be comfortable with at least two. If you can read Palo Alto logs and iptables logs, adapting to FortiGate or ASA becomes pretty straightforward because the underlying data is the same.

I actually put together a complete reference guide that covers all of this in much deeper detail. It is an 81 page guide that walks through every major firewall vendor's log format, threat detection patterns with real log examples, SIEM queries for Sentinel, Splunk, and Elastic, investigation workflows, 20 interview questions with answers, and a 40 question practice quiz. I built it specifically for SOC analysts and folks studying for the CySA+ since the exam tests these exact concepts. If you want to go deeper on any of this, you can check it out here: Firewall Log Analysis Guide

Firewall Log Investigation Checklist for SOC Analysts

When an alert hits your queue and you are staring at a firewall log, here is the process I train my analysts to follow:

First, check the action field. Was the traffic allowed or denied? This immediately tells you the severity level you are dealing with.

Second, check the direction. Is this inbound, outbound, or lateral? Inbound traffic from the internet that was allowed to reach your internal network is always higher priority.

Third, look at the source and destination IPs. Are they internal or external? Look up external IPs on threat intelligence platforms like VirusTotal, AbuseIPDB, and GreyNoise before you spend thirty minutes investigating. A quick TI check can save you a ton of time.

Fourth, check the destination port. What service is being accessed? Port 4444 to an external IP is a completely different conversation than port 443 to a known CDN.

Fifth, look at the data volume. Are the bytes sent and received ratios normal for this type of traffic? Large outbound transfers to external IPs, especially after hours, warrant a closer look.

Sixth, check the timing. Is this a one time event or a repeated pattern? Look for consistent intervals because beaconing is one of the strongest C2 indicators you can find in firewall data.

If you can walk through this process during an interview, you are going to stand out. Most candidates I talk to can rattle off definitions of security terms but very few can actually describe a structured investigation workflow. That is what separates the people who studied from the people who can actually do the job.

Wrapping Up

Firewall log analysis is not optional for SOC analysts. It is foundational. It is the first thing you will do when an alert lands in your queue and it is one of the first things I evaluate during a technical interview. The good news is that once you learn the universal fields and the common threat patterns, you can read logs from any vendor. The format changes but the data is always the same. Source, destination, port, protocol, action. Master those five fields and you can walk into any SOC environment and start working.

If you found this walkthrough helpful and want to go even deeper with vendor specific breakdowns, real world investigation scenarios, and a full practice quiz to test yourself, I put everything I know about this topic into my Firewall Log Analysis Guide. It is built specifically for working SOC analysts and CySA+ candidates. It'S 81 pages for just $4.99 right now. You can grab it here: Firewall Log Analysis Guide

Good luck out there. You got this.