Laboratorium 3

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, U2, U3, K1, K3.

Głównym celem zadania jest opanowanie elementarnej metodyki wdrażania bezpiecznego protokołu HTTPS w serwerze WWW Apache pracującym w środowisku Linux. Studenci poznają zasady generowania kluczy asymetrycznych RSA oraz tworzenia certyfikatów cyfrowych X.509 za pomocą bezpłatnego pakietu OpenSSL. Ćwiczenie uczy konfiguracji wirtualnego hosta nasłuchującego na porcie 443 oraz powiązania go z odpowiednimi plikami klucza i certyfikatu.

W ramach laboratorium zespół bada różnice pomiędzy jawnym ruchem HTTP a zaszyfrowanym kanałem TLS oraz analizuje przyczyny wyświetlania ostrzeżeń o certyfikacie samopodpisanym w przeglądarkach internetowych. Uczestnicy weryfikują wymogi prawne dotyczące ochrony danych medycznych zgodnie z art. 32 RODO i Krajowymi Ramami Interoperacyjności (KRI). Efektem końcowym jest bezpiecznie skonfigurowany serwis WWW oraz pisemne sprawozdanie techniczne opisujące przebieg migracji i wnioski z wdrożenia.

Niepubliczny Zakład Opieki Zdrowotnej „Zdrowie Rodziny” w Miechowie prowadzi lokalny serwis intranetowy dla personelu medycznego. Aplikacja webowa udostępnia harmonogramy dyżurów lekarzy, grafik gabinetów zabiegowych oraz wewnętrzny moduł rezerwacji wizyt domowych. Do tej pory witryna działała wyłącznie na nieszyfrowanym protokole HTTP (port 80 TCP) pod adresem intranetowym http://serwer.przychodnia.local.

W trakcie rutynowego przeglądu procedur bezpieczeństwa nowo powołany Inspektor Ochrony Danych (IOD) zwrócił uwagę, że personel loguje się do serwisu ze stacji roboczych podłączonych do tej samej sieci LAN, w której funkcjonują urządzenia pacjentów podłączone do otwartego punktu dostępowego. Każda osoba podłączona do sieci przychodni mogła przy użyciu prostego analizatora pakietów przechwycić formularze rejestracyjne zawierające numery PESEL i dane o stanie zdrowia pacjentów.

Kierownictwo przychodni podjęło decyzję o natychmiastowej migracji serwisu na protokół HTTPS. Z uwagi na brak zewnętrznej domeny publicznej oraz brak bezpośredniego dostępu serwera do sieci Internet, niemożliwe jest skorzystanie z bezpłatnych certyfikatów z automatycznym odnawianiem od publicznych urzędów certyfikacji. Zespół techniczny musi wygenerować lokalny certyfikat samopodpisany (self-signed) i bezpiecznie zaimplementować go w konfiguracji serwera Apache.

Studenci wcielają się w rolę konsultantów ds. cyberbezpieczeństwa realizujących to wdrożenie. Do dyspozycji zespołu jest serwer Linux z zainstalowanym serwerem Apache 2.4 oraz stacja robocza klienta z systemem Windows 11. Grupa musi przeprowadzić procedurę generowania klucza prywatnego RSA o długości minimum 2048 bitów, utworzyć certyfikat X.509 ważny przez 365 dni, skonfigurować wirtualnego hosta SSL i przeprowadzić weryfikację z poziomu stacji roboczej klienta.

Po zakończeniu prac technicznych zespół przygotowuje kompleksowe sprawozdanie opisujące przebieg prac, analizę wyświetlanego komunikatu ostrzegawczego o nieznanym urzędzie certyfikacji oraz wytyczne dla personelu placówki dotyczące bezpiecznego korzystania z wewnętrznego portalu medycznego.

1. Zalogowanie się na serwer Linux przez protokół SSH lub konsolę lokalną i weryfikacja uprawnień administracyjnych poleceniem 'sudo whoami'.
2. Weryfikacja obecności i wersji pakietu serwera WWW Apache za pomocą polecenia 'apache2 -v'.
3. Sprawdzenie aktualnie nasłuchujących portów sieciowych za pomocą narzędzia 'ss -tulpn | grep apache2' w celu potwierdzenia aktywności portu 80.
4. Włączenie modułu obsługi szyfrowania SSL w serwerze Apache za pomocą polecenia 'sudo a2enmod ssl'.
5. Utworzenie dedykowanego, zabezpieczonego katalogu na klucze i certyfikaty za pomocą polecenia 'sudo mkdir -p /etc/apache2/ssl'.
6. Ustawienie restrykcyjnych uprawnień dostępu do katalogu kluczy poleceniem 'sudo chmod 700 /etc/apache2/ssl'.
7. Wygenerowanie 2048-bitowego klucza prywatnego RSA oraz certyfikatu samopodpisanego X.509 za pomocą narzędzia OpenSSL: 'sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/przychodnia.key -out /etc/apache2/ssl/przychodnia.crt'.
8. Wprowadzenie metadanych certyfikatu: Country Name (PL), Organization Name (NZOZ Zdrowie Rodziny), Common Name (serwer.przychodnia.local).
9. Zabezpieczenie pliku klucza prywatnego poleceniem 'sudo chmod 600 /etc/apache2/ssl/przychodnia.key' w celu uniemożliwienia odczytu przez innych użytkowników systemu.
10. Weryfikacja poprawności wygenerowanego certyfikatu X.509 poleceniem 'openssl x509 -in /etc/apache2/ssl/przychodnia.crt -text -noout'.
11. Utworzenie pliku konfiguracyjnego wirtualnego hosta SSL w '/etc/apache2/sites-available/przychodnia-ssl.conf' z definicją VirtualHost na porcie 443.
12. Wskazanie w pliku konfiguracyjnym dyrektyw 'SSLEngine on', 'SSLCertificateFile' oraz 'SSLCertificateKeyFile' wskazujących na utworzone pliki.
13. Włączenie nowo utworzonej witryny SSL w konfiguracji Apache poleceniem 'sudo a2ensite przychodnia-ssl.conf'.
14. Weryfikacja składni plików konfiguracyjnych serwera za pomocą polecenia 'sudo apache2ctl configtest' i uzyskanie komunikatu 'Syntax OK'.
15. Przeładowanie usługi serwera WWW za pomocą polecenia 'sudo systemctl restart apache2'.
16. Weryfikacja czy Apache poprawnie nasłuchuje na porcie 443 TCP poleceniem 'ss -tulpn | grep 443'.
17. Na stacji roboczej klienta Windows dodanie wpisu w pliku 'C:\Windows\System32\drivers\etc\hosts' mapującego adres IP serwera na nazwę 'serwer.przychodnia.local'.
18. Przeprowadzenie testu połączenia z poziomu wiersza poleceń Windows za pomocą programu curl: 'curl -k -I https://serwer.przychodnia.local'.
19. Uruchomienie przeglądarki internetowej na stacji Windows, otwarcie adresu https://serwer.przychodnia.local oraz analiza szczegółów certyfikatu i ostrzeżenia 'NET::ERR_CERT_AUTHORITY_INVALID'.
20. Udokumentowanie wszystkich listingów konfiguracyjnych, zrzutów ekranu i wyników poleceń na potrzeby końcowego sprawozdania laboratoryjnego.

Generując certyfikat za pomocą OpenSSL, kluczowe znaczenie ma parametr Common Name (CN). Musi on ściśle odpowiadać nazwie domenowej lub adresowi IP wpisywanemu przez użytkownika w pasku adresu przeglądarki internetowej. W przypadku niezgodności przeglądarka zgłosi błąd dopasowania nazwy (Name Mismatch).

Opcja '-nodes' (no DES) nakazuje programowi OpenSSL wygenerowanie klucza prywatnego bez hasła szyfrującego (passphrase). W środowisku produkcyjnym serwera WWW brak hasła jest standardem, gdyż umożliwia automatyczny start usługi Apache po restarcie maszyny bez konieczności ręcznego wprowadzania hasła przez administratora w konsoli.

Poniżej przedstawiono przykładowy widok konsoli serwera Linux podczas generowania certyfikatu OpenSSL, konfiguracji modułu SSL oraz weryfikacji poprawności działania portu 443:

Podczas weryfikacji połączenia za pomocą narzędzia curl przełącznik '-k' (lub '--insecure') informuje program, aby zignorował fakt, że certyfikat jest samopodpisany i nie pochodzi od zaufanego urzędu certyfikacji. Pozwala to na pobranie nagłówków i treści strony bez przerywania połączenia z błędem SSL.

W sprawozdaniu wyjaśnij różnicę pomiędzy szyfrowaniem transmisji (zapewnianym przez klucz symetryczny wynegocjowany podczas TLS Handshake) a uwierzytelnieniem tożsamości serwera (zapewnianym przez łańcuch zaufania PKI i urząd CA). Certyfikat samopodpisany zapewnia pełną poufność danych, lecz nie gwarantuje autentyczności wystawcy.

1. Wykazanie wpływu wdrożenia protokołu HTTPS na eliminację podatności na pasywny podsłuch pakietów (sniffing) w sieci lokalnej przychodni.
2. Analiza prawna obowiązku stosowania szyfrowania danych osobowych i medycznych w świetle art. 32 RODO i przepisów KRI.
3. Wyjaśnienie przyczyn wyświetlania ostrzeżenia bezpieczeństwa w przeglądarce po zastosowaniu certyfikatu samopodpisanego (self-signed).
4. Porównanie właściwości ochronnych i kosztów utrzymania certyfikatu samopodpisanego z certyfikatami wystawianymi przez publiczne urzędy CA.
5. Wskazanie dobrych praktyk zarządzania uprawnieniami do pliku klucza prywatnego serwera w systemie Linux (chmod 600).
6. Rekomendacje dotyczące kolejnych kroków podnoszących bezpieczeństwo, w tym wymuszenia przekierowania z HTTP na HTTPS.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna migracja serwisu przychodni z protokołu HTTP na HTTPS udowodniła, że szyfrowanie kanału transmisji jest absolutnie niezbędne do ochrony prywatności pacjentów przeglądających grafik dyżurów i komunikaty medyczne. Wygenerowanie klucza prywatnego RSA oraz certyfikatu X.509 za pomocą narzędzia OpenSSL pozwoliło na poprawne skonfigurowanie wirtualnego hosta w serwerze Apache na porcie 443. Weryfikacja połączenia narzędziem cURL oraz przeglądarką potwierdziła skuteczne szyfrowanie danych algorytmami TLS 1.3, uniemożliwiając ich podsłuchanie w sieci lokalnej. Zrozumienie mechanizmu działania certyfikatów własnoręcznie podpisanych wyjaśniło przyczyny generowania ostrzeżeń o braku zaufania w aplikacjach klienckich bez zainstalowanego certyfikatu głównego CA. Wdrożenie szyfrowania HTTPS stanowi elementarny krok w spełnieniu wymagań rozporządzenia RODO oraz ustawy o Krajowym Systemie Cyberbezpieczeństwa.

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

Celem ćwiczenia jest opanowanie umiejętności konfiguracji bezpiecznego dostępu do interfejsu graficznego zarządzania urządzeniem sieciowym MikroTik RouterOS (WebFig). Studenci poznają wbudowane mechanizmy zarządzania usługami systemowymi (/ip service) oraz generator certyfikatów cyfrowych wbudowany w system RouterOS CLI. Ćwiczenie uczy bezpiecznego wdrażania usługi www-ssl na porcie 443 TCP.

W toku realizacji zadania zespół analizuje zagrożenia wynikające z przesyłania danych logowania administratora otwartym tekstem w protokole HTTP na porcie 80. Studenci konfigurują parametry certyfikatu cyfrowego, podpisują go lokalnie na routerze i przypisują do usługi WWW-SSL, a następnie trwale dezaktywują nieszyfrowaną usługę WWW. Efektem prac jest utwardzona brama sieciowa oraz sprawozdanie z procedury wdrożeniowej.

