Studying the Impact of a UDP DoS Attack on the Parameters of VoIP Voice and Video Streams

Abstract

This work studies the hypothesis of whether the UDP DoS attack affects voice and video flows in a VoIP network. It is a continuation of a previous work that studied the same hypothesis, but the VoIP server was under different types of TCP DoS attacks. The studied VoIP platform is the Asterisk FreePBX. A simple IP network model was developed for the purpose of the study. The used platform for the modeling of IP networks is GNS3. The study is conventionally divided into two parts: in the first part, only voice streams are exchanged in the network, and the server is subjected to a UDP DoS attack, and in the second part, only video streams are exchanged in the network, and again, Asterisk is subjected to a UDP DoS attack. The obtained results confirm the results of the previous study—the performance of the Asterisk FreePBX is not affected by the UDP DoS attack. Although the server is flooded with UDP packets, it works and is not blocked, and different types of VoIP calls are realized without problems. The UDP DoS attack does not affect the parameters of voice and video VoIP streams.

1. Introduction

UDP packet flooding is a type of denial-of-service (DoS) attack in which a large number of UDP packets are sent to the attacked server/device in order to overload it so that the attacked device will not be able to process and respond to the sent requests. Unlike TCP, UDP is a protocol where no pre-connection is established between the client and the server before the actual data exchange (packet exchange) begins. When using UDP, no packet loss is detected, and no packet loss messages are sent during the packet exchange between the two devices. Therefore, the use of UDP is characterized by low computational resource utilization and high processing speed. These features make UDP widely used not only for data transmission but also for performing UDP flood attacks. Traditional UDP flood attacks are attacks that aim to occupy as much of the bandwidth/computational resources allocated to the attacked device as possible. During these attacks, the attacker sends a large number of spoofed/customized UDP packets to the attacked device. Typically, these packets are large in size and are transmitted at high speed, causing the connection to become congested or even crash the device. This type of attack now is rarely used, but it still can cause problems due to its simplicity of implementation [1].

Unlike TCP DoS attacks where attackers use TCP SYN packets, in a UDP DoS attack, packets can be fragmented. Fragmentation of UDP packets is used when the size of data transmitted in each packet exceeds the configured MTU of the network. The MTU is the maximum amount of useful information that can be “packed” into a single packet. Each network shall be configured to operate with a different MTU size depending on the pre-purpose of the network. For example, the standardized MTU size for an Ethernet network is 1500 bytes. In Ethernet, it is also possible to use MTU sizes up to 9000 bytes—JUMBO frames—but if the IP network uses PPPoE technology, the MTU size will be automatically reduced to 1492 bytes. Another example: The maximum MTU size for the Wi-Fi standard is 2346 bytes. Again, if a Wi-Fi network is configured with a different MTU, the MTU size of 2346 bytes will be automatically reduced. From what has been shown so far, if the UDP packet is larger than the MTU of the network, it will be dropped or automatically fragmented to a smaller size by the network layer. Therefore, during a UDP DoS attack, the attacker may fragment the packet size of the UDP attack in advance to allow the attack to be successful or disguised as a small MTU packet stream in order to avoid/bypass any defenses. The use of packet fragmentation in a UDP DoS attack can be beneficial in low-speed networks. In this scenario, if fragmentation is not used instead of blocking the attacked device, the entire network where the attacked device is located will be blocked/congested, and the attack will not be successful and may even lead to the attacker being quickly and easily detected. Therefore, UDP DoS attacks with fragmented packets can cause the same, if not more, damage as a simple UDP DoS attack without using fragmentation packets. The goal of the TCP SYN packet is to initiate a connection and receive a SYN/ACK response as a result. Typically, the SYN segment does not contain any data. This packet is small, so there is no reason for it to be fragmented. A fragmented SYN packet is irregular, unnatural and as such suspicious. Therefore, such packets may be intercepted and dropped by the receiving device. Therefore, in TCP SYN DoS attacks, fragmentation is not possible.

Another reason why UDP flooding is more dangerous than TCP flooding is that UDP is a connectionless protocol. This means that there is no need to pre-establish a connection between devices before the data exchange is started. Because of this, a UDP flood (UDP DoS attack) can easily overwhelm the attacked device with spoofed packets.

