Detection and Logging

Firewall Logs

Firewall logs record allow and deny decisions at network boundaries and host firewalls. They help you validate segmentation, detect scanning, and spot unexpected outbound activity that may indicate command and control or data exfiltration.

Learning objectives

What you should be able to do after reading.

Use firewall logs to understand exposure, segmentation, and egress behavior
Recognize scan patterns, misconfigurations, and policy drift in log data
Design firewall logging that supports investigations without creating noise

At a glance

Fast mental model before you dive in.

🧠

What firewall logs show

A policy decision (allowed, denied, rejected)
Who talked to whom and on what protocol
Which rule or zone matched the traffic
When and where the traffic hit the firewall

High signal views

Denies to admin ports and sensitive segments
New outbound destinations from servers
East west traffic spikes between segments
Repeated denies from one source across many targets

Gotchas

NAT can hide the original internal source
Stateful logging may capture only the first packet
Rate limits can hide scan shapes
Allowed traffic logging can explode volume fast

What firewall logs should include

Timestamp, action (allow or deny), rule name or id, interface, protocol, and ports
Source and destination IP plus direction, and user or device identity when available
Connection context such as state, bytes or packets, NAT translation, and drop reason when provided

Detection ideas

Pattern	What you see	Why it matters	Security effect of acting
Port scan	One source hitting many ports or many hosts with frequent denies	Often reconnaissance before exploitation attempts	Block or rate limit the source and verify that exposed services are intentional
Unexpected egress	New destinations, unusual ports, or traffic to domains that are rare for that host	May indicate malware command and control or staging for exfiltration	Contain the host, block destinations, and hunt for the same pattern across endpoints
Policy drift	New broad allow rules or sudden spikes in hits on an existing rule	Increases attack surface and can hide malicious traffic	Review change control, tighten rules, and add alerts on high risk rule changes

Signals to watch for

Patterns worth investigating further.

📡

Deny spikes from a single source or toward a critical service
Outbound connections to new destinations that are rare for the environment
Allow rules that suddenly receive heavy traffic outside normal hours

DEEP DIVE

▾

Interpreting a firewall decision

A firewall log is a policy decision at a moment in time. Read it like a sentence: an action happened because a rule matched for a protocol, source, destination, and port.

Extract a consistent core set of fields: action, rule name or id, direction, interface, src_ip, dst_ip, src_port, dst_port, protocol, and any zone or policy label.

Always confirm what you are looking at. Some devices log pre NAT addresses, some log post NAT addresses, and some can log both.

Logging without drowning in noise

Logging every allowed connection is usually too noisy. A practical approach is to log denies, plus a curated set of allows that indicate risk, such as new outbound destinations, admin ports, and traffic to sensitive segments.

If you use sampling or rate limiting, document it. During scanning, rate limits can hide the shape of an attack. Prefer full detail for key assets and segments.

Scan patterns versus normal behavior

Port scans often look like many short attempts to many ports or many hosts. Combine firewall logs with endpoint signals when possible to confirm whether a legitimate process made the attempts.

Normal behavior has patterns. A web server receiving many inbound connections is normal. A database server receiving random inbound ports is not.

Baseline by role. Segment your searches by server class, user subnet, and critical assets to reduce noise.

Egress and segmentation as detection surfaces

Egress is often where detection is easiest. Outbound connections from servers that should not talk to the internet are high value.

Segmentation decisions are also strong signals. If a host starts talking to a segment it never touched before, investigate the process and the identity behind it.

Pair firewall logs with DNS and proxy logs to understand the domain context behind an outbound connection.

NAT, state, and other gotchas

NAT can change what you see. You might need both the internal and external addresses to trace activity back to a host. Make sure you know where NAT occurs in your path.

Stateful firewalls may log only the first packet of a flow, or only denies. Understand whether you get per packet logs, per connection logs, or summaries, because this changes how you interpret volume.

Practical investigations with firewall logs

When you see a deny, ask what it tried to do and whether the host should ever attempt it. If the destination is external, check whether it appears in DNS logs and proxy logs for the same time window.

When you see a new allow to a rare destination, treat it as a lead. Identify the originating process from endpoint telemetry and confirm whether the destination is expected for that application.

Starter hunts

• Denies to admin ports from user subnets

• New outbound destinations from servers

• East west traffic spikes between segments

• Repeated denies from one source across many targets

• High volume outbound connections to one destination