A New Mitigation Method against DRDoS Attacks Using a Snort UDP Module in Low-Specification Fog Computing Environments

Abstract

Current cloud computing expects to face huge traffic costs, data loads, and high latency due to the explosion of data from devices as the IoT and 5G technology evolve. Fog computing has emerged to overcome these issues. It deploys small fog servers at the edge of the network to process critical data in real time while sending the remaining secondary tasks to the central cloud, instead of sending massive amounts of data to the cloud. With the rise in fog computing, among traditional security threats, distributed denial-of-service (DDoS) attacks have become the major threat to availability. This is especially true for fog computing, where real-time processing is critical; there are many fog servers, and the processing power is relatively low. Distributed reflection denial-of-service (DRDoS), one of the frequently used DDoS attack techniques, is an amplification attack that can be used on a small or large scale. It is widely used in attack tools due to its easy configuration. This study analyzes the characteristics of fog computing, the characteristics of DRDoS attacks, and the advantages and disadvantages of existing countermeasures. Based on these analyses, this study proposes a model that could effectively mitigate attacks even on low-specification fog servers by combining a modified Snort module with reduced functionality, simple pattern matching, and filtering distribution using Anycast. This mitigation algorithm has a simple structure rather than a complex filtering structure. To achieve this goal, this study virtually implemented the corresponding fog IoT environment. In spite of its simple structure, it proved that the fog server could secure availability even under DRDoS attacks by implementing and validating the mitigation model.

1. Introduction

The development of the Internet of Things (IoT) and big data has caused problems in the centralized cloud computing environment, such as massive traffic, high latency, and data overloading. As a result, fog computing (or edge computing) has emerged to overcome these problems. Unlike cloud computing, which communicates directly with a central cloud or data center, fog computing places multiple fog servers at the edge of the network to handle data computation, storage, and applications, and sends only core data to the cloud server for processing [1]. In the current transitional period from cloud computing to fog computing, many companies, including ARM, Cisco, Dell, Intel, and Microsoft, are actively working on building infrastructure and standardizing technologies for fog computing and on security and privacy issues in fog environments [2].

However, the development of IoT has also increased the number of vulnerable devices dramatically, and these are exposed to various security threats and exploited in attacks [3]. Recently, the number and scale of DRDoS attacks, a type of DDoS, have skyrocketed due to vulnerable IoT devices and servers [4]. DRDoS attacks, by their very nature, exploit specific protocols that have been found to be vulnerable. They fake spoof attack IPs as legitimate IPs, making it difficult to detect these attacks, and it is easy to set up attacks, which are why many attack tools use DRDoS attacks. DRDoS attacks pose a major threat to the service availability of fog computing, which is characterized by real-time processing and low latency because they deplete the resources of fog servers or paralyze the network bandwidth.

Therefore, this study aimed to propose a mitigation method to ensure that fog computing environments would be of minimal availability against DRDoS UDP attacks. This study focused on countering DRDoS attacks in a fog computing environment. This study implemented a model that would monitor traffic on low-specification fog servers and distribute suspected attack packets to the fog servers sequentially, inspect them, separate legitimate and attack packets, and block attack packets. For this purpose, the Snort module was applied to the fog computer and modified to use only some of its functions.

This study analyzed the fog computing environment and evaluated various types of DRDoS attacks and existing countermeasures. Afterward, this study implemented and validated a mitigation model that could respond to UDP amplification attacks in a low-specification fog environment.

Section 2 reviews related studies, such as the characteristics of fog computing environments and security threats, and examines various attacking techniques of DRDoS attacks, existing countermeasures, and the countermeasures of cloud and fog environments. Section 3 describes the proposal for a mitigation model for the fog environment. Section 4 describes the performance verification of the proposed model through an experiment. In addition, we experimented to determine whether it is suitable for a fog computing environment compared with other methods. Section 5 presents conclusions and further topics to be evaluated.

2. Related Work

2.1. Fog Computing

