You open the firewall log expecting answers and get a wall of near-identical lines scrolling past faster than you can read them. Most of it is the internet shouting at your perimeter, which is normal. Buried in that noise are maybe a dozen lines that actually matter. The skill is not memorising every field — it is learning which lines to slow down for.

The Fields Almost Every Firewall Logs

Vendors differ in layout, but the same handful of fields show up everywhere. Once you can name them, a log line stops being a blur.

• Timestamp — often in UTC, not your local time. Check this before you conclude anything about "overnight" activity.
• Action — allow, deny, drop, reject, or reset. Wording varies by vendor; some log a silent drop as DENY, others send back a TCP reset and call it REJECT. Read your platform's documentation once, then trust it.
• Protocol and ports — TCP, UDP, or ICMP, plus the source and destination port.
• Source and destination address — the pair that tells you which direction traffic was travelling.
• Interface or zone — usually shown as something like WAN to LAN. This is the fastest way to see whether a connection was inbound from the internet, outbound from a workstation, or internal to internal.
• Rule or policy name — the rule that matched. A rule called "default-deny-inbound" tells you more than any IP address will.
• Session details — byte and packet counts, TCP flags, sometimes a NAT translation or application name.

A Sample Line, Read Slowly

Consider this entry, using addresses reserved for documentation:

09:14:22 DROP TCP 203.0.113.44:54832 -> 10.0.0.12:445 [WAN -> LAN] rule=default-deny-inbound

Read it left to right. At 09:14:22 something on the public internet tried to open a connection to a device inside your network. The action was DROP, so the packet was discarded without a reply. The source was port 54832 — an arbitrary high port, which is what client software uses when it initiates a connection. The destination port 445 is SMB, the file-sharing protocol that Windows uses. The zone field confirms the direction: from the outside world to your internal network. The rule name says it all: this was blocked by the blanket inbound deny.

That single line is a complete story, and the story is "nothing happened." Now change one field. Suppose the destination were 10.0.0.12:443 and the rule were "web-server-inbound." Same shape, very different meaning: someone reached a service you intentionally published, and now the interesting questions are who, from where, and how often.

Reading TCP flags at a glance

If your log includes flags, three of them cover most of what you need. A SYN means a new connection attempt. FIN or RST means a session is ending. ACK on its own usually belongs to a conversation already in progress, so an isolated ACK with no session before it is worth a second look.

Events You Will See Constantly

A public-facing firewall sees automated scanning every day. These events are so common that they are background noise:

• Denied inbound connections to ports 445, 3389, 22, 23, and 1433 from unrelated public addresses.
• Single packets with no follow-up, often UDP, sometimes ICMP.
• One source hitting many different ports in a short window — a port scan, usually opportunistic rather than targeted.
• Many sources hitting the same port — ordinary internet-wide scanning.
• Denied traffic to addresses that do not exist on your network at all.

None of these require action on their own. What matters is what a log line is attached to: a denied scan against a host with nothing listening is a shrug; a permitted connection to a database port from an address you cannot identify is a conversation.

What to Investigate First

When you sit down with a log and a limited amount of patience, work in this order.

1. Confirm the timezone. Everything you conclude about timing depends on it.
2. Filter for allowed inbound traffic from public addresses. Blocks are noise; permits are the events that already reached something.
3. Look for repeated patterns. The same source hitting the same destination at even intervals is more interesting than a thousand random denies.
4. Find long or large sessions. Byte counts climb quickly during a data transfer. If a workstation sent far more data than its role suggests, that is worth understanding.
5. Check outbound connections to unusual destinations — especially on ports that do not match the application you would expect to see using them.
6. Match every interesting line to an asset. Know which internal address is a printer, which is a laptop, and which is a server nobody remembers deploying. Half of triage is knowing what the destination is supposed to be.

A single log line rarely proves anything. Its job is to tell you where to look next.

False Alarms Worth Recognising

Some lines look alarming and are not. A denied inbound connection to a server that has been quietly sitting there for a year is routine. A burst of denies during a scheduled backup window is your own infrastructure. Vulnerability scanners you run yourself will light up the log like a fireworks display.

The inverse is also true: a quiet log is not automatically a healthy one. If a firewall logs only denials, permitted traffic can move through it entirely unrecorded. Check what your logging policy actually captures, because you cannot investigate what was never written down.

Your First Week With the Log

Spend the first few days building a baseline instead of hunting. Note the ten busiest internal addresses, the destinations they talk to, and the times of day traffic peaks. Save that somewhere you can find it again.

Then pick one habit: every morning, spend ten minutes filtering for allowed inbound connections and large outbound sessions, and write down anything you cannot explain. Not everything on that list will be a problem. But the day something does go wrong, you will already know what normal looked like — and you will recognise the line that is not.

Photo: Schäferle / Pixabay