Sophos Firewall: Blocking Countries and Malicious IPs

Once services are accessible from the internet, unwanted traffic often appears quickly: port scans, login attempts, known botnets, or access from countries where no users are expected. On the Sophos Firewall, such sources can be blocked on multiple levels.

The quick decision for SFOS 22 is: normally block countries with a Drop firewall rule, WAF publications with Blocked countries, and local firewall services with Device access or a Local Service ACL Exception Rule. For continuously changing malicious IPs, Sophos Firewall Threat Feeds are easier to maintain than manual host lists. A Black Hole DNAT Rule remains a targeted tool for published WAN destinations, particularly where a normal firewall rule does not evaluate WAF traffic to the Hosted address.

Since SFOS 22, Active Threat Response can also match the source IP of inbound DNAT and WAF traffic against MDR, NDR, and third-party threat feeds. Known scanners therefore no longer have to be maintained exclusively in static black-hole rules.

Orientation

Before blocking sources, it must be clear which traffic is meant: published services, local firewall services, outgoing client traffic, or WAF traffic. The right method depends exactly on that.

Which Method is Suitable When?

• Firewall Rule with Drop: Blocks traffic based on Source Country, Source Network, or Source Host. This fits country blocks, individual networks, or manually maintained bad-IP lists.
• Black Hole DNAT: Translates unwanted traffic to a nonexistent, unrouted dummy IP. This is useful when traffic to a specific published WAN destination must be intercepted before the production DNAT rule.
• WAF Blocked countries: Applies to web servers published through WAF. Countries are blocked directly in the WAF rule.
• Local service ACL exception rule: Controls local firewall services such as WebAdmin, User Portal, VPN Portal, or SSH. This is the right place when the firewall itself must be protected.
• Threat Feeds: Use dynamic IPv4, domain, or URL lists. In SFOS 22, IPv4 feeds can also identify source addresses in front of DNAT and WAF publications; evaluate new feeds with Monitor before changing them to Block.

The appropriate method depends on where the traffic is technically processed. Firewall rules do not always apply to traffic going to a Hosted Address used in WAF. In such cases, a WAF country rule or a Black Hole DNAT Rule is often more suitable.

Incoming, Outgoing, or Local Firewall

Before a block rule is set, it should be clear what type of traffic is meant. Otherwise, you might block at the wrong point and later wonder why the attack is still visible or why legitimate traffic fails.

• Incoming to published server: Port forwarding on RDP, HTTPS, SMTP, or custom application. DNAT order, WAF rule, Firewall Rule, IPS, and Logging
• Incoming to the firewall itself: WebAdmin, User Portal, VPN Portal, SSH, Ping, or DNS on the firewall. Device Access and Local Service ACL Exception Rules
• Outgoing from internal clients: Clients contacting suspicious targets on the internet. Firewall Rule, Threat Feeds, Web Protection, DNS Protection, and Logging
• Web server via WAF: Public web application behind Web Server Protection. WAF rule, Blocked countries, Authentication, MFA, and WAF logs

This separation is important because a country rule in Rules and policies > Firewall rules does not automatically secure every attack surface of the firewall. For published servers, the NAT and WAF chain is usually the focus. For admin portals, it first matters whether the local firewall service is accessible from the zone at all. For outgoing client traffic, Threat Feeds, Web Protection, and DNS Protection are often the cleaner tools.

Do Not Confuse with Device Access

Country Blocking and Black Hole DNAT primarily protect traffic processed by firewall or NAT rules. Local services of the Sophos Firewall are a different case. These include WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping, and partially also remote access services.

For these local services, Administration > Device access is initially relevant. There, you decide from which zones a service is generally accessible. If access should only be allowed for individual admin IP addresses, countries, or support sources, Local service ACL exception rules are the right control point. The procedure is described in Securing Sophos Firewall Access: Configuring Device Access Correctly.

⚠️ A country block rule does not replace a clean device access configuration. If WebAdmin, User Portal, VPN Portal, or SSH are too broadly accessible, the firewall itself remains an attack surface. Country Blocking can reduce the risk but cannot replace fundamental access hardening.

For particularly sensitive local services, WAN should not be enabled broadly under Local service ACL. A better approach is an exception rule that only allows expected sources or blocks unwanted countries. For WebAdmin, a fixed admin IP or management VPN is usually cleaner than a country filter because Geo-IP is not a real identity check.

Plan Block Rules

Block rules should be planned so that legitimate traffic is not interrupted unintentionally.

Create a Country Group cleanly

SFOS already includes Country Groups arranged by continent. For a custom operational selection, such as countries with no business relationship, create a group with a meaningful name under Hosts and services > Country group > Add. Select the required countries or regions and save it with Save. A country or region can be a member of several groups.

