Junior w cyberbezpieczeństwie: jakie projekty i laby zbudują twoje portfolio IT

Skąd startujesz i dokąd chcesz dojść jako junior w cyberbezpieczeństwie

Osoba, która „lubi grzebać w IT”, zwykle ma za sobą pierwsze laby, proste CTF-y, może trochę Linuxa i ciekawość. Rekruter i lider zespołu szukają jednak kogoś, kto potrafi udowodnić: umiem postawić środowisko, zrozumieć incydent, odtworzyć atak, napisać prosty skrypt, udokumentować wynik. Różnica bywa jak między „lubię gotować” a „mam sensowne portfolio dań, które ktoś zjadł i przeżył.

Różnica między hobby a portfolio pod rekrutację

Hobby w cyberbezpieczeństwie to:

• klikanie w narzędzia typu Kali bez zrozumienia, co robią,
• uczestnictwo w losowych CTF-ach bez notowania rozwiązań,
• instalowanie kolejnych dystrybucji Linuxa „bo wszyscy tak robią”,
• oglądanie filmów o pentestingu bez odtwarzania kroków u siebie.

Portfolio pod rekrutację to zestaw konkretnych artefaktów:

• repozytoria z konfiguracjami, skryptami i instrukcjami uruchomienia,
• raporty z incydentów lub pentestów, które da się przeczytać jak dokument służbowy,
• diagramy i opisy własnych labów,
• linki do skończonych, opisanych projektów (GitHub, GitLab, blog techniczny).

Rekruter nie ocenia, ile godzin spędziłeś przy komputerze, tylko czy te godziny przełożyły się na powtarzalne efekty, które da się pokazać i omówić w trakcie rozmowy.

Główne ścieżki w cyberbezpieczeństwie a dobór projektów

Już na starcie warto z grubsza określić kierunek. Nie po to, żeby się na zawsze zamknąć w jednym pudełku, ale po to, żeby projekty miały wspólny mianownik. Klasyczne ścieżki dla juniora:

• SOC / Blue Team – monitorowanie, analiza logów, reagowanie na incydenty.
• Pentest / Red Team – testy penetracyjne, symulacje ataków.
• Bezpieczeństwo aplikacji (AppSec) – analiza kodu, testy bezpieczeństwa aplikacji webowych i API.
• GRC / Risk / Compliance – polityki, normy, procesy, ryzyko (bardziej „papierowe”, ale nadal z technicznym kontekstem).

To, co pokazujesz w portfolio, musi być spójne z kierunkiem:

• dla SOC – laby z SIEM, EDR, logami, alertami,
• dla pentestu – laby z atakami end-to-end, raportami, narzędziami własnej produkcji,
• dla AppSec – demonstracje typowych podatności (OWASP Top 10) i sposobów ich naprawy,
• dla GRC – mniej labów, więcej szablonów polityk, analiz ryzyka, mapowania norm na realne systemy (choć nawet tam prosty homelab z siecią firmową pomaga „nie pisać w próżni”).

Na poziomie juniora dobrze jest mieć trzon w jednej ścieżce i 1–2 projekty zahaczające o inne obszary. Na przykład: „chcę do SOC” – więc większość projektów to zbieranie i analiza logów, a obok tego jeden mały pentest-lab, żebyś zrozumiał perspektywę atakującego.

Jak uczciwie ocenić punkt wyjścia

Planowanie labów ma sens dopiero wtedy, gdy wiesz, z jakiego miejsca startujesz. Prosta autodiagnoza:

• Systemy: czy potrafisz zainstalować Windows i Linuxa, dodać użytkownika, zmienić uprawnienia, zainstalować paczki, zrozumieć logi systemowe?
• Sieci: czy rozumiesz różnicę między IP prywatnym a publicznym, TCP vs UDP, podstawy DNS, co robi NAT, co to brama domyślna?
• Linux + CLI: czy umiesz swobodnie poruszać się po konsoli, korzystać z grep, sed, awk, ssh, tail, journalctl/logów?
• Skrypty: czy napisałeś kiedykolwiek cokolwiek w Bash/Pythonie/PowerShellu, co coś automatyzowało, a nie tylko „hello world”?

Jeżeli na większość z tych pytań odpowiadasz „nie do końca” – pierwszy krok to nie jest instalacja Kali, tylko zbudowanie fundamentów i dopiero na nich labów security. Bez tego będziesz tylko klikać w narzędzia, nie rozumiejąc, co faktycznie robią.

Co lider chce zobaczyć w portfolio juniora

Lider zespołu bezpieczeństwa zazwyczaj ma trzy pytania:

1. Czy ta osoba umie się uczyć na żywych przykładach?
2. Czy potrafi udokumentować swoją pracę tak, żeby inni mogli ją powtórzyć?
3. Czy ma choć minimalne zrozumienie kontekstu biznesowego (wie, że „serwer to nie tylko IP do zeskanowania”, ale system kogoś ważnego)?

Dlatego portfolio powinno zawierać projekty, w których widać:

• opis problemu (np. „chciałem zrozumieć, jak wygląda atak bruteforce w logach Windows”),
• architekturę labu (schemat, wypisane VM-ki),
• kroki techniczne (konfiguracja, komendy, narzędzia),
• wnioski (czego się nauczyłeś, co byś poprawił).

