Chúng tôi không làm gì trước những nỗ lực tấn công DDoS kéo dài nhiều tuần

Đang bị tấn công DDoS nhưng không làm gì cả

• Trong nhiều tuần qua, đã có ai đó cố gắng thực hiện tấn công DDoS.
• Họ dội hàng triệu request vào máy chủ để cố tải tệp cấu hình xuống hàng triệu lần.
• Chỉ trong 5 ngày gần đây, đã có hơn 800.000 lần thử tải xuống, và mỗi lần tải tệp cấu hình có dung lượng khoảng 200MB.
• Phần lớn lưu lượng đến từ EU, đặc biệt là Đức và Anh.
• Cuộc tấn công vẫn đang tiếp diễn ngay tại thời điểm bài blog này được viết.

Chúng tôi làm gì trong tình huống khẩn cấp này

• Không chặn địa chỉ IP của kẻ tấn công.
• Có dùng Cloudflare, nhưng không bật chế độ "Under Attack".
• CPU máy chủ hầu như ở trạng thái nhàn rỗi trong phần lớn thời gian bị tấn công.
• Nói chung là gần như không làm gì cả.

Tại sao lại như vậy?

• Dịch vụ có thể xử lý hàng tỷ request mỗi tháng mà không gặp vấn đề gì và chi phí cũng không quá cao.
• Có khoảng 8 dịch vụ API và cơ sở dữ liệu, và ngay cả không có cache thì vẫn có thể xử lý hàng tỷ request mỗi tháng.
• Có Cloudflare và băng thông không giới hạn.

Làm sao điều đó có thể xảy ra?

• Thiết kế của ứng dụng TablePlus rất đơn giản, và triết lý này cũng được áp dụng cho các dịch vụ backend được giữ ở mức tối giản.
• Không dùng các dịch vụ bên thứ ba như Vercel hay Netlify. Thay vào đó là dùng web server không có giới hạn.
• Trước đây, monolithic từng là điểm nghẽn do VPS/bộ xử lý yếu, nhưng ngày nay VPS mạnh có thể xử lý hàng tỷ request mỗi tháng trên một instance duy nhất.
• Vì vậy, họ xây dựng dịch vụ monolithic cho từng ứng dụng. Việc triển khai và bảo trì rất dễ dàng.

Hãy nói về monolithic

• Chúng ta có xu hướng làm mọi thứ trở nên phức tạp, nhưng điều đó không thành vấn đề cho đến khi gặp áp lực hoặc giới hạn.
• Vì ghét sự phức tạp nên họ chọn monolithic. Tích hợp mọi thứ ứng dụng cần vào một dịch vụ duy nhất.
• Việc triển khai rất đơn giản. Chỉ cần một tệp cấu hình duy nhất, build và deploy.
• Ít phụ thuộc hơn nên dễ debug và dễ xác định điểm nghẽn.

Một web framework đơn lẻ bằng Go hoặc Rust, nếu được triển khai đúng cách, có thể xử lý hàng tỷ request mỗi tháng

• Chọn framework hiệu năng cao.
• Đánh index cho cơ sở dữ liệu để giảm thời gian truy xuất khi tập dữ liệu lớn dần.
• Tách cơ sở dữ liệu chính khỏi cơ sở dữ liệu log/dữ liệu sử dụng để hiệu năng không ảnh hưởng đến hoạt động kinh doanh cốt lõi.
• Dùng reverse proxy mạnh như Nginx để xử lý và phân phối request tới API cốt lõi.
• Đặt mọi thứ sau Cloudflare và cấu hình phù hợp.
• Dùng CDN có bảo vệ DDoS.
• Không đặt các tệp tải xuống lớn trên VPS nếu không có CDN hoặc cache.

Hãy nói về triển khai

• Tại TablePlus, họ đơn giản hóa quy trình triển khai nhiều nhất có thể.
• Không dùng Docker, Kubernetes hay container, cũng không cần thiết lập môi trường.
• Họ dùng binary. Có thể sao chép binary và chạy như một process trên máy chủ Linux.
• Họ chọn Go và Rust. Đây là các ngôn ngữ hiệu năng cao và có thể tạo tệp binary để triển khai.

Cập nhật

• Vercel đã liên hệ và cho biết họ có các tính năng có thể bảo vệ trang web trong tình huống như thế này.
• Thông qua quản lý chi tiêu, có thể đặt giới hạn chi tiêu, và cũng có chế độ thử thách tấn công tương tự chế độ "Under Attack" của CF.

Ý kiến của GN⁺

• Bài viết này nhấn mạnh tầm quan trọng của hạ tầng mạnh và chiến lược triển khai được đơn giản hóa để duy trì dịch vụ ổn định ngay cả khi bị tấn công DDoS.
• Kiến trúc monolithic cho thấy lợi thế trong việc giảm độ phức tạp, đơn giản hóa triển khai và tối ưu hiệu năng.
• Việc tận dụng hiệu quả dịch vụ đám mây và CDN để tạo khả năng chống chịu trước tấn công DDoS có thể là một ví dụ tốt cho các doanh nghiệp khác.
• Cách tiếp cận này cũng mang lại góc nhìn về việc xây dựng hạ tầng hiệu quả về chi phí, đặc biệt cho các startup giai đoạn đầu hoặc doanh nghiệp vừa và nhỏ.
• Tuy nhiên, cách tiếp cận monolithic không phù hợp với mọi hệ thống hay ứng dụng, vì vậy điều quan trọng là phải chọn kiến trúc phù hợp với từng yêu cầu và bối cảnh.

