Sophos Firewall Skripte ohne Cronjob: sichere Alternativen
Wer auf einer Sophos Firewall regelmässig einen Befehl ausführen möchte, sucht schnell nach Cronjobs, Startskripten oder persistenten Shell-Dateien. Die öffentliche SFOS-Administration dokumentiert dafür jedoch keinen allgemeinen Betriebsweg. Die Firewall ist eine Security Appliance und sollte nicht zum Automatisierungsserver werden.
Für Konfigurationsänderungen sind die XML API, Sophos Central oder native SFOS-Funktionen der bessere Weg. Zustände und Fehler sollten externe Systeme über Syslog, SNMP oder sFlow überwachen. Ein lokaler Shell-Workaround gehört nur dann auf eine Firewall, wenn Sophos ihn für den konkreten Fall öffentlich beschreibt oder Sophos Support beziehungsweise Professional Services ihn begleitet.
⚠️ Wichtig: Ein Konfigurationsbackup ist kein Beleg dafür, dass selbst angelegte Dateien, Startmechanismen oder Hintergrundprozesse gesichert und nach Restore, HA-Failover oder Firmware-Upgrade wieder vorhanden sind.
Schnellentscheidung
Vor jeder technischen Lösung muss klar sein, welche Aufgabe automatisiert werden soll. Diese Einordnung verhindert, dass ein kleines Skript unbemerkt zu einem kritischen Teil des Firewall-Betriebs wird.
| Aufgabe | Passender Betriebsweg |
|---|---|
| Wiederkehrende Konfigurationsänderung | XML API von einem kontrollierten Automatisierungssystem |
| Gleiche Policy auf mehreren Firewalls | Sophos Central Firewall Group |
| Regelmässiges Konfigurationsbackup | Zeitplan unter Backup & firmware > Backup & restore |
| Zustand, Traffic oder Fehler überwachen | Syslog, SNMP, sFlow oder Sophos Central Reporting |
| Einmalige Diagnose | WebAdmin, Device Console oder ein von Sophos dokumentierter Befehl |
| Produktspezifischer Workaround | Exakte Sophos-Anleitung oder bestätigter Supportfall |
Soll ein Skript regelmässig Dienste neu starten, Dateien löschen oder Verbindungen zurücksetzen, ist das keine Automatisierungslösung. Es kaschiert wahrscheinlich eine Störung. Dann zuerst Logs, Speicher, Firmwarestand und das konkrete Fehlerbild untersuchen.
Warum lokale Skripte problematisch sind
Ein Shell-Skript kann technisch klein sein und trotzdem den Betrieb schwer kontrollierbar machen. Es liegt ausserhalb der normalen WebAdmin-Konfiguration, hat oft keinen Audit Trail und kann nach einem Update mit anderen Dateien, Diensten oder Berechtigungen zusammentreffen.
Besonders relevant sind vier Risiken:
- Backup und Restore: Sophos beschreibt das Backup als Sicherung der Firewall-Konfiguration. Für eigene Shell-Dateien oder Startmechanismen gibt es keine allgemeine Wiederherstellungsgarantie.
- HA: Sophos synchronisiert die Konfiguration vom Primary zum Auxiliary. Daraus darf nicht abgeleitet werden, dass beliebige lokale Dateien oder selbst gebaute Prozesse auf beiden Nodes identisch funktionieren.
- Firmware: Ein Upgrade kann interne Pfade, Dienste oder Laufzeitverhalten ändern. Eine lokale Anpassung muss deshalb nach jedem Upgrade neu bewertet werden.
- Support: Sophos unterstützt die offiziellen APIs und unveränderte Sophos-Skripte. Für selbst entwickelte Integrationen verweist Sophos auf Partner oder Professional Services.
Hinzu kommen Secrets im Klartext, unkontrollierte Logmengen, Endlosschleifen und eine Fehlersuche, bei der niemand mehr sicher weiss, ob SFOS oder der lokale Workaround das Verhalten verursacht.
Unterstützte Alternativen
Native SFOS-Funktion verwenden
Zuerst prüfen, ob SFOS die Aufgabe bereits selbst erledigt. Zeitgesteuerte Backups, Benachrichtigungen, Routing, SD-WAN, Monitoring und zentrale Protokollierung gehören in die dafür vorgesehenen Menüs. Für ein wiederkehrendes Backup wird beispielsweise kein Shell-Skript benötigt; der Zeitplan liegt unter Backup & firmware > Backup & restore.
Bei Routing- oder System-Traffic-Aufgaben hilft häufig eine saubere Policy statt eines Befehls nach jedem Neustart. Der Artikel SD-WAN Routing für Reply Packets und System Traffic erklärt den unterstützten Weg.
Mehrere Firewalls über Sophos Central verwalten
Wenn mehrere Firewalls dieselbe Policy erhalten sollen, kann eine Firewall Group in Sophos Central besser passen als ein eigenes Skript. Der Pfad lautet My Products > Firewall Management > Firewalls. Gruppenrichtlinien werden auf die zugewiesenen Firewalls angewendet; den Status sieht man unter Tasks Queue.
Central-Gruppen sind nicht einfach eine universelle Kopierfunktion. Lokale und zentral verwaltete Regeln können sich in der Reihenfolge beeinflussen, und nicht jede Konfiguration lässt sich in jeder Gruppenstruktur abbilden. Deshalb zuerst mit einer Testgruppe prüfen und danach die Task Queue sowie die tatsächlich angewendeten Regeln kontrollieren.
XML API von extern nutzen
Für wiederkehrende Änderungen an Objekten oder Policies ist die XML API der vorgesehene programmatische Weg. Die Automatisierung sollte auf einem verwalteten System laufen, auf dem Code, Secrets, Logs, Zeitplan und Rollback kontrolliert werden können.
Die Firewall-Seite wird so vorbereitet:
- Unter Profiles > Device access ein Admin-Profil mit den wirklich benötigten Rechten erstellen und mit Save sichern.
- Unter Authentication > Users auf Add klicken, User type auf Administrator setzen, das neue Profil auswählen, Login restriction for device access bewusst begrenzen und mit Save sichern.
- Unter Hosts and services > IP host das Automatisierungssystem als enges Host-Objekt erfassen.
- Unter Administration > API access API access auswählen.
- Unter Allowed IP hosts nur das vorbereitete Host-Objekt auswählen, mit dem Add-Button hinzufügen und mit Apply speichern. SFOS erlaubt hier maximal 64 Einträge.
- Unter Administration > Device access prüfen, ob HTTPS aus der benötigten Zone zugelassen ist. Für WAN-Zugriff besser eine enge Local service ACL exception rule verwenden als HTTPS pauschal für WAN zu öffnen.
API access ist standardmässig ausgeschaltet. Nach einem Upgrade auf SFOS 22.0 werden frühere erlaubte IP-Adressen in Host-Objekte mit dem Präfix apiconfig umgewandelt; diese Altfreigaben gehören in den nächsten Zugriffsreview.
Der Artikel Sophos Firewall XML API Zugriff absichern behandelt Servicekonto, MFA-Verhalten, Admin-Port, Local Service ACL und Secret-Schutz ausführlich. Für vorbereitete oder verglichene Konfigurationsänderungen kann zusätzlich Sophos Firewall Config Studio helfen.
⚠️ API ist nicht automatisch sicher: Die Quell-IP begrenzen, kein persönliches Volladmin-Konto verwenden, Secrets nicht in Repository, Ticket oder Shell-History ablegen und Schreiboperationen zuerst in einer Testumgebung prüfen.
Monitoring ausserhalb der Firewall betreiben
Ein Monitoring-System sollte die Firewall von aussen beobachten. Sonst kann der lokale Prozess genau dann fehlen, wenn die Firewall selbst gestört ist. Je nach Ziel passen SNMP Hardware Monitoring, sFlow Monitoring oder Central Firewall Reporting.
Für längerfristige Ereignis- und Sicherheitsanalyse ist ein externer Syslog- oder SIEM-Empfänger sinnvoller als zusätzliche lokale Logdateien. Dadurch bleiben Daten auch dann verfügbar, wenn die Firewall neu startet, ausfällt oder ersetzt wird.
Wann ein lokaler Workaround vertretbar sein kann
Manche Supportfälle oder Cloud-Deployments benötigen einen eng begrenzten Workaround. Entscheidend ist nicht, ob der Befehl technisch funktioniert, sondern ob es für genau dieses Szenario eine aktuelle Sophos-Anleitung oder eine bestätigte Supportanweisung gibt.
Vor der Umsetzung müssen Version, Plattform, HA-Modus und Rückbauweg zur Anleitung passen. Ein Skript aus einem alten Community-Post, einem anderen Appliance-Modell oder einer früheren SFOS-Version ist keine belastbare Freigabe für die eigene Umgebung.
Liegt nur ein eigener Lösungsansatz vor, sollte er zuerst mit dem Sophos Partner oder Professional Services geklärt werden. Eine generische Anleitung zum Einbau eigener Startskripte wäre hier gefährlicher als hilfreich.
Bestehendes Skript sicher ablösen
Ein vorhandenes Skript nicht sofort löschen. Zuerst muss sichtbar werden, welche Abhängigkeit der Betrieb davon hat.
- Änderungen einfrieren: Skript, Startmechanismus und betroffene Firewall zunächst nicht weiter verändern.
- Zweck erfassen: Symptom, Auslöser, gewünschtes Ergebnis, Pfad, Benutzer, Zeitplan, Secrets und verantwortliche Person dokumentieren.
- Wirkung beobachten: Logs, Prozessstatus, erzeugte Dateien sowie beeinflusste Routen, Dienste oder Interfaces festhalten. Bei HA beide Nodes getrennt prüfen.
- Zielweg wählen: Die Funktion einer nativen SFOS-Einstellung, Central, XML API oder externem Monitoring zuordnen.
- Ersatz testen: Den neuen Ablauf ausserhalb der produktiven Firewall testen und Erfolg, Fehler sowie Rollback protokollieren.
- Kontrolliert umstellen: Im Wartungsfenster den Ersatz aktivieren, das lokale Skript deaktivieren und den fachlichen Funktionstest durchführen.
- Nachkontrolle planen: Nach Neustart, Failover und dem nächsten Firmware-Upgrade erneut prüfen, soweit diese Ereignisse für die Funktion relevant sind.
Vor dem Change gehört ein aktuelles Backup dazu. Sophos Firewall Backup erstellen oder wiederherstellen erklärt Secure Storage Master Key, Restore und Kompatibilität. Das Backup schützt die dokumentierte Konfiguration, ersetzt aber keine separate Bestandsaufnahme lokaler Anpassungen.
Validierung und Rollback
Eine erfolgreiche API-Antwort oder ein laufender Prozess beweist noch nicht, dass die fachliche Aufgabe erfüllt ist. Nach der Umstellung muss genau das Ergebnis getestet werden, das vorher vom Skript abhing: Regel vorhanden, Route aktiv, Backup erstellt, Ziel erreichbar oder Alarm im Monitoring angekommen.
Für API-Änderungen zusätzlich Audit Trail und betroffene Objekte prüfen. Bei Traffic-Auswirkungen gehören Log Viewer, Rule ID, NAT Rule ID, Policy Test oder Packet Capture in die Abnahme. Central-Änderungen werden in der Tasks Queue und danach direkt auf einer betroffenen Firewall kontrolliert.
Der Rollback besteht nicht darin, das alte Skript vorschnell wieder einzuschalten. Zuerst die neue Änderung zurücknehmen und den dokumentierten Ausgangszustand wiederherstellen. Nur wenn der alte Workaround bewusst als Rückfalloption geprüft wurde, darf er zeitlich begrenzt reaktiviert werden.
Betriebsempfehlung
Lokale Skripte sollten in der Betriebsdokumentation als befristete Ausnahme erscheinen, nicht als normale Firewall-Funktion. Jede Ausnahme braucht einen Owner, einen Review-Termin, einen getesteten Rückbau und eine klare Aussage, welche Sophos-Versionen abgedeckt sind.
Für neue Anforderungen gilt die Reihenfolge: native SFOS-Funktion, Sophos Central, externe XML-API-Automation, externes Monitoring und erst danach ein von Sophos bestätigter Sonderfall. So bleiben Änderungen nachvollziehbar, HA und Restore planbarer und die Firewall näher am unterstützten Produktzustand.