DDoS เพื่อช่วยเหลือ: วิธีดำเนินการทดสอบความเครียดและโหลด

Variti พัฒนาการป้องกันบอทและการโจมตี DDoS และยังดำเนินการทดสอบความเครียดและโหลดอีกด้วย ในการประชุม HighLoad++ 2018 เราได้พูดคุยเกี่ยวกับวิธีรักษาความปลอดภัยทรัพยากรจากการโจมตีประเภทต่างๆ กล่าวโดยย่อ: แยกส่วนต่าง ๆ ของระบบ ใช้บริการคลาวด์และ CDN และอัปเดตเป็นประจำ แต่คุณยังคงไม่สามารถจัดการการป้องกันได้หากไม่มีบริษัทที่เชี่ยวชาญ :)

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

การบันทึกวิดีโอของรายงาน

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

เราทำงานอย่างไร

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

สมมุติฐาน

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

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

สถาปัตยกรรมที่ดีเป็นพื้นฐานของความยั่งยืน
ความทนทานต่อข้อผิดพลาดของทรัพยากรและความสามารถในการทนต่อการโจมตีและโหลดควรวางไว้ในขั้นตอนการออกแบบอันที่จริงในขั้นตอนของการวาดผังงานแรกในสมุดบันทึก เพราะหากข้อผิดพลาดร้ายแรงคืบคลานเข้ามาก็สามารถแก้ไขได้ในอนาคตแต่จะเป็นเรื่องยากมาก

ไม่เพียงแต่โค้ดควรจะดีเท่านั้น แต่ยังรวมถึงการกำหนดค่าด้วย
หลายๆ คนคิดว่าทีมพัฒนาที่ดีคือเครื่องรับประกันการบริการที่ทนทานต่อข้อผิดพลาด ทีมพัฒนาที่ดีนั้นมีความจำเป็นจริงๆ แต่ก็ต้องมีการปฏิบัติการที่ดี DevOps ที่ดีด้วย นั่นคือเราต้องการผู้เชี่ยวชาญที่จะกำหนดค่า Linux และเครือข่ายอย่างถูกต้อง เขียนการกำหนดค่าอย่างถูกต้องใน nginx ตั้งค่าขีดจำกัด ฯลฯ มิฉะนั้น ทรัพยากรจะทำงานได้ดีในการทดสอบเท่านั้น และเมื่อถึงจุดหนึ่ง ทุกอย่างจะใช้งานจริงไม่ได้

ความแตกต่างระหว่างการทดสอบโหลดและการทดสอบความเครียด
การทดสอบโหลดช่วยให้คุณสามารถระบุขีดจำกัดของการทำงานของระบบได้ การทดสอบภาวะวิกฤตมีจุดมุ่งหมายเพื่อค้นหาจุดอ่อนในระบบและใช้เพื่อทำลายระบบนี้และดูว่าจะมีพฤติกรรมอย่างไรในกระบวนการล้มเหลวของชิ้นส่วนบางส่วน ในกรณีนี้ ลูกค้ามักจะยังไม่ทราบลักษณะของโหลดก่อนที่จะเริ่มการทดสอบภาวะวิกฤต

คุณสมบัติที่โดดเด่นของการโจมตี L7

โดยปกติเราจะแบ่งประเภทของภาระออกเป็นภาระที่ระดับ L7 และ L3&4 L7 เป็นโหลดที่ระดับแอปพลิเคชัน ส่วนใหญ่มักจะหมายถึงเฉพาะ HTTP แต่เราหมายถึงโหลดใดๆ ที่ระดับโปรโตคอล TCP
การโจมตี L7 มีคุณสมบัติที่โดดเด่นบางประการ ประการแรกพวกเขามาที่แอปพลิเคชันโดยตรงนั่นคือไม่น่าจะสะท้อนให้เห็นผ่านวิธีการเครือข่าย การโจมตีดังกล่าวใช้ตรรกะ และด้วยเหตุนี้ การโจมตีดังกล่าวจึงใช้ CPU, หน่วยความจำ, ดิสก์, ฐานข้อมูล และทรัพยากรอื่นๆ อย่างมีประสิทธิภาพมากและมีการรับส่งข้อมูลเพียงเล็กน้อย

