Sophos Firewall: Blockera länder och skadliga IP-adresser

Så snart tjänster är tillgängliga från internet ser man ofta oönskad trafik: portskanningar, inloggningsförsök, kända botnät eller åtkomst från länder där inga användare förväntas. På Sophos Firewall kan man blockera sådana källor på flera nivåer.

Denna artikel förklarar två typiska varianter:

• Blockera länder eller källnät med en Firewall Rule
• Översätta oönskade källor till en Black Hole DNAT Rule

Vi rekommenderar också Sophos Firewall Threat Feeds för att automatiskt blockera kända skadliga IP-adresser, domäner eller URL:er.

Orientering

Innan källor blockeras måste det vara tydligt vilken trafik som avses: publicerade tjänster, lokala brandväggstjänster, utgående klienttrafik eller WAF-trafik. Rätt metod beror exakt på detta.

Vilken metod passar när?

• Firewall Rule med Drop: Blockerar trafik baserat på Source Country, Source Network eller Source Host. Detta passar för länderblockeringar, enskilda nät eller manuellt underhållna dåliga IP-listor.
• Black Hole DNAT: Omdirigerar oönskad trafik till en icke-existerande intern IP. Detta är användbart när trafik till publicerade tjänster ska fångas upp tidigt.
• WAF Blocked countries: Gäller webbservrar som publiceras via WAF. Länder blockeras direkt i WAF-regeln.
• Local service ACL exception rule: Styr lokala brandväggstjänster som WebAdmin, User Portal, VPN Portal eller SSH. Detta är rätt plats när själva brandväggen ska skyddas.
• Threat Feeds: Använder dynamiska listor över kända skadliga källor. Detta passar för botnät, skannrar, malware-infrastruktur och kända angripar-IP-adresser.

Vilken metod som är lämplig beror på var trafiken tekniskt bearbetas. Firewall-regler gäller inte alltid för trafik som går till en Hosted Address som används i WAF. I sådana fall är en WAF-länderregel eller en Black Hole DNAT Rule ofta bättre lämpad.

Inkommande, utgående eller lokal brandvägg

Innan en blockregel bör det vara klart vilken typ av trafik som avses. Annars blockeras man på fel ställe och undrar senare varför attacken fortfarande är synlig eller varför legitim trafik faller bort.

• Inkommande till publicerad server: Portvidarebefordran på RDP, HTTPS, SMTP eller egen applikation. DNAT-ordning, WAF-regel, Firewall Rule, IPS och loggning
• Inkommande till själva brandväggen: WebAdmin, User Portal, VPN Portal, SSH, Ping eller DNS på brandväggen. Device Access och Local Service ACL Exception Rules
• Utgående från interna klienter: Klienter kontaktar misstänkta mål på internet. Firewall Rule, Threat Feeds, Web Protection, DNS Protection och loggning
• Webbserver via WAF: Offentlig webbapplikation bakom Web Server Protection. WAF-regel, Blocked countries, autentisering, MFA och WAF-loggar

Denna uppdelning är viktig eftersom en länderregel i Rules and policies > Firewall rules inte automatiskt säkrar varje attackyta på brandväggen. För publicerade servrar står oftast NAT- och WAF-kedjan i förgrunden. För admin-portaler är det först viktigt om den lokala brandväggstjänsten överhuvudtaget är tillgänglig från zonen. För utgående klienttrafik är Threat Feeds, Web Protection och DNS Protection ofta de renare verktygen.

Inte förväxla med Device Access

Country Blocking och Black Hole DNAT skyddar i första hand trafik som bearbetas genom Firewall- eller NAT-regler. Lokala tjänster på Sophos Firewall är ett annat fall. Dessa inkluderar till exempel WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping och delvis även fjärråtkomsttjänster.

För dessa lokala tjänster är först Administration > Device access relevant. Där bestämmer man från vilka zoner en tjänst i grunden är tillgänglig. Om åtkomst endast ska tillåtas för enskilda admin-IP-adresser, länder eller supportkällor är Local service ACL exception rules den rätta kontrollpunkten. Förfarandet beskrivs i Säkra åtkomst till Sophos Firewall: Konfigurera Device Access korrekt.

