Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1576
  • Last Modified:

UDP Distributed Reflective Denial of Service (DRDoS) : server or client

Referring to the Tech Advisory below,

suppose on our network/setup, we only have NTP & DNS clients connecting
to external DNS & NTP servers, are we at risk?

Or this advisory is more applicable in the situation where we have UDP
servers (say NTP & DNS servers in our network provide NTP/DNS services
to external parties)?  

Or this risk is present at both UDP servers & UDP clients?  If so, is the
risk higher at the servers or clients' end?

Question from our management:
Have our network implemented ingress filtering as per open source tools from the
Spoofer Project (as a way of Source IP Verification) ?  I don't quite understand this.
Can elaborate & point me to some links that explain further.
I guess the concern is: the attacks come from spoofed (ie 'fake')  IP addresses
that are external to our network & we need means to ascertain the external
IPs (eg: the external DNS & NTP sources that we use) are 'genuine', is this right?

National Cyber Awareness System:
TA14-017A: UDP-based Amplification Attacks
01/17/2014 03:22 PM EST

Original release date: January 17, 2014 | Last revised: February 09, 2014
Systems Affected
Certain UDP protocols have been identified as potential attack vectors:
•      DNS
•      NTP
•      SNMPv2
•      NetBIOS
•      SSDP
•      CharGEN
•      QOTD
•      BitTorrent
•      Kad
•      Quake Network Protocol
•      Steam Protocol
A Distributed Reflective Denial of Service (DRDoS) attack is an emerging form of Distributed Denial of Service (DDoS) that relies on the use of publicly accessible UDP servers, as well as bandwidth amplification factors, to overwhelm a victim system with UDP traffic.
UDP, by design, is a connection-less protocol that does not validate source IP addresses.  Unless the application-layer protocol uses countermeasures such as session initiation, it is very easy to forge the IP packet datagram to include an arbitrary source IP address [7].  When many UDP packets have their source IP address forged to a single address, the server responds to that victim, creating a reflected Denial of Service (DoS) Attack.
Recently, certain UDP protocols have been found to have particular responses to certain commands that are much larger than the initial request.  Where before, attackers were limited linearly by the number of packets directly sent to the target to conduct a DoS attack, now a single packet can generate tens or hundreds of times the bandwidth in its response.  This is called an amplification attack, and when combined with a reflective DoS attack on a large scale it makes it relatively easy to conduct DDoS attacks.  
To measure the potential effect of an amplification attack, we use a metric called the bandwidth amplification factor (BAF).  BAF can be calculated as the number of UDP payload bytes that an amplifier sends to answer a request, compared to the number of UDP payload bytes of the request.
The list of known protocols, and their associated bandwidth amplification factors, is listed below.  US-CERT would like to offer thanks to Christian Rossow for providing this information to us.
Protocol      Bandwidth Amplification Factor      Vulnerable Command
DNS      28 to 54      see: TA13-088A [1]

NTP      556.9      see: TA14-013A [2]

SNMPv2      6.3      GetBulk request
NetBIOS      3.8      Name resolution
SSDP      30.8      SEARCH request
CharGEN      358.8      Character generation request
QOTD      140.3      Quote request
BitTorrent      3.8      File search
Kad      16.3      Peer list exchange
Quake Network Protocol      63.9      Server info exchange
Steam Protocol      5.5      Server info exchange
Attackers can utilize the bandwidth and relative trust of large servers that provide the above UDP protocols to flood victims with unwanted traffic, a DDoS attack.


Detection of DRDoS attacks is not easy, due to their use of large, trusted servers that provide UDP services.  As a victim, traditional DoS mitigation techniques may apply.
As a network operator of one of these exploitable services, look for abnormally large responses to a particular IP address.  This may indicate that an attacker is using your service to conduct a DRDoS attack.

Source IP Verification
Because the UDP requests being sent by the attacker-controlled clients must have a source IP address spoofed to appear as the victim’s IP, the first step to reducing the effectiveness of UDP amplification is for Internet Service Providers to reject any UDP traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force (IETF) released Best Current Practice 38 document in May 2000 and Best Current Practice 84 in March 2004 that describes how an Internet Service Provider can filter network traffic on their network to reject packets with source addresses not reachable via the actual packet’s path [3][4].  The changes recommended in these documents would cause a routing device to evaluate whether it is possible to reach the source IP address of the packet via the interface that transmitted the packet. If it is not possible, then the packet most likely has a spoofed source IP address. This configuration change would substantially reduce the potential for most popular types of DDoS attacks. As such, we highly recommend to all network operators to perform network ingress filtering if possible.  Note that it will not explicitly protect a UDP service provider from being exploited in a DRDoS (all network providers must use ingress filtering in order to completely eliminate the threat).

