A new approach of scalable traffic capture model with Pi cluster

ABSTRACT


INTRODUCTION
The invention of the internet of things (IoT) has reduced users' workload in various sectors through the embodiment of simple processing and communication capability.Devices connected to the internet can be monitored and controlled easily by their users, anywhere and anytime.These devices are connected and communicate with a wired or wireless network and are equipped with better processing capability to handle many scenarios.These devices are called single board computers (SBC), with better processing time than the microcontroller-based device.In addition, this device has an operating system installed which eases the operation and management.IoT, which increases productivity, is suitable for many situations such as homes, offices, and industries [1].This technology is applicable in many situations such as inventory management, production, logistic, retail, and resulting many industries utilize it in their system [2].However, the available devices are vulnerable to outside attacks [3], with most intrusions launched in specific protocols, such as transmission control protocol (TCP) and internet control message protocol (ICMP).These protocols have layer-specific network attacks that require a detection system [4].
SBC can be equipped with the intrusion detection system (IDS) to detect any intrusion targeting the IoT devices with either signature [5] or behavior-based detections [6].This device monitors any information that flows within the network and analyzes it for intrusion possibilities.However, its difficulty lies in the typical capture method, as most intrusion detection systems such as Snort are limited in monitoring capability.The system is only limited to a single network interface to detect intrusions with snort used to run several processes to monitor multiple network interfaces have lower efficiency.Figure 1 is the current traffic capture model.The most common traffic capture model consists of one network interface managed by the system found within a network and stored in the data set [7].Several studies focused on efficient packet capture and found that the model benchmark is capable of storing packets with 120 Gb/s speed [8].High-speed network packet capture has also been verified to understand the efficiency.Linux packet capture's traditional approach is limited only to the rate of packet capture, resource usage, and principles [9].Some studies also proposed using Moloch-based packet capture to preserve data for forensics.However, this study found that the method is simpler and less complicated than typical network capture, which poses a problem when big data is included [7].It focused on multi-channel multi-radio attack detection with a proposed algorithm called the cumulative sum algorithm to monitor every network change.A single interface was used to capture traffic within the network by utilizing the WinPcap library also utilized a single interface instead of a multi-interface [10].Although the proposed method can capture traffic, it has some defects, such as the limitation of a specific operating system [11].
Security is a serious matter in IoT, specifically when the device is open to the public.One of the risks is service disruption caused by denial of service (DoS) attacks [12].The signature-based intrusion detection system is one of many proposed systems that use a list of intrusion characteristics.Several studies made wireless sensor networks detect intrusion wirelessly by implementing IDS and reporting mechanism through message queuing telemetry transport (MQTT) protocol in the Raspberry Pi device.The previous model has capabilities to sense, predict and prevent DoS attacks in the network.Meanwhile, the other model added encryption to the IDS database for better security by using a single communication channel to detect intrusions [13], [14].
Most studies only utilized a single interface inside the device to capture traffic within the network.However, this type of model has some weaknesses, such as being capable of capturing one wireless network only, with the addition of one or more devices to solve the problem.This increases the workload to compile the data, with device controls managed separately by the user, without using efficient hardware resources for the same workload.Figure 2 explains how adding extra devices or processes can increase the workload for data compilation and further data analysis [7].The current model monitoring capability is limited to one interface, with the occurrence of network intrusion in any existing network.In this situation, the current model cannot detect intrusions in the networks.Unmonitored connections become an easy target for the third party to attack and destroy data inside the company system.Besides, the inefficiency of the current model may cause several problems, such as the rise in the cost of network security and the workload for analysis.
Due to these reasons, this study proposed a new approach as the novelty by improving the current model by adding simultaneous network traffic capture with two or more Raspberry Pi computers.Unlike the previous models that only utilized one hardware, the proposed model relied on a cluster computing concept where many Raspberry Pi communicate with each other to solve a complex task known as Pi cluster.The proposed model can monitor multiple networks with a scalable feature and add more hardware to increase the capture capacity.

THE PROPOSED METHOD
This section explains the proposed method used in the study, which consists of several parts, such as the network topology, the proposed algorithm of the model, and the evaluation method.The network topology explains the inter-device connectivity, such as the type of device, its role, and the communication protocol used in the network.The proposed algorithm explains how the model captures multiple traffics in the network while the evaluation method evaluates its performance.

