-1

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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Elvin
  • 113
  • 1
  • 1
  • 4
  • 1
    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 02 '18 at 10:03

3 Answers3

3

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.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
  • is it possible to DoS an apache2 server by using hping3 ?And how should curl command look like? – Elvin May 05 '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 05 '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 05 '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 05 '18 at 13:19
1

1) if your source machine have an IP as 192.168.100.1 and you spoof your source IP to 192.168.100.88, then the local tcp/ip stack discards the packet because you are not what you claim to be. (meaning you IP is 192.168.100.1 and you are spoofing as .88, so in this case the NIC drops your packets and that's the reason you don't have any packet capture at all).

2) for this to work you need to disable source/dest check on your VM. (for example in AWS you can go to instance -> Networking -> Disable Source/Destination Check and you will be able to generate traffic with spoofed IP.)

3) Since it's spoofed IP, you won't get the replies back to you. Instead the replies go to the spoofed IP.

4) today 02/02/2020, I exactly repeated your test and I'm able to generate traffic with spoofed IP, only after I disable source/dest check.

Laxmana Polisetti
  • 11
  • 1
-4

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
camp0
  • 2,172
  • 1
  • 10
  • 10
  • 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 02 '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 02 '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 02 '18 at 19:05
  • But there was a packet capture ... – schroeder May 02 '18 at 19:28
  • 2
    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 02 '18 at 19:32