Чекліст жорсткого захисту після перевстановлення: що закрити насамперед

Порядок важливий: принципи зміцнення, яким можна довіряти

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

Принцип 1: Закривайте віддалені двері перед тим, як облаштовувати інтер’єр

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

Принцип 2: Ідентичність і доступ — ваш перший постійний стан

Користувачі, групи, правила sudo, сервісні облікові записи та API-ключі — це те, як система буде використовуватися наступного року. Перевстановлення очистило брудну історію. Не відновлюйте її для зручності.

Принцип 3: Наблюдання — частина безпеки

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

Принцип 4: Сховище — де помилки стають катастрофами

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

Принцип 5: Бази краще за геройство

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

Цитата, яку варто тримати в голові, коли хочеться діяти навмання: «Надія — не стратегія.» — приписують John M. Sullivan (часто цитують у контексті операцій і планування).

Жарт №1: Свіжо перевстановлений сервер — як новонароджений: милий, голосний і абсолютно не готовий залишатися сам в інтернеті.

Швидкий план діагностики (перші/другі/треті перевірки)

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

Перше: чи здорова система на рівні ОС?

• Навантаження CPU? Перевірте load, чергу виконання та чи це CPU або iowait.
• Тиск пам’яті? Перевірте доступну пам’ять і активність swap.
• Диск заповнений? Заповнення / і /var — класичні постперевстановлювальні проблеми.
• Час правильний? Якщо годинники збиваються, TLS ламається, логи брешуть, а автентифікація стає «таємничою».

Друге: чи нормальний мережевий шлях?

• Маршрут за замовчуванням і DNS? Перевстановлення часто скидає резолвери, маршрути та імена інтерфейсів.
• Правила брандмауера? Ваші сервіси можуть працювати, але бути недоступними.
• Чи не перестаралися з жорсткістю SSH? «Закрито» не завжди означає «відрізано від доступу».

Третє: чи стек сховища робить те, що ви думаєте?

• Монтування і fstab? Відсутні монти змушують додатки писати в корінь.
• Стан RAID/ZFS? Деградовані масиви працюють повільно і виходять з ладу гірше.
• Права? Перевстановлення може непомітно змінити відповідність UID/GID.

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

Цікаві факти та історичний контекст (для скептиків)

1. Ранні Unix припускали довірчі мережі. Багато налаштувань історично віддавали перевагу зручності в університетських мережах, а не ворожому інтернет-оточенні.
2. SSH замінив telnet не просто так. У 1990-х у віддалених сеансах використовували відкритий текст; SSH зробив зашифроване віддалене адміністрування масовим.
3. Сервіси, відкриті за замовчуванням, мають довгу хвилю проблем. «Воно слухає тільки в LAN» — фраза, що часто з’являється в доповідях після інцидентів з перших плоских мереж.
4. Синхронізація часу стала функцією доступності. TLS, Kerberos і багато розподілених систем ламаються дивними способами, коли час збивається.
5. Збереження логів раніше було проблемою диска. Менші диски вимагали агресивної ротації; тепер режим відмови — «зберігати все, доки /var не заповниться».
6. Принцип найменших привілеїв не завжди був культурно прийнятий. Десятиліттями команди ops вирішували задачі швидко спільним root-доступом, потім роками відвикали від цього.
7. Брандмауери перемістилися з периметра на хост. Зростання хмари й zero-trust зробили фільтрацію на рівні хоста й сегментацію нормою, а не параною.
8. Незмінна інфраструктура популяризувала підхід «перевстановити, а не лагодити». Перебудовувати замість ремонту підвищує узгодженість — але тільки якщо ваш базовий захист реальний.

Чеклісти / покроковий план (що закрити в першу чергу)

Це порядок, який я б застосував на продакшн Linux-сервері після перевстановлення. Налаштовуйте під дистрибутив і середовище, але не імпровізуйте з послідовністю.

Фаза 0: не виведіть машину з ладу

• Отримайте поза-мережевий доступ (IPMI/iDRAC/консоль) або консоль серіалу хмари і перевірте його роботу перед змінами SSH чи брандмауера.
• Занотуйте поточні IP, маршрути, DNS і шлях доступу по SSH.
• Встановіть вікно відкату: якщо ви себе заблокуєте, потрібен відомий план відновлення.

Фаза 1: зупиніть просте віддалене компрометування

