TTCN bị DoS bằng kĩ thuật Slowloris
Từ khuya hôm nay đến tận giữa trưa, hầu như bạn không thể truy cập vào TTCN được. Phải mất nhiều thời gian mình mới tìm ra nguyên do: bị DoS bằng kĩ thuật Slowloris.
Đây là kĩ thuật tương tự như SYN flood (tạo nửa kết nối để làm cạn kiệt tài nguyên máy chủ) nhưng diễn ra ở lớp HTTP (lớp ứng dụng). Để tấn công, tin tặc gửi yêu cầu HTTP đến máy chủ, nhưng không gửi toàn bộ yêu cầu, mà chỉ gửi một phần (và bổ sung nhỏ giọt, để khỏi bị ngắt kết nối). Với hàng trăm kết nối như vậy, tin tặc chỉ tốn rất ít tài nguyên, nhưng đủ để làm treo máy chủ, không thể tiếp nhận các kết nối từ người dùng hợp lệ.
Ưu điểm khác của Slowloris là trong suốt quá trình tấn công, do kết nối chưa hoàn chỉnh, sẽ không có thông tin gì trong log. Chỉ đến khi ngưng kết nối, sẽ có hàng loạt lỗi 404 trong log do truy vấn sai.
Không phải mọi máy chủ đều bị ảnh hưởng bởi kiểu tấn công này. Các máy chủ như Microsoft IIS hoặc nginx không “hề hấn” gì trước Slowloris. TTCN dùng nginx làm proxy nghịch, tuy nhiên Apache chạy phía sau vẫn nghe trên IP công cộng (vì còn chạy một website thử nghiệm khác, không qua proxy) nên đã bị tấn công.
Có nhiều cách để khắc phục kiểu tấn công này, mỗi cách đều có ưu điểm riêng:
- Không dùng Apache nữa! Nếu dùng Apache sau proxy nghịch, thì chỉ cho nghe trên cổng 127.0.0.1 hoặc các IP cục bộ.
- Giảm Timeout cho Apache. Tuy nhiên cách này không mấy hiệu quả, tin tặc chỉ phải gửi thêm nhiều gói tin mà thôi.
- Giới hạn số kết nối đến Apache cho mỗi IP. Có thể dùng mod_qos chẳng hạn để làm việc này.
- Giải quyết ở lớp dưới: cấu hình firewall để giới hạn số kết nối đến cổng 80 trên mỗi IP.
Xem thêm http://ha.ckers.org/slowloris/.
Bình luận
Sáng nay vào thongtincongnghe.com mãi không được, toàn báo lỗi gateway. Còn vào ttcn.mobi thì được, nhưng chỉ dừng lại ở trang chủ, vào chi tiết từng bài thì cũng bị lỗi.
Cũng mừng là TTCN đã sống lại. Cảm ơn BTQ.
Ờ, sao lắm người rảnh nhỉ. Mình đọc chả hiểu mô tê gì.
Mình cũng giống bạn, chả hiểu gì, chỉ biết mở đầu là TTCN bị DoS, kết thúc là anh Nam sửa xong đúng dịp đón World Cup :x
nginx
nginx có thể được sử dụng để làm load balancing và có chức năng như một tường lửa đơn giản (có thể cài thêm phần mềm tường lửa lên server nginx mà không cần một tường lửa riêng) để che chắn các web/mail server phía sau. Tuy nhiên nếu nginx bị dos mà các server phía sau chỉ lắng nghe trên các địa chỉ cục bộ thì chết ngắc.
Tại sao chết chắc? Nếu nghe trên IP công cộng thì kém an toàn hơn chứ.
Nếu chỉ cho apache lắng nghe các địa chỉ nội bộ, có nghĩa là phải có cái gì đó đằng trước (proxy) để chuyển các yêu cầu đến server apache. Nếu cái proxy đó mà die thì nguyên hệ thống die luôn.
Đó là một hạn chế của việc sử dụng proxy nghịch. Tuy nhiên việc proxy bị die cũng dễ phát hiện thôi lúc đó có thể cho apache lẵng nghe trên các địa chỉ công cộng.
Thì luôn có cái proxy đằng trước mà, do hệ thống như vậy, và mọi hệ thống có lưu lượng cao đều dùng cách đó.
Vấn đề là khi có cái proxy đó rồi, thì Apache có nghe trên IP công cộng cũng vô ích, thậm chí còn là nguy cơ bảo mật. Khi đã dùng proxy nghịch thì server đằng sau chỉ nghe trên IP cục bộ là đủ (trừ khi muốn nghịch ngợm thì không tính). Proxy sẽ có trách nhiệm lọc luôn các truy vấn, Apache đằng sau hoàn toàn tin tưởng vào các truy vấn nhận được, và cấu hình cho Apache sẽ nhẹ nhàng hơn.
Việc để cho apache lắng nghe trên các địa chỉ công cộng khi đã có proxy là vô nghĩa. Điều đó hoàn toàn đúng nên khôg có gì phải bàn cãi. Vấn đề nêu lên ở đây là làm sao để bảo mật cho hệ thống backend. Nếu sử dụng proxy ngược thì vấn để là bảo vệ cái proxy đó vì nếu cái proxy bị die thì hệ thống sẽ coi như bị die.
À, tại lúc đầu bạn viết khác.
Giải pháp tránh dosuốt
Giải pháp tốt nhất vẫn là sử dụng một tường lửa hoạt động ở chế độ trong suốt