In VoIP technology, the transmission of useful data (voice and video) is carried out using the UDP protocol. Sometimes, the exchange of signaling information is also performed via the UDP [2,3,4,5]. As it is known in VoIP, the VoIP server is used only for managing the signaling information—creating, maintaining and dropping the calls. No voice or video streams pass through the server; i.e., it does not process them. They are exchanged and processed directly between the end devices (IP phones). But there is another group of VoIP servers where all the information (signaling, voice and video streams) pass through the server and are processed by it. Because of this feature, this type of VoIP server is interesting to subject to research to find out whether the UDP DoS attack affects the parameters of the voice or video streams that are processed by the VoIP server. Asterisk FreePBX is such a type of VoIP server where the voice and video streams from the VoIP calls pass through and are processed by the server [6,7,8,9,10].

This work is a continuation of a previous study that studied the impact of various TCP DoS attacks on the parameters of voice and video streams that are processed by the Asterisk FreePBX [11]. What is new and different in this study is that the Asterisk FreePBX is subjected to a UDP attack because the Asterisk FreePBX uses only the UDP protocol to carry signaling and utility information. Attacking the server with UDP packets will verify if this type of attack affects the performance of the server and the parameters of the voice and video streams.

2. Related Works

In [12], the authors provide an in-depth review of the feasibility of using deep learning techniques for detecting DDoS attacks within VoIP networks. Particular attention is paid to Convolutional Neural Network (CNN) and Recurrent Neural Network (RNN) models. Through an in-depth analysis, the authors examined these approaches on various parameters, focusing on their main strengths and weaknesses. Furthermore, they conducted a study aimed at improving the efficiency and accuracy of these methodologies, thus strengthening the resilience of the VoIP networks against malicious attacks.

In [13], the authors provide a sub-analysis and study of the security and vulnerability of VoIP networks, as well as an analysis of the existing level of network security and its impact on VoIP network performance and voice quality. This work is mainly aimed at Penetration Testers. The attacks considered by the authors are denial of service (DoS) attacks, Registration Manipulation and Hijacking Authentication Attacks, Caller ID Spoofing, Man-in-the-middle attacks, Virtual Lan Hopping, Passive and Active Eavesdropping, Spamming over Internet Telephony (SPIT) and VoIP Phishing (Vishing).

In [14], the authors reviewed various technologies and methods for warning and preventing attacks. The authors discussed various vulnerabilities associated with VoIP as well as tests to detect these vulnerabilities that are used in various VoIP network security inspection tools. These tools are used to detect the weaknesses/vulnerabilities that create security threats and problems in VoIP networks.

In [15], the authors propose a P2P VoIP system in which the management of user data is implemented using distributed blockchain technology. The carried-out research shows that this approach can enhance security and decentralization in P2P VoIP. Additionally, the authors thoroughly evaluate the performance and security of the proposed blockchain, the consensus algorithm and several additional blockchain architectures that will be used to manage this data. The authors’ proposed method offers promising prospects for the future of P2P VoIP.

In [16], the authors carried out research in the area of Syn flood and UDP Lag attack detection based on designing and building a system using a machine learning algorithm that incorporates ensemble learning using AdaBoost and the CICDDoS2019 dataset. The sequence to be followed to detect SYN flood and UDP Lag attacks is system design, data collection, search and data analysis. Metrics such as accuracy, recall and F1-score are used to detect distributed denial-of-service (DDoS) attacks including SYN flood and UDP Lag attacks.

In [17], the authors propose a widely applicable P4-based SDN secure system. Through the experiments carried out, the authors show that the proposed secure system can effectively reduce the impact of SYN flooding and UDP flooding. For SYN flooding, the proposed system can release server resources six times earlier if the proposed system is used. During the UDP flooding, the proposed system can reduce the amount of malicious traffic by approximately two-thirds if the proposed system is used again.

In [18], the authors created a machine-learning-based model to predict multiple and different DDoS attacks. The machine learning models used to classify these attacks were Logistic Regression, K-nearest neighbor (KNN), Multi-Layer Perceptron and Decision Tree classifiers. The implementation of the proposed model was carried out using Jupyter Notebook and Python. Based on the carried out experimental studies, KNN and Decision Tree classifiers showed almost similar and best accuracy of 99.98% in predicting TCP and ICMP flooding attacks. The Decision Tree classifier showed the best accuracy of 77.23% compared to others in predicting UDP flooding.

