[資安觀念] 有備就無患？

在筆者接手過的系統中，備份機制是一個常見但是卻也常常做的不足的事情。在討論何謂足夠的備份機制之前，我們先來看看一個更基本的問題，那就是備份對現代化資訊系統的必要性。 
隨著 IT/IS 技術的不斷進步，高可用性 (HA) 的系統已經是基本的配置。除此之外，災難復原 (DR) 更是考慮到了實體的安全，當主要系統的所在地無法正常運作時，可以在最短的時間內於第二個地點恢復服務。甚至，有了號稱可以提供 100% uptime 的雲端系統，備份豈不多餘？
答案絕對是否定的。 正所謂天有不測風雲，設計再精良的系統，都無法保證絕對不會受到損害，而備份就是資訊可用性的最後一道重要防線：

1. 相較於 HA / DR 的技術，備份技術擁有選擇性多、成熟度高、費用便宜等好處。其中選擇性多可以避免發生被單一廠商吃死的狀況。
2. 即使是號稱 100% uptime 的雲端系統，也無法確保真的不會出問題。雲端系統的架構可能比(大部分的)私有架構更為成熟，但是絕對不會一躍變成神一般的等級。
3. 有些問題非 HA / DR 技術可解決，其中之一正是豬一般的隊友。如果你曾經看過 delete from members (SQL command) 或 rm -rf / (SHELL command) 的 Live Show，你就絕不會懷疑備份的重要性。此時，備份 (加上 transaction log) 就可以避免你直接升天。
4. 備份除了可以保全資料，在不得已 (沒預算) 的情況下還可以用來解決需要長期保留資料的問題 (如日誌)。儘管如此，如果在預算許可的情況下，後者還是應該選擇專門用於封存 (Archiving) 的技術。

既然備份依舊是 IT/IS 不可避免的項目，那麼回到一開始的話題，何謂不足的備份機制？常見的情況包含：

1. 備份的目標不完整。舉例來說，公司有三台資料庫主機，卻只有備份到其中兩台。或是明明主機內有五個資料庫，卻只備份到其中三個。這個問題發生的原因通常是沒有落實相關作業的 SOP 或變更管理。
2. 備份的項目不完整。跟前述有點類似，但是主要是指有些該備份的東西卻完全沒有備份。舉例來說，像是使用者上傳的檔案、系統的設定檔等，可能都忘了加入備份機制。這類問題發生的原因通常在於沒有做好系統分析或數位資產分類。
3. 備份沒有進行相關的檢查工作。舉例來說，確認壓縮檔可以正常解壓，又或者資料庫的備份檔可以確實地予以還原。這部份可以透過自動化的程序簡化檢查工作。
4. 備份資料防護不足。既然備份的資料多為公司重要的數位資產，那麼做好保護以避免不相關人士的存取 (甚至竄改) 就顯得相當重要。簡單來說，備份資料的安全防護至少應等同於線上資料的安全防護，甚至是擁有更高等級的防護機制。
5. 備份資料的存放點不足。我看過最誇張的例子就是將僅有的備份放在同一台主機的同一個分割區內。備份就是為了避免當突發狀況發生時遭受資料遺失的風險，把備份資料放在同一個分割區不就宣告只要硬碟一壞就整個 GG 了嗎？
   硬碟會不會壞？你買硬碟時廠商都清清楚楚地標示了保固期跟 MTBF，所以硬碟壞掉根本就是可預期會發生的災難。你會說我用 RAID 啊，一顆硬碟壞掉沒問題的啦，那 RAID 卡就不會故障並把資料搞亂嗎？相信我，我還真遇過。

針對上述第五點，比較嚴謹的作法可參考所謂的 3-2-1 備份法則 (3-2-1 backup rule)：

1. 每一筆資料至少擁有三個分身 (Have at least three copies of your data)
2. 至少使用兩種以上的儲存媒介 (Store the copies on two different media)
3. 保留其中一個分身於異地 (Keep one backup copy offsite)

把僅有的備份資料放在同一個分割區，明顯違反了 3-2-1 備份法則的所有規則。據此，我們可以考慮將主要的備份資料放在同一個機房內的網路硬碟，而次要的備份資料則放在異地。如果主要資料的所在地為辦公室，可以考慮利用雲端硬碟儲存次要的備份資料。但是如果主要的備份資料所在地為 IDC，那麼辦公室或雲端硬碟就可以擇一以用來存放次要的備份資料。透過幾個簡單的規則，下次就算發生機房失火這種極度恐怖的災難，你也可以全身而退了。

[資安觀念] 您補對了嗎？

這幾天 eTag 的新聞依舊不斷，今天看到一篇來自於自由時報的新聞報導 - 國道計程變國際笑話／遠通資安凸槌 政府罰不到，報導最後提到
“根據資深網管人員康康表示，駭客可能在遠傳網址後面加上特殊字元，剛好可以進入敏感目錄，不能顯示後端資料庫資料是否外洩。但這顯示管理人員太不小心了，因為只要有定期更新修補程式，就可以避免這個問題。”
姑且不論這位康康到底是何方神聖，但是看到結論是只要定期更新修改程式就可以避免這個問題，就知道這位康康果然很資深，講的大概是10年前的觀念。
駭客的攻擊手法千百種，不過大致的趨勢是從早期的攻擊網路、攻擊作業系統、到後來針對應用程式的弱點下手。而應用程式包含所謂的套裝程式 (如 PDF Reader) 以及自行開發的程式，都是可能受到攻擊的目標。而公開的網站應用程式，更是熱門的目標。在這些應用程式之中，自行開發的網站應用程式，自是熱門中的熱門。原因無他，一是這類網站通常含有大量的有價資訊，另外一方面則是這類網站的安全防護能力通常也較差，往往用自動化工具就可以找到不少可憐的羔羊。再加上公開的特性，對駭客來說就像男人看到穿著清涼又身材曼妙的美女在沙灘上走來走去一般令人無法抗拒。
很可惜的是，對自行開發的網站應用程式而言，很多安全問題並不是靠更新系統就可以解決的。必須要從應用程式面下手，認真做好各項的防護工作後才能有效提昇安全性。更好的作法，當然就是導入類似 Secure SDLC 的制度。道理很簡單，因為一開始駭客就不是利用作業系統的漏洞取得這些機密資訊，而是利用了程式沒有做好限制的邏輯缺陷。我相信大家都知道窗戶破了就該把窗戶補好，而不是把原本的圍牆升級為高壓電網。就像我常說的，頭痛醫頭不算什麼，頭痛醫腳才是真庸醫。
所以，儘管定期更新真的很重要，但是再也別把它當成萬靈丹或唯一該做的事情了。

