Jak zabezpieczyć serwer przed hakerami?

7,7K

Posiadasz serwer z działającą produkcyjnie aplikacją lub z ważnymi danymi, a w logach serwera widzisz, że stale ktoś próbuje złamać zabezpieczenia i włamać się na Twój serwer? Pewnie zastanawiasz, się jak najlepiej zabezpieczyć swoje cenne dane przed hakerami i próbami włamań…🥺

Dziś kontynuuję poradnik o zabezpieczeniach serwera z zainstalowanym systemem Linux – CentOS 7. Pierwsza część, z której dowiesz się dlaczego warto zabezpieczać serwer, jak sprawdzić, czy ktoś próbował się do niego włamać i jakie podstawowe zabezpieczenia możesz wprowadzić, dostępna jest TUTAJ.

Współpraca

Na wstępie zaznaczę, że artykuł powstał we współpracy z firmą nazwa.pl, która na potrzeby przygotowania artykułu, wdrożenia konfiguracji i przeprowadzenia testów, dostarczyła wydajny serwer VPS w opcji Biznes.

Dostępne warianty wraz z opisami i cennikiem umieszczam w podlinkowanej grafice poniżej.

Wprowadźmy zabezpieczenia!

6. Logowanie na podstawie kluczy SSH

Logowanie z wykorzystaniem kluczy SSH, które są przechowywane po stronie klienta, powinno być jednym z podstawowych punktów podczas zabezpieczenia serwera. Oczywiście decyzja o tym, czy warto wdrażać taki poziom bezpieczeństwa, jest indywidualna, bo jeśli maszyna działa w wyizolowanym środowisku, może nie być konieczności tworzenia aż tak wysokiego poziomu zabezpieczeń.

Niemniej warto mieć to na uwadze i rozważyć tę możliwość, choćby ze względu na wygodę 😉

6.1. Sprawdź, czy masz już klucz!

Całą konfigurację należy rozpocząć od utworzenia pary kluczy RSA publiczny/prywatny na lokalnej maszynie, czyli komputerze klienckim. Należy pamiętać o tym, żeby nie nadpisać sobie już tych istniejących, ponieważ można utracić je bezpowrotnie! Dlatego przed rozpoczęciem konfiguracji dobrą praktyką jest przeszukiwanie plików systemowych i sprawdzenie, czy plik z kluczem znajduje się już na komputerze.

Rzecz jasna nie trzeba tego robić ręcznie, można skorzystać z poniższego polecenia.

ls -l ~/.ssh/id_*.pub

Jeżeli powyższa komenda znajdzie pliki z kluczami na komputerze, masz kilka możliwości, co z tym zrobić. Możesz:

1. Nadpisać pliki bez tworzenia ich kopii.
2. Wykonać kopię zapasową (np. dodając do nazwy „-backup”) i nadpisać pliki.
3. Utworzyć parę kluczy pod inną nazwą niż ta proponowana domyślnie.

W tym artykule skupimy na scenariuszu, w którym kluczy na lokalnym komputerze jeszcze nie ma.

6.2. Generowanie kluczy

Sam proces generowania jest bardzo prosty! Wystarczy wywołać polecenie, które utworzy parę kluczy RSA o rozmiarze 2048-bitów. Tutaj warto zaznaczyć, że jeśli chcesz jeszcze bardziej podnieść poziom bezpieczeństwa swojego serwera, możesz dodać do polecenia parametr -b, który utworzy klucze o rozmiarze 4096-bitów.

Na potrzeby tego poradnika spokojnie wystarczy wariant pierwszy.

ssh-keygen

W wyniku powyższego polecenia zostaniesz poproszony o wskazanie nazwy pliku, w którym zostaną zapisane klucze (domyślnie jest to id_rsa). Jeśli nie chcesz tego zmieniać, zostaw pole puste i wciśnij ENTER.

W kolejnym kroku możesz podać dodatkowe, nieobowiązkowe hasło (ang. passphrase), które jest dobrą opcją na kolejną warstwę zabezpieczeń i tutaj uwaga – hasło jest dodatkiem do kluczy SSH, a to oznacza, że bez nich jest bezużyteczne!

Moim zdaniem warto je zdefiniować 😉

Efektem końcowym będzie komunikat o poprawnym wygenerowaniu kluczy, podobny do powyższego.

6.3. Wysłanie klucza publicznego na serwer

Skoro posiadasz już klucze na komputerze, to czas najwyższy podzielić się tym publicznym z serwerem. Można to oczywiście zrobić na kilka różnych sposobów. Jedną z możliwości (którą tutaj opiszę) jest wykorzystanie narzędzia ssh-copy-id, które kopiuje klucz zawarty w pliku id_rsa.pub na serwer.

Do wykonania polecenia kopiującego klucz potrzebujesz standardowych danych logowania na serwer. Ważne, aby podczas tej operacji było włączone logowanie hasłem!

ssh-copy-id <USER>@<HOST> -p <PORT>

