Sophos Firewall XML API Zugriff absichern

Die XML API der Sophos Firewall ist praktisch für Automatisierung, Monitoring, Backups, Auswertungen und Integrationen. Genau deshalb gehört sie aber auch zur Management-Angriffsfläche. Wer API-Zugriff erlaubt, gibt einem System die Möglichkeit, Konfigurationsdaten zu lesen oder je nach Berechtigung Änderungen vorzunehmen.

API-Zugriff sollte deshalb nicht breit aus internen Netzen oder von beliebigen Quellen erlaubt werden. Besser ist ein kleines, dokumentiertes Set aus Management-Netzen, Automations-Hosts oder festen Partnerzugängen.

Seit SFOS 22 hat Sophos die API-Zugriffskontrolle erweitert. Die API access settings befinden sich unter Administration > API access, und erlaubte Quellen können als IP Hosts definiert werden. Dadurch lassen sich nicht nur einzelne IP-Adressen, sondern auch IP ranges und Netzwerke sauber modellieren.

Auf älteren SFOS-Versionen lag die API-Konfiguration unter Backup and firmware > API. Bei gemischten Kundenumgebungen sollte man deshalb zuerst die SFOS-Version prüfen, bevor man eine Anleitung oder ein Skript unverändert übernimmt.

Wann XML API Zugriff sinnvoll ist

Die XML API ist kein Standardzugang für normale Admin-Arbeit. Sinnvoll ist der Einsatz, wenn ein konkreter technischer Prozess dahintersteht.

Typische Anwendungsfälle:

• Monitoring oder Inventarisierung.
• Automatisierte Konfigurationsprüfungen.
• Backup- oder Dokumentationsprozesse.
• MSP- oder Integrationsplattformen.
• Skripte für wiederkehrende administrative Aufgaben.
• Vorbereitete Änderungen aus Tools wie Sophos Firewall Config Studio.

Wenn ein Prozess auch ohne API auskommt, sollte API-Zugriff nicht vorsorglich aktiviert bleiben. Jede zusätzliche Schnittstelle braucht einen Besitzer, eine Quelle, ein Zugriffskonzept und eine Kontrolle.

Was sich mit SFOS 22 geändert hat

Mit SFOS 22 wurde die XML API Zugriffskontrolle für den Betrieb deutlich besser handhabbar:

• Die API access settings wurden in das Menü Administration > API access verschoben.
• API access ist standardmässig deaktiviert und muss bewusst eingeschaltet werden.
• API access kann auf IP Hosts beschränkt werden.
• Als Quellen sind dadurch IP-Adressen, IP ranges und Netzwerke möglich.
• Bis zu 64 IP Hosts können erlaubt werden.
• Beim Upgrade werden bisher erlaubte IP-Adressen automatisch in IP Host Objekte umgewandelt.
• Migrierte Objekte erhalten den Prefix apiconfig.

Das ist für den Betrieb hilfreich, weil API-Quellen nicht mehr nur als lose Einzeladressen gepflegt werden müssen. Man kann ein Management-Netz, einen Automations-Host oder eine dedizierte Host-Gruppe sauber benennen und später in Reviews wiedererkennen.

Grundregel: API nur aus definierten Quellen erlauben

API access sollte nach dem gleichen Prinzip behandelt werden wie WebAdmin oder SSH: so eng wie möglich, so breit wie nötig.

Sinnvolle Quellen sind zum Beispiel:

• ein dedizierter Automationsserver,
• ein Monitoring-System,
• ein Konfigurationsmanagement-Host,
• ein internes Management-Netz,
• ein VPN- oder Admin-Netz,
• eine klar definierte Partner- oder MSP-Quelladresse.

Nicht sinnvoll sind:

• ganze Client-Netze,
• Gast- oder IoT-Netze,
• Any,
• unklare “Servernetz komplett”-Freigaben,
• temporäre Test-IP-Adressen, die später vergessen werden.

