Klaster pod ochroną

Luka w aplikacji

Atak może być także przeprowadzony bez dostępu do serwera, gdy aplikacja zawiera poważne błędy i udostępnia atakującemu cały zasób plików i danych dostępny dla klastra. Serwer udostępnia jedynie lokalne zasoby, które zawsze są oznaczone jako potencjalnie niebezpieczne. Struktura klastra utrudnia takie oznaczenie ze względu na centralizowany dostęp do plików i baz. W środowisku klastrowym łatwiej o błędy, gdyż napisanie aplikacji jest znacznie trudniejsze i czasochłonne. Definiowanie sesji na podstawie serwera, który jest w klastrze, wymaga specjalnych mechanizmów zabezpieczających. Jeżeli programista tylko "zdefiniuje" odpowiednią sesję, aplikacja może być podatna na przejęcie sesji innych użytkowników. Przejmowanie sesji nie wymaga specjalnych umiejętności i dlatego jest jedną z najniebezpieczniejszych metod ataków na rozwiązania pracujące w systemach klastrowych.

Bezpieczeństwo klastra

Kluczem do zabezpieczenia sieci klastra jest ustalenie trasy ruchu. W odróżnieniu od zwykłego serwera, w klastrowanym serwerze aplikacji można wyróżnić wiele dróg ataku. Pracują tu balancery (co najmniej dwa), które muszą mieć dostęp do serwerów aplikacji. Musimy zatem zabezpieczyć wiele tras, które powinny być oddzielone od innych zasobów. W pojedynczym serwerze trasa jest tylko jedna - od routera do serwera.

Serwery równoważące obciążenie nie powinny samodzielnie decydować o wyłączeniu jednego z nich z sieci - taką decyzję powinny podejmować routery, które przez odpowiednie testy mogą wykryć problem w warstwie sieciowej, przełączyć ruch do właściwego balancera. Należy także unikać bezpośredniej replikacji pomiędzy serwerami. Systemy replikacji oraz kopii zapasowych powinny mieć wbudowany mechanizm kontroli spójności danych (porównywanie podpisów md5 lub SHA-1), a zapis i odczyt powinien być w pełni weryfikowany. Zabezpieczy nas to przed atakiem wykorzystującym replikację danych lub kopię zapasową.

Zerowe zaufanie do balancerów

Balancery nigdy nie mają dostępu bezpośrednio do danych i aby uzyskać taki dostęp, atakujący musiałby włamać się na serwer aplikacji. Ważnym elementem dobrej polityki zabezpieczeń jest zatem brak zaufania dla ruchu pochodzącego z balancerów i traktowanie ich tak jak routerów. Balancery powinny być podłączone do serwerów aplikacji oddzielną warstwą sieciową z monitorowaniem ataków na niższych warstwach.


TOP 200