Regionalny Ośrodek Edukacji i Sportu w powiecie piaseczyńskim wykorzystuje router MikroTik RouterOS jako centralną bramę sieciową obsługującą pracownie szkolne, administrację oraz bezprzewodową sieć dla gości. Urządzenie zarządza routingiem, zaporą sieciową oraz serwerem DHCP dla ponad setki aktywnych użytkowników.

Podczas wewnętrznego audytu konfiguracji wykazano, że webowy interfejs zarządzania routerem (WebFig) pozostaje włączony na domyślnym porcie HTTP 80. Co gorsza, administratorzy logują się do panelu ze stacji roboczych podłączonych do tej samej podsieci, w której funkcjonują komputery uczniów. Uczeń dysponujący podstawowym analizatorem ruchu Wireshark może przechwycić poświadczenia konta 'admin' podczas logowania.

Dyrektor placówki nakazał natychmiastowe zabezpieczenie panelu WebFig. Wymagane jest wdrożenie szyfrowania TLS dla sesji administracyjnych oraz bezwzględne wyłączenie nieszyfrowanego protokołu HTTP, aby uniemożliwić przypadkowe lub celowe logowanie jawnym tekstem.

Zespół studentów podejmuje się realizacji tego zadania w środowisku laboratoryjnym. Uczestnicy łączą się z konsolą RouterOS przez port szeregowy, bezpieczny terminal SSH lub oprogramowanie WinBox. Następnie tworzą szablon certyfikatu cyfrowego o odpowiedniej długości klucza, podpisują go wewnętrznie w pamięci urządzenia i aktywują usługę www-ssl z powiązaniem do nowo utworzonego certyfikatu.

Końcowym etapem jest wykonanie testów sprawdzających z poziomu stacji Windows: próba połączenia na port 80 musi zakończyć się odrzuceniem, natomiast połączenie na port 443 musi skutkować bezpiecznym załadowaniem panelu WebFig z aktywnym szyfrowaniem sesji.

1. Zalogowanie się do konsoli MikroTik RouterOS przez bezpieczny protokół SSH lub konsolę terminala WinBox przy użyciu poświadczeń administratora.
2. Weryfikacja aktualnego stanu usług sieciowych routera poleceniem '/ip service print' i odnotowanie aktywnych portów (www na porcie 80, www-ssl na porcie 443 z flagą X oznaczającą wyłączenie).
3. Sprawdzenie zasobów procesora i pamięci RAM urządzenia poleceniem '/system resource print' przed rozpoczęciem generowania kluczy kryptograficznych.
4. Utworzenie nowego wpisu certyfikatu serwera dla usługi WebFig poleceniem '/certificate add name=webfig-cert common-name=192.168.88.1 days-valid=365 key-size=2048 key-usage=digital-signature,key-encipherment,tls-server'.
5. Weryfikacja poprawności dodania szablonu certyfikatu w rejestrze poleceniem '/certificate print detail'.
6. Lokalne podpisanie certyfikatu w systemie RouterOS za pomocą polecenia '/certificate sign webfig-cert'.
7. Zatwierdzenie procesu podpisywania (potwierdzenie klawiszem Enter) i odczekanie kilku sekund na wygenerowanie 2048-bitowej pary kluczy RSA.
8. Sprawdzenie flag certyfikatu poleceniem '/certificate print' i upewnienie się, że certyfikat uzyskał flagę 'K' (certyfikat posiada wygenerowany klucz prywatny) oraz 'T' (zaufany).
9. Przypisanie wygenerowanego certyfikatu do usługi WWW-SSL oraz jej aktywacja poleceniem '/ip service set www-ssl certificate=webfig-cert disabled=no port=443'.
10. Weryfikacja czy usługa www-ssl jest poprawnie uruchomiona poleceniem '/ip service print where name=www-ssl'.
11. Deaktywacja podatnej, nieszyfrowanej usługi www poleceniem '/ip service set www disabled=yes'.
12. Upewnienie się poleceniem '/ip service print', że usługa www na porcie 80 posiada flagę 'X' (wyłączona).
13. Ze stacji roboczej klienta Windows uruchomienie wiersza poleceń i weryfikacja dostępności portu 80 poleceniem 'Test-NetConnection -ComputerName 192.168.88.1 -Port 80' (oczekiwany wynik: TcpTestSucceeded: False).
14. Weryfikacja dostępności portu 443 poleceniem 'Test-NetConnection -ComputerName 192.168.88.1 -Port 443' (oczekiwany wynik: TcpTestSucceeded: True).
15. Uruchomienie przeglądarki internetowej na stacji Windows i wpisanie adresu 'http://192.168.88.1' w celu upewnienia się, że połączenie niezaszyfrowane nie jest możliwe.
16. Otwarcie w przeglądarce adresu 'https://192.168.88.1', zaakceptowanie monitu o certyfikacie samopodpisanym i zalogowanie się do panelu WebFig.
17. Sprawdzenie w przeglądarce właściwości zabezpieczeń sesji: używany protokół (TLS 1.2 lub TLS 1.3) oraz algorytm szyfrowania danych.
18. Wyeksportowanie certyfikatu publicznego z poziomu RouterOS poleceniem '/certificate export-certificate webfig-cert' w celu zbadania jego struktury.
19. Sporządzenie tabelarycznego zestawienia zmian w konfiguracji usług sieciowych urządzenia RouterOS przed i po utwardzeniu.
20. Sformułowanie wniosków technicznych dotyczących zarządzania urządzeniami brzegowymi w publicznych placówkach oświatowych.

W systemie MikroTik RouterOS generowanie certyfikatu odbywa się dwuetapowo: najpierw poleceniem '/certificate add' tworzy się definicję (rekord z parametrami), a dopiero polecenie '/certificate sign' uruchamia procedurę obliczeniową generującą klucz prywatny i podpisującą certyfikat.

Parametr 'key-usage' ma fundamentalne znaczenie dla poprawności negocjacji TLS. Dla serwera WWW certyfikat musi koniecznie zawierać flagi 'digital-signature', 'key-encipherment' oraz 'tls-server'. Brak flagi 'tls-server' może skutkować odrzuceniem certyfikatu przez nowoczesne przeglądarki internetowe.

Poniżej przedstawiono listing sesji w konsoli RouterOS obrazujący procedurę tworzenia certyfikatu, przypisania go do usługi www-ssl oraz wyłączenia portu 80:

Jeżeli po wdrożeniu certyfikatu i wyłączeniu portu 80 użytkownik wpisze w przeglądarce '192.168.88.1' bez przedrostka 'https://', przeglądarka domyślnie spróbuje połączyć się na port 80 i wyświetli błąd braku odpowiedzi. Należy poinstruować pracowników o konieczności wpisywania pełnego adresu 'https://192.168.88.1'.

W systemach o ograniczonej wydajności procesora (np. starsze modele RouterBOARD) generowanie klucza RSA o długości 4096 bitów może zająć nawet kilkadziesiąt sekund i obciążyć procesor w 100%. Klucz 2048-bitowy zapewnia idealny kompromis pomiędzy bezpieczeństwem a wydajnością sprzętową.

1. Zrozumienie ryzyka przechwycenia poświadczeń administracyjnych urządzenia sieciowego podczas transmisji HTTP w sieci lokalnej.
2. Ocena przydatności wbudowanego mechanizmu zarządzania certyfikatami w RouterOS w porównaniu z zewnętrznymi narzędziami PKI.
3. Wpływ flag atrybutów klucza (key-usage) na poprawność negocjacji sesji TLS w nowoczesnych przeglądarkach.
4. Znaczenie bezwzględnej dezaktywacji niepotrzebnych lub podatnych usług sieciowych (/ip service) w polityce utwardzania routera.
5. Praktyczne aspekty weryfikacji dostępności portów za pomocą poleceń systemowych PowerShell (Test-NetConnection).
6. Wytyczne dotyczące bezpiecznego zarządzania infrastrukturą sieciową w placówkach sektora finansów publicznych.

Przykładowe wnioski (wzór do sprawozdania): Wykorzystanie protokołu www-ssl do zarządzania routerem brzegowym wyeliminowało krytyczną podatność polegającą na przesyłaniu haseł administracyjnych czystym tekstem przez sieć IP. Samodzielne wygenerowanie certyfikatu w konsoli MikroTik RouterOS umożliwiło szybkie powiązanie klucza kryptograficznego z usługą interfejsu webowego WebFig. Bezwzględne wyłączenie nieszyfrowanej usługi WWW na porcie 80 zapobiega przypadkowemu logowaniu się administratora przez niezabezpieczony kanał HTTP. Weryfikacja stanu usług poleceniem '/ip service print' potwierdziła, że ruch konfiguracyjny jest w całości hermetyzowany w tunelu TLS. Ćwiczenie dowodzi, że zabezpieczenie interfejsów zarządzających sprzętem sieciowym powinno być pierwszym i priorytetowym zadaniem administratora podczas wdrażania nowego routera.

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.

Celem zadania jest praktyczna demonstracja podatności nieszyfrowanego protokołu HTTP na podsłuch transmisji w sieci lokalnej (ang. sniffing) oraz uświadomienie studentom krytycznej roli szyfrowania TLS. Studenci wcielają się w rolę audytorów badających przepływ pakietów pomiędzy stacją pracownika a serwerem aplikacji księgowej za pomocą programu Wireshark.

W trakcie ćwiczenia zespół analizuje strukturę żądań HTTP POST zawierających poświadczenia użytkowników, identyfikuje przesyłane w otwartym tekście hasła oraz porównuje ten stan z ruchem przechwyconym po uruchomieniu szyfrowania HTTPS. Zadanie uczy krytycznego myślenia o bezpieczeństwie sieciowym oraz wskazuje mechanizmy obronne w postaci enkapsulacji danych w protokole TLS. Wynikiem prac jest raport audytorski dokumentujący skalę zagrożenia.

Biuro Rachunkowe „Fiskus-Ekspert” w Nowym Sączu świadczy usługi księgowe i kadrowo-płacowe dla kilkudziesięciu lokalnych przedsiębiorstw. W biurze wdrożono webową aplikację do wprowadzania faktur VAT i deklaracji ZUS, zainstalowaną na lokalnym serwerze Linux. Pracownicy logują się do systemu przez przeglądarkę internetową, podając unikalne identyfikatory i hasła dostępowe.

Podczas podłączania nowego urządzenia wielofunkcyjnego w dziale księgowości zauważono, że na jednym z komputerów uruchomiono bez wiedzy zarządu darmowy program do monitorowania sieci. Właściciel biura zaniepokoił się, czy w obecnej konfiguracji sieciowej osoba podłączona do gniazda ściennego w sali obsługi klienta mogłaby przechwycić poufne dane klientów lub hasła logowania personelu.

Zarząd biura zlecił zespołowi studentów przeprowadzenie kontrolowanego eksperymentu audytorskiego. Zadanie polega na przechwyceniu ruchu sieciowego generowanego podczas procesu logowania księgowej do panelu webowego działającego na protokole HTTP (port 80) oraz podjęciu próby odczytania loginu i hasła z przechwyconych pakietów.

W drugim etapie eksperymentu zespół uruchamia na serwerze szyfrowaną wersję serwisu (HTTPS/TLS na porcie 443) i powtarza operację przechwytywania ruchu. Studenci muszą przeanalizować zawartość pakietów TLS i udowodnić, że dane uwierzytelniające zostały przekształcone w nieczytelny kryptogram, uniemożliwiający odczyt poświadczeń przez niepowołanego obserwatora.

Na podstawie zebranych dowodów audytorzy sporządzają sprawozdanie, w którym w przystępny sposób wyjaśniają właścicielowi biura mechanizm działania podsłuchu sieciowego oraz formułują bezwzględną rekomendację wycofania protokołu HTTP ze wszystkich wewnętrznych systemów przetwarzających dane finansowe i osobowe.

