# Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario
## 5 Test Bed  
In order to validate the efficacy of the threat introduced in Section 4, we built a setup representing a full ROS-powered network. Overall, the test bed being presented and used to conduct and analyze the slow DoS attack is meant to represent a simplified, but still realistic, implementation of a typical industrial production line.  
As shown in Figure 5, it consists of five nodes interconnected by means of a 100 BaseTX shop-floor network, depicted as a green line. This network emulates a local plant network; its IP addresses are assigned statically and lie in the same /24 subnet. More specifically, we have the following:  
* Node alice, depicted on the right of the figure, is an Interbotix PincherX-100 robot arm (4 DOF plus gripper) controlled by an 8 th Gen Intel NUC equipped with the Interbotix-provided distribution of Ubuntu 20.04 and ROS noetic. It corresponds to one of the regular ROS nodes depicted on the right side of Figure 4. The NUC runs the ROS joint control software and, possibly, additional ROS applications that implement any local robot arm control algorithms needed by the application at hand.
* Nodes alpha, bravo, and charlie are also regular ROS nodes, based on Raspberry PI 3 model B boards equipped with an off-the-shelf distribution of Ubuntu 20.04 and ROS noetic. They run ROS code that performs various higher-level system coordination and supervision functions. According to the guidelines presented in [51], alpha also hosts the centralized ROS Master and parameter server shown in the middle of Figure 4, which all ROS nodes query as described in Section 3. Node charlie is the malicious node that conducts the slow DoS attack. In our scenario, we assume this node has been compromised in some way to act malevolently and implement the attack sequence summarized in Figure 4.
* The gateway shown at the far left of Figure 5 grants external access to the shop-floor network, for instance, through a wired or WiFi connection to a plant-wide SCADA or MES network. This node usually incorporates a firewall that protects the shop-floor network from unauthorized access, while still allowing control and supervision traffic  
Figure 4: Sequence diagram of the attack scenario.  
to pass through. For instance, a SCADA system might obtain access to robot arm operating information and statistics by means of an OPC-UA/ROS software gateway installed at the shop-floor boundary, or use ROS directly for the same purpose. In the example attack described in this paper, the gateway represents the entry point leveraged by the remote attacker to inject malicious software into node charlie.  
In the specific test bed version used in this paper, the ROS Master is implemented by means of the off-the-shelf rosmaster process found in the ROS noetic distribution. The joint control software running on alice is the robot_state_publisher application provided by Interboix with the robot arm, whose communication functions to the ROS Master are also based on unmodified, lower-level software libraries from ROS noetic.  
The high-level ROS application (also running on alice) is simulated by a Python application, derived from one of the ROS examples, which drives the gripper through a closed Cartesian trajectory in space indefinitely, until stopped by hand. Finally, system coordination and supervision functions are simulated by a telemetry application based on the standard rostopic tool, which runs on bravo and periodically reports the joints' position, velocity, and torque.  
This rather conservative approach is meant to realize a \"minimal working example\" of the vulnerable industrial system and guarantees that neither application-specific nor vendor-specific code is involved in the communication between the ROS Master and the rest of the ROS software. This aspect will turn out to be crucial to ensure that the attack discussed in Section 4 does not depend on the specific test bed in use or any custom software that runs on it, and can hence be exploited on a variety of ROS-based systems.