sunhux
asked on
UDP Distributed Reflective Denial of Service (DRDoS) : server or client
Referring to the Tech Advisory below,
Q1:
suppose on our network/setup, we only have NTP & DNS clients connecting
to external DNS & NTP servers, are we at risk?
Q2:
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)?
Q3:
Or this risk is present at both UDP servers & UDP clients? If so, is the
risk higher at the servers or clients' end?
Q4:
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
Overview
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.
Description
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
Impact
======
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.
Solution
=======
DETECTION
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.
MITIGATION
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.
References
• [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
Q1:
suppose on our network/setup, we only have NTP & DNS clients connecting
to external DNS & NTP servers, are we at risk?
Q2:
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)?
Q3:
Or this risk is present at both UDP servers & UDP clients? If so, is the
risk higher at the servers or clients' end?
Q4:
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
Overview
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.
Description
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
Impact
======
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.
Solution
=======
DETECTION
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.
MITIGATION
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.
References
• [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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
What kind of mitigating measures are in place at *.us.pool.ntp.org
NTP servers?
Is there any equivalent DNS servers out there with mitigating measures
in place?
Will still need help to explain on Q4
NTP servers?
Is there any equivalent DNS servers out there with mitigating measures
in place?
Will still need help to explain on Q4
ASKER
Are the mitigating measures in place at *.us.pool.ntp.org
IETF BCP84 & BCP38 ie what's described at the links below?
http://tools.ietf.org/html/bcp38 and https://tools.ietf.org/html/bcp84
So by "ingress filtering", it refers to the above two measures?
Last question:
Can I safely say that since the us ntp servers at X.us.pool.ntp.org
has those mitigating measures in place, then the ones at my
country (where xx is my country) should have the same measures ?
0.xx.pool.ntp.org
1.xx.pool.ntp.org
2.xx.pool.ntp.org
IETF BCP84 & BCP38 ie what's described at the links below?
http://tools.ietf.org/html/bcp38 and https://tools.ietf.org/html/bcp84
So by "ingress filtering", it refers to the above two measures?
Last question:
Can I safely say that since the us ntp servers at X.us.pool.ntp.org
has those mitigating measures in place, then the ones at my
country (where xx is my country) should have the same measures ?
0.xx.pool.ntp.org
1.xx.pool.ntp.org
2.xx.pool.ntp.org
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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)
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".
Chris
It's not inconceivable of course, but exposure is significantly reduced if you don't allow public access to a service from "any".
Chris
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Since one who sends 1 forged query can send 1000 of those amplification is set up in 1/100th of second
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
my NTP/DNS provider's NTP/DNS services have
anti-spoofing measures in place? Any freeware
tool / easy tests I can perform?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
> 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
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
ASKER
I can then select low-risk provider if my current provider
does not implement Best Current Practices
does not implement Best Current Practices
ASKER
http://spoofer.cmand.org/software.php
Can the above tools be used to do the test?
Can the above tools be used to do the test?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Nothing forbids you drom forging source of packets. Windows shops do it all the time, so nobody will notice unless you mount the attack...
ASKER
Since DNS is Tcp53 & Udp53, can we just make use of
Tcp53 and not use Udp53 so that this UDP risk is not
there?
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)?