Assessing the Impact of DoS Attacks on the Performance of Asterisk-Based VoIP Platforms

Abstract

In this work, a hypothesis is studied as to whether different DoS attacks affect the parameters of voice and video streams, as well as performance, on three different VoIP platforms. This research is a continuation of a previous work, which studied the same hypothesis on the Asterisk FreePBX platform. The studied VoIP platforms are VitalPBX, Issabela, and CompletePBX 5, which are based on Asterisk Free PBX. For the purpose of this research, a simple model of an IP network was developed in the GNS3 IP network modeling platform. The experimental part of this work is conventionally divided into two parts. In the first part, only voice/video streams are exchanged in the network, and the studied VoIP server is not under DoS attacks. In the second part, the studied VoIP server is subjected to DoS attacks. The results obtained confirm the results of the previous research—the performance of the three studied platforms is not affected by DoS attacks. The attacks do not affect the parameters of the VoIP flows—the mean jitter value is below the permissible value of 30 ms; for the three servers, it is around 4 ms. The percentage of lost packets is again below the permissible value of 1%; for the three servers, it is around 0.5%. Despite sustained packet flooding, all three servers remained operational, and VoIP calls were maintained without significant degradation.

1. Introduction

The main development in telecommunications from today’s point of view started with the simple telegraph, moving to analogue communications, and then digital, to the technologies used today that are based on the Internet Protocol and MPLS networks. A key link in modern telecommunications is switching and, more specifically, the telephone exchanges that perform this function, as far as calls between subscribers are concerned. Currently, all developed countries use IP-based telephone exchanges for both landline and mobile communications [1,2,3,4,5].

In the beginning, telephone exchanges were built by different states due to the presence of large investments and serious regulations in the field and were known as public switched telephone networks or PSTNs. Subsequently, they passed or are passing (depending on the different states) to private companies with serious financial and human resources. At present, companies and businesses, no matter how small they are, have their own small, private, and local telephone exchanges. These were preferred in the past, but now we will focus on those that are based on and work with the Internet Protocol and transmit speech information through it, such as VoIP technology. These are Private Branch Exchanges (PBXs). They have a number of advantages, as follows:

• Greater confidentiality of information. The information transmitted in them does not go outside the organization’s network and it is not processed by other operators as far as the calls of internal subscribers are concerned.
• Very good flexibility and equipment options. Not every subscriber needs to have a physical IP phone. They can simply install software phones on the computers that employees work on. Through the internal wireless network (Wi-Fi) and the corresponding application, the employees’ mobile phones can be used as terminals for communication in the private telephone exchange, and so even the subscriber can be mobile within the range of the wireless network.
• Ability to maintain control. The system administrator has full access to the employee conversations. It can be found out who they talked to, for how long, at what time, and more, without requiring special permission from judicial authorities or other institutions.

These exchanges can also connect to the PSTN and/or other networks of terrestrial and mobile operators in various ways, subject to appropriate arrangements. The connection between a VoIP system and a PSTN network is made via a Foreign Exchange Office (FXO) device. This device creates coordination between the two technologies and enables data exchange.

These and many other advantages make them preferred for securing communications in private business and various types of government institutions [6].

In the 21st century and the digital age, there are also a number of dangers. As these PBXs are in almost all cases connected to other large public networks or connected outwards (to the global network—the Internet), there are a number of dangers relating to the privacy of information or their proper functioning. There are two main areas that need to be addressed. The first is eavesdropping. There are a number of methods and sniffers that can carry out unwanted eavesdropping on traffic and breach the confidentiality of information. The second is the disruption of the functioning of the system (most common attacks are denial of service or distributed denial of service—DoS and DDoS). There are a lot of research studies on securing these systems from eavesdropping and DoS/DDoS attacks [7,8,9,10,11].

The purpose of this research is to find out how a DoS attack (TCP SYN or UDP flooding) affects the performance of the VoIP server—whether it overloads, whether calls that have already been established drop, whether new calls have been established, whether the VoIP server is accessible, and more. Additionally, the obtained results will be used to find out whether these attacks affect the parameters of the VoIP streams. It is important to clarify that this research only focuses on VoIP systems where all voice and video streams are handled by the VoIP server and not the end stations (IP phones or softphones), as stated in all books relating to VoIP technology. This study draws attention to this gap in the scientific field—the neglect of research into this type of issue. While previous studies have focused on detection and prevention mechanisms for VoIP DoS attacks, limited attention has been given to the performance behavior of VoIP servers under active DoS conditions. This study aims to fill this gap by experimentally evaluating three Asterisk-based platforms which were subjected to DoS attacks.

Three servers were selected to obtain a more accurate and reliable study. In these platforms, voice and video streams are handled by the VoIP server. The three VoIP platforms will be studied in a modeled and closed IP network. This work provides a form of conclusion to the previous research on the subject presented in [12].

2. Related Work

There can be a number of uncertainties when using IP-based PBXs as identified by the authors in [13]. They found that there are a number of software applications that can be used and modified by malicious attackers such as botnets to automate the process and speed up the attack. They made their own VoIP honeypot by waiting for cybercriminals to attack it and they monitored their actions and then subjected them to analysis. They described the methods and tools the criminals had used and tracked their behavior and what deception they carried out with the resources they had already acquired. By tracking IP addresses, they identified which geographic areas the attackers were from. A number of ways to deal with these threats and scams have also been presented. The difference with the current work is that the authors of this study have used the Asterisk FreePBX as a “decoy” to study the origin of various SIP attacks targeting the VoIP server.

