Ansluta till Sophos Firewall via SSH

För många support- och felsökningsuppgifter behöver du tillgång till Sophos Firewall via SSH. Dessa inkluderar till exempel logganalyser, serviceomstarter, speciella diagnoskommandon eller arbete i Advanced Shell.

Men SSH är också en managementaccess med hög risk. Åtkomst bör därför endast tillåtas från pålitliga administratörsnätverk, via en riktad Local Service ACL-undantagsregel eller via tydligt definierad supportåtkomst. För generell härdning av lokala brandväggstjänster är Konfigurera Device Access korrekt också lämpligt.

Krav

För en SSH-anslutning till Sophos Firewall behöver du:

• Administrativ åtkomst till Sophos Firewall.
• Brandväggens IP-adress eller DNS-namn.
• Tillgång till användaren admin.
• Ett ändrat och säkert dokumenterat lösenord för standardadministratören; fabrikslösenordet får inte fortsätta användas i produktion.
• En pålitlig administratörskälla, till exempel hanteringsnätverk, VPN eller fast admin-IP.
• På macOS eller Linux: den förinstallerade Terminal-appen med SSH.
• På Windows: Windows Terminal med OpenSSH eller PuTTY.
• Tillåten SSH-åtkomst under Administration > Device access eller via en Local service ACL exception rule.
• Vid planerade ändringar i Advanced Shell: säkerhetskopia, underhållsfönster och en tydligt fastställd plan för att återställa ändringarna om problem uppstår.

⚠️ SSH bör endast tillåtas från betrodda nätverk. För produktiva miljöer är det bättre att begränsa åtkomsten till ett hanterings-IP eller adminnätverk i stället för att släppa SSH generellt.

Fastställa vad SSH behövs för

Inte varje analys behöver Advanced Shell. Innan du loggar in bör det vara klart vilken konsol som krävs och hur allvarligt ingreppet är.

• Routing, DNS, Ping, enkla systemkommandon: Device Console. Sophos CLI, mindre riskabel än Advanced Shell.
• Detaljerad systeminformation, databaser eller systemtjänster: Advanced Shell kan behövas. Utan tillförlitliga, ärendespecifika Sophos-anvisningar bör du begränsa dig till skrivskyddade kontroller och inte ändra eller ta bort något.
• Kontrollera tjänststatus eller debug: Advanced Shell. Aktivera debug endast för ett avgränsat syfte och inaktivera det därefter igen.
• Okända kommandon: Kontrollera kommandot först, återskapa det i en testmiljö eller öppna ett supportärende. Prova det inte i produktionssystemet.

Skillnaden är viktig eftersom Device Console och Advanced Shell använder olika syntax. Många fel uppstår helt enkelt för att ett korrekt kommando har skrivits in på fel ställe. En bredare översikt finns i Sophos Firewall Felsökning: Services och loggar.

Tillåta SSH-åtkomst till brandväggen

För att en anslutning ska vara möjlig måste Sophos Firewall tillåta SSH på lämplig zon eller via en Local Service ACL undantagsregel.

1. Logga in i WebAdmin på Sophos Firewall.
2. Öppna Administration.
3. Välj Device access.
4. Kontrollera under Local service ACL om SSH är tillåtet för den avsedda betrodda administrationszonen. Anteckna det aktuella läget innan du gör någon ändring.
5. Om du medvetet vill tillåta åtkomst för hela denna zon aktiverar du SSH endast för den zonen och sparar med Apply. Inställningar som redan är korrekta behöver inte ändras igen.

För ett betrott internt administrationsnätverk kan exempelvis LAN vara rätt zon. En åtkomstbehörighet för en zon gäller dock inte bara en enskild administratörsdator. För att begränsa åtkomsten till en administratörs-IP eller ett hanteringsnätverk använder du i stället den Local service ACL exception rule som beskrivs nedan; bred åtkomst för hela zonen är inte ett ytterligare obligatoriskt steg. Aktivera inte SSH generellt för WAN.

Device Access styr åtkomst till själva brandväggen. Detta är inte samma sak som en vanlig brandväggsregel som tillåter trafik genom brandväggen. Om SSH i Device Access är aktiverat för brett kan en klient nå brandväggens lokala SSH-tjänst även om en klassisk LAN-to-WAN-regel är korrekt konfigurerad.

