Filtrado upstreamPublicado el 23 de mayo de 2026Tiempo de lectura: 13 min
Upstream filtering DDoS: filtrar el ataque antes de saturar la infraestructura
El filtrado DDoS upstream protege un servicio antes de que el ataque llegue al puerto del cliente, al firewall o al servidor. Esta guía explica cuándo sirve, cómo se diferencia del blackhole y cómo combinarlo con entrega de tráfico limpio.
Filtrado upstream
El tema debe tratarse como una política técnica medible.
BGP y handoff importan
La ruta de entrada y el retorno del tráfico limpio deciden gran parte del resultado.
Menos promesas, más runbook
La disponibilidad depende de reglas, umbrales, rollback y visibilidad.
Upstream filtering DDoS: filtrar el ataque antes de saturar la infraestructura es una cuestión de arquitectura, no solo de compra de capacidad. El problema es que el tráfico malicioso llega a la red del cliente antes de que cualquier filtro local pueda actuar. Si el puerto o el enlace ya está saturado, la protección del servidor no tiene oportunidad real. Para redes expuestas, hosters, servicios gaming y plataformas B2B, el diseño debe explicar dónde entra el tráfico, qué capa decide, cómo se evita la saturación y cómo vuelve el tráfico legítimo. Este artículo analiza upstream filtering DDoS, sus variantes naturales como filtrado DDoS upstream, filtrado DDoS de proveedor, pre-filtrado DDoS, filtrado en el transitario, y la forma de convertirlo en una decisión operativa real.
Por qué elegir Peeryx
Por qué elegir Peeryx
Peeryx prioriza un diseño legible: capacidad upstream, filtrado preciso, handoff limpio y soporte que explique decisiones durante el incidente.
El problema es que el tráfico malicioso llega a la red del cliente antes de que cualquier filtro local pueda actuar. Si el puerto o el enlace ya está saturado, la protección del servidor no tiene oportunidad real. Muchos equipos descubren esto durante el primer incidente serio, cuando ya están cambiando rutas bajo presión y sin saber qué impacto tendrá en los usuarios.
upstream filtering DDoS obliga a mirar el camino completo: anuncio BGP, upstream seleccionado, capacidad real del puerto, filtrado disponible, retorno del tráfico limpio y comportamiento del servicio. Si uno de estos puntos queda indefinido, la mitigación puede funcionar en teoría y fallar en producción.
También existe un problema de lenguaje comercial. Decir “tenemos mucha capacidad” no explica qué ocurre con UDP legítimo, tráfico TCP establecido, latencia, comunidades BGP o reglas temporales. Un comprador técnico necesita entender el mecanismo, no solo el número anunciado.
Por qué es importante
Es importante porque una mala decisión se transforma rápidamente en indisponibilidad visible. El usuario final no distingue entre saturación de tránsito, mala política BGP o filtro demasiado agresivo: solo ve timeouts, pérdida de paquetes o desconexiones.
También afecta al coste. Tráfico de ataque que entra por el camino equivocado puede aumentar el 95 percentil, consumir capacidad de backbone y generar tickets de soporte. La arquitectura debe reducir el ataque lo antes posible sin sacrificar tráfico legítimo.
Para servicios sensibles a latencia, como FiveM, Minecraft, VoIP o APIs interactivas, el diseño debe preservar estabilidad. La protección que mantiene el servidor “online” pero rompe la experiencia no es suficiente.
Soluciones posibles
La primera solución es documentar el modelo de entrada: qué prefijos se anuncian, desde qué ASN, con qué upstreams y bajo qué política BGP. Sin esta base, cualquier automatización puede empeorar el incidente.
La segunda es usar filtrado proporcional. Blackhole, ACL, FlowSpec, scrubbing y rate-limit no tienen el mismo impacto. Cada herramienta debe tener un rol claro y una duración limitada.
La tercera es definir la entrega de tráfico limpio antes del ataque. GRE, IPIP, VXLAN, router VM y cross-connect son opciones válidas, pero no tienen el mismo perfil de latencia, control y despliegue.
El objetivo es retirar volumen inútil en el proveedor upstream, no cortar el servicio. La decisión debe ser precisa: protocolo, puertos, longitud de paquetes, flags o origen de reflexión cuando sea visible.
Filtrar en upstream sin romper el tráfico del cliente
Peeryx aborda este tema con una lógica de red primero: atraer el tráfico hacia una capa capaz de absorberlo, reducir la parte obvia del ataque y entregar tráfico limpio sin ocultar la topología al cliente.
La idea no es aplicar reglas genéricas permanentes. Cuando se usa FlowSpec o filtrado upstream, debe ser preciso, temporal y observable. Cuando se usa túnel o cross-connect, el camino debe estar documentado para que el cliente sepa qué cambió.
El objetivo comercial es simple: vender una protección que el cliente pueda comprender. Eso significa explicar el camino, los límites, los umbrales, el soporte y el rollback, no solo prometer mitigación ilimitada.
Por qué elegir Peeryx
Peeryx prioriza un diseño legible: capacidad upstream, filtrado preciso, handoff limpio y soporte que explique decisiones durante el incidente.
Caso concreto o ejemplo de uso
Un hoster con servidores de juego recibe un UDP flood superior a su puerto. Se filtra el patrón evidente upstream, se mantiene UDP legítimo y el tráfico limpio vuelve por GRE, IPIP, VXLAN o cross-connect.
Durante el incidente, el equipo mira volumen, PPS, protocolo, puertos, rutas activas y latencia por ASN. Si la acción elegida reduce el ataque sin cortar el legítimo, se mantiene. Si crea falsos positivos, se retira o se estrecha.
Después del incidente, los datos alimentan el runbook: qué comunidad BGP usar, qué prefijo mover, qué regla no repetir y qué capacidad contratar después. Así la protección mejora en cada ataque.
1. Observar
Identificar volumen, PPS, protocolo, puertos, ruta BGP e impacto cliente.
2. Actuar
Aplicar la acción mínima eficaz: ruta, filtro, cambio o handoff.
3. Retirar
Retirar o estrechar reglas cuando baja la presión para evitar efectos persistentes.
Errores frecuentes
Confundir capacidad con mitigación real.
Improvisar cambios BGP durante el ataque.
Aplicar filtros demasiado amplios sobre UDP o TCP.
No medir latencia y pérdida durante mitigación.
Olvidar el camino de retorno del tráfico limpio.
No tener rollback claro para reglas temporales.
FAQ
¿upstream filtering DDoS sirve solo para grandes ataques?
No. También importa para ataques más pequeños que saturan un enlace, rompen UDP legítimo o degradan una región concreta.
¿Se puede combinar con BGP del cliente?
Sí. El cliente puede mantener control BGP mientras Peeryx aporta entrada protegida, filtrado y entrega limpia.
¿Cuál es el principal riesgo?
El principal riesgo es una regla demasiado amplia o un camino mal documentado que protege la red pero rompe el servicio.
¿Cuándo hablar con Peeryx?
Antes del incidente, para definir prefijos, upstreams, rutas, latencia, handoff y política de mitigación.
Conclusión
Upstream filtering DDoS: filtrar el ataque antes de saturar la infraestructura debe integrarse en una arquitectura completa: BGP, upstreams, filtrado, capacidad, handoff y soporte.
La mejor protección es la que sigue siendo comprensible durante el ataque. Cuando el equipo sabe qué ruta cambió, qué regla se aplicó y cómo vuelve el tráfico limpio, el servicio tiene muchas más posibilidades de permanecer disponible.
Recursos
Lecturas relacionadas
Para profundizar, aquí tiene otras páginas y artículos útiles.
Peeryx puede revisar sus prefijos, upstreams, restricciones de latencia y exposición DDoS para proponer tránsito protegido o handoff limpio adaptado a su topología real.
