Sophos Firewall Säker åtkomst: konfigurera Device Access korrekt

Administration > Device access bestämmer från vilka zoner lokala tjänster för Sophos Firewall kan nås. Dessa inkluderar till exempel HTTPS för konsolen WebAdmin, SSH för CLI, Ping, DNS, User Portal, VPN Portal och andra tjänster.

För det bredare hardening-sammanhanget passar hubben Sophos Firewall Hardening: best practices för säker konfiguration.

Detta område är säkerhetskritiskt. Normala brandväggsregler styr trafiken genom brandväggen. Enhetsåtkomst styr trafik till själva brandväggen. Om WebAdmin eller SSH kan nås från en osäker zon skapas direkt hanteringsåtkomst till säkerhetsenheten.

API är också viktigt: Device Access-behörigheten för HTTPS/WebAdmin påverkar även API-åtkomst. Sedan SFOS 22 hanteras API-åtkomstkällor dessutom under Administration > API access, men en tillåten API-värd hjälper inte om Device Access blockerar lokal HTTPS-åtkomst från denna zon.

⚠️ WebAdmin, SSH och portaler bör endast vara tillgängliga från pålitliga nätverk. För produktiva miljöer är det bättre att begränsa åtkomsten till ett hanteringsnätverk, en fast admin-IP, VPN eller Sophos Central brandväggshantering.

Denna separation hjälper i praktiken:

• Device Access Zontabell: Tillåt eller blockera i allmänhet service per zon, till exempel DNS för LAN, ping för en övervakningszon eller SSL VPN för en nödvändig fjärråtkomstzon.
• Lokal tjänst ACL Exception Rule: Kontrollera åtkomsten närmare efter källa, destination och tjänst, till exempel WebAdmin endast från hanteringsnätverket, SSH endast från en support-IP eller SNMP endast från övervakningssystemet.
• Normal brandväggsregel: Tillåt eller blockera trafik genom brandväggen, till exempel när en klient från LAN ansluter till en server i DMZ eller en internettjänst.

Detta gör det tydligt: En brandväggsregel ersätter inte förstärkning av enhetens åtkomst. Om HTTPS eller SSH är för allmänt tillgänglig via Device Access, kommer en klient att nå brandväggens lokala tjänst innan en klassisk pass-through-regel ens skulle vara rätt kontrollpunkt.

Varför Device Access inte fungerar som en brandväggsregel

En typisk brandväggsregel tillåter eller blockerar anslutningar mellan zoner, till exempel LAN till WAN eller VPN till Server. Device Access är annorlunda: Det här handlar om tjänster som körs direkt på Sophos Firewall.

Exempel:

• En administratör öppnar https://172.16.16.16:4444.
• En klient använder brandväggen som en DNS-server.
• Ett övervakningssystem pingar brandväggen.
• En användare öppnar portalen User Portal eller VPN.
• En administratör ansluter till brandväggen via SSH.

Sådan trafik har inte en server bakom brandväggen som destination, utan snarare själva brandväggen. Det är därför det styrs via den lokala tjänsten ACL.

Detta är också anledningen till att Device Access är en del av den grundläggande härdningen av varje Sophos Firewall. En ren LAN-till-WAN-regeluppsättning skyddar inte automatiskt hanteringen och portaltjänsterna för själva brandväggen. Dessa tjänster måste granskas separat och medvetet begränsas.

Förstå zonavstånd

Överst i Administration > Device access kan du se en tabell med zoner och tjänster. Om en tjänst är aktiverad för en zon, är åtkomst till denna lokala tjänst i allmänhet tillåten från denna zon.

Zonbordet är praktiskt men grovt och passar tydliga inre zoner, till exempel LAN, Management eller VPN. Om en tjänst endast ska vara tillgänglig för individuella administratörs-IP-adresser, platser, länder eller supportmål är Local service ACL-undantagsregler det bättre valet.

För anpassade zoner bör du också kontrollera zoninställningarna. Där kan även närservicen påverkas. Ändå är Administration > Device access den centrala platsen där du medvetet kan aktivera eller begränsa lokala brandväggstjänster.

