值得努力阻止失败的login尝试

是否值得运行fail2ban ， sshdfilter或类似的工具，黑名单IP地址尝试和无法login？

我看到它认为这是一个“安全”的服务器上的安全剧场。不过，我觉得这可能使脚本小子移动到列表中的下一个服务器。

假设我的服务器是“妥善保护”的，我并不担心暴力攻击会真正成功 – 这些工具是否简单地保持我的日志文件清洁，还是我在阻止暴力攻击方面获得任何有价值的好处？

更新：关于蛮力猜测密码的评论很多 – 我提到我并不担心这一点。也许我应该更具体一些，并询问fail2ban是否对仅允许基于密钥的sshlogin的服务器有任何好处。

限制login尝试是防止某些高速密码猜测攻击的简单方法。但是，很难限制分布式攻击，而且很多攻击在数周或数月内以低速度运行。我个人更喜欢避免使用自动回复工具，如fail2ban。这有两个原因：

合法用户有时会忘记密码。我不想禁止合法用户从我的服务器，迫使我再次手动启用他们的帐户（或更糟的是，试图找出哪些100/1000禁止的IP地址是他们的）。
IP地址不是用户的好标识符。如果你有多个用户在一个IP之后（例如，一个在500台学生机器上运行NAT的学校），那么一个单一的用户做出一些不好的猜测就会让你陷入一个痛苦的世界。同时，我看到的大部分密码猜测尝试都是分布式的。

因此，我不认为fail2ban（和类似的自动化响应工具）是一个非常好的方法来保护服务器免受暴力攻击。一个简单的IPTables规则设置为减less日志垃圾邮件（我在我的大多数Linux服务器上）是这样的：

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

它可以防止在任何60秒的时间内从一个IP连接到ssh的4次以上的连接尝试。其余的可以通过确保密码相当强大来处理。在高安全性的服务器上强制用户使用公钥authentication是另一种停止猜测的方法。

像fail2ban这样的工具有助于减less不必要的networkingstream量，并使日志文件变得更小，更清洁。这不是一个很大的安全治疗 – 所有，但使系统pipe理员的生活更容易一些; 这就是为什么我build议在可以负担的系统上使用fail2ban。

它不仅仅是减less噪音 – 大多数ssh攻击尝试在密码上进行暴力猜测。所以，虽然你会看到很多失败的ssh尝试，也许到了第2034次尝试，他们可能会得到一个有效的用户名/密码。

与其他方法相比，fail2ban的好处在于它对有效连接尝试的影响很小。

那么，它可以在一定程度上节省您的networking拒绝攻击，并节省处理失败的开销。

不是脚本小子列表中最弱的服务器总是一件好事。

对不起，但我想说，如果您的sshd拒绝尝试使用密码进行身份validation，您的服务器已妥善保护。

 PasswordAuthentication no