แกล้งบอตสแครปเปอร์

 (herman.bearblog.dev)
4 คะแนน โดย GN⁺ 2025-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กล่าวถึงปัญหา บอตสแครปเปอร์ที่ส่งคำขอมากเกินไปจนทำงานคล้าย DDoS กับเว็บไซต์สาธารณะ พร้อมนำเสนอแนวทางเชิงทดลองในการย้อนใช้สิ่งนี้เพื่อถ่วงเวลาให้มันเสียเปล่า
  • สร้าง ตัวสร้างข้อความบนพื้นฐานของ Markov chain เพื่อผลิตข้อมูลปลอมที่ดูเหมือนไฟล์ .php และล่อให้บอตอันตรายดาวน์โหลดไป
  • จากนั้นสร้าง เซิร์ฟเวอร์คอนเทนต์แบบสแตติก ที่สุ่มส่งย่อหน้าจากนวนิยาย Frankenstein และออกแบบโครงสร้างลิงก์ให้ครอว์เลอร์กระจายตัวแบบระเบิด
  • เพิ่ม แอตทริบิวต์ noindex, nofollow และตัวนับจำนวนคำขอในทุกหน้า เพื่อกันเสิร์ชเอนจินปกติออกและจับเฉพาะบอตที่ละเมิดกฎ
  • ผลการทดลองน่าสนใจ แต่มี ความเสี่ยงต่อการตรวจจับ Googlebot ผิดพลาด จึงไม่ใช้กับบริการจริง และคงไว้เป็นโปรเจ็กต์เพื่อการเรียนรู้และทดลอง

ปัญหาของบอตสแครปเปอร์และแนวคิดในการรับมือ

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

ตัวสร้าง PHP ปลอมบนพื้นฐานของ Markov chain

  • ใช้ Rust สร้าง ตัวฝึก Markov chain เพื่อผลิตคอนเทนต์ที่ดูสมจริงจากข้อมูลข้อความตามอำเภอใจ
  • เจาะกลุ่ม บอตอันตรายที่ไล่หาพาธเปราะบาง เช่น .env, .aws, .php โดยส่งโค้ด PHP ปลอมที่ดูเหมือนจริงแต่ไร้ความหมายให้
  • ขยายขนาดไฟล์ตั้งแต่ 2KB ถึง 10MB เพื่อ ทำให้บอตสิ้นเปลืองทรัพยากร
  • ตัวอย่างผลลัพธ์อยู่ในรูปของ โค้ด PHP ปลอมที่น่าเชื่อถือ ซึ่งปนชื่อฟังก์ชันและคอมเมนต์ของ WordPress
  • เป้าหมายคือทำให้บอตเสียเวลาและทรัพยากร รวมถึงทำให้ผู้โจมตีเสียเวลาไปกับการหาช่องโหว่ที่ไม่มีอยู่จริง

การทดลองเรื่องประสิทธิภาพและการให้ข้อมูลแบบสแตติก

  • เมื่อให้บริการไฟล์ขนาดเกิน 1MB บน VPS ก็เกิด ความล่าช้าในการตอบสนองและภาระเซิร์ฟเวอร์ที่เพิ่มขึ้น
  • เพื่อแก้ปัญหานี้จึงสร้าง “garbage server” ในรูปแบบเว็บไซต์สแตติก
    • โหลดนวนิยาย Frankenstein ทั้งเล่มเข้าเมมโมรี และทุกครั้งที่มีคำขอจะส่งคืนย่อหน้าแบบสุ่ม 4 ย่อหน้า
    • เพิ่มลิงก์ 5 รายการไว้ท้ายแต่ละหน้าเพื่อ ล่อให้เกิดการขยายการครอว์ลแบบระเบิด (เพิ่มแบบคูณ 5)
  • ดูผลลัพธ์ได้ที่ https://herm.app/babbler/

