เว็บแบบเปิดดูแลรักษายากขึ้นจากการโจมตีของ AI scraper

• การโจมตีด้วยเว็บสเครปปิง เพื่อรวบรวมข้อมูลฝึกสำหรับโมเดลภาษาขนาดใหญ่และโครงการอื่น ๆ เพิ่มขึ้นมานานกว่าหนึ่งปีแล้ว ทำให้ภาระทราฟฟิกของเว็บไซต์อิสระหนักขึ้นจนยากที่จะคงความเปิดกว้างไว้ได้
• ผู้โจมตีใช้ residential proxy ที่ประกอบด้วยอุปกรณ์ทั่วไปและอุปกรณ์มือถือหลายล้านเครื่อง ส่งคำขอเพียงไม่กี่ครั้งต่อ IP และปลอม user-agent เพื่อทำให้การบล็อก IP แบบเดิมใช้ไม่ได้ผล
• มัลแวร์ อุปกรณ์สตรีมมิงมีเดียที่มีช่องโหว่ VPN ฟรี และ SDK ของแอป ก่อเป็นเครือข่ายพร็อกซี โดยเคยมีกรณีที่ปริมาณการโจมตีลดลงชั่วคราวหลัง Google โค่นเครือข่าย IPIDEA และ NetNut ก่อนจะกลับมาเพิ่มขึ้นอีก
• เว็บไซต์ต่าง ๆ รับมือด้วย proof of work ของ Anubis, CAPTCHA, กำแพงล็อกอินหรือจ่ายเงิน และเครื่องมือปนเปื้อนข้อมูล แต่ LWN เน้นที่ การปรับแต่งเว็บไซต์และการจำกัดต้นทุนระหว่างถูกโจมตี เพื่อไม่ให้รบกวนผู้อ่านจริง เสิร์ชเอนจิน และ Internet Archive
• ขณะที่ต้นทุนการป้องกัน scraper และการยืนยันผู้ใช้ถูกผลักไปยังเว็บทั้งระบบ หากไม่มีทางออกที่ยั่งยืน เว็บไซต์อิสระอาจย้ายไปอยู่หลังกำแพงป้องกัน และทำให้ อินเทอร์เน็ตแบบเปิด เสียหายได้

---

การโจมตีของ scraper ที่ขยายตัวต่อเนื่อง

• ปัญหาการรวบรวมข้อมูลฝึกสำหรับโมเดลภาษาขนาดใหญ่และโครงการที่เกี่ยวข้อง ซึ่งเคยกล่าวถึงเมื่อต้นปี 2025 ยังคงเลวร้ายลงแม้ผ่านไปกว่าหนึ่งปีแล้ว
• คำขอที่ผู้กระทำการไม่ทราบตัวตนส่งมายังเว็บไซต์เพิ่มขึ้นถึงระดับที่ไม่เคยเกิดขึ้นมาก่อน และทราฟฟิกที่มากเกินไปทำให้การรักษา เว็บแบบเปิด ยากขึ้นเรื่อย ๆ

residential proxy ที่ระดม IP หลายล้านรายการ

• การโจมตีส่งคำขอที่ประสานกันจาก ที่อยู่ IP ไม่ซ้ำกันหลายล้านรายการ เป็นเวลาหลายชั่วโมง โดยแต่ละที่อยู่เข้าถึงเว็บไซต์ไม่เกินสองหรือสามครั้ง
• ข้อมูลอย่าง user-agent ที่ผู้โจมตีควบคุมเป็นข้อมูลสมมติ และปลอมให้แต่ละคำขอดูเหมือนการเข้าถึงของคนทั่วไปที่ใช้เว็บเบราว์เซอร์
• บอทมักไม่ดึงรูปภาพหรือ CSS จึงมีเบาะแสบางอย่างให้แยกจากมนุษย์ได้ แต่เมื่อวิเคราะห์เสร็จ ที่อยู่นั้นก็จะไม่ถูกใช้อีก ดังนั้นการบล็อก IP ภายหลังจึงไม่ได้ผล
• ทราฟฟิกส่วนใหญ่เกิดจากเครือข่ายตามบ้านและมือถือที่ถูกสั่งการโดย โหนดสั่งการและควบคุม ส่วนกลาง
  • ซอฟต์แวร์ที่ติดตั้งบนอุปกรณ์ทั่วไปจะรับคำสั่งจากโหนดควบคุม ดึงหน้าเว็บ และส่งข้อมูลกลับไป
  • จำนวนมากทำงานโดยที่เจ้าของอุปกรณ์ไม่รับรู้หรือไม่ยินยอม และระบบที่ถูกใช้ในลักษณะนี้เรียกว่า residential proxy

