Linux Hardening: SSH to nie tylko port 22. Jak naprawdę zabezpieczyć zdalny dostęp do serwera

SSH jest jedną z tych technologii, które paradoksalnie są jednocześnie symbolem bezpieczeństwa i jednym z najczęściej atakowanych elementów infrastruktury. To właśnie przez Secure Shell administratorzy zarządzają serwerami w chmurze, Raspberry Pi, maszynami wirtualnymi i środowiskami produkcyjnymi. Gdyby spojrzeć na logi dowolnego VPS-a z publicznym adresem IP, szybko okaże się, że jeszcze przed zakończeniem pierwszej kawy ktoś już próbuje się do niego zalogować.

To nie jest atak wymierzony w Ciebie osobiście. Internet pełen jest botów, które nieustannie skanują kolejne adresy IPv4, szukając otwartego portu 22. Gdy tylko go znajdą, rozpoczynają serię prób logowania z wykorzystaniem najpopularniejszych nazw użytkowników i słowników haseł. Większość tych prób zakończy się niepowodzeniem, ale dobrze skonfigurowany serwer powinien być odporny również na sytuację, w której ktoś poświęci mu znacznie więcej uwagi.

Największym błędem jest myślenie o SSH jako pojedynczym ustawieniu w pliku sshd_config. W rzeczywistości bezpieczeństwo zdalnego dostępu składa się z kilku warstw, które wzajemnie się uzupełniają.

Dlaczego sam protokół SSH nie jest problemem?

SSH od lat uchodzi za jeden z najlepiej zaprojektowanych protokołów administracyjnych. Zapewnia szyfrowanie komunikacji, uwierzytelnianie oraz integralność danych. Problem nie leży więc w samym protokole, lecz w sposobie jego konfiguracji.

W praktyce większość udanych włamań nie wynika z „złamania SSH”. Znacznie częściej przyczyną jest jedna z następujących sytuacji:

• pozostawione logowanie hasłem,
• możliwość logowania jako root,
• zbyt wiele prób uwierzytelnienia,
• brak ograniczeń dla użytkowników,
• brak monitorowania logów.

To dobra wiadomość, ponieważ wszystkie te problemy można wyeliminować bez instalowania dodatkowego oprogramowania.

Pierwsza zasada: zapomnij o użytkowniku root

Konto root jest najbardziej przewidywalnym celem atakujących. Bot nie musi zgadywać nazwy użytkownika — zna ją od początku. Wystarczy, że będzie próbował kolejnych haseł.

Dlatego pierwszą zmianą powinno być wyłączenie możliwości bezpośredniego logowania jako root.

W pliku:

/etc/ssh/sshd_config

warto upewnić się, że znajduje się wpis:

PermitRootLogin no

Od tej chwili administracja odbywa się przez zwykłe konto posiadające uprawnienia sudo.

Schemat wygląda wtedy znacznie bezpieczniej.

Internet
    │
    ▼
Użytkownik
    │
    ▼
SSH
    │
    ▼
Konto administratora
    │
    ▼
sudo
    │
    ▼
root

To niewielka zmiana, ale ma ogromne znaczenie podczas automatycznych ataków.

Hasło to już za mało

Jeszcze kilka lat temu silne hasło uznawano za wystarczające zabezpieczenie.

Dzisiaj sytuacja wygląda inaczej.

Atakujący dysponują ogromnymi słownikami haseł oraz mocą obliczeniową pozwalającą wykonywać tysiące prób logowania.

Dlatego najlepszym rozwiązaniem pozostaje logowanie wyłącznie za pomocą kluczy.

Klucz Ed25519 można wygenerować poleceniem:

Bash

ssh-keygen -t ed25519 -C "admin@netbe"

Powstają dwa pliki.

id_ed25519
id_ed25519.pub

Prywatny klucz pozostaje na komputerze administratora.

Publiczny trafia na serwer.

