Research checkpoint #10: simulating a DDoS attack against a Raspberry Pi

This series of tests evaluating the Raspberry Pi with Python sniffing libraries started in post 06, where I tested the performance of this device handling our baseline machine learning models; in post 07 and post 08 I explored it’s capabilities dealing with network traffic, utilizing different Python libraries; and, finally, in the last post I expanded these last tests verifying if the packet length affects the performance of the libraries we are dealing with. Concluding for now our tests, in this post I simulate a DDoS (Distributed Denial of Service) attack to analyze how the Raspberry will handle with an intentional volumetric traffic.

Simulating a DDoS attack

To create this simulation I used netwox, a set of different tools that allows testing in the context of computer networks, for example, the simulation of attacks. For our tests here, I used a SYN flood attack, in which the target receives a large amount of SYN packets from different sources but never receives the response of them to finalize the TCP three-way handshake and establish the connection, i.e., the corresponding ACK packet. The script I used to perform this test is available here. Its procedure is:

• Run the Python sniffer script in the target computer, that is configured to sniff the network traffic for 50 seconds;
• Wait 10 seconds;
• Start the attack, running it during 10 seconds;
• Stop the attack and wait 32 seconds;
• Check if the Python sniffer script has ended its execution.

This same procedure were executed five times in localhost (in which the Raspberry Pi is both the attacker and also the target) and also with a remote attacker (in which the Raspberry Pi is the target and my personal notebook the attacker). The computers were connected directly through an Ethernet cable CAT 5e, without access to the internet. Their specifications are:

• Raspberry Pi Model 3 B
  • Quad Core 1.2GHz Broadcom BCM2837 64bit CPU
  • 1GB RAM
  • Debian GNU/Linux 12 (bookworm) OS
  • 100 Mbits/sec network interface card (Fast Ethernet)
• Acer Aspire 3 A315-41-R4RB
  • AMD Ryzen 5 2500U 2.0GHz 64bit CPU
  • 12GB DDR4 2667 MHz RAM
  • Fedora Linux 41 (Silverblue) OS
  • 1000 Mbits/sec network interface card (Gigabit Ethernet)

The Python sniffer scripts are available here. The Python libraries used to sniff the network are the usual: Pyshark, Scapy and Pypcap + dpkt. The metrics analyzed below were measured using the Python psutil library for CPU consumption and the Python resource module for memory. More details about their usage can be found in post 07.

The netwox application produced packets with small sizes, around 54 bytes each. In the remote attacker case, I also used the Wireshark application on my notebook to count how many packets were traveling on the local network, to serve as a reference value. I didn’t do the same in the localhost case to not interfere with the Raspberry Pi performance.

Here are the collected results:

Test	Use of CPU (mean)	Peak of memory use (max)	N. of packets counted (mean)	N. of packets counted by Wireshark (mean)
Localhost Pyshark1	79.08%	27512 KB	2483.8	-
Localhost Scapy2	20.50%	67608 KB	5001.8	-
Localhost Pypcap + dpkt	19.32%	21204 KB	98069.6	-
Remote server Pyshark	77.60%	27904 KB	2285.2	627471.2
Remote server Scapy	19.72%	67480 KB	3344.2	630071.4
Remote attacker Pycap + dpkt	18.06%	21204 KB	73474.6	631650.2

The difference in the number of packets counted through the libraries is very expressive, with the duo Pypcap + dpkt counting more than 20 times the numbers reported by Scapy and Pyshark. This can be seen more clearly in the graphic below, which also plots the standard deviation of the sequence of repetitions:

Comparison of the number of packets counted by each script.

However, note that in comparison with the reference number reported by Wireshark in the remote attacker case, even the total number of packets counted by Pypcap + dpkt is still low. In the graphic below, each of the colored horizontal lines represents the average of the packets counted by Wireshark over the five repetitions with the corresponding library in the legend.

Comparing the number of packets counted by each of the libraries with the reference number reported by Wireshark.

In my understanding, this conclusion is quite reasonable: the volume of packets is very high, it isn’t expected that the libraries will be able to handle all of it considering the resources we have at our disposal with this kind of device. Also, as discussed in another post, this isn’t the ordinary scenario with which they will have to handle. Thinking about it in the context of an IDS (Intrusion Detection System), a central topic of this research, a volume like this one is an anomaly that clearly indicates an DDoS attack if seen in an IoT (Internet of Things) device. However, this test is still interesting to verify the limits of each library and how this affects the use of CPU and memory, as we will study below.

Also interesting to observe that the libraries had a better performance in the localhost scenario than in the one with a remote attacker. Naturally, and as observed in the tests from the last post, the maximum bit rate that can be handled by the localhost interface is superior than the limit in the Ethernet, which would justify a worse performance in the first scenario. But the results indicates the opposite from what I was expecting, and as we don’t have the Wireshark reference for the localhost tests, it’s hard to affirm that there is a significant difference in the volume of flow between the cases.

Scapy, different from what we saw in the test with 5 Mb/sec with 48 bytes/packet in the last post, achieved its plateau. The number reported in that post is another behavior that isn’t accordingly to what we would expect, as here the volume of packets is very high and Scapy presented its usual performance.

The graphics below compares the CPU and memory usage over the libraries using the values reported above.

If we compare the numbers observed here with the ones we saw in post 08 when we analyzed the results of the Python sniffing scripts with different bit rates of the network traffic, they are very similar with the cases with unlimited rates, with few variations in the values. This might indicates that the tests there were almost DDoS attacks against the Raspberry Pi.

Scapy, one more time, presented a high usage of memory in comparison to the other libraries, which are more close. Thereby, the memory usage isn’t a metric that we can expect to suffer variations during a normal and an anomalous traffic. The differences between the localhost scenario and the one with a remote attacker are also not very expressive.

In CPU usage, on the other hand, the libraries had a slightly improvement in the scenario with a remote attacker when compared with the one in localhost. This is curious considering that the libraries counted more packets in the localhost tests. However, looking at the reference number produced by Wireshark in the second scenario, it’s clear that all the three had difficulties to handle all the traffic, which leaded to this high CPU consumption, which is the main observation to consider here.

Next steps

With this post we conclude for now our tests in the packet parsing context. As defined in post 05, our current goals are:

• Packet Parsing
  • Conduct experiments to verify the performance of Python libraries sniffing the network and processing the packages in a Raspberry Pi (different from what we did in post 4, in which we tested the lib’s with the CIC-IoT-2023 dataset and in a regular computer).
• Inference
  • Run the baseline models proposed in post 02 in a Raspberry Pi to verify its performance.
• Training (centralized IDS)
  • TBD.

This post was made as a record of the progress of the research project “DDoS Detection in the Internet of Things using Machine Learning Methods with Retraining”, supervised by professor Daniel Batista, BCC - IME - USP. Project supported by the São Paulo Research Foundation (FAPESP), process nº 2024/10240-3. The opinions, hypothesis and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of FAPESP.

1. In the final section of post 08, I observed that Pyshark was counting more packets than expected due to a tshark plugin. For the tests here, I deleted the script that was causing this behavior (androiddump), not being anymore a concern. ↩

2. Also in the final section of post 08, I reported that Scapy was counting each packet twice in the localhost tests, this is an expected behavior. However, in the tests performed here, this didn’t happened throughout the entire duration of the test. In my observations, the library duplicated the first packets in the network traffic, but after some point it stopped to count them twice and I couldn’t figure out the exact reason behind this. So, I decided to keep here the number reported by Scapy, even considering that it contains some duplications. ↩