见下文。
论文
IoTFinder: Efficient Large-Scale Identification of IoT Devices via Passive DNS Traffic Analysis
September 7-11, 2020 (all-digital event)
5th IEEE European Symposium on Security and Privacy
这是一篇S&P上收录的论文
论文摘要
- 本文要解决问题
识别潜在的易受攻击的IoT设备
- 解决方案
提出一个IoTFinder系统，通过被动DNS流量分析，能够大规模、高效的识别IoT设备
数据收集：收集分布式被动DNS数据
该系统基于机器学习
仅基于DNS指纹识别IoT设备
识别的广泛性：该系统不论IoT设备处于NAT下，其他中间盒、还是分配了IP4或IP6地址，也能进行识别
IoTFinder
- 多标签分类器
- 本文通过不同设置评估了其分类的准确性
- 不同的DNS流量数据
- 实验结果表明，即使将它们托管在NAT之后并且其流量与由同一本地网络中托管的其他IoT和非IoT设备生成的流量“混合”在一起，我们的方法也可以准确地检测许多不同的IoT设备。
本文主要关于：
IoT安全
流量模型
被动DNS
B相关知识学习
被动DNS（Passive DNS）
https://developer.aliyun.com/article/764940
https://securitytrails.com/blog/passive-dns
DNS：域名与IP地址相互映射的分布式数据库
域名解析：通过域名获取IP地址的过程
被动DNS:
- 与传统的DNS（实时系统需要查询DNS服务器和解析器以将主机名转换为IP地址）不同，被动DNS的工作方式却相反。
这意味着始终存在一个DNS数据库，用于存储DNS记录，IP地址查找以及有关与通用DNS通信中涉及的域，服务器和IP地址有关的所有内容的统计信息。此信息将保存在安全的数据库中，以供以后分析，该数据库会将实时DNS结果转换为被动DNS数据。 - 顾名思义，也即通过被动获取DNS数据（在互联网中，通过流量抓取工具获取DNS数据），这些数据被存储到一个中央安全数据库，形式Passive DNS。这种数据信息和一些本地DNS数据不同的是，它包含的不仅是当前的DNS数据（包括IP映射等），还包括了历史上所存在的一些DNS数据映射等。比如，一个域名在某个时间段内可以解析到多个IP地址上，一个IP地址也可以某个时间段内映射在多个域名，这些映射历史都是可以被Passive DNS数据包含在内，这样研究者可以从这些关联数据中发现已知的恶意域名与未知恶意域名之间的关系，从而挖掘出未知的威胁风险。
- 与传统的DNS（实时系统需要查询DNS服务器和解析器以将主机名转换为IP地址）不同，被动DNS的工作方式却相反。
Passive DNS应用场景
检测网站钓鱼域名
阻断垃圾邮件干扰
识别恶意域名
提供威胁情报
检测域名劫持
品牌保护
域名DNS历史记录查询
查询主域名下的所有子域名被动DNS工作原理
通过实例简单了解
以下实例，使用到的是美国Farsight Security公司推出的Passive DNS数据库—-DNSDB，有关这一案例的更多信息，可参考该公司的Passive DNS白皮书：https://info.farsightsecurity.com/passive-dns-ebook
介绍
面临挑战
传统通过banner grabbing 和fingerprinting 能够识别暴露网络服务的设备包括IoT设备，
但是当IoT设备托管在NAT或者其他中间盒后（防火墙），主动探测不能够识别IoT设备
当IoT设备被分配IPv6地址时，识别也面临挑战
B相关知识学习
banner grabbing（横幅抓取）
https://securitytrails.com/blog/banner-grabbing
横幅抓取是一种用于确定远程计算机上正在运行的服务的信息的活动
在渗透测试或安全审核期间，无论何时执行智能侦察过程，我们都需要注意当前Web服务器的公开信息。
这就是banner grabbing的来源。banner grabbing是获取软件横幅信息（名称和版本）的一种方法，无论是手动完成的，还是使用任何可自动为您完成的OSINT工具。
FTP服务器，Web服务器，SSH服务器和其他系统守护程序通常会公开重要信息，这些信息不仅涉及软件名称，而且还涉及它们所运行的确切版本和操作系统（相关的“横幅”数据）。
在匹配关键CVE的情况下，对任何协议进行抢夺式攻击都可能发现不安全和易受攻击的应用程序，这可能导致服务利用和损害。
您如何进行标语抢夺攻击？ 只需选择您要定位的服务，启动请求，检查收到的响应即可。
fingerprinting(指纹)
https://securitytrails.com/blog/cybersecurity-fingerprinting
物理世界，指纹通常唯一标识单个个体，分析指纹是用于识别与所有类型的犯罪活动有关的最流行的技术之一，从抢劫到绑架甚至是谋杀。
在数字世界中，也有分析指纹的方法，但是从这个意义上讲，我们是在谈论操作系统，网络和服务指纹。
网络安全中的指纹
- 数字世界中的指纹与现实世界中的人类指纹相似。简而言之，指纹是可以用来检测软件，网络协议，操作系统或硬件设备的一组信息。
- 指纹（也称为足迹）是一种使用该信息将数据集关联起来的技术，以便以较高的可能性识别网络服务，操作系统编号和版本，软件应用程序，数据库，配置等。
- 一旦渗透测试人员获得足够的信息，此指纹数据就可以用作针对目标的利用策略的一部分
IoTFinder设计期望
Fully-automated fingerprint learning（全自动指纹学习）
One fingerprint per IoT device（每个物联网设备一个指纹）
给一个DNS流量跟踪D，从Ik设备学习得到一个指纹fk，利用fk作为二分类判断Ik是否产生或者有贡献于在D中看到DNS活动
multi-label classification
与多类别分类方法不同，这些单独的指纹使我们可以轻松地执行多标签分类，从而可以识别可能在同一（NAT）IP地址后共同托管的多个不同的物联网设备
在混合网络流量中准确识别IoT设备
结果可解释
有效的匹配
本文贡献
- 提出了IoTFinder系统，可有效大规模检测IoT设备。其旨在自动从真实IoT设备中学习统计DNS流量指纹，并对地理位置不同的网络位置收集的大量DNS流量上进行有效的匹配来源指纹。
- IoTFinder用作多标签分类器，即IoT设备位于NAT后面，并且其流量与由同一本地网络中托管的其他IoT和非IoT设备生成的流量“混合”，也能够检测到IoT设备。
- 为了评估统计模型的准确性，我们在几种不同的设置下对我们的IoT指纹进行了详细评估，包括通过第三方IoT流量数据集计算检测结果。 这些详细的实验使我们能够突出提出的方法的优点，并指出可能的局限性
- 我们还将物联网指纹应用于在美国的ISP收集的DNS流量上，该ISP托管了超过4000万客户，以评估我们系统的性能。 我们的结果表明，我们可以在有限的时间内（略大于一小时）有效地处理一整天的ISP级DNS流量，并测试所有IoT指纹。
直觉和方法概述
IoT数据收集
建立大型物联网实验室，包括多个语音助手、摄像头等53台来自不同供应商的活动IoT设备。这些设备部署在人参与的实验室中。本文特别关注IoT设备
生成的DNS流量，实验中使用的IoT DNS数据集跨越1.5个月。
激励的示例
上图表示，24个小时内部分IoT设备查询域名的情况，
水平表示每个IoT设备查询的域名，
垂直代表一个小时的窗口，
原点表示DNS查询的次数
基于IoT设备产生的DNS活动构建简单探测模型
文献【19】提出类似模型：给定特定IoT设备的查询的一组域和从第三方网络收集的被动DNS跟踪，如果跟踪中DNS客户端（例有匿名ID或IP地址标识）查询的域名在特定IoT设备查询域中，就将该客户端的IP（或匿名ID）标记为IoT设备托管在其下。
- 此模型问题
- 容易产生大量误报
- 易通过探测域（该域是否包含人类可访问内容）过滤掉一些域名，从而会丢弃一些信息，降低潜在的分类能力
- 也会丢弃不包含供应商名称或设备型号名称的域名
- 使用单个域名检测IoT设备，可能会导致识别共享DNS行为（例，来自同一供应商的不同设备型号）的设备产生严重混淆
- 此模型问题
因此本文想法：
- 组合域名，以及不同IoT设备发出DNS查询的频率通常是具体的。这一观察结果有利于构建
- 一组有区别的行为指纹，可识别不同IoT设备模型，并当与普通客户端DNS行为匹配时，不易触发大量误报。
- 利用该直觉构建一个系统
- 自动学习基于DNS的IoT指纹，
- 无需对查询域名格式严格假设
- 无需手动推导过滤启发式减少误报
方法概述
构建高效的基于DNS的IoT设备指纹，将IoT设备检测和文档检索进行类比【20】
- 名称表示
- $C_i$表示通用设备（IoT或非IoT），实践中由设备的IP(v4或v6)地址表示
- $d_{ij}$是设备$C_i$查询的域名
- $f_{ij}$是$d_{ij}$在$C_i$的DNS流量中出现的频率
我们把$C_i={(d_{ij},f_{ij})}j$视为包含一组$d{ij}$术语的文档，每个术语都有各自的术语频率$f_{ij}$
- 名词表示
- $Q_k$为IoT设备
- $q_{kj}$为$Q_k$查询的域名
- $f_{kj}$为$Q_k$查询$q_{kj}$的频率
沿用文档检索的类比，将$Q_k={(q_{kj},f_{kj})}_j$作为搜索查询词，识别IoT设备的任务是：
检索与搜索查询$Q_k$相似的所有文档$C_i$,并根据相似度排序
根据类比，为了计算IoT设备$Q_k$的DNS行为与通用设备$C_i$的DNS行为之间的相似性
首先将每个$Q_k$和$C_i$转换为各自的TF-IDF(即术语频率-逆文档频率)特征向量表示【20】，然后测量相似性（例，余弦相似性）在得到的特征向量之间。
B相关知识学习
TF-IDF（术语频率-逆文档频率）
TF-IDF反映了在文档集合中一个单词对一个文档的重要性，经常在文本数据挖据与信息提取中用来作为权重因子
面临挑战
主要有关IoT设备模型和文档检索之间的类比。
无论IoT设备是位于NAT后还是和其它设备一起，我们匹配IoT设备的目标都不能立即适合文档检索场景。
文档检索更青睐于单个主题的检索，相比于含多个主题的文档相比，不希望这不利于匹配托管于NAT后的IoT设备或者处于相同IP地址的（IoT或非IoT）
等等。。。
系统详细设计
基于DNS的IoT指纹学习
为了模型化IoT设备的DNS行为，进行如下操作：
- $Q_k={q_{kj}}{j=1}^{m_k}$，表示一个IoT设备在$T_l$时间内查询$m_k$个不同的域名$q{kj}$
- 将$T_l$划分成长度为$w$且不重叠的时间窗口
- $N_w=\frac{T_l}{w}$表示长度为$w$的时间窗口个数
- 给定$q_{kj}$，通过判断其是否在时间窗口中，$n_{q_{kj}}$表示在$N_w$个时间窗口，查询域名$q_{kj}$的次数
- 定义$p_{kj}=\frac{n_{q_{kj}}}{N_w}$，表示设备$Q_k$查询的域名$q_{kj}$在任意长度w的时间窗口内至少查询一次的概率
- 则每个IoT设备$Q_k$的统计指纹为$P_k={(q_{kj},p_{kj})}_{j=1}^{m_k}$
建立查询频率和词频之间的映射取决于测试时考虑的流量窗口的长度
离散化时间处理过程能够弥补相同供应商和相同模型的IoT设备查询频率可能的短期变化
- 例如，相同的IoT设备Ia 和Ib，Ia部署在缓存DNS转发器（例，NAT），Ib直接或者通过非缓存的中间盒设备连接到ISP network，两者的查询频率可能不同（由于处于不同的middlebox下）
- 设置w的长度超过DNS资源记录(例，A记录 或者AAAA记录)TTL，能够使得Ia和Ib的DNS缓存行为近似相等，使得查询频率近似相等
这样更精确化的进行IoT指纹的匹配，后面讨论时间窗口w的取值
计算IDF：估计每个IoT查询的域在全局DNS 跟踪中的反向“流行度”
- $Q={q_i}_{i=1}^m$表示任意IoT设备查询的不同域名的集合
- 类似，$Q=\bigcup{q_{kj}}_{j=1}^{m_k}$
- $T_p$表示被动DNS跟踪收集的观察时间
- $N_c(q_i)$表示在$T_p$时间内查询域名$q_i\in Q$的客户端数，$N_c$表示在$T_p$时间内至少查询一个IoT域名的总的客户端数量
- 定义$IDF(q_i)=\log(1+\frac{N_c}{N_c(q_i)+1})$，也即表示有机会匹配一个IoT设备，域名$q_i$越少见，其逆文档频率越高（其特异性越高）
实践中，从模型中筛选较为流行的域名。在文档检索类别中，过滤掉“stop word”域名，如过滤d域名（例：google.com）,过滤掉d和www.d 过滤目的：
- 减少测试时要考虑匹配的客户端数量$C_i$，从而使指纹匹配更加高效
- 减少触发误报的概率，因为高度流行的域名被大多数非IoT设备查询，从而可能导致虚假匹配
学习过程中，获得每个IoT设备的统计指纹，一个IoT设备指纹应包含内容：
- IoT域查询频率：对每个IoT设备$Q_k$， $P_k={(q_{kj},p_{kj})}_{j=1}^{m_k}$
- 用来计算$P_k$的时间窗口$w$
- 每个域的IDF值：${IDF(q_{kj})}_{j=1}^{m_k}$
- 基于每个设备的最大容许假阳性率$\phi$计算的探测阈值$\theta_k$
基于DNS的IoT指纹匹配
本节阐释基于DNS的IoT指纹如何与未来的被动DNS追踪进行匹配
相关名词：
- $T_t$作为被动观察DNS流量的时间窗口
- $C_i$表示DNS流量中DNS查询的一个客户端
我们目标：在指纹$P_k$和$C_i$的DNS行为之间，计算一个得分$s_{ki}$，
计算TF-IDF向量：
- 计算时间窗口个数：$N_t=\lceil \frac{T_t}{w} \rceil$，其中$w$和学习$P_k$时使用的是相同的
- 设定$f_{kj}=p_{kj}*N_t$，则TF向量$V_k={(q_{kj},f_{kj})}{j=1}^{m_k}$，$f{kj}$表示的是在$T_t$时间内，IoT设备k查询域$q_{kj}$的时间窗口个数
- 最后，计算相应TF-IDF值$\psi_{kj}=f_{kj}*IDF(q_{kj})$
- 使用$\Psi_k={(q_{kj},\psi_{kj})}_{j=1}^{m_k}$表示时间$T_k$内IoT设备$Q_k$的TF-IDF向量
计算客户端$C_i$的TF-IDF向量
- 假定$C_i$在$T_t$时间内查询$n_i$个不同的域名$d_{ij}$及其发生的频率$f_{ij}$
- 即$C_i={(d_{ij},f_{ij})}{j=1}^{n_i}$，其中$f{ij}$是计算查询域名$d_{ij}$的时间窗口w的个数
计算一个IoT的TF-IDF向量和一个客户端$C_i$之间的相似性
将$C_i$映射到$\Psi_k$的$m_k$空间中，实际上，计算新向量$C_i’={(q_{kl},f_{kl}’)}_{l=1}^{m_k}$
- 其中，${q_{kl}}_{l=1}^{m_k}$表示的是和$\Psi_k$相同的$m_k$域名集合
若$q_{kl}=d_{ij}，则f_{kl}’=f_{ij}$
若没有域名$d_{ij}$匹配$q_{kl}，则f_{kl}’=0$
换种说法，也即是我们取所有由客户端$C_i$查询的域同时也被IoT设备查询的域。设置它们的TF值，以反映在时间Tt中$C_i$询问它们的频率。如果一个IoT设备$Q_k$查询的域不在$C_i$的行为中，设定他的频率为0
- 最后计算，TF-IDF向量$\Gamma_i={(q_{kl},\gamma_{kl})}{l=1}^{m_k}$，其中$\gamma{kl}=f_{kl}’ \cdot IDF(q_{kl})$
这种将$C_i$的行为“投射”到$Q_k$的域名空间能够实现我们主要目标之一
- 能够避免仅仅因为$C_i$表示共存于同一IP地址后面(例如，在NAT后面)的多个设备(可能包括几个其他物联网和非物联网设备)的DNS流量，而惩罚$Q_k$和$C_i$的相似性分数，
现在拥有两个跨度相同的向量空间$\Psi_k$和$\Gamma_i$
- 令$\psi=[\psi_{kj}]，\gamma=\gamma_{kj}$是包含$\Psi_k和\Gamma_i$的两个向量
- 计算匹配分数：$s(\Psi_k,\Gamma_i)=\frac{\psi \cdot \gamma}{||\psi||\cdot ||\gamma||}$(例，计算两者余弦相似度)
- 若$s(\Psi_k,\Gamma_i)\geq \theta_k$，就认为$C_i$的DNS行为匹配IoT设备$Q_k$，其中$\theta_k$是自动计算的阈值，将误报的数量限制在预定的最大值$\phi$
学习设备检测阈值
为了学习每个特定设备的检测阈值$\theta_k$，进行如下步骤
收集大的数据集$D$(在训练中的未被看到，标记为被动DNS追踪)，实践中，$D$为我们提够了大量非IoT设备的流量记录，构成负面数据
在$D$中获取$C_i$的行为，并将其与之前学习的IoT指纹进行匹配
计算每个指纹和$D$中每个非IoT设备之间的余弦值$s(\Psi_k,\Gamma_i)$
调整检测阈值$\theta_k$计算假阳性的变化
同样，考虑IoT设备$Q_k$生成的未见过的DNS流量，使用该流量计算每个IoT设备指纹$\Psi_k$的真阳率
给定最大容许假阳率$\phi$，目标找到检测阈值$\theta_k$，满足两个要求：
- 指纹$\Psi_k$产生的假阳率$F_k\leq \phi$
- 保持$F_k\leq \phi$时，最大化真阳率
ROC曲线图（随着检测阈值变化，真阳性率和假阳性率之间的权衡）
如图带有线性插值的ROC曲线
IoT指纹部署
本节讨论如何枚举野外IoT设备
由于计算量大的问题，为了解决这个问题，我们在一个大型Apache Spark集群中实现了我们的特征向量计算和指纹匹配，使得来自一个大型ISP的真实世界的DNS流量的N ×M指纹匹配计算时间减少到每天不到一个小时(详见第4节)。
评估
B相关知识
DPI（Deep Packet Inspection）是一种基于数据包的深度检测技术，针对不同的网络应用层载荷（例如HTTP、DNS等）进行深度检测，通过对报文的有效载荷检测决定其合法性。
相关工作
许多工作探索了使用网络流量分析来检测网络中的物联网设备或研究它们的行为[23]-[37]。
其中一些工作利用网络流量统计进行设备识别[23]-[25]或受损设备检测[26]-[28]
其他工作使用了对不同应用层协议的分析，如HTTP、Telnet、DNS等。，识别物联网设备[29]-[32]
此外，还提出了主动探测技术，通过扫描网络资产[28]、[33]或使用设备的媒体访问控制地址来识别供应商和产品类型[38]、[39]，从而识别物联网设备。
值得注意的是，这些作品中有许多需要访问物联网设备所在的本地网络，或者访问网络流，而在非常大的规模上收集这些网络流通常很昂贵。另一方面，我们专注于仅基于大规模被动DNS流量分析来高效检测物联网设备，因为全球分布式DNS流量通常更容易大规模收集(在某些情况下可以购买)
- 最近的一些作品研究了物联网设备产生的域名系统流量的特征[35]，[36]，并讨论了相关的隐私含义[34]，[40]。最近，有两项工作考虑将DNS流量用于物联网设备检测[19]，[37]。据我们所知，[19]，[37]是最接近我们的工作
在[19]中，作者使用域名查询和物联网设备联系的目的IP地址来构建设备检测系统。如第2.2节所述，郭等人[19]提出了一些手动设计的启发式方法来过滤掉可能引起误报的物联网查询域。例如，给定物联网设备查询的一组域，它们探测这些域以确定它们是否是“面向人类的”(即，它们是否包含人类可访问的内容)。此外，他们还会过滤掉不包含物联网设备供应商名称的域名。然而，如第2.2节所述，这种启发式方法可能会丢弃具有高度歧视性的域名，并可用于更准确地检测特定物联网设备的存在。更重要的是，[19]建议使用单一域名进行检测，这可能会在具有重叠DNS行为的设备(例如，来自同一供应商的不同设备型号)之间造成严重混淆。另一方面，IoTFinter并不依赖于上面提到的启发式，而是可以基于设备查询的域名组合自动学习物联网设备检测模型。此外，IoTFinter会自动学习每个统计物联网指纹的检测阈值，以便将可能的误报限制在所需的容许量内。
在构建了IoTFinter之后，我们意识到最近发表的一篇文章[37]也提出了使用TF-IDF来模拟由物联网设备生成的DNS流量。然而，[37]与我们的工作大不相同。首先，在[37]中提出的系统要求要分类的流量必须已知来自单个物联网设备。引用[37]:[检测]算法应仅在已知流量文档属于已知为物联网设备的设备时调用。”相反，IoTFinder不需要这种先验知识，即使物联网设备与许多其他物联网和非物联网设备共同托管在同一个IP地址后面(例如，在同一个NAT后面)，也能够检测到它们。其次，在[37]中，检测阈值必须由操作员手动设置，而我们设计了一个
一种算法，用于标记现实世界的非物联网流量，并自动学习每个设备模型的检测阈值，以达到预定的最大容许误报率。此外，[37]中介绍的检测管道依赖于WHOIS记录和x509证书来识别物联网设备的供应商。然而，在许多实际情况下，域名的所有者可能与供应商不同，例如当使用私有的WHOIS记录时，或者当服务托管在与云相关的域(例如AWS)上时。在这种情况下，设备最终可能会被分配给错误的供应商。这种错误的决定将级联到设备类型分类器，这依赖于供应商分类器的成功来进行正确的设备识别[37]。我们的工作不一样，因为我们只依靠DNS流量分析，对一个物联网设备查询的域名的归属不做任何假设。此外，我们专注于大规模检测，并实施IoTFinter，以有效检测托管数千万客户端的大型ISP网络中的许多不同物联网设备。
还有一项提议是通过自动域名注册来识别物联网设备[41]。然而，目前还不清楚这一提议在未来是否会被广泛采用，因为它需要物联网供应商的合作。此外，遗留物联网设备可能通过这种机制保持不可检测。另一方面，我们的系统不需要物联网供应商的合作，可以“原样”检测物联网设备，包括可能不支持未来协议的遗留设备。
讨论和限制
- DNS流量轻量，易收集，信息粒度低。
- 本文基于DNS的IoT指纹能够模拟IoT设备DNS行为，能够精确检测许多IoT设备（即是该IoT设备托管在NAT后还是和其它非IoT设备混杂一起）
某些情况下，基于DNS的流量模型无法捕捉同一供应商生产的不同设备之间的差异
同时，每当发现IoT指纹匹配通过相关检测阈值时，我们的系统不仅报告已经检测到设备，还报告具有什么相似性。因此，当相似性不相同时，它可以用作一种置信度得分，以便通过选择具有最高相似性的设备来消除不同设备的歧义。
当大量(例如，数百个)物联网和非物联网设备托管在同一IP之后(例如，在同一NAT之后)时，准确检测物联网设备变得越来越困难。尽管如此，我们表明，我们的统计指纹仍然能够正确检测各种各样的物联网设备，而不会出现误报，即使在这种具有挑战性的情况下也是如此
目前我们的系统无法识别一个域名系统测试背后有多少相同设备的实例。主要原因是域名系统缓存效果可能会“压缩”查询频率信息，从而难以识别表现出相同域名系统行为的设备的确切数量
自然，我们的方法仅限于非加密的域名系统流量，因为我们需要访问查询的域名。最近，出现了使用DoH (RFC8484)或DoT (RFC7858)加密DNS流量的趋势。特别是，集中式DoH可能是一个问题，因为它可能会阻止本地网络运营商(包括互联网服务提供商)收集有关其客户端生成的域名系统流量的详细信息。然而，我们应该考虑一些观察结果。首先，DoH可能会对其他现有的安全应用程序产生负面影响，有人提议尝试防止这种情况[22]。其次，DoH目前大多局限于浏览器发布的DNS查询。因此，如果DoH成为主要浏览器的默认协议，物联网设备可能更容易检测到，因为它们的域名系统查询将与少量的非域名系统流量混合在一起。未来的物联网设备最终也可能开始采用DoH或DoT。然而，对于许多资源受限且不允许添加DNS加密软件的传统物联网设备来说，它们的DNS流量特征可能会变得越来越明显。最后，虽然采用DoH的新(或更新的)物联网设备可能会被直接的互联网服务提供商监控所隐藏，但我们的方法仍然有效，因为它可以由DoH运营商(如谷歌或Cloudflare)而不是单个互联网服务提供商来应用，以估计互联网上的物联网设备数量
