Laboratorium: Utrzymanie usług i serwisów sieciowych

Wykład 2 Rola NTP w logowaniu zdarzeń, synchronizacja Kerberos, hierarchia stratum.

W firmowej sieci rozproszonej zauważono rozbieżności w logach systemowych, co uniemożliwia poprawną analizę incydentów bezpieczeństwa. Serwer Centralny (Router) posiada precyzyjny czas, ale urządzenia brzegowe oraz stacje robocze wykazują kilkuminutowe przesunięcia. Twoim zadaniem jest zbudowanie hierarchicznej struktury synchronizacji czasu, w której Router pełni rolę serwera NTP Stratum 1 (synchronizowanego zewnętrznie), a pozostałe urządzenia pełnią rolę klientów. Musisz zapewnić, aby każde zdarzenie w sieci było opatrzone identycznym stemplem czasowym.

• Użycie routera 2911 jako centralnego serwera NTP.
• Dodanie serwera zewnętrznego (Server-PT) symulującego zegar wzorcowy.
• Konfiguracja routera jako klienta serwera zewnętrznego.
• Uruchomienie usługi NTP server na routerze dla sieci wewnętrznej.
• Konfiguracja przełącznika (Switch 2960) jako klienta NTP routera.
• Konfiguracja dwóch komputerów (PC) do synchronizacji czasu z routerem.
• Ustawienie właściwej strefy czasowej (timezone) na wszystkich urządzeniach.
• Weryfikacja statusu synchronizacji poleceniem "show ntp status".
• Sprawdzenie listy serwerów uprawnionych poleceniem "show ntp associations".
• Wymuszenie aktualizacji czasu i obserwacja zmian w logach buforowanych.
• Zabezpieczenie serwera NTP za pomocą prostego uwierzytelniania (jeśli wspierane).
• Udokumentowanie numeru stratum na różnych poziomach hierarchii.

Poniżej przedstawiono realistyczne wyniki poleceń CLI wzorowane na rzeczywistym środowisku Cisco IOS. Kolorystyka: żółty — polecenia użytkownika, zielony — wyniki, biały — prompt.

Precyzyjna synchronizacja czasu stanowi fundament usług katalogowych, takich jak Active Directory, gdzie protokół Kerberos wymaga zgodności czasowej z tolerancją do 5 minut między klientem a serwerem. W praktyce Cisco, gdy różnica czasu przekracza dopuszczalny próg, bilety TGT są natychmiast odrzucane, co skutkuje blokadą uwierzytelniania użytkowników i niemożnością logowania do zasobów sieciowych. Z perspektywy audytu bezpieczeństwa, heterogeniczne logi bez spójnego timestampu uniemożliwiają korelację zdarzeń i rekonstrukcję chronologii incydentów, co jest kluczowe w dochodzeniu cyberniezgodności oraz w spełnianiu wymogów compliance (np. RODO, ISO 27001). NTP w hierarchii stratum zapewnia skalowalność — serwer zewnętrzny jako stratum 1 propaguje czas do kolejnych warstw, co eliminuje ryzyko złożonych dryftów czasowych w rozległych infrastrukturach korporacyjnych.

Wykład 2 Proces DORA, DHCP Relay Agent, bezpieczeństwo (Snooping).

Firma posiada dwa działy: IT (VLAN 10) oraz HR (VLAN 20). Centralny serwer DHCP znajduje się w podsieci serwerowej, która jest odseparowana od sieci użytkowników przez router. Ponieważ rozgłoszenia DHCP (broadcast) nie przechodzą przez router, musisz skonfigurować mechanizm przekazywania żądań (Relay), aby pracownicy obu działów mogli automatycznie uzyskać adresację IP z właściwych puli. Dodatkowo musisz zapewnić, że urządzenia w VLAN 10 otrzymają inne parametry (np. inny serwer DNS) niż urządzenia w VLAN 20.

• Konfiguracja subinterfejsów dot1Q na routerze brzegowym (Router-on-a-Stick).
• Stworzenie dwóch pul DHCP na dedykowanym serwerze (Server-PT).
• Konfiguracja "ip helper-address" na interfejsach bram domyślnych VLANów.
• Weryfikacja procesu DORA w trybie symulacji (analiza pakietów).
• Przydzielenie statycznej rezerwacji dla drukarki sieciowej po adresie MAC.
• Ustawienie czasu dzierżawy (lease time) na 24 godziny.
• Weryfikacja tablicy dzierżaw na serwerze DHCP.
• Testowanie poprawności konfiguracji bramy domyślnej i DNS na stacjach klienckich.
• Wykluczenie zakresu adresów statycznych (exclusion list) z puli dynamicznej.
• Weryfikacja dostępności serwera DHCP przez ping z różnych VLANów.
• Dokumentacja struktury pakietu po przejściu przez Relay Agent (zmiana adresu źródłowego).

