Serwer www na Raspberry Pi5 z dostępem do internetu cz. 6 | Bezpieczeństwo serwera

Bezpieczeństwo serwera

Pisząc serię artykułów na temat własnego serwera www opartego na Raspberry Pi5, powinienem w sumie zacząć od bezpieczeństwa serwera internetowego. Ciężko jednak zabezpieczyć jest coś, co jeszcze praktycznie nie istnieje. Stawiając swój własny serwer według mojego samouczka, nie byłeś jednak całkowicie bezbronny i narażony na ataki z zewnątrz. Do takiej sytuacji bym nigdy nie dopuścił.

Skrypt instalacyjny jakiego użyłeś do postawienia własnego serwera, instaluje większość potrzebnego oprogramowania jak firewall i fail2ban i robi w nim odpowiednie wpisy. Robi też odpowiednie wpisy pod tym kontem w oprogramowaniu samego serwera.

O dodatkowym uszczelnieniu serwera (to sformułowanie jest bardziej właściwe) pod kontem jego bezpieczeństwa, napisałem już sporo w poprzednich częściach cyklu artykułów Serwer www na Raspberry Pi5 z dostępem do internetu, czego nie dało się też i w sumie uniknąć, gdyż wiele zagadnień jest ze sobą ściśle powiązanych.

Zagrożenia

Podłączając się do sieci internetowej, zawsze narażasz się na różnego rodzaju zagrożenia z tym związane. Różnego typu serwery, są tym bardziej na nie narażone. Włamania na serwer, ataki ddos, wykorzystanie naszego serwera do rozsyłania spamu, czy też uczynienie z niego elementu wchodzącego w skład tzw. botnetu, to tylko niektóre z zagrożeń na jakie narażony jest nasz serwer i z jakimi możesz się spotkać.

Wiele osób też z tego powodu, nie decyduje się na posiadanie własnego serwera sądząc, że sobie nie poradzi z jego odpowiednim zabezpieczeniem, a korzystając z gotowych rozwiązań jak np. konta hostingowe, czy ewentualnie serwery vps, mogą znacznie zminimalizować to zagrożenie. Czy rzeczywiście ?

Korzystając z tzw. kont hostingowych tak naprawdę nie wiesz, jakie zabezpieczenia stosuje twój hostingodawca, oraz czy w ogóle jakieś stosuje. Najczęściej są to podstawowe zabezpieczenia przed atakami ddos, antyspamowe w przypadku poczty, czy też przed włamaniem na serwer. Problem komplikuje dodatkowo fakt, że są to współdzielone maszyny i ich zabezpieczenie nie może w żaden sposób utrudniać korzystania z takiego konta ich klientom. Korzystających notabene z różnych skryptów, z różnych technologii i do różnych celów wykorzystujących takie konta. Jako, że nie masz fizycznego dostępu do takiej maszyny, nie możesz sam ingerować w poziom jej bezpieczeństwa. Musisz nie jako zaufać swojemu hostingodawcy i zaakceptować, to co on oferuje.

Zakupienie serwera vps w praktyce, w niczym nie różni się od tego jakbyś taki serwer miał postawić u siebie w domu i nie zwalnia ciebie z jego zabezpieczenia przed atakami z zewnątrz. Tak wiem, że różne firmy prześcigają się niejako w informacjach jakie to zaawansowane techniki zabezpieczeń stosują na swoich serwerach, jednak rzeczywistość często brutalnie to weryfikuje i pokazuje, że w dalszym ciągu takie serwery padają ofiarami skutecznych ataków ddos (o czym informuje co jakiś czas chociażby serwis Cloudflare), wchodzą w skład różnego rodzajów botnetów, czy też służą do rozsyłania spamu.

Rozpatrując dwa powyższe przypadki pamiętaj, aby zawsze dodatkowo uszczelnić własny serwer, czy też strony, przed zagrożeniami z zewnątrz. Bez względu na to, czy korzystasz z serwera postawionego na podstawie mojego tutoriala, serwera vps, konta hostingowego, czy jakiegokolwiek innego (np. w chmurze, serwera dedykowanego itp.). Pamiętaj także, że nie ma czegoś takiego jak 100% bezpieczeństwo, zawsze będzie istniało ryzyko naruszenia bezpieczeństwa twojego serwera. Twoim zadaniem jednak jest, to ryzyko jak najbardziej zminimalizować.

