Using nmap to scan for DDOS reflectors

Published: 2014-06-02
Last Updated: 2014-06-02 04:51:42 UTC
by Rick Wanner (Version: 1)
6 comment(s)

Before we get into this here is the standard disclaimer.  Do not scan any devices that you do not have explicit permission to scan.  If you do not own the devices I strongly recommend you get that permission in writing.  Also, port scanning may cause instability or failure of some devices and/or applications.  Just ask anyone who lost ILOs to heartbleed.  So be careful!

As we have seen in past diaries about reflective DDOS attacks they are certainly the flavor of the day.  US-CERT claims  there are several UDP based protocols that are potential attack vectors.  In my experience the most prevalent ones are DNS, NTP, SNMP, and CharGEN.  Assuming you have permission; Is there an easy way to do good data gathering for these ports on your network? Yes, as a matter of a fact it can be done in one simple nmap command.

nmap ‚??sU ‚??A ‚??PN ‚??n ‚??pU:19,53,123,161 ‚??script=ntp-monlist,dns-recursion,snmp-sysdescr <target>

Let‚??s break this down:

-sU ‚??perform a UDP scan.  Since all the services above are UDP I only need to scan for the UDP ports.

-A -perform operating system and application version detection.  This will attempt to give you more information about what applications are running on the open ports.  The -A option also includes operating system detection, but it is unlikely that operating system detection will work when scanning this few ports.

-PN ‚??scan even if you can‚??t contact the IP.  By default nmap will not scan any device it can‚??t contact. Unfortunately if a device is hidden behind a firewall nmap will not usually be able to detect the device and will omit it from the detailed scan.  A downside of using ‚??PN is that nmap will complete the detailed scan against the IP even if it doesn‚??t exist or no ports are open.  If you are scanning a large number of IPs the scan will take a long time.

-n ‚??don‚??t do a DNS resolution.  By default nmap performs a DNS resolution.  Not doing that resolution will speed up the scan somewhat.

-pU:19,53,123,161 ‚??scan UDP ports specified.  In nmap ‚??‚??p‚?? is used to indicate which ports to scan. The ‚??U‚?? tells nmap that the ports that follow are UDP ports. Since this scan is only scanning UDP ports (‚??sU) the ‚??U‚?? is redundant.  However over the years I have gotten into the habit of explicitly specifying which type of ports I want to scan unless I want to add some TCP ports (-pT:) to the scan at a later time.

The ports specified in this scan are:

  • 19 ‚?? CharGEN
  •  53 ‚?? DNS
  • 123 ‚?? NTP
  • 161 - SNMP

‚??script=ntp-monlist,dns-recursion,snmp-sysdescr ‚?? the ‚??script= option enables the nmap scripting engine (NSE) and runs scripts when they make sense to run.  In other words, the ntp-monlist script will only be run when the NTP port is found to be open.  nmap has many scripts available which can be used to extend nmaps basic functionality.

The scripts specified on this scan are:

  • ntp-monlist ‚?? while any open NTP service can be used in a reflective DDOS attack the maximum amplification is achieved with NTP services that permit the monlist command to be executed. This script will do a check to see if monlist can be executed against an open NTP port.
    • Normally an open NTP service will look similar to:

123/udp   open   ntp   NTP v4

If the monlist command is enabled on the ntp server, the ntp-monlist script will give you more information:

123/udp open  ntp     NTP v4

| ntp-monlist:

|   Target is synchronised with

|   Alternative Target Interfaces:

|       XXX.16.1.71    

|   Public Servers (4)

|       XXX.87.64.125    XXX.75.12.11    XXX.108.0.131

|   Other Associations (596)


  • dns-recursion ‚?? Normally public DNS servers will only answer DNS queries for which they are authoritative.  A DNS server that permits and processes queries for names it is not authoritative are called recursive DNS servers and recursive DNS servers in most cases are misconfigured.   The output for an open DNS port with recursion enabled will be similar to :

53/udp  open          domain  Microsoft DNS 6.1.7600 (1DB04228)

| dns-nsid:

|_  bind.version: Microsoft DNS 6.1.7600 (1DB04228)

|_dns-recursion: Recursion appears to be enabled

  • snmp-sysdescr ‚?? attempts to extract more information from the SNMP service.  An open SNMP service will look similar to:

161/udp open     snmp    SNMPv1 server (public)

  • With the snmp-sysdescr script it will usually display more information which may tell you more about the device you are scanning:

161/udp open|filtered snmp

|_snmp-hh3c-logins: TIMEOUT

|_snmp-win32-shares: TIMEOUT


161/udp open     snmp    SNMPv1 server (public)

| snmp-sysdescr: Apple AirPort - Apple Inc., 2006-2012.  All rights Reserved.

|_  System uptime: 9 days, 20:15:36.56 (85053656 timeticks)

Want to take a guess at what these devices are?

As you can see nmap provides a simple and effective way of scanning for the common ports used in reflective DDOS attacks.  This diary has barely scratched the surface of nmap‚??s capabilities. 

I would be interested to know if any of you have ways to enhance or improve this scan.


-- Rick Wanner - rwanner at isc dot sans dot edu - - Twitter:namedeplume (Protected)

6 comment(s)


Perhaps it would make sense to add -sV there to test what's really on the chargen port?
Although the nmap documentation is somewhat fuzzy as to what all is included in -A, it is clear that it includes -sV (version detection) and -O (OS detection).

Using -A Chargen most often appears as:
19/udp open Chargen?

Once in a while nmap will show a broken fingerprint for obvious CharGEN:

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at :
From my own experience, nmap lasts too long for large IP blocks.
It would be better to adjust some time issues:

--max-retries 2 --host-timeout 200ms

Even though, I have experienced false negatives due to latency problems. If you are placed on a reliable network (with fiber connections), it would be better for you.

Latency matters in this case!

I have received a couple of comments about possibly adding port 0. In my experience the prevalence of port 0 DDOS has dropped off significantly, probably because the other services are more plentiful and have better amplification factors. If you want to include port 0 it is a minor change to the command line.

nmap –sU –A –PN –n –pU:0,19,53,123,161 –script=ntp-monlist,dns-recursion,snmp-sysdescr <target>
As a habit, I always use --reason so I will know what the response from the port was if it it closed.

For UDP, it would tell me whether a port was no-response, port-unreach, admin-prohibited or whatever. That way, I could more easily determine if I just need to open some firewall rules or if it really is closed.

It won't help with DDOS discovery, but it will help you tune the network to let you properly perform the discovery in the first place.

Of course, if your network is configured properly, you'll just get all no-responses from the blocked ports which looks an awful lot like an open but non responsive port.

It's just a personal preference. The information is already present; you are just displaying it. It will not increase the scan time.
Port 0 shows up in PeakflowSP for DOS attacks that are comprised of UDP fragmented traffic (in which the layer 4 info is not available in the subsequent packets after the first packet). These attacks are not really coming in with a L4 UDP header with port 0, PeakflowSP just doesn't know how to classify the port so it puts in zero.

Diary Archives