读零信任网络：在不可信网络中构建安全系统15协议和过滤

2024-08-11 09:47 由躺柒发表于 #其他

1. 协议

1.1. IKE/IPSec

1.1.1. 因特网密钥交换协议（Internet Key Exchange,IKE）用于执行IPSec认证和密钥交换
1.1.1.1. 通常以后台守护进程的方式实现，使用预共享密钥或X.509证书来认证对端并创建一个安全会话
1.1.2. IKEv1与IKEv2
1.1.2.1. IKEv1过于复杂，性能也不太好
1.1.2.2. 相比于IKEv1, IKEv2更为灵活和可靠
1.1.2.3. 强烈建议使用IKEv2
1.1.3. IPSec不是单一的协议，而是一系列协议的集合
1.1.4. IKE可以被认为是IPSec的控制平面，它处理会话协商和认证，使用协商的结果为端点配置会话密钥和加密算法
1.1.5. 由于核心的IPSec协议内嵌在IP协议栈中，因此IPSec通常在内核中实现
1.1.5.1. 密钥交换是一种相对复杂的机制，IKE以用户态的守护进程形式实现
1.1.5.2. 内核维护的状态定义了IPSec安全关联，流量选择器则定义了对哪些流量应用IPSec策略

1.2. 身份认证凭证

1.2.1. IKEv2支持预共享密钥和X.509证书
1.2.2. 还支持可扩展身份验证协议（EAP）
1.2.3. 支持EAP意味着IKEv2通过代理可以支持大量其他的身份验证方法（包括多因素认证）
1.2.4. X.509证书是IKE的首选认证方法
1.2.4.1. X.509证书不是为人工使用准备的，它们用于设备。证书不但携带信任证明，而且提供了带有签名的元数据，以及一种利用其身份对数据进行强加密的方法
1.2.5. IKEv2支持预共享密钥，但我们强烈反对使用它们，其带来了大量的密钥生成和分发问题，但最重要的是，需要人为记忆这些预共享密钥

1.3. IKE SA_INIT和AUTH

1.3.1. 所有的IKEv2密钥交换都从一对名为IKE_SA_INIT的数据包交换开始，这个初始交换决定密码套件的选择（和Diffie-Hellman交换一样）

1.4. 密码套件选择

1.4.1. IPSec的密码选择比TLS稍微复杂一些
1.4.1.1. IPSec是在内核中实现的，相较于以软件包的形式实现，其对密码支持的要求更严苛
1.4.2. RFC 6379提出了被称为套件B的密码套件，该标准是由美国国家安全局撰写的，它是一个被广泛接受的IPSec密码套件标准
1.4.3. 不是所有的IPSec实现都支持椭圆曲线算法，而套件B强制要求椭圆曲线加密
1.4.4. 对于主流椭圆曲线算法的安全性的担忧，许多人认为国家政府相关人员的干预可能会影响其安全性

1.5. IPSec安全关联

1.5.1. 4个不同状态：幼年（larval）、成熟（mature）、垂死（dying）和死亡（dead）

1.6. IPSec隧道模式

1.6.1. 隧道模式是目前广泛部署的模式，当IPSec在隧道模式下运行时，SA包含了远程端点的信息，用于封装IP数据包并且在路由到端点的过程中保护它
1.6.2. 经常用于VPN，在需要与远程网络建立安全连接的情况下，管理员能够采用隧道方式将流向该网络的流量通过安全通道进行传输
1.6.3. 既然是隧道模式，那就意味着流量在某个时间点会变得不受保护
1.6.4. 发送者与中间网络之间传输的安全是可以确保的，但在此之后，将无法保证安全性
1.6.4.1. 认为隧道模式其实与零信任体系结构相矛盾

1.7. IPSec传输模式

1.7.1. 传输模式提供了几乎相同的安全保证，只是减去了隧道的部分
1.7.2. 它没有封装整个IP数据包，而是封装了IP有效负载，这对于主机到主机的直接IP通信非常有用
1.7.3. 传输模式并不是与网络中间设备建立一个安全联盟，而是与流量的目的端点直接建立安全联盟，确保端到端应用安全，这个属性使得传输模式能够很好地适用于零信任网络
1.7.4. 成熟的零信任数据中心架构应该选择IPSec的传输模式