• Запатчуйте базові пакети ОС.
• Зміцніть SSH: ключі, заборона входу під root, вимкнення паролів (коли безпечно), мінімальні шифри/MACs якщо у вас є політика.
• Увімкніть і перевірте брандмауер хоста: deny за замовчуванням для вхідних, дозволити тільки необхідне.
• Видаліть/відключіть невикористовувані віддалені сервіси (старі веб-консолі, RPC-інтерфейси, dev-порти).

Фаза 2: зробіть ідентичність нудною

• Створіть іменовані облікові записи адміністраторів; уникайте спільного root.
• Закріпіть sudoers: явні групи, без NOPASSWD, якщо немає обґрунтованої причини.
• Встановіть адекватну політику паролів де потрібно (або централізовані політики автентифікації).
• Проведіть інвентаризацію authorized_keys і відкиньте «зомбі»-ключі.

Фаза 3: сховище і безпека даних (де живе біль)

• Підтвердіть монти та опції файлової системи (nodev/nosuid/noexec де доречно).
• Перевірте стан RAID/ZFS; заплануйте scrubs і перевірки SMART.
• Встановіть права і власність на шляхах даних; перевірте відповідність UID/GID для сервісних облікових записів.
• Налаштуйте ротацію логів і обмежувачі використання диска.
• Резервні копії: налаштуйте, виконайте і протестуйте відновлення. Якщо ви не тестуєте — у вас не резервна копія, а бажання.

Фаза 4: спостереження і реагування

• Синхронізація часу (chrony/systemd-timesyncd) і коректність часового поясу.
• Централізуйте логи або хоча б відправляйте критичні логи з хоста.
• Увімкніть аудит привілейованих дій, якщо це вимагає середовище.
• Базове моніторування: CPU, пам’ять, диск, перевірки сервісів і маршрути алертів.

Фаза 5: зміцнення сервісів (захист у глибину)

• Опції ізоляції systemd там, де безпечно.
• Відключіть невикористовувані модулі ядра і загостріть sysctl для мережевої експозиції.
• Підхід до управління секретами (права файлів, змінні середовища, інтеграція з vault, регулярна ротація).

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

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

Завдання 1: Підтвердіть, що саме слухає (і на яких інтерфейсах)

cr0x@server:~$ sudo ss -lntup
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=812,fd=3))
tcp   LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=1021,fd=7))
tcp   LISTEN 0      4096   0.0.0.0:9100       0.0.0.0:*     users:(("node_exporter",pid=1102,fd=3))

Що це означає: SSH і node_exporter відкриті на всіх інтерфейсах; Postgres слухає тільки на локальному інтерфейсі (добра за замовчуванням).

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

Завдання 2: Перевірте, що брандмауер увімкнений і політика не «мені байдуже»

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    203.0.113.10
9100/tcp                   ALLOW IN    10.10.0.0/16

Що це означає: За замовчуванням заборона вхідних з’єднань встановлена. SSH обмежено відомою IP-адресою адміністратора; метрики дозволені з внутрішнього діапазону.

Рішення: Якщо бачите «Default: allow (incoming)», виправте це негайно. Якщо SSH дозволено «Anywhere», звузьте доступ, якщо вам не потрібен глобальний адмініструвальний доступ (ви не потребуєте).

Завдання 3: Підтвердіть, що налаштування SSH не поставлять вас у незручне становище

cr0x@server:~$ sudo sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication|challengeresponseauthentication|x11forwarding|allowusers|allowgroups)'
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes
challengeresponseauthentication no
x11forwarding no

Що це означає: Вхід під root і автентифікація паролем вимкнені; автентифікація ключами увімкнена; X11 forwarding вимкнений.

Рішення: Якщо цей сервер — аварійний доступ або потребує break-glass, визначте це явно (обмежений джерельний IP + окремий ключ + оповіщення). Інакше тримайте паролі вимкненими.

Завдання 4: Переконайтеся, що ви себе не заблокували (через інший термінал)

cr0x@server:~$ ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no admin@server.example
Linux server 6.5.0-21-generic #21-Ubuntu SMP ...
admin@server:~$ echo OK
OK

Що це означає: Вхід по ключу працює як задумано; запасного паролю немає.

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

Завдання 5: Інвентаризація привілейованого доступу (sudo) і видалення несподіванок

cr0x@server:~$ sudo getent group sudo
sudo:x:27:admin,deploy

Що це означає: Група sudo містить облікові записи admin і deploy.

