[ntp:questions] Thoughts on KOD
detha at foad.co.za
Sun Jul 6 20:05:10 UTC 2014
On Sun, 06 Jul 2014 18:51:16 +0000, Rob wrote:
> detha <detha at foad.co.za> wrote:
>>> Maybe. For the moment I think it is sufficient if we provide a
>>> mechanism by which offenders gets reported to *some* system. We *could*
>>> also provide a method by which white/black-list can be dynamically set
>>> from an external source, so enough hooks exists, but I do not think
>>> that NTPD should be burned with the rest of that system.
>> Agreed, not core functionality for ntpd; but it would be nice to have a
>> hook where one can 'vet' an incoming IP address, much like the RBL hooks
>> are implemented in mail agents.
> The problem is that source addresses can be spoofed. There is the BCP38
> document that recommends providers to implement countermeasures against
> that, but it is not widely followed, mostly because there is no financial
> gain for those that do it.
Not such a big problem; if the source address is spoofed, chances are
99.99% that the packet is part of some DDoS attack, and blacklisting that
IP will frustrate that attack (which is why a 'central' place where
abusers are logged would help against NTP reflection attacks: once
triggered, a lot of potential reflectors become useless to the attacker).
The 0.01% where the purpose of the spoofed IP was to get someone's IP
blacklisted will have to be handled somehow, either with timeouts or
> This reminds me of the situation with open SMTP relays. Those once were
> common practice (and even had a function), and when it became apparent
> that they had to be closed because of the abuse, there also was a large
> number of providers that did not want to cooperate.
> There were forced to do so by an RBL system that started to refuse mail
> from systems that were not appropriately configured.
> Probably the only way to get BCP38 implemented is to develop a similar
> system that just rejects traffic orginating at providers who don't do
> source address filtering.
There are some differences between open SMTP relays and networks not
implementing BCP38. TCP versus UDP, and to quote Paul Vixie from
] "... but the big reason why SAV isn't the default is: SAV benefits only
] other people's customers, not an operator's own customers.
] There is no way to audit a network from outside to determine if it
] practices SAV. Any kind of compliance testing for SAV has to be done by
] a device that's inside the network whose compliance is in question. That
] means the same network operator who has no incentive in the first place
] to deploy SAV at all is the only party who can tell whether SAV is deployed."
That, and mis-configured NTP servers, is why we still have reflection
> Without that, NTP server operators are really helpless against attacks,
> both of their servers and backscatter attacks against innocent victims.
> But of course it is outside the scope of NTP to do this, it just happens
> that NTP is a recent victim of this wide misconfiguration problem.
The biggest problem with NTP is the amplification factor. With a 1:1 or
even 1:1.5 amplification factor, the attacker won't bother, and move to
the next target - SNMP is a good candidate. With a 1:12 or better ratio,
the attacker is happy.
One way to weed out misconfigured servers would be to take a page from the
mail operators book about 10 years ago, probe the source of incoming NTP
requests for a misconfigured server (supports monlist on the public side
etc.) and blacklist that source. Draconian? Yes. Effective? Maybe.
More information about the questions