โปรโฮสต์ > บล็อก > การบริหาร > การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)

การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)

การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)การลดความเสี่ยงในการใช้ DoH และ DoT

การป้องกัน DoH และ DoT

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

ภาพรวมที่ดีของความเสี่ยงที่ DNS นำมาคือ การนำเสนอ Verisign ในการประชุมความปลอดภัยสารสนเทศ

การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)31% ของคลาสแรนซัมแวร์ที่สำรวจใช้ DNS สำหรับการแลกเปลี่ยนคีย์ ผลการศึกษา

31% ของคลาสแรนซัมแวร์ที่สำรวจใช้ DNS สำหรับการแลกเปลี่ยนคีย์

ปัญหาร้ายแรง จากข้อมูลของห้องปฏิบัติการวิจัยหน่วย 42 ของ Palo Alto Networks มัลแวร์ประมาณ 85% ใช้ DNS เพื่อสร้างช่องทางคำสั่งและการควบคุม ทำให้ผู้โจมตีสามารถส่งมัลแวร์เข้าสู่เครือข่ายของคุณได้อย่างง่ายดายรวมถึงขโมยข้อมูลด้วย นับตั้งแต่เริ่มก่อตั้ง การรับส่งข้อมูล DNS ส่วนใหญ่ไม่ได้เข้ารหัสและสามารถวิเคราะห์ได้อย่างง่ายดายด้วยกลไกความปลอดภัยของ NGFW 

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

เมื่อกำหนดค่าอย่างถูกต้องแล้ว NGFW จะสามารถปฏิเสธหรือป้องกันการใช้ DNS-over-TLS (DoT) และสามารถใช้เพื่อปฏิเสธการใช้ DNS-over-HTTPS (DoH) ทำให้สามารถวิเคราะห์การรับส่งข้อมูล DNS ทั้งหมดบนเครือข่ายของคุณ

DNS ที่เข้ารหัสคืออะไร?

DNS คืออะไร

ระบบชื่อโดเมน (DNS) จะแก้ไขชื่อโดเมนที่มนุษย์สามารถอ่านได้ (เช่น ที่อยู่ www.paloaltonetworks.com ) ไปยังที่อยู่ IP (เช่น 34.107.151.202) เมื่อผู้ใช้ป้อนชื่อโดเมนลงในเว็บเบราว์เซอร์ เบราว์เซอร์จะส่งแบบสอบถาม DNS ไปยังเซิร์ฟเวอร์ DNS เพื่อขอที่อยู่ IP ที่เชื่อมโยงกับชื่อโดเมนนั้น เพื่อเป็นการตอบสนอง เซิร์ฟเวอร์ DNS จะส่งคืนที่อยู่ IP ที่เบราว์เซอร์นี้จะใช้

การสอบถามและการตอบกลับ DNS จะถูกส่งผ่านเครือข่ายในรูปแบบข้อความธรรมดา ไม่มีการเข้ารหัส ทำให้มีความเสี่ยงที่จะถูกสอดแนมหรือเปลี่ยนแปลงการตอบสนอง และเปลี่ยนเส้นทางเบราว์เซอร์ไปยังเซิร์ฟเวอร์ที่เป็นอันตราย การเข้ารหัส DNS ทำให้ยากสำหรับการติดตามหรือเปลี่ยนแปลงคำขอ DNS ระหว่างการส่งข้อมูล การเข้ารหัสคำขอและการตอบกลับ DNS ช่วยปกป้องคุณจากการโจมตีแบบ Man-in-the-Middle ในขณะที่ดำเนินการฟังก์ชันการทำงานเดียวกันกับโปรโตคอล DNS แบบข้อความธรรมดา (ระบบชื่อโดเมน) 

ในช่วงไม่กี่ปีที่ผ่านมา มีการเปิดตัวโปรโตคอลการเข้ารหัส DNS สองโปรโตคอล:

  1. DNS บน HTTPS (DoH)

  2. DNS-over-TLS (DoT)

โปรโตคอลเหล่านี้มีสิ่งหนึ่งที่เหมือนกัน: พวกเขาจงใจซ่อนคำขอ DNS จากการสกัดกั้นใดๆ... และจากเจ้าหน้าที่รักษาความปลอดภัยขององค์กรด้วย โปรโตคอลส่วนใหญ่ใช้ TLS (Transport Layer Security) เพื่อสร้างการเชื่อมต่อที่เข้ารหัสระหว่างไคลเอนต์ที่ทำการสืบค้นและเซิร์ฟเวอร์ที่แก้ไขการสืบค้น DNS ผ่านพอร์ตที่ปกติไม่ได้ใช้สำหรับการรับส่งข้อมูล DNS

