05.02.2024 | 10:37

Grzegorz Wróbel

Budowa bezpiecznego homelabu – jak łatwo zadbać o bezpieczeństwo serwerów na Linuksie?

Pierwszy artykuł o domowym laboratorium komputerowym spotkał się z waszym dużym zainteresowaniem, więc kontynuujemy temat – dzisiaj pochylimy się nad podstawowymi kwestiami bezpieczeństwa takiego rozwiązania.

Wiecie już, czym jest homelab i dlaczego warto go zbudować. Czas zatem poznać kilka propozycji oraz podejść do łatwego podniesienia bezpieczeństwa systemów opartych na Linuksie. Kilka z przedstawionych zagadnień będzie miało znaczenie w kolejnych odcinkach, gdzie skupimy się na konfiguracji poszczególnych narzędzi, takich jak np. Wazuh.

Artykuły w tej serii mają w założeniu mieć charakter praktyczny. Stąd też celowo pomijamy aspekty instalacji i bazowej konfiguracji systemu oraz usług (informacji na ten temat w sieci nie brakuje), a skupiamy się wyłącznie na najważniejszych zagadnieniach związanych z danym tematem.

W tym artykule znajdziecie subiektywną listę rozwiązań, które możecie wykorzystać do zabezpieczenia systemów linuksowych. Narzędzia te nie są jedynymi dostępnymi do wykorzystania, ale są uniwersalne i łatwe w zastosowaniu przy budowie homelabu. W artykule omówimy: 

  1. Dobór dystrybucji pod docelowe zastosowania w homelabie.
  2. Firewall – na przykładzie UFW pokazujemy, jak łatwo wdrożyć politykę firewalla na Linuksie.
  3. Bezpieczeństwo SSH – wskazujemy, jaki kierunek warto obrać przy wykorzystaniu tego podstawowego protokołu komunikacyjnego.
  4. Fail2Ban – pokazujemy, jak łatwo można zredukować listę prób ataków na usługę SSH.
  5. Lynis – wskazujemy, jak przeprowadzić audyt stanu bezpieczeństwa systemu oraz usług na nim działających w oparciu o rekomendacje standardu CIS. 
  6. Auditd – wdrażamy mechanizm logowania zdarzeń systemowych.
  7. LKRG – wspominamy o module jądra Linuxa, które warto rozważyć jako prewencyjną ochronę jądra przed exploitami.
  8. Ansible – krótka zapowiedź automatyzacji z Ansible, która nawet w małym środowisku homelabowym znacznie upraszcza proces administracji serwerami.

Jaką wybrać dystrybucję i gdzie uruchamiać?

Możemy wybrać dowolną dystrybucję Linuksa. Warto poznać kilka z nich, aby zobaczyć różne podejścia do użytkowania, zarządzania czy utrzymywania. Wiele osób zaczyna od dystrybucji takich jak Ubuntu, Debian czy Fedora, a bardziej ambitni od Rocky Linuxa (następcy CentOS), Archa, a nawet Gentoo. Wszystko zależy od tego, jakie macie plany, a także ile czasu chcecie poświęcić na zagadnienia, które planujecie realizować z wykorzystaniem danej dystrybucji. 

Na pewno warto zwrócić uwagę na długość wsparcia dla danej dystrybucji, dlatego w przypadku np. Ubuntu polecamy wydania LTS (ang. Long Time Support). Mają one zapewniony dłuższy czas wsparcia w kontekście aktualizacji systemowych i poprawek bezpieczeństwa. Drugim istotnym aspektem jest także popularność samej dystrybucji – im większa, tym łatwiej będzie znaleźć rozwiązania naszych problemów.

W tej serii artykułów będziemy uruchamiać hosty oparte na dystrybucji Ubuntu Server 22.04 LTS.

Gdzie uruchamiać wspomniane dystrybucje? Wszystko zależy od tego, czym dysponujecie w swoim homelabie. Może to być stary komputer stacjonarny, dedykowana stacja robocza lub serwer, a może po prostu Raspberry Pi. Możecie postawić samodzielny, czysty system lub skorzystać z gotowych rozwiązań wirtualizacyjnych jak Proxmox czy ESXi. Oczywiście pamiętajcie też o możliwości konteneryzacji z wykorzystaniem np. Dockera.

