Wykład 9: Zdalny dostęp i bezpieczne zarządzanie infrastrukturą sieciową w kampusie

Bezpieczeństwo płaszczyzny zarządzania (Management Plane) to fundament odporności całej infrastruktury teleinformatycznej kampusu akademickiego. Nawet najbardziej zaawansowane mechanizmy redundancji i filtracji w płaszczyźnie danych stają się bezużyteczne w chwili przejęcia kontroli nad przełącznikami i routerami przez nieuprawniony podmiot.

Nowoczesny paradygmat inżynierski wymaga rezygnacji z przestarzałych protokołów nieszyfrowanych, separacji ruchu administracyjnego w dedykowanych sieciach poza pasmem (OOBM), wdrożenia kryptograficznego dostępu SSHv2, tuneli VPN oraz centralizacji kontroli w oparciu o architekturę AAA z uwierzytelnianiem wieloskładnikowym MFA.

W architekturze nowoczesnego kampusu studenckiego i badawczego punkty dostępowe, przełączniki dystrybucyjne oraz rdzeniowe routery przetwarzają terabajty danych na sekundę. Utrata integralności urządzeń brzegowych stwarza ryzyko podsłuchu transmisji jednostek naukowych, modyfikacji tablic routingu oraz paraliżu systemów dziekanatowych. Z tego względu zagadnienia bezpiecznego dostępu administracyjnego stanowią autonomiczną dziedzinę inżynierii sieciowej, opartą na ścisłych procedurach technicznych i formalnych modelach zaufania.

Skróty użyte w tym slajdzie:
SSH (Secure Shell) - Kryptograficzny protokół sieciowy służący do bezpiecznego zdalnego logowania i zarządzania (RFC 4253).
VPN (Virtual Private Network) - Wirtualna sieć prywatna tworząca szyfrowany tunel komunikacyjny przez niezaufaną sieć publiczną.
AAA (Authentication, Authorization, Accounting) - Architektura bezpieczeństwa obejmująca uwierzytelnianie, autoryzację i rejestrowanie zdarzeń.
OOBM (Out-of-Band Management) - Dedykowana, odizolowana fizycznie sieć zarządzająca urządzeniami infrastruktury.
NMS (Network Management System) - Centralny system monitorowania, inwentaryzacji i zarządzania infrastrukturą teleinformatyczną.

Agenda wykładu została ułożona w sposób odzwierciedlający kolejne warstwy zabezpieczeń i metody dostępu administracyjnego: od fizycznego portu konsoli i projektowania odizolowanych sieci OOB, przez zdalny dostęp tekstowy SSHv2, tunele i serwery skokowe Bastion Host.

Druga część wykładu poświęcona jest bezpiecznym połączeniom zewnętrznym VPN (IPsec, SSL/TLS, WireGuard), architekturze AAA ze szczegółowym porównaniem protokołów RADIUS i TACACS+, integracji z bazami katalogowymi AD/LDAP, tokenom sprzętowym zgodnym z FIDO2 oraz procedurom odzyskiwania po poważnych awariach (Disaster Recovery).

Struktura prezentowanego materiału odpowiada cyklowi życia operacji administratorskich w sieci wielobudynkowej. Rozpoczyna się od bezpośredniego kontaktu fizycznego z urządzeniem w serwerowni, przechodzi przez mechanizmy zdalnego sterowania w sieci lokalnej i rozległej, a kończy na zautomatyzowanym nadzorze telemetrycznym i planach ciągłości działania. Takie ujęcie pozwala studentom zrozumieć współzależność pomiędzy warstwą fizyczną okablowania a zaawansowanymi protokołami kryptograficznymi.

Skróty użyte w tym slajdzie:
VTY (Virtual Teletype) - Wirtualne linie terminalowe w systemach Cisco służące do obsługi sesji zdalnych SSH/Telnet.
RADIUS (Remote Authentication Dial-In User Service) - Standardowy protokół AAA (RFC 2865) wykorzystujący transport UDP.
TACACS+ (Terminal Access Controller Access-Control System Plus) - Protokół klasy AAA (RFC 8907) firmy Cisco oferujący szyfrowanie ciała pakietów w sesji TCP 49.
MFA (Multi-Factor Authentication) - Uwierzytelnianie wieloskładnikowe wymagające co najmniej dwóch niezależnych metod weryfikacji tożsamości.
PAM (Privileged Access Management) - Zintegrowane rozwiązania do nadzoru i rejestracji uprzywilejowanych sesji administratorskich.

Podstawą standaryzacji zarządzania i kontroli dostępu są specyfikacje IETF (RFC 4253 dla SSHv2, RFC 8907 dla TACACS+, RFC 2865 dla RADIUS, RFC 4301 dla IPsec, RFC 7296 dla IKEv2 oraz RFC 6347 dla DTLS) oraz wytyczne amerykańskiego instytutu NIST (seria SP 800).

W środowisku uczelnianym wdrożenia muszą spełniać wymagania krajowych regulacji prawnych: Rozporządzenia w sprawie Krajowych Ram Interoperacyjności (KRI, Dz.U. 2017 poz. 2247), Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC) oraz normy PN-EN ISO/IEC 27001, które wymagają szyfrowania ruchu zarządczego i zakazują transmisji haseł otwartym tekstem.

Z punktu widzenia przyszłego inżyniera sieciowego znajomość dokumentów IETF RFC oraz standardów NIST nie jest jedynie wymogiem teoretycznym, lecz praktycznym narzędziem weryfikacji sprzętu i oprogramowania. Dokumenty te precyzują minimalne długości kluczy kryptograficznych, dopuszczalne algorytmy wymiany klucza oraz formaty nagłówków pakietów kontrolnych. W projektach finansowanych ze środków publicznych odwołanie do konkretnych norm stanowi warunek konieczny w procedurach przetargowych i odbiorach technicznych infrastruktury.

Skróty użyte w tym slajdzie:
IETF (Internet Engineering Task Force) - Główny komitet standaryzacyjny odpowiedzialny za specyfikacje techniczne protokołów internetowych.
RFC (Request for Comments) - Dokument techniczny zawierający oficjalną specyfikację protokołu publikowany przez IETF.
NIST (National Institute of Standards and Technology) - Amerykański instytut normalizacyjny publikujący wytyczne kryptograficzne i standardy bezpieczeństwa SP 800.
KRI (Krajowe Ramy Interoperacyjności) - Rozporządzenie Rady Ministrów określające minimalne wymagania dla systemów teleinformatycznych podmiotów publicznych.

Płaszczyzna zarządzania (Management Plane) obejmuje wszystkie protokoły i kanały komunikacyjne wykorzystywane przez inżynierów do konfiguracji, monitorowania i aktualizacji oprogramowania urządzeń sieciowych (SSH, HTTPS, SNMPv3, Syslog, NTP, NETCONF/RESTCONF).

W rozległym kampusie akademickim, gdzie sieć fizyczna dociera do setek publicznie dostępnych sal wykładowych i domów studenckich, płaszczyzna zarządzania jest narażona na nieustanne próby skanowania i ataków brute-force, co wymusza jej ścisłe odizolowanie od ruchu użytkowników.

Izolacja płaszczyzny zarządzania zapobiega sytuacjom, w których błąd użytkownika, zainfekowana stacja robocza w laboratorium komputerowym lub atak wolumetryczny zalewający bufor przełącznika uniemożliwiają inżynierowi zalogowanie się do urządzenia. Nowoczesne systemy operacyjne przełączników realizują ten postulat poprzez mechanizm Control Plane Policing (CoPP), który w sposób sprzętowy limituje liczbę pakietów kierowanych do procesora przełącznika, chroniąc go przed wyczerpaniem zasobów obliczeniowych.

Skróty użyte w tym slajdzie:
Management Plane - Płaszczyzna zarządzania odpowiedzialna za administrację, konfigurację i nadzór nad urządzeniem.
Control Plane - Płaszczyzna sterowania realizująca wymianę informacji o topologii i protokołach routingu.
Data Plane (Forwarding Plane) - Płaszczyzna danych odpowiedzialna za sprzętowe przekazywanie pakietów i ramek.

Wektory ataków na urządzenia sieciowe obejmują podsłuch pakietów (Sniffing) w sieciach współdzielonych, ataki Man-in-the-Middle (MitM) z fałszowaniem tożsamości bramy, ataki słownikowe na konta uprzywilejowane oraz wykorzystanie podatności w niezałatanych wersjach systemów operacyjnych.

Skutkiem udanego przełamania zabezpieczeń płaszczyzny zarządzania może być modyfikacja konfiguracji VLAN, zmiana tras OSPF, wyłączenie zasilania PoE dla kamer monitoringu lub zainstalowanie zmodyfikowanego obrazu oprogramowania układowego (Backdoor Firmware).

Szczególnie niebezpiecznym scenariuszem w środowisku akademickim jest przejęcie uprawnień administracyjnych w wyniku podsłuchu haseł przesyłanych protokołami nieszyfrowanymi w sieciach akademickich. Narzędzia takie jak Ettercap czy Wireshark umożliwiają przechwycenie nieszyfrowanych poświadczeń w kilka sekund. Uzyskany w ten sposób dostęp pozwala intruzowi na rekonfigurację portów typu trunk, utworzenie nieautoryzowanych tuneli transmisyjnych i trwałe ukrycie obecności w infrastrukturze.

Skróty użyte w tym slajdzie:
Brute-Force (Brute-Force Attack) - Atak polegający na automatycznym odgadywaniu haseł dostępowych.
Credential Stuffing (Credential Stuffing) - Atak wykorzystujący skradzione bazy loginów i haseł do masowego testowania dostępu do innych serwisów.
MitM (Man-in-the-Middle) - Atak polegający na przechwytywaniu i podsłuchiwaniu nieszyfrowanego ruchu administracyjnego.

Zarządzanie w paśmie (In-Band Management) polega na przesyłaniu ruchu administracyjnego przez tę samą fizyczną infrastrukturę przełączników i routerów, którą przesyłany jest ruch produkcyjny użytkowników, z logiczną separacją w dedykowanym VLANie zarządczym.

Zaletą tego rozwiązania jest niski koszt (brak dodatkowego okablowania), lecz główną wadą - podatność na zatory i awarie: w przypadku burzy rozgłoszeniowej L2 lub błędu w tablicy routingu inżynier traci łączność z przełącznikiem i nie może wdrożyć działań naprawczych.

Mimo oczywistych wad, zarządzanie w paśmie pozostaje powszechnie stosowane w mniejszych sieciach oraz na poziomie przełączników dostępowych na poszczególnych piętrach budynków ze względów ekonomicznych. Właściwa implementacja tej metody wymaga rygorystycznego wdrożenia list kontroli dostępu (ACL) przypisanych do interfejsów wirtualnych SVI, odizolowania VLAN-u zarządczego od ruchu stacji roboczych oraz przypisania najwyższego priorytetu pakietom kontrolnym w kolejkach QoS (DiffServ EF lub CS6).

Skróty użyte w tym slajdzie:
In-Band (In-Band Management) - Zarządzanie urządzeniami za pośrednictwem tej samej sieci logicznej i fizycznej, która przenosi ruch produkcyjny.
VLAN (Virtual Local Area Network) - Logicznie wydzielona sieć w warstwie 2 służąca do separacji ruchu administracyjnego.