[資安觀念] 意外"總是"會發生

前幾天跟一位多年不見的朋友見面，在談話中他提到了他在年初所遇到的一件慘事，那就是他們線上服務的網路儲存設備的 (Linux-based) 系統整個毀損，甚至造成了部分重要檔案的損失。早在10多年前 .COM 熱潮來襲的時候，那時候因為伺服器等級的硬體設備價格高昂，再加上日誌型的檔案系統還不普遍，所以系統損毀時有所聞。但是以目前硬體設備的價格，硬體式的 RAID 控制卡已經是伺服器的基本配備。在 RAID 的架構下，一般至少會採用可以容忍一顆以上硬碟損毀的設定。再加上目前普遍採用的日誌型檔案系統，要造成系統的損毀，可說是意外中的意外了。只是不管再多的解釋，事情的發生卻是不可爭辯的事實。在面對這類問題時，除了自我解嘲為運氣不好外，是否還能採用其他更積極的作為？

答案當然是有的，而且還是早就已經存在許久的作法。首先，當然就是老生常談的備份。除了定期的備份，針對重要資料甚至可以採用即時備援的架構，以避免備份時間點與意外發生時間點差異所造成的資料損失。備份與備援可以減少原始資料損失時所造成的影響，算是比較被動的作法。比較積極的作法，可以考慮將系統與資料分別存放在不同的檔案系統、不同的硬碟、甚至是不同的 RAID 陣列。事實上，在早期的 Linux 建構建議中，將系統與資料放在不同的檔案系統，一直是一個不可輕忽的作法。但是後來 Linux 的安裝過程過於自動化，連檔案系統的劃分也不需要管理者人工設定，所以這個建議事項越來越難被落實，甚至也很少聽到有人再提起。

無獨有偶的，前一陣子另外一位朋友公司的 ERP 系統，也因為停電而造成資料庫的損毀。資料庫損毀？是的，而且他們用的可是資料庫市場的領導品牌。更何況這可不是意外的停電，而是大樓事先公告的維護性停電。大樓公告被無視化、停電時剛好在進行當日資料庫的備份作業、斷電後重新供電不穩定、前一天資料庫備份無法使用...一連串的巧合，讓他們損失了不少的資料。又是運氣不好？是的，連我一個第三者都覺得運氣真的是太差了吧。

這個事件同樣也只能怪罪於運氣不好嗎？當然不是！大樓管理單位對於停電這麼重要的事情竟然只貼了公告，而沒有主動通知，肯定有所失職。但是大樓管理單位通常不是我們能夠控制的變數，所以我們更應該著力於我們可以控制的事項上。首先，是 UPS 系統的使用。UPAS 可不光是買了接上就行，包含電力不足時的自動關閉也是同樣重要的。此外，針對伺服器在停電後重新恢復供電的行為，是否該設定為自動啟動？還是應該設定為手動啟動？這也是一個值得仔細推敲的問題。最後，備份資料的確認，同樣是容易被許多系統管理者所忽視的重點工作事項。不管是透過雜湊值 (如 MD5) 來確保檔案的完整性，或者是透過匯入的動作來確保資料庫備份資料的正確性，都可以避免日後從口中發出 WTF 的憾事。

這兩個看似完全不相關的事件，同樣都因為新技術的導入，而忽略了原本系統就存在的風險。RAID 讓我們可以避免硬碟損毀所造成的意外，但是它卻無法避免其他意外的發生 (甚至 RAID 本身也可能出錯)。資料庫領導品牌強調他們的資料庫有多種機制可以確保資料不會損毀，但是依舊無法提供 100% 的保證。所以我們在面對這些技術時，千萬別因為這些新奇的保證而忘了其他存在的風險。採用多種保護措施，本來就是管理者用來應付風險的主要策略，千萬不要認為這是資源的重複投資與浪費而縮手。尤其在面對重要資料的保護時，小心、謹慎永遠是不嫌多的，將來有一天你會感謝自己曾經注意到這些"小細節"。

[資安觀念] 談基準的重要性

不管你是不是常有機會跟女生閒話家常，一定都曾聽女生說過類似的話：「我在減肥，我太胖了。」奇怪的是，你可能以為說這話的女生颱風天肯定不能出門，否則就會因為體重過輕而被吹到某個無人島去…所以，太胖這件事對許多人(尤其是女生) 來說，並不是一個客觀的事實，而是主觀的意識。每個女生總喜歡跟自己最瘦的時候相比較，所以隨時都覺得自己很胖，簡直胖到無法見人。

回到資安方面，身為一個專業的管理人員，平時我最怕聽到使用者說出的一句話就是”最近系統好像怪怪的”。這句話有什麼好怕的？因為它代表了無限的可能性。最近？好像？怪怪的？每個字詞本身就是充滿了不確定性，組合在一起的威力就更加龐大了。身為管理者，聽到這句話時你有兩個選擇，一個就是虛應一句：「我知道了，我會查查看。」當然，使用者也都知道你說這句時只是希望結束這個不會有任何結果的對話。另外一個選擇，當然就是試著找出問題並解決之。但是，光憑這句話就要找出問題，你不但需要比福爾摩斯更敏銳的觀察力，還需要比豆豆先生更受老天爺疼愛的好運才有可能成事。

