Sophos Firewall: Device Access och Local Service ACL

Under Administration > Device access anges från vilka zoner lokala tjänster på Sophos Firewall kan nås. Dessa omfattar HTTPS för WebAdmin och API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal och VPN Portal.

Dessa tjänster terminerar direkt på brandväggen och utgör dess hanterings- och serviceyta. Om en tillåtelse är för bred kan botar, komprometterade interna klienter eller externa angripare nå inloggningssidor, API och SSH direkt för att testa inloggningsuppgifter, kända sårbarheter eller felkonfigurationer. MFA och säkra lösenord är fortfarande viktiga, men de begränsar inte åtkomligheten: Device Access minskar attackytan före inloggningen och hör därför till de första härdningsåtgärderna.

Identitetskällan förblir separat. Om WebAdmin ska använda centrala TACACS+-inloggningsuppgifter beskriver TACACS+ för Sophos Firewall-administratörer serveranslutning, lokal profiltilldelning, pilotinloggning och reservväg; HTTPS-nåbarheten begränsas fortfarande här.

Anslutningens mål är avgörande:

• Zontabellen i Device Access: Tillåter i grunden en lokal brandväggstjänst från en zon.
• Local service ACL exception rule: Tillåter eller blockerar en lokal tjänst för specifika källor, mål och tjänster.
• Brandväggsregel: Styr trafik genom brandväggen, exempelvis från LAN till en server i DMZ.

Om exempelvis https://172.16.16.16:4444 öppnas avslutas anslutningen på brandväggen. En vanlig brandväggsregel ersätter därför inte ett tillstånd i Device Access.

⚠️ WebAdmin, SSH och portaler bör endast kunna nås från nätverk som faktiskt behöver dem. För extern administration är Admin-VPN, Sophos Central Firewall Management i Sophos Fusion (inloggning på fusion.sophos.com), ett hanteringsnät eller ett snävt ACL-undantag säkrare än bred WAN-åtkomst.

Två specialfall kan kringgå zontabellen för HTTP- och HTTPS-tjänster:

• Web Proxy: Förfrågningar via Web Proxy betraktas som interna och kan inte styras efter källzon med Device Access. Den som får använda proxyn kan därför nå WebAdmin, Captive Portal, VPN Portal och User Portal även om tjänsten är inaktiverad för den egna zonen.
• Port Sharing: Om VPN Portal och SSL VPN använder samma port och samma protokoll blir VPN Portal åtkomlig från alla SSL VPN-åtkomstzoner. Dessutom fungerar då inte inställningarna under Login security.

Dessa båda vägar måste testas separat vid verifieringen. Den överordnade artikeln Sophos Firewall Hardening sätter Device Access i sammanhanget för den övergripande systemhärdningen.

Planera zoner och lokala tjänster

Zontabellen passar för tydliga grundbehörigheter, exempelvis DNS från LAN, Ping från en övervakningszon eller HTTPS från ett hanteringsnät. Om bara en enskild IP-adress eller ett litet nät behöver åtkomst är en ACL Exception Rule mer exakt.

En zon grupperar gränssnitt. För en anpassad zon kan åtkomst till lokala tjänster också tillåtas eller blockeras under Network > Zones. Före en ändring måste därför det faktiska ingångsgränssnittet och dess zon fastställas. Förbered även det snäva källobjektet, nödvändig Interface Host som mål och porten som tjänsten faktiskt använder. Befintliga IP Hosts finns under Hosts and services > IP host; Interface Hosts hanteras via Network > Interfaces.

Läs standardmatrisen som utgångspunkt

En ny SFOS 22-konfiguration tillåter som standard lokala tjänster från följande zoner. Matrisen är inte ett härdningsmål: restore, migrering, guiden och senare ändringar kan ge ett annat tillstånd, och onödiga tjänster tas bort efter ett positivt och negativt test.

Typiska beslut är:

• HTTPS: WebAdmin och API endast från hanteringsnät eller snävt definierade administratörskällor.
• SSH: Endast för administration eller support och helst med autentisering med publik nyckel. För SSH över nätverket är den dokumenterade inloggningsvägen i SFOS 22/23 det inbyggda kontot admin; CLI-behörighet i en profil bekräftar inte någon SSH-inloggningsväg för ett namngivet administratörskonto. Endast standardadministratören hanterar inställningarna för publika nycklar och själva nycklarna.
• DNS: Endast för interna klientzoner som använder brandväggen som DNS Resolver. DNS från WAN är inget normalt klientfall.
• Ping/Ping6: För nödvändig övervakning, inte generellt från osäkra zoner.
• SNMP: Endast från övervakningssystemet eller övervakningsnätet; konfigurationen beskrivs i SNMP Hardware Monitoring.
• RADIUS SSO: Endast från den fasta accountingavsändaren. RADIUS SSO med accounting förklarar kopplingen mellan klient-IP och användare.
• SSL VPN: Externt så öppet som nödvändigt och med MFA, Logging samt medvetet valda portar och protokoll.
• VPN Portal: Tillhandahåller sedan SFOS 20 Sophos Connect samt IPsec- och SSL VPN-konfigurationer.
• User Portal: Används bland annat för personuppgifter, OTP-token, karantän, undantag och Policy Overrides, inte för nedladdning av VPN-konfigurationen.
• RED, SMTP Relay och Dynamic Routing: Endast i avsedda nätverk eller för definierade motparter. Hur denna gräns kontrolleras för Multicast-Neighbors förklaras i Konfigurera PIM-SM i Sophos Firewall; för små IPv4-routingdomäner förklarar Konfigurera RIPv2 på Sophos Firewall den separata behörigheten för peerzon och datatrafik.

Tjänstedialogen erbjuder dessutom AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy och Wireless Protection. Att en tjänst går att välja är inte en rekommendation om bred zonåtkomst; varje val kräver en konkret klient-, peer- eller administrationsväg. Sökfälten Source Network / Host, Destination host och Services söker även i attribut. Genom att ange 53 går det exempelvis att hitta DNS-tjänsten.

WebAdmin, VPN Portal och User Portal stöder TLS 1.3 sedan SFOS 22. Bra kryptering minskar dock inte attackytan för en tjänst som är åtkomlig i onödan.

Device Access avgör endast från vilket nät WebAdmin Console kan nås. Om inloggningen ska ske via Microsoft Entra ID förklarar Entra ID SSO för Sophos Firewall WebAdmin den separata mappningen av Entra-roller och -grupper till lokala administratörsprofiler.

Dessutom kan restrict-admin-console-wan-access blockera WebAdmin-åtkomst globalt från alla WAN-källor. Kontrollera Advanced Firewall Settings säkert förklarar den avsiktligt omvända enable/disable-logiken och skillnaden mot Local Service ACL.

Begränsa källor snävt

En ACL Exception Rule stöder Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list och Network som källor. Wildcard-FQDN stöds inte.

För WebAdmin från WAN får ingen behörighet för alla källor användas. SFOS tillåter inte att ACL-undantaget skapas när Source Network / Host är inställt på Any eller käll-IP-adressen är 0.0.0.0. Denna produktbegränsning gör inte automatiskt andra stora nätverk säkra. En fast administratörs-IP, ett litet hanteringsnät eller ett underhållet FQDN-objekt är betydligt säkrare. För mobila användare vars källadresser ändras bör administrativ åtkomst ske via VPN eller Sophos Fusion.

Breda WAN-behörigheter för WebAdmin och User Portal inaktiveras sedan SFOS 19.5 MR2 automatiskt efter 90 dagar i följd utan lyckad inloggning. Specifika WAN-källor i ACL Exception Rules påverkas inte och måste fortfarande granskas regelbundet. Sophos Firewall Health Check hjälper till vid återkommande granskning av hanteringsåtkomst, MFA och konfiguration.

Kontrollera Web Proxy och Port Sharing i förväg

