docDo portu WAN urz¹dzenia Sofaware podłšczamy kabel dostarczany
download 
Reklamacja Transkrypt
Do portu WAN urz¹dzenia Sofaware podłšczamy kabel dostarczany
Analiza techniczna rozwiązań ochrony systemów Firewall przed awariami Systemy informatyczne są obecnie powszechnie wykorzystywane do prowadzenia działalności biznesowej. Utrzymanie ich stałej dostępności i niezawodności jest zadaniem, z którym borykają się wszystkie działy IT. Dobrą praktyką jest stosowanie oprogramowania renomowanych producentów, markowych urządzeń i sprzętu komputerowego oraz wykupienie usług wsparcia technicznego. W rozwiązaniach wymagających niezakłóconej pracy stosuje się urządzenia wyposażone w komponenty nadmiarowe (np. dwa zasilacze, macierze dysków), bądź też tworzy konfiguracje klastrów złożonych z wielu urządzeń. Dostępność usług systemu informatycznego funkcjonującego w środowisku sieciowym zależy od wielu czynników (m.in. urządzeń sieciowych, łącz transmisyjnych, systemów zabezpieczeń). Z technicznego punktu widzenia najbardziej obszernym zagadnieniem jest ochrona przed awariami systemów zabezpieczeń. Wynika to ze złożoności ich konfiguracji i realizowanych przez nie operacji. Elementem zabezpieczeń sieciowych, który w pierwszej kolejności podlega ochronie przed awariami jest system zaporowy. Awaria systemu Firewall oznacza bowiem zablokowanie użytkownikom dostępu do sieci i znajdujących się tam zasobów. Konfiguracje zawierające mechanizmy ochrony przed awariami określane są terminem High Availability (HA). Jakość rozwiązań HA W typowej konfiguracji HA system zaporowy składa się z dwóch lub więcej maszyn Firewall tworzących klaster, które kontrolują się wzajemnie i w razie wystąpienia awarii przejmują zadania uszkodzonej maszyny. O jakości rozwiązania HA decydują następujące własności: • Wykrywanie awarii platformy sprzętowej – w razie wykrycia awarii sprzętu (np. dysku, karty sieciowej) następuje odłączenie uszkodzonej maszyny Firewall z klastra i przekazanie jej zadań innej sprawnej maszynie. • Wykrywanie zakłóceń i awarii zabezpieczeń – odłączenie maszyny Firewall z klastra następuje w razie wykrycia poważnych zakłóceń lub awarii funkcjonowania oprogramowania Firewall. • Utrzymanie sesji w czasie awarii – połączenia przechodzące przez Firewall, który uległ awarii są przejmowane przez inną sprawną maszynę w klastrze tak, aby awaria nie była odczuwalna dla użytkowników. • Skalowalność i elastyczność – dodanie maszyny Firewall do klastra powoduje zwiększenie wydajności systemu zaporowego; istnieje możliwość modelowania ruchu sieciowego pomiędzy maszynami Firewall w klastrze. • Badanie otoczenia klastra – funkcjonowanie klastra HA jest uzależnione nie tylko od stanu poszczególnych maszyn Firewall, ale także od stanu otaczającego środowiska (np. moduł HA testuje dostępność łączy, urządzeń sieciowych, serwerów). • Zarządzanie i monitorowanie – klaster HA jest bez zakłóceń zarządzany i monitorowany z użyciem dedykowanych narzędzi. Analiza techniczna rozwiązań ochrony Firewall przed awariami Istnieje bardzo wiele rozwiązań ochrony Firewall przed awariami. Rozwiązania te różnią się zasadą swojego funkcjonowania, jakością i ceną. Informacje przedstawiane na ich temat przez producentów, zwłaszcza dotyczące ich jakości są często nieprawdziwe. Zdarza się, że producenci słabych technicznie technologii HA w materiałach marketingowych opisują swoje rozwiązania podając wymyślone własności, których nie można w sposób wiarygodny zweryfikować (np. aktywna ochrona sesji, poziom zintegrowania HA). Niniejsze opracowanie w sposób techniczny omawia zagadnienia ochrony Firewall przed awariami. W celu lepszego zrozumienia oraz możliwości zweryfikowania informacji zagadnienia te zostały przedstawione w odniesieniu do rzeczywistych rozwiązań HA dostępnych dla systemu zaporowego Check Point VPN-1/ FireWall-1. Klasyfikacja rozwiązań HA Rozwiązania HA dostępne dla systemu zabezpieczeń VPN-1/FireWall-1 z uwagi na sposób funkcjonowania można podzielić na następujące kategorie: • Protokoły rutingu (HA Ruter) – protokóły rutingu IP pozwalające na tworzenie z wielu fizycznych urządzeń jednej wirtualnej maszyny, w której jedna maszyna Firewall jest aktywna, a pozostałe to maszyny zapasowe. Protokoły te funkcjonują niezależnie od zabezpieczeń Firewall. Przykładem takiego rozwiązania jest protokół Virtual Router Redundancy Protocol (VRRP), zaimplementowany m.in. w urządzeniach Nokia oraz Intrusion. • Klastering w systemie operacyjnym – mechanizmy zaimplementowane w systemie operacyjnym platformy Firewall umożliwiające tworzenie klastrów, w których wiele maszyn współdzieli pomiędzy sobą ruch sieciowy. Mechanizmy te funkcjonują niezależnie od zabezpieczeń Firewall. Przykładem takiego rozwiązania jest mechanizm IP Clustering dostępny w urządzeniach Nokia z systemem operacyjnym w IPSO 3.61 (mechanizm wcześniej stosowany w wycofanych z produkcji urządzeniach Nokia CC). • Urządzenia rozdzielające ruch sieciowy (Load Balancer, LB) – zewnętrzne względem Firewall urządzenia, które zgodnie z przyjętym algorytmem rozdzielają ruch sieciowy pomiędzy wiele maszyn Firewall. Przykładem takiego urządzenia jest Radware FireProof. • HA Firewall – rozwiązania programowe funkcjonujące na maszynach Firewall zaprojektowane pod kątem monitorowania i ochrony przed awariami Firewall jako całości (tzn. sprzętu, systemu operacyjnego, procesów zabezpieczeń). Przykładem takich rozwiązań są Check Point ClusterXL, Rainfinity RainWall oraz StoneBeat FullCluster. W tej klasie dostępne są także rozwiązania sprzętowo-programowe HA, gdzie producent dostarcza urządzenia złożone z dwóch odpowiednio zintegrowanych maszyn Firewall (np. Resilience DX4000). 1 IPSO - system operacyjny urządzeń Nokia IP (oparty na FreeBSD). © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 2 Analiza techniczna rozwiązań ochrony Firewall przed awariami Powyżej przedstawione rozwiązania HA posiadają także różne możliwości w zakresie ochrony Firewall przed awariami i utrzymania stałej dostępności usług systemu informatycznego (patrz tabela 1). Tabela 1 – Porównanie jakości rozwiązań ochrony Firewall przed awariami Rodzaj HA Protokoły rutingu (HA Ruter) Klastering w systemie operacyjnym Urządzenia rozdzielające ruch sieciowy (LB) HA Firewall Wykrywanie awarii platformy sprzętowej Firewall Tak Tak Tak Tak Wykrywanie zakłóceń i awarii zabezpieczeń Firewall Nie Nie Tak2 Tak Utrzymanie sesji w czasie awarii Tak3 Tak3 Tak3 Tak3 Skalowalność i elastyczność Nie Tak4 Tak Tak Badanie otoczenia klastra Nie Nie Nie Tak Zarządzanie i monitorowanie Tak5 Tak5 Tak5 Tak5 Własności 2 3 4 5 Urządzenia LB posiadają ograniczone możliwości badania stanu zabezpieczeń Firewall, z uwagi na swoją lokalizację. We wszystkich rozwiązaniach HA utrzymanie sesji przechodzących przez klaster Firewall w razie awarii jest realizowane dzięki synchronizacji stanu modułów zabezpieczeń Check Point VPN-1/FireWall-1. Mechanizmy klasteringu dostępne w systemie operacyjnym mają ograniczone możliwości modelowania ruchu sieciowego pomiędzy maszynami Firewall. Narzędzia monitorowania i zarządzania bardzo różnią się w zależności do rozwiązania HA i są ze sobą trudne do porównania. © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 3 Analiza techniczna rozwiązań ochrony Firewall przed awariami Architektura i zasady funkcjonowania Funkcjonowanie klastrów HA zasadniczo różni się w zależności od tego czy decyzja o kierowaniu ruchu sieciowego odbywa się na urządzeniu zewnętrznym (Load Balancer), czy też realizowane jest to przez mechanizmy HA bezpośrednio na maszynach Firewall (patrz rysunek 1). Rys 1) Zasady funkcjonowania klastrów HA Każde z powyżej przedstawionych rozwiązań HA posiada określone wady i zalety. Zaletą stosowania zewnętrznych urządzeń LB jest to, że funkcjonują one podobnie jak przełączniki (switch) i rozdzielają ruch sieciowy na segmenty sieci do poszczególnych maszyn Firewall. Uzyskuje się przez to większą przepustowość systemu. Dla porównania w programowym klastrze HA ruch sieciowy jest rozsyłany do wszystkich maszyn Firewall. Stosując LB nie powoduje się dodatkowego obciążenia maszyn Firewall przez funkcjonujące tam mechanizmy HA. Jako wady przedstawiane zewnętrznym urządzeniom LB wymienia się ograniczone możliwości kontroli stanu Firewall (patrz tabela 1) oraz to, że potencjalnie same mogą ulec awarii i doprowadzić do niedostępności systemu informatycznego. Koncepcja funkcjonowania programowego klastra HA polega na tym, iż cały ruch z określonej sieci (np. Internetu, sieci chronionej, DMZ) jest kierowany do wszystkich maszyn Firewall, które na podstawie współdzielonych informacji o stanie każdej z maszyn w klastrze podejmują decyzję, czy przyjąć pakiety, czy też pozostawić je dla innej maszyny. Każda z maszyn Firewall w klastrze posiada do tego celu zaimplementowany specjalny filtr pakietów, funkcjonujący pomiędzy sterownikiem do karty sieciowej i jądrem modułu VPN-1/FireWall-1 (patrz rysunek 2). © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 4 Analiza techniczna rozwiązań ochrony Firewall przed awariami Wymiana informacji pomiędzy modułami HA odbywa się za pomocą dedykowanego protokołu, często określanego nazwą heartbeat. Warunkiem utrzymania poprawnej komunikacji sieciowej poprzez klaster HA jest to, iż każda z maszyn Firewall musi wiedzieć co dzieje się na innych maszynach. Za pomocą protokołu heartbeat wymieniane są m.in. następujące informacje: • które maszyny Firewall są w stanie normalnej pracy, • które maszyny Firewall są niedostępne (np. uległy awarii, zostały odłączone przez administratora), • jakie połączenia sieciowe przechodzą przez maszyny Firewall. • jakie jest aktualne obciążenie każdej z maszyn Firewall. połączenie 1 połączenie 2 heartbeat NIC NIC Moduł HA Moduł VPN-1/FireWall-1 Moduł HA Moduł VPN-1/FireWall-1 Rys 2) Koncepcja funkcjonowania klastra Firewall z programowym rozwiązaniem HA Klaster HA złożony z wielu maszyn Firewall jest widziany w sieci jak jedna maszyna. Unika się w ten sposób problemów z konfiguracją rutingu IP na stacjach roboczych i innych urządzeniach w sąsiedztwie klastra. Klaster HA posiada do tego celu współdzielone przez wszystkie maszyny Firewall adresy IP, określane są jako adresy klastrowe. W celu uniknięcia problemów z konfiguracją znajdujących się w otoczeniu klastra przełączników (switch) dla adresów klastrowych IP stosuje się multicast-owe adresy MAC. Dzięki temu pakiety z klastrowym adresem IP (jako miejsce przeznaczenia) są kierowane na wszystkie porty przełącznika6 i trafiają do wszystkich maszyn Firewall. Oprócz adresów klastrowych interfejsy Firewall zwykle posiadają także swoje unikalne adresy, które są potrzebne do nawiązywania połączeń inicjowanych z samych maszyn Firewall (np. zapytania DNS). Rysunek 3 przedstawia przykładową adresację klastra HA. 6 Przełączniki (switch) zgodnie z zasadą swojego działania kierują pakiety z unicast-owym adresem MAC tylko na jeden port. Dlatego, też w klastrach Firewall powszechnie przyjęta jest adresacja multicast-owa MAC. © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 5 Analiza techniczna rozwiązań ochrony Firewall przed awariami Rys 3) Przykład adresacji klastra HA Tryby pracy klastrów HA Wchodzące w skład klastra HA maszyny Firewall są odpowiednio ze sobą zsynchronizowane oraz posiadają mechanizmy wykrywania awarii i automatycznego przejmowania zadań uszkodzonej maszyny (tzw. przełączanie klastra). Synchronizacja polega na współdzieleniu przez maszyny Firewall tablic stanu tak, aby każdy Firewall wiedział, jakie połączenia sieciowe przechodzą przez pozostałe maszyny i jaki jest ich stan. Tryb pracy klastra HA jest uzależniony od tego czy wymagana jest tylko ochrona przed awariami, czy też przewidywane jest duże obciążenie maszyn Firewall i wymagane jest podwyższenie wydajności systemu zaporowego. Występują dwa podstawowe tryby pracy HA: • Active-Standby (określany także jako „gorąca rezerwa”, Hot-Standby) – klaster HA składa się z dwóch lub więcej maszyn Firewall, wśród których tylko jedna jest aktywna, a pozostałe to maszyny zapasowe uruchamiane w razie awarii aktywnego Firewall. • Active-Active – klaster HA składa się z dwóch lub więcej maszyn Firewall, współdzielących pomiędzy sobą w czasie rzeczywistym ruch sieciowy. © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 6 Analiza techniczna rozwiązań ochrony Firewall przed awariami Klaster typu Active-Active może ponadto funkcjonować na dwa sposoby. W pierwszym, zwanym Load Sharing rozdzielane pomiędzy maszyny Firewall są tylko nowe połączenia oraz połączenia z Firewall, który uległ awarii. Ruch rozdzielany jest z użyciem rutingu IP lub odpowiedniego algorytmu. Drugi tryb - Load Balancing funkcjonuje podobnie jak Load Sharing, z tym, że dodatkowo bada obciążenie maszyn Firewall i umożliwia, aby połączenia z bardziej obciążonego Firewall zostały przeniesione na mniej obciążone maszyny w klastrze. W materiałach marketingowych niektórych producentów Load Balancing jest przedstawiany jako kluczowa własność systemów HA. Podział na Load Sharing i Load Balancing w przypadku rozwiązania typu HA Firewall ma jednak w rzeczywistości niewielkie znaczenie. Praktyczne działanie obu trybów pracy jest do siebie bardzo zbliżone: w obu przypadkach oprogramowanie przenosi sesje na inne urządzenie tylko w razie przeciążenia urządzenia bliskiego stanowi awarii. Wynika to z faktu, że przenoszenie sesji pomiędzy systemami Firewall jest bardzo ryzykowne: przenoszona sesja może bowiem zostać łatwo zablokowana z powodu ograniczeń mechanizmu synchronizacji jej stanu między urządzeniami. Wykrywanie awarii Skuteczny system ochrony zabezpieczeń Firewall przed awariami realizuje testy sprzętu i stanu systemu operacyjnego oraz, co w praktyce okazuje się najbardziej istotne, wykonuje kompletne monitorowanie zabezpieczeń (m.in. kontroluje, czy moduł VPN1/FireWall-1 funkcjonuje poprawnie, czy z jakiegoś powodu zabezpieczania nie zostały wyłączone, czy nie uległy zablokowaniu procesy Security Servers, czy jest zainstalowana polityka bezpieczeństwa Firewall, itp.). W rzeczywistych warunkach zakłócenia i awarie w pracy zabezpieczeń Firewall zdarzają się znacznie częściej niż awarie sprzętu. Niektórzy producenci HA traktują Firewall jak zwykłe urządzenie sieciowe i nie zauważają, że oprócz sprzętu znajduje się tam skomplikowane oprogramowanie. Wg analizy wykonanej przez Gartner Group awarie sprzętowe w systemach informatycznych to mniej niż 20% wszystkich przyczyn nieplanowanego braku dostępności (patrz rysunek 4). Protokoły rutingu (np. VRRP), czy też mechanizmy klasteringu dostępne w systemie operacyjnym (np. IP Clustering) nie są w stanie wykryć zakłóceń i awarii procesów zabezpieczeń, a jedynie poważne awarie sprzętu. Zewnętrzne urządzenia typu Load Balancer mają w tym zakresie znaczne ograniczone możliwości. Rys 4) Przyczyny nieplanowanego braku dostępności (źródło: Gartner Group) © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 7 Analiza techniczna rozwiązań ochrony Firewall przed awariami Dedykowane rozwiązania HA oprócz podstawowych testów platformy Firewall mogą wykonywać szereg innych badań, w tym także badań otoczenia klastra. Dla przykładu w systemie StoneBeat FullCluster dostępne są następujące testy: • kontrola stanu interfejsów sieciowych, łączy oraz dostępności urządzeń w sieci, • kontrola zasobów systemu operacyjnego (m.in. wolne miejsce na dysku, pamięci wirtualnej, pamięci swap, średniego obciążenia systemu, obciążenia procesora, liczby poprawnie działających procesorów), • kontrola stanu zabezpieczeń Firewall (m.in. uruchomienia procesów Firewall, zainstalowania określonej polityki bezpieczeństwa, procentu odrzuconych pakietów przez Firewall, procentu zablokowanych pakietów przez Firewall, procentu zaakceptowanych pakietów przez Firewall), • inne parametry badane przez wskazane skrypty i aplikacje. Utrzymanie sesji w czasie awarii Żadne z rozwiązań HA nie może zagwarantować, że wszystkie sesje przechodzące przez Firewall, który uległ awarii zostaną przejęte i poprawnie utrzymane na innej, sprawnej maszynie. Rozwiązanie HA może jedynie zapewnić, że wszystkie nowe połączenia zostaną poprawnie obsłużone przez system zabezpieczeń. Zdarza się, że materiały niektórych dostawców HA podają, iż ich rozwiązania zapewniają, że żadne połączenia sieciowe nie zostaną odrzucone (np. dokument „Nokia IP Clustering in IPSO FAQ”). Nie jest to technicznie możliwe, ponieważ w zakresie utrzymania sesji wszystkie rozwiązania HA bez względu na rodzaj bazują na mechanizmie synchronizacji zaimplementowanym w modułach zabezpieczeń Check Point VPN-1/FireWall-1. Mechanizm ten posiada zaś określone ograniczenia. Dokumentacja „Check Point FireWall-1 Guide NG” dokładnie opisuje sposób funkcjonowania i możliwości mechanizmu synchronizacji. VPN-1/FireWall-1 synchronizuje tabele stanu dla sesji kontrolowanych na poziomie jądra modułu zabezpieczeń, w tym także sesji poddanych translacji NAT oraz sesji szyfrowanych VPN. Nie podlega synchronizacji stan zabezpieczeń Security Servers7. Funkcjonują one bowiem w systemie operacyjnym jako procesy i w czasie rzeczywistym nie ma możliwości synchronizowania ich stanu. Inne ograniczenie wynika z faktu, że synchronizacja Firewall posiada ograniczoną częstość (ok. 100 milisekund) i odbywa się poprzez sieć, która może być przeciążona. Może zdarzyć się więc sytuacja, że informacja o zaakceptowanej przez jeden Firewall sesji TCP (SYN) nie zostanie na czas przekazana do pozostałych maszyn w klastrze i w czasie jego awarii kolejny pakiet sesji (SYN/ACK) zostanie odrzucony. Nie można zagwarantować, że taka sesja TCP zostanie przez aplikację ponownie zsynchronizowana i utrzymana. 7 Procesy Security Servers w systemie zabezpieczeń Check Point FireWall-1 odpowiadają za analizę ruchu sieciowego na poziomie aplikacyjnym. Dla przykładu, dla protokołu HTTP realizowana jest kontrola poprawności poleceń i formatu danych, uwierzytelnianie tożsamości użytkowników, kontrola schematów i adresacji URL, blokowanie ataków typu HTTP Worm (np. Nimda, CodeRed), przeciwdziałanie atakom typu Buffer Overflow (np. kontrola rozmiaru URL), blokowanie niedozwolonych załączników w stronach HTML (np. ActiveX, Java), niedozwolonych plików kopiowanych poprzez HTTP (np. VisualBasic), czy URL zawierających niedozwolone słowa kluczowe. © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 8 Analiza techniczna rozwiązań ochrony Firewall przed awariami Firewall przede wszystkim musi realizować swoje funkcje zabezpieczeń. Nie można obniżać bezpieczeństwa sieci i akceptować połączeń na Firewall w klastrze HA zakładając, że zostały one wcześniej sprawdzone i zaakceptowane na innej maszynie klastra. W zależności o przyjętej polityki bezpieczeństwa, wykorzystywanych aplikacji i obciążenia sieci klaster HA może utrzymać dużą część połączeń przechodzących przez uszkodzoną maszynę Firewall. Potencjalnie liczbę tę można zwiększyć poprzez wyłączenie zabezpieczeń poziomu aplikacji i mechanizmu weryfikacji sekwencji TCP. W większości wdrożeń Firewall wyłączanie zabezpieczeń jest jednak nieuzasadnione, ponieważ statystycznie awaria Firewall zdarza się rzadko, a w razie jej wystąpienia ponowne zestawienie sesji przez użytkownika nie stanowi zwykle dużego kłopotu. Skalowalność i elastyczność System zabezpieczeń Firewall powinien wydajnie obsługiwać aktualnie wykorzystywane oraz planowane protokoły komunikacyjne i usługi sieciowe. Jako regułę można przyjąć, że rozwój technologii informatycznej spowoduje konieczność zwiększania wydajności zabezpieczeń. W tym zakresie przede wszystkim sama platforma sprzętowa Firewall w trakcie eksploatacji nie powinna sprawiać problemów z rozbudową i modernizacją. Mało rozsądne jest stosowanie urządzeń Firewall Appliance, które nie mają możliwości modernizacji (np. wymiany procesora na szybszy, zamontowania większego dysku). Skalowalność zabezpieczeń Firewall można uzyskać także z użyciem technologii HA. Dodanie nowej maszyny Firewall do klastra HA funkcjonującego w trybie Active-Active powoduje podwyższenie wydajności zabezpieczeń. W większości rozwiązań HA dodatkowe urządzenie Firewall można podłączać do klastra bez konieczności zakłócania pracy innych, działających Firewall. Od rozwiązań HA niekiedy wymaga się także elastyczności w zakresie modelowania ruchu sieciowego przechodzącego przez klaster. Przykładem jest sterowanie ruchu z określonych serwerów lub sieci tak, aby był zawsze obsługiwany przez określony Firewall w klastrze, jeżeli tylko znajduje się on w stanie pracy normalnej. Rys 5) Zależność wydajności Firewall od liczby maszyn w klastrze HA Producenci rozwiązań HA podają, że wzrost wydajności Firewall w klastrze Active-Active jest liniowy (tzn. dodając maszynę Firewall o przepływności X Mbps zwiększamy prawie o tą wartość przepływność całego klastra). Rysunek 5 przedstawia wyniki wykonanych przez producenta testów klastra RainWall z czterema komputerami Dell z procesorem 133 MHz. © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 9 Analiza techniczna rozwiązań ochrony Firewall przed awariami Zarządzanie i monitorowanie Utrzymanie odpowiedniego poziomu bezpieczeństwa systemu informatycznego wymaga właściwego zarządzania i monitorowania jego zabezpieczeń. Producenci zabezpieczeń dostarczają do tego celu odpowiednie narzędzia8. Dla rozwiązań HA narzędzia te umożliwiają m.in. konfigurację parametrów HA, dołączanie/odłączenia maszyny Firewall z klastra, monitorowanie obciążenia, itd. Zapewnienie stałego zarządzania systemem Firewall realizowane jest zwykle poprzez tworzenie zapasowej stacji zarządzającej i aktualizowanie jej konfiguracji. Check Point w wersji NG zaimplementował mechanizmy synchronizacji Management HA, które mogą być użyte do stworzenia takiej konfiguracji. W przypadku rozwiązań HA często stosowaną i dobrą praktyką (np. w StoneBeat FullCluster) jest dostarczanie narzędzi pozwalających na kompletne zarządzanie i monitorowanie HA z dowolnej maszyny Firewall w klastrze. Proces zarządzania uniezależnia się w ten sposób od ewentualnej niedostępności konsoli. Rozwiązania „pseudo-HA” Wdrożenie pełnowartościowej konfiguracji HA wymaga poniesienia określonych kosztów. Do wdrożenia najprostszej konfiguracji HA należy dokonać zakupu sprzętu dla dwóch maszyn Firewall, sprzętu dla stacji zarządzającej oraz licencji dla dwóch modułów zabezpieczeń, modułu zarządzania i rozwiązania HA. W instytucjach, gdzie zapewnienie stałej dostępności usług systemu informatycznego nie jest krytyczne, można zbudować konfigurację „pseudo-HA” (określaną także jako „zimna rezerwa”, Cold Standby), w której przełączanie uszkodzonej maszyny Firewall jest wykonywane ręczenie przez administratora. Do tego celu należy zainstalować zapasową maszynę Firewall z dokładnie taką samą konfiguracją jak podstawowy Firewall. Koszt wdrożenia takiego rozwiązania jest znacznie niższy. W trakcie eksploatacji wymagane jest jednak ponoszenie znacznych nakładów pracy na utrzymanie aktualnej konfiguracji zabezpieczeń na zapasowej maszynie Firewall. Można spotkać się także z inną koncepcją „pseudo-HA”, atrakcyjną cenowo, ale w rzeczywistości bardzo ryzykowną dla bezpieczeństwa systemu informatycznego. Koncepcja ta jest podobna do przedstawionej powyżej (tzn. występuje zapasowa maszyna Firewall, jest ona kopią maszyny podstawowej m.in. posiada te same licencje, maszyna zapasowa nie jest podłączona do stacji zarządzającej Firewall, aktualizację jej konfiguracji administrator wykonuje ręcznie). Różnica polega na tym, że maszyna zapasowa jest podłączona fizycznie do sieci i w razie awarii podstawowego Firewall przełączenie na zapasową maszynę (niekontrolowaną przez stację zarządzającą Firewall z uwagi na brak licencji) odbywa się automatyczne za pomocą protokołu rutingu np. VRRP. Pozornie jest to duża zaleta, ponieważ administrator nie musi robić przełączania Firewall ręcznie. Z punktu widzenia bezpieczeństwa jest jednak niedopuszczalne, aby maszyna Firewall została samodzielnie (automatycznie) włączona do sieci, jeżeli nie wiadomo jaki jest jej stan. Może zdarzyć się bowiem sytuacja, że polityka bezpieczeństwa na zapasowej maszynie Firewall będzie nieaktualna lub wyłączona. Maszyna Firewall pozbawiona poprawnie funkcjonujących zabezpieczeń może zostać zaatakowana i stanowić dogodny punkt niekontrolowanego wejścia do sieci wewnętrznej. Zagrożenie to jest realne nawet dla urządzeń Firewall Appliance. Dla przykładu, w urządzeniach Nokia IP są domyślnie zainstalowane serwery Telnet, FTP i HTTP, które mogą zostać potencjalnie wykorzystane do przejęcia kontroli nad maszyną Firewall. 8 Konsola zarządzająca Check Point SmartCenter posiada graficzne narzędzia do konfiguracji, monitorowania i raportowania pracy modułów zabezpieczeń, scentralizowanej aktualizacji oprogramowania, a także monitorowania systemu operacyjnego maszyny Firewall (m.in. obciążenie procesora, zajętość pamięci operacyjnej, wolne miejsce na dysku, stan procesów). © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 10 Analiza techniczna rozwiązań ochrony Firewall przed awariami Podsumowanie Wdrożenia systemów zaporowych Firewall w konfiguracjach klastrowych stały się powszechną praktyką. Zapewniają one ochronę przed awariami, dają swobodę wykonywania czynności administracyjnych (np. przy instalacji nowych wersji oprogramowania) oraz podwyższają wydajność zabezpieczeń. Istnieje wiele rozwiązań ochrony Firewall przed awariami. Różnią się one zasadą swojego funkcjonowania, jakością i ceną. Dokonując wyboru odpowiedniego rozwiązania HA należy zdawać sobie sprawę, że informacje podawane w materiałach marketingowych przez producentów nie zawsze są prawdziwe i nie zawsze koncentrują się na istotnych zagadnieniach. Z reguły dostawcy słabych technologicznie rozwiązań HA próbują w inny sposób ukryć braki swoich produktów. Dla przykładu, można spotkać się z informacją, że określone rozwiązanie HA jest dostarczane bezpłatnie. W rzeczywistości okazuje się jednak, że rozwiązanie to nie działa na innej platformie tylko na sprzęcie tego producenta i tak naprawdę zostało wliczone w jego cenę. Wiarygodne rozwiązanie ochrony przed awariami traktuje system zabezpieczeń Firewall w sposób całościowy (tzn. jako sprzęt, system operacyjny i oprogramowane zabezpieczeń). Wdrożenie systemu HA powinno zostać poprzedzone wykonaniem analizy i odpowiedniego projektu. ! Mariusz Stawowski © 2002 CLICO SP. Z O.O. WSZELKIE PRAWA ZASTRZEŻONE 11
