Today, I first played a syn-flood attack.

When tcp_syncookies are not used by default in Linux, they are very useful.
Hgod 192.168.37.188 21
The results will be immediately displayed. The vsftpd on the machine is down, but if a user has logged on to FTP, the user will not be affected, I think it may be because it has already arrived at established ..., however, when I log on to the FTP again, I find that I cannot log on. It seems that it is indeed effective...
Of course, tcp_syncookies are not used.
Echo "1">/proc/sys/NET/IPv4/tcp_syncookies. I rely on them to see the results immediately...
So I can log on. It seems that syncookie is still useful...
You can take a look at it... the download of dsniff won't work. It's really depressing ....
Libpcap. so.0 is required. I don't know what it is. I already have Libpcap. So and Libnet ....
Let's take a look at arpspoof and try again later. Add hping2 ICMP redirection and fragrouter for forwarding. However, forwarding can be done by default ....

And recently played ARP proxy.

If you have any questions, do not understand:
1. Why can't I use sycookie?
Netstat-Na | grep "syn_recv" | WC-l
There are 193 connections and a maximum of 193 connections. Is the backlog 193? This is not the case...
CAT/proc/sys/NET/IPv4/tcp_max_syn_backlog
It seems to be 256,

After syncookie is used
Netstat-Na | grep "syn_recv" | WC-l
It's 256 connections. It's in the beginning, huh, huh...
After syncookie is used, the backlog queue is full...

2
After syncookie is used, is the backlog queue full by default and the new SYN requests are not stored in the backlog? Should this still be filled with flood, and the new normal SYN cannot be accessed? Although the system can process SYN requests when the backlog is full, the host performance will still decline if there are too many requests... it's not an absolute solution ....