คำแนะนำในการกำจัด NTLM ออกจากสภาพแวดล้อมของคุณโดยสมบูรณ์

บทสรุปผู้บริหาร

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

พิจารณา Windows 10 สิ้นสุดอายุการใช้งานพร้อมกับการประกาศของ Microsoft เกี่ยวกับการเลิกใช้ NTLM ซึ่งเป็นส่วนหนึ่งของ NTLM ปัญหานี้ก็กลับมาปรากฏอีกครั้ง องค์กรต่างๆ จำเป็นต้องเริ่มตั้งคำถามว่า เราจะดำเนินงานได้อย่างไรหากไม่มี NTLM การรับรองและเราควรเตรียมตัวอย่างไรบ้างตอนนี้? 

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

ส่วนที่ 1: NTLM ทำงานอย่างไร?

NTLM (NT LAN Manager) เป็นหนึ่งในโปรโตคอลการตรวจสอบสิทธิ์แบบเก่าของ Microsoft ซึ่งเดิมสร้างขึ้นสำหรับเครือข่าย Windows ยุคแรกๆ ออกแบบมาเพื่อให้ผู้ใช้สามารถพิสูจน์ตัวตนได้โดยไม่ต้องส่งรหัสผ่านแบบข้อความธรรมดา แต่อาศัยวิธีการพิสูจน์ตัวตนแบบเดิม กลไกการท้าทาย-ตอบสนองแม้ว่าจะมีประสิทธิผลตั้งแต่ช่วงทศวรรษ 1990 แต่ปัจจุบันถือว่าล้าสมัยและไม่ปลอดภัยตามมาตรฐานปัจจุบัน  

กระบวนการตรวจสอบสิทธิ์ NTLM ปฏิบัติตามการแลกเปลี่ยนข้อความสามข้อความระหว่างไคลเอนต์ เซิร์ฟเวอร์ และตัวควบคุมโดเมน: 

1. การเจรจา NTLM 
   ไคลเอ็นต์เริ่มต้นการตรวจสอบสิทธิ์โดยการส่งข้อความ "เจรจา" ไปยังเซิร์ฟเวอร์ ข้อความนี้ประกอบด้วยรายละเอียดเกี่ยวกับความสามารถของไคลเอ็นต์ เช่น NTLM เวอร์ชันที่รองรับ 

2. ความท้าทาย NTLM 
   เซิร์ฟเวอร์ตอบกลับด้วยข้อความ "Challenge" ซึ่งประกอบด้วย nonce ขนาด 16 ไบต์ที่สร้างขึ้นแบบสุ่ม (Challenge) เพื่อให้แน่ใจว่าจะไม่สามารถทำซ้ำการพยายามตรวจสอบสิทธิ์ได้ 

3. การตรวจสอบสิทธิ์ NTLM 
   ขณะนี้ไคลเอนต์พิสูจน์ตัวตนโดยสร้างการตอบกลับโดยใช้แฮชรหัสผ่านที่จัดเก็บไว้ 

• ขั้นตอนสำคัญ: ไคลเอนต์คำนวณการตอบสนองความท้าทาย NTLM ตามเกณฑ์ของเซิร์ฟเวอร์ (เช่น NTLMv1 หรือ NTLMv2) 

• ด้วย NTLMv1 ไคลเอนต์จะเข้ารหัสความท้าทายโดยใช้ DES ซึ่งเป็น DES ที่อ่อนแอและถูกบังคับแบบบรูทฟอร์ซได้ง่าย 

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

4. ยอมรับหรือปฏิเสธ 
   In Active Directoryเซิร์ฟเวอร์จะส่งต่อความท้าทายและการตอบสนองไปยังตัวควบคุมโดเมน DC จะค้นหาแฮชรหัสผ่านที่จัดเก็บของผู้ใช้ใน Active Directoryดำเนินการคำนวณแบบเดียวกันและเปรียบเทียบผลลัพธ์ หากตรงกัน การรับรองความถูกต้องจะได้รับการยอมรับ หากไม่ตรงกัน การรับรองความถูกต้องจะถูกปฏิเสธ 

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

