Configurar horarios para reglas y políticas en Sophos Firewall

Un horario hace que una regla o política de Sophos Firewall solo sea efectiva durante una franja definida. Resulta práctico para horarios laborales, accesos de invitados o ventanas de mantenimiento aprobadas. La solución solo es segura cuando la hora del firewall es correcta, se elige el tipo de horario adecuado y ninguna regla más amplia toma el relevo para el mismo tráfico fuera de esa franja.

El procedimiento rápido para una regla de firewall controlada por horario es el siguiente:

1. En Administration > Time, comprobar la hora actual y la zona horaria.
2. En Profiles > Schedule > Add, crear un horario Recurring o One-time.
3. Abrir la regla de firewall afectada y seleccionar el horario en During scheduled time.
4. Volver a comprobar la posición de la regla, el origen, el destino, el servicio y el registro.
5. Probar una conexión nueva antes, durante y después de la franja horaria.
6. En Log Viewer, comprobar qué Firewall Rule ID procesa realmente el tráfico.

⚠️ Un horario no convierte en segura una regla demasiado amplia. Solo limita cuándo es efectiva esa regla o política concreta. El origen, el destino, los servicios, los usuarios, las funciones de protección y el orden de las reglas deben seguir planificándose de forma restrictiva.

Qué controla un horario

Sophos Firewall utiliza los horarios como objetos de tiempo reutilizables. Pueden limitar temporalmente reglas de firewall, políticas web, políticas de aplicaciones, políticas de traffic shaping, políticas de tiempo de acceso y análisis de puntos de acceso no autorizados.

El horario por sí solo no permite ni bloquea tráfico. Solo surte efecto cuando se asigna a una regla, política o análisis. All the time significa que no se desea ninguna restricción temporal.

El punto de control adecuado depende del objetivo:

• Si toda la ruta de red solo debe estar abierta en determinados horarios, el horario debe configurarse en la regla de firewall.
• Si dentro de una ruta abierta solo debe cambiar una acción web o de aplicación, el horario se asigna a la regla de política correspondiente.
• Si el acceso a Internet de un usuario o grupo debe permitirse o bloquearse según la hora, una política de tiempo de acceso suele ser más clara.
• Un horario One-time solo puede asignarse a una regla de firewall.

Recurrente o One-time

En Recurrence type hay dos modelos disponibles:

• Recurring: Se repite los días de la semana y a las horas seleccionadas. Este tipo sirve, por ejemplo, para horarios de oficina o ventanas de mantenimiento periódicas.
• One-time: Se aplica entre una fecha inicial y una final a las horas definidas. Este tipo sirve para una conferencia concreta, un acceso temporal de invitados o un mantenimiento puntual.

Un horario One-time solo puede aplicarse a reglas de firewall. Las políticas web, de aplicaciones y de traffic shaping, las políticas de tiempo de acceso y los análisis de puntos de acceso no autorizados requieren un horario recurrente.

Con Expand, un horario recurrente puede tener distintas horas de inicio y fin para cada día de la semana. Esto resulta más claro que varias reglas casi idénticas, siempre que la aprobación funcional sea la misma todos los días.

Schedule y Access Time no son lo mismo

Un horario solo describe días y horas. Una Access time policy, en cambio, combina un horario recurrente con la acción Allow o Deny y se asigna a usuarios, grupos o usuarios invitados.

Configurar Access Time para usuarios y grupos explica la asignación completa, la prioridad del usuario sobre el grupo y el límite del grupo principal de AD.

Para una ruta de red limitada temporalmente, el horario debe incluirse directamente en la regla de firewall. Para el acceso a Internet de un usuario o grupo en función de la hora, puede ser más adecuada una política de tiempo de acceso. Ambos mecanismos no deben superponerse sin un motivo claro, porque entonces resulta difícil determinar qué nivel finaliza el acceso.

Planificar la base horaria y los valores de ejemplo

