Przejdz do tresci
Avanet

Skrypty Sophos Firewall bez Cronjob: Ryzyka i Alternatywy

Sophos Firewall

Na Sophos Firewall w szczególnych przypadkach lokalne skrypty powłoki mogą wydawać się kuszące: powtarzająca się kontrola, Heartbeat, obejście po ponownym uruchomieniu lub mała zmiana sieci, która ma się automatycznie wydarzyć. Właśnie w tym miejscu należy być bardzo ostrożnym. Sophos Firewall to urządzenie zabezpieczające, a nie ogólny serwer automatyzacji.

Trwałe lokalne skrypty, zmienione procedury startowe lub samodzielnie zbudowane procesy w tle mogą utrudniać aktualizacje, zachowanie HA, przypadki wsparcia, bezpieczeństwo i rozwiązywanie problemów. W wielu przypadkach nie chodzi o to, jak zastąpić Cronjob, ale jaka wspierana lub lepiej kontrolowana alternatywa rozwiązuje właściwy problem.

⚠️ Uwaga: Zmiany lokalnych skryptów powłoki lub startowych na Sophos Firewall nie powinny być stosowane jako standard operacyjny. Przed każdym szczególnym przypadkiem potrzebne są kopia zapasowa, test, plan wycofania, okno konserwacyjne, jasna odpowiedzialność i ocena, czy istnieje wspierana droga.

Szybka decyzja

Jeśli proponowany jest lokalny skrypt, najpierw należy określić rzeczywiste zadanie. Następnie można zazwyczaj szybko ustalić, czy firewall jest właściwym miejscem wykonania.

  • Czy konfiguracja ma być regularnie zmieniana?: Skrypt zmieniłby obiekty firewalla, reguły, trasy lub usługi. Sprawdź zewnętrzną automatyzację przez XML API lub Sophos Central.
  • Czy stan ma być monitorowany?: Skrypt sprawdza interfejs, usługę, VPN, pamięć lub dostępność. Użyj monitoringu zewnętrznego, SNMP, sFlow, Central Reporting lub Syslog.
  • Czy błąd ma być automatycznie ukryty?: Skrypt ponownie uruchamia usługi, usuwa pliki lub resetuje połączenia. Analizuj przyczynę, zabezpiecz logi i sprawdź przypadek wsparcia lub wersję firmware.
  • Czy nieobsługiwane zachowanie ma być trwale wymuszone?: Zmiana ingeruje w logikę startową, routing, przetwarzanie pakietów lub lokalne pliki. Zmień projekt lub użyj wspieranej funkcji.

Jeśli żadna z tych pytań nie jest jasno odpowiedziana, obejście nie jest jeszcze gotowe do produkcyjnego firewalla. Wtedy najpierw należy dokładniej opisać problem: symptom, wyzwalacz, dotknięta wersja, pożądany wynik i akceptowalna droga operacyjna.

Dlaczego lokalne skrypty są problematyczne

Lokalny skrypt może wydawać się mały, ale w środowisku firewalla szybko może stać się krytyczny dla operacji. Firewall przetwarza ruch produkcyjny, VPN, uwierzytelnianie, NAT, logowanie i funkcje bezpieczeństwa. Błędny proces w tle lub niejasna zmiana w zachowaniu startowym może mieć znacznie większe skutki niż na normalnym systemie Linux.

Typowe ryzyka:

  • Wsparcie: Samodzielnie zmienione procedury startowe są trudne do zrozumienia w przypadkach wsparcia.
  • Aktualizacje firmware: Aktualizacje mogą zmieniać pliki, usługi, ścieżki lub zachowanie. Skrypt może działać inaczej lub wcale.
  • HA-Cluster: Zmiany muszą być zrozumiane dla każdego węzła. Po przełączeniu awaryjnym lub zmianie ról skrypt może być brakujący lub działać podwójnie.
  • Bezpieczeństwo: Skrypty często zawierają dane uwierzytelniające, URL-e lub logikę wewnętrzną, które nie są odpowiednio chronione i udokumentowane.
  • Wydajność i pamięć: Nieskończone pętle, wyjścia logów lub częste wywołania sieciowe mogą obciążać CPU, pamięć lub partycje.
  • Rozwiązywanie problemów: Skrypt może maskować objawy. Wtedy rzeczywista przyczyna nie zostaje usunięta.

Jeśli już występują problemy z pamięcią, raportowaniem lub logami, najpierw należy sprawdzić przyczynę. Do tego pasują Czyszczenie pamięci i raportów Sophos Firewall, Rozwiązywanie problemów z usługami i logami Sophos Firewall i Zabezpieczanie logów Sophos Firewall do wsparcia i analizy.

Najpierw sprawdź odpowiednią alternatywę

Wiele zadań, dla których wcześniej budowano lokalne skrypty, można dziś rozwiązać w sposób bardziej elegancki za pomocą dostępnych funkcji, zewnętrznej automatyzacji lub monitoringu.