Dzięki temu serwer nie przechowuje tajnego klucza użytkownika, a jedynie informację pozwalającą zweryfikować jego tożsamość.

To znacznie lepszy model niż przesyłanie hasła przy każdym logowaniu.

Wyłączenie logowania hasłem

Samo dodanie klucza nie wystarczy.

Jeżeli pozostawimy logowanie hasłem jako metodę awaryjną, atakujący nadal będzie mógł próbować zgadywać hasła.

Dlatego warto zmienić konfigurację na:

PasswordAuthentication no
PubkeyAuthentication yes

Od tej chwili jedyną akceptowaną metodą logowania staje się klucz publiczny.

To jedna z najskuteczniejszych zmian, jakie można wprowadzić w kilka minut.

Czy warto zmieniać port 22?

To pytanie wraca regularnie.

Krótka odpowiedź brzmi:

tak, ale z właściwych powodów.

Zmiana portu nie jest pełnoprawnym mechanizmem bezpieczeństwa.

Nie zatrzyma ukierunkowanego ataku.

Nie ukryje serwera przed profesjonalnym skanerem.

Może jednak znacząco ograniczyć ilość automatycznego szumu generowanego przez boty skanujące wyłącznie port 22.

Wyobraźmy sobie dwa serwery.

Pierwszy:

203.0.113.10:22

Drugi:

203.0.113.10:40222

Oba pozostają widoczne.

Różnica polega na tym, że pierwszy będzie otrzymywał znacznie więcej przypadkowych prób logowania.

To nie zastępuje prawdziwych zabezpieczeń.

Po prostu zmniejsza ilość niepotrzebnego ruchu.

Ograniczenie liczby prób logowania

Kolejnym elementem jest ograniczenie zachowania klienta SSH.

Dobrym zestawem ustawień pozostaje:

LoginGraceTime 30
MaxAuthTries 3
MaxSessions 2

Każde z nich rozwiązuje inny problem.

LoginGraceTime ogranicza czas oczekiwania na uwierzytelnienie.

MaxAuthTries utrudnia zgadywanie kolejnych metod logowania.

MaxSessions zmniejsza możliwość nadużywania wielu równoczesnych sesji.

To drobne zmiany.

Ale właśnie z takich drobnych zmian składa się dobry hardening.

Pozwól wejść tylko tym, którzy naprawdę potrzebują dostępu

Jednym z najbardziej niedocenianych parametrów jest:

AllowUsers

Zamiast pozwalać logować się każdemu lokalnemu użytkownikowi systemu, można jawnie wskazać dozwolone konta.

Przykład:

AllowUsers admin deploy backup

To prosty mechanizm ograniczający powierzchnię ataku.

Nawet jeżeli ktoś utworzy przypadkowe konto lokalne, nie oznacza to automatycznie możliwości logowania przez SSH.

Firewall powinien współpracować z SSH

Po zmianie portu łatwo popełnić kosztowny błąd.

Administrator edytuje konfigurację SSH.

Restartuje usługę.

I nagle traci dostęp do serwera.

Dlatego kolejność ma znaczenie.

Najpierw należy otworzyć nowy port.

Przykład dla UFW:

Bash

sudo ufw allow 40222/tcp

Dopiero później restartować usługę.

To jedna z tych pomyłek, którą popełnia się tylko raz.

Fail2Ban nie zastępuje firewalla

Wiele osób myli te dwa narzędzia.

Firewall odpowiada na pytanie:

„Czy pakiet może wejść?”

Fail2Ban odpowiada na inne pytanie:

„Czy ten adres IP zachowuje się podejrzanie?”

Schemat wygląda następująco.

Internet
    │
    ▼
SSH
    │
    ▼
Logi systemowe
    │
    ▼
Fail2Ban
    │
    ▼
Blokada IP

To bardzo skuteczny sposób walki z automatycznymi botami wykonującymi setki prób logowania.