Den webbaserade CLI-konsolen är en annan åtkomstväg än en SSH-klient: SSH-klienten använder TCP 22, medan webbläsarkonsolen använder HTTPS-åtkomsten till WebAdmin. För åtkomst via webbläsaren öppnar du Administration > Device access, kontrollerar behörigheten HTTPS under Local service ACL för den avsedda betrodda administrationszonen och aktiverar den vid behov med Apply. Öppna sedan administratörens rullgardinsmeny längst upp till höger i WebAdmin och välj Console. SSH-behörighet krävs inte för denna åtkomstväg via webbläsaren. Inte heller HTTPS ska öppnas generellt för WAN; befintliga källbegränsningar ska behållas.

För valet av konto gäller den dokumenterade begränsningen i SFOS 22 och 23: PuTTY-anvisningarna kräver uttryckligen admin och utesluter andra användarnamn, även vid inloggning med lösenord. Profilbeskrivningen ger visserligen profilen Administrator fullständig CLI-åtkomst och tillåter att den tilldelas ytterligare administratörer, men anger ingen transportmetod för denna åtkomst. En rollbehörighet är därför ingen garanti för att ett namngivet konto kan logga in via SSH över nätverket. Inte heller bekräftas här någon generell åtkomst till webbläsarkonsolen för varje namngivet konto. Innan en åtkomstväg används som reservlösning ska den konkreta åtkomsten kontrolleras med det avsedda kontot på den installerade SFOS-versionen. Om Console saknas eller åtkomsten nekas ska befintliga fungerande sessioner hållas öppna; kontrollera kontot, profilen och åtkomstvägen och klargör vid behov ärendet med Sophos Support i stället för att utöka WAN- eller ACL-behörigheter. Följande SSH-steg använder fortsatt admin; den exklusiva hanteringen av SSH Public Keys av standardadministratören är en separat behörighet.

Före ändringen bör du anteckna i vilka zoner SSH är aktiverat och vilka SSH-undantag som redan finns. Då kan utgångsläget återställas utan att en annan avsiktlig behörighet tas bort.

Klicka på Add under Local service ACL exception rule och ange så snäva värden som möjligt:

• Name: exempelvis SSH-fran-adminnat; valfritt men entydigt
• Rule position: undantagets position i Local Service ACL
• Description: syfte, ansvarigt team och slutdatum för tillfällig åtkomst
• IP version: IPv4 eller IPv6 som matchar adminkällan och destinationsadressen
• Source zone: zonen från vilken administrationen sker
• Source Network / Host: administratörs-IP eller hanteringsnätverk
• Destination host: brandväggens IP eller det gränssnitt som ska administreras, om åtkomsten även kan begränsas till en konkret destinationsadress
• Services: SSH
• Action: Accept

Spara med Save. För ett enda administrationssystem kan Source Network / Host exempelvis vara ett värdobjekt med 192.0.2.10. Det är en dokumentationsadress som ska ersättas med administratörens verkliga, helst fasta IP-adress. Destination host begränsar dessutom via vilken brandväggs-IP tjänsten kan nås. Inkludera inte alla gränssnitt utan ett operativt skäl.

Öppna en ny SSH-session från den avsedda administratörskällan. Testet lyckas när konsolmenyn visas. Testa sedan från ett avsiktligt otillåtet nätverk och bekräfta att ingen session upprättas. Om resultatet är oväntat låter du den befintliga WebAdmin-sessionen vara öppen och kontrollerar käll-IP, Source zone, IP version, Destination host, regelposition och överordnade filter.

Om åtkomsten var tillfällig tar du endast bort detta undantag under Administration > Device access > Local service ACL exception rule och bekräftar med OK. Om du i stället ändrade en zonkryssruta återställer du endast dess antecknade läge och klickar på Apply. Testa sedan från samma källa och kontrollera att SSH åter är åtkomligt eller blockerat precis som före ändringen. På så sätt verifierar testet utgångsläget utan att förutsätta att inloggningen alltid ska lyckas eller misslyckas.

