Zabezpieczanie dostępu do XML API w Sophos Firewall

XML API w Sophos Firewall jest przydatne do automatyzacji, monitorowania, tworzenia kopii zapasowych, analiz i integracji. Z tego powodu stanowi również część powierzchni ataku zarządzania. Pozwalając na dostęp do API, umożliwiasz systemowi odczyt danych konfiguracyjnych lub, w zależności od uprawnień, wprowadzanie zmian.

Dostęp do API nie powinien być szeroko dozwolony z sieci wewnętrznych lub dowolnych źródeł. Lepszym rozwiązaniem jest mały, udokumentowany zestaw sieci zarządzania, hostów automatyzacji lub stałych dostępów partnerskich.

Od wersji SFOS 22 Sophos rozszerzył kontrolę dostępu do API. Ustawienia dostępu do API znajdują się w sekcji Administration, a dozwolone źródła mogą być definiowane jako hosty IP. Dzięki temu można dokładnie modelować nie tylko pojedyncze adresy IP, ale także zakresy IP i sieci.

Kiedy dostęp do XML API jest sensowny

XML API nie jest standardowym dostępem do codziennej pracy administratora. Jest przydatne, gdy za nim stoi konkretny proces techniczny.

Typowe przypadki użycia:

• Monitorowanie lub inwentaryzacja.
• Zautomatyzowane kontrole konfiguracji.
• Procesy tworzenia kopii zapasowych lub dokumentacji.
• Platformy MSP lub integracyjne.
• Skrypty do powtarzających się zadań administracyjnych.
• Przygotowane zmiany z narzędzi takich jak Sophos Firewall Config Studio.

Jeśli proces może obyć się bez API, dostęp do API nie powinien być pozostawiony aktywny na wszelki wypadek. Każdy dodatkowy interfejs wymaga właściciela, źródła, koncepcji dostępu i kontroli.

Co zmieniło się w SFOS 22

W SFOS 22 kontrola dostępu do XML API stała się znacznie łatwiejsza w obsłudze:

• Ustawienia dostępu do API zostały przeniesione do menu Administration.
• Dostęp do API można ograniczyć do hostów IP.
• Jako źródła mogą być używane adresy IP, zakresy IP i sieci.
• Można zezwolić na maksymalnie 64 hosty IP.
• Podczas aktualizacji dotychczas dozwolone adresy IP są automatycznie przekształcane w obiekty hostów IP.
• Migrowane obiekty otrzymują prefiks apiconfig.

Jest to pomocne w działaniu, ponieważ źródła API nie muszą być już utrzymywane jako luźne pojedyncze adresy. Można dokładnie nazwać sieć zarządzania, host automatyzacji lub dedykowaną grupę hostów i później rozpoznać je w przeglądach.

Zasada podstawowa: zezwalaj na API tylko z określonych źródeł

Dostęp do API powinien być traktowany według tej samej zasady co WebAdmin lub SSH: tak wąsko, jak to możliwe, tak szeroko, jak to konieczne.

Sensowne źródła to na przykład:

• dedykowany serwer automatyzacji,
• system monitorowania,
• host zarządzania konfiguracją,
• wewnętrzna sieć zarządzania,
• sieć VPN lub administracyjna,
• jasno określony adres źródłowy partnera lub MSP.

Nie są sensowne:

• całe sieci klienckie,
• sieci gościnne lub IoT,
• Any,
• niejasne “całkowite udostępnienie sieci serwerowej”,
• tymczasowe adresy IP testowe, które później zostaną zapomniane.

Jeśli zewnętrzni dostawcy usług potrzebują dostępu do API, źródło powinno być zdefiniowane tak szczegółowo, jak to możliwe. Dodatkowo powinno być udokumentowane, do czego dostęp jest używany i kiedy zostanie usunięty.

Zalecany przebieg

Dokładna ścieżka UI może się nieznacznie różnić w zależności od wersji SFOS. W SFOS 22 konfiguracja API znajduje się w sekcji Administration.

Praktyczny przebieg:

1. Sprawdź, który system potrzebuje dostępu do API.
2. Utwórz dla tego systemu jednoznaczny obiekt hosta IP.
3. Jeśli potrzebnych jest kilka źródeł, dokładnie nazwij hosty IP lub sieci.
4. Zezwól na dostęp do API tylko dla tych obiektów.
5. Nie wpisuj szerokich sieci klienckich lub serwerowych.
6. Przetestuj dostęp za pomocą odpowiedniego narzędzia.
7. Usuń źródła, które nie są już potrzebne.
8. Zmianę udokumentuj w procesie zmiany.

W istniejących instalacjach po aktualizacji do SFOS 22 należy dodatkowo poszukać obiektów z prefiksem apiconfig. Obiekty te zostały utworzone z wcześniejszych wpisów zezwalających na API i powinny zostać sprawdzone, nazwane lub oczyszczone.

Dostęp do API i uprawnienia użytkowników

Sama źródłowa IP nie jest pełnym koncepcją bezpieczeństwa. Ograniczenie to jedynie zmniejsza liczbę miejsc, z których API jest dostępne. Dodatkowo musi być jasne, z jakiego konta odbywa się dostęp do API i jakie uprawnienia ma to konto.

Dla środowisk produkcyjnych należy sprawdzić:

• Czy używane jest osobne konto API lub serwisowe?
• Czy konto ma tylko potrzebne uprawnienia?
• Czy jest jasno udokumentowane, która osoba lub zespół jest odpowiedzialny za konto?
• Czy hasło lub sekret są bezpiecznie przechowywane?
• Czy dostęp jest usuwany, gdy integracja nie jest już używana?
• Czy zmiany są śledzone w dziennikach audytu?

Wspólne konta administratorów są problematyczne dla procesów API. Jeśli wiele systemów lub osób używa tego samego konta, śledzenie staje się trudniejsze. Dla analiz zmian istotne jest sprawdzenie dzienników śladu audytu Sophos Firewall.

MFA i użytkownicy API po SFOS 22

MFA jest ważne dla interaktywnych dostępów administratorów. Dla procesów API i automatyzacji trzeba jednak świadomie zaplanować, jak ma działać uwierzytelnianie. Skrypt, narzędzie monitorujące lub system integracyjny nie mogą łatwo wprowadzić kodu OTP, jeśli używany użytkownik wymusza MFA.

Na liście znanych problemów jest udokumentowany przypadek szczególny SFOS 22: Po aktualizacji zmiany konfiguracyjne oparte na API mogą się nie powieść dla migrowanych użytkowników, jeśli MFA jest aktywne i nie jest przekazywany token jednorazowy. Użytkownicy niemigrowani mogą zachowywać się inaczej w niektórych przypadkach. Dla działania ważne jest, aby nie robić z tego nieczystego “MFA wszędzie wyłączone”, ale czysto oddzielić konta API.

Zalecane podejście:

1. Użyj osobnego konta serwisowego dla procesów API.
2. Wyposaż konto tylko w potrzebne uprawnienia.
3. Dodatkowo ogranicz dostęp do API do stałych hostów IP lub sieci zarządzania.
4. Sprawdź, czy MFA dla tego konta jest technicznie i operacyjnie sensowne.
5. Jeśli MFA dla konta API nie jest praktyczne, szczególnie ściśle kontroluj konto pod względem źródła, uprawnień, przechowywania sekretów i śladu audytu.
6. Po aktualizacji do SFOS 22 przetestuj wszystkie procesy API z operacjami odczytu i zapisu.

⚠️ Użytkownicy API bez MFA nie mają wolnej ręki do szerokich uprawnień. Jeśli konto API jest z powodów technicznych obsługiwane bez MFA, źródłowa IP, uprawnienia, przechowywanie hasła, odpowiedzialność i możliwość audytu muszą być ściśle kontrolowane.

Szczególnie ważne jest to w przypadku automatyzacji, które nie tylko odczytują, ale także zmieniają konfigurację. Przed produkcyjnymi zmianami API powinno być dostępne aktualne backup Sophos Firewall. Przy przygotowanych masowych zmianach z Sophos Firewall Config Studio należy dodatkowo sprawdzić, czy generowane wywołania API lub curl działają z planowanym kontem.

Odróżnienie od Device Access

