VirtualBox, VMware czy Hyper-V – jak stworzyć laboratorium do testów penetracyjnych?

Wprowadzenie: jak dobrać hypervisor do labu cyberbezpieczeństwa

Dobór hypervisora warto zacząć od scenariusza ćwiczeń, a nie od rankingu programów. Innego środowiska potrzebujesz do analizy pojedynczej podatnej aplikacji, a innego do odtworzenia firmowej infrastruktury z domeną, serwerami i stacjami roboczymi. Dobry hypervisor to taki, który pozwala sprawnie zbudować potrzebne środowisko, kontrolować jego granice i powtarzać testy — bez poświęcania większości czasu na obsługę samego laboratorium.

Hypervisor umożliwia uruchamianie maszyn wirtualnych, czyli odrębnych środowisk z własnymi systemami operacyjnymi, na jednym komputerze fizycznym. W labie pentesterskim możesz w ten sposób rozdzielić maszynę z narzędziami testowymi, cel ataku oraz dodatkowe usługi. Nie oznacza to jednak automatycznej izolacji od otoczenia: bezpieczeństwo laboratorium zależy również od jego konfiguracji. Celowo podatne systemy nie powinny być dostępne z sieci produkcyjnej ani publicznego internetu, a testy należy ograniczać do zasobów, na których badanie masz zgodę.

VirtualBox, VMware i Hyper-V pozwalają realizować podobne zadania, ale różnią się sposobem pracy i kontekstem zastosowania:

• VirtualBox to rozwiązanie desktopowe, często wybierane do nauki i samodzielnych eksperymentów. Jest naturalnym kandydatem, gdy budujesz niewielki, lokalny lab bez odtwarzania konkretnej platformy firmowej.
• VMware to rodzina produktów, nie jeden hypervisor. W przypadku laboratorium na komputerze osobistym punktem odniesienia jest przede wszystkim VMware Workstation; serwerowy ESXi stanowi osobną kategorię. Workstation warto rozważyć do regularnej pracy z lokalnymi środowiskami testowymi.
• Hyper-V jest rozwiązaniem Microsoftu zintegrowanym z wybranymi edycjami Windows i Windows Server. To szczególnie istotny kandydat, gdy laboratorium ma służyć poznawaniu środowisk opartych na technologiach Microsoftu, choć nie ogranicza się do uruchamiania Windows.

Przed wyborem określ, co chcesz badać, czy lab ma działać na codziennym komputerze, czy na osobnym hoście, oraz czy będziesz korzystać z gotowych maszyn udostępnianych w materiałach edukacyjnych. Nie musisz od razu budować miniatury centrum danych. Do pierwszych ćwiczeń lepsze będzie małe, zrozumiałe środowisko niż rozbudowana infrastruktura, której działania nie potrafisz jeszcze zweryfikować.

Wymagania sprzętowe i systemowe — jaki komputer przygotować do labu?

Komputer do laboratorium pentesterskiego trzeba dobierać pod zestaw maszyn działających jednocześnie, a nie wymagania samego hypervisora. Kali Linux i niewielki serwer testowy mają inne potrzeby niż środowisko z kontrolerem domeny, klientem Windows i kilkoma usługami. W Cognity często słyszymy pytania, jak dobrać sprzęt do takiego laboratorium — odpowiadamy na nie także na blogu. Przed instalacją warto określić pierwszy scenariusz ćwiczeń — od niego zależą potrzebna pamięć, miejsce na dysku i zapas mocy procesora.

System hosta: pierwszy filtr wyboru

Host to system komputera, na którym uruchamiasz maszyny wirtualne. Jego wybór zawęża dostępne rozwiązania. VirtualBox jest dostępny dla Windows, Linuksa i macOS, przy czym obsługiwane konfiguracje zależą od wersji programu oraz architektury procesora. VMware Workstation działa na Windows i Linuksie; na komputerach Mac odpowiednikiem z tej rodziny jest VMware Fusion.

Pełna rola Hyper-V jest dostępna m.in. w edycjach Pro, Enterprise i Education systemu Windows 11 oraz w Windows Server. Windows Home nie udostępnia jej jako standardowej funkcji, nawet jeśli korzysta z komponentów wirtualizacji do innych zadań. Przed wyborem hypervisora sprawdź nie tylko nazwę systemu, ale też jego edycję i obecność używanej wersji na liście wspieranych hostów.

Osobną kwestią jest architektura sprzętu. Wiele gotowych obrazów do ćwiczeń przygotowano dla x86-64. Komputer z procesorem ARM, w tym Mac z Apple Silicon, nie jest ich bezpośrednim zamiennikiem: wirtualizacja nie oznacza automatycznie emulacji innej architektury. Jeśli planujesz korzystać z konkretnych gotowych maszyn, sprawdź ich architekturę jeszcze przed zakupem sprzętu.

