Set up and operate Sophos Firewall Threat Feeds

The Sophos Firewall Threat Feeds from Cybora provides continuous threat intelligence feeds that automatically import Indicators of Compromise (IoCs) into the Sophos Firewall. Such IoCs are, for example, malicious IP addresses, malware domains, phishing URLs or known botnet C&C servers.

For the broader hardening context, use the hub Sophos Firewall Hardening: best practices for secure configuration.

This eliminates a large part of the manual maintenance effort. Instead of manually tracking individual attacker IP addresses or domains in host objects, firewall rules or block lists, the firewall automatically pulls the data from a curated feed and can block appropriate traffic.

This is particularly valuable as soon as a firewall is visible from the outside. Public IPs, DNAT rules, WAF publications, VPN portals or WebAdmin accesses are often found very quickly by bots, scanners and automated exploit frameworks. A good threat feed reduces this unwanted traffic before it gets deeper into the environment.

In short: Threat Feeds are strong when they are understood as an operational process. Select the feed, set the indicator type correctly, test visibly first, then block, review hits regularly and handle false positives cleanly. Simply adding a large list is not a good security strategy.

Classification

What Threat Feeds are

Threat feeds are lists of indicators of compromise. In practice, these are indications of known malicious infrastructure:

• IP addresses: Scanners, botnets, compromised systems or command and control servers.
• Domains: Malware, phishing or C2 domains.
• URLs: specific malicious paths or download links.

Depending on the provider, these feeds come from security organizations, industry consortia, open source communities, commercial threat intelligence, honeypots or your own sensors. In Sophos Firewall v21, the feature has been expanded to include third-party feeds integrated via the Active Threat Response Framework.

The advantages are clear:

• Proactive Protection: Block threats before damage occurs.
• Flexibility: Use feeds from different providers, tailored to individual requirements.
• Automation: The firewall blocks automatically; manual intervention is no longer necessary.
• Relief: Unwanted traffic is discarded earlier and does not even reach internal services.

Do not mix up Threat Feed modules

Several functions sit next to each other under Active threat response. The names sound similar, but they solve different tasks.

• Sophos X-Ops Threat Feeds: Sophos-owned indicators for known threats. In operation, enable the Network Protection function and check logs.
• MDR Threat Feeds: Threat intelligence from the Sophos MDR/XDR context. In operation, connect the MDR/Central process and firewall logging.
• Third-Party Threat Feeds: External IoC lists such as Cybora as IP, domain or URL feeds. In operation, take responsibility for feed quality, action, synchronisation and exceptions.
• NDR Essentials / NDR Active Threat Intelligence: Detection of suspicious traffic patterns rather than a pure IoC list. In operation, evaluate detection signals and do not confuse them with a block list.

This article mainly covers Third-Party Threat Feeds. For NDR and Active Threat Intelligence, see Operate Sophos Firewall NDR and Active Threat Response.

Typical areas of application

Threat feeds are not only interesting for outgoing client traffic. In practice, you can see automated access very quickly, especially with publicly accessible services.

• DNAT to internal servers: Port forwards are scanned quickly. An IPv4 feed can block known bad sources before they reach the internal server.
• WAF publications: Web servers often see bot traffic, CVE scans, CMS probes and credential stuffing. Threat Feeds add reputation to WAF rules.
• VPN Portal, User Portal and WebAdmin: Portals should first be protected via Device Access, MFA and source networks. Threat Feeds additionally reduce known attacker sources.
• Outbound client traffic: Domain and URL feeds can block known malware, phishing or C2 targets.
• Heavily scanned WAN addresses: If a public IP permanently sees bot traffic, a good IPv4 feed can noticeably reduce load on the firewall and logs.

Since SFOS 22, Threat Feeds are especially interesting for incoming forwarded traffic such as DNAT and WAF. This allows the firewall to detect known bad sources in front of published services as well. For older installations or mixed versions, check this point deliberately before assuming the same level of protection.

