订阅以接收新文章的通知:

Cloudflare 如何实施 FIDO2 和 Zero Trust 硬件密钥来防止网络钓鱼呢?

2022/09/29

11 分钟(阅读时间)
How Cloudflare implemented FIDO2 and Zero Trust to prevent phishing

几年前,Cloudflare 的安全架构是一个经典的“城堡+护城河” VPN 架构。员工使用企业 VPN 连接到所有内部应用程序和服务器来完成他们的工作。我们使用基于时间的一次性密码(TOTP)执行双因素身份验证,在登录到 VPN 时使用 Google Authenticator 或 Authy 等身份验证应用,但只有少数内部应用程序具有第二层身份验证。这种架构貌似强大,但安全模型非常弱。最近,我们对一次被我们挫败的网络钓鱼攻击的机制做了详细介绍, 其中说明了攻击者如何尝试入侵被 TOTP 等第二因素身份验证方法“保护”的应用程序。幸运的是,我们早就放弃了 TOTP,取而代之的是硬件安全密钥和 Cloudflare Access。本文详细介绍了我们是如何做到的。

网络钓鱼问题的解决方案是通过一个名为 FIDO2/WebAuthn 多因素身份验证 (MFA)协议。所有 Cloudflare 员工都使用我们的 Zero Trust 产品,以 FIDO2 作为安全多因素和身份验证来登录我们的系统。我们的新架构具备防网络钓鱼能力,允许我们更容易地实施最少特权访问控制。

简单介绍一下安全密钥术语以及我们所用的安全密钥

在 2018,我们希望迁移到防网络钓鱼的 MFA 机制。我们看到 evilginx2 以及基于网络钓鱼推送到移动验证器的成熟程度,还有 TOTP。唯一能够抵御社会工程和凭据窃取攻击的防钓鱼 MFA 是采用 FIDO 标准的安全密钥。基于 FIDO2 的 MFA 引入了新的术语,如 FIDO2、WebAuthn、硬(件)密钥、安全密钥,特别是 YubiKey (一家知名硬件密钥制造商的名称)。我们将在本文中引用这些术语。

WebAuthn Web 身份验证标准,当我们在 Cloudflare 仪表板中推出对安全密钥的支持时,我们曾撰文深入介绍过这种协议的工作原理。

CTAP1(U2F) 和 CTAP2 指客户端到验证器协议,其中详细说明了软件或硬件设备如何与执行 WebAuthn 协议的平台交互。

FIDO2 以上两种用于身份验证的协议的集合。区别并不重要,但这种命名法可能引起困惑。

最重要的是要知道,所有这些协议和标准都是为了创建开放的身份验证协议而开发的,这些协议可以防范网络钓鱼,并可通过硬件设备实施。在软件方面,它们是通过 Face ID、Touch ID、Windows Assistant 或类似功能实施的。硬件方面,YubiKey 或其他单独的物理设备通过 USB、雷电接口或 NFC 用于身份验证。

FIDO2 可以防范网络钓鱼的,因为它实施加密安全的挑战/响应,而且挑战协议包含了用户进行身份验证的特定网站或域。用户合法登录到 example.net 和 example.com 时,安全密钥产生的响应是不相同的。

Cloudflare 多年来向员工发放了多种类型的安全密钥,但目前我们向所有员工发放两种不同的 FIPS 验证安全密钥。第一种是 YubiKey 5 Nano 或 YubiKey 5C Nano,旨在一直插在员工笔记本电脑的 USB 插槽中。第二种是 YubiKey 5 NFC 或 YubiKey 5C NFC,可以通过 NFC 或 USB-C 在台式机和移动设备上使用。

2018 年底,我们在一次公司全体活动中分发了安全密钥。在一个简短的研讨会上,我们要求所有员工登记他们的密钥,用它们进行身份验证,并询问有关设备的问题。这个计划取得了巨大的成功,但仍有不完善之处,部分应用程序不兼容 WebAuthn。当时我们还没有准备好全面实施安全密钥,在我们解决问题时需要一些中间解决方案。

开始:Cloudflare Zero Trust 的选择性安全密钥实施

我们负责维护数千个应用程序和服务器,它们由我们的 VPN 保护。我们开始将所有这些应用程序迁移到我们的 Zero Trust 访问代理,同时向员工发放了一组安全密钥。

Cloudflare Access 允许我们的员工安全地访问以往受 VPN 保护的站点。每个内部服务都将检查一个签名凭据,以验证用户的身份,并确保用户已通过我们的身份提供者登录。Cloudflare Access 对我们的安全密钥推出是必要的,因为它为我们提供了一个工具,可以选择性地对最初少数几个内部应用程序执行安全密钥验证。

将应用程序加入 Zero Trust 产品时,我们使用了 Terraform,这是我们首次强制使用安全密钥的 Cloudflare Access 策略。在与我们的身份提供者集成时,我们设置 Cloudflare Access 以使用 OAuth2。作为 OAuth 工作流程的一部分, 该身份提供者告知 Access 所使用的第二因素类型。

在我们的例子中, swk 是拥有安全钥匙的证明。如果有人登录时没有使用安全密钥,就会看到一条有用的错误消息,告知他再次登录,并在看到提示时按下安全密钥。

选择性实施立即改变了我们安全密钥推出的轨迹。我们于 2020 年 7 月 29 日在单一服务上开始实施,在接下来的两个月里,使用安全密钥的身份验证大幅增加了。这一步是至关重要的,给我们的员工提供了一个熟悉新技术的机会。选择性实施的窗口期应该是至少一个月,以考虑度假的人,但事后看来,不需要比这个时间长太多。

