**Integrated Network Monitoring using Zabbix with Push Notification via Telegram**

\*\*Double blind review, please do not include authors information in this version \*\*

Received Date: \*date

Accepted Date: \*date

Published Date: \*date

**HIGHLIGHTS**

  - Continuous ICMP logged by tcpdump is identified as a possible ping flooding attempt.

  - Continuous SYN packets from the same IP with no SYN\_RCV reply is used as the parameter to trigger an alert to the administrator.

  - Alerts of problem and resolved problem are sent to the administrator for both ping and SYN flooding attempts.

  - Zabbix requires at least a 30 second interval for data retrieval from the monitored host.

ABSTRACT

*The world is increasingly dependent on online services. To offer a service, a network has to be in good health and free of any attacks. An attack is where either the confidentiality, integrity or the availability of a service is compromised. Network monitoring is a solution capable in maintaining these network devices from its usage up to detecting attacks. A denial of service (DOS) attack on a network can affect the network performance and can cause serious damage. Zabbix is an open-source network monitoring tool that is versatile and can be used to monitor hosts on a network. The purpose of this project is to detect possible ping and SYN flooding attempts on a server and to send alerts to the administrator via Telegram. This project uses Zabbix to monitor a server for potential ping and SYN flooding attacks. Tcpdump is used to log the pings received by the server. When the server continuously receives 10 or more pings per second, an alert will be automatically generated and sent to the administrator via Telegram. Similarly, an SYN flood attack is detected by using netstat’s SYN\_RECV flags. When the server continuously receives more than 10 SYN packets without ACK, Zabbix will generate alerts that are sent via Telegram and update the dashboard to show a problem. Zabbix was able to accurately detect all ping flooding attempts on the server. However, SYN flooding attacks were not as accurately detected. The use of Zabbix can be implemented in small businesses or networks for an automated monitoring system. Future works can include more DDOS attacks and adding countermeasure actions when detecting attacks by blocking the IP or port associated to the attack. SYN flooding detection requires refinement as only 2 out of 3 attacks were able to be detected.*

*Keywords: Network Monitoring, Zabbix, Ping Flood, SYN Flood, Telegram*

# INTRODUCTION 

The internet works by connecting millions of users around the world enabling them to communicate and essentially exchange data with each other making it the perfect example of a network. A threat is defined by the prospect of leveraging a security breach or vulnerability and thereby causing potential harm (Birkinshaw, Rouka & Vassilakis, 2019). Network security is a combination of multiple layers of defences at the edge and in the network. Automation in network security is the process of using software to automate network and security provisioning and management. Any attack that compromises the confidentiality, integrity and availability is considered as an intrusion. There are several ways to identify if your network is vulnerable to attacks. This includes using already existing tools like Tcpdump and Wireshark to monitor your network. However, running these tools separately is time consuming and analysing the results manually can be prone to human error as the administrator might miss an event. According to Nobles (2018), human-enabled error amounts to 95% of the increasing cyber-attacks, data breaches and ransomware attacks. A denial of service (DOS) attack on a network can affect the network performance and can cause serious damage. A DOS attack is difficult to avoid even as multiple techniques are adopted as the attack can be implemented in a number of different ways (Abid, 2020). A ping flooding attack is a volume-based attack on a network by sending a large amount of ICMP messages to the victim to consume the server’s resources and deny access to legitimate users. A SYN flooding attack aims to render a server unusable for legitimate traffic by using all the server's resources.

# METHODOLOGY 

The methodology used in this project consists of six phases, starting with the initial phase. The gathering and reviewing of information relevant to the project were reviewed. Reading material and research on topics related to network monitoring, automation and DoS attacks are used to gain more understanding on the project. Using the information obtained, the background of study was written. Information from the background study was then used to identify the project objective, problem statement, research scope and research significance are identified. The planning phase consists of using the information gathered during the initial phase to plan out the flow of the project. In this phase the hardware and software requirements are identified. This project uses the SDLC Waterfall Model methodology. SDLC is a framework building component that determines capability in single steps (Naga Malleswari, D., Kumar, M. P., Sathvika, D., & Kumar, B. A.,2018).

The third phase is the design and development phase. During this phase the network topology of this project is designed. Then, the scripts for collecting data and detecting ping and SYN flooding attacks are written. The dashboard configurations on Zabbix and setting up a Telegram bot was also done. In this phase, the network topology is also determined. Figure 1 illustrates the network topology of this project. To achieve the objectives, a ping flood attack and SYN flood attack will be conducted to the victim server. A ping flood attack to the victim server will be launched using the ping command to send 10 pings per second. A bash script implemented to execute tcpdump with cron logs the pings received on the victim server in tcpdump.log. If the server receives ten or more pings per second from the same source, it will be considered as a possible ping flood. Next, a second script will be implemented to monitor the SYN\_RECV socket status via netstat. To launch a SYN flood attack, hping3 will be used.

