物联网揭晓，第3部分：安全性

在本系列的第1部分中，我认为IoT的局面绝对是一团糟，但是Home Assistant（HA）将它们捆绑在一起确实令人钦佩。在第2部分中，我介绍了IP地址以及运行所有这些东西的体面网络的重要性，然后介绍Zigbee和低功耗，低带宽设备的作用。我还研究了自定义固件和焊接，为什么在我看来，这是我目前不需要考虑的问题。

现在面临的最大挑战-安全性。与其他IoT领域一样，这里还有很多改进的余地，就像其他IoT帖子一样，对于普通人来说，它变得非常复杂。但是也有一些捷径，尤其是在“运用常识”领域。让我们开始吧。

好的，这个笑话是一个愚蠢的老歌，但其中蕴含着一个硬道理：物联网设备中出现了一些令人震惊的安全失效实例。我一直直接参与其中的发现或披露，实际上，安全通常是我最常写的东西。让我将其分解为逻辑部分，并使用现实世界中发生错误的示例，我想用两种不同的方式进行介绍：

让我们以第一个观点为例，立即想到的是大约5年前在我的工作室中发现的Nissan Leaf漏洞。在这种情况下，攻击者可以轻松地从远程位置控制汽车中的运动部件。幸运的是，它不包含驾驶功能，但确实包括远程管理气候控制的功能，并且正如您在该帖子中嵌入的视频中所见，我为我的伴侣Scott Helme做了一些热身工作。他坐在寒冷潮湿的英式夜晚时坐在那里。

TicTocTrack孩子们跟踪手表时也是如此，这使世界另一端的陌生人可以和我6岁的女儿聊天。汽车和手表都遭到黑客攻击的原因是，漏洞位于API层，而不是设备本身，这是我们向另外两个方向发展的地方：

我已经给出了第一点的2个示例，因此这里是第二个示例，它们是从LIFX灯泡开始的。 Context Security发现的漏洞意味着暴露设备所连接的网络的Wi-Fi凭据，这很重要，因为它表明IoT漏洞也可能使网络上的其他设备也处于危险之中。来自Context Security的另一个示例是CloudPets说话（和收听）泰迪熊中的漏洞，该漏洞相当于在蓝牙上没有进行身份验证，从而使攻击者可以控制玩具。 （顺便说一下，由于所有“设备”上的硬编码PIN，Lixil Satis厕所也有类似的漏洞。）

回到风险影响物联网设备收集的数据的点滴，再回到CloudPets，Context Security的文章与我自己关于孩子的CloudPets消息被暴露在互联网上的故事相吻合。我不能将这归咎于泰迪熊本身，而是一个事实，即持有所有收集到的数据的MongoDB在没有密码的情况下公开面对。伟易达公司也是如此，后者通过儿童平板电脑（IMHO，这是一种物联网设备，首先是玩具）收集了大量数据，然后将其暴露给非常简单的漏洞。这些示例在物联网中是否真的存在风险？还是它们只是我们存储在互联网上的数据所面临的相同的旧风险？两者都是，这就是原因：

让我们以智能振动器为例（是的，它们是真实的东西），尤其是WeVibe的情况：

在拉斯维加斯举行的8月Def Con会议上，两名新西兰黑客证明We-Vibe 4 Plus振动器正在将信息（包括设备温度和振动强度）发送回其制造商Standard Innovation。

如果这些数据遭到破坏，则可能会暴露有关其所有者的大量非常个人的信息，而这些信息在物联网出现之前就从来没有以数字形式存在过。尽管暴露数据的潜在风险很可能是经典的auth CloudPets样式的缺乏，但是如果没有为从未有过的设备添加互联网，就不会暴露任何数据。成人玩具已经存在了整整一天，这并不是什么新鲜事物，但是记录它们的使用并将其存储在云中则完全不同。

我将从设备本身开始，向您提出一个问题：您还记得上次在地球仪上修补固件的时间吗？是的，我也是，因为我的大多数可能都和您一样：家里最简单的电气设备。但是，其中一些更像以前的LIFX示例，因为它们几乎没有微处理器，并且启用了Wi-Fi（或Zigbee）。而且，就像LIFX设备一样，它们偶尔也会需要打补丁。他们是复杂的小单位，可以做令人惊奇的事情，并且运行由人类编写的软件，这不可避免地意味着，我们当中的一个（软件开发人员）迟早会搞砸需要修补的东西。

