- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Locking down NTP
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 01:48 AM
тАО10-19-2009 01:48 AM
Locking down NTP
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 02:44 AM
тАО10-19-2009 02:44 AM
Re: Locking down NTP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 03:06 AM
тАО10-19-2009 03:06 AM
Re: Locking down NTP
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 03:49 AM
тАО10-19-2009 03:49 AM
Re: Locking down NTP
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 03:54 AM
тАО10-19-2009 03:54 AM
Re: Locking down NTP
On the client in /etc/ntp.conf
restrict
On the server in /etc/ntp.conf
restrict
above line for each subnet that uses the time server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 05:41 AM
тАО10-19-2009 05:41 AM
Re: Locking down NTP
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 05:56 AM
тАО10-19-2009 05:56 AM
Re: Locking down NTP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-19-2009 04:23 PM
тАО10-19-2009 04:23 PM
Re: Locking down NTP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2009 01:15 AM
тАО10-20-2009 01:15 AM
Re: Locking down NTP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2009 04:13 AM
тАО10-20-2009 04:13 AM
Re: Locking down NTP
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.