The authors in [14] used a VoIP PBX honeypot active for a given period of time to be able to analyze the methods that hackers use in an attempt to gain access to a VoIP system. Here, the authors already used Asterisk PBX to analyze the origin and target of various attacks directed against the VoIP server. They used different techniques to gain access. The magnitude of attack intensity for given periods during the year and how they change during holidays was also identified. They identified the use of Advanced Persistent Threat in order to infiltrate a VoIP system (including PBX) to commit fraudulent charges where possible, adding that system to a botnet of infected voice systems. Hackers have become more disciplined, diligent, and resourceful, launching attacks not only against VoIP protocols but also against web protocols, in some cases from the same IP subnets. Based on this and previous research referenced in the publication, it has been determined that the operation of attackers is now largely if not completely automated.

In the previous two studies, the authors used the VoIP server to be deliberately attacked in order to thoroughly analyze the origin and purpose of each attack. In [15], the authors considered the possibility of portability for Asterisk Free PBX. Implementation was carried out using an IP PBX embedded in a Raspberry Pi SBC that can serve a good number of users, be mobile and easily portable, and retain the functionality of a full IP PBX. It has a wide application where large infrastructures cannot be moved. Performance studies of an Asterisk^®-based IP PBX installed on a Raspberry Pi 3 (model B) platform are presented in terms of concurrent call processing using different codecs. It has been found that the IP PBX implemented on Raspberry Pi 3 can quite normally serve a not very large number of simultaneous calls with the right choice of codec. Unlike the present work, here, the authors did not pay attention to the problem of VoIP server security.

In [16], a VoIP system built on the Asterisk platform and the deployment of robust security solutions throughout the network was discussed and proposed. The increasing dangers of attacks to these systems are highlighted. Encryption protocols, authentication mechanisms, and network segmentation are proposed to enhance security while maintaining system performance. The proposed solution reduces the security vulnerabilities with negligible impact on system performance. The system proposed by the authors also has significant drawbacks when deployed at large scale and for many users, such as configuration complexity and scalability. Here, too, the authors emphasize various methods and techniques for enhancing the security of Asterisk platform without paying attention to the effect of a given attack on the system.

The direct dependence of VoIP networks on the session initiation protocol (SIP) for signaling processing functions is presented in [17]. The most common denial of service (DoS) and distributed denial of service (DDoS) attacks are directly dependent because they limit VoIP resources and make the SIP service unavailable to users. The authors present approaches to detect DoS and DDoS attacks and classify them based on various factors and an analysis of these approaches is provided. Here, the authors again do not consider the impact of the individual attacks on the performance of a given VoIP platform but only propose innovative methods by which various DoS/DDoS attacks can be localized.

The authors in [18] investigated DOS attacks and ways to mitigate their effect on VoIP networks. They proposed a novel framework they call “Call Me Maybe” that combines elements of latency monitoring with dynamic protocol switching. Their research was conducted around routing VoIP over TCP rather than UDP. They used a latency monitoring mechanism to detect when the service is under attack. The combination of rule-based and statistics-based approaches ensures that the “Call Me Maybe” framework is scalable to a wide range of attacks and can be adapted to different network designs. According to them, the “Call me Maybe” framework demonstrates a competitive detection time against even the strongest attack and can be used against all DoS and DDoS attacks. This method is intended as a barrier to protect against UDP (D)DoS attacks and can be used at a basic level by indexing the drop in latency. Again, the authors did not consider the impact of the DoS attack on platform performance. The concept of the proposed protection method is applicable to all VoIP platforms.

Fundamental issues in VoIP technology are discussed in [19]. Problems that may occur such as packet loss, latency, and jitter in communication and data exchange are presented. A step-by-step review of the development and use of reliability techniques to achieve high voice quality in a VoIP network is presented. The reliability techniques and existing problems of VoIP are discussed. Quality of service (QoS) is also addressed. The idea of the authors in this study is close to the objective of the present work. The authors focus on everything that could lead to a change in the reliability/performance of a given VoIP platform, while this paper focuses on the impact of various DoS attacks on the performance of Asterisk Free PBX-based platforms.

In [20], the system which is shown is less commonly used for VoIP deployment, namely a system based on Issabel as an integrated IP PBX server with telecommunication providers. Experiments were carried out making calls from the local PBX to the GSM and PSTN networks. It was found that the Issabel-based PBX server can be used as an alternative telephone system that can make connections to PSTN and GSM networks. The same platform was discussed, which further enriches it with new information relating to the Issabela platform.

In [21], a deep learning model was considered, based on recurrent neural networks (RNNs) was developed to detect low and high intensity DDoS attacks. Three attack scenarios of different durations and intensities were presented. A novel approach for detecting DDoS attacks on VoIP networks is presented. The method presented by the authors is not efficient enough in parallel information processing, so they plan to improve it using convolutional neural networks (CNNs) or self-awareness networks (SANs). Here, too, the authors have focused on the detection of DDoS attacks, which is also partially discussed in this paper.

In [22], the main focus is on the insufficient preparation for handling VoIP networks at the security level. It emphasizes the need for a deep understanding of these networks at a new protocol level in order for them to be well protected. Hacking attacks against VoIP are presented, such as denial of service (DoS) attacks, registration manipulation and data hijacking, authentication attacks, caller ID spoofing, man-in-the-middle attacks, virtual local hopping, passive and active eavesdropping, spam over Internet telephony (SPIT), and VoIP phishing. After analyzing and evaluating the attacks, they have found that VoIP communication technology is good and reliable for use in everyday life, but by well-trained professionals and with a proper system setup. Since these systems do not use encrypted connections by default, it is recommended to use these especially when leaving the internal network. The authors conducted a detailed analysis of the vulnerabilities characteristic of VoIP technology and what would happen if an attack were successful. They did not stop at a specific platform to investigate and test their hypotheses, which is what is covered in this work.