1.8. 将IKE/IPSec用于设备认证

1.8.1. 由于IPSec直接在IP上实现，因此它可以处理大多数应用程序流量，而不仅仅是TCP和UDP

2. 双向认证TLS

2.1. 传输层安全（TLS，通常会沿用其前身SSL的称谓）是用来保护Web流量的常见协议

2.1.1. 它是一种成熟的、易于理解的协议，被广泛地部署和支持，并且已经获得一些敏感业务的信任
2.1.2. HTTPS中的S指代的就是TLS（SSL）
2.1.3. 面向一般公众的服务可以接受客户端身份认证的缺失，但其他任何用例都不可接受这种妥协
2.1.4. 双向身份认证是遵循零信任模型安全协议的必要条件，TLS也不例外

2.2. 在TLS密码套件中有4个主要的组件

2.2.1. 密钥交换
2.2.2. 身份验证
2.2.3. 块加密
2.2.4. 消息完整性

2.3. 系统的整体安全性取决于较弱的客户端能提供的最强密码套件

2.3.1. 在TLS握手中，客户端按优先顺序显示其支持的密码套件列表，如果客户端和服务端支持的密码套件有重合，那么服务器会从这个列表中选择一个密码套件，否则会话建立就可能失败
2.3.2. 建议服务器只支持最合理的密码套件

2.4. 协商是一个弱点

2.4.1. 码套件协商被认为是现代加密协议中的反模式
2.4.2. 较新的协议和框架，如Noise，旨在消除协议协商

2.5. 密钥交换

2.5.1. TLS的密钥交换描述了在不安全的通道上安全地生成加密密钥的过程
2.5.2. 它们使用数学函数来协商密钥，而不用明文进行传输（在大多数情况下是这样）
2.5.3. TLS支持3个主流的密钥交换/协商协议，按照优先顺序排列，它们是ECDHE、DHE和RSA
2.5.4. ECDHE基于Diffie-Hellman交换，使用椭圆曲线来协商一个密钥
2.5.4.1. 椭圆曲线密码具备高强度、高效率的特点，它建立在一个难以解决的数学问题的基础之上
2.5.4.2. 从安全性和性能上考虑，它是理想的选择
2.5.5. DHE同样基于Diffie-Hellman交换，但它使用模运算而不是椭圆曲线来协商一个密钥
2.5.6. RSA密钥交换基于非对称运算来验证数字签名的身份（如X.509证书），它使用服务器的公钥来加密传输需要的共享密钥
2.5.7. 当今主流的公钥密码学都基于这样一种假设，即分解较大数字的计算开销非常大
2.5.7.1. 经典的计算必须依赖于一种被称为普通数域筛选法的技术来推导出大数因子，这是一种相对低效的算法
2.5.7.2. Shor算法是一种比一般数域筛选更有效的量子算法，只要有足够强大的量子计算机，它就可以被用来快速破解大多数非对称密钥交换协议

2.6. 完美的前向保密性

2.6.1. PFS（完美的前向安全性）是一种加密属性，基于PFS，私钥的披露不会导致之前协商的会话的泄露
2.6.2. 可以确保窃听者不能记录会话数据以供之后解密
2.6.3. RSA密钥交换不支持PFS
2.6.3.1. 因为我们是直接使用私钥加密和传输会话密钥的
2.6.4. 必须使用DHE或ECDHE以获得完美的前向安全性
2.6.5. 精心设计服务器端密码套件，在可用的情况下先选择DHE协商，必要时返回到ECDHE协商

2.7. 认证

2.7.1. 有3种常见的认证方法：RSA、DSA和ECDSA
2.7.2. RSA认证是较常见的，它在超过99%的基于Web的TLS资源中使用
2.7.3. DSA认证已不再推荐使用
2.7.4. EDCSA是DSA的新表兄，它使用椭圆曲线来提供公/私钥对

2.8. 职责分离

