Tôi đang bị DDoS

Vấn đề

Từ lúc bắt tay vào xây dựng trang web, tôi đã nghĩ đến khả năng nó bị phá hoại sau này. Có nhiều hình thức tấn công như DDoS, spam hay các cuộc tấn công nhằm vào lỗ hổng bảo mật nào đó... Bạn nghĩ là tôi gây thù chuốc oán với ai nên lo sợ chăng? Thực ra là không đâu, trước đến nay tôi chưa bao giờ gây chiến với ai cả, nhưng không thể nào "thoát khỏi ánh mắt đen tối" của những kẻ táy máy trên mạng ngoài kia được. Đây không phải là trang web đầu tiên tôi dựng lên, thế nên việc lưu ý đến hành vi không mấy thân thiện này không phải là lần đầu.

Gần đây Blog của tôi đang bị DDoS với tần suất nhiều hơn. Gần 3 năm tồn tại, số lượng các cuộc tấn công có thể đếm trên cả hai đầu ngón chân và tay. Nhẹ thì máy chủ bị "đơ", thời gian phản hồi chậm. Nặng thì treo luôn và thế là "sập", không ai có thể truy cập vào được nữa. Thiệt hại thì chưa có nhưng luôn phải mất công vào xử lý mớ hỗn độn này. Đâu phải lúc nào chúng ta cũng có máy tính và Internet bên cạnh.

Tấn công bằng hình thức DDoS không mới, nhưng hiệu quả phá hoại của nó mang lại là cực kì cao. Dù là bất kỳ lý do gì khiến kẻ tấn công quyết định DDoS một trang web đi chăng nữa thì hẳn họ phải rất thõa mãn khi thấy trang web bị tê liệt.

Trước kia tôi lưu trữ tất cả mọi thứ trên DigitalOcean (DO), với cấu hình máy chủ khiêm tốn nhưng chắc chắn nó hoạt động ổn định với lượng người dùng hiện tại. Thi thoảng, tôi phải hứng một trận DDoS nhẹ làm sập máy chủ. Thời gian ban đầu, DO liên tục cảnh báo máy chủ đang sử dụng hơn 70% rồi 90% CPU mà không biết nguyên nhân do đâu. Công cụ UptimeRobot gửi cảnh báo trang web của tôi không thể nào truy cập được nữa. Sau này kiểm tra lại nhật ký truy vấn mới phát hiện: hóa ra mình đang bị DDoS.

Hầu hết thời gian của các cuộc tấn công đều rất ngắn, những lúc đó tôi chỉ biết cắn răng chờ cho đến khi nó kết thúc hoặc cũng có đôi lúc nó diễn ra vào nửa đêm. Sáng mai thức dậy, khởi động lại máy chủ, mọi thứ lại hoạt động trở lại như bình thường.

Mọi người sẽ nghĩ: thế sao không làm cách nào để chống lại DDoS đi? Cảm xúc của tôi sẽ kiểu :| , vì không biết phải chống như thế nào. Ai cũng nghĩ việc đầu tiên cần làm là đặt Rate limit, xin thưa rằng tôi đã đặt. Mỗi IP chỉ được request 10 lần trong 1s. Thế thì nâng cấp máy chủ lên? Tiền đâu mà nâng cơ chứ? 6$ một tháng là không quá nhiều nhưng nó vừa đảm bảo tài chính và lượng truy cập nếu như không có kẻ phá hoại. Vậy thì cài thêm nhiều công cụ mới vào để theo dõi? Bạn nghĩ tôi có thể cài thêm gì trên cái máy chủ Shared CPU 1GB, 20SSD chứ?...

