Ir al contenido
Avanet

Comprender y configurar de forma segura las reglas Sophos Firewall

Sophos Firewall

Las reglas del firewall son el núcleo del Sophos Firewall. Estas reglas determinan qué tráfico entre zonas, redes, usuarios y servicios está permitido o bloqueado y qué funciones de protección se aplican.

Este artículo explica una regla Sophos Firewall de arriba a abajo: Orden, Grupos, Acción, Registro, Fuente, Destino, Services, Coincidencia de usuarios, Exclusiones, NAT, Filtrado web, TLS Inspection, Security Heartbeat, Application Control, IPS, Configuración de tráfico, DSCP, NDR y escaneo de correo electrónico.

La ruta del menú es:

Rules and policies > Reglas de firewall > Agregar regla de firewall > Nueva regla de firewall

Sophos Firewall Agregue una regla de firewall con todas las opciones, desde el estado de la regla hasta las funciones de seguridad
Sophos Firewall: agregar regla de firewall: la regla se configura de arriba a abajo y luego se evalúa según el orden de las reglas.

La máscara de regla se divide en varias áreas: área de encabezado, origen, destino, Services, referencia de usuario, enlace NAT y funciones de seguridad. En la práctica, es importante no ver la máscara como una colección de ganchos individuales. Una regla sólo funciona correctamente si el origen, el destino, el servicio, la secuencia, el registro y las funciones de protección activadas coinciden.

Antes de crearla también se debe tener claro si se trata de una regla IPv4 o IPv6. La vista de reglas se selecciona en consecuencia en WebAdmin. En entornos de doble pila, IPv4 e IPv6 deben planificarse y probarse intencionalmente por separado; una regla IPv4 que funcione no prueba automáticamente que IPv6 sea igualmente seguro.

¿Qué artículo de política de red encaja?

Las reglas de firewall, NAT, WAF, VLAN y enrutamiento están estrechamente entrelazados en el Sophos Firewall. Por lo tanto, es importante que los administradores elijan primero el tema correcto:

Esta separación evita la resolución de problemas típicos. Una regla NAT no permite el tráfico, una regla de firewall no traduce una dirección y una regla WAF no es lo mismo que el reenvío de puertos DNAT normal.

Qué controlan las reglas de firewall y qué no

Las reglas del firewall controlan el tráfico que fluye a través del firewall. Pero estas reglas no son el único punto de control en SFOS. Gran parte de la resolución de problemas se produce porque se busca un comportamiento en la lista de reglas del firewall, aunque otra área sea responsable.

  • Tráfico entre zonas, redes, usuarios y servicios: Reglas del cortafuegos. Aquí es donde se decide si el tráfico directo se permite, se rechaza o se controla con elementos de seguridad.
  • WebAdmin, User Portal, VPN Portal, SSH, DNS o SNMP al propio firewall: Device Access y Local Service ACL. Los servicios de firewall locales no se tratan como tráfico normal de LAN a WAN o WAN a DMZ.
  • dirección o puerto traducción: reglas NAT. NAT traduce el tráfico pero no lo permite automáticamente.
  • Selección de ruta, ruta de regreso, trayectos SD-WAN y VPN: Enrutamiento, configuración SD-WAN, Route Precedence y VPN. Una regla de firewall adecuada no es una solución que funcione.
  • Categorías web, grupos de URL y política web: Filtrado web y política web. La regla de firewall integra la política, pero la lógica web real reside en la política web.
  • Descifrado HTTPS: Reglas de inspección SSL/TLS y distribución de CA. Scan HTTP and decrypted HTTPS solo analiza el tráfico que ya está descifrado.
  • Identidad de usuario: Autenticación, STAS, Portal Cautivo, Entra ID SSO o RADIUS. Una regla de usuario solo coincide si el firewall puede asignar el usuario al tráfico.

Para servicios de gestión y portal, Device Access y Local Service ACL es el artículo central. Si una regla coincide pero la conexión aún falla, La regla Sophos Firewall no funciona: verifique las causas y Probar la regla de firewall con Log Viewer, Policy Test y Packet Capture serán de ayuda. Especialmente en el caso de redes mixtas IPv4/IPv6, también debería comprobarse si una aplicación a través de IPv6 incumple una regla IPv4 más estricta. Si IPv6 no se utiliza activamente, la estrategia IPv6 debería documentarse conscientemente: desactivarlo, bloquearlo, regularlo adecuadamente o introducirlo de forma controlada.

Principio básico y secuencia.

Las reglas del firewall controlan el tráfico entre zonas y redes. Las reglas permiten, rechazan o bloquean el tráfico y pueden aplicar funciones de seguridad adicionales.

Sophos Firewall comprueba las reglas del firewall de arriba a abajo. Tan pronto como una regla coincide, las reglas de firewall posteriores ya no se verifican. Lo importante no es sólo lo que está en una regla, sino también dónde está en la lista de reglas.

Una regla sólo es válida si se aplican todos los criterios relevantes al mismo tiempo:

  • Zona de origen: Sí. LAN.
  • Source networks and devices: Sí. net_LAN_Clients.
  • Horario: Sí. All the time.
  • Zona de destino: Sí. WAN.
  • Destination networks: Sí. Any o un host FQDN.
  • Services: Sí. HTTP, HTTPS, DNS.
  • Coincidencia de usuarios: Sólo si está activado. Grupo AD Internet-Users.
  • Exclusiones: Si se establece, la regla se puede omitir. Excluir servidor de respaldo.

