Configurar la Protección Web de Sophos Firewall con Políticas Web

La Protección Web de Sophos Firewall controla qué sitios web, categorías y contenidos web pueden acceder los usuarios. En la práctica, la Protección Web no es simplemente una casilla de verificación. Una política web debe ser planificada profesionalmente, activada en una regla de firewall adecuada y luego probada con tráfico real.

Muchos errores ocurren porque una política web existe, pero no se aplica a ninguna regla de firewall activa. Otros problemas están relacionados con HTTPS, Inspección TLS, QUIC, reconocimiento de usuarios, orden de reglas o excepciones demasiado amplias. El flujo de trabajo lógico es: planificar la política, construir la regla, activarla, probarla y supervisarla en operación.

¿Qué artículo de Protección Web es adecuado?

La Protección Web se superpone con reglas de firewall, Inspección TLS, QUIC, informes y excepciones. Dependiendo de la tarea, un artículo más específico puede ser más adecuado:

• Configurar Protección Web y Políticas Web en general: Este artículo.
• Comprender Single o Dual Engine, los errores de escaneo, los límites de tamaño y una prueba real de malware: Configurar y probar el escaneo de malware en Sophos Firewall.
• Evaluar categorías web, grupos de URL y alertas instantáneas: Utilizar categorías web y alertas instantáneas de Sophos Firewall.
• Desencriptar y verificar tráfico HTTPS: Implementar correctamente la Inspección TLS de Sophos Firewall.
• Distribuir certificado CA para clientes gestionados: Distribuir certificado CA de Sophos Firewall para Inspección TLS.
• Clasificar QUIC y HTTP/3 en problemas de filtrado web: Bloquear correctamente QUIC y HTTP/3 en Sophos Firewall.
• Determinar qué regla de firewall y política realmente se aplica: Probar reglas de Sophos Firewall con Log Viewer, Policy tester y Packet Capture.
• Evaluar eventos web y de seguridad a largo plazo: Central Firewall Reporting o Enviar Syslog a SIEM.

Así se mantiene el análisis limpio: primero debe quedar claro si la regla de firewall coincide. Luego se verifica la política web, categoría, contexto de usuario, QUIC, Inspección TLS y registro.

Qué controla la Protección Web

La Protección Web consta de varios componentes. No todos los componentes deben utilizarse en cada entorno, pero las interrelaciones deben estar claras.

• Política Web: Reglas para accesos web permitidos, advertidos, bloqueados o basados en cuotas.
• Categorías web: Categorías de Sophos y categorías propias para sitios web.
• Grupos de URL: Listas de dominios propias para reglas de permitir o bloquear específicas.
• Tipos de archivos: Control de tipos de descarga o archivos específicos.
• Filtros de contenido: Términos o patrones para control de contenido.
• Excepciones: Excepciones específicas de comportamiento web, TLS o de escaneo.
• Search engine enforcement: SafeSearch y restricciones de YouTube.
• Advanced settings: restricciones de dominios de inicio de sesión de Google Apps y Microsoft Entra ID Tenant Restrictions.
• Registro e informes: Trazabilidad en Log Viewer, Reporting, Central o SIEM.

La Protección Web no reemplaza una base de reglas de firewall limpia. La regla de firewall decide primero qué tráfico de qué zona a qué zona de destino está permitido. La política web complementa esta regla con control web. Los fundamentos sobre el orden de las reglas, origen, destino, servicios y perfiles de seguridad se encuentran en Entender y construir reglas de Sophos Firewall.

Requisitos previos

Antes del despliegue, deben aclararse estos puntos:

• La Protección Web está licenciada o incluida en el paquete utilizado.
• Las redes de clientes afectadas tienen sus propias reglas de firewall.
• El registro está activo en las reglas relevantes.
• DNS y la hora del firewall funcionan correctamente.
• El reconocimiento de usuarios está aclarado, si las políticas deben aplicarse por usuario o grupo.
• La Inspección TLS está planificada si se deben verificar más detalladamente los contenidos HTTPS.
• QUIC/HTTP/3 se permite o bloquea conscientemente.
• Hay un grupo piloto y una vía de retroceso para sitios críticos para el negocio.

Es especialmente importante la separación por grupos objetivo. Una política web para clientes normales, servidores, invitados, usuarios de VPN y sistemas de gestión no debería ser la misma. Los servidores a menudo necesitan menos control de navegación, pero listas de destinos y actualizaciones más estrictas. Los invitados a menudo necesitan categorías y limitación de ancho de banda, pero no acceso a recursos internos.

Si las políticas web deben reaccionar a usuarios o grupos, el reconocimiento de usuarios debe funcionar. AD SSO, Captive Portal, STAS, SATC u otros métodos no deberían descubrirse recién durante el despliegue de la política web. En Log Viewer debe verse si una solicitud se evaluó como usuario conocido, como grupo o como Anybody o usuario desconocido.

Los criterios de usuario de la regla de firewall coincidente prevalecen sobre Users en la política web; esta puede reducir el alcance, pero no incluir usuarios excluidos por la regla.

Ruta mínima para una política web efectiva

Crear la política en Web > Policies con una decisión Allow/Block concreta. Editar una regla real en Rules and policies > Firewall rules con Action: Accept y valores correctos para Source Zone, Source Network, Destination Zone, Destination Network y Services; activar Log firewall traffic y asignar la política web en Web filtering. Comprobar únicamente el NAT existente, sin crear un comportamiento NAT nuevo solo para esta política. Antes y después, registrar la Rule ID y probar una URL permitida y otra bloqueada desde el contexto real de origen y usuario. Aceptar el cambio únicamente cuando Log Viewer muestre la Rule ID, la política y los resultados Allow/Block esperados.

Planificar la política web

Una buena política web no comienza en la interfaz, sino con algunas decisiones profesionales.

Definir grupos objetivo

Primero se determina para quién se aplica la política:

• Clientes estándar en LAN
• Portátiles gestionados a través de VPN
• Wi-Fi de invitados
• Salas de formación o entornos escolares
• Servidores con acceso HTTP/HTTPS saliente
• Puestos de trabajo de administradores privilegiados

Si la misma regla de firewall contiene varios grupos muy diferentes, la Protección Web será difícil de entender. Es mejor tener reglas y políticas separadas, por ejemplo, LAN_USERS_WEB, GUEST_WEB o SERVER_UPDATES_WEB.

Definir categorías y grupos de URL

La categoría highly objectionable criminal activity siempre se bloquea. Ni las reglas de la política web ni las excepciones pueden permitirla; además, SFOS oculta el dominio afectado en los registros y los informes.

Las categorías web de Sophos son buenas para un control amplio: Malware, Phishing, Contenido para adultos, Anonimizadores, Streaming, Redes sociales o Juegos. Los grupos de URL son mejores cuando se deben permitir o bloquear dominios específicos.

Uso típico:

• bloquear categorías de riesgo conocidas: Categoría web.
• permitir dominios SaaS específicos: Grupo de URL.
• tratar un dominio mal categorizado: Grupo de URL o categoría propia.
• restringir temporalmente el streaming: Política web con horario o cuota.
• página de advertencia en lugar de bloqueo duro: Política web con acción de advertencia.

Los grupos de URL no deben convertirse en una lista de recopilación desordenada. Si se ingresan muchos dominios, la lista necesita un propietario, un propósito y una fecha de revisión. Para listas muy grandes o dinámicas, a menudo son más adecuados Sophos Firewall Threat Feeds u otros componentes arquitectónicos.

Crear y utilizar URL Groups de forma segura explica cómo se relacionan los valores de dominio válidos, la lógica OR, el uso en Web Policies y las exclusiones TLS.

Para coincidencias puramente por dominio, los grupos de URL suelen ser mejores que las categorías web propias. Sophos indica que los grupos de URL son más eficientes y pueden generar menos falsos positivos. Las categorías propias son útiles cuando un dominio debe aparecer además de su categoría estándar de Sophos en una lógica de política propia.

Las palabras clave en categorías propias deben usarse con mucha prudencia. Las palabras clave se comprueban contra la URL completa, incluida la ruta y la consulta. Un permiso basado en una palabra clave puede coincidir de forma no deseada si la palabra aparece en un parámetro de consulta de otro dominio. Para decisiones de permitir, los dominios concretos o grupos de URL suelen ser más limpios; las reglas por palabra clave encajan mejor en casos de bloqueo estrechos.

Establecer reglas de permitir con precaución