Although advancements in the IoT are helping to improve the quality of life, the amount of data generated by so many digital devices is unprecedented, greatly burdening traditional cloud environments. Researchers estimate that, given technological advances such as smart factories, autonomous driving, and smart cities, IoT devices will generate USD 11 trillion in revenue and cost savings annually by 2025 and predict that the total amount of data in the world will reach 163ZB, a 10-fold increase from today’s quantity [4]. Cloud computing handles traditional big data by providing scalable storage, processing services, and load-balancing services based on usage. However, it is inefficient to process the steeply increasing number of devices and data in the central cloud at current network speeds due to various problems, such as high traffic costs, bandwidth issues, and latency.

Fog computing was first proposed by Cisco in 2014 to overcome these shortcomings [5]. It is a paradigm to reduce the data load by distributing the functions provided by the existing cloud to the edge of the network [5]. It is also called edge computing because it is processed at the edge of the network; cloudlet, a terminology referring to the platform itself, is also used interchangeably. Fog computing refers to all methods from data creation to storage and includes edge computing, which simply means that the data is processed closer to where it is created [6].

The fog server is physically closer to the device than the cloud server. A fog server can process primary data generated by the device at a faster rate and respond in real time, and it sends key secondary data that has already been processed once to the cloud for processing. Thus, it can drastically reduce the data load on the cloud [3]. Figure 1 is a comparison of cloud computing and fog computing.

Fog computing is gaining attention as a key component for autonomous IoT and smart factories. For example, researchers are studying the application of fog computing to gather real-time data from IoT sensors attached to vehicles, including autonomous vehicles, to understand driving situations and to promptly respond to unexpected circumstances. South Korean companies such as Samsung SDS and SK Hynix are already introducing fog computing to process huge data generated in smart factories. Microsoft, which provides many cloud computing solutions, released Azure IoT Edge, which is still available, in 2017. Amazon AWS and other companies have also begun to provide fog computing solutions.

Currently, several industry consortia, including Open Edge Computing (OEC) [7], Open Fog Computing (OFC) [8], and Multi-Access or Mobile Edge Computing (MEC) [9], are working on interaction improvement, standardization, and platform and software development in the fog and edge computing sectors [3]. The OEC consortium aims to promote the development of an edge computing ecosystem by providing a standard mechanism for development as well as a platform, while the goal of OFC is to define data processing in fog computing and to enable the easy execution of and interaction with autonomous IoT.

2.2. Security of Fog Computing

There are no standardized security guidelines or security threats for fog computing. However, for this study, we reviewed many previous studies on the security issues and major security threats of fog computing.

Deepak et al. [3] classified the fog computing structure into the fog layer, middleware (communication) layer, and sensor layer and presented possible security threats and countermeasures. Khan et al. [10] showed the main security issues of fog computing by referring to cloud computing security threats because fog computing, which distributes the functions of cloud computing, could share similar security issues with cloud computing.

Table 1. Top 11 security threats.

No	Security Threats (2019)
1	Data breaches
2	Misconfiguration and inadequate change control
3	Lack of cloud security architecture and strategy
4	Insufficient identity, credential, access, and key management
5	Account hijacking
6	Insider threat
7	Insecure interfaces and APIs
8	Weak control plane
9	Meta-structure and application-structure failures
10	Limited cloud usage visibility
11	Abuse and nefarious use of cloud services

presents the top 11 security threats announced in 2020 by the Cloud Security Alliance (CSA), which provides cloud security guidelines [11].

Virtualization of fog servers, malicious insiders, access controls, and vulnerabilities are identical to the security threats of the conventional cloud. Fog platforms are not well standardized and are in a transitional state, so caution is advised. Network security is especially important in fog computing. Since fog servers communicate with many devices and are connected to the cloud servers in fog computing, they are more likely to suffer more damage under an attack. Fog computing services may be exposed to malicious and illegal intrusions due to the large number of exposed fog servers, open networks, and vulnerabilities in the web, protocols, and information systems because of fog computing’s nature. Network security is especially important because the services are provided and used through the network.

2.3. DRDoS Attacks

A distributed denial of service (DDoS) attack uses multiple malware-infected attack PCs to simultaneously attack a specific server or network to deplete its resources and paralyze its services. A famous case is that of 7 July 2009, when DDoS attacks brought down Korean government agencies, portal websites, and bank websites for up to 24 h due to the distributed denial of service attacks [12].

