Które projekty open source warto znać, budując własne domowe laby bezpieczeństwa

Od pomysłu do własnego labu: po co i dla kogo jest domowe środowisko bezpieczeństwa

Typowe cele: nauka, praca, czysta ciekawość

Domowe laby bezpieczeństwa powstają z różnych powodów, ale najczęściej wracają trzy motywacje: chęć nauki cyberbezpieczeństwa od praktycznej strony, przygotowanie do pracy lub certyfikatów oraz zwykła ciekawość tego, jak działają ataki i obrona w sieci. Zamiast czytać o atakach SQL Injection czy skanowaniu portów, można zobaczyć je na żywo, w kontrolowanym i odizolowanym środowisku.

Lab przydaje się osobom, które myślą o karierze w bezpieczeństwie ofensywnym (pentester, red team), defensywnym (SOC, blue team, administrator bezpieczeństwa) albo hybrydowym (DevSecOps, inżynier bezpieczeństwa aplikacji). W każdym z tych obszarów te same projekty open source można wykorzystać na trochę inne sposoby: ktoś z nastawieniem ofensywnym ćwiczy głównie narzędzia atakujące, a osoba od obrony buduje monitoring, korelację zdarzeń i reagowanie na incydenty.

Domowy lab bezpieczeństwa ma też dużą wartość dla administratorów i inżynierów sieci, którzy chcą rozumieć „drugą stronę”. Widząc, jak prosto wygląda skanowanie nmapem czy próby bruteforce’u na serwerze SSH, inaczej podchodzi się do konfiguracji firewalli, segmentacji sieci i polityk haseł. Nawet jeśli celem nie jest praca w bezpieczeństwie, taki lab uczy higieny i pozwala realnie ograniczyć ryzyko w codziennej pracy.

Trzecia grupa to osoby po prostu ciekawe technologii. Chcą pobawić się Kali Linuxem, pootwierać ruch w Wiresharku, postawić kilka maszyn podatnych z VulnHub i zobaczyć, jak to wszystko „gada”. W ich przypadku kluczowe jest, by nie przeginać z komplikacją – kilka dobrze dobranych narzędzi open source zamiast kilkudziesięciu losowo zainstalowanych programów.

Jak dużo wiedzy technicznej potrzeba na start

Obawa „nie jestem adminem, nie dam rady” pojawia się u wielu osób na początku. Do zbudowania pierwszego, prostego domowego labu bezpieczeństwa wystarczy solidna znajomość obsługi komputera, podstawy systemu operacyjnego i gotowość do czytania instrukcji. Na starcie nie są potrzebne głębokie umiejętności sieciowe ani zaawansowana administracja serwerami.

Najbardziej przydaje się kilka umiejętności bazowych:

• swobodne poruszanie się po systemie (Windows, Linux, macOS),
• podstawy pracy w terminalu (chociażby umiejętność wpisania kilku komend i zrozumienia ścieżek),
• rozumienie, czym jest adres IP, sieć lokalna, router domowy,
• umiejętność czytania dokumentacji projektów open source.

Reszta przychodzi w trakcie. Wiele osób właśnie dzięki labowi uczy się Linuksa, TCP/IP, protokołów sieciowych i działania firewalli. Istotne jest tylko, by nie próbować na początku odwzorowywać korporacyjnej infrastruktury z VLAN-ami, tunelem VPN, kilkoma serwerami domeny i SIEM-em klasy enterprise. Zamiast tego lepiej zacząć od dwóch–trzech maszyn wirtualnych i prostego scenariusza atak–obrona.

Minimalne wymagania sprzętowe i przykład konfiguracji startowej

Domowe laby bezpieczeństwa nie wymagają specjalistycznego sprzętu, choć więcej RAM-u i sensowny procesor zdecydowanie ułatwiają życie. Najprostszy punkt startu to laptop lub komputer stacjonarny z minimum 16 GB RAM (da się zacząć z 8 GB, ale będzie ciasno) i dyskiem SSD. Na takim sprzęcie uruchomisz jednocześnie system hosta i kilka lekkich maszyn wirtualnych.

