Instalacja i architektura- część 2

2019-12-19

Druga lekcja cyklu dotyczącego pracy z najnowszym systemem firmy Check Point (R80.10)jest skoncentrowana na zagadnieniach związanych z instalacją tego rozwiązania orazomówieniem architektury. W trakcie 30 minutowej lekcji poznajemy m.in.:

Druga lekcja cyklu dotyczącego pracy z najnowszym systemem firmy Check Point (R80.10) jest skoncentrowana na zagadnieniach związanych z instalacją tego rozwiązania oraz omówieniem architektury. W trakcie 30 minutowej lekcji poznajemy m.in.:

  • możliwe sposoby instalacji
  • wymagania sprzętowe
  • znane ograniczenia
  • architekturę nowego serwera zarządzającego
  • podstawy rozwiązywania problemów

Możliwe scenariusze

Wybierając tryb instalacji musimy zdecydować jaką rolę będzie pełniła nowa instancja instalowanego systemu operacyjnego. Wybór jest całkiem spory, gdyż GAIA (tak nazywa się system operacyjny firmy Check Point) może pracować jako:

  • Security Management Server
  • Security Gateway
  • Log Server
  • Smart Event
  • Standalone Device
  • High Availability

Na potrzeby bardzo dużych środowisk, czyli takich, gdzie serwerów zarządzających jest wiele, możemy wybrać również instalację w trybie Multi Domain. W praktyce decyzję dotyczącą roli instalowanego systemu będziemy tak naprawdę podejmować w trakcie przechodzenia przez kreator pierwszego uruchomienia systemu, jednak zastanowienie się nad tym zagadnieniem wcześniej pozwoli nam m.in. na prawidłowe dobranie parametrów sprzętu czy odpowiednie partycjonowanie dysków instalowanego systemu.

Instalacja

Do instalacji systemu GAIA potrzebne jest nam ISO, które możemy pobrać ze strony usercenter.checkpoint.com. W chwili pisania tego artykułu najnowsze ISO jest do pobrania pod adresem:

GAIA ISO

Zawsze jednak warto sprawdzić czy przypadkiem nie jest dostępny nowszy build. Możemy to zrobić wchodząc w usercenter.checkpoint.com w sekcję Support i wpisując w pole wyszukiwarki wersję szukanego systemu np. R80.10. Po pobraniu obrazu ISO możemy go oczywiście:

  • nagrać na płytę DVD (opcja dla instalacji na urządzeniach typu open server wyposażonych w napęd fizyczny)
  • użyć na wirtualnej maszynie
  • stworzyć nośnik USB umożliwiający instalację nowego systemu na urządzeniach Check Point Appliance - tutaj z pomocą przyjdzie nam narzędzie ISOmorphic, które również jest dostępne w Usercenter (sk65205)

Na filmie została krótko pokazana sekwencja uruchamiania urządzenia z obrazu ISO oraz kreator pierwszego uruchomienia. Praca z First Time Configuration Wizard jest bardzo ważna, gdyż decyzji podjętej na tym etapie dotyczącej trybu pracy urządzenia (Security Management, Multi Domain, Security Gateway) nie będziemy już w stanie zmodyfikować!!! Prezentowany film był nagrywany na wczesnej wersji systemu R80 w związku z czym opcja Security Gateway jest wyszarzona i nie da się jej wybrać. Dla systemu R80.10 oczywiście wszystkie prezentowane możliwości konfiguracyjne są już dostępne. Przechodząc przez kreator będziemy mogli również skonfigurować konto użytkownika administracyjnego czy też adresację interfejsu do zarządzania. Po przejściu przez kreator nastąpi restart urządzenia, po którym będziemy mogli zalogować się do interfejsu www systemu GAIA.

Wymagania sprzętowe

System GAIA możemy zainstalować na:

  • dedykowanych appliance'ach firmy Check Point (lista urządzeń dostępna jest pod adresem: appliance'e Check Point)
  • dedykowanych appliance'ach do zarządzania firmy Check Point (seria SMART-1)
  • urządzeniach typu open serwer wymienionych na liście kompatybilności z systemem operacyjnym GAIA
  • maszynie wirtualnej

Wymagania sprzętowe w momencie tworzenia tego dokumentu kształtują się jak poniżej, warto jednak zawsze zweryfikować aktualność tych informacji w dokumentacji do systemu operacyjnego.

art_2_img_1

Architektura

Podobnie jak w poprzednich latach architektura środowiska Check Point składa się z 3 kluczowych komponentów:

  • Unified Smart Console - aplikacji instalowanej na systemie MS Windows służącej do zarządzania środowiskiem Check Point
  • Security Management Server - serce całego środowiska przechowujące bazę danych, konfigurację polityk, certyfikaty, itp.
  • Security Gateways - nazwane na filmie "Enforcement Points", czyli miejsca, które egzekwują politykę bezpieczeństwa, do niedawna były to głównie bramki stojące w różnych segmentach sieci, jednak teraz politykę jesteśmy w stanie egzekwować również na urządzeniach mobilnych czy w środowiskach chmurowych (m.in. AWS).

art_2_img_2

