Контрольний список безпеки виділеного сервера на перші 30 хвилин
Щойно доставлений bare-metal сервер часто має публічну IPv4-адресу, початковий пароль root і служби, які ще не були перевірені. Розглядайте перший вхід як подію підготовки: зафіксуйте обладнання, оновіть операційну систему, створіть адміністратора без прав root, установіть SSH-ключі, обмежте мережевий доступ і підтвердьте, що доступ для відновлення працює.
У цьому посібнику використовується Ubuntu Server 22.04 або 24.04 LTS. Команди виконуються від імені root, якщо не зазначено інше. Залишайте вихідний SSH-сеанс відкритим, доки не протестуєте другий сеанс із новим обліковим записом адміністратора. Якщо ваш провайдер надає IPMI, iDRAC, iLO або іншу позасмугову консоль, підтвердьте, що вона доступна лише через VPN, IP-адреси зі списку дозволених або окрему мережу керування.
Передумови та мінімальні вимоги до сервера
- Виділений сервер із встановленою Ubuntu Server 22.04 або 24.04 LTS.
- Щонайменше 4 фізичні ядра CPU, 16 ГБ RAM і 240 ГБ NVMe SSD для невеликого продуктивного сервера, що працює з вебзастосунком, стеком моніторингу або кількома самостійно розміщеними службами.
- Локальний комп’ютер з SSH-клієнтом, наприклад OpenSSH у Linux, macOS або Windows PowerShell.
- IPv4-адреса вашого сервера, початкові облікові дані root і дані доступу до консолі або віддаленого керування.
- Стабільна статична публічна IP-адреса для вашої робочої станції адміністрування, якщо ви плануєте обмежити SSH за IP-адресою джерела.
VPS із 2 vCPU, 4 ГБ RAM і 80 ГБ NVMe достатньо для однієї служби з низьким трафіком або VPN-ендпойнта. Обирайте виділений або bare-metal хостинг для постійної активності баз даних, runner-ів збірки, ігрових серверів, стримінгу, віртуалізації або навантажень, що потребують передбачуваних CPU, дискового I/O та ізоляції орендарів.
Оберіть обладнання для навантаження, яке ви захищатимете
Засоби безпеки використовують відносно небагато CPU, але зберігання логів, резервні копії, моніторинг, бази даних і трафік застосунків визначають продуктивну ємність. Наведені нижче показники припускають Linux, сховище NVMe, щоденні резервні копії в окреме сховище та стандартний трафік вебзастосунків.
Висновок: почніть із 4 ядер, 16 ГБ RAM і 240 ГБ NVMe для приблизно 50 активних користувачів, а потім збільшуйте RAM і ємність NVMe до того, як навантаження бази даних або CI досягне постійної конкуренції за диск.
| Одночасні активні користувачі застосунку | vCPU / ядра CPU | RAM | Диск | Щомісячна пропускна здатність |
|---|---|---|---|---|
| До 50 користувачів; невеликий вебсайт, VPN, моніторинг або 1-2 самостійно розміщені застосунки | 4 фізичні ядра | 16 ГБ | 240 ГБ NVMe | 2 ТБ |
| 50-500 користувачів; вебзастосунок із PostgreSQL, поштовим relay або невеликим CI/CD runner-ом | 8 фізичних ядер | 32 ГБ | 480 ГБ NVMe | 5 ТБ |
| 500-3 000 користувачів; платформа на базі бази даних, ігрові вузли, джерело стримінгу або кілька runner-ів збірки | 16 фізичних ядер | 64 ГБ | 2 x 960 ГБ NVMe у RAID 1 | 10 ТБ |
1. Зафіксуйте стан сервера та застосуйте оновлення
Увійдіть, використовуючи облікові дані доставки, і перевірте хост перед внесенням змін. Збережіть вивід у менеджері паролів або документації інфраструктури. Перевірте операційну систему, структуру дисків, активні слухачі та доступні оновлення безпеки.
hostnamectl
uname -a
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
free -h
ss -tulpn
apt update
apt full-upgrade -y
reboot
Після перезавантаження повторно підключіться та переконайтеся, що хост працює з очікуваним ядром:
uptime
uname -r
apt autoremove --purge -y
Не встановлюйте пакети застосунків до оновлення системи. Новий образ може містити виправлення для OpenSSH, ядра Linux, OpenSSL, sudo або інших відкритих компонентів.
2. Створіть іменованого адміністратора та встановіть SSH-ключ
Щоденне адміністрування слід виконувати через іменований обліковий запис із привілеями sudo, а не через обліковий запис root. На локальному комп’ютері створіть SSH-ключ Ed25519, якщо його ще немає:
ssh-keygen -t ed25519 -a 100 -C "[email protected]"
На локальному комп’ютері скопіюйте відкритий ключ до нового облікового запису. Замініть adminuser і SERVER_IP.
ssh-copy-id adminuser@SERVER_IP
Якщо обліковий запис ще не існує, спочатку створіть його на сервері:
adduser adminuser
usermod -aG sudo adminuser
install -d -m 700 -o adminuser -g adminuser /home/adminuser/.ssh
nano /home/adminuser/.ssh/authorized_keys
chmod 600 /home/adminuser/.ssh/authorized_keys
chown adminuser:adminuser /home/adminuser/.ssh/authorized_keys
Вставте один повний рядок відкритого ключа до authorized_keys. Відкрийте другий термінал і протестуйте новий вхід перед зміною налаштувань SSH:
ssh adminuser@SERVER_IP
sudo -v
whoami
Остання команда має повернути root після sudo -i або ім’я вашого облікового запису без нього. Не продовжуйте, якщо вхід за ключем не працює.
3. Посильте захист OpenSSH без втрати доступу
Створіть окрему конфігурацію SSH drop-in замість редагування файлу постачальника. Це спрощує перевірку майбутніх оновлень пакетів. Приклад залишає SSH на порту 22; зміна порту може зменшити шум у логах, але не замінює автентифікацію за ключем і обмеження брандмауера.
cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers adminuser
EOF
sshd -t
systemctl reload ssh
Залиште поточний сеанс відкритим. У новому терміналі переконайтеся, що ключ працює, а входи root і за паролем відхиляються:
ssh -o PreferredAuthentications=publickey adminuser@SERVER_IP
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no adminuser@SERVER_IP
Перевірка пароля має завершитися невдачею. Якщо це не так, перегляньте ефективну конфігурацію SSH за допомогою:
sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers'
4. Налаштуйте брандмауер із забороною за замовчуванням
UFW підходить для одного виділеного сервера. Спочатку дозвольте SSH, потім відкрийте лише порти, які використовують служби, що ви дійсно плануєте запускати. Для типового вебсервера потрібні TCP 80 і 443; PostgreSQL на порту 5432 зазвичай має залишатися приватним і не повинен бути відкритий в інтернет.
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose
Для посиленого захисту площини керування дозвольте SSH лише з вашої фіксованої офісної адреси або адреси виходу VPN. Додайте це правило перед видаленням широкого правила SSH і протестуйте його з цієї дозволеної мережі.
ufw allow from 203.0.113.25 to any port 22 proto tcp
ufw delete allow 22/tcp
ufw status numbered
Порти, опубліковані Docker, можуть обходити очікувану поведінку UFW, оскільки Docker додає правила nftables або iptables. Уникайте публікації портів баз даних, Redis або адміністрування за допомогою -p 0.0.0.0:PORT:PORT, якщо публічний доступ не потрібен. Прив’язуйте приватні служби до 127.0.0.1 або внутрішньої мережі та перевіряйте доступність за допомогою ss -tulpn.
5. Додайте захист від brute-force атак і автоматичні оновлення безпеки
SSH-ключі усувають підбір паролів, але fail2ban усе одно зменшує повторні спроби автентифікації та захищає майбутні служби, наприклад базову автентифікацію Nginx. Установіть fail2ban і ввімкніть його SSH jail:
apt install -y fail2ban unattended-upgrades
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF
systemctl enable --now fail2ban
fail2ban-client status sshd
Увімкніть автоматичні оновлення безпеки, а потім перегляньте створену політику. Автоматичні оновлення корисні для більшості серверів одного призначення, але організації з формальними вікнами змін натомість мають застосовувати виправлення через свій процес керування конфігурацією.
dpkg-reconfigure --priority=low unattended-upgrades
systemctl status unattended-upgrades --no-pager
6. Захистіть обліковий запис провайдера, консоль і DNS
Посилення захисту операційної системи не може захистити від зловмисника, який може скинути сервер, підключити його диски, змінити зворотний DNS або отримати доступ до віддаленої консолі. Використовуйте унікальний пароль і MFA на основі апаратного ключа або застосунку-автентифікатора для панелі керування хостингом. Видаліть облікові записи колишніх працівників, обмежте дозволи на виставлення рахунків і скидання сервера та зберігайте коди відновлення в зашифрованому менеджері паролів.
Для IPMI, iDRAC або iLO негайно змініть наданий пароль керування, установлюйте оновлення мікропрограми постачальника під час вікна обслуговування та не відкривайте його вебінтерфейс публічно. Якщо приватна VLAN керування недоступна, отримуйте доступ через WireGuard VPN або список дозволених IP-адрес джерел.
7. Налаштуйте логування, синхронізацію часу та резервні копії
Точний час робить можливими SSH, TLS, реагування на інциденти та кореляцію логів. Підтвердьте синхронізацію NTP і постійне зберігання журналу:
timedatectl set-ntp true
timedatectl status
mkdir -p /var/log/journal
systemctl restart systemd-journald
journalctl --disk-usage
Резервні копії мають бути відокремлені від сервера, резервне копіювання якого виконується. Дзеркало RAID 1 захищає від відмови одного диска; воно не захищає від видалення, програм-вимагачів, скомпрометованого root-доступу або помилки на рівні облікового запису. Щонайменше щодня створюйте резервні копії даних застосунків і конфігураційних файлів у зашифроване позасерверне сховище.
apt install -y restic
export RESTIC_REPOSITORY='s3:https://OBJECT_STORAGE_ENDPOINT/server-backup'
export RESTIC_PASSWORD='replace-with-a-long-unique-secret'
restic init
restic backup /etc /home /var/www
restic snapshots
Розміщуйте облікові дані репозиторію у файлі середовища, доступному для читання root, або менеджері секретів, а не в історії оболонки. Протестуйте відновлення протягом першого тижня:
mkdir -p /root/restore-test
restic restore latest --target /root/restore-test
ls -la /root/restore-test/etc
8. Перевірте фінальний стан безпеки
Виконайте ці перевірки перед розгортанням застосунків. Вони виявляють поширені помилки, такі як відкритий порт бази даних, неактивний брандмауер, збій служби fail2ban або конфігурація SSH, яка все ще дозволяє root-доступ.
ufw status verbose
ss -tulpn
systemctl --failed
fail2ban-client status sshd
sshd -T | grep -E 'permitrootlogin|passwordauthentication'
last -a | head
journalctl -p 3 -xb --no-pager
Із зовнішньої мережі скануйте лише власну адресу, щоб підтвердити, що відкриті очікувані порти:
nmap -Pn -sV -p 22,80,443,5432 SERVER_IP
Вебсервер зазвичай має показувати лише порти 22, 80 і 443. Якщо порт 5432, 3306, 6379, 2375 або порт панелі керування з’являється неочікувано, зупиніть відповідну службу або обмежте її localhost чи приватною мережею.
Усунення поширених проблем першого дня
SSH перестав працювати після посилення захисту
Використайте консоль провайдера або ваш наявний відкритий SSH-сеанс. Перевірте синтаксис за допомогою sshd -t, перегляньте завантажені налаштування через sshd -T і підтвердьте, що відкритий ключ існує в /home/adminuser/.ssh/authorized_keys. Виправте власника за допомогою chown -R adminuser:adminuser /home/adminuser/.ssh і дозволи за допомогою chmod 700 /home/adminuser/.ssh && chmod 600 /home/adminuser/.ssh/authorized_keys.
UFW заблокував доступ для адміністрування
Використайте позасмуговий доступ до консолі та виконайте ufw status numbered. Додайте правильне правило для конкретного джерела, наприклад ufw allow from 203.0.113.25 to any port 22 proto tcp. Уникайте постійного вимкнення брандмауера; виправте правило та протестуйте друге SSH-з’єднання.
Fail2ban заблокував IP-адресу вашого офісу
Перевірте jail за допомогою fail2ban-client status sshd і зніміть блокування через fail2ban-client set sshd unbanip 203.0.113.25. Дослідіть причину невдалого входу перед додаванням вашої адреси до списку ігнорування.
Дисковий простір заповнюється після ввімкнення логів або резервних копій
Перегляньте використання за допомогою df -h, journalctl --disk-usage і du -xhd1 /var | sort -h. Налаштуйте зберігання журналів, ротацію логів застосунків і не зберігайте архіви резервних копій лише на продуктивному сервері.