> Forgive me for my lack of knowledge in this area, > but does the above command and output still show the vulnerability? > If so, is the fix (as NTP Bug 3118 explains) to add > "restrict default noquery" to the ntp.conf file? > If this is the fix, then all queries are shutoff, correct?
Philip, It would really depend on what your "restrict default" config line(s) currently have. There are a few issues that exist but the biggest is the infamous DDoS amplification attack. It only takes a small UDP packet (from which the source IP can be easily faked) to make a request, and your server sends out a much larger packet in reply, multiply that by hundreds or even thousands of machines that are not properly locked down and a malicious attacker has a way to DDoS any server off the internet. It also exposes which version of NTP & Linux you are running, which could lead to other exploitations not necessarily related to NTP. You are correct in that the 'noquery' statement is what disables the mode 6 response (what you see from sending ntpq -c rv ...) The best way is to lock down your configuration by default, then allow certain permissions for individual IPs or small subnets based on if they have additional needs (beyond basic client time requests). Here are some examples below: # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict default kod limited nomodify notrap nopeer noepeer noquery restrict -6 default kod limited nomodify notrap nopeer noepeer noquery # Permit all access over the loopback interface. restrict 127.0.0.1 restrict ::1 # Hosts on local network are less restricted. #restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap You can go to the NTP online documentation to learn about all the different options for the 'restrict' lines, it is really quite in-depth. In general 99% of the time people only need to query for time, which those default restrict lines above will still allow. (If you wanted to block ALL queries, including time requests, you would use 'ignore' in your default restrict.) The other 1% of the cases could be that you are actually "peering" with another NTP server (instead of client/server) in which you would need to make a special restrict line to allow that host. Or if you were doing remote monitoring / logging / configuration. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