Zarządzanie poza pasmem (Out-of-Band Management - OOBM) zakłada utworzenie niezależnej, fizycznie wydzielonej sieci kablowej, dedykowanej wyłącznie do komunikacji z portami zarządzającymi urządzeń (porty OOB Ethernet oraz porty konsolowe RS-232/USB).

Sieć OOB posiada własne, niezależne przełączniki dostępowe, odrębne trasy kablowe oraz zapory sieciowe. Zapewnia to administratorom dostęp do urządzeń również przy całkowitej awarii sieci produkcyjnej.

Budowa infrastruktury Out-of-Band wiąże się ze znacznymi nakładami finansowymi, gdyż wymaga położenia niezależnych tras kablowych kategorii 6A lub światłowodów oraz zakupu odrębnych przełączników zarządzających. Wydatek ten jest jednak rekompensowany przez drastyczne skrócenie czasu usuwania awarii (MTTR). Inżynier ma gwarancję dotarcia do konfiguracji przełącznika rdzeniowego nawet wówczas, gdy błędna konfiguracja drzewa STP doprowadziła do całkowitej blokady ruchu produkcyjnego.

Skróty użyte w tym slajdzie:
OOB (Out-of-Band) - Podejście architektoniczne polegające na separacji fizycznej sieci zarządzającej od sieci użytkowników.
Dedicated NIC (Dedicated Management Port) - Fizyczny port sieciowy na przełączniku przypisany wyłącznie do procesora zarządzającego.

W kampusie akademickim sieć OOB łączy serwerownie budynkowe (IDF) z głównym centrum danych (MDF). Kluczowe routery i przełączniki rdzeniowe posiadają dedykowane interfejsy OOB pracujące w wydzielonej przestrzeni routingu (Management VRF).

Odizolowanie tabeli routingu za pomocą technologii VRF (Virtual Routing and Forwarding) ogranicza przeciek pakietów pomiędzy siecią akademicką a kanałami zarządzającymi, chroniąc urządzenia przed atakami z wnętrza sieci studenckiej.

W architekturze fizycznej sieci OOB w kampusie stosuje się zasadę pełnej niezależności zasilania i tras kablowych. Przełączniki zarządzające OOB są zasilane z dedykowanych obwodów UPS, a ich łącza światłowodowe biegną w odrębnych kanalizacjach teletechnicznych. W dużych węzłach sieciowych stosuje się przełączniki OOB wyposażone w porty z obsługą wirtualnych instancji trasowania (Management VRF), co sprzętowo separuje tablicę routingu ruchu administracyjnego od tablicy tras produkcyjnych.

Dodatkowo w architekturze OOB stosuje się redundantne zasilacze sieciowe (Dual PSU) podłączone do niezależnych linii zasilania A i B. Interfejsy konsolowe urządzeń podłącza się za pomocą ekranowanych kabli rollover do serwerów konsolowych, a porty FastEthernet/GigabitEthernet dedykowane do zarządzania konfiguruje się w wydzielonym adresie prywatnym zgodnym z RFC 1918 (np. z puli 10.254.0.0/16), całkowicie niewymienianym w protokołach trasowania OSPF czy BGP z resztą kampusu.

Skróty użyte w tym slajdzie:
MDF (Main Distribution Frame) - Główny punkt dystrybucyjny kampusu skupiający szkielet sieci OOBM.
IDF (Intermediate Distribution Frame) - Pośredni punkt rozdzielczy w budynku łączący dedykowane porty zarządzające urządzeń.

Odporność architektury OOBM wzmacnia się poprzez instalację awaryjnych kanałów dostępowych niezależnych od infrastruktury kablowej uczelni, np. routerów komórkowych LTE/5G zintegrowanych z serwerami konsolowymi w głównych węzłach dystrybucyjnych.

W przypadku zerwania światłowodowej magistrali kampusowej podczas prac budowlanych inżynierowie mogą nawiązać bezpieczną sesję przez łącze komórkowe i zdalnie przekierować ruch na zapasowe ringi transmisyjne.

Typowym zjawiskiem w czasie awarii sieci produkcyjnej jest tzw. burza rozgłoszeniowa (Broadcast Storm), wywołana pętlą przełączania warstwy 2. W sieci zarządzanej w paśmie pakiety rozgłoszeniowe zapełniają kolejki interfejsów, powodując odrzucanie pakietów sesji SSH administratora i brak odpowiedzi na zapytania ping. Sieć OOB, funkcjonując na zupełnie odrębnym medium fizycznym i bez mostkowania z siecią kampusową, pozostaje w takiej sytuacji w 100 procentach wolna od zatorów i pozwala na natychmiastowe wyłączenie zapętlonego portu.

Skróty użyte w tym slajdzie:
Congestion Immunity (Network Congestion Immunity) - Odporność sieci zarządzającej OOB na zatory, burze rozgłoszeniowe i ataki DoS w sieci produkcyjnej.

Port konsolowy (Console Port) stanowi podstawowy, bezpośredni interfejs diagnostyczny routera i przełącznika. Zapewnia dostęp do procesora urządzenia na najniższym poziomie, działając nawet przed załadowaniem systemu operacyjnego (tryb ROMMON).

Dostęp konsolowy nie wymaga skonfigurowanego adresu IP ani działających protokołów warstwy 2 i 3. Jest podstawową metodą wstępnej konfiguracji fabrycznie nowego urządzenia (Day-0 Deployment) oraz ratowania sprzętu po błędach w tablicy routingu.

Port konsolowy jest jedynym interfejsem komunikacyjnym, który działa poprawnie przed załadowaniem obrazu systemu operacyjnego (w trybie bootstrap / ROMMON). Pozwala on na diagnozowanie uszkodzeń pamięci RAM, wgrywanie oprogramowania układowego przez protokół Xmodem lub TFTP bezpośrednio do pamięci Flash oraz podgląd komunikatów błędów sprzętowych magistrali PCIe, które nigdy nie pojawiają się w logach sieciowych.

Skróty użyte w tym slajdzie:
Console Port (Console Management Port) - Lokalny port szeregowy urządzenia sieciowego umożliwiający bezpośredni dostęp tekstowy do CLI bez sieci IP.
ROMMON (ROM Monitor) - Niskopoziomowy program rozruchowy w pamięci ROM urządzenia służący do odzyskiwania haseł i wgrywania oprogramowania.

Standardy okablowania konsolowego ewoluowały od tradycyjnych złączy szeregowych DB-9 i kabli płaskich RJ-45 roll-over (Cisco Rollover Cable), przez złącza mini-USB, aż po współczesny standard USB-C ze zintegrowanymi układami UART.

W nowo wdrażanych urządzeniach kampusowych porty USB-C eliminują potrzebę stosowania zawodnych przejściówek USB-Serial, umożliwiając bezpośrednie połączenie laptopa inżyniera z terminalem przełącznika za pomocą standardowego przewodu USB.

Współczesne urządzenia sieciowe coraz częściej rezygnują z tradycyjnego portu szeregowego RJ-45 na rzecz interfejsów USB typu B lub micro-USB ze zintegrowanym konwerterem UART. Wymaga to zainstalowania na komputerze inżyniera odpowiednich sterowników wirtualnego portu szeregowego (VCP). Na stacjach z systemem Linux interfejs taki jest automatycznie wykrywany jako urządzenie znakowe w katalogu /dev/ttyUSB0 lub /dev/ttyACM0, co umożliwia bezpośrednie otwarcie sesji przez programy minicom lub screen.

Skróty użyte w tym slajdzie:
RS-232 (Recommended Standard 232) - Tradycyjny standard transmisji szeregowej sygnałów sterujących i danych (TIA/EIA-232).
RJ-45 (Registered Jack 45) - 8-stykowe złącze modularne powszechnie stosowane w portach konsolowych Cisco z kablem z przeplotem (Rollover).
USB-C (Universal Serial Bus Type-C) - Współczesny miniaturowy interfejs sprzętowy powszechnie zastępujący porty szeregowe w nowym sprzęcie.

Komunikacja przez port konsolowy podlega standardowi RS-232 i wymaga precyzyjnego ustawienia parametrów emulatora terminala (np. PuTTY, Minicom): prędkość 9600 baud, 8 bitów danych, bez kontroli parzystości, 1 bit stopu (9600 8N1) oraz brak kontroli przepływu.

Niezgodność prędkości transmisji (np. 115200 zamiast 9600) skutkuje pojawianiem się nieczytelnych znaków (tzw. śmieci transmisyjnych). Zmiana fabrycznej prędkości konsoli jest dopuszczalna wyłącznie w celu przyspieszenia transferu obrazów IOS w trybie XMODEM.

Standardowa prędkość 9600 bodów wynika z historycznych uwarunkowań transmisji szeregowej RS-232 i gwarantuje stabilność sygnału na długich przewodach miedzianych. Jednak w trakcie wgrywania nowego obrazu systemu przez port konsoli prędkość ta okazuje się wąskim gardłem - transfer pliku o rozmiarze 200 megabajtów trwałby kilkadziesiąt godzin. W takich wypadkach procedury inżynierskie przewidują tymczasową rekonfigurację portu na 115200 bodów w celu skrócenia czasu operacji.

Skróty użyte w tym slajdzie:
Baud Rate (Baud Rate / Symbol Rate) - Szybkość transmisji symboli portu szeregowego (standardowo 9600 bodów dla urządzeń sieciowych).
8N1 (8-N-1 Serial Framing) - Standardowa konfiguracja ramki szeregowej: 8 bitów danych, bez kontroli parzystości (No parity), 1 bit stopu.

Fizyczny dostęp do portu konsolowego stanowi poważne zagrożenie bezpieczeństwa, ponieważ pozwala na restart urządzenia i uruchomienie procedury odzyskiwania haseł. Dlatego szafy teleinformatyczne w kampusie muszą być trwale zamknięte i objęte kontrolą dostępu.

Na poziomie systemu operacyjnego port konsoli musi zostać zabezpieczony wymogiem uwierzytelniania przez AAA lub lokalną bazę użytkowników, a także dyrektywą exec-timeout 5 0 automatycznie zamykającą bezczynną sesję po 5 minutach.

Węzły dystrybucyjne w budynkach dydaktycznych często znajdują się w szafach teletechnicznych zainstalowanych na korytarzach lub w ogólnodostępnych pomieszczeniach gospodarczych. Wpięcie fizycznego kabla konsolowego przez osobę nieuprawnioną pozwala na zrestartowanie urządzenia i przejęcie nad nim kontroli. Z tego powodu fizyczne zabezpieczenie szaf zamkami patentowymi, instalacja czujników otwarcia drzwi oraz konfiguracja haseł na poziomie ROMMON stanowią podstawowe wymogi audytowe.

Skróty użyte w tym slajdzie:
Physical Security (Data Center Physical Security) - Fizyczne zabezpieczenie dostępu do szaf RACK i portów konsolowych przed nieuprawnionym wpięciem.
Exec-Timeout (CLI Exec-Timeout) - Polecenie konfiguracyjne automatycznie wylogowujące bezczynną sesję konsolową po określonym czasie.

Serwery konsolowe (Terminal Servers / Console Servers) to urządzenia wieloportowe wyposażone w 16, 32 lub 48 portów szeregowych, podłączanych bezpośrednio do konsol wszystkich przełączników i routerów w szafie rackowej.