Före härdningen bör använda portar och protokoll noteras under Administration > Admin and user settings samt i SSL VPN global settings.

• WebAdmin använder som standard TCP 4444, User Portal TCP 4443 och VPN Portal TCP 443.
• I SFOS 22/23 är TCP 443 det dokumenterade standardvärdet för WAF; notera de faktiskt konfigurerade WAF-lyssnarna innan eventuella konflikter kontrolleras.
• SSL VPN använder TCP 8443 som standard; UDP kan också väljas som protokoll.
• WebAdmin och User Portal får inte dela sina portar med andra tjänster.
• VPN Portal och SSL VPN bör inte använda samma port och protokoll, eftersom zonblockeringar och Login Security då inte fungerar som förväntat.

Om Web Proxy är aktiv räcker inte ett test utan proxy. Samma portal- eller WebAdmin-anrop måste dessutom testas via den explicita proxyn från en zon som egentligen är blockerad.

Konfigurera Direct Web Proxy med en PAC-fil förklarar hur proxylistenern begränsas till en pilotklient och hur exponeringen valideras under kontrollerade former.

Skapa en snäv Local Service ACL Exception Rule

Före direkt WAN-åtkomst till WebAdmin: Använd först det skrivskyddade kommandot show advanced-firewall i Device Console för att dokumentera det faktiska värdet för restrict-admin-console-wan-access och den installerade builden. För SFOS 22/23 beskriver Sophos enable som en blockering av WebAdmin från alla WAN-källor och som standardvärdet; detta standardvärde ersätter inte det dokumenterade tidigare värdet. ACL-anvisningen beskriver snäva WAN-undantag men klargör inte deras företräde framför denna globala begränsning. Anta därför inte att följande ACL-undantag ensamt gör WebAdmin nåbart från WAN. Behåll begränsningen vid enable och använd den redan testade, godkända åtkomstvägen via Admin-VPN, hanteringsnät eller Fusion. Om direkt WAN-åtkomst är nödvändig och samspelet för den installerade builden inte är tydligt klarlagt ska ändringen för direkt WAN-åtkomst stoppas och frågan klargöras med Sophos Support. Kontrollera även vid ett misslyckat positivt test först denna förutsättning i stället för att utöka ACL:en.

Detta ACL-exempel är ingen instruktion att sätta den globala inställningen till disable. En ändring av den globala begränsningen kräver en separat godkänd ändring med en fungerande oberoende administratörsväg, det dokumenterade faktiska tidigare värdet, egna tester från tillåtna och blockerade WAN-källor samt exakt återställning av detta tidigare värde vid avbrott och när tillfällig åtkomst upphör. Gör ingen ändring om startvärdet eller återställningsvägen inte kan fastställas tillförlitligt. Genomför följande snäva WAN-exempel först när dessa förutsättningar har klarlagts.

Ett typiskt undantag tillåter endast WebAdmin från WAN för en fast support-IP. Menysökvägen är Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Rule position: Välj Top för ett specifikt WAN-undantag och kontrollera övriga regler för överlappningar.
3. Description: Dokumentera syfte, ärende och planerat slutdatum.
4. IP version: Välj efter källan, oftast IPv4.
5. Source zone: WAN
6. Source Network / Host: Välj en specifik administratörs-IP eller ett snävt, underhållet objekt.
7. Destination host: Begränsa till den brandväggsadress eller det gränssnitt som behövs. Any utökar de åtkomliga måladresserna eller gränssnitten, inte tjänsterna som valts under Services.
8. Services: Välj endast HTTPS, inte dessutom SSH av bekvämlighetsskäl.
9. Action: Accept

Kopiera inte exempelvärdena utan att anpassa dem. För ett internt hanteringsnät kan samma mönster använda Source zone: LAN eller en anpassad hanteringszon, Source Network / Host: mgmt-net, hanterings-IP-adressens Interface Host som Destination host, HTTPS och Accept. För att utesluta en känd källa i en zon som i övrigt behöver åtkomst används en separat, korrekt placerad regel med det snäva källobjektet, endast de berörda tjänsterna och Drop. En landsgrupp är på sin höjd en grov nätverksgräns, inte en ersättning för en fast administratörskälla eller VPN.

