☰

Поле Snort, Portscans и Scanned IP Range

tag-icon • tag-icon log-files snort port-scanning
Поле Snort, Portscans и Scanned IP Range

Согласно manual.snort.org, сканирование портов TCP идет с одного компьютера на другой, но если вы посмотрите на оповещение сканирования портов TCP в snort/snorby, то увидите следующее:

В одной руке: Источник: 136.238.4.165 Назначение: 10.19.0.5

С другой стороны: Приоритет.Количество: .5.Количество.подключений: .18.Количество.IP: .1.Диапазон.IP-адресов.сканера:.10.10.28.88:136.238.78.44.Количество.портов/протоколов:.6.Диапазон.портов/протоколов:.199:58891.

Итак, с одной стороны у нас есть поля source и dest, которые говорят, что машина 10.19.0.5 была просканирована с 136.238.4.165. С другой стороны, Scanner IP Range говорит, что с 10.10.28.88 по 136.238.78.44 было сканирование до 10.19.0.5

Как мне понимать эту информацию? Какое устройство начало сканирование?

решение1

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

Хотя Snort имеет возможность сохранять некоторую информацию о состоянии для проверки состояния (называемую flowbits), сигнатуры обрабатываются по отдельным пакетам. Это означает, что источник и пункт назначения не сопоставляются с клиентом и сервером, они сопоставляются непосредственно с полями адреса источника и пункта назначения в заголовке IP. Таким образом, это означает, что конкретный пакет, который вызвал срабатывание этого правила, имел 10.19.0.5 в поле адреса назначения и 136.238.4.165 в поле адреса источника. Мы говорим об одном пакете, это не имеет никакого отношения к тому, кто инициировал сеанс.

Также имейте в виду, как работает препроцессор sfPortscan. Его алгоритм обнаружения на самом деле просто проверяет по 3 шаблонам:

  1. Трафик TCP/UDP, при котором один хост взаимодействует с другим хостом и затрагивает множество портов
  2. Трафик TCP/UDP, когда множество хостов взаимодействуют с одним хостом и попадают на множество портов
  3. Трафик TCP/UDP/ICMP, где один хост взаимодействует со многими хостами через один порт

Во многом из-за #3 это оповещение может быть вызвано практически любой системой, которая фактически предоставляет услугу. По какой-то причине файловые серверы Windows SMB, похоже, являются худшими нарушителями ложных срабатываний. Это делает препроцессор sfPortscan исключительно шумным. Настолько шумным, что если у вас нет жестко ограниченной сети и нет опыта для существенной настройки вывода, то включать этот препроцессор почти не стоит.

Связанный контент