1. Przygotowanie środowiska testowego: serwer Linux z aplikacją webową oraz stacja robocza klienta Windows połączone przez wspólną sieć wirtualną.
2. Uruchomienie na stacji klienta analizatora ruchu sieciowego Wireshark z uprawnieniami administratora.
3. Wybór aktywnej karty sieciowej i rozpoczęcie przechwytywania pakietów w trybie nasłuchiwania.
4. Ustawienie filtru wyświetlania w Wireshark na 'http' w celu odseparowania ruchu aplikacji webowej od innych pakietów sieciowych.
5. Otwarcie w przeglądarce internetowej nieszyfrowanej strony logowania aplikacji pod adresem http://192.168.1.100/login.php.
6. Wprowadzenie w formularzu testowych danych uwierzytelniających (użytkownik: 'ksiegowa_anna', hasło: 'Fiskus2026!Sekret') i wysłanie formularza.
7. Zatrzymanie przechwytywania pakietów w programie Wireshark.
8. Zlokalizowanie w oknie Wireshark pakietu z metodą żądania 'POST /login.php HTTP/1.1'.
9. Rozwinięcie w dolnym panelu szczegółów pakietu sekcji 'HTML Form URL Encoded' lub 'Line-based text data'.
10. Zidentyfikowanie i zarejestrowanie widocznych w otwartym tekście parametrów: 'username=ksiegowa_anna' oraz 'password=Fiskus2026!Sekret'.
11. Skorzystanie z funkcji 'Follow -> HTTP Stream' w celu podejrzenia pełnej konwersacji klient-serwer w formacie tekstowym.
12. Zapisanie zrzutu ekranu jako dowodu podatności nieszyfrowanej transmisji HTTP na sniffing.
13. Przełączenie aplikacji webowej na bezpieczny wariant HTTPS pod adresem https://192.168.1.100/login.php.
14. Ponowne uruchomienie przechwytywania pakietów w Wireshark z filtrem ustawionym na 'tls || tcp.port == 443'.
15. Ponowne wprowadzenie danych logowania w przeglądarce w bezpiecznym formularzu HTTPS i zatwierdzenie logowania.
16. Zatrzymanie przechwytywania w Wireshark i odnalezienie pakietu 'Application Data' protokołu TLS.
17. Próba odczytania zawartości pakietu 'Application Data' i weryfikacja, że ładunek danych (payload) jest w pełni zaszyfrowany i nieczytelny.
18. Porównanie nagłówków pakietu HTTP z pakietem TLS (widoczność parametrów warstwy transportowej vs ochrona warstwy aplikacji).
19. Opracowanie tabelarycznego porównania bezpieczeństwa obu protokołów pod kątem poufności, integralności i autentyczności.
20. Przygotowanie wniosków audytorskich ze szczególnym uwzględnieniem odpowiedzialności prawnej biura rachunkowego za brak zabezpieczeń.

W programie Wireshark protokół HTTP jest domyślnie parsowany do poziomu zrozumiałego dla człowieka tekstu ASCII. Jeżeli formularz logowania przesyła dane za pomocą metody POST, parametry te znajdują się bezpośrednio w ciele żądania (ang. request body) w formacie 'application/x-www-form-urlencoded'.

W przypadku protokołu TLS 1.2 lub TLS 1.3 dane aplikacji są szyfrowane symetrycznym algorytmem blokowym (np. AES-GCM lub ChaCha20-Poly1305). W Wiresharku widać jedynie nagłówki warstwy TLS (Record Layer) informujące o typie rekordu (np. Application Data, Content Type: 23), natomiast cała zawartość użytkowa ma postać losowo wyglądających bajtów.

Poniżej przedstawiono fragment przechwyconego strumienia HTTP w analizatorze Wireshark, ujawniający jawny transfer poświadczeń księgowej, w zestawieniu z zapisem szyfrowanym TLS:

Wyjaśnij w sprawozdaniu, dlaczego powszechne kodowanie poświadczeń za pomocą algorytmu Base64 (stosowane np. w mechanizmie HTTP Basic Authentication) nie stanowi szyfrowania. Base64 jest wyłącznie publicznym formatem kodowania danych binarnych na tekst i każdy analizator pakietów dekoduje go natychmiastowo.

W środowisku laboratoryjnym podsłuch prowadzony jest na maszynie klienta lub na wirtualnym przełączniku w trybie promiscuous. W rzeczywistej sieci LAN opartej na przełącznikach (switchach) pakiety są izolowane pomiędzy portami, jednak atakujący może przełamać tę izolację za pomocą ataku ARP Spoofing (omówionego na wykładzie 1).

1. Praktyczny dowód na to, że przesyłanie formularzy logowania protokołem HTTP całkowicie pozbawia system poufności.
2. Zrozumienie fundamentalnej różnicy pomiędzy kodowaniem tekstu (Base64, URL-encode) a szyfrowaniem kryptograficznym (AES, TLS).
3. Ocena ryzyka naruszenia tajemnicy zawodowej księgowego i wycieku danych finansowych w kontekście art. 267 Kodeksu karnego.
4. Analiza skuteczności szyfrowania TLS w uniemożliwieniu analizy treści przez osoby trzecie monitorujące ruch w sieci.
5. Konieczność stosowania zasady wymuszonego szyfrowania dla całego serwisu, a nie tylko dla samego skryptu logowania.
6. Rekomendacje dotyczące wdrożenia mechanizmów ochrony warstwy łącza danych (np. DHCP Snooping, Dynamic ARP Inspection) na przełącznikach.

Przykładowe wnioski (wzór do sprawozdania): Eksperyment laboratoryjny z przechwytywaniem pakietów protokołu HTTP dobitnie zobrazował łatwość, z jaką intruz w sieci lokalnej może przejąć poświadczenia logowania pracowników biura rachunkowego. Narzędzia tcpdump oraz Wireshark bez trudu wyekstrahowały jawne wartości pól formularza uwierzytelniającego, dowodząc całkowitej bezużyteczności zabezpieczeń aplikacji bez warstwy TLS. Zastosowanie szyfrowania HTTPS zamienia treść żądań POST w nieczytelny strumień bajtów kryptograficznych, chroniąc hasła nawet w przypadku pełnego podsłuchu medium transmisyjnego. Wykazano, że bezpieczeństwo aplikacji webowej jest nierozłącznie powiązane z bezpieczeństwem protokołu transportowego, na którym jest ona osadzona. Ostatecznym wnioskiem jest bezwzględny zakaz eksploatacji jakichkolwiek formularzy uwierzytelniających w środowiskach bez aktywnego i zweryfikowanego certyfikatu SSL/TLS.

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

Celem ćwiczenia jest opanowanie technik automatycznego wymuszania bezpiecznego protokołu HTTPS w serwerze Apache za pomocą mechanizmu reguł przepisywania adresów URL (mod_rewrite) lub dyrektyw przekierowań Redirect. Studenci uczą się eliminować ryzyko przypadkowego przesłania wrażliwych danych przez użytkowników wpisujących adres serwisu z prefiksem http://.

W ramach laboratorium zespół bada kody odpowiedzi HTTP (ze szczególnym uwzględnieniem statusu 301 Moved Permanently), analizuje nagłówki odpowiedzi serwera w programie curl oraz bada zachowanie przeglądarek internetowych podczas automatycznego przejścia na szyfrowany port 443. Studenci weryfikują poprawność działania formularza zapytania ofertowego po przekierowaniu. Zadanie kończy się przygotowaniem dokumentacji wdrożeniowej.

Przedsiębiorstwo Spedycyjno-Logistyczne „Trans-Polska” w Dąbrowie Górniczej wdrożyło na swoim serwerze Apache certyfikat SSL dla oficjalnej witryny firmowej. Na stronie znajduje się formularz wyceny frachtu, w którym klienci podają dane kontaktowe, numery NIP, adresy magazynów oraz deklarowane wartości przewożonych ładunków.

Choć serwer poprawnie obsługuje szyfrowane połączenia pod adresem https://trans-polska.local, w logach serwera zauważono, że ponad 70% klientów nadal wchodzi na stronę, wpisując po prostu 'trans-polska.local' w pasku adresu przeglądarki. W konsekwencji przeglądarki domyślnie nawiązują nieszyfrowane połączenie HTTP na porcie 80, a dane z formularza są wysyłane jawnym tekstem, chyba że klient samodzielnie dopisze literę 's' w adresie.

Dyrektor ds. bezpieczeństwa uznał tę sytuację za niedopuszczalną i polecił administratorom wdrożenie bezwzględnego, automatycznego przekierowania każdego żądania HTTP na odpowiadający mu adres HTTPS ze statusem trwałego przeniesienia (kod 301).

Zespół studentów ma za zadanie skonfigurować serwer Apache w taki sposób, aby żadne żądanie na porcie 80 nie było obsługiwane nieszyfrowanym kanałem. Studenci aktywują moduł mod_rewrite, tworzą odpowiednią konfigurację w pliku wirtualnego hosta HTTP i weryfikują za pomocą narzędzia curl, czy serwer prawidłowo odsyła nagłówek 'Location' kierujący na wersję HTTPS z zachowaniem pełnej ścieżki i parametrów żądania.

Podsumowaniem zadania jest analiza różnicy pomiędzy przekierowaniem tymczasowym (kod 302/307) a trwałym (kod 301/308) pod kątem bezpieczeństwa, pamięci podręcznej przeglądarki oraz optymalizacji indeksowania przez wyszukiwarki.

1. Zalogowanie się na serwer Linux z serwerem Apache i weryfikacja czy moduł rewrite jest aktywny poleceniem 'sudo a2enmod rewrite'.
2. Otwarcie do edycji pliku konfiguracji domyślnego wirtualnego hosta HTTP w '/etc/apache2/sites-available/000-default.conf'.
3. Przeanalizowanie domyślnej sekcji '' i odnotowanie ścieżki DocumentRoot.
4. Wprowadzenie w sekcji portu 80 reguły przekierowania za pomocą dyrektywy 'Redirect permanent / https://trans-polska.local/' lub reguł RewriteEngine.
5. Alternatywne skonfigurowanie zaawansowanego przekierowania zachowującego ścieżkę URI: 'RewriteEngine On', 'RewriteCond %{HTTPS} off', 'RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]'.
6. Zapisanie zmian w pliku konfiguracyjnym i weryfikacja poprawności składni poleceniem 'sudo apache2ctl configtest'.
7. Przeładowanie konfiguracji serwera Apache poleceniem 'sudo systemctl reload apache2'.
8. Weryfikacja zachowania serwera za pomocą narzędzia curl na maszynie Linux: 'curl -I http://trans-polska.local'.
9. Zbadanie otrzymanego nagłówka odpowiedzi: potwierdzenie kodu statusu 'HTTP/1.1 301 Moved Permanently'.
10. Sprawdzenie obecności i poprawności nagłówka 'Location: https://trans-polska.local/'.
11. Wykonanie testu przekierowania z automatycznym śledzeniem lokalizacji za pomocą polecenia 'curl -L -k -I http://trans-polska.local'.
12. Zbadanie łańcucha odpowiedzi w curl (krok 1: odpowiedź 301 z portu 80, krok 2: odpowiedź 200 OK z portu 443).
13. Przetestowanie przekierowania podrzędnego adresu URL (np. 'http://trans-polska.local/kontakt/formularz.html') i upewnienie się, że ścieżka została zachowana na https.
14. Na stacji roboczej klienta Windows otwarcie przeglądarki internetowej i uruchomienie narzędzi deweloperskich (klawisz F12, zakładka Sieć / Network).
15. Wpisanie w pasku adresu 'http://trans-polska.local' i naciśnięcie Enter.
16. Zarejestrowanie w zakładce Sieć pierwszego żądania HTTP ze statusem 301 oraz natychmiastowego żądania HTTPS ze statusem 200.
17. Wypełnienie formularza kontaktowego w przeglądarce i weryfikacja, czy dane zostały przesłane wyłącznie w sesji TLS (zielona kłódka).
18. Przeanalizowanie zachowania pamięci podręcznej przeglądarki wobec przekierowania 301 (trwałe zapamiętanie adresu przez klienta).
19. Sporządzenie raportu zawierającego listingi konfiguracji, schemat przepływu żądań oraz zrzuty ekranu z konsoli curl i narzędzi deweloperskich.
20. Sformułowanie zaleceń dotyczących kolejnego etapu zabezpieczeń w postaci nagłówka HSTS (HTTP Strict Transport Security).