Wenn externe Dienstleister API-Zugriff brauchen, sollte die Quelle so spezifisch wie möglich definiert werden. Zusätzlich sollte dokumentiert sein, wofür der Zugriff verwendet wird und wann er wieder entfernt wird.

Empfohlener Ablauf

Der genaue UI-Pfad kann je nach SFOS-Version leicht variieren. In SFOS 22 liegt die API-Konfiguration unter Administration > API access.

Praktischer Ablauf:

1. Prüfen, welches System API-Zugriff benötigt.
2. Unter Hosts and services > IP host ein eindeutiges IP Host Objekt für dieses System erstellen.
3. Wenn mehrere Quellen nötig sind, IP Hosts, IP ranges oder Netzwerke sauber benennen.
4. Unter Administration > API access API access aktivieren.
5. Unter Allowed IP hosts nur diese Objekte erlauben.
6. Apply anklicken.
7. Keine breiten Client- oder Servernetze eintragen.
8. Zugriff vom echten Automations- oder Monitoring-Host testen, nicht vom Admin-Notebook.
9. Nicht mehr benötigte Quellen wieder entfernen.
10. Änderung im Change-Prozess dokumentieren.

Bei bestehenden Installationen nach einem Upgrade auf SFOS 22 sollte man zusätzlich nach Objekten mit dem Prefix apiconfig suchen. Diese Objekte wurden aus älteren API-Allow-Einträgen erzeugt und sollten geprüft, benannt oder bereinigt werden.

Zugriff gezielt testen

Der API-Endpunkt liegt typischerweise unter:

https://<Firewall-IP-oder-Hostname>:<Port>/webconsole/APIController

Der Port ist der HTTPS-Port der WebAdmin Console. Wenn der Admin-Port unter Administration > Admin settings angepasst wurde, muss das API-Tool denselben Port verwenden. Die API arbeitet mit XML-Payloads über HTTP POST, nicht wie eine klassische REST-API mit getrennten GET-, POST-, PUT- und DELETE-Endpunkten.

Ein sinnvoller Test beantwortet nicht nur die Frage, ob ein Login grundsätzlich möglich ist. Er sollte zeigen, ob die richtige Quelle erlaubt ist, ob das Konto die benötigte Operation ausführen darf und ob das Ergebnis im Audit- oder Change-Prozess nachvollziehbar bleibt.

Für die Abnahme sollte man diese Punkte getrennt prüfen:

• Quelle: Der Test läuft vom echten Automations-, Monitoring- oder Integrationshost, nicht vom Admin-Notebook.
• Zugriff: Die Firewall akzeptiert die Quell-IP nur, wenn das passende IP Host Objekt in API access erlaubt ist.
• Konto: Das verwendete API- oder Servicekonto hat nur die benötigten Rechte.
• Secret: Benutzername, Passwort oder Token landen nicht in Shell-History, Tickets, Chatverläufen oder Screenshots.
• Audit: Der Zugriff oder die Änderung ist im Audit- oder Change-Prozess nachvollziehbar.
• Rollback: Vor Schreiboperationen existieren Backup, Rollback-Punkt und ein ungefährlicher Lesetest.

Gerade curl-Beispiele mit Benutzername und Passwort in der URL sind schnell kopiert und später schwer wieder aus Protokollen zu entfernen. Besser ist ein kurzer Test mit dediziertem Servicekonto, temporärem Test-Secret, sicherer Ablage und anschliessender Rotation, wenn ein Secret in einem unsicheren Kontext verwendet wurde.

Für strukturierte Tests ist eine Postman-Collection oft sauberer als ein schnell kopierter Shell-Befehl. Auch dort sollten Firewall-Adresse, Port, Benutzername, Passwort und Objektwerte als Variablen oder Secrets gepflegt werden, nicht hart in Requests, Screenshots oder Tickets stehen. Die Collection ist kein Sicherheitskonzept, hilft aber, Lese- und Schreiboperationen reproduzierbarer zu testen.

