3. Phương pháp hạn chế.
Nhìn chung với DDoS chúng ta có 2 action cơ bản trong việc hạn chế (sau khi nhận ra được hình thức)
- Thứ nhất là block IP
- Thứ 2 là limit resource.
Block IP có được ưu điểm lớn đó là chặn luôn nguồn tấn công vào, điều này sẽ hạn chế được sự thất thoát tài nguyên, dĩ nhiên rồi vì mục tiêu của anti DDoS là hạn chế sự thất thoát tài nguyên, tuy nhiên bên cạnh đó chúng ta phải đối phó với bài toán khác đó chính là làm sao để lọc một cách cụ thể và chi tiết để không block lộn người dùng hợp lệ. Đây là vấn đề rất quan trọng đấy, nhưng không thảo luận ở đây.
Với cách thứ 2 là limit resource có ưu điểm chính là không block lộn người dùng, bởi vì chúng ta không áp dụng việc block. Thay vào đó chúng ta cần phải tính toán resource phù hợp cho các client, và phân bố cho hợp lý, vì vậy không sợ block nhầm người dùng. Tuy nhiên chúng ta phải đối phó với bài toàn lớn hơn là performance tuning system. Phải cấu hình làm sao cho hợp lý bởi vì lúc này chúng ta cũng đã công nhận rằng nguồn tấn công cũng là người dùng bình thường. Cho nên cũng cần phục vụ như người dùng bình thường.
Và biện pháp cuối cùng đó chính là kết hợp cả hai cái trên lại. Và nó dĩ nhiên là hiệu quả hơn.
Với việc Anti WebHunter, mình chọn biện pháp thứ 2, đó chính là giới hạn resource. Thực ra đây không phải là biện pháp tốt nhất, tuy nhiên bởi vì system của mình thường xuyên bị tấn công với nhiều loại phương pháp khác nhau cho nên buộc mình phải chọn hình thức nào ngăn chặn không chỉ một mà phải có hiệu quả với nhiều phương pháp.
Cụ thể là sau khi tính toán xong số liệu hợp lý, mình điều chỉnh lại firewall và performance tuning system của mình. Theo đó những rules sau đây đang được áp dụng :
- Mỗi IP chi có thể mở một kết nối đến system trong một thời điểm, thực ra sau khi tính toán thì mình nhận ra 1 là đủ, lúc đầu mình giới hạn ở mức 4 nhưng sau đó chuyển xuống 1 và tiếp tục theo dõi, kết quả rằng điều đó không làm ảnh hưởn người dùng, người dùng load vẫn nhanh và ổn định. => không cần nhiều hơn 1.
- Gia tăng thời gian keepalive lên, bởi vì một khi dùng ít kết nối thì cần gia tăng keepalive để việc truyền tải được trơn tru hơn.
- Áp dụng việc cache hợp lý, cache lại những thứ có thể cache, system của mình chủ yếu là trang tin, nội dung dữ liệu chỉ đọc cho nên có thể nói cache là một biện pháp performance tuning rất hiệu quả.
- Không giới hạn thời gian mở connection, bởi vì chỉ mở một kết nối thì có nghĩa là dù nhận được nhiều gói tin nữa thì cũng sẽ bị drop bởi kernel chứ không có kết nối nào được mở.
- Cuối cùng là một khi đã áp dụng những hình thức bên trên thì không cần block IP làm gì nữa, cứ để thoải mái. Dĩ nhiên là mình cũng có áp dụng việc block với syn flood, nhưng trong topic này chỉ nói về WebHunter cho nên mình không đề cập các hình thức khác.
Nói tóm lại, trong bài viết trên của mình chỉ là cách nhìn nhận và giải quyết ván đề của mình, cũng với cách nhìn nhận đó có thể có bạn khác đưa ra hình thức tốt hơn.
- XHACKER -
Nhìn chung với DDoS chúng ta có 2 action cơ bản trong việc hạn chế (sau khi nhận ra được hình thức)
- Thứ nhất là block IP
- Thứ 2 là limit resource.
Block IP có được ưu điểm lớn đó là chặn luôn nguồn tấn công vào, điều này sẽ hạn chế được sự thất thoát tài nguyên, dĩ nhiên rồi vì mục tiêu của anti DDoS là hạn chế sự thất thoát tài nguyên, tuy nhiên bên cạnh đó chúng ta phải đối phó với bài toán khác đó chính là làm sao để lọc một cách cụ thể và chi tiết để không block lộn người dùng hợp lệ. Đây là vấn đề rất quan trọng đấy, nhưng không thảo luận ở đây.
Với cách thứ 2 là limit resource có ưu điểm chính là không block lộn người dùng, bởi vì chúng ta không áp dụng việc block. Thay vào đó chúng ta cần phải tính toán resource phù hợp cho các client, và phân bố cho hợp lý, vì vậy không sợ block nhầm người dùng. Tuy nhiên chúng ta phải đối phó với bài toàn lớn hơn là performance tuning system. Phải cấu hình làm sao cho hợp lý bởi vì lúc này chúng ta cũng đã công nhận rằng nguồn tấn công cũng là người dùng bình thường. Cho nên cũng cần phục vụ như người dùng bình thường.
Và biện pháp cuối cùng đó chính là kết hợp cả hai cái trên lại. Và nó dĩ nhiên là hiệu quả hơn.
Với việc Anti WebHunter, mình chọn biện pháp thứ 2, đó chính là giới hạn resource. Thực ra đây không phải là biện pháp tốt nhất, tuy nhiên bởi vì system của mình thường xuyên bị tấn công với nhiều loại phương pháp khác nhau cho nên buộc mình phải chọn hình thức nào ngăn chặn không chỉ một mà phải có hiệu quả với nhiều phương pháp.
Cụ thể là sau khi tính toán xong số liệu hợp lý, mình điều chỉnh lại firewall và performance tuning system của mình. Theo đó những rules sau đây đang được áp dụng :
- Mỗi IP chi có thể mở một kết nối đến system trong một thời điểm, thực ra sau khi tính toán thì mình nhận ra 1 là đủ, lúc đầu mình giới hạn ở mức 4 nhưng sau đó chuyển xuống 1 và tiếp tục theo dõi, kết quả rằng điều đó không làm ảnh hưởn người dùng, người dùng load vẫn nhanh và ổn định. => không cần nhiều hơn 1.
- Gia tăng thời gian keepalive lên, bởi vì một khi dùng ít kết nối thì cần gia tăng keepalive để việc truyền tải được trơn tru hơn.
- Áp dụng việc cache hợp lý, cache lại những thứ có thể cache, system của mình chủ yếu là trang tin, nội dung dữ liệu chỉ đọc cho nên có thể nói cache là một biện pháp performance tuning rất hiệu quả.
- Không giới hạn thời gian mở connection, bởi vì chỉ mở một kết nối thì có nghĩa là dù nhận được nhiều gói tin nữa thì cũng sẽ bị drop bởi kernel chứ không có kết nối nào được mở.
- Cuối cùng là một khi đã áp dụng những hình thức bên trên thì không cần block IP làm gì nữa, cứ để thoải mái. Dĩ nhiên là mình cũng có áp dụng việc block với syn flood, nhưng trong topic này chỉ nói về WebHunter cho nên mình không đề cập các hình thức khác.
Nói tóm lại, trong bài viết trên của mình chỉ là cách nhìn nhận và giải quyết ván đề của mình, cũng với cách nhìn nhận đó có thể có bạn khác đưa ra hình thức tốt hơn.
- XHACKER -
![[IMG]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_sryA6q-HRA2ZFJXWf3-KqQAW6tnvQc9s7xX8DG7N01aS9aJaNlxXYe8QXRB6YTeq6fiiyeZJV_fUeJgYX0UD_QOwF8Ou2phBClMHR3werKkoIDYfUxB4z4UumtgvkZJ7aN=s0-d)
![[IMG]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_u_K6_1V29TURfKGNG_t0wVjUJIO-orNOi_89FnGMnk-oRjxLGf3N-5eoC1jQnh6GT7vOMJnJmRwAQMYtBTqlApS2XnnpABjGABAv1pckPvNabLhQjrVmqC5FqADSRuQwA=s0-d)
![[IMG]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_v-ZDoRbK28ARShoG9dRWBQNbOM63kO04f-s-8SSHbMYIgGE4GNu4x5tMNcS7ey3-OqytnCF8y-Zmgv12a7YrN81E0G6t7euR25ItqLMj-8N0wJo0O9znNQ2cUzZadwY5z0=s0-d)
![[IMG]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_t_J4H5Poiw3z2Ywj2G_awR_2ldd-re1jmvcmkeeipfRMR1cH8vM6g24SrB7jLbqiEgwlQCMhfOIGY54QlLrZJ9AEwDOzL-CtVutV6I5TGmxv8e-sc4ZiT7mhuWuP7DtRFI=s0-d)
