Follow the templates below to secure your server from being used in a DDOS attack.
CISCO IOS
This is a template IOS configuration that should work for most sites, but pay attention to the comments and notes. If your IOS devices synchronize with a device that is capable of MD5 authentication, see further below for authentication-specific statements. If you use control plane policing, be sure you account for NTP traffic. You might also be interested in adding the log tag to some of your ACLs so you know who is trying to talk NTP to your boxes, but that is best left as a local decision so we have not included it by default.
! Core NTP configuration ntp update-calendar ! update hardware clock (certain hardware only, i.e. 6509s) ntp server 192.0.2.1 ! a time server you sync with ntp peer 192.0.2.2 ! a time server you sync with and allow to sync to you ntp source Loopback0 ! we recommend using a loopback interface for sending NTP messages if possible ! ! NTP access control ntp access-group query-only 1 ! deny all NTP control queries ntp access-group serve 1 ! deny all NTP time and control queries by default ntp access-group peer 10 ! permit time sync to configured peer(s)/server(s) only ntp access-group serve-only 20 ! permit NTP time sync requests from a select set of clients ! ! access control lists (ACLs) access-list 1 remark utility ACL to block everything access-list 1 deny any ! access-list 10 remark NTP peers/servers we sync to/with access-list 10 permit 192.0.2.1 access-list 10 permit 192.0.2.2 access-list 10 deny any ! access-list 20 remark Hosts/Networks we allow to get time from us access-list 20 permit 192.0.2.0 0.0.0.255 access-list 20 deny any
Simple NTP authentication using MD5 in IOS can easily be managed for a limited set of static peers and upstream time providers that support it. Since this is generally a manual process, MD5 authentication support for a a large set of clients is likely to be unwieldy. Nonetheless, this feature provides some additional protection from unwanted NTP messages. This example assumes that you create an ‘ntp authentication-key’ for each peer/server. The key can be re-used, but we do not recommend re-using the same key with peers or upstreams from different autonomous systems. Also create a ‘ntp trusted-key’ line for each keyid you’ve configured. Please note, we have seen some gear limit the pass phrase to eight characters.
ntp authenticate ! enable NTP authentication ntp authentication-key [key-id] md5 [hash] ! define a NTP authentication key ntp trusted-key [key-id] ! mark a NTP authentication key as trusted ntp peer [peer_address] key [key-id] ! form a authenticated session with a peer ntp server [server_address] key [key-id] ! form a authenticated session with a server
The following commands may prove helpful to monitor or debug NTP issues on IOS.
! general NTP and clock status show ntp status ! lists synchronization details with configured peer(s)/server(s) show ntp associations [detail] ! shows or logs detailed NTP messages/packets ! WARNING: not recommended for general use in a production network!! debug ntp [...]
JUNIPER JUNOS
The following configuration statements will define one or more time servers the router will obtain time from. The boot-server option is used to get a significantly skewed clock back into sync. To protect the local ntpd process in JUNOS you can use firewall filters on the loopback interface as you likely do for other services. Authentication can also be done on the Juniper ntpd process and it can be easily managed for a limited set of static peers and upstream time providers that support it. Since this is generally a manual process, authentication support for a large set of clients is likely to be unwieldy. Nonetheless, this feature provides some additional protection from unwanted NTP messages. This example assumes that you create an ntp ‘authentication-key’ for each peer/server. The key can be re-used, but we do not recommend re-using the same key with peers or upstreams from different autonomous systems. Where you see the [key-id] option, adjust that statement according to your authentication setup, if any.
system {
ntp {
authentication-key [key-id] type md5 value "[pass-phrase]";
trusted-key [key-id];
/* Allow NTP to sync if server clock is significantly different than local clock */
boot-server 192.0.2.1;
/* NTP server to sync to */
server 192.0.2.1;
server 192.0.2.2 key [key-id] prefer;
}
}
You can use your loopback filter that shields the router from other anonymous access to also limit who the local NTP service talks to. The relevant section of that filter might look something like the following:
from {
source-address {
0.0.0.0/0;
/* NTP server to get time from */
192.0.2.1/32 except;
}
protocol udp;
port ntp;
}
then {
discard;
}
You must then eventually have a default accept-all rule or, if you have a default deny, you must explicitly allow your router to talk to whatever NTP systems it uses for time synchronization. For example, to add a explicit rule to permit NTP traffic, your configuration might look something like this:
from {
source-address {
/* NTP server to get time from */
192.0.2.1/32;
}
protocol udp;
port ntp;
}
then {
accept;
}
UNIX NTPD
The following configuration is for a UNIX machine to act as simply an NTP client and never to allow NTP queries to it except from the loopback address:
# by default act only as a basic NTP client restrict -4 default nomodify nopeer noquery notrap restrict -6 default nomodify nopeer noquery notrap # allow NTP messages from the loopback address, useful for debugging restrict 127.0.0.1 restrict ::1 # server(s) we time sync to server 192.0.2.1 server 2001:DB8::1 server time.example.net
You can use your standard host firewall filtering capabilities to limit who the NTP process talks to. If you’re using Linux and the host is acting as an NTP client only, the following iptables rules could be adapted to shield your NTP listener from unwanted remote hosts.
-A INPUT -s 0/0 -d 0/0 -p udp --source-port 123:123 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -s 0/0 -d 0/0 -p udp --destination-port 123:123 -m state --state NEW,ESTABLISHED -j ACCEPT
Authentication with the reference NTP software on UNIX can be done using symmetric key encryption, much like in Cisco IOS and Juniper JUNOS, using MD5. However, a public key-based approach called ‘AutoKey’ is also available, which is generally be considered to be even more secure. For more information about these options, see the NTP authentication options page and the Configuring Autokey documentation.
A NOTE ABOUT BROADCAST/MULTICAST NTP
If you do not need multicast NTP support, but you do support IP multicast on your network, you should consider filtering the well known multicast group address for NTP (224.0.1.1) at your border.
A NOTE ABOUT BORDER NTP FILTERING
Some networks may consider filtering all or some NTP traffic between their network and others. This is potentially very troublesome and should only be considered and implemented with a full understanding of the ramifications. We cannot advocate this action by default, but can offer some guidelines to those who wish to do so.
All packets to/from TCP port 123 should be safe to filter since NTP by design only uses UDP. This might, however, affect anyone who attempts to setup another application on TCP port 123 for some reason or any possible future extension of NTP that might use TCP.
Filtering packets from your networks to external networks with UDP source port 123 and/or packets to your networks from external networks with UDP destination port 123 will certainly prevent your hosts from communicating as NTP servers to outside entities, but it may also prevent some NTP hosts from acting as NTP clients as well. We have seen some clients use port 123 for source ports. Filtering in this scenario then may cause problems for those clients.
If you can ensure your internal hosts will only act as clients and all legitimate clients will use an unprivileged client port selection strategy you could probably apply the above aforementioned filter. We would recommend logging or monitoring the filters to assist with troubleshooting should it be necessary. Also, use your systems’s built in NTP monitoring capabilities to ensure all your NTP client systems remain in sync.
If you block all UDP 123 traffic so that no clients may talk to external servers, you should ensure all your internal hosts are setup to use one or more internal NTP servers. Since many system components rely on an accurate notition of time and most use NTP to do so, it is important to provide this service. Note, except for the most limited and restrictive of networks, we do not find it necessary to completely block NTP for all your hosts as long as those hosts can be secured in the kinds of ways suggested in the template configs above.