Prosty przykład konfiguracji startowej:

• Host: Windows 10/11 lub Linux (np. Ubuntu Desktop),
• Hypervisor: VirtualBox (łatwy start) lub Proxmox na osobnej maszynie, jeśli masz stary serwer/PC,
• Maszyny: jedna Kali Linux (narzędzia ofensywne), jedna dystrybucja podatna (np. Metasploitable lub OWASP BWA), ewentualnie jeden Windows jako „oficjalny” cel.

Jeśli masz do dyspozycji stary komputer, można go przekształcić w hosta dla Proxmoxa VE – darmowej, open source’owej platformy wirtualizacji. Komputer główny (laptop) staje się wtedy tylko „konsolą” zarządzającą, a wszystkie cięższe maszyny chodzą na Proxmoxie w sieci lokalnej. To wygodny scenariusz dla osób, które prędzej czy później i tak dołożą kolejne elementy do labu.

Dlaczego open source dominuje w domowych labach bezpieczeństwa

Środowisko cyberbezpieczeństwa w naturalny sposób przyciąga projekty open source. Narzędzia służące do analizy, testów penetracyjnych i monitoringu często powstają oddolnie, jako efekt pracy badaczy bezpieczeństwa i społeczności. Dzięki otwartemu kodowi łatwo je audytować, modyfikować i dostosowywać do potrzeb konkretnego labu.

Główne zalety open source w domowych labach bezpieczeństwa to:

• brak kosztów licencyjnych przy prywatnym użyciu,
• ogromna ilość dokumentacji, tutoriali i przykładów,
• częste aktualizacje i szybkie łatanie błędów,
• łatwość integracji z innymi projektami (API, moduły, skrypty).

Druga strona medalu to chaos narzędzi. Każdy projekt ma swoje wersje, forki, niekompatybilne zależności i metody instalacji. Bez przemyślanego planu można szybko skończyć z dziesiątkami narzędzi, z których używa się dwóch. Dlatego tak ważne jest świadome wybranie kilku kluczowych projektów open source, które faktycznie wspierają cele labu, zamiast instalowania wszystkiego, co „fajne”.

Lab ofensywny, defensywny i mieszany – krótkie rozróżnienie

Domowe laby bezpieczeństwa można z grubsza podzielić na trzy typy: ofensywne (red team), defensywne (blue team) i mieszane. Każdy typ stawia w centrum inne projekty open source, choć sporo narzędzi będzie wspólnych.

Lab ofensywny skupia się na narzędziach typu Kali Linux, Metasploit, frameworki do exploitacji, skanery podatności, narzędzia webowe (OWASP ZAP). Cele to głównie podatne maszyny (VulnHub, Metasploitable, własne serwery) i ćwiczenie pełnego łańcucha ataku.

Lab defensywny stawia na monitoring, IDS/IPS (Suricata, Snort), systemy logowania i analizy (ELK, Wazuh), narzędzia do zbierania i korelacji zdarzeń. Scenariusze obejmują wykrywanie skanowań, prób logowań, nietypowego ruchu czy anomalii na hostach.

Lab mieszany łączy jedno i drugie: z jednej strony narzędzia ofensywne generują ataki, z drugiej strony systemy defensywne próbują je wykryć i zarejestrować. To najbardziej wartościowe podejście dla osób, które chcą zrozumieć cały cykl: od rekonesansu po reakcję na incydent. Projekty open source idealnie nadają się do takiego „przeciągania liny” między czerwonym a niebieskim zespołem… nawet jeśli oba „zespoły” to jedna osoba.

Fundamenty techniczne labu: system bazowy, wirtualizacja i sieć

Jaki system hosta wybrać: Windows, Linux czy macOS

