GH GambleHub

Protección y filtrado de paquetes DDoS

Resumen breve

Los ataques DDoS son de tres clases: L3/L4 volumétricos (obstruyen el canal/hardware), state-exhaustion (agotan las tablas de estado/CPU en balanceadores/firebols) y L7 (generan consultas «plausibles» a la aplicación). La defensa efectiva se construye en varias capas: medidas de red en el perímetro, filtrado/scrubbing fuera de su red, protección en balances/proxy y aplicaciones, además de procedimientos operativos con SLOs medibles.

Paisaje de amenazas

Volumetric (flood UDP/ICMP, amplificación DNS/NTP/SSDP/CLDAP/Memcached): el objetivo es marcar el canal y los puertos.
TCP state-exhaustion (SYN/ACK flood, fragmentación TCP, conexiones «en semi-conos»): agotar conntrack/listeners.
L7 HTTP (S )/WebSocket/GraphQL flood, cache-busting, consultas «lentas»: comer aplicaciones CPU/IO y capas de caché.
Reflection/Amplification: uso de reflectores/amplificadores abiertos con sustitución de fuente IP.
Bombeo de carpetas: la distribución del tráfico a través de múltiples IP/prefijos, lo que complica el filtrado de puntos.

Medidas básicas de red (antes de los ataques)

1. Anti-spoofing: uRPF/BCP38 en la frontera; drop de paquetes salientes con fuentes extranjeras.
2. ACL en edge/PE: prohibición de protocolos/puertos no deseados; listas individuales para el segmento mgmt.
3. CoPP (Control Plane Policing): polising al router (BGP, OSPF, SSH, SNMP).
4. Rate-limits/polising en puertos: bps/PPS para clases «ruidosas», configuración burst.
5. Distribución de carga: Anycast para IPs públicas, georasses; CDN/WAAP para estática y caché.
6. RPKI/ROA + Importación estricta de BGP: reduce el riesgo de que el tráfico se vuelva a encasillar/desviar.
7. Reducción de surface: minimice los servicios publicados, cierre el origen «crudo» por proxy.

Respuesta rápida al ataque: palancas de red

RTBH (Remote Triggered Blackhole): BGP-Community para la ruta cero/32 (o/128) de la víctima.
BGP Flowspec: distribución rápida de reglas L3/L4 (src/dst/puerto/banderas TCP) en PE/edge.
Centros de scrubbing/proveedores anti-DDoS: túnel GRE/VRF o Apstream directo; filtración, luego tráfico «limpio» a usted.
Anycast-antiDDoS: división de flujo a través de puntos de presencia, localización de daños.
CDN/edge-cache: protege el origin, da L7-limites y «challenge» mecanismos.

Hostal y protección L4

Cookies SYN/SYNPROXY: no mantener el estado hasta la confirmación del cliente.