Among the various DDoS attack methods, distributed reflection denial of service (DRDoS) attacks aim to make it harder to defend attacks based on IPs and to trace them back. They spoof the origin IP and send a request packet to a reflector, such as a server to be used in the attack, to send a response packet to the spoofed origin IP (the attack target).

DRDoS attacks utilize an amplification attack method that amplifies the response packet by exploiting a vulnerability in the UDP protocol, which does not examine the request packet well. The specific protocols used in the attack are characterized by sending large response packets for a small amount of request traffic. It does not require a malware-infected botnet because of the nature of the attack, which makes it convenient. Moreover, it is used by a variety of attack tools because the attack scale is much larger.

An amplified DRDoS mainly attacks the UDP protocol because it is difficult to apply an amplified attack, which spoofs the origin IP and exploits vulnerabilities, to a TCP, which uses a three-way handshake. Amplification attacks are carried out by using vulnerable legitimate servers as reflectors. To the victim, the traffic appears to be coming from a legitimate server. Therefore, if the victim simply blocks it based on the origin IP, even normal services become impossible. Since the scale of the attack can reach hundreds of Gbps depending on the number of protocols and reflectors, it is very difficult to defend against it, and even security equipment is often paralyzed before filtering.

The amplified attack on Github in 2018 exploited a vulnerability in the Memcached protocol and reached 1.3 Tbps, the highest recorded. Memcached is a daemon that uses memory to provide caching services and is often established by companies to efficiently use bandwidth [13]. However, since there were over 100,000 Memcached servers left unprotected on the network, they were used to launch the attack [13]. Aside from the difficulty of the conditions, DRDoS attacks often do not require a botnet, and they are easy to set up. Therefore, many attack tools allow small- to large-scale attacks. Shodan [14], a security vulnerability scanning engine, identified more than 50,000 unprotected and vulnerable Memcached servers.

A DRDoS attacker first secures a list of servers or botnets that can be amplified. When a request packet is sent to the acquired list after spoofing the origin address to the target’s address, the servers (or botnets) send amplified response packets to the target to perform a denial-of-service attack. The Network Time Protocol (NTP), Connection-less Lightweight Directory Access Protocol (CLDAP) amplification, Domain Name System (DNS), and Simple Service Discovery Protocol (SSDP) are used as popular attack methods [15].

Memcached is a daemon that provides caching services by using memory and is often established for companies to use bandwidth efficiently. A Memcached reflection attack exploits a design flaw that does not authenticate queries in the large Memcached server (a distributed cache system) on a public network. An attacker sends a request UDP packet disguised as a victim’s IP address to the default port 11211 of a Memcached server, and the Memcached server reflects the response packet that is at least 10,000 times the packet to complete an attack. Cloudflare reported that a request packet of just 15 bytes returned a response packet of 750 KB (51,200-fold amplification). Countermeasures include blocking port 11211 completely or making the Memcached use the TCP protocol instead of the UDP protocol. If the Memcached must be used, it should be configured to only allow IPs that are authenticated through security devices with the server [12,16].

2.4. DRDoS Defense Methods

Anti-spoofing is the first defense method. Blocking IP spoofing can essentially make DRDoS attacks impossible. These techniques can be classified into authentication techniques and methods that use the network topology.

Anti-spoofing based on authentication includes authentication methods using tunneling techniques [17] and third-party authentication. Although both tunneling techniques and third-party authentication methods ensure anti-spoofing, they all incur additional performance overheads due to encryption. In particular, third-party authentication causes the most overheads and additional traffic.

Anti-spoofing using network topology includes ingress/egress filtering [18] and techniques utilizing the Border Gateway Protocol (BGP) and routing tables [19].

The second method is protocol patching. Most of the vulnerable protocols that are exploited for amplification attacks do not have authentication procedures in place for a particular service. That is why they are exploited by these attacks. Therefore, this method patches this vulnerability. A representative patch is to remove the monlist function that is exploited in NTP amplification attacks. However, this method is difficult to apply because it can only be applied to internal servers with patch privileges, and many other vulnerable servers are left with outdated versions and not managed.

