This issue can affect any product or platform running Junos OS with NTP client or server enabled.

When an NTP client or server is enabled within the [edit system ntp] hierarchy level of the Junos configuration, REQ_MON_GETLIST and REQ_MON_GETLIST_1 control messages supported by the monlist feature within NTP may allow remote attackers to cause a denial of service. NTP is not enabled in Junos by default. Once NTP is enabled, an attacker can exploit these control messages in two different ways:as part of a denial of service attack against a remote victimas the target of an attack against the device itselfIf unwanted NTP requests come into a Junos device, the NTP process will occupy resources such as memory and CPU, slowing down other processes and affecting overall system functionality. In extreme cases, the situation could result in traffic loss or protocol flaps.On the SRX Series platform, NTP requests coming in from security zones to the firewall self-traffic are dropped by default unless the ‘host-inbound-traffic‘ for ‘protocol ntp‘ is explicitly enabled.Neither ScreenOS nor JUNOSe are vulnerable to this issue. These systems do not support the “monlist” feature of NTP.This issue has been assigned CVE-2013-5211.

Response to monlist control messages has been disabled by default.The following software releases have been updated to resolve this specific issue: Junos OS 11.4R12, 12.1R10, 12.1X44-D35, 12.1X45-D25, 12.1X46-D15, 12.1X47-D10, 12.2R8, 12.3R7, 13.1R4-S2, 13.2R4, 13.3R2, 14.1R1, and all subsequent releases (i.e. all releases built after 14.1R1).This issue is being tracked as PR 931184 and is visible on the Customer Support website.KB16765 – “In which releases are vulnerabilities fixed?” describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.If a possible attack has been identified, or if the NTP process is occupying a large amount of CPU or memory resources, the most effective mitigation is to apply a firewall filter to allow only trusted addresses and networks, plus the router’s loopback address, access to the NTP service on the device, rejecting all other requests.  For example:
term allow-ntp {
from {
source-address {
<trusted-addresses>;
<router-loopback-address>;
}
protocol udp;
port ntp;
}
then accept;
}

term block-ntp {
from {
protocol udp;
port ntp;
}
then {
discard;
}
}
This term may be added  to the existing loopback interface filter as part of an overall control plane protection strategy.  In general, security best practices recommend having such a filter term, even during normal operation.Also, note that the router loopback address must be included under the NTP allow term. If the loopback is not allowed, ‘show ntp’ commands will time out.
User@Router> show ntp status
localhost: timed out, nothing received
***Request timed out Using the above filter allows only trusted sources to request the NTP service, but if you are interested in identifying the sources of unwanted NTP requests, add the ‘log‘ action to the term block-ntp along with the ‘discard’ action.  For example:
term block-ntp {
from {
protocol udp;
port ntp;
}
then {
log;
discard;
}
}
If your trusted IPs are spoofed, then you will have to apply the ‘log‘ action to the allow-ntp accept action as well. This will help in identifying misbehaving trusted sources as well.
term allow-ntp {
from {
source-address {
<trusted-addresses>;
<router-loopback-address>;
}
protocol udp;
port ntp;
}
then {
log;
accept;
}
}
Once you identify the source of unwanted NTP requests, take appropriate action to block them at the network perimete, and delete the ‘log‘ action from the filter term.Note: The ‘port‘ matching criterion is not supported on EX Series platforms other than the EX9200. When applying NTP control plane protection on EX Series, split the filter into two terms using ‘source-port‘ and ‘destination-port‘. For example:
term 1 {
from {
source-address {
<trusted-addresses>;
}
protocol udp;
source-port ntp;
}
then accept;
}
term 2 {
from {
protocol udp;
destination-port ntp;
}
then {
discard;
}
}
term default {
then accept;
}
The ‘log‘ action can also be used in this sample firewall filter as described earlier to aid in troubleshooting.Apply the firewall filter to the lo0, me0 or both interfaces, depending on whether NTP attacks are coming from the network port or me0 interface.  The recommendation is: If me0/vme is configured for the system, apply the filter to both lo0 and me0/vme. If me0/vme is not configured in the system, apply the filter only to lo0. How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of “PRs fixed” can be provided on request.

Information for how Juniper Networks uses CVSS can be found at KB 16446 “Common Vulnerability Scoring System (CVSS) and Juniper’s Security Advisories.”

Leave a Reply