DHCP Relay (ip helper-address) stanowi efektywniejsze rozwiązanie od instalowania dedykowanych serwerów DHCP w każdej podsieci, ponieważ eliminuje redundancję sprzętową, centralizuje zarządzanie pulami adresowymi i zapewnia spójność polityki adresacji w całej organizacji. W architekturze wielowarstwowej, gdzie routery segmenteują ruch warstwy 3, Relay Agent przekazuje broadcasty DHCP do centralnego serwera, zachowując jednocześnie izolację broadcastów warstwy 2. Z perspektywy bezpieczeństwa, atak DHCP Starvation polega na zalaniu serwera fałszywymi żądaniami DORA w celu wyczerpania puli adresowej — atakujący generuje tysiące żądań z losowymi adresami MAC, co powoduje, że legalni klienci nie mogą otrzymać adresu IP. Ochrona przed tym zagrożeniem wymaga implementacji DHCP Snooping na przełącznikach Cisco, który klasyfikuje porty jako zaufane (trusted) lub niezaufane (untrusted) i blokuje pakiety DHCP Offer pochodzące z nieautoryzowanych źródeł, a także limitowania liczby wpisów ARP na portach accessowych.

Wykład 2 Rekordy A, CNAME, MX, odpytywanie rekurencyjne.

Uruchamiasz nową infrastrukturę usług dla domeny "firma.local". Twoim zadaniem jest konfiguracja serwera DNS, który będzie obsługiwał zapytania lokalne. Musisz stworzyć wpisy dla serwera WWW, serwera pocztowego oraz aliasy dla łatwiejszego zarządzania. Kluczowe jest, aby pracownicy mogli odwoływać się do zasobów po nazwach, a nie po adresach IP. Dodatkowo musisz skonfigurować router tak, aby znał adres lokalnego serwera DNS i potrafił rozwiązywać nazwy urządzeń brzegowych.

• Uruchomienie usługi DNS na serwerze (Server-PT).
• Dodanie rekordu typu 'A' dla www.firma.local wskazującego na IP serwera HTTP.
• Dodanie rekordu typu 'CNAME' (alias) dla web.firma.local.
• Dodanie rekordu typu 'MX' dla mail.firma.local (priorytet 10).
• Konfiguracja klienta (PC) z adresem serwera DNS i testowanie "nslookup".
• Weryfikacja rozwiązywania nazw przy użyciu polecenia ping.
• Konfiguracja routera jako klienta DNS (ip domain-lookup).
• Stworzenie lokalnej bazy hostów na routerze (ip host).
• Testowanie błędnych zapytań i analiza czasu odpowiedzi.
• Udokumentowanie struktury strefy DNS w sprawozdaniu.
• Sprawdzenie poprawności mapowania nazw w przeglądarce WWW komputera.

Rekord typu A (Address) mapuje canonical name na adres IP i stanowi podstawowy zasób strefy, podczas gdy rekord CNAME tworzy alias wskazujący na inną nazwę kanoniczną, co pozwala na elastyczne abstrakcyjne nazywanie usług bez twardego kodowania adresów IP. Kluczową różnicą jest fakt, że rekord A może współistnieć z innymi rekordami tego samego typu dla domeny, podczas gdy CNAME musi być jedynym rekordem dla danej nazwy (nie można utworzyć innych rekordów dla tej samej nazwy, co byłoby w konflikcie). W profesjonalnych sieciach korporacyjnych plik hosts jest rozwiązaniem tymczasowym i nie skalowalnym, ponieważ wymaga ręcznej aktualizacji na każdej stacji roboczej, nie oferuje mechanizmu TTL ani cache'owania, i generuje problem N do kwadratu przy zarządzaniu wieloma hostami — DNS natomiast zapewnia centralizację, automatyczne rozwiązywanie nazw, cache'owanie po stronie resolverów, oraz obsługę delegacji stref, co czyni go jedynym sensownym rozwiązaniem w infrastrukturze LAN większej niż małe biuro.

Wykład 10 Wysoka dostępność (HA), Load Balancing, Round Robin.

Serwer strony internetowej firmy jest przeciążony w godzinach szczytu, a każda jego awaria powoduje paraliż sprzedaży. Jako administrator musisz wdrożyć rozwiązanie zwiększające dostępność i wydajność. Wykorzystasz do tego urządzenie Server Load Balancer (dostępne w Cisco Packet Tracer), które będzie rozdzielało ruch przychodzący na trzy identyczne serwery WWW. Z perspektywy klienta usługa ma być widoczna pod jednym, wirtualnym adresem IP (VIP), nawet jeśli jeden z serwerów zostanie wyłączony.

• Użycie trzech serwerów (Server-PT) z uruchomioną usługą HTTP.
• Dodanie urządzenia "Server Load Balancer" do topologii.
• Konfiguracja puli serwerów (Cluster) na Load Balancerze.
• Ustawienie wirtualnego adresu IP (VIP) dla klastra.
• Konfiguracja algorytmu rozdzielania ruchu (np. Round Robin).
• Testowanie dostępu do strony WWW z komputera PC przez adres VIP.
• Symulacja awarii jednego serwera (wyłączenie usługi/kabla) i weryfikacja dostępności strony.
• Edycja zawartości index.html na każdym serwerze (np. dodanie "Server 1", "Server 2"), aby widzieć przełączanie.
• Monitorowanie statystyk obciążenia na Load Balancerze.
• Weryfikacja czasu reakcji klastra na zniknięcie węzła.
• Dokumentacja korzyści wynikających ze skalowania poziomego (scale-out).

