Laboratorium 2

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Efekty uczenia się: W1, U1, U3, K1.

Głównym celem zadania jest opanowanie metodyki bezpiecznego rekonesansu oraz inwentaryzacji zasobów sieciowych w infrastrukturze placówki ochrony zdrowia. Studenci poznają zasady identyfikacji aktywnych hostów, otwartych portów i działających usług sieciowych bez zakłócania ciągłości działania krytycznych systemów Elektronicznej Dokumentacji Medycznej (EDM). Ćwiczenie uczy odróżniania pasywnego nasłuchu sieciowego od aktywnego skanowania oraz szacowania ryzyka związanego z wysyłaniem pakietów sondy.

W ramach prac laboratoryjnych zespół bada podatności wynikające ze stosowania przestarzałych systemów operacyjnych oraz braku fizycznej lub logicznej segmentacji sieci. Uczestnicy analizują przepisy prawa medycznego i wymogi RODO dotyczące ochrony wrażliwych danych o stanie zdrowia pacjentów. Efektem końcowym jest opracowanie profesjonalnego raportu inwentaryzacyjnego wraz z rekomendacjami wdrożenia wirtualnych sieci lokalnych (VLAN) oraz reguł filtrowania ruchu na zaporze ogniowej.

Przychodnia Rejonowa „Zdrowie” w Wieliczce jest samodzielnym publicznym zakładem opieki zdrowotnej świadczącym usługi medyczne w ramach podstawowej i specjalistycznej opieki zdrowotnej. W strukturze placówki funkcjonuje 14 gabinetów lekarskich, rejestracja ogólna, punkt pobrań materiału do badań laboratoryjnych oraz pracownia diagnostyki obrazowej USG. W sieci lokalnej pracuje 35 komputerów klasy PC, 4 serwery lokalne oraz kilkanaście sieciowych urządzeń medycznych i drukarek recept.

W związku z planowaną integracją lokalnego systemu EDM z centralnym węzłem platformy P1 (e-Zdrowie) dyrekcja placówki zleciła wykonanie niezależnego audytu bezpieczeństwa sieci wewnętrznej. Wstępny wywiad z personelem wykazał, że w gabinetach lekarskich nadal pracują komputery z systemem Windows 7 SP1, a aparat diagnostyczny USG komunikuje się za pośrednictwem przestarzałego systemu Windows XP Embedded. Personel techniczny nigdy nie sporządził aktualnej mapy połączeń sieciowych, a adresacja IP przyznawana jest w jednej płaskiej podsieci 192.168.56.0/24 bez żadnej separacji ruchu.

Szczególnym wyzwaniem audytorskim w środowisku medycznym jest rygorystyczne przestrzeganie zasady nieszkodzenia (Do No Harm). Wysłanie agresywnych zapytań skanujących lub dużej liczby zniekształconych pakietów do wrażliwych urządzeń aparatury medycznej mogłoby spowodować ich zawieszenie lub błędne działanie, co stworzyłoby bezpośrednie zagrożenie dla życia i zdrowia pacjentów. Dlatego audytorzy muszą ściśle zdefiniować zasady zaangażowania (Rules of Engagement, RoE) i dobrać narzędzia w taki sposób, aby przeprowadzić badanie wyłącznie metodami bezpiecznymi i nieinwazyjnymi.

Zespoły studenckie wcielają się w rolę niezależnych audytorów bezpieczeństwa IT powołanych przez dyrektora przychodni. Zadanie polega na przeprowadzeniu wieloetapowego rekonesansu lokalnej podsieci, wykryciu wszystkich podłączonych maszyn, identyfikacji nieautoryzowanych urządzeń podpiętych przez personel (zjawisko Shadow IT) oraz zbadaniu widoczności krytycznych usług systemowych. Grupa musi zweryfikować, czy do bazy danych pacjentów lub konsoli zarządzania aparaturą medyczną można dotrzeć ze stacji roboczej dostępnej w gabinecie zabiegowym.

W końcowym etapie prac zespół opracowuje szczegółowy raport z audytu sieciowego, wskazując luki w architekturze teleinformatycznej przychodni oraz klasyfikując zidentyfikowane zagrożenia zgodnie ze skalą ryzyka. Studenci formułują przystępne wytyczne dla administratora, obejmujące podział sieci na odizolowane segmenty VLAN, wyłączenie zbędnych usług sieciowych oraz wymianę lub bezwzględną izolację maszyn z niewspieranymi systemami operacyjnymi.

1. Formalne zapoznanie się z zakresem upoważnienia do testów (Rules of Engagement) i harmonogramem prac, wykluczającym godziny intensywnego przyjmowania pacjentów w przychodni.
2. Podłączenie stacji audytorskiej z systemem Linux do wyznaczonego portu sieciowego w strefie personelu medycznego.
3. Weryfikacja przydzielonej konfiguracji sieciowej (adres IP, maska podsieci, brama domyślna, adres serwera DNS) za pomocą polecenia systemowego 'ip addr show' oraz 'ip route'.
4. Uruchomienie pasywnego nasłuchu ramek ARP w tle za pomocą darmowego narzędzia netdiscover w trybie nasłuchiwania ('netdiscover -p -i eth0'), co pozwala wykryć aktywność bez wysyłania jakichkolwiek pakietów.
5. Przeprowadzenie aktywnego, lecz łagodnego skanowania rozgłoszeniowego w warstwie łącza danych za pomocą narzędzia arp-scan ('sudo arp-scan --localnet') w celu zebrania adresów MAC wszystkich aktywnych kart sieciowych.
6. Zidentyfikowanie producentów sprzętu na podstawie prefiksów OUI (Organizationally Unique Identifier) w pobranych adresach MAC i powiązanie ich ze znanym wyposażeniem przychodni.
7. Zestawienie listy wykrytych adresów IP i MAC z oficjalnym rejestrem środków trwałych placówki w celu namierzenia urządzeń obcych i nieautoryzowanych (Shadow IT).
8. Wykonanie bezpiecznego badania dostępności hostów w podsieci 192.168.56.0/24 przy użyciu skanowania ping w narzędziu Nmap ('nmap -sn -T2 192.168.56.0/24') z obniżonym tempem transmisji.
9. Zarejestrowanie czasu odpowiedzi i weryfikacja stabilności pracy łączy sieciowych podczas skanowania, aby wykluczyć przeciążenie buforów w urządzeniach medycznych.
10. Wytypowanie kluczowych celów do badania usług: stacji rejestracji pacjentów (192.168.56.20), komputera w gabinecie (192.168.56.25) oraz serwera EDM (192.168.56.100).
11. Wykonanie dyskretnego skanowania TCP SYN najpopularniejszych 100 portów ('nmap -sS --top-ports 100 -T3 192.168.56.100') na serwerze bazy danych EDM.
12. Rozpoznanie wersji oprogramowania działającego na otwartych portach za pomocą flagi detekcji wersji ('nmap -sV --version-light 192.168.56.100').
13. Sprawdzenie obecności przestarzałych protokołów wymiany plików i udostępniania zasobów (SMBv1, NetBIOS porty 137-139, 445) na komputerach stacji roboczych.
14. Uruchomienie programu Wireshark na interfejsie lokalnym w celu zarejestrowania pakietów rozgłoszeniowych i weryfikacji, czy stacje robocze rozgłaszają w sieci nazwy użytkowników lub nazwy grup roboczych.
15. Weryfikacja dostępności portu 3306 (baza danych MySQL/MariaDB) na serwerze EDM ze stacji roboczej gabinetu lekarskiego i ocena braku ograniczeń w zaporze ogniowej.
16. Sporządzenie tabelarycznego zestawienia inwentaryzacyjnego: adres IP, adres MAC, vendor, system operacyjny, wykryte otwarte porty i usługi.
17. Opracowanie matrycy ryzyka dla zidentyfikowanych zagrożeń (np. obecność Windows 7 bez wsparcia, otwarta baza danych w sieci LAN) zgodnie z normą PN-EN ISO/IEC 27001.
18. Przygotowanie logicznego projektu segmentacji sieci lokalnej z podziałem na VLAN 10 (Administracja), VLAN 20 (Gabinety i EDM), VLAN 30 (Aparatura medyczna) oraz VLAN 40 (Wi-Fi pacjentów).

Podczas inwentaryzacji sieci medycznej priorytetem jest ostrożność. Nigdy nie stosuj agresywnych przełączników prędkości typu '-T4' lub '-T5' w programie Nmap, gdyż duża liczba pakietów na sekundę może zdestabilizować starsze sterowniki kart sieciowych w aparaturze diagnostycznej. Zamiast tego zaleca się profil '-T2' lub domyślny '-T3'.

Pasywne wykrywanie za pomocą 'netdiscover -p' jest całkowicie niewidoczne dla systemów monitorowania sieci (IDS), ponieważ stacja audytora nie emituje ani jednego pakietu, a jedynie nasłuchuje zapytań i odpowiedzi ARP generowanych przez inne komputery w trakcie normalnej pracy.

Poniżej przedstawiono przykładowe wywołanie inwentaryzacji lokalnej podsieci za pomocą narzędzia arp-scan w systemie Linux oraz wynik detekcji aktywnego serwera medycznego:

Zwróć uwagę na otwarty port bazy danych 3306 na serwerze EDM. W bezpiecznej architekturze baza danych powinna nasłuchiwać wyłącznie na pętli zwrotnej 127.0.0.1 lub w odseparowanej podsieci dostępnej jedynie dla serwera aplikacji webowej, a nie dla wszystkich stacji w gabinetach.

W systemie Windows weryfikację lokalnej tablicy ARP można wykonać poleceniem 'arp -a', co pozwala porównać perspektywę stacji roboczej pracownika z widokiem stacji audytora.

1. Wykazanie bezpośredniego związku pomiędzy brakiem segmentacji sieci (płaska architektura) a ryzykiem nieuprawnionego dostępu do danych medycznych pacjentów.
2. Ocena poziomu zagrożenia wynikającego z eksploatacji maszyn z systemami Windows 7 i XP po zakończeniu oficjalnego wsparcia technicznego producenta.
3. Uzasadnienie konieczności wprowadzenia reguł RoE chroniących wrażliwą aparaturę diagnostyczną przed awarią podczas badań technicznych.
4. Analiza legalności i granic upoważnienia audytora w kontekście art. 267 Kodeksu karnego oraz przepisów RODO dotyczących danych szczególnych kategorii.
5. Praktyczne wnioski dotyczące skuteczności pasywnych technik rekonesansu (netdiscover) w porównaniu ze skanowaniem aktywnym (arp-scan, nmap).
6. Zalecenia dotyczące docelowej architektury sieci przychodni z wykorzystaniem przełączników zarządzalnych i dedykowanych podsieci VLAN.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzony audyt sieci wewnętrznej przychodni wykazał, że całkowity brak segmentacji sieci (płaska architektura) tworzy krytyczne ryzyko nieuprawnionego dostępu do Elektronicznej Dokumentacji Medycznej. Identyfikacja niezaszyfrowanego portu bazy danych MySQL dostępnego dla wszystkich stacji w gabinetach oraz obecność niewspieranych systemów Windows XP dowodzi konieczności pilnego wdrożenia wirtualnych sieci VLAN. Pasywne techniki rekonesansu okazały się w pełni wystarczające do zmapowania topologii bez ryzyka zakłócenia pracy wrażliwej aparatury diagnostycznej. Ustalenie formalnych reguł zaangażowania (Rules of Engagement) zapewniło pełną legalność działań audytorskich w zgodzie z art. 267 Kodeksu karnego oraz wymogami RODO. Kluczową rekomendacją jest odizolowanie serwerów EDM w dedykowanej strefie DMZ oraz fizyczne odcięcie urządzeń medycznych od stacji z dostępem do Internetu.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Efekty uczenia się: W1, W4, U1, U4, K1.

Celem ćwiczenia jest nabycie praktycznych umiejętności oceny konfiguracji bezpieczeństwa publicznie dostępnych usług internetowych jednostki samorządu terytorialnego. Studenci badają poprawność wdrożenia protokołów kryptograficznych SSL/TLS na serwerze WWW, weryfikują łańcuch certyfikatów cyfrowych X.509 oraz analizują odporność witryny na powszechne ataki sieciowe poprzez badanie nagłówków HTTP. Zadanie obejmuje również ocenę zabezpieczeń poczty elektronicznej pod kątem ochrony przed podszywaniem się pod domenę urzędową.

W ramach analizy studenci wykorzystują darmowe narzędzia wiersza poleceń oraz publiczne testery konfiguracyjne do weryfikacji rekordów DNS takich jak SPF, DKIM oraz DMARC. Praca w grupie uczy identyfikacji przestarzałych algorytmów szyfrujących, podatności na ataki man-in-the-middle oraz formułowania technicznych zaleceń utwardzania (hardening) serwera Apache/Nginx oraz serwera pocztowego. Wynikiem zadania jest pisemna ocena ryzyka operacyjnego i wizerunkowego dla urzędu gminy.

Urząd Gminy w Lipnicy Małej prowadzi oficjalny Biuletyn Informacji Publicznej (BIP), portal informacyjny dla mieszkańców oraz serwer poczty elektronicznej w domenie 'uglipnicamala.gov.pl'. Za pośrednictwem witryny mieszkańcy pobierają formularze wniosków o dowody osobiste, zgłoszenia podatkowe oraz sprawdzają harmonogramy sesji rady gminy. Poczta elektroniczna urzędu wykorzystywana jest do oficjalnej korespondencji z instytucjami państwowymi, w tym z urzędami skarbowymi i wojewodą.

Mieszkańcy gminy oraz lokalni przedsiębiorcy zgłosili do wójta incydent otrzymania fałszywych wiadomości e-mail rzekomo wysłanych ze skrzynki 'sekretariat@uglipnicamala.gov.pl', w których wzywano do opłacenia zaległego podatku od nieruchomości na prywatny numer rachunku bankowego. Analiza wykazała, że cyberprzestępcy wykorzystali brak odpowiednich polityk uwierzytelniania nadawcy poczty w rekordach domenowych DNS urzędu, co umożliwiło bezkarne fałszowanie nagłówków wiadomości (email spoofing).

