Systemy operacyjne obsługujące serwery witryn Internetowych, posiadają zarówno swoje wady, jak i zalety. Windows jest zdecydowanie prostszy w obsłudze, ale w jego plikach systemowych istnieje wiele wad i luk, które są w stanie wykorzystać hakerzy, a sam Microsoft często ma problemy z łataniem tych niedoróbek (przy okazji kreując inne). Linux jest trochę lepiej skonstruowany pod tym względem, lecz niestety i on nie jest pozbawiony tego typu problemów. Co robić, by zabezpieczyć serwer obsługiwany przez ten system przed ewentualnymi atakami z zewnątrz?

Spis treści:

[br]

Istota bezpieczeństwa

Pandemia zmusiła nas do zmiany trybu życia, który w dużej części przeniósł się do internetu, co poskutkowało o wiele większą ilością danych w serwerach witryn. Analogicznie, zwiększyła się również aktywność różnego rodzaju cyberprzestępców, którzy znajdują coraz to nowe luki w zabezpieczeniach, co skutkuje wyciekami informacji, nierzadko tych wrażliwych.

Doskonałym przykładem jest niedawny atak na serwery polskiego producenta gier – CD Projekt Red, z których, poza ogromną ilością danych pracowników i klientów, wykradziono również kody źródłowe ich produkcji. Ciągle słyszymy również o wycieku danych z różnego rodzaju urzędów czy serwerów mediów społecznościowych (takich jak Facebook czy Instagram). Hakerzy starają się wyciągnąć z serwerów takich miejsc jak największą ilość danych wrażliwych, które mogą przyczynić się do zaciągania kredytów na cudze dane czy ujawnianiem informacji tajnych dla niektórych osób i instytucji.
[br]

VPN > FTP

Istotną kwestią jest protokół, z którego korzystamy przy przesyłaniu danych. Domyślnym schematem jest połączenie FTP, które przesyła informacje w formie czystego, niesformatowanego i niezaszyfrowanego tekstu.

Poza VPN, istnieje szereg innych, o wiele bezpieczniejszych kanałów do wysyłki danych na serwer. Są to choćby protokoły RSYNC* czy SFTP. Ten typ zabezpieczenia wyklucza możliwość przechwycenia danych, ponieważ hasła i informacje przesyłane są w formie zaszyfrowanej wiadomości, którą stosunkowo ciężko złamać.

Przykładowe polecenie do przesłania katalogu używając RSYNC przez protokół SSH:
$ rsync -av -e 'ssh -p X' LokalnyFolder/ login@server:/DocelowyFolder/

*Uwaga, nie mylić z rsyncd. Rsyncd działa na porcie 873, jest nieszyfrowany i podatny na ataki brute-froce.
[br]

Dzielenie dysku na partycje

System Linux domyślnie instaluje wszystkie kluczowe katalogi w jednym miejscu. W takim wypadku warto zastanowić się, czy nie podzielić dysku na osobne partycje, do których można ulokować konkretne foldery z istotnymi dla działania systemu, plikami.

Katalogami, które należy szczególnie chronić są:

/home/
/var/log/
/var/tmp/

Istotne są też cztery inne foldery, które wiele poradników i specjalistów zaleca chronić szczególnie, choć z innego powodu:

/etc/
/usr/
/boot/
/lib/

Są to bardzo wrażliwe dla serwera informacje, których nie należy modyfikować w żaden sposób (są one sprawdzane przy ewentualnych konserwacjach serwera). Zaleca się zatem, by ustawić partycję, na której znajdą się te foldery na opcję „read only” (tylko do odczytu), tak aby żaden użytkownik (uprawniony, bądź nie) nie był w stanie ich edytować. Jest to bardzo istotne, ponieważ po niewłaściwej modyfikacji, system może ulec uszkodzeniu lub ułatwić atakującemu robotę.

