อินเทอร์เน็ตไม่ใช่ที่หลบภัยที่ปลอดภัยอีกต่อไป

 (brainbaking.com)
9 คะแนน โดย GN⁺ 2025-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีกรณีที่เซิร์ฟเวอร์ส่วนตัวล่มจากคำขอจำนวนมหาศาลของ บอตสแครป AI
  • จากการวิเคราะห์ล็อก พบความพยายามเข้าถึงอย่างหนักจากช่วง IP โฮสต์ในสิงคโปร์ของ Alibaba(US) Technology (47.79.*)
  • เนื่องจากใช้ User-Agent ปลอมแปลง ในรูปแบบ Mozilla/5.0 ระบบตรวจจับบอตทั่วไปจึงแทบใช้การไม่ได้
  • ระบบบล็อกอัตโนมัติ ของ Fail2ban และ Nginx ทำงานหนักเกินไป จนต้องบล็อกทั้งช่วง IP ด้วยตนเอง
  • ผู้ดูแลเซิร์ฟเวอร์ส่วนตัวต้องเผชิญการโจมตีซ้ำ ๆ จน สภาพแวดล้อมการโฮสต์ด้วยตนเองหดตัวลง และถูกผลักไปสู่แพลตฟอร์มแบบรวมศูนย์

สาเหตุที่เซิร์ฟเวอร์ล่มและการรับมือเบื้องต้น

  • เมื่อไม่กี่วันก่อน เซิร์ฟเวอร์ขนาดเล็ก ที่ใช้โฮสต์เว็บไซต์หยุดให้บริการชั่วคราวจาก การโจมตีของบอตสแครป
    • ก่อนหน้านี้ก็เคยมีการโจมตีลักษณะคล้ายกัน และกำลังพิจารณานำเครื่องมือป้องกันที่แข็งแกร่งอย่าง Anubis มาใช้
    • การโจมตีที่เกิดซ้ำทำให้ แรงจูงใจในการสร้างสรรค์และความสนุกในฐานะงานอดิเรก ของนักพัฒนารายบุคคลลดลง
  • หลังพบว่าเซิร์ฟเวอร์ตอบสนองช้า เมื่อตรวจสอบด้วยคำสั่ง top ก็พบว่า Gitea และ Fail2ban ใช้ CPU ไปเกือบทั้งหมด
    • แม้จะปิดโปรเซส Gitea แล้ว ภาระของ Fail2ban ก็ยังไม่ลดลง และ Nginx access log เพิ่มขึ้นอย่างผิดปกติ

การวิเคราะห์ล็อกและรูปแบบการโจมตี

  • ในล็อกมีการบันทึก คำขอ HTTP 502 จำนวนมากที่พุ่งเป้าไปยังพาธ /commit/
    • ในส่วนหัวของคำขอ มีการใช้ User-Agent ที่ปลอมเป็นเบราว์เซอร์ทั่วไป เช่น Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
    • เครื่องมือตรวจสอบ User-Agent ส่วนใหญ่มองว่าเป็นทราฟฟิกปกติ ทำให้ หลบเลี่ยงการตรวจจับ ได้
  • IP ที่โจมตีไม่ได้มาจากแหล่งเดียว แต่เกิดจาก หลายที่อยู่ โดยทั้งหมดใช้ช่วง 47.79.* ร่วมกัน
    • จากการตรวจสอบด้วย ipinfo.io พบว่าช่วงดังกล่าวเป็นของ Alibaba(US) Technology Co., Ltd.
    • ในฟอรัมอย่าง PhpBB ก็มีรายงาน กรณีการโจมตี จากช่วง IP เดียวกันเช่นกัน

มาตรการป้องกันและข้อจำกัด

  • Fail2ban วิเคราะห์ Nginx log แบบเรียลไทม์เพื่อใช้กฎบล็อก แต่ เมื่อปริมาณล็อกพุ่งสูงมากจึงประมวลผลไม่ทัน
    • มีการรันสคริปต์เพื่อบล็อก IP ที่พยายามเข้าถึง /commit/ ทันที แต่ก็ยังมี ข้อจำกัดด้านความเร็ว
    • สุดท้ายจึงต้องใช้คำสั่ง iptables เพื่อ บล็อกทั้งช่วง 47.79.0.0/16 ด้วยตนเอง
  • การรับมือเช่นนี้เป็นเพียง วิธีแก้ปัญหาเฉพาะหน้า เท่านั้น และยังมีโอกาสสูงที่การโจมตีจากช่วง IP ใหม่จะเกิดขึ้นต่อไป
    • กำลังพิจารณาใช้ บริการป้องกันภายนอก อย่าง Cloudflare หรือระบบป้องกันขั้นสูงอย่าง Anubis
    • แต่ก็ยังลังเล เพราะไม่ต้องการให้ทราฟฟิกวิ่งผ่าน เซิร์ฟเวอร์ในสหรัฐฯ ที่มีความสามารถในการติดตาม