You can search the selection by the full name or the two-letter alpha-2 code. Individual regions missing from a default group can be added manually to a default or custom group. Before changing it later, refresh and review the Usage column because the same Country Group may be used in firewall rules, NAT, routing, or other policies.

Blocking Countries with a Firewall Rule

For general country blocking, create a Firewall Rule with Drop. SFOS evaluates rules from top to bottom and stops at the first match, so position is part of the security outcome.

Menu path:

Rules and policies > Firewall rules > IPv4 or IPv6 > Add firewall rule > New firewall rule

Recommended fields:

• Rule name: Descriptive name, for example, BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Rule group: None or a deliberately selected rule group
• Action: Drop
• Source zones: Any
• Source networks and devices: Country, country group, IP list, or host group
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any or a defined service
• Log firewall traffic: Enabled

For effective country blocking, Sophos requires Source zones: Any and Destination zones: Any in this rule pattern. You can still narrow the networks and services when protecting only a specific publication. IPv4 and IPv6 rules are created separately; configure and test both protocol views in a dual-stack environment.

Countries and country groups are used as objects under Hosts and services. For multiple countries, a Country group is clearer than many individual countries directly in each rule. Bad-IP lists belong in suitable IP host or IP host group objects. The limits matter: IP host lists are not meant for arbitrarily large dynamic feeds. For constantly changing attacker infrastructure, Threat Feeds are easier to maintain.

Country blocking should also be understood as a best-effort control. Geo-IP data can be incorrect, users travel, attackers use proxies or compromised systems in allowed countries, and cloud services use globally distributed infrastructure. Therefore, a country rule should never be the only protective measure.

When Not to Block Too Broadly

A block rule is quickly created but can later produce hard-to-trace side effects. You should be particularly cautious if productive applications depend on external platforms, CDNs, payment providers, cloud services, monitoring providers, or support partners.

Before a broad country or IP block, you should clarify:

• Are there users, partners, or service providers in the affected countries?
• Does an application use cloud or CDN infrastructure with changing source addresses?
• Are updates, webhooks, monitoring, backups, or support accesses triggered via external services?
• Is there a way to log first or test the rule for a limited time?
• Is it clear who checks false positives and how an exception is granted?

For internet services with real user authentication, country rules are often just an additional measure. MFA, tight firewall rules, up-to-date target systems, IPS, WAF protection, logging, and Threat Feeds remain more important than the longest possible block list.

Plan Allowlist Before Blocklist

For critical services, an allowlist is often cleaner than an ever-growing blocklist. If a service only needs to be accessible from fixed partners, branches, monitoring systems, or admin locations, you should first allow these sources and block the rest. This reduces maintenance effort and prevents you from reactively blocking each new scanner IP individually.

An allowlist is particularly suitable for:

• Admin access to published management services
• B2B interfaces with known partner IP addresses
• Monitoring, backup, webhooks, or API endpoints with fixed source systems
• Temporary support access with ticket, expiration date, and review

A blocklist is more suitable when a service needs to remain publicly accessible, but noticeable sources should be reduced. The rule should then be operated with logging, review date, and clear exceptions. For web servers published via WAF, Sophos Firewall WAF: Securely Publishing Web Servers is also relevant, as countries, authentication, and web server protection are controlled closer to the published application.

Treat WAF Country Filters Separately

In Web Server Protection, the WAF rule has its own fields for Allowed client networks, Blocked client networks, Blocked countries, and Block IP addresses of unknown country-origin. These settings belong to the published web application and are not the same as a normal firewall drop rule.

This is useful because the country filter is attached directly to the WAF publication. At the same time, caution is needed: Block IP addresses of unknown country-origin can exclude legitimate users if their IP address cannot be assigned clearly. Before enabling it, check the own external IP address with the GeoIP2 Databases Demo. Only enable this option when the effect has been tested and support knows about it.

For WAF rules, country filters are only one building block. Authentication, MFA, certificate, Web Server Protection, IPS/WAF signatures, logging, and an up-to-date backend server remain more important than a long list of blocked countries.

Black Hole DNAT and Threat Feeds

For published services, it can be useful to intercept unwanted sources before the productive DNAT rule. For dynamic attacker infrastructure, Threat Feeds are also helpful.

Black Hole DNAT for Unwanted Sources

A Black Hole DNAT Rule translates traffic to a target that does not exist in the network. Together with the firewall policy, this keeps the traffic from reaching the actual service: NAT translates addresses but does not independently allow or drop access.

This is particularly useful when a service is published via DNAT and you want to intercept certain sources before the actual port forwarding.

Black Hole DNAT should be used selectively. It is especially suitable for traffic to published services where a normal DNAT rule lies beneath. For general outgoing client traffic, local firewall services, or web servers published via WAF, a Firewall Rule, Device Access, or a WAF setting is usually the better control point.