Hardware specification
The proposed models were determined using one Raspberry Pi Zero W and three Raspberry Pi 3B plus.The Raspberry Pi Zero W specification is a 1 GHz single-core CPU, 512MB of RAM, wireless network, and ethernet HAT module through GPIO and micro USB data port.This computer act as a master device in the proposed model, while the Raspberry 3B plus is a 1.4 GHz quad cores CPU, 1 GB of RAM, dual-band wireless network, ethernet, and USB modules.Besides, this study builds one isolated wired network and an open wireless network.All hardware has 32GB of micro USB installed as storage.The official Raspberry Pi OS was also installed into the operating system of a desktop containing Python 3, with additional libraries such as pyshark (network capture), psutil (performance benchmark), mpi4py (message passing interface wrapper), and OpenMPI.

Network topology
This study proposes a simultaneous network traffic capture model with multiple IoT devices.This model used many devices compared to previous models that used a device to capture traffic networks.With this configuration, it is possible to capture traffic from several network connections with a single instruction [15].To make this model work, it must have a single master and several worker devices, which handles the process control and perform capture process, respectively.
Figure 3 explains the topology model of multi-interface and multi-device traffic captured where master IoT managed three worker devices.In this study, the master device is assigned as a process manager to control the running processes in each Worker device.It sends a query to store the captured data in the database server, which receives data from the capture process.This eliminates the data compilation process with the communication between the master and worker devices using open message passing interface (OpenMPI) through Python [16]- [18].This interface spreads processes according to the allocated device processors available in the system before the commencement of the capture process [19].According to preliminary studies [18], [19], the capture effectivity increases by running multiple processes in parallel limited to one wireless network interface.The topology requires properly implementing an algorithm and running inside the device.This algorithm allows interface control for each connected device and compiles captured traffic data into one.

The proposed algorithm
The proposed algorithm copies the concept of single intrusion multiple data (SIMD), where a single instruction can operate multiple devices to process several data.This study tries to achieve this by implementing a message passing interface (MPI) protocol into the models.With this protocol, the master device can instruct numerous devices to capture multiple networks simultaneously [20], [21].Figure 4 illustrates the SIMD concept with MPI.
Figure 4 explains how the algorithm manages the traffic capture process using one master and many worker devices.The algorithm was unable to differentiate the master from workers.Therefore, this study configures the rank assignment manually through a machine file.It listed the master device as the first, which is ranked zero (0) in the model, while the remaining follow suit (rank>0).This ranking system helps this ISSN: 2088-8708  A new approach of scalable traffic capture model with Pi cluster (Kristoko Dwi Hartomo) 2189 study assign a role in the algorithm, which decides what process to run with the master and worker devices ranking 0 and > 0. The process control in the master device monitors contains warning and error information for the users to carry out the termination commands.The master device will monitor MPI Abort flags when triggered by the worker process.When the user aborts the process, the master device sends a termination command to all running processes.In the worker devices counterpart, the process started by initializing the wireless network interface for packet capture.Furthermore, this algorithm runs a loop that monitors the MPI abort flag by fetching an IPv6 packet from the network interface for further data extraction.The process continues to extract the captured data to filter TCP and ICMP protocols.When the captured packet has TCP protocol, the process extracts its parameters, such as the source and destination addresses, protocol, source and destination ports, sequence packet, window size, and payload as TCP characteristics.However, when the captured packet is an ICMP packet, then the algorithm extracts the source and destination addresses, protocol, ICMP type, and data.The result of all processes queried to the database for long-term storage, and at the end of the loop, the algorithm monitors the MPI abort flags from the master device and terminates the process.Meanwhile, the communication exchange between devices must be separated using the Ethernet network interface connected to a local area network to avoid capturing performance degradation and communication interruptions during the process.Compared to the typical traffic capturing model, the proposed model has several advantages like centralized process control, support scalability with more than two devices, simultaneous capture of different wireless networks, and single data set compilation.

