Do portu WAN urz¹dzenia Sofaware podłšczamy kabel

Transkrypt

P ROFESJONALNE S YSTEMY B EZPIECZEŃSTWA
Analiza techniczna rozwiązań ochrony Firewall przed awariami
Systemy informatyczne są powszechnie wykorzystywane do prowadzenia działalności
biznesowej. Utrzymanie ich stałej dostępność i niezawodności jest zadaniem, z którym borykają
się działy IT. Dobrą praktyką jest stosowanie oprogramowania renomowanych producentów,
markowych urządzeń i sprzętu komputerowego oraz zakupienie usług wsparcia technicznego.
W rozwiązaniach wymagających niezakłóconej pracy stosuje się urządzenia wyposażone w
komponenty redundancyjne (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 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.
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.
CLICO Sp. z o.o., Al. 3-go Maja 7, 30-063 Kraków; Tel: 12 6325166; 12 2927525; Fax: 12 6323698;
E-mail: [email protected], [email protected].; Ftp.clico.pl.; http://www.clico.pl
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).
W/w 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
Tak
2
Tak
Utrzymanie sesji w czasie
awarii
Tak
3
Tak
Skalowalność i elastyczność
Własności
1
2
3
4
5
3
Tak
3
Tak
Nie
Tak
4
Tak
Tak
Badanie otoczenia klastra
Nie
Nie
Nie
Tak
Zarządzanie i monitorowanie
Tak
5
Tak
5
Tak
5
Tak
3
5
IPSO - system operacyjny urządzeń Nokia IP oparty na FreeBSD.
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
2
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).
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.
3
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.
Rys 3) Przykład adresacji klastra HA
4
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.
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.
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 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ł VPN-1/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.
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.
5
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. Nokia 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)
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ą
informuje, 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 ograniczania. Dokumentacja „Check
Point FireWall-1 Guide NG” dokładnie opisuje sposób funkcjonowania i możliwości mechanizmu
synchronizacji.
6
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.
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
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.
7
Producenci rozwiązań HA podają, że wzrost wydajności Firewall w klastrze ActiveActive 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.
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 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).
8
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łatne. 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
O autorze:
Autor od wielu lat zawodowo zajmuje się bezpieczeństwem systemów informatycznych. Posiada w tym
zakresie liczne stopnie specjalizacji m.in. ekspert zabezpieczeń Check Point, konsultant Entrust. Jest
autorem dwóch książek i wielu publikacji w prasie informatycznej. Od 1996 roku zajmuje się produktami
zabezpieczeń Check Point.
9

Do portu WAN urz¹dzenia Sofaware podłšczamy kabel

Transkrypt

Podobne dokumenty

75,00 PLN brutto