eBPF security monitoring

Every Linux host running the agent carries a security module that watches the kernel with eBPF: process execution, file changes, network connections, SSH sessions, privilege changes, and container activity. Detection rules run on the host, matching events become security events in your workspace, AI triage reads each one in context, and the ones that matter become alerts on your escalation policy. Nothing is installed beyond the agent and there is no kernel module; What is eBPF explains the mechanism.

Windows hosts get the same pipeline from the Event Log and Sysmon instead of eBPF; see Install on Windows.

Turn it on

The security module is part of the agent and is enabled per host. On a new host it is on; the Agent tab of the server page shows the module’s state, engine, and the probes it has loaded. Security monitoring is included with host monitoring on Professional and Business and on the trial - there is no separate charge per host.

The policies

Detection rules are grouped into policies. Seven are enabled by default for every workspace:

Policy	Watches for
Access control	SSH logins off-hours, at weekends, from unknown sources; new users and groups; sudoers changes; session activity
File integrity	Changes to system binaries and `/etc` outside a package manager or maintenance window; YARA matches. See File integrity monitoring and YARA
Network security	Reverse shells, unexpected listeners, connections to unusual destinations, DNS to suspicious names
Process monitoring	Suspicious binaries and interpreters, execution from temp directories, process injection patterns
Container security	Shells inside containers, escapes, privileged containers, images from registries outside your allowlist
Privilege escalation	Setuid abuse, capability changes, unexpected root shells
Cryptojacking	Miner binaries, mining pool connections, the CPU pattern of a miner

Two frameworks add compliance-tagged rules on top: SOX and PCI DSS. Turning a framework on tags matching events with the control they evidence, which the compliance module collects. Every rule carries MITRE ATT&CK tactics and techniques; see MITRE ATT&CK overview.

Turn policies and individual rules on or off, and override a rule’s severity, under Security, then Detections. Built-in rule bodies are not editable - fork one into a custom rule instead. The whole surface is described in Customizing detection rules and Custom rules, saved filters, and ignore rules.

From event to alert

A rule match becomes a security event with a priority (emergency through debug), the rule, the host, the process and user involved, and the raw fields. Two things then happen:

AI triage reads it - what the process is, what ran before, whether the host has done this before, what the directives say - and records a verdict: malicious, suspicious, benign, or informational. See AI triage and Kicker.
The alert bridge decides whether to page. Under Security, then Detections, then Alerting, set whether security events raise alerts at all, the minimum severity (default high), and the escalation policy they route to. An event at or above the floor raises an alert that behaves like any other; see Working with alerts.

The bridge is what keeps the pager quiet: the stream can carry thousands of informational events a day while only a handful cross the floor.

The lists the rules read

Under Security, then Detections, then Lists:

List	Used by
Business hours and days, with timezone	Off-hours and weekend rules. Unset means 08:00 to 18:00, Monday to Friday, UTC.
SSH allowed source addresses	Logins from an address not on the list alert at connect time (bare IPs or CIDRs; an empty list disables the rule)
Authorised container registries	Images from anywhere else alert (registry hosts or image prefixes; empty leaves the rule inert)

Set the business hours on day one; the off-hours rules are among the most useful and the least useful when the hours are wrong.

Automatic response

Security, then Detections, then Response controls SSH brute-force blocking: when a source address fails authentication more than the threshold within the window, the agent blocks it for a cooldown. Every host starts in dry-run, logging what it would have blocked, and there is an account-wide kill switch that forces every host back to dry-run. Details in SSH login monitoring. Hosts can also be locked against SSH by default and opened only for declared work; see SSH lockdown.

The first hour after installing

Set business hours and the SSH allowed-source list.
Open Security, then Events and read what the first hour produced. A fresh host generates a burst of informational events as baselines build; that settles.
For anything that fired and should not, create an ignore rule scoped to that rule and host, or a correction in Kicker’s memory if the AI verdict was wrong.
Check the alert bridge floor. High is the right default; lower it for a small, quiet fleet, raise it for a noisy one.
Send a test through: an SSH login from an address not on the list should produce an event and, above the floor, an alert on your policy.