ความยากลำบากของการดูแลเซิร์ฟเวอร์ส่วนตัว

  • กำลังพิจารณาย้ายอินสแตนซ์ Gitea ไปยัง Codeberg
    • ผู้ดูแลเซิร์ฟเวอร์ส่วนตัวจำนวนมากกำลัง เลิกโฮสต์เอง และย้ายไปใช้แพลตฟอร์มแบบรวมศูนย์ เพราะต้องเจอกับการโจมตีซ้ำแล้วซ้ำเล่า
    • แนวโน้มนี้นำไปสู่ การอ่อนแอลงของความกระจายศูนย์และความเป็นอิสระของอินเทอร์เน็ต
  • บล็อกเกอร์คนอื่น ๆ ก็รายงานความเสียหายจากการโจมตีลักษณะคล้ายกันเช่นกัน และปัญหานี้กำลังขยายไปเป็น ปัญหาของผู้ดูแลเว็บรายเล็กโดยรวม

ความผิดปกติของทราฟฟิกอื่นที่สังเกตพบ

  • พบ Referer header ปลอม ที่อ้างถึงโดเมนบริษัทใหญ่ เช่น bioware.com, mcdonalds.com, microsoft.com
    • ในความเป็นจริง เว็บไซต์เหล่านั้นไม่ได้ให้ลิงก์มา และเกิดทราฟฟิกเพิ่มขึ้นโดย ไม่ทราบจุดประสงค์
  • แม้การโจมตีจะเกิดขึ้นซ้ำอีก ก็ยังแสดง เจตนารมณ์ว่าจะไม่ละทิ้งการโฮสต์ด้วยตนเอง
    • ตอนท้ายบทความย้ำความตั้งใจที่จะดูแลเซิร์ฟเวอร์อิสระต่อไปด้วยประโยค “Get Hostin’ Or Die Tryin’ ”

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

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

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

  • รู้สึกว่าอินเทอร์เน็ตไม่ใช่ พื้นที่ปลอดภัยสำหรับนักพัฒนาซอฟต์แวร์สายงานอดิเรก อีกต่อไป
    ผมดูแลเซิร์ฟเวอร์เองมาตั้งแต่ราวปี 2005 และทันทีที่เซิร์ฟเวอร์ออนไลน์ก็จะถูกโจมตีตลอด
    โดยเฉพาะเมื่อผูกชื่อ DNS หรือใช้ใบรับรอง TLS ดูเหมือนว่าการถูกเปิดเผยใน certificate transparency logs จะยิ่งทำให้การโจมตีหนักขึ้น
    พอเปิดเว็บไซต์สู่สาธารณะก็มีทราฟฟิกอันตรายถาโถมเข้ามา และถ้าไปทำให้องค์กรไหนไม่พอใจ ก็ดูเหมือนจะมีการจ้างคนมาลอง DDoS ด้วย
    ทั้ง crawler, botnet, การโจมตีอัตโนมัติ และคนที่โกรธกัน ล้วนเป็นเรื่องที่เจอทุกปี
    ลองใช้ผู้ให้บริการโฮสติ้งมาหลายเจ้าแล้ว แต่ผลก็คล้ายกัน

    • เมื่อก่อน PHP guestbook ห่วย ๆ ที่ผมเขียนเองเคยกลายเป็น เว็บสแปม XSS ภายในไม่กี่วัน
      พอไม่อัปเดต WordPress ก็โดนฝัง SEO spam ภายในไม่กี่ชั่วโมง และพอเผลอเปิด Redis ออกสู่อินเทอร์เน็ตก็โดนติดตั้ง RAT ของบอตเน็ต
      แต่ผมก็ไม่ได้คิดว่าสิ่งเหล่านี้แปลว่าอินเทอร์เน็ตนั้น ‘อันตราย’
      กลับกัน มันเป็นประสบการณ์ที่สอนว่าผมยังต้องเรียนรู้อะไรอีก
      หลังจากนั้นก็ใช้ star-cert เพื่อไม่ให้โผล่ใน certificate logs, เพิ่ม basic auth, ทำแบ็กอัปไว้ และดูแลระบบอย่างระมัดระวัง
      สิ่งที่อันตรายจริง ๆ น่าจะเป็นคนที่ไม่รู้เรื่องเทคนิคแล้วติดตั้ง exe อะไรก็ได้ พร้อมส่งข้อมูลทุกอย่างให้ Facebook หรือ TikTok มากกว่า
    • ผมก็ใช้โดเมนส่วนตัวเหมือนกัน แม้จะไม่มีใครนอกจากผมเองเข้าใช้งานเลย แต่ก็ยังโดน บอตโจมตี ไม่หยุด
      คำขอส่วนใหญ่เป็นการพยายามโจมตีช่องโหว่ของ WordPress ทั้งที่ผมไม่เคยใช้ WordPress เลย
      ตอนเห็นล็อกครั้งแรกผมช็อกมาก แต่ตอนนี้ก็มองว่าเป็นเรื่องปกติในชีวิตประจำวันไปแล้ว
    • เพื่อแหย่พวกผู้โจมตี ผมทำสิ่งที่เรียกว่า ‘HTTP Adventure’ แล้วเอาไปวางไว้ตามพาธแอดมินยอดนิยม
      ตัวอย่าง: https://www.masswerk.at/wp-admin
    • ราวปี 2008 ผมดูแลเว็บธุรกิจที่มี PageRank 6 แล้วตั้งแต่นั้นมาการโจมตีจาก Script Kiddies ก็เพิ่มขึ้นแบบระเบิด
      เป็นช่วงที่เครื่องมือสำหรับสแกนช่วง IP และค้นหาช่องโหว่อัตโนมัติเริ่มแพร่หลาย
      คิดถึงยุคเว็บช่วงปี 1995~2008 ที่ยังมี Web Rings, Technorati และแฟนไซต์ต่าง ๆ
      อ้างอิง: วิกิ Script Kiddie
    • แทนที่จะบอกว่า “ถูกโจมตีอยู่ตลอด” ความจริงอาจจะอธิบายได้แม่นกว่าว่า ทราฟฟิกถูก ‘ทำให้หารายได้ได้ (monetised)’ ไปแล้ว

  • ผมเคยใช้ zipbomb กันบอต แล้วได้ผลดี
    แต่หลังจาก โพสต์เรื่องนั้นลง HN ก็มีบอตชุดใหม่แห่กันเข้ามาจนเซิร์ฟเวอร์ราคา $6 รับไม่ไหว
    การเสิร์ฟ payload ขนาด 1~10MB ให้กับวันละ 100,000 requests เป็นไปไม่ได้เลย
    หลังจากนั้นผมเลยเล็งเป้าเฉพาะบอตบางตัว แล้วทำ honeypot เพื่อเก็บ IP ก่อนตอบกลับ 403
    ผ่านไปไม่กี่เดือน ทราฟฟิกก็กลับมาสู่ระดับปกติ

    • เทคนิค บล็อกบอต แบบนี้น่าจะมีมูลค่าทางตลาด
      แค่ยังไม่แน่ใจว่าลูกค้าเป้าหมายคือใคร เพราะผู้ใช้ self-hosting ส่วนใหญ่ก็ไม่ได้มีเงินมาก

  • เซิร์ฟเวอร์ cgit ของผมก็โดน scraper เข้ามาตลอดมา 1 ปีแล้ว
    แต่เป็นบอตที่ค่อนข้าง ‘สุภาพ’ เพราะยิงมาแค่ 2~3 ครั้งต่อนาที
    ที่ตลกคือโค้ดที่ผมอัปโหลดทั้งหมดก็ clone ได้ตรงจาก upstream อยู่แล้ว แต่ก็ยังอุตส่าห์มาขูดเอาเอง
    ดูจากล็อกแล้วเป็นระบบอัตโนมัติที่ไม่มีประสิทธิภาพจริง ๆ

  • ถ้าตั้งค่า rate-limiting ของ Nginx เอง ก็แก้ปัญหาได้ง่ายกว่า Fail2ban
    บล็อกอ้างอิง: https://blog.nginx.org/blog/rate-limiting-nginx

  • อาจใช้กับบริการสาธารณะอย่างบล็อกได้ยาก แต่ถ้าเป็น self-hosting ใช้ส่วนตัว แนะนำให้ตั้งค่า การยืนยันตัวตนแบบ mTLS ไว้ที่ reverse proxy
    คำขอที่ไม่มีใบรับรองจะถูกบล็อกทันที และมีแค่อุปกรณ์ของผมเท่านั้นที่เข้าได้
    ตั้งครั้งเดียวแล้วแทบไม่ต้องคอยดูแลอะไรอีก

    • แต่ผมคิดว่า Wireguard ดีกว่า
      ตั้งค่าง่าย และทำงานได้ดีทั้งบน Android กับ iOS
      ตอนนี้ผมตั้งให้บริการ self-hosted ทั้งหมดเข้าถึงได้เฉพาะจากภายใน Wireguard VPN เท่านั้น และเปิดไฟร์วอลล์ไว้แค่พอร์ตของ Wireguard
    • แต่ถ้าเป็นบริการอย่างบล็อกที่คนอื่นต้องเข้าถึงได้ด้วย mTLS ก็ไม่ค่อยสมจริง

  • Anubis กำลังเล่นเกม ‘แมวจับหนู’ กับบอตได้ดี
    แต่มีแค่เจ้าที่มีข้อมูลทราฟฟิกขนาดใหญ่แบบ Cloudflare เท่านั้นที่ทำการบล็อกตามชื่อเสียงของ IP ได้ดี
    ผู้ดูแลรายเล็กมักทำได้แค่บล็อกทั้งช่วง IP ซึ่งไม่มีประสิทธิภาพ
    จึงควรมีโซลูชันแบบ Crowdsec ที่แชร์ข้อมูลชื่อเสียงเพื่อบล็อก IP อันตราย และให้ challenge แบบง่าย ๆ ที่ไม่ต้องพึ่ง JS
    ถ้าทำแนวทางนี้ได้จริง นักพัฒนาสายงานอดิเรกก็น่าจะกลับมารันบริการได้ง่ายขึ้น

  • อินสแตนซ์ Gitea ของผมก็เพิ่งโดน scraping ผ่าน IP และ ASN ที่กระจายตัว
    ถ้าเป็นบริษัท AI ที่มีทุนหนา ก็คงยากจะกันได้แม้ใช้ Anubis
    เลยกำลังคิดเรื่อง ‘วางยาพิษให้ scraper (poisoning)’ — คือส่งข้อมูลขยะไปแทนโค้ด

    • ช่วงนี้ยังมีบริการพร็อกซีที่อ้างว่าเป็น IP แบบ ‘จัดหามาอย่างมีจริยธรรม (residential)’ โผล่มาด้วย
      บริการแบบนี้ยิ่งทำให้การขัดขวาง scraping ยากขึ้น

  • ของที่ได้รับความนิยม สุดท้ายก็มักเข้าสู่วงจร ถูกมวลชนยึดไปจนพัง
    เลยรู้สึกว่าทางแก้เดียวคือย้ายไปพื้นที่ใหม่อยู่เรื่อย ๆ

  • หลังย้าย DNS ไป Cloudflare ก็มี แพ็กเก็ต SYN แปลก ๆ เข้ามาไม่หยุด
    มีคำขอมาที่พอร์ต 443 หรือ 22 ทุกวินาที แต่หลัง SYN-ACK แล้วกลับไม่มีการตอบสนอง
    ดูเหมือนว่าส่วนใหญ่มาจากผู้ให้บริการโฮสต์เกม VPS ในบราซิลและที่อื่น ๆ
    ผมเลยจับแพ็กเก็ต SYN ไปเช็กด้วย RDAP แล้วบล็อกทั้ง subnet ขององค์กรนั้นทิ้งเลย
    ตอนนี้ whitelist ไว้แค่ Google
    ส่วน Digital Ocean ดูเหมือนจะเป็นหนึ่งในแหล่งหลักของทราฟฟิกอันตราย

    • นี่เป็นการโจมตีแบบ สะท้อน SYNACK ชนิดหนึ่ง
      โดย network stack จะพยายามส่งซ้ำ ทำให้ทราฟฟิกถูกขยายและส่งใส่เหยื่อ
    • น่าจะเป็นการโจมตีที่เกี่ยวกับเกม เช่น DDoS ใส่เซิร์ฟเวอร์ Minecraft
      มักมีการปลอม src IP กันเยอะ จึงแนะนำให้ตั้ง rp_filter เป็น strict 
      net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
    • แต่การที่ ISP ตรวจตราพฤติกรรมของผู้ใช้นั้นอันตราย
      เหมือนกับที่บริษัทไฟฟ้าไม่ควรห้ามใช้หลอดไฟสีแดง ผู้ให้บริการก็ไม่ควร ควบคุมทราฟฟิก ของบริการเช่นกัน

  • เหตุผลที่ผมอินกับโพสต์นี้ ไม่ใช่เพราะอินเทอร์เน็ตปลอดภัย แต่เพราะมัน บันทึกความจริงแบบนี้ไว้
    ผมเองก็บล็อก Alibaba /16 กับทั้งช่วงของ AWS อยู่เหมือนกัน

    • แทนที่จะบล็อกช่วง IP เอง การ บล็อกตาม ASN มีประสิทธิภาพกว่า
      ผมใช้สคริปต์ที่ดึงข้อมูล RouteViews มาทุกวันด้วย cron แล้วนำไปใส่ใน iptables
      ตัวอย่างโค้ด: 
      iptables -A BAD_AS -s $ROUTE -j DROP;
    • สำหรับ AWS นั้น ตั้งแต่ปี 2014 ก็ เปิดเผยช่วง IP เป็น JSON อยู่แล้ว
      ก็หวังว่าคลาวด์เจ้าอื่นจะทำแบบนี้เหมือนกัน