Lightweight log-monitoring-based mitigation tool against WLAN attacks

ABSTRACT


INTRODUCTION
Wireless local area networks (WLANs) have become an integral part of our modern communication infrastructure, providing seamless connectivity and added convenience [1], [2].WLANs are networks that utilize the air as their transmission medium.Hosts on these networks typically communicate with an access point (AP) which is connected to the Internet allowing the delivery of information back and forth.The advantages of WLANs are numerous, including ease of installation where there is no need to install a cable to every connected station, affordability as the access point is not expensive and wire costs are negligible, increased productivity because users can move freely while staying connected to the internet, and reasonable data rates which can reach up to 1 Gbps (with the release of recent standards).
However, the proliferation of wireless technology has also introduced new security challenges, as wireless networks are susceptible to various types of attacks that can compromise their integrity and availability [3], [4].These security challenges stem from various factors: firstly, the wireless communication medium functions as a broadcast medium, allowing any station within proximity to intercept traffic from other stations.Secondly, early wireless networks had weak security protocols that have improved over time, yet many devices still employ outdated technologies with vulnerabilities.Thirdly, individuals often connect to available wireless networks without verifying their authenticity, especially when in unfamiliar or travel settings.The primary wireless network technology is Wi-Fi, utilizing radio waves, with frequencies such as 2.4 GHz and 5 GHz.Each of these frequencies is presenting advantages and disadvantages [5], [6].Wi-Fi networks typically feature an access point to provide wireless connectivity to other stations, forming a basic service set (BSS) that constitutes a wireless local area network.
This paper delves into WLAN security, more specifically, we develop defense tools aimed at safeguarding WLAN against three prominent attacks: dynamic host configuration protocol (DHCP) starvation attack [7], address resolution protocol (ARP) poisoning attack [8], and Wi-Fi deauthentication attack [9].These attacks represent significant threats to WLAN security and have the potential to disrupt communication, compromise data confidentiality, and enable bad actors to gain unauthorized access.
Here is a brief about each protocol and attack: first, DHCP dynamically assigns IP addresses to hosts, while the starvation attack is when an attacker exhausts the available IP addresses on a DHCP server by requesting excessive leases.On the other hand, ARP maps IP addresses to media access control (MAC) addresses, while the poisoning attack is when an attacker sends falsified ARP messages to associate their own MAC address with the IP address of another device.Lastly, the deauthentication attack is when an attacker sends deauthentication frames to disconnect devices from a Wi-Fi network, disrupting their connectivity.Current research on DHCP starvation attacks in WLANs faces several drawbacks.Firstly, many studies primarily focus on traditional mitigation techniques, such as rate limiting or DHCP snooping, which may not adequately address sophisticated attack variants or evolving attacker strategies [10].Additionally, most of the research tends to overlook the potential impact of these attacks on real-world networks, often relying on simulated environments that may not accurately replicate complex network dynamics [11].
Research on ARP spoofing attacks against WLANs encounters several limitations.Primarily, many studies focus on conventional countermeasures, such as static ARP table entries or ARP cache validation, which may not effectively mitigate sophisticated ARP spoofing techniques employed by attackers [12].Furthermore, most of the research often relies on simplistic network topologies or simulated environments, which may not accurately reflect the complexities of real-world WLAN environments [13].
Research on Wi-Fi deauthentication attacks faces several limitations.Firstly, many studies primarily focus on conventional mitigation techniques, such as implementing intrusion detection systems or deploying wireless intrusion prevention systems, which may not effectively counter sophisticated deauthentication attack strategies [14].Additionally, most of the research often relies on simplified network models or simulated environments, which may not accurately represent the complexities of real-world Wi-Fi networks [9].
Addressing these drawbacks is crucial for advancing WLANs and enhancing their resilience against attacks.Despite their long-standing presence, ongoing research continues to explore these vulnerabilities.Consequently, modern solutions coexist with effective traditional methods.This paper aims to design and implement a GUI-based WLAN defense/attack tool.It will apply defenses to shield the network and generate attacks for testing.The code is open source, facilitating customization by companies and enhancing usability.Additionally, it offers an extra layer of protection for regular users against network and device vulnerabilities.Detection of attacks relies on a novel method, monitoring DHCP server logs and router activity logs via firmware.The proposed tool efficiently detects and resolves attacks, validated through deployment and testing in a real environment rather than a simulator.
The remainder of the paper is organized as follows: section 2 reviews current research on mitigating these challenges.In section 3 introduces our comprehensive defense design.In section 4 presents tests assessing the performance of our defense tools under different conditions, offering insights into their effectiveness and limitations.

