蜜罐与物联网安全 – 作者:klovey-安全小百科

“善守者，敌不知其所攻” — 《孙子兵法》

一、概述

物联网(IOT)设备在各领域的爆发增长使其成为黑客攻击的重灾区，而其繁杂异构的特点也给安全防御带来很大挑战。蜜罐(Honeypot)作为主动防御的重要手段，既可服务于物联网安全，也可利用物联网设备作载体。本文旨在阐述 蜜罐与物联网安全的微妙关联，并就 物联网中蜜罐的应用与识别提出一些观点。

二、蜜罐分类

作为对黑客善于伪装的借鉴，蜜罐的使用由来已久。蜜罐的分类方式多种多样，基于规模的大小可分为：蜜罐(单一节点)、蜜网(多个节点)、蜜场(代理可扩展)；基于资源又可分为：虚拟蜜罐(虚拟化技术实现)、实物蜜罐(软硬件设备实现)、混合蜜罐(实物与软件仿真结合)。

以上的分类都比较容易理解，这里不做展开。笔者认为基于目的分类值得关注，单纯捕获漏洞攻击和偏向欺骗性防御虽然对交互上都有所要求，但从部署侧重点、架构上都有所差异。

2.1 捕获漏洞攻击

蜜罐是获取漏洞和一系列攻击操作的高效手段，能获取到漏洞和行为的详细程度与蜜罐可交互性正相关，而交互性与投入成正比，在构建此类蜜罐时可能需要关注：

蜜罐设置的漏洞陷阱是否具有足够的代表性？

蜜罐设置分布是否足以覆盖易受攻击的范围？

蜜罐规模是否达到吸引黑客攻击的目的？

蜜罐交互性是否足以获取攻击行为全部信息？

蜜罐构建成本是否可以通过好的架构压缩？

2.2 欺骗性防御

欺骗性蜜罐一般部署于 实际业务环境，对检测和隔离的要求更高，在构建此类蜜罐时可能需要关注：

蜜罐交互性能否有效引流攻击行为？

蜜罐间隔离措施是否能确保互相不受影响？

蜜罐与核心网络隔离措施是否确保其避免成为跳板？

蜜罐在整个网络中的最佳部署比例是多少？

蜜罐流量分析能否在检测、取证和溯源起关键作用？

蜜罐的原理相同，在规模、成本和交互性都有着一定的要求，但在实时检测、流量分析、安全性和隔离要求依目的而异，下文蜜罐构建内容中将有所涉及。

三、物联网与蜜罐

单个蜜罐设备一般要求量级轻，而整体系统需要成一定规模部署，这很容易让人联想到物联网。上文提到，物联网和蜜罐关系密切，主要体现在 蜜罐可利用物联网设备作载体，而不仅限于捕获物联网漏洞；相对的，也可使用设备上的实物或虚拟 蜜罐捕获物联网安全漏洞。

3.1 利用物联网设备搭建蜜罐

蜜罐的部署多种多样，可以直接用主机、虚拟机、docker等等，当然利用小设备搭建也是不错的选择，网上也不乏利用 树莓派和 Dionaea搭建低交互蜜罐的教程。有时甚至直接可以利用可刷开源 (OpenWrt) 系统的 路由器就可以满足要求。

利用设备部署蜜罐的优点在于：物联网设备量级轻，易于分散部署，满足同等规模要求的同时成本低。而其部署难点也较为明显：设备一般计算复杂度低，用于非捕获物联网漏洞的蜜罐时交互性可能不满足要求。

3.2 利用蜜罐捕获物联网攻击

物联网设备漏洞挖掘的痛点在于：设备数量大、架构多，硬件固件类型繁杂，普通研究手段捉襟见肘，随着低级漏洞的逐步消失，协议和二进制模拟 fuzz效果都着实一般。

而结合蜜罐捕获物联网漏洞的优点是，不仅可以利用众多黑客智慧获取漏洞，还可以监控攻击行为，为漏洞态势预测提供依据。但也并非轻而易举，在虚拟蜜罐的真实性、交互性，实物蜜罐的统一管理和成本控制等方面难点诸多。

成规模的物联网实物蜜罐和 僵尸网络有很多相似之处，而蜜罐也可以用来检测僵尸网络攻击，颇有 以彼之道还施彼身的意味。同时，按照上文的描述方式，利用物联网蜜罐捕获物联网漏洞的正常操作似乎成为绕口令，颇有套娃的既视感。

