Methodology for Studying the Level of Network Security of an IP PBX Server

Abstract

This paper presents a methodology for studying the level of network security of VoIP platforms. The methodology is designed for VoIP platforms where the voice and video traffic passes through and are processed by the VoIP server itself, rather than being exchanged directly between the end devices. The proposed methodology consists of four stages: scanning for open ports; scanning for well-known vulnerabilities; penetration testing; and finally, analysis and recommendations (if necessary). Well-known tools used for monitoring IP networks were used to implement the methodology: Namp, Wireshark, hping3, and Colasoft Capsa Free. The studied VoIP platforms were VitalPBX and Issabel, which are based on the Asterisk FreePBX platform. The penetration tests included attacking VitalPBX and Issabel with TCP and UDP DoS attacks. The penetration tests were carried out and implemented using the GNS3 IP network modeling platform. This study found that Issabel has many more unnecessarily open ports than VitalPBX; on both platforms, DoS attacks are likely to be unsuccessful, which was confirmed by the experimental studies carried out. The applicability of the proposed methodology was confirmed by the study carried out.

1. Introduction

VoIP (Voice over IP) is now established as the dominant technology for building internal telephone connections in companies. There are many reasons for this, but the main ones are the following advantages of using VoIP PBX [1,2,3,4,5,6,7,8,9,10] instead of a conventional digital telephone exchange:

• VoIP and the standard corporate LAN use the same network because both technologies use the IP technology. This means that maintenance costs are lower because only one network needs to be maintained instead of two different networks.
• The costs for technical support staff are reduced. Instead of employing separate staff to maintain the digital telephone network (phones and the telephone exchange) and additional technical staff to maintain the IP network and its end devices, a single technical team will be used to maintain only the IP network.
• Calls can be made from a computer, smartphone, tablet, or IP phone.
• VoIP allows regular analogue phones to be connected to a VoIP system using adapters (analog telephone adapters, ATAs). Therefore, the company can save money by reducing the need to buy physical IP phones during the initial launch of the VoIP system.
• VoIP technology offers many more services and features than standard digital telephone exchanges. One example is Follow Me (or Find Me/Follow Me). This is an advanced call-forwarding feature that “follows” the user by forwarding their incoming calls to different devices (mobile, home, IP phone) either in a predefined order or all at once. This means that they do not miss important customer calls, regardless of location, and allows employees to work flexibly from anywhere.
• There are many more other advantages and services that are offered only with VoIP technology.

Since the technology is IP-based, it means that every VoIP PBX server can be a potential victim of an attack. Therefore, before installing the respective VoIP distribution in the institution, it is important to carry out research to find out the level of network security of the particular VoIP distribution. Based on the results of this study, the administrator of the IP network on which the specific IP PBX distribution will be installed will know what actions need to be taken to ensure that the institution’s level of security is maintained.

This paper presents a simple methodology for studying the level of network security of a VoIP PBX server. The proposed methodology is a combination of different methods for assessing the level of network security of various network devices using an application for determining the level of network security of VoIP servers. These different methods are grouped into separate stages. Well-known tools are used to implement the individual stages, which are applied to find out network vulnerabilities.

By definition, voice and video traffic is not processed and does not pass through the VoIP server. It is exchanged only between the end devices—IP phones or softphones. The VoIP server is used only as a proxy between the end devices—it participates only in the process of establishing and terminating the connection. However, there are VoIP platforms, such as the Asterisk Free PBX, where the VoIP server is used not only in the process of establishing and terminating connections, but also in the processing of the voice and video streams. The presented methodology is suitable for use with VoIP platforms where the voice and the video traffic pass through and are processed by the VoIP server itself. Two Asterisk Free PBX-based platforms are studied: Issabel and VitalPBX. On both platforms, the VoIP server processes both service information and the voice and video traffic.

2. Related Works

VoIP has been steadily gaining ground for several years and is replacing existing telephone networks in organizations. Most organizations that have implemented VoIP technology are either unaware of or ignore the security and vulnerability issues. VoIP servers are also susceptible to abuse and easy to exploit. In [11], the authors examine various exploitation techniques, followed by penetration and security testing of VoIP machines. The authors carried out multiple attacks against an Asterisk-based VoIP server, including: 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), VoIP phishing (vishing). After carrying out the tests, they found that the VoIP communication technology is good and reliable for everyday use, but still requires many security measures to be implemented before it can be used. There are many unknown vulnerabilities that need to be discovered and removed before it can be used in everyday life. Without any vulnerability assessment, the use of VoIP technology can lead to security issues that can create major privacy problems in the future. And yet, many VoIP technologies do not use encryption to secure network traffic, which is the most common vulnerability in VoIP systems. These systems work with unencrypted data on the network, which is easy for attackers to eavesdrop on using network sniffing tools.

VoIP is an important technology in modern communication systems. Security is an important factor in the communication system. Today, the Session Initiation Protocol (SIP) is mainly used in VoIP services. SIP can be used for flooding too. Flooding is a type of denial-of-service attack in which the attacker interrupts user traffic by flooding it with data. In [12], the authors examine various technologies and methods for alerting users in order to prevent attacks. The authors describe the vulnerabilities and tests related to VoIP that are used in VoIP security tools to detect weaknesses that create threats and security issues in the technology. The authors examine various attacks against VoIP and discuss in detail denial-of-service attacks and ways to prevent them. In addition, they review many other prevention methods used in the past, as well as the latest ones. In this paper, the authors present a method called VoIPFD (voice over Internet protocol flooding detection), which is used to detect attacks in VoIP communications.