RELATED WORK
In this section, several related state-of-the-art papers are presented.These papers discuss the attacks we are handling in this project.The attacks are DHCP starvation, ARP poisoning, and Wi-Fi deauthentication.

DHCP Starvation
To detect this attack, investigators usually resort to monitoring DHCP server logs [15] to narrow down the culprit of the attack.An intrusion detection system (IDS) can be used for such monitoring.Systems like these typically use two types of detection; the first of which is signature-based detection which will assess network traffic based on previously known attack methodology and notify a network administrator when a known attack may be happening on the network.The second type is anomaly detection which is far more complex.It will learn the normal activity to come to expect on the network over time based on legitimate users' usage and traffic, then will be able to identify when abnormalities arise.Tripathi and Hubballi [11], the paper delves into a smart anomaly-based IDS specifically intended for monitoring DHCP-related attacks.This system uses training and testing phases, much like a machine learning algorithm, in order to profile expected traffic related to DHCP training, then is fed abnormal cases where a starvation attack is targeting the test DHCP server testing.The testing phase can use one of the many attack generation tools (such as dhcpig [16]).
Tripathi and Hubballi [17], more advanced methods of the attack are discussed.These are targeted towards specific victims on the network as opposed to a network-wide attack that starves the DHCP pool entirely.Such an attack could be used to deny service from specific subnets on a network, those of which could be intended for critical functions.These methods include directly interrupting the discover-offerrequest-acknowledge (DORA) message exchange by sending spoofed replies and, as a result, targeting the attack at specific victims (disallowing them to lease addresses).The more advanced detection methods mentioned in [11] are necessary for the detection of some of the newer iterations of the attack from [17].
To prevent attacks, implementing rate limiting is crucial.Huawei [18], rate limiting restricts the rate at which DHCP messages are processed on the server side, minimizing the effectiveness of targeted starvation attacks.This was achieved by implementing rate limiting on the WLAN device, such as a home router functioning as the DHCP server.By monitoring packet rates through each port, suspiciously high volumes trigger independent examination channels, preventing disruption to legitimate traffic and server functionality.While this method protects against server shutdowns, it doesn't prevent address pool starvation.Alternatively, rate limiting at the address level restricts specific MAC addresses from sending further requests if they exceed a preset packet volume threshold, ensuring that no attacks are allowed to occur.Some of the referenced related work like [19] has tried (and mostly failed) to introduce authentication methods for DHCP message exchanges.Given that DHCP packets are of the UDP type, meaning they are connectionless and have no authentication, any client local to the network can send requests to the DHCP server and be leased an address without checking for legitimacy.This would seemingly be fixed by using an authentication method, but most WLAN implementations that have previously attempted this fell short of fully preventing starvation attacks with this method [19].As an alternative to the covered existing research, we propose a method involving periodic ping sweeps to check the legitimacy of IP-leases.Accordingly, our tool will perform the necessary changes if suspicious activity is detected.

ARP poisoning
Normally, detecting ARP spoofing could be tricky as to where to look.Typically, a network analyzer such as "Wireshark" can help as using such programs can give the user alerts if an ARP poisoning attack is detected [20].Atmojo et al. [21], a machine learning model is trained using features such as IP addresses, transmission control protocol (TCP) port, user datagram protocol (UDP) port, length, protocol, and MAC addresses.The model is trained and used to assess the test data and to classify each record if it is a normal activity or is an ARP poisoning attack.
Meghana et al. [22], the approach used to prevent ARP poisoning is to have a static ARP table, meaning manually configuring the bindings for each host in the network.This method has many disadvantages, primarily being that most networks are dynamic such that there is a DHCP server in the network and so mappings are not permanent.In addition, this method becomes impractical in larger networks.Another method would involve adding a layer of security using stateful ARP, such that a device would keep distinct records for ARP requests and ARP replies.Once the device receives an ARP reply, it first checks if this reply corresponds to a sent ARP request.If no request was sent, the host would suppose that the ARP reply received was in fact sent by an attacker and so would discard it and not update the ARP table.Despite that this solution would be effective, changing into a stateful ARP requires alteration of the already in use protocol.
Another technique to prevent ARP poisoning, which is discussed in [23], is to implement a client-side checker with a voting system.In the case of ARP tables, updating the system would wait for a random interval from 0 to 100 milliseconds, then sends a voting request for all other systems in the network to get the correct IP and MAC address pair.Upon the voting result, if a MAC address gets more than 50% of the votes it will be accepted, and the ARP table and cache will be updated.In our implementation, we propose incorporating a duplicate detection system to check for (incorrectly) repeated MAC addresses in any host's ARP table.The tool would take this as a sign of malicious activity occurring during the communication between wireless hosts on the network; thus, potentially a man-in-the-middle (MiTM) attack!