Los horarios se rigen por el reloj y la zona horaria del firewall. Antes de configurarlos, hay que comprobar al menos Current time y Time zone en Administration > Time. Configurar la hora del sistema y NTP en Sophos Firewall explica cómo verificar correctamente NTP y la zona horaria.

Cambiar los servidores NTP no es un paso rutinario de resolución de problemas: Sophos indica que todas las conexiones IPsec se vuelven a establecer al hacerlo. Para la validación inicial del horario basta con una comprobación de solo lectura de la base horaria existente.

Los siguientes valores de muestra ilustran el procedimiento. En el ejemplo recurrente para invitados, la zona y la red son campos de coincidencia separados:

• Recurring: Guest_BusinessHours, de lunes a viernes, de 07:30 a 18:00
• Regla de firewall: Guest_to_WAN_BusinessHours
• Source zones: la zona propia de invitados, Guest en el ejemplo
• Source networks and devices: net_Guest_10.50.0.0_24
• Destination zones: WAN
• Destination networks: Any
• Servicios: HTTP y HTTPS
• One-time: Vendor_Maintenance_2026-09-15, el 15 de septiembre de 2026 de 22:00 a 23:30
• Origen externo de ejemplo: 198.51.100.25
• Destino interno de ejemplo: 10.20.30.40
• Servicio: HTTPS

198.51.100.25 es una dirección de documentación y debe sustituirse por la dirección pública fija del proveedor. Los nombres, redes, fecha y horas también son valores de muestra. Deben utilizarse el origen realmente aprobado, el destino más restrictivo, los servicios necesarios y la franja autorizada. El ejemplo de mantenimiento presupone una ruta entrante que ya funciona y se ha probado. Si el servidor interno se publica en Internet, DNAT y la regla de firewall asociada deben estar correctamente configurados con independencia del horario; consulte Publicar un servidor mediante DNAT o PAT.

Crear un horario recurrente

Para el ejemplo de invitados, se crea un horario recurrente:

1. Abrir Profiles > Schedule.
2. Seleccionar Add.
3. Establecer Name en Guest_BusinessHours.
4. En Description, documentar la finalidad, el responsable y la zona horaria, por ejemplo Acceso web de invitados, Lun-Vie 07:30-18:00 Europe/Zurich, Responsable TI.
5. Establecer Recurrence type en Recurring.
6. Seleccionar de lunes a viernes.
7. Establecer Start time en 07:30 y Stop time en 18:00.
8. Dejar desactivados sábado y domingo.
9. Para horarios diarios distintos, utilizar Expand y comprobar cada día por separado.
10. Guardar con Save.

Después de guardarlo, asigne el horario al punto de control previsto. Hasta entonces no tiene efecto.

Asignar un horario a una regla de firewall

La autorización propiamente dicha sigue siendo una regla de firewall normal. Comprender y configurar de forma segura las reglas de Sophos Firewall explica cómo interactúan los criterios de coincidencia, las funciones de protección y el orden de las reglas.

Para el ejemplo de invitados:

1. Abrir Rules and policies > Firewall rules y seleccionar IPv4.
2. Para una regla nueva, abrir Add firewall rule > New firewall rule; también puede editarse una regla existente ya documentada.
3. Establecer Action en Accept y limitar Source zones y Source networks and devices a la red de invitados.
4. Establecer Destination zones en WAN y Destination networks en Any. Si solo se necesitan destinos concretos, conviene usar un objeto más restrictivo.
5. Seleccionar únicamente los Services necesarios, HTTP y HTTPS.
6. En During scheduled time, seleccionar Guest_BusinessHours.
7. Asignar políticas web, de aplicaciones e IPS adecuadas.
8. Activar Log firewall traffic.
9. Comprobar la posición de la regla y guardar.

Para una red privada de invitados también debe existir una regla SNAT adecuada, salvo que el sistema ascendente enrute las direcciones de origen privadas. La regla NAT se comprueba por separado, ya que Sophos Firewall también evalúa las reglas NAT por primera coincidencia. El horario no corrige una coincidencia NAT ausente o errónea. El ejemplo solo permite HTTP y HTTPS; la resolución DNS necesaria para el acceso por nombre debe funcionar por una ruta autorizada y probada por separado.

