Simulated and monitored DDoS attacks Write up research

1. Objective

In this project, we looked into Distributed Denial-of-Service (DDoS) attacks by simulating a SYN flood inside a virtual environment. Our goal was to examine how these attacks affect server performance and test whether basic protections could help. We used two Ubuntu servers — one with no security setup and the other secured with iptables firewall rules. The attack was launched from a Kali Linux virtual machine using hping3, targeting both servers at the same time. While the attack was running, we monitored things like CPU load, system responsiveness, and network activity using netstat, tshark, and htop. The results showed that the unprotected server couldn’t handle the attack, with hundreds of half-open connections and a noticeable spike in CPU usage. Meanwhile, the server with iptables stayed stable and kept performing well. This showed us how even simple firewall configurations can make a big difference when it comes to protecting systems from common DDoS threats [1].

1. Introduction

2.1 Overview of the Experiment

This project focuses on learning how Distributed Denial-of-Service (DDoS) attacks work and how they can be stopped, specifically by looking at a type of attack called a SYN flood. A SYN flood targets a weakness in the TCP three-way handshake. Instead of completing the handshake, the attacker just sends a huge number of SYN requests and never follows up with the final ACK. This tricks the server into holding open a bunch of half-finished connections. Eventually, these unfinished requests take up too much memory and CPU power, making it hard or even impossible for real users to connect.

The main goal of this experiment was to simulate a SYN flood attack in a virtual environment and see how well basic iptables rules could defend against it. To do this, we set up a virtual lab in Oracle VirtualBox with three virtual machines: one Kali Linux machine to act as the attacker, and two Ubuntu servers. One of the servers had no protection at all, while the other was set up with iptables to help block the attack and serve as a simple defense system.

We used the Kali VM to launch the SYN flood using hping3, a command-line tool that can send a large number of SYN packets. While the attack was running, we monitored both servers using tools like netstat to check connection states and tshark to watch the network traffic. These tools helped us collect real-time data and see how each server responded when facing the same attack.

This project builds on past cybersecurity research showing that SYN flood attacks, even though they’re simple to carry out, are still one of the most effective and damaging types of denial-of-service attacks. Earlier studies point out that real-time traffic filtering and rate limiting are key ways to stop these attacks, especially when using tools like iptables, which are commonly available on Linux systems [1].

In this experiment, we wanted to not only test these ideas but also show that strong defenses don’t have to rely on expensive, high-end security systems. By using open-source tools and free virtual machines, we were able to create a setup that’s easy to recreate for learning, research, or training purposes.

Fig. 1. Normal TCP handshake vs. SYN flood attack

2.2 Problem Identification (Nature of Attack)

SYN flood attacks are one of the oldest and most common types of Distributed Denial-of-Service (DDoS) attacks. They take advantage of a weakness in the TCP protocol, specifically during the handshake process that sets up a connection between a client and a server. The normal TCP handshake works like this:

The client sends a SYN request to start the connection.
The server responds with a SYN-ACK to acknowledge the request.
The client replies with an ACK to complete the handshake. In a SYN flood attack, the attacker leaves out the final ACK on purpose.
This causes the server to hold onto these half-finished connections, which can eventually overwhelm it and prevent real users from connecting.

Past research and real-world cases show that SYN flood attacks are still commonly used by attackers, either on their own or as part of bigger DDoS campaigns. One reason they’re still so popular is because they don’t need a lot of bandwidth to be effective, which makes them a cheap and easy option for causing disruption. While some large-scale attacks use botnets to send traffic from thousands of devices, our experiment showed that even one machine can create noticeable problems in a controlled setting.

One of the biggest challenges with stopping SYN flood attacks is that they look almost exactly like normal connection requests. Without the right filtering or rate-limiting in place, a server can’t easily tell the difference between a real user trying to connect and an attacker sending fake SYN requests. That’s why tools like iptables and more advanced intrusion detection systems are so important. They help spot patterns in the traffic and block the bad requests before they start draining the server’s resources.

By focusing on the SYN flood attack, this project tackles a type of vulnerability that’s easy to understand but still causes serious damage. It shows how important real-time traffic analysis is and proves that even simple countermeasures, if set up correctly, can make a big difference in protecting a system, even against steady, low-level attacks that target the core of the protocol.

Fig. 2. SYN flood overwhelming the server’s TCP backlog

2.3 Technical Approach

To explore how a SYN flood attack works and what kind of impact it has, we built a virtual setup where we could safely run the attack and see how it affects systems with and without protection. Our approach combined both the offensive side, launching the attack, and the defensive side, like monitoring the traffic and using a firewall to try and block it.