Wi-Fi deauthentication
Typically, implementing security measures such as strong Wi-Fi network passwords, Wi-Fi protected access version 3 (WPA3) encryption [24], or intrusion detection systems can help mitigate the risk of this attack.Otherwise, an incident response team may need to sift through communication history, using network monitoring tools, to analyze the network traffic searching for unusual patterns.Latha and Bommi [25], suggested using machine learning-based IDS alongside hardware, software, and upgrades to handle WLAN incursions.Experimental results showed the proposed machine learningbased IDS achieved a high detection capability, with a 96% detection rate for denial-of-service (DoS) attacks and a maximum classifier accuracy of 88.8%.However, utilizing machine learning for deauthentication attacks can be challenging due to their unpredictable nature.Training a model, particularly with numerical features, may yield inconsistent results, reflected in the research's accuracy below 90%, which is suboptimal for mitigating attacks affecting host device availability.
Khasanova [26], has attempted to tackle Wi-Fi attacks by examining the contents of dissociation and deauthentication frames.This approach can prove effective if there is a known signature causing suspicion of a potential attack.It is also useful to detect more dangerous attacks which may target the access point as well as the clients on the WLAN.All in all, this research's methodology is less than ideal for any kind of mitigation as it involves a lot of sifting through captured traffic to find evidence and is rather reactionary.
The experimental and traditional findings demonstrate the effectiveness of defense strategies used against this attack.Unfortunately, they nearly always rely on a higher level of security or the aid of machine learning techniques, both of which may increase network-setup costs and may not be widely supported just yet.However, monitoring the order of log messages provides a consistent pattern whenever a legitimate device deauthentication happens.Using a series of conditional programming statements can help isolate incidents where bad actors may be involved in a wireless device dropping their connection suddenly.

PROPOSED METHOD
Conventional cybersecurity defenses are largely rooted in wired techniques [27], often prove inadequate in mitigating the dynamic nature of wireless attacks.By integrating innovative, purpose-built scripts, and a seamlessly coordinated defense strategy, our approach seeks to strengthen wireless network security against a range of potential threats.For testing purposes, the attacks are generated in a controlled test environment.Moreover, the defense approach uses shell scripts to prevent attacks, overcoming router storage constraints and allowing users to customize parameters.Figure 1  1065 connected to the router via an ethernet cable to ensure stability, performance, and security.This was done to prevent deauthentication attacks on the logging system, preventing log loss.
In the proposed network structure, a TP-Link router was used which supports 2.4 GHz and has a custom OpenWrt firmware v18.06.OpenWrt firmware is chosen for its high customization, security, and stability.Moreover, the router had limited flash storage (4 megabytes) and approximately 70 kilobytes were accessible after installing the needed tools.Due to the limited storage, the newest firmware version was incompatible with the router.The firmware had to be Linux-based to run the shell scripts.In addition, it needed to support our desired customization for the logging system.
Logs are sent to an external server using TCP protocol for reliability.The logging server's IP is the same as the defense machine's and is a static lease on the router.The coreutils-nohup package is installed to run commands without hang-ups.Moreover, Rsyslog package was installed to ensure the logging server was up and running.We configured the logging server to run over TCP protocol.The Rsyslog offers high performance when it comes to sending and processing log messages because it utilizes multithreading.In addition, it offers the ability to configure the output format.In summary, the developed design is composed of two tools; attack and defense, which run independently.Both have a GUI which was built using Python with the Tkinter library to be user-friendly.

