NuajProtect · Linux
The NuajProtect Linux agent is a single static binary, run by systemd, that blocks malicious traffic in the kernel of the server it protects. It carries the same detection and intelligence engine as the NuajBridge appliance — the live global threat-intelligence feed, flood detection measured against the link's own baseline, port-scanner detection and repeat-offender escalation — and enforces the result through the fastest path the kernel offers: XDP/eBPF where it exists, nftables or iptables with ipset where it does not. There is no proxy and no extra hop: accepted traffic is forwarded by the kernel rather than reassembled by something in front of it.
In one sentence
| What it is | The NuajProtect Linux agent — a host-based edge filter with a global threat-intelligence feed behind it |
|---|---|
| Form | One static binary, no runtime dependencies, run by systemd as an unprivileged system user |
| Architectures | x86_64 and aarch64 |
| Distributions | Any Linux with systemd — Debian, Ubuntu, RHEL, Rocky, Alma, Fedora and derivatives |
| Enforcement | XDP/eBPF where the kernel offers it; otherwise nftables, or iptables with ipset. Chosen by the agent at start-up, not configured |
| Placement | Sentry — protects the host it runs on. Relay — protects what is behind it, directly or over GRE, WireGuard or IPsec |
| Addressing | IPv4 and IPv6, both enforced |
| Paths | /opt/nuajprotect for the binary and its configuration, /var/log/nuajprotect for logs |
| Service | nuajprotect-agent under systemd; CLI on your PATH as nuajprotect |
| Local interface | A break-glass console and API bound to 127.0.0.1, reachable when the control plane is not |
| Control plane | Managed SaaS over mutual TLS, or a self-hosted control plane you run yourself |
| Price | Free through the beta and for a full year after general availability |
Enforcement
Three enforcement backends, one decision, made by the agent when it starts. You are not asked to know which one your kernel supports, and an older box is not left with nothing.
First choice
The earliest point in the kernel a packet can be dropped — before it is allocated a socket buffer, before the network stack has spent anything on it. Where a driver supports XDP natively the drop happens in the driver itself.
Where BPF is unavailable
Sets and rules maintained by the agent, matched by the kernel. Later in the path than XDP, and still a kernel drop — what the rules match is dropped before your application is reached, and nothing is proxied on the way.
Older kernels
The long-term-kernel path. A 5.4-series kernel cannot do XDP, and that is not a failure to report — it is the case this backend exists for. The same lists, enforced by the tooling that box has.
What the backend does not change is the decision. The blocklist, the flood thresholds derived from your own link's baseline, the scanner strikes and the repeat-offender escalation are computed the same way wherever the agent runs; only the instruction handed to the kernel differs. A fleet with three kernel generations in it therefore enforces one policy, and the dashboard shows you which backend each endpoint chose.
Placement
Sentry
The protection runs on the machine it defends. Traffic to and from that host is filtered in its own kernel, and software on the host can hand the agent an attacker it spotted at the application layer. This is the default for a public-facing server or VM, and the fastest thing to try: one install, no change to how anything is routed.
Relay
A forwarding gateway cleans traffic on its way to services that never see the raw internet. They can sit directly behind it or at the far end of a tunnel — GRE, WireGuard or IPsec — so the protected addresses need not be exposed at all. One relay covers appliances, embedded systems and anything else that cannot run an agent of its own.
Both are the same binary and the same account. An endpoint's type and its placement are two separate settings, and the combinations that are not possible are listed as unavailable rather than offered and then rejected at setup. Where a whole network needs covering with nothing installed on any of it, that is the NuajBridge appliance instead.
Install
The installer is a shell script, served over TLS, and your account gives you the exact command for the endpoint you are adding. Download it, read it, then run it — piping a script straight into a shell means running something you have not seen, and this one needs root.
# fetch, read, then run — never pipe a script you have not seen into a shell
curl -fsSL <the installer URL from your account> -o nuajprotect-install.sh
less nuajprotect-install.sh
sudo bash nuajprotect-install.sh
systemctl status nuajprotect-agent journalctl -u nuajprotect-agent -f nuajprotect status
The agent authenticates to the control plane with mutual TLS, so an endpoint is a certificate rather than a shared secret in a config file, and enrolment is done from your NuajProtect account. Run it watching before you run it blocking: monitor mode, the allowlist and the per-endpoint activity view exist because any filter can misjudge unusual but legitimate traffic, and the time to find that out is before it is dropping it.
Application reporting
Credential stuffing inside valid sessions. A scraper that behaves until it doesn't. An API key being walked one identifier at a time. None of it looks wrong on the wire — and all of it is obvious to the application it is happening to.
Because the agent runs on the host, your own software can hand it an address it has judged hostile, over a local interface bound to 127.0.0.1 that nothing off the machine can reach. The agent enforces it in the kernel immediately. The report also travels: what one protected edge works out, the account's other edges enforce, and — where the evidence is strong enough — the global intelligence feed carries it to everyone else.
That same local interface is the break-glass path. If the control plane is unreachable, the agent keeps enforcing what it already knows and you can still see and change what it is doing, from the console on the loopback address. A protected server does not stop being protected because a network between it and us is having a bad day.
Upgrades
The agent upgrades itself when the control plane offers a newer build, and every release is signed. The signature is verified before anything is replaced; if it does not check out, the upgrade is refused and the running build stays. A self-upgrading fleet is only as trustworthy as the answer to "what exactly is it allowed to install", and that is the answer.
Upgrades are also held back while a configuration change is still settling, so no box restarts into a new build and a new policy in the same moment — the two events are separated deliberately, because a fleet that changes both at once cannot tell you which one caused what.
Questions
Running MikroTik at the edge as well? The same account manages NuajProtect on RouterOS, and every deployment — agent, router or appliance — is a sensor as much as an enforcement point.
Get started
The service is free through the beta and for a full year after general availability. Start with one exposed box; everything you protect lives in the same account.