Linux Security - 7 warstw ochrony, które działają!

Bezpieczeństwo Linuksa nie sprowadza się do jednego narzędzia. W praktyce liczą się uprawnienia użytkowników, szybkie aktualizacje, dobrze ustawiona zapora, ograniczenie usług oraz kopie zapasowe, które naprawdę da się odtworzyć. To praktyczny przewodnik po linux security w codziennej administracji, bez nadmiaru teorii i bez sztucznych uproszczeń.

Od czego naprawdę zależy bezpieczeństwo Linuksa

Linux jest bezpieczny przede wszystkim dlatego, że dobrze rozdziela uprawnienia, a nie dlatego, że sam z siebie jest „niewrażliwy”. Standardowy model opiera się na prawach użytkownika, grupy i innych użytkowników, czyli na klasycznym DAC. To działa dobrze, dopóki nie da się jednej aplikacji zbyt szerokich praw albo nie zostawi się administratora bez dyscypliny.

W praktyce największe znaczenie ma zasada najmniejszych uprawnień. Jeśli usługa ma dostęp tylko do jednego katalogu i jednego portu, to nawet po kompromitacji szkody zwykle są mniejsze. Nad tym modelem działają dodatkowo mechanizmy LSM, czyli Linux Security Modules, które pozwalają wymuszać bardziej szczegółowe reguły dla procesów. To ważne, bo sam kernel ma własne mechanizmy obronne, ale one nie naprawią złej konfiguracji systemu ani nie zastąpią rozsądnej administracji.

Ja zwykle zaczynam od prostego pytania: co w tym systemie naprawdę musi działać, a co zostało włączone „na wszelki wypadek”? Od tej odpowiedzi zależy reszta, bo najłatwiej zabezpiecza się system, który nie jest przeładowany usługami. Kiedy ten fundament jest jasny, można przejść do kont, uprawnień i pracy administratora.

Jak ustawić konta, uprawnienia i dostęp administratora

Najwięcej błędów zaczyna się od przyzwyczajenia do pracy na koncie zbyt uprzywilejowanym. Na laptopie domowym często kończy się to wygodą, ale na serwerze taki nawyk jest po prostu ryzykowny. Bezpieczniej jest używać zwykłego konta do codziennych zadań i sięgać po prawa administracyjne tylko wtedy, gdy są potrzebne.

1. Tworzę osobne konto do codziennej pracy, a nie loguję się stale jako administrator.
2. Używam sudo, ale tylko tam, gdzie to potrzebne, i nie daję szerokiego dostępu całej grupie „na zapas”.
3. Wyłączam logowanie rootem przez SSH, jeśli zdalny dostęp jest w ogóle potrzebny.
4. Do logowania zdalnego wolę klucze SSH niż hasła, a tam, gdzie to możliwe, dokładam drugi czynnik uwierzytelniania.
5. Sprawdzam prawa do plików i katalogów, bo zbyt szerokie chmod 777 to szybka droga do kłopotów, nie do wygody.

W większych środowiskach przydają się też ACL, czyli dodatkowe listy uprawnień. To dobre rozwiązanie wtedy, gdy standardowy model właściciel-grupa-inni jest za mało elastyczny, ale nie chcesz otwierać katalogu szerzej niż trzeba. Na serwerach zwracam też uwagę na umask, bo zbyt liberalna domyślna maska tworzy pliki i katalogi z prawami, które potem trzeba ręcznie porządkować.

W praktyce to właśnie tutaj wygrywa się dużą część bezpieczeństwa. Gdy lokalne uprawnienia są już pod kontrolą, największą powierzchnię ataku zwykle otwiera sieć.

Jak zamknąć niepotrzebne porty i nie zepsuć sobie dostępu

Jeśli miałbym wskazać jedną rzecz, którą warto sprawdzić pierwszą, byłaby to lista aktywnych usług nasłuchujących na porcie. Zaskakująco często działa coś, czego nikt nie planował wystawiać na zewnątrz. Sam fakt, że usługa działa lokalnie, nie jest problemem. Problem zaczyna się wtedy, gdy odpowiada całej sieci.

