Есть ли система, которая помогает выявить источник взлома (помимо стандартных логов)?

Question

[Алексей Николаев]

Доброй ночи.
Есть сервер, на котором регулярно проводятся модификации сайтов (их несколько на сервере). Причем модифицируется .htaccess, что позволяет злоумышленнику создавать несуществующие технически страницы. Код по много раз проверен, ничего подозрительного не выявлено. Ядро (ModX последней версии) сверено с исходниками - все чисто. В логах доступа также нет ничего такого, за что можно зацепиться. Подозреваю, что htaccess модифицируется потому, что дальше доступа у злоумышленника по каким-либо причинам не имеется (собственно, все папки закрыты, и явных дыр тоже выявить не смогли).

Есть мысли вынести сайты на уровень выше корня, оставив только точку входа, но хотелось бы понять природу подобных атак, и что является дырой - собственно CMS, кривые плагины или проблемы хостинга. Есть ли способы подробно отследить, как именно был получен доступ на сервер, откуда был модифицирован файл? Как вообще проводится поиск эксплойтов на сайте, если идей никаких нет?

Заранее спасибо за советы.

Answer 1

[index0h]

сверено с исходниками - все чисто

И в БД тоже? Я очень давно последний раз трогал MODx и на сколько помню там было в моде часть исходников хранить в БД.
Надеюсь вы проверяли исходники не вручную? (в смысле через diff в вашей VCS + в БД)

Есть мысли вынести сайты на уровень выше корня, оставив только точку входа

Это первое, что нужно делать))

Как вообще проводится поиск эксплойтов на сайте, если идей никаких нет?

0 - Если у вас в публичном каталоге не одна точка входа, а весь проект - вы уже себе в ногу выстрелили
1 - Ищутся CVE в багтрекере CMS
2 - Проверяются плагины, установленные в системе, они тоже могут содержать уязвимости
3 - Проверяется возможность загрузить и выполнить файл. Например на uploads (или как там каталог называется) права на запуск должны со всей силы отсутствовать
4 - Проверяются открытые порты сервера (если наружу торчит mysql, redis, memcached, ... - тогда сами себе злобный буратино)
5 - Ищутся все возможные точки с eval/include/require/include_once/require_once/exec/shell_exec/... для стороннего кода это потенциальная точка выполнения
6 - Ищутся возможные sql инъекции по коду cms/плагинов
7 - Ищутся всевозможные phpmyadmin и тому подобные сервисы, торчащие наружу
8 - Если в коде активно юзаются глобальные переменные - это потенциальная дыра в безопасности
9 - Если аргументы методов не проверяются - это тоже потенциальная дыра в безопасности
10 - Вам стоит убедиться и в том, что отсутствует утечка изнутри. На одном проекте случайно нашел залитый бывшими сотрудниками phpspy

Comments

[xfg]

> если наружу торчит что-то помимо 80/443 - вы сами себе злобынй буратино

Как тогда управлять удаленным сервером, который находится за пределами локальной сети? Можно ssh повесить на нестандартный порт, но он все равно будет торчать наружу.

Что вы предлагаете?

[index0h]

xfg
На сервере нужно 2 сетевых интерфейса. Публичный умеет в 80/443, в остальное умеет приватный.
Хотя... на счет ssh я наверное погорячился)) Исправлю ответ

[xfg]

index0h: понял, спасибо.

Answer 2

[Михаил Есенин]

Система такая есть - это Auditd. Но, кажется, тебе нужно выявить первопричину этих событий, index0h правильно расписал про поиск дыр. Сделать это можно как с помощью онлайн-сканеров безопасности вроде Pentest-tools, METASCAN, так и самому руками с помощью популярных утилит из того же Kali Linux. :)