Cách Sử Dụng Chế Độ "Under Attack" Của Cloudflare Khi Bị Tấn Công DDoS

Chế độ "Under Attack" của Cloudflare là một thiết lập phòng thủ khẩn cấp, giúp lọc lưu lượng bot bằng cách hiển thị cho người dùng một xác thực an ninh ngắn gọn. Bằng cách chọn trang web của bạn trong bảng điều khiển Cloudflare và kích hoạt tính năng Chế Độ "Under Attack" từ phần Bảo Mật, bạn có thể làm chậm các yêu cầu HTTP/HTTPS trong vài phút, bảo vệ khả năng truy cập của người dùng thực vào trang web và giảm tải cho máy chủ của bạn. Tuy nhiên, chế độ này không phải là giải pháp lâu dài; nó cần được sử dụng kết hợp với cài đặt proxy DNS chính xác, quy tắc WAF, giới hạn tốc độ, cấu hình bộ nhớ đệm và bảo mật máy chủ gốc.

Trong hướng dẫn này, chúng tôi sẽ từng bước giải thích cách kích hoạt chế độ "Under Attack" của Cloudflare, khi nào nên sử dụng, những cài đặt nào cần hỗ trợ và cách quay trở lại trạng thái bình thường một cách an toàn sau khi cuộc tấn công kết thúc. Mục tiêu là cung cấp một danh sách kiểm tra có thể thực hiện được trong lúc hoảng loạn và phục hồi khả năng truy cập của trang web của bạn trong thời gian ngắn nhất có thể.

Chế Độ "Under Attack" Của Cloudflare Là Gì?

Chế độ "Under Attack" của Cloudflare là cấp độ bảo mật khẩn cấp do Cloudflare cung cấp. Khi được kích hoạt, Cloudflare sẽ yêu cầu trình duyệt của người dùng thực hiện một xác thực ngắn gọn. Quy trình xác thực này thường chỉ mất vài giây và làm khó khăn cho việc các bot tự động, các công cụ tấn công HTTP đơn giản hoặc các client độc hại có thể tải trực tiếp lên trang web.

Mục tiêu chính của chế độ này là giảm thiểu các cuộc tấn công ở lớp ứng dụng, tức là ở cấp độ Layer 7. Ví dụ, nếu có hàng nghìn yêu cầu GET đến trang chính, hàng loạt thử nghiệm POST vào trang đăng nhập WordPress, hoặc các truy vấn tốn kém đến trang tìm kiếm, chế độ "Under Attack" sẽ cung cấp một phản ứng nhanh chóng.

Điều quan trọng là: chế độ "Under Attack" sẽ lọc các yêu cầu web; tuy nhiên, nếu địa chỉ IP của máy chủ của bạn bị tấn công trực tiếp, dịch vụ bên ngoài Cloudflare của bạn vẫn có thể bị lộ, hoặc nếu cuộc tấn công diễn ra ở cấp độ Layer 3/4, các biện pháp bổ sung là cần thiết. Do đó, việc đảm bảo rằng các bản ghi DNS được proxied qua Cloudflare, ẩn địa chỉ IP gốc và thực hiện các biện pháp bảo mật đúng cách từ phía hosting là hết sức quan trọng. Tham khảo thêm về Dịch vụ web hosting an toàn và Cài đặt chứng chỉ SSL.

Triệu Chứng Của Cuộc Tấn Công DDoS: Cần Kiểm Tra Gì Trước Khi Chuyển Sang Chế Độ "Under Attack"?

Không phải mọi sự chậm trễ đều là do DDoS. Đôi khi, một plugin lỗi, khóa cơ sở dữ liệu, tác vụ cron sử dụng CPU cao hoặc cài đặt bộ nhớ đệm sai cũng có thể gây ra kết quả tương tự. Do đó, trước khi kích hoạt chế độ "Under Attack", việc nhanh chóng chẩn đoán là rất hữu ích. Tuy nhiên, nếu máy chủ gặp khó khăn trong việc phản hồi, người dùng nhận được lỗi 502, 503, 504 và log có sự bùng nổ yêu cầu bất thường, thì chế độ khẩn cấp không nên bị trì hoãn.

Các Triệu Chứng DDoS Điển Hình