ส่วนที่ 2: การกำจัด NTLM ในองค์กรของคุณ

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

ขั้นตอนที่ 1: กำหนดว่าแอปพลิเคชันใดใช้ NTLM

คุณไม่สามารถกำจัดสิ่งที่คุณมองไม่เห็นได้ ขั้นตอนแรกคือ ตรวจจับการใช้งาน NTLM ทั่วทั้งสภาพแวดล้อมของคุณ. 

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

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

ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร Silverfort แพลตฟอร์ม นี่คือวิธีสร้างรายงานที่ครอบคลุมของแอปพลิเคชันทั้งหมดที่ใช้ NTLM ในสภาพแวดล้อมของคุณ: 

1. เปิดแท็บบันทึกการรับรองความถูกต้อง 

2. สร้างตัวกรองโปรโตคอล NTLM 

• เพิ่มตัวกรองเพิ่มเติมตามต้องการ (ช่วงเวลา ผู้ใช้ อุปกรณ์ ฯลฯ)
• สามารถกรอง NTLMv1 ได้โดยตรงโดยใช้ตัวบ่งชี้ความเสี่ยง

3. ส่งออกรายงาน

• จัดกลุ่มข้อมูลตามปลายทางเพื่อระบุว่าแอปพลิเคชันและเซิร์ฟเวอร์ใดที่ยังคงใช้ NTLM

สิ่งสำคัญที่ต้องจำไว้คือ ไคลเอ็นต์เป็นผู้รับผิดชอบการประมวลผล NTLM ซึ่งหมายความว่าการตรวจจับไม่สามารถหยุดลงที่ระดับแอปพลิเคชันได้ คุณต้องระบุไคลเอ็นต์ที่กลับมาใช้ NTLM ด้วย เพื่อขจัด NTLM อย่างสมบูรณ์ คุณต้องตรวจสอบไคลเอ็นต์อย่างต่อเนื่องและตรวจหาสาเหตุของการล้มเหลว ในหลายกรณี การล้มเหลวเกิดขึ้นเนื่องจากไม่สามารถสร้าง Kerberos ได้ เช่น เนื่องจากการกำหนดค่า Service Principal Names (SPN) ไม่ถูกต้อง หรือเมื่อไคลเอ็นต์เชื่อมต่อกับทรัพยากรโดยใช้ที่อยู่ IP แทน NetBIOS หรือชื่อโฮสต์ DNS ตามที่ Kerberos กำหนด คุณต้องแก้ไขสาเหตุพื้นฐานเหล่านี้เพื่อป้องกันไม่ให้ไคลเอ็นต์กลับไปใช้ NTLM เป็นค่าเริ่มต้น 

เมื่อตรวจสอบความล้มเหลวในการพิสูจน์ตัวตน Kerberos โปรดจำไว้ว่าในกรณีส่วนใหญ่ ความพยายามยืนยันตัวตน Kerberos ที่ล้มเหลวจะตามมาด้วยการยืนยันตัวตน NTLM ที่สำเร็จทันที พฤติกรรมนี้ทำให้ NTLM สามารถคงสถานะนี้ไว้ในสภาพแวดล้อมการทำงานแบบเงียบๆ ได้อย่างง่ายดาย ดังนั้น ควรตรวจสอบความล้มเหลวของ Kerberos แต่ละครั้งเพื่อทำความเข้าใจสาเหตุที่แท้จริง ไม่ว่าจะเป็นการหายไปหรือการกำหนดค่า Service Principal Name (SPN) ไม่ถูกต้อง การใช้ที่อยู่ IP แทนชื่อโฮสต์ หรือข้อผิดพลาดอื่นๆ ในการใช้งาน หากไม่ตรวจสอบนี้ ระบบสำรองของ NTLM จะยังคงทำงานต่อไปโดยไม่มีการตรวจสอบ ส่งผลให้ความพยายามในการแก้ไขปัญหานี้ล้มเหลว 

