新工具與其他技術相同,是在以前的基礎上不斷進步,最經典的網路日誌記錄和指標也不例外。網路流量的工具、檢測和監控在私有雲和地端部署中幾乎沒有變化。今日所使用的許多日誌與指標已經存在了將近二十年的歷史,最初是為了解決計費等問題而設計的。這對資料流模式的可視化是絕對有好處的,而流量記錄正好是個經久不衰的經典應用範例。
就像網路上的應用程式和資料可視化一樣,現今正在使用且有關描述某些東西“應該”如何運作的眾多規則和RFC都是十多年前所寫的,但並沒有規則真正的硬性規定一定要照著執行,這為極少數的應用部署提供了很大的靈活性。當應用程式或服務設定錯誤或是惡意行為者想要規避檢測時,即使對標準使用端口進行最少的變更,也會造成大多數市場上常見的可視化和檢測方案被規避。Port spoofing就是一種眾所周知的技術,MITRE ATT&CK中有一整個類別專門提及這種規避檢測的方法。
規避可視化的常見經典範例之一是在非標準端口上使用SSH協議。SSH通常預設分配使用端口22。安全工具通常預設SSH流量將使用端口22,並且幾乎世界上每個安全團隊都將這個端口嚴格看管。常見的做法就是在邊界封鎖這個端口然後對外宣稱目前是安全的。輕輕鬆鬆就搞定了,對吧?事情沒那麼簡單
假如惡意行為者更改了SSH流量的預設端口怎麼辦?端口443通常用於HTTPS/TLS,並且安全政策設定通常都允許通過。HTTPS流量在現代企業中無處不在,包含了關鍵業務流量和個人使用流量。IT防火牆通常不會封鎖端口443/HTTPS,因此使其成為攻擊者的理想通信通道。更改SSH以端口443運行是一項簡單的工作,因為無論是基於正當或非正當理由,許多論壇提供了關於這個操作的詳細說明。而幾乎所有現代的雲端可視化工具卻只會根據端口來報告流量,而不是呈現實際情況的流量。
即使是雲端中的工作負載也會有可能誤判連到本機的會話。在上面的螢幕截圖中,我們看到一個運作中的SSH會話被誤以為是TLS,因為Linux操作系統單純利用端口號碼來判定連接類型。網路端口若是真的被動了手腳,操作系統工具也只會將此流量紀錄為被動手腳後的非預設端口後送出給工具。
現今,幾乎所有流量工具都利用TCP和UDP端口進行評估。這導致了我們所看到的流量圖與現實世界中的真實流量有落差,在公有雲、私有雲和地端部署中皆是如此。在當今安全意識越來越強的世界中,參考與現實有落差的流量圖而做出的任何決定並不像以前那樣安全。SSH是一個非常強大的工具,威脅參與者可以利用它在任何網路中進行資料傳輸、建立隧道和橫向移動。這只是一個例子來告訴大家,一個工具除了原本我們以為的功能外還有多少種其他意想不到的用途,別忘了還有其他應用程式和協議,看不見的隱藏應用只會更令人心生畏懼。MITRE有自己的port spoofing類別,而且這種趨勢只會越來越大。
次世代防火牆(NGFW)已經在本地端的邊界點解決了這個問題。然而,公有雲又是另一回事了,因為這個問題尚未在東西向或橫向流量上獲得解決。VPC資料流日誌只記錄與端口號關聯的對話,並不知道目前正在使用的應用程式或協議。透過深度封包檢測進行深度觀察可以調查對話,並可以正確識別正在使用的應用程式和協議。在Gigamon,我們將此稱為Application Intelligence,它目前在網路流量檢查中可識別5,000多個應用程式、協議和屬性。
Application Metadata Intelligence不僅會查看外部表頭,還會更深入地檢查封包。我們深入研究了定義給定應用程式的封包的獨特特徵,我們稱之為深度可觀察性(deep observability)。
在這種情況下,Gigamon可以提醒您端口443上有偽裝成Web流量的SSH流量。這種深度可觀察性可以輕鬆看見跨越整個企業的東西向流量,包括公有雲和容器到容器的流量。 在公有雲中,深度封包檢測面臨著一系列獨特的挑戰。沒有廣播流量的前提下,要檢查流量就需要一個安全工具VPC來篩選或將流量鏡像。第二個比較不複雜的選項是將流量鏡像到合適的工具。Gigamon屬於了第二個解決方案。這種方式的好處包含了降低部署複雜度和操作摩擦,而且不會像inline工具檢查那樣造成性能衝擊。
眾所周知,開發人員持續追求的是快速迭代,DevOps若是無意中部署了未知的應用程式或是設定錯誤,而威脅參與者將不斷尋求利用這些漏洞來製造破口。SecOps將嘗試驗證控制和保護措施,但這只能透過具有網路安全洞察力的深度可觀察性(deep observability)才能真正實現。如果您無法在非標準端口上檢測到 SSH 這樣簡單的範例,那麼您如何得知在您目前的混合雲基礎架構中還潛伏著哪些其他已察覺的未知風險因素?
【了解更多】立即免費報名,3/28 智慧製造轉型策略論壇!https://bit.ly/3SW24Ji