• Tăng lưu lượng truy cập từ 5, 10 hoặc 50 lần so với mức bình thường trong thời gian ngắn.
• Có hàng trăm yêu cầu đến một trang hoặc endpoint trong một giây.
• Lưu lượng truy cập đến từ nhiều quốc gia nhưng có giá trị user-agent tương tự.
• Các URL tốn kém như admin, login, search, cart trong WordPress, WooCommerce, OpenCart hoặc phần mềm tùy chỉnh bị tấn công.
• Máy chủ hết giới hạn kết nối CPU, RAM, PHP-FPM worker hoặc MySQL.
• Tăng đột biến các lỗi 4xx và 5xx trong bảng điều khiển phân tích Cloudflare.
• Người dùng thực có thể truy cập trang web một cách ngắt quãng, nhưng lưu lượng bot liên tục gửi yêu cầu.

Ví dụ, nếu một trang thương mại điện tử bình thường nhận 2.000 yêu cầu mỗi phút, mà trong 10 phút tăng lên 80.000 yêu cầu mỗi phút, và 70% yêu cầu đi đến trang giỏ hàng hoặc tìm kiếm, đây là dấu hiệu rõ ràng của một cuộc tấn công Layer 7. Trong kịch bản này, chế độ "Under Attack" nên được kích hoạt trong vòng 5 phút đầu tiên, sau đó các quy tắc WAF và giới hạn tốc độ cần được thêm vào cho các URL mục tiêu.

Khi Nào Nên Sử Dụng Chế Độ "Under Attack" Của Cloudflare?

Chế độ "Under Attack" của Cloudflare không phải là một thiết lập bảo mật tiêu chuẩn cần được giữ mở liên tục. Bởi vì nó cũng hiển thị một màn hình chờ ngắn cho những người truy cập thực. Tình huống này đặc biệt có thể ảnh hưởng đến trải nghiệm người dùng trên các trang tập trung vào chuyển đổi, ở các bước thanh toán hoặc trong các cấu trúc sử dụng API. Cách sử dụng đúng nhất là kích hoạt tạm thời trong thời gian tấn công và điều chỉnh mức độ bảo mật khi lưu lượng truy cập trở lại bình thường.

Các Tình Huống Thích Hợp Để Sử Dụng

• Khi có lưu lượng yêu cầu HTTP/HTTPS dày đặc và bất thường vào trang web.
• Khi tài nguyên máy chủ đang cạn kiệt nhanh chóng và tỷ lệ lỗi 502/503 tăng cao.
• Khi WAF của Cloudflare chưa được cấu hình với các quy tắc riêng và cần một lớp bảo vệ nhanh chóng.
• Khi lưu lượng bot vượt quá rõ ràng so với lưu lượng người dùng thực.
• Khi các trang web, biểu mẫu, màn hình đăng nhập hoặc endpoint tìm kiếm là mục tiêu của cuộc tấn công.

Các Tình Huống Cần Thận Trọng

• Khi lưu lượng API, nhà cung cấp thanh toán, webhook hoặc API đang sử dụng cao.
• Khi bạn đang ở giai đoạn quan trọng cho việc thu thập thông tin từ bot tìm kiếm.
• Khi người dùng doanh nghiệp của bạn đang truy cập từ các trình duyệt cũ hoặc từ mạng hạn chế.
• Khi bạn có các subdomain không nằm sau proxy Cloudflare trên trang web của mình.

Trong các trang web có lưu lượng API, nếu chế độ "Under Attack" được áp dụng cho toàn bộ tên miền, một số tích hợp có thể bị thất bại. Do đó, nếu có thể, nên lập kế hoạch cho quy tắc WAF đặc biệt, danh sách cho phép hoặc mức độ bảo mật khác cho các subdomain API. Để biết thêm chi tiết về bảo mật API, hãy tham khảo Hướng dẫn an ninh API và giới hạn tần suất.

Làm Thế Nào Để Kích Hoạt Chế Độ "Under Attack" Của Cloudflare? Hướng Dẫn Từng Bước