In the NAT rule, it is important not to confuse the attacker’s original view with the translated dummy destination. Create the rule under Rules and policies > NAT rules > Add NAT rule > New NAT rule, above the production DNAT rule. Original source contains the blocked IP list, country, or country group. Original destination is the public WAN address or WAN host object that the attacker is targeting. Translated destination is the non-routed dummy host. Source and service translation usually remain set to Original in this pattern.

After saving, check in the Log Viewer whether the expected NAT Rule ID is hit. If the normal DNAT rule still matches, the Black Hole rule is too low, the source does not match, or the addressed service or destination does not match the test traffic.

The Black Hole DNAT rule still needs a matching firewall rule or log path so the hit remains traceable. NAT only translates; it is not an access permission by itself. If nobody later knows why the dummy host exists or which source is intercepted, this technique quickly becomes legacy clutter.

Example:

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: Bad IP list, country, or country group
• Original destination: Public WAN IP or WAN host object
• Original service: Any or the published service
• Translated source (SNAT): Original
• Translated destination (DNAT): For example, IP host BLACKHOLE-192.0.2.254 with 192.0.2.254, provided this documentation address is neither used nor routed internally
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

The example value 192.0.2.254 comes from the TEST-NET-1 documentation network. Replace it with a demonstrably unused, unrouted address if that network is already used internally. The rule must remain above the actual DNAT rules. If the normal DNAT rule matches first, the Black Hole DNAT Rule comes too late.

The dummy host should not be chosen randomly. A sensible choice is an address from an internal, unused documentation or dummy network that is not routed and not planned for real systems later. The rule should clearly describe why this host exists so that it is not accidentally deleted or used productively.

Why Order is Crucial

With NAT rules, the first matching rule wins. Therefore, a Black Hole DNAT Rule must be very high up, usually at the top of the NAT rule table.

Example order:

1. Black Hole DNAT for bad IP list and blocked countries
2. Specific DNAT rules for published services
3. Special SNAT rules
4. General MASQ rule for outgoing traffic

The same principle applies to Firewall Rules: specific block rules are above general allow rules. Otherwise, it can happen that the traffic is already allowed before the drop rule is checked.

Do Not Leave Source Unnecessarily on Any

For published services, you should restrict the source as much as possible.

Sensible sources can be:

• Individual public IP addresses
• Networks of partners or branches
• Countries from which access is expected
• FQDN hosts or DNS host groups, if appropriate
• Maintained host groups with allowed admin IP addresses

Any is only sensible if the service really needs to be accessible worldwide. Then you should activate additional protective measures: logging, IPS, MFA where possible, strong authentication, up-to-date target systems, and Threat Feeds.

IPv6 must be planned separately. An IPv4 country rule does not prove that the same application is also protected over IPv6. In dual-stack environments, matching IPv6 rules, logging, and a test path are required. If IPv6 is not used productively, it should be deliberately disabled, blocked, or introduced with documentation.

Use Threat Feeds in SFOS 22 as Well

Manual lists and country rules are static, while attacker infrastructure changes continuously. We therefore also recommend Sophos Firewall Threat Feeds. That guide covers licensing, feed format, certificate validation, polling, false positives, and Threat Exclusions end to end.

Threat Feeds are particularly helpful for:

• Known scanner IP addresses
• Botnets
• Malware infrastructure
• Compromised hosts
• Dynamically maintained bad IP lists

This removes the need to maintain every individual IP manually. A technically suitable example is the IPv4, domain, and URL Threat Feeds available from cybora.io; like any provider, it must first be assessed for freshness, useful matches, and false positives in your own network.

For inbound published services, the SFOS 22 difference matters: Active Threat Response can match remote source IP addresses in forwarded DNAT and WAF traffic. Also enable Remote source match (inbound traffic) under System services > Log settings > Active threat response. This option is off by default and is required for these inbound events to appear in the Active Threat Response log. Start a new third-party feed with Action: Monitor. Change it to Block only after checking Sync status, indicator count, representative matches, and possible false positives.

Testing and Operation

After the change, counters, logs and expected access paths should be checked deliberately.

Operation and Review of Blocklists

Blocklists are only helpful if they remain comprehensible in operation. Therefore, a country rule or bad IP list should not just grow indefinitely without someone checking the hits, exceptions, and side effects.

For each manual blocklist, it should be documented:

• Why the source was blocked
• Whether it is a temporary or permanent block
• Who maintains the list
• When the rule will be reviewed again
• Which services or DNAT rules are affected
• How a false positive is released

You should be cautious, especially with cloud, CDN, hosting, or support networks. A single IP address can later belong to another customer, a CDN range can contain legitimate services, and an external service provider can change its outgoing IP. If legitimate access is blocked, the entire rule should not be immediately disabled. A better approach is a narrow exception with reason, ticket, and review date.

