-2

I was trying to perform a SYN flood attack, and I was using hping3. This is how the command looks like :

 sudo hping3 -S -a 192.168.100.88 --flood -p 80 192.168.100.15

Where 192.168.100.88 is a non-existing IP address. The attacked server should answer back and make half-opened connections.

As a result I've got this :

    elvin@elvin-VPCZ21X9R:~$ sudo hping3 -S -a 192.168.100.88 --flood -p 80 192.168.100.15
HPING 192.168.100.15 (wlp2s0 192.168.100.15): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
--- 192.168.100.15 hping statistic ---
22082825 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

What is this: 100% packet lost? What does that mean?

Then I opened up Wireshark and didn't see any traffic which looked like a flood.

Had I performed the SYN-flood? Or did that not work?

Also I've pinged the IP address while sending packages by using this command

ping 192.168.100.15

Is it right to check by this command the status of the apache2 server?

  • Few questions: 1) "the server should answer back" - to whom? Your attacking machine? You do see how that is impossible? 2) 100% packet loss means that nothing came back to your machine, but see #1 3) Did you see any traffic to the target on Wireshark, flood or no? 4) You say that you pinged the server, but what was the response? – schroeder May 2 '18 at 10:03
2

First off, if you spoof a source IP address, you will not get answers from the destination as the SYN/ACK packets go to the spoofed address.

Other than that, if wireshark doesn’t show appropriate outgoing traffic, assuming you used it correctly, there are a few possible reasons:

  • your IP stack might filter spoofed packets,
  • your local packet filter might drop packets with a SRC that is not your actual address.

Additionally, a ping on the destination machine is not what will give you accurate results on the status of the TCP stack of the target (and a web server has nothing to do with this at all).

See, when you syn-flood, your goal is to have so many half-open connections that the OS TCP stack doesn’t allow new connections to be made.

Only on full connections you aim for the program handling the connections (in this case it seems like an apache) exhausts either memory, file handles or cpu.

Only in the latter case you can hope for the memory or cpu exhaustion to keep the OS from responding to pings - and that not even reliably. Additionally, Apache doesn’t spin of processes like crazy, even on full connections, the maximum process count will probably be reached before exhaustion of resources is a problem.

So, to check if your attack has any impact on the availability of the attacked web server, you should rather curl than ping to have a full request be made - if that connection times out, your attack works.

  • is it possible to DoS an apache2 server by using hping3 ?And how should curl command look like? – Elvin May 5 '18 at 12:53
  • Wether the Apache gets DoS’d by a syn flood depends on the servers resources, configuration and operating system. Probably not, on modern values for each. As for the curl command, please refer to curl -h. – Tobi Nary May 5 '18 at 12:56
  • ,I mean , how does curl can help me looking after server's service as the way as ping does – Elvin May 5 '18 at 13:11
  • OP, I really do not know what I should add to the last paragraph of my answer. Side note: you should probably learn some basics before trying to DoS. – Tobi Nary May 5 '18 at 13:19
-3

I think you should check your routing tables of the server and the host. You are using the option -a

-a --spoof hostname
          Use this option in order to set a fake IP source address, this option ensures that target will not gain your real address. However  replies  will  be  sent  to
          spoofed address, so you will can't see them. In order to see how it's possible to perform spoofed/idle scanning see the HPING3-HOWTO.

This means that if your source machine have an IP as 192.168.100.1 and you change your source IP to 192.168.100.88, the server will respond to 192.168.100.88, not to 192.168.100.1. Also it would be a good idea to pcap the traffic on the server side to see this effect.

  • The OP said that Wireshark did not display anything, so I'm not sure that getting packet captures on the server side is the first step ... – schroeder May 2 '18 at 11:56
  • You are also assuming that the goal is for the traffic to return to the attacking machine. This is not obvious from the question. In addition, you do not really explain the purpose of checking the routing tables. – schroeder May 2 '18 at 11:57
  • Im not assuming anything, the packets should be on some place, and by checking the routing table at least you know where the out packets goes, on the other and on the server side happens a similar effect. Is true that the question dont have all the information needed, IPs, network topology and so on, so with the given information I have the suspicious that or the server have filter the packets or route to other place, Is always good to have the pcap files, no pcap no diagnostic :) – camp0 May 2 '18 at 19:05
  • But there was a packet capture ... – schroeder May 2 '18 at 19:28
  • 1
    The problem here is that you are not explaining your answer and your answer seems to ignore details in the question. This is a common problem with your answers and is why you get downvoted so much. I think you have some good answers deep in the subtext of your answers, but they are overshadowed by errors and misunderstandings. – schroeder May 2 '18 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.