Sophos Firewall Zeitpläne für Regeln und Policies einrichten

Ein Schedule macht eine Sophos-Firewall-Regel oder Policy nur während eines definierten Zeitfensters wirksam. Das ist praktisch für Arbeitszeiten, Gastzugänge oder ein genehmigtes Wartungsfenster. Sicher wird die Lösung erst, wenn die Firewall-Zeit stimmt, der passende Schedule-Typ gewählt ist und ausserhalb des Fensters keine breitere Regel denselben Traffic übernimmt.

Der Kurzweg für eine zeitgesteuerte Firewall-Regel lautet:

1. Unter Administration > Time aktuelle Uhrzeit und Zeitzone kontrollieren.
2. Unter Profiles > Schedule > Add einen wiederkehrenden oder einmaligen Schedule erstellen.
3. Die betroffene Firewall-Regel öffnen und den Schedule bei During scheduled time auswählen.
4. Regelposition, Source, Destination, Service und Logging erneut prüfen.
5. Je eine neue Verbindung vor, innerhalb und nach dem Zeitfenster testen.
6. Im Log Viewer kontrollieren, welche Firewall Rule ID den Traffic tatsächlich verarbeitet.

⚠️ Ein Schedule macht eine zu breite Regel nicht sicherer. Er begrenzt nur, wann genau diese Regel oder Policy wirksam ist. Source, Destination, Services, Benutzer, Schutzfunktionen und Regelreihenfolge müssen weiterhin eng geplant werden.

Was ein Schedule steuert

Sophos Firewall verwendet Schedules als wiederverwendbare Zeitobjekte. Sie können Firewall-Regeln, Web Policies, Application Policies, Traffic-Shaping-Policies, Access-Time-Policies und Rogue-AP-Scans zeitlich begrenzen.

Der Schedule selbst erlaubt oder blockiert noch keinen Traffic. Er wirkt erst, wenn er einer Regel, Policy oder einem Scan zugewiesen wird. All the time bedeutet, dass keine zeitliche Einschränkung vorgesehen ist.

Wiederkehrend oder einmalig

Unter Recurrence type stehen zwei Modelle zur Verfügung:

• Recurring: Wiederholt sich an den gewählten Wochentagen und Uhrzeiten. Dieser Typ passt beispielsweise für Bürozeiten oder regelmässige Wartungsfenster.
• One-time: Gilt zwischen einem Start- und Enddatum zu den definierten Uhrzeiten. Dieser Typ passt für eine einzelne Konferenz, einen temporären Gastzugang oder eine einmalige Wartung.

Ein One-time-Schedule lässt sich ausschliesslich auf Firewall-Regeln anwenden. Web-, Application- und Traffic-Shaping-Policies, Access-Time-Policies sowie Rogue-AP-Scans benötigen einen wiederkehrenden Schedule.

Mit Expand können bei einem wiederkehrenden Schedule unterschiedliche Start- und Endzeiten für einzelne Wochentage hinterlegt werden. Das ist übersichtlicher als mehrere fast identische Regeln, solange die fachliche Freigabe an allen Tagen gleich bleibt.

Schedule und Access Time sind nicht dasselbe

Ein Schedule beschreibt nur Tage und Uhrzeiten. Eine Access time policy kombiniert dagegen einen wiederkehrenden Schedule mit der Aktion Allow oder Deny und wird Benutzern, Gruppen oder Gastbenutzern zugewiesen.

Die vollständige Zuweisung, die Benutzer-vor-Gruppen-Priorität und die AD-Main-Group-Grenze erklärt Access Time für Benutzer und Gruppen einrichten.

Für einen zeitlich begrenzten Netzwerkpfad gehört der Schedule direkt in die Firewall-Regel. Für zeitabhängigen Internetzugriff eines Benutzers oder einer Gruppe kann eine Access-Time-Policy passender sein. Beide Mechanismen sollten nicht ohne klaren Grund überlagert werden, weil sonst schwer erkennbar ist, welche Ebene den Zugriff beendet.

Zeitbasis und Beispielwerte planen

Schedules richten sich nach der Uhr und Zeitzone der Firewall. Vor der Konfiguration werden deshalb unter Administration > Time mindestens Current time und Time zone kontrolliert. Wie NTP und Zeitzone sauber geprüft werden, erklärt Sophos Firewall Systemzeit und NTP konfigurieren.

Ein Wechsel der NTP-Server ist kein beiläufiger Troubleshooting-Schritt: Sophos weist darauf hin, dass dabei alle IPsec-Verbindungen neu aufgebaut werden. Für eine Schedule-Abnahme genügt zunächst die lesende Kontrolle der bestehenden Zeitbasis.

Die folgenden Musterwerte machen den Ablauf greifbar:

• Wiederkehrend: Guest_BusinessHours, Montag bis Freitag, 07:30 bis 18:00
• Firewall-Regel: Guest_to_WAN_BusinessHours
• Source: net_Guest_10.50.0.0_24
• Destination: WAN und Any
• Services: HTTP und HTTPS
• Einmalig: Vendor_Maintenance_2026-09-15, am 15. September 2026 von 22:00 bis 23:30
• Externe Beispielquelle: 198.51.100.25
• Internes Beispielziel: 10.20.30.40
• Service: HTTPS

