Nếu muốn web scraping như các tập đoàn lớn (2021)
(incolumitas.com)- Chỉ với AWS Lambda và Headless Chrome cũng đã có thể thu thập hàng triệu Google SERP mỗi tuần, nhưng trước các trang được bảo vệ chặt chẽ, kiến trúc bot dựa trên cloud dễ nhanh chóng chạm giới hạn
- Bằng cách gọi lại Lambda và tận dụng nhiều region, với 16 region có thể đồng thời dùng khoảng
16 * 250 = 4000IP công khai, đủ cho các mục tiêu được bảo vệ lỏng lẻo - Các hãng chống bot như DataDome, Akamai, Imperva theo dõi sự không nhất quán trong cấu hình trình duyệt, dấu vết tự động hóa và thông tin fingerprint; bài toán thực sự gần với việc giảm tỷ lệ dương tính giả hơn là bản thân việc phát hiện
- Đề xuất một kiến trúc ít bị phát hiện hơn: dùng thiết bị Android thật và IP di động thay vì Docker hay server cloud; IP 4G/5G/LTE được nhiều người dùng hợp lệ ở các đô thị lớn chia sẻ nên khó chặn
- Trang trại thiết bị thật phải chấp nhận việc mua thiết bị, thuê mặt bằng theo thành phố, bảo trì tại chỗ và lỗi phần cứng; Android emulator cũng vẫn có rủi ro bị phát hiện là mô phỏng
Kiến trúc scraping quy mô lớn xây bằng AWS Lambda
- Khi vận hành một dịch vụ scraping trước đây, tác giả từng thu thập tối đa hàng triệu Google SERP mỗi tuần, nhưng không dùng các nhà cung cấp proxy như Brightdata, Packetstream hay Oxylabs
- Cho rằng khó tin tưởng các khách hàng khác cùng chia sẻ băng thông proxy
- Scraping không DoS đối với thông tin công khai thì chấp nhận được, nhưng vạch ranh giới với gian lận quảng cáo, spam mạng xã hội, SQL injection tự động, XSS và các kiểu tấn công web tương tự
- Chi phí dịch vụ proxy cũng là một gánh nặng
- Cấu hình thực tế là một function chạy trình duyệt trong 300 giây, đưa Headless Chrome vào AWS Lambda và dùng puppeteer-extra cùng chrome-aws-lambda
- Google không chặn bot quá mạnh đối với công cụ tìm kiếm của chính mình mà chủ yếu áp dụng giới hạn tốc độ theo IP, nên nếu chỉ xét Google SERP thì có lẽ dùng
curlcũng có thể làm được - Trên Lambda, sau 3 lần gọi function sẽ nhận được IP công khai mới; khi gọi đồng thời 1000 function thì đạt khoảng 250 IP công khai
- Tính ra nếu dùng 16 region thì có thể sử dụng đồng thời khoảng
4000IP công khai - Dù là IP trung tâm dữ liệu dùng chung, như vậy vẫn đủ để thu thập hàng triệu Google SERP mỗi tuần
- Tính ra nếu dùng 16 region thì có thể sử dụng đồng thời khoảng
- Google Cloud Platform cũng đã được thử, nhưng Google chặn traffic từ hạ tầng cloud của chính họ mạnh hơn traffic từ AWS
- Trải nghiệm này dựa trên giai đoạn 2019 và 2020; tình hình sau đó có thể đã thay đổi
Vì sao bot trên cloud bị chặn
- Kiến trúc dựa trên Lambda có thể hoạt động với các mục tiêu cho phép scraping ở một mức độ nào đó như Google, Bing, Amazon, nhưng không phù hợp với các trang áp dụng bảo vệ mạnh
- Các hãng chống bot như DataDome, Akamai, Imperva tìm kiếm fingerprint trình duyệt, sự không nhất quán trong cấu hình và các dấu vết khác với trình duyệt do con người điều khiển
- Ví dụ về kỹ thuật phát hiện rất đa dạng
- Browser Red Pills
- Browser Based Port Scanning
- Google Picasso
- Font Fingerprinting
- TLS Fingerprinting
- WebGL Fingerprinting
- Phát hiện IP thật qua WebRTC
- Behavioral Classification
- Truy vấn Gyroscope API
- Fingerprinting bằng HTTP header, CSS feature query và font mà không cần JavaScript
- Có rất nhiều cách phát hiện bot, và gần như mọi kiến trúc bot đều dễ bị phát hiện ở một mức nào đó
- Bên tạo bot khó hơn bên phát hiện; thách thức lớn hơn của các hãng chống bot gần với việc giảm tỷ lệ dương tính giả hơn là bắt được phần lớn bot
Cấu trúc kinh tế dễ bị phát hiện
- Các nhà phát triển bot muốn scraping quy mô lớn thường đặt trình duyệt vào container Docker rồi orchestration bằng Docker Swarm hoặc Kubernetes
- Những bot như vậy thường được host trên các nhà cung cấp cloud như Hetzner, AWS, DigitalOcean
- Kiến trúc này rất khác môi trường của người dùng thật
- Việc người dùng bình thường duyệt Instagram trong container Docker trên một Hetzner VPS là tình huống không tự nhiên
- Đưa ra hai quy tắc để scraping thành công
- Quy tắc quan trọng thứ hai: đừng nói dối về cấu hình trình duyệt
- Quy tắc quan trọng nhất: chỉ nói dối về cấu hình trình duyệt khi sẽ không bị phát hiện
Trang trại thiết bị Android thật
- Vì khó reverse engineering các thư viện fingerprint chống bot đã bị obfuscate, tác giả đề xuất cách tiếp cận dùng thiết bị thật để scraping
- Kiến trúc giả định là mua 500 thiết bị Android giá rẻ và trộn thiết bị từ khoảng 5 nhà sản xuất để đa dạng fingerprint
- Thiết bị Android giá rẻ bắt đầu từ 58 USD mỗi chiếc
- Cho rằng nếu mua 100 chiếc một lần có thể nhận được chiết khấu lớn
- Gắn cho mỗi thiết bị một gói dữ liệu rẻ và điều khiển bằng DeviceFarmer/stf
- Ý tưởng là đặt mỗi nơi 100 thiết bị tại 5 thành phố lớn như London, Paris, Boston, Frankfurt, Los Angeles, và thuê không gian lưu trữ giá rẻ gần ăng-ten di động
- Cài Android Go nhẹ lên thiết bị, loại bỏ các thành phần không cần thiết rồi cắm nguồn
- Nếu bật rồi tắt chế độ máy bay mỗi 5 phút, có thể nhận IP mới thông qua 4G Carrier Grade NAT
- Địa chỉ IP di động được tối đa hàng trăm nghìn người dùng hợp lệ ở các đô thị lớn chia sẻ, nên trên thực tế rất khó chặn
- Ví dụ, cho rằng Instagram sẽ không chặn 200.000 người ở LA chỉ vì một số người dùng spam
- Trích dẫn tài liệu của Ofcom nói rằng nếu một địa chỉ IPv4 trong CGN bị chặn, toàn bộ cơ sở thuê bao có thể bị ảnh hưởng
- Với IPv6, không gian địa chỉ quá rộng nên hầu hết các hãng chống bot gần như không gán, hoặc không hề gán, uy tín IP cho địa chỉ IPv6
Điểm có thể bị phát hiện và gánh nặng vận hành của kiến trúc thiết bị thật
- Nếu để thiết bị thật nằm trên sàn cả ngày, trạng thái không xoay hoặc không chuyển động sẽ kéo dài, nên cần spoof các sự kiện JavaScript
deviceorientationvàdevicemotionở cấp kernel- Website có thể truy cập dữ liệu xoay và gia tốc của Android mà không cần xin quyền
- Ngoài vấn đề này, tác giả cho rằng chưa rõ hệ thống phát hiện bot có thể chặn kiến trúc đó bằng cách nào
- Gánh nặng vận hành không nhỏ
- Phải mua 500 thiết bị Android
- Phải thuê không gian lưu trữ ở các thành phố lớn và tốn chi phí
- Cần người sửa sự cố trang trại thiết bị ở 5 thành phố
- Phải xử lý phần cứng và các vấn đề có thể liên tục phát sinh
- Kiến trúc như vậy trở thành một dự án lớn, và chi phí bảo trì có thể lên tới hàng nghìn USD
Android emulator như một phương án thay thế
- Cho rằng dùng Android emulator thay cho thiết bị Android thật có lẽ tốt hơn
- Có thể giảm chi phí, nhưng các hãng chống bot có thể phát hiện môi trường mô phỏng
- Có nhiều cách phát hiện có thể xảy ra
- Red pill dựa trên trình duyệt có thể làm lộ việc trình duyệt đang chạy trong môi trường mô phỏng
- Quét cổng dựa trên trình duyệt có thể tìm các cổng hoặc dịch vụ như
adbchỉ chạy trên thiết bị Android được mô phỏng - Google có thể đặt ID quảng cáo trên toàn bộ thiết bị di động; nếu ID này không có hoặc luôn giống nhau thì có thể là tín hiệu đáng ngờ
- Social Media Login Detection có thể kiểm tra trạng thái đăng nhập tài khoản Gmail hoặc YouTube; trên Android, nếu không đăng nhập tài khoản Google thì có thể bị xem là đáng ngờ
- Ngoài ra có thể còn nhiều kỹ thuật phát hiện thiết bị Android được mô phỏng khác
- Android emulator có khả năng cao là không hoàn hảo, và sự không hoàn hảo đó có thể lộ ra qua lượng JavaScript API khổng lồ của trình duyệt di động
- Dù vậy, tác giả vẫn ưu tiên cách tiếp cận mô phỏng và đề xuất cấu hình kết nối vài server mạnh với các 4G dongle
- proxidize.com cung cấp proxy di động 4G, nhưng vì bản thân proxy cũng có thể bị phát hiện, tác giả muốn dùng trực tiếp 4G dongle trong Android emulator
- Kiến trúc cuối cùng là dạng các trạm scraping theo khu vực
- Lắp đặt 1 server scraping mạnh, kết nối 50 4G dongle, tại một vị trí địa lý
- Chạy 50–100 thiết bị Android được mô phỏng trên mỗi server
- Bố trí các trạm như vậy ở 5 thành phố lớn
- Một server command-and-control đơn giản sẽ orchestration 5 trạm scraping
1 bình luận
Ý kiến trên Hacker News
Trong phần lớn trường hợp, dữ liệu đó cũng không thực sự là dữ liệu “của họ” theo nghĩa có thể được pháp luật công nhận. Vì vậy đạo đức của web scraping cũng như các vấn đề pháp lý liên quan không hề đơn giản như vậy. Mùa thu năm ngoái tôi có viết về chuyện này và bài đó cũng được quan tâm ở đây: https://news.ycombinator.com/item?id=37264676
Rốt cuộc, họ đang ngăn người khác dùng chính những thủ thuật mà họ từng dùng để tăng trưởng
Tôi nghĩ từ khi con người bắt đầu giao tiếp, đối thoại vẫn luôn diễn ra kiểu như vậy. Ngược lại, các vấn đề pháp lý trông giống như một tấm vải được dệt ra để bảo vệ những doanh nghiệp đã có chỗ đứng bằng mối đe dọa bạo lực nhà nước; chẳng mới mẻ gì, đáng buồn nhưng cũng dễ đoán. Rộng hơn, nỗ lực đóng gói chuyện này thành vấn đề quyền sở hữu trí tuệ rồi gắn với việc bảo vệ nghệ sĩ và nhà sáng tạo cũng rất gượng gạo về mặt logic, khiến người ta phải nhăn mặt
Có rất nhiều web scraping SaaS và dịch vụ liên quan, cùng hàng chục nhà cung cấp proxy dân cư. Phần lớn cơ chế chống bot tiến hóa quá nhanh đến mức ngay cả trong các vai trò kỹ thuật phần mềm truyền thống, chỉ cần chuyên làm kỹ thuật vượt chống bot cũng có thể kiếm thu nhập khá tốt. Vì tốc độ thay đổi này, làm việc tại một công ty web scraping ổn định hơn so với lấy web scraping làm nghề tự do. Scraper thường được trả theo dự án nên về lâu dài thiếu ổn định; scraping cao cấp cần đầu tư vận hành như proxy dân cư và thuê máy chủ; còn các việc giá rẻ thì thù lao rất thấp. Chỉ riêng việc Brightdata tổ chức hội nghị web scraping cũng cho thấy việc bán dịch vụ scraping quy mô lớn sinh lợi đến mức nào
Tôi tò mò liệu các thiết bị IoT bảo mật yếu hoặc phần cứng tiêu dùng nhiễm malware có thường được dùng cho mục đích này không. Cách hợp tác với ISP để có IP dân cư dường như không sinh lời hoặc không khả thi, nên nếu là dịch vụ proxy dân cư thì có vẻ chỉ còn những cách khá kín đáo
Tôi không có nền tảng trong lĩnh vực này, nhưng ghép nối những gì các công ty khoe ra thì không khó, và tôi cũng có mục đích thực tế là tự động hóa cá cược thể thao. Công việc chính ngoài đời của tôi cũng gần với mảng đó, và việc này giúp tôi học lập trình nhanh ở cuối tuổi 20. Nhưng gần như ngay lập tức, yêu cầu đổ về từ các nhà vận hành sneaker bot ở Trung Quốc và từ những người dùng thứ tiếng Anh kỳ lạ, có vẻ không phải người bản ngữ. Tôi gỡ mã xuống không phải vì đe dọa pháp lý, mà vì không muốn làm hỗ trợ khách hàng hay làm dưới trướng người khác; phần lớn yêu cầu đều kiểu “anh làm, rồi ta chia lợi nhuận”, khiến tôi khó tin là có ai lại chấp nhận đề nghị như vậy. Internet là mãi mãi, nên có thể một phần đoạn mã bắt chước Cyberfed-Akamai 0.8~2.3 vẫn còn trôi nổi đâu đó. Nếu một người học lập trình ở giữa độ tuổi 20 và trong vòng 3 năm đã đưa lên được đoạn mã có tác dụng, thì các công ty an ninh mạng thu phí đắt cho những sản phẩm như vậy nên thấy xấu hổ. Tôi cũng không học toán sau lớp 10, và do ADHD nên không thể xem video hay đọc bài viết lâu; tất cả những gì tôi làm là chép từ GitHub và các dịch vụ tương tự rồi học cho đến khi nó chạy được. Tôi đoán trong ngành này có lẽ đang bán rất nhiều giải pháp kiểu dầu rắn
Các tác nhân đe dọa dùng những dịch vụ như Cloudflare để chặn truy cập vào payload độc hại. Đây là vấn đề lớn đối với khách hàng muốn tìm và phát hiện giả mạo thương hiệu hoặc phishing thông tin đăng nhập, nhưng Cloudflare thì hoàn toàn không giúp gì và đơn giản là không quan tâm
Điều thú vị là hầu như không thấy phishing đứng sau Akamai. Chúng tôi cũng làm trong lĩnh vực này, nên có lợi ích liên quan trong việc tiếp tục có thể phát hiện các mối đe dọa như vậy
Nó vui vì phải giải quyết các vấn đề trong thế giới thực và tìm cách mới để làm một việc gì đó. Phát triển exploit cũng vậy. Những người này không phải là người không thích nghi, mà là những người bình thường đang làm việc họ đam mê. Chính lối nghĩ “người làm việc tôi ghét là kẻ không thích nghi” mới hoàn toàn kỳ quặc
Quy trình rõ ràng, không có rủi ro quyền riêng tư hay thủ thuật kỳ quặc, và nếu thất bại thì cũng thất bại theo cách mà con người ít nhất có thể nhìn thấy và báo cáo. Tốt hơn là trông như một lỗi không rõ nguyên nhân
Tôi đang băn khoăn cách xử lý khi bị từ chối, và có lẽ một thiết bị Android giá rẻ có thể lấp chỗ trống đó