Sophos Firewall per SSH verbinden

Für viele Support- und Troubleshooting-Aufgaben benötigt man Zugriff auf die Sophos Firewall per SSH. Dazu gehören zum Beispiel Loganalysen, Service-Neustarts, spezielle Diagnosebefehle oder das Arbeiten in der Advanced Shell.

SSH ist aber auch ein Management-Zugang mit hohem Risiko. Der Zugriff sollte deshalb nur aus vertrauenswürdigen Admin-Netzen, über eine gezielte Local Service ACL Exception Rule oder über einen klar definierten Support-Zugang erlaubt werden. Für die allgemeine Härtung lokaler Firewall-Dienste passt zusätzlich Device Access richtig konfigurieren.

Voraussetzungen

Für eine SSH-Verbindung zur Sophos Firewall benötigt man:

• Administrativen Zugriff auf die Sophos Firewall.
• Die IP-Adresse oder den DNS-Namen der Firewall.
• Zugriff auf den Benutzer admin.
• Ein geändertes und sicher dokumentiertes Passwort für den Default-Admin; das werkseitige Passwort darf nicht im produktiven Betrieb verbleiben.
• Eine vertrauenswürdige Admin-Quelle, zum Beispiel Management-Netz, VPN oder feste Admin-IP.
• Auf macOS oder Linux: die vorinstallierte Terminal-App mit SSH.
• Auf Windows: Windows Terminal mit OpenSSH oder PuTTY.
• Erlaubten SSH-Zugriff unter Administration > Device access oder über eine Local service ACL exception rule.
• Bei geplanten Änderungen in der Advanced Shell: Backup, Wartungsfenster und ein klar festgelegter Plan, um Änderungen bei Problemen zurückzunehmen.

⚠️ SSH sollte nur aus vertrauenswürdigen Netzen erlaubt werden. Für produktive Umgebungen ist es besser, den Zugriff auf eine Management-IP oder ein Admin-Netz zu beschränken, statt SSH allgemein freizugeben.

Vorher klären, wofür SSH benötigt wird

Nicht jede Analyse braucht die Advanced Shell. Vor dem Login sollte klar sein, welche Konsole benötigt wird und wie stark der Eingriff ist.

Typische Zuordnung:

• Routing, DNS, Ping und einfache Systembefehle: Dafür ist meistens die Device Console richtig. Diese Konsole nutzt die Sophos CLI und ist weniger riskant als die Advanced Shell.
• Detaillierte Systeminformationen, Datenbanken oder Systemdienste: Dafür kann die Advanced Shell nötig sein. Ohne eine fallbezogene, belastbare Sophos-Anweisung bleibt man bei lesenden Prüfungen und ändert oder löscht nichts.
• Service-Status oder Debug prüfen: Das gehört ebenfalls in die Advanced Shell. Debug sollte nur gezielt aktiviert und danach wieder deaktiviert werden.
• Unbekannte Befehle: Nicht im Produktivsystem ausprobieren. Besser zuerst prüfen, in einer Testumgebung nachvollziehen oder einen Supportfall eröffnen.

Die Unterscheidung ist wichtig, weil Device Console und Advanced Shell unterschiedliche Syntax verwenden. Viele Fehler entstehen nur dadurch, dass ein korrekter Befehl am falschen Ort eingegeben wird. Eine breitere Übersicht steht in Sophos Firewall Troubleshooting: Services und Logs.

SSH-Zugriff auf der Firewall erlauben

Damit eine Verbindung möglich ist, muss die Sophos Firewall SSH auf der passenden Zone oder über eine Local Service ACL Exception Rule erlauben.

1. Im WebAdmin der Sophos Firewall anmelden.
2. Administration öffnen.
3. Device access auswählen.
4. Unter Local service ACL prüfen, ob SSH für die vorgesehene vertrauenswürdige Admin-Zone erlaubt ist. Den aktuellen Zustand vor einer Änderung notieren.
5. Falls man bewusst den Zugriff für diese ganze Zone erlauben möchte, SSH nur für diese Zone aktivieren und mit Apply speichern. Bereits passende Einstellungen müssen nicht erneut geändert werden.

Für ein vertrauenswürdiges internes Administrationsnetz kann beispielsweise LAN die passende Zone sein. Eine Zonenfreigabe gilt jedoch nicht nur für einen einzelnen Admin-Rechner. Für eine Beschränkung auf eine Admin-IP oder ein Management-Netz verwendet man stattdessen die unten beschriebene Local service ACL exception rule; die breite Zonenfreigabe ist dafür kein zusätzlicher Pflichtschritt. SSH nicht pauschal für WAN aktivieren.

Device Access steuert Zugriff zur Firewall selbst. Das ist nicht dasselbe wie eine normale Firewall-Regel, die Traffic durch die Firewall erlaubt. Wenn SSH in Device Access zu breit aktiviert ist, erreicht ein Client den lokalen SSH-Dienst der Firewall unabhängig davon, ob eine klassische LAN-zu-WAN-Regel sauber gebaut ist.