四、物联网蜜罐的矛与盾

上述铺(Fei)垫(Hua) 之后终于进入正题，来探讨下蜜罐的构建与识别。

4.1 物联网蜜罐构建

网上的开源蜜罐不胜枚举，除了Kippo、rdpy等常见专一工具，还有很多支持多协议，GitHub上有仓库对蜜罐工具和文章进行了分类梳理。这里简单提及几个具有代表性的物联网 蜜罐工具，并阐述一些物联网 蜜罐架构的侧重点。

4.1.1工具

KAKO

KAKO为许多常见的嵌入式设备提供漏洞蜜罐，利用python开发，支持包括telnet、http和https服务。

KAKO用过YAML文件配置执行，默认为kako.yaml，在 kako-simulations仓库中可以找到更多示例。其输出格式支持 AWS SNS和 JSON文件。这为输出的 日志分析提供便利，而KAKO本身不提供分析功能。

Hoenypot-iot

Hoenypot-iot仅提供http服务，利用python开发，会将攻击的IP等信息记录日志文件，然后存入MySQL 数据库中。

Potd

Potd是专为OpenWrt和IOT设备打造的SSH/TCP蜜罐，利用C开发，具有较强的可扩展性，目前仅支持libssh，计划添加HTTP、openssh、SCADA和 MySQL协议，还将完善其沙箱执行(Jailed Process)。

Dionaea

Dionaea是Nepenthes项目的后继，通过 低交互模拟 多种协议捕获攻击者源信息及攻击操作，并自动分析其中可能包含的 shellcode、函数调用和 下载文件。

当然还有许多功能较为单一的物联网蜜罐工具，包括telent-iot-honeypot、Miniprint、HoneyNTP等等。

开源工具的选择可能是构建蜜罐系统的第一步，需要对蜜罐构建的目的有清晰的认识，比如是否支持多网络协议，是否需要添加工控协议，记录是否存放数据库，是否自动分析，交互性要求，沙箱安全性要求等等。

工具选择完成紧接着是整个系统构建，按照上文分类，也就是蜜网或者蜜场的部署方式，接下来探讨一下架构设计。

4.1.2架构

固件虚拟

物联网设备众多，架构复杂，通过虚拟固件不仅可以 节省物理设备费用，还便于 管理和监视成规模攻击行为，难点在于模拟的 真实性，即是否满足 高交互性和 抗指纹攻击。

架构示例：Honware

Honeware可以用设备的固件镜像来模拟基于Linux的客户端设备和IOT设备，除** X86-64** 外，目前支持 ARM和 MIPS。感兴趣的小伙伴可以从从Vetterl和Clayton两位作者的论文中获悉设计思路。

笔者在之前一篇 固件文章中列举过一些固件模拟方法，Honware模拟仍然是基于 QEMU，其基本架构如上图所示：

可以看到，在宿主机上主要分有3层模块，QEMU负责系统的基础模拟，在默认 kernel中包含网络、日志、NVRAM和 信号处理4个子模块，最上层是IOT Linux系统，提供包括 Telnet、SSH、Web、SSDP等各种服务。

流程也是物联网研究常规操作：

固件解包依旧利用 binwalk，由于固件包五花八门，难点在于判断哪些系统文件对 boot起关键作用。Kernel构建即上述架构中默认 kernel的4各子模块，这里只强调 NVRAM (non-volatile memory)，用于存取设备配置参数，固件模拟中经常因为 NVRAM的问题导致失败。Honware中则先将自己的 NVRAM写入 LD_PRELOAD，确保最先读取，然后利用脚本读取 kernel日志，更新缺失的库。 固件修改主要针对脚本和配置，添加需要的程序。模拟执行即 QEMU的参数和运行问题。

论文中对部署后 UPNP、DNS、Mirai攻击等有较详细的评估，并阐述了抗 Timing攻击和指纹攻击，这里因篇幅限制不再展开。

混合代理

模拟的再真实也没有直接用实体设备方便，但是买设备需要玛尼，就想能不能虚实结合，以少当多来用，此时就可以使用 可扩展代理的方式。

架构示例：SIPHON

SIPHON是可扩展高交互混合蜜罐，其主要架构如下图所示：

