UDP Services Audit: Which UDP Ports to Close and How to Check Yours

A UDP services audit finds every UDP port your hosts answer on and closes or restricts the ones that need not be reachable. Only a few belong on the internet: authoritative DNS, NTP if you serve time, QUIC on 443, and VPN or media endpoints you deliberately run. SNMP, SSDP, memcached, CLDAP and syslog almost never do.

UDP has no handshake, so a server cannot tell whether a request really came from the address in the packet. Any UDP service that answers a small request with a large reply can become a reflector that floods someone else, and any management service that answers strangers leaks information. This post is a defender's checklist for your own network: what the standards say, which ports to close, how to list and verify UDP listeners, and how to restrict DNS, NTP and SNMP when they must stay on.

For protocol basics, read our UDP explainer. For what an eavesdropper can read and change in a UDP header, see TCP vs UDP: what an eavesdropper can see and change. This post is about inventory, exposure and reflection risk.

Key takeaways

• UDP (RFC 768, 28 August 1980) gives you ports, a length and a checksum. It does not guarantee delivery, ordering or duplicate protection, and it does nothing to verify the sender's address.
• RFC 8085 (BCP 145, March 2017) tells application designers that services which answer short requests with large responses "SHOULD take steps to minimize their potential for being abused" and that the source IP address "is not a useful authenticator".
• CISA's alert TA14-017A lists the UDP protocols most abused for reflection, with bandwidth amplification factors from about 2 for mDNS to between 10,000 and 51,000 for memcached.
• Internet-facing by design: authoritative DNS (53), public NTP (123), QUIC and HTTP/3 (443), and VPN or media endpoints you choose to run. Almost never internet-facing: SNMP (161), SSDP (1900), memcached (11211), CLDAP (389), syslog (514), chargen (19), QOTD (17), TFTP (69), portmap (111), NetBIOS (137), mDNS (5353) and WS-Discovery (3702).
• List UDP listeners with ss -ulnp on Linux, Get-NetUDPEndpoint or netstat -ano -p udp on Windows and lsof -nP -iUDP on macOS, then confirm from an outside vantage point that only intended ports answer.
• For services that must stay on: restrict recursion on DNS resolvers (RFC 5358, BCP 140), block NTP control queries from outside (RFC 8633, BCP 223), and replace SNMP community strings with SNMPv3 user based security (RFC 3414).
• BCP 38 (RFC 2827) and BCP 84 (RFC 3704) ingress filtering stop spoofed source addresses leaving your network. They do not stop someone else spoofing your address, which is why closing reflectors on your side still matters.

What UDP is for, where it sits and which documents define it

UDP is a transport layer protocol that runs directly over IP. RFC 768, written by Jon Postel and dated 28 August 1980, defines it in three pages. Its stated purpose is to let application programs send messages to other programs "with a minimum of protocol mechanism". The same paragraph says the protocol is transaction oriented and that "delivery and duplicate protection are not guaranteed", and it points applications that need ordered, reliable streams to TCP.

That is almost the whole contract. UDP gives an application:

• Multiplexing by port. A 16 bit source port and a 16 bit destination port, so many programs on one host can share an IP address.
• A length field. The size of the datagram including the 8 byte header, so the minimum value is 8.
• A checksum. A 16 bit checksum over a pseudo header (addresses, protocol, length), the UDP header and the data. RFC 768 says the pseudo header "gives protection against misrouted datagrams". It catches accidents, not deliberate changes, because anyone who alters a datagram can recompute it.

UDP gives you no connection, retransmission, ordering, congestion control, encryption or sender authentication. Even the source port is optional: if unused, RFC 768 says a value of zero is inserted.

Two newer documents matter for an audit:

• RFC 8085, "UDP Usage Guidelines" (BCP 145, March 2017). It obsoletes RFC 5405 and guides anyone designing an application, tunnel or protocol over UDP. Congestion control is its main subject, but its port and Security Considerations sections speak directly to reflection risk.
• The IANA Service Name and Transport Protocol Port Number Registry. The authoritative list of which service owns which port. The copy fetched for this post was last updated on 22 October 2026. Port numbers are a convention, not enforcement: a process can bind any free port, so an audit looks at what is actually listening.