The author in [23] presents a model of an Asterisk-based VoIP system to be used for a complete solution and security enhancement across the VoIP network. The VoIP technology as a whole has been analyzed and its vulnerabilities have been identified and ways to address potential threats have been proposed. A security framework is proposed to secure the VoIP network. The presented system and security solutions are tested and analyzed to ensure reliability and effectiveness. The critical security measures and their necessity for securing the infrastructures are identified. Different types of protocols that can be used in a VoIP-based network design are discussed and analyses and comparisons between them are made. Based on this, the author recommends the SIP protocol to be used in the design of Asterisk VoIP-based networks. A dial plan and numbering system to be used is also presented. The call system is designed by creating VDI images as well as Oracle virtual box configuration, and IPsec VPN is implemented throughout the network. It was found that there was a quality-of-service issue with VoIP calls according to the security throughout the network. The author examined Asterisk IP PBX, on which the Asterisk Free PBX platform, studied in this paper, is based. The author’s idea was to protect the system using various techniques, such as special addressing and VPN, without paying attention to the effect of various attacks on the system, which is the subject of this paper.

In [24], methods for increasing the availability of a VoIP system are presented. Various challenges related to the proper and continuous operation of these systems are analyzed. For these analyses and proposed solutions, software such as Kamailio (SIP signaling server), RTPengine (media traffic processing), Redis (in-memory database for storing RTP transactions), and Linux Ubuntu as host operating system are used. The presented architecture manages to load balance and seamlessly switch to a backup node in case of failure of one or more components. A method for increasing the availability of a VoIP system in the event of the failure of one or more of its components is presented. The authors’ idea is to examine/analyze methods for improving the accessibility of the VoIP system. The main challenges related to the functioning of VoIP systems are analyzed, such as ensuring service continuity, fault tolerance, scalability, resource efficiency, and others. The authors have not examined/analyzed the impact of various attacks on VoIP, which is performed in this work.

As can be seen from the presented review, most researchers are focusing their studies on detecting and preventing possible attacks against VoIP systems, which is normal. The presented research is fundamentally different. It addresses the hypothesis “what would happen if the VoIP server/platform is not secure and the DoS attack is successful”—is it fatal, is the server functional, are the calls dropping, is it possible to make calls, etc. The present study, together with the previous study, can be seen as an enrichment of the research on topics relating to the network security of VoIP systems.

3. Research Methodology, Topology of the Experimental Network, Used Tools

3.1. Research Methodology

For the purpose of this study, three different VoIP PBXs are studied: the VitalPBX, Isabella, and CompletePBX 5. The versions of two of the VoIP servers have limited capabilities (VitalPBX and CompletePBX) because they are free versions. The full features are available upon purchase of a license. The limitation of both platforms is aimed at a limited number of simultaneous calls, or a limited number of subscribers, or the inability to make video calls. All other PBX capabilities are available for both the paid and free versions.

This study will be carried out as follows. Each of the VoIP servers will be virtualized independently in a modeled IP network. A number of subscribers will be associated with it, according to the constraints of the respective PBX. Both voice and video calls will be made in the modelled network where possible. Initially, calls will be realized without the VoIP server being attacked. During these calls, all traffic exchanged between the VoIP server under study and the subscribers will be captured by Wireshark. Then, the subscribers will build calls when the VoIP server under study is subjected to a TCP and UDP DoS attacks.

During the TCP SYN attack, the size of the attacking packets is not changed—the default size of 60 bytes is used. These packets are sent in a series, approximately every 300 µs. During the second TCP SYN attack, the size of the attacking packets is changed to 1000 bytes. The packets are sent over a period of approximately 200 µs. This time is not configured, and it is the default value.

In order to expand the scope of this study, research was carried out with other attacks, making this study more comprehensive. To achieve this, a study was carried out on how the studied platforms would react when attacked with UDP flooding. The reason for carrying out a study with UDP flooding is that these types of attacks are the most common and destructive threats in VoIP systems. During the UDP flooding, the size of the attacking packets is set to 1000 bytes in order to maximize the load on the attacked system. If the attack is carried out with larger packets, some of them will be discarded by the network devices through which they pass, i.e., the attack will not be effective. This also applies for the TCP SYN attack. The attacking packets are sent at approximately 200 µs. Again, this time is not configured and is set by default.

The duration of each conversation, regardless of whether the system is attacked or not, is approximately 10 min. The duration of each attack is also approximately 10 min.

The parameters that are monitored and used to estimate the quality of the VoIP flows (audio and video streams) are packet loss and average jitter. The maximum allowable average jitter should not exceed 30 ms and the percentage of packets lost should not exceed 1% [25,26].

The obtained results will be compared and analyzed. In this way, it will be possible to determine if and how the TCP and UDP DoS attack has any impact on the performance of the studied PBXs and does the attack have any impact on the parameters of the VoIP flows.

3.2. Topology of the Experimental Network

