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

เป็นไปได้ไหม

เราต้องการให้ผู้ใช้บางคนสามารถทำได้เช่นsudoและกลายเป็นรูต

นั่นคือปัญหาที่ sudo ออกแบบมาเพื่อแก้ปัญหาเพื่อให้ส่วนนั้นง่ายพอ

แต่ด้วยข้อ จำกัด ที่ผู้ใช้ไม่สามารถเปลี่ยนรหัสผ่านรูตได้

คุณสามารถดังที่SHWชี้ให้เห็นในความคิดเห็นกำหนดค่า sudo เพื่ออนุญาตเฉพาะการกระทำบางอย่างที่จะนำมาเป็นรูทโดยผู้ใช้บางราย นั่นคือคุณสามารถอนุญาตให้ user1 จะทำอย่างไรsudo services apache2 restartให้ user2 ที่จะทำsudo rebootแต่ไม่มีอะไรอื่นขณะที่ช่วยให้ได้รับการว่าจ้างในฐานะผู้ดูแลระบบที่จะทำuser3 sudo -iมีวิธีการตั้งค่า sudo แบบนั้นหรือคุณสามารถค้นหา (หรือถาม) ที่นี่ นั่นเป็นปัญหาที่แก้ไขได้

อย่างไรก็ตามผู้ใช้ที่ได้รับความสามารถในการsudo -iหรือsudoเข้าไปในเปลือก ( sudo bashเช่น) สามารถทำอะไรก็ได้ นั่นเป็นเพราะเมื่อ sudo เปิดตัวกระสุน sudo ก็ออกมาจากภาพ มันให้บริบทการรักษาความปลอดภัยของผู้ใช้ที่แตกต่างกัน (ส่วนใหญ่มักจะเป็น root) แต่ไม่มีการพูดในสิ่งที่แอปพลิเคชันที่ดำเนินการทำ หากแอปพลิเคชันนั้นเปิดใช้งานpasswd rootจะไม่มีสิ่งใด sudo สามารถทำได้ โปรดทราบว่าสามารถทำได้ผ่านแอปพลิเคชันอื่นเช่นกัน ตัวอย่างเช่นตัวแก้ไขขั้นสูงจำนวนมากมีเครื่องมืออำนวยความสะดวกในการเรียกใช้คำสั่งผ่านเชลล์ซึ่งเชลล์จะถูกเรียกใช้งานด้วย uid ที่มีประสิทธิภาพของกระบวนการแก้ไขนั้น (นั่นคือรูท)

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

ขออภัย; หากคุณหมายถึง "มั่นใจว่าเราจะสามารถเข้าสู่ระบบและใช้ระบบได้ไม่ว่าผู้ใช้ที่มีสิทธิ์เข้าถึงรูทจะทำอะไร" นั่นไม่สามารถทำได้ (สำหรับทุกเจตนาและวัตถุประสงค์) "sudo rm / etc / passwd" หรือ "sudo chmod -x / bin / bash" อย่างรวดเร็ว (หรือรูทเชลล์ใดก็ตามที่ใช้) และคุณจะถูกซ่อนอยู่มาก ความหมาย "สวยมาก" คุณจะต้องเรียกคืนจากการสำรองข้อมูลและหวังว่าพวกเขาจะไม่ทำอะไรที่เลวร้ายไปกว่าการใช้นิ้วมือ " คุณสามารถทำตามขั้นตอนบางอย่างเพื่อลดความเสี่ยงของอุบัติเหตุโดยไม่ตั้งใจซึ่งนำไปสู่ระบบที่ใช้ไม่ได้ แต่คุณไม่สามารถป้องกันความอาฆาตพยาบาทที่ทำให้เกิดปัญหาร้ายแรงมากจนถึงและรวมถึงจุดที่ต้องสร้างระบบใหม่จากศูนย์หรืออย่างน้อยที่สุด สำรองข้อมูลที่ดี

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

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

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

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