„Zainteresowania: cyberbezpieczeństwo, Linux, sieci” na CV nie znaczą nic. Seria trzech–czterech konkretnych projektów z linkami do GitHuba – bardzo dużo.

Fundamenty przed pierwszym labem – bez tego lab stanie się dekoracją

Minimum techniczne, żeby lab miał sens

Homelab do cyberbezpieczeństwa przy braku podstaw kończy jako ładny zrzut ekranu z Kali i Metasploitem. Wrażenie na znajomych – średnie. Wrażenie na rekruterze – żadne. Żeby projekty miały realną wartość, potrzebne jest minimum techniczne:

• Sieci: model TCP/IP, pojęcie portu, różnice między TCP a UDP, adresacja IPv4 (maska, podsieć), co robi router, czym jest VLAN, jak działa DNS (rekordy A, CNAME, MX), po co NAT.
• Systemy: podstawy administracji Windows (usługi, logi, użytkownicy, uprawnienia), Linux (system plików, użytkownicy/grupy, uprawnienia, pakiety).
• Wiersz poleceń: w praktyce 90% narzędzi security żyje w terminalu. Swobodne poruszanie się po CLI to „język ojczysty” w tej branży.
• Wirtualizacja: rozumiesz, co to jest hypervisor, snapshot, NAT vs bridge, jak działają sieci wewnętrzne w VirtualBoksie/VMware.

Nie chodzi o poziom eksperta, tylko o swobodę w podstawach. Narzędzia security tylko odsłaniają to, co dzieje się w systemie i sieci. Jeśli ich nie rozumiesz, każdy raport nmapa będzie zagadką, a każdy log – ścianą tekstu.

Dlaczego sama znajomość narzędzi to pułapka

Typowy błąd początkujących: lista narzędzi w CV dłuższa niż lista zadań domowych w technikum. Kali, Burp, Metasploit, Wireshark, Nessus, Hydra… i tak dalej. Problem w tym, że bez kontekstu technicznego te narzędzia zamieniają się w magiczne przyciski „scan” i „exploit”.

Przykład: uruchamiasz nmap -sV 192.168.1.10, widzisz otwarte porty 22 i 80. Jeśli nie wiesz, że:

• 22 to zwykle SSH (zdalna powłoka),
• 80 to HTTP (serwer webowy),
• za nimi kryją się konkretne usługi, wersje, konfiguracje,

to nmap jest po prostu kolorowym skanerem. Tymczasem sensowne projekty security polegają na rozumieniu kontekstu: co ten port oznacza, jak ta usługa jest wystawiona, co może być podatne.

Dlatego kolejność powinna być odwrotna:

1. Zrozumienie, jak działa system i sieć.
2. Dopiero potem – jak narzędzia pomagają te systemy i sieci badać, monitorować, atakować.

Krótki plan naprawczy pod fundamenty

Jeżeli widzisz braki w podstawach, dobry plan na 2–3 miesiące to:

• Tydzień 1–3: Linux + CLI
  • postaw sobie jedną VM-kę z Ubuntu / Debian / Rocky Linux,
  • codziennie pracuj w terminalu: pliki, katalogi, uprawnienia, użytkownicy, systemd, logi, ssh, podstawowe narzędzia sieciowe (ping, traceroute, ip/ifconfig, netstat/ss),
  • zapisuj wszystkie przydatne komendy i ich zastosowania w jednym pliku README.
• Tydzień 4–6: sieci
  • konfiguruj statyczne IP na VM-kach,
  • zrozum, jak działają podsieci /24, /25, /26,
  • postaw prosty serwer HTTP i pinguj go z innej VM-ki,
  • zobacz pakiety w Wiresharku, prześledź handshake TCP.
• Tydzień 7–8: Windows i logi
  • postaw Windowsa (np. Windows 10/11 lub serwerowy trial),
  • poćwicz zarządzanie użytkownikami, politykami, logami (Event Viewer),
  • przetestuj logowanie lokalne, nieudane logowania, RDP.

Do każdego z tych kroków można od razu dorzucić mały element security – choćby prosty skrypt monitorujący logi czy konfigurację zapory.

Łączenie teorii z małymi labami

Zamiast „czytać do oporu, a potem kiedyś coś zbudować”, lepiej traktować każdy moduł wiedzy jako pretekst do mikro-labu:

• uczysz się o DNS – zbuduj prosty serwer DNS w labie i zrób atak typu DNS spoofing w odizolowanej sieci,
• uczyć się o logach – wygeneruj kilka nieudanych logowań i sprawdź, jak wyglądają w systemie i w SIEM-ie,
• uczyć się o protokołach – użyj Wiresharka, żeby „zobaczyć” HTTP, TLS, SSH.

Każdy taki mikro-lab opisujesz w krótkim pliku: cel, kroki, rezultat, wnioski. Po kilku tygodniach masz luźno powiązane notatki, które można połączyć w jeden większy projekt.

Jak zbudować pierwszy prosty homelab do cyberbezpieczeństwa

Wybór platformy wirtualizacji

Do zbudowania homelabu junior w cyberbezpieczeństwie nie potrzebuje serwerowni w piwnicy. W większości przypadków wystarczy laptop z 16 GB RAM (8 GB da się przeżyć, ale będzie boleć) i dyskiem SSD. Najpopularniejsze opcje:

Na start zwykle wystarcza VirtualBox lub VMware Player. Kiedy poczujesz, że lab cię ogranicza, można wynieść się na Proxmoxa na jakimś używanym mini-PC.

Minimalny zestaw maszyn w labie juniora

Prosty homelab do nauki cyberbezpieczeństwa może składać się z:

• 1 VM z Windows – np. Windows 10/11 lub Server (czasowe licencje developerskie/testowe są dostępne),
• 2 VM z Linuxem:
  • Linux-„serwer” (np. Ubuntu Server) – do instalacji usług: web, DNS, SSH, logowanie,
  • Linux-„atakujący” – np. Kali lub Parrot,
• 1 VM z routerem/firewallem – pfSense albo OPNsense, żeby poćwiczyć segmentację i logi z zapory.

Taki zestaw pozwala stworzyć wirtualną „mini-firmę”: masz klienta, serwer, atakującego i firewall między nimi. Na tej bazie można budować laby pod SOC, pentest, a nawet AppSec.

Prosta topologia sieci wirtualnej – „mini-firma” na twoim laptopie

Żeby lab nie był zbiorem losowych VM-ek, potrzebna jest choć symboliczna architektura. Wystarczy mała topologia, która imituje prostą firmę:

• sieć „wewnętrzna” – tam siedzą Windows-klient i serwer Linux,
• firewall/router między siecią wewnętrzną a „internetem”,
• maszyna atakująca podpięta po drugiej stronie firewalla (jako pseudo-internet).

W VirtualBoksie możesz to odwzorować tak:

• Sieć wewnętrzna (Internal Network) – np. o nazwie LAN_INTERNAL, adresacja 192.168.10.0/24.
• Sieć zewnętrzna – NAT lub druga sieć wewnętrzna, np. 10.10.10.0/24 dla „internetu labowego”.
• pfSense/OPNsense ma dwa interfejsy:
  • LAN – 192.168.10.1 (podpięty do LAN_INTERNAL),
  • WAN – 10.10.10.1 (podpięty do „zewnętrznej” sieci).
• Windows i Linux-serwer siedzą w LAN_INTERNAL, dostają IP z DHCP z firewalla lub statyczne.
• Linux-atakujący jest w „internacie” – w sieci 10.10.10.0/24.

W ten sposób możesz:

• testować ataki z „internetu” na wewnętrzne systemy,
• śledzić, co rejestruje firewall,
• bawić się regułami: blokuj, loguj, przepuszczaj tylko wybrane porty.

Rysunek tej architektury (nawet zrobiony w darmowym draw.io) to pierwsza rzecz, jaką warto dodać do README z projektem.

Bezpieczeństwo labu – jak nie zhakować samego siebie

Lab ma być piaskownicą, a nie nowym źródłem malware w domowej sieci. Kilka prostych zasad robi różnicę:

• Maszyny podatne (np. OWASP Juice Shop, Metasploitable, słabe konfiguracje) trzymaj w sieci wewnętrznej, bez mostkowania do domowego routera.
• Jeśli wystawiasz coś na bridge (most do fizycznej sieci), rób to świadomie i bez znanych backdoorów czy exploitów typu „all ports open, come in”.
• Nie loguj się z podatnych VM-ek na swoje prywatne konta (mail, social media, bankowość). To proszenie się o kłopoty.
• Regularnie rób snapshoty VM-ek przed eksperymentami – rollback po zepsutym systemie czy ransomware w labie to kwestia minut.
• Wyłącz udostępnianie folderów host <-> VM, kiedy ćwiczysz malware lub nieznane skrypty.

Na etapie rekrutacji dobrze brzmi adnotacja w opisie projektu: krótko, jak zadbałeś o odizolowanie labu. Pokazuje, że myślisz o ryzyku, nie tylko o „hakerce”.

Pierwszy projekt: prosty serwer www + podstawowe skanowanie

Najłatwiej zacząć od czegoś banalnego i wykorzystać to na kilka sposobów. Przykładowy pierwszy projekt:

1. Na Linux-serwerze instalujesz prosty web serwer:
   • sudo apt install apache2 lub nginx,
   • wrzucasz prosty index.html (może być „Hello, lab”).
2. Na Windowsie sprawdzasz, czy strona się ładuje po IP serwera.
3. Na Linux-atakującym uruchamiasz:
   • nmap -sV -p- IP_SERWERA – wszystkie porty, fingerprint usług,
   • prostą enumerację HTTP (np. nikto lub gobuster na katalogi).
4. Na firewallu włączasz logowanie ruchu i patrzysz, jak wyglądają połączenia skanera.

Z tak prostej konfiguracji możesz wyciągnąć materiał na całkiem sensowny wpis:

• jak zmiana konfiguracji serwera (np. wyłączenie listingu katalogów) wpływa na wynik skanowania,
• jak firewall widzi ruch nmapa przy różnych typach skanu (-sS, -sT),
• jak wyglądają logi Apache/Nginx przy prostym dirbustingu.

Po kilku takich iteracjach „prostego serwera” zaczynasz rozumieć, co właściwie widzisz w narzędziach, zamiast tylko odpalać kolejne przełączniki.

Projekty dla przyszłego blue team / SOC – monitorowanie i reagowanie

Budowa centralnego logowania – pierwszy krok w stronę SIEM

Bez logów analityk SOC jest ślepy. Dobrą bazą pod całe portfolio jest projekt „centralny system logowania”:

1. Wybierasz stack:
   • ELK / OpenSearch (Elasticsearch + Logstash + Kibana / OpenSearch Dashboard),
   • lub Wazuh (SIEM + HIDS na bazie ELK),
   • lub prostsze Graylog, jeśli chcesz mniejszą złożoność.
2. Stawiasz serwer logów na Linux-serwerze w labie.
3. Konfigurujesz:
   • winlogbeat/Winlogbeat/Agent Wazuh na Windowsie,
   • filebeat/agent na Linux-„serwerze”,
   • syslog z firewalla (pfSense ma gotową integrację po UDP/TCP).

Po uruchomieniu masz jedno miejsce, gdzie zbiegają się logi z całego labu. W portfolio możesz pokazać:

• schemat przepływu logów (host → agent → serwer logów → dashboard),
• konfigurację podstawowych filtrów / indexów,
• zrzuty ekranu z pierwszych prostych dashboardów (logowania, błędy, ruch z firewalla).

To jest fundament – pod każdy kolejny projekt SOC-owy możesz dopinać scenariusze ataków i incydentów, a logi już się archiwizują.

Scenariusz 1: bruteforce na konta i korelacja logów

Klasyk w SOC: dużo nieudanych logowań. Nie trzeba mieć Red Teama, żeby to zasymulować.

1. Na Windowsie:
   • tworzysz kilka kont użytkowników,
   • ustawiasz politykę kont (blokada po N nieudanych logowaniach).
2. Z Linux-atakującego:
   • używasz narzędzia typu hydra lub prostego skryptu PowerShell/ Bash, żeby generować nieudane logowania (RDP, SMB lub lokalnie przez próbę mapowania udziału).
3. W systemie logów:
   • tworzysz query, które wyciąga zdarzenia typu Logon Failure,
   • agregujesz je po IP lub nazwie użytkownika.

Następny krok to zbudowanie alertu:

• X nieudanych logowań w Y minut z jednego IP,
• blokada konta → osobny alert (żeby zobaczyć, jak wygląda „eskalacja” problemu w logach).

Rozsądne jest opisanie w README:

• jak wygenerowałeś ruch,
• jakie event ID użyłeś (np. 4625 w Windows),
• jak sparametryzowałeś alert (co uznajesz za podejrzane).

Na rozmowie technicznej można wtedy przejść krok po kroku: „pokaż query”, „co byś zmienił, żeby zmniejszyć false positive’y”.

Scenariusz 2: detekcja podejrzanego PowerShella i komend administracyjnych

PowerShell jest ulubionym narzędziem atakujących, ale i administratorów. Różnica tkwi w zachowaniu, nie w samym fakcie użycia.

1. Na Windowsie:
   • włączasz szczegółowe logowanie PowerShell (Script Block Logging / Module Logging),
   • instalujesz Sysmon z sensowną konfiguracją (np. popularny config SwiftOnSecurity czy własny, okrojony).
2. Generujesz „złe zachowania”:
   • prosta komenda typu Invoke-WebRequest ściągająca plik z „zewnętrznego” serwera,
   • kodowanie Base64 w parametrach PowerShella,
   • uruchomienie PowerShell z przełącznikiem -ExecutionPolicy Bypass.
3. Na serwerze logów:
   • budujesz query po Event ID związanych z PowerShell i po Sysmonie (proces powershell.exe / pwsh.exe),
   • szukasz konkretnych stringów (np. DownloadString, FromBase64String).

Z tego da się zrobić mini-playbook reagowania:

• jakie są pierwsze kroki analityka, gdy widzi podejrzaną komendę (sprawdzenie użytkownika, hosta, powiązanych procesów),
• jak odróżniasz legitymne skrypty administracyjne od potencjalnego malware (godzina, kontekst, nietypowy użytkownik).

Opis w repozytorium nie musi być książką – nawet pół strony, ale pokazywać tok myślenia, a nie tylko konfigurację Sysmona.

Scenariusz 3: ruch sieciowy – od skanu portów do prostego C2

Druga noga SOC-u to sieć. Tu przydaje się firewall i narzędzia typu Zeek/Suricata, ale można zacząć skromniej.

• Na firewallu:
  • włączasz logowanie połączeń wychodzących i przychodzących,
  • ustawiasz regułę, która loguje każdy pakiet na wybrany host (np. Linux-serwer).
• Na Linux-serwerze:
  • instalujesz tcpdump i/lub Wiresharka,
  • przechwytujesz ruch na interfejsie wewnętrznym podczas:
    • skanu nmapa z maszyny atakującej,
    • zwykłego ruchu webowego z Windowsa.

Możesz pójść krok dalej:

• uruchomić prosty „pseudo-C2” – np. cykliczne połączenia HTTP z klienta do serwera co 10 sekund z losowym payloadem,
• zobaczyć, jak wygląda w logach firewalla i w przechwyconych pakietach taki „beaconing”.

W portfolio dobrze opisać:

• jak różni się „normalny” ruch użytkownika od skanu (częstotliwość, porty, flagi TCP),
• jaką prostą regułę wykrywania skanów/podejrzanego beaconu byś zaproponował (nawet opisowo, bez pełnego silnika reguł).

Mini-projekt: własny dashboard SOC-owy