SSH ska inte vara tillgänglig okontrollerat från Internet. Om extern åtkomst är nödvändig bör detta endast tillåtas via en tydligt definierad käll-IP, VPN eller dedikerad supportåtkomst.

Diagnostics > Support access är en separat mekanism. Den öppnar inte bara SSH från internet, utan ger Sophos Support tillfällig åtkomst via en supportkanal som brandväggen etablerar. Även denna åtkomst bör tidsbegränsas och stängas av efter supportärendet.

När Support access aktiveras väljer man en varaktighet; därefter genererar brandväggen ett unikt Access ID för Sophos Support. Detta Access ID förblir giltigt under den valda perioden; Support access kan stängas av i förtid när som helst. Sophos Support kan därmed få åtkomst till WebAdmin och skalet utan att behöva vanliga administratörsuppgifter. Brandväggen upprättar själv de utgående supportanslutningarna för både HTTPS och SSH via TCP 22; ur ett driftsperspektiv är detta något annat än att tillåta inkommande SSH från WAN.

Före varje aktivering – även i WebAdmin – kontrollerar du först den befintliga supportkanalen under 4. Device Console med det skrivskyddade kommandot:

show support_access

Kommandot visar om Support access är aktivt och, vid aktiv åtkomst, även Access ID och varaktighet. Dokumentera utgångsläget samt eventuell visad varaktighet och Access ID uteslutande i det autentiserade, tillhörande supportärendet. Informationen som visas bevisar inte i sig vilket ärende kanalen tillhör; klargör denna koppling och samtycket till åtkomsten med det ansvariga teamet och Sophos Support.

Om en kanal redan är aktiv för ett annat ärende eller om det är oklart vem som ansvarar för den, avbryter du och samordnar nästa steg utan att aktivera kanalen igen, ersätta den eller stänga av den. En aktiv kanal som redan är godkänd för samma ärende ska inte heller aktiveras på nytt; dess fortsatta användning och avslut samordnas inom det befintliga ärendet. Det fristående arbetsflödet för att aktivera, analysera och inaktivera får endast påbörjas när utgångsläget är bekräftat inaktivt och uttryckligt samtycke finns för detta supportärende. Denna förutsättning gäller för båda följande åtkomstvägar.

För WebAdmin-metoden öppnar man Diagnostics > Support access, aktiverar Support access och bekräftar med OK. Därefter väljer man den tid som behövs för det aktuella supportärendet, klickar på Apply och bekräftar igen med OK. Brandväggen etablerar en säker kontrollanslutning till sin åtkomstproxy; det genererade access ID finns under Access status och lämnas endast till Sophos Support via den överenskomna supportkanalen.

Styra Support access från Device Console

SFOS 22 kan även aktivera supportkanalen under 4. Device Console. Omedelbart före skrivkommandot utför du där återigen den kontroll med show support_access som beskrivs ovan. Aktivera endast kanalen om den är bekräftat inaktiv och samtycke finns för detta ärende:

set support_access enable

Efter en lyckad aktivering visar kommandot Access ID och åtkomstens varaktighet. Stäm av den varaktighet som faktiskt visas mot det ärendespecifika samtycket; den dokumenterade CLI-syntaxen innehåller ingen parameter för att ställa in en varaktighet. Om du behöver en viss varaktighet använder du den WebAdmin-metod som beskrivs ovan, efter samma föregående kontroll. Access ID och varaktighet lämnas endast i det autentiserade, tillhörande supportärendet och kopieras inte till allmän dokumentation, chattar eller lösenordsvalv.

Efter avslutad analys stänger du, oavsett återstående tid, endast av den egna kanal som har upprättats med samtycke för detta ärende. Kontrollera först med show support_access och det dokumenterade Access ID att det fortfarande är samma kanal. Om den redan är inaktiv behövs inget skrivkommando; om ID skiljer sig eller om det är oklart vem som ansvarar för kanalen, avbryter du och samordnar nästa steg i stället för att stänga av en kanal som kan tillhöra någon annan:

set support_access disable

Kontrollera därefter under Diagnostics > Support access eller med show support_access att den egna kanalen inte längre är aktiv. disable ändrar varken den vanliga SSH-konfigurationen under Device Access eller Local Service ACL Exception Rules; tillfälliga administratörs- och SSH-behörigheter återställs därför separat till det tidigare antecknade läget, och endast i den omfattning som motsvarar den egna ändringen.

