Чому перевіряти потрібно

Між появою робочих експлойтів і вашим оновленням минув певний час. Латка закриває двері, але не виставляє за них того, хто встиг увійти. Якщо сервер дивився в інтернет непропатченим бодай добу після 21 жовтня 2026 року, перевірку варто зробити.

Крок 1. Сліди в журналах вебсервера

Атака виглядає як незвично великі POST-запити, часто до неіснуючих шляхів, іноді з відповіддю 500.

awk '$6 ~ /POST/ && $10 > 100000' /var/log/nginx/access.log | tail -50
grep -c ' 500 ' /var/log/nginx/access.log

Порівняйте кількість відповідей 500 зі звичайним рівнем. Сплеск у дні до оновлення — привід приглянутися уважніше.

Крок 2. Нові та змінені файли

find /var/www -type f -newermt '2026-10-15' \( -name '*.php' -o -name '*.phar' \) -printf '%TY-%Tm-%Td %p\n' | sort
find /tmp /var/tmp /dev/shm -type f -name '*.php' 2>/dev/null

Файли PHP у тимчасових каталогах — майже завжди поганий знак. У каталозі сайту звертайте увагу на файли, яких немає у вашому репозиторії.

Крок 3. Що запущено і що слухає

ps -eo lstart,user,cmd --sort=start_time | tail -30
ss -tulpn | grep -vE ':(22|80|443|3306|6379)\b'

Шукайте процеси, запущені від користувача вебсервера, яких ви не заводили, і порти, які ніхто не повинен слухати.

Крок 4. Точки закріплення

crontab -l; sudo crontab -l
ls -la /etc/cron.d/ /etc/cron.*/
sudo grep -rn 'curl\|wget\|base64' /etc/cron* 2>/dev/null | head
systemctl list-units --type=service --state=running | tail -20
cat ~/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

Чужий ключ в authorized_keys означає, що доступ збережено і зміною пароля він не закривається.

Крок 5. Якщо знайшли сліди

Порядок дій важливий:

Зніміть образ диска або хоча б копію журналів — вони знадобляться, щоб зрозуміти, що сталося.
Не «чистіть» сервер по одному файлу: у разі повноцінного зламу надійніше підняти новий сервер і перенести дані, перевіривши їх.
Змініть усе, що могло витекти: паролі баз даних, ключі API, токени платіжних систем, ключі SSH, паролі панелей.
Перевірте, чи не йшла пошта з сервера — компрометацію часто використовують для розсилань.

Якщо слідів немає

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

Часті запитання

Чи допоможе антивірус?

Сканери на кшталт ClamAV з набором правил для вебшелів знаходять типові закладки, але не всі. Відсутність знахідок нічого не доводить.

Чи варто змінювати паролі клієнтів?

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

Скільки зберігати журнали?

Щонайменше 90 днів. Під час розслідування першого, чого бракує, — це записів тижневої давнини.