LWN:建立一个SSH蜜罐!

Linux News搬运工

共 4538字,需浏览 10分钟

 ·

2021-03-31 14:23

关注了就能看到更多这么棒的文章哦~

Creating an SSH honeypot

March 11, 2021
This article was contributed by Marta Rybczyńska
FOSDEM
DeepL assisted translation
https://lwn.net/Articles/848291/

许多开发人员都会使用 SSH 访问自己的系统,因此 SSH 服务器就成为许多攻击的目标。在FOSDEM 2021会议期间,Sanja Bonic 和 Janos Pasztor 介绍了他们利用容器(container)来轻松创建 SSH 蜜罐的实验。所谓的蜜罐(honeypot)就是指一些假服务器,其管理员可以利用这个服务器来观察攻击者做了些什么,而不会真正威胁到生产系统(production system)。这场对话式的讲解向听众们介绍了设置 SSH 服务器来扮演蜜罐角色的过程,展示了 SSH 攻击都是什么样子,并就如何提高 SSH 服务器的安全性提出了一些建议。

蜜罐是一个可以接入网络的服务器,通常会故意降低一下防护能力(比普通服务器的防护能力更弱)。系统管理员们通过部署蜜罐来吸引攻击者,并记录他们的行动,这样管理员就可以分析这些行为,根据获得的信息来改进生产系统上的防御措施。蜜罐可能会让我们知道攻击者有什么新的攻破系统的方法,也可以用来让我们了解最常见的方法都是哪些。针对不同类型的服务器,蜜罐也会有各种不同的形式。Bonic 和 Pasztor 主要专注于提供可以被公众访问到的 SSH 服务器蜜罐。构建这样的蜜罐需要:SSH 服务器,允许攻击者进入的执行环境(其中任何破坏都不会带来损失),以及记录攻击者行动的所有信息的日志(审计,audit)系统。

他们先从日志系统(logging system)开始动手,毕竟它不仅仅用在蜜罐中。在大公司里,通常会记录这些审计痕迹(audit trails),"以防公司一些非常机密的东西被泄露出去"。Bonic 和 Pasztor 为他们的蜜罐选择的日志记录解决方案是 asciinema,一个记录和重放控制台会话(recording and replaying console sessions)的工具。asciinema 日志是各种 JSON 片段,易于解析。它开头是一个 header(包含格式版本和终端尺寸等信息);随后的所有数据每行都是一个包含三项的数组:时间戳、mode(输入或输出)和内容。有兴趣的读者可以在 asciinema 的示例页面上看到用这个工具可以做些什么。Bonic 和 Pasztor 最初的想法是可以后续将攻击者的步骤用类似视频播放的方式回放出来。

第二项需要配置的就是 SSH 服务器。Pasztor 介绍说已经有多个项目都在研究伪造 SSH 服务器,也就是模拟出一个环境,并给出模拟的结果。从蜜罐构建者的角度来看,问题在于该工具必须要模拟一个 shell,并且蜜罐还需要一个目录结构(当然还包括其文件中的内容)。Pasztor 说,提供所有这些必要文件的话,就相当于组装了一个虚拟机,而这不是一件容易的事情。他补充说,蜜罐需要阻止攻击者真正在机器上运行程序,因为这可能会导致安全问题。如果运行蜜罐的原因只是想看看攻击者在发布什么命令,一个伪装服务器就足够了。然而,如果要进行深入分析的话就需要更多信息。

他们决定使用一个标准的 SSH 服务(OpenSSH),但又将其创建的会话(session)重定向到一个独立的安全环境中去。Pasztor 解释说,他们最初的想法是使用 Docker,虽然它不像虚拟机那样与 host system 是隔离开的,但其仍然可以作为一个安全边界措施(create a security boundary)。只需要根据标准步骤安装好一个 SSH 服务之后在 sshd_config 中添加一行内容,就可以设置成在有人用 SSH 登录时运行就会运行一个 Docker 容器(container):

ForceCommand /usr/bin/docker run -ti ubuntu

docker 可执行文件的路径需要根据你的系统来相应调整,ubuntu 是将要使用的容器名称。Pasztor 说,当有人连接时,他们就会 "落到一个容器中,并且不能跳出容器"。

然而,如果再加上 asciinema(或者其他任何日志工具)会变成:

ForceCommand /usr/bin/asciinema rec /tmp/ssh.cast –c \
"/usr/bin/docker run -ti ubuntu"

这种方法增加了复杂性,而且容易出错。如果蜜罐想模拟执行在连接上实际发送的命令(被 ForceCommand 覆盖了),情况就会变得更糟。如果不注意的话,这种设置很容易通过 SSH_ORIGINAL_COMMAND 环境变量被注入命令,这个环境变量可能就包含了攻击者的命令(在它被 ForceCommand 替换掉之前就会执行)。如果这个变量没有经过适当的检测和处理,就会让攻击者获得对主机系统的访问权,这在蜜罐中是 "你绝对不希望发生的事情"。