We used Oracle VirtualBox to build the environment, setting up a private internal network called DDoSNet to keep everything contained and make sure nothing outside the lab was affected. The setup included three virtual machines:

Kali Linux (Attacker): Used to launch the SYN flood using tools like hping3.
Ubuntu Server (Unprotected): Had no defenses in place, allowing us to observe the full impact of the attack.
Ubuntu Server (Protected): Set up with iptables firewall rules to help detect and block the SYN flood traffic.
Fig. 3. Virtual machines configured in VirtualBox

​​We used the hping3 tool to launch the SYN flood, since it allowed us to send a large number of SYN packets quickly. The attack was aimed at port 80 on both servers, but we ran the test on each server separately to keep the conditions consistent and make a fair comparison. The command we used was:

sudo: Run with root privileges
hping3: The tool used to craft and send raw TCP packets
-S: Send SYN packets
— flood: Send packets as fast as possible (flood mode)
-p 80: Target port 80 (HTTP)
-I enp0s3: Specifies the network interface to send packets from (here, enp0s3)
192.168.100.10: Target IP address ( unprotected server)
During each test, we used a few different tools to keep track of how the servers were handling the attack:

netstat: Used to check active TCP connections and look for a buildup of SYN_RECV states
tshark: Captured and analyzed packets in real time so we could see what kind of traffic was hitting the server
ping: Let us measure packet loss and latency to get a sense of how responsive the server was during the attack
Before launching the attack, we set up some basic iptables rules on the protected server to act as a simple, local defense. These rules were designed to limit the number of incoming SYN packets and slow down the flood. A breakdown of the rules and how they worked is explained in Section 4.1. This setup made it easy to run the tests in a consistent way and helped us clearly see how well the protections worked by comparing the results from both servers under the same conditions [2].

1. Experiment:

3.1 Network Topology

The network topology is the virtual environment in which the experiment took place using a virtual box consisting of three machines connected via an internal network so that they can all communicate locally. This set simulates a realistic local network server under attacking conditions while remaining isolated from the internet for safety concerns. All machines are connected to the same virtual network (DDosNet) to allow isolated packet exchange without risking external exposure.

TABLE I: VIRTUAL MACHINES

Component

Role

IP Address

Key Configuration

Kali Linux (Attacker)

Launches SYN flood via hping3

192.168.100.30

hping3 tool installed, connected via eth0

Unprotected Server

Target without protection

192.168.100.10

Apache2 on port 80, no firewall or limits

Protected Server

Target with iptables defense

192.168.100.20

Apache2 on port 80, iptables rate limiting

Fig. 4. Internal network settings for the virtual machine in VirtualBox

Traffic Flow and Behavior
The attacker (Kali) sends a high volume of TCP SYN packets using hping3 targeting port 80.
The unprotected server receives all traffic, quickly exhibiting high SYN_RECV counts, CPU spikes, and dropped connections
The protected server uses iptables to:
Allow a limited number of new connections (3/minute)
Drop excess SYN packets beyond that rate
This setup effectively demonstrates the difference in resilience between protected and unprotected systems.

Tools and Services
hping3: Used to simulate the SYN flood from Kali
Apache2: Runs on both servers to simulate a live web service
iptables: Configured on the protected server for DDoS mitigation
htop, netstat, tshark: Used for monitoring CPU, connections, and packet flow
Purpose and Justification
This topology was designed to replicate a realistic internal network under attack, allowing us to evaluate the effectiveness of basic firewall defenses in a repeatable, isolated setting. It reinforces the need for proactive mitigation in cybersecurity infrastructure and provides a safe platform for testing without risking actual production systems.

Configuration and System Setup

The configuration of this experiment is designed with three main iso images Kali linux this was used for the attacker and two ubuntu server images with no GUI or a graphical interface this was done to mimic actually working in a server. With all three iso images downloaded and installed we choose to host on Oracle VMware. Once all three iso images on Oracle initially want to run all three to make sure they work after that you want to go into Oracles settings and go into network for each other servers and switch them to internal network By selecting the Internal Network mode, all virtual machines (such as the attacker, protected server, and unprotected server) are placed within an isolated virtual LAN. This means that network traffic is restricted to just the virtual machines connected to this internal network and does not interact with the host system or the external internet. This isolation is especially important when simulating potentially harmful activities like DDoS attacks, as it prevents any risk of accidentally affecting other systems or networks. Naming the internal network DDoSNet serves an organizational purpose. It clearly identifies the virtual network being used for DDoS testing, which helps avoid confusion when managing multiple virtual networks in VirtualBox. This also enhances reproducibility and documentation by allowing other users to easily replicate the setup using the same network name. Using an internal network configuration ensures that the virtual machines can communicate directly with one another without relying on NAT or bridged adapters. This direct connection is essential for accurately simulating real-world attack scenarios, such as sending flood traffic from an attacker machine to a target server. Overall configuring the network as an internal adapter and naming it DDoSNet creates a safe, controlled, and well-organized environment for conducting the experiment, while also supporting good cybersecurity research practices.