Las reglas de permitir en las políticas web deben ser estrictas. Una regla de permitir en la parte superior puede hacer ineficaces las reglas de bloqueo posteriores, ya que las reglas de política web de Sophos se evalúan de arriba hacia abajo. Esto es especialmente relevante si un grupo de URL, una regla de tipo de archivo o una excepción de categoría está por encima de otras reglas.

En la práctica, se recomienda:

Una autorización por motivos de negocio situada por encima de reglas de bloqueo críticas solo se aplica a su alcance estrictamente definido. Si una categoría de riesgo debe permanecer bloqueada sin excepciones, su regla Block debe situarse por encima de todas las reglas Allow coincidentes. El orden se comprueba con un destino de negocio permitido y un destino bloqueado dentro del alcance de la excepción; permitir un dominio no debe autorizar accidentalmente todos los tipos de archivo ni todos los contenidos de ese destino.

• Reglas de advertencia o cuota para áreas grises.
• Tráfico web generalmente permitido solo al final.

Crear política web

La política web se crea en el siguiente menú:

Web > Policies

Proceso básico:

1. Seleccionar Add policy.
2. Asignar un nombre descriptivo, por ejemplo, LAN_USERS_STANDARD_WEB.
3. Añadir reglas.
4. Comprobar search engine enforcement, por ejemplo SafeSearch o YouTube restrictions.
5. Establecer policy quota status si se utilizan acciones Quota.
6. Comprobar Advanced settings, especialmente logging, reporting, descargas grandes, Google Apps y Microsoft Entra ID Tenant Restrictions.
7. Guardar la política.

Una regla dentro de la Política Web se crea con Add rule. El firewall crea primero una regla predeterminada desactivada que bloquea HTTP para Anybody. Después se ajustan los campos de forma deliberada:

1. Abrir Users y establecer conscientemente Anybody, usuarios concretos o grupos.
2. Abrir Activities y seleccionar All web traffic, User activities, Categories, URL Groups o File types.
3. Para contenido, abrir la pestaña separada Content filters, elegir el filtro, activar and with content y mantener HTTPS en Use action.
4. Establecer Action para HTTP: Allow, Warn, Block o Quota.
5. Comprobar la acción HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS o Quota HTTPS.
6. Establecer Constraints si la regla solo debe aplicarse a un horario.
7. Comprobar la posición de la regla dentro de la política.
8. Activar el estado de la regla.
9. Guardar la política.

En Users > Add new item, desmarcar Anybody si la regla solo debe aplicarse a determinados usuarios o grupos. En Activities > Add new item, desmarcar All web traffic antes de seleccionar Activities individuales. Confirmar cada selección con Apply selected items. De lo contrario, la regla seguirá siendo innecesariamente amplia pese a añadir objetos individuales. Las acciones HTTP se llaman Allow HTTP, Warn HTTP, Block HTTP y Quota HTTP; Use action aplica la misma decisión a HTTPS. En Content filters, esta vinculación es fija y no puede sustituirse por una acción HTTPS diferente.

Importar correctamente listas de filtros de contenido

Los Content filters se gestionan en Web > Content filters y después se seleccionan en Activities dentro de la regla de política web. Para listas de términos más grandes, Sophos admite un archivo .txt sencillo. El archivo puede contener como máximo 2,000 líneas y cada entrada puede tener hasta 80 caracteres, incluidos espacios y signos de puntuación.

El archivo contiene un término por línea y cada línea se evalúa como exact match. No admite encabezados, comentarios, metadatos ni columnas; usar UTF-8.

Procedimiento seguro:

1. Limpiar los términos en un editor de texto y colocar exactamente una entrada por línea.
2. Guardar el archivo como .txt con codificación UTF-8.
3. Importar la lista en Web > Content filters y asignarle un nombre descriptivo.
4. En Activities, abrir Content filters, seleccionar el filtro, activar and with content y mantener Use action.
5. Probar con un cliente piloto un término permitido y otro que coincida deliberadamente, y comprobar la acción en Log Viewer.

Si se rechaza la importación o algunos términos no se aplican, comprobar primero el número de líneas, la longitud de los caracteres, la codificación y los caracteres adicionales invisibles. Una regla Allow amplia situada por encima de la regla de Content filter no debe eludir la lista.

Para la importación, seleccionar específicamente Add content filter, introducir el nombre, elegir un archivo como blocked.txt mediante Choose file y hacer clic en Apply. Después, en la regla de política web, comprobar expresamente Block HTTP y Use action para HTTPS, confirmar el filtro con Apply selected items, activar Status y guardar la política. La importación por sí sola no activa ningún bloqueo. Para el piloto, es preferible una política propia y asignada a una modificación no controlada de la Default Policy compartida.

Crear tipos de archivo web personalizados

Sophos Firewall identifica los File types mediante la extensión del archivo o el encabezado MIME. Los tipos integrados no se pueden editar. Un tipo personalizado se crea en Web > File types > Add a partir de una plantilla adecuada y se completa con las extensiones necesarias sin punto inicial o con encabezados MIME. El mismo objeto se puede utilizar después en políticas de protección web y de correo electrónico.

En el cuadro de diálogo Add se debe indicar un nombre. Template es opcional e incorpora las extensiones y los encabezados MIME habituales de una categoría; esos valores se pueden ampliar para el tipo personalizado. A continuación se guarda con Save. Las extensiones no llevan un punto inicial: pdf es correcto y .pdf no. Los tipos integrados sirven como plantillas y no se pueden editar; cualquier cambio requiere un tipo personalizado.

SFOS incluye las categorías integradas All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files y Web files. La vista detallada en Web > File types es la referencia operativa para las extensiones y los encabezados MIME configurados actualmente. Por ejemplo, Compressed files incluye entradas como 7z, gz, rar, tar.gz y zip, mientras que Document files incluye entradas como docx, xlsx, pptx, odt, rtf y pdf. Antes de permitir una categoría, abra el tipo integrado concreto en su versión de SFOS y compárelo con el caso de uso real, en lugar de confiar únicamente en su nombre.

El nuevo tipo de archivo no tiene ningún efecto por sí solo. Debe seleccionarse en Activities > File types dentro de la regla de política web correspondiente. Después se comprueban la acción, el estado y el orden de la regla, y que la política web siga asignada a la regla de firewall que procesa realmente el tráfico.

La validación se realiza con una descarga representativa y con un archivo deliberadamente similar que no debería coincidir. En Log Viewer se comprueban la política web y la acción. Una coincidencia por extensión o encabezado MIME es una clasificación de política, no una prueba de malware ni de que se haya realizado un análisis Zero-Day. En HTTPS, la visibilidad necesaria también depende de la ruta de TLS Inspection. Si el tipo no coincide, compare primero el estado y el orden de la regla, el File Type seleccionado realmente, la respuesta Content-Type del servidor, la extensión visible y el estado de TLS Inspection. Un tipo MIME incorrecto o genérico enviado por el servidor puede hacer que la prueba se comporte de forma distinta a lo que sugiere el nombre del archivo.

Referencia de los tipos de archivo integrados

La siguiente referencia asigna las extensiones y los encabezados MIME documentados a las categorías integradas. Describe una clasificación, no un archivo permitido o seguro. Antes de realizar cambios, contrastar los valores con los de la propia instalación. All executable files también incluye ejecutables de Mac/Linux mediante encabezados MIME adicionales; Executable files está orientado a Windows. Dynamic files generan contenido web dinámico y Encoded files incluyen, entre otros, contenidos cifrados o codificados en binario. Las categorías pueden solaparse: por ejemplo, mdf figura en bases de datos y Disk Images, tar en documentos y tar.gz en archivos comprimidos. En particular, application/octet-stream en Backup files es un valor MIME genérico, no una prueba fiable de que se trate de un archivo de copia de seguridad.

All executable files

• Extensiones: exe, cmd, bat, com.
• Encabezados MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Extensiones: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• Encabezados MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

Backup files

• Extensiones: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• Encabezados MIME: application/octet-stream.

Compressed files

• Extensiones: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• Encabezados MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Extensiones: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• Encabezados MIME: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Extensiones: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• Encabezados MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensiones: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• Encabezados MIME: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

Disk image files

• Extensiones: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• Encabezados MIME: application/x-cdlink.

Document files

• Extensiones: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, wpd, wps, pdf.
• Encabezados MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

• Extensiones: jsp, asp, php, cgi, shtml.
• Encabezados MIME: text/x-script.perl, text/asp.

Encoded files