System hosta to fundament całego labu. Od niego zależy dostępność sterowników, wydajność wirtualizacji oraz komfort pracy z narzędziami open source. Dla wielu osób naturalnym wyborem będzie Windows, bo jest już zainstalowany na laptopie. Nie ma w tym nic złego, pod warunkiem, że świadomie wykorzystasz jego możliwości i ograniczenia.

Windows + WSL + VirtualBox/Hyper-V to popularne połączenie. Windows zapewnia wygodę codziennego użycia, WSL (Windows Subsystem for Linux) daje dostęp do części narzędzi linuksowych, a VirtualBox lub Hyper-V uruchamia maszyny wirtualne z Kali, podatnymi serwerami i Windowsami-ofiarami. Wadą może być nieco niższa wydajność i większa złożoność konfiguracji sieci w porównaniu z natywnym Linuksem.

Linux jako host (np. Ubuntu, Debian, Fedora) zapewnia bardzo dobrą integrację z hypervisorami open source (KVM/Libvirt, QEMU), świetną obsługę narzędzi sieciowych i dostęp do większości projektów open source „od ręki”. To świetny wybór, jeśli chcesz zanurzyć się w świat bezpieczeństwa na poważniej i nie przeszkadza ci praca na Linuksie jako głównym systemie.

macOS także nadaje się na hosta, choć wybór hypervisorów jest mniejszy (VirtualBox, UTM, komercyjny VMware Fusion). Narzędzia bezpieczeństwa można częściowo uruchamiać natywnie w terminalu, resztę w VM-kach. Minusem jest mniejsza elastyczność w konfiguracji sieci i trudniejszy dostęp do niektórych sterowników, ale dla użytkownika Maców to nadal rozsądna baza.

Hypervisory i platformy labowe open source

Wybór hypervisora decyduje o tym, jak łatwo będzie zarządzać maszynami wirtualnymi i jak bardzo lab może się rozbudować. W domowych labach bezpieczeństwa królują trzy rozwiązania open source: VirtualBox, KVM/Libvirt oraz Proxmox VE.

VirtualBox jest najprostszy na start. Działa na Windows, Linuxie i macOS. Instalacja obrazów ISO z Kali czy Metasploitable jest banalna, a interfejs graficzny ułatwia osobom mniej technicznym pierwsze kroki. Wadą jest mniejsza wydajność i ograniczone możliwości zaawansowanej segmentacji sieciowej, choć do prostych scenariuszy w zupełności wystarcza.

KVM/Libvirt + virt-manager to zestaw natywnych technologii wirtualizacji dla Linuksa. Daje bardzo dobrą wydajność, duże możliwości konfiguracji sieci (bridge, NAT, sieci izolowane) i zintegrowane narzędzia (virt-manager, virsh). Dla użytkowników Linuksa to naturalny wybór, a przy okazji świetne ćwiczenie z administrowania serwerami.

Proxmox VE jest kompletną platformą wirtualizacji klasy „domowy data center”. Instalowany na gołym metalu, oferuje webowy interfejs, wsparcie dla VM-ów (KVM) i kontenerów (LXC), snapshoty, klastrowanie i zaawansowaną sieć. Proxmox to idealny fundament dla osób, które mają osobny sprzęt pod lab i myślą o rozbudowie (np. kilka węzłów, segmentacja VLAN, dedykowane serwery logów).

Open source’owe narzędzia do zarządzania VM i siecią w labie

Nawet w małym labie szybko docenia się wygodne narzędzia do zarządzania maszynami i ich połączeniami. Świat open source dostarcza kilka sprawdzonych projektów, które mocno upraszczają codzienną pracę.

virt-manager to graficzny front-end dla KVM/Libvirt. Pozwala tworzyć i zarządzać maszynami, konfigurować ich sieci (bridge, NAT, izolowane) i przydzielać zasoby. Przydaje się, gdy hostem jest Linux, a chcesz mieć „klikany” dostęp do wirtualizacji.