Die webbasierte CLI Console ist ein anderer Zugriffsweg als ein SSH-Client: Der SSH-Client verwendet TCP 22, die Browser-Konsole dagegen den HTTPS-Zugang zum WebAdmin. Für den Browser-Weg öffnet man Administration > Device access, prüft unter Local service ACL die Berechtigung HTTPS für die vorgesehene vertrauenswürdige Admin-Zone und aktiviert sie bei Bedarf mit Apply. Anschliessend öffnet man im WebAdmin die Admin-Dropdown-Liste oben rechts und wählt Console. Eine SSH-Freigabe ist für diesen Browser-Weg nicht erforderlich. Auch HTTPS wird nicht pauschal für WAN geöffnet; bestehende Quellbeschränkungen bleiben bestehen.

Für die Kontowahl gilt die dokumentierte Grenze von SFOS 22 und 23: Die PuTTY-Anleitung verlangt ausdrücklich admin und schliesst andere Benutzernamen aus, auch beim Passwort-Login. Die Profilbeschreibung gewährt dem Profil Administrator zwar vollen CLI-Zugriff und erlaubt dessen Zuweisung an weitere Administratoren, nennt dafür aber keinen Transportweg. Eine Rollenberechtigung ist daher keine Zusage, dass man sich mit einem benannten Konto per Netzwerk-SSH anmelden kann. Ebenso ist hier kein allgemeiner Browser-Konsolenzugang für jedes benannte Konto bestätigt. Vor einem Einsatz als Rückfallweg prüft man den konkreten Zugang mit dem vorgesehenen Konto auf der installierten SFOS-Version. Fehlt Console oder wird der Zugang abgewiesen, bleiben bestehende funktionierende Sitzungen offen; Konto, Profil und Zugriffsweg werden geprüft und der Fall nötigenfalls mit Sophos Support geklärt, statt WAN- oder ACL-Freigaben zu verbreitern. Die folgenden SSH-Schritte verwenden weiterhin admin; die ausschliessliche Verwaltung der SSH Public Keys durch den Default-Admin ist eine separate Berechtigung.

Vor der Änderung notiert man, in welchen Zonen SSH aktuell aktiviert ist und welche SSH-Ausnahmen bereits bestehen. So lässt sich der Ausgangszustand wiederherstellen, ohne eine andere gewollte Freigabe zu löschen.

Unter Local service ACL exception rule auf Add klicken und die Werte möglichst eng setzen:

• Name: zum Beispiel SSH-vom-Adminnetz; frei wählbar und eindeutig
• Rule position: Reihenfolge der Ausnahme in der Local Service ACL
• Description: Zweck, verantwortliches Team und bei temporärem Zugriff das Enddatum
• IP version: IPv4 oder IPv6 passend zur Admin-Quelle und Zieladresse
• Source zone: die Zone, aus der administriert wird
• Source Network / Host: die Admin-IP oder das Management-Netz
• Destination host: die Firewall-IP oder das Interface, das administriert werden soll, wenn der Zugriff zusätzlich auf eine konkrete Zieladresse eingeschränkt werden kann
• Services: SSH
• Action: Accept

Danach mit Save speichern. Für ein einzelnes Admin-System kann Source Network / Host beispielsweise ein Hostobjekt mit 192.0.2.10 sein. 192.0.2.10 ist eine Dokumentationsadresse und muss durch die tatsächliche, möglichst feste Admin-IP ersetzt werden. Destination host grenzt zusätzlich ein, über welche Firewall-IP der Dienst erreichbar sein soll; ohne betrieblichen Grund sollte man nicht alle Interface-Adressen abdecken.

Die Regel wird von der vorgesehenen Admin-Quelle mit einer neuen SSH-Sitzung geprüft. Erfolg bedeutet, dass das Konsolenmenü erscheint. Danach testet man aus einem absichtlich nicht erlaubten Netz, dass dort keine Sitzung zustande kommt. Bei einem unerwarteten Ergebnis bleibt die bestehende WebAdmin-Sitzung offen; geprüft werden Quell-IP, Source zone, IP version, Destination host, Regelposition und vorgeschaltete Filter.

War der Zugriff nur temporär, löscht man anschliessend genau diese Ausnahme unter Administration > Device access > Local service ACL exception rule und bestätigt mit OK. Wurde stattdessen ein Zonen-Häkchen geändert, setzt man nur dieses auf den zuvor notierten Zustand zurück und klickt Apply. Danach prüft man aus derselben Quelle, ob SSH wieder genau wie vor der Änderung erreichbar oder gesperrt ist. So bestätigt der Test den Ausgangszustand, statt pauschal einen fehlgeschlagenen oder erfolgreichen Login zu erwarten.