• Extensiones: bin, enc, hex, hqx, mim, mime, uue.
• Encabezados MIME: application/mac-binary, application/macbinary, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Extensiones: exe, cmd, bat, com.
• Encabezados MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Extensiones: bmp, gif, jpeg, jpg, pcx, png.
• Encabezados MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

• Extensiones: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• Encabezados MIME: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Extensiones: 8bi, arx, plugin, vst, xll.
• Encabezados MIME: application/x-visio.

System files

• Extensiones: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• Encabezados MIME: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Extensiones: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• Encabezados MIME: application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, Video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

• Extensiones: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• Encabezados MIME: application/atom+xml.

Agrupar correctamente las User Activities

En Web > User activities > Add, una User activity reúne Web Categories, File types y URL Groups en una actividad reutilizable. Estos elementos se evalúan con OR; basta con una coincidencia. Por tanto, el nombre no identifica a un usuario conectado, sino a una colección de criterios web.

La User Activity se selecciona después en Activities dentro de la regla de política web. Es útil cuando se emplea la misma combinación en varias políticas. Para validarla, se prueba al menos una coincidencia por cada tipo de objeto incluido y un caso similar que no debe coincidir.

En el cuadro de diálogo, establecer un nombre descriptivo como RISK_WEB_CONTENT, seleccionar las categorías, los tipos de archivo o los URL Groups necesarios mediante Add new item y guardar con Save. Show: All permite limitar los tipos de objeto mostrados cuando sea necesario. Por ejemplo, una actividad puede agrupar la categoría Spyware/Malware y una lista propia de dominios de prueba bloqueados: basta con que coincida uno de estos criterios para activar la acción Block de la regla de política. Para las pruebas, utilizar destinos inofensivos bajo control propio; no abrir una página real de malware.

Comprobar el orden de las reglas y las políticas migradas

Las reglas de política web se evalúan de arriba abajo. Por ejemplo, si una regla Allow para el tipo de archivo .mdb está por encima de una regla que bloquea una categoría, las descargas .mdb de esa categoría siguen permitidas. En modo DPI, la conexión inicial a la categoría puede permitirse hasta que se determine el tipo de archivo; si el archivo no coincide después, el firewall descarta la conexión sin mostrar una página de bloqueo. Si la categoría debe bloquearse siempre, su regla se coloca por encima de la regla Allow del tipo de archivo.

Las políticas antiguas migradas también tienen un límite estricto de 128 reglas por política. Si el origen contiene más reglas, SFOS usa únicamente las primeras 128. Por eso, las reglas adyacentes de User Activities, Categories, URL Groups, File types y Dynamic Categories se consolidan deliberadamente en Activities combinadas antes o después de la migración. El recuento, el orden y las pruebas reales de Allow y Block forman parte de la validación de la migración.

Las franjas recurrentes se crean como un horario independiente. El procedimiento y la diferencia con una regla de firewall controlada por horario se explican en Configurar horarios para reglas y políticas en Sophos Firewall.

Una política web por sí sola no tiene efecto. La política debe usarse luego en una regla de firewall. Este es uno de los errores de configuración más comunes.

Solo se consolidan reglas adyacentes con la misma asignación de usuarios, las mismas acciones HTTP/HTTPS y las mismas condiciones temporales. No deben perderse las diferencias en Content filters, Constraints ni en el orden. Antes de consolidar, guardar una copia de la política anterior o documentarla y registrar coincidencias y no coincidencias representativas para cada Activity. Después de consolidar, volver a comprobar estas decisiones; un menor número de reglas no demuestra por sí solo una protección equivalente.

Configurar Advanced settings de forma selectiva

Enable logging and reporting incluye la política en los registros y los informes; además, sigue siendo necesario activar Log firewall traffic en la regla de firewall coincidente. Prevent downloading of large files bloquea las descargas que superen el tamaño indicado. Elegir el umbral según las descargas realmente necesarias para el negocio y comprobarlo con archivos inofensivos por debajo y por encima del valor; este bloqueo de descargas no es lo mismo que un límite de tamaño para el escaneo de malware.

Add X-Forwarded-For header to outgoing HTTP requests transmite al destino la dirección IP de la solicitud HTTP original. No es una opción necesaria para el filtrado web. Activarla solo si existe una necesidad justificada, porque el servidor de destino recibe así información adicional del cliente; evaluar previamente la transmisión de direcciones internas y los requisitos de protección de datos. Para el piloto, documentar los valores anteriores y, si se producen efectos no deseados, revertir exactamente estos cambios.

Activar política web en regla de firewall

La regla de firewall se encuentra en:

Rules and policies > Firewall rules

Para el tráfico de Internet de clientes normales, generalmente se utiliza una regla de LAN o una zona de clientes a WAN. Allí se selecciona la política web adecuada en el área Web filtering.

Puntos de verificación en la regla de firewall:

• La zona de origen y las redes de origen coinciden con la red de clientes.
• La zona de destino es generalmente WAN.
• Los servicios incluyen HTTP/HTTPS o los servicios web deseados.
• Log firewall traffic está activo.
• En el área Web filtering se establece la política web correcta.
• Scan HTTP and decrypted HTTPS está activado cuando debe funcionar el escaneo de malware web o de contenido.
• Use Zero-day protection solo es útil si los archivos se escanean por HTTP o HTTPS desencriptado.
• Block QUIC protocol está configurado conscientemente.
• En la ruta transparente de la regla de firewall, Use web proxy instead of DPI engine está activado para SafeSearch, YouTube Restrictions y restricciones de Google Apps; en los demás casos y con Direct Proxy, el modo se elige según las funciones necesarias.
• La Inspección TLS se planifica por separado y no se confunde con la política web.

Sophos Firewall activa Block QUIC protocol de forma predeterminada cuando en la regla se selecciona una Política Web o se activa Scan HTTP and decrypted HTTPS. A menudo tiene sentido, porque QUIC no puede escanearse como el tráfico HTTPS clásico. Aun así, no conviene aceptar la opción sin pruebas: navegadores, servicios de Google, herramientas de colaboración y aplicaciones SaaS concretas pueden cambiar su comportamiento cuando QUIC está bloqueado.

Si en la misma regla de firewall también se usa Application Control, hay una superposición importante: algunas Micro Apps, por ejemplo cargas o descargas dentro de Dropbox o Gmail, se reconocen mediante detalles de URL. En entornos DPI, este reconocimiento requiere una regla SSL/TLS Inspection adecuada con desencriptado. Entonces Application Control puede evaluar esas Micro Apps aunque la Política Web no sea el punto de decisión principal.

Si una regla más general coincide por encima de la regla web deseada, el tráfico no alcanza la política web. En tales casos, ayuda Probar reglas de Sophos Firewall con Log Viewer y Packet Capture.

Clasificar HTTPS, Inspección TLS y QUIC

Una gran parte del tráfico web es HTTPS. Sin Inspección TLS, el firewall ve menos contenido. Las categorías, SNI, certificados, IP de destino, información de dominio y metadatos ayudan, pero no reemplazan una inspección completa del contenido.

DPI o Web Proxy?

En la Protección Web, se debe decidir temprano si la regla de firewall afectada utiliza el DPI Engine o el Web Proxy. Esta decisión influye en qué funciones se aplican y qué registros son relevantes más tarde.

• Modo DPI: estándar moderno para muchas reglas de Internet de clientes. La Inspección TLS se realiza a través de reglas de inspección SSL/TLS, Quota no es compatible.
• Modo Web Proxy: entornos con comportamiento de proxy explícito o cuota de política. Comportamiento del proxy, compatibilidad del navegador/cliente y registros del proxy deben verificarse conscientemente.

En muchas instalaciones, el modo DPI es el mejor punto de partida. Sin embargo, si se necesitan tiempos de cuota a través de Quota, una regla puramente DPI no es suficiente. Entonces, el modo Web Proxy debe planificarse y probarse conscientemente. Esta decisión debe tomarse antes del despliegue, ya que un cambio posterior puede generar otros patrones de error, registros y experiencias de usuario.

En una regla de firewall transparente, Transparent Web Proxy procesa únicamente los puertos 80 y 443; en otros puertos, el DPI Engine puede inspeccionar tráfico HTTP y SSL/TLS siempre que coincidan la regla de firewall y las reglas SSL/TLS Inspection. Direct Proxy es una ruta explícita independiente elegida por el cliente y no requiere necesariamente Use web proxy instead of DPI engine. Por ello, en cada prueba debe documentarse si el cliente usa la ruta transparente o su configuración de proxy explícita.

La decisión funcional completa, la migración piloto y las pruebas específicas de cada modo se explican en Comparar correctamente DPI Engine y Web Proxy.