Najważniejsza zasada: Automatyzacja powinna działać możliwie poza firewallem. Wtedy wersjonowanie, sekrety, logowanie, monitoring, wycofanie i odpowiedzialności są lepiej kontrolowane.

Kiedy w ogóle dyskutować o lokalnym skrypcie

Lokalny skrypt to co najwyżej szczególny przypadek. Powinien być dyskutowany tylko wtedy, gdy konkretnego problemu nie można rozwiązać za pomocą WebAdmin, Device Console, XML API, Central, Syslog, monitoringu lub innej wspieranej funkcji.

Lokalne podejście może być sensowne tylko wtedy, gdy wszystkie punkty są spełnione:

  • Cel jest ściśle ograniczony i udokumentowany.
  • Nie jest to trwałe zastępstwo dla brakującej funkcji operacyjnej.
  • Zmiana została przetestowana w środowisku testowym.
  • Istnieje pełna kopia zapasowa i jasna droga wycofania.
  • Wpływ na HA, aktualizacje firmware i wsparcie został oceniony.
  • Istnieje odpowiedzialna osoba, która sprawdza skrypt po aktualizacjach i przełączeniach awaryjnych.

Jeśli te punkty nie są spełnione, nie należy budować lokalnego obejścia. Lepiej jest wtedy zmienić rzeczywisty projekt lub zautomatyzować zadanie zewnętrznie.

Minimalne wymagania przed szczególnym przypadkiem

Przed szczególnym przypadkiem nie należy eksperymentować bezpośrednio na produkcyjnym firewallu. Najpierw zmiana jest traktowana jak mała zmiana.

Kopia zapasowa i przywracanie

Przed zmianą musi być dostępna aktualna kopia zapasowa. Dodatkowo powinno być jasne, gdzie znajduje się Secure Storage Master Key i czy przywracanie na sprzęcie zastępczym, wirtualnej aplikacji lub środowisku HA zostało realistycznie przetestowane.

Dla krytycznych zmian sama kopia zapasowa konfiguracji nie zawsze wystarcza. Jeśli zmiana dotyczy lokalnych plików lub procesów, musi być udokumentowane, co zostało zmienione poza normalną konfiguracją.

HA i przełączenie awaryjne

W przypadku klastrów HA nie wystarczy rozważać tylko aktywnego firewalla. Trzeba wiedzieć:

  • Na którym węźle istnieje zmiana?
  • Co się dzieje po przełączeniu awaryjnym?
  • Czy zmiana działa potem wcale, raz czy podwójnie?
  • Czy jest traktowana jednakowo na obu węzłach podczas aktualizacji firmware?

Właśnie dlatego lokalne skrypty w środowiskach HA są szczególnie ryzykowne.

Logowanie i kontrola

Szczególny przypadek bez kontroli to nie jest czysta operacja. Musi być widoczne, czy automatyzacja działa, zawodzi czy powoduje nieoczekiwane skutki uboczne. Do tego potrzebne są cel logowania, monitoring i prosta procedura kontrolna po ponownych uruchomieniach, aktualizacjach i przełączeniach awaryjnych.

Jeśli do kontroli potrzebne jest SSH lub Advanced Shell, dostęp powinien być wcześniej odpowiednio zabezpieczony. Podstawy znajdują się w Łączenie z Sophos Firewall przez SSH i Rozwiązywanie problemów z CLI Sophos Firewall: ważne polecenia.

Czego unikać

Niektóre wzorce powodują w praktyce więcej problemów niż korzyści.

  • Nieautoryzowane ponowne uruchomienia: Firewall nie powinien być regularnie ponownie uruchamiany, aby ukryć objawy. Należy zawęzić przyczynę.
  • Trwałe pętle w tle: Nieskończone pętle mogą obciążać CPU, pamięć, sieć lub logi.
  • Trwała logika startowa bez dokumentacji: Po aktualizacjach, przywracaniu lub przełączeniu awaryjnym nie jest jasne, jaki stan obowiązuje.
  • Bezpośrednia manipulacja pakietami lub routingiem przez powłokę: Jeśli dotyczy to routingu, SD-WAN, IPsec, NAT lub MSS, najpierw należy sprawdzić wspierane funkcje firewalla.
  • Sekrety w postaci jawnej: Dane uwierzytelniające, tokeny lub URL-e nie powinny być niekontrolowane w lokalnych skryptach.
  • Obejścia bez właściciela: Jeśli nikt nie jest odpowiedzialny za przegląd i usunięcie, obejście staje się przestarzałe.

W przypadku problemów z IPsec, routingiem lub MSS zazwyczaj inne artykuły są lepszym punktem wyjścia: Rozwiązywanie problemów z IPsec VPN Sophos Firewall, Sprawdzanie MTU i MSS przy problemach z VPN na Sophos Firewall, Dostosowanie priorytetu routingu na Sophos Firewall i SD-WAN Routing dla pakietów odpowiedzi i ruchu systemowego.

