Tworzenie domowego labu do nauki cyberbezpieczeństwa z wykorzystaniem darmowych narzędzi

Po co w ogóle domowy lab i dla kogo ma sens

Realne cele: po co komu domowe laboratorium bezpieczeństwa

Domowy lab do nauki cyberbezpieczeństwa to kontrolowane środowisko, w którym można bezpiecznie ćwiczyć ataki, obronę, konfigurację systemów i narzędzi bezpieczeństwa. Zamiast „klikać na sucho” w dokumentacji, dostajesz miejsce, gdzie wolno coś popsuć, postawić od nowa, eksperymentować i uczyć się na błędach bez konsekwencji biznesowych.

Najczęstsze cele budowy takiego labu to:

• Nauka podstaw bezpieczeństwa – protokoły sieciowe, prawa dostępu, logi, firewall, proste ataki i ich wykrywanie.
• Trening narzędzi – Nmap, Wireshark, Metasploit, IDS/IPS, SIEM-y open source, skanery podatności.
• Przygotowanie do certyfikatów – CompTIA Security+, CEH, OSCP, eJPT, PNPT i inne egzaminy wymagające praktyki.
• Symulacja incydentów – od prostych infekcji malware do scenariuszy „ransomware w firmie na 50 osób”.
• Testowanie własnych aplikacji – sprawdzanie bezpieczeństwa kodu, konfiguracji serwerów i usług.

Największą przewagą labu nad teorią jest możliwość szybkiego przechodzenia od „tak powinno działać” do „zobaczmy, jak to naprawdę działa”. W książce SQLi to dwa diagramy i kilka payloadów. W labie widzisz faktyczne zapytania w logach, odpowiedzi serwera, skutki w bazie i możesz je potem analizować bez stresu.

Dla kogo ma sens domowe lab cyberbezpieczeństwa

Domowe środowisko testowe ma sens dla większości osób, które choć trochę zahaczają o IT, nawet jeśli ich obecna rola nie ma w nazwie słowa „security”. Kilka typowych profili:

• Studenci i osoby na początku kariery IT – świetne uzupełnienie studiów informatycznych, kierunków pokrewnych i bootcampów. To, czego często brakuje na uczelni, to właśnie praktyka i kontakt z „żywym systemem”.
• Pracownicy helpdesku i wsparcia technicznego – unikają przejścia prosto w ogień w roli admina lub security engineer, bo wcześniej ćwiczą scenariusze incydentów „na sucho”.
• Administratorzy systemów i sieci – miejsce do testowania patchy, nowych usług, konfiguracji firewalli, VPN-ów i polityk bezpieczeństwa.
• Programiści – środowisko do testów bezpieczeństwa własnych aplikacji webowych, API, mikroserwisów.
• Osoby przebranżawiające się – bezpieczny poligon, gdy pierwsza praca w security jest dopiero na horyzoncie.

Dobry lab pentesterski w domu sprawia, że rozmowy kwalifikacyjne w cyberbezpieczeństwie nie są „zderzeniem z murem”. Kiedy rekruter pyta o konkretny atak, narzędzie lub konfigurację, możesz odwołać się do faktycznych ćwiczeń z własnego środowiska, a nie do kilku przeczytanych artykułów.

Czego zdecydowanie nie robić w domowym labie

Choć domowe środowisko testowe brzmi niewinnie, da się tu narobić poważnych szkód – głównie sobie i sąsiadom w sieci. Kilka zasad bezpieczeństwa, których lepiej nie łamać:

• Nie testuj na produkcji – nawet „małe skanowanie Nmapem” na serwerze firmowym bywa zauważalne i może naruszać politykę bezpieczeństwa.
• Nie skanuj cudzych sieci bez zgody – sąsiadów, firm, randomowych hostów w internecie. Skaner portów w logach kogoś innego może zostać zakwalifikowany jako próba ataku.
• Nie odpalaj malware na swoim host systemie – zawsze używaj maszyn wirtualnych, najlepiej odciętych od sieci produkcyjnej.
• Nie eksperymentuj „w ciemno” na swoim głównym systemie – niektóre narzędzia ofensywne potrafią uszkodzić konfigurację, dane i stabilność systemu, na którym je odpalasz.

Różnica między rozsądnym labem a „zabawą bez planu” polega na tym, że w pierwszym wiesz, co testujesz, masz plan cofnięcia zmian (snapshot, backup) i jasno wyznaczone granice tego, co jest dozwolone. W drugim – efekt końcowy często brzmi „coś przestało działać, nie wiem co”.

Teoria kontra praktyka: siła kontrolowanego „popsucia”

Kto choć raz usunął nie ten wpis w rejestrze Windows albo zmienił iptables o jedną literkę za wiele, ten wie, że najlepsze lekcje przychodzą z praktyki. Domowy lab cyberbezpieczeństwa pozwala:

