correlation between ingress and egress traffic in case of volume-based DDoS
Hi, volume-based DDoS attacks should often result with following bandwidth graphs: http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png This is a fabricated bps graph for 100GigE port facing an uplink provider. As seen on the image, outgoing traffic drops at the time when incoming traffic increases. I could see following reasons for this: 1) large portion of traffic uses TCP protocol and in case of congestion(even in one direction), ACK messages are lost and TCP congestion avoidance kicks in and as a result it will reduce the cwnd which in effect reduce the data TCP sender can send 2) certain router platforms share some hardware resources both with Tx and Rx traffic Are those assumptions correct? Are there any other reasons which cause outgoing traffic to drop if incoming traffic is very high or the other way around? thanks, Martin
On 23 Sep 2015, at 23:07, Martin T wrote:
Are there any other reasons which cause outgoing traffic to drop if incoming traffic is very high
Lots. It's very situationally-specific. The attack traffic may not be crafted in such a way so as to elicit a response from the targeted host(s). The relevant network links/paths could be filled, with attack traffic 'crowding out' legitimate traffic. The hosts could be pummeled with attack traffic and be so busy trying to deal with it at either the NIC level or the network stack level or the kernel level or the app/service level that it can't respond. The relevant network infrastructure could be down due to the attack traffic, for various reasons (software-based platform overloaded, traffic punted to RP, etc.). The hosts could be sitting behind a stateful firewall or load-balancer or 'IPS' which has gone down under the onslaught. And so forth. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Wed, Sep 23, 2015 at 12:07 PM, Martin T <m4rtntns@gmail.com> wrote:
volume-based DDoS attacks should often result with following bandwidth graphs:
http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png
This is a fabricated bps graph for 100GigE port facing an uplink provider. As seen on the image, outgoing traffic drops at the time when incoming traffic increases.
Are those assumptions correct? Are there any other reasons which cause outgoing traffic to drop if incoming traffic is very high or the other way around?
Hi Martin, I don't have much to add to what Roland said. The whole point of a volume-based denial of service attack is to overwhelm your target's infrastructure with fake traffic so that it is unable to handle real traffic. In a successful attack, the real traffic will drop off to almost nothing, having been crowded out. Depending on the details, this may or may not show up in a traffic graph. If the fake traffic induces return traffic, you'll see the return traffic spike as well. If the fake traffic all gets dropped somewhere within the infrastructure, you'll see return traffic plummet as you did in the graph you linked. Both cases can happen depending on the exact details of the attack. An aside - ack loss doesn't hurt TCP terribly much since the next ack also covers the previous one. TCP tends to stall when 2% to 5% of the payload packets are lost. Bear in mind that payload moves both ways. Even an http request contains a large request header. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
hi martin On 09/23/15 at 07:07pm, Martin T wrote:
volume-based DDoS attacks should often result with following bandwidth graphs:
http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png
This is a fabricated bps graph for 100GigE port facing an uplink
when you say "fabricated" ... what do you mean ?? - if its actual ( real ) .. than okay for the reasoning - if its "fabricated" ( sanitized, made up, theory ), than still okay for reasoning as roland says, there's dozens of reasons to explain the results one sees in graphs .... graphs are always subject to different interpretation depending on different circumstances
provider. As seen on the image, outgoing traffic drops at the time when incoming traffic increases. I could see following reasons for this:
1) large portion of traffic uses TCP protocol and in case of
in my case, the way i would simulate a tcp-based DDoS attack against a test victim, outgoing traffic should remain steady state per the normal tcp traffic ... and tarpit the ddos attacks from the victim under the volumetric tcp-based attacks setup the ingress filters for tarpits the attacking zombie should run out of kernel memory and crash if it tries to sustain huge amt of volumetric tcp-based ddos attacks without tarpits, all kinds of whacky network stuff will occur depending on how the tcp-based ddos attacks are lauached if its an icmp-based ddos attack, the outgoing traffic may be 10x or 100x more traffic than incoming icmp-based ddos attack if the server was not hardened to protect itself from icmp-based attacks if it was hardened, limit outgoing reply to incoming icmp-attacks, than it outgoing reply should be constant due to normal remaining traffic, but incoming icmp attacks can be 10x or 100x or 1000x normal similarly, if its an udp-based ddos attack, the outgoing traffic may be 10x or 100x more than the incoming traffic if dns,ntp,snmp, x11,nfs,etc was not hardened to protect itself from udp-based attacks if it was hardened, limit outgoing reply to incoming udp-attacks, than it outgoing reply should be constant due to normal remaining traffic, but incoming udp attacks can be 10x or 100x or 1000x normal if its an arp-based ddos attack, outgoing traffic may generate the same amt of traffic going out as whats coming in .. hopefully, you have bought good switches that don't fail-over into hub-mode launching those volumetric attacks takes a few minutes to figure out what options to use to create certain type of ddos attacks - nc, socat, iperf, etc - ping, nping, hping, etc - hundreds of other apps
congestion(even in one direction), ACK messages are lost and TCP congestion avoidance kicks in and as a result it will reduce the cwnd which in effect reduce the data TCP sender can send
syn-cookies doesnt kick in until all tcp stack is exhausted and syn-cookies tries to service all incoming tcp requests probably a bad thing to attempt to do while under tcp-based ddos attacks fiddling with send and receive buffers and delays and timeout would add more fun to the problem and resulting bandwidth graphs
2) certain router platforms share some hardware resources both with Tx and Rx traffic
Are those assumptions correct? Are there any other reasons which cause outgoing traffic to drop if incoming traffic is very high or the other way around?
in the subject, you used "ingress and egress" filters ... those rules would also definitively affect the resulting bandwidth graphs if you're in the cloud ... all these thingies still apply to the guest OS and especially the host OS magic pixie dust alvin # # DDoS-Mitigator.com # DDoS-Simulator.net #
participants (4)
-
alvin nanog -
Martin T -
Roland Dobbins -
William Herrin