This article is intended only for technical support agents and IT professionals. If you're looking for help for a problem, please ask the Microsoft Community.

Introduction

The purpose of this article is to provide guidance for how to reduce the User Datagram Protocol (UDP) amplification attack surface. This article includes the following information:

  • Overview of UDP and UDP amplification attacks.

  • How to configure an Azure Network Security Group (NSG) for least privilege internet access for ports and protocols.

  • How to configure services to remove the UDP amplification attack surface if the port is required for Recursive Domain Name Service (DNS) or Network Time Protocol (NTP) servers.

  • How to run an Nmap scan for verification of the NSG configuration.

Users should follow the guidance in this article to close inbound UDP connections to reduce the attack surface.

Summary

User Datagram Protocol (UDP) is a connection-less protocol. When UDP is allowed inbound access to your Azure cloud services, it creates an attack surface that can be used for a distributed reflective denial-of-service (DRDoS) against virtual machines (VMs). The UDP-based amplification attack is a form of a distributed denial-of-service (DDoS) attack that relies on publicly accessible UDP services and bandwidth amplification factors (BAFs) to overwhelm a victim’s system with UDP traffic.

Note By default, if you have created an NSG, the configuration closes all ports, including UDP. Additionally, Azure has DDOS protection on the platform level. Therefore, users can also add DDOS on their service layer.

To learn more about this kind of attack, see https://www.us-cert.gov/ncas/alerts/TA14-017A.

The UDP-based amplification attack is a form of a distributed denial-of-service (DDoS) attack

The following common ports are often used as part of these UDP reflection attacks: 17 (QOTD), 19 (CharGEN), 53 (DNS), 69 (TFTP), 123(NTP), 161 (SNMP), 389 (CLDAP), 1900 (SSDP), 9987 (DSM/SCM Target Interface), 11211 (Memcached). Users should assess whether they must publicly expose these ports to the internet, and then close all UDP ports that are not absolutely necessary. In particular, users who have to have inbound UDP for port 53 (DNS) or port 123 (NTP) should have the vulnerable configurations (as listed in this article) removed. This is because these two ports are used extensively for this type of attack.

Protocol

UDP port

Vulnerable configuration

DNS

53

Recursive DNS open to the public internet

NTP

123

Enabled Open query and monlist commands

Recommended action

The following steps help mitigate the effect of the attack on UDP:

  1. Evaluate the need for which services have to be exposed to the internet, determine which inbound UDP ports are absolutely necessary for correct service operation, and close all non-essential UDP ports.

  2. Users who must have the UDP ports be open can refer to specific sections of this article for recommendations that are related to NTP and DNS listening on UDP ports. For all other ports, follow the UDP Ports to close section.

The monlist service in NTP provides the ability to run queries for debugging information and should only be temporarily enabled for debugging a service issue. It can also be used to undertake UDP reflection attacks. In NTP Daemon (NTPD) packages older than 4.2.8, this service is enabled by default.  Users should follow this guidance:

  • Users who require monlist should configure an NSG to allow access to only required IP addresses.

  • Users who do not require monlist  and are running Linux NTPD packages older than version 4.2.8 should update the package to a current version and make sure that monlist is not enabled. Users who cannot update the package to a newer version will Have to configure the service by using the  following remediation steps:

  1. Check for the version of the NTPD package:

#sudo -i ntpq -c rv

  1. If the version of the NTPD package is earlier than 4.7p26, follow these steps:

#vi /etc/ntp.conf

  1. If they do not already exist, add these lines:

restrict -4 default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

  1. Restart the NTP service:

# service ntp restart [Debian/ Ubuntu]

# service ntpd restart [Redhat/ Centos]

Note 1: If you installed the NTPD package on Windows, and you have open ports, you will have to follow the steps for remediation action.

Note 2: See https://www.us-cert.gov/ncas/alerts/TA14-013A for more details.

Note 3: Regular NTP packets that are used for time sync (mode 3 and mode 4) are not affected. This means that it is safe to sync time and for a server to serve only time.

