Avanet Support-Zugang auf Sophos Firewall einrichten

Für einen Supportfall kann Avanet vorübergehend direkten Zugriff auf die WebAdmin-Konsole einer Sophos Firewall benötigen. Unter SFOS 22 ist dieser Zugang nur vertretbar, wenn Auftrag, Konto, Rechte, Quelladresse und Endzeit feststehen. Die globalen WAN-Freigaben für HTTPS und SSH bleiben deaktiviert; der Zugriff erfolgt über eine gezielte Local service ACL exception rule.

Für viele Fälle reicht eine Bildschirmfreigabe oder ein bestehender, kontrollierter Partnerzugang. Ein neuer direkter WAN-Zugang ist nur sinnvoll, wenn Avanet selbständig analysieren oder Änderungen durchführen muss. SSH kommt erst hinzu, wenn Device Console, Advanced Shell oder Logdateien gebraucht werden.

Die technischen Grundlagen erklärt Device Access und Local Service ACL auf Sophos Firewall. Vor Änderungen sollte ausserdem ein aktuelles Sophos Firewall Backup vorhanden sein.

Wichtig: Der Support-Zugang ist administrativer Zugriff auf die Firewall. Benutzer, ACL-Regel und SSH-Key müssen nach dem Fall deaktiviert oder entfernt werden, wenn kein dauerhafter Zugang vereinbart wurde.

Diagnostics > Support access ist keine Abkürzung für diesen Ablauf. Die Funktion erstellt eine befristete Access ID ausschliesslich für Sophos Support und gibt diesem WebAdmin- und Shell-Zugriff ohne Admin-Zugangsdaten. Eine solche ID wird nicht an Avanet weitergegeben.

Zugriff und Zeitraum festlegen

Vor der Konfiguration wird im Ticket festgehalten:

• welche Arbeiten Avanet durchführen darf,
• ob WebAdmin genügt oder zusätzlich SSH benötigt wird,
• wann der Zugang beginnt und endet,
• welche Avanet-Supportquelle verwendet wird,
• wer die Freigabe erteilt und den Rückbau kontrolliert.

Avanet muss die konkrete öffentliche Ausgangs-IP oder einen ausdrücklich dafür vorgesehenen FQDN im authentifizierten Ticket nennen. Die Quelle wird weder aus einer Website abgeleitet noch geraten. Vor der Änderung öffnet und testet man ausserdem einen unabhängigen Rückweg über Konsole, Management-LAN, Admin-VPN oder Sophos Fusion (ehemals Sophos Central).

Ein vorhandener Avanet- oder Partnerzugang sollte nicht durch ein zweites Dauerkonto ergänzt werden. In diesem Fall werden Profil, MFA, Quellbegrenzung und Status des vorhandenen Kontos geprüft. Für eine gemeinsame Analyse ohne direkten Login ist eine Bildschirmfreigabe oft die risikoärmste Variante.

WebAdmin-Benutzer einrichten

Der allgemeine Ablauf für persönliche Konten, Profile, MFA und Offboarding steht unter Sophos Firewall Administratoren und Profile sicher einrichten. Dieser Abschnitt ergänzt den supportbezogenen Spezialfall mit Zeitfenster, Supportquelle und kontrolliertem Rückbau.

Ein lokales, fallbezogenes Konto wie avanet-<ticket> ist ausschliesslich für die WebAdmin-Konsole gedacht. Ein eigenes Konto macht Änderungen im Audit Trail besser zuordenbar als die gemeinsame Nutzung des Default-Admins. SFOS speichert Benutzernamen klein; der Name lässt sich später nicht ändern.

1. Authentication > Users öffnen.
2. Add auswählen.
3. Benutzername und Anzeigename eintragen.
4. User type auf Administrator setzen.
5. Ein passendes Profile auswählen.
6. Ein starkes, nur für diesen Zugang bestimmtes Passwort und die im Auftrag bestätigte Kontaktadresse eintragen.

