Skydda Sophos Firewall VPN Portal mot brute force-attacker

Många misslyckade inloggningar till Sophos Firewall VPN Portal visar till en början att portalen är nåbar från internet och utsätts för automatiserade attacker. De bevisar ännu inte att ett intrång har lyckats. Situationen blir kritisk när verkliga användarnamn träffas, konton i AD eller Microsoft Entra ID låses eller en okänd lyckad inloggning visas mellan de misslyckade försöken.

Begränsa attacken i följande ordning:

1. Spara tidsintervall, användare, käll-IP-adresser och autentiseringsmetoder i loggarna.
2. Kontrollera lyckade inloggningar och identitetshändelser under samma period.
3. Begränsa VPN Portal till nödvändiga källor eller länder med en Local Service ACL.
4. Aktivera Block login och uteslut portdelning mellan VPN Portal och SSL VPN.
5. Ta bort autentiseringsmetoder som inte behövs och kontrollera MFA eller Entra-skydd.
6. Blockera dessutom kända skadliga IPv4-källor via Threat Feeds och övervaka effekten.

⚠️ Stäng inte av VPN Portal utan förberedelser. Sophos Connect Provisioning och Microsoft Entra ID SSO använder VPN Portal-porten. Före ändringar av Device Access eller portar krävs en testad andra administratörsväg och en plan för klientprofiler, Redirect URIs och återställning.

Dokumentera inställningarna eller spara en konfigurationsbackup före varje ändring. Ta med WAN-valet för VPN portal, alla fält och ordningen för Local Service ACL-undantag, aktiveringsstatus och de tre värdena för Block login, portar och protokoll för VPN Portal och SSL VPN samt val och ordning för autentiseringsservrar. För provisioning eller Entra SSO sparas även vpn_portal_port, portalens URL och Redirect URI. För ändrade Threat Feeds sparas URL, indikatortyp, action, status och anpassade alternativ. Återställningen använder dessa värden, inte antagna standardvärden.

Bekräfta attacken i Log Viewer

Öppna autentiseringshändelserna i Log Viewer och filtrera på:

• Log component: VPN Portal Authentication
• Status: Failed

För varje träff är tidpunkt, Source IP, Source country, Username, Authentication mechanism och Reason relevanta. Alla visas inte som standardkolumner i varje vy; Detailed view och extra kolumner visar tillgängliga händelsedetaljer. Kontrollera även råloggar och Identity Provider-loggar om sammanhang saknas. I ett SIEM filtreras log_component på VPN Portal Authentication och status på Failed; syntaxen beror på SIEM-systemet.

Sök därefter även efter Successful för samma användarnamn och tidsintervall. En okänd lyckad inloggning är viktigare än enbart antalet misslyckade försök och måste hanteras som en möjlig kontoincident.

En enda källa eller en distribuerad attack

Fördelningen avgör vilket skydd som fungerar:

• Många försök från en IP-adress: Block login kan tillfälligt blockera källan när tröskelvärdet har nåtts.
• Få försök från många IP-adresser: Ett distribuerat botnät kan förbli under tröskelvärdet för varje källa. ACL:er, identitetsskydd och Threat Feeds blir då viktigare.
• Många användarnamn från samma källa: Detta stämmer med Password Spraying eller Credential Stuffing.
• Upprepade försök mot samma verkliga användare: Kontrollera AD-, Entra- eller RADIUS-loggar efter kontolåsningar och lyckade inloggningar.
• Slumpmässiga namn som inte finns: Detta är ofta automatiserad skanning, men skapar fortfarande belastning och loggbrus.

Att manuellt blockera enbart käll-IP-adressen löser sällan en distribuerad attack permanent. Minska först den nåbara ytan och lägg därefter automatiskt till kända skadliga källor.

Kontrollera råloggar riktat

Om Log Viewer inte ger tillräckligt sammanhang hämtas de berörda filerna under Diagnostics > Tools > Troubleshooting logs:

• vpnportal.log för portalåtkomst;
• access_server.log för användarautentisering och auktorisering;
• oauth_sso_vpn.log dessutom för Microsoft Entra ID SSO.

sslvpn.log hör däremot till SSL VPN-tjänsten och blir relevant först när felet uppstår vid tunneluppbyggnaden i stället för vid portalinloggningen. Autentiseringsloggar kan innehålla användarnamn, offentliga IP-adresser och andra känsliga uppgifter från förfrågningar. Begränsa därför utdrag i tid och innehåll, maskera dem innan de delas och kopiera dem inte okontrollerat till offentliga ärenden. Sophos Firewall-tjänster och loggar kopplar fler loggfiler till rätt tjänst; Spara Sophos Firewall-loggar beskriver ett strukturerat supportarkiv.

