A Simple Experimental Stand for Studying the Network Security Level of Power Electronic Devices

Abstract

In this work the use of an experimental setup for studying the network security level of power electronic devices is proposed. A methodology which represents the individual stages of the studying process of the network security level of power electronic devices is also developed. To prove the applicability of the developed experimental setup, two power distribution units were studied. The experimental setup is simple and easy to implement. It uses well known tools for network security analysis and traffic monitoring. From the experimental studies carried out, it was found that the two power distribution units have similar network vulnerabilities and the exchange of the information is unsecure. From the penetration tests carried-out, expected results were found, but unexpected ones were also found. The experimental results prove the applicability of the developed experimental setup for studying the network security level of power electronic devices.

1. Introduction

In terms of communication capabilities, power electronic devices (PEDs) have reached their maximum. Almost any PED, if designed to have this functionality, can now be connected to an IP network. So, it will be controlled or monitored remotely. Years ago, this was impossible, or rather impractical, because the purpose of a PED is to supply power to different devices or to convert electrical energy with some parameters into electrical energy with other parameters [1,2,3,4,5]. But with the rapid development of the Internet and the evolution of the idea of connectivity of any devices to the Internet, PEDs such as inverters, PV controllers, PDUs, UPSs and others can now be connected to the Internet. However, being connected to the Internet poses many risks. As it is known, any device that is connected to the Internet is a potential victim of an attack, which is designed to abuse that device.

PEDs can be considered as part of the critical infrastructure group. Therefore, they are important devices because without them it would not be possible to supply power to the various devices, used for building telecommunication networks, such as switches, routers, servers and others. Therefore, it is necessary for the PEDs that will be connected to IP networks, especially if they will be monitored/controlled over the Internet, to be secured [6,7,8,9,10,11,12,13,14,15,16,17,18,19]. Hacking a PED can lead to various undesirable consequences, depending on the devices that are power supplied by the PED, such as the following:

• Shutting down/hard restart servers—if a PED is used to supply power to servers and it is hacked, the attacker at any time can shut down or constantly restart the server(s) that are power supplied by that PED;
• Sabotage the whole or part of an ISP network—if PEDs are used for supplying power to network devices that are used for building up the ISP’s communications network, hacking them would lead to possible temporary disruptions in network operation (e.g., the attacker intentionally restarts network devices periodically by commanding the hacked PEDs) or to a complete network shutdown, again due to controlling the PEDs;
• Editing data related to the values of current, voltage, frequency, power, etc. These manipulated data can lead to errors/problems in the operability of devices such as electric vehicle charging stations.

Therefore, it is necessary to conduct research to find out the network security level of a particular PED before it is installed/connected in the corresponding IP network. Why conduct such research? As mentioned above, PEDs now have the ability to connect to IP networks or the Internet. So, they can be considered as network devices and can be attacked like any other network device. This means that connecting such a device that has not been previously studied for possible network security vulnerabilities would compromise the entire network. No serious network administrator would connect an unstudied device to the network they maintain because it would “expose” the network. Common questions that these administrators ask the installers of various devices with network functionality (the ability to connect to IP networks), such as NVRs, DVRs, security system modules, or access control systems, through which these systems will be monitored remotely, are as follows: which network ports they are using; what traffic they are generating; any additional open ports; is the data exchange encrypted, etc? The installers themselves, in most cases, cannot provide such information because they do not know it. In most cases, some of this information is not even given in the technical documentation of the devices. And providing information about how the devices’ performance changes during various cyber-attacks has not occurred to the manufacturers/developers of these modules at all.

Answering these questions, as well as the experience I have gained during the study of IP networks, gave me the idea for the realization of the presented experimental setup. It is a result of many years of studies related to monitoring and characterizing of the communication traffic exchanged in different IP networks and characterizing the communication traffic generated by PEDs.

The purpose of this work is to demonstrate the feasibility of a simple and easy-to-implement testbed for studying the network security level of a PED. Despite the simplicity of the proposed method, it is effective and can be used for any type of PED as long as it has the functionality to connect to IP networks. The applicability of the testbed has been demonstrated through experiments carried out with different PEDs.

2. Types of Cyber-Attacks and Vulnerabilities Applicable to Power Electronic Devices

Since the communication link between the PED and the user is through the Internet or some other IP network, the information exchange/data flow can be attacked. Since PEDs already have network functionalities, they can be considered as typical network devices. Due to this functionality, the damage/manipulation of the PED can now be done remotely without the need for physical access to it. The attacks that are inherent to IP networks and modern communication networks in general are the same for PEDs. These attacks can lead to various situations, such as incorrect battery charging, unwanted turning on or off of various devices, intentional damage to devices, theft of money during a payment transaction for the energy consumed by the electric vehicle during the charge, etc.

2.1. Vulnerabilities Specific to the PED

Vulnerabilities are a broad category of flaws, potential “cracks” and weaknesses in the system hardware, software of a network device [20,21,22,23,24,25]. These vulnerabilities can be classified as follows:

