Sophos Firewall: Landen en kwaadaardige IP's blokkeren

Zodra diensten vanaf het internet bereikbaar zijn, zie je vaak snel ongewenst verkeer: poortscans, inlogpogingen, bekende botnets of toegang vanuit landen waaruit geen gebruikers worden verwacht. Op de Sophos Firewall kun je dergelijke bronnen op meerdere niveaus blokkeren.

Dit artikel legt twee typische varianten uit:

• Landen of bronnetwerken blokkeren met een Firewall Rule
• ongewenste bronnen met een Black Hole DNAT Rule naar het niets vertalen

Daarnaast raden we Sophos Firewall Threat Feeds aan, zodat bekende kwaadaardige IP’s, domeinen of URL’s automatisch kunnen worden geblokkeerd.

Oriëntatie

Voordat bronnen worden geblokkeerd, moet duidelijk zijn welk verkeer bedoeld is: gepubliceerde diensten, lokale firewall-diensten, uitgaand clientverkeer of WAF-verkeer. De juiste methode hangt precies daarvan af.

Welke methode past wanneer?

• Firewall Rule met Drop: Blokkeert verkeer op basis van Source Country, Source Network of Source Host. Dit past voor landenblokkades, individuele netwerken of handmatig onderhouden slechte IP-lijsten.
• Black Hole DNAT: Leidt ongewenst verkeer om naar een niet-bestaand intern IP-adres. Dit is nuttig wanneer verkeer naar gepubliceerde diensten vroeg moet worden onderschept.
• WAF Blocked countries: Geldt voor webservers die via WAF worden gepubliceerd. Landen worden direct in de WAF-regel geblokkeerd.
• Local service ACL exception rule: Stuurt lokale firewall-diensten zoals WebAdmin, User Portal, VPN Portal of SSH. Dit is de juiste plek wanneer de firewall zelf beschermd moet worden.
• Threat Feeds: Gebruiken dynamische lijsten van bekende kwaadaardige bronnen. Dit past voor botnets, scanners, malware-infrastructuur en bekende aanvallers-IP-adressen.

Welke methode zinvol is, hangt af van waar het verkeer technisch wordt verwerkt. Firewall-regels grijpen niet in elk geval voor verkeer dat naar een in WAF gebruikte Hosted Address gaat. In dergelijke gevallen is een WAF-landenregel of een Black Hole DNAT Rule vaak beter geschikt.

Inkomend, uitgaand of lokale firewall

Voor een blokkeerregel moet duidelijk zijn welk type verkeer bedoeld wordt. Anders blokkeer je op de verkeerde plek en vraag je je later af waarom de aanval nog steeds zichtbaar is of waarom legitiem verkeer uitvalt.

• Inkomend naar gepubliceerde server: Poortdoorschakeling naar RDP, HTTPS, SMTP of eigen applicatie. DNAT-volgorde, WAF-regel, Firewall Rule, IPS en logging
• Inkomend naar de firewall zelf: WebAdmin, User Portal, VPN Portal, SSH, Ping of DNS op de firewall. Device Access en Local Service ACL Exception Rules
• Uitgaand van interne clients: Clients spreken verdachte doelen op internet aan. Firewall Rule, Threat Feeds, Web Protection, DNS Protection en logging
• Webserver via WAF: openbare webapplicatie achter Web Server Protection. WAF-regel, Blocked countries, authenticatie, MFA en WAF-logs

Deze scheiding is belangrijk omdat een landenregel in Rules and policies > Firewall rules niet automatisch elk aanvalsvlak van de firewall beveiligt. Voor gepubliceerde servers staat meestal de NAT- en WAF-keten op de voorgrond. Voor admin-portalen telt eerst of de lokale firewall-dienst überhaupt vanuit de zone bereikbaar is. Voor uitgaand clientverkeer zijn Threat Feeds, Web Protection en DNS Protection vaak de schonere hulpmiddelen.

Niet verwarren met Device Access

Country Blocking en Black Hole DNAT beschermen in de eerste plaats verkeer dat door firewall- of NAT-regels wordt verwerkt. Lokale diensten van de Sophos Firewall zijn een ander geval. Daartoe behoren bijvoorbeeld WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping en deels ook Remote-Access-diensten.

Voor deze lokale diensten is eerst Administration > Device access relevant. Daar bepaal je vanuit welke zones een dienst in principe bereikbaar is. Als toegang alleen voor individuele admin-IP-adressen, landen of supportbronnen toegestaan moet worden, zijn Local service ACL exception rules het juiste controlepunt. De procedure staat in Sophos Firewall toegang beveiligen: Device Access correct configureren.

