PROFESJONALNE USŁUGI BEZPIECZEŃSTWA

Transkrypt

1 PROFESJONALNE USŁUGI BEZPIECZEŃSTWA Przewodnik instalacji i konfiguracji StoneBeat FullCluster for FireWall-1 Opracował: Mariusz Stawowski Certified StoneBeat FullCluster Engineer Zapewnienie stałej dostępności usług systemu informatycznego jest ważnym kryterium bezpieczeństwa, mającym w wielu instytucjach duże znacznie, często bardziej istotne od pozostałych kryteriów: poufności, autentyczności, integralności, czy niezaprzeczalności działania. Utrzymywanie dostępności systemu w środowisku sieci lokalnej LAN zwykle koncentruje się na serwerach usług i z reguły oprócz kwestii finansowych nie stanowi dużego problemu. Zwykle sami producenci za odpowiednio wyższą cenę oferują urządzenia z komponentami redundancyjnymi, bądź też konfiguracje klastrów złożonych z wielu maszyn. Zagadnienia tworzenia systemów odpornych na awarie przyjmują zupełnie inny wymiar w środowisku sieci rozległych, takich jak Internet. Dostępność usług systemu informatycznego funkcjonującego w sieci Internet zależy od wielu różnych czynników (np. urządzeń sieciowych, łącz transmisyjnych, systemów zabezpieczeń). Z uwagi na specyfikę środowiska Internet, szczególnie istotnym elementem mającym wpływ na dostępność systemu są środki bezpieczeństwa zastosowane do ochrony serwerów usług przed niepożądanym działaniem złośliwych użytkowników Internetu, potocznie nazywanych hakerami. Podstawowym elementem zabezpieczeń sieciowych odpowiedzialnym za odpieranie tego typu ataków jest system zaporowy Firewall. Ważne jest więc, aby także Firewall posiadał środki zabezpieczające go przed awariami sprzętowymi i programowymi. Konfiguracje systemów Firewall zawierających mechanizmy ochrony przed awariami określane są terminem High Availability (HA). W konfiguracji HA system zaporowy składa się z dwóch lub więcej maszyn Firewall, które kontrolują się wzajemnie i w razie wystąpienia awarii przejmują zadania uszkodzonej maszyny bez utraty otwartych połączeń sieciowych. Wchodzące w skład HA maszyny Firewall są odpowiednio ze sobą zsynchronizowane oraz w większości konfiguracji posiadają także mechanizmy wykrywania awarii i automatycznego przejmowania zadań uszkodzonej maszyny. Synchronizacja polega na współdzieleniu przez maszyny Firewall tablic stanu połączeń, tak aby każdy Firewall wiedział jakie połączenia sieciowe przechodzą przez pozostałe maszyny i jaki jest ich stan. Operacja przejmowana roli innego Firewall (uszkodzonego lub wyłączonego) określana jest terminem Switch Over. Dostępne na rynku komercyjnym produkty Firewall zwykle oferują możliwości tworzenia systemów zaporowych odpornych na awarie. Konfiguracje HA różnych producentów często różnią pod względem funkcjonalności i skuteczności. Funkcjonalność HA określana jest poprzez rodzaje połączeń, które mogą zostać zabezpieczone (np. zwykłe połączenia TCP/IP, połączenia poddane translacji adresów NAT, sesje zaszyfrowane VPN) oraz dodatkowe usługi, jak równoważenie obciążenia sieci. Skuteczność HA zależy w zasadniczym zakresie od rodzaju i jakości testów wykonywanych przez maszyny Firewall (testów identyfikujących awarie) oraz skuteczności wykonywania operacji Switch Over. CLICO Sp. z o.o., Al. 3-go Maja 7, Kraków; Tel: ; ; Fax: ; support@clico.pl, orders@clico.pl.; Ftp.clico.pl.;

