Wirtualne bezpieczeństwo

Rozwiązania wirtualizacyjne, wbrew temu co mówią dostawcy, nie zapewniają większego bezpieczeństwa, a co najwyżej większą dostępność systemów i aplikacji.

Rozwiązania wirtualizacyjne, wbrew temu co mówią dostawcy, nie zapewniają większego bezpieczeństwa, a co najwyżej większą dostępność systemów i aplikacji.

Serwery wirtualne pod różnymi wcieleniami są wykorzystywane od wielu lat. Początkowo wirtualne środowiska miały jedynie zwiększać dostępność usług i aplikacji, ale okazało się, że można je stosować w charakterze zabezpieczeń antywłamaniowych. Zwirtualizowane serwery WWW lub poczty były bezpieczne dla reszty systemów działających w sieci nawet po włamaniu, włamywacz miał bowiem dostęp tylko do wydzielonej, wirtualnej przestrzeni, niemającej styku z innymi, potencjalnie poufnymi danymi czy systemami o krytycznym znaczeniu.

Projektanci środowisk poszli jednak dalej. Skoro można stworzyć bezpieczne środowisko aplikacyjne, można przecież zwirtualizować cały sprzęt i system operacyjny. W tym wypadku w pierwszym rzędzie miała na celu wspólne zarządzanie wieloma systemami wirtualnymi, co miało spowodować obniżenie kosztów wdrażania i zarządzania. Niejako przy okazji mowa była także o dalszym zwiększeniu bezpieczeństwa, ale czy obietnica ta została spełniona?

Bezpieczeństwo wirtualne

Rozwiązania wirtualizacyjne dla serwerów można podzielić na dwie grupy: maszyny wirtualne i przestrzenie wirtualne. Do tych pierwszych możemy zaliczyć VMware ESX Server i Microsoft Virtual Server. Do grupy przestrzeni wirtualnych należą m.in. Vserver, chroot (Linux), BSD Jail, Solaris Zones.

Podstawowym warunkiem bezpieczeństwa, który powinny spełniać produkty wirtualizacyjne, jest absolutna "szczelność", tj. niemożność bezpośredniego komunikowania się procesu uruchomionego w ramach maszyny wirtualnej z procesami głównego systemu operacyjnego. Oznacza to, że użytkownik, któremu udało się np. złamać zabezpieczenia witryny WWW lub serwera pocztowego, nie ma prawa uzyskać dostępu do danych, które są poza nim. Jeżeli produkt nie spełni tej zasady, wykorzystanie wirtualnego środowiska w charakterze środka bezpieczeństwa nie ma żadnego merytorycznego sensu.

Niestety, większość zabezpieczeń maszyn wirtualnych da się ominąć - to w końcu tylko programy. Nie bez znaczenia jest także i to, że nie względy bezpieczeństwa były najważniejsze podczas ich projektowania, lecz raczej dostępność lub wygoda zarządzania. Opublikowany ostatnio problem z produktami VMware (kod: ACSSEC-2005-11-25 - 0x1) dotyczy luki znalezionej w pliku vmnat.exe. Umożliwia ona uzyskanie dostępu do całego systemu poprzez technikę zdalnego przepełnienia sterty, co dowodzi, że metody omijania zabezpieczeń takich produktów cały czas są badane, a więc, jak można mniemać, także wykorzystywane.

Ale słaby model bezpieczeństwa rozwiązań wirtualizacyjnych nie jest odkryciem ostatnich miesięcy. Środowiska przeznaczone dla systemów Linux/Unix miały ten problem od dawna. Chroot, najbardziej popularny program do wirtualizacji serwerów WWW, był w przeszłości "łamany" dziesiątki razy. Pojawiały się nawet robaki internetowe zawierające spreparowany kod maszynowy pozwalający "uwolnić" wirusa ze środowiska wirtualnego i zainfekować główny system. Także inne odmiany środowisk wirtualnych bywały celem hakerów, wystarczy przypomnieć problemy z unixowym środowiskiem Jail (BSD) czy implementację wirtualnej maszyny Java Microsoftu.

Anomalie wieku dziecięcego

Jeśli dostawcy przekonują do zakupu rozwiązań wirtualizacyjnych, posługując się argumentacją o większym bezpieczeństwie, mogą mieć na myśli co najwyżej bezpieczeństwo przed prostymi atakami albo niedouczonymi hakerami-amatorami. Jeśli o takie bezpieczeństwo chodzi kupującemu, nie ma sprawy. Jeśli jednak kupujący liczy, że środowisko wirtualne uwolni go od wszelkich trosk związanych z bezpieczeństwem danych, może się zdziwić, że jednak tak nie jest.

Wdrożenie serwera wirtualnego zamiast zakupu serwera fizycznego na pewno jest tańsze, ale trudno obronić pogląd, że jest bezpieczniejsze. Przełamanie zabezpieczeń maszyny wirtualnej pozwala sięgnąć do systemu operacyjnego - kontrola nad nim daje nieograniczone możliwości manipulowania pozostałymi maszynami wirtualnymi i działającymi w nich systemami i aplikacjami. Nawet jeśli systemy wirtualne są zabezpieczone hasłami, przepełnienie bufora z poziomu systemu podstawowego czyni systemy wirtualne bezbronnymi.