⚠️ Een Country-Block-regel vervangt geen correcte Device-Access-configuratie. Als WebAdmin, User Portal, VPN Portal of SSH te breed bereikbaar zijn, blijft de firewall zelf een aanvalsvlak. Country Blocking kan het risico verminderen, maar niet de fundamentele toegangshardening vervangen.

Voor bijzonder gevoelige lokale diensten moet WAN onder Local service ACL niet breed worden ingeschakeld. Beter is een exception rule die alleen de verwachte bronnen toestaat of ongewenste landen blokkeert. Voor WebAdmin is een vast admin-IP of management-VPN meestal schoner dan een landenfilter, omdat Geo-IP geen echte identiteitscontrole is.

Blokkeerregels plannen

Blokkeerregels moeten zo worden gepland dat legitiem verkeer niet onbedoeld wordt onderbroken.

Landen blokkeren met een Firewall Rule

Voor algemeen Country Blocking kun je een Firewall Rule met Drop maken.

Menupad:

Rules and policies > Firewall rules

Aanbevolen velden:

• Rule name: duidelijke naam, bijvoorbeeld BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Action: Drop
• Source zones: Any
• Source networks and devices: Land, landengroep, IP-lijst of hostgroep
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any of een gedefinieerde service

Voor Country Blocking is het belangrijk dat Source zones en Destination zones niet te nauw worden ingesteld. Als je alleen WAN als Source zone invoert, werkt de regel mogelijk niet voor alle relevante verkeerspaden.

Landen en landengroepen worden als objecten onder Hosts and services gebruikt. Voor meerdere landen is een Country host group overzichtelijker dan veel losse landen direct in elke regel. Slechte IP-lijsten horen in passende IP host- of IP host group-objecten. De grenzen zijn belangrijk: IP host-lijsten zijn niet bedoeld voor willekeurig grote dynamische feeds. Voor voortdurend wisselende aanvaller-infrastructuur zijn Threat Feeds beter te onderhouden.

Country Blocking moet ook als Best-Effort-controle worden begrepen. Geo-IP-gegevens kunnen onjuist zijn, gebruikers reizen, aanvallers gebruiken proxy’s of gecompromitteerde systemen in toegestane landen, en clouddiensten gebruiken wereldwijd verspreide infrastructuur. Daarom mag een landenregel nooit de enige beschermingsmaatregel zijn.

Wanneer je niet te breed moet blokkeren

Een blokkeerregel is snel gemaakt, maar kan later moeilijk te begrijpen neveneffecten veroorzaken. Vooral voorzichtig moet je zijn als productieve applicaties afhankelijk zijn van externe platforms, CDN’s, betalingsproviders, clouddiensten, monitoringproviders of supportpartners.

Voor een brede landen- of IP-blokkering moet je daarom verduidelijken:

• Zijn er gebruikers, partners of dienstverleners in de getroffen landen?
• Gebruikt een applicatie cloud- of CDN-infrastructuur met wisselende bronadressen?
• Worden updates, webhooks, monitoring, back-ups of supporttoegang via externe diensten geactiveerd?
• Is er een mogelijkheid om eerst alleen te loggen of de regel tijdelijk te testen?
• Is het duidelijk wie valse positieven controleert en hoe een uitzondering wordt vrijgegeven?

Voor internetdiensten met echte gebruikersaanmelding zijn landenregels vaak slechts een aanvullende maatregel. MFA, strikte firewallregels, actuele doelsystemen, IPS, WAF-bescherming, logging en Threat Feeds blijven belangrijker dan een zo lang mogelijke blokkadelijst.

Allowlist voor Blocklist plannen

Bij kritieke diensten is een Allowlist vaak schoner dan een steeds langere Blocklist. Als een dienst alleen bereikbaar moet zijn vanuit vaste partners, filialen, monitoringsystemen of admin-locaties, moet je eerst deze bronnen toestaan en de rest blokkeren. Dit vermindert het onderhoud en voorkomt dat je reactief elke nieuwe scanner-IP afzonderlijk moet blokkeren.

Een Allowlist past bijzonder goed voor:

• Admin-toegang tot gepubliceerde managementdiensten
• B2B-interfaces met bekende partner-IP-adressen
• Monitoring, back-up, webhooks of API-eindpunten met vaste bronsystemen
• Tijdelijke supporttoegang met ticket, vervaldatum en beoordeling