Ponad surowymi logami rekruterzy lubią zobaczyć, że jesteś w stanie „opowiedzieć historię” w danych. Dobry krok to zbudowanie jednego porządnego dashboardu:

• Panel logowań:
  • liczba udanych vs nieudanych logowań w czasie,
  • top 10 adresów IP z nieudanymi próbami,
  • top 10 kont z błędnymi hasłami.
• Panel ruchu sieciowego:
  • top 10 portów docelowych z firewalla,
  • liczba połączeń blokowanych vs dopuszczonych,
  • mapka źródeł (nawet jeśli wszystkie IP są „lokalne”, można to zamienić w pseudo-geolokalizację dla treningu).

W README dodajesz krótki opis: jakie pytania dla analityka ten dashboard pomaga szybko zadać i na co odpowiada. To pokazuje, że rozumiesz, po co to robisz, a nie tylko „bo tak było w tutorialu ELK”.

Projekty dla przyszłego red team / pentestera – atakowanie z głową

Cel ataku w labie – świadomie podatna aplikacja

Zamiast skakać od jednego CTF-a do drugiego, lepiej mieć jeden dobrze opisany, powtarzalny scenariusz ataku w swoim labie. Najprościej oprzeć go o gotowe podatne aplikacje:

• OWASP Juice Shop – podatna aplikacja webowa, świetna do nauki OWASP Top 10,
• Damn Vulnerable Web Application (DVWA),
• Vulnerable by Design (np. VulnHub, bWAPP).

Instalujesz taką aplikację na Linux-serwerze w swojej „mini-firmie” i traktujesz jak aplikację klienta. Dodatkowo na firewallu ustawiasz reguły, żeby ruch szedł przez „internet labowy”, a nie bezpośrednio po NAT hosta.

Kluczowe nie jest samo „zhakowanie” aplikacji (bo to bywa opisane krok po kroku w internecie), tylko twoja dokumentacja:

• jak odkrywałeś podatności,
• jak je weryfikowałeś,
• jakie były potencjalne skutki biznesowe.

Mini-ścieżka: od rozpoznania do prostego raportu z testu aplikacji

Samo „kliknięcie podatności” w Juice Shopie czy DVWA to dopiero rozgrzewka. W portfolio dużo lepiej wygląda opisany, prosty flow pentestu aplikacji – nawet jeśli dzieje się w twoim homelabie.

1. Rozpoznanie aplikacji:
   • mapujesz funkcjonalności (rejestracja, logowanie, koszyk, wyszukiwarka, panele admina),
   • robisz krótką listę URL-i z podziałem na:
     • publiczne,
     • wymagające logowania,
     • podejrzanie brzmiące (np. /admin, /debug, /backup).
2. Proxy i intercept:
   • stawiasz Burp Suite / OWASP ZAP jako proxy,
   • konfigurujesz przeglądarkę labową, żeby cały ruch szedł przez proxy,
   • robisz spacer po aplikacji, łapiąc żądania i odpowiedzi.
3. Identyfikacja punktów wejścia:
   • formularze, parametry GET/POST, nagłówki, ciasteczka,
   • API – jeżeli aplikacja korzysta z endpointów REST/GraphQL, dodajesz je do osobnej sekcji.
4. Priorytetyzacja testów:
   • na początek klasyki: SQLi, XSS, IDOR, słabe logowanie,
   • później ciekawsze rzeczy: manipulacja uprawnieniami, logika biznesowa.

Do repozytorium wrzucasz:

• zrzut ekranu mapy aplikacji z Burpa/ZAP-a,
• prostą tabelkę (CSV/Markdown) z listą endpointów i krótkim opisem,
• 2–3 przykłady żądań HTTP (surowe, jako załącznik), przy których później „coś znalazłeś”.

Taki mini-proces pokazuje, że nie działasz na ślepo. Nawet jeżeli znajdziesz tylko drobnego XSS-a, rekruter widzi, że rozumiesz, jak się „dociera” do podatności.

Scenariusz: klasyczny XSS / SQLi od A do Z

Najlepiej wziąć jeden typ podatności i zrobić go porządnie – od odkrycia po rekomendacje. Na potrzeby portfolio spokojnie wystarczy skromny scenariusz:

1. Odkrycie podatności:
   • w polu wyszukiwarki wpisujesz prosty payload, np. '"<script>alert(1)</script>,
   • obserwujesz, czy apka poprawnie encoduje znaki, czy wypluwa to „na surowo”.
2. Eksploatacja:
   • jeśli payload się wykonuje – dokumentujesz krok po kroku (screeny, pełne żądanie i odpowiedź),
   • sprawdzasz, czy XSS jest:
     • reflected (w odpowiedzi na to samo zapytanie),
     • stored (zapisuje się w bazie, widzą go inni użytkownicy).
3. Rozszerzenie scenariusza:
   • czy można wykraść ciasteczko sesyjne (w labie, nie u realnego klienta),
   • czy jesteś w stanie wykonać akcję w imieniu innego użytkownika (CSRF + XSS).
4. Minimalne „łatanie”:
   • szukasz w kodzie, gdzie parametr jest wyświetlany bez filtrowania,
   • dodajesz prostą filtrację / encodowanie, np. w Node/Expressie, PHP czy Pythonie.

Na koniec robisz mini-raport (1–2 strony) z czterema sekcjami:

• Opis podatności – krótko, bez przepisów z OWASPa,
• Wykorzystanie – powtarzalne kroki, żeby można było odtworzyć błąd,
• Ryzyko – co realnie może się stać (np. przejęcie sesji użytkownika),
• Propozycja naprawy – co trzeba zmienić w kodzie/konfiguracji.

To jest złoto na rozmowę: ustawiasz laptopa, otwierasz raport, pokazujesz lab i przechodzisz przez scenariusz. Nagle nie jesteś „kolejnym juniorem po kursie X”, tylko osobą, która faktycznie coś rozpracowała.

Atak na warstwę uwierzytelniania – bruteforce, słabe hasła, reset hasła

Drugi dobry scenariusz red-teamowy to rozgryzienie mechanizmów logowania i resetu hasła w podatnej aplikacji. W labie możesz sobie na to pozwolić bez wyrzutów sumienia.

1. Analiza formularza logowania:
   • sprawdzasz, czy jest limit błędnych logowań,
   • czy pojawiają się komunikaty typu „użytkownik nie istnieje”, „złe hasło” (przydatne do enumeracji).
2. Prosty bruteforce:
   • budujesz małą listę haseł (np. najpopularniejsze hasła z top-1000),
   • używasz narzędzia typu hydra / ffuf / moduł Intruder w Burpie,
   • sprawdzasz, czy w logach (twoje ELK/Wazuh) pojawia się charakterystyczny pattern błędnych logowań.
3. Enumeracja użytkowników:
   • obserwujesz różne komunikaty błędów przy istniejącym vs nieistniejącym użytkowniku,
   • sprawdzasz endpoint „zapomniałem hasła” – czy zdradza, czy użytkownik istnieje.
4. Reset hasła:
   • analizujesz link resetujący (token w URL, czas życia, możliwość odgadnięcia),
   • testujesz proste manipulacje: ponowne użycie tokena, skrócenie/wydłużenie, zmiana ID użytkownika.

W dokumentacji warto dorzucić kilka refleksji z perspektywy obrony:

• jakie zabezpieczenia byś tu dołożył (CAPTCHA, blokady, komunikaty „neutralne”),
• jakie alerty w swoim SIEM-ie ustawiłbyś na masowe próby resetu hasła czy logowania.

Taki scenariusz fajnie łączy red i blue: z jednej strony pokazujesz, jak atakujesz, z drugiej – jak byś się sam przed sobą bronił.

Pivoting w homelabie – z podatnego hosta do „serwera firmy”

Red team nie kończy pracy na jednym hoście. Nawet w małym homelabie jesteś w stanie pokazać prosty lateral movement i pivoting, bez wymyślnych narzędzi.

1. Topologia labu:
   • masz podatną maszynę w sieci „DMZ” (np. z Juice Shopem),
   • masz wewnętrzny serwer (np. Windows Server / Linux „serwer plików”),
   • firewall między nimi (pfSense/opnsense), który blokuje ruch bezpośredni z twojego hosta do sieci wewnętrznej.
2. Przejęcie hosta w DMZ:
   • np. RCE przez podatną aplikację,
   • uzyskujesz powłokę (reverse shell / SSH, jeśli „admin” był leniwy).
3. Rozpoznanie z przejętego hosta:
   • skan wewnętrznej podsieci (nmap z hosta w DMZ),
   • sprawdzenie, jakie porty/hosty są widoczne tylko z jego perspektywy.
4. Pivoting:
   • tunel SSH z DMZ do twojej maszyny (np. dynamiczny SOCKS, ssh -D),
   • konfiguracja proxychains na twoim hostcie, żeby ruch szedł przez przejętą maszynę,
   • skanowanie/eksploatacja serwera wewnętrznego „przez” DMZ.

W portfolio to możesz opisać jako mini-„kill chain”:

• inicjalny wektor (podatna aplikacja),
• eksploatacja i ustanowienie dostępu,
• ruch boczny do kolejnego hosta.

Dla bonusu możesz dopisać, jakie ślady zostawiasz w logach (na serwerze, firewallu, w SIEM-ie), czyli naturalny punkt zaczepienia do rozmowy z kimś z blue teamu.

Scenariusz phishingowy w kontrolowanych warunkach

Nie ma red teamu bez socjotechniki, ale nie trzeba od razu wysyłać maili do połowy świata. W mini-firmie w labie da się odtworzyć bezpieczny scenariusz phishingowy.

1. Infrastruktura:
   • mailserver w labie (np. hMailServer na Windows, postfix/dovecot na Linuxie),
   • kilka kont użytkowników w twojej „firmie”,
   • prosta strona phishingowa (np. login przypominający O365 / panel firmy), hostowana na innym serwerze w labie.
2. Przygotowanie kampanii:
   • krótki mail typu „Twoje hasło wygasa, zaloguj się, żeby przedłużyć dostęp”,
   • link prowadzący do twojej fałszywej strony,
   • logowanie requestów na stronie phishingowej (np. zapisujesz login/hasło do pliku lub bazy w labie).
3. Symulacja ofiar:
   • logujesz się z różnych kont testowych z „naiwnym” hasłem,
   • obserwujesz logi mailservera, serwera www, ewentualnie proxy/IDS.

W opisie projektu dobrze wyraźnie zaznaczyć, że:

• wszystko dzieje się w labie, na twoich własnych kontach i domenach,
• scenariusz służy tylko do nauki i zrozumienia, jakie ślady zostawia phishing.

