A Virtual Honeypot Framework for Capturing CPE and IoT Zero Days
摘要—现有的解决方案在检测针对用户端设备（CPE）和物联网（IoT）设备的零日漏洞方面是无效的。我们提出了honware，一个高交互性的蜜罐框架，它可以在不接触制造商的硬件的情况下模拟各种设备。Honware自动处理一个标准的固件镜像（如通常提供的更新），定制文件系统，并使用一个特殊的预建Linux内核运行系统。然后，它记录攻击者的行为，并记录他们的哪些行为导致了系统被破坏。我们提供了一个广泛的评估，并表明我们的框架改进了现有的仿真策略，这些策略的可扩展性是有限的，它在提供网络功能和仿真设备的固件应用方面都有明显的改善—这是一个关键的方面，因为漏洞经常被攻击者利用在 “前端 “功能，如网络接口。Honware的设计排除了大多数蜜罐的指纹攻击，由于它的性能与真实设备的性能相当，使用定时攻击的指纹攻击可以说是微不足道的。我们提供了四个案例研究，证明honware能够快速部署，捕捉攻击的确切细节和恶意软件样本。特别是我们发现了一个以前未知的攻击，其中一个ipTIME N604R无线路由器的默认DNS被改变。我们相信，honware通过缩短攻击者在互联网规模上利用零日的时间，对重新平衡攻击者和防御者的经济做出了重大贡献。
Introduction
互联网正在从计算机互联网转变为一个连接日常设备（”物”）的全球网络。对自动化的强调和设备本身的性质共同意味着，不影响设备功能的漏洞和利用有可能不被其所有者注意到。最近的分布式拒绝服务（DDoS）攻击使用了安全性不足的用户端设备（CPE）和物联网（IoT）设备[1], [2], [3]，进一步突出了现有的防御系统在检测零日漏洞和捕获攻击信息方面的缓慢。这意味着攻击者有相当长的时间来发现和破坏易受攻击的设备，然后才能很好地了解攻击载体和后续的缓解措施[4]。
长期以来，蜜罐，即看起来是合法系统的资源，已被证明在捕获恶意软件、帮助打击垃圾邮件和提供关于即将到来的威胁的早期预警信号方面是有效的[5], [6], [7], [8]。Mirai僵尸网络是第一个招募各种物联网设备的大型僵尸网络，它使用自动伪随机扫描过程来识别和感染新设备。由于Mirai的源代码已经被泄露，并且被充分了解，因此建立一个蜜罐是很简单的，它通过向扫描器发送适当的字符串来模拟一个易受攻击的设备。但是，如果没有源代码，或对恶意软件的二进制文件进行逆向工程，这种类型的蜜罐就很难构建。监测大量使用不同攻击技术的攻击者，其中一些可能是以前未知的 “零日 “设备，这是一个巨大的挑战。
同时，以适度的投资来扫描整个IPv4地址空间的易受攻击设备已经变得可行。诸如Shodan或ZMap[9]等工具给了攻击者一个重要的优势。一旦发现某项技术、设备或具体实施的漏洞，攻击者就能轻易找到嵌入该漏洞的设备，并立即从该漏洞中获益。2003年，Spitzner认为蜜罐 “获得的流量很少”，”收集的高价值数据很少”[10]。然而，这种观察是在攻击通常由人类进行的时候，而自从僵尸网络兴起后，蜜罐观察到的几乎所有活动都由自动脚本执行。
之前的研究包括Firmadyne[11]，这是一个运行嵌入式软件并随后提供动态分析能力的分析系统，以及IoTPOT[12]，这是第一个为冒充物联网设备定制的通用高交互式蜜罐之一。IoTPOT支持八种架构，包括ARM、MIPS和X86，旨在向23号端口（Telnet）的连接返回适当的字符串。如果命令是未知的，它试图在一个通用的沙盒环境中运行它，以推断出适当的返回字符串。2017年，Guarnizo等人[13]提出了一个名为SIPHON的 “可扩展的高互动 “蜜罐平台，它是基于物理设备的。他们通过分布式架构在一系列IPv4地址上暴露了六个安全摄像头、一个联网录像机和一个联网打印机。
所有这些方法都有关键的缺点。Firmadyne是为动态分析而建立的，但不是为了监测大量的攻击者，因此不能与互联网连接。IoTPOT不使用真实设备的固件图像，因此它是一个脆弱平台的通用代表，无法检测到新的攻击模式；SIPHON需要连接到互联网的物理设备来捕获攻击信号，这是一个昂贵的努力，其可扩展性有限。
我们提出了honware，这是第一个灵活和通用的框架，可以有效地在互联网上的网络设备上部署蜜罐，记录攻击者的跟踪和他们的行动。honware不需要购买CPE或IoT设备并将其作为蜜罐运行，而是利用设备的固件镜像（可广泛下载）和一个特殊的预制Linux内核来模拟虚拟环境中的设备行为。特别是，它很容易为一个特定的设备部署所有可用的firmware版本，以便了解哪些设备容易受到特定攻击。
总的来说，我们有四个主要贡献。
- 我们提出了新的技术（并在现有工作的基础上进行了改进），使honware能够在不需要定制硬件的情况下运行标准的固件图像。
- 我们表明，honware优于现有的仿真策略，在可扩展性、网络功能的提供和仿真软件应用方面有明显的改进。
- 我们进行了广泛的测量，表明honware的性能可与真实设备相媲美，并且honware不容易受到基于时间攻击的微不足道的指纹识别的影响。
- 我们列举了四个例子来说明honware在识别真实世界的攻击方面所取得的成功，这些攻击在传统的低/中/高交互式蜜罐方法中很难捕捉到。
II. BACKGROUND
蜜罐按其模拟的系统类型进行分类，如SSH、网络或电子邮件服务器。它们又被分为低度互动（在SSH的背景下只是收集凭证猜测）、中度互动（模拟有限数量的shell命令）或高度互动（允许攻击者完全控制一台机器）。低度和中度互动的蜜罐容易部署和维护，但通常只实现一小部分的系统功能。相比之下，高交互性蜜罐暴露了一个完整的系统，因此任何漏洞都可以被利用，无论它们之前是否被知道。一旦防御者完全了解了新的攻击，就可以建立一个定制的低度或中度互动蜜罐，以捕获该特定的攻击流量，并提供有关危害程度的定量数据，以及当前恶意软件样本和C&C位置等操作数据。
自2016年年中以来，随着Mirai僵尸网络的兴起，人们对 “客户内部设备”（CPE）的兴趣越来越大，这是一个连接到电信供应商网络的xDSL调制解调器、路由器、交换机和其他家庭网络设备的通用术语。ADSL和电缆调制解调器等CPE在物联网生态系统中特别重要，因为它们是进入一个场所网络的入口，一旦被攻破，攻击者就可以连接到该场所的其他设备。CPE和IoT设备的固件主要基于Linux，通常辅以定制的内核模块和驱动程序，以提供设备的特定功能。CPE的固件几乎都可以下载，Netgear[14]、Link-TP[15]和Linksys[16]为各种类型的调制解调器和路由器提供在线GUI仿真器。越来越多的制造商也将其固件的源代码作为GPL代码发布，特别是为了支持正在进行的项目，如OpenWrt[17]。
在与犯罪分子的军备竞赛中，蜜罐的 “指纹 “是一个持续的问题。Morishita等人[18]指出，许多蜜罐并没有融入他们所模拟的服务类型，而是根据其独特的配置来显示自己。Vetterl和Clayton[19]开发了一种自动技术，根据数据包级别的协议互动来识别蜜罐，用微不足道的探测来识别蜜罐。复杂的攻击者利用指纹技术避免与蜜罐互动，可以长期避免被发现，但honware通过运行与真实设备完全相同的应用程序和协议栈，回避了所有这些问题。
Garfinkel等人[20]表明，虚拟化会诱发异常现象，如时间差异，这些异常现象可用于检测虚拟化环境。Kedrowitsch等人[21]比较了Linux容器与不同的虚拟化环境（如QEMU、基于内核的虚拟机（KVM）和VMWare）的欺骗能力，发现QEMU可以通过其缓慢的性能得到最佳印证。同样，Holz和Raynal[22]表明，命令的执行时间提供了一种有效的方法来检测蜜罐，因为仿真通常会导致更长的执行和响应时间。同样地，Mukkamala等人[23]发现，在虚拟化环境中运行的蜜罐通常比真实服务的响应速度慢。然而，他们也证明，对于与互联网连接的蜜罐，这个指标可能并不实用，因为它取决于网络负载、路由和仿真技术。
III.虚拟蜜罐框架
Honware使用CPE和IoT制造商提供的固件镜像，采用快速仿真器（QEMU）在一台主机上运行不同CPU架构（X86-64 PC、ARM、MIPS和PowerPC）的代码。虽然部分软件将与特定设备的硬件密切相关，但Linux内核和设备驱动API在许多不同的设备上基本相同。通过使用自定义内核，Honware将软件的执行与底层硬件解耦。
图1显示了honware的四个主要部分：主机操作系统和内核、QEMU、定制内核和包含telnet和web服务器等应用的firmware文件系统（从firmware镜像中提取）。
QEMU是全机仿真的事实标准，它提供了将蜜罐连接到互联网的必要功能。然而，QEMU不能用于现成的CPE和IoT firmware镜像的仿真。firmware有自己的内核，将尝试与硬件进行通信，但它的缺席意味着这种通信将失败。例如，任何访问非易失性存储器（nvram）以读取配置文件或试图从硬件检索MAC地址的行为都会失败。因此，我们用我们自己定制的内核和提取的文件系统在主机操作系统（如FreeBSD或Linux Ubuntu）上运行QEMU。
Honware目前使用三个定制的内核，因为这些内核足以处理大量的固件镜像。这些内核是用于MIPS little endian（mipsel）和MIPSbig endian（mipseb）的Linux内核2.6.32.70，以及用于ARM的4.1.52。我们特意使用了较早的内核，因为这些内核在CPE和IoT软件图像中最为普遍，很少需要对较新的内核进行支持。MIPS内核是用MIPS Malta和MIPS32 CPU的第2版编译的。MIPS Malta特别有用，因为它支持PCI和LAN功能的仿真，这些功能是网络设备仿真的内在要求。ARM内核是用架构Versatile Express和VIRT/MULTI_V6_V7作为假的CPU架构编译的。由于Versatile Express平台是用于开发和快速原型设计的，它提供了广泛的硬件支持。我们进一步对内核进行配置，以支持各种网络功能，如VLAN和WLAN。
镜像软件的仿真分三个阶段进行，并且是完全自动化的。A）从固件镜像中提取文件系统，B）修改文件系统以实现虚拟化，C）使用我们预先编译的内核在QEMU中运行。Honware通常会处理一个固件镜像（通常是一个.zip或.rar文件），并在一分钟内准备好运行蜜罐。
A. 自动提取固件
路由器、ADSL调制解调器和物联网设备的固件图像在网上广泛提供，许多制造商在其网站上提供定期更新。Honware使用这些图像作为输入，通常以压缩格式，并提取固件文件系统。任何提供的内核都会被忽略，因为在QEMU中运行它将不允许我们干扰firmware系统的应用和服务的执行—这是运行firmware镜像作为一个蜜罐的必要条件，事实上，也是为了将firmware镜像与底层硬件解耦。
为了提取文件系统，我们使用binwalk[24]并递归地寻找Linux文件系统结构。我们通过确定一个文件夹是否包含必要的根结构，包括bin、usr和proc，来识别Linux的lesystem。这被证明是具有挑战性的，因为并非所有的软件镜像都是以同样的方式打包的。有时，它们包括多个合适的文件系统，如一个用于升级的软件镜像，一个用于以前的版本，还有一个用于出厂重置。我们还发现了在启动过程中挂载辅助文件系统的情况，例如，提供刮擦空间。在这种情况下，我们只考虑初始进程所在的文件系统，因为如果没有这个进程，软件根本就不会启动。虽然提取的目的是完全自动的，但如果需要的话，honware也允许手动选择要使用的文件系统。
然后我们使用qemu-img创建一个2GB的原始文件，随后创建一个ext2文件系统，并复制根文件夹结构，包括所有文件和二进制文件。我们通过读取文件系统中最大的二进制文件（通常是Busybox）的ELF头来推断CPU架构。我们进一步从软件图像中提取所有的证书（.pem）文件，这样我们就可以使用Wireshark等工具来解密，例如，HTTPS流量到网络服务器。
由于DiffieHellman密钥交换不仅使用静态密钥，而且还使用会话密钥，因此解密SSH流量更具挑战性。检索相关的会话密钥并不简单，需要在客户内存中找到一个特定的内存结构。我们决定不解决这个特殊的问题，因为我们可以在我们的定制内核中记录执行的命令。然而，蜜罐操作者可以考虑使用SSLSNOOP[25]或相关技术来收集原始的traffic。
B. 定制的预建内核
现在我们考虑一下我们定制的Linux内核的各个组成部分，并解释一下我们是如何在Firmadyne等早期系统上进行改进的。特别是，以前的工作忽略了内核的信号处理程序，以确保应用程序继续运行，而不是无声地终止，而且以前没有尝试过支持树外的内核模块。此外，我们的内核并不完全依赖客户系统的默认配置来确保网络连接，而是可以强制使用一个特定的网络配置。此外，honware支持ARM小-endian平台的多达四个以太网设备，而Firmadyne只支持一个以太网设备。
1）蜜罐记录和模块加载。为了使蜜罐能够深入了解系统是如何被攻击的，并监测后续行动，必须具备广泛的日志记录能力。为了获得所有执行的程序和命令的细节，以及适当的时间戳、进程ID和上下文，我们修改了内核函数do_execve。对于每个连接，我们创建一个新的会话ID，在这个会话ID下记录被调用的程序和它们的细节。这意味着，启动过程、Cron作业和其他由固件镜像本身执行的过程可以与外部触发的行动明确区分开来。
2）信号拦截。我们遇到的一个核心问题是，启动进程和各种应用程序经常无声无息地终止，或出现通用错误信息。应用程序终止的原因可能是错误的或丢失的nvram值，不正确的硬件模拟或丢失的内核功能。为了减轻这个问题的影响，我们修改了内核中的信号处理，1）不允许内核终止进程，例如通过默认的信号处理；2）不允许程序以SIGABRT信号等方式终止自己。这意味着，无论发送什么信号，应用程序和内核模块都会继续执行。为了达到这个目的，我们修改了内核函数get_signal()，它被do_signal()调用，负责内核的信号处理。
事实证明，拦截SIGNAL 6（SIGABRT）特别有用。我们发现，SIGABRT被用来检测被破坏的约束，例如，指示缺少许可证密钥或没有硬件模块。特别是，装有Broadcom芯片的设备会在nvram中寻找各种设置，以区分不同的硬件版本。如果找不到这些设置，init进程或调用的应用程序要终止自己，以防止进一步执行。除了SIGNAL 6，我们还拦截SIGNAL 11（SIGSEGV）和SIGNAL 7（SIGFPE）。后两者可以缓解由丢失nvram值引起的问题，这些值对运行中的应用程序来说不是绝对必要的。SIGPFE通常是针对浮动点错误发送的，例如当应用程序试图除以0时，我们认为nvram的缺失导致了零值的使用和各种数学运算失败。
对于少数firmware图像，忽略信号会导致无限循环和非常高的CPU使用率，然而在许多情况下，程序似乎继续成功运行。因此，拦截信号是在忽略（某些）数值，同时使仿真有用和可行之间的一种权衡。
3) 模块加载。许多固件镜像都带有自定义模块，以实现设备的特定功能，如加密操作或对自定义硬件的支持。为了避免不必要的行为和内核崩溃，我们定制的内核将不会加载不兼容的模块，即使有指示（modprobe -f）。然而，内核将接受具有不同vermagic字符串的模块，不要求完全匹配。Vermagic字符串通常用于确保模块是为同一内核版本建立和配置的，但由于制造商和固件版本之间的Vermagic字符串差异很大，我们忽略了它们。例如，如果一个模块的vermagic字符串是2.6.22-routeros，那么我们较新的2.6.32.71版本的内核将试图加载它。这个问题可以通过为每一个具有正确ermagic字符串的软件镜像重新编译内核来避免，但这将是及时部署蜜罐的一个重大障碍，我们发现，在实践中，我们的方法非常好。
4）NVRAM：为了存储和以后检索设备特定的配置参数，设备制造商通常使用非易失性存储器（nvram）。Chen等人[11]研究了23 035个固件图像，发现其中有一半以上访问了Nvram，例如在启动过程中处理配置信息。通常情况下，固件镜像在启动过程中会设置各种nvram值，随后用nvram_get读取这些nvram值。为了模拟nvram，我们使用了在[26]中首次提到、后来由Firmadyne开发的方法：我们将环境变量LD_PRELOAD设置为我们自己的nvram实现路径，这样我们的文件就会在任何其他（firmware）库之前被加载。这意味着，我们可以可靠地拦截对nvram_get和nvram_set的调用。
为了扩展Firmadyne的方法，我们实现了一个脚本，自动读取内核日志，检测缺失的nvram值，重新编译必要的共享库，并在下次运行firmware的时候更新文件系统。这可能是一个反复的过程，因为设置某些nvram值可能会导致其他nvram值被访问，而这些值也可能丢失。在我们的评估中（第四节），将honware与Firmadyne进行了比较，我们使用了静态值，没有反复寻找丢失的值。然而，如表一和表二所示，在正确模拟固件、其应用和推断网络配置方面，我们取得了比Firmadyne更好的结果。
5）网络配置。提供网络功能是honware的一个基本前提，因为没有网络功能，仿真系统就无法连接到互联网，从而被攻击者探测到。为了推断网络配置，honware解析内核日志，以了解网桥设备的初始配置，通常命名为br0或ra0。 然后，它寻找配置网桥的ifconfig命令，以及为该网桥添加一个或多个网络接口的addif命令。随后，它提取 IP 地址，在 QEMU 中创建一个 tap 接口，并在主机上设置相关的路由和 iptables 规则，将所有流量转发到推断的网络接口。
如果网络不能使用推断的配置，我们就重新运行仿真，用自定义的配置覆盖固件的默认网络配置。这是通过将配置放入/sbin/boot.sh来实现的，该配置将在启动过程中由内核执行。自定义配置首先关闭网络接口（eth_x）和任何错误配置的网桥。然后，它分配适当的本地静态IP地址，并将网络接口重新添加到网桥上，设置一个路由，以便访客网络接口和主机的网络接口能够交换数据包。最后，该脚本删除了所有的防火墙规则，这样我们就可以确定流量不会受到干扰。如果网络仍然不响应ICMP回声请求数据包，我们就认为该软件图像无法到达网络（而我们试图创建一个有用的蜜罐的努力也没有成功）。
为了全面测试网络可达性，我们使用ping和nmap。特别是我们使用nmap 1对最常见的端口进行扫描，包括端口22（SSH）、23（Telnet）、80（HTTP）、443（HTTPS）和1900（UPnP）。对8个387个软件图像的评估结果可以在第四章A节中找到。
C. 文件系统的修改
在提取了文件系统后，我们必须对其进行修改以进行仿真。首先，我们添加nvram仿真模块（第III-B4节）。其次，我们修改do_execve，如果存在的话，通过内核函数call_usermodehelper执行/sbin/boot.sh。这使我们能够为一个特定的固件镜像执行自定义脚本和命令，而不必改变预先建立的内核或对固件文件系统进行复杂的修改。这使得蜜罐运营商可以灵活地指定额外的网络接口，执行具有特殊配置选项的应用程序，或根据自己的需要定制防火墙。
不足为奇的是，许多仿真软件图像并不配置静态IP地址，而是使用DHCP。由于我们选择不模拟对DHCP服务器的访问，获取IP地址的尝试就会失败，模拟的固件就无法通过网络到达。为了解决这个问题，我们使用busybox-static，这是一个静态链接的Busybox版本，可用于mipseb、mipsel和ARM以及许多其他架构。我们将这个Busybox二进制文件复制到客户文件系统中，并使用它来建立一个网桥，将一个网络接口连接到它上面，对两者进行适当的配置，并设置一个默认路由（见第III-B5节）。这种方法比依赖客户系统本身的默认配置要好得多，例如Firmadyne的做法。
D. 仿真
在提取和准备好文件系统后，honware调用QEMU来启动仿真。对蜜罐进行测试，看它是否对本地网络上的ICMP回声请求包作出反应。如果成功的话，就会创建必要的接口、路由和主机防火墙规则，将蜜罐连接到互联网上。我们将主机以太网接口上的传入数据包预先路由到QEMU tap接口，并将数据包重新路由到主机上。通过指定以这种方式处理的端口，操作者只需要将他们感兴趣的端口暴露在互联网上。
Honware可以被配置成只在一定时间内或永远运行，即直到被用户停止。当honware运行时，它会输出内核日志信息、传入网络连接的细节以及所有调用的命令和相关的时间信息，并将这些都写入日志文件中。
IV. 评价
对我们框架的评估有三个方面。首先，我们将honware与Firmadyne[11]在提取的固件图像、网络可达性和模拟服务的数量方面进行比较。我们通过获取和运行他们所使用的完全相同的固件图像来实现这一目标。第二，我们提供了四个案例研究，证明honware能够快速模拟设备，不仅能够捕获恶意软件样本，而且能够模拟先进的设备行为，这在传统蜜罐中是不可行的。第三，我们进行了广泛的测量，表明honware的性能与真实设备相当，并且不容易受到基于时间攻击的琐碎指纹的影响。
A. 提取、网络可达性和服务
为了衡量honware提取firmware图像、配置网络和模拟服务的能力，我们获得了Firmadyne评估中使用的firmware图像列表，并下载了所有仍可在提供的URL上访问的图像。截至2019年3月，23 035个图像中的8 387个（36.4%）仍然可以下载。该列表包括CPE和物联网设备的各种fimware图像，如ADSL调制解调器、路由器、NAS系统、网络摄像机和智能电源插头。不幸的是，Firmadyne的作者失去了他们的数据库，这将使我们能够将单个图像映射到可到达的网络和监听服务的结果，所以我们自己在剩余的8 387个固件图像上运行Firmadyne，以便能够比较结果。
1）提取。如表一所示，honware在提取固件图像方面似乎比Firmadyne更好。总的来说，我们成功地提取了8387张图片中的4650张（55.4%），而Firmadyne为2920张（34.8%）。我们都使用binwalk（事实上的标准工具，用于提取固件），对于大多数制造商，我们的结果是非常相似的。对Synology来说，我们的结果明显要好得多，可能是因为这些固件图像相当大，平均压缩到133MB，而且我们允许文件系统达到2GB大小（Firmadyne为1GB）。也就是说，我们怀疑Firmadyne由于空间限制而未能正确填充文件系统。Firmadyne和honware都无法提取文件系统的软件图像是加密的，有一种专有的图像打包方式，或者仅仅是更新—因此重要的文件夹和二进制文件都丢失了。
2）网络可达性。为了测量网络可达性，我们准备并运行所有成功提取的firmware图像，如第III-D节所述，并向它们发送ICMP回波请求包。如表一所示，我们取得了比Firmadyne明显更好的结果。从4650个成功提取的固件图像中，有1903个图像（40.9%）响应了ICMP数据包，而Firmadyne只有460个图像（占所提取图像的15.8%）。对于OpenWrt，我们能够ping 674个设备，而对于Firmadyne，没有firmware图像是可以到达的，这显然增加了我们的分数。然而，我们发现Zyxel（69比20）、TP-Link（147比95）和Netgear（384比187）的结果相似。
我们认为honware的表现更好，原因有二。首先，Firmadyne只支持一个以太网设备的ARM little-endian平台，而honware最多支持四个。
这一点特别重要，因为网桥必须至少有一个设备连接（如eth0），这样服务才能通过网络到达。第二，Firmadyne没有（回退）机制来纠正缺失的网络配置设置，例如，由于nvram无法在没有物理硬件的情况下被加载。相反，如第III-B5节所述，honware将自动检测初始故障，并建立一个桥和一个相关的以太网设备。
3）服务。软件应用程序的执行对蜜罐来说至关重要，因为大多数漏洞都是针对这些应用程序的。如果它们不能发挥作用，那么将firmware图像连接到互联网的价值就很有限。如表二所示，与Firmadyne相比，在honware下运行的应用程序对其监听端口的响应明显增多。我们发现，对于telnet，有879个软件图像响应我们的nmap扫描，而Firmadyne则为149个。80端口的HTTP是第二大观察服务，有676个软件图像响应我们的nmap扫描，其次是67端口（316）和1900端口（239）。
我们把明显更好的结果归功于我们的仪器化内核，它非常强调改进信号处理和构建一个工作的网络配置，通过执行我们的自定义/sbin/boot.sh脚本。这种技术使我们能够非常简单地改变默认配置，这对于试图通过DHCP获得IP地址的固件镜像来说特别重要。
B. 蜜罐的野外部署
为了评估honware的有效性，我们在互联网上部署了多个蜜罐，包括四个品牌的ADSL调制解调器，TP-Link、D-Link、Eminent和ipTIME。我们现在讨论四个案例，这些案例表明设备可以被快速模拟，比以前的方法快得多，而且honware可以检测到已知和以前未知的攻击。特别是在模拟ipTIME的路由器时，我们观察到一种未知的攻击，即路由器的默认DNS设置被改成一个流氓IP地址—我们后来发现它不仅影响ipTIME，也影响其他品牌。
1) Broadcom UPnPHunter。UPnPHunter是Broadcom通用即插即用（UPnP）软件中一个格式字符串漏洞的名称，影响到各种品牌，包括TP-Link、D-Link和Netgear[3]。该漏洞允许远程攻击者导致UPnP服务崩溃或执行任意代码。在野外看到的攻击是不寻常的，因为在试图进行第二阶段的攻击之前，初始连接预先确定了设备可能存在漏洞。360Netlab报告说，他们花了一个多月的时间来编码一个自定义的蜜罐，以适当地依次回应每个连接[27]。有了honware，由于所有服务都在运行，我们能够在蜜罐连接到互联网的24小时内观察到所述的攻击。
为了捕捉攻击，我们模拟了一个ADSL路由器调制解调器（D-Link DSL-2741B，软件版本517b50，发布于2010-03-08）。该路由器使用MIPS架构（大恩典），默认情况下，端口21/tcp、22/tcp、23/tcp、80/tcp、1028/tcp、67/udp、69/udp和5431/tcp上有监听应用。在我们将仿真器连接到互联网之前，我们使用概念验证代码[3]来测试该漏洞。该漏洞在5431端口使用SetConnectionType和GetConnectionTypeInfo函数，即UPnP SOAP服务。前一个函数用于设置格式字符串，后一个函数用于读取输出。正如预期的那样，我们成功地使UPnP守护程序崩溃，读取任意内存并以root权限执行任意代码，使我们完全控制了设备。
2019-23-01，一台来自印度的机器通过5431端口连接到我们的蜜罐，并发送
不幸的是，加载器未能下载恶意软件，而是发送了一个单字符X。我们不确定为什么会发生这种情况：可能是攻击者忘记更新占位符，包括一些恶意软件或壳代码，或者攻击者没有我们实验中使用的特定类型路由器的壳代码。
虽然我们没有捕获任何恶意软件，但我们已经表明，我们可以在一天之内为一个特定的设备创建一个蜜罐，并观察对它的攻击。迅速了解复杂的攻击载体和缩短攻击者滥用漏洞的时间窗口，而没有人能够精确地识别他们的方法，这显然是有价值的。
2) DNS劫持：我们观察到一个以前未知的攻击，其中默认的DNS服务器在我们的一个蜜罐中被改变，该蜜罐模拟ipTIME N604R无线路由器，软件版本为7.50（发布于2011-01-31）。这个特定的设备是由EFM网络公司制造的，主要用于韩国，由ipTIME分销。
默认情况下，该路由器在80/tcp、113/tcp和68/udp端口有监听应用。2015年，Kim [28]发现了一个通过发送精心制作的DHCP请求引发的远程代码利用漏洞。我们在位于芬兰和德国的两个不同的IP地址上运行这个软件的两个实例，并希望看到这种攻击—相反，我们记录了一个以前未知的攻击。
攻击者使用timepro.cgi脚本和广域网设置菜单，将默认的DNS覆盖到一个位于荷兰的恶意IP地址。这导致设备改变了iptables规则，如下所示。/sbin/iptables -t nat -A PREROUTING -i br0 -d 192.168.0.1 -p udp —dport 53 —j DNAT —to-estination X.X.X.X，x.x.x是攻击者控制的DNS服务器。他们还配置了第二个DNS服务器，以确保所有的DNS流量都流向他们的机器。
我们实验性地在攻击者的DNS服务器上解析www.yahoo.com，发现它解析到了中国AS41718（中国长城网络有限公司）的一台机器上。被解析的IP地址有一个不寻常的（自签的）证书，这使得它对一系列的网站具有权威性，许多网站与韩国有联系，但也有www.paypal.com、www.yahoo.com、www.google.com.tw 和更多。根据Shodan，还有39个具有相同证书的IP地址分布在世界各地，包括香港、台湾和美国/加州。
对在线支持论坛的搜索显示，同样的DNS服务器与其他攻击有关。三个使用TP-Link 2和Anderson 3设备的用户发现他们的DNS设置被改变了。我们将我们的发现报告给经过审查的安全专家和执法部门，以便他们能够采取适当的行动。
3）UPnPProxy。EternalSilence是一个新发现的UPnPProxy转发恶意软件家族[29]。EternalSilence向被攻击的设备添加端口转发规则，以暴露路由器后面的TCP端口139和445。每条规则都有一个相同的描述，即 “galleta silenciosa”，因此可以很容易地被印上指纹。这些规则被持久地保存在路由器的配置中，所以重启后不会清除它们；受害者必须明确地删除这些流氓条目。
利用我们的框架，我们建立了一个ADSL调制解调器路由器（Eminent EM4544，软件版本8.38，发布于201305-30）。这种类型的路由器使用MIPS架构（big endian），默认在280/tcp、113/tcp、68/udp和5431/tcp端口有监听应用程序。我们在2019-01-04设置了蜜罐，四天后的2019-01-08，一台来自玻利维亚的机器发出了一个M-SEARCH请求（M-SEARCH * HTTP/1.1），然后是一个GET请求（GET /etc/linuxigd/gatedesc.xml HTTP/1.0）来检索设备细节。响应包括各种设备细节，如设备类型、制造商和型号。随后，攻击者发出一个 AddPortMapping 请求，如图 2 所示。这个规则触发了 miniupnp 守护进程，将 47359 端口重定向到 192.168.8.1:135，这个动作被适当地记录为：miniupnpd[202]：将 47359 端口重定向到 192.168.8.1:135 协议 TCP for: galleta silenciosa。
我们成功地捕捉到了端口转发规则的改变，但与最初发现这种攻击的Akamai[29]一起，我们没有看到利用被攻击设备的进一步尝试。尽管如此，honware提供了一种机制，通过假装成一个易受攻击的设备，轻松捕获任何此类攻击的traffic。如果恶意防火墙规则在未来被利用，我们将能够立即观察到这种行为，并适当地报告。
4) Mirai变体。Mirai的源代码在不断进化，最近发现了一个名为Yowai/Hakai的新变体。这个变种利用了ThinkPhP[2]的invokeFunction中的一个漏洞，允许在底层服务器上执行任意代码。ThinkPhP是一个被各种网络设备广泛使用的PHP框架，特别是那些在中国制造的设备[30]。一旦设备被感染，它们会做进一步的扫描，以发现其他易受攻击的设备。利用ThinkPhP的一个好处是，它不与原始Mirai恶意软件竞争，因为它的目标是80端口的Web服务器，而不是23端口的telnet。现成的Mirai蜜罐不会记录这种攻击，因为它们会在23和2323端口寻找Mirai的traffic [31]。
为了捕捉攻击信号，我们用honware处理了ADSL调制解调器路由器TP-Link TD-W8960N的固件，该路由器于201111-08发布，并建立了一个蜜罐。默认情况下，该设备的监听端口为21/tcp、22/tcp、23/tcp、80/tcp、67/udp、69/udp、1900/udp和5431/tcp。我们的蜜罐从2019-02-17运行到2019-03-01（14天），捕获了566次试图利用ThinkPhP框架漏洞的攻击。总共捕获了49个不同的URL，即恶意软件实例，每个独特的URL的中位数为4次攻击。一个恶意软件样本与70个攻击相关。我们通过Virustotal检查，49个样本中有16个（32.7%）是全新的。其余的，超过三分之二的样本在被Virustotal首次记录之前就被honware捕获；只有13个（26.5%）样本在honware之前被其他人检测到并上传到Virustotal。在所有49个样本中，honware检测到恶意软件的中位数为9.7天，而Virustotal拥有一份副本。看来，我们能够比传统的蜜罐更快地将恶意软件提供给防御者社区。
C. 对指纹honware的定时攻击
指纹是蜜罐开发商和运营商一直关注的问题。一旦蜜罐被攻击者识别，它在检测新的攻击载体和监测攻击流量方面的价值将急剧下降。此外，运行蜜罐的主机也可能被攻击者列入黑名单，从而使它们变得毫无价值，即使是运行无法检测的蜜罐。因此，蜜罐应该总是以一种不容易被发现的方式来建立。
根据设计，Honware很难在网络堆栈或应用层打上指纹，但时间攻击是一个潜在的问题—仿真可能会极大地影响运行速度，因此我们非常谨慎地评估了这个问题。
仿真不可避免地在CPU使用、网络延迟和I/O操作方面引入了开销。然而，许多CPE和IoT设备的资源有限；例如，D-Link家用路由器DIR 825的CPU时钟为680 MHz，只有64MB的内存。此外，它通常被用于住宅网络，其（上传）带宽有限。相比之下，即使是流行的云供应商提供的最低级别的虚拟机，可能会部署蜜罐，其虚拟CPU核心的时钟频率为数GHz，1GB的内存和1Gbit的连接。因此，任何时间问题都可能是由于运行速度过快和运行速度过慢造成的。
为了将我们的蜜罐与真实的设备进行比较，我们寻找了在21、23和443端口有监听服务的自我识别设备。我们特别选择了443，因为加密流量需要更多的资源，因此可以作为我们的蜜罐和真实服务器之间的一个很好的区别。
不幸的是，大多数设备在没有进一步互动的情况下，不会通过其监听服务显示其型号和固件版本，但使用Shodan，我们能够找到三个合适的设备：华硕RT-AC52U双频AC750无线路由器（FTP服务器在21端口），Zyxel VMG1312B无线N VDSL2网关（telnet服务器在23端口）和D-Link无线N双频路由器DIR-825（Web服务器在443端口）。我们假设每个在23号端口连接时返回字符串VMG1312-B10A的设备都是相关的特定型号，Shodan报告说从120台设备中收到了该字符串。同样地，我们预计只有华硕RT-AC52U设备（74台设备）会发出220 Welcome to ASUS RT-AC52U FTP服务这个字符串，而HTTP/1.1 200 Ok Server这个字符串则会发出。DIR-825网络服务器/v1.00仅由D-Link DIR-825型号（127台设备）发送。
在确定了三种合适的设备后，我们建立了30个蜜罐来模拟它们，每个蜜罐有10个，在两个流行的云供应商那里，包括新加坡、加拿大、美国、德国、印度、荷兰和英国的实例。然后，对于每个协议（FTP、Telnet、HTTPS），我们测量应用服务器响应我们请求的时间，包括蜜罐和通过Shodan识别的真实设备。
对于每一次测量，初始往返时间（RTT），即SYN和SYN-ACK包之间的时间，被计算出来，随后被用来调整接收和传输信息的时间信息。作为一个例子，图3显示了与设备的FTP服务器的互动以及我们所做的调整。因此，我们的测量不是为了识别网络延迟或互联网引起的延迟，而只是为了测量应用服务器对传入的探针产生适当响应所需的时间。
当我们连接到21号端口的FTP服务器时，远程服务器将在完成TCP握手后发送欢迎信息220 欢迎来到华硕RT-AC52U FTP服务，时间为t欢迎。同样，在进一步发送回车键（t cr ）后，FTP服务器将回应530请用USER和PASS登录（t login ）。因此，应用服务器响应的时间是t 1 = t welcome -t rtt和t 2 = t cr ack -t rtt /2或者t 2 = t login - t cr - t rtt。telnet和HTTP协议本质上是相似的，但我们不是发送回车，而是开始并完成TLS握手，随后要求网络服务器用标准的GET请求发送主网页。对于telnet服务器，我们不与远程服务器进行协商，也不发送除SYN和ACK数据包以外的任何数据，因为默认情况下，telnet服务器会启动协商过程，并呈现一个登录提示，而无需进一步互动。
如图4所示，应用服务器的响应时间在真实设备和模拟设备之间确实有所不同。图4中的每条线代表了上述不同位置的一台设备的经验累积分布函数。对于这些设备中的每一个，我们在一天的时间内进行了300次测量，以测量对我们的连接和资源请求的响应时间。我们发现，真实的系统比我们的模拟设备快，而系统则慢一些—但不同协议之间有明显的差异。
对于FTP来说，在真实设备上发送欢迎信息的速度始终比模拟设备快。后者需要大约5ms的时间来填充欢迎信息，而真实系统需要大约1.8ms。有趣的是，响应我们回车的信息在仿真设备上没有明显的慢。我们不能确定为什么会出现这种情况，但我们推测华硕的FTP服务器在每次初始FTP连接时都会执行额外的操作，如检查文件系统或初始化内存。这些操作在真实设备上可能特别快，因为它们使用的是闪存，而虚拟机使用的是SSD或更慢的HDD。
对于telnet，模拟设备的反应比真实设备快得多。我们进一步发现，真实设备的响应时间是相当不稳定的，大多数telnet服务器的响应时间约为60-75ms（根据RTTs调整），而仿真设备一直需要几毫秒。同样地，真实设备需要比模拟设备更长的时间来呈现登录提示。
对于HTTPS，我们发现真实设备和模拟设备的响应时间大致相同，大多数服务器在30ms内完成TLS握手。TLS握手开始和应用数据传输（网页）结束之间的时间也是相当的。
总的来说，我们发现仿真一般不会减慢应用服务器的速度—我们认为这是因为我们使用的低成本云实例的规格比大多数CPE和IoT设备要好得多。在仿真速度较快的情况下，有可能会使honware的响应速度大大降低。
当然，在某些情况下，有可能对honware进行指纹识别，这是真的（也是完全可以预期的）。然而，差异可以变得足够小，以至于在攻击者能够可靠地区分模拟和真实设备之前，需要反复测量和参考组（即访问真实设备）。此外，互联网本质上引入了抖动、网络延迟和假象，这些都有助于进一步增加发动此类攻击的时间和努力—在HTTPS的情况下，honware的运行速度几乎与真实设备相同—指纹识别将是非常困难的。
V. 伦理考虑
我们在任何时候都遵循我们机构的道德政策，在每个阶段都有适当的授权。我们将DNS劫持攻击（第IV-B2节）报告给经过审查的安全专业人士和执法部门，以便他们能够采取适当的行动。
提取软件图像来分析其安全属性，是长期以来的惯例[32], [33], [34], [35]。可能有人会说，Honware是不同的，因为我们把firmware和我们的定制内核一起连接到互联网上，然后它不是由我们来分析，而是由未知的恶意实体分析。我们的观点是，我们的研究符合公众利益，因为能够为各种互联网连接的设备快速创建蜜罐，不仅使安全研究人员，也使制造商能够发现新的攻击载体，并提供更新以修补漏洞。此外，我们只使用可在公司网站上公开访问的软件图像，不需要注册或许可证密钥。
我们避免做我们自己的互联网范围内的扫描，以确定合适的设备为我们的定时测量，而是使用Shodan。我们的定时探针对远程服务器的整体流量的贡献是可以忽略不计的，因为我们在一天内只为每个设备启动了300个连接。在21、23和443端口开放的设备通常会收到数量级更高的流量，特别是来自恶意软件（如23端口的Mirai）或来自持续索引网络的搜索引擎。
当运行高交互性蜜罐时，总是有可能对第三方造成损害，即有人可能使用我们的模拟设备进行进一步的攻击或执行恶意活动。这是一个值得关注的问题，因此我们密切监测我们的蜜罐，一旦滥用的数量变得很大或没有进一步的兴趣，就会停止。例如，使用我们的设备作为代理发送垃圾邮件是意料之中的事，但在充分了解其作案手法，即攻击媒介、攻击本身和后果后，我们阻止了所有发出的流量并重置了设备。对于一个设备，我们不得不阻止出站流量，因为它被卷入了使用SSDP协议的DDoS攻击。我们的方法完全符合运行高交互式蜜罐时的传统良好做法。
应该注意的是，采取阻断出站流量的行动是在更好地理解攻击场景和躲避想要识别蜜罐的攻击者之间进行权衡。关于这些权衡的详细讨论可以在Nawrocki等人[36]中找到。
VI. 讨论
Honware旨在识别那些不容易被低/中/高互动蜜罐的传统方法捕获的攻击。它不是作为了解大规模、重复性攻击的工具而设计的，也就是说，如果一个设备能够被Mirai攻破，我们只对攻击一次感兴趣，而不是看到同样的攻击每隔几分钟就重复发生。在知道攻击载体后，我们需要防止进一步的妥协，例如通过阻止某些IP或识别攻击流量（例如，Mirai的初始扫描设置初始序列号以匹配目的地IPv4地址）。一旦对攻击有了充分的了解，就应该建立中等程度的交互式蜜罐，以收集有关大规模攻击的更多量化数据，减少维护并将潜在危害降到最低。
Honware的真正价值在于它有可能重新平衡攻击者和防御者的经济利益。以适度的投资来扫描所有IPv4地址空间的易受攻击设备已经变得可行。一旦发现某项技术、设备或具体实施的漏洞，攻击者就能轻易找到具有该漏洞的设备，并立即从该漏洞中获益。使用honware来识别准确的攻击载体并获得恶意软件的副本，意味着可以更快、更精确地部署反措施。
我们承认，Honware可以被那些准备进行大量测量工作以识别小的时间差异的攻击者印证。然而，本文所描述的工作重点不是推进最先进的沙盒反规避技术，而是开发一种工具，能够为非常广泛的设备快速构建蜜罐，并使这些蜜罐不容易受到基于协议偏差[19]或自我暴露特性[18]的指纹攻击。我们将真正的服务暴露在互联网上，并使用制造商提供的标准配置文件，这意味着我们的蜜罐将与真正的设备无法区分。传统上，蜜罐参与了 “红皇后竞赛”，通过更新模拟代码来对抗新的指纹攻击。Honware完全避免了这一点，这一点特别重要，因为最近已经表明，蜜罐运营商很少更新他们的蜜罐或注意他们的配置[37]。
我们设想honware可以在互联网范围内使用，例如，由制造商为他们的每一个产品和固件版本建立蜜罐。他们将了解已知的漏洞是否被实际利用，他们将非常及时地了解以前未知的问题。目前，Shodan等搜索引擎上列出的潜在漏洞设备的数量通常被用来将漏洞分为低、中或高影响。该框架将允许更好地评估有（未打补丁的）设备连接到互联网的风险，并允许以更彻底的方式确定漏洞的影响。
目前，honware框架专注于CPE和IoT设备，但旨在支持各种各样的这些设备。因此，我们做出了某些设计决定，这些决定对于特定的品牌或设备类型可能不是最佳的。然而，在任何时候都可以进行调整，特别是合作的设备制造商可以协助指定缺失的nvram值或建议其他配置调整。目前，honware仅限于基于Linux的ARM和MIPS架构的设备。随着其他架构的普及，重新编译Linux内核是很简单的。然而，仿真仍然受限于QEMU的能力及其对架构的支持，要支持不是基于Linux而是使用专有操作系统的设备，还需要做相当多的工作。
VII.related work
IoTPOT是首批为冒充物联网设备而定制的通用高交互性蜜罐之一[12]。它支持包括ARM、MIPS和x86在内的八种架构，旨在向端口23的连接返回适当的字符串。当命令未知时，它试图在基于OpenWRT的沙盒环境中运行该命令，并推断出适当的返回字符串（s）。同样地，Conpot基于Modbox和SNMP协议模拟工业控制系统。它支持对大型基础设施的模拟，以便对手可以相信他们正在与一个复杂的工业系统网络进行互动。
由于IoTPOT和Conpot[38]没有使用实际的软件来模拟设备，因此返回静态信息，Litchfield等人开发了HoneyPhy[39]。这个框架试图通过从连接的物理设备中获取数据信息来提供一个适当的模拟。例如，如果攻击者通过被破坏的网络接口打开暖气，蜜罐必须真实地反映这些变化，这样对手就不会意识到他们在与蜜罐互动。然而，IoTPOT、Conpot和HoneyPhy只模拟特定的应用/网络层，而不是基于实际的软件。因此，它们的行为必然会与实际的物联网设备不同。
IoTCandyJar[40]的方法更为复杂。IoTCandyJar利用互联网上公开的物联网设备来收集HTTP的响应，然后使用马尔科夫决策过程（MDP）来响应攻击者的探测。他们表明，在经过扫描互联网的学习期后，他们能够发送有意义的响应并捕获攻击轨迹。然而，他们的技术只适用于非加密的traffic，并且只能在任何登录之前捕获响应，即路由器管理界面和类似的不能被代表。他们还依赖于找到大量公开可用的设备，这些设备也必须识别自己，以提供有意义的响应。
2017年，Guarnizo等人[13]提出了一个基于物理设备的 “可扩展高互动 “蜜罐平台。他们通过分布式架构在一系列IPv4地址上暴露了六个安全摄像机、一个联网的录像机和一个联网的打印机。在他们研究的两个月里，他们测量了对其设备的50 000至600 000次攻击，这取决于位置。
2016年，供应商和ISP被TR-069 NewNTPServer漏洞打了个措手不及，该漏洞可用于在脆弱的路由器上执行任意命令[41]。TR-069是一个用于远程管理终端用户设备的应用层协议，现在已经有监测TR-069协议的定制蜜罐[42]。同样地，也提出了专注于工业控制系统的可编程逻辑控制器蜜罐的新设计[43]。
最近，通过扫描互联网IPv4地址空间寻找脆弱的工业控制系统并识别蜜罐，也取得了进展。Feng等人[44]使用启发式算法来确定检测到的ICS设备是一个蜜罐的概率。最近，有研究表明，工业控制系统越来越多地部署在世界各地，其中有60,000个系统可以公开访问[45]。
Ronen等人[46]展示了物联网设备的风险，飞利浦Hue智能灯可以被用来传播恶意软件。在他们的例子中，恶意软件从一个灯传播到它的邻居，并感染位于附近的灯。他们估计，对于巴黎这样的城市，只有15000个随机定位的灯泡就足以让每个灯泡都受到感染。
与目前的工作最接近的是Chen等人[11]提出的Firmadyne，它动态地分析基于Linux的固件图像以发现漏洞。他们依靠预编译的Linux内核，并使用QEMU[47]作为一个完整的系统仿真器。然而，他们的方法是不可扩展的，因为它需要持续的人工努力和专家在固件提取和仿真阶段对故障进行分类。它的目的是让开发者发现漏洞，而不是部署在互联网上被攻击者探测。我们的蜜罐框架在确定firmware图像的网络方面有明显的优势，使设备网络可达，最重要的是，在运行监听应用程序，如Web服务器（见第四章A节）。
另一个专注于固件图像的项目，Firmalice是一个二进制分析框架，旨在发现认证绕过漏洞[33]。它支持检查代码库，以发现硬编码的凭证、隐藏的认证接口和意外的错误，这些错误允许对手跳过认证过程并执行特权操作。
VIII. CONCLUSION
Honware是第一个允许系统设计者、开发者和安全研究人员有效地部署高真实性、高互动性的网络设备蜜罐的系统。该框架不需要购买和设置物理设备作为蜜罐，只需从制造商的网站上下载标准的固件镜像，就能实现CPE和IoT设备的虚拟化。
我们证明，honware可以在虚拟环境中模拟大量不同品牌的设备，而不受底层硬件的影响。我们的框架优于现有的仿真策略，这些策略的可扩展性有限，而且honware在提供网络功能和仿真firmware应用方面明显优于以前的项目—这是一个关键的方面，因为漏洞经常被攻击者利用在 “前端 “功能，如Web界面或UPnP守护程序。
越来越多的漏洞在攻击的不同阶段使用多种协议，并针对非常具体的软件实现和设备。一般的蜜罐在捕捉这些攻击方面是无效的，因为它们不能返回适当的流量，以允许攻击的后期部分开始，因此被记录下来。Honware使用原始的软件应用程序及其配置，这意味着攻击的每个阶段都可以被监控和充分了解。
此外，使用原始应用程序使honware实例更耐指纹，并防止基于协议偏差的指纹攻击或那些识别蜜罐规格的构架。我们进一步表明，honware的性能与真实设备的性能相当，而且它不容易受到基于时间攻击的微不足道的ngerprinting的影响。
我们的蜜罐框架在检测CPE和IoT设备的漏洞方面具有巨大的潜力，否则这些漏洞可能在相当长的时间内被利用而不被人察觉。我们展示了四个真实的案例研究，显示了我们的方法的实际价值，特别是在一天之内，我们能够描述一个复杂的攻击，而专家们用传统技术花了一个月的时间来识别。此外，在希望看到一个已被报道的攻击发生时，我们确定了一个以前未知的与复杂的基础设施相关的DNS变化攻击者。
攻击者正在不断地扫描互联网以寻找易受攻击的设备。我们相信honware是在重新平衡攻击者和防御者的经济方面迈出的重要一步，它削减了攻击者利用漏洞的能力，特别是 “零日 “漏洞，在相当长的时间内，防御者无法捕捉到攻击的细节，从而开始缓解过程。
若有收获，就点个赞吧
0 人点赞