• Physical—means that the device is easily accessible by anyone who wants to harm it. Examples of such vulnerabilities are the physical manipulation of inverters or PV controllers installed in some unattended solar farm. If measures are not taken to physically protect these PEDs, the same can be very easily manipulated, resulting in the operation of the target park being suspended;
• Network vulnerabilities—this type of vulnerability is related to the interaction between the PED and the IP network. When a PED connects to an IP network which is connected to the Internet, it immediately becomes a potential victim of attack. If the PED is not secured from attacks, it can very easily be taken under remote control. These vulnerabilities make it very easy for a PED to be remotely taken over and controlled.

The vulnerabilities that are specific to standard network devices can be said to be applied to PEDs as well. Of course, PEDs are not network devices and they have more limited network functionalities. In general, the communication capabilities are limited to a simple web server (http server) through which the PED is monitored and managed, i.e., vulnerabilities related to the operating system such as malware are not common for PEDs. Therefore, it can be argued that mainly network vulnerabilities related to web servers are the most common for PEDs. Examples of such vulnerabilities are the use of http instead of https; the use of weak passwords; unnecessarily open ports; and vulnerability to DoS attacks, etc.

2.2. Attacks Specific to PEDs

Attacks that are specific to PEDs can be divided into two broad groups—attacks aimed at blocking the access/operation of the PEDs and attacks aimed at taking full control of the PEDs.

2.2.1. Attacks Aimed at Blocking Access to the PED

Denial-of-service (DoS) are attacks in which a device’s resources are overloaded and it cannot respond to the received requests. Distributed denial-of-service (DDoS) is the same attack as DoS, except that the source of the attack is not a single device, but multiple devices that are infected with malware controlled by the attacker.

TCP SYN flood attack: in this attack, the attacker exploits the working principle of the TCP protocol. TCP is connection oriented, i.e., before the data exchange between the client and the web server of the PED is started, an exchange procedure of service packets is started during which the way of the real data exchange is determined. During this session establishment process between the client and the server, the attacker device (the client) floods the attacked device (the web server of the PED) with connection requests (TCP SYN packets). The server responds to the sent requests, but the attacking device does not. This causes the attacked system (web server of the PED) to wait. While it waits for a response from the attacker device (it waits for the TCP ACK packets), the attacker continues to continuously send new requests (TCP SYN packets) to which the web server of the PED responds. This causes the web server of the PED to crash or become unusable when the connection request queue fills up—Figure 1.

There are many other TCP DoS attacks such as TCP ACK attack, TCP FIN attack, TCP RST attack, which aim to restrict legitimate access to the corresponding PED.

Teardrop attack: this is a type of denial of service (DoS) attack that uses fragmented data packets to flood the web server of the PED or the victim’s network. The attack results in overlapping length compensation fields and fragmentation in successive packets in the attacked device. The attacked device attempts to reconstruct the packets but fails. This causes the connection to the device to crash. These attacks typically target servers that have existing TCP/IP vulnerabilities. Ultimately, they exploit the way IP packets are fragmented and reassembled to bypass traditional security controls.

Smurf attack: this attack involves using IP spoofing and ICMP to saturate the attacked device with traffic. This attack method uses ICMP echo requests directed to broadcast IP addresses. First, the attacker uses malware to create spoofed packets whose source address is set as the IP address of the attacked device—the PED. The packet is then sent to the IP broadcast address of a router. The router sends requests to every device in the broadcast network, with the number of requests increasing with the number of devices in the network. Each device in the network receives the request from the router and then responds to the spoofed address with ICMP Echo Reply packets. The PED receives a stream of ICMP Echo Reply packets. As a result, the PED’s embedded web server can be overloaded and cause a denial of service. This process is repetitive and can be automated to generate huge amounts of traffic, which can also lead to network congestion—Figure 2.

Ping of dead: this type of attack uses IP packets to “ping” the PED with an IP packet size above the maximum of 65,535 bytes. IP packets of this size are not allowed, so the attacker fragments the IP packet into smaller packets. Once the attacked device (the web server of the PED) assembles the packet, it may experience buffer overflows and other crashes.

Botnets: botnets are systems infected with malware that are under foreign control for the purpose of carrying out DDoS attacks. These bots or zombie systems are used to carry out attacks against various devices and networks. For example, an attack can be built like this to attack a PED. As a result of the bot attacks, the attacked PED is rendered inoperable due to overloading its embedded web server or taking up all the bandwidth on the network where it is installed. These DDoS attacks are difficult to track because the botnets are located in different geographical locations—Figure 3.

2.2.2. Attacks Aimed at Taking Control of the PED or Modifying the Information Exchange

Eavesdropping: this is an attack in which the information exchanged between the PED and the control and management center is eavesdropped/monitored—Figure 4. In this attack, the exchanged information is not changed, only collected, and can be copied to a specific server. This type of attack can be divided into two types:

• Passive eavesdropping: the exchanged information is only monitored, not collected;
• Active eavesdropping: the exchanged information is collected by specially designed programs and devices. The collected information is then recorded or forwarded to a dedicated server.

Figure 4. Example of an eavesdropping attack.

Figure 4. Example of an eavesdropping attack.

Then the collected information can be analyzed and used at a later stage for hacking the PED.

Man in the Middle attack: in this attack, another device or the attacker himself is placed between two communicating devices (the PED and the Control center), which secretly redirects or modifies information between these devices while they are connected. Thus, instead of information being exchanged between the two trusted devices, the information passes through the attacker. There are different types of MITM:

• Session hijacking: in this type of MITM attack, the attacker redirects the session to establish a connection between the two devices. The attacking device replaces its IP address with that of the Control center and the PED starts exchanging data with the attacking device instead of with the Control center. An example of a MITM session hijacking attack is an active eavesdropping. During this attack the attacker makes independent connections to the two devices, the PED and the Control center. It starts sending messages between them to make them believe they are connected directly to each other, when in fact the entire session is being controlled by the attacker. The attacker can now intercept any messages that pass between the two devices as well as insert new messages into the session—Figure 5.

• IP Spoofing: IP spoofing is the creation of packets with a false source IP address in order to impersonate another computer system, network or device. This type of attack can be used to “convince” the PED that it is communicating with the monitoring and control center. So, the attacker grants access to the PED. The attack is carried out as follows: the attacking device sends a packet with a known, secure IP address instead of its real IP address. Thus, the PED accepts this address and starts exchanging data with the attacking device thinking it is secure—Figure 6.

• Replay attack: in this attack valid data transmission is repeated or delayed in a malicious or fraudulent manner. For example, the attacker has intercepted the data between the PED and the control and monitoring center. It then retransmits them, potentially causing unauthorized actions or gaining access. This attack exploits the lack of proper authentication mechanisms in protocols, making this attack a significant threat to data integrity and security. The attack is characterized by two stages. The first stage is interception. The attacker intercepts a valid data transmission between the PED and the control and monitoring center. This could be, for example, a login/access session to the PED. The second stage is re-transmission—the attacker re-sends the intercepted data to the PED, making it look like a legitimate message from the original sender. This can trick the PED into taking action based on the reused data—Figure 7.

False data injection attack: in this attack, the hacked PED can be made to send incorrect data. For example, an attacker has hacked a smart meter. As a result, the meter starts reading incorrectly, which may result in paying higher bills or reporting no energy consumed.

3. Related Work

In [26], the authors address the challenges related to firmware security, vehicle charging safety, and power management security of connected electric vehicles. They have studied the vulnerabilities of electric vehicles to various cyber-attacks ranging from energy efficiency attacks to safety attacks. Simulations, including hardware in the loop studies, have been carried out to analyze the impact of cyber-attacks at both the power converter (device) and vehicle (system) level. The authors propose an architecture for the next generation of power electronics systems to address the cyber-physical security challenges of electric vehicles. The authors have also addressed potential research opportunities involving firmware vulnerability detection, model-based and data-driven detection and mitigation of these vulnerabilities.

In [25], the authors focus on Grid-Connected Power Electronics Converters (GCPECs), providing a comprehensive literature review of existing results from selected sources in the aspects of vulnerabilities, countermeasures and test environments. By analyzing the GCPEC structure, the authors find that GCPEC vulnerabilities include both cyber and physical layers that are easily accessible to hackers. These vulnerabilities in both layers should be considered simultaneously and coordinated well with each other. Hardware protection is an essential approach to enhancing cybersecurity within the GCPEC. The authors find that detection and mitigation approaches must be taken into account for the complexity of the algorithms to be implemented and assess the limits of computational and data processing capabilities within the GCPEC while evaluating the feasibility and applicability of various techniques and methods to counter cyberattacks at test centers. In addition, countermeasures must comply with relevant standards to ensure the interoperability and cyber security of GCPEC devices in smart grids. Finally, based on the review and analysis, the authors have specified four recommendations for future research on the cybersecurity of GCPECs and their applications in smart grids.

In [27], the authors present a network-level cybersecurity vulnerability assessment specific to synchrophasor measurement devices. A synchrophasor network is essential for a wide area metering system (WAMS) that collects time-synchronized data from multiple components of the power grid and facilitates the processing and transmission of this data. Hackers can use their knowledge of firmware and protocols to disrupt or damage the operation of the power system in an inconspicuous manner. However, exploitation can be limited or controlled if the operator is aware of the vulnerabilities. The authors have made a classification of attacks in the synchrophasor network. What type of resources and intelligence are sufficient to carry out an attack on field synchrophasor devices? They have identified and demonstrated what would happen if someone were to exploit the vulnerabilities found in the synchrophasor devices. The reverse-engineered attack by the authors focuses on capturing essential packet characteristics and consuming bandwidth during the three-way handshake between legitimate entities. The packet transmission delay gradually increases, leading to retransmission; thus, the legitimate link is terminated. Through their paper, the authors show, at the device level, reliable information regarding the gaps and weaknesses in field synchrophasor devices.

The network security of a battery management system (BMS) is an essential factor to consider as more and more battery systems need internet connectivity for functionality such as intelligent monitoring, control and maintenance. In [28], the authors discuss the vulnerabilities that would lead to potential cyber-attacks. The authors have considered different defensive strategies to reduce the impact of these vulnerabilities, as well as the application of blockchain technology in BMS, which is proposed to be used as a reference for baseline cybersecurity for BMS developers. The implementation of blockchain technology holds promise for securing BMS from malicious cyber-physical attacks and for ensuring the secure use of battery systems for multiple applications in cyber-physical environments.