HTTP น้ำท่วม

ในกรณีของการโจมตีใดๆ โหลดจะสร้างได้ง่ายกว่าการจัดการ และในกรณีของ L7 ก็เป็นเช่นนั้นเช่นกัน ไม่ใช่เรื่องง่ายเสมอไปที่จะแยกแยะทราฟฟิกการโจมตีจากทราฟฟิกที่ถูกต้อง และโดยส่วนใหญ่สามารถทำได้ตามความถี่ แต่หากวางแผนทุกอย่างอย่างถูกต้อง ก็จะเป็นไปไม่ได้ที่จะเข้าใจจากบันทึกว่าการโจมตีอยู่ที่ไหนและคำขอที่ถูกต้องนั้นอยู่ที่ไหน
เป็นตัวอย่างแรก ให้พิจารณาการโจมตี HTTP Flood กราฟแสดงให้เห็นว่าการโจมตีดังกล่าวมักจะมีพลังมาก ในตัวอย่างด้านล่าง จำนวนคำขอสูงสุดเกิน 600 คำขอต่อนาที

HTTP Flood เป็นวิธีที่ง่ายที่สุดในการสร้างโหลด โดยทั่วไปแล้วจะใช้เครื่องมือทดสอบโหลดบางประเภท เช่น ApacheBench และตั้งค่าคำขอและเป้าหมาย ด้วยวิธีการง่ายๆ ดังกล่าว มีความเป็นไปได้สูงที่จะเกิดการแคชของเซิร์ฟเวอร์ แต่ก็สามารถหลีกเลี่ยงได้ง่าย ตัวอย่างเช่น การเพิ่มสตริงแบบสุ่มในคำขอ ซึ่งจะบังคับให้เซิร์ฟเวอร์แสดงหน้าเว็บใหม่อย่างต่อเนื่อง
นอกจากนี้อย่าลืมเกี่ยวกับ user-agent ในกระบวนการสร้างโหลด ตัวแทนผู้ใช้ของเครื่องมือทดสอบยอดนิยมจำนวนมากถูกกรองโดยผู้ดูแลระบบ และในกรณีนี้โหลดอาจไม่ถึงแบ็คเอนด์ คุณสามารถปรับปรุงผลลัพธ์ได้อย่างมากโดยการแทรกส่วนหัวที่ถูกต้องจากเบราว์เซอร์ลงในคำขอ
การโจมตีแบบ HTTP Flood นั้นเรียบง่ายพอ ๆ กับการโจมตี พวกมันก็มีข้อเสียเช่นกัน ประการแรก ต้องใช้พลังงานจำนวนมากเพื่อสร้างโหลด ประการที่สอง การโจมตีดังกล่าวตรวจพบได้ง่ายมาก โดยเฉพาะอย่างยิ่งหากมาจากที่อยู่เดียว เป็นผลให้คำขอเริ่มถูกกรองทันทีโดยผู้ดูแลระบบหรือแม้แต่ในระดับผู้ให้บริการ

สิ่งที่จะค้นหา

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

จะดูได้ที่ไหน