![](6231e01fa745b_media/media/image1.png)

**Figure** **1:** Network Topology

The next phase is the testing phase. In this phase, the **system’s capabilities to alert the administrator of a possible ping and SYN flooding attacks based on the triggers that were predefined during the design and development phase. There will be three tests and objectives to achieve in this phase. The objective for test 1 is the ability to detect a ping flooding attack. In the first test, the parameters used to identify a possible ping flood attack is 10 consecutive pings from the same IP address per second. A study on DoS detection solution for cloud platform using SNMP done by Gayathri & Neelanarayanan (2018) uses the assumption of 3 requests originating from the same source per second is assumed to be a DoS attack. In this test, a machine will send 10 pings per second using the ping command. The expected outcome of this test is to analyse the graphs produced by Zabbix and tcpdump logs the pings received in tcpdump.log. A ping flood would cause a sudden spike in the graph. The second test will be done by conducting a SYN flooding attack. In this test, the trigger for a SYN flood attack is set to IPs with 10 or more SYN packets sent with no ACK. A SYN flood attack can be simulated using hping3. Next, the systems alert capabilities during a ping flood attack and SYN flood attack are tested. To test the alert capability, a ping flood attack and SYN flood attack will be conducted.**

**The fifth phase is the analysis phase. The time the attack is started and stopped are recorded and the time the administrator receives an alert is also recorded. The analysis done is on the accuracy of detection of the ping and SYN flooding attacks and the capability to alert the administrator of the attack. The final phase is documentation. All the steps taken to complete this project is recorded and documented.**

**Setting up**

In DigitalOcean, two new droplets were created to host the servers on the cloud. The V.Server is the victim server with the IP 178.128.119.51 and ZABBIX-Server is the Zabbix server with the IP 209.97.164.25. To install Zabbix, access to the server via putty is required. Zabbix’s latest repository was installed from the Zabbix Official Repository. Then, the Zabbix server and web frontend with MySQL database using the *sudo apt install zabbix-server-mysql zabbix-frontend-php* command. The next step is to install the Zabbix agent on the victim server which will collect data and send the data to the Zabbix server with *sudo apt install zabbix-agent*. To configure the Zabbix frontend, go to http://209.97.164.254/zabbix/ and check the pre-requisites necessary. Login to Zabbix with the default user credentials and make the necessary password change. Next, active checks enable Zabbix to collect data for it to monitor the victim server. The trappers are set to enable the processing of active checks on Zabbix with the command by starting the trappers in /etc/zabbix/zabbix\_server.conf. To receive notifications from Zabbix, a Telegram bot is needed. The bot will send the alerts to the administrator. In Zabbix frontend, a media type is added. In Users, update the send to field and place the bot ID to start receiving notifications.

**Launching Ping Flooding Attack**

One of the attacks launched on the victim server to test the objective of the project is achieved. To launch a ping flooding attack, open the terminal and use the ping command with the -n and -i options. The -n option will show the IP instead of hostname and the -i option specifies the interval between successful packet transmissions. To simulate a ping flood attack that would be able to be detected, 10 or more ping request needs to be sent per second. The -i option will allow this by setting it to 0.1. Using the command *ping -n -i 0.1 \<IP\>*, 10 pings will be sent per second to the target. This command however, needs to be done as a root user by implementing the *sudo su* command. This would fulfil the trigger requirements for Zabbix to show the pings as a possible ping flooding attack.

**Launching SYN Flooding Attack**

An SYN flooding attack can be simulated using the hping3 tool available on Linux distributions. To install hping3 on Ubuntu run the commands sudo apt update and sudo apt install hping3. To start the attack, use the command *hping3 \<IP\> --flood --rand-source --destport \<port number\> --syn -d 120 -w 64*. Based on the triggers set, any IP that sends 10 or more packets with SYN flag on and have received the SYN+ACK packet from the target without sending an ACK back is considered to be an attempt at SYN flooding. To check if an attempted connection was a potential SYN flood attack, netstat was used to check the socket status for the SYN\_RECV status. This indicates that the server has received the initial SYN packet, it has sent its own SYN+ACK packet and is waiting on the ACK from the attacker machine to complete the three-way handshake. When a server receives a large number of connections, it waits for a response from the client, leaving the connections open and draining the server's resources, resulting in a denial of service (Salunkhe, Jadhav & Bhosale, 2017).

