What Sophos Firewall logs actually record

Sophos Firewall produces records across traffic handling, security inspection, authentication, VPN activity, system health, and administrative changes. The exact log categories available depend on the SFOS version, enabled modules, licensing, and deployed features. A firewall protecting a simple office network will generate a very different event profile than one enforcing SSL/TLS inspection, web protection, site-to-site VPNs, and high-availability failover.

The most useful distinction is between a connection decision and a security detection. A traffic log tells you that the firewall allowed, denied, dropped, or rejected a session according to a rule or routing decision. A security log may tell you that the same session was blocked because a web policy, intrusion prevention signature, malware control, application rule, or threat-protection feature identified a risk.

Neither event type stands alone. An allowed firewall rule does not mean the activity was safe. A security block does not automatically mean a host is compromised. Context from endpoint telemetry, DNS activity, identity records, and the destination's reputation is often needed before declaring an incident.

Where to start in Sophos Firewall Log Viewer

The Log Viewer is the first stop for a focused investigation. Filter by a narrow time range, then add known indicators such as source IP address, destination IP address, username, hostname, rule name, service, or action. Starting with a precise question prevents the common mistake of scrolling through thousands of unrelated events.

Time accuracy matters more than many teams realize. Confirm that the firewall uses reliable NTP synchronization and that analysts understand the displayed time zone. When Sophos Firewall, Microsoft 365, endpoint protection, cloud audit logs, and a SIEM disagree by several minutes, reconstructing an incident becomes unnecessarily difficult.

For sustained monitoring, retain and forward logs beyond the local appliance where appropriate. Local storage is useful for immediate troubleshooting, but it has practical limits during a busy event, hardware issue, or retention cycle. Centralized logging to a SIEM supports longer retention, correlation, alerting, and audit reporting. It also keeps a record available if the firewall itself is affected during an incident.

Reading Sophos Firewall traffic logs

Traffic logs are the foundation of most firewall investigations. They typically identify the source and destination, protocol or service, policy or rule involved, action taken, interfaces or zones, and traffic volume. Depending on the event and configuration, they may also show translated addresses, user identity, connection details, and an explanation for the decision.

Start by reading a traffic event in this order:

1. Establish the direction. Determine whether the connection is inbound, outbound, or moving between internal segments. A denied inbound connection to a public address is common. An unexpected connection from a finance workstation to a server-management subnet deserves more attention.
2. Identify the decision point. Review the matched firewall rule, routing path, NAT behavior, and action. A rule name should explain business intent. Names such as Rule 17 or Allow Any slow every future investigation.
3. Check identity and asset context. An IP address is not an owner. Map it to a DHCP lease, endpoint, server, VPN user, or cloud workload. Confirm whether the user, host, and destination fit normal business activity.
4. Measure repetition and volume. One blocked attempt may be background internet noise. Hundreds of repeated attempts, a sudden burst of outbound traffic, or a long-lived unusual session can change the risk assessment.
5. Correlate before changing policy. Find nearby authentication, VPN, web, endpoint, and DNS events before opening a rule or blocking a destination. Fast changes based on incomplete evidence can interrupt legitimate operations.

An action field needs careful interpretation. Deny, drop, and reject are not interchangeable in troubleshooting terms. A deny or drop can be an expected policy enforcement result, while a reject may return a response to the requester. The real question is why that action occurred: a rule mismatch, an expired VPN state, an unavailable route, a missing NAT rule, or an intentional segmentation control.

Also account for traffic that may be processed differently based on firewall acceleration, inspection settings, or policy design. If a team expects detailed application or threat visibility but has excluded a flow from inspection for performance or compatibility reasons, the absence of a security event is not proof that the flow was harmless.

Security, web, and threat events need context

Security-related logs often receive the most attention because their labels sound urgent. They can include intrusion prevention detections, malicious-download blocks, web-control decisions, application-control events, advanced threat findings, and TLS inspection failures. They are valuable, but a mature response process classifies them before escalating.

