在大多数操作系统中，处理 TCP 三向握手是操作系统网络代码的责任。应用程序只能通过 listen() 系统调用声明对接收某个端口上的连接感兴趣。如果有应用程序在端口上侦听，操作系统将使用 SYN/ACK 响应 SYN，否则使用 RST。没有应用程序对此有任何发言权。

这是默认行为。它可以被很多东西修改，包括但不限于主机上的包过滤机制。此外，TCP/IP 的专门实现可能会故意表现得不同。

当 NMAP 既没有收到 SYN/ACK 也没有收到 RST 来回复 SYN 数据包时，它会将该端口报告为“已过滤”。它无法确定没有收到回复的原因。相反，如果中间防火墙通过回复 RST 来阻止端口，则 NMAP 将报告该端口已关闭，即使探测数据包实际上从未到达其目的地。

总之，你的报价至少是不准确的。如果端口由于数据包过滤之外的其他原因而无法确定为打开或关闭，NMAP 也会将端口报告为已过滤。数据包过滤只是最常见的原因，因此已成为该结果的同名。更重要的是，当 NMAP由于介入的数据包过滤器而无法确定端口是打开还是关闭时，它甚至可能将端口报告为关闭。

通常，您和目标之间有多个设备。一路上，防火墙、路由器、交换机和其他网络设备可以限制您的数据包实际到达您的目标。基于主机的防火墙或应用程序访问控制也可能导致过滤响应。

有时，您会在 ICMP 错误消息的响应中收到来自过滤设备的响应，但在大多数情况下，数据包会在路由的某个地方被丢弃。

你的假设：

• 不可以。除非您在批准的列表中，否则 iptables 可以配置为根本不响应。或者 iptables 可以配置为完全不响应的主机/网络列表。
• 这取决于您如何定义安全设备。更好的术语是访问控制设备，因为它可能类似于路由器上的 ACL。
• 根据应用程序及其网络堆栈，这是可能的。具有用户陆地网络堆栈的应用程序可以选择如何处理请求而不是操作系统。

在尝试进入最简单形式的目标网络时：

互联网---防火墙---目标

您将通过至少 3 级过滤：

1. 防火墙
2. 在目标的操作系统级别
3. 在目标的应用程序级别

在每个级别，第一个 IP 数据包（以及任何其他协议数据包作为 ESP 或 AH 数据包）可能会收到 4 种类型的处理：

1. 数据包被简单地丢弃（不是任何形式的回复）
2. 数据包被丢弃并返回 ICMP 类型 3、代码 9 或 10，
3. 接收 TCP RST 数据包
4. 接收 TCP ACK 数据包

真正的网络是建立在这个基本的砖块上的。

这里有几个问题，让我试着改写一下，这样才能给出适当的答复。

问题 1.如果流量到达主机，系统会回复 SYN/ACK 还是 RST？

简短的回答 - 不一定，您可能会得到一个 ICMP 目标不可达（端口不可达），当没有进程在该端口上侦听时，这被认为是可接受的回复（RFC 1122，第 40 页和RFC 792，第 5 页）。您也可能根本得不到任何回复——不幸的是，并非每个人都遵守 RFC 规范。不幸的是，我见过用 FIN 回复 SYN 的实现！是的，它可能那么糟糕。

问题 2.每个设法到达端口的探测都会得到正确的答复吗？

简短的回答 - 不一定，跨操作系统的 TCP 堆栈实现会有所不同，例如，我见过资源有限的嵌入式系统已将侦听器进程换出，并且当进程恢复到内存时，窗口回复的机会已经结束。这是一个例外而不是规则，但您应该记住，并非每个人都会遵守该标准 - 有些可能具有内置的 SYN 洪水保护机制，可能会将来自同一主机的太多 SYN 段视为 DoS 尝试。

问题 3.应用程序可以忽略探测吗？

通常这不是应用程序的责任，而是负责这些事情的操作系统堆栈。这并不是说您不能实现自己的协议处理程序，但这种情况很少见。但我想说，很少有应用程序在其通信的 TCP 握手部分有发言权。

我希望这些答案对您有所帮助:-)