La primera regla coincidente gana. Si una regla general LAN_to_WAN_Any está por encima de una regla LAN_to_WAN_Restricted específica, nunca se alcanzará la regla específica.

Planificar la base de reglas antes de crear

Se puede crear rápidamente una única regla de firewall. Lo que es más difícil es una base de reglas que aún sea comprensible, comprobable y segura después de dos años. Por lo tanto, antes de introducir nuevas reglas, primero debe aclarar a qué zona de seguridad, grupo y lógica operativa pertenece la regla.

Preguntas orientadoras útiles:

  • ¿Qué tipo de tráfico debería permitirse realmente?: Anote el origen, el destino y Services antes de crear.
  • ¿El tráfico pertenece a su propia zona?: Separe conscientemente servidores, clientes, invitados, administración, VPN y DMZ.
  • ¿Existe ya una norma específica?: Verifique las reglas existentes en lugar de crear una segunda regla similar.
  • ¿Está involucrada NAT?: Planifique las reglas de firewall y NAT juntas, pero no las mezcle.
  • ¿Cómo se comprobará más tarde?: Active el registro y defina el tráfico de prueba específico.
  • ¿La liberación es temporal?: Documente la fecha de vencimiento o boleto en la descripción.

Para zonas e interfaces limpias, Sophos Firewall Configurar zonas e interfaces encaja primero. Si una regla existente no funciona, la lista de verificación La regla Sophos Firewall no funciona: verificar causas será de ayuda.

⚠️ Una regla Any amplia suele ser conveniente, pero rara vez es una buena configuración final. Puede ayudar a corto plazo para las pruebas. Luego debería ser reemplazado o eliminado nuevamente por fuentes, destinos y servicios específicos.

Tipos de reglas claramente separados

Una buena base de reglas separa visiblemente los diferentes riesgos entre sí. El error más común no es una única opción incorrecta, sino una regla general que cubre clientes, servidores, VPN, invitados y administración al mismo tiempo. Esto funciona rápidamente al principio, pero luego se vuelve difícil de probar y de endurecer.

  • Cliente Internet: Fuente típica: Redes de clientes; Objetivo típico: WAN; ¿A qué prestar atención?: Política web, Application Control, IPS, TLS Inspection, QUIC, Registro.
  • Servidor Internet: Fuente típica: Redes de servidores; Objetivo típico: objetivos definidos de actualización, copia de seguridad o nube; ¿A qué prestar atención?: más estrictas que las reglas del cliente, a menudo sin referencia del usuario.
  • Invitado-WLAN: Fuente típica: Zona de invitados; Objetivo típico: WAN; ¿A qué prestar atención?: sin control consciente de objetivos internos, ancho de banda y DNS.
  • Gestión: Fuente típica: Redes de administración; Objetivo típico: Firewall, servidores, conmutadores, hipervisores; ¿A qué prestar atención?: no mezclar con las reglas normales del cliente.
  • VPN Acceso remoto: Fuente típica: VPN o zona propia de acceso remoto; Objetivo típico: zonas objetivo internas; ¿A qué prestar atención?: sólo objetivos y servicios requeridos, iniciando sesión en la fase introductoria.
  • Sitio a sitio: Fuente típica: zonas VPN locales y remotas o zonas XFRM; Objetivo típico: Redes de socios o ubicaciones; ¿A qué prestar atención?: Verifique enrutamiento, NAT, ruta de retorno y registro juntos.
  • Sistema publicado: Fuente típica: WAN o fuentes definidas; Objetivo típico: DMZ o zona del servidor; ¿A qué prestar atención?: DNAT/WAF, IPS, registro, nivel de parche y limitación de fuente.
  • Acceso temporal: Fuente típica: soporte definido o fuente del proyecto; Objetivo típico: objetivo estrecho; ¿A qué prestar atención?: Ticket del documento, fecha de caducidad, propietario y desmontaje.

Si dos conexiones tienen propietarios, funciones de protección o ciclos de revisión diferentes, las reglas separadas suelen ser más limpias. Si sólo se requiere un servicio adicional para el mismo fin profesional, se podrá ampliar una norma existente.

Ejemplo práctico ficticio

Como ejemplo, se crea una regla de cliente limpia:

Objetivo: Los clientes del LAN interno pueden acceder a Internet. El filtro web, Application Control, IPS y el registro deben estar activos. Los servidores, invitados y redes de administración tienen sus propias reglas y no se mezclan con esta regla de cliente.

  • Nombre de la regla: LAN_to_WAN_Clients. Borrar nombre con origen y destino.
  • Descripción: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Más adelante sabrás por qué existe la regla.
  • Rule position: Bajo reglas específicas de bloque y servidor. Las normas específicas deberían entrar en vigor primero.
  • Rule group: Internet Access. Mejor visión general.
  • Acción: Accept. Se permite el tráfico.
  • Registrar el tráfico del firewall: Habilitado. Solución de problemas del Log Viewer.
  • Source zones: LAN. El tráfico proviene de la zona LAN.
  • Source networks and devices: net_LAN_Clients. No todas las redes LAN, solo clientes.
  • Durante el horario programado: All the time. El acceso a Internet debería ser permanente.
  • Destination zones: WAN. El objetivo es Internet.
  • Destination networks: Any. Principalmente práctico para clientes de Internet.
  • Services: HTTP, HTTPS, DNS, NTP. Sólo servicios básicos requeridos.
  • Web policy: Default Workplace Policy. Controlar el acceso web según categorías.
  • Block QUIC protocol: Habilitado. El filtrado y escaneo web siguen siendo efectivos.
  • IPS: Política del cliente. Protección contra exploits para el tráfico saliente de clientes.
  • Control de aplicaciones: Política de aplicación del cliente. Bloquear aplicaciones no deseadas.
  • Tráfico de forma: Opcional. Sólo si se requiere ancho de banda.
  • DSCP marking: Vacío. Sólo es necesario si los dispositivos posteriores evalúan DSCP.

