Sophos Firewall scripts without cron jobs: safe alternatives

Anyone who wants to run a command regularly on a Sophos Firewall will soon start looking for cron jobs, startup scripts or persistent shell files. However, the public SFOS administration documentation does not describe a general operating method for this. The firewall is a security appliance and should not become an automation server.

For configuration changes, XML API, Sophos Central or native SFOS functions are the better approach. External systems should monitor status and errors through Syslog, SNMP or sFlow. A local shell workaround belongs on a firewall only when Sophos publicly describes it for the specific case, or when Sophos Support or Professional Services assists with it.

⚠️ Important: A configuration backup is not proof that user-created files, startup mechanisms or background processes are backed up and will still be present after a restore, HA failover or firmware upgrade.

Quick decision

Before considering any technical solution, you must be clear about which task needs to be automated. This classification prevents a small script from quietly becoming a critical part of firewall operations.

If a script regularly restarts services, deletes files or resets connections, it is not an automation solution. It is probably masking a fault. Investigate the logs, storage, firmware version and specific error pattern first.

Why local scripts are problematic

A shell script can be technically small but still make operations difficult to control. It sits outside the normal WebAdmin configuration, often has no Audit Trail and may encounter different files, services or permissions after an update.

Four risks are particularly relevant:

• Backup and restore: Sophos describes the backup as a backup of the firewall configuration. There is no general restoration guarantee for custom shell files or startup mechanisms.
• HA: Sophos synchronises the configuration from the Primary to the Auxiliary. This must not be taken to mean that arbitrary local files or custom processes will work identically on both nodes.
• Firmware: An upgrade can change internal paths, services or runtime behaviour. A local modification must therefore be reassessed after every upgrade.
• Support: Sophos supports the official APIs and unmodified Sophos scripts. For custom integrations, Sophos refers customers to partners or Professional Services.

Other risks include plaintext secrets, uncontrolled log volumes, endless loops and troubleshooting where nobody can be certain whether SFOS or the local workaround is causing the behaviour.

Supported alternatives

Use a native SFOS function

First check whether SFOS already performs the task itself. Scheduled backups, notifications, routing, SD-WAN, monitoring and central logging belong in the menus provided for them. A recurring backup, for example, does not require a shell script; the schedule is configured under Backup & firmware > Backup & restore.

For routing or system traffic tasks, a properly designed policy will often help more than a command after every restart. The article SD-WAN routing for reply packets and system traffic explains the supported approach.

Manage multiple firewalls through Sophos Central

If several firewalls need the same policy, a Firewall Group in Sophos Central may be more appropriate than a custom script. The path is My Products > Firewall Management > Firewalls. Group policies are applied to the assigned firewalls; you can see their status under Tasks Queue.

Central groups are not simply a universal copy function. Local and centrally managed rules can affect each other’s order, and not every configuration can be represented in every group structure. Test with a test group first, then check the Tasks Queue and the rules that were actually applied.

Use XML API externally

For recurring changes to objects or policies, XML API is the intended programmatic method. The automation should run on a managed system where code, secrets, logs, schedules and rollback can be controlled.

Prepare the firewall as follows:

1. Under Profiles > Device access, create an admin profile with only the permissions that are actually required and save it with Save.
2. Under Authentication > Users, click Add, set User type to Administrator, select the new profile, deliberately restrict Login restriction for device access and save with Save.
3. Under Hosts and services > IP host, create a tightly scoped host object for the automation system.
4. Under Administration > API access, select API access.
5. Under Allowed IP hosts, select only the host object you prepared, add it with the Add button and save with Apply. SFOS allows a maximum of 64 entries here.
6. Under Administration > Device access, check whether HTTPS is allowed from the required zone. For WAN access, use a tightly scoped Local service ACL exception rule rather than enabling HTTPS generally for WAN.

API access is disabled by default. After an upgrade to SFOS 22.0, previously allowed IP addresses are converted into host objects with the prefix apiconfig; include these legacy permissions in the next access review.

The article Secure Sophos Firewall XML API access covers service accounts, MFA behaviour, the admin port, Local Service ACL and protecting secrets in detail. Sophos Firewall Config Studio can also help when preparing or comparing configuration changes.

⚠️ API access is not automatically secure: Restrict the source IP, do not use a personal full administrator account, do not store secrets in a repository, ticket or shell history, and test write operations in a test environment first.

Run monitoring outside the firewall

A monitoring system should observe the firewall from the outside. Otherwise, the local process may be unavailable precisely when the firewall itself is experiencing a fault. Depending on the objective, use SNMP hardware monitoring, sFlow monitoring or Central Firewall Reporting.

For longer-term event and security analysis, an external Syslog or SIEM receiver is more appropriate than additional local log files. This keeps the data available even if the firewall restarts, fails or is replaced.

When a local workaround may be acceptable

Some support cases or cloud deployments require a tightly scoped workaround. What matters is not whether the command technically works, but whether there are current Sophos instructions or confirmed support guidance for that exact scenario.

Before implementation, the version, platform, HA mode and rollback method must match the instructions. A script from an old Community post, another appliance model or an earlier SFOS version is not reliable approval for your own environment.

If only a custom solution exists, discuss it with the Sophos partner or Professional Services first. Generic instructions for adding custom startup scripts would be more dangerous than helpful here.

Safely replace an existing script

Do not delete an existing script immediately. First establish which operational dependency relies on it.

1. Freeze changes: Do not make any further changes to the script, startup mechanism or affected firewall initially.
2. Record its purpose: Document the symptom, trigger, required outcome, path, user, schedule, secrets and responsible person.
3. Observe its effect: Record logs, process status, generated files and any routes, services or interfaces it affects. For HA, check both nodes separately.
4. Choose the target method: Assign the function to a native SFOS setting, Central, XML API or external monitoring.
5. Test the replacement: Test the new process outside the production firewall and record success, errors and rollback.
6. Migrate in a controlled manner: Activate the replacement during a maintenance window, disable the local script and perform the functional test.
7. Plan follow-up checks: Check again after a restart, failover and the next firmware upgrade, where these events are relevant to the function.

A current backup is required before the change. Create or restore a Sophos Firewall backup explains the Secure Storage Master Key, restore and compatibility. The backup protects the documented configuration, but it does not replace a separate inventory of local modifications.

Validation and rollback

A successful API response or a running process does not prove that the operational task has been completed. After the migration, test the exact result that previously depended on the script: rule present, route active, backup created, destination reachable or alert received by the monitoring system.

For API changes, also check the Audit Trail and affected objects. If traffic is affected, include Log Viewer, Rule ID, NAT Rule ID, Policy Test or Packet Capture in the acceptance test. Check Central changes in the Tasks Queue and then directly on an affected firewall.

Rollback does not mean re-enabling the old script prematurely. First reverse the new change and restore the documented initial state. Only if the old workaround has been deliberately tested as a fallback may it be reactivated for a limited period.

Operational recommendation

Local scripts should appear in the operations documentation as temporary exceptions, not as normal firewall functions. Every exception needs an owner, a review date, a tested rollback method and a clear statement of which Sophos versions are covered.

For new requirements, follow this order: native SFOS function, Sophos Central, external XML API automation, external monitoring and only then a special case confirmed by Sophos. This keeps changes traceable, makes HA and restore more predictable, and keeps the firewall closer to the supported product state.

FAQ