ในสถานการณ์ของคุณคุณจะต้อง จำกัด การเข้าถึงsuและpasswdคำสั่งและการเข้าถึงแบบเปิดเพื่อทุกอย่างอื่น ปัญหาคือไม่มีสิ่งใดที่คุณสามารถทำได้เพื่อป้องกันผู้ใช้ของคุณจากการแก้ไข/etc/shadow(หรือ/etc/sudoersสำหรับเรื่องนั้น) โดยตรงและวางรหัสผ่านการเปลี่ยนรูทเป็นไฮแจ็กรูท และนี่เป็นเพียงสถานการณ์ "โจมตี" ที่ตรงไปตรงมาที่สุด Sudoers ที่มีกำลังไม่ จำกัด ยกเว้นคำสั่งหนึ่งหรือสองคำสั่งสามารถแก้ไขข้อ จำกัด เพื่อจี้เข้าถึง root ได้อย่างสมบูรณ์

ทางออกเดียวที่แนะนำโดยSHW ในความคิดเห็นคือการใช้sudoเพื่อให้ผู้ใช้ของคุณเข้าถึงชุดคำสั่งที่ จำกัด แทน

ปรับปรุง

อาจมีวิธีที่จะทำให้สำเร็จหากคุณใช้ Kerberos tickets เพื่อตรวจสอบสิทธิ์ อ่านเอกสารนี้เพื่ออธิบายการใช้.k5loginไฟล์

ฉันพูดส่วนที่เกี่ยวข้อง:

สมมติว่าผู้ใช้อลิซมีไฟล์. k5login ในโฮมไดเร็กทอรีของเธอที่มีบรรทัดต่อไปนี้:
bob@FOOBAR.ORG
ซึ่งจะอนุญาตให้ bob ใช้แอปพลิเคชันเครือข่าย Kerberos เช่น ssh (1) เพื่อเข้าถึงบัญชีของ alice โดยใช้ตั๋ว Kerberos ของ bob
...
โปรดทราบว่าเนื่องจากบ็อบเก็บรักษาตั๋ว Kerberos ไว้สำหรับเงินต้นของเขาเองbob@FOOBAR.ORGเขาจะไม่ได้รับสิทธิพิเศษใด ๆ ที่จำเป็นต้องมีตั๋วของอลิซเช่นการเข้าถึงรูทไปยังโฮสต์ของไซต์ใด ๆ หรือความสามารถในการเปลี่ยนรหัสผ่านของอลิซ

ฉันอาจจะเข้าใจผิด แต่ ฉันยังคงอ่านเอกสารและยังไม่ทดลองใช้ Kerberos ด้วยตัวเอง

