Guía de despliegue de Defense Fabric

Qué hace el software

Defense Fabric ejecuta la detección, el filtrado de paquetes y el control de políticas en sus servidores. La capacidad local depende de esos equipos y sus enlaces. No incluye la capacidad de red upstream del tránsito IP protegido de Peeryx.

Flow Collector es una herramienta gratuita e independiente de observación y control del desvío. No sustituye al motor de filtrado de Defense Fabric. El tránsito Peeryx es el servicio de red contratado por separado que permite filtrar el tráfico en la red anterior a su infraestructura.

Servidor y sistema operativo

El instalador actual está dirigido a Debian 12 y el plugin de filtrado distribuido es para x86-64. La licencia vinculada al equipo requiere TPM 2.0. El instalador fija VPP y sus plugins en 25.10-release: no cambie esa ABI de VPP durante una actualización del sistema operativo.

• Disponga de acceso de administración independiente, DNS funcional, reloj correcto y HTTPS saliente para el registro, las comprobaciones de licencia y las actualizaciones firmadas.
• Valide conjuntamente CPU, distribución de memoria, ubicación NUMA, anchura del enlace PCIe, referencia exacta del adaptador, firmware, controlador y ópticas. El nombre de la familia ConnectX no basta para confirmar la compatibilidad.
• Separe la administración del servidor de las interfaces de tráfico. Reserve CPU, memoria y almacenamiento suficientes para el motor, la recopilación de flujos y la conservación de evidencias.

Dimensionamiento y pruebas de rendimiento

Utilice Gbit/s y Mpps conjuntamente. Un enlace Ethernet de 100 Gbit/s con tramas de 64 bytes permite aproximadamente 148,81 Mpps si se incluyen el preámbulo y el intervalo entre tramas. Es un cálculo de velocidad de línea, no un resultado de filtrado. Dos puertos no garantizan el doble de capacidad de extremo a extremo.

Las configuraciones de hardware publicadas son candidatas a validación. No se ha publicado un informe de rendimiento reproducible para ellas. Pruebe el equipo real con el número de reglas y tamaños de paquete previstos, tráfico legítimo simultáneo y mitigación activada. Registre pérdidas, latencia y recuperación, además del caudal.

Licencias, puertos y servidores

La licencia base incluye un puerto 10G. Los puertos adquiridos forman una bolsa compartida entre los servidores gestionados por la licencia. Instalar un segundo servidor no duplica esa bolsa. Asigne la velocidad y cantidad necesarias a cada servidor antes del uso de pago. El límite de gestión es de 128 servidores por licencia.

La prueba de 14 días no impone una cuota de software sobre el número de puertos o la velocidad declarada. No elimina los límites físicos ni los requisitos de validación del hardware y activación de red. Añadir un servidor no reinicia la prueba.

La validez de la licencia, la identidad del servidor y la preparación del enrutamiento son comprobaciones separadas. Al terminar la prueba se requieren pago y derechos de uso vigentes para continuar la operación bajo licencia. El área de cliente muestra la fecha de vencimiento y el estado de renovación aplicables.

Instalación y registro

Empiece en la página Defense Fabric de su cuenta. Cree o seleccione la suscripción, añada el servidor y genere su token de registro de corta duración y un solo uso. Siga las instrucciones asociadas a ese servidor y mantenga privados su identidad y token.

El instalador comprueba Debian 12, la disponibilidad del TPM y la versión necesaria de VPP. Si ya existe un plano de datos activo e independiente, prepare una migración con mantenimiento en lugar de instalar encima. La verificación de la versión firmada y el registro correcto no demuestran que el tráfico del cliente esté protegido.

• Anote la versión instalada y revise el resultado de la instalación.
• Confirme por separado la conexión al panel, el motor, los puertos asignados y los contadores de interfaces.
• Mantenga el servidor en observación hasta haber probado el reenvío y el recorrido de retorno.

Interfaces y retorno del tráfico limpio

Identifique la entrada del tráfico que debe filtrarse y la interfaz lógica separada que devuelve el tráfico limpio. Confirme VLAN, direcciones, puertas de enlace, MTU y accesibilidad del siguiente salto tanto en el router como en el servidor de filtrado. No confunda los contadores de administración de Linux con los de los puertos de filtrado.

Evite que el tráfico desviado vuelva a la entrada sin filtrar y forme un bucle. Las direcciones del plano de control y de la puerta de enlace del tráfico limpio deben quedar fuera de los rangos protegidos. Mida tráfico real del cliente en ambos sentidos antes de dar el recorrido por válido.

Inline, desvío BGP o arquitectura híbrida

