adrelanos <[email protected]> wrote: > I read http://www.openbsd.org/faq/faq6.html#OpenNTPD and also found this > nowhere else. > > NTP is not authenticated in OpenBSD by default, right?
Right. OpenBSD's ntpd implements the publically specified protocol, SNTPv4 (RFC2030), which simply doesn't include authentication. Mills's reference ntpd offers authentication, remote management, etc., but it uses undocumented protocols for these features. Requests sent by OpenBSD's ntpd include a 64-bit random cookie that the server needs to mirror back or the response will be ignored. Flooding a machine with bad NTP packets will thus have no effect, you need to mount an actual MITM attack. > That is a major security vulnerability. A MITM can set the clock > severals years back, thus getting the client into using expired/revoked > SSL certificates and provable loads of other issues. I think you'll find it surprisingly hard to move the clock back by that much, since ntpd doesn't set the clock but slowly slews it, see adjtime(2). I recently had a machine that had lost its BIOS settings, and I quickly punched in a rough clock time, thinking ntpd would correct it quickly. I had forgotten about DST, so the time was off by an hour rather than a few minutes, and ntpd took a long time--a day?--to correct this. Anyway, your concern about authenticating NTP is quite valid. If you are worried about such an MITM attach in your network environment, you can set up IPsec to authenticate the server. For example, as a proof of principle, I have this unidirectional AH security association on a pair of machines here: flow ah in proto udp from 2001:6f8:124a::1 port domain to 2001:6f8:124a::6 flow ah in proto udp from 2001:6f8:124a::1 port ntp to 2001:6f8:124a::6 ah transport from 2001:6f8:124a::1 to 2001:6f8:124a::6 spi 0xac100006 -- Christian "naddy" Weisgerber [email protected]
