Встановлення Ubuntu Server 24.04 LTS: мінімальна конфігурація, яка справді безпечна

February 19, 2026 • February 19, 2026 • Читання: 7 хв • Views: 1

Було корисно?

Вам потрібна компактна інсталяція Ubuntu Server, бо зайвий софт — це ризик. Вам також потрібна безпека, бо інтернет — це хаос, а ваш сервер — найближча купа проблем.

Підступ у тому, щоб думати, що «мінімальний» автоматично означає «безпечний». Крихітна система зі недбалою конфігурацією SSH, слабкими оновленнями і макетом диска, який ви випадково створили, — це все ще система, яку можуть захопити, або яка розбудить вас о 03:17, бо /var заповнився і потягнув за собою journald.

Що має означати «мінімальний» у продакшні

«Мінімальний» — не «найменший ISO». Це набір навмисних обмежень:

Маленька поверхня атаки: менше демонов, що слухають мережу, менше парсерів, менше залежностей.
Передбачувані оновлення: оновлення безпеки — автоматичні; функціональні оновлення — за планом.
Аудитований стан: ви можете пояснити, навіщо потрібен пакет і що відкрило порт.
Відновлюване сховище: макет диска витримає сплески логів, дампи ядра і людські помилки.
Операційна ергономіка: journald працює, синхронізація часу працює, DNS працює, і ви можете діагностувати проблеми без гадань.

«Безпека» — це не галочка. Це позиція: розумні налаштування за замовчуванням, жорсткий доступ ззовні, принцип найменших привілеїв, своєчасне патчування і достатня спостережуваність, щоб виявляти проблеми раніше за клієнтів.

Одна з моїх улюблених істин про продакшн — парафразована ідея, часто приписувана SRE-спільноті: надія — не стратегія; надійність приходить від інженерних зворотних зв’язків.

Жарт №1: Безпека — як користування зубною ниткою: усі погоджуються, що це корисно, а більшість роблять це лише після того, як починає кровоточити.

Факти та історичний контекст, які стануть у пригоді о 2:00

Короткий, конкретний контекст допомагає приймати кращі рішення під тиском:

Каденція LTS Ubuntu: LTS-релізи виходять кожні два роки; операційно такий ритм став корпоративним стандартом, бо вписується в бюджети й контроль змін.
systemd не «переміг» миттєво: він замінив мішанину init-скриптів єдиною моделлю (units, залежності, watchdog). Така уніфікація — чому сучасна діагностика Linux така швидка, якщо ви вивчите інструменти.
За замовчуванням OpenSSH посилився з часом: старі криптографії були прибрані, це не «вічне депрекування». Якщо ваш застарілий клієнт ламається, це підказка, а не злий намір Ubuntu.
UFW існує, бо людям потрібні поручні: iptables/nftables потужні, але проста модель політики запобігає «випадковому» відкриттю Redis усьому світу.
journald замінив розкидані логи: структуровані метадані (unit, PID, boot ID) — ось чому «що сталося після останнього перезавантаження?» тепер — одна команда.
ext4 навмисно став «нудним»: він заробив репутацію тим, що відмовляє передбачувано. Багато команд вибирають його не тому, що це захопливо, а тому, що він не дивує.
LUKS став масовим спочатку на ноутбуках, потім на серверах: шифрування диска перейшло з «параноїдального» в «стандарт відповідності», коли закони про повідомлення про витоки й снапшоти у хмарі зробили дані в спокої реальністю.
TPM-підтримка секретів — не лише для десктопів: сучасні сервери все частіше очікують апаратних коренів довіри; інструменти Ubuntu це відображають.
Unattended security updates стали нормою після епох хробаків: операційна культура змінилася, коли «Patch Tuesday» перетворився на «патч зараз або відбудову пізніше».

Рішення під час інсталяції, які важко скасувати

1) Виберіть правильний ISO та режим інсталяції

Використовуйте офіційний інсталятор Ubuntu Server 24.04 LTS. Якщо інсталюєте на фізичне залізо — віддавайте перевагу стандартному серверному ISO. Якщо розгортаєте в хмарі — ваш «інсталятор» здебільшого — це cloud-init плюс вибір образу.

Мінімальна конфігурація означає: без GUI, без «допоміжних» ролей сервера під час інсталяції, без зайвих snap-пакетів, якщо ви не знаєте навіщо.

2) Мережа: спочатку DHCP, потім статична (якщо ви не маршрутизатор)

Якщо сервер не є частиною вашої мережевої інфраструктури, почніть з DHCP, щоб завершити інсталяцію й отримати віддалений доступ. Потім встановіть статичний ліз у DHCP або перейдіть на статичну netplan-конфігурацію, коли дізнаєтеся ім’я інтерфейсу й правильні DNS.

