我有一个pfSense框充当我的公共路由器和状态防火墙。
有1个WAN接口和几个使用NAT后面的私有IP的LAN接口。
我期望在WAN接口上看到使用Snort的portscans或各种东西。
我不希望在其中一个LAN接口上看到这个SNORT警报。
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盒子上的任何东西都不应该是转发/路由/ NATing / PATING任何东西到内部地址。
我可以理解，如果我的内部机器正在与尼加拉瓜的IP进行通信，但是世界上的UDP数据报如何从WAN接口到LAN接口进行转发？
所以这里有一些事情我正在引起混乱。
首先，Snort是指源和目的地。 虽然Snort确实有能力保存一些状态信息（称为flowbits），但签名是针对单个数据包进行处理的。 这意味着源和目标不映射到客户端和服务器，它们直接映射到IP标头中的源地址和目标地址字段。 这就意味着引发这个规则的特定数据包在目标地址中有192.168.5.15，在源地址中有165.98.148.2。 我们在这里谈论的是一个单一的数据包，与谁发起会议无关。
其次，你的NAT设备在UDP方面比你想像的要多。 TCP很容易。 这是一个面向连接的协议。 整个devise就是谈判沟通，聊一会，然后说再见。 整个过程非常明确，NAT设备遵循这些标准。 他们看到你的SYN出去并在xlate表中添加一个条目，然后当FIN + ACK回来时，或者FIN + RST熄灭，或者足够的时间stream逝，xlate条目被删除。
UDP是无连接的，只是失火而已。 整个想法是，应用程序要么实现自己的握手和/或重发系统，要么不需要它们。 所以你会认为防火墙会允许你的UDP数据包出去，但是任何响应都会被阻塞。 除了没有。 你的NAT设备知道即使像UDP这样的无连接协议也经常有双向通信。 就像这样，它将像传输TCP那样为传出的UDPstream量插入xlate条目。 规则是有点不同，例如，我期望的条目超时在不同的时间间隔，只有当他们超时删除。
第三，这个警报可能是由Snort的sfPortscan预处理器触发的。 在一个严格限制的环境中，我可以看到它非常有用。 否则，可能会相当嘈杂。 问题在于它执行的检测types
很大程度上是因为＃3这个警报可以由任何实际提供服务的系统触发。 出于某种原因，Windows SMB文件服务器似乎是误报最严重的罪犯。
现在，这里是事情的乐趣。 假设configuration（服务器，networking和防火墙）都很好。 在这种情况下，您的文件服务器可能会启动与外部IP的通信。 然后，返回通信触发了导致pfSense显示警报的sfPortscan预处理器。 这可能是一件坏事。 如果我，我会开始一个数据包捕获任何文件到/从您的文件服务器和一个外部地址。 然后，您可以开始检查数据包捕获并尝试弄清楚发生了什么事情。
UDP src / dest很容易被Snort误解。 不知道更多的stream量是很难说的。 在UDPstream量，DNS请求和其他事情上，UDP端口扫描规则一直不能使用。 如果您没有任何端口转发或到该内部IP的1：1 NAT，则不是来自远程IP的stream量，而是来自本地IP的stream量。