Configurar Direct Web Proxy con un archivo PAC explica cómo se combinan el listener, archivo PAC, Device Access y una regla proxy funcional.

Los clientes solo IPv6 que acceden a destinos web solo IPv4 utilizan una ruta propia de dos reglas. NAT64 con Direct Web Proxy separa la Web Policy de la regla IPv6 de Application Control e IPS en el egreso IPv4.

Si Sophos Firewall debe reenviar sus Web Requests a un parent proxy, configurar un upstream proxy en WAN o LAN/DMZ guía por la ruta adecuada de reglas y NAT para cada topología.

Cuando varios usuarios RDS comparten una IP de servidor, Per-Connection AD SSO para hosts multiusuario puede distinguir las conexiones proxy HTTP y HTTPS individuales. No se aplica al tráfico sin proxy y, por tanto, debe diferenciarse deliberadamente de SATC.

Inspección TLS

Si se deben verificar de manera confiable las descargas, el escaneo de malware, ciertas categorías web o controles de contenido, se debe planificar la Inspección TLS. Para ello, se necesita un certificado CA confiable en los clientes, reglas TLS adecuadas, excepciones y un piloto limpio.

El despliegue se detalla en Desplegar gradualmente la Inspección TLS en Sophos Firewall. Para distribuir y validar el certificado CA, es adecuado Instalar el certificado CA de Sophos Firewall para escaneo HTTPS.

QUIC y HTTP/3

Los navegadores modernos a menudo utilizan QUIC o HTTP/3 sobre UDP 443. Esto puede interferir con las expectativas de filtrado web, inspección TLS y escaneo, si se desea verificar el tráfico HTTPS clásico sobre TCP.

En muchos entornos empresariales, es recomendable bloquear QUIC en las reglas de Internet de clientes, para que los navegadores vuelvan a HTTPS sobre TCP. Los detalles se encuentran en Bloquear correctamente QUIC y HTTP/3 en Sophos Firewall.

SafeSearch, YouTube y restricciones de inquilinos

SafeSearch y YouTube están en Search engine enforcement; Google Apps y Entra en Advanced settings.

Opciones típicas:

• Enforce SafeSearch para Google, Yahoo y Bing.
• Enforce YouTube restrictions para contenidos restringidos de YouTube.
• Restrict login domains for Google Apps para dominios de Google permitidos.
• Apply Microsoft Entra ID tenant restrictions para control de inquilinos en la nube de Microsoft.

La referencia de la API XML de SFOS 22/23 describe EnforceSafeSearch como aplicable únicamente cuando se deniegan las categorías Adult Content, Nudity y Porn en la Web Policy. Compruebe estas decisiones en la política realmente asignada al tráfico; activar la opción y cumplir los requisitos de proxy y HTTPS scanning no basta para acreditar esta condición documentada. Confirmar este requisito en API help del build instalado y comprobar después el valor guardado y su efecto; no asumir la misma representación en la interfaz de todas las compilaciones. Si la ayuda de la compilación instalada difiere, aclare la diferencia antes de confiar en SafeSearch.

En la ruta transparente de la regla de firewall, SafeSearch, YouTube Restrictions y las restricciones de Google Apps requieren Use web proxy instead of DPI engine; un Direct Proxy explícito puede ofrecer estas funciones de proxy sin esa opción de la regla de firewall. SafeSearch en Bing y Yahoo por HTTPS requiere además HTTPS scanning, mientras que las restricciones de inicio de sesión de Google Apps solo se aplican a dominios alojados por Google. Microsoft Entra ID Tenant Restrictions son independientes, necesitan valores de tenant correctos y deben probarse con inicios de sesión reales en la nube de Microsoft, no solo con una URL de ejemplo. Estos controles no sustituyen la gobernanza de identidades y aplicaciones en la nube de Microsoft 365 o Google Workspace.

En Apply Microsoft Entra ID tenant restrictions, Restrict-Access-To-Tenants contiene los inquilinos permitidos como una lista de nombres de dominio o IDs de dominio separados por comas, con un máximo de 256 caracteres en total. Restrict-Access-Context contiene el ID de dominio del inquilino que establece la restricción, con un máximo de 50 caracteres. Obtener estos valores de la administración del propio inquilino, no de una configuración de ejemplo ajena. Guardar previamente los valores existentes; después, probar en el piloto un inicio de sesión en un inquilino permitido y otro en uno no permitido y, si se producen errores, restaurar únicamente los valores modificados a su estado anterior.

Cuotas y páginas de advertencia

Las políticas web no solo pueden bloquear o permitir. Con acciones de advertencia o cuota, se puede informar conscientemente a los usuarios o permitir acceso limitado en el tiempo.

Ejemplos útiles:

• Los usuarios pueden confirmar conscientemente una advertencia para ciertas áreas grises.
• El streaming o las compras solo están permitidos por tiempo limitado.
• Los entornos escolares o de laboratorio permiten ciertas categorías solo durante tiempos definidos.

Importante: la cuota de política no es compatible en el modo DPI. Si se necesitan tiempos de cuota, se debe utilizar el modo Web Proxy. Esto debe decidirse temprano, ya que DPI y Web Proxy tienen diferentes características y límites.

La allowed time quota se define a nivel de Política Web y se aplica a todas las reglas de esa política que usan una acción Quota. Si dos categorías necesitan cuotas de tiempo distintas, son más limpias políticas web separadas que una sola política con expectativas de cuota mezcladas. Las cuotas se restablecen localmente a medianoche y no pueden configurarse en cero.

Policy Quota no se aplica a Content filters ni Dynamic Categories, y DPI no la admite. Los cambios no surten efecto si la política es inválida, no queda tiempo o ya hay una sesión Quota activa. En estos casos, comprobar primero el estado de la política y la sesión, en lugar de cambiar el valor repetidamente.

Esta Policy Quota se aplica a categorías web y no es la Surfing Quota basada en usuarios. La creación, asignación y comprobación del consumo de Surfing Quota y Network Traffic Quota siguen un procedimiento separado.

Al acceder a un destino con una acción Quota, primero aparece la página de cuota. El usuario elige una duración que no supere la cuota disponible y Proceed, o renuncia al acceso con Return to previous page. Al finalizar el periodo elegido, la página vuelve a aparecer; si la cuota se ha agotado, ya no se ofrece tiempo restante. Un Policy Override puede permitir acceso temporal en su lugar; en ese caso, la cuota no se aplica. Por tanto, el permiso de override no debe activarse como una alternativa indiscriminada para todos los usuarios.

Una regla SSL/TLS Inspection coincidente con Action > Deny sigue bloqueando; ampliar la cuota o restablecerla no resuelve este conflicto. Primero, comprobar si el bloqueo TLS responde a los requisitos previstos. Solo para un caso expresamente autorizado y de alcance reducido se debe planificar una Web Exception que omita la desencriptación HTTPS. Esta también elimina las comprobaciones que dependen de ella y puede permitir certificados de servidor no válidos; no utilizarla como solución estándar. Comprobar por separado el acceso permitido durante el piloto, que el bloqueo se mantenga fuera del alcance de la excepción y la reversión mediante la desactivación de la excepción piloto. El límite real de la Web Exception debe definirse mediante sus criterios admitidos, por ejemplo, la IP de origen del piloto junto con el patrón de nombre de host confirmado, no mediante el grupo del usuario de la cuota.

Comprobar la Policy Quota durante el funcionamiento

En Web > Policy quota status, SFOS muestra para usuarios individuales el tiempo restante en las Web Policies afectadas dentro de un periodo de 24 horas. El usuario seleccionado puede restablecerse allí mediante Reset. Es un cambio de estado deliberado, no un botón de diagnóstico: primero se documentan usuario, política, tiempo restante, motivo y hora.

Este restablecimiento afecta a la Policy Quota temporal de una categoría web. No es lo mismo que Reset user accounting para Surfing Quota o Network Traffic Quota. Un reset no corrige ni un orden de reglas incorrecto ni una identificación de usuario ausente.

Personalizar las páginas de advertencia y bloqueo

En Web > User notifications se pueden configurar imágenes propias y mensajes de bloqueo, override, quota y advertencia. Los marcadores {category}, {user} y {url} insertan la categoría web, el nombre de usuario y la URL bloqueada. La preview comprueba la presentación y el texto, pero no que la Web Policy y la regla de firewall correctas coincidan con la solicitud productiva.