SSH sollte nicht unkontrolliert aus dem Internet erreichbar sein. Wenn externer Zugriff notwendig ist, sollte dieser nur über eine klar definierte Quell-IP, VPN oder einen dedizierten Support-Zugang erlaubt werden.

Diagnostics > Support access ist ein separater Mechanismus. Dabei öffnet man nicht einfach SSH aus dem Internet, sondern erlaubt Sophos Support temporären Zugriff über einen von der Firewall aufgebauten Support-Kanal. Auch dieser Zugriff sollte zeitlich begrenzt und nach dem Supportfall wieder deaktiviert werden.

Beim Aktivieren von Support access wählt man eine Dauer, danach erzeugt die Firewall eine eindeutige Access ID für Sophos Support. Diese Access ID bleibt für die gewählte Dauer gültig; Support access kann jederzeit vorzeitig abgeschaltet werden. Sophos Support kann damit auf WebAdmin und Shell zugreifen, ohne normale Admin-Zugangsdaten zu benötigen. Die Firewall baut die Support-Verbindungen für HTTPS und SSH selbst über TCP 22 auf; das ist betrieblich etwas anderes als eine eingehende SSH-Freigabe aus dem WAN.

Vor jeder Aktivierung – auch im WebAdmin – prüft man zunächst unter 4. Device Console mit dem rein lesenden Befehl den bestehenden Supportkanal:

show support_access

Der Befehl zeigt, ob Support access aktiv ist, und bei aktivem Zugriff auch Access ID und Dauer. Den Ausgangszustand sowie eine angezeigte Dauer und Access ID dokumentiert man ausschliesslich im authentifizierten, zugehörigen Supportfall. Die Anzeige allein belegt nicht, welchem Fall der Kanal gehört; diese Zuordnung und die Zustimmung zum Zugriff klärt man mit dem zuständigen Team und Sophos Support.

Ist bereits ein Kanal für einen anderen Fall aktiv oder ist die Zuständigkeit unklar, stoppt man und koordiniert das weitere Vorgehen, ohne den Kanal erneut zu aktivieren, zu ersetzen oder abzuschalten. Auch ein bereits für denselben Fall autorisierter aktiver Kanal wird nicht neu aktiviert; seine weitere Nutzung und sein Abschluss werden im bestehenden Fall abgestimmt. Den eigenständigen Ablauf Aktivieren, Analysieren und Deaktivieren beginnt man nur bei bestätigt inaktivem Ausgangszustand und mit ausdrücklicher Zustimmung für diesen Supportfall. Diese Voraussetzung gilt für beide folgenden Zugriffswege.

Für den WebAdmin-Weg öffnet man Diagnostics > Support access, schaltet Support access ein und bestätigt mit OK. Danach wählt man die für den konkreten Supportfall benötigte Dauer, klickt Apply und bestätigt erneut mit OK. Die Firewall baut eine sichere Steuerverbindung zu ihrem Access Proxy auf; die erzeugte Access ID findet man unter Access status und übermittelt sie ausschliesslich über den vereinbarten Supportkanal an Sophos Support.

Support access in der Device Console schalten

SFOS 22 kann den Supportkanal auch unter 4. Device Console aktivieren. Unmittelbar vor dem Schreibbefehl führt man dort nochmals die oben beschriebene Prüfung mit show support_access aus. Nur wenn der Kanal bestätigt inaktiv ist und die Zustimmung für diesen Fall vorliegt, aktiviert man ihn:

set support_access enable

Nach erfolgreicher Aktivierung zeigt der Befehl die Access ID und die Zugriffsdauer an. Die tatsächlich angezeigte Dauer wird mit der fallbezogenen Zustimmung abgeglichen; die dokumentierte CLI-Syntax enthält keinen Parameter zum Setzen einer Dauer. Benötigt man eine bestimmte Dauer, verwendet man nach derselben Vorprüfung den oben beschriebenen WebAdmin-Weg. Access ID und Dauer werden nur im authentifizierten, zugehörigen Supportfall übermittelt und nicht in allgemeine Dokumentationen, Chats oder Passwortablagen kopiert.

Nach Abschluss der Analyse schaltet man unabhängig von der Restlaufzeit ausschliesslich den für diesen Fall mit Zustimmung eingerichteten eigenen Kanal ab. Vorher prüft man mit show support_access und der dokumentierten Access ID, dass es noch dieser Kanal ist. Ist er bereits inaktiv, entfällt der Schreibbefehl; bei einer abweichenden ID oder unklarer Zuständigkeit stoppt man und koordiniert, statt einen möglicherweise fremden Kanal abzuschalten:

set support_access disable

Anschliessend wird unter Diagnostics > Support access oder mit show support_access kontrolliert, dass der eigene Kanal nicht mehr aktiv ist. disable verändert weder die normale SSH-Konfiguration unter Device Access noch Local Service ACL Exception Rules; temporäre Admin- und SSH-Freigaben werden deshalb separat und nur im Umfang der eigenen Änderung auf den zuvor notierten Zustand zurückgebaut.

