ทำไม NginX และ Lighttpd ไม่ได้รับผลกระทบจาก Slowloris

23

ฉันกำลังตรวจสอบช่องโหว่ของSlowlorisและฉันคิดว่าฉันเข้าใจว่าทำไมการโจมตีแบบนี้ถึงได้อย่างไร

สิ่งที่ฉันไม่เข้าใจคือสาเหตุที่ Lighttpd และ NginX ไม่ได้รับผลกระทบ (อ้างอิงจากบทความเดียวกันกับลิงก์ด้านบน) พวกเขาทำอะไรที่แตกต่างกันมาก?

— The Shurrican
แหล่งที่มา

25

Apache มีทฤษฎี 'ลูกค้าสูงสุด'

นั่นคือจำนวนการเชื่อมต่อพร้อมกันที่สามารถจัดการได้ IE หากเซิร์ฟเวอร์ apache มีขีด จำกัด 'ลูกค้าสูงสุด' ที่ 100 และแต่ละคำขอใช้เวลา 1 วินาทีจึงจะเสร็จสมบูรณ์ก็สามารถจัดการได้สูงสุด 100 คำขอต่อวินาที

แอปพลิเคชันเช่น SlowLoris จะท่วมเซิร์ฟเวอร์ด้วยการเชื่อมต่อในตัวอย่างของเราถ้า SlowLoris ส่ง 200 การเชื่อมต่อต่อวินาทีและ Apache สามารถจัดการการเชื่อมต่อได้ 100 ครั้งต่อวินาทีเท่านั้นคิวการเชื่อมต่อจะใหญ่ขึ้นเรื่อย ๆ และใช้หน่วยความจำทั้งหมดบนเครื่อง Hault สิ่งนี้คล้ายกับวิธีการทำงานของ LOIC แบบไม่ระบุชื่อ

NGINX และ Lighttpd (ในหมู่อื่น ๆ ) ไม่มีการเชื่อมต่อสูงสุดพวกเขาใช้เธรดผู้ปฏิบัติงานแทนตามหลักทฤษฏีไม่มีข้อ จำกัด เกี่ยวกับจำนวนการเชื่อมต่อที่สามารถจัดการได้
หากคุณตรวจสอบการเชื่อมต่อ Apache ของคุณคุณจะเห็นว่าการเชื่อมต่อที่ใช้งานอยู่ส่วนใหญ่นั้นเป็นข้อมูล 'ส่ง' หรือ 'รับ' จากไคลเอนต์ ใน NGINX / Lighttpd พวกเขาเพียงเพิกเฉยต่อคำขอเหล่านี้และปล่อยให้พวกเขาทำงานในพื้นหลังไม่ใช้ทรัพยากรของระบบและมันจะต้องดำเนินการเชื่อมต่อกับสิ่งที่เกิดขึ้น (แยกการตอบสนองการอ่านข้อมูลจากเซิร์ฟเวอร์แบ็กเอนด์เป็นต้น)

ฉันตอบคำถามคล้าย ๆ กันในบ่ายวันนี้ดังนั้นข้อมูลในนั้นอาจจะน่าสนใจสำหรับคุณลดการรอคิว Apache

— รอยเปื้อน
แหล่งที่มา

คำตอบที่ดีและมีรายละเอียดมาก +1

— Oldskool

6

การแก้ไขเล็กน้อย: nginx ไม่ได้ใช้เธรดผู้ปฏิบัติงานเพื่อให้ได้การเชื่อมต่อจำนวนมาก จากnginx.org : "Nginx ไม่พึ่งพาเธรดเพื่อจัดการกับคำขอ แต่ใช้สถาปัตยกรรม (อะซิงโครนัส) ที่ขับเคลื่อนด้วยเหตุการณ์ที่ปรับขนาดได้มากขึ้น"

— วันที่

2

แม้ว่าจะมีผลข้างเคียงที่เป็นไปได้ความตั้งใจของ Slowloris ไม่ใช่เพื่อ "ใช้หน่วยความจำทั้งหมดในเครื่อง" แต่จะหมดความจุสูงสุดในการเชื่อมต่อซึ่งปฏิเสธการเชื่อมต่อที่ตามมาจากการประสบความสำเร็จ

— wulfgarpro

@Day Nginx ใช้เธรดผู้ปฏิบัติงานเพื่อสนับสนุนการดำเนินการแบบอะซิงโครนัส แผนผังสถาปัตยกรรมแอปพลิเคชันที่มีประโยชน์มีให้ที่นี่: aosabook.org/en/nginx.html#fig.nginx.arch

— Terry Burton

13

Nginx มีความเสี่ยงต่อการโจมตีช้า ทรัพยากรที่ขาดแคลนคือจำนวนสูงสุดของการเชื่อมต่อผู้ปฏิบัติงานพร้อมกัน หมายเลขนี้สามารถคำนวณได้เป็นworker_connections * worker_processesและเท่ากับ 512 ในการกำหนดค่า nginx เริ่มต้น ดังนั้นจึงเป็นเรื่องง่ายมากที่จะลง Nginx ที่ไม่มีการป้องกันด้วยเครื่องมือเช่นgoloris

— valyala
แหล่งที่มา

golorisดูเหมือนเครื่องมือที่ฉันต้องการเพื่อให้แน่ใจว่าการนำไปใช้งาน / การตั้งค่าของฉันทำงานได้อย่างที่คาดไว้!

— Alexis Wilke

8

ควรยอมรับความคิดเห็นของ valyala เป็นคำตอบ

เซิร์ฟเวอร์ nginx ส่วนใหญ่ใช้การกำหนดค่าเริ่มต้นดังนั้นจึงมีความเสี่ยงต่อการโจมตีช้า ฉันใช้ slowloris เพื่อจัดการเว็บไซต์ nginx ของเพื่อนบางคนที่ใช้เฉพาะแล็ปท็อปของฉันและโดยปกติจะใช้เวลาน้อยกว่า 5 นาที (เพื่อนของฉันท้าให้ฉันทำเช่นนั้น)

ตามที่ valyala ระบุไว้ในทางเทคนิค nginx ไม่ได้รับผลกระทบจาก slowloris แต่การกำหนดค่าเริ่มต้นจะ จำกัด จำนวนการเชื่อมต่อสูงสุดดังนั้นเมื่อการเชื่อมต่อมีจำนวนเกินจำนวนนั้น nginx จะส่งคำขอใหม่ซึ่งส่งผลให้เกิดการปฏิเสธบริการ

วิธีที่รู้จักกันในการป้องกัน nginx จาก slowloris รวมถึงการ จำกัด จำนวนการเชื่อมต่อจาก IP เดียวกันและเพิ่มการกำหนดค่า การโจมตียังคงใช้ได้ แต่จะยากขึ้น (อาจใช้เวลามากกว่า 5 นาทีหรือไม่: D)

— เหงียนฟานตัน
แหล่งที่มา