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. Sicher ist dieser Zugang nur, wenn er auf eine bekannte Supportquelle, den benötigten Dienst und einen klaren Zeitraum begrenzt wird. Die globalen WAN-Freigaben für HTTPS und SSH bleiben dabei 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.

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.

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 lokale Benutzer avanet ist ausschliesslich für die WebAdmin-Konsole gedacht. Ein eigener Benutzer macht Änderungen im Audit Trail besser zuordenbar als die gemeinsame Nutzung des Default-Admins.

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. Starkes, nur für diesen Zugang bestimmtes Passwort und E-Mail-Adresse eintragen.

Als typische Werte passen Username avanet, Name Avanet und Email support@avanet.local. Das Profil Administrator gibt vollständigen Zugriff auf WebAdmin und CLI. Es wird nur verwendet, wenn der Supportfall diese Rechte tatsächlich erfordert. Für klar begrenzte Aufgaben ist unter Profiles > Device access ein eigenes Profil mit den benötigten Read-only- oder Read-write-Rechten besser.

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.

Wenn die feste Support-IP bekannt ist, sollte sie zusätzlich als Login restriction for device access eingetragen werden. Die Local Service ACL begrenzt dann die erreichbare Konsole, die Benutzerrestriktion zusätzlich die Anmeldung dieses Kontos. Mit Save speichern.

Passwort und MFA vorab testen

Das Passwort wird über einen vereinbarten sicheren Kanal übergeben und nicht dauerhaft in E-Mail oder Tickettext abgelegt. Wenn MFA für Administratoren verwendet wird, werden Token-Einrichtung, Übergabe und Reset-Verantwortung vor dem Supporttermin geklärt. Ein kurzer Login-Test verhindert, dass das eigentliche Wartungsfenster mit Passwort-, Rollen- oder MFA-Problemen beginnt.

Supportquelle und Local Service ACL begrenzen

FQDN-Host für support.avanet.com anlegen

Die Local Service ACL unterstützt FQDN-Hosts als Quelle. Dadurch muss bei einer kontrollierten Änderung der Avanet-Ausgangs-IP nicht jede Firewall manuell angepasst werden. Die Firewall verwendet die im DNS aufgelösten Adressen bis zum Ablauf des DNS-TTL. Wildcard-FQDNs werden für Local Service ACL Exception Rules nicht unterstützt.

1. Hosts and services > FQDN host öffnen.
2. Add auswählen.
3. Name und FQDN auf support.avanet.com setzen.
4. Mit Save speichern.

Vor dem nächsten Schritt wird geprüft, ob support.avanet.com auf die im Ticket genannte öffentliche Support-IP auflöst. Wenn die tatsächliche Ausgangs-IP nicht zum DNS-Ergebnis passt, wird die ACL den Zugriff korrekt ablehnen.

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: FQDN-Objekt support.avanet.com
• Destination host: öffentliche Firewall-Adresse oder Any, wenn die Firewall über mehrere passende WAN-Adressen erreichbar sein muss
• 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. Sophos verhindert eine globale WAN-Freigabe der WebAdmin-Konsole aus gutem Grund. 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.

Der Benutzer avanet kann nicht für SSH verwendet werden. Sophos Firewall akzeptiert für die CLI nur den Default-Benutzer admin. Der Public Key wird deshalb nicht am Benutzer avanet, 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 für den aktuellen Fall bestätigten Public Key unter Authorized keys einfügen und mit dem Plus-Symbol hinzufügen.
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>

Der private Schlüssel bleibt beim Supporttechniker und wird nie auf der Firewall gespeichert. Nach dem Supportfall wird der fallbezogene Public Key entfernt und SSH aus der Exception Rule genommen, sofern kein dauerhafter Zugang vereinbart ist. 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 avanet anmelden und prüfen, ob das gewählte Profil die benötigten Menüs 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.
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:

• Löst support.avanet.com auf die tatsächliche öffentliche Ausgangs-IP auf?
• 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 avanet durchgeführt wurden.
2. Bei grösseren Regelwerksänderungen kann Sophos Firewall Config Studio den Vorher-Nachher-Vergleich unterstützen.
3. Benutzer avanet deaktivieren oder löschen, wenn kein dauerhafter Partnerzugang vereinbart ist.
4. Local Service ACL Exception Rule deaktivieren oder löschen.
5. Fallbezogenen SSH Public Key entfernen.
6. Von der bisherigen Supportquelle prüfen, dass WebAdmin und SSH nicht mehr erreichbar sind.

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