หากอยากทำ Web Scraping แบบบริษัทใหญ่ ๆ (2021)
(incolumitas.com)- เพียงใช้ AWS Lambda กับ Headless Chrome ก็สามารถรวบรวม Google SERP ได้หลายล้านรายการต่อสัปดาห์ แต่เมื่อเจอกับ เว็บไซต์ที่มีการป้องกันอย่างเข้มงวด โครงสร้างบอตบนคลาวด์จะชนข้อจำกัดได้ง่าย
- หากใช้การเรียก Lambda ซ้ำและหลายรีเจียน จะสามารถใช้ IP สาธารณะ พร้อมกันได้ประมาณ
16 * 250 = 4000รายการเมื่อคิดจาก 16 รีเจียน ซึ่งเพียงพอสำหรับเป้าหมายที่ป้องกันไม่เข้มงวด - ผู้ให้บริการป้องกันบอตอย่าง DataDome, Akamai, Imperva ติดตามความไม่สอดคล้องของการตั้งค่าเบราว์เซอร์ ร่องรอยการทำงานอัตโนมัติ และข้อมูล fingerprint โดยโจทย์ที่ยากจริง ๆ ใกล้เคียงกับ การลด false positive มากกว่าการตรวจจับเอง
- เสนอแนวทางที่ตรวจจับได้ยากกว่า โดยใช้เครื่อง Android จริงและ IP มือถือ แทน Docker หรือเซิร์ฟเวอร์คลาวด์ เพราะ IP 4G/5G/LTE ถูกแชร์โดยผู้ใช้ปกติจำนวนมากในเมืองใหญ่ ทำให้บล็อกได้ยาก
- ฟาร์มอุปกรณ์จริงต้องยอมรับภาระเรื่องการซื้อเครื่อง การเช่าพื้นที่ในแต่ละเมือง การบำรุงรักษาหน้างาน และความขัดข้องของฮาร์ดแวร์ ส่วน Android emulator ก็ยังมีความเสี่ยงเรื่อง การตรวจจับการจำลองสภาพแวดล้อม
โครงสร้างสเกลใหญ่สำหรับ scraping ที่สร้างด้วย AWS Lambda
- ในช่วงที่เคยให้บริการ scraping สามารถรวบรวม Google SERP ได้สูงสุดหลายล้านรายการต่อสัปดาห์ แต่ไม่ได้ใช้ผู้ให้บริการพร็อกซีอย่าง Brightdata, Packetstream, Oxylabs
- มองว่าไม่น่าไว้วางใจลูกค้ารายอื่นที่ใช้แบนด์วิดท์พร็อกซีช่วงเดียวกันร่วมกัน
- การ scraping ข้อมูลสาธารณะที่ไม่ใช่ DoS ถือว่าใช้ได้ แต่ขีดเส้นแยกจากการฉ้อโกงโฆษณา สแปมโซเชียลมีเดีย การโจมตีเว็บแบบ SQL injection อัตโนมัติ และ XSS
- ค่าใช้จ่ายของบริการพร็อกซีก็เป็นภาระด้วย
- โครงสร้างจริงคือฟังก์ชันที่ใส่ Headless Chrome ลงใน AWS Lambda แล้วรันเบราว์เซอร์เป็นเวลา 300 วินาทีด้วย puppeteer-extra และ chrome-aws-lambda
- Google ไม่ได้บล็อกบอตอย่างเข้มงวดกับเสิร์ชเอนจินของตัวเอง และโดยมากใช้ rate limit ตาม IP ดังนั้นหากดูเฉพาะ Google SERP ก็อาจทำได้แม้ด้วย
curl - ใน Lambda หลังเรียกฟังก์ชัน 3 ครั้งจะได้ IP สาธารณะใหม่ และเมื่อเรียก 1000 ฟังก์ชันพร้อมกัน จะไปถึง IP สาธารณะประมาณ 250 รายการ
- คำนวณว่าหากใช้ 16 รีเจียน จะสามารถใช้ IP สาธารณะพร้อมกันได้ประมาณ
4000รายการ - แม้จะเป็น IP ดาต้าเซ็นเตอร์แบบแชร์ แต่ก็เพียงพอสำหรับรวบรวม Google SERP หลายล้านรายการต่อสัปดาห์
- คำนวณว่าหากใช้ 16 รีเจียน จะสามารถใช้ IP สาธารณะพร้อมกันได้ประมาณ
- เคยลอง Google Cloud Platform ด้วย แต่ Google บล็อกทราฟฟิกจากโครงสร้างพื้นฐานคลาวด์ของตนเองเข้มงวดกว่าทราฟฟิกจาก AWS
- ประสบการณ์นี้อ้างอิงจากปี 2019 และ 2020 และสถานการณ์หลังจากนั้นอาจเปลี่ยนไปแล้ว
เหตุผลที่บอตบนคลาวด์ถูกบล็อก
- โครงสร้างบน Lambda อาจใช้ได้กับเป้าหมายที่ยอมให้ scraping ได้ในระดับหนึ่ง เช่น Google, Bing, Amazon แต่ไม่เหมาะกับเว็บไซต์ที่ใช้การป้องกันเข้มงวด
- ผู้ให้บริการป้องกันบอตอย่าง DataDome, Akamai, Imperva มองหา browser fingerprint ความไม่สอดคล้องของการตั้งค่า และร่องรอยที่ต่างจากเบราว์เซอร์ที่มนุษย์ใช้งาน
- ตัวอย่างเทคนิคตรวจจับมีแพร่หลายมาก
- Browser Red Pills
- Browser Based Port Scanning
- Google Picasso
- Font Fingerprinting
- TLS Fingerprinting
- WebGL Fingerprinting
- การตรวจจับ IP จริงผ่าน WebRTC
- Behavioral Classification
- การเรียกดู Gyroscope API
- การทำ fingerprint ด้วย HTTP header, CSS feature query และฟอนต์โดยไม่ใช้ JavaScript
- วิธีตรวจจับบอตมีจำนวนมาก และสถาปัตยกรรมบอตแทบทุกแบบมีจุดอ่อนต่อการถูกตรวจจับในระดับหนึ่ง
- ฝั่งที่สร้างบอตทำงานยากกว่าฝั่งที่ตรวจจับ และโจทย์ที่ใหญ่กว่าของผู้ให้บริการป้องกันบอตมักใกล้เคียงกับ การลด false positive มากกว่าการจับบอตส่วนใหญ่ให้ได้
โครงสร้างทางเศรษฐศาสตร์ที่ถูกตรวจจับได้ง่าย
- นักพัฒนาบอตที่ต้องการ scraping ปริมาณมากมักใส่เบราว์เซอร์ไว้ใน Docker container แล้ว orchestrate ด้วย Docker Swarm หรือ Kubernetes
- บอตเหล่านี้มักถูกโฮสต์บนผู้ให้บริการคลาวด์อย่าง Hetzner, AWS, DigitalOcean
- โครงสร้างนี้ต่างจากสภาพแวดล้อมของผู้ใช้มนุษย์อย่างมาก
- สถานการณ์ที่ผู้ใช้ปกติท่อง Instagram อยู่ใน Docker container บน Hetzner VPS นั้นไม่เป็นธรรมชาติ
- เสนอกฎสำหรับ scraping ให้สำเร็จ 2 ข้อ
- กฎที่สำคัญเป็นอันดับสอง: อย่าโกหกเกี่ยวกับการตั้งค่าเบราว์เซอร์
- กฎที่สำคัญที่สุด: โกหกเกี่ยวกับการตั้งค่าเบราว์เซอร์เฉพาะตอนที่จะไม่ถูกจับได้เท่านั้น
ฟาร์มอุปกรณ์ Android จริง
- เนื่องจากการทำ reverse engineering ไลบรารี fingerprint ของระบบป้องกันบอตที่ถูก obfuscate ทำได้ยาก จึงเสนอแนวทางใช้เครื่องจริงสำหรับ scraping
- โครงสร้างสมมติคือซื้อเครื่อง Android ราคาถูก 500 เครื่อง และผสมเครื่องจากประมาณ 5 ผู้ผลิตเพื่อให้ fingerprint หลากหลาย
- เครื่อง Android ราคาถูกเริ่มต้นที่เครื่องละ 58 ดอลลาร์
- มองว่าหากซื้อทีเดียว 100 เครื่องจะได้ส่วนลดมาก
- ติดแพ็กเกจข้อมูลราคาถูกให้แต่ละเครื่อง และควบคุมด้วย DeviceFarmer/stf
- แนวคิดคือกระจายเครื่องเมืองละ 100 เครื่องใน 5 เมืองหลัก เช่น London, Paris, Boston, Frankfurt, Los Angeles และเช่าพื้นที่เก็บของราคาถูกที่อยู่ใกล้เสาสัญญาณมือถือ
- ติดตั้ง Android Go แบบเบาในอุปกรณ์ ลบองค์ประกอบที่ไม่จำเป็นออก แล้วเสียบไฟไว้
- หากเปิดปิดโหมดเครื่องบินทุก 5 นาที จะได้ IP ใหม่ผ่าน 4G Carrier Grade NAT
- ที่อยู่ IP มือถือถูกแชร์โดยผู้ใช้ปกติได้มากถึงหลายแสนคนในเมืองใหญ่ จึงบล็อกได้ยากในทางปฏิบัติ
- ยกตัวอย่างว่า Instagram คงไม่บล็อกคน 200,000 คนใน LA เพียงเพราะมีผู้ใช้สแปมบางส่วน
- อ้างอิง เอกสารของ Ofcom ที่ระบุว่าหากที่อยู่ IPv4 ใน CGN ถูกบล็อก อาจกระทบฐานสมาชิกทั้งหมดได้
- สำหรับ IPv6 พื้นที่ที่อยู่กว้างมากจนผู้ให้บริการป้องกันบอตส่วนใหญ่แทบไม่ให้ หรือไม่ให้เลยซึ่งชื่อเสียง IP กับที่อยู่ IPv6
จุดที่ตรวจจับได้และภาระการปฏิบัติการของโครงสร้างอุปกรณ์จริง
- หากวางอุปกรณ์จริงไว้กับพื้นทั้งวัน สภาพที่ไม่มีการหมุนหรือการเคลื่อนไหวจะดำเนินต่อเนื่อง ดังนั้นต้อง spoof อีเวนต์ JavaScript
deviceorientationและdevicemotionในระดับ kernel- เว็บไซต์สามารถเข้าถึงข้อมูลการหมุนและความเร็วของ Android ได้โดยไม่ต้องขอสิทธิ์
- หากไม่นับปัญหานี้ ก็ยังไม่ชัดเจนว่าระบบตรวจจับบอตจะบล็อกโครงสร้างดังกล่าวได้อย่างไร
- ภาระการปฏิบัติการไม่เล็ก
- ต้องซื้ออุปกรณ์ Android 500 เครื่อง
- ต้องเช่าพื้นที่เก็บของในเมืองหลัก และมีค่าใช้จ่าย
- ต้องมีคนคอยแก้ปัญหาฟาร์มอุปกรณ์ใน 5 เมือง
- ต้องจัดการฮาร์ดแวร์ และอาจเกิดปัญหาอย่างต่อเนื่อง
- โครงสร้างแบบนี้จะกลายเป็นโครงการขนาดใหญ่ และอาจมีค่าบำรุงรักษาหลายพันดอลลาร์
ทางเลือกอย่าง Android emulator
- มองว่าการใช้ Android emulator แทนอุปกรณ์ Android จริงน่าจะดีกว่า
- แม้ลดต้นทุนได้ แต่ผู้ให้บริการป้องกันบอตอาจตรวจพบสภาพแวดล้อมการจำลองได้
- วิธีตรวจจับที่เป็นไปได้มีหลายแบบ
- red pill บนเบราว์เซอร์อาจเผยว่าเบราว์เซอร์กำลังรันอยู่ในสภาพแวดล้อมการจำลอง
- การสแกนพอร์ตผ่านเบราว์เซอร์ อาจค้นหาพอร์ตหรือบริการอย่าง
adbที่รันเฉพาะบนอุปกรณ์ Android ที่ถูกจำลอง - Google สามารถตั้งค่า Advertising ID ให้กับอุปกรณ์มือถือทั้งเครื่องได้ และหากไม่มี ID นี้หรือมีค่าเหมือนเดิมเสมอ ก็อาจเป็นสัญญาณน่าสงสัย
- Social Media Login Detection สามารถตรวจสอบได้ว่ามีการล็อกอินบัญชี Gmail หรือ YouTube หรือไม่ และหากบน Android ไม่มีการล็อกอินบัญชี Google ก็อาจถูกมองว่าน่าสงสัย
- นอกจากนี้อาจมีเทคนิคตรวจจับอุปกรณ์ Android ที่ถูกจำลองอีกมาก
- Android emulator มีโอกาสสูงที่จะไม่สมบูรณ์ และความไม่สมบูรณ์นั้นอาจถูกเปิดเผยผ่าน JavaScript API จำนวนมหาศาลของเบราว์เซอร์มือถือ
- อย่างไรก็ตามยังชอบแนวทางจำลองสภาพแวดล้อม และเสนอการจัดวางที่เชื่อมต่อ 4G dongle กับเซิร์ฟเวอร์แรง ๆ ไม่กี่เครื่อง
- proxidize.com ให้บริการพร็อกซีมือถือ 4G แต่พร็อกซีตรวจจับได้ในตัวเอง จึงอยากใช้ 4G dongle โดยตรงจาก Android emulator
- โครงสร้างสุดท้ายอยู่ในรูปแบบ scraping station รายพื้นที่
- ติดตั้งเซิร์ฟเวอร์ scraping ประสิทธิภาพสูง 1 เครื่องที่เชื่อมต่อ 4G dongle 50 ตัวในตำแหน่งทางภูมิศาสตร์หนึ่งแห่ง
- รันอุปกรณ์ Android ที่จำลองขึ้น 50~100 เครื่องบนแต่ละเซิร์ฟเวอร์
- วาง station แบบนี้ใน 5 เมืองหลัก
- เซิร์ฟเวอร์ command-and-control แบบเรียบง่ายจะ orchestrate scraping station ทั้ง 5 แห่ง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ข้อมูลนั้นส่วนใหญ่ก็ไม่ใช่ข้อมูล “ของพวกเขา” จริง ๆ ในความหมายที่กฎหมายรับรองได้ด้วยซ้ำ ดังนั้นทั้ง จริยธรรมของเว็บสเครปปิง และประเด็นทางกฎหมายที่เกี่ยวข้องจึงไม่ได้เรียบง่ายขนาดนั้น เมื่อฤดูใบไม้ร่วงที่ผ่านมา บทความที่ผมเขียนเรื่องนี้ก็ได้รับความสนใจที่นี่เช่นกัน: https://news.ycombinator.com/item?id=37264676
สุดท้ายก็คือพวกเขาห้ามไม่ให้คนอื่นใช้วิธีที่ตัวเองเคยใช้เพื่อเติบโต
ตั้งแต่มนุษย์เริ่มสื่อสารกันมา การสนทนาก็เป็นแบบนี้มาตลอดไม่ใช่หรือ ในทางกลับกัน ประเด็นทางกฎหมายดูเหมือนผืนผ้าที่ถูกทอขึ้นเพื่อปกป้องผู้ประกอบการเดิมด้วยภัยคุกคามจากความรุนแรงของรัฐ ไม่ได้ใหม่อะไร แถมน่าสมเพชแต่ก็พอคาดเดาได้ ถ้ามองกว้างขึ้น ความพยายามจะห่อเรื่องนี้ให้เป็นประเด็น ทรัพย์สินทางปัญญา แล้วโยงเข้ากับการคุ้มครองศิลปินและครีเอเตอร์ก็ดูฝืนตรรกะอย่างมากจนน่าขมวดคิ้ว
มี SaaS สำหรับเว็บสเครปปิงและบริการที่เกี่ยวข้องอยู่มากมาย และยังมีผู้ให้บริการ residential proxy อีกหลายสิบราย กลไกป้องกันบอต ส่วนใหญ่พัฒนาเร็วมาก จนแม้ในบทบาทวิศวกรรมซอฟต์แวร์แบบดั้งเดิม ก็สามารถหารายได้ค่อนข้างดีจากการทุ่มทำเฉพาะเทคนิคเลี่ยงระบบป้องกันบอตได้เลย ด้วยความเร็วในการเปลี่ยนแปลงแบบนี้ การทำงานในบริษัทเว็บสเครปปิงจึงมั่นคงกว่าการยึดเว็บสเครปปิงเป็นอาชีพโดยตรง สเครปเปอร์รับเงินเป็นโปรเจกต์จึงไม่มั่นคงในระยะยาว การสเครปขั้นสูงต้องลงทุนด้านปฏิบัติการ เช่น residential proxy และการเช่าเซิร์ฟเวอร์ ส่วนงานราคาถูกก็จ่ายค่าตอบแทนต่ำมาก แค่ดูว่า Brightdata จัดคอนเฟอเรนซ์เว็บสเครปปิง ก็เห็นได้ว่าการขายบริการสเครปปิงขนาดใหญ่นั้นทำกำไรได้แค่ไหน
สงสัยว่าอุปกรณ์ IoT ที่ความปลอดภัยอ่อนแอ หรือฮาร์ดแวร์ผู้บริโภคที่ติดมัลแวร์ ถูกใช้เพื่อจุดประสงค์แบบนี้บ่อยหรือไม่ วิธีร่วมมือกับ ISP เพื่อให้ได้ IP บ้านดูไม่น่าทำกำไรหรือไม่น่าจะเป็นไปได้ ดังนั้นถ้าเป็นบริการ residential proxy ก็คงเหลือแต่แนวทางที่ค่อนข้างลับ ๆ เท่านั้น
ผมไม่มีพื้นหลังในด้านนี้ แต่พอเอาสิ่งที่บริษัทต่าง ๆ คุยอวดไว้มาปะติดปะต่อกัน ก็ไม่ได้ยาก และยังมีเป้าหมายเชิงปฏิบัติในการทำให้การเดิมพันกีฬาเป็นอัตโนมัติด้วย งานประจำจริง ๆ ก็ใกล้เคียงด้านนั้น และมันช่วยให้ผมเรียนโปรแกรมมิงได้เร็วในช่วงปลายวัย 20 แต่เกือบจะทันที ก็มีคำขอหลั่งไหลมาจากผู้ทำบอตรองเท้าสนีกเกอร์ในจีน และจากคนที่ใช้ภาษาอังกฤษแปลก ๆ เหมือนไม่ใช่เจ้าของภาษา ผมเอาโค้ดลงไม่ใช่เพราะถูกขู่ทางกฎหมาย แต่เพราะไม่อยากทำงานซัพพอร์ตลูกค้าหรือทำงานใต้คนอื่น และคำขอส่วนใหญ่ก็เป็นแนว “คุณทำงาน แล้วเราค่อยแบ่งรายได้กัน” จนยากจะเชื่อว่าใครจะรับข้อเสนอแบบนั้น อินเทอร์เน็ตคงอยู่ตลอดไป ดังนั้นโค้ดบางส่วนที่เลียนแบบ Cyberfed-Akamai 0.8~2.3 อาจยังลอยอยู่ที่ไหนสักแห่ง ถ้าคนที่หัดโปรแกรมมิงตอนกลางวัย 20 แล้วภายใน 3 ปีเขียนโค้ดที่ใช้การได้แบบนั้น บริษัทไซเบอร์ซีเคียวริตี้ที่คิดเงินแพงกับผลิตภัณฑ์แบบนั้นก็ควรละอาย ผมไม่ได้เรียนคณิตตั้งแต่หลัง ม.5 และเพราะ ADHD ทำให้ดูวิดีโอหรืออ่านอะไรนาน ๆ ไม่ได้ ทั้งหมดที่ทำก็แค่ลอกตามจาก GitHub และบริการคล้าย ๆ กันจนกว่าจะทำงานได้ ผมคิดว่าในอุตสาหกรรมนี้คงมี โซลูชันแบบน้ำมันงู ขายอยู่ไม่น้อย
ผู้ก่อภัยคุกคามใช้บริการอย่าง Cloudflare เพื่อปิดกั้นการเข้าถึงเพย์โหลดอันตราย สำหรับลูกค้าที่ต้องการค้นหาและตรวจจับการปลอมแปลงแบรนด์หรือฟิชชิงขโมยข้อมูลประจำตัว นี่เป็นปัญหาใหญ่ แต่ Cloudflare ไม่ช่วยอะไรเลยและก็แค่ไม่สนใจ
ที่น่าสนใจคือแทบไม่ค่อยเห็นฟิชชิงอยู่หลัง Akamai เราก็ทำงานในด้านนี้เหมือนกัน จึงมีส่วนได้เสียที่ต้องตรวจจับภัยเหล่านี้ต่อไปให้ได้
มันสนุกเพราะต้องแก้ปัญหาในโลกจริงและหาวิธีใหม่ ๆ ในการทำอะไรบางอย่าง การพัฒนา exploit ก็เช่นกัน คนเหล่านี้ไม่ใช่ คนปรับตัวไม่ได้ แต่เป็นคนปกติที่ทำสิ่งที่ตัวเองหลงใหลต่างหาก วิธีคิดแบบ “คนที่ทำสิ่งที่ฉันไม่ชอบคือคนปรับตัวไม่ได้” นั่นแหละที่แปลกสุด ๆ
ขั้นตอนชัดเจน ไม่มีความเสี่ยงด้านความเป็นส่วนตัวหรือทริกแปลก ๆ และถึงล้มเหลว ก็ล้มเหลวในแบบที่อย่างน้อยมนุษย์ยังมองเห็นและรายงานได้ ดีกว่าดูเหมือนข้อขัดข้องที่ไม่รู้สาเหตุ
กำลังคิดว่าจะจัดการกรณีถูกปฏิเสธอย่างไร บางที อุปกรณ์ Android ราคาถูกสักเครื่อง อาจช่วยอุดช่องว่างได้