Begränsa VPN Portal till nödvändiga källor

VPN Portal är en lokal brandväggstjänst. Vanliga brandväggs- eller DNAT-regler styr inte denna åtkomst; för detta används Administration > Device access. De fullständiga grunderna finns i Device Access och Local Service ACL.

Före ändringen ska en oberoende åtkomst via konsol, management-LAN, administratörs-VPN eller Sophos Fusion (tidigare Sophos Central) öppnas och faktiskt testas. Skapa därefter först det begränsade undantaget:

1. Klicka på Add under Administration > Device access > Local service ACL exception rule.
2. Rule name: till exempel vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; om IPv6 är publicerat krävs dessutom en separat IPv6-regel.
5. Source zone: WAN.
6. Source networks and hosts: fasta partnernät, en underhållen IP-lista eller en Country Group med de länder som faktiskt behövs.
7. Destination host: WAN-gränssnittet eller den WAN-IP som konfigurerats på Sophos Firewall och som åtkomsten kommer in på. Bakom en framförliggande NAT-router avses inte routerns offentliga adress.
8. Services: endast VPN portal.
9. Action: Accept.
10. Spara regeln.

Testa efter sparandet först undantaget från en tillåten extern källa. Ta via den verifierade andra administratörsvägen bort det allmänna WAN-valet för VPN portal i Device Access och spara. Ändringar får omedelbar effekt. Den tillåtna källan ska fortfarande nå portalen och en otillåten extern källa ska inte göra det. Återställ det tidigare WAN-valet via den andra vägen om det positiva testet misslyckas. Device Access-guiden beskriver fler varianter.

En landsbegränsning är lämplig när användargruppen är tydligt geografiskt avgränsad. Den är dock ingen identitetskontroll: resenärer, mobilnät, VPN-leverantörer och felaktigt tilldelad IP-geolokalisering kan låsa ute legitima användare. Global åtkomst kräver därför särskilt starkt identitetsskydd, MFA, loggning och en granskningsprocess.

Brandväggens konfigurerade webbproxy är ett viktigt undantag. SFOS behandlar dess HTTP- och HTTPS-förfrågningar som intern trafik och inte som trafik från en zon. Användare med proxyåtkomst kan därför nå VPN Portal och andra HTTP-tjänster på brandväggen även när Device Access inaktiverar dem för användarens zon. Vid proxyanvändning görs negativtestet en gång direkt och en gång verifierbart via explicit eller transparent webbproxy. Device Access kan inte zonblockera denna interna väg; begränsa själva proxyåtkomsten vid oönskat resultat.

Ställ in Login Security och portar korrekt

Aktivera Block login under Administration > Admin and user settings > Login security och fyll i de tre fälten för antal försök, tidsintervall och blockeringstid. Fem försök på 60 sekunder med fem minuters blockering är bara ett exempel, inte ett universellt Sophos-standardvärde eller ett produktionsvärde att använda utan pilot. Välj värden efter användarantal, helpdesk och delade NAT-källor. Testa från en kontrollerad käll-IP medan den andra administratörsvägen är öppen.

Blockeringen fungerar per käll-IP och gäller alla tjänster efter tröskeln, däribland WebAdmin, CLI, VPN Portal och User Portal. Bakom NAT på kontor, hotell eller leverantör kan flera användare och en administratör påverkas samtidigt. Utför aldrig negativtestet via den enda administratörsvägen.

Vid en distribuerad attack är Block login endast ett skyddslager. Många botar kan var och en ligga under tröskelvärdet. Misslyckade CAPTCHA-inmatningar räknas inte som misslyckade inloggningar och utlöser inte blockeringen.

Uteslut portdelning

Jämför följande två värden:

• Administration > Admin and user settings > VPN portal HTTPS port, som standard TCP 443
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, som standard 8443 med TCP eller UDP

Om VPN Portal och SSL VPN använder samma port och samma protokoll gäller inte inställningarna för Login Security. Dessutom blir VPN Portal nåbar från de zoner som tillåts för SSL VPN, även om den är inaktiverad där i Device Access.

Kombinationen måste därför vara unik. Att enbart flytta tjänsten till en slumpmässig port förhindrar ingen attack. Om VPN Portal-porten ändras måste portalens URL, Entra Redirect URI och värdet vpn_portal_port för Sophos Connect Provisioning anpassas och testas på nytt med en pilotanvändare.

Skydda autentisering och berörda konton

Under Authentication > Services > VPN portal authentication methods ska endast nödvändiga servrar vara aktiva. En oanvänd lokal, AD-, LDAP- eller RADIUS-väg tillåter onödiga försök mot en annan katalog. Minst en server måste vara vald. VPN Portal stöder inte RADIUS med challenge-based MFA; planera därför inte detta som portal-MFA.