การรักษาความลับของการสืบค้น DNS ถือเป็นข้อดีอย่างมากของโปรโตคอลเหล่านี้ อย่างไรก็ตาม สิ่งเหล่านี้ก่อให้เกิดปัญหากับเจ้าหน้าที่รักษาความปลอดภัยที่ต้องตรวจสอบการรับส่งข้อมูลเครือข่ายและตรวจจับและบล็อกการเชื่อมต่อที่เป็นอันตราย เนื่องจากโปรโตคอลใช้งานแตกต่างกัน วิธีการวิเคราะห์จึงแตกต่างกันระหว่าง DoH และ DoT

DNS ผ่าน HTTPS (DoH)

การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)DNS ภายใน HTTPS

DoH ใช้พอร์ต 443 ที่รู้จักกันดีสำหรับ HTTPS ซึ่ง RFC ระบุไว้โดยเฉพาะว่ามีเจตนาที่จะ "ผสมการรับส่งข้อมูล DoH กับการรับส่งข้อมูล HTTPS อื่น ๆ บนการเชื่อมต่อเดียวกัน" "ทำให้ยากต่อการวิเคราะห์การรับส่งข้อมูล DNS" และด้วยเหตุนี้จึงหลีกเลี่ยงการควบคุมขององค์กร ( RFC 8484 DoH มาตรา 8.1 ). โปรโตคอล DoH ใช้การเข้ารหัส TLS และไวยากรณ์คำขอที่จัดทำโดยมาตรฐาน HTTPS และ HTTP/2 ทั่วไป โดยเพิ่มคำขอ DNS และการตอบกลับนอกเหนือจากคำขอ HTTP มาตรฐาน

ความเสี่ยงที่เกี่ยวข้องกับ DoH

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

И Google และ Mozilla ได้นำความสามารถ DoH มาใช้ ในเบราว์เซอร์เวอร์ชันล่าสุด และทั้งสองบริษัทกำลังทำงานเพื่อใช้ DoH เป็นค่าเริ่มต้นสำหรับคำขอ DNS ทั้งหมด Microsoft กำลังพัฒนาแผนเช่นกัน ในการบูรณาการ DoH เข้ากับระบบปฏิบัติการของพวกเขา ข้อเสียคือไม่เพียงแต่บริษัทซอฟต์แวร์ที่มีชื่อเสียงเท่านั้น แต่ยังรวมถึงผู้โจมตีที่เริ่มใช้ DoH เพื่อหลบเลี่ยงมาตรการไฟร์วอลล์ขององค์กรแบบเดิมๆ (ตัวอย่างเช่น ทบทวนบทความต่อไปนี้: PsiXBot ใช้ Google DoH แล้ว , PsiXBot ยังคงพัฒนาต่อไปด้วยโครงสร้างพื้นฐาน DNS ที่อัปเดต и การวิเคราะห์ลับๆของ Godlua .) ไม่ว่าในกรณีใด ปริมาณข้อมูล DoH ทั้งที่ดีและเป็นอันตรายจะไม่ถูกตรวจพบ ส่งผลให้องค์กรมองข้ามการใช้ DoH ในทางที่เป็นอันตรายเพื่อเป็นช่องทางในการควบคุมมัลแวร์ (C2) และขโมยข้อมูลที่ละเอียดอ่อน

สร้างความมั่นใจในการมองเห็นและการควบคุมการรับส่งข้อมูล DoH

เนื่องจากเป็นทางออกที่ดีที่สุดสำหรับการควบคุม DoH เราขอแนะนำให้กำหนดค่า NGFW เพื่อถอดรหัสการรับส่งข้อมูล HTTPS และบล็อกการรับส่งข้อมูล DoH (ชื่อแอปพลิเคชัน: dns-over-https) 

ขั้นแรกตรวจสอบให้แน่ใจว่า NGFW ได้รับการกำหนดค่าให้ถอดรหัส HTTPS ตาม คำแนะนำเกี่ยวกับเทคนิคการถอดรหัสที่ดีที่สุด.

ประการที่สอง สร้างกฎสำหรับการรับส่งข้อมูลแอปพลิเคชัน "dns-over-https" ดังที่แสดงด้านล่าง:

การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)กฎ NGFW ของ Palo Alto Networks เพื่อบล็อก DNS-over-HTTPS