W tym samym czasie przeglądarki internetowe zaczęły ostrzegać odwiedzających stronę internetową urzędu przed potencjalnym zagrożeniem bezpieczeństwa z powodu błędu weryfikacji certyfikatu SSL/TLS oraz stosowania przestarzałych wersji protokołów szyfrowania. Wójt gminy zdecydował o pilnym przeprowadzeniu audytu technicznego witryny oraz konfiguracji serwera pocztowego przez zespół zewnętrznych analityków, aby przywrócić zaufanie mieszkańców i zabezpieczyć gminę przed sankcjami ze strony organów nadzorczych.

Zespół studentów podejmuje się wykonania audytu konfiguracji usług webowych i pocztowych urzędu z perspektywy zewnętrznego obserwatora. Studenci badają ważność i łańcuch zaufania certyfikatu cyfrowego, oceniają obsługiwane zestawy szyfrów (Cipher Suites), weryfikują obecność ochronnych nagłówków odpowiedzi HTTP (HSTS, CSP, X-Frame-Options) oraz analizują rekordy domeny za pomocą zapytań DNS.

Na podstawie zebranych danych audytorzy przygotowują raport techniczny zawierający ocenę podatności na podsłuch i manipulację treścią strony oraz instrukcję wdrożenia nowoczesnych standardów bezpieczeństwa poczty (SPF, DKIM, DMARC z polityką reject). Raport wskazuje konkretne linie konfiguracyjne dla serwera webowego oraz przykładowe wpisy strefy DNS, które urząd powinien niezwłocznie wprowadzić.

1. Zdefiniowanie zakresu badania zewnętrznego usług publicznych urzędu gminy i weryfikacja poprawności analizowanej nazwy domenowej.
2. Pobranie i zbadanie publicznych rekordów DNS domeny (rekordy A, MX, NS, TXT) za pomocą polecenia 'dig uglipnicamala.gov.pl ANY' lub internetowych serwisów DNS.
3. Weryfikacja obecności i składni rekordu Sender Policy Framework (SPF) w rekordach TXT domeny pod kątem autoryzowanych serwerów nadawczych.
4. Sprawdzenie obecności rekordu DMARC ('_dmarc.uglipnicamala.gov.pl') i weryfikacja zdefiniowanej polityki postępowania z nieautoryzowaną pocztą ('p=none', 'p=quarantine', 'p=reject').
5. Pobranie nagłówków odpowiedzi serwera WWW przy użyciu narzędzia curl ('curl -I https://uglipnicamala.gov.pl') w celu zbadania ujawnianych wersji oprogramowania serwerowego.
6. Analiza nagłówka 'Server' oraz 'X-Powered-By' pod kątem podatności na enumerację wersji systemu operacyjnego i silnika serwera.
7. Weryfikacja obecności nagłówka HTTP Strict Transport Security (HSTS - 'Strict-Transport-Security') wymuszającego wyłącznie szyfrowaną komunikację.
8. Sprawdzenie nagłówków zapobiegających atakom typu Clickjacking oraz Cross-Site Scripting (X-Frame-Options, X-Content-Type-Options, Content-Security-Policy).
9. Pobranie i inspekcja certyfikatu cyfrowego serwera WWW za pomocą klienta OpenSSL ('openssl s_client -connect uglipnicamala.gov.pl:443 -servername uglipnicamala.gov.pl').
10. Weryfikacja daty ważności certyfikatu, podmiotu certyfikatu (Subject) oraz urzędu certyfikacji (Issuer), który go wystawił.
11. Zbadanie poprawności łańcucha certyfikatów pośrednich (Certificate Chain) i weryfikacja, czy serwer przesyła kompletny łańcuch do przeglądarki.
12. Sprawdzenie obsługiwanych wersji protokołów szyfrowania (TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3) za pomocą darmowego skryptu testssl.sh lub testera SSL Labs.
13. Zidentyfikowanie słabych i przestarzałych zestawów szyfrów (np. szyfry CBC, RC4, 3DES, algorytmy wymiany kluczy RSA bez Perfect Forward Secrecy).
14. Weryfikacja podatności serwera na znane historyczne luki protokołu TLS (Heartbleed, POODLE, ROBOT) przy użyciu skryptu nmap 'ssl-enum-ciphers'.
15. Przeprowadzenie audytu podatności warstwy aplikacji darmowym skanerem Nikto ('nikto -h https://uglipnicamala.gov.pl -Tuning 1,2,3') w trybie bezpiecznym bez agresywnych zapytań.
16. Ocena ryzyka spoofingu pocztowego dla mieszkańców na podstawie wyników analizy rekordów SPF i DMARC.
17. Sformułowanie wzorcowego rekordu DMARC z polityką 'p=reject' oraz raportowaniem 'rua' w celu ochrony domeny urzędu przed phishingiem.
18. Opracowanie spójnego zestawu reguł konfiguracyjnych dla serwera WWW (Apache/Nginx) eliminujących luki w nagłówkach i wyłączających przestarzałe protokoły TLS.

Weryfikacja nagłówków bezpieczeństwa serwera WWW za pomocą polecenia 'curl -I' pozwala w ułamku sekundy ustalić, czy administrator wdrożył nowoczesne mechanizmy obronne przeglądarki. Brak nagłówka HSTS pozwala napastnikowi w sieci lokalnej na przeprowadzenie ataku typu SSL Stripping.

Analiza certyfikatów za pomocą 'openssl s_client' jest niezastąpionym narzędziem diagnostycznym. Flaga '-servername' jest krytyczna, ponieważ umożliwia przesyłanie rozszerzenia SNI (Server Name Indication), bez którego serwery obsługujące wiele domen na jednym adresie IP zwrócą niewłaściwy certyfikat domyślny.

Poniżej pokazano przykładowe zbadanie nagłówków HTTP i certyfikatu SSL serwera urzędowego oraz weryfikację rekordu SPF w konsoli systemu Linux:

Zwróć uwagę na ujawnianie wersji Apache i PHP w nagłówkach Server oraz X-Powered-By. Jest to zbędny wyciek informacji (Information Disclosure), ułatwiający potencjalnemu napastnikowi dopasowanie exploitów. Należy zalecić wyłączenie tych nagłówków w plikach konfiguracyjnych (np. ServerTokens Prod, ServerSignature Off, expose_php = Off).

W sprawozdaniu warto porównać wyniki z bezpłatnych serwisów internetowych, takich jak SecurityHeaders.com oraz SSL Labs Qualys, które przydzielają przejrzyste oceny literowe od A+ do F.

1. Ocena wpływu braku rygorystycznej polityki DMARC i SPF na podatność domeny urzędowej na ataki podszywania się (email spoofing).
2. Uzasadnienie konieczności wymuszania szyfrowania HTTPS z użyciem nagłówka HSTS w kontekście ochrony sesji obywateli korzystających z portalu urzędu.
3. Wnioski dotyczące zagrożeń płynących ze wspierania przestarzałych wersji protokołów TLS 1.0 i 1.1 oraz słabych zestawów szyfrów.
4. Analiza ryzyka wycieku informacji o wersjach oprogramowania (Apache, PHP) w nagłówkach HTTP i metody ich ukrywania.
5. Rekomendacje dotyczące procedury monitorowania ważności certyfikatów SSL/TLS i automatyzacji ich odnawiania (np. protokół ACME / certbot).
6. Ocena kosztów wdrożenia proponowanych środków zaradczych i ich znaczenia dla bezpieczeństwa danych osobowych mieszkańców.

Przykładowe wnioski (wzór do sprawozdania): Badanie ekspozycji zewnętrznej serwera urzędu gminy ujawniło podatność infrastruktury pocztowej na ataki podszywania się (email spoofing) z powodu braku rekordu DMARC oraz zbyt permisywnego wpisu SPF. Brak wymuszenia szyfrowania HTTPS za pomocą nagłówka HSTS oraz aktywne wsparcie dla przestarzałego protokołu TLS 1.0 stwarzały bezpośrednie zagrożenie przechwycenia sesji obywateli korzystających z e-usług. Ujawnianie dokładnych wersji serwera Apache i interpretera PHP w nagłówkach odpowiedzi HTTP niepotrzebnie ułatwiało potencjalnemu napastnikowi profilowanie podatności pod kątem publicznych exploitów. Wdrożenie rygorystycznej polityki DMARC z regułą odrzucania (p=reject) oraz konfiguracja nagłówków bezpieczeństwa trwale podnosi cyberodporność urzędu bez konieczności ponoszenia kosztów licencyjnych. Rekomenduje się zautomatyzowanie odnawiania certyfikatów TLS za pośrednictwem protokołu ACME, co wykluczy ryzyko utraty ciągłości działania portalu gminnego.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności. Kon3 Autoryzacja i uwierzytelnianie. Efekty uczenia się: W1, W2, U1, U3, K1.

Celem zadania jest praktyczne zrozumienie zagrożeń wynikających z przesyłania danych uwierzytelniających i poufnych dokumentów otwartym tekstem w lokalnej sieci komputerowej. Studenci uczą się przechwytywania i analizowania ruchu sieciowego za pomocą bezpłatnych analizatorów pakietów, takich jak Wireshark, Tshark oraz Tcpdump. Ćwiczenie pozwala naocznie przekonać się, jak proste jest odczytanie haseł logowania, treści korespondencji i plików finansowych przesyłanych przez nieszyfrowane protokoły.

W trakcie laboratorium grupa bada charakterystykę transmisji tradycyjnych protokołów, takich jak FTP, Telnet, HTTP oraz nieszyfrowany POP3/IMAP, zestawiając je z ich bezpiecznymi, kryptograficznymi odpowiednikami (SFTP, SSH, HTTPS, IMAPS). Studenci analizują etyczne i prawne konsekwencje podsłuchiwania transmisji w kontekście tajemnicy zawodowej księgowych oraz przepisów RODO. Końcowym rezultatem jest opracowanie planu migracji na protokoły szyfrowane oraz procedury audytu czystości ruchu sieciowego.

Biuro Rachunkowe „Fiskus-Partner” w Bochni świadczy usługi księgowe, kadrowo-płacowe i doradztwa podatkowego dla ponad 120 małych i średnich przedsiębiorstw z regionu małopolskiego. W biurze zatrudnionych jest 8 księgowych, które codziennie wprowadzają do lokalnych programów finansowych wyciągi bankowe, faktury VAT, dane o wynagrodzeniach pracowników oraz deklaracje podatkowe ZUS i PIT.

W celu wymiany dokumentów z klientami oraz archiwizacji baz danych księgowe korzystają z lokalnego serwera plików NAS podłączonego do wspólnego przełącznika sieciowego. Nowo zatrudniony informatyk zauważył, że pracownicy do przesyłania comiesięcznych zestawień obrotów używają tradycyjnego klienta FTP, a poczta elektroniczna w programie pocztowym skonfigurowana jest na portach 110 (POP3) oraz 25 (SMTP) bez włączonego szyfrowania SSL/TLS. Dodatkowo panel konfiguracyjny sieciowej drukarki wielofunkcyjnej dostępny jest przez zwykły protokół HTTP.

Właściciel biura rachunkowego uświadomił sobie, że jakikolwiek nieautoryzowany dostęp do lokalnej sieci (np. poprzez sieć Wi-Fi, do której hasło udostępniano klientom biura, lub podłączenie obcego laptopa w poczekalni) pozwala na całkowite przechwycenie haseł dostępem do systemów księgowych oraz wgląd w poufne finanse obsługiwanych firm. Zażądał przeprowadzenia kontrolowanego audytu ruchu sieciowego, który udowodni pracownikom konieczność natychmiastowej rezygnacji z nieszyfrowanych połączeń.

Zespół laboratoryjny wciela się w audytorów wykonujących badanie przepływu danych w środowisku testowym odwzorowującym sieć biura. Zadaniem studentów jest przechwycenie strumieni danych generowanych przez aplikacje biurowe, zidentyfikowanie pakietów zawierających poświadczenia w postaci jawnego tekstu (plain text) oraz wykazanie, jakie informacje biznesowe mogą wpaść w ręce osoby niepowołanej. Audyt musi odbywać się z zachowaniem ścisłych rygorów etycznych bez utrwalania rzeczywistych danych osobowych.

Na zakończenie zespół przygotowuje kompleksowe sprawozdanie prezentujące zidentyfikowane luki w transmisji, zrzuty zrekonstruowanych sesji oraz szczegółowy przewodnik konfiguracyjny wymuszający przejście na protokoły chronione kryptograficznie. Raport zawiera także wytyczne dotyczące blokowania niebezpiecznych portów na przełączniku i routerze brzegowym.