El mensaje debe explicar brevemente por qué se ha bloqueado o advertido el acceso y dónde comunicar un caso de negocio legítimo. Los nombres de usuario y las URLs pueden contener información sensible, por lo que la página no debe incluir secretos internos, contraseñas ni datos de contacto innecesarios.

Para las imágenes, activar Use custom images y seleccionar las imágenes deseadas. Para los textos, activar según corresponda Use custom block message, Use custom override message, Use custom quota message o Use custom warn message e introducir el texto. Abrir el enlace Preview correspondiente y después comprobar el tipo de mensaje adecuado con una solicitud real del piloto. No utilizar datos reales de clientes en las imágenes de prueba.

Limitar de forma segura los Policy Overrides

Un usuario ya autorizado por el administrador crea su sesión en el User Portal del siguiente modo:

1. Abrir My policy overrides > Add y asignar un nombre descriptivo a la sesión.
2. Conservar el código de acceso proporcionado o generar uno nuevo mediante Generate access code. Solo se permite crear manualmente un código propio si se ha concedido expresamente ese permiso.
3. Seleccionar los sitios web y las categorías web permitidos que sean necesarios; no pueden autorizarse los destinos que el administrador haya excluido de los overrides.
4. En Restricted to time periods, seleccionar un horario existente de la lista. Aquí se selecciona un horario, no se introduce un intervalo arbitrario como texto libre.
5. Guardar con Apply. Después, introducir el código de acceso en el campo de código de la página de bloqueo cuando se solicite un destino bloqueado que coincida.

Mediante Status, el usuario activa o desactiva esta sesión de override. Esto no equivale a la gestión administrativa mediante View overrides: el administrador puede activar, desactivar o eliminar la sesión creada por el usuario de forma independiente. Sin autorización, este procedimiento de usuario no está disponible; se mantiene la restricción al grupo principal de AD y a usuarios individuales.

Policy Overrides es una herramienta distinta de las cuotas. Con Enable policy override, los usuarios autorizados pueden crear en el User Portal acceso temporal a sitios web normalmente bloqueados. Authorized users and groups limita quién puede hacerlo y Blocked websites and categories define destinos que nunca pueden sobrescribirse. Allow manual access code entry solo se activa si los códigos creados por los usuarios encajan en el proceso de aprobación.

En Web > General settings > Policy overrides, documentar primero el estado anterior y los usuarios autorizados. En el User Portal, el usuario autorizado especifica sitios o categorías, un intervalo de tiempo limitado y un código de acceso para el override. Al solicitar un destino bloqueado coincidente, la página de bloqueo contiene un campo adicional para ese código. Si Allow manual access code entry está activado, los usuarios especificados pueden crear sus propios códigos; si está desactivado, deben utilizar códigos generados. Esta elección no debe confundirse con introducir un código ya válido en la página de bloqueo.

View overrides permite mostrar, activar, desactivar y eliminar overrides existentes. Para la aceptación, utilizar un usuario de prueba autorizado para acceder a un destino coincidente dentro del intervalo de tiempo con un código válido; sin código, fuera del intervalo y para un destino que nunca pueda autorizarse mediante override, debe seguir aplicándose el bloqueo normal. Correlacionar usuario, Rule ID, política web, acción y hora en Log Viewer. En HTTPS, la página de bloqueo debe poder mostrarse; una simple interrupción de la conexión no ofrece ningún campo de entrada.

Para revertir, desactivar el override piloto mediante View overrides y comprobar el bloqueo original con una nueva solicitud. Solo después eliminar un override que ya no sea necesario y restaurar únicamente los valores globales cambiados durante el piloto a su estado anterior documentado. No eliminar de forma indiscriminada los overrides existentes de otros usuarios.

Para usuarios de AD, My policy overrides solo se aplica al grupo principal y a usuarios individuales, no a otras pertenencias a grupos. Una regla de inspección SSL/TLS coincidente con Action > Deny sigue teniendo prioridad. Si un override aprobado debe funcionar en esa situación, se planifica una Web Exception de alcance reducido que omita la desencriptación HTTPS y se prueba por separado con un caso negativo; la regla TLS no se debilita de forma general. La autorización de override no restringe la Web Exception; definir su propio alcance por IP de origen junto con nombre de host o categoría y realizar pruebas negativas de ese alcance, como se describe a continuación.

Web Exceptions y excepciones TLS

Las Web Exceptions son potentes y por eso peligrosas si se usan como reparación rápida: una excepción en Web > Exceptions puede omitir comprobaciones de protección para el tráfico coincidente, independientemente de la política web aplicada. Según la selección, puede omitir HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection o Policy checks; en particular, omitir HTTPS decryption elimina las comprobaciones que dependen del descifrado y permite certificados de servidor no válidos, mientras que omitir Malware and content scanning desactiva automáticamente también Zero-day protection.

En entornos DPI se aplica una limitación importante: las Web Exceptions solo tienen efecto si hay una Política Web configurada, Malware and content scanning está activo o ATP está activo. En cambio, las SSL/TLS Exclusion Rules son el lugar correcto cuando solo se quiere evitar el desencriptado de ciertas conexiones TLS. La diferencia operativa es importante:

• SSL/TLS Exclusion Rule: excluye conexiones TLS de la desencriptación de forma específica, normalmente por Certificate Pinning o incompatibilidad.
• Web Exception: puede omitir comprobaciones de Política Web, escaneo de malware, análisis Zero-Day o validación de certificados.
• URL Group in Web Policy: controla Allow, Warn, Block o Quota dentro de la lógica normal de la política. Un URL Group no es un criterio de Web Exception.

Para las Web Exceptions, evitar los dominios raíz y los patrones de expresiones regulares de URL demasiado amplios: un patrón sin más delimitación, como example.com, también puede coincidir con texto en la ruta o la consulta de otro dominio. Los patrones de nombres de host específicos pueden coincidir en el contexto TLS; las rutas que solo aparecen en la URL son visibles únicamente con HTTP o HTTPS ya descifrado. Los criterios admitidos para las Web Exceptions son patrones de expresiones regulares de URL, categorías web, direcciones IP de origen y direcciones IP de destino, no usuarios, grupos de usuarios ni URL Groups.

Para una autorización por motivos de negocio limitada a un grupo de usuarios, utilizar la regla de firewall coincidente y Users en la Web Policy; para una exclusión del descifrado limitada por identidad en modo DPI, utilizar la regla de inspección SSL/TLS adecuada con Don’t decrypt y criterios explícitos de usuario o grupo. Estos criterios de identidad no se convierten en criterios de una Web Exception aplicada por separado ni limitan por sí solos el alcance de las comprobaciones que esta omite.

Para un piloto de Web Exception, combinar las Source IP addresses de los clientes específicos con un patrón de nombre de host confirmado o una categoría web justificada. Probar tanto un origen no autorizado como un destino fuera de ese alcance real de coincidencia; una dirección IP no es una identidad de usuario. No deducir de la lógica genérica AND que las excepciones por IP de origen e IP de destino puedan combinarse para la exclusión TLS: las directrices de exclusión TLS que se mantienen indican que no pueden combinarse, y su alcance exacto no está claro. Si se requieren ambas restricciones de IP, detenerse sin activar ni ampliar la excepción y obtener una aclaración específica para la compilación utilizada. El procedimiento y los límites de coincidencia se explican en Crear y probar Web Exceptions de forma segura.

Las excepciones combinan sus distintos criterios con AND. Dentro de un mismo tipo de criterio, por ejemplo varios URL Patterns, se aplica OR. Es útil, pero propenso a errores: una excepción con URL Pattern y Source IP solo se aplica si ambos coinciden. En cambio, una excepción con muchos URL Patterns puede actuar mucho más ampliamente de lo esperado.

Hay que ser especialmente prudente con Policy checks. Si una Web Exception omite Policy checks, puede debilitar indirectamente otras decisiones de reglas. En combinación con Synchronized Security Heartbeat, una excepción así puede hacer que las solicitudes web no se bloqueen como se espera aunque haya controles Heartbeat en la regla de firewall.

Automatizar Web Protection de forma selectiva mediante la XML API

La XML API resulta útil cuando es necesario mantener los mismos objetos web verificados en varios firewalls. No sustituye ni la asignación de la Web Policy a la regla de firewall realmente adecuada ni la comprobación del tráfico. Antes de escribir, guardar el inventario actual de objetos, sus referencias y la Policy anterior. El acceso, la construcción de requests, la versión de la API, el estado XML y el Audit Trail se explican en Configurar de forma segura el acceso a la XML API y evaluar las respuestas. Las siguientes relaciones entre objetos no constituyen una solicitud completa y ejecutable. Ante las contradicciones entre fuentes indicadas expresamente, consultar primero API help del build instalado y no escribir sin una aclaración inequívoca.

