反正趕快更新吧，這次可是被列為High Critical的風險等級，建議大家檢查版本是否已經升級到4.1.249.1036
2010年3月18日 星期四
2010年3月11日 星期四
2010年3月10日 星期三
2010年3月1日 星期一
當網站服務遇到洪水猛獸-DDoS分散式阻斷服務攻擊
剛過完年，趕緊抽空整理一下DDoS的資料
攻擊分類：
1. Network Layer：利用常見標準通訊協定來攻擊。
a. Stateless：可偽造IP。
ICMP：Ping flood
TCP：SYN flood、ACK flood、RST flood
UDP：UDP flood
b. Stateful：不可偽造IP，但用botnet做IP變換。
TCP：Zombie Connections
2. Service Layer：不可偽造IP，於服務層產生錯誤
SSL flood
3. Application Layer：不可偽造IP，製造大量正常請求至主機應用層，使其超過負荷。
HTTP flood
造成結果：
1. 網路頻寬滿載：Ping flood、UDP flood
2. 作業系統（或前端網路設備）滿載：SYN flood（ASK/RST)、Zombie Connections
3. 伺服器滿載：SSL flood、HTTP flood、Application flood
技術防禦：
1. UDP/ICMP：攻擊能量可達3000000~5000000 pps、5~10Gbps。可用IPS、Firewall或請ISP Drop掉UDP、ICMP封包，除非要開放特定服務（如DNS）
2. SYN flood：攻擊能量可達1000000~2000000 pps、600Mbps~1.2 Gbps。主機調整時加大Session Table、SYN Table並縮短SYN_RECV Timeout。或以SYN proxy、SYN cookie資安設備的機制來做緩衝。
3. ACK/RST flood：常與SYN flood合併出現，可使用高效能IPS於主機前端過濾未建立連線的封包。但須注意狀態檢查的處理能力、Concurrent session數，以免誤判。
4. Connection flood：用netstate可看到大量ESTABLISHED、TIME_WAIT、CLOSE_WAIT等狀態，虛耗網路或主機的資源處理連線。可於主機端加大Session Table、開啟TCP reuse/recycle，縮短close/fin timeout，或用高效能IPS限制每秒允許建立連線數，限制相同來源連線數的上限，追蹤攻擊IP並阻擋。
5. SSL flood：以大量真實來源對SSL服務主機進行SSL Handshake，但不發送後續HTTP Request。可用SSL加速器或於網路層限制SSL連線之建立速度，並追蹤攻擊IP加以阻擋。
6. Application flood：以真實來源對應用層服務發送請求（如HTTP或game），使服務主機無法負荷而過載。若為特別的協定，如game，較少能以資安設備攔截，僅能於網路層攔截過於快速之連線建立行為，並追蹤攻擊IP加以阻擋。亦可考慮多加主機做負載平衡先解決燃眉之急。
建議處理機制，三大方向：IP、ISP、IPS（這可不是考排列組合喔）
1. IP 準備好備用的IP，受攻擊時調整DNS，把備用IP與受攻擊IP對調。
2. 與ISP聯手處理，平日應瞭解ISP的通報管道、網路能力。
3. 使用IPS、Firewall、Router等設備，拋棄或重導網站流量。
處理SOP：
1. 前置作業：利用cati、opennms、nagios等工具，記錄主機狀態(CPU、記憶體、網路連線數、網路介面流量、封包數、應用程式存取記錄)、網路設備狀態（系統負荷、Session量、流量封包數、各協定佔用量、服務狀況、每秒事件數）、系統日誌。
2. 收集資訊：收集資訊做攻擊種類判斷。
3. 側錄封包：啟動port mirror，收集封包判斷。
4. 請ISP協助：
5. 進行阻擋：
6. 報案：
7. 事件檢討：
相關資安設備：
1. IPS：領導廠商有TippingPoint、IBM ISS、McAfee。
2. Firewall：領導廠商有Juniper、CISCO
3. Application Delivery Controller（ADC）
國內其他通報管道：TWNIC、TWCERT。
（以上內容節錄於資安人雜誌）
訂閱：
文章 (Atom)