Figure 1 presents the topology of the experimental network. The GNS3 version 2.2.54 IP network modeling platform is used to implement the network [27]. The use of modeling platforms has many advantages that help in realizing any research that could not otherwise be realized [28,29,30,31,32,33,34,35,36,37]. In this particular research, the use of GNS3 solves the problem of lack of physical network equipment (routers and switches) and secondly makes sure that the network is isolated. VoIP_server is a virtual machine (hypervisor) of the tested VoIP PBX. R1 is an emulated disk image of a router that is used as a DHCP server that “distributes” IP addresses to all devices in the modeled network. Kali_Linux is a Kali_Linux virtual machine that is used to attack the VoIP PBX under test. ESW1 and ESW2 are emulated disk images of managed switches. No configurations were made on them—it is as if they were just out of the box and plugged in. They work like regular switches. VM_1 to VM_4 are virtual machines on which Windows 10 is virtualized. They are used as VoIP PBX subscribers. A softphone is installed on each of them. Video and audio calls are established between them.

3.3. Used Tools

The following instruments were used for the purpose of this study:

• Network protocol analyzer—Wireshark ver. 4.6.0 was used for this study. It was used to capture all packets exchanged between the VoIP server under study and its subscribers. Its main advantage that led to the use of this tool is the built-in VoIP flow analysis capabilities [38];
• hping3 ver. 3.0.0—this is a tool built into Kali Linux that is used to generate custom TCP/UDP packets designed to build various TCP/UDP DoS attacks. In this study, hping3 was used to implement TCP and UDP DoS attacks [39];
• Nmap ver. 7.94—this tool is also a part of the Kali Linux tools. It is used to scan ports on network devices. Nmap sends specially crafted packets to the host and then analyzes the responses. In this study, only the analysis of functionality of Nmap was used, based on specialized scripts, to analyze a network device for various network vulnerabilities [40];
• Colasoft Ping Tool ver. 2.0—this tool was used to check what is the round-trip delay between the subscriber and the studied VoIP server during the DoS attacks—if there is packet loss, what the delay is and more [41];
• Windows CMD—the ping command will be used, to find out the packet loss and the average delay in ms.

4. Results

4.1. Results for the VitalPBX

4.1.1. Only Audio Calls and TCP Flooding

VitalPBX, ver. 4.5.1-3 is a community free version. The main limitation is the maximum number of subscribers which is 12. For the purpose of this work, only four subscribers are used to talk to each other. There are other restrictions, as shown in [42].

Figure 2 represents what the server load is during the two concurrent calls when the system is not under attack. The system load is low.

Figure 3 presents the summarized results for the voice stream that is exchanged between VM_1 and VM_2 when the system is not under attack. The results are from the analysis carried out with Wireshark. Figure 3a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.3)—VitalPBX (192.168.10.20)—VM_2 (192.168.10.24). Figure 3b shows the values in the reverse direction VM_2 to VM_1. As can be seen, all traffic passes through and is processed by VitalPBX. From the summarized data, it can be seen that the mean value of the jitter and the loss of packets are very far from the maximum allowable values—there is no packet loss and the average/mean jitter value is about 1 ms.

Figure 4 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to VitalPBX (black); from VitalPBX to VM_2 (blue); from VM_2 to VitalPBX (green); and from VitalPBX to VM_1 (brown)—are shown. The presented graph is again created from the analysis of VoIP flows performed by Wireshark. As can be seen, the jitter varies between 0.5 and 1.5 ms. with limited peaks of larger value.

Figure 5 represents the computational load of VitalPBX during the TCP DoS attack. Compared to the normal operation, there is a twofold increase in the CPU utilization, around 3.7%. The memory load is unchanged.

Figure 6 presents the summarized results of the voice stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 6a shows the data for the voice stream that is exchanged in the direction VM_1—VitalPBX—VM_2. Figure 6b shows the values in the opposite direction. From the summarized data, it can be seen that there is an increase in the mean jitter value in the direction VM_1—VitalPBX—VM_2, but the value is still far from the maximum allowed. In the opposite direction, the average value of the jitter is almost the same as the value during the normal operation mode. There is one lost packet only. Even though the system is under TCP DoS attack, there is no deterioration in the parameters.

Figure 7 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to VitalPBX (black); from VitalPBX to VM_2 (green); from VM_2 to VitalPBX (blue); and from VitalPBX to VM_1 (brown)—are shown. As can be seen from the graph, there is a clear distinction between the two main voice streams. Despite the presence of a TCP DoS attack, there is no significant deterioration in the jitter.

Figure 8 represents how many packets are sent during the attack—23,138,429.

Figure 9 represents how the delay changes during the attack. The graph structure is based on data from the Colasoft Ping Tool—the delay is low.

Figure 10 presents the summarized results of the delay. The results are taken from the CMD of Windows 10, using the ping command. There are no lost packets; the average time is 8 ms. Regardless of the attack, the web server of the VitalPBX responds to the requests. The system has not crashed.

4.1.2. Only Audio Calls and UDP Flooding

Figure 11 presents the summarized results of the voice stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 11a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.20)—VM_2 (192.168.10.24). Figure 11b shows the parameter values in the opposite direction. There is an increase in the percentage of lost packets compared to when the platform is attacked with a TCP SYN attack. In addition, there is also an increase in the average jitter value. The increase in the values of both parameters is within acceptable limits.

Figure 12 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to Vi-talPBX (black); from VitalPBX to VM_2 (blue); from VM_2 to VitalPBX (brown); and from VitalPBX to VM_1 (green)—are shown. Compared to the same graph for the TCP SYN attack, there is an increase in the instantaneous values, but they are within normal limits.

Figure 13 shows the computational load on the platform during the attack. The load is similar to the load when the platform is attacked with a TCP SYN attack.

Figure 14 shows the traffic processed by the platform during the attack. The traffic is presented in bytes per second. The platform processes about 6 MB/s, which shows that the attack is successful and floods the server.

Figure 15 shows the load on the server’s network card during the attack. The load is around 6%.