Cockpit jest webowym interfejsem administracyjnym dla serwerów Linux. Dodatkowe moduły pozwalają zarządzać VM-kami KVM/Libvirt, monitorować zasoby, przeglądać logi. W labie bezpieczeństwa można go wykorzystać jako centralny punkt zarządzania hostem-wirtualizatorem.

Panel Proxmoxa to dla wielu osób pierwszy kontakt z bardziej zaawansowaną wirtualizacją. Przeglądarkowy interfejs umożliwia tworzenie sieci typu NAT, bridge, VLAN-y, zarządzanie snapshotami i replikacją. W połączeniu z Proxmoxem Proxmox Backup Server można zbudować w pełni darmową, rozbudowaną platformę labową.

Segmentacja sieci w labie bez doktoratu z sieci

Dobrze zaprojektowana sieć w labie bezpieczeństwa to klucz do realistycznych ćwiczeń. Segmentacja pozwala oddzielić „świat ofiar” od „świata narzędzi ofensywnych” i reszty domowej infrastruktury. Nie trzeba od razu wchodzić w złożone VLAN-y – wystarczą podstawowe tryby sieci wirtualnej.

Najczęściej używane tryby to:

• NAT – maszyny mają dostęp do internetu przez hosta, nie są widoczne z zewnątrz; dobre dla Kali, która ma pobierać aktualizacje, ale nie musi być dostępna z LAN-u,
• host-only / sieci wewnętrzne – maszyny widzą się nawzajem i hosta, ale nie mają dostępu do internetu; świetne do izolowanych scenariuszy atak–obrona,
• bridge – maszyny są pełnoprawnymi urządzeniami w sieci domowej (dostają IP z routera), co ułatwia integrację, ale wymaga uwagi, by nie „wypuścić” podatnych systemów na świat.

W wielu hypervisorach (VirtualBox, Proxmox) można jedną kartę sieciową VM-ki skonfigurować jako host-only (do komunikacji wewnętrznej), a drugą jako NAT (do pobierania aktualizacji). Dzięki temu podatne maszyny pozostają odizolowane od domowej sieci, ale stacja narzędziowa ma internet, by pobrać aktualne exploity czy aktualizacje dystrybucji.

Bezpieczna izolacja: jak nie wystawić złośliwego labu na prawdziwy internet

Jedna z najrozsądniejszych obaw: „czy odpalając malware w labie, mogę przypadkiem zainfekować domową sieć?”. Ryzyko można znacząco ograniczyć, jeśli od początku trzyma się kilku zasad i wykorzystuje możliwości, które dają projekty open source i sam hypervisor.

• Używaj sieci typu host-only / internal dla najbardziej podatnych maszyn i tych, na których testujesz malware.
• Wyłącz udostępniane foldery między hostem a VM-ką w scenariuszach z nieznanym oprogramowaniem.
• Na hoście skonfiguruj firewall, który blokuje przychodzące połączenia do portów używanych przez maszyny labowe (np. rule w Windows Firewall lub iptables/nftables na Linuksie).
• Korzystaj ze snapshotów przed większymi eksperymentami – jeśli coś pójdzie nie tak, przywrócenie stanu sprzed testów zajmuje chwilę.

Dystrybucje bezpieczeństwa jako serce labu: Kali, Parrot, BlackArch i spółka

Kali Linux – klasyk do testów penetracyjnych

Kali to dla wielu pierwsza dystrybucja „od bezpieczeństwa”. Ma świetne wsparcie społeczności, masę gotowych tutoriali i setki narzędzi zainstalowanych domyślnie. W labie domowym sprawdza się jako główna „stacja ofensywna” – punkt startowy do skanowania, exploitacji i analizy ruchu.

Najprostszy model: jedna główna VM-ka z Kali, aktualizowana i pielęgnowana, a obok niej zestaw podatnych systemów. Dzięki temu nie trzeba instalować narzędzi na każdej maszynie – wszystko jest pod ręką w jednym miejscu.

Przydatne warianty Kali w kontekście labu:

• Standardowa wersja desktopowa – wygodna, jeśli spędzasz dużo czasu w GUI (Burp, przeglądarka, Wireshark),
• Kali w wersji „Light” lub bez środowiska graficznego – do lżejszych VM-ek, gdzie większość pracy robisz w terminalu (np. na słabszym sprzęcie),
• Kali w WSL – sensowny kompromis na Windowsie, jeśli nie chcesz jeszcze stawiać pełnej VM-ki, ale potrzebujesz narzędzi linuksowych.

Dobry nawyk: trzymać jeden „czysty” obraz Kali (snapshot po instalacji i podstawowej konfiguracji), a do eksperymentów klonować go jako osobne VM-ki. Gdy środowisko „zarosną” śmieciami i eksperymentalnymi pakietami, wystarczy skasować klon i utworzyć nowy.

Parrot Security – lżejsza alternatywa z myślą o prywatności

Parrot Security OS bywa ciekawszy dla osób, które obawiają się „ciężkości” Kali albo chcą mieć lepsze wsparcie pod kątem prywatności (domyślne twarde ustawienia, narzędzia kryptograficzne, sandboxing). W labie domowym różnica nie jest dramatyczna, ale na starszym laptopie Parrot potrafi działać zauważalnie sprawniej.

Dodatkowy atut – przyzwoity zestaw narzędzi do analizy forensycznej i pracy z dokumentami (np. pakiet biurowy), więc Parrot może pełnić rolę zarówno stacji ofensywnej, jak i codziennego desktopa w labie.

BlackArch – dystrybucja dla lubiących Arch Linux

BlackArch to rozszerzenie Arch Linux o ogromne repozytoria narzędzi bezpieczeństwa. Dobrze pasuje do osób, które:

• lubią filozofię Arch (rolling release, pełna kontrola),
• chcą samodzielnie decydować o każdym pakiecie i konfiguracji,
• nie boją się rozwiązywania problemów, gdy rolling release „coś popsuje”.

W labie można podejść hybrydowo: host na stabilnym Linuksie (Debian/Ubuntu), a BlackArch jako VM-ka – stacja narzędziowa dla bardziej wyspecjalizowanych pakietów. To dobry pomysł, jeśli brakuje jakiegoś rzadkiego narzędzia w Kali/Parrot, a jest dostępne w repozytorium BlackArch.

Dystrybucje defensywne: Security Onion, SELKS i spółka

Środowisko defensywne ma własne „gwiazdy” w świecie open source. Najpopularniejsze są:

• Security Onion – gotowa platforma do monitoringu bezpieczeństwa: Suricata/Zeek, Elastic, Kibana, narzędzia do analizy pakietów i logów. Idealna jako centralny sensor w labie mieszanym, który podsłuchuje sieć „ofiar”.
• SELKS (od Stamus Networks) – dystrybucja z Suricatą, Elasticsearch, Logstash, Kibana, Scirius. Szybsza w konfiguracji niż ręczne składanie stosu IDS + ELK od zera.
• Wazuh (często na zwykłym Ubuntu/Debianie) – EDR/HIDS open source z serwerem centralnym i agentami na hostach. W labie świetnie pokazuje, jak wygląda korelacja zdarzeń z wielu maszyn.

Sensowna mini-architektura: jedna VM-ka z Security Onion/SELKS nasłuchująca ruchu z segmentu „podatnych ofiar” oraz osobna VM-ka z Wazuhem i agentami na systemach Windows/Linux. Do tego Kali/Parrot generują realne ataki, które widać w dashboardach.

Systemy-ofiary: podatne maszyny do ćwiczeń

Bez podatnych systemów lab szybko staje się muzeum narzędzi. Dobrze mieć kilka łatwo powtarzalnych scenariuszy, opartych o znane projekty:

• Metasploitable 2/3 – klasyczne zestawy podatności do nauki pracy z Metasploitem i ręcznej exploitacji.
• OWASP Broken Web Applications, WebGoat, Juice Shop – webowe środowiska treningowe, świetne do ćwiczeń z Burpem, OWASP ZAP i manualnym testowaniem aplikacji.
• VulnHub, Hack The Box (klient + prywatne VPN) – obrazy lub zdalne maszyny, które można włączać w własny lab, tworząc scenariusze zbliżone do CTF.

Dobrym nawykiem jest oznaczanie podatnych VM-ek np. w nazwach („VULN-win7”, „VULN-web-lab”), by nie pomylić ich z innymi systemami w sieci, szczególnie jeśli używasz trybu bridge i host widzi je jak zwykłe komputery w LAN-ie.

Kluczowe narzędzia sieciowe w open source: od skanowania do monitoringu

Odkrywanie i mapowanie sieci: Nmap, Masscan i spółka

Pierwszy krok w większości scenariuszy – zobaczyć, co właściwie działa w sieci labowej. Do tego służą:

• Nmap – klasyk do skanowania portów, identyfikacji usług, wersji oprogramowania i systemów operacyjnych. Pozwala też tworzyć skrypty NSE do automatyzacji odkrywania podatności.
• Masscan – ultrafast skaner portów. Przydaje się, gdy lab rośnie i trzeba szybko przeskanować większy zakres adresów (np. /16) albo kilka segmentów testowych.

Dobry, prosty scenariusz na start: postaw kilka VM-ek (Windows, Linux, podatna aplikacja webowa) w sieci host-only, a następnie:

1. użyj Nmapa do pełnego skanu segmentu,
2. porównaj wynik z tym, co sam ręcznie skonfigurowałeś na hostach (otwarte porty, serwisy),
3. przełącz się na Masscana i zobacz różnice w szybkości.

Sniffing i analiza ruchu: Wireshark, tcpdump, Arkime

Monitorowanie ruchu w labie buduje intuicję: jak wygląda normalny ruch HTTP, jak wyglądają próby logowań, gdzie widać exploit. Wśród projektów open source wyróżniają się:

• tcpdump – lekki, konsolowy sniffer. Idealny do szybkiego przechwycenia ruchu na interfejsie VM-ki lub interfejsie bridge na hoście. Zapisuje pliki pcap, które można później analizować w Wiresharku.
• Wireshark – bogate GUI, filtry wyświetlania, dekodery tysięcy protokołów. W labie możesz analizować np. wymianę podczas logowania do SSH czy surowe zapytania HTTP w czasie ataku.
• Arkime (dawniej Moloch) – system do pełnotekstowego indeksowania ruchu sieciowego i jego przeszukiwania. Przydaje się, gdy chcesz wracać do ruchu sprzed kilku dni i analizować go jak logi.

Praktyczna mini-architektura: na hoście Proxmox/KVM tworzysz port mirroring na wirtualnym switchu i wysyłasz kopię ruchu do osobnej VM-ki „sensorowej” z Wiresharkiem lub Arkime. To pozwala oglądać cały ruch między ofiarami i stacją ofensywną, bez „doklejania” sniffera do każdej maszyny.

IDS/IPS w labie: Suricata, Snort, Zeek

Systemy IDS/IPS to serce obronnej części labu. Trzy najpopularniejsze projekty open source:

• Suricata – silnik IDS/IPS nowej generacji, obsługuje wielowątkowość, detekcję na poziomie aplikacji, TLS i HTTP, integruje się z regułami Emerging Threats. W labie może pracować w trybie czysto pasywnym (IDS) lub aktywnie blokować ruch (IPS).
• Snort – klasyczny IDS, nadal szeroko używany, z bogatym zestawem reguł. Jako projekt do nauki pisania reguł i rozumienia podstaw detekcji sprawdza się bardzo dobrze.
• Zeek (dawniej Bro) – platforma analityczna, która zamiast skupiać się na sygnaturach, generuje szczegółowe logi o aktywnościach w sieci. Dobry pomost między światem „IDS na sygnaturach” a podejściem bardziej analitycznym.

