Tor นำการป้องกันแบบ Proof-of-Work มาใช้กับบริการ Onion
(blog.torproject.org)- Tor 0.4.8 นำการป้องกันที่ให้ความสำคัญกับ ทราฟฟิกเครือข่ายที่ผ่านการตรวจสอบแล้ว มาใช้เมื่อบริการ Onion ถูกโจมตีแบบ DoS
- ในโครงสร้างของบริการ Onion ที่ซ่อนที่อยู่ IP นั้น การจำกัดอัตราตาม IP ยังไม่สมบูรณ์ จึงจำเป็นต้องใช้วิธีปริศนาฝั่งไคลเอนต์ที่ไม่กระทบต่อความเป็นส่วนตัว
- เมื่อบริการอยู่ภายใต้แรงกดดัน ไคลเอนต์จะพิสูจน์ปริมาณงานด้วย การคำนวณปริศนา ที่ยากขึ้นเรื่อย ๆ และลำดับความสำคัญของการเชื่อมต่อจะเปลี่ยนไปตามระดับนั้น
- เวลาแก้ปริศนาเริ่มต้นสำหรับผู้ใช้ทั่วไปอยู่ที่ประมาณ 5ms บนคอมพิวเตอร์ที่เร็ว และสูงสุด 30ms บนฮาร์ดแวร์ที่ช้า จึงรองรับได้บนอุปกรณ์ส่วนใหญ่
- เมื่อทราฟฟิกโจมตีเพิ่มขึ้น ปริมาณงานที่ต้องใช้จะเพิ่มได้ถึงประมาณ 1 นาที ทำให้ความพยายามเชื่อมต่อจำนวนมากมีต้นทุนสูงขึ้น และผู้ใช้ปกติยังมีโอกาสเข้าถึงได้แม้ในสถานการณ์แออัด
การป้องกัน PoW สำหรับบริการ Onion ใน Tor 0.4.8
- Tor เปิดตัว การป้องกันแบบ Proof-of-Work (PoW) สำหรับบริการ Onion อย่างเป็นทางการพร้อมกับรีลีส Tor 0.4.8
- เป้าหมายคือการยับยั้งการโจมตีแบบ DoS พร้อมกับให้ความสำคัญกับ ทราฟฟิกที่ผ่านการตรวจสอบแล้ว
- แนะนำให้ผู้ให้บริการ Onion อัปเดตเป็นเวอร์ชัน 0.4.8
- เนื่องจากบริการ Onion ซ่อนที่อยู่ IP เพื่อความเป็นส่วนตัวของผู้ใช้ จึงอาจเปราะบางต่อ การโจมตีแบบ DoS และการจำกัดอัตราตาม IP แบบดั้งเดิมเพียงอย่างเดียวไม่สามารถป้องกันได้อย่างสมบูรณ์
ปริศนาฝั่งไคลเอนต์และการจัดลำดับความสำคัญ
- โดยพื้นฐานแล้ว PoW ทำงานเหมือน ระบบตั๋ว ที่ปิดไว้เป็นค่าเริ่มต้น แต่เมื่อเกิดความตึงเครียดบนเครือข่าย จะสร้างคิวลำดับความสำคัญขึ้นมา
- ก่อนเข้าถึงบริการ Onion ไคลเอนต์ต้องแก้ปริศนาเล็ก ๆ เพื่อพิสูจน์ว่าได้ทำ ปริมาณงาน ตามที่กำหนดแล้ว
- ยิ่งปริศนายากเท่าไร ก็หมายความว่าได้ทำงานมากขึ้นเท่านั้น
- บริการ Onion จะกำหนดลำดับความสำคัญของการเชื่อมต่อตามระดับความพยายามที่ไคลเอนต์แสดงให้เห็น
- หากผู้โจมตีส่งคำขอจำนวนมากจนทำให้บริการ Onion ท่วม การคำนวณที่ต้องใช้เพื่อเข้าถึงไซต์ .onion จะเพิ่มขึ้น
- ความพยายามเชื่อมต่อจำนวนมากต้องใช้ทรัพยากรคำนวณมากขึ้น
- โครงสร้างนี้ทำให้ความคุ้มค่าของผู้โจมตีลดลงเมื่อปริมาณงานที่ต้องใช้เพิ่มขึ้น
ผลกระทบที่ผู้ใช้ทั่วไปจะเห็น
- ผู้ใช้ทั่วไปมักส่งคำขอจำนวนไม่มากในแต่ละครั้ง ดังนั้นภาระในการแก้ปริศนาจึงอยู่ในระดับที่จัดการได้บนอุปกรณ์ส่วนใหญ่
- เวลาแก้ปริศนาเริ่มต้นบนคอมพิวเตอร์ที่เร็วอยู่ที่ประมาณ 5ms
- บนฮาร์ดแวร์ที่ช้าจะอยู่ที่สูงสุด 30ms
- เมื่อทราฟฟิกโจมตีเพิ่มขึ้น ปริมาณงานที่ต้องใช้อาจเพิ่มขึ้นได้ถึงราว 1 นาที
- กระบวนการนี้ผู้ใช้จะมองไม่เห็น และประสบการณ์ขณะรอคำตอบ PoW จะคล้ายกับการรอการเชื่อมต่อเครือข่ายที่ช้า
- หากไซต์สำคัญ ๆ นำวิธีนี้ไปใช้ จะช่วยลดผลกระทบด้านลบของการโจมตีแบบเจาะจงเป้าหมายต่อความเร็วเครือข่าย และช่วยกระจายโหลดเมื่อทราฟฟิกพุ่งสูงอย่างกะทันหัน ทำให้การเข้าถึงบริการ Onion สม่ำเสมอและเชื่อถือได้มากขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
น่าสนใจมาก ดูจากข้อเสนอแล้วความคาดหวังค่อนข้างชัดเจน: ไม่ได้ตั้งใจจะกัน บอตเน็ตขนาดใหญ่ แต่มีเป้าหมายเพื่อป้องกันสคริปต์คิดดี้หรือบอตเน็ตขนาดเล็ก
ระหว่างการโจมตี DoS ผู้ใช้ที่ต้องการเชื่อมต่อจริง ๆ ยังผ่านเข้าไปได้ แต่อาจต้องออกแรงพอสมควร
การเลือก https://github.com/tevador/equix เป็นอัลกอริทึม proof-of-work ก็น่าสนใจเช่นกัน
ไม่ใช่วิธีที่ต้องทำให้ค่าต่ำกว่าเป้าหมายคงที่จึงจะสำเร็จแบบ Bitcoin แต่เป็นโครงสร้างที่ไคลเอนต์ “ประมูล” ด้วยความพยายามด้าน proof-of-work และยิ่งลงแรงมากก็ยิ่งมีลำดับความสำคัญสูงขึ้น มีคำอธิบายว่าคล้ายกับ proof-of-stake ตรงที่เป็นการฝากงานแทนการฝากเหรียญ
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
เวอร์ชันนี้ก็ดี แต่คิดว่าจะดีกว่านี้ถ้าเพิ่มการโอนมูลค่าเข้าไป
แถม proof-of-work ก็เป็นแค่การคำนวณที่สูญเปล่าและไม่จำเป็น การคำนวณไม่ได้ฟรี และทุกวัตต์ที่ใช้กับ proof-of-work ยิ่งทำให้วิกฤตสภาพภูมิอากาศปัจจุบันแย่ลง
ในฐานะคนที่อยู่ในพื้นที่ซึ่งอีกไม่กี่วันจะร้อนแบบรู้สึกได้ 120 องศา และอุณหภูมิจริง 109 องศา พูดอย่างสุภาพคือ คนที่เสนอว่า proof-of-work เป็นไอเดียที่ดีสำหรับอะไรก็ตาม น่าจะไปตายซะ
มันไม่ได้น่าสนใจ แต่เป็นกรณีของ การบริโภคเพื่ออวดสถานะ ที่โจ่งแจ้งที่สุดบนโลก
บทความที่ดีกว่า หรือรายละเอียดทางเทคนิคจริง ๆ อยู่ที่ https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
ฟังก์ชัน proof-of-work ที่เลือกดูเหมือนจะเป็น equi-X
แปลกใจที่ของแบบนี้ไม่ได้ถูกใส่เข้ามาเร็วกว่านี้ และยังไม่ได้อ่านข้อเสนอ [0] อย่างละเอียดพอ เลยยังไม่รู้ว่าจะเพิ่มข้อมูลที่กระทบต่อความเป็นนิรนามของผู้ใช้หรือไม่ แต่ถ้าผูกเป็นหน่วยผู้ใช้-บริการและไม่ถูกเก็บไว้ที่ไหนก็ดูโอเค
ยังสงสัยด้วยว่าจะลดภาระของบริการที่ถูกพร็อกซีและภาระของโหนดเองได้มากแค่ไหน เพราะการเข้าถึงถูกกระจายไปหลายโหนด ดูเหมือนฝั่งบริการน่าจะได้ประโยชน์มากกว่า
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
ดีเลย อีกไม่นานอาจไม่ต้องใช้ CDN สำหรับป้องกัน DDoS แล้วก็ได้ แค่ให้บริการ API เป็น Onion service ก็พอ
วิธีนี้เคยถูกเสนอมาก่อนเพื่อป้องกัน สแปมอีเมล ด้วย
Cloudflare ก็ทำได้เช่นกัน ในรูปแบบที่ทุกครั้งที่เข้าเว็บยุ่ง ๆ จะให้เครื่องรันการคำนวณไร้ประโยชน์เป็นเวลาตั้งแต่ไม่กี่วินาทีไปจนถึงไม่กี่นาที ผลโดยรวมคงเป็นการสูบแบตเตอรี่ทั่วโลก
http://www.hashcash.org/
ที่น่าสนใจคือมันกลายเป็นแรงบันดาลใจให้การขุดแบบ proof-of-work ของ Bitcoin
เพราะมันจะปล่อยก๊าซเรือนกระจกขึ้นสู่ชั้นบรรยากาศด้วย
สงสัยว่าเมื่อ proof-of-work เริ่มทำงานแล้ว อะไรจะกันไม่ให้ผู้โจมตีสร้างตัวตนใหม่แล้ว DDoS ต่อ
แก้ไข: ดูเหมือนว่า proof-of-work จะถูกตั้งค่าเป็นราย “บริการ” ที่ถูกโจมตี ไม่ใช่รายไคลเอนต์
เพราะความเป็นนิรนามหรือคุณสมบัติที่สร้างตัวตนใหม่ได้อย่างอิสระ ผู้โจมตีจึงสามารถทำให้ความจุหมดด้วย การโจมตีแบบ Sybil และทำให้เกิดการปฏิเสธการให้บริการได้
สงสัยว่ามีวิธีแก้ปัญหา Sybil attack ให้สง่างามกว่านี้หรือไม่ ตัวอย่างเช่น CPU จำนวนมากมีคู่คีย์ที่เป็นเอกลักษณ์ต่อโปรเซสเซอร์อยู่ภายใน และสามารถตรวจสอบได้ด้วยใบรับรอง CA root ของผู้ออกอย่าง Intel, AMD เป็นต้น ถ้าผูก proof-of-work เข้ากับลายเซ็นต่อเนื่องและอนุญาตให้ตรวจสอบแบบขนานได้ proof-of-work ทั้งหมดก็จะมีเอกลักษณ์เฉพาะตาม CPU ทำให้ไม่สามารถทำ parallelize ด้วย botnet ได้
พวกเขาดูเหมือนจะเล็งไปที่หน่วยความจำเพื่อเพิ่มต้นทุนของ botnet ยังดูเหมือนว่ามีอีกหลายวิธีที่จะลดสถานการณ์โจมตีแบบนี้ได้ ตรรกะเดียวกันน่าจะนำไปใช้กับโทรศัพท์ที่ใช้ eSIM ได้ด้วย จากนั้นการยืนยันตัวตนของเครือข่ายมือถือก็ใช้ public-key cryptography อยู่แล้ว จึงน่าจะทำ unique proof ได้เช่นกัน
เป็นแค่ความคิดที่ผุดขึ้นมาเฉย ๆ จึงมีโอกาสสูงว่าจะมองข้ามปัญหาชัด ๆ ของวิธีนี้ไป
เหตุผลที่เลือกอัลกอริทึมที่ใช้หน่วยความจำมาก ก็เพื่อป้องกันการใช้ฮาร์ดแวร์เฉพาะอย่าง ASIC
ในแนวทางคล้ายกัน ลองให้เซิร์ฟเวอร์มีหลาย pool ของ IP และให้ไคลเอนต์ส่ง proof ของ port knocking กลับมาเป็นอย่างไร เช่น ให้ token แล้วให้ส่งไปยัง IP:พอร์ตนี้ และรอการตอบกลับที่เป็นเอกลักษณ์ซึ่งฉันตรวจสอบได้ แบบนี้อาจเรียกว่า proof of latency ได้ ใช้ CPU ต่ำและกระจายโหลดไปยังหลายเครื่องและหลายพอร์ตได้ ข้อเสียคือแน่นอนว่าต้องมีหลาย IP และอาจต้องมีหลายเซิร์ฟเวอร์ แม้จะทำบนเครื่องเดียวกันได้ แต่ถ้าเป็นเช่นนั้นก็แค่ย้ายภาระ CPU ไปเป็นการเชื่อมต่อพอร์ตเท่านั้น
มีไอเดียที่จะลดทราฟฟิกของเครือข่าย Tor หรือทำให้เร็วขึ้นได้ ควรทำให้ใช้เครือข่ายเหมือน CDN ได้ ถ้าต้องการเผยแพร่ไฟล์ ก็ควรส่งชิ้นส่วนไฟล์ไปยังโหนดที่อนุญาต และเมื่อมีคำขอไฟล์เข้ามา ก็ควรชี้ไปยังโหนดเหล่านั้นได้
แน่นอนว่าต้องระวังไม่ให้เครือข่าย Tor กลายเป็น “ตัวแทน torrent แบบนิรนาม” จนบั่นทอนจุดประสงค์ของมัน
ข้อเสนอปัจจุบันพูดถึง “การจัดลำดับความสำคัญของทราฟฟิกเครือข่ายที่ตรวจสอบแล้ว” เพราะมันช่วยเครือข่ายจริง ๆ จึงน่าสนใจถ้าการแชร์ “ชิ้นส่วนไฟล์” สามารถเพิ่มลำดับความสำคัญของทราฟฟิกได้ เท่ากับเป็น proof of bandwidth contribution แทน “proof-of-work”
แต่ก็ยังไม่ค่อยเข้าใจว่าสิ่งนี้จะลดทราฟฟิกเครือข่ายได้อย่างไร สุดท้ายก็ต้องสื่อสารกับโหนด CDN อยู่ดี
เมื่อดูเป้าหมายและข้อจำกัดที่ข้อเสนอนี้ตั้งไว้ ก็ถือว่าสมเหตุสมผล และน่าจะบรรลุเป้าหมายนั้นได้ อย่างที่บอก มันน่าจะใช้ได้กับ botnet ขนาดเล็ก แต่ botnet ขนาดใหญ่ก็ยังสามารถถล่มทรัพยากรที่มีอยู่ของไคลเอนต์แต่ละรายได้อยู่ดี
โดยส่วนตัวไม่ชอบ proof-of-work ในที่นี้มันใกล้กับ attrition ในฐานะกลไกป้องกันมากกว่า อาจทำให้ฮาร์ดแวร์เก่าล้าสมัยเร็วขึ้น และเมื่อรวมอุปกรณ์ทั้งหมดที่ได้รับผลกระทบ ก็มีแนวโน้มว่าจะใช้ไฟฟ้าค่อนข้างมาก หากนำไปใช้ในวงกว้างจะเป็นภาระต่อสิ่งแวดล้อมไม่น้อย
จากมุมมองของผู้โจมตี การทำให้ระดับความยากสูงขนาดนั้นเองก็ถือเป็นความสำเร็จได้แล้ว เพราะถ้าผู้ใช้ต้องรอ 1 นาทีโดยให้อุปกรณ์ทำงานที่ 100% หลายกรณีก็คงเลิกใช้ไปเลย
ถึงอย่างนั้น มันก็เป็นวิธีที่ค่อนข้างดีในการบรรเทาการโจมตี DoS โดยไม่ทำลายความไม่เปิดเผยตัวตนของผู้ใช้ ดังนั้นจากมุมนั้น แม้จะมีข้อเสียก็ยังเป็นทางออกที่ดี ตราบใดที่อยู่ใน Tor ก็ไม่น่ามีปัญหาใหญ่ แต่ถ้านำไปใช้กับเว็บทั่วไป ผมมองว่าจะเป็นหายนะอย่างสิ้นเชิง
ในบทความบอกว่าความต่างของเวลาแก้โจทย์ระหว่างเซิร์ฟเวอร์ระดับสูงกับโทรศัพท์สเปกต่ำมีเพียง 6 เท่า ไม่รู้ว่าเป็นไปได้อย่างไร เซิร์ฟเวอร์น่าจะมี RAM และจำนวน CPU มากกว่าโทรศัพท์มากกว่า 6 เท่า และ CPU ก็น่าจะเร็วกว่าอีกด้วย
นอกจากนี้ ถ้าเป็น DDoS งานฝั่งเซิร์ฟเวอร์จะ parallelize ได้ดีจนน่าอึดอัด แต่ฝั่งไคลเอนต์อาจไม่จำเป็นต้อง parallelize ได้
แม้ความต่างจะเป็น 6 เท่า หรือแค่ 1 เท่า แต่เมื่อ DDoS ถูกตรวจพบ เวลาที่ใช้แก้โจทย์บอกว่าเป็น 1 นาที ถึงจุดนั้นบริการก็แทบจะล่มไปแล้วไม่ใช่หรือ?
ประเด็นสำคัญของส่วนที่ว่าเมื่อ DDoS ถูกตรวจพบ เวลาแก้โจทย์เป็น 1 นาที คือการเปลี่ยนการโจมตี DoS แบบง่ายที่มีอยู่เดิมอย่าง introduction flooding ให้กลายเป็นความขัดข้องบางส่วนหรือการชะลอตัว เป็นการปรับปรุงแบบค่อยเป็นค่อยไปสำหรับปัญหาที่ยาก