Jeśli skrypt już istnieje

Istniejących lokalnych skryptów nie należy usuwać ani przejmować bez zastanowienia. Najpierw potrzebna jest inwentaryzacja.

Sprawdź:

  • Jaki problem miał pierwotnie rozwiązać skrypt?
  • Kto go stworzył i kto jest dziś odpowiedzialny?
  • Gdzie się znajduje i jak jest uruchamiany?
  • Czy działa po ponownym uruchomieniu, przełączeniu awaryjnym HA i aktualizacji firmware?
  • Czy zawiera dane uwierzytelniające, tokeny, wewnętrzne URL-e lub twarde adresy IP?
  • Czy istnieją logi lub monitoring?
  • Czy istnieje wspierana alternatywa, na którą można przejść?

Następnie decyduje się, czy skrypt zostanie usunięty, zastąpiony, udokumentowany lub przeniesiony do zewnętrznej automatyzacji. Przed każdą zmianą należy utworzyć kopię zapasową i zaplanować okno konserwacyjne.

Szablon dokumentacji dla szczególnych przypadków

Jeśli lokalny szczególny przypadek mimo ryzyk pozostaje tymczasowo, powinien być tak udokumentowany, aby inna osoba zrozumiała go po aktualizacji, przełączeniu awaryjnym lub przypadku wsparcia.

  • Cel: Jaki konkretny problem jest rozwiązywany?
  • Miejsce: Plik, ścieżka, użytkownik, mechanizm startowy i dotknięty węzeł HA
  • Wyzwalacz: Kiedy skrypt działa: ręcznie, przy starcie, cyklicznie czy przez usługę?
  • Zmiana: Jakie polecenia, pliki, usługi, trasy lub interfejsy są wpływane?
  • Ryzyko: Co się dzieje w przypadku błędu, ponownego uruchomienia, aktualizacji firmware, przywracania lub przełączenia awaryjnego?
  • Kontrola: Gdzie widać sukces, błędy i skutki uboczne?
  • Wycofanie: Jak całkowicie przywrócić stan?
  • Właściciel: Kto sprawdza szczególny przypadek po aktualizacjach i kiedy zostanie usunięty?

Ta dokumentacja nie powinna znajdować się tylko w osobistym systemie notatek. W podręczniku operacyjnym lub klienckim zapobiega, aby późniejszy przypadek wsparcia nie zaczynał się od poszukiwań na firewallu.

Lista kontrolna

  • Cel skryptu jest konkretnie udokumentowany.
  • Sprawdzone zostały wspierane alternatywy, takie jak WebAdmin, XML API, Central, Syslog, SNMP, sFlow lub Config Studio.
  • Istnieje kopia zapasowa, Secure Storage Master Key i droga wycofania.
  • Zachowanie HA jest ocenione.
  • Zaplanowano środowisko testowe lub okno konserwacyjne.
  • Sekrety nie są przechowywane lokalnie w postaci jawnej.
  • Zdefiniowano logowanie i monitoring.
  • Ustalono odpowiedzialną osobę i termin przeglądu.
  • Po aktualizacjach firmware szczególny przypadek jest świadomie ponownie sprawdzany.

FAQ

Czy można używać Cronjobs na Sophos Firewall?

Nie powinno się opierać modelu operacyjnego na utrzymywaniu lokalnych Cronjobs lub obejść skryptów startowych na firewallu. Dla powtarzających się zadań zewnętrzna automatyzacja przez wspierane interfejsy jest zazwyczaj bardziej stabilna, zrozumiała i lepiej utrzymywalna.

Czy skrypt Heartbeat na firewallu ma sens?

Zazwyczaj nie. System monitoringu powinien monitorować firewall z zewnątrz, a nie być zależny od samego firewalla. W przeciwnym razie lokalny proces może ukrywać problem lub zawieść dokładnie wtedy, gdy jest potrzebny.

Czy powinno się regularnie automatycznie restartować Sophos Firewall?

Nie. Powtarzające się restarty są oznaką, że problem nie został właściwie rozwiązany. Lepiej jest przeanalizować usługi, logi, pamięć, wersję firmware i dotknięte funkcje.

Co jest bezpieczniejsze dla powtarzających się zmian?

Dla powtarzających się zmian zewnętrzna automatyzacja, XML API, Sophos Central, udokumentowane procesy zmiany lub specjalistyczne narzędzia do monitoringu i konfiguracji są lepsze niż lokalne skrypty na firewallu.

Co jest szczególnie ważne w klastrach HA?

W przypadku HA musi być jasne, na którym węźle istnieje lokalna zmiana i co się dzieje po przełączeniu awaryjnym, aktualizacji firmware lub przywracaniu. Jeśli nie jest to jednoznacznie udokumentowane i przetestowane, nie powinno się używać lokalnego szczególnego przypadku w produkcji.