Därefter sparas regeln och testas från en tillåten och en otillåten källa. Regelns placering är viktig: regler högre upp kan påverka resultatet. Vid överlappande regler bör den faktiska effekten därför kontrolleras på brandväggen och inte enbart härledas från listan.

API-åtkomst

Tre villkor måste stämma överens för API:t:

1. API:t är aktiverat under Administration > API access.
2. Källadressen finns i Allowed IP hosts.
3. Device Access tillåter HTTPS från den aktuella zonen eller via ett passande ACL-undantag.

Sedan SFOS 22 finns API-konfigurationen under Administration och stöder IP Host-objekt för adresser, intervall och nätverk. Upp till 64 objekt är möjliga. Någon bred HTTPS-behörighet behövs inte. Den fullständiga konfigurationen finns i Begränsa åtkomsten till Sophos Firewall API på ett säkert sätt.

XML-automatisering: zoninställning, inte ACL-undantag

XML-zondokumentationen för SFOS 22/23 placerar HTTPS och SSH under Zone/ApplianceAccess/AdminServices/HTTPS respektive Zone/ApplianceAccess/AdminServices/SSH. Detta är åtkomst till lokala tjänster på zonnivå: varken en brandväggsregel för transittrafik eller en källspecifik Local service ACL exception rule. En ändring i denna gren påverkar hanteringens nåbarhet från zonen; den begränsar inte åtkomsten till en enda administratörs-IP. För en snäv källbehörighet är ACL-undantaget som beskrivs ovan fortfarande rätt avgränsning.

Dokumentationen motsäger sig själv om värdena: XML-exemplet visar Enable/Disable, medan den gemensamma parametertabellen upprepar Enable och även listar 12 och 40. Detta ger ingen tillförlitlig boolesk eller numerisk kodning. Klargör syntaxen för den installerade firmwareversionen före varje automatiserad skrivning; denna hierarkiförklaring är inte en körbar mall för att ge åtkomst.

Inte heller Zone/MemberPorts är en skrivinstruktion: kommentaren i XML-exemplet anger uttryckligen att zonens medlemsportar är skrivskyddade. Den valfria CSV-raden i tabellen beskriver hur de visas, inte en verifierad metod för att ändra dem. Testa före varje automatiserad zonändring en oberoende återställningsväg med en inloggad session och kontrollera sedan tillåtna och blockerade källor enligt utrullningen nedan.

Ta bort en anpassad zon säkert

Att radera en Local service ACL exception rule tar endast bort det undantaget, inte zonen med det angivna namnet. Att inaktivera en lokal tjänst är inte heller att radera en zon. Zoner och gränssnitt förklarar kopplingarna.

1. Identifiera under Network > Zones det exakta namnet på den anpassade zon som inte längre behövs i produktion och dokumentera dess tidigare tillstånd. Retired_Test är endast ett exempel, inte ett raderingsmål att kopiera. Logga först in via och testa den oberoende administratörsvägen i utrullningen nedan; den får inte bero på denna zon eller på gränssnitt eller regler som ska ändras.
2. Granska under Network > Interfaces alla tilldelningar till denna zon och under Rules and policies > Firewall rules alla hänvisningar som Source zone eller Destination zone. Radera inte gränssnitt eller regler som behövs: tilldela dem den avsedda kvarvarande zonen endast inom en godkänd ändring och kontrollera effekten. Om hänvisningar måste finnas kvar eller deras användning är oklar, behåll zonen och dess beroenden och stoppa raderingen. Kaskadradera inte produktionsberoenden för att tvinga fram borttagningen.
3. Ta bort endast denna namngivna zon först efter att beroendena har klarlagts. XML-dokumentationen för SFOS 22/23 kräver Name med högst 60 tecken: först A-Za-z1-9 (inte 0), därefter A-Za-z0-9_. Detta bekräftar varken stöd för jokertecken eller automatisk kaskadradering; här anges ingen XML-begäran eller obelagd raderingsdialog.
4. Kontrollera sedan att endast den avsedda zonen saknas, att kvarvarande gränssnittstilldelningar och brandväggsregler stämmer och att nödvändig transittrafik fortfarande fungerar. Testa lokala tjänster på nytt från tillåtna och blockerade källor samt den oberoende administratörsvägen. Stoppa vid avvikelser och använd den vägen för att återställa de dokumenterade ändringarna selektivt, inte utöka behörigheter.

