เหตุใดการรันชื่อ (ผูก) ใน chroot จึงมีความสำคัญต่อความปลอดภัย หรืออาจจะไม่ใช่

ฉันกำลังเล่นกับการเชื่อมโยงและเริ่มสงสัยว่าทำไมซอฟต์แวร์นี้เป็นเช่นใน CentOS ทำงานใน chroot อย่าเข้าใจฉันผิดฉันรู้ว่าการผูกคืออะไรและ chroot (คุก) มีไว้เพื่ออะไร แต่คำถามหลักของฉันคือการผูกที่ไม่มี chroot ไม่ปลอดภัยมาก?

เป็นอันตรายหรือไม่หากตั้งค่าโดยไม่ต้องติดคุก (มากกว่าบริการหรือซอฟต์แวร์อื่น ๆ ) ในระบบมีหลาย proccesses ทำงานโดยไม่ต้อง chroot และฉันคิดว่าการประนีประนอมของใด ๆ ของพวกเขาเป็นสิ่งที่อันตรายมาก แต่สิ่งที่ทำให้ชื่ออันตรายมากขึ้นแล้วซอฟต์แวร์อื่น ๆ ที่ทำงานโดยไม่ต้อง chroot?

@Some Guy พูดถึงคุณต้องคิดเกี่ยวกับเรื่องนี้ในมุมมองทางประวัติศาสตร์

มุมมองทางประวัติศาสตร์คือฮาร์ดแวร์ชิ้นเดียวเป็นบริการที่แตกต่างกันหลายสิบรายการภายใต้ระบบปฏิบัติการเดียว หากบริการหนึ่งถูกทำลายทุกอย่างในฮาร์ดแวร์นั้นจะถูกทำลาย

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

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

การโยงเวอร์ชันก่อนหน้าไม่ได้ตัดสิทธิ์ บน Unix เฉพาะบัญชีรูทเท่านั้นที่สามารถเปิดพอร์ตที่ต่ำกว่า 1024 และผูกตามที่เราทุกคนรู้ว่าจำเป็นต้องฟังใน udp / 53 และ tcp / 53 เนื่องจากการเชื่อมโยงเริ่มต้นในฐานะรูทและไม่ปล่อยสิทธิ์การประนีประนอมใด ๆ ก็หมายความว่าระบบทั้งหมดอาจถูกบุกรุกได้ ซอฟต์แวร์เกือบทุกวันนี้จะเริ่มเปิดซ็อกเก็ตและทำสิ่งอื่น ๆ ที่ต้องการสิทธิ์รูทจากนั้นพวกเขาจะเปลี่ยนผู้ใช้ที่พวกเขาใช้งานเป็นบัญชีที่ไม่มีสิทธิพิเศษ เมื่อสิทธิ์ลดลงผลกระทบของการถูกบุกรุกจะต่ำกว่าระบบโฮสต์มาก

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

สมมติว่ามีช่องโหว่ที่สามารถนำไปใช้ประโยชน์ได้ใน BIND และบางคนสามารถใช้รหัสโดยอำเภอใจได้ หากพวกเขาอยู่ใน chroot พวกเขาต้องแบ่งออกก่อนที่จะไปทำอะไรอย่างอื่นในระบบ ตามที่ระบุไว้ในสิทธิ์ใช้งานรูตที่จำเป็นสำหรับ chroot-break BIND ไม่ได้ทำงานในฐานะรูทและควรมีเครื่องมือขั้นต่ำที่มีให้ใน chroot จำกัด ตัวเลือกเพิ่มเติม หากไม่มีการเรียกระบบเพื่อเพิ่มสิทธิพิเศษฝ่ายตรงข้ามจะมองไปที่ระเบียน DNS ของคุณ

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

คำนำ

ฉันได้ยินผู้คนคงย้ำความเข้าใจผิดจากทั่วทุกมุมอินเทอร์เน็ต .. ดังนั้นฉันจะพยายามชี้แจงให้ฟัง

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

คืออะไรและอะไรคือคุก Chroot

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

chroot ถูกใช้อย่างมีประสิทธิภาพและอยู่ในฐานรหัสสำหรับหลาย ๆโปรแกรมและไลบรารี (เช่น openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot และอื่น ๆ อีกมากมาย ) สมมติว่าแอพพลิเคชั่นหลักเหล่านี้ได้ติดตั้งระบบความปลอดภัยที่ผิดพลาดนั้นไม่เป็นความจริง

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

บางขั้นตอนในการรักษาความปลอดภัย chroot คุกของคุณ

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

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

