Konfigurera Avanet-supportåtkomst på Sophos Firewall

I ett supportärende kan Avanet tillfälligt behöva direktåtkomst till WebAdmin-konsolen på en Sophos Firewall. Åtkomsten är endast säker om den begränsas till en känd supportkälla, den tjänst som behövs och en tydligt angiven tidsperiod. De globala WAN-öppningarna för HTTPS och SSH förblir avstängda. Åtkomsten sker i stället via en riktad Local service ACL exception rule.

I många fall räcker skärmdelning eller en befintlig, kontrollerad partneråtkomst. Ny direktåtkomst från WAN är bara motiverad om Avanet behöver analysera eller genomföra ändringar självständigt. SSH läggs endast till när Device Console, Advanced Shell eller loggfiler behövs.

De tekniska grunderna beskrivs i Device Access och Local Service ACL på Sophos Firewall. Innan ändringar genomförs bör det dessutom finnas en aktuell säkerhetskopia av Sophos Firewall.

Viktigt: Supportåtkomsten ger administrativ åtkomst till brandväggen. Användaren, ACL-regeln och SSH-nyckeln måste inaktiveras eller tas bort efter ärendet om ingen permanent åtkomst har avtalats.

Fastställ åtkomst och tidsperiod

Följande dokumenteras i ärendet innan konfigurationen påbörjas:

• vilka arbeten Avanet får utföra,
• om WebAdmin räcker eller om SSH också behövs,
• när åtkomsten börjar och slutar,
• vilken Avanet-supportkälla som används,
• vem som godkänner åtkomsten och kontrollerar att den avvecklas.

En befintlig Avanet- eller partneråtkomst bör inte kompletteras med ytterligare ett permanent konto. Kontrollera i stället profil, MFA, källbegränsning och status för det befintliga kontot. För gemensam analys utan direktinloggning är skärmdelning ofta alternativet med lägst risk.

Konfigurera en WebAdmin-användare

Den allmänna processen för personliga konton, profiler, MFA och offboarding beskrivs i Konfigurera administratörer och profiler säkert på Sophos Firewall. Det här avsnittet kompletterar den med det supportspecifika fallet, inklusive tidsfönster, supportkälla och kontrollerad avveckling.

Den lokala användaren avanet är endast avsedd för WebAdmin-konsolen. En separat användare gör det enklare att koppla ändringar i Audit Trail till rätt person än om standardadministratören delas.

1. Öppna Authentication > Users.
2. Välj Add.
3. Ange användarnamn och visningsnamn.
4. Ställ in User type på Administrator.
5. Välj en lämplig Profile.
6. Ange ett starkt lösenord som endast används för denna åtkomst samt en e-postadress.

Typiska värden är Username avanet, Name Avanet och Email support@avanet.local. Profilen Administrator ger fullständig åtkomst till WebAdmin och CLI. Använd den endast om supportärendet verkligen kräver dessa rättigheter. För tydligt avgränsade uppgifter är en separat profil under Profiles > Device access med nödvändiga Read-only- eller Read-write-rättigheter ett bättre val.

Under Administrator advanced settings finns ytterligare två begränsningar:

• Schedule for device access: tillåter endast inloggning till WebAdmin-konsolen under det valda schemat.
• Login restriction for device access: tillåter endast inloggning från valda IPv4-adresser eller ett IPv4-intervall.

Om den fasta support-IP-adressen är känd bör den även anges under Login restriction for device access. Local Service ACL begränsar då åtkomsten till konsolen, medan användarbegränsningen även begränsar inloggningen för kontot. Spara med Save.

Testa lösenord och MFA i förväg

Lösenordet överförs via en överenskommen säker kanal och sparas inte permanent i e-post eller ärendetext. Om MFA för administratörer används ska konfigurationen av token, överlämningen och ansvaret för återställning klargöras före supporttillfället. Ett kort inloggningstest förhindrar att det egentliga underhållsfönstret inleds med problem kring lösenord, roller eller MFA.

Begränsa supportkällan och Local Service ACL

Skapa en FQDN-värd för support.avanet.com

Local Service ACL stöder FQDN-värdar som källa. Därmed behöver inte varje brandvägg anpassas manuellt om Avanets utgående IP-adress ändras under kontrollerade former. Brandväggen använder de adresser som DNS har löst upp tills DNS-TTL löper ut. Wildcard-FQDN stöds inte i Local Service ACL Exception Rules.

1. Öppna Hosts and services > FQDN host.
2. Välj Add.
3. Ange support.avanet.com för både Name och FQDN.
4. Spara med Save.

Kontrollera före nästa steg att support.avanet.com löser upp till den offentliga support-IP-adress som anges i ärendet. Om den faktiska utgående IP-adressen inte stämmer överens med DNS-resultatet kommer ACL-regeln att neka åtkomsten, vilket är det avsedda beteendet.

Skapa en Local Service ACL Exception Rule

HTTPS och SSH är lokala tjänster på brandväggen. Vanliga brandväggsregler styr inte denna trafik. Åtkomsten konfigureras därför under Administration > Device access.

1. Öppna Administration > Device access.
2. Kontrollera under Local service ACL att HTTPS och SSH inte är globalt aktiverade för WAN.
3. Rulla till Local service ACL exception rule och välj Add.
4. Skapa regeln med följande värden.

