NTP amplification: when a time server answers for you

The reasoning is on attack layers: this arrives as volume, and request inspection happens after volume has already done its work.

Three properties combine, and removing any one of them ends the technique.

The protocol needs no connection. Queries and replies are single messages, so nothing verifies that the sender is who the address says.

The return address can be forged. The service answers the address in the query, and that address is the victim's.

One legacy query returns disproportionate data. Older time server software supported an administrative query that returned a list of recent clients. A short request produced a long answer, which is precisely the property amplification needs. It exists for diagnostics, it was never meant to be reachable from the whole internet, and current software disables or removes it.

The pattern is not specific to time services. Any protocol that answers unauthenticated queries with larger replies can be used the same way, which is why the defence is structural rather than a matter of blocking one service.

The mechanism is identical, and only the population differs.

Service discovery on local networks works by asking connected devices to announce what they offer. The replies are verbose by design, and the protocol assumes a local network where that is harmless. Consumer routers that expose this to the internet, usually by accident, become reflectors the way an exposed time server does.

Two things follow. The reflector population is enormous and consists of devices nobody administers, so it does not shrink the way server misconfigurations do. And from the victim's side it is indistinguishable from any other amplification: high volume from sources with no relationship to you.

Every amplification event has a victim and a set of unwitting participants. You can be either.

As the victim, nothing about your configuration caused it and nothing about your configuration stops it. The traffic is legitimate replies from legitimate servers, and the only remedy is upstream.

As a potential reflector, you have work to do. Any service you run that answers queries from anywhere, and answers them with more data than it received, is a candidate. For time services specifically, the administrative query class should not be reachable from the internet, and software current enough to have removed it is the simpler fix.

This second role is the one most people never check. Being used as a reflector does not degrade your service noticeably, produces no alerts, and is visible only as outbound traffic nobody looks at.

Rarely from your own monitoring, which is the problem.

The usual notification is external: an abuse report from a network on the receiving end, or a message from your hosting provider forwarding one. By then the traffic has been leaving your server for a while, billed to you, and attributed to you by everyone who saw it.

The check that prevents this costs a few minutes and belongs in the same routine as any other exposure review: confirm which services answer queries from outside, and whether any of them answers with more than it received.

Two signals distinguish it from an ordinary flood.

Replies you never requested. Inbound traffic from a service port belonging to a protocol you did not query, from many sources at once. That is the signature: not requests arriving, but answers.

Sources are real and reachable. Unlike forged floods, these addresses belong to servers that genuinely exist and respond. Anyone investigating will find working services at the other end, which is why blocking them is both possible and pointless: there are always more.

Four measures, and the first two are the only ones that help a victim.

Filter upstream by source characteristics. Replies from a protocol you never use can be dropped before your link, and this is a rule your connectivity provider can apply quickly.

Have capacity in front of you. As with every attack in this family, absorbing volume is infrastructure rather than configuration.

Do not run open reflectors. Restrict administrative query classes to the networks that need them, keep software current, and confirm that services intended for internal use are not reachable from outside. This protects other people rather than you, which is why it gets skipped.

Support source address validation. Networks that verify traffic leaves them carrying addresses they own make forgery impossible at the origin. No individual operator can deploy this on someone else's network, which is why the technique persists despite being solvable in principle.

What does not help: request rules and challenges, since nothing here reaches the stage where a request exists.

The same reflection mechanism applies to the naming system, and that case belongs to the naming layer of this network, where resolver behaviour and record types are documented.

Bridge WAF inspects requests, which is the wrong layer for this attack. What applies is termination: when visitors reach your site through the platform's edge, the address receiving reflected traffic is not your origin's, and the capacity absorbing volume is the platform's. Asking which component covers which layer is a fair question for any provider, including us. See what the platform offers at Bridge CDN.