ไม่ใช่ผู้ดูแลระบบทุกคนที่มีระดับความรู้ที่จำเป็นในการรักษาความปลอดภัยพารามิเตอร์เคอร์เนลที่จำเป็นทั้งหมดบนเซิร์ฟเวอร์เฉพาะหรือภายใต้ระบบเสมือนจริงเต็มรูปแบบ นี่หมายความว่าการปรับใช้ OpenVZ หมายความว่าลูกค้าของคุณจะมีพื้นผิวการโจมตีน้อยลงเพื่อพยายามปกปิดและปลอดภัยก่อนที่จะปรับใช้แอปพลิเคชันของตน โฮสต์ที่ดีจะทำงานได้ดีในการรักษาพารามิเตอร์เหล่านี้และในทางกลับกันสิ่งนี้จะดีกว่าสำหรับทุกคนใน Node หรือในศูนย์ข้อมูล แต่สำหรับอินเทอร์เน็ตโดยรวม ...

ตามที่ระบุไว้ chroot จัดเตรียมการจำลองเสมือนของระบบไฟล์ คุณต้องตรวจสอบให้แน่ใจว่าไม่มีไฟล์ปฏิบัติการที่เรียกใช้ setuid, แอปพลิเคชันที่ไม่ปลอดภัย, ห้องสมุด, การเชื่อมโยงที่ไม่มีเจ้าของห้อย ฯลฯ หากผู้โจมตีสามารถประนีประนอมผูกมัดพวกเขาจะต้องกัดเซาะระบบไฟล์เสมือน ในทางอื่นประนีประนอมบางสิ่งบางอย่างที่อาศัยอยู่ภายใน chroot- หนีคุกมักจะผ่านการเพิ่มสิทธิหรือฉีดของเขาหรือเธอเข้าสู่ระบบฐาน

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

เหตุใดจึงยังคงใช้ chroot เมื่อเทียบกับการจำลองเสมือนระบบเต็มรูปแบบ

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

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

พิจารณาสถานการณ์อื่น: คุณมี apache ที่ทำงานอยู่ในสภาพแวดล้อมเสมือนจริง คุณต้องการแยกผู้ใช้แต่ละคน การจัดเตรียมระบบไฟล์เสมือนผ่าน chroot เพิ่มเข้าสู่ apache (mod_chroot, mod_security และอื่น ๆ ) จะเป็นตัวเลือกที่ดีที่สุดเพื่อให้มั่นใจถึงความเป็นส่วนตัวสูงสุดระหว่างผู้ใช้ สิ่งนี้ยังช่วยป้องกันการรวบรวมข้อมูลของ Intel และมอบความปลอดภัยอีกชั้นหนึ่ง

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

เพื่อตอบคำถามของคุณ

ฉันไม่ได้ใช้ CentOS เป็นพิเศษ แต่ฉันรู้ว่าตอนนี้ Bind จะลดสิทธิ์ของมันก่อนดำเนินการ ฉันจะถือว่าอย่างไรก็ตามการผูกนั้นถูก chrooted เนื่องจากประวัติของเวกเตอร์การโจมตีและช่องโหว่ที่อาจเกิดขึ้น

นอกจากนี้ ... มันเหมาะสมกว่าที่จะ chroot แอปพลิเคชันนี้โดยอัตโนมัติมากกว่าที่จะไม่เพราะทุกคนไม่สามารถเข้าถึงการจำลองเสมือนระดับระบบ / ระบบปฏิบัติการทั้งหมด สิ่งนี้ในทางกลับกันและในทางทฤษฎีช่วยให้มีความปลอดภัยแก่ฐานผู้ใช้ CentOS:

ผู้ให้บริการระบบปฏิบัติการไม่ได้คิดว่าทุกคนกำลังใช้ระบบเดียวกัน ด้วยวิธีนี้พวกเขาสามารถช่วยเพิ่มระดับความปลอดภัยให้มากขึ้น ...

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

นี่คือบางส่วนเนื่องจากเหตุผลทางประวัติศาสตร์เมื่อเวอร์ชันเก่าของ Bind มีช่องโหว่ด้านความปลอดภัยที่รุนแรงและบ่อยครั้ง ฉันยังไม่ได้ติดตามเรื่องนี้ แต่ฉันเดิมพันว่ามันดีขึ้นมากตั้งแต่วันที่ไม่ดี

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

ดังนั้นจึงมักจะเป็นกฎของหัวแม่มือในเรื่องความปลอดภัย: ปลอดภัยกว่าขออภัยโดยเฉพาะอย่างยิ่งในความพยายามของ chroot-ing มันค่อนข้างน้อย