เพื่อตรวจสอบความล้มเหลวของ Kerberos โดยใช้ Silverfort:

1. เปิดบันทึกการตรวจสอบสิทธิ์

2. ใช้ตัวกรอง: ผลลัพธ์ IdP: ปฏิเสธ, โปรโตคอล: Kerberos

3. วิเคราะห์ผลลัพธ์

ขั้นตอนที่ 2: ประเมินความเสี่ยง – NTLMv1 เทียบกับ NTLMv2

การใช้งาน NTLM ไม่ได้มีความเสี่ยงในระดับเดียวกันเสมอไป สิ่งสำคัญในแผนการกำจัดของคุณคือการแยกความแตกต่างระหว่าง NTLMv1 และ NTLMv2 

NTLMv1

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

NTLMv2

NTLMv2 ปรับปรุงความปลอดภัยด้วยการนำ HMAC-MD5 มาใช้และรวมข้อมูลเพิ่มเติมในการแลกเปลี่ยนข้อมูลยืนยันตัวตน การปรับปรุงที่สำคัญประการหนึ่งคือการใช้ AV_PAIRS (คู่แอตทริบิวต์-ค่า) ซึ่งสามารถส่งข้อมูลต่างๆ เช่น ไทม์สแตมป์ของไคลเอ็นต์ ชื่อเซิร์ฟเวอร์เป้าหมาย และข้อมูลเป้าหมาย ฟิลด์เหล่านี้ช่วยป้องกันการโจมตีแบบรีเพลย์และรีเลย์แบบง่ายๆ เนื่องจากการตอบสนองจะเชื่อมโยงกับเซิร์ฟเวอร์และบริบทเซสชันที่เฉพาะเจาะจง 

อย่างไรก็ตาม การป้องกันยังไม่สมบูรณ์ หากผู้โจมตีสามารถจัดการหรือลบ AV_PAIRS ได้ (เช่น ในการกำหนดค่าที่ไม่ได้บังคับใช้การตรวจสอบความถูกต้องของเป้าหมาย) การโจมตีแบบรีเลย์ก็ยังคงเป็นไปได้ ในทางปฏิบัติ NTLMv2 ยังคงมีความเสี่ยงต่อการส่งผ่านแฮชและรีเลย์ NTLM ในสถานการณ์ที่ไม่มีการบังคับใช้การลงนามและการเชื่อมโยงช่องสัญญาณ 

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

ขั้นตอนที่ 3: บล็อก NTLMv1 ด้วยนโยบายกลุ่มและทราบข้อจำกัดของมัน

การบล็อก NTLMv1 ผ่านนโยบายกลุ่มเป็นขั้นตอนสำคัญในแผนการกำจัดใดๆ นโยบาย LMCompatibilityLevel (หรือนโยบายกลุ่มที่เทียบเท่า) ช่วยให้คุณกำหนดค่าตัวควบคุมโดเมนให้ปฏิเสธการตรวจสอบสิทธิ์ NTLMv1 และยอมรับเฉพาะ NTLMv2 เท่านั้น นี่คือการกำหนดค่าพื้นฐานที่แนะนำสำหรับทุก Active Directory สิ่งแวดล้อม 

วิธีเปิดใช้งานนโยบายกลุ่ม: 

1. จุดเปิด คอนโซลการจัดการนโยบายกลุ่ม (จีพีเอ็มซี) 

2. ไปที่: การกำหนดค่าคอมพิวเตอร์ → การตั้งค่า Windows → การตั้งค่าความปลอดภัย → นโยบายท้องถิ่น → ตัวเลือกความปลอดภัย 

3. ค้นหาการตั้งค่า: ความปลอดภัยของเครือข่าย: ระดับการตรวจสอบสิทธิ์ LAN Manager 

4. ตั้งค่าเป็น: ส่งคำตอบ NTLMv2 เท่านั้น ปฏิเสธ LM และ NTLM 