Eine API, die erreichbar ist, ist noch kein Beweis, dass die geplante Änderung fachlich sicher ist. Vor produktiven Schreiboperationen sollte deshalb zuerst eine ungefährliche Leseabfrage funktionieren und danach eine kleine, kontrollierte Änderung getestet werden.

API-Zugriff und Benutzerrechte

Eine Quell-IP allein ist kein vollständiges Sicherheitskonzept. Die Einschränkung begrenzt nur, von wo die API erreichbar ist. Zusätzlich muss klar sein, mit welchem Konto der API-Zugriff erfolgt und welche Rechte dieses Konto hat.

Für produktive Umgebungen sollte man prüfen:

• Wird ein eigenes API- oder Servicekonto verwendet?
• Hat das Konto nur die benötigten Berechtigungen?
• Ist klar dokumentiert, welche Person oder welches Team für das Konto verantwortlich ist?
• Wird das Passwort oder Secret sicher gespeichert?
• Wird der Zugriff entfernt, wenn die Integration nicht mehr genutzt wird?
• Sind Änderungen über Audit Logs nachvollziehbar?

Geteilte Admin-Konten sind für API-Prozesse problematisch. Wenn mehrere Systeme oder Personen denselben Account verwenden, wird die Nachvollziehbarkeit schwächer. Für Change-Analysen ist Sophos Firewall Audit Trail Logs prüfen relevant.

Für ein dediziertes API-Konto ist ein enger Ablauf besser als ein schnell kopierter Volladmin. In der Sophos-Dokumentation taucht dafür sinngemäss der Baustein Allow API access to administrators auf: Nicht nur die Quelle wird erlaubt, sondern auch der Administrator beziehungsweise das Profil muss den passenden Zugriff besitzen.

1. Unter Profiles > Device access ein Administratorprofil mit den benötigten Rechten erstellen.
2. Unter Authentication > Users einen Administratorbenutzer für den API-Prozess anlegen.
3. Das passende Administratorprofil zuweisen.
4. Wenn der Zugriff nur temporär gebraucht wird, Access time begrenzen.
5. Wenn möglich Login restriction for device access auf die vorgesehenen Quellen begrenzen.
6. Danach API access und Device Access passend zur Quelle freigeben.

Sophos unterstützt die offiziellen APIs und unveränderte Beispielskripte. Eigene Integrationen, Wrapper und Automationen brauchen trotzdem einen internen Besitzer, Tests und ein Rollback-Konzept. Ein “funktioniert im Lab” reicht für produktive Schreiboperationen nicht.

MFA und API-Benutzer nach SFOS 22

MFA ist für interaktive Administratorzugänge wichtig. Für API- und Automationsprozesse muss man aber bewusst planen, wie Authentifizierung funktionieren soll. Ein Skript, Monitoring-Tool oder Integrationssystem kann nicht ohne Weiteres einen OTP-Code eingeben, wenn der verwendete Benutzer MFA erzwingt.

In der Known-Issues-Liste ist ein SFOS-22-Sonderfall dokumentiert: Nach einem Upgrade können API-basierte Konfigurationsänderungen bei migrierten Benutzern fehlschlagen, wenn MFA aktiv ist und kein One-time Token übergeben wird. Nicht migrierte Benutzer können sich in bestimmten Fällen anders verhalten. Für den Betrieb ist wichtig, dass man daraus kein unsauberes “MFA überall aus” macht, sondern API-Konten sauber trennt.

Empfohlener Ansatz:

1. Für API-Prozesse ein eigenes Servicekonto verwenden.
2. Das Konto nur mit den benötigten Rechten ausstatten.
3. API access zusätzlich auf feste IP Hosts oder Management-Netze begrenzen.
4. Prüfen, ob MFA für dieses Konto technisch und betrieblich sinnvoll ist.
5. Wenn MFA für das API-Konto nicht praktikabel ist, das Konto besonders eng über Quelle, Rechte, Secret-Ablage und Audit Trail kontrollieren.
6. Nach einem SFOS-22-Upgrade alle API-Prozesse mit Lese- und Schreiboperationen testen.

