Check Sophos Firewall daily: operations checklist for admins

A Sophos Firewall can remain technically reachable while showing early warning signs: a WAN connection flaps, disk usage grows, a service reports an error, or failed admin sign-ins increase. A short, repeatable operations check makes these changes visible before they become a longer outage or a security incident.

This workflow covers current operations. The Sophos Firewall Health Check, by contrast, determines whether selected settings comply with Sophos and CIS recommendations. The two checks complement each other but do not replace one another.

The ten-minute check

A fixed workflow is enough for the daily overview:

1. In the Control Center, check new messages and the status of services, WAN, interfaces, VPN, and uptime.
2. Under Diagnostics > System graphs, compare CPU, memory, load average, disk, and important interfaces with the normal baseline.
3. Check the security dashboards and the reports in use for the latest fully available period for new IPS, web, application, zero-day, or Active Threat Response events.
4. In the Log Viewer, check failed administrative sign-ins, unusual sources, and the associated services.
5. For HA, take account of the processing node and, for central reporting, the expected data source.
6. Document every relevant deviation with time, firmware, node, source, affected service, and next step.
7. Do not restart services, delete logs, or broaden rules because of a single spike. Correlate the trend, logs, and actual function first.

This short check is not intended to trigger a configuration change every morning. Its value lies in identifying changes early and deciding clearly whether observation, diagnosis, or escalation is required.

Four views, four different statements

The most important views do not show the same thing:

• Control Center: current overview of system, services, WAN, interfaces, VPN, uptime, and actionable messages.
• System graphs: timeline of CPU, memory, load average, disk, WAN transfer, and interface counters.
• Reports: consolidated analysis of a completed period. Some widgets and report data aren’t updated in real time.
• Log Viewer: individual events with time, module, action, source and destination information, and, depending on the log type, Rule ID or other details.

A red widget is a signal, not yet a complete diagnosis. Likewise, a current green status doesn’t prove that no brief error occurred overnight. Only the combination of current state, timeline, report, and individual event produces a reliable picture.

Check system state and availability

Read the Control Center first

In the Control Center, start with new messages. Sophos shows registration, licensing, reporting, WAN, or upgrade issues there, among other things. Some messages disappear automatically after the issue is resolved and can’t simply be deleted manually. Every relevant message therefore needs an owner and a traceable next step.

Next, compare the services, WAN connections, interfaces, and VPNs actually in use with the expected state. A red interface isn’t automatically an outage: an unused port without an IP address or a physical parent interface for a VLAN can be expected to appear red. What matters is a deviation from the documented design.

A daily check includes at least:

• unexpectedly stopped or degraded services;
• WAN links that are down or repeatedly change state;
• production interfaces with new errors, drops, or collisions;
• important VPN connections that are disconnected contrary to the operations plan;
• an unexpected restart or unusually short uptime;
• new messages that don’t yet have an owner or ticket.

Read System graphs against a baseline

Under Diagnostics > System graphs, look for patterns rather than just individual spikes. Evaluate CPU, memory, and load average together with the core count, traffic, and affected period. A short spike during backup, reporting, or a pattern update has a different meaning from continuously high load during normal traffic.

For disk usage, the trend matters most. One period of high utilization and steady growth are different problem patterns. For interfaces, traffic, errors, drops, and collisions help distinguish firewall load from a link, duplex, cable, or switch problem.

The detailed explanation of load average, offloading, TLS inspection, and System graphs is available in Understanding Sophos Firewall performance specifications. For storage limits and on-box reporting, see Checking Sophos Firewall storage and reports.

⚠️ A single high measurement isn’t yet a reason to restart a service. Time, duration, recurring pattern, affected traffic, and logs must correlate first. Before a restart, preserve the relevant logs and, for an incident, a CTR.

Check security events and admin sign-ins

Read reports for changes

The daily security review focuses on new or significantly changed patterns. Depending on the enabled features, the following areas are particularly relevant:

• Reports > Dashboards > Security dashboard for the consolidated overview;
• Reports > Network & threats > Intrusion attacks for IPS events;
• Reports > Network & threats > Active threat response for blocked IoCs;
• Reports > Applications & web for risky, unwanted, or blocked web and application use;
• zero-day, Security Heartbeat, or wireless reports if these features are used in production.

Not every event is an incident. Source, destination, user, rule, action, frequency, and timing are decisive. A single access attempt from a country doesn’t justify blocking the entire country. Repeated attacks against an exposed service or newly allowed high-risk traffic, however, deserve a specific investigation.