Các bước dưới đây là danh sách kiểm tra thực tiễn đã được chuẩn bị để hành động nhanh chóng trong lúc xảy ra tấn công. Giao diện Cloudflare có thể có những thay đổi nhỏ theo thời gian; tuy nhiên, logic vẫn không thay đổi: bạn chọn tên miền của mình, nâng cao mức độ bảo mật và xác thực lưu lượng truy cập đến qua Cloudflare.

1. Đăng Nhập Vào Tài Khoản Cloudflare Của Bạn

Đầu tiên, hãy đăng nhập vào tài khoản Cloudflare của bạn và chọn tên miền đang bị tấn công. Nếu bạn quản lý nhiều tên miền, hãy đảm bảo bạn đang làm việc trên đúng zone. Mở chế độ "Under Attack" trên một tên miền sai sẽ gây lãng phí thời gian và cuộc tấn công thực sự vẫn đang tiếp diễn.

2. Kiểm Tra Các Bản Ghi DNS Được Proxied

Để chế độ "Under Attack" có hiệu quả, lưu lượng web phải đi qua Cloudflare. Trong phần DNS, hãy đảm bảo rằng các bản ghi A, AAAA và CNAME đang ở trạng thái đám mây màu cam, tức là đã được proxied. Các bản ghi DNS có đám mây xám (chỉ DNS) không được đi qua lớp bảo mật Cloudflare. Đặc biệt cần kiểm tra www, tên miền gốc và các subdomain đang sử dụng.

Nếu địa chỉ IP gốc của bạn có thể nhìn thấy trên Internet, kẻ tấn công có thể bỏ qua Cloudflare và tấn công trực tiếp vào máy chủ. Do đó, việc cho phép chỉ lưu lượng HTTP/HTTPS từ dải IP của Cloudflare trong tường lửa máy chủ là một biện pháp bảo vệ mạnh mẽ. Bạn có thể nhận hỗ trợ từ nhà cung cấp dịch vụ hosting của bạn về vấn đề này hoặc tham khảo Cách thực hiện cài đặt DNS Cloudflare.

3. Kích Hoạt Tính Năng Chế Độ "Under Attack" Từ Phần Bảo Mật

Sau khi mở tên miền liên quan trong bảng điều khiển Cloudflare, hãy tìm tùy chọn Chế Độ "Under Attack" trong màn hình Bảo Mật hoặc Tổng Quan. Khi bạn kích hoạt tùy chọn này, Cloudflare sẽ bắt đầu hiển thị một trang xác thực ngắn cho những người truy cập vào trang web. Trong một số bảng điều khiển, cài đặt này cũng có thể xuất hiện dưới tên "I am Under Attack" trong phần Mức độ Bảo mật.

Thay đổi sau khi kích hoạt thường sẽ có hiệu lực trong thời gian ngắn. Trong vài phút đầu tiên, cần theo dõi Cloudflare Analytics, Sự kiện Bảo mật và mức tiêu thụ nguồn của máy chủ. Nếu số lượng CPU và kết nối bắt đầu giảm, điều đó có nghĩa là chế độ đã hoạt động. Tuy nhiên, nếu tỷ lệ lỗi vẫn tiếp tục cao, các quy tắc bổ sung cần được viết thêm.

4. Kiểm Tra Trải Nghiệm Của Người Dùng Thực

Sau khi kích hoạt chế độ, hãy kiểm tra trang web từ các mạng khác nhau. Cần thử nghiệm trang chính, trang sản phẩm, trang đăng nhập và quy trình thanh toán từ mạng di động, mạng văn phòng và nếu có thể từ một vị trí khác. Nếu người dùng có thể truy cập trang web sau khi vượt qua màn hình xác thực, đó là hành vi mong đợi. Nếu người dùng bị mắc kẹt trong vòng lặp xác thực vô tận, cần kiểm tra các cài đặt chặn cookie, sự tương thích trình duyệt hoặc các xung đột quy tắc bảo mật Cloudflare.

5. Xác Định Các URL Mục Tiêu Của Cuộc Tấn Công