2 Jednym z najbardziej renomowanych produktów HA na rynku jest StoneBeat FullCluster (SBFC) firmy StoneSoft. Umożliwia on tworzenie systemów zabezpieczeń Firewall w konfiguracji Load Balancing lub Hot Stand-by. Do podstawowych własności SBFC można zaliczyć: zabezpieczenie systemu zaporowego Check Point VPN-1/FireWall-1 przed awariami, dynamiczne równoważenie obciążenia maszyn Firewall w klastrze HA, skanowalność w zakresie tworzenie i zarządzania klastra HA (tzn. maszyny Firewall mogą być dodawane lub usuwane z klastra bez konieczność zatrzymywania pracy całości; maksymalnie można zestawić 32 maszyn). SBFC należy do licznej rodziny produktów HA, m.in.: FullCluster - ochrona przed awariami dla systemów zabezpieczeń Check Point VPN-1/FireWall-1, Microsoft ISA Server, NAI Gauntlet i Symantec (Axent) Raptor, SecurityCluster ochrona przed awariami dla serwerów zabezpieczeń (m.in. Trend Micro InterScan VirusWall, Aladdin esafe, ISS RealSecure Network Sensor), WebCluster - ochrona przed awariami dla serwerów Web i e-commerce, CacheCluster - ochrona przed awariami dla serwerów Web Proxy (Cache), DNSCluster - ochrona przed awariami dla serwerów DNS, ServerCluster - ochrona przed awariami dla serwerów aplikacji, StoneGate - system Firewall i VPN z wbudowanymi zabezpieczeniami przed awariami HA oraz ochroną przed awariami łączy do Internetu i chronionych serwerów. CLICO,

3 1. Przygotowanie maszyn Firewall w klastrze SBFC Przed instalacją VPN-1/FireWall-1 oraz SBFC wymagane jest odpowiednie przygotowanie systemu operacyjnego maszyn Firewall. Przede wszystkim dotyczy to usunięcia wszystkich protokołów i aplikacji sieciowych poza TCP/IP. Dla przykładu, w systemie Windows NT nie powinno być NetBIOS, ani też narządzi diagnostycznych do kart sieciowych typu 3Com drmon SmartAgent. Zalecane jest, aby z aplikacji sieciowych Windows NT pozostał jedynie agent SNMP. Procedura przygotowania systemów operacyjnych Windows NT i SUN Solaris jako platformy Firewall została przedstawiona w załączniku. Internet ruter hub IP(2): virtual IP: IP(2): virtual IP: nt6 IP(3): virtual IP: IP(3): virtual IP: nt3 IP(1): hostname address IP(1): hostname address hub switch IP: Sieć chroniona Management CLICO,

4 Warunkiem poprawnej pracy klastra SBFC jest odpowiednie skonfigurowanie parametrów sieciowych: Adres IP interfejsu zarządzania Firewall ustalamy jako podstawowy adres maszyny Firewall Gateway (tzn. hostname address). Jest to jeden z interfejsów CNIC. Do zestawienia połączeń sieciowych możemy wykorzystać przełączniki (switch), bądź zwykłe koncentratory (hub). Uwaga: Zestawiając maszyny Firewall w sieci należy zadbać, aby pakiety przychodzące na interfejsy ONIC z Internetu, DMZ i sieci chronionych docierały do wszystkich maszyn w klastrze. W przypadku stosowania przełączników zwykle wymagane jest skonfigurowanie na tych interfejsach multicast-owych adresów MAC. Procedura przygotowania maszyny Firewall zależy od systemu operacyjnego: SUN Solaris Konfigurujemy DNS w pliku /etc/hosts, wpisując nazwy maszyn Firewall oraz adresy IP ich interfejsów ID CNIC; w pliku /etc/nsswitch.conf modyfikujemy linię hosts: files dns. Konfigurujemy interfejsy Firewall w plikach /etc/hostname.x, wpisując odpowiednie adresy IP lub nazwy DNS (gdzie X odpowiada nazwie /dev/ karty sieciowej). Dedykowane adresy IP przypisujemy fizycznym interfejsom ONIC (np. hostname.qfe0). Klastrowe adresy IP przypisujemy wirtualnym interfejsom ONIC (np. hostname.qfe0:1). Uwaga: Przed ustawieniem klastrowych adresów IP należy odłączyć interfejsy ONIC z sieci (dotyczy także Windows NT). Tworzymy startowy skrypt konfiguracji rutingu (np. /etc/rc3.d/s99staticroutes), gdzie usuwamy ustawienia rutingu do przyległych sieci poprzez klastrowe adresy IP (np. route delete net ). Ruting powinien odbywać się poprzez dedykowane adresy IP. W definicji ARP maszyn Firewall (np. /etc/rc2.d/s99addarp) wprowadzamy odpowiednie statyczne wpisy ARP dla adresu rutera oraz klastrowych adresów Firewall: (tzn. arp s X.X.X.X <MAC>). CLICO,