Este ejemplo no es deliberadamente un billete gratuito Any. En la práctica, las redes de clientes, redes de servidores, redes de invitados, VoIP y gestión deben considerarse por separado. Para la primera prueba productiva, este ejemplo debe incluir un caso de prueba breve: cliente definido, dirección de destino específica, Rule ID esperado, NAT Rule ID esperado y una mirada a Log Viewer o Central/Syslog. Sin este paso de aprobación, no queda claro si la regla realmente procesa la conexión esperada.

Área de encabezado: estado, nombre, acción y registro

Estado de la regla

Estado de la regla activa o desactiva la regla.

Generalmente hay una nueva regla activa. Para reglas preparadas, puede desactivar el estado y activar la regla solo más tarde. Las reglas desactivadas se deben verificar periódicamente para que no queden reglas de prueba o migración antiguas en la configuración.

Ejemplo práctico: Se prepara una nueva regla para un servidor pero solo se activa en la ventana de mantenimiento.

Nombre de la regla

El nombre debería dejar claro de inmediato lo que hace la regla.

Buenos nombres:

  • LAN_to_WAN_Clients
  • Guest_to_WAN_WebOnly
  • Server_to_WAN_Updates
  • VoIP_to_WAN_SIP_RTP
  • WAN_to_DMZ_HTTPS_Webserver

Nombres como Rule1, Test, Allow o Internet son menos útiles porque ya no se puede saber qué tarea tiene la regla.

Descripción

La descripción es importante para operaciones, soporte y auditorías. Debería decir:

  • por qué existe la regla
  • quién solicitó la regla
  • qué restricciones se establecieron deliberadamente
  • si hay un ticket, un proyecto o una fecha de vencimiento

Ejemplo:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

En el artículo Sophos Firewall documentando con sensatez las reglas se describe con más detalle cómo utilizar este campo correctamente y documentar las reglas del firewall de manera comprensible.

Rule position

Rule position especifica dónde se insertará la nueva regla.

  • Top: Sólo para reglas, reglas de bloque o pruebas muy específicas.
  • Bottom: A menudo es útil para nuevas reglas estándar.
  • Above rule: Si una norma debe entrar en vigor específicamente antes que una norma existente.
  • Below rule: Si una regla debe seguir específicamente una regla existente.

Regla básica: lo específico antes que lo general. Una regla para un servidor individual o una aplicación específica suele tener un nivel superior a una regla general de Internet.

Rule group

Rule group es una agrupación organizativa. El grupo en sí no es una frontera de seguridad ni su propio motor de políticas. El firewall continúa verificando cada regla de arriba a abajo.

Ejemplos de grupos útiles incluyen:

  • Internet Access
  • Server Rules
  • DNAT
  • VPN
  • Guest
  • Management
  • Block Rules

En entornos pequeños, None puede ser suficiente. En entornos más grandes, vale la pena realizar una agrupación clara desde el principio; de lo contrario, la base de reglas se vuelve confusa rápidamente.

Acción

Acción determina qué sucede con el tráfico coincidente.

  • Accept: Se permite el tráfico. Reglas de permiso normales.
  • Drop: El tráfico se descarta silenciosamente. Bloquear reglas donde el cliente no debería recibir respuesta.
  • Reject: Se rechaza el tráfico y el cliente recibe una respuesta. Solución de problemas o reglas de bloqueo interno.
  • Protect with web server protection: Se aplica la protección WAF. Protección del servidor web, no para las reglas normales de LAN a WAN.

Para reglas normales de cliente o servidor, normalmente se utiliza Accept. Para las reglas de bloqueo, Drop es más silencioso, Reject suele ser más agradable para la resolución de problemas.

Registrar el tráfico del firewall

Registrar el tráfico del firewall casi siempre debe estar activado para reglas importantes.

Sin iniciar sesión, más adelante faltará información importante en el Visor de registros. Muchos casos de resolución de problemas fallan no debido a la regla en sí, sino porque no hubo registro y no es posible ver qué regla se aplicó realmente.

Importante: El firewall normalmente registra las sesiones del firewall cuando finaliza una conexión y ocurre un evento Destroy. No todas las conexiones aparecen en el momento exacto en que el cliente las inicia.

Para que los registros sean visibles localmente, en Sophos Central o mediante Syslog, System services > Log settings también debe configurarse adecuadamente. Para un almacenamiento más prolongado, tiene sentido Sophos Central Firewall Reporting o un servidor Syslog. Más sobre esto: Habilitar informes de firewall central y Enviar Sophos Firewall Syslog de forma segura a SIEM.

Para reglas productivas, el registro no debe verse simplemente como un gancho para la resolución de problemas. También es la base para las revisiones: ¿se sigue utilizando la regla, a qué fuentes se aplica, qué objetivos se abordan realmente y si una regla es demasiado amplia?

