Skip to content
PEERYXNETWORK
PEERYX NETWORK5 min

Memcached DDoS: diagnosis and mitigation

Diagnose reflected Memcached replies, distinguish victim-side filtering from securing a cache, and preserve legitimate traffic when choosing where to mitigate.

On this page

Key points

  • UDP is not the modern defaultMemcached has disabled UDP by default since 1.5.6. Check the actual process and package configuration.
  • Check the directionReflected responses commonly have source port 11211. A destination-port-only rule answers a different question.
  • Protect the constrained linkFiltering after a saturated handoff cannot recover the capacity already consumed before it.

How Memcached reflection reaches an unrelated service

An exposed Memcached instance with UDP enabled can send replies to an address forged into a request. If that address belongs to your service, your network receives the replies even though you do not operate a public cache. Reflection describes that redirection; amplification describes a response larger than the request.

Do not treat every Memcached installation as a reflector. UDP has been disabled by default since version 1.5.6, released in February 2018. An older package or an explicit configuration can behave differently. A version number alone does not show which sockets are listening.

Memcached reflection path

  1. Forged source address

    The request names the victim as its source.

  2. Exposed UDP cache

    A reachable reflector generates the response.

  3. Victim network

    Replies traverse its upstream links and delivery path.

Conceptual path, not a measured amplification factor. Source-address validation prevents spoofing at its origin; the victim also needs an appropriate filtering path.

Confirm the traffic before deciding what to block

  1. Identify the observation point

    Record the interface, direction, time window and sampling rate. Compare ingress interface counters with exporter estimates and the affected service’s errors. A saturated upstream link may prevent the host from observing the complete attack.

  2. Separate source and destination ports

    Inspect inbound UDP responses with source port 11211, their destinations and packet sizes. Incoming requests to a cache usually concern destination port 11211. Neither port alone proves an attack; compare with the services and clients you actually authorize.

  3. Check fragments and request visibility

    Later IPv4 fragments do not carry the UDP header. A port-only filter or sampled flow record can therefore miss part of the picture. Not seeing requests in a one-direction capture does not prove none were sent: routing asymmetry and sampling can hide them.

  4. Measure the service impact

    Keep bandwidth, packet rate, drops, queueing and application success separate. A high packet count with spare bandwidth can expose a processing bottleneck; high bandwidth can instead exhaust a handoff before local CPU becomes busy.

If you operate a Memcached server

Keep the cache on an intended private or loopback address and restrict access to its real clients. If UDP is unnecessary, the Memcached startup option -U 0 disables it. Verify the effective service configuration rather than assuming a distribution’s defaults.

Plan the change around the application: establish which clients use TCP or UDP, check listening sockets and retain a rollback path. After applying the change in an appropriate window, verify normal cache operations and application error rates. Closing your own exposed cache removes a potential reflector; it does not stop third-party servers reflecting traffic toward you.

If your address is the victim

Find the earliest capacity limit: provider-facing port, shared uplink, tunnel underlay, handoff or server NIC. Local filtering can protect application resources while capacity remains, but it cannot restore packets lost before the filter. When the incoming link is saturated, the intervention must move upstream of that bottleneck.

Define a rule around the protected destination and the traffic pattern you have verified. Preserve required cache traffic and other UDP services. A broad UDP block may stop the attack graph while also stopping games, VPNs or DNS. Source-port matching, fragment handling and the available actions must be checked on the actual filtering device.

For a diverted path, validate prefix authorization, route installation, the receiving endpoint, MTU and return traffic. Agree who owns rule expiry and route withdrawal. A tunnel transports packets; it does not identify attack traffic by itself.

Example: filtering before a 1 Gbit/s handoff

Consider an illustrative 1 Gbit/s delivery link with 100 Mbit/s of legitimate traffic. If 2 Gbit/s of reflected replies is offered before that link, a firewall behind it cannot make the link carry all required packets. This is a capacity example, not a customer measurement or a filtering benchmark.

A useful validation records the attack pattern before filtering, the residual load after filtering and successful legitimate transactions through the handoff. Spare receiving capacity matters: a lower attack graph does not by itself prove the service has recovered.

Common mistakes during the incident

  • Blocking destination port 11211 when the relevant inbound packets are replies from source port 11211.
  • Assuming the absence of requests in one capture proves unsolicited traffic across the whole network.
  • Ignoring non-initial fragments or applying an untested fragment policy to legitimate services.
  • Equating a cache configuration fix with protection against unrelated external reflectors.
  • Leaving an emergency rule active without an owner, expiry condition or recovery check.

Evidence to keep for the provider and recovery

Keep the affected destination, precise timestamps and timezone, ingress interface, counter deltas, sampling settings and a bounded packet sample from your own traffic. Separate offered attack traffic from post-filter delivery. Avoid relying on a single peak or on a packet capture taken after loss has already occurred.

After mitigation, verify the customer application and any expected cache access, then check residual PPS, drops and queueing. Withdraw temporary rules according to the agreed procedure and confirm that the normal path still works. Preserve the incident evidence for threshold review instead of treating one incident’s pattern as a permanent universal signature.

Questions and answers

Can I be targeted without running Memcached?

Yes. Reflection uses servers elsewhere. Your address is placed in forged requests, so their replies arrive at your network.

Does source port 11211 prove the traffic is malicious?

No. It identifies a useful protocol signal. Check destination role, authorized clients, payload context and traffic direction before deciding how to filter.

Does upgrading my cache solve an attack against my public IP?

It can remove an exposed reflector you operate, but cannot repair third-party servers or recover an already saturated upstream path.

References and documentation

Match the response to the constraint.

If the access circuit is saturated, filtering behind it cannot restore lost capacity. Compare protected network delivery with local filtering, and validate both packet rate and bit rate before choosing a design.

More guides on this subject ↗