Jeśli udało Ci się uzyskać efekt podobny do mojego, będziesz mógł połączyć się ze swoim serwerem, korzystając z kluczy. W rezultacie zostaniesz automatycznie zalogowany lub serwer poprosi Cię dodatkowo o podanie passphrase, które zdefiniowałeś wcześniej.

ssh -p 96 <USER>@<HOST>

7. Wyłączenie logowania hasłem

Skoro jest już na serwerze nowa opcja logowania, możesz wyłączyć tę bazującą tylko na haśle. Musisz tylko pamiętać, aby każdy użytkownik, który powinien mieć dostęp do serwera, posiadał skonfigurowane klucze, gdyż w przypadku ich braku zablokujesz im dostęp do maszyny.

Konfiguracja jest bardzo prosta i szybka. Otwórz plik sshd_config i zmień parametr PasswordAuthentication z yes na no.

sudo vi /etc/ssh/sshd_config

Po wprowadzeniu zmian plik należy zapisać, a usługę sshd zrestartować, aby nowe ustawienia zostały załadowane na serwerze.

sudo service sshd restart

Od tego momentu klient (komputer), który spróbuje nawiązać połączenie zwykłym hasłem (bez kluczy RSA) nie zostanie wpuszczony do serwera.

8. Wyłączenie nieużywanych portów

Porty na serwerze są w pewnym sensie jak okna w domu. Jeżeli któryś jest niekontrolowany i nie zadbasz o jego odpowiednie zabezpieczenie lub całkowite zamknięcie (wyłączenie), narazisz serwer na potencjalne włamanie.

Odpowiedź jest bardzo prosta! Skanując Twój serwer i wysyłając port po porcie pakiety ACK. Niestety jest to bardzo proste i wystarczy skorzystać, np. z narzędzia Nmap. Poniżej przykład z wynikiem takiego skanowania mojego serwera. Na potrzeby objaśnienia przykładu sprawdziłem porty z zakresu 1-1000 poniższym poleceniem i otrzymałem listę otwartych portów… 🤨

nmap -p 1-1000 <IP>

Jak widać przed Nmap-em nie ukrył się nawet mój dedykowany port 96, który służy do nawiązywania połączenia SSH. Przed botami taka konfiguracja i wyłączenie domyślnego portu 22 zadziała, ale dla bardziej upartej osoby nie będzie to żaden problem… Innym sposobem na weryfikację, które porty są otwarte, jest wywołanie polecenia netstat na serwerze.

netstat -tulnp

Z tego „raportu” również można wywnioskować, iż część adresów TCP oraz UDP zarówno dla IPv4, jak i IPv6 jest „otwarta na świat”. Jeśli zauważysz, że serwer nasłuchuje na portach, których nie znasz, sprawdź, które aplikacje lub usługi z nich korzystają i upewnij się, że są one dla Ciebie lub serwera niezbędne.

9. Włączenie zapory FireWall

Kolejnym, bardzo ważnym sposobem na zabezpieczenie serwera jest włączenie i skonfigurowanie zapory sieciowej. W przypadku systemu CentOS można skorzystać z FirewallD. Jeżeli program nie jest zainstalowany domyślnie na Twoim serwerze, możesz go doinstalować poniższym poleceniem.

sudo yum install firewalld

9.1. Uruchomienie usługi firewalld

Zapora zaraz po zainstalowaniu jest wyłączona. Możesz to zweryfikować poniższym poleceniem, które powinno zwrócić status not running.

sudo firewall-cmd --state

Aby móc wprowadzać jakąkolwiek konfigurację w zaporze i podnieść bezpieczeństwo serwera, musisz uruchomić usługę.

sudo systemctl start firewalld

Po wykonaniu polecenia i ponownym sprawdzenie statusu zapory sieciowej otrzymasz informację: running.

9.2. Dodanie portu 96/tcp do reguł firewalla

UWAGA! Bardzo istotny krok, którego pominięcie będzie skutkować zablokowaniem dostępu do serwera przez SSH.

Jeżeli zmieniasz domyślny port SSH/22 (a w moim przypadku jest to 96), koniecznie musisz dodać odpowiednią regułę do zapory sieciowej. Jeśli tego nie zrobisz, serwer nie będzie na nim nasłuchiwał i odrzuci połączenia.

Wykonaj poniższe polecenia aby zaktualizować reguły i sprawdzić czy port został dodany poprawnie.

sudo firewall-cmd --zone=public --add-port=96/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-ports

9.3. Usunięcie portu 96/tcp z reguł zapory

Wpisałeś przez przypadek niepoprawny numer portu? Możesz go szybko usunąć z reguł zapory poniższą komendą.

sudo firewall-cmd --zone=public --remove-port=96/tcp --permanent
sudo firewall-cmd --reload

9.4. Uruchomienie zapory na starcie serwera

Ostatnie polecenie, dzięki któremu usługa z programem firewalla będzie uruchamiać się zaraz po uruchomieniu serwera.

sudo systemctl enable firewalld

Od tego momentu musisz pamiętać aby dodawać kolejne porty, na których powinien nasłuchiwać serwer do reguł zapory sieciowej. I nie tyczy się to tylko SSH! Dla przykładu porty serwerów aplikacyjnych lub protokoły http/https również muszą być dodawane, bez tego komunikacja nie będzie działać prawidłowo.

