我们有一个由硬件防火墙保护的八节点 IIS Web 服务器群。防火墙配置为允许端口 80 流量入站，但设置为阻止出站流量。
在我们的防火墙日志中，我看到许多被拒绝的连接实例，这些连接的 src/srcname 是其中一个 Web 服务器，src_port 为 80，一个随机 IP 的 dst/dstname 和一个 30000+ 的 dst_port
我是一个具有软件背景（不是 IT/devops）的人，我的理解是所有 HTTP 流量都应该由高源端口上的源客户端发起，目标 IP 是 Web 服务器，目标端口是 80。
但是防火墙日志显示相反的情况，是否存在这样的情况？
为什么防火墙日志会显示从源端口 80 通过防火墙到某个高编号端口的连接？
编辑防火墙日志摘录：http://pastebin.com/RE7vrHAk
答案1
引用 Web 服务器上的端口 80 和公共 IP 地址上的高号端口的 TCP 连接听起来就像从客户端到 Web 服务器的 TCP 连接。
您如何确定这些连接的发起者是您的 Web 服务器？您是否看到 TCP SYN 来自 Web 服务器的端口 80？
我怀疑您的防火墙设备以某种方式定期“丢失”连接状态，并且由于确定 TCP 连接发起者的唯一方法是通过观察初始握手，因此无法可靠地期望防火墙报告这些连接的“方向”。
您能否向我们详细介绍一下防火墙，并提供一些经过清理的日志数据？
当然，您有可能被攻击者入侵，攻击者试图以将其流量伪装成 HTTP 响应的方式与互联网通信，但奥卡姆剃刀原理表明，这实际上是被防火墙错误分类的响应流量。将流量与您的 Web 服务器日志关联起来肯定有助于消除它们实际上是从 Web 服务器发起的连接的理论。
编辑：
看起来你正在使用 Fortigate 防火墙。我以前没有用过这种防火墙，但我可以大致谈谈。
看起来这是一个状态检测防火墙。因此，它会维护一个状态表，用于记录它“看到”的连接，标识发起者、端口号、预期的 TCP 序列号以及生存时间 (TTL)，在连接空闲一段时间后，生存时间 (TTL) 会将该连接从状态跟踪表中“淘汰”。虽然我认为这些连接可能处于打开状态，没有流量流过，时间比 TTL 长，但似乎不太可能，除非有人修改了默认TTL，大幅降低。
Fortigate 中用于跟踪会话的 RAM 数量是有限的。有必要查看日志和管理界面，看看它是否可以报告正在跟踪的会话总数以及可跟踪会话的最大可能数量。
该日志数据完全看起来像一个状态防火墙，其状态表中已经丢失了连接轨迹。