Thực ra tôi đã suy nghĩ rất nhiều về vấn đề này, chỉ là không thể chặn được DDoS hiệu quả. Nhớ lại mô hình OSI 7 lớp mà hầu hết sinh viên công nghệ sẽ được học. Chúng ta có lớp 7 - cũng là lớp cao nhất - là lớp ứng dụng (Application Layer). Rate limit mà trước kia tôi có - nằm ở lớp 7, các phần mềm cài vào cũng nằm ở lớp 7... 7 là lớp tương tác trực tiếp với ứng dụng hay với máy chủ của bạn, hiểu đơn giản nếu kẻ tấn công gửi được HTTP request đến máy chủ của bạn tức là hắn đang tấn công vào lớp 7. Chắc chắn rồi, máy chủ của bạn sẽ phải xử lý những yêu cầu của hắn, cho dù đơn giản là từ chối request đi chăng nữa, vẫn cần một ít thời gian CPU để xử lý. Một request thì đơn giản đấy, nhưng hàng nghìn, trăm nghìn request vào một lúc sẽ như thế nào? Như bạn thấy đấy, Blog của tôi sập.

Cách đây khoảng 3 tuần, tôi có đăng lên bài viết chuyển từ DO sang Cloudflare. Tất cả đều có toan tính cả, ban đầu sẽ di chuyển giao diện sang trước, sau đó là API rồi tất cả mọi thứ để không cần duy trì hệ thống trên một máy chủ tập trung như của DO nữa. Có lẽ bài viết này đã "giật dây" cho một số đối tượng và họ quyết định thử xem sang "nhà mới" thì có chống được DDoS không?

Câu trả lời là có, nhưng chỉ một phần. Sau khi phát hiện ra trang chủ Blog không còn là SSR nữa. Những kẻ tấn công đã nhanh chóng nhận ra các cuộc gọi đến API của tôi vẫn nằm ở DO, và chúng tiếp tục tấn công vào API và hậu quả thì mọi người cũng biết rồi đấy - nó vẫn sập.

Cuối cùng, không thể chịu đựng thêm được nữa. Dù không có nhiều thời gian nhưng tôi phải thực hiện một cuộc di cư lớn sang Cloudflare để chấm dứt các cuộc tấn công này.

Khắc phục

Cloudflare (CF) - cái tên không quá xa lạ với nhiều người. Nhiều năm về trước, nhiều người biết đến nó với máy chủ Proxy miễn phí, SSL miễn phí, CDN rồi Cache... rất nhiều điều thú vị ở trên đó. Thời gian đầu, tôi sử dụng Cloudflare nhưng không hiểu hết công dụng của nó, hay thậm chí cài đặt xong trang web, thấy truy cập vào còn chậm hơn hay những tính năng cache cực kì khó chịu. Bẵng đi một thời gian, giờ đây Cloudflare có vẻ đã lột xác, các thao tác dường như rõ ràng hơn, tài liệu nhiều hơn và cộng đồng cũng lớn mạnh hơn.

Cloudflare ngăn chặn DDos từ lớp 3, 4. Tức là nó ngăn chặn được request đáng nghi trước khi vào được lớp 7 là ứng dụng của bạn. CF hứng mũi chịu sào cho bạn. Tất cả những gì cần làm là thiết lập cấu hình để cho nó ngăn chặn tất cả truy vấn đáng ngờ.

Thành thật mà nói CF có rất nhiều tính năng mà tôi chưa hiểu hết. Nhưng trước tiên, chúng ta hãy cứ tìm cách chống lại DDoS trước đã, những điều mới lạ sau đó sẽ dành thời gian để khai phá sau. Cách đơn giản nhất để chống DDoS là chuyển tên miền chính vào Cloudflare, bật Proxy lên và thiết lập Rate limit cho nó.

Rate limit là một hình thức giới hạn số lượng truy cập trong vòng bao lâu đó. Đây là một trong nhiều cách đơn giản mà hiệu quả nhằm chống lại tấn công DDoS. Bỗng nhiên một IP liên tục gửi yêu cầu đến địa chỉ của bạn, hẳn với mục đích là phá hoại hoặc "vô tình" sử dụng một dòng lệnh "loop" nào đó mà hắn cười khề khà khi được hỏi: "Xin lỗi, tôi không may tạo ra bug"... Chà, quả "bug" này to đấy, nếu bạn không "fix" được thì để tôi giúp.

