Jak zabezpieczyć serwer Linux

Linux jest często wybierany do hostingu, baz danych, systemów firmowych i usług sieciowych. Domyślna instalacja może być dobrym punktem wyjścia, ale dopiero konfiguracja dopasowana do roli serwera zapewnia rozsądny poziom ochrony. Hardening powinien być wykonany metodycznie i udokumentowany, aby kolejna aktualizacja lub zmiana administratora nie cofnęła wdrożonych zabezpieczeń.

1. Zacznij od roli i inwentaryzacji serwera

Przed zmianą ustawień trzeba wiedzieć, do czego serwer służy, jakie aplikacje obsługuje, kto się z nim łączy i jakie dane przechowuje. Należy spisać system operacyjny, wersję jądra, zainstalowane usługi, otwarte porty, konta, zadania cykliczne, certyfikaty, repozytoria i zależności aplikacji.

2. Aktualizacje i źródła oprogramowania

Aktualizacje bezpieczeństwa powinny być instalowane regularnie, a dla krytycznych podatności możliwie szybko. W środowisku produkcyjnym warto stosować okno serwisowe, testować aktualizacje na kopii lub serwerze testowym i posiadać możliwość wycofania zmiany. Repozytoria muszą pochodzić z zaufanych źródeł, a przypadkowe skrypty instalacyjne pobierane z internetu należy traktować jako kod wymagający przeglądu.

3. Zabezpieczenie SSH i kont administracyjnych

Dostęp administracyjny powinien być ograniczony do konkretnych adresów, sieci VPN lub hosta pośredniczącego. Zamiast współdzielonego konta należy używać indywidualnych kont z rejestrowaniem operacji przez sudo. Logowanie kluczem SSH jest zwykle bezpieczniejsze od samego hasła, pod warunkiem ochrony klucza prywatnego.

• wyłącz bezpośrednie logowanie użytkownika root przez SSH,
• zablokuj logowanie hasłem tam, gdzie można stosować klucze,
• usuń stare klucze i konta nieaktywnych administratorów,
• włącz MFA lub dodatkową warstwę dostępu dla systemów krytycznych,
• stosuj ochronę przed automatycznymi próbami logowania i analizuj logi.

4. Firewall i ograniczenie usług sieciowych

Firewall hosta powinien dopuszczać tylko wymagany ruch. Sam fakt, że serwer stoi za zaporą brzegową, nie oznacza, że lokalna filtracja jest zbędna. Pozwala ona ograniczyć ruch pomiędzy segmentami oraz zmniejszyć skutki błędu w konfiguracji sieci. Usługi administracyjne nie powinny być wystawione bezpośrednio do internetu, jeżeli można udostępnić je przez VPN.

5. Uprawnienia, pliki i tajne dane

Należy stosować zasadę najmniejszych uprawnień. Proces aplikacji powinien działać na osobnym koncie i mieć dostęp tylko do potrzebnych katalogów. Hasła, klucze API i certyfikaty nie powinny znajdować się w publicznych repozytoriach ani w plikach dostępnych dla wszystkich użytkowników. Wrażliwe pliki wymagają odpowiednich praw, a dane aplikacji warto oddzielić od kodu.

6. Logowanie i monitoring

Bez logów nie da się wiarygodnie ustalić, co wydarzyło się podczas incydentu. Należy monitorować logowania, użycie uprawnień administracyjnych, zmiany konfiguracji, błędy usług, nietypowy ruch i wykorzystanie zasobów. Dla ważnych systemów logi powinny być wysyłane do zewnętrznego systemu, aby atakujący nie mógł łatwo usunąć śladów.

7. Kopie zapasowe i odtwarzanie

Backup powinien obejmować dane, konfigurację, bazy oraz informacje potrzebne do odtworzenia usługi. Sama informacja „zadanie zakończone poprawnie” nie jest dowodem, że kopia nadaje się do użycia. Konieczne są cykliczne testy odtwarzania i przynajmniej jedna kopia odseparowana od serwera.

8. Standard i dokumentacja

W większej liczbie serwerów warto przyjąć wspólny standard konfiguracji i używać automatyzacji. Narzędzia audytowe oraz profile hardeningu mogą pomóc, ale nie zastępują analizy wpływu na aplikację. Nie każda rekomendacja jest właściwa dla każdego serwera, dlatego odstępstwa należy opisać i zaakceptować.