目录

• 1、SPA的核心逻辑
  • 1.3、为什么需要网络认证？
  • 1.4、回到OSI模型说起
  • 1.5、SPA-自底向上，从底层解决上层的问题
  • 1.6、小结
• 2、CSA-SDP举办黑客大赛带来的辩证启示
  • 2.1、CSA-SDP举办多次黑客马拉松
  • 2.2、CSA SDP主张的防护层次
  • 2.3、开启SPA就一定安全吗？
• 3、SPA的代际之争
  • 3.1、第0代(SPA前身)—Port Knocking（端口敲门）
  • 3.2、第1代(标准SPA) — UDP SPA
  • 3.3、【争议】第2代(SDP厂商标准) — TCP SPA
  • 3.4、【争议】第3代(SDP厂商标准）—TCP+UDP双重SPA
  • 3.5、小结

0、前前言

以前也时不时会在freebuf上看文章，但是一直没发过。忽然发现freebuf可以自由投稿。先把以前在同名公众号上写的原创内容，挑一部分发一下。

后续新内容会考虑同步在freebuf上发送。

1、前言

近些年火热的零信任领域中，一直有零信任三大技术路线SIM的说法， SIM=SDP（Software Defined Perimeter,软件定义边界）+IAM（Identity and Access Management ,统一身份管理）+MSG（Micro Segmentation,微分段）。

其中， SDP主要解决用户到业务的南北向访问安全，在近些年疫情、安全、零信任理念驱动等因素影响下，算是零信任领域中更为主要的赛道，大量厂商各显神通，都推出了SDP相关的产品方案。

而SDP的关键特征，就是SPA ，可见其重要程度。本系列则计划针对SPA进行一些解读，便于大家理解。

注： 零信任理念并不在本系列中展开，后续考虑另设专题讨论。感兴趣的读者可以自行在网络上查找现有材料

篇1：SPA-Learning-001-零信任之初步了解SPA和SDP-SPA

篇2：SPA-Learning-002-零信任SDP之SPA的核心逻辑与代际之争

篇3-SPA-Learning-003-零信任SDP之SPA 典型方案和技术原理

篇4-SPA-Learning-004-零信任SDP之SPA真的能防止DDOS吗？

1、SPA的核心逻辑

1.1、前情提要

在 SPA-Learning-001-初步了解SPA和SDP-SPA中2.5.4章节，我们提到，通过SPA实现的效果其实和Port Knocking是基本一致的，均如下：

1)、拒绝未敲门的终端（所对应的公网源IP）接入：攻击者和正常用户，如果不发起敲门，都不能接入。

2)、仅允许已敲门的终端（所对应的公网源IP）接入：完成了SPA敲门的正常用户，才可以正常访问。

1.2、SPA的本质-网络认证

或许是因为授权依赖于认证，在认证协议中，OAuth2协议最初定义是授权协议，但是却经常被用作认证用途（可参考 Auth-Learning-004-企业身份安全之典型认证/SSO协议浅析）。

而SPA也与之类似，只是并非应用认证，而是网络认证。

SPA(Single Packet Authorization，单包授权)从名称上主要体现的是授权(Authorization)，但是事实上认证(Authentication)才是其核心，SPA也可以被称之为Single Packet Authentication,单包认证。

1.3、为什么需要网络认证？

在 SPA-Learning-001-初步了解SPA和SDP-SPA中，我们用2.3章节，向各位读者说明了应用漏洞随着业务复杂化是难以避免的， 而Port Knocking和SPA都致力于缓解应用漏洞带来的问题 ，缓解思路都是隐藏自身 。至此，我们从概念和效果上，初步理解了网络层认证的价值。

但是PK/SPA此类网络认证究竟是如何解决问题，又解决了哪些问题，深层的逻辑是什么？SPA是万能的吗（显然并不是，那么它的边界又在哪）？

1.4、回到OSI模型说起

如下图，我们从OSI模型的不同层次，来看安全漏洞情况，我们发现如下情况：