Posiadając własny serwer, masz jednak większe możliwości w jego uszczelnieniu.

Uszczelniamy nasz serwer

Uszczelnienie naszego serwera będzie wymagało kilku zmian i modyfikacji.

Uwaga: Zmieniając cokolwiek w plikach konfiguracyjnych swojego serwera, testuj od razu na bierząco wprowadzoną zmianę/modyfikację ze zwróceniem uwagi, czy wszystko działa prawidłowo po takiej zmianie. Jeżeli nie, poprawiaj swoje błędy na bieżąco. Pozwoli ci to uniknąć wielu problemów.

Firewall na routerze

Na routerze swojego dostawcy internetu, nie otwieraj nigdy do internetu portów oprogramowania, które ma działać lokalnie, jak serwery Mysql, serwery cachujące redis i memcache, serwery nas samba i nfs itp. bo to proszenie się o kłopoty. Otwieraj wyłącznie porty tych usług, które muszą być dostępne z internetu jak serwery www, panelu Ispconfig3, serwera ftp, ewentualnie panelu Webmin (opiszę w kolejnych częściach samouczka), czy też serwerów pocztowych jeśli takie posiadasz.

Firewall na serwerze

Twój firewall to UFW, opierający swoje działanie na łańcuchach iptables. Zarządzać nim możesz w prosty sposób poprzez swój panel Isponfig3. Na początek włącz reguły swojego firewalla w panelu Ispconfig3, jeśli dotychczas tego nie zrobiłeś i dostosuj jego konfigurację do własnych potrzeb. Usuń porty usług z jakich nie korzystasz (np. serwery pocztowe, czy dns bind) i dodaj te z jakich korzystasz np. redis, a aktualna lista ich nie uwzględnia. Więcej na ten temat pisałem w poprzednich częściach samouczka.

Uwaga: Nie otwieraj na firewallu portów usług, których nie udostępniasz na zewnątrz (poza serwer). Jeśli nie masz potrzeby udostępniania baz danych, serwerów cachujących redis i memcache itp. nie otwieraj ich portów na firewallu.

Uszczelniamy serwer Apache

Zainstalujemy sobie do tego celu dwie dodatkowe wtyczki dla naszego serwera Apache. Pierwszą będzie ModSecurity, a drugą ModEvasive. ModSecurity jest też wymagane, jeżeli będziesz chciał użyć dla niego filtra fail2ban opisanego poniżej.

ModSecurity, to zestaw różnego rodzaju filtrów i reguł poprawiających bezpieczeństwo, a także wydajność naszego serwera.

ModEvasive, to między innymi zestaw filtrów pomagających ominąć potencjalne ataki dos, ddos, bruteforce, wycelowane w nasz serwer www.

Wydaj w konsoli swojego serwera polecenia

# sudo apt install libapache2-mod-security2 libapache2-mod-evasive
# sudo a2enmod security2
# sudo a2enmod evasive
# sudo restart apache2

ModSecurity ma wiele opcji konfiguracyjnych ale jeśli nie potrzebujesz dodatkowo włączyć jakiejś opcji w jego ustawieniach lub zmodyfikować jakiś parametr, a do tego nie wiesz dokładnie co robisz, standardowa jego konfiguracja będzie ok.

Dodaj tylko w panelu IspConfig3 w polu Dyrektywy Apache, dla swojej strony lub stron (lub w pliku .htaccess) poniższe wpisy

# Włączenie reguł ModSecurity jeśli moduł włączony jest na serwerze
<IfModule mod_security2.c>
SecRuleEngine On
</IfModule>

# Modyfikacja standardowych reguł ModEvasive
<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
</IfModule>

Są to standardowe ustawienia zalecane przez twórcę wtyczki ModEvasive. Po więcej informacji odsyłam na https://github.com/jzdziarski/mod_evasive.

Standardowo ModEvasive, posiada już zdefiniowane standardowe wartości. Drobna modyfikacja tych wartości, według powyższego przykładu jednak, może pomóc w lepszym wykorzystaniu wtyczki.