通过应用程序切换到使用我们的 Zero Trust 产品并放弃 VPN,我们还获得了其他哪些安全方面的好处呢?对于传统应用程序或未实施 SAML 的应用程序,这种迁移对于执行基于角色的访问控制和最小权限原则是必要的。VPN 将对您的网络流量进行身份验证,但您的所有应用程序都不知道网络流量属于谁。我们的应用程序难以执行多级权限,并且每个权限都必须重新构建自己的认证方案。

加入到 Cloudflare Access 时,我们创建了执行 RBAC 的组,并告诉我们的应用程序每个人应该拥有什么样的权限级别。

这是一个只有 ACL-CFA-CFDATA-argo-config-admin-svc 组成员才可以访问的站点。它强制员工在登录时使用他们的安全密钥,并且不需要复杂的 OAuth 或 SAML 集成。我们有超过 600 个内部站点使用相同的模式,全部都强制使用安全密钥。

可选状态的结束:Cloudflare 完全放弃 TOTP

2021 年 2 月,我们的员工开始向我们的安全团队报告社会工程攻击尝试。他们接到了自称是我们 IT 部门人员打来的电话,引起了我们的警觉。我们决定开始要求所有身份验证都使用安全密钥,以防止任何员工成为社会工程攻击的受害者。

在禁用了所有其他形式的 MFA (SMS, TOTP 等)后,除了 WebAuthn,我们开始正式仅使用 FIDO2。然而,如上图显示,“软令牌”(TOTP)使用并非完全为零。这是因为,对于那些丢失安全密钥或被锁定帐户,需要经历一个安全离线恢复过程的人,替代方法可以帮助其完成这一过程。最佳做法是为员工分发多个安全密钥,以便在出现这种情况时作为备份。

现在所有的员工都在使用他们的 YubiKey 执行防钓鱼 MFA,我们已经大功告成了吗?对了,SSH 和非 HTTP 协议如何处理呢?我们需要一种统一的身份和访问管理方法,因此将安全密钥引入任意其他协议是我们的下一个考虑。

为 SSH 使用安全密钥

为了支持将安全密钥引入到 SSH 连接,我们将 Cloudflare Tunnel 部署到所有的生产基础设施。Cloudflare Tunnel 与 Cloudflare Access 无缝集成,无论通过隧道的是什么协议,同时运行隧道需要隧道客户端 cloudflared。这意味着我们可以将 cloudflared 二进制文件部署到我们所有的基础设施中,并创建到每台机器的隧道,在需要安全密钥的地方创建 Cloudflare Access 策略,SSH 连接将开始通过 Cloudflare Access 要求使用安全密钥。

在实践中,这些步骤并没有听起来那么令人生畏,Zero Trust 开发文档中包含有关做到这一点的优秀教程 。我们的每个服务器都有启动隧道所需的配置文件。Systemd 调用 cloudflared,后者在启动隧道时使用这个(或类似的)配置文件。

tunnel: 37b50fe2-a52a-5611-a9b1-ear382bd12a6
credentials-file: /root/.cloudflared/37b50fe2-a52a-5611-a9b1-ear382bd12a6.json

ingress:
  - hostname: <identifier>.ssh.cloudflare.com
    service: ssh://localhost:22
  - service: http_status:404

当操作员需要使用 SSH 接入我们的基础设施时,他们使用 ProxyCommand SSH 指令调用 cloudflared,用 Cloudflare Access 进行身份验证,然后通过 Cloudflare 转发 SSH 连接。我们员工的 SSH 配置有一个类似这样的条目,可以用 cloudflared 中的 helper 命令生成:

Host *.ssh.cloudflare.com
    ProxyCommand /usr/local/bin/cloudflared access ssh –hostname %h.ssh.cloudflare.com

值得注意的是,OpenSSH 从 8.2 版开始支持 FIDO2,但我们发现使用统一的访问控制方法(所有的访问控制列表都在单一地方维护)是有好处的。

我们的收获以及我们的经验如何帮助你

经过这几个月,毫无疑问,身份验证的未来是 FIDO2 和 WebAuthn。这个过程总共花了我们几年的时间,我们希望这些经验能够对其他希望使用基于 FIDO 的认证进行现代化的组织有所帮助。

如果您有意在自己的组织推出安全密钥,或者对 Cloudflare 的 Zero Trust 产品感兴趣,欢迎通过 [email protected]联系我们。我们的预防措施帮助抵御了最新一轮的网络钓鱼和社会工程攻击,让我们非常高兴,但我们的安全团队仍在不断成长,以帮助预防接下来发生的任何事情。

我们保护整个企业网络,帮助客户高效构建互联网规模的应用程序,加速任何网站或互联网应用程序抵御 DDoS 攻击,防止黑客入侵,并能协助您实现 Zero Trust 的过程

从任何设备访问 1.1.1.1,以开始使用我们的免费应用程序,帮助您更快、更安全地访问互联网。要进一步了解我们帮助构建更美好互联网的使命,请从这里开始。如果您正在寻找新的职业方向,请查看我们的空缺职位
Security (CN)Zero Trust (CN)Cloudflare Zero Trust (CN)简体中文

在 X 上关注

Cloudflare|@cloudflare

相关帖子

2024年3月08日 14:05

Log Explorer:在没有第三方存储的情况下监视安全事件

借助 Security Analytics + Log Explorer 的综合功能,安全团队可以在 Cloudflare 中本地分析、调查和监控安全攻击,无需将日志转发给第三方 SIEM,从而缩短解决时间并降低客户的总体拥有成本...