, CC BY-SA
W dzisiejszych czasach uruchomienie serwera na hostingu zajmuje kilka minut i kilka kliknięć myszką. Jednak zaraz po uruchomieniu trafia on w wrogie otoczenie, ponieważ jest otwarty dla całego internetu jak niewinna dziewczyna na rockowej dyskotece. Szybko wyczuwają go skanery i odkryją tysiące automatycznych botów skryptowych, które krążą po sieci w poszukiwaniu luk i nieprawidłowych konfiguracji. Po uruchomieniu istnieje kilka rzeczy, które należy zrobić, aby zapewnić podstawową ochronę.
Spis treści
Użytkownik bez uprawnień root
Po pierwsze, należy założyć sobie użytkownika bez uprawnień root. Chodzi o to, że użytkownik root ma absolutne przywileje w systemie, a jeśli pozwolisz mu na zdalne zarządzanie, to w połowie wykonasz pracę za hakera, zostawiając mu ważną nazwę użytkownika.
Dlatego trzeba założyć innego użytkownika, a dla roota wyłączyć zdalne zarządzanie przez SSH.
Nowego użytkownika zakłada się poleceniem useradd:
useradd [options] Następnie dla niego dodaje się hasło poleceniem passwd:
passwd Na koniec tego użytkownika należy dodać do grupy, która ma prawo do wykonywania poleceń z podwyższonymi przywilejami sudo. W zależności od dystrybucji Linuxa, mogą to być różne grupy. Na przykład, w CentOS i Red Hat użytkownika dodaje się do grupy wheel:
usermod -aG wheel W Ubuntu dodaje się go do grupy sudo:
usermod -aG sudo
Klucze zamiast haseł SSH
Atak przez brute force lub wyciek haseł to standardowy wektor ataku, więc autoryzację na podstawie haseł w SSH (Secure Shell) lepiej wyłączyć, a zamiast tego zastosować autoryzację na podstawie kluczy.
Są różne programy do realizacji protokołu SSH, takie jak i , ale najpopularniejszy jest OpenSSH. Instalacja klienta OpenSSH na Ubuntu:
sudo apt install openssh-clientInstalacja na serwerze:
sudo apt install openssh-serverUruchomienie demona SSH (sshd) na serwerze z Ubuntu:
sudo systemctl start sshdAutomatyczne uruchamianie demona przy każdym załadunku:
sudo systemctl enable sshd Należy zauważyć, że część serwerowa OpenSSH zawiera część kliencką. To znaczy przez openssh-server można łączyć się z innymi serwerami. Co więcej, z klienta można uruchomić tunel SSH z zdalnego serwera do zewnętrznego hosta, a wtedy ten zewnętrzny host będzie traktował zdalny serwer jako źródło zapytań. To bardzo przydatna funkcja do maskowania swojego systemu. Więcej informacji w artykule .
Na maszynie klienckiej zazwyczaj nie ma sensu instalować pełnoprawnego serwera, aby uniknąć możliwości zdalnego dostępu do komputera (ze względów bezpieczeństwa).
Aby utworzyć nowego użytkownika, należy najpierw wygenerować klucze SSH na komputerze, z którego będziesz łączyć się z serwerem:
ssh-keygen -t rsa Publiczny klucz przechowywany jest w pliku .pub i wygląda jak ciąg losowych znaków, który zaczyna się od ssh-rsa.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname
Następnie, z poziomu konta root, należy stworzyć w katalogu domowym użytkownika folder SSH i dodać publiczny klucz SSH do pliku authorized_keys, używając edytora tekstu, takiego jak Vim:
mkdir -p /home/user_name/.ssh && touch /home/user_name/.ssh/authorized_keysvim /home/user_name/.ssh/authorized_keysNa koniec, należy ustawić poprawne uprawnienia dla pliku:
chmod 700 /home/user_name/.ssh && chmod 600 /home/user_name/.ssh/authorized_keysi zmienić właściciela na tego użytkownika:
chown -R username:username /home/username/.sshPo stronie klienta należy wskazać lokalizację prywatnego klucza do autoryzacji:
ssh-add DIR_PATH/keylocationTeraz można zalogować się na serwer jako użytkownik za pomocą tego klucza:
ssh [username]@hostnamePo autoryzacji można używać polecenia scp do kopiowania plików lub narzędzia do zdalnego montowania systemu plików lub katalogów.
Warto wykonać kilka kopii zapasowych prywatnego klucza, ponieważ jeśli wyłączysz autoryzację hasłem i go stracisz, nie będziesz miał absolutnie żadnej możliwości dostępu do swojego serwera.
Jak wspomniano wcześniej, w SSH należy wyłączyć autoryzację dla roota (z tego powodu tworzyliśmy nowego użytkownika).
Na CentOS/Red Hat znajduje się linia PermitRootLogin yes w pliku konfiguracyjnym /etc/ssh/sshd_config i zmieniamy ją:
PermitRootLogin no Na Ubuntu dodajemy linię PermitRootLogin no do pliku konfiguracyjnego 10-my-sshd-settings.conf:
sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.confPo zweryfikowaniu, że nowy użytkownik przechodzi uwierzytelnienie za pomocą swojego klucza, można wyłączyć uwierzytelnienie za pomocą hasła, aby wykluczyć ryzyko jego wycieku lub ataku metodą brute-force. Teraz aby uzyskać dostęp do serwera, osoba nieuprawniona będzie musiała zdobyć prywatny klucz.
Na CentOS/Red Hat znajduje się linia PasswordAuthentication yes w pliku konfiguracyjnym /etc/ssh/sshd_config i zmieniamy go w następujący sposób:
PasswordAuthentication no Na Ubuntu dodajemy linię PasswordAuthentication no do pliku 10-my-sshd-settings.conf:
sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.confInstrukcję podłączenia dwuskładnikowego uwierzytelnienia przez SSH znajdziesz w .
Firewall
Zapora ogniowa zapewnia, że na serwerze będzie przechodził tylko ten ruch w wyznaczonych portach, które bezpośrednio zezwoliłeś. To chroni przed wykorzystaniem portów, które przypadkowo włączyły się z innymi usługami, co znacząco zmniejsza powierzchnię ataku.
Przed zainstalowaniem zapory ogniowej należy upewnić się, że SSH znajduje się na liście wyjątków i nie będzie blokowane. W przeciwnym razie po uruchomieniu zapory nie będziemy mogli połączyć się z serwerem.
Z dystrybucją Ubuntu dostarczany jest Uncomplicated Firewall (), a z CentOS/Red Hat — .
Zezwolenie na SSH w zaporze ogniowej na Ubuntu:
sudo ufw allow ssh Na CentOS/Red Hat używamy polecenia firewall-cmd:
sudo firewall-cmd --zone=public --add-service=ssh --permanentPo tej procedurze można uruchomić zaporę ogniową.
Na CentOS/Red Hat uruchamiamy usługę systemd dla firewalld:
sudo systemctl start firewalld
sudo systemctl enable firewalldNa Ubuntu używamy takiego polecenia:
sudo ufw enable
Fail2Ban
Serwis analizuje logi na serwerze i zlicza liczbę prób dostępu z każdego adresu IP. W ustawieniach określono zasady, ile prób dostępu jest dozwolone w określonym czasie — po czym dany adres IP jest blokowany na ustalony czas. Na przykład pozwalamy na 5 nieudanych prób uwierzytelnienia przez SSH w ciągu 2 godzin, po czym blokujemy dany adres IP na 12 godzin.
Instalacja Fail2Ban na CentOS i Red Hat:
sudo yum install fail2banInstalacja na Ubuntu i Debianie:
sudo apt install fail2banUruchomienie:
systemctl start fail2ban
systemctl enable fail2ban Program ma dwa pliki konfiguracyjne: /etc/fail2ban/fail2ban.conf i /etc/fail2ban/jail.conf. Ograniczenia dla banów podane są w drugim pliku.
Jail dla SSH jest włączony domyślnie z ustawieniami fabrycznymi (5 prób, interwał 10 minut, ban na 10 minut).
[DEFAULT] ignorecommand = bantime = 10m findtime = 10m maxretry = 5
Oprócz SSH, Fail2Ban może chronić także inne usługi na serwerze WWW nginx lub Apache.
Automatyczne aktualizacje zabezpieczeń
Jak wiadomo, w każdym oprogramowaniu ciągle odkrywane są nowe luki. Po publikacji informacji, exploity są dodawane do popularnych pakietów exploitów, które są powszechnie wykorzystywane przez hakerów i nastolatków do skanowania wszystkich serwerów po kolei. Dlatego bardzo ważne jest, aby aktualizacje bezpieczeństwa były instalowane natychmiast po ich wydaniu.
Na serwerze Ubuntu w domyślnej konfiguracji włączone są automatyczne aktualizacje bezpieczeństwa, więc nie są wymagane dodatkowe działania.
Na CentOS/Red Hat należy zainstalować aplikację i włączyć zegar:
sudo dnf upgrade
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timerSprawdzenie zegara:
sudo systemctl status dnf-automatic.timer
Zmiana domyślnych portów
SSH został stworzony w 1995 roku jako zamiennik telnet (port 23) i ftp (port 21), dlatego autor programu Tatu Ylönen , i został on zatwierdzony w IANA.
Oczywiście, wszyscy przestępcy są świadomi, na którym porcie działa SSH — i skanują go razem z pozostałymi standardowymi portami, aby sprawdzić wersję oprogramowania, weryfikować standardowe hasła roota itd.
Zmiana standardowych portów — obfuskacja — kilkakrotnie zmniejsza objętość zbędnego ruchu, rozmiar logów i obciążenie serwera, a także zmniejsza powierzchnię ataku. Chociaż niektórzy (security through obscurity). Powód jest taki, że technika ta stoi w sprzeczności z fundamentalną . Dlatego na przykład Narodowy Instytut Standardów i Technologii USA w podkreśla potrzebę otwartej architektury serwera: "Bezpieczeństwo systemu nie powinno polegać na ukryciu implementacji jego komponentów", mówi dokument.
Teoretycznie, zmiana domyślnych portów jest sprzeczna z praktyką otwartej architektury. Jednak w praktyce wystąpienie złośliwego ruchu rzeczywiście maleje, więc to prosta i skuteczna miara.
Numer portu można skonfigurować, zmieniając dyrektywę Port 22 w pliku konfiguracyjnym. Jest on również określany poprzez parametr -p do . Klient SSH i programy również wspierają parametr -p.
Parametr -p można użyć do określenia numeru portu podczas łączenia za pomocą polecenia ssh w systemie Linux. W i scp używa się parametru -P (nagłówek P). Polecenie z wiersza poleceń nadpisuje każdą wartość w plikach konfiguracyjnych.
Jeśli serwerów jest wiele, prawie wszystkie te czynności związane z zabezpieczeniem serwera Linux można zautomatyzować w skrypcie. Jednak w przypadku pojedynczego serwera lepiej ręcznie kontrolować proces.
Reklama
Zamów i od razu pracuj! dowolnej konfiguracji i z dowolnym systemem operacyjnym w ciągu minuty. Maksymalna konfiguracja pozwoli na pełne wykorzystanie możliwości — 128 rdzeni CPU, 512 GB RAM, 4000 GB NVMe. Epicko 🙂
Źródło: habr.com