IoT固件应具有自我修复功能。这是非常重要的，因为普通人根本不会手动修补他们的灯泡。或说话的泰迪熊。或振动器。您是否可以通过上述3个示例中的任何一个来想象您的非技术朋友有意识地考虑固件更新？您会多久考虑一次固件更新？我会多久一次？为了测试最后一个问题，我启动了许多物联网设备应用程序，以查看哪些应用程序正在自动更新（因此我不必考虑打补丁），而不是需要手动更新（在这种情况下，我应该一直在思考）关于修补程序）。我从飞利浦Hue应用开始，该应用既可以自动更新，也可以使用最新的固件版本：

好的，那很好，那时候我就不用考虑了。让我们尝试一下Nanoleaf，这是两个孩子都在墙上挂的LED灯板：

好的，所以他们是最新的，但是会保持最新吗？通过他们自己？老实说，我不知道，因为不清楚，再次使用我以前的术语，它们是否可以自我修复。与Shellys一样，我变得如此依赖：

为了完美地说明问题，我在发布系列的这一部分的前一天摘下了屏幕截图。仅仅一天后，情况就不同了，我只知道有一个更新待处理，因为我启动了应用程序并查看了设备：

我只检查了在Tuya应用中运行的数十个已连接灯中的一个：

看起来不错，但这不是默认状态！我必须手动启用自动更新，并且必须在每个设备上进行。人们只是不想自己做。

我接下来要检查的是我的Thermomix，可以通过设备本身直接访问固件情况：

我不确定这是否会自动更新（它在房子里还是很新的），但是具有较大的TFT屏幕和能够在设备前面提示用户的功能，如果可以的话需要人与人之间的互动。

嗯...好吗？坏？需要更新吗？事实证明，您无法通过查看设备本身来判断，您需要跳回主菜单，转到设置，进入固件更新，然后才能看到所有设备的所有待处理事项：

我不知道如何自动更新这些内容，也不希望继续返回到应用程序并检查未决的内容。我按了“更新”按钮，并认为一切都很好...（不是，但是我很快会再讲）

这就是我要处理的所有内容，我将回头看第1部分的标题：这真是一团糟。在默认自动更新甚至在哪里查找更新方面，制造商或设备之间都没有一致性。并且在任何人开始跳来跳去之前建议设备不应该自动更新，因为您应该在正式投入生产之前仔细测试任何补丁，并确保您具有可靠的回滚策略，这些设备是为像我妈妈和爸爸这样的人而制作的！它必须很容易。不是。

现在，我已经完成了有关补丁修补应如何自治的讨论，让我们从昨天在我的推文中提出的问题开始，来讨论其中的问题：

昨天在我的IoT博客系列的第一篇中，我感叹我的一个智能插头是如何无法访问的。看起来@tplinkuk通过固件更新破坏了它，现在它会破坏房子周围的一堆东西。查看对他们的推文的愤怒回应，哇😯https://t.co/RKFxNF7v9a

-特洛伊·亨特（@troyhunt）2020年11月23日

似乎发生的事情是，为了解决“插头上的安全漏洞”，TP-Link发布了固件更新，该更新终止了HA集成。更具体地说，他们关闭了端口，该端口允许HA直接与破坏集成的智能插件进行通信，但没有破坏本机Kasa应用程序。在撰写本文时，解决方法是使用TP-Link提出支持票证，将其发送给您的MAC地址，然后他们将通过固件降级做出响应，您可以使用该固件降级将设备还原到以前的状态。啊。 （旁注：关于此特定问题，似乎已完成使HA在固件的新版本中正常运行的工作。）

但是，这是一个更大的哲学问题：该设备仍可与本机应用正常运行，@ TPLINKUK是否应负责支持未记录的用例？可能是“否”，但在理想情况下，他们会记录其他应用程序的本地连接，而不会中断该连接。

-特洛伊·亨特（@troyhunt）2020年11月23日

