Linux Hardening: 25 rzeczy, które robię zaraz po instalacji Ubuntu, zanim serwer trafi do Internetu

Świeżo zainstalowany Ubuntu jest znacznie bezpieczniejszy niż jeszcze kilka lat temu. Ma włączony AppArmor, regularnie otrzymuje poprawki bezpieczeństwa i domyślnie nie udostępnia wielu usług. To jednak nie oznacza, że serwer jest gotowy do wystawienia publicznego adresu IP. W praktyce pierwsze minuty po uruchomieniu maszyny w chmurze często wystarczają, aby pojawiły się pierwsze próby skanowania portów, logowania przez SSH czy automatyczne boty szukające podatnych usług.

Po latach administracji serwerami wypracowałem prostą zasadę: zanim zainstaluję Docker, bazę danych czy serwer WWW, wykonuję zestaw podstawowych czynności, które znacząco zmniejszają powierzchnię ataku. Większość z nich zajmuje kilka minut, ale później potrafią oszczędzić wiele godzin walki z niepotrzebnymi incydentami.

Zanim cokolwiek uruchomisz, sprawdź, co już działa

Pierwszym odruchem wielu administratorów jest instalowanie kolejnych pakietów. Tymczasem znacznie rozsądniej jest najpierw sprawdzić stan systemu. Interesuje mnie przede wszystkim to, jakie usługi nasłuchują na portach sieciowych i czy nie działa coś, czego nie planuję używać.

Najwygodniejszym poleceniem pozostaje:

Bash

ss -tulpn

Ten jeden raport często mówi więcej niż kilka ekranów konfiguracji. Jeżeli serwer ma pełnić wyłącznie rolę hosta dla aplikacji WWW, nie potrzebuję otwartego serwera poczty ani usług testowych. Każdy zbędny proces zwiększa potencjalną powierzchnię ataku.

Aktualizacje wykonuję przed instalacją czegokolwiek

To pozornie oczywiste, ale w praktyce wiele osób instaluje aplikacje na nieaktualnym systemie. Zawsze zaczynam od:

Bash

sudo apt update
sudo apt full-upgrade -y

Dopiero potem przechodzę dalej. Dzięki temu wszystkie kolejne pakiety instalują się już na aktualnym fundamencie.

Tworzę zwykłego użytkownika i zapominam o codziennej pracy na root

Praca jako root jest wygodna tylko do momentu pierwszej pomyłki.

Tworzę osobne konto:

Bash

sudo adduser marek
sudo usermod -aG sudo marek

Od tej chwili większość administracji wykonuję przez sudo, co pozwala zachować lepszą kontrolę nad wykonywanymi operacjami.

SSH to pierwsza linia obrony

Największa liczba automatycznych prób włamań dotyczy właśnie SSH. Nie chodzi nawet o to, że port 22 jest „zły”. Problem polega na tym, że jest nieustannie skanowany.

Moja podstawowa konfiguracja obejmuje:

• wyłączenie logowania jako root,
• logowanie wyłącznie kluczami,
• ograniczenie liczby prób logowania,
• zmianę domyślnego portu tam, gdzie ma to sens.

To temat na osobny poradnik, który już znajduje się na Netbe.

Firewall powinien być pierwszą usługą, nie ostatnią

Jednym z najczęściej spotykanych błędów jest uruchomienie aplikacji, a dopiero później zastanawianie się nad firewallem.

W Ubuntu najwygodniejszym rozwiązaniem pozostaje UFW, czyli prosty interfejs dla netfilter.

Najpierw pozwalam na SSH:

Bash

sudo ufw allow OpenSSH

Następnie ustawiam domyślną politykę:

Bash

sudo ufw default deny incoming
sudo ufw default allow outgoing

Dopiero na końcu aktywuję firewall:

Bash

sudo ufw enable

Kolejność ma znaczenie. Włączenie UFW przed dodaniem reguły dla SSH może zakończyć zdalną administrację własnym serwerem. To jedna z najczęstszych pułapek podczas pierwszej konfiguracji.

AppArmor zostawiam w spokoju

Wielu początkujących administratorów wyłącza AppArmor, kiedy jakaś aplikacja zgłasza problem.

To zazwyczaj zły pomysł.

AppArmor ogranicza możliwości procesu nawet wtedy, gdy aplikacja zostanie skompromitowana. Zamiast go wyłączać, znacznie lepiej sprawdzić profil i ewentualnie dostosować konfigurację.

To jeden z tych mechanizmów, które niczego nie „przyspieszają”, ale potrafią uratować system w najgorszym momencie.

Wyłączam usługi, których nie potrzebuję

Ubuntu instaluje niewiele zbędnych usług, ale mimo wszystko sprawdzam:

Bash

systemctl list-unit-files --state=enabled

Każda niepotrzebna usługa to kolejny proces.

A każdy proces może zawierać błąd.

Automatyczne aktualizacje bezpieczeństwa

Nie wszystkie aktualizacje powinny instalować się automatycznie.

Aktualizacje bezpieczeństwa – już tak.

Najwygodniej zrobić to przez unattended-upgrades.

Dzięki temu krytyczne poprawki trafiają na serwer bez czekania na ręczną interwencję.