Fig. 5. Network topology used in the DDoS simulation

3.2 Experiment Steps

Step 1: Download Oracle VirtualBox, then download all three Iso images: Kali Linux for the attacker, Ubuntu server image for both servers.

Step 2: Insert all ISO images into Oracle and run them. Name the Ubuntu servers, one protected and one unprotected. Step starting with the Kali Linux install tools like hping3. This was the only tool you needed for Kali. Close the Kali image after.

Step 3: On the Ubuntu unprotected server, install tshark and netstat tools, close them, and do the same thing for the protected server, but install iptables also on the protected server, and then close it.

Fig. 6. Installing hping3 on Kali Linux

Fig. 7. Installing iptables and tshark on the protected server

Step 4: Go into network settings and switch the NAT type to internal do this for all three VMs. This will allow them to talk to each other.

Fig. 8. Internal network adapter settings

Step 5: Now it’s time to assign static IPs, start up the unprotected server, and use the command sudo nano /etc/systemd/network/10-static.network, you then want to write the following into the file

Fig. 9. Static IP configuration on unprotected server

After this is complete, you want to make sure the static IP is saved, so run sudo ip a.

Fig. 10. Verifying static IP on unprotected server

After the static IP is saved, you can close the unprotected server and run the protected server and do the same thing, but make sure the IP is set to 192.168.100.20 instead of the 192.168.100.10 for the protected server.

Fig. 11. Static IP configuration on protected server

Sudo ip a to make sure the changes are applied, then do the same for Kali and assign it 192.168.100.30

Fig. 12. Launching SYN flood from Kali using hping3

Step 6: Run Kali and unprotected, on the unprotected server, run sudo netstat -ant | grep :80, then on Kali launch the flood attack to the unprotected server.

Fig. 13. ping output showing server response

Once the attack is going on the unprotected server and run sudo netstat -ant | grep :80 a couple more times to see if the queue is filling it.

Fig. 14. SYN_RECV queue on unprotected server

As you can see the server is now attacked and will become unresponsive Stop the attack crtl + c, stop the unprotected machine.

Step 7: Run the protected machine and add the IP tables rule listed below.

Fig. 15. Iptables rules applied on the protected server

Step 8: Now that these rules are enabled, run sudo tshark and sudo watch -n 1 “iptables -L INPUT -v — line-numbers”. Now, on the Kali server, run the attack on the protected server: sudo hping3 -S — flood -I eth0 -p 80 192.168.100.20. Now watch the iptables rules and watch the rule drop packets

Fig. 16. Iptables dropping SYN packets on protected server

3.3 Results and Analysis

Fig. 17. Impact of SYN flood on SYN connections and CPU usage

The unprotected server experienced a massive spike in SYN connections (from 5 to 750) and a sharp increase in CPU usage (from 10% to 95%) during the flood. This confirms its vulnerability to SYN flood attacks. The protected server, equipped with iptables rate-limiting, maintained control during the attack. SYN connections only increased slightly, and CPU usage remained low. The experiment clearly illustrates the stark contrast between the behavior of the unprotected and protected servers under SYN flood conditions the unprotected server saw an exponential increase in SYN connection attempts — from just 5 to over 750 — indicating that it was unable to control the flow of incoming traffic. In contrast, the protected server, equipped with iptables rate-limiting rules, maintained a manageable level of SYN connections (peaking at just 12) and experienced only a minor increase in CPU load. This demonstrates that basic filtering rules can significantly reduce the impact of DDoS attacks, even in resource-constrained environments.]

Become a member
These findings emphasize the importance of implementing simple yet effective security measures, especially in systems exposed to public networks. They also highlight the value of proactive defense in cybersecurity practice — waiting until an attack happens is often too late. Proper configuration, even at the firewall level, can be the difference between service continuity and system failure.