เมื่อเราสแกนทรัพยากรก่อนการทดสอบ แน่นอนว่าเราจะดูที่ไซต์ก่อน เรากำลังมองหาช่องป้อนข้อมูลทุกประเภท ไฟล์ขนาดใหญ่ โดยทั่วไป ทุกอย่างที่สามารถสร้างปัญหาให้กับทรัพยากรและทำให้การดำเนินงานช้าลง เครื่องมือพัฒนาทั่วไปใน Google Chrome และ Firefox ช่วยได้ที่นี่ โดยแสดงเวลาตอบสนองของหน้า
เรายังสแกนโดเมนย่อยด้วย ตัวอย่างเช่น มีร้านค้าออนไลน์บางแห่ง abc.com และมีโดเมนย่อย admin.abc.com เป็นไปได้มากว่านี่คือแผงผู้ดูแลระบบที่ได้รับอนุญาต แต่ถ้าคุณใส่ภาระลงไปก็สามารถสร้างปัญหาให้กับทรัพยากรหลักได้
ไซต์อาจมีโดเมนย่อย api.abc.com เป็นไปได้มากว่านี่คือทรัพยากรสำหรับแอปพลิเคชันบนมือถือ แอปพลิเคชันสามารถพบได้ใน App Store หรือ Google Play ติดตั้งจุดเชื่อมต่อพิเศษ วิเคราะห์ API และลงทะเบียนบัญชีทดสอบ ปัญหาคือผู้คนมักคิดว่าสิ่งใดก็ตามที่ได้รับการคุ้มครองโดยการอนุญาตนั้นจะไม่ได้รับผลกระทบจากการโจมตีแบบปฏิเสธการให้บริการ สมมุติว่าการอนุญาตเป็น CAPTCHA ที่ดีที่สุด แต่ก็ไม่ใช่ การสร้างบัญชีทดสอบ 10-20 บัญชีเป็นเรื่องง่าย แต่ด้วยการสร้างบัญชีเหล่านี้ เราจึงสามารถเข้าถึงฟังก์ชันที่ซับซ้อนและซ่อนเร้นได้
โดยปกติแล้ว เราจะดูประวัติที่ robots.txt และ WebArchive, ViewDNS และมองหาทรัพยากรเวอร์ชันเก่า บางครั้งมันเกิดขึ้นที่นักพัฒนาได้เปิดตัวเช่น mail2.yandex.net แต่เวอร์ชันเก่าคือ mail.yandex.net ยังคงอยู่ ไม่รองรับ mail.yandex.net นี้อีกต่อไป ทรัพยากรการพัฒนาไม่ได้รับการจัดสรร แต่ยังคงใช้ฐานข้อมูลต่อไป ดังนั้น เมื่อใช้เวอร์ชันเก่า คุณจะสามารถใช้ทรัพยากรของแบ็กเอนด์และทุกสิ่งที่อยู่ด้านหลังเลย์เอาต์ได้อย่างมีประสิทธิภาพ แน่นอนว่าสิ่งนี้ไม่ได้เกิดขึ้นเสมอไป แต่เราก็ยังเจอสิ่งนี้ค่อนข้างบ่อย
โดยปกติแล้ว เราจะวิเคราะห์พารามิเตอร์คำขอและโครงสร้างคุกกี้ทั้งหมด คุณสามารถพูดได้ว่าดัมพ์ค่าบางส่วนลงในอาร์เรย์ JSON ภายในคุกกี้ สร้างการซ้อนจำนวนมาก และทำให้ทรัพยากรทำงานเป็นเวลานานอย่างไม่มีเหตุผล

โหลดการค้นหา

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

หากไม่มีการค้นหา?

