raytracy
2005-05-17, 11:47 AM
使用 DIY 系統, 需考量您自己或公司以後的維運能力, 特別是在事故發生時, 是否能在可接受的時間內恢復營運的能力. 小弟無法直接提供您答案, 但可以提供一些參考:
舉例來說:
小弟負責的 ISP 技術部門, 幾乎全面採用 Linux based FW, 服務的客戶數大約兩萬人, 而且即使將來客戶增加到數十萬人, 也不會放棄. 一來, 我們的每一位值班技術人員原本就很熟悉 Linux/BSD, 都超過三五年以上的經驗(小弟個人是從 1993 年開始玩 Linux 的), 其中一人值班時, 其他至少還有2~4位工程師可以從旁支援; 一般的故障排除平均不到五分鐘, 突發的攻擊事件, 連安全政策討論在內也不超過一小時; 二來, 我們使用的硬體都是 Server 級的, 除了本身的容錯能力外, 也有備援機做 Cold Standby, 全年的硬體可用率至少可達 99.9% 以上. 剩下的只有人為設定錯誤才會造成問題. 因此就營運面來考量, 我們使用這樣的系統, 並無不妥, 且節省了上千萬元台幣的成本.
但有趣的是, 在我們的機房內, 卻有另外一台硬體防火牆, 專門用來保護一組負責 Provision 用戶的管理系統. 為何在這個地方, 我們反而不使用原本熟悉的 DIY FW 呢? 那是因為這套 Provision 系統相當複雜, 在查修上常需藉助原廠的協助, 此時若我們採 DIY FW 的話, 若原廠將責任推給我們的 FW, 很可能會延誤修復時機; 因此這塈鴷峊球都通用的知名品牌, 讓 Provision 廠商沒有推卸餘地, 必要時他們也可以進 FW 去查看所需的資訊(至少他們可以將此資訊交給其他人判讀), 而這些則是採用 DIY FW 會有爭議的.
換成另外一個場景:
也是我們關係企業的另一家 ISP, 他們卻跟我們剛好相反: 只有少量的使用 DIY FW, 其他大部分流量都靠硬體防火牆來處理. 所以他們一直在採購升級高性能大容量的 FW. 但是若去了解他們的資源, 就會發現: 原來他們只有兩個人可以輪班, 每天工作超過 12 小時, 而且本身對於 Linux 才剛入門, 網路安全只具備基礎的認識, 沒有能力去解析攻擊內容, 或擬定安全政策. 因此對他們來說, DIY FW 反而是很大的負擔; 但採用 Appliance FW, 可以把許多工作都交給 FW 廠商來處理, 他們才有餘力去執行日常的維運工作. 雖然他們花很多錢在這上面, 但卻也確保了一定的維運品質.
雖然他們也有 DIY FW, 不過那是我協助建立的, 而且不是直接設定 iptable, 而是在上層加一個比較簡單的 iptable 管理介面來進行設定(shorewall). 對他們來說, 只要五分鐘就可以上手, 而且我隨時可以支援.
所以, DIY FW 本身的強度, 取決於硬體的選擇, 建置維運人員的操作能力, 以及所選用的安全政策是否正確; 但, 是否要採用 DIY 方式? 除了強度之外, 還要考慮其他的外在因素.
另外順便提醒幾件事:
1. 建置 firewall 並不代表安全等級提升了; 設定了正確的 firewall 安全政策才會提升安全.
2. 一般所指的 network firewall 通常只負責到第四層 (TCP/UDP), 但仍有許多安全事件是透過第七層來進行的, 這些需要靠 Content Filter 才能擋得掉.
3. FW 的國際測試認證, 是因為那些硬體 FW 被看成「黑盒子」, 沒有人知道裡面是否有潛在的漏洞, 因此需要認證機構來證明他是安全的; 但 Linux DIY FW, 從 Kernel 到 App, 所有 source code 都公開, 隨時都在被全球數千萬名的技術人員持續驗證更新中, 沒有黑盒子存在, 所以只要您有能力持續收集相關的安全資訊, 這種「白盒子」是沒有必要去認證.
4. 如果建置 DIY FW 的人離開了(不論離開幾小時, 幾天, 或永遠), 別人是否有能力接手營運?
贊助商連結
舉例來說:
小弟負責的 ISP 技術部門, 幾乎全面採用 Linux based FW, 服務的客戶數大約兩萬人, 而且即使將來客戶增加到數十萬人, 也不會放棄. 一來, 我們的每一位值班技術人員原本就很熟悉 Linux/BSD, 都超過三五年以上的經驗(小弟個人是從 1993 年開始玩 Linux 的), 其中一人值班時, 其他至少還有2~4位工程師可以從旁支援; 一般的故障排除平均不到五分鐘, 突發的攻擊事件, 連安全政策討論在內也不超過一小時; 二來, 我們使用的硬體都是 Server 級的, 除了本身的容錯能力外, 也有備援機做 Cold Standby, 全年的硬體可用率至少可達 99.9% 以上. 剩下的只有人為設定錯誤才會造成問題. 因此就營運面來考量, 我們使用這樣的系統, 並無不妥, 且節省了上千萬元台幣的成本.
但有趣的是, 在我們的機房內, 卻有另外一台硬體防火牆, 專門用來保護一組負責 Provision 用戶的管理系統. 為何在這個地方, 我們反而不使用原本熟悉的 DIY FW 呢? 那是因為這套 Provision 系統相當複雜, 在查修上常需藉助原廠的協助, 此時若我們採 DIY FW 的話, 若原廠將責任推給我們的 FW, 很可能會延誤修復時機; 因此這塈鴷峊球都通用的知名品牌, 讓 Provision 廠商沒有推卸餘地, 必要時他們也可以進 FW 去查看所需的資訊(至少他們可以將此資訊交給其他人判讀), 而這些則是採用 DIY FW 會有爭議的.
換成另外一個場景:
也是我們關係企業的另一家 ISP, 他們卻跟我們剛好相反: 只有少量的使用 DIY FW, 其他大部分流量都靠硬體防火牆來處理. 所以他們一直在採購升級高性能大容量的 FW. 但是若去了解他們的資源, 就會發現: 原來他們只有兩個人可以輪班, 每天工作超過 12 小時, 而且本身對於 Linux 才剛入門, 網路安全只具備基礎的認識, 沒有能力去解析攻擊內容, 或擬定安全政策. 因此對他們來說, DIY FW 反而是很大的負擔; 但採用 Appliance FW, 可以把許多工作都交給 FW 廠商來處理, 他們才有餘力去執行日常的維運工作. 雖然他們花很多錢在這上面, 但卻也確保了一定的維運品質.
雖然他們也有 DIY FW, 不過那是我協助建立的, 而且不是直接設定 iptable, 而是在上層加一個比較簡單的 iptable 管理介面來進行設定(shorewall). 對他們來說, 只要五分鐘就可以上手, 而且我隨時可以支援.
所以, DIY FW 本身的強度, 取決於硬體的選擇, 建置維運人員的操作能力, 以及所選用的安全政策是否正確; 但, 是否要採用 DIY 方式? 除了強度之外, 還要考慮其他的外在因素.
另外順便提醒幾件事:
1. 建置 firewall 並不代表安全等級提升了; 設定了正確的 firewall 安全政策才會提升安全.
2. 一般所指的 network firewall 通常只負責到第四層 (TCP/UDP), 但仍有許多安全事件是透過第七層來進行的, 這些需要靠 Content Filter 才能擋得掉.
3. FW 的國際測試認證, 是因為那些硬體 FW 被看成「黑盒子」, 沒有人知道裡面是否有潛在的漏洞, 因此需要認證機構來證明他是安全的; 但 Linux DIY FW, 從 Kernel 到 App, 所有 source code 都公開, 隨時都在被全球數千萬名的技術人員持續驗證更新中, 沒有黑盒子存在, 所以只要您有能力持續收集相關的安全資訊, 這種「白盒子」是沒有必要去認證.
4. 如果建置 DIY FW 的人離開了(不論離開幾小時, 幾天, 或永遠), 別人是否有能力接手營運?
贊助商連結