Режим відмови: ви вгадали статичну IP, помилилися при введенні шлюзу, і тепер єдиний шлях управління — фізичний доступ. Це не «безпечно», це просто самотньо.

3) Користувачі: створіть одного адміністратора, без спільних акаунтів

Створіть одного початкового користувача з sudo. Не дозволяйте прямий root SSH-доступ. Поведінка з «адмінськими» спільними акаунтами — це майбутня провалена аудиторська перевірка.

4) SSH: лише ключі, і зробіть це рано

Якщо інсталятор пропонує імпортувати SSH-ключі (наприклад, з хостингу ідентичності), зробіть це. Якщо ні — додайте свій публічний ключ одразу після першого запуску. Логін по паролю через SSH — зайвий ризик, який вам не потрібен.

5) Оновлення: автоматичні оновлення безпеки, перезавантаження — свідомо

Увімкніть автоматичні оновлення безпеки. Ви не доводите свою стійкість, вручну погоджуючи кожну виправлення OpenSSL. Ви просто створюєте накопичення ризику.

6) Сховище: визначте межі ураження

Ваші рішення щодо сховища визначають, як машина впаде. Один кореневий розділ — просто, доки логи не підскочать, контейнери не розростуться або хтось не вкине бекап у /var/tmp.

Для мінімального, але безпечного підходу прагніть до:

Чистої EFI-конфігурації (на сучасному обладнанні).
Окремого /boot лише якщо це необхідно (наприклад, деякі налаштування з зашифрованим коренем).
Зашифрованого кореневого розділу, якщо модель загроз включає вкрадені диски, виведені з обігу накопичувачі, віддалених операторів або вимоги відповідності.
Окремого простору для /var або принаймні здорового збереження логів. Якщо ви запускаєте контейнери, розглядайте /var/lib як зону для зростання.

Макет сховища: нудні вибори, менше простоїв

Будьмо відвертими: сховище — це місце, де «мінімальний» найчастіше стає «крихким». Ваш CPU пробачить; диск — ні.

Параметри монтування, що зменшують збитки

Деякі опції монтування — дешеві виграші:

nodev на розділах, які не повинні містити файли пристроїв (часто /home, /var/tmp).
nosuid там, де не хочете працювати setuid-бінаріям (часто /tmp, /var/tmp).
noexec може допомогти на /tmp, але будьте обережні: це може зламати інсталятори й інструменти. Використовуйте навмисно.

Це само по собі не «робить вас безпечними». Це зменшує радіус ураження в поганий день.

Базові післяінсталяційні налаштування: акаунти, SSH, брандмауер, оновлення

Пакети: встановлюйте менше, видаляйте більше

Почніть з того, що дає образ сервера. Додавайте лише те, що потрібно роботі. Якщо потрібен інструмент для одноразового порятунку — встановіть, використайте і подумайте про видалення після. Продакшн-сервер — не ваш ноутбук.

Твердість SSH: автентифікація ключами, мінімальна поверхня, сильні налаштування за замовчуванням

Цільовий стан:

Аутентифікація на основі ключів
Без root-login через SSH
Обмежені користувачі або групи, яким дозволено SSH
Розумні часи простою з відключенням
Логування, що корисне без зайвого шуму

Брандмауер: за замовчуванням — заборонити вхідні, дозволяйте лише потрібне

Якщо це сервер, він не повинен приймати вхідний трафік, якщо ви явно цього не плануєте. Ось сенс брандмауера.

Автоматичні оновлення безпеки

Увімкніть unattended upgrades для патчування безпеки. Потім вирішіть, як поводитися з перезавантаженнями. Для багатьох флітів: автоматичні оновлення безпеки плюс заплановані вікна перезавантажень — золота середина.

Синхронізація часу: бо логи без часу — фанфікшн

systemd-timesyncd (або chrony, якщо віддаєте йому перевагу) гарантує, що ваші TLS, логи й часові ланцюжки інцидентів не перетворяться на сміття.

Жарт №2: Нічого не старіє на вас швидше, ніж налагодження «виглядних» збоїв, що насправді були спричинені дрейфом часу.

Практичні завдання (команди, виводи, рішення)

Нижче — реальні завдання, які ви виконаєте на свіжій інсталяції Ubuntu Server 24.04. Кожне включає: команду, типовий вивід і наступне рішення. Виконуйте їх від імені адміністратора з sudo, коли треба.

Завдання 1: Підтвердити, що ви дійсно встановили