How UDP works on the wire

The header is 8 bytes and never changes:

There is no session setup and no teardown. A typical request and reply looks like this:

Client 198.51.100.7:53211                 Server 203.0.113.10:53
        |                                          |
        |  UDP datagram: query (small)             |
        |----------------------------------------->|
        |                                          |  server reads the source
        |                                          |  address from the IP header
        |  UDP datagram: answer (often larger)     |  and replies to it
        |<-----------------------------------------|
        |                                          |
   (no handshake, no acknowledgment, no close)

The server trusts the source address in the IP header because it has nothing else to go on. That one design fact explains most of what follows.

Ports and the IANA registry

The registry entries for the services this post covers, checked on the IANA site:

Client side ports are usually drawn from the dynamic range. RFC 8085 describes it as 49152 to 65535, "where the high order two bits of the port are set to one", which is why you will see many short lived high numbered UDP sockets in any listing.

Versions and history

UDP itself has never been revised: RFC 768 from 1980 is still the specification. What has changed is the guidance around it and the defaults of the services that run on it.

Note the pattern. CLDAP was moved toward Historic status in 2003, yet CISA still added it to its amplification list later because directory servers kept answering it. Memcached's UDP listener stayed on by default until the 1.5.6 release notes reported amplification attacks surfacing "in the last few days". Protocols age out of the standards long before they age out of running systems, which is the case for auditing rather than trusting what should be deployed.

Why connectionless protocols enable spoofing and reflection

This is a concept section. It explains why the design allows abuse; it does not describe how to carry it out.

TCP delivers no application data until a three-way handshake proves the client can receive traffic at the address it claims, so a TCP service never sends its real response to a forged address. UDP has no such step. The first datagram can carry a complete request, and the reply goes to whatever source address the IP header carries. CISA's alert puts it plainly: "By design, UDP is a connection-less protocol that does not validate source Internet Protocol (IP) addresses."

That gap produces three related problems:

1. Spoofing. Anyone who can send packets from a network that does not filter forged sources can make a UDP request appear to come from another address.
2. Reflection. The server, acting in good faith, replies to the forged address. The victim receives traffic it never requested, and the traffic comes from your server, not from the real sender.
3. Amplification. If the reply is much larger than the request, each forged byte becomes many bytes at the victim. CISA measures this as the bandwidth amplification factor: the UDP payload bytes an amplifier sends in reply divided by the UDP payload bytes of the request.

The defender's lesson is that your server is the useful part of the attack. You cannot stop a stranger from forging your address somewhere else on the internet, but you can make sure your hosts do not answer strangers with large replies. RFC 5358 says of DNS reflection that the attacks are "not due to any particular flaw in the design of the DNS", except that DNS relies on UDP, "the easy abuse of which is at the source of the problem".

Concept only: why a reflector hurts someone else

  Forged request, source = victim's address
  -----------------------------------------> Your open UDP service
                                                     |
                                                     | Reply goes to the
                                                     | address in the packet
                                                     v
                                               Victim receives traffic
                                               it never asked for,
                                               possibly many times larger

Security properties and known weakness classes

What UDP guarantees and what it does not

RFC 8085's Security Considerations section starts with exactly this: "UDP does not provide communications security", and applications that need protection against eavesdropping, tampering or forgery "SHOULD employ end-to-end security services provided by other IETF protocols". It names IPsec and DTLS, notes that DTLS "does not protect the UDP headers", and recommends well known standard mechanisms "rather than inventing their own".

Weakness classes, as concepts