Skalowanie pionowe (vertical scaling) polega na wymianie lub rozbudowie zasobów pojedynczego serwera (CPU, RAM, dysk), co generuje przestoje przy rozbudowie i tworzy pojedynczy punkt awarii, natomiast skalowanie poziome (horizontal scaling) dodaje kolejne węzły do klastra, umożliwiając rozbudowę bez przestojów i zapewniając redundancję przy awarii jednostki. Mechanizm health check w load balancerze pełni krytyczną rolę — cyklicznie weryfikuje dostępność każdego członka klastra poprzez wysyłanie probe'ów HTTP/TCP i automatycznie wyklucza z puli węzły, które nie odpowiadają w określonym interwale (np. 3 nieudane próby co 5 sekund), co gwarantuje ciągłość usługi dla użytkowników końcowych. W kontekście Cisco Server Load Balancer w Packet Tracer, algorytm Round Robin rozkłada żądania sekwencyjnie, natomiast w środowisku produkcyjnym stosuje się bardziej zaawansowane metody — Least Connections czy IP Hash — uwzględniające stan sesji i aktualne obciążenie węzłów.

Wykład 3 Filtrowanie pakietów, listy kontroli dostępu (Standard vs Extended ACL), bezpieczeństwo warstwy 3 i 4.

Serwerownia firmy stała się celem nieautoryzowanych prób dostępu. Twoim zadaniem jest wdrożenie rygorystycznej polityki bezpieczeństwa na routerze brzegowym, który będzie pełnił rolę zapory ogniowej. Musisz zezwolić na ruch WWW i DNS do serwerów publicznych, ale jednocześnie zablokować wszelkie inne próby połączeń z internetu (np. ICMP, Telnet). Dodatkowo, dział HR nie powinien mieć dostępu do zasobów działu IT wewnątrz sieci lokalnej. Sukcesem będzie udowodnienie, że tylko pożądany ruch przepływa przez router, a pozostałe pakiety są odrzucane i logowane.

• Stworzenie rozszerzonych list kontroli dostępu (Extended ACL).
• Zezwolenie na ruch HTTP (port 80) i HTTPS (port 443) do serwerów WWW.
• Zezwolenie na zapytania DNS (UDP port 53) do serwera nazw.
• Zablokowanie ruchu typu "ping" (ICMP) z sieci zewnętrznej do LAN.
• Zastosowanie ACL na właściwych interfejsach routera (in/out).
• Konfiguracja ACL blokującej komunikację między VLAN 10 (IT) a VLAN 20 (HR).
• Użycie słowa kluczowego "log" w regułach blokujących do monitorowania ataków.
• Weryfikacja działania ACL poleceniem "show access-lists".
• Testowanie blokady za pomocą narzędzia "Ping" oraz "Web Browser" na komputerach.
• Analiza odrzuconych pakietów w trybie symulacji (komunikat "administratively prohibited").
• Zasada "implicit deny" – upewnienie się, że wszystko, co nie jest dozwolone, jest zabronione.

ACL przetwarzają reguły metodą First Match — pierwsza pasująca reguła kończy ewaluację i decyduje o akcji (permit/deny), co wymusza precyzyjne porządkowanie reguł od najbardziej specyficznych do najbardziej ogólnych. Listy ACL na routerze Cisco oferują jedynie statyczne filtrowanie pakietów warstwy 3 i 4 bez stanu sesji — nie śledzą stanu połączeń TCP ani kontekstu applicationalnego, co oznacza, że ruch odpowiedzi (np. dane HTTP wracające do klienta) musi być jawnie dozwolony w obu kierunkach, a router nie potrafi rozpoznać, czy pakiet jest odpowiedzią na wcześniej dozwoloną sesję. Dedykowane urządzenia klasy Firewall (np. ASA, Firepower) implementują Stateful Inspection — analizują pakiety w kontekście sesji, automatycznie pozwalają na ruch powrotny dla ustanowionych połączeń, oferują Deep Packet Inspection (DPI), applcation-layer gateway i intrusion prevention, co czyni je niezastąpionymi w segmencie perimeter defense przed ACL routera.

Wykład 4 Protokoły pocztowe, MX records, uwierzytelnianie użytkowników.

Firma rezygnuje z usług darmowych dostawców poczty na rzecz własnego, wewnętrznego serwera. Twoim zadaniem jest uruchomienie usługi SMTP (wysyłanie) oraz POP3 (odbieranie) na centralnym serwerze usług. Musisz stworzyć konta dla pracowników (np. admin@firma.local, user@firma.local) i skonfigurować aplikacje pocztowe na Laptopie-PT oraz PC-PT tak, aby mogły wymieniać korespondencję. Sukcesem laboratorium będzie przesłanie poprawnie sformatowanej wiadomości e-mail między skrajnymi punktami topologii.

• Uruchomienie usługi Email na serwerze (Server-PT).
• Ustawienie nazwy domeny "firma.local" w ustawieniach serwera poczty.
• Utworzenie minimum 3 kont użytkowników z silnymi hasłami.
• Konfiguracja rekordu MX w serwerze DNS (powiązanie z Zadaniem 03).
• Konfiguracja klienta pocztowego (Mail Browser) na stacjach roboczych.
• Ustawienie właściwych adresów serwerów SMTP i POP3 (mogą być nazwy DNS).
• Wysłanie wiadomości testowej i weryfikacja jej odebrania przez drugiego użytkownika.
• Analiza nagłówków pocztowych w trybie symulacji (PDU details).
• Sprawdzenie logów serwera poczty pod kątem poprawności logowania (auth).
• Weryfikacja blokady wysyłania poczty przy błędnym haśle.
• Przetestowanie załączników (jeśli wspierane przez symulator).