De dokumenterade XML-statusvärdena är 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) och 504 (ZoneFirewallRuleExists). Vid 503 eller 504, granska de berörda gränssnitts- eller regelhänvisningarna igen i stället för att radera beroende objekt utan åtskillnad. 500 betyder inte att åtgärden lyckades; inte heller 200 ersätter efterkontrollen.

DNS från WAN

Enbart ett DNS ACL-undantag från WAN gör inte att brandväggen svarar på DNS-förfrågningar där. För detta måste dessutom en statisk DNS Host med Publish on WAN skapas under Network > DNS. Det bör endast göras för ett specifikt auktoritativt användningsfall; brandväggen får inte därigenom bli en publikt åtkomlig rekursiv resolver. Konfigurera och testa DNS Host Entries på Sophos Firewall beskriver delegering, DNS Host Entry samt positiva och negativa tester.

Driftdetaljer före ändringen

Efter en uppgradering eller återställning från en version före SFOS 20 övertar VPN Portal den tidigare User Portal-porten, även en anpassad port. User Portal flyttas till 4443, eller till 65040 om den porten är upptagen. Kontrollera den konfigurerade porten, inte bara standardvärdet, innan en till synes saknad ACL-behörighet undersöks. VPN Portal-användare eller -grupper måste också ingå i en lämplig Remote Access-policy; enbart nåbarhet ger ingen användarbehörighet.

WAF-lyssnaren måste skilja sig från VPN Portal i WAN-IP-adress eller port. Gentemot SSL VPN räcker även ett annat protokoll: WAF och VPN Portal använder TCP, medan SSL VPN kan använda TCP eller UDP. Att skilja lyssnarna åt är inte samma sak som ACL-behörighet; testa berörda tjänster på nytt efter varje portändring.

Dynamic Routing tillåter routinguppdateringar till brandväggen, inte datatrafik genom den. Aktivera det för den faktiska peerzonen, inte automatiskt för WAN. I WAN-exemplet med två RIP-brandväggar tar bara sidan med aktiverad åtkomst emot uppdateringar; den andra avvisar uppdateringarna och lär sig inte de annonserade näten. Om rutter saknas på ena sidan kontrolleras peerzonen på båda sidor och därefter protokollkonfigurationen i den länkade routingartikeln.

Widgeten Messages i Control center kan varna för WAN-åtkomst till HTTPS och SSH. Kontrollera zonbehörigheter och ACL-undantag och begränsa åtkomsten till VPN eller specifika värdar och nät. Meddelanden kan inte raderas manuellt; vissa försvinner när kravet är uppfyllt. Ett försvunnet meddelande ersätter inte positiva och negativa tester. Meddelanden om huvudnyckel, registrering, licenser, rapporter och firmware hör till respektive driftrutin, inte till en extra ACL-regel.

Rulla ut ändringar utan lockout

Ändringar i Device Access får omedelbar effekt.

Återställningsvägen måste fungera även efter den planerade zon- eller portändringen. En andra webbläsarflik som använder samma blockerade åtkomstväg är inte oberoende. Dokumentera först de exakta tidigare inställningarna och vem som har konsolåtkomst; gör ingen fjärrändring utan en fungerande återställningsväg. Vid fjärrarbete måste man före ändringen redan vara inloggad via den andra administratörsvägen och ha testat att den fungerar.