• Intencjonalnie psuć – np. zainstalować starą, podatną wersję aplikacji, źle skonfigurować backup, udostępnić zbyt szerokie uprawnienia.
• Symulować błędy użytkownika – otwarcie załącznika, kliknięcie w podejrzany link, wprowadzenie danych do fałszywego formularza.
• Ćwiczyć naprawianie – przywracanie z backupu, odtwarzanie konfiguracji, zmiana haseł, rotacja kluczy, zabudowa dodatkowych zabezpieczeń.

Teoretycznie każdy wie, że snapshot to „cofnięcie stanu maszyny”. Po pierwszym nieudanym update, który zepsuł pół systemu, i uratowaniu się jednym kliknięciem „Revert”, definicja snapshotu nabiera bardzo praktycznego znaczenia.

Plan działania: jak podejść do budowy labu krok po kroku

Określenie celu: offensive, defensive czy środowisko mieszane

Domowe lab cyberbezpieczeństwo może mieć różne „charaktery”, w zależności od tego, czego chcesz się nauczyć. Zanim rzucisz się do pobierania dziesiątek obrazów ISO, określ, do czego to środowisko ma służyć:

• Lab offensive (pentest, red team) – skupienie na narzędziach atakujących: skanery, exploity, fuzzery, frameworki typu Metasploit. Potrzebujesz tu głównie podatnych maszyn, aplikacji webowych, serwerów z błędnymi konfiguracjami.
• Lab defensive (blue team, SOC) – skupienie na logach, monitoringu, korelacji zdarzeń, pisaniu reguł do SIEM-a, reagowaniu na incydenty. Przyda się tu centralny syslog, SIEM (np. Wazuh, TheHive, ELK), IDS/IPS, firewall, stacje robocze generujące normalny ruch.
• Lab mieszany – najczęstsza opcja. Coś atakuje, coś się broni, a Ty patrzysz z dwóch stron: jak wygląda atak oczami napastnika i co zostawia po sobie w logach i alertach.

Dobrym podejściem jest zacząć od prostego scenariusza: jedna maszyna atakująca, jedna ofiara, jedna maszyna „użytkownika”. Na tym mini-zestawie da się przećwiczyć i ofensywę, i defensywę, i podłączanie kolejnych komponentów w miarę, jak rosną umiejętności.

Realistyczna ocena poziomu startowego

Inaczej buduje się lab, gdy Linuxa widziałeś tylko na zrzutach ekranu, a inaczej, gdy od lat administrujesz serwerami. Dwa uproszczone profile startowe:

• Absolutny początkujący – znajomość podstaw Windows, może drobny kontakt z konsolą. Tu kluczowe będzie postawienie prostego, stabilnego środowiska: jedna dystrybucja Linux (np. Ubuntu), jedna maszyna Windows z legalnego obrazu testowego, jedna podatna aplikacja webowa. Więcej maszyn na start oznacza więcej chaosu.
• Osoba z doświadczeniem administracyjnym – swobodna praca z siecią, systemami, może już jakieś skrypty. Tu można szybciej przejść do segmentacji sieci, osobnego firewalla, DNS-a, centralnego logowania, a nawet symulacji kilku podsieci.

Zaawansowani często wpadają w pułapkę „od razu zbuduję sobie mini-korporację na 20 maszyn”. Lepiej zacząć od trzech–czterech, ale mieć je porządnie opisane, zrozumiane i opanowane, zamiast 20 wirtualek, o których po miesiącu nie wiesz, która jest od czego.

Czas i budżet: scenariusz „stary laptop + 0 zł”

Przy budżecie bliskim zera plan jest prosty: maksymalne wykorzystanie istniejącego sprzętu i darmowych narzędzi. Typowa sytuacja: stary laptop z 8 GB RAM i dyskiem SSD/HDD. Co da się z tego wycisnąć?

• Host – lekki system (np. Linux Mint / Xubuntu) zamiast zasobożernej edycji Windows.
• Hypervisor – VirtualBox lub VMware Workstation Player (oba darmowe do użytku niekomercyjnego).
• 3–4 maszyny wirtualne – jedna „atakująca” (Kali/Parrot), jedna „ofiara” (Metasploitable), jedna zwykła stacja użytkownika (Ubuntu/Windows eval), ewentualnie osobny router/firewall, jeśli RAM pozwala.

Czasowo sensownie działa model „bloków nauki”: np. 5–7 godzin tygodniowo podzielonych na 2–3 sesje. Lepszy jest konsekwentny, stały rytm niż jeden „maraton” raz na trzy tygodnie, po którym pamiętasz głównie zmęczenie.

Strategia rozwoju: mały lab, który rośnie z Tobą

Domowy lab pentesterski i defensywny powinien być żywym organizmem. Na początku wystarczy absolutne minimum, potem można go rozbudowywać warstwami:

