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.

Diagnostics > Support access ersätter inte den här proceduren. Funktionen skapar ett tidsbegränsat Access ID enbart för Sophos Support, som får åtkomst till WebAdmin och skalet utan administratörsuppgifter. Dela inte detta ID med Avanet.

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.

Avanet måste ange den exakta offentliga utgående IP-adressen eller ett uttryckligen avsett FQDN i det autentiserade ärendet. Källan ska varken härledas från en webbplats eller gissas. Öppna och testa före ändringen en oberoende hanteringsväg via konsol, management-LAN, administratörs-VPN eller Sophos Fusion (tidigare Sophos Central).

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.

Ett lokalt ärendekonto, exempelvis avanet-<ticket>, är endast avsett för WebAdmin och gör ändringar i Audit Trail lättare att hänföra. SFOS sparar namnet med gemener och det kan inte ändras senare.

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.

Som Username kan avanet-<ticket> användas, där <ticket> ersätts med internt ärendenummer. Guiden publicerar avsiktligt varken lösenord eller supportadress. Profilen Administrator ger full WebAdmin-åtkomst och används endast när uppdraget kräver det. Börja annars under Profiles > Device access med Read-only och ge Read-write enbart för godkända ändringar.

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 säker kanal och placeras inte i e-post eller ärende. Under Authentication > Multi-factor authentication väljer du Specific users and groups för OTP, lägger till ärendekontot och markerar Web admin console under Require MFA for. Hemlighet, QR-kod och engångskoder hör inte hemma i ärendet. Om MFA inte är tekniskt möjligt används skärmdelning eller VPN i stället för att utelämna MFA. Se MFA för administratörer.

Begränsa supportkällan och Local Service ACL

Skapa källobjektet som bekräftats i ärendet

För ett kort underhållsfönster ger en IP-värd med endast den bekräftade offentliga adressen minst förtroendeyta. Om ärendet uttryckligen anger ett FQDN stöder Local Service ACL också en FQDN-värd och litar på alla upplösta adresser tills DNS-TTL löper ut. Wildcard-FQDN stöds inte.

1. För en fast IP-adress öppnar du Hosts and services > IP host, väljer Add och sparar den bekräftade adressen som en enda IPv4-värd.
2. Endast för ett bekräftat FQDN öppnar du Hosts and services > FQDN host och väljer Add.
3. Ange ett ärendespecifikt Name och kopiera det exakta ärendevärdet till FQDN.
4. Spara med Save, öppna objektet igen och kontrollera det.

För ett FQDN jämförs samtliga upplösta adresser med ärendet. En oväntad eller obekräftad adress är ett stoppvillkor: använd den enda bekräftade IP-adressen eller be Avanet om ett förtydligande.

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: exakt det bekräftade IP- eller FQDN-objektet
• 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:

• Stämmer den faktiska utgående IP-adressen med källobjektet och, för FQDN, aktuell DNS-upplösning?
• 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 först bort Local Service ACL Exception Rule så att den externa vägen stängs.
4. Kontrollera från den tidigare källan att WebAdmin och SSH inte nås och att den oberoende hanteringsvägen fortfarande fungerar.
5. Ta bara bort ärendets SSH-nyckel; stäng av Enable authentication endast om inga andra nycklar är beroende av funktionen.
6. Inaktivera eller ta bort ärendekontot och dess MFA-token om permanent åtkomst inte uttryckligen har godkänts.
7. Låt en andra person jämföra ACL, konto, nycklar, Audit Trail och ärende med utgångsläget.

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