Fuente, Zona y Horario

En el área Fuente defines de dónde proviene el tráfico.

Source zones

Source zones es la zona de donde proviene el tráfico.

Ejemplos:

  • LAN para redes de clientes internos
  • VPN para usuarios de acceso remoto
  • DMZ para redes de servidores
  • Guest para invitados-WLAN
  • WAN para tráfico entrante de Internet

Ejemplo práctico: Se selecciona LAN para una regla de Internet desde clientes a Internet. Para una regla DNAT de un servidor externo a uno interno, normalmente se utiliza WAN como zona de origen en la regla de firewall asociada.

Source networks and devices

Source networks and devices reduce la fuente con mayor precisión.

Los objetos posibles son, por ejemplo:

  • anfitriones individuales
  • Redes
  • rangos de IP
  • Grupos anfitriones
  • Anfitriones FQDN
  • Objetos de país

Para empezar, el Any parece cómodo, pero suele ser demasiado ancho. Es mejor una red de cliente específica, un grupo de hosts o un objeto de red con un nombre claro.

Ejemplo práctico: en lugar de Any en el código fuente, utilice net_LAN_Clients. Los servidores, impresoras, invitados y dispositivos de administración tienen sus propias reglas.

Durante el horario programado

Durante el horario programado determina cuándo se aplica la regla.

Valores típicos:

  • All the time
  • Horas de trabajo
  • Ventana de mantenimiento
  • liberaciones temporales

Los horarios son útiles si el acceso solo se debe permitir en determinados momentos. Al solucionar problemas, siempre debe comprobar si la hora, la zona horaria y la programación del firewall son realmente correctas.

Ejemplo práctico: el acceso de mantenimiento externo a un servidor solo está permitido durante una ventana de mantenimiento definida.

Destino y servicios

En el área Destino y servicios defines dónde se permite el tráfico y qué puertos o protocolos se permiten.

Destination zones

Destination zones es la zona objetivo.

Ejemplos:

  • WAN para acceso a internet
  • DMZ para servidores en un DMZ
  • LAN para objetivos internos
  • VPN para usuarios remotos o rutas de sitio a sitio

Ejemplo práctico: WAN se utiliza para el tráfico de Internet del cliente. Server o DMZ se pueden utilizar para que los clientes accedan a un servidor interno si estas zonas se crean en consecuencia.

Destination networks

Destination networks reduce el objetivo con mayor precisión. Para las reglas de Internet del cliente, Any suele ser un comienzo viable. Para servidores, redes de administración o acceso a VPN, los objetivos deberían limitarse significativamente más.

Ejemplos:

  • Any para acceso general a Internet
  • Host FQDN como updates.vendor.com
  • Objeto host de un servidor interno
  • Objeto de red de una estación remota vía VPN
  • Objeto de país para reglas Geo-IP

Ejemplo práctico: un servidor de respaldo solo puede ir a los destinos de respaldo en la nube del fabricante, no a Any.

Services

Services son definiciones de protocolo y puerto.

Ejemplos:

  • HTTP para TCP 80
  • HTTPS para TCP 443
  • DNS para TCP/UDP 53
  • NTP para UDP 123
  • propio Services como Synology_5555

Services debe elegirse lo más estrictamente posible. Any sólo tiene sentido si realmente se deben permitir todos los protocolos o si se trabaja conscientemente con otros controles.

Ejemplo práctico: Para clientes web normales, un grupo con HTTP, HTTPS, DNS y NTP suele ser suficiente. Sólo se permite el acceso al servidor desde Internet al servicio realmente publicado.

Match known users

Con Match known users, la identidad del usuario pasa a formar parte de la coincidencia. La regla ya no se aplica sólo a las direcciones IP, sino también a usuarios o grupos conocidos.

Esto tiene sentido si:

  • Las políticas web deben aplicarse por grupo AD
  • Los informes deben estar relacionados con el usuario.
  • diferentes grupos de usuarios obtienen diferentes derechos de Internet
  • MFA, Portal cautivo o SSO ya están configurados correctamente

Obstáculo: si la autenticación no funciona correctamente, es posible que la regla no coincida. Luego, el tráfico cae a una regla más general a continuación o se reduce según la regla de eliminar todo.

Para las pruebas iniciales, suele ser mejor comenzar sin coincidencias de usuarios y agregar criterios de usuario más adelante.

Si se utiliza la coincidencia de usuarios, no debería haber una regla alternativa amplia que permita el mismo tráfico sin referencia del usuario. De lo contrario, la regla de usuario parece limpia, pero los usuarios desconocidos terminan usando la regla general. Por lo tanto, cuando se acepta, el Log Viewer debería mostrar el usuario, el grupo y el Rule ID.

Agregar exclusión

Con Agregar exclusión el tráfico se puede excluir de una regla. El firewall solo omite esta regla si todos los criterios de exclusión establecidos coinciden y luego verifica la siguiente regla.

Las exclusiones pueden incluir Source zones, Source networks and devices, Destination zones, Destination networks y Services.

Ejemplo práctico: una regla general de Internet de un cliente utiliza filtros web. Sin embargo, un servidor de actualización específico debería ejecutar su propia regla con otras características de seguridad. Entonces puedes excluir este servidor de la regla general.