1. Poziom 1 – bazowe środowisko: 2–3 maszyny, jedna sieć, proste ataki (skanowanie, proste exploity), podstawowa analiza logów.
2. Poziom 2 – segmentacja: dodanie routera/firewalla, osobnych podsieci, testy komunikacji między segmentami, proste reguły firewall.
3. Poziom 3 – monitoring: wdrożenie centralnego logowania, SIEM-a open source, IDS/IPS, testowanie alertów na typowe ataki.
4. Poziom 4 – zaawansowane scenariusze: symulacja phishingu, ruchu bocznego (lateral movement), ataków na AD, persistence.

Każdy nowy komponent dodawaj dopiero wtedy, gdy poprzedni poziom masz opanowany. Inaczej zamiast laboratorium powstanie „muzeum niedokończonych eksperymentów”.

Sprzęt i zasoby: co jest potrzebne, a co tylko „miłe mieć”

Minimalne wymagania sprzętowe dla domowego labu

Wirtualizacja jest łakoma na RAM i dysk, procesor też nie lubi nudy, ale nie trzeba od razu kupować serwera za kilka tysięcy. Kilka realistycznych konfiguracji:

Kluczowe jest tu zrozumienie jednej rzeczy: RAM kończy się szybciej, niż myślisz. Jedna maszyna Windows spokojnie potrafi skonsumować 3–4 GB, Linux serwerowy zadowoli się 1–2 GB. Gdy zsumujesz to dla kilku maszyn, robi się ciasno.

Wykorzystanie starego laptopa, PC i małych serwerów

Domowe laboratorium do nauki bezpieczeństwa bardzo lubi sprzęt „z odzysku”. Zamiast wyrzucać stary komputer, można go przekształcić w hosta pod wirtualizację:

• Stary laptop – cichy, energooszczędny, często mały ekran. Świetny jako pierwsza maszyna, gorzej jako długotrwały serwer. Warto dodać RAM i wymienić dysk na SSD.
• Stacjonarny PC – najłatwiej rozbudować (więcej RAM, dodatkowy dysk, lepszy procesor). Nadaje się na stały host labu, który może działać kilka godzin bez przerwy.
• Mały serwer / miniPC (np. używany serwer, Intel NUC, micro serwery) – większa kultura pracy pod obciążeniem, możliwość pracy 24/7, ale często głośniejsze i wymagają osobnego monitora lub zdalnego zarządzania.

Różnica między „da się odpalić” a „da się komfortowo pracować” jest odczuwalna przy większej liczbie maszyn. Jeśli czujesz, że jedna dodatkowa maszyna zmienia Twojego laptopa w nagrzewnicę z turbodoładowaniem – to jest sygnał, żeby pomyśleć o lekkim usprawnieniu sprzętu.

Jak szybko ocenić, czy komputer udźwignie lab

Najprostszy test to policzenie: ile maszyn chcesz mieć uruchomionych równocześnie i ile RAM-u oraz dysku faktycznie potrzebują:

• Linux „atakujący” – 2 GB RAM, 20–30 GB dysku.
• Windows „użytkownik” – 3–4 GB RAM, 40–60 GB dysku.

Przydział zasobów dla typowych ról maszyn

Przy planowaniu labu pomaga potraktowanie każdej VM jako „pracownika z etatem”: ma swoje zadania i swój przydział zasobów. Z grubsza można przyjąć takie widełki (pod ofensywę + defensywę):

• Linux „atakujący” (Kali/Parrot) – 2–4 GB RAM, 2 vCPU, 30–40 GB dysku; więcej RAM przydaje się przy narzędziach typu Burp czy multiplekserach terminala, gdy odpalasz wszystko naraz.
• Linux „ofiara” (np. podatny serwer WWW) – 1–2 GB RAM, 1 vCPU, 20–30 GB dysku; w zupełności wystarczy pod większość gotowych obrazów treningowych.
• Windows „użytkownik” / „oficjalny” endpoint – 4 GB RAM jako rozsądne minimum, 2 vCPU, 60–80 GB dysku (update’y i logi lubią przestrzeń).
• SIEM / stack logujący (ELK, Wazuh, itp.) – 4–8 GB RAM, 2–4 vCPU, 80–120 GB dysku; to zjada zasoby, więc nie ma sensu stawiać tego na pierwszym, ledwo zipiącym laptopie.
• Firewall/router (pfSense/OPNsense, router na Linuxie) – 1–2 GB RAM, 1–2 vCPU, 10–20 GB dysku.

Dobry nawyk: odpal lab, popracuj godzinę, a potem zajrzyj do monitoringu hosta (Menadżer zadań / htop). Jeżeli wszystko czerwone, wiatrak komputera gra „heavy metal”, a Ty masz lagi przy przełączaniu okien, to znak, że maszyny dostały zbyt tłusty przydział i można im nieco przykręcić RAM lub vCPU.

Rzeczy „miłe mieć”, ale niekonieczne na start

Rozbudowany lab łatwo zmienia się w miejsce do testowania gadżetów. Zamiast rzucać się od razu na wszystko, lepiej dodać te elementy później – gdy pojawi się na nie realne zadanie:

