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

Базовая защита сайта - обновления, доступы, проактивная защита

Закрываем сайт в порядке убывания пользы: сначала люди и доступы, потом обновления и права, и только затем тонкие настройки защиты.

Решение

Смотрим, у кого есть полный доступ:

$res = CUser::GetList('ID', 'ASC', ['GROUPS_ID' => [1], 'ACTIVE' => 'Y'],
    ['FIELDS' => ['ID', 'LOGIN', 'EMAIL', 'LAST_LOGIN']]);
while ($u = $res->Fetch()) {
    printf("%-4d %-20s %-28s последний вход=%s\n",
        $u['ID'], $u['LOGIN'], $u['EMAIL'], $u['LAST_LOGIN'] ?: 'никогда');
}

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

Проверяем, что платформа обновлена:

echo SM_VERSION, "\n";
$res = CModule::GetList();
while ($module = $res->Fetch()) {
    printf("%-24s %s\n", $module['ID'], $module['VERSION'] ?? '');
}
// обновления закрывают известные дыры: старая версия - открытая инструкция

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

Смотрим права и чужие файлы:

Окно терминала
find /home/bitrix/www -type f -perm -o+w | head -20        # доступные всем на запись
find /home/bitrix/www/upload -name '*.php' | head -20      # исполняемое в загрузках
find /home/bitrix/www -name '*.php' -newermt '-7 days' | grep -v '/bitrix/' | head

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

Включаем проактивную защиту:

COption::SetOptionString('security', 'filter_status', 'Y');   // фильтр запросов
COption::SetOptionString('security', 'filter_action', 'filter');
// защита закрывает типовые атаки, но не заменяет обновления и пароли
// перед включением фильтра проверяют формы: он режет и часть своих запросов

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

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

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

Резервные копии остаются самым последним рубежом защиты сайта. Проверенная копия превращает взлом из катастрофы в неприятный день, а непроверенная не превращает ни во что.

Типичные проблемы

В административной части появились чужие пользователи.

Кто-то получил доступ к сайту сразу с полными правами администратора. Разбор начинают со списка администраторов и журнала входов в административную часть.

В каталоге загрузок лежат файлы с кодом.

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

Сайт рассылает спам.

Через сайт работает чужой скрипт либо кем-то украдены доступы к почтовому ящику. Проверяют очередь почты и все недавно изменённые файлы на сайте.

Проактивная защита включена, а сайт взломали.

Вход был сделан через слабый пароль или устаревшее решение каталога. Фильтр запросов подобные случаи вообще никак не закрывает.

После чистки взлом повторился.

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

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

Что делать первым при подозрении на взлом?

Снять копию текущего состояния и посмотреть журнал входов. Чистка без копии лишает возможности разобраться в причине.

Нужен ли отдельный сканер файлов?

Полезен, но не заменяет разбор: он находит известное. Свежие изменения в файлах ищут и обычными средствами.

Стоит ли закрывать административную часть по адресу?

Да, если администраторы работают с известных адресов. Это самая дешёвая защита из всех действенных.

Как часто обновлять платформу?

Обновления безопасности - сразу, остальные - по плану с проверкой на копии. Откладывание «на потом» и есть типовая причина взлома.

Смежное

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