У меня есть ящик pfSense, работающий как мой общедоступный маршрутизатор и межсетевой экран с отслеживанием состояния.
Существует 1 интерфейс WAN и несколько интерфейсов LAN, использующих частные IP-адреса за NAT.
Я ОЖИДАЮ увидеть сканирование портов или другие вещи с Snort на интерфейсе WAN.
Я не ожидаю увидеть это предупреждение SNORT на одном из интерфейсов LAN.
Attempted Information Leak
PSNG_UDP_PORTSCAN
SRC: 165.98.148.2 (some Nicaraguan IP)
DST: 192.168.5.15 (a linux file sever on the LAN)
У меня нет переадресации портов на 192.168.5.15. Фактически, ничто в поле pfSense вообще не должно пересылать / маршрутизировать / NAT / PAT что-либо на этот внутренний адрес.
Я мог понять, связывалась ли моя внутренняя машина с никарагуанским IP-адресом, но как вообще дейтаграммы UDP переходят из интерфейса WAN в интерфейс LAN без пересылки?
Так что здесь происходит несколько вещей, которые, я думаю, вызывают путаницу.
Во-первых, что Snort подразумевает под источником и местом назначения. Хотя у Snort есть возможность хранить некоторую информацию о состоянии для проверки с отслеживанием состояния (называемой потоковыми битами), сигнатуры обрабатываются для отдельных пакетов. Это означает, что источник и назначение не сопоставляются с клиентом и сервером, они сопоставляются непосредственно с полями адреса источника и назначения в IP-заголовке. Это означает, что конкретный пакет, который вызвал срабатывание этого правила, имел 192.168.5.15 в адресе назначения и 165.98.148.2 в адресе источника. Здесь мы говорим об одном пакете, он не имеет ничего общего с тем, кто инициировал сеанс.
Во-вторых, ваше устройство NAT делает с UDP больше, чем вы думаете. ПТС - это просто. Это протокол, ориентированный на соединение. Весь дизайн заключается в том, что вы договариваетесь о сеансе связи, некоторое время болтаете, а затем прощаетесь. Весь процесс очень четко определен, и устройства NAT соответствуют этим стандартам. Они видят, что ваш SYN выходит, и добавляют запись в таблицу xlate, затем запись xlate удаляется, когда возвращается FIN + ACK, или FIN + RST выходит, или проходит достаточно времени.
UDP, будучи без установления соединения, просто запустил и забыл. Вся идея состоит в том, что приложение либо реализует собственную систему квитирования и / или ретрансляции, либо оно ему не нужно. Таким образом, вы могли бы предположить, что брандмауэр позволит вашему UDP-пакету выйти, но любой ответ будет заблокирован. Но это не так. Ваше устройство NAT знает, что даже протокол без установления соединения, такой как UDP, часто имеет двустороннюю связь. Таким образом, он будет вставлять записи xlate для исходящего UDP-трафика, как и TCP. Правила немного отличаются, например, я ожидал, что время ожидания записей истечет с другим интервалом и будет удалено только по истечении времени ожидания.
В-третьих, это предупреждение наверное запускается препроцессором sfPortscan для Snort. В жестко ограниченной среде я вижу, что это весьма полезно. В противном случае может быть довольно шумно. Проблема заключается в типах обнаружений, которые он выполняет.
Во многом из-за № 3 это предупреждение может быть вызвано практически любой системой, которая действительно предоставляет услугу. По какой-то причине файловые серверы Windows SMB кажутся худшими нарушителями ложных срабатываний.
И вот здесь самое интересное. Предположим, что конфигурации (сервер, сеть и брандмауэр) все в порядке. В этом случае, скорее всего, ваш файловый сервер инициировал связь с внешним IP-адресом. Затем обратная связь запустила препроцессор sfPortscan, который заставил pfSense отобразить предупреждение. Наверное, это плохо. Если бы я был вами, я бы начал захват пакетов для всего на ваш файловый сервер и с внешнего адреса. Затем вы можете начать просматривать захваченные пакеты и попытаться выяснить, что происходит.
UDP src / dest может легко ошибиться Snort. Трудно сказать, не зная больше о трафике. Это правило сканирования портов UDP постоянно дает сбой при обработке трафика VoIP, DNS-запросов и других вещей. Если у вас нет перенаправления портов или NAT 1: 1 для этого внутреннего IP-адреса, значит, это трафик не с удаленного IP-адреса, а с локального IP-адреса.