1)、 二层、三层，主要面对的是泛洪攻击（Flood），产生的影响是DOS(denial-of-service，拒绝服务）即影响服务可用性的攻击。

2)、四层实质上面对的也是泛洪攻击(Flood) ，只是由于操作系统在内核实现TCP/UDP协议栈，所以协议栈代码可能会引入新的漏洞。比如说windows OS在2021年还引入了2个RCE命令执行漏洞，1个DOS拒绝服务漏洞。

3)、五层、六层最核心的是针对SSL/TLS的攻击，包括泛洪攻击(Flood)以及工具库漏洞(openSSL心脏滴血)、SSL协议降级等攻击。

4)、 7层应用层才是漏洞的集中营：7层应用层的漏洞占比超过99% ， 六层及以下的漏洞，加起来也只占不到1% 。

随便找一个漏洞库检索，挑选任意一页， 几乎全是应用层漏洞 。

从另一个视角其实大家也更容易理解\ ，开发人员写代码，绝大部分写的都是对应OSI应用层代码\ 。

SSL/TLS是使用现成的库，TCP/IP等都是用操作系统厂商、网络设备厂商编写的代码，而且7层以下的总代码量占比和7层应用层的比起来，就像沙砬之于地球。

1.5、SPA-自底向上，从底层解决上层的问题

此时再回到SPA试图解决的问题，结合上述OSI模型就很清楚了。

SPA单包授权，包括之前的Port Knocking，尝试解决的核心逻辑，都是自底向上，从底层解决上层问题，关键思路是隐藏上层，减少暴露。

那么，既然要隐藏上层、减少暴露，但是又要对合法用户开放访问，那么答案显而易见===>在7层以下进行认证。

而网络认证，最典型且通用的层次就是OSI三层(IP层)或四层（TCP/UDP）。

1.6、小结

SPA单包授权意图通过在OSI的应用层以下（如网络层、传输层），对网络访问进行认证 ，从而防范应用层潜在的99%以上的漏洞攻击利用 ，保护应用安全。

2、CSA-SDP举办黑客大赛带来的辩证启示

提起SDP， 不少人还习惯通过CSA举办的黑客大赛来举例子 ，说明几次黑客大赛， 全世界的黑客都没有攻破SDP的防护，以此证明SDP的防护有多么的强 。

但是如果想作为专业性的安全从业者 ，就不能只看表面，还需要辩证地看待黑客大赛，辩证理解SPA的作用和不足。

2.1、CSA-SDP举办多次黑客马拉松

根据CSA官方新闻，CSA共举办过4次以上的SDP黑客马拉松比赛 ，悬赏1万美元，让攻击者对SDP进行攻击。

2.1.1、第二次黑客大赛

本次黑客大赛从2014年9月18日开始，至2014年10月22日宣布结束。参考https://cloudsecurityalliance.org/press-releases/2014/10/21/cloud-security-alliance-software-hackathon-closed-software-defined-perimeter-prevails-again/^[1]。

本次比赛，CSA官方提供了SDP各组件IP以及最终业务服务器的IP地址。并且还提供了一个授权用户的网络数据抓包 （主要是为了方便攻击者分析数据包格式，进行伪造、重放等攻击操作）。

在过程中，超过100个国家的人，发起了一共29亿次以上的攻击，但是全部未通过SPA单包授权的认证校验，访问数据包被丢弃，攻击失败。

2.1.2、CSA第三次黑客大赛

根据CSA官方在2015年4月7日发布的新闻稿件（见： https://cloudsecurityalliance.org/press-releases/2015/04/07/cloud-security-alliance-to-host-third-software-defined-perimeter-sdp-hackathon-top-prize-of-10000-available/^[2]），CSA举办了第三届黑客马拉松。

第三届SDP黑客马拉松重点关注凭据盗窃，旨在验证SDP的设备身份验证功能，以阻止基于密码的攻击。攻击规则是， 将SDP的账号密码提供给攻击者， 但攻击者必须绕过SDP的设备身份验证才能访问具有该帐户的服务器。