But threat feeds do not replace clean publication. If a service is accessible via DNAT or WAF, only necessary ports should still be opened, source networks or countries should be restricted, IPS/WAF rules activated and logs checked. Threat feeds are an additional protection component, not a free pass for broad Any rules.

Requirements and licence

To use Third-Party Threat Feeds, Sophos Firewall needs the Xstream Protection Bundle. No additional Sophos Central licences are required for this. Other Threat Feed modules have their own requirements: Sophos X-Ops Threat Feeds require Network Protection, MDR Threat Feeds additionally require Sophos MDR Essentials or MDR Complete in Sophos Central, and NDR Essentials requires the Xstream Appliance Bundle.

In addition, you should check before the rollout:

• The firewall runs on an SFOS version with third-party threat feed support.
• The firewall can reach the feed URL via DNS and HTTPS.
• A clear Indicator type is used per feed, for example IPv4 address, Domain or URL.
• The feed is a plain-text file with one indicator per line.
• IP ranges, IPv6 addresses, network addresses, wildcard domains and regular expressions are not the right format for Third-Party Threat Feeds.
• Active Threat Response logging is enabled.
• It is clear whether the feed is initially just observed or directly blocked.

Practical recommendation: introduce new feeds in a controlled manner first. If the firewall allows it, start with an observation phase, check hits in Log Viewer and then switch to blocking. This makes it clear early on whether legitimate systems would be affected.

URL feeds and TLS Inspection

IP and domain feeds are mostly easy to understand. URL feeds are a little more demanding because the firewall needs to see the relevant URL path. With HTTPS traffic, this is not always possible without appropriate decryption.

If URL feeds are to be used productively, you must therefore check whether the Web Proxy, DPI Engine and TLS Inspection suit the environment. Without a clear view of HTTPS traffic, a URL feed can be less effective than expected.

For domain and URL feeds, the feed configuration alone is not always enough. The firewall needs a suitable firewall rule for the traffic and, depending on the traffic, Application Classification or an IPS policy. For full URL paths over HTTPS, Web Proxy decryption or DPI with a matching SSL/TLS inspection rule is also required. If a feed appears to produce no hits, do not only check the feed URL, but also the firewall rule, inspection path and exclusions.

Planning before rollout

Monitor or Block?

A Threat Feed can monitor or block depending on SFOS version and configuration. For production security, blocking is often the goal, but not every feed should blindly go straight into block mode.

• Monitor: Make hits visible without directly blocking traffic. Check log volume, affected sources/destinations and unexpected hits.
• Block: Actively stop known malicious indicators. Prepare false-positive process, alerting and exceptions.
• Review: Check effectiveness and side effects. Assess feed quality, old hits, support cases and business risk.

For heavily exposed services, a well-curated IPv4 feed can reduce a lot of noise directly. Be more careful with domain or URL feeds because legitimate services can more often run through shared infrastructure, CDNs or redirects.

Sophos evaluates block and monitor feeds in the displayed order. The first matching hit in both feed types is logged; blocking is based on the first hit in the block list. This makes the order practically relevant: a cleanly curated production block feed should not sit somewhere between test feeds, temporary incident lists and experimental sources.

Feed order and position

When adding a third-party feed, you can set the feed position. This sounds trivial, but is useful in operation: critical, well-curated feeds should be clearly named and ordered. Test feeds, temporary feeds or sources with a higher false-positive risk should not be hidden between production feeds.

Practical naming convention:

• Production IPv4 block feed: cybora-premium-ipv4-block
• Domain feed in monitor mode: cybora-standard-domain-monitor
• Temporary incident feed: incident-2026-06-c2-ipv4

A good name shows provider, plan or purpose, indicator type and action. This saves time in Log Viewer and during later reviews.

Synchronisation and Storage Quota

For Third-Party Threat Feeds, Sophos Firewall shows active feeds, total number of Threat Indicators, Storage Quota and synchronisation status. These values should not be ignored after setup.

Important checks:

• Sync status: Success, Fetching or Disabled are quick to classify. With Authentication error, Connection error, Storage full, SSL/TLS error or Failed, check the cause and feed deliberately.
• Last updated: Timestamp matches the expected polling interval.
• Storage quota: The firewall still has enough space for the loaded IoCs.
• Threat indicators: Count roughly matches the provider’s expectation.
• Synchronize now: Manual synchronisation works when a change should not wait for the next polling interval.

If the Storage Quota is full, the feed provider is not automatically at fault. Small appliances have less headroom than larger models. The firewall continues to fetch IoCs at the configured interval and updates the list as soon as space is available again. Even so, check feed scope, indicator types and priority rather than adding more and more lists.

On smaller XGS models, the polling interval may also be restricted. According to Sophos, XGS 87/87w, 88/88w and 107/107w only support 24h, 7d and 30d as polling interval options for Third-Party Threat Feeds. If a booked feed updates more frequently, include this platform difference in expectations for freshness and blocking effect.

From Free to Ultimate Threat Feed – by Cybora

Reliable and up-to-date threat intelligence is crucial. Avanet therefore relies on curated threat feed plans from Cybora that are specifically designed for use on Sophos Firewalls.

The feeds are compiled from various sources to ensure the broadest and most reliable threat detection possible. These include community and OSINT data, commercially purchased information, honeypot results and anonymised attack, error and anomaly logs from real Sophos Firewall environments in operation.

Free (Basic) is suitable for home users, PoC and compatibility tests. Standard adds important malware and phishing domains to the IPv4 feed. Premium expands coverage to include domains and URLs with hourly updates. Ultimate is designed for critical infrastructure and high-risk perimeters with 15-minute updates.

Sophos Firewall Threat Feeds filter out known malicious infrastructure sooner. Depending on the environment, the free Basic plan is sufficient for testing, while Standard, Premium and Ultimate are intended for productive needs with increasing coverage and timeliness.

Cybora is especially suitable when a concrete, purchasable feed for Sophos Firewall is needed and the organisation does not want to collect, format, check and operate several OSINT lists itself. The practical value lies less in the largest list and more in curated indicators, clear feed plans and an operating path that fits Sophos Firewall’s Third-Party Threat Feed function.

Compare threat feeds

When comparing, you shouldn’t just pay attention to the number of entries. A huge list is not automatically better if it produces a lot of false positives or is poorly maintained. It is crucial that the feed is current, curated and easy to use for the firewall.

Important criteria:

• Up-to-dateness of data
• supported indicator types
• Quality and curation of sources
• Update interval
• False positive risk
• Traceability in the log viewer
• sensible exception process

Avanet Firewall Network

Part of the Premium Feed is data from a distributed firewall network. This view is particularly interesting for attack patterns that are hardly noticeable on a single firewall.

Many tools easily detect brute force attacks on individual IP addresses, but fail when dealing with distributed botnet attacks. In such cases, each host controlled by the attacker makes only a few failed login attempts at a low frequency, thereby avoiding detection and blocking.

Some botnets contain hundreds of thousands of infected hosts, allowing cybercriminals to carry out massive brute force attacks without being blocked.

Such patterns create a constantly updated Threat Intelligence Feed with IPs that have been noticed on multiple systems. By merging and continuously feeding this data into the Threat Intelligence Feed, IP addresses that specifically attack infrastructure are identified and automatically blocked.

What threat feeds do not replace

Threat feeds are powerful, but they are no substitute for clean firewall fundamentals.

Not to be replaced:

• restrictive firewall rules
• MFA for VPN, portals and admin access
• Device Access and Local Service ACL, as described in Securing Sophos Firewall access.
• IPS, WAF, Web Protection and TLS Inspection
• Patch management and hotfixes
• Logging, reporting and regular monitoring

For example, if a web server is published via DNAT, the firewall rule should still have the narrowest possible sources, specific services and activated logging. A threat feed blocks known bad sources, but unknown or new attackers can still arrive.

Set up Sophos Firewall Threat Feed