ฉันสมมติว่าคุณต้องการให้แน่ใจว่าคุณมีสิทธิ์เข้าถึง "ผู้ดูแลระบบฉุกเฉิน" แม้ว่าผู้ดูแลระบบที่แท้จริงของคุณจะหมดสติ (แต่นอกเหนือไปจากนั้น

วิธีที่นิยม (แม้ว่า hackish มาก) คือการมีผู้ใช้ที่สองกับuid=0ชื่อทั่วไปtoor(รากย้อนหลัง) มันมีรหัสผ่านที่แตกต่างกันและสามารถใช้เป็นการเข้าถึงข้อมูลสำรองได้ หากต้องการเพิ่มคุณอาจต้องแก้ไข/etc/passwdและ/etc/shadow(คัดลอกrootบรรทัด)

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

หรือคุณอาจต้องการตรวจสอบกลไกการตรวจสอบรับรองทางเลือกเช่นsshคีย์libnss-extrausers, LDAP และอื่น ๆ

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

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

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

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

แน่นอนว่าผู้ใช้ที่มีการเข้าถึงประเภทนั้น (และมีความรู้เล็กน้อย) อาจสามารถแฮ็คระบบได้อย่างง่ายดาย แต่อย่างน้อยคุณก็กำลังทำงานกับรูปแบบความปลอดภัยของระบบปฏิบัติการ

PS มีหลายวิธีในการจัดการการเข้าถึงรูทสำหรับตัวคุณเองโดยไม่ต้องใช้รหัสผ่าน หนึ่งถ้าคุณอยู่ใน/etc/sudoers(โดยไม่มีข้อ จำกัด ) sudo bashคุณจะต้องใช้รหัสผ่านของคุณเองที่จะกลายเป็นรากเช่นกับ แต่คุณก็ไม่จำเป็นต้องไปที่นั่น

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

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

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

ฉันไม่รู้ว่ามันจะเป็นจริงได้ แต่นี่คือแฮ็คที่สกปรก:

1. เขียนสคริปต์ / โปรแกรม wrapper ซึ่งจะคัดลอก/etc/passwdไฟล์ไปยังตำแหน่งอื่นก่อนโทรจริงsudo
2. อนุญาตให้ผู้ใช้ปกติใช้ sudo
3. เมื่อเขาทำงานเสร็จหรือเมื่อเขาออกมาจาก sudo ให้เรียกคืน/etc/passwdไฟล์

ฉันรู้ว่ามีหลายสิ่งหลายอย่างที่คุณต้องพิจารณาเพื่อให้ได้ ท้ายที่สุดมันแฮ็คที่สกปรก

คำสั่งที่sudoมีไว้สำหรับให้สิทธิ์รูทและไม่มีการป้องกันหลังจากนั้นเป็นเท็จโจ๋งครึ่ม

คุณใช้visudoเพื่อแก้ไขไฟล์ sudoers นี่คือตัวอย่างบรรทัด:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroเป็นชื่อผู้ใช้ที่เราอนุญาต วาง%ที่ด้านหน้าเพื่อทำให้มันใช้ได้กับกลุ่ม
• ALLเป็นชื่อสำหรับกฎนี้ Sudoers สามารถทำได้มากกว่าการให้สิทธิ์ระดับโลก นั่นคือสิ่งที่มันซับซ้อน
• = ไม่ต้องการคำอธิบาย
• ALL:ALLอ่านว่า (who_to_run_it_as: what_group_to_run_it_as) วิธีนี้คุณสามารถอนุญาตให้เรียกใช้คำสั่ง แต่เฉพาะในบริบทของผู้ใช้หรือกลุ่มที่ระบุ
• NOPASSWD: บอกให้ปิดพรอมต์รหัสผ่าน
• /path/to/command ให้คุณระบุคำสั่งเฉพาะ path_to_commmand, else_command

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

อ้างอิง

• จากคำตอบอื่นของฉันที่นี่

(ฉันไม่รู้อูบุนตู แต่ควรคล้ายกับ Fedora / Red-Hat)
สิ่งเดียวที่ฉันสามารถจินตนาการถึงการ จำกัด การเข้าถึงการเปลี่ยนรหัสผ่านรูทไม่ได้ให้สิทธิ์การเข้าถึงรูททั้งหมดด้วย sudo หรือใช้ SElinux เพื่อ จำกัด การเข้าถึง ไปยังไฟล์รหัสผ่าน ... แต่ฉันจะไม่ไว้วางใจด้วยการเข้าถึงมากที่สุดเท่าที่รูทโดยทั่วไปมีการเข้าถึงที่ไม่ จำกัด และสามารถอัปเดต SElinux หรือติดตั้งไฟล์รหัสผ่านที่ติดตั้งใหม่หรือรันโปรแกรม pre-prepred เพื่อเปลี่ยนรหัสผ่าน

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

หากคุณพยายามปกป้องการเข้าถึงรูทของคุณเท่านั้นให้ตั้งค่าโปรแกรมที่สามารถกู้คืนรหัสผ่านรูทได้แม้ว่าจะมีการเปลี่ยนแปลง แต่ก็สามารถเรียกคืนได้ด้วยการเข้าถึงขั้นต่ำ (sudo ทำได้ดีในตัวมันเอง)

ความต้องการของคุณคือ:

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

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

1. เรียกใช้เซิร์ฟเวอร์ภายในสภาพแวดล้อมเสมือน คุณจะสามารถเมานต์ระบบไฟล์ของเซิร์ฟเวอร์และแทนที่ไฟล์ที่แก้ไขด้วยเวอร์ชันที่รู้จักกันดี ขึ้นอยู่กับความเสียหายที่เป็นไปได้ที่คุณคาดหวังคุณสามารถถ่ายภาพของไดเรกทอรีที่สำคัญทั้งหมด (/ bin, / sbin, / etc, / usr, / var ฯลฯ ) และขยาย snapshot เพื่อเขียนทับไฟล์ที่เสียหายขณะที่เหลือ ระบบไม่เป็นอันตราย

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

3. โมดูลเคอร์เนล Linux Security Modules (LSM) ของเคอร์เนลเป็นพื้นฐานสำหรับการสร้างโมดูลที่ปลอดภัย LSM ใช้โดย SELinux แต่ยังใช้ในระบบที่รู้จักและใช้งานง่ายกว่าเช่น Smack, TOMOYO และ AppArmor บทความนี้มีภาพรวมที่ดีของตัวเลือก โอกาสเป็นหนึ่งในนั้นสามารถกำหนดค่าออกจากกล่องเพื่อป้องกันการเข้าถึง / etc / passwd, / etc / shadow หรือไฟล์อื่น ๆ ที่คุณต้องการแม้โดยรูท

4. แนวคิดเดียวกันกับ # 1 แต่เมื่อเซิร์ฟเวอร์ไม่ได้อยู่ในสภาพแวดล้อมเสมือน คุณสามารถโหลดเซิร์ฟเวอร์เชนลงในระบบปฏิบัติการแบบอ่านอย่างเดียวเช่นไลฟ์ซีดีซึ่งจะเมานต์ระบบไฟล์ของเซิร์ฟเวอร์โดยอัตโนมัติและเขียนทับระบบฐานในการบู๊ตแต่ละครั้งด้วยสำเนาที่รู้จักกันดี ระบบปฏิบัติการแบบอ่านอย่างเดียวจะบูตเข้าสู่ระบบปฏิบัติการหลัก

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

เทคโนโลยีอื่น ๆ ที่คุณอาจต้องการตรวจสอบตามความต้องการของคุณ:

• สถาปัตยกรรมการวัดความสมบูรณ์ของ Linux / โมดูลการตรวจสอบเพิ่มเติม (IMA / EVM) และ
• โมดูลแพลตฟอร์มที่เชื่อถือได้ (TPM)

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

ข้อได้เปรียบที่ยิ่งใหญ่ของสิ่งนี้คือไม่มีสิ่งใดที่จะกำหนดค่า คำถามของคุณจะกลายเป็น: " ฉันลืมรหัสผ่านรูทฉันจะกลับมาได้อย่างไร " และคำตอบคือต้องรีบู๊ตและเลือกโหมดผู้ใช้คนเดียวเมื่อเครื่องเกิดขึ้น นั่นทำให้คุณรูทเชลล์โดยไม่จำเป็นต้องรู้รหัสผ่าน ถึงตอนนี้คุณสามารถตั้งรหัสผ่านใหม่ได้ (เช่นเดียวกับไปและซ่อมแซมความเสียหายใด ๆ ... )

หากคุณโคลนเซิร์ฟเวอร์ของคุณให้เป็น VM (เช่นVirtualBox ) คุณสามารถให้เข้าถึงรากอิสระกับผู้คนและยังคงรับประกันได้ว่าคุณจะมีการเข้าถึงโดยตรงพาร์ทิชันระบบปฏิบัติการของแขกของ (s), และดังนั้นจึงรักษาควบคุมครั้งสุดท้ายเหนือ/etc/passwdและ เหมือนคุณจะได้รูทบนระบบโฮสต์

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

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

แต่สมมติว่าคุณสามารถไว้วางใจผู้ใช้ของคุณจะไม่เป็นความชั่วร้ายเจตนาคุณสามารถทำให้ข้อ จำกัด ในการใช้รหัสผ่านการเปลี่ยนแปลงเรื่องของนโยบาย คุณสามารถสร้าง wrapper สำหรับpasswdโปรแกรมที่จะเตือนพวกเขาว่า "กรุณาอย่าเปลี่ยนรหัสผ่านรูท" นี่ถือว่าแหล่งที่มาของปัญหาคือผู้ใช้ที่เปลี่ยนรหัสผ่านรูทกำลังทำอยู่เนื่องจากมีความเข้าใจผิด (เช่นอาจคิดว่าพวกเขากำลังเปลี่ยนรหัสผ่านของตนเองหลังจากที่ทำเสร็จแล้วsudo bash)

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

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

1. ตรวจสอบเมื่อผู้ใช้เปลี่ยนข้อมูลประจำตัวเป็นรูทและติดตามกระบวนการที่สร้างขึ้นใด ๆ
2. ล็อกการสร้างกระบวนการจากนั้นเป็นต้นมาเพื่อดูว่าใครเป็นผู้ใช้ต้นฉบับที่รับผิดชอบในแต่ละกระบวนการและใช้รีโมตโฮสต์ที่ผู้ใช้ที่เชื่อถือได้ครึ่งไม่มีสิทธิ์เข้าถึงเพื่อส่งบันทึก
3. ใช้ประเภทของการติดตามบางระบบเข้าสู่ระบบสิ่งที่เกิดขึ้นและต่อมาจะสามารถค้นพบว่าใครอยู่เบื้องหลังการละเมิดนโยบาย

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

การดำเนินการสามารถทำได้โดยการแก้ไข libcหรือการติดตามการโทรของระบบ (ดีกว่า)

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

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

ปัญหาคือ: ถ้าเจ้าของมีสิทธิ์เข้าถึงกล่องมันสามารถกู้คืน Acces แบบลอจิคัลไปยังระบบได้อย่างง่ายดาย ถ้าไม่ - การรักษารหัสผ่านรูทจะไม่ช่วยเช่นการตั้งค่า sshd หรือการตั้งค่าเครือข่ายไม่ดีดังนั้นระบบยังไม่สามารถเข้าถึงได้

หัวข้อเกี่ยวกับวิธีป้องกันระบบจากความเสียหายโดยบุคคลที่มีสิทธิ์ระดับผู้ดูแลนั้นกว้างเกินไปที่จะจัดรูปแบบคำถาม SE

การพูดเกี่ยวกับวิธีแก้ปัญหาฉุกเฉินระยะไกลทางไกลวิธีที่ดีที่สุดคือ IPMI (ฉันคิดว่า) ถ้ามี เจ้าของระบบสามารถเชื่อมต่อไดรฟ์เสมือนได้ตลอดเวลาบูตจากมันและดำเนินการตามการกู้คืนระบบ

หาก IPMI ไม่พร้อมใช้งานเทคโนโลยีการจำลองเสมือนที่เหมาะสมใด ๆ สามารถทำงานได้ตามที่ได้รับการเสนอข้างต้น

คุณสามารถ จำกัด การเข้าถึง sudo ใน/etc/sudoersไฟล์ของคุณ

เพื่ออธิบายไวยากรณ์ของ / etc / sudoers อย่างเต็มที่เราจะใช้กฎตัวอย่างและแยกย่อยแต่ละคอลัมน์:

jorge  ALL=(root) /usr/bin/find, /bin/rm

คอลัมน์แรกกำหนดผู้ใช้หรือกลุ่มกฎ sudo นี้ที่ใช้ ในกรณีนี้มันคือผู้ใช้ jorge หากคำในคอลัมน์นี้นำหน้าด้วยสัญลักษณ์% คำนั้นจะกำหนดค่านี้เป็นกลุ่มแทนที่จะเป็นผู้ใช้เนื่องจากระบบสามารถมีผู้ใช้และกลุ่มที่มีชื่อเดียวกัน

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

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

ค่าสุดท้าย (/ usr / bin / find, / bin / rm) เป็นรายการคำสั่งที่คั่นด้วยเครื่องหมายจุลภาคที่ผู้ใช้ในคอลัมน์แรกสามารถเรียกใช้ในฐานะผู้ใช้ในคอลัมน์ที่สาม ในกรณีนี้เราอนุญาตให้ jorge รัน find และ rm เป็น root ค่านี้ยังสามารถตั้งค่าเป็น wildcard ทั้งหมดซึ่งจะอนุญาตให้ jorge รันคำสั่งทั้งหมดบนระบบในฐานะรูท

เมื่อคำนึงถึงสิ่งนี้คุณสามารถอนุญาตให้ใช้คำสั่ง X ในรูปแบบที่คั่นด้วยจุลภาคและตราบใดที่คุณไม่ได้เพิ่มpasswdสิ่งนี้คุณควรจะปรับ

ไม่มีราก 1/2 :) เมื่อคุณให้สิทธิพิเศษแก่รูทพวกเขาสามารถทำสิ่งที่พวกเขาต้องการ หรือคุณสามารถใช้ sudo เพื่อรันเชลล์bash ที่ จำกัดหรือรัน rbash โดยไม่มีสิทธิ์รูท

