Säkra åtkomst till Sophos Firewall: konfigurera Device Access

Under Administration > Device access anger man från vilka zoner lokala tjänster på Sophos Firewall ska vara åtkomliga. Det gäller till exempel HTTPS för WebAdmin Console, SSH för CLI, Ping, DNS, User Portal, VPN Portal och andra tjänster.

Detta område är säkerhetskritiskt. Vanliga firewall-regler styr trafik genom brandväggen. Device access styr trafik till själva brandväggen. Om WebAdmin eller SSH är åtkomliga från en osäker zon uppstår direkt managementåtkomst till säkerhetsenheten.

⚠️ WebAdmin, SSH och portaler bör bara vara åtkomliga från betrodda nät. I produktionsmiljöer är det bättre att begränsa åtkomsten till ett managementnät, en fast admin-IP, VPN eller Sophos Central Firewall Management.

Varför Device Access inte är en firewall-regel

En typisk firewall-regel tillåter eller blockerar anslutningar mellan zoner, till exempel LAN till WAN eller VPN till Server. Device Access är annorlunda: det 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 DNS-server.
• Ett övervakningssystem pingar brandväggen.
• En användare öppnar User Portal eller VPN Portal.
• En administratör ansluter till brandväggen via SSH.

Sådan trafik har inte en server bakom brandväggen som mål, utan brandväggen själv. Därför styrs den via den lokala service ACL.

Det är också därför Device Access hör till grundläggande hardening av varje Sophos Firewall. En ren LAN-till-WAN-regeluppsättning skyddar inte automatiskt brandväggens egna management- och portaltjänster. Dessa tjänster måste kontrolleras separat och begränsas medvetet.

Förstå zonåtkomst

I den övre delen av Administration > Device access finns en tabell med zoner och tjänster. Om en tjänst är aktiverad för en zon är åtkomst till den lokala tjänsten i princip tillåten från den zonen.

Zontabellen är praktisk, men grov. Den passar för tydliga interna zoner som LAN, Management eller VPN. Så snart en tjänst bara ska vara åtkomlig för enskilda admin-IP-adresser, platser, länder eller supportmål är Local service ACL exception rules ett bättre val.

Typiska exempel:

För Custom Zones kan åtkomlighet till lokala tjänster även påverkas via zoninställningarna. Ändå bör Device Access alltid kontrolleras medvetet, eftersom detta är den centrala översikten för lokala firewall-tjänster.

Vilka tjänster kan begränsas med ACL Rules?

Med Local Service ACL och ACL Exception Rules kan man styra lokala firewall-tjänster mycket exakt. Dessa tjänster är särskilt relevanta:

Ju fler av dessa tjänster som är åtkomliga från WAN, gästnät, IoT-nät eller otydligt definierade zoner, desto större blir attackytan. Målet är inte att stänga av allt, utan att göra varje tjänst åtkomlig endast där den verkligen behövs.

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

En ACL Rule behöver inte bara tillåta Any. Som källa kan man arbeta mycket exakt, till exempel med:

• enskilda admin-IP-adresser
• managementnät
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts eller DNS groups
• Country objects eller landsgrupper
• dedikerade VPN- eller supportnät

På så sätt kan åtkomst begränsas mycket bättre. Exempel: Om en extern supporttjänst bara kommer från en fast FQDN eller ett definierat IP-intervall ska inte hela WAN-zonen få åtkomst till HTTPS eller SSH. Om ett övervakningssystem behöver SNMP ska inte ett helt servernät få fråga SNMP på brandväggen.

I globala Remote Access-scenarier är avgränsningen svårare. Vissa företag kan inte bara tillåta SSL VPN eller VPN Portal från Schweiz, Tyskland eller ett enskilt land, eftersom medarbetare arbetar över hela världen. I sådana fall bör man dessutom använda MFA, logging, restriktiva portalinställningar och Threat Feeds.

Local Service ACL Exception Rule

Om en tjänst inte ska vara aktiverad för en hel zon använder man en Local service ACL exception rule. Då kan man mycket exakt definiera vem som får åtkomst 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.

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

För WebAdmin-åtkomst från internet ska man aldrig använda Any som källa. Sophos förhindrar medvetet WebAdmin-åtkomst från WAN-zonen för alla källor, eftersom detta vore en hög risk. Om WAN-åtkomst verkligen behövs bör den bara tillåtas via specifika käll-IP-adresser, definierade nät, FQDN-objekt eller andra snäva källor.

Ordningen är också viktig. ACL Exception Rules utvärderas uppifrån och ned. En högre Drop-regel kan göra en senare Accept-regel verkningslös. Omvänt kan en för brett formulerad Accept-regel upphäva planerade begränsningar. Regelordningen bör därför kontrolleras lika medvetet som firewall-regler.

Rekommenderad grundkonfiguration

För många produktionsmiljöer är följande logik rimlig:

• Tillåt HTTPS/WebAdmin bara från Management, admin-VPN eller en fast admin-IP.
• Inaktivera SSH som standard och tillåt bara vid behov via riktad ACL.
• Aktivera DNS bara i zoner där klienter verkligen använder brandväggen som DNS-server.
• Tillåt Ping för interna övervakningssystem, men inte generellt från WAN.
• Aktivera User Portal, VPN Portal och SSL VPN bara när de behövs.
• Tillåt RED bara för platser eller källintervall där det faktiskt finns RED Appliances.
• Tillåt SNMP bara från övervakningssystemet.
• Tillåt SMTP Relay bara för definierade interna system.
• Aktivera Dynamic Routing bara i routingsegment där dynamiska routingprotokoll verkligen används.
• Kontrollera MFA för WebAdmin, VPN Portal och Remote Access.
• Använd Sophos Central Firewall Management om säker extern managementåtkomst behövs.