Integrating the Cybora Threat Feeds is straightforward and takes only a few minutes. All feeds are fully compatible with the Third-Party Threat Feed function of Sophos Firewall and can be added via the firewall web interface as follows:

1. Open menu: Protect > Active threat response > Third-party threat feeds > Add
2. Enter basic data
   • Name: cybora-premium-ipv4
   • Description: Cybora Feed - Premium
3. Set indicator type
   • Indicator type: IPv4 address, Domain or URL
   • Create a separate feed per indicator type if the same source offers IPs, domains and URLs.
4. Select action
   • For productive blocking: Block.
   • For a cautious start: choose Monitor or an observing action if available and useful.
5. Store feed URL
   • Insert the appropriate address from the Avanet feed list in the External URL field.
   • The URL must return a text file with one indicator per line.
6. Set polling interval
   • Choose Polling interval: to match the booked feed.
   • A shorter time doesn’t help if the feed itself only updates at a longer interval.
7. Configure authentication (if necessary)
   • Depending on the feed, without authentication, with an API key or with Basic Authentication.
   • Do not expose credentials or feed keys in tickets, screenshots or public documentation.
8. Test connection and save
   • Run Test connection.
   • Then save with Save.

After saving, do not immediately move on to the next topic. First check whether the feed synchronises, whether the expected number of IoCs is visible and whether Log Viewer shows hits with feed name, action, source and destination in a traceable way.

Control during operation

After setting it up, you shouldn’t just assume that everything will fit. It is important that hits are visible and explainable.

1. Check System services > Log settings and activate active threat response logging.
2. Filter for Active threat response in the Log viewer.
3. Check which feed hit.
4. Check the source, destination, service and affected firewall rule.
5. Do not set a broad exception for false positives, but check and document the specific indicator.

Especially with DNAT, WAF and VPN portals, after activation you can often see very quickly how much unwanted traffic comes from known bad sources. This makes Threat Feeds particularly useful as an additional protection component for exposed services.

If a feed shows no hits

No hits do not automatically mean that the feed is poor. Another Active Threat Response component may detect the same IoC earlier, the relevant traffic may not pass through the right firewall rule, or the firewall may not see enough context for domains and URLs.

Useful checks:

1. Open Threat indicators and search for a known test indicator.
2. Check whether the feed is active and whether the sync status shows Success.
3. For Authentication error, check credentials or API key.
4. For Connection error, check DNS, internet access, HTTP status and feed server.
5. For SSL/TLS error, check the CA certificate and certificate chain of the feed server.
6. For Failed, check feed format, file access in the browser and invalid indicators.
7. Check the firewall rule and Log Viewer for the expected traffic.
8. For domain feeds, check Application Classification or IPS policy.
9. For URL feeds, check Web Proxy, DPI and SSL/TLS inspection rule.
10. Check Threat Exclusions, Web Exclusions and SSL/TLS Exclusion Lists.
11. If no relevant hits appear after an observation phase, reassess feed scope or feed position.

Handling false positives

False positives are possible with any dynamic block list. The decisive point is how cleanly they are handled.

Practical process:

1. Open the affected log entry in Log Viewer.
2. Note feed name, indicator type, action, Source, Destination and Service.
3. Check whether the traffic is expected and legitimate from a business perspective.
4. Check or report the indicator with the feed provider.
5. Set the exception as narrowly as possible.
6. Document ticket, reason and review date.

A broad exception for whole networks is not a good solution just because a user “cannot open a site”. For URL or domain hits, additionally check whether TLS Inspection, Web Policy, DNS Protection or another security function is involved.

Operational checklist

• Feed name, provider, plan and owner documented.
• Indicator type clearly set per feed.
• Action Monitor or Block deliberately chosen.
• Polling interval set to match the feed.
• Certificate validation and authentication tested.
• Synchronisation status and Storage Quota checked.
• Active Threat Response logs visible.
• False-positive process with review date defined.
• DNAT, WAF and VPN scenarios assessed by SFOS version.
• Alerts or reports for recurring hits planned.

FAQ