Serwer konsolowy udostępnia te porty przez bezpieczną sieć IP (SSH na odpowiednie porty TCP), umożliwiając inżynierom jednoczesny, zdalny dostęp do konsoli tekstowej kilkudziesięciu urządzeń bez konieczności fizycznej wizyty w serwerowni.

Centralny serwer konsolowy (Terminal Server / Console Server) to wieloportowe urządzenie montowane w szafie rack, wyposażone w kilkanaście lub kilkadziesiąt złączy szeregowych podłączonych bezpośrednio do portów konsoli zarządzanych przełączników. Serwer konsolowy udostępnia te porty przez sieć IP za pośrednictwem szyfrowanych sesji SSH. Dodatkowo urządzenia te wyposaża się w zintegrowane modemy łączności komórkowej LTE/5G, co zapewnia niezależny kanał ratunkowy (Out-of-Band Cellular Fallback) w razie awarii światłowodu doprowadzającego Internet do kampusu.

Skróty użyte w tym slajdzie:
Terminal Server (Console Terminal Server) - Wyspecjalizowane urządzenie sprzętowe (np. Opengear) udostępniające dziesiątki portów konsolowych przez sieć IP.
Cellular Uplink (Cellular Out-of-Band Uplink) - Awaryjne łącze komórkowe (LTE/5G) w serwerze konsolowym umożliwiające zdalny dostęp po awarii światłowodu.

Protokół Telnet (RFC 854) przesyła całą komunikację - w tym loginy administratorów i hasła trybu Enable - czystym tekstem (Plaintext). Każdy użytkownik podpięty do tego samego segmentu L2 może przechwycić poświadczenia za pomocą prostego sniffera (np. Wireshark).

Przepisy Krajowych Ram Interoperacyjności (Dz.U. 2017 poz. 2247), Ustawa o KSC oraz norma ISO/IEC 27001 wymagają ochrony poufności transmisji, co w praktyce wyklucza Telnet. Na wszystkich liniach VTY należy zablokować Telnet komendą transport input ssh.

Protokół Telnet powstał w 1969 roku w ramach sieci ARPANET, w czasach gdy kwestie cyberbezpieczeństwa nie były priorytetem. Brak jakiegokolwiek szyfrowania powoduje, że każdy bajt wprowadzany z klawiatury administratora - w tym identyfikator użytkownika i tajne hasło dostępu - jest przesyłany w otwartym polu danych pakietu TCP. Każdy student kierunku informatycznego podłączony do tego samego segmentu sieci może bez trudu odczytać te dane przy użyciu prostych analizatorów ruchu sieciowego.

Skróty użyte w tym slajdzie:
Telnet (Teletype Network Protocol) - Przestarzały protokół zdalnego terminala (RFC 854) przesyłający loginy i hasła otwartym tekstem bez szyfrowania.

Protokół Secure Shell w wersji 2 (SSHv2, RFC 4253) stanowi znormalizowany standard bezpiecznego zdalnego logowania. Zastępuje podatną na ataki wersję SSHv1, eliminując podatności na wstrzykiwanie danych (Insertion Attacks) i manipulację integralnością.

Architektura SSHv2 składa się z trzech warstw: protokołu warstwy transportowej (Transport Layer Protocol) zapewniającego szyfrowanie i uwierzytelnianie serwera, protokołu uwierzytelniania użytkownika (User Authentication Protocol) oraz protokołu połączenia (Connection Protocol) obsługującego terminale i tunele.

Architektura protokołu SSHv2 (RFC 4251) składa się z trzech ściśle współpracujących warstw: warstwy transportowej (SSH-TRANS), warstwy uwierzytelniania użytkownika (SSH-USERAUTH) oraz warstwy połączenia (SSH-CONN). Warstwa transportowa odpowiada za bezpieczne szyfrowanie kanału, negocjację kluczy i weryfikację integralności. Na niej opiera się warstwa uwierzytelniania, a po pomyślnym logowaniu warstwa połączenia realizuje multipleksowanie wielu logicznych kanałów wewnątrz jednego strumienia TCP, obsługując jednocześnie powłokę tekstową, transfer plików SFTP oraz tunele.

W implementacji OpenSSH kluczowe jest również wyłączenie przestarzałych algorytmów skrótu SHA-1 oraz szyfrów blokowych CBC, które wykazują podatności na ataki typu plaintext-recovery. Zgodnie z wytycznymi technicznymi NIST SP 800-131A zaleca się stosowanie wyłącznie algorytmów z rodziny SHA-2 (SHA-256, SHA-512) oraz trybów szyfrowania ze zintegrowanym uwierzytelnianiem AEAD, takich jak AES-GCM lub ChaCha20-Poly1305.

Skróty użyte w tym slajdzie:
SSHv2 (Secure Shell Version 2) - Współczesna, bezpieczna wersja protokołu SSH (RFC 4253) eliminująca krytyczne podatności kryptograficzne wersji SSHv1.
Transport Layer (SSH Transport Layer Protocol) - Warstwa protokołu SSH (RFC 4251) zapewniająca szyfrowanie, integralność i uwierzytelnianie serwera.

Podczas nawiązywania sesji SSHv2 następuje hybrydowe połączenie kryptografii asymetrycznej i symetrycznej. Algorytm Diffiego-Hellmana (lub ECDH) pozwala na uzgodnienie wspólnego klucza symetrycznego przez niezaufany kanał bez jego bezpośredniego przesyłania.

Właściwy transfer danych szyfrowany jest wysoce wydajnymi szyframi symetrycznymi (np. AES-256-GCM lub ChaCha20-Poly1305), co zapewnia minimalne obciążenie procesora przełącznika oraz poufność i integralność pakietów.

Proces nawiązywania połączenia SSH stanowi doskonały przykład połączenia kryptografii asymetrycznej i symetrycznej w praktyce inżynierskiej. Asymetryczny algorytm Diffiego-Hellmana (DH lub ECDH) pozwala obu stronom wynegocjować wspólny klucz sesyjny przez niezaufany kanał bez jego bezpośredniego przesyłania w sieci. Natychmiast po wygenerowaniu wspólnego sekretu cały dalszy ruch jest szyfrowany algorytmem symetrycznym AES lub ChaCha20, co gwarantuje maksymalną wydajność i minimalne obciążenie procesora przełącznika.

Skróty użyte w tym slajdzie:
RSA (Rivest-Shamir-Adleman) - Powszechny algorytm kryptografii asymetrycznej wykorzystujący parę kluczy publiczny/prywatny (rekomendowane min. 2048/4096 bitów).
AES (Advanced Encryption Standard) - Symetryczny szyfr blokowy (FIPS 197) stosowany do szyfrowania strumienia danych w sesji SSH (AES-256-GCM).
Ed25519 (Edwards-curve Digital Signature Algorithm) - Nowoczesny, wysoce bezpieczny algorytm podpisu cyfrowego oparty na krzywej eliptycznej Curve25519.

Przy pierwszym połączeniu klient SSH pobiera publiczny klucz gospodarza (Host Key) serwera i oblicza jego kryptograficzny skrót (Fingerprint). Inżynier ma obowiązek zweryfikować ten odcisk, po czym zostaje on zapisany w pliku known_hosts.

Jeśli przy kolejnym logowaniu klucz serwera ulegnie zmianie, klient SSH wyświetli ostrzeżenie o możliwym ataku Man-in-the-Middle (MitM) i zablokuje połączenie. Chroni to administratora przed omyłkowym zalogowaniem się do podstawionego urządzenia.

Plik known_hosts w katalogu domowym inżyniera przechowuje powiązania adresów IP urządzeń z ich publicznymi kluczami tożsamości. Jeżeli atakujący podszyje się pod przełącznik w ataku ARP Spoofing i podstawi własny serwer SSH, klient natychmiast przerwie połączenie i wyświetli ostrzeżenie o zmianie odcisku klucza serwera (Host Key Verification Failed). Świadomy administrator nigdy nie powinien bezkrytycznie akceptować zmienionych kluczy bez telefonicznej lub bezpośredniej weryfikacji sumy kontrolnej w serwerowni.

Skróty użyte w tym slajdzie:
Fingerprint (SSH Host Key Fingerprint) - Krótki skrót kryptograficzny (np. SHA-256) jednoznacznie identyfikujący klucz publiczny serwera SSH.
Known Hosts (SSH Known Hosts Database) - Lokalny plik klienta przechowujący zweryfikowane odciski kluczy serwerów chroniący przed atakami MitM.

Utwardzanie konfiguracji serwera SSH na urządzeniach Cisco obejmuje: wygenerowanie silnej pary kluczy RSA (minimum 2048 bitów, a optymalnie 4096 bitów komendą crypto key generate rsa modulus 4096) oraz wymuszenie wersji 2 poleceniem ip ssh version 2.

Dodatkowo należy ograniczyć czas oczekiwania na logowanie (ip ssh time-out 60) oraz zmniejszyć dopuszczalną liczbę nieudanych prób autoryzacji (ip ssh authentication-retries 3), co skutecznie utrudnia zautomatyzowane ataki brute-force.

W procesie utwardzania demona SSH kluczowe znaczenie ma bezwzględne wyłączenie podatnej wersji SSHv1 za pomocą dyrektywy ip ssh version 2 oraz wygenerowanie klucza asymetrycznego RSA o długości co najmniej 2048 lub 4096 bitów (bądź kluczy opartych na krzywych eliptycznych ECDSA/Ed25519). Ponadto zaleca się ograniczenie limitu czasu bezczynności (ip ssh time-out 60) oraz zredukowanie maksymalnej liczby nieudanych prób logowania (ip ssh authentication-retries 2), co skutecznie neutralizuje zautomatyzowane ataki słownikowe.

Skróty użyte w tym slajdzie:
Crypto Key (Crypto Key Generation) - Polecenie CLI generujące parę kluczy asymetrycznych RSA wymaganych do uruchomienia serwera SSH.
IP SSH Version 2 (Enforce SSHv2) - Dyrektywa konfiguracyjna wymuszająca odrzucanie podatnych negocjacji protokołu SSHv1.

Standardowym mechanizmem obrony linii wirtualnych VTY jest powiązanie ich z listą kontroli dostępu za pomocą polecenia access-class <ACL> in. Lista ACL dopuszcza połączenia SSH wyłącznie z precyzyjnie określonych podsieci administracyjnych lub stacji inżynierskich.

Próby nawiązania sesji z sieci studenckich, laboratoriów czy adresów publicznych są natychmiast odrzucane na poziomie warstwy sieciowej, a zdarzenie jest rejestrowane w logach systemowych Syslog.

Brak restrykcyjnej listy ACL na wirtualnych liniach terminalowych VTY sprawia, że usługa SSH nasłuchuje na wszystkich dostępnych interfejsach warstwy 3 przełącznika, w tym na adresach IP przypisanych do sieci studenckich. Zastosowanie polecenia access-class w konfiguracji linii vty 0 15 wymusza sprzętową filtrację pakietów TCP na porcie 22, zezwalając na nawiązanie sesji wyłącznie z adresów IP należących do podsieci stacji administratorów lub serwera skokowego.