⚠️ En Country-Block-regel ersätter inte en korrekt Device-Access-konfiguration. Om WebAdmin, User Portal, VPN Portal eller SSH är för brett tillgängliga, förblir brandväggen själv en attackyta. Country Blocking kan minska risken, men inte ersätta den grundläggande åtkomsthärdningen.

För särskilt skyddsvärda lokala tjänster bör WAN inte aktiveras brett under Local service ACL. Bättre är en exception rule som endast tillåter förväntade källor eller blockerar oönskade länder. För WebAdmin är en fast admin-IP eller management-VPN oftast renare än ett landsfilter, eftersom Geo-IP inte är en verklig identitetskontroll.

Planera blockeringsregler

Blockeringsregler bör planeras så att legitim trafik inte avbryts av misstag.

Blockera länder med en Firewall Rule

För allmän Country Blocking kan man skapa en Firewall Rule med Drop.

Menypath:

Rules and policies > Firewall rules

Rekommenderade fält:

• Rule name: Beskrivande namn, till exempel BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Action: Drop
• Source zones: Any
• Source networks and devices: Land, ländergrupp, IP-lista eller värdgrupp
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any eller en definierad tjänst

För Country Blocking är det viktigt att Source zones och Destination zones inte sätts för snävt. Om man bara anger WAN som Source zone kanske regeln inte gäller för alla relevanta trafikvägar.

Länder och landsgrupper används som objekt under Hosts and services. För flera länder är en Country host group tydligare än många enskilda länder direkt i varje regel. Dåliga IP-listor hör däremot hemma i lämpliga IP host- eller IP host group-objekt. Gränserna är viktiga: IP host-listor är inte avsedda för godtyckligt stora dynamiska feeds. För ständigt förändrad angriparinfrastruktur är Threat Feeds enklare att underhålla.

Country Blocking bör också förstås som en Best-Effort-kontroll. Geo-IP-data kan vara felaktiga, användare reser, angripare använder proxies eller komprometterade system i tillåtna länder, och molntjänster använder globalt distribuerad infrastruktur. Därför bör en länderregel aldrig vara den enda skyddsåtgärden.

När man inte bör blockera för brett

En blockregel är snabbt skapad, men kan senare orsaka svårförståeliga bieffekter. Man bör vara särskilt försiktig om produktiva applikationer är beroende av externa plattformar, CDN:er, betalningsleverantörer, molntjänster, övervakningsleverantörer eller supportpartners.

Innan en bred land- eller IP-blockering bör man därför klargöra:

• Finns det användare, partners eller tjänsteleverantörer i de berörda länderna?
• Använder en applikation moln- eller CDN-infrastruktur med varierande källadresser?
• Utlöses uppdateringar, webhooks, övervakning, säkerhetskopior eller supportåtkomst via externa tjänster?
• Finns det en möjlighet att först bara logga eller testa regeln tidsbegränsat?
• Är det klart vem som kontrollerar falska positiva och hur ett undantag godkänns?

För internettjänster med riktig användarinloggning är länderregler ofta bara en extra åtgärd. MFA, snäva Firewall-regler, aktuella målsystem, IPS, WAF-skydd, loggning och Threat Feeds förblir viktigare än en så lång blocklista som möjligt.

Planera Allowlist före Blocklist

För kritiska tjänster är en Allowlist ofta renare än en ständigt växande Blocklist. Om en tjänst bara behöver vara tillgänglig från fasta partners, filialer, övervakningssystem eller admin-platser bör man först tillåta dessa källor och blockera resten. Det minskar underhållsbehovet och förhindrar att man reaktivt måste blockera varje ny skanner-IP individuellt.

En Allowlist passar särskilt bra för:

• Admin-åtkomst till publicerade management-tjänster
• B2B-gränssnitt med kända partner-IP-adresser
• Övervakning, säkerhetskopiering, webhooks eller API-slutpunkter med fasta källsystem
• Tillfällig supportåtkomst med biljett, utgångsdatum och granskning

