En esta página
Puntos clave
- Proteja el camino antes del hostUn filtro local no recupera paquetes perdidos en un enlace upstream saturado.
- Asigne un responsable a cada decisiónFiltros solapados y estados independientes pueden producir resultados contradictorios.
- Haga observable la recuperaciónContadores, versiones y una reversión probada deben acompañar el recorrido del tráfico.
Asigne una responsabilidad a cada capa
Una cadena de filtrado dedicada es una secuencia de decisiones, no una lista de productos instalados. Empiece por el recurso que protege cada capa. La mitigación upstream puede reducir tráfico antes de agotar el acceso. Los controles locales tempranos pueden descartar paquetes inadecuados antes de un procesamiento más caro. Los controles con estado aplican políticas de conexión; la aplicación valida identidad, autorización y comportamiento de solicitudes.
Estas funciones pueden residir en una o varias plataformas, pero sus límites deben ser comprensibles. Añadir filtros sin función definida dificulta localizar falsos positivos. Si dos capas mantienen estado de conexión, decida cómo ve cada una la ida y el retorno y qué hace cuando un paquete llega a otro proceso o nodo.
| Capa | Objetivo | Evidencia que conservar |
|---|---|---|
| Camino upstream | Reducir tráfico antes de un enlace de entrega limitado. | Decisión upstream, contadores de entrada y entrega, y estado del desvío. |
| Procesamiento temprano | Descartar tráfico no deseado bien definido con trabajo acotado. | Contadores de coincidencias, pérdidas de colas de recepción y versión exacta de reglas. |
| Política de conexión | Aplicar reglas de acceso y estado al tráfico compatible. | Éxito de conexiones, fallos de asignación y observaciones del retorno. |
| Aplicación | Validar usuarios y solicitudes de aplicación. | Acciones completadas, tipos de error, tiempo de respuesta y carga del backend. |
Sitúe los controles donde se ejecuta realmente la implementación
Un programa XDP puede ejecutarse pronto en un camino de recepción compatible, pero importa el modo de conexión. Deben comprobarse en la interfaz real el controlador, modo nativo o genérico y comportamiento de redirección o reenvío. Que el verificador eBPF acepte un programa no demuestra que clasifique correctamente ni que el host alcance una tasa de paquetes.
Un camino de reenvío en espacio de usuario puede gestionar la interfaz de otra forma. El software que usa DPDK o una vinculación concreta de NIC debe validarse con el resto del host; no suponga que todas las funciones del kernel siguen en el recorrido. Revise el despliegue documentado del producto antes de combinarlo con otro plano de datos.
Empiece con pocas reglas explicables. Limite el alcance al tráfico que opera, identifique paquetes legítimos parecidos a cada patrón y conserve una forma de desactivar el cambio. Una coincidencia amplia sin estado no distingue siempre una solicitud legítima de un ataque por ejecutarse temprano.
Dimensione el procesamiento, no solo la etiqueta de la NIC
Paquetes por segundo, bytes en el cable, distribución de flujos y creación de estado afectan a la carga. RSS distribuye tráfico con campos y funciones hash admitidos por la NIC; no garantiza reparto uniforme ante cualquier ataque. Una cola saturada puede perder paquetes mientras otros núcleos parecen libres. Revise colas e interrupciones, ubicación de procesos y relación NUMA con las interfaces.
En una entrega en línea el tráfico utiliza recursos de entrada y salida. Número de puertos, dirección y margen importan junto con la capacidad de filtrado medida. Un segundo servidor de reserva no duplica automáticamente la capacidad útil bajo el escenario de fallo requerido. Calcule la configuración que debe sobrevivir y mida con la política prevista activa.
Mantenga compatibles estado y enrutamiento
Seguimiento de conexiones, proxy SYN y filtrado consciente del protocolo necesitan la visibilidad que espera su implementación. Si el retorno evita al responsable del estado, una conexión legítima puede parecer incompleta. Varios caminos activos pueden necesitar hash coherente, sincronización de estado o una alternativa sin estado compatible. Dos sesiones BGP no aportan esas propiedades automáticamente.
Cambios de encapsulación, ECMP, NAT o balanceo pueden cambiar qué nodo observa un flujo. Documéntelo antes de activar una función con estado. En Defense Fabric, valide los requisitos de enrutamiento del modo TCP elegido y pruebe la redundancia con ese modo activo. No deduzca compatibilidad con cualquier funcionamiento asimétrico con estado.
Deje las decisiones de aplicación al componente adecuado
Un filtro de red puede reducir paquetes no deseados y aplicar comprobaciones de protocolos compatibles. No se convierte en un sistema de autorización por estar delante de un servidor. Mantenga controles de acceso, presupuestos de solicitudes, política del origen y monitorización de aplicación donde exista el contexto necesario.
Para alojar juegos, distinga el protocolo realmente compatible de una autorización UDP genérica. Minecraft Java y FiveM no comparten exactamente caminos ni pasos de validación. Pruebe establecimiento normal y comportamiento durante el juego, no solo respuesta de una dirección. No active un perfil ajeno porque su nombre parezca cercano al servicio.
Siga el mismo intervalo de observación por toda la cadena
Etiquete cada gráfica con punto de observación, dirección, método de muestreo y ventana temporal. Tráfico ofrecido upstream, estimaciones de flujos, contadores NIC y solicitudes de aplicación son medidas distintas. Una reducción puede significar filtrado correcto, pérdidas anteriores, cambio de ruta o fallo del colector. Correlacione evidencias antes de atribuir una causa.
Registre versiones activas y momento de cada cambio. Prefiera contadores acotados a registrar cada paquete descartado durante una inundación. Si desaparece la telemetría, distinga «sin observación» de «sin tráfico». La recuperación del colector y la del reenvío deben comprobarse por separado.
Valide los cambios por etapas
Defense Fabric, Transit IP protegido y Flow Collector pueden participar en partes distintas del diseño. Licencia, transporte y recogida de telemetría siguen necesitando validación separada. Un ensayo exitoso en un host aporta evidencia para ese host y esa carga, no una garantía pública para todos los clientes.
Dibuje el recorrido existente
Registre interfaces, rutas, responsables de reglas y funcionamiento de la aplicación antes de modificar la cadena.
Pruebe un control
Use tráfico representativo en un entorno aislado autorizado; compruebe comportamiento legítimo y descartes.
Pruebe fallo y reversión
Simule la pérdida de nodo o camino acordada y confirme estado y restauración.
Conserve un acta de aceptación versionada
Guarde juntos software, hardware, reglas, observaciones y límites pendientes del ensayo.
Preguntas sobre despliegue
¿Puedo colocar XDP delante de cualquier aplicación DPDK?
No lo suponga. La gestión de la interfaz, el modo del controlador y el recorrido real dependen del despliegue. Consulte la arquitectura compatible antes de combinar planos de datos.
¿Un segundo filtro siempre mejora la protección?
No. Necesita una función definida y comportamiento compatible de enrutamiento y estado. De lo contrario puede añadir latencia, falsos positivos o ambigüedad operativa.
¿Qué demuestra que la cadena está lista?
Un acta que conecte recorrido real, pruebas de servicio legítimo, carga representativa aislada, comportamiento ante fallos y reversión; no solo una etiqueta de velocidad de puerto.