The impact of virtual collaboration and digital transformation has led to a significant increase in the use of VoIP technologies. VoIP, which operates on a client-server architecture to adapt to older circuit-switched technology, has gradually begun to use the P2P architecture in parallel with the development of this architecture. The lack of “peer admission” and “call flow control” features in pure P2P architecture has led to vulnerabilities against certain attacks, such as modification, termination, eavesdropping, and SPIT. Although various studies have been carried out to reduce these vulnerabilities in P2P systems on other platforms, the literature on P2P VoIP is limited. Studies using distributed blockchains have been limited to authentication and have not been able to eliminate the centralization of the system, retaining SIP servers in their architecture. In [13], the authors propose a P2P VoIP system and evaluate the possibility of managing user data through distributed blockchain technology. Their analyses show that this approach can improve security and decentralization in P2P VoIP. In addition, the authors carried out an in-depth assessment of the performance and security of the blockchain type, the consensus algorithm, and several blockchain architectures that will be used to manage this data, offering promising prospects for the future of P2P VoIP.

VoIP phones are early representatives and current enhancers of IoT. In [14], the authors note that they are still widely used in traditional, unsecure configurations and demonstrate the Phonejack family of attacks to readers. Phonejack 1 involves exploiting vulnerabilities in phones. Phonejack 2 demonstrates how to organize a denial-of-service attack on a network of phones. Phonejack 3 eavesdrops on conversations. The authors have found that inexpensive devices such as Raspberry Pi can be configured and programmed as effective countermeasures to the Phonejack-type attacks discussed, thus supporting the approach of integrating the two technologies. The authors argue that confidence in basic network security measures may be overly optimistic. VoIP phones really need to be secure, just as almost all devices with Internet access are secure today.

VoIP is one of the most widely used technologies in the communications industry. An important feature of any computer system is the way it provides security, the hierarchy of access to information, and the way it secures itself from intentional or unauthorized access attempts. Ensuring the security of Internet communications can be compared to signing a letter and sending it in a sealed envelope. The signature guarantees the authenticity of the letter, and the sealed envelope ensures the necessary confidentiality. In [15], the authors present a study in the field of information system security, optimizing the implementation of security policies at the communication network level in order to ensure data protection. The study was carried out using Cisco packet tracer. The study emphasizes that auditing VoIP platforms or networks are an important step in achieving their security. There are many problems in the VoIP technology that have a negative impact on security. For example, the use of a highly secure session can be affected by poor service quality. At the same time, insecure communication can be affected if session protocols send the encryption key in clear text.

With the widespread adoption of VoIP on the Internet, SIP security issues have received considerable attention from researchers, and the authentication mechanism in SIP is becoming increasingly important. Many studies have revealed that the initial version of the SIP specification is vulnerable to malicious attacks. To improve the security of the SIP authentication mechanism, numerous changes and additions have been made over the years. Studies of the previous specification have been carried out and some attacks, such as replay attacks, online dictionary attacks, man-in-the-middle attacks, etc. have been found out to be easily implemented. Despite these studies, no analyses have been carried out on the security of the new SIP security mechanisms. In [16], the authors make precisely such an analysis. They analyze the security properties of the SIP Digest Access Authentication Scheme using the SPAN (Security Protocol Animator) protocol analysis tool. In the work, the authors present a formal approach to analyzing the SIP Digest authentication scheme based on SPAN analysis. Two models of the SIP Digest authentication scheme were created in two practical scenarios. Although the result of the analysis is that access authentication is secure, the authors note that it is not possible to absolutely confirm that the mechanism is secure. Nevertheless, the method is applicable to formal analytical needs.

The security and confidentiality of participants’ data in video conferences is becoming a major issue. Despite its importance, forensic analysis of video conferencing applications, which are part of the large group of VoIP technologies, remains a relatively understudied area. In [17], the authors present a detailed analysis of the Cisco WebEx video conferencing application on the Windows operating system in the areas of memory forensics, disk space forensics, and network forensics. The analysis shows that valuable user data can be extracted from various sources. These include: user emails; user IDs; profile pictures; sent and deleted chat messages; shared media; meeting information, including meeting passwords; Advanced Encryption Standard (AES) keys; keyword searches; timestamps; and log files. Although network communications are encrypted, some useful data can be extracted, such as IP addresses of server domains and host devices, along with message/event timestamps. Digital certificates for video conference communications can also be extracted.

VoIP communication applications are among the most widely used applications for keeping people connected. These popular applications, such as WhatsApp, Skype, and Viber, although widely used on mobile devices, also offer desktop versions. Numerous researchers have carried out significant research in the field of digital forensics with regard to these popular applications, both for mobile and desktop devices. However, there is a lack of research related to other VoIP applications such as Discord, which is one of the most widely used methods of communication. In [18], the authors examine the desktop version of Discord for Windows 10. The study was carried out from the perspective of forensics and cybersecurity. The results show that copies of text messages can be recovered along with cached images that have been sent/received. The authors discussed the security aspects of any information stored locally and provided guidance to forensic investigators and users regarding the confidentiality of their data.