Typowy scenariusz w labie mieszanym:

1. Suricata lub Snort nasłuchuje ruchu z segmentu podatnych maszyn.
2. Generujesz ataki z Kali (np. skanowanie Nmap, prosty exploit HTTP).
3. Obserwujesz, które reguły się odpalają, a następnie tuningujesz je (np. wyciszasz noisy alerty, dopisujesz własne reguły do konkretnych podatności w swoim labie).

Monitorowanie hostów i logów: ELK, Graylog, Wazuh

Samo patrzenie na ruch sieciowy nie wystarczy. Drugim filarem labu defensywnego są logi z systemów i aplikacji. Tu królują projekty:

• ELK Stack (Elasticsearch, Logstash, Kibana) – klasyczna trójka, umożliwiająca gromadzenie logów z wielu hostów, ich parsowanie i wizualizację. Możesz w jednym miejscu przeglądać zdarzenia z Windowsa, Linuksa, aplikacji webowych i IDS.
• Graylog – alternatywa dla ELK z własnym webowym interfejsem i mechanizmami do zarządzania strumieniami logów. Często prostszy do ogarnięcia dla początkujących niż „goły” Elastic.
• Wazuh – oprócz zbierania logów oferuje HIDS, monitorowanie integralności plików, detekcję rootkitów, korelację zdarzeń. Dobry jako „centralny mózg” małego SOC-a w labie.

Jedno z prostszych ćwiczeń: skonfiguruj Windows Server i jedną stację roboczą tak, by wysyłały logi (np. przez Winlogbeat) do ELK/Wazuha, a następnie:

• spróbuj kilku normalnych akcji (logowanie, instalacja programu),
• wykonaj symulowany atak z Kali (brute-force RDP/SSH, próba exploitacji SMB),
• porównaj, które zdarzenia w logach odróżniają normalne działania od ataku.

Open source’owe firewalle i routery w labie: pfSense, OPNsense, VyOS

Jeśli masz w labie więcej niż jeden segment sieci (np. sieć ofiar, sieć adminów, stacja ofensywna), wygodnie jest zbudować wirtualny router/firewall. W roli „wirtualnego edge’a” dobrze sprawdzają się:

• pfSense – oparte na FreeBSD rozwiązanie z rozbudowanym GUI, obsługą VLAN-ów, VPN, reguł firewall i pakietów (np. Snort, Suricata). Dobre jako centralna brama między segmentami labu.
• OPNsense – fork pfSense, z odświeżonym interfejsem i częstszymi aktualizacjami. Równie użyteczny jako wirtualny firewall w Proxmoxie/VirtualBoxie.
• VyOS – linuksowy system routerowy dla osób, które wolą CLI i konfigurację „jak na dużym routerze”. Uczy „prawdziwej” administracji siecią.

Proste, ale skuteczne ustawienie: VM-ka pfSense z dwoma lub trzema interfejsami – jeden do internetu (NAT z hypervisora), jeden do sieci „ofiar”, jeden do sieci „red team”. Dzięki temu możesz ustawiać reguły, które przepuszczają tylko określone typy ruchu, a przy okazji ćwiczysz zarządzanie firewallem jak w realnej infrastrukturze.

Frameworki ofensywne open source: Metasploit, exploit-db i narzędzia webowe

Metasploit Framework – szkielet do exploitacji w labie

Metasploit to dla wielu osób synonim „frameworku ofensywnego”. W labie domowym pozwala zrozumieć pełen łańcuch ataku: od wyszukania podatności, przez dobór exploita, aż po utrzymanie sesji na przejętym hoście.

Podstawowe elementy, z którymi warto się oswoić:

• auxiliary modules – skanery, moduły fuzzujące, pomocnicze narzędzia (np. brute-forcery),
• exploit modules – właściwe exploity na konkretne podatności,
• payloads – np. Meterpreter, reverse shell, bind shell,
• post modules – działania po udanym włamaniu (eskalacja uprawnień, zbieranie informacji, pivoting).