从综合防御来看， 第三届黑客大赛降低了一定的攻击难度（提供了SDP的账号密码） 。但是由于账号密码位于OSI应用层（7层） ，而攻击者被SPA拦截在了三层/四层 ，所以仍然攻击失败。

2.1.3、CSA 第四次黑客大赛

CSA官方在2016年RSA大会上举办了第四届SDP黑客马拉松，见：https://cloudsecurityalliance.org/press-releases/2016/02/04/cloud-security-alliance-to-host-fourth-software-defined-perimeter-hackathon-top-prize-of-10000-up-for-grabs/^[3]。

第四届的重心，从安全性转向了多云部署以及可靠性。攻击结果显而易见，仍未突破SPA防护。

2.2、CSA SDP主张的防护层次

当然，CSA-SDP并不只是提出SPA一层防护。

在\ 《CSA SDP_Hackathon_Whitepaper》中，CSA提出了5层安全控制模型。

整体CSA-SDP的防护体系主张如下：

1)、单包授权（SPA）:拒绝未授权设备的所有流量，使得SDP设备自身以及所保护的网络，在互联网上处于隐身状态。

2)、双向证书认证(mTLS) ：通过双向认证，起到防中间人、对设备身份做初步校验的安全目的。

3）、设备验证/授信终端（Device Validation,DV)：只允许受信任的设备（如企业终端）接入到网络。即使采用了mTLS双向证书，证书也有可能被盗用，所以需要校验终端是否在受信列表中。

4)、动态防火墙(Dynamic Firewalls): 默认全部拒绝 (deny all)，根据SPA校验的结果，动态放开指定公网源IP(Permit <IP>)的访问权限。

5)、应用绑定(Application Binding,AppB)： 首先主张对服务端应用采取最小化权限 ，即不再是端口集或网段，而是指定的应用（域名、IP+端口）。同时，作为一个附加建议 ， 用户设备(User's Device)的应用程序也可以白名单化(whitelist application) ， 实现仅允许受信的用户端进程和服务端应用，才能通过加密隧道。

2.2.1、小结-五层技术防护的补充理解（从五层防护转换至NDAP四层认证）

通过将CSA-SDP的五层安全控制模型从技术机制和安全效果两个维度进行总结，可以得出如下结论：

1)、SDP除了传统的应用层账号认证外，至少应具备四大认证能力，从网络、设备、服务端应用、终端进程四个方面，对访问的主客体进行认证校验。

1.1)、N-网络认证(Network Authentication)：SDP server端应对未授权IP的隐身，同时能够针对授权设备定向放到ACL。对应技术机制为：SPA单包授权（动态防火墙属于SPA的附属技术）

1.2)、D-设备认证(Device Authentication):应具备防中间人能力；应能识别出设备的唯一性，并具备防伪造能力，以及能够禁止未授信终端接入；对应技术机制：

1.3)、A-应用认证(Application Authentication):当用户访问服务端应用时，应能够针对特定域名、IP端口进行隧道代理访问，实现最小化权限。非授信应用不允许使用加密隧道。 \ 对应技术机制：\ 隧道技术、RBAC权限模型

1.4)、【可选主张】P-进程认证(Process Authentication):对用户终端上的进程进行白名单限制，非授信进程不允许使用加密隧道。\ 对应技术机制：\ 可信进程技术

2.3、开启SPA就一定安全吗？

显然，并不是 。

前面提到，SPA单包授权机制的本质是N-网络认证(Network Authentication) ，那么SPA也会面临和应用认证同等逻辑的安全漏洞/风险 。

2.3.1、从LBCB-安全漏洞效果维度分析SPA安全风险

从安全漏洞效果维度，参考 HVV-Learning-006-应用安全和理解安全漏洞第2.2章节：