The authors of [11,15] point out that further researches are needed to find out more possible network vulnerabilities in the VoIP technology. The proposed methodology aims to do exactly this—to study the level of network security of VoIP servers. To find out potential network vulnerabilities, which can then be eliminated. The methodology presented in this paper is more generalized compared to the works discussed in this section. The proposed methodology is of medium difficulty to implement. Well-known tools are used. This work also aims to enrich the current knowledge on the subject.

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

3.1. Research Methodology

For the purposes of this study, two VoIP platforms based on the Asterisk Free PBX were studied—VitalPBX and Issabel. This study was be carried out as follows. Each of the two platforms were virtualized independently in a modeled IP network. A certain number of subscribers were be added to it. Each of the two platforms were subjected to various studies and tests related to the individual stages of the proposed methodology.

The penetration tests were divided into two parts. First, penetration tests were performed when only audio streams were exchanged, and then only video streams were exchanged in the network. The purpose of this division was to obtain results that are specific to the particular group of multimedia streams. The obtained results show how the different DoS attacks affect only the parameters of voice streams and what effect they have on the parameters of video streams. In addition, the penetration tests themselves were also separated—the platforms were first attacked with TCP SYN and then with a UDP DoS attack. This was also done in order to present a comparison of how the different types of DoS attacks affect the parameters of the voice and video streams.

During the DoS attacks, the size of the attacking packets are set to the size of 1000 bytes. These packets are sent in a series, approximately every 200 µs. This time is not configured and it is the default value.

Voice and video calls (where possible) were made in the simulated network. The use of simulation programs and platforms has many advantages, without which the research would be impossible. These platforms make it possible to study and implement various processes that cannot be implemented in the real world or whose implementation involves significant financial costs associated with the purchase of expensive equipment [19,20,21,22,23,24,25,26,27,28,29]. The obtained results were compared and analyzed. This made it possible to determine the level of network security of each of the platforms.

3.2. Topology of the Experimental Network

The workstation on which the network is modeled is a dual-processor with 2x Xeon Gold 6138 CPU, 192 GB of RAM, Nvidia RTX4000 with 8 GB of VRAM. VMware Workstation Pro (version 25) is used as a hypervisor.

Figure 1 shows the topology of the modeled network. The GNS3 IP network modeling platform [30] was used to implement the network.

VoIP_server is a virtual machine (hypervisor) of the tested VoIP platform (VitalPBX or Issabel). Both virtual machines have 4 dedicated processor cores and 4 GB of RAM.

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.

Cloud 1 is a module through which the modeled network connects to the Internet. Internet connectivity is required for some of the network vulnerability tests because the database is too large to be stored in Kali Linux. Therefore, during the specific test, Kali Linux must be connected to the Internet to access these databases.

Kali_Linux is a Kali Linux virtual machine through which the studied VoIP platform is attacked and tested. The virtual machine has 3 dedicated processor cores and 4 GB of RAM.

ESW1 and ESW2 are emulated disk images of manageable switches. No configurations were made on them—it is as if they had just been taken out of the box and turned on. They function as ordinary switches.

VM_1 to VM_4 are virtual machines on which Windows 10 is virtualized. These virtual machines have 4 dedicated processor cores and 8 GB of RAM. They are used as subscribers to the VoIP servers. A software phone was installed on each of them. They were able to make video and audio calls.

There are no restrictions on the network throughput in the simulated network.

3.3. Used Tools

The following tools were used for the purposes of this study:

• Network protocol analyzer—Wireshark [31] was used for the purposes of this study. It captured all packets exchanged between the VoIP server and its subscribers. Its main advantage, which led to the use of this tool, is its built-in capabilities for analyzing VoIP streams;
• hping3—This is a tool built into Kali Linux. It is used to create custom TCP/UDP packets. These packets are used to launch various TCP/UDP DoS attacks [32]. In this study, hping3 was used to implement different DoS attacks;
• Nmap—This tool is also part of the Kali Linux toolkit. It is used to scan ports, identify different network vulnerabilities, and more [33]. In this study, the analysis functionality of Nmap was used, which is based on specialized scripts. These scripts are used to analyze a particular network device for various network vulnerabilities;
• Network analyzer: Colasoft Capsa 11 free [34] was used for this work. It is used to monitor the entering/leaving traffic of the studied VoIP platform. This tool was used to determine how the VoIP platform responds to the penetration tests.

4. Developed Methodology

Figure 2 presents the developed methodology.

The first stage is to identify open ports. This is an important step because every hacker always performs this check. Unnecessary open ports are similar to open doors that anyone can walk through. Therefore, these vulnerabilities must be eliminated. To eliminate them, it is necessary to know which ports are open, whether they are needed or not, and to close the unnecessary ones.

The next stage is testing for Common Vulnerabilities and Exposures (CVEs). At this stage, the VoIP platform is subjected to special tests and analysis using specialized scripts with the help of the Nmap tool. For example, some of these scripts can be used to examine the VoIP platform to determine whether its built-in web server is vulnerable to any well-known vulnerabilities. After each script is executed, Nmap presents an analysis of the test results.