หากไม่มีการค้นหา ไม่ได้หมายความว่าไซต์นั้นไม่มีช่องป้อนข้อมูลที่มีช่องโหว่อื่นๆ ฟิลด์นี้อาจได้รับอนุญาต ในปัจจุบัน นักพัฒนาต้องการสร้างแฮชที่ซับซ้อนเพื่อปกป้องฐานข้อมูลการเข้าสู่ระบบจากการโจมตีตารางสีรุ้ง นี่เป็นสิ่งที่ดี แต่แฮชดังกล่าวใช้ทรัพยากร CPU จำนวนมาก การอนุญาตที่ผิดพลาดจำนวนมากนำไปสู่ความล้มเหลวของตัวประมวลผล และส่งผลให้ไซต์หยุดทำงาน
การปรากฏบนเว็บไซต์ทุกรูปแบบสำหรับความคิดเห็นและข้อเสนอแนะเป็นเหตุผลในการส่งข้อความขนาดใหญ่มากที่นั่นหรือเพียงแค่สร้างน้ำท่วมใหญ่ บางครั้งเว็บไซต์ยอมรับไฟล์ที่แนบมา รวมถึงไฟล์ในรูปแบบ gzip ด้วย ในกรณีนี้ เราใช้ไฟล์ขนาด 1TB บีบอัดเป็นหลายไบต์หรือกิโลไบต์โดยใช้ gzip แล้วส่งไปที่ไซต์ จากนั้นจะถูกคลายซิปและได้รับเอฟเฟกต์ที่น่าสนใจมาก

ส่วนที่เหลือ API

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

กำลังโหลดเนื้อหาจำนวนมาก

หากเราได้รับการเสนอให้ทดสอบแอปพลิเคชันหน้าเดียว หน้า Landing Page หรือเว็บไซต์นามบัตรทั่วไปที่ไม่มีฟังก์ชันการทำงานที่ซับซ้อน เราจะมองหาเนื้อหาจำนวนมาก ตัวอย่างเช่น รูปภาพขนาดใหญ่ที่เซิร์ฟเวอร์ส่ง ไฟล์ไบนารี เอกสาร PDF เราพยายามดาวน์โหลดทั้งหมดนี้ การทดสอบดังกล่าวโหลดระบบไฟล์ได้ดีและอุดตันช่องสัญญาณ ดังนั้นจึงมีประสิทธิภาพ นั่นคือแม้ว่าคุณจะไม่ปิดเซิร์ฟเวอร์ แต่ดาวน์โหลดไฟล์ขนาดใหญ่ด้วยความเร็วต่ำ คุณก็จะอุดตันช่องสัญญาณของเซิร์ฟเวอร์เป้าหมายจากนั้นการปฏิเสธการบริการก็จะเกิดขึ้น
ตัวอย่างของการทดสอบดังกล่าวแสดงให้เห็นว่าที่ความเร็ว 30 RPS ไซต์หยุดตอบสนองหรือสร้างข้อผิดพลาดของเซิร์ฟเวอร์ครั้งที่ 500

อย่าลืมเกี่ยวกับการตั้งค่าเซิร์ฟเวอร์ คุณมักจะพบว่ามีคนซื้อเครื่องเสมือน ติดตั้ง Apache ที่นั่น กำหนดค่าทุกอย่างตามค่าเริ่มต้น ติดตั้งแอปพลิเคชัน PHP และด้านล่างคุณจะเห็นผลลัพธ์

ที่นี่โหลดไปที่รูทและมีเพียง 10 RPS เรารอ 5 นาทีและเซิร์ฟเวอร์ขัดข้อง เป็นเรื่องจริงที่ไม่ทราบแน่ชัดว่าทำไมเขาถึงล้ม แต่มีข้อสันนิษฐานว่าเขามีความทรงจำมากเกินไปจึงหยุดตอบสนอง

ตามคลื่น

ในช่วงหนึ่งหรือสองปีที่ผ่านมา การโจมตีด้วยคลื่นได้รับความนิยมอย่างมาก นี่เป็นเพราะความจริงที่ว่าหลายองค์กรซื้อฮาร์ดแวร์บางชิ้นสำหรับการป้องกัน DDoS ซึ่งต้องใช้เวลาพอสมควรในการสะสมสถิติเพื่อเริ่มกรองการโจมตี นั่นคือพวกเขาไม่ได้กรองการโจมตีในช่วง 30-40 วินาทีแรก เนื่องจากจะรวบรวมข้อมูลและเรียนรู้ ดังนั้นภายใน 30-40 วินาทีนี้ คุณสามารถเปิดใช้งานได้มากมายบนไซต์โดยที่ทรัพยากรจะอยู่เป็นเวลานานจนกว่าคำขอทั้งหมดจะถูกล้าง
ในกรณีของการโจมตีด้านล่าง จะมีช่วงเวลา 10 นาที หลังจากนั้นการโจมตีส่วนที่ได้รับการแก้ไขใหม่ก็มาถึง

นั่นคือการป้องกันได้เรียนรู้ เริ่มกรอง แต่การโจมตีส่วนใหม่ที่แตกต่างไปจากเดิมอย่างสิ้นเชิงมาถึง และการป้องกันก็เริ่มเรียนรู้อีกครั้ง ในความเป็นจริง การกรองหยุดทำงาน การป้องกันไม่มีประสิทธิภาพ และไซต์ไม่สามารถใช้งานได้
การโจมตีแบบ Wave มีลักษณะเป็นค่าที่สูงมากที่จุดสูงสุด โดยสามารถเข้าถึงหนึ่งแสนหรือล้านคำขอต่อวินาที ในกรณีของ L7 หากเราพูดถึง L3&4 อาจมีการรับส่งข้อมูลได้หลายร้อยกิกะบิต หรือตามนั้น อาจมี mpps หลายร้อยหากคุณนับเป็นแพ็กเก็ต
ปัญหาของการโจมตีดังกล่าวคือการซิงโครไนซ์ การโจมตีมาจากบ็อตเน็ตและจำเป็นต้องมีการซิงโครไนซ์ในระดับสูงเพื่อสร้างการขัดขวางครั้งใหญ่เพียงครั้งเดียว และการประสานงานนี้ไม่ได้ผลเสมอไป: บางครั้งผลลัพธ์ก็เป็นจุดสูงสุดแบบพาราโบลาซึ่งดูค่อนข้างน่าสมเพช

ไม่ใช่ HTTP เพียงอย่างเดียว

นอกจาก HTTP ที่ L7 แล้ว เรายังต้องการใช้ประโยชน์จากโปรโตคอลอื่นๆ ตามกฎแล้ว เว็บไซต์ทั่วไป โดยเฉพาะโฮสติ้งทั่วไป จะมีโปรโตคอลเมลและ MySQL ที่ไม่ชัดเจน โปรโตคอลเมลอาจมีการโหลดน้อยกว่าฐานข้อมูล แต่ก็สามารถโหลดได้อย่างมีประสิทธิภาพและจบลงด้วย CPU ที่โอเวอร์โหลดบนเซิร์ฟเวอร์
เราค่อนข้างประสบความสำเร็จในการใช้ช่องโหว่ SSH ปี 2016 ขณะนี้ช่องโหว่นี้ได้รับการแก้ไขแล้วสำหรับเกือบทุกคน แต่ไม่ได้หมายความว่าไม่สามารถส่งโหลดไปยัง SSH ได้ สามารถ. มีการอนุญาตจำนวนมาก SSH กิน CPU เกือบทั้งหมดบนเซิร์ฟเวอร์ จากนั้นเว็บไซต์ก็ล่มสลายจากหนึ่งหรือสองคำขอต่อวินาที ดังนั้น คำขอหนึ่งหรือสองคำขอที่อิงตามบันทึกนี้จึงไม่สามารถแยกความแตกต่างจากโหลดที่ถูกต้องได้
การเชื่อมต่อจำนวนมากที่เราเปิดในเซิร์ฟเวอร์ยังคงมีความเกี่ยวข้องอยู่ ก่อนหน้านี้ Apache มีความผิดในเรื่องนี้ ตอนนี้ nginx ประสบปัญหานี้จริง ๆ เนื่องจากมักได้รับการกำหนดค่าตามค่าเริ่มต้น จำนวนการเชื่อมต่อที่ nginx สามารถเปิดไว้นั้นมีจำกัด ดังนั้นเราจึงเปิดการเชื่อมต่อตามจำนวนนี้ nginx จะไม่ยอมรับการเชื่อมต่อใหม่อีกต่อไป และด้วยเหตุนี้ ไซต์จึงไม่ทำงาน
คลัสเตอร์การทดสอบของเรามี CPU เพียงพอที่จะโจมตีการจับมือ SSL ตามหลักการแล้ว ดังที่แสดงให้เห็นในทางปฏิบัติ บางครั้งบอตเน็ตก็ชอบทำเช่นนี้เช่นกัน ในด้านหนึ่ง เห็นได้ชัดว่าคุณไม่สามารถทำได้หากไม่มี SSL เนื่องจากผลลัพธ์ของ Google การจัดอันดับ และความปลอดภัย ในทางกลับกัน SSL มีปัญหาเกี่ยวกับ CPU