Skróty użyte w tym slajdzie:
Access-Class (Line VTY Access-Class) - Dyrektywa Cisco IOS przypisująca listę kontroli dostępu ACL do linii terminalowych VTY.
Transport Input (Transport Input SSH) - Polecenie blokujące nawiązywanie połączeń nieszyfrowanych na liniach VTY (blokada Telnetu).

Uwierzytelnianie kluczami publicznymi (SSH Key-Based Authentication) eliminuje ryzyko związane ze słabymi lub przechwyconymi hasłami. Inżynier generuje parę kluczy na swojej stacji roboczej (preferowany algorytm Ed25519 lub RSA 4096), a klucz publiczny umieszcza na serwerze.

Prywatny klucz inżyniera jest zabezpieczony silnym hasłem passphrase i nie powinien opuszczać stacji roboczej w postaci niezaszyfrowanej. Połączenie dochodzi do skutku dzięki kryptograficznemu wykazaniu posiadania klucza prywatnego w odpowiedzi na wyzwanie serwera (Challenge-Response).

Uwierzytelnianie asymetryczne opiera się na wygenerowaniu pary kluczy kryptograficznych na stacji roboczej inżyniera, gdzie klucz prywatny jest zabezpieczony silnym hasłem lokalnym (passphrase), a klucz publiczny zostaje umieszczony w konfiguracji przełącznika. W przeciwieństwie do tradycyjnych haseł, klucze asymetryczne są całkowicie odporne na ataki podsłuchu i próby zgadywania metodą brute-force, a także umożliwiają bezpieczną automatyzację zadań administracyjnych za pośrednictwem skryptów bez konieczności zapisywania poświadczeń otwartym tekstem.

Skróty użyte w tym slajdzie:
Public Key Auth (SSH Public Key Authentication) - Bezhasłowa metoda logowania oparta na kryptograficznym potwierdzeniu posiadania klucza prywatnego.
Authorized Keys (Authorized Keys File) - Zbiór zaufanych kluczy publicznych uprawnionych do logowania na dane konto administratorskie.

Protokół SSH oferuje funkcję tunelowania ruchu (SSH Port Forwarding), pozwalając na bezpieczne przesyłanie dowolnego protokołu warstwy aplikacji (np. nieszyfrowanego HTTP, RDP czy VNC) wewnątrz zaszyfrowanego kanału SSH.

Dzięki tunelowaniu inżynierowie mogą bezpiecznie zarządzać starszymi urządzeniami laboratoryjnymi nieposiadającymi wsparcia dla protokołu HTTPS, bez ryzyka podejrzenia sesji przez osoby trzecie w sieci kampusowej.

Tunelowanie SSH umożliwia hermetyzację dowolnego strumienia danych TCP wewnątrz bezpiecznego, zaszyfrowanego kanału SSH. W środowisku kampusowym technika ta jest wykorzystywana do bezpiecznego przesyłania nieszyfrowanych protokołów pomocniczych, takich jak starsze systemy zarządzania bazami danych czy aplikacje webowe bez certyfikatu TLS. Dzięki temu ruch wrażliwy może bezpiecznie pokonać segmenty sieci o obniżonym zaufaniu bez ryzyka podsłuchu przez osoby trzecie.

Skróty użyte w tym slajdzie:
Port Forwarding (SSH Port Forwarding) - Mechanizm tunelowania ruchu aplikacji TCP wewnątrz zaszyfrowanego kanału SSH.

Lokalne przekierowanie portów (Local Port Forwarding, parametr -L) polega na otwarciu portu nasłuchującego na lokalnej stacji inżyniera i tunelowaniu całego skierowanego tam ruchu przez serwer SSH do docelowego hosta w chronionej serwerowni.

Przykładowo, polecenie ssh -L 8443:10.1.100.5:443 serwer-skokowy umożliwia otwarcie w przeglądarce adresu https://localhost:8443 i uzyskanie bezpiecznego dostępu do interfejsu WWW przełącznika odizolowanego w sieci OOB.

Lokalne przekierowanie portów (wywoływane parametrem -L w kliencie SSH) nakazuje lokalnej stacji inżyniera nasłuchiwanie na wybranym porcie TCP i przesyłanie wszystkich przychodzących pakietów przez tunel SSH bezpośrednio do wskazanego adresu i portu docelowego za serwerem SSH. Mechanizm ten pozwala administratorowi na bezpieczny dostęp do interfejsu graficznego przełącznika (HTTPS) lub konsoli webowej kontrolera Wi-Fi, które z powodów bezpieczeństwa nie są bezpośrednio wystawione do sieci kampusowej.

Skróty użyte w tym slajdzie:
Local Forwarding (Local Port Forwarding (-L)) - Przekierowanie portu z lokalnego komputera przez serwer SSH do docelowej usługi w sieci wewnętrznej.

Dynamiczne przekierowanie portów (Dynamic Port Forwarding, parametr -D) zamienia klienta SSH w lokalny serwer proxy zgodny ze standardem SOCKS5. Cały ruch aplikacji skonfigurowanych do korzystania z proxy jest dynamicznie kierowany przez tunel SSH.

Pozwala to inżynierowi na jednoczesne przeglądanie interfejsów webowych dziesiątek urządzeń w wewnętrznej sieci uczelni bez konieczności definiowania osobnych reguł dla każdego portu.

Dynamiczne przekierowanie portów (parametr -D w kliencie SSH) przekształca klienta SSH w lokalny serwer pośredniczący pracujący zgodnie ze standardem SOCKS5 (RFC 1928). W tym wariancie administrator nie musi definiować każdego docelowego portu z osobna; wystarczy skonfigurować przeglądarkę internetową lub narzędzie diagnostyczne, aby kierowały cały ruch przez lokalne proxy SOCKS, co umożliwia swobodne przeglądanie zasobów całej odizolowanej podsieci zarządzającej.

Skróty użyte w tym slajdzie:
Dynamic Forwarding (Dynamic Port Forwarding (-D)) - Utworzenie lokalnego serwera proxy SOCKS5 przekierowującego cały ruch przeglądarki przez tunel SSH.
SOCKS5 (Socket Secure version 5) - Protokół proxy (RFC 1928) elastycznie trasujący pakiety TCP/UDP dowolnej aplikacji.

Serwer skokowy (Bastion Host / Jump Server) to silnie utwardzony serwer pośredniczący, stanowiący jedyny dozwolony punkt wejścia do strefy zarządzania infrastrukturą kampusową. Urządzenia sieciowe akceptują połączenia SSH wyłącznie z adresu IP serwera skokowego.

Wdrożenie Bastion Host znacznie ogranicza powierzchnię ataku: routery i przełączniki są niedostępne bezpośrednio z reszty sieci, a cała uwaga zespołu ds. bezpieczeństwa może skupić się na monitorowaniu i utwardzaniu pojedynczego węzła pośredniczącego.

Serwer skokowy (Bastion Host / Jump Host) pełni funkcję ściśle kontrolowanej bramy wejściowej do strefy zarządzania infrastrukturą kampusową. Żadna stacja robocza inżyniera nie może łączyć się bezpośrednio z urządzeniami sieciowymi z pominięciem bastionu. Sam bastion jest systemem o zminimalizowanej liczbie zainstalowanych pakietów (minimal OS footprint), bez interfejsu graficznego, z wdrożonym modułem SELinux lub AppArmor oraz rygorystycznymi regułami zapory sieciowej ograniczającymi ruch przychodzący wyłącznie do autoryzowanych adresów źródłowych.

W celu uniemożliwienia ominięcia bastionu reguły zapór sieciowych (ACL) na przełącznikach dystrybucyjnych i rdzeniowych konfiguruje się w taki sposób, aby odrzucały wszelki ruch SSH (port TCP 22) pochodzący z jakichkolwiek innych adresów IP niż dedykowany interfejs serwera skokowego. W połączeniu z wymogiem uwierzytelniania dwuskładnikowego na samym bastionie rozwiązanie to drastycznie ogranicza wektor ataku na sieć szkieletową kampusu.

Skróty użyte w tym slajdzie:
Bastion Host (Bastion Host / Jump Host) - Wzmocniony i odizolowany serwer pośredniczący stanowiący jedyny dopuszczalny punkt wejścia do strefy zarządzania.
DMZ (Demilitarized Zone) - Strefa zdemilitaryzowana, w której umieszczany jest serwer skokowy.

Nowoczesne wdrożenia serwerów skokowych integrują się z systemami Privileged Access Management (PAM). Systemy te realizują pełną rejestrację sesji wideo, logowanie wpisywanych komend tekstowych (Keystroke Logging) oraz automatyczną rotację haseł administratorskich.

Dzięki temu instytucja posiada wiarygodny ślad audytowy zmian konfiguracji wprowadzanych przez administratorów, co spełnia rygorystyczne wymagania normy ISO/IEC 27001 oraz przepisów o ochronie infrastruktury krytycznej.

Wdrożenie serwera skokowego umożliwia pełny audyt działań inżynierów i zewnętrznych integratorów sieciowych. Za pomocą dedykowanych narzędzi, takich jak tlog, Teleport czy Apache Guacamole, każda sesja tekstowa CLI oraz graficzna RDP/VNC jest rejestrowana w postaci zapisu strumienia wejścia-wyjścia ze stemplem czasowym. Zapisy te są natychmiast wysyłane do chronionego serwera logów (WORM - Write Once, Read Many), co uniemożliwia zatarcie śladów przez administratora w przypadku popełnienia błędu konfiguracyjnego.

Skróty użyte w tym slajdzie:
Session Recording (SSH/RDP Session Recording) - Funkcja systemów PAM rejestrująca pełny zapis wideo oraz poleceń tekstowych wprowadzanych przez administratora.
Audit Trail (Security Audit Trail) - Dziennik zdarzeń dokumentujący kto, kiedy i jakie modyfikacje wprowadził w konfiguracji urządzeń.

Wirtualne sieci prywatne (VPN - Virtual Private Network) tworzą logiczny, szyfrowany tunel komunikacyjny ponad publiczną lub niezaufaną siecią WAN/Internet, zapewniając poufność, integralność oraz autentyczność przesyłanych pakietów.

W architekturze uczelnianej technologie VPN wykorzystywane są w dwóch podstawowych scenariuszach: łączenia odległych filii i kampusów zamiejscowych (Site-to-Site) oraz bezpiecznego dostępu dla pracowników pracujących zdalnie (Remote-Access).

Wirtualne sieci prywatne VPN stanowią logiczne rozszerzenie infrastruktury kampusowej ponad fizycznymi granicami sieci lokalnej. Technologia ta tworzy wirtualny tunel transmisyjny w warstwie sieciowej lub transportowej, zapewniając trzy kluczowe filary bezpieczeństwa: poufność (szyfrowanie danych), integralność (kryptograficzne sumy kontrolne HMAC) oraz uwierzytelnianie stron komunikacji. Dzięki temu rozproszone jednostki organizacyjne mogą bezpiecznie wymieniać dane przez publiczny Internet.

Skróty użyte w tym slajdzie:
Site-to-Site (Site-to-Site VPN) - Tunel VPN łączący trwale dwie odrębne sieci lokalne (np. oddział kampusu z centralną serwerownią).
Remote Access (Remote-Access Client VPN) - Rozwiązanie umożliwiające pracownikom i studentom bezpieczne łączenie się z zasobami uczelni z domu.

