Ir al contenido
PEERYXNETWORK
PEERYX NETWORK5 min

DDoS por Memcached: diagnóstico y mitigación

Diagnosticar respuestas reflejadas de Memcached, distinguir el filtrado de la víctima de la protección de una caché y conservar el tráfico legítimo al elegir dónde mitigar.

En esta página

Puntos clave

  • UDP ya no está activo por defectoMemcached desactiva UDP por defecto desde la versión 1.5.6. Compruebe el proceso real y la configuración del paquete.
  • Comprobar la direcciónLas respuestas reflejadas suelen usar el puerto de origen 11211. Una regla limitada al puerto de destino analiza otro tráfico.
  • Proteger el enlace limitanteFiltrar después de una entrega saturada no recupera la capacidad consumida antes de ella.

Cómo llega la reflexión Memcached a un servicio ajeno

Una instancia Memcached expuesta con UDP activo puede responder a una dirección falsificada en una solicitud. Si esa dirección pertenece a su servicio, su red recibe las respuestas aunque no opere ninguna caché pública. Reflexión describe esa redirección; amplificación, una respuesta mayor que la solicitud.

No toda instalación Memcached es un reflector. UDP está desactivado por defecto desde la versión 1.5.6, publicada en febrero de 2018. Un paquete antiguo o una configuración explícita pueden comportarse de otra forma. La versión por sí sola no muestra qué sockets están escuchando.

Recorrido de la reflexión Memcached

  1. Origen falsificado

    La solicitud identifica a la víctima como emisor.

  2. Caché UDP expuesta

    Un reflector accesible genera la respuesta.

  3. Red de la víctima

    Las respuestas atraviesan sus enlaces y su ruta de entrega.

Esquema conceptual, sin factor de amplificación medido. La validación de direcciones de origen evita la suplantación donde comienza; la víctima también necesita una ruta de filtrado adecuada.

Confirmar el tráfico antes de decidir qué bloquear

  1. Identificar el punto de observación

    Registre interfaz, dirección, intervalo y tasa de muestreo. Compare los contadores de entrada con las estimaciones del exportador y los errores del servicio afectado. Un enlace ascendente saturado puede impedir que el servidor observe el ataque completo.

  2. Separar puertos de origen y destino

    Examine las respuestas UDP entrantes con puerto de origen 11211, sus destinos y tamaños de paquete. Las solicitudes dirigidas a una caché suelen usar el puerto de destino 11211. Ninguno demuestra un ataque por sí solo: contraste con los servicios y clientes realmente autorizados.

  3. Comprobar fragmentos y visibilidad de las solicitudes

    Los fragmentos IPv4 posteriores no contienen la cabecera UDP. Un filtro basado solo en puertos o un registro de flujos muestreado puede omitir parte del tráfico. No ver solicitudes en una captura unidireccional no demuestra que no existan: la asimetría de rutas y el muestreo pueden ocultarlas.

  4. Medir el efecto sobre el servicio

    Distinga ancho de banda, paquetes por segundo, descartes, colas y operaciones correctas de la aplicación. Un PPS alto con ancho de banda libre puede revelar un límite de procesamiento; un gran caudal puede saturar la entrega antes de cargar la CPU local.

Si administra un servidor Memcached

Vincule la caché a la dirección privada o de bucle local prevista y restrinja el acceso a sus clientes reales. Si UDP no es necesario, la opción de inicio Memcached -U 0 lo desactiva. Verifique la configuración efectiva del servicio sin dar por sentados los valores de la distribución.

Planifique el cambio alrededor de la aplicación: identifique clientes TCP y UDP, compruebe sockets en escucha y mantenga una vía de reversión. Tras intervenir en una ventana adecuada, verifique las operaciones de caché y los errores de la aplicación. Cerrar su propia caché expuesta elimina un posible reflector; no impide que servidores ajenos reflejen tráfico hacia usted.

Si su dirección es la víctima

Localice el primer límite de capacidad: puerto hacia el proveedor, enlace compartido, red subyacente del túnel, entrega o NIC del servidor. El filtrado local puede proteger la aplicación mientras quede capacidad, pero no recupera paquetes perdidos antes del filtro. Si la entrada está saturada, la intervención debe situarse antes de ese cuello de botella.

Defina una regla para el destino protegido y el patrón de tráfico verificado. Conserve los intercambios necesarios con la caché y otros servicios UDP. Un bloqueo general UDP puede reducir la gráfica del ataque y detener a la vez juegos, VPN o DNS. Compruebe coincidencias por puerto de origen, fragmentos y acciones en el equipo de filtrado real.

Si desvía el tráfico, valide autorización del prefijo, rutas instaladas, extremo receptor, MTU y tráfico de retorno. Acuerde quién gestiona la caducidad de reglas y la retirada de rutas. Un túnel transporta paquetes; no identifica por sí mismo los ataques.

Ejemplo: filtrar antes de una entrega de 1 Gbit/s

Consideremos una entrega ilustrativa de 1 Gbit/s con 100 Mbit/s legítimos. Si llegan 2 Gbit/s de respuestas reflejadas antes de ese enlace, un cortafuegos situado detrás no puede hacerle transportar todos los paquetes necesarios. Es un ejemplo de capacidad, no una medición de un cliente ni una prueba de rendimiento del filtrado.

Una validación útil registra el patrón antes del filtro, la carga residual después y las transacciones legítimas completadas a través de la entrega. Importa la capacidad de recepción restante: una gráfica de ataque menor no demuestra por sí sola que el servicio se haya recuperado.

Errores habituales durante el incidente

  • Bloquear el puerto de destino 11211 cuando los paquetes relevantes son respuestas desde el puerto de origen 11211.
  • Suponer que la ausencia de solicitudes en una captura demuestra tráfico no solicitado en toda la red.
  • Ignorar fragmentos no iniciales o aplicar a servicios legítimos una política de fragmentación sin probar.
  • Confundir una corrección de configuración de la caché con protección frente a reflectores externos independientes.
  • Mantener una regla de emergencia sin responsable, condición de caducidad ni comprobación de recuperación.

Evidencias para el proveedor y la recuperación

Conserve destino afectado, horas precisas y zona horaria, interfaz entrante, variaciones de contadores, parámetros de muestreo y una muestra limitada de sus propios paquetes. Separe el ataque ofrecido de la entrega posterior al filtro. Evite basarse en un único pico o en una captura tomada después de producirse pérdidas.

Después de mitigar, compruebe la aplicación del cliente y el acceso esperado a la caché; después, PPS residual, pérdidas y colas. Retire las reglas temporales según el procedimiento acordado y confirme la ruta normal. Guarde las evidencias para revisar umbrales sin convertir el patrón de un incidente en una firma universal permanente.

Preguntas y respuestas

¿Puedo recibir un ataque sin usar Memcached?

Sí. La reflexión utiliza servidores remotos. Su dirección se inserta en solicitudes falsificadas y sus respuestas llegan a su red.

¿El puerto de origen 11211 demuestra tráfico malicioso?

No. Es un indicio útil del protocolo. Revise el papel del destino, los clientes permitidos, el contexto de los datos y la dirección antes de decidir el filtrado.

¿Actualizar mi caché resuelve un ataque contra mi IP pública?

Puede eliminar un reflector expuesto que usted opere, pero no repara servidores ajenos ni recupera un enlace ascendente ya saturado.

Referencias y documentación

Adaptar la respuesta a la limitación.

Si el acceso está saturado, filtrar detrás de él no recupera la capacidad perdida. Compara la entrega por una red protegida con el filtrado local y valida tanto paquetes como bits por segundo.

Más guías sobre este tema ↗