• Reflection and amplification. Covered above. The weakness is in the combination of an unauthenticated source address and a reply larger than the request. RFC 8085 says such services should consider authenticating the sender before responding, or otherwise limit the cases where short unauthenticated requests produce large responses, and may offer ways to cap the number of responses per time interval.
• Off-path data injection. If an attacker who cannot see your traffic can guess the ports involved, a forged datagram can be accepted as a genuine reply. RFC 8085, section 5.1, says applications should use a randomised source port or an equivalent check, as TCP stacks do. RFC 9109 applied this to NTP in August 2021, recommending ephemeral port randomisation for modes that do not need the well known port.
• Unauthenticated management interfaces. SNMPv1 and v2c communities and NTP control messages (mode 6 and ntpd's mode 7) were designed for trusted networks. Elsewhere they leak configuration and counters, and RFC 8633 notes NTP control responses "are much larger than the corresponding queries", so they amplify too.
• Discovery protocols talking to the world. SSDP, mDNS, NetBIOS name service and WS-Discovery announce a device to its local network. Reachable from the internet, they announce it to everyone.
• Flooding a service that cannot push back. Without a handshake there is no cheap way to reject a source before doing work for it. See whether syslog over UDP is safe for security logs for the logging side.
• State exhaustion in middleboxes. Firewalls and NAT devices keep an entry per UDP flow (see below), and many short flows can fill those tables.

CISA's alert cites NTP amplification tied to CVE-2013-5211, which concerned ntpd's monitoring query. Like the memcached reports of February 2018, it depended on a service answering the internet when it did not need to.

What RFC 8085, BCP 38 and BCP 84 say

RFC 8085 for people who run services

RFC 8085 is written for designers, but three rules translate directly into operating advice:

1. Do not reply big to small, unauthenticated requests. Applications that do "SHOULD take steps to minimize their potential for being abused as part of a DoS attack". For an operator, that means turning off features that produce large unauthenticated replies, or restricting who can ask.
2. Check the sender, not just the port. Section 5.1 says applications "SHOULD implement receiver port and address checks".
3. Use standard security such as DTLS or IPsec rather than inventing one.

It also notes that some operators see UDP attack surges "multiple orders of magnitude above the baseline", which pushes them to rate limit UDP generally. Every UDP service you expose is exposed to that throttling too.

BCP 38 and BCP 84: ingress filtering

RFC 2827 (BCP 38, May 2000) describes ingress filtering to stop forged source addresses leaving the network where they originate: a network edge drops outbound packets whose source address does not belong to the network behind it.

RFC 3704 (BCP 84, March 2004) extends the idea to multihomed networks and defines several reverse path forwarding (RPF) variants:

• Strict RPF. Accept a packet only if it arrived on the interface the router would use to reach its source. RFC 3704 calls this "a very reasonable approach in front of any kind of edge network", but it fails where routing is asymmetric.
• Feasible path RPF. Strict RPF that also accepts alternate paths the router knows about.
• Loose RPF. Accept a packet if any route to its source exists. RFC 3704 notes this "sacrifices directionality", so it only drops sources with no route at all.

On a Linux host or router, the rp_filter sysctl implements these modes, and the kernel documentation describes value 1 as strict mode and value 2 as loose mode "as defined in RFC3704". The documented default is 0, no source validation, though some distributions enable it at boot.

BCP 38 stops your network originating spoofed traffic; it does nothing about someone elsewhere forging your address. RFC 5358 calls ingress filtering "the only real solution" to reflection because it must be deployed everywhere to work. Until it is, closing your reflectors is the part you control.

How stateful firewalls track UDP "connections"

UDP has no connection, so a firewall cannot watch a handshake. RFC 8085, section 3.5, explains what middleboxes do instead: they "create per-flow state when they see a packet that, according to some local criteria, indicates a new flow, and destroy the state after some time during which no packets belonging to the same flow have arrived."

In practice:

1. A host inside sends a UDP datagram out. The firewall records the flow, usually as the pair of addresses and ports.
2. Replies from the outside that match the recorded flow are allowed back in while the entry exists.
3. When no packets have been seen for a timeout period, the entry is deleted. Later replies are dropped, as is any unsolicited traffic from outside.

RFC 8085 notes that "No common timeout has been specified for per-flow UDP state", that NATs require a timeout of 2 minutes or longer per RFC 4787, and that many deployed middleboxes use shorter timeouts. It also says applications that need to keep state alive should not send keep-alives more often than once every 15 seconds.

On Linux, netfilter connection tracking documents two defaults: nf_conntrack_udp_timeout of 30 seconds, and nf_conntrack_udp_timeout_stream of 120 seconds, an extended timeout used when a UDP stream is detected.

Three consequences for an audit:

• A stateful firewall protects clients, not servers. If UDP 161 is allowed in, every source on the internet can start a new flow to SNMP.
• UDP allow rules should name sources. For management protocols, list a handful of collector or monitoring addresses, not "any".
• CISA lists stateful inspection as a mitigation. Its alert recommends "stateful UDP inspections" such as reflexive access lists at the border, which drop datagrams that are not part of a flow your side started.

Which UDP services should face the internet

This is the core of the audit. The table gives a default verdict for each common service. "Internet-facing" means reachable from any source on the public internet, not from a list of partner or monitoring addresses.

The amplification figures are CISA's, taken from TA14-017A. A blank does not mean a protocol cannot amplify; it means CISA did not list it. For the full CISA table and how amplification compares across TCP and UDP, see the TCP vs UDP post.

The ones that are meant to be public

Authoritative DNS. It has to answer anyone; RFC 5358 calls restricting authoritative servers to a subset of the internet "impractical". You control recursion (off) and rate (limited). RFC 5358 also warns that larger DNSSEC and NAPTR answers make authoritative servers better amplifiers over time. See recursive vs authoritative DNS servers for the two roles.

Public NTP. Time service answers anyone; control queries must not. RFC 8633 recommends public-facing servers "block NTP control message queries from outside their organization". Hosts that only keep their own time need no inbound UDP 123. Our posts on NTP stratum, offset and delay and Network Time Security cover accuracy and authenticated time.

QUIC on UDP 443. If you serve HTTP/3, UDP 443 is open. RFC 9000 says that before validating a client's address, servers "MUST NOT send more than three times as many bytes as the number of bytes they have received", the anti-amplification limit. That caps QUIC as an amplifier but does not make implementations bug free; see QPACK amplification on HTTP/3 servers.

VPN, media and telephony edges. IKE, IPsec NAT traversal, OpenVPN, STUN, TURN and SIP belong only on the gateways and relays that run them. UDP 500 or 3478 open on an application server is a finding.

The ones that almost never should be

SNMP (161, 162). SNMPv1 and v2c send the community string in clear, and CISA lists SNMPv2 GetBulk as an amplifier. Keep SNMP on a management network; our SNMP explainer covers versions and setup.

SSDP (1900). A local UPnP discovery protocol. No server or router WAN interface should answer it from the internet.

memcached (11211). The largest factor in CISA's table. Since 1.5.6 (27 February 2018) UDP is off unless enabled "via -U 11211", so finding it means an old version or a deliberate choice. See whether memcached is safe to expose.

CLDAP (389). Defined in RFC 1798 (1995) and recommended for Historic status by RFC 3352 (2003), yet directory servers still answer it. Nothing outside your network should reach UDP 389.

Syslog (514). Registered with a reference to RFC 5426. It is one way, so not a reflector, but an exposed collector accepts forged lines from anyone. Keep collectors internal and use TLS across untrusted networks; see is syslog over UDP safe for security logs.

Legacy and local services. Echo (7), QOTD (17) and chargen (19) are early internet test services; disable them. mDNS (5353), NetBIOS (137) and WS-Discovery (3702) are for the local link; CISA's alert cites CERT/CC's VU#550620 (March 2015) on mDNS implementations answering unicast queries from outside it. Block them at the edge.

Secure configuration, with defender-side check commands

Only run these commands against systems you own or are authorised to test. They read configuration and socket tables, or send ordinary queries to your own addresses. None of them sends forged traffic.

Step 1: list every UDP socket on each host

UDP has no listening state in the TCP sense; a server simply binds a port and waits. The tools below list bound UDP sockets along with the owning process.

Linux, with ss from iproute2. The ss(8) man page documents -u for UDP sockets, -l for listening sockets, -n to skip name resolution and -p to show the owning process.

# All bound UDP sockets with the owning process (root needed to see other users' processes)
sudo ss -ulnp

# Only IPv4 or only IPv6
sudo ss -ulnp -4
sudo ss -ulnp -6

# One port, using the documented port filter syntax
sudo ss -ulnp 'sport = :161'

Read the local address column carefully. A socket bound to 127.0.0.1 or ::1 is reachable only from the host itself. A socket bound to 0.0.0.0, * or [::] accepts datagrams on every interface, which is what you need to justify.

Windows, with PowerShell. Microsoft documents Get-NetUDPEndpoint as getting "current statistics for a UDP endpoint", with -LocalAddress, -LocalPort and -OwningProcess parameters.

# Every UDP endpoint, sorted by port
Get-NetUDPEndpoint | Sort-Object LocalPort

# Endpoints on one port, for example SNMP
Get-NetUDPEndpoint -LocalPort 161

# Endpoints owned by one process ID
Get-NetUDPEndpoint -OwningProcess 1234

Windows, with netstat. The Microsoft Learn reference documents -a for listening ports, -n for numeric output, -o for the process ID and -p with udp or udpv6 to restrict the protocol. -b shows the executable and needs an elevated prompt.

netstat -ano -p udp
netstat -ano -p udpv6
# From an elevated prompt, include the executable name
netstat -anob -p udp

macOS, with lsof. The lsof manual documents -i with a protocol and optional port, -n to skip host name lookups and -P to show port numbers rather than names.

# All UDP sockets with the owning command and PID
sudo lsof -nP -iUDP

# One port
sudo lsof -nP -iUDP:5353

Step 2: map each socket to a reason

For each port not on loopback, record the process, the package or image it came from, and why it must be reachable. Anything without a reason gets stopped or rebound to the one interface that needs it. Short lived high ports owned by clients are usually outbound flows in the 49152 to 65535 dynamic range, not services.

Step 3: verify from outside that only intended ports answer

Inside-out listings show what is bound; outside-in checks show what firewalls and cloud security groups let through. Run these from a host you control outside the network, against public addresses you own, and check your hosting provider's acceptable use terms first.

The Nmap reference guide documents UDP scanning with -sU and version detection with -sV. No response is reported as open|filtered, an ICMP port unreachable as closed, and any UDP response as open; version detection resolves many open|filtered results.

# Only against addresses you own or are authorised to test.
# 203.0.113.10 is a documentation address; replace it with your own.
sudo nmap -sU -p 53,69,111,123,137,161,389,500,514,1900,3702,4500,5353,11211 203.0.113.10

# Add version detection to separate real services from silent filters
sudo nmap -sUV -p 53,123,161,389,1900,11211 203.0.113.10

The guide notes UDP scanning "can be slow", so scan the ports you care about. Then check specific behaviours, again from outside:

# DNS: does your server recurse for strangers?
# dig sets the recursion desired bit by default.
dig @203.0.113.10 example.com A

# NTP: does your server answer mode 6 control queries from outside?
# ntpq's readvar (rv) command sends a mode 6 request; it should time out.
ntpq -c rv 203.0.113.20

An address in the answer section for a name outside your zones means the server recurses for the internet; Unbound documents REFUSED as its default reply to disallowed clients. The ntpq documentation says most control commands "send a single mode-6 message to the server", so a timeout is what you want.

Step 4: check host level anti-spoofing and state tracking on Linux

# Reverse path filtering: 0 off, 1 strict (RFC 3704), 2 loose
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

# UDP connection tracking timeouts (documented defaults 30 and 120 seconds)
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream

The kernel documentation recommends strict mode to prevent spoofing, and loose mode when routing is asymmetric. The conntrack values only exist when the netfilter connection tracking module is loaded.

DNS: closing an open resolver

RFC 5358's recommendation is short: provide recursive service "to only the intended clients", turn recursion off on authoritative only servers, keep recursive and authoritative roles separate where practical, and "By default, nameservers SHOULD NOT offer recursive service to external networks." It lists ways to authorise clients: by source address ACL, by incoming interface, or by TSIG or SIG(0) signed queries.

BIND 9. The reference documents that recursion defaults to yes and, when allow-recursion is unset, allow-query-cache defaults to localnets and localhost. Setting either list to any makes an open resolver. Authoritative only servers should set recursion off. BIND's rate-limit block (Response Rate Limiting) "Controls excessive UDP responses, to prevent BIND 9 from being used to amplify reflection denial-of-service (DoS) attacks."

// named.conf on a recursive resolver: serve only your own networks
acl internal { 10.0.0.0/8; 192.168.0.0/16; localhost; };
options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
};