First, determine the enforcement result. Was the action blocked, allowed, warned, or merely detected? Next, identify the protected asset and the destination or payload involved. A blocked exploit attempt against an internet-facing service should lead to patch and exposure validation. A web-filter block for a newly registered domain might warrant endpoint review, especially if the same user had repeated authentication failures or downloaded a suspicious file.

False positives are possible, particularly with custom applications, encrypted traffic, uncommon protocols, and aggressive intrusion prevention policies. The wrong response is to create a broad exclusion because one business application stopped working. A better response is to document the affected flow, validate the vendor requirement, limit the exception to the smallest possible scope, and set a review date.

TLS inspection deserves the same discipline. It can provide valuable visibility into encrypted web traffic, but it introduces certificate-management, privacy, performance, and application-compatibility considerations. Sensitive categories, regulated workflows, and applications that use certificate pinning may require narrowly defined bypass decisions. Those exceptions should be visible in policy review and not become permanent blind spots.

VPN, authentication, and administrator logs reveal control failures

Remote access incidents often become visible first in authentication and VPN records rather than in firewall traffic logs. Review successful and failed login attempts, user names, source addresses, authentication method, tunnel establishment, assigned addresses, disconnects, and configuration changes. A cluster of failed logins followed by a successful connection from an unfamiliar geography is a prompt for identity validation, not an automatic compromise verdict.

Administrative and system logs are equally significant. They can show firmware changes, policy edits, configuration imports, service restarts, high-availability events, interface failures, disk or resource pressure, and administrator activity. These records help distinguish a security event from an operational failure. For example, a sudden rise in denied traffic after a maintenance window may point to an unintended policy change rather than hostile activity.

Protect administrative access with named accounts, strong MFA where supported by the access design, restricted management networks, and a controlled change process. Shared administrator credentials make log attribution weak and turn a routine troubleshooting task into an audit problem.

Build a monitoring model instead of collecting noise

Logging every available detail indefinitely is not automatically good security. It can increase storage cost, obscure important signals, and expose more operational or personal data than the organization needs to retain. The right level depends on risk, regulatory obligations, network volume, incident-response maturity, and the systems available for analysis.

A practical baseline includes firewall policy decisions for sensitive zones and internet-facing services; VPN and authentication outcomes; administrator changes; IPS, malware, and web-security events; system and high-availability health; and DNS or application telemetry where it supports investigation. High-volume permitted traffic can require selective logging or aggregation, provided that critical systems still retain enough evidence for triage.

Forwarding these events to a SIEM creates more value when correlation rules reflect real operational risks. Useful examples include repeated VPN failures followed by a successful login, an endpoint alert followed by new outbound connections, a new administrative login followed by firewall rule changes, or an internal host contacting many blocked destinations in a short period. Alerts should have ownership, severity criteria, and an escalation path. A dashboard with no response process is reporting, not monitoring.

For NIS2-oriented governance and similar compliance expectations, firewall logs support evidence of access control, monitoring, incident handling, and change management. They do not satisfy those obligations by themselves. Retention standards, documented review procedures, asset ownership, tested response playbooks, and management oversight are part of the wider control environment.

Make logs useful during the next incident

The best time to improve Sophos Firewall logging is before the urgent ticket arrives. Use meaningful rule names, keep network zones and object definitions understandable, document approved exceptions, synchronize time, and test whether key events reach the SIEM with the fields analysts need. Review logging after major network, cloud, identity, and application changes.

A boutique managed security partner can take ownership of that operating model: tuning Sophos policies, investigating alerts alongside endpoint and identity evidence, and explaining the tradeoffs before making changes. The practical measure of success is simple: when an event occurs, your team can determine its scope and business impact quickly enough to act with confidence.

Author: Yavor Y. Zlatev CEO of AdvisionIT

Date: 15.08.2026