甲骨文公司對導致Oracle TNS Listener毒藥***的零日漏洞處理方式，讓很多管理員感到困惑，他們不知道該對數據庫採取什麼安全措施。在本文中，我們將研究TNS Listener漏洞的運作原理，分析Oracle的迴應以及企業是否應該調整其網絡防禦系統以更好地保護其數據庫。
TNS Listener漏洞
這個特殊的漏洞很容易被利用，並允許***者執行中間人***以獲取對數據庫服務器的完全控制：它的嚴重程度取決於對它的***深度。該漏洞暴露了TNS Listener服務，此服務將來自客戶端的連接請求路由到所有版本的Oracle數據庫的服務器中。安全研究人員Joxean Loret在2008年發現了這個漏洞，並向Oracle報告了此漏洞。四年後，他發佈了該漏洞的細節信息，因爲他以爲Oracle已經解決了這個問題。
然而，Oracle最近才針對漏洞CVE-2012-1675發佈了一個帶外安全警告。並且，這只是一個解決方法，而不是一個補丁，它提供了保護TNS Listener和抵禦利用該漏洞發起的***的指導信息。2012年4月Oracle關鍵補丁更新也沒有包含針對該漏洞的補丁。Oracle對於發佈解決方案而不是補丁，給出了以下原因：
這個補丁很複雜，這將嚴重影響“向後移植（backport）”或傳統安裝。
這個補丁是存在迴歸問題的代碼的關鍵部分。
客戶要求Oracle不要涵蓋安全補丁，因爲該補丁將會增加回歸到CPU的機會，而這可能危及數據庫的穩定性。
Oracle TNS Listener毒藥***漏洞可能多年來都存在於所有版本的Oracle數據庫平臺中，但這個漏洞只有在下一個主要版本推出時纔可能會被修復。在那之前，管理員必須採用Oracle提供的解決方法，沒有使用該解決方法的Oracle客戶很容易受到遠程未授權***者的***。
如果在這個解決方法發佈之前可能已經發生了***呢？不幸的事實是，惡意***者也許已經獨立地發現這個Oracle TNS Listener毒藥***漏洞，並可能多年來都利用它來***企業數據庫，而管理員可能從來都沒有發現。
在過去，企業將不得不進行取證調查以及分析歸檔日誌文件，看看是否可以檢測到異常命令或者網絡流量來證明有人成功利用了這個漏洞。原漏洞通知時間和Oracle採取的並非完全令人信服的行動時間這麼久，也讓一些安全專家質疑Oracle還知道哪些其他漏洞而選擇不修復。
這種情況也闡明瞭爲什麼計算機安全專家在美國參議院軍事委員會新興威脅和功能小組委員會，告訴成員要假設美國軍方計算機網絡已經被***的原因，基於這個前提，安全工作應更專注於保護敏感數據，而不是控制訪問權限。這些意見不是這個漏洞的結果，而是基於大型企業發生的數據泄露事故數量，它們的系統已經被感染幾個月甚至幾年。
使用網絡外圍作爲數據庫防禦
儘管如此，管理員仍然不應該放棄其外圍防禦。相反地，在這些防禦的基礎上，還應該採用謹慎的網絡分段，併爲數據庫連接強制使用SSL和傳輸層安全加密。預防永遠好過補救，穩妥的企業安全團隊應該假定：在網絡某處存在被感染的系統，惡意軟件正試圖通過該系統收集和滲出重要數據到遠程命令控制中心。
爲了反映這一現實，安全團隊必須重新調整其優先次序、資源和時間。他們應該確保分配足夠的時間和技術（例如數據丟失防護）來尋找可疑內部流量，並在當出現不符合安全政策的請求時，防止數據離開網絡。
開源工具Hone可用於追蹤企業內可疑惡意活動的來源。Hone由美國能源部下屬太平洋西北國家實驗室發佈，它是一個網絡活動可視化工具，通過跟蹤流量到產生流量的應用，Hone能夠幫助網絡經理更好地識別和理解***，並幫助管理員更快地識別感染來源。
隨着軟件代碼變得越來越複雜，供應商不能快速提供漏洞補丁的請擴將會越來越多。Oracle對TNS Listener毒藥***的處理方式充分說明：在供應商發佈下一個修復補丁之前，企業不能坐以待斃。基於這個前提，企業必須重新調整安全防禦措施，監控和控制傳入和傳出流量，以彌補關鍵業務企業應用的不足。