Możesz też dopisać „perspektywę SOC”: jakie reguły antyphishingowe, jakie szkolenia czy mechanizmy (MFA, filtry) zablokowałyby ten konkretny atak.

Łączenie red i blue – jeden incydent, dwa punkty widzenia

Najbardziej przekonujący projekt to taki, w którym opisujesz jeden incydent zarówno oczami atakującego, jak i obrońcy. Nawet prosty scenariusz z labu potrafi tu zrobić wrażenie.

Może to wyglądać tak:

1. Wybierasz scenariusz:
   • np. SQLi w podatnej aplikacji → przejęcie konta admina → próba ruchu bocznego,
   • albo: phishing → logowanie na fejkowej stronie → logowanie atakującego na konto ofiary.
2. Strona red:
   • krok po kroku, jak wykonałeś atak,
   • konkretne komendy, requesty, narzędzia,
   • co uważałeś za „sukces” na każdym etapie.
3. Strona blue:
   • jakie logi się pojawiły (event ID, typy zdarzeń, źródła),
   • jak wyglądałby alert w twoim SIEM-ie,
   • jak brzmiałby krótki opis incydentu w systemie ticketowym.
4. Mini-playbook:
   • jakie byłyby 3–4 pierwsze działania analityka (izolacja hosta, reset haseł, blokada IP, snapshot maszyny),
   • jak byś zweryfikował, czy atak się nie powtarza.

W repozytorium można to rozdzielić na dwa katalogi:

• /red – skrypty, payloady, screeny z narzędzi ofensywnych,
• /blue – query do SIEM-a, screeny dashboardów, przykładowe alerty.

Taki projekt jest szczególnie mocny, jeśli aplikujesz do roli, w której firma liczy na to, że będziesz rozumieć „drugą stronę barykady”, niezależnie, czy idziesz w pentest, czy w SOC.

Jak opisać laby i projekty, żeby faktycznie pracowały na twoje portfolio

Struktura repozytorium – porządek ważniejszy niż liczba narzędzi

Trzy średnie projekty opisane z sensem robią lepsze wrażenie niż dziesięć losowych screenów. Warto trzymać się powtarzalnej struktury repozytoriów, żeby rekruter od razu wiedział, gdzie czego szukać.

Przykładowy układ:

• /docs – opisy architektury, raporty z testów, diagramy,

Najczęściej zadawane pytania (FAQ)

Od czego zacząć naukę cyberbezpieczeństwa jako kompletny początkujący?

Na samym początku lepiej odpuścić Kali i „hakowanie wszystkiego”. Pierwszy krok to fundamenty: systemy operacyjne (Windows i Linux), sieci komputerowe oraz swoboda w wierszu poleceń. Bez tego narzędzia security będą tylko kolorowym interfejsem bez zrozumienia, co się naprawdę dzieje.

Dobry start to jedna maszyna z Linuxem (np. Ubuntu) i zwykłe zadania: praca w terminalu, użytkownicy, uprawnienia, logi, podstawowe komendy sieciowe. Do tego proste ćwiczenia z sieci (IP, podsieci, TCP/UDP, DNS) i później dorzucenie Windowsa, żeby zobaczyć, jak wyglądają logi i konta w praktyce. Dopiero na takim gruncie laby bezpieczeństwa zaczynają mieć sens.

Jakie projekty do portfolio są dobre dla juniora w cyberbezpieczeństwie?

Najbardziej liczą się projekty, które da się powtórzyć i pokazać krok po kroku. Dla rekrutera ważne jest, żeby zobaczyć: jak stawiasz środowisko, jak analizujesz problem, jak dokumentujesz wnioski. Zrzuty ekranu z Kali bez opisu nie robią roboty.

Przykładowe projekty do portfolio to m.in.:

• homelab z kilkoma VM-kami, z opisanym ruchem sieciowym i logami,
• prosty raport z „pentestu” własnego labu (cele, kroki, wynik, rekomendacje),
• demo kilku podatności z OWASP Top 10 z pokazaniem, jak je naprawić,
• opisany incydent w stylu SOC: co się stało, jak to zobaczyłeś w logach, co zmieniłeś.

Kluczem jest dokumentacja: repozytorium z konfiguracjami, skryptami, plus czytelny opis.

Jakie laby budować pod SOC / Blue Team, a jakie pod pentesting?

Jeśli celujesz w SOC/Blue Team, skup się na labach z logami i monitoringiem. Ustaw kilka VM-ek, wygeneruj proste „ataki” (np. bruteforce logowania, skanowanie portów), zbierz logi w jednym miejscu (SIEM open-source, nawet prosty stack ELK) i pokaż, jak wykrywasz zdarzenia. Pokaż też, jakie wnioski wyciągasz z alertów.

Dla pentestingu liczą się laby „end-to-end”: atak od rekonesansu, przez eksploatację, po eskalację uprawnień i raport. Może to być np. podatna aplikacja webowa na własnym serwerze, atak z użyciem standardowych narzędzi (nmap, Burp, Metasploit) i dokładnie opisane kroki oraz rekomendacje naprawy. Jeden dobrze opisany scenariusz jest lepszy niż 10 anonimowych screenów z CTF-ów.

Czy udział w CTF-ach wystarczy, żeby zdobyć pracę w cyberbezpieczeństwie?