Procesor: rdzenie i sprzętowe wsparcie wirtualizacji

Dla typowego labu x86-64 wybierz 64-bitowy procesor Intel z VT-x lub AMD z AMD-V. Funkcja ta musi być włączona w UEFI/BIOS; może występować pod nazwą Intel Virtualization Technology albo SVM Mode. W przypadku Hyper-V istotna jest również obsługa SLAT, czyli translacji adresów drugiego poziomu — u Intela realizowanej przez EPT, a u AMD przez NPT.

Nowoczesny procesor z 4 rdzeniami i 8 wątkami wystarczy do niewielkiego środowiska, ale do regularnej pracy z kilkoma maszynami rozsądniej wybrać 6–8 rdzeni. Nie traktuj liczby wątków jako liczby pełnych rdzeni ani nie przydzielaj każdej maszynie maksymalnej liczby vCPU. Host także potrzebuje zasobów; dla lekkich maszyn punktem wyjścia mogą być 2 vCPU.

RAM i dysk: budżet dla całego środowiska

16 GB RAM to praktyczny punkt wejścia do małego labu, a 32 GB — rozsądna konfiguracja na start z zapasem. Przy 8 GB możliwe są proste ćwiczenia, lecz równoczesna praca hosta, przeglądarki i kilku gości szybko staje się uciążliwa. Dla rozbudowanego środowiska domenowego z wieloma systemami Windows warto rozważyć 64 GB.

Pamięć planuj oddzielnie dla hosta i gości. Na system gospodarza oraz podstawowe aplikacje pozostaw orientacyjnie 6–8 GB, korygując ten zapas według rzeczywistego zużycia. Pozostałą pamięć rozdziel zgodnie z rolą maszyn, zamiast przydzielać wszystkim identyczne wartości.

Na aktywne maszyny wybierz SSD; najlepiej NVMe, jeśli komputer go obsługuje. Dysk 512 GB pozwala zacząć, ale 1 TB daje znacznie większą swobodę. Przestrzeń zajmują nie tylko systemy gości, lecz także obrazy instalacyjne, dane z ćwiczeń i punkty przywracania. Dyski wirtualne powiększane dynamicznie oszczędzają miejsce początkowo, lecz nie eliminują potrzeby kontrolowania wolnej przestrzeni.

Rekomendowana konfiguracja na start

• Host: wspierany Windows lub Linux dla VirtualBox/VMware Workstation; Windows w odpowiedniej edycji, jeśli wybierasz Hyper-V.
• Sprzęt: procesor x86-64 z 6–8 rdzeniami i aktywną wirtualizacją sprzętową, 32 GB RAM oraz SSD 1 TB.
• Pierwszy zestaw maszyn: Kali Linux z 4 GB RAM, lekki serwer Linux z 2 GB oraz klient Windows z 6–8 GB. To wartości startowe, zależne od uruchamianych narzędzi i usług.
• Miejsce na lab: na początek wydziel około 200–300 GB, zostawiając dodatkowy zapas na wzrost obrazów i dane.

Do takiego zestawu nie potrzebujesz dedykowanej karty graficznej. Jeśli budżet wymaga kompromisów, zwykle bardziej przyda się możliwość rozbudowy RAM i większy SSD niż mocniejszy GPU — chyba że planujesz osobne zadania wykorzystujące obliczenia graficzne.

Wydajność i stabilność: jak VirtualBox, VMware i Hyper-V radzą sobie z obciążeniem labu?

Laboratorium z jedną maszyną Kali Linux i podatną aplikacją stawia inne wymagania niż środowisko z kontrolerem domeny, kilkoma stacjami roboczymi i systemem zbierającym logi. W pierwszym przypadku różnice między hypervisorami mogą być mało odczuwalne. W drugim o płynności pracy decyduje to, jak środowisko radzi sobie z równoczesnym obciążeniem procesora, dysku i sieci. Nie ma uniwersalnego zwycięzcy wydajnościowego — wynik zależy od hosta, konfiguracji maszyn i charakteru testów. W przypadku VMware poniższe porównanie dotyczy Workstation, czyli rozwiązania do labu uruchamianego na komputerze użytkownika, a nie platformy ESXi.

Narzut wirtualizacji: nie tylko wykorzystanie procesora

