O poranku w moim telefonie pojawiła się wiadomość od znajomego, który stracił łączność po SSH/SCP ze swoim serwerem. Z jego słów wynikało, że nic ostatnio nie zmieniał, choć w weekend próbował przeprowadzić aktualizację, ale ten proces mógł nie do końca się udać, bo były straszne problemy z komunikacją z VPSem, co chwilę zrywało połączenie. No cóż – brak dostępu do serwera VPS po SSH to poważna sprawa, więc odłożyłem to, co planowałem, i ruszyłem z pomocą. Zwłaszcza że to oznaczało potencjalny pomysł na nowy artykuł (nawet jeśli mi ich nie brakuje, w przeciwieństwie do wolnego czasu).
Reset ustawień iptables i UFW
Kolega podał mi adres IP serwera oraz port dla SSH (bo zgodnie z moją radą używa innego niż domyślny 22) oraz login i hasło i… Faktycznie – z serwerem nie można było się połączyć (tak, wiem, mówił, ale… ;-)). W tym momencie poprosiłem o dostęp do panelu zarządzania serwerem, bo zazwyczaj jest tam bezpośredni dostęp do konsoli, z pominięciem SSH. Udało się połączyć, co oznaczało, że problem jest po stronie serwera SSH lub firewalla (iptables).
Choć szybka kontrola usługi (serwera) SSH nie wykazała problemów, to dokonałem reinstalacji:
sudoa apt-get install -reinstall openssh-server
Na serwerze nie było też widać żadnych blokad wprowadzonych np. przez Fail2ban:
sudo iptables -L f2b-ssh -v -n --line-numbers
sudo iptables -L f2b-sshd -v -n --line-numbers
Ani ogólnie jakichkolwiek blokad, które mogłyby wskazać problem:
sudo iptables -L INPUT
sudo iptables -L
Również status UFW (firewall, w sumie będący nakładką na iptables) wskazywał, że wszystko jest OK:
sudo ufw status verbose
W takim razie uznałem, ze najlepiej będzie zresetować iptables oraz UFW:
sudo ufw disable
sudo ufw reset
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F
po tej operacji szybki test wykazał, że połączenie po SSH jest możliwe, więc zostało tylko ponownie zabezpieczyć serwer, korzystając w UFW:
sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable
Jest to konfiguracja dla standardowego webserwera, czyli na połączenia przychodzące otwarty port dla SSH (22, ale zalecam korzystać z innego), oraz port 80 i 443 dla WWW. Więcej o UFW pisałem w artykule „instalacja i konfiguracja UFW, czyli prosty i skuteczny firewall w systemie Linux”.
- Zero Trust od Cloudflare, czyli prosty i bezpieczny sposób na dostęp do lokalnych zasobów z zewnątrz, bez publicznego adresu IP i otwierania portów na routerze - 1970-01-01
- Home Assistant i integracja z IMGW-PIB, czyli tworzymy automatyzację z powiadomieniami bazując na sensorach zagrożenie i alarm powodziowy - 1970-01-01
- Home Assistant 2024.9 i kolejne przydatne nowości w widoku „sekcje”, dzięki którym jeszcze lepiej można dopasować wygląd - 1970-01-01
Podlinkowałbyś takie proste ABC zabezpieczenia serwera VPN wystawionego na świat?
W pewnym sensie takim ABC jest ten artykuł, a konkretnie podlinkowane w nim artykuły. Tak więc:
Zmiana portu SSH: https://webinsider.pl/raspberry-pi-ssh/
Firewall UFW: https://webinsider.pl/linux-firewall-ufw/
Do tego ew. Fail2Ban: https://webinsider.pl/linux-firewall-fail2ban/
Logowanie po SSH z certyfikatem: https://webinsider.pl/linux-ssh-logowanie-z-certyfikatem/
Logowanie po SSH 2FA: https://webinsider.pl/linux-ssh-scp-google-authenticator-2fa/
E-mail po zalogowaniu: https://webinsider.pl/ssh-login-info-email/
Ew, do tego Logwatch: https://webinsider.pl/linux-debian-logwatch/
+ Rkhunter i Chkrootkit: https://webinsider.pl/linux-rkhunter-chkrootkit/
To moim zdaniem taka podstawa. Dalej już zależnie od konkretnego przeznaczenia tego serwera.
A jak chciałbyś tak bardziej krok po kroku w jednym rzucie, to poczekaj jeszcze chwilę, bo mam teraz jeszcze inne projekty do dokończenia/zrealizowania, ale może niebawem będzie coś, na co będziesz mógł wydać „drobniaki ze skarbonki” ;-)