- Các dịch vụ web công khai của Canonical đã bị gián đoạn khoảng 20 giờ kể từ 16:33 UTC ngày 30 tháng 4 năm 2026, và các endpoint kho lưu trữ Ubuntu cũng gặp sự cố muộn hơn
- Nhóm thân Iran nhận trách nhiệm về cuộc tấn công cho biết họ đã sử dụng dịch vụ DDoS trả phí Beamed, dịch vụ này quảng bá khả năng vượt qua Cloudflare và xoay vòng IP dân dụng
- Hạ tầng đăng ký và định tuyến liên quan đến tên miền Beamed dẫn tới các dấu vết Cloudflare AS13335, Immaterialism, AS39287 và Materialism s.r.l.
- Việc tái phân bổ AS39287 và gia hạn chứng chỉ apex của Canonical cho archive.ubuntu.com và security.ubuntu.com đã diễn ra trong cùng một khung 24 giờ ngày 27 tháng 2 năm 2026
- Trong lúc bị tấn công, Canonical chỉ chuyển security.ubuntu.com và archive.ubuntu.com sang Cloudflare, tạo nên cấu trúc mà theo hồ sơ công khai, thứ được chuyển đi không phải tiền chuộc mà là gói thuê bao trả phí
Sự cố của Canonical và việc chuyển sang Cloudflare
- Vào 16:33:37 UTC ngày 30 tháng 4 năm 2026, hệ thống giám sát của Canonical đánh dấu blog.ubuntu.com là Service Down, và trong khoảng 10 phút, các dịch vụ web công khai như ubuntu.com, API tư vấn bảo mật, cổng nhà phát triển, trang doanh nghiệp và nền tảng đào tạo cũng đồng loạt ngừng hoạt động
- Sự cố kéo dài khoảng 20 giờ, được ghi nhận là Service Restored vào 12:44 UTC ngày 1 tháng 5 năm 2026
- Nhóm nhận trách nhiệm vụ tấn công tự giới thiệu là Islamic Cyber Resistance in Iraq hoặc 313 Team, một nhóm có xu hướng thân Iran, và cho biết họ đã sử dụng dịch vụ trả phí
- Công cụ tấn công được nêu tên là Beamed, một sản phẩm tấn công từ chối dịch vụ thương mại được bán trên nhiều TLD; beamed.su dùng làm trang marketing và blog, còn beamed.st là cổng đăng nhập khách hàng
- Bài blog tháng 4 năm 2026 của Beamed quảng bá khả năng “vượt qua Cloudflare”, nêu ra ba kỹ thuật bao gồm xoay vòng IP dân dụng và “endpoint hunting” thủ công để tìm máy chủ gốc
- Một tuần sau cuộc tấn công, beamed.su và beamed.st vẫn hoạt động trực tuyến, và cả hai đều phân giải tới các địa chỉ Cloudflare AS13335
- Hai endpoint kho lưu trữ của Canonical là security.ubuntu.com và archive.ubuntu.com sau đó cũng dùng các địa chỉ Cloudflare AS13335
Beamed và hạ tầng đăng ký, định tuyến
- Tên miền hướng tới người dùng của Beamed được đăng ký thông qua một nhà đăng ký có tên Immaterialism Limited; nhà đăng ký này bán dịch vụ đăng ký tên miền theo mức phí cố định và API JSON
- Immateriali.sm được proxy qua nameserver của Cloudflare là tani.ns.cloudflare.com và trey.ns.cloudflare.com
- Immaterialism Limited được đăng ký tại Companies House của Anh với mã công ty 15738452, thành lập ngày 24 tháng 5 năm 2024
- Khi thành lập, giám đốc là Nicole Priscila Fernandez Chaves ở Costa Rica, và công ty sử dụng địa chỉ hộp thư hàng loạt tại Great Portland Street, London
- Ngày 11 tháng 4 năm 2025, Fernandez Chaves rời vị trí giám đốc nhưng vẫn giữ hơn 75% lợi ích kinh tế, và Naomi Susan Colvin, cư dân Anh, được bổ nhiệm làm giám đốc kế nhiệm tại cùng địa chỉ đó
Việc tái phân bổ AS39287 ngày 27 tháng 2 năm 2026
- Ngày 26 tháng 2 năm 2026, Immaterialism Limited đã nộp hai thay đổi trong cùng một ngày lên Companies House
- Chuyển văn phòng đăng ký từ 85 Great Portland Street sang 167-169 Great Portland Street
- Thay đổi chi tiết person with significant control của Fernandez Chaves
- Ngày hôm sau, 27 tháng 2 năm 2026, hạ tầng định tuyến quảng bá không gian IP của Beamed và các dịch vụ liên quan đã chuyển thẩm quyền pháp lý
- Hệ thống tự trị quảng bá không gian địa chỉ của Materialism là AS39287, và RIPE đã cấp số AS này vào ngày 24 tháng 1 năm 2006
- Danh tính định tuyến của AS39287 vẫn được giữ nguyên, nhưng hồ sơ nhà vận hành và quốc gia đã thay đổi hai lần
-
Giai đoạn Privactually Ltd và FLATTR-AS
- Từ khoảng năm 2017 đến khoảng năm 2020, AS39287 thuộc sở hữu của công ty Cyprus Privactually Ltd và được vận hành dưới tên FLATTR-AS
- Flattr được liên kết với dự án micropayment của Peter Sunde Kolmosoppi, một trong các đồng sáng lập The Pirate Bay
- Dưới hồ sơ đăng ký đó, địa chỉ liên hệ abuse của các prefix là abuse@shelter.st
-
Giai đoạn ab stract ltd
- Từ năm 2020 đến năm 2026, cùng số AS này được tái phân bổ cho công ty Phần Lan ab stract ltd tại Urho Kekkosen katu 4-6E, Helsinki
- Đối tượng maintainer trong hồ sơ RIPE là BKP-MNT, và cá nhân xuất hiện trong hồ sơ là Peter Kolmisoppi, một nhà đồng sáng lập khác của The Pirate Bay
- Nameserver có thẩm quyền của tên miền vận hành abstract.fi là ba nameserver Njalla: njalla.fo, njalla.no và njalla.in
- Njalla là dịch vụ proxy tên miền privacy-as-a-service do Peter Sunde tạo ra, vận hành thông qua 1337 Services LLC tại Saint Kitts and Nevis
-
Tái phân bổ sang Materialism s.r.l.
- Vào 12:11:48 UTC ngày 27 tháng 2 năm 2026, RIPE ghi nhận lần tái phân bổ thứ ba, và AS39287 trở thành tài sản của Materialism s.r.l. tại Bulevardul Metalurgiei, Bucharest, Romania
- Việc tái phân bổ bao gồm 45.158.116.0/22, 2001:67c:2354::/48, 2a02:6f8::/32; prefix IPv6 cuối cùng đã được cấp lần đầu từ tháng 8 năm 2008 dưới cơ chế trước đó
- Trong suốt ba giai đoạn chuyển đổi, cấu hình peering vẫn được giữ nguyên, và AS39287 tiếp tục import/export với cùng cấu hình tới AS42708(Telia), AS37560(GTT), AS12552(GlobalConnect), AS34244(Voxility) và AS54990
- Các tuyến đường vẫn đi ra cùng các mạng upstream, và điều thay đổi trong hồ sơ công khai chỉ là tên nhà vận hành hiển thị
- Danh sách nhà đăng ký tên miền được IANA công nhận cho thấy 1337 Services LLC, pháp nhân giao dịch đứng sau Njalla, nằm trong cơ sở khách hàng của Immateriali.sm
Việc xoay vòng chứng chỉ Canonical diễn ra cùng ngày
- Hồ sơ certificate transparency của các endpoint kho lưu trữ Canonical xuất hiện nhiều mục trong cùng khung 24 giờ với lần tái phân bổ định tuyến
- Vào 06:14:03 UTC ngày 27 tháng 2 năm 2026, Let’s Encrypt cấp chứng chỉ apex mới cho archive.ubuntu.com
- Cùng ngày, lúc 19:13:35 UTC, Let’s Encrypt cấp chứng chỉ apex mới cho security.ubuntu.com
- Trong hồ sơ certificate transparency năm 2026 của security.ubuntu.com, trước mục này chỉ có chứng chỉ mirror khu vực, không thấy chứng chỉ apex nào sớm hơn trong log hiển thị
- Cùng ngày, lúc 22:14:03 UTC, chứng chỉ mới cho clouds.archive.ubuntu.com được cấp
- Trong 9 ngày tiếp theo, cùng mô hình đó lặp lại với azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com và wildcard-ec2.archive.ubuntu.com
- Mỗi chứng chỉ mới đều được cấp cho hostname apex, không phải mirror khu vực
- Chứng chỉ gốc hợp lệ cho hostname apex được xem như điều kiện tiên quyết để đặt hostname đó sau mạng phân phối nội dung
- Sự trùng hợp về thời điểm giữa lần tái phân bổ định tuyến ngày 27 tháng 2 năm 2026 và việc xoay vòng chứng chỉ của Canonical không được giải thích chỉ bằng hồ sơ công khai
Dòng thời gian vụ tấn công
- Dòng thời gian dựa trên nhật ký sự cố theo từng phút từng xuất hiện trên trang status.canonical.com của Canonical, được lưu lại thành ảnh chụp trong Ubuntu Discourse thread 81470 vào khoảng 22:52 UTC ngày 30 tháng 4
-
10 phút đầu: sự cố diện rộng trên web công khai
- 16:33:37: blog.ubuntu.com lần đầu bị đánh dấu Down và được ghi là Incident Start Time
- 16:34:10: canonical.com Down
- 16:34:45: academy.canonical.com Down
- 16:35:15: developer.ubuntu.com Down
- 16:35:22: maas.io Down
- 16:36:09: jaas.ai Down, Ubuntu Security API(CVEs) Down
- 16:37:13: Ubuntu Security API(Notices) Down
- 16:41:57: assets.ubuntu.com Down
- 16:43:25: ubuntu.com Down
- Feed tư vấn bảo mật ngừng hoạt động trong vòng 3 phút kể từ khi bắt đầu, và apex marketing ngừng hoạt động trong vòng 10 phút
- Ở thời điểm này, các host chưa bị tấn công là security.ubuntu.com và archive.ubuntu.com; đây là các endpoint kho lưu trữ có thể khiến mọi cài đặt Ubuntu đều thất bại khi chạy
apt update
-
3 giờ sau: tấn công các endpoint kho lưu trữ
- 19:34:38: security.ubuntu.com lần đầu bị đánh dấu Down
- 19:40:01: archive.ubuntu.com Down
- Các endpoint kho lưu trữ gặp sự cố khoảng 3 giờ sau khi cuộc tấn công bắt đầu
- Từ 19:40 UTC và trong 70 phút tiếp theo, hai endpoint kho lưu trữ liên tục chuyển đổi giữa Down và Operational trên bảng trạng thái
- Nhật ký trạng thái ghi nhận 5 lần chuyển Down/Operational đối với security.ubuntu.com và 4 lần đối với archive.ubuntu.com trong giai đoạn đó
- Mô hình này phù hợp với việc đã thử các biện pháp giảm thiểu ở phía origin như giới hạn tốc độ, lọc theo khu vực hoặc scrubbing traffic, nhưng thất bại trước tải liên tục ở quy mô 3.5 Tbps được công bố
-
Ổn định sau 20:50 UTC
- 20:50:29: archive.ubuntu.com Operational
- 20:51:13: security.ubuntu.com Operational
- Sau khoảng cách 44 giây này, trong ảnh chụp trạng thái kéo dài tới 22:52 UTC, hai host không còn xuất hiện là Down lần nào nữa
- Hiện tượng flapping dừng lại, và hai endpoint cùng ổn định trong khoảng chưa tới 1 phút ở mốc 4 giờ 17 phút sau khi cuộc tấn công bắt đầu
- Tại thời điểm bài viết, security.ubuntu.com và archive.ubuntu.com phân giải tới 104.20.28.246 và 172.66.152.176; đây là các địa chỉ do Cloudflare vận hành trong AS13335
- Các host bị ảnh hưởng khác như ubuntu.com, canonical.com, launchpad.net, snapcraft.io và login.ubuntu.com vẫn phân giải tới dải AS41231 của Canonical là 185.125.189.x và 185.125.190.x
- Nameserver có thẩm quyền của ubuntu.com vẫn là ns1.canonical.com, ns2.canonical.com và ns3.canonical.com
Việc chuyển sang Cloudflare có chọn lọc
- Canonical chỉ chuyển hai bản ghi A security.ubuntu.com và archive.ubuntu.com, là các mục tiêu mà kẻ tấn công nhắm tới để làm tê liệt kho lưu trữ, sang Cloudflare
- Các dịch vụ còn lại vẫn ở trên hạ tầng riêng của Canonical và chịu đựng cuộc tấn công dưới các biện pháp giảm thiểu hiện có
- Các host không phải kho lưu trữ tiếp tục flapping cho tới cuối ảnh chụp, rồi phục hồi nhờ kết hợp giữa lọc upstream, giảm thiểu tấn công hoặc cuộc tấn công chấm dứt
- Lần xác nhận công khai đầu tiên của Canonical được đăng lúc 07:13 UTC ngày 1 tháng 5, tức 10 giờ sau khi các endpoint kho lưu trữ đã ổn định sau Cloudflare
- Việc phục hồi hoàn toàn mọi thành phần được xác nhận lúc 12:44 UTC ngày 1 tháng 5, tức khoảng 20 giờ sau khi cuộc tấn công bắt đầu
Cấu trúc xoay quanh việc có phải là “tống tiền” hay không
- Trên con đường có thể kiểm chứng công khai, không có khoản tiền chuộc nào được chuyển đi
- Cũng không có dòng tiền điện tử ở quy mô như vậy xuất hiện trong hồ sơ công khai
- Không có thư đòi tiền chuộc nào được công bố, và nếu có đàm phán thì rất có thể đã diễn ra kín
- Điều được chuyển đi trong hồ sơ công khai là gói thuê bao trả phí
- Hai endpoint giá trị nhất của Canonical, tức các endpoint kho lưu trữ có thể gây ra lỗi cập nhật bảo mật tự động trên toàn cầu, đã chuyển sang quan hệ dịch vụ với Cloudflare
- Đồng thời, các khách hàng hiện tại khác của Cloudflare còn bao gồm nhà vận hành booter đang tấn công Canonical
- Vì Beamed vẫn tiếp tục có thể được thuê và thời gian gián đoạn của hạ tầng Canonical hoạt động như một hạn chót, cấu trúc này có thể được diễn giải như một giao dịch hoàn tất mà không cần yêu cầu công khai riêng biệt
- Bên bảo vệ thu lợi từ cả hai phía, trong khi ở từng thời điểm vẫn giữ được vẻ trung lập về nội dung và nằm trong câu chữ của điều khoản dịch vụ
So sánh với độc quyền mạng thông tin đua ngựa
- Trong thập niên 1930, General News Bureau của Moses Annenberg bán rất nhanh kết quả trường đua cho các bookmaker trên khắp nước Mỹ
- Sự so sánh được đưa ra là bookmaker đăng ký thuê bao thì sống sót, còn bookmaker không đăng ký thì mất khả năng đặt tỷ lệ cược vì các đối thủ có thuê bao
- Lợi nhuận của Annenberg phụ thuộc vào độc quyền trong việc xác minh kết quả đua ngựa, và độc quyền đó khiến các bookmaker không chính thức phải phụ thuộc vào đường dây của ông để vận hành
- Chính phủ liên bang đã phá vỡ độc quyền này bằng vụ truy tố thuế năm 1939, và các wire service kế tiếp bị truy quét cho tới thập niên 1940
- Bài báo năm 1942 liên quan đến Mayor LaGuardia cho biết 9 người bị bắt trong một cuộc truy quét “wire service trị giá 1 triệu USD mỗi năm” phục vụ các nhà cái cá cược đua ngựa và poolroom bookmaker ở New York, New Jersey, Westchester và Nassau County
- Từ đó xuất hiện chỉ trích rằng thị trường bảo vệ DDoS ngày nay đang ở vị trí tương tự trong quan hệ với thị trường booter
- Doanh thu của Cloudflare phụ thuộc vào vị trí xác minh xem dịch vụ có thể truy cập được trên Internet công cộng hay không, và khi cùng công ty đó cũng là nhà cung cấp hosting cho booter, vai trò đe dọa và bảo vệ hợp lại thành một dòng doanh thu duy nhất
Dấu vết còn lại trong hồ sơ công khai
- Dấu vết của sự kiện này được để lại rải rác trong nhiều sổ đăng ký và hồ sơ công ty
- Companies House lưu hồ sơ doanh nghiệp, cơ sở dữ liệu RIPE lưu việc tái phân bổ định tuyến, log certificate transparency lưu ngày xoay vòng chứng chỉ apex, và trang trạng thái của Canonical lưu thời điểm các bản ghi thay đổi
- Ngày 27 tháng 2 năm 2026, ba sự chuẩn bị đã hoàn tất trong cùng một khung lịch
- Materialism s.r.l. tiếp quản AS39287 và prefix IPv6 cũ đi kèm
- Immaterialism Limited nộp hồ sơ lên Companies House
- Phía Canonical gia hạn chứng chỉ gốc cho hai hostname apex sau này được chuyển ra sau mạng phân phối nội dung
- Khoảng cách 4 giờ từ lúc cuộc tấn công bắt đầu đến khi các địa chỉ Cloudflare xuất hiện trên hostname kho lưu trữ của Canonical có thể được diễn giải là quãng thời gian quyết định mua dịch vụ được dịch chuyển
- Vào 20:50:29 UTC ngày 30 tháng 4 năm 2026, quan hệ khách hàng mới trở nên hiển hiện công khai
1 bình luận
Ý kiến trên Hacker News
Theo cách tôi hiểu thì cách nói thuê năng lực tấn công từ Cloudflare là không chính xác
Đúng là nhóm đó đã lưu trữ trang web sau Cloudflare, nhưng tôi chưa thấy chỗ nào khẳng định hạ tầng Cloudflare được dùng cho chính cuộc tấn công
Có vẻ toàn bộ bài viết đang trộn lẫn giữa việc lưu trữ trang hướng dẫn do kẻ tấn công vận hành với việc lưu trữ chính cuộc tấn công
Dù là website hay hạ tầng điều khiển thì tất cả đều là mục tiêu tấn công
Phòng vệ DDoS do các công ty như Akamai cung cấp, giá thì phải liên hệ hỏi, chỉ doanh nghiệp lớn mới dùng nổi và tuyệt đối không có chuyện đăng ký ẩn danh
Cloudflare đã thay đổi ngành này khi cung cấp miễn phí bảo vệ DDoS cho mọi người, kể cả các dịch vụ DDoS-for-hire, và khi họ không còn có thể đẩy nhau ngoại tuyến nữa thì ngành công nghiệp DDoS mới thực sự có thể phát triển mạnh
Có vẻ cũng không phải là lưu lượng được proxy, vì ít nhất không có header
CF-Connecting-IpTôi không biết nó có được dùng trong cuộc tấn công này không, nhưng nó có được dùng trong một số cuộc tấn công
Dù vậy Cloudflare vẫn ít gây phiền hơn rất nhiều so với gần như mọi nhà cung cấp hạ tầng khác
Tôi cũng không chắc lập luận đó có đứng vững không
Có rất nhiều máy chủ chỉ huy-điều khiển được lưu trữ trên AWS và cũng có rất nhiều nạn nhân trên AWS, nhưng khó mà nói AWS phải chịu trách nhiệm hay là đang đe dọa ai, và nhìn chung tôi nghĩ câu trả lời là không
Ai cũng có thể chọn ra vài trang mà họ nghĩ là không nên được dùng dịch vụ lưu trữ của Cloudflare
Vấn đề là danh sách đó của mỗi người lại khác nhau
Cloudflare nên lưu trữ mọi thứ cho đến khi nhận được lệnh hợp pháp
Nếu họ bắt đầu tự phán xét nội dung trang web có “phù hợp” hay không theo một tiêu chuẩn mơ hồ nào đó, chắc chắn người ta sẽ nổi giận một cách hoàn toàn chính đáng
Tuyên bố rằng ai đó đang thuê năng lực tấn công từ Cloudflare cần phải có căn cứ, và theo những gì tôi biết thì kẻ tấn công không dùng hạ tầng Cloudflare cho cuộc tấn công thực tế
Không khí chung của bài này khác quá nhiều so với các bài liên quan đến Google nên tôi thấy khá bối rối
Tôi không chắc Cloudflare có phải tác nhân xấu hay không, nhưng tôi nghĩ mọi người nên hành xử như thể họ là vậy
Nếu dịch vụ được quảng bá là tấn công Cloudflare một cách công khai, thì theo các điều khoản hợp lý chắc chắn đó phải là vi phạm
Điều đó cũng có trong điều khoản thực tế của Cloudflare
https://www.cloudflare.com/en-ca/website-terms/
Trong “7. PROHIBITED USES”, có nói rằng không được sử dụng website hay dịch vụ trực tuyến theo cách có thể làm hư hại, vô hiệu hóa, quá tải, cản trở hoặc làm suy yếu máy chủ hay API của Cloudflare, hoặc các mạng được kết nối; không được truyền virus, worm, trojan hay các thành phần mang tính phá hoại khác; và không được cố truy cập trái phép thông qua hack hay đào tiền mã hóa
Ngoài ra, Cloudflare cũng giữ quyền chặn nội dung trên Distributed Web Gateway nếu theo toàn quyền quyết định của họ, nội dung đó là bất hợp pháp, có hại hoặc vi phạm điều khoản, bao gồm phát tán phần mềm độc hại, cổ xúy phishing và các hình thức lạm dụng kỹ thuật khác
Dù có gỡ trang hướng dẫn của kẻ tấn công xuống thì họ cũng có thể chuyển sang GitHub Pages hay vô số dịch vụ lưu trữ trang tĩnh miễn phí khác
Theo tôi thấy thì không có bằng chứng nào cả cho việc Cloudflare đã tạo điều kiện cho chính cuộc tấn công
Họ không quyết định đứng hoàn toàn ngoài cuộc
Tuyên bố không can thiệp nên được hiểu là một dạng chấp thuận ngầm
Vì chúng ta biết họ thực sự vẫn đuổi những người dùng mà họ không đủ ưa
Những bài như thế này dường như dựa trên niềm tin kỳ lạ rằng Cloudflare không phản hồi báo cáo bảo mật hay lệnh pháp lý
Theo kinh nghiệm của tôi, Cloudflare phản hồi phù hợp và tương đối nhanh so với mặt bằng ngành
Họ có thể chủ động hơn hoặc tăng thêm ma sát trong quy trình đăng ký, nhưng lý do họ không muốn đóng vai cảnh sát Internet là điều tôi thấy chấp nhận được
Tôi không nghĩ để lưu trữ nội dung trên Internet mà phải bị yêu cầu cả thẻ tín dụng, số điện thoại và bản sao giấy tờ tùy thân
Nếu không, các đảo khác sẽ cắt kết nối với họ
Thực thi pháp luật là biện pháp cuối cùng, vì tòa án không vận hành theo tốc độ của Internet, và vì tính chất xuyên biên giới của Internet nên chẳng ai muốn có quy định chính phủ áp từ trên xuống
Cloudflare đã dùng vốn đầu tư mạo hiểm để cung cấp miễn phí những thứ vốn rất đắt đỏ và mua thị phần
Nếu khiến tất cả cửa hàng tạp hóa chuyển sang hòn đảo của mình, bạn có thể vận hành sào huyệt tội phạm mà không phải lo bị những người khác tẩy chay
Cứ hỏi những người chống botnet, phần mềm độc hại và lừa đảo trực tuyến thì biết
Một khi chạm đến ngõ cụt Cloudflare thì đành phải bỏ cuộc
Cơ quan thực thi pháp luật sẽ không nhận một vụ chỉ có 7.000 máy tính nhiễm, còn Cloudflare cũng sẽ không tự điều tra rồi xử lý
Trên thực tế tôi cũng không làm vậy
Tôi đã cung cấp đủ bằng chứng để họ có thể bắt đầu điều tra nội bộ hoặc liên hệ khách hàng lạm dụng, nhưng họ đã không làm
Với một stresser thì thứ nhìn thấy từ bên ngoài chỉ là bảng đăng nhập
Những trang như vậy cũng đâu có công khai quảng cáo chính xác chúng đang làm gì
Cloudflare tự định vị mình là hạ tầng
Tức là họ cho rằng mình không chịu trách nhiệm với nội dung được họ chuyên chở
Trong tình huống thông thường, để bảo vệ hệ thống của mình khỏi các hệ thống xấu trên Internet, tôi có thể chặn ở tầng IP
Nhưng Cloudflare proxy ở tầng IP cả hệ thống tốt, hệ thống xấu và mọi thứ ở giữa
Bình thường thì bạn có thể chặn ở mức IP các website do tổ chức tội phạm vận hành, hoặc liên hệ
abuse@của tổ chức lưu trữ nội dung để chặn hay báo cáoCloudflare khiến cả hai cách đó đều không làm được
Và khi gửi báo cáo lạm dụng cho Cloudflare, cũng không có gì đảm bảo họ sẽ không chuyển nguyên thông tin liên hệ của tôi cho chính đối tượng mà tôi đang tố cáo
Trong vài năm qua họ đã thay đổi lập trường để trông có vẻ có trách nhiệm hơn, nhưng cốt lõi vẫn vậy
Ngay cả khi tôi muốn gửi báo cáo
abuse@cho hệ thống đang ẩn sau Cloudflare, tôi cũng không thể chắc rằng họ sẽ không chỉ chuyển tiếp nó trong khi tôi không biết họ chuyển cho aiBài liên quan tuần trước:
“Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
https://news.ycombinator.com/item?id=48025001
Dù tôi không thích vai trò của CF trong Internet hiện đại, bài này trông giống như một mớ suy đoán đang cố nối các chấm lại với nhau mà không có cơ sở nào ngoài chuyện gia hạn chứng chỉ của Canonical và việc đổi công ty diễn ra cùng ngày
Tuy vậy vẫn có một câu chuyện bên lề đáng xem
Có vẻ gần đây Njalla đã âm thầm tái cấu trúc tổ chức hoặc thay đổi quyền sở hữu[1], và Njalla cùng immateriali.sm có vẻ là các pháp nhân liên quan[2]
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
Như bài viết nói rất ngắn gọn, Cloudflare bảo vệ phía trước cho kẻ tấn công miễn phí rồi lại tính tiền nạn nhân để được khắc phục
Dịch vụ phòng vệ DDoS có thể bị xem như một dạng bảo kê kỹ thuật số, và điều đó tạo ra động cơ để mặc cho kẻ tấn công tiếp tục tấn công
Kiểu như: “Internet nguy hiểm đấy, muốn bảo vệ website khỏi những kẻ tấn công đang dùng tầng miễn phí của chúng tôi thì hãy trả tiền cho chúng tôi”
Ngay cả khi không có chuyện thông đồng tích cực hay chia doanh thu, cũng không rõ dịch vụ phòng vệ DDoS đang đứng về phía nào
Tôi đồng ý với lời chỉ trích, nhưng Cloudflare đâu có phát minh ra DDoS
Dù Cloudflare có biến mất một cách thần kỳ vào ngày mai thì bot crawler AI cũng không dừng lại
Phương án thay thế là gì? Chắc không phải một thế giới nơi muốn duyệt Internet thì phải tải lên giấy tờ tùy thân do chính phủ cấp chứ?
Nhưng nếu muốn giữ tính ẩn danh tương đối và tính toàn cầu của Internet thì làm sao làm được điều đó?
Có thể mọi người lập hợp tác xã để lo phòng thủ, nhưng sẽ khó vận hành ở quy mô toàn cầu
Phòng vệ DDoS chủ yếu là có dung lượng dư thừa đủ để chịu được rồi lọc ra, nên mức đầu tư cần thiết là rất lớn
Cloudflare, dù không phải 100% như trong vụ The Daily Stormer[1], nhìn chung không kiểm duyệt nội dung được cho là hợp pháp đi qua hệ thống của mình và không tự chọn vai trò người phán quyết tính hợp pháp
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
Hoàn toàn đồng ý
Cloudflare đang bảo vệ những kẻ lừa đảo ở quy mô cực lớn mà chẳng ai bận tâm
Những cửa hàng giả mạo tôi báo cho Cloudflare, những trang phishing nằm sau Cloudflare, không có cái nào bị gỡ xuống cả
Không một cái nào
Nếu là một công ty kiếm hàng tỷ đô bằng cách bảo vệ con người thì họ phải xử lý chuyện này nghiêm túc
Ví dụ một vụ tòa án khiếu kiện nhỏ kiểu “tôi thiệt hại 20 đô, và để xác định đối tượng phải bồi thường thì tôi yêu cầu thông tin thanh toán khách hàng được cung cấp cho Cloudflare, ngân hàng phát hành và số tài khoản” nghe có vẻ khá ổn
Tôi chưa nghe ai nói đã thử, nhưng nếu có ai làm thì tôi rất muốn xem kết quả
Tôi nghĩ tình trạng hiện tại tốt hơn nhiều
Tôi vẫn luôn nghĩ Ubuntu bị sập là vì các máy chủ ubuntu không thể vá copy.fail, nên nhóm hacker đó muốn khai thác được nhiều mục tiêu nhất có thể trong khoảng thời gian đó
modprobe(8)# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadCó thể có tiến trình nào đó dùng tính năng này (
lsof | grep AF_ALG), nhưng theo hiểu biết của tôi thì nó không được dùng rộng rãi, nên trên đa số hệ thống việc vô hiệu hóa sẽ không gây vấn đềMọi máy chủ apex đều hẳn đã được cấu hình tính sẵn sàng cao để duy trì cân bằng tải, nên người dùng bình thường sẽ không cảm thấy gì khi vá copy.fail
Người dùng của chúng tôi cũng hoàn toàn không nhận ra khi chúng tôi triển khai bản vá
Đó không phải đe dọa mà gần với tống tiền hơn
CF không làm cả hai điều đó
Theo logic này thì nhà sản xuất bàn phím cũng phải chịu trách nhiệm cho các hành vi phạm pháp được viết ra bằng sản phẩm của họ
Tiếp tục cung cấp dịch vụ cho một tổ chức đang được dùng để hỗ trợ hoạt động tội phạm là chuyện rất khác, và chấm dứt khách hàng vì hoạt động bất hợp pháp thậm chí còn chẳng phải điều gây tranh cãi
Nếu bạn nhận một quả bom trong kiện hàng UPS thì không phải lỗi của UPS
Nhưng nếu người ta đã báo cho UPS rằng ai đó đang dùng UPS để gửi bom cho mọi người mà họ không làm gì cả, thậm chí còn có vẻ bảo vệ người gửi bom, thì chẳng phải họ cũng phải chịu phần nào trách nhiệm sao?
Trong kịch bản này, “nhà sản xuất bàn phím” gần với nhà sản xuất router mà Cloudflare mua thiết bị hơn, chứ không phải Cloudflare
Trong phép so sánh này, Cloudflare gần giống một đơn vị tổng hợp báo chí chở lẫn đủ thứ bẩn thỉu với bình luận bình thường
Trong hoàn cảnh thông thường, bạn có thể không đọc tờ báo bẩn, còn ai muốn đọc thì tự quyết định
Nhưng trong tình huống của Cloudflare thì các tờ báo chính thống lớn đều đã quyết định xuất bản nội dung qua Cloudflare, và khi thứ có vấn đề được phát cùng với đó thì thay vì chất vấn nhà phát hành gốc, bạn lại phải chất vấn Cloudflare
Mà Cloudflare thì có thể chuyển thông tin của tôi cho những kẻ cực kỳ khó chịu mà tôi không hề biết trước
Vậy thì nên vạch ranh giới ở đâu?