• Rule name: Avanet-Support
• Rule position: Top
• Description: ärendenummer, syfte och planerat slutdatum
• IP version: IPv4
• Source zone: WAN
• Source Network / Host: FQDN-objektet support.avanet.com
• Destination host: brandväggens offentliga adress eller Any om brandväggen behöver vara tillgänglig via flera lämpliga WAN-adresser
• Services: HTTPS; SSH endast vid bekräftat behov; Ping/Ping6 endast för en specifik diagnos
• Action: Accept

Spara med Save. Positionen Top säkerställer att den riktade åtkomsten utvärderas före en överlappande Drop-regel. Befintliga Exception Rules måste ändå kontrolleras. En bredare Accept-regel ovanför eller en felaktig källzon kan förändra den avsedda säkerhetsmodellen.

Använd inte: Any eller 0.0.0.0 som Source. Sophos förhindrar av goda skäl att WebAdmin-konsolen öppnas globalt från WAN. WAN-kryssrutan för HTTPS eller SSH får inte heller aktiveras för detta arbetsflöde.

Lägg endast till SSH vid behov

SSH ger åtkomst till Device Console och Advanced Shell och är därför betydligt mer långtgående än en begränsad WebAdmin-profil. I många supportärenden förblir Services därför begränsat till HTTPS.

Användaren avanet kan inte användas för SSH. Sophos Firewall accepterar endast standardanvändaren admin för CLI. Public Key läggs därför inte till för användaren avanet, utan globalt under Public key authentication for admin.

1. Öppna Administration.
2. Välj Device access.
3. Rulla till Public key authentication for admin.
4. Aktivera Enable authentication.
5. Klistra in den Public Key som har bekräftats för det aktuella ärendet under Authorized keys och lägg till den med plustecknet.
6. Välj Apply.

Endast standardadministratören kan lägga till eller ta bort SSH-nycklar. För en anpassad administratör visas inte Apply. Sophos stöder RSA-nycklar på minst 2048 bitar samt vissa DSA- och ECDSA-nycklar, men inte ED25519. En ny supportnyckel bör vara modern, tillräckligt stark och kompatibel med den SSH-klient som används.

En Public Key kan exempelvis ha följande struktur:

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

Den privata nyckeln stannar hos supportteknikern och lagras aldrig på brandväggen. Efter supportärendet tas ärendets Public Key bort och SSH tas bort från Exception Rule, om ingen permanent åtkomst har avtalats. Den praktiska inloggningen beskrivs i Ansluta till Sophos Firewall via SSH.

Testa åtkomsten och avgränsa fel

En lyckad inloggning från den tillåtna källan räcker inte som godkännandetest. Kontrollera också att åtkomst från en annan internetkälla förblir blockerad.

1. Öppna WebAdmin från den överenskomna Avanet-supportkällan via den konfigurerade administratörsporten. Standardporten är TCP 4444, men den kan ha ändrats under Administration > Admin and user settings.
2. Logga in som avanet och kontrollera att den valda profilen ger åtkomst till de menyer som behövs.
3. Använd en andra internetkälla som inte har godkänts. WebAdmin-konsolen ska inte vara tillgänglig därifrån.
4. Om SSH har tillåtits testar du inloggning som admin med ärendets Private Key. Lösenordsinloggning via SSH behövs inte för detta test.
5. Kontrollera autentiseringshändelserna i Log viewer. Konfigurationsändringar kontrolleras dessutom i Audit Trail.
6. Dokumentera testresultatet och åtkomstens sluttid i ärendet.

Om WebAdmin inte går att nå

Börja kontrollen vid källan och arbeta dig fram till brandväggen:

• Löser support.avanet.com upp till den faktiska offentliga utgående IP-adressen?
• Kommer åtkomsten verkligen från den zon som valts under Source zone?
• Stämmer den WAN-adress som används med Destination host?
• Ligger Exception Rule på Top och innehåller den HTTPS?
• Används rätt WebAdmin-port?
• Blockerar en operatörsrouter, en framförliggande NAT-enhet eller en upstream-ACL åtkomsten?
• Hindrar Login restriction for device access inte TCP-anslutningen, men användaren från att logga in?

De globala WAN-kryssrutorna för HTTPS eller SSH aktiveras inte vid felsökning. Om Exception Rule är korrekt behövs de inte för denna riktade åtkomst.

Om inloggningen misslyckas

Om konsolen går att nå men inloggningen misslyckas kontrollerar du användarstatus, lösenord, MFA, profil, Schedule for device access, Login restriction for device access och de systemomfattande inställningarna för blockering av inloggningar under Administration > Admin and user settings. Efter flera misslyckade försök kan Sophos Firewall tillfälligt blockera käll-IP-adressen för alla inloggningstjänster.

Avveckla åtkomsten kontrollerat

När supportärendet är avslutat kontrolleras de överenskomna ändringarna och själva åtkomsten separat:

1. Kontrollera i Audit Trail vilka konfigurationsändringar som utfördes med avanet.
2. Vid större ändringar i regelverket kan Sophos Firewall Config Studio underlätta en jämförelse före och efter.
3. Inaktivera eller ta bort användaren avanet om ingen permanent partneråtkomst har avtalats.
4. Inaktivera eller ta bort Local Service ACL Exception Rule.
5. Ta bort ärendets SSH Public Key.
6. Kontrollera från den tidigare supportkällan att WebAdmin och SSH inte längre går att nå.

En partneråtkomst som medvetet behålls kräver fortfarande MFA, en strikt begränsad källa, en ansvarig person och regelbunden kontroll. Ett inaktivt ärende är inget skäl att lämna administrativ åtkomst permanent öppen.

Vanliga frågor