Typiska exempel:

• HTTPS: WebAdmin åtkomst från hanteringsnätverket. Tillåt inte bred från WAN.
• SSH: CLI åtkomst för administratörer eller support. Tillåt endast specifikt, helst med en publik nyckel.
• Ping/Ping6: Övervakning och enkla tillgänglighetstester. Aktivera inte i onödan från osäkra zoner.
• DNS: Klienter använder brandväggen som en DNS resolver. Aktivera endast för interna klientzoner.
• SSL VPN: SSL VPN användare upprättar en anslutning till brandväggen. Externt endast vara så öppen som nödvändigt och säkrad med MFA; Kontrollera porten separat i fjärråtkomstområdet.
• User Portal: Användare laddar VPN-konfigurationer eller tokens. Externt, om möjligt via VPN/ZTNA eller snävt begränsat.
• VPN Portal: Fjärråtkomst VPN användare. Endast om det verkligen behövs och säkert med MFA.
• RED: RED apparater ansluter till brandväggen. Tillåt endast verkliga RED-platser eller definierade källor.
• SMTP Relay: Interna system använder brandväggen som ett SMTP relä. Släpp inte som ett öppet relä från osäkra zoner.
• SNMP: Övervakning hämtar värden från brandväggen. Tillåt endast från övervakningssystemet; detaljer finns i SNMP Hardware Monitoring.
• Dynamic Routing: Routningsprotokoll mellan routrar och brandvägg. Aktivera endast på angivna nätverkssegment.

I SFOS 22 stöder WebAdmin, VPN Portal och User Portal TLS 1.3. Detta är bra för kryptering, men det ändrar inte grundprincipen: en tjänst som kan nås från för många källor förblir en onödig attackyta. Transportkryptering ersätter inte en ren ACL.

Vilka tjänster kan begränsas med hjälp av ACL-regler?

Lokala brandväggstjänster kan styras mycket exakt via Local Service ACL och ACL Exception Rules. Dessa tjänster är särskilt relevanta:

• DNS: Brandväggen svarar på DNS förfrågningar från nätverk som den inte är tänkt att betjäna.
• Dynamic Routing: Routningsprotokoll kan nås från fel segment.
• HTTPS: WebAdmin-konsolen är tillgänglig för för många källor.
• Ping/Ping6: Brandväggen är onödigt lätt att se och skanna.
• RED: RED tjänster är tillgängliga från källor som är för breda.
• SMTP Relay: Felkonfigurationer kan främja relämissbruk.
• SNMP: Övervakningsdata kan efterfrågas från felaktiga nätverk.
• SSH: Direkt CLI åtkomst till brandväggen är för öppen.
• SSL VPN: VPN registreringspunkter är tillgängliga och skannade över hela världen.
• User Portal: Portalinloggning och VPN nedladdningar exponeras i onödan.
• VPN Portal: Fjärråtkomstportalen är inriktad på bots och brute force-försök.

Ju fler av dessa tjänster som är tillgängliga från WAN, gästnätverk, IoT-nätverk eller vagt definierade zoner, desto större blir attackytan. Målet är inte att avaktivera allt, utan att göra varje tjänst endast tillgänglig där den verkligen behövs.

Definiera åtkomstkällor så snävt som möjligt

En ACL-regel behöver inte bara tillåta Any. Du kan arbeta mycket fint som källa, till exempel med:

• individuella admin IP-adresser
• Ledningsnätverk
• IP-intervall
• IP-listor
• FQDN värdar
• FQDN värdgrupper
• DNS värdar eller DNS grupper
• Landobjekt eller landsgrupper
• dedikerade VPN eller supportnätverk

Detta gör det mycket lättare att begränsa åtkomsten. Till exempel: Om en extern supporttjänst endast kommer från ett fast FQDN eller ett definierat IP-intervall, ska hela WAN-zonen inte ha tillgång till HTTPS eller SSH. Om ett övervakningssystem kräver SNMP, bör ett helt servernätverk inte tillåtas att fråga efter SNMP på brandväggen.