Las exclusiones son poderosas, pero dificultan la lectura de las reglas. Si una regla contiene muchas excepciones, una regla específica separada suele ser más comprensible.

Create linked NAT rule

Con Create linked NAT rule se puede crear una regla NAT de origen directamente desde la regla del firewall. Esta regla NAT vinculada aparece en la tabla de reglas NAT.

Esto parece conveniente para los principiantes, pero en la práctica las reglas NAT independientes suelen ser más claras. Si una regla NAT genérica ya cubre el mismo tráfico, no debe crear una regla NAT vinculada adicional.

Para una regla normal de cliente a Internet, la regla SNAT predeterminada con MASQ suele ser suficiente, siempre que esté activa y se ajuste correctamente a la base de reglas. Importante: NAT no permite el tráfico por sí solo. NAT traduce direcciones o puertos. La regla de firewall adecuada aún decide si se permite el tráfico.

Más sobre esto: Comprensión de NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Filtrado web

En el área Filtrado web se configura la política web, el análisis de malware y el comportamiento del filtro web.

Web policy

Web policy controla el acceso web a través de categorías, usuarios, grupos, grupos de URL y reglas.

Ejemplo práctico: se utiliza una política web para clientes que bloquea malware, phishing, contenido para adultos y categorías de riesgo, pero permite aplicaciones comerciales.

Si no se establece ninguna política web, el filtrado web basado en categorías no se realizará a través de esta opción.

En Sophos Firewall Uso de categorías web y alertas instantáneas se describe cómo planificar categorías, grupos de URL, políticas web y alertas instantáneas en conjunto.

Aplicar modelado de tráfico basado en categorías web

Esta opción aplica la configuración del tráfico según las categorías web. Sólo tiene sentido si se utilizan reglas de configuración del tráfico o políticas de categorías web adecuadas.

Ejemplo práctico: las categorías de streaming son limitadas, las aplicaciones empresariales siguen siendo las preferidas.

Block QUIC protocol

QUIC utiliza UDP 80 y UDP 443. Muchos navegadores utilizan QUIC para los servicios de Google y otras aplicaciones web modernas.

Si el filtrado web o el escaneo de malware para el tráfico web es importante, Block QUIC protocol debe dejarse habilitado en muchos entornos. Los navegadores suelen recurrir a HTTPS sobre TCP normal, lo que es más fácil de controlar y comprobar.

Más sobre esto: Sophos Firewall Bloquear QUIC y HTTP/3 correctamente.

Scan HTTP and decrypted HTTPS

Esta opción escanea HTTP y HTTPS ya descifrado en busca de malware.

Importante: esta opción no descifra HTTPS automáticamente. Para que HTTPS realmente se verifique, se requieren reglas de inspección SSL/TLS apropiadas en Rules and policies > Reglas de inspección SSL/TLS.

Ejemplo práctico: si TLS Inspection está activo para LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS puede verificar los archivos descargados en el tráfico HTTPS descifrado.

Más sobre esto: Implementar gradualmente TLS Inspection a Sophos Firewall.

Utilice protección de día cero

Utilice la protección de día cero envía descargas sospechosas a Sophos Zero-Day Protection para su posterior análisis. Esto es útil para reglas de cliente y servidor que desean verificar descargas de Internet.

La función requiere una licencia adecuada y puede provocar retrasos según el tipo de archivo y la política.

Escanear FTP en busca de malware

Esta opción analiza el tráfico FTP en busca de malware. Sólo es relevante si realmente se utiliza FTP y normalmente se permite el Services coincidente.

FTP se ha vuelto menos común en los entornos modernos, pero todavía ocurre en sistemas heredados, controles de máquinas o mecanismos de actualización más antiguos.

Utilice proxy web en lugar de DPI engine

Sophos Firewall puede verificar el tráfico web a través de DPI engine o mediante Web Proxy.

Para configuraciones modernas, DPI suele ser la mejor opción predeterminada porque puede manejar el tráfico HTTP y SSL/TLS en todos los puertos. El proxy web sigue siendo útil si se requieren funciones de proxy especiales, por ejemplo, aplicación de SafeSearch, restricciones de YouTube, restricciones de dominio de aplicaciones de Google, protección pharming, caché web o proxy principal.

Si Usar proxy web en lugar de DPI engine no está habilitado, la regla funciona en modo DPI.

Descifrar HTTPS durante el filtrado de proxy web

Esta opción pertenece al modo proxy web. Solo es relevante si Usar proxy web en lugar de DPI engine está activado y HTTPS se va a descifrar en modo proxy.

En el modo DPI, el descifrado HTTPS no se controla aquí, sino mediante reglas de inspección SSL/TLS.

Synchronized Security Latido del corazón

Con Configurar Synchronized Security Heartbeat, el estado de Sophos Endpoint se puede incluir en la regla de firewall.

Opciones típicas:

  • Establecer el estado mínimo para los dispositivos de origen
  • Bloquear clientes sin latidos
  • Establecer el estado mínimo para los dispositivos de destino
  • Bloquear solicitudes a destinos sin latido

Esto es sólido, pero sólo tiene sentido si Sophos Endpoint, Sophos Central y Security Heartbeat están configurados correctamente.

Ejemplo práctico: Los clientes con Security Heartbeat rojo ya no pueden acceder a los servidores o ya no tienen acceso a Internet.

Para una primera regla de cliente, no debe activar el latido a ciegas; de lo contrario, puede bloquear dispositivos que no pueden enviar ningún latido.

