Обновились после PHP2Shell: как проверить, что не взломали

Почему проверять нужно

Между появлением рабочих эксплойтов и вашим обновлением прошло какое-то время. Заплата закрывает дверь, но не выставляет за неё того, кто успел войти. Если сервер смотрел в интернет непропатченным хотя бы сутки после 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. Если нашли следы

Порядок действий важен:

1. Снимите образ диска или хотя бы копию журналов — они понадобятся, чтобы понять, что произошло.
2. Не «чистите» сервер по одному файлу: при полноценном взломе надёжнее поднять новый сервер и перенести данные, проверив их.
3. Смените всё, что могло утечь: пароли баз данных, ключи API, токены платёжных систем, ключи SSH, пароли панелей.
4. Проверьте, не уходила ли почта с сервера — компрометацию часто используют для рассылок.

Если следов нет

Это хороший знак, но не доказательство. Включите хранение журналов на отдельном сервере, настройте оповещения о новых файлах PHP в каталогах сайтов и проверьте, что резервные копии делаются и восстанавливаются.

Частые вопросы

Поможет ли антивирус?

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

Стоит ли менять пароли клиентов?

Если есть основания считать, что база утекла — да, с принудительным сбросом. Без признаков компрометации достаточно сменить служебные ключи.

Сколько хранить журналы?

Минимум 90 дней. При расследовании первое, чего не хватает, — это записи недельной давности.