Configurar Surfing y Network Traffic Quota en Sophos Firewall

Una Surfing quota limita el tiempo de internet utilizable por un usuario autenticado. Una Network traffic quota, en cambio, limita el volumen de datos transferido. Ambas políticas se asignan a un usuario o grupo y son adecuadas, por ejemplo, para aulas de formación, invitados o paquetes de uso claramente definidos.

Para los invitados temporales, la creación de la cuenta, la validez, Captive Portal y la limpieza se planifican por separado. El ciclo de vida completo se explica en Crear y operar de forma segura usuarios invitados en Sophos Firewall; este artículo se centra en las cuotas.

La vía rápida para una introducción controlada es la siguiente:

1. Definir si se limitará el consumo de tiempo, el volumen de datos o ambos.
2. Crear una nueva política piloto en Profiles > Surfing quota o Profiles > Network traffic quota.
3. Asignar la política a un pequeño grupo piloto en Authentication > Groups o a un único usuario de prueba en Authentication > Users.
4. Volver a autenticar al usuario y comprobar la identidad reconocida en Current activities > Live users.
5. Utilizar para la prueba una regla de firewall basada en usuarios con Log firewall traffic.
6. Abrir el usuario en Authentication > Users y comprobar el consumo mediante View usage.
7. Probar el límite, el siguiente ciclo y el rollback antes de incorporar más usuarios.

⚠️ Reset user accounting restablece tanto el tiempo de navegación consumido como los contadores de tráfico de red. Es un cambio de estado, no un botón general de diagnóstico. Antes de un restablecimiento se documentan el usuario, los valores actuales, la hora y el motivo. Tampoco se modifica directamente una cuota de producción compartida; para las pruebas se utiliza una política piloto separada.

Elegir la función adecuada para el requisito

Cuatro funciones con nombres similares resuelven tareas diferentes:

• Access Time permite o bloquea usuarios durante franjas horarias fijas. No cuenta el consumo.
• Surfing quota proporciona a un usuario un crédito de tiempo consumible para el acceso a internet.
• Network traffic quota proporciona a un usuario un crédito de datos consumible.
• Traffic Shaping limita o prioriza el ancho de banda. Una velocidad de datos baja no es una cuota de datos.

Además, una Web Policy ofrece la acción Quota para el acceso temporal a determinadas categorías web. Esta Policy Quota pertenece a la lógica del proxy web y no es la misma función que la Surfing Quota basada en usuarios de este artículo.

Una cuota no crea una regla de firewall ni una identidad de usuario. La firewall debe reconocer al usuario, la ruta de red debe estar permitida y el tráfico de prueba debe coincidir con la regla esperada. Solo entonces puede comprobarse la cuota de forma significativa.

Planificar el ejemplo y los requisitos previos

El ejemplo continuo utiliza un pequeño grupo piloto con dos políticas separadas:

• Grupo: Quota_Pilot
• Usuario de prueba: quota-pilot
• Surfing Quota: Students_InternetTime
• Cycle type: Cyclic (repeat access)
• Cycle hours: 24
• Maximum access time: 02:00
• Network Traffic Quota: Students_DataVolume
• Restriction: Total network traffic
• Cycle type: Cyclic
• Cycle period: Day
• Quota per cycle: 5000 MB
• Maximum quota: Unlimited

Son ejemplos de documentación deliberadamente pequeños: cada ciclo de 24 horas proporciona dos horas de internet y cada día 5000 MB de volumen de datos. Los nombres, el tiempo, el volumen de datos, el ciclo y el límite total se adaptan al acuerdo de uso real. Los límites pequeños de prueba no deben copiarse en una política exclusivamente productiva sin comprobar su impacto.

Antes de configurar se comprueban estos puntos:

1. El usuario piloto puede iniciar sesión con el método de autenticación previsto.
2. El nombre de usuario y la dirección de origen aparecen en Current activities > Live users.
3. En usuarios de AD, el campo Group de Authentication > Users es correcto.
4. Una regla de firewall adecuada y basada en usuarios permite el tráfico de prueba y tiene activado Log firewall traffic.
5. Están documentadas las asignaciones existentes de Surfing quota, Network traffic, Access time y Traffic shaping.
6. Se conocen el estado anterior y un usuario de prueba alternativo.

Si el usuario no aparece como Live User, primero se corrige la autenticación. Una cuota no puede asignar de forma fiable a un crédito de usuario normal el tráfico desconocido o tratado únicamente por IP.