Om det finns en annan router eller ett utgående filter framför brandväggen måste den tillåta TCP 22 till *.apu.sophos.com. Ingen inkommande WAN-regel skapas för detta på Sophos Firewall. Inaktiva supportsessioner stängs efter 15 minuter; den valda totala varaktigheten och möjligheten att stänga av Support access manuellt är oberoende av denna tidsgräns.

Kontrollera utgående tjänster och portar för Sophos Firewall sammanställer övriga tillverkarmål för uppdateringar, licenser, RED, Central, reporting och backup.

Support access via XML API: klargör före skrivåtkomst

XML-API-hjälpen för SFOS 22 och 23 benämner objektet SupportAccess, men innehåller två motsägelser: I XML-exemplet heter taggen för varaktighet GrantAccessFor, men i parametertabellen GrantAccessForr. För ConfigOption anger tabellen standardvärdet ON, men tillåter endast Enable och Disable. Av detta går det varken att härleda ett giltigt värde ON i en begäran eller att supportåtkomsten är aktiv som standard. Klarlägg giltig taggstavning för den installerade builden i API help eller med Sophos Support före ett skrivande anrop.

Tabellen markerar båda fälten som valfria skalära värden och anger tidsperioderna 1 day, 2 days, 1 week, 2 weeks, 1 month och 2 months. Detta klargör inte vad som faktiskt händer om ett fält utelämnas. Före en automatiserad ändring kontrollerar man därför den objektspecifika API-hjälpen för den installerade SFOS-builden och låter Sophos Support klargöra öppna frågor om taggen, värdena eller beteendet när fält utelämnas. Så länge motsägelsen inte har klarlagts stoppas XML-skrivåtkomsten; man hittar inte på någon payload och provar inte båda stavningarna i produktionssystemet. För ett godkänt supportärende är den ovan beskrivna WebAdmin-metoden fortfarande alternativet, utan att utöka WAN- eller ACL-behörigheter.

Referensen anger för denna operation 200 med Operation Successful. och 500 med Operation Fail.. Kontrollera det konkreta objektsvaret i stället för att blint upprepa en misslyckad eller oklar skrivåtkomst. Efter en bekräftad ändring kontrollerar man det faktiska aktiveringsläget och varaktigheten under Diagnostics > Support access respektive med det ovan beskrivna show support_access. Efter supportärendet inaktiverar du endast den egna kanal som är godkänd för detta ärende, med de ansvarskontroller som beskrivs ovan, och kontrollerar att den är inaktiv; tillfälliga SSH-/ACL-behörigheter återställs fortfarande separat.

Lägga till en publik nyckel för admin

För SSH-åtkomst är autentisering med publik nyckel den föredragna metoden. På Sophos Firewall kan den publika nyckeln för användaren admin lagras under Administration > Device access. Lösenordsinloggning kan vara nödvändig i nödsituationer, men bör inte förbli den mest bekväma standardåtkomsten.

⚠️ En SSH-inloggning till Sophos Firewall är endast möjlig med användaren admin. Andra WebAdmin-användare kan inte logga in via SSH.

Viktigt: Endast standardadministratören kan ändra autentiseringen med publik nyckel för SSH, det vill säga lägga till eller ta bort SSH-nycklar. Sådana ändringar av SSH-nycklar ska ingå i en dokumenterad administrationsprocess och är inte en spontan genväg för support.

Standardadministratören är inte ett vanligt rollkonto som bara kan ersättas. Sophos anger att kontot inte kan döpas om eller tas bort. Standardadministratörens lösenord, MFA- eller återställningsinformation för interaktiva administratörsinloggningar och lagrade publika SSH-nycklar bör därför hanteras tillsammans i den administrativa driftprocessen. En publik nyckel ersätter inte korrekt hantering av kontot.

Namngivna WebAdmin-administratörer hanteras separat och kan inte logga in via SSH med sina egna användarnamn. Hantera lokala administratörer och Device Access-profiler enligt principen om minsta behörighet beskriver livscykeln och behörigheterna för dessa konton.

