Cloudflare đã thiết kế hệ thống của họ như thế nào để dễ dàng mở rộng nhanh chóng nhằm đỡ các cuộc tấn công DDoS quy mô lớn?

Trong những tuần vừa qua, một số dịch vụ legacy DNS và DDoS-mitigation đã gặp nhiều sự cố quy mô lớn trước những đợt tấn công mạng mạnh mẽ. Nhiều khách hàng của Cloudflare đã hỏi (một cách ân cần) rằng chúng tôi đã làm gì để đối phó những đợt tấn công như thế này.

Tuy bất cứ dịch vụ nào cũng có giới hạn của nó, Cloudflare hiển nhiên cũng không phải là ngoại lệ, nhưng chúng tôi vẫn có kiến trúc đủ mạnh mẽ để chống chọi các cuộc tấn công gần đây và sẽ tiếp tục mở rộng để chặn đứng những cuộc tấn công diện rộng không tránh thể tránh khỏi trong thời gian sắp tới. Chúng tôi, vẫn đang không ngừng nghỉ, khắc phục mọi botnet bị ảnh hưởng. Dựa trên những dữ liệu đã được công bố, cùng những nguồn tin riêng được gửi đến, chúng tôi đã ngăn chặn thành công đợt tấn công với quy mô và kiểu mẫu tương tự mà không gây hại đến khách hàng.

Có lẽ, đây đã là thời điểm thích hợp để phân tích điểm khác biệt giữa kiến trúc của Cloudflare và những dịch vụ legacy DNS khác DDoS-mitigation, và những khác biệt này đã giúp chúng tôi bảo vệ khách hàng trước muôn vàn nguy cơ như thế nào.

Analogy: Database mở rộng như thế nào

Trước khi nhìn vào kiến trúc của chúng tôi, hãy dành ít phút cho một vấn đề công nghệ tương tự khác, dễ hiểu hơn, là: scaling databases (cơ sở dữ liệu mở rộng). Từ những năm giữa 1980, khi  relational databases (cơ sở dữ liệu quan hệ) bắt đầu khởi sắc, đến tận những năm đầu 2000, các công ty đã từng quan niệm đánh đồng việc mở rộng với việc mua thêm phần cứng mới. Cuộc chơi luôn là: mua server database bự nhất có thể mua được, bắt đầu bơm dữ liệu vào, và hy vọng mình sẽ mua được server bự hơn nữa trước khi bạn hết bộ nhớ. Bởi vậy, các công ty phần cứng đáp trả bằng những thiết bị phần cứng ngày càng đắt đỏ, tối ưu cho database.

Meet the IBM z13 mainframe (source: IBM)

Đến một thời điểm nhất định, tất cả thông tin mà một số tổ chức muốn lưu trữ cũng không có cách nào gói gọn trong một chiếc hộp nhỏ bé nữa. Google là một ví dụ rất điển hình. Trước đó công ty này chỉ là một startup, họ không có tài nguyên để mua những chiếc server database đồ sộ đắt tiền. Mà dù có tiền đi nữa, những server lớn nhất cũng chả có cách lào lưu trữ mọi thông tin (nói trắng ra là cả cái internet luôn) mà họ muốn đưa vào.

Vì vậy, thay vì đi theo con đường của tiền nhân, Google đã viết ra một phần mềm mới lạ, cho phép nhiều server rẻ tiền, thông thường có thể làm việc cùng nhau giống như một database lớn hoàn chỉnh vậy. Dần dần, khi Google phát triển thêm nhiều dịch vụ, phần mềm ngày càng thể hiện sự hiệu quả, chuyển tải khắp tất cả máy tính trong mạng lưới của Google để tận dụng tốt đa mạng, khả năng sử lý và khả năng lưu trữ. Và, nếu Goolge cần mở rộng, họ chỉ việc thêm server thông thường – là đã có thể mở rộng tài nguyên đáp ứng được với nhu cầu rồi.

Legacy DNS và DDoS Mitigation

Giờ ta sẽ so sánh cách làm này với cách bảo mật của các dịch vụ legacy DNS và DDoS mitigation. Thông thường, cách chặn tấn công thường là mua và build một cái hộp bự và dùng nó để lọc các traffic đến. Nếu bạn tìm hiểu thêm và các chi tiết kỹ thuật của đa số nhà cung cấp dịch vụ legacy DDoS mitigation, bạn sẽ thấy phần cứng từ các công ty như Cisco, Arbor Networks, và Radware dính chùm với nhau thành “scrubbing centers.”

Hệ thống xử lý thải CC BY-SA 3.0 image by Annabel

