Jednym ze sposobów obsługi dużego obciążenia, przy zachowaniu wysokiej dostępności usługi, jest wykorzystanie klastrów serwerów webowych. W zależności od producenta, mamy do wyboru różnorodne konfiguracje i funkcjonalności. Najpopularniejszy na rynku jest darmowy LVS (linux virtual server) i mod_proxy dostarczony do serwera Apache, połączony z rozwiązaniem heartbeat. Chociaż dokumentacja zawiera szereg użytecznych informacji i przykładów konfiguracji, nie informuje o zagrożeniach związanych z wdrożeniem tej technologii.

Klastry webowe, to nic innego jak strona internetowa obsługiwana przez więcej niż jeden serwer. Struktura składa się co najmniej z dwóch serwerów rozdzielających ruch (load balancery) i serwerów aplikacyjnych, których ilość zależy od obciążenia aplikacji. Zadaniem load balancerów jest rozdzielenie ruchu przychodzącego na serwery aplikacyjne zależnie od ich obciążenia. Wykorzystanie klastra webowego zapewni firmie wysoką wydajność i dostępność serwisu - awaria pojedynczego serwera nie powoduje załamania obsługi całego serwisu. Jest to główny argument przemawiający za wdrożeniem architektury klastrowej.

Atak na balancery

Najbardziej narażone na atak są balancery, nawet jeśli są tylko serwerami pośredniczącymi, gdyż muszą udostępniać taką samą usługę, jak serwery aplikacji, by sprawnie przekazywać ruch (w naszym przypadku serwer Web). Niebezpieczeństwo związane z eksploatacją serwerów klastrowych polega na tym, że udane włamanie na jeden serwer daje włamywaczowi szansę podsłuchu całego ruchu kierowanego do serwerów aplikacyjnych. Do tego celu wystarczy wykorzystanie mechanizmów równoważenia obciążenia.

Aby sprawnie określić, który z balancerów jest włączony, oba urządzenia muszą się ze sobą komunikować za pomocą systemu heartbeat. Większość rozwiązań komercyjnych i darmowych sprawdza stan balancera poprzez warstwę sieciową, zatem wystarczy wyłączenie interfejsu sieciowego odpowiedzialnego za komunikację z drugim balancerem i przejęty serwer stanie się aktywny. W przypadku rozwiązań bardziej skomplikowanych, wystarczy wysłać komendę żądającą odłączenia drugiego klastra od sieci. Kiedy drugi balancer zostanie odłączony, cały ruch jest rozdzielany przez jedną maszynę. Po przełączeniu całego ruchu na przejęty serwer, można go dowolnie przechwytywać.

Atak na serwery aplikacji

Klastrowane serwery aplikacyjne są traktowane przez wielu specjalistów ds. bezpieczeństwa jak normalne serwery w jednej sieci. Jest to błędne i niebezpieczne założenie. Serwery aplikacji w klastrze są bardziej narażone na ataki, co wynika ze specyfiki systemów klastrowych, gdzie różne serwery aplikacji muszą mieć dostęp do tych samych danych. Do tego celu wykorzystuje się macierz, która udostępnia te same pliki dla systemów, lub rozwiązanie replikacji, gdzie dane zostają przekopiowane z jednego serwera na drugi. Atak przeciwko takiemu środowisku można przeprowadzić nie tylko zewnętrznie, ale także od wewnątrz.

Wgranie złośliwego kodu na dowolny z systemów w klastrze może powodować infekcję wszystkich maszyn klastra, ale nie zawsze atak jest przeprowadzany tą drogą, gdyż może pozostawić widoczne ślady włamania. Włamywacze mogą jednak próbować zarazić system kopii zapasowych. Atak może polegać na instalacji odpowiednich skryptów lub modyfikacji oprogramowania w taki sposób, by utrudnić wykrycie zmian i zapewnić samoczynną, ponowną instalację kodu w przypadku odtworzenia systemu kopii bezpieczeństwa. Po zarażeniu systemu backupowego, wystarczy tylko uszkodzić serwer, by wymagana była reinstalacja i przywrócenie plików.