Als nachvollziehbarer Username passt beispielsweise avanet-<ticket>; <ticket> wird durch die interne Fallnummer ersetzt. Der Artikel nennt bewusst weder Passwort noch Supportadresse. Das Profil Administrator gibt vollständigen WebAdmin-Zugriff und wird nur verwendet, wenn der Auftrag dies wirklich verlangt. Für klar begrenzte Aufgaben erstellt man unter Profiles > Device access ein eigenes Profil und setzt jedes Menü auf None, Read-only oder Read-write. Beginnen sollte man mit Read-only und nur die für genehmigte Änderungen benötigten Bereiche auf Read-write setzen.

Unter Administrator advanced settings stehen zwei zusätzliche Begrenzungen zur Verfügung:

• Schedule for device access: erlaubt die Anmeldung an der WebAdmin-Konsole nur während des gewählten Zeitplans.
• Login restriction for device access: erlaubt die Anmeldung nur von ausgewählten IPv4-Adressen oder einem IPv4-Bereich.

Die im Ticket bestätigte feste Support-IP wird zusätzlich unter Login restriction for device access > Selected nodes eingetragen. Die Local Service ACL begrenzt damit die erreichbare Konsole, die Benutzerrestriktion zusätzlich die Anmeldung dieses Kontos. Bei einem FQDN als ACL-Quelle ist für diese zweite Schranke weiterhin die aktuell bestätigte IPv4-Adresse nötig. Mit Save speichern. Der Zeitplan sperrt nur die Anmeldung dieses Kontos; er deaktiviert weder die ACL-Regel noch SSH automatisch.

Passwort und MFA vorab testen

Das Passwort wird über einen vereinbarten sicheren Kanal übergeben und nicht in E-Mail oder Tickettext abgelegt. Unter Authentication > Multi-factor authentication wählt man für OTP Specific users and groups, fügt das Fallkonto hinzu und aktiviert unter Require MFA for die Web admin console. Token-Einrichtung und Reset-Verantwortung werden vor dem Termin geklärt; Seed, QR-Code und Einmalcodes gehören nicht ins Ticket. Die Details erklärt MFA für Administratoren.

Der erste Login wird noch über den unabhängigen Managementzugang begleitet. Dabei prüft man MFA und das Profil, ohne eine produktive Einstellung zu ändern. Ist MFA technisch nicht möglich, wird kein direkter WAN-Zugang als stiller Ersatz eingerichtet; dann verwendet man Bildschirmfreigabe, VPN oder einen anderen vereinbarten kontrollierten Zugangsweg.

Supportquelle und Local Service ACL begrenzen

Das im Ticket bestätigte Quellobjekt anlegen

Für ein kurzes Wartungsfenster ist ein IP-Host mit genau der bestätigten öffentlichen Ausgangs-IP die kleinste Vertrauensfläche. Wenn Avanet im Ticket ausdrücklich einen Support-FQDN nennt, unterstützt die Local Service ACL auch einen FQDN-Host. Die Firewall vertraut dann allen dazu aufgelösten Adressen bis zum Ablauf des DNS-TTL; Wildcard-FQDNs werden nicht unterstützt.

1. Für eine feste IP Hosts and services > IP host öffnen, Add auswählen und die bestätigte Adresse als einzelnes IPv4-Hostobjekt speichern.
2. Nur bei einem bestätigten FQDN Hosts and services > FQDN host öffnen und Add auswählen.
3. Einen fallbezogenen Name und unter FQDN exakt den Namen aus dem Ticket eintragen.
4. Mit Save speichern und das erzeugte Objekt nochmals öffnen.

Bei einem FQDN vergleicht man alle aufgelösten Adressen mit den Angaben im Ticket. Unerwartete oder nicht bestätigte Adressen sind eine Stop-Bedingung; in diesem Fall wird stattdessen die einzelne bestätigte IP verwendet oder bei Avanet nachgefragt.

Local Service ACL Exception Rule erstellen

HTTPS und SSH sind lokale Dienste der Firewall. Normale Firewall-Regeln steuern diesen Traffic nicht. Die Freigabe wird deshalb unter Administration > Device access eingerichtet.