cr0x@server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble

Що це означає: Ви на правильному LTS-релізі і маєте кодову назву. Ніяких гадань «я думав, що встановив 24.04».

Рішення: Якщо це не 24.04 LTS — зупиніться і виправте pipeline образів, перш ніж привертати жорсткі налаштування не на ту версію.

Завдання 2: Перевірити ядро та режим завантаження (UEFI чи legacy)

cr0x@server:~$ uname -r
6.8.0-31-generic

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Що це означає: Рядок ядра підтверджує, що ви запускаєте. Наявність UEFI важлива для розділення диска і поведінки завантажувача.

Рішення: Якщо ви очікували UEFI, а отримали legacy — виправте налаштування прошивки зараз. Змішані середовища спричинюють дивні відновлення завантаження пізніше.

Завдання 3: Побачити диски, розділи та файлові системи чітко

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
NAME        SIZE TYPE FSTYPE      MOUNTPOINTS MODEL
nvme0n1   476.9G disk                       Samsung SSD 980
├─nvme0n1p1  512M part vfat        /boot/efi
├─nvme0n1p2    1G part ext4        /boot
└─nvme0n1p3 475.4G part crypto_LUKS

cr0x@server:~$ sudo cryptsetup status luks-root
/dev/mapper/luks-root is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/nvme0n1p3
  sector size:  512
  offset:  32768 sectors
  size:    997638144 sectors
  mode:    read/write

Що це означає: Ви бачите реальну карту пристроїв. LUKS2 активний — шифрування працює.

Рішення: Якщо шифрування було обов’язковим, а ви не бачите crypto_LUKS — ви не в відповідності. Перевстановіть або мігруйте коректно; не відкладайте.

Завдання 4: Перевірити використання файлових систем перед несподіванками

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root ext4    40G  3.2G   35G   9% /
/dev/nvme0n1p2 ext4  1007M  220M  720M  24% /boot
/dev/nvme0n1p1 vfat   511M  6.1M  505M   2% /boot/efi
tmpfs          tmpfs  3.1G     0  3.1G   0% /run/user/1000

Що це означає: Ви перевіряєте, що root не маленький і що /boot має місце для оновлень ядра.

Рішення: Якщо в /boot менше ~300–400 MiB вільного, ви рано чи пізно провалите оновлення ядра. Виправте розміри розділів або свідомо очистіть старі ядра.

Завдання 5: Підтвердити, що слухає на мережі

cr0x@server:~$ sudo ss -tulpen
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      4096   0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=1020,fd=3)) uid:0 ino:27360 sk:3 cgroup:/system.slice/ssh.service

Що це означає: Лише SSH слухає. Це чиста базова лінія.

Рішення: Якщо бачите небажані прослуховування (БД, вебсервер, RPC) — видаліть/відключіть їх або обґрунтуйте. «Я не знав, що воно запущене» — це не захист.

Завдання 6: Встановити базові правила брандмауера (UFW)

cr0x@server:~$ sudo ufw status verbose
Status: inactive

cr0x@server:~$ sudo ufw default deny incoming
Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)

cr0x@server:~$ sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

cr0x@server:~$ sudo ufw allow 22/tcp
Rule added
Rule added (v6)

cr0x@server:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

Що це означає: Ви заблокували вхідний трафік лише для SSH.

Рішення: Перед увімкненням UFW віддалено переконайтеся, що SSH дозволено й у вас є консольний доступ, якщо щось піде не так. Операційне правило: ніколи не відсікайте себе від машини, до якої немає фізичного доступу.

Завдання 7: Загартування SSH-конфігурації і безпечна перевірка

cr0x@server:~$ sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

cr0x@server:~$ sudoedit /etc/ssh/sshd_config

Приклад мінімальних рядків для налаштування (підкоригуйте імена користувачів/груп):

cr0x@server:~$ sudo grep -nE '^(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication|AllowUsers|AllowGroups|X11Forwarding|ClientAliveInterval|ClientAliveCountMax)' /etc/ssh/sshd_config
33:PermitRootLogin no
57:PasswordAuthentication no
58:KbdInteractiveAuthentication no
89:X11Forwarding no
101:ClientAliveInterval 300
102:ClientAliveCountMax 2

cr0x@server:~$ sudo sshd -t

cr0x@server:~$ sudo systemctl reload ssh

Що це означає: Порожній вивід від sshd -t — це успіх. reload застосовує зміни без обриву існуючих сесій.

Рішення: Якщо sshd -t виводить помилки — не перезавантажуйте. Виправте конфіг і тільки тоді reload. Синтаксичні помилки — класична самосаботаж.