1. Protocols and Algorithms for Prevention, Detection, and Countermeasures

4.1 Prevention Mechanisms:

Protocols Implemented

To keep the protected server from getting overwhelmed by the SYN flood, we used iptables, which is a built-in firewall tool found in most Linux systems. It works by checking incoming packets and following a set of rules to decide if they should be allowed through, blocked, or dropped. In our case, we set up iptables to filter and limit the number of TCP SYN packets going to port 80, which is the standard port for HTTP traffic.

Firewall Rules

The following rules were applied to the protected Ubuntu server:

The first iptables rule allows a limited number of new SYN connections to port 80.
The second rule drops any extra SYN packets that go over the set threshold.
The — limit-burst option lets a short burst of traffic through before the rate limit kicks in.
The — limit option controls how many packets are allowed per second after the initial burst.
This setup helps block excessive traffic while still letting legitimate users connect to the server.
These rules used stateless filtering, which means they only checked the packet headers and didn’t track any session information. This helped keep CPU and memory usage low.

Effectiveness and Rationale

This approach was chosen because:

iptables is a lightweight tool that comes bundled with most Linux distributions.
It can be configured to drop excessive traffic before any system resources are allocated, which makes it effective against SYN flood attacks that aim to fill up the server’s connection backlog.
The rules can be easily adjusted to suit different use cases or adapt to various traffic patterns.
During the experiment, the protected server stayed fully responsive and didn’t experience any service interruption, even while under continuous attack. Monitoring tools showed that only a small number of SYN requests were accepted, while the rest were blocked by the firewall before they could use up system resources. This simple prevention method proved to be both effective and practical, showing that even basic tools like iptables can significantly improve a system’s ability to withstand denial-of-service attacks when configured properly [1].

4.2 Detection Mechanisms:

Detecting and mitigating Distributed Denial of Service (DDoS) attacks on a network is very critical for any individual and organization. DDoS attacks can inhibit the daily function of an organization by causing service disruptions since it involves overwhelming the target with high network traffic. To effectively detect and mitigate an attack, it is vitally important to implement network security tools such as the ones used in this project,namely IPtables, Tshark, Netstat, and UFW (Uncomplicated Firewall) which analyzes network traffic, capture network packets and detect anomalies signifying a DDoS attack [2]. Iptables and Tshark were installed and updated on the protected server in order to ensure that they had the latest security and threat updates, while UFW and Netstat were used on the unprotected server. A description of each tool is described below, the algorithms used for detecting the attack and the implementation process.

Monitoring Tools:

iptables:

A command-line tool used to configure the IP packet filter rules of the Linux kernel firewall.
Chains of defined rules are built into the IPtables, such a rate-limiting, and some can be created by the system administrator. These rules control traffic flow because they are defined based on ports, protocols, and IP addresses.
These rules are policies created to enhance security by logging, detecting, and blocking suspicious network traffic patterns.
Tshark:

A command-line tool like Wireshark that is used for monitoring and analyzing network traffic in real time or from PCAP files
Filters for patterns and detects anomalies in the network traffic.
This enhances security in the protected server by conducting deep packet inspection to identify malicious traffic,c and is great for forensic analysis [2].
Monitoring Tools on the Unprotected Server

Netstat:

A command-line tool that displays active connections
Identify listening ports
Monitor network traffic
Identify network anomalies
As a security enhancement tool, it tracks open ports, identifies suspicious connections, and helps to detect intrusions.
UFW (Uncomplicated Firewall):

A user-friendly command-line firewall configuration tool to set rules in IPtables to filter network traffic.
To enhance security, UFW blocks or allows traffic based on IP/port and helps mitigate DDoS attacks through rate-limiting.
On the unprotected server, UFW Status was set to inactive which allowed any network traffic to pass through the firewall.
Detection Algorithms:

To help protect the system and detect possible attacks, we used detection algorithms that monitor for anything unusual or threats. Integrating multiple detection techniques provides a layered approach to securely monitor the network. According to Koushik Chatterjee in the International Journal of Computer Science and Telecommunications [Volume 4, Issue 3, March 2013], the mechanism behind the detection algorithm is enhanced by the accessing of databases for known signatures which is vital in protecting networks from malicious actor; he further states that known attacks are easily detected and that there’s usually no false positives (Chatterjee, 2013). The detection algorithms used in this project are: traffic-based algorithms, Signature-based algorithms, and anomaly-based algorithms, which enhances the network ability to detect emerging DDoS attacks. These algorithms use different methods to detect and capture threats shown below.