W domu mam dedykowany serwer pod wirtualizację, na którym postawiłem Proxmoxa i tam hostuję większość usług uruchomionych w sieci. Na innym z serwerów zainstalowałem Ubuntu Server 22.04 LTS, który obsługuje skonteneryzowane usługi. Taki model pozwala mi na różne warianty testów i korzystania z wybranych usług.

Systemowy firewall – iptables, UFW 

Firewall możemy skonfigurować na dwa sposoby. Możemy pójść ścieżką klasyczną w postaci iptables lub cel zrealizować znacznie łatwiejszym narzędziem do zarządzania regułami, czyli UFW. Poniżej pokażemy bardzo prosty przykład polityki do wdrożenia na przykładzie UFW. 

Dobrą zasadą (jeśli tylko to możliwe) jest ograniczenie zewnętrznego dostępu do usług na serwerze tylko do określonej listy źródeł. Podobnie możemy zrobić także lokalnie w komunikacji wychodzącej z naszego systemu. Upraszczamy w ten sposób aspekt pilnowania nadmiarowo dostępnych usług sieciowych, które są uruchamiane na zarządzanym przez nas serwerze. 

UFW jest domyślnie dostępny w dystrybucji Ubuntu, dlatego w pierwszej kolejności dodamy reguły, które stworzą bazową politykę. Następnie uruchomimy UFW i wyświetlimy dodane reguły. Zacznijmy od blokady ruchu przychodzącego z wyjątkiem usługi SSH.

sudo ufw default deny incoming
sudo ufw allow OpenSSH

Następnie zablokujmy ruch wychodzący z wyjątkami dla protokołu HTTP, HTTPS, DNS oraz SSH.

sudo ufw default deny outgoing
sudo ufw allow out http
sudo ufw allow out https 
sudo ufw allow out 53
sudo ufw allow out OpenSSH

Ostatnim krokiem jest uruchomienie UFW i podejrzenie dodanych reguł w trybie numeracji.

sudo ufw enable
sudo ufw status numbered

W ten sposób wdrożyliśmy naszą podstawową politykę firewalla dla komunikacji zarówno IPv4, jak i IPv6. Jak widać, można ją edytować w prosty i klarowny sposób. Prawda, że łatwe?

Podstawowe zabezpieczenia protokołu SSH 

Rekomendujemy skorzystanie z wytycznych CIS. Znajdziecie tam szereg podstawowych i rekomendowanych zabezpieczeń do wdrożenia. W przypadku SSH zwrócimy uwagę na najbardziej istotne zagadnienia:

Kolejną naszą rekomendacją jest zainstalowanie Fail2Ban, który będzie wykrywał próby nieautoryzowanego dostępu do serwera SSH. Będzie on blokował tych bardziej aktywnych atakujących na podstawie zdefiniowanej przez nas polityki.

Instalacja i konfiguracja sprowadza się do kilku komend. Najpierw skorzystamy z menadżera apt, a następnie tworzymy własny “jail.local”, który jest plikiem konfiguracyjnym dla naszych polityk. Możemy go stworzyć na podstawie kopii domyślnie dostępnej konfiguracji.

sudo apt update 
sudo apt install fail2ban 
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Przedstawione poniżej parametry są bazowe dla uruchomienia usługi. Kolejno wymienione regulują czas blokady, określają maksymalną liczbę prób nieudanego logowania, a także okres, w którym weryfikowana jest liczba takich prób.

bantime  = 10m
maxretry = 5
findtime = 10m

W dalszej części konfiguracji musimy dodać jeszcze parametry dla wybranego przez nas protokołu. Poniższa konfiguracja będzie miała zastosowanie dla protokołu SSH. 

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

Po zapisaniu zmian wystarczy z pomocą polecenia systemctl zrestartować usługę, a także ustawić ją jako domyślnie uruchamianą przy starcie systemu. 

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

W efekcie, gdy ktoś spróbuje zalogować się do naszego serwera w sposób nieautoryzowany, po liczbie ustalonych przez nas błędnych logowań zostanie zablokowany.

Lynis – sprawdzamy poziom zabezpieczenia systemu

Do weryfikacji stanu zabezpieczeń wykorzystamy program Lynis, który przeprowadza lokalny skan systemu operacyjnego. Otrzymamy raport podsumowujący aktywne zabezpieczenia lub ich brak, bazujący na wytycznych standardu CIS. 