Model evaluation and validation
This study evaluates the algorithm's efficiency of IoT by comparing the proposed model with a typical traffic capture model.The evaluation process includes performance benchmarking by configuring experiments to obtain the right data [22]- [24].In this experiment, the intruder attacks three wireless devices by flooding them with TCP and ICMP packets simultaneously.These devices receive attacks and store them in the database server using the querying method.Every captured process in each model records specific benchmark data stored in its memory called unique set size (USS) in megabytes [25], CPU usage, and execution time.These benchmark indicators are Linux-based performance accessible to the users and suitable as evaluation parameters.The internal performance of IoT boards also plays a role in the capturing process, while the network performance has many external factors.Therefore, the internal board performance is selected as evaluation parameters [26], [27].The execution time explains how fast the model captures a packet, which also helps to calculate the rate of the model, as shown in (1).
As shown in (1) calculates the capture rate by dividing the total numbers of the captured packet by the sum of execution time in seconds, where 1 millisecond is equal to 1e-3 second.The result of this calculation is useful for determining the capture rate of both models.Before the experiment started, this study made two hypotheses based on benchmark indicators, as shown in Table 1 The hypothesis above is used to decide whether the scalable model utilized more hardware resources than the non-scalable and vice versa.The X values obtained during the experiment are the benchmark indicators, such as USS, CPU usage, and execution time.The benchmark result alone is insufficient to provide evidence for the evaluation.Therefore, this experiment uses the independent left-tailed test.This study used (2) to obtain the t value and the critical data according to the student's t-table.This independent left-tailed test helps the validation process of the proposed model.
The equation of the independent one-tailed test consists of several parts, which calculate the sum of the squared values, data size, mean, and the sum of squares.The first step to obtaining the independent test value denoted as t is subtracting the scalable model's mean ( ̅ 1 ) from the non-scalable ( ̅ 2 ).The  1 +  2 in the lower part of the equation, refers to the addition between the sum of the square of the scalable ( 1 ) and the non-scalable ( 2 ) models.Let  1 +  2 − 2 be the degree of freedom between and pooled standard error ( ) set to the number of the scalable ( 1 ) and the non-scalable ( 2 ) model data.The t value is obtained by dividing the subtraction of the mean in the upper equation with the square root of the product in the lower equation.After obtaining the t value from the equation, the t critical value is determined using the student's t-table with an alpha value of 0.05.When the value of t is outside and within the t critical value, the hypothesis is accepted and rejected, respectively.