The third defense method is to block or evade traffic. Firewalls are the most basic way to block attack packets. They can simply close all unused ports or block specific IPs. However, since firewalls do not analyze packets, it is common to install an intrusion detection system (IDS) and an intrusion prevention system (IPS) behind firewalls that use software to analyze packets to categorize them as attack packets or legitimate packets and to block attack packets. They can be implemented by physical devices or by using software, and many software packages offer different ways to analyze packets and block attacks.

• Misuse Detection
• Anomaly Detection

Misuse detection, also known as signature-based detection, is the most commonly used method for detecting attacks based on previously used patterns that exploit known vulnerabilities.

Although it shows a high detection rate within the scope of the patterns, it has the disadvantage that it is difficult to detect attacks other than those with defined attack patterns, it is hard to analyze many packets, and it needs to continuously update patterns to detect new attacks. Signature-based pattern matching techniques detect packets that have a pattern recorded in a ruleset, which contain a lot of known attack ports, IP addresses, data sizes, data content, and UDP lengths.

Anomaly detection is a method for detecting abnormal behaviors that deviate from normal system usage. It detects behaviors that exceed the criteria by using statistical criteria such as the number of logins by normal users, time of day, CPU usage, and disk I/O. This method has the advantage of detecting new types of attacks. However, it also has some disadvantages, such as difficulty in setting statistical criteria and a high error detection rate.

To overcome these disadvantages, Yuan et al. [20] proposed a method that uses a deep learning algorithm to flexibly set statistical criteria and reflect them in filtering, but it requires large resources, which is a disadvantage. And ref. [21] proposed a DRDoS security method using a multi-agent learning mechanism.

In addition, ref. [22] is based on symmetric routing that forces response packets to take the same path as that of request packets. Ref. [23] discusses three different mitigation techniques—Access Control List (ACL), Reflexive Access Control List (RACL), and firewalls—and evaluates their effectiveness in thwarting SSDP DRDoS attacks. And ref. [24] presents a state-of-the-art review of DRDoS attack detection and mitigation algorithms as well as the datasets on which these algorithms operate. Ref. [25] provided a new DDoS detection framework based on the Matching Pursuit algorithm for detecting resource-hogging DDoS attacks. There need to be detection systems available for asymmetric DDoS attacks that are simple to install, efficient, and adaptable. Ref. [26] attempted to discriminate between good and bad users by modeling their behavior on a simple annotated probabilistic Timed Automata (PTA) and using a suspicion scoring system. This allows for a rapid detection method with a relatively low false-positive rate. Ref. [27] suggested a dynamic DDoS assault detection system that utilizes classification algorithms, a distributed system, and a fuzzy logic system. The solution used fuzzy logic to dynamically select from a library of categorization algorithms capable of spotting different types of DDoS attacks. Ref. [28] detailed a strategy for detecting and repelling DDoS attacks in a Software Defined Network (SDN) setting. At first, the author employed a DDoS assault detection trigger mechanism on the data layer to scrutinize any unusual traffic. Next, the author made use of the rate and asymmetry aspects of suspicious flows to identify them using a K-Means and K-Nearest Neighbor (KNN)-based mixed machine learning approach. Ref. [28] described a two-pronged approach that allows the hypervisor to establish trustworthy connections with guest virtual machines by taking into account both objective and subjective trust sources and utilizing Bayesian inference to aggregate them.

We will also look at defense methods against DDoS or DRDoS attacks using the Session Initiation Protocol (SIP). First, in [29], a model was constructed to automatically learn SIP message features using deep packet inspection (DPI)-based methods and to detect DDoS attack patterns efficiently. In [30], the authors focused on detecting DDoS attacks in SIP-based VoIP networks using deep packet inspection (DPI)-based methods. The proposed approach was based on analyzing packets to extract attack signatures and to implement new detection rules. In [31], deep forest models and service differentiation were used to filter out general DRDoS attack flows. Ref. [32] proposed a defense mechanism that consists of statistics, inspection, and action modules to mitigate the SIP-DRDoS attack. We implement the SIP-DRDoS attack by utilizing our SIP-based audit and attack software in our VoIP/SIP security lab environment that simulates an enterprise-grade SIP network.