Gdyby serwery wirtualne działały na oddzielnych serwerach, włamywacz miałby utrudnione zadanie, ponieważ musiałby dodatkowo pokonać zabezpieczenia na poziomie sieci. W tym świetle wydaje się, że kluczowe nadal jest porządne zabezpieczenie systemu, a nie uczynienie go wirtualnym. Jeśli system działa w ramach maszyny wirtualnej, lecz jest niezbyt dobrze zabezpieczony, staje się zalążkiem zagrożeń.

Wirtualny, nie magiczny

Ale i same maszyny wirtualne muszą z biegiem czasu ewoluować. Na razie, jak niegdyś w przypadku chroot, systemy wirtualne na Windows to rzadkość. Mniejsze prawdopodobieństwo włamania do takiego systemu wynika wyłącznie z faktu, że włamywacz nie wie, że próbuje zdobyć kontrolę nad systemem wirtualnym.

Dla porównania, aktualnie większość serwerów apache/qmail lub SQL jest obecnie instalowana w środowiskach chroot, większość dystrybucji linuxowych proponuje pakiety serwerów WWW z domyślnie instalującym się środowiskiem wirtualnym. Chroot stał się standardem i włamywacze o tym wiedzą, co zupełnie zmienia poziom zagrożenia. Hakerzy przygotowują się do tego, że system, do którego właśnie weszli, może nie mieć bezpośredniego dostępu do sprzętu i że najpierw trzeba będzie złamać zabezpieczenia maszyny wirtualnej. Tylko patrzeć, jak to samo będzie dotyczyć zwirtualizowanych systemów Windows, czy to za pomocą rozwiązań Microsoft, czy VMware.

Z punktu widzenia bezpieczeństwa systemu wirtualizacja mimo wszystko może być pomocna, np. na potrzeby monitorowania i logowania zdarzeń. Jeśli włamywacz nie może zatrzeć za sobą śladów, jego skłonność do włamania drastycznie maleje. Zanim haker przedostanie się przez zabezpieczenia maszyny wirtualnej i skasuje logi zapisywane przez system główny, mogą one zostać wyeksportowane na inny serwer fizyczny.

Dobrze zaplanowana cykliczna wymiana logów z systemami zewnętrznymi daje kilka minut przewagi nad hakerami. Wiele firm, ignoruje takie rozwiązania uznając, że środowisko wirtualne zapewnia im totalne bezpieczeństwo. Nic bardziej mylnego. Wirtualizacja jest może terminem sugerującym oderwanie od rzeczywistości, ale nie jest to z pewnością magia, tylko wciąż kod pisany przez człowieka skłonnego do popełniania błędu co ileś tam linii.

Wirtualna pielęgnacja

Wirtualny system w uproszczeniu działa na takich samych zasadach jak normalny system i należy go tak samo pielęgnować. Użytkownicy nie całkiem świadomi, z czym mają do czynienia, uznają nazbyt często, że system wirtualny jest z natury bezpieczny, więc w razie wykrycia luki wystarczy zabezpieczyć system podstawowy. Inny grzech to zabezpieczanie systemu głównego podczas gdy to serwery wirtualne są oknami na świat. Nie chcą być może przyjąć do wiadomości, że drugi, trzeci, czy czwarty serwer na tym samym komputerze wymaga takiej samej uwagi, co serwer główny. Nawet przy dużej automatyzacji nadzór człowieka jest potrzebny, ponieważ po drugiej stronie barykady również może stać człowiek.

VMware Player - niebezpieczna zabawka

Przygotowywany obecnie przez VMware pakiet VMware Player powstaje głównie z myślą o użytkownikach, którzy chcą korzystać z Internetu bez obawy narażania podstawowego systemu operacyjnego na zagrożenia z Internetu. Popularność na pewno będzie duża, ale rzeczywiste bezpieczeństwo korzystania z takiego środowiska będzie naprawdę... bardzo wirtualne. Może się okazać, że ostatecznie wykorzystanie wirtualizacji przez tzw. zwykłych użytkowników przyniesie skutek odwrotny do zamierzonego. Jeśli dajmy na to, VMware Player zostanie wykorzystane do korzystania z banku internetowego, przełamanie sesji SSL lub atak typu man-in-the-middle są tak samo prawdopodobne i przebiegają tak samo, jak w przypadku korzystania z normalnego systemu. Przeglądarka IE w środowisku wirtualnym będzie zawierać te same błędy, co zawsze. Jeśli za pośrednictwem systemu wirtualnego użytkownik pobierze plik i zdecyduje się zapisać na dysku, problem jest gotowy. Gdy później otworzy go w normalnym systemie koń trojański ukryty w pliku, będzie wiedział, co ma robić.