Results for the change in the round-trip delay during the UDP flooding is not presented because the obtained values are almost the same as the results obtained during this study with TCP SYN attack. These results will not present significant new information.

4.1.3. Only Video Calls and TCP SYN Attack

The community version of the VitalPBX also supports video calls. For the purpose of this study, whether the TCP DoS attack affects the quality of video calls is studied. The video call is carried out between VM_1 and VM_2 only.

Figure 16 presents the summarized results for the video stream that is exchanged between VM_1 and VM_2 when the system is not under attack. Figure 16a shows the data for the video stream that is exchanged in the direction VM_1—VitalPBX—VM_2. Figure 16b shows the parameter values in the opposite direction. The values of monitored parameters are very far from the maximum allowable values—there is no packet loss the value of the mean jitter is increased, compared to the audio-only study.

Figure 17 presents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to VitalPBX (black); from VitalPBX to VM_2 (brown); from VM_2 to VitalPBX (blue); and from VitalPBX to VM_1 (green)—are shown. Compared to the study relating only to voice stream exchanges, here, the instantaneous value of the jitter is constant at around 35 ms, exceeding the values obtained so far in other studies.

Figure 18 presents the summarized results of the video stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 18a shows the data for the voice stream that is exchanged in the direction VM_1—VitalPBX—VM_2. Figure 18b shows the parameter values in the opposite direction. The average jitter value in both directions is slightly increased. There is an increase in the number of packets lost. In the VM_1—VitalPBX—VM_2 direction, the losses are 0.02 and 0.03% which is normal because the system is under TCP SYN attack.

Figure 19 presents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to VitalPBX (black); from VitalPBX to VM_2 (green); from VM_2 to VitalPBX (blue); and from VitalPBX to VM_1 (brown)—are shown. The graphic is identical to the results when the system is not attacked.

Figure 20 presents how many packets are sent during the attack—45,535,298.

Figure 21 presents how the delay changes during the attack. It can be noted that regardless of the attack, VitalPBX continues to respond to queries and the latency is small.

Figure 22 presents a summary of the delay. There are no lost packets, the average time is 3 ms. The results confirm the values obtained from the graph in Figure 21. Regardless of the attack, the web server of the VitalPBX responds to the requests. The system has not crashed.

4.1.4. Only Video Calls and UDP Flooding Attack

Figure 23 presents the summarized results of the video stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 23a shows the data for the video stream that is exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.20)—VM_2 (192.168.10.24). Figure 23b shows the parameter values in the opposite direction. The results are almost the same as the results when the system is attacked with a TCP SYN attack.

Figure 24 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to VitalPBX (black); from VitalPBX to VM_2 (blue); from VM_2 to VitalPBX (green); and from VitalPBX to VM_1 (brown)—are shown. During the UDP flooding attack, a constant jitter value of around 35 ms is observed, which is the same as the graph for the TCP SYN attack.

The computational load on the platform, incoming traffic, and network card load is almost the same as during this study when only voice traffic is exchanged.

Results for the change in round-trip delay during UDP flooding are not presented because the values obtained are almost the same as the results obtained during this study with a TCP SYN attack. Presenting these graphs would not lead to any significant new information.

4.2. Results for the Isabella

4.2.1. TCP DoS Attack

The Issabela ver. 5.0.0 is a free platform for making VoIP calls. The platform offers the possibility for anyone to develop additional add-ons or use ready-made ones created by the community [43]. Figure 25 represents the system load during the two simultaneous calls when the platform is not under attack. The results are from the dashboard panel where various system state data is visualized. The system is lightly loaded.

Figure 26 represents the communication load of the system. The four registered PJSIP subscribers, the two active calls, and the voice traffic being handled by the platform are visible.

Figure 27 presents the summarized results for the voice stream that is exchanged between VM_1 and VM_2 when the system is not under attack. Figure 27a shows the voice stream data that is exchanged in the direction VM_1 (192.168.10.9)—Issabela (192.168.10.7)—VM_2 (192.168.10.24). Figure 27b shows the parameter values in the reverse direction VM_2 to VM_1. All traffic has passed through and is processed by Issabela. The values of these parameters are very far from the maximum allowable values—there is no packet loss, and the average jitter is about 1 ms. The results are similar to those obtained during the VitalPBX study.

Figure 28 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation graphs for the four flows—VM_1 to Issabela (brown); from Issabela to VM_2 (black); from VM_2 to Issabela (green); and from Issabela to VM_1 (blue)—are shown. The obtained results are similar to those from VitalPBX.

Making video calls for this platform could not be implemented. Other users of the platform are also experiencing this problem. Therefore, this study with video calls was not carried out, but instead two studies were carried out with voice calls that are subjected to different TCP DoS attacks. In the first attack, the size of the attacking packets is set to the default values and during the second attack, the size of the attacking packets is set to 1000 bytes. During both attacks, the calls between the users are not stopped, only the attacks. The first attack is terminated after some time and then the second attack started immediately afterwards. The goal is to see how the attacked system would react when the size of the attacking packet is increased.

Figure 29 represents the system load during the two attacks. An increase in CPU load is noticed, which is normal. The memory load is unchanged.

Figure 30 represents the communication load of the system during the first attack. The difference with the results in Figure 26 is the increased traffic being handled by Issabela due to the attack.

Figure 31 represents the communication load of the system when the size of the attacking packets is set to 1000 bytes. The difference with Figure 30 is the many times increased incoming traffic, handled by Issabela (about 5 MB/s) due to the large attack packet sizes.