Standard CIS, a dokładniej Center of Internet Security, robi mnóstwo dobrej roboty dla budowania świadomości bezpieczeństwa,  na przykład udostępniając za darmo dedykowane rekomendacje hardeningu systemów i usług sieciowych.

Uruchomienie Lynisa sprowadza się do kilku komend. Pobieramy najnowszą paczkę Lynisa, rozpakowujemy ją, zmieniamy uprawnienia dla katalogu Lynisa pochodzącego z paczki, a następnie przechodząc do niego uruchamiamy funkcję audytu całego systemu.

wget https://downloads.cisofy.com/lynis/lynis-3.0.9.tar.gz
tar xvf lynis-3.0.9.tar.gz 
sudo chown -R 0:0 lynis
cd lynis/
sudo ./lynis audit system

W rezultacie możemy spodziewać się całkiem sporej listy zagadnień ocenionych przez Lynisa. Na czystym i nieskonfigurowanym docelowo systemie należy oczekiwać szeregu “niezgodności” dla przeanalizowanych ustawień. Poniższy raport prezentuje listę sprawdzonych parametrów kernela z wytypowaniem odchyleń dla rekomendowanych wartości (podanych w nawiasie po nazwie). Są one zgodne ze wspomnianymi rekomendacjami zabezpieczeń od CIS, a także dokładnie wytłumaczone w samym dokumencie. Aby go pobrać, musicie wypełnić formularz. Pamiętajcie, że są one przeznaczone do niekomercyjnego zastosowania. 

Całość raportu wieńczy podsumowanie, które w punktacji 0-100 prezentuje stan bezpieczeństwa audytowanego systemu. Na tej podstawie jesteśmy w stanie przeanalizować braki w konfiguracji systemu oraz usług na nim działających. Wyznacza to praktyczny kierunek sukcesywnej poprawy zabezpieczeń, a także daje możliwość ich weryfikacji ad-hoc. 

Logowanie zdarzeń w systemie 

Dzienniki zdarzeń to jeden z kluczowych mechanizmów bezpieczeństwa, pomagających zarówno monitorować anomalie, jak i analizować ewentualne incydenty. My skorzystamy z Auditd, popularnego rozwiązania na systemach opartych na Linuksie. Pozwala na kolekcjonowanie zdarzeń, które mają miejsce w przestrzeni użytkownika systemowego, a także w samym jądrze systemu. 

Instalacja i wdrożenie reguł do monitorowania jest prosta i wymaga użycia kilku komend. Reguły możemy dodać i budować w oparciu o wytyczne wspomnianego już benchmarku CIS lub skorzystać z gotowych list, dostępnych np. tutaj

sudo apt update 
sudo apt install auditd

Reguły zapisywane są w pliku /etc/audit/rules.d/audit.rules. Za pomocą polecenia auditctl -l możemy je wyświetlić. W domyślnej instalacji nie uświadczymy jednak żadnej reguły.

Dla pokazania, jak działa Auditd, dodajmy dwie proste reguły do pliku audit.rules. Będą one rejestrować zdarzenie uruchomienia przez użytkownika komendy nc. Warto ją monitorować  z uwagi na częste wykorzystanie przez atakujących do otwierania portów dla zdalnego dostępu.

sudo auditctl -w /usr/bin/nc -k netcat_use

Zdarzenie wywołamy poprzez uruchomienie komendy nc w powłoce użytkownika lokalnego. Znajdziemy je potem w logach z wykorzystaniem komendy ausearch.

nc -vz zaufanatrzeciastrona.pl 80
sudo ausearch -k netcat_use

Jak widać, zdarzenie zostało zarejestrowane. Wpis w logu dostarcza dużo detali technicznych do dalszej analizy. Na przykład Wazuh, opierając się na takich danych, jest w stanie np. informować o anomaliach w systemie. 

Linux Kernel Runtime Guard 

O LKRG pisaliśmy już w 2018 roku, a z jego autorem Adamem również poruszaliśmy temat tego narzędzia w Rozmowie Kontrolowanej. Jest to moduł kernela, który odpowiada za reagowanie na wykryte anomalie związane z próbami wykorzystywania podatności w systemie operacyjnym. Zapewnia weryfikację w trybie rzeczywistym integralności i konfiguracji jądra systemowego, a także monitorowanie kluczowych struktur danych i funkcji jądra. W praktyce LKRG może znacznie utrudnić wykorzystanie Metasploita przez atakującego czy zablokować próbę ucieczki z przejętego kontenera do systemu hostującego