Dyrektywa 'Redirect permanent / https://domena/' jest najprostszą i najbardziej wydajną metodą przekierowania w serwerze Apache. Działa ona szybciej niż moduł mod_rewrite, ponieważ nie wymaga uruchamiania silnika wyrażeń regularnych dla każdego przychodzącego pakietu.

Zastosowanie kodu odpowiedzi HTTP 301 (Moved Permanently) informuje przeglądarkę, że zmiana adresu ma charakter stały. Nowoczesne przeglądarki zapamiętują tę informację w lokalnej pamięci podręcznej i przy kolejnych wizytach użytkownika automatycznie zamieniają 'http://' na 'https://' jeszcze przed wysłaniem pierwszego zapytania do sieci.

Poniżej przedstawiono przykładowy wynik testu przekierowania za pomocą narzędzia curl, pokazujący kod 301 oraz nagłówek 'Location':

W narzędziu curl przełącznik '-I' (duża litera i) wymusza wysłanie metody HTTP HEAD zamiast GET, co powoduje pobranie wyłącznie nagłówków odpowiedzi serwera bez ściągania zawartości strony. Jest to idealna metoda do szybkiej weryfikacji kodów przekierowań i nagłówków bezpieczeństwa.

Pamiętaj, że przekierowanie HTTP -> HTTPS chroni użytkownika dopiero od momentu odebrania odpowiedzi 301. Samo pierwsze żądanie na porcie 80 nadal wędruje przez sieć w postaci jawnej. Aby wyeliminować nawet to pierwsze nieszyfrowane zapytanie, w kolejnych etapach wdraża się nagłówek HSTS (ćwiczenie 05).

1. Wykazanie, jak automatyczne przekierowanie eliminuje czynnik błędu ludzkiego przy wpisywaniu adresów internetowych.
2. Zrozumienie semantyki kodów odpowiedzi HTTP (różnica pomiędzy kodem 301 Trwałym a kodem 302 Tymczasowym).
3. Wpływ buforowania odpowiedzi 301 w przeglądarkach internetowych na redukcję zbędnego ruchu sieciowego.
4. Potwierdzenie zachowania pełnej ścieżki URI (ścieżka i parametry GET) podczas migracji zapytania na port 443.
5. Identyfikacja ograniczeń samego przekierowania 301 (podatność pierwszego zapytania na atak sslstrip w sieci lokalnej).
6. Uzasadnienie konieczności stosowania przekierowania w kontekście ochrony danych przesyłanych w formularzach kontaktowych.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie trwałego przekierowania HTTP na HTTPS (kod odpowiedzi 301 Moved Permanently) stanowi kluczowy mechanizm chroniący użytkowników przed przypadkowym wysłaniem danych przez niezabezpieczony kanał. Konfiguracja dyrektywy Redirect w wirtualnym hoście Apache gwarantuje, że każde zapytanie skierowane na port 80 zostaje natychmiast i bezbłędnie skierowane na bezpieczny port 443. Zastosowanie narzędzia cURL z flagą nagłówkową pozwoliło na precyzyjną weryfikację poprawności kodu statusu HTTP oraz adresu docelowego w nagłówku Location. Mechanizm ten zapobiega błędom ludzkim wynikającym z wpisywania w przeglądarce samego adresu domeny bez prefiksu https://. Prawidłowo zrealizowane przekierowanie 301 nie tylko podnosi bezpieczeństwo przesyłanych formularzy zapytań ofertowych, ale także pozytywnie wpływa na pozycjonowanie serwisu i zaufanie kontrahentów firmy logistycznej.

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

Głównym celem zadania jest zapoznanie studentów z mechanizmem ochronnych nagłówków odpowiedzi HTTP (Security Headers) stosowanych do wzmocnienia odporności aplikacji webowych na powszechne ataki klienckie. Studenci uczą się aktywować moduł mod_headers w serwerze Apache oraz definiować reguły wstrzykiwania nagłówków do odpowiedzi serwera.

W toku ćwiczenia zespół konfiguruje kluczowe nagłówki ochronne: HTTP Strict Transport Security (HSTS), X-Frame-Options, X-Content-Type-Options oraz Referrer-Policy. Studenci badają odporność serwisu na ataki typu Clickjacking, wymuszone obniżenie wersji protokołu (SSL Stripping) oraz podsłuch nagłówków odsyłających. Prace wieńczy weryfikacja nagłówków w narzędziu curl oraz w publicznych analizatorach bezpieczeństwa.

Sklep internetowy „Eko-Styl” z siedzibą w Rzeszowie prowadzi sprzedaż odzieży ekologicznej i kosmetyków naturalnych. Platforma przetwarza dane osobowe klientów, adresy dostaw oraz integruje się z bramkami płatności online. Mimo wdrożenia certyfikatu SSL/TLS, audytor zewnętrzny wykazał, że aplikacja jest podatna na ataki socjotechniczne z powodu braku podstawowych nagłówków ochronnych w konfiguracji serwera WWW.

W szczególności stwierdzono, że witrynę sklepu można bez przeszkód osadzić wewnątrz niewidocznej ramki '.

Słowo kluczowe 'always' w dyrektywie 'Header always set' jest kluczowe dla bezpieczeństwa. Zapewnia ono, że nagłówek zostanie dołączony do odpowiedzi serwera niezależnie od kodu statusu HTTP, a więc także w przypadku błędów aplikacji (kody 4xx i 5xx) czy przekierowań (kody 3xx). Brak tego słowa mógłby spowodować pominięcie nagłówka przy błędach.

Nagłówek HTTP Strict Transport Security (HSTS) informuje przeglądarkę, że witryna może być odwiedzana wyłącznie za pośrednictwem protokołu HTTPS przez czas określony parametrem 'max-age' (wartość w sekundach, np. 31536000 oznacza 365 dni). Po odebraniu tego nagłówka przeglądarka automatycznie przepisuje każde odwołanie http:// na https:// wewnątrz swojego mechanizmu sieciowego.

Poniżej przedstawiono przykładowy listing nagłówków odpowiedzi serwera pobranych za pomocą polecenia curl po poprawnym skonfigurowaniu modułu mod_headers:

W środowisku produkcyjnym, po gruntownym przetestowaniu stabilności protokołu HTTPS na wszystkich poddomenach, domenę można zgłosić do globalnej listy HSTS Preload (prowadzonej przez Google i wbudowywanej w silniki przeglądarek Chrome, Firefox, Edge, Safari). Wówczas przeglądarka nigdy nie wyśle nawet pierwszego żądania HTTP.

Nagłówek X-Content-Type-Options z wartością 'nosniff' chroni użytkowników przed atakami polegającymi na podszywaniu się pod pliki graficzne przez złośliwe skrypty JavaScript (tzw. MIME Confusion Attack). Zmusza on przeglądarkę do ścisłego respektowania deklarowanego nagłówka Content-Type.

1. Zrozumienie roli nagłówków HTTP jako pierwszej linii obrony po stronie przeglądarki użytkownika.
2. Ocena skuteczności nagłówka X-Frame-Options w całkowitej eliminacji zagrożenia atakiem typu Clickjacking.
3. Analiza mechanizmu działania nagłówka HSTS i jego wpływu na uniemożliwienie ataków obniżenia wersji protokołu (SSL Stripping).
4. Znaczenie parametru 'always' w dyrektywach konfiguracyjnych serwera Apache dla zagwarantowania spójności polityki bezpieczeństwa.
5. Praktyczna weryfikacja blokady zasobów w narzędziach deweloperskich przeglądarek internetowych.
6. Rekomendacje dotyczące rozbudowy konfiguracji o zaawansowaną politykę Content Security Policy (CSP) w kolejnych etapach rozwoju serwisu.

Przykładowe wnioski (wzór do sprawozdania): Implementacja nagłówków bezpieczeństwa HTTP w serwerze Apache wykazała, że skuteczna ochrona serwisu WWW wykracza poza samo włączenie certyfikatu SSL/TLS. Wdrożenie nagłówka HSTS (Strict-Transport-Security) skutecznie uniemożliwia ataki typu SSL Stripping, wymuszając na przeglądarkach klientów wyłącznie szyfrowaną komunikację przez zdefiniowany czas. Zastosowanie nagłówka X-Frame-Options z wartością DENY lub SAMEORIGIN trwale eliminuje podatność platformy e-commerce na ataki typu Clickjacking w ramkach iframe. Dodanie reguły X-Content-Type-Options 'nosniff' zapobiega niebezpiecznemu zgadywaniu typów MIME plików przez przeglądarkę, ograniczając skutki złośliwych załączników. Audyt konfiguracji za pomocą serwisów analizujących nagłówki potwierdził skokowy wzrost cyberodporności aplikacji przy zerowym narzucie na wydajność serwera.

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

Celem ćwiczenia jest nabycie praktycznych umiejętności ograniczania ekspozycji sieciowej interfejsu administracyjnego routera brzegowego MikroTik RouterOS. Studenci poznają dwupoziomowy model zabezpieczeń oparty na restrykcjach adresowych samej usługi (/ip service) oraz regułach filtrowania pakietów w zaporze ogniowej (/ip firewall filter).

W ramach zadania zespół konfiguruje dedykowaną listę zaufanych adresów IP, z których dopuszczone jest logowanie do panelu www-ssl, oraz wdraża regułę bezwzględnego odrzucania pakietów kierowanych do portu zarządzania z innych podsieci i interfejsu WAN. Studenci testują skuteczność blokady z poziomu stacji roboczych o różnych adresach IP. Efektem jest utwardzona brama urzędowa oraz profesjonalna dokumentacja reguł dostępu.

Urząd Gminy w Zabierzowie zarządza siecią teleinformatyczną łączącą referaty urzędu, kasę, punkt obsługi mieszkańców oraz publiczną sieć Wi-Fi w sali obsługi klienta. Głównym urządzeniem zarządzającym ruchem jest router MikroTik RouterOS zainstalowany w serwerowni urzędu.

W trakcie audytu zgodności z Krajowymi Ramami Interoperacyjności (KRI) audytor zwrócił uwagę, że panel zarządzania WebFig (nawet po włączeniu szyfrowania www-ssl) odpowiada na zapytania z każdego adresu IP w sieci lokalnej, w tym z podsieci przeznaczonej dla interesantów urzędu. Oznacza to, że każda osoba odwiedzająca urząd może wyświetlić ekran logowania do głównego routera gminy i podjąć próby zgadywania hasła.

Zgodnie z zaleceniami KRI oraz normą ISO/IEC 27001, interfejsy zarządzania infrastrukturą krytyczną muszą być odizolowane i dostępne wyłącznie z dedykowanej stacji administratora lub wyodrębnionej podsieci zarządzającej (Management VLAN). Urząd zlecił wdrożenie restrykcyjnych polityk dostępu.

Zespół studentów podejmuje się realizacji zadania w środowisku laboratoryjnym. Grupa ma za zadanie ograniczyć dostęp do usługi www-ssl wyłącznie do jednego zaufanego adresu IP (stacja administratora: 192.168.88.50) za pomocą parametru 'address' w menu '/ip service'. Następnie studenci wzmacniają ochronę, tworząc regułę w zaporze sieciowej MikroTik w łańcuchu 'input', która cicho odrzuca (drop) wszelkie próby skanowania portu 443 z innych adresów.

W końcowym etapie zespół przeprowadza weryfikację: ze stacji administratora panel WebFig musi otwierać się bez przeszkód, natomiast próba nawiązania połączenia ze stacji o innym adresie IP (symulującej komputer interesanta) musi zakończyć się przekroczeniem czasu oczekiwania (timeout), nie ujawniając nawet obecności usługi.