Figure 32 presents the summarized results of the audio stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 32a shows the data for the voice stream that is exchanged in the direction VM_1—Issabela—VM_2. Figure 32b shows the parameter values in the opposite direction. The average value of the jitter in both directions is almost the same as its value when the system is not attacked, and the values are close to the average value of the jitter when VitalPBX is attacked. There is more packet loss here compared to VitalPBX, but this is due to the fact that Issabela is attacked with large size packets.

Figure 33 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to Issabela (black); from Issabela to VM_2 (blue); from VM_2 to Issabela (brown); and from Issabela to VM_1 (green)—are shown. As can be seen from the results in Figure 28 and in this graph, the attack does not affect the value of the jitter.

Figure 34 represents how many packets, with the packet size set to the default, are sent during the attack—19,101,011 packets.

Figure 35 represents how the delay changes during the attack. Compared to the same results obtained for the VitalPBX study, here the attack has an impact. The delay varies between 200 and 250 ms, with a maximum allowable round-trip delay of 300 ms for normal multimedia traffic exchange. There is also a small amount of packet loss.

Figure 36 presents a summary of the delay, measured by using the ping command. The lost packets are 23 and the average time is 187 ms. The attack has an impact, albeit small.

Figure 37 represents how many packets, with a packet size of 1000 bytes, are sent during the attack—16,710,583 packets.

Figure 38 presents how the delay changes during the attack. The result is almost identical to the result from the first attack.

Figure 39 presents a summary of the delay, measured by using the ping command. As can be seen, there are more packets lost compared to the result from the first attack (Figure 36), 9%. There is a small reduction in the delay.

4.2.2. UDP Flooding Attack

Figure 40 presents the summarized results of the audio stream that is exchanged between VM_1 and VM_2 during the UDP flooding attack. Figure 40a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.9)—Issabela (192.168.10.18)—VM_2 (192.168.10.24). Figure 40b shows the parameter values in the opposite direction. There is a slight increase in the average jitter value and packet loss percentage compared to the results obtained during the second TCP SYN attack when the size of the attacking packets is set to 1000 bytes.

Figure 41 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to Issabela (black); from Issabela to VM_2 (blue); from VM_2 to Issabela (green); and from Issabela to VM_1 (brown)—are shown. Compared to the graph obtained during the second TCP SYN attack, there is an increase in the instantaneous jitter values for the entire duration of the conversation. This is due to the flooding with UDP packets, but the values remain within normal limits.

Figure 42 shows the computational load on the platform during the attack. The load on the platform is similar to the load when Issabela is not under attack.

Figure 43 shows the traffic processed by the platform during the attack. The platform processes about 6 MB/s, which indicates that the attack is successful and floods the server. The results are similar to those obtained during the second TCP SYN attack on Vital PBX.

Figure 44 shows the load on the server’s network card during the attack. The load is about 6%.

Again, results for the round-trip delay are not provided because they are similar to those obtained during the TCP SYN attack and will not add any new information.

4.3. CompletePBX 5

4.3.1. TCP DoS Attack

CompletePBX 5 ver. 5.2.27 is a temporary full-featured version of a paid VoIP PBX that allows users to test its functionality and suitability for their needs before committing to a purchase. CompletePBX 5 is a fully functional and free software PBX virtual machine. With the launch of the virtual machine, each user gets full access to all the built-in features of the PBX software. The CompletePBX 5 virtual machine is limited to three users only who can talk to each other. There is no video calling capability [44].

Figure 45 shows what the system load is during normal operation mode. The results are from the Dashboard of the system. The workload is the same as the other two studied systems. Conversation is only taking place between VM_1 and VM_2.

Figure 46 presents the summarized results for the voice stream that is exchanged between VM_1 and VM_2 when the system is not under attack. Figure 46a shows the data for the voice stream exchanged in the direction VM_1 (192.168.10.9)—CompletePBX 5 (192.168.10.3)—VM_2 (192.168.10.24). Figure 46b shows the parameter values in the opposite direction VM_2 to VM_1. The results are similar to those obtained for the other two systems. From the summarized data, it can be seen that the values of the tracked parameter are very far from the maximum allowed values.

Figure 47 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to CompletePBX 5 (brown); from CompletePBX 5 to VM_2 (blue); from VM_2 to CompletePBX 5 (green); and from VitalPBX to VM_1 (black)—are shown. As can be seen from the graph, the value of the jitter is within normal limits.

Making video calls could not be implemented on this platform either. Therefore, two studies were again carried out with voice calls that were subjected to different TCP DoS attacks. During the first attack, the size of the attacking packet is set to the default values—60 bytes. During the second attack, the packet size is set to 1000 bytes. Again, during both attacks, the conversations between the users were not stopped, only the attacks.

Figure 48 shows what the system load is during the first attack. The load is similar to the results when the system is not attacked.

Figure 49 shows what the system load is during the second attack. There is no significant change in the system load.

Figure 50 presents the summarized results of the audio stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 50a shows the data for the voice stream that is exchanged in the direction VM_1—CompletePBX 5—VM_2. Figure 50b shows the parameter values in the opposite direction. The values are almost similar to the values obtained in the study of the other two systems.

Figure 51 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to CompletePBX 5 (black); from CompletePBX 5 to VM_2 (blue); from VM_2 to CompletePBX 5 (brown); and from VitalPBX to VM_1 (green)—are shown. As can be seen from the graph, the value of the jitter is again within normal limits even during the attack.

Figure 52 represents how many packets, with the packet size set to the default (first attack), are sent during the attack—19,259,395 packets.

Figure 53 represents how the delay changes during the attack. The results are similar to those obtained for VitalPBX. The delay here is much smaller compared to the delay measured for Issabela. Here, the attack does not have an impact as it has on Issabela.