Recent standards have also defined a mandatory set of control parameters for grid-tied power converters, which should be able to be controlled from a remote hub that sends commands over a communications network. While such remote control capability enables many new features for managing grid-tied power converters, this functionality also makes them vulnerable to cyber-attacks. In [29], the authors consider the blocks of power converter control systems that are vulnerable to cyber-attacks. Then, the authors reviewed typical cyber-attacks by considering different applications of grid-tied power converters. Additionally, the authors examined the impact of different types of cyberattacks on grid support functions. Finally, the authors provide a summary and recommendations for further research.

In [24], the authors have provided an in-depth review of the current issues related to cyber vulnerabilities in cyber-physical power systems (CPPS), reflecting the latest developments in the field to date. This includes an in-depth analysis of the diverse types of cyber threats specific to CPPS and their potential implications. The authors delve into the complexity of cyberattacks, examining sophisticated and targeted attacks alongside the usual threats, and emphasizing the dynamic nature of cyberthreats. Their review highlights critical but often overlooked challenges, such as system visibility and standardization of security protocols, arguing for their importance in enhancing CPPS resilience. In addition, the authors pay particular attention to aspects of recovery from a cyberattack, an area that has received less attention in the existing literature. The authors conceive their work as a kind of reference guide, displaying information on research, practice and policy development dedicated to ensuring the safety, reliability and resilience of ICT-integrated power systems.

While recent advances in control and communications have improved the functionality of power converters in applications such as electric vehicles and smart grids, these functionalities have also led to new vulnerabilities, especially to cyber-physical attacks. In [30], the authors present a systematic review of the resilience framework for cyber-physical systems (CPSs) based on power electronic converters, emphasizing the emerging challenges posed by cyber-physical attacks. In their work, the authors categorize state-of-the-art research into four key attack phases: anticipation and preparation; resistance and absorption; detection and assessment; and recovery. The authors address modeling of attacks on transducers and cyber-physical devices; testbeds for transducer-based CPS; system protection at the cyber- and physical-layer; attack detection; post-attack assessment; and recovery strategies. The authors have analyzed real case studies and practical problems. In addition, the authors discuss the challenges and opportunities of the resilience framework.

In [16], the authors make a detailed study of the cyber security of cyber-physical high voltage direct current (HVDC) systems. The authors have provided a comprehensive review of state-of-the-art HVDC systems, paying special attention to cyber threats and vulnerabilities, protection and mitigation strategies, and test environments. Based on the review and analysis, the authors offer recommendations for future research directions to address gaps in this area of study. According to the authors, future research in this area should prioritize in integrating cyber and physical data into a single system to focus on detecting, at an early stage, attacks to mitigate the potentially serious impacts of cyber-attacks on HVDC networks.

In [12], the authors study the security vulnerabilities of photovoltaic (PV) inverters, paying special attention to their internal sensors, which are critical for reliable energy conversion. The authors found that both current and voltage sensors are susceptible to electromagnetic interference (EMI) at frequencies of 1 GHz or higher, regardless of the presence of electromagnetic compatibility (EMC) protections. These vulnerabilities can lead to incorrect sensor readings, disrupting control algorithms. The authors propose an EMI attack that leads to three potential outcomes: denial of service (DoS), physical failure of the inverter, and reduction in output power. These effects have been observed on six commercial single-phase and three-phase PV inverters as well as in a real microgrid. The results were obtained by irradiating with EMI signals from a distance of 100–150 cm with power up to 20 W. This study by the authors highlights the increasing security risks of power electronics in renewable energy sources (RES), which represents a new target for cyber-physical attacks in future RES-dominated grids. Finally, the authors propose three methods to deal with such threats that are adaptive to different threat scenarios, and their advantages and disadvantages are discussed.

In [18], the authors discussed the cybersecurity of smart microgrids in detail. In their work, they have briefly discussed the cyber physical systems in smart microgrids. Then, they focus on cyber-attacks on data availability, integrity and confidentiality. False data injection (FDI) compromises the integrity of data in the cyber/communication network and is one of the most challenging threats to smart microgrids. Therefore, this attack is discussed in detail in the work. Such FDI attacks can target voltage and frequency management as well as secure systems of smart microgrids. In their work, the authors have also considered the economic and physical–technical impacts of FDI attacks on smart microgrids. The defense strategies against these attacks, according to the authors, are classified into protection strategies, where selected instrument measurements are protected, and detection/limiting strategies, based on static or dynamic detection. Additionally, the authors have given examples of the implementation of building FDI attacks, detecting them and limiting them in smart microgrids.

4. Proposed Experimental Testbed and Methodology to Study the Network Security Level of a PED

In this work, a simple and relatively easy-to-implement experimental setup is proposed, which can be used to study the network security level of any PEDs. The only condition is that the PEDs under study must have the ability to connect to IP networks. Based on this simple and effective experimental setup, a methodology is developed to describe the different stages of the study and what exactly is being studied.

4.1. Developed Experimental Stand

Figure 8 shows the topology of the proposed experimental setup used to study the network security level of a PED. The experimental setup consists of the following devices:

• Studied PED: this is the PED to be studied. It can be any kind of PED as long as it has the capability to connect to an IP network;
• Managed switch: the managed switch is needed because the port mirroring functionality is required for the bench purposes. By using this functionality, all traffic from a specific port or from all ports is copied to one specific port to which a monitoring station connects. In this way, the traffic generated by the studied PED is not “mixed” with the other traffic and it is known exactly what the traffic generated by the PED is;
• Monitoring station: this is a workstation on which special tools are installed to monitor the traffic. Through this machine only the generated traffic from the PED is monitored and recorded;
• Kali Linux: this is a workstation with Kali Linux version 2024.4 installed on it. Some of the operating system tools are used to perform the PED network security level study.

Figure 8. Topology of the experimental stand.

Figure 8. Topology of the experimental stand.

4.2. Developed Methodology

Figure 9 presents the developed methodology.

The first stage of the study is finding out of open ports. This is an important study because every hacker always does this check first. Excess open ports are like open doors through which anyone can enter. Therefore, this vulnerability should be eliminated. To eliminate it, we need to know which ports are open and close the unnecessary ones.

The next stage is to analyze the PED for well-known network vulnerabilities. In this stage, the PED will be subjected to special analysis through specialized scripts using a special tool. Through these scripts the PED is tested to find out if its embedded web server is vulnerable to some of the well-known vulnerabilities. After the execution of each script, the used tool presents an analysis report of the test performed.

Step three of the proposed methodology is to carry out a study whereby it can be found out whether the information exchanged between the PED and the user/control and management center is secure or not—whether the transmitted data are encrypted or transmitted in plain text;

Step four of the proposed methodology is carrying out penetration tests. Different attacks will be applied on the studied PED to find out how these attacks affect the PED performance. In this work, the PED will be subjected to different TCP DoS attacks to examine how different TCP DoS attacks affect the performance of the studied PED.

The last stage is analysis of the results and recommendations. In this stage, the obtained results from the previous stages will be analyzed and, if necessary, recommendations will be proposed to enhance the network security of the studied PED.

5. Used Tools

For the purpose of this work the following tools were used:

• Network protocol analyzer: for this work, Wireshark ver. 4.4.7 [31] was used. It is installed on the monitoring station and captures all packets exchanged with the studied PED. It is used to execute step 3 of the proposed methodology—finding out whether the exchanged information is secure or not;
• Network analyzer: for this work, Colasoft Capsa 11 free [32] was used. It is also installed on the monitoring station and is used to monitor the traffic entering/exiting the network interface of the studied PED. This tool will be used to observe the response of the PED when it is subjected to the various TCP DoS attacks;
• Burp Suite Community Edition: this is a platform for performing security tests on web applications [33]. It is used in step three of the proposed methodology as a validation of the obtained results from the Wireshark;
• Nmap: this is used to discover hosts and links in a computer network by sending packets and analyzing the responses [34]. It is part of the built-in tools of Kali Linux. It provides many capabilities for exploring computer networks, host discovery, service and operating system discovery. By using specialized scripts, it can be used to identify vulnerabilities. Nmap is used in the first and second steps of the developed methodology;
• hping3: this is a tool that can be used to scan a network/device as well as to generate altered ICMP/UDP/TCP packets for implementing various DoS attacks [35]. It is one of the built-in tools of Kali Linux. The tool is used in the first and last stages of the developed methodology.

These tools are chosen due to several factors:

• First: they are free. There is no need to pay for them, which means anyone can use them. Thus, the proposed experimental setup for studying the level of network security of PEDs is much more affordable and almost anyone can implement it using these free tools;
• Second: regardless of being free, the information they provide is reliable and trustworthy. They are used by everyone who is involved in network security monitoring of various network devices. There is an endless amount of information on the Internet about how and what these tools can be used for, which is what makes them so popular among network security enthusiasts and researchers;
• Third: they are easy to work with. For example, Capsa 11 presents information in a graphical form, and one can choose what the refresh interval should be, which results in a change of the graph. Changing this interval produces different graphs that can be used to represent different stages of a study.

6. Results

In order to validate the applicability of the developed bench and methodology, several PEDs—more specifically several PDUs—will be studied. The PDUs are of different manufacturers and with different additional capabilities. The first PDU is from a world-famous manufacturer—EATON (30 Pembroke Road, Dublin, Ireland 4, IE)— and the other PDU is from a local, Bulgarian, manufacturer of electronic devices NeoMontana (Neomontana electronics, 1715 Sofia, Bulgaria, Mladost-4, bl. 483). The Neomontana PDU is used by one of the telecommunication operators in Bulgaria for remote monitoring and remote power supply management of various network devices.

6.1. Results from the Study of the EATON PDU

Figure 10 presents the result of scanning for open ports, which is the first step of the proposed methodology. The TCP SYN scan command “-sS” was used, which is relatively unobtrusive and hidden as it never completes the TCP handshake. As can be seen from the result there is only one open port, 80, through which the studied PDU is accessed and managed.

Figure 11 presents the result of the open port scan with hping3, which was done to confirm the results of the Nmap scan. As can be seen from the result, again only port 80 is open, the rest are closed. The result confirms the results obtained by Nmap.

For the second step of the methodology, analyzing for well-known vulnerabilities, the Nmap tool was again used. Figure 12 presents the result of the analysis of the EATON PDU when it was subjected to a slowloris attack (slowloris is a DoS attack that allows the attacker to overwhelm the attacked server by opening and maintaining many concurrent HTTP connections between the attacker and the target). As can be seen from the result, Nmap cannot give a concrete answer as to whether the studied PDU is vulnerable to DoS attacks or not. In order to determine this, it is necessary to perform penetration tests with DoS attacks.