Protokół POP3 domyślnie pobiera wiadomości z serwera i opcjonalnie je usuwa, co oznacza, że po pobraniu na klienta wiadomości nie są dostępne na innych urządzeniach i są podatne na utratę przy awarii lokalnego nośnika — w przeciwieństwie do IMAP, który synchronizuje stan folderów w czasie rzeczywistym między serwerem a wieloma klientami, oferując funkcje takie jak foldery zdalne, flagowanie wiadomości i unified inbox. Rekord MX (Mail Exchange) jest krytyczny dla dostarczania poczty z zewnątrz, ponieważ serwery pocztowe innych domen wyszukują go jako pierwszy krok w procesie delivery — resolver DNS zwraca priorytetowe hosty MX dla domeny docelowej, a SMTP connect próbuje połączyć się z serwerem o najniższym priorytecie, przechodząc do kolejnych w przypadku niedostępności. Bez poprawnego rekordu MX poczta przychodząca z Internetu zostanie odrzucona z błędem "MX not found" lub "Sender verify failed", co skutuje communication blackout dla firmy.

Wykład 5 Systemy plików sieciowych, backup konfiguracji, transfer plików.

Polityka bezpieczeństwa firmy wymaga regularnego tworzenia kopii zapasowych konfiguracji wszystkich routerów i przełączników. Twoim zadaniem jest uruchomienie centralnego serwera FTP dla dokumentacji oraz serwera TFTP dla szybkich zrzutów konfiguracji ("running-config"). Musisz zapewnić, że każde urządzenie sieciowe potrafi przesłać swój plik konfiguracyjny do serwera, a w razie awarii administrator może go szybko przywrócić z kopii sieciowej. Dodatkowo skonfiguruj autoryzowany dostęp do serwera FTP dla pracowników IT.

• Uruchomienie usług FTP i TFTP na serwerze dedykowanym.
• Stworzenie konta użytkownika FTP o nazwie "backup_user" z uprawnieniami do zapisu.
• Wykonanie kopii zapasowej konfiguracji Routera (copy running-config tftp:).
• Wykonanie kopii zapasowej konfiguracji Switcha (copy running-config ftp:).
• Weryfikacja obecności plików na serwerze (lista plików w GUI Serwera).
• Przeprowadzenie testu przywracania (skasowanie startup-config i restart urządzenia).
• Udokumentowanie procesu uwierzytelniania FTP w trybie symulacji.
• Sprawdzenie limitów transferu i czasów oczekiwania (timeout).
• Zabezpieczenie serwera FTP przed dostępem z sieci gości za pomocą ACL.
• Użycie polecenia "archive" na routerze dla automatyzacji backupu (jeśli wspierane).
• Analiza różnic między protokołem TFTP a FTP w kontekście niezawodności.

Backup konfiguracji urządzeń sieciowych stanowi fundament procedur Disaster Recovery (DR) — w przypadku awarii sprzętowej lub corrupt firmware, gotowy config pozwala na szybkie przywrócenie usług bez rekonfiguracji od zera, co minimalizuje MTTR (Mean Time To Repair) i straty biznesowe. TFTP w sieciach produkcyjnych stosuje się głównie lokalnie ze względu na brak uwierzytelniania, szyfrowania i kontroli dostępu — jest to protokół bezstanowy, który przesyła pliki w plaintext, co czyni go podatnym na sniffing i man-in-the-middle, a w przypadku transferu wielu konfiguracji naraz nie ma mechanizmu wznawiania ani hash verification. W praktyce Cisco produkcyjnej, TFTP służy do prostych scenariuszy lokalnych (np. backup na lokalny serwer w serverowni lub na workstation admina), natomiast pełne rozwiązania backupowe wykorzystują SCP/SFTP z autentykacją kluczami lub FTP z TLS, oferujące szyfrowanie transferu, autentykację użytkowników i audit trail. Rekomendowaną praktyką jest przechowywanie co najmniej 3 wersji konfiguracji (ostatnia, poprzednia, przed-ostatnia) z datami w nazwie pliku, przechowywanych na wydzielonym serwerze backup z polityką retention.

Wykład 8 Zarządzanie zdalne, utwardzanie VTY, kryptografia klucza publicznego.

Zarządzanie urządzeniami sieciowymi przez port konsolowy jest niepraktyczne w rozbudowanej infrastrukturze. Administratorzy muszą mieć dostęp do CLI z dowolnego miejsca w sieci biurowej. Jednak protokół Telnet przesyła hasła otwartym tekstem, co jest niedopuszczalne. Twoim zadaniem jest całkowite wyłączenie protokołu Telnet i skonfigurowanie usługi SSH (Secure Shell) w wersji 2 na wszystkich routerach i przełącznikach. Musisz wygenerować klucze RSA o odpowiedniej długości i zapewnić, że tylko autoryzowani użytkownicy mogą się zalogować.

• Ustawienie nazwy hosta oraz domeny (ip domain-name) na routerze i switchu.
• Generowanie kluczy kryptograficznych poleceniem "crypto key generate rsa" (min. 1024 bity).
• Włączenie serwera SSH w wersji 2 (ip ssh version 2).
• Utworzenie lokalnego użytkownika administratora z hasłem typu secret.
• Konfiguracja linii VTY do akceptowania tylko połączeń SSH (transport input ssh).
• Ustawienie logowania lokalnego (login local) na liniach VTY.
• Testowanie połączenia SSH z narzędzia "SSH Client" na komputerze PC.
• Weryfikacja blokady połączeń typu Telnet.
• Udokumentowanie w sprawozdaniu zrzutu z polecenia "show ssh".
• Ustawienie czasu bezczynności (exec-timeout) dla sesji zdalnych.
• Implementacja blokady po kilku błędnych próbach logowania (jeśli wspierane).