Figure 54 presents a summary of the delay during the first attack, measured by using the ping command. No packets are lost, and the delay is about 2 ms.

Figure 55 represents how many packets, with a packet size of 1000 bytes (the second attack), are sent during the attack—19,641,568 packets.

Figure 56 represents how the delay changes during the second attack. The results are similar to those of the first attack.

Figure 57 presents a summary of the delay during the second attack. The results are similar to those obtained during the first attack.

4.3.2. UDP Flooding Attack

Figure 58 presents the summarized results of the audio stream that is exchanged between VM_1 and VM_2 when the system is attacked. Figure 58a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.9)—CompletePBX 5 (192.168.10.3)—VM_2 (192.168.10.24). Figure 58b shows the parameter values in the opposite direction. Compared to the same results obtained during the second TCP SYN attack, there is an increase in the average jitter value. The percentage of lost packets is lower than in the TCP SYN attack study, but the difference between the two results is small.

Figure 59 represents how the jitter changes during the whole conversation between VM_1 and VM_2. The jitter variation plots for the four flows—VM_1 to CompletePBX 5 (brown); from CompletePBX 5 to VM_2 (black); from VM_2 to CompletePBX 5 (green); and from VitalPBX to VM_1 (blue)—are shown. Compared to the previous study, the UDP flooding attack leads again to an increase in the instantaneous jitter values.

Figure 60 shows what the system load is during the UDP flooding. Compared to the results obtained during the second TCP SYN attack, there is a slight increase in processor load.

Figure 61 shows the traffic processed by the platform during the attack. The results are similar to those obtained so far.

Figure 62 shows the load on the server’s network card during the attack. The load is about 6%, which is the same as the results for the other platforms.

Again, no results for the delay are provided because they are similar to those obtained during both the TCP SYN attacks and do not have any new information.

5. Discussion

5.1. Discussions About the VitalPBX Results

From the carried-out study and the results obtained, it is found that both DoS attacks (TCP SYN and UDP flooding) do not affect the voice flow parameters. The two main parameters that are observed, mean jitter and packet loss, are always within the norm. Even during the attacks, there is no significant deterioration in the values of these parameters. During both attacks, the web server responds to all requests despite being flooded. The delay is around 8 ms. The CPU utilization of the platform increases slightly, by around 1%. The attacks also did not cause VitalPBX to “freeze”, even though the server was flooded with TCP and UDP packets. The obtained results show that the UDP attack leads to a slight increase in the instantaneous values of the jitter. The system functioned normally.

In this study, when only video streams were exchanged, different results were obtained. Due to the TCP SYN attack, packet losses slightly increased. Nevertheless, the average jitter is higher, about 4 ms and 11 ms, and the delay is around 3 ms. During the UDP flooding, the mean jitter value again slightly increased compared to the TCP SYN attack. The packet loss is almost the same as it is for the TCP SYN attack. The server is not blocked; it is accessed without problems during both attacks.

The confirmation that DoS attacks would not affect system performance is represented by the results in Figure 63. The figure presents the results of running the “vuln” script in Nmap. Through this script, the studied device is tested for the most common vulnerabilities. As can be seen from the results, the VitalPBX is only slightly vulnerable to some DoS attacks that could possibly lead to a denial of service. The results also show that there are a few ports that are open, but no other network vulnerabilities are found.

5.2. Discussions About the Issabela Results

The obtained results for this platform are similar to those obtained for VitalPBX. The average jitter and packet loss were within the norm. CPU utilization increased by 8%, from 4% to 12% during the TCP SYN attack. This large increase in workload is due to the fact that two TCP DoS attacks were performed in the Issabela study—during the first attack, the size of the attacking packets is not changed, the default size of 60 bytes is used. During the second attack, the size of the attacking packets is set to 1000 bytes. During the TCP SYN attacks, the embedded web server was sometimes clogged and could not process all requests. This can be seen in the round-trip delay graphs and the results from the “ping” command. During both TCP SYN attacks, there were 23 packets lost during the first attack and 34 packets lost during the second attack, respectively.

During the UDP flooding, there is a slight increase in the mean jitter value and the packet loss, compared to the results for the second TCP SYN attack. Also, there is an increase in the instantaneous values of the jitter compared to the second TCP SYN attack. Nevertheless, the increases in the values are still below the maximum allowed levels.

Despite the presence of lost packets, large delay values, and increased jitter due to the both attacks, Issabela did not become overloaded during the attacks. There was access and phone calls could be constructed without problems.

The confirmation that the DoS attacks would not affect system performance is again proven by the results of running the “vuln” script in Nmap—Figure 64.

As can be seen from the results—they are similar to the results of the VitalPBX analysis—Issabela is again only slightly vulnerable to some DoS attacks that could potentially lead to a denial of service. Again, no such results were obtained during this study.

5.3. Discussions About the CompletePBX 5 Results

The results obtained for this platform do not differ much from the results of the other two studied platforms. Again, two TCP SYN attacks are carried out on this platform. The first attack is carried out with a default attacking packet size. The second attack is carried out with a changed attack packet size set to 1000 bytes. During these attacks, an increase in the CPU load is observed as it is for the other two platforms. The difference with the other two platforms is the increase in the percentage of packets lost, which is higher compared to the other two. There are no lost packets in the delay measurement.

The results for the UDP flooding attack are almost the same as the results obtained during the second TCP SYN attack.