เครือข่ายพร็อกซีอาชญากรรมและอุปกรณ์ที่ติดเชื้อ

• รูปแบบหนึ่งคือ ผู้ปฏิบัติการเชิงอาชญากรรม ที่รัน scraper บนระบบที่ยึดครองด้วยมัลแวร์
• Google เริ่ม โค่นเครือข่ายบอท IPIDEA เมื่อต้นปี และเปิดเผยข้อมูลเกี่ยวกับวิธีดำเนินงาน
  • ช่วงเวลาที่ IPIDEA หยุดทำงานตรงกับช่วงที่ทราฟฟิก scraper ของ LWN ลดลงอย่างมาก
  • หลังจากค่อนข้างสงบอยู่หลายเดือน การโจมตีก็กลับมาเพิ่มขึ้นอีก
• เมื่อเร็ว ๆ นี้พบว่า อุปกรณ์สตรีมมิงมีเดีย เป็นพาหะหลักของซอฟต์แวร์สเครปปิงที่เป็นอันตราย
  • อุปกรณ์บางส่วนติดเชื้อมาตั้งแต่ขั้นตอนซัพพลาย
  • อุปกรณ์อื่น ๆ มีความปลอดภัยหละหลวม จึงถูกยึดได้ง่ายหลังขายไปแล้ว

เครือข่ายพร็อกซีเชิงพาณิชย์ที่ใช้ VPN ฟรีและ SDK ของแอป

• อีกรูปแบบหนึ่งทำตัวเหมือนบริษัทที่ถูกกฎหมายในระดับหนึ่ง และขาย ที่อยู่ IP ที่ “ได้มาอย่างมีจริยธรรม”
• Bright Data เป็นบริษัทตัวอย่างที่โฆษณาความสามารถในการเลี่ยงการควบคุมการเข้าถึงและการจำกัดทราฟฟิกของเว็บไซต์
  • ผู้ใช้ VPN “ฟรี” ต้องอนุญาตให้ Bright Data เราต์ทราฟฟิกผ่านอุปกรณ์ของตน
  • โทรศัพท์มือถือและอุปกรณ์อื่น ๆ ที่ใช้ VPN นี้จะกลายเป็นปลายทางของเครือข่าย residential proxy ของ Bright Data และถูกนำไปใช้โจมตีเว็บไซต์
• บริษัทคล้ายกันให้ไลบรารีที่นักพัฒนาแอปสามารถเชื่อมกับผลิตภัณฑ์ของตนได้ และจ่ายเงินให้นักพัฒนาแลกกับการส่งต่อการเชื่อมต่อเครือข่ายของผู้ใช้
  • บริษัทหนึ่งเคยสอบถามว่าจะลงโฆษณา SDK ของตนบน LWN ได้หรือไม่ แต่การพูดคุยจบลงอย่างรวดเร็ว
  • ผู้ปฏิบัติการมีตั้งแต่รายที่พยายามสร้างภาพลักษณ์ถูกกฎหมายโดยอ้างว่า “ปฏิบัติตาม GDPR” ไปจนถึงรายที่ไร้จริยธรรมอย่างโจ่งแจ้ง
• ผู้ปฏิบัติการพร็อกซีเหล่านี้สามารถรันโค้ดที่เข้าถึงทรัพยากรของเครือข่ายที่มีอุปกรณ์หลายล้านเครื่องเชื่อมต่ออยู่ได้ จึง ไม่อาจสันนิษฐานได้ว่าสิทธิ์ดังกล่าวถูกใช้เฉพาะกับเว็บสเครปปิงเท่านั้น

บริษัทโมเดลและผู้ใช้เครือข่ายพร็อกซี