5 Windows NT Instalujemy agenta SNMP. W konfiguracji interfejsów ONIC (ustawienia Advanced) dedykowane adresy IP wpisujemy jako pierwsze. Adresy IP klastrowe wpisujemy jako drugie. Konfigurujemy DNS w pliku winnt\system32\drivers\etc\hosts, wpisując nazwy maszyn Firewall oraz adresy IP ich interfejsów ID CNIC. Weryfikujemy nazwę komputera w ustawieniach Control Panel -> Network -> Protocols -> TCP/IP -> DNS. Konfiguracja ARP jest podobna jak w Solaris. Odbywa się jednak dopiero po zainstalowaniu VPN-1/FireWall-1 za pomocą pliku $FWDIR/state/local.arp, gdzie w kolejnych liniach wpisywane są pary <IP> <MAC> (np :02:03:04:05:06). CLICO,

6 2. Instalacja i wstępna konfiguracja VPN-1/FireWall-1 Instalujemy i wstępnie konfigurujemy oprogramowanie VPN-1/FireWall-1 na maszynach Firewall i stacji zarządzającej: Licencje dla VPN-1/FireWall-1 Module generujemy na adres IP zewnętrznego interfejsu ONIC maszyn Firewall Gateway. Licencje dla SBFC generujemy na adres podstawowy Firewall Gateway (tzn. adres IP interfejsu ID CNIC). Obiekty Firewall Gateway w polityce bezpieczeństwa definiujemy podając adres IP interfejsu ID CNIC (tzn. hostname address). Powinien to być podstawowy adres IP maszyny Firewall Gateway. Adres ten można łatwo ustalić wykonując polecenie Ping z nazwą komputera Firewall. Zalecane jest, aby maszyny Firewall w klastrze SBFC zostały zainstalowane na tej samej platformie systemu operacyjnego i posiadały tą samą wersję oprogramowania VPN-1/FireWall-1 (version/sp). Stacja zarządzająca powinna posiadać tą samą wersję oprogramowania VPN- 1/FireWall-1 (version/sp) co maszyny Firewall w klastrze. W definicji obiektów Firewall dla poszczególnych maszyn w klastrze SBFC dodajemy interfejsy wirtualne w formie <nazwa interfejsu fizycznego>_1. CLICO,

7 Tworzymy obiekt Gateway Cluster z adresem IP, odpowiadającym wirtualnemu adresowi interfejsu zewnętrznego maszyn Firewall. Następnie maszyny Firewall dodajemy do stworzonego obiektu Gateway Cluster. CLICO,