1. Przygotowanie odizolowanego stanowiska audytorskiego z systemem Linux i zainstalowanymi narzędziami Wireshark oraz Tcpdump.
2. Podłączenie stacji audytora do portu lustrzanego (SPAN/Mirror) na przełączniku zarządzalnym lub praca w laboratoryjnej maszynie wirtualnej generującej kontrolowany ruch testowy.
3. Uruchomienie przechwytywania pakietów na interfejsie sieciowym za pomocą narzędzia tcpdump z zapisem do pliku ('sudo tcpdump -i eth0 -w /tmp/ruch_biuro.pcap').
4. Zasymulowanie przez drugiego członka zespołu próby logowania do testowego serwera FTP za pomocą klienta wiersza poleceń lub przeglądarki.
5. Zatrzymanie przechwytywania i otwarcie pliku pcap w programie Wireshark.
6. Zastosowanie filtru wyświetlania 'ftp' w Wiresharku w celu wyizolowania poleceń sterujących protokołu FTP.
7. Zlokalizowanie pakietów z komendami 'USER' oraz 'PASS' i odczytanie przesłanego loginu i hasła zapisanego jawnym tekstem.
8. Wykorzystanie funkcji 'Follow TCP Stream' w Wiresharku do pełnej rekonstrukcji przebiegu całej sesji FTP i podejrzenia nazw pobieranych plików.
9. Zasymulowanie transmisji formularza logowania przez protokół HTTP bez certyfikatu SSL (port 80).
10. Zastosowanie filtru 'http.request.method == "POST"' w Wiresharku w celu odszukania przesyłanych parametrów formularza uwierzytelniającego.
11. Odczytanie zawartości pól formularza (login, hasło, numer rachunku bankowego) w surowej zawartości pakietu HTTP POST.
12. Zbadanie nieszyfrowanej sesji pobierania poczty przez protokół POP3 (port 110) za pomocą filtru 'pop' i odnalezienie komend 'USER' i 'PASS'.
13. Przeprowadzenie analizy statystycznej przechwyconego ruchu w menu Wireshark (Statistics -> Protocol Hierarchy) w celu określenia udziału procentowego protokołów nieszyfrowanych.
14. Skonfigurowanie i przetestowanie bezpiecznego połączenia przez protokół SFTP/SSH (port 22) w celu porównania wyglądu pakietów w analizatorze.
15. Zweryfikowanie, że w strumieniu danych SSH/SFTP oraz HTTPS zawartość pakietów jest całkowicie nieczytelna dla podsłuchującego (zaszyfrowany payload).
16. Sporządzenie listy zidentyfikowanych w sieci biura protokołów nieszyfrowanych wraz z ich numerami portów i przypisanym poziomem krytyczności.
17. Opracowanie procedury wyłączenia usług FTP, Telnet i HTTP na serwerze biurowym oraz zastąpienia ich usługami SFTP, SSH i HTTPS.
18. Sformułowanie zaleceń dotyczących wdrożenia bezpiecznych certyfikatów TLS w programach pocztowych księgowych (port 993 IMAPS, port 465 SMTPS).

Podczas analizy w programie Wireshark najważniejszą umiejętnością jest sprawne korzystanie z filtrów wyświetlania (Display Filters). Filtry te nie ograniczają liczby zapisywanych pakietów, lecz pozwalają błyskawicznie odnaleźć poszukiwane protokoły wśród tysięcy innych ramek rozgłoszeniowych.

Pamiętaj, że protokół FTP korzysta z dwóch niezależnych połączeń: kanału sterującego (domyślnie port TCP 21), w którym przesyłane są komendy i hasła, oraz kanału danych (port TCP 20 lub porty dynamiczne w trybie pasywnym), w którym płyną same pliki. Opcja 'Follow TCP Stream' w Wiresharku łączy wszystkie pakiety danej konwersacji w czytelny dla człowieka ciąg tekstowy.

Poniżej pokazano przykładowy listing przechwycenia poświadczeń FTP za pomocą konsolowego narzędzia tcpdump i filtrującego polecenia grep:

Zwróć uwagę, że przechwytywanie pakietów w sieciach z przełącznikami (switched networks) w normalnych warunkach pozwala na podsłuch jedynie ruchu rozgłoszeniowego oraz pakietów kierowanych bezpośrednio do własnej karty sieciowej. W audycie korzysta się z portu lustrzanego (Port Mirroring) skonfigurowanego przez administratora przełącznika.

W referacie wyjaśnij różnicę pomiędzy protokołem FTPS (FTP opakowany w tunel SSL/TLS) a SFTP (podsystem przesyłania plików działający w ramach protokołu SSH). Chociaż brzmią podobnie, są to całkowicie odmienne rozwiązania technologiczne.

1. Wykazanie skrajnego ryzyka utraty poufności danych finansowych i haseł przy stosowaniu nieszyfrowanych protokołów transmisji.
2. Ocena łatwości przechwycenia danych uwierzytelniających przez osoby niepowołane posiadające dostęp do lokalnego segmentu sieci LAN.
3. Prawne i etyczne aspekty ochrony tajemnicy zawodowej oraz odpowiedzialność administratora za brak wdrożenia szyfrowania zgodnie z RODO.
4. Porównanie nakładu pracy niezbędnego do migracji z FTP/HTTP na SFTP/HTTPS z potencjalnymi stratami wizerunkowymi i finansowymi biura.
5. Wnioski dotyczące skuteczności analizatorów pakietów (Wireshark, Tcpdump) jako narzędzi audytu i weryfikacji czystości ruchu sieciowego.
6. Konieczność wdrożenia polityki bezpieczeństwa zabraniającej używania przestarzałych protokołów i blokowania ich portów na zaporze ogniowej.

Przykładowe wnioski (wzór do sprawozdania): Analiza ruchu sieciowego w biurze rachunkowym jednoznacznie potwierdziła, że stosowanie nieszyfrowanych protokołów transmisji (FTP, HTTP, POP3) prowadzi do natychmiastowego ujawnienia haseł i poufnych danych klientów w czystym tekście. Dowolny użytkownik podłączony do lokalnego segmentu sieci LAN lub złośliwe oprogramowanie na stacji roboczej jest w stanie przechwycić poświadczenia za pomocą darmowych snifferów pakietów. Zastąpienie przestarzałych usług ich bezpiecznymi odpowiednikami kryptograficznymi (SFTP, HTTPS, IMAPS z TLS) całkowicie neutralizuje ryzyko podsłuchu transmisji. Konfiguracja portu lustrzanego (Port Mirroring) na przełączniku zarządzalnym okazała się skuteczną metodą pasywnego audytu bez zakłócania bieżącej pracy personelu księgowego. Wdrożenie bezwzględnego zakazu transmisji jawnej stanowi elementarny wymóg zgodności z zasadą poufności i integralności określoną w art. 5 ust. 1 lit. f RODO.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon4 Sieciowe systemy składowania danych: SAN, NAS. Efekty uczenia się: W1, U1, U3, U4, K1.

Celem zadania jest nabycie praktycznych umiejętności weryfikacji bezpieczeństwa usług sieciowego udostępniania zasobów plikowych opartych na protokole Server Message Block (SMB/CIFS) oraz serwerze Samba. Studenci badają konfigurację udziałów dyskowych w przedsiębiorstwie, sprawdzają podatność na anonimowy dostęp (sesje zerowe / Null Sessions) oraz weryfikują obecność przestarzałej i niebezpiecznej wersji protokołu SMBv1. Ćwiczenie uczy bezpiecznego audytu usług dyskowych bez ryzyka uszkodzenia lub zablokowania danych biznesowych.

W ramach laboratorium grupa przeprowadza kontrolowaną enumerację zasobów za pomocą darmowych narzędzi linuksowych (smbclient, enum4linux, skrypty Nmap NSE) oraz analizuje wpisy konfiguracyjne serwera Samba w pliku /etc/samba/smb.conf. Studenci uczą się wyszukiwania informacji o znanych podatnościach w publicznych bazach CVE oraz narzędziu Searchsploit. Efektem pracy jest opracowanie wzorcowej, bezpiecznej konfiguracji udziałów plikowych spełniającej zasadę najmniejszych uprawnień (Least Privilege).

Firma Logistyczna „Trans-Krak” w Niepołomicach zarządza flotą 80 pojazdów ciężarowych oraz centrum dystrybucyjnym o powierzchni 12 000 m². W dziale spedycji, dyspozytorni i magazynie pracuje 40 pracowników, którzy wymieniają się listami przewozowymi, skanami dokumentów celnych CMR, fakturami oraz planami tras za pośrednictwem centralnego serwera plików NAS opartego na systemie Linux z usługą Samba.

Podczas wdrożenia serwera kilka lat temu administrator skonfigurował udziały sieciowe w sposób maksymalnie uproszczony, aby kierowcy i pracownicy magazynu nie musieli logować się hasłem przy przesyłaniu skanów dokumentów. W efekcie utworzono katalog współdzielony 'Wymiana' z uprawnieniami zapisu dla każdego użytkownika w sieci (dostęp gościnny), a w konfiguracji włączono wsteczną kompatybilność z protokołem SMBv1, aby umożliwić współpracę ze starymi skanerami kodów kreskowych pracującymi pod kontrolą Windows CE.

Niedawny incydent w konkurencyjnej firmie transportowej, która padła ofiarą ataku ransomware rozprzestrzeniającego się przez podatności w protokole SMB (takie jak EternalBlue), wywołał zaniepokojenie zarządu spółki. Prezes zażądał pilnej weryfikacji serwera plików pod kątem bezpieczeństwa, sprawdzenia czy nieautoryzowany użytkownik może uzyskać wgląd do dokumentacji celnej oraz oceny podatności na ataki sieciowe.

Zespół audytorów laboratoryjnych podejmuje wyzwanie przeprowadzenia audytu konfiguracji SMB w środowisku testowym wiernie odtwarzającym warunki panujące w firmie logistycznej. Studenci sprawdzają, jakie udziały dyskowe są widoczne bez podawania poświadczeń, czy możliwe jest odczytanie listy kont użytkowników domeny lub grupy roboczej oraz czy serwer akceptuje negocjację niebezpiecznego protokołu SMBv1. Badanie ma charakter bezinwazyjny – audytorzy identyfikują podatności, lecz nie uruchamiają żadnych exploitów.

W podsumowaniu audytu grupa formułuje techniczny plan naprawczy. Obejmuje on wyłączenie obsługi SMBv1, wymuszenie szyfrowania i podpisywania pakietów SMB (SMB Signing), likwidację sesji anonimowych oraz konfigurację uwierzytelniania opartego na indywidualnych kontach z precyzyjnie przypisanymi uprawnieniami do poszczególnych folderów.

1. Zapoznanie się ze strukturą organizacyjną firmy logistycznej i zdefiniowanie celów audytu usługi udostępniania plików SMB.
2. Podłączenie stacji audytora do sieci testowej i weryfikacja dostępności serwera plików (192.168.56.100) na portach TCP 139 oraz 445.
3. Przeprowadzenie rekonesansu portów SMB za pomocą narzędzia Nmap z flagą wykrywania wersji ('nmap -sS -p 139,445 -sV 192.168.56.100').
4. Uruchomienie skryptu Nmap 'smb-os-discovery' w celu zebrania informacji o wersji systemu operacyjnego, nazwie komputera i domenie/grupie roboczej.
5. Zbadanie obsługiwanych dialektów protokołu SMB za pomocą skryptu 'smb-protocols' w celu weryfikacji, czy serwer akceptuje niebezpieczny dialekt SMBv1.
6. Weryfikacja wymogu cyfrowego podpisywania pakietów SMB za pomocą skryptu 'smb-security-mode' (sprawdzenie flagi message_signing: disabled/enabled).
7. Próba nawiązania sesji zerowej (Null Session) i wylistowania dostępnych udziałów bez hasła za pomocą narzędzia smbclient ('smbclient -L //192.168.56.100 -N').
8. Próba anonimowego podłączenia się do wykrytego udziału 'Wymiana' ('smbclient //192.168.56.100/Wymiana -N') i sprawdzenie uprawnień do pobierania oraz tworzenia plików.
9. Uruchomienie darmowego narzędzia enum4linux ('enum4linux -a 192.168.56.100') w celu automatycznej enumeracji udziałów, polityki haseł oraz listy użytkowników lokalnych.
10. Przeanalizowanie raportu enum4linux pod kątem wycieku nazw kont pracowniczych (User Enumeration) ułatwiającego późniejsze ataki słownikowe.
11. Sprawdzenie podatności serwera na znane krytyczne luki w zabezpieczeniach protokołu SMB przy użyciu skryptów Nmap z kategorii vuln ('nmap -p 445 --script smb-vuln* 192.168.56.100').
12. Weryfikacja podatności na błąd MS17-010 (EternalBlue) oraz SambaCry (CVE-2017-7494) wyłącznie na podstawie odpowiedzi negocjacyjnych bez wysyłania złośliwego ładunku (payload).
13. Wyszukanie informacji o zidentyfikowanej wersji serwera Samba w lokalnej bazie exploitów za pomocą narzędzia Searchsploit ('searchsploit samba 4.X').
14. Przeanalizowanie pliku konfiguracyjnego serwera Samba (/etc/samba/smb.conf) na maszynie testowej i wskazanie niebezpiecznych dyrektyw (np. 'map to guest = bad user', 'ntlm auth = yes').
15. Zaprojektowanie bezpiecznych reguł w pliku smb.conf: 'server min protocol = SMB2_10', 'server signing = mandatory', 'restrict anonymous = 2'.
16. Opracowanie matrycy uprawnień dostępu do udziałów z podziałem na role: Spedytor (odczyt/zapis), Magazyn (tylko odczyt), Zarząd (poufne).
17. Zweryfikowanie poprawności działania zmodyfikowanej konfiguracji Samby za pomocą wbudowanego narzędzia testparm ('testparm -s').
18. Przygotowanie syntetycznych wniosków audytorskich dla zarządu firmy logistycznej zawierających ocenę ryzyka biznesowego i harmonogram prac naprawczych.

Protokół SMBv1 powstał w latach 80. XX wieku i z powodu licznych wad projektowych oraz braku mechanizmów obronnych jest uznawany za wysoce niebezpieczny. Oficjalne wytyczne CSIRT NASK oraz agencji CISA nakazują całkowite wycofanie SMBv1 ze wszystkich sieci korporacyjnych.

Uruchamiając skrypty Nmap z grupy 'smb-vuln*', zachowaj ostrożność. Skrypty te są zaprojektowane jako bezpieczne testy sygnaturowe (Safe Checks), jednak w przypadku bardzo starych systemów Windows mogą wywołać zawieszenie usługi, dlatego w środowisku produkcyjnym wykonuje się je wyłącznie za zgodą właściciela systemu.

