Our team has decided to try the following 4 attacks:
SYN attack
SQL injection attack
DNS poisoning
A brute force attack (to compare this process with more sophisticated attack techniques)
The first attack that we tried was the SYN attack. A SYN attack is a denial-of-service attack where the attacker sends repeated initial connection request (SYN) packets (often with spoofed IP addresses) to overwhelm all ports on a machine. The server then responds to each one of the connection requests and leaves an open port ready to receive the response. While the server waits for the final ACK packet, the attacker continues to send more SYN packets which causes the server to maintain a new open port connection (for a certain amount of time). This ultimately leads to the server not being able to function normally [1]. A SYN attack with spoofed IP addresses is an approach where attackers spoof the source IP address of a trusted server or internet-connected device, making it harder to trace the packets and prevent the attack [2].
For this project, we are using the T-pot honeypot system, which is a multi-honeypot system that supports more than 20 honeypots. Documentation here: https://github.com/telekom-security/tpotce
We simulated a SYN attack on port 80 using hping3, which is a packet generator that lets you send packets with specific flags or payloads. We used the following command:
sudo hping3 -c 15000 -d 120 -S -w 64 -p 80 --flood --rand-source [Server IP Address]
The -c flag specifies that we sent 15000 packets to the honeypot where the size of each packet is 120 bytes (specified by the -d flag) and the packet window size is 64 (specified by -w).
-S specifies the type of packet, which is a TCP SYN packet.
-p specifies that we want to flood port 80.
--flood is used to send packets without waiting for responses, so we can effectively flood the system.
--rand-source uses random source IP addresses for each packet, which makes it harder to track the sender. This is commonly done in DOS attacks.
When we simulated this attack from one of our local machines, we instantly started noticing an overall slowdown of the honeypot server. Our SSH connections to the server started lagging. Since the server had several half-connections, the SYN attack was forcing the server to consume additional resources and it was unable to keep our SSH connections alive successfully. Additionally, running simple commands directly on the server (not via SSH) was also difficult during the attack, since the server was under extreme load and was not adequately processing requests. Overall, we saw that the performance of the server degraded as a result of the SYN attack since resource limits were impacted. We recorded this attack in a TCP dump. Evaluating the network layers impacted by the attack, we know that the primary impact is on the Transport Layer since the attack primarily abuses the TCP handshake process and directly handles the SYN packets. The goal of our project is to research what causes the vulnerabilities at the impacted layers and how they can be improved. We have all started researching the Network Layer after experimenting with this SYN Attack and will be looking into protection strategies to talk about in the final report and presentation.
References
[1] SYN flood DDoS attack | Cloudflare, https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/
[2] What are SYN flood DDoS attacks? | Akamai, https://www.akamai.com/glossary/what-are-syn-flood-ddos-attacks