Lista kontrolna wzmacniania zabezpieczeń serwerów Linux

Domyślna instalacja systemu Linux nie jest instalacją bezpieczną. Błędy konfiguracji, takie jak otwarty dostęp SSH do katalogu root, słabe zapory sieciowe i niezałatane oprogramowanie, są przyczyną większości naruszeń bezpieczeństwa. Nowe serwery są poddawane automatycznym skanom w ciągu kilku minut od podłączenia do sieci, dlatego wzmocnienie zabezpieczeń powinno nastąpić przed wykonaniem jakichkolwiek innych czynności.

Niniejsza lista kontrolna obejmuje podstawowe kroki: zablokowanie SSH, konfigurację zapór sieciowych, instalację poprawek, zaostrzenie uprawnień do plików, włączenie obowiązkowej kontroli dostępu oraz skonfigurowanie rejestrowania audytowego.

Zabezpiecz SSH

SSH to główny punkt dostępu i pierwsza rzecz, którą sprawdzają atakujący. Domyślna konfiguracja (uwierzytelnianie hasłem, logowanie jako root, port 22) jest dokładnie tym, czego szukają automatyczne skanery.

Wygeneruj parę kluczy Ed25519, która zapewnia lepsze bezpieczeństwo i wydajność niż RSA:

ssh-keygen -t ed25519

Gdy logowanie oparte na kluczu zacznie działać, zaktualizuj /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers yourname
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Zmień domyślny port z 22 na mniej oczywisty. Nie powstrzyma to zdeterminowanego atakującego, ale znacznie ograniczy szum generowany przez automatyczne skanery.

Zawsze testuj zmiany z drugiego terminala przed zamknięciem bieżącej sesji. Uruchom sudo sshd -t , aby sprawdzić, czy nie ma błędów składniowych, a następnie systemctl reload sshd , aby zastosować zmiany bez przerywania aktywnych połączeń.

Dodaj uwierzytelnianie dwuskładnikowe

Uwierzytelnianie dwuskładnikowe (2FA) oznacza, że osoba atakująca potrzebuje zarówno klucza SSH, jak i fizycznego dostępu do urządzenia. Zainstaluj moduł PAM Google Authenticator:

sudo apt install libpam-google-authenticator   # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Fedora

Uruchom google-authenticator dla każdego użytkownika, aby wygenerować klucz tajny i kody odzyskiwania. Przechowuj kody odzyskiwania w trybie offline.

Dodaj tę linię do /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Następnie zaktualizuj /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Podczas testowania utrzymuj otwartą aktywną sesję. Kody TOTP zależą od dokładnego czasu systemowego, więc upewnij się, że działa NTP.

Konfiguracja zapór sieciowych i Fail2Ban

Uruchom zaporę sieciową opartą na hoście, nawet jeśli Twój serwer znajduje się za zaporą sieciową. Zasada jest prosta: domyślnie blokuj cały ruch przychodzący, a następnie zezwalaj tylko na to, co jest potrzebne.