Sophos Firewall evalúa las reglas de firewall de arriba abajo. Si la regla programada no es efectiva fuera de su horario, una regla posterior y más amplia puede permitir el mismo tráfico. Por tanto, una regla Allow controlada por horario necesita una coincidencia claramente separada o una lógica de bloqueo posterior planificada conscientemente. La solución se valida mediante la Firewall Rule ID real, no solo con una solicitud de página satisfactoria.

Regla de mantenimiento puntual

Para una única ventana de acceso de un proveedor, se crea un horario puntual específico:

1. Abrir Profiles > Schedule > Add.
2. Establecer Name en Vendor_Maintenance_2026-09-15 y documentar en Description el ticket, el responsable y la finalidad.
3. Establecer Recurrence type en One-time.
4. Establecer tanto la fecha inicial como la final en el 15 de septiembre de 2026.
5. Establecer Start time en 22:00 y Stop time en 23:30.
6. Volver a contrastar los valores con la ventana aprobada y la zona horaria del firewall, y guardar con Save.
7. Asignar el horario en During scheduled time a la regla de mantenimiento restrictiva que ya se haya probado.

La regla permanece como objeto de configuración después de la franja, pero no coincide fuera del horario. Por ello, el ticket y el responsable también deben definir si, tras finalizar, la regla se desactiva, se elimina o se reutiliza con un horario nuevo.

Una regla puntual no sustituye a unos criterios restrictivos. En el ejemplo con DNAT, la autorización incluye Source zones WAN, la dirección confirmada en Source networks and devices, la zona interna DMZ en Destination zones, Destination networks 10.20.30.40, el servicio HTTPS, el registro y la posición correcta. La regla de firewall comprueba el destino interno traducido después de DNAT. Any como red de origen o servicio sigue siendo un riesgo innecesario incluso durante una franja breve.

Utilizar horarios en políticas

Los horarios recurrentes también pueden utilizarse en otras áreas:

• Web policy: Una regla de la política web puede limitarse temporalmente.
• Application policy: Una regla de filtro de aplicaciones puede tener un horario.
• Traffic shaping policy: En System services > Traffic shaping > Add > Add schedule se asigna un horario a la regla de ancho de banda. Después puede surtir efecto mediante un usuario, una regla de firewall, una categoría web o una entrada de aplicación.
• Access time policy: Un horario recurrente determina cuándo se aplica Allow o Deny a los usuarios y grupos asignados.
• Rogue AP scan: En dispositivos con Wi-Fi integrado, el horario se selecciona en Wireless > Rogue AP scan > General settings > Schedule system-triggered scan at. El análisis desconecta brevemente a los clientes, por lo que la franja debe contemplar esta interrupción.

El control temporal de la política y la asignación de la política son pasos separados. Una política web o de aplicaciones solo surte efecto a través de la regla de firewall asociada. Configurar y probar Application Control en Sophos Firewall explica por completo el control de aplicaciones, mientras que Configurar Web Protection con políticas web en Sophos Firewall cubre la lógica del filtrado web.

Las distintas capas temporales de una misma conexión deben documentarse deliberadamente. Un horario en la regla de firewall y otro distinto en una política web o de aplicaciones pueden producir resultados técnicos diferentes: la ruta de red puede permanecer abierta mientras solo cambia una acción web o de aplicación concreta.

Probar de forma fiable los límites temporales

Una configuración guardada todavía no es una prueba. La validación utiliza una conexión nueva y los mismos valores de prueba antes, durante y después de la franja horaria:

1. Documentar Current time y Time zone en el firewall.
2. Comprobar el tipo de horario, los días de la semana, la hora de inicio y la de fin.
3. Comprobar la posición de la regla y During scheduled time.
4. Poco antes del inicio, generar un flujo de prueba definido y registrar el comportamiento de bloqueo o fallback esperado.
5. Abrir una conexión nueva después del inicio.
6. En Log Viewer, comparar el origen, el destino, el servicio, la Firewall Rule ID, la acción y la marca de tiempo.
7. Después del final, abrir otra conexión nueva y comprobar qué regla se aplica ahora.
8. Para políticas web o de aplicaciones, comprobar además la política, el usuario y la acción de la política.

