是否值得运行fail2ban , sshdfilter或类似的工具,黑名单IP地址尝试和无法login?
我看到它认为这是一个“安全”的服务器上的安全剧场。 不过,我觉得这可能使脚本小子移动到列表中的下一个服务器。
假设我的服务器是“妥善保护”的,我并不担心暴力攻击会真正成功 – 这些工具是否简单地保持我的日志文件清洁,还是我在阻止暴力攻击方面获得任何有价值的好处?
更新 :关于蛮力猜测密码的评论很多 – 我提到我并不担心这一点。 也许我应该更具体一些,并询问fail2ban是否对仅允许基于密钥的sshlogin的服务器有任何好处。
限制login尝试是防止某些高速密码猜测攻击的简单方法。 但是,很难限制分布式攻击,而且很多攻击在数周或数月内以低速度运行。 我个人更喜欢避免使用自动回复工具,如fail2ban。 这有两个原因:
因此,我不认为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