DDoS Countermeasures

Reaction, once it is noticed

Blackholing deserves the plain sentence RFC 5635 gives it. Destination-based filtering "injects a discard route ... All packets towards that destination, attack traffic AND legitimate traffic, are then dropped", so that "the impact of the attack on the target is complete". It is used because it protects the provider's other customers. For the victim it is the attacker's own goal, achieved efficiently.

The run: what each answer does to the good traffic

The listing takes a college with a 1 Gbit/s connection, 200 Mbit/s of genuine traffic and a 5 Gbit/s flood, and computes how much of the genuine traffic arrives under each response. A congested link cannot tell which packet matters, so each kind gets its share of the room.

# What each answer to a flood actually does to the traffic that matters: the good traffic.
# A link carries what it carries; the question is who gets the room. Nothing is sent anywhere.

LINK = 1_000_000_000          # the college's connection to its provider, 1 Gbit/s
GOOD = 200_000_000            # genuine traffic wanting to arrive, 200 Mbit/s
ATTACK = 5_000_000_000        # the flood aimed at it, 5 Gbit/s

def through(link, good, attack):
    """A congested link has no idea which packet matters: each kind gets its share."""
    offered = good + attack
    if offered <= link:
        return good, attack
    return link * good / offered, link * attack / offered

def report(name, good_in, attack_in, link=LINK, note=''):
    good_out, attack_out = through(link, good_in, attack_in)
    print('   %-31s %7.1f %8.1f %7.1f%%  %s'
          % (name, good_out / 1e6, attack_out / 1e6, 100 * good_out / GOOD, note))

print('A 1 Gbit/s LINK, 200 Mbit/s OF GENUINE TRAFFIC, A 5 Gbit/s FLOOD')
print('   %-31s %7s %8s %8s' % ('what is done', 'good', 'attack', 'of the'))
print('   %-31s %7s %8s %8s' % ('', 'Mbit/s', 'Mbit/s', 'good'))
report('nothing', GOOD, ATTACK)
report('a firewall at our own end', GOOD, ATTACK, note='drops it AFTER the link')
report('the provider blackholes us', 0, 0, note='we go offline')

# filtering upstream by source: p of the attack recognised, q of the good wrongly dropped
for p, q in ((0.90, 0.02), (0.99, 0.02), (0.99, 0.20)):
    report('provider filters %d%%, %d%% false' % (p * 100, q * 100),
           GOOD * (1 - q), ATTACK * (1 - p))

# scrubbing: everything is diverted through a centre with capacity to spare
for p, q in ((0.99, 0.02), (0.999, 0.01)):
    good_out = GOOD * (1 - q)
    attack_out = ATTACK * (1 - p)
    report('scrubbing centre, %.1f%% removed' % (p * 100), good_out, attack_out,
           link=10 * LINK, note='diverted and returned')

print()
print('READ THE SECOND LINE AGAIN: our own firewall changes nothing for the link,')
print('because the packets have already crossed it. Only the provider, upstream,')
print('can give the room back. Blackholing gives it back to everyone except us.')

# ---- and the attacks that do NOT fill the link ------------------------------------------------
print()
print('THE OTHER KIND: WHEN THE LINK IS NOT THE PROBLEM')
BACKLOG, TIMEOUT = 128, 120
link_packets = LINK / (54 * 8)
print('   a backlog of %d held %d s is kept full by %.1f packets a second'
      % (BACKLOG, TIMEOUT, BACKLOG / TIMEOUT))
print('   the link carries about %s packets a second, so the flood is %.7f of it'
      % (format(round(link_packets), ','), (BACKLOG / TIMEOUT) / link_packets))
print('   buying a bigger link does nothing, because the link was never the problem')
print('   with SYN cookies the server keeps no state until the handshake finishes,')
print('   so there is no table left to fill')

What the run establishes, in order.

With nothing done, four fifths of the genuine traffic is lost. The link carries 1 Gbit/s of the 5.2 Gbit/s offered, so only about 38 Mbit/s of the 200 Mbit/s wanted gets through: 19 per cent.

A firewall at your own end changes nothing about that. It reads the same 19 per cent, because the packets it drops have already crossed the link and used the room. This is the single most important practical fact in the chapter: against a link-filling attack, local equipment cannot help, however good it is. It protects the server behind it, not the road to it.

Blackholing is a complete outage that you asked for. The table shows 0.0 Mbit/s of genuine traffic, which is what RFC 5635 warns.

Filtering upstream is what actually works, and its false alarms are the whole design question. At 90 per cent of the attack removed the link is no longer full, and 98 per cent of genuine traffic arrives; pushing the attack removal from 90 to 99 per cent changes nothing for the good traffic, because the link already had room. But raising the false-alarm rate from 2 per cent to 20 per cent costs 18 points of genuine traffic. Beyond the point where the link stops being full, accuracy about genuine traffic matters more than accuracy about attack traffic.

