Answered by the Webhosting Experts

Managed Services
at Hivelocity

Bare Metal Shouldn’t be a Grind
Let Hivelocity take the busy work out of your daily server maintenance with our Managed Services plans. Choose from 1 of 6 different managed service offerings. Standard and Premium plans available.

Questions about something specific? Chat now with one of our expert account managers and learn which plan is right for you and your customers!

With Managed Server Technicians on-site 24/7/365, your server is always in good hands.

Tags
...
...

Secure network time protocol (NTP)

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.

Share

Facebook
Twitter
LinkedIn
Email
WhatsApp

Need More Personalized Help?

If you have any further issues, questions, or would like some assistance checking on this or anything else, please reach out to us from your my.hivelocity.net account and provide your server credentials within the encrypted field for the best possible security and support.

If you are unable to reach your my.hivelocity.net account or if you are on the go, please reach out from your valid my.hivelocity.net account email to us here at: [email protected] We are also available to you through our phone and live chat system 24/7/365.

Rapid Restore

Backup your entire server’s data every night and have access to 5 days of rolling restore points.  Restore your server’s data, OS and configuration any time you need it.

Our Rapid Restore service saves the day during accidental data loss, hardware failures and virus contraction. Simply pick your recovery point and restore the data from that day. 

DDoS Protection

While our competitors may advertise DDoS protection, most often, they are merely implementing easily evaded router rules or simply black-holing targeted servers. They consider this “DDoS protecting their network.” However, neither of these solutions should give comfort to any online business. Should your site be attacked, chances are likely both of these options will end with your server being taken offline. At Hivelocity, we take the responsibility of keeping your servers online very seriously. For this reason, we offer two very serious forms of DDoS protection.

FREE

Every solution we provide includes our Filtering Edge of Network System (FENS). FENS is a series of proprietary systems that proactively monitors and protects the entire Hivelocity Network from most common Denial of Service (DOS) and Distributed Denial of Service (DDoS) attacks.

$15/MONTH PER SERVER

For an extra fee, you can enhance your server’s protection further with the addition of our Server Defense System. Our Server Defense System sits in front of your server, inspecting inbound data and looking for malicious traffic. The moment an attack is detected, it instantly begins scrubbing each data packet. Hivelocity’s Server Defense System delivers business continuity even in the face of massive and complex attacks.

Our Server Defense System is like adding an alarm and armed guard to your business, alerting you to and destroying anything attempting to jump that fence. Our Server Defense System utilizes internally developed proprietary systems in addition to Corero’s Threat Defense Smartwalls for data packet scrubbing. Each of our data centers is a scrubbing center with Corero Smartwalls on-premise, allowing us to provide on-prem zero-lag data scrubbing.

SSL Certificates

The security of your online commerce and protecting your customers’ data is as important to us as it is to you. When your customers see the green bar, they will know their connection to you is protected. We offer single domain, multi-domain, and wild-card certificates.

We offer industry leading 128-bit encryption certificates, allowing you to conduct e-commerce with complete security. Inspire confidence in your customers by displaying any number of seals and indicators certifying that your site is secure.

Load Balancing

Adding this service to two servers with identical content will allow you to distribute your load evenly across your hardware. Don’t lose business because you couldn’t handle the demand. Load balance and handle your biggest resource spikes with ease.

Firewalls

Stop attacks, prevent unauthorized access, and achieve regulatory compliance. Our Juniper hardware firewalls offload the work so your server never has to consume resources protecting itself from malicious traffic. A single firewall can be used to protect multiple servers.

Cloud Storage

Cloud storage offers users redundancy and easy accessibility, ensuring your data remains secure and readily available. Scale to as much as you need for only a 20¢/GB.

Cloud Storage is distributed and replicated across many servers, protecting your data from hardware failure. Highly scalable, it can handle thousands of client connections via TCP/IP. Connect to your virtual drive with SFTP, FTP, and SSHMount and in the future NFS and AFP. Cloud Storage is based on a stackable design which is upgradeable up to 2TB per instance.