8 3. Ustawienie synchronizacji modułów VPN-1/FireWall-1 Moduły VPN-1/FireWall-1 w klastrze SBFC powinny zostać ze sobą zsynchronizowane w zakresie aktualizacji wewnętrznych tabel stanu. Wszystkie maszyny Firewall w klastrze powinny cały czas wiedzieć do dzieje się na pozostałych maszynach, tak aby w razie awarii jednej z maszyn mogły przejąć połączenia przez nią przechodzące (m.in. sesje IPSec/IKE). Dla przykładu konfiguracja synchronizacji dwóch modułów VPN-1/FireWall-1 odbywa się w następujący sposób: Synchronizacja maszyn Firewall odbywa się z użyciem podstawowych (unikalnych) adresów IP za pomocą protokołu FW1 (256/tcp). Na pierwszej maszynie Firewall tworzymy plik $FWDIR/conf/sync.conf i zapisujemy w nim adres IP lub nazwę DNS drugiej maszyny Firewall. Na drugiej maszynie Firewall tworzymy plik $FWDIR/conf/sync.conf i zapisujemy w nim adres IP lub nazwę DNS pierwszej maszyny Firewall. Na pierwszej maszynie Firewall za pomocą polecenia "fw putkey" uwierzytelniamy kanał komunikacji z drugą maszyną Firewall. Na drugiej maszynie Firewall za pomocą polecenia "fw putkey" uwierzytelniamy kanał komunikacji z pierwszą maszyną Firewall. Restartujemy moduły VPN-1/FireWall-1 na obu maszynach Firewall (fwstop/fwstart). Synchronizacja stanu modułów VPN-1/FireWall-1 odbywa się w odstępach czasowych 100 milisekund. Zalecane jest, aby wszystkie maszyny klastra SBFC zostały także zsynchronizowane czasowo (tzn. czas i data systemowa, strefa czasowa). Można do tego celu użyć narzędzia dostępne w systemie operacyjnym, np.: timeserv z Windows NT Resorce Kit (ewentualnie polecenie net time z odwołaniem do istniejącego serwera czasu w sieci), xntpd w SUN Solaris. CLICO,

9 4. Instalacja sterowników, modułów i narzędzi SBFC 4.1 Instalacja w systemie SUN Solaris SBFC zastępuje interfejsy maszyny Firewall swoimi wirtualnymi interfejsami, widzianymi w systemie operacyjnym pod nazwą SBIF. Przed instalacją SBFC na maszynach Firewall z systemem operacyjnym SUN Solaris wymagane jest dodanie tych interfejsów do listy interfejsów akceptowanych przez VPN-1/FireWall-1: w pliku /etc/fw.boot/ifdev dopisujemy linię sbif accept Instalując SBFC należy wybrać komponenty odpowiednie dla maszyn Firewall i stacji zarządzającej. W systemie Solaris na maszynie Firewall instalujemy zwykle wszystkie komponenty, tzn.: SBFCbase zestaw narzędzi zarządzania, SBFCdrv sterowniki HA, SBFCmod moduł HA, SBFCsnmp agent SNMP wraz z narzędziami, SBFCconf moduł zarządzania poprzez Web, SBFCgui moduł zarządzania poprzez GUI. Zdalna stacja zarządzająca SBFC, która służy także do administracji Check Point VPN-1/FireWall-1 najczęściej jest na platformie Windows NT. Po zainstalowaniu SBFC należy ustawić zmienną środowiskową SBFCHOME oraz ścieżkę PATH. Dla przykładu, dla powłok sh, ksh i bash w pliku.profile wpisujemy: SBFCHOME=/opt/fullcluster export SBFCHOME PATH=${PATH}:${SBFCHOME}/bin export PATH CLICO,

10 4.2 Instalacja w systemie Windows NT Instalację SBFC na maszynach Firewall z systemem operacyjnym Windows NT rozpoczynamy od zainstalowania sterownika StoneBeat Driver: Control Panel -> Network -> Protocols -> Add -> Have disk -> <CD>\FireWall-1\nt\Module Po zainstalowaniu sterowników SBFC i przeładowaniu maszyny Firewall w systemie operacyjnym pojawią się wirtualne interfejsy sieciowe, widziane pod nazwą SBIF. Konfiguracja rzeczywistych interfejsów zostaje skopiowana na interfejsy wirtualne. CLICO,

