On Nov 6, 2015, at 12:08 AM, Miroslav Lichvar <[email protected]> wrote: > On Thu, Nov 05, 2015 at 01:55:44PM -0800, Charles Swiger wrote: >> There exists a certain VOIP PBX vendors' braindamaged ntp client >> implementation which handles a KoD DENY by repolling every second. >> >> It wouldn't stop even when all traffic was firewalled. One spoofed packet >> to one of those means the IP being spoofed gets an NTP packet every second >> until the PBX gets rebooted. > > Interesting. Isn't this an example of a broken client where not > responding with any good timestamps was supposed to let it drift, the > user notice the clock is wrong and get the implementation fixed, as we > talked about earlier in this thread? Is it fixed now?
Not sure; it was nearly ten years ago. I eventually had my upstream ISP blackhole the traffic on their side. > Would it stop the one-second poll if it received a good reply from the > server? If yes, the new suggested approach in rate limiting would be > helpful here. Well, if it received normal poll replies, it was running at a polling rate of 64 s, IIRC. >>> If the rate limiting code was modified to respond to the client >>> requests with KoD DENY (and the client actually supported the code as >>> described in the RFC) or it completely blocked the client for one day, >>> it would make the attack much cheaper. >> >> The client freewheels for the day and maybe drifts by a few milliseconds. >> So? > > Well, the attacker can keep doing once per day to prevent the client > from getting any useful packets. That's what the attack seems to be > about. One of the cases they mention, anyway. A more complicated attack was trying to time-warp the target by futzing with all of their NTP sources. Regards, -- -Chuck _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