Tunele Site-to-Site VPN łączą całe sieci lokalne za pośrednictwem routerów brzegowych lub zapór ogniowych NGFW. Urządzenia końcowe (komputery, telefony VoIP) komunikują się przez tunel w sposób w pełni przezroczysty, bez instalowania dodatkowego oprogramowania.

Dla połączeń Site-to-Site w kampusie standardem jest protokół IPsec działający w trybie tunelowym, zabezpieczający magistralę transmisyjną pomiędzy głównym kampusem a zamiejscowymi instytutami badawczymi.

Połączenia Site-to-Site VPN są konfigurowane na brzegowych ruterach lub zaporach sieciowych poszczególnych lokalizacji uczelni (np. między kampusem głównym a zamiejscowymi wydziałami lub domami studenckimi). Cały proces szyfrowania i deszyfracji pakietów odbywa się w sposób całkowicie przezroczysty dla stacji końcowych użytkowników. Ruch między podsieciami lokalnymi jest automatycznie kierowany do tunelu kryptograficznego na podstawie tablicy routingu lub polityk bezpieczeństwa (Policy-Based Routing).

Skróty użyte w tym slajdzie:
GRE (Generic Routing Encapsulation) - Protokół tunelowania (RFC 2784) pozwalający na przesyłanie pakietów multicastowych i protokołów routingu przez sieć IP.
mGRE (Multipoint GRE) - Odmiana protokołu GRE stosowana w zaawansowanych sieciach VPN (np. DMVPN) do dynamicznego tworzenia tuneli.

Dostęp zdalny (Remote-Access VPN) umożliwia pojedynczym użytkownikom (wykładowcom, inżynierom, studentom) bezpieczne wpięcie do sieci uczelnianej z domu lub podróży służbowej. Wymaga uwierzytelnienia użytkownika oraz dynamicznego przydziału wewnętrznego adresu IP.

W rozwiązaniach Remote-Access powszechnie stosuje się protokoły SSL/TLS VPN, technologie WireGuard oraz mobilne profile IKEv2/IPsec, wspierające automatyczną kontrolę stanu bezpieczeństwa stacji końcowej (Endpoint Posture Assessment).

W architekturze Remote-Access VPN kluczowym elementem jest bramka dostępowa (VPN Gateway) oraz dedykowane oprogramowanie klienckie zainstalowane na urządzeniu pracownika lub studenta (np. Cisco AnyConnect, OpenConnect lub WireGuard Client). Bramka dokonuje weryfikacji tożsamości użytkownika w centralnej bazie Active Directory lub RADIUS, a po poprawnym uwierzytelnieniu przydziela wirtualny adres IP ze specjalnej puli adresowej i instaluje reguły filtrowania ograniczające dostęp tylko do dozwolonych zasobów uczelni.

Skróty użyte w tym slajdzie:
Split Tunneling (VPN Split Tunneling) - Technika kierowania przez tunel VPN wyłącznie ruchu do sieci uczelnianej przy zachowaniu bezpośredniego dostępu do Internetu.

Pakiet protokołów IPsec (Internet Protocol Security, RFC 4301) to dojrzały i znormalizowany standard ochrony warstwy sieciowej (L3). Obejmuje protokół nagłówka uwierzytelniającego (AH) oraz protokół szyfrowania i ochrony integralności (ESP - Encapsulating Security Payload).

W nowoczesnych wdrożeniach kampusowych stosuje się wyłącznie protokół ESP (numer protokołu IP 50), ponieważ nagłówek AH nie zapewnia szyfrowania danych i nie jest zgodny z mechanizmem translacji adresów NAT.

Zestaw protokołów IPsec (Internet Protocol Security, RFC 4301) operuje w warstwie 3 modelu OSI, co oznacza, że zapewnia kryptograficzne zabezpieczenie dla dowolnego protokołu warstwy wyższej (TCP, UDP, ICMP). Architektura IPsec opiera się na dwóch protokołach nagłówkowych: Encapsulating Security Payload (ESP, RFC 4303), który oferuje szyfrowanie i opcjonalną weryfikację integralności, oraz Authentication Header (AH, RFC 4302), który gwarantuje jedynie integralność bez szyfrowania danych, co sprawia, że w praktyce inżynierskiej stosuje się niemal wyłącznie protokół ESP.

Warto zwrócić uwagę na problem narzutu nagłówków (Overhead) generowanego przez protokół ESP w tunelu IPsec. Dodatkowy nagłówek IP, nagłówek ESP, wektor inicjalizujący (IV) oraz pole sumy kontrolnej ICV zwiększają rozmiar pakietu nawet o 50-70 bajtów. W sieciach kampusowych wymaga to odpowiedniego skonfigurowania parametru MTU na interfejsach tunelowych lub wdrożenia mechanizmu MSS Clamping (ip tcp adjust-mss 1360), aby zapobiec nieefektywnej fragmentacji pakietów IP.

Skróty użyte w tym slajdzie:
IPsec (Internet Protocol Security) - Zbiór otwartych standardów (RFC 4301) zapewniających uwierzytelnianie, integralność i szyfrowanie pakietów w warstwie IP.
AH (Authentication Header) - Protokół IPsec (RFC 4302) zapewniający integralność i uwierzytelnienie źródła danych bez szyfrowania zawartości.
ESP (Encapsulating Security Payload) - Protokół IPsec (RFC 4303) gwarantujący poufność (szyfrowanie), integralność oraz ochronę przed atakiem powtórzeniowym.

IPsec ESP może pracować w dwóch trybach: transportowym (Transport Mode) oraz tunelowym (Tunnel Mode). W trybie transportowym szyfrowany jest wyłącznie ładunek pakietu IP, a oryginalny nagłówek IP pozostaje odsłonięty (tryb stosowany w połączeniach host-to-host).

W trybie tunelowym cały oryginalny pakiet IP zostaje zaszyfrowany i zamknięty w nowym, zewnętrznym nagłówku IP. Tryb tunelowy jest standardowym rozwiązaniem dla bramek VPN łączących odrębne sieci kampusowe, ukrywając wewnętrzną strukturę adresacji.

Wybór między trybem transportowym a tunelowym zależy od topologii połączenia. Tryb transportowy szyfruje wyłącznie ładunek pakietu IP, zachowując oryginalny nagłówek IP, co czyni go optymalnym do komunikacji typu end-to-end między dwoma konkretnymi serwerami. Z kolei tryb tunelowy hermetyzuje cały oryginalny pakiet IP wraz z jego nagłówkiem wewnątrz zupełnie nowego nagłówka IP, co jest niezbędne w połączeniach typu brama-brama (Site-to-Site) oraz w tunelach zdalnego dostępu, ukrywając wewnętrzną topologię adresową kampusu.

Skróty użyte w tym slajdzie:
Transport Mode (IPsec Transport Mode) - Tryb szyfrowania samego ładunku pakietu IP z zachowaniem oryginalnego nagłówka IP (dla połączeń host-host).
Tunnel Mode (IPsec Tunnel Mode) - Tryb szyfrowania całego oryginalnego pakietu IP i dodania nowego zewnętrznego nagłówka IP (dla tuneli bram sieciowych).

Protokół IKE (Internet Key Exchange) odpowiada za automatyczne uwierzytelnienie węzłów, wymianę kluczy kryptograficznych i zestawienie tuneli IPsec. Nowoczesny standard IKEv2 (RFC 7296) zastępuje przestarzały i złożony protokół IKEv1.

IKEv2 zmniejsza liczbę wymienianych komunikatów z 9 w IKEv1 (6 w Main Mode i 3 w Quick Mode) do 4 w podstawowej wymianie IKEv2, ma wbudowane wsparcie dla translacji NAT (NAT-Traversal na porcie UDP 4500), obsługuje protokół MOBIKE dla urządzeń mobilnych oraz cechuje się wyższą odpornością na ataki Denial of Service.

Protokół IKEv2 (Internet Key Exchange version 2, RFC 7296) stanowi radykalny krok naprzód w stosunku do historycznego IKEv1. Redukuje liczbę komunikatów potrzebnych do ustanowienia tunelu z dziewięciu w IKEv1 do zaledwie czterech w IKEv2 (IKE_SA_INIT oraz IKE_AUTH). Ponadto IKEv2 posiada natywną obsługę mechanizmu MOBIKE (RFC 4555), co pozwala użytkownikom mobilnym na płynne przełączanie się między siecią Wi-Fi a łączem komórkowym LTE bez zrywania aktywnej sesji VPN.

Skróty użyte w tym slajdzie:
IKEv1 (Internet Key Exchange version 1) - Tradycyjny protokół negocjacji kluczy IPsec (RFC 2409) składający się z dwóch złożonych faz.
IKEv2 (Internet Key Exchange version 2) - Nowoczesny i zoptymalizowany protokół negocjacji kluczy (RFC 7296) o wyższej odporności na ataki DoS i wsparciu dla mobilności.

Negocjacja IKEv2 przebiega w dwóch fazach: IKE_SA_INIT (uzgodnienie algorytmów kryptograficznych, wygenerowanie kluczy za pomocą Diffiego-Hellmana) oraz IKE_AUTH (kryptograficzne uwierzytelnienie tożsamości węzłów i zestawienie pierwszego tunelu IPsec Child SA).

Skojarzenia bezpieczeństwa (Security Associations - SA) są jednokierunkowe: do pełnej komunikacji dupleksowej wymagane są co najmniej dwa skojarzenia SA (jedno dla ruchu wychodzącego, drugie dla przychodzącego), z których każde posiada unikalny identyfikator SPI.

W pierwszej fazie negocjacji IKE strony zestawiają bezpieczny, szyfrowany kanał kontrolny (IKE SA), weryfikując nawzajem swoją tożsamość za pomocą kluczy współdzielonych PSK lub certyfikatów cyfrowych X.509. Dopiero wewnątrz tego kanału realizowana jest faza druga (Child SA / IPsec SA), w której precyzowane są parametry szyfrowania faktycznego ruchu użytkowników, w tym algorytmy symetryczne (np. AES-GCM) oraz okres ważności kluczy, po upływie którego następuje automatyczna renegocjacja (Rekeying).

Skróty użyte w tym slajdzie:
ISAKMP (Internet Security Association and Key Management Protocol) - Protokół ramowy (RFC 2408) definiujący procedury tworzenia i negocjacji skojarzeń bezpieczeństwa SA.
DH Group (Diffie-Hellman Group) - Grupa matematyczna określająca siłę klucza algorytmu uzgadniania kluczy symetrycznych przez niezaufany kanał.

Protokoły SSL/TLS VPN wykorzystują technologie kryptograficzne warstwy transportowej (TLS 1.3) działające domyślnie na porcie 443 TCP. Zaletą tego podejścia jest ułatwienie przechodzenia przez zapory ogniowe i hotelowe punkty dostępowe blokujące protokoły IPsec.

Wadą tunelowania ruchu TCP wewnątrz zewnętrznego strumienia TCP jest zjawisko TCP-over-TCP Meltdown. Dlatego dojrzałe rozwiązania dostępowe (np. Cisco AnyConnect) po wstępnym uzgodnieniu sesji przełączają transmisję na wydajny protokół DTLS (RFC 6347) oparty na pakietach UDP.

