Nếu có vấn đề thì hãy chặn ở cấp IP
(boston.conman.org)- Gần đây khi phân tích lưu lượng web, tác giả phát hiện một web bot tên Thinkbot tạo ra lượng truy cập lớn nhất
- Bot này phớt lờ
robots.txt, và cả câu tự giới thiệu cũng rất hời hợt, đại loại là “nếu có vấn đề thì cứ chặn IP” - Trong một tháng, nó đã sử dụng 74 địa chỉ IP khác nhau, phân tán trên 41 khối mạng
- Kết quả điều tra cho thấy toàn bộ các khối mạng này đều thuộc sở hữu của Tencent, làm dấy lên nghi ngờ rằng điều này có liên quan đến khả năng chuyển chi phí của Great Firewall sang bên khác
- Cuối cùng, tác giả đã thêm các quy tắc chặn quy mô lớn bao phủ hơn khoảng 470 nghìn IP
Sự xuất hiện của Thinkbot
- Trong lúc phân tích lưu lượng web, tác giả phát hiện web bot mang tên Thinkbot chiếm tỷ lệ rất cao
- Chuỗi User-Agent của nó thiếu thiện chí như sau
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- Ngoài câu “nếu gây rắc rối trong giai đoạn thử nghiệm thì hãy chặn IP”, thậm chí không có cả URL tham chiếu
- Nó hoàn toàn không tôn trọng tệp
robots.txtvà vẫn tiếp tục crawl - Ngay cả khi muốn chặn với tư cách quản trị website, tác giả cũng không thể xử lý bằng một IP đơn lẻ vì bot dùng tới 74 địa chỉ IP
- Sau khi lần ngược và tra cứu ASN, tác giả xác nhận lưu lượng này đến từ 41 khối mạng
- Điều đó có nghĩa là không thể phòng thủ chỉ bằng cách chặn một IP riêng lẻ
Liên quan đến Tencent
- Cả 41 khối mạng này đều thuộc sở hữu của Tencent
- Tác giả nghi ngờ chính phủ Trung Quốc có thể đang làm ngơ hoặc khuyến khích điều này, và có thể hiểu đây là một nỗ lực chuyển chi phí của Great Firewall sang phần còn lại của thế giới
- Trong nội địa Trung Quốc, việc thu thập nội dung được cho phép; còn dù có bị chặn từ bên ngoài thì từ góc nhìn của CCP cũng không thành vấn đề, nhưng điều đó lại tạo gánh nặng cho các quốc gia và website khác khi cố gắng ngăn chặn
Biện pháp chặn bằng tường lửa
- Tác giả đã trực tiếp thêm các khối mạng của Tencent vào quy tắc tường lửa badbots
- Ví dụ:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19v.v. - Tổng cộng đã thêm hơn 40 khối mạng; dù chưa bao phủ toàn bộ IP do Tencent sở hữu, chúng vẫn chứa hơn 476.590 IP duy nhất
Kết luận và phép ví von
- Tác giả mô tả tình huống này như một thực tế rằng “trên Internet, chúng ta không còn có thể giữ được những điều tốt đẹp nữa”
- Đây không chỉ là một ca chặn lưu lượng bot đơn thuần, mà còn cho thấy sự suy giảm niềm tin trên toàn bộ hệ sinh thái Internet và phản ứng phòng thủ mang tính tất yếu
6 bình luận
Thực ra, luận điệu về mối đe dọa từ Trung Quốc ở các lĩnh vực khác đã trở thành hiện thực từ lâu rồi, và giờ có vẻ như Trung Quốc bắt đầu đe dọa cả sự tồn tại tổng thể của hệ sinh thái Internet.
Đây không phải lời nói đơn thuần xuất phát từ tâm lý thù ghét hay thiên kiến chính trị, mà dường như nhiều người cần nhận ra rằng nó đang thực sự trở thành hiện thực.
Sao lần nào mổ xẻ những vụ việc kiểu này ra cũng lại là CCP..
Wow.. đúng là đỉnh thật..
Đỉnh..
Lại là Trung Quốc nữa rồi.
Ý kiến Hacker News
Khi phát triển một web crawler, tôi đã cố gắng làm nó thân thiện nhất có thể. Tôi kiểm tra
robots.txtrất nghiêm ngặt, crawl chậm, ghi rõ danh tính trong chuỗi User Agent và chỉ dùng một địa chỉ IP duy nhất. Thế nhưng tôi lại gặp đủ kiểu mánh chống bot áp dụng ngay với chính filerobots.txt. Gần đây,robots.txttải xuống chậm khủng khiếp như một cuộc tấn công slow loris, khiến tôi vô tình coi nó là 404 rồi tiếp tục crawl. Sau trải nghiệm đó, tôi đã đổi code để khi timeout thì coi nhưDisallow /. Trớ trêu là dù cố tuân thủ quy tắc, cuối cùng vẫn phải viết code để phát hiện công cụ anti-botTôi thấy chuyện này giống như giấu chuông cửa để ngăn trộm
Cũng giống như ở ứng dụng server, phía client tôi sẽ lặng lẽ ngắt kết nối TCP nếu bên kia có hành vi ác ý hoặc sai chuẩn. Bên đó sẽ phải tự lãng phí tài nguyên một lúc rồi mới tự nhận ra chuyện gì đang xảy ra
Tôi nghĩ rất có thể hiện tượng này không phải cố ý. Các bot xấu vốn không tuân thủ quy tắc
robots.txtthì ngay từ đầu cũng chẳng tải file đó, nên đây có thể là lỗi hoặc sự kém năng lực hơn là ác ýCác biện pháp trừng phạt chỉ nhắm vào những người cố gắng tuân thủ quy tắc thì ngược lại còn phản tác dụng
Tôi đánh giá cao việc bạn cố gắng tuân thủ quy tắc. Việc hạn chế
robots.txtcó thể là nhầm lẫn, nhưng một số crawler lại tìm ra những trang thú vị hơn từrobots.txt, nên làm chậm nó có thể giúp né vấn đề nhanh chóng. Rốt cuộc cách này chặn thông tin của bot và làm bot chậm lại; từ góc nhìn của người vận hành site, vì đang bị bot xấu gây hại nên họ khó mà bận tâm phân biệt bot tử tế với bot không tử tếTôi tò mò không biết các website bị bot gây thiệt hại nặng thường có điểm chung gì. Tôi đã chạy web server tại nhà nhiều năm với TLD
.com, cũng có thứ hạng tìm kiếm Google khá cao ở các từ khóa liên quan, và không hề cấu hình chặn bot đặc biệt nào trên router hay server. Có lần tôi đếm riêng request của bot vì tò mò, nhưng phần lớn chỉ là quét cổng hoặc lấy trang index, gần như không theo các liên kết tải động. Từ thời Apache 2 cho tới hiện tại khi tôi vận hành nhiều site bằng Axum, tôi không thấy ảnh hưởng rõ rệt nào do bot gây ra. Có lẽ là vì directory listing chăng, tôi rất muốn nghe lời giải thíchTôi có cảm giác nhiều người rất thông minh đang bị ám ảnh quá mức với vấn đề web scraping. Trừ khi hoạt động của bot thực sự gây tải cực lớn hoặc vấn đề nghiêm trọng cho site của bạn thôi, còn không thì phần lớn chỉ là một trò “cướp cờ” vô nghĩa. Khác biệt ở đây là rốt cuộc bạn không tìm được cờ của đối phương, mà chỉ mất thời gian. Tôi nghĩ cách xử lý tốt nhất là xây dựng một sản phẩm web nhanh và được thiết kế tốt, đủ sức chịu được những người tham gia phân tán, khó nhận diện ngay cả khi họ gây tải. Thực tế, cách tiếp cận này còn cải thiện đáng kể mức độ hài lòng của người dùng thật
Theo kinh nghiệm của tôi thì có thể bạn chưa biết mức độ nghiêm trọng của vấn đề này. Ở công ty cũ, tôi từng phụ trách hiệu năng ứng dụng cho web app, và một số người dùng thì nhanh như chớp nhưng đa số lại rất chậm. Khi phân tích log hiệu năng, tôi phát hiện 60% tổng request là từ bot đã biết đến danh tính, chưa tính các bot vớ vẩn khác. Thậm chí một vài công ty còn gây ra các cuộc tấn công DoS vào dịch vụ, từng có lúc làm site sập. Vấn đề là bot luôn chỉ lấy phản hồi đã cache, khiến các cuộc hội thoại của người dùng thật liên tục bị đẩy khỏi cache LRU. Có bot scrape lại mọi trang đã ghé qua sau mỗi vài phút, có bot thì cứ tăng throughput cho đến khi dịch vụ chậm hẳn mới thôi. Đôi khi chúng còn cố chạy JavaScript và submit form. Googlebot là bot duy nhất cư xử lịch sự. Ngay cả lưu lượng truy cập thật sự thì 40% cũng chỉ dồn vào đúng một URL, nên lợi ích từ bot gần như bằng không. Về sau tôi mới nhận ra nhiều bot trong số đó phục vụ việc thu thập dữ liệu của các công ty AI thời kỳ đầu
Một người bạn của tôi đang vận hành một instance gitea nhỏ, công khai, chỉ để dùng giữa bạn bè. Thế mà mỗi giờ vẫn nhận hàng nghìn request từ bot. Dù không ảnh hưởng trực tiếp tới dịch vụ, ít nhất nó vẫn tạo cảm giác như bị quấy rối
Tôi trả tiền cao để lấy dữ liệu nhằm tạo ra sản phẩm web nhanh. Vì vậy khi chặn các thực thể như vậy, đó không phải lãng phí thời gian mà là tiết kiệm được băng thông và chi phí server thật sự. Nhờ đó khách hàng thật của tôi cũng được hưởng cùng lợi ích mà không hề bị bất tiện vì nội dung bị scrape. Tôi không hiểu được logic cho rằng mình đang bị ai đó bóc lột
Tôi nghĩ nó giống trò đập chuột chũi hơn là “cướp cờ”. Theo trải nghiệm cá nhân, trong các diễn đàn cố nhận diện và chặn “bot xấu”, lúc nào cũng có thêm bot mới xuất hiện, không bao giờ kết thúc
Đúng là trong chúng ta có nhiều người thông minh, nhưng cũng có xu hướng ám ảnh quá mức với các vấn đề kỹ thuật. Nếu không làm gì thì chuyện đó cứ gây khó chịu mãi, còn ít nhất chặn chúng lại thì cảm giác bớt bực hơn
Tôi luôn ngạc nhiên vì có nhiều người trên Hacker News xem
robots.txtmột cách nghiêm túc hơn tôi tưởng. Thật ấn tượng khi có nhiều người có thiện chí đến vậy. Nhưngrobots.txtkhông phải giải pháp thực chất. Người ta phải biếtrobots.txtlà gì, rồi còn phải thêm code kiểm trarobots.txtvào crawler, nên độ phức tạp tăng lên. Tôi tò mò không biết có giải pháp thực tiễn nào khác không. Những thứ như “micropayment” hay “cây Merkle khổng lồ để xác minh danh tính thật” đã được nhắc tới từ lâu, nhưng chưa từng được triển khai thực tếTôi nghĩ gần như không có nhà phát triển bot nào là không biết
robots.txt. Chỉ là có những người tự cho rằng dự án của mình là trường hợp đặc biệt nên được quyền phớt lờ quy tắc chungrobots.txtkhông có hiệu lực cưỡng chế về mặt pháp lýTrong log của chúng tôi cũng thấy các mẫu bot như vậy. Khá khó chịu, nhưng ít ra chúng còn tự nhận là bot và lưu lượng thật sự không nhiều. Phần lớn traffic lại đến từ các bot giả làm trình duyệt thật, hoặc từ nhiều IP ở Brazil và châu Á. Tuần vừa rồi tôi đã thử đủ mọi cách để chặn bot, nên chia sẻ vài kinh nghiệm có thể hữu ích.
Request đến từ hàng trăm IP, nhưng mỗi IP chỉ vài lần mỗi ngày, và tất cả đều giả danh UA thật
Chúng hầu như không gửi URL referrer, nhưng bot của Huawei Cloud thì có gửi referrer đôi lúc dù traffic không nhiều
Thử nghiệm chính là giới hạn băng thông (1Kb/s) cho URL có chứa
id=, hy vọng khi chậm đi chúng sẽ bỏ cuộc, nhưng bot chẳng quan tâm và vẫn tiếp tục requestChúng cũng thích nghi với kết nối keep-alive, nên tôi tắt hẳn keep-alive trên
/cgit/, nhưng chúng vẫn chiếm hết kết nốiCách hiện tại là chỉ cho phép URL có
id=nếu có chuỗi truy vấnnotbot; nếu không có referrer thì trả về 403 kèm hướng dẫn rằng nếu là người dùng hợp lệ thì hãy thêm tham sốnotbot. Cách này giúp giảm tải và cải thiện kết nối cho người dùng hợp lệ, nhưng bot vẫn cứ request và chỉ tiếp tục nhận 403Kết luận là có lẽ chỉ còn hai cách: dùng các biện pháp ad hoc chuyên biệt cho từng site, hoặc giao cho những nơi có đủ tài nguyên như Cloudflare xử lý. Các giải pháp chặn bot tiêu chuẩn đều có giới hạn vì bên có nhiều tài nguyên có thể lách qua hoặc chịu được chi phí đó
Cũng có thể chặn sớm bằng 403 với các UA substring hiếm gặp như MSIE 3.0 hay HP-UX. Sau đó gom log 403 lại để chặn riêng các ASN gây vấn đề, rồi tiếp tục trò đập chuột chũi
Tôi dùng phần mềm thuộc họ Bernstein publicfile của djbwares. Tôi cũng thêm công cụ static GEMINI UCSPI-SSL, và dựa trên ý tưởng từ spec GEMINI để cấm toàn bộ fragment và query parameter trong URL request. Lý do cũng giống như trong GEMINI, và hoàn toàn áp dụng được cho dịch vụ HTTP tĩnh. Theo cấu hình server của tôi, nếu muốn xử lý query parameter tử tế thì phải tạo riêng nhiều tên file kỳ lạ, điều này không thực tế. Nhờ ý tưởng đó, các nỗ lực tấn công vào lỗ hổng CGI hay PHP thậm chí không chạm được tới filesystem, mà bị chặn ngay ở bước phân tích request. Với người vận hành site tĩnh, tôi khuyên nên chặn cả query parameter như GEMINI. Tất nhiên nếu trong nhóm site tĩnh mà bạn thực sự muốn dùng query parameter thì đó là ngoại lệ
Từ lúc nào đó tôi đã tự hỏi liệu cách làm whitelist theo dải IP có thực sự khả thi không. Tôi cũng hình dung tới cách cộng đồng cùng nhau duy trì nó giống như danh sách adblock
Không may là bot cư xử tốt thường lại dùng IP ổn định, còn kẻ xấu thì có thể dùng proxy dân dụng bất cứ lúc nào. Nếu cấm IP proxy dân dụng thì người dùng thật bị ảnh hưởng, còn kẻ xấu chỉ việc đổi sang nơi khác. Từ kinh nghiệm thực tế phải đối mặt với hàng nghìn IP, tôi thấy chỉ dựa vào thông tin IP thì khó kết luận và cần thêm tín hiệu khác
Công ty Pokémon Go cũng từng thử cách này để chặn scraping ngay sau khi ra mắt. Họ chia IP thành ba loại: blacklist (Google Cloud, AWS, v.v.), IP không đáng tin (dân dụng) và whitelist (IPv4 bình thường, v.v.). Ban đầu họ có chặn được các scraper chính, nhưng scraper lớn nhất lại lách bằng cách vận hành cả một trại modem đầu cuối. Kết quả là người dùng bình thường bỏ game vì không có bản đồ, còn người chơi hardcore thì lại trả tiền để dùng scraper nhiều hơn. Cuối cùng server còn chịu tải lớn hơn. Tôi xem đây là một trong nhiều quyết định tệ mà Pokémon Go từng đưa ra
Nhiều công ty Mỹ đã làm vậy rồi. Nhưng nếu họ vẫn tiếp tục thu phí mà không cung cấp cách hủy dịch vụ khi bạn đang ở nước ngoài, thì điều đó là vô lý
Whitelist và blacklist không nhất thiết phải chọn một cách nhị phân. Phần lớn traffic nằm trong vùng xám. Nếu một IP nào đó đã được đưa vào whitelist mà bị phát hiện có dấu hiệu bất thường, thì phải gỡ khỏi whitelist, thông báo, nhận phản hồi và điều phối cho đến khi xác nhận sự cố đã được giải quyết — điều này cực kỳ phức tạp trong thực tế. Whitelist chỉ hiệu quả giữa các đối tác có quan hệ tin cậy. Blacklist hữu ích để chặn các địa chỉ nhiều vấn đề, hoặc CIA, Nga, Trung Quốc hay các nhà cung cấp cloud. Cách thực tế là chỉ whitelist những nơi như host dùng nội bộ doanh nghiệp, nơi có hệ thống chống lạm dụng đủ vững chắc
Tôi đang xây dựng một whitelist bot tích cực thông qua dự án mã nguồn mở GoodBots. Rất hoan nghênh PR
Tôi dùng cách thêm custom header vào mọi request gửi đi, rồi chặn tất cả request khác
Bên ngoài thì dùng proxy Cloudflare, còn bên trong đặt Crowdsec và Modsecurity CRS trước Traefik. Sau khi tinh chỉnh để giảm false positive, hệ thống chạy rất ổn định. Các IP bị chặn tạm thời và các IP được report sẽ được gửi vào Crowdsec, rồi log lên một kênh Discord. Trung bình mỗi ngày tôi chặn vài chục IP khác nhau. Theo cảm nhận của tôi, các nỗ lực truy cập tài nguyên riêng tư hoặc nhắm vào CVE thì IP Mỹ còn nhiều hơn IP Trung Quốc rất nhiều. Tôi không bận tâm tới chuyện crawl nội dung công khai, còn mọi thứ khác đều chỉ có thể truy cập qua SSO hoặc intranet. Chặn riêng một số quốc gia kém hiệu quả hơn việc chỉ chặn các nỗ lực exploit hoặc flood
Cách làm kiểu Crowdsec hấp dẫn thật, nhưng tôi thấy việc giao toàn bộ traffic của server cho một công ty vì lợi nhuận là rủi ro lớn
Những nỗ lực tấn công nghiêm trọng thì cuối cùng cũng sẽ bị chặn sẵn ở những nơi như Cloudflare WAF thôi
Nhiều tòa nhà chung cư chỉ có thể đi ra ngoài Internet bằng một vài địa chỉ IP (Carrier-grade NAT tham khảo)
Hơn một nửa traffic của tôi là từ bot của Bing, Claude và Facebook. Chúng không phải nguồn traffic chính, nhưng lại ngốn tài nguyên server và là nguyên nhân lớn khiến site chậm đi (AI, Microsoft và Facebook nhiều khi còn bỏ qua cả lẽ thường). Trung Quốc và những nơi khác chỉ là một phần của traffic ác ý; vấn đề thực sự là các công ty Mỹ phớt lờ
robots.txthoặc giới hạn tốc độ DNS