Как найти веб-шелл на сайте: пошаговая проверка и очистка

Что такое веб-шелл и как он попадает на сайт

Веб-шелл (web shell) — это файл или фрагмент кода на языке, который исполняет ваш веб-сервер: чаще всего PHP, реже ASP.NET, JSP или Python. Самые известные семейства — c99, r57, WSO, b374k, China Chopper. Но в реальных взломах чаще встречаются не «громоздкие» панели, а крошечные однострочные загрузчики, которые принимают команду из запроса и выполняют её.

Проникают они, как правило, через несколько типовых лазеек: устаревшие плагины и темы, уязвимые формы загрузки файлов, украденные пароли от FTP, SSH и админ-панели, а также взломанные соседние сайты на одном хостинговом аккаунте. Поэтому поиск шелла — это всегда ещё и расследование: нужно понять вектор атаки.

Отдельная сложность в том, что хороший шелл ничем себя не выдаёт. Сайт открывается, заказы приходят, а вредоносный код живёт месяцами. Узнают о нём обычно по косвенным симптомам.

С чего начать поиск

Если совпал хотя бы один признак, не торопитесь «чистить» всё подряд. Сначала сделайте полную копию сайта и базы данных в изолированное место: она понадобится для анализа и как страховка, если что-то пойдёт не так. Затем по возможности переведите сайт в режим обслуживания или ограничьте доступ к админке по IP.

Искать веб-шелл логичнее всего в тех местах, куда злоумышленнику проще всего записать файл и где он меньше всего бросается в глаза.

Поиск подозрительного кода командами

Если у вас есть SSH-доступ, самый быстрый способ найти подозрительные места — поиск по шаблонам. Например, команда `grep -rEn '(eval|base64_decode|gzinflate|str_rot13)[[:space:]]*[(]' --include='*.php' .` выводит все файлы и строки, где встречаются типичные функции маскировки. Для запуска системных команд подойдёт такой же поиск по `system`, `shell_exec`, `passthru`, `exec`, `popen` и `proc_open`.

Учтывайте, что результатов будет много: в нормальных плагинах эти функции встречаются тоже. Ищите комбинации: eval вместе с base64_decode и данными из $_POST, $_GET, $_REQUEST или $_COOKIE. Подозрительны и очень длинные строки без пробелов, и код, где имена функций собираются из кусочков или через chr().

Если доступа к консоли нет, часть работы можно сделать через панель хостинга: там часто встроен антивирус, а файловый менеджер умеет сортировать файлы по дате изменения.

Нашли шелл — не удаляйте его сразу

Находка — это момент, когда легко наделать ошибок. Сначала сохраните копию файла и зафиксируйте путь, дату изменения и владельца. Затем посмотрите в логах, с какого IP-адреса и когда к нему обращались: первое обращение подскажет время взлома, а запросы незадолго до него — путь проникновения.

Именно по времени создания шелла можно найти уязвимость: если файл появился сразу после POST-запроса к форме загрузки или старому плагину, дыра, скорее всего, там. После этого переходите к удалению и вместе с ним ищите связанные бэкдоры — их обычно несколько, и лежат они в разных местах, чтобы пережить уборку.

Как закрыть дыру после очистки

После того как все найденные шеллы удалены, переходите к профилактике. Обновите CMS, плагины и темы, удалите неиспользуемые расширения, особенно «взломанные» премиум-версии. Запретите исполнение PHP в папках загрузок на уровне настроек веб-сервера и ограничьте права на запись: файлы ядра не должны быть доступны для изменения процессу сайта.

Включите двухфакторную аутентификацию для админки и хостинга, ограничьте доступ к панели по IP и регулярно проверяйте список пользователей. Настройте автоматические резервные копии с хранением вне сервера и ежедневное сканирование. А через неделю-две повторите проверку: если бэкдор остался, он обычно проявляется именно в этот период.