SSH zapewnia bezpieczny tunel komunikacyjny poprzez szyfrowanie całej sesji (w tym login/password payload) algorytmami symetrycznymi (AES, 3DES) i asymetrycznymi (RSA/DSA), autentykację serwera za pomocą host key, oraz opcjonalną autentykację klienta kluczami publicznymi — w przeciwieństwie do Telnet, który przesyła dane tekstem jawnym (plaintext), co oznacza, że każdy pakiet przechwycony w snifferze ujawnia pełne poświadczenia i konfigurację. Pozostawienie otwartego dostępu Telnet w sieci publicznej (np. przez bramę WAN) niesie ryzyko kradzieży poświadczeń poprzez ARP spoofing lub przechwycenie pakietów na przełączniku niezarządzanym, a także umożliwia ataki typu man-in-the-middle na infrastrukturę, gdzie atakujący może przejąć sesję i wykonać polecenia konfiguracyjne na urządzeniu bez wiedzy admina. W najlepszych praktykach Cisco, Telnet powinien być bezwzględnie wyłączony na wszystkich interfejsach dostępnych z zewnątrz (line vty 0 4), a dostęp realizowany wyłącznie przez SSH z autentykacją lokalną lub RADIUS/TACACS i listami ACL ograniczającymi źródłowe sieci IP.

Wykład 6 Monitorowanie wydajności, logowanie zdarzeń, MIB i OID.

Utrzymanie stabilności usług wymaga ciągłego nadzoru nad obciążeniem procesorów i stanem interfejsów. Twoim zadaniem jest wdrożenie systemu monitorowania opartego na protokole SNMP oraz centralnego zbierania logów przez Syslog. Musisz skonfigurować router tak, aby wysyłał powiadomienia (Traps) o poważnych błędach do serwera NMS oraz przesyłał wszystkie komunikaty z konsoli do centralnego archiwum logów. Dzięki temu administrator będzie mógł analizować historię awarii nawet po restarcie urządzenia.

• Uruchomienie usług "Syslog" oraz "SNMP" na serwerze monitorującym.
• Konfiguracja routera do wysyłania logów (logging host).
• Ustawienie poziomu logowania na "informational" (level 6).
• Konfiguracja protokołu SNMP na routerze (read-only community string).
• Udzielenie zgody na wysyłanie trapów SNMP do serwera.
• Symulacja awarii (shutdown interfejsu) i weryfikacja wpisu w logach na serwerze.
• Monitorowanie obciążenia łącza za pomocą wbudowanego narzędzia SNMP na serwerze.
• Użycie polecenia "show logging" na routerze i porównanie z zawartością serwera.
• Analiza komunikatów "Trap" (OID) przechwyconych przez sniffer.
• Ustawienie lokalizacji i kontaktu dla agenta SNMP na routerze.
• Weryfikacja działania mechanizmu przy przeciążeniu (generowanie dużego ruchu).

Monitoring pasywny (Syslog) polega na odbieraniu powiadomień z urządzeń — logi są pushowane automatycznie przy zajściu zdarzenia, co generuje dużą objętość danych i wymaga centralnego agregatora (np. Splunk, ELK), natomiast monitoring aktywny (SNMP polling) wymaga odpytywania urządzeń przez NMS w interwałach (co 5 min), co pozwala na kumulatywne zbieranie metryk (CPU, RAM, interface counters) i trend analysis over time. SNMP oferuje standardowe MIB-y umożliwiające uniformowe zbieranie metryk across vendors, co czyni go de facto standardem w network monitoring. Spełnienie warunków SLA (np. availability 99.9%) wymaga ciągłego monitoringu dostępności i reaktywności — NMS generuje alerty przy przekroczeniu progów (np. CPU > 80% przez 5 min), a historyczne dane pozwalają na wykazanie, że usługa spełniała warunki umowy (uptime percentage), co jest podstawą roszczeń klientskich i kar umownych. Rekomendowaną praktyką jest kombinacja obu podejść: Syslog dla krytycznych zdarzeń (link down, auth failure) i SNMP dla metryk performance, z dashboardami w Grafana/Zabbix.

Wykład 10 Redundancja brzegowa, protokoły FHRP, wirtualne IP.

Awaria głównego routera brzegowego w Twojej firmie powoduje utratę łączności z Internetem dla wszystkich pracowników. Aby uniknąć tego pojedynczego punktu awarii (SPOF), musisz wdrożyć mechanizm redundancji bramy domyślnej przy użyciu protokołu HSRP (Hot Standby Router Protocol). Skonfigurujesz dwa routery działające w jednym zespole, które wspólnie będą obsługiwać jeden wirtualny adres IP. W przypadku awarii routera głównego, router zapasowy automatycznie przejmie jego rolę w czasie niezauważalnym dla użytkowników.