2.5. DRDoS Defense System by Cloud and Fog Computing

The attack traffic blocking methods introduced above can effectively mitigate most small-scale attacks on a single IPS/IDS. However, there is a limitation that even filtering is paralyzed by attacks over bandwidth due to large-scale bottlenecks. Cloudflare’s DDoS mitigation solution, which is a representative solution among many DDoS mitigation solutions, can mitigate attacks up to 51 Tbps by relaying traffic to its globally distributed data centers, distributing filtered traffic across more than 15,000 servers and passing only legitimate traffic [33].

Fujinoki [34] proposed a cloud-based method to defend against DRDoS attacks. This method employs multiple mirror servers and management servers inside the cloud to monitor traffic. When the traffic exceeds a threshold, the management server distributes the traffic to the internal mirror servers and repeats the process. When the traffic is finally separated into traffic below the threshold, the management server separates normal traffic from attack traffic.

However, unlike a centralized cloud environment, fog computing consists of relatively low-specification servers and necessarily includes many that are under the IoT. Moreover, since fog computing is physically spread out at the edge of the network, providing DRDoS mitigation solutions to each fog computing environment can cause a high economic burden.

The DDoS security control services provided by companies use different methods and pricing schemes, but they basically provide IPSs, customized security policy settings, 24/7 security control, regular security reports, analysis and countermeasures in the event of an incident, and backup. The price is based on one server, and the cloud-based Azure charges are based on usage. Compared with the existing centralized server structure, fog computing is very costly when applying existing security solutions. In addition, if existing popular signature-based intrusion detection/blocking systems are implemented on low-specification fog servers, resource usage would be relatively high.

As Mukherjee [35] pointed out, it would be necessary to prepare countermeasures tailored to the fog environment, and since fog computing is in a transitional state, there are not enough studies on it. To overcome these shortfalls, this study proposes a mitigation model that compensates for the lack of large-scale packet processing and the high false-positive rate of simple filtering, shortcomings of traditional IPSs, based on the results of previous studies. This study also compares the overall performance of the mitigation model with that of traditional intrusion detection/blocking systems on fog servers.

3. Design of the Mitigation Model

In a fog computing environment, there are insufficient resources to install high-performance security systems or defense systems. It is difficult to use a resource-intensive security system in the fog computing environment. So, the most important goal in this system is to use few resources. Based on the previous analysis, the requirements for a mitigation model in a low-specification fog server can be summarized as follows:

• Low resource consumption for filtering.
• Enabled to handle as many DRDoS packets as possible.
• Able to maintain availability for minimal fog service.

This study aimed to implement a model that would mitigate DRDoS attacks, which are commonly used by attack tools, by combining simple packet filtering based on the Snort intrusion detection module [36] while focusing on speed to satisfy these requirements. In addition, fog servers with the same address are arranged according to scale in an Anycast manner to distribute the filtering load. Anycast is a method of addressing in computer networks in which a whole group of computers is assigned a common address. Since the signature-based algorithm of conventional packet filtering matches packets against 40,000 patterns, low-specification fog servers spend more resources on intrusion detection than on service. A combination of anomaly detection techniques and artificial intelligence is also not suitable due to its high resource consumption. Therefore, this study used a simplified signature-based detection method. Finally, it aimed to handle attacks of the size of the fog server’s bandwidth by combining Snort modules, Anycast, and simple packet filtering.

Based on this, this study implemented the mitigation model. Figure 2 shows the algorithms of the proposed mitigation model. It shows the algorithms for determining the blacklist, which compares the UDP length, source port, and payload by using a database that stores attack patterns. This mitigation algorithm has a simple structure rather than a complex filtering structure. It is designed to fit the above three requirements for fog computer environments.

Table 2. Filtering algorithm options.