Typowy labowy scenariusz z Metasploitem:

1. Na VM-ce Metasploitable uruchamiasz podatną usługę (np. vsftpd, usługę webową).
2. Na Kali/Parrot używasz Nmapa, by zidentyfikować usługę i wersję.
3. W Metasploicie szukasz modułu exploita dopasowanego do wersji (np. komenda search).
4. Konfigurujesz payload (np. Meterpreter reverse TCP), uruchamiasz exploit i uzyskujesz sesję.
5. Ćwiczysz moduły post-exploitation – enumerację użytkowników, pivoting na inne hosty w labie.

Exploit-DB, Searchsploit i GitHub jako źródła wiedzy o podatnościach

Metasploit to nie wszystko. W wielu scenariuszach wygodniej lub konieczne jest użycie exploitów spoza frameworka. Źródła open source, które dobrze mieć pod ręką:

Praktyczne wykorzystanie Exploit-DB w domowym labie

Exploit-DB to przede wszystkim baza gotowych exploitów i proof-of-conceptów. W labie domowym świetnie nadaje się do odtwarzania historycznych podatności i zrozumienia, jak wygląda cykl „CVE → exploit → poprawka”.

Podstawowe elementy ekosystemu wokół Exploit-DB:

• Exploit-DB (strona WWW) – przeszukiwanie exploitów po nazwie aplikacji, CVE, typie podatności, platformie. Dobre, gdy wiesz, czego szukasz (np. konkretnego CVE z raportu).
• Searchsploit – konsolowy frontend do Exploit-DB, dostępny domyślnie w Kali i innych dystrybucjach bezpieczeństwa. Działa offline po zaktualizowaniu lokalnej bazy exploitów.
• Mirrory na GitHubie – projekty, które kopiują Exploit-DB, umożliwiając łatwiejszą integrację z własnymi narzędziami (np. skrypty w Pythonie).

Dobry sposób na oswojenie się z Exploit-DB to odtworzenie klasycznych CVE na podatnych maszynach (Metasploitable, VulnHub, DVWA, Juice Shop). Schemat pracy może wyglądać tak:

1. Skanujesz maszynę Nmapem, identyfikujesz usługę i wersję (np. Apache 2.4.49).
2. Uruchamiasz searchsploit apache 2.4.49 i sprawdzasz dostępne exploity.
3. Czytasz opis exploita i wymagania (wersja, konfiguracja, parametry).
4. Tworzysz kopię podatnej aplikacji w labie i dostosowujesz ją tak, aby zgadzały się warunki z opisu.
5. Uruchamiasz exploit, a potem modyfikujesz go (np. zmiana payloadu, sposobu łączenia) i obserwujesz, co się dzieje.

Przy pierwszym kontakcie z Exploit-DB wiele osób boi się kompilowania exploitów w C lub modyfikowania Pythona. W labie ryzyko jest niewielkie – jeśli coś „wysadzisz”, najwyżej odtworzysz snapshot maszyny. To właśnie dobre miejsce na eksperymenty, które w środowisku produkcyjnym byłyby zbyt ryzykowne.

GitHub jako kopalnia narzędzi ofensywnych

Poza Exploit-DB masy exploitów i narzędzi lądują dziś bezpośrednio na GitHubie. To tam pojawiają się pierwsze proof-of-concepty dla świeżych CVE, skrypty automatyzujące całe łańcuchy ataków czy frameworki dla konkretnych technologii (np. Active Directory, Kubernetes).

Przykładowe kategorie repozytoriów, które dobrze mieć na radarze:

• PoC dla konkretnych CVE – pojedyncze skrypty, często proste, ale idealne do odtworzenia podatności w labie (np. popularne RCE w serwerach WWW, VPN-ach, aplikacjach do backupu).
• Frameworki pod AD i Windows – np. Impacket, BloodHound, C