未加星标

Arrive On Time With NTP -- Part 3: Secure Setup

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Earlier in this series, I provided a brief overview of NTP and then looked at important NTP options to lock down your servers. In this article, I’ll look at some additional security concerns.

Check out the pool

According to the excellent site NTP Pool Project website , which points users at a “big virtual cluster of Time Servers providing reliable easy to use NTP service for millions of clients,” there are 182 active servers for the UK pool in the IPv4 space and 99 available to IPv6 at the time of writing. For reference, they provide useful historical statistics and graphs to presumably keep an eye on any geographical areas which require more resilience, among other things. Figure 1 shows a graph of the available servers for the UK.

ntp-fig1.png
Arrive On Time With NTP -- Part 3: Secure Setup

Figure 1: The historical number of NTP servers available in the pool to the UK. Copyright NTP Pool Project and Develooper, found at http://www.pool.ntp.org/zone/uk

Used with permission

Review your options

Let’s go back to the friendly restrict command,mentioned previously. It can unilaterally “ignore” everything from hosts or subnets, This should deny absolutely everything, indeed packets of all kinds, including ntpq and ntpdc queries.

I also mentioned Kiss of Death packets earlier and adding the kod option to a restrict line means that we will send a kiss-o'-death (KoD) packet if we want help reduce unwelcome packets and introduce rate-limiting of some description.

One other point to note is that using the limited option only denies clock updates if a requests comes up against the rate limits established by the discard command. The limited option doesn’t apply to ntpq and ntpdc queries, which might add more load from a user with nefarious intentions.

A common addition to the restrict line is nomodify . This denies ntpq and ntpdc queries that might attempt to modify the time on an NTP server. As you would expect, however, any queries that return information only are allowed.

You are unlikely to avoid seeing this option: the noquery flag makes certain that you deny all ntpq and ntpdc queries. Be aware, however, that offering up the correct time is still possible despite this being enabled.

If you want to avoid building relationships with other NTP servers (e.g., unless they are successfully authenticated with you), then the nopeer option will allow you to do this. According to the manual, “This includes broadcast, symmetric-active and many-cast server packets when a configured association does not exist.”

The noserve option is simple; it dutifully denies all packets from a machine (or range of machines) except for ntpq and ntpdc queries.

As you might expect the notrust switch enforces who can connect to your NTP server. In fact, it will deny traffic that isn’t cryptographically authenticated. Again quoting from the manual:

“Note carefully how this flag interacts with the auth option of the enable and disable commands. If auth is enabled, which is the default, authentication is required for all packets that might mobilize an association. If auth is disabled, but the notrust flag is not present, an association can be mobilized whether or not authenticated. If auth is disabled, but the notrust flag is present, authentication is required only for the specified address/mask range.”

One final option to pay attention immediately to is called version. This option will be certain to disallow traffic that doesn’t match the current NTP version of your server or client. This can clearly be useful for enforcing that up-to-date versions are used and therefore older security issues present less risk. A similar approach appears in OpenSSH where using the legacy “version 1” is far from recommended; therefore, it is necessary to explicitly enable that version to avoid falling into a potential trap and opening up security holes unnecessarily.

Localized infrastructure

One infrastructure recommendation relates to installing NTP servers and introducing “peering” yourself for improving resilience and capacity. Implementing a peer-to-peer infrastructure within your Stratum 2 servers means that those servers within the peer group allow each other to update their clocks. This, in turn, helps with load balancing and any additional load on their relevant upstream servers. This approach might also be called distributing the time horizontally.

As with all online architectural challenges, there are several other factors to consider. For example, keeping time diligently with three upstream servers and building a complex internal NTP fabric, upon which you come to heavily rely, is of little use if you only have one external Internet connection.

Perimeter Lockdown

Earlier, I promised to quickly examine how to lock down your firewalling with IPtables, rather than opening up UDP port 123 carte blanche. This might apply to your local NTP client, or if you added such rules to a perimeter firewall all of the clients on your LAN. I’ll look at limiting who you can speak to in order to ensure that only very select, predefined, time servers can connect with you.

I’ll use the “uk.pool.ntp.org” example for familiarity, but in reality you might lock down these rules to three individual servers and not a pool of servers. This is because, although you are assured of the reliability of multitudinous NTP servers being available, you may not want to trust them all. Due to the high churn rate, some could be compromised and cause you unwelcome headaches.

Outbound -- egress -- traffic rules are slightly more sophisticated than those we use to allow traffic into our machine or network. This is because we want to allow “NEW” time lookups to be performed and also pick up the response when an NTP server responds to such a request with what’s called an “ESTABLISHED” connection. You can achieve that as follows:

# iptables -A OUTPUT -o eth0 -p udp -d uk.pool.ntp.org --sport ntp -m state --state NEW,ESTABLISHED -j ACCEPT

Note that if this were my configuration, I would most likely tie these rules to specific IP addresses.

Conversely, to allow an inbound time check to occur, you can use this fractionally simpler line with just “ESTABLISHED” connections being allowed through:

# iptables -A INPUT -i eth0 -p udp -s uk.pool.ntp.org --sport ntp -m state --state ESTABLISHED -j ACCEPT Alternative to NTP Finally, to help clear up any confusion there’s an alternative of sorts to the venerable Network Time Protocol that is worth a quick mention. This option comes in the form of the Simple Network Time Protocol (SNTP). What is interesting is that both timekeeping solutions follow the same packet format and actually, according to RFC 4330 , “the NTP and SNTP packet formats are the same, and the arithmetic operations to calculate the client time, clock offset, and roundtrip delay are the same.” So, be confused no longer if you think

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

主题: UTIPv4IPv6
分页:12
转载请注明
本文标题:Arrive On Time With NTP -- Part 3: Secure Setup
本站链接:http://www.codesec.net/view/529887.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(28)