บันทึกนักพัฒนา: ยกระดับความปลอดภัย Kademlia DHT ป้องกัน Eclipse Attacks ใน py-libp2p
สัปดาห์นี้เน้นการอุดช่องโหว่ความปลอดภัยด้วย IP subnet diversity พร้อมจัดการปัญหา race conditions ในเทสสวีทของ py-libp2p
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เพิ่มฟีเจอร์ IP subnet diversity ใน Kad-DHT ผ่าน PR #1383
- ยกเลิกแนวคิด randomized lookup selection เพื่อเน้นการจัดการ bucket ที่รัดกุมขึ้น
- แก้ไขปัญหาเทสล้มเหลว (flaky tests) สองจุดใน py-libp2p ได้แก่ test_expiry_removal และ test_gossip_gate_filters_peers
- เปิด PR ค้างไว้ 3 รายการเพื่อเตรียมผลักดันเข้าสู่ระบบหลักในสัปดาห์หน้า
การเจาะลึกความปลอดภัยของ libp2p ในสัปดาห์นี้มุ่งเน้นไปที่การสร้างฟีเจอร์ IP subnet diversity สำหรับ Kad-DHT ควบคู่ไปกับการแก้ไขปัญหา race conditions ที่แก้ไม่ตกในชุดทดสอบ พร้อมกับเปิด PR ใหม่ 3 รายการและดูแลรักษาการตั้งค่า Neovim ส่วนตัวเบื้องหลังเพื่อให้งานดำเนินไปอย่างราบรื่น
ความพยายามด้านความปลอดภัยเป็นหัวใจหลักในสัปดาห์นี้ โดยเน้นไปที่การทำให้การใช้งาน Kademlia DHT มีความทนทานต่อการโจมตีแบบ Eclipse attacks มากขึ้น ผ่านการร่างตรรกะสำหรับ IP subnet diversity และการตามแก้ปัญหา race conditions ในชุดทดสอบของ py-libp2p ทำให้สัปดาห์นี้เต็มไปด้วยการคิดเชิงสถาปัตยกรรมระดับสูงควบคู่ไปกับการแก้โค้ดแบบอะซิงโครนัสที่จุกจิก
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เวลาส่วนใหญ่ในสัปดาห์นี้ทุ่มเทให้กับ py-libp2p โดยเฉพาะเรื่องการเลือกเพียร์ (peer selection) ใน Kademlia DHT โดยได้เปิด PR สำคัญในชื่อ feat(kad_dht): enforce IP subnet diversity in k-buckets (#1383) ซึ่งเพิ่มโค้ดตรรกะใหม่ 226บรรทัด เพื่อป้องกันไม่ให้ตารางเส้นทาง (routing table) เต็มไปด้วยเพียร์จากเน็ตเวิร์กย่อยเดียวกัน
Eclipse Attack คือการโจมตีที่ผู้ไม่หวังประสงค์พยายามควบคุมโหนดข้างเคียงทั้งหมดของเป้าหมาย เพื่อตัดขาดเหยื่อออกจากเครือข่ายจริงหรือป้อนข้อมูลเท็จ การบังคับใช้ IP subnet diversity จึงช่วยเพิ่มต้นทุนและความยากลำบากให้อะตั๊กเกอร์ เพราะไม่สามารถสร้างโหนดนับพันบนคลาวด์พروไวเดอร์ subnet เดียวเพื่อครอบครอง k-buckets ได้ง่ายๆ
นอกจากนี้ยังได้เปิดประเด็นอภิปรายเชิงลึกในหัวข้อ Eclipse-attack hardening for kad-dht: our approach, and why we dropped randomized lookup selection (#1383 / #1384) โดยเดิมทีได้พิจารณาใช้ระบบ randomized lookup selection เป็นกลไกป้องกัน แต่หลังจากพิจารณาแล้วกลับตัดสินใจยกเลิกเพื่อเลือกการจัดการ bucket ที่มีประสิทธิภาพมากกว่า
เมื่อทำงานกับไลบรารีที่พึ่งพานำเน็ตเวิร์กแบบอะซิงโครนัส หลีกเลี่ยงไม่ได้ที่จะต้องเจอกับ "flaky test tax" โดยสัปดาห์นี้ได้ใช้เวลาไล่ล่าปัญหา race conditions สองจุดที่รบกวนระบบ CI ได้แก่:
- test(timed_cache): de-flake test_expiry_removal (#1408): ปัญหาเทสแข่งกับเธรดพื้นหลัง (background sweeper thread) โดยใช้
trio.sleepแต่เนื่องจากสภาพแวดล้อม CI ที่ซีพียูโหลดไม่คงที่ ทำให้กระบวนการกวาดข้อมูลไม่เสร็จทันก่อนเทสจะตรวจผล - test(pubsub): de-flake test_gossip_gate_filters_peers (#1401): การแพร่กระจายการสมัครสมาชิกใน Gossipsub ขึ้นอยู่กับจังหวะเวลา หากเทสทำงานเร็วกว่าเครือข่ายจำลอง ระบบจะพังทันที
ด้านงานข้างสนาม ได้ดูแลสภาพแวดล้อมการทำงานโดยมีการคอมมิต 6 ครั้งใน config ของ Neovim ผ่านระบบ CI อัตโนมัติที่ช่วยอัปเดตปลั๊กอินเป็นเวอร์ชันล่าสุดเสมอ ด้วยอัตราส่วนการเพิ่ม 7 บรรทัดและลบ 7 บรรทัด ทำให้สัปดาห์นี้มีความสมดุลในการดูแลรักษาเครื่องมืออย่างลงตัว
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น