Poniżej przedstawiono przykładowy wynik enumeracji udziałów SMB za pomocą narzędzia smbclient oraz skanowania podatności skryptami Nmap:

Narzędzie enum4linux jest potężnym skryptem perlowym integrującym możliwości smbclient, rpcclient, net oraz nmblookup. Wyniki jego działania warto przekierować do pliku tekstowego ('enum4linux -a 192.168.56.100 > audyt_smb.txt'), co ułatwia późniejsze przeszukiwanie za pomocą grep.

W systemach Windows weryfikację dostępnych udziałów zdalnych można przeprowadzić w wierszu poleceń komendą 'net view \\192.168.56.100' lub w środowisku PowerShell za pomocą polecenia 'Get-SmbShare'.

1. Wpływ obecności protokołu SMBv1 na podatność infrastruktury firmy na ataki zautomatyzowanego złośliwego oprogramowania (np. WannaCry, NotPetya).
2. Ocena ryzyka biznesowego wynikającego z anonimowego dostępu gościnnego do dokumentacji transportowej i listów przewozowych CMR.
3. Znaczenie wymuszenia cyfrowego podpisywania pakietów SMB (SMB Signing) w zapobieganiu atakom typu NTLM Relay i podsłuchowi w sieci LAN.
4. Zalecenia dotyczące migracji starych urządzeń magazynowych (skanerów) na protokoły bezpieczne w celu wyeliminowania konieczności wspierania SMBv1.
5. Przegląd wzorcowej konfiguracji serwera Samba w pliku smb.conf gwarantującej izolację uprawnień pomiędzy działami firmy.
6. Konieczność cyklicznego audytu uprawnień do udziałów sieciowych i weryfikacji kont nieaktywnych pracowników.

Przykładowe wnioski (wzór do sprawozdania): Audyt usługi udostępniania plików SMB w przedsiębiorstwie logistycznym wykazał obecność krytycznych podatności konfiguracyjnych w postaci anonimowego dostępu do udziałów zawierających dokumenty przewozowe. Wykrycie aktywnego protokołu SMBv1 stwarzało bezpośrednie zagrożenie błyskawicznego rozprzestrzenienia się złośliwego oprogramowania typu ransomware wykorzystującego luki z rodziny EternalBlue. Wyłączenie SMBv1 na rzecz bezpiecznego SMBv3 oraz wymuszenie podpisywania pakietów (SMB Signing) skutecznie eliminuje wektory ataków przekaźnikowych (SMB Relay) i podsłuchu w sieci lokalnej. Zlikwidowanie kont gościnnych i powiązanie praw dostępu do zasobów z uwierzytelnionymi kontami domenowymi przywróciło pełną kontrolę nad obiegiem dokumentów. Przeprowadzona weryfikacja narzędziem Nmap dowodzi, że regularne skanowanie skryptami NSE pozwala na wczesne wykrycie luk konfiguracyjnych zanim zostaną one wykorzystane przez intruza.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Efekty uczenia się: W1, U1, U3, K1, K2.

Głównym celem zadania jest opanowanie technik pasywnego rekonesansu ze źródeł ogólnodostępnych (Open Source Intelligence, OSINT) w celu oceny cyfrowego śladu i zewnętrznej powierzchni ataku przedsiębiorstwa e-commerce. Studenci uczą się pozyskiwać wiedzę o infrastrukturze sieciowej, adresacji IP, subdomenach, dostawcach usług chmurowych oraz stosowanych technologiach bez wysyłania jakichkolwiek pakietów bezpośrednio do serwerów badanego podmiotu. Ćwiczenie uczy myślenia analitycznego i łączenia rozproszonych danych w spójną mapę zasobów cyfrowych.

W trakcie prac laboratoryjnych grupa wykorzystuje publiczne rejestry WHOIS, pasywne bazy DNS, rejestry przejrzystości certyfikatów (Certificate Transparency Logs), wyszukiwarki internetowe urządzeń sieciowych (Shodan, Censys) oraz archiwa internetowe (Wayback Machine). Studenci oceniają ryzyko wycieku metadanych pracowników, zapomnianych środowisk testowych (staging) oraz ujawnienia paneli administracyjnych. Zwieńczeniem zadania jest opracowanie raportu ekspozycji zewnętrznej z zaleceniami ograniczenia widoczności wrażliwych informacji.

Sklep Internetowy „Zabawki-Edu” w Tarnowie prowadzi sprzedaż zabawek edukacyjnych, pomocy dydaktycznych oraz gier planszowych na rynku polskim i europejskim. Platforma handlowa przetwarza miesięcznie ponad 5000 zamówień, obsługując płatności elektroniczne oraz gromadząc dane osobowe i adresowe dziesiątek tysięcy klientów. Właściciele sklepu zlecili modernizację platformy zewnętrznej agencji programistycznej, która utworzyła w chmurze dodatkowe subdomeny dla deweloperów.

Właściciel sklepu powziął podejrzenie, że pracownicy agencji pozostawili w sieci publicznej niechronione środowiska testowe zawierające kopie robocze bazy danych klientów oraz ujawnili na forach internetowych i w publicznych repozytoriach kodu adresy serwerów wewnętrznych. Dodatkowo klienci sklepu zaczęli otrzymywać wiadomości spamowe sugerujące wyciek adresów e-mail z bazy newslettera.

Zarząd spółki postanowił zlecić zespołowi audytorów wykonanie dyskretnego audytu bezpieczeństwa metodą białego wywiadu (OSINT). Podstawowym warunkiem postawionym przed zespołem jest całkowita niewidzialność badania: audytorzy mają bezwzględny zakaz przeprowadzania jakichkolwiek aktywnych skanów na adresy IP sklepu, aby nie zakłócić pracy serwisu w szczycie sezonu handlowego i nie wywołać fałszywych alarmów w systemach bezpieczeństwa firmy hostingowej.

Studenci wcielają się w analityków wywiadu jawnoźródłowego. Korzystając wyłącznie z publicznie dostępnych baz danych, rejestrów domenowych i wyszukiwarek indeksujących metadane, zespół mapuje całą architekturę zewnętrzną sklepu. Studenci sprawdzają, jakie subdomeny zostały ujawnione w certyfikatach SSL (np. test.zabawki-edu.pl, dev.zabawki-edu.pl, staging.zabawki-edu.pl), jakie technologie i wersje CMS są widoczne w bazach Shodan, oraz czy w archiwach sieciowych nie zachowały się stare pliki konfiguracyjne.

Efektem pracy grupy jest szczegółowy profil ekspozycji cyfrowej firmy e-commerce. Raport przedstawia zidentyfikowane wektory potencjalnego ataku, listę ujawnionych subdomen wymagających natychmiastowego zabezpieczenia lub usunięcia z publicznego DNS oraz procedurę higieny cyfrowej (Digital Hygiene) dla pracowników i kontraktorów sklepu.

1. Sformułowanie zakresu audytu OSINT i określenie głównej domeny docelowej (np. 'zabawki-edu.pl') w porozumieniu ze zleceniodawcą.
2. Pobranie i przeanalizowanie danych rejestracyjnych domeny z krajowego rejestru NASK (WHOIS) za pomocą polecenia 'whois zabawki-edu.pl'.
3. Zidentyfikowanie operatora rejestrującego, daty rejestracji, daty wygaśnięcia domeny oraz adresów serwerów nazw (NS).
4. Pasywne zebranie rekordów DNS domeny (A, AAAA, MX, TXT) za pośrednictwem publicznych baz danych DNS bez bezpośredniego odpytywania serwerów celu.
5. Zbadanie rejestrów przejrzystości certyfikatów (Certificate Transparency) przy użyciu publicznego serwisu 'crt.sh' w celu wykrycia wszystkich historycznie wystawionych certyfikatów dla domeny i jej subdomen.
6. Skompilowanie pełnej listy subdomen (np. panel.zabawki-edu.pl, mail.zabawki-edu.pl, dev.zabawki-edu.pl) ujawnionych w logach certyfikatów cyfrowych.
7. Weryfikacja historii zmian rekordów DNS i adresów IP za pomocą pasywnych serwisów typu SecurityTrails lub ViewDNS.info.
8. Sprawdzenie, czy adresy IP serwerów sklepu znajdują się w bazach wyszukiwarki Shodan ('shodan host ') oraz Censys w celu zbadania zindeksowanych usług i nagłówków banerowych.
9. Analiza zindeksowanych przez Shodan portów bez wysyłania jakichkolwiek pakietów ze stacji audytora (wykorzystanie danych zgromadzonych przez roboty Shodana).
10. Wyszukanie zindeksowanych dokumentów biurowych (PDF, DOCX, XLSX) należących do domeny za pomocą zaawansowanych operatorów Google (Google Dorks: 'site:zabawki-edu.pl filetype:pdf').
11. Pobranie przykładowego publicznego pliku PDF ze strony sklepu i zbadanie jego metadanych narzędziem Exiftool ('exiftool regulamin.pdf') w celu wykrycia nazwisk autorów, nazw oprogramowania i ścieżek dyskowych.
12. Zbadanie historii witryny w internetowym archiwum Wayback Machine (archive.org) w celu odszukania starych podstron, zapomnianych cenników lub dawnych danych kontaktowych.
13. Sprawdzenie wycieków adresów e-mail w domenach powiązanych ze sklepem w bezpiecznych serwisach agregujących naruszenia danych (np. Have I Been Pwned).
14. Analiza używanego silnika sklepu (np. WooCommerce, PrestaShop) i bibliotek JavaScript za pomocą analizatora pasywnego nagłówków lub bazy Wappalyzer.
15. Weryfikacja, czy panele logowania do systemów zarządzania (np. /wp-admin, /admin) są publicznie widoczne w wynikach wyszukiwarek.
16. Zestawienie zidentyfikowanych zasobów zewnętrznych w przejrzystą mapę powierzchni ataku (Attack Surface Map).
17. Klasyfikacja ryzyka dla każdego ujawnionego zasobu (subdomena deweloperska, wyciek metadanych, widoczny panel administracyjny).
18. Przygotowanie rekomendacji dla zarządu sklepu dotyczących usunięcia zbędnych wpisów DNS, ograniczenia dostępu do środowisk testowych poprzez VPN oraz czyszczenia metadanych publikowanych dokumentów.

Pasywny rekonesans OSINT charakteryzuje się tym, że badany podmiot nie jest w stanie wykryć audytu w swoich logach serwerowych, ponieważ audytor odpytuje wyłącznie serwisy trzecie (bazy WHOIS, Shodan, crt.sh, Google). Jest to kluczowy element etycznego przygotowania do testów penetracyjnych.

Serwis 'crt.sh' jest niezwykle cennym źródłem informacji. Zgodnie ze standardami przeglądarek każdy publicznie wystawiony certyfikat SSL musi zostać zgłoszony do publicznego logu Certificate Transparency. Wpisując w wyszukiwarkę zapytanie '%.zabawki-edu.pl', audytor uzyskuje listę subdomen, o których administratorzy często zapomnieli.

Poniżej pokazano przykładowe zapytanie WHOIS oraz inspekcję metadanych pliku PDF pobranego ze strony internetowej:

Zwróć uwagę na ujawnienie nazwiska autora w metadanych pliku PDF. Jest to typowy błąd organizacyjny ułatwiający cyberprzestępcom ataki inżynierii społecznej (spear phishing), ponieważ napastnik poznaje imię, nazwisko i rolę osoby odpowiedzialnej za IT.

W sprawozdaniu omów pojęcie 'Google Dorking' i wyjaśnij, w jaki sposób roboty wyszukiwarek internetowych mogą zindeksować pliki bazodanowe (np. 'filetype:sql' lub 'filetype:env') przypadkowo umieszczone w głównym katalogu serwera WWW.

1. Ocena skuteczności pasywnego wywiadu OSINT w identyfikacji niechronionych zasobów i subdomen przedsiębiorstwa.
2. Zagrożenia wynikające z ujawniania środowisk deweloperskich i testowych (staging) w publicznych logach Certificate Transparency.
3. Ryzyko związane z wyciekiem danych osobowych i technologicznych w metadanych dokumentów publikowanych na stronach WWW.
4. Rola wyszukiwarek typu Shodan i Censys w monitorowaniu ekspozycji usług sieciowych firmy bez generowania alertów bezpieczeństwa.
5. Wnioski etyczno-prawne dotyczące legalności zbierania danych ze źródeł ogólnodostępnych w granicach polskiego prawa.
6. Rekomendacje dotyczące wdrożenia procedury higieny cyfrowej: czyszczenie metadanych, ukrywanie subdomen deweloperskich za siecią VPN.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzony pasywny rekonesans OSINT ujawnił znaczny poziom nieświadomej ekspozycji cyfrowej sklepu internetowego w ogólnodostępnych źródłach sieciowych. Zidentyfikowanie zapomnianej subdomeny testowej ze środowiskiem deweloperskim oraz indeksowanie poufnych ścieżek w pliku robots.txt stwarzało dogodne warunki do przygotowania precyzyjnego ataku na aplikację główną. Analiza metadanych w udostępnionych plikach faktur PDF pozwoliła na odtworzenie struktury loginów pracowników oraz wersji oprogramowania biurowego bez generowania ani jednego pakietu do serwera ofiary. Wdrożenie procedury usuwania metadanych przed publikacją dokumentów oraz usunięcie nieużywanych rekordów DNS radykalnie zmniejsza powierzchnię ataku na platformę e-commerce. Pasywny audyt OSINT stanowi bezcenne narzędzie weryfikacji stanu bezpieczeństwa, pozwalając spojrzeć na organizację oczami potencjalnego adwersarza.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Autoryzacja i uwierzytelnianie. Efekty uczenia się: W1, U1, U3, U4, K1.

