Sophos Firewall Scripts Without Cronjob: Risks and Alternatives

In special cases, local shell scripts on a Sophos Firewall may seem tempting: a recurring check, a heartbeat, a workaround after a restart, or a small network change that should happen automatically. However, caution is advised here. A Sophos Firewall is a security appliance, not a general automation server.

Persistent local scripts, altered startup sequences, or self-built background processes can complicate upgrades, HA behaviour, support cases, security, and troubleshooting. Often, the question is not how to replace a cronjob, but which supported or better-controlled alternative solves the actual problem.

⚠️ Warning: Local shell or startup script changes on a Sophos Firewall should not be used as a standard operational practice. Before any special case, a backup, test, rollback plan, maintenance window, clear responsibility, and an assessment of whether a supported method exists are necessary.

Quick Decision

When a local script is proposed, the primary task should first be identified. This usually quickly reveals whether the firewall itself is the right place for execution.

Should a configuration be changed regularly?: The script would adjust firewall objects, rules, routes, or services. Consider external automation via XML API or Sophos Central.
Should a state be monitored?: The script checks interface, service, VPN, storage, or reachability. Use external monitoring, SNMP, sFlow, Central Reporting, or Syslog.
Should an error be automatically masked?: The script restarts services, deletes files, or resets connections. Analyse the cause, secure logs, and check support case or firmware status.
Should unsupported behaviour be permanently enforced?: The change affects startup logic, routing, packet processing, or local files. Change design or use a supported function.

If none of these questions are clearly answered, the workaround is not yet ready for a productive firewall. Then the problem should first be described more precisely: symptom, trigger, affected version, desired outcome, and acceptable operational method.

Why Local Scripts Are Problematic

A local script may seem small, but in a firewall environment, it can quickly become critical to operations. The firewall processes productive traffic, VPNs, authentication, NAT, logging, and security functions. A faulty background process or unclear change to startup behaviour can therefore have significantly greater impacts than on a normal Linux system.

Typical risks:

Supportability: Self-modified startup sequences are difficult to assess in support cases.
Firmware Upgrades: Updates can change files, services, paths, or behaviour. A script may then run differently or not at all.
HA Cluster: Changes must be understood per node. After failover or role change, a script may be missing or act twice.
Security: Scripts often contain credentials, URLs, or internal logic that are not properly protected and documented.
Performance and Storage: Endless loops, log outputs, or frequent network calls can burden CPU, memory, or partitions.
Troubleshooting: A script can mask symptoms. Then the actual cause is not addressed.

If storage, reporting, or log problems already occur, the cause should first be checked. Suitable for this are Clean up Sophos Firewall Storage and Reports, Sophos Firewall Troubleshooting: Services and Logs, and Secure Sophos Firewall Logs for Support and Analysis.

First Check the Suitable Alternative

Many tasks for which a local script was previously built can now be solved more cleanly through existing functions, external automation, or monitoring.

Recurring configuration change: XML API with restricted access, documented process, and external execution. The basics are in Secure XML API Access to Sophos Firewall.
Compare backup or check configuration change: Use Sophos Firewall Config Studio and Audit Trail instead of local shell logic.
Control routing or system traffic: Use integrated routing, SD-WAN, and IPsec functions. For system traffic, SD-WAN Routing for Reply Packets and System Traffic is suitable.
Monitoring heartbeat: Use external monitoring, not a permanent process on the firewall. For hardware and traffic visibility, SNMP Hardware Monitoring, sFlow Monitoring, and Central Firewall Reporting are suitable.
Long-term log analysis: Use Syslog, SIEM, or Central Reporting instead of permanently extending local files.
Regular recovery preparation: Document and test Backup and Restore on Sophos Firewall properly.

The most important principle: Automation should run outside the firewall as much as possible. This makes versioning, secrets, logging, monitoring, rollback, and responsibilities better controllable.

When a Local Script Should Even Be Considered

A local script is at most a special case. It should only be considered if a specific problem cannot be solved via WebAdmin, Device Console, XML API, Central, Syslog, Monitoring, or another supported function.

A local approach can only be sensible if all points are met:

The purpose is narrowly defined and documented.
It is not a permanent replacement for a missing operational function.
The change has been tested in a test environment.
A complete backup and a clear rollback path are available.
The impact on HA, firmware upgrades, and support is assessed.
There is a responsible person who checks the script after updates and failovers.

If these points are not met, no local workaround should be built. Then it is better to change the actual design or automate the task externally.

Minimum Requirements Before a Special Case

Before a special case, one should not experiment directly on the productive firewall. First, the change is treated like a small change.

Backup and Recovery