10. Konfiguracja fail2ban

Fail2ban jest aplikacją, która chroni przed atakami skierowany w serwer metodą brute force. Atakujący w ten sposób sprawdza różne kombinacje np. loginów i haseł, dzięki temu próbuje trafić na poprawną kombinację, która „wpuści” go do serwera.

Działanie programu jest proste w idei. Analizuje logi, wychwytuje nieudane próby logowania i zgodnie z ustalonymi regułami, które definiuje się w plikach konfiguracyjnych, blokuje adres IP atakującego, tym samym uniemożliwiając mu dostęp do serwera.

10.1. Instalacja

Fail2ban nie jest domyślnie dostępny dla CentOS’a. Z tego względu, w pierwszej kolejności trzeba zainstalować na serwerze repozytorium EPEL (Extra Packages for Enterprise Linux).

sudo yum install epel-release
sudo yum install fail2ban fail2ban-systemd

Trzeba pamiętać, że po zainstalowaniu konieczna jest aktualizacja reguł SELinux!

sudo yum update -y selinux-policy*

10.2. Konfiguracja

Jeżeli cały proces instalacyjny zakończył się bez problemów i program znajduje się już na serwerze, w kolejnym etapie trzeba zająć się jego odpowiednią konfiguracją. Znajdziesz ją w katalogu /etc/fail2ban, a domyślnym plikiem konfiguracyjnym jest jail.conf.

UWAGA! Jego zawartości nie wolno modyfikować! Dlaczego? Ponieważ kolejne aktualizacje programu mogą spowodować nadpisanie pliku, a tym samym utratę wprowadzonej konfiguracji.

No dobrze… Ale w jakiś sposób konfigurację trzeba dodać, prawda? Wystarczy utworzyć plik o nazwie jail.local, którego zawartość będzie nadpisywać ustawienia ze wspomnianego już pliku jail.conf. Można to zrobić poniższym poleceniem:

sudo cp -pf /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Dzięki temu konfiguracja umieszczona w pliku jail.local może być dowolnie modyfikowana i nie ma ryzyka, że zostanie nadpisana przez nowe wersje programu.

W tym poradniku dodamy regułę blokującą dostęp do serwera przez SSH. I tutaj uwaga! Ponownie zrobimy to w dedykowanym, osobnym pliku sshd.local. Taka praktyka jest powszechnie znana i stosowana. Dzięki niej można uporządkować reguły i podzielić odpowiednio konfigurację.

Poniższe polecenie utworzy nowy plik, do którego możesz wkleić podaną przeze mnie konfigurację.

sudo vi /etc/fail2ban/sshd.local

[sshd]
enabled = true
port = 96
logpath = %(sshd_log)s
maxretry = 5
bantime = 86400

Poniżej krótki opis ustawionych parametrów:

• enable – włącz (true) lub wyłącz (false) regułę.
• port – chroniony port. Dla standardowego portu 22 można wpisać wartość „ssh”.
• logpath – plik z logiem, który fail2ban skanuje i analizuje.
• maxretry – limit nieudanych prób logowania.
• bantime – okres (w sekundach), na jaki adres IP dostaje blokadę (bana).

10.3. Uruchomienie usługi

Żeby program zaczął działać, nasłuchiwać i blokować intruzów, należy go oczywiście uruchomić i zadbać o to aby włączał się automatycznie po uruchomieniu serwera.

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Status usługi możesz sprawdzić, korzystając z dedykowanych komend, które program dostarcza. Dzięki nim możesz zweryfikować np. jakie porty w danym momencie chroni (jakie więzienia są aktywne) lub ile adresów IP już zbanował.

sudo fail2ban-client status

sudo fail2ban-client status sshd

Podsumowanie

W tym artykule poznaliśmy kolejnych 5 sposób (łącznie już 10 😱) na zabezpieczenie serwera z Linuxem. Moim zdaniem najistotniejszymi punktami tego artykułu, na które warto zwrócić szczególną uwagę, są:

• Konfiguracja logowania przy pomocy kluczy SSH.
• Wyłączenie możliwości logowania hasłem.
• Włączenie zapory sieciowej.

Te 3 kroki zdecydowanie zmniejszą ryzyko ataków i znacznie ograniczą próby włamań do serwera.

Na koniec przypomnę tylko, że artykuł powstał we współpracy z firmą nazwa.pl, która udostępniła mi wydajny serwer VPS na potrzeby konfiguracji i przeprowadzenia testów. Szczegóły, specyfikacje i oferta są dostępne TUTAJ!

Daj lajka i czytaj dalej!

Jeżeli chcesz być na bieżąco z artykułami i jesteś ciekawy, co będzie dalej, daj lajka na profilu FB, a przede wszystkim zapisz się do newslettera! Spodobał Ci się artykuł? Z pewnością zaciekawią Cię inne wpisy na blogu lub filmy na kanale YT!

Dzięki za Twój czas, widzimy się niebawem! 🙂