- Máy chủ Gitea công khai
git.xeserv.us trở nên không ổn định do các yêu cầu từ AmazonBot, và người vận hành đã yêu cầu đội ngũ AmazonBot đưa tên miền này vào danh sách chặn
- Dù đã cấu hình
robots.txt để Disallow: / với mọi bot, các yêu cầu vẫn tiếp tục đổ tới, khiến tình hình có thể đi đến mức phải ngừng vận hành máy chủ Git công khai
- Các trình thu thập AI khiến việc chặn trở nên khó khăn bằng cách đổi user-agent hoặc dùng proxy IP dân dụng
- Đã chặn ở nginx ingress để trả về
418 cho user-agent chứa Amazon, nhưng yêu cầu vẫn tiếp tục từ các IP khác, và khoảng 10% thậm chí không có user-agent amazonbot
- Cuối cùng, máy chủ Gitea lại được chuyển ra sau VPN, và một reverse proxy tên
Anubis được tạo ra để kiểm tra proof of work trước khi cho phép yêu cầu đi vào
Yêu cầu từ AmazonBot và giới hạn của robots.txt
- Người vận hành đã yêu cầu phía vận hành AmazonBot thêm
git.xeserv.us vào danh sách tên miền bị chặn
- Họ cũng yêu cầu phía đó liên hệ nếu muốn thu thập dữ liệu máy chủ Git, để có thể chi trả chi phí nâng cấp phần cứng nhằm đáp ứng mức sử dụng tài nguyên quá lớn
- Dù đã thiết lập
robots.txt để chặn mọi bot, điều này vẫn không đủ để ngăn các yêu cầu thực tế
User-agent: *
Disallow: /
- Bài viết cũng tổng hợp lý do vì sao khó chặn bot crawler AI
- Bot nói dối
- Thay đổi user-agent
- Dùng địa chỉ IP dân dụng làm proxy
- Và còn dùng những cách khác nữa
Chặn ở nginx ingress và công bố Anubis
- Vào 2025-01-17 17:50 UTC, người vận hành đã thêm cấu hình chặn user-agent ở nginx ingress
nginx.ingress.kubernetes.io/configuration-snippet: |
if ($http_user_agent ~* "(Amazon)" ){
return 418;
}
- Ngay cả sau cấu hình này, bot vẫn tiếp tục gửi yêu cầu từ các IP khác nhau mỗi lần, và khoảng 10% số yêu cầu không có user-agent
amazonbot
- Vào 2025-01-18 19:00 UTC, máy chủ Gitea được chuyển trở lại sau VPN
- Sau đó, người vận hành bắt đầu tạo một reverse proxy để kiểm tra proof of work trước khi cho phép yêu cầu đi vào máy chủ Gitea
- Đến 2025-01-18 23:50 UTC, reverse proxy này đã có thể được xem tại
https://git.xeserv.us/ với tên Anubis
- Tính đến 2025-03-26 14:27 UTC,
Anubis đã trở thành một dự án độc lập có trang tài liệu riêng
1 bình luận
Các ý kiến trên Hacker News
Giờ là lúc gửi thư đứng tên luật sư. Theo hướng dẫn truy tố của Computer Fraud and Abuse Act, Bộ Tư pháp Mỹ nhìn chung không coi việc truy cập máy chủ công khai là “truy cập trái phép” nếu đó không phải là một cuộc tấn công rõ ràng, nhưng sau đó, nếu người có thẩm quyền gửi yêu cầu dừng bằng văn bản rõ ràng và bị đơn đã nhận, hiểu yêu cầu đó, thì kể từ thời điểm ấy sẽ bị xem là trái phép
Vì vậy, hãy nhờ luật sư viết một lá thư “cease and desist” rõ ràng, rồi gửi cho Amazon bằng thư bảo đảm hoặc thông qua người tống đạt theo cách luật sư khuyến nghị. Có lẽ nên làm cả hai và gửi thêm email nữa
Sau đó xem Amazon có dừng không; nếu không dừng thì có thể nộp đơn tố giác hình sự. Khi đó Amazon cũng sẽ phải để tâm
https://www.justice.gov/jm/jm-9-48000-computer-fraud
Bot của Amazon phải đến từ các dải IP Amazon đã biết và phải tuân thủ robots.txt. Một kỹ sư Amazon cũng đã xác nhận trong một bình luận khác: https://news.ycombinator.com/item?id=42751729
Nếu thứ duy nhất khớp với Amazon là chuỗi user agent “AmazonBot”, còn dải IP hay hành vi thì không khớp, gửi thư luật sư cho Amazon chẳng khác nào đốt tiền
Tôi thích giải pháp trong bình luận này: https://news.ycombinator.com/item?id=42727510
Cách làm là đặt ở đâu đó trên site một liên kết mà con người sẽ không bao giờ truy cập, cấm nó trong robots.txt, rồi nếu IP nào truy cập liên kết đó thì chặn 24 giờ. Vì nghe nói crawler của OpenAI đặc biệt phớt lờ wildcard, nên đặt nó dưới một wildcard để xử lý
Nhưng vì có quá nhiều IP liên quan nên gần như không ảnh hưởng đến lưu lượng
Tôi khuyên nên xem header nhận được thật kỹ. varnishlog khá tốt cho việc này; nếu nhìn đủ lâu, bạn có thể tìm ra đặc điểm chung của mọi request. Ví dụ như sự kết hợp lạ giữa ngôn ngữ được báo cáo và vị trí địa lý, hoặc cùng một phiên bản trình duyệt cũ kỹ
Tệ hơn nữa, trình xử lý lỗi có bug khiến tiến trình máy chủ bị khởi động lại khi điều kiện này xảy ra, và trong quá trình đó làm vô hiệu cả triển khai cache “khá ổn theo chuẩn .NET 2.0”
Vì vậy tôi nhớ là chúng tôi bắt đầu thêm kỹ thuật canary làm biện pháp an toàn. Vài canary đơn giản vẫn rẻ hơn thêm một web server khác. Tất nhiên chúng tôi cũng sửa vấn đề cache, và thêm cách để dịch vụ “la hét” khi có quá nhiều request xấu
Nhưng rốt cuộc crawler của chính các công ty đó lại không parse được manifest do họ tạo ra
Chúng tôi cũng thấy cùng hành vi từ tất cả bot AI·SEO, nên tôi đồng tình. Chúng chỉ tuân thủ robots.txt ở mức vừa đủ, và cũng khó chặn. Khi crawl, chúng ập đến như spam, làm tải tăng mạnh và đánh sập nhiều máy chủ của khách hàng
Nếu crawler AI muốn truy cập thì phải cư xử tử tế hoặc trả tiền. Nếu không, kết quả sẽ là bị chặn gần như phổ biến
-j TARPITcho các IP gửi request đến/apitrung bình trên X lần mỗi giâyTôi không chắc triển khai trên cloud thì làm thế nào. Tôi chưa từng cần đến nó ở đó
https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
Hoặc ít nhất, vì lịch sự, mong chúng crawl vào ban đêm hoặc ngoài giờ cao điểm
Tôi sẽ không giả định đây thực sự là Amazon. Tác giả đang thấy các request luân phiên dùng IP dân dụng và chuỗi user agent cũng thay đổi
Việc giả làm crawler của một công ty lớn là kỹ thuật thường thấy của những người muốn tránh bị chú ý. Thực tế request đến từ IP dân dụng là một tín hiệu cảnh báo lớn rằng có chuyện khác đang diễn ra
Dựa trên thông tin tôi có thể kiểm tra nội bộ, khả năng đây thực sự là Amazon là rất thấp. Amazonbot phải tuân thủ robots.txt và luôn phải đến từ địa chỉ IP do Amazon sở hữu. Quy trình xác minh ở đây: https://developer.amazon.com/en/amazonbot
Tôi đã chuyển việc này vào nội bộ để kiểm tra xem có đội nội bộ kỳ lạ nào mà tôi không biết đang làm chuyện này không, nhưng tác giả nên xem lưu lượng này là độc hại và xử lý như trường hợp mạo danh user agent
[1] https://brightdata.com/proxy-types/residential-proxies
Gần đây tôi cũng gặp vấn đề tương tự. Instance Forgejo của tôi bắt đầu dùng 100% CPU của home server, vì Claude cùng các bạn AI của Meta và Google gần như đang nã vào vô hạn link với tốc độ cao
robots.txt và danh sách chặn dựa trên user agent trong Caddy đã giảm được phần nào, nhưng không biết cách này còn hiệu quả bao lâu
Phép lịch sự trong scraping đã đi đâu mất rồi?
Rủi ro lớn hơn là một trong các công ty này, thậm chí là công ty tự nhận là “Open”, trở nên lớn đến mức “không thể để sụp đổ” xét từ góc độ kinh tế hoặc an ninh quốc gia
Facebook nổi tiếng vì đã khiến việc scrape danh sách bạn bè từ MySpace trở nên dễ dàng, rồi sau khi lớn mạnh, họ lại cấm chính hành vi tương tự trên site của mình
Làm ơn tỉnh táo lại đi
Có chắc đây không phải là một vụ DDoS giả mạo Amazon không?
Việc request đến từ IP dân dụng thật sự rất đáng ngờ
Động cơ của kiểu DDoS này có thể là đánh sập các site nhỏ và làm cho trông như Amazon chịu trách nhiệm, qua đó nhắm vào Amazon
Nếu thực sự là Amazon thì điểm bắt đầu là chặn toàn bộ các dải IP họ công bố. Tuy nhiên nghe như request cũng đến từ ngoài các dải đó
Các dịch vụ kiểu này trả tiền cho băng thông của người dùng rồi bán lại cho bên thứ ba, nên rất nhiều traffic bot trông như đến từ IP dân dụng
Site Pinboard của tôi cũng đang bị những thứ có vẻ là crawler AI nện liên tục. Mùa hè này chúng bắt đầu từ IP Trung Quốc và Singapore, nhưng giờ thì tôi không thể chặn theo dải IP nữa và phải dựa vào CAPTCHA
Mức traffic đủ để giết site ngay lập tức, trong khi tôi cũng chẳng có văn bản thú vị nào để huấn luyện, chỉ có link thôi
Tôi tò mò không biết tác giả bài gốc đã xác định Amazon crawler là nguyên nhân bằng cách nào. Tôi cũng muốn tìm đối tượng để quy trách nhiệm
Cách tốt nhất để chống lại những thứ này có thể không phải là chặn. Chặn không gây thiệt hại gì cho Amazon hay công ty nào khác
Thay vào đó, sẽ thế nào nếu ta có thể cho bot ăn nội dung rõ ràng độc hại hoặc làm hỏng dữ liệu?
Nếu việc này được thực hiện ở quy mô lớn hơn và Amazon phát hiện dữ liệu đầu độc, họ sẽ phải tốn tiền để loại bỏ nhanh chóng và sẽ cố ngăn bot ăn loại dữ liệu đó
Dĩ nhiên vấn đề lớn nhất là chẳng ai muốn đặt thứ như vậy trên site của mình
Các scraper này vốn đã ăn cả CSAM và những thứ kinh khủng tương đương mà không ngần ngại. Một số nhà thầu gắn nhãn dữ liệu ở Kenya của OpenAI đã nghỉ việc vì chuyện này. Đây là bài của Time năm 2023
Hiện các công ty AI không quan tâm đến chất lượng dữ liệu mà chỉ nhìn vào số lượng. Cách duy nhất có thể gây thiệt hại cho họ là trả về 0 byte
Chỉ cần làm bằng một phần mười những gì Sam Altman đã phê duyệt, người bình thường đã vào tù ngay
https://zadzmo.org/code/nepenthes/
Sẽ tốt nếu Amazon tặng chút credit AWS như một cử chỉ thiện chí để bù phần traffic outbound vượt mức do Amazon và các bot khác gây ra. Dù vậy có lẽ doanh thu quảng cáo từ bài viết này sẽ bù được. Tắt adblock là hòa vốn
Trước khi chặn bằng Nginx, Bytespider chiếm 59% và Amazonbot chiếm 21%; cộng lại, hai bot này chiếm 80% tổng lưu lượng truy cập vào máy chủ Git của chúng tôi
Trong một tháng, ClaudeBot đã gửi nhiều lưu lượng truy cập tới Redmine hơn tổng lưu lượng của 5 năm trước khi có ClaudeBot