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 filtrowania stron WWW, 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.

Właściwy punkt kontroli zależy od celu:

• Jeśli cała ścieżka sieciowa ma być otwarta tylko w określonych godzinach, harmonogram należy umieścić w regule zapory.
• Jeśli w otwartej ścieżce ma się zmieniać tylko działanie związane z filtrowaniem stron WWW lub aplikacji, harmonogram należy przypisać do odpowiedniej reguły zasady.
• Jeśli dostęp użytkownika lub grupy do Internetu ma być dozwolony albo blokowany zależnie od czasu, zwykle czytelniejsza jest zasada czasu dostępu.
• Harmonogram One-time można przypisać wyłącznie do reguły zapory.

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 filtrowania stron WWW, 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. Strefa i sieć gościnna są oddzielnymi polami dopasowania:

• Recurring: Guest_BusinessHours, od poniedziałku do piątku, od 07:30 do 18:00
• Reguła zapory: Guest_to_WAN_BusinessHours
• Source zones: własna strefa gościnna, w przykładzie Guest
• Source networks and devices: net_Guest_10.50.0.0_24
• Destination zones: WAN
• Destination networks: 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. Przykład serwisowy zakłada już działającą i przetestowaną ścieżkę przychodzącą. Publikacja serwera w Internecie wymaga poprawnego DNAT i powiązanej reguły niezależnie od harmonogramu; patrz Publikowanie serwera przez DNAT lub PAT.

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 i wybrać IPv4.
2. Wybrać Add firewall rule > New firewall rule albo edytować udokumentowaną regułę.
3. Ustawić Action na Accept oraz ograniczyć Source zones i Source networks and devices do sieci gościnnej.
4. Ustawić Destination zones na WAN, a Destination networks na Any; w razie potrzeby użyć węższego celu.
5. Wybrać tylko Services HTTP i HTTPS.
6. W polu During scheduled time wybrać Guest_BusinessHours.
7. Przypisać odpowiednie zasady filtrowania stron WWW, aplikacji i IPS.
8. Włączyć Log firewall traffic.
9. Sprawdzić pozycję reguły i zapisać.

Prywatna sieć gościnna wymaga odpowiedniej reguły SNAT, chyba że urządzenie nadrzędne routuje prywatne adresy źródłowe. Reguły NAT również działają według pierwszego dopasowania i trzeba je sprawdzić osobno; harmonogram nie naprawi błędnego dopasowania NAT. Przykład zezwala tylko na ruch HTTP i HTTPS; rozwiązywanie nazw DNS potrzebne do dostępu po nazwie musi działać osobną, dozwoloną i przetestowaną ścieżką.

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

Dla pojedynczego dostępu usługodawcy należy utworzyć osobny harmonogram One-time:

1. Otworzyć Profiles > Schedule > Add.
2. Ustawić Name na Vendor_Maintenance_2026-09-15, a w Description podać ticket, właściciela i cel.
3. Ustawić Recurrence type na One-time.
4. Ustawić datę rozpoczęcia i zakończenia na 15 września 2026.
5. Ustawić Start time na 22:00, a Stop time na 23:30.
6. Ponownie porównać wartości z zatwierdzonym oknem i strefą czasową zapory, a następnie zapisać za pomocą Save.
7. Przypisać harmonogram w During scheduled time do przetestowanej, ściśle ograniczonej reguły serwisowej.

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 DNAT reguła zawiera Source zones WAN, potwierdzony adres w Source networks and devices, wewnętrzną strefę DMZ w Destination zones, Destination networks 10.20.30.40, usługę HTTPS, rejestrowanie i właściwą pozycję. Reguła sprawdza przetłumaczony cel wewnętrzny po DNAT. Any jako sieć źródłowa lub usługa pozostaje niepotrzebnie ryzykowne nawet w krótkim przedziale czasu.

Używanie harmonogramów w zasadach

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

• Web policy: regułę zasady filtrowania stron WWW można ograniczyć czasowo.
• Application policy: reguła filtra aplikacji może otrzymać harmonogram.
• Traffic shaping policy: harmonogram dodaje się w System services > Traffic shaping > Add > Add schedule; reguła może działać przez użytkownika, regułę zapory, kategorię internetową lub wpis aplikacji.
• Access time policy: harmonogram cykliczny określa, kiedy Allow lub Deny dotyczy przypisanych użytkowników i grup.
• Rogue AP scan: na urządzeniu z wbudowanym Wi-Fi wybrać Wireless > Rogue AP scan > General settings > Schedule system-triggered scan at. Skan na krótko rozłącza klientów, co trzeba uwzględnić w oknie.

Sterowanie czasem zasady i przypisanie zasady to osobne kroki. Zasada filtrowania stron WWW 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 filtrowania stron WWW 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 filtrowania stron WWW lub aplikacji mogą dawać technicznie różne wyniki: ścieżka sieciowa może pozostać otwarta, podczas gdy zmieni się tylko określone działanie związane z filtrowaniem stron WWW lub aplikacji.

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 filtrowania stron WWW 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 pracy. Następnie sprawdzić dzień tygodnia, godzinę rozpoczęcia, godzinę zakończenia oraz ewentualne wartości dla poszczególnych dni ustawione za pomocą Expand. Po Sync now widok Current time nie odświeża się od razu; przed uznaniem, że czas nadal jest nieprawidłowy, przeładować WebAdmin. Decydują czas i strefa wyświetlane przez zaporę.

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 filtrowania stron WWW, 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ą udokumentować nazwę harmonogramu, typ, dni, godziny, strefę czasową, wszystkie zastosowania i pozycje reguł. All the time nie jest uniwersalnym wycofaniem, bo usuwa ograniczenie czasowe. Przy zmianie samego harmonogramu przywrócić poprzedni; nową regułę wyłączyć lub usunąć, a w istniejącej przywrócić Action, pola dopasowania, zasady, rejestrowanie i pozycję. Zmienione DNAT lub SNAT oraz ich pozycje także podlegają wycofaniu.

Typowe wycofanie wygląda następująco:

1. Pozostawić otwartą istniejącą sesję administratora oraz alternatywny dostęp administracyjny.
2. Przywrócić poprzedni harmonogram, wyłączyć nową regułę albo odtworzyć wszystkie zmienione pola.
3. Porównać powiązane reguły NAT, pozycję i stan z udokumentowanymi wartościami.
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