90 дней тестировали BitNinja — коробочное решение для защиты сервера и сайта. Рассказываем кто, откуда и что атакует

от автора

BitNinja — это аналог Dr.Web или Immunify, но в отличие от них специализируется не только на ловле вирусов, но и фильтрации входящего трафика. Для работы антивируса задействует AI, а управлять защитой всех серверов можно из одного окна.

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

Тестирование BitNinja мы разделили на три фазы.

1. Пассивное — просто размещаем BitNinja на серверах с разной конфигурацией и смотрим, на какие активности он реагирует.

2. Активное — идем по публичной документации вендора и тестируем с помощью симуляции атак. 

Важно. В России симуляция атаки на сервер приравнивается к киберпреступлению. Поэтому, если вы работаете из РФ и/или тестовые VPS находятся в РФ, не симулируйте атаки на серверах с белыми IP. Это уголовно наказуемое преступление. Тестировать продукт таким образом можно только в серой сети и только предупредив хостера. Если вы работаете из другой страны и/или тестовые VPS находятся в другой стране, изучите местное законодательство по этому вопросу.

3. Приближенное к реальности — за BitNinja размещается какой-то реальный код, который пентестеры пытаются вскрыть.

В этой статье я расскажу об итогах пассивного тестирования. По его результатам я сгенерировал несколько гипотез:

  • Даже пустой сервер подвергается атакам.

  • WordPress привлекает больше внимания атакующих, чем Drupal.

  • Иногда атаки проходят по всей сети провайдера, без цели захватить какой-то конкретный сервер.

  • Больше всего атак и блокировок приходится на запросы, взаимодействующие с портами сервера.

Рассказываю подробности.

Инфраструктура для пассивного тестирования BitNinja

Мы взяли 3 сервера с 2 ядрами, 4 ГБ RAM и 60 ГБ жесткого диска и разными операционными системами: Debian 11, Ubuntu 22 и AlmaLinux 8. Пользователь на сервере во всех случаях был один — root. Все серверы находятся в одном кластере и у одного хостинг-провайдера, на территории РФ.

ПО на сервере:

  • Ispmanager lite с рекомендуемым ПО;

  • BitNinja, устанавливался как stand alone версия;

  • WordPress на Ubuntu 22 и Debian 11 (далее WPU и WPD);

  • Drupal на AlmaLinux 8 (далее DA).

Сайты на CMS не создавали — это просто голые файлы CMS, даже без доменов. В ноябре мы зададим домены и создадим сайты. Посмотрим, как изменится ситуация.

При схожих вводных со стороны ПО и ТТХ мы ожидали и одинакового результата с точки зрения активности злоумышленников. Но ошиблись.

Настройки BitNinja

Основная задача теста — проверить сколько атак отловит BitNinja с минимальными настройками. Поэтому никаких существенных изменений не было. Единственное, для DA и WPD был включен WAF, без каких-либо изменений в правилах.

Поскольку для всех CMS в качестве БД использовался MySQL, также можно было включить Database Cleaner — этот модуль проверяет базы данных на предмет заражения. Но в моменте это забылось.

Подробнее об устройстве BitNinja в блоге ispmanager →

Состояние модулей BitNinja

Malware detection

Включен, настройки по умолчанию

WAF

Включен для DA и WPD

Trusted Proxy

Включен, настройки по умолчанию

Port Honeypot

Включен, настройки по умолчанию

Web Honeypot

Выключен

DoS Detection

Включен, настройки по умолчанию

Log Analysis

Включен, настройки по умолчанию

Defense Robot

Включен, настройки по умолчанию

Site Protection

Выключен

Database Cleaner

Выключен

Sandbox Scanner

Включен, настройки по умолчанию

Vulnerability Patcher

Включен, настройки по умолчанию

Spam Detection

Включен, настройки по умолчанию

Advanced Modules

Включены, настройки по умолчанию

Результаты пассивного тестирования BitNinja