Crear una Surfing Quota

Una Surfing Quota cuenta el tiempo de internet consumido. En la ayuda de SFOS 22, el mismo objeto aparece documentado tanto en Profiles > Surfing quota como en Web > Surfing quotas. Se utiliza la entrada que muestre WebAdmin en la compilación instalada.

Elegir Cyclic o Non-cyclic

• Cyclic (repeat access): El crédito de tiempo vuelve a estar disponible en ciclos recurrentes. El tiempo no utilizado no se transfiere al ciclo siguiente.
• Non-cyclic (one-time access): El crédito de tiempo se concede una sola vez. Tras consumirlo, el usuario se desconecta.

Además, Validity period limita el número de días durante los cuales la política es válida. Maximum access time define el tiempo utilizable. Cuando se alcanza el máximo, el usuario se desconecta aunque aún no haya expirado la validez de la cuota.

Para el ejemplo piloto:

1. Abrir Profiles > Surfing quota > Add. Si la compilación muestra la función en Web > Surfing quotas, seleccionar allí Add.
2. Establecer Name en Students_InternetTime.
3. Introducir, por ejemplo, Pilot: 2h per 24h, Owner IT como Description.
4. Establecer Cycle type en Cyclic (repeat access).
5. Establecer Cycle hours en 24.
6. Definir expresamente el Validity period del piloto o seleccionar Unlimited solo si no se necesita una fecha de caducidad.
7. Establecer Maximum access time en 02:00.
8. Guardar con Save.

La política guardada todavía no tiene efecto. Solo la asignación a un usuario o grupo vincula el crédito de tiempo con una identidad.

Crear una Network Traffic Quota

Una Network Traffic Quota cuenta el volumen de datos transferido. No limita la velocidad. Por tanto, un usuario puede consumir su crédito rápida o lentamente; si se necesita un límite de ancho de banda, se planifica además una política de Traffic Shaping adecuada.

Limitar el tráfico total o separar subida y descarga

• Total network traffic: Un único crédito común cuenta conjuntamente la subida y la descarga.
• Individual network traffic (Upload & download): La subida y la descarga reciben límites separados. Solo es adecuado cuando el requisito realmente trata ambas direcciones por separado.

También existen dos modelos de ciclo:

• Cyclic: El crédito se aplica a cada ciclo seleccionado. Están disponibles Day, Week, Month y Year. El volumen no utilizado no se transfiere.
• Non-cyclic: El crédito se aplica a un único periodo de ciclo.

Quota per cycle define el crédito de cada ciclo. Una Maximum quota opcional añade un límite total y debe ser superior a la cuota del ciclo. Cuando se agota el límite del ciclo o el límite total, la firewall desconecta al usuario. Para volver a conectarlo antes del restablecimiento ordinario se necesita Reset user accounting.

Para el ejemplo piloto:

1. Abrir Profiles > Network traffic quota > Add.
2. Establecer Name en Students_DataVolume.
3. Introducir, por ejemplo, Pilot: 5000 MB per day, Owner IT como Description.
4. Establecer Restriction en Total network traffic.
5. Establecer Cycle type en Cyclic.
6. Establecer Cycle period en Day.
7. Establecer Quota per cycle en 5000 MB.
8. Mantener Maximum quota en Unlimited para este ejemplo recurrente. Si se necesita un límite total, debe ser superior a la cuota del ciclo.
9. Guardar con Save.

En este ejemplo, 5000 MB corresponden a 5 GB. En una política real, el valor se deriva del crédito aprobado y se introduce en la unidad que espera WebAdmin. En cambio, una política con subida y descarga separadas recibe valores propios y justificados para cada dirección.

Asignar cuotas a un grupo o usuario

Utilizar un grupo como método operativo normal

Para usuarios con el mismo crédito, una política de grupo es más fácil de operar que muchos valores individuales:

1. Abrir Authentication > Groups.
2. Crear el grupo Quota_Pilot o editar un grupo piloto claramente delimitado.
3. Seleccionar Students_InternetTime en Surfing quota.
4. Seleccionar Students_DataVolume en Network traffic.
5. No modificar incidentalmente otros valores de Access Time, Traffic Shaping, Remote Access o del portal.
6. Guardar.
7. Volver a autenticar al usuario piloto y comprobar el grupo utilizado realmente.

