Solutions · Linux servers and edge
Linux endpoint security that blocks before it runs, not after.
ThreatBreaker treats Linux as a first-class platform, not a port. The kernel asks the agent before a file executes, so a malicious binary is refused before it can do anything, on servers, workstations and ARM64 edge devices, online or offline.
Ubuntu, Kali and RHEL. One self-contained binary. Installs with a single command.
The kernel asks before the file runs
Linux has a feature called fanotify. With permission events, the kernel pauses a file access and asks a listening program whether to allow it, and it waits for the answer.
ThreatBreaker's agent is that listener. When a process tries to execute a file, the agent decides with its Sigma rules, YARA-X signatures, IOC lists and an on-device machine-learning model. Allow, and the program starts as normal. Deny, and the kernel refuses: the program never executes.
Prevention, not detect-then-kill
Most Linux endpoint tools notice a bad process after it starts and then kill it. Pick a model to see the difference on the same malicious binary.
The gap between “started” and “killed” is where files get encrypted and credentials get read.
What else the agent watches on Linux
Pre-execution blocking is one layer. These run alongside it, on the machine itself.
Process events in real time
Every process start and exit through the netlink process connector, with command line, parent and hash.
Injection
ptrace and executable-memory heuristics catch code pushed into a process that is already running.
Command and control
A time-based beacon detector flags processes that call home on a schedule.
Rootkits
Rootkit scanning looks for what tries to hide from the system itself.
Memory and files
YARA-X scans files at rest and process memory, throttled to protect the host.
Known vulnerabilities
A CVE scan on first check-in and every week shows which servers need patching first.
Built for production servers and ARM64 edge
Linux server security only works if the agent stays out of the way of the workload it protects.
One self-contained binary
Written in Rust, compiled per platform, with no runtime dependencies to install or keep patched.
Runs as a service
Registers as a daemon with a watchdog that restarts it if it stops.
Safe updates
Signed automatic updates; if a new binary crashes on first run, the previous one is restored.
Hard to silence
The agent re-hashes its own binary every five minutes and marks its process non-dumpable.
x86-64 and ARM64
The same agent runs on ARM64 Linux, including NVIDIA Jetson edge systems.
Works offline
Rules, signatures and the model run on the device, so detection continues without a network.
Indicative footprint from our whitepaper: tens of MB of RAM and under 1% CPU at idle, rising briefly during memory scans. Re-measure on your own fleet.
Your rules, enforced the safe way
Exceptions by content hash only
To silence a rule for one binary, you accept it by its hash, never by name or path: on Linux an attacker controls both.
Custom Sigma rules
Add your own detection logic over process events, alongside the built-in rules.
Linux triage playbooks
Run ready-made command templates, such as a persistence sweep or Linux triage, against one server or a batch.
Questions engineers ask first
We would rather you ask these than assume. An engineer will answer them for your exact kernel and workload.
Thirty minutes with an engineer. No slides.
- 1We support Ubuntu, Kali and RHEL. Which kernel versions does that cover, and what about other distributions?
- 2What happens to file access if the agent hangs, crashes or is killed: fail-open or fail-closed, and can I choose?
- 3Does pre-execution blocking work on the Jetson L4T kernel (JetPack 6 and 7)?
- 4What does a permission decision cost per file open on my workload, and how is scope tuned?
What it does not do
- –Catch code that never goes through a watched file execution with the pre-execution block. Injection into running processes is the job of the other detectors above.
- –Patch your kernel or packages. CVE scans tell you what to patch; you patch it.
- –Restore files. Containment and quarantine only.
- –Promise that nothing gets through. It is one strong layer, not a guarantee.
Linux endpoint security questions
- Does Linux need endpoint security?
- Yes. Servers, container hosts and edge devices running Linux are common targets for cryptominers, ransomware and backdoors, and they are often the machines nobody watches.
- What should I look for in a Linux EDR?
- Whether it blocks before execution or only kills afterwards, whether it keeps working offline, what it costs the host, and whether Linux is a first-class platform or a port. ThreatBreaker blocks before execution with fanotify and runs offline.
- Is there an open-source EDR for Linux?
- Open-source tools such as osquery, Wazuh and Falco give strong visibility. ThreatBreaker adds pre-execution blocking, investigation, forensics and response in one agent and one console.
- fanotify or eBPF: what is the difference?
- fanotify permission events are a long-standing kernel interface built for an allow-or-deny decision before a file is accessed. eBPF is mostly used to observe the system, though BPF LSM programs can also enforce. ThreatBreaker uses fanotify for its pre-execution block.
- Which Linux distributions are supported?
- Ubuntu, Kali and RHEL. Ask an engineer about kernel versions and other distributions for your fleet.
- Does it run on ARM64 and NVIDIA Jetson?
- The agent runs on ARM64 Linux, including NVIDIA Jetson, with detection on the device. Ask us for the current status of pre-execution blocking on the Jetson L4T kernel.
- Does it work on servers with no internet access?
- Yes. Detection runs on the machine. On-premise and air-gapped deployments use offline licence files verified locally, with no call home.
Ask us the hard questions about your kernel.
Thirty minutes with an engineer: the mechanism, the failure modes and your distribution.