Traffic Pattern Analysis: Compares real-time traffic with normal baseline traffic. A sudden spike in traffic volume can trigger an alert indicating a possible DDoS attack.
Signature-based Algorithm: Used for pattern matching, which compares real-time network traffic to known DDoS attacks stored in the Database.
Anomaly-based Detection Algorithms: Watches for deviations from normal network traffic behavior, such as excessive requests from unknown sources, which indicates a possible DDoS Attack.
Implementation Process:

In order to detect possible attacks, there is a need to configure the network security tools on the servers to detect attacks. The following step-by-step process makes sure that everything works smoothly and all alerts are accurate.

Configuring the Tools: protected server

iptables and Tshark were installed and configured on the protected server.

Iptables were configured in the command line interface (CLI) by defining rules which allow traffic only from sources that are trustworthy. This is implemented by defining two rules using the command line interface, “sudo iptables -A INPUT -p tcp –-dport 80 –syn -m -limit –limit 3/minutes –limit– burst 5 -J ACCEPT” and “sudo iptables -A INPUT -p tcp –dport 80 -syn -j DROP. These rules are set to protect the server from SYN flood attacks and to control the number of incoming TCP connection requests that are allowed through port 80 (HTTP).
The CLI input: “sudo iptables -A INPUT -p tcp –-dport 80 –syn -m -limit –limit 3/minutes –limit– burst 5 -J ACCEPT” is a rate-limiting chain rule that allows only three new incoming TCP connections per minute on port 80, and allows an initial burst of 5 connections before the limit kicks in.

SYN connections that go above this threshold will continue to the next rule in the chain which is “sudo iptables -A INPUT -p tcp –dport 80 -syn -j DROP” . This rule blocks incoming TCP connections that match the first step of the TCP handshake on port 80: it silently drops the packets by not sending an acknowledgement. Please see image below:

Protected server with iptables protection rule defined

Tshark is configured to monitor, capture and filter the network traffic by using the CLI command “sudo tshark -i eth0”.
Configuring the Tools: unprotected server

Netstat and UWF were tools installed and configured on the unprotected server. UFW was usually actively protecting the server by default, but in this project, it was disabled to make the server vulnerable to attacks. See picture below:
Fig. 18. UFW disabled on unprotected server

Netstat was configured using the following command on the CLI : “sudo netstat -an | grep SYN_RECV |wc -1”, which is a command executed by the root user to identify and count the number of incoming HTTP connections to the server. During a SYN flood attack, a large number of SYN_RECV connections are received and an unusually high number of incomplete TCP handshakes demonstrates a possible attack. Please see below :
Fig. 19. SYN_RECV count showing 182 half-open connections

Establishing a Baseline:
A baseline was first established to monitor the protected and unprotected server.

The baseline was established on the protected server by using the command “sudo watch -n 1 “iptables -L INPUT -v –line numbers” and the sudo password , which displayed in the terminal that there were no packets received, accepted or dropped as seen in the image below:
Fig. 20. Baseline of Protected Server

The baseline was established on the unprotected server by using the command “sudo netstat -ant | grep :80 ” and the sudo password, which displayed in the terminal that there was no traffic between the unprotected server and the Kali attacker server as seen in the image below:
Fig. 21. Baseline of unprotected server

Configuring Detection Algorithms

Detecting and mitigating Distributed Denial of Service (DDoS) attacks on the servers utilized various detection techniques, which included traffic pattern analysis, signature-based detection, and anomaly-based detection. Reviewing the logs and alerts enabled the knowledge of whether the rules applied were effective or defective based on the traffic behaviors.

Traffic-Pattern Analysis was used by comparing normal traffic patterns with real-time data on Tshark and Netstat. Neither tool needed adjustments because they were very effective in sending alerts of the spike in the network traffic, as seen below:
Tshark registered the packets from the attacker (kali) ip address 192.168.100.30 to the protected server ip address 192.168.100.20 during the SYN flood and we can see that they are being sent from kali to the protected server and the type of protocol was TCP.
Fig. 22. Tshark logs showing TCP SYN flood traffic to protected server

Netstat registered the hping attack that was launched by the attacker (kali) ip address 192.168.100.30 against the unprotected server at ip address 192.168.100.10. The increase in the traffic was immediately displayed in the terminal along with several SYN_RECV acknowledgements without the TCP three-way handshake being completed. Please see the image below:
Fig. 23. Netstat detects the hping attack from the attacker’s IP address.