Instalacja LKRG może wymagać większej uwagi i doświadczenia, ale nie jest żadnym wyzwaniem zarezerwowanym dla ekspertów. Poświęcimy jej w przyszłości osobny artykuł, tymczasem zachęcamy was do spróbowania samodzielnej instalacji i przetestowania. 

Pamiętajcie o automatyzacji 

Ansible to bardzo popularne narzędzie automatyzujące pracę z wieloma hostami. Usprawnia realizację nudnych, rutynowych zadań związanych z administracją systemami. W naszym homelabie możemy spodziewać się konieczności np. regularnych aktualizacji systemów. Wraz z rozwojem homelabu liczba rutynowych zadań, które nadają się do automatyzacji będzie tylko rosnąć :) 

Na razie zostawiamy was z ogólnym wprowadzeniem do Ansible’a, a w jednym z odcinków tej serii przyjrzymy się, jak łatwo adaptować playbooki Ansible’a do działania.

Nawyk bezpieczeństwa “by default”

Wdrożenie zabezpieczeń wcale nie musi być nie lada wyzwaniem. Warto wyrobić w sobie nawyk myślenia o bezpieczeństwie już od początku budowania nowych systemów i sieci. 

W artykule opisaliśmy tylko subiektywnie wybrane rozwiązania. Naszym celem jest budowa świadomości i zachęcanie do wdrażania i utrzymywania bezpiecznych systemów, dlatego pominęliśmy bardziej techniczne i wymagające zagadnienia. Podobnie z doborem narzędzi – chcemy zwrócić uwagę na łatwość ich wykorzystywania w praktyce. Jeśli jesteście chętni, aby któremuś z omawianych tematów przyjrzeć się bardziej – śmiało dajcie o tym znać w komentarzach! Pamiętajcie, że tego typu kwestie są też omawiane często na discordowym serwerze Zaufanej Trzeciej Strony.

Powrót