Chế độ "Under Attack" cung cấp một lớp bảo vệ tổng thể; tuy nhiên, hiệu quả thực sự chỉ được nhận thấy khi có các quy tắc cụ thể cho từng mục tiêu. Từ các Sự kiện Bảo mật Cloudflare, Phân tích Web, log truy cập hosting và log ứng dụng, hãy xác định các đường dẫn nhận được nhiều yêu cầu nhất. Ví dụ, các URL như /wp-login.php, /xmlrpc.php, /search, /cart, /api/login hoặc /checkout có thể đang bị tấn công.

Khi đã xác định được URL mục tiêu, có thể thực hiện các hành động dựa trên các tiêu chí như quốc gia, user-agent, phương thức yêu cầu, đường dẫn URI hoặc điểm số bot với WAF Custom Rules. Ví dụ, có thể áp dụng managed challenge cho các IP gửi yêu cầu vượt quá số lượng hợp lý mỗi phút cho một endpoint đăng nhập nhất định. Đối với các trang WordPress, liên kết Các biện pháp bảo mật WordPress là một cơ hội liên kết tự nhiên.

Sự Khác Biệt Giữa Chế Độ "Under Attack" Và Các Tùy Chọn Bảo Mật Khác Của Cloudflare

Các công cụ bảo mật của Cloudflare phục vụ cho các mục đích khác nhau. Chế độ "Under Attack" là một bộ lọc khẩn cấp nhanh chóng và tổng quát; trong khi WAF và Giới Hạn Tốc Độ cung cấp các giải pháp nhắm mục tiêu hơn, bền vững hơn và cân bằng hơn về trải nghiệm người dùng.

Trong thực tế, một cách tiếp cận bảo vệ tốt sẽ diễn ra như sau: Đầu tiên giảm áp lực khẩn cấp bằng chế độ "Under Attack", sau đó phân tích mẫu tấn công, thêm các quy tắc WAF và giới hạn tốc độ, cuối cùng củng cố cấu trúc lâu dài thông qua các cài đặt bộ nhớ đệm và tường lửa gốc.

Các Cài Đặt Cloudflare Khuyên Dùng Trong Thời Gian Tấn Công

Dù chế độ "Under Attack" có thể được kích hoạt chỉ bằng một nút nhấn, nhưng sự thành công trong việc phòng chống DDoS phụ thuộc vào các cài đặt hỗ trợ. Các gợi ý sau đây là những ứng dụng thường được thực hiện nhất trong các hoạt động thực tế.

Tạo Bảo Vệ Nhắm Mục Tiêu Với Các Quy Tắc WAF

WAF của Cloudflare cho phép bạn thực hiện các hành động dựa trên các điều kiện cụ thể. Ví dụ, bạn có thể áp dụng thách thức cho các yêu cầu POST đến trang /wp-login.php chỉ từ các quốc gia cụ thể. Bằng cách này, bạn cô lập mục tiêu của cuộc tấn công mà không làm nặng toàn bộ trang web.

• Mở trang admin và đăng nhập chỉ cho các quốc gia hoặc dải IP cụ thể.
• Chặn các endpoint không sử dụng như XML-RPC.
• Áp dụng managed challenge cho các giá trị user-agent nghi ngờ.
• Giới hạn tốc độ đối với các client gửi yêu cầu quá thường xuyên trên một đường dẫn URI cụ thể.

Đặt Mức Độ Bộ Nhớ Đệm Đúng Cách

Nếu máy chủ gốc cần phản hồi cho mọi yêu cầu trong thời gian tấn công, tài nguyên sẽ nhanh chóng cạn kiệt. Các tệp tĩnh, hình ảnh, CSS, JavaScript và các trang có thể lưu trữ cần được phục vụ qua Cloudflare edge. Trong các nền tảng động như WordPress, plugin bộ nhớ đệm, quy tắc bộ nhớ đệm Cloudflare và tiêu đề bộ nhớ đệm thích hợp có thể được sử dụng kết hợp.

Ví dụ, trong một trang tin tức hoặc blog, các trang hiển thị cho khách truy cập ẩn danh có thể được lưu trữ từ 5 đến 30 phút. Cài đặt đơn giản này có thể giảm thời gian TTFB ngay cả trong giai đoạn không có tấn công và giảm tải cho tài nguyên hosting. Về mặt hiệu suất, có thể tham khảo liên kết Hướng dẫn tăng tốc website.

Xác Định Ngưỡng Giới Hạn Tốc Độ Một Cách Thực Tế

