Proxy Ressource Footprint

by

When it comes to honeypots in the embedded—especially automotive—domain, the proxy-based approach used by the CROWSI framework comes with clear advantages. By shifting the actual honeypot to an isolated backend infrastructure and exposing it through a lightweight proxy on the edge device, we minimize both risk and resource demand at the edge.

Of course, the proxy itself still consumes some resources, and a common question is: how much? This is especially relevant when retrofitting CROWSI to legacy hardware, where often every bit of processing power and memory counts.

In this post, we’ll walk through our standard demo setup and share resource consumption measurements under different scenarios.

Demo Setup

Our demo environment consists of:

  • A running CROWSI backend with multiple decoys (HTTP- and SSH-based)
  • A Raspberry Pi Zero W v1.1 running a native nginx instance

Here’s a schematic of the setup:

The Raspberry Pi Zero W (2017) offers modest specs—512 MB RAM and a single-core CPU clocked at 1 GHz. On paper, this makes CROWSI integration already appear lightweight. But skeptics might argue that the device isn’t doing anything else, making the comparison less meaningful. So let’s put it to the test with actual runtime measurements.

Measuring Resource Usage

We used the Linux tool htop to monitor both overall system resource usage and process-level consumption in real time.

1. Baseline – Proxy Not Running

Before starting nginx, we captured baseline CPU and memory usage.

Unsurprisingly, the device sat nearly idle, with CPU utilization fluctuating near zero and memory usage minimal.

2. Idle Proxy Running

Next, we started nginx—still without any attacker interaction. The snapshot showed:

  • CPU: No measurable increase attributable to nginx (average usage fluctuated as expected).
  • Memory: nginx consumed about 1.1% of total memory, roughly 4.7 MB.

➡️ Takeaway: Under normal conditions, the proxy’s footprint is negligible.

3. Proxy Under Attack

Finally, we simulated real-world load by running two types of interactions:

  1. SSH session to CROWSI decoy – No noticeable changes in CPU or memory.
  2. HTTP directory scan (Gobuster) – This is a common early attacker technique that stresses the target by attempting all possible directory paths, based on a wordlist.

Command used:

gobuster dir -u http://192.168.0.114 -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -b 200

During the scan:

  • Memory usage stayed almost unchanged.
  • CPU usage increased, with nginx worker processes clearly taking the load.
  • System stability remained intact—no crashes, no out-of-resource conditions.

➡️ Takeaway: Even under heavy attack scenarios, the system handles the load gracefully.

Conclusion

Our measurements indicate the proxy generally adds only minimal overhead on constrained edge hardware. In our tests the observed resource consumption was very low, which should allow deployment on most typical systems — so long as those systems are not already operating at or near 100% CPU or memory usage.

  • In normal operation, the proxy’s resource footprint is effectively negligible.
  • Under heavy attack, CPU utilization can increase significantly; in our setup this did not destabilize the system, but that may not hold for already-saturated devices.

Taken together, these results suggest proxy based honeypots like CROWSI are suitable for many legacy and resource-limited devices, providing enhanced monitoring and protection without imposing undue strain. That said, fitting the proxy is not guaranteed to be possible on every device — always assess current device utilization and critical workloads before deploying. However, these measurements and real world deployment example hopefully gives you some guidance.

It’s also worth noting that in this test we used a default installation of nginx, which in the first place is not the most lightweight proxy available. This means that—even with these already low consumption figures—there is still room for further optimization and reduction if more tailored or minimal proxy solutions are employed.

Operational recommendation: deactivate the proxy under critical load

In production, consider adding an operational safeguard that temporarily deactivates the proxy (or reduces its functionality) when the device’s system load crosses a safety threshold. The rationale is twofold:

  • Protect core functionality: If a device has time- or customer-critical features, preserving those should take priority over honeypot telemetry. Disabling the proxy under extreme load prevents the monitoring layer from causing service degradation or failures.
  • Honeypot advantage: An unreliable or intermittently available interface can still be useful. Many attackers interpret instability as a sign of success (they may assume they’ve caused a crash or achieved persistence), and an unreliable interface can feed those misconceptions—potentially encouraging attackers to continue interacting with the decoy and wasting more of their resources.