For published servers, you should also check whether the blocklist really takes effect before the productive DNAT rule. The operational check in Publishing Servers via DNAT on Sophos Firewall helps to evaluate published services, NAT rules, and logging together. If blocked sources run through a firewall rule, Testing Firewall Rules with Log Viewer, Policy Test, and Packet Capture is the appropriate test path.

A meaningful review consists not only of a glance at the rule. You should check in the Log Viewer whether the rule still hits, which sources are affected, and whether the hits match the expected risk. For longer-term evaluation, Central Firewall Reporting or Sending Sophos Firewall Syslog to SIEM are better than local logs alone.

Test Procedure After the Change

After a new block rule, you should not only check whether the unwanted access disappears. It is also important to check whether desired traffic continues to function and whether the firewall logs the hit comprehensibly.

Practical procedure:

1. Create a rule with a descriptive name, logging, and a clear description.
2. If possible, test first with a small source list or a single country.
3. Check the expected block from a suitable external source.
4. Filter in the Log Viewer by source, destination, service, firewall rule ID, and NAT rule ID.
5. Test a legitimate access from an allowed source.
6. For published servers, check whether the productive DNAT rule still applies to allowed sources.
7. Document the review date and owner of the rule.

For a firewall drop rule, the test hit must show the expected Firewall Rule ID and a dropped action. For Black Hole DNAT, also verify the NAT Rule ID and translated destination. Always establish a new connection after changing a NAT rule: established connections are not reevaluated against the updated NAT configuration.

If a clean test from outside is not possible, monitor the change at least with Log Viewer, Diagnostics > Packet capture, and a tight maintenance window. Packet Capture shows NAT ID, Rule ID, Status, and Reason, helping distinguish whether a packet arrived, was forwarded, or was dropped. A block rule without visible hits and without an owner is hardly distinguishable from legacy after a few months.

Safe Rollback

• Firewall Rule: Disable it or restore its previous position, then retest allowed and blocked traffic.
• Black Hole DNAT: Disable it or restore the previous order and establish a new test connection. Delete the dummy host only when Usage shows no other references.
• WAF country filter: Remove the countries just added or turn off Block IP addresses of unknown country-origin, then test the published application from a legitimate source.
• Third-party Threat Feed: Change Action from Block back to Monitor. A global Threat Exclusion is not an equivalent rollback because it affects other Active Threat Response modules as well.

Troubleshooting

If the expected result is missing, work through logging, rule matching and policy behaviour step by step.

Typical Mistakes

• Black Hole DNAT is below the normal DNAT rule: The normal DNAT rule matches first, the block rule does not apply
• Dummy target does exist in the network: Traffic unexpectedly lands on a real system
• Source is maintained differently in NAT and Firewall Rule: Rules become hard to trace and drift apart
• Country Blocking is used as the only protective measure: Bots from allowed countries can still attack
• WAF and DNAT are mixed up: A firewall drop rule does not automatically protect every WAF publication. Check WAF Blocked countries separately.
• Local firewall services are protected with normal firewall rules: For WebAdmin, User Portal, VPN Portal, and SSH, first check Device Access and Local Service ACL.
• IPv6 is forgotten: An IPv4 rule does not block an IPv6 path.
• Temporary IP blocks are never reviewed: Old entries later block legitimate access or create unnecessary complexity
• Cloud or CDN ranges are blocked too broadly: Business applications, updates, or external service providers may fail
• Logging is disabled: It is not clear in the Log Viewer which rule applied
• Remote source match is missing: The feed can handle inbound DNAT or WAF traffic, but the expected event is absent from the Active Threat Response log
• An existing connection is reused: NAT rule changes only apply to new connections

Troubleshooting

If a block rule does not apply, you should check in this order:

1. Is the NAT or Firewall Rule really above the allow rules?
2. Does the source IP match the bad IP list or the chosen country?
3. Is the traffic processed by a WAF rule, DNAT rule, or Firewall Rule?
4. Is logging active on the affected Firewall Rule?
5. Does the Log Viewer show the expected Firewall Rule ID or NAT Rule ID?
6. Can you see the traffic in Diagnostics > Packet capture?
7. Is there a newer exception, host group, or threat feed exclusion that affects the expected block?
8. Was a temporary block left standing permanently after an incident?

For analysis, Firewall Rule Not Matching: Check Order, Matching, and Logs, Using the Packet Capture Tool in WebAdmin, and Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT are helpful.

If the blocked traffic actually belongs to a published server, you should additionally check the productive DNAT rule: Is the Black Hole DNAT rule really above it, is the same public destination address hit, and is the service identical or deliberately chosen more broadly? For the complete publication, Publishing Servers via DNAT on Sophos Firewall is suitable.

FAQ