En Blocklist passar bättre när en tjänst medvetet måste vara offentligt tillgänglig, men man vill minska påfallande källor. Då bör regeln drivas med loggning, granskningsdatum och tydliga undantag. För webbservrar som publiceras via WAF är dessutom Sophos Firewall WAF: Publicera webbservrar säkert relevant, eftersom länder, autentisering och webbserverskydd där styrs närmare den publicerade applikationen.

Behandla WAF-landsfilter separat

I Web Server Protection har WAF-regeln egna fält för Allowed client networks, Blocked client networks, Blocked countries och Block IP addresses of unknown country-origin. Dessa inställningar hör till den publicerade webbapplikationen och är inte samma sak som en normal firewall-Drop-regel.

Det är praktiskt eftersom landsfiltret sitter direkt på WAF-publiceringen. Samtidigt krävs försiktighet: Block IP addresses of unknown country-origin kan utesluta legitima användare om deras IP-adress inte kan tilldelas tydligt. Innan aktivering bör den egna externa IP-adressen kontrolleras med GeoIP2 Databases Demo. Denna option bör endast aktiveras när effekten är testad och känd i supportprocessen.

För WAF-regler är landsfilter bara en byggsten. Autentisering, MFA, certifikat, Web Server Protection, IPS/WAF-signaturer, loggning och en uppdaterad backendserver är fortfarande viktigare än en lång lista över blockerade länder.

Black Hole DNAT och Threat Feeds

För publicerade tjänster kan det vara meningsfullt att fånga upp oönskade källor redan före den produktiva DNAT-regeln. För dynamisk angriparinfrastruktur är Threat Feeds dessutom användbara.

Black Hole DNAT för oönskade källor

En Black Hole DNAT Rule översätter trafik till ett mål som inte finns i nätverket. Trafiken går därmed in i tomma intet och når inte den egentliga tjänsten.

Detta är särskilt användbart när en tjänst publiceras via DNAT och man vill fånga upp vissa källor innan den egentliga portvidarebefordran.

Black Hole DNAT bör användas selektivt. Det är särskilt lämpligt för trafik till publicerade tjänster där en vanlig DNAT-regel ligger under. För allmän utgående klienttrafik, lokala brandväggstjänster eller webbservrar som publiceras via WAF är oftast en Firewall Rule, Device Access eller en WAF-inställning den bättre kontrollpunkten.

I NAT-regeln är det viktigt att inte blanda ihop angriparens ursprungliga vy med det översatta dummy-målet. Regeln hör hemma i Rules and policies > NAT rules ovanför den produktiva DNAT-regeln. Original source innehåller den blockerade IP-listan, landet eller ländergruppen. Original destination är den offentliga WAN-adressen eller det WAN-värdobjekt som angriparen anropar. Translated destination är den icke-routade dummy-värden. Source- och service-översättning ligger i detta mönster normalt kvar på Original.

Efter sparandet bör man kontrollera i Log Viewer om den förväntade NAT Rule ID träffas. Om den normala DNAT-regeln fortfarande matchar står Black Hole-regeln för långt ner, source stämmer inte, eller så matchar den anropade tjänsten respektive destination inte testtrafiken.

Till Black-Hole-DNAT-regeln hör fortfarande en passande firewall-regel eller loggväg, så att träffen förblir spårbar. NAT översätter bara, det är ingen självständig åtkomsttillåtelse. Om ingen senare vet varför dummy-värden finns eller vilken källa som fångas upp blir tekniken snabbt ett arv.

Exempel:

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: Dålig IP-lista, land eller ländergrupp
• Original destination: Offentlig WAN-IP eller WAN-värdobjekt
• Original service: Any eller den publicerade tjänsten
• Translated source (SNAT): Original
• Translated destination (DNAT): Dummy-värd som inte existerar
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

Dummy-värden bör använda en IP-adress som inte finns i det egna nätverket och inte routas. Viktigt är att denna regel står ovanför de egentliga DNAT-reglerna. NAT-regler bearbetas uppifrån och ner. Om den vanliga DNAT-regeln matchar först, kommer Black Hole DNAT Rule för sent.

