Re: [ntp:questions] Public ntp-server and reflection-attacks
On 11/21/2013 08:42, Rudolf E. Steiner wrote: Hi. We have strong reflection-attacks on our public timeserver (ntpd 4.2.6p5). The strange behavior is the server received one packet and sends 100 packets to the target. Yes, this is becoming increasingly common, and everyone operating NTP servers (not just those that are intended to be public) will need to take steps to ensure that they are not open to this sort of attack. The attacker is asking for something (usually the equivalent of 'ntpdc -c monlist') that causes your server to respond with lots of data. [snip] This means, the attacker sends _one_ packet and gets _100_ packets to his target. How can I disable this behavior of ntpd? There are several ways, but having a basic 'restrict' statement in your config like this will help mitigate this attack: restrict default noquery nomodify notrap nopeer restrict -6 default noquery nomodify notrap nopeer I believe the key command is 'noquery' which means that the server can't be queried for information (it does NOT affect the server's ability to respond to time requests). However, the other options will also protect your public time server. (I am also interested in how others are locking down public NTP servers.) michael ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New 60 KHz WWVB Time Format
On 1/16/13 6:36 AM, Thomas Laus wrote: I have not seen this information posted to this newsgroup. The US NIST radio station WWVB will be changing it's transmission format. The information can be found at: http://www.nist.gov/pml/div688/grp40/wwvb.cfm The old format is still being sent twice a day until the end of January 2013, but the station will only transmit the new phase modulated time code after this month. It is supposed to be compatible with the existing 'Atomic' clocks, but I have some of the original ones that were made in China that are no longer syncing. Heh: A few radio controlled clocks that used information from the carrier – specifically the Spectracom NetClock and receivers manufactured by True Time during the 1970s and 1980s – will no longer be able to read the time code and will also be obsolete. To allow users of these receivers to migrate to new products, the plan for implementing the new modulation protocol includes a transition period that will extend until at least January 31, 2013. UC Berkeley's Spectracom 8170 (NetClock) is just about to celebrate its 30th birthday. While other reference clocks are now being used to provide stratum-1 service for the campus, it was always nice to have The Reference Clock That Would Not Die as a backup. It's a shame that it won't work anymore through no fault of its own, but I suppose that's the price of progress. michael ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Building FreeBSD V8.0 kernel for PPS
On 4/13/10 1:40 PM, G8KBV wrote: Hi all again. I'm still trying to follow the instructions at:- http://blog.doylenet.net/?p=145 As earlier, so far so good (if after several tries, eventualy getting FreeBSD loaded and running) I'm at the stage of enabling PPS support in the kernel. But After successfully adding 'options PPS_SYNC' to the PPSGENERIC file, at the end of the other options declerations (using vim!) And checking it's 'stuck' in there. When I 'make buildkernel KENRCONF=PPSGENERIC' Nowt happens, except a short error message to the effect that it doesnt know how to build the kernel. Did you remember to 'cd /usr/src' before 'make buildkernel KENRCONF=PPSGENERIC'? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Manycast
On 11/02/09 07:47, Evandro Menezes wrote: Sorry, there's a change in the server configuration that i omitted before. So, I'm trying to figure out how to get manycast working, so I set up 3 computers to be clients: disable auth enable bclient tos orphan 8 manycastclient 224.0.1.1 manycastserver 224.0.1.1 And one computer to be a server: disable auth enable bclient tos orphan 8 manycastclient 224.0.1.1 manycastserver 224.0.1.1 server pool.ntp.org iburst server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org Nevertheless, the clients just never synchronize with the server. Sometimes, if a client is powered on, it does find the server, however sometimes it drops the association to never find the server again. I'm using 4.2.4p7 in all 4 computers. What gives? Try using a different multicast than the standard ntp mcast address. That's for multicast synchronization, and it may interfere with manycast. Most of the example configs included in the reference NTP distribution use the administratively-scoped address 239.1.1.1. I have had success using this address as well, but make sure that it's not already being used elsewhere in your organization. michael ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
On 6/15/09 2:38 PM, Rich wrote: Is this sort of behaviour to be expected? Does this mean that the NTP algorithm ought to be giving more weight to servers with shorter delays? Or, perhaps, does it suggest that there might be something wrong with the Stanford servers that is making them all cluster around a time that is several milliseconds different from the rest of the world? Keep in mind that the NTP protocol can't handle asymmetric round-trip delay. It's more likely that the faraway servers have asymmetric paths to Stanford, which would explain their offsets. (They are also more likely to have higher jitter.) If you're actually on the Stanford network, you may want to use one of the public NTP servers on the CalREN network, since those servers are close by and their paths are likely to be symmetric. michael ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
