Set up and safely operate Sophos Firewall Threat Feeds

Sophos Firewall Threat Feeds automatically import known malicious IP addresses, domains, and URLs as Indicators of Compromise (IoCs). For a safe rollout, first observe the feed in Monitor mode, check hits and side effects, and only then switch to Block.

This article focuses primarily on Third-Party Threat Feeds, such as the feeds from Cybora. The feature was introduced with Sophos Firewall v21.

Set up a Threat Feed

Third-Party Threat Feeds require the Xstream Protection Bundle, but no additional Sophos Central licence. The firewall must be able to reach the feed URL over DNS and HTTPS.

1. Open System services > Log settings.
2. Under Active threat response, enable at least one supported log destination. For the local Log Viewer, this is Local reporting. XGS 87/87w and 107/107w do not support local reporting; use Sophos Central or a syslog server on these models.
3. To see hits on incoming DNAT and WAF traffic, also enable Remote source match (inbound traffic). This option is disabled by default.
4. Open Protect > Active threat response > Third-party threat feeds > Add.
5. Enter a unique name and description, for example:
   • Pilot: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Reviewed production feed: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. For Indicator type, select IPv4 address, Domain, or URL. If a source provides multiple types, create a separate feed for each type.
7. Set Action to Monitor for the rollout. After a reviewed observation period, it can be changed to Block.
8. Under External URL, enter the appropriate address from the Avanet feed list or your own provider. The file must contain one indicator per line.
9. Configure an API key or Basic Authentication if required. Credentials do not belong in tickets or screenshots.
10. Enable Validate server certificate. For a public certificate, the issuing CA must be present under Certificates > Certificate authorities; for a private CA, import its certificate first.
11. Select a Polling interval that matches the provider’s update interval.
12. Run Test connection and save with Save.

Then check Sync status, Last updated, the number of Threat indicators, and the available Storage quota. Success confirms the download, but not that the expected traffic is actually detected or blocked. Validate this effect separately in the Log Viewer.

Choose the right feed and action

Supported indicators

A feed contains exactly one of these types:

• IPv4 address: scanners, botnets, compromised systems, or C2 servers
• Domain: malware, phishing, or command-and-control domains
• URL: specific malicious paths or download links

The feed must be a plain-text file with one indicator per line. IP ranges, IPv6 addresses, networks, wildcard domains, and regular expressions cannot be used in Third-Party Threat Feeds as substitutes for individual supported IoCs.

A large list is not automatically a good one. Origin, freshness, update interval, false-positive risk, and hits in the local environment matter more than the raw number of entries. A feed that provides no lasting benefit only consumes storage.

Monitor before Block

Monitor logs hits but allows the traffic. This shows which sources, destinations, and services would be affected. Block logs and drops matching traffic.

For a new feed, this sequence is useful:

1. Place the feed near the top of the Third-Party list.
2. Start with Monitor.
3. Check hits and possible false positives during a representative period.
4. Document the responsible person and the exception process.
5. Only then switch to Block.

A well-curated IPv4 feed for highly exposed services can be put into production sooner than a domain or URL feed. The latter more often match shared infrastructure, CDNs, or redirects and therefore require particularly careful review.

Order and naming

Active Threat Response processes the modules in this order: MDR, NDR Essentials, Sophos X-Ops, and then Third-Party Threat Feeds. With Log and drop, a match in an earlier module stops further checking. With Log only or Monitor, however, the firewall logs individual events for MDR, X-Ops, and Third-Party Threat Feeds.

Within Third-Party Threat Feeds, the firewall evaluates the Block and Monitor lists separately in their displayed order. It logs the first match in each list and blocks based on the first match in the Block list. Production feeds, pilot feeds, and temporary incident lists should therefore be clearly named and ordered:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

A good name identifies the provider or purpose, indicator type, and action. This saves time during log analysis and reviews.

Distinguish Threat Feed modules

Several features with different purposes and licence requirements appear under Active threat response:

• Sophos X-Ops Threat Feeds: Sophos indicators; require Network Protection and, for enforcement, Web Protection. Both are included in the Standard or Xstream bundle or can be licensed individually.
• MDR Threat Feeds: IoCs from Sophos MDR; require the Xstream Protection Bundle and MDR Essentials or MDR Complete in Sophos Central. The dedicated guide explains Central integration, the local action, audit ID, Task Queue, and incident verification.
• Third-Party Threat Feeds: external IPv4, domain, or URL lists; require the Xstream Protection Bundle.
• NDR Essentials: analyses traffic with machine learning and requires the Xstream Appliance Bundle.
• NDR Active Threat Intelligence: logs Sophos-curated NDR patterns, requires the Xstream Protection Bundle, and must be enabled per firewall rule using Scan with NDR Active threat intelligence. XGS 87/87w and 88/88w are not supported.

For NDR, see the separate guide Operate Sophos Firewall NDR and Active Threat Response.

Understand the effect on traffic

IPv4, domain, and URL traffic

Forwarded IPv4 traffic requires a firewall rule that processes the relevant traffic. System-bound traffic to services under Administration > Device access, such as WebAdmin, VPN Portal, and VPN, is matched separately against source-IP indicators and does not pass through a transit firewall rule.

For forwarded traffic, domain feeds additionally require Application Classification or an IPS policy in the firewall rule.

For complete HTTPS URLs, the firewall must also see the path. This requires either Web Proxy with HTTPS decryption or DPI with a suitable SSL/TLS inspection rule. Without decryption, the firewall sees only the domain through SNI, not the complete URL path.

DNAT and WAF from SFOS 22

Since SFOS 22, the firewall can match the source IP of incoming forwarded traffic for DNAT and WAF against MDR, NDR, and Third-Party Threat Feeds. This makes it possible to identify known scanners and botnets before they reach published services.

