We've been evaluating Intercept X Advanced for EDR on our internal application servers (mostly Node.js and Python APIs). During load testing, we're seeing legitimate internal RPC traffic being flagged and blocked by the "Malicious Traffic Detection" module. The traffic is between known, managed hosts within the same subnet.
The alerts in the Central console show "Exploit" and "Suspicious Connection" for connections on non-standard ports (e.g., 3001, 5001, 8000) that our microservices use. This appears to be a case of the behavioral detection being overly sensitive to the specific patterns of our home-grown protocol.
I need to create a precise exception policy to allow this traffic without disabling protection for truly malicious external connections. The Sophos docs point towards "Web Control" or "Host Firewall" policies, but the interaction with the Exploit Prevention component is unclear.
Has anyone successfully whitelisted internal application traffic at this level? Specifically:
* Is it better to create an allow rule based on source/destination IP and port in the firewall policy, or to use an "Exclusion" in the Exploit Prevention policy?
* Does an IP-based rule in the Host Firewall actually stop the Exploit Prevention module from analyzing the packets, or will it still scan and alert?
* What's the performance impact of an exclusion vs. a firewall rule? We need minimal latency overhead for this internal channel.
Our current test firewall rule (set via Central) looks like this, but alerts persist:
```json
{
"rule_name": "Allow Internal App RPC",
"action": "allow",
"direction": "in",
"protocol": "tcp",
"local_ports": ["3001", "5001-5005"],
"remote_addresses": ["192.168.10.0/24"]
}
```
Should we be looking at a registry hack or local policy on each server instead? The goal is a centralized, managed solution.
benchmark or bust
benchmark or bust
You're on the right track, but you're about to waste a lot of time if you treat this as a Host Firewall problem. The "Exploit" and "Suspicious Connection" alerts are coming from the behavioral exploit prevention engine, not the stateful firewall. A firewall allow rule won't stop those alerts or blocks.
You need to create an exclusion in the Exploit Prevention policy, specifically for the "Malicious Traffic Detection" module. Go to Policies > Exploit Prevention, edit your policy, and find the "Exclusions" section. Add a process path exclusion for your Node.js and Python interpreters (e.g., `C:Program Filesnodejsnode.exe` or the path to your Python.exe). You can scope it by source IP ranges (your internal subnet) if you want to be extra safe.
This tells the engine to ignore network activity generated by those specific processes when talking to your trusted IPs. Just using port-based firewall rules is like trying to fix a roof leak by mopping the floor.
Speed up your build
That's a correct distinction between firewall rules and the behavioral engine, and specifying the process path is indeed the proper approach. A nuance worth adding, from having seen similar configurations, is that you should also consider the exact command line or working directory if these interpreters are launched in multiple contexts. The engine might treat a Python script running a management tool differently from one handling API traffic, even with the same executable path.
You can sometimes refine the exclusion further by pairing the process path with a specific network signature or port range in the policy's advanced settings, though that varies by Intercept X version. Have you verified whether the exclusions take immediate effect on the endpoints, or if they require a policy push and agent restart? That tripped up a team I worked with last month.
Let's keep it constructive