1. Zalogowanie się do routera MikroTik RouterOS z poziomu konsoli WinBox lub bezpiecznego połączenia SSH.
2. Weryfikacja aktualnej konfiguracji usługi www-ssl poleceniem '/ip service print where name=www-ssl'.
3. Odnotowanie, że pole 'ADDRESS' jest puste, co oznacza akceptowanie połączeń z dowolnego adresu IP na świecie.
4. Identyfikacja adresu IP stacji roboczej administratora w podsieci LAN (np. 192.168.88.50/24).
5. Ograniczenie dostępu do usługi www-ssl wyłącznie do wybranego adresu stacji administratora poleceniem: '/ip service set www-ssl address=192.168.88.50/32'.
6. Weryfikacja wprowadzonego ograniczenia poleceniem '/ip service print' i sprawdzenie wpisu w kolumnie ADDRESS.
7. Przetestowanie logowania do panelu WebFig w przeglądarce ze stacji administratora (192.168.88.50) i upewnienie się, że dostęp jest poprawny.
8. Zmiana adresu IP stacji roboczej (lub użycie drugiej maszyny wirtualnej) na adres 192.168.88.99 symulujący stację nieautoryzowaną.
9. Próba otwarcia panelu 'https://192.168.88.1' z nieautoryzowanego adresu i zarejestrowanie komunikatu błędu przeglądarki (brak odpowiedzi serwera).
10. Powrót do stacji administratora i wdrożenie drugiego poziomu ochrony w zaporze sieciowej RouterOS.
11. Utworzenie dedykowanej listy adresowej dla uprawnionych stacji zarządzających: '/ip firewall address-list add list=admin-hosts address=192.168.88.50 comment="Stacja Glownego Administratora"'.
12. Dodanie reguły zezwalającej na ruch do portu 443 dla zaufanych hostów: '/ip firewall filter add chain=input protocol=tcp dst-port=443 src-address-list=admin-hosts action=accept place-before=0 comment="Zezwol na WebFig tylko z listy admin-hosts"'.
13. Dodanie reguły blokującej wszelkie pozostałe próby połączeń do portu 443: '/ip firewall filter add chain=input protocol=tcp dst-port=443 action=drop comment="Blokuj WebFig z pozostalych hostow"'.
14. Weryfikacja kolejności reguł w zaporze sieciowej za pomocą polecenia '/ip firewall filter print'.
15. Przeprowadzenie skanowania portu 443 z nieautoryzowanej stacji za pomocą narzędzia Nmap: 'nmap -p 443 192.168.88.1'.
16. Odnotowanie stanu portu w wyniku skanowania Nmap (oczekiwany stan: 'filtered' zamiast 'closed' lub 'open').
17. Obserwacja liczników pakietów i bajtów w regułach zapory sieciowej poleceniem '/ip firewall filter print stats'.
18. Udokumentowanie wyników działania zapory oraz różnicy pomiędzy akcją 'drop' a 'reject' w kontekście ukrywania infrastruktury urzędu.
19. Opracowanie procedury awaryjnego dostępu do routera w przypadku zmiany adresu IP stacji administratora (dostęp przez port konsolowy lub adres MAC w WinBox).
20. Sformułowanie zaleceń audytorskich dla Urzędu Gminy zgodnie z wymogami Rozporządzenia w sprawie KRI.

Zastosowanie parametru 'address' w menu '/ip service' jest mechanizmem filtrowania wbudowanym bezpośrednio w demona danej usługi sieciowej. Odrzuca on pakiety na poziomie aplikacji, co stanowi doskonałą pierwszą linię obrony, jednak nie chroni zasobów sieciowych przed przetwarzaniem pakietów przez stos TCP/IP routera.

Wdrożenie reguł w zaporze ogniowej '/ip firewall filter' w łańcuchu 'input' zapewnia ochronę na poziomie jądra systemu operacyjnego. Reguła z akcją 'drop' powoduje ciche porzucenie pakietu bez odsyłania jakiejkolwiek odpowiedzi do nadawcy, dzięki czemu skanery portów identyfikują cel jako 'filtered', a potencjalny napastnik nie jest w stanie stwierdzić, czy pod tym adresem w ogóle działa router.

Poniżej przedstawiono listing poleceń RouterOS CLI konfigurujących listę adresową, reguły filtrujące zapory sieciowej oraz statystyki zablokowanych pakietów:

Zawsze zachowuj szczególną ostrożność podczas konfigurowania reguł zapory ogniowej w łańcuchu 'input'. Jeżeli przez pomyłkę zablokujesz własny adres IP lub interfejs zarządzający, możesz całkowicie utracić dostęp do urządzenia przez sieć IP. W systemie MikroTik bezpiecznym ratunkiem jest włączenie trybu 'Safe Mode' (skrót Ctrl+X) przed wprowadzeniem ryzykownych reguł.

Tryb Safe Mode automatycznie cofa wszystkie wprowadzone zmiany konfiguracyjne, jeżeli w ciągu określonego czasu połączenie administratora z routerem zostanie zerwane.

1. Uzasadnienie konieczności wielowarstwowej ochrony interfejsów zarządzania w jednostkach administracji samorządowej.
2. Porównanie skuteczności filtrowania na poziomie usługi (/ip service) oraz na poziomie zapory sieciowej (/ip firewall filter).
3. Zrozumienie znaczenia akcji 'drop' w kontekście utrudniania rekonesansu sieciowego i zaciemniania topologii (Security through Obscurity w połączeniu z kontrolą dostępu).
4. Wpływ odizolowania ruchu zarządzającego od podsieci ogólnodostępnych na zgodność z wymogami KRI i RODO.
5. Ocena ryzyka zablokowania dostępu administratora i znaczenie procedur awaryjnych (Safe Mode, dostęp konsolowy).
6. Rekomendacje dotyczące wdrożenia dedykowanego segmentu VLAN do celów zarządzania infrastrukturą teleinformatyczną urzędu.

Przykładowe wnioski (wzór do sprawozdania): Ograniczenie dostępu sieciowego do panelu administracyjnego RouterOS stanowi fundamentalny warunek ochrony infrastruktury sieciowej urzędu gminy przed nieuprawnioną rekonfiguracją. Wykorzystanie parametru 'address' w konfiguracji usługi www-ssl pozwala na sprzętowe odrzucenie pakietów pochodzących z adresów IP spoza zaufanej podsieci stacji administratora. Równoległe zastosowanie reguł w łańcuchu Input zapory sieciowej (firewall filter) tworzy wielowarstwową barierę (Defense in Depth), chroniąc interfejs WebFig nawet w razie błędu w samej usłudze webowej. Weryfikacja z poziomu stacji w podsieci urzędników potwierdziła całkowity brak odpowiedzi portu administracyjnego na próby nawiązania połączenia. Opracowana konfiguracja skutecznie minimalizuje ryzyko ataków typu Brute-Force oraz prób wykorzystania luk w oprogramowaniu układowym routera.

Kon1 Rodzaje i źródła zagrożeń. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon3 Architektura PKI i certyfikaty X.509. Efekty uczenia się: W3, W4, U1, U2, U4, K1, K2.

Celem zadania jest praktyczne zrozumienie hierarchicznej struktury infrastruktury klucza publicznego (PKI) oraz roli głównego urzędu certyfikacji (Root Certificate Authority – Root CA). Studenci tworzą lokalny, wewnętrzny urząd certyfikacji w środowisku Linux przy użyciu pakietu OpenSSL oraz wystawiają podpisany przez ten urząd certyfikat dla serwera WWW.

W toku ćwiczenia zespół generuje klucz prywatny i samopodpisany certyfikat Root CA, tworzy żądanie podpisania certyfikatu (CSR) dla szkolnego serwera intranetowego, podpisuje wniosek kluczem Root CA oraz instaluje certyfikat główny w magazynie zaufanych urzędów certyfikacji na stacji roboczej Windows. Studenci weryfikują eliminację ostrzeżeń przeglądarki i ustanowienie pełnego zaufania kryptograficznego. Prace kończą się przygotowaniem referatu technicznego.

Zespół Szkół Technicznych w Tarnowie posiada rozbudowaną infrastrukturę intranetową obejmującą elektroniczny dziennik lekcyjny, platformę e-learningową Moodle oraz serwer zasobów edukacyjnych dla uczniów. Wszystkie te usługi pracują w lokalnej domenie szkolnej '.szkola.local', która nie jest dostępna z publicznego Internetu.

Do tej pory na serwerach szkolnych stosowano certyfikaty samopodpisane. W rezultacie przy każdym logowaniu do platformy edukacyjnej uczniowie i nauczyciele widzieli w przeglądarkach czerwone komunikaty ostrzegawcze o 'braku zaufania do witryny' i byli zmuszani do klikania opcji 'Zaawansowane -> Przejdź mimo zagrożenia'. Wykształciło to u młodzieży skrajnie niebezpieczny nawyk bezrefleksyjnego ignorowania ostrzeżeń bezpieczeństwa, co ułatwiało potencjalne ataki phishingowe.

Dyrektor szkoły zlecił powołanie wewnętrznego szkolnego Urzędu Certyfikacji (Szkolne Root CA). Plan zakłada wygenerowanie głównego certyfikatu urzędu, bezpieczne zainstalowanie go w magazynach certyfikatów na wszystkich szkolnych komputerach pracowni oraz wystawienie certyfikatu serwerowego podpisanego przez szkolne CA dla serwera Apache.

Studenci wcielają się w administratorów PKI odpowiedzialnych za wdrożenie tego rozwiązania. Zespół konfiguruje środowisko OpenSSL, generuje 4096-bitowy klucz główny CA oraz certyfikat urzędu o 10-letnim okresie ważności. Następnie studenci generują klucz i wniosek CSR dla serwera WWW, podpisują wniosek szkolnym urzędem CA i konfigurują serwer Apache.

W ostatnim etapie studenci eksportują certyfikat szkolnego CA do pliku '.crt', importują go do magazynu 'Zaufane główne urzędy certyfikacji' w systemie Windows i weryfikują, że przeglądarka internetowa wyświetla zamkniętą zieloną kłódkę bez jakichkolwiek monitów ostrzegawczych.

1. Utworzenie dedykowanej struktury katalogów dla Urzędu Certyfikacji na serwerze Linux: 'mkdir -p ~/mini-pki/{certs,crl,newcerts,private}'.
2. Ustawienie restrykcyjnych uprawnień dla katalogu kluczy prywatnych: 'chmod 700 ~/mini-pki/private'.
3. Utworzenie początkowych plików bazy danych CA: 'touch ~/mini-pki/index.txt' oraz 'echo 1000 > ~/mini-pki/serial'.
4. Wygenerowanie 4096-bitowego klucza prywatnego głównego urzędu Root CA: 'openssl genrsa -aes256 -out ~/mini-pki/private/root-ca.key 4096'.
5. Wprowadzenie i zapamiętanie bezpiecznego hasła szyfrującego klucz główny CA.
6. Wygenerowanie samopodpisanego certyfikatu Root CA o ważności 10 lat: 'openssl req -x509 -new -nodes -key ~/mini-pki/private/root-ca.key -sha256 -days 3650 -out ~/mini-pki/certs/root-ca.crt'.
7. Uzupełnienie danych Root CA: Country (PL), Organization (ZST Tarnow), Common Name (ZST Tarnow Wewnetrzne Root CA).
8. Wygenerowanie 2048-bitowego klucza prywatnego dla serwera WWW: 'openssl genrsa -out /etc/apache2/ssl/szkola-serwer.key 2048'.
9. Utworzenie żądania podpisania certyfikatu (CSR) dla serwera: 'openssl req -new -key /etc/apache2/ssl/szkola-serwer.key -out /tmp/szkola-serwer.csr'.
10. Wprowadzenie w CSR identyfikatora serwera: Common Name = 'intranet.szkola.local'.
11. Utworzenie pliku rozszerzeń 'szkola-ext.cnf' zawierającego parametry 'subjectAltName = DNS:intranet.szkola.local' oraz 'basicConstraints = CA:FALSE'.
12. Podpisanie wniosku CSR serwera kluczem głównym Root CA: 'openssl x509 -req -in /tmp/szkola-serwer.csr -CA ~/mini-pki/certs/root-ca.crt -CAkey ~/mini-pki/private/root-ca.key -CAcreateserial -out /etc/apache2/ssl/szkola-serwer.crt -days 730 -sha256 -extfile szkola-ext.cnf'.
13. Wprowadzenie hasła do klucza Root CA i autoryzacja wystawienia certyfikatu serwera.
14. Skonfigurowanie serwera Apache w pliku VirtualHost z użyciem nowego certyfikatu 'szkola-serwer.crt' oraz klucza 'szkola-serwer.key'.
15. Przeładowanie usługi serwera WWW poleceniem 'sudo systemctl reload apache2'.
16. Skopiowanie pliku certyfikatu publicznego 'root-ca.crt' na stację roboczą klienta Windows.
17. W systemie Windows uruchomienie konsoli certyfikatów 'certmgr.msc' i zaimportowanie 'root-ca.crt' do magazynu 'Zaufane główne urzędy certyfikacji'.
18. Wpisanie w pliku 'hosts' na stacji Windows mapowania IP na nazwę 'intranet.szkola.local'.
19. Uruchomienie przeglądarki internetowej i wejście na stronę 'https://intranet.szkola.local'.
20. Weryfikacja braku ostrzeżeń o błędzie certyfikatu, zbadanie łańcucha certyfikacji (ZST Tarnow Root CA -> intranet.szkola.local) oraz udokumentowanie wyników w sprawozdaniu.