Step three of the proposed methodology is carrying out penetration tests. Various attacks are applied to the VoIP platform under study to find out how these attacks affect the performance of the VoIP platform. In this work, the studied VoIP platforms were subjected to TCP DoS and UDP DoS attacks to determine how the different DoS attacks affect the performance of the studied platforms. Do they affect the parameters of the voice and video streams? Does the server become inaccessible? Does it crash? Pen testing the VoIP platforms with DoS attacks was chosen because the developed methodology is intended for VoIP platforms where voice and video traffic pass through the VoIP server and are processed by it. Thus, theoretically, a successful DoS attack will make the server crash and all VoIP calls to drop.

The final stage is an analysis of the obtained results and making recommendations. In this last step, the obtained results from the previous stages are analyzed and, if necessary, recommendations are made to improve the network security level of the studied VoIP platform.

5. Results

5.1. Results for VitalPBX

In this free version (community version) of the platform, the main limitation is the maximum number of subscribers. It is set to 12. For the purposes of this work, only four subscribers were added to the server. Other limitations of the platform are described in [35].

5.1.1. Identifying Network Vulnerabilities

Figure 3 shows the result of the first stage of the proposed methodology—port scanning. The “-sS” command represents a TCP SYN scan, which uses a half-open scan because a full TCP connection is not opened. This scan is also called a stealth scan. SYN packets are sent as if a real connection is going to be established, and then a response is awaited. SYN/ACK indicates that the port is in listening mode (open), while RST indicates that the port is not in listening mode (closed). If no response is received after several repetitions, the port is marked as filtered. The port is also marked as filtered if an ICMP unreachable error is received. The port is also considered open if a SYN packet (without an ACK flag) is received in response. This may be due to an extremely rare TCP feature known as simultaneous open or split handshake. This scan is slow and takes longer to test all ports. As can be seen, there are few open ports. Of interest are ports 22, 80, and 443, through which the system can be accessed remotely. Port 3501 connects to proprietary applications, sometimes used for things like remote access, game servers, or custom network management, although its specific use depends entirely on the software that uses it. Port 3500 is often used by specific applications for secure connections, potentially for older Blackberry Enterprise Servers (BESs). It is characterized by vulnerabilities in devices such as EMC AlphaStor (software for managing archival tape backups and sharing libraries) for remote command execution. This is a dynamic port for various proprietary or lesser-known network functions. Ports 5060 and 5061 are used for SIP exchange.

Figure 4 shows the result of finding out whether the tested web server is vulnerable to a slowloris DoS attack, without launching an actual DoS attack. This is a denial-of-service attack program that allows the attacker to overload the attacked server by opening and maintaining many simultaneous HTTP connections [36]. This test is from the second stage of the proposed methodology. The test is performed using a specially developed script in Nmap.

As can be seen, the script tested both accesses to the platform—via an HTTP session and an HTTPS session. For both tests, the result is “LIKELY VULNERABLE.” This means that the server is subject to a time-out attack, but depending on the architecture of the web server, complete denial of service is not always possible. A time-out attack (slowloris or slow read attack) is a modified version of a DoS attack, which is characterized by attacking with low-speed (slow) streams of packets. The attack deliberately works slowly, gradually consuming the server’s resources until it crashes, rather than overloading the server with a huge amount of data all at once. Since most web servers have a limit on the number of simultaneous connections they can handle, using such an attack enables the following possibilities: opening multiple simultaneous connections to the server; sending only part of the request; maintaining the connection constantly; the server keeps all these connections open, waiting for the requests to complete, but at a certain point all available connections are occupied and legitimate users receive a message that the server is unavailable. Of course, full testing requires a real DoS attack to determine whether the server will still be operational during the DoS attack.

The next step in this stage of the proposed methodology is to test the system to see if VitalPBX web server is vulnerable to a slowloris DoS attack. Executing this script launches a slowloris attack. This script opens and maintains multiple “half-HTTP” connections until the server exhausts its resources, resulting in a denial of service [37]. Figure 5 shows the result of running this script. “--max-parallelism 400” defines the number of simultaneous connections, which for this particular test is set to 400 (this is the minimum recommended value from the developers of the script). As can be seen when testing the two possible sessions—through port 80 and port 443—the attack is unsuccessful. This result confirms the result of running the script from the previous study.

Figure 6 shows the results of testing the ciphers supported by the studied platform. This script repeatedly initiates SSLv3/TLS connections, each time trying a new cipher or compressor, while recording whether the host accepts or rejects it. The end result is a list of all cipher suites and compressors that the server accepts. Each cipher suite is shown with a letter grade (from A to F) that indicates the strength of the connection. The grade is based on the cryptographic strength of the exchanged key and the encryption throughput. The rating is based on the Qualys SSL Labs SSL Server Rating Guide [38]. As can be seen, all supported ciphers are rated with the highest grade.

The next network vulnerability test is performed using the “vulners” script. This script is used for passive vulnerability detection. It identifies potential security gaps by comparing the software versions found during the Nmap scan with the extensive Vulners.com vulnerability database [39]. For the test to be successful, an Internet connection is required. Because of this requirement, the simulated network must be connected to the Internet. The results in Figure 7 reveal the vulnerabilities and how they can be exploited to compromise the system.