1. Dokumentera aktuella zonbehörigheter, ACL-undantag, portar och nödvändiga tjänster.
2. Öppna en oberoende åtkomstväg, exempelvis lokal konsol, Management-LAN, Admin-VPN eller Sophos Fusion.
3. Se vid större ändringar till att en aktuell Backup och Secure Storage Master Key finns tillgängliga.
4. Skapa det nya, snäva Accept-undantaget utan att ännu ta bort den befintliga breda behörigheten.
5. Kontrollera den tillåtna åtkomsten som utgångsvärde. Så länge den breda zonbehörigheten är aktiv bevisar testet ännu inte att det nya undantaget används.
6. Ange ett snävt filter för källa, mål och port under Diagnostics > Packet capture och aktivera Trace On.
7. Ta bort den gamla breda zonbehörigheten via den oberoende administratörsvägen.
8. Funktionstesta omedelbart därefter tjänsten från den tillåtna källan. En lyckad TCP-/TLS-anslutning eller tjänsteåtkomst och vanligtvis Status: Consumed bekräftar positivfallet; Reason: LOCAL_ACL behöver inte visas.
9. Testa samma tjänst från en otillåten källa. För det blockerade försöket förväntas vanligtvis Status: Violation och Reason: LOCAL_ACL.
10. Kontrollera för HTTP/HTTPS dessutom Web Proxy-vägen och för portaler SSL VPN-åtkomstzonerna.
11. Stoppa Packet Capture och kontrollera kompletterande tjänste- eller inloggningshändelser i Log viewer. Det Rule-ID som visas i Packet Capture är brandväggsregelns ID, inte ID:t för ACL Exception Rule, och kan vara 0 för lokal trafik.
12. Dokumentera regel, syfte, ansvarig, ärende, källa, tjänst samt gransknings- eller slutdatum.

Avbrott och återställning: Om den tillåtna åtkomsten slutar fungera återställs den senast ändrade inställningen till sitt dokumenterade tidigare värde via den oberoende vägen, och åtkomsten testas igen. Om en blockerad källa fortfarande når tjänsten ska behörigheten inte utökas: undersök proxyn, Port Sharing och överlappande ACL-regler och begränsa den oönskade vägen utan att förlora återställningsåtkomsten. Upprepa båda testerna först efter korrigering.

Korta dokumentationsexempel underlättar senare granskning:

• HTTPS: Regel admin-https-from-mgmt, källa mgmt-net, syfte WebAdmin, granskas kvartalsvis.
• SSH: Källa support-ip-temporary, syfte supportärende, tas bort när ärendet avslutas.
• SNMP: Källa monitoring-server, syfte övervakning av maskinvara och gränssnitt, granskas halvårsvis.
• SSL VPN: Källa WAN, syfte Remote Access, loggar granskas varje månad.

Vid flera brandväggar eller ett HA-kluster bör ett system med god återställningsmöjlighet ändras först. Rollbyten och underhållsåtkomst beskrivs i guiden Konfigurera High Availability i Sophos Firewall.

Specialfall och ytterligare skydd

User Portal, VPN Portal och SSL VPN

Först måste det klargöras vilken portal som faktiskt behövs. VPN-klienter och konfigurationer hör hemma i VPN Portal; User Portal fyller andra användarfunktioner. En översikt finns i Jämförelse av portaler i Sophos Firewall.

Om en Remote Access-tjänst måste vara tillgänglig över hela världen är MFA, restriktiva användargrupper och Logging viktigare än en olämplig landsbegränsning. Konfigurationen visas i Aktivera MFA för WebAdmin, VPN Portal och Remote Access i Sophos Firewall. Port Sharing bör ändå undvikas: autentisering ersätter inte korrekt styrning av åtkomligheten.

Publikt åtkomliga inloggningar till WebAdmin, User Portal, VPN Portal och SSL VPN hittas snabbt av skannrar och botar. Även med MFA orsakar detta Brute Force-trafik, loggbrus och extra belastning.