Przykład: katalog /tmp służy do przechowywania plików tymczasowych. Oznacza to, że haker może wykorzystać ten katalog do wykonania złośliwego kodu, a następnie wystarczy, że zrestartuje serwer, a system automatycznie usunie „wszystkie” dowody.

Jeśli budujesz nowy serwer, sposób partycjonowania dysku jest pierwszą rzeczą, o której musisz zdecydować i często najtrudniejszą do późniejszej zmiany. Istnieje grupa zwana Center for Internet Security, która tworzy zbiory łatwych do odczytania instrukcji konfiguracji. Możesz znaleźć gotowe przewodniki dotyczące konkretnego systemu i zapoznać się z jego szczegółami.
[br]

Blokada serwera przed botami

Częstym typem ataku na różnego rodzaju serwery jest wielokrotna próba zalogowania się na nie przez boty lub za pomocą różnego rodzaju złośliwego oprogramowania. Nieautoryzowane próby dostępu można znaleźć w spisach logów, zarówno w głównych plikach systemu operacyjnego systemu, jak i w jego poszczególnych elementach.

Najprostszym sposobem by wyeliminować tego typu ruch jest oczywiście instalacja odpowiedniego programu, który z miejsca wykluczy wszelką niechcianą aktywność ze strony atakującego. Najpopularniejszym, w przypadku systemów operacyjnych Linux, jest pakiet fail2ban. Po kilku nieudanych dostępach, fail2ban automatycznie blokuje dostęp do serwera z danego adresu IP. Jest to o tyle wygodne, że właściciel serwera może w każdej chwili zobaczyć logi fail2ban’a w /var/log/fail2ban.log
Tego typu logfile jest łatwy do odczytania, bo wygląda mniej więcej tak:

...
2006-02-13 15:52:30,388 fail2ban.actions: WARNING \[sendmail\] Ban XXX.66.82.116 
2006-02-13 15:59:29,295 fail2ban.actions: WARNING \[sendmail\] Ban XXX.27.118.100 
2006-02-13 16:07:31,183 fail2ban.actions: WARNING \[sendmail\] Unban XXX.66.82.116 
2006-02-13 16:14:29,530 fail2ban.actions: WARNING \[sendmail\] Unban XXX.27.118.100 
2006-02-13 16:56:27,086 fail2ban.actions: WARNING \[ssh\] Ban XXX.136.60.164 
2006-02-13 17:11:27,833 fail2ban.actions: WARNING \[ssh\] Unban XXX.136.60.164

Możemy też statystyki wyświetlić w formie graficznej:
Fail2Ban
[br]

Konfiguracja zapory systemu Linux

Podstawowym systemem zabezpieczeń, bez względu na to, na jakim systemie działamy, jest zwykle zapora ogniowa. Polega ona nie mniej nie więcej na wprowadzaniu do serwera poleceń zablokowania portów oraz odblokowaniu tych, których w danych momencie potrzebujemy. Dla przykładu, blokuje się dostęp do portu 22/2222, a odblokowuje do innego.

Dzięki firmie Microsoft i jej niesławnym zabezpieczeniom przyjęło się, że ten rodzaj zabezpieczeń jest praktycznie bezużyteczny. Jest to spory błąd, ponieważ dobrze użytkowana zapora ogniowa jest w stanie zablokować wiele niechcianych połączeń z serwerem.

Przykładem niech będzie serwer typu front-end, który działa zwykle na bazach danych SQL.

Serwer, który podłączony jest do portu (jakiegokolwiek, dla przykładu port 8291) będzie pobierał z niego wszystkie informacje dotyczące ruchu, który odbywa się w tym porcie, a nie tylko ruch pochodzący z serwera. Po dodaniu do niego zapory ogniowej, system zacznie zachowywać się nieco inaczej – będzie odrzucał wszystkie próby łączności niepochodzące z serwera typu front-end, przyjmując tylko te, które wygenerowano z komputera o określonym IP.

Na Linuxie do filtrowania pakietów zazwyczaj używa się programu o nazwie iptables