วิธีนี้จะช่วยให้แน่ใจว่าระบบ Windows ได้รับคำสั่งให้สร้างการตอบสนอง NTLMv2 เท่านั้น และตัวควบคุมโดเมนปฏิเสธการตรวจสอบสิทธิ์ NTLMv1 

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

หากต้องการคำอธิบายทางเทคนิคโดยละเอียดเกี่ยวกับวิธีการทำงานของการบายพาสดังกล่าวและสาเหตุที่เกิดขึ้น โปรดดูโพสต์บล็อกของฉัน: การบายพาส NTLMv1 ใน Active Directory – การเจาะลึกทางเทคนิค. 

คำแนะนำปัจจุบันของฉันคือการตรวจสอบและกำจัด NTLMv1 และหากเป็นไปได้ ให้สร้างนโยบายตามความเสี่ยงสำหรับการตรวจสอบสิทธิ์ NTLMv1 ทั้งหมดโดยใช้ Silverfort. 

ขั้นตอนที่ 4: ตรวจสอบว่าแอปพลิเคชันรองรับวิธีการตรวจสอบสิทธิ์อื่น ๆ หรือไม่

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

ก่อนที่จะเปลี่ยนหรือเลิกใช้แอปพลิเคชัน ตรวจสอบว่าแอปพลิเคชันนั้นรองรับวิธีการตรวจสอบสิทธิ์ที่ปลอดภัยยิ่งขึ้นแล้วหรือไม่: 

• Kerberos – แอปพลิเคชัน Windows ที่ทันสมัยส่วนใหญ่สามารถใช้การพิสูจน์ตัวตนแบบ Kerberos ได้เมื่อกำหนดค่า Service Principal Name (SPN) อย่างถูกต้อง ปัญหา NTLM หลายข้อสามารถแก้ไขได้โดยการแก้ไข SPN หรือการตรวจสอบให้แน่ใจว่าไคลเอนต์เชื่อมต่อโดยใช้ชื่อโฮสต์ DNS แทนที่อยู่ IP 

• SAML, OpenID Connect (OIDC) หรือ OAuth – แอปพลิเคชันเว็บและบริการที่เผชิญหน้ากับคลาวด์มักรองรับมาตรฐานการตรวจสอบสิทธิ์สมัยใหม่เหล่านี้ ไม่ว่าจะโดยตรงหรือผ่านการรวมเข้ากับผู้ให้บริการข้อมูลประจำตัว (IdP) 

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

เมื่อประเมินแอปพลิเคชัน: 

• ตรวจสอบเวอร์ชันใหม่กว่า – เวอร์ชันใหม่กว่าอาจยกเลิกการพึ่งพา NTLM หรือเพิ่มการรองรับสำหรับโปรโตคอลการระบุตัวตนสมัยใหม่ 

• การตรวจสอบเอกสาร ผู้จำหน่ายหลายรายจัดทำเอกสารเกี่ยวกับ Kerberos หรือการรองรับการระบุตัวตนแบบรวม แต่ก็มักไม่ได้รับการใช้ 

• ตรวจสอบการกำหนดค่าตัวตน – ตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณได้รับการบูรณาการกับผู้ให้บริการข้อมูลประจำตัวส่วนกลางของคุณทุกที่ที่เป็นไปได้ 

ตัวอย่างที่ดีของเรื่องนี้คือ Microsoft SQL Server เมื่อเข้าถึงด้วยไดรเวอร์ mssql-jdbc อย่างเป็นทางการ ในตอนแรก การใช้งานหลายระบบดูเหมือนจะใช้การตรวจสอบสิทธิ์แบบ NTLM แต่ในความเป็นจริงแล้ว ไดรเวอร์รองรับอย่างเต็มที่ การรับรองความถูกต้องของ Kerberosโดยมีเงื่อนไขว่าชื่อบริการหลัก (SPN) ได้รับการกำหนดค่าอย่างถูกต้อง และไคลเอนต์เชื่อมต่อโดยใช้ชื่อโฮสต์ DNS แทนที่อยู่ IP นอกจากนี้ เอกสารของ Microsoft ยังระบุวิธีการกำหนดค่าไดรเวอร์สำหรับ Kerberos อย่างชัดเจน เพื่อหลีกเลี่ยงการย้อนกลับของ NTLM นี่เป็นกรณีที่ NTLM ดูเหมือนจะหลีกเลี่ยงไม่ได้ แต่ด้วยการตรวจสอบเอกสารและปรับการกำหนดค่าข้อมูลประจำตัว ผู้ดูแลระบบสามารถย้ายแอปพลิเคชันไปยัง Kerberos และลดการใช้งาน NTLM ได้ 