Hasła nie powinny być jedyną ochroną

Nawet silne hasło ma swoje ograniczenia.

Jeżeli tylko mogę, korzystam z kluczy SSH.

Przykładowo:

Bash

ssh-keygen -t ed25519

To jedna z tych zmian, która praktycznie nic nie kosztuje, a znacząco utrudnia automatyczne ataki.

Sprawdzam konfigurację DNS

Zły DNS potrafi powodować nie tylko problemy z wydajnością.

Może również wpływać na bezpieczeństwo aktualizacji i działania usług.

Dlatego zawsze sprawdzam:

Bash

resolvectl status

Docker nie powinien być pierwszym użytkownikiem systemu

To ciekawy przypadek.

Wiele osób instaluje Dockera od razu po systemie.

Ja najpierw zabezpieczam hosta.

Dopiero później instaluję kontenery.

To podejście znacząco upraszcza późniejsze zarządzanie.

Wyłączam logowanie hasłem przez SSH

To jeden z najważniejszych kroków.

W pliku:

/etc/ssh/sshd_config

zmieniam:

PasswordAuthentication no
PermitRootLogin no

Po restarcie usługi serwer akceptuje wyłącznie klucze.

Sprawdzam otwarte porty po każdej zmianie

Po instalacji nowej aplikacji ponownie uruchamiam:

Bash

ss -tulpn

To prosty nawyk.

Pozwala natychmiast zauważyć nieoczekiwane usługi.

Logi są ważniejsze niż dashboard

Nowoczesne dashboardy wyglądają efektownie.

Ale pierwszym miejscem, które sprawdzam podczas problemów, pozostaje:

Bash

journalctl -xe

Systemd dostarcza ogromnej ilości informacji.

Warto nauczyć się z nich korzystać.

Kopie zapasowe planuję od początku

Najgorszy moment na myślenie o backupie to chwila po awarii.

Minimalny plan obejmuje:

• konfigurację systemu,
• dane aplikacji,
• klucze SSH,
• pliki .env,
• bazy danych.

Testuję odzyskiwanie, nie tylko tworzenie kopii

Backup, którego nigdy nie odtworzono, jest tylko przypuszczeniem.

Regularne testy odtwarzania są równie ważne jak samo wykonywanie kopii.

IPv6 sprawdzam świadomie

Wiele serwerów działa jednocześnie na IPv4 i IPv6.

Jeżeli firewall zabezpiecza tylko IPv4, może powstać nieoczekiwana luka.

Dlatego zawsze sprawdzam obie konfiguracje.

Ograniczam liczbę pakietów

Im mniej oprogramowania, tym mniej potencjalnych podatności.

To jedna z najprostszych zasad hardeningu.

Monitoruję miejsce na dysku

Pełny dysk potrafi zatrzymać działanie usług szybciej niż atak.

Polecenie:

Bash

df -h

wraca do mnie regularnie.

Sprawdzam uprawnienia plików

Szczególną uwagę zwracam na:

• /etc,
• katalogi użytkowników,
• klucze SSH,
• pliki konfiguracyjne.

Błędne uprawnienia często są prostsze do wykorzystania niż skomplikowane podatności.

Dokumentuję każdą zmianę

Najlepszy administrator za pół roku nie pamięta wszystkiego.

Krótki plik z wykonanymi zmianami potrafi zaoszczędzić mnóstwo czasu.

Moja checklista pierwszych 25 minut

Po zakończeniu konfiguracji przechodzę przez prostą listę kontrolną.

• Aktualizacje systemu.
• Nowy użytkownik z sudo.
• Klucze SSH.
• Root login wyłączony.
• Logowanie hasłem wyłączone.
• UFW skonfigurowany.
• AppArmor aktywny.
• Zbędne usługi wyłączone.
• Automatyczne aktualizacje.
• Kopie zapasowe zaplanowane.
• Otwarte porty zweryfikowane.
• IPv6 sprawdzone.
• Dokumentacja zmian zapisana.

Nie wszystkie serwery wymagają identycznej konfiguracji. Serwer WWW, host Docker, maszyna KVM czy domowy Raspberry Pi będą miały inne potrzeby. Jednak te pierwsze kroki tworzą solidny fundament, na którym później można bezpiecznie budować kolejne usługi.

To właśnie dlatego hardening nie powinien być traktowany jako jednorazowa operacja wykonywana po wdrożeniu. Powinien stać się częścią procesu instalacji – czymś, co robimy automatycznie, zanim serwer zacznie wykonywać swoje właściwe zadanie.

Polecane wpisy

Specyfika ataków na urządzenia IoT: Jakie zagrożenia wiążą się z Internetem Rzeczy?

Specyfika ataków na urządzenia IoT: Jakie zagrożenia wiążą się z Internetem Rzeczy? Internet Rzeczy (IoT) stał się jedną z najbardziej Czytaj dalej

Spyware i Adware: Złośliwe oprogramowanie szpiegujące i wyświetlające niechciane reklamy

🕵️‍♂️ Spyware i Adware: Złośliwe oprogramowanie szpiegujące i wyświetlające niechciane reklamy W świecie cyberzagrożeń coraz częściej spotykamy dwa typy złośliwego Czytaj dalej