Dummy-värden bör inte väljas slumpmässigt. En adress från ett internt, oanvänt dokumentations- eller dummy-nät som inte routas och inte senare planeras för riktiga system är lämplig. Regeln bör tydligt beskriva varför denna värd existerar, så att den inte av misstag raderas eller används produktivt.

Varför ordningen är avgörande

Vid NAT-regler vinner den första matchande regeln. En Black Hole DNAT Rule måste därför stå mycket högt upp, oftast allra högst upp i NAT-regeltabellen.

Exempel på ordning:

1. Black Hole DNAT för dålig IP-lista och blockerade länder
2. Specifika DNAT-regler för publicerade tjänster
3. Speciella SNAT-regler
4. Allmän MASQ-regel för utgående trafik

För Firewall Rules gäller samma princip: specifika blockregler står ovanför allmänna tillåtregler. Annars kan det hända att trafiken redan har tillåtits innan drop-regeln prövas.

Källa inte onödigt kvar på Any

För publicerade tjänster bör man begränsa Source så mycket som möjligt.

Lämpliga källor kan vara:

• Enskilda offentliga IP-adresser
• Nät från partners eller filialer
• Länder från vilka åtkomst förväntas
• FQDN Hosts eller DNS Host Groups, om lämpligt
• Underhållna Host Groups med tillåtna admin-IP-adresser

Any är endast lämpligt om tjänsten verkligen måste vara tillgänglig över hela världen. Då bör man aktivera ytterligare skyddsåtgärder: loggning, IPS, MFA där det är möjligt, stark autentisering, aktuella målsystem och Threat Feeds.

IPv6 måste planeras separat. En IPv4-landsregel bevisar inte att samma applikation också är skyddad via IPv6. I dual-stack-miljöer krävs passande IPv6-regler, loggning och en testväg. Om IPv6 inte används produktivt bör det medvetet inaktiveras, blockeras eller införas dokumenterat.

Använd Threat Feeds dessutom

Manuella listor och länderregler är statiska. Angriparinfrastruktur förändras dock ständigt. Därför rekommenderar vi dessutom Sophos Firewall Threat Feeds.

Threat Feeds hjälper särskilt med:

• Kända skanner-IP-adresser
• Botnät
• Malware-infrastruktur
• Komprometterade värdar
• Dynamiskt underhållna dåliga IP-listor

Så behöver man inte underhålla varje enskild IP manuellt. Brandväggen kan blockera kända dåliga källor redan innan de når den publicerade tjänsten.

Test och drift

Efter ändringen bör räknare, loggar och förväntade åtkomstvägar kontrolleras medvetet.

Drift och granskning av blocklistor

Blocklistor är endast användbara om de förblir begripliga i drift. En länderregel eller dålig IP-lista bör därför inte bara växa permanent utan att någon granskar träffarna, undantagen och bieffekterna.

För varje manuell blocklista bör det dokumenteras:

• Varför källan blockerades
• Om det är en tillfällig eller permanent blockering
• Vem som underhåller listan
• När regeln ska granskas igen
• Vilka tjänster eller DNAT-regler som påverkas
• Hur ett falskt positivt godkänns

Särskilt med moln-, CDN-, hosting- eller supportnät bör man vara försiktig. En enskild IP-adress kan senare tillhöra en annan kund, ett CDN-område kan innehålla legitima tjänster, och en extern tjänsteleverantör kan ändra sin utgående IP. Om en legitim åtkomst blockeras bör inte hela regeln inaktiveras omedelbart. Bättre är ett snävt undantag med anledning, biljett och granskningsdatum.

För publicerade servrar bör man dessutom kontrollera om blocklistan verkligen träder i kraft före den produktiva DNAT-regeln. Driftkontrollen i Publicera server via DNAT på Sophos Firewall hjälper till att bedöma publicerade tjänster, NAT-regler och loggning tillsammans. Om blockerade källor går via en Firewall Rule är Testa Firewall-regel med Log Viewer, Policy Test och Packet Capture den lämpliga testvägen.