显然，TP-Link绝不是人们现在以HA方式使用其插头的意图，我将在本文的下一部分中详细讨论为什么HA这样做。但是正确或错误的选择设备时，所冒的风险是制造商可能会在某个时候破坏该功能。一种解决方法是简单地阻止设备接收任何更新：

Troy，适用于HA和家庭IoT子网的防火墙规则编号1（尽管即使它们具有“本地”访问API，也会破坏Wiz Bulb连接）pic.twitter.com/RGOhsGaq7F

-GerryD©️（@ Bayview252）2020年11月23日

但是，如果该设备是早期的LIFX灯泡，并且该补丁旨在修复严重的安全漏洞，该怎么办？现在，您引入了另一种风险，因为您没有在打补丁，而必须在进行补丁时将其与所冒的风险进行权衡！正如@GerryD在该线程中所说的那样，这是一个经过计算的风险，最终，您要权衡一个问题和另一个问题。

说到交易问题，另一种方法是使用诸如Tasmota的自定义固件来刷新设备：

讲故事的道德，请避免任何需要专有权限的内容。他们总能把你弄糟。使用可以将Tasmota放下的设备。如果只有一家公司会出售不需要特定云服务的设备。

-Brian Orpin（@borpin）2020年11月23日

Tasmota正是针对这种用例而设计的，我非常有信心，他们不会像TP-Link那样破坏功能。但是，我也高度相信Tasmota是软件，所有软件都有错误（无论是否开源），并且您仍然需要修补机制。就我之前@GerryD的推文而言，即使在运行开源自定义固件时，对设备进行防火墙仍然仍然是一个问题。

那么，什么是正确的方法？对于您的普通消费者（要记住，购买TP-Link智能插头的人可能超过99％），自动更新固件是关键。对于我们其余的人，我们需要认识到，在使用物联网设备非预期的方式时会承担风险。在理想世界中，公司将以Shelly拥有的相同方式来实现这一目标：

我们合作的一家公司是Shelly。他们为从事产品集成工作的人员提供了服务，可以使用预发布的固件，还可以使用专门的质量检查小组与CEO +工程师进行交流。集成正在迅速成熟，下一个版本将是真正的

-Paulus Schoutsen（@balloob）2020年11月24日

Paulus是HA的创始人，在我的物联网旅程中，我和他聊天了几下。此推文是Shelly的榜样行为，老实说，我读过这篇文章后，对他们的看法提高了一些。在这个完美的世界中，TP-Link并不一定要花很多精力来构建HA集成（尽管那太好了！），但是他们将做出承诺以确保其设备“开放”并易于访问。其他有记录的，受支持的平台，将来的补丁程序将不会破坏这些平台。也许这只是时间问题，随着需求的增长，谁知道，我们甚至可能会在TP-Link盒子上看到HA，就像科技巨头一样。

关于设备更新固件的整个讨论引起了我现在要探讨的另一场哲学辩论，那就是关于自包含的IoT生态系统应如何在LAN内而不是与云相关的讨论。

在该系列的第1部分中，我引用了HA网站的内容，介绍了该项目如何“首先将本地控制和隐私”。实际上，这意味着HA可以在局域网内以自包含的方式运行。例如，在上述TP-Link固件更新之前，HA可以从我服务器机柜中的家中直接伸到Ari机房中的智能插头，并通过9999端口与之通信。如果没有Internet连接，它仍然可以工作（本地控制）和TP-Link都不是我刚刚切换一个开关（隐私优先）的明智选择。如果物联网制造商的云服务中断，弹性还带来了额外的好处：

因为我的装备是基于Tuya的，所以Tasmota对我来说是完美的。我知道Troy不喜欢固件替换方法，但是我不想一天（或者不醒！）醒来，因为Tuya云服务器中断，我的所有HA都坏了。

-艾伦（@ Alan_1）2020年11月23日

弹性还不仅限于云中断。如果Tuya关闭服务怎么办？仍然希望能够打开灯？关于本地控制，有很多话要说。就是说，关于云集成还有很多要说的，气象站就是一个很好的例子。我正在查看设备（Davis Vantage Pro2目前是领先者，但我愿意接受建议），然后提出一个问题：哪些设备与HA集成？而且（基于上述TP-Link经验），哪些集成在将来不会中断？与智能插头相比，气象站是一笔可观的支出，我不希望它以某种方式工作，然后有一天会损坏。

