我设置了一个端口敲击方案，使用 iptable 规则保护端口 22。除此之外，我还设置了一些“蜜罐”规则，如果客户端击中未使用的公共端口（例如端口 21）或敲击序列周围的端口，则禁用客户端的端口敲击几分钟。这似乎很有效（我相信这是比将端口更改为模糊端口更好的选择）。对于 SSHD，密码登录无论如何都是禁用的 - 需要加密的私钥/公钥组合。
在这一页有一个“滴水盘”方案，如果未使用的端口被命中，客户端在 60 秒内无法与任何东西（甚至是开放端口）通信。我最担心的是“--hitcount 3”似乎由对单个端口的任何简单请求触发。
所以我的问题是，你对这种设置有什么看法？Web 服务器上的“滴水盘”是否太多，还是恰到好处？除了保持进出策略并仅打开需要的内容外，你们还有其他防火墙安全建议吗？
编辑：我使用的是 CentOS 5.7。我们假设“在合理范围内尽可能安全”。服务器必须通过 PCI/SAS 合规性（和其他类似标准）。重点是防火墙，不一定是可能被发现的单个服务的漏洞（这是另一个话题）。我遗漏了与防火墙或外部任何事物相关的任何内容。希望尽可能使攻击者难以获得访问权限。
答案1
这完全是主观意见，但我从来没有对港口敲门那么感兴趣。
感觉有点像临时解决办法，我总是担心会有那么一天，它会完全停止按预期工作，或者我会发现一个极端情况，将我锁定在系统之外。
我发现，如果禁用密码验证并仅使用 SSH 密钥对，我很少看到同一个机器人多次尝试端口。当有这么多其他主机可供尝试和控制时，这不切实际。除非人们停止允许 root SSH 登录并完全放弃密码验证，否则唾手可得的果实仍然存在，可供网络犯罪分子采摘。
在防火墙处，我通常会断开与 TCP 22 的连接，除了少数位置之外，因为我很少在需要直接访问盒子的地方（我只会通过 VPN 连接到可以访问的位置）。
我假设这是一个 Web 服务器，对吧？花点时间了解 Web 应用程序的要求。典型的状态防火墙几乎无法防御通过端口 80 发生的攻击，如 SQL 注入、XSS 等。
我还会设置一些强大的日志记录（如果您正在运行数据库，则记录所有 SQL 查询；为您的防火墙日志、Web 服务器日志、auth.log、系统日志、Web 服务器日志等设置远程系统日志）
我会在另一个主机上设置代理服务器（如果可以的话），并在防火墙处丢弃来自 Web 服务器的所有内容。当/如果您的机器被控制，攻击者将无法在 Internet 上建立直接 TCP/UDP 连接（通常攻击者想要做的第一件事就是获取您系统的 shell），如果您的警报已到位，您会立即知道。
唯一应该允许的传出 HTTP 流量应该通过代理服务器退出，并且您（至少对于服务器）应该有一个可以允许的域白名单（例如包管理存储库）。
这样做会大有裨益；假设你会被拥有，并制定相应的计划和防御。