Clash of the Titans

舊片重拍的希臘神話題材，Good，Sam Worthington 越來越紅了。

QuickTime：
http://www.apple.com/trailers/wb/clashofthetitans/
YouTube：
http://www.youtube.com/watch?v=pcBNHZEiX0g

mod_security-2.5.10 套件更新之問題排解

上週日（11/08）一整天 DR 的網站（Fedora 10）都無法順利連結，而前因是 DR 在前一日、也就是週六做例行的套件更新以及自動關機程序，隔天出門前將伺服器開機後走人，後來發現網站連不上，等到晚上回家後才發現 httpd 因為 mod_secuity 模組的關係無法啟動。查看錯誤訊息是無法載入設定檔案，於是去檢查設定檔所在的目錄，發覺路徑不對，就調整了一下，但檔案也有缺，所以就想上網查清楚到底怎麼回事，才發現是套件出了包：

https://bugzilla.redhat.com/show_bug.cgi?id=533124

只要把套件從 2.5.10-1 更換成 2.5.10-2 即可，不過在那當下 yum 更新還抓不到最新的套件，DR 只好從這裡抓下來解決：

http://koji.fedoraproject.org/koji/buildinfo?buildID=140180

更新之後，httpd 可以啟動了，然而新的問題是 DR 網站裡一個叫做「document.gif」的圖檔被擋住了，查看 error.log 發現又是 mod_secuity 所為：

[Thu Nov 12 00:26:05 2009] [error] [client 61.64.173.115] ModSecurity: Warning. Operator GE matched 5 at TX:anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "41"] [msg "Transactional Anomaly Score (score 20): Detects very basic XSS probings"] [hostname "darkranger.no-ip.org"] [uri "/image/document.gif"] [unique_id "SvrlnX8AAAEAAC0TRNwAAAAA"]

查了一下什麼是 XSS，原來就是傳說中的「跨網站指令碼攻擊」，但是這個圖檔非常單純，憑什麼擋下來？所以 DR 做了點實驗，把 document.gif 重新命名為 document2.gif，竟然就過了，這規則也太腦殘了吧？然而 DR 的網頁都是手工的 HTML，為了一條有問題的規則動輒挖出所有網頁改內容，儘管用批次處理做得到卻不太應該，應該還是要從規則著手才是。

於是把 modsecurity_crs_60_correlation.conf 裡頭那行規則註解掉，再將 httpd reload，log 雖然沒訊息了，但圖檔還是被擋，這時 DR 陷入了極大的困惑和不解，並且驚覺自己對 mod_secuity 的設計非常非常的不熟！接下來 DR 查了點文件，認為 modsecurity_crs_60_correlation.conf 大概只是處理 log 的輸出，真正的抵擋規則在別的檔案，直接按字面上檢查 modsecurity_crs_41_xss_attacks.conf 卻看不出個所以然。只好使出殺手鐧，設定檔一個個給 httpd 載進去試，看是載了哪個檔案後被擋下來。然而最後一路到 modsecurity_crs_49_enforcement.conf 才擋下來，而裡頭的規則只是按分數執行抵擋結果而已，並沒有判定 XSS 攻擊的部份。顯然各個設定檔有交互參照性，試到這裡就夠了，還是有請專業吧。

最後 DR 把問題丟到 Core Rule Set 的 mailing list，得到以下的回覆：其實要檢查的是 modsec_audit.log，裡頭可以找到究竟是哪裡的規則把它擋下來，於是 DR 參照 log，鎖定 modsecurity_crs_41_phpids_filters.conf 這個檔案，將裡頭的一條規則註解掉解決，在還沒搞清楚如何撰寫規則前就先這樣處理了。

補充資料，以 mod_security 的中文文件來說，以下這篇是 DR 目前為止找到最「好看」的：

http://support.oss.org.tw/wiki/index.php/ModSecurity

Panda USB Vaccine 與 Removable Malware Removal v1.6

最近兩週 DR 又稍微研究了一下隨身碟防毒的相關工具與方案，首先是 gaptx 的 usbprotector（勿跟 Wow! USB Protector 搞混），不過這工具不太 OK……然後是知名防毒軟體廠商 Panda Security 的 USB Vaccine（疫苗），這個工具就比較有趣，首先它兼具系統和隨身碟的免疫方法，系統的部份由於 DR 先前就整理過可行的免疫方法（針對 Autorun），詳情可參考此文章，因此該工具對於系統的免疫功能就暫不研究。

DR 有興趣的是：它怎麼做到對於隨身碟本身的免疫？於是就安裝了 Panda USB Vaccine，然後插入一支隨身碟給它用用看。只見它在隨身碟裡放入一個隱藏的 autorun.inf - 這乍看之下跟網路上流傳的那些腦殘方法相差無幾，然而 DR 馬上發現這個檔案無法被開啟、被刪除、或者重新命名，無論是用 explorer、命令行介面還是其它工具皆無法，意指這個 autorun.inf 完全無法被 Windows 讀取，這就非常有趣了。

接下來 DR 免不其然的要確認：這個狀況是否完全針對 Windows，還是其它作業系統也是如此？於是把隨身碟拿到 Linux 底下開啟，有趣的是這個 autorun.inf 在 Linux 底下要殺要剮非常容易，還可以直接打開來看裡頭有什麼，但也發現檔案本身並無任何異狀。究竟為何在不同作業系統有不同的存取狀況？又是如何辦到的？

這時 DR 回想起來 Panda USB Vaccine 在安裝時有詢問是否選擇 NTFS 支援（beta），而當時是沒有勾選的，於是 DR 便把隨身碟從 FAT 格式化為 NTFS，再執行看看，果然它就沒有辦法進行免疫動作了。這顯示 Panda USB Vaccine 的免疫功能是從檔案系統層著手的，DR 在網路上的進一步搜尋也更說明了這點，雖然這並未解釋為何在不同作業系統（更精確的講是不同的檔案系統驅動）有不同狀況，並且既然 Linux 不受影響，那麼一個延伸問題是：這個方案算是合理使用，或者其實是鑽 Windows 的設計缺失？

若先不討論這些技術議題，就防治評價而言，建立完全無法讀取的 autorun.inf 算是蠻有效的防禦方案，因為既然無法開啟，那麼裡頭就算塞了 Autorun 指令也無法被 Windows 執行，並且除非更動檔案系統，否則病毒也沒有能力去覆蓋它。


那、那跟 DR 自製的 Removable Malware Removal 有什麼關係？由於 r-m-removal 預設是逢隱藏 autorun.inf 必刪，而 DR 評估了一下，既然有這樣「防毒式」的 autorun.inf 存在， 那麼程式有必要加些判定讓使用者能夠分辨是否具有威脅（何況這種 autorun.inf 還砍不掉）。於是 DR 在 1.6 版加了一段簡單的開檔程式，成功開啟就刪除，而無法開啟就屬於防毒式的 autorun.inf，再回報給使用者。

不過 r-m-removal v1.6 並不只是改了上述部份而已，還有以下改進：

1. 移除逢隱藏 *.inf 檔案必刪的規則，現在只處理隱藏 autorun.inf，這樣比較符合現實狀況。

2. 檔案掃描現在會將目錄直接排除，避免一些擁有「副檔名」的目錄被當成檔案來處理。

3. 發現一些無用的程式碼順勢清理掉。

基本上 v1.6 並不屬於安全性更新，而是功能更新，v1.5 並無可能導致病毒被放行的規則紕漏。任何建議歡迎提供給 DR。