Cũng giống như thế giới database cũ kỹ, có nhiều thủ thuật hay ho để buộc những chiếc hộp sắt khổng lồ này làm việc với nhau (đại loại vậy), nhưng lại khá là thiếu tinh tế. Thông thường, giới hạn vật lý của số packet mà một hộp duy nhất có thể hấp thu sẽ trở thành giới hạn hiệu lực lên tổng số lượng mà một nhà cung cấp dịch vụ có thể ngăn chặn. Đồng thời, trong các cuộc tấn công DDoS lớn, đa số traffic của đợt tấn công sẽ không bao giờ chạm được đến scrubbing center, vì với chỉ một vài vị trí, upstream ISPs sẽ trở thành bottle neck (điểm nghẽn).

Hơn nữa, về mặt chi phí, việc triển khai scrubbing hardware tỏ ra thiếu hiệu quả. Nếu bạn là DNS provider, bạn thực sự bị tấn công mấy lần một năm? Đầu tư hàng đống tiền cho mitigation hardware đắt đỏ ở mỗi trung tâm dữ liệu liệu có đáng? Ngay cả khi là nhà cung cấp legacy DDoS, thông thường dịch vụ của bạn chỉ được dùng đến khi khách hàng bị tấn công, vậy nên việc nâng cấp sức mạnh cao hơn nhiều lần tấn công lớn nhất trước đó tỏ ra vô cùng vô lý. Đây hiển nhiên là suy nghĩ của nhiều người, nhưng kết luận này đang tỏ ra “chết người” với mô hình truyền thống.

Tương lai không được gói trong hộp

Từ đầu đến nay với Cloudflare, chúng tôi xem cơ sở hạ tầng của mình giống như Google với database của họ vậy. Những ngày đầu, nhiều nhà cung cấp phần chứng chống DDos truyền thống từng cố thuyết phục chúng tôi sử dụng công nghệ của họ. Bản thân chúng tôi cũng đã từng “trót” muốn dựng một siêu cự đại hộp để dọn traffic. Cách làm này có vẻ như là một thách thức kỹ thuật đầy quyến rũ, nhưng chúng tôi nhận ra rằng mô hình này sẽ chẳng bao giờ mở rộng được.

Thay vào đó, chúng tôi bắt đầu với một kiến trúc rất đơn giản. Những hệ thống đầu tiên của Cloudflare chỉ gồm ba thành phần: router (bộ định tuyến), switch (bộ chuyển mạch), và server (máy chủ). Đến nay chúng tôi thậm chí còn đơn giản hóa mô hình này hơn nữa, thi thoảng loại bỏ router hoàn toàn và dùng những bộ chuyển mạch đủ sức xử lý routing table (bảng định tuyến) để dịnh tuyết các packet khắp các khu vực địa lý mà trung tâm dữ liệu đảm nhiệm.

Không dùng cả cân bằng tải hay phần cứng chuyên dụng chống DDos (có thể biến thành điểm nghẽn trong một cuộc công kích), chúng tôi viết phần mềm dùng BGP (giao thức định tuyến nền tảng của internet) để phân bố tải theo địa lý và đến mỗi trung tâm dữ liệu trong toàn hệ thống của chúng tôi. Nguyên lý chủ đạo cho hô hình này: mỗi server ở mỗi cụm có khả năng đáp trả đến mỗi kiểu request. Phần mềm của chúng tôi liên tục phân bố tải dựa trên nhu cầu của khách hàng cụ thể tại thời điểm cụ thể. Nói cách khác, chúng tôi tự động phân tán tải khắp hàng chục nghìn server trong những cuộc tân công quy mô lớn.

Graphene: Cấu trúc đơn giản bền gấp 100 lần thép tốt nhất (credit: Wikipedia)

Như vậy, chúng tôi có thể tiếp tục đầu tư vào mạng lưới của mình ít tốn kém hơn. Nếu Frankfurt cần sức chứa tăng 10%, chúng tôi có thể phân phối qua đó thêm 10% server, chứ không phải đau đầu suy nghĩ xem mình có nên mua thêm hộp Colossus Mega Scrubber™ hay không.

Vì mỗi lõi trong mỗi server ở mỗi trung tâm dữ liệu đều có thể giúp gảm chặn công kích, như vậy với mỗi trung tâm dữ liệu mới nhất đưa vào hoạt động, chúng tôi lại càng có khả năng bảo vệ gần nguồn tốt hơn, nhanh hơn, linh hoạt hơn và mạnh mẽ hơn. Đến cùng, giải pháp tốt nhất cho bonet siêu phân phối chính là mạng lưới siêu phân phối (massively distributed network). Đây chính là nguyên lý hoạt động của internet từ cổ chí kim, sức mạnh phân bố, chứ không cách nào tập trung nhỏ lẻ trong từng vị trí dọn lọc được.

Làm thế nào mà dịch vụ DDoS Mitigation của chúng tôi rẻ đến vậy