Tunele SSL/TLS VPN wykorzystują protokół TLS działający w warstwie aplikacji nad protokołem TCP (zazwyczaj na porcie 443). Główną zaletą takiego podejścia jest doskonała przepuszczalność przez restrykcyjne zapory sieciowe i mechanizmy translacji adresów NAT na całym świecie, gdyż ruch ten wygląda dla urządzeń pośredniczących jak standardowe przeglądanie stron internetowych HTTPS. W nowoczesnych implementacjach do przesyłania danych stosuje się wariant DTLS (Datagram TLS, RFC 6347), który opiera się na protokole UDP i eliminuje problem nakładających się retransmisji TCP (TCP-over-TCP meltdown).

Skróty użyte w tym slajdzie:
SSL VPN (Secure Sockets Layer VPN) - Technologia VPN wykorzystująca protokoły TLS do budowy bezpiecznych połączeń dla użytkowników zdalnych.
DTLS (Datagram Transport Layer Security) - Wersja TLS oparta na pakietach UDP (RFC 6347) eliminująca problem TCP-over-TCP w tunelach VPN.

Dostęp SSL VPN dzieli się na dwa warianty: bezagentowy portal webowy (Clientless SSL VPN) oraz pełny tunel sieciowy (Full Client SSL VPN). Portal bezagentowy wymaga wyłącznie przeglądarki WWW i służy do udostępniania wybranych aplikacji uczelnianych.

Wariant Full Client wymaga instalacji oprogramowania agenta (np. AnyConnect, OpenConnect), który tworzy wirtualną kartę sieciową w systemie operacyjnym stacji i zapewnia pełną transparentną łączność ze wszystkimi zasobami kampusu.

Wariant bezklientowy (Clientless SSL VPN) realizuje dostęp przez standardową przeglądarkę internetową, w której bramka VPN pełni rolę zwrotnego proxy (Reverse Proxy), przepisując w locie adresy URL i renderując aplikacje uczelniane w oknie przeglądarki. Z kolei wariant pełnego klienta (Full Client SSL VPN) tworzy wirtualną kartę sieciową (interfejs TUN/TAP) w systemie operacyjnym stacji roboczej, zapewniając pełną dwukierunkową łączność w warstwie sieciowej IP dla wszystkich aplikacji komputerowych, zgodnie z przydzielonymi regułami routingu.

Skróty użyte w tym slajdzie:
Clientless (Clientless SSL VPN) - Dostęp do aplikacji webowych realizowany bezpośrednio z przeglądarki WWW bez instalacji dodatkowego oprogramowania.
Full Client (Full-Tunnel VPN Client) - Wirtualna karta sieciowa (np. Cisco AnyConnect, OpenConnect) zapewniająca pełny dostęp w warstwie 3.

Protokół WireGuard to nowoczesna technologia VPN, zintegrowana bezpośrednio z jądrem systemu Linux. Charakteryzuje się niezwykle zwięzłym kodem źródłowym (około 4000 linii kodu wobec setek tysięcy w OpenVPN i IPsec).

Protokół bazuje na stałym zestawie nowoczesnych prymitywów kryptograficznych: Curve25519 do wymiany kluczy, ChaCha20 do szyfrowania symetrycznego, Poly1305 do uwierzytelniania danych oraz BLAKE2s do haszowania, eliminując podatności wynikające z błędnej negocjacji szyfrów.

Technologia WireGuard (RFC 8986) reprezentuje nową generację protokołów VPN, charakteryzując się niezwykle zwięzłym kodem źródłowym liczącym około 4000 linii, co w porównaniu z setkami tysięcy linii w OpenVPN czy IPsec drastycznie ułatwia audyt bezpieczeństwa i minimalizuje powierzchnię ataku. WireGuard rezygnuje ze złożonych faz negocjacji na rzecz modelu Noise Protocol Framework, wykorzystując wyłącznie nowoczesne, zweryfikowane algorytmy kryptograficzne: Curve25519 do wymiany kluczy, ChaCha20 do szyfrowania oraz Poly1305 do uwierzytelniania wiadomości.

Skróty użyte w tym slajdzie:
WireGuard (WireGuard Secure Network Tunnel) - Nowoczesny, minimalistyczny protokół VPN działający w przestrzeni jądra o wysokiej wydajności.
Noise Protocol (Noise Protocol Framework) - Kryptograficzny szkielet konstrukcji bezpiecznych protokołów, na którym oparto mechanizmy WireGuard.

Wdrożenie protokołu WireGuard w kampusie zapewnia wysoką wydajność i minimalne opóźnienia, co jest kluczowe dla przesyłania dużych zbiorów danych naukowych pomiędzy laboratoriami uczelnianymi.

Dzięki koncepcji Cryptokey Routing WireGuard wiąże publiczne klucze kryptograficzne z wewnętrznymi adresami IP stacji, zapewniając szybkie wznawianie transmisji (Roaming) przy przełączaniu laptopa inżyniera pomiędzy siecią Wi-Fi a modemem komórkowym.

W środowisku uczelnianym WireGuard doskonale sprawdza się w łączności pomiędzy oddalonymi stacjami badawczymi a serwerownią wydziałową, jak również w dostępie zdalnym dla pracowników mobilnych. Dzięki integracji bezpośrednio w jądrze systemu Linux (od wersji 5.6) WireGuard osiąga przepustowości bliskie sprzętowej wydajności interfejsów sieciowych przy minimalnym narzucie na procesor. Co istotne, protokół ten nie odpowiada na nieautoryzowane pakiety UDP, co czyni go całkowicie niewidocznym dla zewnętrznych skanerów portów nmap.

Skróty użyte w tym slajdzie:
ChaCha20 (ChaCha20 Stream Cipher) - Wysoko wydajny szyfr strumieniowy (RFC 8439) zoptymalizowany pod kątem urządzeń pozbawionych sprzętowej akceleracji AES.
Poly1305 (Poly1305 Authenticator) - Szybki algorytm wyliczania kodu uwierzytelniania wiadomości MAC (RFC 8439).

Porównanie technologii VPN wskazuje na podział ról w kampusie: IPsec/IKEv2 dominuje w łączach szkieletowych Site-to-Site, SSL/TLS z protokołem DTLS stanowi standard dostępu zdalnego dla stacji pracowniczych, a WireGuard sprawdza się w wysoko wydajnych łączach badawczych.

Dobór technologii musi uwzględniać nie tylko maksymalną przepustowość, lecz także łatwość zarządzania profilami użytkowników, integrację z infrastrukturą PKI oraz wsparcie dla uwierzytelniania MFA.

Dobór odpowiedniej technologii VPN w infrastrukturze kampusowej zależy od profilu użytkowników oraz wymagań wydajnościowych. IPsec pozostaje niekwestionowanym standardem w łączach szkieletowych Site-to-Site ze względu na sprzętową akcelerację w routerach i wsparcie w normach branżowych. SSL/DTLS VPN jest niezastąpiony w dostępie pracowniczym i studenckim z uwagi na łatwość przenikania przez zapory ogniowe dostawców Internetu, natomiast WireGuard stanowi najefektywniejsze rozwiązanie dla nowoczesnych platform chmurowych i stacji badawczych.

Skróty użyte w tym slajdzie:
Crypto Comparison (VPN Protocols Comparative Matrix) - Zestawienie porównawcze protokołów IPsec, TLS i WireGuard pod kątem wydajności, narzutu i bezpieczeństwa.

Architektura AAA stanowi fundament zarządzania tożsamością i kontroli dostępu w sieciach korporacyjnych. Dzieli proces zabezpieczenia zasobów na trzy komplementarne etapy: uwierzytelnianie tożsamości (Authentication), nadawanie uprawnień (Authorization) oraz rozliczanie działań (Accounting).

Wdrożenie modelu AAA ogranicza liczbę lokalnych kont użytkowników na przełącznikach, przenosząc zarządzanie uprawnieniami na scentralizowane serwery bezpieczeństwa (Cisco ISE, FreeRADIUS, Microsoft NPS).

Model AAA stanowi logiczny szkielet każdej architektury kontroli dostępu w sieci teleinformatycznej. Rozdzielenie procesu na trzy odrębne fazy pozwala na precyzyjne egzekwowanie zasady najmniejszych uprawnień (Principle of Least Privilege). Nawet jeżeli użytkownik pomyślnie potwierdzi swoją tożsamość w procesie uwierzytelniania, to dopiero silnik autoryzacji decyduje, do jakich konkretnie urządzeń, komend i stref sieciowych ma on w danej chwili uprawnienia, podczas gdy moduł rozliczalności rejestruje każde podjęte działanie.

Warto podkreślić różnicę między uwierzytelnianiem a autoryzacją na prostym przykładzie akademickim: legitymacja studencka potwierdza tożsamość studenta (uwierzytelnianie), jednak to wpis w systemie dziekanatowym określa, do których laboratoriów i sal ma on prawo wstępu (autoryzacja). W architekturze AAA serwer centralny może po pomyślnym uwierzytelnieniu nadać studentowi dostęp wyłącznie do sieci Wi-Fi w bibliotece, podczas gdy pracownikowi naukowemu przydzieli dostęp do serwerów klastra obliczeniowego.

Skróty użyte w tym slajdzie:
Authentication (AAA Authentication) - Proces weryfikacji tożsamości użytkownika lub urządzenia żądającego dostępu do infrastruktury.
Authorization (AAA Authorization) - Proces określania zakresu uprawnień i dozwolonych poleceń dla uwierzytelnionego podmiotu.
Accounting (AAA Accounting) - Rejestrowanie informacji o czasie trwania sesji, przesłanych danych i wykonanych poleceniach administracyjnych.

Pierwszy filar AAA - Uwierzytelnianie (Authentication) - odpowiada na pytanie: "Kim jesteś?". Weryfikuje deklarowaną tożsamość użytkownika na podstawie poświadczeń: hasła, certyfikatu cyfrowego X.509 lub tokena kryptograficznego.

Zgodnie z zasadami redundancji urządzenie sieciowe konfiguruje się z listą serwerów uwierzytelniających: w przypadku braku odpowiedzi serwera głównego zapytanie trafia do serwera zapasowego, a lokalna baza kont jest aktywowana w razie braku dostępności serwerów AAA.

W kampusie akademickim proces uwierzytelniania musi radzić sobie z heterogenicznym środowiskiem użytkowników: studentami, kadrą naukową, personelem administracyjnym oraz zewnętrznymi serwisantami. Wdrażanie lokalnych baz użytkowników na każdym przełączniku z osobna prowadzi do chaosu i luk bezpieczeństwa. Zamiast tego urządzenia sieciowe konfiguruje się jako klientów AAA odpytujących centralne serwery uwierzytelniające (np. Cisco ISE lub FreeRADIUS), które weryfikują hasła w scentralizowanej bazie tożsamości.

Skróty użyte w tym slajdzie:
Local Auth (Local User Database) - Lokalna baza użytkowników zdefiniowana bezpośrednio w pamięci przełącznika jako metoda awaryjna fallback.

Drugi filar AAA - Autoryzacja (Authorization) - odpowiada na pytanie: "Co masz prawo zrobić?". Po pomyślnym uwierzytelnieniu serwer określa poziom uprawnień inżyniera, przypisując go do odpowiedniego poziomu Privilege Level (od 1 do 15 w systemie Cisco IOS).

