Контрольний список для посилення захисту сервера Linux

Встановлення Linux за замовчуванням не є безпечним. Неправильні конфігурації, такі як відкритий кореневий SSH-доступ, слабкі брандмауери та невиправлене програмне забезпечення є причиною більшості порушень. Нові сервери піддаються автоматизованому скануванню протягом декількох хвилин після виходу в мережу, тому зміцнення безпеки повинно відбуватися в першу чергу.

Цей контрольний список охоплює основні кроки: блокування SSH, налаштування брандмауерів, виправлення, посилення дозволів на файли, увімкнення обов'язкового контролю доступу та налаштування журналів аудиту.

Блокування SSH

SSH - це ваша основна точка доступу і перше, що досліджують зловмисники. Конфіг за замовчуванням (пароль auth, логін root, порт 22) - це саме те, що шукають автоматичні сканери.

Згенеруйте пару ключів Ed25519, яка забезпечує кращу безпеку та продуктивність, ніж RSA:

ssh-keygen -t ed25519

Після того, як вхід на основі ключів запрацює, оновіть файл /etc/ssh/sshd_config:

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

Змініть порт за замовчуванням з 22 на щось менш очевидне. Це не зупинить цілеспрямованого зловмисника, але значно зменшить шум від автоматичного сканування.

Завжди тестуйте зміни з другого терміналу перед закриттям поточного сеансу. Виконайте sudo sshd -t для перевірки синтаксичних помилок, а потім systemctl перезавантажте sshd, щоб застосувати зміни без розриву активних з'єднань.

Додайте двофакторну автентифікацію

2FA означає, що зловмиснику потрібен як ваш SSH-ключ, так і фізичний доступ до вашого пристрою. Встановіть модуль Google Authenticator PAM:

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

Запустіть google-authenticator для кожного користувача, щоб згенерувати секретний ключ і коди відновлення. Зберігайте коди відновлення в автономному режимі.

Додайте цей рядок до /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Потім оновіть файл /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Під час тестування не закривайте активний сеанс. Коди TOTP залежать від точного системного часу, тому переконайтеся, що NTP працює.

Налаштування брандмауерів та Fail2Ban

Запустіть брандмауер на основі хоста, навіть якщо ваш сервер знаходиться за мережевим брандмауером. Принцип простий: за замовчуванням забороняйте весь вхідний трафік, а потім дозволяйте тільки те, що вам потрібно.

Для Ubuntu/Debian (UFW):

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

Для 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

Посильте захист мережевого стеку ядра, додавши ці параметри до /etc/sysctl.conf:

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

Встановіть Fail2Ban

Fail2Ban відстежує спроби входу і забороняє IP-адреси після повторних невдалих спроб. Створіть файл /etc/fail2ban/jail.local (не редагуйте jail.conf безпосередньо, оновлення перезапишуть його) і налаштуйте його на заборону IP-адрес на одну годину після трьох невдалих спроб протягом 10 хвилин. Встановіть правильний бекенд для вашого брандмауера(banaction = ufw або banaction = nftables).

Аудит служб і видалення застарілих протоколів

Перевірте, що прослуховується за допомогою ss -tlnp і що виконується за допомогою systemctl list-units --type=service --state=running. Вимкніть все, що вам не потрібно: Bluetooth, CUPS, avahi-daemon, rpcbind.

Видаліть застарілі протоколи, які передають дані у відкритому вигляді:

У Debian/Ubuntu: sudo apt-get --purge видалити xinetd nis tftpd telnetd rsh-server. На системах на основі RHEL: yum erase xinetd ypserv tftp-server telnet-server rsh-server. Перевірте видалення за допомогою ss -tulpn.

Виправлення та автоматизація оновлень

Оновлення системи - це найшвидший спосіб закрити відомі прогалини в безпеці. Запускайте оновлення одразу після створення резервної копії:

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

Потім автоматизуйте виправлення безпеки. У Debian/Ubuntu встановіть автоматичні оновлення і налаштуйте їх на застосування лише виправлень безпеки. У RHEL/Rocky встановіть dnf-automatic і встановіть upgrade_type = security у файлі /etc/dnf/automatic.conf.

Налаштуйте сповіщення електронною поштою про результати оновлення. Вимкніть автоматичне перезавантаження на робочих серверах(Automatic-Reboot = false), щоб перезавантаження відбувалося під час планового обслуговування. Для середовищ з високим часом безвідмовної роботи розгляньте можливість встановлення виправлень в режимі реального часу за допомогою Canonical Livepatch (Ubuntu) або kpatch (RHEL).

Зміцнюйте файлові системи та дозволи

В першу чергу перевірте двійкові файли SUID та SGID. Ці файли запускаються з підвищеними привілеями і є першочерговими цілями для зловмисників:

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