Dla Ubuntu/Debian (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw limit ssh
ufw enable

Dla RHEL/Rocky/AlmaLinux (Firewalld):

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Zabezpiecz stos sieciowy jądra, dodając następujące elementy do pliku /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1

Zainstaluj Fail2Ban

Fail2Ban monitoruje próby logowania i blokuje adresy IP po wielokrotnych niepowodzeniach. Utwórz /etc/fail2ban/jail.local (nie edytuj jail.conf bezpośrednio, aktualizacje go nadpiszą) i skonfiguruj go tak, aby blokował adresy IP na godzinę po trzech nieudanych próbach w ciągu 10 minut. Ustaw odpowiedni backend dla swojej zapory (banaction = ufw lub banaction = nftables).

Usługi audytowe i usuwanie starszych protokołów

Sprawdź, co nasłuchuje za pomocą ss -tlnp i co jest uruchomione za pomocą systemctl list-units --type=service --state=running. Wyłącz wszystko, czego nie potrzebujesz: Bluetooth, CUPS, avahi-daemon, rpcbind.

Usuń przestarzałe protokoły, które przesyłają dane w postaci zwykłego tekstu:

W systemach Debian/Ubuntu: sudo apt-get --purge remove xinetd nis tftpd telnetd rsh-server. W systemach opartych na RHEL: yum erase xinetd ypserv tftp-server telnet-server rsh-server. Sprawdź usunięcie za pomocą ss -tulpn.

Aktualizacje i automatyzacja

Aktualizacja systemu to najszybszy sposób na wyeliminowanie znanych luk w zabezpieczeniach. Uruchom aktualizacje natychmiast po wdrożeniu:

apt update && apt upgrade -y      # Debian/Ubuntu
dnf update -y                      # RHEL/Rocky

Następnie zautomatyzuj instalację poprawek bezpieczeństwa. W systemie Debian/Ubuntu zainstaluj unattended-upgrades i skonfiguruj go tak, aby stosował wyłącznie poprawki bezpieczeństwa. W systemie RHEL/Rocky zainstaluj dnf-automatic i ustaw upgrade_type = security w /etc/dnf/automatic.conf.

Skonfiguruj powiadomienia e-mailowe o wynikach aktualizacji. Wyłącz automatyczne restartowanie na serwerach produkcyjnych (Automatic-Reboot = false), aby restart odbywał się podczas zaplanowanych okien serwisowych. W przypadku środowisk wymagających wysokiej dostępności rozważ stosowanie poprawek na żywo za pomocą Canonical Livepatch (Ubuntu) lub kpatch (RHEL).

Zabezpiecz systemy plików i uprawnienia

Najpierw sprawdź pliki binarne SUID i SGID. Pliki te działają z podwyższonymi uprawnieniami i są głównym celem ataków:

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -ls

Zacieśnij uprawnienia do plików krytycznych: /etc/shadow powinny 600, /etc/passwd powinny być 644, /etc/ssh/sshd_config powinno być 600. Ustaw globalny umask wartość 027 w /etc/profile , aby zapobiec temu, by nowe pliki były dostępne do odczytu dla wszystkich.

Znajdź i napraw pliki z prawami zapisu dla wszystkich za pomocą find / -xdev -type f -perm -0002 -ls. W przypadku katalogów, które muszą pozostać dostępne do zapisu dla wszystkich (takich jak /tmp), zastosuj bit sticky: chmod 1777 /tmp.

Opcje bezpiecznego montowania

Edytuj /etc/fstab , aby ograniczyć działania na partycjach krytycznych:

Przetestuj zmiany za pomocą mount -o remount przed ponownym uruchomieniem, aby uniknąć problemów z uruchamianiem systemu.

Włącz obowiązkowe kontrole dostępu

SELinux i AppArmor nakładają ograniczenia na poziomie jądra dotyczące tego, co mogą robić procesy. Użyj tego, co jest w Twojej dystrybucji: SELinux dla RHEL/CentOS/Fedora, AppArmor dla Ubuntu/Debian/SUSE. Przełączanie się między nimi powoduje problemy z kompatybilnością.

SELinux: Sprawdź status za pomocą getenforce. Rozpocznij w trybie permissive (setenforce 0) przez co najmniej dwa tygodnie, aby zarejestrować zachowanie obciążenia bez powodowania żadnych awarii. Monitoruj naruszenia za pomocą ausearch -m avc -ts recent. Użyj audit2why do diagnozowania blokad oraz audit2allow -M [module_name] do tworzenia modułów zasad. Gdy logi będą czyste, przełącz się na tryb egzekwowania za pomocą setenforce 1, a następnie ustaw je na stałe w /etc/selinux/config.

AppArmor: Sprawdź aktywne profile za pomocą aa-status. Zainstaluj apparmor-utils , aby uzyskać dostęp do poleceń zarządzania. Uruchom profile w trybie ostrzegania za pomocą aa-complain, a następnie przejdź do trybu egzekwowania, gdy aa-enforce , gdy już będziesz pewny. Użyj aa-genprof do tworzenia profili dla niestandardowych aplikacji.

Skonfiguruj rejestrowanie audytowe i monitorowanie

Bez rejestrowania zdarzeń nie pozostawiają one żadnego śladu. Zainstaluj auditd:

sudo apt-get install auditd audispd-plugins

Dodaj monitorowanie systemu plików dla plików krytycznych:

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity

Śledź wszystkie polecenia wykonywane na poziomie administratora:

-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

Załaduj reguły za pomocą augenrules --load i dodaj -e 2 na końcu pliku reguł, aby zabezpieczyć konfigurację przed manipulacją (zmiany wymagają ponownego uruchomienia).

Monitorowanie integralności plików za pomocą AIDE

AIDE wykrywa nieautoryzowane zmiany w plikach, porównując aktualny stan z bazą znanych, poprawnych stanów. Zainstaluj go, zainicjuj bazę danych za pomocą aideiniti przenieś wynikowy plik do /var/lib/aide/aide.db.gz. Skonfiguruj codzienne zadanie cron, aby uruchamiało aide --check i wysyłania wyników pocztą elektroniczną do administratorów.

Centralizacja logów

Lokalne logi są bezużyteczne, jeśli atakujący z uprawnieniami roota je usunie. Przekazuj logi na serwer zdalny w czasie rzeczywistym, używając rsyslog z szyfrowaniem TLS. Dodaj do /etc/rsyslog.conf:

*.* @@remote-host:514

Set LogLevel VERBOSE w konfiguracji SSH, aby logi zawierały odciski kluczy dla każdego pomyślnego logowania. W środowiskach produkcyjnych zarządzających wieloma serwerami narzędzia takie jak Wazuh czy OSSEC zapewniają oparte na hostach wykrywanie włamań wraz ze scentralizowaną analizą logów

Bieżąca konserwacja

Wzmocnienie zabezpieczeń nie jest zadaniem jednorazowym. Konfiguracje ulegają zmianom, pojawiają się nowe luki w zabezpieczeniach, a zmiany kadrowe powodują pozostawienie nieaktywnych kont.

Co tydzień: przeglądaj logi Fail2Ban, sprawdzaj nieudane aktualizacje, weryfikuj kopie zapasowe.

Co miesiąc: audyt kont użytkowników i uprawnień, przegląd uruchomionych usług, pełne skanowanie za pomocą Lynis lub OpenSCAP.

Co kwartał: Zmieniaj dane uwierzytelniające, aktualizuj reguły zapory sieciowej, testuj odzyskiwanie po awarii.

Korzystaj z narzędzi typu „infrastruktura jako kod”, takich jak Ansible z rolami wzmacniania bezpieczeństwa dev-sec.io, aby egzekwować spójne konfiguracje w całej flocie i zapobiegać rozbieżnościom między audytami.

Serwery dedykowane FDC zapewniają pełny dostęp root i całkowitą kontrolę nad stosem zabezpieczeń. Zapoznaj się z opcjami serwerów dedykowanych, aby zbudować platformę, na której kontrolujesz każdą warstwę.