Рішення: Вирішіть, чи дійсно deploy потребує повного sudo. Зазвичай йому потрібні конкретні команди, а не повний режим бога.

Завдання 6: Перевірте на безпарольний sudo (воно поширюється)

cr0x@server:~$ sudo grep -R --line-number -E 'NOPASSWD|ALL=\(ALL\) ALL' /etc/sudoers /etc/sudoers.d 2>/dev/null
/etc/sudoers:27:%sudo   ALL=(ALL:ALL) ALL
/etc/sudoers.d/deploy:1:deploy ALL=(root) NOPASSWD:/usr/bin/systemctl restart myapp.service

Що це означає: Користувач deploy може перезапускати один сервіс без пароля. Це вузько обмежено і захищає інтереси автоматизації.

Рішення: Залишайте так, якщо це потрібно для автоматизації і чітко обмежено. Якщо знайдете NOPASSWD:ALL, приберіть його і будьте готові виявити «автоматизацію», яка насправді була просто поспіхом.

Завдання 7: Підтвердіть автоматичні оновлення безпеки (або ваш канал патчінгу)

cr0x@server:~$ systemctl status unattended-upgrades --no-pager
● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled)
     Active: active (running) since Tue 2026-02-03 11:14:26 UTC; 1 day ago

Що це означає: Автоматичні оновлення увімкнені і працюють.

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

Завдання 8: Підтвердіть відповідність ядра і ОС вашому базовому стану

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

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

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

Завдання 9: Перевірте синхронізацію часу (безпека й адекватність)

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

Що це означає: Годинник синхронізований; NTP активний; використовується UTC (приємно нудно).

Рішення: Якщо System clock synchronized: no, виправте це перед дебагом TLS, членства в кластері чи «випадкових» помилок автентифікації.

Завдання 10: Перевірте диски, файлові системи і монтування

cr0x@server:~$ lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat   FAT32       2F1A-9C2B                              512M     2% /boot/efi
├─sda2 ext4   1.0         6f8d1c6a-1f6a-4b6c-9f0a-1f7c6e2a1b4a   18G     21% /
└─sda3 ext4   1.0         41b2b9b0-9a1f-4b57-9b0d-0d8d1d7b6e2e  820G     9% /srv

Що це означає: Root і /srv окремі. Добре: дані додатків не завалять ОС миттєво.

Рішення: Якщо /var не виділено окремо, а ви очікуєте багато логів, розгляньте виділення або принаймні агресивну ротацію і моніторинг.

Завдання 11: Перевірте, що fstab не підкине вам несподіване перезавантаження

cr0x@server:~$ sudo cat /etc/fstab
UUID=6f8d1c6a-1f6a-4b6c-9f0a-1f7c6e2a1b4a /     ext4 defaults,errors=remount-ro 0 1
UUID=41b2b9b0-9a1f-4b57-9b0d-0d8d1d7b6e2e /srv  ext4 defaults,noatime         0 2

Що це означає: Монти використовують UUID (стабільно). errors=remount-ro захищає корінь від прихованої корупції, змінюючи режим на лише для читання при помилках.

Рішення: Якщо у вас є «тимчасові» монти, вирішіть, чи вони повинні бути з nofail. Для критичних даних не використовуйте nofail; краще впасти раннім етапом, ніж завантажитися в напівпрацюючому стані.

Завдання 12: Перевірте використання файлових систем і знайдіть першу «чому це заповнено?»

cr0x@server:~$ df -hT
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   20G  4.2G   15G  23% /
/dev/sda3      ext4  900G   80G  774G  10% /srv
tmpfs          tmpfs 3.1G     0  3.1G   0% /run/user/1000

Що це означає: Зараз вільно багато місця. Суть — встановити базову лінію перед тим, як система почне «ротіти».

Рішення: Встановіть алерти на 70/80/90% залежно від темпу зростання. Якщо / маленький — будьте агресивніші.

Завдання 13: Підтвердіть, що ротація логів увімкнена і не фантазія

cr0x@server:~$ sudo logrotate -d /etc/logrotate.conf | tail -n 8
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file apt
reading config file rsyslog
Handling 2 logs
rotating pattern: /var/log/syslog  weekly (4 rotations)
renaming /var/log/syslog to /var/log/syslog.1

Що це означає: Logrotate може розпарсити конфіг і має намір ротувати syslog щотижня з 4 обертами.

