☰

pfSense 和 Snort：接口上出现意外的端口扫描流量

tag-icon • tag-icon pfsense snort port-scanning
pfSense 和 Snort：接口上出现意外的端口扫描流量

我有一个 pfSense 盒子作为面向公众的路由器和状态防火墙。

有 1 个 WAN 接口和几个使用 NAT 后面的私有 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/PAT 到该内部地址。

如果我的内部机器正在与尼加拉瓜 IP 通信，我可以理解，但 UDP 数据报究竟是如何在没有转发的情况下从 WAN 接口传输到 LAN 接口的呢？

答案1

所以，我认为，这里发生的一些事情造成了混乱。

首先，Snort 所说的源和目标是什么意思。虽然 Snort 确实有能力保留一些状态信息以进行状态检查（称为流位），但签名是针对单个数据包进行处理的。这意味着源和目标不映射到客户端和服务器，而是直接映射到 IP 标头中的源和目标地址字段。因此，这意味着导致此规则触发的特定数据包的目标地址为 192.168.5.15，源地址为 165.98.148.2。我们在这里谈论的是单个数据包，它与谁发起了会话无关。

其次，NAT 设备使用 UDP 执行的操作比您想象的要多。TCP 很简单。它是一种面向连接的协议。整个设计就是您协商一个通信会话，聊一会儿，然后说再见。整个过程定义得非常明确，NAT 设备遵循这些标准。它们看到您的 SYN 发出后，会将一个条目添加到 xlate 表，然后当 FIN+ACK 返回或 FIN+RST 发出或经过足够长的时间时，xlate 条目会被删除。

UDP 是无连接的，即发射后不管。整个想法是，应用程序要么实现自己的握手和/或重传系统，要么不需要它们。因此，您会认为防火墙会允许您的 UDP 数据包发出，但任何响应都会被阻止。但事实并非如此。您的 NAT 设备知道，即使是像 UDP 这样的无连接协议也经常有双向通信。因此，它将像 TCP 一样为传出的 UDP 流量插入 xlate 条目。规则略有不同，例如，我希望条目在不同的间隔内超时，并且仅在超时时被删除。

第三，这个警报是大概由 Snort 的 sfPortscan 预处理器触发。在严格限制的环境中，我发现它非常有用。否则，它可能会非常嘈杂。问题在于它执行的检测类型

  1. TCP/UDP 流量，其中一个主机与另一个主机通信并访问多个端口
  2. TCP/UDP 流量，其中多台主机与一台主机通信并访问多个端口
  3. TCP/UDP/ICMP 流量，其中一个主机通过单个端口与多个主机通信

很大程度上是因为第 3 条，几乎任何实际提供服务的系统都可以触发此警报。出于某种原因，Windows SMB 文件服务器似乎是误报率最高的系统。

现在事情变得有趣了。让我们假设配置（服务器、网络和防火墙）都很好。在这种情况下，您的文件服务器很可能发起了与外部 IP 的通信。然后返回的通信触发了 sfPortscan 预处理器，导致 pfSense 显示警报。这可能是一件坏事。如果我是你，我会开始对任何往返于你的文件服务器和外部地址的数据包进行捕获。然后你可以开始查看数据包捕获并尝试找出发生了什么。

答案2

Snort 很容易将 UDP 源/目标搞错。如果不进一步了解流量，很难说。UDP 端口扫描规则在 VoIP 流量、DNS 请求和其他事情上总是失败。如果您没有任何端口转发或 1:1 NAT 到该内部 IP，那么它不是来自远程 IP 的流量，而是来自本地 IP。

相关内容