DOSHashTableSize – Rodzaj tablicy, która definiuje liczbę węzłów najwyższego poziomu dla każdego elementu podrzędnego. Zwiększenie tej liczby jak w przykładzie powyżej, zapewni lepszą wydajność, jednak zużywa więcej pamięci. Jeżeli masz problem z nadmiernym wykorzystaniem pamięci na serwerze. Zmniejsz tą wartość, do pożądanych wartości.

DOSPageCount – Próg liczby żądań na interwał, dotyczący tej samej strony. Po przekroczeniu którego, adres ip klienta wysyłającego żądania do serwera www, zostanie zablokowany.

DOSSiteCount – Próg całkowitej liczby żądań na interwał, do jakiegokolwiek obiektu witryny. Po przekroczeniu którego, adres ip klienta wysyłającego żądania do serwera www, zostanie zablokowany.

DOSPageInterval – Czas interwału dla DosPageCount. W przykładzie 1s.

DOSSiteInterval – Czas interwału dla DosSiteCount. W przykładzie 1s.

DOSBlockingPeriod – Czas blokady w sekundach. W tym czasie zablokowany klient będzie otrzymywał błąd 403

Fail2Ban

Jest to pewnego rodzaju filtr. który działa tak, że jak wykryje jakieś nieprawidłowości klienta łączącego się z naszym serwerem, blokuje jego ip na określony czas. To, jakie usługi mają być brane pod uwagę oraz czas blokady definiujemy w pliku konfiguracyjnym dla reguł fail2ban.

Standardowo uruchomione będziesz miał jedynie reguły dla ssh. Warto jednak dodać inne np. dla serwera Apache lub Nginx, w zależności jaki serwer masz u siebie uruchomiony. Reguły dla fail2ban definiujesz w pliku /etc/fail2ban/jail.local lub jail.conf (gdzie są zdefiniowane wszystkie reguły dla fail2ban wraz z ich opisem).

Aby włączyć daną regułę, musisz do niej dopisać dodatkową linię enable = true. Aby zachować porządek, wszystkie reguły definiuj w jail.local. Usuń więc z pliku jail.conf linię enable = true w sekcji [sshd], aby uniknąć duplikatu. Będzie ona zdefiniowana w jail.local, więc bez sensu ją powielać dodatkowo w jail.conf.

Wyedytuj plik jail.local i dodaj do niego odpowiednie wpisy (przykład dla serwera apache), aby wyglądały jak w poniższym przykładzie.

[sshd]
#mode   = normal
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

[pure-ftpd]
enabled = true
port = ftp
filter = pure-ftpd
logpath = /var/log/syslog
maxretry = 3

[apache-auth]
enabled = true
port     = http,https
logpath  = %(apache_error_log)s

[apache-badbots]
enabled  = true
port     = http,https
logpath  = %(apache_access_log)s
bantime  = 48h
maxretry = 1

[apache-noscript]
enabled  = true
port     = http,https
logpath  = %(apache_error_log)s

[apache-overflows]
enabled  = true
port     = http,https
logpath  = %(apache_error_log)s
maxretry = 2

[apache-nohome]
enabled  = true
port     = http,https
logpath  = %(apache_error_log)s
maxretry = 2

[apache-botsearch]
enabled  = true
port     = http,https
logpath  = %(apache_error_log)s
maxretry = 2

[apache-fakegooglebot]
enabled  = true
port     = http,https
logpath  = %(apache_access_log)s
maxretry = 1
ignorecommand = %(fail2ban_confpath)s/filter.d/ignorecommands/apache-fakegoogleb

[apache-modsecurity]
enable = true
port     = http,https
logpath  = %(apache_error_log)s
maxretry = 2

[webmin-auth]
enabled = true
port    = 10000
logpath = %(syslog_authpriv)s
backend = %(syslog_backend)s

Zwróć jednak uwagę na to, jakie filtry chcesz uruchomić. Usuń więc z tej listy te, z których usług nie będziesz korzystał (np. webmin, jeśli go nie posiadasz) i dodaj ewentualnie te, które będą tobie potrzebne (np, serwerów poczty, jeżeli takie posiadasz lub służące do monitorowania serwera jak np. Monit).

[…] – to co jest pomiędzy tymi nawiasami definiuje nazwę danego filtra i nie powinno być modyfikowane.