Celem ćwiczenia jest zbadanie bezpieczeństwa lokalnej infrastruktury bezprzewodowej (Wi-Fi) oraz identyfikacja podatności stacji roboczych wynikających z włączonych protokołów rozgłoszeniowych w sieci LAN. Studenci uczą się weryfikować stosowane mechanizmy szyfrowania transmisji radiowej (WPA2-PSK vs WPA3), poprawność separacji sieci dla gości oraz analizować zagrożenia związane z automatycznym rozwiązywaniem nazw w systemach Windows (protokoły LLMNR, NetBIOS-NS, mDNS). W trakcie ćwiczenia studenci dokonują pomiaru propagacji sygnału radiowego poza obrys lokalu biurowego agencji.

W trakcie prac laboratoryjnych zespół monitoruje ruch radiowy i kablowy za pomocą bezpłatnych narzędzi (Airodump-ng, Wireshark, Responder w trybie analizy/nasłuchu) w kontrolowanym środowisku laboratoryjnym. Studenci poznają mechanizm działania ataków typu Man-in-the-Middle polegających na zatruwaniu zapytań rozgłoszeniowych (LLMNR Poisoning) oraz metody ich całkowitej eliminacji. Pozwala to zrozumieć zjawisko niekontrolowanego wycieku fal elektromagnetycznych i potrzebę regulacji mocy nadawczej punktów dostępowych. Efektem pracy jest opracowanie polityki bezpieczeństwa sieci bezprzewodowej oraz wzorcowej konfiguracji zasad grupy (GPO) wyłączających zbędne protokoły na stacjach roboczych.

Agencja Interaktywna „Pixel-Creative” w Krakowie zajmuje się projektowaniem serwisów internetowych, kampanii reklamowych oraz produkcją materiałów wideo dla klientów korporacyjnych. W nowoczesnym biurze typu open space pracuje 25 grafików, programistów i copywriterów. Wszyscy pracownicy korzystają z laptopów podłączonych do firmowej sieci bezprzewodowej Wi-Fi. W biurze często goszczą klienci, którzy otrzymują dostęp do Internetu za pośrednictwem tego samego punktu dostępowego.

W trakcie wewnętrznego przeglądu administrator zauważył, że punkt dostępowy Wi-Fi rozgłasza tylko jedną sieć z prostym hasłem współdzielonym (WPA2-PSK), do której podłączone są zarówno laptopy pracowników z dostępem do serwera projektów, jak i prywatne smartfony gości odwiedzających agencję. Na routerze nie włączono mechanizmu izolacji klientów (Client Isolation), co oznacza, że każde urządzenie w sieci bezprzewodowej może swobodnie komunikować się z pozostałymi komputerami.

Ponadto stacje robocze z systemem Windows 10 i 11 posiadają domyślnie włączone protokoły Link-Local Multicast Name Resolution (LLMNR) oraz NetBIOS Name Service (NBT-NS). Gdy pracownik omyłkowo wpisze nieistniejącą nazwę serwera plików w eksploratorze Windows, system wysyła w całej sieci lokalnej zapytanie rozgłoszeniowe multicast. W takiej sytuacji dowolne urządzenie w sieci Wi-Fi może odpowiedzieć fałszywym komunikatem, wymuszając przesłanie skrótu hasła użytkownika (skrót NTLMv2) w celu podsłuchu.

Zarząd agencji zlecił zespołowi studentów przeprowadzenie technicznego audytu sieci Wi-Fi i stacji roboczych. Audytorzy mają za zadanie zbadać siłę szyfrowania sieci bezprzewodowej, sprawdzić czy gość może skanować komputery pracowników oraz zarejestrować zapytania rozgłoszeniowe generowane przez laptopy personelu. Testy muszą być przeprowadzone w sposób bezpieczny, bez zakłócania pracy agencji i bez przechwytywania rzeczywistych haseł pracowników.

W raporcie końcowym zespół audytorski przedstawia szczegółowe wytyczne techniczne. Obejmują one wdrożenie osobnej, odizolowanej sieci Wi-Fi dla gości z mechanizmem Client Isolation, podniesienie standardu szyfrowania do WPA3-Enterprise lub silnego WPA2 z unikalnymi poświadczeniami oraz procedurę natychmiastowego wyłączenia protokołów LLMNR i NetBIOS na wszystkich stacjach roboczych.

1. Określenie ram prawnych audytu sieci bezprzewodowej i uzyskanie pisemnej zgody zarządu agencji na badanie emisji radiowej.
2. Zbadanie widocznych sieci Wi-Fi w otoczeniu biura za pomocą narzędzia wiersza poleceń w systemie Linux ('nmcli dev wifi') lub Windows ('netsh wlan show networks mode=bssid').
3. Uruchomienie karty sieciowej w trybie monitora w środowisku laboratoryjnym za pomocą pakietu Aircrack-ng ('sudo airmon-ng start wlan0').
4. Przechwycenie parametrów punktu dostępowego agencji narzędziem airodump-ng ('sudo airodump-ng wlan0mon --bssid ') i weryfikacja stosowanego szyfrowania (WPA2 vs WPA3, algorytm CCMP/AES vs TKIP).
5. Zbadanie siły sygnału (RSSI) oraz obecności sieci rozgłaszających identyfikator SSID w strefie ogólnodostępnej (poza biurem agencji na korytarzu budynku).
6. Podłączenie stacji audytora do sieci Wi-Fi w roli gościa i weryfikacja przydzielonego adresu IP oraz maski podsieci.
7. Przetestowanie działania mechanizmu izolacji klientów (Client Isolation) poprzez próbę wysłania polecenia ping do innej stacji roboczej pracownika.
8. Zarejestrowanie, czy stacja gościa widzi pakiety rozgłoszeniowe generowane przez komputery personelu w programie Wireshark.
9. Zastosowanie filtru 'llmnr || nbns || mdns' w Wiresharku w celu zaobserwowania zapytań o nazwy zasobów w podsieci.
10. Zasymulowanie na stacji testowej wpisania błędnej nazwy udziału sieciowego (np. '\\\\serwer-projektow-nieistnieje') i zbadanie generowanego pakietu LLMNR UDP 5355.
11. Uruchomienie narzędzia Responder w trybie wyłącznie analitycznym/pasywnym ('sudo responder -I eth0 -A') w odizolowanym laboratorium, aby zweryfikować podatność sieci na ataki podsłuchowe.
12. Zaobserwowanie, jak narzędzie wykrywa zapytania LLMNR i NBT-NS bez wysyłania fałszywych odpowiedzi trujących (tryb Analyze).
13. Przeanalizowanie mechanizmu wymiany uwierzytelnienia NTLMv2 i wskazanie ryzyka związanego z próbą łamania przechwyconych skrótów haseł w trybie offline.
14. Przygotowanie instrukcji wyłączenia protokołu LLMNR w rejestrze systemu Windows (klucz HKLM\\Software\\Policies\\Microsoft\\Windows NT\\DNSClient\\EnableMulticast = 0).
15. Przygotowanie procedury wyłączenia usługi NetBIOS over TCP/IP we właściwościach karty sieciowej lub za pośrednictwem serwera DHCP.
16. Zaprojektowanie architektury dwóch odrębnych sieci Wi-Fi na punktach dostępowych agencji: SSID 'Pixel-Corp' (VLAN pracowniczy, 802.1X) oraz SSID 'Pixel-Guest' (VLAN gościnny, separacja klientów, pasmo ograniczone).
17. Weryfikacja zaleceń dotyczących przejścia na standard WPA3 (SAE - Simultaneous Authentication of Equals) eliminujący podatność na ataki słownikowe offline na handshake.
18. Opracowanie sprawozdania z audytu wraz z listą kontrolną (checklist) weryfikacji konfiguracji bezpieczeństwa dla nowo wdrażanych laptopów w firmie.

Protokoły LLMNR (UDP 5355) oraz NetBIOS-NS (UDP 137) są pozostałościami z dawnych czasów sieci komputerowych, gdy serwery DNS nie były powszechnie dostępne w małych sieciach LAN. Współcześnie stanowią one poważną lukę bezpieczeństwa, ponieważ system Windows rozsyła zapytania rozgłoszeniowe zawsze, gdy serwer DNS zwróci błąd braku nazwy.

Narzędzie Responder jest standardowym narzędziem wykorzystywanym w testach penetracyjnych. W zadaniu audytorskim na ocenę 3.0 używamy go wyłącznie z przełącznikiem '-A' (Analyze Mode). W tym trybie Responder nie wysyła żadnych fałszywych odpowiedzi zatruwających i nie przejmuje haseł, lecz działa jak wyspecjalizowany sniffer raportujący podatne komputery.

Poniżej pokazano przykładowe zbadanie parametrów sieci Wi-Fi w systemie Linux oraz nasłuch zapytań LLMNR narzędziem Responder w trybie analitycznym:

W systemie Windows wyłączenie protokołu LLMNR można zrealizować centralnie dla wszystkich komputerów w domenie Active Directory za pomocą edytora zasad grupy (gpedit.msc) w gałęzi: Konfiguracja komputera -> Szablony administracyjne -> Sieć -> Klient DNS -> Wyłącz rozpoznawanie nazw multiemisji.

W sprawozdaniu wyjaśnij różnicę pomiędzy protokołem WPA2-Personal (PSK), gdzie wszyscy użytkownicy dzielą jedno wspólne hasło do sieci, a WPA2/WPA3-Enterprise (802.1X), gdzie każdy pracownik loguje się indywidualnym loginem i hasłem lub certyfikatem cyfrowym.

1. Wykazanie niebezpieczeństw wynikających ze współdzielenia jednego segmentu Wi-Fi pomiędzy pracownikami a gośćmi agencji.
2. Mechanizm działania ataków podsłuchowych opartych na protokołach LLMNR i NetBIOS-NS oraz ocena ich powszechności.
3. Konieczność wdrożenia mechanizmu Client Isolation na punktach dostępowych Wi-Fi w celu ochrony stacji roboczych przed atakami wewnątrz sieci lokalnej.
4. Porównanie bezpieczeństwa protokołów WPA2-PSK oraz WPA3-SAE w kontekście podatności na ataki przechwytywania handshake i łamania offline.
5. Praktyczne korzyści z centralnego zarządzania konfiguracją stacji roboczych za pomocą zasad grupy (GPO) w celu eliminacji zbędnych usług sieciowych.
6. Rekomendacje dotyczące procedury bezpiecznego udostępniania Internetu gościom biura bez narażania zasobów produkcyjnych.

Przykładowe wnioski (wzór do sprawozdania): W toku audytu sieci bezprzewodowej agencji interaktywnej wykazano skrajną podatność protokołu WPA2-PSK na przechwycenie czterokierunkowego uścisku dłoni (4-way handshake) i złamanie hasła w trybie offline. Współdzielenie jednego klucza sieciowego przez wszystkich pracowników i klientów agencji uniemożliwiało jakąkolwiek rozliczalność i ułatwiało podsłuch ruchu projektowego wewnątrz firmy. Rekomendowana migracja do standardu WPA3-Personal (z algorytmem SAE odpornym na ataki słownikowe) lub WPA3-Enterprise z indywidualnymi kontami 802.1X trwale eliminuje zagrożenie przejęcia klucza sesji. Wdrożenie odrębnej podsieci dla gości z funkcją izolacji klientów skutecznie zabezpieczyło stacje robocze grafików i deweloperów przed niepowołanym skanowaniem. Audyt potwierdził, że bezpieczeństwo Wi-Fi wymaga ciągłej reewaluacji stosowanych mechanizmów szyfrowania i odrzucenia przestarzałych zabezpieczeń.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Efekty uczenia się: W1, U1, U3, U4, K1.

Celem zadania jest praktyczne zbadanie skali zagrożenia wynikającego ze stosowania fabrycznych lub domyślnych danych logowania (Default Credentials) w aktywnych urządzeniach sieciowych placówki oświatowej. Studenci uczą się identyfikować panele administracyjne urządzeń peryferyjnych (przełączniki zarządzalne, routery brzegowe, punkty dostępowe, sieciowe urządzenia wielofunkcyjne) oraz weryfikować ich odporność na próby logowania przy użyciu standardowych zestawów loginów i haseł. Studenci analizują również specyfikę urządzeń pracujących w trybie autonomicznym, które często nie są objęte centralnym systemem aktualizacji.

W trakcie laboratorium grupa zapoznaje się z publicznymi bazami domyślnych haseł producentów sprzętu IT oraz bezpiecznymi skryptami audytorskimi narzędzia Nmap (grupa auth). Studenci poznają rygorystyczne zasady etyczne zapobiegające zablokowaniu kont administracyjnych (Account Lockout) oraz uczą się konstruowania procedur wymuszania zmiany haseł podczas pierwszego uruchomienia sprzętu. Ćwiczenie wyczula przyszłych audytorów na konieczność tworzenia precyzyjnych rejestrów sprzętowych w każdej placówce publicznej. Wynikiem zadania jest raport audytowy zawierający rejestr podatnych urządzeń oraz instrukcję bezpiecznego zarządzania poświadczeniami.

Zespół Szkół Technicznych w Nowym Sączu posiada rozbudowaną infrastrukturę informatyczną obejmującą 4 pracownie komputerowe, sieć administracyjną w sekretariacie i księgowości oraz sieć Wi-Fi dla uczniów i nauczycieli. W skład infrastruktury sieciowej wchodzi 16 przełączników zarządzalnych różnych producentów (TP-Link, D-Link, Cisco), 8 punktów dostępowych Wi-Fi oraz 6 sieciowych urządzeń wielofunkcyjnych (kserokopiarek) zainstalowanych w pokojach nauczycielskich i bibliotece.

Sprzęt sieciowy był kupowany partiami na przestrzeni ostatnich siedmiu lat w ramach różnych projektów unijnych i instalowany przez różne firmy zewnętrzne. Nauczyciel pełniący funkcję administratora sieci nie otrzymał kompletnej dokumentacji powykonawczej z wykazem haseł administracyjnych. W trakcie rutynowych prac konserwacyjnych okazało się, że nowo podłączone przełączniki piętrowe w korytarzu szkolnym nadal posiadają fabryczny adres IP oraz standardowe hasło 'admin/admin'.