MFA förhindrar inte varje misslyckat försök, men minskar risken att ett känt eller gissat lösenord ensamt räcker. MFA för VPN Portal och Remote Access beskriver konfigurationen för lokala användare och kataloganvändare. Vid Microsoft Entra ID SSO ska även Entra MFA, Conditional Access, Sign-in Logs och Risk Events kontrolleras.

En verklig användare med misstänkta misslyckade försök ska inte enbart undersökas på brandväggen:

1. Kontrollera kontolåsningar och lyckade inloggningar hos ansvarig Identity Provider.
2. Avsluta okända lyckade sessioner enligt incidentprocessen.
3. Återställ lösenord och registrerade MFA-metoder vid misstanke om kompromettering.
4. Kontrollera gruppmedlemskap och Remote Access-behörighet.
5. Först därefter kontrolleras med en dokumenterad pilotinloggning att legitim åtkomst fungerar igen.

VPN Portal kan endast tas bort från WAN om ingen nödvändig process är beroende av den. .pro-provisioning ansluter via vpn_portal_port. Vid Entra SSO måste URL:en för VPN Portal och Remote Access samt registrerad Redirect URI motsvara publicerad gateway och port. Manuellt distribuerade .ovpn-filer kan möjliggöra striktare publicering, men profiländringar kräver kontrollerad distribution och testning.

Lägg till Threat Feeds mot kända källor

Sophos Firewall kan även matcha kända skadliga käll-IP-adresser i trafik till brandväggens egna tjänster, däribland VPN Portal, WebAdmin och VPN. Enligt SFOS 22 gäller detta MDR, NDR Essentials och Third-Party Threat Feeds, men inte Sophos X-Ops Threat Feeds. En underhållen Third-Party Feed med IPv4-adresser är därför ett extra lager för kända källor.

Konfigurera Threat Feeds på Sophos Firewall beskriver den fullständiga konfigurationen, licenskrav, Monitor-pilot, Block-drift, False Positives och de Cybora-feeds som Avanet har testat. För en ny feed gäller fortfarande att hämtning och IoC-innehåll ska kontrolleras, effekten först observeras och blockering aktiveras kontrollerat först därefter.

Aktivera Local reporting för Active threat response under System services > Log settings för lokala träffar i Log Viewer. XGS 87/87w och 107/107w stöder inte lokal rapportering; använd Sophos Fusion eller en Syslog-server.

Threat Feeds ersätter inte en ACL eller stark autentisering. De matchar bara listade adresser. Third-Party Feeds accepterar enskilda IPv4-adresser men inte IPv6, IP-intervall eller nätadresser; nya botadresser förblir nåbara. En False Positive kan blockera legitima användare. Starta en feed i Monitor, kontrollera fel och oväntade träffar och byt först därefter till Block. En Threat Exclusion gäller alla Active Threat Response-moduler och ska därför vara snäv, motiverad och tidsbegränsad. Granska träffar och undantag regelbundet.

Vid återställning sätts en ändrad feed tillbaka till föregående action; en ny feed inaktiveras utan att raderas ogranskat. Kontrollera sedan att en källa med False Positive åter når portalen och att övriga skydd fungerar.

Kontrollera effekten och fortsätt övervaka

Upprepa samma definierade test efter varje ändring:

1. En tillåten extern källa når VPN Portal och en pilotanvändare kan logga in.
2. En otillåten källa når inte längre portalen.
3. VPN Portal och SSL VPN använder en unik kombination av port och protokoll.
4. Ett kontrollerat misslyckat försök visas i Log Viewer med förväntad käll-IP och autentiseringsmetod.
5. Sophos Connect Provisioning, Entra SSO och själva VPN-tunneln fortsätter att fungera.
6. Threat Feed-träffar visas på den konfigurerade loggdestinationen om skyddet används.
7. Inga nya AD- eller Entra-låsningar eller okända lyckade inloggningar sker under observationsperioden.

Om ett test misslyckas återställs först bara den senaste ändringen till dokumenterat tidigare värde. Det kan gälla feed-action, server, Block login, port och Redirect URI eller Device Access. För Device Access återställs först gamla WAN via den andra vägen, sedan tas det nya ACL-undantaget bort. För port återställs port och protokoll, .pro, portal-URL och Redirect URI tillsammans, varefter tillåtet och nekat test upprepas.

För långsiktig upptäckt skickas autentiseringsloggar till ett SIEM. Lämpliga larm tar inte bara hänsyn till antalet fel, utan även många olika källor mot samma användare, många användarnamn från en källa och lyckade inloggningar efter en serie misslyckade försök.

FAQ