1

I've been trying to test our software against DOS attacks. So, I used 'HPing3' but it just fills up 10-11M of my interface's bandwidth! I ran the tool 40 times, I mean 40 hping3 processes, unfortunately nothing changed in my interface's bandwidth!

Well, my question is: How should I fill up my interfaces bandwidth for DOS attacks simulation?

@camp0 here is the result of ethtool:

# ethtool enp3s0
Settings for enp3s0:
    Supported ports: [ TP MII ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Half 1000baseT/Full 
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Full 
    Advertised pause frame use: Symmetric Receive-only
    Advertised auto-negotiation: Yes
    Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                         100baseT/Half 100baseT/Full 
                                         1000baseT/Half 1000baseT/Full 
    Link partner advertised pause frame use: Symmetric Receive-only
    Link partner advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: pumbg
    Wake-on: g
    Current message level: 0x00000033 (51)
                   drv probe ifdown ifup
    Link detected: yes
  • HI, probably your interface don't support more than 10M or your CPU is not enought, however it would be a good idea if you could provide us the information of your network card (ethtool and ifconfig in linux) – camp0 Jan 19 '19 at 14:27
  • There's probably a better tool to use for this job; perhaps specifically tailored to DoS testing. – multithr3at3d Jan 19 '19 at 15:29
  • Also you need to consider that if you are sending the traffic over internet you have chances that been filtered by intermediate systems. – camp0 Feb 14 at 10:07
0

try putting your hping3 machine on the same network fabric, literally the same switch as the box you are testing. This takes any issues with multiple hops and routing out of the equation.

| improve this answer | |
  • I did it before, but nothing changed. also I used the --fast switch and again the same result. – N00000000000000000p Jan 20 '19 at 7:33
  • i mean --flood – N00000000000000000p Jan 20 '19 at 7:44
0

You don't need hping3 to fill your gigabit pipe: the standard ping utility in my Debian creates about 1.3GiB/s when using the flood and data size options. CPU seems to be spent on creating the packets and so at 100% CPU, the only thing you can do is create larger packets rather than more packets.

hping3 with the exact same arguments (flood and largest possible packet size) gets me 2.1GiB/s. The default protocol there is TCP; in ICMP mode, it goes even further at 3.3GiB/s. When not pinging localhost, the MTU will be an issue, but with the largest possible packets and fastest possible setting, that's all you're going to get out of hping3 (well, that and running it in parallel like you already do).

Note that the easiest way to bring a website down is almost never to fill up the pipe with raw data. Find an HTTP request that takes a few hundred milliseconds (search queries, login requests sometimes, that sort of thing) and flood that. Since you can re-use TCP/TLS connections, you only have to worry about the actual request, so let's say 250 bytes. On a slow home internet connection of, let's say, 10mbps upload, you can do that request 40 thousand times per second (10e6/250=40k). Given that each request takes a few hundred milliseconds, let's say 250 (¼s) to make things easy, the site would need ten thousand CPU cores to keep up with that (40k*¼=10k), assuming that CPU is the internal bottleneck. Or even more efficient: send 1000 requests in parallel (making sure that the thousandth request is sent before the first one is done processing), once, and at least for smaller sites odds are that the site does not recover on its own.

This is a bit outside the scope of this question's title, but in the body you mentioned that denial of service attack simulation is your real goal, so this is how I would go about that (it works for a significant portion of our clients: DDoS is out of scope but a search query that takes 2 seconds makes this child-play and so we mention it as a risk).

| improve this answer | |

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.