還好，身為一個專業的管理人員，你還是知道有哪些是必須追問的問題。「怪怪的？怎麼樣怪？」「就是系統乎快乎慢。」使用者認真地回答著。好了，使用者已經把問題描述出來了，但是…問題還是繼續藏身在五里霧當中。乎快乎慢？快是多快，慢又是多慢？什麼時候快，又什麼時候慢？當然，你可以繼續追問使用者這些問題，但是我相信這已經超出”正常”使用者能夠提供的資訊了。所以，這時候「我知道了，我會查查看。」這句 showstopper 又會被你搬上檯面，故事結束！

故事當然可以有不一樣的結局，只要你平日已經建立相關的機制並擁有所需資訊，你就可以判斷出是不是真有問題的存在，甚至精準地指出問題的所在。以上面的例子而言，如果我們平日就已經收集每個程序觸發的時間、動作、反應時間等資訊，我們就可以知道”最近”的反應時間跟之前相較而言是否有任何明顯的變化，有哪些動作受到影響，而影響的程度有多大。這些平日辛苦收集而來的資訊，就是我們用來判斷問題的基準值 (Baseline)。也就是說，我們要回答什麼是”怪怪的”這個棘手的問題之前，必須先知道什麼樣才是”不怪的”。我們可不能隨著使用者的心情，就決定系統是快、是慢，就像我們不能聽到女生說她因為過胖所以要減肥就認定她一定很胖一樣。

基準值，其實可以分為兩種類型，一種是人為強制產生的，另外一種則是根據實際的情況所自然產生。前者通常可看成是 (廣義) 政策的一部分，像是規定”所有使用者的螢幕保護程式必須在閒置五分鐘後自動啟動，並以密碼加以保護”就可以視為基準的一種。透過這類基準的建立，我們可以確保安全需求的基本滿足。這種類型的基準值因為屬於人工強制產生，所以在管理上並沒有太多的技術難處。 像是微軟還提供了 Microsoft Baseline Security Analyzer 這個免費工具，可以用來確保 Windows 系統滿足微軟所建議的基準值。

相較於人工強制產生的基準值，根據實際使用情況而自動產生的基準值，可就複雜許多了。以前述例子而言，你知道每個程序執行各項動作的平均/最慢/最快反應時間嗎？你知道這些反應時間與時段的關係嗎？你知道這些反應時間與日期 (幾月幾日/星期幾) 的關係嗎？甚至你知道這些反應時間跟各使用者之間的關係嗎？你可能會說，這麼多的東西我怎麼可能知道。沒錯，要知道的東西實在是很多，但是這並不是管理者用來偷懶的藉口。資安的事情，本來就沒有完善的一天，所以這些資訊的收集與分析，也不是三兩次就可以搞定的。好吧，你可能會說程序的反應時間跟資安有什麼關係(我個人認為是有很大的關係)，那我換幾個問題來問。你知道使用者通常什麼時候登入系統進行作業？每次大概登入多久？從哪邊登入？這些資訊的收集與利用，其實跟我之前談到的日誌管理有很大的關聯性，只是收集的內容更多，應用範圍更大而已。

唯有透過這些資訊的收集與分析，我們才能精準的回答”最近系統好像怪怪的”這類棘手的問題，甚至是主動發現隱而未發的問題，防範於未然。事實上，這個概念被廣泛應用在 IDS、防毒軟體、SIEM 等相關產品上，只是通常以”異常行為偵測”的名字出現。”異常行為偵測”立意雖好，但是在實務上同樣會面臨沒有收集到的資訊就沒辦法分析的根本問題。雖然目前因為儲存技術的進步以及儲存成本的下降，使得儲存大量資料變得可行，但是資訊數量的成長速度卻有可能遠大於成本下降的速度，導致總體成本並沒有隨之下降。此外，正常與異常之間的分際，通常也不如黑與白一般的清晰而無爭議，所以”高誤報率”與”高漏報率”是這類功能很難擺脫的陰影。

嚴格說來，類似的問題存在於各個領域當中。不管是金融投資、企業運作都有監控的機制與系統，而這些系統不但可以消極的指出問題之所在，更可以積極的指出成長的機會。商業智慧 (BI) ，正是這類系統運作於企業運作的當紅應用。相較於 BI 的火紅，在資安擁有類似訴求的 SIEM 顯然在受到企業主的重視程度上遠遠不及於 BI。這幾乎是所有資安產品的相同宿命，但是因為 SIEM 的技術難度較高，一般 opensource 產品不容易有所表現。而那些提供免費版本的商業軟體，卻有有使用上的限制。更甚者，導入這類系統其實並不會讓管理人員生活的更美好 (至少在可見的未來是如此)，因為有更多的資料需要判斷，而這需要一個清晰的腦袋與足夠的經驗。企業主不知道或不重視這類系統，再加上導入這些系統反而會增加管理者的負擔，也難怪這些就成為雙方不願意去揭開的祕密。畢竟，「我知道了，我會查查看。」在大部分的時候都還挺有用的。但是如果你是一個目標導向的管理人員，類似的機制與資訊，絕對會是你最為強大的助力。 而對於一個長期穩定運作的系統，了解並掌握這些隱藏於事實底下的基準值，更是絕對不可缺少。

最後，你可以也應該用證據向使用者證明為什麼系統沒有像他感覺的一樣有乎快乎慢的問題。但是，你千萬別跟她爭論她一點也不胖，尤其是絕對別拿 BMI 那套跟她說。

[資安觀念] 利用封鎖避免密碼遭受暴力破解法(錯誤嘗試)

密碼的選定，一向是一個很兩難的議題。太過簡單的密碼容易被猜到，而太過複雜的密碼也因為難以記憶而逼迫使用者利用各種秘技加以繞過(如自動記憶的功能，甚至是直接把密碼大剌剌地寫在螢幕前的便利貼上)。不過不管如何選擇，密碼本身都難以避免一種技術性很低的破解方式，那就是暴力破解法。只要給予足夠的時間，任何的密碼都可以在嘗試過所有可能組合之後被猜到。面對這類攻擊行為，我們能做的就是讓所有可能的組合範圍盡量龐大(所以要求在密碼當中使用更多的字元和特殊符號)，另外一個應對之策就是減緩嘗試的速度。以減緩嘗試速度來看，許多應用程式會在密碼輸入錯誤之後停頓一段時間(如一秒鐘)才允許下一次的登入嘗試。一秒鐘對於人類來說或許是一個很短的時間，但是對於自動化的攻擊程式來說可就算是天長地久了。至於要停頓多久，那就看應用程式開發人員自己的判斷了，有些可能是固定的時間，有些則可能讓停頓的時間隨著錯誤次數的增加而越來越長。

除了延緩可以再次嘗試登入的時間，更嚴謹的系統甚至會進行封鎖的動作，而封鎖的對象一般是針對帳號或 IP 位址。然而，不管是針對帳號或 IP 位址的封鎖，都無法避免駭客利用這些特點對系統進行阻斷服務攻擊 (Denial of Service, DoS)的可能性。舉例來說，如果應用程式會針對嘗試登入錯誤達三次的帳號進行封鎖，駭客只要故意利用此帳號故意登入錯誤三次，就可以讓這個帳號無法使用。雖然針對帳號或 IP 位址的封鎖，兩者之間並沒有矛盾之處，甚至也可以同時進行，但是在大多數的情況下應用程式僅會針對一個項目予以封鎖。

簡單來看，以帳號形式的封鎖比 IP 形式的封鎖更容易遭受阻斷服務的攻擊，原因在於駭客可以輕易地使用各個帳號進行嘗試登入的動作。相較於帳號，駭客要假冒合法使用者的 IP 位址而使得這些 IP 位址受到封鎖，在技術上的難度就顯得高了許多。封鎖 IP 位址比較大的風險在於如果這是一個經過 NAT 轉換過的 IP 位址，封鎖此一 IP 位址可能就代表了有一大群的電腦因此都同時遭受封鎖。

除了封鎖的對象，封鎖機制還有另外一個必須考量的重點就是封鎖的時間長短。封鎖的時間越長，對駭客而言在進行錯誤嘗試的攻擊時就須花費更多的時間，但是另外一方面也讓阻斷服務攻擊一旦成功時所造成的影響越嚴重。封鎖時間的極致，就是必須由管理者手動解除封鎖，而不是在固定的時間後自動解除。這類系統雖然安全性很高，但是卻會大幅增加管理者的負擔，因此使用上必須格外謹慎。

其次，阻擋的方式亦會決定阻擋的成效。阻擋可以分為本機與網路兩種形式，本機最常見的方式就是透過主機型的防火牆 (例如 iptables)，而在 Linux 下還有 /etc/hosts.deny 也可以用來當做阻擋的機制。至於網路的形式，包含網路型的防火牆以及路由器/交換器的 ACL，都是常見的阻擋方式。在主機上進行阻擋，可以同時應付來自外部與內部的攻擊。而如果利用網路進行封鎖，在應付來自內部的攻擊上可能就會力有未逮。然而對於一個異質環境而言，如何在不同的作業系統上統一管理封鎖的機制，是利用主機進行阻擋時所必須面對的嚴峻挑戰。

談完了封鎖的基本概念，我將在下一篇跟各位分享如何在 CentOS 下利用 fail2ban 這個套件達成封鎖的目的。

[資安觀念] 加密≠安全

每次一有機會跟從事軟體開發的朋友聊天時，我就會問一下他們有關軟體安全的問題。當然，我問的問題很簡單，就是他們的軟體有考慮安全的問題嗎？嗯，其中一種蠻常聽到的回答就是：「有啊，我們的資料在傳輸時有加密。」或者是「沒有耶，我們的資料都沒有做任何的加密。」

噹！這樣的答案聽起來好像很有理，卻是對軟體安全有著極大的誤解。對於軟體安全而言，從需求面可以分成兩大類型，第一類是安全性功能 (Security Feature)，像是資料在儲存時要進行加密就是屬於這類需求。另外一類需求我們稱為安全軟體的需求 (Requirements for Secure Software)，也是大家比較不熟悉的部份。舉例來說，避免程式受到跨網站腳本攻擊就是屬於安全軟體的需求。

兩者之間的分別其實並不是那麼地明顯，甚至有時候我們也可以把第一類需求歸屬在第二類需求之中。但是簡單來看，安全性功能依舊是屬於產品功能的一部分，所以可視為是用來解決客戶問題的手段。例如，將資料在加密後才加以儲存就可以避免使用者的資料被有心份子所窺探。除了加密之外，像是身分驗證也是很常見的安全性功能。相較於安全性功能，安全軟體的需求解決的是軟體本身的問題，像是如何避免有心份子利用軟體的錯誤取得寶貴的資料，或者是如何確保軟體在遭受攻擊時可以繼續運作。

事實上，軟體安全強調的並不是第一類型的需求，反而是第二種類型。就算你開發的軟體跟安全本身沒有任何關係(例如公司的公告欄網站)，依舊有可能因為本身沒有做好安全的防護而導致安全問題的產生。以公司的公告欄網站為例，如果程式存在跨網站腳本的弱點，那麼就有可能讓有心份子修改公告，把自己升職為總經理。也就是因為這樣，所以我們在討論軟體安全時，不管該軟體是不是具有安全性功能，都必須考慮到安全軟體的需求。

這兩種類型的需求往往各自獨立，但是必須特別注意的是，一旦安全性功能出現問題，其所導致的危害往往將更為嚴重。舉例來說，一旦身分驗證系統出現問題，那麼就有可能導致系統內所有資料的外洩。所以對於安全性功能來說，我們通常必須更加小心地確保其沒有安全上的疑慮。除了安全性功能外，一些高價值的功能(如商品交易)也是必須多加小心的地方。

針對安全軟體的需求，通常由安全政策所衍生，而這些政策則來自於公司管理階層的考量、採用的標準、甚至是法規要求。此外，也應該包含對於各式威脅與攻擊手法的防範措施。想要進一步了解此話題的讀者可以參考這篇文章。

[資安觀念] 駭客利用 Honeypot 反將一軍