Primero los objetos, después la Policy y la asignación

Un caso de automatización acotado consiste en un URL Group propio para destinos empresariales, un File Type propio para descargas y una User Activity que agrupe estos criterios. Primero leer o crear estos objetos con sus nombres reales; después hacer que las reglas de la Policy hagan referencia a estos objetos y, por último, asignar de forma controlada la Web Policy a la regla de firewall existente que sea realmente adecuada. Un objeto nuevo, por sí solo, todavía no permite ni bloquea tráfico.

• URL Group: WebFilterURLGroup contiene Name y entradas URL repetidas bajo URLlist. La grafía URLlist no es la misma que URLList de una Web Category externa. IsDefault identifica un URL Group integrado; según la referencia, el campo es de solo lectura y los cambios en él se ignoran durante el update. No convierte un objeto propio en un objeto predeterminado editable. Para los valores de dominio adecuados y el mantenimiento desde la UI, sigue siendo determinante el procedimiento de URL Group.
• File Type: FileType agrupa FileExtensionList con valores FileExtension repetidos y MIMEHeaderList con valores MIMEHeader repetidos. El comentario del ejemplo XML describe Template de modo que se adoptan las extensiones y los encabezados MIME de la plantilla y se insertan adicionalmente las entradas especificadas por separado. Por ello, después de escribir, comprobar la lista completa efectiva, no solo los valores añadidos. El ejemplo muestra Blank, pero la tabla de parámetros no explica Template; no deducir de ello una lista universal de plantillas permitidas. Las extensiones siguen escribiéndose sin punto inicial, por ejemplo, pdf.
• User Activity: UserActivity utiliza Name para el nombre existente y NewName para un cambio de nombre previsto. Bajo CategoryList se encuentran objetos Category con Type e ID. En el ejemplo, las denominaciones de tipo web category, file type y url group están separadas de la ID, que es el nombre del objeto. No utilizar una palabra de tipo como ID de objeto ni inventar una ID numérica. El ejemplo denomina la etiqueta de descripción Desc, mientras que la tabla indica Description; confirmar la etiqueta válida para el build específico. La combinación OR de los criterios de la Activity sigue siendo independiente de la acción HTTP/HTTPS posterior.

Ante un error de File Type, estas respuestas XML son especialmente relevantes: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type o Edit File Type 503 / Message.FileTypeSameDetailRecordExists y 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Son símbolos de referencia sin modificar, no textos de mensaje resueltos ni códigos HTTP. Con 202, leer los nombres antiguo y nuevo, así como las referencias de la Policy; con 503, comparar los valores de detalle ya existentes y, con 505, comprobar las extensiones y los encabezados MIME. No limitarse a crear un segundo objeto con otro nombre.

Categorías propias: separar contenido, clasificación y ancho de banda

WebFilterCategory distingue mediante ConfigureCategory dos vías de entrada: Local utiliza DomainList/Domain y KeywordList/Keyword; External utiliza URLList/URL para la lista de categorías externa. Una URL de lista externa no es automáticamente un valor de dominio empresarial cuyo acceso deba permitirse. El origen, la actualización y el contenido de la lista externa deben poder verificarse. No mezclar ambas vías en un request sin comprobarlas.

Classification clasifica la categoría, pero no decide entre Allow y Block. La descripción menciona en parte denominaciones distintas de las de la tabla de enumeraciones; esta indica Productive, Unproductive, Acceptable y Objectionable. Tampoco ConfigureCategory es totalmente coherente: el ejemplo muestra Local/External, y la tabla incluye además 0. No transmitir nombres de clasificación traducidos ni 0 como sustituto sin verificar. QoSPolicy hace referencia a una política de ancho de banda, no a una acción de Web Policy; la selección y el efecto se comprueban en el procedimiento de Traffic Shaping. Solo una regla de Web Policy adecuada convierte la categoría en una decisión de acceso.

La tabla de categorías exige una comprobación posterior precisa de los detalles:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded y Update Category 201 / Message.WFCCategoryDetailCannotUpdated: no tratar todas las respuestas XML 2xx como valores de dominio, palabras clave o listas guardados por completo. Volver a leer por separado la cabecera del objeto y cada conjunto de detalles necesario. Add Category 202 remite, al igual que 200, a Message.WFCAddSuccess; el nombre de símbolo compartido no explica la diferencia entre los códigos.
• Add Category 522 / Message.WFCMaxFiveURL y 523 / Message.WFCMaxFiveKeyword, pero Update Category 503 / Message.WFCMaxFiveURL y 504 / Message.WFCMaxFiveKeyword: evaluar conjuntamente la operación y el código. Los nombres de los símbolos, por sí solos, no demuestran un límite actual universal de cinco entradas; aclarar la cantidad realmente permitida mediante la ayuda del build.
• Delete WebFilter Category 201 / Message.WFCRelationExists y 203 / Message.WFCSomeCategoryCannotDeleted: comprobar las referencias y las categorías restantes antes de eliminar o volver a intentarlo. No asumir un éxito global de eliminación para una selección de varias categorías.

Todos los símbolos Message.* se dejan aquí deliberadamente sin resolver. Antes de un reintento, guardar el estado realmente almacenado y la respuesta; en particular, no repetir a ciegas un cambio de categorías aplicado parcialmente.

Content Condition Lists: Key no es Name

Un objeto ContentConditionList contiene el Name visible, la identidad independiente Key y ContentList con valores ContentString repetidos. La referencia exige Name y Key; para Delete Content Condition List, el selector es expresamente Key. Por ello, al leer y documentar, conservar ambos valores y no utilizar nunca el nombre mostrado como clave de eliminación sin verificarlo.

La tabla de la API describe ContentString como valores Regex sin procesar e indica que los duplicados no se ignoran. En cambio, la importación desde la UI descrita más arriba es una lista de texto con un Exact Match por línea. Por tanto, no está demostrado que una importación desde la UI y una lista Regex de la API tengan un formato de entrada idéntico. Antes de una migración, aclarar la semántica con la ayuda del build y probar coincidencias y no coincidencias inocuas; no transmitir una lista de texto existente como payload Regex sin verificarla.

Resultan especialmente llamativas las asignaciones contradictorias entre operaciones y mensajes de la referencia:

Estas filas demuestran una contradicción en la documentación, no que un Update elimine o que un Delete actualice. Comprobar la operación, Key, la respuesta y los contenidos realmente existentes. Sin una aclaración inequívoca para el build, no deducir de ello ninguna operación destructiva ni iniciar un reintento automático a partir del nombre de un símbolo.

WebFilterPolicy: conservar el orden y los selectores

WebFilterPolicy mantiene las reglas bajo RuleList/Rule. Cada regla hace referencia, bajo CategoryList/Category, a un nombre de objeto ID y a un selector type. El ejemplo de Policy utiliza WebCategory, URLGroup, UserActivity, DynamicCategory y FileType; estos tokens difieren de las denominaciones de tipo del ejemplo de User Activity y la etiqueta type aparece aquí en minúsculas. Adoptar la grafía, el tipo de objeto y el nombre existente a partir del objeto leído o de la ayuda del build, en lugar de serializar etiquetas de la UI o IDs inventadas.

HTTPAction y HTTPSAction son decisiones separadas; FollowHTTPAction describe su vinculación. El ejemplo de la API menciona Deny, Allow, Warn, Log y Quota. Estos valores de ejemplo no confirman que todos puedan seleccionarse en cualquier build, y Deny no debe sustituirse sin más por la palabra Block de la UI. PolicyRuleEnabled controla la activación de la regla, Schedule el horario referenciado y UserList/User el ámbito de usuarios. CCLRuleEnabled y CCLList/CCL vinculan los filtros de contenido con la regla; el ejemplo hace referencia ahí a un nombre de CCL, mientras que la eliminación de la CCL requiere su Key. El comportamiento HTTPS de un Content Filter debe seguir correspondiéndose con la vinculación de la UI explicada más arriba. Durante el update, conservar el orden, el ámbito de usuarios, el horario, los filtros de contenido y la Default Action, y comparar toda la Policy almacenada. La ausencia de un campo no permite presuponer con certeza su conservación ni su eliminación.

Para las siguientes entradas, la referencia no proporciona una plantilla ejecutable y libre de contradicciones:

• DefaultAction: la tabla indica un máximo de un carácter, pero al mismo tiempo permite Allow y Deny. No acortar a un carácter ni inventar una codificación numérica alternativa. EnableReporting muestra Enable/Disable en el ejemplo, mientras que la tabla solo permite Enable; por tanto, la desactivación no está confirmada sin comprobar el build.
• DownloadFileSizeRestriction: el comentario XML indica de 1 a 1536 MB, y la tabla de parámetros de 0 a 1536. Por tanto, el significado de 0 no está aclarado; no tratarlo ni como ilimitado ni como un límite activo válido. Definir conjuntamente el interruptor DownloadFileSizeRestrictionEnabled y el límite según la ayuda del build, y comprobarlos con archivos inocuos a ambos lados del límite confirmado. La tabla de la API indica de 1 a 1440 para QuotaLimit; confirmar el intervalo admitido en el build instalado antes de escribir. DPI sigue sin admitir la Policy Quota.
• Tenant Controls: Office365Enabled, Office365TenantsList y Office365DirectoryId pertenecen a la restricción de tenants de Microsoft. Para la lista, la tabla de la API indica 4096 caracteres, mientras que la ayuda de la UI para Restrict-Access-To-Tenants indica 256; no equiparar estos límites ni deducir del dato de la API que puede usarse un valor más largo en producción. El valor de ejemplo de Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, contiene caracteres no hexadecimales y no es un valor GUID de ejemplo válido. No corregirlo silenciosamente; utilizar la Directory-ID real de la administración del tenant propio y probar inicios de sesión de tenants permitidos y no permitidos. Confirmar la correspondencia de los campos de la UI, las longitudes y la semántica en el build instalado.

Add Policy 522 / Message.WebPoliciesLimit se refiere al límite de Policies; no deducir de ello un límite de reglas o categorías. Update Policy 503 / Message.WFPQuotaLimitInvalid exige comprobar la entrada de Quota. La referencia incluye además Update Policy from API como denominación de operación independiente; sus filas de respuesta no contienen esta entrada 503. Esto no demuestra que esa vía acepte cualquier Quota. Comprobar el estado, la Policy almacenada y el efecto real antes de volver a escribir.

No mezclar las opciones de protección globales y las notificaciones

WebFilterSettings es el área global de configuración del filtro web, no una WebFilterPolicy individual. Contiene, entre otros, PharmingProtection, Scanning, BlockUnscannableContent y PUAWhitelist con nombres PUA repetidos. Una entrada PUA es una excepción aprobada deliberadamente, no un paso necesario para una nueva Web Policy. La selección del escáner y su efecto siguen tratándose en el procedimiento enlazado de Malware Scanning; ajustar un mensaje no es motivo para modificar de paso las opciones de protección globales o la lista PUA.

WebFilterProtectionSettings es otro contrato independiente de análisis/protección con campos como ScanMode y FileSizeThreshold. Los campos de protección con nombres similares no lo convierten en sinónimo de WebFilterSettings o WebFilterNotificationSettings; no intercambie payloads entre estos objetos. Para un texto meramente informativo, no incluya opciones de análisis, tamaño o certificados. También para este objeto de protección, el contrato válido debe proceder de la ayuda de la compilación, no de valores de ejemplo adoptados sin verificar.

También aquí el ejemplo contradice la tabla: BlockUnscannableContent muestra Enable/Disable, mientras que la tabla permite Allow y Block (Best Protection). No unificar estas enumeraciones ni deducirlas del nombre del campo. Antes de cualquier cambio, guardar el comportamiento anterior y aclarar el contrato exacto del build.

WebFilterNotificationSettings, en cambio, se ocupa de las notificaciones a los usuarios. OverrideDefaultDeniedMessage corresponde a DefaultDeniedMessage, y OverrideDefaultWarnedMessage a DefaultWarnedMessage; los textos personalizados solo se seleccionan deliberadamente mediante el Override correspondiente. La tabla incluye campos adicionales de Override/Quota que faltan parcialmente en el ejemplo: OverrideDefaultOverrideMessage/DefaultOverrideMessage y OverrideDefaultQuotaMessage/DefaultQuotaMessage. Los interruptores de Override/Quota indican 0/1 como valores permitidos, pero al mismo tiempo Enable como valor predeterminado. Es otra contradicción entre fuentes y no un motivo para codificar todos los flags de la misma manera. Para un cambio exclusivamente de texto, modificar solo los campos de texto/Override previstos conforme al contrato confirmado del build y comprobar la página correspondiente en la prueba piloto.

DeniedMessageImage selecciona Default o Custom. El ejemplo vincula TopImageFile y BottomImageFile con un nombre de archivo del request multipart; la tabla describe jpg/jpeg. Sin embargo, en User Notifications, la tabla denomina al parámetro superior Top Image, mientras que el ejemplo utiliza TopImageFile. Estos datos no bastan para construir con certeza los nombres de las partes, Content-Disposition, el endpoint de carga o la asociación de archivos. Aclarar primero la transferencia de archivos mediante la ayuda del build o una colección oficial confirmada para ese fin. No realizar cambios automatizados de imágenes sin un contrato de carga confirmado. Los campos similares de mensajes e imágenes de WebFilterSettings no hacen que ambos objetos sean intercambiables.

DefaultWebFilterNotificationSettings es, a su vez, independiente: ofrece textos de mensaje predeterminados con nombre, por ejemplo, WebsiteBlocked. Un caso de uso acotado y útil es un aviso aprobado con el contacto de soporte correcto. Para ello, guardar exactamente el texto original afectado, modificar solo la clave de mensaje confirmada, comprobar la vista previa correspondiente y la página real de la prueba piloto y, si es necesario, restaurar exactamente ese texto. El texto de un mensaje no es ni una autorización de acceso ni una prueba de una detección de malware o Zero-Day.

Volver a leer y validar cada cambio de automatización

Después de cada operación de escritura, volver a leer mediante la API o en WebAdmin el objeto exacto al que se ha dirigido la operación: comparar nombres/Keys, listas efectivas, referencias, orden de la Policy, activación y asignación real al firewall. Después, ejecutar los mismos requests piloto permitidos y bloqueados que antes del cambio y correlacionar Rule ID, usuario, Web Policy y acción en Log Viewer. Un éxito HTTP, un código XML 2xx o un símbolo Message.* sin resolver no bastan por sí solos. Ante un cambio parcial o una respuesta poco clara, guardar primero el estado actual y el Audit Trail y después corregir de forma selectiva; no realizar reintentos ciegos de Add/Delete. Solo se revierten los cambios propios documentados, no otras Policies, Overrides o valores de protección globales existentes.

Probar la Protección Web

Después de guardar, no solo se debe verificar si la política existe. Lo crucial es si se aplica al tráfico real.

1. Usar el Policy Tester

La ruta exacta es Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web prueba la ruta transparente combinada, mientras que Web policy only aísla la decisión de la política web. La prueba web solo representa accesos transparentes, no contempla rutas SD-WAN ni admite Source Networks con direcciones MAC. Si no se especifica el protocolo, usa HTTP; si no se especifica el puerto, usa el puerto estándar del protocolo elegido.

Antes del cambio, deben ejecutarse ambos modos pertinentes como referencia y registrarse el resultado y la Rule ID esperada; después, se repiten las mismas pruebas. El Policy Tester sigue siendo una comprobación previa y debe complementarse con pruebas Allow y Block reales desde un cliente piloto, ya que NAT, la Inspección TLS, QUIC, el enrutamiento o una ruta Direct Proxy explícita pueden tratar de forma distinta el flujo real.

2. Prueba real con cliente piloto

Con un cliente piloto, verificar:

• sitio de negocios permitido
• categoría bloqueada
• categoría de advertencia
• Permitir grupo de URL
• Bloquear grupo de URL
• sitio HTTPS con y sin Inspección TLS
• Descarga de un tipo de archivo de prueba inofensivo
• Comportamiento con QUIC activo o bloqueado

3. Verificar Log Viewer

En el Log Viewer debería ser visible:

• qué regla de firewall fue alcanzada
• qué usuario fue reconocido, si es relevante
• qué categoría web o grupo de URL estuvo involucrado
• si HTTPS, Inspección TLS o escaneo de malware estuvieron involucrados
• si la acción permitió, advirtió o bloqueó
• si se aplicó una Web Exception o TLS Exclusion
• si una descarga se trató de forma distinta por tamaño, error de escaneo de malware o análisis Zero-Day

