使用 OCI 网络防火墙进行 SSL 转发代理和使用解密规则的入站检查

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

性感的佛珠 · 网站防火墙· 2 周前 ·

果断的青椒 · 网站防火墙· 2 周前 ·

八块腹肌的黄瓜 · 网站防火墙· 2 周前 ·

不敢表白的紫菜 · 安全狗用户服务器自带的防火墙上如何开放端口· 3 周前 ·

重情义的芹菜 · 如何关闭服务器3389 • Worktile社区· 3 周前 ·

活泼的砖头 · 小米路由器3G刷入OpenWrt：从入门到精通· 2 周前 ·

暗恋学妹的双杠 · 胡桃大战史莱姆链接网站下载(胡桃大战史莱姆w ...· 1 月前 ·

跑龙套的玉米 · Amazon釋出EC2 ...· 2 月前 ·

含蓄的人字拖 · Advancing progress in ...· 3 月前 ·

行走的烤土司 · mysql 表列的拓展信息 - CSDN文库· 5 月前 ·

Oracle Cloud Infrastructure (OCI) 网络防火墙服务是基于云的托管防火墙解决方案，它利用来自 Palo Alto Networks 的新一代防火墙技术 (NGFW)。OCI 网络防火墙服务具有先进的机器学习驱动的防火墙功能，可为您的 OCI 负载提供顶级保护，同时在 OCI 生态系统中轻松使用。

OCI 网络防火墙在通过防火墙时检查所有请求，包括传输层安全 (Transport layer security，TLS) 加密流量。根据用户定义的防火墙策略规则，该服务可以执行各种操作，包括允许、拒绝、删除、入侵检测或预防。通过这些强大的功能，OCI 网络防火墙是保护 OCI 工作负载免受各种安全威胁的强大工具。

本教程的目标是提供在 OCI 云的下一代防火墙中使用解密规则实施 SSL 转发代理和入站检查的综合指南。

了解 SSL/TLS 加密的基本知识及其工作原理。

在 OCI 云中配置下一代防火墙以执行 SSL 转发代理和入站检查。

创建解密规则来拦截 SSL/TLS 流量并检查其是否存在威胁。

实施高级加密概念，例如完美正向保密 (Perfect Forward Secrecy，PFS) 和证书固定，以增强网络的安全性。

对配置和实施 SSL 转发代理和入站检查期间可能出现的常见问题进行故障排除。

遵循本教程，您将充分了解使用解密规则的 SSL 转发代理和入站检查，并能够应用此知识在 OCI 云中保护您的网络基础结构。

活动 Oracle Cloud Infrastructure (OCI) 租户。您必须具有在 OCI 中创建和管理网络安全资源的必要权限。

基本了解 SSL/TLS 加密及其工作原理。这包括对 X.509 证书、公钥基础结构 (public key infrastructure，PKI) 以及 RSA 和 Diffie-Hellman 等加密协议的了解。

熟悉防火墙、入侵检测/预防系统和网络监视工具等网络安全概念。

在 OCI 中设置的虚拟云网络 (VCN) 和子网，配置了适当的路由规则、Internet 网关和安全列表。

在 VCN 中创建的 OCI 网络防火墙实例。

由 openssl 创建的 SSL/TLS 证书。

了解如何使用 OCI 控制台或 OCI CLI 创建和管理网络安全资源。

注：建议您在 OCI 中设置一个测试环境，以便在生产环境中实施防火墙配置和解密规则之前对其进行试验。

OCI 网络防火墙策略包含以下列表：

应用程序列表，您可以在其中创建应用程序列表，并为每个应用程序定义协议类型和端口范围。

可以创建可以允许或拒绝访问的 URL 的列表的 URL 列表。

可从中创建 IPv4 和 IPv6 地址或 CIDR 范围列表的 IP 地址列表，您可以允许或拒绝访问这些地址。

上面的列表可用于在防火墙策略中创建解密和安全规则，以允许、丢弃、入侵检测、入侵预防和拒绝流量（如果使用安全规则）以及通过 SSL 转发代理和 SSL 入站检查解密流量。

在本教程中，我们通过在防火墙策略中具有安全规则，通过 Internet 创建了与 Linux 计算机（公共子网：129.146.201.118）的 SSH 连接。

要访问 OCI 网络防火墙，请登录到 OCI 控制台并导航到 身份和安全 选项卡。

TLS 是一种加密协议，可为通过 Internet 在应用程序之间发送的任何数据提供端到端安全性。大多数常见的场景是安全的网络浏览。但是，它可以也应该用于其他应用程序，例如电子邮件、文件传输、视频/音频会议、即时消息和 IP 语音等。

了解 TLS 不保护最终系统上的数据非常重要。它确保通过互联网安全地传送数据，避免可能窃听和/或更改要发送的内容（在途）。TLS 通常在 TCP 上实施，以加密应用层协议，例如 HTTP、FTP、SMTP 和 IMAP，尽管它也可以在 UDP、DCCP 和 SCTP 上实现。

为了保护数据，TLS 依赖于加密技术来加密/解密通过互联网发送的传输中数据。我们将涵盖对称和非对称加密、公钥基础结构 (PKI) 和 X.509 数字证书等术语和概念。

要对网络设置、配置和应用下一代防火墙，您需要了解 TLS 连接（例如 https）的工作原理，包括数字 X.509 证书配置和部署。

加密和类型

加密背后的想法恰恰是为了在“不安全的渠道”中隐藏或隐藏（加密）我们想要从 A 到 B 发送的信息。不安全的通道是通道或路径，我们无法保证任何人不会拦截、窃取或修改（窃听）从 A 到 B 传输的信息，而其他方式。

通过加密，我们可以通过加密（隐藏）原始数据到目标位置来保护通过不安全通道传输的信息。接收者收到后，接收者将能够将收到的加密数据解密为其原始值。

有两种类型的加密： 对称和非对称 。

为了加密/解密数据块，对称加密引擎使用完全相同的密钥来加密和解密数据。这通常称为 主密钥 或 共享密钥 。

虽然这听起来像是实现加密的简单方法，但其中的主要问题是 通过不安全的通道分发 双方之间的 主密钥 。此 主密钥交换 过程将在本教程中使用不同的技术进行处理，包括以下部分中介绍的一种技术：非对称加密。

常见的对称加密算法有：AES128、AES256、Serpent、Camelia 等。

非对称加密

非对称加密/加密，使用一对具有特殊关系的相关密钥：通过一对密钥加密的数据可以 仅加密 另一对密钥和 其他方式 。

通常将此对密钥称为公钥和私钥。公钥可以与所有人共享，而 私钥必须保密 。

非对称加密通过使用公钥进行加密和私钥进行解密（或其他方式）解决密钥分发问题。然而，权衡是非对称加密系统与对称系统相比非常缓慢，并且由于其密钥长度要长得多，因此需要更多的计算能力。

对称加密算法的速度更快，且所需的计算能力更少，但其主要弱点是密钥分发，因为相同的密钥用于加密和解密信息，密钥必须分发给任何需要访问数据的人。

TLS 使用不对称和对称加密，不仅用于加密数据，还用于验证连接中涉及的各方。以下是 X.509 证书执行操作的位置。

X.509 证书

X.509 证书是基于广泛接受的 International Telecommunications Union (ITU) X.509 标准的数字证书，用于定义公钥基础结构 ( PKI ) 证书的格式。X.509 证书使用包含相关公共密钥和私钥的 密钥对 进行归档。如上所述，该密钥对恰好是非对称加密中使用的密钥对，我们选择一种是公钥，另一种是私钥。请记住，使用其中一个密钥加密的任何内容只能由其他密钥解密，反之亦然。

您可以想象，密钥对的 公共部分 （其名称暗示）是公共的，并且可以 自由分布 。私钥必须是 安全密钥 ，并且通常使用对称加密模式中的主密钥进行加密，因此即使被盗，也无法使用它。

除了公钥外， X.509 证书 还包含表示身份（主机名、组织或个人）的其他信息，因此 x.509 证书将此身份绑定到包含的公钥 。

X.509 v3 数字证书的结构如下所示：

签名算法 ID

发布者名称

主题公共密钥信息

公共密钥算法

主题公共密钥 ？ 这是公共密钥

颁发者唯一标识符（可选）

用者唯一标识符（可选）

扩展（可选）

证书签名算法

公钥绑定到用主题名称表示的身份，该名称是具有以下格式的字符串：

国家（地区）（countryName、C）、

组织 (organizationName，O)，

组织部门 (organizationalUnitName，OU)，

唯一判别名限定符 (dnQualifier)，

州或省名称 (stateOrProvinceName，ST)，

公共名称 (commonName，CN)

序列号 (serialNumber)。

其中，主题：C = US，ST = California，L = Mountain View，O = Google LLC，CN = *。google.com

因此，此身份属于 Google，在美国国家/地区、加利福尼亚州和 通用名称 为 *。google.com 。

我们可以使用此证书来两种用途： 分发我们的公钥 和 向他人验证我们的身份 。记住这一点，那里的任何计算机/移动/设备，收到我们的证书时，它将拥有我们的公钥和身份，因此，它将能够使用公钥发送加密的信息，只有我们将能够解密（使用私钥）。此外，证书内部还有我们的身份，因此接收它的设备将能够信任此身份，并确保它与正确的身份交换信息。

如上所述，通过公钥/私钥进行的不对称加密比对称加密（x4 或更多）慢得多，因此不可行。此外，我们还没有解释接收证书的设备如何才能真正信任证书中的身份。At the end, the X.509 certificate is just a piece of text received over an insecure channel .要信任/验证收到的证书，需要 Certificate Authority （可信到 sign 数字证书的组织）。证书颁发机构验证请求证书的公司或个人的身份和合法性，如果验证成功，CA 会颁发签名证书。CA 组织的示例包括 Oracle、VeriSign、D-Trust、DigiCert 等。

那么，从加密的角度来看，这个签名过程是如何运作的？同样，我们将为此使用非对称加密的强大功能，如下所示：

需要有签名证书的公司/网站将创建名为 CSR（Certificate Signing Request，证书签名请求）的东西，只是如上所述的 X509 证书，包括公共密钥和所有身份数据。

此文本文件带有。CSR 扩展将发送到指定的 CA 公司，该公司将评估证书的身份、域名（通用名称或主题替代名称，即 www.mycompanydomain.com 、*。mycompany.com 等）。识别过程将包括自动检查公司/网站的私钥。请注意，CA 现在具有公钥，因此它可以“挑战”公司/网站，以便能够使用私钥（以前使用公钥加密）解密某些东西以显示证书私钥的所有权等。

Once the identity of the company has been proved, the CA will sign the CSR by adding a piece of information to the CSR .信息片段（签名）将是 CSR 信息/内容散列 ( https://en.wikipedia.org/wiki/Cryptographic_hash_function )，然后使用 CA 证书的私钥 进行加密。CSR 信息/内容的散列将确保加密的数据不会被操纵。

现在，CSR 成为可在任何 TLS 连接中使用的真正 X509 数字证书："CSR+the Signature" -> final X509 Certificate

因此，现在我们有 X.509 证书可供采取行动。在 TLS 连接期间接收此证书的计算机/移动/设备如何验证它是否为有效的 X.509 证书？同样，我们将使用非对称加密的强大功能，如下所示：

要检查/验证 X.509 是否是真实的，我们需要验证证书的签名（请记住，签名是证书的加密“散列”部分）。此签名已由全球值得信赖的 CA 公司之一使用私钥“创建”，正如我们大家已经知道的那样， 除由一个私钥加密的所有内容外，只能被公钥对账 。

验证过程需要有一个 CA Trusted Store 公钥，该存储由我们信赖的互联网的所有 CA 机构（DigiCert、Oracle、VeriSign 等）提供。在我们收到证书（包括签名部分）后， 签名的验证过程包括“尝试”以使用 CA Trusted Store 中的至少一个公钥解密签名 。如果这是正（解密已完成），则 CA 是使用其私钥对 CSR 进行签名的人员。记住，使用私钥加密的任何东西只能用公钥解密，反之亦然。

现在我们知道我们有一个有效的证书，其中包括我们尝试连接到的域名，例如 www.mycompanycomain.com （包括在证书的通用名称或主题替代名称字段中），计算机/移动/浏览器将确保我们实际连接到该 DNS 域名 ( www.mycompanycomain.com )，而不是其他域名。这是强制性验证，因为任何人都可以窃取 X.509 证书并尝试从其他 DNS 域服务器（ www.myfakecompany.com 等）使用该证书，这将传递 CA 签名验证过程。

因此，现在所有的计算机/移动设备/设备都可以下载我们的证书的公钥并发送加密的数据，以便我们只能解密它。由于非对称加密比对称加密（x4 或更多）慢得多，因此它不可行。解决方法是同时使用这两者，这也是需要 SSL/TLS 的地方。

TLS 基础知识

TLS 是一种加密协议，可为通过 Internet 在应用程序之间发送的数据提供端到端的安全性。用户大多熟悉它用于安全 Web 浏览，特别是 Web 浏览器中在建立安全会话时显示的挂锁图标。

TLS 使用 对称和非对称加密 的组合，因为这在安全传输数据时在性能和安全性之间提供了很好的折衷。请记住，非对称加密需要 4 倍或更多的计算能力，而不是对称加密。但是，对称加密需要通信两端的同一主密钥才能加密/解密消息，因此使用对称加密的目标是能够交换该消息两方之间的主密钥（或共享密钥），首先通过不安全的通道，然后开始使用此主密钥来确保通信的安全，对使用所选对称引擎发送/接收的所有消息进行加密/解密。

为了通过不安全的通道交换主密钥， TLS 将使用两种不同的技术 ，它们遵循相同的目标，即 在不安全的通道中安全地交换主密钥/共享密钥 ：

Rivest、Shamir、Adleman ( RSA )

Diffie-Hellman 交换 ( DHE ) 和椭圆曲线 Diffie-Hellman 交换 ( ECDHE )

RSA 方法 将依靠非对称加密（私钥和公钥）的强大功能通过不安全的通道交换主密钥。

DHE/ECDHE 将依靠使用数学计算来生成不安全通道中两方之间的相同主键。双方将交换某些良性信息，这些信息将与他们的特权信息混合，因为它通过不安全的渠道旅行，并且可以在没有任何风险的情况下捕获。谈判结束时，双方的数学计算最终都将基于相同的共同秘密或主密钥。更多信息 https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

这两种关键交换方法在称为 TLS 握手 的过程中进行。

已取消屏蔽 TLS 握手

SSL/TLS 握手 是网络中两方（例如浏览器和 Web 服务器）之间的协商，用于 确定其连接的详细信息 。在协商期间，双方将验证（使用 X509 证书）， 同意密码套件 （主密钥将如何交换以及将使用哪些加密引擎，例如 AES256、128，散列）例如 SHA1、2 等 )，最后，当验证发生（收到有效证书）并就如何建立 安全通道完成 达成协议时，我们将有一个来自双方的安全通道。下面是实际步骤：

请注意，在上图中，我们在加密套件协商期间使用 RSA（私钥/公钥）交换要用于议定对称加密引擎（即 AES256）的主密钥（或共享密钥）。如果使用 DHE/ECDHE，而不是使用公钥和私钥交换主密钥，双方将使用 DHE 计算，交换良性材料，最终在双方计算相同的结果。此结果将成为用于对称加密的主密钥（共享密钥）。

任务 1：使用 OCI 网络防火墙进行 SSL 转发代理以及使用解密规则的入站检查

在 Linux 计算机上使用开放 SSL 为出站流量和入站检查创建两个自签名证书。更新 Linux 计算机以信任证书。

我们创建了一个解密规则来解密通过 SSL 转发代理的流量，另一个用于 SSL 入站检查。如同 SSL 出站连接所述，来自公共子网的所有流量都将传输到 OCI 网络防火墙以及通过 OCI 网络防火墙，它正在从互联网网关到互联网的路径。

对于入站检查，它会通过互联网网关将下一个 HOP 作为防火墙，然后访问公共子网中的 Linux 计算机。

根据解密规则，对于使用 Hub-Linux-Machine 的源 IP 地址以及任何目标 IP 地址，流量应该由 SSL 转发代理解密，对于作为 Hub-Linux 的任何来源和目标的入站连接，它应该使用 SSL 入站检查解密流量。

注：对于任何遇到防火墙的流量，它首先检查解密规则，然后检查安全规则。

问题： 如何确定解密规则是否可用于遇到防火墙的通信？

答案： 可以在名称为“解密”规则命中计数附加到防火墙的度量上看到此项。

每当 Linux 计算机尝试访问 Internet 上的 https 网站或者 https 上与 Linux 计算机的任何入站连接时，解密规则命中计数都会增加。

任务 3：将解密规则与安全规则一起使用以允许或拒绝流量

添加到上述用例中，让我们了解如何将解密规则与安全规则一起使用以允许或拒绝流量。如测试案例开头所述，我们可以使用列表来允许或拒绝流量。

此处，我们已为 SSL 转发代理和入站 SSL 检查创建了解密规则。为了进行测试，我们为从 Hub Linux 计算机到 Internet 的出站连接创建了安全规则，以允许访问 *。oracle.com。

注：默认情况下，在 OCI 网络防火墙上拒绝所有流量访问。需要为应允许的流量创建规则。

URL 列表：

安全规则：

现在，Linux 计算机尝试通过 OCI 网络防火墙在 Internet 上访问 *。oracle.com 时会发生什么情况。

发生 SSL 转发代理的第一个解密规则，您将获得度量上的解密规则命中计数增加，如果允许 *。oracle.com，则它将签入安全规则。

在我们的情况下，这是允许的，我们可以在 Linux 上看到 *。oracle.com 的可访问性。

如上所述，默认情况下 OCI 网络防火墙上的所有流量均被拒绝访问。如果 Linux 计算机尝试通过 Internet 访问任何其他 https URL，则先执行解密规则，然后将默认重置流量，拒绝该流量。

您可以从 OCI 网络防火墙日志中查看详细信息。

当我们尝试从 Linux 计算机访问 oracle.com 时：