11 Pierwotna konfiguracja interfejsów sieciowych maszyny Firewall Ethernet adapter El90x1: Description: 3Com EtherLink PCI Physical Address: DF-D1-29 IP Address: Ethernet adapter El90x3: Description: 3Com EtherLink PCI Physical Address: F7-87-E3 IP Address: IP Address: Ethernet adapter El90x2: Description: 3Com EtherLink PCI Physical Address: B-C7-A3-AE IP Address: IP Address: Default Gateway: Konfiguracja interfejsów sieciowych po instalacji sterownika SBFC Ethernet adapter SBIfMP4: Description: SBIfMP4 3Com EtherLink PCI Physical Address: B-C7-A3-AE IP Address: IP Address: Default Gateway: Ethernet adapter SBIfMP6: Description: SBIfMP6 3Com EtherLink PCI Physical Address: DF-D1-29 IP Address: Ethernet adapter SBIfMP5: Description: SBIfMP5 3Com EtherLink PCI Physical Address: F7-87-E3 IP Address: IP Address: Po zainstalowaniu sterowników StoneBeat Driver i przeładowaniu maszyny Firewall należy zainstalować pozostałe komponenty SBFC: Module moduł HA oraz rozszerzenia agenta SNMP, Control Tools narzędzia zarządzania z linii komend, Configuration Programs konsola zarządzania GUI i Web. Dalsza konfiguracja SBFC może odbywać się za pomocą konsoli GUI lub Web. Do uruchomienia klastra wymagane jest ustawienie: kluczy i certyfikatów SSL, parametrów modułu SBFC, interfejsów maszyn w klastrze SBFC, klucza Passphrase PEM modułu SBFC (hasło dostępu do prywatnych kluczy kryptograficznych modułu SBFC wykorzystywane w czasie startu systemu, używane także przez konsolę z linii komend), Licencji produktu. Podstawowa konfiguracja modułu SBFC zapisywana jest w pliku node.conf. Uwaga: Po zainstalowaniu SBFC należy uaktualnić nazwy interfejsów sieciowych w definicji obiektów VPN-1/FireWall-1. CLICO,

12 5. Klucze i certyfikaty SSL Komunikacja pomiędzy modułami SBFC oraz konsolą GUI i konsolą z linii komend jest zabezpieczona kryptograficznie za pomocą protokołu SSL. Generowanie kluczy (szyfrowania, uwierzytelniania) oraz certyfikatów cyfrowych dla wszystkich elementów klastra SBFC (tzn. modułów SBFC, konsoli GUI, konsoli z linii komend) odbywa się zwykle na jednej stacji, skąd po ich wygenerowaniu odpowiednie pliki są przekopiowywane. Można do tego celu użyć narzędzia GUI lub Web. Generowanie kluczy i certyfikatów rozpoczynamy od Urzędu Certyfikacji (CA). Następnie generujemy klucze i certyfikaty dla konsoli GUI, konsoli z linii komend oraz poszczególnych modułów SBFC. CLICO,

13 Klucze i certyfikaty SSL generowane dla poszczególnych elementów klastra należy na bieżąco kopiować do katalogów Back-up tak, aby nie zostały nadpisane przez klucze i certyfikaty tworzone dla kolejnych elementów. Po wygenerowaniu całości określone pliki należy przekopiować do odpowiednich elementów klastra SBFC: 1. Klucze i certyfikaty dla konsoli zarządzania GUI zapisujemy na stacji zarządzającej jako: etc/<nazwa klastra>/guikey.pem etc/<nazwa klastra>/guicerts.pem 2. Klucze i certyfikaty dla konsoli z linii komend zapisujemy na stacji zarządzającej jako: etc/sbfckey.pem etc/sbfccert.pem 3. Plik clients, zawierający listę nazw CN (common name) certyfikatów klientów zarządzania, zapisujemy w katalogu etc na wszystkich maszynach Firewall w klastrze. 4. Certyfikat Urzędu Certyfikacji cacert.pem zapisujemy do katalogu etc na każdej maszynie Firewall oraz stacji zarządzającej. 5. Plik z parametrami algorytmu Diffiego-Hellmana dhparams.pem zapisujemy do katalogu etc na każdej maszynie Firewall oraz stacji zarządzającej. 6. Klucze i certyfikaty modułu SBFC zapisujemy na maszynie Firewall jako: etc/modulekey.pem etc/modulecert.pem SBFC obsługuje certyfikaty cyfrowe utworzone za pomocą algorytmów DSA i RSA. Zawarty w SBFC program do tworzenia certyfikatów używa algorytmu DSA. Generowane klucze i certyfikaty SSL są zapisywane w formacie Private Enhanced Mail (PEM). Klucze prywatne są zabezpieczone za pomocą haseł PEM Passphrase. CLICO,