WAŻNE! Koniecznie należy pamiętać, aby nie odciąć się przez zaporę i nie utracić dostępu do własnego serwera. Jest to bardzo częsty błąd ludzi, którzy nie do końca wiedzą jak skonfigurować dane urządzenie.
[br]

Logowanie za pomocą hasła SSH

SSH (Secure Shell) jest jednym ze sposobów na uzyskanie dostępu do serwera z komputera zdalnego. Obsługa tego procesu jest banalna – poza wpisaniem komendy „root” należy podać również adres IP komputera, do którego chcemy się połączyć. Serwer wysyła informację zwrotną z prośbą o hasło – po jego wpisaniu mamy pełny dostęp do informacji znajdujących się na serwerze.

W poradnikach, które można znaleźć, najczęstszą poradą jest wyłączenie zdalnego dostępu. Hasła, w tym przypadku, wysyłane są w formie zwykłego tekstu, co jest dość niebezpiecznym rozwiązaniem, o czym można przeczytać w pliku, odnoszącym się do Standardu Architektury Protokołu SSH, a dokładniej w punkcie 9.4.5., który mówi:

Jeśli serwer został przejęty, użycie uwierzytelniania za pomocą hasła ujawni atakującemu prawidłową kombinację nazwy użytkownika i hasła, co może prowadzić do dalszych włamań.

Aby wyłączyć zdalny dostęp do serwerów za pomocą hasła i loginu SSH należy uruchomić w dowolnych edytorze tekstowym plik etc/ssh/sshd_config i wyszukać odpowiednią linijkę kodu i zmienić, by wyglądała ona tak:

PasswordAuthentication no

Uwaga! Najpierw dodaj poprawnie klucze na serwer, a dopiero potem wyłącz sobie opcje logowania przy pomocy hasła.

Ta czynność całkowicie eliminuje możliwość ataku na serwer typu brute force w kombinacji user@IPserwera, który polega głównie na łamaniu haseł różnymi sposobami. W tym wypadku, potencjalny atak tego typu nie ma praktycznie sensu, ponieważ logowanie się do serwera za pomocą hasła jest wyłączone.

Jaką mamy alternatywę po wyłączeniu tej funkcji? Autoryzacja za pomocą kluczy SSH, które są o wiele bezpieczniejsze, choć nie są pozbawione wad. Pierwszą rzeczą, którą należy zrobić, by ustanowić ten typ zdalnego dostępu jest stworzenie kluczy prywatnego i publicznego. Pierwszy umieszczany jest w każdym komputerze, z którego staramy się uzyskać dostęp, a drugi umieszczany jest na serwerze.

Klucz tworzymy przy pomocy ssh-keygen. Najlepiej jest użyć rodzaj klucza ed25519 jeśli jest taka możliwość:

$ ssh-keygen -t ed25519

A jeszcze lepiej jest dodać -a 100 czyli ilość rund KDF (Key Derivation Rounds). Zwiększa to ilość mocy procesora potrzebnej do odszyfrowania klucza:

$ ssh-keygen -a 100 -t ed25519

Po wpisaniu komendy i kliknięciu enter zostaniemy poproszeni o podanie hasła:

ssh-keygen

Kolejnym krokiem jest dopisanie klucza na serwerze do pliku _~/.ssh/authorizedkeys.

Przy pomocy ssh-copy-id:
ssh-copy-id username@remote_host

Lub ręcznie przy pomocy ssh:

cat ~/.ssh/id_ed25519.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

W przypadku, gdy serwer wykryje niezgodność między kluczem publicznym i prywatnym, automatycznie odmówi zdalnego dostępu do serwera, co dosyć dobrze zapobiega atakom typu man-in-the-middle. Ten typ hakowania polega na połączeniu nieautoryzowanego klucza publicznego z tym prywatnym, umieszczonym na serwerze. Atak tego typu umożliwia podgląd i modyfikację wszelkich aktywności użytkownika, atakującemu system hakerowi (więcej o tym można przeczytać tutaj).
[br]