I globala scenarier för fjärråtkomst är gränsdragningen svårare. Vissa företag kan inte bara släppa portalen SSL VPN eller VPN för Schweiz, Tyskland eller ett enda land eftersom anställda reser över hela världen. I sådana fall bör du också arbeta med MFA, loggning, restriktiva portalinställningar och Threat Feeds.

Beslutsmodell för lokala tjänster

För varje lokal tjänst bör du medvetet bestämma vilken åtkomstnivå som är lämplig. Det är sällan meningsfullt att behandla WebAdmin, SSH, User Portal, VPN Portal, DNS och SNMP lika.

• Inaktiverad: Lämplig när tjänsten inte behövs i miljön. Exempel: SSH permanent avstängd om ingen CLI-åtkomst tillhandahålls.
• Endast intern zon: Lämplig om tjänsten behövs av många interna kunder. Exempel: DNS från LAN när klienter använder brandväggen som en DNS resolver.
• Management Network: Lämplig för administrativa eller övervakningsrelaterade tjänster. Exempel: HTTPS, SSH och SNMP endast från Management.
• Admin-VPN: Lämplig om administratörer ska arbeta externt, men inte direkt från Internet. Exempel: WebAdmin kan endast nås via VPN.
• ACL Exception Rule: Lämplig om åtkomst ska komma från en mycket specifik källa. Exempel: En support-IP tillåts tillfälligt åtkomst till HTTPS eller SSH.
• WAN allmänt tillgänglig: Endast för riktiga fjärråtkomsttjänster och med extra skydd. Exempel: SSL VPN för mobilanvändare med MFA, loggning och Threat Feeds.

Detta beslut bör dokumenteras. Speciellt vid undantag från WAN måste man senare kunna förstå varför tjänsten är tillgänglig, vem som behöver den och när undantaget kommer att kontrolleras igen.

WAN åtkomst är ett undantag

WAN är inte bara en annan zon. Allt som kan nås från WAN kommer att hittas av skannrar, bots och brute force-verktyg. Det är därför WebAdmin från WAN inte bör planeras som en normal driftvariant.

Om extern hanteringsåtkomst behövs är dessa varianter vanligtvis säkrare:

• Sophos Central Brandväggshantering för administrativa uppgifter.
• Admin-VPN med MFA och rensa användargrupp.
• En tillfällig ACL Exception Rule för en fast käll-IP.
• Ett dedikerat hanteringsnätverk via plats-till-plats VPN.

För den allmänna härdningsbilden passar Sophos Firewall Använd hälsokontroll korrekt också eftersom hanteringsåtkomst, MFA, säkerhetskopior och regelbunden hygien utvärderas tillsammans där.

Sophos skyddar dessutom WebAdmin från att delas med alla WAN-källor. Om WAN-åtkomst verkligen är nödvändig måste den begränsas via specifika källor som individuella IP-adresser, nätverk eller FQDN-objekt. Befintliga äldre utgåvor från äldre konfigurationer bör kontrolleras regelbundet: Sophos kan automatiskt inaktivera vissa breda WAN-utgåvor för WebAdmin eller User Portal efter en lång period av inaktivitet, medan riktade ACL-undantag för specifika WAN-källor fortfarande kan gälla.

Lokal service ACL Exception Rule

Om en tjänst inte ska släppas för en hel zon, använd en Local service ACL-undantagsregel. Detta gör att du kan definiera mycket exakt vem som får tillgång till vilken lokal tjänst.

Sökväg:

1. Öppna Administration.
2. Välj Device access.
3. Bläddra till Local service ACL exception rule.
4. Klicka på Add.

Typiskt flöde för ett smalt adminundantag från WAN:

1. Ange Regelnamn, till exempel admin-https-from-support-ip.
2. Ställ in Regelposition till Top om en befintlig släpp- eller tillåtregel annars skulle kunna träda i kraft i förväg.
3. Välj IP-version för att matcha källan, vanligtvis IPv4.
4. Ställ in Källzon till WAN.
5. Ställ in Källnätverk/värd till den specifika admin-IP, ett litet adminnätverk eller ett underhållet FQDN/IP-objekt.
6. Begränsa Destinationsvärd till den berörda brandväggsadressen eller gränssnittet om inte alla lokala destinationer är avsiktliga.
7. Ställ in Tjänster på den lokala tjänsten som krävs, till exempel HTTPS för WebAdmin eller API, inte HTTPS och SSH samtidigt för enkelhetens skull.
8. Ställ in Åtgärd på Accept.
9. Spara och testa omedelbart från tillåtna och obehöriga källor.

En ACL Exception Rule består huvudsakligen av dessa fält:

• Rule name: Unikt namn, till exempel admin-https-from-mgmt.
• Rule position: Ordning för ACL-regler.
• Source zone: Zon från vilken åtkomsten kommer, till exempel WAN, LAN eller VPN.
• Source Network / Host: Tillåten admin IP, hanteringsnätverk, FQDN värd eller IP-lista.
• Destination host: Brandväggs IP eller gränssnitt nås.
• Services: Lokal service, till exempel HTTPS, SSH, Ping eller DNS.
• Action: Accept eller Drop.

För att komma åt WebAdmin från Internet bör du aldrig använda Any som källa. Sophos förhindrar medvetet WebAdmin-åtkomst från WAN-zonen för alla källor eftersom detta skulle vara hög risk. Om WAN-åtkomst verkligen är nödvändig bör den endast tillåtas från specifika käll-IP-adresser, definierade nätverk, FQDN-objekt eller andra smala källor.

Samma logik gäller för API-automatisering. En värd kan tillåtas under Administration > API access och ändå misslyckas om HTTPS-behörigheten saknas under Device Access. Omvänt bör en HTTPS-behörighet inte göras bredare bara för att ett API-verktyg ansluts. För API-detaljer passar begränsa Sophos Firewall API-åtkomst säkert.

Ordningen är också viktig. ACL Exception Rules utvärderas från topp till botten. En högre Drop-regel kan ogiltigförklara en senare Accept-regel. Omvänt kan en Accept-regel som är för brett formulerad undergräva senare planerade restriktioner. Ordningen på reglerna bör därför kontrolleras lika medvetet som med brandväggsregler.

Destination host är särskilt viktig om brandväggen har flera gränssnitt, aliasadresser, VPN-adresser eller separata portal-/adminmål. En regel bör så exakt som möjligt peka på den brandväggsadress som faktiskt ska administreras eller användas. Annars kommer det som faktiskt är en smal källversion plötsligt att påverka fler lokala tjänster eller gränssnitt än planerat.

Undvik lockout innan du gör ändringar

Ändringar av enhetsåtkomst påverkar direkt hantering och portalåtkomst. Därför, innan någon begränsning, bör det vara klart hur man kommer tillbaka till brandväggen om en regel är felaktig.

Innan du sparar en riskabel ändring bör du kontrollera:

• Finns en andra administratör med en lämplig rättighetsprofil tillgänglig?
• Finns det åtkomst via ett annat nätverk, till exempel Management-LAN, Admin-VPN eller Sophos Central?
• Finns det lokal konsol eller out-of-band-tillgänglighet om WebAdmin blir oåtkomlig?
• Arbetar du för närvarande på ett HA-kluster där en rolländring kan ändra åtkomstvägen?
• Dokumenteras aktuell backupfil, Secure Storage Master Key och nödåtkomst?
• Finns det ett kort underhållsfönster under vilket felaktig åtkomst omedelbart upptäcks?

Särskilt för avlägsna platser bör du inte först ta bort den breda versionen och sedan testa den. Den omvända processen är säkrare: skapa en ny smal ACL Exception Rule, testa tillåten åtkomst, bekräfta den andra administratörssökvägen och först därefter minska den gamla versionen av breda zoner.

