Interpretar correctamente los datos de rendimiento de Sophos Firewall
Los datos de rendimiento de un Sophos Firewall son importantes para el dimensionamiento, pero a menudo se interpretan incorrectamente. El mayor rendimiento del firewall en la hoja de datos no es automáticamente el rendimiento que un sitio alcanzará con IPS, Protección web, Inspección TLS, VPN, NAT, informes y muchos usuarios simultáneos.
Por lo tanto, al elegir un modelo, no se debe mirar solo un número de Gbit/s. Lo importante es qué funciones de protección están activas, qué tráfico pasa por el firewall y qué reservas necesita el entorno en el día a día. La Guía de dimensionamiento de Sophos Firewall explica la elección del modelo; este artículo explica cómo evaluar las métricas de rendimiento subyacentes.
Regla rápida para el dimensionamiento
En la práctica, generalmente no es el rendimiento puro del firewall el mejor punto de partida.
- Solo enrutamiento y reglas de firewall simples: Considerar el rendimiento del firewall e IMIX.
- Red empresarial normal con IPS y Control de aplicaciones: Dar más peso a los valores de NGFW o Protección contra amenazas.
- Muchas conexiones HTTPS con descifrado: Planificar el rendimiento de la Inspección TLS y la reserva de CPU.
- Muchas conexiones VPN: Considerar por separado los requisitos de IPsec o Acceso remoto.
- Firewall virtual: Tomar en serio el hipervisor, CPU, RAM, almacenamiento y tarjetas de red virtuales tanto como la licencia de Sophos.
Si no está claro si es mejor el hardware o la aplicación virtual, Sophos Firewall - ¿Hardware o aplicación virtual? puede ayudar en la decisión.
Por qué los valores de la hoja de datos no son suficientes
Los valores de rendimiento se determinan bajo condiciones de laboratorio definidas. Esto es útil porque hace que los modelos sean comparables. Sin embargo, un entorno productivo se comporta de manera diferente:
- Los tamaños de los paquetes son mixtos.
- Los usuarios generan sesiones paralelas.
- Los perfiles de seguridad examinan el tráfico con diferentes profundidades.
- El tráfico HTTPS requiere significativamente más recursos con la Inspección TLS.
- VPN, SD-WAN, NAT, registro e informes funcionan en paralelo.
- WLAN, switches, clientes, servidores y proveedores influyen en el rendimiento percibido.
Por lo tanto, un valor de la hoja de datos es un valor comparativo, no una promesa para cada flujo individual. Para un dimensionamiento sólido, se debe planificar con reservas y no considerar las funciones operativas posteriores a la compra.
Las métricas más importantes
- Rendimiento del firewall: Comparación en tráfico simple de capa 3/capa 4 A menudo se lee como rendimiento real de Internet con todas las funciones de seguridad
- Firewall IMIX: mezcla más realista de diferentes tamaños de paquetes Se ignora, aunque las redes reales rara vez tienen solo paquetes grandes
- Rendimiento IPS: Tráfico con Prevención de Intrusiones Se subestima cuando IPS está activo para muchas reglas
- Rendimiento NGFW: Firewall con funciones adicionales de próxima generación como IPS y Control de aplicaciones Se confunde con el rendimiento puro del firewall
- Protección contra amenazas: Valor de aproximación más fuerte para funciones de protección activadas Se entiende como un valor mínimo fijo en lugar de una métrica comparativa
- Inspección TLS: Descifrado y examen de HTTPS Se olvida en el dimensionamiento, aunque puede ser muy intensivo en recursos
- VPN IPsec: Conexión de sitios y túneles cifrados Se planifica solo en función de la conexión a Internet, sin considerar el punto final, tamaños de paquetes y CPU
- Sesiones y conexiones por segundo: Muchos usuarios, tráfico web, publicación de servidores, conexiones cortas Rara vez se verifica, pero puede ser relevante con muchos clientes o servicios publicados
Rendimiento del firewall e IMIX
El rendimiento puro del firewall describe un procesamiento relativamente simple del tráfico. Este valor es útil cuando un firewall principalmente enruta, realiza NAT y procesa reglas de firewall clásicas.
IMIX está más cerca de la carga real de la red porque mezcla diferentes tamaños de paquetes. Esto es importante porque los paquetes pequeños cargan un firewall de manera diferente a las descargas grandes. En las redes empresariales, rara vez hay solo un flujo de datos grande y limpio. Los accesos web, DNS, VoIP, aplicaciones en la nube, actualizaciones y transferencias de archivos generan diferentes patrones.
Para ubicaciones con tráfico de usuarios normal, IMIX es a menudo más significativo que el valor máximo más atractivo.
IPS, NGFW y Protección contra amenazas
Una vez que IPS, Control de aplicaciones, Protección web o el examen de malware están activos, el firewall debe hacer más que simplemente reenviar paquetes. El firewall debe clasificar el tráfico, reconocer patrones, aplicar reglas y, según la política, examinar el contenido.
Los términos a menudo se mezclan:
- IPS evalúa el tráfico en función de firmas y reglas para patrones de ataque conocidos.
- NGFW describe el rendimiento del firewall con funciones adicionales como IPS y Control de aplicaciones.
- Protección contra amenazas es un valor de aproximación más fuerte para entornos donde varias funciones de protección están activas simultáneamente.
Para una empresa que realmente opera Sophos Firewall como un gateway de seguridad, los valores de NGFW y Protección contra amenazas suelen ser más relevantes que el rendimiento puro del firewall.
Planificar la Inspección TLS de manera realista
La Inspección TLS es uno de los mayores factores de rendimiento. El firewall descifra las conexiones HTTPS, examina el contenido y vuelve a cifrar la conexión. Esto genera carga en la CPU y puede ser notablemente perceptible según el conjunto de cifrado, el servidor de destino, el cliente, las excepciones y la política.
Por lo tanto, la Inspección TLS no debe activarse de manera casual. Es sensato un despliegue gradual con un grupo piloto, excepciones, monitoreo y una búsqueda de errores clara. El artículo Implementar correctamente la Inspección TLS de Sophos Firewall describe el proceso operativo.
También se debe distribuir correctamente el certificado CA. Para los clientes, Instalar el certificado CA de Sophos Firewall para el escaneo HTTPS es el punto de partida adecuado.
Evaluar el rendimiento de VPN por separado
El rendimiento de VPN no solo depende del modelo de firewall. También son relevantes el punto final, la conexión a Internet, la latencia, los tamaños de paquetes, MTU/MSS, los parámetros de cifrado, el enrutamiento y los túneles paralelos.
Para las conexiones de sitio a sitio, se deben estimar de manera realista los flujos de datos planificados: transferencias de archivos, copias de seguridad, ERP, VoIP, RDP, monitoreo y replicación se comportan de manera diferente. Para el acceso remoto, también se añaden el dispositivo cliente, WLAN, proveedor y cliente VPN.
Si un enlace VPN parece lento, no se debe verificar solo el valor de la hoja de datos. Una prueba de enlace definida con iPerf suele ser más significativa que una prueba de velocidad en el navegador.
Qué influye en el rendimiento real
En la práctica, varios factores actúan simultáneamente:
- perfiles de seguridad activos por regla de firewall
- Inspección TLS y excepciones
- Política IPS y alcance de firmas
- Protección web, Control de aplicaciones y examen de malware
- NAT, DNAT, publicación de servidores y WAF
- IPsec, SSL VPN, Sophos Connect y túneles de sitio a sitio
- Registro, informes, informes centrales y Syslog
- muchas sesiones pequeñas en lugar de pocas descargas grandes
- Aceleración del firewall, FastPath, Aceleración IPsec y tráfico que no se puede descargar
- Operación HA, versión de firmware y hotfixes
- Recursos virtuales en aplicaciones de software o en la nube
Por lo tanto, el rendimiento siempre debe evaluarse en el contexto de la política concreta. Una regla de firewall sin perfiles de seguridad se comporta de manera diferente a una regla con IPS, filtro web, Control de aplicaciones e Inspección TLS.
Interpretar correctamente FastPath y Offloading
Los firewalls modernos de Sophos no procesan cada flujo de datos de la misma manera. Dependiendo de la aplicación, firmware, regla, perfil de seguridad y tipo de tráfico, el tráfico puede acelerarse parcialmente o examinarse en una ruta de procesamiento más lenta. Los términos importantes para esto son FastPath, aceleración del firewall, aceleración PKI y aceleración IPsec.
La clasificación inicial sigue realizándose en SlowPath: el kernel y, cuando corresponde, el motor DPI inspeccionan la conexión. Una vez completado el handshake TCP o después de que pase un paquete en cada dirección, SFOS puede incorporar un flujo apto a la caché de conexiones FastPath. Por tanto, FastPath no es un bypass sin inspección; solo procesa el estado programado por el kernel. Los protocolos no aptos, como IP-in-IP, permanecen en SlowPath.
Para el dimensionamiento, esto es importante porque una prueba rápida no demuestra que cada flujo de producción utilice la misma ruta. Sophos indica Firewall e IPsec Acceleration para todos los appliances XGS. La PKI Acceleration dedicada para procesar certificados en flujos TLS inspeccionados solo está documentada para XGS 4300, 4500, 5500, 6500, 7500 y 8500. Los modelos desktop Gen. 2 XGS 88/88w, 108/108w, 118/118w y 128/128w usan Virtual FastPath en el kernel x86 en lugar de un Xstream Flow Processor dedicado.
Los límites son más estrictos para appliances virtuales y de software. Según la ayuda de SFOS 22, Virtual FastPath solo es compatible con VMware ESXi y los controladores NIC igc, e1000, e1000e y vmxnet3. VFP se desactiva automáticamente con otros hipervisores, en despliegues cloud o con controladores no compatibles. El firewall continúa funcionando, pero sin esta mejora de FastPath. Para e1000 y e1000e, Sophos especifica una MTU máxima de 3500 bytes, y para los demás controladores compatibles una máxima de 9000 bytes. Son límites de plataforma, no un motivo para activar jumbo frames sin una prueba de extremo a extremo.
PKI Acceleration no acelera todo el procesamiento TLS. En los flujos TLS 1.2 y TLS 1.3 inspeccionados por el motor DPI, solo descarga el proceso de volver a firmar certificados de servidor X.509 con autenticación RSA de hasta 4096 bits. El cifrado simétrico, el tráfico de web proxy y las conexiones SSL VPN que terminan en el firewall no se benefician de ella.
Ciertas funciones o tipos de tráfico pueden limitar o impedir el offloading, por ejemplo:
- SSL VPN
- WAF y tráfico proxy
- QoS y DoS
- Inalámbrico, RED, LAG y PPPoE
- Tráfico IP fragmentado
- Ciertas situaciones de puente, HA o virtualización
En IPsec, el stack XFRM descarga la encapsulación, el cifrado, la desencapsulación y el descifrado ESP en función de la SA de fase 2. No se descargan las SA con 3DES, BlowFish o MD5, las SA en interfaces virtuales como VLAN ni el tráfico IPsec sobre interfaces VLAN o inalámbricas. El túnel puede seguir funcionando, pero consume más CPU del host.
Las políticas de seguridad no impiden el offloading de forma general. Una regla sin IPS, web filtering, antivirus ni application control puede cambiar después del handshake o de los paquetes iniciales; con application control, Sophos indica que la decisión se toma después de unos ocho paquetes. Para STARTTLS con Don’t decrypt, se toma después de unos 15 paquetes. Por eso, los primeros paquetes aún pueden aparecer en SlowPath aunque el flujo posterior esté acelerado.
Regla práctica: El offloading no es un objetivo de seguridad. No se eliminan perfiles de protección ni la inspección solo para alcanzar FastPath. Lo que importa es la protección necesaria y las mediciones reproducibles de throughput, CPU y aplicación.
En HA hay que mirar con especial cuidado. Active-Active HA no admite Firewall Acceleration. En Active-Passive HA, Firewall e IPsec Acceleration solo las usa el nodo primario. Por tanto, el sizing para HA no debe extrapolar sin más valores de laboratorio standalone a ambos nodos.
La búsqueda de errores también puede influir en las mediciones. Con Packet Capture o iftop, SFOS envía el tráfico temporalmente por SlowPath de forma predeterminada. Si el offloading permanece activo durante la captura, un Packet Capture estándar no puede registrar tráfico FastPath. Por tanto, un paquete ausente no demuestra que el firewall no haya procesado el flujo; Sophos remite a Support cuando se necesita una captura FastPath. Las mediciones de rendimiento y los resultados de captura siempre se documentan con el momento, método de prueba, versión del firmware, tipo de interfaz y política activa.
Las aceleraciones están activadas de forma predeterminada en las plataformas compatibles. Activar o desactivar Firewall o PKI Acceleration reinicia IPS o el motor DPI; cambiar IPsec Acceleration reinicia todos los túneles IPsec. Estos cambios pertenecen a una ventana de mantenimiento, no a una prueba de rendimiento improvisada. Primero se confirma la sospecha con Log Viewer, Packet Capture, Solución de problemas de IPsec y un caso de prueba claro.
Leer y controlar correctamente PKI Acceleration
El estado configurado y el estado efectivo no son lo mismo. La configuración se consulta con:
show ips-settings
PKI Acceleration está activada de forma predeterminada en los modelos XGS compatibles. enabled solo es efectivo si Firewall Acceleration también está funcionando. Si PKI Acceleration está activada pero Firewall Acceleration está desactivada, SFOS muestra enabled (inactive). En versiones de SFOS o modelos no compatibles aparece como disabled; cambiar la opción en la CLI no puede aportar la compatibilidad de hardware o plataforma que falta.
La configuración global se cambia mediante el árbol de comandos de IPS:
set ips pki-acceleration disable
set ips pki-acceleration enable
El cambio reinicia IPS o el motor DPI, por lo que debe realizarse en una ventana de mantenimiento. Primero se registran el valor actual y el estado de Firewall Acceleration. Después se vuelven a comprobar show ips-settings, el estado de IPS y DPI y un flujo TLS real descifrado por el motor DPI. Solo así se puede confirmar que la nueva firma del certificado, la latencia, la CPU y la aplicación siguen funcionando correctamente. Si no aparece el efecto esperado, se restaura el valor documentado anteriormente.
Comprobar IPsec Acceleration de forma controlada
Primero se lee el estado global:
system ipsec-acceleration show
IPsec Acceleration está enabled por defecto y descarga del SlowPath las SA de fase 2 aptas. Un estado global activado no demuestra que una SA concreta esté offloaded. 3DES, BlowFish y MD5 están excluidos, y siguen vigentes los límites de interfaces y plataformas descritos anteriormente.
El cambio se aplica a todo el firewall y reinicia todos los túneles IPsec. Por tanto, disable no es una prueba para un solo túnel. Si un error claro justifica una prueba A/B, se documentan primero el estado de los túneles, las SA, CPU, rendimiento y tráfico de prueba. En la ventana de mantenimiento están disponibles estos dos cambios opuestos:
system ipsec-acceleration disable
system ipsec-acceleration enable
Después de cada cambio realmente ejecutado se vuelven a comprobar show, el establecimiento del túnel, las SA de fase 2, routing, las reglas y tráfico real en ambas direcciones. Sin una mejora reproducible se restaura el valor original. No se mantiene un perfil criptográfico obsoleto solo para hacer posible una comparación de rendimiento.
Cambiar Firewall Acceleration solo en una ventana de mantenimiento
Primero se consulta el estado actual en Device Console:
system firewall-acceleration show
En plataformas compatibles, Firewall Acceleration está en enable de forma predeterminada. Según Sophos, cada cambio provoca una interrupción y reinicia IPS o el motor DPI. Por tanto, disable no es una prueba A/B informal durante la producción. La firewall sigue procesando todo el tráfico, pero sin las ventajas de rendimiento de FastPath.
Para un cambio planificado están disponibles estos dos comandos. No se ejecutan uno inmediatamente después del otro como bloque de prueba, porque cada transición puede volver a interrumpir el tráfico:
system firewall-acceleration disable
system firewall-acceleration enable
Después de cada transición realmente necesaria se vuelven a comprobar show, el estado de IPS y DPI, las nuevas sesiones, los servicios publicados, VPN, throughput, CPU y Log Viewer. Un valor disabled visible no se sustituye a ciegas por enable: DoS, HA active-active, un FastPath que no se carga o una combinación no compatible de VM, hipervisor o driver de NIC también pueden impedir la aceleración. enable no puede forzar un FastPath funcional en una plataforma técnicamente no compatible.
Verificar el rendimiento en operación
Los valores de la hoja de datos ayudan antes de la compra. En operación, se necesitan otras herramientas. Es importante separar los conceptos: el Control Center no muestra rendimiento de ficha técnica, sino indicadores operativos actuales. La tarjeta Performance se basa en el load average sobre los núcleos de CPU. Valores por encima del número de núcleos disponibles significan que hay más trabajo pendiente del que el sistema puede procesar en ese momento.
El color de la tarjeta sigue umbrales fijos de Sophos: Normal con un load average inferior a 2, Warning de 2 a 5 y Alert por encima de 5 núcleos de CPU. Este semáforo es un indicador rápido, pero no equivale al umbral de sobrecarga individual del appliance. Por tanto, se deben interpretar conjuntamente el estado de la tarjeta, el número real de núcleos y la evolución temporal.
También son relevantes CPU, memoria, ancho de banda, sesiones, Decryption Capacity y Decrypt Sessions. Decryption Capacity es especialmente útil con TLS Inspection porque muestra cuánto utiliza el descifrado SSL/TLS actual la capacidad de descifrado disponible. Los detalles de decryption no se actualizan como medición en vivo segundo a segundo, sino normalmente cada cinco minutos. Estos valores deben leerse siempre junto con política, regla, perfil de seguridad, hora y tipo de tráfico.
Usar System Graphs como línea temporal
En Diagnostics > System graphs se pueden comparar CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone e interfaces individuales durante distintos periodos. Primero se selecciona el periodo del incidente y después solo los gráficos que correspondan a la función afectada.
Un pico es una correlación, todavía no una causa. Por ello, CPU, memoria o load average deben compararse con el tráfico de interfaz, el número de usuarios, los registros, la política y la hora exacta de la prueba. La evolución resulta especialmente útil para distinguir un valor atípico breve de una carga alta recurrente o sostenida; por sí sola no demuestra ni que el appliance sea demasiado pequeño ni que un servicio concreto esté defectuoso.
Interpretar correctamente las unidades y la agregación
El gráfico de CPU separa el uso por procesos de usuario, componentes del sistema y el tiempo inactivo restante. Memory muestra Used, Free y Total en MB. Load Average, en cambio, no es un porcentaje: sus tres curvas representan promedios de uno, cinco y quince minutos. Por eso debe interpretarse junto con el número de núcleos de CPU disponibles.
Disk Usage muestra el porcentaje ocupado por firmas, archivos de configuración, informes y datos temporales. Es un desglose funcional del gráfico y no la misma vista que las particiones de df -kh o el watermark de informes. Live Users cuenta los usuarios que estuvieron conectados a Internet durante el periodo seleccionado y muestra además el mínimo, el máximo y el promedio. No es el número de cuentas de usuario configuradas.
Para la zona WAN hay gráficos separados de subida y bajada, de la tasa total combinada y de la tasa por gateway. Según la vista aparecen los valores actual, mínimo, máximo y promedio. Sophos documenta un error importante de etiquetado: WebAdmin muestra KBps, pero los valores están realmente en kbit/s. Interpretarlos como kilobytes por segundo introduce un error de factor ocho.
Importante para VLAN: Hay gráficos de interfaz separados para interfaces físicas, Wireless LAN, interfaces WAN e interfaces VLAN de la zona WAN. Las VLAN de otras zonas se combinan en el gráfico con su interfaz física principal. Por eso, un pico en el puerto principal no puede atribuirse a una sola VLAN interna sin otra medición.
Los gráficos de interfaz muestran bits recibidos y enviados, además de drops, errores y colisiones. La resolución se agrega para periodos más largos: hoy y ayer usan promedios de cinco minutos, la semana de 15 minutos, el mes de seis horas y el año de un día. Por ello, los picos breves pueden desaparecer en la vista mensual o anual; para un incidente debe elegirse primero el periodo adecuado más estrecho.
Procedimiento práctico:
- Verificar el Centro de control: Observar CPU, RAM, carga de interfaz y advertencias.
- Abrir el Visor de registros: ¿La regla de firewall esperada está activa y el registro está habilitado?
- Controlar la política y los perfiles de seguridad: ¿Qué funciones afectan al tráfico afectado?
- Usar Packet Capture: ¿Se ven paquetes, paquetes de respuesta, NAT y caídas?
- Realizar una prueba de enlace: Con iPerf o una descarga definida, verificar qué ruta realmente es lenta.
- Anotar el contexto de offloading: El tipo de interfaz, el modo HA, el tipo de VPN, PPPoE, WAF, SSL VPN o Packet Capture pueden influir en la medición.
- Anotar el momento: Picos de carga, copias de seguridad, actualizaciones o informes pueden distorsionar los resultados.
Para una rápida delimitación de la conexión WAN, Realizar una prueba de velocidad de Internet de Sophos Firewall por SSH es útil. Para pruebas de extremo a extremo entre dos sistemas, Probar el rendimiento de Sophos Firewall con iPerf es más adecuado. Si una regla no se aplica como se esperaba, Probar reglas de Sophos Firewall de manera específica es apropiado.
La lista diaria de administración de Sophos Firewall muestra cómo combinar Control Center, System graphs, informes y eventos administrativos en un procedimiento breve y periódico.
Errores típicos de dimensionamiento
- Solo se compara el mayor rendimiento del firewall.
- Se planifica la Inspección TLS, pero no se incluye en la reserva de rendimiento.
- VPN y Acceso remoto se evalúan según el número de usuarios en lugar del uso real.
- Se considera la conexión a Internet, pero no el tráfico interno este-oeste.
- Los firewalls virtuales se ejecutan en hosts sobrecargados.
- Los informes, registros y la conexión central se consideran solo después.
- El crecimiento, nuevas ubicaciones, VLAN adicionales o publicación de servidores faltan en la planificación.
- No se hace diferencia entre el valor de laboratorio, el valor real y la experiencia del usuario.
Lista de verificación práctica para el dimensionamiento
Antes de elegir un modelo, se deben aclarar estos puntos:
- Ancho de banda de Internet hoy y planificado para los próximos años.
- Número de usuarios, dispositivos, servidores y ubicaciones.
- Proporción de tráfico web, aplicaciones en la nube, VoIP, copias de seguridad y transferencias de archivos.
- Funciones de seguridad planificadas por grupo de tráfico.
- Alcance de la Inspección TLS y excepciones necesarias.
- Número y uso de conexiones IPsec, SSL VPN y Sophos Connect.
- Necesidad de WAF, Protección de correo, RED, WLAN o Informes centrales.
- Reservas esperadas para actualizaciones, crecimiento y picos de carga.
- Modelo operativo: Hardware XGS, aplicación virtual, nube o clúster HA.