SIPHON提出了蜜罐虫洞(Wormholes) 的概念，虫洞作为物理名词大家应该都不陌生，就是用来穿越的，在这里虫洞扮演同样角色。简单来说，就是在共网上开放 “虫洞” 吸引攻击者，虫洞负责将攻击流量导向 转发器(Forwarder)，转发器隐藏实际设备位置，并将流量导向 实际设备(Device under Attack)，虫洞与设备多对一就即可实现放大功能。最后，存储分析器(Storage & Analysis Unit) 直接与虫洞联接，获取“第一手”流量开展分析。

上图展示了利用云部署虫洞的实现原型，通过三个不同的云服务供应商 (Amazon、LiNode和 Digital Ocean) 扩大部署覆盖面，转发器和云虫洞之间通过反向 SSH隧道建立连接，转发器将定向流量通过 socat分配至物联网设备，并将执行结果流量实时反馈给云虫洞。通过在转发器中为物联网设备每个连接使用 不同的本地端口就可以实现自动化，而攻击者眼中的设备也是真实存在的，如下图所示：

此架构的优点显而易见，利用云虫洞使蜜罐部署更加灵活，使用真实物联网设备提高交互能力，代理映射型架构不仅隐藏真实设备的IP，还尽可能节省了成本。对SIPHON蜜罐实施评估感兴趣的小伙伴可从其论文中了解详细内容。

AI蜜罐

如果既不想花钱买实体设备，也不想模拟固件，毕竟模拟过的人都知道，面对五花八门的固件，问题那是相当多的，那么可以尝试时下流行的 机器学习。尽管 AI(大家都懂)在网络安全各领域中的作用并没有预期的那么强大，但并不妨碍其一定是未来趋势。

架构示例：IOTCandyJar

IOTCandyJar旨在利用机器学习模拟 IoT设备行为构建 智能交互(intelligent-interaction) 蜜罐，其结构如下图：

所谓 智能交互(intelligent-interaction) 简单来说就是通过机器学习掌握物联网设备的正确相应，并将合理的响应用于和攻击者的交互上。下面来详细说明 IOTCandyJar的原理。

如上图公式所示，BulaBulaBula，~.~，还是算了，说明不了。感兴趣的小伙伴可以研读此论文，告辞。

AI虚拟蜜罐如果具有足够的真实性前景很大，一是方便构建云蜜罐，二是在某些场景尤其工控、医疗设备等安全防护领域，模拟相对困难，实体又代价太大，而AI蜜罐给了不错的选择。

实体防御

上述三种架构重在捕获，而 防御型蜜罐的部署侧重点可能与之有所不同。下面使用的示例架构不仅限于物联网，当然作为内网防御蜜罐节点，物联网设备也是不错的选择。

架构示例：欺骗性防御

欺骗性防御是一个比较新的术语，定义尚未明确，基本是指通过蜜罐网络捕获检测攻击行为，实现自动化防御，欺骗性防御经常会和 自适应防御作比较。

欺骗性防御的优点包括发现早、误报少、可扩展等等，总之就是覆盖了蜜罐的优势。下面简单给出几种欺骗性防御方案，显然方案的复杂程度和投入多少直接相关。

重定向

在业务服务器上设置敏感目录、敏感文件，例如 admin.php, login.php等，并设置 “302重定向跳转”指向蜜罐。

伪装代理

在业务服务器上部署伪装代理，比如业务服务器使用443端口，则 伪装代理启用80/8080端口，并将流量转发给蜜罐。

诱饵

设置诱饵的方法比较激进，即主动发布 GitHub等敏感消息，泄露内部信息，如数据库、办公系统、中间件、服务器等，当然都是 蜜罐信息。还可在办公网如 BBS，Wiki等应用中放入一些网盘分享链接，诱骗登录。

布阵以待

此类方法是蜜罐的大规模部署，成本比较高。即五步一”廊“，十步一”阁“，使得内网渗透处处踩雷。

网络安全的核心是保护资产，蜜罐也是资产的一部分，蜜罐内和蜜罐间的安全监测尤为重要，以往蜜罐被打穿成为跳板的例子也不在少数，单纯吸引攻击的蜜罐在防御中舍得其反。蜜罐日志分析中能否更进一步，与检测溯源，比如 Att&ck联动实现更加自动化也值得关注。当然，回归文章主题，不要忘记 物联网设备作为蜜罐节点也是不错的选择。