Przy sprzętowym wsparciu wirtualizacji wszystkie trzy rozwiązania mogą zapewnić dobrą wydajność obliczeniową. Narzut staje się bardziej widoczny przy intensywnej obsłudze wirtualnych urządzeń, operacjach wejścia–wyjścia oraz rywalizacji wielu maszyn o czas procesora. Dlatego wynik pojedynczego benchmarku CPU niewiele mówi o komforcie pracy w rozbudowanym labie.

VirtualBox sprawdza się w niewielkich i średnich środowiskach szkoleniowych, ale nie należy z góry uznawać go za wolniejszy w każdym zadaniu. VMware Workstation jest sensownym wyborem do labów desktopowych z wieloma maszynami, choć również wymaga sprawdzenia pod docelowym obciążeniem. Hyper-V warto uwzględnić przede wszystkim na hoście z Windows: jego architektura jest zintegrowana z systemem, co jednak nie oznacza automatycznej przewagi we wszystkich testach.

Na Windows znaczenie ma też aktywność hypervisora Microsoftu, wykorzystywanego między innymi przez zabezpieczenia oparte na wirtualizacji. VirtualBox i VMware Workstation mogą wtedy korzystać z innej ścieżki wykonania niż przy bezpośrednim dostępie do mechanizmów wirtualizacji procesora. Wpływ na wydajność zależy od wersji oprogramowania i obciążenia — porównanie wykonane przy różnych ustawieniach hosta może więc być mylące.

I/O dysku: częste źródło spowolnień

Równoczesny start systemów, instalowanie aktualizacji, zapis logów i praca baz danych generują wiele drobnych operacji dyskowych. W takich warunkach ważniejsze od maksymalnego transferu sekwencyjnego bywają opóźnienia odczytu i zapisu oraz zdolność obsługi wielu żądań jednocześnie. Jeśli wszystkie maszyny korzystają z tego samego przeciążonego nośnika, zmiana hypervisora może przynieść niewielką poprawę.

Presję na dysk dodatkowo zwiększa brak wolnej pamięci RAM. Gdy host zaczyna intensywnie korzystać z pliku wymiany, opóźnienia mogą dotknąć całego laboratorium. Objawia się to wolnym przełączaniem między maszynami, zawieszaniem interfejsów i przekraczaniem limitów czasu w usługach, mimo że procesor nie jest stale obciążony w stu procentach.

Sieć: przepustowość to tylko część obrazu

Ruch między maszynami na jednym hoście nie musi przechodzić przez fizyczną kartę sieciową. Jego obsługa nadal zużywa jednak zasoby procesora i pamięci. Podczas intensywnego skanowania, generowania wielu krótkich połączeń czy przechwytywania pakietów istotna jest nie tylko przepustowość, lecz także liczba obsługiwanych pakietów, opóźnienia i ewentualne straty. Ograniczeniem może okazać się zarówno warstwa wirtualizacji, jak i sama badana usługa.

Wiele maszyn: stabilność ważniejsza niż rekord benchmarku

Przydzielenie każdej maszynie większej liczby vCPU nie gwarantuje przyspieszenia. Gdy wiele aktywnych systemów konkuruje o ograniczone zasoby hosta, rosną czasy oczekiwania i pogarsza się responsywność. W labie pentesterskim ma to znaczenie dla wiarygodności obserwacji: timeout skanera może wynikać z przeciążenia środowiska, a nie z filtrowania ruchu czy zachowania celu.

Najbardziej miarodajny test wyboru to uruchomienie porównywalnego zestawu maszyn i typowego scenariusza: logowania do domeny, skanowania aplikacji oraz równoległego zbierania logów. Warto sprawdzić czas wykonania zadania, opóźnienia dysku, presję na pamięć i responsywność hosta, a próbę powtórzyć. Lepszym wyborem będzie platforma zapewniająca powtarzalne wyniki przez całą sesję niż ta, która osiąga najwyższy rezultat w krótkim teście jednej maszyny.

Funkcje sieciowe pod lab: NAT, Bridge, Host-only i izolowane segmenty

W laboratorium pentestowym konfiguracja sieci decyduje nie tylko o tym, które maszyny mogą się komunikować, lecz także o tym, dokąd trafi ruch generowany podczas testów. Podatne systemy powinny działać w wydzielonym segmencie, bez niepotrzebnego dostępu do sieci domowej lub firmowej. VirtualBox, VMware i Hyper-V pozwalają zbudować taki układ, ale inaczej nazywają poszczególne tryby i nie zawsze zapewniają identyczne zachowanie. W Cognity omawiamy konfigurację sieci laboratoryjnych zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

NAT, Bridge i Host-only — który tryb wybrać?