นอกจากนี้ พิจารณาเพิ่มการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA ได้ทุกที่) เมื่อใดก็ตามที่เป็นไปได้ แม้ว่า NTLM หรือ Kerberos จะยังคงใช้งานอยู่ MFA จะช่วยลดความเสี่ยงได้อย่างมาก การขโมยข้อมูลประจำตัว และการใช้อย่างผิดวิธี Silverfort ขยายการป้องกัน MFA ไปสู่โปรโตคอลการตรวจสอบสิทธิ์ เช่น NTLM และ Kerberosซึ่งให้ชั้นการป้องกันพิเศษสำหรับทั้งระบบเดิมและระบบสมัยใหม่ 

ขั้นตอนที่ 5: วางแผนปิดแอปพลิเคชันที่ใช้ NTLM

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

แผนนี้ควรประกอบด้วย: 

การอัพเกรด – เปลี่ยนไปใช้แอปพลิเคชันเวอร์ชันใหม่ที่รองรับ Kerberos หรือมาตรฐานการตรวจสอบสิทธิ์สมัยใหม่ ผู้จำหน่ายหลายรายยกเลิกการพึ่งพา NTLM ในเวอร์ชันล่าสุด 

เปลี่ยน – หากไม่สามารถอัปเกรดได้ ให้ประเมินตัวเลือกทดแทนที่สอดคล้องกับกลยุทธ์การระบุตัวตนของคุณ 

การรื้อถอน – กำหนดระยะเวลาที่ชัดเจนสำหรับการยุติการใช้งานแอปพลิเคชันที่ต้องอาศัย NTLM เพียงอย่างเดียว 

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

การใช้ IP แทนชื่อโฮสต์ – เมื่อไคลเอนต์เชื่อมต่อด้วยที่อยู่ IP แทนที่จะเป็น NetBIOS หรือชื่อโฮสต์ DNS จะไม่สามารถใช้ Kerberos ได้ และบังคับให้ใช้ NTLM แทน 

การใช้ Kerberos ที่ไม่เหมาะสมในแอปพลิเคชัน – แอปพลิเคชันบางตัวไม่สามารถนำ Kerberos ไปใช้ได้อย่างถูกต้อง และเลือกใช้ NTLM แทน ตัวอย่างที่ดีของการใช้งานที่ไม่เหมาะสมคือ ช่องโหว่การปลอมแปลงของ KDC ระบุโดย Silverfort ในผลิตภัณฑ์หลายชนิด เช่น IBM QRadar (CVE-2019-4545)  Cisco ASA และ เครือข่ายพาโลอัลโต PAN-OS , ซึ่งการจัดการ Kerberos ที่ไม่ถูกต้องทำให้ผู้โจมตีสามารถหลีกเลี่ยง Kerberos และได้รับการเข้าถึงที่สูงขึ้นได้ (อ่านเพิ่มเติมที่นี่). 

หากต้องการทราบข้อมูลสรุปขั้นตอนเหล่านี้โดยย่อ ซึ่งคุณสามารถแบ่งปันกับทีมของคุณได้ เยี่ยมชมที่นี่.

การตรวจจับและแก้ไขปัญหาเหล่านี้ถือเป็นสิ่งสำคัญในการป้องกันไม่ให้ NTLM กลับมาปรากฏขึ้นอีกหลังจากที่คุณเชื่อว่าปัญหาดังกล่าวถูกกำจัดไปแล้ว 

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

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