Om många misslyckade VPN Portal-inloggningar eller kontolåsningar redan förekommer samlar Skydda Sophos Firewall VPN Portal mot brute force-attacker loggkontroll, identitetskontroll, begränsning via ACL och efterkontroll i ett incidentflöde.

Om en portal måste vara åtkomlig över hela världen kan Threat Feeds i Sophos Firewall med åtgärden Block dessutom blockera kända skadliga IPv4-källor från Third-Party Feeds som Cybora, även för trafik till själva brandväggen. Domän- eller URL-IoC:er skyddar inte en inloggning mot en skadlig käll-IP, och IPv6-källor stöds inte för närvarande. Threat Feeds är därför ett tilläggsskydd och inte en ersättning för snäva ACL:er. Den länkade artikeln förklarar konfiguration, tester och Allowlisting.

SSH och tillfälliga supportregler

SSH bör endast vara åtkomligt vid behov, från ett hanteringsnät, via VPN eller för en fast support-IP. Public-Key-autentisering är att föredra. Efter ett supportärende raderas det tillfälliga ACL-undantaget; en inaktiveringsstatus som inte har bekräftats i det aktuella gränssnittet bör inte förutsättas. Ytterligare steg finns i Anslut till Sophos Firewall via SSH.

CLI-behörighet är inte detsamma som SSH-inloggning: Enligt profilbeskrivningen för SFOS 22/23 ger profilen Administrator full CLI-åtkomst utan att ange transportmetod. PuTTY-anvisningen för samma versioner kräver däremot användarnamnet admin för SSH över nätverket och utesluter andra användarnamn; detta gäller även inloggning med lösenord. Här dras därför varken slutsatsen att namngivna administratörskonton kan använda SSH eller någon generell slutsats om alla former av CLI-åtkomst. WebAdmin-funktionen Console öppnar en konsol i webbläsaren via WebAdmin-åtkomsten och är inget bevis på inloggning via SSH över nätverket. Om ett visst namngivet konto kan använda denna webbläsaråtkomst måste kontrolleras separat utifrån kontots behörigheter och den installerade firmwareversionen. Nyckelhanteringen, som endast standardadministratören har rätt till, är också en separat behörighet och avgör inte vilka konton som kan logga in via SSH med lösenord.

Kontrollera den faktiska reservvägen före en ACL-ändring: Använd det inbyggda kontot admin med dess aktuella inloggningsuppgifter eller en nyckel som konfigurerats för kontot för den dokumenterade åtkomstvägen via SSH över nätverket. Logga in via den valda åtkomstvägen i en ny session, öppna den konsol som behövs och dokumentera konto, transportmetod och firmwareversion i ändringsärendet; enbart en åtkomlig TCP-port räcker inte. Fungerande åtkomst till Console i webbläsaren är fortfarande beroende av WebAdmin-vägen och är ingen oberoende reservväg om denna blockeras. Om ett namngivet konto behövs som reservväg via SSH eller om det observerade beteendet strider mot anvisningen ska ändringen stoppas, en redan testad och behörig åtkomstväg behållas och den exakta omfattningen av konto- och transportstödet klargöras med Sophos Support. Varken utöka ACL:en eller använd upprepade inloggningsförsök som ersättning för detta klargörande.

Ta bort ett utgånget undantag under Administration > Device access > Local service ACL exception rule med Delete vid regeln och bekräfta med OK. Testa först administratörsvägen som ska finnas kvar; kontrollera sedan att den tidigare supportkällan inte längre kan ansluta. Ett dokumenterat slutdatum är här ett granskningskrav, inte bevis för automatisk radering.

Felsökning

Om en inloggning plötsligt inte kan nås kontrolleras även Administration > Admin and user settings > Login security > Block login. Denna blockering per käll-IP beror på misslyckade inloggningar och kan påverka WebAdmin, CLI, VPN Portal och User Portal. Den är ingen ACL-regel. Misslyckade CAPTCHA-försök räknas inte som dessa inloggningsförsök. Kontrollera den inställda blockeringstiden och händelserna i stället för att tillåta HTTPS för en hel zon eller stänga av skyddet generellt.

