The piece of C codes below is suppose to perform a SYN FLOOD attack to bug down a server at the other end . I am only familiar with elementary programming in C will rely on those among us who are familiar with advance programming in C to make their observations and correlate the codes with the explanation below.
Host C (for Client) sends a SYN packet to host S (for Server) to request a connection, with a spoofed source IP address. Host S then replies to this packet, with a SYN|ACK packet, replying to the spoofed address. The connection request is then placed on the stack until a final ACK is received. But since the source address of the SYN packet was spoofed, the Host S (the server) will never receive an ACK packet, because the host who it sent a SYN|ACK packet to doesn't even exist, so the connection requests stay on the stack! And in a SYN flooding attack, an attacker sends literally hundreds if not thousands of packets a minute, so with all of these thousands of unanswered connection requests sitting on the stack, Host S could be brought to it's knees as it's resources are starved and it's process table is saturated. On some platforms, the machine can be brought to almost a total lockup, and the CPU utilization can be raised dramatically to 100%.
This has become a very popular and effective DoS attack, as it is a pretty easy DoS attack to launch with pre-built tools, and requires minimal knowledge of the victim host.
Thanks for the nice explanation sose. I got curious about this. So I compiled the code on a linux (Suse based) VMware machine and attacked my oldest tyrannosaurus home computer. Note here that this is a very slow 450Mhz PIII with 256Mb on it, WinXP. Here are the results in brief:
1. CPU usage on the victim did rise to 70%-80% but never caused the machine to hang or stop working. CPU usage dropped to normal again once the attack was stoped.
2. Sniffing the attack shows the following:
The attacker is 192.168.0.3 and the victim is 192.168.0.1.
Unfortunately, If I understand it well, it seems from this that the code did not perform the attack correctly. the SYN as you can see is equal to 0 (in all packets). Although surprisingly, I can see the line tcp->syn = 1; :!:. The other thing is that the source address is the linux machine it self, not random!!.
Now lets see the man in the middle attack(sequence number prediction)/tcp session hijacking
This is the ultimate attack in IP spoofing, to gain a connection with a host, pretending to be another host, preferably a trusted host. All that is required is that the attacker can predict the sequence number of the server host's SYN|ACK packet after sending a SYN packet, but this is not as simple task as somebody might think. First, there's the issue of actually guessing the sequence number of this packet of interest, and secondly, there's the issue of the host you are spoofing of answering to the SYN|ACK packet, and sending a RST (reset connection) packet because it was not expecting the SYN|ACK packet. The second problem is actually simpler to deal with. A classic method of preventing the spoofed host from replying to the SYN|ACK packet with a RST is by SYN flooding it
Solo please can you kindly detail your attacks setup using these codes
like number of system, OS, modus oprendi etc
Sure, Two PCs A and B connected to a small 8 ports switch. Both having windows XP. PC A (with VMware installed) is running a virtual PC having linux (Suse 10.x). I compiled the code on the linux VM using Eclipse IDE + CDT. Then ran the attack on the linux targeting PC B (B is the victim). While doing so, a sniffer (Commview) installed on PC A is sniffing it's NIC that connects the switch. The results above is the output of the sniffer.
Offcourse, the linux VM is using PC A's NIC to connect to the network.