Giới hạn tốc độ rất hiệu quả, đặc biệt là đối với các endpoint tốn kém. Tuy nhiên, nếu ngưỡng được thiết lập ngẫu nhiên, người dùng thực có thể bị chặn. Ví dụ, một người dùng thông thường có thể thực hiện từ 5 đến 15 tìm kiếm mỗi phút trên một trang tìm kiếm sản phẩm; 100 tìm kiếm mỗi phút là bất thường. Trên trang đăng nhập, 10 lần thử không thành công trong 5 phút là nghi ngờ trong hầu hết các kịch bản.

Một cách tiếp cận ví dụ: áp dụng managed challenge cho các IP gửi hơn 10 yêu cầu cho /wp-login.php trong 1 phút, và áp dụng chặn tạm thời cho các IP gửi hơn 50 yêu cầu trong 5 phút. Đối với các endpoint API, các giới hạn chính xác hơn nên được thiết lập dựa trên session người dùng, IP, token và phương thức.

Ẩn Địa Chỉ IP Gốc Và Giới Hạn Bằng Tường Lửa

Một trong những sai lầm nghiêm trọng nhất khi sử dụng Cloudflare là để địa chỉ IP gốc bị lộ. Các bản ghi DNS cũ, các subdomain hoạt động với IP trực tiếp, các dịch vụ web bị nhầm lẫn với bản ghi email hoặc các cấu hình bị rò rỉ có thể cho phép kẻ tấn công truy cập vào máy chủ mà không cần thông qua Cloudflare.

Ở phía máy chủ, mở cổng 80 và 443 chỉ cho các dải IP của Cloudflare sẽ cung cấp một bảo vệ mạnh mẽ. Ngoài ra, các cổng SSH, bảng điều khiển, cơ sở dữ liệu và quản lý không nên để công khai trên Internet; cần sử dụng giới hạn IP, mật khẩu mạnh, 2FA và nếu có thể thì sử dụng VPN. Về bảo mật hosting, có thể tham khảo Cài đặt bảo mật cPanel và Cấu Hình Tường Lửa VPS.

Các Điểm Cần Lưu Ý Đặc Biệt Đối Với WordPress, WooCommerce Và Các Trang Doanh Nghiệp

Không phải trang web nào cũng có cùng cấu trúc lưu lượng. Một trang blog, một cửa hàng WooCommerce, và một bảng điều khiển SaaS có thể có những kết quả khác nhau khi sử dụng chế độ "Under Attack" của Cloudflare. Do đó, cần xác định các đường dẫn quan trọng theo loại trang.

Trang WordPress

Những tệp thường bị tấn công nhiều nhất trên WordPress là /wp-login.php và /xmlrpc.php. Nếu bạn không sử dụng XML-RPC, việc chặn nó thường là an toàn. Có thể áp dụng các hạn chế theo quốc gia hoặc IP cho bảng điều khiển admin. Ngoài ra, các plugin bảo mật không nên xung đột với quy tắc Cloudflare; quá nhiều cơ chế thách thức đồng thời có thể khiến người dùng rơi vào vòng lặp xác thực.

Cửa Hàng WooCommerce

Các trang giỏ hàng, thanh toán và tài khoản trong WooCommerce cần được chú ý. Vì những trang này có tính động, nên không nên áp dụng bộ nhớ đệm quá mạnh. Khi chế độ "Under Attack" đang hoạt động, cần đảm bảo rằng các URL callback hoặc webhook của nhà cung cấp thanh toán vẫn hoạt động. Nếu cần, có thể đưa các dải IP của nhà cung cấp thanh toán vào danh sách cho phép hoặc viết quy tắc riêng cho endpoint liên quan.

Trang Doanh Nghiệp Và Sử Dụng API

Các cổng doanh nghiệp, tích hợp CRM và API cho các ứng dụng di động có thể không xử lý được màn hình thách thức JavaScript. Trong những cấu trúc này, thay vì áp dụng chế độ "Under Attack" cho toàn bộ tên miền, có thể quản lý riêng subdomain API. Ví dụ, có thể kích hoạt chế độ "Under Attack" cho www.example.com trong khi áp dụng bảo mật dựa trên token, giới hạn tốc độ và danh sách cho phép cho api.example.com.