Running a DNS recursive resolver open to the internet can cause a UDP attack against a user's own service and those of other users. Users should evaluate whether they actually must have a DNS service running. If they do not, they should either deny all access to Port 53 or uninstall the DNS service by following the instructions that are specific to their operating system and DNS implementation.

User who do require a DNS service to be running to provide authoritative name resolution but who do not require DNS recursion should disable this feature by following the instructions that are specific to their operating system and DNS implementation (as provided later in this article). Additionally, we strongly recommended in all cases that access to Port 53 in your NSG be restricted to the specific set of IP addresses that are required to operate your service by having the least privileges.

Windows: Disable DNS recursive resolver setting on DNS Server for Windows server 2012, 2016

  1. Open DNS Manager (select Start, point to Administrative Tools, and then select DNS).

  2. In the console tree, right-click the applicable DNS server, and then select Properties.

  3. Select the Advanced tab.

  4. In Server options, make sure that the Disable recursion check box isselected.

  5. Restart the DNS service (from the Services control panel).

Linux: Disabling DNS recursion on your Bind server

  1. Connect to your server through SSH (Secure Shell) by using your root credentials.

  2. After you connect to your server, check your named.conf file for any DNS recursion, and investigate the settings:

    cat /etc/named.conf | grep "recursion"

  3. Open your named.conf file by using any text editor, and check the settings for recursion by using the following command:

    #vi /etc/named.conf

  4. Change the settings for external DNS recursion only, and locate the section that is named “external.” If the section is not available, you can add the following lines to your named.conf file to disable the external DNS recursion. Put the following lines in the “options” section:

    allow-transfer {"none";};

    allow-recursion {"none";};

    recursion no;

    If you already have the external section, you can change its settings by changing the recursion value to yes or no, depending on your needs.

  5. After configuring your changes, save the file.

  6. Restart the DNS server for the changes to take effect. Run the following command to restart your DNS service:

    service named restart

    Note: If you are using any other proprietary DNS server, refer to respective product documentation to disable DNS recursive setting.

Users should close high-risk inbound UDP ports by following the guidance in this section. We recommended that users close inbound connections from the internet on all UDP ports.

Users who must open a specific UDP port to the internet should open that port only and reastrict inbound access to those IP ranges that are strictly necessary (that is, do not expose UDP ports to the entire internet).

To close the UDP ports, users can take either or both of the following actions:

  • Update their ARM template to disable inbound UDP. This requires NSG template redeployment. However, it makes sure that future deployments that use this template will have the correct security settings.

  • Update the NSG rules to restrict network access. See Azure Portal, Azure Powershell, Azure CLI.

Resources: Information on NSGs , Manage Network Security Group (NSG)

Check for open UDP ports to the internet

Users should verify that services are configured to disallow the UDP inbound connections by reviewing their NSG rules, following the guidance that is found in How to Manage NSGs. Users can also run an external Nmap scan to verify that UDP ports are closed correctly.

Steps to complete an Nmap scan

Important: Users should scan only within their own IP address ranges to make sure that other users are not affected by following the Penetration Testing Rule of Engagement and also to make sure that the scan complies with the Microsoft Online Service Terms.

  1. Install Nmap.

  2. Check the firewall settings to make sure that you are allowing outbound UDP traffic to run the scan.

  3. Follow the Nmap instructions in this section about how to perform a scan. Users can also use the Zenmap GUI (the icon is installed on the desktop when Windows Nmap is installed).

    1. Create a .csv file that has a list of IP addresses to scan for a specific port (for example, Port 69).

    2. Run the Nmap command. You can include these options: -sUV (UDP ports) -T4 -p {port to scan} -Pn {treat all hosts as online} -iL {input list} -oL {output list} & (optional flag to run in background):

      nmap -sUV -T4 -Pn -p 69 -iL filename.csv -oX filename.xml &

    3. Check the ports that are most commonly used in reflection attacks:

      nmap -sUV -T4 -Pn -p17,19,53,69,111,123,137,161,389,1900,5353,11211 -iL filename.csv -oX filename.xml &

    4. Review the results to identify any open ports.

  1. Install Nmap through the package manager or from https://nmap.org/download.html.

