Konfiguracja harmonogramów reguł i zasad na Sophos Firewall

Harmonogram sprawia, że reguła lub zasada Sophos Firewall obowiązuje tylko w zdefiniowanym przedziale czasu. Jest to przydatne w przypadku godzin pracy, dostępu dla gości lub zatwierdzonego okna serwisowego. Rozwiązanie jest bezpieczne dopiero wtedy, gdy czas zapory jest prawidłowy, wybrano właściwy typ harmonogramu, a poza oknem żadna szersza reguła nie przejmuje tego samego ruchu.

Skrócony przebieg konfiguracji reguły zapory sterowanej czasem wygląda następująco:

1. W sekcji Administration > Time sprawdzić bieżący czas i strefę czasową.
2. W sekcji Profiles > Schedule > Add utworzyć harmonogram cykliczny lub jednorazowy.
3. Otworzyć odpowiednią regułę zapory i wybrać harmonogram w polu During scheduled time.
4. Ponownie sprawdzić pozycję reguły, źródło, cel, usługę i rejestrowanie.
5. Przetestować nowe połączenie przed przedziałem, w jego trakcie i po jego zakończeniu.
6. W Log Viewer sprawdzić, który Firewall Rule ID faktycznie przetwarza ruch.

⚠️ Harmonogram nie zapewnia bezpieczeństwa zbyt szerokiej regule. Ogranicza jedynie czas obowiązywania tej konkretnej reguły lub zasady. Źródło, cel, usługi, użytkownicy, funkcje ochronne i kolejność reguł nadal muszą być ściśle zaplanowane.

Co kontroluje harmonogram

Sophos Firewall używa harmonogramów jako obiektów czasu wielokrotnego użytku. Mogą one czasowo ograniczać reguły zapory, zasady internetowe, zasady aplikacji, zasady traffic shaping, zasady czasu dostępu i skanowanie nieautoryzowanych punktów dostępowych.

Sam harmonogram nie zezwala na ruch ani go nie blokuje. Zaczyna działać dopiero po przypisaniu go do reguły, zasady lub skanowania. All the time oznacza, że nie przewidziano ograniczenia czasowego.

Cykliczny lub jednorazowy

W polu Recurrence type są dostępne dwa modele:

• Recurring: powtarza się w wybrane dni tygodnia i o wybranych godzinach. Ten typ nadaje się na przykład do godzin biurowych lub regularnych okien serwisowych.
• One-time: obowiązuje między datą rozpoczęcia i zakończenia w zdefiniowanych godzinach. Ten typ nadaje się do pojedynczej konferencji, tymczasowego dostępu dla gości lub jednorazowej konserwacji.

Harmonogram One-time można stosować wyłącznie do reguł zapory. Zasady internetowe, aplikacji i traffic shaping, zasady czasu dostępu oraz skanowanie nieautoryzowanych punktów dostępowych wymagają harmonogramu cyklicznego.

Opcja Expand pozwala ustawić w harmonogramie cyklicznym różne godziny rozpoczęcia i zakończenia dla poszczególnych dni tygodnia. Jest to bardziej przejrzyste niż kilka niemal identycznych reguł, o ile zatwierdzenie biznesowe jest takie samo we wszystkie dni.

Schedule i Access Time to nie to samo

Harmonogram opisuje wyłącznie dni i godziny. Access time policy łączy natomiast harmonogram cykliczny z działaniem Allow lub Deny i jest przypisywana użytkownikom, grupom lub użytkownikom-gościom.

Konfiguracja Access Time dla użytkowników i grup objaśnia pełne przypisanie, pierwszeństwo ustawienia użytkownika przed grupą i ograniczenie do głównej grupy AD.

W przypadku czasowo ograniczonej ścieżki sieciowej harmonogram należy umieścić bezpośrednio w regule zapory. Dla zależnego od czasu dostępu do Internetu użytkownika lub grupy bardziej odpowiednia może być zasada czasu dostępu. Oba mechanizmy nie powinny być nakładane bez wyraźnego powodu, ponieważ utrudnia to ustalenie, która warstwa kończy dostęp.

