我们有一个由硬件防火墙保护的八节点IIS Web服务器场。 防火墙configuration为允许端口80的stream量入站，但设置为阻止出站stream量。
在我们的防火墙日志中，我看到很多拒绝连接的实例，它们的src / srcname是其中一个web服务器， src_port是80 ，dst / dstname是随机IP，dst_port是30000+
我是一个具有软件后台（不是IT / devops）的人，我的理解是，所有的HTTPstream量都应该由源端口上的源客户端发起，目标IP是Web服务器，目的端口是80。
但防火墙日志显示相反，是否有一种情况下，这是有道理的？
为什么防火墙日志会显示通过防火墙从源端口80到某个高编号端口的出站连接？
编辑防火墙日志摘录： http ： //pastebin.com/RE7vrHAk
在您的Web服务器上引用端口80的TCP连接和在公共IP地址上的高编号端口听起来像从客户端到Web服务器的TCP连接。
你如何确定这些连接的发起者是你的Web服务器？ 你是否看到来自Web服务器端口80的TCP SYN？
我怀疑你的防火墙设备周期性地“失去了连接状态”，因为确定TCP连接的发起者的唯一方法是通过观察初始握手，防火墙不能可靠地期望报告“方向“这些连接。
你能告诉我们更多关于防火墙的信息吗，或者可以提供一些卫生的日志数据？
当然，你已经被一个试图与互联网通信的攻击者以一种可能将其stream量伪装成HTTP响应的方式进行攻击的可能性，但是Occam的Razor说，它实际上是响应stream量被你的防火墙误分类。 将stream量与您的Web服务器日志关联起来肯定有助于打破从Web服务器启动连接的理论。
编辑：
看起来你正在使用Fortigate防火墙。 我以前没有和其中一个人一起工作的乐趣，但我可以一般性地谈论这个。
看起来这是一个有状态的检查防火墙。 因此，它维护一个状态表，用于已经“看到”的连接，标识发起者，端口号，预期的TCP序列号以及从状态跟踪表中“超时”连接的生存时间（TTL）闲置了一段时间之后。 虽然我认为有可能这些连接处于打开状态，没有比TTLstream量更长的stream量，但似乎不太可能， 除非有人已经大幅度修改了默认的TTL。
在Fortigate中有一个有限的RAM来跟踪会话。 值得回顾一下日志和pipe理界面，看它是否可以报告正在跟踪的会话总数以及可跟踪会话的最大可能数量。
该日志数据完全具有状态防火墙的外观，该状态防火墙在状态表中丢失了连接。