As can be seen from the presented review, most authors emphasize different ways, methods and techniques to increase security against different cyber-attacks, which is normal and understandable, but do not discuss if the attack would have any impact on the parameters of the individual VoIP flows. The very idea of studying the effect of an attack on the performance of a VoIP server is interesting and will show what would happen if the methods to defend against such attacks were overcome.

3. Research Methodology and Used Tools

3.1. Research Methodology

For the purpose of this work, the GNS3 IP network modeling platform [19,20,21] is used. The use of platforms for modeling different systems and the processes in them makes research related to different areas of science easy to conduct and increasingly applied in the process of studying different problems [22,23,24,25,26,27,28]. Using GNS3 will solve several key problems such as the following:

• The attack will be isolated to the “territory” of the modeled network. The modeled network will not be connected to the Internet or other IP networks. Thus, the attack action will be isolated, controlled and co-focused only on the territory of the modeled network;
• Real network device models will be used, which are very expensive, and not everyone can afford them. The main advantage of GNS3 is working with disk images of real operating systems of different network devices. Real/physical network devices are very expensive, and not every researcher can afford to buy them. This limiting factor is eliminated by the use of the GNS3, through which these network devices can be used by researchers, in the form of models. In this way, the modeled networks with GNS3 will be closer to the real networks.

The present study is divided into two parts. In the first part, only voice traffic will be exchanged in the modeled network, and in the second part, only video traffic will be exchanged. As mentioned in the beginning, Asterisk FreePBX will be used as the VoIP server. During both studies, Asterisk will be attacked/flooded with UDP packets. The packet size is 950 bytes, which is the maximum packet size that can be proceeded with by the emulated disk images of the modeled network devices. Beyond this size, packets begin to be dropped by the network devices. These packets are sent every 10 µs.

Compared to the previous study, more results from the Asterisk FreePBX monitoring menu that were missing in the previous study were added—Live network usage; Asterisk’s CPU load and memory load. A network analyzer will be used to monitor the load on the Asterisk FreePBX network card.

In addition, packets exchanged between the Asterisk FreePBX and the subscribers during the video and audio calls will be captured using Wireshark. After the end of the study, Wireshark’s RTP stream analysis feature will be used to analyze/show how the UDP DoS attack affects the parameters of the individual streams. The parameters to be monitored are maximum and mean jitter and packet loss. These are the main parameters that are monitored when monitoring VoIP traffic. The values of these parameters determine the quality of service—the mean jitter should not exceed 30 ms, and the packet loss should be around 1% [29,30].

3.2. Used Tools

For the purpose of the present study, the following tools are used:

• Network packet analyzer: Wireshark [31] was used due to its integration with GNS3 and the functionality to analyze RTP flows.
• Network analyzer: Colasoft Capsa 11 free was used [32]. It monitors the network interface of the Asterisk FreePBX.
• hping3: This is a network tool that generates/sends modified ICMP/UDP/TCP packets. It is used to flood the attacked device—it implements UDP/TCP DoS attacks [33].
• Nmap: It is a tool for discovering network devices and for studying the network security level of a device [34].

4. Topology of the Modeled Network

Figure 1 presents the topology of the modeled network.

R1 is a router and is used only as a DHCP server that distributes IP addresses to the devices on the network—VM1 to VM4, Kali_Linux and Asterisk_Free_PBX. No other settings were changed on the router. ESW1 and ESW2 are emulated disk images of real managed switches. The settings of these switches are the factory defaults, and no additional settings were changed. VMware Workstation Pro 17 is used for the virtualization of the VMs, Kali Linux and the Asterisk FreePBX. VM1 to VM4 are virtual machines with installed Windows 10 Home on them. The softphone Linphone is installed on these virtual machines through which the Asterisk subscribers (VM1 to VM4) talk to each other. Kali_Linux is a virtual machine on which Kali Linux is installed, through which Asterisk FreePBX is attacked. Asterisk_Free_PBX is also a virtual machine on which Asterisk FreePBX is installed. Using Wireshark, the link between Asterisk_Free_PBX and ESW2 is monitored. Thus, all packets that are exchanged between the Asterisk FreePBX and the individual VMs will be captured and then analyzed, using the capabilities of the Wireshark. The modeled network is isolated, and there is no connection to the Internet. For the present study, the topology of the modeled network is slightly modified. In the previous study, Kali Linux was deployed in another network, external to the Asterisk FreePBX, behind the R1 router. In the current study, Kali Linux and the Asterisk FreePBX are on the same network to negate possible router influences.