2.8.1. 需要保护的资源是设备，因此将加密功能独立于工作负载本身非常有意义
2.8.2. 要确保所有这些应用程序都确实通过正确的方式使用TLS，在已知漏洞上保持最新状态是非常困难的
2.8.3. 将TLS的配置职责转移到控制平面是非常有用的
2.8.3.1. 到服务的连接被TLS守护进程代理，然后本地转发给应用程序
2.8.3.2. TLS守护进程配置了系统证书、信任权限和节点信息
2.8.3.3. 通过这种方式，可以确保所有的软件都接受设备认证和TLS的安全保护，而不管软件是否支持TLS库
2.8.4. 零信任网络对业务流采用了“白名单”机制，所以可通过限制到已知TLS端点的业务流白名单，确保应用程序业务流量受到保护

2.9. 块加密

2.9.1. TLS握手主要有两个目的：认证和会话密钥的创建
2.9.2. 当无须考虑身份或认证问题时，使用对称加密就可以满足所需的安全强度
2.9.3. 对称加密使用一个单独的密钥而不是公/私钥对，并且与非对称加密相比其计算成本要低得多
2.9.4. 业界一致建议采用AES
2.9.4.1. 它设计完美，并且没有专利保护，可以在硬件中广泛实现，并且已在软件中普遍采用
2.9.4.2. 它非常高效，经过严格的审查/检查，并且保持一致性

2.10. ⑩消息完整性

2.10.1. 消息的完整性即使不是必需的也是一个重要属性
2.10.2. 完整性算法的选择仅限于MD5和SHA系列的散列算法
2.10.2.1. 前者已经被破解
2.10.2.2. 这使得SHA系列成为TLS确保消息完整性的唯一合理选择
2.10.2.3. 不断增长的计算能力导致SHA-1脆弱并易受攻击
2.10.2.4. 建议选择可以合理部署的最强SHA散列算法

2.11. ⑾基于双向TLS进行设备认证

2.11.1. TLS是依赖于协议的
2.11.1.1. 它通常基于TCP协议实现，虽然基于UDP的协议变种DTLS也是可用的
2.11.2. 只要代理和保护的上游节点被一个计算机网络分离开，这种运行模式就不适用于零信任网络
2.11.3. 在零信任网络中，基于TLS协议实现的通信代理必须和应用程序部署在一个逻辑主机上
2.11.4. 在用TLS保护数据中心零信任网络时，应用需要自动化配置以便使用外部的TLS通信，它不像IPSec协议那样是“免费”加密
2.11.5. TLS仍然是目前保护面向客户的零信任网络的较好选择，它在软件和传输网络中都得到了广泛的支持，并且其运作模式直接而可信赖
2.11.6. 大部分Web浏览器本身就支持双向TLS认证，这意味着资源可以直接基于零信任原则进行保护而不需要专门的客户端软件

3. 过滤

3.1. 过滤是数据包被网络上的系统接受或拒绝的过程

3.2. 防火墙确实提供了过滤作用，但它们也可以提供其他服务

3.2.1. 网络地址转换（NAT）
3.2.2. 流量控制
3.2.3. VPN隧道服务

3.3. 传统意义上过滤功能可以由很多系统提供，比如路由器或交换机

3.4. 过滤是一种简单的服务，在网络系统的很多地方都可以应用它

3.5. 许多零信任概念都集中在高级加密和认证系统上，这是因为网络安全的这些方面没有得到应有的设计和考虑

3.5.1. 不应该低估网络过滤的重要性，它仍然是零信任架构的关键组成部分

4. 主机过滤

4.1. 过滤主机上的流量

4.1.1. 主机过滤让网络端点成为其自身安全的积极参与者，其目标是确保每台主机都被配置为过滤自己的网络流量

4.2. 防火墙利用专用集成电路（Application-Specific Integrated Circuit, ASIC）来有效地处理流经设备的数据包

4.3. 软件防火墙比硬件防火墙要灵活很多，它们提供了一组丰富的服务