Gestionar grupos de usuarios de Sophos Firewall de forma segura explica cómo interactúan los grupos locales e importados, el grupo principal y las excepciones de usuario. La importación de AD propiamente dicha se mantiene en Conectar Active Directory con Sophos Firewall.

Una excepción de usuario tiene prioridad

En Authentication > Users, Surfing quota y Network traffic pueden definirse de forma diferente para un usuario individual. Estos valores de usuario tienen prioridad sobre la política de grupo.

Si un cambio de grupo no afecta a un usuario, primero se comprueba su objeto de usuario. Una excepción es adecuada para una excepción documentada o un piloto, pero a largo plazo puede crear casos especiales ocultos. Para volver a la política de grupo, se restablece de forma controlada el estado de herencia anterior del usuario.

En Active Directory solo cuenta Main Group

Para los usuarios de AD, Surfing Quota y Network Traffic no utilizan Other group memberships. Se aplica la Main Group que aparece en el campo Group de Authentication > Users, o una política explícita del usuario.

El orden en Authentication > Groups > Reorder puede cambiar la Main Group y afectar al mismo tiempo a varias políticas. Por eso no se cambia como solución rápida para una cuota. Tras un cambio planificado de grupo, se vuelve a autenticar al usuario y se comprueba de nuevo la Main Group.

Clientless Users quedan excluidos

Los Clientless Users no admiten Surfing Quota ni Network Traffic. Para un dispositivo fijo sin inicio de sesión de usuario, la ruta de red, el horario y, si es necesario, Traffic Shaping se planifican en una regla de firewall restringida. Las cuotas de usuario no se utilizan como sustituto basado en IP.

Comprobar el consumo y validar el límite

View usage en WebAdmin

Para mostrar el consumo, Sophos requiere una regla de firewall basada en usuarios con Log firewall traffic activado. A continuación:

1. Volver a autenticar al usuario piloto.
2. Comprobar el nombre de usuario y la dirección de origen en Current activities > Live users.
3. Abrir Authentication > Users y seleccionar al usuario piloto.
4. Abrir View usage.
5. En Surfing Quota, comprobar el tiempo asignado, la caducidad y el tiempo de internet consumido.
6. En Network Traffic, comprobar Cycle renewal, subida, descarga y cuota asignada.
7. Generar una pequeña transferencia de prueba permitida y volver a comprobar el cambio.
8. Correlacionar en Log Viewer el usuario, Source, Destination, Service, Firewall Rule ID, Action y la marca de tiempo.

La vista mensual muestra además IP de origen, inicio, fin, duración, subida y descarga. Sin embargo, un valor de consumo por sí solo no demuestra que se hayan utilizado la ruta prevista y la regla correcta. Por eso se combinan View usage, Log Viewer y un flujo de prueba real. Probar correctamente una regla de Sophos Firewall explica la validación de reglas.

Control del usuario en User Portal

En User Portal, en Internet usage, un usuario puede comprobar, según el tipo de cuenta y la política, el tiempo de navegación asignado y consumido, la renovación del ciclo, así como la subida, la descarga y el crédito restante. Esto reduce consultas, pero no sustituye la validación administrativa de la asignación, Main Group, la regla y los registros.

Probar el límite de consumo de forma controlada

Para una prueba de límite se utiliza una política piloto separada con un crédito deliberadamente pequeño, pero suficiente. La prueba no debe afectar a ningún grupo de producción.

1. Documentar los valores iniciales en View usage.
2. Iniciar un flujo de prueba HTTP o HTTPS claramente limitado.
3. Observar el consumo y Log Viewer durante la prueba.
4. Confirmar que al alcanzar el límite se produce la desconexión esperada.
5. No presuponer una transición exacta al segundo; la firewall comprueba periódicamente la autorización.
6. Probar el siguiente ciclo ordinario o un restablecimiento aprobado expresamente.
7. Restaurar después la política piloto y la asignación anterior.

Utilizar Reset user accounting de forma segura

Reset user accounting restablece el tiempo de navegación y el consumo de tráfico de red del usuario. Con una Network Traffic Quota agotada, este restablecimiento es necesario si el usuario debe volver a conectarse antes del siguiente ciclo ordinario.

Un restablecimiento controlado es el siguiente:

1. Documentar el usuario, el ticket, el motivo, los valores actuales de cuota y la hora.
2. Comprobar si puede esperarse al cambio de ciclo ordinario.
3. Asegurarse de que está seleccionado el usuario correcto.
4. Abrir el usuario en Authentication > Users.
5. Abrir View usage y conservar los valores iniciales.
6. Ejecutar Reset user accounting solo con la autorización prevista.
7. Volver a autenticar al usuario y comprobar los nuevos contadores.
8. Comprobar un pequeño flujo de prueba, la Firewall Rule ID y los registros.

El restablecimiento no corrige una Main Group incorrecta, una identificación de usuario ausente ni una política de firewall o web que bloquee. Si estas causas no se aclaran primero, el problema reaparece a pesar de los contadores restablecidos.

Delimitar los errores sistemáticamente

La cuota parece no contabilizarse

Primero se comprueba en Current activities > Live users si aparecen la identidad y la dirección de origen esperadas. Después se verifica que el tráfico coincida con una regla de firewall basada en usuarios y con Log firewall traffic. Si falta el registro o el flujo utiliza otra regla, View usage puede quedar incompleto.

A continuación se comparan la política de grupo, la excepción de usuario y, en AD, la Main Group. La cuota no se reduce precipitadamente solo para forzar un efecto visible.

La cuota de grupo solo afecta a algunos usuarios

Una política explícita en el usuario tiene prioridad. En Authentication > Users se comprueban ambos campos de cuota y la Main Group. En AD no se evalúan las Other group memberships. Tras un cambio de grupo, se vuelve a autenticar al usuario.

El usuario se desconecta inesperadamente

En View usage se comprueba si se ha alcanzado Cycle quota, Maximum quota o Maximum access time. Después se revisan por separado Access Time, Web Policy, la regla de firewall y la autenticación. Captive Portal también puede aparecer por credenciales incorrectas u otros problemas de autenticación; la cuota no es automáticamente la causa. Configurar y probar Captive Portal en Sophos Firewall explica la ruta completa de inicio de sesión.

El consumo no coincide con lo esperado

Se comprueba si está configurado Total network traffic o límites separados de subida y descarga. Después se comparan los detalles mensuales, la IP de origen, la Firewall Rule ID y la transferencia de prueba real. Una Network Traffic Quota cuenta volumen de datos, no solo descargas visibles en el navegador; el tráfico en segundo plano del usuario autenticado también puede contribuir al consumo.

El restablecimiento solo ayuda brevemente

Si el usuario vuelve a desconectarse poco después del restablecimiento, se comprueban los valores de la política, el ciclo, el máximo, la excepción de usuario y el consumo real. El contador no se restablece repetidamente antes de comprender la causa.

Rollback y funcionamiento

Un rollback controlado restablece de forma trazable el estado anterior de herencia y contadores:

1. Restaurar la asignación anterior de Surfing y Network Traffic para el usuario o grupo piloto.
2. En AD, volver a autenticar al usuario y comprobar la Main Group.
3. Documentar View usage y el consumo actual.
4. Restablecer el accounting de forma controlada solo si se acordó para la prueba.
5. Ejecutar un pequeño flujo de prueba y comprobar la Firewall Rule ID y los registros.
6. Eliminar las políticas piloto solo cuando ya no exista ninguna dependencia de usuario o grupo.
7. Actualizar el ticket, el owner, los límites y el resultado de la prueba.

En funcionamiento, toda cuota compartida necesita un nombre comprensible, una Description, un owner y una justificación documentada para el ciclo, el crédito y el límite total. Los cambios se validan con un usuario piloto, una prueba positiva de consumo y una prueba negativa de límite.

Lista de comprobación operativa

• El consumo de tiempo y el consumo de datos se han planificado por separado.
• Surfing Quota y Network Traffic Quota tienen nombres y owners comprensibles.
• Cycle, Validity, Quota per cycle y Maximum están justificados.
• Las políticas están asignadas al grupo o usuario correcto.
• Se han comprobado las excepciones de usuario.
• En AD, la Main Group es correcta; no se presuponen Other group memberships.
• Los Clientless Users no se planifican con cuotas de usuario.
• El usuario piloto aparece como Live User.
• La regla de firewall basada en usuarios registra el tráfico de prueba.
• View usage, User Portal, Firewall Rule ID y el consumo real coinciden.
• Reset user accounting solo se utiliza con documentación y autorización.
• El estado anterior y el rollback están documentados.

Preguntas frecuentes