☰

两天内 auth.log 中有 19,000 次 root 密码尝试失败？

tag-icon • tag-icon linux ssh authentication
两天内 auth.log 中有 19,000 次 root 密码尝试失败？

我正在调试一些登录问题，碰巧注意到我的 /var/log/auth.log 中有很多失败的 root 密码尝试。这是一个 VPS Linode。

我通过 grep 查找了过去两天的 19K 次尝试。

我知道我应该将 sshd 移至其他端口，但似乎很难记住和使用，而且需要更新一堆脚本。此外，攻击者难道不能只通过端口扫描来找到新端口吗？

我为 root 设置了一个非常强的密码，因此我并不是太担心。

我猜每分钟只有 6 次......所以可能不是一个性能问题。

但这似乎并不理想。

关于如何阻止或预防它，您有什么想法吗？

似乎来自一个相当小的 IP 地址列表...也许我可以阻止这些？我检查了几个，它们似乎在中国。

另一个选项是禁用 root 登录并使用唯一用户名设置 sudo 用户。但我不认为这会解决这个特定问题——人们仍然可以尝试以 root 身份通过 ssh 登录...

更新：使用默认设置安装 apt-get install fail2ban 后，我发现 auth.log 中的 root 尝试失败次数减少了 6-8 倍：

root@localhost:/var/log# grep "Failed password for root" auth.log | wc
    21301  327094 2261733
root@localhost:/var/log# grep "May  1.*Failed password for root" auth.log | wc
    6217   95973  664165
root@localhost:/var/log# grep "May  2.*Failed password for root" auth.log | wc
    8370  127280  880779
root@localhost:/var/log# grep "May  3.*Failed password for root" auth.log | wc
    1030   16250  111837

我还消除了 root ssh 密码验证，并按照以下步骤仅为 root 切换为基于密钥的登录：https://unix.stackexchange.com/questions/99307/permit-root-to-login-via-ssh-only-with-key-based-authentication

但这并不能阻止失败的密码条目出现在 auth.log 中。这只是意味着，即使他们知道密码，他们也无法通过。因此，fail2ban 减少了这些日志条目，而基于密钥的 root ssh 提供了真正的安全性。

最后，按照建议，我已将端口 22 列入 IP 白名单，以完全消除日志条目。作为参考，可以在 Ubuntu 上使用 ufw 完成此操作，如下所示：

apt-get install ufw
ufw allow from 127.198.4.3 to any port 22
ufw --force enable

我在其中使用 --force 是因为当我启动新节点时，我在脚本中以非交互方式执行此操作。

但是，为了处理来自我的动态 IP 的访问，并且不需要每次我的 IP 改变时都弄乱 Linode 的基于 Web 的 Lish 控制台，我使用了混合方法。

我有一台主服务器，托管我的主域，其他节点根据需要启动，作为子域上的子服务器。主服务器保存用于 ssh 进入子服务器的私钥。它也是 ssh 白名单中的 IP。

但是主服务器不使用 ssh 密钥，也不使用 IP 白名单。我希望能够在紧急情况下从任何地方访问它，即使我没有密钥文件，或者甚至从我不信任安装密钥文件的地方。我需要类似密码访问的东西，但在密钥记录或 ssh 受损的环境中是安全的。

我多年来一直在使用的解决方案是基于硬件的双因素身份验证，使用 YubiKey USB 设备和安装在主服务器上的 Yubico PAM 模块。

因此，即使攻击者拥有主服务器的 root 密码，他们也无法在没有我的 YubiKey 的情况下进入。而且 YubiKey 很容易随身携带。我可以从世界上最肮脏的网吧安全地访问我的服务器的 root 权限。

到达主服务器后，我可以无需密码通过 ssh 进入任何子服务器。

因此，我仍然需要在主服务器上使用 fail2ban，以减少 auth.log 条目。毕竟，子服务器上不需要它，因为 IP 白名单可以解决这个问题。

答案1

尝试阻止特定 IP 范围遭受暴力攻击并不是解决问题的理想方法。有许多僵尸网络和服务器不断扫描互联网并试图入侵服务器和设备。尝试阻止流量效率极低，因此最好的选择是减轻攻击或完全避免攻击。

减少您看到的连接数的一种方法是更改​​ SSH 端口。大多数攻击者采用散弹枪式攻击方法来入侵主机，因此只要您选择非标准备用端口，您就不会看到很多 SSH 尝试，除非是针对性攻击。扫描互联网上的所有端口需要花费大量时间，因此虽然这不是最好的方法，但可以将其视为缓解某些攻击的一种方法。

另一种缓解方法是设置类似 Fail2Ban 的功能，自动将多次验证失败的 IP 列入黑名单。这可以缓解部分攻击，但目前效果不佳，因为大多数暴力攻击都来自分布式主机。

处理 SSH 安全的最佳方法是限制对服务本身的访问。这可以通过将允许访问 SSH 端口的 IP 列入白名单，并设置基于密钥的身份验证，然后禁用密码身份验证来实现。如果攻击者无法访问 SSH 端口或从未有机会尝试密码，那么就不必担心暴力攻击。

答案2

我不会依赖较长的 root 密码。18 个字符不是很长，尤其是如果它主要是带有一些符号和数字的单词。

一般来说，允许在服务器（尤其是面向公众的服务器）上使用密码进行 root 登录不是一个好主意，原因如下：用户名很容易猜出，风险太大，而且有很多人使用脚本。

对所有用户都改用基于密钥的身份验证也不失为一个好主意。这在很大程度上消除了暴力攻击的威胁。

相关内容