Завдання 8: Перевірити методи автентифікації SSH у логах

cr0x@server:~$ sudo journalctl -u ssh -n 20 --no-pager
Aug 01 10:12:44 server sshd[1442]: Accepted publickey for cr0x from 10.0.0.50 port 50192 ssh2: ED25519 SHA256:Qm...
Aug 01 10:13:02 server sshd[1461]: Connection closed by authenticating user ubuntu 10.0.0.51 port 55322 [preauth]

Що це означає: Ви бачите успішні логіни за ключами. Також помітите підозрілі спроби або несподівані імена користувачів.

Рішення: Якщо бачите прийняття по паролю — ваша SSH-конфігурація не застосована або ви редагуєте не той файл. Виправте негайно.

Завдання 9: Увімкнути unattended-upgrades і перевірити поведінку

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:2 http://security.ubuntu.com/ubuntu noble-security InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

cr0x@server:~$ sudo apt install -y unattended-upgrades
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  unattended-upgrades
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

cr0x@server:~$ sudo systemctl status unattended-upgrades --no-pager
● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/usr/lib/systemd/system/unattended-upgrades.service; enabled)
     Active: inactive (dead)

Що це означає: Сервіс виконується по таймерам і у хуках вимикання; «inactive» може бути нормальним станом.

Рішення: Переконайтеся, що таймер увімкнений, і підтвердіть, що обрані лише security-репозиторії, якщо ви хочете мінімальних змін.

Завдання 10: Перевірити apt-таймери і останній запуск

cr0x@server:~$ systemctl list-timers --all | grep -E 'apt|unattended'
Fri 2026-02-06 06:12:21 UTC  10h left   Thu 2026-02-05 06:13:02 UTC  13h ago  apt-daily.timer             apt-daily.service
Fri 2026-02-06 06:45:10 UTC  10h left   Thu 2026-02-05 06:45:22 UTC  13h ago  apt-daily-upgrade.timer     apt-daily-upgrade.service

cr0x@server:~$ sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
2026-02-05 06:45:23,121 INFO Starting unattended upgrades script
2026-02-05 06:45:23,210 INFO No packages found that can be upgraded unattended

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

Рішення: Якщо таймери відсутні — можливо, ви на тонкому образі або таймери відключені політикою. Виправте це усвідомлено, а не випадково.

Завдання 11: Підтвердити стан синхронізації часу

cr0x@server:~$ timedatectl
               Local time: Thu 2026-02-05 20:10:17 UTC
           Universal time: Thu 2026-02-05 20:10:17 UTC
                 RTC time: Thu 2026-02-05 20:10:17
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Годинник синхронізований і NTP активний. UTC — розумний серверний дефолт.

Рішення: Якщо синхронізація — «ні», виправте час перед налагодженням чогось іншого. TLS і кластерні системи погано поводяться зі зсувом часу.

Завдання 12: Швидко перевірити DNS і маршрутизацію (мережева санітарія)

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp1s0           UP             10.0.10.25/24 fe80::a00:27ff:fe4e:66a1/64

cr0x@server:~$ ip r
default via 10.0.10.1 dev enp1s0
10.0.10.0/24 dev enp1s0 proto kernel scope link src 10.0.10.25

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.10.2
       DNS Servers: 10.0.10.2 10.0.10.3

Що це означає: Інтерфейс активний, маршрут за замовчуванням існує, DNS-сервери налаштовані.

Рішення: Якщо DNS невірний — виправляйте netplan або опції DHCP; не «відвертайте» проблему хаками в /etc/hosts, якщо це не свідоме відображення сервісу.

Завдання 13: Підтвердити, які пакети встановлені (виявити випадковий блоут)

cr0x@server:~$ apt list --installed | head -n 15
Listing... Done
adduser/noble,now 3.137ubuntu1 all [installed]
apt/noble-updates,now 2.7.14 amd64 [installed]
base-files/noble,now 13ubuntu10 amd64 [installed]
bash/noble,now 5.2.21-2ubuntu4 amd64 [installed]
bsdutils/noble,now 1:2.39.3-9ubuntu6 amd64 [installed]

Що це означає: Ви швидко бачите всесвіт пакетів, які доведеться підтримувати.

Рішення: Якщо бачите ролі сервера, які не планували (база даних, поштовий стек) — видаліть їх або перебудуйте. Приховані демони стають «таємними портами».

Завдання 14: Переконатися, що AppArmor активний

cr0x@server:~$ sudo aa-status
apparmor module is loaded.
45 profiles are loaded.
45 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes are unconfined but have a profile defined.