14 6. Konfiguracja parametrów modułu SBFC Konfiguracja maszyn Firewall w klastrze SBFC może odbywać się z konsoli GUI lub Web. Za pomocą konsoli Web istnieje także możliwość skonfigurowania całości klastra z jednej maszyny. Konfiguracja modułu (węzła) SBFC obejmuje następujące parametry: Node ID unikalny identyfikator maszyny Firewall w klastrze SBFC. Cluster ID identyfikator klastra SBFC; powinien być taki sam na wszystkich maszynach w klastrze. Failover-time czas braku odpowiedzi z modułu SBFC po upływie, którego maszyna jest uznawana za uszkodzoną i rozpoczyna się jej odłączanie z klastra; w razie nie wpisania wartości parametru zostanie przyjęta wartość domyślna. Capacity wydajność maszyny Firewall ustalana za pomocą specjalnego programu (benchmark). Protocol Message Period częstość, z jaką moduł SBFC wysyła komunikaty Heartbeat; w razie nie wpisania wartości parametru zostanie przyjęta wartość domyślna. Load Measurement Interval częstość, z jaką moduł SBFC sprawdza obciążenie maszyny Firewall; zwykle przyjmuje się wartość 15 sekund. Node Priority parametr przewidziany do przyszłych zastosowań. Cluster Standby Mode tryb pracy klastra: Load Balancing lub Hot Stand-by. Node Start-up Mode stan, jaki moduł SBFC przyjmuje po restarcie systemu; w klastrze z Load Balancing zwykle ustala się stand-by tak, aby moduł po wykonaniu testów kontrolnych automatycznie przeszedł do stanu on-line. CLICO,

15 7. Konfiguracja interfejsów sieciowych SBFC Interfejsy maszyn Firewall w klastrze SBFC konfigurowane są w zależności od pełnionej roli (ONIC, CNIC, Heartbeat) oraz sposobu podłączenia do sieci (hub, switch). Adres interfejsu ID CNIC ustalamy jako adres zarządzania. Konfiguracja interfejsu CNIC, poprzez który odbywa się także komunikacja Heartbeat. Konfiguracja interfejsu ONIC podłączonego do koncentratora (hub). Konfiguracja interfejsu ONIC podłączonego do przełącznika. CLICO,

16 8. Konfiguracja filtru równoważenia obciążenia Konfiguracja filtru równoważenia obciążenia maszyn Firewall w klastrze SBFC odbywa się w pliku filter.conf. Każdy z węzłów w klastrze SBFC powinien posiadać takie same ustawienia filtru. W przeciwnym przypadku w klastrze komunikacja sieciowa może odbywać się w sposób niepoprawny (np. ruting asymetryczny). Ustawienia filtra wymagane są m.in. dla następujących usług i protokołów: FTP, NAT, VPN. Przykładowe ustawienia: filter-mode = dynamic Połączenia w klastrze są dynamicznie rozdzielane pomiędzy maszyny Firewall w razie gdy jedna z maszyn jest przeciążona. Jest to ustawienie domyślne. filter-mode = static Połączenia w klastrze są dynamicznie rozdzielane pomiędzy maszyny Firewall tylko w razie gdy jedna z maszyn przechodzi ze stanu online na offline. node = all designated-ip = netmask Węzeł 1 obsługuje pakiety z/do sieci , gdy jest w stanie online. node = 1 pass-ip = netmask node = 2 filter-ip = netmask Węzeł 1 obsługuje pakiety z/do sieci , gdy jest w stanie online. preferred-ip = netmask Węzeł 1 obsługuje pakiety z/do sieci , gdy jest w stanie online. Zalecane ustawienie dla VPN i NAT Pool. tunnel = netmask Tunel VPN przebiega z IP: do Odległa domena VPN to sieć IP: / ignore-port = Ignorowanie portów TCP 20 i 21 w czasie równoważenia obciążenia tak, aby połączenia kontrolne oraz danych w sesji FTP przechodziły przez ten sam węzeł. CLICO,

