# Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario
## 7 Countermeasures and Protection  
If we consider the protection from the SlowROS attack discussed in this paper, although the approaches found in the literature and mentioned in Section 2 could be adapted to this aim, a dedicated detection and mitigation system able to protect from the considered threat is still missing. Nevertheless, in Section 6.5 we analyzed how protection systems embedded on many Linux-based operating systems can apply some kind of mitigation, identifying the attack as a SYN flood attack. Although the mitigation could be effective to protect from specific executions of SlowROS, we demonstrated that a malicious user could still fine-tune the attack and slow down the connection establishment procedure by means of specific delays (i.e., \(T_{\text{SYN}}\)), thus bypassing the restriction. As an additional benefit, such an approach would also lead to a reduction in the attack bandwidth. In other words, since the protection can easily be circumvented by the attacker, it should not be considered an efficient countermeasure. Other protection approaches may filter network connections through dedicated firewall rules, embedded on the targeted host or on an intermediary firewall. To this aim, it is possible to use tools like Iptables or nfw [55] to block single node attacks, by limiting the number of concurrent connections a single node is allowed to establish with the server [56] and forcibly closing open connections, regardless of the server-side timeout settings described in Section 6.2. Such an approach is effective to counter slow DoS scenarios, even though it it may be ineffective against distributed attacks and artificially reduce server capacity. Indeed, in such a case, the attacking group of nodes may not be sufficient, in terms of the number of attacking bots, to lead a denial of service on the victim. Another mitigation option may involve the implementation of a server-side timeout, used to close connections that do not respect minimum bandwidth requirements. Such an approach is implemented, for instance, by the reqtimeout module for the Apache web server [57]. By following this direction, let \(B\) be the bandwidth required for a single connection. During a flooding-based attack, \(B\) is supposed to assume particularly high values. On the contrary, in a slow DoS scenario, \(B\) is extremely low. As normal/legitimate flows are characterized by \"in-between\" values of \(B\), it could be possible to implement a flow-control threshold \(T_{B}^{s}\) that lets connections stay alive only if \(B>T_{B}^{s}\), hence being able to counter slow DoS threats. Typically, such an approach is adopted to implement \(B<T_{B}^{f}\), with \(T_{B}^{f}\) being the threshold used to filter flooding-based threats. Therefore, generally speaking, implementing two lower and upper thresholds \(T_{B}^{s}\) and \(T_{B}^{f}\) may filter anomalous traffic. Nevertheless, identifying proper \(T_{B}^{s}\) and \(T_{B}^{f}\) values may not be trivial, as they depend on the behavior of the underlying network components. In addition, referring to \(T_{B}^{f}\) in particular, accurately defining when to apply the thresholds, in terms of time from the establishment of the connection, may not be trivial as well, as it may lead to temporary denial of service states. Therefore, although such an approach may represent a good choice for web server protection, the identification of an appropriate bandwidth threshold(s) to adopt may be complex, due to the nature of the ROS traffic. In addition, it is important to consider that such an approach may interrupt malicious connections only after the denial of service state has been experienced. Further variants of the mitigation technique may consider the use of dynamic thresholds, varying as a function of the number of currently established connections. Instead, relying on various forms of server-side payload syntax checking is going to be ineffective because, as shown in Section 4, the slow DoS threat described in this paper only transmits legitimate payloads to the server.