bonesi is not completing tcp 3-way handshake

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I'm running bonesi using the following command in my lab setup:

# bonesi -i russkill2_bots.txt -p tcp -r 1 -o bonesi_stats_33_0.txt -c 1 -b 
russkill2_user-agents1.txt -d eth1 -v 3.0.21.12:80

I have one client:
# cat russkill2_bots.txt 
3.0.21.6

and there are 111 different user-agent values in russkill2_user-agents1.txt

bonesi is sending a SYN and receives SYN/ACK from the victim server 
(3.0.12:12). what happens next is strange. bonesi is sending a RST soon after 
it receives SYN/ACK (and before sending the final ACK):

3.0.21.6:34270 sends SYN to 3.0.21.12:80
3.0.21.12:80 sends SYN, ACK
3.0.21.6:34270 sends RST
3.0.21.6:34270 sends ACK

Because of the RST, the victim server also responds with a RST. Hence the 
server doesn't even get a chance to respond to HTTP flood. 

What is the expected output? What do you see instead?

I expect that benesi send an ACK to complete the handshake (in packet #3) and 
not RST. 


What version of the product are you using? On what operating system?
bonesi-0.1.1; 

OS: CentOS release 5.3 (Final)

# uname -rv
2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:39:21 EDT 2009

Any clue greatly appreciated!

Please provide any additional information below.

Original issue reported on code.google.com by keshavap...@gmail.com on 3 Mar 2011 at 9:38

[GoogleCodeExporter]

Hello,

sorry for coming back to you so late.

After all, I could reproduce your behavior. It looks like it is a problem, if 
the IP address you are spoofing is in fact the IP address of the system. In 
this case, the OS gets the packet (instead of bonesi), tries to process it and 
returns an RST because it is not expected (the OS did not send the SYN). 

To overcome this problem, put a different IP in your russkill2_bots.txt file, 
e.g. 3.0.21.7. and make sure the server routes this address back to 3.0.21.6 ( 
e.g. by setting the default GW).

Then, everything works as expected.

Please note, that bonesi was designed to use hundreds or even thousands of 
spoofed addresses in order to test a DDoS remediation device very practically. 
In the case you only want to use a single IP source address, there might be 
better tools for you, e.g. "ab", the Apache HTTP server benchmarking tool.

Original comment by Markus-Go on 5 Sep 2011 at 5:33

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Sorry for the late response. It worked after I made the changes that you 
suggested. Thanks!
The packet rates that I'm seeing are great. TCP traffic from 1 bot is about 5.5 
Mbps, 7.8 Kpps; From 10 bots, it is  about 17 Mbps and 31 Kpps on an Intel 
TSRMT2 running centos. Fantastic and great work!

Thanks again.

Original comment by keshavap...@gmail.com on 8 Dec 2011 at 7:23

[Markus-Go]

Original comment by Markus-Go on 13 Dec 2011 at 4:37

• Changed state: Done