The resource attacks are a different problem entirely. A SYN flood that keeps a 128-entry backlog full needs about one packet a second, against a link that carries some 2.3 million; buying more bandwidth is spending money on the wrong thing, and SYN cookies cost nothing.

What a small site can actually do

In order, and before anything happens:

1. Know your provider's process. Who to call, what they can filter, whether they offer blackholing or scrubbing, and how long it takes. This is the only step that helps against a link-filling flood, and it cannot be arranged during one.
2. Put something large in front, if the service matters: a content delivery network or hosted front end absorbs floods as part of its ordinary work.
3. Turn on the cheap server defences: SYN cookies, connection limits per address, timeouts, and rate limits on expensive pages such as search and login.
4. Do not be an amplifier. Close open DNS resolvers, NTP monitor commands, SNMP and anything else listening on UDP that need not be public.
5. Apply ingress filtering on your own edge so that your machines cannot forge addresses.
6. Record what normal looks like, so that an alarm means something.
7. Write the plan down and name who decides, including who may accept a blackhole.
8. Report. In India CERT-In's 2022 directions list denial of service and distributed denial of service among the incidents that must be reported within six hours.

Distinctions that carry marks

What beginners get wrong here

Recommending a firewall against a bandwidth flood. It sits behind the link the attack has already filled.

Thinking a bigger link solves it. It raises the attacker's bill a little; against an amplified attack their bill is divided by hundreds.

Calling blackholing a defence without saying what it costs. It completes the outage for the target on purpose.

Optimising the wrong error. Once the attack is below the link's capacity, what matters is how little genuine traffic the filter discards.

Forgetting the other kind of attack. SYN floods and request floods need almost no bandwidth, and are answered by SYN cookies, limits and timeouts.

Quick revision

• Three classes: prevention and pre-emption, detection and filtering, traceback and identification, with reaction as the response.
• Prevention: BCP 38 ingress filtering, closing reflectors (RFC 5358), patching, capacity, SYN cookies.
• Filtering works only upstream: a local firewall cannot recover a link that is already full.
• Blackholing (RFC 3882, RFC 5635): the provider discards all traffic to the address; "the impact of the attack on the target is complete".
• Scrubbing: divert, clean, return.
• Run: nothing 19% of good traffic; local firewall 19%; blackhole 0%; upstream filter at 90% with 2% false alarms 98%; the same filter with 20% false alarms 80%.
• A small site: know the provider's process, get something large in front, turn on server defences, do not be an amplifier, filter your own egress, know normal, write the plan, report within six hours.

Test yourself

1. Classify the countermeasures against distributed denial of service. They fall into attack prevention and pre-emption, before the attack, which includes ingress filtering of forged source addresses, closing services that can act as reflectors, patching machines so they do not become bots, removing the resources attacks target such as by using SYN cookies, and providing capacity; attack detection and filtering, during the attack, which means recognising attack traffic and discarding it as early and as near its source as possible; and attack source traceback and identification, during and after, which attempts to find where traffic really came from despite forged addresses. The victim's own response, from rate limiting to blackholing or scrubbing, is the reaction these support.

2. Why can a firewall at the victim's premises not defend against a bandwidth-filling flood? Because the attack consumes the access link before it reaches the firewall. A congested link carries only its capacity and has no way to prefer genuine packets, so genuine traffic is already lost in proportion; dropping the attack packets after they have crossed the link recovers nothing. In the worked example, a 5 Gbit/s flood against a 1 Gbit/s link leaves about 19 per cent of the genuine traffic arriving, whether or not there is a firewall. Only action upstream, by the provider, can return the room.

3. What is remote triggered black hole filtering, and what does it cost? It is a technique in which the victim asks its provider, usually by a routing announcement, to install a discard route for the attacked address, so that routers in the provider's network drop all packets towards it. It is fast and cheap and protects the provider's other customers and the rest of the network from the flood. Its cost falls entirely on the victim: as RFC 5635 states, attack traffic and legitimate traffic alike are dropped, taking the target completely offline, which is what the attacker wanted.

4. Why is a false alarm rate more important than a detection rate once filtering is in place? Because as soon as enough of the attack is removed for the link to have spare capacity, removing more of it gains nothing, while every percentage point of genuine traffic wrongly discarded is a direct loss of service. In the worked example, raising attack removal from 90 to 99 per cent left the genuine traffic unchanged at 98 per cent, while raising the false alarm rate from 2 to 20 per cent cut it to 80 per cent: the filter would then be doing part of the attacker's work.

5. What should a college do in advance to be ready for a denial of service attack? Agree with its provider, before anything happens, who to contact and what filtering, blackholing or scrubbing is available and how quickly; put a content delivery network or hosted front end in front of services that matter; enable the inexpensive server defences, SYN cookies, per-address connection limits, timeouts and rate limits on expensive pages; close any service that could make it an amplifier, such as an open DNS resolver; apply ingress filtering at its own edge so its machines cannot forge addresses; record what normal traffic looks like so that alarms are meaningful; write down who decides what, including who may accept being blackholed; and be ready to report the incident to CERT-In within six hours as the 2022 directions require.