Planowanie podstawy czasu i wartości przykładowych

Harmonogramy korzystają z zegara i strefy czasowej zapory. Przed konfiguracją należy więc sprawdzić co najmniej Current time oraz Time zone w sekcji Administration > Time. Artykuł Konfiguracja czasu systemowego i NTP na Sophos Firewall wyjaśnia, jak prawidłowo sprawdzić NTP i strefę czasową.

Zmiana serwerów NTP nie jest rutynowym krokiem diagnostycznym: Sophos informuje, że powoduje ona ponowne zestawienie wszystkich połączeń IPsec. Do wstępnej walidacji harmonogramu wystarczy kontrola istniejącej podstawy czasu w trybie tylko do odczytu.

Poniższe wartości przykładowe przedstawiają konkretny przebieg:

• Recurring: Guest_BusinessHours, od poniedziałku do piątku, od 07:30 do 18:00
• Reguła zapory: Guest_to_WAN_BusinessHours
• Źródło: net_Guest_10.50.0.0_24
• Cel: WAN i Any
• Usługi: HTTP i HTTPS
• One-time: Vendor_Maintenance_2026-09-15, 15 września 2026 od 22:00 do 23:30
• Zewnętrzne źródło przykładowe: 198.51.100.25
• Wewnętrzny cel przykładowy: 10.20.30.40
• Usługa: HTTPS

198.51.100.25 jest adresem dokumentacyjnym i należy go zastąpić stałym publicznym adresem usługodawcy. Nazwy, sieci, data i godziny również są wartościami przykładowymi. Należy użyć faktycznie zatwierdzonego źródła, najwęższego celu, wymaganych usług oraz autoryzowanego przedziału czasu.

Tworzenie harmonogramu cyklicznego

Dla przykładu sieci gościnnej tworzony jest harmonogram cykliczny:

1. Otworzyć Profiles > Schedule.
2. Wybrać Add.
3. Ustawić Name na Guest_BusinessHours.
4. W polu Description udokumentować cel, właściciela i strefę czasową, na przykład Dostęp internetowy gości, pon-pt 07:30-18:00 Europe/Zurich, właściciel IT.
5. Ustawić Recurrence type na Recurring.
6. Wybrać dni od poniedziałku do piątku.
7. Ustawić Start time na 07:30, a Stop time na 18:00.
8. Pozostawić sobotę i niedzielę wyłączone.
9. W przypadku różnych godzin w poszczególne dni użyć Expand i sprawdzić każdy dzień oddzielnie.
10. Zapisać przyciskiem Save.

Zapisany harmonogram nie ma jeszcze wpływu na ruch. Sterowanie czasem odpowiedniej ścieżki zostaje włączone dopiero po przypisaniu harmonogramu do reguły lub zasady.

Przypisywanie harmonogramu do reguły zapory

Właściwe zezwolenie nadal stanowi zwykła reguła zapory. Artykuł Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall wyjaśnia współdziałanie kryteriów dopasowania, funkcji ochronnych i kolejności reguł.

Dla przykładu sieci gościnnej:

1. Otworzyć Rules and policies > Firewall rules.
2. Utworzyć regułę Guest_to_WAN_BusinessHours albo edytować istniejącą, wcześniej udokumentowaną regułę.
3. Ograniczyć Source zones i Source networks and devices do sieci gościnnej.
4. W polu During scheduled time wybrać Guest_BusinessHours.
5. Ustawić Destination zones na WAN i wykluczyć cele wewnętrzne.
6. Wybrać tylko wymagane Services.
7. Przypisać odpowiednie zasady internetowe, aplikacji i IPS.
8. Włączyć Log firewall traffic.
9. Sprawdzić pozycję reguły i zapisać.