รายละเอียดการออกแบบและวิธีการใช้งาน

  • นวนิยายที่เลือกเป็น public domain และเลือกใช้เพราะทำในช่วง ฮาโลวีน รวมถึงมองว่า AI กับ Frankenstein มีความคล้ายกัน
  • ทุกหน้ากำหนด noindex,nofollow เพื่อ จับเฉพาะบอตที่ฝ่าฝืนกฎ
  • ด้านล่างของแต่ละหน้ามี ตัวนับจำนวนครั้งที่ถูกเรียกใช้งาน ซึ่งจะรีเซ็ตเมื่อดีพลอยใหม่เพราะเก็บไว้ในเมมโมรี
  • ยังแยกเซิร์ฟเวอร์สำหรับคำขอ .php โดยเฉพาะ เพื่อ สุ่มส่งไฟล์ PHP จริงจากในเมมโมรี
  • สรุปโปรเจ็กต์ด้วยวลี “Garbage for the garbage king!”

ความเสี่ยงและข้อจำกัด

  • ระบบนี้มี ความเสี่ยงต่อการตรวจจับเสิร์ชเอนจินผิดพลาดหากนำไปใช้กับบริการจริง
    • ถ้า Googlebot มาไล่เก็บ endpoint ผิด ๆ อาจ ถูกจัดเป็นเว็บไซต์สแปม
    • อาจนำไปสู่การแสดงผลในการค้นหาที่ลดลงหรือ มีคำเตือนใน Chrome
  • ดังนั้นจึง ไม่แนะนำสำหรับเว็บไซต์ที่พึ่งพาการค้นหา และใช้งานเพียงเป็นโปรเจ็กต์ทดลอง
  • babbler สำหรับ .php ไม่ใช่ HTML จึง ไม่กระทบ Googlebot และมุ่งเป้าเฉพาะบอตอันตราย

บทสรุปและข้อคิดเห็นส่วนตัว

  • เพิ่ม ลิงก์ซ่อนอยู่ (rel="nofollow") ในบล็อกเพื่อล่อสแครปเปอร์อันตราย
  • หาก โควตาทราฟฟิกของ VPS เกิน ก็พิจารณาใช้ Cloudflare cache
  • โปรเจ็กต์นี้เป็นการทดลองที่ทั้งสนุกและปนความหงุดหงิด พร้อมกับได้เรียนรู้ Markov chain และหลักการทำงานของบอต
  • สุดท้ายแล้ว ไม่ใช่ทุกความพยายามจะต้องใช้งานได้จริงเสมอไป บางครั้งแค่สนุกก็เพียงพอแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-17