Figure 65 shows the results of running the “vuln” script in Nmap. The main vulnerability discovered is cross-site request forgery (CSRF). CSRF is a vulnerability that allows an attacker to cause a user to perform actions that they did not intend to perform. Examples of CSRF are making a wire transfer; changing an email address or password; posting messages or images on social networks; and more [45]. Nmap does not detect a vulnerability to a DoS attack, which is indeed the case. This is confirmed by the results obtained for CompletePBX 5—both DoS attacks do not affect the performance of the platform.

5.4. Summary of Results

First, the obtained results during the TCP DoS are similar to the results obtained in the previous study—the TCP SYN attack does not affect the performance of the three studied VoIP platforms.

Table 1. Average values for the whole TCP SYN attack part study.

Platform	Mean Jitter (ms)	Packet Loss (%)	Delay (ms)	System State	CPU Load (%)
VitalPBX	7	0.025	6	Stable	3.6
Issabela	1.05	0.01	180	Stable	12
CompletePBX 5	1	0.025	2	Stable	6

presents summary data for this study relating to the TCP SYN attack. The data shown is average for the entire study.

Secondly, the obtained results for the three platforms during the UDP flooding are again similar to the results obtained in a previous study [46]—the UDP DoS attack does not affect the performance of the three studied VoIP platforms.

Table 2. Average values for the whole UDP flooding attack part study.

Platform	Mean Jitter (ms)	Packet Loss (%)	Delay (ms)	System State	CPU Load (%)
VitalPBX	3.8	0.022	5	Stable	3.37
Issabela	1.6	0.015	182	Stable	5
CompletePBX 5	1.86	0.01	3	Stable	11

presents summary data for this study relating to the UDP flooding attack. Again, the data shown is average for the entire study.

As can be seen from the two tables, there is a difference between the two studies. The TCP SYN attack has a greater impact on the mean jitter values for VitalPBX than the UDP flooding. For the other two platforms, UDP flooding leads to a deterioration in the jitter values.

The data on lost packets shows that the TCP SYN attack leads to more packet loss in CompletePBX 5 compared to the UDP flooding attack. For the other two platforms, there is no significant difference in the data between the two attacks.

The TCP SYN attack leads to greater processor load on VitalPBX and Issabela, while the UDP flooding leads to greater processor load on CompletePBX 5.

The delay is almost the same for both attacks.

All three platforms are stable during the both attacks

The three platforms operate without issues: memory load remains virtually unchanged; CPU load increases slightly during the attacks; conversations between users do not drop and conversations can be initiated/established during attacks; all three systems are accessible and can be operated.

This is because all three studied platforms are based on the Asterisk FreePBX. This study confirms that Asterisk FreePBX is sufficiently secure from the impact of various DoS attacks. The three studied VoIP platforms are suitable for small and medium-sized institutions, but for two of them (CompletePBX 5 and VitalPBX), prospective users need to purchase a license to be able to deploy the maximum number of users that are limited in the free versions. All three platforms are suitable for users who cannot afford large investments in additional cyber protection measures. With all three platforms, the only way to detect that a platform is being attacked with a DoS attack is by constantly monitoring the traffic coming into the VoIP server. With Issabela, there is no need to use an additional tool to monitor the incoming traffic—there is a traffic monitoring tool built into the Dashboard panel. For the other two platforms, an additional tool must be used. Another way to detect a DoS attack is to configure alarms to be sent when traffic increases above a certain value. As can be seen from this study, these are the only ways to detect the presence of a TCP DoS attack because this attack does not affect the quality of the voice flows—calls are not dropped, no delays occur, and there is no large packet loss. Regardless of the resilience of a TCP DoS attack, it is advisable to use other additional security measures, such as those discussed in [47,48,49,50,51,52,53].

It should be mentioned that the carried-out studies have been performed in a simulated environment and there is a difference between the latency in the real network devices and the emulated ones. This could produce different outcomes. Furthermore, the actual implementation of a denial-of-service attack can be carried out in a completely different way in a real network compared to a simulated network. Regardless of the fact that GNS 3 models IP networks are as close as possible to real ones, there is always a difference between real and modeled IP networks. Therefore, it is important to note that under the tested laboratory conditions, the TCP SYN and UDP DoS attacks did not significantly degrade VoIP performance.

6. Conclusions

Three VoIP PBXs from different developers were studied, all three based on Asterisk FreePBX.

This study showed that the TCP and UDP DoS attack did not significantly affect the parameters of voice and video streams, as well as the performance of the three studied VoIP platforms. Even though each of the studied VoIP servers was flooded with TCP and UDP packets, these floodings did not degrade the parameters of the individual VoIP flows. The average jitter and packet loss rates are within normal limits, very far from the maximum allowable levels, exceeding which would lead to a degradation of VoIP service quality.

During both attacks, all three platforms were accessible. CPU and memory load, on all three servers, was lightly loaded despite the flood with packets.

This study confirms the results obtained from the previous studies when Asterisk FreePBX was attacked with various TCP and UDP DoS attacks. In both the previous study and this study, it was found that both the DoS attacks did not affect the parameters of the VoIP flows and regardless of the attacks, the three servers are available and different VoIP calls can be made.

For future work, the idea is to repeat the same research, but this time to examine Asterisk PBX, which differs fundamentally from Asterisk FreePBX. This will allow us to determine whether the conclusions reached for Asterisk FreePBX also apply to Asterisk PBX. The idea is to conduct this research under Linux because of the limitations of GNS3 when running under Windows. Working under Linux allows us to use the full capabilities of GNS3, which are not available under Windows.

Another idea for future work is to repeat the same research, but this time using the EVE-NG IP network modeling platform, which, like GNS3, works with disk images of real network devices. This will allow a comparison between the two IP network modeling platforms.