The PDU was also studied for any possible vulnerabilities using the “vuln” command—Figure 13. As can be seen from the result, no vulnerabilities were found except the open port 80.

The third step of the methodology is to verify that the information exchange between the PDU and the user/monitoring center is secure. Figure 14 shows that the exchanged information is partially secure. From the obtained result using Burp suite ver. 2024.9.4, it can be seen that the username is transmitted in plain text while the password is not.

Figure 15 shows the page in the settings menu of the studied PDU where the username and password are changed. In this case the password is changed to “password”.

In addition, all statistical information about the values of the voltage, current, power consumption is transmitted in plain text and can be manipulated.

Figure 16 confirms the Burp suite results. As can be seen from the Wireshark window, the username is sent in plain text, while the password is not. The presented result confirms the result from Figure 14. The result from Figure 15 is also confirmed by Wireshark—it is exactly the same as from the Burp Suite and therefore is not presented.

The final stage of the methodology is to attack the studied PDU with different DoS attacks to find out how different DoS attacks affect the PDU performance.

Figure 17 represents the distribution of different TCP packets in normal mode—the device is accessed without problem through a browser. The result is from Colasoft Capsa Free. As can be seen from the figure, the TCP session is successful—this is evidenced by the presence of TCP FIN packets which terminate a normal successful TCP session.

Figure 18 represents how many packets were sent during the TCP SYN DoS attack (this attack consists of flooding the attacked device with TCP SYN requests that the attacked device cannot respond to because it is continuously flooded with more and more TCP requests [36]). A total of 40,694,371 packets were sent. The attack is performed using the hping3 tool. Figure 19 shows the result of the “ping” command during the attack. From 135 packets, only 2 packets are received, and 2 packets are received incorrectly. The losses were 98.5%. The device is unreachable.

Figure 20 represents the TCP packet distribution during the attack. As can be seen, the number of TCP SYN packets is several tens of thousands due to the flooding. The device is inaccessible because there are no TCP SYNACK and TCP FIN packets exchanged are typical for a successful session. The presence of TCP RST packets is due to the efforts of the built-in web server trying to terminate the problematic session, but it cannot.

Figure 21 represents how many packets are sent during the TCP ACK DoS attack (in this attack, the attacked device is flooded with TCP ACK packets. These packets are exchanged during the three-way handshake and are used to confirm that the device has received the TCP SYN packet and is ready to establish a TCP session with the other device that sent the TCP SYN packets. The purpose of this attack is to block the attack by overloading its computing or bandwidth resources [37]). A total 31,302,021 packets were sent.

Figure 22 shows the result of the “ping” command during the attack. Out of 111 packets, only 2 packets were received. The losses were 98.2%. The device is inaccessible again.

Figure 23 represents what the TCP packet distribution was during the attack. As can be seen from the figure, there is an increase in TCP RST packets, which are several thousands, because the embedded web server is trying to terminate the problematic session, but it cannot. The device is inaccessible because there are no TCP SYNACK and TCP FIN packets that are exchanged on a successful session.

Figure 24 shows how many packets were sent during the TCP RST DoS attack (this attack is a type of DDoS attack that aims to disrupt network connectivity by flooding the bandwidth and the computational resources of the attacked device by continuously sending TCP RST packets [38]). A total of 34,433,619 packets were sent. Figure 25 shows the result of the “ping” command during the attack. From 118 packets, only 3 were received. The losses were 97.4%. The device is still inaccessible.

Figure 26 represents the TCP packet distribution during the attack. As can be seen from the figure, there is a huge increase in TCP RST packets, which are several tens of thousands. To this number can be included the RST packets that are generated by the embedded web server that tries to terminate the problematic session, but it cannot. The device is inaccessible.

Figure 27 represents how many packets are sent during the TCP FIN DoS attack. In this attack, the victim receives a stream of TCP FIN packets that are not associated with any of the already established TCP sessions in the attacked device’s database. It is forced to dedicate a significant portion of its computational resources to processing the incoming TCP FIN packets, resulting in a degraded working performance of the attacked device. Sometimes this attack may result in the inability to access the attacked device [39]). A total of 35,201,536 packets were sent. Figure 28 represents the result of the “ping” command during the attack. Out of 122 packets, only 1 is received. The losses were 99.2%. The device is still inaccessible.

Figure 29 represents the TCP packet distribution during the attack. As can be seen from the figure, there is a huge increase in TCP FIN packets, which are several tens of thousands. The device is inaccessible.

Figure 30 represents the traffic the EATON PDU processed during the four attacks. As can be seen from the graph, the traffic processed during the attacks was huge, which is normal for this type of attack.

6.2. Results of the NeoMontana PDU Study

Figure 31 shows the result of the open port scan. As with the EATON PDU there is only one open port—port 80, used for remote accessing and management the PDU.

Again, to confirm the Nmap results, a scan was also carried out with hping3. The result is the same—Figure 32.