Name	Option	Example	Description
Packet.Port	Source port number	CLDAP: 389, 636	The port of services primarily used for attacks
Packet.Payload	Data content	::getextendedtats	Data content and hexadecimals that appear primarily in attack patterns
Packet.Udplen	UDP length	1000 bytes or more	The maximum length is determined by a router

shows the inspection options for the filtering algorithm by referring to the vulnerable code published by CVE, involving only the source port, data payload, and UDP length, which are the most essential elements for determining an attack. It uses the Trie Structure commonly used in pattern matching. It compares the source port, data payload, and UDP length of the packet to the information stored in the Attack Pattern Database. If they match, the packet is blacklisted, and if only the last UDP length does not match, the ID of the packet is stored separately for further analysis. This is because there is a possibility of an APT attack, which fragments a packet to avoid pattern matching and intrusion detection. Attack patterns are based on the Common Vulnerabilities and Exposures (CVE: information and security vulnerability standard code) list and Snort’s community rules [37,38].

Therefore, our proposed method is to prevent DRDoS attacks by using Snort on the fog server. However, since there are many low-specification fog servers, some fog servers may not work normally due to Snort’s high CPU time. Therefore, with the exception of UDP, we removed most of the rules that were not being used, such as the POP3, IMAP, SMTP, and DNS server rules. This change may be vulnerable to attacks, except for UDP services. But this system uses a low-specification fog server and does not use any services other than UDP services. This proposed system will increase the availability of low-specification fog computing systems.

4. Simulation

4.1. Simulation Environment

Vmware, a virtual environment, was used for the experiment, and the environment was configured as shown in Figure 3. It was configured to allow one virtual machine to act as a router to distribute incoming traffic to internal fog servers according to the Round Robin method. The Snort intrusion detection module, log server, and simple packet filtering were installed on the fog server, and a program to exchange random virtual weather data between IoT sensors and fog servers was also implemented. The host attacked the fog server by using the Kali Linux attack tool and the Memcached attack tool.

Table 3. Environment for testing.

Environment	Fog Server	Fog Sensor	Host
Operating system (OS)	Ubuntu 16.04.2 LTS, Kali Linux 2024.1 Windows 10 x64	Windows 10 x64	Window 10 x64 and Kali Linux 2024.1
Processor core	1	1	4
Hard disk	40 GB	20 GB	2 TB
Memory (RAM)	4 GB	2 GB	8 GB
Tool	Snort 2.9.20, BASE Nov.24 MySQL 5.7		Visual Studio 2022, MySQL 5.7

shows the virtual machines used in the experiment and the development environment on the host. The old version of Linux, Ubuntu 16.04.2, the latest version of Kali Linux 2024.1, and Windows 10 x64 were used in the environment as the fog server. The use of Ubuntu 16.04.2, an older version of Linux, was tested by examining the difficulty of updating the already installed OS due to the properties of fog computing. But there was no effect of OS version on our experimental results. So, for the experiment, we used a mixture of the data tested with the old version of Linux and the data tested with the relatively latest version of Linux and Windows 10.

The sensors were programmed to send 10 fictitious weather data packets per second, at 40 bytes per second. Based on this, this study implemented a model that stored only UDP packets that came in at more than 100 times a second in the log, which was five times that of the weather data, and blocked the IP if it was an attack packet after checking the patterns of the log packets and distinguishing attack packets from normal packets.

We conducted two major experiments. First, we measured how many normal packets arrived if an attack occurred and if our proposed defense system worked. The second is an experiment on how well our proposed method fits the fog computer environment. It measured resource usage using the existing Snort, Suricata, and the proposed mitigation method that used modified Snort. Suricata is an IPS developed by the Open Information Security Foundation (OISF) that is based on Snort. It additionally has protocol identification, HTTP normalizer and parser, and file identification functions. It has improved quantitative and qualitative processing performance because it supports multi-threading.

Figure 4 shows the screenshots during the simulation. Figure 4a is a screenshot of the initial Snort startup. Figure 4b shows a screenshot of the local.rules file of Snort. Figure 4c,d are screenshots measuring the CPU time. Figure 4c shows a screenshot of the CPU time measured using the top command every second. Figure 4d is an example of measuring the percentage value CPU time for all processes in user mode using the API of the Windows OS.

