- Tác giả vận hành Spigot, một trình tạo cấu trúc phân cấp trang web giả, và phơi bày các trang được tạo ngẫu nhiên trước những trình thu thập web hung hăng
- Gần đây, tác giả phát hiện trình thu thập hình ảnh đang tập trung rà quét trang để tìm ảnh jpg
- Để xử lý việc tạo ảnh theo thời gian thực với mức dùng CPU tối thiểu, tác giả đề xuất dùng phần có cấu trúc của tệp JPEG thật làm mẫu, rồi chèn dữ liệu ngẫu nhiên vào phần đã nén
- Kết quả thử nghiệm cho thấy JPEG được tạo theo cách này dù có lỗi vẫn có thể được đa số trình xem ảnh hiển thị, và cũng đủ giống thật đối với crawler
- Cách làm này ít tiêu tốn tài nguyên máy chủ nhưng lại tạo gánh nặng cho crawler, và đã được áp dụng cho khoảng 60% số trang của Spigot
Bối cảnh của Spigot và việc giả mạo JPEG
- Spigot tạo cấu trúc phân cấp trang web giả theo thời gian thực dựa trên Markov Chain để cung cấp dữ liệu vô nghĩa cho các trình thu thập web hung hăng
- Một số crawler dùng chữ ký trình duyệt ngẫu nhiên và IP để che giấu danh tính, cho thấy khả năng lạm dụng trái phép các thiết bị qua botnet
- Thông qua phân tích lưu lượng, tác giả xác nhận một crawler mới tên là "ImageSiftBot" đang yêu cầu dồn dập các trang Spigot để thu thập hình ảnh
- Mục tiêu chính của Spigot là giảm thiểu mức sử dụng CPU trên máy chủ và duy trì hoạt động hiệu quả
Bài toán tạo ảnh giá rẻ
- Việc tạo ảnh động tiêu tốn nhiều CPU do nén, nên cần một phương pháp hiệu quả hơn
- Tác giả chú ý rằng tệp JPEG gồm phần cấu trúc của tệp (kích thước, màu sắc, v.v.) và vùng dữ liệu pixel đã nén
- Từ nhiều tệp JPEG, tác giả chỉ trích xuất thông tin header có cấu trúc, rồi điền vùng dữ liệu pixel bằng dữ liệu ngẫu nhiên
- Nhờ vậy có thể tạo ảnh ngay tại chỗ mà không cần nén lại mỗi lần, giúp giảm tối đa gánh nặng cho máy chủ
Cấu trúc tệp JPEG và cách triển khai thực tế
- Tệp JPEG gồm nhiều chunk (có marker và độ dài)
- Giữ lại header/thông tin meta, chỉ ghi lại độ dài của dữ liệu pixel đã nén → rồi chèn dữ liệu ngẫu nhiên vào đúng vùng này
- Khi dùng 514 mẫu JPEG, toàn bộ header và dữ liệu có cấu trúc cần thiết chỉ khoảng 500KB, nên gần như không tạo gánh nặng bộ nhớ
- Ví dụ mã: tạo ảnh bằng cách điền số ngẫu nhiên vào chunk dữ liệu pixel của từng mẫu
Kết quả sử dụng thực tế và công bố mã nguồn mở
- Các trình xem ảnh thực tế vẫn có thể hiển thị hình ở mức độ nhất định ngay cả khi vùng pixel là ngẫu nhiên hoàn toàn
- Trình thu thập web khó nhận diện lỗi, và chi phí thu thập dữ liệu của chúng sẽ tăng lên
- Với JPEG kích thước 1280x960, dung lượng 200~300KB, có thể tạo khoảng 900 ảnh mỗi giây, đủ nhẹ cho xử lý thời gian thực
- Phương pháp này đã được áp dụng cho 60% tổng số trang của Spigot; dùng seed ngẫu nhiên dựa trên URL để trả về cùng một ảnh khi được yêu cầu lại
- Quan sát thấy lưu lượng yêu cầu lớn từ ImageSiftBot, Meta, AmazonBot, GPTBot, v.v.
- Mục tiêu cốt lõi là dùng ít tài nguyên máy chủ để tăng gánh nặng cho crawler
Mã Huffman và tối ưu hóa bổ sung
- Dữ liệu pixel của JPEG dùng mã hóa Huffman, nên nếu chèn dữ liệu ngẫu nhiên hoàn toàn thì một số trình xem có thể phát sinh lỗi
- Tác giả thêm kỹ thuật bit masking đơn giản (
0x6D) để tránh xuất hiện 3 bit 1 liên tiếp trở lên, từ đó giảm xác suất phát sinh mã Huffman sai từ 90% xuống dưới 4%
- Có thể tạo ra một luồng Huffman hoàn toàn hợp lệ, nhưng lợi ích không đáng kể so với tài nguyên máy chủ và thời gian phát triển bỏ ra
Kết luận
- Cách tạo JPEG giả của Spigot giúp tiết kiệm tài nguyên máy chủ với hiệu quả vượt trội, đồng thời gây nhiễu và làm lãng phí tài nguyên của crawler
- Mã liên quan dài chưa tới 100 dòng và đã được công khai trên GitHub
- Đây là một kỹ thuật phòng vệ/phân tán lưu lượng web đơn giản nhưng sáng tạo
1 bình luận
Ý kiến Hacker News
Việc tệp robots.txt chặn quyền truy cập của robot vào cây /spigot/ là điều đã đoán trước, nhưng rồi lại phát hiện rằng chỉ cần bỏ /spigot/ khỏi URL thì vẫn có thể truy cập Spigot, và vì không gian tên /~auj không bị robots.txt chặn, nên ngay cả crawler thiện chí cũng có thể vô tình rơi vào vòng lặp trang vô hạn nếu truy cập đường dẫn đó, đây không phải tình huống dễ chịu gì tham khảo robots.txt
Trước đó trong bình luận của tác giả có nói rằng họ không cấu hình robots.txt riêng, và về lựa chọn cực đoan này, họ cho biết không thích ý niệm rằng quản trị viên website phải cố tình thiết lập gì đó để ngăn DOS do crawler gây ra, quan điểm là crawler tử tế thì không nên liên tục cào một site quá 15 lần mỗi giây
Về điểm ngay cả crawler thiện chí cũng rơi vào vòng lặp trang vô hạn, có ý kiến hoài nghi về việc quản trị viên website có nghĩa vụ phải “thân thiện” với người đi scrape website hay không, không chắc là điều đó bắt buộc
Nếu có thể nhận diện crawler phớt lờ robots.txt, thì việc giữ chiếm kết nối mạng và bỏ mặc có vẻ hiệu quả hơn là trả về dữ liệu “rác”, không rõ vì sao lại cần cung cấp rác vô hạn ở endpoint
Có ý tưởng rằng để gây nhiễu scraper dùng làm đầu vào cho AI, có thể gắn chú thích giả cho từng ảnh, ví dụ với ảnh là một mảng màu xanh thì ghi "một con mèo đang chơi với quả bóng catnip", còn ảnh màu xanh dương thì ghi "một con chim cổ đỏ đang làm tổ" theo kiểu như vậy
Trường hợp tệ nhất là bot facebookexternalhit do meta (Facebook) vận hành, thậm chí còn được tài liệu hóa chính thức là bot này bỏ qua robots.txt, Facebook nói là để phát hiện liên kết độc hại, nhưng trên thực tế nếu người dùng xấu cứ liên tục gửi URL của endpoint đắt đỏ lên Facebook, thì Facebook sẽ thành bên ném bom lưu lượng thay họ, vì vậy mỗi tháng có vài ngày site bị dội traffic hơn 10 r/s suốt cả ngày
Đọc bài về Spigot làm nhớ đến Project Honeypot, 20 năm trước mỗi lần nhận email nói rằng script của dự án này và bản ghi MX mình đóng góp đã giúp bắt được kẻ thu thập email trên site của mình thì thấy rất phấn khích, ví dụ như được báo là nhờ MX của mình mà họ đã bắt được một spammer chưa xác minh (IP: 172.180.164.102)
Làm giả JPEG tốn CPU ít hơn rất nhiều so với tạo JPEG đúng chuẩn, hơn nữa bản thân quá trình này còn có thể đóng vai trò như một kiểu fuzzing khiến phía malware đối phương bị crash nếu phần giải mã JPEG của họ làm ẩu
Việc lưu lượng truy cập gần đây đến từ hàng nghìn IP dân dụng không nhất thiết có nghĩa đó là botnet điển hình, mà có thể là cấu trúc “proxyware”, nơi nhiều người đăng ký “VPN miễn phí” hoặc công cụ “tạo thu nhập thụ động”, rồi thiết bị của họ trở thành nút thoát lưu lượng cho người khác, trong trường hợp này họ có thể vô tình trở thành đường trung chuyển cho traffic của AI crawler tài liệu liên quan
Suy cho cùng loại proxyware này cũng là một biến thể botnet mà người dùng tự nguyện tham gia, mà những người đó khó có khả năng vào nơi như HN để biết IP của mình đang có vấn đề, nên cũng có ý rằng ai đó dẫn riêng các IP đó tới một trang cảnh báo kiểu “bạn là một phần của botnet” thì cũng ổn, nhưng thực tế thì chặn thẳng tay vẫn là tiện nhất
Có ý kiến cho rằng kiểu này hoàn toàn vẫn đủ để xếp vào phạm trù botnet
Cách bài viết nói về việc làm hài lòng bot khá ấn tượng, bài rất vui và dự án cũng thú vị
Thái độ kiểu “thấy tội nghiệp con bot đang vật lộn với nhiệm vụ được giao nên nghĩ cách làm nó vui lên” nghe rất mới mẻ và thú vị, khác hẳn những luồng thảo luận thường đầy giận dữ hay phàn nàn
Thích kết quả (hình ảnh) ở liên kết này xem ảnh, nó mang cảm giác như một tác phẩm nghệ thuật có thông điệp
Nếu muốn trải nghiệm Spigot đúng nghĩa, trong Firefox có thể vào F12 > Network > đổi No Throttling thành GPRS, còn trong Chromium thì vào F12 > Network > tạo Custom profile 20kbps để giới hạn tốc độ cho chân thực
Không biết ở đây có cả nội dung liên quan đến Shakespeare không