1. Administration > Device access öffnen.
2. Im Bereich Local service ACL sicherstellen, dass HTTPS und SSH für WAN nicht global aktiviert sind.
3. Zum Bereich Local service ACL exception rule scrollen und Add auswählen.
4. Die Regel mit den folgenden Werten erstellen.

• Rule name: Avanet-Support
• Rule position: Top
• Description: Ticketnummer, Zweck und geplantes Enddatum
• IP version: IPv4
• Source zone: WAN
• Source Network / Host: genau das bestätigte IP- oder FQDN-Objekt
• Destination host: die tatsächlich verwendete WAN-Adresse der Firewall; Any nur, wenn mehrere dokumentierte WAN-Adressen benötigt werden
• Services: HTTPS; SSH nur bei bestätigtem Bedarf; Ping/Ping6 nur für eine konkrete Diagnose
• Action: Accept

Mit Save speichern. Die Position Top stellt sicher, dass die gezielte Freigabe vor einer überlappenden Drop-Regel geprüft wird. Bestehende Exception Rules müssen trotzdem kontrolliert werden: Eine breitere Accept-Regel oberhalb oder eine falsche Quellzone kann das beabsichtigte Sicherheitsmodell verändern.

Nicht verwenden: Any oder 0.0.0.0 als Source. Eine globale WAN-Freigabe macht die WebAdmin-Konsole unnötig breit erreichbar. Auch die WAN-Checkbox für HTTPS oder SSH darf für diesen Ablauf nicht aktiviert werden.

SSH nur bei Bedarf ergänzen

SSH bietet Zugriff auf Device Console und Advanced Shell und ist damit deutlich weitreichender als ein eingeschränktes WebAdmin-Profil. Für viele Supportfälle bleibt Services deshalb auf HTTPS beschränkt.

Das Fallkonto kann nicht für SSH verwendet werden. Sophos Firewall verwendet für diesen CLI-Zugang den Default-Benutzer admin. Der Public Key wird deshalb nicht am Fallkonto, sondern global unter Public key authentication for admin hinterlegt.

1. Administration öffnen.
2. Device access auswählen.
3. Zum Bereich Public key authentication for admin scrollen.
4. Enable authentication aktivieren.
5. Den über den vereinbarten sicheren Kanal bestätigten Public Key unter Authorized keys einfügen und mit dem Plus-Symbol hinzufügen. Vorher den bestehenden Key-Bestand dokumentieren, damit beim Rückbau nur der fallbezogene Key entfernt wird.
6. Apply auswählen.

Nur der Default-Admin kann SSH-Keys hinzufügen oder löschen; bei einem benutzerdefinierten Administrator erscheint Apply nicht. Sophos unterstützt RSA-Schlüssel ab 2048 Bit sowie bestimmte DSA- und ECDSA-Schlüssel, jedoch kein ED25519. Für einen neuen Support-Key sollte ein moderner, ausreichend starker und vom eingesetzten SSH-Client unterstützter Schlüssel verwendet werden.

Ein Public Key hat beispielsweise diese Struktur:

ssh-rsa <base64-public-key> avanet-support-<ticket>

Das ist nur ein Syntaxmuster und kein verwendbarer Schlüssel. Der private Schlüssel bleibt beim Supporttechniker und wird weder auf der Firewall noch im Ticket gespeichert. Nach dem Supportfall wird der fallbezogene Public Key entfernt und SSH aus der Exception Rule genommen. Die praktische Anmeldung beschreibt Sophos Firewall per SSH verbinden.

Zugang testen und Fehler eingrenzen

Ein erfolgreicher Login von der erlaubten Quelle allein reicht nicht als Abnahme. Es wird auch geprüft, dass der Zugang von einer anderen Internetquelle blockiert bleibt.

