Согласно manual.snort.org, TCP Portscans передается с одного компьютера на другой, но если вы посмотрите на предупреждение TCP Portcan в snort / snorby, вы увидите следующее:
В одной руке: Источник: 136.238.4.165 Dest: 10.19.0.5
С другой стороны: Priority.Count: .5.Connection.Count: .18.IP.Count: .1.Scanner.IP.Range: .10.10.28.88: 136.238.78.44.Port / Proto.Count: .6.Port / Proto.Range: .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.
Как мне понять эту информацию? Какое устройство запустило сканирование?
Я думаю, вы слишком зацикливаетесь на терминологии TCP-соединения и на том, как это связано с тем, что Snort подразумевает под источником и местом назначения.
Хотя у Snort есть возможность хранить некоторую информацию о состоянии для проверки с отслеживанием состояния (называемой потоковыми битами), сигнатуры обрабатываются для отдельных пакетов. Это означает, что источник и назначение не сопоставляются с клиентом и сервером, они сопоставляются непосредственно с полями адреса источника и назначения в IP-заголовке. Это означает, что конкретный пакет, вызвавший срабатывание этого правила, имел 10.19.0.5 в поле адреса назначения и 136.238.4.165 в поле адреса источника. Здесь мы говорим об одном пакете, он не имеет ничего общего с тем, кто инициировал сеанс.
Также помните, как работает препроцессор sfPortscan. Его алгоритм обнаружения на самом деле просто проверяет 3 шаблона:
Во многом из-за № 3 это предупреждение может быть вызвано практически любой системой, которая действительно предоставляет услугу. По какой-то причине файловые серверы Windows SMB кажутся худшими нарушителями ложных срабатываний. Это делает препроцессор sfPortscan исключительно шумным. Настолько шумно, что, если у вас нет жестко ограниченной сети и нет опыта для значительной настройки вывода, почти даже не стоит включать этот препроцессор.