Steht vor der Firewall ein weiterer Router oder ausgehender Filter, muss dieser TCP 22 zum Ziel *.apu.sophos.com erlauben. Dafür wird keine eingehende WAN-Regel auf der Sophos Firewall erstellt. Inaktive Support-Sitzungen werden nach 15 Minuten geschlossen; die gewählte Gesamtdauer und das manuelle Abschalten von Support access bleiben davon unabhängig.

Die weiteren Herstellerziele für Updates, Lizenzierung, RED, Central, Reporting und Backups ordnet Sophos Firewall ausgehende Dienste und Ports prüfen ein.

Support access per XML API: vor Schreibzugriff klären

Die XML-API-Hilfe für SFOS 22 und 23 bezeichnet das Objekt als SupportAccess, enthält aber zwei Widersprüche: Im XML-Beispiel heisst der Dauer-Tag GrantAccessFor, in der Parametertabelle dagegen GrantAccessForr. Für ConfigOption nennt die Tabelle den Default ON, erlaubt jedoch nur Enable und Disable. Daraus lässt sich weder ein gültiger Request-Wert ON noch ein standardmässig aktiver Supportzugang ableiten. Vor einem Schreibzugriff die gültige Tag-Schreibweise für den installierten Build in API help oder mit Sophos Support klären.

Die Tabelle kennzeichnet beide Felder als optionale skalare Werte und nennt die Zeitfenster 1 day, 2 days, 1 week, 2 weeks, 1 month und 2 months. Das klärt nicht, was beim Weglassen eines Feldes tatsächlich passiert. Vor einer automatisierten Änderung prüft man deshalb die objektspezifische API-Hilfe des installierten SFOS-Builds und lässt offene Fragen zu Tag, Werten oder Auslassungsverhalten mit Sophos Support klären. Solange der Widerspruch nicht geklärt ist, stoppt der XML-Schreibzugriff; man erfindet keinen Payload und probiert nicht beide Schreibweisen im Produktivsystem aus. Für einen freigegebenen Supportfall bleibt der oben beschriebene WebAdmin-Weg die Alternative, ohne WAN- oder ACL-Freigaben zu verbreitern.

Die Referenz nennt für diese Operation 200 mit Operation Successful. und 500 mit Operation Fail.. Die konkrete Objektantwort prüfen, statt einen fehlgeschlagenen oder unklaren Schreibzugriff blind zu wiederholen. Nach einer bestätigten Änderung kontrolliert man den tatsächlichen Aktivierungszustand und die Dauer unter Diagnostics > Support access beziehungsweise mit dem oben beschriebenen show support_access. Nach dem Supportfall ausschliesslich den eigenen, für diesen Fall autorisierten Kanal unter den oben beschriebenen Zuständigkeitsprüfungen deaktivieren und den inaktiven Zustand prüfen; temporäre SSH-/ACL-Berechtigungen werden weiterhin separat zurückgebaut.

Public Key für admin hinterlegen

Für SSH-Zugriffe ist die Authentifizierung mit einem Public Key die bevorzugte Methode. Auf der Sophos Firewall kann der Public Key für den Benutzer admin unter Administration > Device access hinterlegt werden. Passwort-Login kann für Notfälle notwendig sein, sollte aber nicht der bequemste Standardzugang bleiben.

⚠️ Eine SSH-Anmeldung an der Sophos Firewall ist nur mit dem Benutzer admin möglich. Andere WebAdmin-Benutzer können sich nicht per SSH anmelden.

Wichtig: Nur der Default-Admin kann die Public-Key-Authentifizierung für SSH ändern, also SSH-Schlüssel hinzufügen oder entfernen. Solche Änderungen an SSH-Schlüsseln gehören in einen dokumentierten Admin-Prozess und sind keine spontane Supportabkürzung.

Der Default-Admin ist kein normales Rollen-Konto, das man beliebig ersetzt. Sophos weist darauf hin, dass dieses Konto nicht umbenannt oder gelöscht werden kann. Deshalb gehören Default-Admin-Passwort, MFA-/Recovery-Informationen für interaktive Admin-Anmeldungen und die hinterlegten SSH Public Keys gemeinsam in den Admin-Betriebsprozess. Ein Public Key ersetzt keine saubere Kontrolle über dieses Konto.

Benannte WebAdmin-Administratoren werden getrennt verwaltet und können sich nicht mit ihrem eigenen Benutzernamen per SSH anmelden. Den Lifecycle und die Rechte dieser Konten erklärt Lokale Administratoren und Device-Access-Profile nach Least Privilege verwalten.

