Let's start with sim floods, as this is like one of the most popular TCP IP transport layer DDoS attacks. But before actually starting to discuss SYN floods, in my opinion, it is better to refresh your knowledge on three way handshake and how it works. In three way handshake, the client initiates the TCP connection with a SYN request. And then the host replies with a SYN ack. And finally, the client confirms it with an act. So this is like the standard procedure.
As you already know, when it comes to SYN floods, the attacker pretending to be a legitimate user sends multiple SYN requests. And he doesn't care about replies. From a network perspective, he doesn't care about syntax he will receive he just keeps sending SYN requests. So that after some time, the host will not be able to respond to any requests from Meanwhile, as all these resources will be occupied by the attackers requests, so the legitimate users will be kept pending by the host. And they will wonder why the server has stopped responding all because of the attacker. This attack fashion can be implemented both with a single source meaning in a DOS fashion or it can be carried out in a DDoS fashion by using multiple sources sending SYN requests.
So how can a network engineer detect such an attack? Here, we see a sample over SYN flood. So this is basically more or less how it looks like all the time. As you can see, the source IP constantly sends the SYN requests as we just discussed, to the same port of the destination. And when it comes to filtering, per flags on Wireshark This is the simplest And best way to filter the traffic for the SYN flood capture. Basically, we are setting the SYN flag to one and act two zero in order to filter out snacks in traffic, and therefore just to be able to focus on the sense, and probably the most important part, how to mitigate it.
The first advice is increasing backlog queue. This is basically to allow the server to be able to handle more incoming SYN requests. Here, we are actually just increasing the memory. second method is to recycle the oldest half open TCP connections. It basically means overwriting the list of half open TCP connections. In other words for all the SYN requests which have been received, replacing constantly the oldest ones with the newest ones in the table.
This is where the word recycling comes from. For the remaining Items, meaning SR cookies, firewalls and proxies with right controls. I will continue in the next lecture, because they deserve to have their own lecture. The next lecture will consist of so called response challenges, which will include these remaining items. Those response challenges help us to mitigate ongoing SYN floods without blocking the legitimate users.