Om en lokal tjänst inte är åtkomlig eller blockerad som förväntat kontrolleras följande i denna ordning:

1. Mål och port: Stämmer brandväggens IP-adress och använder tjänsten den förväntade porten?
2. Källzon: Kommer klienten direkt från den förväntade zonen, via VPN eller via Web Proxy?
3. Zontabell: Är tjänsten tillåten för denna zon under Administration > Device access?
4. ACL-undantag: Stämmer IP version, Source zone, källobjekt, Destination host, Service, Action och Position?
5. Port Sharing: Delar VPN Portal och SSL VPN port och protokoll?
6. API: Stämmer API-aktivering, Allowed IP hosts och HTTPS Device Access överens?
7. DNS: Är DNS tillåtet för interna klienter? Vid WAN-publicering krävs dessutom Publish on WAN.
8. Loggar: Visar Log Viewer kompletterande tjänste- eller inloggningshändelser?
9. Packet Capture: Starta Trace före det nya testet. Den tillåtna åtkomsten måste fungera och visar vanligtvis Status: Consumed; det blockerade försöket visar vanligtvis Status: Violation och Reason: LOCAL_ACL. Rule-ID är inte ID:t för ACL-undantaget. Användningen beskrivs i Packet Capture i Sophos Firewall.

Om WebAdmin eller en portal förblir åtkomlig trots att källzonen har inaktiverats testas först Web Proxy och Port Sharing. En extra brandväggsregel löser inte detta problem.

För långsiktig spårbarhet lämpar sig Central Firewall Reporting eller Skicka Syslog från Sophos Firewall till SIEM.

Checklista för drift

• WebAdmin är inte brett åtkomligt från WAN, gäst-, IoT- eller VoIP-zoner.
• HTTPS, SSH och SNMP är begränsade till specifika hanterings- eller övervakningskällor.
• User Portal, VPN Portal och SSL VPN är endast aktiva om driftkonceptet kräver dem.
• VPN Portal och SSL VPN delar inte samma port och protokoll.
• Web Proxy-åtkomst till lokala HTTP/HTTPS-tjänster har testats separat.
• API access, Allowed IP hosts och HTTPS Device Access är samordnade.
• Tillfälliga ACL-undantag innehåller syfte och slutdatum och raderas efter avslutat arbete.
• Tillåtna och blockerade källor har testats; loggarna bekräftar resultatet.
• Reglerna granskas regelbundet avseende inaktuella källor, onödiga tjänster och breda Accept-undantag.

Förbehåll om källorna

STAS tillhandahåller användarautentisering; det är varken ett VPN eller en krypterad administrationskanal. Tillåtelse för autentiseringstjänsten ersätter inte en skyddad hanteringsväg.

De bevarade SSH-nyckelinstruktionerna för SFOS 22/23 är tvetydiga: de anger RSA/DSA med minst 2048 bitar och anger ECDSA med undantag för ED25519. Dra inte slutsatsen att ED25519 stöds och betrakta inte DSA som en rekommendation. Bekräfta vilken algoritm den faktiska firmwareversionen stöder före registreringen; ladda endast upp den offentliga nyckeln och behåll en separat återställningsväg. En Device Access-tillåtelse bekräftar inte stöd för en nyckelalgoritm.

Adaptive Learning omfattar även URL:er för upptäckta virus, hotnamn/URL:er/IP-adresser, käll-IP-adresser och använda program. Den förvalda HTTPS-rapporteringen omfattar enhets-, firmware- och licensdata (utan ägarinformation), status för funktioner/HA/molnhantering, antal objekt, fel samt CPU-/minnes-/diskanvändning i procent. Detta är ett beslut om datautlämnande, inte en ACL-kontroll. Sophos Assistant är aktiverat som standard; stäng av det genom att avmarkera Turn on Sophos Assistant under Administration > Admin and user settings, klicka på Apply och sedan logga ut och in igen. Detta stänger inte av telemetrin.

FAQ