Sophos Firewall sprawdza reguły zapory od góry do dołu. Jeśli zaplanowana reguła nie obowiązuje poza swoim harmonogramem, późniejsza, szersza reguła może zezwolić na ten sam ruch. Reguła Allow sterowana czasem wymaga więc wyraźnie oddzielonego dopasowania albo świadomie zaplanowanej późniejszej logiki blokowania. Rozwiązanie należy zweryfikować na podstawie rzeczywistego Firewall Rule ID, a nie tylko poprawnego otwarcia strony.

Jednorazowa reguła serwisowa

W przypadku pojedynczego okna dostępu usługodawcy należy zamiast tego wybrać One-time w sekcji Profiles > Schedule > Add. Datę rozpoczęcia, datę zakończenia i godziny należy przepisać z zatwierdzonego okna serwisowego. Następnie harmonogram jest przypisywany do wąskiej reguły zapory w polu During scheduled time.

Po zakończeniu przedziału reguła pozostaje jako obiekt konfiguracji, ale poza harmonogramem nie jest dopasowywana. W tickecie i uzgodnieniach z właścicielem należy więc również określić, czy po zakończeniu reguła zostanie wyłączona, usunięta czy użyta ponownie z nowym harmonogramem.

Reguła jednorazowa nie zastępuje wąskich kryteriów. W przykładzie zezwolenie zawiera wyłącznie potwierdzony adres źródłowy, host docelowy 10.20.30.40, wymaganą usługę HTTPS, rejestrowanie i prawidłową pozycję reguły. Szerokie źródło WAN lub Any jako usługa pozostają niepotrzebnym ryzykiem nawet w krótkim oknie.

Używanie harmonogramów w zasadach

Harmonogramy cykliczne mogą być także używane w innych obszarach:

• Web policy: w polu Constraints określa się, kiedy obowiązuje reguła zasady.
• Application policy: reguła filtra aplikacji może otrzymać harmonogram.
• Traffic shaping policy: reguła przepustowości jest stosowana tylko podczas wybranego harmonogramu.
• Access time policy: harmonogram cykliczny określa, kiedy Allow lub Deny dotyczy przypisanych użytkowników i grup.
• Rogue AP scan: skanowanie może być wykonywane w cyklicznych terminach.

Sterowanie czasem zasady i przypisanie zasady to osobne kroki. Zasada internetowa lub aplikacji działa dopiero za pośrednictwem odpowiedniej reguły zapory. Artykuł Konfiguracja i testowanie Application Control na Sophos Firewall szczegółowo opisuje kontrolę aplikacji, a Konfiguracja Web Protection za pomocą zasad internetowych na Sophos Firewall omawia logikę filtrowania stron.

Wiele warstw czasowych w tym samym połączeniu należy świadomie udokumentować. Harmonogram w regule zapory i inny harmonogram w zasadzie internetowej lub aplikacji mogą dawać technicznie różne wyniki: ścieżka sieciowa może pozostać otwarta, podczas gdy zmieni się tylko określona akcja internetowa lub aplikacyjna.

Niezawodne testowanie granic czasu

Zapisana konfiguracja nie jest jeszcze dowodem. Walidacja wykorzystuje nowe połączenie i te same wartości testowe przed przedziałem, w jego trakcie i po jego zakończeniu:

1. Udokumentować Current time i Time zone na zaporze.
2. Sprawdzić typ harmonogramu, dni tygodnia, godzinę rozpoczęcia i zakończenia.
3. Sprawdzić pozycję reguły i During scheduled time.
4. Krótko przed rozpoczęciem wygenerować zdefiniowany ruch testowy i zapisać oczekiwane zachowanie blokowania lub fallback.
5. Po rozpoczęciu otworzyć nowe połączenie.
6. W Log Viewer porównać źródło, cel, usługę, Firewall Rule ID, działanie i znacznik czasu.
7. Po zakończeniu otworzyć kolejne nowe połączenie i sprawdzić, która reguła teraz obowiązuje.
8. W przypadku zasad internetowych lub aplikacji sprawdzić także zasadę, użytkownika i działanie zasady.