Посильте права доступу до критично важливих файлів: /etc/shadow має бути 600, /etc/passwd має бути 644, /etc/ssh/sshd_config має бути 600. Встановіть глобальну маску 027 у файлі /etc/profile, щоб запобігти відкриттю нових файлів для читання з усього світу.

Знайдіть і виправте доступні для запису файли за допомогою find / -xdev -type f -perm -0002 -ls. Для каталогів, які мають залишатися доступними для запису (наприклад, /tmp), застосуйте липкий біт: chmod 1777 /tmp.

Налаштування параметрів безпечного монтування

Відредагуйте /etc/fstab, щоб обмежити можливості критично важливих розділів:

Перевірте зміни за допомогою mount -o remount перед перезавантаженням, щоб уникнути проблем із завантаженням.

Увімкніть обов'язковий контроль доступу

SELinux та AppArmor додають обмеження на рівні ядра на те, що можуть робити процеси. Використовуйте те, що постачається з вашим дистрибутивом: SELinux для RHEL/CentOS/Fedora, AppArmor для Ubuntu/Debian/SUSE. Перемикання між ними може спричинити проблеми сумісності.

SELinux: Перевірте стан за допомогою getenforce. Запустіть систему у дозвільному режимі(setenforce 0) принаймні на два тижні, щоб зафіксувати поведінку робочого навантаження, не порушуючи нічого. Відстежуйте порушення за допомогою ausearch -m avc -ts recent. Використовуйте audit2why для діагностики блоків і audit2allow -M [ім'я_модуля ] для створення модулів політики. Після очищення журналів переключіться на примусове застосування за допомогою setenforce 1, а потім зробіть його постійним у /etc/selinux/config.

AppArmor: Перевірте активні профілі зі статусом aa. Встановіть apparmor-utils для команд керування. Запустіть профілі у режимі скарг за допомогою aa-complain, а потім перейдіть у режим примусового виконання за допомогою aa-enforce, коли будете впевнені. Використовуйте aa-genprof для створення профілів для користувацьких програм.

Налаштуйте реєстрацію та моніторинг аудиту

Без реєстрації інциденти не залишають жодних слідів. Встановіть auditd:

sudo apt-get install auditd audispd-plugins

Додайте спостереження за файловою системою для критично важливих файлів:

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

Відстежуйте виконання всіх команд кореневого рівня:

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

Завантажте правила за допомогою augenrules --load і додайте -e 2 в кінці файлу правил, щоб зробити конфігурацію захищеною від несанкціонованого доступу (зміни вимагають перезавантаження).

Моніторинг цілісності файлів за допомогою AIDE

AIDE виявляє несанкціоновані зміни файлів, порівнюючи поточний стан із заздалегідь відомим базовим. Встановіть його, ініціалізуйте базу даних за допомогою aideinit і перемістіть отриманий файл до /var/lib/aide/aide.db.gz. Налаштуйте щоденне завдання cron для запуску aide --check і надсилання результатів адміністраторам електронною поштою.

Централізуйте журнали

Локальні журнали марні, якщо зловмисник з root-доступом видаляє їх. Передавайте журнали на віддалений сервер в режимі реального часу за допомогою rsyslog з шифруванням TLS. Додайте в /etc/rsyslog.conf:

*.* @@remote-host:514

Встановіть LogLevel VERBOSE у вашому налаштуванні SSH, щоб журнали містили відбитки ключів для кожного успішного входу. Для виробничих середовищ, які керують декількома серверами, такі інструменти, як Wazuh або OSSEC, забезпечують виявлення вторгнень на основі хостів з централізованим аналізом журналів.

Постійне обслуговування

Зміцнення - це не одноразове завдання. Конфігурації змінюються, з'являються нові вразливості, а зміни персоналу залишають після себе осиротілі облікові записи.

Щотижня: Переглядайте журнали Fail2Ban, перевіряйте наявність невдалих оновлень, перевіряйте резервні копії.

Щомісяця: Аудит облікових записів і дозволів користувачів, перегляд запущених служб, повне сканування за допомогою Lynis або OpenSCAP.

Щоквартально: Ротація облікових даних, оновлення правил брандмауера, тестування аварійного відновлення.

Використовуйте інструменти інфраструктури як коду, такі як Ansible з ролями зміцнення dev-sec.io, щоб забезпечити узгодженість конфігурацій у вашому парку обладнання та запобігти дрейфу між аудитами.

Виділені сервери FDC надають вам повний root-доступ і повний контроль над стеком безпеки. Ознайомтеся з варіантами виділених серверів, щоб побудувати платформу, де ви контролюєте кожен рівень.