Що це означає: Мандатний контроль доступу присутній і застосовує профілі для відомих сервісів.

Рішення: Якщо AppArmor відключений — ви обираєте менш жорстку базу. Увімкніть його, якщо немає доведених несумісностей і плану пом’якшення.

Завдання 15: Перевірити привілеї користувачів і прибрати ризикові дефолти

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

cr0x@server:~$ sudo -l
Matching Defaults entries for cr0x on server:
    env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User cr0x may run the following commands on server:
    (ALL : ALL) ALL

Що це означає: Ваш адмін-користувач може ескалювати, а політика sudo — дефолтна.

Рішення: Для корпоративного середовища віддавайте перевагу принципу найменших привілеїв через політики sudoers. Для одноцільового сервера обмежуйте адміністраторів і робіть їх трасованими.

Завдання 16: Виявити проблеми зі здоров’ям диска раніше, ніж вони стануть «випадковими крахами»

cr0x@server:~$ sudo apt install -y smartmontools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  smartmontools

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | head -n 20
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-31-generic] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 980
Serial Number:                      S64...
Firmware Version:                   2B4QFXO7
NVMe Version:                       1.4
Total NVM Capacity:                 500,107,862,016 [500 GB]

Що це означає: Ви можете підтвердити пристрій, прошивку та згодом перевіряти лічильники помилок.

Рішення: Якщо smart-дані показують помилки медіа або критичні попередження — замініть диск. Не сперечайтеся з фізикою.

План швидкої діагностики (швидко знайти вузьке місце)

Це playbook для ситуації «сервер повільний», який працює в реальних операціях. Мета — визначити обмежуючий ресурс за хвилини, а не збирати дрібні деталі.

Спочатку: переконайтеся, що це не мережа або DNS

Перевірте маршрути й лінк: ip -br a, ip r
Перевірте DNS: resolvectl status
Перевірте стек черги і прослуховування сокетів: ss -s, ss -tulpen

Якщо DNS зламаний — усе виглядає повільним. Встановлення пакетів, TLS-руки, виклики API — всюди біль.

Друге: знайдіть гарячий процес і на що він чекає

Загальний огляд: top або htop (якщо встановлено)
Системний тиск: uptime (load average), vmstat 1
IO на процес: pidstat -d 1 (з sysstat), якщо потрібно

Шукайте: CPU завантажений обчисленням, або високий load при низькому використанні CPU (часто IO wait), тиск пам’яті (swap), або «стадо» процесів.

Третє: визначте, чи сховище — вузьке місце

IO wait і блок-пристрої: iostat -xz 1 (sysstat)
Файлові системи заповнені: df -hT
Помилки диска: dmesg -T | tail, journalctl -k -n 200

Класичний сигнал: високий load average, CPU вільний, а часи відповіді жахливі. Часто це латентність сховища.

Четверте: переконайтеся, що пам’ять не стискається непомітно

Огляд пам’яті: free -h
Доказ OOM: journalctl -k | grep -i oom

Якщо ядро вбиває процеси — розглядайте це як проблему ємності або витоку, а не «випадкові» крахи.

П’яте: перевірте systemd на збійні юніти та флаппінг

Невдалі сервіси: systemctl --failed
Останні помилки: journalctl -p err..alert -b

Флаппінг-демони можуть створювати навантаження, шторм логів, виснаження портів і хибні симптоми. systemd підкаже, якщо запитати прямо.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Я увімкнув UFW і опинився закритим»

Симптоми: SSH обривається, повторне підключення неможливе, консоль працює.

Корінь проблеми: Брандмауер увімкнули, не дозволивши SSH, або дозволили неправильний інтерфейс/порт.

Виправлення: З консолі: sudo ufw disable. Потім застосуйте у правильному порядку: allow SSH спочатку, підтвердьте, потім enable. В середовищах з нестандартними портами SSH — явно дозволіть цей порт і перевірте з ss -tulpen перед увімкненням.

2) «Оновлення ядра падають через /boot повний»

Симптоми: apt upgrade помилки, DKMS збої, накопичення старих пакетів ядра.

Корінь проблеми: Розділ /boot занадто малий або старі ядра не очищаються.

Виправлення: Обережно видаліть старі ядра: dpkg -l 'linux-image-*', потім purge старі версії (не поточне ядро). У довгостроковій перспективі: виділіть більший /boot або уникайте окремого /boot, якщо це не потрібно.

3) «SSH-ключі не працюють; все одно пропонує пароль»

Симптоми: Аутентифікація по ключу не пройшла, сервер просить пароль, логи показують Failed publickey.