The final test in the second stage of the methodology is testing the system with the “vuln” script. Nmap includes a special “vuln” category that runs all scripts designed to check for specific, well-known vulnerabilities (e.g., CVE, default passwords, SQL injection and other). Running the “vuln” script starts the execution of all scripts in the “vuln” category. Figure 8 shows the result of running the script. In addition to the already discovered possibility of a successful DoS attack, the script discovers another vulnerability that allows for a cross-site request forgery (CSRF) attack. In this attack, the attacker tricks the user or browser into sending an HTTP request to the target site from a malicious site. The request includes the user’s access data and causes the server to perform some harmful action, thinking that the user intended to do so.

5.1.2. Penetration Tests During Audio Calls Only

The third stage of the methodology involves carrying out penetration tests. The tests include attacking the platform with a TCP and UDP DoS attack while the system is only processing voice calls. During this study the number of simultaneous calls was two, because there were only four subscribers in the network—VM_1 to VM_4. These calls lasted about 10 min. These tests verified whether the results from the study carried out in the second stage of the methodology were confirmed. Secondly, they investigated whether the DoS attacks affect the parameters of the voice and the video streams. During these steps, the simulated network is not connected to the Internet. The connection between R1 and the Cloud1 module was deleted so that the simulated network was isolated.

Normal Operation Mode

The purpose of this mode was to use the obtained results as a benchmark, so we could compare them to the results we got during the attacks. This is the best way to compare what happens to the attacked platform before and during the attacks.

Figure 9 shows the load on the VitalPBX server in normal operating mode, during the exchange of voice streams only. There are four subscribers talking to each other, in two simultaneous calls. The load of the system is low. The data is from the platform’s Dashboard menu.

Figure 10 shows the processed traffic by VitalPBX in normal mode, when four subscribers are talking to each other. The result is obtained from Colasft Capsa 11 free. The traffic is normal for an audio conversation.

Figure 11 presents a summary result for the voice stream that was exchanged between VM_1 and VM_2 when the system was not under attack. The results are from the analysis carried out with Wireshark. 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.10)—VM_2 (192.168.10.11). Figure 11b 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. The parameters that are monitored and used to estimate the quality of the VoIP flows 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% [40,41]. From the summarized data, it can be seen that the values of these parameters are very far from the maximum allowable values—there are a total of four lost packets in both directions, and the average/mean jitter value is between 9.8 and 15 ms.

TCP DoS Attack

Figure 12 shows the traffic processed by VitalPBX during the attack. Traffic has increased many times over. VitalPBX is flooded with TCP requests.

Figure 13 shows the load on the VitalPBX network card during the attack.

Figure 14 shows the load of VitalPBX. The CPU load increased slightly—by 0.34%— and the memory load by just over 1%. These increases are negligible compared to the “flooding” that the server is subjected to.

Figure 15 presents a summary result for the voice stream that was exchanged between VM_1 and VM_2 when the system was under the TCP DoS attack. Figure 15a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.10)—VM_2 (192.168.10.11). Figure 15b shows the values in the reverse direction VM_2 to VM_1. During the TCP DoS attack the total number of lost packets in both directions increased to 26 packets. The average jitter value is almost the same as during normal operation. Even though the server is flooded with TCP requests, the quality of the voice streams is not affected.

The hping3 tool was used to carry out the attack. Figure 16 shows how many packets were sent during the attack—27,159,630. The attack used was TCP SYN flooding.

Figure 17 shows the distribution of the different TCP packets processed by VitalPBX. There is a huge number of TCP SYN packets sent to VitalPBX. Regardless of this flood, VitalPBX is accessible via a browser. This is proven by the presence of TCP FIN packets, which terminated the few successful TCP sessions through which the platform was accessed.

UDP DoS Attack

Figure 18 shows the traffic processed by VitalPBX during the attack. The result is similar to that obtained during the TCP DoS attack.

Figure 19 shows the load on the VitalPBX network card during the attack. Again, the result is similar to that obtained during the TCP DoS attack.

Figure 20 shows what the load is. The attack only led to an increase in processor load of just over 1% compared to the result of the TCP attack.

Figure 21 presents a summary of the results for the voice stream that was exchanged between VM_1 and VM_2 when the system was under the UDP DoS attack. Figure 21a shows the data for the voice stream exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.10)—VM_2 (192.168.10.11). Figure 21b shows the values in the reverse direction, from VM_2 to VM_1. During the UDP DoS attack the total number of lost packets in both directions has decreased to 12 packets. The average jitter value remains almost unchanged. The data shows that the UDP DoS attack is less demanding than the TCP DoS attack.

Figure 22 represents the number of packets sent during the attack—40469068.

Figure 23 shows the distribution of the different TCP packets. Despite being flooded with UDP packets, VitalPBX is still accessible via a browser. This is proven by the presence of TCP FIN and TCP ACK packets, which are indicators of successfully established and terminated TCP sessions during which the platform was accessed.

5.1.3. Penetration Tests During Video Calls Only