Linux: `sysctl net. ipv4. tcp_syncookies=1' o'SYNPROXY 'en el equilibrador de entrada.

Sintonizar el contrack (si se utiliza):
  • Modera 'nf _ conntrack _ max' razonablemente, aumentando la hashsize;
  • Reduzca los tiempos de espera para estados «semiabiertos» e inactivos.
  • eBPF/XDP: drop temprano en NIC (protección PPS), filtrado por firmas/velocidad al núcleo.
  • nftables/iptables: límites en PPS, descartar banderas «sospechosas», connlimit.
  • hardening UDP: si el servicio no utiliza un drop UDP en la frontera; si utiliza - restringir fuentes/puertos.
Ejemplo de 'nftables' (simplificado):
nft table inet filter {
sets {
bad_ports { type inet_service; elements = { 19, 1900, 11211 } } # chargen/SSDP/memcached
}
chains {
input {
type filter hook input priority 0; policy drop;
ct state established,related accept ip saddr 127. 0. 0. 0/8 drop ip6 saddr::1/128 drop

limit new TCP tcp flags & (syn    ack) == syn limit rate 200/second burst 400 accept tcp flags & (syn    ack) == syn drop

deny bad UDP ports udp dport @ bad _ ports drop

ICMP rate-limit icmp type echo-request limit rate 50/second burst 100 accept icmpv6 type echo-request limit rate 50/second burst 100 accept
}
}
}
SYNPROXY en el equilibrador de entrada (ejemplo de 'iptables'):
bash iptables -t raw -A PREROUTING -p tcp --syn -j CT --notrack iptables -A INPUT -p tcp -m tcp --syn -m hashlimit --hashlimit 100/second --hashlimit-burst 200 --hashlimit-mode srcip --hashlimit-name syns -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 iptables -A INPUT -m state --state INVALID -j DROP

Protección L7 (corta)

WAAP/WAF: modelo positivo en caminos críticos, ratios-límites, desafío/JS, puntuación conductual.
Almacenamiento en caché/offload estático: reduzca las solicitudes a origin; protección contra cache-busting (normalización/listas negras de parámetros).
Limitadores GraphQL: 'maxDepth', 'maxCost', prohibición de introspección en la venta.
Patrón BFF: tokens de cliente fino, lógica pesada/límites en el servidor.
Idempotencia y colas: previenen repeticiones en forma de avalancha cuando se degradan.

Telemetría y detección

Flujos de red: NetFlow/sFlow/IPFIX (pps, talkers superiores, protocolos/puertos/ASN).
Sensores pasivos L7: logs balancers/proxy (nginx/envoy), métricas p95/99, error-rate.
Umbrales básicos: «crecimiento inesperado de PPS/CPU en edge», «estallido de SYN-RECV», «UDP sin respuesta».
Firmas/comportamiento: frecuencias de IP/ASN/JA3, ráfagas de 4xx/5xx, anomalías de user-agent.
Visualización: dashboards individuales L3/L4/L7; mapa de tráfico geo/ASN; tiempo antes de que RTBH/Flowspec se active.

SLO/SLI y alerting

Ejemplos de SLO:
  • «MTTD anomalías DDoS ≤ 60 segundos, MTTM (activación RTBH/Flowspec) ≤ 3 min».
  • "p95 latencia vía edge ≤ 50 ms fuera de los ataques; cuando se ataca ≤ 200 ms bajo mitigación".
  • «El porcentaje de tráfico malicioso descartado ≥ el 99% mientras se mantiene ≥ 98% legítimo».
Alarmas:
  • PPS/CPU/IRQ de nodos de red> umbrales;
  • SYN-RECV/half-open > X;
  • crecimiento 5xx/latency en endpoints públicos;
  • porcentaje de desafío/deny en WAF> umbral (riesgo de FP).

Patrones de defensa arquitectónica

1. Tiered Defense: Edge (ACL/CoPP) → Scrubbing/Anycast → L7 proxy/WAAP → App.
2. Traffic Diversion: Comunidad BGP para mudarse a la zona de matorral, GRE-Beckhol durante el tiempo de picado.
3. Stateless Edge: filtrado sin estado máximo a conntrack; stateful - más cerca de la aplicación.
4. eBPF/XDP First: drops tempranos (por JA3/puertos/velocidad) al núcleo.
5. Golden Paths: IP/dominios individuales para APIs críticas para no «demoler» todo en su totalidad.

Procedimientos operativos e incidentes

Runbooks: quién y en qué métricas incluye RTBH/Flowspec/scrubbing, cómo cambiar Anycast/pools.
Listas Negras y TTL: el bloque es a corto plazo para no «moverse»; re-test automático de fuentes.
Comunicaciones: plantillas de mensajes a proveedores/socios/vendedores; canal de comunicación fuera del dominio atacado.
Post-Incident: informe con línea de tiempo (T0... Tn), «qué funcionó/no», actualización del directorio de pruebas.
Ejercicios: juegos regulares: RTBH dry-run, pérdida de la región de Anycast, saturation link, ataques «lentos».

Sintonizar balances/Linux (muestreo)

bash
TCP sysctl -w net. ipv4. tcp_max_syn_backlog=4096 sysctl -w net. ipv4. tcp_syncookies=1 sysctl -w net. ipv4. tcp_fin_timeout=15 sysctl -w net. ipv4. tcp_tw_reuse=1

Conntrack (if enabled)
sysctl -w net. netfilter. nf_conntrack_max=1048576 sysctl -w net. netfilter. nf_conntrack_tcp_timeout_syn_recv=30 sysctl -w net. netfilter. nf_conntrack_udp_timeout=15

NIC/IRQ ethtool -G eth0 rx 4096 tx 4096

Errores frecuentes

Mantener todo el tráfico a través de stateful-firewall en edge → agotamiento de conntrack. Haga stateless donde pueda.
El canal de → RTBH/Flowspec tardío ya está «en cero». Automatice los umbrales y la activación.
Un frente IP/uno para «todo» → no hay aislamiento blast radius. Comparta dominios/IP y cuotas.
Caché cero → cada L7 de circulación golpea origin; habilite el almacenamiento en caché y la normalización de parámetros.
Bloqueo ciego de países/ASN sin análisis de legitis: corta la conversión; use reglas/desafíos matizados.
Los límites demasiado agresivos → una FP masiva en el pico del negocio.

Hoja de ruta de implementación

1. Evaluación de la superficie: inventario de IP/prefijos/puertos/protocolos, mapa de rutas críticas.
2. Higiene de la red: antispufing, ACL, CoPP, RPKI/ROA, abandono de servicios UDP superfluos.
3. Sabotaje del tráfico: contrato con un proveedor de scrubbing, Anycast/CDN, comunidades BGP.
4. Edge-tuning: filtrado sin estado, SYNPROXY/eBPF, temporizadores razonables de contracorriente.
5. L7/WAAP: modelo positivo, límites/desafíos, caché.
6. Observabilidad: NetFlow/sFlow, dashboards L3/L4/L7, alertas, SLO.
7. Automatización: botones RTBH/Flowspec, IaC para reglas, configuraciones canarias.
8. Ejercicios y RCA: pruebas regulares, actualización de playbucks.

Características para iGaming/fintech

Eventos máximos (torneos, promociones, partidos): planificar capacity/límites, calentar cachés, pre-warming CDN.
Integraciones de pago: IP/dominios dedicados, canales prioritarios a través del proveedor anti-DDoS, mTLS a PSP, límites estrictos a endpoints críticos.
Control anti-frod/bot: pruebas de comportamiento y desafíos humanos en el registro/login/código promocional.
UX y conversión: con protección agresiva, use hojas grace para VIP/partners, degradación suave (caché/readonly).
Requisitos legales: transparencia de los registros, almacenamiento de telemetría, depuración de los efectos de las medidas sobre el Tiempo-a-Wallet y las métricas de volumen de negocios.

Ejemplos: Flowspec y RTBH (conceptualmente)

RTBH a través de la comunidad (ejemplo):

route 203. 0. 113. 10/32 blackhole set community 65535:666 announce to upstream
Flowspec (unidad UDP> 1 Mbit/interfaz por puerto 19/1900):

match destination 203. 0. 113. 0/24 protocol = udp destination-port {19,1900}
then rate-limit 1000

FAQ

¿WAF resuelve DDoS?
En parte para L7. Contra L3/L4 y volumetric necesita medidas de scrubbing/Anycast/networking.

¿Las cookies SYN son suficientes?
Esta es la protección básica de SYN-flood, pero sin límites de red y scrubbing, el canal todavía se puede marcar.

¿Es necesario desactivar ICMP?
No. Mejor rate-limit y sólo tipos peligrosos, ICMP es útil para el diagnóstico/PMTU.

¿El túnel de matorral GRE no añadirá latencia?
Sí, pero normalmente es admisible. Compensa con la caché y la ruta exacta hasta el PoP más cercano.

Resultado

La robusta protección DDoS es una arquitectura de varios niveles: higiene de la red (anti-spoofing/ACL/CoPP), sabotaje rápido del tráfico (RTBH/Flowspec/scrubbing/Anycast), mecanismos de host y L7 (SYNPROXY, eBPF/XDP, WAAP), además de telemetría, SLO y playbucks depurados. Este enfoque minimiza lo simple, mantiene los canales vivos y mantiene las métricas de negocio incluso bajo la presión de ataques distribuidos.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.