Otras características de seguridad

Identificar y controlar aplicaciones (Control de aplicaciones)

Se selecciona una política de filtro de aplicaciones a través de Identificar y controlar aplicaciones (control de aplicaciones).

Esto permite reconocer y controlar aplicaciones, por ejemplo:

  • Visor de equipo
  • Puerta
  • Mensajeros
  • Transmisión
  • Almacenamiento en la nube
  • Herramientas de control remoto

Application Control requiere una licencia adecuada. En la práctica, esta característica está incluida en los paquetes Sophos Firewall con Protección web, por ejemplo Protección estándar, Protección Xstream o Protección Epic.

TLS Inspection suele ser crucial para la detección de aplicaciones en tráfico cifrado. Sin descifrado, según el servicio, el firewall solo ve los nombres de host, SNI, información de certificados o IP y no el contenido completo.

El proceso personalizado para filtros, vinculación de reglas, registros y verificación de falsos positivos está disponible en Sophos Firewall Configuración y prueba de Application Control.

Apply application-based traffic shaping policy

Esta opción aplica el modelado del tráfico definido en la Política de aplicación o en el Objeto de aplicación.

Ejemplo práctico: los equipos de Microsoft deben ser reconocidos y priorizados con una política de configuración de tráfico específica. Luego se debe seleccionar la política Application Control adecuada y se debe aplicar la política de configuración de tráfico basada en aplicaciones.

Si ya configuró una política de configuración de tráfico explícita en el campo Configurar tráfico, se debe documentar claramente qué política debe tener prioridad y por qué.

Detectar y prevenir exploits (IPS)

Se selecciona una política IPS en Detectar y prevenir exploits (IPS).

IPS comprueba el tráfico en busca de patrones de ataque y exploits conocidos. Se utiliza una política diferente para el tráfico de clientes a Internet que para el tráfico de servidores o servicios publicados.

Ejemplos prácticos:

  • Regla de cliente LAN_to_WAN: Política de cliente o LAN a WAN IPS
  • Regla DNAT al servidor web: servidor o política IPS del servidor web
  • Regla de VoIP: Pruebe con cuidado porque los perfiles IPS agresivos pueden alterar la VoIP

Los IPS no deberían activarse en todas partes con la política más dura. Una política de IPS demasiado amplia o incorrecta puede interrumpir el tráfico legítimo o crear una carga innecesaria.

El artículo dedicado Sophos Firewall Configure IPS y pruébelo de forma segura explica con más detalle la activación global, el estado de la licencia, la selección de políticas, el registro y el análisis de falsos positivos.

Dar forma al tráfico

Con Configurar tráfico se puede aplicar una política de configuración de tráfico directamente a la regla. Esto es relevante para:

  • VoIP
  • Reuniones en línea
  • Tráfico de respaldo
  • Invitado WLAN
  • rutas lentas WAN

Ejemplo práctico: el invitado WLAN obtiene una política de límite para no desplazar el tráfico empresarial.

Más información sobre esto: Configurar la configuración del tráfico de aplicaciones en Sophos Firewall.

DSCP marking

DSCP marking marca los paquetes según la calidad del servicio en dispositivos de red descendentes.

Esto sólo tiene sentido si los conmutadores, enrutadores o dispositivos WAN también evalúan estos valores DSCP. El Sophos Firewall puede marcar, pero el resto de la red debe tratar estas marcas de forma coherente.

Ejemplo práctico: el tráfico VoIP recibe un marcado DSCP para que los switches y routers WAN traten este tráfico de forma preferente.

Escanear con NDR Inteligencia activa contra amenazas

Escanee con NDR Inteligencia de amenazas activa utiliza Sophos NDR Threat Intelligence para evaluar adicionalmente el tráfico de red.

Esta opción solo es útil si el entorno utiliza los componentes Sophos Central y NDR requeridos. En muchos entornos no es la primera opción para una regla básica, pero puede ser una valiosa adición en redes con mayor supervisión.

Escanear el contenido del correo electrónico

El área Escanear contenido de correo electrónico se refiere a los protocolos de correo electrónico.

Posibles opciones:

  • Scan IMAP
  • Scan IMAPS
  • Scan POP3
  • Scan POP3S
  • Scan SMTP
  • Scan SMTPS

Si activa protocolos allí, los puertos estándar apropiados también deben incluirse en el Services de la regla o agregarse mediante Agregar puertos.

Esta área a menudo no es relevante para las reglas normales del cliente web. Debe planificarlo conscientemente para los servidores de correo o el tráfico de correo del cliente.

Ejemplo práctico: un servidor de correo interno puede enviar SMTP externamente. Luego se crea una regla de servidor separada, se activa el registro y se verifica que el escaneo de correo electrónico coincida con la arquitectura de correo.

Verificar después de guardar

Después de guardar, debes probar la regla y no simplemente asumir que todo funciona correctamente.

Para comprobar:

  1. ¿Está la regla en la posición correcta?
  2. ¿Está activo Registrar el tráfico del firewall?
  3. Cuando cambiaron las reglas, ¿se restableció el contador de visitas o se creó una nueva prueba clara?
  4. ¿Coincide la regla en el Visor de registros?
  5. ¿Aparece el firewall esperado Rule ID?
  6. ¿Se aplica la regla NAT deseada?
  7. ¿Funciona el DNS?
  8. ¿Se aplican los filtros web IPS, Application Control y TLS Inspection como se esperaba?
  9. ¿Hay caídas inesperadas o errores de SSL/TLS?