Do zapory nie trzeba od razu podchodzić jak do projektu klasy enterprise. W codziennej administracji wystarcza prosty wybór narzędzia i konsekwencja w regułach. Na Ubuntu często spotyka się ufw, w środowiskach z bardziej rozbudowaną polityką strefową dobrze sprawdza się firewalld, a przy większej kontroli nad ruchem najwięcej daje nftables.

Ja sprawdzam przede wszystkim trzy rzeczy: które porty są otwarte, z jakich adresów mają być dostępne i czy reguły odpowiadają faktycznej roli maszyny. Do audytu przydaje się też szybki podgląd aktywnych nasłuchów, na przykład przez ss -tulpn. Jeśli po zamknięciu niepotrzebnych usług ktoś nadal próbuje dobijać się do SSH, można dołożyć narzędzie typu fail2ban, ale traktuję je jako warstwę pomocniczą, nie zastępstwo poprawnej konfiguracji.

Gdy sieć jest już uporządkowana, następny krok to mechanizmy, które ograniczają aplikacje nawet wtedy, gdy jedna z nich zostanie przejęta.

SELinux i AppArmor bez zbędnej teorii

SELinux i AppArmor rozwiązują ten sam problem, ale inną drogą. To mechanizmy Mandatory Access Control, czyli obowiązkowego wymuszania reguł, które działają obok zwykłych praw plików. Ich sens jest prosty: nawet jeśli proces zostanie przejęty, jego możliwości nadal są ograniczone profilem bezpieczeństwa.

Na Ubuntu częściej spotkasz AppArmor, a w rodzinie Red Hat i na wielu serwerach produkcyjnych częściej pojawia się SELinux. Z perspektywy administratora ważniejsze od samej nazwy jest to, że oba rozwiązania dobrze działają wtedy, gdy nie walczy się z nimi na siłę. Tryb permissive albo complain ma sens jako etap diagnostyczny, ale nie jako wygodny stan docelowy.

W dobrze ustawionym systemie takie profile nie przeszkadzają, tylko porządkują zachowanie usług. To szczególnie ważne przy serwerach WWW, bazach danych, usługach plikowych i wszystkich procesach, które mają kontakt z siecią. Jeśli aplikacja potrzebuje wyjątków, najpierw warto doprecyzować regułę, a nie od razu wyłączać cały mechanizm.

Po zamknięciu warstwy aplikacyjnej zostaje jeszcze najprostszy punkt ataku: opóźnione aktualizacje.

Aktualizacje, które naprawdę zmniejszają ryzyko

W praktyce większość problemów bezpieczeństwa zaczyna się od starego pakietu, starego kernela albo starej usługi, której nikt już nie monitoruje. Dlatego aktualizacje traktuję jako codzienną higienę, a nie jednorazowy projekt. Nowe wersje łatają nie tylko błędy funkcjonalne, ale też podatności, które dają zdalne wykonanie kodu, eskalację uprawnień albo wyciek danych.

Najrozsądniejszy rytm jest prosty: krytyczne poprawki tego samego dnia lub w ciągu 24 godzin, zwykłe aktualizacje w tygodniowym oknie serwisowym, a pełniejszy przegląd pakietów i usług przynajmniej raz w miesiącu. Na serwerach produkcyjnych dobrze działa automatyzacja aktualizacji bezpieczeństwa, ale tylko wtedy, gdy ktoś rzeczywiście sprawdza, co zostało zainstalowane i czy system po restarcie działa poprawnie.

• Instaluję pakiety z oficjalnych repozytoriów dystrybucji, a nie z przypadkowych skryptów pobranych z internetu.
• Usuwam usługi, których nie używam, zamiast tylko je wyciszać.
• Aktualizuję również firmware i komponenty sprzętowe, jeśli dystrybucja daje bezpieczną ścieżkę aktualizacji.
• Przy większych wdrożeniach trzymam punkt odniesienia w postaci benchmarków CIS dla konkretnej dystrybucji.

Nie traktuję aktualizacji jako „ostatniego kroku”. To raczej warstwa, do której wraca się stale, bo właśnie ona utrzymuje system w stanie, w którym wcześniejsze zabezpieczenia mają sens. Gdy masz już aktualny system, trzeba jeszcze zadbać o to, by awaria albo incydent nie zniszczył całej pracy.