Рішення: Якщо ви покладаєтесь лише на journald, встановіть SystemMaxUse і SystemMaxFileSize у /etc/systemd/journald.conf. Інакше /var рано чи пізно почне мститися.

Завдання 14: Перевірте постійність journald і обмеження розміру

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 384.0M in the file system.

Що це означає: Журнали займають дисковий простір. Це нормально — поки не стане критично.

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

Завдання 15: Знайдіть сервіси, що стартують автоматично (і не повинні)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled
UNIT FILE                         STATE   PRESET
cron.service                      enabled enabled
ssh.service                       enabled enabled
unattended-upgrades.service       enabled enabled
postgresql.service                enabled enabled
apache2.service                   enabled enabled

Що це означає: Apache увімкнено. Можливо, це потрібно. Можливо, це залишок від «швидкого тесту» пакетів.

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

Завдання 16: Перевірте, що приватні TLS-ключі та секрети не читаються всіма

cr0x@server:~$ sudo find /etc/ssl -type f -name '*.key' -printf '%m %u %g %p\n'
640 root ssl-cert /etc/ssl/private/server.key

Що це означає: Режим 640, власник root, група ssl-cert. Типово для Debian/Ubuntu.

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

Завдання 17: Перевірте здоров’я сховища (SMART) перед тим, як довіряти машині

cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0-21-generic] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Що це означає: Диск повідомляє, що здоровий (не гарантія, але базова перевірка).

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

Завдання 18: Якщо ви використовуєте ZFS, підтвердіть стан пулу і заплануйте scrubs

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:44 with 0 errors on Sun Feb  1 03:10:02 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sdb       ONLINE       0     0     0
          sdc       ONLINE       0     0     0

errors: No known data errors

Що це означає: Пул online, останній scrub не виявив помилок.

Рішення: Якщо стан DEGRADED — вважайте це терміновим. Також переконайтеся, що scrubs заплановані (cron/systemd timer), щоб битовий розпад не став несподіваним хобі.

Завдання 19: Підтвердіть права на критичних шляхах даних (і узгодженість UID/GID)

cr0x@server:~$ sudo stat -c '%U %G %a %n' /srv /srv/myapp /srv/myapp/data
root root 755 /srv
myapp myapp 750 /srv/myapp
myapp myapp 700 /srv/myapp/data

Що це означає: Дані обмежені. Сервісний обліковий запис володіє своїми даними. Добре.

Рішення: Якщо бачите директорії даних, власником яких є root для сервісів, ви, ймовірно, «виправите» це пізніше chmod -R і спричините побічні проблеми. Встановіть власність правильно вже зараз.

Завдання 20: Підтвердіть наявність резервних копій і можливість їх відновлення (єдиний тест, що має значення)

cr0x@server:~$ sudo restic -r /backups/restic repo snapshots
repository 2f1a... opened (version 2, compression level auto)
ID        Time                 Host        Tags        Paths
c31e9f5a  2026-02-04 02:00:12  server                  /etc /srv/myapp

Що це означає: Сніпшот існує. Це ще не дає впевненості.

Рішення: Виконайте цілеспрямоване відновлення в тимчасову директорію і перевірте контрольні суми / запуск сервісу. Резервні копії без відновлення — це просто перформанс-арт.

Жарт №2: Якщо ви ніколи не тестували відновлення, ваша стратегія резервного копіювання — це поєднання «думок і молитв» з додатковим диском.

Три корпоративні міні-історії (як це ламається в реальних компаніях)

1) Інцидент через неправильне припущення: «Воно доступне тільки внутрішньо»

Середня компанія відбудувала сервер метрик після відмови диска. Інженер зробив те, що багато хто робить у втомі: встановив експортер, перевірив панелі — і пішов далі. Припущення було, що сервер живе «в приватній мережі».

Він ж — певною мірою. Нове хмарне зображення отримало публічну IP за замовчуванням, а security group був скопійований з шаблону для іншої ролі. Експортер слухав на 0.0.0.0:9100. Без автентифікації. Без правил брандмауера на хості. Панель працювала — отже все «добре».

За кілька днів сервер почав показувати дивні сплески і вихідний трафік. Нічого драматичного, але досить для тригера білінгу. Incident response знайшла сканери, які збирали метадані і намагалися відкрити відомі слабкі кінцеві точки. Експортер сам по собі не був короною; він був витоком інвентарю: версії ядра, змонтовані файлові системи, мережеві інтерфейси і іноді деталі середовища через textfile-колектори.

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

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