1. WebAdmin über die vereinbarte Avanet-Supportquelle und den konfigurierten Admin-Port öffnen. Der Standardport ist TCP 4444, kann aber unter Administration > Admin and user settings geändert worden sein.
2. Mit dem Fallkonto anmelden und prüfen, ob MFA funktioniert und das gewählte Profil nur die benötigten Menüs und Aktionen erlaubt.
3. Eine zweite, nicht freigegebene Internetquelle verwenden. Die WebAdmin-Konsole darf von dort nicht erreichbar sein.
4. Falls SSH freigegeben wurde, die Anmeldung als admin mit dem fallbezogenen Private Key testen. Passwort-SSH ist für diesen Test nicht nötig.
5. Im Log viewer die Authentifizierungsereignisse prüfen. Konfigurationsänderungen werden zusätzlich im Audit Trail kontrolliert. Eine harmlose, genehmigte Teständerung kann bei Read-write-Aufträgen die Zuordnung zum Fallkonto bestätigen und wird sofort zurückgenommen.
6. Testergebnis und Endzeit des Zugangs im Ticket dokumentieren.

Wenn WebAdmin nicht erreichbar ist

Die Prüfung beginnt an der Quelle und arbeitet sich zur Firewall vor:

• Entspricht die tatsächliche Ausgangs-IP dem Quellobjekt und, bei einem FQDN, dessen aktueller DNS-Auflösung?
• Kommt der Zugriff wirklich aus der in Source zone gewählten Zone?
• Stimmt die angesprochene WAN-Adresse mit Destination host überein?
• Steht die Exception Rule an Top und enthält sie HTTPS?
• Wird der korrekte WebAdmin-Port verwendet?
• Blockiert ein Providerrouter, vorgeschaltetes NAT-Gerät oder eine Upstream-ACL den Zugriff?
• Verhindert Login restriction for device access zwar nicht die TCP-Verbindung, aber die Anmeldung des Benutzers?

Die globalen WAN-Häkchen für HTTPS oder SSH werden zur Fehlerbehebung nicht aktiviert. Wenn die Exception Rule korrekt ist, sind sie für diesen gezielten Zugang nicht erforderlich.

Wenn die Anmeldung scheitert

Ist die Konsole erreichbar, aber der Login nicht möglich, werden Benutzerstatus, Passwort, MFA, Profil, Schedule for device access, Login restriction for device access und die systemweiten Block-Login-Einstellungen unter Administration > Admin and user settings geprüft. Nach mehreren Fehlversuchen kann Sophos Firewall die Quell-IP vorübergehend für alle Anmeldedienste blockieren.

Zugang kontrolliert zurückbauen

Nach Abschluss des Supportfalls werden die vereinbarten Änderungen und der Zugang selbst getrennt geprüft:

1. Im Audit Trail kontrollieren, welche Konfigurationsänderungen mit dem Fallkonto durchgeführt wurden, und fachliche Änderungen getrennt zurücknehmen, falls sie nicht übernommen werden sollen.
2. Bei grösseren Regelwerksänderungen kann Sophos Firewall Config Studio den Vorher-Nachher-Vergleich unterstützen.
3. Zuerst die Local Service ACL Exception Rule deaktivieren oder löschen, damit der externe Pfad geschlossen ist.
4. Von der bisherigen Supportquelle prüfen, dass WebAdmin und SSH nicht mehr erreichbar sind; der unabhängige Managementzugang muss weiter funktionieren.
5. Nur den fallbezogenen SSH Public Key entfernen und Enable authentication nur dann ausschalten, wenn keine anderen Schlüssel davon abhängen.
6. Das Fallkonto deaktivieren oder löschen und den MFA-Token entfernen, wenn kein ausdrücklich genehmigter Dauerzugang besteht.
7. ACL, Benutzer, Key-Bestand, Audit Trail und Ticket durch eine zweite Person gegen den Ausgangsstand prüfen.

Ein bewusst beibehaltener Partnerzugang benötigt weiterhin MFA, eine eng begrenzte Quelle, einen Verantwortlichen und eine regelmässige Überprüfung. Ein inaktives Ticket ist kein Grund für dauerhaft offenen Managementzugriff.

Häufige Fragen