VitalPBX also allows video calls to be set up. For the purposes of this study, there were two subscribers who carried out a video call between themselves during the penetration tests. The duration of the video calls was approximately 10 min.

Normal Operation Mode

Figure 24 shows the load on the VitalPBX server in normal operating mode, during the exchange of video streams only. Unlike the study related to voice streams, here, the processor load is slightly higher, as is the memory load. This is normal because the server processes video streams, which are more labor-intensive to process.

Figure 25 shows the processed traffic by VitalPBX in normal mode. The traffic is higher compared to voice traffic only, which is normal for video calls.

Figure 26 presents a summary of the results for the video stream that was exchanged between VM_1 and VM_2 when the system was not under attack. Figure 26a shows the data for the voice stream that was exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.10)—VM_2 (192.168.10.11). Figure 26b shows the values in the reverse direction, from VM_2 to VM_1. Again, all the video traffic passes through and is processed by VitalPBX. From the summarized data, it can be seen that the values of the monitored parameters are again very far from the maximum allowable values—there are a total of 23 lost packets in both directions, and the mean jitter value is between 2.7 and 3.2 ms.

TCP DoS Attack

Figure 27 shows the traffic processed by VitalPBX during the attack. VitalPBX is flooded with TCP requests. The result is similar to that obtained in tests when only voice traffic is exchanged.

Figure 28 shows the load on VitalPBX network card during the attack. Again, the result is similar to that obtained during the TCP DoS attack.

Figure 29 shows the load of VitalPBX during the attack. The values are close to those during normal operation. These increases are negligible compared to the “flooding” to which the server is subjected.

Figure 30 presents a summary result for the video stream that was exchanged between VM_1 and VM_2 when the system was under attack. Figure 30a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.10)—VM_2 (192.168.10.11). Figure 30b shows the values in the reverse direction VM_2 to VM_1. There is no change in the average jitter value, which is almost equal to the value in normal mode. The total number of lost packets in both directions has increased to 92 packets.

Figure 31 represents the number of packets sent during the attack—22,669,732.

Figure 32 shows the distribution of the different TCP packets. VitalPBX is again accessible via a browser, regardless of the flood with TCP SYN requests. This is proven by the presence of TCP FIN packets, which are an indicator of successfully established and terminated TCP sessions during which the platform was accessed.

UDP DoS Attack

Figure 33 shows the load on VitalPBX during the attack. The CPU load has almost doubled compared to the previous results, while the memory load remains almost unchanged.

The results for the processed traffic and the network card load will not be presented because they are exactly the same as those presented so far and will not provide any new information.

Figure 34 presents a summary result for the video stream that was exchanged between VM_1 and VM_2 when the system was under attack. Figure 34a shows the data for the voice stream that is exchanged in the direction VM_1 (192.168.10.9)—VitalPBX (192.168.10.10)—VM_2 (192.168.10.11). Figure 34b shows the values in the reverse direction VM_2 to VM_1. In the direction from VM2 to VM1, there is an increase in the average jitter value, but there are almost no lost packets. In the direction from VM1 to VM2, the average jitter value is almost unchanged, but the number of lost packets is high—63 lost packets.

Figure 35 represents the number of packets sent during the attack—22,352,362.

Figure 36 shows the distribution of the different TCP packets. The result is the same as for the study carried out with voice stream exchange only—VitalPBX can be successfully accessed via a browser.

5.2. Results for Issabel

This 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 [42].

5.2.1. Finding out Network Vulnerabilities

Figure 37 shows the result of the first stage of the proposed methodology—port scanning. The result is almost identical to the result for VitalPBX, but there are several additional open ports. These are 25, 110, 143, 993, 995, and 4190, which are used for exchanging e-mails. Port 1720 is an old protocol used for exchanging service information before, during, and after a call. It has now been replaced by SIP, using port 5060. Port 3306 is used for network access to MySQL databases. Ports 4445, 5038, and 8089 are used for remote access and remote management of web platforms. Since Issabel offers remote support through a subscription, these ports are used for these purposes. Through ports 22, 80, 443, and 8088, the system can be accessed remotely. Port 5060 is used for SIP exchange.

Figure 38 shows the result of determining whether the tested web server is vulnerable to a slowloris DoS attack. The result shows that the script only tested access to the platform via a HTTP session through port 8088, which is configured to be the main access port. The result is “LIKELY VULNERABLE,” which was the result for VitalPBX. Complete denial of service is not always possible.

Figure 39 shows the result of running the script that tests whether Issabel’s web server is vulnerable to a slowloris DoS attack. Only one session was tested—through port 8088. The attack was unsuccessful, as was the result for VitalPBX.

Figure 40 presents the results of the test for the ciphers supported by the tested platform. Once again, all supported ciphers received the highest grade.

The next test for network vulnerabilities is performed using the “vulners” script. The results, shown in Figure 41a,b, reveal the vulnerabilities and how they can be exploited to compromise the system.

The last test from the second stage of the methodology is testing the system with the “vuln” script. Figure 42 shows the result of running the script. Apart from the already discovered possibility of a successful DoS attack, the script does not find out any other vulnerabilities.

5.2.2. Penetration Tests During Audio Call Only