Attack suite
The attack design mainly consists of existing tools for performing the attacks in a controlled environment.This tests the defenses' effectiveness.We used several methods to perform the three attacks.
First, the DHCP starvation attack can be generated using many tools such as Hyenae, dhcpstarv, dhcpig, Gobbler, and Yersinia.We moved to a Python script written using the Scapy library found on GitHub [28] to perform the attack because these scripts are available to anyone and could be used unethically.Yet all the tools work on the same basis, which goes through the DORA cycle.
The DHCP starvation script works by sending the full DORA cycle using random MAC addresses to lease as many IP addresses as possible from the pool.The script initiates by generating a random MAC address and sending a DHCP discover packet with the spoofed MAC address.The script then iterates until receiving a DHCP offer packet or reaching a preset attempt limit.In persistent mode, it continuously sends DHCP discover packets if no offers are received; otherwise, it retries a number of times before concluding the attack.Subsequently, it transmits a DHCP request packet with the obtained IP and spoofed MAC address, ultimately executing the DHCP starvation attack by invoking the main function with specified arguments.
Secondly, regarding the ARP Poisoning attack, we had two options; the first is the Arpspoof tool, which is a command line-based tool that was fast and functioning as expected.The second was Ettercap, which has a GUI and functions correctly but is slower than Arpspoof, and we would rather not to deal with an additional, third-party GUI.Therefore, the ARP poisoning attack is orchestrated using Arpspoof to facilitate a MiTM scenario between two devices.Arpspoof tool leverages ARP spoofing, sending falsified ARP messages to the target hosts, thereby linking the attacker's MAC address with the IP address of the intended victim.With this manipulation established, Arpspoof intercepts network traffic between the victim and the router, enabling the attacker to potentially compromising sensitive information or launching further network attacks.
Lastly, for the Wi-Fi deauthentication attack, we may use airplay-ng or MDK4.Airplay-ng is compatible with many devices and easy to use and set up.MDK4 is widely supported, very stable, and reliable, but more challenging to set up and use.Nevertheless, both tools work similarly; by switching the adapter to monitor mode (promiscuous) and sending the packets to the targeted devices.The deauthentication attack was executed using Airodump-ng and Airplay-ng through the following steps.Firstly, monitor mode was initiated with the command "airmon-ng start interface-name".Then, the Airodump-ng tool was employed to scan the wireless medium and gather necessary data.Finally, the deauthentication attack was launched via the Airplay-ng command, targeting the identified basic service set identifier (BSSID) and station, and specifying the number of packets to be transmitted to forcefully break their connection.

The defense suite
The developed defense design consists of two main components.The first of which is the series of scripts we have written to apply defenses, and the other is the GUI from which the defenses can be applied, and shows recent logs, an ARP table, and DHCP leases updated frequently.The user can choose to enable the defense or not.
The defense approach is a lightweight solution to overcome the router's storage constraints.Specifically, the defense suite consists of scripts to apply defenses as shown in Figure 2, by verifying active IP addresses, preventing duplicate connections, and detecting and mitigating Wi-Fi deauthentication attacks.These scripts provide robust defense mechanisms against various network threats, contributing to overall The first script checks the DHCP lease-file for active IP addresses to test lease legitimacy.If a host is active and is currently using an IP address, it responds to echo request with an echo reply.If the host is inactive, it is assumed to be a false lease.Consequently, the host's address is reported and removed from the DHCP server pool.Figure 2(a) shows a detailed flowchart of the defense script for DHCP starvation.
The second script defends against ARP poisoning.It works by monitoring exchanged messages for any possible duplicate MAC addresses.If it detects duplicate MACs, it blocks that MAC from connecting to the AP.This modifies the wireless configuration to deny connections as the duplicate MAC address represents the attacker's MAC address.
The third script scans logs for Wi-Fi deauthentication events.The script continuously scans the logs for any "disconnect" message, which may be a possible attack.Particularly, an attack is detected if a certain pattern of logs appears which is the existence of a disconnect message that is not followed by a dis-association message.If an attack is detected, it generates a random MAC address, updates wireless configuration, and restarts the interface to prevent progress.
Changing the network's BSSID to a new randomly generated MAC address will nullify the attacker's attempt to deauthenticate WLAN hosts since the attack involves targeting a specific BSSID.A side effect of the script described is a very minor drop in connection for legitimate users while the BSSID is updated.However, from our testing, this drop is negligible and does not hurt availability for clients.This means that despite a minor lag that some may experience, their access to the network and anything they may be doing via the internet will not be negatively impacted.