Корінь проблеми: Неправильні права на ~/.ssh або authorized_keys, неправильний користувач, або редаговано неактивний include в конфігу sshd.

Виправлення: Переконайтеся, що ~/.ssh має права 700, authorized_keys — 600, та належить користувачу. Перевірте конфіг з sshd -T і sshd -t. Потім reload ssh.

4) «Apt оновлення випадково зависають»

Симптоми: apt update зависає, особливо на DNS запитах або доступі до mirror-ів.

Корінь проблеми: Зламаний DNS, captive proxy або проблеми з IPv6 маршрутом.

Виправлення: Перевірте resolvectl status і маршрути. Тестуйте резолюцію з getent hosts archive.ubuntu.com. Якщо IPv6 не працює — виправте мережу правильно, а не відключайте IPv6 наосліп (відключення може зламати сучасні середовища).

5) «Диск заповнюється за ніч і машина ніби привид»

Симптоми: Сервіси не стартують, SSH повільний, логи зупиняються, journald рапортує проблеми.

Корінь проблеми: Зростання /var (логи, шари контейнерів, дампи) на єдиному кореневому файловому просторі без квот або відокремлення.

Виправлення: Знайдіть винуватців (du -xh --max-depth=1 /var). Додайте політику збереження логів, наступного разу робіть окремий /var, і розгляньте тонке налаштування зарезервованого місця файлової системи. Якщо ви запускаєте контейнери — тримайте /var/lib як окрему домену ємності.

6) «Коробка повільна, але CPU вільний»

Симптоми: High load average, CPU idle значний, часи відповіді погані.

Корінь проблеми: Латентність сховища, IO wait, або процес, застряглий на IO (наприклад, синхронний fsync від БД).

Виправлення: Використайте iostat -xz 1 і перевірте використання диска та await. Перевірте помилки в journalctl -k. Якщо це VM — перевірте хостове сховище та «шумних сусідів» також.

7) «Unattended upgrades зламали сервіс»

Симптоми: Сервіс впав після нічних оновлень; проблеми сумісності.

Корінь проблеми: Ви дозволили більше, ніж оновлення безпеки (або оновлення безпеки внесло зміну поведінки).

Виправлення: Зафіксуйте unattended-upgrades лише на security-пакетах і стаджуйте оновлення на канарковому середовищі. Якщо сервіс дуже чутливий — керуйте цим пакетом за явним контролем змін, але решту тримайте запатченими.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через помилкове припущення

Компанія мала «мінімальний образ Ubuntu». Він швидко завантажувався, запускав один застосунок і проходив скан безпеки. Всі потім похвалилися і перейшли далі — сигнал, що скоро з’явиться наступна сторінка.

Команда розгорнула нову партію серверів і увімкнула повне шифрування диска. Вони припустили, що макет інсталятора збереже root у безпеці. Вони не відокремили /var, не встановили обмежень journald і не перевірили припущення щодо обсягу логів. Застосунок мав баг, який підвищував вербosity логування під час транзитної помилки. Ви можете здогадатися про подальше.

За кілька годин диски заповнилися. Коли / став повним, відбулася каскада: journald не міг записувати, сервіси не могли створювати тимчасові файли, пакетні менеджери не могли працювати, навіть SSH логіни стали нестабільними, бо автентифікація записує на диск теж. On-call інженер пережив класичний сценарій — намагався виправити систему, яка не могла зафіксувати свою поломку.

Постмортем не був про баг у застосунку; вони трапляються. Справжнє неправильне припущення було «мінімальний образ = мінімальний ризик». Їм потрібен був макет, що ізолює зростання (окремий /var) і політика логування, яка трактує диск як обмежений ресурс, а не пропозицію.

Виправлення було нудним: керівництво по партиціюванню, ліміти логів і переддеплойний тест, який навмисно спамить логи, щоб довести, що сервер залишається відновлюваним. Цей тест тепер — причина, чому їхній «мінімальний» образ дійсно заслуговує назву.

Міні-історія 2: Оптимізація, що обернулась проти

Група, орієнтована на продуктивність, вирішила, що «шифрування — це наклад». Вони прибрали LUKS з флотилії серверів на швидких NVMe. Вони виміряли бенчмарк, він трохи покращився. Слайд був переконливим. Так буває.

Через місяці робочий потік виведення обладнання на утилізацію відправив накопичувачі до зовнішнього переробника. Одна партія не була правильно витерта; це пропуск процесу, а не злочинний намір. Але наміри не важливі, коли диск з даними клієнтів покинув приміщення. Реакція на інцидент була жорсткою: юридичний відділ, відповідність, комунікації з клієнтами та такі наради, де кожне речення стає доказом.