Innan du lagrar den publika nyckeln på brandväggen genererar du ett matchande par av en publik och en privat nyckel på din egen administratörsklient med ett SSH-nyckelverktyg. Ett befintligt, lämpligt och matchande nyckelpar kan återanvändas. Följ anvisningarna i nästa avsnitt om SSH-nyckeltyper som stöds när det gäller nyckeltyp och nyckellängd. Lagra och skydda den privata nyckeln uteslutande på administratörsklienten; dela den aldrig och ladda aldrig upp den till brandväggen. Kopiera endast den publika nyckeln för de följande stegen.

Den publika nyckeln läggs till i området Public key authentication for admin:

1. Öppna Administration.
2. Välj Device access.
3. Bläddra till området Public key authentication for admin.
4. Aktivera Enable authentication.
5. Lägg till den publika nyckeln under Authorized keys.
6. Spara med Apply.

Låt den befintliga WebAdmin- eller SSH-sessionen vara öppen medan du testar den nya nyckeln i en andra SSH-session. Ta inte bort en gammal nyckel eller ändra reservinloggning med lösenord förrän konsolmenyn visas i den andra sessionen. Om testet misslyckas finns den befintliga åtkomsten kvar: kontrollera nyckeltyp, registrerad publik nyckel, matchande privat nyckel och tillåten källa och ta endast bort den nytillagda felaktiga posten.

Den privata nyckeln finns alltid kvar på administratörsklienten och får inte delas. Endast den publika nyckeln lagras på brandväggen.

Om flera administratörer använder SSH ska inte samma privata nyckel delas. Det är bättre att ha separata administratörsklienter, dokumenterade publika nycklar och en genomgång av vilka nycklar som fortfarande behövs. Efter byten av personal eller tjänsteleverantörer bör området Authorized keys kontrolleras.

Nyckeltyper för SSH som stöds

Inte alla moderna SSH-nyckeltyper är lika lämpliga för Sophos Firewall. Innan du rullar ut bör du kontrollera om nyckeltypen stöds.

• RSA: Använd minst 2048 bitar.
• DSA: Minst 2048 bitar, om nödvändigt av kompatibilitetsskäl.
• ECDSA: Stöd; ED25519 accepteras inte för detta ändamål.
• ED25519: För SSH Public Key Authentication, använd inte på Sophos Firewall.

För ny administratörsåtkomst är en korrekt hanterad RSA eller ECDSA-nyckel som stöds vanligtvis mer pragmatisk än en modern nyckeltyp som brandväggen eller ett äldre SSH-verktyg inte accepterar.

Ansluta från macOS eller Linux

En SSH-klient finns vanligtvis redan på macOS och Linux. Anslutningen upprättas i terminalen.

Exempel:

ssh admin@192.0.2.1

192.0.2.1 ersätts av IP-adressen eller DNS-namnet för din egen Sophos Firewall.

När anslutningen upprättas för första gången frågar SSH-klienten om målsystemets fingeravtryck ska accepteras. Kontrollera fingeravtrycket innan du bekräftar det. Om en varning om en ändrad värdnyckel visas efter en ominstallation av brandväggens systemavbildning, ett maskinvarubyte eller en IP-ändring ska du inte acceptera det nya fingeravtrycket utan kontroll. Kontrollera först om den aktuella brandväggen faktiskt har ersatts, installerats om eller fått en ny IP-adress. Först därefter kan du ta bort den gamla posten i ~/.ssh/known_hosts och acceptera det nya fingeravtrycket.

Beroende på konfigurationen begärs sedan lösenordet för användaren admin eller så utförs inloggningen med den lagrade SSH-nyckeln.

Om en specifik privat nyckel ska användas:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

För återkommande åtkomst dokumenterar du sökvägen till den privata nyckeln, den tillåtna käll-IP-adressen och syftet. Posten i known_hosts ska inte kopieras till ärenden eller chatthistorik. Vid värdnyckelvarningar är ändringshistoriken viktigare än en snabb kringlösning.

Ansluta med PuTTY

Under Windows kan du antingen använda Windows Terminal med OpenSSH eller använda PuTTY.

Med Windows Terminal fungerar upprättandet av en anslutning på samma sätt som macOS eller Linux:

ssh admin@192.0.2.1