2) Оптимізація, що обернулася проти: відключення оновлень щоб «уникнути перезавантажень»

Команда fintech мала культуру високої доступності та побоювалася несподіваних оновлень ядра. Після перевстановлення вони вимкнули unattended upgrades і пообіцяли патчити у щомісячному вікні. Потім щомісячне стало щоквартальним, бо завжди був важливий кейс.

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

Зрештою рутинне сканування безпеки залило червоні рядки. Реакція була передбачуваною: екстрений патч, екстрені перезавантаження, екстрені погодження змін. «Оптимізація» породила саме те, чого прагнули уникнути, але тепер о 2 ранку з менеджментом у конференц-колі.

Виправлення не було «увімкнути оновлення і молитися». Вони реалізували пайплайн патчінгу: спочатку staging, потім production, і передбачуваний ритм із планом відкату. Культура змінилася: планові перезавантаження стали нормою, а «несподівані перезавантаження» — симптомом інциденту, а не прийнятним ризиком.

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

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

Логістична компанія мала парк серверів додатків, які часто перебудовувалися — апаратні заміни, оновлення ОС тощо. У їхньому базовому стані були окремі файлові системи: / — маленький і стабільний, /srv — для даних додатків, і /var — під логи. Це не те, чим хизуються на конференціях.

Одного вікенду вийшов новий реліз з випадково ввімкненим debug-логуванням. Обсяг логів підірвався. На однофайловій розкладці це класична ланцюгова реакція: / заповнюється, сервіси падають, SSH стає кволим, і відновлення перетворюється на паніку, бо навіть тимчасовий файл не записати.

Тут /var заповнився, алерти спрацювали, додаток деградував, а ОС залишилася робочою. SSH лишився стабільним. Вони пройшли ротацію, повернули рівень логів і система відновилася без корупції файлової системи чи екстреного відновлення.

Постмортем був коротким. Не тому, що нічого не сталося — а тому, що радіус ураження був обмежений нудними рішеннями, прийнятими під час перевстановлення. Окремі монти, адекватна ротація і правильна власність — не гламурно. Але саме вони дозволяють пережити власне програмне забезпечення.

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

1) Симптом: «SSH вчора працював, тепер я заблокований»

Корінна причина: Брандмауер затягнули без перевірки доступу з реального IP адміністратора; або PasswordAuthentication вимкнули до розгортання ключів; або AllowUsers налаштовано неправильно.

Виправлення: Використайте консоль для відкату. Перевірте sshd -T і спробуйте вхід лише по ключу з другої сесії перед тим, як закрити консоль. Обмежуйте SSH за IP тільки після підтвердження стабільних шляхів доступу.

2) Симптом: «Сервіс працює, але недоступний»

Корінна причина: Процес прив’язаний до 127.0.0.1 або неправильного інтерфейсу після перевстановлення; або брандмауер хоста за замовчуванням deny без явного allow; або невідповідність правил у хмарі.

Виправлення: Перевірте ss -lntup для підтвердження bind-адрес. Перевірте правила брандмауера на хості і в хмарі. Не припускайте, що «працює» означає «доступно».

3) Симптом: «Дисковий простір постійно зникає»

Корінна причина: journald або логи додатків без обмежень; дампи core з великим розміром; тимчасові файли накопичуються; видалені, але відкриті файли.

Виправлення: Обмежте використання journald, налаштуйте logrotate і використайте lsof +L1 щоб знайти видалені відкриті файли. Помістіть важкі шляхи запису на окремі монти і вмикайте ранні алерти.

4) Симптом: «Права правильні, але додаток не читає/пише»

Корінна причина: Невідповідність UID/GID після перевстановлення; томи контейнерів змонтовані з власником host root; відсутні ACL; відмови SELinux/AppArmor.

Виправлення: Перевірте id myapp і власність на диску. Якщо використовується SELinux/AppArmor, дивіться відмови і правильно міткуйте профілі замість бездумного chmod -R.

5) Симптом: «TLS раптом ламається: сертифікат ще не дійсний / прострочений»

Корінна причина: Час не синхронізовано; плутанина з часовими зонами; RTC неправильно налаштований; NTP заблокований.

Виправлення: Виправте синхронізацію часу перш за все (timedatectl, chrony). Не робіть ротацію сертифікатів, поки годинник не стане адекватним, інакше ви будете ганятися за примарами.

6) Симптом: «Після перевстановлення продуктивність жахлива»