• Użycie dwóch routerów 2911 połączonych tym samym VLANem od strony LAN.
• Ustawienie adresu fizycznego IP na każdym routerze (np. .1 i .2).
• Konfiguracja grupy HSRP (standby 1) na obu routerach.
• Ustawienie wirtualnego adresu IP (VIP: .254) dla grupy.
• Konfiguracja priorytetu (priority) dla routera głównego w celu wymuszenia roli Active.
• Włączenie mechanizmu "preempt" umożliwiającego powrót do roli Active po naprawie.
• Konfiguracja komputerów PC tak, aby ich bramą domyślną był adres VIP (.254).
• Weryfikacja statusu poleceniem "show standby brief".
• Testowanie failover (shutdown interfejsu Active) podczas trwającego pingu do internetu.
• Analiza komunikatów "Hello" protokołu HSRP w trybie symulacji.
• Dokumentacja czasu przełączenia (liczba utraconych pakietów ping).

Koncept Virtual IP (VIP) w protokole HSRP polega na przypisaniu wirtualnego adresu IP i MAC do grupy standby, który jest aktywny na urządzeniu active router i przenoszony w przypadku awarii na router standby bez zmiany konfiguracji na stacjach klienckich — brama domyślna wstępnie skonfigurowana na każdym hoście pozostaje niezmieniona. Z perspektywy ciągłości biznesowej, użytkownicy końcowi nie muszą modyfikować swojej konfiguracji IP/gateway w momencie awarii fizycznego routera, ponieważ ruch jest przejmowany przez VIP działający na standby router — oznacza to zero-touch recovery i brak przestojów warstwy 3 dla aplikacji biznesowych. W kontekście HSRP Cisco, mechanizm preempt pozwala routerowi o wyższym priorytecie na przejęcie roli active po resecie lub rekonwalescencji, a hello timer (domyślnie co 3 sekundy) zapewnia szybkie wykrycie awarii (holdtime = 10 sekund), co w praktyce oznacza przełączenie w ciągu około 10-15 sekund — wystarczające dla większości aplikacji, ale nie dla time-sensitive VoIP, gdzie rekomendowany jest HSRP z track interface i reduced hold timer.

Wykład 7 Sieci bezprzewodowe, standard 802.1X, uwierzytelnianie promieniowe (RADIUS).

Firma rezygnuje z prostych haseł współdzielonych (PSK) w sieci Wi-Fi na rzecz uwierzytelniania opartego na kontach użytkowników. Twoim zadaniem jest konfiguracja kontrolera WLC (Wireless LAN Controller) oraz serwera RADIUS. Pracownicy działu HR mają logować się do osobnej sieci bezprzewodowej przy użyciu swoich indywidualnych poświadczeń. Musisz zapewnić, że tylko autoryzowani użytkownicy z bazy danych serwera RADIUS otrzymają dostęp do zasobów sieciowych przez punkt dostępowy Lightweight AP.

• Dodanie kontrolera WLC 2504 oraz serwera (RADIUS-PT) do topologii.
• Konfiguracja serwera RADIUS (Service: AAA) i dodanie klienta WLC (Shared Secret).
• Stworzenie bazy użytkowników na serwerze RADIUS.
• Konfiguracja WLAN na kontrolerze WLC z zabezpieczeniem WPA2-Enterprise.
• Przypisanie serwera RADIUS jako Authentication Server dla danego WLAN.
• Przyłączenie Lightweight AP do kontrolera i rozgłaszanie SSID.
• Konfiguracja Laptopa-PT do połączenia z siecią Wi-Fi przy użyciu loginu i hasła.
• Weryfikacja procesu uwierzytelniania w logach serwera RADIUS.
• Sprawdzenie statusu klienta w panelu kontrolnym WLC (GUI).
• Testowanie blokady dostępu dla nieprawidłowych poświadczeń.
• Udokumentowanie korzyści z centralnego zarządzania kluczami szyfrującymi.

WPA2-Enterprise wykorzystuje autentykację RADIUS (802.1X/EAP) z certyfikatami lub kartami Smart Card, gdzie każdy użytkownik otrzymuje unikalne credentials, co pozwala na accountability i revoke dostępu bez zmiany PSK na wszystkich urządzeniach — w przeciwieństwie do WPA2-PSK, gdzie wspólny pre-shared key jest współdzielony między wszystkimi użytkownikami i jeśli zostanie skompromitowany, attacker uzyskuje dostęp do całej sieci bez możliwości identyfikacji sprawcy. Protokół EAP (Extensible Authentication Protocol) w procesie negocjacji połączenia bezprzewodowego definiuje sekwencję: supplicant (klient WiFi) inicjuje 802.1X, switch AP przekazuje żądanie do serwera RADIUS, EAP method (np. PEAP, TTLS) negocjuje autentykację, a po success serwer RADIUS wysyła klucze sesyjne (PMK) do AP i klienta, które służą do tworzenia pary 4-way handshake dla encryption. W sieciach korporacyjnych ze sprzętem Cisco, rekomendowana konfiguracja obejmuje WPA2-Enterprise z serwerem RADIUS (np. Cisco ISE, FreeRADIUS) i certyfikatami EAP-TLS dla najwyższego poziomu bezpieczeństwa.

Wykład 4 Komunikacja IP, protokół SCCP/SIP, Voice VLAN.

Wdrażasz system telefonii IP w nowym biurze. Twoim zadaniem jest konfiguracja routera brzegowego jako centrali telefonicznej (Cisco Unified Communications Manager Express). Musisz wydzielić osobny VLAN dla ruchu głosowego, skonfigurować usługę DHCP dla telefonów (opcja 150) oraz przypisać numery wewnętrzne do aparatów IP Phone. Sukcesem będzie realizacja połączenia głosowego między dwoma telefonami i weryfikacja poprawności wyświetlania numerów na ekranach urządzeń.