Rulla ut ändringar på ett säkert sätt

Ändringar av enhetsåtkomst kan låsa administratörer. Det är därför du inte bör ändra dem slentrianmässigt, utan snarare behandla dem som ett ledningsbyte.

Beprövad process:

1. Dokument aktuell åtkomst: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP och Ping.
2. Se till att det finns en andra administratörsväg, till exempel lokal konsol, admin-VPN eller Sophos Central.
3. Skapa en säkerhetskopia innan du implementerar större ACL-ändringar.
4. Skapa ny ACL Exception Rule så specifikt som möjligt.
5. Testa åtkomst från den tillåtna källan.
6. Testa åtkomst från en obehörig källa.
7. Log Viewer kontrollera om de förväntade händelserna är synliga.
8. Ta bara bort gammal bred zondelning när ny åtkomst har bekräftats.
9. Dokumentera ändringar med datum, källa, tjänst och ansvarig.

Om flera brandväggar eller HA-kluster påverkas, bör ändringen först testas på ett system med god reservkapacitet. För HA-miljöer är Sophos Firewall Ställ in hög tillgänglighet också lämpligt eftersom hanteringsåtkomst, rolländringar och underhållsfönster måste övervägas tillsammans där.

Uppföljningskontroll efter ändringar av enhetsåtkomst

Efter en justering räcker det inte att bara kontrollera din egen WebAdmin-åtkomst. Du bör testa både tillåtna och otillåtna källor, annars är det oklart om härdningen verkligen fungerar.

• WebAdmin från ledningsnätverket: Access fungerar som planerat.
• WebAdmin från normalt klientnätverk: Åtkomst är blockerad om det inte uttryckligen tillåts.
• SSH från administratörsnätverk: Åtkomst fungerar bara om SSH är medvetet aktiverad.
• SSH från WAN eller gästnätverk: Åtkomsten är blockerad.
• DNS från klientnätverk: DNS fungerar bara i nätverk som är tänkta att använda brandväggen som en resolver.
• User Portal eller VPN Portal: Endast obligatoriska portaler kan nås.
• SNMP från övervakningssystem: Övervakning fungerar, andra källor är blockerade.

Om åtkomsten fungerar oväntat bör inte bara ACL Exception Rule kontrolleras. Zontabellen i det övre enhetens åtkomstområde, anpassade zoninställningar, VPN-zon, proxybeteende och befintliga breda Accept-regler kan också vara orsaken.

En kort lista per tjänst räcker ofta för dokumentation:

• HTTPS: tillåten källa mgmt-net, orsak Adminzugriff WebAdmin, granska kvartalsvis.
• SSH: tillåten källa support-ip-temporary, orsak Supportfall, recension efter att biljetten är klar.
• SNMP: tillåten källa monitoring-server, orsak övervakning av hårdvara och gränssnitt, granska halvårsvis.
• SSL VPN: tillåten källa WAN, orsak Remote Access, granskning med månatlig loggkontroll.

Varje uppföljningskontroll bör också kontrollera om framgångsrik och blockerad åtkomst ens är synlig. Loggvisaren räcker ofta för korta tester. För längre lagrings- eller granskningsfrågor är Central Reporting eller Syslog bättre lämpade eftersom lokala loggar kan roteras eller gå förlorade vid incidenter.

Rekommenderad grundkonfiguration

För många produktiva miljöer är följande logik vettig:

• Tillåt endast HTTPS/WebAdmin från Management, Admin-VPN eller en fast admin-IP.
• Tillåt endast API från definierade automations- eller övervakningsvärdar och begränsa även HTTPS på lämpligt sätt via Device Access.
• SSH inaktivera som standard och tillåt det endast specifikt via ACL om det behövs.
• DNS aktiveras endast i zoner där klienter faktiskt använder brandväggen som en DNS-server.
• Tillåt ping för interna övervakningssystem, men vanligtvis inte från WAN.
• Aktivera bara User Portal, VPN Portal och SSL VPN när de behövs.
• Tillåt endast RED för platser eller källområden där RED apparater faktiskt finns.
• Tillåt SNMP endast för övervakningssystemet.
• SMTP Tillåt relä endast för definierade interna system.
• Aktivera Dynamisk routing endast i routingsegment där dynamiska routingprotokoll faktiskt används.
• Kontrollera MFA för WebAdmin, VPN Portal och fjärråtkomst; Anläggningen är i MFA för Sophos Firewall WebAdmin, VPN Portal och aktivera fjärråtkomst.
• Använd Sophos Central Brandväggshantering om säker extern hanteringsåtkomst krävs.