หากคุณต้องการมีกลไกที่ไม่ปลอดภัยในการเข้าสู่เซิร์ฟเวอร์ในฐานะผู้ใช้คุณสามารถสร้างผู้ใช้อื่นด้วยuid=0หรือสร้าง cron อย่างง่ายซึ่งจะรีเซ็ตรหัสผ่านรูทเป็นระยะ

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

ซู -

กลายเป็นราก uid ของรูท = 0; uid ของล้อ = 10 ผู้คนใช้ชื่อ แต่ระบบปฏิบัติการใช้ uid คำสั่งบางอย่างไม่สามารถเรียกใช้โดยสมาชิกของกลุ่มล้อ (ถ้าคุณใช้วงล้ออย่าทำผิดพลาดในการเพิ่มรูตในฐานะสมาชิกกลุ่มล้อ) ดูเอกสารของ Red Hat ถ้าคุณไม่รู้ว่าวงล้อคืออะไร

อีกตัวเลือกหนึ่งคือใช้คีย์ ssh แทนรหัสผ่าน สมมติว่าคุณมั่นใจได้ว่าคนที่ใช้ sudo จะไม่เพิ่มกุญแจสาธารณะของพวกเขาลงในไฟล์ ~ / .ssh / authorizedkeys สิ่งนี้จะทำให้เกิดความกังวลเกี่ยวกับการเปลี่ยนรหัสผ่านของ root เนื่องจากรหัสผ่าน root จะถูกละเว้นอย่างมีประสิทธิภาพ

