when a client sends 10 TCP SYN packets by hping3(not spoofing), server responds and sends 10 TCP SYN+ACK packets. now client should answer to server and Establish the connection by sending 10 ACK packets, but client sends 10 RST and terminates the half-open connections(i guess that's because linux kernel responds).
how can i send 10 SYN packets per second (to the same destination with different source ports ) and in response of SYN+ACKs, send ACK and establish the connections? thanks very much
You cannot craft packets in user space outside of the native TCP/IP stack and expect the Kernel to accept unsolicited SYN/ACK packets in response. The Kernel is right to RST the packets as per RFC standard. I'm doubtful that hping3 will be able to achieve what you are looking for.
If you are comfortable with Python, you can look into Scapy which will allow you to send and receive packets in user space. Here's a simple example of creating a three-way-handshake in Scapy.
hping3 is typically used as an attacking tool that attempts to break the normal way of doing things-in the described case the 3 way handshake- in order to inflict damage to the destination.
Having a tool to a establish a flood of TCP connections would probably be classified as a stress-testing tool rather than an attacking tool.
-S which is the most popular option of hping3 refers to SYN flooding attack and I will take a guess that this is what you used. In this mode hping3 sends a myriad of SYN messages but intentionally refrains from sending the last message of the 3-way handshake. The connections are left "half-open" and the victim has already committed a ton of resources (in theory) for the totality of these connections.
In your case the attacking machine's kernel is issuing the RST messages almost immediately preventing the attack to complete. The reasons for this are mentioned by @MarkoPolo. If the attack would work, you should actually expect to see several retransmission attempts of the SYN-ACK message from the victim corresponding to each SYN.
If your plan is actually to successfully execute the attack then I suggest you enter a firewall rule to effectively drop your outgoing RST messages.
iptables –A OUTPUT –p tcp –s 192.168.56.101 --tcp-flags RST RST –j DROP