Autoryzacja może mieć charakter statyczny (przypisanie poziomu uprawnień) lub granularny (weryfikacja każdego pojedynczego polecenia CLI przed jego wykonaniem na przełączniku).

Autoryzacja poleceń w systemach sieciowych klasy enterprise (np. Cisco IOS-XE) opiera się na 16 poziomach uprawnień (od 0 do 15) lub zaawansowanych widokach ról (Role-Based CLI Views). Inżynier poziomu 1 może mieć prawo wyłącznie do wykonywania podstawowych poleceń diagnostycznych show i ping, podczas gdy uprawnienia poziomu 15 (enable) dają pełną kontrolę nad konfiguracją interfejsów i protokołów routingu. Dzięki protokołowi TACACS+ każde wprowadzone w terminalu polecenie jest indywidualnie autoryzowane przez serwer centralny przed jego wykonaniem.

Skróty użyte w tym slajdzie:
Privilege Level (Cisco IOS Privilege Levels) - Poziomy uprawnień w systemie Cisco (zakres 0-15, gdzie 15 oznacza pełne uprawnienia administratorskie).
Role-Based (Role-Based Access Control (RBAC)) - Nadawanie uprawnień do komend na podstawie przypisanych ról administracyjnych (np. operator, audytor, administrator).

Trzeci filar AAA - Rozliczalność (Accounting) - odpowiada na pytanie: "Co faktycznie zrobiłeś i kiedy?". Rejestruje dokładny czas rozpoczęcia i zakończenia sesji oraz historię komend wprowadzonych przez inżyniera w trybie tekstowym.

Dane rozliczeniowe przesyłane są na dedykowane serwery audytowe w czasie rzeczywistym (komunikaty Start-Stop), co znacznie utrudnia zatarcie śladów nieautoryzowanych modyfikacji w przypadku kompromitacji urządzenia.

Funkcja rozliczalności (Accounting) generuje szczegółowe rekordy audytowe dla każdej sesji administracyjnej. Rejestrowany jest dokładny czas rozpoczęcia i zakończenia sesji, adres IP stacji inżyniera, metoda logowania oraz każde wykonane polecenie wraz z jego parametrami. Dane te są przesyłane w czasie rzeczywistym do bazy serwera AAA oraz replikowane do centralnego systemu SIEM, co umożliwia odtworzenie przebiegu zdarzeń w przypadku wystąpienia incydentu bezpieczeństwa lub awarii konfiguracyjnej.

Skróty użyte w tym slajdzie:
Syslog (System Logging Protocol) - Standardowy protokół przesyłania zdarzeń systemowych do centralnego serwera logów (RFC 5424).
Audit Compliance (Compliance Audit Trail) - Zgodność procedur rejestracji zdarzeń z wymaganiami prawnymi (RODO, KRI, PN-EN ISO/IEC 27001).

Protokół RADIUS (RFC 2865) to powszechny standard AAA wykorzystujący transport UDP (porty 1812 dla autoryzacji i 1813 dla accountingu). Charakteryzuje się połączeniem funkcji uwierzytelniania i autoryzacji w jednym pakiecie odpowiedzi (Access-Accept).

Krytyczną cechą protokołu RADIUS jest szyfrowanie wyłącznie pola hasła użytkownika za pomocą algorytmu MD5; pozostała część pakietu (w tym nazwa użytkownika i atrybuty) jest przesyłana tekstem jawnym, co czyni go podatnym na podsłuch w niezaufanych sieciach.

Protokół RADIUS (Remote Authentication Dial-In User Service, RFC 2865) wykorzystuje bezpołączeniowy protokół UDP (porty 1812 dla uwierzytelniania i 1813 dla rozliczalności). Kluczową cechą architektury RADIUS jest połączenie fazy uwierzytelniania i autoryzacji w pojedynczą parę komunikatów Access-Request i Access-Accept. Poważnym ograniczeniem bezpieczeństwa tego protokołu jest fakt, że szyfrowaniu podlega wyłącznie pole hasła użytkownika za pomocą algorytmu MD5 ze współdzielonym kluczem, natomiast pozostała część pakietu przesyłana jest otwartym tekstem.

Skróty użyte w tym slajdzie:
Shared Secret (RADIUS Shared Secret) - Klucz współdzielony wykorzystywany do zabezpieczenia komunikacji pomiędzy klientem NAS a serwerem RADIUS.

Protokół TACACS+ (RFC 8907) to zaawansowany protokół klasy AAA zoptymalizowany pod kątem bezpiecznego zarządzania urządzeniami sieciowymi. W odróżnieniu od RADIUS wykorzystuje niezawodny transport TCP na porcie 49 oraz szyfruje całe ciało każdego pakietu danych.

TACACS+ niezależnie realizuje procesy uwierzytelniania, autoryzacji i rozliczalności. Umożliwia wdrożenie autoryzacji komend (Per-Command Authorization), odpytując serwer o zgodę przed wykonaniem każdego polecenia wpisanego przez inżyniera.

Protokół TACACS+ (Terminal Access Controller Access-Control System Plus, zdefiniowany jako standard otwarty w RFC 8907) został zaprojektowany z myślą o kompleksowym zarządzaniu urządzeniami sieciowymi. W przeciwieństwie do protokołu RADIUS, TACACS+ opiera się na niezawodnym protokole połączeniowym TCP (port 49) oraz szyfruje całe ciało pakietu, zapewniając pełną poufność wymienianych atrybutów. Dodatkowo w pełni separuje moduły uwierzytelniania, autoryzacji i rozliczalności, co pozwala na autoryzację każdego polecenia CLI z osobna.

Szyfrowanie całego pakietu w protokole TACACS+ opiera się na operacji XOR z pseudolosowym ciągiem bajtów generowanym przy użyciu funkcji skrótu MD5 ze współdzielonym kluczem tajnym (Shared Secret). Choć funkcja MD5 jest obecnie uznawana za kryptograficznie złamaną w zastosowaniach weryfikacji podpisów, to w protokole TACACS+ w połączeniu z odpowiednio długim (minimum 16-24 znaki) i złożonym hasłem współdzielonym oraz dedykowaną siecią OOBM zapewnia wysoki poziom ochrony przed podsłuchem wewnątrz sieci.

Skróty użyte w tym slajdzie:
TCP Port 49 (TACACS+ Transport Port) - Dedykowany port protokołu TCP wykorzystywany przez protokół TACACS+ gwarantujący niezawodność dostarczenia pakietów.
Payload Encryption (Full Payload Encryption) - Cecha protokołu TACACS+ polegająca na szyfrowaniu całego ładunku pakietu z wyjątkiem standardowego nagłówka.

Zestawienie porównawcze jednoznacznie wskazuje obszary zastosowań obu standardów: RADIUS jest standardem dedykowanym do kontroli dostępu użytkowników końcowych do sieci (IEEE 802.1X w sieciach Wi-Fi i przewodowych), gdzie liczy się prosta obsługa atrybutów VLAN.

Z kolei TACACS+ jest standardem do zarządzania urządzeniami sieciowymi (Device Administration), zapewniając pełną poufność komunikacji administratorskiej oraz granularną kontrolę nad komendami w trybie CLI.

W dojrzałym projekcie sieci kampusowej oba protokoły znajdują swoje komplementarne zastosowanie: RADIUS jest niezastąpionym standardem do kontroli dostępu do medium transmisyjnego (Network Access), takiego jak uwierzytelnianie użytkowników w sieciach Wi-Fi (standard 802.1X / EAP) oraz portach przełączników dostępowych. Z kolei TACACS+ stanowi bezwzględny wymóg inżynierski w obszarze administracji urządzeniami (Device Administration), zapewniając rygorystyczny nadzór nad poleceniami CLI administratorów.

Skróty użyte w tym slajdzie:
Command Auth (Per-Command Authorization) - Unikalna funkcja protokołu TACACS+ umożliwiająca autoryzację każdego pojedynczego polecenia CLI na serwerze.

Wdrożenie klienta TACACS+ na przełącznikach Cisco wymaga aktywacji modelu AAA (aaa new-model), zdefiniowania grupy serwerów TACACS+ z silnymi kluczami współdzielonymi oraz powiązania list autoryzacji z liniami terminalowymi.

Konfiguracja dyrektywy aaa authorization commands 15 default group TACACS_GROUP local wymusza odpytanie serwera o każde polecenie poziomu 15, wspierając zgodność z procedurami bezpieczeństwa teleinformatycznego uczelni.

Konfiguracja dyrektyw AAA na urządzeniach brzegowych i rdzeniowych wymaga zdefiniowania list metod fallback. Kluczowe jest skonfigurowanie opcji lokalnego uwierzytelniania (local) jako metody zapasowej na wypadek całkowitego braku łączności z serwerami TACACS+ (np. aaa authentication login default group TACACS_GROUP local). Brak takiego zabezpieczenia w przypadku awarii sieci OOB odciąłby inżynierów od dostępu do przełączników, z kolei niewłaściwe ustawienie kolejności metod mogłoby umożliwić logowanie lokalne przed sprawdzeniem serwera centralnego.

Skróty użyte w tym slajdzie:
AAA New-Model (AAA New-Model CLI Command) - Globalne polecenie Cisco IOS aktywujące nowoczesną architekturę podsystemu AAA.
Server Group (TACACS+ Server Group) - Grupa serwerów AAA definiowana w konfiguracji urządzenia gwarantująca redundancję w przypadku awarii węzła głównego.

Centralizacja tożsamości inżynierów opiera się na integracji serwerów AAA (np. Cisco ISE) z uczelnianą usługą katalogową Microsoft Active Directory lub serwerami OpenLDAP za pomocą bezpiecznych protokołów LDAPS lub Kerberos.

Dzięki temu uprawnienia administratorskie są ściśle powiązane z członkostwem w grupach bezpieczeństwa AD (Role-Based Access Control - RBAC). Zablokowanie konta pracownika w domenie odbiera mu dostęp przy kolejnym logowaniu.

Integracja serwera AAA z uczelnianą infrastrukturą Microsoft Active Directory lub serwerami OpenLDAP realizowana jest przez bezpieczny protokół LDAPS (port TCP 636) z weryfikacją łańcucha certyfikatów X.509. Pozwala to na powiązanie profili uprawnień sieciowych z grupami bezpieczeństwa w domenie uczelnianej. Gdy pracownik działu IT zmienia stanowisko lub odchodzi z uczelni, odebranie uprawnień w domenie Active Directory natychmiastowo skutkuje zablokowaniem dostępu do wszystkich przełączników, ruterów i zapór w całym kampusie.

Skróty użyte w tym slajdzie:
LDAP (Lightweight Directory Access Protocol) - Protokół usług katalogowych (RFC 4511) integrujący serwery AAA z centralną bazą tożsamości uczelni.
Active Directory (Microsoft Active Directory (AD)) - Korporacyjna usługa katalogowa integrująca uwierzytelnianie Kerberos i bazy danych użytkowników.

Uwierzytelnianie wieloskładnikowe (MFA / 2FA) to obowiązkowy wymóg bezpieczeństwa w dostępie zdalnym. Wymaga przedstawienia co najmniej dwóch niezależnych składników: czegoś, co wiesz (hasło), czegoś, co masz (token sprzętowy) lub czym jesteś (biometria).

