谷歌、Twitter先后开始远程办公，工程师发文吐槽：VPN都是垃圾！

前段时间，由于国内疫情严重，不少科技公司开启了远程办公，工程师吐槽 VPN 服务器因负载过高频频崩溃。如今，国外疫情严重，谷歌、Twitter 等大厂也开始进入远程办公。不料，国外工程师更加暴躁，直接评价：所有 VPN 都是垃圾。

因疫情全球蔓延，国外科技大厂开启远程办公

由于新冠病毒开始在全球肆虐，欧洲和亚洲各地区企业和组织开始效仿中国，采取远程办公的方式防止新冠病毒的传播。一些高风险地区，每天有数百万人在家办公，线上压力比以往任何时候都要大。而且有迹象表明，随着新冠病毒感染人群的攀升，未来几天或几周内大部分受波及地区都会采取在家远程办公的方式工作。

由于有员工报告出现流感症状，谷歌已要求其都柏林欧洲总部约 8000 名员工在家中工作。 谷歌发言人称，将继续采取预防措施，以保护员工的健康和安全。Twitter 也在周一表示，由于担心新冠病毒疫情的蔓延，公司“强烈鼓励”所有近 5000 名全球员工在家办公。Twitter 此前表示，公司将暂停一切非重要的公司商旅活动，优化内部会议、全体员工大会以及其他重要任务安排，以确保远程办公人员参与进来。

一些公司已经拥有了内部 Slack 和 Zoom 系统，员工可以选择使用哪种办公方式办公。但是一组与新冠病毒相关的最新数据表明，拥有这类远程办公系统的公司少之甚少，绝大多数公司都是第一次使用远程办公系统。

这些远程办公软件的实际使用率是怎样的？Google 给了我们一些提示：

在搜索引擎反映出来的数据可以看出，Zoom、 Slack 和 Microsoft Teams 的关键词搜索数量在以惊人的速度增长。

• Zoom 的搜索量在韩国增加了 525％，在日本增加了 150％，在意大利增加了 104％；
• Slack 的搜索量在韩国增长了 17％，在日本保持平稳，在意大利增长了 19％；
• Microsoft Teams 搜索量在韩国增长了 186％，在日本下降了 17％，在意大利增长了 108％；

疫情期间，远程办公软正经历着（或即将经历）销售、试用和新用户增长的繁荣期。尽管额外的流量基本上是免费的，营销效率却是飞速增长，但是有些软件服务团队却因用户体量如此巨大而不堪重负。由于疫情期间用户激增，许多市面上流行的远程办公工具存在着宕机、延迟或技术 bug 的问题，有员工也因此吐槽：远程工具实在是太难用了！

工程师激烈吐槽：企业 VPN 糟透了

当企业纷纷开启远程办公模式，为了访问企业内网，不少公司给员工提供了企业 VPN。然而，根据一些员工在社交网络上的反馈，企业 VPN 不太好用：一方面是因为突然之间要承受巨大的访问量，导致经常有员工被卡掉线；另一方面则是企业 VPN 的安全性有待提升。

技术专家 Matthew Sullivan 在自己的博客上专门写了一篇文章来吐槽企业 VPN 的安全性问题，当然更重要的是，他提出了一些可行的选择和搭建方案。

首先，他的观点是：

尽量别用 VPN。

为什么？因为：

所有的 VPN 都是垃圾。

他认为，VPN 也需要精心配置，否则黑客就能够找到可乘之机。更重要的是，这种精心配置只存在于理论层面，现实用户几乎不会在这方面下什么心思！

在 99.95% 的情况下，VPN 的设置都采取以下方式：

1. 桥接一台网络设备——例如笔记本电脑甚至是另一台服务器
2. 接入更庞大的服务器网络——例如云端或者内部环境
3. 跨越互联网——利用额外的加密层进行保护

谷歌、Twitter先后开始远程办公，工程师发文吐槽：VPN都是垃圾！" src="https://www.liam.xin/wp-content/uploads/2020/03/9-1583220831.png" alt="谷歌、Twitter先后开始远程办公，工程师发文吐槽：VPN都是垃圾！">

在 Matthew 看来，这显然不是什么好主意。如果笔记本电脑存在恶意软件，而且通过 VPN 接入了生产网络，该怎么办？恶意软件会因此获得对生产基础设施的本地网络访问权限，后果显然相当严重。

此外，黑客也可以通过 VPN 设备或者软件漏洞入侵 VPN 本体，从而回避安全检查并直接接入目标网络，这种情况可不是没出现过，之前影响巨大的 Heartbleed 漏洞就可以被用于劫持 VPN 访问。

关于 VPN 安全漏洞的消息层出不穷，全球范围内的攻击者都在迅速利用这些漏洞访问目标网络。更要命的是，这些系统直接面向互联网公开，而且没有配备任何保护机制。再者，修复程序往往无法自动执行，而且要求运营者在专有操作系统上运行专有软件管理方案中的专有更新机制。

接下来的问题就是，在互联网上找到公司 VPN 设备的难度有多大？Matthew 说，在撰写本文之前，他并不是非常确定，所以就这个问题在 Shodan.io 上花了 30 分钟左右学习了一番。下面来看相关结论：

• Thomson Reuters——一家价值 410 亿美元、拥有 26000 名员工的企业，其半数收入来自金融服务
• SAP Concur——入侵活动与开支管理服务，有大量个人身份信息与付款信息
• Progressive Insurance——个人身份信息与个人健康信息，也包括一部分付款信息
• Chevron Phillips Chemical——这是一家知名化工企业，其他的应该不用多谈了