Bevor man den Public Key auf der Firewall hinterlegt, erzeugt man auf dem eigenen Admin-Client mit einem SSH-Schlüsselwerkzeug ein Schlüsselpaar aus öffentlichem und privatem Schlüssel. Ein bereits vorhandenes, geeignetes und zusammengehöriges Schlüsselpaar kann wiederverwendet werden. Für Schlüsseltyp und Schlüssellänge gelten die Hinweise im folgenden Abschnitt zu den unterstützten SSH-Key-Typen. Den privaten Schlüssel speichert und schützt man ausschliesslich auf dem Admin-Client; er wird weder weitergegeben noch auf die Firewall hochgeladen. Für die folgenden Schritte kopiert man nur den öffentlichen Schlüssel.

Der Public Key wird im Bereich Public key authentication for admin hinzugefügt:

1. Administration öffnen.
2. Device access auswählen.
3. Zum Bereich Public key authentication for admin scrollen.
4. Enable authentication aktivieren.
5. Den Public Key unter Authorized keys hinzufügen.
6. Mit Apply speichern.

Die bestehende WebAdmin- oder SSH-Sitzung bleibt offen, während man den neuen Key in einer zweiten SSH-Sitzung prüft. Erst wenn dort das Konsolenmenü erscheint, darf ein alter Key entfernt oder ein Passwort-Fallback geändert werden. Schlägt der Test fehl, bleibt die bisherige Anmeldung erhalten; man prüft Key-Typ, Public-Key-Eintrag, passenden Private Key und erlaubte Quelle und entfernt nur den neu hinzugefügten fehlerhaften Eintrag.

Der private Schlüssel bleibt immer auf dem Admin-Client und darf nicht weitergegeben werden. Auf der Firewall wird nur der Public Key hinterlegt.

Wenn mehrere Admins SSH nutzen, sollte nicht derselbe private Schlüssel geteilt werden. Besser sind getrennte Admin-Clients, dokumentierte Public Keys und ein Review, welche Schlüssel noch benötigt werden. Nach Personalwechseln oder Dienstleisterwechseln sollte der Bereich Authorized keys geprüft werden.

Unterstützte SSH-Key-Typen

Nicht jeder moderne SSH-Key-Typ ist auf Sophos Firewall gleich geeignet. Vor dem Rollout sollte man prüfen, ob der Schlüsseltyp unterstützt wird.

Wichtige Einordnung der Key-Typen:

• RSA: Mindestens 2048 Bit verwenden.
• DSA: Nur verwenden, wenn es aus Kompatibilitätsgründen nötig ist; dann ebenfalls mindestens 2048 Bit.
• ECDSA: Wird unterstützt. Wichtig ist nur, ECDSA nicht mit ED25519 zu verwechseln.
• ED25519: Für die SSH Public Key Authentication auf Sophos Firewall nicht verwenden, weil dieser Key-Typ für diesen Zweck nicht akzeptiert wird.

Für neue Admin-Zugänge ist ein sauber verwalteter RSA- oder unterstützter ECDSA-Key meist pragmatischer als ein moderner Key-Typ, den die Firewall oder ein älteres SSH-Tool nicht akzeptiert.

Verbindung mit macOS oder Linux herstellen

Auf macOS und Linux ist ein SSH-Client normalerweise bereits vorhanden. Die Verbindung wird im Terminal hergestellt.

Beispiel:

ssh admin@192.0.2.1

Dabei wird 192.0.2.1 durch die IP-Adresse oder den DNS-Namen der eigenen Sophos Firewall ersetzt.

Beim ersten Verbindungsaufbau fragt der SSH-Client, ob der Fingerprint des Zielsystems akzeptiert werden soll. Dieser Fingerprint sollte geprüft und anschliessend bestätigt werden.

Wenn nach einem Reimage, Hardwaretausch oder IP-Wechsel eine Warnung zu einem geänderten Host Key erscheint, sollte der neue Fingerprint nicht blind akzeptiert werden. Zuerst prüfen, ob wirklich dieselbe Firewall ersetzt, neu installiert oder auf eine neue IP verschoben wurde. Erst danach kann der alte Eintrag in ~/.ssh/known_hosts bereinigt und der neue Fingerprint angenommen werden.

Danach wird je nach Konfiguration das Passwort des Benutzers admin abgefragt oder die Anmeldung über den hinterlegten SSH-Key durchgeführt.

Wenn ein bestimmter privater Key verwendet werden soll:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

Für wiederkehrende Zugriffe dokumentiert man den Pfad zum privaten Schlüssel, die erlaubte Quell-IP und den Zweck. Der known_hosts-Eintrag wird nicht in Tickets oder Chatverläufe kopiert. Bei Host-Key-Warnungen ist die Änderungshistorie wichtiger als ein schneller Workaround.

Verbindung mit PuTTY herstellen

Unter Windows kann man entweder Windows Terminal mit OpenSSH verwenden oder PuTTY einsetzen.