• บริษัทที่มีชื่อเสียงซึ่งทำธุรกิจหลักด้านการพัฒนาโมเดลก็สเครปเว็บด้วยตนเองเช่นกัน
  • ทราฟฟิกที่ระบุถึงบริษัทนั้นได้ง่ายจะแสดงตัวตนอย่างชัดเจนใน user-agent
  • โดยทั่วไปจะปฏิบัติตามกลไกควบคุมอย่าง robots.txt
  • รวบรวมข้อมูลซ้ำทั้งเว็บไซต์ราวกับตรวจดูว่าแม้แต่บทความที่เขียนในปี 2003 มีการเปลี่ยนแปลงล่าสุดหรือไม่
  • อย่างไรก็ตาม บริษัทเหล่านี้ไม่ได้ส่งทราฟฟิกปริมาณมหาศาลจนระบบหลายล้านเครื่องรับไม่ไหว จึงไม่ใช่ปัญหาใหญ่ที่สุด
• ยังไม่ชัดเจนว่าใครเป็นผู้จ่ายเงินเพื่อรัน การโจมตีผ่าน residential proxy
  • ยังไม่พบหลักฐานว่าบริษัทโมเดลแนวหน้ากำลังใช้เครือข่ายเหล่านี้
  • บริษัทเหล่านี้ไม่เปิดเผยวิธีป้อนข้อมูลให้โมเดลหรือแหล่งที่มาของข้อมูลฝึก และก็ไม่ได้แสดงท่าทีเคารพผู้สร้างคอนเทนต์หรือผู้ที่กังวลเรื่องปัญหาการดำเนินงาน
• ต่อโมเดลสาธารณะหนึ่งรายการ อาจมีโมเดลอีกจำนวนมากที่ไม่ถูกเปิดเผยต่อภายนอก
  • หลายบริษัทอาจกำลังสร้างโมเดลของตนเองภายใต้ความคาดหวังว่าหากนำหน้าในการแข่งขัน AI ได้ก็จะได้รับมูลค่าบริษัทมหาศาล
  • หน่วยงานรัฐบาลลับในหลายประเทศก็อาจต้องการมีโมเดลและข้อมูลฝึกของตนเอง
  • องค์กรอาชญากรรมขนาดใหญ่ก็มีแนวโน้มต้องการโมเดลของตนเองเช่นกัน
• เมื่อเครื่องมือ AI ถูกมองเป็นอาวุธ การแข่งขันสะสมอาวุธ จึงกำลังดำเนินอยู่ และอินเทอร์เน็ตทั้งระบบก็ถูกดึงเข้าไปเกี่ยวข้องในกระบวนการนี้

มาตรการป้องกันเพื่อรักษาอินเทอร์เน็ตแบบเปิด

• ผู้ดูแลเว็บไซต์นำกลไกป้องกันหลายแบบมาใช้เพื่อหยุดการโจมตี โดยลดผลกระทบต่อผู้ใช้จริงให้มากที่สุด
• Anubis ถูกใช้อย่างแพร่หลาย โดยกำหนดให้ผู้เข้าถึงทำ proof of work เพื่อบล็อก scraper
• บริการเชิงพาณิชย์แสดงปุ่มให้ “พิสูจน์ว่าเป็นมนุษย์” ส่วนเว็บไซต์อื่น ๆ ขอให้ทำ CAPTCHA เช่น เลือกช่องที่มีไฟจราจร หรือวางชิ้นส่วนปริศนาให้ตรงตำแหน่ง
• บางเว็บไซต์ย้ายฟังก์ชันหลักไปไว้หลังล็อกอินหรือกำแพงจ่ายเงิน และใช้เครื่องมืออย่าง iocaine เพื่อทำให้ข้อมูลที่ scraper ได้รับปนเปื้อนอย่างแข็งขัน
• ต้นทุนในการสร้างและดูแลกลไกป้องกัน รวมถึงความไม่สะดวกของผู้ใช้ที่ต้องผ่านกลไกเหล่านี้ คือ ภาระหนักที่ scraper และผู้จ่ายเงินให้ scraper ผลักให้คนทั้งโลกแบกรับ

