Securing Sophos Firewall XML API Access

The XML API of the Sophos Firewall is useful for automation, monitoring, backups, evaluations, and integrations. For this reason, it is also part of the management attack surface. Allowing API access gives a system the ability to read configuration data or make changes depending on permissions.

API access should therefore not be broadly allowed from internal networks or arbitrary sources. It is better to have a small, documented set of management networks, automation hosts, or fixed partner accesses.

Since SFOS 22, Sophos has expanded API access control. The API access settings are located in the Administration section, and allowed sources can be defined as IP hosts. This allows not only individual IP addresses but also IP ranges and networks to be cleanly modeled.

When XML API Access is Useful

The XML API is not a standard access for normal admin work. Its use is sensible when there is a specific technical process behind it.

Typical use cases:

• Monitoring or inventory.
• Automated configuration checks.
• Backup or documentation processes.
• MSP or integration platforms.
• Scripts for recurring administrative tasks.
• Prepared changes from tools like Sophos Firewall Config Studio.

If a process can manage without the API, API access should not remain enabled as a precaution. Every additional interface needs an owner, a source, an access concept, and control.

What Changed with SFOS 22

With SFOS 22, XML API access control has become significantly more manageable for operations:

• The API access settings have been moved to the Administration menu.
• API access can be restricted to IP hosts.
• As sources, IP addresses, IP ranges, and networks are possible.
• Up to 64 IP hosts can be allowed.
• During the upgrade, previously allowed IP addresses are automatically converted into IP host objects.
• Migrated objects receive the prefix apiconfig.

This is helpful for operations because API sources no longer need to be maintained as loose individual addresses. A management network, an automation host, or a dedicated host group can be cleanly named and later recognized in reviews.

Basic Rule: Allow API Only from Defined Sources

API access should be treated in the same way as WebAdmin or SSH: as narrow as possible, as broad as necessary.

Sensible sources include:

• a dedicated automation server,
• a monitoring system,
• a configuration management host,
• an internal management network,
• a VPN or admin network,
• a clearly defined partner or MSP source address.

Not sensible are:

• entire client networks,
• guest or IoT networks,
• Any,
• unclear “server network complete” permissions,
• temporary test IP addresses that are later forgotten.

If external service providers need API access, the source should be defined as specifically as possible. Additionally, it should be documented what the access is used for and when it will be removed.

Recommended Procedure

The exact UI path may vary slightly depending on the SFOS version. In SFOS 22, the API configuration is under Administration.

Practical procedure:

1. Check which system needs API access.
2. Create a unique IP host object for this system.
3. If multiple sources are needed, name IP hosts or networks clearly.
4. Allow API access only for these objects.
5. Do not enter broad client or server networks.
6. Test access with the affected tool.
7. Remove sources that are no longer needed.
8. Document changes in the change process.

For existing installations after an upgrade to SFOS 22, you should also search for objects with the prefix apiconfig. These objects were created from older API allow entries and should be checked, named, or cleaned up.

API Access and User Rights

A source IP alone is not a complete security concept. The restriction only limits from where the API is reachable. Additionally, it must be clear which account is used for API access and what rights this account has.

For productive environments, you should check:

• Is a separate API or service account used?
• Does the account have only the necessary permissions?
• Is it clearly documented which person or team is responsible for the account?
• Is the password or secret stored securely?
• Is access removed when the integration is no longer used?
• Are changes traceable through audit logs?

Shared admin accounts are problematic for API processes. If multiple systems or people use the same account, traceability is weaker. For change analyses, checking Sophos Firewall Audit Trail Logs is relevant.

MFA and API Users After SFOS 22

MFA is important for interactive administrator access. For API and automation processes, you must consciously plan how authentication should work. A script, monitoring tool, or integration system cannot easily enter an OTP code if the user enforces MFA.

A special case in the known issues list for SFOS 22 is documented: After an upgrade, API-based configuration changes may fail for migrated users if MFA is active and no one-time token is provided. Non-migrated users may behave differently in certain cases. For operations, it is important not to make an unclean “MFA off everywhere” decision, but to separate API accounts cleanly.

Recommended approach:

1. Use a dedicated service account for API processes.
2. Equip the account only with the necessary rights.
3. Additionally limit API access to fixed IP hosts or management networks.
4. Check whether MFA is technically and operationally sensible for this account.
5. If MFA is not practical for the API account, control the account particularly tightly through source, rights, secret storage, and audit trail.
6. After an SFOS 22 upgrade, test all API processes with read and write operations.

⚠️ API users without MFA are not a free pass for broad rights. If an API account is operated without MFA for technical reasons, source IP, rights, password storage, responsibility, and auditability must be more tightly controlled.

This point is particularly important for automations that not only read but also change configurations. Before productive API changes, a current backup of the Sophos Firewall should be available. For prepared mass changes from Sophos Firewall Config Studio, you should also check whether the generated API or curl calls work with the planned account.

Distinction from Device Access

API access control is not the same as Device Access. Device Access controls local firewall services such as WebAdmin, SSH, User Portal, VPN Portal, DNS, or Ping. The API access settings, on the other hand, control access to the management interface of the XML API.

Nevertheless, both topics belong together in management hardening. Each layer limits a different part of the attack surface:

If an admin network is allowed to use WebAdmin, SSH, and API, this network should be particularly well protected. A compromised client in the management network is otherwise a direct entry into firewall management.

Operation and Review

API access should be regularly reviewed. Especially after migrations, service provider changes, automation projects, or firewall upgrades, old sources often remain.

Sensible review questions:

• Which IP hosts are currently allowed API access?
• Are there objects with the prefix apiconfig?
• Are these objects still necessary?
• Do names and descriptions match the actual purpose?
• Are there documented responsible parties?
• Are API accesses considered in a change or audit process?
• Is there a current backup before major API-based changes?

Before API-based changes, a backup should always be available. The article Create or restore a Sophos Firewall backup describes what to consider for backup, restore, and compatibility.

Typical Errors

Troubleshooting

If a tool does not reach the XML API, you should check systematically:

1. Does the source IP match from the firewall’s perspective?
2. Is the source allowed as an IP host, IP range, or network?
3. Was an apiconfig object created after an upgrade but not properly adjusted?
4. Does the tool use the correct firewall address and port?
5. Do username, password, or secret match?
6. Does the account have the necessary rights?
7. Does the account enforce MFA, although the tool cannot provide a one-time token?
8. Are there routing, NAT, or proxy effects between the tool and the firewall?
9. Was access intentionally removed by a hardening measure?

If an API change has unexpected effects, first secure the last backup and then check the audit trail, Config Studio comparison, and affected firewall objects. For live traffic problems, Log Viewer and Packet Capture are more helpful than the API itself.

Checklist

Before activation:

• Document the purpose of API access.
• Clearly determine the source system.
• Create an IP host object with a descriptive name.
• Check service account and permissions.
• Deliberately set the MFA behavior of the API account.
• Establish a backup and rollback process.

During operation:

• Allow API access only for defined sources.
• Do not allow broad client, guest, or IoT networks.
• Check apiconfig objects after upgrades.
• Control service provider accesses temporally and technically.
• Store secrets securely and renew them when personnel or tools change.
• Specifically test API read and write operations after SFOS upgrades.

During review:

• Regularly check allowed API sources.
• Remove IP hosts that are no longer needed.
• Match changes with audit trail and change tickets.
• Test automation processes after firmware updates.

FAQ