Перейти к содержимому

Сайт взломан - признаки, разбор и порядок действий

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

С чего начать

Ищем свежие и подозрительные файлы:

Окно терминала
find /home/bitrix/www -name '*.php' -newermt '-3 days' | grep -v '/bitrix/' | head -30
grep -rlE 'eval\(|base64_decode\(|assert\(' /home/bitrix/www/upload/ 2>/dev/null | head
# дата изменения и место - два самых быстрых признака чужого файла

Файл с кодом в каталоге загрузок и свежие правки там, где никто ничего не менял,

  • два самых надёжных признака. Разбор начинают с них, а не с попыток понять, что именно делает найденный код.

Смотрим, кто заходил в административную часть:

$res = CEventLog::GetList(['ID' => 'DESC'], ['AUDIT_TYPE_ID' => 'USER_LOGIN']);
$n = 0;
while (($row = $res->Fetch()) && $n++ < 30) {
printf("%s %-16s адрес=%s\n", $row['TIMESTAMP_X'], $row['ITEM_ID'], $row['REMOTE_ADDR']);
}
// вход администратора ночью с незнакомого адреса - повод остановиться и разобраться

Журнал входов отвечает на главный вопрос: зашли под чужой учётной записью или пролезли мимо входа. От ответа зависит всё дальнейшее, и без него чистка превращается в угадывание.

Проверяем список администраторов и почту:

$res = CUser::GetList('ID', 'DESC', ['GROUPS_ID' => [1]], ['FIELDS' => ['ID', 'LOGIN', 'DATE_REGISTER']]);
while ($u = $res->Fetch()) { printf("%-4d %-20s создан=%s\n", $u['ID'], $u['LOGIN'], $u['DATE_REGISTER']); }

Свежая запись с полными правами - прямое доказательство. Такую запись не удаляют сразу: сначала записывают её данные, потом выключают, и только потом начинают разбираться, как она появилась.

Причины

  1. Утёкший или слабый пароль администратора примерно 30% случаев

    ПризнакВ журнале обычный вход под настоящей учётной записью с чужого адреса.

    ПроверкаСмотрим журнал входов и сверяем адреса с теми, откуда работают свои люди.

    Что делатьМеняем пароли всем администраторам, включаем второй фактор и завершаем чужие сеансы.

  2. Устаревшая платформа или решение из каталога примерно 25% случаев

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

    ПроверкаСмотрим версию платформы и список установленных решений с датами их обновлений.

    Что делатьОбновляем платформу и решения, снимаем заброшенные, затем чистим следы взлома.

  3. Заражённый компьютер сотрудника примерно 20% случаев

    ПризнакПравки идут через доступ по файловому протоколу от имени реального человека.

    ПроверкаСверяем журналы доступа к файлам с рабочим временем этого сотрудника.

    Что делатьМеняем его доступы, проверяем его компьютер и переходим на защищённый доступ по ключу.

  4. Своя форма загрузки без проверок примерно 15% случаев

    ПризнакЧужие файлы лежат ровно в том каталоге, куда пишет своя форма.

    ПроверкаСмотрим код формы: проверяет ли она тип файла и запрещает ли исполняемые расширения.

    Что делатьДобавляем проверку типа и запрет исполнения в каталоге загрузок на уровне веб-сервера.

  5. Общий доступ к серверу у подрядчиков примерно 10% случаев

    ПризнакОдну учётную запись сервера используют несколько человек и подрядчиков.

    ПроверкаСмотрим список ключей доступа и учётных записей на сервере.

    Что делатьРазводим доступы по людям и убираем ключи тех, кто больше не работает над проектом.

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

Что делать в первую очередь?

Снять полную копию текущего состояния. Без неё разбор причины станет невозможен, а чистка сотрёт следы.

Можно ли просто восстановиться из копии?

Можно, но пока причина не закрыта, взлом повторится в тот же день. Восстановление - шаг после разбора, а не вместо него.

Как найти все чужие файлы?

Сравнением с чистой копией платформы и поиском по дате изменения. Ручной просмотр каталогов пропускает часть закладок.

Нужно ли сообщать посетителям?

Если утекли их данные - да, и это требование закона, а не вежливость. Молчание обходится дороже.

Смежное

Первоисточник