วิธีป้องกันของ LWN และข้อจำกัด

• เมื่อเร็ว ๆ นี้ LWN เผชิญการโจมตีจาก scraper ที่รุนแรงที่สุดเท่าที่เคยมีมา แต่ด้วยมาตรการป้องกันที่สร้างไว้ จึงรับทราฟฟิกได้ในระดับที่ผู้อ่านจริงส่วนใหญ่แทบไม่สังเกตเห็น
• หากเปิดเผยวิธีป้องกันเฉพาะเจาะจง ก็อาจให้ข้อมูลตอบโต้แก่ผู้โจมตี จึงเก็บเป็นความลับ และฝั่งป้องกันเองก็ยังอยู่ใน การแข่งขันสะสมอาวุธ เช่นกัน
• ให้ความสำคัญกับการลดผลกระทบต่อผู้อ่านจริงให้มากที่สุด
  • LWN ไม่ใช้ Anubis เพราะทำให้การเข้าถึงเว็บไซต์ล่าช้าและสร้างความไม่สะดวกแก่ผู้อ่าน
  • ดูเหมือนว่า scraper จะเลี่ยง Anubis ได้ในที่สุด และเริ่มมีสัญญาณเช่นนั้นแล้ว
  • หากสามารถระดมอุปกรณ์ของคนอื่นหลายล้านเครื่องได้ proof of work ก็ไม่ใช่อุปสรรคใหญ่
• พยายามไม่ปิดกั้นการเข้าถึงของเสิร์ชเอนจินปกติและองค์กรอย่าง Internet Archive
  • รายการอนุญาตแบบชัดเจนที่ให้เข้าถึงได้เฉพาะเสิร์ชเอนจินเจ้าตลาด จะยิ่งเสริมสถานะของ ผู้ผูกขาด ที่มีปัญหาด้านคุณภาพบริการอยู่แล้ว
  • จนถึงตอนนี้ LWN สามารถรักษาการเข้าถึงตามปกติได้โดยไม่ต้องมีรายการอนุญาตสำหรับเสิร์ชเอนจินใดเป็นพิเศษ
• ปรับแต่งบางส่วนของเว็บไซต์อย่างจริงจัง และลดงานที่มีต้นทุนสูงให้เหลือน้อยที่สุดระหว่างถูกโจมตี
  • ผู้อ่านที่ไม่ระบุตัวตนอาจได้รับผลกระทบจากมาตรการเหล่านี้เป็นครั้งคราว แต่ผู้ใช้ที่ล็อกอินจะไม่ได้รับผลกระทบ
  • ในสถานการณ์โจมตีที่มาตรการป้องกันทำงานอยู่ บางครั้งเวลาในการตอบสนองกลับเร็วกว่าเวลาปกติด้วยซ้ำ
• ไม่มองว่ามาตรการปัจจุบันเป็นทางออกถาวร และต้องพิจารณาการตอบโต้ขั้นถัดไปไว้เผื่อวันที่มาตรการเหล่านี้หมดประสิทธิภาพ

การโค่น NetNut และความสงบชั่วคราว

• Google ประกาศเมื่อวันที่ 2 กรกฎาคมว่าได้ร่วมมือกับสำนักงานสอบสวนกลางสหรัฐฯ (FBI) และหน่วยงานอื่น ๆ เพื่อ โค่นเครือข่าย residential proxy ของ NetNut
• หลังปฏิบัติการดังกล่าว ระดับการโจมตีของ scraper ดูเหมือนลดลงบ้าง แต่จากประสบการณ์ที่ผ่านมา ความสงบนี้อาจอยู่ได้ไม่นาน
• Google Play Store จะตรวจสอบแอปที่ติด NetNut
• ผู้ให้บริการแอปสโตร์รายใหญ่ยังไม่ตอบว่าเหตุใดแอปที่มีฟังก์ชัน residential proxy จึงลงทะเบียนได้ง่าย

อินเทอร์เน็ตที่ถูกผลักไปหลังกำแพงป้องกัน