198.51.100.25 ist eine Dokumentationsadresse und wird durch die feste öffentliche Adresse des Dienstleisters ersetzt. Auch Namen, Netze, Datum und Uhrzeiten sind Musterwerte. Gewählt werden die tatsächlich genehmigte Quelle, das engste Ziel, die benötigten Services und das freigegebene Zeitfenster.

Wiederkehrenden Schedule erstellen

Für das Gäste-Beispiel wird ein wiederkehrender Schedule angelegt:

1. Profiles > Schedule öffnen.
2. Add auswählen.
3. Name auf Guest_BusinessHours setzen.
4. In Description Zweck, Owner und Zeitzone dokumentieren, beispielsweise Gäste-Webzugriff, Mo-Fr 07:30-18:00 Europe/Zurich, Owner IT.
5. Recurrence type auf Recurring setzen.
6. Montag bis Freitag auswählen.
7. Start time auf 07:30 und Stop time auf 18:00 setzen.
8. Samstag und Sonntag deaktiviert lassen.
9. Bei abweichenden Tageszeiten Expand verwenden und jeden Tag einzeln kontrollieren.
10. Mit Save speichern.

Der gespeicherte Schedule hat noch keine Wirkung. Erst die Zuweisung zu einer Regel oder Policy aktiviert die Zeitsteuerung für den entsprechenden Pfad.

Schedule einer Firewall-Regel zuweisen

Die eigentliche Freigabe bleibt eine normale Firewall-Regel. Wie Match-Kriterien, Schutzfunktionen und Reihenfolge zusammenspielen, steht unter Sophos Firewall-Regeln verstehen und sicher konfigurieren.

Für das Gäste-Beispiel:

1. Rules and policies > Firewall rules öffnen.
2. Die Regel Guest_to_WAN_BusinessHours erstellen oder eine bestehende, bereits dokumentierte Regel bearbeiten.
3. Source zones und Source networks and devices auf das Gäste-Netz begrenzen.
4. Bei During scheduled time Guest_BusinessHours auswählen.
5. Destination zones auf WAN setzen und interne Ziele ausschliessen.
6. Nur die benötigten Services auswählen.
7. Passende Web-, Application- und IPS-Policies zuweisen.
8. Log firewall traffic aktivieren.
9. Regelposition prüfen und speichern.

Sophos Firewall wertet Firewall-Regeln von oben nach unten aus. Ist die geplante Regel ausserhalb ihres Schedules nicht wirksam, kann eine spätere, breitere Regel denselben Traffic erlauben. Eine zeitgesteuerte Allow-Regel benötigt deshalb entweder einen eindeutig getrennten Match oder eine bewusst geplante nachfolgende Blocklogik. Die Lösung wird anhand der tatsächlichen Firewall Rule ID abgenommen, nicht nur anhand eines erfolgreichen Seitenaufrufs.

Einmalige Wartungsregel

Für einen einzelnen Dienstleisterzugriff wird unter Profiles > Schedule > Add stattdessen One-time gewählt. Startdatum, Enddatum und Uhrzeit werden aus dem genehmigten Wartungsfenster übernommen. Danach wird der Schedule der engen Firewall-Regel bei During scheduled time zugewiesen.

Die Regel bleibt nach dem Zeitfenster als Konfigurationsobjekt vorhanden, trifft aber ausserhalb des Schedules nicht. Ticket und Owner sollten deshalb auch festlegen, ob die Regel nach Abschluss deaktiviert, gelöscht oder für einen späteren Termin mit neuem Schedule wiederverwendet werden darf.

Eine einmalige Regel ist kein Ersatz für enge Kriterien. Beim Beispiel gehören ausschliesslich die bestätigte Quelladresse, der Zielhost 10.20.30.40, der benötigte Service HTTPS, Logging und die richtige Regelposition in die Freigabe. Eine breite WAN-Quelle oder Any als Service bleibt auch während eines kurzen Fensters unnötig riskant.

Schedules in Policies verwenden

Wiederkehrende Schedules können auch in anderen Bereichen eingesetzt werden:

• Web Policy: Unter Constraints wird festgelegt, wann eine Policy-Regel gilt.
• Application Policy: Eine Application-Filter-Regel kann einen Schedule erhalten.
• Traffic shaping policy: Die Bandbreitenregel wird nur während des gewählten Schedules angewendet.
• Access time policy: Ein wiederkehrender Schedule bestimmt, wann Allow oder Deny für zugewiesene Benutzer und Gruppen gilt.
• Rogue AP scan: Der Scan kann zu wiederkehrenden Zeiten ausgeführt werden.

Die Zeitsteuerung der Policy und die Zuweisung der Policy sind getrennte Schritte. Eine Web- oder Application-Policy wirkt erst über die zugehörige Firewall-Regel. Die Anwendungskontrolle wird unter Sophos Firewall Application Control einrichten und testen und die Webfilterlogik unter Sophos Firewall Web Protection mit Web Policies einrichten vollständig erklärt.