• Użycie routera 2811 (wspiera Voice) i przełącznika 2960.
• Konfiguracja Voice VLAN na portach switcha połączonych z telefonami.
• Ustawienie DHCP Pool z opcją "option 150 ip [adres_routera]".
• Włączenie usługi "telephony-service" na routerze.
• Zdefiniowanie maksymalnej liczby telefonów i linii (max-dn, max-ephones).
• Stworzenie wpisów "ephone-dn" z numerami telefonów (np. 101, 102).
• Powiązanie fizycznych telefonów (ephone) z numerami linii (button).
• Zasilanie telefonów (Power Adapter lub PoE w switchu).
• Testowanie wybierania numeru i weryfikacja statusu "Connected".
• Analiza ruchu RTP w trybie symulacji (pakiety głosowe).
• Dokumentacja znaczenia Voice VLAN dla jakości rozmów.

Ruch głosowy VoIP jest niezwykle wrażliwy na opóźnienia i jitter — każda millisekunda ma znaczenie dla naturalności konwersacji, a standardy ITU-T G.114 definiują maksymalne opóźnienie 150ms one-way dla satysfakcjonującej jakości. Izolacja ruchu głosowego w dedykowanym Voice VLAN (np. VLAN 100) w połączeniu z mechanizmami QoS na switchu (np. CoS 5 dla VoIP) zapewnia, że pakiety głosowe są obsługiwane z najwyższym priorytetem i nie są kolejkowane za paketami danych intensywnie obciążającymi łącze. Gdy łącze zostanie nasycone ruchem HTTP/Bulk data bez QoS, bufory kolejkowania przepełniają się, pakiety głosowe są odrzucane lub opóźniane, co skutkuje charakterystycznymi artefaktami audio (przeskoki, echo) i nieczytelnością rozmowy. W architekturze Cisco Voice, konfiguracja Auto QoS lub ręczna konfiguracja priority queue na interfejsach access-switchy stanowi obowiązkowy element wdrożenia VoIP w środowisku produkcyjnym.

Wykład 8-10 Przemysł 4.0, urządzenia brzegowe IoT, monitorowanie środowiskowe.

Serwerownia firmy wymaga stałego monitoringu temperatury i wilgotności. Twoim zadaniem jest stworzenie inteligentnego systemu nadzoru opartego na urządzeniach IoT. Musisz połączyć czujniki temperatury i wilgotności do bramy IoT (Home Gateway), a następnie skonfigurować algorytmy, które automatycznie uruchomią klimatyzator lub wentylator po przekroczeniu krytycznych wartości. Całość systemu musi być dostępna dla administratora przez panel WWW, umożliwiając zdalny podgląd stanu serwerowni w czasie rzeczywistym.

• Dodanie Home Gateway (IoT Gateway) do topologii.
• Dodanie czujników: Temperature Sensor, Humidity Sensor.
• Dodanie elementów wykonawczych: Fan (Wentylator) lub AC (Klimatyzator).
• Połączenie urządzeń IoT do bramy (bezprzewodowo lub kablem IoT).
• Konfiguracja serwera IoT na bramie.
• Zalogowanie się do panelu kontrolnego IoT z tabletu lub PC (adres IP bramy).
• Stworzenie reguły (Condition): "Jeśli temperature > 25, to włącz Fan".
• Weryfikacja działania automatyki przez podgrzanie czujnika (Environment Monitor).
• Dokumentacja odczytów na wykresach w panelu IoT.
• Analiza protokołu komunikacji urządzeń IoT (np. MQTT lub HTTP).
• Zabezpieczenie dostępu do bramy IoT silnym hasłem.

Automatyzacja IoT w infrastrukturze krytycznej przynosi korzyści w postaci predictive maintenance (prognozowanie awarii na podstawie metryk sensorowych), real-time monitoring parametrów środowiskowych (temperatura, wilgotność, zużycie energii), oraz automatycznej reakcji (np. wyłączenie klimatyzacji przy przekroczeniu progu temperaturowego w serwerowni) bez interwencji człowieka. Z drugiej strony, podłączenie urządzeń IoT bez izolacji do sieci korporacyjnej stanowi poważne zagrożenie bezpieczeństwa — urządzenia te często mają słabe zabezpieczenia (default credentials, brak szyfrowania), są podatne na firmware vulnerabilities, i w przypadku kompromitacji mogą stanowić wektor lateral movement do sieci wewnętrznej (np. smart termometr w serwerowni jako punkt wejścia dla atakującego). Best practice w Cisco architecture zakłada izolację IoT w dedykowanym VLAN z firewall'em lub ACL filtrującym dostęp do sieci zarządzania, oraz monitoring urządzeń IoT przez NMS z alertami na nowe nieautoryzowane MAC adresy (np. IEEE 802.1X fails for IoT, wtedy MAC Authentication Bypass z policies).

Wykład 1 Architektura sieciowa, tunele L3, wirtualizacja łącz.

Firma otworzyła nowy oddział w innym mieście. Oba oddziały mają dostęp do Internetu, ale muszą wymieniać dane w sposób transparentny (tak jakby były w jednej sieci lokalnej). Twoim zadaniem jest stworzenie wirtualnego tunelu GRE (Generic Routing Encapsulation) między routerami brzegowymi obu oddziałów. Tunel musi umożliwić przesyłanie ruchu z sieci LAN1 do sieci LAN2 przez niezaufaną sieć publiczną (Internet), wykorzystując routing statyczny skierowany do interfejsu tunelowego.

