What syscall-layer tooling cannot see in P2P infrastructure: a technique-by-technique analysis | NullRabbit

← Back to ResearchMore than $100 billion in digital assets is staked across decentralized networks. The operators who run that infrastructure protect it with traditional syscall-layer security tooling: Falco, commercial EDR, generic host agents. This is a technique-by-technique analysis of why that tooling is structurally blind to an entire class of availability attacks against the nodes themselves.

The shape is always the same. A network denial-of-service attack against a validator or RPC node lands, and nothing fires. It is not a tuning problem, and it is not a rule you forgot to enable. These attacks live above the layer the tools observe, so the tools cannot see them however they are configured.

The analysis below uses Falco as the worked example. Falco is the standard open-source syscall-layer runtime security engine, and its detection surface is public and documented, so its limits can be shown rather than asserted. The same limits apply to any tool that observes at the system-call boundary, including commercial EDR and generic host agents, because they are properties of that boundary and not of how well Falco is written. The five techniques are reproduced denial-of-service findings from the NullRabbit corpus of P2P and RPC infrastructure attacks. Each one links to its NRDAX registry entry and, where published, a full write-up and advisory.

The question

Host runtime security watches the system-call boundary. When a process opens a file, spawns a child, connects a socket, or reads a buffer, the kernel emits an event and the engine checks its rules against it. For what these tools were built to catch, that is a good place to watch: a shell spawned inside a container, an unexpected execve, a write to /etc/shadow, an outbound connection to somewhere it should not go.

A network denial-of-service attack against a blockchain node is not that kind of event. Its harm is CPU spent on a cryptographic handshake, memory consumed by concurrent protocol streams, or bandwidth burned serialising an oversized response. What drives it is the rate, the volume, and the frame-level detail of traffic arriving on a port the node deliberately exposes. The question is whether any of that reaches the syscall boundary in a form a rule can act on. Technique by technique, it does not.

The detection surface

Be exact about what a syscall-layer engine sees for network activity. The list is short:

evt.type, the system call itself: accept, connect, close, read, write, sendto, recvfrom.

The fd.* five-tuple for a socket: fd.sip, fd.sport, fd.cip, fd.cport, fd.l4proto. Who connected to whom, on what ports, over TCP or UDP.

evt.res, the return value of a read or write, meaning the number of bytes moved by that one call, or a negative errno.

Process and container identity, proc.* and container.*, to attribute the event to a workload.

That is the whole surface for network behaviour. Everything below asks what these fields can reconstruct about an attack whose mechanism runs above them, and what they cannot.

Three structural limits

Three properties of this vantage point carry the argument. They are not gaps you can patch. They follow from observing at the system-call boundary.

No counting, and no time windows

Falco evaluates each event on its own. A rule condition is a boolean expression over the fields of one syscall. There is no operator for "N events in T seconds", no per-source counter, no sliding window in the condition language. You can write a rule that fires on one accept. You cannot write one that fires on the fiftieth accept from a source IP in the last second, because the rule has no memory of the previous forty-nine.

Rate and volume detection has to move downstream to a metrics backend, say Prometheus with an alerting rule. At that point it is metrics alerting, not a syscall rule, and it has been flattened to a coarse count that no longer carries the per-source, per-connection attribution needed to name a technique. Almost every attack here is defined by rate or volume, so this one limit rules most of them out before any protocol detail matters.

No CPU field, and no reliable live memory

The fields describe the syscall and the process that made it. They do not describe what that process is consuming. There is no process-CPU field and no reliable per-event memory-growth (RSS) signal. You can see that a socket was accepted. You cannot see that servicing it cost 40 ms of elliptic-curve arithmetic, or that resident memory just grew by 200 MB.

For the two techniques whose harm is CPU burn or memory growth, the harm is exactly the quantity the fields cannot express. The attack is invisible not because it hides, but because the instrument has no dial for it.

No protocol parsing, and the bytes are encrypted anyway

Falco captures at most the first snaplen bytes of a read or write buffer, 80 by default, and it...