Denial-of-Service Impact Evaluation Testbed for Embedded Devices

This repository accompanies the publication “Denial-of-Service Impact Evaluation Testbed for Embedded Devices” and provides artifacts to reproduce the testbed and sample suite used to assess network-based DoS impacts on embedded CPS/IoT devices. It documents a generalized measurement strategy, a device-centric testbed architecture with redundant paths to separate DUT vs. infrastructure effects, and a demonstrator using TRex and an OPC UA-based application including TCP SYN and stateful OPC UA HEL floods.

Current Scope

Section	Description
Testbed	Minimal setup; limited deployment automation; time sync for logs and measurement data via NTP; manual TRex console via TRex deamon; small amount of in TRex implemented attacks
Sample application	open62541-based OPC UA server
Roadmap	Attack framework; more sophisticated control element

Testbed

Overview

The testbed separates attack traffic and reference/control traffic over two switches to cleanly distinguish DUT effects from infrastructure effects. The attack device runs TRex to generate stateless (e.g., TCP SYN) and stateful (e.g., OPC UA HEL) floods; a mirror on the attack-path switch allows verification of generated load. Measurement and control are performed from a separate host to avoid interference.

Control & synchronization (current approach)

There is no sophisticated orchestration layer yet. Control is exercised from a central Measurement & Control (M&C) device which:

• runs an NTP server with all test hosts as clients; given the 1 Hz sampling rate and millisecond-level NTP accuracy, this is sufficient for synchronization,
• coordinates runs via remote access to start/stop local daemons for logging/measurement on DUT and client,
• leaves attack execution manual via the TRex interactive console (remote-controllable).

Topology diagram

Network configuration

The network configuration on the respective endpoints should not be left as is, since this can allow for unwanted traffic on interfaces that should be isolated from each other. Thus, add routing and firewall settings to guarantee an adequate network configuration. Here are the configs we used in our sample testbed:

DUT: routes per subnet

sudo ip route add 192.168.0.0/24 dev end0
sudo ip route add 192.168.1.0/24 dev enp1s0

Measurement & Control: isolate experiment subnets

sudo iptables -A INPUT -i enx001c42133ce -s 192.168.0.0/24 -j DROP
sudo iptables -A INPUT -i enp1s0 -s 192.168.1.0/24 -j DROP

TRex configuration & hardware-specific notes

TRex requires NIC- and platform-specific settings (PCI addresses, MACs, CPU pinning). Use the official guide to install and generate a baseline config, then adapt for your hardware: TRex manual (install/config): https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_download_and_installation

Sample configuration files are provided in the repo for orientation (adjust to your NICs/MACs/CPU layout before use):

• Stateless (STL) mode: configs/trex/trex_cfg_stl.yaml
• Advanced stateful (ASTF) mode: configs/trex/trex_cfg_opcua.yaml

Sample Application

• Overview: The sample app is an open62541-based OPC UA server (10 nodes with read/write callbacks) running on the DUT; a Python client cycles through the nodes at 1 Hz to record QoS metrics under baseline vs. attack conditions (per the publication).