Issabel, similar to VitalPVX, was subjected to penetration tests. Again, during the tests, there were two simultaneous calls because there were only four subscribers in the network—VM_1 to VM_4. The tests involved attacking the platform with TCP and UDP DoS attacks while the system was processing only voice calls. Again, the calls lasted about 10 min.

Normal Operation Mode

Figure 43 shows Issabel’s load during normal operation, when only voice streams are exchanged. The data is from the platform’s Dashboard menu.

Figure 44 shows the communication load on the system. There are four registered PJSIP subscribers, two active calls, and the voice traffic processed by the platform. The data is from the platform’s Dashboard menu.

Figure 45 shows the processed traffic by Issabel in normal mode when four subscribers are talking to each other. The traffic is normal for an audio conversation.

Figure 46 presents a summary of the results for the voice stream that was exchanged between VM_1 and VM_2 when the system was not under attack. Figure 46a shows the data for the voice stream exchanged in the direction VM_1 (192.168.10.13)—Issabel (192.168.10.2)—VM_2 (192.168.10.40). Figure 46b shows the values in the reverse direction, from VM_2 to VM_1. Again, all traffic passes through and is processed by Issabel. Unlike the results obtained for VitalPBX, the average jitter values here are several times lower. Meanwhile, the number of lost packets in both directions is almost equal—seven for Issabel and five for VitalPBX.

TCP DoS Attack

Figure 47 shows Issabel’s load during the attack. The CPU load increased to 22%, while the memory load remained unchanged.

Figure 48 shows the communication load on the system. Incoming traffic has increased significantly due to the attack, to around 5.8 MB/s. Outgoing traffic has also increased compared to normal operation—341 KB/s.

A graph showing the network card load will not be presented because the obtained result is similar to the results presented so far and will not provide any new information.

Figure 49 presents a summary of the results for the voice stream that was exchanged between VM_1 and VM_2 when the system was under attack. Figure 49a shows the data for the voice stream that was exchanged in the direction VM_1 (192.168.10.13)—Issabel (192.168.10.2)—VM_2 (192.168.10.40). Figure 49b shows the values in the reverse direction, from VM_2 to VM_1. The only significant difference with the result obtained when Issabel is not attacked is the loss of only one packet. The average jitter value is identical to the value obtained when the platform is not attacked.

Figure 50 represents the number of packets sent during the attack—20,556,445.

Figure 51 shows the distribution of the different TCP packets processed by Issabel. Again, there is a huge amount of TCP SYN packets sent to the server. The huge number of TCP RST packets are generated by Issabel’s built-in web server in order to terminate the problematic session. Such reaction is missing for VItalPBX. This shows that the developers of the platforms use different web servers. Regardless of this flooding, Issabel is accessible via a browser. This is proven by the presence of TCP FIN packets, which terminated the few successful TCP sessions through which the platform was accessed via a browser.

UDP DoS Attack

Figure 52 shows Issabel’s load during the attack. The CPU load dropped to 12%, which is lower than the load when the platform is not under attack. The memory load increased slightly.

Figure 53 shows the communication load of the system. Incoming traffic increased from 5.8 MB/s during the TCP DoS attack to 7.17 MB/s. This is normal because during UDP flooding, a huge number of UDP packets are observed. Outgoing traffic is reduced compared to the study during the TCP DoS attack—around 44 kB/s. The value is the same as when the platform is not under attack. This is because no TCP RST packets are generated, through which the built-in web server wants to terminate a problematic TCP session, because there is no such session.

The network card load graph will not be presented again because the obtained result is similar to the results presented so far and will not provide any new information.

Figure 54 presents a summary of the results for the voice stream that was exchanged between VM_1 and VM_2 when the system was under attack. Figure 54a shows the data for the voice stream that was exchanged in the direction VM_1 (192.168.10.13)—Issabel (192.168.10.2)—VM_2 (192.168.10.40). Figure 54b shows the values in the reverse direction, from VM_2 to VM_1. The only difference from the result obtained when Issabel is subjected to a TCP DoS attack is the increased packet loss—from 1 to 4 lost packets during a UDP DoS attack. The average jitter value remains unchanged compared to when the platform is attacked with a TCP DoS attack.

Figure 55 represents the number of packets sent during the attack—20,556,445.

Figure 56 shows the distribution of the different TCP packets processed by Issabel. The result is similar to that obtained in the VitalPBX study, when it was attacked with a UDP DoS attack. Issabel continued to be accessible via a browser.

Penetration tests when Issabel processes video streams were not carried out due to the inability to start video calls, even though video calls are officially supported by the platform. Many users also report similar problems in numerous technical support forums, including the inability to carry out video calls with Issabel.

6. Analysis and Recommendations

The final stage of the developed methodology is an analysis of the obtained results and recommendations for improving network security.

Both VoIP platforms have a limited number of open ports, some of which are the same on both platforms. VitalPBX has fewer open ports and fewer unnecessary ports that need to be closed. These are: 22, 3500, 3501. They are unusable for VoIP technology and pose a risk to the security of the platform. Therefore, they must be blocked. Issabel has more open ports, most of which are unnecessary for VoIP technology. These are ports: 25, 110, 143, 993, 995, 1720, 3306, 4190, 4445, 5038, 8089. All of them provide security gaps in the platform and must be neutralized.

