Пріоритети безпеки виділеного сервера протягом перших 30 хвилин
Щойно наданий bare-metal сервер може мати публічну IPv4-адресу, стандартні облікові дані root і всі мережеві порти, доступні ззовні, якщо ви не зміните конфігурацію. Перша мета — не розгортання застосунків: це створення безпечного шляху адміністрування без випадкового блокування власного доступу.
Виконуйте ці дії з довіреної робочої станції у приватній мережі. Залишайте відкритим доступ через консоль провайдера, IPMI, KVM-over-IP або rescue-консоль, доки не перевірите другий SSH-сеанс з новим обліковим записом і SSH-ключем. Доступ до консолі є методом відновлення, якщо зміна SSH, брандмауера або мережевої конфігурації завершиться невдачею.
Передумови
- Виділений сервер під керуванням Ubuntu Server 24.04 LTS із доступом root або sudo.
- Робоча станція зі встановленим OpenSSH. Linux і macOS містять його; користувачі Windows можуть використовувати PowerShell або Windows Terminal.
- IPv4-адреса вашого сервера та, якщо налаштовано, IPv6-адреса.
- Статична публічна IP-адреса для вашого офісного або домашнього з’єднання, якщо ви плануєте обмежити SSH за IP-адресою джерела.
- Щонайменше 4 фізичні ядра CPU, 16 ГБ RAM і 480 ГБ SSD або NVMe-сховища для невеликого виробничого навантаження виділеного сервера. Самі інструменти безпеки використовують мало ресурсів, але виробничі служби, журнали, знімки та резервні копії — ні.
Не відкривайте базу даних, Docker API, Redis, Elasticsearch або панель керування для публічного інтернету під час початкового налаштування. Прив’язуйте приватні служби до 127.0.0.1, приватної VLAN або VPN-інтерфейсу, якщо публічний доступ не є явно необхідним.
Виробниче планування ресурсів після базового налаштування безпеки
Засоби контролю безпеки мають залишати достатньо місця для системних журналів, оновлень пакетів, резервних копій, агентів моніторингу та служб, які розміщуватиме сервер. Наведене нижче планування передбачає вебзастосунки Linux, бази даних, ігрові сервери, самостійно розміщені застосунки або CI-ранери із зашифрованими віддаленими резервними копіями.
Корисна початкова конфігурація — 4 ядра, 16 ГБ RAM і 480 ГБ SSD для невеликої публічної служби; використовуйте більше пам’яті та дзеркальне NVMe-сховище зі зростанням обсягу запитів і активності бази даних.
| Публічні HTTP-запити за секунду | CPU | RAM | Диск | Щомісячний трафік |
|---|---|---|---|---|
| До 50 запитів/с | 4 фізичні ядра | 16 ГБ | 480 ГБ SSD або NVMe | 5 ТБ |
| 50–300 запитів/с | 8 фізичних ядер | 32 ГБ | 960 ГБ NVMe | 10 ТБ |
| 300–1 000 запитів/с | 16 фізичних ядер | 64 ГБ | 2 × 1,92 ТБ NVMe у RAID 1 | 20 ТБ |
Для одного легкого VPN, вузла моніторингу або маловідвідуваного самостійно розміщеного застосунку VPS із 2 vCPU, 4 ГБ RAM і 80 ГБ NVMe може бути економічнішим. Обирайте виділене обладнання для постійного I/O навантаження бази даних, CPU-навантаження ігрового сервера, великих CI/CD-збірок, високого трафіку або робочих навантажень, що потребують сильнішої апаратної ізоляції.
Крок 1: Зафіксуйте поточний стан і оновіть операційну систему
Увійдіть, використовуючи облікові дані, надані під час доставки. Перш ніж щось змінювати, підтвердьте дистрибутив, активні мережеві слухачі, структуру дисків і поточну історію входів.
ssh root@SERVER_IP
hostnamectl
uname -a
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
ss -tulpn
last -a | head
apt update && apt -y full-upgrade
rebootПовторно підключіться після перезавантаження та підтвердьте, що запущено очікуване ядро:
ssh root@SERVER_IP
uname -r
apt autoremove -y
apt install -y sudo curl ca-certificates vim ufw fail2ban unattended-upgrades auditdПерегляньте неочікувані порти прослуховування. Свіжий сервер Ubuntu зазвичай має лише SSH на TCP-порту 22. Якщо ss -tulpn показує служби, які ви не встановлювали, визначте їхні пакети перед видаленням. Не зупиняйте агент віддаленого керування, наданий вашим провайдером, без підтвердження, що доступ до консолі залишається доступним.
Крок 2: Створіть іменований обліковий запис адміністратора та встановіть SSH-ключ
Для щоденного адміністрування слід використовувати іменований обліковий запис із sudo, а не прямий вхід root. На робочій станції створіть ключ Ed25519, якщо ще не маєте його. Захистіть приватний ключ парольною фразою.
ssh-keygen -t ed25519 -a 100 -C "admin@workstation"
ssh-copy-id root@SERVER_IPДруга команда тимчасово копіює ваш публічний ключ до root. На сервері створіть обліковий запис адміністратора та скопіюйте до нього авторизований ключ:
adduser admin
usermod -aG sudo admin
install -d -m 700 -o admin -g admin /home/admin/.ssh
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown admin:admin /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keysВідкрийте другий термінал і перевірте новий обліковий запис, перш ніж змінювати налаштування SSH:
ssh admin@SERVER_IP
sudo -v
sudo whoamiОстання команда повинна вивести root. Залиште початковий сеанс root відкритим до завершення Кроку 4. Для команд надайте кожному адміністратору окремий обліковий запис і ключ. Не використовуйте спільний приватний ключ і не зберігайте ключі в чатах, заявках або незашифрованих файлах паролів.
Крок 3: Налаштуйте брандмауер із забороною за замовчуванням
UFW контролює вхідний трафік на хості. Спочатку дозвольте SSH, а потім — лише служби, які навмисно є публічними. Якщо ваш офіс має фіксовану публічну IP-адресу, обмеження SSH цією адресою зменшує спроби підбору паролів та експлуатації вразливостей.
ufw default deny incoming
ufw default allow outgoing
ufw allow from YOUR_PUBLIC_IP to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verboseЗамініть YOUR_PUBLIC_IP реальною адресою, наприклад 203.0.113.10. Якщо ваша IP-адреса часто змінюється, тимчасово використовуйте ufw allow 22/tcp, а потім обмежте SSH через VPN або стабільну офісну адресу. Не вмикайте UFW, доки не існує правила дозволу SSH.
Для застосунків, яким потрібен UDP, додайте лише необхідний порт. Наприклад, сервер WireGuard зазвичай потребує:
ufw allow 51820/udp
ufw status numberedНе використовуйте широкі правила, як-от ufw allow 1:65535/tcp. Зворотному проксі зазвичай потрібні TCP 80 і 443; PostgreSQL, MySQL, Redis і Docker не слід відкривати публічно для звичайних розгортань.
Крок 4: Посильте SSH без втрати доступу
Вимикайте вхід root і автентифікацію паролем лише після підтвердження, що новий адміністратор може увійти за допомогою ключа. Використовуйте drop-in файл SSH замість безпосереднього редагування конфігурації постачальника.
cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers admin
EOF
sshd -t
systemctl reload sshПеревірка sshd -t не повинна повертати виводу. Відкрийте третій термінал і перевірте як очікуваний успіх, так і очікувану невдачу:
ssh -o PreferredAuthentications=publickey admin@SERVER_IP
ssh -o PreferredAuthentications=password admin@SERVER_IPКоманда на основі ключа має підключитися; команда лише з паролем має завершитися невдачею. Якщо вхід за ключем не працює, використайте все ще відкритий сеанс root або консоль провайдера, видаліть drop-in файл, виконайте systemctl reload ssh і перегляньте journalctl -u ssh -n 50.
Крок 5: Увімкніть захист від брутфорсу та автоматичні оновлення безпеки
Fail2ban читає журнали автентифікації та блокує повторні невдалі спроби. Це доповнення до SSH-ключів та обмежень брандмауера, а не їхня заміна.
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 4
findtime = 10m
bantime = 1h
EOF
systemctl enable --now fail2ban
fail2ban-client status sshdУвімкніть автоматичні оновлення безпеки, щоб відомі вразливості отримували виправлення між вікнами обслуговування:
dpkg-reconfigure -plow unattended-upgrades
systemctl enable --now apt-daily-upgrade.timer
systemctl status apt-daily-upgrade.timer --no-pagerРегулярно перевіряйте необхідність перезавантаження. Оновлення ядра та низькорівневих бібліотек можуть потребувати запланованого перезавантаження, навіть якщо пакети успішно встановилися:
test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "No reboot required"Крок 6: Налаштуйте журнали, синхронізацію часу та базовий аудит
Точний час уможливлює розслідування інцидентів. Ubuntu типово використовує systemd-timesyncd; перевірте синхронізацію та увімкніть аудит для змін привілейованих файлів і команд.
timedatectl status
systemctl enable --now auditd
systemctl status auditd --no-pager
auditctl -lПеревіряйте активність автентифікації за допомогою цих команд:
journalctl -u ssh --since "30 minutes ago"
last -a | head -20
sudo ausearch -m USER_LOGIN --start todayДля виробничих серверів надсилайте журнали до окремої системи за допомогою syslog, платформи моніторингу або служби керування інформацією та подіями безпеки. Зловмисник, який отримує root-доступ, може змінити локальні журнали; зберігання поза сервером підвищує якість доказів.
Крок 7: Перевірте стан сховища та створіть план резервного копіювання
RAID покращує доступність після відмови диска, але не є резервною копією. Видалена база даних, скомпрометований застосунок або подія ransomware можуть негайно реплікуватися на дзеркало. Зберігайте зашифровані копії поза сервером і перевіряйте відновлення.
apt install -y smartmontools
smartctl -a /dev/sda | less
systemctl enable --now smartd
mkdir -p /root/backup-test
tar -czf /root/backup-test/etc-$(date +%F).tar.gz /etcНазви пристроїв відрізняються. Використовуйте lsblk для визначення дисків; NVMe-пристрої зазвичай відображаються як /dev/nvme0n1. Для даних застосунків створюйте резервні копії баз даних за допомогою нативних інструментів бази даних, таких як pg_dump або mariadb-dump, а потім надсилайте зашифровані резервні копії до незалежного місця зберігання. Зберігайте кілька точок відновлення та виконуйте тестове відновлення щонайменше щокварталу.
Крок 8: Перевірте відкриту поверхню атаки ззовні
Після налаштування брандмауера виконайте сканування портів із робочої станції. Результат має показувати лише порти, які ви навмисно дозволили.
nmap -Pn -sV -p 22,80,443,51820 SERVER_IP
curl -I http://SERVER_IP
sudo ufw status numbered
sudo fail2ban-client status sshdЯкщо вебсервер не встановлено, порти 80 і 443 можуть відображатися як відфільтровані, оскільки UFW дозволяє трафік, але ніщо не прослуховує ці порти. Це прийнятно під час налаштування; видаліть правила UFW, доки не буде розгорнуто зворотний проксі або вебслужбу. Після встановлення Docker, ігрового сервера, поштового стеку або панелі керування знову перевірте відкриті слухачі за допомогою ss -tulpn, оскільки кожен із них може додати нові точки доступу.
Усунення поширених проблем перших 30 хвилин
SSH перестав працювати після посилення захисту
Використайте доступ до консолі провайдера, перевірте конфігурацію за допомогою sshd -t і перегляньте journalctl -u ssh -n 100. Підтвердьте, що ваш публічний ключ міститься в /home/admin/.ssh/authorized_keys, режим каталогу — 700, а режим файлу — 600. Видаліть AllowUsers admin, якщо ваше фактичне ім’я для входу відрізняється.
UFW заблокував ваше підключення
З консолі виконайте ufw status numbered. Додайте правильне правило за допомогою ufw allow 22/tcp або правильної IP-адреси джерела, а потім видаліть помилкове правило за допомогою ufw delete NUMBER. Зберігайте доступ до консолі для кожної віддаленої зміни брандмауера.
Fail2ban заблокував IP-адресу вашого офісу
Перевірте jail і зніміть блокування за допомогою:
fail2ban-client status sshd
fail2ban-client set sshd unbanip YOUR_PUBLIC_IPДодавайте довірені IP-адреси адміністрування до списку ignoreip лише якщо вони стабільні та контрольовані. Не додавайте до білого списку широкі діапазони ISP.
Автоматичні оновлення не застосувалися
Перевірте активність таймера за допомогою systemctl list-timers apt-daily-upgrade.timer і перегляньте /var/log/unattended-upgrades/unattended-upgrades.log. Підтвердьте DNS та вихідне HTTPS-з’єднання, перш ніж припускати проблему з пакетом.
Робота з безпекою після перших 30 хвилин
Початкова база — це лише початок. Додайте зворотний проксі з актуальними налаштуваннями TLS, розгорніть моніторинг використання диска, навантаження, пам’яті, строку дії сертифікатів і збоїв резервного копіювання, відокремте виробниче середовище від розробки, оперативно оновлюйте застосунки та періодично перевіряйте користувачів, SSH-ключі, правила брандмауера й запущені контейнери. Для поштових серверів, платіжних систем, медичних даних або регульованих робочих навантажень документуйте засоби контролю доступу та розгляньте незалежну перевірку безпеки.