Inline: el tráfico atraviesa continuamente el filtrado local. Valide qué ocurre si falla el servidor, la interfaz o la alimentación. Instalar software no crea un bypass físico.

Desvío BGP: el router envía el tráfico de los destinos atacados seleccionados al siguiente salto de filtrado. Defina filtros de importación/exportación y comunidades explícitas. Compruebe anuncios, instalación en la FIB, retorno limpio y retirada. Los intervalos de exportación y la convergencia influyen en el tiempo de respuesta.

Híbrida: combine el filtrado local con tránsito protegido Peeryx cuando necesite mitigación upstream. El tránsito requiere activación propia, prefijos autorizados y un recorrido de entrega probado. Comprar la licencia no cambia por sí solo su enrutamiento upstream.

BGP, FlowSpec y RTBH

Configure router ID, direcciones locales y del vecino, ASN, siguiente salto de filtrado accesible y comunidad de desvío acordada. El interruptor de enrutamiento del panel autoriza las sesiones y anuncios gestionados por el agente. Guardar un borrador no confirma que el router haya instalado la ruta prevista.

FlowSpec exporta reglas selectivas upstream solo si está habilitado, la simulación está desactivada y la familia BGP correspondiente está establecida. Empiece en dry-run, inspeccione las reglas generadas y pruebe las capacidades y límites del router. El panel limita a 50 las reglas simultáneas.

RTBH es el último recurso: descarta todo el tráfico hacia el destino afectado, incluido el legítimo. Trate el umbral, el tiempo de persistencia y el periodo de validez hasta la retirada como controles distintos. Pruebe la recuperación.

sFlow, NetFlow e IPFIX

Active la recepción en una dirección accesible para los exportadores autorizados, preferiblemente mediante red privada o VPN. El puerto predeterminado es UDP 6343. Configure el mismo puerto en ambos extremos y restrinja la lista de exportadores permitidos. No exponga un colector sin restricciones a Internet.

Compruebe muestreo y temporizadores de exportación antes de fijar umbrales. sFlow comunica su tasa de muestreo; el multiplicador configurado se aplica a NetFlow/IPFIX cuando el exportador no la proporciona. La ventana de recopilación se configura entre 5 y 60 segundos.

Compare las tasas estimadas con los contadores de interfaces y compruebe la antigüedad de los datos. La ausencia de exportaciones no demuestra que el tráfico o el ataque hayan terminado. Las capturas de paquetes y las estimaciones de flujos ofrecen observaciones distintas.

Prefijos, umbrales y recuperación

Las políticas utilizan bloques IPv4 /24 registrados y excepciones /32 dentro de ellos. Examine el tráfico normal antes de aplicar un perfil. En esta versión, los umbrales de detección por protocolo y destino se expresan en PPS. Los ajustes en Gbit/s de FlowSpec y RTBH corresponden a sus decisiones de capacidad independientes.

Monitor observa sin desviar por ataque. Automatic desvía durante los ataques detectados. Permanent mantiene activo el recorrido de filtrado validado. Fije el umbral de salida por debajo del de entrada y use un tiempo de mantenimiento para evitar cambios de ruta repetidos durante un ataque fluctuante.

Un perfil carga umbrales por protocolo. No es una lista de aplicaciones permitidas. Un perfil más estricto no resulta automáticamente adecuado para una red con más tráfico.

Reglas adaptativas y protección TCP/UDP

La detección adaptativa puede evaluar firmas en observación o aplicar reglas generadas en modo activo. Revise la firma registrada y su efecto sobre el tráfico legítimo antes de excluirla o cambiar el backend. El backend debe corresponder a la versión instalada y al hardware validado.

SYN proxy valida el establecimiento de conexiones y requiere un recorrido simétrico probado. SYN challenge está previsto para el caso asimétrico compatible. No son controles intercambiables: el panel impide combinaciones incompatibles. La validación específica de SYNACK también requiere el recorrido simétrico documentado.

Las cuotas por origen limitan paquetes UDP o el total combinado SYN/SYNACK por IP de origen en los prefijos donde se habilitan. Usuarios tras NAT, VPN o proxy pueden compartir una dirección. Incluya su tráfico normal conjunto al elegir la cuota.

Excepciones y firewall posterior al filtrado

Utilice excepciones /32 para hosts concretos dentro de un /24 registrado. Manténgalas acotadas y documentadas. Una regla accept actúa en el firewall posterior al filtrado; no recupera paquetes descartados previamente ni garantiza que se omitan todas las demás comprobaciones.

El panel admite hasta 20 prioridades ordenadas de firewall por prefijo. Compruebe protocolo, rango de origen, puertos de destino y unidades de tasa antes de aplicar. Los selectores de puerto TCP/UDP no tienen sentido para todos los protocolos IP.