Same wyniki z CTF-ów rzadko wystarczą. Dla juniora mają sens tylko wtedy, gdy z każdego zadania zostaje ślad: write-up, repozytorium z rozwiązaniem, notatki. Rekruter nie jest w stanie nic wywnioskować z opisu „brałem udział w 20 CTF-ach”.

Jeśli lubisz CTF-y, wybieraj zadania zbliżone do realnych problemów (web, forensics, pwn) i po każdym zadaniu rób krótką dokumentację: jak wyglądał problem, jakie narzędzia i techniki zastosowałeś, co cię zaskoczyło. Z dwóch–trzech solidnych write-upów można już zbudować sensowny element portfolio.

Jak sprawdzić, czy mam wystarczające podstawy, żeby zacząć laby z bezpieczeństwa?

Prosty test: odpowiedz sobie szczerze na kilka pytań. Czy potrafisz zainstalować Windows i Linuxa, dodać użytkownika, zmienić mu uprawnienia, przejrzeć logi? Czy wiesz, czym się różni adres IP prywatny od publicznego, TCP od UDP, co robi NAT i DNS? Czy po wejściu do terminala nie czujesz się jak turysta bez słownika?

Jeżeli większość odpowiedzi to „średnio”, zrób 2–3 miesiące „treningu podstaw”: Linux + CLI, sieci, trochę administracji Windows. Możesz od razu dorzucać mini-zadania security, typu prosty skrypt monitorujący logi czy testowanie konfiguracji firewalla. To jak nauka jazdy: zanim pojedziesz na tor wyścigowy, dobrze jest opanować skrzyżowania.

Co konkretnie chce zobaczyć lider zespołu bezpieczeństwa w portfolio juniora?

Lider zwykle patrzy na trzy rzeczy: czy umiesz uczyć się na żywych przykładach, czy potrafisz udokumentować swoją pracę i czy widzisz choć trochę kontekst biznesowy. Samo „znam Kali, Burpa i Wiresharka” to za mało.

W praktyce portfolio powinno zawierać:

• krótki opis problemu lub celu (np. „chciałem zobaczyć, jak wygląda skanowanie portów w logach systemu”),
• schemat lub opis architektury labu (jakie VM-ki, jaka sieć, jakie role),
• konkretne kroki: komendy, konfiguracje, użyte narzędzia,
• wnioski – co z tego wynika, co byś poprawił, co można by zrobić w firmowym środowisku.

Taki projekt pokazuje, że jesteś w stanie nie tylko „klikać”, ale i pracować jak członek zespołu.

Jak długo budować portfolio z labami, zanim zacznę wysyłać CV na juniora w cyber?

Nie ma jednej magicznej liczby miesięcy, ważniejsza jest jakość. Często wystarczy 3–6 miesięcy systematycznej pracy, żeby zebrać 3–4 sensowne, dobrze opisane projekty powiązane z wybraną ścieżką (SOC, pentest, AppSec, GRC). Lepiej mieć mniej projektów, ale dopracowanych, niż „listę rzeczy, które kiedyś zacząłem”.

Dobry moment na start z CV jest wtedy, gdy:

• swobodnie stawiasz proste laby w wirtualizacji,
• rozumiesz podstawy sieci i systemów bez zaglądania w notatki co 30 sekund,
• masz portfolio online (GitHub, GitLab, blog) z projektami, o których potrafisz opowiadać technicznie na rozmowie.

Od tego momentu równolegle rozwijasz kolejne laby i wysyłasz aplikacje – praktyka i tak przyspieszy, gdy pojawią się pierwsze rozmowy.

Najważniejsze punkty

• Różnica między „lubię cyberbezpieczeństwo” a kandydatem do zatrudnienia polega na tym, czy potrafisz udowodnić efekty swojej pracy: postawione środowisko, przeanalizowany incydent, odtworzony atak, działający skrypt i sensowna dokumentacja.
• Portfolio to nie lista narzędzi ani godzin spędzonych przy komputerze, tylko konkretne artefakty: repozytoria z konfiguracją i instrukcją, raporty z incydentów/pentestów, diagramy labów i linki do skończonych projektów, które da się omówić na rozmowie.
• Projekty muszą być spójne z wybraną ścieżką (SOC, pentest, AppSec, GRC); lepiej mieć trzon w jednym kierunku i 1–2 projekty zahaczające o inne obszary niż przypadkową kolekcję „rzeczy z YouTube’a”.
• Bez podstaw systemów, sieci, CLI i wirtualizacji homelab staje się tylko ładnym zrzutem ekranu z Kali – najpierw trzeba ogarnąć fundamenty, dopiero potem ma sens zabawa w „security”.
• Lider szuka osoby, która uczy się na realnych przykładach i potrafi po sobie zostawić ślad: opis problemu, architekturę labu, konkretne kroki techniczne oraz wnioski, a nie tylko screen z nmapa.
• Sam udział w CTF-ach, instalowanie kolejnych dystrybucji i „klikanie w narzędzia” bez zrozumienia to hobby; rekruterów interesuje praca, którą ktoś będzie w stanie powtórzyć według twojej dokumentacji.
• Lista narzędzi w CV nie zastąpi kilku dobrze opisanych projektów – trzy–cztery sensowne laby z linkami do GitHuba znaczą więcej niż imponujący spis technologii, których dotknąłeś raz na kursie.