To verify your network has implemented ingress filtering, download the open source tools from the Spoofer Project [5].

Traffic Shaping
Limiting responses to UDP requests is another potential mitigation to this issue.  This may require testing to discover the optimal limit that does not interfere with legitimate traffic.  The IETF released Request for Comment 2475 and Request for Comment 3260 that describes some methods to shape and control traffic [6] [8].  Most network devices today provide these functions in their software.
•      [1] DNS Amplification Attacks
•      [2] NTP Amplification Attacks Using CVE-2013-5211
•      [3] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
•      [4] Ingress Filtering for Multihomed Networks
•      [5] The Spoofer Project
•      [6] An Architecture for Differentiated Services
•      [7] SIP: Session Initiation Protocol
•      [8] New Terminology and Clarifications for Diffserv
Revision History
•      January 17, 2014 - Initial Release
  • 7
  • 6
  • 5
  • +4
10 Solutions
sunhuxAuthor Commented:
Since DNS is Tcp53 & Udp53, can we just make use of
Tcp53 and not use Udp53 so that this UDP risk is not

For NTP, as it only uses Udp (port 123), guess we don't
have any other alternative or can we request our ISPs to
provide NTP on some other UDP ports (say high UDP ports)?
Giovanni HewardCommented:
To primary issue with DDoS amplification attacks relating to this advisory, is that if you're hosting vulnerable services (an open DNS resolver, for example), those services may be used to attack a third party.  An attacker (for example) could spoof the source IP address and using a 64 byte query create a 3,223 byte response.  In other words, an attacker is able to achieve a 50x amplification over whatever traffic they can initiate to your open DNS resolver.  Put another way, if you have a 50MB pipe, an attacker need only to direct 1MB in ongoing requests to your vulnerable service(s) to consume your bandwidth and direct 50MB of traffic toward their intended target (who'll trace the attack to your systems.)  In this example-- implementing BCP 38 will reduce spoofed packet DDoS attacks.  

If the vulnerable service itself is unnecessary then disable it.  If necessary, then effective mitigation techniques will need to be implemented, per the advisory and other industry best practices.  

Changing the port is security through obscurity and not recommended.  An attacker need only scan your IP net range to include all 65,535 ports to discover and leverage the vulnerable services discovered.    In addition, changing assigned well known ports will likely break the majority of software used to communicate with those services, as the port/protocol is assumed and often hard coded in the OS and other applications.

You can transfer this risk by disabling your own NTP server(s) (for example) and use a third party system, preferable ones implementing mitigation techniques.  An additional benefit to this strategy may be higher availability and redundancy.

sunhuxAuthor Commented:
What kind of mitigating measures are in place at  *
NTP servers?

Is there any equivalent DNS servers out there with mitigating measures
in place?

Will still need help to explain on Q4
Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

sunhuxAuthor Commented:
Are the mitigating measures in place at  *  
IETF BCP84 & BCP38  ie what's described at the links below?  and

So by "ingress filtering", it refers to the above two measures?