METHOD
The experiment process has specific configurations to ensure that the model is reproducible with fair evaluation benchmark results.The first step is configuring the topology because, without proper network connectivity, the experiment process will not run as intended.Figures 5(a The evaluation process was carried out using a benchmark with high-performance computing systems [24], [28], [29].The model's evaluation is an experiment with a total of four Raspberry Pi boards and one computer.The master and workers handle process spawning and capture the traffic while the database stores data.The computer acts as the attacker on the boards, while the master is assigned to a singlecore Raspberry Pi since the device only needs to spawn processes.Meanwhile, the workers are three Raspberry Pi 3Bs with four logical processors, which have a better computation process than the master and are suitable for capturing process.The database is also assigned to the last worker to handle data compilation and storage [26], [30], [31].Since the master device is headless, remote access is required to start the capture process.The next step is to build links and communication between devices by connecting all boards to an isolated local area network to ensure undisturbed master-to-workers and workers-to-database communications.After the internal network setup, the three worker devices and the attacker's computer are connected to a wireless network with a maximum speed of up to 4.6 MB/second for single-channel communication.Therefore, when used concurrently between devices, each can utilize the channel with an average speed of 1.17 MB/second.The typical model does not have a controller to manage the devices, hence, each capture process acts independently without interference.Figure 6 is the physical installation of the proposed model: According to Figure 6, the proposed model consists of a 5-ports switch, a wireless router, and the proposed model.The model has one master node on the rightmost and three worker nodes on the left.Since the model only needs three worker nodes, this study leaves the leftmost node turned off and not connected to the local area network (LAN) network.Each node connects to the switch and forms an isolated LAN network through a wired cable.Besides that, the nodes connect to the wireless network through a wireless router on the right side like Figure 5(a).
After the topology setup, the next step is the configuration of the experiment scenarios, which explains the flooding attacks and capturing process.This study used two protocols for flooding attacks,

RESULTS AND DISCUSSION
The experiment successfully gathered 3,072 packets for each model, consisting of three benchmark indicators, with the collection comprising several thousand rows used to calculate the average per field.Table 2 contains the average calculation of the sample data separated into two columns, namely scalable and non-scalable models for the proposed and typical models.Table 2 shows that each model utilized hardware resources differently.The USS indicator represented the actual use of the running model during the capture process at scalable and non-scalable values of 18.82 and 14.43 MB USS memory.The CPU usage showed different results compared to previous indicators, with scalable and non-scalable values of 3.07% and 3.22%.In terms of execution time, the scalable and non-scalable models captured packets within 3.07 and 3.22 ms. Figure 7 presents the USS usage gap between both models.
Figure 7 shows that the scalable and non-scalable models consumed an average of 18.82 and 14.43 MB of memory.There is an extra 4.39MB memory usage of the scalable model to capture the traffic, despite consuming 30.44% more memory than the non-scalable.This extra memory will not burden the system since most IoT device has quite a large memory to run many processes.Meanwhile, Figure 8 shows the CPU usage comparison models.
Unlike the USS usage counterpart, the CPU usage between models in this experiment is similar.Figure 8 shows that the scalable and non-scalable models only used 10.79% and 12.65% of average CPU usage.There is a 1.85% gap between both models, but the scalable result is lower because it consumed 14.66% less CPU, which is more efficient for the IoT device.Furthermore, high CPU usage produces higher temperatures capable of damaging the board without cooling equipment.Both benchmarks affect the execution time of the model, Figure 9 shows the execution time comparison between both models.
According to the result, the scalable model can capture 15 more packets than the non-scalable due to its ability to increase the capture rate by 5%.This means that the proposed model provides better performance than the former.Therefore, this study utilized an independent left-tailed test to determine and give more evidence of whether the scalable is more efficient.
The independent left-tailed test results in Table 1 will decide whether the hypothesis for each indicator is accepted or rejected.Table 3 shows that the USS indicator hypothesis is accepted in the scalable model because it has more memory than the non-scalable due to the storage of cluster information MPI.The scalable model holds cluster information to recognize and communicate with the rest of the devices.Every process running in each device of the scalable model carried the device's sequence (rank), the size of the total available logical processors, and the hostname.Meanwhile, the non-scalable model did not carry this kind of information in its process because it lacked adequate memory.The CPU and exec time benchmark result also rejected the null hypothesis.
Since the t-statistic is lower than the t-critical one tail test, the alternate hypothesis process was used.The scalable model utilized less CPU, less power, and a faster packet capture process than the non-scalable.Since the scalable model spreads its process to several allocated logical processors, the needed processing power is lower.The non-scalable model relied on the device's system to allocate the process to available logical processors.In terms of execution time, the non-scalable model runs a bit slower than the scalable.The system processor management might affect the non-scalable execution time to run a specific process in a particular logical processor.Based on the hypotheses' overall results, this study concluded that the scalable model is more efficient in processing power than the non-scalable.Although the scalable carried more data in its process, it held necessary cluster information to ensure the master and workers' devices communicate properly.

CONCLUSION
The experiment results for both scalable and non-scalable models showed that the scalable model utilized 30.44% more USS than the non-scalable.However, the scalable model held necessary cluster information in its process to ensure master-to-workers communications by using 14.66% less CPU.In terms of execution time, the scalable model executes 3.63% faster than the non-scalable, which benefits users due to its ability to capture and analyze traffic without hindering the board's performance.Besides, users can obtain more data quickly from different networks than in the non-scalable model.
This model allowed the network interface to work separately under a single master device command.At least two single-board computers capable of processing are required to make this model work properly.Despite its ability to capture more data, some weaknesses are considered, such as the need for additional swap space to capture more data, vital communication between devices, and disruption due to accidental disconnection.The network interface is limited to one logical processor's core only.Further studies need to improve more capturing capability, such as writing the proposed method with a programming language close to machine language (C++), implementing in more modern IoT devices, expanding the capture varieties to many network protocols, adding intrusion detection capability for a more secure network, and multi wireless network interface in each device management to capture more significant traffic.

Figure 1 .
Figure 1.The current traffic capture model

Figure 2 .
Figure 2. Data compilation process in the current model

Figure 5 .
Figure 5. Topology comparison where (a) is the proposed model, and (b) is the typical model


ISSN: 2088-8708 Int J Elec & Comp Eng, Vol. 13, No. 2, April 2023: 2186-2196 2192 namely ICMP and TCP, with a simple shell script written to spawn flooding attacks simultaneously toward the target.The script can shorten the attack spawning time with the help of the experiment process.The first scenario is to test the proposed models with flood attacks, while the second examines the previous model.The result from each scenario contains benchmark data for further analysis.

Figure 6 .
Figure 6.The USS usage comparison

Table 2 .
The Benchmark result comparison summary

Table 3 .
The independent left one-tailed test result