[lacnog] Fwd: TA14-017A: UDP-based Amplification Attacks
Eduardo A. Suárez
esuarez en fcaglp.unlp.edu.ar
Dom Feb 9 19:27:45 BRST 2014
----- Mensaje reenviado de US-CERT en ncas.us-cert.gov -----
Fecha: Sun, 09 Feb 2014 12:24:54 -0600
De: US-CERT <US-CERT en ncas.us-cert.gov>
Responder-A: US-CERT en ncas.us-cert.gov
Asunto: TA14-017A: UDP-based Amplification Attacks
Para: root en fcaglp.fcaglp.unlp.edu.ar
NCCIC / US-CERT
National Cyber Awareness System:
TA14-017A: UDP-based Amplification Attacks [
https://www.us-cert.gov/ncas/alerts/TA14-017A ] 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* DNS28
to 54see: TA13-088A [ http://www.us-cert.gov/ncas/alerts/TA13-088A
] [1] NTP556.9see: TA14-013A [
http://www.us-cert.gov/ncas/alerts/TA14-013A ] [2] SNMPv26.3GetBulk
request NetBIOS3.8Name resolution SSDP30.8SEARCH 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 [
http://spoofer.cmand.org/index.php ] [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 [
http://www.us-cert.gov/ncas/alerts/TA13-088A ]
* [2] NTP Amplification Attacks Using CVE-2013-5211 [
http://www.us-cert.gov/ncas/alerts/TA14-013A ]
* [3] Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing [
http://tools.ietf.org/html/bcp38 ]
* [4] Ingress Filtering for Multihomed Networks [
http://tools.ietf.org/html/bcp84 ]
* [5] The Spoofer Project [ http://spoofer.cmand.org/index.php ]
* [6] An Architecture for Differentiated Services [
http://tools.ietf.org/html/rfc2475 ]
* [7] SIP: Session Initiation Protocol [
http://tools.ietf.org/html/rfc3261 ]
* [8] New Terminology and Clarifications for Diffserv [
http://tools.ietf.org/html/rfc3260 ]
Revision History
* January 17, 2014 - Initial Release
________________________________________________________________________
This product is provided subject to this Notification [
http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [
http://www.us-cert.gov/privacy/ ] policy.
________________________________________________________________________
OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] |
Security Publications [ http://www.us-cert.gov/security-publications ]
| Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources
[ http://www.us-cert.gov/related-resources ]
STAY CONNECTED: Sign up for email updates [
http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ]
SUBSCRIBER SERVICES:
Manage Preferences [
http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ] | Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.c7fb9ceed3d76bfcc21d69fb25950a45&destination=root@fcaglp.fcaglp.unlp.edu.ar ] | Help [ https://subscriberhelp.govdelivery.com/
]
________________________________________________________________________
This email was sent to root en fcaglp.fcaglp.unlp.edu.ar using
GovDelivery, on behalf of: United States Computer Emergency Readiness
Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 ·
(703) 235-5110 Powered by GovDelivery [
http://www.govdelivery.com/portals/powered-by ]
----- Terminar mensaje reenviado -----
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
------------ próxima parte ------------
NCCIC / US-CERT
National Cyber Awareness System:
TA14-017A: UDP-based Amplification Attacks [ https://www.us-cert.gov/ncas/alerts/TA14-017A ] 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* DNS28 to 54see: TA13-088A [ http://www.us-cert.gov/ncas/alerts/TA13-088A ] [1] NTP556.9see: TA14-013A [ http://www.us-cert.gov/ncas/alerts/TA14-013A ] [2] SNMPv26.3GetBulk request NetBIOS3.8Name resolution SSDP30.8SEARCH 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 [ http://spoofer.cmand.org/index.php ] [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 [ http://www.us-cert.gov/ncas/alerts/TA13-088A ]
* [2] NTP Amplification Attacks Using CVE-2013-5211 [ http://www.us-cert.gov/ncas/alerts/TA14-013A ]
* [3] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing [ http://tools.ietf.org/html/bcp38 ]
* [4] Ingress Filtering for Multihomed Networks [ http://tools.ietf.org/html/bcp84 ]
* [5] The Spoofer Project [ http://spoofer.cmand.org/index.php ]
* [6] An Architecture for Differentiated Services [ http://tools.ietf.org/html/rfc2475 ]
* [7] SIP: Session Initiation Protocol [ http://tools.ietf.org/html/rfc3261 ]
* [8] New Terminology and Clarifications for Diffserv [ http://tools.ietf.org/html/rfc3260 ]
Revision History
* January 17, 2014 - Initial Release
________________________________________________________________________
This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [ http://www.us-cert.gov/privacy/ ] policy.
________________________________________________________________________
OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ http://www.us-cert.gov/related-resources ]
STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ]
SUBSCRIBER SERVICES:
Manage Preferences [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ] | Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.c7fb9ceed3d76bfcc21d69fb25950a45&destination=root@fcaglp.fcaglp.unlp.edu.ar ] | Help [ https://subscriberhelp.govdelivery.com/ ]
________________________________________________________________________
This email was sent to root en fcaglp.fcaglp.unlp.edu.ar using GovDelivery, on behalf of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110 Powered by GovDelivery [ http://www.govdelivery.com/portals/powered-by ]
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20140209/56057596/attachment.html>
Más información sobre la lista de distribución LACNOG