Najważniejsze komponenty serwera zarządzającego to:

  • PostgreSQL - główna baza danych przechowująca obiekty, polityki, użytkowników, licencje oraz inne dane związane z procesem zarządzania środowiskiem Check Point
  • Objects_5_0.C - baza danych generowana w trakcie instalowania polityki bezpieczeństwa na potrzeby zachowania kompatybilności wstecz z Security Gateways w wersji starszej niż R80.10
  • Solr - komponent umożliwiający indeksowanie danych, dzięki któremu wyszukiwanie obiektów w bazie danych jest bardzo szybkie

Główne role serwera zarządzającego to:

art_2_img_3

Główne procesy

Absolutną nowością dla osób, które już znają rozwiązania Check Point jest proces CPM. Proces ten:

  • Umożliwia połączenie za pomocą Smart Console na porcie TCP 19009 do serwera zarządzającego
  • Wykonuje operacje na bazie danych (tworzenie/usuwanie/modyfikowanie obiektów)
  • Wykonuje Kompilację polityki bezpieczeństwa
  • Umożliwia migrację pomiędzy starą a nową logiką zarządzania
  • Wprowadza nową architekturę zarządzania dla skonsolidowanej konsoli (jedna aplikacja zarządzająca zamiast wielu mniejszych aplikacji)

Więcej szczegółów dotyczących pozostałych procesów odpowiedzialnych za pracę systemu operacyjnego można znaleźć w UserCenter pod sk97638.

sk97638

Baza danych

Jak wspominałem wcześniej główna baza danych to PostgreSQL. W nomenklaturze Check Point baza danych została podzielona na wiele tzw. "domainid". Wspomnianych domainid nie należy absolutnie mylić ze środowiskiem multi domain security management, jest to wyłącznie podobieństwo nazw dla dwóch zupełnie różnych elementów środowiska Check Point. W bazie danych znajdziemy zatem wiele domen podzielonych na dwie główne kategorie: System Domains oraz User Domains.

art_2_img_4

Przykładowo:

  • System Domain - przechowuje obiekty takie jak: administratorzy, zaufani klienci GUI, profile dostępu
  • CP data Domain - to domena read only, która zawiera wszystkie domyślne obiekty powoływane przez Check Point np. obiekty serwisów, obiekt puli adresów dla office_mode, itp.
  • IPS_DOMAIN - zawiera aktualizację sygnatur IPS, ponieważ jest to dedykowana domena dla modułu IPS pozwala dzięki temu na rollback aktualizacji sygnatur IPS
  • APPI_DOMAIN - domena dla aktualizacji sygnatur modułów Appliacation Controll i URL Filtering
  • LOG_DOMAIN - zawiera dane konfiguracyjne log serwerów
  • SMC_USER_DOMAIN - przechowuje repozytorium obiektów i reguł tworzonych przez użytkownika

Łącząc fakty

  1. Aplikacja Smart Console na kliencie komunikuje się z procesem CPM serwera zarządzającego R80.10 na porcie TCP 19009
  2. Proces CPM jest odpowiedzialny za zapisywanie informacji do bazy PostgreSQL oraz do komponentu SOLR.
  3. W R80.10 nadal funkcjonuje proces FWM dla zachowania kompatybilności wstecz. Obydwa procesy (CMP i FWM) komunikują się ze sobą poprzez "Authentication Request i Reply"
  4. Informacje kierowane przez proces CMP do bazy danych podlegają walidacji. Jeśli przejdzie ona pomyślnie dane mogą zostać zapisane do bazy PostgreSQL.
  5. CPM komunikuje się również z procesem Solr, który jest odpowiedzialny za indeksowanie danych w bazie PostgresSQL, celem przyspieszenia przeszukiwania tejże bazy.

Ważne

Praca administratorów jest oparta o indywidualne sesje. Łącząc się za pomocą Smart Console (lub za pomocą API) do serwera zarządzającego każdy z administratorów otrzymuje odrębną, indywidualną sesję. Wszystkie zmiany są wykonywane wyłącznie w ramach sesji użytkownika i nie są one widoczne dla pozostałych administratorów do momentu, kiedy nie zdecydujemy się na upublicznienie zmian do bazy danych poprzez wybranie odpowiedniej opcji w interfejsie zarządzającym („Publish”). Dopiero po opublikowaniu zmian nasze działania będą widoczne dla pozostałych administratorów systemu. Więcej szczegółów na temat sesji, publikowania zmian oraz pracy wielu użytkowników jednocześnie zostanie omówionych podczas kolejnych lekcji.

Rozwiązywanie problemów

W filmie zostało przedstawionych kilka bardzo podstawowych operacji związanych m.in. z weryfikacją czy główne procesy serwera zarządzającego są aktywne, czy cpwd (check point watch dog) monitoruje te procesy, czy moduł slr jest aktywny. Rozwiązywanie problemów związanych z procesem cpm można zdecydowanie rozpocząć od weryfikacji pliku logu tego procesu. Plik znajduje się w lokalizacji $FWDIR/log/cpm.elg. Zawartość tego pliku może być bardzo przydatna podczas tworzenia zgłoszenia tserwisowego w portalu UserCenter.

Więcej szczegółów związanych z debugowaniem głównych procesów R80.10 można znaleźć w artykule sk115557:

artykuł sk115557

Galeria