Skrypty na Sophos Firewall bez zadań cron: bezpieczne alternatywy
Administrator, który chce regularnie wykonywać polecenie na Sophos Firewall, szybko zaczyna szukać zadań cron, skryptów startowych lub trwałych plików powłoki. Publiczna dokumentacja administracyjna SFOS nie opisuje jednak ogólnego sposobu ich eksploatacji. Firewall jest urządzeniem zabezpieczającym i nie powinien pełnić roli serwera automatyzacji.
Do zmian konfiguracji lepiej wykorzystać XML API, Sophos Central lub natywne funkcje SFOS. Stany i błędy powinny być monitorowane przez systemy zewnętrzne za pośrednictwem Syslog, SNMP lub sFlow. Lokalne obejście oparte na skrypcie powłoki powinno znaleźć się na firewallu wyłącznie wtedy, gdy Sophos publicznie opisuje je dla konkretnego przypadku albo gdy towarzyszy mu Sophos Support lub Professional Services.
⚠️ Ważne: Kopia zapasowa konfiguracji nie stanowi dowodu, że samodzielnie utworzone pliki, mechanizmy startowe lub procesy działające w tle zostaną zapisane i będą ponownie dostępne po przywróceniu, przełączeniu awaryjnym HA lub aktualizacji firmware.
Szybka decyzja
Przed wyborem rozwiązania technicznego trzeba jasno określić, jakie zadanie ma zostać zautomatyzowane. Taka klasyfikacja zapobiega sytuacji, w której niewielki skrypt niepostrzeżenie staje się krytycznym elementem działania firewalla.
| Zadanie | Odpowiedni sposób realizacji |
|---|---|
| Powtarzalna zmiana konfiguracji | XML API wywoływane z kontrolowanego systemu automatyzacji |
| Ta sama polityka na wielu firewallach | Sophos Central Firewall Group |
| Regularna kopia zapasowa konfiguracji | Harmonogram w Backup & firmware > Backup & restore |
| Monitorowanie stanu, ruchu lub błędów | Syslog, SNMP, sFlow lub Sophos Central Reporting |
| Jednorazowa diagnostyka | WebAdmin, Device Console lub polecenie udokumentowane przez Sophos |
| Obejście specyficzne dla produktu | Dokładna instrukcja Sophos lub potwierdzone zgłoszenie do pomocy technicznej |
Jeżeli skrypt ma regularnie restartować usługi, usuwać pliki lub resetować połączenia, nie jest to rozwiązanie automatyzacyjne. Prawdopodobnie maskuje usterkę. W takiej sytuacji należy najpierw przeanalizować logi, miejsce na dysku, wersję firmware i konkretny objaw błędu.
Dlaczego lokalne skrypty są problematyczne
Skrypt powłoki może być technicznie niewielki, a mimo to utrudniać kontrolę nad eksploatacją. Działa poza standardową konfiguracją WebAdmin, często nie pozostawia wpisów w Audit Trail, a po aktualizacji może kolidować ze zmienionymi plikami, usługami lub uprawnieniami.
Szczególnie istotne są cztery rodzaje ryzyka:
- Kopia zapasowa i przywracanie: Sophos opisuje kopię zapasową jako zabezpieczenie konfiguracji firewalla. Nie ma ogólnej gwarancji przywrócenia własnych plików powłoki ani mechanizmów startowych.
- HA: Sophos synchronizuje konfigurację z Primary do Auxiliary. Nie można na tej podstawie zakładać, że dowolne lokalne pliki lub samodzielnie zbudowane procesy będą działać identycznie na obu węzłach.
- Firmware: Aktualizacja może zmienić wewnętrzne ścieżki, usługi lub zachowanie środowiska uruchomieniowego. Dlatego lokalną modyfikację trzeba ponownie ocenić po każdej aktualizacji.
- Wsparcie: Sophos wspiera oficjalne API oraz niezmodyfikowane skrypty Sophos. W przypadku samodzielnie opracowanych integracji Sophos odsyła do partnerów lub Professional Services.
Do tego dochodzą dane poufne zapisane jawnym tekstem, niekontrolowane ilości logów, nieskończone pętle oraz diagnostyka, podczas której nikt nie ma już pewności, czy dane zachowanie powoduje SFOS, czy lokalne obejście.
Obsługiwane alternatywy
Wykorzystanie natywnej funkcji SFOS
Najpierw należy sprawdzić, czy SFOS wykonuje już dane zadanie samodzielnie. Zaplanowane kopie zapasowe, powiadomienia, routing, SD-WAN, monitoring i centralne rejestrowanie zdarzeń należy konfigurować w przeznaczonych do tego menu. Powtarzalna kopia zapasowa nie wymaga na przykład skryptu powłoki; harmonogram znajduje się w Backup & firmware > Backup & restore.
W przypadku routingu lub ruchu systemowego często wystarczy prawidłowo skonfigurowana polityka zamiast polecenia wykonywanego po każdym restarcie. Artykuł Routing SD-WAN dla pakietów odpowiedzi i ruchu systemowego przedstawia obsługiwany sposób postępowania.
Zarządzanie wieloma firewallami przez Sophos Central
Jeżeli wiele firewalli ma otrzymać tę samą politykę, Firewall Group w Sophos Central może być lepszym rozwiązaniem niż własny skrypt. Ścieżka to My Products > Firewall Management > Firewalls. Polityki grupowe są stosowane do przypisanych firewalli, a ich stan jest widoczny w Tasks Queue.
Grupy Central nie są uniwersalną funkcją kopiowania. Reguły lokalne i zarządzane centralnie mogą wzajemnie wpływać na swoją kolejność, a nie każdą konfigurację da się odwzorować w dowolnej strukturze grup. Dlatego najpierw należy przeprowadzić test z grupą testową, a następnie sprawdzić Tasks Queue oraz faktycznie zastosowane reguły.
Zewnętrzne wykorzystanie XML API
Do powtarzalnych zmian obiektów lub polityk przeznaczone jest XML API. Automatyzacja powinna działać w zarządzanym systemie, w którym można kontrolować kod, dane poufne, logi, harmonogram i sposób wycofania zmian.
Firewall należy przygotować w następujący sposób:
- W Profiles > Device access utwórz profil administratora tylko z rzeczywiście potrzebnymi uprawnieniami i zapisz go przyciskiem Save.
- W Authentication > Users kliknij Add, ustaw User type na Administrator, wybierz nowy profil, świadomie ogranicz Login restriction for device access i zapisz ustawienia przyciskiem Save.
- W Hosts and services > IP host dodaj system automatyzacji jako precyzyjnie ograniczony obiekt hosta.
- W Administration > API access wybierz API access.
- W Allowed IP hosts wybierz wyłącznie przygotowany obiekt hosta, dodaj go przyciskiem Add i zapisz ustawienia przyciskiem Apply. SFOS zezwala w tym miejscu na maksymalnie 64 wpisy.
- W Administration > Device access sprawdź, czy HTTPS jest dozwolony z wymaganej strefy. W przypadku dostępu z WAN lepiej zastosować ściśle ograniczoną Local service ACL exception rule niż ogólnie otwierać HTTPS dla WAN.
API access jest domyślnie wyłączony. Po aktualizacji do SFOS 22.0 wcześniej dozwolone adresy IP zostają przekształcone w obiekty hostów z prefiksem apiconfig; te starsze zezwolenia należy uwzględnić podczas kolejnego przeglądu dostępu.
Artykuł Zabezpieczanie dostępu do XML API w Sophos Firewall szczegółowo omawia konto serwisowe, zachowanie MFA, port administracyjny, Local Service ACL i ochronę danych poufnych. Przy przygotowywaniu lub porównywaniu zmian konfiguracji pomocny może być również Sophos Firewall Config Studio.
⚠️ API nie jest automatycznie bezpieczne: Ogranicz źródłowy adres IP, nie używaj osobistego konta z pełnymi uprawnieniami administratora, nie zapisuj danych poufnych w repozytorium, zgłoszeniu ani historii powłoki oraz najpierw testuj operacje zapisu w środowisku testowym.
Monitoring poza firewallem
System monitoringu powinien obserwować firewall z zewnątrz. W przeciwnym razie lokalnego procesu może zabraknąć dokładnie wtedy, gdy sam firewall ulegnie awarii. W zależności od celu odpowiednie będą monitorowanie sprzętu przez SNMP, monitorowanie sFlow lub Central Firewall Reporting.
Do długoterminowej analizy zdarzeń i bezpieczeństwa lepiej nadaje się zewnętrzny odbiornik Syslog lub SIEM niż dodatkowe lokalne pliki dziennika. Dzięki temu dane pozostają dostępne również po restarcie, awarii lub wymianie firewalla.
Kiedy lokalne obejście może być uzasadnione
Niektóre zgłoszenia do pomocy technicznej lub wdrożenia chmurowe wymagają ściśle ograniczonego obejścia. Decydujące znaczenie ma nie to, czy polecenie działa technicznie, lecz to, czy dla dokładnie tego scenariusza istnieje aktualna instrukcja Sophos albo potwierdzone zalecenie pomocy technicznej.
Przed wdrożeniem trzeba upewnić się, że wersja, platforma, tryb HA i sposób wycofania odpowiadają instrukcji. Skrypt pochodzący ze starego wpisu w Community, innego modelu urządzenia lub wcześniejszej wersji SFOS nie stanowi wiarygodnej zgody na zastosowanie go we własnym środowisku.
Jeżeli istnieje tylko samodzielnie opracowana koncepcja rozwiązania, należy najpierw omówić ją z partnerem Sophos lub Professional Services. Ogólna instrukcja dodawania własnych skryptów startowych byłaby w tym przypadku bardziej niebezpieczna niż pomocna.
Bezpieczne zastępowanie istniejącego skryptu
Nie należy od razu usuwać istniejącego skryptu. Najpierw trzeba ustalić, w jakim stopniu działanie środowiska jest od niego zależne.
- Wstrzymaj zmiany: Na razie nie modyfikuj skryptu, mechanizmu startowego ani firewalla, którego dotyczą.
- Określ cel: Udokumentuj objaw, wyzwalacz, oczekiwany wynik, ścieżkę, użytkownika, harmonogram, dane poufne i osobę odpowiedzialną.
- Obserwuj działanie: Zapisz logi, stan procesu, utworzone pliki oraz trasy, usługi lub interfejsy, na które skrypt wpływa. W przypadku HA sprawdź osobno oba węzły.
- Wybierz docelowy sposób: Przypisz funkcję do natywnego ustawienia SFOS, Central, XML API lub zewnętrznego monitoringu.
- Przetestuj rozwiązanie zastępcze: Sprawdź nowy przebieg poza produkcyjnym firewallem i zarejestruj powodzenie, błędy oraz sposób wycofania zmian.
- Przeprowadź kontrolowaną migrację: W oknie serwisowym aktywuj rozwiązanie zastępcze, wyłącz lokalny skrypt i wykonaj test funkcjonalny.
- Zaplanuj kontrolę: Sprawdź ponownie po restarcie, przełączeniu awaryjnym i następnej aktualizacji firmware, o ile zdarzenia te są istotne dla danej funkcji.
Przed zmianą należy utworzyć aktualną kopię zapasową. Artykuł Tworzenie lub przywracanie kopii zapasowej Sophos Firewall omawia Secure Storage Master Key, przywracanie i kompatybilność. Kopia zapasowa chroni udokumentowaną konfigurację, ale nie zastępuje osobnej inwentaryzacji lokalnych modyfikacji.
Walidacja i wycofywanie zmian
Pomyślna odpowiedź API lub działający proces nie dowodzą jeszcze, że zadanie zostało wykonane prawidłowo. Po migracji trzeba sprawdzić dokładnie ten rezultat, który wcześniej zależał od skryptu: czy reguła istnieje, trasa jest aktywna, kopia zapasowa została utworzona, cel jest osiągalny albo alarm dotarł do systemu monitoringu.
W przypadku zmian przez API należy dodatkowo sprawdzić Audit Trail i obiekty, których dotyczą. Jeżeli zmiana wpływa na ruch, weryfikacja powinna obejmować Log Viewer, Rule ID, NAT Rule ID, Policy Test lub Packet Capture. Zmiany w Central należy sprawdzić w Tasks Queue, a następnie bezpośrednio na jednym z firewalli, których dotyczą.
Wycofanie zmian nie polega na pochopnym ponownym włączeniu starego skryptu. Najpierw trzeba wycofać nową zmianę i przywrócić udokumentowany stan początkowy. Stare obejście można tymczasowo ponownie aktywować tylko wtedy, gdy zostało świadomie sprawdzone jako opcja awaryjna.
Zalecenia eksploatacyjne
Lokalne skrypty powinny być opisane w dokumentacji eksploatacyjnej jako wyjątek obowiązujący przez ograniczony czas, a nie jako standardowa funkcja firewalla. Każdy wyjątek wymaga właściciela, terminu przeglądu, przetestowanego sposobu wycofania oraz jasnego wskazania obsługiwanych wersji Sophos.
W przypadku nowych wymagań należy zachować następującą kolejność: natywna funkcja SFOS, Sophos Central, zewnętrzna automatyzacja przez XML API, zewnętrzny monitoring, a dopiero potem szczególny przypadek potwierdzony przez Sophos. Dzięki temu zmiany pozostają identyfikowalne, a HA i przywracanie są łatwiejsze do zaplanowania. Firewall pozostaje też bliżej wspieranego stanu produktu.