Uczniowie technikum informatycznego, dysponując smartfonami podłączonymi do szkolnej sieci, z łatwością odkryli panele webowe urządzeń i zaczęli dla żartu zmieniać konfigurację portów na przełącznikach, co doprowadziło do paraliżu łączności w sekretariacie szkoły podczas przesyłania danych do Systemu Informacji Oświatowej (SIO). Dyrektor szkoły zażądał natychmiastowego przeprowadzenia audytu wszystkich aktywnych urządzeń pod kątem domyślnych haseł.

Grupa studentów wciela się w audytorów bezpieczeństwa wykonujących inwentaryzację urządzeń w laboratoryjnej podsieci szkolnej. Zadaniem zespołu jest wykrycie wszystkich aktywnych paneli zarządzania (protokoły HTTP, HTTPS, Telnet, SSH, SNMP), ustalenie modeli urządzeń na podstawie nagłówków i banerów oraz przeprowadzenie ostrożnego testu podatności na domyślne dane uwierzytelniające. Audytorzy muszą ściśle przestrzegać zasady maksymalnie jednej próby logowania, aby nie zablokować urządzeń.

W podsumowaniu audytu studenci sporządzają raport wykazujący zidentyfikowane urządzenia wraz z przypisanym poziomem ryzyka. Zespół przygotowuje kompleksową procedurę zmiany haseł fabrycznych na silne hasła unikalne, wyłączenia nieszyfrowanych protokołów zarządzania (Telnet, HTTP) na rzecz SSH i HTTPS oraz odizolowania interfejsów zarządzających w dedykowanym, niedostępnym dla uczniów segmencie VLAN Management.

1. Zapoznanie się ze specyfikacją urządzeń sieciowych typowo spotykanych w placówkach edukacyjnych oraz zasadami bezpiecznego audytu poświadczeń.
2. Skanowanie laboratoryjnej podsieci szkolnej (192.168.56.0/24) w poszukiwaniu otwartych portów zarządzania: TCP 22 (SSH), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 8080 (Web-Alt) oraz UDP 161 (SNMP).
3. Identyfikacja producentów i modeli urządzeń na podstawie pobranych banerów tekstowych za pomocą flagi 'nmap -sV'.
4. Wytypowanie urządzeń sieciowych (przełącznik Cisco, router MikroTik, punkt dostępowy TP-Link, kserokopiarka HP) do szczegółowego badania.
5. Sprawdzenie publicznych baz wiedzy producentów (Default Password Databases, routerpasswords.com) w celu ustalenia fabrycznych poświadczeń dla zidentyfikowanych modeli.
6. Zbadanie konfiguracji usługi SNMP i weryfikacja podatności na domyślne ciągi społecznościowe (Community Strings: 'public', 'private') za pomocą skryptu 'nmap -sU -p 161 --script snmp-info'.
7. Zastosowanie skryptu Nmap 'http-default-accounts' na wykrytych panelach webowych w celu ostrożnej weryfikacji znanych kombinacji loginów i haseł.
8. Zbadanie panelu administracyjnego przełącznika za pomocą narzędzia curl ('curl -I http://192.168.56.50') i weryfikacja nagłówka 'WWW-Authenticate: Basic realm=...'.
9. Przeprowadzenie pojedynczego testu autoryzacji z poświadczeniami 'admin:admin' za pomocą polecenia 'curl -u admin:admin http://192.168.56.50/index.html' z rejestracją kodu odpowiedzi HTTP (200 OK vs 401 Unauthorized).
10. Zbadanie obecności otwartego i nieszyfrowanego portu Telnet (TCP 23) na starym przełączniku dystrybucyjnym.
11. Zweryfikowanie możliwości zalogowania się na port Telnet przy użyciu domyślnego konta 'cisco/cisco' lub 'admin/admin' w środowisku testowym.
12. Zbadanie panelu sieciowej kserokopiarki pod kątem braku jakiegokolwiek hasła na koncie administratora (częsta przypadłość drukarek sieciowych).
13. Ocena ryzyka przejęcia kontroli nad ruchem w szkole przez nieautoryzowanego użytkownika (np. zmiana serwera DNS na przełączniku, podsłuch portów poprzez Port Mirroring).
14. Opracowanie polityki zarządzania hasłami dla urządzeń sieciowych: minimalna długość 16 znaków, losowa generacja, przechowywanie w bezpiecznym menedżerze haseł (np. KeePassXC).
15. Przygotowanie przykładowych poleceń CLI dla routera i przełącznika wyłączających dostęp przez Telnet i HTTP oraz aktywujących bezpieczny dostęp SSH.
16. Zaprojektowanie wydzielonego segmentu sieciowego VLAN 99 (VLAN Zarządczy / Management VLAN) z dostępem ograniczonym wyłącznie do stacji roboczej administratora.
17. Wdrożenie reguł filtrowania na zaporze ogniowej blokujących dostęp do portów zarządzających ze strefy Wi-Fi dla uczniów.
18. Sporządzenie formalnego rejestru urządzeń sieciowych szkoły zawierającego adresy IP, wersje oprogramowania układowego (firmware) oraz status zmiany hasła fabrycznego.

Weryfikacja domyślnych danych logowania różni się diametralnie od ataków siłowych (Brute Force). Audytor nie przeprowadza masowego zgadywania tysięcy haseł ze słownika, lecz testuje jedynie 1–2 standardowe kombinacje przewidziane przez producenta danego modelu (np. admin/admin, admin/1234, ubnt/ubnt).

Bardzo częstym i niebezpiecznym przeoczeniem jest pozostawienie domyślnego ciągu SNMP Community 'public'. Protokół SNMPv1/v2c przesyła zapytania bez szyfrowania, a znajomość ciągu 'public' pozwala każdemu użytkownikowi sieci na odczytanie pełnej tablicy routingu, listy adresów MAC i konfiguracji interfejsów przełącznika.

Poniżej pokazano przykładowe zbadanie usługi SNMP oraz weryfikację domyślnych danych logowania panelu webowego urządzenia sieciowego:

W sprawozdaniu podkreśl, że protokoły Telnet oraz HTTP powinny zostać bezwzględnie wyłączone na wszystkich urządzeniach sieciowych. Zarządzanie powinno odbywać się wyłącznie za pośrednictwem szyfrowanych protokołów SSH (w wersji 2) oraz HTTPS z aktualnymi certyfikatami.

W przypadku urządzeń wielofunkcyjnych (drukarek/kserokopiarek) wskaż, że dostęp do ich wbudowanych serwerów WWW często pozwala na pobranie skanów dokumentów z pamięci urządzenia lub podejrzenie konfiguracji książki adresowej e-mail.

1. Wpływ zaniedbań konfiguracyjnych w urządzeniach sieciowych na bezpieczeństwo całej infrastruktury teleinformatycznej szkoły.
2. Ryzyko wynikające z pozostawienia domyślnych haseł w kontekście dostępu uczniów do sieci kablowej i bezprzewodowej.
3. Zagrożenia związane z udostępnianiem usługi SNMP z domyślnym ciągiem 'public' umożliwiającym rekonesans sieci.
4. Konieczność bezwzględnego wycofania nieszyfrowanych protokołów zarządzania (Telnet, HTTP) na rzecz SSH i HTTPS.
5. Rola właściwej segmentacji sieci i wdrożenia dedykowanego VLAN Zarządczego (Management VLAN) odizolowanego od użytkowników.
6. Wymogi organizacyjne: wprowadzenie formalnej procedury odbioru technicznego nowo instalowanego sprzętu z wymogiem zmiany haseł.

Przykładowe wnioski (wzór do sprawozdania): Weryfikacja urządzeń sieciowych w szkole wykazała obecność fabrycznych danych logowania na przełącznikach zarządzalnych i kamerach monitoringu wizyjnego, co umożliwiało natychmiastowe przejęcie kontroli nad infrastrukturą przez uczniów. Wykorzystanie darmowych skryptów Nmap NSE pozwoliło na błyskawiczne zautomatyzowanie audytu i wykrycie aktywnych, nieszyfrowanych paneli administracyjnych Telnet i HTTP. Bezwzględna zmiana haseł domyślnych na unikalne hasła złożone oraz wyłączenie protokołów jawnych na rzecz SSH i HTTPS stanowi fundament higieny teleinformatycznej. Wprowadzenie dedykowanego VLAN-u do zarządzania urządzeniami odcięło dostęp do interfejsów administracyjnych ze strony komputerów w pracowniach uczniowskich. Wyniki zadania dowodzą, że zaniedbania na etapie instalacji sprzętu sieciowego mogą całkowicie zniweczyć bezpieczeństwo nawet poprawnie skonstruowanej sieci.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Efekty uczenia się: W1, W4, U1, U3, K1.

Celem zadania jest przeprowadzenie audytu technicznego stacji roboczych oraz sieci lokalnej w środowisku przetwarzającym dane o najwyższym rygorze poufności – kancelarii notarialnej. Studenci uczą się weryfikować bezpieczeństwo usług zdalnego pulpitu (RDP), badać podatność lokalnego segmentu sieci LAN na podsłuch transmisyjny (zatruwanie tablic ARP) oraz oceniać konfigurację zapory sieciowej na komputerach pracowników.

W trakcie laboratorium zespół bada stacje z systemem Windows i Linux pod kątem otwartych portów RPC i RDP, weryfikuje wymóg stosowania uwierzytelniania na poziomie sieci (Network Level Authentication, NLA) oraz analizuje w kontrolowanym środowisku wirtualnym teoretyczne i praktyczne aspekty ataku ARP Spoofing. Praca kładzie szczególny nacisk na etykę audytora, bezwzględne przestrzeganie tajemnicy notarialnej oraz rygory art. 267 Kodeksu karnego. Wynikiem jest plan zabezpieczenia stacji i wdrożenia mechanizmów obronnych na przełącznikach (Dynamic ARP Inspection).

Kancelaria Notarialna w Bochni prowadzona przez dwóch notariuszy zatrudnia 4 asystentów oraz sekretarza. W kancelarii sporządzane są akty notarialne dotyczące obrotu nieruchomościami o wielomilionowej wartości, umowy majątkowe małżeńskie, testamenty oraz protokoły spółek prawa handlowego. Dokumenty te zawierają najbardziej poufne dane majątkowe i osobiste klientów, a ich ujawnienie stanowiłoby rażące naruszenie tajemnicy notarialnej oraz przepisów RODO.

W kancelarii funkcjonuje sieć lokalna łącząca 6 stacji roboczych z systemem Windows 11 Pro, sieciowy skaner dokumentów oraz serwer z bazą repertoriów notarialnych. W okresie pandemii informatyk skonfigurował możliwość pracy zdalnej, włączając na komputerach asystentów usługę Pulpitu Zdalnego (Remote Desktop Protocol, RDP port 3389). Podczas ostatniego przeglądu notariusz zauważył, że na jednym z komputerów wyłączono zaporę sieciową Windows Defender Firewall, aby ułatwić przesyłanie skanów z kserokopiarki.

Kancelaria korzysta z usług zewnętrznego serwisu sprzątającego oraz przyjmuje w salach konferencyjnych klientów z własnymi laptopami, którzy czasami proszą o podłączenie do kabla sieciowego pod stołem. Notariusze powzięli uzasadnioną obawę, że osoba postronna podłączająca się do gniazda Ethernet w sali spotkań mogłaby podsłuchać ruch w sieci lokalnej lub podjąć próbę połączenia się z pulpitami pracowników za pośrednictwem usługi RDP.

Zespół studentów podejmuje się przeprowadzenia audytu bezpieczeństwa stacji roboczych kancelarii w wiernie odtworzonym środowisku wirtualnym. Zadanie polega na zbadaniu widoczności portów RDP i RPC w podsieci, zweryfikowaniu czy usługa RDP wymusza bezpieczne uwierzytelnianie NLA oraz zasymulowaniu w izolowanym laboratorium podatności protokołu ARP na zatrucie (ARP Poisoning), aby zrozumieć mechanizm podsłuchu w niesegmentowanej sieci biurowej.

W końcowym sprawozdaniu audytorzy prezentują analizę ryzyka i opracowują wytyczne techniczne. Zespół rekomenduje wdrożenie uwierzytelniania NLA, wyłączenie RDP na stacjach niewymagających zdalnego dostępu, aktywację zapory ogniowej z blokadą ruchu przychodzącego z obcych podsieci oraz wdrożenie na przełączniku funkcji Dynamic ARP Inspection (DAI) i DHCP Snooping eliminujących możliwość podsłuchu.