Before the change, a current backup must be available. Additionally, it should be clear where the Secure Storage Master Key is located and whether a restore on replacement hardware, virtual appliance, or HA environment has been realistically tested.

For critical changes, a pure configuration backup is not always enough. If the change affects local files or processes, it must be documented what has been changed outside the normal configuration.

HA and Failover

In HA clusters, it is not enough to only consider the active firewall. One must know:

On which node does the change exist?
What happens after a failover?
Does the change then not run, run once, or run twice?
Is it treated the same on both nodes during firmware updates?

This is why local scripts are particularly tricky in HA environments.

Logging and Control

A special case without control is not a clean operation. It must be visible whether the automation is running, failing, or causing unexpected side effects. For this, a log target, monitoring, and a simple check routine after restarts, updates, and failovers are needed.

If SSH or Advanced Shell is necessary for control, access should be properly secured beforehand. The basics are in Connect to Sophos Firewall via SSH and Sophos Firewall CLI Troubleshooting: Important Commands.

What to Avoid

Some patterns cause more problems than benefits in practice.

Unattended Restarts: A firewall should not be regularly restarted to mask symptoms. The cause must be narrowed down.
Permanent Background Loops: Endless loops can burden CPU, memory, network, or logs.
Persistent Startup Logic Without Documentation: After updates, restore, or HA failover, it is otherwise unclear what state applies.
Direct Packet or Routing Manipulation via Shell: If routing, SD-WAN, IPsec, NAT, or MSS are affected, supported firewall functions should be checked first.
Secrets in Plain Text: Credentials, tokens, or URLs should not be uncontrolled in local scripts.
Workarounds Without Owner: If no one is responsible for review and removal, the workaround becomes a legacy issue.

For IPsec, routing, or MSS issues, other articles are usually a better starting point: Sophos Firewall IPsec VPN Troubleshooting, Check MTU and MSS on Sophos Firewall for VPN Issues, Adjust Route Precedence on Sophos Firewall, and SD-WAN Routing for Reply Packets and System Traffic.

If a Script Already Exists

Existing local scripts should not be blindly removed or adopted. First, an inventory is needed.

Check:

What problem was the script originally supposed to solve?
Who created it and who is responsible today?
Where is it located and how is it started?
Does it continue to run after restart, HA failover, and firmware update?
Does it contain credentials, tokens, internal URLs, or hard IP addresses?
Are there logs or monitoring?
Is there a supported alternative to which it can be migrated?

Then it is decided whether the script is removed, replaced, documented, or transferred to external automation. Before any change, a backup should be created and a maintenance window planned.

Documentation Template for Special Cases

If a local special case remains temporarily despite risks, it should be documented so that another person understands it after an update, failover, or support case.

Purpose: What specific problem is being solved?
Location: File, path, user, startup mechanism, and affected HA node
Trigger: When does the script run: manually, at startup, cyclically, or by a service?
Change: Which commands, files, services, routes, or interfaces are affected?
Risk: What happens in case of error, restart, firmware update, restore, or failover?
Control: Where can success, errors, and side effects be seen?
Rollback: How is the state fully reverted?
Owner: Who checks the special case after updates and when will it be removed?

This documentation should not only be in a personal note system. In the operations or customer runbook, it prevents a later support case from starting with a search on the firewall.

Checklist

The purpose of the script is specifically documented.
Supported alternatives such as WebAdmin, XML API, Central, Syslog, SNMP, sFlow, or Config Studio have been checked.
Backup, Secure Storage Master Key, and rollback path are available.
HA behaviour is assessed.
Test environment or maintenance window is planned.
Secrets are not stored locally in plain text.
Logging and monitoring are defined.
Responsible person and review date are set.
After firmware updates, the special case is consciously rechecked.

FAQ

Can you use cronjobs on Sophos Firewall?

You should not base the operational model on maintaining local cronjobs or startup script workarounds on the firewall. For recurring tasks, external automation via supported interfaces is usually more stable, traceable, and better maintainable.

Is a heartbeat script on the firewall sensible?

Usually not. A monitoring system should monitor the firewall from the outside, not be dependent on the firewall itself. Otherwise, a local process can mask a problem or fail exactly when needed.

Should a Sophos Firewall be regularly restarted automatically?

No. Recurring restarts are a sign that a problem has not been properly resolved. It is better to analyse services, logs, storage, firmware status, and affected functions.

What is safer for recurring changes?

For recurring changes, external automation, XML API, Sophos Central, documented change processes, or specialised monitoring and configuration tools are better suited than local scripts on the firewall.

What is particularly important for HA clusters?

In HA, it must be clear on which node a local change exists and what happens after failover, firmware update, or restore. If this is not clearly documented and tested, no local special case should be used productively.