Технічно, результат не був хакерським зломом. Це було гірше в іншому сенсі: це було запобіжне. Шифрування перетворило б подію на не-подію, за умови, що ключі були керовані правильно і не приклеєні до шасі.

Наслідки були не лише «втрата безпеки». Це була операційна тяганина. Довелося впроваджувати екстрену політику витирки, перевіряти процедури поводження з активами й ретрофітити шифрування в середовищі, яке вже було заповнене даними. Ретрофіт у масштабі завжди складніший, ніж зробити правильно під час інсталяції.

Урок засвоїли: оптимізуйте там, де це має значення і де можна довести безпеку. Якщо оптимізація дає +2% і створює прірву відповідності — це не оптимізація. Це майбутній інцидент з кращим маркетингом.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша організація мала нудну, але коректну політику: кожен серверний билд повинен пройти «listen test» і «patch test». Listen test — це просто: перерахувати всі слухаючі порти і пояснити кожен. Patch test — довести, що оновлення безпеки увімкнені і заплановані, і показати останній вдалий запуск.

Люди кидали очима. Здавалося нудною формальністю. Але це займало близько трьох хвилин при автоматизації — менше часу, ніж сварка через це.

Одного дня новий базовий образ випадково включив телеметричний агент, який відкрив локальний веб-інтерфейс, прив’язаний до 0.0.0.0. Ніхто не планував цього; він був запакований саме так. У багатьох середовищах це дійшло б до продакшну і чекало, поки сканер його знайде.

Listen test провалився одразу. Інженер вказав на ss -tulpen, ідентифікував процес і заблокував реліз. Агент видалили, образ перебудували і продовжили. Ніяких інцидентів. Ніяких заяв. Нічних патч-скрамів не було.

Оце й є тихе спасіння: нудна звичка, що ловить гострі проблеми. Найкращі відмови — ті, про які не треба писати звіт.

Чек-листи / покроковий план

Фаза 0: До запуску інсталятора (10 хвилин, що запобігають жалю)

Визначте: чи потрібне шифрування диска? Якщо так — сплануйте введення/відновлення ключів у вашому середовищі (консоль, віддалений KVM або інтеграція з TPM, якщо можливо).
Визначте: чи потрібен окремий /var (рекомендується для більшості серверів)? Якщо так — оцініть розмір на основі логів + даних застосунку + зростання контейнерів.
Визначте: як ви отримаєте доступ до сервера, якщо мережа впаде? IPMI/iDRAC/iLO, віртуальна консоль або фізичний доступ.
Підготуйте SSH-ключі для початкового адміністратора.
Запишіть: hostname, стратегія IP (DHCP/static), DNS-сервери, очікування NTP.

Фаза 1: Вибори інсталятора (тримайте мінімум, збережіть відновлюваність)

Встановіть Ubuntu Server 24.04 LTS (без GUI).
Створіть одного адміністратора (з включеним sudo).
Імпортуйте або додайте підтримку SSH-ключів під час інсталяції, якщо пропонується.
Виберіть сховище:
- Використовуйте LUKS, якщо потрібно.
- Віддавайте перевагу ext4, якщо у вас немає вже операційної моделі ZFS.
- Сильно розгляньте окремий /var для серверів з пишучим навантаженням.
Пропустіть додаткові ролі сервера, якщо це не спеціальне встановлення і ви точно не знаєте навіщо вони потрібні.

Фаза 2: Перший запуск — базова безпека

Оновіть списки пакетів: sudo apt update.
Встановіть автоматизацію безпеки: sudo apt install unattended-upgrades; підтвердіть таймери.
Загартуйте SSH: відключіть парольну автентифікацію, відключіть root-login, reload ssh, підтвердіть логін по ключах.
Увімкніть UFW з дефолтом deny inbound; дозволяйте лише потрібні порти.
Підтвердьте синхронізацію часу: timedatectl має показувати synchronized.
Підтвердьте слухачі: sudo ss -tulpen повинно бути саме те, що ви планували.
Зафіксуйте стан: збережіть виводи lsblk, df -hT, systemctl --failed.

Фаза 3: Загартування без самосаботажу

Застосуйте опції монтування для /tmp і /var/tmp обдумано. Тестуйте ваш софт; не ламайте інсталятори тихо.
Обмежте збереження journald, щоб логи не з’їдали диск: лімітуйте за розміром і часом відповідно до середовища.
Використовуйте systemd-hardening для юнітів ваших застосунків (NoNewPrivileges, ProtectSystem, PrivateTmp). Розгортайте поступово і тестуйте.
Визначте політику перезавантажень: заплановані вікна обслуговування або автоматичні перезавантаження при потребі. Будь-який варіант — явний.