The second step of the methodology is to analyze for well-known vulnerabilities. Figure 33 presents the result of the PDU analysis when it was subjected to the slowloris script. As can be seen from the result, the analysis for this vulnerability shows that the device is partially vulnerable to DoS attacks—“LIKELY VULNERABLE”. This result means that not all DoS attacks would be successful. This depends on how the developed embedded web server works. To verify this result, a penetration test will be carried out with different DoS attacks. This will reveal whether the embedded web server is indeed able to handle some of the DoS attacks.

The studied PDU was also examined for all possible vulnerabilities using the vuln script—Figure 34. As can be seen from the presented result, only two vulnerabilities are present—the open port 80 and the possibility for some DoS attacks to succeed in blocking the operation of the embedded web server.

Figure 35 shows that the exchanged information is not secured. Unlike the PDU of Eaton, for this PDU the username and password are exchanged with simple Base64 coding, which is a binary-to-text coding/encoding scheme. It is used to transmit data stored in binary formats over channels that reliably support text-only content. This kind of encoding can be decoded very easily, as can be seen from the result.

Figure 36 shows the page in the settings menu of the PDU where the username and password are changed. In this case, the password is changed from “admin” to “password”. This result is similar to the result in Figure 15. Again, all statistical information about the values of the voltage, current, temperature, and humidity are transmitted in plain text.

Figure 37 confirms the Burp suite results. As can be seen from the Wireshark window, the username and password are sent encoded via Base 64. The presented result confirms the result in Figure 35. The result from Figure 36 is also confirmed by Wireshark—it is exactly like the Burp Suite results and therefore are not presented.

Figure 38 represents the distribution of the different TCP packets in normal operation mode. As can be seen from the figure, the TCP session is successful—this is evidenced by the presence of TCP SYNACK packets and the TCP FIN packets that terminate a TCP session.

Figure 39 represents how many packets were sent during the TCP SYN DoS attack. A total of 40,032,361 packets were sent.

Figure 40 represents the result of the “ping” command during the attack. Out of 39 packets, only 6 packets were received. The losses were 79%. The device is inaccessible.

Figure 41 represents the TCP packet distribution during the attack. As can be seen, the number of TCP SYN packets is around 40,000 because of the flooding. The device is inaccessible because there is no exchange of TCP SYNACK and TCP FIN packets. The presence of few TCP RST packets is due to the embedded web server trying to terminate the problematic session, but it cannot.

Figure 42 represents how many packets were sent during the TCP ACK DoS attack. A total of 50,298,424 packets were sent.

Figure 43 represents the result of the “ping” command during the attack. Out of 120 packets, only 119 packets were received. The losses were 0%. The device is accessible.

Figure 44 represents the TCP packet distribution during the attack. As can be seen, the device is being accessed. This is evidenced by the presence of TCP SYN, TCP ACK and TCP FIN packets whose presence proves a successful TCP session. There is an increase in TCP RST packets—up to about 10,000. This is due to the embedded web server attempting to terminate the problematic session by responding to each received ACK packet with an RST packet. But the attempts to terminate the session are unsuccessful.

Figure 45 represents how many packets were sent during the TCP RST DoS attack. A total of 51,160,280 packets were sent.

Figure 46 represents the result of the “ping” command during the attack. Out of 121 packets, all 121 packets were received. The losses were 0%. The device is accessible.

Figure 47 represents the TCP packet distribution during the attack. As can be seen, the device is accessed again. This is evidenced by the presence of TCP SYN, TCP ACK and TCP FIN packets. There is an increase in TCP RST packets, up to about 40,000, because of the attack. This number also includes the TCP RST packets that are generated by the embedded web server, through which it tries to terminate the session, but it cannot.

Figure 48 represents how many packets were sent during a TCP FIN DoS attack. A total of 52,203,542 packets were sent.

Figure 49 represents the result of the “ping” command during the attack. Out of 117 packets only 115 packets were received, and 2 packets were lost. The losses were 1%. The device is accessible.

Figure 50 represents the TCP packet distribution during the attack. As can be seen, the device is accessed again. This is evidenced by the presence of TCP SYN, TCP ACK and TCP FIN packets. There is an increase in TCP FIN packets, up to about 35,000, because of the attack. As during the TCP ACK attack, a large number of TCP RST packets are observed—10,000. The embedded web server attempts to respond to each attack packet with an RST packet to terminate the session, but it cannot.

Figure 51 represents the traffic the Neomontana PDU processed during the four attacks. As can be seen from the graph the traffic processed during the attacks was again huge, which is normal for this type of attack.

7. Analysis and Recommendations

The last stage of the developed methodology is the analysis of the obtained results and proposed recommendations for enhancing the network security level. Both PDUs have only one open port. This is great because the administrator of the network to which these devices would eventually connect, does not have to deal with additional activities involved in restricting access to the possible open ports. In the case of the two studied devices, no such activities would be required due to the presence of only one open port.

In terms of data exchange, both devices do not have any data encryption because they use http instead of https. As it can be seen from the presented results, for both devices the information is not transmitted securely—either in plain text, when exchanging statistical data such as values of the current, voltage, temperature, humidity, etc., or using simple encoding, which is very easy to decode. In both devices, the procedure for changing username and password is exchanged in plain text. Credential information can thus very easily be intercepted in the subsequent analysis of the intercepted packets. To remedy this deficiency both devices must be accessed using the VPN technology. Thus, the information exchange will be encrypted and cannot be read. The use of VPN for both devices is imperative because they are used in remote power supply management of various network devices and servers. If these PDUs are hacked, the performance of the ISP network may be questionable.