4.2. Mitigation Process Test

After installing Snort on the fog server, the local.rule file was edited to save those UDP packets that attempted more than 100 connections per second in the log by referring to the network’s 100 Mbps bandwidth and mean traffic. Moreover, it was set to block the private IP 10.0.0.0 band and 172.16.0.0 band, frequently used as attack IPs. The private IP 192.168.2.0 band was not blocked for communication with the host. Rules were also set up to check whether a packet was blacklisted (IP blocklist) or whitelisted (IP allowlist), and it was configured to use only user-defined local.rules in the Snort.conf configuration file to avoid using the pre-defined large rule set.

When a packet satisfies the set rule, Snort saves the log in its database. This provides detailed information of the packet. This study implemented simple packet filtering based on pattern matching by combining a database that can retrieve packet details with the patterns of well-known DRDoS UDP amplification attacks. This study implemented an algorithm that would compare packets with defined patterns based on port numbers, data, UDP length, and IP ID fields and blacklist and block the IPs of matched packets. To validate this, this study attempted an attack using 100 reflector servers with a single host using a Memcached attack tool published on Github [39].

Figure 5 assumes that each of the four IoT sensors sends packets. Each sensor sends 10 weather data packets per second. When an attack occurs and the defense system is working, Figure 5 show how many normal packets in the fog server are received after the IoT sensors sends 10,000 packets.

Immediately after the attack started, the real-time traffic of the fog server was 448 Mbit/s (56 Mb/s packets), more than 50% of a 100 Mbps bandwidth’s capacity on average values. In addition, although the IoT sensor sent data immediately after the attack, the fog server did not receive it.

As soon as the filtering algorithm was applied, the suspicious packets were categorized, and the IPs that met the pattern were added to the blocklist. Snort detected a large number of packets from the same address to port 11211 in a short period.

The IoT Sensor sent 10,000 packets and the fog server received 8118 packets, showing that 1882 packets were lost due to the attack. This can be seen in Figure 5. This experiment was attempted 50 times, and this is the average value. The test results showed that the attack mitigation model ensured more than 80% packet delivery on average, which was affected by a combination of detection time, the time taken for logs to be stored in the DB, the time taken for running the filtering algorithm, the time taken to be registered in the blocklist, and resource usage.

Figure 6 shows the number of normal packets received in 30 s. As shown in the figure, the DRDoS attack begins exactly after 10 s. It may be seen that successful transmission is not performed until the attack pattern is applied and blocking is performed. After that, after normal blocking is performed, the successful packet delivery rate is stable at around 80%.

Packets below the minimum amplification factor of 10,000-fold were attacked using the Memcached attack tool.

Table 4. Transmission quantity by the number of reflectors (Mbps).

Number of Reflectors	Request Packets	Expected Bps	Actual Bps	Ratio to Bandwidth
10	15 bytes	12 Mbps	5 Mbps	68%
50	15 bytes	60 Mbps	22 Mbps	210%
100	15 bytes	120 Mbps	56 Mbps	448%

suggests that the spoofed request packets or attack traffic were lost in the middle, filtered by external routers, DNS, ISPs, etc. In addition, the Memcached attack tool attempted attacks on over 400% of the bandwidth, but the filtering of the fog server performed well to ensure over 80% transmission of the sensor data.

It was confirmed that DRDoS attacks were prevented by the proposed method using Snort in the fog server and that a large number of packets operated normally. However, if server systems with Snort consume a lot of resources, especially CPU time, it can be difficult to apply it to the fog server. So, we measured how much CPU time Snort consumes.

4.3. Resource Usage Test

The purpose of this study is to present a method to defend against DRDoS attacks using Snort on low-specification computers such as fog computers. Therefore, many functions were removed from Snort for low-specification fog computing environments. The rule check is the one that consumes the most resources in Snort. The predefined ruleset was so large that only essential parts were grouped, and other parts were removed. Additionally, the login function was removed from Snort. We modified the configuration file provided by Snort. We tested the resource performance of the fog server with the changed Snort, the fog server with unchanged Snort, and Suricata. The experimental results using Snort and the proposed model is an average value of the experiments of three OS versions: Ubuntu, Kali, and Windows 10. The results of the three versions of the experiment show little difference.