RESULTS AND DISCUSSION
In this section, we will show the results by displaying screen shots for scenarios before and after applying the defense scripts.First, Figure 3 shows the attack suite GUI interface.We show how to generate each attach, and how to defend against it.

Testing DHCP starvation defense
In order to set up the generation of the DHCP starvation attack, we needed to use the Kali VM.By default, the attack script would send a specific number of DHCP requests.To test the attack in this initial scenario, we reduced the DHCP pool size to accommodate the limited duration of the attack.After confirming that it was functioning as expected, we used the persistent mode of the script in order to keep the attack running indefinitely.This would result in the starvation of the entire pool, regardless of size, which would eventually be eventually successful.
First, without defenses applied, the network was affected by the starvation attack quickly (in a matter of seconds), where it lost the ability to lease IP addresses to legitimate hosts.Had the pool size been bigger, the time needed for the attacker to complete starvation would have been slightly longer.As can be seen in Figure 4, the victim device attempting to connect to the Wi-Fi SSID "TEST" (the test network) would be unable to get past the "obtaining IP address" stage as the pool was all used up by the attacker's leases as shown in Figure 5.If a successful DHCP starvation attack had already happened, and the defense was reactively applied, the network would recover as follows: first, the defense machine would perform ping sweeps at the interval already specified in the defense script.Secondly, the maliciously leased IP addresses wouldn't all be able to respond and the defense machine would, as a result, remove these from the lease file as shown in Figure 6.This would then allow legitimate hosts on the network to successfully lease IP addresses once again.Figure 6.Recovered DHCP pool (functioning normally) If the defense machine had the defense active, and the attack happened to occur at the same time, the malicious leases would not be effective at starving the pool.This is because the periodic pings to leased addresses would stay right on top of the attacker's leases and remove them from the lease file; resulting in the DHCP service's availability remaining intact.While the defense is applied, the attacker's leases would be recognized as malicious and removed from the lease file immediately.

Testing ARP poisoning defense
To generate the ARP poisoning MiTM attack, we used the Arpspoof tool.We tested on a Windows laptop first, but the security features of Windows 11 blocked the attacks as it would re-send an ARP request even after receiving a spoofed ARP reply.To get past this, we opted to use a device running an Android security patch level.This device fell victim to the fake ARP replies.At this point, the ARP tables of the router and Android device were successfully poisoned.We confirmed this as the Android device had lost connectivity to the router.With no ARP poisoning defense applied, an attacker can poison the ARP table of both the router and a victim.Consequently, the attacker can play MiTM between the router and the victim.By sending ARP reply packets to both devices, the changes would be accepted and saved to the ARP tables.
Figure 7 shows running the "arp" command before and after the attack is performed.We can see that the router's ARP table has changed after the attack and now there are two IP addresses with the same MAC address; one is the MAC address of the attacker and the other is for the victim (wrong pair with the IP).It is also noticed that the victim is unable to communicate with the router as the packet is sent to the router's IP, but on layer 2 level any packet would be destined to the attacker as it would have the MAC address of the attacker.1069 continuously monitoring the router's ARP table would rapidly isolate the attacker and deny them access.In such a case, the poisoned ARP table will be restored promptly with a minor delay in the next communicated packet.
Figure 8.Detection of attack and recovery of ARP table