Ubuntu / Debian :

sudo apt-get update
sudo apt-get install nmap

Redhat / CentOS:

yum update
yum install nmap [Redhat/ Centos]

  1. Use the following Nmap commands to verify known UDP ports:

    1. Create a .csv file that includes a list of IP addresses to scan for a specific port (for example, Port 69).

    2. Upload the .csv file to your Linux VM by using the pscp command:

      pscp filename.csv admin@remotehost:filename.csv

    3. Run the sudo nmap command including the options -sUV (UDP ports) -T4 -p {port to scan} -Pn {treat all hosts as online} -iL {input list} -oL {output list} & (optional flag to run in background):

      sudo nmap -sUV -T4 -Pn -p 69 -iL filename.csv -oX filename.xml &

    4. Check the ports that are most commonly used in reflection attacks:

      sudo nmap -sUV -T4 -Pn -p17,19,53,69,111,123,137,161,389,1900,5353,11211 -iL filename.csv -oX filename.xml &

    5. When the process is finished, download the file by using pscp command.

    6. Review the results to identify any open ports.

Examples of Nmap scans

Note: If you plan to automate the scanning process by using the commands in these examples, be aware that UDP scans can take a long time to run because the scanner must sometimes wait to detect whether traffic is returned (this is not guaranteed). For best performance, create a scan for each port.

Run a Windows scan from the command line by having all ports closed.

Note Because this is an Nmap UDP scan, "open|filtered" can be interpreted as "closed."

The following command runs a Windows scan:

C:\Users\user\DeskTop>nmap -sUV -T4 -Pn -p17,19,53,69,111,123,137,161,389,1900,5353,11211 23.36.53.224

Windows nmap scan

Run a Linux scan for 1.1.1.1 by having DNS open. Notice that DNS port 53 does not say "open|filtered" because this would indicate that the port is closed. However, the other ports are shown as "open|filtered." This indicates that they are closed.

The following command runs a Linux scan:

testuser@testUbuntu:~$ sudo nmap -sUV -T4 -Pn -p17,19,53,69,111,123,137,161,389,1900,5353,11211 1.1.1.1

Linux nmap scan

Additionally, run the following scripts to check whether the services on Ports 53, 123, and 389 are misconfigured.

For Linux users, each command must be proceeded by sudo.

To scan for open DNS recursive resolvers:

nmap -sUV -Pn -T4 -p 53 --script=dns-recursion -iL <input_file> -oX <output_file>

For a single IP address:

nmap –sU –p53 –script=dns-recursion <Public IP address>

NTPD package versions that are earlier than 4.2.8 are vulnerable to UDP reflection attacks through a monlist command. If “restrict noquery” is configured, a monlist reflection attack would not work.

Nmap script to identify the vulnerability:

nmap -sUV -Pn -T4 -p 123 --script= ntp-monlist -iL <input_file> -oX <output_file>

For a single IP address:

nmap -sU -pU:123 -Pn -n --script=ntp-monlist <Public IP address>

nmap -sU -p389 -v -n -Pn <Public IP address>

Show Publicly exposed LDAP information:

nmap -p 389 --script ldap-rootdse <Public IP address>

Frequently asked questions

This is not a recommended configuration. However, if the user has a dependent service, they should add additional security by using signing per the following guidance:

Users should use the following documents for how to configure Time Sync for their Azure VMs. If the user uses a vulnerable package for Linux or Windows NTPD, they should update to the current version.

No. These are the standard ports for the UDP services. However, either the services can be listening on another port number or the server can exist behind a load balancer that port forwards from another source port.

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

What affected your experience?

Any additional feedback? (Optional)

Thank you for your feedback!

×