// named.conf on an authoritative only server
options {
    recursion no;
    rate-limit { responses-per-second 10; };
};

The rate limit value is an illustration; tune it to your traffic. To check what a server is actually running with, print the effective configuration. The BIND manual documents named-checkconf -e as printing "the effective server configuration that would result from named.conf and its included files".

named-checkconf -e | grep -E 'recursion|allow-recursion|allow-query-cache|rate-limit'

Unbound. Unbound's access-control directive takes a netblock and an action. Its documentation says that "By default only localhost (the 127.0.0.0/8 IP netblock, not the loopback interface) is implicitly allowed, the rest is refused", and that refused is the default because the DNS protocol does not handle silently dropped packets well. Add only your own networks:

server:
    access-control: 10.0.0.0/8 allow
    access-control: 2001:db8::/32 allow

Then run unbound-checkconf, which the Unbound documentation names as the tool for checking the configuration file. For the wider set of DNS threats beyond reflection, see DNS attack techniques and defenses.

NTP: time service yes, control queries no

RFC 8633 says control messages are "a vector for amplification attacks when abused" and recommends blocking them from outside the organisation. Mode 6 and mode 7 use beyond basic monitoring should require authentication, a controlkey for mode 6 and a requestkey for mode 7.

ntpd (the NTP reference implementation). RFC 8633's appendix gives the restriction lines that stop a server answering query and configuration traffic by default:

# ntp.conf
restrict default -4 nomodify notrap nopeer noquery
restrict default -6 nomodify notrap nopeer noquery
restrict source nomodify notrap noquery

The ntp.org access control documentation defines each flag: noquery denies ntpq and ntpdc queries while leaving time service unaffected, nomodify denies queries that try to change server state, notrap declines mode 6 trap service, and nopeer denies packets that would mobilise an association unless authenticated.

chrony. Tighter defaults. With no allow directive "no clients are allowed access", its chronyc monitoring port defaults to UDP 323 bound to 127.0.0.1 and ::1, and cmdport 0 closes that port entirely (the Unix domain command socket is unaffected). If you serve time, allow names the subnets you serve and ratelimit limits responses per client address.

# chrony.conf on a server for internal clients only
allow 10.0.0.0/8
ratelimit
cmdport 0

Check the result on the host:

# chronyd's command port should be on loopback or absent; 123 only if you serve time
sudo ss -ulnp 'sport = :323'
sudo ss -ulnp 'sport = :123'

SNMP: management network and SNMPv3

RFC 3414 (December 2002, STD 62) defines the User-based Security Model for SNMPv3. Its stated goals include verifying the identity of the user on whose behalf a message was generated, detecting messages whose time of generation was not recent, and protecting message contents from disclosure when needed. The original document specifies HMAC-MD5-96 and HMAC-SHA-96 for authentication and CBC-DES for privacy; implementations such as Net-SNMP also accept AES for privacy, as its createUser syntax shows.

