Avanet Support-Zugang auf Sophos Firewall einrichten

Für Supportfälle, geplante Changes oder eine gemeinsame Fehleranalyse kann es sinnvoll sein, Avanet temporär Zugriff auf eine Sophos Firewall zu geben. Dieser Zugriff sollte aber nicht dadurch entstehen, dass WebAdmin oder SSH allgemein aus dem Internet erreichbar wird. Besser ist ein klar begrenzter Support-Zugang mit eigenem Admin-Benutzer, definierter Quelle und dokumentiertem Rückbau.

Diese Anleitung beschreibt einen typischen Ablauf für den Zugriff über HTTPS/WebAdmin und optional SSH. Für die allgemeinen Grundlagen zu lokalen Firewall-Diensten passt zusätzlich Device Access und Local Service ACL auf Sophos Firewall. Wenn SSH verwendet wird, sollte auch Sophos Firewall per SSH verbinden bekannt sein.

⚠️ Ein Support-Zugang ist ein administrativer Zugriff auf die Firewall. Er sollte nur für den benötigten Zeitraum aktiv sein, möglichst eng auf die Support-Quelle begrenzt werden und nach Abschluss des Falls wieder geprüft oder entfernt werden.

Vor dem Einrichten klären

Vor der Freigabe sollte kurz klar sein, welcher Zugriff wirklich benötigt wird:

• Reicht WebAdmin? Für viele Aufgaben genügt HTTPS/WebAdmin. SSH nur aktivieren, wenn Logdateien, CLI oder Advanced Shell gebraucht werden.
• Ist der Zeitraum begrenzt? Support-Zugänge sollten nach dem Fall deaktiviert oder entfernt werden.
• Welche Quelle darf zugreifen? Wenn möglich nur support.avanet.com beziehungsweise die vereinbarte Avanet-Supportquelle erlauben.
• Wer dokumentiert die Änderung? Benutzer, ACL-Regel, Zeitpunkt und Grund im Change oder Ticket festhalten.
• Gibt es ein Backup? Vor grösseren Änderungen sollte ein aktuelles Backup vorhanden sein.

Wenn bereits ein allgemeines Admin- oder Partnerkonto existiert, sollte nicht einfach ein weiteres dauerhaftes Konto entstehen. In solchen Fällen ist meist besser, den bestehenden Zugriff zu prüfen, MFA und Rollen zu kontrollieren und nur die Quelle temporär zu erlauben.

Sicherheitsmodell für den Support-Zugang

Ein Support-Zugang sollte nicht als normales Dauerkonto behandelt werden. Er ist ein bewusst eingerichteter administrativer Zugriff für einen konkreten Fall. Dadurch sollte man vorab entscheiden, welche Variante zum Risiko und zur Aufgabe passt.

Mögliche Varianten:

• Temporärer Benutzer avanet: sinnvoll, wenn Avanet Änderungen direkt nachvollziehbar durchführen soll. Starkes Passwort, Zeitraum, Rollenprofil und Rückbau dokumentieren.
• Bestehender Partner- oder Adminzugang: sinnvoll, wenn bereits ein kontrollierter Avanet-Zugang existiert. Zugriff nicht doppelt anlegen, sondern Quelle, MFA und Berechtigung prüfen.
• Nur Bildschirmfreigabe ohne eigenen Login: sinnvoll, wenn Avanet nur mitliest oder gemeinsam mit einem Admin klickt. Änderungen werden dann dem angemeldeten lokalen Admin zugeschrieben.
• SSH zusätzlich zu WebAdmin: nur verwenden, wenn CLI, Logdateien oder Advanced Shell benötigt werden. SSH zeitlich begrenzen und quellseitig eng erlauben.