5. Results

5.1. Results When Only Voice Traffic Is Exchanged

5.1.1. Results from Normal Mode of Operation

Figure 2 represents the traffic that goes through the Asterisk during normal operation. All subscribers talk to each other. There are two voice streams (VM1 calling VM2 and VM3 calling VM4), each with a rate of 42 kB/s. As can be seen, the traffic is normal for processing voice streams. The result is from the Asterisk FreePBX dashboard.

Figure 3 shows the traffic that enters/exits the Asterisk FreePBX network interface card (NIC). The result is from Capsa free 11. As can be seen, the traffic that goes through the Asterisk network interface is the same as in Figure 2, except that it is summed.

Figure 4 represents the traffic that is generated/processed by the VM3. The same traffic is generated/processed by the other VMs. As can be seen, if the traffic from the two virtual machines (VM3 and VM4) is summed, the traffic generated by the two voice streams that is processed by the Asterisk FreePBX is obtained.

Figure 5 represents what the CPU utilization of the Asterisk is for different time intervals. As can be seen from the graph, the CPU utilization is below 50%. There is only a single overshoot above 50%. In the general case, the load during the calls is around 20%.

Figure 6 represents what the memory load of Asterisk was for the entire study period. As can be seen from the graph, the memory load is around 14%.

Figure 7 shows the summarized information about the parameters of the voice stream that is exchanged between VM1 (192.168.2.3) and VM2 (192.168.2.6) in both directions—from VM1 to the Asterisk (192.168.2.2) Figure 7a, then from the Asterisk to the VM2 and vice versa. As can be seen from the figures, the values of the most important parameters—mean jitter and packet loss are within the norm.

Figure 8 represents how the jitter changes during the entire conversation in the direction from VM1 to the Asterisk and vice versa. As can be seen from the graph, there are only a few momentary spikes; otherwise, the jitter values vary between 0.5 and 1.5 ms.

Figure 9 represents how the jitter changes during the entire conversation in the direction from VM2 to the Asterisk and vice versa. As can be seen from the graph, the result is similar to the result in Figure 8.

These results will be used as a reference. These results will be compared to the results obtained when Asterisk is attacked with a UDP DoS attack during audio conversations/calls between the users.

5.1.2. Results When Asterisk Is Attacked

In this scenario, all subscribers in the network are talking to each other, and while they are talking, Asterisk is attacked/flooded with UDP packets—a UDP DoS attack.

Figure 10 represents what traffic is let through by the Asterisk during the attack.

As can be seen from the graph, the traffic (RX) received from Asterisk is about 12 MB/s. The transmitted traffic remains the same as it was during normal operation. This figure shows that Asterisk is flooded—a successful UDP DoS attack.

Figure 11 shows what traffic is handled by the Asterisk network interface. The presented result confirms the result of the Asterisk network interface monitoring tool.

Figure 12 shows what the utilization of the Asterisk network adapter is during the attack. If the load is above 50%, it means that the network/device is overloaded. As can be seen from the graph, the utilization is around 10%, which is well below the value for an overloaded device. In normal mode, the load is below 1%.

Figure 13 represents what the Asterisk CPU load is. As can be seen from the graph, it is a continuation of the results in Section 5.1.1. There is a slight increase in the load for all three measurement time periods, but it is not anything drastic—the load continues to hover around 20%.

Figure 14 represents what the Asterisk memory load is. The shown graph is again a continuation of the graph from Figure 6 because the study was conducted on the same day, shortly after the study in Section 5.1.1 was completed. As can be seen from the graph, there is a slight 1% increase in memory load. The other values are the same as in Figure 6.

