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 > API access, 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 > API access.
• Dostęp API jest domyślnie wyłączony i musi zostać świadomie włączony.
• 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: API tylko z określonych źródeł

API access należy traktować tak samo jak WebAdmin lub SSH: możliwie wąsko, tylko tak szeroko, jak to konieczne.

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

• dedykowany serwer automatyzacji,
• system monitoringu,
• host zarządzania konfiguracją,
• wewnętrzna sieć zarządzająca,
• sieć VPN lub administracyjna,
• jasno zdefiniowany adres źródłowy partnera lub MSP.

Niesensowne są:

• całe sieci klienckie,
• sieci gościnne lub IoT,
• Any,
• niejasne zwolnienia typu „cała sieć serwerowa”,
• tymczasowe adresy IP testowe, o których później się zapomina.

Jeśli zewnętrzni dostawcy usług potrzebują dostępu API, źródło powinno być zdefiniowane możliwie dokładnie. Dodatkowo należy udokumentować, do czego służy dostęp i kiedy zostanie usunięty.

Zalecany przebieg

Dokładna ścieżka w interfejsie może się nieznacznie różnić zależnie od wersji SFOS. W SFOS 22 konfiguracja API znajduje się w Administration > API access.

Praktyczny przebieg:

1. Sprawdzić, który system potrzebuje dostępu API.
2. W Hosts and services > IP host utworzyć jednoznaczny obiekt IP Host dla tego systemu.
3. Jeśli potrzebnych jest kilka źródeł, czytelnie nazwać IP Hosts, IP ranges lub sieci.
4. W Administration > API access włączyć API access.
5. W Allowed IP hosts dopuścić tylko te obiekty.
6. Kliknąć Apply.
7. Nie dodawać szerokich sieci klienckich ani serwerowych.
8. Przetestować dostęp z rzeczywistego hosta automatyzacji lub monitoringu, nie z laptopa administratora.
9. Usunąć źródła, które nie są już potrzebne.
10. Udokumentować zmianę w procesie change.

W istniejących instalacjach po aktualizacji do SFOS 22 należy dodatkowo wyszukać obiekty z prefiksem apiconfig. Obiekty te zostały utworzone ze starszych wpisów API allow i należy je sprawdzić, nazwać lub uporządkować.

Celowo przetestować dostęp

Endpoint API zwykle znajduje się pod adresem:

https://<IP-lub-nazwa-firewalla>:<Port>/webconsole/APIController

Port jest portem HTTPS WebAdmin Console. Jeśli port administracyjny został zmieniony w Administration > Admin settings, narzędzie API musi używać tego samego portu. API pracuje z payloadami XML przez HTTP POST, a nie jak klasyczne REST API z oddzielnymi endpointami GET, POST, PUT i DELETE.

Sensowny test nie odpowiada tylko na pytanie, czy logowanie jest możliwe. Powinien pokazać, czy właściwe źródło jest dozwolone, czy konto może wykonać potrzebną operację i czy wynik pozostaje śledzalny w procesie audytu lub change.

W ramach odbioru należy oddzielnie sprawdzić:

• Źródło: Test działa z rzeczywistego hosta automatyzacji, monitoringu lub integracji, nie z laptopa administratora.
• Dostęp: Firewall akceptuje źródłowy adres IP tylko wtedy, gdy pasujący obiekt IP Host jest dozwolony w API access.
• Konto: Używane konto API lub serwisowe ma tylko wymagane uprawnienia.
• Secret: Nazwy użytkowników, hasła lub tokeny nie trafiają do historii powłoki, ticketów, czatów ani zrzutów ekranu.
• Audyt: Dostęp lub zmiana są śledzalne w procesie audytu lub change.
• Rollback: Przed operacjami zapisu istnieje backup, punkt wycofania i nieszkodliwy test odczytu.

Przykłady curl z nazwą użytkownika i hasłem w URL szybko się kopiuje, a później trudno usunąć je z logów. Lepszy jest krótki test z dedykowanym kontem serwisowym, tymczasowym secretem testowym, bezpiecznym przechowywaniem i późniejszą rotacją, jeśli secret został użyty w niebezpiecznym kontekście.

Do testów strukturalnych kolekcja Postman jest często czystsza niż szybko skopiowane polecenie shell. Również tam adres firewalla, port, nazwa użytkownika, hasło i wartości obiektów powinny być przechowywane jako zmienne lub secrety, a nie na stałe w requestach, screenshotach lub ticketach. Kolekcja nie jest koncepcją bezpieczeństwa, ale pomaga bardziej powtarzalnie testować operacje odczytu i zapisu.

Dostępne API nie dowodzi jeszcze, że planowana zmiana jest technicznie bezpieczna. Przed operacjami zapisu w produkcji powinna najpierw działać nieszkodliwa kwerenda odczytu, a następnie mała, kontrolowana zmiana.

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.

Dla dedykowanego konta API lepszy jest wąski proces niż szybko skopiowany pełny administrator. W dokumentacji Sophos ten element występuje jako Allow API access to administrators: zezwala się nie tylko na źródło, ale również administrator lub profil musi mieć odpowiedni dostęp.

1. Utwórz profil administratora z wymaganymi uprawnieniami w Profiles > Device access.
2. Utwórz użytkownika administracyjnego dla procesu API w Authentication > Users.
3. Przypisz odpowiedni profil administratora.
4. Jeśli dostęp jest potrzebny tylko tymczasowo, ogranicz Access time.
5. Jeśli to możliwe, ogranicz Login restriction for device access do przewidzianych źródeł.
6. Następnie zezwól na API access i Device Access dla odpowiedniego źródła.