Een Blocklist past eerder als een dienst bewust openbaar bereikbaar moet blijven, maar opvallende bronnen moeten worden verminderd. Dan moet de regel met logging, beoordelingsdatum en duidelijke uitzonderingen worden beheerd. Voor webservers die via WAF worden gepubliceerd, is daarnaast Sophos Firewall WAF: Webserver veilig publiceren relevant, omdat daar landen, authenticatie en webserverbescherming dichter bij de gepubliceerde applicatie worden beheerd.

WAF-landenfilters apart behandelen

Bij Web Server Protection heeft de WAF-regel eigen velden voor Allowed client networks, Blocked client networks, Blocked countries en Block IP addresses of unknown country-origin. Deze instellingen horen bij de gepubliceerde webapplicatie en zijn niet hetzelfde als een normale firewall-Drop-regel.

Dat is praktisch, omdat het landenfilter direct aan de WAF-publicatie hangt. Tegelijk is voorzichtigheid nodig: Block IP addresses of unknown country-origin kan legitieme gebruikers uitsluiten als hun IP-adres niet duidelijk kan worden toegewezen. Controleer voor activering het eigen externe IP-adres met de GeoIP2 Databases Demo. Activeer deze optie alleen wanneer het effect is getest en bekend is in het supportproces.

Voor WAF-regels zijn landenfilters slechts een bouwsteen. Authenticatie, MFA, certificaat, Web Server Protection, IPS/WAF-signatures, logging en een actuele backendserver blijven belangrijker dan een lange lijst geblokkeerde landen.

Black Hole DNAT en Threat Feeds

Bij gepubliceerde diensten kan het zinvol zijn om ongewenste bronnen al vóór de productieve DNAT-regel af te vangen. Voor dynamische aanvaller-infrastructuur zijn daarnaast Threat Feeds nuttig.

Black Hole DNAT voor ongewenste bronnen

Een Black Hole DNAT Rule vertaalt verkeer naar een doel dat niet in het netwerk bestaat. Het verkeer loopt daarmee in het niets en bereikt de eigenlijke dienst niet.

Dit is vooral nuttig als een dienst via DNAT wordt gepubliceerd en je bepaalde bronnen voor de eigenlijke poortdoorschakeling wilt onderscheppen.

Black Hole DNAT moet gericht worden ingezet. Het is vooral geschikt voor verkeer naar gepubliceerde diensten, waarbij een normale DNAT-regel eronder ligt. Voor algemeen uitgaand clientverkeer, lokale firewall-diensten of webservers die via WAF worden gepubliceerd, is meestal een Firewall Rule, Device Access of een WAF-instelling het betere controlepunt.

In de NAT-regel is het belangrijk om het oorspronkelijke perspectief van de aanvaller niet te verwarren met de vertaalde dummy-bestemming. De regel hoort in Rules and policies > NAT rules boven de productie-DNAT-regel te staan. Original source bevat de geblokkeerde IP-lijst, het land of de landengroep. Original destination is het publieke WAN-adres of het WAN-hostobject dat de aanvaller aanspreekt. Translated destination is de niet-gerouteerde dummy-host. Source- en service-translation blijven in dit patroon normaal gesproken op Original.

Na het opslaan moet in de Log Viewer worden gecontroleerd of de verwachte NAT Rule ID wordt geraakt. Als de normale DNAT-regel nog steeds matcht, staat de Black Hole-regel te laag, past de source niet, of komen de aangesproken service of destination niet overeen met het testverkeer.

Bij de Black-Hole-DNAT-regel hoort nog steeds een passende firewallregel of logpad, zodat de hit traceerbaar blijft. NAT vertaalt alleen, het is geen zelfstandige toegangsautorisatie. Als later niemand meer weet waarom de dummy-host bestaat of welke bron wordt afgevangen, wordt deze techniek snel een erfenis.

Voorbeeld:

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: Slechte IP-lijst, land of landengroep
• Original destination: openbare WAN-IP of WAN-hostobject
• Original service: Any of de gepubliceerde service
• Translated source (SNAT): Original
• Translated destination (DNAT): Dummy-host die niet bestaat
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

De dummy-host moet een IP-adres gebruiken dat niet in je eigen netwerk bestaat en niet wordt gerouteerd. Belangrijk is dat deze regel boven de eigenlijke DNAT-regels staat. NAT-regels worden van boven naar beneden verwerkt. Als eerst de normale DNAT-regel matcht, komt de Black Hole DNAT Rule te laat.