Logowanie przez root SSH

Jednym z najbardziej narażonych na atak hakerski elementem jest możliwość bezpośredniego dostępu do serwera poprzez logowanie jako root przez wspomniany Service Shell. W przypadku złamania hasła przez technikę brute force, osoba nieuprawniona otrzymuje wgląd do systemu.

Jak zażegnać potencjalne zagrożenie tym atakiem? Po raz kolejny zmuszeni jesteśmy zmodyfikować plik sshd_config (/etc/ssh/ssh_config), będąc zalogowani jako root. Krokiem pierwszym jest modyfikacja kolejnej linijki kodu w tym pliku, a mianowicie

#PerminRootLogin yes

na

PermitRootLogin no

Ostatnim etapem w eliminacji zagrożeń płynących z logowania jako root SSH w systemie Linux jest restart usługi sshd poprzez wpisanie do konsoli kodu:

\>/etc/init.d/sshd restart
[br]

Zmiana domyślnego portu SSH

Klasycznym zabezpieczeniem serwera jest zmiana domyślnego portu w myśl zasady: „Jeśli nie możesz znaleźć portu, którego używamy, nie masz możliwości zhakowania naszego serwera”. Jest to myślenie życzeniowe, ponieważ ten rodzaj profilaktycznej obrony zatrzymuje tylko i wyłącznie słabsze ataki ludzi, którzy sprawdzają domyślne porty SSH i łamią zwykle wyłącznie słabsze hasła (junior hakerzy hehe). Ale… w internecie jest mnóstwo automatycznych skryptów, botów, które właśnie w ten sposób działają.

Zmiana domyślnego portu SSH jest w stanie zmniejszyć nam ruch, a więc i obciążenie generowane przez tego typu próby ataku na nasz serwer. Domyślną wartością jest port 22 .Co zrobić, by zmienić tę wartość? Należy (po raz kolejny) otworzyć w dowolnym edytorze tekstowym plik sshd_config, a następnie znaleźć linijkę Port 22 i zmienić wartość liczbową na którąś z zakresu 1125-66535 (z wyłączeniem portu 2222, który jest równie często sprawdzany przez atakujących, jak 22).
[br]

Podsumowanie

Jak więc widać, sposobów na obronę serwera opartego na systemie operacyjnym Linux jest wiele. Należy pamiętać jednak o tym, że praktycznie żaden z nich, nie daje stuprocentowej pewności na to, że działanie osób z zewnątrz nie wpłynie na jego funkcjonowanie, ani na to, że dane zachowane na urządzeniu są w pełni bezpieczne. Większość z wyżej wymienionych opcji zabezpieczeń powinna w zupełności wystarczyć w chwili, gdy planujemy stworzenie serwera (lub ten już funkcjonuje), który będzie działał na stosunkowo małą skalę (serwer domowy).

Co w przypadku, gdy trzeba postawić serwer w firmie, gdzie istnieje spore ryzyko ataku? Warto zgłosić się do osób z IT, które ogarniają temat. Robienie czegoś samemu bez doświadczenia w branży security może wiązać się ze sporym ryzykiem. Po pierwsze – w przypadku niskiego obycia ze sprawami związanymi z IT, sami możemy zaszkodzić bezpieczeństwu naszego serwera, zwłaszcza w nieprzychylnym dla laików środowisku Linux. Po drugie – technologia cały czas idzie do przodu, a aktualizacje związane z poprawą działania systemu mogą przynieść sporo zmian, zarówno w kwestii funkcjonowania serwera, jak i w obsłudze jego zabezpieczeń. Po trzecie – proces zabezpieczania jest bardzo czasochłonny, zwłaszcza, gdy mamy średnie pojęcie o tematyce z zakresu IT.

Instagram SAPSAN: LINK
Instagram Autora: LINK
Grupa na FB: LINK

Bądźcie zdrów! Na poprawę humoru wrzucam mema.
mem

Sapsan