Panel, informes y API

Evalúe por separado la conexión al panel, el estado del motor, BGP y la preparación de la protección. Un agente conectado o un proceso en ejecución no equivalen a una prueba satisfactoria de reenvío. Las estadísticas recientes se muestrean; investigue una muestra antigua en lugar de considerarla tráfico cero.

El historial de ataques, las reglas registradas y las evidencias PCAP, ZIP o PDF disponibles ayudan a explicar incidentes. La retención y el muestreo limitan lo que puede reconstruirse. Una exportación no tiene por qué contener la captura completa del ataque.

Consulte la referencia OpenAPI pública para conocer operaciones y permisos. Se requiere autenticación: limite los tokens a la cuenta y los permisos necesarios. Las escrituras de políticas usan revisiones y devuelven un estado pendiente de aplicación. Compruebe el nodo antes de considerar aplicada la modificación. No automatice contra funciones privadas internas del panel.

Varios servidores y ECMP

Una licencia compartida y un segundo servidor no crean replicación automática de estado ni alta disponibilidad. Defina detección de fallos, preferencias de ruta, retirada y recuperación para toda la arquitectura. Pruebe cada fallo por separado.

El diseño compatible con segundo enlace usa iBGP directamente conectado con el mismo ASN y VLAN distintas para tráfico sin filtrar y limpio. Requiere Fabric 2.8.0 o posterior. Cada sesión utiliza su propio siguiente salto local. ECMP distribuye flujos; uno de ellos puede permanecer en un único enlace.

SYN proxy y SYNACK challenge no están validados para este modo de doble recorrido. Dos enlaces 100G no constituyen una garantía de filtrado a 200 Gbit/s.

Actualizaciones y recuperación de configuración

Utilice el procedimiento de actualización firmada del panel. Planifique una ventana de mantenimiento: la actualización puede reiniciar el motor de filtrado. Confirme la versión prevista y conserve acceso independiente antes de empezar.

El actualizador verifica la versión, conserva la configuración y prepara archivos de recuperación. Si falla la instalación, examine el diagnóstico y el estado restaurado. Una reversión no demuestra por sí sola que todos los recorridos de red hayan recuperado el servicio.

Antes de modificar políticas, guarde la configuración pertinente y compare los cambios propuestos. Mantenga privados copias y credenciales. Valide la política restaurada con el software en ejecución antes de devolverle tráfico desviado.

Lista de aceptación para producción

Acuerde la prueba y las condiciones de reversión antes de desviar servicios activos. Use tráfico que esté autorizado a generar y un destino de prueba controlado.

• Referencia: compare tráfico normal, contadores, pérdidas y accesibilidad de aplicaciones con protección inactiva y activa.
• Detección: genere un evento acotado y confirme que solo afecta al destino, regla y ruta previstos.
• Recuperación: detenga el evento, espere el tiempo configurado y confirme retirada de reglas y reenvío normal.
• Fallos: pruebe por separado la pérdida del exportador, de BGP y del nodo de filtrado. Confirme el recorrido real y si el diseño deja pasar o bloquea el tráfico al fallar.
• Registre versión, servidor, NIC, tamaños de paquete, número de reglas, muestreo, duración, pérdidas y latencia. Conserve evidencias de funcionamiento y reversión.

Diagnosticar la capa afectada

Sin contacto con el panel: compruebe conectividad de gestión, DNS, reloj, HTTPS, identidad y licencia. No cambie BGP en producción solo para recuperar la conexión de administración.

Motor activo sin tráfico protegido: revise interfaces de filtrado, VLAN, siguientes saltos y contadores RX/TX reales. Compruebe la FIB del router y el retorno limpio independientemente del estado de la sesión BGP.

Mitigación inesperada: compare tasa normal medida, muestreo, perfil y regla registrada. Modifique un borrador, revise el cambio y aplíquelo de forma deliberada. Recopile diagnósticos antes de reiniciar procesos o retirar rutas.

Límites conocidos

Esta guía describe la versión distribuida para Debian 12/x86-64 y el flujo de protección IPv4. No certifica otros sistemas operativos, NIC arbitrarias, paridad de políticas IPv6, conmutación sin pérdidas ni un resultado concreto en Mpps.

El filtrado local no recupera ancho de banda ya saturado upstream. El tránsito Peeryx permite trasladar el filtrado a una red anterior mediante un servicio separado. Flow Collector puede apoyar una arquitectura bajo demanda validada específicamente.

Las funciones SYN, ECMP y el enrutamiento automático tienen requisitos de compatibilidad propios. Una combinación no probada requiere validación; no debe considerarse un servicio activo.