Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP
Poznaj powody, dla których protokoły przesyłające dane jawnym tekstem, takie jak Telnet, FTP i HTTP, ujawniają dane uwierzytelniające, oraz dowiedz się, jak ich szyfrowane zamienniki (SSH, SFTP, HTTPS) rozwiązują te problemy.
Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP to bezpłatna lekcja Security+ Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Security+ Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Security+ Academy zawiera 4 lekcji w sumie.
Problem z protokołami przesyłającymi dane jawnym tekstem
Wiele podstawowych protokołów internetowych zaprojektowano w latach 70. i 80., gdy bezpieczeństwo nie było najważniejszym priorytetem. Protokoły przesyłające dane jawnym tekstem przesyłają wszystkie dane — w tym nazwy użytkowników, hasła i informacje poufne — w postaci jawnego tekstu przez sieć. Każde urządzenie w tym samym segmencie sieci lub dowolny system, przez który przechodzą pakiety, może przechwycić i odczytać ten ruch za pomocą ogólnodostępnych narzędzi, takich jak Wireshark. W środowiskach z przełącznikami sieciowymi, które zwykle izolują ruch między portami, spoofing ARP może przekierować ruch do systemu atakującego, przez co protokoły przesyłające dane jawnym tekstem są niebezpieczne nawet w „wewnętrznych” sieciach.
# What an attacker sees on the wire with Telnet
# (captured via Wireshark or tcpdump)
tcpdump -i eth0 -A port 23
# Sample Telnet capture output:
..login: admin..
..password: S3cr3tPa$$...
..$ ls -la /etc/passwd..
# Every keystroke is visible in plaintext
# Credentials, commands, and file contents - all exposedTelnet a SSH
Telnet (port TCP 23) zapewnia zdalny dostęp do wiersza poleceń systemów, ale przesyła wszystko w postaci jawnego tekstu. Nie ma wbudowanego uwierzytelniania wykraczającego poza nazwę użytkownika i hasło, które są przesyłane bez szyfrowania. SSH (Secure Shell) (port TCP 22) zastępuje Telnet szyfrowanym i uwierzytelnionym kanałem. SSH wykorzystuje asymetryczną wymianę kluczy w celu ustanowienia klucza sesji, a następnie szyfruje całą dalszą komunikację za pomocą szyfrowania symetrycznego. SSH uwierzytelnia również serwer (zapobiegając podszywaniu się pod serwer) i oprócz uwierzytelniania hasłem obsługuje uwierzytelnianie kluczem publicznym (bez hasła, ale bezpieczniejsze niż hasła).
# SSH connection (encrypted, server authenticated)
ssh admin@192.168.1.10
# SSH key-based authentication (no password)
ssh -i ~/.ssh/id_rsa admin@192.168.1.10
# Generate SSH key pair
ssh-keygen -t ed25519 -C 'admin@company.com'
# Copy public key to server
ssh-copy-id -i ~/.ssh/id_rsa.pub admin@192.168.1.10
# Disable Telnet on network devices (Cisco IOS)
no service telnet
line vty 0 4
transport input ssh
login localWymiana kluczy i uwierzytelnianie SSH
Bezpieczeństwo SSH opiera się na solidnym procesie wymiany kluczy. Podczas nawiązywania połączenia klient weryfikuje klucz hosta względem lokalnie przechowywanej kopii — zapobiega to podszywaniu się pod serwer. Jeśli klucz hosta niespodziewanie się zmieni, SSH ostrzega użytkownika (jest to częsty sygnał ataku typu man-in-the-middle). Po zweryfikowaniu serwera uwierzytelnianie klienta może używać: hasła (szyfrowanego podczas przesyłania, ale podatnego na ataki brute force), klucza publicznego (klient potwierdza posiadanie klucza prywatnego; rozwiązanie znacznie silniejsze) lub keyboard-interactive (obsługuje MFA). Organizacje powinny wymuszać uwierzytelnianie oparte na kluczach i wyłączać uwierzytelnianie hasłem w usługach SSH dostępnych z Internetu.
# Harden SSH server configuration
# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no # Require key auth only
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers admin deploy
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ClientAliveInterval 300 # Disconnect idle sessions
ClientAliveCountMax 0
# Restart SSH after changes
systemctl restart sshdFTP a SFTP i FTPS
FTP (File Transfer Protocol) (porty TCP 20/21) przesyła pliki w postaci jawnego tekstu — dane uwierzytelniające, polecenia i dane plików są ujawniane. FTP korzysta również z oddzielnego kanału danych (w trybie pasywnym lub aktywnym), co komplikuje reguły zapory sieciowej. SFTP (SSH File Transfer Protocol) przesyła pliki przez tunel SSH na porcie 22 — jest całkowicie odrębny od FTP i ma z nim wspólną jedynie podobną nazwę. FTPS (FTP Secure) dodaje szyfrowanie TLS do oryginalnego protokołu FTP. SFTP jest ogólnie preferowany, ponieważ korzysta z jednego portu i dziedziczy uwierzytelnianie oraz szyfrowanie SSH. FTP należy wyłączyć we wszystkich systemach produkcyjnych.
# SFTP usage (over SSH, single connection)
sftp admin@fileserver.company.com
sftp> put localfile.zip /uploads/
sftp> get /reports/monthly.pdf .
sftp> ls /uploads/
sftp> exit
# Automated SFTP transfer with key auth
sftp -i ~/.ssh/id_rsa admin@fileserver.company.com <<EOF
put /tmp/report.csv /incoming/
EOF
# Disable FTP on Linux (remove vsftpd)
apt purge vsftpd
# Verify no FTP listener:
ss -tlnp | grep ':21'HTTP a HTTPS
HTTP (port TCP 80) przesyła zawartość stron, w tym dane formularzy, pliki cookie sesji i tokeny uwierzytelniające, w postaci jawnego tekstu. HTTPS (port TCP 443) opakowuje HTTP w TLS, zapewniając szyfrowanie, uwierzytelnianie serwera i integralność danych. Organizacje powinny wymuszać korzystanie z HTTPS wszędzie: przekierowywać cały ruch HTTP do HTTPS (przekierowanie 301), wdrażać HSTS, aby uniemożliwić przeglądarkom łączenie się przez HTTP, oraz konfigurować flagi plików cookie secure i HttpOnly, aby zapobiegać kradzieży tokenów sesji przez HTTP lub JavaScript. Współczesne przeglądarki oznaczają strony HTTP jako „Niezabezpieczone” — HTTPS jest obecnie standardowym wymaganiem wobec wszystkich usług internetowych.
# nginx: force HTTPS redirect
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;
add_header Strict-Transport-Security
'max-age=31536000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
}SNMP v1/v2 a SNMPv3
SNMP (Simple Network Management Protocol) służy do zarządzania urządzeniami sieciowymi i serwerami. SNMPv1 i v2c wykorzystują ciągi wspólnotowe (zasadniczo współdzielone hasła) przesyłane jawnym tekstem — ciągi takie jak „public” (odczyt) i „private” (zapis) są wartościami domyślnymi znanymi atakującym. Atakujący przechwytujący ruch SNMP poznaje ciąg wspólnotowy i może odczytywać konfiguracje urządzeń lub zmieniać ich ustawienia. SNMPv3 dodaje uwierzytelnianie (HMAC-MD5 lub HMAC-SHA) i szyfrowanie (AES) z poświadczeniami przypisanymi do użytkowników, dzięki czemu jest jedyną wersją odpowiednią dla środowisk produkcyjnych. SNMPv1/v2c należy wyłączyć.
# SNMPv3 configuration (Cisco IOS)
snmp-server group MYGROUP v3 priv
snmp-server user MONITORUSER MYGROUP v3 \
auth sha MyAuthP@ss priv aes 128 MyPrivP@ss
# SNMPv3 query from monitoring server
snmpwalk -v3 -l authPriv \
-u MONITORUSER \
-a SHA -A MyAuthP@ss \
-x AES -X MyPrivP@ss \
192.168.1.1 sysDescr
# Disable SNMPv1/v2c:
no snmp-server community public ro
no snmp-server community private rwLDAP a LDAPS
LDAP (Lightweight Directory Access Protocol) (port TCP 389) domyślnie uwierzytelnia użytkowników i odpytuje usługi katalogowe (Active Directory, OpenLDAP) w postaci jawnego tekstu, ujawniając dane uwierzytelniające i dane katalogowe. LDAPS (LDAP over SSL/TLS, port TCP 636) szyfruje połączenie za pomocą certyfikatu. StartTLS to alternatywa, która przełącza istniejące połączenie LDAP na TLS, korzystając z tego samego portu 389. Zarówno LDAPS, jak i StartTLS zapewniają szyfrowanie, jednak LDAPS jest zazwyczaj prostszy i bardziej niezawodny. Organizacje powinny skonfigurować wszystkie aplikacje korzystające z LDAP do używania LDAPS oraz blokować niezabezpieczony LDAP na porcie 389 na zaporze sieciowej.
POP3/IMAP a szyfrowane pobieranie poczty
Starsze klienty poczty pobierają wiadomości za pomocą protokołów POP3 (port 110) i IMAP (port 143) w postaci jawnego tekstu. Szyfrowane alternatywy to: POP3S (port 995, TLS) i IMAPS (port 993, TLS). Nowoczesne platformy pocztowe (Exchange Online, Google Workspace) wymuszają TLS dla wszystkich połączeń klienckich i obsługują uwierzytelnianie oparte na tokenach OAuth 2.0 zamiast haseł. Organizacje powinny wyłączyć uwierzytelnianie podstawowe w protokołach pocztowych — wymaganie nowoczesnego uwierzytelniania (OAuth 2.0 + MFA) zapobiega atakom polegającym na wykorzystaniu wykradzionych danych uwierzytelniających, które wykorzystują jawne mechanizmy uwierzytelniania starszych protokołów pocztowych.
# Protocol port reference card
Protocol Insecure Port Secure Port Replacement
--------- ------------ ---------- -----------
Telnet 23 22 SSH
FTP 20/21 22 SFTP
HTTP 80 443 HTTPS
SMTP 25 587/465 SMTPS
POP3 110 995 POP3S
IMAP 143 993 IMAPS
LDAP 389 636 LDAPS
SNMP 161/162 161/162 SNMPv3
RDP 3389 3389 RDP+NLA+TLSZastępowanie protokołów w praktyce
Zastąpienie niezabezpieczonych protokołów wymaga czegoś więcej niż tylko włączenia bezpiecznej wersji — niezabezpieczoną wersję należy aktywnie wyłączyć. Kroki: przeprowadzić audyt użycia istniejących protokołów (skany Nmap, dzienniki zapory sieciowej), przeprowadzić migrację aplikacji i konfiguracji do bezpiecznego protokołu, dokładnie przetestować rozwiązanie (aplikacje biznesowe mogą przestać działać), a następnie zablokować niezabezpieczony protokół na zaporze sieciowej i hoście. Częste problemy: starsze drukarki i urządzenia wbudowane często obsługują wyłącznie FTP lub SNMPv2; starsze systemy przemysłowe mogą wymagać protokołu Telnet. W takich przypadkach zamiast prostej aktualizacji protokołu konieczna jest izolacja sieciowa lub wymiana urządzenia przez dostawcę.
# Audit for insecure protocol usage
# Nmap: find all Telnet listeners on network
nmap -p 23 10.0.0.0/24 --open -sV
# Find FTP listeners
nmap -p 21 10.0.0.0/24 --open
# Find HTTP (not HTTPS) web services
nmap -p 80 --open 10.0.0.0/24
# Check for SNMPv1/v2c community strings
nmap -sU -p 161 --script snmp-info 10.0.0.0/24
# Block Telnet at firewall after migration
iptables -A FORWARD -p tcp --dport 23 -j DROP
iptables -A INPUT -p tcp --dport 23 -j DROPBezpieczeństwo protokołu Remote Desktop
RDP (Remote Desktop Protocol) (port 3389) jest powszechnie używany do zdalnej administracji systemami Windows i stanowi główny cel ataków. Niezabezpieczone konfiguracje RDP obejmują: udostępnienie portu 3389 w Internecie, używanie wyłącznie uwierzytelniania hasłem oraz wyłączenie NLA. Wzmacnianie zabezpieczeń RDP: należy włączyć Network Level Authentication (NLA), które uwierzytelnia użytkownika przed otwarciem pełnej sesji (blokując nieuwierzytelnione połączenia); wymagać TLS 1.2+ dla wszystkich sesji RDP; umieścić RDP za VPN-em lub bramą RDP, zamiast udostępniać je w Internecie; oraz wymusić blokadę konta, aby zapobiegać atakom brute force. Wiele kampanii ransomware uzyskuje początkowy dostęp za pośrednictwem ujawnionego i niewłaściwie zabezpieczonego RDP.
Etapowe wycofywanie niezabezpieczonych protokołów
Odchodzenie od niezabezpieczonych protokołów w środowiskach produkcyjnych wymaga starannego planowania, aby uniknąć zakłóceń w działalności firmy. Podejście etapowe: Etap 1 — rozpoznanie: uruchomienie skanów Nmap i przeprowadzenie audytu dzienników zapory sieciowej w celu zidentyfikowania wszystkich zastosowań protokołów przesyłających dane jawnym tekstem. Etap 2 — włączenie bezpiecznych alternatyw: skonfigurowanie SSH, SFTP i HTTPS obok istniejących niezabezpieczonych usług. Etap 3 — migracja użytkowników: zaktualizowanie skryptów, aplikacji, narzędzi monitorujących i procedur użytkowników tak, aby korzystały z bezpiecznego protokołu. Etap 4 — wyłączenie i blokada: wyłączenie niezabezpieczonej usługi na każdym hoście oraz zablokowanie portu na zaporze sieciowej. Testowanie na każdym etapie zapobiega awariom środowiska produkcyjnego.
# Phase 4: Disable and block Telnet permanently
# Disable Telnet service on Linux
systemctl stop telnet.socket
systemctl disable telnet.socket
# Block Telnet at iptables
iptables -A INPUT -p tcp --dport 23 -j DROP
iptables -A OUTPUT -p tcp --dport 23 -j DROP
# Save rules
iptables-save > /etc/iptables/rules.v4
# Block at network firewall (Cisco ASA)
access-list OUTSIDE_IN deny tcp any any eq 23
# Verify: should timeout / connection refused
nc -zv 192.168.1.10 23Szybki test
Sprawdź swoją wiedzę na temat zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji poznali Państwo: protokoły przesyłające dane jawnym tekstem (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP), które ujawniają dane uwierzytelniające i dane podczas podsłuchiwania sieci i należy je zastąpić, bezpieczne zamienniki (SSH, SFTP, HTTPS, SNMPv3, LDAPS), które używają szyfrowania TLS lub SSH do ochrony tej samej funkcjonalności, oraz fakt, że zastępowanie protokołów wymaga wyłączenia niezabezpieczonej wersji na poziomie zapory sieciowej i hosta po przeprowadzeniu audytu zależności starszych systemów. Następnie omówimy wersje TLS, zestawy szyfrów i doskonałe utajnienie przekazywania.
Ucz się Security+ Academy dzięki korepetycjom AI — za darmo
Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.
- Kursy
- 30
- Lekcje
- 120
Często zadawane pytania
Czy lekcja „Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP” jest bezpłatna?
Tak — pełny tekst „Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Security+ Academy, przejdź na CoddyKit PRO. Kurs Security+ Academy zawiera 4 lekcji w sumie.
Co nauczysz się w „Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP”?
Poznaj powody, dla których protokoły przesyłające dane jawnym tekstem, takie jak Telnet, FTP i HTTP, ujawniają dane uwierzytelniające, oraz dowiedz się, jak ich szyfrowane zamienniki (SSH, SFTP, HTTP… Ćwiczysz Security+ Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Security+ Academy?
Nie wymagamy żadnego doświadczenia. Security+ Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.
Ile czasu zajmuje lekcja „Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Security+ Academy?
Tak. Każda lekcja Security+ Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Zastępowanie niezabezpieczonych protokołów: Telnet a SSH, FTP a SFTP
- Wersje TLS, zestawy szyfrów i perfect forward secrecy
- Bezpieczny DNS: DNSSEC i DNS over HTTPS (DoH)
- IPsec, protokoły VPN i bezpieczeństwo zdalnego dostępu