• Servers (code):

  • Attacked-path server (default endpoint opc.tcp://192.168.0.3:4841): sample-app/server/opcua_server_attacked.c
  • Reference-path server (default endpoint opc.tcp://192.168.1.3:4842): sample-app/server/opcua_server_unattacked.c

• Build: sample-app/server/Makefile (uses pkg-config for open62541).

  cd sample-app/server && make

Measurement Client

• Attacked-path client: sample-app/client/opcua_client_attacked.py (endpoint opc.tcp://192.168.0.3:4841)

• Reference-path client: sample-app/client/opcua_client_unattacked.py (endpoint opc.tcp://192.168.1.3:4842)

• What it does: Iterates over SampleNode0..9 once per second, performing write→read cycles and logging per-operation metrics (timestamps, value written/read, WriteDuration(ms), ReadDuration(ms), RTT(ms), Match, Request/Response rate).

• Outputs:

  • opcua_client_metrics_attacked.csv
  • opcua_client_metrics_unattacked.csv

• Dependencies: Python opcua (freeopcua).

  pip install opcua

Other Scripts

• System metrics logger — scripts/logging/log_system_metrics.sh Logs CPU (per-core & aggregate), software CPU interrupts (SCPU), memory, and temperature at 1 Hz into cpu/, scpu/, memory/, temperature/. Requires sysstat (mpstat).

  sudo apt install -y sysstat

• DUT hardening (iptables rules) — configs/dut/iptables_rules.sh Curated baseline rules for rate-limiting and dropping malformed/suspicious traffic on the DUT (connlimit, RST limiting, invalid state, spoofed sources, etc.).

  # Appliccable to iptables (might need syntax changes for other systems such as e.g. nftables):
  sudo bash configs/dut/iptables_rules.sh

  Background reference (inspiration for the configs): JavaPipe DoS protection guide (archived): https://web.archive.org/web/20240304123353/https://javapipe.com/blog/iptables-ddos-protection/ Notes: Adapt thresholds to your environment; test offline first; consider persistence (e.g., iptables-persistent) and verify that rules don’t block your control channel.

• DUT hardening (sysctl tuning) — configs/dut/99-custom.conf System-level tuning for queues, buffers, conntrack, SYN behavior, and TCP defaults (e.g., somaxconn, netdev_max_backlog, nf_conntrack_*, tcp_max_syn_backlog, keepalive, ECN). Apply via sysctl on your DUT.

Sample Attacks

1) TCP SYN Flood (TRex STL)

• Profile: scripts/attacks/syn_attack_paper.py Stateless SYN flooding against the DUT’s OPC UA port (4841).

• Invoke (example):

  # on the TRex host
  sudo ./t-rex-64 --cfg /opt/trex/v3.06/dostestbedcfg/trex_cfg_stl.yaml -i
  # from the TRex console, start it with ./trex-console first
  start -f /opt/trex/v3.06/stl/dostestbed/syn_attack_paper.py -m 500mbps -d 60 -p 0 1

  (Adjust config, rate, duration, and port mapping to your setup. If you get data from TRex but cannot see an impact on the DUT, verify with the mirror on the switch.)

2) OPC UA HEL Flood (TRex ASTF)

• Profile: scripts/attacks/HEL_flood_astf.py Stateful HEL handshake flooding: TRex performs TCP connection setup and sends an OPC UA HEL message per flow.

• Invoke (example):

  # on the TRex host
  sudo ./t-rex-64 --cfg /etc/trex_cfg_opcua.yaml -i --astf
  # from the TRex console, start it with ./trex-console first
  start -f /opt/trex/v3.06/astf/dostestbed/HEL_flood_astf.py -m 10000000 -d 60

  (Ensure ASTF config matches your NIC & endpoints; adjust the scale factor (-m) to your setup and target load.)

Publication & How to Cite

Florian Foerster, Song Son Ha, Henry Beuster, Thomas Robert Doebbert, Gerd Scholl, and Dominik Merli. Denial-of-Service Impact Evaluation Testbed for Embedded Devices. In Proceedings of the 2025 Workshop on CPS&IoT Security and Privacy (CPSIoTSec ’25), October 13–17, 2025, Taipei, Taiwan. ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/3733801.3764197

@inproceedings{Foerster2025_DoS_Testbed,
  author    = {Florian Foerster and Song Son Ha and Henry Beuster and
               Thomas Robert Doebbert and Gerd Scholl and Dominik Merli},
  title     = {Denial-of-Service Impact Evaluation Testbed for Embedded Devices},
  booktitle = {Proceedings of the 2025 Workshop on CPS\&IoT Security and Privacy (CPSIoTSec '25)},
  address   = {Taipei, Taiwan},
  publisher = {ACM},
  year      = {2025},
  pages     = {1--12},
  doi       = {10.1145/3733801.3764197}
}