# Mitigation against DDoS Attacks on an IoT-Based Production Line Using Machine Learning
## 4 Discussion  
In order to track the traffic, it is possible to consider larger infrastructures. Testing was performed with two switches that generated a sampling rate. The sampling rate was sent over a different subnet to the sFlow Collector, which streamed the data for processing into the Spark application. Spark application generated a REST call. The connection of the verified production line is shown in Figure 9.  
The production line is connected with two switches. Network switches are in the role of an sFlow agent. Network traffic created during the production process is sampled and delivered to the NetFlow collector. Network samples are transformed from UDP sFlow packet into the normalized format by an application written in Python. Data are formatted and stored into CSV structure and in parallel streamed to the prepared socket where Spark is expecting input data. Data is transformed and Spark is using a trained model and doing classification of samples. If traffic is detected with attributes as an attack, Spark is sending REST call to Node RED and it is sending requests to network switches to block  
Figure 8: Reaction time for attacks. Figure 7: Node RED provisioning. communication and sending a notification about it. There is a possibility to create a lot of actions and make a strategy of protection, which can be complex according to architecture and security policy. The process of evaluating network communication and predicting the correctness of packets has to ensure the blocking of dangerous network data flow until other devices are operational. The critical time, as measured in the experiment, is 14 s, as seen in Figure 5. A sample sFlow, data acquisition, transformation, neural analytics, and provisioning must therefore be completed before devices' communication capabilities fail and they need to be restarted. The sFlow itself is delayed as the sample needs to be prepared and then loaded. However, DDoS and DRDoS attacks generate so much data traffic that, in this case, sFlow appears to be a convenient data source. The transformation of sFlow into readable data is fast and not performance-intensive. The data submission and evaluation by Spark are a critical part, and they are suitable as one of the tested parameters of the proposed solution. It is necessary to define the start and end times of the evaluation operation. Similarly, timestamp generation was applied during each possible operation in the provisioning count. During testing, the value was reached without much difficulty in less than 2 s from the start of the DDoS attack until it was blocked. This time was achieved with sFlow, which had a sampling rate set to 1 s. Machine learning was run in the local Spark installation on the local network. This was because Spark is intended primarily for big data, and a greater amount of data needed to be evaluated. The solution for IoT devices is aimed at testing the possibility of evaluating DDoS and DRDoS attacks, which produce a large amount of data traffic, and to verify the possibilities of big data techniques in evaluating network communication from the point of view of security. This ensures easier expansibility and scalability of integration in larger production lines, and the solution can be applied outside the IoT equipment and can also provide a sufficiently adaptable solution. On the other hand, if the goal is to make the solution simple, the part that is implemented in Spark can be replaced by a modified implementation. The provisioning part was selected for its easy implementation and possible adaptation, which is required according to the comprehensive security design and the security rules of the company. The volume of data that can be processed far exceeds the amount of data that is generated from network traffic by the sFlow protocol. The samples themselves do not carry information about the data but quantify ongoing network communication.