W poniższym porównaniu VMware oznacza przede wszystkim desktopowy VMware Workstation. Rozwiązań sieciowych znanych z ESXi nie należy automatycznie przypisywać do jego funkcji.

NAT nie oznacza pełnej izolacji. Zwykle ogranicza niezamówione połączenia przychodzące, ale pozwala maszynie inicjować połączenia na zewnątrz — także do dostępnych zasobów lokalnych. Istotna jest też różnica w VirtualBox: zwykły NAT nie tworzy automatycznie wspólnej sieci między maszynami, natomiast NAT Network umożliwia ich wzajemną komunikację w jednym segmencie.

Bridge sprawdza się wtedy, gdy test świadomie obejmuje fizyczne urządzenia w autoryzowanej sieci. Nie jest dobrym ustawieniem domyślnym dla celowo podatnego serwera. Host-only ułatwia natomiast obsługę labu z komputera gospodarza, lecz nie odcina podatnych maszyn od hosta. Jeśli taki dostęp nie jest potrzebny, lepszym punktem wyjścia będzie sieć wyłącznie między VM.

Segmentacja: osobne sieci czy VLAN?

Do odtworzenia stref użytkowników, serwerów i DMZ często wystarczą osobne wirtualne sieci połączone maszyną pełniącą funkcję routera lub firewalla, np. z OPNsense albo pfSense. Taki układ pozwala ćwiczyć kontrolę przepływu ruchu i testować reguły dostępu bez podłączania labu do fizycznego przełącznika.

VLAN-y mają znaczenie, gdy przedmiotem ćwiczeń jest również tagowanie 802.1Q lub integracja z fizyczną infrastrukturą. Hyper-V udostępnia konfigurację identyfikatorów VLAN i trybu trunk na wirtualnych kartach sieciowych. W VirtualBox i VMware Workstation nie należy zakładać identycznej obsługi: możliwość przenoszenia tagowanego ruchu zależy od konkretnego połączenia, systemu hosta i sterowników. Osobne segmenty wirtualne zapewniają separację topologii, ale same w sobie nie są ćwiczeniem z VLAN-ów.

Przechwytywanie ruchu i podłączenie narzędzi

Wireshark i tcpdump można uruchomić wewnątrz maszyny testowej, a na hoście — przechwytywać ruch na dostępnych interfejsach wirtualnych. Nie oznacza to jednak automatycznej widoczności całego labu. Wirtualny przełącznik zwykle nie wysyła do każdego portu ruchu unicast wymienianego przez pozostałe maszyny; samo włączenie trybu promiscuous w analizatorze może więc nie wystarczyć.

VirtualBox pozwala określić politykę trybu promiscuous dla karty VM, a Hyper-V oferuje port mirroring. W VMware Workstation sposób obserwacji należy dobrać do użytej sieci i miejsca przechwytywania. Dla sensorów Suricata lub Zeek warto zaplanować kopiowanie ruchu albo umieścić sensor na jego trasie, zamiast zakładać, że zobaczy wszystkie pakiety tylko dlatego, że działa w tej samej podsieci.

Praktyczny układ startowy to maszyna z narzędziami, podatny cel i opcjonalny sensor w jednym odizolowanym segmencie. Dostęp do aktualizacji można zapewniać czasowo, a bardziej rozbudowany lab podłączyć przez kontrolowany firewall. Dodanie drugiej karty NAT nie zastępuje takiej kontroli: trzeba sprawdzić routing, przekazywanie pakietów i reguły zapory, aby maszyna z dwoma interfejsami nie stała się niezamierzonym wyjściem poza laboratorium.

Snapshoty, klony i automatyzacja — jak szybko odtwarzać środowisko testowe

Po udanym wykorzystaniu podatności maszyna testowa rzadko nadaje się od razu do kolejnego ćwiczenia. Zmienione uprawnienia, dodatkowe konta czy uszkodzona konfiguracja mogą wpłynąć na wynik następnej próby. Dlatego w laboratorium pentesterskim liczy się nie tylko możliwość uruchomienia maszyn, ale także szybki i powtarzalny powrót do znanego stanu. Snapshoty pozwalają cofać zmiany, klony tworzyć odrębne instancje, a automatyzacja ogranicza ręczne przygotowywanie scenariuszy.

Snapshot to punkt powrotu, nie kopia zapasowa

Snapshot, nazywany w Hyper-V punktem kontrolnym, umożliwia przywrócenie wcześniejszego stanu maszyny. Zależnie od platformy i wybranego trybu może obejmować stan dysków, konfigurację oraz pamięć operacyjną. W praktyce warto utworzyć go po przygotowaniu środowiska, a następny bezpośrednio przed testem, który zmienia system. Przywrócenie punktu początkowego usuwa późniejsze zmiany w objętych nim dyskach — wyniki skanowania, logi i notatki potrzebne do raportu należy wcześniej zachować poza przywracaną maszyną.