Figure 2 shows the testing framework used in this project. Three tests with different objectives were conducted.

![](6231e01fa745b_media/media/image2.png)

**Figure** **2:** Testing Framework

The first test involves conducting a ping flooding attack to observe a spike in the graph and the problem generated on Zabbix dashboard. The second test was done by conducting a SYN flooding attack and the expected outcome is that the problem appears on Zabbix. The third test is to evaluate the system’s alerts capabilities during ping and SYN flooding. This test is done by launching the attacks and the time the attack is started and the time the administrator receives an alert is recorded.

**FINDINGS AND DISCUSSIONS**

**Ping Flooding Attack Results**

**Based on the Table 1, three ping flooding attempts were launched to the victim server (178.128.119.51). Zabbix was able to detect these attacks using the trigger that 10 or more pings from the same source per second set. The administrator receives an alert of the attack immediately after the attack appears on Zabbix’s dashboard. The alert sent to the administrator includes the problem, the time the problem started, the problem name, which host the problem is on, the severity, the operational data, and the original problem ID. Once the attack was stooped, Zabbix also sends the administrator an alert that the problem has been resolved.**

**Table** **1:** Ping Flood Testing Results

<table>
<thead>
<tr class="header">
<th>No</th>
<th>Start Time of Attack (24hrs)</th>
<th>Alert Trigger</th>
<th>Problem listed on Zabbix Dashboard</th>
<th>Administrator’s Alert (24hrs)</th>
<th>Time Attack is Stopped (24hrs)</th>
<th><p>Time Problem is Recovered</p>
<p>(24hrs)</p></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>1</td>
<td>19:20</td>
<td>PROBLEM</td>
<td>Possible pin flood from 218.111.111.246 !</td>
<td>19:20</td>
<td>19:23</td>
<td>19:24</td>
</tr>
<tr class="even">
<td>2</td>
<td>19:27</td>
<td>PROBLEM</td>
<td>Possible pin flood from 218.111.111.246 !</td>
<td>19:27</td>
<td>19:30</td>
<td>19:31</td>
</tr>
<tr class="odd">
<td>3</td>
<td>19:35</td>
<td>PROBLEM</td>
<td>Possible pin flood from 218.111.111.246 !</td>
<td>19:35</td>
<td>19:40</td>
<td>19:41</td>
</tr>
</tbody>
</table>

During an attack, the graph shows the pings received are clustered together and is highlighted with a red hue. Zabbix uses the ICMP ping logged in tcpdump.log to map out the graph where each dot represents a ping received. **Zabbix dashboard illustrates the ping flood attacks launched in the ICMP ping requests from different sources (per 1 sec) graph where pings received were clustered together. Based on Figure 3, when the victim server was attacked, the graph showed an increase or spike in the dots representing the pings it was receiving.**

![](6231e01fa745b_media/media/image3.png)

**Figure** **3:** ICMP Ping Graph

**SYN Flooding Attack Results**

**Table** **2:** SYN Flooding Test Results

<table>
<thead>
<tr class="header">
<th>No</th>
<th>Start Time of Attack (24hrs)</th>
<th>Alert Trigger</th>
<th>Problem listed on Zabbix Dashboard</th>
<th>Administrator’s Alert (24hrs)</th>
<th>Time Attack is Stopped (24hrs)</th>
<th><p>Time Problem is Recovered</p>
<p>(24hrs)</p></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>1</td>
<td>19:50</td>
<td>PROBLEM</td>
<td>10 packets without ACK from 218.111.111.246 !</td>
<td>19:51</td>
<td>19:54</td>
<td>19:52</td>
</tr>
<tr class="even">
<td>2</td>
<td>20:10</td>
<td>PROBLEM</td>
<td>&gt; 10 packets without ACK from 218.111.111.246 !</td>
<td>20:10</td>
<td>20:15</td>
<td>20:13</td>
</tr>
<tr class="odd">
<td>3</td>
<td>20:25</td>
<td>TRIGGER IS SILENT</td>
<td>Problem not listed</td>
<td>Alert not sent</td>
<td>21:35</td>
<td>-</td>
</tr>
</tbody>
</table>

Table 2 shows the results obtained during the SYN flooding attack testing. Three SYN flooding attacks were launched using the *hping3 178.128.119.51 --c 5 --destport 22 --syn -d 120 -w 64* command. Zabbix was successful in detecting two of the attack and alerts were sent to the administrator. Without stopping the attack, the victim server was able to recover and Zabbix’s dashboard was updated to show “RECOVERED” as the status.

