虽然我还没有部署它，但我知道很多人已经部署了它。他们中的每一个人都注意到，SSH 蛮力攻击等事件消耗的带宽量因此而显着减少。

但是，这并不是说没有缺点。AFAIK，没有可用的基于内核的端口敲击实现，对我来说，这将是采用的真正关键。端口敲门守护程序依赖于从防火墙系统读取失败（和过滤/禁止）的日志文件条目。这一切都很好，但如果文件系统已满，会发生什么？当守护进程因为一些失控的进程耗尽系统的 RAM 和交换而被杀死时会发生什么？如果这两件事中的任何一个都依赖于其他东西并停止工作，会发生什么？您很可能最终会得到一台必须物理访问的服务器。这可能会比合理的成本更高，

我可以说的一件事是它不是“通过默默无闻的安全”。端口敲门是一种身份验证形式，与任何身份验证系统一样，它可以根据需要变得简单或复杂。可以完成诸如“敲击端口 10,000 + realPortNumber”之类的简单操作，这相当于一个微不足道的中断，或者端口敲击本身可能用于传输某种形式的真实身份验证（例如，给定 1 个 AES 编码数据块）由其他方法派生的密钥）。但是，使用端口敲击来传输大量数据是不可行的，因为它比仅发送单个数据包花费的时间要长得多，而且如果数据包是通过 TCP 传输的，那么至少可以知道它是否被成功接收或遇到某种形式的错误。

然而，这带来了一个有趣的问题，即如何管理日志文件——用户态实现主要需要日志文件来确定是否已成功发送敲门，如果这些日志泄露会发生什么？身份验证数据变得已知，这显然不是一件好事。

我不能告诉你是否在你的设置中使用端口敲门。我还没有，我也不是 100% 肯定我会。对我来说，使用基于强密码学（例如 PKI 基础设施）的强身份验证系统比使用端口敲门更有意义。此外，无论如何，添加单点故障来访问关键基础设施对我来说似乎是一个坏主意，并且更难以通过任何形式的保证来正确支持。不过，这同样是基于端口敲门软件未在操作系统内核级别与防火墙集成的概念；如果这种情况发生变化，我也可能会改变我对使用它的感觉。

端口敲门不仅仅是另一个纯文本密码 - 至少在用于保护侦听 TCP 端口（如 SSH）的服务时。端口敲击意味着不再可能使用 nmap 进行服务发现，因为使用了默认丢弃防火墙策略。SSHD 也存在可远程利用的漏洞，这些漏洞与弱密码无关。我不希望任何人能够启动 nmap 并看到我有 SSHD 监听。

此外，还有一种更强大的端口敲门变体，称为“单包授权”，但它也是一种完全被动的身份验证方案，因此它保留了端口敲门的优点，但解决了其局限性（重放攻击容易，DoS 攻击容易等） .)。

一个很容易验证的事实是，所有面向 Internet 的服务都相对经常存在安全漏洞 - 诸如 SSH、OpenSSL 等服务。对这些服务的攻击在 Internet 上被大量尝试，针对任何具有合适开放端口的系统。

在我看来，端口敲门的目的是让这些正在寻找通用漏洞的随机攻击者远离互联网。也就是说，它不应该阻止专门的攻击者，或构成服务实际安全性的任何部分。端口敲门的好处应该是，它确实足够简单，以至于它不可能有任何可利用的错误。

这种用法意味着端口敲门可以尽可能松懈，只要它能阻止大多数攻击者。它可能只是默默无闻的安全性，但更好的方法是将其作为“密码”身份验证的弱形式。

因此，“最好的”端口敲门服务将是无法想象任何攻击的服务，但对于任何合法用户来说都可以从任何类型的客户端机器上使用它是微不足道的。

根据我在其他地方的评论，尽管有很多实现使用各种特殊技巧来响应敲门声，但它可以在 Linux 系统上纯粹使用 iptables来实现。即这实际上是一个基于内核的端口敲击实现

由于敲击在网络上是可见的，使用超过 3 次敲击的序列几乎没有什么好处。我建议使用 TCP——虽然它会更慢，但你可以更好地保证敲门声已经送达。

然而，虽然它依赖于用户空间程序，但我更喜欢fail2ban，因为它不需要额外的步骤/软件来连接，可靠地运行，如果它确实失败了，它不会阻止我访问服务器。

让我感到惊讶的是加密身份的采用如此之少——尽管 RFC1413 仅提到这是一种使用协议的可能方法，而不是定义它应该如何工作。

但是当然你应该确保你已经尽可能地独立于这个限制访问（即没有root登录，限制对指定组的访问，如果可行，需要密钥对）。SSH 被设计为安全的——从历史上看，主流实现中的漏洞相对较少。攻击成功的原因通常归结为可猜测的用户名、简单密码和暴力攻击或社会工程的组合。请注意，我并不主张您强制执行复杂的密码验证（最小长度除外），也不是您要求用户不断更改密码，有更好的方法（例如两因素），但不幸的是很少有实现。