• Osobny NAS / storage – przydatny, gdy robisz dużo snapshotów, kopii i trzymasz gigabajty logów lub obrazów dysków. Na start rolę „prostego NAS-a” spokojnie może pełnić dodatkowy dysk w PC.
• Sprzętowy firewall / router – fajny, gdy chcesz trenować konfigurację jak w firmie, ale software’owy pfSense/OPNsense na VM-ie umożliwi Ci bardzo podobne ćwiczenia.
• Przełącznik zarządzalny (managed switch) – przydaje się do VLAN-ów i analizy ruchu „na drucie”, zwłaszcza z fizycznymi hostami i np. Raspberry Pi. Do labu stricte wirtualnego w zupełności wystarczają wirtualne sieci hypervisora.
• Raspberry Pi / małe ARM-y – świetne do symulacji IoT, małych sensorów, honeypotów na brzegu sieci. Na start zajmij się jednak porządnym opanowaniem zwykłych VM-ek.

Jeśli jakiś element od kilku tygodni leży w koszyku sklepu i nie umiesz wymyślić dla niego konkretnego scenariusza ćwiczeń – prawdopodobnie jeszcze nie jest potrzebny.

Oszczędne gospodarowanie miejscem na dysku

Dyski w labie mają tendencję do zapełniania się „same z siebie”: każdy nowy obraz ISO, snapshot, backup logów powoli zjada gigabajty. Kilka prostych trików trzyma to w ryzach:

• Obrazy dysków dynamicznych (thin provisioning) – większość hypervisorów domyślnie tworzy dyski, które rosną w miarę użycia. Zostaw tę opcję, zamiast tworzyć od razu 200 GB plików.
• Przechowywanie ISO poza głównym dyskiem – jeśli masz drugi dysk (nawet powolny HDD), wrzuć tam ISO systemów i archiwa starych maszyn.
• Cykliczne sprzątanie snapshotów – snapshot sprzed pół roku do patcha sprzed pół roku rzadko jest jeszcze potrzebny. Zostaw te aktualne, resztę wyeksportuj lub usuń.
• Szablony (template VM) – zamiast stawiać za każdym razem „surową” maszynę od zera, przygotuj 1–2 wzorce (np. czysty Ubuntu serwer + czysty Windows eval) i klonuj je przed ćwiczeniami.

Dobry, lekko ascetyczny lab jest wygodniejszy niż „gigantyczne muzeum ISO z ostatnich 10 lat”. W cyberbezpieczeństwie liczy się to, co faktycznie działa i z czego korzystasz.

Wirtualizacja i izolacja: fundament bezpiecznego labu

Wybór hypervisora: VirtualBox, VMware, Proxmox i inni

Serce domowego labu to hypervisor. Do zastosowań edukacyjnych realnie wchodzą w grę cztery najpopularniejsze rozwiązania:

• VirtualBox – całkowicie darmowy, prosty, ma mnóstwo poradników. Świetny na pierwsze kroki i małe laby „na jednym laptopie”. Wadą bywa wydajność i czasem kłopotliwe dodatki (Guest Additions).
• VMware Workstation Player – również darmowy do użytku niekomercyjnego, zwykle odrobinę stabilniejszy i szybszy od VirtualBoxa, szczególnie pod Windows. Dobra opcja, gdy cenisz wygodę i prosty interfejs.
• Hyper‑V (Windows) – wbudowany w Pro/Enterprise, ale bardziej „serwerowy” w obyciu. Dla osób lubiących Windowsa i chcących uczyć się też zarządzania rolami serwerowymi Microsoftu.
• Proxmox VE / XCP‑ng – platformy typu bare‑metal, czyli system, który instalujesz bezpośrednio na serwerze/PC i z którego zdalnie zarządzasz VM-kami. Świetne, gdy masz osobny host pod lab, chcesz snapshoty, klastry, kontenery itd.

Na start często wygrywa prostota: VirtualBox lub VMware Player na głównym komputerze. Gdy poczujesz, że lab Cię „wciąga” i zaczynasz myśleć o osobnym serwerze, wtedy naturalnie pojawia się Proxmox lub podobne rozwiązanie.

Typy sieci wirtualnych i ich konsekwencje

Każdy hypervisor oferuje różne typy połączeń sieciowych. Konfiguracja jednej opcji potrafi zmienić całe zachowanie labu – i poziom bezpieczeństwa hosta. Najważniejsze tryby:

• NAT – VM wychodzi do Internetu „przez” hosta, z zewnątrz jej nie widać. Bezpieczny i wygodny tryb na start, szczególnie dla maszyn ofiar i testowych.
• Host‑only – maszyny widzą tylko hosta i inne VM-ki w tej samej sieci host-only, ale nie mają bezpośredniego dostępu do Internetu. Idealne dla w pełni odizolowanego labu.
• Bridged – VM zachowuje się jak zwykły komputer w Twojej domowej sieci, dostaje IP z routera. Świetne do testowania rzeczy „jak w realnej sieci”, ale wymaga ostrożności, żeby nie wysyłać exploitów w kierunku routera ISP czy innych domowników.
• Internal Network (w VirtualBox) lub odpowiedniki – sieć widoczna wyłącznie dla wybranych VM-ek, nawet host do niej nie ma dostępu (chyba że dodasz drugą kartę w innej sieci).