⚠️ API-Benutzer ohne MFA sind kein Freipass für breite Rechte. Wenn ein API-Konto aus technischen Gründen ohne MFA betrieben wird, müssen Quell-IP, Rechte, Passwortablage, Verantwortlichkeit und Auditierbarkeit enger kontrolliert werden.

Besonders wichtig ist dieser Punkt bei Automationen, die nicht nur lesen, sondern Konfiguration ändern.

Vor produktiven API-Änderungen sollte man mindestens drei Dinge prüfen:

• Ein aktuelles Backup der Sophos Firewall ist vorhanden.
• Das geplante API-Konto kann eine ungefährliche Leseabfrage erfolgreich ausführen.
• Bei vorbereiteten Massenänderungen aus Sophos Firewall Config Studio funktionieren die erzeugten API- oder curl-Aufrufe mit dem geplanten Konto.

Abgrenzung zu Device Access

Die API-Zugriffskontrolle ist nicht dasselbe wie Device Access, beide Kontrollen greifen aber ineinander. Device Access steuert lokale Firewall-Dienste wie WebAdmin, SSH, User Portal, VPN Portal, DNS oder Ping. Die API access settings steuern zusätzlich, welche IP Hosts die XML API nutzen dürfen. Wichtig: Die Device-Access-Berechtigungen für die WebAdmin Console gelten auch für API-Zugriffe.

Für die Praxis bedeutet das: API access muss erlaubt sein, die Quelle muss in den API access settings zugelassen sein, und der lokale Managementzugriff zur Firewall darf nicht durch Device Access blockiert werden. Jede Schicht begrenzt einen anderen Teil der Angriffsfläche:

• Device Access richtig konfigurieren: begrenzt lokale Firewall-Dienste wie WebAdmin, SSH, User Portal, VPN Portal, DNS oder Ping.
• API access control: begrenzt die IP Hosts, die die XML API zusätzlich nutzen dürfen.
• MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren: schützt interaktive Logins für WebAdmin, VPN Portal und Remote Access.
• Named Admins und klare Rollen: verbessern Nachvollziehbarkeit und begrenzen den Schadensradius von Admin- und Servicekonten.

Wenn ein Admin-Netz WebAdmin, SSH und API nutzen darf, sollte dieses Netz besonders gut geschützt sein. Ein kompromittierter Client im Management-Netz ist sonst ein direkter Einstieg in die Firewall-Verwaltung.

Bei WAN-Zugriff sollte man nicht die ganze WAN-Zone für HTTPS/WebAdmin öffnen. Wenn externer API- oder Admin-Zugriff wirklich nötig ist, gehört er in eine Local service ACL exception rule mit enger Source, passendem Service HTTPS, definierter Regelposition und dokumentiertem Zeitraum.

Betrieb und Review

API-Zugriff sollte regelmässig überprüft werden. Besonders nach Migrationen, Dienstleisterwechseln, Automationsprojekten oder Firewall-Upgrades bleiben oft alte Quellen stehen.

Sinnvolle Review-Fragen:

• Welche IP Hosts dürfen aktuell API access nutzen?
• Gibt es Objekte mit dem Prefix apiconfig?
• Sind diese Objekte noch notwendig?
• Stimmen Namen und Beschreibungen mit dem tatsächlichen Zweck überein?
• Gibt es dokumentierte Verantwortliche?
• Werden API-Zugriffe in einem Change- oder Audit-Prozess berücksichtigt?
• Gibt es ein aktuelles Backup vor grösseren API-basierten Änderungen?

Vor API-basierten Änderungen sollte immer ein Backup vorhanden sein. Der Artikel Sophos Firewall Backup erstellen oder wiederherstellen beschreibt, worauf man bei Backup, Restore und Kompatibilität achten sollte.