Kontrola dostępu do API nie jest tym samym co Device Access. Device Access kontroluje lokalne usługi firewall, takie jak WebAdmin, SSH, User Portal, VPN Portal, DNS czy Ping. Ustawienia dostępu do API kontrolują natomiast dostęp do interfejsu zarządzania XML API.

Mimo to oba tematy należą do utwardzania zarządzania. Każda warstwa ogranicza inny fragment powierzchni ataku:

Jeśli sieć administracyjna może korzystać z WebAdmin, SSH i API, powinna być szczególnie dobrze chroniona. Skompromitowany klient w sieci zarządzania to w przeciwnym razie bezpośredni dostęp do zarządzania firewallem.

Działanie i przegląd

Dostęp do API powinien być regularnie sprawdzany. Szczególnie po migracjach, zmianach dostawców usług, projektach automatyzacji lub aktualizacjach firewalla często pozostają stare źródła.

Sensowne pytania przeglądowe:

• Które hosty IP mogą obecnie korzystać z dostępu do API?
• Czy istnieją obiekty z prefiksem apiconfig?
• Czy te obiekty są nadal potrzebne?
• Czy nazwy i opisy odpowiadają rzeczywistemu celowi?
• Czy są udokumentowani odpowiedzialni?
• Czy dostępy do API są uwzględniane w procesie zmiany lub audytu?
• Czy przed większymi zmianami opartymi na API istnieje aktualna kopia zapasowa?

Przed zmianami opartymi na API zawsze powinna być dostępna kopia zapasowa. Artykuł Tworzenie lub przywracanie kopii zapasowej Sophos Firewall opisuje, na co należy zwrócić uwagę przy tworzeniu kopii zapasowej, przywracaniu i kompatybilności.

Typowe błędy

Rozwiązywanie problemów

Jeśli narzędzie nie może osiągnąć XML API, należy strukturalnie sprawdzić:

1. Czy adres źródłowy IP jest poprawny z punktu widzenia firewalla?
2. Czy źródło jest dozwolone jako host IP, zakres IP lub sieć?
3. Czy po aktualizacji utworzono obiekt apiconfig, ale nie został odpowiednio dostosowany?
4. Czy narzędzie używa poprawnego adresu i portu firewalla?
5. Czy nazwa użytkownika, hasło lub sekret są poprawne?
6. Czy konto ma potrzebne uprawnienia?
7. Czy konto wymusza MFA, mimo że narzędzie nie może przekazać tokenu jednorazowego?
8. Czy między narzędziem a firewallem występują efekty routingu, NAT lub proxy?
9. Czy dostęp został celowo usunięty przez środek utwardzający?

Jeśli zmiana API ma nieoczekiwane skutki, najpierw zabezpiecz ostatnią kopię zapasową, a następnie sprawdź ślad audytu, porównanie Config Studio i dotknięte obiekty firewalla. W przypadku problemów z ruchem na żywo bardziej pomocne są Log Viewer i Packet Capture niż samo API.

Lista kontrolna

Przed aktywacją:

• Udokumentuj cel dostępu do API.
• Jednoznacznie określ system źródłowy.
• Utwórz obiekt hosta IP z mówiącą nazwą.
• Sprawdź konto serwisowe i uprawnienia.
• Świadomie ustal zachowanie MFA dla konta API.
• Ustal proces tworzenia kopii zapasowej i przywracania.

Podczas działania:

• Zezwalaj na dostęp do API tylko dla określonych źródeł.
• Nie udostępniaj szerokich sieci klienckich, gościnnych lub IoT.
• Sprawdź obiekty apiconfig po aktualizacjach.
• Kontroluj dostępy dostawców usług czasowo i fachowo.
• Przechowuj sekrety w sposób chroniony i odnawiaj je przy zmianie personelu lub narzędzi.
• Testuj operacje odczytu i zapisu API po aktualizacjach SFOS.

Podczas przeglądu:

• Regularnie sprawdzaj dozwolone źródła API.
• Usuń niepotrzebne hosty IP.
• Porównaj zmiany z dziennikiem audytu i biletami zmiany.
• Testuj procesy automatyzacji po aktualizacjach oprogramowania.

FAQ