Komentarze

  • 2024.02.05 12:11 Tomilidzons

    A co sądzicie o unattended-upgrades w Debianie i pochodnych? Krytyczne aktualizacje będą się wgrywać same, można nawet ustawić automatyczny restart gdzieś w nocy.

    Odpowiedz
    • 2024.02.05 13:41 MateuszM

      To zależy. Ja osobiście nie lubię jak się coś instaluje bez mojej wiedzy. W Debianie nie ma z tym zazwyczaj problemu ale np. na Arch-u zdarzyło mi się kilka razy, że system po aktualizacji nie wstał albo pewne usługi się nie uruchomiły. Ogólnie na dystrybucjach „Enterprise” można tego (automatycznych aktualizacji) używać ale ogólnie bym nie ryzykował.

      Odpowiedz
    • 2024.02.05 13:59 Kili

      Niestety, ale unattended-upgrades na Debianie i pochodnych powodują problemy. Można ograniczyć je do aktualizacji security, ale problem z nimi jest jak z instalacją oprogramowania na tej rodzinie systemów linuksowych: brak historii transakcji, pozwalającej wycofać zmiany uszkadzające system. Po dłuższym użytkowaniu pojawiają się problemy z konfliktami zależności. Można wtedy rozważyć alternatywne menadżery pakietów, ale unattended-upgrades wymusza używanie APT.

      Automatyczne aktualizacje na systemach innych niż Debian, to wręcz rzecz pożądana.

      Odpowiedz
    • 2024.02.05 14:50 Grzegorz Wróbel

      Również jestem zwolennikiem aktualizacji manualnych, nietrudno jest wyrobić sobie taki nawyk aby o nich nie zapomnieć.
      Dlatego z unattended-upgrades nie korzystałem zasadniczo :)

      Odpowiedz
    • 2024.02.06 08:41 Vad

      Korzystałem bardzo długo w zakresie security. Bez problemów. Nie musiałem pamiętać o aktualizacjach bezpieczeństwa, a jak chciałem nową wersję paczki wydaną, ale nie związaną z bezpieczeństwem, to wykonywałem to ręcznie. Taki kompromis, żeby nie wjechali przez podatność, a kontrolować zmiany softu.

      Odpowiedz
    • 2024.02.08 19:33 Mateusz

      Osobiście od lat hostuję własny serwer email i mam włączone pełne automatyczne aktualizacje, nie tylko security. Nie twierdzę, że na 100% nigdy nic się złego nie wydarzy, ale przez te już blisko 10 lat nie miałem ani jednego problemu z tym związanego.

      Odpowiedz
  • 2024.02.06 04:38 maximus

    caly sprzet i caly software w jednym miejscu.I nagle mamy awarie i trzeba wezwac pomoc i obcy ludzie widza dokladnie wszystko co i gdzie mamy i na czym pracujemy.Absurd

    Odpowiedz
    • 2024.02.06 14:48 Pan_Od_Awarii

      Nie czym w sumie o jakiej awarii szanowny Pan pisze. Ale zazwyczaj jak ktos nieznany wchodzi do mojego domu to:
      – zamykam drzwi;
      – nie naparzam w terminalu podczas wizyty, a wlasciwie kazdy sorzet hest zablokowany;
      – wszyscy moi goscie sa pod kontrola i zazwyczaj nie paletaja sie po pomieszczeniach;

      Ale zastanawiam jak wiele awarii szanowny Pan mial w swoim zyciu, bo mam wrazenie ze wiecej technikow/supportu zasuwalo mi po labach cloudowych niz w zyciu mialem awarii.

      Odpowiedz
    • 2024.02.06 14:51 Czytelnik

      Zawsze możesz podzielić mieszkanie na wiele mikrokawalerek i w każdej umieścić jedno urządzenie :-). Gdy ta seria artykułów się zakończy to przyjdzie czas na cykl: Hidden Home Lab – czyli jak urkyć nasze serwery przed żoną i teściami w meblach, podwieszanym suficie, wnękach w ścianach. Zaproszonymi gośćmi będzie ekipa od montażu klimatyzacji w Naczelnym Sądzie Administracyjnym, która w przewodach wentylacyjnych ukryła koparki kryptowalut.

      Odpowiedz
    • 2024.02.07 12:20 Pan_Od_Awarii

      Ale serio oczyma wyobrazni widze 2 technikow wezwanych do zapchanej toalety przechodzacych obok pracujacego Szanownego Pana i wywiazuje sie dialog:
      – widziales ?
      * widzialem!, leszczu z root’a pracuje,
      – i na dodatek na Proxmoxie, a my przeciez team VMware ESXi
      * musimy tutaj wrocic dzis w nocy, aby przeinstalowac mu system, i poprawic cable managment(to dla purystow jezykowych)
      …..

      Odpowiedz
      • 2024.02.07 15:04 Duży Pies

        na koniec powinieneś spuentować:
        * wyjaraliśmy po blancie i poszliśmy do dom…
        .
        Masz dobrą bajerę, ale czy pisanie bzdur, to nie strata czasu?

        Odpowiedz
  • 2024.02.07 19:35 grzebacz

    Czy w ogole wystawianie ssh (nawet z kluczem i na niestandardowym porcie) jest w 2024 r. dobrą praktyką?
    Osobiście wystawiam wyłącznie wireguarda, który nie jest gadatliwy i atakujący nie wie że tam jest i dopiero po połączeniu do serwera po wg łączę się z ssh. Wydaje mi się ze tak jest bezpieczniej. Mam rację ?

    Odpowiedz
    • 2024.02.08 10:53 GłównyInformatyk

      Masz rację

      Odpowiedz
  • 2024.02.12 08:30 Paweł

    A sprawy firewalla nie można załatwić przy pomocy pfSense czy OPNsense ?

    Odpowiedz
  • 2024.02.16 19:38 marek

    Błąd w konfiguracji fail2ban – brakuje zmiany opcji backend na systemd w jail.local.

    Bez tej zmiany wywala bląd: Have not found any log file for sshd jail, i nie odpala się.

    system: ubuntu

    Odpowiedz
  • 2024.02.28 23:57 hisomu

    Niestety ESXi od VMware już odpada, jako że Broadcom ich wykupił i zmienił politykę odnośnie ich darmowych produktów, a szczególnie ESXi dla rozwiązań typu HomeLab…
    Oprócz Proxmox’a, który swoją drogą jest super, polecam również XCP-ng :)
    Więcej można poczytać na ich oficjalnym profilu:
    https://kb.vmware.com/s/article/96168?lang=en_US

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Budowa bezpiecznego homelabu – jak łatwo zadbać o bezpieczeństwo serwerów na Linuksie?

Komentarze