Skip to content
Avanet

Set up and verify Linux Runtime Detection for Sophos servers

Sophos Server Protection

Linux Runtime Detection (RTD) monitors running processes and applications on Linux servers with Sophos Protection for Linux (SPL). An RTD detection reports suspicious activity; it does not mean RTD blocked or remediated the process. RTD complements Server Threat Protection but replaces neither its malware protection nor Linux real-time scanning. Terminating malicious processes on a real-time malware detection is a separate Server Threat Protection setting, not an effect of RTD. Saving a profile configuration alone does not activate detection on a server.

In brief: Check the license and SPL servers → enable Linux runtime detections in the effective Server Threat Protection policy → enable a Linux Runtime Detection policy for a small group of Linux servers, using SophosLabs default detections or an explicitly selected profile version → verify assignment and detections → only then expand the rollout.

Prerequisites and the decision before the pilot

RTD policies apply only to Linux servers, not Windows servers or the separately configured Sophos Linux Sensor. Sophos lists Sophos XDR - Server or Sophos MDR Plus - Server as required for RTD policies. Do not infer RTD entitlement from a general Server Protection, Endpoint, or other MDR license. Check the specific server license, availability in your tenant, and the installed SPL agent before approving the pilot. If the policy or license is unavailable, do not substitute a superficially similar Endpoint or Sensor configuration.

Choose a low-criticality, representative Linux server and a dedicated pilot group, such as linux-rtd-pilot. The name is up to you; its membership must reflect the servers you actually intend to test. Record the policies currently in effect, group membership, and, if applicable, the profile name and Profile Version. This lets you reverse the change specifically without disturbing baseline protection. An RTD rule may report legitimate operations, so include the pilot’s maintenance and automation processes in your observations.

Configure the policy and optional profile

  1. In Sophos Fusion, open the Server Threat Protection policy effective for the pilot servers under My Products > Server > Policies. Use Show filters > Operating System > Linux to display the relevant options. Under Runtime Protection, check that Linux runtime detections is enabled, then save the policy. If this policy also protects other servers, create or use a policy limited to the pilot group rather than inadvertently changing the entire fleet. The separate Enable scan for Server Protection for Linux agent switch controls Linux real-time file scanning; it is not the RTD switch and should not be turned off for an RTD test.
  2. Decide before creating the RTD policy: Sophos Labs Default Detection uses SophosLabs default detections without custom rule tuning. Choose Linux Runtime Detection Profile only if you need to deliberately adjust and version individual rules or their allow/block lists. A profile also builds on SophosLabs content; it does not replace the policy.
  3. For the profile option only: Open My Products > Global Settings > Protection and Remediation > Linux Profiles, click Create Profile, give it a name such as linux-rtd-pilot, check Content Version, optionally document the Change Description, and change only rules you understand. Save initially creates version 1. Use Create New Version for a later change; record which Profile Version is approved for the pilot. Profile Version (your configuration) and Content Version (SophosLabs content) are different things. Record both with every adjustment rather than treating the profile version number as a complete indication of the detection content in use. SPL always receives the latest SophosLabs default content; existing profiles are also updated with new SophosLabs content. Manually selected content updates, by contrast, apply to the separately managed Sophos Linux Sensor—not the SPL server policy. Recheck custom rule changes after subsequent content updates.
  4. Under My Products > Server > Policies, create a Linux Runtime Detection policy. Open Settings, turn on Enable Linux Runtime Detection, and select either Sophos Labs Default Detection or Linux Runtime Detection Profile. For the profile option, explicitly select both Profile and Version. Enable the policy, assign it only to the pilot group, and click Save. Then check the assignment; saving a policy or profile alone does not prove that the target servers are applying it.

Check the scope: A profile can be used by multiple RTD policies. Before creating a new version or changing a rule, expand Active under Linux Profiles and check which policies are affected. Changing a shared policy can affect multiple groups. Do not disable a rule broadly or create a global exception as a quick response to a single false positive.

Verify policy effect and detections

Open My Products > Server > Servers > Server Groups, select linux-rtd-pilot, and check the Policies tab to confirm that the enabled Threat Protection and RTD policies apply to the group. Also check the policies actually assigned to the affected server and its current agent/contact status. If using a profile, Profile and Version in the RTD policy must match the approved selection. An entry under Linux Profiles > Active shows which policies use the profile, not that a test was successfully triggered on the host.

Next, monitor detections for the pilot server under Threat Analysis Center > Detections and record the time, server, rule, observed process, and operational context of each alert. This view requires uploaded device data; if nothing at all appears there, also check the Data Lake data transfer setting applicable to the server. A corresponding RTD detection confirms that an event was reported, not that RTD blocked or remediated it. The absence of alerts during normal operation neither confirms that RTD works nor proves that it has failed. Do not trigger malicious actions on production servers for testing.

If expected data is missing, first check the license/tenant, SPL connectivity, and the actual assignment of both enabled policies. For a profile, also check that the relevant rule is present and Enabled. According to Sophos, differing final build digits between Content Version in Fusion and rtd_content_version on the Linux device do not necessarily mean the content is outdated; do not change the profile version blindly. If a policy, agent, or upload issue remains unclear, provide timestamps and policy details to Sophos Support rather than using an undocumented test command or forcing an agent restart. Your security team or contracted MDR provider should investigate a suspicious detection; follow your incident-response process for an active incident.

Narrow down false positives and roll back safely

When an alert looks suspicious, investigate it first: Is the process authorized, which host and rule are involved, and was there relevant maintenance? Only after that review should you inspect the specific rule and its Allow/Block List in the profile. A narrowly scoped adjustment is preferable to disabling the rule outright; document its scope, rationale, and version, then retest with the pilot group only. Changing an allow/block list can reduce or alter detection. If you cannot confidently classify the alert as a false positive, do not allowlist it; have your security team or contracted MDR provider investigate further.

To roll back, first restore the pilot’s RTD policy assignment or profile selection to its documented previous state, then check the policy actually in effect again. If a new profile version causes problems, reselect the previously documented Profile Version in the pilot policy and save it; first check any other policies using the same profile. This reverses only the saved profile configuration or policy assignment: With SPL, it neither rolls back SophosLabs detection content that has since been updated nor pins an earlier Content Version. Recheck rule adjustments against the current content. Only if the pilot enabled the previously disabled Linux runtime detections prerequisite in a Threat Protection policy assigned specifically to the pilot can you restore that switch to its previous state. Do not disable Linux real-time scanning, all of Server Threat Protection, or SPL as an RTD rollback: doing so would remove protection in a different area. Finally, recheck contact status, effective policies, and any further detections.