Hierarchiczna infrastruktura PKI opiera się na łańcuchu zaufania (Chain of Trust). System operacyjny klienta posiada wbudowaną bazę zaufanych urzędów certyfikacji (Root CA). Jeśli certyfikat serwera WWW został podpisany przez urząd znajdujący się w tym magazynie, przeglądarka automatycznie uznaje witrynę za autentyczną.

Plik rozszerzeń x509v3 z dyrektywą 'subjectAltName' (SAN) jest obecnie bezwzględnie wymagany przez przeglądarki Google Chrome, MS Edge i Firefox. Dawniej wystarczało pole Common Name (CN), jednak współczesne standardy bezpieczeństwa odrzucają certyfikaty, które nie deklarują domen w rozszerzeniu SAN.

Poniżej przedstawiono listing procedury podpisywania wniosku CSR serwera szkolnego za pomocą certyfikatu Root CA oraz wynik weryfikacji łańcucha poleceniem openssl verify:

Klucz prywatny urzędu certyfikacji ('root-ca.key') jest najcenniejszym elementem całej infrastruktury PKI. W warunkach produkcyjnych klucz Root CA jest chroniony silnym hasłem, przechowywany na odłączonym od sieci nośniku kryptograficznym (HSM lub dedykowany pendrive w sejfie) i używany wyłącznie do podpisywania certyfikatów pośrednich (Intermediate CA).

W systemie Windows import certyfikatu do magazynu użytkownika lub komputera można zautomatyzować w całej szkole za pomocą zasad grupy Active Directory (GPO) lub polecenia certutil: 'certutil -addstore -f "Root" root-ca.crt'.

1. Zrozumienie działania łańcucha zaufania PKI (Root CA -> Certyfikat końcowy) i jego roli w uwierzytelnianiu serwerów.
2. Wpływ obecności zaufanego certyfikatu na kształtowanie prawidłowych nawyków cyberbezpieczeństwa wśród użytkowników.
3. Rola żądania certyfikatu (CSR) jako bezpiecznego mechanizmu przekazywania klucza publicznego do podpisu bez ujawniania klucza prywatnego.
4. Znaczenie rozszerzenia Subject Alternative Name (SAN) we współczesnych standardach walidacji certyfikatów X.509.
5. Analiza procedur bezpieczeństwa związanych z fizyczną i logiczną ochroną klucza prywatnego Root CA.
6. Uzasadnienie przewagi wewnętrznego Mini-CA nad kupowaniem drogich certyfikatów komercyjnych dla zamkniętych sieci intranetowych.

Przykładowe wnioski (wzór do sprawozdania): Uruchomienie własnego Urzędu Certyfikacji (Mini-CA) za pomocą narzędzia OpenSSL pozwoliło na pełne zrozumienie hierarchicznej struktury zaufania w infrastrukturze klucza publicznego (PKI). Proces generowania żądania podpisania certyfikatu (CSR) oraz jego autoryzacja kluczem prywatnym CA wyjaśniły matematyczne i organizacyjne podstawy weryfikacji tożsamości serwerów. Zaimportowanie certyfikatu głównego Root CA do magazynu zaufanych urzędów na stacjach roboczych w pracowniach trwale wyeliminowało ostrzeżenia przeglądarek o braku zaufania. Zastosowanie wewnętrznego CA stanowi wysoce ekonomiczne i bezpieczne rozwiązanie dla szkolnych sieci intranetowych, eliminując konieczność zakupu komercyjnych certyfikatów dla domen lokalnych. Kluczowym wnioskiem z ćwiczenia jest konieczność bezwzględnej ochrony klucza prywatnego Root CA, którego kompromitacja oznaczałaby utratę integralności całego środowiska PKI.

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, U2, U4, K1, K3.

Celem ćwiczenia jest praktyczne opanowanie konfiguracji mechanizmu kontroli dostępu do wyznaczonych zasobów serwera Apache za pomocą uwierzytelniania podstawowego (HTTP Basic Authentication) powiązanego ze schematem haseł bcrypt/apr1 oraz bezwzględnie zabezpieczonego tunelem kryptograficznym TLS. Studenci poznają zasady tworzenia i zarządzania bazą użytkowników htpasswd.

W ramach zadania zespół konfiguruje pliki dyrektyw kontroli dostępu (.htaccess lub dyrektywy Directory w konfiguracji wirtualnego hosta), bada proces wymiany nagłówków autoryzacyjnych HTTP (kody 401 Unauthorized oraz nagłówek Authorization) i weryfikuje bezpieczeństwo poświadczeń przesyłanych wewnątrz tunelu HTTPS. Studenci analizują wymogi ochrony tajemnicy notarialnej w świetle przepisów prawa. Efektem prac jest zabezpieczone repozytorium aktów oraz pisemny referat.

Kancelaria Notarialna w Grodzisku Mazowieckim prowadzi wewnętrzny serwer webowy wykorzystywany przez notariuszy i aplikantów do wymiany projektów aktów notarialnych, odpisów ksiąg wieczystych oraz rejestrów spadkowych. W zasobach serwera wyodrębniono katalog webowy '/akty-poufne', w którym gromadzone są zdigitalizowane dokumenty o najwyższym stopniu poufności.

W trakcie audytu wewnętrznego stwierdzono, że do katalogu '/akty-poufne' ma obecnie dostęp każdy użytkownik sieci lokalnej, który zna bezpośredni adres URL, bez konieczności wprowadzania jakichkolwiek poświadczeń. Sytuacja ta stwarza krytyczne ryzyko naruszenia tajemnicy notarialnej (art. 18 ustawy Prawo o notariacie) oraz nieuprawnionego ujawnienia danych osobowych stron czynności notarialnych.

Kierownik kancelarii zażądał natychmiastowego zablokowania swobodnego dostępu do katalogu. Wymagane jest wdrożenie mechanizmu autoryzacji wymagającego podania loginu i silnego hasła przez uprawnionych pracowników kancelarii, przy czym mechanizm ten musi funkcjonować wyłącznie w ramach szyfrowanego protokołu HTTPS, aby wykluczyć podsłuch poświadczeń.

Zespół studentów podejmuje się realizacji zadania w środowisku Linux / Apache. Grupa ma za zadanie wygenerować bazę użytkowników htpasswd z hasłami zabezpieczonymi bezpieczną funkcją skrótu, skonfigurować dyrektywę '' w wirtualnym hoście SSL serwera Apache oraz przetestować zachowanie przeglądarki podczas prób autoryzacji.

Po wdrożeniu studenci weryfikują działanie mechanizmu z poziomu wiersza poleceń curl oraz w przeglądarce, dokumentując proces odrzucenia nieautoryzowanego zapytania kodem 401, mechanizm challenge-response oraz pomyślny dostęp po poprawnym uwierzytelnieniu.

1. Zalogowanie się na serwer Linux i utworzenie dedykowanego katalogu na poufne dokumenty: 'sudo mkdir -p /var/www/html/akty-poufne'.
2. Utworzenie przykładowego poufnego pliku dokumentacji: 'echo "Poufny Rejestr Czynnosci Notarialnych 2026" | sudo tee /var/www/html/akty-poufne/rejestr.txt'.
3. Ustawienie odpowiednich uprawnień własności dla serwera WWW: 'sudo chown -R www-data:www-data /var/www/html/akty-poufne'.
4. Utworzenie chronionego katalogu na pliki haseł poza przestrzenią dokumentów WWW: 'sudo mkdir -p /etc/apache2/auth'.
5. Zabezpieczenie katalogu haseł przed dostępem niepowołanych użytkowników systemu: 'sudo chmod 700 /etc/apache2/auth'.
6. Utworzenie pliku bazy haseł i dodanie pierwszego użytkownika 'notariusz_jan' za pomocą narzędzia htpasswd z funkcją bcrypt: 'sudo htpasswd -B -c /etc/apache2/auth/.htpasswd notariusz_jan'.
7. Wprowadzenie i potwierdzenie silnego hasła dla użytkownika 'notariusz_jan'.
8. Dodanie drugiego użytkownika 'aplikant_adam' (bez opcji -c, aby nie nadpisać pliku): 'sudo htpasswd -B /etc/apache2/auth/.htpasswd aplikant_adam'.
9. Zbadanie zawartości pliku '/etc/apache2/auth/.htpasswd' i zaobserwowanie, że hasła są zapisane w postaci kryptograficznych skrótów bcrypt ('$2y$...').
10. Ustawienie uprawnień odczytu pliku haseł wyłącznie dla użytkownika serwera Apache: 'sudo chown www-data:www-data /etc/apache2/auth/.htpasswd' oraz 'sudo chmod 640 /etc/apache2/auth/.htpasswd'.
11. Edycja pliku konfiguracyjnego wirtualnego hosta SSL '/etc/apache2/sites-available/przychodnia-ssl.conf'.
12. Wprowadzenie wewnątrz sekcji '' bloku konfiguracji ochrony katalogu: '', 'AuthType Basic', 'AuthName "Kancelaria Notarialna - Strefa Poufna"', 'AuthUserFile /etc/apache2/auth/.htpasswd', 'Require valid-user', ''.
13. Sprawdzenie poprawności składni konfiguracji Apache poleceniem 'sudo apache2ctl configtest'.
14. Przeładowanie serwera Apache poleceniem 'sudo systemctl reload apache2'.
15. Przeprowadzenie testu dostępu bez podania poświadczeń za pomocą narzędzia curl: 'curl -k -I https://localhost/akty-poufne/rejestr.txt'.
16. Zarejestrowanie odpowiedzi serwera: kod 'HTTP/1.1 401 Unauthorized' oraz obecność nagłówka 'WWW-Authenticate: Basic realm="Kancelaria Notarialna - Strefa Poufna"'.
17. Przeprowadzenie testu z błędnymi danymi uwierzytelniającymi: 'curl -k -I -u notariusz_jan:ZleHaslo123 https://localhost/akty-poufne/rejestr.txt' (potwierdzenie kodu 401).
18. Przeprowadzenie testu z poprawnymi danymi uwierzytelniającymi: 'curl -k -u notariusz_jan:PoprawneHaslo https://localhost/akty-poufne/rejestr.txt' (potwierdzenie pobrania zawartości dokumentu ze statusem 200 OK).
19. Otwarcie w przeglądarce internetowej adresu 'https://serwer.przychodnia.local/akty-poufne/rejestr.txt', zaobserwowanie systemowego okna logowania i weryfikacja poprawnego logowania.
20. Udokumentowanie procesu konfiguracji, wyników testów wiersza poleceń oraz sformułowanie wniosków prawno-technicznych.