1)、泄漏(Leakage) - 泄漏认证凭证与数据:SPA使用的身份ID/凭证(密钥、证书等）可能在分发、使用过程中被泄漏；甚至还有可能整体被拖库

2)、绕过(Bypass) - 绕过认证和授权：SPA的代码也是由程序员、由自然人编写，所以如果因为SPA代码和设计不当，SPA认证有可能被绕过、授权有可能被放大而产生越权等关联风险。

3)、控制(Control) - 控制应用与系统:SPA如果因为代码或设计不当，对参数处理不当，有可能会产生诸如RCE命令注入、SQL注入、特权SPA码、调试/特权指令等漏洞，从而导致SDP应用被部分或完整控制。

4)、破坏(Break) - 破坏可用性和审计：虽然SPA宣称可以防止DDOS，以TCP Syn-Flood为例，

2.3.2、从EPLR-安全漏洞技术成因维度分析SPA安全风险

从漏洞技术成因维度，参考 HVV-Learning-010-边界突破-浅谈对外暴露的安全设备/应用安全第2.2.2章节 EPLR-漏洞技术成因 。

E-不必要的暴露引发(Expose) ：SPA通常是二进制协议，默认不返回数据，但是依然提供了多个二进制API接口。从代码及设计角度，可能会有不必要的调试接口、特权指令暴露。

P-协议/接口参数校验缺陷引发(Parameter Verification)： SPA作为二进制协议，如果二进制参数校验不当，同样容易引发缓冲区溢出、命令执行等漏洞。

L-接口逻辑&设计缺陷引发(Interface Logic&Design) ：SPA中的认证机制，如果设计或逻辑存在缺陷，可能会引发认证绕过、越权等漏洞。

R-运行时环境缺陷引发(Runtime Environment) ：SPA服务所采用的工具库等同样有可能存在漏洞。举例：假设以java语言+fastjson库处理SPA数据，则有可能被fastjson反序列化漏洞所波及。

3、SPA的代际之争

因为零信任近几年较火的缘故，所以SPA在业界宣传中，俨然会有第几代、第几代的区分。

那么这里对SPA的代际之争，尝试以一种通用方式进行理解和解读。

重点不在于定义第N代和第M代（这个没有实际意义），而是理解SPA不同实现之间的差异性，能够识别优劣和适用场景 。

3.1、第0代(SPA前身)—Port Knocking（端口敲门）

在 SPA-Learning-001-初步了解SPA和SDP-SPA的\ 2.4、端口敲门(Port Knocking)\ 章节，我们曾提过Port Knocking（端口敲门）是SPA的前身。

PK的隐身效果和SPA一致。

但是，存在关键不足为：

1)、认证因素较弱，且容易暴露、伪造

2)、发送多包导致速度慢、体验偏差且可靠性不足

3.2、第1代(标准SPA) — UDP SPA

在 SPA-Learning-001-初步了解SPA和SDP-SPA的2.5章节中，阐明了UDP SPA(标准SPA）的效果：

UDP SPA针对性优化了Port Knocking的两大不足：

1)、【完善解决】认证因素通过在SPA Packet中携带加密信息进行解决，可通过设计实现防重放、强认证能力

\ 2)、【极致优化】\ 只发送一个单一数据包，相比PK提升了认证速度

从安全效果上，参考《本文1.5、SPA-自底向上，从底层解决上层的问题》，能够通过隐身+认证，极大幅降低4层及以上的安全漏洞风险。

正是由于标准SPA采用UDP作为敲门机制，在实际落地过程中，受国内运营商网络、客户自身网络建设缘故，在落地上会遇到一些障碍与挑战。

3.2.1、UDP SPA的落地挑战—敲门放大漏洞

如下图，可以看到，对于公网源IP相同的多个局域网终端，\ 只要有任意一个终端敲门成功，\ 其他终端即可以通过SPA校验访问业务。

尤其是如果业务前面有经过CDN加速 ，会变成同一个源IP，导致只需要一个spaclient完成敲门，其他任意终端均可正常访问。