The Net-SNMP snmpd.conf manual documents three facts every audit should check:

• "The default behaviour is to listen on UDP port 161 on all IPv4 interfaces." Use agentaddress to bind the agent to the management interface only.
• rocommunity and rwcommunity grant SNMPv1 or v2c access "regardless of where they were sent from" unless a SOURCE is given.
• rouser and rwuser grant SNMPv3 users access at a minimum level of noauth, auth or priv.

# snmpd.conf: bind to the management interface, SNMPv3 only, encrypted
agentaddress udp:10.20.0.5:161
rouser monitoring priv
# No rocommunity or rwcommunity lines

# Which interfaces is snmpd bound to?
sudo ss -ulnp 'sport = :161'

# Are any community based access lines still configured?
sudo grep -nE '^\s*(rocommunity|rwcommunity|com2sec)' /etc/snmp/snmpd.conf

The createUser line belongs in snmpd's persistent configuration and must use pass phrases that are not reused anywhere else. Our SNMP explainer walks through user setup and views.

memcached, SSDP, CLDAP and the rest

For services that should never face the internet, the configuration change is usually to stop the service or stop it binding UDP, and the network change is to drop the port at the edge:

• memcached. Run 1.5.6 or later and do not pass -U with a port. If an audit shows UDP 11211 bound, find the start-up arguments and remove the option.
• SSDP and WS-Discovery. Disable the discovery service on servers. On home and branch routers, make sure UPnP is not answering on the WAN interface.
• CLDAP. Drop UDP 389 at the network edge. Directory traffic from outside, if it is needed at all, should be LDAP over TLS on TCP.
• chargen, QOTD, echo. Disable them. Nothing modern depends on them.
• TFTP and portmap. Keep them on provisioning and storage networks only.