Những Thống Kê Cần Theo Dõi Sau Khi Kích Hoạt Chế Độ "Under Attack"

Để hiểu một biện pháp bảo mật có hiệu quả hay không, cần có sự giám sát số liệu. Chỉ việc trang web có thể mở ra không đủ; cần phải đánh giá tỷ lệ lỗi, tải máy chủ và hành vi của người dùng thực cùng nhau.

• Sự kiện Bảo mật Cloudflare: Cho biết các quy tắc nào đã thực hiện bao nhiêu yêu cầu thách thức hoặc chặn.
• Mã trạng thái HTTP: Cần theo dõi sự thay đổi trong các lỗi 403, 429, 502, 503 và 504.
• Khả năng sử dụng CPU và RAM của máy chủ: Sẽ có sự giảm sau khi kích hoạt chế độ "Under Attack".
• Kết nối PHP-FPM và MySQL: Cho thấy sự giảm tải ở lớp ứng dụng.
• Băng thông và số lượng yêu cầu: Cần so sánh khối lượng lưu lượng với tỷ lệ yêu cầu bị lọc.
• Chuyển đổi của người dùng thực: Cần kiểm tra việc gửi biểu mẫu, đơn hàng, đăng nhập và các bước thanh toán.

Ví dụ, nếu sau khi kích hoạt chế độ "Under Attack", tổng số yêu cầu vẫn giữ nguyên nhưng số yêu cầu đến máy chủ gốc giảm 60%, điều đó có nghĩa là lớp Cloudflare đang hấp thụ một khối lượng lớn. Tuy nhiên, nếu việc sử dụng CPU MySQL vẫn cao, cuộc tấn công có thể đã kích hoạt một truy vấn động cụ thể; trong trường hợp này, cần xem xét các log ứng dụng.

Như Thế Nào Để Tắt Chế Độ "Under Attack" Sau Khi Cuộc Tấn Công Kết Thúc?

Không nên để chế độ "Under Attack" mở liên tục sau khi lưu lượng tấn công trở lại bình thường cho hầu hết các trang web. Bởi vì việc hiển thị xác thực bổ sung cho mỗi người dùng có thể ảnh hưởng đến tỷ lệ chuyển đổi, hiệu quả thu thập thông tin và sự hài lòng của người dùng. Quy trình tắt cũng cần được thực hiện một cách có kiểm soát như khi mở.

Các Bước Quay Trở Lại An Toàn

• Chờ ít nhất 30-60 phút để lưu lượng truy cập trở lại mức bình thường.
• Xác minh rằng số lượng thách thức và chặn đã giảm trên màn hình Sự kiện Bảo mật Cloudflare.
• Đảm bảo rằng các quy tắc WAF và giới hạn tốc độ nhắm mục tiêu vẫn đang hoạt động trước khi tắt chế độ "Under Attack".
• Điều chỉnh mức độ bảo mật xuống mức cân bằng hơn như High hoặc Medium.
• Kiểm tra trang web từ các thiết bị khác nhau và theo dõi tỷ lệ lỗi 5xx.
• Theo dõi log trong 24 giờ để kiểm tra xem cuộc tấn công có bắt đầu lại hay không.

Để thực hiện tốt, nên tạo một báo cáo sự cố sau cuộc tấn công. Trong báo cáo này, cần ghi lại thời gian bắt đầu tấn công, các URL mục tiêu, số lượng yêu cầu lớn nhất, các hành động đã thực hiện, các quy tắc hiệu quả và các cải tiến lâu dài. Tài liệu này sẽ giúp rút ngắn thời gian can thiệp trong các sự kiện tiếp theo.

Các Lỗi Thường Gặp Và Những Điều Cần Tránh

Cần phải đưa ra quyết định nhanh chóng trong lúc xảy ra DDoS; tuy nhiên, các cài đặt sai có thể chặn cả người dùng thực. Các lỗi sau đây thường xảy ra khi chịu áp lực lớn.

