Перелік заходів із зміцнення безпеки серверів Linux

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

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

Блокування SSH

SSH — це ваша основна точка доступу і перше, що перевіряють зловмисники. Стандартна конфігурація (аутентифікація за паролем, вхід як 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 reload sshd для застосування змін без розриву активних з'єднань.

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

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

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 remove 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 встановіть unattended-upgrades та налаштуйте його так, щоб застосовувалися лише патчі безпеки. У RHEL/Rocky встановіть dnf-automatic та встановіть upgrade_type = security в /etc/dnf/automatic.conf.

Налаштуйте сповіщення електронною поштою про результати оновлення. Вимкніть автоматичні перезавантаження на виробничих серверах (Automatic-Reboot = false), щоб перезавантаження відбувалися під час запланованих вікон технічного обслуговування. Для середовищ з високим часом безперебійної роботи розгляньте можливість використання live patching за допомогою 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. Встановіть глобальний umask на 027 в /etc/profile , щоб запобігти тому, щоб нові файли були доступні для читання всім.

Знайдіть і виправте файли, доступні для запису всім, за допомогою find / -xdev -type f -perm -0002 -ls. Для каталогів, які повинні залишатися доступними для запису всім (наприклад /tmp), застосуйте біт sticky: 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 [module_name] для створення модулів політики. Коли журнали очистяться, перейдіть до режиму примусу за допомогою setenforce 1, а потім зробіть це постійним у /etc/selinux/config.

AppArmor: Перевірте активні профілі за допомогою aa-status. Встановіть 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

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

-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 та надсилання результатів адміністраторам електронною поштою.

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

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

*.* @@remote-host:514

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

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

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

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

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

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

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

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