When to use which control

Where Safeguard fits

Safeguard does not scan ports, inspect packets, configure firewalls or tune DNS, NTP or SNMP daemons, and nothing in the audit above depends on it. Run the commands in this post with your own tools.

The connection is the software behind the ports. A UDP service is a process, and that process comes from a package or a container image: a DNS server, an NTP daemon, an SNMP agent, memcached, or a QUIC and HTTP/3 library inside your own application. Safeguard's software composition analysis, generally available, builds a full transitive inventory of the libraries in your repositories and container images, and its SBOM generation and analysis, also generally available, produces SPDX and CycloneDX documents you can keep with each release. Vulnerability management with EPSS and CISA KEV enrichment and reachability analysis, both generally available, rank which of those components to fix first. When an advisory lands for a QUIC library or a DNS server package, that inventory tells you which images carry the affected version; our post on using SBOMs to find affected products fast walks through that workflow. Policies and gates at build, CI and release, generally available, can stop an image with a known exploited version from shipping.

Common mistakes

• Trusting the port number. A service on 53 might be a forwarder you forgot, a container's embedded resolver or something unrelated. Always map the socket to a process.
• Checking only inside-out. ss and Get-NetUDPEndpoint show what is bound, not what is reachable. Cloud security groups, host firewalls and edge rules decide reachability, so check from outside too.
• Reading open|filtered as closed. For UDP, silence is ambiguous. Use version detection, or test the specific protocol behaviour, before you conclude a port is safe.
• Assuming "authoritative only" means safe. If recursion is still on, or allow lists say any, an authoritative server is also an open resolver. Turn recursion off explicitly and verify it.
• Leaving NTP control queries open on a public time server. Serving time and answering ntpq are separate decisions. RFC 8633 says to block control queries from outside.
• Using SNMP communities "just for read only". Read only community access over UDP still leaks configuration in clear and still amplifies. Move to SNMPv3 with privacy, bound to a management interface.
• Thinking a stateful firewall blocks inbound UDP to opened ports. It only filters traffic that does not match a flow. A port you have allowed in accepts new flows from anyone.
• Believing BCP 38 protects your servers. Ingress filtering stops your network originating spoofed traffic. It does not stop others spoofing you.
• Forgetting IPv6. A service bound to [::] may be reachable on a global IPv6 address your IPv4 rules do not cover. Test the v6 address from outside.
• Copying old configuration into new images. It can quietly undo safe defaults such as memcached's UDP being off, chrony serving no clients and Unbound refusing non-local clients.
• Auditing once. New images and appliances appear every sprint. Make the inventory a scheduled job.

FAQ

Which UDP ports should be closed on a server?

Every UDP port the server does not need to serve. On most application servers that means no inbound UDP at all except possibly 443 for HTTP/3. Ports such as 19, 17, 69, 111, 137, 161, 389, 1900, 3702, 5353 and 11211 should almost never be reachable from the internet.

How do I list open UDP ports on Linux?

Run sudo ss -ulnp. The ss(8) man page documents -u for UDP, -l for listening sockets, -n for numeric output and -p for the owning process. Look for sockets bound to 0.0.0.0, * or [::] rather than loopback.

How do I check open UDP ports on Windows?