3.2.2、UDP SPA的挑战—UDP丢包风险

UDP丢包风险：由于运营商对UDP是有一定的打压的，一般有QoS限速、丢包的可能，有可能UDP敲门包丢失，导致不能正常访问业务。

如下述，正常情况下，会导致telnet(业务访问）可能会失败。

3.2.3、UDP SPA的挑战—弱网延迟放大风险

访问延迟相对较高：需要先发送一个UDP包，然后才能发起TCP连接访问业务。有时如果丢包，还需要重试，一定程度会影响业务访问体验。

（暂不详述）

3.3、【争议】第2代(SDP厂商标准) — TCP SPA

正是因为UDP SPA在实际落地中，可能会遇到较多问题。

所以部分SDP厂商推出了TCP SPA模式，该模式在 2022年3月，CSA SDP工作组发布《Software-Defined Perimeter (SDP) Specification v2.0》中被收录，成为SDP SPA的一种事实标准分支。下为CSA SDP2.0原文描述：

TCP-SPA相比UDP-SPA，缺少了端口隐身的效果，TCP连接将能够被建立(telnet能成功），截图如下：

但是TLS连接无法建立，效果截图如下（可以看到有ERR_SSL_PROTOCOL_ERROR ，SSL协议错误的报错拦截）：

3.3.1、简单对比UDP-SPA和TCP-SPA

3.4、【争议】第3代(SDP厂商标准）—TCP+UDP双重SPA

我们看到UDP-SPA和TCP-SPA模式各有优劣，于是显而易见地，将两者结合是否是一个好主意？

TCP+UDP双重模式后，虽然UDP丢包/延迟体验未解决，但是其他安全方面，是结合两者之所长，确实成为了一个更强的强化版。

如下图，可以看到：

1)、相比UDP-SPA模式，双重SPA解决了敲门放大漏洞问题。

2)、相比TCP-SPA模式，双重SPA解决了4层漏洞防御，实现了SDP端口隐藏。

3.5、小结

可以看到SPA在关键技术迭代上，受零信任理念影响，整体迭代在近些年呈加速趋势。共经历了Port Knocking、UDP-SPA、TCP-SPA，包括后续还有TCP+UDP双重SPA几种关键的实现模式 。

但是各个模式各有优劣，总体而言，UDP-SPA、TCP-SPA、UDP+TCP双重SPA三种模式都有其适应场合，应根据实际情况进行测试、选用 。

同时，结合本文 《2.3、开启SPA就一定安全吗？ 》，无论是哪种模式的SPA实现，都应考虑SPA自身的安全性，可参考从EPLR、LBCB或其他自身熟悉的安全维度去检视其综合安全性，避免将SPA当作功能需求，SPA应当是一种设计精良、安全SDL内建的安全机制 ，才能更有效地保护OSI 4层及以上的应用安全。

参考资料

[1]

https://cloudsecurityalliance.org/press-releases/2014/10/21/cloud-security-alliance-software-hackathon-closed-software-defined-perimeter-prevails-again/: https://cloudsecurityalliance.org/press-releases/2014/10/21/cloud-security-alliance-software-hackathon-closed-software-defined-perimeter-prevails-again/

[2]

https://cloudsecurityalliance.org/press-releases/2015/04/07/cloud-security-alliance-to-host-third-software-defined-perimeter-sdp-hackathon-top-prize-of-10000-available/: https://cloudsecurityalliance.org/press-releases/2015/04/07/cloud-security-alliance-to-host-third-software-defined-perimeter-sdp-hackathon-top-prize-of-10000-available/

[3]

https://cloudsecurityalliance.org/press-releases/2016/02/04/cloud-security-alliance-to-host-fourth-software-defined-perimeter-hackathon-top-prize-of-10000-up-for-grabs/: https://cloudsecurityalliance.org/press-releases/2016/02/04/cloud-security-alliance-to-host-fourth-software-defined-perimeter-hackathon-top-prize-of-10000-up-for-grabs/