Zastosowanie MFA znacznie redukuje ryzyko udanego ataku w przypadku ujawnienia hasła pracownika w wyniku phishingu lub wycieku poświadczeń z innych serwisów internetowych.

Wdrożenie uwierzytelniania wieloskładnikowego MFA dla dostępu zdalnego i uprzywilejowanego jest obecnie bezwzględnym wymogiem określonym w wytycznych normy ISO/IEC 27001 oraz dyrektywie NIS 2. Tradycyjne hasła są podatne na przełamanie w wyniku ataków socjotechnicznych, przechwycenia na zawirusowanych stacjach roboczych czy wycieków z serwisów zewnętrznych. Wymuszenie drugiego, niezależnego składnika autoryzacji gwarantuje, że samo posiadanie hasła nie pozwala atakującemu na zestawienie sesji VPN czy zalogowanie do serwera skokowego.

Z technicznego punktu widzenia wdrożenie MFA w sieci kampusowej integruje się zazwyczaj na poziomie serwerów RADIUS za pośrednictwem rozszerzenia EAP (Extensible Authentication Protocol) lub dedykowanych wtyczek NPS (Network Policy Server). Podczas nawiązywania połączenia VPN użytkownik po podaniu hasła otrzymuje żądanie autoryzacji (Challenge-Response), które wymaga wprowadzenia jednorazowego kodu TOTP lub dotknięcia sprzętowego klucza FIDO2 podłączonego do portu USB stacji roboczej.

Skróty użyte w tym slajdzie:
2FA (Two-Factor Authentication) - Uwierzytelnianie dwuskładnikowe wymagające podania hasła oraz dynamicznego kodu jednorazowego.
TOTP (Time-Based One-Time Password) - Standard generowania haseł jednorazowych zależnych od aktualnego znacznika czasu (RFC 6238).

Analiza metod MFA wykazuje różny poziom odporności na ataki: kody SMS i wiadomości e-mail są podatne na przechwycenie (SIM Swapping), a powiadomienia Push na smartfonie na ataki MFA Fatigue (push bombing).

W praktyce wdrożeniowej preferowanym rozwiązaniem o wysokim poziomie bezpieczeństwa są sprzętowe klucze kryptograficzne zgodne ze standardem FIDO2 / WebAuthn (np. klucze YubiKey), które są kryptograficznie związane z domeną i odporne na phishing.

Tradycyjne metody MFA, takie jak kody wysyłane w wiadomościach SMS lub powiadomienia w aplikacjach mobilnych na smartfonie, wykazują podatność na ataki typu SIM Swapping, phishing w czasie rzeczywistym (np. przy użyciu platformy Evilginx) oraz ataki zmęczeniowe (MFA Fatigue / Prompt Bombing). Z tego względu w sieciach o podwyższonych rygorach bezpieczeństwa standardem stają się sprzętowe klucze kryptograficzne USB/NFC zgodne ze standardem FIDO2 / WebAuthn. Klucze te wykonują kryptograficzne podpisanie wyzwania powiązanego z adresem domeny serwera, co całkowicie uniemożliwia ich wyłudzenie na fałszywej stronie internetowej.

Skróty użyte w tym slajdzie:
FIDO2 (Fast Identity Online 2) - Otwarty standard silnego uwierzytelniania bezhasłowego oparty na kryptografii asymetrycznej i sprzętowych kluczach bezpieczeństwa.
U2F (Universal 2nd Factor) - Standard fizycznych tokenów kryptograficznych (np. YubiKey) odpornych na ataki phishingowe.

Zabezpieczenie stacji inżynierskich (Privileged Access Workstations - PAW) wymaga odseparowania komputerów używanych do zarządzania rdzeniem sieci od codziennej pracy biurowej (przeglądania Internetu i poczty elektronicznej).

Stacje PAW podlegają rygorystycznemu utwardzeniu: szyfrowanie dysków (BitLocker/LUKS), wymóg logowania kluczami sprzętowymi, izolacja sieciowa oraz blokada instalacji nieautoryzowanego oprogramowania za pomocą polityk AppLocker.

Koncepcja uprzywilejowanych stacji roboczych (Privileged Access Workstations - PAW) polega na fizycznym lub logicznym odseparowaniu sprzętu wykorzystywanego do zarządzania krytyczną infrastrukturą sieciową od codziennej aktywności biurowej. Stacja inżynierska nie może służyć do przeglądania stron WWW ani odbierania poczty elektronicznej, które stanowią główny wektor infekcji złośliwym oprogramowaniem. Urządzenia te posiadają włączone szyfrowanie dysków (BitLocker lub LUKS), zablokowane porty USB dla pamięci masowych oraz zintegrowane systemy EDR monitorujące integralność procesów systemowych.

Skróty użyte w tym slajdzie:
PAW (Privileged Access Workstation) - Dedykowana, maksymalnie utwardzona stacja robocza wykorzystywana wyłącznie do zadań administracji siecią.
Endpoint Security (Endpoint Protection Platform) - Oprogramowanie antywirusowe i EDR monitorujące integralność stacji administratorów.

Nowoczesne zarządzanie infrastrukturą sieciową odchodzi od ręcznej konfiguracji przez CLI na rzecz automatyzacji w modelu Infrastructure as Code (IaC) z wykorzystaniem narzędzi Ansible, Python oraz repozytoriów Git (GitOps).

Automatyzacja ogranicza błędy ludzkie (Human Error), zapewnia powtarzalność wdrożeń w budynkach kampusu oraz umożliwia automatyczny audyt zgodności konfiguracji urządzeń z politykami bezpieczeństwa w trybie ciągłym.

Ręczne wprowadzanie poleceń w konsoli CLI stwarza wysokie ryzyko popełnienia błędu ludzkiego (Human Error) oraz prowadzi do dryfu konfiguracji (Configuration Drift), w którym stan urządzeń w kampusie rozbiega się z dokumentacją projektową. Nowoczesne podejście inżynierskie zakłada traktowanie konfiguracji sieciowej jako kodu (Infrastructure as Code - IaC). Narzędzia takie jak Ansible, NAPALM czy Terraform pobierają zatwierdzone szablony konfiguracji z repozytorium Git, sprawdzają zgodność i automatycznie aplikują zmiany na setkach przełączników w sposób powtarzalny i audytowalny.

Skróty użyte w tym slajdzie:
GitOps (GitOps Infrastructure as Code) - Metodyka zarządzania konfiguracją sieciową polegająca na wersjonowaniu plików konfiguracyjnych w repozytorium Git.
Ansible (Ansible Automation Platform) - Bezagentowe narzędzie do automatyzacji konfiguracji i orkiestracji urządzeń sieciowych przez protokół SSH.

Procedury Disaster Recovery obejmują działania awaryjne w przypadku utraty haseł administratorskich lub awarii serwerów AAA. W systemach Cisco wykorzystuje się wówczas modyfikację rejestru konfiguracyjnego (Config-Register 0x2142 w trybie ROMMON), co pozwala na ominięcie pliku startup-config.

Jednak na przełącznikach zlokalizowanych w miejscach publicznych standardem inżynierskim jest zabezpieczenie procedury poleceniem no service password-recovery, które uniemożliwia zresetowanie hasła bez uprzedniego całkowitego wyczyszczenia pamięci Flash, chroniąc przed kradzieżą konfiguracji.

Procedury Disaster Recovery muszą precyzować formalne ścieżki postępowania w sytuacjach krytycznych, takich jak utrata haseł roota, kompromitacja kluczy kryptograficznych czy całkowite uszkodzenie oprogramowania układowego przełącznika. Zastosowanie komendy no service password-recovery w urządzeniach Cisco chroni wprawdzie przed nieautoryzowanym odczytem pliku konfiguracyjnego w trybie ROMMON, lecz wymaga od inżynierów posiadania aktualnych, zaszyfrowanych kopii zapasowych konfiguracji w bezpiecznym repozytorium sieciowym, gdyż jedyną metodą odzyskania urządzenia jest całkowite wyczyszczenie pamięci NVRAM.

Skróty użyte w tym slajdzie:
Config Register (Configuration Register) - 16-bitowy rejestr procesora routera decydujący o sposobie ładowania systemu (0x2102 vs 0x2142 do pomijania NVRAM).
Password Recovery (Disaster Password Recovery) - Procedura odzyskiwania dostępu administracyjnego do urządzenia sieciowego z pominięciem pliku startup-config.

Podsumowanie wykładu systematyzuje architekturę bezpiecznego zarządzania: zakaz transmisji niezaszyfrowanej, fizyczną separację sieci OOB z łączami LTE, szyfrowany dostęp SSHv2 i VPN, centralizację tożsamości TACACS+/FIDO2 oraz automatyzację procedur audytowych.

Zintegrowane wdrożenie tych mechanizmów tworzy wielowarstwową barierę ochronną (Defense-in-Depth), wspierając poufność i ochronę rdzenia teleinformatycznego uczelni.

Podsumowując zagadnienia wykładu, należy podkreślić, że bezpieczeństwo płaszczyzny zarządzania wymaga podejścia holistycznego. Pojedynczy mechanizm obronny - niezależnie od tego, czy jest to szyfrowanie SSHv2, dedykowana sieć OOBM, czy serwer TACACS+ - nie zapewni pełnej ochrony przed zdeterminowanym intruzem. Dopiero synergiczne połączenie fizycznej separacji, silnej kryptografii, scentralizowanej kontroli tożsamości z uwierzytelnianiem FIDO2 oraz automatycznego audytu tworzy barierę odporną na współczesne cyberzagrożenia.

Skróty użyte w tym slajdzie:
Management Summary (Secure Management Architecture Summary) - Synteza standardów bezpiecznego zarządzania: separacja OOBM, szyfrowanie SSH/VPN, centralizacja AAA TACACS+.

Wykład 9 zamyka moduł programowy poświęcony zabezpieczeniu płaszczyzny zarządzania i dostępu zdalnego. Kolejny, ostatni wykład serii przenosi punkt ciężkości na bezpieczeństwo płaszczyzny danych oraz zaawansowaną analitykę sieciową.

Wykład 10 poświęcony będzie całościowej architekturze bezpieczeństwa sieci kampusowej: zaporom ogniowym nowej generacji (NGFW), systemom wykrywania intruzów IPS/IDS, segmentacji TrustSec, listom kontroli dostępu ACL oraz nadzorowi telemetrycznemu NetFlow/IPFIX i SIEM.

Zabezpieczenie płaszczyzny zarządzania stanowi fundament, na którym w kolejnym module zbudujemy architekturę ochrony płaszczyzny danych oraz monitorowania ruchu. Podczas Wykładu 10 szczegółowo przeanalizujemy zasady działania zapór sieciowych nowej generacji (NGFW), mechanizmy wewnętrznej segmentacji ISFW, zaawansowane zabezpieczenia portów w warstwie 2 przełączania (802.1X, DAI, DHCP Snooping) oraz nowoczesne systemy telemetrii sieciowej oparte na protokołach IPFIX, Syslog i SIEM.

Skróty użyte w tym slajdzie:
Network Security (Campus Network Security Architecture) - Całościowa architektura bezpieczeństwa sieci kampusowej obejmująca zapory NGFW, NAT, DMZ i telemetrię.