Typische Fehler

• API access für ein ganzes Client-Netz erlaubt: Jeder kompromittierte Client aus diesem Netz kann die API erreichen.
• Alte apiconfig Objekte nicht geprüft: Migrierte Altfreigaben bleiben unbemerkt aktiv.
• Servicekonto nutzt volle Adminrechte: Ein kompromittiertes Secret hat unnötig grossen Schadenradius.
• API-Automation nutzt einen MFA-pflichtigen Admin: Skript oder Tool kann nach SFOS-Upgrade bei Schreiboperationen fehlschlagen.
• Falscher Port im Tool: Der Admin-HTTPS-Port wurde geändert, das Tool nutzt aber weiter den alten Port.
• REST-Logik erwartet: Das Tool sendet REST-Methoden statt XML-Payload über HTTP POST an APIController.
• Temporäre Dienstleister-IP bleibt aktiv: Externer Zugriff bleibt länger möglich als geplant.
• Keine Dokumentation zum Zweck: Spätere Admins wissen nicht, ob eine Freigabe noch gebraucht wird.
• API-Änderungen ohne Backup: Fehlerhafte Automatisierung ist schwerer zurückzurollen.

Troubleshooting

Wenn ein Tool die XML API nicht erreicht, sollte man strukturiert prüfen:

1. Stimmt die Quell-IP aus Sicht der Firewall?
2. Ist die Quelle als IP Host, IP range oder Netzwerk erlaubt?
3. Wurde nach einem Upgrade ein apiconfig Objekt erzeugt, aber nicht passend angepasst?
4. Erlaubt Device Access den lokalen WebAdmin/API-Zugriff aus dieser Zone?
5. Verwendet das Tool die richtige Firewall-Adresse und den richtigen Admin-HTTPS-Port?
6. Stimmen Benutzername, Passwort oder Secret?
7. Hat das Konto die benötigten Rechte?
8. Erzwingt das Konto MFA, obwohl das Tool keinen One-time Token übergeben kann?
9. Gibt es Routing-, NAT- oder Proxy-Effekte zwischen Tool und Firewall?
10. Wurde der Zugriff absichtlich durch eine Härtungsmassnahme entfernt?
11. Wurde vom richtigen Quellsystem getestet oder nur vom Admin-Client?

Wenn eine API-Änderung unerwartete Auswirkungen hat, zuerst das letzte Backup sichern und danach Audit Trail, Config Studio Vergleich und betroffene Firewall-Objekte prüfen. Bei Live-Traffic-Problemen helfen Log Viewer und Packet Capture eher als die API selbst.

Checkliste

Vor Aktivierung:

• Zweck des API-Zugriffs dokumentieren.
• Quellsystem eindeutig bestimmen.
• IP Host Objekt mit sprechendem Namen erstellen.
• Servicekonto und Berechtigungen prüfen.
• MFA-Verhalten des API-Kontos bewusst festlegen.
• Backup- und Rollback-Prozess festlegen.
• Testmethode ohne Secret-Leak festlegen.

Beim Betrieb:

• API access nur für definierte Quellen erlauben.
• Keine breiten Client-, Gast- oder IoT-Netze freigeben.
• apiconfig Objekte nach Upgrades prüfen.
• Dienstleisterzugänge zeitlich und fachlich kontrollieren.
• Secrets geschützt speichern und bei Personal- oder Toolwechsel erneuern.
• Secrets rotieren, wenn sie in Shell-History, Tickets oder unsicheren Ablagen gelandet sind.
• API-Lese- und Schreiboperationen nach SFOS-Upgrades gezielt testen.

Beim Review:

• Erlaubte API-Quellen regelmässig prüfen.
• Nicht mehr benötigte IP Hosts entfernen.
• Änderungen mit Audit Trail und Change-Tickets abgleichen.
• Automationsprozesse nach Firmware-Updates testen.

FAQ