En esta página
Puntos clave
- Localizar el recurso agotadoUn enlace saturado, una tabla llena y una aplicación lenta requieren pruebas y respuestas diferentes.
- Mantener las reglas útilesLa protección DDoS complementa el control de acceso; desactivar el firewall no es una estrategia de respuesta.
- Medir la configuración realUna cifra de rendimiento anunciada no describe todas las mezclas de paquetes, funciones de inspección o tasas de conexión.
Un firewall tiene una ubicación y una capacidad limitada
Un firewall aplica políticas de acceso, descarta tráfico no deseado y, según el producto y su configuración, puede incorporar funciones DDoS o aceleración por hardware. Es incorrecto afirmar que todos fallan ante cualquier DDoS. La pregunta útil es qué recurso agota el incidente y si el equipo puede actuar antes de perderlo.
Un filtro situado detrás de un acceso saturado no recupera paquetes legítimos descartados aguas arriba. A la inversa, un enlace con ancho de banda libre puede entregar más decisiones por paquete o nuevos estados de los que soporta un sistema concreto. Para el usuario, ambos casos se parecen, pero necesitan soluciones distintas.
Distinguir cuatro límites antes de cambiar reglas
Recoja estas mediciones en el mismo intervalo e indique el punto de observación. La entrada del firewall, su salida y una muestra de flujos aguas arriba no son vistas intercambiables. Compare un periodo sano con el incidente antes de convertir un solo gráfico en diagnóstico.
| Recurso | Mediciones necesarias | Lo que no demuestran |
|---|---|---|
| Capacidad del acceso | Tasas ofrecidas y recibidas, pérdidas aguas arriba y errores de interfaz. | Recibir poco tráfico no descarta pérdidas anteriores al firewall. |
| Procesamiento de paquetes | Paquetes por segundo, pérdidas en colas de recepción y carga por núcleo. | Una media de CPU baja no descarta una cola o un worker saturado. |
| Estados de conexión | Nuevas conexiones, entradas asignadas, límites y fallos de asignación. | El número de entradas por sí solo no identifica sesiones maliciosas. |
| Trabajo de la aplicación | Solicitudes correctas, latencia, fallos de conexión y carga del backend. | Un error HTTP aislado no demuestra un DDoS de red. |
Situar cada control antes del recurso que protege
Si el acceso es el cuello de botella, estudie filtrado aguas arriba o una entrega protegida. Si se satura el propio equipo, una regla sin estado bien acotada, un filtrado temprano compatible o una mitigación especializada pueden reducir trabajo antes del procesamiento costoso. El abuso de aplicaciones puede requerir autenticación, controles de solicitudes o un proxy compatible.
Conserve las reglas necesarias, el acceso de administración y el tráfico de control. Los firewalls modernos difieren en estados, aceleración y funciones DDoS: examine la configuración real y las mediciones de las funciones habilitadas. Las etiquetas hardware o software no determinan qué carga cabe.
Leer los contadores de estado antes de elegir una solución
En Linux, nf_conntrack_count informa de las entradas de flujo asignadas y nf_conntrack_max define el límite configurado. Léalos junto con los fallos de asignación y el comportamiento del tráfico. Un aumento puede ser crecimiento legítimo; una cifra baja no demuestra que el resto de la pila de red esté sano.
No aumente límites ni acorte todos los tiempos de espera a ciegas. El consumo de memoria, las sesiones establecidas y el comportamiento de los protocolos forman parte de la decisión. Registrar cada paquete durante una inundación puede añadir trabajo y ocultar eventos útiles. Prefiera contadores acotados y las funciones de registro adecuadas de su implementación.
Ejemplo: 12 Mpps no llenan necesariamente 10 Gbit/s
Considere un flujo hipotético de 12 millones de tramas Ethernet mínimas por segundo. Con 64 bytes por trama, incluido FCS, más 20 bytes de preámbulo y tiempo entre tramas, la ocupación nominal en un sentido es de 8,064 Gbit/s. Eso por sí solo no llena un enlace de 10 Gbit/s. Tramas mayores, otro tráfico y la forma de contabilizar pueden cambiar el resultado.
El cálculo tampoco indica si un firewall concreto puede inspeccionar ese flujo. Hay que medir su ruta de procesamiento y su carga de estados. Es un ejemplo de dimensionamiento, no un incidente de cliente ni un benchmark. Una cifra anunciada de 40 Gbit/s no basta para declarar el firewall apto o saturado.
Definir el éxito más allá del contador de descartes
Establecer una referencia
Registre picos legítimos, tamaños, nuevas conexiones y transacciones correctas. Incluya supervisión y acceso administrativo.
Reproducir el límite de forma controlada
Use una ruta de prueba aislada y autorizada con las reglas previstas. Mida carga ofrecida, tráfico legítimo entregado, pérdida y latencia; no sature un enlace compartido de producción para descubrir su límite.
Comprobar la entrega protegida
Tras filtrar, confirme que el tráfico residual cabe en el enlace receptor, el firewall y la aplicación. Observe conexiones nuevas y sesiones existentes.
Probar la reversión
Identifique responsable, alcance y procedimiento de retirada. Compruebe que eliminar una regla restaura la política prevista sin exponer otros servicios.
Evitar cambios que oculten el fallo real
- Muchos descartes no equivalen a un servicio recuperado: compruebe acciones correctas de los clientes.
- No desactive todo el firewall para esquivar un problema de rendimiento sin explicar.
- No compare un benchmark de reenvío de tramas grandes con inspección con estado de paquetes pequeños.
- No suponga que el filtrado aguas arriba elimina todas las solicitudes de aplicación no deseadas.
- No confunda la media de un incidente corto con su mayor tasa de paquetes o conexiones.
Documentar el límite de cada capa de protección
Anote qué componente controla accesos, reduce paquetes, cambia rutas y aplica controles de aplicación. Registre sus pruebas de capacidad y recuperación. Así operaciones puede escalar el siguiente incidente según el recurso afectado.
Preguntas y respuestas
¿Puede un firewall detener ciertos ataques DDoS?
Sí, si su ubicación, recursos disponibles y controles son adecuados. Un equipo local no recupera tráfico ya perdido en una ruta aguas arriba saturada.
¿Hay que ampliar siempre la tabla de conexiones?
No. Confirme presión de asignación, coste de memoria y necesidades legítimas antes de cambiar límites. Una tabla mayor no resuelve todos los cuellos de botella de procesamiento o aplicación.
¿El tránsito protegido sustituye las reglas del firewall?
No. La reducción aguas arriba y el control de acceso local tienen responsabilidades distintas. Mantenga y valide la política necesaria para el servicio.