1. Zapoznanie się z przepisami Ustawy Prawo o notariacie w zakresie ochrony tajemnicy notarialnej oraz określenie zasad zaangażowania (RoE).
2. Skanowanie laboratoryjnej podsieci kancelarii w celu identyfikacji stacji roboczych z otwartymi portami TCP 3389 (RDP), 135 (RPC) oraz 445 (SMB).
3. Weryfikacja konfiguracji usługi RDP na stacji roboczej za pomocą skryptu Nmap 'rdp-enum-encryption' pod kątem obsługiwanych algorytmów szyfrowania.
4. Sprawdzenie, czy usługa Pulpitu Zdalnego wymusza uwierzytelnianie na poziomie sieci (Network Level Authentication, NLA) przy użyciu skryptu 'rdp-ntlm-info'.
5. Analiza certyfikatu cyfrowego wystawionego dla usługi RDP (często certyfikat samopodpisany generowany automatycznie przez system Windows).
6. Zbadanie stanu zapory sieciowej na stacjach roboczych i weryfikacja reguł profilu 'Sieć prywatna' oraz 'Sieć publiczna'.
7. Zapoznanie się z teoretyczną zasadą działania protokołu Address Resolution Protocol (ARP) oraz brakiem mechanizmów uwierzytelniania w zapytaniach i odpowiedziach ARP.
8. Uruchomienie w izolowanym środowisku wirtualnym (dwie maszyny laboratoryjne) narzędzia arpspoof w celu demonstracji mechanizmu zatruwania tablicy ARP ('arpspoof -i eth0 -t ').
9. Obserwacja zmian w tablicy ARP atakowanej maszyny za pomocą polecenia 'arp -a' (podmiana adresu MAC bramy domyślnej na MAC audytora).
10. Przeanalizowanie w programie Wireshark ramek fałszywych odpowiedzi ARP Reply generowanych podczas ataku w laboratorium.
11. Zbadanie, jak podsłuch ARP umożliwia przejęcie nieszyfrowanego ruchu stacji i dlaczego transmisje szyfrowane (HTTPS, RDP z NLA) chronią treść przed bezpośrednim odczytem.
12. Natychmiastowe zatrzymanie testu ARP w laboratorium i przywrócenie poprawnej konfiguracji sieciowej.
13. Opracowanie instrukcji włączenia wymogu NLA w systemie Windows: Właściwości systemu -> Zdalny -> Zezwalaj na połączenia tylko z komputerów z NLA.
14. Przygotowanie konfiguracji zapory Windows Defender blokującej połączenia RDP ze wszystkich adresów IP poza zdefiniowaną podsiecią zarządzania.
15. Zaprojektowanie reguł bezpieczeństwa na przełączniku sieciowym: włączenie funkcji DHCP Snooping oraz Dynamic ARP Inspection (DAI) w celu automatycznego blokowania fałszywych pakietów ARP.
16. Weryfikacja procedury blokowania nieużywanych gniazd sieciowych w sali konferencyjnej kancelarii (wyłączenie portów na przełączniku - 'shutdown').
17. Sformułowanie zaleceń dotyczących wdrożenia szyfrowania całych dysków stacji roboczych (BitLocker / LUKS) na wypadek kradzieży sprzętu z kancelarii.
18. Przygotowanie raportu z audytu prezentującego podsumowanie ryzyk dla notariuszy oraz plan wdrożenia środków zaradczych.

Uwierzytelnianie na poziomie sieci (NLA) jest krytycznym mechanizmem zabezpieczającym usługę RDP. Bez NLA serwer RDP wyświetla pełny graficzny ekran logowania Windows każdemu, kto połączy się z portem 3389, co umożliwia ataki wyczerpania zasobów oraz eksploatację luk w bibliotekach graficznych serwera RDP (np. luka BlueKeep).

Atak ARP Spoofing polega na rozsyłaniu fałszywych pakietów ARP informujących, że adres IP bramy domyślnej jest powiązany z adresem MAC stacji atakującej. W nowoczesnych sieciach przełączanych ochroną przed tym atakiem jest mechanizm Dynamic ARP Inspection (DAI), który weryfikuje poprawność pakietów ARP w oparciu o bazę powiązań DHCP Snooping.

Poniżej pokazano przykładowe zbadanie konfiguracji usługi RDP skryptem Nmap oraz weryfikację tablicy ARP na stacji roboczej:

Pamiętaj, że demonstrację ataku ARP Spoofing wolno wykonywać WYŁĄCZNIE w odizolowanym środowisku maszyn wirtualnych laboratorium. Wykonanie takiego testu w rzeczywistej sieci bez pisemnej autoryzacji stanowi przestępstwo z art. 268a Kodeksu karnego (niszczenie lub zakłócanie danych informatycznych).

W systemie Windows stan usługi RDP oraz wymóg NLA można zweryfikować w rejestrze: klucz 'HKLM\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication' (wartość 1 oznacza włączone NLA).

1. Znaczenie ochrony tajemnicy notarialnej i danych osobowych klientów w kontekście konfiguracji bezpieczeństwa stacji roboczych.
2. Rola uwierzytelniania na poziomie sieci (NLA) w zabezpieczaniu usługi RDP przed atakami typu pre-auth i odmową usługi.
3. Zrozumienie słabości protokołu ARP w sieciach lokalnych oraz mechanizmu działania ataków Man-in-the-Middle.
4. Skuteczność sprzętowych mechanizmów obronnych na przełącznikach (Dynamic ARP Inspection, DHCP Snooping, Port Security).
5. Etyczne i prawne granice testowania bezpieczeństwa: bezwzględny zakaz nieautoryzowanego podsłuchu i zakłócania pracy sieci.
6. Rekomendacje dotyczące procedury fizycznego zabezpieczenia gniazd sieciowych w strefach dostępnych dla klientów kancelarii.

Przykładowe wnioski (wzór do sprawozdania): Audyt stacji roboczych w kancelarii notarialnej ujawnił szereg uchybień w zakresie zabezpieczenia danych w spoczynku oraz kontroli fizycznego dostępu do terminali pracowniczych. Brak pełnego szyfrowania dysków systemowych stwarzał ryzyko wycieku repertorium notarialnego i projektów aktów własności w razie kradzieży sprzętu lub włamania do lokalu. Wdrożenie zasad automatycznej blokady sesji po 3 minutach bezczynności oraz ograniczenie obsługi niezaufanych nośników USB w zasadach GPO wyeliminowało podstawowe wektory wycieku danych. Zastosowanie narzędzi skryptowych w środowisku PowerShell pozwoliło na szybką inwentaryzację stanu poprawek systemowych i konfiguracji zapory lokalnej na wszystkich maszynach. Ostateczne zalecenia audytorskie zapewniają pełną zgodność funkcjonowania kancelarii z rygorami tajemnicy notarialnej oraz wytycznymi Krajowej Rady Notarialnej w zakresie cyberbezpieczeństwa.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Kon4 Sieciowe systemy składowania danych. Efekty uczenia się: W1, W3, U1, U3, U4, K1.

Celem zadania jest nabycie praktycznych umiejętności oceny bezpieczeństwa konfiguracji relacyjnych baz danych (MySQL/MariaDB/PostgreSQL) wykorzystywanych w środowiskach wytwórczych oprogramowania. Studenci uczą się weryfikować ekspozycję sieciową portów bazodanowych, badać poprawność konfiguracji uwierzytelniania użytkowników, sprawdzać obecność kont z pustymi lub domyślnymi hasłami oraz kontrolować wymuszanie szyfrowania transmisji protokołem TLS.

W trakcie ćwiczenia laboratoryjnego grupa analizuje konfigurację serwera bazy danych w plikach konfiguracyjnych (np. my.cnf, mysqld.cnf), weryfikuje uprawnienia użytkowników na poziomie tabel i baz danych oraz sprawdza odporność usługi na zdalny rekonesans za pomocą skryptów Nmap NSE. Studenci badają powszechne błędy programistyczne, takie jak używanie konta 'root' w aplikacjach webowych. Rezultatem zadania jest opracowanie zaleceń utwardzania (hardening) serwera bazy danych zgodnie z zasadą najmniejszych uprawnień.

Spółka „Soft-Dev Innovations” w Rzeszowie jest małym software house'em zatrudniającym 12 programistów, testerów i inżynierów DevOps. Firma tworzy dedykowane aplikacje webowe i mobilne dla klientów z sektora e-commerce oraz usług finansowych. W lokalnej serwerowni oraz w chmurze prywatnej firma utrzymuje serwery baz danych MySQL oraz PostgreSQL, na których przechowywane są bazy deweloperskie, środowiska testowe oraz kopie robocze danych produkcyjnych.

W celu ułatwienia pracy zdalnej programistom pracującym z domu administrator bazy danych zmienił dyrektywę 'bind-address' z lokalnej 127.0.0.1 na 0.0.0.0, wystawiając port 3306 bezpośrednio na interfejs sieciowy. Ponadto dla ułatwienia testów utworzono użytkownika 'dev_user' z prawami dostępu ze wszystkich adresów IP ('dev_user'@'%') i przydzielono mu pełne uprawnienia administracyjne (GRANT ALL PRIVILEGES), a część kont testowych nie posiada w ogóle ustawionego hasła.

Nowy kierownik projektu ds. bezpieczeństwa zauważył, że aplikacje klienckie łączą się z bazą danych przez nieszyfrowane połączenia TCP, przesyłając zapytania SQL, loginy i dane osobowe otwartym tekstem przez sieć lokalną. Dodatkowo w logach serwera odnotowano próby automatycznego skanowania portu 3306 z zewnątrz. Zaistniało bezpośrednie ryzyko nieuprawnionego pobrania baz danych przez konkurencję lub zainstalowania ransomware szyfrującego tabele SQL.

Zespół audytorów laboratoryjnych podejmuje zadanie przeprowadzenia kompleksowego przeglądu konfiguracji serwera bazy danych. Studenci weryfikują z zewnątrz dostępność portu 3306, badają wersję silnika bazy danych, sprawdzają czy serwer zezwala na połączenia bez szyfrowania SSL/TLS oraz badają uprawnienia kont bazodanowych. Wszystkie czynności audytowe realizowane są w sposób bezinwazyjny bez modyfikacji zawartości tabel.

Końcowym efektem pracy studentów jest opracowanie raportu technicznego z audytu bazy danych. Raport zawiera wykaz wykrytych nieprawidłowości, ocenę ryzyka wycieku danych klientów oraz gotowy zestaw dyrektyw konfiguracyjnych dla serwera MySQL, obejmujących ograniczenie nasłuchiwania interfejsów, wymuszenie TLS (require_secure_transport = ON), usunięcie kont testowych oraz wdrożenie bezpiecznych ról użytkowników o minimalnych uprawnieniach.

1. Zapoznanie się ze specyfikacją serwera bazy danych MySQL/MariaDB oraz wymaganiami bezpieczeństwa przechowywania danych w oparciu o normę ISO/IEC 27001.
2. Przeprowadzenie zewnętrznego rekonesansu portu bazy danych (TCP 3306 dla MySQL, TCP 5432 dla PostgreSQL) za pomocą narzędzia Nmap.
3. Uruchomienie skryptów Nmap NSE dedykowanych do badania MySQL: 'mysql-info', 'mysql-enum', 'mysql-empty-password'.
4. Zbadanie wersji silnika bazy danych pobranej w nagłówku powitalnym i wyszukanie znanych luk w bazie CVE.
5. Weryfikacja, czy serwer bazy danych posiada aktywne konta z pustym hasłem (Empty Password) na podstawie raportu skryptu 'mysql-empty-password'.
6. Próba nawiązania połączenia z poziomu stacji audytora za pomocą klienta wiersza poleceń ('mysql -h 192.168.56.100 -u root -p') w celu sprawdzenia blokady zdalnego logowania konta root.
7. Zbadanie wymuszania szyfrowania TLS podczas nawiązywania sesji za pomocą polecenia 'mysql -h 192.168.56.100 -u dev_user --ssl-mode=DISABLED' (czy serwer odrzuca połączenia bez SSL).
8. Zweryfikowanie statusu szyfrowania aktywnej sesji poleceniem SQL 'SHOW STATUS LIKE "Ssl_cipher";' (obecność aktywnego szyfru potwierdza bezpieczny kanał).
9. Przeanalizowanie pliku konfiguracyjnego serwera MySQL (/etc/mysql/mysql.conf.d/mysqld.cnf) na maszynie laboratoryjnej.
10. Zbadanie dyrektywy 'bind-address' i wykazanie ryzyka nasłuchiwania na adresie 0.0.0.0 zamiast 127.0.0.1 lub dedykowanym IP podsieci prywatnej.
11. Inspekcja tabeli 'mysql.user' poleceniem SQL 'SELECT User, Host, plugin, authentication_string FROM mysql.user;' w celu wykrycia kont z maską '%'.
12. Weryfikacja uprawnień użytkowników za pomocą polecenia 'SHOW GRANTS FOR "dev_user"@"%";' i zidentyfikowanie nadmiarowych uprawnień (SUPER, GRANT OPTION, DROP).
13. Zbadanie obecności domyślnej bazy danych 'test' oraz anonimowych kont użytkowników tworzonych historycznie w starszych instalacjach MySQL.
14. Przechwycenie nieszyfrowanej sesji SQL w programie Wireshark (filtr 'mysql') i odczytanie treści przesyłanych zapytań SELECT zawierających dane osobowe.
15. Zaprojektowanie wzorcowej konfiguracji utwardzającej w pliku mysqld.cnf: 'bind-address = 127.0.0.1', 'require_secure_transport = ON', 'local_infile = OFF'.
16. Opracowanie bezpiecznych poleceń SQL tworzących użytkownika dedykowanego wyłącznie dla aplikacji webowej z uprawnieniami ograniczonymi do SELECT, INSERT, UPDATE, DELETE na jednej bazie.
17. Przygotowanie procedury bezpiecznego dostępu zdalnego dla programistów za pośrednictwem tunelu SSH (SSH Port Forwarding) zamiast otwierania portu 3306 do sieci publicznej.
18. Sformułowanie syntetycznych wniosków audytorskich i przygotowanie raportu podsumowującego dla zarządu software house'u.

Wystawienie portu bazy danych 3306 bezpośrednio do sieci publicznej lub szerokiej sieci lokalnej jest jednym z najpoważniejszych błędów architektonicznych. Baza danych powinna być dostępna wyłącznie lokalnie (localhost) dla aplikacji działającej na tym samym serwerze lub odpytywana przez bezpieczny tunel SSH lub dedykowany interfejs sieci prywatnej.

Dyrektywa 'require_secure_transport = ON' wprowadzona w MySQL 5.7+ jest kluczowym mechanizmem obronnym. Gdy jest aktywna, serwer automatycznie odrzuca wszelkie próby logowania użytkowników korzystających z nieszyfrowanych połączeń TCP, chroniąc poświadczenia przed podsłuchem.

Poniżej pokazano przykładowe zbadanie serwera MySQL za pomocą skryptów Nmap oraz weryfikację uprawnień i szyfrowania w konsoli klienta MySQL:

Zwróć uwagę na dyrektywę 'local_infile = OFF'. Pozostawienie jej włączonej pozwala klientowi bazy danych na odczytywanie lokalnych plików z systemu operacyjnego serwera za pomocą polecenia 'LOAD DATA LOCAL INFILE', co w przypadku wystąpienia wstrzyknięcia SQL (SQL Injection) prowadzi do całkowitego wycieku plików systemowych (np. /etc/passwd).

W sprawozdaniu wyjaśnij, jak działa tunelowanie portów przez SSH ('ssh -L 3307:127.0.0.1:3306 user@serwer.pl'), które umożliwia programistom bezpieczną pracę na lokalnym porcie 3307 bez otwierania bazy danych na świat.

1. Wpływ błędnej konfiguracji nasłuchiwania interfejsów sieciowych (bind-address 0.0.0.0) na ekspozycję bazy danych na ataki z sieci.
2. Zagrożenia wynikające ze stosowania kont bazodanowych z uniwersalną maską hosta ('%') i pustymi poświadczeniami.
3. Konieczność bezwzględnego wymuszania szyfrowania TLS w relacjach klient-serwer bazy danych w celu ochrony przed podsłuchem.
4. Wdrożenie zasady najmniejszych uprawnień (Least Privilege) w zarządzaniu kontami użytkowników aplikacji i eliminacja użycia konta root.
5. Zastosowanie tuneli kryptograficznych SSH jako bezpiecznej alternatywy dla bezpośredniego wystawiania portów bazodanowych.
6. Rekomendacje dotyczące audytu logów zapytań (General Query Log / Audit Plugin) w celu wczesnego wykrywania prób nadużyć.

Przykładowe wnioski (wzór do sprawozdania): Audyt serwera bazy danych w środowisku deweloperskim ujawnił niebezpieczną praktykę nasłuchiwania usługi na publicznym interfejsie sieciowym oraz stosowanie uprawnień konta 'root' przez aplikację webową. Wykazano, że błędy walidacji danych wejściowych w połączeniu ze zbyt szerokimi uprawnieniami konta bazy danych umożliwiają całkowite pobranie zawartości tabel za pomocą podstawowych technik SQL Injection. Ograniczenie nasłuchu bazy do pętli zwrotnej 127.0.0.1 oraz utworzenie dedykowanego użytkownika z uprawnieniami zawężonymi wyłącznie do operacji SELECT, INSERT i UPDATE radykalnie zredukowało ryzyko kompromitacji. Zastosowanie zapytań parametryzowanych (Prepared Statements) w kodzie źródłowym trwale zabezpieczyło aplikację przed wstrzykiwaniem złośliwego kodu SQL. Zadanie potwierdziło, że bezpieczeństwo warstwy bazodanowej wymaga ścisłej współpracy administratorów systemowych z zespołem programistycznym.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Efekty uczenia się: W1, U1, U3, U4, K1.

Głównym celem zadania jest nabycie umiejętności praktycznej weryfikacji skuteczności zapory sieciowej (Firewall) zainstalowanej na routerze brzegowym przedsiębiorstwa oraz badanie poprawności filtracji ruchu sieciowego. Studenci uczą się odróżniać zaawansowane techniki skanowania portów (TCP SYN, UDP, TCP FIN, Null, Xmas, ACK) oraz analizować, w jaki sposób router brzegowy (system MikroTik RouterOS lub Linux iptables/nftables) reaguje na pakiety o nietypowych kombinacjach flag TCP. Uczestnicy zajęć weryfikują zachowanie routera w odpowiedzi na próby skanowania ze sfałszowanym adresem źródłowym.

W trakcie laboratorium grupa analizuje reguły filtrowania ruchu przychodzącego, weryfikuje zabezpieczenie routera przed pakietami o stanie niepoprawnym (connection-state=invalid) oraz bada, czy porty zarządzające urządzeniem brzegowym (SSH, WinBox, WebFig) są prawidłowo odizolowane od publicznego interfejsu WAN. Studenci uczą się identyfikować błędy w kolejności reguł firewalla oraz projektować bezpieczne łańcuchy reguł filtrujących. Zdobyta wiedza pozwala na świadome projektowanie reguł zapory, które skutecznie chronią sieć lokalną przed niepowołaną penetracją. Końcowym efektem jest stworzenie kompleksowego raportu z audytu zapory brzegowej z gotowymi regułami konfiguracyjnymi.

Spółdzielnia Mieszkaniowa „Zacisze” w Oświęcimiu zarządza 45 budynkami wielorodzinnymi zamieszkanymi przez ponad 6000 lokatorów. W biurze spółdzielni funkcjonuje sieć teleinformatyczna obsługująca dział czynszów, księgowość, dział techniczny oraz system zdalnego odczytu wodomierzy i podzielników ciepła. Cała sieć biura podłączona jest do Internetu za pośrednictwem routera brzegowego MikroTik RouterOS z bezpośrednim publicznym adresem IP przydzielonym przez operatora telekomunikacyjnego.

Dotychczasowa konfiguracja routera brzegowego została przygotowana w pośpiechu podczas podłączania nowego łącza światłowodowego. Administrator utworzył regułę maskarady (NAT) dla sieci wewnętrznej, lecz w łańcuchu filtrowania wejściowego (input) nie zdefiniował domyślnej reguły odrzucania ruchu (drop), przez co wszystkie porty usługowe routera – w tym panel konfiguracyjny WebFig (port 80), panel WinBox (port 8291) oraz port Telnet (port 23) – są widoczne i dostępne z dowolnego miejsca w globalnej sieci Internet.

W ostatnich tygodniach w logach systemowych routera zaczęły masowo pojawiać się próby logowania na konto 'admin' pochodzące z adresów IP zlokalizowanych w różnych częściach świata. Wzrost obciążenia procesora routera do 100% doprowadził do okresowych przerw w łączności z bankowością elektroniczną spółdzielni oraz zakłóceń w pracy systemu odczytu liczników. Prezes spółdzielni nakazał pilne przeprowadzenie audytu bezpieczeństwa routera brzegowego i szczelności zapory ogniowej.

Zespół audytorów laboratoryjnych podejmuje zadanie oceny bezpieczeństwa bramy brzegowej w kontrolowanym środowisku wirtualnym (maszyna z systemem MikroTik RouterOS lub Linux z zaporą iptables). Studenci badają router zarówno od strony symulowanego interfejsu zewnętrznego (WAN), jak i od strony sieci lokalnej (LAN). Audytorzy testują reakcję zapory na skanowanie TCP SYN, skanowanie UDP oraz nietypowe pakiety TCP FIN i Xmas, weryfikując czy zapora działa w sposób stanowy (Stateful Firewall).

Po zebraniu wyników skanowania zespół opracowuje profesjonalny raport audytowy prezentujący wykryte luki w filtrowaniu ruchu. Studenci przygotowują zoptymalizowany zestaw reguł zapory RouterOS/iptables, wdrażający bezwzględną blokadę pakietów niepożądanych na interfejsie WAN, wyłączenie nieużywanych usług (Telnet, FTP, WWW) oraz ograniczenie dostępu administracyjnego do dedykowanego adresu IP w sieci LAN lub bezpiecznego tunelu VPN.

1. Zdefiniowanie zakresu audytu bramy brzegowej i zapoznanie się z architekturą zapory stanowej (Stateful Packet Inspection, SPI).
2. Uruchomienie stanowiska laboratoryjnego z routerem brzegowym (MikroTik RouterOS / Linux) i skonfigurowanymi dwoma interfejsami: WAN (zewnętrzny) i LAN (wewnętrzny).
3. Podłączenie stacji audytora do interfejsu WAN w celu symulacji perspektywy zewnętrznego atakującego z Internetu.
4. Przeprowadzenie szybkiego skanowania TCP SYN najpopularniejszych 100 portów na adresie WAN routera ('nmap -sS --top-ports 100 192.168.1.1').
5. Zidentyfikowanie otwartych portów usług zarządzających routerem: TCP 80 (WebFig), TCP 8291 (WinBox), TCP 22 (SSH), TCP 23 (Telnet).
6. Wykonanie skanowania TCP FIN ('nmap -sF 192.168.1.1') oraz skanowania Xmas ('nmap -sX 192.168.1.1') w celu zbadania zachowania stosu TCP/IP routera na pakiety z nieprawidłowymi kombinacjami flag.
7. Przeprowadzenie skanowania portów UDP ('nmap -sU --top-ports 20 192.168.1.1') i weryfikacja dostępności portu UDP 53 (DNS) oraz UDP 161 (SNMP).
8. Zbadanie, czy router brzegowy nie działa jako otwarty serwer DNS (Open DNS Relay), co mogłoby posłużyć do ataków DDoS typu DNS Amplification.
9. Zalogowanie się do konsoli zarządzania routerem ze stacji LAN w celu pobrania i przeanalizowania bieżącej tablicy reguł zapory ogniowej ('/ip firewall filter print').
10. Zidentyfikowanie braku domyślnej reguły odrzucającej na końcu łańcucha input (brak zasady Default Deny).
11. Sprawdzenie obecności reguł akceptujących pakiety o stanie powiązanym i nawiązanym ('connection-state=established,related').
12. Zbadanie, czy zapora posiada aktywną regułę natychmiastowego odrzucania pakietów niepoprawnych ('connection-state=invalid').
13. Zbadanie konfiguracji usług systemowych routera ('/ip service print') i wskazanie zbędnych aktywnych demonów (telnet, ftp, api).
14. Zaprojektowanie wzorcowego zestawu reguł łańcucha input w systemie RouterOS, blokującego wszelki ruch z interfejsu WAN z wyjątkiem odpowiedzi na ruch inicjowany przez router.
15. Skonfigurowanie reguły wyłączającej odpowiedź na zapytania ICMP (ping) z interfejsu WAN lub ograniczającej ich częstotliwość (Rate Limiting).
16. Wyłączenie nieużywanych usług zarządzania oraz zmiana domyślnych portów dla usług niezbędnych (np. zmiana portu SSH z 22 na niestandardowy).
17. Powtórzenie skanowania Nmap od strony interfejsu WAN po wdrożeniu poprawek w celu zweryfikowania, czy wszystkie porty uzyskały status 'filtered'.
18. Przygotowanie raportu podsumowującego audyt bramy brzegowej z kompletnym skryptem konfiguracyjnym dla administratora spółdzielni mieszkaniowej.

W zaporze stanowej (Stateful Firewall) kluczową koncepcją jest śledzenie połączeń (Connection Tracking). Pierwszą i najważniejszą regułą w każdym łańcuchu filtrowania powinna być reguła akceptująca pakiety należące do połączeń już nawiązanych lub powiązanych ('established, related'), co radykalnie zmniejsza obciążenie procesora routera.

Status portu 'filtered' w raporcie Nmap oznacza, że zapora sieciowa zablokowała pakiet sondy i nie odesłała żadnej odpowiedzi (pakiet został porzucony poleceniem DROP) lub odesłała komunikat błędu ICMP. Z punktu widzenia bezpieczeństwa zewnętrzny interfejs WAN powinien wykazywać stan 'filtered' dla wszystkich portów.

Poniżej pokazano przykładowe skanowanie routera przed wdrożeniem poprawek oraz wzorcowy zestaw reguł zapory w systemie MikroTik RouterOS:

W systemie Linux analogiczną konfigurację zapory stanowej realizuje się za pomocą poleceń iptables z modułem conntrack: 'iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT' oraz 'iptables -A INPUT -m conntrack --ctstate INVALID -j DROP', z domyślną polityką 'iptables -P INPUT DROP'.

W sprawozdaniu wyjaśnij różnicę pomiędzy działaniem reguły 'action=drop' (ciche odrzucenie pakietu) a 'action=reject' (odesłanie pakietu TCP RST lub komunikatu ICMP Port Unreachable). W interfejsach publicznych WAN zdecydowanie preferowana jest akcja 'drop'.

1. Wpływ braku podstawowych reguł filtrowania na routerze brzegowym na podatność sieci wewnętrznej na ataki z Internetu.
2. Znaczenie koncepcji zapory stanowej (Stateful Firewall) i mechanizmu śledzenia połączeń conntrack.
3. Zagrożenia wynikające z publicznego udostępniania paneli zarządzania routerem (WebFig, WinBox, SSH, Telnet).
4. Porównanie technik skanowania portów (SYN, FIN, Xmas, UDP) w diagnostyce zachowania zapory sieciowej.
5. Konieczność stosowania zasady domyślnego blokowania (Default Deny) na interfejsach zewnętrznych routera brzegowego.
6. Rekomendacje dotyczące bezpiecznego zdalnego zarządzania infrastrukturą spółdzielni poprzez szyfrowany tunel VPN zamiast otwartych portów WAN.

Przykładowe wnioski (wzór do sprawozdania): Ocena konfiguracji bramy brzegowej w spółdzielni mieszkaniowej wykazała krytyczny błąd architektoniczny polegający na otwarciu portów zarządzających (WinBox, SSH, WebFig) na interfejsie publicznym WAN. Brak restrykcyjnej domyślnej reguły blokującej (Default Drop) w łańcuchu Forward zapory sieciowej umożliwiał swobodne sondowanie wewnętrznych podsieci spółdzielni przez skanery internetowe. Zrekonfigurowanie zapory w oparciu o model 'blokuj wszystko, co nie jest jawnie dozwolone' oraz ograniczenie dostępu administracyjnego wyłącznie do lokalnej sieci zarządzającej natychmiast wyeliminowało zagrożenie. Zastosowanie mechanizmu śledzenia połączeń (Stateful Inspection) w RouterOS zapewniło prawidłową obsługę ruchu powrotnego dla uprawnionych użytkowników. Wyniki audytu dowodzą, że poprawna konstrukcja reguł zapory brzegowej stanowi najważniejszą linię obrony przed masowymi skanowaniami i atakami siłowymi z sieci globalnej.