El procedimiento completo con Log Viewer, Packet Capture y Rule ID se describe en Probar correctamente una regla de Sophos Firewall.

Sophos no documenta de forma general que todas las sesiones existentes finalicen inmediatamente al terminar un horario. Por ello, para accesos críticos para la seguridad se observan tanto una conexión nueva después del límite como una sesión que ya estaba activa. Si las sesiones existentes deben finalizar de inmediato, el horario no puede considerarse la única medida de protección sin una prueba real.

Delimitar los errores sistemáticamente

La regla se aplica a una hora incorrecta

Primero hay que abrir Administration > Time y comparar Current time y Time zone con la hora operativa documentada. Después se comprueban el día de la semana, la hora de inicio, la hora de fin y los valores diarios configurados mediante Expand. Tras Sync now, Current time no se actualiza de inmediato en la vista; hay que recargar WebAdmin antes de concluir que la hora sigue siendo incorrecta. Para evaluar los horarios cuentan la hora y la zona horaria mostradas en el firewall.

El tráfico funciona fuera de la franja

En Log Viewer se identifica la Firewall Rule ID que procesó realmente el tráfico. Con frecuencia, una regla Allow general posterior toma el relevo. En ese caso se corrigen el orden de las reglas y la lógica de coincidencia, en lugar de ampliar el horario. Si no aparece un registro de regla adecuado, Packet Capture y la regla implícita de descarte total #0 ayudan a delimitar la causa.

One-time no está disponible en una política

Este es el límite documentado del producto: los horarios One-time solo pueden asignarse a reglas de firewall. Las políticas web, de aplicaciones, de traffic shaping y de tiempo de acceso requieren un horario recurrente.

No se puede eliminar el horario

Un horario en uso no puede eliminarse directamente. Primero se identifican todas las reglas, políticas y análisis dependientes. Después se asigna a cada dependencia otro horario adecuado o se elimina de forma controlada. Solo entonces se elimina el horario que ya no está en uso.

La política cambia, pero la ruta de red sigue abierta

Un horario de política solo controla la regla de política correspondiente. Si toda la ruta de red debe cerrarse fuera de la franja, la regla de firewall también debe limitarse temporalmente y probarse frente a reglas fallback posteriores.

Planificar los cambios y la reversión

Antes de un cambio se documentan el nombre del horario, el tipo, los días, las horas, la zona horaria, todos los usos y la posición de las reglas de firewall afectadas. All the time no es una reversión universal, ya que elimina por completo la limitación temporal.

La reversión depende de lo que se haya cambiado. Si solo se modificó el horario, se reasigna el anterior. Una regla de firewall nueva se desactiva o elimina de forma controlada; en una regla existente se restauran la acción, los campos de coincidencia, las políticas, el registro y la posición a los valores anteriores documentados. Si se modificaron DNAT o SNAT para la ruta, esas reglas y sus posiciones también forman parte de la reversión.

Una reversión típica es la siguiente:

1. Mantener abiertas la sesión de administrador existente y una vía de administración alternativa.
2. Según la situación inicial, reasignar el horario anterior, desactivar la regla nueva o restaurar todos los campos modificados.
3. Comparar las reglas NAT asociadas, la posición y el estado de la regla con los valores anteriores documentados.
4. Probar con una conexión nueva y la Rule ID esperada.
5. Eliminar el horario nuevo solo cuando ya no existan dependencias.
6. Actualizar el ticket, el responsable y el resultado de la prueba.

En una autorización de mantenimiento puntual, la retirada planificada debe incluirse en el ticket antes de la activación. Así no queda una regla inactiva pero no documentada tras finalizar el mantenimiento.

Preguntas frecuentes