หากคุณต้องการเพิ่มความน่าเชื่อถือให้กับผู้ใช้เหล่านี้ (เพื่อไม่เพิ่มรหัสสาธารณะของตัวเอง) ให้ลองใช้แอตทริบิวต์ไฟล์เพิ่มเติมและใช้บิตที่ไม่เปลี่ยนรูป หลังจากสร้างไฟล์ ~ / .ssh / authorizedkeys ของคุณและหลังจากกำหนดค่า / etc / ssh / sshd_config และ / etc / ssh / ssh_config เท่าที่คุณต้องการให้ตั้งค่าบิตที่ไม่เปลี่ยนรูป แน่นอนว่ายังมีวิธีที่จะไขสกรูด้วยเช่นกัน - ไม่มีอะไรสมบูรณ์แบบ

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

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

- John Crout

วิธีหนึ่งคือเพื่อให้แน่ใจว่า/etcไม่สามารถเขียนได้ โดยไม่มีใครตราบใดที่อาจมีsudoerรอบ

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

ที่สามารถทำได้โดยใช้อุปกรณ์ท้องถิ่นที่ป้องกันการเข้าถึงการเขียนไป (ค้นหาwrite blockerฮาร์ดแวร์)

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

เพื่อให้แน่ใจว่าผู้ใช้ยังไม่สามารถกรูขึ้นความสามารถในการเข้าสู่ระบบของคุณต้องได้อ่านอย่างเดียวติดตั้งและ/bin/sbin

และคุณจะต้องมีสคริปต์ที่คืนค่าการเชื่อมต่อเครือข่ายเป็นระยะ

(ในฐานะ sidenote: หากคุณอนุญาตให้ sudoer มีชุดคำสั่งที่ จำกัด อย่างมากเท่านั้นและสำหรับแต่ละคำสั่งที่ปลอดภัยว่าพวกเขาไม่สามารถแยกออกจากพวกเขา / เปลี่ยนพวกเขา ฯลฯ คุณสามารถป้องกันได้ในขณะที่/etcเขียนได้ .. )