Behandla SSH särskilt försiktigt

SSH är mycket användbart för troubleshooting och support, men bör inte vara brett öppet permanent. För SSH gäller:

• Endast användaren admin kan logga in via SSH.
• Public-key-autentisering är den föredragna metoden.
• Åtkomst från WAN bör bara ske via fasta käll-IP-adresser eller VPN.
• Efter en analys bör man kontrollera om SSH fortfarande behövs.

Mer information finns i guiden Ansluta till Sophos Firewall via SSH.

Bots, brute force och Threat Feeds

I praktiken ser man mycket ofta att alltför öppna tjänster omedelbart hittas av bots. Särskilt WebAdmin, User Portal, VPN Portal och SSL VPN påverkas. Även om en tjänst skyddas med lösenord och MFA skapar publika inloggningar attackförsök, brute-force-trafik, loggbrus och onödig belastning på brandväggen.

Det betyder inte automatiskt att en attack lyckas. Det visar däremot att tjänsten är en del av den publika attackytan. Ju färre källor som ens når inloggningen, desto bättre.

Om en portal måste vara globalt åtkomlig räcker ofta inte landsfilter eller enskilda käll-IP-adresser. I sådana miljöer rekommenderar vi dessutom Third-Party Threat Feeds. Threat Feeds förser brandväggen löpande med aktuella Indicators of Compromise, till exempel skadliga IP-adresser, domäner eller URL:er. Kända skannrar, botnät och angripare kan därmed blockeras innan de når WebAdmin, VPN Portal, SSL VPN eller andra publicerade tjänster.

Mer information: Sophos Firewall Threat Feeds

Vanliga misstag

Firewall-regel kontrolleras i stället för Device Access

Om WebAdmin, SSH, DNS eller Ping till brandväggen inte är åtkomliga hjälper inte en vanlig firewall-regel. Trafiken går inte genom brandväggen, utan slutar på brandväggen själv. Därför måste Administration > Device access kontrolleras.

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

WebAdmin bör inte vara åtkomligt från varje intern zon. Ett gästnät, IoT-nät eller VoIP-nät behöver normalt ingen åtkomst till firewall-management. Även internt bör man utgå från att komprometterade klienter kan finnas. Ett separat managementnät eller admin-VPN minskar denna risk tydligt.

DNS inte aktiverat för klientzonen

Om klienter ska använda brandväggen som DNS-server måste DNS vara tillåtet för rätt zon. Annars når klienterna brandväggens IP, men får inget DNS-svar. Omvänt bör DNS inte tillåtas från zoner där brandväggen inte ska användas som DNS resolver.

User Portal och VPN Portal blandas ihop

User Portal och VPN Portal är olika tjänster. Beroende på Remote Access-koncept måste man kontrollera vilken portal som verkligen behövs. Ofta aktiveras en portal för att en användare en gång behövde ladda ned en konfiguration, och därefter förblir den öppen i flera år. Sådana rester bör tas bort regelbundet.

Web Proxy-specialfall förbises

När Web Proxy används kan HTTP- och HTTPS-förfrågningar se interna ut ur proxyns perspektiv. Det kan påverka hur åtkomst till WebAdmin, Captive Portal, VPN Portal eller User Portal kontrolleras. I miljöer med proxy bör man därför testa särskilt noggrant vilka åtkomster som verkligen är möjliga.

ACL-regel för brett formulerad

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 egentliga säkerhetsvinsten med ACL-undantag. Bättre är en liten, tydlig regel med en entydig källa och exakt de tjänster som behövs.

Drop-regel på fel plats

Om en drop-regel ligger ovanför en accept-regel kan den tänkta åtkomsten ändå blockeras. För ACL Exception Rules är ordningen därför lika viktig som för firewall-regler.

SSL VPN och VPN Portal lämnas för öppna

Remote Access måste ofta vara åtkomligt utifrån. Ändå bör man kontrollera om alla länder, nät och användargrupper verkligen behöver åtkomst. Om snäv källbegränsning inte är möjlig bör MFA, logging och Threat Feeds användas desto mer konsekvent.

Troubleshooting

Om en lokal tjänst inte är åtkomlig hjälper denna ordning:

1. Stämmer brandväggens mål-IP?
2. Kommer klienten från den förväntade zonen?
3. Är tjänsten tillåten för denna zon under Administration > Device access?
4. Finns en passande Local service ACL exception rule?
5. Matchar eventuellt en högre ACL-regel med Drop?
6. Är tjänsten konfigurerad på en annan port?
7. Ses åtkomsten annorlunda på grund av VPN, proxy eller NAT?
8. Visar Log Viewer någon ledtråd?
9. Kan Packet Capture se anslutningsförsöket på interfacet?

För supportåtkomst kan det vara lämpligt att skapa en riktad ACL Exception Rule och ta bort eller inaktivera den efter avslutat arbete.

Mer information

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Ansluta till Sophos Firewall via SSH
• Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access