För PuTTY: Om programmet inte redan finns laddar du först ned det från den officiella nedladdningssidan för PuTTY och installerar det på administratörsdatorn. Upprätta sedan anslutningen:

1. Öppna PuTTY.
2. Ange IP-adressen eller DNS-namnet för Sophos Firewall under Host Name.
3. Ställ in Port till 22.
4. Ställ in Connection type till SSH.
5. Anslut med Open.
6. Kontrollera och bekräfta SSH-fingeravtrycket.
7. Logga in som användare admin och använd lösenord eller SSH nyckel beroende på konfigurationen.

Efter inloggning visas konsolmenyn för Sophos Firewall.

Om PuTTY används med en privat nyckel måste nyckeln matcha den publika nyckeln som finns lagrad på brandväggen. Efter byte av personal eller tjänsteleverantör bör inte bara lösenordet ändras; gamla offentliga nycklar måste också tas bort från Authorized keys.

Öppna Device Console eller Advanced Shell

Efter en lyckad inloggning visas Main Menu. Följande återgivning ger en översikt över menyalternativen:

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

Vid prompten Select Menu Number [0-7]: anger du numret för önskat menyalternativ, exempelvis 1 för Network Configuration. För diagnostikkommandon är särskilt de följande två åtkomstvägarna viktiga. 7. Shutdown/Reboot Device leder till åtgärder som kan avbryta driften; detta menyalternativ ska inte användas för att prova sig fram.

För många SFOS-kommandon använder du:

4. Device Console

För djupare Linux- eller filsystemuppgifter, använd Advanced Shell via:

5. Device Management
3. Advanced Shell

Advanced Shell erbjuder mycket omfattande åtkomst till systemet. Kommandon ska endast köras där om det är tydligt vad de gör.

Enligt Sophos överlever konfigurationsändringar som görs direkt i Advanced Shell, exempelvis av gränssnitt, regler eller policyer, inte en omstart och ingår inte i säkerhetskopior. Det är därför inte en normal konfigurationsväg. Filer under /tmp/ tas också bort vid omstart.

• Device Console: ping, dnslookup, traceroute, show, routing eller systemalternativ.
• Advanced Shell: detaljerad systeminformation, databaser, systemtjänster och ärendespecifik diagnostik på anvisning av Sophos Support.

För logganalys, tjänstnamn och typiska felmönster är Sophos Firewall Felsökning: Services och loggar en bättre utgångspunkt än att memorera enskilda kommandon.

Förstå kommandofamiljerna set och system

I 4. Device Console definierar set inställningar och parametrar för olika systemkomponenter, medan system konfigurerar systemparametrar. Båda familjerna kan ändra konfigurationen. Använd därför bara hjälpen för att lära känna dem, inte ett fullständigt ändringskommando. Dokumentationen för SFOS 22 och 23 använder dessa allmänna syntaxmönster – de är inte kommandon att kopiera:

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set eller system är det fasta prefixet och skrivs exakt som det visas.
• Ersätt [command] med det dokumenterade kommando som behövs, exempelvis advanced-firewall för set eller firewall-acceleration för system.
• [option 1|option 2] betyder att man väljer ett av de dokumenterade alternativen. Skriv inte hakparenteserna eller |; här betyder de inte att valet bara kan utelämnas.
• <value> är en platshållare för ett värde som passar det valda alternativet. Ersätt den, inklusive vinkelparenteserna, med det värde som behövs. Vilka argument som faktiskt krävs avgörs av hjälpen för det specifika kommandot, inte enbart av det allmänna mönstret.

Endast syntaxförklaring – kör inte: i tillverkarens exempel set advanced-firewall icmp-error-message allow är set prefixet, advanced-firewall det valda kommandot, icmp-error-message alternativet och allow det konkreta värdet som ersätter <value>. Det är en konfigurationsändring, inte ett nödvändigt SSH-steg. Exemplet system firewall-acceleration enable är inte heller en övning: system är prefixet, firewall-acceleration det valda kommandot och enable det valda alternativet. Det specifika exemplet innehåller inget ytterligare värde; lägg inte till <value> utan kontroll och aktivera inte accelerationen för att prova.