• Cho rằng chế độ "Under Attack" sẽ bảo vệ mà không cần proxied các bản ghi DNS.
• Để địa chỉ IP gốc bị lộ và không chặn truy cập từ bên ngoài Cloudflare trong tường lửa.
• Áp dụng thách thức cho toàn bộ tên miền mà không kiểm tra các địa chỉ API, webhook và callback thanh toán.
• Viết các quy tắc WAF chặn quá rộng khiến người dùng thực bị chặn.
• Bộ nhớ đệm quá mạnh các trang giỏ hàng, thanh toán hoặc bảng điều khiển người dùng mà không nên bộ nhớ đệm.
• Để chế độ mở hàng tuần sau khi cuộc tấn công kết thúc.
• Chỉ nhìn vào màn hình Cloudflare mà không xem xét log máy chủ để đưa ra quyết định.

Đặc biệt, việc chặn các callback thanh toán trên các trang thương mại điện tử có thể dẫn đến mất doanh thu nghiêm trọng. Do đó, khi viết quy tắc bảo mật, nên thử nghiệm với các hành động log hoặc managed challenge trước, thay vì chặn ngay lập tức. Sau khi thấy hiệu quả của quy tắc, có thể chuyển sang các biện pháp cứng rắn hơn.

Lập Kế Hoạch Cho Một Hệ Thống Phòng Ngừa Bền Vững Trên Nền Tảng Hostragons Như Thế Nào?

Cloudflare cung cấp một lớp bảo vệ mạnh mẽ; tuy nhiên, việc phòng chống DDoS thành công không chỉ dừng lại ở phía CDN. Cấu trúc hosting, tối ưu hóa phần mềm, cài đặt SSL, quản lý DNS và chiến lược sao lưu cũng cần được xem xét. Đối với một trang web được lưu trữ trên Hostragons, cách tiếp cận cơ bản nên như sau: Cloudflare lọc lưu lượng, lớp hosting chỉ tiếp nhận lưu lượng sạch, còn ứng dụng thì được tối ưu để không tạo ra tải cơ sở dữ liệu không cần thiết.

Trước khi một dự án mới được phát hành, việc quản lý tên miền với các bản ghi DNS chính xác, cài đặt chứng chỉ SSL một cách suôn sẻ và chọn các tài nguyên máy chủ web phù hợp với hồ sơ lưu lượng của bạn là rất quan trọng. Ở đây, các liên kết Tra cứu tên miền và đăng ký tên miền, Gói hosting web, giải pháp hosting doanh nghiệp và Chứng chỉ SSL miễn phí có thể giúp ích cho người dùng.

Đối với các dự án có lưu lượng truy cập cao hoặc có nguy cơ tấn công cao, nên xem xét các tùy chọn VPS hoặc máy chủ quản lý thay vì hosting chia sẻ tiêu chuẩn. Bằng cách này, tường lửa, máy chủ web, PHP-FPM, Redis, bộ nhớ đối tượng và cài đặt cơ sở dữ liệu có thể được cấu hình một cách linh hoạt hơn. Tuy nhiên, cho dù nền tảng nào được chọn, chế độ "Under Attack" của Cloudflare chỉ nên được coi là một công cụ khẩn cấp; kiến trúc bảo mật lâu dài cần được hỗ trợ bởi WAF, phân tích log và cập nhật thường xuyên.

Danh Sách Kiểm Tra Nhanh: 15 Phút Đầu Tiên Khi Xảy Ra Tấn Công DDoS

Thời gian là rất quan trọng trong lúc xảy ra tấn công. Danh sách dưới đây tóm tắt những gì đội kỹ thuật hoặc chủ sở hữu trang web có thể làm trong 15 phút đầu tiên.

• Đăng nhập vào bảng điều khiển Cloudflare và chọn tên miền đúng.
• Kiểm tra các bản ghi DNS có đám mây màu cam, tức là đã được proxied.
• Kích hoạt chế độ "Under Attack".
• Kiểm tra trang chính, đăng nhập, giỏ hàng, thanh toán và các endpoint API.
• Xác định các URL mục tiêu từ màn hình Sự kiện Bảo mật Cloudflare.
• Thêm quy tắc WAF hoặc giới hạn tốc độ cho các đường dẫn bị tấn công nhiều nhất.
• Kiểm tra tình trạng CPU, RAM, PHP-FPM và MySQL của máy chủ.
• Kiểm tra xem có truy cập trực tiếp vào IP gốc hay không.
• Xem xét xem có cần danh sách cho phép cho các nhà cung cấp thanh toán, webhook và các tích hợp quan trọng hay không.
• Ghi lại tất cả các hành động cùng với thời gian.