Last question:
Can I safely say that since the us ntp servers at
has those mitigating measures in place, then the ones at my
country (where xx is my country) should have the same measures ?
mitigation measure is to set "noquery" in default ntp access list (an not serve strangers unless you really want to(

No you dons disable NTP/UDP because 99% of clients (read windows) have no clue of DNS/TCP
You need to restrict recursive resolvers to your site (in RFC sense)
Chris DentPowerShell DeveloperCommented:
You ask this later, addressing it first before looping back and adding my opinion on the first set.

> Are the mitigating measures in place at  *  
> IETF BCP84 & BCP38  ie what's described at the links below?

That pool consists of many different, independent, organisations. It is not going to be possible to answer that question, for a start the organisations in question may not even with to divulge details of their defences.

It is not your responsibility to make sure they are unable to act as amplifiers. You have no ability to influence that whether you happen to use them as a service or not.

Back to the original:

There are three parties involved in an amplification / reflection attack.

1. The attacker
2. The amplifier
3. The victim

If you're the victim of this kind of attack the mitigation is likely to take the form of a clean-and-forward service. It's almost certainly unreasonable to expect you to be able to handle that yourself as you would need to be working on the Internet backbone. If that were the case you wouldn't be here asking this (I hope!) :)

If, on the other hand, you're in the position of being an amplifier you must take steps to secure your services to prevent abuse.

In that instance you are only remotely interesting if you present an exposed, unsecured, server-based service (such as a publicly accessible open DNS resolver). This is where reverse path verification and being able to detect spoofing is important.


As victim: Irrelevant, those services are not the target. Your ability to provide services (not limited to those) is.
As amplifier: The external DNS servers are the risk. If those aren't yours you have no exposure.


As victim: Irrelevant. See above.
As amplifier: Server only. A client cannot amplify, it does not exist to respond to external clients.


As victim: Still irrelevant. You could be running anything, as long as your connection can be swamped you're a potential target.
As amplifier: Just servers. Clients are not relevant as they are not generally capable of being amplifiers, nor are they generally accessible.


As victim: Irrelevant again. This is only applicable if you're protecting a potential amplifier.
As amplifier: Steps should be taken to reduce the likelihood of your UDP based service responding to spoofed IP addresses. So yes, you should attempt to ensure the requesting client is somewhat real.


Jan SpringerCommented:
With DNS, if you have a CPE or server that answers queries from any source, then you are part of the problem.

If you are an NTP server that answers queries from any source, then you are part of the problem.

If you are an NTP client that responds to certain queries, then you *may* be part of the problem.
NTP - if you answer multiple packets to single UDP request you are a problem (namely monl/peer responses can stretch in 100s of packets)
Chris DentPowerShell DeveloperCommented:
The degree of exposure remains important. You would struggle to act as an amplifier for a DDoS attack (like those that make the news) if your service is internal only.

It's not inconceivable of course, but exposure is significantly reduced if you don't allow public access to a service from "any".

Brian UtterbackPrinciple Software EngineerCommented:
If you are a NTP client, you may still be a problem. However, if you are *only* a client and no other system queries your system to get time and your system only has a handful if servers configured (single digits) then you should be a problem. The amplification attack involves sending a query to to NTP server asking for a list of clients. If you have no clients the list can fit in a single packet and no amplification has occurred.
Since one who sends 1 forged query can send 1000 of those amplification is set up in 1/100th of second
btanExec ConsultantCommented:
The DDoS effect is mainly on open and unprotected server which the service I  this case ntp or dns are available to others system to query and get response.

The client can be the attacker though spoofing the source to be specific victim servers exposed through the open. So with more of such client engaged, the reflected amplification can increased even further.

You can catch this recent case on ntp amplification..

The spoofer project FAQ should help explaining the intent and objective. The spoofer client program does nothing more than send various sequences of spoofed-source IP packets and confers with our server to determine which packets were received or lost. Actually it isjust saying whether source filtering policy in place is effectiveand the project is  collecting and showing stats...anything more did not benefit individual bjt more of wider appreciation on current Isp and internet filtering and spoofed ip check capability.

Whether udp or tcp, both are attackable and of course tcp based service is mostly handled based on the state of connection and mitigation typically are available in the perimeter network security devices lr server already like syn cookie while udp based such as icmp or ping flood can be stopped if those are already not allowed by default. It also depends on the service reliability that you need to ensure as business value drive security policy, tends not to be vice versa.
sunhuxAuthor Commented:
If I'm an NTP/DNS client, how can I verify/test that
my NTP/DNS provider's NTP/DNS services have
anti-spoofing measures in place?  Any freeware
tool / easy tests I can perform?
btanExec ConsultantCommented:
the spoofer project is supposed to do it as the client program is "spoofing" the client source ip as it state in its website

Maybe also the check on RFC 2267

While the filtering method discussed in this document does
   absolutely nothing to protect against flooding attacks which
   originate from valid prefixes (IP addresses), it will prohibit an
   attacker within the originating network from launching an attack of
   this nature using forged source addresses that do not conform to
   ingress filtering rules. All providers of Internet connectivity are
   urged to implement filtering described in this document to prohibit
   attackers from  using forged source addresses which do not reside
   within a range of legitimately advertised prefixes.  In other words,
   if an ISP is aggregating routing announcements for multiple
   downstream networks, strict traffic filtering should be used to
   prohibit traffic which claims to have originated from outside of
   these aggregated announcements.

As mentioned previously, while ingress traffic filtering drastically
   reduces the success of source address spoofing, it does not preclude
   an attacker using a forged source address of another host within the
   permitted prefix filter range. It does, however, ensure that when an
   attack of this nature does indeed occur, a network administrator can
   be sure that the attack is actually originating from within the known
   prefixes that are being advertised. This simplifies tracking down the
   culprit, and at worst, the administrator can block a range of source
   addresses until the problem is resolved.

This is an old article which you may find it useful. Though not necessary on IP spoofed but as a whole spoofed packet injection

 Here are a few tips for comparing packet traces by hand:

Spoofed packets may correspond to protocol errors or extreme delays reported or observed in application software; for example, if a client program gives an error like "Connection reset by peer", "Connection closed by foreign host", "Lost connection", etc., or data rates suddenly drop, packet spoofing may have occurred. Noting the timing of suspicious errors may provide guidance for where to look for spoofed packets in a packet trace file.

Spoofed packets used to disrupt connections are often TCP segments with the FIN or RST flags set (also known as "FIN packets" and "RST packets"); each of these flags indicates that a computer does not want to continue a TCP conversation. Wireshark can be configured to color these packets differently so that they stand out in a packet display. Keep in mind that there are legitimate uses for FIN and RST packets within the TCP standards and that the presence of forged FIN or RST packets, not the presence of such packets generally, is suspicious. (A client software or firewall bug, for example, could cause one end of a connection to disconnect prematurely - but that isn't the ISP's fault!)

EFF is developing a tool called pcapdiff to help automate the process of comparing large pcap trace files that were made simultaneously at each end of a connection. This automation makes it easier to find packet spoofing or tampering when one doesn't know what to look for ahead of time and could make the comparison process less tedious (considering that many communications involve thousands of packets or more, and not all tampering will have results as obvious as TCP RST injection). The pcapdiff program is a command-line utility written in Python which requires exactly two pcap packet traces; it automatically compares them to find discrepancies indicating dropped and spoofed packets.
Why should you care about your providers DNS/NTP services? They inpact you as much/little as  any of a million of DNS and 100s of thousands NTP servers out there that you cannot fix.
Chris DentPowerShell DeveloperCommented:
> Any freeware tool / easy tests I can perform?

Please be aware that if you do not have permission to do this you put yourself at risk as you will be (effectively) attacking their systems.

I said this above and I believe it is still pertinent:

That [US NTP] pool consists of many different, independent, organisations. It is not going to be possible to answer that question, for a start the organisations in question may not even with to divulge details of their defences.

It is not your responsibility to make sure they are unable to act as amplifiers. You have no ability to influence that whether you happen to use them as a service or not.
You can extend this to any public service you may use (free or otherwise).

If this lack of visible security on the part of the service providers is problematic you can, in almost all cases, stop using them. Of those protocols listed only DNS and NTP are common Internet services and only DNS must use external services (at some point).

For DNS, run your own secured recursive resolver (don't forward to untrusted parties). If it's not publicly available it can only be abused by those inside your network. Implement whatever additional security on that system you wish to give you peace of mind. It is impossible to assure that your DNS server will never use another which is a possible amplifier (you'd have to secure every authoritative server in the world).

For NTP, you could buy a hardware time-source, plug it in and establish your own internal, private, stratum 1 time server.

This does not prevent you being the victim of an attack, but you are not contributing and are unlikely to be using services that may contribute.

What, as a client, are you expecting to achieve or prove?

sunhuxAuthor Commented:
> What, as a client, are you expecting to achieve or prove?
To verify I have a reliable provider ie my NTP/DNS provider
has spoof mitigating measures in place & my provider has
very low risk of becoming an amplification attack
sunhuxAuthor Commented:
I can then select low-risk provider if my current provider
does not implement Best Current Practices
sunhuxAuthor Commented:
Can the above tools be used to do the test?
Chris DentPowerShell DeveloperCommented:
Not by you without express / explicit permission from the service provider. Using a service does not grant you the right to execute scans against them.

If you need to know for your own compliance reasons, you must talk to your provider.
Sending 2 packets to each service in own name is not a scan...
/usr/sbin/ntpdc -c peer
/usr/sbin/ntpdc -c monl
If they respond they are vulnerable (these dont)
(for windows: ntpc.exe is in meinberg distribution)

Since your DNS provider allows recursive queries from you you cannot check.
Does not hurt to ask if thay implement RFC3013 4.5 for you (since you are paying customer i dont see reasons they dont answer)
Netalyzr (the online service at berkeley uni) will tell a word or two about your network quality.
Chris DentPowerShell DeveloperCommented:
Agreed, the commands above are very unlikely to upset anyone. However, this only shows they've taken steps to sensibly configure the NTP service, it doesn't show whether or not anti-spoofing measures are in place.

Tests designed to trigger anti-spoofing measures should be avoided without very clear permission from the service owner. For all they know you might performing reconnaissance for a planned attack.

I shall leave it alone though, my closing advice remains that if you are unsure about the security of the services you do one of the following:

1. Implement your own closed / protected services.
2. Contact the provider and ask (either for permission to test, or for a statement of compliance).
3. Find a provider that clearly states it has the protective measures you want in place and use them instead.

Nothing forbids you drom forging source of packets. Windows shops do it all the time, so nobody will notice unless you mount the attack...
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Choose an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

  • 7
  • 6
  • 5
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now