Bezpieczna praktyka na początek: atakujący + ofiara w sieci host-only, ewentualnie z wyjściem na Internet przez NAT, a zwykłe użytkowe maszyny (np. codzienny system) trzymać w sieci produkcyjnej / domowej.

Izolacja labu od sieci domowej

Nawet jeśli testujesz exploity na „oficjalnie podatnych” obrazach, zawsze istnieje szansa, że coś zachowa się inaczej, niż oczekujesz. Prosty zestaw zasad pozwala spać spokojniej:

• Oddziel ofiary od sieci domowej – host-only / internal network to podstawowy bezpiecznik. Maszyny z podatnymi serwerami nie muszą mieć dostępu ani do innych domowych sprzętów, ani do Twoich NAS-ów z prywatnymi zdjęciami.
• Nie używaj kont z labu do realnych usług – konta użytkowników, które powstają w labie, nie powinny mieć takich samych haseł jak Twoje konto w banku czy główny e‑mail. To brzmi banalnie, dopóki nie wycieknie Ci przypadkiem plik z hasłami z labu.
• Przemyśl dostęp do Internetu – część ćwiczeń wymaga, część nie. Możesz mieć dwie wersje tej samej maszyny: jedną z dostępem na zewnątrz (aktualizacje, pobieranie narzędzi), drugą zamkniętą w host-only do „brudnej roboty”.

Jeśli w domu działa np. praca zdalna Twoja albo kogoś z domowników, lab powinien być gościem grzecznym, a nie „zabawą w administratora ISP”. Segmentacja wirtualna to tani zamiennik osobnej fizycznej sieci.

Snapshoty, klony i wersjonowanie środowiska

Snapshoty to „punkt przywracania” dla VM. Bez nich domowy lab szybko zamienia się w spalony poligon pełen połowicznie zepsutych instalacji. Kilka zasad, które ratują dużo nerwów:

• Snapshot przed każdym większym eksperymentem – update systemu, instalacja nowego narzędzia, test exploitów w jądrze? Zrób snapshot „przed” z krótkim opisem typu: pre‑kernel‑update.
• Opisuj snapshoty po ludzku – za miesiąc „Snapshot1, Snapshot2, Snapshot3” nic Ci nie powie. „Czysty system”, „Po instalacji ELK”, „Przed testami ransomware” – to już konkret.
• Używaj klonów do osobnych scenariuszy – gdy chcesz równolegle ćwiczyć różne ścieżki na tej samej bazie (np. dwa różne wektory ataku), sklonuj VM-kę w trybie linked/full clone.

Jeśli lab ma żyć dłużej, niż jeden weekend, snapshoty i klony to po prostu podstawowe narzędzia higieny. Dobrze zorganizowany zestaw kilku obrazów z różnymi etapami konfiguracji pozwala szybko wracać do wybranych ćwiczeń bez odtwarzania wszystkiego od zera.

Kontenery jako uzupełnienie wirtualnych maszyn

Coraz więcej osób dorzuca do labu kontenery (Docker, podman), bo są lekkie i błyskawicznie stawiają gotowe usługi. Nie zastępują całkowicie VM-ów, ale świetnie je uzupełniają:

• Szybkie testy aplikacji webowych – podatne aplikacje typu DVWA, Juice Shop, Mutillidae są dostępne jako obrazy Docker. Stawiasz i po chwili masz cel do ataku.
• Usługi pomocnicze – małe serwisy, bazy danych, brokery kolejek (np. Redis, RabbitMQ) do ćwiczeń z logami czy mikroserwisami.
• Łatwe niszczenie i odtwarzanie – gdy ćwiczenie dobiegnie końca, po prostu kasujesz kontener i tworzysz nowy z tego samego obrazu.

Dobrze działa model, w którym system operacyjny trzymasz w VM, a konkretne aplikacje w kontenerach. Masz wtedy jednocześnie realizm systemu i wygodę błyskawicznego wstawiania/wywalania usług.

Wybór systemów operacyjnych i gotowych obrazów do nauki

Systemy dla maszyny atakującej

Rolę „stacji ofensywnej” najczęściej pełni jedna z wyspecjalizowanych dystrybucji Linuxa. Kilka najpopularniejszych, razem z plusami i minusami:

• Kali Linux – klasyk pentesterski. Ogromna liczba narzędzi „out of the box”, mnóstwo poradników, kursów i CTF-ów zakłada, że masz Kali. Wadą bywa to, że początkujący toną w ilości dostępnych programów.
• Parrot Security OS – lżejsza alternatywa dla Kali, część osób chwali stabilność i mniejsze zapotrzebowanie na RAM. Również ma bogaty zestaw narzędzi ofensywnych.
• Standardowa dystrybucja (Ubuntu, Debian) z ręcznie doinstalowanymi narzędziami – świetny sposób, by poznać narzędzia od strony instalacji i konfiguracji, ale wymaga trochę więcej cierpliwości.