เป็นทางเลือกชั่วคราว (หากองค์กรของคุณยังไม่ได้ใช้การถอดรหัส HTTPS อย่างสมบูรณ์) คุณสามารถกำหนดค่า NGFW เพื่อใช้การดำเนินการ "ปฏิเสธ" กับ ID แอปพลิเคชัน "dns-over-https" ได้ แต่ผลกระทบจะถูกจำกัดอยู่เพียงการบล็อก well- เซิร์ฟเวอร์ DoH ที่รู้จักด้วยชื่อโดเมน ดังนั้นหากไม่มีการถอดรหัส HTTPS การรับส่งข้อมูล DoH จะไม่สามารถตรวจสอบได้อย่างสมบูรณ์ (ดู  Applipedia จาก Palo Alto Networks   และค้นหา "dns-over-https")

DNS ผ่าน TLS (DoT)

การลดความเสี่ยงในการใช้ DNS-over-TLS (DoT) และ DNS-over-HTTPS (DoH)DNS ภายใน TLS

แม้ว่าโปรโตคอล DoH มีแนวโน้มที่จะผสมกับการรับส่งข้อมูลอื่น ๆ บนพอร์ตเดียวกัน แต่ DoT จะใช้พอร์ตพิเศษที่สงวนไว้สำหรับจุดประสงค์นั้นแทน โดยเฉพาะอย่างยิ่งการไม่อนุญาตให้ใช้พอร์ตเดียวกันโดยการรับส่งข้อมูล DNS แบบเดิมที่ไม่ได้เข้ารหัส ( RFC 7858 ส่วนที่ 3.1 ).

โปรโตคอล DoT ใช้ TLS เพื่อให้การเข้ารหัสที่ห่อหุ้มการสืบค้นโปรโตคอล DNS มาตรฐาน โดยมีการรับส่งข้อมูลโดยใช้พอร์ต 853 ที่รู้จัก ( RFC 7858 ส่วนที่ 6 ). โปรโตคอล DoT ได้รับการออกแบบมาเพื่อให้องค์กรสามารถบล็อกการรับส่งข้อมูลบนพอร์ตหรือยอมรับการรับส่งข้อมูล แต่เปิดใช้งานการถอดรหัสบนพอร์ตนั้นได้ง่ายขึ้น

ความเสี่ยงที่เกี่ยวข้องกับ DoT

Google ได้ติดตั้ง DoT ในไคลเอนต์ของตน Android 9 Pie และใหม่กว่า โดยมีการตั้งค่าเริ่มต้นให้ใช้ DoT โดยอัตโนมัติ หากมี หากคุณได้ประเมินความเสี่ยงแล้วและพร้อมที่จะใช้ DoT ในระดับองค์กร คุณจะต้องให้ผู้ดูแลระบบเครือข่ายอนุญาตการรับส่งข้อมูลขาออกบนพอร์ต 853 อย่างชัดเจนผ่านขอบเขตสำหรับโปรโตคอลใหม่นี้

สร้างความมั่นใจในการมองเห็นและการควบคุมการรับส่งข้อมูล DoT

ตามแนวทางปฏิบัติที่ดีที่สุดสำหรับการควบคุม DoT เราขอแนะนำสิ่งใดๆ ข้างต้น โดยอิงตามความต้องการขององค์กรของคุณ:

  • กำหนดค่า NGFW เพื่อถอดรหัสการรับส่งข้อมูลทั้งหมดสำหรับพอร์ตปลายทาง 853 เมื่อถอดรหัสการรับส่งข้อมูล DoT จะปรากฏเป็นแอปพลิเคชัน DNS ซึ่งคุณสามารถใช้การกระทำใดก็ได้ เช่น เปิดใช้งานการสมัครสมาชิก การรักษาความปลอดภัย DNS ของ Palo Alto Networks เพื่อควบคุมโดเมน DGA หรือโดเมนที่มีอยู่ DNS Sinkholing และป้องกันสปายแวร์

  • อีกทางเลือกหนึ่งคือให้กลไก App-ID บล็อกการรับส่งข้อมูล 'dns-over-tls' บนพอร์ต 853 โดยสมบูรณ์ ซึ่งโดยปกติจะถูกบล็อกโดยค่าเริ่มต้น ไม่จำเป็นต้องดำเนินการใดๆ (เว้นแต่คุณจะอนุญาตแอปพลิเคชัน 'dns-over-tls' หรือการรับส่งข้อมูลพอร์ตเป็นการเฉพาะ 853)

ที่มา: will.com

เพิ่มความคิดเห็น