To further analyze the traffic in Netstat, the command “sudo netstat -an | grep SYN_RECV | wc -l which displayed the number of SYN_RECV received was 182, and then a few seconds later 312 SYN_RECV was registered. Please see figures below:

The hping3 attack is requesting three way handshakes and the server is overloaded. A regular server would be a low number and a high load aka an attack would be a high number .

Netstat registered (SYN_RECV) overloading on the unprotected server.

Signature-based detection was enacted to detect known attack patterns, such as SYN flood attacks, by defining rules to detect repeated connection attempts that match malicious behavior. The following rules were implemented:
sudo iptables -A INPUT -p tcp –-dport 80 –syn -m -limit –limit 3/minutes –limit– burst 5 -J ACCEPT which limit the amount of traffic flow that is accepted.
sudo iptables -A INPUT -p tcp –dport 80 -syn -j DROP which drops all SYN packets which are suspected to be malicious.
Anomaly-based detection helped to detect abnormal network traffic behaviour by using custom rules and commands to spot strange or unexpected activity to catch common DDoS behaviors. Both a combination of the tools used in traffic pattern analysis and signature-based detection were also effective in capturing the abnormal spike in the network traffic. Below is an image of the various tools registering the anomalies:
Fig. 24. Tshark output shows server unreachable

Fig. 25. Iptables showing dropped SYN packets during flood

Fig. 26. Netstat shows abnormal connection activity.

4.3 Countermeasures:

Immediate Actions Taken on the protected server:

When the attack was detected on the protected server, the malicious IPs and traffic were immediately blocked based on the rules defined in the chain rules in the iptables seen below:
. After the first 5 connection attempts, rate limiting is activated to limit only 3 connections per minute and the number of requests that were coming from one source. There were 14 packets accepted and 8422K dropped as seen in the image below:
Fig. 27. Iptables showing 8422k packets dropped and 14 accepted

These actions mitigate the impact and prevent further damage on the protected server by \allowing a few traffic to allow legitimate users access and handle spikes in the network traffic.
Long-term Solutions:

Implement an Intrusion Detection / Prevention System like Snort to help further secure the network parameters.
Install Wireshark for real-time network traffic analysis since it is a more advanced tool.
Immediate Actions Taken on the protected server:

There were no countermeasures on the unprotected server so that the deadly effects of a DDoS attack can be clearly noted. In a real-life scenario, reenabling the UFW, installing Wireshark and an Intrusion Detection/ Prevention System (IDS/IPS) like Splunk would be very effective. Better yet, with the ever evolving landscape in the technological arena, there might be a need for a greater defensive system like an AI-powered system [1].

1. Conclusion:

This project was a very transformative project because it demonstrates that if someone has a computing device but cannot afford an expensive IDS/IPS, having this knowledge of enabling basic command line tools is a major step in establishing a protective home or enterprise network. This project exposes the effects of a DDoS attack on two servers, an unprotected and protected server, which demonstrates how even having the least bit of prevention mechanism, such as installed tools like Iptables, can be defensive against a DDoS attack. The outcomes were significantly great, which are:

The unprotected server was taken down by the attacker.
The protected server withstood the attack.
Spike in the network traffic was detected by tshark, and netstat was effective
Defined chain rules in the iptables helped to mitigate the attack on the protected server.
Finally, this project demonstrates that using basic command-line installed tools can also form a layered defensive approach, if high-end IDS/IPS tools are not affordable, and they are available for use by anyone who needs it.

1. Future Recommendations:

Further advance the DDoS attack using botnets against the protected server and monitor how it keeps up under various levels of attacks..
Enhance the attacks to use UDP Flood, HTTP flood, and ARP spoofing.
Integrate System Information Event management (SIEM) tools and a playbook to establish guidelines to identify vulnerabilities before there is a disruption in the organization’s network [2].
Design and develop a framework to mitigate DoS/DDoS attacks using IPtables Firewall (Chatterjee, 2013).
References

[1] A. S. Ahmed, M. A. Rashid, and M. A. Rahman, “Design and Development of a Framework to Mitigate DoS/DDoS Attacks Using IPtables Firewall,” ResearchGate, Jan. 2013. [Online]. Available: https://www.researchgate.net/publication/237006612_Design_and_Development_of_a_Framework_to_mitigate_DoSDDoS_Attacks_Using_IPtables_Firewall

[2] Datadome, “What Is a Network Intrusion Detection System (NIDS)?,” DataDome Learning Center. [Online]. Available: https://datadome.co/learning-center/what-is-a-network-intrusion-detection-system/