Szyfrowanie i kopie zapasowe, czyli plan na moment, w którym coś pójdzie źle

Bez szyfrowania i dobrych kopii zapasowych bezpieczeństwo jest niepełne. Full-disk encryption z LUKS ma największy sens na laptopach, komputerach przenośnych i serwerach, do których ktoś może uzyskać fizyczny dostęp. Chroni dane wtedy, gdy sprzęt zniknie, zostanie przejęty albo trafi do serwisu.

Kopie zapasowe układam według zasady 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z jedną kopią poza głównym systemem. W praktyce dobrze działa też jedna kopia offline albo niemutowalna, bo ransomware bardzo często uderza właśnie w backup podpięty zbyt blisko produkcji. Snapshoty są wygodne, ale nie zastępują kopii. Pomagają wrócić do stanu z konkretnej chwili, lecz nie chronią przed błędnym usunięciem, awarią całego środowiska ani atakiem, który obejmuje również warstwę przechowywania.

• Szyfruję dyski na urządzeniach mobilnych i tam, gdzie fizyczny dostęp do sprzętu jest realnym ryzykiem.
• Oddzielam backup od systemu produkcyjnego, najlepiej także od tego samego konta administratora.
• Testuję odtwarzanie co kwartał, bo kopia, której nie sprawdziłem, jest tylko przypuszczeniem.
• Przechowuję jedną wersję poza główną lokalizacją lub poza siecią, jeśli skala systemu na to pozwala.

Gdy odzyskiwanie danych jest już pod kontrolą, zostaje jeszcze jedna rzecz, która zamyka całość: widoczność tego, co system robi na co dzień.

Logi i monitoring, które pozwalają zauważyć problem wcześniej

Bez logów administrator widzi zwykle tylko skutek, a nie początek incydentu. Dlatego przegląd zdarzeń z journald, logów uwierzytelniania i audytu traktuję jak część normalnej pracy, nie jako reakcję po fakcie. Na serwerach przydaje się również auditd, bo pozwala śledzić zmiany w newralgicznych miejscach, takich jak konfiguracja SSH, sudoers czy skrypty uruchamiane cyklicznie.

Najważniejsze sygnały ostrzegawcze są zwykle bardzo przyziemne:

• powtarzające się nieudane logowania do SSH lub paneli administracyjnych;
• nowe porty nasłuchujące bez uzasadnienia biznesowego;
• zmiany w katalogach systemowych, których nikt nie planował;
• dodanie nowych wpisów w sudoers albo zadań w cron bez zatwierdzenia;
• nietypowy ruch wychodzący z maszyny, która zwykle pracuje lokalnie.

W tym miejscu warto dołożyć narzędzia typu fail2ban, alerty z systemu monitoringu albo centralne zbieranie logów, jeśli mówimy o większej infrastrukturze. To nie jest dekoracja. To mechanizm, który pozwala zorientować się, że zabezpieczenia zaczynają być testowane, zanim problem urośnie do pełnego incydentu. Na tym etapie zostaje już tylko zamienić teorię w krótki plan działań, który da się wdrożyć od ręki.

Co wdrożyłbym najpierw na laptopie, a co na serwerze

• Na każdym systemie włączam aktualizacje bezpieczeństwa i sprawdzam, czy są naprawdę instalowane.
• Oddzielam konto użytkownika od konta administracyjnego i upraszczam dostęp tylko tam, gdzie to konieczne.
• Na serwerze zamykam wszystkie porty, których nie potrzebuję, i zostawiam tylko świadomie wystawione usługi.
• Włączam SELinux albo AppArmor zamiast traktować je jako opcjonalny dodatek.
• Szyfruję dysk tam, gdzie sprzęt może zniknąć lub trafić w niepowołane ręce.
• Utrzymuję backup z kopią offline i testuję odtwarzanie zanim naprawdę będzie potrzebne.

To właśnie taki zestaw daje najbardziej przewidywalny efekt. Nie wygląda spektakularnie, ale realnie ogranicza ryzyko, zmniejsza skutki błędu i ułatwia odzyskanie kontroli, gdy coś pójdzie nie tak. Jeśli chcesz iść krok dalej, benchmarki CIS dla swojej dystrybucji i regularny przegląd aktywnych usług to dobry następny ruch.