- ผู้ดูแลบล็อกส่วนตัวส่ง Zip Bomb ที่ใช้ gzip เป็นการตอบกลับ HTTP ให้บอตประสงค์ร้าย เพื่อลดการสแกนช่องโหว่ สแปม และการคัดลอกเนื้อหา
- ใช้ประโยชน์จากกระบวนการ Accept-Encoding: gzip, deflate ที่เบราว์เซอร์และครอว์เลอร์ปกติใช้ โดยส่งคืน
200 OK และ Content-Encoding: gzip สำหรับคำขอที่น่าสงสัย
- ไฟล์ gzip ขนาด 1MB จะขยายเป็นประมาณ 1GB เมื่อแตกไฟล์ ส่วนไฟล์ 10MB จะขยายเป็นประมาณ 10GB ทำให้บอตจำนวนมากใช้หน่วยความจำจนหมดหรือหยุดคำขอ
- มิดเดิลแวร์ของเซิร์ฟเวอร์ตรวจสอบ IP ในแบล็กลิสต์และรูปแบบสแปม และหากเข้าเงื่อนไขก็จะส่งไฟล์ Zip Bomb ที่สร้างไว้ล่วงหน้าแล้วจบการประมวลผลคำขอ
- แม้จะตรวจจับและหลบเลี่ยงได้ง่าย จึงไม่ใช่มาตรการป้องกันที่สมบูรณ์ แต่เพียงพอสำหรับใช้กัน บอตแบบง่าย ที่รบกวนเซิร์ฟเวอร์ด้วยการครอว์ลแบบหว่านแห
ทราฟฟิกบอตและที่มาของการใช้ Zip Bomb
- ทราฟฟิกเว็บส่วนใหญ่มาจาก บอต และก็มีการใช้งานที่ถูกต้อง เช่น RSS reader, ครอว์เลอร์ของเสิร์ชเอนจิน และบอต AI ที่ค้นหาเนื้อหาใหม่
- ปัญหาคือ บอตประสงค์ร้าย ที่ดำเนินการโดยสแปมเมอร์ นักคัดลอกเนื้อหา และแฮกเกอร์
- ในที่ทำงานเดิม บอตค้นหาช่องโหว่ของ WordPress แล้วแทรกสคริปต์อันตรายลงในเซิร์ฟเวอร์
- หลังจากนั้นเซิร์ฟเวอร์ดังกล่าวกลายเป็นส่วนหนึ่งของบอตเน็ตที่ใช้ทำ DDoS
- หนึ่งในเว็บไซต์ยุคแรก ๆ ถูกถอดออกจาก Google Search โดยสมบูรณ์เพราะสแปมที่บอตสร้างขึ้น
- หลังจากประสบการณ์เหล่านี้ จึงเริ่มใช้ Zip Bomb เพื่อปกป้องเซิร์ฟเวอร์จากบอตประสงค์ร้าย
วิธีเปลี่ยนการบีบอัด gzip ให้เป็นเครื่องมือป้องกัน
- Zip Bomb คือ ไฟล์บีบอัด ขนาดเล็กที่ขยายเป็นไฟล์ขนาดใหญ่มากระหว่างการแตกไฟล์ จนสร้างภาระให้เครื่อง
- ในยุคแรกของเว็บ การบีบอัด gzip ถูกนำมาใช้เพื่อลดปริมาณข้อมูลที่ส่งในสภาพแวดล้อมอินเทอร์เน็ตช้า
- หากลดไฟล์ HTML ขนาด 50KB เหลือ 10KB ก็ประหยัดการรับส่งข้อมูลได้ 40KB
- บนอินเทอร์เน็ตแบบ dial-up เวลาดาวน์โหลดหน้าเว็บลดจาก 12 วินาทีเหลือ 3 วินาที
- เมื่อส่งคำขอ เบราว์เซอร์จะแจ้งวิธีบีบอัดที่รองรับผ่านเฮดเดอร์
Accept-Encoding: gzip, deflate
- หากเซิร์ฟเวอร์รองรับการบีบอัดด้วย ก็จะส่งคืน เวอร์ชันบีบอัด ของข้อมูลที่คาดไว้
- บอตครอว์ลเว็บก็รองรับการบีบอัดอย่าง gzip เพื่อเก็บข้อมูลจำนวนมากเช่นกัน และคุณสมบัตินี้ถูกนำมาใช้เพื่อการป้องกัน
การตอบกลับที่ส่งให้คำขอประสงค์ร้าย
- บล็อกมักพบบอตที่สแกนช่องโหว่ด้านความปลอดภัยบ่อยครั้ง และส่วนใหญ่จะถูกเพิกเฉย
- หากตัดสินว่าเป็นคำขอที่พยายามฉีดอินพุตอันตรายหรือสำรวจการตอบกลับ จะส่ง การตอบกลับ gzip พร้อม
200 OK
Content-Encoding: gzip
- ขนาดไฟล์ที่ส่งอยู่ที่ 1MB~10MB ตามสถานการณ์
- ไฟล์ 1MB จะขยายเป็นประมาณ 1GB เมื่อแตกไฟล์
- ไฟล์ 10MB จะขยายเป็นประมาณ 10GB เมื่อแตกไฟล์
- บอตเห็นเฮดเดอร์แล้วตัดสินว่าเป็นไฟล์บีบอัด จากนั้นพยายามแตกไฟล์เพื่อหาเนื้อหา
- เมื่อไฟล์ขยายตัวต่อเนื่อง หน่วยความจำจะถูกใช้จนหมด และเซิร์ฟเวอร์หรือสคริปต์อาจแครชได้
- สำหรับสคริปต์ที่ดื้อและไฟล์ 1MB ยังไม่พอ จะส่งไฟล์ 10MB ให้ ซึ่งระบุว่าสคริปต์จะหยุดทำงานทันที
ตัวอย่างการสร้าง Zip Bomb และนำไปใช้กับเซิร์ฟเวอร์
- เมื่อสร้าง Zip Bomb ต้องยอมรับ ความเสี่ยง เพราะอาจทำให้อุปกรณ์ของตนเองแครชหรือเสียหายได้
- ไฟล์ gzip ที่แตกออกมาเป็น 10GB สร้างได้ด้วยคำสั่งต่อไปนี้
dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz
- องค์ประกอบของคำสั่งมีดังนี้
dd: คำสั่งสำหรับคัดลอกหรือแปลงข้อมูลif=/dev/zero: ใช้ไฟล์พิเศษที่สร้างสตรีมไบต์ 0 แบบไม่สิ้นสุดเป็นอินพุตbs=1G: ตั้งขนาดบล็อกเป็น 1GBcount=10: ประมวลผลบล็อก 1GB จำนวน 10 บล็อก เพื่อสร้างข้อมูลศูนย์ขนาด 10GBgzip -c > 10GB.gz: บีบอัดข้อมูลเอาต์พุตด้วย gzip แล้วบันทึกเป็นไฟล์ 10GB.gz
- ในกรณีนี้ ขนาดไฟล์ผลลัพธ์จะอยู่ที่ประมาณ 10MB
- เพิ่ม มิดเดิลแวร์ ในเซิร์ฟเวอร์เพื่อตรวจสอบว่าคำขอปัจจุบันเป็นประสงค์ร้ายหรือไม่
- รักษาแบล็กลิสต์ของ IP ที่สแกนทั้งไซต์ซ้ำ ๆ
- ใช้รูปแบบที่หลังจากฝากสแปมแล้วกลับมาตรวจสอบอีกครั้งว่าสแปมนั้นถูกแสดงบนหน้าเว็บหรือไม่ เป็นส่วนหนึ่งของการตรวจจับด้วย
if (ipIsBlackListed() || isMalicious()) {
header("Content-Encoding: gzip");
header("Content-Length: ". filesize(ZIP_BOMB_FILE_10G)); // 10 MB
readfile(ZIP_BOMB_FILE_10G);
exit;
}
- ต้นทุนคือในบางสถานการณ์เซิร์ฟเวอร์ต้องส่ง ไฟล์ 10MB
- ในกรณีที่บทความกลายเป็นไวรัล จะลดลงมาใช้ไฟล์ 1MB และระบุว่าไฟล์นี้ก็ได้ผลเช่นกัน
ข้อจำกัดและขอบเขตการใช้งาน
- Zip Bomb ไม่ใช่ มาตรการป้องกันที่สมบูรณ์
- ตรวจจับได้ง่าย
- หลบเลี่ยงได้เช่นกัน
- ไคลเอนต์อาจอ่านเนื้อหาเพียงบางส่วนเท่านั้น
- ถึงอย่างนั้นก็เพียงพอในฐานะเครื่องมือสำหรับกัน บอตที่ไม่ซับซ้อน ซึ่งครอว์ลเว็บแบบไม่เลือกและรบกวนเซิร์ฟเวอร์
- ดูตัวอย่างการทำงานได้จากการรีเพลย์ล็อกเซิร์ฟเวอร์: this replay of my server logs
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ราวปี 2001 ผมมี สายเชื่อมต่อแบบคงที่ ที่บ้าน และโฮสต์นู่นนี่บนเครื่อง Linux ที่บ้าน
เพราะอัปเดตของ Windows NT ทำให้หลายระบบเปิดฟีเจอร์เข้ารหัสแบบมองโลกในแง่ดี ที่จะเชื่อมต่อไปยังพอร์ตหนึ่งก่อนเพื่อเจรจา s/wan แล้วค่อยส่งทราฟฟิก TCP ผมเห็นทราฟฟิกแบบนั้นในไฟร์วอลล์บ่อย ๆ เลยไม่ได้คิดว่าเป็นเรื่องใหญ่
แต่มีเครื่องหนึ่งที่พยายามเชื่อมต่อทุกไม่กี่วินาทีอยู่เรื่อย ๆ จนน่ารำคาญมาก ผมพยายามติดต่อผู้ดูแลระบบแล้วแต่ไม่สำเร็จ
สุดท้ายผมแจ้งไปทำนองว่า “ผมกำลังจะเปิดบริการใหม่บนพอร์ตนั้น หวังว่าจะไม่เกิดปัญหา” และพอไม่มีคำตอบ ก็รันเซิร์ฟเวอร์บนพอร์ตนั้นที่อ่าน
/dev/urandomเปิดTCP_NODELAYและอื่น ๆ แล้วอัดข้อมูลสุ่มเข้าไปให้เร็วที่สุดเท่าที่ทำได้เครื่อง NT ที่ตั้งค่าผิดจะเชื่อมต่อเข้ามา ดูดข้อมูลสุ่มไปราว 5 วินาทีแล้วหายไป จากนั้น 5 นาทีต่อมาก็กลับมาอีก กิน ยาแก้บัฟเฟอร์โอเวอร์โฟลว์ แล้วหายไปอีก ทำแบบนี้ซ้ำอยู่หลายสัปดาห์ ก่อนจะหายไปจากอินเทอร์เน็ตโดยสิ้นเชิง
ผมมักนึกภาพว่าคงมีแอดมินบางคนเกาหัวสงสัยว่าทำไมเครื่อง NT ถึงรีบูตไม่หยุด
ทุกคำขอควรมีทั้งเวลาหมดอายุและขีดจำกัดปริมาณข้อมูลที่จะใช้
ผมเลยทำ PDF 100 หน้า ที่ทุกหน้าเป็นสี่เหลี่ยมสีดำขนาดใหญ่ แล้วส่งผ่านเกตเวย์อีเมล-ถึง-แฟกซ์ที่ตอนนั้นยังใหม่อยู่ ภายในหนึ่งชั่วโมงก็มีโทรศัพท์โกรธ ๆ โทรมา แล้วแฟกซ์ก็หยุดไป
ส่วนที่ว่า “พยายามติดต่อผู้ดูแลเครื่อง และนั่นเป็นเรื่องปกติ” น่าสนใจเป็นพิเศษ
หลังจากปล่อยโดเมนหมดอายุ RPi เครื่องนี้ก็ตายทุก 5 นาที ผมนึกว่าเป็นปัญหาไฟเลี้ยง แต่ภายหลังถึงนึกถึง งาน CRON นั้นได้
เหตุผลที่เอาเครื่อง NT มารันบริการแบบนี้มีเป็นพัน ๆ กรณีคือ “เพื่อจะได้ไม่ต้องมีแอดมิน” ซึ่งไม่ควรมองข้าม
ในยุค 90 และต้นยุค 2000 มีเซิร์ฟเวอร์จำนวนมากถูกนำขึ้นอินเทอร์เน็ต และแนวปฏิบัติมาตรฐานทั่วอุตสาหกรรมคือ ใช้ NT เพื่อจะได้ไม่ต้องมีแอดมิน
ตอนเด็ก ๆ ผมเคยทำอะไรโง่ ๆ เล่น ๆ โดยใส่
ln -s /dev/zero index.htmlไว้ในโฮมเพจของตัวเองเบราว์เซอร์สมัยนั้นจัดการเรื่องนี้ได้ไม่ดี แทบจะค้างไปเลย และบางครั้งก็ทำให้ระบบฝั่งไคลเอนต์ตายตามไปด้วย
ภายหลังดูเหมือนว่าเบราว์เซอร์เริ่มตรวจสอบเนื้อหาจริงและหยุดคำขอแบบนั้น
หลายปีต่อมาถึงเปิดมันได้ในที่สุด
squashfsที่มีเฮดเดอร์เหมาะสม ใส่เนื้อหาไม่รู้จบที่ไม่มีแท็กปิด แล้วทำให้เซิร์ฟเวอร์ไม่รายงานขนาดไฟล์ก่อนดาวน์โหลดได้ไหมมีไอเดียไหม?
favicon.icoที่เคยทำให้เบราว์เซอร์ตายน่าจะเป็นอันนี้: https://freedomhacker.net/annoying-favicon-crash-bug-firefox...
/dev/zipbombแล้วก็ได้ทุกวันนี้เบราว์เซอร์แทบทั้งหมดรองรับ zstd และ brotli แล้ว ระเบิดแบบนี้อาจได้ผลยิ่งกว่าเดิมในตอนนี้
ความเห็นเก่า This แสดงอัตราบีบอัด 1.2M:1 ที่น่าทึ่ง และ zstd seems to be doing even better
เพียงแต่ว่าบอทอาจไม่รองรับมาตรฐานการบีบอัดสมัยใหม่
ในทางกลับกัน นั่นอาจเป็นวิธีที่ดีในการกันบอท เพราะเบราว์เซอร์สมัยใหม่ทั้งหมดรองรับ zstd ดังนั้นถ้าบังคับใช้กับ user agent ของเบราว์เซอร์ที่ไม่ได้อยู่ในรายการอนุญาต ก็จะทำให้สแครปเปอร์สับสนโดยอัตโนมัติได้
มันพึ่งพาการสตรีมมุมมองผู้ใช้ทั้งหมดในทุกการโต้ตอบอย่างมาก และถ้าใช้ brotli บน SSE ก็ได้อัตราบีบอัด 200:1[2] ได้ง่าย ๆ
ปัญหาคือผู้ไม่หวังดีสามารถขอสตรีมแบบไม่บีบอัดได้
brotli รองรับโดยเบราว์เซอร์ 98% ดังนั้นผมจึงไม่ส่งข้อมูลให้ไคลเอนต์ที่ไม่รองรับการบีบอัดแบบ brotli และสแครปเปอร์กับบอทจำนวนมากก็ไม่รองรับเหมือนกัน จึงได้ผลค่อนข้างดี
[1] checkboxes demo
https://checkboxes.andersmurphy.com
[2] article on brotli SSE
https://andersmurphy.com/2025/04/15/why-you-should-use-brotl...
เพราะบล็อกข้อมูล
0ที่ถูกบีบอัดด้วย gzip รุ่นแรกนั้นเองมี เอนโทรปีต่ำ และ zst แบบซ้อนลดไฟล์ 10G ให้เหลือ 99 ไบต์ได้แต่ไม่อยากลองเอง
ส่วนที่พูดถึงว่าบอตพบช่องโหว่ของ WordPress ในที่ทำงานเก่า แล้วเอาสคริปต์อันตรายไปใส่ไว้บนเซิร์ฟเวอร์ แม้จะออกนอกประเด็นไปนิดแต่ก็น่าสนุกดี
พอได้รู้ว่าไม่ใช่แค่ฉันคนเดียวที่เจอเหตุการณ์ PHP shell ถูก deploy ลงเซิร์ฟเวอร์ราวกับเวทมนตร์ภายใน 1 ชั่วโมงหลังติดตั้ง WordPress ก็กลับรู้สึกโล่งใจขึ้นมา
ไม่เคยน้อยกว่า 3 ตัว และรับประกันว่ามีเสมอ
ต่อให้ไม่ใช่ชั่วโมงแรก สักวันหนึ่งเมื่อคุณลืมแพตช์ มันก็จะระเบิดในที่สุด
/wp-loginเข้ามามันยังเป็นวิธีที่ดีในการหาบอตด้วย พอเห็น IP ที่ request เส้นทางเกี่ยวกับ CMS ดัง ๆ ก็โยนเข้า หลุม iptables ทันที
พอบอกว่า “ลอง deploy nginx server สำหรับ hello world ตัวแรกดู” ไม่นานก็เริ่มเห็น request แปลก ๆ ใน log ทันที
ฉันเคยทำเรื่องคล้าย ๆ กันกับ ssh ด้วย โดยหาวิธีฆ่า ssh client ที่กำลังเดารหัสผ่าน root ได้
ผลคือ script kiddie หลายคนยิง DDoS ใส่เซิร์ฟเวอร์เล็ก ๆ ของฉัน สุดท้ายเลยเปลี่ยนมาใช้วิธีระบุตัวผู้กระทำที่ชัดเจนว่าทำเรื่องไม่ดี แล้วบล็อก IP ด้วยกฎ firewall แทน
แต่ใน IPv6 เรื่องนี้กำลังยากขึ้น
ถ้าเป็นคนทำเว็บเพจเอง ก็อาจฝัง zip bomb ไว้ในหน้าเว็บผ่านลิงก์ที่ตามนุษย์มองไม่เห็นได้
เช่น anchor ที่เป็นตัวอักษรสีขาวบนพื้นขาว ไม่มี highlight ตอน hover/click บอตก็จะดาวน์โหลดไปตรวจสอบ และ crawler กับ AI scraper ก็เช่นกัน
ปัญหาคือบอตที่เรียบง่ายมาก ๆ ซึ่งท่องเว็บไปเรื่อย ๆ แล้วส่งสแปมหยาบ ๆ ลงทุกฟอร์มที่ดูเหมือนจะถูกโพสต์ได้
ตอนแรกเพิ่ม CAPTCHA แบบง่ายที่เป็นตัวอักษรบิดเบี้ยว ซึ่งกันบอตได้มาก แต่ไม่ทั้งหมด
ดู log ของเซิร์ฟเวอร์แล้วพบว่าบอตพวกนี้ส่ง request แค่สามอย่างอย่างรวดเร็ว คือหน้าที่มีฟอร์ม, รูป CAPTCHA, และ POST request ของข้อมูลฟอร์ม โดยไม่โหลด CSS หรือ JS เลย
ดังนั้นจึงเพิ่ม field เข้าไปในฟอร์มอีกหลายตัวแล้วซ่อนด้วย CSS จากนั้นถ้ามีการส่งอะไรมาใน field เหล่านั้น ก็ให้ request ล้มเหลวและบล็อก session
นอกจากนี้ยังทำให้รูป CAPTCHA เป็นพื้นหลัง CSS และเปลี่ยน
srcเป็นรูปโปร่งใส ผลคือสแปมหยุดสนิท และผู้ใช้จริงไม่สังเกตเห็นอะไรเลยhttps://github.com/skeeto/endlessh
ระหว่างสองอย่างนี้ ดูเหมือนจะง่ายกว่าด้วยซ้ำ
Zip bomb น่าสนุกดี
ฉันเคยเจอช่องโหว่ในผลิตภัณฑ์ความปลอดภัยตัวหนึ่ง ที่ถ้าเป็น zip archive ขนาดใหญ่กว่าค่าหนึ่ง หรือเป็นไฟล์ที่มีสิ่งนั้นอยู่ข้างใน ก็จะไม่ทำ malware scan อย่างถูกต้อง
ในทางปฏิบัติ ถ้าใส่ zip bomb ไว้ในเอกสาร Office XML ผลิตภัณฑ์นั้นก็อาจปล่อยไฟล์ OOXML ผ่านไปได้ แม้ข้างในจะมีมัลแวร์ที่ระบุได้ง่ายก็ตาม
ลอง deploy อันนี้แทนสคริปต์ honeypot ที่ใช้ประจำแล้ว แต่ดูเหมือนจะทำงานได้ไม่ค่อยดี
ดู log ของเว็บเซิร์ฟเวอร์แล้วพบว่าบอตไม่ได้ดาวน์โหลดยาพิษขนาด 10MB ไปทั้งหมด แต่ตัดจบที่ความยาวต่าง ๆ กัน
จนถึงตอนนี้ยังไม่เห็นตัวไหนเอาไปมากกว่าประมาณ 1.5MB
หรือจริง ๆ แล้วมันกำลังทำงานอยู่กันนะ? อาจกำลังถอดรหัสแบบ streaming ทันทีแล้วตายไปก็ได้
เช่น ถ้า log ว่าอ่านไป 1.5MB ก็อาจกำลังถอดรหัสในหน่วยความจำแบบทันทีเป็น 1.5GB แล้ว crash ไปก็ได้
ไม่มีทางตรวจสอบได้
ประมาณคอนเทนต์ที่สร้างแบบไม่สิ้นสุด พร้อมอ้างอิงไปยังหน้าสร้างคอนเทนต์อื่น ๆ เต็มไปหมด
อาจช่วยได้จนกว่า
wgetแบบง่าย ๆ และบอตจะปรับตัวทันเสริมว่า ฉันอยู่ฝั่งบอตนะ แต่ช่วยก็ไม่เป็นไร
บอตบางตัวน่าจะมี hard limit สำหรับขนาด resource ที่จะดาวน์โหลด
จำนวนไม่น้อยเป็นบอตฝึก/สแครปของ LLM ที่น่ารำคาญ ดังนั้นถึงส่ง zip bomb ขนาด 800KB ไปแล้วฆ่ามันไม่ได้ อย่างน้อยก็ทำให้ ทรัพยากรคอมพิวต์ ของฝั่งนั้นสูญเปล่าได้
ควรชี้ไว้ว่าอันนี้ไม่ใช่ไฟล์ zip แบบคลาสสิก แต่เป็น gzip bomb
ไม่ใช่วิธีใช้ zip ซ้อนกันทำให้แอนติไวรัสล้ม แต่ทำงานเหมือนเว็บเพจบีบอัดทั่วไป
เมื่อไม่นานมานี้ โครงสร้างพื้นฐานหลบเลี่ยงการเซ็นเซอร์บางส่วนของ Tor Project เคยถูกรันอยู่บนไซต์เดียวกับบทความบล็อกเกี่ยวกับ zip bomb[0]
ไฟล์ zip หนึ่งในนั้นถูก Google crawl และถูกใส่เข้าไปในรายการโดเมนอันตราย ทำให้ส่วนที่ค่อนข้างสำคัญของเครื่องมือ Snowflake ของ Tor พัง
ใช้เวลาหลายสัปดาห์กว่าจะแก้ได้[1]
[0] https://www.bamsoftware.com/hacks/zipbomb/
[1] https://www.bamsoftware.com/hacks/zipbomb/#safebrowsing
เพื่อป้องกันการอัปโหลดในแอปพลิเคชันของฉัน ฉันสร้าง พาร์ทิชันดิสก์ชั่วคราวขนาดคงที่ ประมาณ 10MB ต่ออัน แล้วแตกไฟล์บีบอัดลงไปในนั้น
ถ้ามีใครอัปโหลดอะไรที่ใหญ่เกินไป ความเสียหายก็จะถูกกักไว้ในนั้น
unzip -p | head -c 10MB