En Syslog o SIEM no bastan URL y acción. Para un análisis fiable también se necesitan Firewall Rule ID, usuario, categoría, Política Web, método HTTP, estado, resultado de escaneo, indicio de excepción y relación SSL/TLS. Si estos campos faltan en el SIEM o se normalizan de forma incorrecta, la Protección Web se ve rápidamente menos clara en los informes de lo que realmente es en la firewall.

Para una solución de problemas más profunda, también son relevantes los archivos de registro. La asignación se encuentra en Solución de problemas de Sophos Firewall: Servicios y registros.

Alertas instantáneas e informes

Si ciertas categorías no solo deben bloquearse, sino también informarse activamente, las alertas instantáneas pueden ser útiles. Esto es especialmente útil en escuelas, entornos estrictamente regulados o áreas con políticas claras de uso de Internet.

Los tres métodos de evaluación responden a diferentes preguntas:

• Correo electrónico rápido para pocas categorías web sensibles: Alertas instantáneas.
• Informes recurrentes, tendencias y evaluaciones de usuarios o categorías: Central Firewall Reporting.
• Almacenamiento a largo plazo, correlación con otros sistemas o procesos SOC: Syslog o SIEM.

Antes de las alertas instantáneas, debe quedar claro quién recibe la notificación, qué categorías realmente desencadenan una reacción, cómo se manejan los falsos positivos y cuándo se revisa la selección de categorías. Una lista amplia de alertas sin propietario genera rápidamente ruido de correo electrónico, pero no mejor seguridad.

Para la activación técnica y la clasificación, consulte Utilizar categorías web y alertas instantáneas de Sophos Firewall. Para evaluaciones a largo plazo, se deben considerar Central Firewall Reporting o Enviar Syslog de Sophos Firewall a SIEM.

Gestionar cambios y excepciones en operación

La Protección Web cambia continuamente en operación. Se añaden nuevos servicios SaaS, se categorizan incorrectamente dominios individuales, los departamentos necesitan acceso temporal y el comportamiento del navegador cambia. Sin un proceso claro, rápidamente surgen excepciones amplias que nadie puede explicar más tarde.

Para cada cambio, se debe registrar al menos:

• ¿Quién necesita el acceso? evita excepciones globales para pocos usuarios.
• ¿Qué dominio, categoría o tipo de archivo está afectado? separa claramente Grupo de URL, Categoría Web y Tipo de Archivo.
• ¿Es una excepción temporal o permanente? obliga a revisión en lugar de aprobaciones permanentes en la sombra.
• ¿Qué regla de firewall y política web están afectadas? evita cambios en la regla incorrecta.
• ¿Cómo se prueba? hace que el éxito sea demostrable en el Log Viewer.

Se recomienda un pequeño proceso de cambio:

1. Registrar la solicitud con usuario, URL, momento, motivo comercial y captura de pantalla o mensaje de error.
2. Verificar en el Log Viewer qué regla de firewall, política web, categoría y acción se aplicaron.
3. Decidir si la categoría es fundamentalmente incorrecta, si solo se debe liberar un dominio individual o si se rechaza la solicitud.
4. Si es necesaria una autorización por motivos de negocio, mantener un alcance reducido en la regla de firewall coincidente y en la Web Policy: un URL Group específico en lugar de una categoría completa y Users explícitos en lugar de toda la LAN. Si, en su lugar, se necesita una Web Exception, utilizar sus propios criterios admitidos de URL, categoría o IP; un grupo de usuarios o un URL Group no es un criterio de Web Exception.
5. Probar el cambio en una regla de prueba o grupo piloto.
6. Después de guardar, realizar una prueba real y documentar Log Viewer, categoría, ID de regla y contexto de usuario.
7. Establecer una fecha de revisión, especialmente para excepciones comerciales temporales.

Las excepciones temporales deben nombrarse claramente, por ejemplo, TMP_ALLOW_vendor-portal_until_2026-07-31. Las excepciones comerciales permanentes también necesitan un propietario. Si nadie es responsable de una excepción, no debe permanecer permanentemente en la política.

Si surgen muchos dominios individuales para el mismo servicio, a menudo el problema no es la política web, sino la arquitectura del servicio. Entonces, se debe verificar si una regla de firewall propia, una política web propia, un grupo de URL bien mantenido u otro punto de control es más adecuado. Para listas dinámicas de IOC o de bloqueo, las excepciones de política web generalmente no son el lugar adecuado; para eso son más adecuados Sophos Firewall Threat Feeds.

Reversión y acceso temporal de emergencia

Un cambio en la política web puede afectar inmediatamente el trabajo productivo. Por lo tanto, antes de realizar cambios importantes, se debe establecer cómo se restaurará el estado anterior.

Opciones prácticas de reversión:

• duplicar o documentar la política web afectada antes del cambio
• probar el cambio primero en una regla piloto o grupo pequeño de usuarios
• no eliminar inmediatamente la regla de firewall o política web antigua
• definir ventana de tiempo, usuarios de prueba y criterio de retroceso
• después de guardar, verificar Log Viewer, ID de regla y decisión de categoría

Ante bloqueos urgentes, no insertar por reflejo una regla Allow amplia en la parte superior. Dar preferencia a una autorización por motivos de negocio de alcance reducido y duración limitada en la regla de firewall coincidente y en la Web Policy, con un URL Group específico, Users explícitos y una fecha de revisión. Esto no es una Web Exception limitada a un grupo de usuarios. Cualquier omisión necesaria de la inspección requiere sus propios criterios de coincidencia aprobados y admitidos, así como pruebas positivas y negativas independientes. Reevaluar después la autorización temporal.

Errores comunes

La política web no se aplica

Generalmente, la política no está activada en la regla de firewall correcta, la regla no se alcanza, una regla más arriba permite el tráfico o el contexto del usuario no coincide. Primero, verificar Log Viewer y ID de regla.

HTTPS no se bloquea como se esperaba

Sin Inspección TLS, el firewall ve menos detalles. Dependiendo del destino, una decisión de dominio o categoría puede funcionar, mientras que la inspección de contenido, tipos de archivos o ciertas funciones de búsqueda están limitadas.

Si la conexión no se desencripta, la firewall puede seguir usando información SNI o de dominio para decisiones de política. Pero las páginas de bloqueo, páginas de advertencia, tipos de archivo, Content Filters, escaneo de malware y análisis Zero-Day necesitan más visibilidad. Por eso, en Log Viewer no solo se debe comprobar la acción de la Política Web, sino también el estado de SSL/TLS Inspection.

QUIC elude la expectativa

Si los navegadores utilizan UDP 443, el tráfico puede procesarse de manera diferente al HTTPS clásico sobre TCP. En las reglas de clientes, se debe decidir conscientemente si se bloquea QUIC.

La regla de permitir está demasiado arriba

Una regla de permitir amplia al principio de la política web puede invalidar las reglas de bloqueo posteriores. El orden de las reglas dentro de la política web es tan importante como el orden de las reglas en la lista de reglas de firewall.

Demasiadas excepciones

Las excepciones resuelven rápidamente un problema individual, pero pueden reducir la efectividad de la protección. Cada excepción necesita un propósito, propietario y fecha de revisión. Si surgen muchas excepciones, a menudo la estructura de la política es incorrecta o una aplicación comercial necesita una regla propia.

Son especialmente arriesgadas las Web Exceptions que omiten Policy checks o Malware and content scanning. Si solo molesta HTTPS decryption, una SSL/TLS Exclusion suele ser más estrecha y comprensible.

El informe no muestra nada

Entonces, se deben verificar el registro, los informes, la regla de firewall, la selección de políticas o la redirección de registros. Una política sin registro es difícil de evaluar en operación.

Lista de verificación de operación

• Estado de licencia de Protección Web verificado.
• Tráfico de clientes, servidores, invitados y VPN evaluado por separado.
• Política web creada con nombre descriptivo.
• Categorías críticas y grupos de URL planificados conscientemente.
• Orden de reglas dentro de la política web verificada.
• Política web activada en la regla de firewall adecuada.
• Log firewall traffic, logging de Política Web y Reporting activos.
• Las reglas de Política Web están activadas y en el orden correcto.
• Inspección TLS y certificado CA para grupo piloto verificados.
• Estrategia QUIC definida.
• Web Exceptions y TLS Exclusions documentadas por separado.
• Policy Tester y pruebas reales realizadas.
• Log Viewer e informes controlados.
• Proceso de cambio para excepciones de política web definido.
• Excepciones temporales con fecha de vencimiento establecida.
• Excepciones documentadas con propietario y fecha de revisión.

FAQ