Wenn MFA für Administratoren aktiv ist, sollte der Ablauf vor dem Termin geklärt werden. Je nach Umgebung kann ein temporärer Admin-Benutzer zusätzliche Token- oder Login-Schritte benötigen. Der Artikel MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren erklärt die Grundlagen. Für Rollen und Berechtigungen gilt: So wenig wie möglich, so viel wie nötig. Bei echten Troubleshooting-Fällen ist ein zu enges Profil aber oft hinderlich, weil Logs, VPN, NAT, Regeln, Routing und Systemzustand zusammen geprüft werden müssen.

Für Änderungen im Supportfenster sollte ausserdem ein aktuelles Backup vorhanden sein. Nach der Analyse kann man mit Audit Trail Logs und bei grösseren Regelwerksänderungen mit Config Studio nachvollziehen, welche Anpassungen erfolgt sind.

Passwort, MFA und Übergabeweg festlegen

Der technische Zugriff ist nur ein Teil des Support-Zugangs. Genauso wichtig ist, wie Passwort, MFA und Freigabeprozess gehandhabt werden. Ein starkes Supportpasswort sollte nicht dauerhaft in Tickets, E-Mails oder Chatverläufen liegen bleiben. Besser ist ein zeitlich begrenztes Passwort aus einem Passwortmanager oder ein anderer vereinbarter sicherer Übergabeweg.

Vor dem Termin sollte klar sein:

• Wer erstellt das Passwort oder den temporären Admin-Zugang?
• Über welchen sicheren Kanal wird das Passwort übergeben?
• Muss der Benutzer avanet MFA verwenden?
• Wer kann einen MFA-Token zurücksetzen, wenn die Anmeldung scheitert?
• Wird das Passwort nach dem Supportfall geändert, der Benutzer deaktiviert oder der Benutzer gelöscht?
• Ist dokumentiert, wer die Änderung freigegeben hat?

Wenn MFA aktiv ist, sollte der Supporttermin nicht erst mit der Token-Einrichtung beginnen. Praktisch ist ein kurzer Vorabtest mit WebAdmin-Login, Rollenprofil und Quelle. Wenn MFA bewusst nicht für den temporären Benutzer verwendet wird, müssen Quelle, Zeitraum, Rechte und Rückbau besonders eng begrenzt sein.

Benutzer avanet hinzufügen

Der Benutzer avanet ist für den WebAdmin-Zugriff gedacht. Damit lässt sich im Audit Trail besser nachvollziehen, dass eine Änderung im Rahmen eines Supportfalls erfolgt ist. Der Benutzer sollte ein starkes Passwort erhalten und nur so lange aktiv bleiben, wie er benötigt wird.

1. In der linken Navigation Authentication öffnen.
2. Users auswählen.
3. Add anklicken.

Typische Werte:

• Username: avanet
• Name: Avanet
• User type: Administrator
• Profile: Administrator, wenn Avanet die Firewall vollständig prüfen oder ändern muss
• Password: starkes Einmal- oder Supportpasswort aus einem Passwortmanager
• Email: zum Beispiel service@avanet.com

Danach mit Save speichern.

Wenn nur sehr eingeschränkte Aufgaben geplant sind, kann ein engeres Admin-Profil sinnvoller sein. Für viele Supportfälle braucht Avanet aber vorübergehend vollständige Rechte, weil Ursache, Logs, Regeln, NAT, VPN, Routing und Systemzustand oft zusammen geprüft werden müssen.

FQDN Host für support.avanet.com anlegen

Damit die ACL-Regel nicht für beliebige Internetquellen gilt, wird zuerst ein Hostobjekt für die Avanet-Supportquelle erstellt.

1. Hosts and services öffnen.
2. FQDN host auswählen.
3. Add anklicken.

Typische Werte:

• Name: support.avanet.com
• FQDN: support.avanet.com

Mit Save speichern. Die Firewall löst den FQDN über DNS auf und verwendet das Objekt danach als Quelle in der lokalen ACL-Regel.

Local Service ACL Exception Rule einrichten

Zugriffe auf WebAdmin und SSH sind lokale Dienste der Firewall. Dafür sind nicht normale Firewall-Regeln zuständig, sondern Administration > Device access und Local service ACL exception rule.