For these hits to appear in the Active Threat Response log, Remote source match (inbound traffic) must be enabled under System services > Log settings > Active threat response. It is disabled by default. Without this setting, blocking may work while the expected DNAT or WAF events remain absent from the Log Viewer.

Typical use cases

Threat Feeds do more than protect outbound client traffic. Publicly accessible services in particular are often scanned automatically within a short time.

• DNAT to internal servers: An IPv4 feed can block known malicious sources before they reach the published server.
• WAF publications: Reputation data complements WAF rules against bot traffic, CVE scans, CMS probes, and credential stuffing.
• VPN Portal, User Portal, and WebAdmin: Protect these services first with MFA, source networks, and Device Access and Local Service ACL. Threat Feeds additionally reduce traffic from known attacker sources.
• Outbound client traffic: Domain and URL feeds can block known malware, phishing, and C2 destinations.
• Heavily scanned WAN addresses: A good IPv4 feed reduces automated noise and relieves the firewall and its logs.

Threat Feeds complement basic hardening; they do not replace it. Published services still need restrictive DNAT or WAF rules, only the required ports, sensible source or country restrictions, IPS or WAF, and enabled logging. A feed is not a licence for broad Any rules. The overall process is described in the Sophos Firewall Hardening Hub.

Check synchronisation and operation

Test feed retrieval and traffic effect separately

A successful connection and Sync status: Success prove only that the firewall could download and read the list. A complete test covers three levels:

1. Retrieval: Test connection, Sync status, Last updated, and Storage quota are plausible.
2. Content: An expected IoC appears under Threat indicators.
3. Effect: Controlled test traffic produces a hit in Log viewer > Active threat response or at the configured Central or syslog destination. Depending on the match, the feed name, Log/Drop action, match direction, source and destination or URL, protocol, and ports can be traced.

For a reproducible test, use a short custom pilot feed on a controlled HTTPS server. It contains the IPv4 address of a controlled test destination. Keep the feed on Monitor, have a lab client connect to the test destination, and check the log entry. Do not access production malware destinations or third-party systems for testing.

Synchronisation and Storage Quota

These values in the feed overview are important for ongoing operation:

• Success, Fetching, or Disabled under Sync status
• the expected timestamp under Last updated
• a plausible number of Threat indicators
• sufficient available Storage quota
• a successful manual update using Synchronize now

For an Authentication error, check the API key or credentials. For a Connection error, check DNS, internet access, the HTTP status, and the feed server. An SSL/TLS error points to the certificate or certificate chain, while Failed often indicates the feed format or invalid indicators.

If storage is full, review feed scope, quality, and priority instead of adding more lists. On XGS 87/87w, 88/88w, and 107/107w, only 24h, 7d, and 30d polling intervals are available for Third-Party Threat Feeds. A provider feed that updates more frequently does not override this appliance limitation.

If no hits appear

Use this troubleshooting order:

1. Feed enabled, Sync status: Success, and expected IoC under Threat indicators
2. a higher-priority MDR, NDR, or X-Ops detection for the same IoC
3. Active Threat Response logging and, for DNAT/WAF, Remote source match
4. the matching firewall rule and its logging
5. for domains, Application Classification or an IPS policy
6. for URLs, Web Proxy or DPI and SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions, and SSL/TLS Exclusion Lists

If a feed produces no relevant hits over a representative observation period, reassess its value.

Handle false positives

For an incorrect block, first open the log entry and document the feed name, Log/Drop action, match direction, source and destination or URL, protocol, and ports. Then confirm that the traffic is legitimate, report the affected indicator to the feed provider, and create only the narrowest possible exception with a reason, owner, and review date.

A broad exception for entire networks is not a clean solution. For domain or URL hits, TLS Inspection, a web policy, DNS Protection, or another security feature may also be involved.

Backup and restore

A firewall backup contains the Third-Party Threat Feed configuration, but not the downloaded lists. After a restore, the firewall immediately retrieves the sources again and applies the configured action. DNS, internet access, certificate validation, and credentials must therefore work immediately after recovery.

Threat Feed configurations cannot be imported or exported separately; Threat Exclusions, however, can. After a restore, check feed retrieval, IoC count, and traffic effect again.

Cybora Threat Feeds for Sophos Firewall

Cybora provides curated feeds so administrators do not need to collect, normalise, and continuously review multiple OSINT lists themselves. The data comes from community and OSINT sources, commercial threat intelligence, honeypots, and anonymised attack and anomaly logs from managed Sophos Firewall environments.

Avanet has tested several Threat Feed providers in real firewall environments. In our view, Cybora currently offers the best value for Sophos Firewall. We evaluated feed quality, coverage, update intervals, and costs. Even so, administrators should first evaluate the feed in a Monitor pilot in their own environment.

Compare plans

Free (Basic) is suitable for home users, proof-of-concept deployments, and compatibility tests. Standard adds malware and phishing domains to the IPv4 feed. Premium extends coverage with domains and URLs updated hourly. Ultimate targets critical infrastructure and high-risk perimeters with 15-minute updates.

Beyond quantity and price, freshness, supported indicator types, source quality, update interval, false-positive risk, and traceability in the Log Viewer matter. The right feed is the one that produces relevant hits with acceptable side effects in the local environment.

Avanet Firewall Network

Part of the Premium feed comes from a distributed firewall network. This perspective helps identify attack patterns that are barely visible on a single firewall.

In distributed brute-force attacks, each bot makes only a few failed login attempts and often remains below a local threshold. Combining anonymised signals reveals IP addresses that systematically attack infrastructure across multiple systems. This creates a continuously updated Threat Intelligence Feed for automated defence.