El artículo Prueba de la regla de firewall con Log Viewer, Policy Test y Packet Capture ayuda a realizar una comprobación limpia.

Al realizar cambios productivos, tiene sentido una pequeña comparación del antes y el después:

  • Existe un punto de copia de seguridad o restauración: El desmantelamiento sigue siendo posible si la norma produce efectos secundarios.
  • Registro de auditoría o ticket de cambio anotado: más adelante quedará claro quién hizo el cambio y cuándo.
  • Caso de prueba definido de antemano: El éxito no sólo se juzga por el sentimiento.
  • Sólo un cambio por prueba: Causa y efecto siguen siendo comprensibles.
  • Log Viewer o registros centrales comprobados: los verdaderos Rule ID y NAT ID son visibles.
  • Decisión de desmantelamiento documentada: las reglas de prueba temporales no permanecen activas permanentemente.

Si tiene varios firewalls o grupos administrados centralmente, también debe verificar si el cambio ha llegado al dispositivo o grupo correcto. Para Sophos Central, la Cola de tareas de administración de firewall ayuda; Los cambios locales se pueden rastrear con Registros de seguimiento de auditoría.

Operación y revisión periódicas

Una regla de firewall no está lista sólo porque se haya guardado. Las buenas reglas tienen un propósito claro, se registran, se pueden probar y se pueden verificar nuevamente más tarde. Especialmente en entornos maduros, muchos riesgos surgen no de una sola regla incorrecta, sino de antiguas excepciones, reglas demasiado amplias o reglas sin dueño.

Vale la pena seguir una rutina sencilla para las revisiones periódicas:

  • ¿Se seguirá dictando la regla?: Las reglas no utilizadas a menudo se pueden desactivar y eliminar más adelante.
  • ¿La fuente sigue siendo correcta?: Las redes de clientes, redes de servidores y áreas VPN cambian con el tiempo.
  • ¿Sigue estando justificado el Any?: Se deben documentar deliberadamente fuentes amplias, objetivos o Services.
  • ¿El registro es activo y útil?: Sin registros, los análisis y auditorías posteriores son significativamente más débiles.
  • ¿Siguen siendo compatibles NAT, filtro web, IPS y TLS Inspection?: Las funciones de seguridad pueden funcionar de manera diferente después de actualizaciones, cambios de aplicaciones o cambios de certificados.
  • ¿Hay una fecha de vencimiento?: De lo contrario, las reglas de soporte o proyecto temporal permanecen activas permanentemente.

Para las reglas críticas, también debe documentar quién es técnicamente responsable. Esto es particularmente importante para los servicios publicados, reglas VPN, acceso de administración, recursos compartidos de proveedores de servicios y reglas con Any en Services o destino.

¿Nueva regla, cambiar o desactivar la regla existente?

No todas las solicitudes nuevas necesitan inmediatamente una nueva regla de firewall. Demasiadas reglas similares hacen que la lista sea confusa, pero las reglas que están demasiado resumidas rápidamente se vuelven demasiado amplias. Una simple decisión ayuda antes de guardar algo en el WebAdmin:

  • Mismo origen, mismo destino, mismo propósito, sólo un servicio adicional: Ampliar regla existente. La norma sigue siendo técnicamente coherente y más fácil de comprobar.
  • Mismas redes, pero diferentes requisitos de protección, diferente registro o diferente propietario: Crea tu propia regla. Los filtros web, IPS, TLS Inspection, NDR o el registro se pueden comprobar por separado.
  • Proveedor de servicios temporal o acceso de soporte: Crea tu propia regla temporal. El propietario, el billete, la fecha de caducidad y la ventana de prueba permanecen claramente visibles.
  • Servidores, invitados, VoIP, IoT o gestión se ven afectados: Consulta tu propia regla o zona. Los diferentes riesgos no deberían desaparecer en la regla de Internet de un cliente.
  • Una regla no está clara o es antigua: Primero desactivar y observar. La eliminación directa elimina la posibilidad de comprobar visitas, registros y dependencias de forma controlada.
  • Una regla es ciertamente superflua después de una revisión: Eliminar después de la copia de seguridad y la documentación. El conjunto de reglas se vuelve más pequeño sin romper dependencias que funcionan a ciegas.

Para cambios operativos normales, este proceso es sólido:1. Anote el propósito, propietario, ticket y tráfico esperado. 2. Verifique las reglas existentes para el mismo origen, destino, servicio y Rule group. 3. Decida si se amplía una regla existente o si su propia regla es más limpia. 4. Para cambios productivos, planifique copias de seguridad, registros de auditoría y casos de prueba. 5. Después de guardar Log Viewer, Rule ID, verifique la decisión de NAT y las características de seguridad afectadas.

Si la decisión falla principalmente debido a la falta de documentación, primero se debe dar seguimiento a las reglas Sophos Firewall deben documentarse de manera significativa. Si no está claro si todavía se necesita una regla existente, una prueba controlada con Probar regla de firewall con Log Viewer, Policy Test y Packet Capture ayuda.

Organizar los contadores de visitas correctamente

Los contadores de visitas ayudan con la limpieza, pero no son una prueba completa. Una regla de emergencia que rara vez se utiliza aún puede ser importante. Por el contrario, una regla amplia puede tener muchos resultados aunque permita demasiados.