The results from the penetration tests show that the EATON PDU is inaccessible during all TCP DoS attacks. In contrast to the EATON PDU, the Neomonata PDU is only inaccessible during the TCP SYN attack, and accessible during the other attacks. This was further demonstrated during the analysis of both devices using the network vulnerability analysis scripts via the Nmap tool. The results for the EATON PDU showed that the device was vulnerable to DoS attacks, which was proven by the penetration tests performed. The Neomontana PDU analysis, with the same scripts, showed that the device may not be susceptible to DoS attacks. This was also proven by the penetration tests performed, at which time it was seen that only during the TCP SYN attack was the device inaccessible. During the other three TCP DoS attacks the device was accessible. This means that the embedded web server is somehow designed to be able to resist to some of the DoS attacks. For both devices, additional measures must be taken to be secured against DoS attacks, such as the following:

• Segmenting the network 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 linked to DoS attacks in the past or present;
• Limiting the speed of traffic, which can prevent a DoS attack from overloading the server;
• Using content delivery networks (CDNs)—this distributes the content of the website across multiple locations; thus, a DoS attack could not bring down the entire site.

Additional measures and techniques that can be applied to enhance network security are outlined in [40,41,42,43,44,45,46,47,48,49].

8. Discussion

8.1. About the Proposed Experimental Stand

From the obtained results, it was found out that both PDUs have almost the same vulnerabilities. Both devices have only one open port, port 80, which is used for access and control through a browser. Having only one open port is “good news” because no additional measures will be needed.

For both devices the exchange of information is not secure. Data are exchanged either in plain text or through the use of simple coding techniques that are very easy to decode. For devices that are used by ISPs or service providers, the non-secure data exchange is a big problem because possible hacking of these PDUs could result in a network down or inability to deliver services.

A difference between the two PDUs was found during the penetration tests when both devices were subjected to different DoS attacks. The EATON PDU was inaccessible during all attacks, which was an expected result. However, the Neomontana PDU was only inaccessible during the TCP SYN attack. During the other attacks, the device was accessed without problems. The penetration tests also confirmed the results of the vulnerability analysis carried out with Namp—the Neomontana PDU, according to Namp, may not be affected by some DoS attacks. That did occur. This means that the developed embedded web server is somehow designed to resist to some of DoS attacks.

8.2. Disadvantages and Limitations

The main drawback of the proposed stand is the mandatory use of a switch having the port mirror function. Such switches are significantly more expensive than regular switches, which would lead to additional financial costs. The proposed stand can be implemented with a regular switch, but the use of such a switch would lead to indeterminacy of the monitored traffic—the monitoring station would only monitor its own generated traffic. Thus, more in-depth studies would be impossible.

Another limitation is that the computational capabilities of the monitoring station must be high. With weaker computational capabilities, real-time monitoring becomes difficult and at times may not be in real-time. The real-time monitoring tools used at the time require a lot of computational resources.

Another drawback is that using Kali Linux as a virtual machine leads to erroneous results, including port scanning errors, inability to implement the attacks, etc. To avoid such problems, it is imperative that Kali Linux must be installed as a standalone operating system and not as a virtual machine. This means using a dedicated workstation.

As a possible limitation of the developed experimental setup is that the studied PEDs use old architectures of their embedded web servers—the use of port 80 (HTTP), i.e., when studying PEDs which are using more modern embedded web server architectures, such as TLS (Transport Layer Security), the exchange of information is encrypted because it uses HTTPS (Hypertext Transfer Protocol Secure), respectively, using port 443; therefore, some of the steps in the methodology will need to be revised.

Table 1. Summary of the possibilities.

Possibilities	Yes	No
Mandatory use of a switch with the mirror port function		It is possible to use an ordinary switch. However, it will not be possible to differentiate the traffic source.
Mandatory installing Kali Linux as a standalone operating system	Yes, it should, to avoid the possibility of errors.
Mandatory to use a workstation with high computing capabilities as a monitoring station		It is possible to use a weaker workstation. The results will be displayed with a delay.
Can any PEDs be studied	Yes. But it will be needed to revise some of the methodology steps to monitor new security vulnerabilities (future work)

provides a summary of the possibilities, based on the presented constraints, for the developed experimental setup.

8.3. Future Work

The main challenge for future developments will be to redesign/update some of the steps of the proposed methodology to match the capabilities of the HTTPS. In the use of HTTPS there is a new group of vulnerabilities that need to be addressed, such as mixed content (exchanging unencrypted HTTP content within the HTTPS sessions); certificate issues; vulnerabilities in web applications; outdated protocol versions and others, which are not common for the HTTP.

9. Conclusions

The proposed experimental setup, along with the developed methodology to study the network security level of PEDs, is simple and easy to implement. It uses only free tools. Nevertheless, the obtained results are reliable.

Any PDU can be studied as long as it has the capability to connect to IP networks.

The practical results demonstrate and prove the applicability of the developed setup along with the developed methodology. The obtained results can be used by the administrators of IP networks to which possible PEDs will be connected to assess what measures to take to enhance the network security level.