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

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

Хочеться одразу взятися за велике: перебудувати, перенести, загнати в контейнери. Спершу зробіть маленьке. Година часу, пʼять запитань - і ви знатимете, чи ця машина просто незручна, чи вже аварійна.

Це аудит, який ми провели саме на такій машині минулого тижня, і ось що він реально показав. Кожна знахідка нижче справжня, і жодну з них не було видно ззовні.

1. Що насправді слухає, і що про це думає файрвол

Ці дві відповіді завжди порівнюють, а не читають окремо. Перша - правда про машину; друга - те, що хтось колись мав на увазі.

ss -tlnp                     # усі TCP-сокети, що слухають, разом із процесом
iptables -L INPUT -n --line-numbers

Наша знахідка, і саме її варто забрати з цієї статті: у файрволі був акуратний allowlist для порту адмінпанелі, три довірені підмережі, написаний людиною, яка розуміла, що робить. На чотири рядки вище нього стояв широкий ACCEPT для того самого порту з 0.0.0.0/0, доданий пізніше.

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

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

2. Хто насправді користується тим, що ви зараз хочете закрити

Найкорисніша звичка цього аудиту. Перш ніж закрити будь-який шлях, прочитайте його лог доступу і полічіть реальних користувачів.

# найактивніші адреси за одним шляхом, останні 10к рядків
grep -h 'phpmyadmin' /var/log/nginx/*access* | awk '{print $1}' \
  | sort | uniq -c | sort -rn | head

Дві наші знахідки - прямо звідси:

  • phpMyAdmin 2017 року, доступний з інтернету, на веб-сервері, чий PHP уже не отримував оновлень від постачальника. Лог показав 201 запит з однієї адреси і 38 з іншої - обидва боти, що проходять по словнику. Жодної людської сесії за весь період.
  • proftpd у роботі, відкритим текстом, без TLS. xferlog порожній з червня. Єдині підключення - спроби анонімного логіну з ботнету.

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

Правило таке: ніколи не закривайте сервіс на припущенні, що ним ніхто не користується. Закривайте на доказі, що ним ніхто не користується. Різниця між цими двома непомітна, доки не подзвонять із відділу, що виписує рахунки.

3. Не замкнутися самому

Усе в цьому розділі - робота з файрволом на машині, до якої ви маєте доступ тільки через цей самий файрвол. Дві запобіжні дії, обидві дешеві.

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

iptables-save > /root/iptables.good
echo 'iptables-restore < /root/iptables.good' | at now + 10 minutes

Застосуйте зміну, відкрийте новісіньку SSH-сесію звідкись іншого, і лише тоді скасовуйте завдання командою atrm. Перевірка на вже відкритій сесії нічого не доводить: встановлене з’єднання переживає правила, які блокують нові.

Потім зробіть так, щоб це пережило перезавантаження - окремий крок, і саме той, про який забувають:

service iptables save          # або: netfilter-persistent save
systemctl is-enabled iptables

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

4. Що насправді продовжується, а що лише виглядає так

Тихий убивця. На цій машині продовження TLS було завданням усередині панелі керування, чия ліцензія закінчилася два місяці тому. Cron продовження помер разом із ліцензією. Чотири сайти вже п’ять днів провалювали TLS-хендшейк до того, як аудит це знайшов, а ще сім мали знятися з сертифікатів протягом трьох тижнів.

# усі запланові завдання на машині за один прохід
crontab -l; ls -l /etc/cron.*/ /etc/cron.d/; systemctl list-timers --all

Читайте все, включно із закомейченими рядками - вони показують, що колись працювало. І шукайте дублікати: ми вимкнули один cron продовження і лише з другого проходу знайшли другий, що запускав те саме завдання, в іншу годину, на чотири рядки нижче.

Повернути продовження собі - коротка робота навіть на дистрибутиві з вичерпаним терміном підтримки, ми описали це в acme.sh на сервері, де certbot не встановлюється.

5. Що встановлено, але нічим не використовується

Застарілі машини накопичують рантайми. На нашій було одинадцять окремих збірок PHP, починаючи з 5.2. Цікаве питання не те, що встановлено, а що насправді підключено:

grep -rhoE 'php[0-9]+' /etc/nginx/conf.d/*.conf /etc/httpd/conf.d/*.conf \
  | sort | uniq -c | sort -rn

Вісім сайтів працювали на 7.4, три на 8.0, і кожна збірка старіша за це була мертвим вантажем. Ця одна команда змінила план переїзду: машина, яка на вигляд потребує хостингу з підтримкою PHP 5.2, насправді потребує 7.4 і 8.x, тобто будь-чого сучасного.

Аудит - це не лише про те, що закрити. Це ще й про те, щоб виявити, що страшної частини роботи насправді не існує.

Що купила одна година

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

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

Якщо аудит відправив вас у пошуки нової машини, ми порівняли варіанти з живими цінами в найкращому VPS для самохостингу у 2026 і описали чотири роки на одному провайдері в огляді Hetzner Cloud.