Cuộc tấn công tự DDOS của Twitter
(sfba.social)- Trong lúc feed trang chủ Twitter ngừng hoạt động gần như suốt buổi sáng hôm đó, đã quan sát thấy tình huống web client liên tục lặp lại yêu cầu nội dung, dường như tự gây ra DDOS
- Ngay cả trên màn hình không tải được, việc thử lại vẫn không dừng; video đầu tiên cho thấy lỗi rate limited và thanh cuộn rung lắc
- Ở video thứ hai, có thể thấy Twitter gửi cho chính mình khoảng 10 yêu cầu mỗi giây trong quá trình cố lấy nội dung không hề đến
- Giới hạn đọc với người dùng chưa đăng nhập được áp dụng gần đây được chỉ ra là nguyên nhân có thể đã tạo ra một điều kiện ngoài dự kiến
- Trong console mạng của Firefox ở video theo sau, các yêu cầu vẫn tiếp tục dồn dập, được hiểu là đã dẫn tới tình huống tự DDOS khi trình duyệt của người dùng lặp lại yêu cầu tới Twitter
Các yêu cầu lặp lại được quan sát trên web client của Twitter
- Feed trang chủ Twitter đã ngừng hoạt động gần như suốt buổi sáng hôm đó, và ngay cả khi không tải được gì, website vẫn không ngừng thử lại yêu cầu
- Video đầu tiên ghi lại cảnh thông báo lỗi người dùng đang ở trạng thái rate limited cùng thanh cuộn bên phải rung lắc
- Video thứ hai cho thấy lý do thanh cuộn rung lắc, ghi lại cảnh Twitter gửi cho chính mình khoảng 10 yêu cầu mỗi giây để cố lấy nội dung
- Thay đổi ngăn người dùng chưa đăng nhập đọc Twitter được chỉ ra là bối cảnh khiến nội dung không thể đến nơi
Xác nhận tiếp theo và tài liệu đính kèm
- Bài đăng tiếp theo cho thấy thêm cảnh các yêu cầu mạng tiếp tục phát sinh thông qua màn hình console mạng của Firefox
- Có nhận định rằng đoạn mã được triển khai đã gây ra race condition, và kết quả là người dùng thực hiện các yêu cầu mang tính DDOS hướng tới Twitter
- Người đăng cho biết ban đầu đã đóng kết nối, nhưng sau đó Twitter vẫn tiếp tục duy trì tình huống kích hoạt yêu cầu trong một thời gian
- Tài liệu đính kèm:
2 bình luận
Twitter, tạm thời chuyển sang chế độ giới hạn tốc độ
Ý kiến trên Hacker News
Từ kinh nghiệm cá nhân rất đau đớn, hiếm có điều gì làm con người lung lay hơn việc bị ép thực hiện một ý tưởng tồi tệ khủng khiếp dù biết rõ nó là như vậy
Nhất là khi bạn đã cố nói điều đó với người đang gây áp lực buộc bạn làm trái với phán đoán tốt nhất của mình nhưng thất bại, và còn tệ hơn nữa khi sau này người đó lớn tiếng phủ nhận rằng họ từng đưa ra yêu cầu như vậy dù có cả bằng chứng bằng văn bản
Không rõ những người đang làm việc ở Twitter có cảnh báo rằng các biện pháp gần đây có thể gây ra tác dụng phụ lớn như thế này hay không, nhưng nhìn vào cách vận hành của ban lãnh đạo thì điều đó hoàn toàn không có gì đáng ngạc nhiên
Tôi rất ghét những gì Twitter đã trở thành trong vài tháng qua, và ngay cả trước khi bị mua lại tôi cũng không thích nó vì định dạng ngắn làm mất sắc thái và chỉ vài tweet dễ nhúng đã trở thành căn cứ cho các bài báo, nhưng tôi thực sự thấy đáng thương cho những người phải làm việc dưới ban quản lý như vậy
Nếu đoán thì có lẽ Elon đã nói “trang quá chậm”, các kỹ sư thấy yêu cầu cho home feed bị chậm nhưng không hiểu cấu trúc, cũng không có công cụ profiling, lại bị ép phải sửa trong một thời hạn phi thực tế
Vì thế gần như điều duy nhất họ có thể làm là bắn nhiều yêu cầu song song rồi hy vọng một trong số đó sẽ nhanh
Từng làm trong ngành game, tôi hiểu vì sao có những trò chơi tiêu tốn cả đống tiền và thời gian mà vẫn phát hành trong tình trạng ngay cả chức năng cơ bản cũng hỏng
Kiểu áp lực lịch trình cực đoan này nghịch lý ở chỗ nó tạo ra một vũng lầy khổng lồ nơi sửa một thứ thì mười thứ khác vỡ theo, và cuối cùng tiến độ bị đình trệ
Đây là xử lý lỗi cơ bản đáng lẽ phải có từ nhiều năm trước
Dù là 403 hay bất cứ phản hồi nào chặn tweet, nó tuyệt đối không được kích hoạt việc retry vô hạn với khoảng cách cực ngắn
Tôi đã làm một công cụ để quản lý các ticket lỗ hổng của đội, mà ca sử dụng đầu tiên lại là xóa toàn bộ ticket lỗ hổng bất chấp sự phản đối của tôi
Người thực hiện quan tâm đến việc làm cho mọi thứ trông đẹp trên giấy tờ hơn là cải thiện bảo mật thực sự
Bạn đã biết từ rất lâu và đề xuất lặp đi lặp lại, nhưng thậm chí còn không được phép thử, ngược lại còn bị gạt ra và bị coi là “cái người đó”
Tôi từng trải qua điều này với một cách tiếp cận kỹ thuật và kinh doanh đang từ từ giết chết công ty dù “cách làm cũ” vẫn bằng cách nào đó còn chạy được
Dù vậy, nếu cấp trên xác nhận rõ trách nhiệm cho một việc mà họ đánh giá là rủi ro nhưng cần thiết, thì khi có vấn đề xảy ra cũng sẽ có nhiều không gian hơn để phản ứng tốt, và lập trình viên cũng đỡ phải hứng chịu những lời mỉa mai muộn màng
Tất nhiên, kiểu này vẫn dễ bị chửi hơn
Cần nhớ rằng lần này là cuối tuần nghỉ lễ
Elon đã ép ra một bản phát hành lớn, về cơ bản là bắt các kỹ sư phải đi làm và lặp đi lặp lại nhiều bản vá trong 12 giờ qua
Tôi lo cho các lập trình viên
Điều còn đáng ngạc nhiên hơn là dạo này kỹ thuật ở Twitter trông tạm bợ đến mức nào
Họ không bỏ công đào sâu vào codebase mà chỉ chọn những bản sửa đơn giản và ngắn nhất, nên mới sinh chuyện
Đến thời điểm này thì cả điều kiện tuyển dụng lẫn kỳ vọng của sếp đều đã quá rõ ràng
Vì lý do gì mà vẫn ở lại thì cũng khó mà đồng cảm với những người cứ tiếp tục chịu đựng
Khả năng rất thấp là lỗi này là nguyên nhân
Bộ giới hạn tốc độ phía server có chi phí thấp, và lỗi frontend chỉ được kích hoạt khi giới hạn tốc độ đã hoạt động
Tôi cũng từng thấy lỗi tương tự trong hệ thống mình quản lý vì thư viện mạng mặc định thích retry request mà không có giới hạn hợp lý nào
Nhưng những lần retry đó chưa từng làm bộ giới hạn tốc độ kiệt sức
Nếu bạn gọi vào một API chỉ trả lỗi sau khi đã làm xong một số tác vụ tốn kém thì sẽ phiền hơn đôi chút, và vì vậy tôi đặt giới hạn tốc độ cho mọi endpoint công khai
Web app có lẽ chỉ là phần nhỏ nhất trong lưu lượng Twitter, và ứng dụng native thì có lẽ không gặp vấn đề này
Có thể việc chặn truy cập ẩn danh đã gây ra DDoS, dẫn đến một cú tăng vọt khổng lồ ở chỉ số nào đó, rồi vì thế Elon kết luận là scraping tăng mạnh và áp giới hạn 600 tweet mỗi ngày để trừng phạt scraper
Có vẻ quota của tôi đã được reset hoặc chính sách đã thay đổi, vì giờ tôi lại vào được trang
Tôi đồng ý rằng khả năng lỗi này là nguyên nhân gốc của toàn bộ chuyện là thấp
Nhưng tôi cũng không tin vào câu chuyện mà Musk đem ra bán như lý do khiến ông ấy gần như đóng cửa trang
Cả hai đều có thể đúng, và điều đó cứ khiến người ta tiếp tục nghĩ đến các nguyên nhân tiềm năng khác, dù hoàn toàn phí thời gian nhưng lại giống như một mồi nhử kỳ quái về mặt tinh thần
Cuốn sách "Nothing is true and everything is possible" nói về cách Putin dùng thông tin sai lệch để kiểm soát công chúng và loại bỏ chính trị dân chủ, và cảm giác là điều đó cũng áp dụng ở đây
Fan của Musk sẽ lặp lại đúng những gì ông ta bảo họ nói, nhưng phần lớn mọi người sẽ biết đó chỉ là lời nhảm nhí phục vụ lợi ích riêng
Và những ai cố tìm nguyên nhân gốc rất dễ bị cuốn vào các câu chuyện như lỗi này, nghe thì có vẻ đúng nhưng hoàn toàn không có dữ liệu hậu thuẫn
Nếu muốn thấy một con đường tương lai khả dĩ của nước Mỹ, tôi rất khuyến nghị cuốn sách này
https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
Tôi từng tận mắt thấy và cố giảm thiểu các trường hợp suy thoái mà những lần retry kiểu này đè bẹp backend đến mức server không kịp từ chối yêu cầu
Do retry ở nhiều tầng caller phía thượng nguồn, tình hình tệ đến mức request gần như timeout ngay trong TCP buffer/queue trước cả khi được ứng dụng xử lý
Tôi không biết backend của trang chủ Twitter có ở quy mô tương tự hay không
Tình huống này khá thú vị
Nhìn vào ảnh chụp màn hình thì có vẻ đang phát sinh một lượng khổng lồ
GET /TweetDetail, và như 429 cho thấy, dường như đã kích hoạt một dạng giới hạn tốc độ nào đóNếu điều này là hệ quả của quyết định gần đây buộc xác thực cho mọi lệnh gọi API, thì thủ phạm thật sự có thể là API gateway hoặc một thành phần tương tự ở bên dưới
Ngoài ra, hành vi này trông có vẻ không dừng lại, mà đó không phải là kiểu hành vi mong đợi từ retry với exponential backoff
Không phải tôi muốn nói mình là kỹ sư giỏi hơn những người đang làm ở Twitter, nhưng ngay cả khi bỏ qua yếu tố liên quan đến Musk thì nhìn thấy hiện tượng như thế này ngoài thực tế vẫn rất thú vị
Tôi đã thấy quá nhiều trường hợp người ta cho rằng xử lý yêu cầu người dùng với độ trễ thấp là quá quan trọng, nên họ thích một kiểu backoff ngẫu nhiên cố định hơn là exponential backoff
Tôi đã thấy trong nhiều cuộc họp thiết kế và tài liệu rằng người ta hiểu rõ sự đánh đổi giữa quá tải và phục hồi hệ thống, rồi vẫn đưa ra quyết định rõ ràng là không dùng exponential backoff
Một thay đổi phía backend, tức là xác thực bắt buộc + giới hạn tốc độ, có thể đã được triển khai mà không kiểm thử đủ kỹ frontend và backend cùng nhau
Trông đó giống một thủ phạm hợp lý
Có thể các instance của Twitter đang bị buộc phải dừng
Platformer được cho là đã đưa tin ngày 10/6 rằng “Twitter đã từ chối thanh toán chi phí dịch vụ Google Cloud trước ngày gia hạn hợp đồng 30/6”
Cũng có nói rằng “hợp đồng Google Cloud của Twitter đã kéo dài từ năm 2018”
https://www.engadget.com/twitter-has-supposedly-started-payi...
À, có vẻ như chuyện này giải thích được toàn bộ mớ hỗn loạn
Họ có lẽ đang cố rời khỏi GCP, nhưng có lẽ đây không phải là chuyện đột ngột mất quyền truy cập GCP vì từ chối thanh toán
Đây là bài báo từ một tuần trước
Mọi thứ đều tự host
Gcloud chỉ hỗ trợ tác vụ batch và phân tích dữ liệu
Đây là một giả thuyết thú vị, nhưng DDoS đã xảy ra trước quyết định vô hiệu hóa truy cập ẩn danh
Trên thực tế, quyết định đó được đưa ra để giảm thiểu DDoS đang diễn ra[0][1]
Vì vậy, logic retry đáng ngờ của web frontend có thể đã làm tình hình tệ hơn, nhưng không phải nguyên nhân gốc rễ
[0] https://twitter.com/elonmusk/status/1674865731136020505
“Đây là biện pháp khẩn cấp tạm thời. Việc hút dữ liệu quá mức đang làm giảm chất lượng dịch vụ cho người dùng bình thường!”
[1] https://twitter.com/elonmusk/status/1674942336583757825
“Nó sẽ sớm được gỡ bỏ. Như bài trước đã nói, mức độ scraping dữ liệu cực đoan đòi hỏi hành động mạnh và tức thời.”
“Từ startup đến một số công ty lớn nhất hành tinh, gần như mọi công ty làm AI đều đang scraping một lượng dữ liệu khổng lồ.”
“Việc phải khẩn cấp dựng lên một lượng lớn máy chủ chỉ để giúp một startup AI nào đó có mức định giá phi lý nghe thật bực mình.”
Chắc chắn ở đâu đó vẫn đang lưu hành những kho lưu trữ khổng lồ chứa toàn bộ tweet trước một ngày cụ thể mà các startup đó dùng
Có ai biết trước thay đổi chỉ cho đăng nhập thì đã có các request như thế này chưa?
Nếu hóa ra công việc scraping khổng lồ thực ra là lỗi JavaScript của chính họ thì sẽ rất buồn cười
Sẽ không hề ngạc nhiên nếu phần lớn “lưu lượng scraping” thực ra là do chính Twitter tự gây ra
Kết quả vừa ngớ ngẩn vừa quá dễ đoán
Hàng chục request có lẽ đã được gửi đi trong vài giây trước khi bị dính giới hạn tốc độ
Nhiều lỗi nhỏ như vậy gộp lại có thể trông giống như một cuộc DDoS hay scraping nào đó
Có vẻ cũng chưa chắc là bug
Elon nói rằng đã giới hạn số tweet xem được mỗi ngày xuống 600, và đó là một giới hạn điên rồ
Phần lớn mọi người chỉ cần cuộn 5 phút là đã vượt mức đó rồi
Tôi nhớ là khi Tweetbot hiện rằng feed của tôi có hơn 500 mục, thì cũng đã đủ thứ nhảm nhí để đọc trong vài chuyến đi tram 20 phút
Tôi không nghi ngờ việc Twitter gần đây đã chứng kiến mức tăng lưu lượng khổng lồ, nhưng tôi khá chắc rằng phần lớn trong số đó là vấn đề do chính Twitter tự tạo ra
Elon lẽ ra chỉ cần để yên mọi thứ, nhưng à đúng rồi, có 44 tỷ đô la mà
Parag Agrawal và đội ngũ của ông ấy biết chính xác mình đang làm gì
Đúng là câu nói kẻ ngốc và tiền bạc sớm muộn cũng chia tay
Sau khi Elon bị tòa án Delaware buộc phải mua Twitter, ông ta đi gặp các nhà độc tài lắm tiền và nhận 44 tỷ đô la từ họ để đốt Twitter thay mặt họ
Không có Twitter thì cũng không có Arab Spring, không có cập nhật thảm họa theo thời gian thực, và cũng không cần chặn Internet để ngăn tiếng nói phản đối lan rộng
Không quá quan trọng nhưng giới hạn tốc độ đang lại được nới ra
6k/600/300 → 8k/800/400 (khoảng giữa trưa) → 10k/1k/500 (khoảng 3 giờ chiều)
https://twitter.com/elonmusk/status/1675214274627530754 và dựa trên câu trả lời của chính ông ấy
Hiện ra “Something went wrong”
Theo quy định mới chỉ dành cho người đăng nhập thì có lẽ dù trang còn sống cũng vẫn không đọc được
Giờ thì liên kết Twitter đã trở thành liên kết bị ô nhiễm, về cơ bản là vô dụng
Đúng là một gánh xiếc hoàn chỉnh