#1313: Некорретная работа СОВ или некоторые принципы работы СОВ

Отредактирована: 676 дней назад

Симптомы

СОВ отрабатывает выборочно, регистрирует скан портов из внутренней сети.
С хоста, расположенного в зоне Untrusted запущена служба nmap в активном режиме, с указанием диапазона портов (nmap -A -p 21-65535 81.211.74.179).

В журнале СОВ обнаружены только два типа событий:

  2.1 Обнаружение сканирования SIP.

  2.2 Обнаружение сканирования RDP.

При этом, во всех событиях порт назначения TCP - всегда один и тот же - 10053.

Решение

Расхождение в результатах сканирования и журналах СОВ связано в первую очередь с тем, что UG не выполняет инспектирование трафика некоторых своих сервисов:

  • CLI over SSH (2200)
  • Web-console (8001)
  • Сервиса репликации настроек кластера (4369,9002)

Полный список зарезервированных портов, которые не подвержены инспекции СОВ:

  • 2200, 8001, 4369, 9000-9100

Это сделано с целью предотвратить потерю контроля над устройством или распад кластера при некорректной работе модуля СОВ или его сигнатур. Также это поведение справедливо для отдельных модулей, которые включаются через CLI, например для модуля SIP (5060). К сожалению, на данный момент это реализация by design и изменить это поведение со стороны пользователя не представляется возможным.

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

Большое количество сработок на 10053ий порт, как уже упоминалось ранее, связано с тем, что внутренний сервис DNS UG перенаправляет все запросы, направленные на порт 53 скриптами nmap, именно на порт 10053, после чего трафик попадает в СОВ.

Отсутствие сработки сигнатуры SSH на сторонних tcp портах связано с тем, что сигнатура срабатывает только при обнаружении ответе порта на инициализацию SSH-handshake, чего не происходит с тем же портом 53. Вы можете проверить сработку данной сигнатуры, выполнив сканирование хоста, расположенного за UG - она будет обнаружена в транзитном трафике при сканировании соответствующего порта.

Отсутствие сработки сигнатуры OS scan связано с тем, что в зависимости от ОС, nmap может не отправлять tcp/udp-payload, а использовать косвенные признаки - номера seq и ack, TTL. В таких случаях сработки также не происходит.