Skip to content
IP-099 IP Addresses & Networks

What does a firewall log actually show?


title: "What does a firewall log actually show?" card_id: "IP-099" status: "complete" source_document: "https://docs.google.com/document/d/17nO3_RbH6zgInmV33LrNhP3UGQshEW1VE8RxbboIIy0/edit?usp=drivesdk"


What does a firewall log actually show?

What does a firewall log actually show?

A firewall log is a record created when a firewall observes network traffic and decides how to handle it.

But that doesn't mean every firewall records everything it sees.

Logging depends on how the firewall has been configured.

It might record allowed traffic.

Blocked traffic.

The beginning or end of a connection.

Traffic matching particular rules.

Security alerts.

Or only selected activity considered important by whoever manages it.

So the absence of a firewall record doesn't necessarily prove that the traffic never existed.

It may simply mean that the firewall wasn't configured to record it.

The exact format varies between products, but firewall logs often contain some common information.

First, there should be a timestamp.

That tells you when the firewall recorded the activity.

As always, you need to establish the time zone and whether the firewall’s clock was accurate.

The log may then show a source IP address and a destination IP address.

The source is where the traffic recorded in that entry appeared to come from.

The destination is where it was being sent.

But those labels only make sense when you understand where the firewall was positioned and which direction the traffic was moving.

A source address might be a private address belonging to a device inside the network.

Or it might be a public address connecting from the internet.

The destination might be an external service, an internal server or another part of the same organisation.

The log may also show source and destination ports.

Those help identify the particular communication at each end.

For example, a destination port of 443 is commonly associated with HTTPS traffic.

But the port number doesn't prove what application was used or what the traffic contained.

You may also see the protocol.

That might be TCP or UDP.

It could also be something such as ICMP, which is used for network functions including ping and doesn't use TCP or UDP port numbers.

There should usually be an action or outcome recorded by the firewall.

Depending on the product, that might be described as:

Allowed.

Accepted.

Blocked.

Denied.

Dropped.

Rejected.

Or something similar.

Those words describe the firewall’s decision.

They don't automatically tell you whether the wider activity succeeded, whether it was malicious or who was responsible.

The log may identify the rule or policy that produced that decision.

That might be a rule number, rule name or policy identifier.

The rule can help explain why the traffic was allowed or blocked.

But you may need the firewall configuration from the relevant time to understand what that rule actually did.

Some logs also identify the interface or network zone through which the traffic arrived or left.

That can help establish whether the traffic was moving into the network, out towards the internet or between different internal areas.

You might also see information about:

The amount of data transferred.

How long a connection lasted.

A session or connection identifier.

The application the firewall believed was involved.

The user or device associated with the traffic.

Or addresses and ports created through Network Address Translation.

Not every firewall will provide all of that information.

And the presence of a field doesn't guarantee that it has been interpreted correctly in a report or export.

Imagine a log showing:

A private source address of 10.0.0.25.

A source port of 51514.

A public destination address of 203.0.113.10.

A destination port of 443.

The TCP protocol.

And an action marked as allowed.

At its most basic, that tells you the firewall allowed TCP traffic from that internal address and port towards that external address and port.

It doesn't tell you what the person was doing.

It doesn't prove that the destination accepted the connection.

And it doesn't identify who was using the internal device.

Those questions require other records.

Before interpreting a firewall log, establish:

Which firewall created it.

Where that firewall was positioned.

What type of event it records.

Which time standard it uses.

And what each field means within that particular product.

A firewall log is an observation and a decision made at one point in a network.

It can tell you a great deal about the traffic the firewall saw.

But it can only tell you what that firewall was capable of seeing—and what it was configured to record.


Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.