17 static-nat-ip = netmask static-nat-ip = netmask Ustawienia wymagane przez statyczny NAT, gdzie IP: to adresy publiczne, zaś IP: to adresy prywatne. hide-nat-ip = netmask hide-nat-ip = Ustawienia wymagane przez dynamiczny NAT, gdzie IP: to adres publiczny, zaś IP: to adresy prywatne. Zdefiniowane na FireWall-1 reguły translacji NAT można także odczytać za pomocą opcji w GUI SBFC i zapisać do pliku filter-nat.conf. 9. Testy stanu maszyn Firewall w klastrze SBFC Awarie sprzętowe maszyn Firewall wykrywane są przez protokół heartbeat. Protokół heartbeat działa na dedykowanych interfejsach maszyn Firewall jako multicast Ethernet. Zmiany adresów MAC na multicastowe dokonuje moduł SBFC (tzn. nie jest to konfigurowane w systemie operacyjnym). Wykrywanie innych nieprawidłowości odbywa się poprzez testy kontrolne zdefiniowane w pliku checklist, np.: multiping 5 online offline multiping <adres IP> firewall-module-on 3 online offline 1 1 fw-module-running virtual memory 120 online offline 1 1 virtual-memory ext_onic_up 60 online alert 1 1 networkinterface-up sbif0 system log 1000 online alert 1 1 systemlog /var/adm 3000 filesystem 1200 online offline 1 1 filesystem /var CLICO,

18 10. Aktywowanie zmian konfiguracji Aktywowanie zmian konfiguracji SBFC odbywa się za pomocą poniższej sekwencji poleceń: #sbfc sbfc>reconfigure all sbfc>restart all /* sbfc abortconfig odwołanie komendy sbfc reconfigure */ 11. Skrypty zmiany stanu i alarmowe W SBFC występują dwa skrypty uruchamiane w czasie zmiany stanu węzłów: zmiana stanu na online: online.sh (Unix), online.bat (NT), zmiana stanu na offline: offline.sh (Unix), offline.bat (NT). W/w skrypty należy utworzyć i zapisać w katalogu $SBFCHOME/etc. Dla przykładu można za ich pomocą informować administratorów o zmianach stanu w klastrze SBFC poprzez . #!/bin/sh /usr/bin/mailx s SBFC root <<EOF Maszyna FW o nazwie /bin/hostname przyjela stan OFFLINE o /bin/date EOF Oprócz w/w skryptów można używać także skryptów alarmowych alert.sh (Unix) lub alert.bat (NT) jako reakcji na niepomyślne wykonanie testów kontrolnych SBFC. CLICO,

19 12. Zarządzanie i monitorowanie klastra SBFC Zarządzanie i monitorowanie SBFC odbywa się za pomocą interfejsu StoneBeat GUI (sbgui), Windows GUI (tylko na platformie Windows NT), interfejsu Web ( oraz z linii komend (sbfcconfig). Wstępna konfiguracja całego klastra SBFC sprawnie odbywa się z jednej maszyny za pomocą interfejsu Web ( Na wszystkich maszynach należy wcześniej ustalać adresy IP do zarządzania. Stan węzłów w klastrze SBFC po restarcie zależy od ustawień Start-up: stand-by po pozytywnym zakończeniu testów przechodzi w stan online, offline bez testów przechodzi w stan offline. Administrator SBFC może z linii komend zmienić stan węzła: sbfc online <numer węzła> sbfc offline <numer węzła> sbfc forceoffline <numer węzła> - zmienia stan na offline nawet, gdy jest to ostatni sprawny węzeł Po awarii węzła administrator SBFC powinien ręcznie zmienić stan naprawionego węzła z offline na online. Administrator SBFC może z linii komend zablokować węzeł w określonym stanie: sbfc lockonline <numer węzła> sbfc lockoffline <numer węzła> Zachowanie węzła po restarcie maszyny Firewall zależy od stanu, w jakim został zablokowany tzn.: offline locked pozostaje w tym stanie, online locked odblokowuje się. Stan węzłów w klastrze SBFC odczytuje się za pomocą komend: sbfc status sbfc getinfo CLICO,