Mit Windows Terminal funktioniert der Verbindungsaufbau ähnlich wie unter macOS oder Linux:

ssh admin@192.0.2.1

Für PuTTY: Falls das Programm noch nicht vorhanden ist, lädt man es zuerst von der offiziellen PuTTY-Downloadseite herunter und richtet es auf dem Admin-Rechner ein. Danach folgt der Verbindungsaufbau:

1. PuTTY öffnen.
2. Unter Host Name die IP-Adresse oder den DNS-Namen der Sophos Firewall eintragen.
3. Port auf 22 setzen.
4. Connection type auf SSH stellen.
5. Mit Open verbinden.
6. Den SSH-Fingerprint prüfen und bestätigen.
7. Als Benutzer admin anmelden und je nach Konfiguration Passwort oder SSH-Key verwenden.

Nach dem Login erscheint das Konsolenmenü der Sophos Firewall.

Wenn PuTTY mit einem privaten Schlüssel genutzt wird, muss der Key zum hinterlegten Public Key auf der Firewall passen. Nach einem Personal- oder Dienstleisterwechsel sollte nicht nur das Passwort geändert werden; alte Public Keys müssen ebenfalls aus Authorized keys entfernt werden.

Device Console oder Advanced Shell öffnen

Nach erfolgreicher Anmeldung erscheint das Main Menu. Die folgende Darstellung dient als Orientierung für die Menüauswahl:

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

Am Prompt Select Menu Number [0-7]: gibt man die Nummer des gewünschten Menüpunkts ein, beispielsweise 1 für Network Configuration. Für Diagnosebefehle sind besonders die folgenden beiden Wege wichtig. 7. Shutdown/Reboot Device führt zu Aktionen, die den Betrieb unterbrechen können; dieser Menüpunkt ist nicht zum Ausprobieren gedacht.

Für viele SFOS Befehle verwendet man:

4. Device Console

Für tiefere Linux- oder Dateisystem-Aufgaben verwendet man die Advanced Shell über:

5. Device Management
3. Advanced Shell

Die Advanced Shell bietet sehr weitreichenden Zugriff auf das System. Befehle sollten dort nur ausgeführt werden, wenn klar ist, was sie bewirken.

Änderungen an Konfigurationen wie Interfaces, Rules oder Policies, die direkt in der Advanced Shell vorgenommen werden, bleiben laut Sophos nach einem Neustart nicht bestehen und landen nicht im Backup. Solche Eingriffe sind deshalb kein regulärer Konfigurationsweg. Dateien unter /tmp/ werden beim Neustart ebenfalls gelöscht.

Typische Beispiele:

• Device Console: ping, dnslookup, traceroute, show, Routing- oder Systemoptionen.
• Advanced Shell: detaillierte Systeminformationen, Datenbanken, Systemdienste und fallbezogene Diagnose durch Sophos Support.

Für Loganalyse, Dienstnamen und typische Fehlerbilder ist Sophos Firewall Troubleshooting: Services und Logs der bessere Startpunkt als einzelne Befehle auswendig zu übernehmen.

Die Befehlsfamilien set und system verstehen

In 4. Device Console definiert set Einstellungen und Parameter verschiedener Systemkomponenten; system konfiguriert Systemparameter. Beide Familien können die Konfiguration verändern. Zum Kennenlernen nutzt man deshalb nur die Hilfe, nicht einen vollständigen Änderungsbefehl. Die Dokumentation für SFOS 22 und 23 verwendet diese allgemeinen Syntaxschemata – keine Befehle zum Kopieren:

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set beziehungsweise system ist das feste Präfix und wird genau so eingegeben.
• [command] ersetzt man durch den gewünschten dokumentierten Befehl: bei set beispielsweise advanced-firewall, bei system beispielsweise firewall-acceleration.
• [option 1|option 2] bedeutet, dass man eine der dokumentierten Alternativen auswählt. Die eckigen Klammern und | werden nicht eingegeben; sie bedeuten hier nicht, dass man die Auswahl beliebig weglassen darf.
• <value> ist ein Platzhalter für einen zur gewählten Option passenden Wert. Man ersetzt ihn einschliesslich der spitzen Klammern durch den benötigten Wert. Welche Argumente tatsächlich erforderlich sind, bestimmt die Hilfe des konkreten Befehls, nicht allein dieses allgemeine Schema.

Nur zur Syntaxerklärung, nicht ausführen: Im Herstellerbeispiel set advanced-firewall icmp-error-message allow ist set das Präfix, advanced-firewall der gewählte Befehl, icmp-error-message die Option und allow der konkrete Wert anstelle von <value>. Das ist eine Konfigurationsänderung, kein notwendiger SSH-Schritt. Auch das Herstellerbeispiel system firewall-acceleration enable ist keine Lernübung: system ist das Präfix, firewall-acceleration der gewählte Befehl und enable die gewählte Option. Dieses konkrete Beispiel enthält keinen zusätzlichen Wert; man hängt nicht ungeprüft <value> an und schaltet die Beschleunigung nicht zum Ausprobieren ein.