L3&4

เมื่อเราพูดถึงการโจมตีที่ระดับ L3&4 เรามักจะพูดถึงการโจมตีที่ระดับลิงก์ โหลดดังกล่าวแทบจะแยกแยะได้จากโหลดที่ถูกต้อง เว้นแต่จะเป็นการโจมตี SYN-flood ปัญหาของการโจมตี SYN-flood สำหรับเครื่องมือรักษาความปลอดภัยคือมีปริมาณมาก ค่า L3&4 สูงสุดคือ 1,5-2 Tbit/s การรับส่งข้อมูลประเภทนี้ประมวลผลได้ยากแม้แต่กับบริษัทขนาดใหญ่ รวมถึง Oracle และ Google
SYN และ SYN-ACK เป็นแพ็กเก็ตที่ใช้เมื่อสร้างการเชื่อมต่อ ดังนั้นน้ำท่วม SYN จึงแยกแยะได้ยากจากภาระที่ถูกต้อง: ไม่ชัดเจนว่านี่คือ SYN ที่สร้างการเชื่อมต่อหรือเป็นส่วนหนึ่งของน้ำท่วม

UDP-น้ำท่วม

โดยปกติแล้ว ผู้โจมตีจะไม่มีความสามารถเท่าที่เรามี ดังนั้นจึงสามารถใช้การขยายสัญญาณเพื่อจัดระเบียบการโจมตีได้ นั่นคือผู้โจมตีจะสแกนอินเทอร์เน็ตและค้นหาเซิร์ฟเวอร์ที่มีช่องโหว่หรือกำหนดค่าไม่ถูกต้อง เช่น เพื่อตอบสนองต่อแพ็กเก็ต SYN เดียว ให้ตอบสนองด้วย SYN-ACK สามตัว ด้วยการปลอมแปลงที่อยู่ต้นทางจากที่อยู่ของเซิร์ฟเวอร์เป้าหมาย คุณสามารถเพิ่มพลังได้ XNUMX เท่าด้วยแพ็กเก็ตเดียว และเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังเหยื่อ

ปัญหาเกี่ยวกับการขยายเสียงคือตรวจจับได้ยาก ตัวอย่างล่าสุด ได้แก่ กรณีที่น่าตื่นเต้นของ Memcached ที่มีช่องโหว่ นอกจากนี้ ขณะนี้มีอุปกรณ์ IoT, กล้อง IP จำนวนมาก ซึ่งส่วนใหญ่กำหนดค่าตามค่าเริ่มต้นเช่นกัน และโดยค่าเริ่มต้นจะมีการกำหนดค่าไม่ถูกต้อง ซึ่งเป็นเหตุผลว่าทำไมผู้โจมตีจึงมักทำการโจมตีผ่านอุปกรณ์ดังกล่าว

SYN-น้ำท่วมที่ยากลำบาก

