- Vào thời chưa có on-call rotation chính thức, lúc 3 giờ sáng, con mèo đã đánh thức người đang ngủ, nhờ đó có thể ngay lập tức phát hiện cảnh báo AWS CloudWatch và sự cố website
- Sau cảnh báo unhealthy targets của load balancer, trang web không thể mở được, và có một lượng lớn request đổ vào từ nhiều IP gắn với nhiều quốc gia
- Vì sản phẩm chỉ được cung cấp cho người dùng tại Mỹ, lưu lượng quốc tế là bất thường, và xét theo tình huống thì đó là một cuộc tấn công DDoS
- Cách chặn từng IP một trên server có thể kém hiệu quả, nhưng nhờ quy tắc chặn theo quốc gia đã được cấu hình sẵn trong AWS WAF, trong khoảng 1 giờ đã chặn được hàng trăm nghìn request
- Vào thời điểm cuộc tấn công bắt đầu, hộp thư hỗ trợ khách hàng nhận được email đe dọa nói rằng chúng đã làm sập trang bằng lỗ hổng Apache và đòi 5.000 USD bằng Bitcoin, công ty đã không trả lời
Sự cố lộ ra lúc 3 giờ sáng
- Khi đó startup chưa có on-call rotation chính thức, và đội ngũ vận hành theo cách cùng nhau theo dõi các cảnh báo khẩn cấp
- Khoảng 3 giờ sáng, con mèo chải tóc làm người viết tỉnh giấc, và khi nhìn điện thoại thì thấy vài phút trước đã có cảnh báo từ AWS CloudWatch
- Nguyên nhân cảnh báo là unhealthy targets của load balancer, và website thực sự đã không tải được
- Trên dashboard giám sát có thể thấy lượng lớn request đến từ nhiều địa chỉ IP gắn với nhiều quốc gia
- Vì sản phẩm chỉ được cung cấp cho người dùng tại Mỹ, lưu lượng quốc tế khác hẳn bình thường, nên được xác định là một cuộc tấn công DDoS
Chặn làn sóng request bằng AWS WAF
- Biện pháp ứng phó đầu tiên được nghĩ đến là chặn địa chỉ IP ở cấp server, nhưng nếu kẻ tấn công có thể dùng nhiều IP nguồn hơn thì cách này sẽ phiền phức và hiệu quả cũng hạn chế
- Tận dụng AWS Web Application Firewall đã cấu hình sẵn, họ thêm quy tắc chặn request từ các quốc gia khác để xử lý sự cố ngay lập tức
- Sau khi quy tắc được áp dụng, trong khoảng 1 giờ đã chặn được hàng trăm nghìn request, và website bắt đầu hoạt động trở lại
- Khi làn sóng request cũng dừng lại, sự cố trước mắt được giải quyết
Email đe dọa đến ngay sau cuộc tấn công
- Sáng hôm đó, họ kiểm tra email được gửi vào hộp thư hỗ trợ khách hàng vào đúng thời điểm cuộc tấn công bắt đầu
- Người gửi khẳng định đã tìm ra lỗ hổng của website và làm Apache bị crash, nhưng công ty không dùng Apache
- Chúng nói đã chặn toàn bộ lưu lượng của website và có thể duy trì điều đó trong vài tháng, đồng thời yêu cầu gửi 5.000 USD bằng Bitcoin thì sẽ đưa “solution file”
- Công ty đã không trả lời
- Vì điện thoại để ở chế độ không làm phiền vào ban đêm, nên không thể nói rằng rung hoặc âm báo từ thông báo AWS đã đánh thức con mèo trước
- Tác giả cho rằng con mèo bằng cách nào đó đã cảm nhận được chuyện không thể đợi đến sáng, và đây là cách bị đánh thức dễ chịu hơn rất nhiều so với báo động PagerDuty
1 bình luận
Các ý kiến trên Hacker News
Như mọi khi, rất dễ bỏ sót mối đe dọa nội bộ. Email tống tiền có ngữ pháp đáng ngờ? Đòi tiền chuộc bằng Bitcoin? Có bao giờ bạn nghĩ khả năng kẻ đứng sau vụ tấn công thật ra là một con mèo chưa?
Ở Kansas không có nhiều động đất, nhưng tôi vẫn nhớ trận động đất đầu tiên và duy nhất mà mình cảm nhận được
Tôi đang ngủ say thì con mèo Siamese dùng chân vỗ vào mặt đánh thức tôi dậy, rồi nó ngồi ở cuối giường và gầm gừ hung hăng khác thường
Chưa đầy 30 giây sau thì bắt đầu rung lắc. Tôi không biết nó biết bằng cách nào, nhưng chuyện đó khá đáng kinh ngạc; nó đã ra đi vào năm 2020 và tôi vẫn nhớ nó
Trong trận động đất gần đây ở NYC cũng có các video chó tru lên trước khi người ta cảm nhận được rung chấn, và tôi xem đây là hiện tượng khá phổ biến
Khi trải qua trận động đất 7,4 độ ở Taipei vài tuần trước, điều duy nhất tôi nghĩ đến là phải quay về với con chó của mình như đã hứa. Trước khi tôi rời đi nó có vẻ bất an, nhưng tôi không biết nó cảm nhận được việc tôi rời đi hay cảm nhận được trận động đất mà tôi đang đi về phía đó
Trong đá có hai loại sóng âm: sóng P và sóng S. Sóng P là sóng áp suất nên nhanh hơn, còn sóng S dao động ngang và chậm hơn một chút. Khả năng cao con mèo đã tỉnh dậy vì tiếng rít của sóng P, vốn đến sớm hơn một chút so với trận động đất mà con người cảm nhận được
Việc có hai loại sóng và sóng P đến trước có thể xem tại https://manoa.hawaii.edu/exploringourfluidearth/physical/oce...
Có thể điện thoại để chế độ im lặng nhưng màn hình vẫn liên tục nhấp nháy. Máy của tôi cũng hoạt động như vậy ở chế độ đó
Ở công việc đầu tiên của tôi, có một người luôn nhận ra sự cố sắp xảy ra trên dashboard giám sát trước khi nó bùng lên. Bản thân người đó cũng không giải thích hay hiểu được mình đang nhìn thấy gì, người khác cũng không bắt chước được, nhưng khi họ nói có gì đó bất thường thì thường là thông báo cảnh báo sẽ đến ngay sau đó
Tôi từng đọc một bài về một giám sát công trường được công nhân kính nể vì có khả năng tìm ống dẫn dưới đất hoặc trong tường giỏi một cách bất thường. Ban đầu ông ấy bắt đầu tin đó là siêu năng lực, nhưng về sau kết luận rằng mình đã vô thức học được các mẫu hình điển hình và những manh mối thỉnh thoảng xuất hiện nhưng trái trực giác. Ví dụ như nhìn thấy ống thông gió trên tường tòa nhà rồi nhận ra khả năng có đường ống thoát nước ở tầng hầm
Tôi đã đến mức nhận ra khá chính xác “trò này sắp crash rồi, phải lưu thôi”. Lưu xong, khởi động lại 10 giây sau thì nó thực sự crash, mà đến giờ tôi vẫn không biết mình biết bằng cách nào
5.000 đô la nghe cũng khá kiểu hoàng tử đấy. Năm 2016 công ty chúng tôi cũng nhận được yêu cầu như vậy
Chúng tôi bị DDoS và quyết định phớt lờ, nhưng để phòng hờ vẫn tìm hiểu một ít BTC. Sau đó chúng tôi tốn hơn 5.000 đô la rất nhiều để triển khai hàng đống biện pháp chống DDoS, nhưng việc không trả tiền cho kẻ tống tiền là xứng đáng
Chúng tôi không trả lời bất kỳ email nào. Đám tấn công cũng khá ngu, chỉ nhắm vào web server đặt ở nơi có kết nối tốt
Dịch vụ thực sự kiếm tiền thì nằm ở Caribbean, chỉ có đường T1 1,5Mbps và đường dự phòng vệ tinh 0,5Mbps. Chúng có thể làm nghẽn chỗ đó dễ hơn và lâu hơn nhiều, và khi đó thiệt hại doanh thu sẽ vào khoảng 1 triệu đô la mỗi giờ
Trả 5.000 đô la cho một kẻ tấn công có thể trông rẻ hơn xây dựng phòng thủ, nhưng nếu có phòng thủ thì khả năng bị tấn công trong tương lai sẽ thấp hơn. Và như đã nói, bản thân việc không đưa tiền cho tội phạm cũng có giá trị
Về đoạn “tôi không trả lời, nhưng nhìn lại thì chắc trêu chúng cũng vui”, không phản hồi là câu trả lời hiệu quả duy nhất
Nếu trêu chọc, bạn chỉ khiến mình nổi bật hơn và có thể trở thành mục tiêu của các cuộc tấn công khác. Bạn được gì từ đó?
Nhưng tưởng tượng thì vẫn vui, nhất là sau khi xem video được liên kết trong bài: https://www.youtube.com/watch?v=dWzz3NeDz3E
Trước đây, một người trong gia đình tôi phát hiện máy rửa bát bị rò nước nhờ cảnh báo từ mèo
Kết luận là hoặc con mèo đang cố cứu chúng tôi, hoặc đang cố giết chúng tôi
Một người đang ngủ ngoài trời thì tỉnh dậy vì tiếng quạ kêu, và đúng lúc đó một con mèo lớn, có lẽ là hổ, đang lén áp sát
Một nhân vật cho rằng con quạ đang cố cảnh báo người đó, còn nhân vật khác cho rằng con chim đã báo cho con hổ biết có người đang ngủ để nó có thể ăn phần thừa sau bữa
“Ngữ pháp kinh khủng” cơ à, đúng là thời trước ChatGPT
Nghiêm túc hơn một chút, liệu có ngày nào đó sẽ có cách chặn DDoS vĩnh viễn không? Mọi mối đe dọa đều xấu, nhưng DDoS có vẻ là kiểu tấn công tầm thường nhất. Không cần kỹ năng hay kiến thức đặc biệt; chỉ cần chạy script, hoặc trả tiền cho người khác chạy như một dịch vụ
Địa chỉ IP, hay subnet nếu là IPv6, là tài nguyên bị giới hạn đối với người dùng thông thường, băng thông cũng vậy. Hầu hết các tấn công khuếch đại cần IP spoofing, mà trong các kết nối thông thường thì nhiều khi không làm được
Nếu là tấn công dựa trên dung lượng, bên nào có nhiều băng thông hơn sẽ thắng. Kẻ tấn công có thể dùng khuếch đại ở đây. Nếu là tấn công dựa trên tải hoặc ở tầng ứng dụng, có thể xử lý bằng cách chặn IP của kẻ tấn công ở mức firewall. Trường hợp này đã có WAF/Cloudfront, nên không phải tấn công dung lượng thuần túy mà gần với tấn công tầng ứng dụng hơn
Việc tìm IP kẻ tấn công để chặn là bài toán quy đúng chi phí theo từng IP nguồn, đồng thời cũng quy đúng lợi ích từ hoạt động người dùng hợp pháp theo từng IP nguồn, rồi chặn những IP hoặc dải IP có chi phí vượt xa lợi ích
Nói thì dễ hơn làm. Chi phí xuất hiện dưới nhiều dạng: kết nối mở chiếm bộ nhớ, TLS handshake, request khiến web server tốn kém để phân tích, request kích hoạt truy vấn cơ sở dữ liệu đắt đỏ, băng thông I/O, v.v. Vì vậy đa số sẽ đặt Cloudflare, hoặc như ở đây là Cloudfront, ở phía trước và обход bằng quy tắc thủ công như trong trường hợp này
Sẽ rất tuyệt nếu có cách làm DDoS khó thành công ngay ở tầng giao thức, nhưng tôi không chắc điều đó có khả thi không
Và còn có DDoS dựa trên dung lượng. Cái này có thể chặn nếu bạn có nhiều băng thông hơn tất cả mọi người, nhưng khá khó, và bản thân bạn cũng trở thành một kẻ tấn công tiềm tàng
Đổi mới ở đây là phát tán bộ lọc lưu lượng bằng BGP. Null routing tương ứng với sản phẩm khả dụng tối thiểu. Kiểu như: IP này đang bị tấn công, hãy vứt bỏ lưu lượng hướng đến đó càng sớm càng tốt. Tôi cũng từng thấy các hệ thống tinh vi hơn, chẳng hạn bỏ UDP, bỏ packet bị phân mảnh, bỏ packet gửi/nhận ở một số port UDP/TCP cụ thể
Phần lớn các hệ thống kiểu này được thiết kế để các route đặc biệt không lan truyền trực tiếp ra ngoài peer, nhưng trong một số trường hợp việc lan truyền có thể lại là điều mong muốn
Nếu phần lớn khách hàng ở Mexico, còn Canada phát động DDoS khiến đường truyền giữa tôi và Canada bị nghẽn, thì có thể đó không phải vấn đề lớn. Miễn là các router tiêu dùng ở phía Mexico không tự nguyện nhảy vào giúp cái nút thắt Canada đó
Tôi tưởng đã nối máy cho mèo ăn với hệ thống cảnh báo
Dù sao thì cũng dễ thương. Con mèo tên gì vậy?
Tên nó là Bamboo. Đáng buồn là nó đã mất vì ung thư. Tôi đặt tên như vậy vì một trong những việc đầu tiên nó làm sau khi được nhận nuôi là cố ăn chậu tre của tôi
Máy cho mèo ăn không dây phụ thuộc vào Internet, và khi thức ăn không rơi ra, con mèo đã đi khiếu nại với quản trị viên
Làm tôi nhớ đến cuốn sách này: Dogs that Know When their Owners are Coming Home https://www.sheldrake.org/books-by-rupert-sheldrake/dogs-tha...
Chặn DDoS bằng token bucket dễ đến mức thường thì lúc mèo phải đánh thức tôi dậy chỉ là khi Discord của tôi bị raid thôi
Trông giống cách bỏ các packet tạo tải quá mức ở firewall hoặc phía ingress trước khi chúng chạm tới application server
Nếu cuộc tấn công có lượng yêu cầu kết nối hoặc số lượng địa chỉ IP duy nhất đủ lớn thì vẫn có thể làm dịch vụ quá tải
Token bucket thường chỉ là một phần của chiến lược phục hồi, chứ không phải giải pháp vạn năng cho mọi vấn đề từ chối dịch vụ