4.3.1. 比如根据日期和任意的数据偏移（字段）来定义策略
4.3.2. Linux:IPtable
4.3.3. BSD系统：Berkley包过滤（BPF）
4.3.4. macOS：应用程序防火墙和基于命令行的主机防火墙
4.3.5. Windows:Windows防火墙服务

4.4. 零信任网络假设网络中始终充满威胁，需要在每个可能的位置过滤网络流量，通常使用主机防火墙实现

4.5. 通过主机防火墙可以过滤不良网络流量来减小主机的攻击面

4.6. 主机过滤非常容易着手实施，配置管理系统很好地支持了主机防火墙的管理

4.7. 在安全设计中隔离的好处，主机过滤可以从中受益

4.8. 关于主机过滤的问题是，其部署点在网络中的位置太“深”了，会造成大量的额外成本

4.8.1. 增加了拒绝服务（DoS）攻击的可能性，使内部网络充斥大量的无用流量，压垮了相对脆弱的软件防火墙

5. 双向过滤

5.1. 同时过滤主机的出入流量

5.1.1. 一种在接收和发送数据包时同时应用的过滤策略

5.2. 出站（入站的反面）这个术语用来描述离开主机的网络流，这种类型的过滤通常用于管理从私有网络到公共网络的通信，它很少在私有网络内部使用

5.2.1. 入站过滤更容易理解，因为在构建防火墙规则时可以枚举出所有的监听服务，出站过滤则需要更多的记录来得知主机如何进行通信
5.2.2. 通常认为，入站过滤能够阻止网络中的不良通信
5.2.3. 出站过滤需要了解每一个预期的流量，这在传统网络中不常见

5.3. 即使在系统中出现了关键的错误配置，一个部署了全面的双向过滤机制的网络也会受到保护

5.4. 双向过滤不是预防疾病，而是保护被错误配置的系统能够免受错误配置带来的潜在影响

5.5. 在系统中构建双向过滤并没有那么困难，可以通过程序化实现对通信业务流的捕获，捕捉这些流的较好方法是定义细粒度的入站规则

5.6. 出站过滤机制最好与运行在系统上的应用程序隔离，建议在虚拟化或容器化环境的外层实现过滤以便拥有健壮的过滤机制

5.7. 当网络流数据库与运行系统隔离时，双向过滤是较有效的

5.8. Calico项目是动态调度工作负载的虚拟网络系统

6. 中间过滤

6.1. 通过两个主机间的设备过滤流量

6.1.1. 指除了发送方或接收方之外的设备在零信任网络中可以并且应该参与到流量过滤中

6.2. 边界过滤在零信任网络中可以发挥作用，并且在网络结构中的中间设备也可以发挥作用

6.3. 高吞吐量的过滤流量通常是来自互联网入口的流量，在理想情况下，我们希望尽快过滤流量，以减少延迟过滤的影响和成本

6.4. UPnP被认为是有害的

6.4.1. 从主机策略衍生出的边界策略不应该与UPnP混合使用
6.4.2. UPnP是一种用于重新配置用户防火墙的技术
6.4.3. UPnP受到诟病是因为网络上的任何应用程序都可以重新配置边界，在零信任模型中，主机策略和边界创建的例外规则之间应该存在信任链

6.5. 零信任网络不会抛弃所有的边界概念，相反，它们鼓励管理员从主机开始向外扩展，边界设备最终会以某种方式发挥作用，而值得关注的是其在缓解拒绝服务攻击上的应用

6.6. 使用主机策略数据库来动态地规划网络结构本身

6.7. 软件定义网络（Software-Defined Network,SDN）

6.7.1. 它不会盲目地将数据包路由到目的地址，而是根据预期和允许的流量，积极管理交换和路由策略
6.7.2. 将潜在的恶意流量挡在主机之外，减少了攻击面
6.7.3. 主机上基于软件的防火墙在网络中增加了额外的防御层
6.7.4. 想象一个SDN控制器，它只根据强身份认证和授权过程的结果实现流量传输，希望访问网络资源的客户端可以向控制平面发出信号，提供网络访问请求以及相应的凭证，请求成功授权之后，网络过滤或转发规则就会被下发并且执行，但这些规则仅针对特定的已授权业务流