SYN-flood น่าจะเป็นการโจมตีประเภทที่น่าสนใจที่สุดจากมุมมองของนักพัฒนา ปัญหาคือผู้ดูแลระบบมักใช้การบล็อก IP เพื่อป้องกัน ยิ่งไปกว่านั้น การบล็อก IP ไม่เพียงส่งผลต่อผู้ดูแลระบบที่ใช้สคริปต์เท่านั้น แต่ยังรวมถึงระบบรักษาความปลอดภัยบางระบบที่ซื้อมาด้วยเงินจำนวนมากด้วย
วิธีการนี้อาจกลายเป็นหายนะได้ เพราะหากผู้โจมตีเปลี่ยนที่อยู่ IP บริษัทจะบล็อกเครือข่ายย่อยของตัวเอง เมื่อไฟร์วอลล์บล็อกคลัสเตอร์ของตัวเอง ผลลัพธ์จะล้มเหลวในการโต้ตอบภายนอก และทรัพยากรจะล้มเหลว
นอกจากนี้การบล็อคเครือข่ายของคุณเองก็ไม่ใช่เรื่องยาก หากสำนักงานของลูกค้ามีเครือข่าย Wi-Fi หรือหากประสิทธิภาพของทรัพยากรถูกวัดโดยใช้ระบบการตรวจสอบต่างๆ เราจะนำที่อยู่ IP ของระบบการตรวจสอบนี้หรือ Wi-Fi สำนักงานของลูกค้าและใช้เป็นแหล่งที่มา ท้ายที่สุด ดูเหมือนว่าทรัพยากรจะพร้อมใช้งาน แต่ที่อยู่ IP เป้าหมายถูกบล็อก ดังนั้น เครือข่าย Wi-Fi ของการประชุม HighLoad ซึ่งมีการนำเสนอผลิตภัณฑ์ใหม่ของบริษัทอาจถูกบล็อก และทำให้เกิดต้นทุนทางธุรกิจและเศรษฐกิจบางประการ
ในระหว่างการทดสอบ เราไม่สามารถใช้การขยายสัญญาณผ่าน memcached กับทรัพยากรภายนอกใดๆ ได้ เนื่องจากมีข้อตกลงที่จะส่งการรับส่งข้อมูลไปยังที่อยู่ IP ที่อนุญาตเท่านั้น ดังนั้นเราจึงใช้การขยายสัญญาณผ่าน SYN และ SYN-ACK เมื่อระบบตอบสนองต่อการส่ง SYN หนึ่งตัวด้วย SYN-ACK สองหรือสามตัว และที่เอาต์พุต การโจมตีจะถูกคูณด้วยสองหรือสามครั้ง

เครื่องมือ

เครื่องมือหลักอย่างหนึ่งที่เราใช้กับปริมาณงาน L7 คือ Yandex-tank โดยเฉพาะอย่างยิ่ง Phantom ถูกใช้เป็นปืน และมีสคริปต์หลายตัวสำหรับสร้างคาร์ทริดจ์และวิเคราะห์ผลลัพธ์
Tcpdump ใช้เพื่อวิเคราะห์การรับส่งข้อมูลเครือข่าย และใช้ Nmap เพื่อวิเคราะห์เซิร์ฟเวอร์ ในการสร้างโหลดที่ระดับ L3&4 จะใช้ OpenSSL และความมหัศจรรย์ของเราเองเล็กน้อยกับไลบรารี DPDK DPDK เป็นไลบรารีจาก Intel ที่ให้คุณทำงานกับอินเทอร์เฟซเครือข่ายโดยไม่ต้องผ่านสแต็ก Linux ซึ่งจะช่วยเพิ่มประสิทธิภาพ โดยปกติแล้ว เราใช้ DPDK ไม่เพียงแต่ในระดับ L3&4 เท่านั้น แต่ยังใช้ในระดับ L7 ด้วย เนื่องจากช่วยให้เราสามารถสร้างโฟลว์โหลดที่สูงมาก ภายในช่วงหลายล้านคำขอต่อวินาทีจากเครื่องเดียว
นอกจากนี้เรายังใช้ตัวสร้างปริมาณการเข้าชมและเครื่องมือพิเศษที่เราเขียนขึ้นสำหรับการทดสอบเฉพาะ หากเราจำช่องโหว่ภายใต้ SSH ได้ แสดงว่าชุดข้างต้นไม่สามารถถูกโจมตีได้ หากเราโจมตีโปรโตคอลเมล เราจะใช้ยูทิลิตี้เมลหรือเพียงแค่เขียนสคริปต์ลงไป