• Użycie dwóch routerów połączonych przez symulowaną chmurę Internetu.
• Adresacja interfejsów publicznych (WAN) i prywatnych (LAN).
• Stworzenie wirtualnego interfejsu Tunnel 0 na obu routerach.
• Ustawienie źródła (tunnel source) i celu (tunnel destination) tunelu.
• Nadanie adresacji IP dla końcówek tunelu (np. 10.255.255.1 i .2).
• Konfiguracja routingu statycznego dla sieci zdalnej przez tunel.
• Weryfikacja łączności (ping) między komputerami w obu oddziałach.
• Użycie polecenia "traceroute" i analiza ścieżki (brak przeskoków pośrednich z Internetu).
• Analiza enkapsulacji pakietu GRE (dodatkowy nagłówek IP).
• Udokumentowanie MTU tunelu i problemu fragmentacji pakietów.
• Weryfikacja statusu tunelu poleceniem "show ip interface brief".

Interfejs fizyczny tunelu GRE jest reprezentowany przez wirtualny interfejs Tunnel, który enkapsuluje pakiety wewnątrz nagłówka IP z protokołem GRE (IP protocol 47), natomiast interfejs tunelowy logicznie działa jak interfejs warstwy 3 — ma własny adres IP, maskę i protokół routingu, co pozwala na traktowanie tunelu jako medium transportowego dla protokołów routingu. GRE jest szczególnie przydatny do przesyłania pakietów multicast w sieciach, gdzie protokoły routingu (np. OSPF, EIGRP) używają multicast do neighbor discovery i wymiany LSA — w standardowym podejściu router enkapsuluje multicast packet w unicast GRE i przesyła do drugiego końca tunelu (co jest widoczne w tabeli routingu i działa z OSPF w trybie Point-to-Point GRE). W sieciach produkcyjnych, GRE jest często używany w połączeniu z IPsec (GRE over IPsec) dla szyfrowania ruchu przez niezaufane sieci — nagłówek GRE jest dodawany jako pierwszy (dla obsługi multicast), a następnie całość jest szyfrowana przez IPsec ESP/AES, co zapewnia zarówno elastyczność (obsługa protokołów warstwy 3, multicast) jak i bezpieczeństwo (szyfrowanie payloadu).

Wykład 10 Zarządzanie pasmem, mechanizmy QoS, klasyfikacja i znakowanie (DSCP).

Łącze internetowe firmy jest często zapychane przez pobieranie dużych plików, co powoduje rwanie rozmów VoIP oraz opóźnienia w systemach terminalowych. Twoim zadaniem jest wdrożenie mechanizmu jakości usług (QoS) na routerze wyjściowym. Musisz sklasyfikować ruch głosowy jako krytyczny, przypisać mu najwyższy priorytet i zagwarantować minimalne pasmo, natomiast ruch typu HTTP/FTP ograniczyć w momentach przeciążenia. Dzięki temu usługi czasu rzeczywistego będą działać płynnie nawet przy pełnym obciążeniu łącza.

• Stworzenie class-map dla różnych typów ruchu (Voice, Data).
• Klasyfikacja ruchu Voice na podstawie ACL (porty RTP) lub typu protokołu.
• Stworzenie policy-map i przypisanie akcji (priority, bandwidth).
• Zastosowanie polityki QoS na interfejsie wychodzącym (service-policy output).
• Znakowanie pakietów wartościami DSCP (np. EF dla głosu).
• Weryfikacja działania QoS poleceniem "show policy-map interface".
• Generowanie dużego ruchu (np. FTP transfer) i jednoczesny test pingu do telefonu.
• Analiza liczników "matches" i "drops" w statystykach polityki.
• Udokumentowanie struktury policy-map w sprawozdaniu.
• Sprawdzenie wpływu QoS na opóźnienia (jitter) – obserwacja w trybie symulacji.
• Opisanie mechanizmu Low Latency Queuing (LLQ).

Opóźnienie (latency) to czas propagacji pakietu od nadawcy do odbiorcy, mierzony w milisekundach, jitter to zmienność tego opóźnienia między kolejnymi pakietami (np. pakiet A ma 20ms, pakiet B ma 50ms = 30ms jitter), a utrata pakietów (packet loss) to procent pakietów, które nie dotarły do celu — w kontekście VoIP, utrata powyżej 1% powoduje zauważalne artefakty audio. W sieciach hybrydowych (głos + dane), mechanizmy QoS są niezbędne, ponieważ ruch danych (HTTP, FTP, SMTP) jest tolerancyjny na opóźnienia i jitter, ale bursty traffic (np. backup over WAN) potrafi wygenerować kolejki, które opóźniają pakiety VoIP powyżej akceptowalnych progów — bez QoS, VoIP jest traktowany jako Best Effort (DSCP 0), co oznacza, że przegrywa konkurencję o bandwidth z każdym innym flow. Cisco QoS model (modular QoS CLI — MQC) pozwala na klasyfikację ruchu (match by ACL, DSCP, CoS), tworzenie kolejki priorytetowej (priority queue) dla VoIP (np. DSCP EF — Expedited Forwarding dla ruchu RTP), i konfigurację gwarantowanego pasma dla klas biznesowych (voice, video, critical data) — w rezultacie VoIP ma gwarantowane pasmo nawet przy pełnym obciążeniu łącza.