Para las revisiones, siempre debe combinar los contadores de visitas con Log Viewer, la descripción de la regla y el caso de uso real. Si una regla no está clara, no debe eliminarse inmediatamente. Un proceso controlado es mejor: aclarar el propósito, activar el registro, definir ventanas de prueba, informar a las partes interesadas y solo entonces desactivarlo o eliminarlo.

Hacer que los cambios sean rastreables

Debería haber una copia de seguridad disponible antes de cambios importantes en las reglas. Audit Trail y Config Studio ayudan a comprobar las diferencias de forma comprensible. El proceso práctico se encuentra en Sophos Firewall Verificar registros de seguimiento de auditoría y Sophos Firewall Usar Config Studio.

Si se ajustan muchas reglas, no solo se debe comparar la configuración, sino también ejecutar casos de prueba reales. Una regla puede ser sintácticamente correcta y aun así permitir tráfico incorrecto, utilizar la ruta NAT incorrecta o interrumpir una aplicación a través de IPS, filtrado web o TLS Inspection.

Errores típicos

La regla está demasiado abajo: Una regla más general anterior coincide con el tráfico primero.

La fuente es demasiado amplia: Any funciona, pero deja las reglas poco claras y aumenta la superficie de ataque.

El destino es demasiado amplio: Rara vez se debe permitir que los servidores o las redes de administración accedan a Internet con Any.

Services son demasiado anchos: Any permite mucho más de lo necesario. Son mejores Services específicos o grupos de servicios.

El registro no está activo: La información más importante falta en el Log Viewer.

Se olvidó IPv6: IPv4 está regulado adecuadamente, pero IPv6 se ejecuta según otras reglas o permanece abierto inconscientemente.

Rule group ciertamente está confundido: Un grupo de reglas solo mejora la descripción general. Un grupo de reglas no es su propio límite de seguridad y no cambia la lógica de evaluación.

HTTPS no se analiza: Scan HTTP and decrypted HTTPS está activo, pero no existe una regla de inspección o descifrado SSL/TLS adecuada.

El filtro web no funciona: No se ha establecido ninguna política web, usuario incorrecto, zona de origen incorrecta o QUIC no bloqueado.

La coincidencia de usuarios no funciona: La autenticación, el SSO AD, el portal cautivo o la asignación de usuarios no funcionan correctamente.

Falta NAT: La regla del firewall permite el tráfico, pero SNAT/MASQ no encaja.

La función de seguridad no coincide con el tráfico: Una política de IPS, una opción de proxy o una opción de escaneo de correo electrónico incorrectas pueden interrumpir el tráfico legítimo. Si después de estos puntos no queda claro por qué el tráfico funciona de manera diferente a lo esperado, debe realizar pruebas estructuradas adicionales con Log Viewer, Policy tester y Packet Capture. El procedimiento adecuado se encuentra en Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.

Preguntas frecuentes

¿En qué orden comprueba Sophos Firewall las reglas del firewall?

Sophos Firewall verifica las reglas de arriba a abajo. La primera regla coincidente gana. Por lo tanto, las reglas específicas, las reglas de bloque y los casos especiales deben anteponerse a las reglas generales.

¿Debería utilizar Cualquiera en las reglas de firewall de Sophos?

Any puede ser útil para pruebas o reglas muy generales de Internet, pero debe justificarse deliberadamente. Para servidores, administración, VPN, acceso de proveedores de servicios y redes críticas, fuentes concretas, objetivos y Services son significativamente mejores.

¿Necesita sus propias reglas de firewall de Sophos para IPv6?

Sí. Las reglas de IPv4 e IPv6 se tratan por separado. En entornos de doble pila, IPv6 debe permitirse, bloquearse o introducirse deliberadamente de forma controlada. De lo contrario, una base de reglas IPv4 debidamente reforzada puede ser eludida por el tráfico IPv6 ignorado.

¿Por qué no puedo ver una conexión permitida en el visor de registros?

A menudo, Registrar el tráfico del firewall no suele estar activo o el tipo de registro adecuado no está activado para los registros locales, Sophos Central o Syslog en System services > Log settings. Además, algunas sesiones solo aparecen como entrada de registro cuando finaliza la conexión.

¿Una regla de firewall reemplaza una regla NAT?

No. La regla del firewall decide si el tráfico está permitido o bloqueado. NAT traduce direcciones o puertos. Para acceso a Internet, DNAT y VPN, la regla de firewall y la regla NAT deben coincidir.

¿Las reglas de firewall también controlan WebAdmin, SSH o VPN Portal?

No como el tráfico normal. El acceso a los servicios de firewall locales se controla principalmente a través de Device Access y Local Service ACL. Las reglas de firewall normales son responsables del tráfico a través del firewall.

¿Cómo se prueba limpiamente una regla de Sophos Firewall?

Primero defina un caso de prueba concreto: origen, destino, servicio, regla esperada y decisión NAT esperada. Luego use Log Viewer, Probador de políticas y, si es necesario, Packet Capture. Para casos complejos, debe restablecer los contadores de visitas o utilizar una ventana de prueba clara.

¿Deberían eliminarse inmediatamente las reglas de firewall poco claras?

No. Las reglas productivas poco claras primero deben documentarse, registrarse y desactivarse de forma controlada. Sólo cuando se hayan verificado el propósito, el propietario, las visitas y los registros, tendrá sentido la eliminación.