Pełny przebieg z Log Viewer, Packet Capture i Rule ID opisano w artykule Prawidłowe testowanie reguły Sophos Firewall.

Sophos nie dokumentuje ogólnie, że każda istniejąca sesja jest natychmiast kończona po zakończeniu harmonogramu. W przypadku dostępu o znaczeniu krytycznym dla bezpieczeństwa należy zatem obserwować zarówno nowe połączenie po przekroczeniu granicy, jak i już trwającą sesję. Jeżeli istniejące sesje muszą zakończyć się natychmiast, bez rzeczywistego testu harmonogram nie może być uznany za jedyne zabezpieczenie.

Systematyczne zawężanie błędów

Reguła obowiązuje o niewłaściwej porze

Najpierw otworzyć Administration > Time i porównać Current time oraz Time zone z udokumentowanym czasem operacyjnym. Następnie sprawdzić dzień tygodnia, godzinę rozpoczęcia, godzinę zakończenia oraz ewentualne wartości dzienne ustawione za pomocą Expand. Strefa czasowa przeglądarki administratora nie zmienia czasu zapory.

Ruch działa poza przedziałem

W Log Viewer ustalić Firewall Rule ID, który faktycznie przetworzył ruch. Często ruch przejmuje późniejsza ogólna reguła Allow. W takim przypadku należy poprawić kolejność reguł i logikę dopasowania, a nie rozszerzać harmonogram. Jeśli brakuje odpowiedniego logu reguły, Packet Capture i niejawna reguła drop-all #0 pomagają zawęzić przyczynę.

One-time nie jest dostępny w zasadzie

Jest to udokumentowane ograniczenie produktu: harmonogramy One-time można przypisywać wyłącznie do reguł zapory. Zasady internetowe, aplikacji, traffic shaping i czasu dostępu wymagają harmonogramu cyklicznego.

Nie można usunąć harmonogramu

Używanego harmonogramu nie można usunąć bezpośrednio. Najpierw należy zidentyfikować wszystkie zależne reguły, zasady i skanowania. Następnie każdej zależności trzeba przypisać inny odpowiedni harmonogram albo usunąć ją w sposób kontrolowany. Dopiero potem można usunąć nieużywany harmonogram.

Zasada zmienia się, ale ścieżka sieciowa pozostaje otwarta

Harmonogram zasady kontroluje tylko odpowiednią regułę tej zasady. Jeśli cała ścieżka sieciowa ma być zamknięta poza przedziałem, również reguła zapory musi być ograniczona czasowo i przetestowana pod kątem późniejszych reguł fallback.

Planowanie zmian i wycofania

Przed zmianą należy udokumentować nazwę harmonogramu, typ, dni, godziny, strefę czasową, wszystkie zastosowania oraz pozycję objętych zmianą reguł zapory. Aby zapewnić bezpieczną drogę powrotną, należy ponownie przypisać poprzedni harmonogram, zamiast bez zastanowienia wybierać All the time.

Typowe wycofanie wygląda następująco:

1. Pozostawić otwartą istniejącą sesję administratora oraz alternatywny dostęp administracyjny.
2. Przypisać udokumentowany poprzedni harmonogram do odpowiedniej reguły lub zasady.
3. Potwierdzić, że pozycja i stan reguły pozostały bez zmian.
4. Przetestować za pomocą nowego połączenia i oczekiwanego Rule ID.
5. Usunąć nowy harmonogram dopiero wtedy, gdy nie istnieją już żadne zależności.
6. Zaktualizować ticket, właściciela i wynik testu.

W przypadku jednorazowego zezwolenia serwisowego planowane wycofanie należy umieścić w tickecie jeszcze przed aktywacją. Dzięki temu po terminie nie pozostanie nieaktywna, lecz nieudokumentowana reguła.

Często zadawane pytania