之前我在 [從電影看資安] 誰才是大將軍 - 大兵小將 這篇文章中提到資安專家利用假冒的觀念來減少危險，後來甚至演變出所謂的 Honeypot/Honeynet，這類機制不但可以用來減少駭客攻擊的有效性，甚至可以用來學習駭客的行為以利資安專家對抗駭客所發動的攻擊。我在文章最後提到假冒的觀念對於攻擊與防守的雙方都同樣重要，甚至攻擊方對於假冒更是駕輕就熟，畢竟攻擊要成功，完美的假冒往往是一個基本條件。但是像是 Honeypot 這種用來誘敵的機制，對於攻擊一方的用途卻是到了近期才被加以利用。這倒也不是說明資安專家就比駭客更加聰明，而是資安專家往往比較被動，所以對他們採用 Honeypot 的效用不大。不過一旦駭客發現這是一個好方法，他們絕對不會放棄，而且我相信駭客可以發揮出更好的效果。因為駭客只要放出足夠的煙霧彈就夠資安專家們忙上好一陣子了，而在現今的攻擊情境中，好一陣子已經可以產生決定性的效果。事情會怎麼演變，就讓我們繼續觀察吧。

 

相關連結：

• Attackers Now Using Honeypots to Trap Researchers

[資安觀念] SaaS 與 DoS/DDoS

DoS/DDoS (阻斷服務攻擊) 對許多人來說，早已經是耳熟能詳的名詞。以 DoS 的定義來說，只要能夠讓服務中斷，不管用什麼方法都可以算是 DoS 的攻擊。所以，拿榔頭把連結伺服器的路由器給敲爛，絕對也是 DoS 攻擊的一種。這樣的攻擊方式除了被逮捕的風險高了許多，而且在效率上也不夠好。所以除非你跟某家企業有深仇大恨，而且報著必死的決心，不然請勿輕易嘗試此一作法。也因此以網路為主的遠端 DoS/DDoS 才是主要的攻擊手法，駭客想盡一切辦法讓使用者無法連結到某個企業的網路服務，像是把網路頻寬或伺服器的運算資源消耗殆盡。

而這一兩年極為熱門的話題 - SaaS (或大家比較常聽到的雲端運算)，除了它本身產生的資安考量外，SaaS 與 DoS/DDoS 還有其他的關聯。首先，SaaS 的架構讓駭客擁有了更多且更便宜 (甚至免費) 的資源來對攻擊目標的資源進行消耗的行為。嚴格來說，甚至可以說是以 Botnet 為主的地下經濟本身就是一種 SaaS 的服務，只是買方甚至連軟體都不用操作就可以收到結果。另外之前提到利用 SaaS 架構提供破解 WPA 的服務，雖然不是用來進行 DoS/DDoS 的攻擊，卻也是利用 SaaS 來增強破壞力的應用。

除此之外，隨著 SaaS 架構的風行，有人預計利用 DoS/DDoS 攻擊手法來對企業進行威脅的事件將會持續增加。原因之一是很多 SaaS 架構採用用多少算多少的計費方式，這樣的方式也就表示用的越多，帳單的金額就越高。在此情況下，DoS/DDoS 攻擊就算無法癱瘓企業的網路服務，也將使得帳單金額大增。因此，駭客可以利用這樣的預期損失而對企業進行事前的勒索。我個人覺得這雖然有其道理，但是 SaaS 的服務通常可以設定帳單金額的上限，所以在最差的情況下，被攻擊企業的網路服務也”只是”完全停擺，並不會有金額大爆炸的情況發生。倒是 SaaS 的模式，讓企業遭受 DoS/DDoS 攻擊時的損失容易量化，因此方便駭客對勒索金額進行”合理的”喊價。不論如何，當 SaaS 讓資源的應用變成價格化後，DoS/DDoS 攻擊已經不再只是單純的”給他死”，而有更多的操作空間可以讓駭客獲取利益。這年頭，當駭客不但要有技術能力，還得有商業頭腦才行。

 

相關連結：

• Amazon EC2 cloud harbours botnet
• Q1 2009 Distributed Denial of Service (DDoS) Report @ Verisign (PDF)

[資安觀念] Virtual Patching

之前我討論過許多次關於更新的重要性並介紹了相關的工具，然而對於許多資訊背景的人員來說，上補丁 (Patching) 一詞或許比更新更令人覺得親切。不管是叫做更新或是上補丁，指的都是利用置換程式執行檔 (或其他相關檔案) 的方式來修正應用程式 (包含作業系統等各種程式) 的問題，這類問題包含安全性的問題、功能的提升、或是一般操作性的錯誤。

雖然 Patching 是解決應用程式問題時最有效也是最重要的方法，但是 Patching 在實際的應用上卻也存在著不少的困擾：

• 如果存在問題的應用程式是商業軟體，使用者通常只能等待原廠提供更新檔案。在此之前，使用者無法對應用程式本身做任何的處理。對於安全性的問題而言，這段更新前的空窗期將會讓應用程式處於一個毫無防備能力的困境。這類問題就是所謂的 Zero-day Attacks。
• 早期的攻擊手法多以網路與作業系統作為目標，而這類產品的供應商大多屬於大型的組織，所以提供更新的速度與品質具有一定的質量。但是現在攻擊手法多以應用程式為主要攻擊目標，所有相關的供應商服務能量不一，再加上技術能力的良莠不齊，導致等待時間的空窗期變得更長，使用者甚至無法取得正式的更新檔案。
• 就算是使用 Open Source 的應用程式，一旦發生問題後雖然使用者可以自行對於應用程式本身進行修改，但是對大多數的使用者而言並不具備這樣的技術能力與資源 (人力/時間)。再加上原開發團隊屬於志願性質，因此對於提供更新的保證顯得更加的薄弱。
• 組織在進行實際更新作業前，往往必須經過審慎的測試過程。對於越重要的系統，測試過程的時間也就越長，也就是說越重要的系統處於未更新的時間越長。然而這類系統一旦發生問題，所產生的危害卻也更大。在兩者影響相互放大的情況下，讓問題的嚴重性急速惡化。