In PowerShell, run Get-NetUDPEndpoint | Sort-Object LocalPort, or use netstat -ano -p udp to see each port's process ID. On macOS, use sudo lsof -nP -iUDP.

Is it safe to expose UDP port 53?

Only for an authoritative DNS server, with recursion turned off and response rate limiting on. A recursive resolver should answer only your own clients; RFC 5358 says name servers "SHOULD NOT offer recursive service to external networks" by default.

Should NTP port 123 be open to the internet?

Only if you intentionally run a public time server. Then block control queries from outside, as RFC 8633 recommends. Hosts that only need correct time should not accept inbound UDP 123 from the internet.

Does a firewall block incoming UDP by default?

A stateful firewall with a default deny inbound policy drops unsolicited UDP and allows replies to flows your side started, for as long as the flow entry lives. Once you open a port, any source can start a new flow to it.

Is QUIC on UDP 443 a reflection risk?

Much less than older UDP protocols. RFC 9000 requires a QUIC server to send no more than three times the bytes it has received from an address before validating it. The remaining risk is in implementation bugs, so keep your QUIC and HTTP/3 libraries patched.

Why does a UDP port scan show open|filtered?

Because many UDP services stay silent when they receive a probe they do not understand, and many firewalls drop probes silently. The Nmap guide explains that no response is reported as open|filtered; version detection with -sV sends protocol specific probes to tell the two apart.

Does BCP 38 protect my own servers from reflection attacks?

No. BCP 38 stops forged source addresses leaving the network that deploys it. It protects everyone else from your network. Your servers are protected by closing reflectors on your side, rate limiting the services that must stay public, and upstream mitigation for floods aimed at you.

Fix it without waiting for upstream

The UDP services in this audit are code you depend on: DNS servers, NTP daemons, SNMP agents, memcached, and the QUIC and HTTP/3 libraries inside your own applications and images. When one of them has a vulnerability, the fix lives in a package or base image you build and ship.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows, not port scanning or traffic filtering. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image behind a UDP service, such as a DNS resolver or a QUIC enabled web server, the same scan lists the packages inside it with their versions and known vulnerabilities, so the process you found in Step 2 of the audit maps to a concrete component list.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a QUIC, DNS or SNMP library pinned in your manifest.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images include a particular memcached, BIND or QUIC library version, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 768: User Datagram Protocol, 28 August 1980
• RFC 8085 (BCP 145): UDP Usage Guidelines, March 2017
• RFC 2827 (BCP 38): Network Ingress Filtering, May 2000
• RFC 3704 (BCP 84): Ingress Filtering for Multihomed Networks, March 2004
• RFC 5358 (BCP 140): Preventing Use of Recursive Nameservers in Reflector Attacks, October 2008
• RFC 8633 (BCP 223): Network Time Protocol Best Current Practices, July 2019
• RFC 9109: Network Time Protocol Version 4: Port Randomization, August 2021
• RFC 3414 (STD 62): User-based Security Model for SNMPv3, December 2002
• RFC 9000: QUIC, A UDP-Based Multiplexed and Secure Transport, May 2021
• RFC 1798: Connection-less Lightweight X.500 Directory Access Protocol, June 1995
• RFC 3352: Connection-less LDAP to Historic Status, March 2003
• IANA Service Name and Transport Protocol Port Number Registry
• CISA alert TA14-017A: UDP-Based Amplification Attacks
• ss(8) Linux manual page
• Microsoft Learn: Get-NetUDPEndpoint
• Microsoft Learn: netstat
• lsof manual page
• Linux kernel documentation: IP sysctl (rp_filter)
• Linux kernel documentation: Netfilter conntrack sysctl
• BIND 9 configuration reference
• BIND 9 manual pages (dig, named-checkconf)
• Unbound: unbound.conf manual
• chrony.conf documentation
• ntp.org: Access Control Commands and Options
• ntp.org: ntpq, standard NTP query program
• Net-SNMP: snmpd.conf manual
• memcached 1.5.6 release notes, 27 February 2018
• Nmap reference guide: UDP Scan (-sU)

Last reviewed: 23 October 2026. Defaults change between releases; check your implementation's documentation for the version you run.