ความคิดเห็นจาก Hacker News

  • ต่อให้โลกเปลี่ยนไป ก็สุดท้ายยังต้องเจอปัญหาเดิม ๆ
    เมื่อ 10~15 ปีก่อน ฉันเคยต่อสู้กับพวก บริการติดตามโซเชียลมีเดีย แบรนด์ใหญ่ ๆ จ่ายเงินให้พวกเขาเพื่อติดตามความเห็นบนฟอรัม แต่พวกนั้นกลับมา scrape ชุมชนฟรีที่ฉันดูแลโดยไม่ได้รับอนุญาต และทำให้เซิร์ฟเวอร์มีโหลดเพิ่มขึ้น
    ถึงจะ บล็อกบอต ของพวกเขา พวกมันก็กลับมาโดยเปลี่ยน IP กับ UA อยู่ดี เลยทำฟิลเตอร์ที่สุ่มแทรกชื่อแบรนด์ลงในโพสต์เพื่อทำลายคุณภาพข้อมูลของพวกเขา พอเปิดใช้มาตรการนี้ การ scrape ก็หยุดไปหมดภายในสองวัน

    • ฉันก็มีประสบการณ์คล้ายกัน มีบอตเอา ฟอร์มรับบริจาคของเว็บฉันไปใช้ทดสอบบัตรเครดิต แล้วก็พยายามต่อไปเรื่อย ๆ โดยเปลี่ยน IP ไปมา เลยเปลี่ยนจากการบล็อกเป็นสุ่มส่งข้อความสำเร็จ/ล้มเหลวกลับไปแทน ทำให้ข้อมูลของพวกมันปนเปื้อน และยอมแพ้ไปในไม่กี่วัน
    • เรื่องการวิเคราะห์เฮดเดอร์มีประโยชน์มาก บน เซิร์ฟเวอร์ Fediverse ของฉันเองก็พบบอตที่ใช้ UA เป็น Chrome เวอร์ชันเก่า แต่ไม่ส่ง Accept-Language header มาเลย พอตั้ง nginx ให้คืนค่า 403 ทราฟฟิกก็เริ่มลดลง
    • เหมือนในหนัง The Imitation Game ถ้าตอบสนองทุกคำขอทันที ฝั่งตรงข้ามจะไหวตัวทัน ถ้าจัดการแค่บางคำขอ หรือส่ง รหัสข้อผิดพลาดแบบสุ่ม กลับไป จะตรวจจับได้ยากขึ้น และทำให้การดีบักของพวกเขายากขึ้นมาก
    • บอตส่วนใหญ่ยังคงเลียนแบบ ชุด HTTP header ได้ไม่ดี แม้จะเป็นปี 2025 แล้วก็ยังต้องกรองด้วยวิธีเดิม และบอตก็ยังวิวัฒน์ตามแพตเทิร์นเดิมอยู่
    • สงสัยว่าทำไมการแทรกชื่อบริษัทถึงทำให้บอตหายไป อยากถามว่าเป็นเพราะ สัญญาณข้อมูลถูกปนเปื้อน ระหว่างที่พวกเขาหาคำพูดถึงแบรนด์อยู่หรือเปล่า

  • บอตพวกนี้ไม่ได้ parse ไฟล์ PHP จริง ๆ แต่ใช้การมีอยู่ของไฟล์นั้นเพื่อสร้าง fingerprinting สำหรับตรวจหาช่องโหว่ ดูแค่ response code แล้วก็ทิ้งไปเลย

    • ใช่ ในกรณีแบบนี้เครื่องมืออย่าง fail2ban หรือ crowdsec จะมีประสิทธิภาพกว่า ลองใช้ crowdsec แล้วพบว่าแม้แต่เซิร์ฟเวอร์ที่ทราฟฟิกน้อยก็ยังโดนลองสแกนหาช่องโหว่เยอะมาก
    • ถ้าอย่างนั้นก็น่าจะใช้กลยุทธ์เปิดเผย ช่องโหว่ปลอม เพื่อหลอกล่อบอตได้เหมือนกัน เช่น ล่อบอตอัตโนมัติเข้าไปใน honeypot (honeybot) เพื่อสังเกตการทำงานภายใน ดูเพิ่มเติม: The Cuckoo’s Egg
    • ถ้า LLM scraper พวกนี้เอาการตอบกลับแบบนี้ไปใช้เป็นข้อมูลฝึก ก็อาจเพิ่มความเสี่ยงของ data poisoning ได้ งานวิจัยช่วงหลังก็บอกว่าแค่ข้อมูลไม่กี่จุดก็ทำให้โมเดลพังได้

  • ไม่นานมานี้ได้ยินเรื่อง tarpit สำหรับ AI และ scraper เป็นวิธีที่ไม่ตัดการเชื่อมต่อ แต่ค่อย ๆ ส่งข้อมูลไม่สิ้นสุดอย่างช้ามาก เครื่องมือชื่อ Nepenthes ดูน่าสนใจดี อยากลองเอามาทดลอง

  • เมื่อก่อนถ้าบล็อก scraper บน HN จะโดนด่า มีตรรกะประมาณว่า “จะเข้าถึงยังไงก็เรื่องของฉัน”

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

  • ถ้าคุณดูแล Apache server เอง คุณสามารถใช้ RewriteEngine เพื่อบล็อกคำขอ PHP ได้ทันที

    RewriteEngine On
RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
RewriteCond %{QUERY_STRING} \.php [NC,OR]
RewriteCond %{THE_REQUEST} \.php [NC]
RewriteRule .* - [F,L]

    บนเซิร์ฟเวอร์ของฉันไม่มี PHP ดังนั้นคำขอพวกนี้ทั้งหมดเป็นอันตรายแน่นอน

    • บน nginx ก็ตั้งคล้ายกันได้ สำหรับคำขอ PHP หรือ ASPX จะคืนค่า HTTP 418 “I’m a teapot” 
      location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
error_page 418 /418.html;
      แบบนี้ช่วยให้กรองล็อกได้ง่ายขึ้น ตัวอย่าง: FreeSolitaire.win/wp-login.php

  • scraper เชิงรุกส่วนใหญ่มักเล็ง ช่องโหว่ของ WordPress พวกมันไม่ได้ต้องการไฟล์ PHP เองเท่ากับต้องการ ผลลัพธ์ที่ไฟล์ส่งออกมา การตั้งค่าแบบนี้จึงคล้าย honeypot ชนิดหนึ่ง แต่ถ้าบอตไม่เจอสิ่งที่สคริปต์คาดไว้ มันก็จะไปเอง

    • น่าจะเป็นไปได้ว่าพวกมันใช้ regex หาแพตเทิร์นหน้าเข้าสู่ระบบผู้ดูแล จากผลลัพธ์ ถ้าไม่เจอก็ข้ามทันที พูดอีกอย่างคือ เขียน regex บรรทัดเดียวยังมีประสิทธิภาพกว่าการสร้าง PHP ปลอมขนาด 4KB

  • ก่อนหน้านี้เคยโพสต์เรื่อง กลยุทธ์ zipbomb บน HN แล้วทราฟฟิกพุ่งเป็น 100,000 ครั้งในวันเดียว VPS ราคา $6 รับไม่ไหว ตอนนี้เลยใช้ zipbomb ตอบโต้เฉพาะบอตที่ก้าวร้าวที่สุด ส่วนที่เหลือให้ 403 กลยุทธ์ใหม่ได้ผลดี แต่ก็ยังลังเลว่าจะเปิดเผยอีกไหม ดูเพิ่ม: โพสต์ก่อนหน้า

  • เมื่อก่อนใช้แค่ fail2ban แต่ก็อยากทำ มาตรการป้องกันที่สนุกกว่านี้
    ใน .htaccess จะ redirect path ที่น่าสงสัย (/.git, /wp-login) ไปที่ decoy.php แล้วบังคับให้ดาวน์โหลด decoy.zip ขนาด 10GB
    decoy.php จะทำตัวเหมือนไฟล์สำคัญที่ถูกร้องขอ แต่จริง ๆ แล้วเป็นการสตรีม ล็อกปลอมกับข้อมูล SQL ปลอม แบบไม่สิ้นสุดเพื่อรั้งบอตไว้

  • บอตพวกนี้ไม่ได้มา scrape ไฟล์ PHP แต่กำลังหา ช่องโหว่ของเฟรมเวิร์ก ถ้าให้การตอบกลับที่ไม่คาดคิด พวกมันก็จะยอมแพ้แล้วไปหาเป้าหมายอื่นทันที

  • บางครั้งก็คิดเล่น ๆ ว่า — จะทำให้บอตเอาทรัพยากรที่มันกำลังเผาทิ้งไป ขุดคริปโตเคอร์เรนซี แทนได้ไหม?

    • ถ้าจะลองทำ คงต้องทำให้มัน รัน JavaScript แต่บอตส่วนใหญ่ก็น่าจะมี มาตรการรับมือ กับความพยายามแบบนั้นอยู่แล้ว