Zur sicheren Erkundung tippt man in der Device Console nur set und drückt dreimal Tab, um die verfügbaren Einstellungen aufzulisten. Tab gefolgt von ? zeigt deren Beschreibungen. Für die andere Familie wiederholt man das mit dem Präfix system. Erwartet wird eine Hilfeanzeige, keine geänderte Einstellung. Die Eingabezeile anschliessend leeren, ohne einen Änderungsbefehl mit Enter abzuschicken. Fehlt die erwartete Hilfe, prüft man zuerst die Konsole und die Dokumentation der installierten SFOS-Version, statt einen Beispielbefehl auszuprobieren.

Verbindung beenden

⚠️ Die älteren Device-Console-Steuerungen enableremote und disableremote sind kein normaler Abmeldeweg: In SFOS 22 und 23 beschreibt Sophos, dass disableremote nicht nur neue SSH-Verbindungen auf Port 22 verhindert, sondern auch bestehende SSH-Sitzungen beendet. Deshalb nicht zum Abmelden oder zum Rückbau einer temporären ACL-Freigabe ausführen. Vor einem ausdrücklich freigegebenen Einsatz dieser Steuerungen muss ein funktionierender, von Netzwerk-SSH unabhängiger Rückfallweg geprüft sein: lokale serielle oder Out-of-Band-Konsole bei physischen Appliances beziehungsweise die passende Plattformkonsole bei virtuellen oder Cloud-Firewalls. Ohne diesen Zugang und einen für die installierte Version geklärten Wiederherstellungsplan stoppt man und klärt den Fall mit Sophos Support. Die Beschreibung von enableremote nennt einen Ethernet-Port; daraus wird hier weder eine TCP-Port-Syntax noch eine pauschale Gegenanweisung abgeleitet. Für temporäre Zugriffsrechte bleibt der oben beschriebene genaue Rückbau unter Administration > Device access massgeblich; der ausgehend aufgebaute Kanal unter Diagnostics > Support access ist davon getrennt.

In der Advanced Shell verwendet man zum Verlassen der Shell den folgenden Befehl. Er ist kein Ersatz für die Nummernauswahl im Konsolenmenü:

exit

Befindet man sich in einem Untermenü, kehrt man zunächst zum Main Menu zurück. Dort beendet 0. Exit die Konsolensitzung: am Menü-Prompt 0 eingeben. Shell-Befehl und Menünummer werden also an unterschiedlichen Stellen verwendet.

Sophos Firewall beendet inaktive SSH-Sitzungen nach 15 Minuten. Das ist kein Ersatz für sauberes Abmelden: Offene Sitzungen, Debug-Modi und temporäre Freigaben sollten trotzdem bewusst geschlossen beziehungsweise zurückgebaut werden.

War der SSH-Zugriff nur für einen Supportfall erlaubt, nimmt man anschliessend genau diese temporäre Zugriffsberechtigung zurück. Eine dafür angelegte Local service ACL exception rule wird wie oben beschrieben gelöscht; ein geändertes Zonen-Häkchen wird auf den zuvor notierten Zustand zurückgesetzt und mit Apply gespeichert. Andere weiterhin benötigte Berechtigungen bleiben erhalten. Das ist besonders bei externen Quell-IP-Adressen oder Dienstleisterzugängen wichtig.

Nach tiefen Eingriffen sollte zusätzlich geprüft werden:

• Ist Debug wieder deaktiviert?
• Wurde eine temporäre ACL Exception Rule entfernt oder deaktiviert?
• Sind keine temporären Dateien, Support-Dumps oder Mitschnitte unnötig auf der Firewall liegen geblieben?
• Sind Logauszüge, Uhrzeit, Befehl und Ergebnis im Ticket oder Change dokumentiert?
• Wurde der SSH-Key nur für den geplanten Admin- oder Supportzugang verwendet?

Häufige Probleme

Verbindung wird abgelehnt

Wird die Verbindung abgelehnt, ist SSH häufig nicht für die gewählte Zone oder Quelle erlaubt. Unter Administration > Device access prüft man deshalb die SSH-Einstellung und vorhandene Local service ACL exception rule-Einträge. Ausserdem klären, ob eine breitere Zonenfreigabe absichtlich zurückgenommen wurde. Eine solche Einschränkung wird nicht ungeprüft wieder geöffnet.

Verbindung läuft in einen Timeout

Ein Timeout deutet oft darauf hin, dass die Firewall über die gewählte IP-Adresse nicht erreichbar ist, eine Route fehlt oder eine vorgelagerte Firewall den Zugriff blockiert.