För längre spårbarhet bör du också kontrollera loggstrategin. Lokala loggar är tillräckliga för akut felsökning, men inte för varje gransknings- eller incidentsvarsfråga. Om portal- eller hanteringsåtkomst behöver kunna spåras på lång sikt är Central Brandväggsrapportering eller Sophos Firewall Skicka syslogg till SIEM de mer lämpliga modulerna.

Hantera SSH med särskild försiktighet

SSH är mycket användbar för felsökning och support, men bör inte lämnas vidöppen permanent. Följande gäller för SSH:

• Endast användare admin kan logga in via SSH.
• Autentisering med offentlig nyckel är det föredragna sättet.
• Åtkomst från WAN bör endast ske via fasta käll-IP-adresser eller VPN.
• Efter att ha slutfört en analys bör det kontrolleras om SSH fortfarande krävs.

Mer information finns i instruktionerna anslut Sophos Firewall via SSH.

Bots, Brute Force och Threat Feeds

I praktiken är det mycket vanligt att se att tjänster som är för öppna omedelbart hittas av bots. Särskilt drabbade är WebAdmin, User Portal, VPN portal och SSL VPN. Även om en tjänst är skyddad av lösenord och MFA skapar offentliga inloggningar attackförsök, brute force-trafik, loggbrus och onödig belastning på brandväggen.

Detta betyder inte automatiskt att en framgångsrik attack kommer att äga rum. Men det visar att tjänsten är en del av den offentliga attackytan. Ju färre källor som kommer till inloggningen, desto bättre.

Om en portal måste vara tillgänglig över hela världen räcker det ofta inte med landsfilter eller individuella käll-IP-adresser. I sådana miljöer rekommenderar vi även Tredjepart Threat Feeds. Threat Feeds förser kontinuerligt brandväggen med aktuella indikatorer på kompromiss, till exempel skadliga IP-adresser, domäner eller URL:er. Detta kan blockera kända skannrar, botnät och angripare från att nå WebAdmin, VPN Portal, SSL VPN eller andra publicerade tjänster.

Den dedikerade artikeln Sophos Firewall Threat Feeds förklarar planering, godkännandelistning och drift.

Vanliga misstag

Brandväggsrules kontrollhjul finns tillgängligt för Device Access

Om WebAdmin, SSH, DNS eller ping till brandväggen inte kan nås, kommer en normal brandväggsregel inte att hjälpa. Trafiken går inte genom brandväggen, utan slutar vid själva brandväggen. Det är därför Administration > Device access måste kontrolleras.

WebAdmin tillåts från för många zoner

WebAdmin ska inte vara tillgänglig från alla interna zoner. Ett gästnätverk, IoT-nätverk eller VoIP-nätverk behöver vanligtvis inte tillgång till brandväggshantering. Det bör även internt antas att det kan finnas klienter som är utsatta för intrång. Ett separat hanteringsnätverk eller en administratör VPN minskar denna risk avsevärt.

DNS inte aktiverad för klientzon

Om klienter ska använda brandväggen som en DNS-server måste DNS tillåtas för lämplig zon. Annars kommer klienterna att nå brandväggens IP men kommer inte att få ett DNS svar. Omvänt bör DNS inte tillåtas från zoner där brandväggen inte är avsedd att användas som en DNS resolver.

User Portal och VPN portalen förvirrad