Figure 15 shows the summarized information about the parameters of the voice stream that is exchanged between VM1 (192.168.2.3) and VM2 (192.168.2.6) in both directions—from VM1 to the Asterisk (192.168.2.2), then from Asterisk to the VM2 and vice versa. As can be seen from the results, there is a slight degradation in the parameters—packet loss is 0.02% compared to the same results from Section 5.1.1. The maximum and average jitter values are also slightly inflated. The average jitter value is still much further away from the maximum allowed value of 30 ms.

Figure 16 represents how the jitter changes during the entire call in the direction from VM1 to the Asterisk and vice versa. As can be seen from the graph in the direction from VM1 to the Asterisk, an increase in the instantaneous values of the jitter is observed. This increase is minimal and does not affect the quality of the voice stream. These values are still very far from the maximum allowed.

Figure 17 represents how the jitter changes during the entire call in the direction from VM2 to the Asterisk and vice versa. As can be seen from the graph, the result is the same as in Figure 16.

For the other voice stream, between VM3 and VM4, the results are analogous—again, a slight deterioration in the observed parameters, resulting in no deterioration in the quality of the voice stream. Therefore, they are not presented.

Figure 18 shows how many UDP packets were sent during the attack. During the attack, 28,986,051 UDP packets with a size of 950 bytes were sent.

Even though Asterisk is under a UDP DoS attack, the VoIP server is accessible. This can be seen/confirmed by both the screenshots presented from the Asterisk dashboard menu and the result of the ping command executed by VM1—Figure 19. As can be seen from the result, no packets were lost, all sent packets were processed by the Asterisk, and the server responded to all ICMP packets sent by the VM1 despite being flooded with UDP packets.

5.2. Results When Only Video Traffic Is Exchanged

5.2.1. Results from Normal Mode of Operation

In this scenario, a video stream is exchanged between two users, and Asterisk is not attacked. Figure 20 represents the traffic that is let through by the Asterisk during normal operation. Only two subscribers are having a video conversation (VM1 and VM2). One video stream is available. Each part of the video stream has a rate of 94 kB/s. As can be seen, the traffic is normal for processing video streams. The result is again from the Asterisk FreePBX dashboard.

Figure 21 shows the traffic that is let through by the Asterisk FreePBX network interface. As can be seen, the traffic on the Asterisk network interface is the same as in Figure 20, except it is summed.

Figure 22 represents the traffic that is generated/processed by the VM1. The same traffic is generated/processed by the other VM. As can be seen, if the traffic from the two virtual machines (VM1 and VM2) is summed again, the traffic generated by the two video streams that is processed by the Asterisk FreePBX is obtained.

Figure 23 presents what the CPU utilization of the Asterisk is for different time intervals for the entire study period. As can be seen from the graph, the CPU utilization is below 30%. In the general case, the load during the calls is hovering around 20%. The results are similar to the results in Section 5.1.1.

Figure 24 represents what the memory load of the Asterisk was for the entire study period. As can be seen from the graph, the memory load is at 14%, almost the same as the results in Section 5.1.

Figure 25 shows the summarized information about the parameters of the video stream that is exchanged between VM1 (192.168.2.3) and VM2 (192.168.2.6) in both directions—from VM1 to the Asterisk (192.168.2.2), then from Asterisk to the VM2 and vice versa. The parameters to be monitored are again maximum and mean jitter and packet loss. As can be seen from the figure, the values of these parameters are within the norm. Compared to the same parameters in Figure 7, a slight increase in the individual values is observed, which is normal for real-time video transmission.

Figure 26 represents how the jitter changes during the entire conversation in the direction from VM1 to the Asterisk and vice versa. Compared to Figure 8, the values are slightly inflated but within the norm.

Figure 27 represents how the jitter changes during the entire conversation in the direction from VM2 to the Asterisk and vice versa. As can be seen from the graph, the result is similar to the result in Figure 26.

5.2.2. Results When Asterisk Is Attacked

In this scenario, two subscribers in the network are having a video conversation with each other, and while they are talking, the Asterisk is attacked/flooded with UDP packets—a UDP DoS attack.

Figure 28 represents what traffic is let through by the Asterisk during the attack. As can be seen from the graph, the received traffic (RX) is again around 12 MB/s. The transmitted traffic remains the same as during the normal operation mode. This figure shows that Asterisk is flooded—a successful UDP DoS attack.

