Który protokół zapewnia szyfrowanie połączenia?
A. DNS
B. TELNET
C. DHCP
D. SSH
Pytanie z egzaminu CKE, październik 2013 (arkusz E.13-X-13.10).
SSH, czyli Secure Shell, to protokół zaprojektowany właśnie do bezpiecznej pracy zdalnej przez sieć. Najważniejsze jest tu szyfrowanie całej sesji: login, hasło, wydawane polecenia i wyniki poleceń nie lecą przez sieć otwartym tekstem. W praktyce SSH działa najczęściej na porcie TCP 22 i jest opisany w rodzinie standardów RFC 4251 i pokrewnych. Stosuje kryptografię asymetryczną do uzgadniania kluczy oraz szyfrowanie symetryczne do przesyłania danych, więc podsłuchanie ruchu nie daje normalnie czytelnej treści. Z mojego doświadczenia to jedna z podstawowych rzeczy, które trzeba znać przy administracji serwerami Linux, przełącznikami, routerami czy systemami NAS. Przez SSH można bezpiecznie logować się na serwer, tunelować połączenia, przesyłać pliki przez SFTP albo SCP i automatyzować zadania skryptami. Dobra praktyka branżowa to wyłączenie logowania roota, używanie kluczy SSH zamiast haseł, pilnowanie uprawnień do plików kluczy oraz aktualizowanie algorytmów kryptograficznych. W porównaniu z Telnetem różnica jest ogromna, bo Telnet przesyła dane jawnie, a SSH powstał po to, żeby tego problemu uniknąć.
W tym pytaniu łatwo pomylić protokoły sieciowe, bo DNS, DHCP, Telnet i SSH wszystkie mogą występować w typowej sieci lokalnej, ale ich zadania są zupełnie inne. DNS służy głównie do tłumaczenia nazw domenowych na adresy IP, na przykład gdy wpisujesz nazwę strony w przeglądarce. Klasyczny DNS nie zapewnia szyfrowania połączenia, choć istnieją nowsze rozwiązania takie jak DNS over HTTPS albo DNS over TLS. To jednak są dodatkowe mechanizmy, a nie podstawowa cecha zwykłego DNS. DHCP z kolei automatycznie przydziela adres IP, bramę domyślną, maskę i serwery DNS komputerom w sieci. Jest bardzo praktyczny, ale nie jest protokołem do bezpiecznego logowania ani szyfrowania sesji użytkownika. Telnet bywa mylący, bo też pozwala na zdalną pracę w terminalu, podobnie jak SSH. Problem w tym, że Telnet przesyła nazwę użytkownika, hasło i komendy otwartym tekstem. Ktoś z dostępem do ruchu sieciowego może to podejrzeć przy pomocy sniffera, i to jest poważny błąd bezpieczeństwa. Moim zdaniem Telnet warto znać historycznie i diagnostycznie, ale w normalnej administracji powinien być zastąpiony przez SSH. Typowy błąd myślowy polega na tym, że ktoś kojarzy protokół z dostępem zdalnym i automatycznie zakłada, że jest bezpieczny. W branży tak się nie robi: zawsze sprawdza się, czy protokół zapewnia poufność, integralność i sensowne uwierzytelnianie. Właśnie dlatego poprawną odpowiedzią jest SSH, a nie DNS, DHCP ani Telnet.