Locking down NTP

[N Ward]

Hi,

we are using NTP keys in our environment, but have been asked to lock down NTP to only the servers in the environment. We are currently using 2 NTP servers as Primary and Secondary, both are broadcasting, with several clients.

What is the best approach?

[N Ward]

What I'm hoping to achieve is clients and a server that do not respond to any query requests. The clients should only listen to the ntp server.

[Michael Steele_2]

Hi

You currently configured in one of three states, broadcast. You want now go to either peer or client server and change the /etc/ntp.conf file.

The peer command specifies that the local server is to operate in symmetric active mode with the remote server. In this mode, the local server can be synchronized to the remote server and, in addition, the remote server can be synchronized by the local server. This is useful in a network of servers where, depending on various failure scenarios, either the local or remote server may be the better source of time.

The server command specifies that the local server is to operate in client mode with the specified remote server. In this mode, the local server can be synchronized to the remote server, but the remote server can never be synchronized to the local server. This is the most common operating mode (by far).

The broadcast command specifies that the local server is to operate in broadcast mode, where the local server sends periodic broadcast messages to a client population at the broadcast/multicast address specified. Ordinarily, this specification applies only to the local server operating as a sender; for operation as a broadcast client, see the broadcastclient or multicastclient commands below. In this mode, address is usually the broadcast address of (one of) the local network(s) or a multicast address assigned to NTP. The address of 224.0.1.1 is assigned to NTP. This is presently the only address that should be used. Note that the use of multicast features requires a multicast kernel.

http://docs.hp.com/en/B2355-90692/xntpd.1M.html

[Hakki Aydin Ucar]

Even though, I am not familiar the configuration and issues, sometime I used these links, maybe you can use them:

http://www.eecis.udel.edu/~mills/ntp/html/index.html

http://support.ntp.org/bin/view/Main/WebHome

http://www.meinberg.de/english/support/index.htm

[N Ward]

I believe this may be what I need...


On the client in /etc/ntp.conf

restrict mask noquery

On the server in /etc/ntp.conf

restrict mask noquery nomodify notrap

above line for each subnet that uses the time server.

[Matti_Kurkela]

Yes, those lines will limit what your clients can do with the server and vice versa.

You'll also need these lines:

restrict 127.0.0.1
restrict default ignore

The first line allows full access from the local host (i.e. allows run-time monitoring and configuration changes with commands like ntpq). For modifying the configuration, the correct NTP keys are still required.

Note that the syntax is somewhat counter-intuitive: "restrict " with no restrictions is actually more like "unrestrict ".

The second line tells ntpd to completely ignore all NTP packets from any hosts which don't match any other "restrict" configuration line. This is the single most important restriction line, if you aim for a "deny by default" policy.

MK

[N Ward]

Thanks, makes sense, I'll add those in too.

[rick jones]

Given that NTP (at least when it can access three or more independent sources of time...) has algorithms to detect bad clocks, what is the rationale behind trying to lock down NTP?

[N Ward]

We are currently sync internally and adjusting the local clock once a week. This will change to a external atomic clock soon, however we were asked to prevent (in the main) the ability to query the ntp daemon which can (apparently)reveal details about the host.

[Don Mallory]

I prefer the method below.

It opens any localised traffic on the host (127.0.0.1) so that it can manage itself, and allows clients on the local 10.10.10.0/24 and 10.10.11.0/24 subnets to query, but do not allow them to modify the host.

As well, in this case it uses the Asia Pacific NTP pool. There is a very heavy recommendation to move to NTP pools instead of using tier 1 servers, which reduces the global load on these services (think tier 1 DNS, can you imagine everyone hitting those for all queries? Ugh.) The downfall is that it is MUCH harder to firewall this.

Next, the fudge factor. Always the fudge factor. This allows the local host to still supply time internally if it's clock goes a little wonky.

You can use NTP authentication, or not, if your clients support it. Mine don't, so I don't. Laslty, the keys for the authentication.

This is from a Red Hat host, but it's pretty close to what you would do under HP-UX as it all comes from ntp.org.


restrict 10.10.10.0 mask 255.255.255.0 nomodify notrap
restrict 10.10.11.0 mask 255.255.255.0 nomodify notrap
restrict 127.0.0.1

# Asia Pacific NTP Pool
peer 0.asia.pool.ntp.org
peer 1.asia.pool.ntp.org
peer 2.asia.pool.ntp.org
peer 3.asia.pool.ntp.org

fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
authenticate no
keys /etc/ntp/keys


For clients, looks similar, but it allows connections to the NTP servers themselves.

restrict default ignore
restrict 10.10.10.81 mask 255.255.255.255 nomodify notrap noquery
restrict 10.10.10.84 mask 255.255.255.255 nomodify notrap noquery
restrict 127.0.0.1
server 10.10.10.81
server 10.10.10.84
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
authenticate no
keys /etc/ntp/keys

Note that the server allows the clients on the local subnets only query it, however it denies anything else. The clients do not allow anything to query them.