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.

Statt einen eigenen Schedule anzulegen, kann ein vorhandener Standard-Schedule verwendet werden, wenn sein Typ und seine tatsächlich konfigurierten Tage, Zeiten und gegebenenfalls Datumsgrenzen zum genehmigten Bedarf passen. Die Werte werden unter Profiles > Schedule geprüft, nicht aus dem Namen abgeleitet. Passt kein Standard-Schedule, wird ein eigener wiederkehrender oder einmaliger Schedule erstellt.

Welcher Kontrollpunkt passt, hängt vom Ziel ab:

• Soll der gesamte Netzwerkpfad nur zu bestimmten Zeiten offen sein, gehört der Schedule in die Firewall-Regel.
• Soll innerhalb eines offenen Pfads nur eine Web- oder Application-Aktion wechseln, erhält die betreffende Policy-Regel den Schedule.
• Soll der Internetzugriff eines Benutzers oder einer Gruppe zeitlich erlaubt oder gesperrt werden, ist eine Access-Time-Policy meist klarer.
• Ein One-time-Schedule lässt sich nur einer Firewall-Regel zuweisen.

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. Beim wiederkehrenden Gästezugang sind Zone und Netzwerk getrennte Match-Felder:

• Wiederkehrend: Guest_BusinessHours, Montag bis Freitag, 07:30 bis 18:00
• Firewall-Regel: Guest_to_WAN_BusinessHours
• Source zones: die eigene Gästezone, im Beispiel Guest
• Source networks and devices: net_Guest_10.50.0.0_24
• Destination zones: WAN
• Destination networks: 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. Das Wartungsbeispiel setzt einen bereits funktionierenden und getesteten eingehenden Pfad voraus. Wird der interne Server aus dem Internet veröffentlicht, müssen DNAT und die zugehörige Firewall-Regel unabhängig vom Schedule korrekt eingerichtet sein; der Ablauf steht unter Server per DNAT oder PAT veröffentlichen.

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, verantwortliche Stelle und Zeitzone dokumentieren, beispielsweise Gäste-Webzugriff, Mo-Fr 07:30-18:00 Europe/Zurich, verantwortlich: 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.

Nach dem Speichern wird der Schedule dem vorgesehenen Kontrollpunkt zugewiesen.

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 und IPv4 wählen.
2. Für eine neue Regel Add firewall rule > New firewall rule öffnen oder eine bestehende, bereits dokumentierte Regel bearbeiten.
3. Action auf Accept setzen und Source zones sowie Source networks and devices auf das Gäste-Netz begrenzen.
4. Destination zones auf WAN und Destination networks auf Any setzen. Wenn nur bestimmte Ziele nötig sind, ist ein engeres Zielobjekt besser.
5. Nur die benötigten Services HTTP und HTTPS auswählen.
6. Bei During scheduled time Guest_BusinessHours auswählen.
7. Passende Web-, Application- und IPS-Policies zuweisen.
8. Log firewall traffic aktivieren.
9. Regelposition prüfen und speichern.

Für ein privates Gäste-Netz muss ausserdem eine passende SNAT-Regel vorhanden sein, sofern der Upstream die privaten Quelladressen nicht routet. Die NAT-Regel wird separat geprüft, weil Sophos Firewall NAT-Regeln ebenfalls nach dem First-Match-Prinzip auswertet. Ein fehlender oder falscher NAT-Treffer wird nicht durch den Schedule behoben. Das Beispiel begrenzt nur HTTP und HTTPS; eine für namensbasierten Zugriff benötigte DNS-Auflösung muss über einen separat freigegebenen und geprüften Pfad funktionieren.

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 ein eigener One-time-Schedule erstellt:

1. Profiles > Schedule > Add öffnen.
2. Name auf Vendor_Maintenance_2026-09-15 setzen und in Description Ticket, verantwortliche Stelle und Zweck dokumentieren.
3. Recurrence type auf One-time setzen.
4. Startdatum und Enddatum auf den 15. September 2026 setzen.
5. Start time auf 22:00 und Stop time auf 23:30 setzen.
6. Die Werte nochmals gegen das genehmigte Fenster und die Firewall-Zeitzone prüfen und mit Save speichern.
7. Den Schedule bei During scheduled time der bereits getesteten, engen Wartungsregel zuweisen.

Die Regel bleibt nach dem Zeitfenster als Konfigurationsobjekt vorhanden, greift aber ausserhalb des Schedules nicht. Im Ticket wird deshalb auch festgelegt, 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 DNAT-Beispiel gehören Source zones WAN, die bestätigte Adresse unter Source networks and devices, Destination zones DMZ, Destination networks 10.20.30.40, der Service HTTPS, Logging und die richtige Regelposition in die Freigabe. Die Firewall-Regel prüft dabei das übersetzte interne Ziel nach DNAT. Any als Quellnetz oder 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: Eine Regel der Web Policy kann zeitlich begrenzt werden.
• Application Policy: Eine Application-Filter-Regel kann einen Schedule erhalten.
• Traffic shaping policy: Unter System services > Traffic shaping > Add > Add schedule erhält die Bandbreitenregel einen Schedule. Sie kann anschliessend über einen Benutzer, eine Firewall-Regel, eine Webkategorie oder einen Application-Eintrag wirksam werden.
• Access time policy: Ein wiederkehrender Schedule bestimmt, wann Allow oder Deny für zugewiesene Benutzer und Gruppen gilt.
• Rogue AP scan: Auf Geräten mit integriertem WLAN wird der Schedule unter Wireless > Rogue AP scan > General settings > Schedule system-triggered scan at ausgewählt. Der Scan trennt Clients kurzzeitig; das Zeitfenster muss diese Unterbrechung berücksichtigen.

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. Nach Sync now aktualisiert sich Current time nicht sofort in der Ansicht; WebAdmin muss neu geladen werden, bevor man eine weiterhin falsche Zeit diagnostiziert. Für die Schedule-Auswertung sind die auf der Firewall angezeigte Zeit und Zeitzone entscheidend.

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. All the time ist kein pauschaler Rückweg, weil es die zeitliche Begrenzung vollständig entfernt.

Um einen bestehenden Schedule zu ändern, Profiles > Schedule öffnen, den vorgesehenen Schedule eindeutig identifizieren und Edit anklicken. Die Änderung wirkt sich auf alle Verwendungen dieses Zeitobjekts aus. Die geänderten Tage, Zeiten und gegebenenfalls Datumsgrenzen gegen die Freigabe prüfen, mit Save speichern und die oben beschriebene Abnahme vor, innerhalb und nach dem Zeitfenster wiederholen.

Der Rückweg hängt davon ab, was geändert wurde. Wurde der Schedule selbst bearbeitet, werden seine dokumentierten Vorwerte wiederhergestellt; wurde nur die Zuweisung gewechselt, wird der unveränderte vorherige Schedule wieder zugewiesen. Das erneute Auswählen eines bearbeiteten Objekts stellt dessen Zeiten nicht wieder her. Eine neu angelegte Firewall-Regel wird deaktiviert oder kontrolliert entfernt; bei einer bestehenden Regel werden auch Action, Match-Felder, Policies, Logging und Position auf die dokumentierten Vorwerte zurückgesetzt. Wurden für den Pfad DNAT oder SNAT geändert, gehören diese Regeln und ihre Position ebenfalls zum Rückbau.

Ein typischer Rollback lautet:

1. Bestehende Admin-Sitzung und alternativen Managementzugang offenhalten.
2. Je nach Ausgangslage die dokumentierten Schedule-Vorwerte wiederherstellen oder den unveränderten vorherigen Schedule wieder zuweisen; die neue Regel deaktivieren oder alle geänderten Regelfelder wiederherstellen.
3. Zugehörige NAT-Regeln, Regelposition und Status mit den dokumentierten Vorwerten vergleichen.
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