Dla pierwszego labu zwykle wygrywa Kali lub Parrot. Później, gdy poczujesz się pewniej, sensowne jest zbudowanie swojej „skrojonej” stacji ofensywnej na bazie zwykłego Debiana/Ubuntu, z dokładnie takim zestawem narzędzi, jakiego potrzebujesz.

Systemy dla maszyn ofiar: Windows i Linux

Strona „ofiary” powinna odzwierciedlać to, co faktycznie spotkasz w świecie. Nawet jeśli pracujesz w większości na Linuxie, Windows pojawi się prędzej czy później – choćby w formie stacji użytkowników.

• Windows
  • Legalne obrazy ewaluacyjne (Enterprise, Server) są dostępne bezpłatnie na stronach Microsoftu do celów testowych.
  • Dla nauki przydatne są: jedna stacja robocza (Windows 10/11) i ewentualnie jedna VM z Windows Server jako „mini‑domena”.
  • Systemy Windows potrafią dobrze wymusić naukę aktualizacji, polityk, AV/EDR oraz pracy z logami zdarzeń.
• Linux
  • Na role serwerów ofiar świetne są: Ubuntu Server, Debian, CentOS/Alma/Rocky (jeśli chcesz klimat Red Hata).
  • Można też użyć specjalnie podatnych dystrybucji, typu Metasploitable, które zawierają mnóstwo klasycznych podatności „w pakiecie”.

Specjalnie podatne obrazy i środowiska treningowe

Po bazowych systemach przychodzi czas na cele stworzone z myślą o treningu. Zamiast przypadkowo „psuć” domowy router, lepiej poćwiczyć na maszynach, które wręcz proszą się o atak.

• Metasploitable 2/3 – klasyczny, podatny Linux (oraz wersja oparta na Windows/Ubuntu). Idealny do nauki Metasploita, klasycznych podatności sieciowych, słabych haseł czy źle skonfigurowanych usług.
• OWASP Broken Web Applications (BWA) – kolekcja podatnych aplikacji WWW w jednym obrazie. Skondensowany kurs SQLi, XSS, CSRF i reszty webowego „zoo”.
• Vulnhub – serwis z gotowymi obrazami VM-ki do pobrania. Każda maszyna to osobny scenariusz, często z opisem poziomu trudności. Dobre, gdy chcesz „mini‑CTF” u siebie, bez konieczności logowania do platformy online.
• TryHackMe / Hack The Box (offline) – większość zabawy to tryb online, ale zdarzają się maszyny do pobrania jako OVA/ISO. Wygodne, jeśli lubisz mieć pełną kontrolę nad siecią i narzędziami monitorującymi.

Dobrym nawykiem jest prowadzenie sobie mini‑listy: który obraz służy do czego, jaki poziom trudności, co już na nim zrobiłeś. Po kilku miesiącach „VulnHub‑VM‑7” nie powie Ci nic o tym, czy ćwiczyłeś tam escalation, czy raczej SQL injection.

Różnorodność usług: serwery, stacje, IoT

Świat nie składa się tylko z jednej stacji Windows + jednego serwera Ubuntu. W labie można (i warto) odwzorować różne typy urządzeń:

• Serwery WWW i API – Apache, Nginx, IIS, małe REST‑owe API w Pythonie lub Node. To naturalny poligon do nauki testów penetracyjnych aplikacji webowych.
• Stacje użytkowników – zwykły Windows z przeglądarką i pakietem biurowym albo Linux Desktop. Tu można ćwiczyć phishing, payloady w dokumentach, makra, keyloggery.
• „Udawane” IoT – pełnego routera ISP w VM nie postawisz, ale małe systemy typu OpenWrt, pfSense czy FreeBSD w roli firewalla już tak. Do tego lekkie systemy z jedną usługą (np. kamery IP, prosty FTP) odtwarzające styl „sprzętu z marketu”.

Nawet prosta kombinacja: serwer WWW + baza danych + stacja użytkownika + router/firewall w środku, daje dużo więcej realizmu niż samotny Metasploitable gdzieś z boku.

Projekt sieci labowej: proste topologie i segmentacja

Najprostszy scenariusz: jeden atakujący, jedna ofiara

Na absolutny początek wystarczą dwie maszyny. Taki „duet” pozwala już zrealizować większość podstawowych ćwiczeń ofensywnych.

• VM‑atakujący – Kali/Parrot w trybie host‑only (ew. druga karta NAT do aktualizacji).
• VM‑ofiara – Metasploitable lub podatny serwer WWW również w sieci host‑only.

Host fizyczny nie jest widoczny z tej sieci, domowy router też nie. Testujesz skanowanie, exploitację i post‑exploitation bez ryzyka strzelania w nieodpowiednie IP.