Mechanizm HTTP Basic Authentication przesyła poświadczenia użytkownika w nagłówku żądania w formacie 'Authorization: Basic '. Ciąg ten jest jedynie zakodowany w formacie Base64 ('login:haslo') i nie jest w żaden sposób zaszyfrowany. Dlatego stosowanie Basic Auth na nieszyfrowanym protokole HTTP jest krytycznym błędem bezpieczeństwa. Dopiero enkapsulacja całego połączenia w tunelu TLS (HTTPS) sprawia, że nagłówek ten staje się całkowicie bezpieczny i niewidoczny dla osób trzecich w sieci.

W narzędziu htpasswd zawsze zaleca się stosowanie przełącznika '-B', który wymusza użycie nowoczesnego, odpornego na łamanie siłowe algorytmu bcrypt zamiast przestarzałego algorytmu MD5 czy tradycyjnego DES crypt.

Poniżej przedstawiono przykładową sesję w konsoli serwera ilustrującą generowanie haseł htpasswd oraz weryfikację kodów odpowiedzi HTTP za pomocą curl:

Zwróć uwagę na lokalizację pliku '.htpasswd'. Bezwzględnie nie wolno umieszczać tego pliku wewnątrz katalogu głównego serwera WWW (DocumentRoot), np. w '/var/www/html/'. W przypadku błędu konfiguracji serwera plik ten mógłby zostać bezpośrednio pobrany przez użytkowników internetu. Katalog '/etc/apache2/auth/' jest lokalizacją bezpieczną.

W sprawozdaniu wyjaśnij różnicę pomiędzy dyrektywą 'Require valid-user' (dostęp dla każdego użytkownika zdefiniowanego w pliku haseł) a 'Require user notariusz_jan' (dostęp zawężony wyłącznie do wskazanego loginu).

1. Zrozumienie mechanizmu działania protokołu HTTP Basic Authentication i jego zależności od warstwy kryptograficznej TLS.
2. Wykazanie, dlaczego kodowanie Base64 wymaga bezwzględnego tunelowania w protokole HTTPS dla zapewnienia poufności.
3. Ocena poziomu bezpieczeństwa funkcji skrótu bcrypt w porównaniu ze standardowymi skrótami MD5 w kontekście ataków słownikowych.
4. Znaczenie prawidłowego lokowania plików poświadczeń poza drzewem katalogowym DocumentRoot serwera Apache.
5. Analiza prawna ochrony tajemnicy notarialnej i danych osobowych w świetle art. 18 Prawa o notariacie i art. 32 RODO.
6. Rekomendacje dotyczące wdrożenia uwierzytelniania wieloskładnikowego (MFA) dla stref o najwyższym poziomie poufności.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie mechanizmu HTTP Basic Authentication w połączeniu z szyfrowaniem TLS zapewniło skuteczną, dwuwarstwową ochronę poufnych repozytoriów dokumentów w kancelarii notarialnej. Analiza nagłówków protokołu HTTP wykazała, że przesyłanie poświadczeń w nagłówku 'Authorization' w postaci zakodowanej base64 jest bezpieczne wyłącznie wtedy, gdy cały ruch jest hermetyzowany w tunelu TLS. Zastosowanie bezpiecznych algorytmów haszowania (np. bcrypt) w plikach .htpasswd uniemożliwia odzyskanie haseł użytkowników nawet w przypadku nieuprawnionego odczytu konfiguracji serwera. Precyzyjne zdefiniowanie dyrektyw 'Require valid-user' w plikach konfiguracyjnych Apache pozwoliło na wydzielenie stref dostępu dla poszczególnych pracowników kancelarii. Zadanie udowodniło, że proste mechanizmy uwierzytelniania wbudowane w serwer WWW, przy zachowaniu rygorów kryptograficznych, mogą stanowić solidną barierę dla niepowołanego dostępu.

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

Celem ćwiczenia jest opanowanie umiejętności implementacji dynamicznych reguł ochronnych w zaporze sieciowej MikroTik RouterOS w celu mitygacji ataków siłowych (Brute-Force) oraz ataków słownikowych ukierunkowanych na interfejs WebFig (port 443 TCP). Studenci poznają mechanizm list adresowych (Address Lists) z dynamicznym czasem wygaśnięcia.

W trakcie laboratorium zespół bada zachowanie routera podczas serii nieudanych prób logowania, tworzy wieloetapowy mechanizm detekcji powtarzających się żądań w łańcuchu 'input' zapory sieciowej oraz konfiguruje automatyczne wpisywanie agresora na czarną listę (Blacklist) z blokadą na określony czas. Studenci weryfikują działanie ochrony symulując atak ze stacji roboczej klienta. Wynikiem zadania jest zabezpieczony router oraz sprawozdanie techniczne.

Przedsiębiorstwo Komunalne „Eko-Wodociągi” w Otwocku zarządza miejską stacją uzdatniania wody oraz przepompowniami ścieków. Do monitorowania i sterowania pracą urządzeń brzegowych wykorzystywane są routery MikroTik RouterOS z aktywnym panelem WebFig na porcie HTTPS 443.

W analizie dzienników zdarzeń (logów) routera odnotowano niepokojący wzrost liczby nieudanych prób logowania na konto 'admin' pochodzących z różnych podsieci lokalnych oraz urządzeń podłączonych przez mosty radiowe. W ciągu zaledwie jednej godziny zarejestrowano ponad 600 prób uwierzytelnienia z jednego adresu IP, co jednoznacznie wskazuje na działanie automatycznego skryptu łamiącego hasła metodą Brute-Force.

Tego typu ataki stwarzają bezpośrednie zagrożenie przejęcia kontroli nad infrastrukturą krytyczną gminy, a dodatkowo powodują wysokie obciążenie procesora routera ciągłym przetwarzaniem żądań kryptograficznych TLS Handshake i weryfikacją haseł.

Dyrektor ds. bezpieczeństwa polecił zespołowi administratorów pilne wdrożenie mechanizmu automatycznej obrony. Rozwiązanie musi wykrywać hosty wykonujące więcej niż 5 prób nawiązania połączenia w krótkim czasie i automatycznie blokować ich adres IP na okres 60 minut, uniemożliwiając prowadzenie skutecznego ataku słownikowego.

Studenci wcielają się w inżynierów bezpieczeństwa realizujących tę konfigurację w RouterOS CLI. Zespół tworzy sekwencję reguł zapory ogniowej wykorzystujących mechanizm 'connection-state=new' oraz dynamiczne dodawanie adresów do list 'webfig_stage1', 'webfig_stage2' i 'webfig_blacklist', a następnie testuje rozwiązanie w kontrolowanych warunkach laboratoryjnych.

1. Zalogowanie się do konsoli routera MikroTik RouterOS przy użyciu bezpiecznego konta administracyjnego.
2. Weryfikacja aktualnych logów systemowych poleceniem '/log print where topics~"account"' w celu zbadania historii logowań.
3. Utworzenie reguły zapory ogniowej w łańcuchu 'input' bezwzględnie blokującej hosty znajdujące się na czarnej liście: '/ip firewall filter add chain=input src-address-list=webfig_blacklist action=drop comment="Blokuj agresorow WebFig Brute-Force" place-before=0'.
4. Dodanie pierwszej reguły detekcji rejestrującej nowe próby połączenia na port 443: '/ip firewall filter add chain=input protocol=tcp dst-port=443 connection-state=new src-address-list=!webfig_stage1 action=add-src-to-address-list address-list=webfig_stage1 address-list-timeout=1m comment="Krok 1 Brute-Force"'.
5. Dodanie drugiej reguły detekcji wyłapującej powtórne próby połączenia w ciągu 1 minuty: '/ip firewall filter add chain=input protocol=tcp dst-port=443 connection-state=new src-address-list=webfig_stage1 action=add-src-to-address-list address-list=webfig_stage2 address-list-timeout=1m comment="Krok 2 Brute-Force"'.
6. Dodanie trzeciej reguły, która przy kolejnej próbie wpisuje agresora na czarną listę na 60 minut: '/ip firewall filter add chain=input protocol=tcp dst-port=443 connection-state=new src-address-list=webfig_stage2 action=add-src-to-address-list address-list=webfig_blacklist address-list-timeout=60m comment="Krok 3 Blacklist 60m"'.
7. Upewnienie się, że standardowy ruch established i related jest przepuszczany na początku łańcucha input: '/ip firewall filter add chain=input connection-state=established,related action=accept place-before=0'.
8. Weryfikacja kolejności reguł w zaporze sieciowej poleceniem '/ip firewall filter print'.
9. Na stacji roboczej klienta Windows przygotowanie prostego skryptu PowerShell symulującego wielokrotne próby połączenia do portu 443.
10. Uruchomienie pętli testowej w PowerShell: '1..5 | ForEach-Object { Test-NetConnection -ComputerName 192.168.88.1 -Port 443; Start-Sleep -Milliseconds 500 }'.
11. Równoległa obserwacja w konsoli RouterOS dynamicznego zapełniania list adresowych poleceniem '/ip firewall address-list print'.
12. Zarejestrowanie momentu, w którym adres stacji klienta pojawia się na liście 'webfig_blacklist' z odliczanym czasem wygaśnięcia.
13. Weryfikacja skutku blokady: kolejne próby w PowerShell kończą się niepowodzeniem (TcpTestSucceeded: False).
14. Próba otwarcia w przeglądarce adresu 'https://192.168.88.1' i upewnienie się, że strona routera przestała całkowicie odpowiadać dla stacji testowej.
15. Sprawdzenie stanu liczników zablokowanych pakietów w regule drop za pomocą polecenia '/ip firewall filter print stats'.
16. Usunięcie adresu testowego z czarnej listy poleceniem '/ip firewall address-list remove [find address="192.168.88.50"]' w celu natychmiastowego przywrócenia dostępu.
17. Ponowna weryfikacja dostępności panelu po wyczyszczeniu wpisu z czarnej listy.
18. Przeanalizowanie wpływu doboru parametrów czasowych (timeout) na skuteczność mitygacji oraz ryzyko zablokowania legalnego administratora.
19. Opracowanie procedury białej listy (Whitelist) dla zaufanych adresów IP chroniącej przed omyłkowym zablokowaniem kluczowych stacji.
20. Sformułowanie wniosków końcowych dotyczących zabezpieczania urządzeń infrastruktury krytycznej przed atakami wolumetrycznymi i siłowymi.

Mechanizm wieloetapowego wykrywania ataków Brute-Force w RouterOS opiera się na łańcuchu list adresowych o krótkim czasie życia (np. 1 minuta). Dopiero gdy host wykonuje połączenia częściej niż wynosi dopuszczalny próg w zdefiniowanym oknie czasowym, zostaje przeniesiony do listy docelowej 'webfig_blacklist' z długim czasem blokady.

Kluczowe znaczenie ma umieszczenie reguły blokującej ('action=drop src-address-list=webfig_blacklist') na samej górze łańcucha 'input' (lub zaraz po regule accept established,related). Router przetwarza reguły filtrujące sekwencyjnie od góry do dołu, dlatego agresor musi zostać zablokowany zanim pakiet dotrze do reguł akceptujących.

Poniżej przedstawiono przykładowy widok konsoli RouterOS obrazujący status dynamicznej czarnej listy adresowej po wykryciu próby ataku siłowego:

W systemie produkcyjnym bezwzględnie należy zmienić domyślną nazwę konta 'admin' na unikalną (np. 'kierownik_it_2026') oraz utworzyć silne, co najmniej 16-znakowe hasło. Znakomita większość automatycznych skryptów atakujących testuje wyłącznie poświadczenia konta o nazwie 'admin'.

Warto również rozważyć zmianę domyślnego portu usługi www-ssl z 443 na niestandardowy port o wysokim numerze (np. 8443 lub 10443), co eliminuje ponad 90% automatycznych skanerów przeszukujących sieć w poszukiwaniu standardowych usług WWW.