因為 Patching 存在這些問題，所以有了 Virtual Patching 這個概念。Virtual Patching 一詞在 2003 年就引進於 ISS 的產品 (Internet Scanner) 之中。簡單來說就是當 Internet Scanner 發現系統存在安全性的問題時，就利用 IDS 的規則來偵測攻擊行為的發生。也就是說 Virtual Patching 並不是針對有問題的應用程式本身進行修正，而是採用外掛 (IDS) 的方式讓外界無法有效地利用應用程式的缺陷加以攻擊。早期 IDS 僅能提供偵測的能力，但是目前的產品已經透過整合 IDS/IDP 與各式各樣的防火牆 (傳統的 Firewall、Web Application Firewall、Database Firewall) 來達到即時阻擋的能力。

雖然 Virtual Patching 可說是一種治標不治本的防禦方式，但是透過全自動化 (至少在理論上) 的作業方式，可以大幅縮短應用程式毫無防備能力的空窗期。在 Web 應用程式大行其道的今日，Web 應用程式所帶來的安全議題不但急速惡化，而且開發團隊 (不管是供應商或是內部人員) 的技術能力與資源與實際的需求也呈現更大的差距，所以 Patching 的困境也愈形嚴重，因此 Virtual Patching 的概念受到許多安全廠商的重視。這些廠商利用 Web Application Scanner 與 Web Application Firewall 的整合，達到發現安全問題與防堵的全自動化，可以有效減少 Web 應用系統無防備能力的空窗期。雖說這樣的機制在使用上確實很方便，但是依舊有一些必須特別注意的地方：

• 應用系統的安全問題往往不只侷限於實作的層面，需求與設計階段所產生的安全問題影響通常更大。Virtual Patching 必須先利用掃描的方式發現問題後才能防堵問題，而自動化的掃描適用於找出實作方面的問題，對於需求與設計方面的問題幾乎沒有任何偵測能力，所以這類機制註定無法全面解決 Web Application 的安全問題。
• 這類機制透過 Web Application Firewall 達到防堵的目的，而 Web Application Firewall 多採用 Blacklisting 的方式。Blacklisting 在大多數的情況下所帶來的安全性遠不及 Whitelisting 的方式。
• 此方法採用的治標不知本的方法，長久來說對於整體系統的安全提昇助益有限，甚至往往是有害的。就像生病吃特效藥一樣，有用的特效藥反而讓人忽略了平常維持身體健康的重要性。所以一旦特效藥失效，或是感染的疾病沒有特效藥可以醫治，病情的惡化程度反而更為加劇。也就是說如果因為過度依賴這樣的機制而使得開發團隊失去提昇 Web Application 安全的能力，長久來說對於整體 Web Application 的安全環境反而是有害的。

寫到這裡，您一定猜到我要說什麼。那就是跟所有的安全議題一樣，Web Application 的安全性絕不是光靠一種機制就可以完全解決，不管這個機制是治標還是治本。唯有必須透過多層次 (Layered) 的防禦機制，才能夠提供較為完整的安全性。而所謂的防禦機制，絕對不僅限於事後的防範，更應該從 Web Application 的發源時期就開始考量與實施，而這就是 SSDLC (Secure Software Development Life Cycle) 的範疇了。

[資安觀念] DDoS，擋的掉嗎？

再談到 DDoS 之前，我們要先談到 DoS (Denial of Service，阻斷服務攻擊)。 DoS，嚴格來說其所指的並不是一種特定的攻擊方式，而是所有影響資訊可用性 (Availability) 的破壞行為。換句話說，DoS 並不以竊取機密資料 (Confidentiality) 或破壞資料完整性 (Integrity) 為主。對許多人而言，AIC (Availability、Integrity 與 Confidentiality) 中的 A 可能會被認為是其中危害最小的一個。畢竟對於大多數的 DoS 攻擊而言，攻擊過後就像沒有甚麼事情都不曾發生一樣，所有的網路、系統、程式還是可以持續運作。但是隨著人類對於資訊系統依賴程度的提高，DoS 的影響已經從原來的不便，擴大到了會造成實際金錢的損失，有時候甚至可能是生命的損失。而且可用性受到影響，往往也最容易被使用者所發現，所以對服務提供者來說，直接面對的問題就是因此導致使用者信心的流失。DDoS (Distributed Denial of Service，分散式阻斷服務攻擊) 的目的與 DoS 一樣，只是利用人 (機) 海戰術來增加破壞的成功機率。除了增加成功的機率，人海戰術也可以讓被攻擊的對象失去明確的回擊目標(這裡指的回擊不一定是技術上的回擊，更包含法律上的回擊)。

也因為這樣，舉凡任何一個資訊系統內的元件都可能是 DoS/DDoS 攻擊的目標。包含網路頻寬、網路設備、伺服器、應用程式，都是可能的對象，而且不管是軟、硬體都無法避免受到這類問題的影響。如果以 TCP/IP 協定來說，從實體層、網路層、傳輸層，再到應用層，每一層都有可能成為 DoS/DDoS 的目標。這樣看來，很多看似不相干的攻擊行為，其實都可以歸類在 DoS/DDoS 的範疇之內。舉例來說，當一個駭客透過 SQL Injection 的方式將整個資料庫內的資料刪除時，雖然跟傳統上所認知的 DoS/DDoS 攻擊不同，但是卻也是一種貨真價實的 DoS 攻擊，而其透過的管道則是應用程式的弱點。如果以這種角度來看，DoS/DDoS 幾乎可以說是無法 (完全) 加以避免的，因為任何資訊安全的弱點都有可能被用來當作 DoS/DDoS 攻擊的管道。不過幸運的是，沒有人會讓這樣的事情發生，因為這樣一來廠商就沒的混了，所以在大部分的資料中針對 DoS/DDoS 還是有一些標準的手法可供參考 (這樣才有辦法找出共通性的解決方案)。

根據 CEH 的分類，DDoS 的架構圖如下

