[Pool] New participant, big question
timekeeper at famsik.de
Mon Feb 10 00:14:51 UTC 2014
> I've just joined the pool with the time.cajuntechie.org server
welcome! Glad to have you!
> I'm wondering if the default configuration is enough.
What's that "default configuration"? Your Linux distribution's
default configuration, I take it.
Now, I don't know what that is. Personally, I recommend something like
restrict -4 default limited kod notrap nomodify nopeer noquery
restrict -6 default limited kod notrap nomodify nopeer noquery
- and that's about what many distributions ship these days.
Possibly with the exception of "limited" (which requires an additional
"discard" to be of use) and "kod".
With minor simplification, configuring "kod" asks the server
to tell clients when they are being rate-limited.
As people report its being widely ignored exactly by those clients
that get kods sent to them, its utility is debated.
Personally, I want to promote adherence to "Best Practices"
as described in chapter 10 of http://www.ietf.org/rfc/rfc4330.txt .
So I have decided to make sure my server sends kods.
In my opinion, "limited" and "kod" should be used together.
In passing: I have disabled my earlier iptables-based rate limiting
and am back to relying on ntpd's build-in limiting, to make sure
kods get sent.
> To test my server, I went to another computer outside of the network and
> did a 'host time.cajuntechie.org' in ntpdc. I then issued a few commands
> like monlist, peers, etc and I got a timeout every single time. Does
> this mean my server is safe from the amplification attack or do I need
> to do more?
Sounds good to me.
To be pedantic about wording: Both rate-limiting and the "restrict"
configuration are about making sure that your server
can not be used as the amplifier (the _weapon_) in an amplification attack.
I'm not aware of anything you can do configuration-wise
to make sure it is safe from becoming the _victim_ of an amplification attack.
Continuing on that "pedantic" theme, you may want to make sure
NTP traffic gets through from that computer (the one you went to)
to your time server. For that, visit that computer again and issue
ntpdate -d time.cajuntechie.org
This should give you some debug information and tell you
how much ntpdate would have adjusted the clock,
had you been root and not used "-d".
If you see such output, that's a strong hint your other test
actually exercises your server and its results are valid.
More information about the pool