一种方法是找到一个可以与Weather Underground集成（戴维斯可以使用WeatherLink Live进行集成）的气象站，而不是尝试直接在Weather Station和HA之间进行集成，然后使用Weather Underground集成。现在，您依赖于云，但是您也大大扩展了兼容设备的范围（WU集成非常普遍），并且这样做的方式比连接到非标准服务的自定义集成要容易得多。我对此没有任何问题，我认为对“尽管没有云依赖关系”过于虔诚会使您失去很多选择。

就是说，从简单的安全性和隐私性角度（通常也是从性能角度来看），我总是优先考虑本地通信。例如，房屋中的每个Shelly设备都禁用了云集成：

但这并不能阻止我远程控制设备，因为我可以使用HA的Nabu Casa来做到这一点，但这确实使我不再依赖另一家物联网供应商来远程管理我的家。由于这些设备不会永久轮询别人的云……几乎，它还为我提供了更多的隐私。由于某种原因，我车库门上的Shelly每秒对api.shelly.cloud发出DNS请求！

这些数据来自我的Pi孔，并且Shelly是根据早期图像精确配置的。我什至从Shelly的/ settings API中提取了JSON（您可以在网络上任何Shelly的IP地址上找到该路径，并检索所有配置数据），将其与其他Shelly进行比较，但未显示此行为，我仍然无法弄清楚为何如此健谈。我在这里要说的是，设备可以做很多与母舰的通讯，如果可能的话，应该禁用它。

如果我们认识到整个事情都是一团糟，并且至少到今天为止，我们没有一个很好的策略来修补问题，那该怎么办？一种流行的方法是将物联网所在的网络与非物联网所在的网络隔离。这种心态类似于将所有可能的坏鸡蛋放在一个篮子中，将好鸡蛋（例如您的PC）放在另一个篮子中。

这样做的要求是在支持它的家庭中安装网络设备。在第2部分中，我谈到了良好的网络设备的重要性，实际上我之前曾写过很多关于Ubiquiti的文章，包括他们的AmpliFi消费者产品线和UniFi生产者产品线，后者已经在我家经营了四年。运行UniFi，我可以轻松创建多个Wi-Fi网络：

然后，当我们查看哪些客户端已连接到哪些SSID时，我们可以看到它们分布在主要（HTTP403）和物联网（HTTP403 IoT）网络中：

我的房屋中也有很多接入点，因此根据设备的位置和信号强度，将不同的设备连接到不同的AP。我选择将所有我高度信任的设备（例如iPhone，iPad和PC）放置在主网络上，并将所有IoT物联网放置在IoT网络上。我还将Ubiquiti摄像头（包括其门铃）放置在主网络上，以确保它们基本上都是UniFi生态系统的一部分。

但这只是按SSID进行细分；每个设备都在同一子网和相同的逻辑VLAN上，并且目前没有任何客户端细分，因此控制壁炉上的灯的Shelly无法看到我的iPhone。 Ubiquiti很好地记录了如何执行此操作，而在我的UniFi网络的第一个版本中，这正是事情的配置方式。 （另请参阅如何配置VLAN间路由。）但是有问题...

主要问题是，您最终遇到各种情况，其中特定的IoT设备需要查看控制它的应用程序，但是由于VLAN的主要目的是将IoT东西锁住，所以东西会失败。因此，最终您将跟踪设备，端口和协议，并在网络之间创建越来越复杂的防火墙规则。故障排除很痛苦。每当我的IoT设备运行不正常时，我就会怀疑地观察VLAN之间的防火墙规则。我最终不断调试网络流量，并在无尽的线程中进行搜索，就像这一步一样，试图弄清Sonos在VLAN上表现不佳的原因。

当我设置UniFi网络的版本2（在此处完整的鸣叫线程）时，我保留了IoT SSID，但从不打扰VLAN。这使所有现有设备都可以轻松跳转到新网络（我使用了来自v1 netwo的相同密码