我有一个 pfSense 盒子充当我面向公众的路由器和状态防火墙。
在 NAT 后面有 1 个 WAN 接口和几个使用私有 IP 的 LAN 接口。
我希望在 WAN 接口上看到端口扫描或各种带有 Snort 的东西。
我不希望在其中一个 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 确实有能力保留一些状态信息以进行状态检查（称为流位），但签名是针对单个数据包进行处理的。这意味着源和目标不映射到客户端和服务器，它们直接映射到 IP 标头中的源和目标地址字段。因此，这意味着导致此规则触发的特定数据包的目标地址为 192.168.5.15，源地址为 165.98.148.2。我们在这里谈论的是单个数据包，它与发起会话的人无关。
其次，您的 NAT 设备使用 UDP 执行的操作比您想象的要多。TCP很容易。它是一个面向连接的协议。整个设计就是你们协商一个沟通环节，聊一会，然后说再见。整个过程非常明确，NAT 设备遵循这些标准。他们看到你的 SYN 出去并向 xlate 表添加一个条目，然后当 FIN+ACK 返回时，xlate 条目被删除，或者 FIN+RST 出去，或者足够的时间过去了。
UDP 是无连接的，只是火了就不管了。整个想法是应用程序要么实现自己的握手和/或重传系统，要么不需要它们。所以你会假设防火墙会允许你的 UDP 数据包出去，但任何响应都会被阻止。除了它没有。您的 NAT 设备知道即使像 UDP 这样的无连接协议也经常有双向通信。因此，它将像 TCP 一样为传出的 UDP 流量插入 xlate 条目。规则有点不同，例如我希望条目以不同的时间间隔超时，并且只有在超时时才被删除。
第三，此警报可能是由 Snort 的 sfPortscan 预处理器触发的。在严格限制的环境中，我可以看到它非常有用。否则它会很吵。问题在于它执行的检测类型
主要是因为#3 这个警报可以被任何实际提供服务的系统触发。出于某种原因，Windows SMB 文件服务器似乎是误报最严重的罪魁祸首。
现在这里是事情变得有趣的地方。让我们假设配置（服务器、网络和防火墙）都很好。在那种情况下，很可能是您的文件服务器启动了与外部 IP 的通信。然后返回的通信触发了 sfPortscan 预处理器，导致 pfSense 显示警报。这可能是一件坏事。如果我是你，我会开始捕获任何进/出你的文件服务器和外部地址的数据包。然后您可以开始查看数据包捕获并尝试弄清楚发生了什么。
UDP src/dest 很容易被 Snort 弄错。不知道更多关于流量是什么很难说。UDP 端口扫描规则在 VoIP 流量、DNS 请求和其他事情上总是失灵。如果您没有任何端口转发或 1:1 NAT 到该内部 IP，那么它不是来自远程 IP 的流量，而是来自本地 IP。