简单一翻，就找到了这么多大公司直接暴露在互联网上的 VPN。问题确实很严重。那么，有没有可靠的解决办法？

如何保证 VPN 的安全性？

零信任

Matthew 给出的首个解决方法是“零信任”。

零信任的基本概念是对所有连接操作进行独立授权，也就是尽可能避免对网络之内的任何内容做出可信假设。

为了轻松实现对生产服务器的零信任登录，他给出了选择对应解决方案的三个理由：

1. 以 OpenSSH 核心完善而来

从底层来看，解决方案平台最好是一套拥有良好管理配置的 OpenSSH（即计算机上的 ssh 命令）部署方案。OpenSSH 经过严格测试，是一款相当安全的远程管理解决方案。自 2003 年以来，OpenSSH 从未因默认配置中的漏洞而遭遇未经授权的远程访问。

该网络入口点本身相当于一个基于 Amazon Linux 2 的单功能 EC2 实例，简单的结构意味着其攻击面非常有限。请注意：VPN 设备的一大问题，在于需要匹配专有软件 / 操作系统配置——这类配置正是阻碍自动修复程序的元凶。只要能够对网络入口点以及其他基础设施实现自动修复，就能在这场安全对抗当中占得先机。

2. 不存在网络桥接

之前提到过，大多数 VPN 在配置中都会将网络设备（例如笔记本电脑）桥接至互联网上规模更大的服务器网络当中。关于 VPN，Matthew 表示，他个人最接受不了的一点就是它劫持掉了用户的所有网络流量。虽然可以通过配置分出部分流量，但客户以及 NIST 800-53 SC-7(7) 等安全控制条款往往要求采取这种全流量转发的方式。

可以看到，这里的安全控制思路已经远远落后于行业实际情况。在过去，VPN 可能是唯一的流量加密解决方案。审计人员往往认为，如果没有 VPN 的保护，用户可能会通过未经加密的通道发布保密信息。但在另一方面，这也意味着最终用户的普通 Slack 流量也会通过生产 VPC 进行传递。

好在还有更合理的办法。在 OASA（一种可行的解决方案）模式下，用户与服务器之间的连接拥有独立代理。例如，提交“我想加入 EC2 实例 i-028d62efa6f0b36b5”这条请求，会让系统首先跳至网络入口点，而后再次跳转至目标服务器。OASA 还会在单点登录供应商完成身份验证之后，再验证请求发出方是否在受信内部设备上预先注册并获得批准。最后，OASA 发布客户端凭证，在接下来的 10 分钟之内持续保护这些跃点。

这让接入后的活动空间变得非常有限。管理员可以登录至网络入口点，再根据需要将端口转至另一目标——但在建立任何连接时，操作者都需要明确请求，且系统在默认情况下会拒绝一切请求。最重要的是，因为这套体系跟 VPN 没关系，所以不需要通过生产 VPC 来路由一切有必要和没必要的网络流量。

3. 网络访问范围与随机 IP

这些网络入口点基于各个 VPC 进行部署（例如某个 VPC 用于生产、某个用于分段、某个用于开发等）。此外，主机保护解决方案会对每个应用程序进行严密监控，记录应用的所有活动并执行流量过滤。如此一来，即使攻击者成功侵入网络入口点位置，其实也没有什么后续空间可以利用。无论如何，这套安全模式都不会因为访问者已经进入 VPC 而允许其随意访问一切受保护资源。

企业端口敲门

实际应用场景中，几乎没人会使用端口敲门，但设置起来却非常有趣。简而言之，端口敲门是对各个封闭的网络端口建立命中序列，只有按正确顺序进行操作，才会打开“真实”端口供您的 IP 使用。听起来挺好，但在实际应用中缺乏可行性。

但端口敲门的基本原理给了 Matthew 启发，让他开始考虑如何对这个概念进行迭代，他将这种解决方法称为“企业端口敲门”。

Matthew 说，想创建一种机制，确保网络入口点与互联网防火墙始终保持隔离，直到有用户发起访问。这种机制必须易于使用、可靠性高，而且能够通过现有身份提供程序执行身份验证。

于是他草拟出这套机制的基础架构，然后把结果提交给工程技术团队。几周之后，方案就被投入生产环境。

这项服务非常简单，可通过 AWS API Gateway 访问 AWS Lambda 函数（无服务器架构），整个使用体验简单可靠。下面来看该机制的基本原理：

1. 用户通过单点登录成功完成身份验证
2. 应用遍历已经配置完成的 AWS 账户，找到带有特定标签的安全组（安全组，即 AWS 中的防火墙规则）
3. 应用对安全组进行更新，批准访问者的 IP 地址。安全组规则拥有一个包含创建时间的标签。
4. 清除 cron 定期运行，在可配置时间后删除之前的 IP 授权清单。

在这项服务的支持下，Matthew 团队建立起一套远程访问解决方案。这套方案与互联网完全隔离，砸到能够在开启防火墙端口之前通过的用户目录进行双因素身份验证。

简单易行的工具

虽然听起来有点复杂，但整个登录流程其实非常简单：

1. 单点登录（如果尚未登录）
2. 在 SSO 门户中点击企业端口敲门连接器
3. 在终端内，使用 SSH 命令并将目的地声明为所需的 EC2 实例 ID。OASA 非常聪明，只需要指定要使用的网络入口点，其余流程都能自动完成！