Figure 29 shows what traffic is let through by the Asterisk network interface. The presented result confirms the result of the Asterisk network interface monitoring tool—the server is flooded with UDP packets.

Figure 30 shows what the load on the Asterisk network adapter was during the attack. As can be seen from the graph, the load is about 10%. The result is the same as the result in Section 5.1.2.

Figure 31 represents what the CPU load of the Asterisk was at the end of the study. The graph is an extension of the results in Section 5.2.1. There is one peak that exceeds 50% load because that is when the UDP DoS attack starts. After that, the load decreases, and it settles in a stable range. Compared to the normal mode of operation (Section 5.2.1), a slight increase in load is observed for all three measurement time periods, but it is not anything dramatic.

Figure 32 represents what the Asterisk memory load was at the end of the study. The graph presented is again a continuation of the same graph in Figure 24 because the study was conducted on the same day. As can be seen from the graph, there is a slight 1% decrease in memory load at that particular time. The other values are close to the same results presented in Section 5.1 and Section 5.2.2.

Figure 33 presents the summarized information about the parameters of the video streams that are exchanged between VM1 (192.168.2.3) and VM2 (192.168.2.6) in both directions—from VM1 to the Asterisk (192.168.2.2), then from Asterisk to the VM2 and vice versa. The presence of packet loss is noticed which is minimal. The rest of the parameters are within normal limits.

Figure 34 represents how the jitter changes during the entire conversation in the direction from VM1 to the Asterisk and vice versa. As can be seen from the graph in the direction from VM1 to the Asterisk, there is not any striking difference with the result obtained in the normal mode of operation—Figure 26.

Figure 35 represents how the jitter changes during the entire video call in the direction from VM2 to the Asterisk and vice versa. As can be seen from the graph, the result is the same as in Figure 34.

Figure 36 shows how many UDP packets were sent during the attack. During the attack, 32,044,426 UDP packets with a size of 950 bytes were sent.

The VoIP server is still available and accessible. This can be seen/confirmed from both the screenshots presented from the Asterisk dashboard menu and the result of the ping command executed by VM1—Figure 37. The result is for the entire period of the study. As can be seen from the result, again, there were no packet losses, all sent packets were processed by the Asterisk, and the server responded to all regardless of the UDP DoS attack.

6. Discussion

6.1. Analysis of Results When Only Voice Traffic Is Exchanged

From the carried-out study and the obtained results, it was found that the UDP DoS attack does not affect the voice flow parameters. The two main parameters that are monitored, mean jitter and packet loss, are always within the norm—during the attack, packet loss increases to 0.02%, with an allowable 1% packet loss. The average jitter also increases to 2.86 ms, which is very far from the allowable 30 ms limit. These increases are in the background of flooding the server with UDP packets, of size 950 bytes each.

Furthermore, this attack does not lead to Asterisk being blocked either. Even though the server is flooded with UDP packets, the system functions normally. This was confirmed by the obtained and presented results. Figure 38 presents what the CPU load of the Asterisk is for the day when only voice streams were exchanged—for normal mode and during the UDP DoS attack. As can be seen from the graph, the average CPU utilization for the whole day varies around 20%.

Figure 39 shows what the memory load was for the day. As can be seen from the graph, only 15% of the memory is used, and the rest of the memory is free. As can be seen from the graph, there is no significant difference in the memory load when Asterisk is attacked and when it is not attacked—always only 15% of the memory is in use.

These graphs explain the success rate of the ping command during the UDP DoS attack—the server’s hardware resources are not 100% occupied, which is the goal of a UDP DoS attack—to completely block the system.

6.2. Analysis of Results When Only Video Traffic Is Exchanged

The obtained results confirmed the results of the past study when Asterisk FreePBX was attacked with various TCP DoS attacks. From the current study, it was found that the UDP DoS attacks do not affect the parameters of the VoIP video streams. During the attack, the packet loss increased to 0.06% (with an allowable 1% packet loss), which is more compared to the study when only voice streams were exchanged. This is normal because when video traffic is exchanged, the amount of information that is exchanged is much more than when only voice traffic is exchanged. The average jitter is also very far from the allowable 30 ms.

