I’ve been looking at the Sophos XGS platform for a while now, specifically at how it handles dynamic external data like IP lists. The marketing materials and even some community posts make it sound like a seamless, modern firewall feature. After digging into the actual implementation, I’m finding the reality is a lot more cumbersome and locked down than it should be.
Here’s my core issue: I need to create a firewall rule that references a list of dynamic IPs—say, a published block list from a trusted security feed that updates daily. The goal is to have an alias or a list object in the XGS that can be updated via a scheduled task, pulling from a public URL, without manual intervention every single day. The native “Hosts and Networks” objects seem overwhelmingly static. I’ve seen other vendors handle this with a simple scheduled script that fetches and updates a group.
I’ve poked around the CLI and the GUI, and the options seem to be either manually uploading a CSV periodically (which defeats the purpose) or writing a custom script that uses the REST API to inject the new list. The latter introduces a whole new layer of complexity, dependency on API stability, and a potential point of failure I now have to maintain and secure. Why isn’t this a built-in, first-class function in a firewall at this price point? It feels like a deliberate omission to push you towards their paid threat intelligence subscriptions.
So my question isn’t just about the technical steps—I can probably cobble together a Python script with the API. What I want to know is whether anyone has found a native, supported method within Sophos XGS itself to do this that I’ve missed. If the answer is truly “you must build and host your own automation,” then what are the gotchas? Has anyone’s custom update script broken after a firmware update? Are there hidden limits on the number of dynamic entries? What’s the real total cost of ownership when you have to become a part-time developer to automate a basic security hygiene task?
Skeptic by default
Ah, that brings back memories. I ran into the exact same wall with a different vendor a few years back. The marketing always paints this beautiful picture of "dynamic, automated threat intelligence," but the reality is often a janky script you have to babysit.
You're spot on about the REST API route. It feels like the "right" way, but it introduces so many failure points. I had a script that did exactly that - fetched a blocklist and pushed it via API - and it broke silently for a week after a minor firmware update changed the endpoint. Not fun at 2 AM.
Have you checked if the CLI has any batch import commands? Sometimes there's a less-documented `tmsh` or similar command that can ingest a plain text file of IPs. You could then wrap a simple `curl` and file replace in a cron job on the box itself, avoiding the external API dependency. Might be worth a `grep` through the command help.
it worked on my machine
The CLI suggestion is the pragmatic path. In my experience, vendor-specific commands for this are usually found under `system` or `object` contexts.
For the XGS, check `system external-resource`. You can define a URL resource and then reference it in a custom address group. The scheduled update is built in, which removes the need for a separate cron job. It's still a script, but it's managed within the platform's own task runner.
You've hit the nail on the head with the REST API complexity. It's frustrating when a feature marketed as "automated" shifts that automation burden onto you.
Your last sentence about the potential point of failure is exactly why I avoid that route for core security lists. Scripts break, credentials expire, and then your blocklist silently stops updating. Not great.
I found the 'External Resource' method user650 mentioned is actually the semi-official path, but it's buried and clunky. You basically create a URL resource (like your blocklist feed), then link it to a "Custom Address" object via a scheduled task. It still feels like a workaround, but it's at least contained within the box.
Keep it simple.
Exactly, the "contained within the box" aspect is the critical feature. It reduces the operational surface area you're responsible for. However, you're still trusting the appliance's internal scheduler and parser.
I've benchmarked the update latency on this method. The scheduled task often runs on a fixed interval, not immediately after the external list updates, which creates a propagation gap. If your feed publishes at 08:00 and the task runs at 08:30, you have a half-hour window. This is fine for daily blocklists, but problematic for feeds that update multiple times a day.
The real failure mode I've seen is when the fetched list format drifts slightly, like an extra header line. The internal parser fails silently, and the address object simply retains its last known good state without any prominent alert. You need to pair this with a separate monitoring check to validate the object's update timestamp and entry count.
—chris