TCRF kể lại 12 ngày bị DDoS: từ Claude ban đến Linode null-route và cú lừa mang tên Fastly

The Cutting Room Floor (TCRF) — wiki nổi tiếng chuyên khai thác nội dung cắt bỏ trong game — vừa đăng bài postmortem chi tiết về đợt tấn công DDoS kéo dài gần hai tuần, bắt đầu từ ngày 27/8. Câu chuyện không chỉ là nhật ký hạ tầng mà còn là lời cảnh tỉnh cho mọi quản trị viên web nhỏ: chống DDoS thực sự tốn tiền, tốn thời gian, và đôi khi cả những nhà cung cấp lớn cũng không giúp được gì như bạn tưởng.

Chuyện bắt đầu từ một danh sách ban dành cho AI agent

Trước khi kể về cuộc tấn công, chủ site tiết lộ một chi tiết đáng chú ý: anh đã thêm tính năng tự động thêm người dùng vào "danh sách ban Claude" nếu họ truy cập site bằng user agent của Claude Code. Ai đó từng bị ban rồi tìm cách lách qua, sau đó tỏ ra ngày càng tức giận và dựng nên câu chuyện không có thật rằng site đã xóa sạch VM và hệ điều hành của anh ta. Câu chuyện này còn được một số trang công nghệ đưa tin, dù hoàn toàn không có căn cứ.

Điều đáng nói là cuộc tấn công DDoS nổ ra ngay sau khi ồn ào trên nổ ra. Chủ site cho rằng thời điểm trùng khớp như vậy "khó có thể coi là ngẫu nhiên".

Minh họa về việc cấm AI agent truy cập site

Cuộc tấn công diễn ra như thế nào?

Khác với các kiểu DDoS thông thường nhắm vào bot hoặc scraper để làm cạn CPU khi sinh trang, đợt tấn công này đơn thuần bão hòa đường truyền mạng bằng lưu lượng rác khổng lồ. Các công cụ chống bot như Anubis — vốn yêu cầu bot phải giải toán mất một giây trước khi xem trang — hoàn toàn vô dụng trong tình huống này.

Lưu lượng rác lớn đến mức Linode buộc phải null-route (vô hiệu hóa kết nối) máy chủ của TCRF vì traffic bắt đầu ảnh hưởng đến các khách hàng khác dùng chung hạ tầng. Nói cách khác: nhà cung cấp không đỡ nổi lượng rác bay vào.

"Tất cả phần màu tím đó? Tệ thật đấy."

Dòng thời gian đáng chú ý:

• 12:11 trưa 27/8: Chart CPU lần đầu hiện phần màu tím bất thường — biểu thị hệ thống đang phải xử lý luồng traffic rác khổng lồ. Đợt này kéo dài khoảng nửa tiếng.
• 19:39 ngày 27/8: Đợt tấn công thứ hai ập đến, đánh sập mọi kết nối. Traffic rác dồn vào cổng 80 dù phần lớn đã bị lọc bởi ufw và nginx.
• 20:34: Chủ site liên hệ hỗ trợ Linode sau khi thử đủ mọi cách.
• 22:44: Linode xác nhận hệ thống chống DDoS tự động đã kích hoạt chặn ở tầng router, không có ETA cụ thể để gỡ bỏ thủ công.

Biểu đồ lưu lượng mạng tăng vọt trong đợt DDoS

Ngày thứ hai: dựng server dự phòng, bị đánh sập luôn

Sang ngày 28/8, cuộc tấn công vẫn chưa dừng sau hơn 12 giờ. Chủ site dựng một server phụ chỉ để phục vụ trang trạng thái tí hon dưới 3 KB, đổi DNS và tưởng mọi chuyện đã xong.

Không may, kẻ tấn công quét và đánh sập luôn cả server dự phòng, đồng thời nhắm vào các dịch vụ phụ trợ khác mà chủ site đang vận hành, bao gồm chính blog cá nhân. Phần lớn các dịch vụ này chạy trên shared hosting, tức là ngay cả muốn dùng Anubis cũng không được.

Cùng lúc đó, các báo cáo lạm dụng vô căn cứ cũng liên tục được gửi đến Linode và Akamai với URL bịa đặt, buộc chủ site phải phản hồi từng lần một rằng "URL này không tồn tại và chưa từng tồn tại".

Ngày thứ ba: tín hiệu giả và sự thật phũ phàng

