Volumetric Attacks and Amplification

Amplification in general

The general pattern, of which Smurf is one instance:

1. Find a service that answers a small request with a large reply, and that runs over a protocol where the source address is not verified (so the reply can be sent to a forged address). Connectionless protocols like UDP fit, because there is no handshake to prove the requester's address.
2. Send many such small requests, each with the victim's address forged as the source.
3. The services send their large replies to the victim, who is flooded by traffic they never requested, from services that are not the attacker.

The measure of an amplifier is its amplification factor: the ratio of reply size to request size. A service that answers a tiny request with a reply dozens or hundreds of times larger multiplies the attacker's bandwidth by that factor, so a modest attacker generates a huge attack.

The services abused this way are ordinary infrastructure misconfigured to answer strangers: certain DNS resolvers (a small query, a large response, which is why the DNS-hardening chapter said an open resolver harms third parties), NTP servers with the monitoring command enabled (the enumeration chapter's finding, a short request yielding a long client list), and various others such as SSDP on consumer devices. In every case the abused service is not the attacker's and not the victim's; it is an innocent third party whose misconfiguration lets it be used as a reflector and amplifier.

This is a category of harm the earlier chapters kept flagging: a service exposed to strangers can be turned against someone else. The organisation running an open resolver or an NTP server with monitoring enabled suffers no direct harm, which is exactly why they leave it open, and it becomes a weapon against a third party.

The root cause and the control that removes it

Amplification, and spoofed floods generally, depend on source-address spoofing: the attacker must be able to send packets claiming to come from the victim. Remove that ability and the whole technique collapses, because the replies would go back to the attacker, not the victim.

The control is anti-spoofing filtering, also called ingress and egress filtering (the practice referenced in the NTP chapter):

• Egress filtering by a network operator drops outbound packets whose source address does not belong to that network. If every network did this, no attacker could send a packet forging a victim's address, because their own network would drop it at the door.
• Ingress filtering drops inbound packets that claim to come from inside the network but arrive from outside.

Anti-spoofing is the single control that would starve amplification attacks at their source, and it is a long-standing recommendation. Its weakness is that it must be deployed by the operators of the networks the spoofed traffic leaves, who are not themselves the victims, so there is a collective-action problem: the network that could stop it is not the one that suffers. This is the same shape as the open-reflector problem, and it is why these attacks persist despite a known fix: the fix depends on parties other than the victim acting.

The complementary controls, for the operators of potential amplifiers, are the enumeration and DNS chapters' recommendations: do not run an open resolver, disable the NTP monitoring command, restrict services to the sources that need them, and rate-limit responses, so that even if spoofing occurs your service is not the amplifier.

Mitigating volumetric attacks as a victim

Since a victim cannot fix other people's spoofing or reflectors, their defences are about capacity and absorption, developed fully in the mitigation chapter:

• Upstream scrubbing: a provider with vast capacity absorbs and filters the flood before it reaches the victim's connection. For a large volumetric attack this is the only practical defence, because the victim's own connection is the thing being overwhelmed.
• Capacity and distribution: enough bandwidth, and services spread across many locations (anycast) so the attack is divided among them.
• Filtering the obvious: a scrubbing service can drop traffic that is clearly part of an amplification attack, for example large DNS or NTP responses to a host that never sent the queries.

A worked example, framed defensively

An assessor reviews an organisation's exposure both as a potential victim and as a potential unwitting amplifier.

• As a victim: the organisation has no upstream scrubbing arrangement, so a large volumetric attack would saturate its connection with no recourse. Finding: no volumetric mitigation; arrange upstream scrubbing in advance.
• As an amplifier: the organisation runs a DNS resolver open to the internet and an NTP server with the monitoring command enabled. Findings: both can be used to amplify attacks against third parties. These are harms to others, which the organisation has no direct incentive to fix, which is precisely why an assessment must flag them.
• The organisation's own network does not perform egress filtering, so a compromised device inside it could send spoofed traffic. Finding: enable anti-spoofing egress filtering, which prevents the organisation's network being used to launch spoofed attacks.

Recommendations: arrange upstream scrubbing (victim defence); close the open resolver and disable NTP monitoring (stop being an amplifier); and enable egress filtering (stop being a launch point). The report makes explicit that two of the three findings protect other people, a category organisations habitually neglect and an assessment should not.

What beginners get wrong

• Thinking a volumetric attack exploits the server. It saturates the connection; the server is never reached. Nothing on the server can help.
• Believing Smurf still works. The specific attack is dead (broadcast pings are no longer forwarded), but the amplification principle it teaches is alive in DNS, NTP and other reflectors.
• Missing that the amplifier is a third party. The abused service is neither the attacker's nor the victim's; it is an innocent, misconfigured party used as a reflector.
• Overlooking that you might be the amplifier. An open resolver or an NTP server with monitoring enabled harms others, which is why it is left open and why it must be flagged.
• Forgetting the root cause. Amplification depends on source-address spoofing; anti-spoofing (ingress/egress) filtering would starve it, but must be deployed by the networks the spoofed traffic leaves.
• Expecting the victim to fix spoofing. They cannot; their defences are capacity and upstream scrubbing.

Quick revision

• Volumetric attacks fill the target's connection with sheer traffic; the server is never reached, so its own defences are irrelevant. They require generating more traffic than the victim can receive, hence distributed and often amplified.
• Smurf is the teaching case (now dead): a small ping to a broadcast address with the victim's source spoofed, so every host replies to the victim. Amplification.
• General amplification: small requests with the victim's forged source to a service that answers with a large reply, over an unverified protocol (often UDP); the amplification factor is reply-to-request size. Reflectors: open DNS resolvers, NTP with monitoring, SSDP, others, all innocent third parties.
• Root cause: source-address spoofing; the control is anti-spoofing (ingress/egress) filtering, deployed by the networks the spoofed traffic leaves (a collective-action problem). Amplifier operators should also close open resolvers, disable NTP monitoring, restrict sources and rate-limit.
• Victim defences: upstream scrubbing, capacity and anycast.

Test yourself

1. How does a volumetric attack work, and why can the victim's own server do nothing about it?

It sends more traffic than the target's internet connection can carry, so the connection is saturated and legitimate traffic cannot get through. The victim's server can do nothing because the connection fills before any packet reaches the server to be processed, so no server-side configuration or capacity helps; the bottleneck is the pipe, not the machine.

1. Explain the Smurf attack and what general principle it illustrates.

Smurf sent a small ICMP echo request to a network's broadcast address with the source address forged to be the victim's, so every machine on that network replied to the victim, turning one small packet into many at the victim. It illustrates amplification: using a forged source address and a service that answers a small request with a larger or multiplied response to make a small attacker generate a large flood.

1. What properties must a service have to be usable as an amplifier?

It must answer a small request with a much larger reply, giving a high amplification factor, and it must run over a protocol where the source address is not verified, typically a connectionless protocol like UDP, so that the reply can be directed to a forged victim address rather than back to the real requester. Open DNS resolvers and NTP servers with monitoring enabled are common examples.

1. What is the root cause of amplification attacks, and why does the fix persist unapplied?

The root cause is source-address spoofing, the ability to send packets forging the victim's address as the source. The fix is anti-spoofing ingress and egress filtering, which drops packets with forged source addresses, but it must be deployed by the operators of the networks the spoofed traffic leaves, who are not the victims and have little direct incentive, so a collective-action problem keeps it from being universal.

1. Why should an assessment flag an organisation's open resolver even though it causes the organisation no direct harm?

Because an open resolver can be used as an amplifier and reflector in denial-of-service attacks against third parties, so it is a harm to others rather than to the organisation itself. Organisations habitually neglect such issues precisely because they suffer no direct consequence, which is exactly why an assessment must identify them, alongside recommending anti-spoofing filtering so the organisation's network cannot be used to launch spoofed attacks.