Mała sieć firmowa w pigułce

Gdy duet przestaje wystarczać, można zbudować mini‑„firmę” na 3–5 VM‑kach. Przykładowy układ:

• Segment LAN – 1–2 stacje Windows (użytkownicy), opcjonalnie jedna stacja Linux.
• Segment serwerów – VM z AD (Windows Server), serwer plików, serwer WWW/Baza.
• Firewall/router – pfSense/OPNsense z dwoma interfejsami: LAN i WAN (NAT do Internetu).
• Stacja atakująca – wpięta albo do „zewnętrznej” sieci (symulacja Internetu), albo
  do osobnego segmentu „red team” za tym samym firewallem.

Wirtualny firewall robi za strażnika: pozwala odtworzyć reguły, VPN, DMZ, a przy okazji uczy konfiguracji, którą później można spotkać w produkcji. To moment, gdy lab zaczyna przypominać coś więcej niż „dwie VM‑ki na krzyż”.

Segmentacja VLAN i kilka podsieci

Jeśli hypervisor wspiera wirtualne przełączniki i VLAN‑y, można pójść krok dalej. Nawet dwa‑trzy VLAN‑y pokazują zupełnie nowe możliwości:

• VLAN 10 – użytkownicy – stacje robocze, drukarki, podstawowe usługi.
• VLAN 20 – serwery – AD, bazy danych, serwery aplikacyjne, plikowe.
• VLAN 30 – lab ofensywny – stacje atakujące, podatne obrazy, narzędzia.

Firewall/router (np. pfSense) ogarnia routing między VLAN‑ami i reguły filtrujące. Można ćwiczyć scenariusze typu: „atak z VLAN 10 na VLAN 20 po błędnej konfiguracji ACL” albo „przeskok z podsieci labowej do produkcyjnej” – oczywiście wszystko nadal w granicach domowego hypervisora.

Oddzielenie ruchu labowego od domowego

Jeżeli lab pracuje na tym samym fizycznym sprzęcie, z którego korzystają inni domownicy, warto zadbać, aby lab miał swoją „piaskownicę”:

• Tworzysz wirtualny przełącznik używający tylko host‑only lub odizolowanej karty fizycznej (np. drugiej karty w PC).
• Domowy ruch (Netflix, praca zdalna, gry) idzie zwykłą kartą sieciową, a lab – swoją oddzielną.
• Jeśli brakuje portów, prosty router za 100–200 zł może pełnić rolę „dedykowanego Internetu” dla labu.

Taki podział pozwala bez stresu puszczać skanery i automaty w sieci labowej, nie ryzykując, że ktoś z domowników nagle straci połączenie podczas ważnego calla, bo akurat floodujesz wszystko, co ma otwarty port 80.

Darmowe narzędzia offensive: skanery, exploity i platformy CTF

Skanery sieci i portów

Skanowanie to pierwszy kontakt z nowym celem. Przydaje się zestaw narzędzi od najprostszych do bardziej zaawansowanych.

• nmap – fundament. Skanowanie portów, wykrywanie usług i wersji, proste skrypty NSE do sprawdzania podatności. Można na nim uczyć się zarówno podstaw (TCP/UDP, SYN/Connect), jak i bardziej wyrafinowanych fingerprintów.
• masscan – nmap w wersji „turbo”. Błyskawicznie przeszukuje duże zakresy IP, ale wymaga ostrożnej konfiguracji, żeby nie wystrzelić sobie w kolano (np. zalewając lab albo własny router).
• rustscan – szybkie sprawdzanie portów z automatycznym przekazaniem wyników do nmapa. Wygodny workflow: rustscan → nmap -A na znalezione porty.

Dobrym ćwiczeniem jest porównywanie wyników z różnych narzędzi na tej samej VB‑ce. Własny „poligon” pozwala eksperymentować z parametrami bez strachu o nieświadome skanowanie Internetu.

Narzędzia do enumeracji usług

Po wykryciu portu i usługi trzeba się wgryźć głębiej. Tu wchodzą w grę narzędzia do enumeracji konkretnego protokołu:

• enum4linux / smbclient – eksploracja udziałów SMB, informacji o domenie Windows, użytkownikach, policy.
• ldapsearch (oraz skrypty NSE do LDAP) – wyciąganie danych z kontrolerów domeny, kont użytkowników, struktur OU.
• impacket (np. secretsdump.py, psexec.py, getTGT.py) – pakiet skryptów do pracy z protokołami Windows/AD. Idealny do scenariuszy post‑exploitation.
• gobuster / feroxbuster – enumeracja katalogów i plików WWW. Pokazuje, że za prostą stroną potrafi się chować ciekawa infrastruktura.

W labie można spokojnie używać agresywniejszych wordlist i długich skanów. Gdy maszyny ofiar należą tylko do Ciebie, nikt nie napisze skargi do działu bezpieczeństwa.

Frameworki exploitacyjne