1. Zrozumienie mechanizmu automatycznych ataków siłowych na webowe interfejsy zarządzania urządzeniami sieciowymi.
2. Ocena skuteczności dynamicznych list adresowych RouterOS w mitygacji ataków słownikowych.
3. Znaczenie hierarchii i kolejności reguł w zaporze sieciowej dla wydajności procesora routera.
4. Rola białych list (Whitelist) w zabezpieczeniu przed przypadkowym odcięciem uprawnionego personelu.
5. Wpływ zmiany domyślnych nazw kont i portów na redukcję szumu skanowania sieciowego.
6. Zalecenia dotyczące monitorowania i alarmowania o próbach naruszenia bezpieczeństwa w infrastrukturze komunalnej.

Przykładowe wnioski (wzór do sprawozdania): Zaimplementowanie dynamicznych list adresowych w zaporze MikroTik RouterOS pozwoliło na skuteczną detekcję i automatyczne tłumienie ataków słownikowych i siłowych (Brute-Force) na panel WebFig. Mechanizm wieloetapowego zliczania nieudanych prób logowania umożliwia odróżnienie sporadycznych pomyłek uprawnionych pracowników od zautomatyzowanego skanowania przez botnety. Automatyczne dopisywanie agresywnych adresów IP do czarnej listy z regułą DROP na 24 godziny radykalnie ogranicza zużycie procesora routera i zapobiega atakom typu odmowa usługi (DoS). Zastosowanie mechanizmów tarpit lub natychmiastowego odrzucenia pakietów TCP RESET skutecznie dezinformuje skanery sieciowe przeciwnika. Rozwiązanie to stanowi wzorcowy przykład automatyzacji obrony perymetrycznej, podnosząc cyberodporność routera bez konieczności ciągłej interwencji administratora.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon3 Algorytmy kryptograficzne i zestawy szyfrów. Efekty uczenia się: W1, W2, W4, U1, U3, U4, K1, K2.

Głównym celem zadania jest nabycie praktycznych umiejętności utwardzania konfiguracji kryptograficznej serwera Apache poprzez eliminację podatnych, przestarzałych wersji protokołów szyfrowania (SSLv2, SSLv3, TLS 1.0, TLS 1.1) oraz wymuszenie wyłącznie nowoczesnych protokołów TLS 1.2 i TLS 1.3 z bezpiecznymi zestawami szyfrów (Cipher Suites).

W trakcie laboratorium studenci badają podatności kryptograficzne starszych protokołów (takie jak ataki POODLE, BEAST czy DROWN), testują zachowanie serwera za pomocą zaawansowanych poleceń klienta 'openssl s_client' wymuszających konkretne wersje protokołów oraz konfigurują restrykcyjne dyrektywy SSLProtocol i SSLCipherSuite w serwerze Apache. Prace kończą się analizą raportu podatności i sformułowaniem rekomendacji dla instytucji sektora finansowego.

Bank Spółdzielczy Ziemi Mazowieckiej prowadzi regionalny portal informacyjny oraz internetowy system obsługi wniosków kredytowych dla rolników i lokalnych przedsiębiorców. Serwis funkcjonuje na serwerze Linux Apache z zainstalowanym komercyjnym certyfikatem cyfrowym X.509.

W ramach okresowego audytu bezpieczeństwa zleconego przez Komisję Nadzoru Finansowego (KNF) stwierdzono, że serwer WWW akceptuje połączenia z wykorzystaniem przestarzałych protokołów TLS 1.0 i TLS 1.1, a lista obsługiwanych szyfrów obejmuje algorytmy korzystające z funkcji skrótu SHA-1 oraz trybu szyfrowania blokowego CBC, podatnego na ataki typu Padding Oracle.

Inspektor nadzoru KNF zażądał natychmiastowego dostosowania konfiguracji kryptograficznej do standardów PCI DSS 4.0 oraz Rekomendacji KNF dotyczących zarządzania obszarami technologii informacyjnej. Wymagane jest bezwzględne wyłączenie protokołów starszych niż TLS 1.2 oraz wdrożenie bezpiecznych zestawów szyfrów zapewniających doskonałe utajnianie z wyprzedzeniem (PFS – Perfect Forward Secrecy).

Zespół studentów wciela się w audytorów i inżynierów bezpieczeństwa realizujących to zadanie. Grupa najpierw przeprowadza diagnostykę podatności serwera, wykazując możliwość nawiązania połączenia przestarzałym protokołem TLS 1.0. Następnie studenci modyfikują plik konfiguracyjny modułu SSL Apache, wprowadzając rygorystyczne reguły doboru protokołów i szyfrów.

Końcowym etapem jest ponowna weryfikacja: próba nawiązania połączenia przez TLS 1.0 i TLS 1.1 musi zakończyć się natychmiastowym błędem uzgadniania (Handshake Failure), natomiast połączenia przez TLS 1.2 i TLS 1.3 muszą być realizowane z wykorzystaniem bezpiecznych algorytmów ECDHE-RSA-AES-GCM.

1. Zalogowanie się na serwer Linux i weryfikacja aktualnej globalnej konfiguracji modułu SSL w pliku '/etc/apache2/mods-available/ssl.conf'.
2. Zbadanie domyślnej dyrektywy 'SSLProtocol' i odnotowanie akceptowanych protokołów.
3. Przeprowadzenie testu podatności z poziomu konsoli serwera za pomocą narzędzia OpenSSL, próbując wymusić protokół TLS 1.0: 'openssl s_client -connect localhost:443 -tls1'.
4. Zaobserwowanie, że połączenie zostało pomyślnie zestawione ('New, TLSv1.0, Cipher is...'), co dowodzi podatności serwera na ataki kryptograficzne.
5. Przeprowadzenie testu dla protokołu TLS 1.1 poleceniem 'openssl s_client -connect localhost:443 -tls1_1' i odnotowanie pomyślnego nawiązania sesji.
6. Otwarcie do edycji pliku konfiguracyjnego wirtualnego hosta SSL '/etc/apache2/sites-available/przychodnia-ssl.conf' (lub dedykowanego pliku banku).
7. Wprowadzenie restrykcyjnej dyrektywy wyłączającej wszystkie protokoły oprócz TLS 1.2 i TLS 1.3: 'SSLProtocol -all +TLSv1.2 +TLSv1.3'.
8. Skonfigurowanie bezpiecznej listy zestawów szyfrów dla protokołu TLS 1.2: 'SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'.
9. Wymuszenie priorytetu wyboru szyfru po stronie serwera: 'SSLHonorCipherOrder on'.
10. Włączenie mechanizmu ochrony sesji przed ponownym użyciem: 'SSLSessionTickets off'.
11. Zapisanie pliku konfiguracyjnego i przetestowanie poprawności składni poleceniem 'sudo apache2ctl configtest'.
12. Przeładowanie usługi serwera Apache poleceniem 'sudo systemctl restart apache2'.
13. Ponowne wykonanie testu wymuszenia protokołu TLS 1.0: 'openssl s_client -connect localhost:443 -tls1'.
14. Zarejestrowanie oczekiwanego błędu negocjacji: 'handshake failure' lub 'no protocols available', co dowodzi skuteczności blokady.
15. Ponowne wykonanie testu dla protokołu TLS 1.1: 'openssl s_client -connect localhost:443 -tls1_1' (potwierdzenie błędu negocjacji).
16. Przeprowadzenie testu połączenia z nowoczesnym protokołem TLS 1.2: 'openssl s_client -connect localhost:443 -tls1_2'.
17. Odnotowanie pomyślnego nawiązania sesji z wykorzystaniem szyfrowania uwierzytelnionego AES-GCM oraz wymiany kluczy opartej na krzywych eliptycznych (ECDHE).
18. Przeprowadzenie testu z protokołem TLS 1.3: 'openssl s_client -connect localhost:443 -tls1_3' i analiza parametrów najnowszego standardu.
19. Sporządzenie zestawienia tabelarycznego parametrów kryptograficznych przed i po utwardzeniu serwera.
20. Opracowanie podsumowania dla zarządu banku spółdzielczego z uzasadnieniem zgodności z wytycznymi KNF i PCI DSS.

Protokoły TLS 1.0 i TLS 1.1 zostały oficjalnie uznane za przestarzałe i wycofane z użycia przez organizację IETF w dokumencie RFC 8996 w marcu 2021 roku. Ich stosowanie wiąże się ze znanymi podatnościami na ataki kryptograficzne oraz brakiem wsparcia dla nowoczesnych mechanizmów AEAD (Authenticated Encryption with Associated Data).

Kluczowym elementem nowoczesnej konfiguracji jest zapewnienie własności Perfect Forward Secrecy (PFS). Osiąga się to poprzez stosowanie algorytmów wymiany kluczy opartych na efemerycznym protokole Diffiego-Hellmana (DHE) lub jego wariancie na krzywych eliptycznych (ECDHE). W przypadku kompromitacji klucza prywatnego serwera w przyszłości, nagrany wcześniej przez napastnika ruch sieciowy nadal pozostanie niemożliwy do odszyfrowania.

Poniżej przedstawiono zrzut ekranu z konsoli serwera obrazujący błąd odrzucenia przestarzałego protokołu TLS 1.0 oraz pomyślną negocjację bezpiecznej sesji TLS 1.3:

W protokole TLS 1.3 zarządzanie zestawami szyfrów zostało fundamentalnie uproszczone. Dyrektywa 'SSLCipherSuite' w Apache kontroluje głównie szyfry protokołu TLS 1.2, natomiast dla TLS 1.3 dedykowana jest dyrektywa 'SSLCipherSuite TLSv1.3 ...', choć domyślne zestawy TLS 1.3 w nowoczesnych wersjach OpenSSL są bezpieczne i nie wymagają ręcznej ingerencji.

W instytucjach finansowych regularne skanowanie konfiguracji SSL serwerów publicznych (np. za pomocą bezpłatnego narzędzia testssl.sh lub serwisu Qualys SSL Labs) jest standardową procedurą audytową wymaganą do uzyskania najwyższej oceny bezpieczeństwa A+.

1. Zrozumienie ewolucji protokołów kryptograficznych od podatnego SSLv2/SSLv3 do nowoczesnego standardu TLS 1.3.
2. Wpływ wycofania starszych protokołów (TLS 1.0, TLS 1.1) na zgodność z wymogami regulacyjnymi KNF i PCI DSS.
3. Znaczenie koncepcji Perfect Forward Secrecy (PFS) w ochronie historycznie zarejestrowanej komunikacji szyfrowanej.
4. Rola szyfrowania uwierzytelnionego AEAD (AES-GCM, ChaCha20-Poly1305) w eliminacji ataków typu Padding Oracle na tryb CBC.
5. Umiejętność diagnostyki parametrów negocjacji SSL/TLS za pomocą narzędzi wiersza poleceń OpenSSL.
6. Sformułowanie procedur ciągłego monitorowania podatności kryptograficznych w systemach bankowości elektronicznej.

Przykładowe wnioski (wzór do sprawozdania): Audyt konfiguracji kryptograficznej serwera bankowego wykazał konieczność natychmiastowego wycofania wsparcia dla przestarzałych protokołów TLS 1.0 i TLS 1.1 z uwagi na ich podatność na ataki kryptograficzne (np. BEAST, POODLE). Ograniczenie dozwolonych wersji do TLS 1.2 oraz TLS 1.3 gwarantuje wykorzystanie wyłącznie silnych zestawów szyfrujących opartych o algorytmy AEAD (AES-GCM, ChaCha20-Poly1305). Obowiązkowe stosowanie protokołów wymiany kluczy z mechanizmem Forward Secrecy (ECDHE) zabezpiecza archiwalne sesje klientów przed odszyfrowaniem w przyszłości w razie ujawnienia klucza prywatnego serwera. Weryfikacja konfiguracji za pomocą darmowego narzędzia testssl.sh pozwoliła na szczegółową ocenę podatności serwera i uzyskanie najwyższych ocen w standardach branżowych KNF i PCI DSS. Zadanie potwierdziło, że stała modernizacja parametrów kryptograficznych jest niezbędnym elementem utrzymania zaufania w sektorze bankowości elektronicznej.