Figure 7 compares the mean resource usage and execution time of Snort, Suricata, and the mitigation model on the fog server under defense mechanisms. Suricata runs faster than Snort thanks to multi-threading, but the tradeoff is a higher CPU usage. Suricata consumed more than 50% of the resources from 30,000 packets per second in fog servers. However, since the fog server had two CPU cores, there was no dramatic change. The proposed mitigation model recorded much lower CPU utilization and execution time, confirming its advantage over conventional IPSs in terms of resource usage [40].

In Figure 7, CPU time in a low-specification fog computing environment, showed similar results for both Snort and Suricata. However, it can be seen that the proposed mitigation model shows a low CPU time, because we use modified Snort with many functions removed. Ref. [32] describes a defense mechanism to mitigate SIP-DRDoS attacks. This method is not aimed at operating at low specifications like in fog computing environments. However, since some security configurations operate in the kernel mode, we obtain a good performance in terms of CPU times, although this method [32] and our proposed method do not use the same environment.

Figure 8 shows the initial running time of the original Snort and our proposed modified Snort and Suricata. These can be meaningless experiments, because most security programs of the server operate continually when they are first executed. However, quick recovery can be an important security factor, assuming that a serious attack kills servers or destroys security systems. Furthermore, these initial running elapsed times indirectly demonstrate the security system’s load.

This work suggests a method for defending against DRDoS attacks by deploying Snort on fog computing environments. For Snort to stably perform on a low-specification computer such as in fog computing environments, a modified Snort with reduced functions was deployed and tested. The results showed a packet delivery efficiency of about 80%. In addition, CPU time was measured at about half that of the normal Snort. However, other security functions of Snort were removed or the log in was removed. This can be far from a stable security system. But this can be an excellent way to cope with DDoS as well as DRDoS attacks in low-specification computing environments like fog computing.

5. Conclusions

Fog computing environments are highly network-dependent because distributed fogs distribute the functions of the cloud. Moreover, denial-of-service attacks such as DDoS pose a great threat to the availability of fog computing. This study investigated fog computing, DRDoS attack patterns, and countermeasure techniques to implement a DRDoS mitigation model and designed a mitigation model based on it.

The mitigation model achieved the study goal of defending against DRDoS attacks by using an easy-to-use attack tool with a reduced specification burden by combining a Snort detection module, simple packet filtering, and filtering distributed processing through Anycast to ensure availability in a low-specification fog environment. The proposed mitigation model maintained availability, with a packet delivery ratio of over 80%, on average, even under over-bandwidth attacks by the Memcached attack tool, and demonstrated low CPU time (resource usage) and initial running elapsed time compared with other methods.

This study compared traditional IPSs and the mitigation model on a low-specification fog server and found that DB inputs and outputs for log analysis were dominant in terms of execution time and resource usage in all systems. Significant performance gains can be expected if the database is optimized or upgraded to a better-performing one. A modified Snort with reduced functions was also deployed and tested. As a result, it showed a better performance. However, other security functions of Snort were removed or the log in was removed. This can be far from a stable security system. But this can be an excellent way to cope with DDoS as well as DRDoS attacks in low-specification computing environments like fog computing.

We used no more than 100 reflector servers using the Memcached attack tool. No matter how much it is amplified, it cannot perform large-scale attacks over bandwidth with a single host, which is a limitation. Although it defended against these small attacks in this study, large-scale attacks that exceed several orders of magnitude in bandwidth will paralyze the router even before reaching the server, so further studies are needed. Moreover, the packet filtering algorithm has the disadvantage of being vulnerable to new types of attacks due to pattern-based matching. Although the simple filtering used in this study is expected to block some new attacks because it only checks the essential options, future studies are required to test hybrid techniques that combine anomaly detection techniques and to examine techniques that classify attack patterns through artificial intelligence neural networks to overcome these shortcomings.