Verwendet eine noch nicht fertig eingerichtete Firewall weiterhin das werkseitige Default-Passwort, verwirft SFOS SSH-Verbindungen aus der WAN-Zone absichtlich ohne Fehlermeldung. Das ist eine Schutzfunktion. Das Passwort wird deshalb zuerst über einen zulässigen lokalen Administrationsweg geändert; Device Access oder die ACL werden nicht als Umgehung verbreitert.

Kein Netzwerkzugang zur Firewall

Wenn weder WebAdmin noch SSH erreichbar sind, setzt man nicht hektisch weitere WAN- oder Zonenfreigaben. Für eine physische Appliance ist die lokale serielle Konsole der Rückfallweg, etwa bei falschem Device Access, Routing oder falsch zugeordneten Interface-Zonen. Man verwendet das passende RJ45-Konsolenkabel oder bei unterstützten Modellen Micro-USB und stellt im Terminalprogramm 38400 Baud ein.

Sind Micro-USB und RJ45 gleichzeitig angeschlossen, hat Micro-USB Vorrang und die Firewall leitet die Konsolenausgabe dorthin um. Bei leerem Terminal prüft man zuerst den richtigen seriellen Port, das Kabel und diese Priorität. Der Wert 38400 Baud ist im BIOS ausgegraut, damit er nicht versehentlich geändert wird; man versucht daher nicht, ihn dort anzupassen.

Die konkreten Verbindungsschritte stehen unter Serielle Verbindung öffnen. Ist das admin-Passwort bekannt, meldet man sich nach dem Verbindungsaufbau damit an und benötigt keinen Passwort-Reset. Man nutzt nur die Verbindungsschritte des verlinkten Artikels, nicht dessen Reset-Ablauf. Erfolg ist das angezeigte Konsolenmenü; bei virtuellen oder Cloud-Firewalls ist stattdessen der zum jeweiligen Plattformtyp passende Konsolenzugang nötig.

Anmeldung schlägt fehl

Wenn die Anmeldung fehlschlägt, sollten der Benutzer admin, das Passwort beziehungsweise der SSH-Key und die erlaubten Quellnetze geprüft werden. Typische Meldungen wie Permission denied (publickey,password) deuten auf ein falsches Passwort, einen nicht passenden privaten Schlüssel oder fehlende Public-Key-Konfiguration hin.

Ist das Passwort des Default-Admins tatsächlich verloren, zeigt Sophos Firewall Admin-Passwort zurücksetzen den seriellen Recovery-Weg für physische Appliances und die getrennten Grenzen für virtuelle und Cloud-Firewalls.

Wenn Public-Key-Login fehlschlägt, zusätzlich Key-Typ, Key-Länge, falschen privaten Schlüssel, PuTTY-Keyformat und den Eintrag unter Authorized keys prüfen. Ein korrekt erlaubter SSH-Dienst hilft nicht, wenn der Schlüssel nicht zum hinterlegten Public Key passt.

Host-Key-Warnung erscheint

Eine Host-Key-Warnung kann harmlos sein, wenn eine Firewall neu installiert oder ersetzt wurde. Die Warnung kann aber auch auf ein falsches Zielsystem oder eine IP-Adressverwechslung hinweisen. Deshalb zuerst Firewall, IP-Adresse, DNS und Änderungshistorie prüfen. Erst danach sollte der alte known_hosts Eintrag entfernt werden.

Falsche Konsole geöffnet

Wenn ein dokumentierter Sophos-CLI-Befehl nicht erkannt wird, ist häufig die falsche Konsole geöffnet oder die Syntax unvollständig. In der Device Console zeigt Tab die verfügbaren Befehle und Argumente; ? zeigt Beschreibungen. Linux-Shell-Anweisungen werden dort nicht eingegeben. Unbelegte Befehle werden auch in der Advanced Shell nicht ausprobiert.

Betriebscheckliste

• SSH nur aus vertrauenswürdigen Admin-Quellen erlauben.
• Werkseitiges Default-Passwort vor dem produktiven SSH-Zugriff ändern.
• Wenn möglich eine Local service ACL exception rule statt einer breiten Zonenfreigabe verwenden.
• Public Key Authentication für das Konto admin gegenüber Passwort-Login bevorzugen.
• Default-Admin-Passwort, MFA-/Recovery-Informationen und SSH-Keys getrennt dokumentieren.
• Einen unterstützten Schlüsseltyp verwenden und die Schlüssellänge dokumentieren.
• Private Keys nicht teilen.
• SSH-Fingerprint beim ersten Login prüfen.
• Host-Key-Warnungen nach Reimage oder Hardwaretausch bewusst behandeln.
• Device Console und Advanced Shell nicht verwechseln.
• Änderungen in der Advanced Shell nur mit klarem Zweck ausführen.
• Temporäre SSH-Zugriffsberechtigungen nach Supportfällen wieder zurücknehmen.
• Alte Public Keys nach Personal- oder Dienstleisterwechsel löschen.

FAQ