1. Administration öffnen.
2. Device access auswählen.
3. Zum Bereich Local service ACL exception rule scrollen.
4. Add anklicken.

Die Regel sollte so eng wie möglich gesetzt werden:

• Rule name: Avanet-Support.
• Rule position: passend zur bestehenden ACL-Struktur, häufig Bottom.
• IP version: IPv4, oder zusätzlich IPv6, wenn ausdrücklich benötigt.
• Source zone: Zone, aus der der Supportzugriff ankommt, häufig WAN.
• Source Network / Host: FQDN-Objekt support.avanet.com.
• Destination host: Any oder gezielt die Firewall-Adresse, je nach Umgebung.
• Services: HTTPS; SSH nur wenn wirklich benötigt; Ping/Ping6 nur für Diagnose.
• Action: Accept.

Danach speichern und die Regelposition prüfen. Wenn oberhalb eine breitere Ablehnungs- oder Ausnahme-Regel liegt, kann die neue Regel wirkungslos sein.

⚠️ Any als Source ist für WebAdmin oder SSH keine gute Support-Freigabe. Wenn die Quelle nicht feststeht, sollte zuerst mit Avanet geklärt werden, welche Supportquelle verwendet wird. Eine breite Freigabe erhöht sofort die Angriffsfläche der Firewall.

Optional: SSH Public Key hinterlegen

SSH wird nur benötigt, wenn eine Analyse über Device Console, Logdateien oder Advanced Shell notwendig ist. Für viele Supportfälle reicht WebAdmin.

Wichtig ist die Unterscheidung: Der zuvor angelegte Benutzer avanet ist ein WebAdmin-Benutzer. SSH-Zugriff auf Sophos Firewall erfolgt üblicherweise mit dem Benutzer admin. Der SSH Public Key wird deshalb im Bereich 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, falls Public-Key-Authentifizierung noch nicht aktiv ist.
5. Den von Avanet gelieferten Public Key unter Authorized keys hinzufügen.
6. Mit Apply speichern.

Der Public Key sollte aus dem aktuellen Ticket oder dem vereinbarten sicheren Kommunikationskanal stammen. Ein alter Key aus früheren Unterlagen sollte nicht ungeprüft wiederverwendet werden. Wenn Avanet für einen konkreten Fall einen neuen Key liefert, ist dieser Key massgebend.

Beispiel für den Aufbau eines Avanet Public Keys:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCktco/uC29KdU+Hf7GjcYXFumGJvt11MPxhdpnYA2XVEbnsI9r/XrW9J9K2ugvVGNoOD4IlN/bWZ1z3W6UqFKGgHUYkQu2h+0PFzP5I12Pu9I/3qIWwOhdA2j523FzneGQFptNCHHLQwma/zYJJwcVqsiJo/mg6W8jUbS30jFP6zDJvGRzbA2ATC7XzGNfa/CYr/AKoqdvm87RThOT7uh86w39x9VQTZH7d217K2UVuUrSppvnRaw5NCwukamWDDs8EtsVIFNkkxMl/SdJTC1SOSfO6mw8erXm1RhmNT5+wN/87f+DQioQPuWSrC3EHkgqw9BjoU3aLtYUw9AAItf6jJeUnZBfBCeJ1fJAzYpR8STdbaI8RXP1QMOr4omtmCakfnEH8kZ1BAYXxVzrJBXQ+sDVLZtWNDPqg8jIpdJ6bRNk/m7B+LAwsofHVLH1VSxoOEYdJGQvPfwonqo2JR+vosYhoHG89eh5EL/X9z5amvfVCShf6icstYwmaUmT/9lUTd8tkJZeTxNoezyspHhMryfB93653vb6wPS/n0ITkfu6rSfSrE1A1Y1dD5QtsFF6oEZxPqo8qQajtGhI3vZdHZSx53PqFqInra75xFHc+EjEsoLjt2wQdHr+ttEKvfrjfQmyXaWzqqE6bxmbbcMPtqY+pzMf83nEGwepJka0uw==

