SANS ISC: NTP reflection attack - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Symantec has notice in the last few weeks that there is a significant NTP reflection attacks. NTP is Network time protocol and it’s used to synch the time between client and server, it is a UDP protocol and it’s run on port 123.

In the NTP reflection attack the attacker send a crafted packet which request a large amount of date send to the host.

“In this case, the attackers are taking advantage of the monlist command.  Monlist is a remote command in older version of NTP that sends the requester a list of the last 600 hosts who have connected to that server.  For attackers the monlist query is a great reconnaissance tool.  For a localized NTP server it can help to build a network profile.  However, as a DDoS tool, it is even better because a small query can redirect megabytes worth of traffic:”

 

Here is an example of monlist request

 

Ntpdc –n –c monlist 127.0.0.1

 

  And here is the output

Or you can run a nse script which can be found at https://svn.nmap.org/nmap/scripts/ntp-monlist.nse       

And here is the packet capture of the NMAP script request:

And here is the packet capture of the response:

One way of protecting NTP server from such attack is adding

 

disable monitor

 

 To /etc/ntp.conf file

 And here is the output of the NMAP script after adding this command :

 

I believe you have listed the wrong configuration file... The file you want to edit is /etc/ntp.conf.

Quoting Anonymous:I believe you have listed the wrong configuration file... The file you want to edit is /etc/ntp.conf.

you are right.
it should be /etc/ntp.conf

Thanks

What else would normally have been "monitored" that we would be shutting off by this additional script?

One important note is that by default, when you enable ntp client on a Juniper router, it also enable NTP server with an older version allowing monlist. In other words most Juniper routers out on the Internet right now are probably susceptible to being used in this manner.

Quoting Sassan:What else would normally have been "monitored" that we would be shutting off by this additional script?

This is a great question and there is no documentation that I can find online. Anyone have an answer here?

Also, what's the difference between 'no monitor' and 'noquery'? Does it function essentially the same way?

This Symantec article recommends that noquery be enabled in the NTP conf file:

http://www.symantec.com/connect/blogs/hackers-spend-christmas-break-launching-large-scale-ntp-reflection-attacks

Thanks!!

I guess noquery blocks all queries making the ntpd client-only, ignoring any requests.
(this would generally be the most common use).

nomonitor turns off the monitoring, or at least prevents remote query of the last clients to query the server.

Quoting Anonymous:One important note is that by default, when you enable ntp client on a Juniper router, it also enable NTP server with an older version allowing monlist. In other words most Juniper routers out on the Internet right now are probably susceptible to being used in this manner.

http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613
Mitigation of NTP amplification attacks involving Junos
- basically seems to set a filter rule on ntp, rather than restricting access in the configuration file. I can't even find a configuration file for xntpd, although the command supports one.


In addition to the monitor command "ntpdc -c monlist -n <hostname>", the command "ntpdc -c reslist" may be used to discover the current restrictions. A multi-line response but with " 0.0.0.0 ... none" may indicate a configuration error. On *nix, the ntp.conf line
"restrict default kod nomodify notrap nopeer noquery" is required to
set a restrictive default set, while a subsequent "restrict 127.0.0.1" really means "allow 127.0.0.1"

Resurrecting from the dead I know but thought I'd point out that the Ntpdc command should be in lower case.