Snapshot nie jest niezależnym backupem: zwykle opiera się na dysku bazowym i plikach różnicowych. Nie chroni więc przed utratą całego magazynu danych. Zamiast utrzymywać rozbudowane drzewo kolejnych punktów, lepiej zachować kilka opisanych etapów, na przykład „czysty system” i „środowisko przed testem”, a niepotrzebne usuwać za pomocą narzędzi hypervisora.

W Hyper-V standardowy punkt kontrolny może zachować stan pamięci działającej maszyny, co przydaje się podczas odtwarzania konkretnego momentu ćwiczenia. Produkcyjny wykorzystuje mechanizmy gościa, takie jak VSS w Windows lub zamrażanie systemu plików w Linux, aby uzyskać spójny stan danych bez zapisu pamięci. Nie służy więc do wznowienia działających procesów dokładnie w miejscu przerwania.

Klony i template’y: jedna baza, wiele scenariuszy

Pełny klon ma własną kopię dysków i nie wymaga dysku maszyny źródłowej. Sprawdza się, gdy środowisko ma być rozwijane niezależnie lub przenoszone. Klon powiązany zapisuje własne zmiany, ale korzysta ze wspólnej bazy. Pozwala szybko przygotować kilka wariantów podatnej maszyny, jednak wymaga zachowania plików, od których zależy.

Template to przygotowany wzorzec do wdrażania kolejnych maszyn, a nie punkt cofania zmian. W vSphere szablony są osobnym elementem zarządzania środowiskiem. W lokalnym VirtualBox, Workstation czy samym Hyper-V podobny proces można oprzeć na wyłączonej maszynie wzorcowej, eksporcie albo przygotowanym obrazie dysku. Nie są to jednak identyczne mechanizmy. Przed powielaniem warto ustalić, które elementy mają pozostać wspólne, a które wymagają zmiany — zwłaszcza nazwy hostów, identyfikatory i klucze systemowe.

CLI i API: reset laboratorium bez przeklikiwania konsoli

VBoxManage pozwala skryptowo tworzyć i przywracać snapshoty, klonować maszyny oraz sterować ich uruchamianiem. W Hyper-V analogiczne zadania realizują między innymi polecenia Checkpoint-VM, Restore-VMSnapshot, Export-VM i Import-VM. Przy imporcie jako kopia można nadać maszynie nowy identyfikator.

W przypadku VMware trzeba rozróżnić produkty: PowerCLI jest przede wszystkim narzędziem do automatyzacji infrastruktury vSphere, a nie zamiennikiem lokalnego CLI Workstation. Dla Workstation typowym narzędziem jest vmrun, obsługujące między innymi operacje na snapshotach. Ta różnica ma znaczenie, jeśli gotowe skrypty mają być jednym z kryteriów wyboru platformy.

Dobry skrypt resetujący lab powinien przywracać właściwe punkty, uruchamiać maszyny w ustalonej kolejności i sprawdzać gotowość usług. W scenariuszach wielomaszynowych trzeba też zachować spójność całego zestawu: cofnięcie tylko jednego hosta może rozjechać stan zależnych usług. Snapshoty poszczególnych maszyn nie tworzą automatycznie jednego, skoordynowanego punktu odtworzenia laboratorium.

Łatwość konfiguracji i utrzymania: codzienna obsługa VirtualBox, VMware i Hyper-V

W labie pentesterskim wygoda obsługi szybko przestaje oznaczać wyłącznie prosty kreator maszyny wirtualnej. Ważniejsze staje się to, czy po aktualizacji hosta środowisko nadal działa, czy konsola pozwala sprawnie pracować i jak łatwo ustalić przyczynę nieudanego uruchomienia VM. Dobry wybór to platforma, którą potrafisz nie tylko skonfigurować, lecz także samodzielnie utrzymać. W przypadku VMware poniższe porównanie dotyczy Workstation, czyli rozwiązania desktopowego, a nie infrastruktury serwerowej ESXi.

Interfejs i wygoda codziennej pracy

Sterowniki i dodatki: rozróżnij hosta od gościa

Problemy po instalacji często wynikają z pomieszania dwóch warstw. Moduły i sterowniki na hoście umożliwiają pracę hypervisora, a dodatki w gościu usprawniają obsługę uruchomionego systemu. Jeżeli VM w ogóle nie startuje, reinstalowanie Guest Additions czy VMware Tools zwykle nie rozwiąże przyczyny. Jeśli natomiast system się uruchamia, ale nie zmienia rozdzielczości albo nieprawidłowo obsługuje wskaźnik myszy, dodatki gościa są jednym z pierwszych elementów do sprawdzenia.

