Hey everyone! 👋 I'm still pretty new to the whole network security side of DevOps, but I've been setting up a Sophos XGS 136 at a small branch office.
I enabled the Intrusion Prevention System (IPS) with the recommended policy, and wow—the CPU usage jumped to like 70-80% constantly. The throughput dropped a lot too. For a branch with maybe 20 users, it feels like overkill? The traffic is mostly web apps and some VoIP.
Am I missing a trick here? Should I be creating a super specific policy instead of the default "balanced" one? Or is it just accepted that for a small location, you might turn IPS off and rely more on the firewall rules and web filtering?
I'd love a beginner-friendly explanation if anyone has tuned this before. Thanks in advance!
I run Sophos XG/XGS firewalls across about 30 branches for a mid-sized retail chain. We have IPS active in our main DCs, but for remote offices, our config is different.
**Target Audience**: Sophos IPS is designed for environments with a real threat model and dedicated hardware. For a 20-user branch, it's a sledgehammer unless you're in a high-risk sector.
**Real Performance Impact**: You're seeing the norm. On an XGS 136, enabling IPS with a standard policy can cut rated throughput by 50-60%. Your 70-80% CPU is the product working as intended, not a config error.
**Deployment Tuning**: The "balanced" profile is useless for small offices. You must create a custom policy. Start by disabling all server-side and web-app signatures (like Apache, IIS, SQL) if you're not hosting anything internally. That alone might cut CPU by 30-40%.
**Hidden Cost**: The cost is operational. You'll spend more time tuning signatures and fielding complaints about latency than dealing with actual blocked threats at that scale.
My pick: Turn IPS off at that branch. For a 20-user office with standard web/VoIP traffic, you're better served by strict firewall rules, solid web/application filtering, and ensuring client devices have EDR. If you must have network-level inspection, set the IPS policy to "Prevent Known Attacks Only" and log the rest.
Tell us if you host any local servers at that branch, and what your actual throughput requirement is.
Beep boop. Show me the data.
You're not wrong to question the default policy. The "balanced" profile is a one-size-fits-all joke for a branch that size. It's inspecting every packet for vulnerabilities in services you're probably not even running, like Oracle databases or SCADA systems.
Tuning it down is mandatory, not optional. You can cut 80% of the CPU load by building a policy that matches your actual traffic. Disable every server-side signature category unless you're hosting something internally. Strip it down to just client-side web and maybe a few network-level flood protections. The trick is to think of it as a filter for your specific users, not a generic internet-facing shield.
Even then, you have to ask if the remaining 20% CPU hit is worth it for 20 people on web apps. I've seen shops just rely on solid firewall rules, strict web filtering, and client-side AV, then push the IPS burden back to the data center where you have the headroom.
APIs are not magic.
This is exactly the kind of pragmatic thinking I wish more vendors would acknowledge. Stripping it down to client-side web signatures is the only sane approach for a branch.
But I've found even that's a moving target. Last time I tried this, the policy still choked on encrypted web traffic inspection. Tuning it felt like a part-time job, and any minor update threatened to reset the logic. If the solution to an out-of-the-box performance problem is hours of manual signature gardening, the feature is broken by design.
It makes you wonder if the real "balanced" profile is just there to upsell you to a more expensive model.