För att utforska säkert skriver man bara set i Device Console och trycker tre gånger på Tab för att visa de tillgängliga inställningarna. Tab följt av ? visar beskrivningarna. Upprepa med prefixet system för att utforska den andra familjen. Det förväntade resultatet är hjälptext, inte en ändrad inställning. Rensa sedan inmatningsraden utan att skicka ett ändringskommando med Enter. Om den förväntade hjälpen saknas kontrollerar man först konsolen och dokumentationen för den installerade SFOS-versionen i stället för att prova ett exempelkommando.

Avsluta anslutningen

⚠️ De äldre Device Console-kommandona enableremote och disableremote är inte ett normalt sätt att logga ut: för SFOS 22 och 23 beskriver Sophos att disableremote inte bara förhindrar nya SSH-anslutningar på port 22, utan också avslutar befintliga SSH-sessioner. Kör därför inte dessa kommandon för att logga ut eller återkalla en tillfällig ACL-behörighet. Före varje uttryckligen godkänd användning av dessa kommandon måste en fungerande återställningsväg som är oberoende av nätverks-SSH ha testats: en lokal seriell konsol eller out-of-band-konsol för fysiska appliances, eller lämplig plattformskonsol för virtuella brandväggar eller molnbrandväggar. Utan denna åtkomst och en återställningsplan som har bekräftats för den installerade versionen ska du avbryta och reda ut ärendet med Sophos Support. Beskrivningen av enableremote nämner en Ethernet-port; här härleds varken någon TCP-portsyntax eller något generellt omvänt kommando från detta. För tillfälliga åtkomstbehörigheter gäller fortfarande den exakta återställning som beskrivs ovan under Administration > Device access; den utgående kanal som upprättas under Diagnostics > Support access är separat.

I Advanced Shell använder du följande kommando för att lämna skalet. Det ersätter inte valet av ett nummer i konsolmenyn:

exit

Om du befinner dig i en undermeny återgår du först till Main Menu. Där avslutar 0. Exit konsolsessionen: ange 0 vid menyprompten. Skalkommandot och menynumret används alltså på olika ställen.

Sophos Firewall stänger inaktiva SSH-sessioner efter 15 minuter. Det ersätter inte en ren utloggning: öppna sessioner, debug-lägen och tillfälliga åtkomstregler ska ändå stängas eller tas bort medvetet.

Om SSH-åtkomsten endast tilläts för ett supportärende återkallar du därefter exakt den tillfälliga åtkomstbehörigheten. En Local service ACL exception rule som skapades för detta tas bort enligt beskrivningen ovan; en ändrad zonkryssruta återställs till det tidigare antecknade läget och sparas med Apply. Andra behörigheter som fortfarande behövs behålls. Detta är särskilt viktigt för externa käll-IP-adresser eller åtkomst för tjänsteleverantörer.

Efter djupa ingrepp bör även följande kontrolleras:

• Är debugläget inaktiverat igen?
• Har en tillfällig undantagsregel för ACL tagits bort eller inaktiverats?
• Finns det inga tillfälliga filer, supportdumpar eller paketfångster kvar i onödan på brandväggen?
• Är loggutdrag, tidpunkt, kommando och resultat dokumenterade i supportärendet eller ändringsärendet?
• Användes SSH-nyckeln endast för den planerade administratörs- eller supportåtkomsten?

Vanliga problem

Anslutning nekas

Om anslutningen nekas är SSH ofta inte tillåtet för den valda zonen eller källan. Kontrollera därför SSH-inställningen och befintliga Local service ACL exception rule-poster under Administration > Device access. Ta också reda på om en bredare åtkomstbehörighet för zonen har återkallats avsiktligt. En sådan begränsning ska inte tas bort utan föregående kontroll.

Tidsgräns för anslutningen

En timeout indikerar ofta att brandväggen inte kan nås via den valda IP-adressen, en rutt saknas eller en uppströmsbrandvägg blockerar åtkomst.

Om en brandvägg som ännu inte är färdigkonfigurerad fortfarande använder det fabriksinställda standardlösenordet avvisar SFOS avsiktligt SSH-anslutningar från WAN-zonen utan felmeddelande. Det är en skyddsfunktion. Ändra först lösenordet via en tillåten lokal administrationsväg; bredda inte Device Access eller ACL som en genväg.