enabled – czy filtr ma być włączony (true), czy też wyłączony (false). Brak tego parametru definiuje filtr jako wyłączony.

port – czyli port (lub jego alias) na jakim działa dana usługa. Jeżeli zmienisz standardowy port w danej usłudze np. bazy danych, czy ssh, to powinieneś też zmienić go w pliku konfiguracyjnym dla tych filtrów.

maxretry – maksymalna ilość błędnych połączeń, logowań itp. w przeciągu zdefiniowanego czasu, po jakich ma nastąpić blokada. Wartość opcjonalna, jeśli nie zdefiniowana brana jest pod uwagę wartość standardowa zdefiniowana w pliku jail.conf.

bantime i findtime – to kolejno czas na jaki ip ma być banowany oraz czas jaki musi upłynąć pomiędzy wykrytymi nieprawidłowościami, aby licznik zaczął liczyć je od zera. np jeśli bantime i findtime zostaną ustawione na 5min to, gdy fail2ban wykryje jakąś nieprawidłowość, i kolejną po np. 4min i 59s. nałoży blokadę na ip na okres 5min. Gdy kolejna nieprawidłowość jednak, zostanie wykryta dopiero po np. 5min i 2sek, to blokada taka nie zostanie nałożona. Ten dość prosty trik skutecznie utrudnia ataki typu DoS, niewielkie ataki typu DDDoS oraz Bruteforce na nasz serwer. Tutaj podobnie jak w maxretry. Jeśli nie zdefiniujesz jawnie tych wartości w danym filtrze, zostaną przypisane im wartości domyślne.

Zapisz plik konfiguracyjny i zrestartuj fail2ban

# sudo systemctl restart fail2ban

następnie sprawdź, czy usługa fail2ban się uruchomiła.

# systemctl status fail2ban

Musi mieć ona status avtive.

CloudFlare

Potężne narzędzie, dzięki któremu możesz ukryć swój prawdziwy adres ip i tym samym znacząco zwiększyć poziom bezpieczeństwa swojego serwera i stron www.

Jako, że jest to serwer pośredniczący, komunikacja na portach 443 oraz 80 z twoim serwerem www powinna być nawiązywana jedynie z Cloudflare, dopiero on powinien udostępniać odpowiednie treści itp. ukrywając nie jako za sobą Twój serwer.

Żeby to było możliwe, musisz mieć włączone proxy na rekordach dns odpowiedzialnych za połączenia ze stronami internetowymi (rekordy A i ewentualnie CNAME jeśli masz je zdefiniowane) – taka pomarańczowa chmurka przy rekordzie strony.

Niesie to ze sobą jednak pewną niedogodność. Nie masz możliwości połączenia się z twoim serwerem ftp, poprzez adres twojastrona.pl, wpisywany jako nazwa serwera. Połączyć się możesz jedynie poprzez wpisanie fizycznego, zewnętrznego adresu ip swojego serwera lub możesz stworzyć kolejny rekord a/subdomenę nie chronioną poprzez proxy specjalnie dla połączeń ftp i za jej pomocą łączyć się z serwerem FTP. Nie powinna być to raczej nazwa ftp.mojastrona.pl, a jakaś bardziej indywidualna nazwa, aby miało to jakiś sens. Osobiście preferuję ten pierwszy sposób.

Jako, że proxy nie obejmuje innych rekordów jak poczty – mx, txt – spf, dkim itp. istnieją sposoby , aby taki adres ip jednak namierzyć. Nie jest to więc ochrona absolutna, a jedynie kolejna cegiełka do uczynienia z twojego serwera małej fortecy.

Kilka słów na zakończenie

Naniesione poprawki bezpieczeństwa opisane w niniejszym tutorialu, są w stanie, w znacznym stopniu podnieść bezpieczeństwo Twojego serwera. Dobrane one zostały w taki sposób, aby dodatkowo nie obciążać za bardo samego RaspberryPi i nie powodować potencjalnych problemów i konfliktów, z których usunięciem miałbyś problem.

Zawsze jednak powinieneś dodatkowo kierować się pewnymi zasadami.