Có thể sẽ hơi lấn cấn chỗ này, chẳng phải ở trên tôi nói thiết lập Rate limit cho máy chủ rồi mà vẫn không ăn thua sao? Thì hãy nhớ lại rằng, Cloudflare sẽ làm trung gian cho mọi truy vấn trước khi đến máy chủ thật của chúng ta, tức là tầng 7, mà theo họ, CF có công nghệ hay đơn giản là họ có khả năng chống được DDos ở lớp 3, 4. Tóm lại, thiết lập Rate limit ở CF, nó sẽ chặn được kha khá truy vấn trước khi nó vào đến được máy chủ thật của chúng ta.

Sau đây tôi sẽ chỉ cho bạn đọc cách cấu hình Rate limit để giảm thiểu tấn công DDoS qua Cloudflare. Lưu ý đây là một trong những cách mà tôi sử dụng, còn rất nhiều cách khác nữa cho nên nếu có phương pháp hay hơn xin hãy để lại bình luận dưới bài viết.

Đầu tiên, chắc chắn rồi, bạn hãy đăng ký một tài khoản Cloudflare và thiết lập tên miền muốn chống DDoS. Đừng lo lắng, Cloudflare sẽ hướng dẫn bạn cách làm ngay sau khi đăng ký thành công.

Sau khi tên miền được kích hoạt, hãy bấm vào nó, chọn "Security" > "WAF" ngay thanh điều hướng bên trái màn hình.

WAF hiểu đơn giản là FireWall của Cloudflare, nó cho phép bạn thiết lập, ngăn chặn, sửa đổi... request của người dùng trước khi vào đến máy chủ thật của bạn. Nhìn sang phía bên phải đi, để vào được máy chủ của bạn, một request có thể sẽ đi qua tất cả các lớp bảo mật này của CF đấy.

Ngay tại màn hình đó, chuyển sang tab "Rate limiting rules" và bấm vào nút "Create rule" to tướng màu xanh ngay phía dưới.

Tại đây, đặt tên cho "Rule", chọn đường dẫn để Cloudflare thiết lập giới hạn. Ví dụ ở đây tôi chọn "/", nghĩa là tất cả đường dẫn của tên miền chính sẽ được bảo vệ.

Tiếp theo, thiết lập giới hạn bằng cách điền vào ô "Requests" và "Period" - nghĩa là số lượng request trong vòng bao nhiêu giây. Ví dụ dưới đây tôi chọn 10 request trong vòng 10 giây cho mỗi IP. Nếu vượt quá con số này, người dùng sẽ nhận được một HTTP Status 429.

Cuối cùng lưu lại và hãy thử spam trang web của bạn đến giới hạn vừa thiết lập xem nó đã hoạt động hay chưa.

Nếu bạn hỏi tôi điền số lượng request như thế nào thì xin hãy "thử". Thử đi thử lại đến khi tìm ra được con số chính xác, bởi vì con số này phụ thuộc vào trang web của bạn đang gọi nhiều hay ít. Ví dụ trong một lần tải trang, nó gọi tổng cộng 20 request thì chắc chắn con số limit phải lớn hơn 20. Chưa kể 1 giây, rồi 2 giây... sau đó, nó tiếp tục gọi thêm "n" request nữa, hoặc cũng có thể người dùng liên tục điều hướng trang web của bạn, khiến phát sinh thêm "m" request nữa trong vòng bao nhiêu giây đó... Nói tóm lại, con số này phụ thuộc rất nhiều vào trang web của bạn cho nên hãy thử và tính toán sao cho hợp lý.

Cuối cùng, những con số thống kê về tất cả request vượt giới hạn sẽ nằm tại đây. Bạn có thể bấm vào con số "0" kia để xem chi tiết. Ở đây là tôi chưa có request nào vượt giới hạn trong vòng 24h qua.