• DDoS Attacks
  • Bandwidth Depletion
    • Flood Attack
      • TCP
      • UDP
      • ICMP
    • Amplication Attack
      • Smurf
      • Fraggle
  • Resource Depletion
    • Protocol Exploit Attack
      • TCP SYN Attack
      • PUSH+ACK Attack
    • Malformed Packet Attack (such as teardrop)

不可否認，這些手法多還是屬於網路層的攻擊方式。除此之外，還有所謂的 Reflective DNS 攻擊，就是假冒受害者做出許多的 DNS 查詢動作，讓這些大量回應將受害者的網路與系統處理能力耗盡。這些方式都是透過標準的協定(TCP/IP 相關協定) 所進行，因此可以採用一些共通性的應對措施。跟其他資安問題的應對措施相比，DDoS 應對措施有不少是屬於被動性的，也就是其目的是減少當遭受 DDoS 攻擊時產生的負面影響，而不是事前的預防或即刻消弭的。這些措施大多已經實現在各種網路設備當中，防火牆、路由器、交換器、IPS，都有對應的機制可以減緩 DDoS 的攻擊。為什麼我說減緩，因為這些設備通常都在使用者的網路環境內，就算防禦的再好，依舊可能因對外頻寬被耗盡而無法提供正常的 (網際網路) 連線能力。所以，想要有效地減少 DDoS 攻擊的影響絕對需要 ISP 的協助。至於 ISP 會不會提供協助？從 DDoS 攻擊依舊發生的情況來看，顯然 ISP 並沒有提供這樣的服務，至少不會主動提供。如果 ISP 沒有提供這樣的服務，而且又沒有辦法更換 ISP，那麼一種可能性就是把系統移到具備這樣能力的 Datacentor，讓責任歸屬比較單純化。此外，也有一些廠商 (如 VeriSign) 提供所謂過濾流量的服務，可以讓所有應該流到客戶的流量先導到他們所管理的網路，再經由這些網路把正常的流量傳遞給客戶。需要特別注意的是，即使採用了這些先進的服務，系統依舊無法完全擺脫 DoS/DDoS 的陰影。舉例來說，要讓一個網路服務癱瘓，有時候並不需要攻擊提供服務的系統本身，只要把相關的 DNS 伺服器打趴就可以了。所以如果 DNS 伺服器沒有保護好，系統保護得再好也是無濟於事。更何況廠商本身就不會成為攻擊的目標嗎？

如果我們再把問題延伸一下，是不是可以在更上游的地方就攔截這些惡意的流量呢？理論上是可以的，但是這個需要 ISP 之間的互助。更好的方法，就是讓這些駭客根本沒有辦法招集足夠的殭屍大軍來進行 DDoS 攻擊。很可惜的是，殭屍大軍所招募的電腦並不在我們的掌控中，所以我們無法透過這種方式來保護我們自己免於遭受 DDoS 的攻擊。但是以另一個角度來看，身為網際網路的一份子，避免自己成為殭屍大軍的一員是一個很基本且重要的事項。如果每個網際網路上的使用者都能發揮『我為人人，人人為我』的心態，或許 DDoS 的事件就可以減少許多。 

所以，如果你的角色是網路/作業系統管理者，那麼恭禧你，你有很多現成的方法可以解決 DoS/DDoS 的困擾。但是如果你是應用系統開發者，那麼你必須採用SSDLC，找出相關的風險，並尋求解決之道。因為應用系統的可用性，完全依賴在網路/作業系統的可用性，因此你有絕大部分的時機需要網路/作業系統管理者的配合才能解決問題。畢竟，網路或是作業系統的問題，就應該在網路與作業系統的層級加以解決，應用系統則專注於避免應用程式層面的安全議題。所以對於一個組織而言，如何能夠在各個職務之間維持各自專業分工的同時還能夠保持密切的合作，將是對付 DoS/DDoS 最為有效的策略。最後，如果有人 (廠商) 跟你說他可以幫助你完全避免遭受到 DoS/DDoS 的攻擊，那他百分之分百是在騙你。對網路層的攻擊是如此，對應用程式層的攻擊更是如此。不相信我說的？所有的資訊安全專家都知道風險永遠不可能完全加以消弭，問題只在於他們敢不敢告訴你。

 

相關連結：

• Denial-of-service attack @ Wikipedia
• DDoS Migitation Services @ VeriSign

[資安觀念] 非法的 DHCP 伺服器，你到底要做甚麼？

因為稽核的必要性與重要性日益升高，再加上新版的個人資料保護法已經通過三讀立法，所以內部管理的議題持續受到用戶的重視，而其中一個項目就是所謂的 IP 管理 (IPAM)。IP 管理基本上就是管理 IP 位址的使用情況，從過去的 ISP/Datacenter 管理客戶的 IP 位址，到現在網路管理者用來自行管理內部網路的使用情況。跟 IP 位址運作相關聯的重要協定（包含 ARP、DHCP、DNS 等）所衍生的問題，都是這類產品所必須面對的。

在使用 DHCP 的環境中，對大多數的網路管理員來說，通常最困擾的就是 IP 相衝的問題。也就是有些被稱為小白的終端使用者不循正常方式使用 DHCP，卻逕自設定成固定 IP。當然，這些使用者可能因為無心，不小心設定成 DHCP 伺服器所管理的 IP 位址，因此造成日後透過 DHCP 伺服器取得同一個 IP 位址的電腦設備些許的不便。不過真正的問題是萬一這些使用者設定的是網路設備 (如印表機)、甚至是伺服器所使用的 IP 位址，那會發生甚麼事情可就很難說了。比較嚴重的情形，甚至可能造成服務的中斷。這類問題真正麻煩的地方，倒也不是怎麼解決問題，而是找到問題的源頭，也就是那位小白終端使用者。

