注意:
- 此教學課程需要存取 Oracle Cloud。若要註冊免費帳戶,請參閱開始使用 Oracle Cloud Infrastructure Free Tier 。
- 它會使用 Oracle Cloud Infrastructure 證明資料、租用戶及區間的範例值。完成實驗室時,請將這些值替代為您雲端環境特定的值。
使用 OCI 網路防火牆進行 SSL 轉送代理主機及使用解密規則進行內送檢查
簡介
Oracle Cloud Infrastructure (OCI) Network Firewall 服務是雲端管理防火牆解決方案,運用來自 Palo Alto Networks 的新一代防火牆技術 (NGFW)。OCI Network Firewall 服務具備先進的機器學習防火牆功能,可為您的 OCI 工作負載提供頂級防護,同時在 OCI 生態系統中輕鬆使用。
OCI 網路防火牆會檢查所有要求,包括傳輸層安全 (TLS) 加密流量,因為它通過防火牆。根據使用者定義的防火牆原則規則,服務可以採取各種動作,包括允許、拒絕、刪除、入侵偵測或預防。OCI Network Firewall 具備這些強大功能,可保護您的 OCI 工作負載免於各種安全威脅。
目標
本教學課程的目標是提供在 OCI 雲的下一代防火牆中,使用解密規則導入 SSL 轉送代理主機及內送檢查的全方位指南。
- 瞭解 SSL/TLS 加密的基本知識以及如何運作。
- 在 OCI 雲中設定下一代防火牆,以執行 SSL 轉送代理主機和內送檢查。
- 建立解密規則以攔截 SSL/TLS 流量,並檢查是否有威脅。
- 實作進階加密概念,例如 Perfect Forward Secrecy (PFS) 和 Certificate Pinning,增強網路的安全性。
- 疑難排解 SSL 轉送代理主機組態和內送檢查期間可能發生的一般問題。
依照此教學課程,您將可完全瞭解 SSL 轉送代理主機及使用解密規則進行輸入檢查,並且能夠套用此知識在 OCI 雲中保護您的網路基礎架構。
必要條件
- 作用中 Oracle Cloud Infrastructure (OCI) 租用戶。您必須具備在 OCI 中建立及管理網路安全資源的必要權限。
- 對 SSL/TLS 加密的基本瞭解及其運作方式。這包括 X.509 憑證、公用金鑰基礎架構 (PKI) 及加密協定 (例如 RSA 和 Diffie-Hellman) 的知識。
- 熟悉網路安全概念,例如防火牆、入侵偵測 / 預防系統和網路監控工具。
- 在 OCI 中設定的虛擬雲端網路 (VCN) 和子網路,已設定適當的路由規則、網際網路閘道及安全清單。
- 在您的 VCN 中建立的 OCI 網路防火牆執行處理。
- 由 openssl 建立的 SSL/TLS 憑證。
- 深入瞭解如何使用 OCI 主控台或 OCI CLI 建立及管理網路安全資源。
注意:建議您在 OCI 中設定測試環境,以在生產環境實行防火牆組態和解密規則之前先進行實驗。
架構
OCI 網路防火牆原則包含下列清單:
-
應用程式清單,您可以在其中建立應用程式清單,以及定義每個應用程式的協定類型和連接埠範圍。
-
您可以在其中建立您允許或拒絕存取之 URL 清單。
-
您可以在此處建立可允許或拒絕存取之 IPv4 和 IPv6 位址或 CIDR 範圍的清單。
-
以上清單可在防火牆原則中建立「解密」和「安全」規則,以允許、刪除、入侵偵測、防止入侵及拒絕流量,以進行安全規則,以及使用 SSL 轉送代理主機和 SSL 內送檢查來解密流量。
測試案例
本教學課程將透過網際網路建立 Linux 機器 (公用子網路:129.146.201.118) 的 SSH 連線,因為防火牆原則中有安全規則。
-
若要存取 OCI 網路防火牆,請登入您的 OCI 主控台,然後瀏覽至識別與安全頁籤。
-
您可以選擇網路防火牆原則,然後開始建立防火牆的原則。
-
對於我們的測試案例,若要從網際網路透過 OCI 網路防火牆在 Linux 機器上執行 SSH,我們已建立連接埠 22 的應用程式清單,IP 位址清單定義了 Linux 公用 IP 和專用 IP,以及允許應用程式清單作為任何和目的地作為 IP 位址清單的安全規則。
-
應用程式清單:
-
IP 位址清單:
-
安全規則。
-
您現在可以瞭解清單如何用來建立防火牆的安全規則。透過使用此規則,我們已對 Linux 機器進行 SSH。
瞭解 TLS/SSL 加密技術
注意:
本教學課程基本瞭解網路安全和加密概念。如果您不熟悉這些主題,建議您參閱本節的詳細資料。
如果您已具備必要的技能 / 知識,您可以略過此區段並繼續進行任務 1。
TLS 是一種加密協定,可針對透過網際網路在應用程式之間傳送的任何資料提供端對端安全。最常見的情況是安全的網路瀏覽模式。不過,它也可以用於其他應用程式,例如電子郵件、檔案傳輸、視訊 / 音訊會議、即時訊息與語音傳輸 IP 等等。
請務必瞭解 TLS 不會保護一般系統上的資料。它可以確保透過網際網路安全地傳遞資料,以避免可能竊聽和 (或) 更改要傳送的內容 (傳輸中)。TLS 一般會在 TCP 上實作,以加密應用程式層協定 (例如 HTTP、FTP、SMTP 以及 IMAP),雖然可以同時在 UDP、DCCP 和 SCTP 上實作 TLS。
為了保護資料,TLS 使用加密技術來加密 / 解密透過網際網路傳送的傳輸中資料。我們將涵蓋對稱和非對稱加密、公用金鑰基礎架構 (PKI) 和 X.509 數位憑證等詞彙和概念。
若要在您的網路設定、設定及套用新一代防火牆,您必須瞭解 TLS 連線 (例如 https) 的運作方式,包括數位 X.509 憑證組態與部署。
加密和類型
加密背後的想法是隱藏或隱藏 (加密) 我們要在「不安全通道」中從 A 傳送至 B 的資訊。不安全通道是一種通道或路徑,我們無法保證沒有任何人會攔截、竊取或修改 (竊取) 從 A 傳送至 B 的資訊,以及其他方式。
Cryptography 允許我們將原始資料加密 (隱藏) 以傳送至目的地,來保護通過不安全通道傳送的資訊。收件者收到後,將能夠將收到的加密資料解密成原始值。
有兩種加密類型:對稱與非對稱。
對稱式加密
為了加密 / 解密資料區塊,對稱加密引擎使用相同的金鑰來加密和解密資料。這通常稱為主要金鑰或共用密碼。
Though it sounds like an easy way to achieve encryption, the main problem here is distributing the master key between the two parties over an insecure channel.本教學課程將使用不同的技術處理此主金鑰交換程序,包括下列各節所述的技巧:非對稱加密。
一些較常見的對稱加密演算法為:AES128、AES256、Serpent、Camelia 等。
非對稱加密
非對稱加密 / 加密,使用一組具有特殊關係的相關金鑰:任何您加密並搭配其中一組金鑰的資料,都可以僅由另一組金鑰解密,以及以其他方式進行解密。
我們通常會將這組金鑰稱為公用金鑰和私密金鑰。公開金鑰可與所有人共用,而私密金鑰必須保持加密。
非對稱加密透過使用公開金鑰進行解密 (或以其他方式解決) 來解決金鑰分配的問題。不過,由於對稱系統的金鑰長度龐大,因此取捨非對稱加密系統會非常慢,因此需要更多的運算能力。
對稱加密演算法可以更快且需要較少的運算能力,但主要弱點是金鑰分配,因為使用相同的金鑰來加密和解密資訊,所以必須將金鑰分配給需要存取資料的任何人。
TLS 使用非對稱與對稱式加密,不僅用於加密資料,也用於認證連線的相關人員。這裡是 X.509 憑證執行動作的位置。
X.509 憑證
X.509 憑證是基於廣為接受的國際電信聯盟 (ITU) X.509 標準的數位憑證,可定義公用金鑰基礎架構 (PKI) 憑證的格式。X.509 憑證是使用由相關公開金鑰與私密金鑰組成的金鑰組來歸檔。如上所述,此金鑰組精確地說,用於非對稱加密的金鑰組,在其中選擇要公開的金鑰與私密金鑰。請記住,您以其中一個金鑰加密的所有內容,只能由另一個金鑰解密,也只能以其他方式加密。
您可以想像一下,金鑰組的公用部分 (即其名稱隱含) 會是公用部分,並且可以常常分散。私密金鑰必須是安全金鑰,在對稱加密模式中通常使用主金鑰加密,因此即使被盜用,沒人還是可以使用。
除了公開金鑰之外,X.509 憑證還包含代表 identity (主機名稱、組織或個人) 的其他資訊,因此 x.509 憑證會將此識別連結到包含的公開金鑰。
X.509 v3 數位憑證的結構如下:
憑證
版本號碼
序號
簽名演算法 ID
發照者名稱
有效期間
此時間之後
此時間之前
主題名稱
主旨公開金鑰資訊
公開金鑰演算法
Subject Public Key 這是公用 KEY
發行者唯一 ID (選擇性)
主體唯一 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.若要信任 / 認證收到的憑證,我們需要憑證授權機構 ( 信任的組織) 才能簽署數位憑證。憑證授權機構會驗證要求憑證的公司或個人身分識別和合法性,如果驗證成功,CA 就會發出簽署的憑證。CA 組織的範例包括 Oracle、VeriSign、D-Trust、DigiCert 等。
因此,從加密的觀點來看,此簽署流程的運作方式為何?再者,我們將使用非對稱加密的強大功能,如下所示:
- 公司 / 網站若需要簽署憑證,將建立一個稱為 CSR (憑證簽署要求) 的項目,除了上述的 X509 憑證之外,還沒有其他任何項目,包括公開金鑰和所有識別資料。
- 此文字檔搭配 。CSR 擴充功能將會傳送至指定的 CA 公司,以評估憑證的身分、網域名稱 (通用名稱或主題替代名稱,例如 www.mycompanydomain.com 、*。mycompany.com 等)。該識別過程將包括自動檢查公司 / 網站的私密金鑰。請注意,CA 目前有公開金鑰,因此它可以「挑戰」公司 / 網站以私密金鑰 (先前以公開金鑰加密) 來解密某些東西,以展示憑證私密金鑰的擁有權等。
- 公司的身分證明之後, CA 將會透過新增一段資訊至 CSR 來簽署 CSR 。資訊片段 (簽章) 將會是 CSR 資訊 / 內容雜湊 (https://en.wikipedia.org/wiki/Cryptographic_hash_function),然後以 CA 憑證的私密金鑰進行加密。CSR 資訊 / 內容的雜湊會確保未曾被操控加密的資料。
- 現在,CSR 會成為真實的 X509 數位憑證,隨時可在任何 TLS 連線中使用:"CSR+the Signature" -> final X509 Certificate
因此,現在我們有 X.509 憑證可以採取行動。TLS 連線期間接收此憑證的電腦 / 行動裝置如何驗證其是否為有效的 X.509 憑證?此外,我們將使用非對稱加密的強大功能,如下所示:
- 為了檢查 / 驗證 X.509 是否真實,我們需要驗證憑證的簽章 (請記住,簽章是憑證的「雜湊」部分)。此簽章已經由全球信任的 CA 公司之一使用其私密金鑰建立,我們也完全瞭解任何加密過的私密金鑰 (只能由其公開金鑰對方加密) 。
- 此驗證程序需要擁有所有在網際網路上信任的 CA 機構 (DigiCert、Oracle、VeriSign 等) 的「CA 信任存放區」公開金鑰。收到憑證後 (包含簽章部分),簽章的驗證過程會包含「嘗試」來解密來自我們的 CA 信任存放區至少一個公開金鑰的簽章。如果這是正值 (已完成解密),則該 CA 是用其私密金鑰簽署 CSR 的金鑰。再者,請記住,使用私密金鑰加密的所有內容,只能以公開金鑰和其他方式解密。
現在我們知道我們有一個有效的憑證,其中包含嘗試連線的網域名稱,例如 www.mycompanycomain.com (包含在憑證的通用名稱或主題替代名稱欄位中),電腦 / 行動 / 瀏覽器將確保我們實際上連線至該 DNS 網域名稱 (www.mycompanycomain.com) 而不是連線至其他網域。這是必要的驗證,因為任何人都可以取用 X.509 憑證,然後嘗試從其他 DNS 網域伺服器 (www.myfakecompany.com 等) 使用憑證,並且會通過 CA 簽章驗證程序。
因此,現在所有的電腦 / 行動檔案 / 裝置都可以下載我們憑證的公開金鑰並傳送加密的資料,讓我們只能解密。由於非對稱加密的速度比對稱加密 (x4 以上) 慢,因此不行。此解決方案使用兩者,必須使用 SSL/TLS。
TLS 基本知識
TLS 是一種加密協定,提供在應用程式之間透過網際網路傳送資料的端對端安全。大部分使用者會透過在安全的 Web 瀏覽中使用,尤其是建立安全階段作業時,網頁瀏覽器中顯示的 padlock 圖示。
TLS 使用對稱式與非對稱式加密的組合,這是在安全傳輸資料時,在效能與安全之間能夠有良好的漏洞。請記住,非對稱密碼編譯需要比對稱密碼編譯高 4 倍或更多的運算能力。不過,對稱式加密在通訊兩側需要相同的主要金鑰才能加密 / 解密訊息,因此使用對稱式加密的目標在於能夠交換對稱式加密雙方之間的主金鑰 (或共用密碼) 會先經過不安全的通道,然後再開始使用此主金鑰來保護通訊、使用所選對稱引擎傳送 / 接收的每個訊息加密 / 解密。
為了透過不安全通道交換主金鑰, TLS 將使用兩種不同技術,採用相同目標,以在不安全通道中安全地交換主金鑰 / 共用密碼:
- Rivest, Shamir, Adleman (RSA)
- Diffie-Hellman 交換 (DHE) 和 Elliptic Curve 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 轉送代理主機及使用解密規則進行內送檢查
-
使用 Open SSL 在 Linux 機器上輸出流量與輸入檢查的 openssl 建立兩個自行簽署的憑證。更新 Linux 機器以信任憑證。
-
在 OCI 中建立保存庫。
-
建立保存庫之後,請建立金鑰。「加密密碼」內容必須為下列格式。
{ "caCertOrderedList": [ "-----BEGIN CERTIFICATE -----END CERTIFICATE-----\n" ], "certKeyPair": { "cert" : "-----BEGIN CERTIFICATE -----END CERTIFICATE----\n", "key": "-----BEGIN RSA PRIVATE KEY -----END RSA PRIVATE KEY----\n" } } -
在網路防火牆原則中,新增對應的加密密碼。
-
選擇「對應的加密密碼」類型作為 SSL 轉送代理主機或 SSL 輸入檢查。
-
選擇已建立的保存庫。
-
選擇加密密碼。
-
新增對應的加密密碼。
-
-
建立解密設定檔。
-
選擇「SSL 轉送代理主機」並檢查「伺服器憑證」驗證選項,或者選擇 SSL 內送檢查,並檢查您流量所需的不支援模式檢查。
-
新增解密設定檔。
-
-
建立解密規則。
-
從您在原則中建立的 IP 位址清單中選取來源 IP 位址,或選擇任一位址。
-
從您在原則中建立的 IP 位址清單中選取目的地 IP 位址,或選擇任一位址。
-
選取用以解密 SSL 轉送代理主機、SSL 內送或不解密流量的動作。
-
選擇解密設定檔和對應的加密密碼。
-
使用解密規則更新原則之後,即可將原則連附至防火牆。
作業 2:將原則附加至防火牆
建立網路防火牆時,可以選擇應連接至防火牆的原則。
我們已建立解密規則,以透過 SSL 轉送代理主機將流量解密,並且使用 SSL 輸入檢查。如 SSL 外送連線所述,來自我們公用子網路的所有流量都會傳送至 OCI 網路防火牆,而透過 OCI 網路防火牆,因此會採用從網際網路閘道至網際網路的路徑。
為了進行輸入檢查,系統會透過網際網路閘道將下一個 HOP 視為防火牆,然後存取公用子網路中的 Linux 機器。
根據解密規則,對於來源 IP 位址,我們使用 Hub-Linux-Machine 和任何目的地 IP 位址,流量應該由 SSL 轉送代理主機解密,以作為任何和目的地的輸入連線 (作為 Hub-Linux 機器),它應該以 SSL 內送檢查解密流量。
注意:若是觸及防火牆的任何流量,會先檢查「解密」規則,然後檢查安全規則。
問題:如何識別讓攻擊防火牆的流量採用解密規則?
答案:您可以在連附至防火牆之「解密規則命中計數」名稱的度量上看到此狀況。
每當 Linux 機器嘗試連線網際網路上的 https 網站,或 https 上 Linux 機器的任何內送連線時,解密規則命中次數就會增加。
作業 3:將解密規則與安全規則搭配使用,以允許或拒絕流量
新增至上述使用案例,讓我們知道解密規則如何與安全規則搭配使用,以允許或拒絕流量。如測試案例開始所述,我們可以使用清單來允許或拒絕流量。
我們已經建立 SSL 轉送代理主機和內送 SSL 檢查的解密規則。為了測試目的,我們已針對從 Hub Linux 機器到網際網路的外送連線建立安全規則,以允許對 *。oracle.com 的存取。
注意: OCI 網路防火牆預設會拒絕所有流量存取。必須為應該允許的流量建立規則。
網址清單:
安全規則:
現在 Linux 機器嘗試透過 OCI 網路防火牆在網際網路上存取 *。oracle.com 時會發生什麼事。
-
SSL 轉送代理主機的第一個解密規則發生,您將會得到測量結果的解密規則命中次數增加,然後在允許 *。oracle.com 時檢查安全規則。
-
如果允許,我們將能夠在 Linux 上看到 *。oracle.com 的連線能力。
-
如上所述,所有流量預設都無法在 OCI 網路防火牆上存取。如果 Linux 機器嘗試透過網際網路連線任何其他 https URL,則首先會執行「解密」規則,然後依預設,系統會重設流量。
-
您可以從 OCI 網路防火牆日誌檢視詳細資訊。
-
嘗試從 Linux 機器連線到 oracle.com 時:
-
嘗試連線到任何其他 URL 時:
-
問題:如何查看針對流量進行的規則?
回答:您可以在 OCI Network Firewall 日誌中看到它。
若為 oracle.com
對於任何其他 URL:
相關連結
確認
認證者 - Luis Catalán Hernández (OCI Cloud Network Specialist and Multi Cloud),Sachin Sharma (OCI 資深雲端專家)
其他學習資源
探索 docs.oracle.com/learn 的其他實驗室,或者存取更多 Oracle Learning YouTube 頻道上的免費學習內容。此外,請瀏覽 education.oracle.com/learning-explorer 以成為 Oracle Learning 檔案總管。
如需產品文件,請造訪 Oracle Help Center 。
Use OCI Network Firewall for SSL forward proxy and inbound inspection using Decryption rule
F79849-01
March 2023
Copyright © 2023, Oracle and/or its affiliates.