Ingen nätverksåtkomst till brandväggen

Om varken WebAdmin eller SSH kan nås ska du inte förhastat tillåta ytterligare WAN- eller zonåtkomst. För en fysisk enhet är den lokala seriella konsolen reservvägen, exempelvis vid felaktiga inställningar för Device Access, routing eller felaktigt tilldelade gränssnittszoner. Använd rätt RJ45-konsolkabel eller, på modeller som stöder det, Micro-USB och ställ in 38400 baud i terminalprogrammet.

Om Micro-USB och RJ45 är anslutna samtidigt har Micro-USB företräde och brandväggen omdirigerar konsolutmatningen dit. Om terminalen är tom kontrollerar du först att rätt seriell port används, kabeln och denna prioritet. Värdet 38400 baud är nedtonat i BIOS för att förhindra oavsiktliga ändringar; försök därför inte ändra det där.

De konkreta anslutningsstegen finns under Öppna en seriell anslutning. Om lösenordet för admin är känt loggar du in med det efter att anslutningen har upprättats och behöver inte återställa lösenordet. Använd endast anslutningsstegen i den länkade artikeln, inte dess återställningsprocedur. Anslutningen har lyckats när konsolmenyn visas; för virtuella brandväggar eller molnbrandväggar krävs i stället den konsolåtkomst som passar respektive plattformstyp.

Inloggningen misslyckas

Om inloggningen misslyckas ska användaren admin, lösenordet eller SSH-nyckeln och de tillåtna källnätverken kontrolleras. Typiska meddelanden som Permission denied (publickey,password) indikerar ett felaktigt lösenord, en felaktig privat nyckel eller en saknad offentlig nyckelkonfiguration.

Om inloggningen med publik nyckel misslyckas, kontrollera dessutom nyckeltyp, nyckellängd, felaktig privat nyckel, PuTTY nyckelformat och posten under Authorized keys. En korrekt tillåten SSH-tjänst hjälper inte om nyckeln inte matchar den lagrade publika nyckeln.

Om standardadministratörens lösenord verkligen har gått förlorat beskriver Återställ adminlösenordet på Sophos Firewall den seriella återställningsvägen utan fullständig Factory Reset. Denna väg gäller fysiska appliances med konsolanslutning; för virtuella brandväggar och cloud-brandväggar måste plattformskonsolen och den återställningsväg som stöds kontrolleras.

Värdnyckelvarning visas

En värdnyckelvarning kan vara ofarlig om en brandvägg har installerats om eller ersatts. Varningen kan också indikera ett felaktigt målsystem eller en sammanblandning av IP-adresser. Kontrollera därför först brandvägg, IP-adress, DNS och ändringshistorik. Först då bör den gamla known_hosts-posten tas bort.

Fel konsol öppnad

Om ett dokumenterat Sophos CLI-kommando inte känns igen kan fel konsol vara öppen eller syntaxen vara ofullständig. I Device Console visar Tab tillgängliga kommandon och argument; ? visar beskrivningarna. Ange inte Linux-shellinstruktioner där och prova inte odokumenterade kommandon i Advanced Shell heller.

Operationell checklista

• Tillåt endast SSH från betrodda administratörskällor.
• Ändra det fabriksinställda standardlösenordet innan SSH används i produktion.
• Använd om möjligt en Local service ACL exception rule i stället för bred åtkomst för en hel zon.
• Föredra autentisering med publik nyckel för kontot admin framför lösenordsinloggning.
• Dokumentera standardadministratörens lösenord, MFA- och återställningsinformation samt SSH-nycklar separat.
• Använd en nyckeltyp som stöds och dokumentera nyckellängden.
• Dela inte privata nycklar.
• Kontrollera SSH-fingeravtrycket vid första inloggningen.
• Hantera värdnyckelvarningar efter ominstallation eller maskinvarubyte medvetet.
• Blanda inte ihop Device Console och Advanced Shell.
• Gör endast ändringar i Advanced Shell med ett tydligt syfte.
• Återkalla tillfälliga SSH-åtkomstbehörigheter efter supportärenden.
• Ta bort gamla publika nycklar efter personalbyten eller byten av tjänsteleverantör.

Vanliga frågor