For a safe assessment of sources and countries, see Blocking malicious IP addresses and countries. If a packet was dropped, Analyzing dropped packets on Sophos Firewall leads from the Log Viewer and Rule ID to the actual cause of the drop.

Assess failed admin sign-ins

Review failed administrative sign-ins by time, source IP, destination service, username, and repetition. A typing error from the management network requires different treatment from distributed attempts from the internet or repeated sign-ins to a disabled account.

For suspicious attempts, check exposure and identity first:

1. Is WebAdmin, SSH, User Portal, or VPN Portal intended to be reachable from the affected zone?
2. Does the source come from an approved management network or a targeted Local Service ACL Exception?
3. Is MFA active for the affected administrative access path?
4. Do CAPTCHA, session timeout, and Block login work as planned?
5. Are there simultaneous configuration changes or successful sign-ins for the same account?

Check network access under Sophos Firewall Device Access and Local Service ACL. For accounts, profiles, and offboarding, see Local administrators and device access profiles, and for the second factor, Enabling MFA on Sophos Firewall.

⚠️ Block login can block the source IP for multiple services after failed attempts. Don’t tighten values aggressively during an incident while there is no tested alternative admin and recovery path.

Understand HA, reporting, and model limits

In an HA cluster, each node stores only the logs and reports for the traffic it processed itself. For an event, therefore identify the node that was active or processing traffic at that time. An empty local report on one node doesn’t prove that no event occurred in the cluster.

Sophos Central Firewall Reporting can provide a consolidated view and longer retention. However, the local and central views aren’t treated as identical real-time sources. Enabling and operating Central Firewall Reporting explains log selection, arrival, and retention.

Additional limits:

• Control Center reports are updated periodically and aren’t a real-time event display.
• After upgrading from a version earlier than SFOS 21, report widgets may initially show little or no data until the new report database has been updated.
• XGS 87/87w and XGS 88/88w don’t support on-appliance reports. Central logs, SIEM, and monitoring are therefore more important on these models.
• Missing data can be caused by logging, report period, licensing, retention, disk watermark, or the wrong HA node. It doesn’t automatically prove that no traffic was present.

Document and escalate deviations

A daily check is only complete when relevant deviations have a next step. For a ticket or operations journal, these fields are usually enough:

• date, time, and time zone;
• firewall name, model, SFOS version, and build;
• for HA: node, role, and last status change;
• affected function, zone, interface, VPN, or rule;
• observed state and expected state;
• screenshot, report period, log filter, or Rule ID;
• impact on users or services;
• owner, priority, next check, and escalation path.

Immediate escalation is appropriate when a production WAN link or critical VPN path fails unexpectedly, a protection service is stopped, disk usage continues to grow, load remains high, repeated admin attacks correlate with a successful sign-in, or a new security event matches allowed malicious traffic.

Observation is more appropriate for a brief explainable spike, an intentionally unused interface, or a known event that already has a documented owner and stable functional verification.

Choose a useful check frequency

Sophos doesn’t prescribe one universal daily schedule for every view. The frequency therefore follows risk, operating hours, and existing monitoring:

• Daily or per shift: new messages, stopped services, WAN/VPN/HA, uptime, critical security events, and failed admin sign-ins.
• Weekly: graph trends, interface errors, disk growth, report patterns, recurring sources, and open tickets.
• After changes, upgrades, or failover: retest the affected function, logs, reports, alert path, and actual traffic.
• Regularly outside the short check: Health Check, firewall rule review, backup restore test, license and certificate expiry, and capacity planning.

Email notifications or monitoring shorten response time but don’t replace the review. An alert path is reliable only after transport, event selection, recipient, and response have been tested. The complete workflow is available in Setting up and testing Sophos Firewall email notifications.

Operations checklist

• Check the Control Center for new messages and unexpected status changes.
• Compare services, production WAN links, interfaces, VPNs, and uptime with the expected state.
• Read CPU, memory, load average, disk, and important interface counters against the baseline.
• Check security reports for the latest fully available period.
• Correlate suspicious events in the Log Viewer with source, destination, user, action, and Rule ID.
• Assess failed admin sign-ins by source, service, and repetition.
• For HA, take account of the processing node and node-local logs.
• Don’t trigger restarts, log deletion, or broad rule changes without preserving evidence and a recovery path.
• Document every relevant deviation with owner, priority, and next step.
• After a correction, retest not only the status but also the actual function.

FAQ