• จำเป็นต้องมีทางออกที่ยั่งยืนกว่านี้ ก่อนที่อินเทอร์เน็ตทั้งระบบจะย้ายไปอยู่หลังกำแพงป้องกัน และ เครือข่ายแบบเปิด ที่เคยส่งเสริมความคิดสร้างสรรค์จะหายไป
• อุตสาหกรรมที่ก่อให้เกิดการโจมตีเหล่านี้นำคอนเทนต์ของเว็บไซต์อิสระไปใช้ แล้วไม่แยแสหากเว็บไซต์ถูกทำลาย และท่าทีเดียวกันนี้ก็เกิดขึ้นกับโลกและเศรษฐกิจด้วย
• พฤติกรรมเช่นนี้จะดำเนินต่อไปจนกว่าจะมีการใช้มาตรฐานจริยธรรมขั้นต่ำกับบริษัทที่ดำเนินงานโมเดลภาษาขนาดใหญ่และเทคโนโลยีที่เกี่ยวข้อง และผู้ดูแลเว็บไซต์ก็ไม่มีทางเลือกนอกจากต้องป้องกันตนเอง

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ในบรรดาธุรกิจที่ดูน่าสงสัยอย่างโจ่งแจ้งทั้งหมดที่เพิ่งได้รู้จักมา พร็อกซีที่อยู่อาศัย นี่ช็อกที่สุด
  ได้ไปอ่านรายละเอียดใน https://spur.us/blog/smart-tv-apps-residential-proxy-sdks แล้ว แทบไม่อยากเชื่อว่าสิ่งนี้ถูกกฎหมาย ควรถูกจัดอยู่ในหมวดเดียวกับบอตเน็ตและเรียกว่า บอตเน็ตที่ถูกทำให้ถูกกฎหมาย

  • เป็นธุรกิจที่สมควรถูกประณามจริงๆ แม้จะบอกว่าใช้เฉพาะพาร์ตเนอร์ที่ผ่านการตรวจสอบและอนุมัติแล้ว แต่ก็นึกไม่ออกเลยว่าพร็อกซีที่อยู่อาศัยจะมีการใช้งานที่ชอบธรรมแม้แต่ข้อเดียว มันมีการใช้งานแบบนั้นจริงหรือ?
  • ต้องระมัดระวังกับการ กำกับดูแลพร็อกซีที่อยู่อาศัย ถ้าสร้างกฎเพื่อเล่นงานสิ่งนี้ ก็จะมีสิ่งอื่นๆ อีกมากที่ได้รับผลกระทบไปด้วย นอกเหนือจากบอตเน็ตพร็อกซีที่อยู่อาศัย

• เหยื่ออีกรายคือ ตัวตรวจสอบลิงก์ การตรวจว่ามีลิงก์เสียอยู่ในเว็บหรือไม่กลายเป็นเรื่องที่ยากมาก
  ถ้ามีเวลา ก็น่าจะลองใช้โครงการ Common Crawl เพื่อตรวจสอบว่าเนื้อหายังอยู่หรือไม่

  • ตัวอย่างลิงก์ ที่แอปแชตสร้างฝั่งผู้ส่งก็ได้รับผลกระทบเหมือนกัน เคยดีใจที่ได้มีส่วนเพิ่มฟีเจอร์นี้ให้ gajim ซึ่งเป็นไคลเอนต์ XMPP แต่ในทางปฏิบัติคำขอตัวอย่างลิงก์กลับถูกหน้าจอ “กำลังตรวจสอบว่าคุณเป็นมนุษย์” ขวางไว้บ่อยมากจนชวนหดหู่