De dummy-host moet niet willekeurig worden gekozen. Een adres uit een intern, niet-gebruikt documentatie- of dummy-netwerk dat niet wordt gerouteerd en niet later voor echte systemen is gepland, is zinvol. De regel moet duidelijk beschrijven waarom deze host bestaat, zodat hij niet per ongeluk wordt verwijderd of productief wordt gebruikt.

Waarom de volgorde cruciaal is

Bij NAT-regels wint de eerste passende regel. Een Black Hole DNAT Rule moet daarom heel hoog staan, meestal helemaal bovenaan in de NAT-regeltabel.

Voorbeeldvolgorde:

1. Black Hole DNAT voor slechte IP-lijst en geblokkeerde landen
2. specifieke DNAT-regels voor gepubliceerde diensten
3. speciale SNAT-regels
4. algemene MASQ-regel voor uitgaand verkeer

Bij Firewall Rules geldt hetzelfde principe: specifieke blokkeerregels staan boven algemene toestaan-regels. Anders kan het gebeuren dat het verkeer al is toegestaan voordat de Drop-regel wordt gecontroleerd.

Bron niet onnodig op Any laten

Bij gepubliceerde diensten moet je de Source zo veel mogelijk beperken.

Zinvolle bronnen kunnen zijn:

• individuele openbare IP-adressen
• netwerken van partners of filialen
• landen waarvan toegang wordt verwacht
• FQDN-hosts of DNS-hostgroepen, indien passend
• onderhouden hostgroepen met toegestane admin-IP-adressen

Any is alleen zinvol als de dienst echt wereldwijd bereikbaar moet zijn. Dan moet je aanvullende beschermingsmaatregelen activeren: logging, IPS, MFA waar mogelijk, sterke authenticatie, actuele doelsystemen en Threat Feeds.

IPv6 moet apart worden gepland. Een IPv4-landenregel bewijst niet dat dezelfde applicatie ook via IPv6 beschermd is. In dual-stack-omgevingen zijn passende IPv6-regels, logging en een testpad nodig. Als IPv6 niet productief wordt gebruikt, moet het bewust worden uitgeschakeld, geblokkeerd of gedocumenteerd ingevoerd.

Threat Feeds aanvullend gebruiken

Handmatige lijsten en landenregels zijn statisch. Aanvallersinfrastructuur verandert echter voortdurend. Daarom raden we aanvullend Sophos Firewall Threat Feeds aan.

Threat Feeds helpen vooral bij:

• bekende scanner-IP-adressen
• botnets
• malware-infrastructuur
• gecompromitteerde hosts
• dynamisch onderhouden slechte IP-lijsten

Zo hoef je niet elke afzonderlijke IP handmatig bij te houden. De firewall kan bekende slechte bronnen al blokkeren voordat ze de gepubliceerde dienst bereiken.

Testen en beheer

Controleer na de wijziging bewust counters, logs en verwachte toegangspaden.

Beheer en beoordeling van blokkeerlijsten

Blokkeerlijsten zijn alleen nuttig als ze in gebruik begrijpelijk blijven. Een landenregel of slechte IP-lijst mag daarom niet zomaar permanent groeien zonder dat iemand de treffers, uitzonderingen en neveneffecten controleert.

Voor elke handmatige blokkeerlijst moet worden gedocumenteerd:

• waarom de bron is geblokkeerd
• of het een tijdelijke of permanente blokkering betreft
• wie de lijst onderhoudt
• wanneer de regel opnieuw wordt beoordeeld
• welke diensten of DNAT-regels zijn getroffen
• hoe een vals positief wordt vrijgegeven

Vooral bij cloud-, CDN-, hosting- of supportnetwerken moet je voorzichtig zijn. Een enkel IP-adres kan later aan een andere klant toebehoren, een CDN-range kan legitieme diensten bevatten, en een externe dienstverlener kan zijn uitgaande IP wijzigen. Als een legitieme toegang wordt geblokkeerd, moet niet meteen de hele regel worden uitgeschakeld. Beter is een nauwe uitzondering met reden, ticket en beoordelingsdatum.

Voor gepubliceerde servers moet je bovendien controleren of de blokkeerlijst echt voor de productieve DNAT-regel geldt. De operationele controle in Server per DNAT op Sophos Firewall publiceren helpt om gepubliceerde diensten, NAT-regels en logging gezamenlijk te beoordelen. Als geblokkeerde bronnen via een Firewall-regel lopen, is Firewall-regel testen met Log Viewer, Policy Test en Packet Capture het juiste testpad.

