Giter Club home page Giter Club logo

j-feature-ntp's Introduction

NTP configuration - JUNOS Feature Request

The NTP service on JUNOS systems will, by default, listen on UDP port 123 on all interfaces and configured addresses. Modern versions of the ntpd reference implementation includes an interface command to control specific interfaces or addresses the NTP service opens and listens on. In addition, there exists a restrict configuration option that controls how the NTP daemon will handle received NTP packets from hosts, including remote time servers. Modern JUNOS software appears to be using an ntpd implementation that includes these features. Unfortunately the interface control capability and restrict options are not currently available as JUNOS configuration options in the system ntp hierarchy. We the undersigned wish to express our desire for the equivalent JUNOS configuration statements. Together we request Juniper Networks commit to adding these capabilities into JUNOS. These capabilities are important for network operators to completely and more easily limit access to the NTP process from outside the local system.

Background and Rationale

Networked systems on the Internet must be resilient to attack and abuse. No where is this more true than with infrastructure devices such the enterprise and service provider routers from Juniper Networks. Network operators have devised a number of best practices for router management that include a variety of security protections such as firewall filter rules, cryptographically-strong authentication mechanisms, and anomaly monitoring capabilities.

Network infrastructure equipment must often run, and network operators generally expect, certain network client services such as time synchronization, remote logging, and traffic flow collection. Generally these largely client-side services are only ever intended to be accessible directly from the local routing operating system itself, and rarely if ever from random, unsolicited remote hosts. It is generally considered best practice to eliminate a network listener if the service never expects to receive communications from a remote host. In other cases where a network service must communicate with itself over a local socket, the network listener should only bind to a loopback address.

Open and accessible NTP services on router systems have shown to pose a particularly acute threat in practice. Open NTP services from routing systems have been implicated in real-world DDoS attacks and information leak cases. Many network operators have taken steps to protect NTP services from abuse by configuring loopback firewall filters that restrict access to the NTP service from all, but a handful of statically configured time systems the router is set to synchronize time with.

Generally, in enterprise and service provider router systems, the NTP service is only ever used as a client service, and rarely if ever do these routers act as NTP servers for other remote systems. Therefore we urge Juniper to provide the ability to configure the interface and restrict options for the NTP service for those operators that wish to remove any possibility of access to the NTP service from remote systems.

Suggested JUNOS Syntax Changes

We are seeking two specific features to the system ntp configuration hierarchy syntax. We first summarize these changes, provide reference ntp.conf configuration examples and suggest corresponding JUNOS configuration statements.

restrict option

The restrict access control option dictates what messages the NTP process will receive, act on, and respond to. The reference ntpd provides a number of options and flags to the restrict option, but we argue that only a handful are necessary for Juniper routers. We recommend the following restrict options be supported:

  [edit system]
  ntp {
      restrict [default | address] {
          ignore;
          nomodify;
          noquery;
          nopeer;
          noserve;
          notrap;
          notrust;
      }
  }

interface option

The interface configuration option controls which interface or address will be opened by ntpd and listen for incoming messages for processing. We recommend the following interface options be supported:

  [edit system]
  ntp {
      interface [listen | ignore | drop] {
          all;
          ipv4;
          ipv6;
          [interface];
          address[/prefix];
      }
  }

References

Signatories

  • John Kristoff, Network Architect, DePaul University

j-feature-ntp's People

Contributors

jtkristoff avatar

Watchers

James Cloos avatar Karl Newell avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.