W VirtualBox warto utrzymywać Guest Additions zgodne z używaną wersją platformy. W linuksowych gościach VMware standardowym wyborem są zwykle pakiety open-vm-tools z repozytorium dystrybucji; integracja pulpitu może wymagać dodatkowego pakietu. Współczesne systemy Windows oraz wiele dystrybucji Linuksa mają komponenty integracyjne Hyper-V dostarczane wraz z systemem lub jego jądrem, więc nie należy automatycznie szukać osobnego instalatora.

Udogodnienia nie zawsze są pożądane w środowisku testowym. Wspólny schowek, przeciąganie plików i foldery współdzielone włączaj tylko wtedy, gdy są potrzebne. Przy pracy z celowo podatnym systemem ograniczenie takich połączeń zmniejsza ryzyko przypadkowego przeniesienia danych między gościem a hostem.

Aktualizacje bez niepotrzebnych przestojów

Przed aktualizacją hypervisora zamknij systemy gości zamiast pozostawiać maszyny w stanie zapisanym — odtworzenie takiego stanu po zmianie wersji może się nie udać. Zabezpiecz pliki VM i ich konfigurację, sprawdź informacje o wydaniu, a po aktualizacji uruchom najpierw jedną mniej istotną maszynę. Dopiero po sprawdzeniu konsoli i podstawowych funkcji przejdź do reszty labu.

Na hoście z Linuksem aktualizacja jądra może wymagać przebudowania modułów VirtualBox lub VMware. Przy włączonym Secure Boot znaczenie ma również ich poprawne podpisanie i zaufanie do klucza. Nie traktuj wyłączania zabezpieczeń jako domyślnej naprawy. W Hyper-V zmiany platformy są dostarczane wraz z aktualizacjami Windows, dlatego restart hosta warto planować poza trwającymi ćwiczeniami.

Troubleshooting: diagnozuj objaw, nie zmieniaj wszystkiego naraz

• Maszyna nie startuje: zapisz pełny komunikat błędu, sprawdź dostępność plików VM, uprawnienia oraz wolne miejsce. Następnie zajrzyj do VBox.log, vmware.log albo dzienników Hyper-V w Podglądzie zdarzeń.
• Awaria pojawiła się po aktualizacji hosta: sprawdź zgodność wersji hypervisora i stan jego modułów lub usług. Na Windows uwzględnij aktywność Hyper-V oraz zabezpieczeń opartych na wirtualizacji — mogą zmieniać sposób działania VirtualBox i Workstation, ale nie oznaczają automatycznie całkowitej niezgodności.
• System działa, lecz konsola sprawia problemy: zweryfikuj dodatki gościa i ustawienia obrazu. Testowo wyłącz akcelerację 3D, jeśli występują artefakty lub czarny ekran.

Po każdej zmianie wykonuj jeden test i zapisuj wynik. Krótka notatka z wersją hosta, hypervisora oraz ostatnią modyfikacją często skraca naprawę bardziej niż wielokrotna reinstalacja całego środowiska.

Kompatybilność z systemami i narzędziami: Windows, Linux, BSD, macOS oraz integracje

O przydatności hypervisora decyduje nie tylko możliwość uruchomienia wybranego systemu, ale też dostępność funkcji potrzebnych w konkretnym scenariuszu testowym. System, który uruchamia się w maszynie wirtualnej, nie zawsze jest oficjalnie wspieranym gościem. Ma to znaczenie zwłaszcza przy BSD, macOS i gotowych obrazach laboratoryjnych przygotowanych pod określoną platformę.

Windows i Linux — najszerszy wybór scenariuszy

VirtualBox, VMware i Hyper-V pozwalają budować laboratoria z maszynami Windows oraz popularnymi dystrybucjami Linuksa. Można więc połączyć stacje robocze, serwery usług i systemy z narzędziami pentesterskimi. Przed wyborem warto jednak sprawdzić obsługę konkretnych wersji gości, szczególnie gdy ćwiczenia wymagają starszych, celowo podatnych systemów.

Istotne jest również rozróżnienie produktów VMware: Workstation jest przeznaczony dla hostów Windows i Linux, a Fusion dla macOS. Hyper-V jest rozwiązaniem związanym z hostami Windows, natomiast VirtualBox udostępnia wydania dla kilku systemów gospodarza. Sama zgodność z hostem nie oznacza jednak, że każdy obraz maszyny będzie działał bez konwersji. Jeśli korzystasz z gotowych laboratoriów, sprawdź, dla jakiego hypervisora i jakiej architektury procesora zostały przygotowane.