Both platforms support multiple encryption algorithms, which have been highly rated by Namp.

Both platforms were tested for any vulnerabilities. The result for both was “LIKELY VULNERABLE” to a slowloris DoS attack. An additional potential vulnerability was observed in VitalPBX—a cross-site request forgery (CSRF) attack. No such vulnerability was found in the Issabel study.

The results of the tests to determine whether the tested web server on both platforms is vulnerable to a slowloris DoS attack are positive from a security perspective. For both platforms, the result was “LIKELY VULNERABLE,” which means that in the event of a DoS attack, the attack may have no effect on the respective platform: it will continue to be accessible and fully operational. This result was also confirmed by tests to see if the built-in web server on both platforms would crash if attacked with a slowloris DoS attack. The results for both platforms were again positive from a security perspective—the attack was not successful. The experimental study confirmed the results from Namp. Both platforms were attacked with TCP and UDP DoS attacks. During the attacks, both servers were accessible without any problems via a browser. This means that the built-in web servers on both platforms are designed to withstand DoS attacks. Of course, additional actions must be taken to secure both devices from DoS attacks, such as the well-known ones:

• Network segmentation by creating VLANs and using hardware firewalls.
• Load balancing—distributing traffic across multiple servers.
• Blocking traffic from known or suspected IP addresses that have been associated with DoS attacks in the past or present.
• Limiting traffic speed, thus preventing server overload from a DoS attack.
• Using Content Delivery Networks (CDNs)—this distributes the content of the website across several locations, preventing a DoS attack from bringing down the entire site.

Based on the results obtained from the experimental study, it was found that TCP and UDP DoS attacks did not lead to serious deterioration of the voice and video stream parameters. Regardless of the attacks, calls did not drop and were established without problems during the attacks. Both platforms were accessible without problems via a browser, and various configuration menus could be accessed.

Both platforms support encryption for remote access data exchange via port 443 HTTPS (HyperText Transfer Protocol Secure). This functionality must be enabled for both platforms because VitalPBX and Issabel support encryption ciphers that are highly rated by Nmap. This will minimize the risk of interception of the exchanged information related to platform configuration, user names, passwords, and other data.

Mandatory closing of unnecessary open ports.

For VitalPBX and Issabel, the only way to detect whether a platform is under a DoS attack is through constant monitoring of the incoming traffic. Issabel does not require the use of an additional tool, as the Dashboard panel has a built-in traffic monitoring tool. For VitalPBX, an additional tool is required. Another way to detect a DoS attack is to configure alerts to be sent when traffic exceeds a certain value. As can be seen from this study, these are the only ways to detect a TCP or UDP DoS attack, as these attacks do not affect the quality of the voice streams—calls are not dropped, there are no delays, and there is no significant packet loss.

Regardless of resistance to DoS attacks, it is advisable to use other additional security measures, such as those mentioned in [43,44,45,46,47,48,49,50,51,52].

7. Conclusions

A methodology for studying the level of network security of VoIP servers has been proposed. The proposed methodology is applicable to VoIP platforms where all voice and video traffic is processed and passes through the VoIP server, rather than being exchanged only between the end devices.

Well-known tools used in IP network monitoring were used to implement the methodology. The methodology itself is simple and moderately difficult to implement, using entirely free tools.

Two VoIP platforms, VitalPBX and Issabel, were studied. Both are based on the Asterisk FreePBX. Although they are based on the same platform, there are differences between the two. The most significant difference is in the open ports. This study revealed that Issabel has many more unnecessarily open ports than VitalPBX.

For both platforms, it was found that DoS attacks are unlikely to affect their performance—DoS attacks have no effect on them. This was proven by the experimental research related to penetration tests. TCP and UDP DoS attacks do not affect the performance of either platform: VitalPBX and Issabel were accessible via a browser during the attacks.

An analysis with actions to increase the level of network security on both platforms is presented, based on the obtained results from the applied methodology.

The applicability of the methodology has been proven by the obtained results.

For future activities, switching to another platform for IP network modeling is considering—EVE NG—which differs significantly from GNS3 and offers other possibilities. Another direction being considered is switching to using GNS3 entirely under Linux instead of Windows ,as has been the case so far. The need to switch to Linux is due to the fact that under Linux there are no limitations on the capabilities of GNS3, as there are under Windows. The final direction for future development is the application of the developed methodology to real, physical VoIP servers installed in real IP networks. This will allow a comparison between the results obtained from the current work and the results obtained from the study of a real working platform.

It is important to note that these studies were carried out in a simulated environment, and there is a difference between real network devices and emulated ones. This can lead to different results. Furthermore, the actual execution of a denial-of-service attack may 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 as closely as possible to real ones, there is always a difference between real and simulated IP networks. Therefore, it is important to note that under the tested laboratory conditions, TCP and UDP DoS attacks did not significantly degrade VoIP performance.

Limitations in GNS3’s capabilities are due to the use of Windows as the operating system. Many GNS3 users in various technology forums have indicated the huge difference in GNS3’s performance and usability when running on Linux. When GNS3 runs on the Linux operating system, the limitations imposed by Windows are absent, and the platform works to its full potential.