Sáng 29/8, Linode thông báo không thấy null-route nào trên địa chỉ IPv4 nữa, tưởng như cuộc tấn công đã kết thúc. Nhưng kiểm tra thực tế cho thấy mọi thứ vẫn chết: uptime tracker báo down, log traffic trống rỗng.

Sau khi đào sâu, Linode thừa nhận block chưa từng được gỡ. Thông báo trước đó dựa trên dữ liệu giám sát chưa đầy đủ. Đến 15:49, họ xác nhận cuộc tấn công vẫn đang diễn ra ở cường độ cao.

• Thời điểm này: cuộc tấn công đã kéo dài 1 ngày 20 giờ.
• Kết luận của chủ site: chờ đợi không phải giải pháp. Kẻ tấn công rõ ràng có nhiều tiền hơn là lý trí, và cần một dịch vụ tầng 3 mới xử lý nổi.

Cú lừa mang tên Fastly

Chủ site quyết định thử Fastly thay vì Cloudflare — dịch vụ mà anh không mấy thiện cảm. Fastly quảng cáo rõ ràng: "Đang bị tấn công? Tạo tài khoản miễn phí để định tuyến traffic qua mạng Fastly trong vài phút và nhận ngay khả năng chống DDoS."

Nhưng thực tế phũ phàng:

• Sau 14 giờ chạy trang downtime tí hon, tài khoản đã vượt hạn mức 10 USD và lên tới 21 USD.
• Tính năng "DDoS protection" tính phí 20 USD nhưng chặn đúng 0 yêu cầu và cho qua 100%.
• Đến 14:30 ngày 30/8, tài khoản Fastly bị đình chỉ mà không có email hay thông báo nào.
• Gần một ngày sau, Fastly mới giải thích: tài khoản Dev không được dùng để xử lý lưu lượng lớn như vậy, nên bị khóa vì "lạm dụng băng thông".

"Điều họ không nói với bạn là khả năng 'chống DDoS tức thì' cũng được đo bằng phút — khoảng 900 phút. Ít nhất là với chúng tôi."

Cùng lúc đó, một lỗi opsec nghiêm trọng xuất hiện: trong lúc vội vàng cấu hình Fastly, chủ site quên giới hạn backend chỉ nhận request từ frontend được phép. Kẻ tấn công chỉ cần quét dải IP của Linode, hỏi từng địa chỉ xem có phải site của TCRF không, và tìm ra server dự phòng.

Cloudflare vào cuộc và ngày kết thúc

Chiều 30/8, tcrf.net được chuyển sang Cloudflare và bật chế độ "Under Attack". Ngay sau đó, kẻ tấn công còn chủ động liên hệ qua Telegram và Discord, nhưng bị chặn ngay lập tức.

Đến nửa đêm 1/9 — tức 4 ngày 4 giờ sau khi cuộc tấn công bắt đầu — site chính thức hoạt động trở lại, dù cuộc tấn công vẫn chưa dừng hẳn.

Ngày 9/9, lúc 12 giờ trưa, lưu lượng rác cuối cùng biến mất khỏi cả server chính lẫn server dự phòng. Đến 16:22, Linode xác nhận block cuối cùng đã được gỡ bỏ. Tổng cộng: 12 ngày 16 giờ.

Những thứ thu được sau cơn bão

Dù trải qua quãng thời gian dài đầy mệt mỏi, quá trình chống chọi cũng mang lại nhiều nâng cấp đáng giá cho hạ tầng TCRF:

• Cải thiện caching và phân phối nội dung
• Hỗ trợ đầy đủ IPv6
• Tự động chặn nhiều loại bot, bao gồm cả Tor exit node
• Bỏ chặn hầu hết VPN
• Nhúng nội dung tốt hơn cho Discord, Bluesky
• Lưu trữ tự động lên Wayback Machine qua Cloudflare
• Hỗ trợ HTTP/2 và HTTP/3
• Hệ thống firewall và bảo mật tốt hơn
• Phân tích cơ bản vượt xa log nginx thuần túy

Mục tiêu lâu dài của chủ site là xây dựng một proxy không phụ thuộc Cloudflare cho người dùng đã đăng nhập, để những ai không thể truy cập qua Cloudflare — ví dụ vì dùng phần cứng quá cũ — vẫn xem được site.

Câu chuyện của TCRF là lời nhắc nhở rõ ràng: với hạ tầng nhỏ, một cuộc tấn công DDoS tầng mạng có thể biến mọi giải pháp miễn phí hoặc giá rẻ thành vô nghĩa, còn các dịch vụ trả phí thì chưa chắc đã minh bạch về giới hạn và chi phí của mình.