Сводка
Период 17.08 — 29.10 (обновим по завершению октября)

  • Зафиксировано инцидентов — 82 тыс.;

  • Заблокировано попыток «вскрытия» портов — 81 тыс.;

  • Заблокировано соединений с помощью WAF — 30 штук;

  • Найдено вирусов — 0;

  • Зафиксировано DoS-атак — 13;

  • Проанализировано подозрительных логов — 17;

  • Заблокировано пакетов. Много. На графике значения в тысячах заблокированных пакетов.

Из сводки видно, что по интернету гуляет множество парсеров и ботов, которые «щупают» ресурсы в поисках уязвимостей. На серверах нет абсолютно ничего, однако с завидной регулярностью их утюжат в поисках дырок. Даже несколько DoS-атак прошло.

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

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

Разбивка по странам тоже не такая, как я ожидал. Да, там есть Индия и Тайвань, но. 

  1. Китай — с очень большим отрывом.

  2. США.

  3. РФ.

Кроме Китая, неожиданным для меня стали Танзания и UK

Кроме Китая, неожиданным для меня стали Танзания и UK

Уверен, что страны, из которых приходят атаки будут отличаться в зависимости от того, где сервер стоит. Наши тестовые VPS находятся в Москве.

Результаты по отдельным серверам

Моя гипотеза была в том, что объем атак будет равномерно распределен между серверами. Но нет, я ошибся. Больше всего атак пришлось на WPU, потом WPD и в конце DA.

Моя новая гипотеза в том, что причиной такого поведения стал WordPress.

У WordPress куча модулей, не все из них безопасны и это самая популярная в мире CMS — на WordPress самое большое число сайтов в мире. Даже сервера с голым WordPress без какого-либо контента или сайтов привлекают больше внимания ботов, чем сервер с Drupal. 

Разница между WPD и WPU в том, что на WPD работает WAF, но могло ли это стать причиной такой существенной разницы в количестве атак — сейчас я сказать не могу. Смущает, что сам WAF заблокировал очень мало запросов. Но, возможно, боты как-то его определяют и даже не пытаются продолжать запросы. Если вы в курсе — расскажите, пожалуйста.

Port Honeypot

Никакой сезонности или одинаковых паттернов не обнаружилось. Серверы атаковали хаотично, без очевидной логики. Были странно похожие колебания для DA, но они повторились всего лишь раз. Этого мало, чтобы сделать какие-либо выводы.

Синий — DA, зеленый — WPU, красный — WPD

Синий — DA, зеленый — WPU, красный — WPD

DoS Detection

Под DoS-атаки попал только сервер WPU. На остальных включен WAF, возможно дело в этом.

DoS-атаки на сервер WPU

DoS-атаки на сервер WPU

WAF

Общее количество атак на DA было меньше, чем на остальные сервера, но WAF отразил больше подключений. Но запросов мало, поэтому это, скорее всего, случайность.

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

Синий — DA, Красный — WPD. Синий намеренно притушил, чтобы было видно совпадение пиков.

Синий — DA, Красный — WPD. Синий намеренно притушил, чтобы было видно совпадение пиков.

Blocked packets

Рackets или «пакеты» — это единица измерения трафика, который генерируется IP-адресом. Каждый инцидент или запрос могут содержать разное количество пакетов, в зависимости от размера запроса. В терминологии BitNinja речь идет именно о HTTPS- пакетах.

Почему-то на DA количество дней с атаками было больше, чем на других серверах. При том, что пик достался WPU. Также как и в случае с заблокированными подключениями к портам.

Синий — DA, зеленый — WPU, красный — WPD

Синий — DA, зеленый — WPU, красный — WPD

Что дальше

Из результатов нашего тестирования атак за три месяца я сгенерировал несколько гипотез:

  • Даже пустой сервер подвергается атакам.

  • WordPress привлекает больше внимания атакующих, чем Drupal.

  • Иногда атаки проходят по всей сети провайдера, без цели захватить какой-то конкретный сервер.

  • Больше всего атак и блокировок приходится на запросы, взаимодействующие с портами сервера.

В планах прикрутить к серверам домены, завести на них сайты с формами и посмотреть, как изменится активность злоумышленников. А параллельно провести вторую фазу — активное тестирование по документации вендора.

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


ссылка на оригинал статьи https://habr.com/ru/articles/854658/