During a recent audit of an OpenClaw deployment's network telemetry, I observed a recurring pattern of outbound connection attempts directly to raw IPv4 and IPv6 addresses, bypassing any DNS resolution. The destination addresses were not in any pre-approved allowlist and appeared to be randomized within certain netblocks. This behavior was observed from the primary agent process after the initial provisioning handshake.
My initial hypothesis was a potential compromise leading to C2 beaconing or data exfiltration. However, before escalating to an incident, I performed a deeper binary analysis and traced the syscalls. The activity originates from the `claw-netprobe` subsystem, which is part of the IronClaw lineage's network topology auto-discovery.
The purpose is to map egress path constraints and detect any transparent proxies or non-compliant egress filtering by attempting connections to a set of reserved, unrouted, or documentation-only IP ranges (e.g., `192.0.2.0/24`, `2001:db8::/32`). The logic is:
1. **Validate Routing Independence:** Test paths that should be blocked by a properly configured egress filter, triggering alerts if they succeed.
2. **Probe for Leakage:** Ensure no traffic is escaping to non-authorized external networks.
3. **Benchmark Latency:** To known-dropped addresses, establishing a baseline for timeout thresholds.
While documented in the IronClaw architecture whitepaper (v3.1, Section 4.7, "Egress Validation Heuristics"), this behavior is not prominently detailed in the OpenClaw deployment guide. It can easily be mistaken for malicious traffic.
The expected iptables/nftables rules for a hardened egress profile should **explicitly drop** these probes without logging them as alerts. A recommended supplement to your destination-based allowlist is:
```bash
# IPv4 - Drop documentation and test ranges
iptables -A OUTPUT -d 192.0.2.0/24 -j DROP
iptables -A OUTPUT -d 198.51.100.0/24 -j DROP
iptables -A OUTPUT -d 203.0.113.0/24 -j DROP
iptables -A OUTPUT -d 192.88.99.0/24 -j DROP # 6to4 relay anycast
# IPv6 - Drop documentation range
ip6tables -A OUTPUT -d 2001:db8::/32 -j DROP
```
If your threat model requires complete silence on these probes, consider matching on the process's supplemental GID or a network namespace mark set by the agent itself, but that requires deeper integration.
**Question for the forum:** Has anyone else instrumented a more granular method to distinguish this auto-discovery traffic from a true breach, perhaps using seccomp-bpf to filter the `connect()` syscalls based on address families or port ranges? I'm particularly interested in runtime attestation that the calls originate from the signed `netprobe` module and not injected code.
-Jane
Show me the threat model.
Yes, that's the expected behavior for the network egress profiling. You've traced it correctly to `claw-netprobe`. The detail about using documentation-only ranges like 192.0.2.0/24 is accurate, but I've seen it also target a few other netblocks, including some IANA-reserved spaces and, more interestingly, a small subset of randomly generated addresses within the public IPv4 space. This second part isn't just for probing leakage, but to establish a baseline of "normal" connection failure modes versus the specific timeout signatures introduced by certain middlebox configurations.
In a recent deployment, this caused a false positive with a particularly aggressive IDS that flagged the random destination attempts as a port scan. The key was in the syscall pattern - it's a non-blocking, staggered connect-and-immediate-close with a specific SYN packet signature, not a full port sweep. The log annotation was poor, though. The subsystem should tag these attempts in the telemetry stream with a `probe_type: egress_path_validation` field, but I've found that only works if the agent was compiled with the `instrument_network` feature, which often isn't the case for production builds due to overhead.
Exactly. That syscall pattern is a dead giveaway for `claw-netprobe`. The SYN packet has the DF flag cleared and the window size set to 3, which you won't see in a real scanner.
But you're right about the logging being useless. We had the same IDS false positive. The vendor's fix was to add a YARA rule for that packet signature, but that just papers over the core issue: the telemetry needs the probe_type tag. Without `instrument_network`, you're blind.
I've started patching the agent module to at least log the destination CIDR block to syslog. Stops the SecOps panic.
Assume breach. Then prove you can respond.
Totally saw this on my first test cluster. It's `claw-netprobe` doing its thing, exactly like you traced. The logic you laid out is spot on.
The randomized public IP part had me worried about data leakage too, until I realized it's just establishing that baseline for failure modes. It helps differentiate between a straight-up blocked port and a weird middlebox injecting TCP resets.
Have you noticed any correlation with your power draw? My old R720 lab hosts spiked a tiny bit during the probe bursts. Not enough to worry about, just interesting. Might be the non-blocking syscalls keeping things busy.