During the SYN flood attack tests, Zabbix was able to detect an attack within 60 seconds it was launched, and the alert was sent to the administrator immediately after it was detected. Zabbix was able to recover from these attacks between 2-5 minutes it was launched even before the attack was stopped. However, after the second attempt at testing Zabbix’s capabilities to alert the administrator of the attack, Zabbix was not able to detect the attacks and thus the administrator remained unaware of the attack. This provides an opportunity for attackers to launch multiple SYN flooding attacks consecutively to consume the resources of the victim server.

Based on the results obtained during the testing, Zabbix was able to detect a possible ping flood and send an alert to the administrator within 60 seconds when the flooding was detected. For Zabbix to detect a possible ping flood, it has a minimum of 30 second refresh time to fetch the data from the host monitored. Once the data from tcpdump.log is obtained, if the trigger requirement of more than 10 pings per second from the same source is met, Zabbix produces an alert for the dashboard and administrator. The recovery time has a recovery error of 60 seconds based on the time the attack was stopped and the time recovery alert was sent to the administrator and for Zabbix to update its dashboard to show that the victim server has recovered from the attack.

**CONCLUSION AND RECOMMENDATIONS**

This project was able to detect ping and SYN flooding attempts and send alerts to the administrator. 10 or more pings from the same source per second was considered as a ping flooding attempt. Zabbix was able to detect the pings and log it as a possible ping flood attack. When the ping flood was detected, Zabbix dashboard showed a spike in the ping flood graph and a problem also appears on the dashboard. For detecting an SYN flood, the trigger used was 10 or more SYN packets with no ACK was logged as an SYN flooding attack. When the attack was launched, Zabbix dashboard showed the SYN flood as a problem. When both the flooding attacks were detected by Zabbix, a Telegram message with the details of the attack was sent to the administrator. Therefore, the objectives of the project were achieved. During the testing phase, several weaknesses in Zabbix’s monitoring was found. The most notable finding is that Zabbix was not able to detect SYN flooding attacks as accurately as ping flooding attack. Zabbix was also able to resolve an SYN flood attack within minutes it was launched without having the attack stopped. From this observation, it was concluded that Zabbix has a cut-off threshold of the amount of SYN packets it receives. Zabbix also needs a period of at least 30 seconds to collect the data from the agent.

Future work can be done to include more type of attacks, particularly DDOS attacks. This project only used ping flooding and SYN flooding attack. Several attacks to be considered in future works can include but not limited to ping of death attack, SSH brute force attack, UDP flooding, and smurf attack. Adding attacks for a more extensive monitoring on a server is a good investment as cybercriminals are always ready to exploit any weakness they find for their gain. SYN flooding detection needs further refinement as Zabbix was not able to accurately detect all the SYN flood conducted to it after more than 2 attacks. Next, it is also recommended that countermeasures be put in place after detecting the attacks. The countermeasures can include blocking the IP launching the attack or closing certain ports.

There are also several limitations to this project. The triggers used to identify a ping or SYN flooding attack may not reflect real world situations as the volume of these attacks can be significantly larger. SYN flooding detection could only detect a maximum of two SYN flooding attempts during the testing done.

**REFERENCES**

Abid, K. (2020). Ping Flood Attack Detection via Wireshark. *International Journal of Advanced Science and Technology*, *29*(5), 9595–9601.

Birkinshaw, C., Rouka, E., & Vassilakis, V. G. (2019). Implementing an intrusion detection and prevention system using software-defined networking: Defending against port-scanning and denial-of-service attacks. *Journal of Network and Computer Applications*, *136*(February), 71–85. https://doi.org/10.1016/j.jnca.2019.03.005

Gayathri, R., & Neelanarayanan, V. (2018). DoS detection solution for cloud platform using SNMP. *International Journal of Pure and Applied Mathematics*, *118*(23), 175–183.

Naga Malleswari, D., Kumar, M. P., Sathvika, D., & Kumar, B. A. (2018). A study on SDLC for water fall and agile. *International Journal of Engineering and Technology(UAE)*, *7*(2), 10–13. https://doi.org/10.14419/ijet.v7i2.32.13516

Nobles, C. (2018). Botching Human Factors in Cybersecurity in Business Organizations. *HOLISTICA – Journal of Business and Public Administration*, *9*(3), 71–88. https://doi.org/10.2478/hjbpa-2018-0024

Salunkhe, H. S., Jadhav, S., & Bhosale, V. (2017). Analysis and Review of TCP SYN Flood Attack on Network with Its Detection and Performance Metrics. *International Journal of Engineering Research And*, *V6*(01), 250–256. https://doi.org/10.17577/ijertv6is010218