ผลการวิจัย

โดยสรุปฉันอยากจะพูดว่า:

• นอกจากการทดสอบโหลดแบบคลาสสิกแล้ว ยังจำเป็นต้องทำการทดสอบความเครียดอีกด้วย เรามีตัวอย่างจริงที่ผู้รับเหมาช่วงของพันธมิตรทำการทดสอบโหลดเท่านั้น แสดงให้เห็นว่าทรัพยากรสามารถทนต่อการโหลดตามปกติได้ แต่แล้วภาระงานที่ผิดปกติก็ปรากฏขึ้น ผู้เยี่ยมชมไซต์เริ่มใช้ทรัพยากรแตกต่างออกไปเล็กน้อย และเป็นผลให้ผู้รับเหมาช่วงต้องนอนลง ดังนั้นจึงควรมองหาช่องโหว่แม้ว่าคุณจะได้รับการปกป้องจากการโจมตี DDoS อยู่แล้วก็ตาม
• จำเป็นต้องแยกบางส่วนของระบบออกจากส่วนอื่นๆ หากคุณมีการค้นหา คุณต้องย้ายมันไปยังเครื่องที่แยกจากกัน นั่นคือ แม้แต่ Docker ก็ไม่สามารถทำได้ เพราะถ้าการค้นหาหรือการอนุญาตล้มเหลว อย่างน้อยก็มีบางอย่างยังคงทำงานต่อไปได้ ในกรณีของร้านค้าออนไลน์ ผู้ใช้จะยังคงค้นหาผลิตภัณฑ์ในแค็ตตาล็อก ไปจากผู้รวบรวม ซื้อหากได้รับอนุญาตแล้ว หรืออนุญาตผ่าน OAuth2
• อย่าละเลยบริการคลาวด์ทุกประเภท
• ใช้ CDN ไม่เพียงแต่เพื่อเพิ่มประสิทธิภาพความล่าช้าของเครือข่ายเท่านั้น แต่ยังเป็นวิธีการป้องกันการโจมตีจากการอ่อนล้าของช่องสัญญาณและเพียงแค่ท่วมเข้าสู่การรับส่งข้อมูลแบบคงที่
• จำเป็นต้องใช้บริการคุ้มครองพิเศษ คุณไม่สามารถป้องกันตัวเองจากการโจมตี L3&4 ในระดับแชนเนลได้ เนื่องจากมีแนวโน้มว่าคุณจะไม่มีแชนเนลที่เพียงพอ คุณไม่น่าจะต่อสู้กับการโจมตี L7 ได้เนื่องจากอาจมีขนาดใหญ่มาก นอกจากนี้ การค้นหาการโจมตีขนาดเล็กยังคงเป็นสิทธิพิเศษของบริการพิเศษ อัลกอริธึมพิเศษ
• อัปเดตเป็นประจำ สิ่งนี้ไม่เพียงแต่ใช้กับเคอร์เนลเท่านั้น แต่ยังรวมถึง SSH daemon ด้วย โดยเฉพาะอย่างยิ่งหากคุณเปิดไว้ด้านนอก โดยหลักการแล้ว ทุกอย่างจำเป็นต้องได้รับการอัปเดต เนื่องจากคุณไม่สามารถติดตามช่องโหว่บางอย่างได้ด้วยตัวเอง

ที่มา: will.com