• สุดท้ายแล้ว งานที่มีต้นทุนสูง อย่างการแสดงประวัติของรีโพซิทอรีบน GitHub ก็คงจะถูกซ่อนไว้หลังด่านยืนยันตัวตนทั้งหมด ส่วนที่เหลือก็ทำเป็นแบบสแตติกแล้วเสิร์ฟผ่าน CDN

  • มีความกังวลเรื่องการรวมศูนย์และการสอดส่องของภาครัฐ ฯลฯ ดังนั้น CDN ควรเป็น ทางเลือกสุดท้าย และควรรีดประสิทธิภาพจากตัวเซิร์ฟเวอร์เองให้ได้มากขึ้นก่อน
    ในระดับแอปพลิเคชัน การทำคอนเทนต์ให้เป็นสแตติกมากขึ้น ลดการ query ฐานข้อมูล และใช้แคช ย่อมช่วยได้ชัดเจน เราเคยอยู่ในยุคที่ไม่ต้องกังวลเรื่องประสิทธิภาพมากนักเป็นเวลานาน แต่ตอนนี้แม้แต่เว็บเล็กๆ ก็ต้องใส่ใจมากขึ้น และมันยังดีกว่าเห็น “กำลังตรวจสอบเบราว์เซอร์” ของ Cloudflare ไปทั่วทุกที่
    ฉันเคยมีปัญหาบน VPS ขนาดเล็กเพราะวิธีดั้งเดิมของ Apache ที่ fork โปรเซสแยกต่อหนึ่งคำขอ โตมากับการจับ LAMP server เลยคุ้นและสบายใจกับ Apache แต่ก็ไม่ใช่วิธีที่ใช้เครื่องได้คุ้มค่าที่สุด และสุดท้ายประเด็นนั้นสำคัญกว่า แม้ไม่มีข้อมูลเชิงประจักษ์ แต่รู้สึกว่าเซิร์ฟเวอร์อย่าง Caddy น่าจะรับโหลดได้ดีกว่า เลยคิดว่าจะย้ายตอนอัปเกรดเซิร์ฟเวอร์ครั้งหน้า
  • เซิร์ฟเวอร์ Forgejo ของฉันก็เจอสถานการณ์เดียวกัน พยายามจัดการทราฟฟิกมุ่งร้ายต่อเนื่องด้วย Anubis แต่ไม่เข้าใจอย่างถ่องแท้ว่าจะปรับแต่งมันให้เข้ากับทราฟฟิกแบบนั้นได้อย่างไร และก็ไม่ชอบที่จะต้องเจอโจทย์ยืนยันตัวตนที่ช้าด้วยตัวเอง
    ลองใช้ fail2ban เหมือนกัน แต่พอขนาดใหญ่ขึ้นมันก็รับมือได้ไม่ดี สุดท้ายเลยให้ Cloudflare จัดการด้วยกฎความปลอดภัยที่สรุปไว้ในบล็อกโพสต์ แม้จะไม่อยากพึ่ง Cloudflare ระยะยาว แต่พอเห็น กราฟการใช้ CPU ช่วงล่างของบทความก็เปลี่ยนใจ
  • ในทางกลับกัน Git repository กับ crawler เข้ากันได้แย่มาก ลิงก์ที่สร้างแบบไดนามิกทำให้เกิดการระเบิดของจำนวนชุดผสม จนกลายเป็น กับดักครอว์เลอร์ แบบแก้ขัด ดังนั้นถ้าเป็น crawler ที่พอใช้ได้ก็มักจะหลีกเลี่ยง URL ที่มีสตริงเลขฐานสิบหกยาวๆ อยู่ในพาธอย่างจริงจัง
    ทั้งที่ทำให้ Git host มีต้นทุนมหาศาล แต่ก็น่าแปลกที่มีโฮสต์จำนวนมากไม่ตั้งค่า robots.txt เพื่อไม่ให้มัน crawl ลึกเข้าไปถึงภายในรีโพซิทอรี

• ตรงที่บอกว่า “มีคนขอให้เล่ามาตรการที่ใช้ป้องกันไซต์ แต่ด้วยเหตุผลที่เห็นได้ชัด ฉันไม่อยากลงรายละเอียด เพราะแม้ในระดับนี้ก็ยังเป็นการแข่งขันด้านอาวุธ” ฟังแล้วเจ็บปวด
  ฉันเองก็ประสบความสำเร็จพอสมควรในศึกนี้ แต่เพราะ โศกนาฏกรรมของทรัพยากรร่วม ถ้าเปิดเผยมาตรการง่ายๆ ที่ใช้อยู่ มันก็จะได้ผลน้อยลง เป็นหัวข้อที่น่าสนใจมากและมีไอเดียแปลกใหม่หลายอย่างจนอยากเขียนบล็อกถึงมัน แต่ก็ทำไม่ได้ น่าเสียดายจริงๆ