Корінна причина: Неправильний драйвер сховища, відсутня прошивка, деградований RAID/ZFS, або налаштування планувальника вводу/виводу скинуті; або swap-трещання через змінені налаштування пам’яті.

Виправлення: Почніть з iostat, vmstat і перевірок здоров’я сховища. Переконайтеся у статусі RAID/ZFS. Підтвердіть, що ви на потрібному стеку ядра/драйверів.

7) Симптом: «Резервні копії проходять, але відновлення ламається»

Корінна причина: Резервні копії захоплюють неправильні шляхи, відсутні права/ACL, або ключі шифрування не збережені; процедура відновлення ніколи не валідована.

Виправлення: Проведіть відновлення: відновіть у тимчасовий шлях, перевірте цілісність і запустіть сервіс з відновленою конфігурацією. Ставте кроки відновлення як код і автоматизуйте їх.

Питання й відповіді

1) Що потрібно закрити в першу чергу після перевстановлення?

Експозицію SSH і вхідну мережеву політику. Запатчуйте базову ОС, зміцніть SSH (ключі, без root, без паролів коли можливо) і встановіть deny за замовчуванням у брандмауері з явними дозволами.

2) Чи слід негайно вимикати автентифікацію паролем у SSH?

Тільки після перевірки доступу по ключу з окремої сесії і наявності консолі. Вимикайте паролі рано, але не робіть цього як першу зміну на хості, доступному лише віддалено.

3) Чи нормально дозволяти SSH звідусіль, якщо я використовую сильні ключі?

Це терпимо, але не оптимально. Сильні ключі зменшують атаки на облікові дані, але ви все одно отримуєте шум від брутфорсу, спроби експлойтів і збільшену експозицію. Обмежуйте по джерелу або через VPN, де можливо.

4) Як обрати між UFW, nftables і firewalld?

Обирайте те, чим ваша команда може послідовно оперувати. UFW простий і звичний в Ubuntu. nftables — потужний і прямий. firewalld підходить у середовищах, стандартизованих на ньому. Послідовність важливіша за особисті вподобання.

5) Чому після перевстановлення ламаються права додатку, навіть коли файли виглядають правильно?

Класичне зміщення UID/GID. Ім’я користувача може збігатися, але числові ідентифікатори — ні. Перевірте також ACL і відмови SELinux/AppArmor. Почніть з відповідності ідентичності; уникайте chmod -R як «рішення».

6) Чи потрібно шифрувати диски на серверах?

Якщо існує ризик фізичного доступу, багатокористувацьке середовище, вимоги комплаєнсу або ви відправляєте диски в RMA — так. LUKS додає операційної складності (розблокування при завантаженні, управління ключами). Вирішіть усвідомлено і протестуйте завантаження та відновлення.

7) Скільки логів достатньо після перевстановлення?

Достатньо, щоб відповісти: хто увійшов, що змінилося, що впало і що система робила перед падінням. Мінімум: auth-логи, системні логи, логи сервісів і синхронізація часу. Відправляйте поза хост, якщо ризик компрометації реальний.

8) Який найшвидший спосіб спіймати випадково відкрите сервіс?

ss -lntup на хості, плюс зовнішнє сканування портів з відомої точки. Вид хоста показує, що слухає; зовнішнє сканування показує, що доступно через брандмауери.

9) Чи справді потрібно тест відновлення одразу після перевстановлення?

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

10) Яка зміна в hardening найчастіше перестарана?

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

Практичні наступні кроки

1. Запустіть інвентаризацію прослуховуваних портів і змусьте кожен відкритий порт виправдати своє існування.
2. Встановіть deny за замовчуванням для вхідних у брандмауері хоста і явно дозвольте SSH з відомих джерел.
3. Зміцніть SSH за допомогою ключів, заборони входу під root і відключення паролів (після перевірки).
4. Встановіть базу ідентичності: облікові записи адміністраторів, правила sudo і сервісні користувачі з найменшими привілеями.
5. Зробіть сховище нудним: перевірте монти, права, ротацію і перевірки здоров’я дисків.
6. Доведіть резервні копії шляхом відновлення реальної частини даних і запуску сервісу з неї.
7. Увімкніть нудні сигнали: синхронізацію часу, обмеження зберігання логів і відправку логів поза хост, де доречно.
8. Запишіть базовий стан: виводи ключових команд, версії, правила брандмауера і очікування власності — щоб майбутній ви міг порівнювати реальність з наміром.

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