• Twórz silne hasła
• Nie ufaj cudownym poradnikom, rodzaju jak np. szybko i w łatwy sposób podnieść bezpieczeństwo danej usługi, czy też samego serwera. Zawsze dokładnie wszystko sprawdzaj i analizuj, jeśli już musisz z czegoś skorzystać.
• Analizuj logi. Przynajmniej co jakiś czas sprawdzaj obciążenie serwera (komenda top, htop lub btop, wydana w konsoli twojego serwera z uprawnieniami root) , czy obciążenie raptownie z dnia nadzień nie wzrosło zacznie i analizuj logi. Mało prawdopodobne jest, aby Twoja strona internetowa z dnia nadzień zyskała setki, czy tysiące nowych użytkowników i dzięki temu wzrosło znacznie obciążenie serwera. Bardziej prawdopodobne jest, że serwer przechodzi właśnie jakiś atak ddos, stał się elementem jakiegoś botnetu lub wysyłany jest z niego masowo jakiś spam :] Analizuj logi i reaguj od razu w przypadku wystąpienia problemu, uszczelniając luki w bezpieczeństwie.
• Aktualizuj na bieżąco oprogramowanie serwera wydając w konsoli serwera polecenia

# sudo apt update
# sudo apt upgrade

Codziennie wykrywane są jakieś luki w oprogramowaniu, które są potem łatane, więc jest to bardzo ważne.

• Chroń swoje hasła i nie udostępniaj ich osobom trzecim, a już na pewno nieznajomym z internetu, którzy to niby znaleźli u ciebie jakąś lukę, czy problem i są gotowi ją usunąć za darmo, albo prawie za darmo. W imię wyższych idei :].
• Nigdy nie zmieniaj konfiguracji swojego oprogramowania na serwerze, jeśli nie wiesz dokładnie co robisz. Jeden błąd może narazić twój serwer na ataki. Przykład ? Włączenie możliwości połączeń za pomocą protokołu UDP, w serwerze Memcached (standardowo powinny być one wyłączone, przynajmniej w nowszej wersji oprogramowania Memcached. Takie masz zainstalowane jeśli stawiałeś serwer według samouczka niniejszej serii artykułów), może spowodować nieautoryzowane połączenia z nim przez osoby trzecie, które nie powinny mieć do niego dostępu. Takie połączenia w ekstremalnych sytuacjach mogą przybrać formę ataku, poprzez wysycenie całego limitu przyznanego Memcached.
• Nie udostępniaj żadnych portów na zewnątrz swojego serwera, a już na pewno do internetu jeśli nie masz takiej potrzeby. Firewall służy do tego, aby nieużywane porty były na nim zablokowane. Odblokowane powinny być tylko niezbędne porty, do prawidłowego działania takich usług jak www, ftp, poczta, panel www itp.
• Oprócz samego serwera (jako maszyny), nie pomijaj też poprawy bezpieczeństwa samych stron internetowych, poczty itp. To zawsze przynosi korzyści wcześniej, czy później. Nie zaszkodzi, a może pomóc.
• Jeśli korzystasz z Cloudflare, ukrywaj w miarę możliwości rekordy A i CNAME za serwerem proxy (nie zawsze jest to możliwe). Gdy wykryjesz atak ddos lub masz podejrzenie, że taki właśnie ma miejsce, nie wahaj się włączyć odpowiedniej ochrony do przeciwdziałania mu w panelu Cloudflare. Opcja Under Attack.

Jak możesz zauważyć, niektóre narzędzia (a właściwie ich przeznaczenie), czasem się pokrywają w swoim działaniu. Możesz odnieść wrażenie, że na przykład ModEvasive Apache i niektóre reguły Fail2Ban, odpowiedzialne za przeciwdziałanie atakom DoS, DDoS, czy BruteForce na strony www, pełnią to samo zadanie.

Narzędzia te jednak, działają w odmienny sposób i nie kolidują ze sobą. W efekcie jest duża szansa, że to czego nie wychwyci np. ModEvasive, wychwyci Fail2Ban i odwrotnie.

Temat bezpieczeństwa serwerów internetowych, to dość rozbudowane zagadnienie. Jeśli będziesz miał jakieś pytania, czy wątpliwości najlepiej zostaw komentarz pod niniejszym artykułem, a postaram się na niego odpowiedzieć w miarę swoich możliwości i dostępnej wiedzy.

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 1

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 2

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 3

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 4

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 5