Sự hiệu quả của nguồn tài nguyên phải được thể hiện ở chi phí vận hành chứ không nên dừng lại ở chi phí vốn. Vì dùng cùng thiết bị và mạng để cung cấp tất cả chức năng của Cloudflare, nên chúng tôi hiếm khi phải tốn thêm chi phí băng thông khi phải chặn đứng một cuộc tấn công nào đó. Các bạn chịu khó đọc phần giải thích dưới đây thêm chút nữa nhé, vì để hiểu rõ ý này, bạn trước hết phải biết một chút về cách mua băng thông của chúng tôi đã.

Chúng tôi trả tiền băng thông từ số lượng vượt quá số lượng cộng dồn hàng tháng mà nhà cung cấp cho phép (tại phần trăm thứ 95 của hiệu số giữa ingress so với egress). Ingress là thuật ngữ mạng chỉ traffic được gửi đến network của chúng tôi. Egress là traffic được gửi đi từ network.

Bên cạnh dịch vụ giải cứu DDos, Cloudflare còn cung cấp nhiều giải pháp khác trong đó có caching. Bản chất của cache là bạn luôn nên có nhiều traffic chạy ra cache hơn là chạy vào. Trong trường hợp của chúng ta, trong các tình huống thông thường, chúng ta bắt gặp egress (traffic ra) nhiều hơn ingress (traffic vào).

Những đợt tấn công DDos đẩy ingress tăng cao nhưng lại không ảnh hưởng đến egress. Tuy nhiên, ngay cả trong một cuộc công kích siêu lớn, ingress vượt egress rất hiểm xảy ra. Vì chúng ta chỉ trả theo hiệu số ingress so với egress, và vì egress luôn cao hơn ingress nhiều, nên ta sẽ có một lượng băng thông không phí khổng lồ để xử lý tấn công.

Khi dịch vụ của chúng tôi càng được ưa chuộng, năng lực ngăn chặn tấn công của chúng tôi cũng sẽ tăng theo đó. Nhiều người quan ngại làm sao chúng tôi lại có thể thu một mức phí cố định với mọi quy mô công kích như vậy. Và, tuy nhiều legacy provider từng tuyên bố rằng dịch vụ pro bono DDoS mitigation của họ sẽ tốn họ đến hàng triệu đô, chúng tôi vẫn có thể bảo vệ miễn phí các trang quan trọng (trên trường chính trị lẫn nghệ thuật) trước hàng tá đợt tấn công siêu lớn mà vẫn trang trải được nhờ vào Project Galileo .

Chiến thắng cuộc đua vũ trang

Cloudflare là nhà cung cấp DNS duy nhất, ngay từ ban đầu, đã được thiết kế để ngăn chặn các cuộc tấn công DDos quy mô lớn. Cũng giống với bản chất phân tán của DDos, hệ thống cứu trợ DDos của Cloudflare cũng được phân bố rộng khắp mạng lưới toàn cầu của mình.

Không còn nghi ngờ gì nữa, chúng ta đang trong một cuộc chiến vũ trang với những kẻ tấn công. Tuy nhiên, chúng ta đang ở chiếu trên của trận chiến, cả về mặt kỹ thuật lẫn kinh tế. Đối mặt với mỗi nhà cung cấp legacy, những kẻ tấn công vẫn có lợi thế: chi phí của nhà cung cấp rất cao vì họ phải mua thiết bị và băng thông đắt đỏ, trong khi những kẻ tấn công tốn ít chi phí hơn vì họ dùng các thiết bị bị hack. Bởi lẽ đó, con át chủ bài của chúng tôi nằm ở phần mềm kỳ diệu này, giúp chuyển tải khắp mạng lưới phần cứng phân phối giá rẻ khổng lồ. Khi có thể giảm thiểu chi phí, chúng tôi liền có thể tiếp tục đầu tư mở rộng để đón đầu các cuộc tấn công trong tương lai.

Hôm nay, chúng tôi tin rằng Cloudflare đã có thừa sức mạnh để ngăn chặn các vụ tấn công (công khai) của tất cả đối thủ cộng lại. Và chúng tôi sẽ tiếp tục mở rộng, với mỗi trung tâm mới sau mỗi tuần. Thông tin tốt nhất với người dùng là chúng tôi đã, đang và sẽ thiết kế Cloudflare theo hướng tiếp kiệm và vẫn giữ vững sức mạnh trước những kẻ tấn công. Luôn có hạn chế cho mọi dịch vụ, chúng tôi vẫn phải luôn đề cao cảnh giác trước mọi nguy cơ. Nhưng chúng tôi tin rằng, đây là hướng đi vô cùng đúng đắn, với khả năng tối đa có thể ngăn chặn mọi sự lăm le chờ chực của những kẽ phá hoại khó nhằn.

Techtalk via Cloudflare