與所有技術(shù)一樣，新工具都是在以前的基礎(chǔ)上進行迭代，經(jīng)典的網(wǎng)絡(luò)日志記錄和指標也不例外。
在私有云和內(nèi)部部署中，網(wǎng)絡(luò)流量的工具、儀器和監(jiān)控幾乎沒有變化。現(xiàn)在使用的許多日志和指標都有近20年的歷史，最初是為了解決賬單等問題而設(shè)計的。
對交通流模式的可見性是一個額外的好處。流量日志恰好是經(jīng)久不衰的用例。然而，這種對既定方法的依賴在網(wǎng)絡(luò)和端口欺騙中留下了一些漏洞。
但是什么是端口欺騙，為什么它很重要?
就像網(wǎng)絡(luò)上的應(yīng)用程序和數(shù)據(jù)可見性一樣，現(xiàn)在使用的許多規(guī)則和rfc都是在十多年前編寫的，描述了一些東西“應(yīng)該”如何工作，盡管沒有真正的規(guī)則強制執(zhí)行。
這為很少使用的部署提供了很大的靈活性。當(dāng)應(yīng)用程序或服務(wù)配置錯誤或惡意參與者想要逃避檢測時，即使對標準端口進行最輕微的更改也會妨礙大多數(shù)當(dāng)前的可見性和檢測方案。
端口欺騙是一種已知的技術(shù)，MITRE ATT&CK有一個專門針對這種規(guī)避的完整類別。
在非標準端口上使用安全外殼(SSH)協(xié)議是規(guī)避可見性的最常見和最通用的示例之一。SSH通常分配給端口22。
安全工具假定SSH流量將使用端口22，并且世界上幾乎每個安全團隊都嚴格鎖定該端口。常見的做法是在外圍阻止此端口，并將其稱為安全。很容易，對吧?
還沒那么快。如果惡意參與者更改了其SSH流量上的默認端口，該怎么辦?端口443廣泛用于HTTPS/TLS，并且?guī)缀蹩偸翘幱诖蜷_狀態(tài)。
HTTPS流量在現(xiàn)代企業(yè)中無處不在，無論是關(guān)鍵業(yè)務(wù)活動還是個人活動。IT防火墻不會例行公事地阻止端口443/HTTPS，因此使其成為攻擊者的理想入口點。
將SSH更改為在443上運行很簡單。有許多論壇提供了關(guān)于這樣做的合法和不合法原因的詳細說明。幾乎所有的現(xiàn)代云可見性工具都會如實報告流量，而不是實際情況。
即使是云中的工作負載也可能錯誤識別自己的連接。活動的SSH會話可能會被錯誤報告為TLS，因為linux操作系統(tǒng)僅根據(jù)端口采用連接類型。
網(wǎng)絡(luò)會出錯，而操作系統(tǒng)工具也會出錯，因為它們會將此流量報告為已知流量。
如今，幾乎所有流量都由其TCP和UDP端口進行評估。這導(dǎo)致了對流量性質(zhì)的許多假設(shè)。在公共云、私有云和本地云中都是如此。
在當(dāng)今越來越注重安全的世界里，對交通性質(zhì)做出假設(shè)已經(jīng)不像以前那么安全了。SSH是一種非常強大的工具，威脅參與者可以使用它在任何網(wǎng)絡(luò)上進行文件傳輸、隧道傳輸和橫向移動。
這只是一個工具可以有多種用途的一個例子。考慮到其他應(yīng)用和協(xié)議，意識到有多少東西是不可見的變得令人望而生畏。Mitre有自己的端口欺騙類別，而且這種趨勢只會越來越大。
東西交通也需要深入的可觀察性。下一代防火墻(NGFW)在周邊點內(nèi)部解決了這一問題。然而，公共云則是另一回事，這個問題尚未在東西方或橫向規(guī)模上得到解決。
VPC流日志僅記錄與端口號一起發(fā)生的對話，并不真正了解正在使用的應(yīng)用程序或協(xié)議。具有深度數(shù)據(jù)包檢測的深度可觀察性可調(diào)查會話，并可以正確識別正在使用的應(yīng)用程序和協(xié)議。
我的公司稱之為應(yīng)用程序智能，它目前在網(wǎng)絡(luò)流量檢查中識別了5000多個應(yīng)用程序、協(xié)議和屬性。
應(yīng)用程序元數(shù)據(jù)智能不僅查看外部報頭，還更深入地查看數(shù)據(jù)包。我們深入研究定義給定應(yīng)用程序的數(shù)據(jù)包的獨特特征。這被稱為深度可觀測性。
如果攻擊者通過SSH從同一子網(wǎng)中的工作負載A連接到工作負載B，我的公司的深度可觀察性管道會使用應(yīng)用程序智能來查看流量的真實情況，并將其報告給安全工具。
在這種情況下，我們可以提醒技術(shù)人員端口443上有偽裝成Web流量的SSH流量。這種可觀察性的深度可以輕松地橫跨整個企業(yè)，包括公共云和集裝箱到集裝箱通信。
在公有云中，深度包檢測面臨著一系列獨特的挑戰(zhàn)。沒有廣播，要檢查流量，要么需要安全VPC來引導(dǎo)流量通過，要么需要流量鏡像。
第二個也是不太復(fù)雜的選項是將流量鏡像到適當(dāng)?shù)墓ぞ摺igamon解決了第二個問題。好處包括減少部署復(fù)雜性和操作摩擦，而不會像在線檢測路徑那樣影響性能。
已知的情況是，開發(fā)人員將繼續(xù)快速運行，DevOps將無意中部署未知或錯誤配置的應(yīng)用程序，威脅參與者將不斷尋求利用這些漏洞來創(chuàng)建盲區(qū)。
SecOps將嘗試驗證規(guī)則和保護，這只有通過網(wǎng)絡(luò)衍生的智能和洞察力的深度可觀察性才能真正實現(xiàn)。
如果一個組織無法在非標準端口上檢測到SSH的簡單用例，那么其混合云基礎(chǔ)設(shè)施中還可能潛藏著什么其他已知的未知因素呢?