En meningsfull granskning består inte bara av en titt på regeln. Man bör i Log Viewer kontrollera om regeln fortfarande träffar, vilka källor som påverkas och om träffarna motsvarar den förväntade risken. För långsiktig utvärdering är Central Firewall Reporting eller Skicka Sophos Firewall Syslog till SIEM bättre än enbart lokala loggar.

Testförlopp efter ändringen

Efter en ny blockregel bör man inte bara kontrollera om den oönskade åtkomsten försvinner. Viktigt är också om önskad trafik fortfarande fungerar och om brandväggen loggar träffen begripligt.

Praktiskt förlopp:

1. Skapa regel med beskrivande namn, loggning och snäv beskrivning.
2. Om möjligt, testa först med en liten Source-lista eller ett enskilt land.
3. Kontrollera förväntad blockering från en lämplig extern källa.
4. Filtrera i Log Viewer efter Source, Destination, Service, Firewall Rule ID och NAT Rule ID.
5. Testa en legitim åtkomst från en tillåten källa.
6. För publicerade servrar, kontrollera om den produktiva DNAT-regeln fortfarande gäller för tillåtna källor.
7. Dokumentera granskningsdatum och ägare av regeln.

Om inget rent test från utsidan är möjligt bör ändringen åtminstone övervakas med Log Viewer, Packet Capture och ett snävt underhållsfönster. En blockregel utan synliga träffar och utan ägare är efter några månader knappast mer än en gammal rest.

Felsökning

Om det förväntade resultatet saknas kontrolleras logging, rule matching och policybeteende steg för steg.

Typiska fel

• Black Hole DNAT står under den vanliga DNAT-regeln: Den vanliga DNAT-regeln matchar först, blockregeln träder inte i kraft
• Dummy-mål existerar ändå i nätverket: Trafik hamnar oväntat på ett riktigt system
• Source underhålls olika i NAT och Firewall Rule: Regler blir svårbegripliga och driver isär
• Country Blocking används som enda skyddsåtgärd: Bots från tillåtna länder kan fortfarande attackera
• WAF och DNAT blandas ihop: En firewall-Drop-regel skyddar inte automatiskt varje WAF-publicering. Kontrollera WAF Blocked countries separat.
• Lokala brandväggstjänster skyddas med vanliga firewall-regler: För WebAdmin, User Portal, VPN Portal och SSH ska Device Access och Local Service ACL kontrolleras först.
• IPv6 glöms bort: En IPv4-regel blockerar ingen IPv6-väg.
• Tillfälliga IP-blockeringar granskas aldrig: Gamla poster blockerar senare legitima åtkomster eller skapar onödig komplexitet
• Moln- eller CDN-områden blockeras för brett: Affärsapplikationer, uppdateringar eller externa tjänsteleverantörer kan falla bort
• Loggning är inaktiverad: I Log Viewer är det inte klart vilken regel som träffade

Felsökning

Om en blockregel inte träder i kraft bör man kontrollera i denna ordning:

1. Står NAT- eller Firewall-regeln verkligen ovanför tillåtreglerna?
2. Matchar Source IP till den dåliga IP-listan eller det valda landet?
3. Bearbetas trafiken av en WAF-regel, DNAT-regel eller Firewall Rule?
4. Är loggning aktiv på den berörda Firewall Rule?
5. Visar Log Viewer den förväntade Firewall Rule ID eller NAT Rule ID?
6. Ser man trafiken i Diagnostics > Packet capture?
7. Finns det ett nyare undantag, Host Group eller Threat-Feed-Exclusion som påverkar den förväntade blockeringen?
8. Lämnades en tillfällig blockering efter en incident kvar permanent?

För analys hjälper också Firewall-regel träder inte i kraft: Kontrollera ordning, matchning och loggar, Använd Packet Capture Tool i WebAdmin och Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Om den blockerade trafiken egentligen tillhör en publicerad server bör dessutom den produktiva DNAT-regeln kontrolleras: Står Black-Hole-DNAT-regeln verkligen ovanför, träffas samma offentliga mål och är tjänsten identisk eller medvetet bredare vald? För den kompletta publiceringen passar Publicera server via DNAT på Sophos Firewall.

FAQ