Nie zastępuje on poprawnej konfiguracji SSH.

Stanowi kolejną warstwę ochrony.

Logi mówią więcej niż dashboard

Jednym z najlepszych nawyków administratora jest regularne zaglądanie do logów uwierzytelniania.

W Ubuntu najczęściej interesuje nas:

Bash

sudo journalctl -u ssh

lub klasyczny log:

/var/log/auth.log

To właśnie tam najłatwiej zauważyć:

• powtarzające się próby logowania,
• błędne konfiguracje,
• problemy z kluczami,
• nietypowe zachowanie użytkowników.

Dobry administrator nie czeka na alarm.

Uczy się rozpoznawać normalne zachowanie systemu.

A co z nowoczesnymi algorytmami szyfrowania?

Współczesne wersje OpenSSH domyślnie korzystają z bardzo bezpiecznych algorytmów.

Warto jednak wiedzieć, które z nich są obecnie uznawane za preferowane.

Najczęściej spotkasz między innymi:

• chacha20-poly1305,
• aes256-gcm,
• curve25519.

Nie trzeba ręcznie zmieniać każdej wartości.

Znacznie ważniejsze jest regularne aktualizowanie samego OpenSSH.

Nowe wersje nie tylko usuwają podatności.

Często wycofują również przestarzałe algorytmy.

Najczęstsze błędy, które nadal widzę

Po latach pracy z serwerami pewne pomyłki powtarzają się wyjątkowo często.

Pierwszą jest pozostawienie aktywnego logowania hasłem „na wszelki wypadek”.

Drugą — testowanie zmian bez drugiej otwartej sesji SSH.

Trzecią — zmiana portu bez aktualizacji reguł firewalla.

Czwartą — praca na koncie root, bo „jest szybciej”.

Każdy z tych błędów wydaje się niewielki.

W praktyce potrafi zdecydować o tym, czy serwer pozostanie bezpieczny.

Checklista SSH Hardening

Po zakończeniu konfiguracji warto przejść przez krótką listę kontrolną.

• Wyłączono PermitRootLogin.
• Włączono logowanie kluczami Ed25519.
• Wyłączono PasswordAuthentication.
• Skonfigurowano AllowUsers.
• Ustawiono LoginGraceTime.
• Ograniczono MaxAuthTries.
• Zweryfikowano reguły UFW lub nftables.
• Przetestowano nowe ustawienia z drugiej sesji SSH.
• Sprawdzono logi po restarcie usługi.
• Rozważono wdrożenie Fail2Ban.

Najważniejsza lekcja

SSH nie powinno być traktowane jako pojedyncza usługa działająca na porcie 22.

To granica pomiędzy światem zewnętrznym a serwerem.

Jeżeli ta granica zostanie zaprojektowana warstwowo — z kluczami publicznymi, wyłączonym rootem, ograniczoną liczbą prób logowania, firewallem i monitorowaniem logów — nawet nieustanny szum automatycznych botów przestaje mieć większe znaczenie.

Największym błędem nie jest pozostawienie portu 22.

Największym błędem jest pozostawienie zbyt wielu możliwości osobie, która próbuje przejść przez tę bramę.

Polecane wpisy

Cyberbezpieczeństwo – najczęściej zadawane pytania i praktyczne odpowiedzi

Cyberbezpieczeństwo – najczęściej zadawane pytania i praktyczne odpowiedzi Cyberbezpieczeństwo to jeden z najważniejszych tematów współczesnej technologii. Codziennie miliony użytkowników Google Czytaj dalej

Odzyskiwanie danych po ataku ransomware z wykorzystaniem shadow copies i innych wbudowanych narzędzi Windows

💾 Odzyskiwanie danych po ataku ransomware z wykorzystaniem shadow copies i innych wbudowanych narzędzi Windows 🔧 Jak je efektywnie używać Czytaj dalej