User Portal och VPN portalen är olika tjänster. Beroende på fjärråtkomstkonceptet måste det kontrolleras vilken portal som verkligen behövs. Ofta aktiveras en portal eftersom en användare var tvungen att ladda ner en konfiguration en gång, men sedan förblir den öppen i flera år. Sådana förorenade platser bör avlägsnas regelbundet.

Om portaler måste förbli tillgängliga från Internet, bör du inte bara markera kryssrutan. Det som är viktigt är MFA, användargrupper, token/provisioning process, utgången av tillfälliga användare, loggning och frågan om portalen fortfarande behövs permanent efter utrullningen.

Web Proxy Specialfall förbises

När Web Proxy används kan HTTP- och HTTPS-förfrågningar visas interna från ett proxyperspektiv. Detta kan påverka hur åtkomst till WebAdmin, Captive Portal, VPN Portal eller User Portal kontrolleras. I miljöer med proxy bör du därför testa särskilt noggrant vilken åtkomst som verkligen är möjlig.

ACL-regeln formulerad för brett

En ACL Exception Rule med Source zone: Any, Source Network / Host: Any och Services: HTTPS, SSH är nästan aldrig en bra idé. Sådana regler kringgår den faktiska säkerhetsfördelen med ACL-undantaget. Det är bättre att ha en liten, tydlig regel med en tydlig källa och exakt de tjänster som krävs.

Släpp regeln i fel position

Om en släppregel ligger över en acceptregel kan tillåten åtkomst fortfarande blockeras. Med ACL Exception Rules är ordningen lika viktig som med brandväggsregler.

Omvänt kan en regel för bred acceptans överst på listan göra efterföljande släppregler praktiskt taget värdelösa. Efter varje regeländring bör inte bara den nya regeln, utan även träfflogiken för reglerna ovan kontrolleras.

SSL VPN och VPN portalen lämnades för öppen

Fjärråtkomst måste ofta vara tillgänglig utifrån. Ändå bör du kontrollera om alla länder, nätverk och användargrupper verkligen behöver tillgång. Om snäv källbegränsning inte är möjlig bör MFA, loggning och Threat Feeds användas ännu mer konsekvent.

Felsökning

Om en lokal tjänst inte är tillgänglig hjälper den här sekvensen:

1. Är brandväggens mål-IP korrekt?
2. Kommer klienten från den förväntade zonen?
3. Är service tillåten i Administration > Device access för denna zon?
4. Finns det en lämplig ACL-undantagsregel för lokala tjänster?
5. Gäller en högre ACL-regel med Drop möjligen?
6. Är tjänsten konfigurerad på en annan port?
7. Visas åtkomst via VPN, proxy eller NAT annorlunda än förväntat?
8. Visar Log Viewer en ledtråd?
9. Kan Packet Capture se anslutningsförsöket på gränssnittet?

För supportåtkomst kan det vara meningsfullt att skapa en riktad ACL Exception Rule och sedan ta bort eller inaktivera den efter slutförandet.

Checklista för verksamheten

• WebAdmin kan inte nås brett från WAN.
• SSH tillåts endast tillfälligt eller från lednings-/adminnätverk.
• DNS endast aktiv för klientzoner som faktiskt använder brandväggen som resolver.
• SNMP tillåts endast av övervakningssystemet eller övervakningsnätverket.
• User Portal, VPN portal och SSL VPN är endast aktiva om de behövs i fjärråtkomstkonceptet.
• MFA kontrollerade för WebAdmin, VPN portal och fjärråtkomst.
• API-åtkomst tillåts endast från definierade värdar och kontrolleras mot Device Access.
• ACL Exception Rules namngiven med tydlig källa, tjänst och syfte.
• Tillfälliga supportregler dokumenterade med utgångsdatum.
• Testad åtkomst från tillåtna och förbjudna källor.
• Loggning, Central Reporting eller Syslog kontrolleras för relevant portal- och hanteringsåtkomst.
• Kvartalsgranskning planerad för WebAdmin, SSH, SNMP, User Portal, VPN portal och SSL VPN.

FAQ