Sophos wspiera oficjalne API i niezmienione skrypty przykładowe. Własne integracje, wrappery i automatyzacje nadal potrzebują wewnętrznego właściciela, testów i koncepcji rollbacku. „Działa w labie” nie wystarcza dla produkcyjnych operacji zapisu.

MFA i użytkownicy API po SFOS 22

MFA jest ważne dla interaktywnych dostępów administracyjnych. Dla procesów API i automatyzacji trzeba jednak świadomie zaplanować uwierzytelnianie. Skrypt, narzędzie monitorujące lub system integracyjny nie może po prostu wpisać kodu OTP, jeśli używany użytkownik wymusza MFA.

Na liście Known Issues udokumentowano szczególny przypadek SFOS 22: po aktualizacji zmiany konfiguracji przez API mogą się nie udać dla zmigrowanych użytkowników, jeśli MFA jest aktywne i nie przekazano one-time token. Niezmigrowani użytkownicy mogą w pewnych przypadkach zachowywać się inaczej. Operacyjnie ważne jest, aby nie robić z tego nieporządnego „wyłączmy MFA wszędzie”, lecz czysto oddzielić konta API.

Zalecane podejście:

1. Dla procesów API używać osobnego konta serwisowego.
2. Nadać kontu tylko wymagane uprawnienia.
3. Dodatkowo ograniczyć API access do stałych IP Hosts lub sieci zarządzających.
4. Sprawdzić, czy MFA dla tego konta ma sens technicznie i operacyjnie.
5. Jeśli MFA dla konta API nie jest praktyczne, kontrolować konto szczególnie ściśle przez źródło, uprawnienia, przechowywanie secretów i audit trail.
6. Po aktualizacji do SFOS 22 przetestować wszystkie procesy API operacjami odczytu i zapisu.

⚠️ Użytkownicy API bez MFA nie są przepustką do szerokich uprawnień. Jeśli konto API z powodów technicznych działa bez MFA, źródłowy IP, uprawnienia, przechowywanie hasła, odpowiedzialność i audytowalność muszą być kontrolowane ściślej.

Ten punkt jest szczególnie ważny przy automatyzacjach, które nie tylko czytają, ale także zmieniają konfigurację.

Przed produkcyjnymi zmianami przez API należy sprawdzić co najmniej trzy rzeczy:

• Istnieje aktualny backup Sophos Firewall.
• Planowane konto API może pomyślnie wykonać nieszkodliwą kwerendę odczytu.
• Przy przygotowanych zmianach masowych z Sophos Firewall Config Studio wygenerowane 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, ale oba mechanizmy działają razem. Device Access kontroluje lokalne usługi firewall, takie jak WebAdmin, SSH, User Portal, VPN Portal, DNS czy Ping. Ustawienia dostępu do API dodatkowo kontrolują, które hosty IP mogą używać XML API. Ważne: uprawnienia Device Access dla WebAdmin Console obowiązują także dla dostępów API.

W praktyce oznacza to, że API access musi być dozwolony, źródło musi być dopuszczone w ustawieniach dostępu do API, a lokalny dostęp administracyjny do firewall nie może być blokowany przez Device Access. Każda warstwa ogranicza inny fragment powierzchni ataku:

• Prawidłowa konfiguracja Device Access: lokalne usługi firewall, takie jak WebAdmin, SSH, User Portal, VPN Portal, DNS czy Ping
• Kontrola dostępu do API: hosty IP, które mogą dodatkowo używać XML API
• Aktywacja MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access: interaktywne loginy dla WebAdmin, VPN Portal i Remote Access
• Nazwani administratorzy i jasne role: Śledzenie i zakres szkód kont administratorów i serwisowych

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

• API access dozwolony dla całej sieci klienckiej: Każdy skompromitowany klient z tej sieci może osiągnąć API.
• Stare obiekty apiconfig niesprawdzone: Zmigrowane stare wyjątki pozostają niezauważenie aktywne.
• Konto serwisowe używa pełnych praw administratora: Skompromitowany secret ma niepotrzebnie duży zasięg szkód.
• Automatyzacja API używa administratora wymagającego MFA: Skrypt lub narzędzie może po aktualizacji SFOS zawieść przy operacjach zapisu.
• Błędny port w narzędziu: Port HTTPS administratora został zmieniony, ale narzędzie nadal używa starego portu.
• Oczekiwana logika REST: Narzędzie wysyła metody REST zamiast payloadu XML przez HTTP POST do APIController.
• Tymczasowy IP dostawcy pozostaje aktywny: Dostęp zewnętrzny jest możliwy dłużej niż planowano.
• Brak dokumentacji celu: Późniejsi administratorzy nie wiedzą, czy zezwolenie jest nadal potrzebne.
• Zmiany API bez backupu: Błędną automatyzację trudniej wycofać.

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 Device Access zezwala na lokalny dostęp WebAdmin/API z tej strefy?
5. Czy narzędzie używa poprawnego adresu firewalla i właściwego portu admin HTTPS?
6. Czy nazwa użytkownika, hasło lub sekret są poprawne?
7. Czy konto ma potrzebne uprawnienia?
8. Czy konto wymusza MFA, mimo że narzędzie nie może przekazać tokenu jednorazowego?
9. Czy między narzędziem a firewallem występują efekty routingu, NAT lub proxy?
10. Czy dostęp został celowo usunięty przez środek utwardzający?
11. Czy test wykonano z właściwego systemu źródłowego, czy tylko z klienta administratora?

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.
• Ustal metodę testowania bez wycieku sekretów.

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.
• Rotuj sekrety, jeśli trafiły do historii shella, ticketów lub niebezpiecznych lokalizacji.
• 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