BSD i macOS — sprawdź konkretną wersję i architekturę

Systemy z rodziny BSD wymagają dokładniejszej weryfikacji niż popularne dystrybucje Linuksa. FreeBSD może działać na wszystkich trzech platformach, lecz zakres oficjalnego wsparcia i integracji zależy od wersji systemu oraz hypervisora. Nie należy automatycznie przenosić tych założeń na OpenBSD, NetBSD czy bazujące na BSD urządzenia wirtualne. W przypadku gotowego firewalla lub routera najlepiej kierować się dokumentacją jego producenta.

Przy macOS ograniczenia są zarówno techniczne, jak i licencyjne. Licencje macOS co do zasady wiążą jego wirtualizację ze sprzętem Apple, a dopuszczalne zastosowania i liczba instancji wynikają z warunków konkretnej wersji systemu. Nie zakładaj też, że hypervisor działający na Macu obsługuje macOS jako gościa.

Na komputerach Apple Silicon dodatkową granicą jest architektura ARM. Obrazy Windows lub Linuksa przygotowane dla x86-64 nie stają się zgodne tylko dlatego, że mają format rozpoznawany przez program. Wirtualizacja nie jest tym samym co emulacja innej architektury, dlatego zgodność gotowych maszyn pentesterskich trzeba sprawdzić przed zaplanowaniem całego labu.

Active Directory, WSL2 i Docker

Laboratorium Active Directory nie wymaga Hyper-V. Kontrolery domeny Windows Server oraz klienci Windows mogą pracować również w VirtualBox i VMware. Wybór powinien wynikać z pozostałych potrzeb środowiska, a nie z przekonania, że domena Microsoftu wymusza hypervisor tego samego producenta.

WSL2 korzysta z mechanizmów wirtualizacji Microsoftu, co ma znaczenie, jeśli na tym samym hoście Windows chcesz używać VirtualBox lub VMware Workstation. Ich nowsze wydania mogą współpracować z aktywnym hypervisorem Microsoftu, ale nie należy zakładać pełnej równoważności z pracą bez tej warstwy. Sprawdź zgodność konkretnego wydania, zwłaszcza gdy potrzebujesz wirtualizacji zagnieżdżonej.

Docker Engine można uruchomić wewnątrz linuksowej maszyny wirtualnej na każdej z porównywanych platform. Docker Desktop na Windows może korzystać z zaplecza WSL2 lub Hyper-V, zależnie od konfiguracji i rodzaju kontenerów. Kontenery są przydatne do odtwarzania podatnych aplikacji, ale nie zastępują pełnych maszyn w ćwiczeniach wymagających osobnego jądra systemu, sterowników czy kompletnej infrastruktury domenowej.

Licencja hypervisora nie obejmuje całego laboratorium

Podstawowy pakiet VirtualBox jest otwartym oprogramowaniem, natomiast Extension Pack podlega odrębnej licencji; zastosowania firmowe mogą wymagać licencji komercyjnej. VMware Workstation Pro i Fusion Pro są udostępniane bezpłatnie również do zastosowań komercyjnych, lecz nie oznacza to takich samych zasad dla innych produktów VMware ani automatycznego dostępu do płatnego wsparcia.

Kliencki Hyper-V jest dostępny w odpowiednich edycjach Windows, między innymi Pro, Enterprise i Education, a nie jako pełna rola w Home. Niezależnie od platformy trzeba osobno zweryfikować prawa do uruchamiania gości Windows i Windows Server: licencja hosta nie daje automatycznie nieograniczonych praw do instancji wirtualnych, a wydania ewaluacyjne mają ograniczenia czasowe i warunki użytkowania. Osobnego sprawdzenia wymaga też Docker Desktop, którego bezpłatne użycie zależy od rodzaju zastosowania i organizacji. To szczególnie ważne, gdy prywatny lab ma później służyć zespołowi w firmie.

Przykładowa architektura labu: segmentacja, role maszyn i wybór hypervisora

Dobry lab do testów penetracyjnych powinien pozwalać nie tylko znaleźć podatność, lecz także sprawdzić, jakie daje ona możliwości i co zatrzymuje dalszy atak. Dlatego zamiast umieszczać wszystkie maszyny w jednej sieci, warto zbudować małe środowisko z wydzielonymi strefami. Taki układ nadaje się zarówno do ćwiczeń z bezpieczeństwa aplikacji, jak i do testowania segmentacji czy analizy zdarzeń po stronie obrońcy.

