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.

This article explains two typical methods:

• Blocking countries or source networks with a Firewall Rule
• Translating unwanted sources into a void using a Black Hole DNAT Rule

Additionally, we recommend Sophos Firewall Threat Feeds to automatically block known malicious IPs, domains, or URLs.

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: Redirects unwanted traffic to a non-existent internal IP. This is useful when traffic to published services should be intercepted early.
• 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 lists of known malicious sources. This fits botnets, scanners, malware infrastructure, and known attacker IP addresses.

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.

Blocking Countries with a Firewall Rule

For general country blocking, you can create a Firewall Rule with Drop.

Menu path:

Rules and policies > Firewall rules

Recommended fields:

• Rule name: Descriptive name, for example, BLOCK_COUNTRY_PANAMA
• Rule position: Top
• 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

For country blocking, it is important that source zones and destination zones are not set too narrowly. If you only enter WAN as the source zone, the rule may not apply to all relevant traffic paths.

Countries and country groups are used as objects under Hosts and services. For multiple countries, a Country host 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. The traffic thus runs into a void and does not reach the actual service.

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. The rule belongs in Rules and policies > NAT rules 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): Dummy host that does not exist
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

The dummy host should use an IP address that does not exist in your network and is not routed. It is important that this rule is above the actual DNAT rules. NAT rules are processed from top to bottom. 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 Additionally

Manual lists and country rules are static. However, attacker infrastructure changes continuously. Therefore, we also recommend Sophos Firewall Threat Feeds.

Threat Feeds are particularly helpful for:

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

This way, you do not have to maintain every single IP manually. The firewall can already block known bad sources before they reach the published service.

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.

If a clean test from outside is not possible, the change should at least be monitored with Log Viewer, Packet Capture, and a tight maintenance window. A block rule without visible hits and without an owner is hardly distinguishable from legacy after a few months.

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

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