WordPress na platformie Amazon AWS EC2 – cz.4

Jak uczynić naszą instancję bezpieczniejszą?

Informacje tutaj zawarte nie są z pewnością kompendium wiedzy na temat bezpieczeństwa i nie taki też miał być cel tego artykułu. Chcę jednak pokazać kilka podstawowych czynności, które uważam za pewne minimum w kontekście bezpieczeństwa naszego Linuxa. Muszę podkreślić, że to Ty masz pełną kontrolę nad swoją instancją i to do Ciebie należy zadbanie o bezpieczeństwo przechowywanych przez Ciebie danych, oraz bezpieczeństwo osób, które będą odwiedzać Twoją stronę. Zdecydowanie zachęcam do zdobywania wiedzy w temacie administracji serwerem.

Aktualizacje

Jedną z najistotniejszych czynności jest regularna aktualizacja systemu i zainstalowanego oprogramowania. Niestety błędy zdarzają się wszędzie (głośny przykład błędu w bibliotece OpenSSL z 2014 roku), dlatego powinniśmy jak najszybciej instalować wszelkie pojawiające się aktualizacje bezpieczeństwa. Zanim ruszymy dalej, upewnijmy się zatem, że nasz system jest aktualny.

Niektórzy zauważyli pewnie, że po zalogowaniu na naszą instancję, zostaliśmy przywitani takim (liczby mogą się różnić) komunikatem:

ec2_updates

Oznacza to ni mniej, ni więcej jak to, że od czasu wydania tej wersji dystrybucji pojawiło się „trochę” różnych aktualizacji, z czego w moim przypadku 56 to aktualizacje bezpieczeństwa. Naprawmy to zatem. 🙂

Na początek wydajemy polecenie:

sudo apt-get update

W ten sposób upewniamy się, że system „wie” o wszystkich aktualizacjach, które powinien zainstalować. W tym momencie nic jeszcze nie jest instalowane. Pobierane są jedynie informacje o możliwych zmianach.

Następnie możemy wydać polecenie:

sudo apt-get upgrade

lub

sudo apt-get dist-upgrade

Jest pomiędzy nimi zasadnicza różnica. W pierwszym przypadku zaktualizowane zostaną jedynie pakiety już zainstalowane. Często jednak jest tak, że jeden pakiet zależy w jakiś sposób od innych. Jeśli nowsza wersja już zainstalowanego oprogramowania zależy od pakietu z którego wcześniej nie korzystała i nie jest on obecny w systemie, aktualizacja danego pakietu nie dojdzie do skutku. Wszystkie informacje o problemach zostaną wypisane w konsoli.

W przypadku drugiego polecenia zależności rozwiązywane są automatycznie i różne pakiety mogą zostać usunięte lub doinstalowane. W chwili obecnej nie ma to dla nas wielkiego znaczenia, bowiem maszyna przed chwilą została uruchomiona i do niczego jej jeszcze nie używamy. Kiedy jednak uruchomimy już serwer www, bazę danych i nasza strona będzie dostępna publicznie, nie chcielibyśmy, aby po wykonaniu aktualizacji nagle coś przestało działać. Nie oznacza to oczywiście, że mamy nie aktualizować naszego systemu. Oznacza to jedynie, że zawsze musimy wiedzieć co i dlaczego robimy. Jako pewnego rodzaju zabezpieczenie warto rozważyć uruchomienie środowiska stage-owego i przetestowanie modyfikacji na nim, zanim zdecydujemy się na aktualizację środowiska produkcyjnego, tym bardziej że duplikacja instancji EC2 jest bardzo prosta.

Co bardziej dociekliwi zauważyli pewnie, że pomimo zainstalowania wszystkich aktualizacji, OpenSSL o którym wspominałem przed chwilą pozostał w wersji 1.0.1f czyli teoretycznie podatnej na atak HeartBleed. Jest to jednak nieprawda. Wersja ta została załatana przez opiekunów Ubuntu w dniu upublicznienia podatności. Więcej informacji tutaj.

Na koniec tej części warto zrestartować naszą maszynę:

sudo reboot

Po wydaniu tego polecenia nasze połączenie zostanie przerwane. Odczekajmy minutę lub dwie i spróbujmy połączyć się ponownie.

Zmiana domyślnego portu usługi SSH

Warto rozważyć zmianę domyślnego portu SSH z 22 na jakiś inny losowy numer powyżej 1023. Wiele botów używanych do ataków automatycznych poszukując otwartego portu SSH ogranicza się do sprawdzenia domyślnego portu dla tej usługi. Nie ograniczy to wszystkich prób włamania, ale odsieje przynajmniej część z nich. Zmiany portu możemy dokonać w pliku konfiguracyjnym usługi SSH. Musimy edytować go jako użytkownik uprzywilejowany, wydajemy więc polecenie:

sudo nano /etc/ssh/sshd_config

Oczywiście zamiast nano można użyć swojego ulubionego edytora tekstu. 🙂

Odszukujemy w pliku linijkę

Port 22

i zmieniamy wartość portu na jakąś inną wartość, np.

Port 56321

ec2_custom_ssh_2

Zapisujemy zmiany (w nano naciskając ctrl+O i potwierdzając enterem), a następnie zamykamy edytor (w nano ctrl+X). Pozostało nam teraz zrestartować SSH przy pomocy polecenia:

sudo service ssh restart

Nasze aktualne połączenie nie zostanie zerwane, ale od tej chwili każde nowe połączenie do naszego serwera musi odbywać się na porcie wpisanym do pliku konfiguracyjnego. Zanim będzie to możliwe, musimy otworzyć ten port na naszym firewallu. Wracamy więc do przeglądarki i panelu zarządzania EC2.

W grupie „Network & Security” odnajdujemy zakładkę „Security Groups”, a następnie klikając na naszą grupę prawym przyciskiem myszy wybieramy opcję „Edit inbound rules”. Teraz w miejsce SSH wybieramy „Custom TCP Rule” i podajemy numer wybranego wcześniej portu, zatwierdzając na końcu zmiany przyciskiem „Save”.

ec2_custom_ssh

Powinno być już możliwe nawiązanie nowego połączenia. Jeśli łączymy się z konsoli musimy dodać parametr „-p” i dopisać po nim numer portu, a więc w moim przypadku będzie to:

ssh -i ~/.ssh/test1-keys.pem ubuntu@52.29.70.252 -p 56321

Jeśli łączymy się przy pomocy putty na liście zapisanych połączeń wybierzmy odpowiednie, wczytajmy ustawienia przy pomocy przycisku „load”, zmieńmy numer portu i ponownie zapiszmy profil połączenia.

ec2_custom_ssh_3

Podsumowanie

Po tej części nasz system jest w pełni aktualny, a SSH działa na innym niż domyślny porcie. Tak jak wspominałem nie gwarantuje to oczywiście 100% bezpieczeństwa i warto zainteresować się różnymi narzędziami, które mogą nam pomóc w „utwardzaniu” (hardening) naszego systemu, oraz w wykrywaniu potencjalnych zagrożeń. W następnej części przejdziemy do instalacji oprogramowania niezbędnego do działania naszej maszyny w charakterze serwera www.

Część 1
Część 2
Część 3
Część 5
Część 6
Część 7
Część 8

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *