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 im Bereich Administration, 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.

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 verschoben.
• 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.

Praktischer Ablauf:

1. Prüfen, welches System API-Zugriff benötigt.
2. Für dieses System ein eindeutiges IP Host Objekt erstellen.
3. Wenn mehrere Quellen nötig sind, IP Hosts oder Netzwerke sauber benennen.
4. API access nur für diese Objekte erlauben.
5. Keine breiten Client- oder Servernetze eintragen.
6. Zugriff mit dem betroffenen Tool testen.
7. Nicht mehr benötigte Quellen wieder entfernen.
8. Ä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.

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.

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 ein aktuelles Backup der Sophos Firewall vorhanden sein. Bei vorbereiteten Massenänderungen aus Sophos Firewall Config Studio sollte man zusätzlich prüfen, ob die erzeugten API- oder curl-Aufrufe mit dem geplanten Konto funktionieren.

Abgrenzung zu Device Access

Die API-Zugriffskontrolle ist nicht dasselbe wie Device Access. Device Access steuert lokale Firewall-Dienste wie WebAdmin, SSH, User Portal, VPN Portal, DNS oder Ping. Die API access settings steuern dagegen den Zugriff auf die Verwaltungsschnittstelle der XML API.

Trotzdem gehören beide Themen zusammen zur Management-Härtung. Jede Schicht begrenzt einen anderen Teil der Angriffsfläche:

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.

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

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. Verwendet das Tool die richtige Firewall-Adresse und den richtigen Port?
5. Stimmen Benutzername, Passwort oder Secret?
6. Hat das Konto die benötigten Rechte?
7. Erzwingt das Konto MFA, obwohl das Tool keinen One-time Token übergeben kann?
8. Gibt es Routing-, NAT- oder Proxy-Effekte zwischen Tool und Firewall?
9. Wurde der Zugriff absichtlich durch eine Härtungsmassnahme entfernt?

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.

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.
• 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