Testing Wi-Fi deauthentication defense
To test the deauthentication attack, we will first show what happens without the defense applied.The attacker successfully deauthenticates the victim, which leads to disruption of network connectivity.By forcing the victim's device to disconnect from the network, the user will lose the ability to access the internet, communicate with other devices, or utilize network-dependent services.When the attack was successful, as we can see in Figure 9, the logs showed that the victim had a "disconnected" log from the hostapd service without "disassociated" and "deauthenticated" logs.In addition, if the victim attempts to reconnect while the attack is in progress, they will be deauthenticated once again and lose connectivity almost immediately.The next test was done after the occurrence of an attack, and the victim was not able to reconnect to the WLAN.Here we enabled the deauthentication defense, which will generate a random MAC address and change BSSID to that new random value; the defense script can be seen in action in Figure 10.The time to change BSSID and randomize MAC varies for different attack scenarios, but eventually, in all scenarios, the network is available for all legitimate users, and all of them will be promptly moved to the new BSSID and MAC.This is because the beacon messages are sent every 100 ms. Figure 10 also shows that the interface WLAN0 is initially not found.But, once the script runs, the interface is updated with the newly generated MAC, and the interface is found once again.Finally, when performing the attack with the defense active, we can see that the victim will still be disconnected, but as the defense is actively scanning the logs, it will detect the attack instantly, generate a random BSSID and MAC and apply them right away to the router's configuration.This will restore connectivity to the victim soon enough without affecting other legitimate users.So, while the attack may still be going on, it would have zero effect on our router.In fact, it is attacking a BSSID that no longer exists!.

Discussion
Overall, the tests demonstrated effective defense mechanisms and user-friendly interfaces for executing and monitoring network actions.Table 1 summarizes the effects of generating the attacks while the defenses are applied to logs, legitimate users, attacker, victim, and router.The DHCP defense script performed a ping sweep on all the leases, for which we need to experiment with different ping counts.We started with four echo request/reply pairs; it worked successfully but needed some time to ping every device on the network hence slowing down the performance of the defense; for that reason, we reduced the count to one because all the devices are on our local network and theoretically no packets will be lost.That change succeeded in less time with reduced network traffic.Moreover, removing the leased IP record from the DHCP leases file in the router temporarily removed the lease, but when the devices communicated with the router, the entry would be inserted again.As a result, we needed to remove that record by restarting (committing) the DHCP service.This, however, didn't affect legitimate devices trying to obtain an IP address from the server.During testing, we noticed that the ARP table was not being periodically cleared.As a result, we needed an ARP script to restart the network upon completion of each loop iteration to apply its changes if an attack was detected.This restart was critical for the stability of the network after suffering an ARP poisoning attack.It also helped ensuring that there were no residual invalid ARP table entries.
The deauthentication defense script needed a new random MAC address to be applied to the new BSSID.This MAC would be applied to the router's wireless interface to broadcast the BSSID; however, for this change to be applied, we needed to reinitialize the wireless interface, but reinitializing it would sometimes fail.We also tried bringing the interface down and back up again, which also failed sometimes.To ensure that the change would be stable, we concluded that the only way the interface would operate again is by applying a new MAC, which is done by having flags in the script and running a script if needed.
It is worth mentioning that the newest generation of wireless security protocols, known as WPA3, is intended to increase the security of Wi-Fi networks.Although WPA3 primarily focuses on enhancing encryption and authentication processes, it does provide some features that are able to mitigate the studied attacks.However, not all devices or routers support WPA3.

CONCLUSION
In this paper, we have developed and tested defense mechanisms against three critical wireless network attacks: DHCP starvation, ARP poisoning, and Wi-Fi deauthentication.Our study demonstrates the efficiency of our innovative defense strategies in mitigating these threats.Through careful design and scripting, we have successfully mitigated the disruptions caused by these attacks.Our defense mechanisms effectively restore DHCP pool functionality, detect and prevent ARP poisoning, and rapidly restore connectivity after most Wi-Fi deauthentication incidents.As wireless security evolves, our research underscores the importance of adaptive defense mechanisms.By proactively addressing vulnerabilities and deploying agile countermeasures, we contribute to the ongoing effort to ensure secure and reliable wireless network operations.The future work could include the addition of a report generating feature for the defense GUI that contains the current status of the router as well as the latest attacks performed on it recently.This would help provide incident response teams with a clear breakdown of what happened and how it was addressed by the defense tool.It would also be useful in trying to understand & respond to more modern attacks that may occur in the future.

Figure 1 .
Figure 1.Test environment hardware setup


ISSN: 2502-4752 Indonesian J Elec Eng & Comp Sci, Vol.35, No. 2, August 2024: 1061-1072 1066 network protection.More precisely, the defense tool uses five shell scripts executed using the /bin/sh interpreter.Three of them are attack-specific and two for generating and setting random MAC addresses.

Figure 4 .Figure 5 .
Figure 4. Legitimate host unable to lease an IP address

Table 1 .
Attacks' effect on the network