auth-nocache กับไฟล์ข้อมูลรับรอง: ช่วยหรือทำร้าย?

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

สองวิธีตอบคำขอข้อมูลรับรอง

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

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

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

auth-nocache ทิ้งอะไรจริง ๆ

เมื่อล็อกอินแบบโต้ตอบ --auth-nocache จะลบสำเนาที่เก็บไว้ออกจากหน่วยความจำหลังใช้งานแล้ว ค่าใช้จ่ายคือคำถามใหม่ในทุกช่วงการเจรจาใหม่ เพราะรอบถัดไปไม่สามารถใช้สิ่งที่ถูกทิ้งไปแล้วซ้ำได้

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

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

จุดที่เส้นทางแบบไฟล์พัง

ไคลเอนต์ที่เริ่มเป็น root เพื่อเปิดอุปกรณ์อุโมงค์แล้วเปลี่ยนไปเป็น user และ group จะอ่านไฟล์ข้อมูลรับรองสองครั้ง ครั้งหนึ่งก่อนการเปลี่ยน อีกครั้งในการเจรจาใหม่ที่ตามมา หากไฟล์อยู่ในโหมด 600 และเป็นของ root การอ่านครั้งที่สองจะล้มเหลว และความล้มเหลวนั้นจะปรากฏขึ้นหนึ่งชั่วโมงต่อมาในฐานะข้อผิดพลาดการยืนยันตัวตนที่ดูเหมือนปัญหาของเซิร์ฟเวอร์ ตรวจสอบบันทึกของไคลเอนต์รอบช่วงการเจรจาใหม่ แล้วตรวจสอบบัญชีและไฟล์ร่วมกัน

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

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

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

กรณีที่ต้องการตัวเลือกนี้จริง ๆ

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

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

แยกสองเหตุผลนี้ไว้ในคอมเมนต์ของโปรไฟล์ ไม่อย่างนั้นผู้ดูแลคนถัดไปจะถือว่าตัวเลือกอยู่ที่นั่นด้วยเหตุผลที่เขาเองจะเลือก

การเปรียบเทียบในหนึ่งการตัดสินใจ

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

ไม่มีรูปแบบใดทำให้รหัสผ่านที่เก็บไว้ปลอดภัยได้ด้วยตัวเอง และไม่มีรูปแบบใดทำให้คำเตือนตอนเริ่มมีความหมาย

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