☰

安全审查：对 ssh 登录尝试进行分类

tag-icon • tag-icon ssh security logs aws
安全审查：对 ssh 登录尝试进行分类

我看到我自己的 ssh 登录 AWS EC2 Ubuntu Linux 实例为

Nov 18 07:32:21 ip-10-20-30-40 sshd[9487]: Accepted publickey for ubuntu from 15.26.37.48 port 46273 ssh2: RSA SHA256:e37A/qiEdkHHNpeksdPO

当我运行很少寻找漏洞的命令

ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log
ubuntu@ip-12-34-56-78:~$ egrep "Failed|Failure" /var/log/auth.log
ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log | awk '{print $11}' | uniq -c | sort -nr
ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure"
ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=sshd.service | grep "failure"

什么也没有出现。到目前为止，一切都很好。

但是当我浏览日志文件时，我发现两个可疑问题。首先，我看到“身份验证失败”：

ubuntu@ip-12-34-56-78:~$  grep "authentication failure" /var/log/auth.log

Nov 14 09:23:19 ip-12-34-56-78 sshd[9711]: Disconnecting authenticating user root 98.76.54.32 port 36745: Too many authentication failures [preauth]
Nov 14 09:23:22 ip-12-34-56-78 sshd[9713]: Disconnecting authenticating user root 98.76.54.32 port 36754: Too many authentication failures [preauth]
Nov 16 11:45:29 ip-12-34-56-78 sshd[20710]: Disconnecting invalid user admin 15.48.27.78 port 51289: Too many authentication failures [preauth]

其次，即使我通过 ssh 进行连接，也会出现如下所示的行。ssh -i myKeyPair.pem [email protected]

Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session closed for user root

Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Invalid user stuart from 34.55.89.144 port 32946
Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Connection closed by invalid user stuart 34.55.89.144 port 32946 [preauth]

Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Invalid user ubnt from 21.34.55.89 port 56171
Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: error: Received disconnect from 21.34.55.89 port 56171:14: Unable to connect using the available authentication methods [preauth]
Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Disconnected from invalid user ubnt 21.34.55.89 port 56171 [preauth]

Nov 17 12:39:00 ip-12-34-56-78 sshd[32695]: Did not receive identification string from 233.55.89.13 port 54959

Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Received disconnect from 144.233.55.89 port 42056:11: Normal Shutdown, Thank you for playing [preauth]
Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Disconnected from invalid user sinusbot 144.233.55.89 port 42056 [preauth]
Nov 17 23:52:24 ip-12-34-56-78 sshd[1398]: Invalid user sinusbot from 144.233.55.89 port 57180

我不确定很多问题：

  1. 这句“谢谢你玩”到底开什么玩笑？这不是一个错误的游戏服务器；而是一个错误的游戏服务器。是吗？
  2. 有很多像“stuart”这样的用户看起来像是自动尝试“碰运气”。难道这只是机器人吗？
  3. 是否有配置可以阻止这些尝试出现或被处理？
  4. 过去，我曾经通过 ssh-keygen 生成一个文件，然后将其复制/粘贴到远程服务器，但现在我使用 AWS 的.两者在安全性上是平等的，因为任何获取 pem 文件或私钥的人都可以不受阻碍地进入。我说得对吗？ssh -i myKeyPair.pem [email protected]
  5. 最重要的是：我记得我选择了公钥 ssh 作为我唯一的身份验证方法，但我也在 AWS 设置上尝试过这个和那个。我可以运行什么测试来持续确认我和其他人都没有在 ssh 中打开除公钥之外的任何内容？

答案1

1 到 3 的简答题

对于一个不太混乱的分析，我发现last -i和lastb -i是不可或缺的。

  • 该preauth符号表明登录尝试失败。

  • 这谢谢你来玩符号有点管理员的幽默感。

  • 所有失败的尝试都会被记录。

  • 正如您所说，“大门”对互联网开放......因此，除非您配置端口碰撞，否则世界上的每个主机都“到达了大门”。

一般来说，如果公钥是ssh您的配置的唯一身份验证方法，则脚本机器人几乎无法攻击。但是，您每月可能会尝试数千次，甚至更多。

如果您担心此类尝试，您可以安装并配置失败2禁止。

更长的答案和欢迎来到矩阵

机器人和唾手可得的成果

大多数经验不足的管理员在开始查看日志文件时可能会感到恐慌。我知道当我有了我的问题时，我开始问许多与您发布的问题相同的问题。这是对互联网上看似无穷无尽的黑客攻击的常见反应。

我的技术朋友和同事向我保证，我看到的不是有针对性的攻击，大部分是自动脚本检查容易实现的目标。而它是......