Ręczne wykorzystywanie podatności jest świetną nauką, ale frameworki eksploitacyjne pokazują, jak może wyglądać „arsenał” działający bardziej automatycznie.

• Metasploit Framework – najbardziej znany zestaw exploitów. Zawiera moduły do rozpoznania, exploitów i post‑exploitation. Dobrze współgra z Metasploitable i wieloma maszynami z VulnHub/CTF.
• Exploit‑DB + searchsploit – baza exploitów w różnej formie. searchsploit pozwala szybko przeszukiwać lokalne repozytorium np. po wersji aplikacji.
• pwntools – biblioteka Pythona do pisania własnych exploitów (szczególnie binarek). Przydatne, gdy wchodzisz w CTF‑y z kategorii pwn i chcesz iść krok dalej niż „gotowy exploit z internetu”.

Dobry nawyk: w labie najpierw spróbować zrozumieć ręcznie, co robi exploit, a dopiero potem odpalić go w Metasploit. Dzięki temu, gdy zobaczysz w firmie starą wersję usługi, nie będziesz jedynie „klikaczem exploitów”.

Narzędzia do testów aplikacji webowych

Bezpieczeństwo webu to osobny świat. Tu przydaje się dedykowany zestaw narzędzi – część działa w przeglądarce, część jako serwery proxy.

• Burp Suite Community Edition – darmowa wersja popularnego proxy. Wystarcza na start do przechwytywania, modyfikacji i odtwarzania żądań, prostych fuzzingów i mapowania aplikacji.
• OWASP ZAP – alternatywa open‑source. Ma skaner automatyczny, sporo dodatków i dobrze integruje się ze skryptami.
• sqlmap – automatyzacja SQL injection. W labie możesz bez wyrzutów sumienia odpalić „pełny arsenał” przeciwko podatnej aplikacji.
• wfuzz / ffuf – fuzzery HTTP, pozwalające szukać ukrytych parametrów, endpointów, poddomen.

Najwygodniej jest mieć w labie dedykowaną VM‑kę z podatnymi aplikacjami webowymi (DVWA, Juice Shop, Mutillidae, BWA), do której ruch idzie wyłącznie przez proxy Burp/ZAP. Łatwo wtedy odtwarzać całe scenariusze krok po kroku.

Narzędzia do uprzywilejowania i post‑exploitation

Gdy pierwsza powłoka już jest, zabawa dopiero się zaczyna. Wtedy korzystasz z narzędzi do lateral movement, eskalacji uprawnień i utrzymania dostępu.

• LinPEAS / WinPEAS – skrypty do wykrywania wektorów eskalacji uprawnień w Linuxie i Windows. Pokazują, jak wiele informacji system sam zdradza, jeśli ktoś wie, gdzie patrzeć.
• BloodHound + SharpHound – mapping zależności i ścieżek ataku w Active Directory. Idealny dodatek do mini‑domeny w labie.
• Mimikatz – znane narzędzie do pracy z poświadczeniami w Windows. W domowym labie lepiej niż gdziekolwiek indziej widać, skąd biorą się „magicznie” zdobyte hasła.
• CrackMapExec – „scyzoryk” do pracy z sieciami Windows: enumeracja, logowanie, wykonywanie poleceń na wielu hostach. Pokazuje, jak niewielka pomyłka w konfiguracji może otworzyć drzwi do całej domeny.

Dla zrównoważenia dobrze mieć równoległą „perspektywę obrońcy”: w tej samej sieci odpalić narzędzia monitorujące, żeby zobaczyć, jak takie akcje wyglądają w logach.

Platformy CTF i laby online jako uzupełnienie

Domowy lab to świetna baza, ale nie zastąpi różnorodności, jaką dają platformy CTF. Dobrze traktować je jak „siłownię” obok własnego podwórka.

• TryHackMe – scenariusze prowadzone krok po kroku. Idealne, gdy dopiero zbierasz narzędzia i chcesz mieć podpowiedzi, co dalej.
• Hack The Box – większy nacisk na samodzielność i kreatywność. Od prostych maszyn po naprawdę skomplikowane środowiska.
• Root‑Me, picoCTF, PortSwigger Web Academy – mniejsze, bardziej wyspecjalizowane zadania, w większości darmowe. Świetne do treningu konkretnych obszarów (np. czysty web, kryptografia, reverse engineering).

Dobrym nawykiem jest odtwarzanie najciekawszych scenariuszy z CTF‑ów w swoim labie: zakładasz podobną usługę, konfigurowany błąd i próbujesz przeprowadzić ten sam atak „na sucho”, ale już bez gotowej infrastruktury platformy.

Narzędzia pomocnicze: listy haseł, generatory, środowisko pracy

Wokół ofensywnych narzędzi jest cała otoczka „pomocników”, bez których praca idzie jak po piasku.

• Seclists – ogromna kolekcja wordlist (hasła, nazwy katalogów, subdomeny, payloady). Montujesz ją w VM‑ce atakującego i praktycznie każde narzędzie ma co „gryźć”.