During this study, the UDP DoS attack did not result in the blocking of the Asterisk. Despite the server being flooded with UDP packets, the system functioned normally. Figure 40 represents what the CPU utilization of Asterisk was for the day when only video streams were exchanged—for normal mode and during the UDP DoS attack. As can be seen from the graph, the average CPU utilization is low—about 13%.

Figure 41 shows what the memory load was for the day. As can be seen from the graph, only 14% of the memory is in use, the rest of the memory is free. As can be seen from the graph, there is no significant difference in the memory load when Asterisk is attacked and when it is not attacked—always only 14% of the memory is in use.

Again, during this study, the ping command is successful. Asterisk’s computational capabilities are not blocked.

6.3. Summary of Results

The presented results confirm the results from the previous study obtained when carrying out the same research with the difference that the Asterisk FreePBX was attacked with different TCP DoS attacks. It was then found that the different TCP DoS attacks did not affect the parameters of the voice and video streams. Asterisk was not blocked. The same results were obtained in this study. Again, as in the previous study, Asterisk’s built-in firewall was enabled. These two different studies show that Asterisk is designed to resist different DoS attacks that do not affect the parameters of the different streams and do not cause the server to be blocked. This is confirmed by the result in Figure 42. Figure 42 represents what the result of running the “vuln” script in Nmap was. Through this script, Nmap checks the device under test for the most common vulnerabilities. As can be seen from the result, the Asterisk FreePBX is only slightly vulnerable to some DoS attacks that could possibly lead to a denial of service.

From the carried-out study, it can be argued that the Asterisk FreePBX is sufficiently secured from the impact of various TCP DoS and UDP DoS attacks. This VoIP platform is suitable for small to medium-sized institutions that cannot afford large investments in additional cyber protection measures. The only way to detect either of the two attacks (TCP DoS or UDP DoS) is to monitor the “Live network Usage” tab from the dashboard menu of the Asterisk FreePBX or configure alarms to be sent when there is an increase in traffic above a certain value. As seen from the carried-out study, this is the only way to detect the presence of either of the two attacks because these attacks do not affect the quality of voice and video streams—calls do not drop, no delays occur, and there is no packet loss. Regardless of the available built-in security of the Asterisk FreePBX, it is recommended to add other additional security measures such as those discussed in [35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50].

7. Limitations and Future Work

The limitations in the presented study are mainly related to the peculiarities in the performance of the used platform for modeling IP networks—GNS3. The main drawback of the presented study is that in order to carry out it normally and without any issues, a workstation with significant computational capabilities must be used. This is necessary for the IP network modeling to be carried out without any interruptions, lags, freezes and other such problems due to a lack of hardware power from the workstation used. The workstation used for this study has two 18-core processors (72 logic cores in total) and 192 GB of RAM. The next limitation is related to the working principle of the GNS3. In order to use 100% of the capabilities of the platform, Linux should be used instead of Windows. From my other experimental studies and carried out research on various technology forums related to the GNS3, it was found that when using the Linux operating system, the speeds in GNS3-modeled networks are much higher than if the Windows operating system is used.

As a guideline for future work, on the topic at hand, is to repeat the two studies (applying UDP DoS attacks and TCP DoS attacks), but this time using Asterisk rather than Asterisk FreePBX. In addition, I intend to use Linux as the operating system to exploit the full capabilities of the GNS3, thus eliminating one of the limitations associated with using an operating system.

8. Conclusions

This study showed that the UDP DoS attack had no impact on the parameters of the voice and video flows in a VoIP network based on Asterisk FreePBX. Even though the server is flooded with UDP packets, this flooding does not degrade the parameters of the individual VoIP streams. The mean jitter and packet loss, for both VoIP streams, are within normal limits, very far from the maximum allowable levels, exceeding which would result in the degradation of VoIP service quality.

In addition, during the UDP attack, the Asterisk FreePBX is accessible. Both the server’s CPU and memory are lightly loaded despite the flood with UDP packets.

This study confirms the results obtained from the previous study when Asterisk FreePBX was attacked with various TCP DoS attacks. And in the previous study, it was found that different TCP DoS attacks do not affect the parameters of individual VoIP flows, and regardless of the attacks, the server is accessed, and different VoIP calls can be made.

Both studies show that the Asterisk FreePBX is designed to be able to resist a variety of DoS attacks that do not impact system performance.