Nếu danh sách này được thực hiện thường xuyên, sự hoảng loạn trong một cuộc tấn công thực sự sẽ giảm đi và chất lượng can thiệp sẽ tăng lên. Đối với các trang web lớn, nên tài liệu hóa quy trình này thành một kế hoạch can thiệp sự kiện.

Các Câu Hỏi Thường Gặp

Chế độ "Under Attack" của Cloudflare có bảo vệ hoàn toàn cho trang web không?

Không. Chế độ "Under Attack" của Cloudflare hiệu quả trong việc giảm lưu lượng bot và flood ở cấp độ HTTP/HTTPS; nhưng không cung cấp bảo vệ toàn diện nếu không được kết hợp với các bản ghi DNS được proxied, ẩn địa chỉ IP gốc, quy tắc WAF, giới hạn tốc độ, bộ nhớ đệm và các cài đặt tường lửa trên máy chủ.

Chế độ "Under Attack" có gây hại cho SEO không?

Sử dụng ngắn hạn thường không gây tổn hại nghiêm trọng đến SEO. Tuy nhiên, nếu chế độ này được mở quá lâu, hiệu quả thu thập thông tin của công cụ tìm kiếm và trải nghiệm người dùng có thể bị ảnh hưởng. Do đó, sau khi tấn công kết thúc, tắt chế độ và tiếp tục với các quy tắc bảo mật nhắm mục tiêu là điều tốt hơn.

Chế độ "Under Attack" nên mở trong bao lâu?

Chế độ này có thể mở cho đến khi cường độ tấn công giảm; thực tế là sau khi lưu lượng trở lại bình thường, nên theo dõi ít nhất 30-60 phút và sau đó tắt từ từ. Trước khi tắt chế độ, cần đảm bảo rằng các quy tắc lâu dài như WAF và giới hạn tốc độ đã sẵn sàng.

Chế độ "Under Attack" có ảnh hưởng đến API hoặc hệ thống thanh toán không?

Có, nó có thể ảnh hưởng. Bởi vì một số client API, dịch vụ webhook và hệ thống callback thanh toán không thể hoàn thành xác thực an ninh dựa trên trình duyệt. Do đó, các endpoint quan trọng cần được thử nghiệm, và nếu cần, nên xác định các quy tắc Cloudflare riêng hoặc danh sách cho phép.

Có cần thực hiện thêm biện pháp nào bên phía hosting khi sử dụng Cloudflare không?

Có. Cloudflare cung cấp bảo vệ mạnh mẽ ở lớp trước; nhưng địa chỉ IP của máy chủ gốc cần được ẩn, tường lửa chỉ nên cho phép lưu lượng cần thiết, phần mềm cần được cập nhật và cấu hình bộ nhớ đệm cần phải chính xác. Hạ tầng hosting an toàn là một phần quan trọng của khả năng chống DDoS.

Kết Luận

Chế độ "Under Attack" của Cloudflare là một công cụ khẩn cấp hiệu quả, giúp làm dịu tình hình cho một trang web đang bị tấn công DDoS. Khi được kích hoạt với cài đặt proxy DNS chính xác, nó giúp giảm lưu lượng bot, giảm tải cho máy chủ và tăng khả năng người dùng thực tiếp cận trang web. Để đạt được kết quả tốt nhất, chế độ này cần được hỗ trợ bởi các quy tắc WAF, giới hạn tốc độ, tối ưu hóa bộ nhớ đệm và bảo mật tường lửa gốc.

Nếu bạn muốn trang web của mình hoạt động bền bỉ hơn trước các cuộc tấn công, hãy thường xuyên xem xét cơ sở hạ tầng, quản lý DNS và cấu hình SSL của bạn. Bạn có thể khám phá các giải pháp hosting, tên miền và SSL của Hostragons để tạo ra một nền tảng an toàn và bền vững hơn cho trang web của mình.