云可見性和端口欺騙:已知的未知因素
與所有技術一樣,新工具都是在以前的基礎上進行迭代,經典的網絡日志記錄和指標也不例外。
在私有云和內部部署中,網絡流量的工具、儀器和監控幾乎沒有變化。現在使用的許多日志和指標都有近20年的歷史,最初是為了解決賬單等問題而設計的。
對交通流模式的可見性是一個額外的好處。流量日志恰好是經久不衰的用例。然而,這種對既定方法的依賴在網絡和端口欺騙中留下了一些漏洞。
但是什么是端口欺騙,為什么它很重要?
就像網絡上的應用程序和數據可見性一樣,現在使用的許多規則和rfc都是在十多年前編寫的,描述了一些東西“應該”如何工作,盡管沒有真正的規則強制執行。
這為很少使用的部署提供了很大的靈活性。當應用程序或服務配置錯誤或惡意參與者想要逃避檢測時,即使對標準端口進行最輕微的更改也會妨礙大多數當前的可見性和檢測方案。
端口欺騙是一種已知的技術,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有自己的端口欺騙類別,而且這種趨勢只會越來越大。
東西交通也需要深入的可觀察性。下一代防火墻(NGFW)在周邊點內部解決了這一問題。然而,公共云則是另一回事,這個問題尚未在東西方或橫向規模上得到解決。
VPC流日志僅記錄與端口號一起發生的對話,并不真正了解正在使用的應用程序或協議。具有深度數據包檢測的深度可觀察性可調查會話,并可以正確識別正在使用的應用程序和協議。
我的公司稱之為應用程序智能,它目前在網絡流量檢查中識別了5000多個應用程序、協議和屬性。
應用程序元數據智能不僅查看外部報頭,還更深入地查看數據包。我們深入研究定義給定應用程序的數據包的獨特特征。這被稱為深度可觀測性。
如果攻擊者通過SSH從同一子網中的工作負載A連接到工作負載B,我的公司的深度可觀察性管道會使用應用程序智能來查看流量的真實情況,并將其報告給安全工具。
在這種情況下,我們可以提醒技術人員端口443上有偽裝成Web流量的SSH流量。這種可觀察性的深度可以輕松地橫跨整個企業,包括公共云和集裝箱到集裝箱通信。
在公有云中,深度包檢測面臨著一系列獨特的挑戰。沒有廣播,要檢查流量,要么需要安全VPC來引導流量通過,要么需要流量鏡像。
第二個也是不太復雜的選項是將流量鏡像到適當的工具。Gigamon解決了第二個問題。好處包括減少部署復雜性和操作摩擦,而不會像在線檢測路徑那樣影響性能。
已知的情況是,開發人員將繼續快速運行,DevOps將無意中部署未知或錯誤配置的應用程序,威脅參與者將不斷尋求利用這些漏洞來創建盲區。
SecOps將嘗試驗證規則和保護,這只有通過網絡衍生的智能和洞察力的深度可觀察性才能真正實現。
如果一個組織無法在非標準端口上檢測到SSH的簡單用例,那么其混合云基礎設施中還可能潛藏著什么其他已知的未知因素呢?