除了上述的情況外，還有另外一個問題，那就是所謂的惡意 DHCP 伺服器 (Rogue DHCP Server)。惡意 DHCP 伺服器對網路有甚麼影響呢？對不少管理者而言，可能認為它帶來的問題跟上述情況差不多，也就是會造成 IP 衝突的情況。不過惡意的 DHCP 伺服器，其危害可絕對不僅於此，其真正的危害來自於所謂的中間人攻擊 (Man-in-the-Middle Attack)。透過 DHCP 的協定，終端設備除了可以取得 IP 位址外，像是閘道 (Gateway)、DNS 伺服器、WINS 伺服器等重要設定也都可以一併加以設定。其中尤其以閘道與 DNS 伺服器兩個設定值，更是幾乎所有網路環境都必須使用的設計值。所以，惡意的 DHCP 伺服器只要將發放給終端設備的閘道設定成已經受其掌控的設備 （這種手法又可以稱之為 DHCP 假冒, DHCP Spoofing)，如此一來這個終端設備所有非同 IP 網段的封包資料就會先送到這個受其掌控的設備。在這種情況下，資料的竊取已經不算甚麼，就連資料的假冒也是輕而易舉。其他像是控制 DNS 伺服器或 WINS 伺服器的設定，雖然產生的網路行為不同，但是卻都同樣可以達成中間人攻擊的目的。

要解決惡意 DHCP 伺服器的問題，網路設備廠商在 Layer 2 實現了一種泛稱為 DHCP Snooping 的機制。而如果使用的網路設備不支援，有些 IPAM 的產品 (軟、硬體) 也提供了一定的防護能力。當然，網路設備通常能夠提供比較嚴謹的防護能力，但是卻同時也很容易受到網路設備本身佈署情況的影響，而造成防護範圍不足的問題，因此在規畫相關解決方案時必須多加注意。如果你的預算不足，也有一些小工具可以幫助你找到這些隱匿在網路中的惡意份子。

相關連結：

• Understanding and Configuring DHCP Snooping @ Cisco Catalyst 4000 family swithces (PDF)
• Preventing DHCP Spoofing (MX-series Routers Only)
• Rogue DHCP @ Wikipedia

[資安觀念] 古語有云，時間就是金錢

不管你在工作上是不是從事資安相關的領域，或多或少都曾經面對要在許多不同解決方案中找出最佳作法的情況。如果是採用預算制，比較一般性的做法就是找出預算之內而且效果最好的解決方案。另外一個方法就是找出可以接受的最低成效，然後在此限制下找出最低成本的解決方案。後者通常適用於沒有固定的預算，或是對於成效有一定要求的情況。

嚴格說來，不管是哪一種方式，其實都是在成本與效果之間求取一個最佳解法，只是受到限制的條件不一樣。但是限制條件通常並不是如表面那麼單純且直接。例如以預算制的情況來說，雖然只要在預算內即可，但是有時候省下更多的錢也是功勞一件 (當然也有實際花費跟預算越接近越好的狀況)。而且即使對於省錢與否並不在乎，至少對於解決方案還是會有基本的要求。因此如果已經把預算用完還是無法達到基本的要求，同樣會出大問題。所以，比較明確的說法應該是受到限制的條件比重不一樣，但是基本上要考量的項目卻都是相同的。有關成本與效果的平衡，在資安的領域比較常用 Cost-Effective 這個名詞。接下來我想談談有關成本這個議題。

評估成本的方法有很多，TCO (Total Cost of Ownership) 是一種常見的評估方式，而 TCO 主要包含取得成本 (Total Cost of Acquisition) 與維運成本 (Operation Costs) 兩大部分。當然，儘管是所謂的 TCO，但是真的能夠把所有的顯性與隱性成本都找出來嗎？答案可能沒有那麼樂觀。也因此光是使用 Windows 還是 Linux 擁有較低的 TCO 這個議題就可以讓兩方人馬爭吵多年依舊沒有結論。不論如何，基本上TCO 在考量各個項目的成本時，會考量到相關人員的成本。例如當考量一個系統的維運成本時，我們會將所需分配的系統管理員人力成本納入計算。但是，一個系統所影響的並不是只有系統管理員。一個比較重要的系統，或許跟整個組織的所有人員都有關聯，甚至連組織外部的人員也會有所關聯。一旦有關聯後，對於這些人所產生的成本”理論上”就應該加以考量。不過理論終究是理論，很少評估方式會考慮到這樣的成本。主要理由有二，第一個是這樣的評估方式會讓待評估的項目變得又多又複雜，進而增加評估所產生的成本。另外一個更重要的理由，這些成本根本不是”我”的成本，所以不關我的事情。

舉例來說，如果 IT 部門要改良一個原有的系統，A方案可以不影響使用者目前的工作量，而且也不必增加原有的維護人力需求。B方式可以節省 50% 的維護人力 ，但是卻會增加組織內每個使用者 1% 的工作量。在其他成本皆相同的情形下，IT 部門會選擇哪個方案？通常應該是B…因為省下來的錢是 IT 部門的預算，而多出來的工作量跟 IT 部門沒有直接的關係。以這個例子而言，增加 1% 的工作量對於大多的使用者來說並不會造成太大的困擾，因此可能不會造成太大的反彈。但是如果因此增加了 10% 的工作量，那麼在推廣上就需要一些手段。當然，在組織內部發生這種問題，比較有制度的公司或許還有機會發現並加以解決。但是如果今天使用者並不是組織內部的員工，而是外部的使用者呢？誰會注意、甚至關心這些人的成本？只要能夠說服使用者接受，對組織而言當然是成本越低越好。

以說服的理由來看，資訊安全在某些時候確實是一個不錯的說詞。所以，我們上網路銀行轉帳需要先購買一個讀卡機、每次使用時先要找出讀卡機、使用後要記得馬上拔掉並收好。這樣的成本有多高？而避免的風險又有多少？兩者之間是否 Cost-Effective 確實存在很大的疑問。簡單來說，風險與成本對不同的人來說本就是不一樣的，但是當所有的算法都是廠商一廂情願的想法，所產生結果的可參考性自然有很大爭議的空間。Microsoft 安全研究員 Cormac Herley 在去年針對這個議題發表了一份論文，引起了一陣討論，也讓我們用更全面地眼光去看待 Cost-Effective 這句話。至少，就時間就是金錢這句話，不是只有”我”的時間才是金錢，”你”的也是。

相關連結：

• So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users
• Please do not change your password