correlation between ingress and egress traffic in case of volume-based DDoS

Mailman List Mirror (Read Only)
1

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

2

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.

3

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

4

hi martin

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