Mehrere Zeitstufen in derselben Verbindung sollten bewusst dokumentiert werden. Ein Schedule in der Firewall-Regel und ein anderer Schedule in einer Web- oder Application-Policy können technisch unterschiedliche Ergebnisse erzeugen: Der Netzwerkpfad bleibt beispielsweise offen, während nur eine bestimmte Web- oder App-Aktion wechselt.

Zeitgrenzen zuverlässig testen

Eine gespeicherte Konfiguration ist noch kein Nachweis. Die Abnahme verwendet eine neue Verbindung und dieselben Testwerte vor, innerhalb und nach dem Zeitfenster:

1. Current time und Time zone auf der Firewall dokumentieren.
2. Schedule-Typ, Wochentage, Start- und Stopzeit kontrollieren.
3. Regelposition und During scheduled time prüfen.
4. Kurz vor Beginn einen definierten Testfluss erzeugen und erwartetes Block- oder Fallback-Verhalten festhalten.
5. Nach Beginn eine neue Verbindung öffnen.
6. Im Log Viewer Source, Destination, Service, Firewall Rule ID, Action und Zeitstempel vergleichen.
7. Nach Ende erneut eine neue Verbindung öffnen und kontrollieren, welche Regel jetzt greift.
8. Bei Web- oder Application-Policies zusätzlich Policy, Benutzer und Policy-Aktion prüfen.

Der vollständige Ablauf mit Log Viewer, Packet Capture und Rule ID steht unter Sophos Firewall-Regel sauber testen.

Sophos dokumentiert nicht allgemein, dass beim Ende eines Schedules jede bereits bestehende Session sofort getrennt wird. Für eine sicherheitskritische Freigabe werden deshalb sowohl eine neue Verbindung nach der Grenze als auch eine bereits laufende Sitzung beobachtet. Wenn bestehende Sessions zwingend sofort enden müssen, darf der Schedule ohne diesen realen Nachweis nicht als alleinige Schutzmassnahme gelten.

Fehler systematisch eingrenzen

Regel greift zur falschen Uhrzeit

Zuerst Administration > Time öffnen und Current time sowie Time zone mit der dokumentierten Betriebszeit vergleichen. Danach Wochentag, Startzeit, Stopzeit und gegebenenfalls die mit Expand gesetzten Tageswerte prüfen. Die Zeitzone des Admin-Browsers ändert die Firewall-Zeit nicht.

Traffic funktioniert ausserhalb des Fensters

Im Log Viewer die tatsächlich verwendete Firewall Rule ID ermitteln. Häufig übernimmt eine spätere allgemeine Allow-Regel den Traffic. Dann wird nicht der Schedule verbreitert, sondern Regelreihenfolge und Match-Logik werden korrigiert. Fehlt ein passender Regel-Log, helfen Packet Capture und die implizite Drop-all-Regel #0 bei der Abgrenzung.

One-time ist in einer Policy nicht verfügbar

Das ist die dokumentierte Produktgrenze: One-time-Schedules lassen sich nur Firewall-Regeln zuweisen. Für Web-, Application-, Traffic-Shaping- oder Access-Time-Policies wird ein wiederkehrender Schedule benötigt.

Schedule lässt sich nicht löschen

Ein verwendeter Schedule kann nicht direkt entfernt werden. Zuerst werden alle abhängigen Regeln, Policies und Scans ermittelt. Danach erhält jede Abhängigkeit einen anderen passenden Schedule oder wird kontrolliert entfernt. Erst der unbenutzte Schedule wird gelöscht.

Policy wechselt, der Netzwerkpfad bleibt offen

Ein Policy-Schedule steuert nur die entsprechende Policy-Regel. Soll der ganze Netzwerkpfad ausserhalb des Fensters geschlossen sein, muss auch die Firewall-Regel passend zeitlich begrenzt und gegen spätere Fallback-Regeln getestet werden.

Änderungen und Rollback planen

Vor einer Änderung werden Schedule-Name, Typ, Tage, Zeiten, Zeitzone, alle Verwendungen und die Position betroffener Firewall-Regeln dokumentiert. Für einen sicheren Rückweg wird nicht blind All the time gesetzt, sondern der vorherige Schedule wieder zugewiesen.

Ein typischer Rollback lautet:

1. Bestehende Admin-Sitzung und alternativen Managementzugang offenhalten.
2. Der betroffenen Regel oder Policy den dokumentierten vorherigen Schedule zuweisen.
3. Regelposition und Status unverändert kontrollieren.
4. Mit einer neuen Verbindung und der erwarteten Rule ID testen.
5. Den neuen Schedule erst löschen, wenn keine Abhängigkeit mehr besteht.
6. Ticket, Owner und Testergebnis aktualisieren.

Bei einer einmaligen Wartungsfreigabe gehört der geplante Rückbau bereits vor dem Aktivieren ins Ticket. So bleibt nach dem Termin keine inaktive, aber undokumentierte Regel zurück.

Häufige Fragen