Фаза 4: Оперативність (бо «безпечно» і «діагностовано» йдуть разом)

Налаштуйте базові моніторингові гачки: використання диска, здоров’я SMART/NVMe, невдалі systemd-юніти, статус оновлень.
Переконайтеся, що логи доступні віддалено (централізоване логування), якщо ви маєте більше одного сервера.
Проведіть drill: заповніть /var (у безпечному стенді), переконайтеся, що сервер відновлюваний і сповіщення працюють.

Поширені запитання

Чи справді мені потрібен брандмауер, якщо слухає лише SSH?

Так. «Лише SSH слухає» — це знімок стану, а не гарантія. Брандмауер — це страхувальна сітка для майбутніх встановлень пакетів, випадкових сервісів і людських помилок.

Чи завжди варто відключати парольну автентифікацію SSH?

Для серверів, доступних з інтернету: так, майже завжди. Для ізольованих лабораторних мереж: також рекомендовано. Якщо необхідно зберегти паролі (вимоги відповідності або спадщина) — вводьте MFA підтримуваним методом і обмежуйте швидкість. Але розумійте, що ви платите ризиком.

Чи варто змінювати порт SSH?

Це зменшить шум у логах, але не зупинить реальних нападників. Якщо робите це — заради чистоти логів, а не «безпеки». Справжня безпека — це ключі, контроль доступу і патчі.

Чи потрібен Fail2ban?

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

Чи варто ставити повне шифрування диска на серверах?

Так, коли модель загроз включає втрату дисків, віддалений доступ до них, ризик колокації, помилки виведення обладнання або снапшоти, що виходять з-під вашого контролю. Операційна вартість — керування ключами та розблокування на завантаженні. Заплануйте це; не імпровізуйте під час інциденту.

ext4 чи XFS для мінімальної безпечної конфігурації?

ext4 — консервативний дефолт і легкий для відновлення. XFS підходить для великих файлових систем і певних навантажень, але ext4 виграє у конкурсі «нудний і передбачуваний» для загальних серверів.

Як не дати логам заповнити диск?

Використовуйте два важелі: обмеження journald і logrotate (для традиційних логів). Також ізолюйте зростання: окремий /var або принаймні моніторинг. Якщо застосунок надто гучний — виправляйте логування в ньому.

Чи варто встановлювати купу інструментів для налагодження наперед?

Ні. Встановіть мінімальний базовий набір плюс те, що потрібно для вашої операційної моделі (часто: smartmontools, можливо sysstat). Усе інше можна встановити тимчасово. Кожен зайвий пакет — це ще код, який ви будете патчити вічно.

Які мінімальні «докази», які варто зберегти після інсталяції?

Щонайменше: версія ОС, макет диска, використання файлових систем, слухаючі порти, правила брандмауера, статус таймерів оновлень, стан синхронізації часу і невдалі systemd-юніти. Це доводить і безпеку, і оперативність.

Як зрозуміти, що моя система достатньо безпечна?

Поставте конкретні питання: Чи може хтось брутфорсом здолати SSH паролем? Чи обмежені вхідні порти? Чи оновлення безпеки автоматичні? Чи AppArmor у режимі enforce? Чи може заповнення диска вбити машину? Якщо ви можете відповісти на ці питання командами і конфігами — ви маєте реальну безпеку.

Наступні кроки, які варто виконати

Практичний завершальний список — те, що відокремлює «встановлено» від «готово до продакшну»:

Заблокуйте SSH і протестуйте з другої сесії перед тим, як відключитися.
Увімкніть UFW з дефолтом deny inbound і явними дозволами тільки потрібних портів.
Увімкніть unattended security updates і підтвердіть, що таймери виконувалися щонайменше раз.
Перевірте макет сховища за допомогою lsblk і df -hT; переконайтеся, що /boot і /var не піднесуть сюрприз.
Налаштуйте збереження journald на розумні межі відповідно до розміру диска і потреб логування.
Задокументуйте «listen list»: які порти відкриті і навіщо. Будь-який невідомий слухач — блокер релізу.
Прогонить playbook швидкої діагностики на здоровій системі, щоб знати, як виглядає «норма».
Вирішіть політику перезавантажень до першого критичного оновлення ядра, щоб не обговорювати це в найгірший момент.

Мінімалізм — це дисципліна. Безпека — це звичка. Ubuntu Server 24.04 LTS дає хороші примітиви — але керувати машиною доведеться вам.

Схожі статті

Windows Vista: реліз, що навчив боятися оновлень