有一系列用户名和密码列表，可以在各种信誉较差的地方进行买卖。运行脚本机器人的个人购买一个或多个这些列表，并使用它来尝试访问特定子网内的任何计算机，甚至可能爬行整个 IPv4 地址空间。

这就是为什么您会看到一系列大约一百个名称，例如：弗雷德、莎莉、乔治……等等……您甚至可能会看到您的名字或类似的内容。对于您可能运行的其他服务（例如电子邮件）也是如此。如果您查看该/var/log/mail.log文件，您将看到相同类型的用户名和密码组合黑客尝试。

这些攻击都是机器人。如果您在服务器上配置了合理的安全措施，则不太可能因ssh黑客尝试而受到损害。

SSH 密钥

SSH 密钥对具有公共组件和私有组件。私有组件永远不应该被分发。公共组件应放置在目标服务器的~/.ssh/authorized_keys文件中。

在公钥身份验证期间，私钥和该密钥的密码都不会通过连接传输。一旦进行身份验证，ssh就使用商定的对称会话密钥对会话进行加密。窃取了您的私钥的攻击者仍然需要找出您的密码。并且攻击者应该无法在不损害存储私钥的计算机的情况下嗅探该密码。

SSH 密钥是加密对象，因此会受到算法日落日期和/或在任何给定算法的整个生命周期中发现的漏洞的影响。因此，确保经常更新服务器软件并检查用户密钥是否有任何新发现的问题非常重要。

截至撰写本文时，标准算法似乎仍然是 RSA 2048。AWS 密钥脚本根据以下内容生成 RSA 2048 密钥AWS 文档。不过，我已将所有密钥更改为 Curve 25519，因为这些密钥要短得多，而且该算法据称是独立于任何国家机构或可能受到损害的实体开发的。

服务器审计和记录保存

由于您已经表明您在一开始就启用了 ssh 公钥身份验证，并且还禁用了密码身份验证，因此没有理由怀疑远程攻击者已禁用公钥身份验证。确实如此，除非您的 AWS 账户本身已被泄露。但是，您可能会收到一些有关用于访问您的 AWS 账户的意外 IP 地址的通知。

如果您想要更长的日志记录，您可以延长日志文件的保存时间logrotate和/或安装审计。

您的配置的健全级别

适用于小型/个人服务器的 Sane ssh 安全措施

  • 公钥认证和仅公钥认证
  • 禁用 root 用户的 ssh 访问
  • 仅对sudo需要 root 权限的用户启用
  • 使用至少 2048 位的 RSA 密钥，或 Curve 25519 密钥
  • 切勿将私钥材料放在服务器上
  • 除非绝对需要，否则禁用 X11 转发

对于大多数新安装，唯一应该更改的设置是启用公钥身份验证和禁用 X11。

/etc/ssh/shhd_config

...
PermitRootLogin no
...
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
...

疯狂的 ssh 安全

除了上述内容之外，还可以启用端口敲门、将主机密钥限制为单一算法（例如 Curve 25519）、将服务器的主机密钥指纹放入域的 DNS 记录中，并使用 DNSSEC 保护该记录。

  • 要限制服务器的主机密钥，只需取消注释您将使用的算法并重新启动服务器即可sshd。请注意，一旦完成此操作并且您尝试再次连接，主机密钥将不匹配。按照连接尝试替换本地存储的主机密钥指纹时的说明进行操作。

/etc/ssh/sshd_config

...
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
...
  • sshfp要为选定的主机密钥生成DNS 记录：

ssh-keygen -r domain.tld -f /etc/ssh/ssh_host_ed25519_key

生成的记录可以放置在您域的 DNS 区域文件中，并且ssh连接将检查该指纹。这可以防止首次连接时或服务器主机密钥更改时对 ssh 的中间人攻击。

并按照文档进行配置：

knockd is a port-knock server.  It listens to all traffic on an ethernet (or PPP) interface, looking for special "knock" sequences of port-
hits.  A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server.  This port need not be open -- since knockd
listens  at the link-layer level, it sees all traffic even if it's destined for a closed port.  When the server detects a specific sequence
of port-hits, it runs a command defined in its configuration file.  This can be used to open up holes in a firewall for quick access.

....

[options]
     logfile = /var/log/knockd.log

[openSSH]
     sequence    = 7000,8000,9000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -A INPUT -s %IP% --dport 22 -j ACCEPT

[closeSSH]
     sequence    = 9000,8000,7000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -D INPUT -s %IP% --dport 22 -j ACCEPT
  • DNSSEC 配置此处不再详述。然而，重要的是要记住 DNS 欺骗是 DNSSEC 解决的一个真正问题。

相关内容