Der private Schlüssel wird nicht auf der Firewall gespeichert und sollte nie per E-Mail oder Chat weitergegeben werden. Auf der Firewall gehört nur der Public Key in das Feld für autorisierte Schlüssel. Nach Abschluss des Supportfalls sollte geprüft werden, ob dieser Public Key wieder entfernt werden kann.

Zugriff testen

Nach dem Speichern sollte der Zugriff nicht blind als erledigt gelten. Sinnvoll ist ein kurzer Funktionstest:

1. WebAdmin-Zugriff über die vereinbarte Avanet-Supportquelle testen.
2. Anmeldung mit dem Benutzer avanet prüfen.
3. Falls SSH benötigt wird: Verbindung mit admin und Public Key testen.
4. Im Log viewer und gegebenenfalls im Audit Trail prüfen, ob die Anmeldung und spätere Änderungen nachvollziehbar sind.
5. Dokumentieren, wann der Zugang wieder deaktiviert oder entfernt wird.

Wenn der Zugriff nicht funktioniert, zuerst die Quelle und die ACL-Regel prüfen. Danach DNS-Auflösung des FQDN-Objekts, Regelposition, Device Access, vorgelagerte NAT-Geräte und Routing kontrollieren.

Für einen Supporttermin ist zusätzlich hilfreich, vorab den betroffenen Kontext bereitzulegen:

• Firewall-Seriennummer und aktuelle SFOS-Version.
• Kurze Fehlerbeschreibung mit Zeitpunkt und betroffenen Netzen.
• Relevante Screenshots oder Logauszüge, falls vorhanden.
• Information, ob HA, SD-WAN, VPN, WAF, Central Management oder externe Authentifizierung beteiligt ist.
• Hinweis, ob Änderungen erlaubt sind oder zuerst nur Analyse gewünscht ist.

Dadurch muss der Support-Zugang nicht länger offen bleiben als nötig, und die eigentliche Analyse startet nicht mit Grundsatzfragen zu Zugriff, Kontext und Berechtigung.

Zugang nach dem Supportfall zurückbauen

Nach Abschluss des Supportfalls sollte der Zugang nicht dauerhaft unverändert bestehen bleiben. Je nach Vereinbarung gibt es drei saubere Varianten:

• Benutzer deaktivieren: sinnvoll, wenn später weiterer Support absehbar ist, aber aktuell kein Zugriff nötig ist.
• ACL-Regel deaktivieren: sinnvoll, wenn das Konto bestehen bleiben soll, aber kein externer Zugriff möglich sein darf.
• Benutzer und ACL-Regel entfernen: sinnvoll, wenn der Zugang nur einmalig benötigt wurde.

Zusätzlich sollte geprüft werden, ob ein SSH Public Key wieder entfernt werden kann. Wenn Änderungen an der Firewall vorgenommen wurden, passen Backup und Restore auf Sophos Firewall, Audit Trail Logs und bei Regelwerksänderungen Config Studio zur Nachkontrolle.

Checkliste

• Benutzer avanet mit starkem Passwort erstellt.
• Admin-Profil bewusst gewählt und dokumentiert.
• FQDN-Host support.avanet.com erstellt.
• Local Service ACL Exception Rule auf die Avanet-Supportquelle begrenzt.
• Nur benötigte Dienste erlaubt: HTTPS, SSH nur bei Bedarf.
• SSH Public Key nur im Bereich Public key authentication for admin hinterlegt.
• Passwortübergabe, MFA und Rückbauweg vor dem Termin geklärt.
• Rollenprofil und Änderungsfreigabe vor dem Termin geklärt.
• Zugriff getestet und im Ticket dokumentiert.
• Rückbau oder Deaktivierung nach Abschluss eingeplant.

Häufige Fragen