Trzy strefy i kontrolowany przepływ ruchu

Punktem wyjścia mogą być trzy odrębne sieci wirtualne, połączone przez maszynę pełniącą funkcję routera i zapory. Przykładowa adresacja jest umowna — należy dobrać ją tak, aby nie kolidowała z siecią domową, firmową ani połączeniami VPN hosta.

• Strefa attacker — 10.77.10.0/24: maszyna z Kali Linux lub inną dystrybucją zawierającą narzędzia testowe. Reprezentuje punkt, z którego rozpoczynasz ćwiczenie, a nie zaufaną stację administracyjną.
• Strefa victim — 10.77.20.0/24: celowo podatna aplikacja, serwer testowy lub stacja robocza. Na początek wystarczy jeden cel, np. maszyna z OWASP Juice Shop.
• Strefa infra — 10.77.30.0/24: usługi wspierające scenariusz, np. DNS, kontroler domeny testowej albo kolektor logów. Nie trzeba uruchamiać ich wszystkich od razu; zwykle warto zacząć od centralnego zbierania zdarzeń.

Domyślną zasadą między strefami powinno być blokowanie ruchu, a wyjątki mają wynikać z konkretnego ćwiczenia. Przykładowo attacker otrzymuje dostęp do aplikacji WWW w strefie victim, ale nie do panelu administracyjnego zapory. Serwer aplikacji może przekazywać logi do wskazanego odbiorcy w infra, bez swobodnego dostępu do pozostałych usług tej strefy. Sama odmienna adresacja nie zapewnia izolacji — potrzebne są oddzielne sieci wirtualne i egzekwowane reguły komunikacji.

Podatnych maszyn nie należy podłączać bezpośrednio do fizycznej sieci domowej lub firmowej. Do tego projektu pasują sieci wewnętrzne VirtualBox, segmenty LAN w VMware Workstation albo prywatne przełączniki Hyper-V. Zarządzanie można początkowo prowadzić przez konsolę hypervisora, bez tworzenia dodatkowej ścieżki sieciowej do hosta. Jeżeli potrzebny jest internet do aktualizacji, udostępniaj go przez kontrolowaną bramę tylko na czas prac; sam NAT nie gwarantuje odcięcia dostępu do sieci lokalnej.

Scenariusze, które wykorzystują tę architekturę

Test aplikacji WWW: udostępnij ze strefy attacker wyłącznie port aplikacji w victim. Sprawdź podatności, a następnie porównaj działania testera z zapisami serwera i zapory. Celem jest nie tylko potwierdzenie błędu, ale również ustalenie, czy pozostawia on ślady przydatne do wykrycia incydentu.

Weryfikacja segmentacji: przyjmij, że maszyna victim została już przejęta, i z jej poziomu sprawdź dostępność usług infra. Porównaj stan zbyt szerokich uprawnień sieciowych z wariantem ograniczonym do niezbędnych połączeń. To praktyczny sposób oceny, czy zapora rzeczywiście ogranicza skutki kompromitacji.

Ćwiczenie domenowe: dodaj testowy kontroler domeny w infra oraz stację Windows w victim. Dopuść komunikację wymaganą do działania domeny, a następnie badaj skutki błędnych uprawnień i możliwości ich wykrywania. Używaj wyłącznie laboratoryjnych kont, haseł i danych — bez powiązań z produkcyjnym Active Directory.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

VirtualBox, VMware czy Hyper-V do takiego projektu?

VirtualBox jest rozsądnym punktem wyjścia do samodzielnego, niewielkiego labu z kilkoma strefami. VMware Workstation warto wybrać zwłaszcza wtedy, gdy gotowe środowiska ćwiczeniowe są dostarczane i sprawdzane właśnie dla tego produktu. Hyper-V będzie naturalnym wyborem na zgodnym hoście Windows, szczególnie przy laboratorium skoncentrowanym na usługach Microsoft i scenariuszach domenowych.

Każde z tych rozwiązań pozwala zrealizować opisany podział. Na start ważniejsza od marki hypervisora jest możliwość sprawdzenia izolacji i jednoznacznego określenia dozwolonych połączeń. Zacznij od maszyny attacker, jednego celu i zapory. Kolejne systemy dodawaj dopiero wtedy, gdy odpowiadają na konkretną potrzebę ćwiczenia.

Jak dostosować jeden projekt Canva do różnych kanałów komunikacji? 13 listopada 2026

Jak przygotować projekt w Canva do druku? Rozdzielczość, marginesy, spady i jakość grafiki. 11 listopada 2026