Een zinvolle beoordeling bestaat niet alleen uit een blik op de regel. Je moet in de Log Viewer controleren of de regel überhaupt nog treft, welke bronnen zijn getroffen en of de treffers bij het verwachte risico passen. Voor langdurige evaluatie zijn Central Firewall Reporting of Sophos Firewall Syslog naar SIEM sturen beter dan alleen lokale logs.

Testprocedure na de wijziging

Na een nieuwe blokkeerregel moet niet alleen worden gecontroleerd of de ongewenste toegang verdwijnt. Belangrijk is ook of gewenst verkeer nog steeds functioneert en of de firewall de treffer begrijpelijk logt.

Praktische procedure:

1. Regel met duidelijke naam, logging en nauwe beschrijving maken.
2. Indien mogelijk eerst testen met een kleine bronlijst of een enkel land.
3. Verwachte blokkering vanuit een passende externe bron controleren.
4. In de Log Viewer filteren op Source, Destination, Service, Firewall Rule ID en NAT Rule ID.
5. Een legitieme toegang vanuit een toegestane bron testen.
6. Bij gepubliceerde servers controleren of de productieve DNAT-regel nog steeds voor toegestane bronnen geldt.
7. Beoordelingsdatum en eigenaar van de regel documenteren.

Als een schone test van buitenaf niet mogelijk is, moet de wijziging ten minste met Log Viewer, Packet Capture en een nauw onderhoudsvenster worden bewaakt. Een blokkeerregel zonder zichtbare treffers en zonder eigenaar is na enkele maanden nauwelijks nog van een oude last te onderscheiden.

Troubleshooting

Als het verwachte resultaat ontbreekt, controleer dan stap voor stap logging, rule matching en policygedrag.

Typische fouten

• Black Hole DNAT staat onder de normale DNAT-regel: De normale DNAT-regel matcht eerst, de blokkeerregel grijpt niet
• Dummy-doel bestaat toch in het netwerk: Verkeer komt onverwacht op een echt systeem terecht
• Source wordt in NAT en Firewall Rule verschillend onderhouden: Regels worden moeilijk te begrijpen en drijven uit elkaar
• Country Blocking wordt als enige beschermingsmaatregel gebruikt: Bots uit toegestane landen kunnen nog steeds aanvallen
• WAF en DNAT worden door elkaar gehaald: Een firewall-Drop-regel beschermt niet automatisch elke WAF-publicatie. Controleer WAF Blocked countries apart.
• Lokale firewall-diensten worden met normale firewallregels beschermd: Controleer voor WebAdmin, User Portal, VPN Portal en SSH eerst Device Access en Local Service ACL.
• IPv6 wordt vergeten: Een IPv4-regel blokkeert geen IPv6-pad.
• Tijdelijke IP-blokkeringen worden nooit gecontroleerd: Oude vermeldingen blokkeren later legitieme toegang of veroorzaken onnodige complexiteit
• Cloud- of CDN-ranges worden te breed geblokkeerd: Bedrijfsapplicaties, updates of externe dienstverleners kunnen uitvallen
• Logging is uitgeschakeld: In de Log Viewer is niet duidelijk welke regel heeft gegrepen

Problemen oplossen

Als een blokkeerregel niet grijpt, moet je in deze volgorde controleren:

1. Staat de NAT- of Firewall-regel echt boven de toestaan-regels?
2. Matcht de Source IP met de slechte IP-lijst of het gekozen land?
3. Wordt het verkeer verwerkt door een WAF-regel, DNAT-regel of Firewall-regel?
4. Is logging op de getroffen Firewall-regel actief?
5. Toont de Log Viewer de verwachte Firewall Rule ID of NAT Rule ID?
6. Zie je het verkeer in Diagnostics > Packet capture?
7. Is er een nieuwere uitzondering, hostgroep of Threat-Feed-uitsluiting die de verwachte blokkering beïnvloedt?
8. Is een tijdelijke blokkering na een incident permanent blijven staan?

Voor de analyse helpen ook Firewall-regel grijpt niet: volgorde, matching en logs controleren, Packet Capture Tool in WebAdmin gebruiken en NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ, PAT.

Als het geblokkeerde verkeer eigenlijk naar een gepubliceerde server behoort, moet je bovendien de productieve DNAT-regel controleren: Staat de Black-Hole-DNAT-regel echt daarboven, wordt hetzelfde openbare doeladres geraakt en is de service identiek of bewust breder gekozen? Voor de volledige publicatie past Server per DNAT op Sophos Firewall publiceren.

FAQ