[GN⁺]

Ý kiến trên Hacker News

• Tóm tắt bình luận thứ nhất:

  • Người bình luận cho rằng việc khoe hiệu năng của website đã bị phóng đại.
  • "1 tỷ request mỗi tháng" thực ra chỉ tương đương vài trăm request mỗi giây, đây là mức rất nhỏ và khó có thể xem là tấn công DDoS.
  • Vì trang web nằm sau CDN (Cloudflare), nên có vẻ họ không làm gì đặc biệt liên quan đến hiệu năng.
  • Việc tệp 200MB được cache và phân phối qua CDN là điều hiển nhiên, và đem điều đó ra khoe cho thấy thiết kế có phần không phù hợp.

• Tóm tắt bình luận thứ hai:

  • 4TB lưu lượng mỗi tháng khó có thể xem là một cuộc tấn công DDoS.
  • 6 triệu request mỗi tháng chỉ tương đương khoảng 2 request mỗi giây, nên ở quy mô này việc vận hành một dịch vụ nguyên khối (monolith service) không thành vấn đề.
  • Giả định rằng phần lớn request sẽ được Cloudflare xử lý bằng cache ở tầng CDN.

• Tóm tắt bình luận thứ ba:

  • Trang web chỉ là một website marketing tĩnh đơn giản, không có diễn đàn thảo luận, và phản hồi được xử lý qua GitHub issue.
  • Việc khoe rằng có thể xử lý hàng triệu lượt tải xuống tệp tĩnh mỗi ngày bằng một cách triển khai đơn giản nghe khá kỳ lạ.
  • Cloudflare đang thực hiện toàn bộ phần giảm thiểu, và trên thực tế lưu lượng có thể quá nhỏ đến mức thậm chí không cần điều đó.

• Tóm tắt bình luận thứ tư:

  • Lượng truy cập tăng thêm được mô tả có vẻ giống "hành vi lạm dụng dịch vụ vô nghĩa" hơn là một cuộc tấn công DDoS thực sự.
  • Có thể bỏ qua kiểu lạm dụng này miễn là nó không gây ra chi phí hoặc vấn đề cạn kiệt tài nguyên.
  • Những câu chuyện về hạ tầng tự động mở rộng nhưng phần lớn không tạo ra công việc hữu ích là điều thường thấy, và tốt nhất là nên tiếp tục theo dõi lưu lượng.
  • Có phàn nàn về logging; nếu kho lưu trữ log rẻ và dồi dào thì đó không phải vấn đề lớn, nhưng tốt hơn là nên tự động phân loại lưu lượng lạm dụng và hạn chế việc xử lý thông thường đối với chúng.

• Tóm tắt bình luận thứ năm:

  • 50 triệu request mỗi tháng phát sinh từ Anh có thể chỉ là mức do một script đơn lẻ chạy ra.
  • Người viết kỳ vọng một máy chủ Go có thể xử lý số request nhiều hơn gấp 250 lần mỗi giây ngay cả khi không tối ưu hóa.
  • Bản thân lời khuyên không tệ, nhưng các con số của họ không phải là bằng chứng cho lời khuyên đó.

• Tóm tắt bình luận thứ sáu:

  • Phân phối binary có thể được ưa chuộng hơn dùng Docker, nhưng có những vấn đề bảo mật liên quan đến host chạy binary đó.
  • Một dịch vụ nguyên khối (monolith service) duy nhất được host trên một VPS duy nhất thì rẻ và ổn, nhưng nếu phần cứng gặp sự cố thì có thể dẫn đến downtime đáng kể.
  • Việc gộp mọi thứ vào một dịch vụ duy nhất có thể làm mất đi khả năng phòng thủ nhiều lớp (defence in depth), điều này có thể cho phép truy cập vào kho dữ liệu nếu xảy ra vấn đề bảo mật.

• Tóm tắt bình luận thứ bảy:

  • "1 tỷ request mỗi tháng" là mức một máy chủ đơn có thể xử lý, và chỉ một script lỗi cũng có thể tạo ra lượng lưu lượng như vậy.

• Tóm tắt bình luận thứ tám:

  • Đặt câu hỏi liệu hàng tỷ request mỗi tháng có thực sự được xem là một cuộc tấn công DDoS lớn hay không.

• Tóm tắt bình luận thứ chín:

  • Xây dựng một dịch vụ nguyên khối (monolith service) cho từng ứng dụng giúp việc triển khai và bảo trì trở nên dễ dàng.
  • Chỉ cần triển khai tệp binary thay vì phải dùng Docker, Kubernetes, dependency hay môi trường runtime.

• Tóm tắt bình luận thứ mười:

  • Khi đọc tiêu đề thì họ đã kỳ vọng nội dung lớn hơn, nhưng việc đứng sau Cloudflare là một yếu tố quan trọng.
  • Tùy vào phân bố lưu lượng, có thể hệ thống vẫn chạy tốt trên VPS ngay cả khi không có Cloudflare.
  • Các cuộc tấn công DDoS layer7 từ Nga có quy mô lớn đến mức ngay cả các nhà cung cấp lớn cũng thất bại vì vấn đề dung lượng.