为了解决这个问题,Pasztor 开发了 ContainerSSH,它允许 SSH 服务使用 HTTP API 与容器(或其他任意什么后端)对话。他们的幻灯片列出了 Docker、Podman 和 Kubernetes 这些都是能支持的后端,它们都提供了这样的 API。当用户连接到 ContainerSSH 时,服务器会使用这些 API 与后端对话,并启动一个新的容器来处理这个网络连接。ContainerSSH 可以连接到一个自定义的认证服务器,动态改变每个用户的配置。在蜜罐这个场景中,他们使用了一个选项将审计日志发送到 asciinema,另一个选项来让 ContainerSSH 接受任意用户登录(也就是不需要通常必需的有效账户和密码)。

他们将服务器部署上线之后,开始收到各种奇怪的错误信息,而不是他们原本期望看到的 console 日志。Pasztor 感到很困惑。后来发现,原来大多数攻击者都是机器人。他们倾向于直接通过 SSH 发送命令,而不是启动一个控制台会话(console session),但最初的蜜罐配置是针对人类登录这种场景设计的,用于记录 console session 的。为了解决这个问题,他们改用不同的格式来记录审计日志。新的格式是二进制的文件,记录了一切信息(包括密码)。这一次的日志包含了查看正在发生事情的所需信息。

有些攻击者只是运行一个程序来获取输出信息。他们希望得到系统的信息,例如 CPU 的类型。一半的攻击者只是检查了一下密码,并没有做其他事情。其他人则做了 Bonic 和 Pasztor 没有预料到的事情。例如,一些攻击者使用 SSH 文件传输协议(SFTP)上传一些文件,解压后再运行产生的程序,最后删除他们留下的痕迹。

Pasztor 看到一种 “非常有趣” 的攻击。攻击者会查找 GSM 设备,或查找直接连接到这个系统的手机(可以通过/dev/ttyGSM*等设备文件访问到的那些)。对于没有在传统 IT 行业或数据中心工作过的人来说,可能很难理解为什么有人会将手机连接到 SSH 服务器上。Pasztor 解释说,许多系统管理员使用电话或 GSM 设备来发送警报信息。如果互联网访问中断了,这样的设置就很有用了,毕竟手机可能还能工作,可以向管理员发送消息。而攻击者可能想做的事情就是利用这些监控手机来发送垃圾信息。

Pasztor 说,现在跟以前的 SSH 攻击很不一样了。现在很多编程语言里都提供了 SSH library 或 SFTP module。这使得攻击者很容易就进行一些复杂的工作。例如攻击者会建立一个单一连接(single connection),所以连接速率限制(connection-rate limits)不会对他们形成制约。利用这一个单一连接,他们自己创建多个通道(multiple channels)来执行他们的攻击程序。

讲座接下来提出了一些对于想要运行 SSH 服务的人的建议。首先是改变服务器使用的端口(默认是 22)。一旦改变了端口号,系统就很少会看到攻击了。Bonic 记得在 10 年或 15 年前读到过关于端口重新编号的建议,她说这个建议如今仍然有效。不过,它只能阻止机器人,而不能组织那些有针对性的定向攻击(directed attack)。

他们的第二个建议是使用密钥进行身份验证,"如果可以的话,应该完全禁用密码"。如果有必要保留密码,一个好的做法是避免使用那些常见组合,比如 test 作为用户名以及 test 作为密码。他们看到过有的案例中由于使用了默认密码,然后攻击者在 20 分钟内就进入了系统。最后,SSH 私钥应该用密码保护起来。如果发生了有针对性的攻击(targeted attack),往往会跟开发人员的笔记本电脑有关,因为开发人员通常拥有较高的权限,并且可以直接访问生产系统。如果该笔记本电脑中含有未受保护的密钥,那么攻击者就有了进入服务器的捷径。在提问环节,一些听众不同意建议的顺序,认为使用密钥而不是密码这应该是最主要的保护措施。

Pasztor 最后展示了容器与 SSH 的其他用途。ContainerSSH 最初是为了解决网站所有者需要在服务器之间移动数据、但在每台服务器上都有不同的用户名的这类网络托管(web-hosting)问题而建立的。这可以通过 SFTP 来完成,但可能会很麻烦。容器化的 SSH 可以用一个简单的环境来包装那些必要的服务器,用户完全不需要修改底层系统的权限。

ContainerSSH 的另一个用途是在教育领域。在传统的教育系统中,学生完成一套练习后,会产生很多文件遗留在那里。有了容器之后,等到学生注销后,容器连同所有的剩余文件都会被删除。使用容器就让 Linux 的教学变得更加简单,现在甚至可以在容器中运行一个完整的 Kubernetes 集群。最后一个用例是在高安全环境(high-security environment)中。ContainerSSH 可以很容易地将会话日志(session log)自动上传到外部对象存储(external object store)中,确保日志永远不会被存放在被监控的系统上,从而避免被攻击者篡改。

讲座的幻灯片[PDF]视频可供下载。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作~

长按下面二维码关注,关注 LWN 深度文章以及开源社区的各种新近言论~



浏览 29
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报