ไม่ใช่ว่ามันเป็นความคิดที่ดีที่จะเปลี่ยน แต่เพื่อความสนุก ตามนี้โพสต์ยังคงมีปัญหาบางอย่างแม้หลังจากการเปลี่ยนแปลงรายการใน/etc/passwd
, และ/etc/shadow
/etc/sudoers
ข้อเสนอแนะใด ๆ
ไม่ใช่ว่ามันเป็นความคิดที่ดีที่จะเปลี่ยน แต่เพื่อความสนุก ตามนี้โพสต์ยังคงมีปัญหาบางอย่างแม้หลังจากการเปลี่ยนแปลงรายการใน/etc/passwd
, และ/etc/shadow
/etc/sudoers
ข้อเสนอแนะใด ๆ
คำตอบ:
ในทางทฤษฎีการเปลี่ยนแปลงใน/etc/passwd
และ/etc/shadow
จะเป็นสิ่งที่คุณต้องการที่จะ 'เปลี่ยนชื่อ' ราก ปัญหาเกิดขึ้นเนื่องจากซอฟต์แวร์ Unix ทุกชิ้นมีอยู่สมมติว่าชื่อผู้ใช้ 'root' มีอยู่และเป็น superuser - ชื่อแทนอีเมล, daemons ต่างๆ, cron ...
หากคุณพยายามที่จะลองทำดูคุณfind /etc -type f -exec grep -l root {} +
ควรเริ่มต้นการค้นหารายการไฟล์ปรับแต่งที่คุณอาจต้องเปลี่ยน - แต่อย่างที่คุณพูดไปแล้วนี่เป็นความคิดที่เลวมากในเกือบทุกสถานการณ์
แก้ไขความคิดอื่น - หากคุณยังไม่ได้ (ซึ่งคุณควรมี) ตรวจสอบให้แน่ใจว่า/etc/aliases
มีรายการroot
และชื่อผู้ใช้ที่มีอยู่หรือที่อยู่อีเมลที่ประเมินอย่างถูกต้อง งานระบบทั่วทั้งระบบอัตโนมัติจำนวนมาก ( cron
ตัวอย่างเช่น) ส่งเอาต์พุตของพวกเขาทางอีเมลไปยังroot
ซึ่งถูกใช้นามแฝงตามธรรมเนียมไปยังผู้ดูแลระบบที่รับผิดชอบการดำเนินการของระบบนั้น
chown root …
หรือคล้ายกันในเชลล์สคริปต์
ความกลัวทั้งหมดนี้กำลังพูดว่า "อย่าทำ!" ไร้สาระ ครั้งหนึ่งใช่มันอาจทำลายสคริปต์ที่เขียนไม่ดีมากมาย แต่ฉันคิดว่าสคริปต์เหล่านั้นจะไม่ธรรมดาอีกต่อไป อย่างน้อยไม่ได้อยู่ในการแจกแจงมาตรฐาน
เราได้รับคำสั่งให้เปลี่ยนชื่อบัญชีรูทบนเซตย่อยของเซิร์ฟเวอร์ linux ดังนั้นหลังจากพยายามค้นคว้าว่าจะทำอย่างไรให้ถูกต้องฉันกลับพบว่ามีหลายกระทู้ที่พูดว่า "อย่าทำ!" มีคำเตือนที่น่ากลัวมากมายเกี่ยวกับ "สิ่งไม่ดี" ที่เกิดขึ้นหากคุณเลือกที่จะทำเช่นนี้ แต่ฉันยังไม่พบอะไรกับตัวอย่างที่เป็นรูปธรรมของ "สิ่งเลวร้าย" ที่อาจเกิดขึ้นได้
ดังนั้นให้ฉันสำรองและอธิบายว่าฉันอยู่ที่ไหนและเรามาที่นี่ได้อย่างไร เรากำลังสร้างสภาพแวดล้อมที่เป็นไปตามมาตรฐาน PCI และหนึ่งในเครื่องมือที่ช่วยให้เราปฏิบัติตาม "ข้อกำหนด" เหล่านั้นกำลังบอกเราว่าเราจำเป็นต้องเปลี่ยนชื่อรูทและผู้ดูแลระบบและบัญชีผู้ใช้ทั่วไปเป็นอย่างอื่น สำหรับผู้ที่ไม่ได้รับการศึกษาเกี่ยวกับ PCI คุณมีตัวเลือกในการทำตามแนวทางหรือการจัดทำเอกสารว่าทำไมคุณไม่สามารถหรือไม่เลือกที่จะไม่ปฏิบัติตามแนวทางนั้นและกลยุทธ์ที่บรรเทาคุณต้องรักษาระบบให้ปลอดภัย ดังนั้นฉันคิดว่าสถานที่ส่วนใหญ่เอกสารทำไมพวกเขาจะไม่เปลี่ยนชื่อบัญชีรูทของพวกเขาอย่างไรก็ตามกลุ่มของเราได้ตัดสินใจว่าถ้าเราสามารถเปลี่ยนชื่อบัญชีผู้ดูแลระบบ windows โดยไม่มีปัญหาก็จะเปลี่ยนชื่อบัญชีรูทลินุกซ์ด้วย
ฉันมีประสบการณ์ในการโต้แย้ง "ความปลอดภัยผ่านความสับสน"; ฉันรู้ว่าการเปลี่ยนชื่อบัญชีรูทไม่ได้ช่วยเพิ่มความปลอดภัยมากนักควรปิดใช้งานรูทที่ SSH และอื่น ๆ ฉันรู้ว่านั่นไม่ใช่ประเด็นฉันไม่สนใจที่จะได้ยินมากขึ้น ฉันไม่สนใจคำเตือน "ท้องฟ้าจะตก" อีกต่อไป ฉันกำลังมองหาข้อความเช่นนี้: "> สิ่งเลวร้ายนี้ <จะเกิดขึ้นกับ> แพ็คเกจมาตรฐานนี้ <(เว้นแต่ว่าคุณ> ทำสิ่งนี้ <)"
จนถึงตอนนี้ฉันมีระบบ 3 CentOS (RHEL) ที่ดูเหมือนไม่มีปัญหาในการเปลี่ยนชื่อบัญชีรูท นี่คือสิ่งที่ฉันทำ: ฉันเปลี่ยนชื่อบัญชีใน / etc / passwd, / etc / shadow, / etc / group และ / etc / gshadow จากนั้น grepped สำหรับชื่อรูทใน / etc / และแก้ไขไฟล์นามแฝง postfix เพื่อให้รูทนั้นเป็นชื่อแทนชื่อบัญชีใหม่ของเราเรียกมันว่า rojotoro (ควรทำสิ่งที่คล้ายกันสำหรับระบบอีเมลอื่น) ฉันยังพบว่าฉันต้องเปลี่ยนการกำหนดค่าบางอย่างสำหรับ logrotate เมื่ออธิบายว่าใครควรเป็นเจ้าของไฟล์ที่มันจะสร้างขึ้นโดยอัตโนมัติ และนั่นคือทั้งหมดที่ฉันได้เปลี่ยนไป
ฉันดูสคริปต์ init.d หลายตัว แต่ไม่ได้เปลี่ยนแปลงอะไรเลยและทุกอย่างดูเหมือนจะเริ่มต้นได้ดีตอนบู๊ต ฉันต้องระบุบัญชีใหม่เมื่อใช้ sudo: "sudo -u rojotoro vim / etc / passwd" เป็นตัวอย่าง แต่จริง ๆ แล้วฉันไม่ต้องการเปลี่ยนแปลงอะไรในไฟล์ sudoers ฉันคาดว่าอาจมีปัญหาเกี่ยวกับ selinux ที่เรามีและบังคับใช้ แต่จนถึงขณะนี้ฉันไม่จำเป็นต้องสัมผัสกับระบบนั้น
ฉันสามารถเห็นได้ว่าสคริปต์ mkdev หรือ mkfs อาจต้องมีการปรับ แต่ฉันไม่ได้วางแผนที่จะใช้ดังนั้นฉันไม่ได้ดูพวกเขาด้วยการตรวจสอบที่พวกเขาสมควรได้รับ
ถ้ามันง่ายที่จะเปลี่ยนโดยไม่มีผลร้ายต่อระบบที่เปิดใช้ selinux ทำไมความต่อเนื่องของความหวาดกลัวทั้งหมดจึงเกิดขึ้น?
rpm -Va
พูดในระบบที่เปลี่ยนชื่อบัญชีรูทได้หรือไม่? ตามคู่มือ RPM สูงสุด "ตัวระบุผู้ใช้และกลุ่มจะต้องไม่ใช่ตัวเลข" ดังนั้น RPM ใด ๆ ที่ระบุไฟล์จะต้องเป็นเจ้าของโดย root จะไม่สามารถทำได้ในเวลาติดตั้ง เพียงแค่สงสัยว่าระบบของคุณจะจัดการกับสิ่งนั้นอย่างไร
ข้อเสนอแนะ: อย่าทำอย่างนั้น
เครื่องมือบางอย่างพยายามคุยกับรูทผ่าน uid คุณไม่ควรมีปัญหา เครื่องมือบางอย่างสมมติว่าบัญชีรูทของคุณเรียกว่ารูทและจะแตก นอกจากว่าคุณพร้อมที่จะคอมไพล์ครึ่งระบบของคุณ "เพื่อความสนุก" อย่าเพิ่งลอง
ในใจของฉันสิ่งที่ง่ายที่สุดที่จะทำคือการสร้างผู้ใช้ใหม่ (นามแฝง) ด้วย UID 0 และ/root
เป็นบ้าน
ทำไมคุณไม่เปลี่ยนเชลล์เริ่มต้นของรูทไปเป็น/bin/false
หรือ/sbin/nologin
(ไม่มีใครสามารถเข้าสู่ระบบได้ แต่ระบบยังคงใช้งานได้) และล็อกอินเป็นชื่อแทนใหม่ที่สร้างขึ้น?
razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root
หากคุณเปลี่ยนเชลล์ของรูทเป็น nologin sudo, mail หรือ ftw จะไม่เสียหาย
/bin/false
หรือ/sbin/nologin
ไม่สามารถเริ่มบริการใด ๆ ได้ ดังนั้นทุกคนจะต้องได้รับการกำหนดรูปแบบใหม่ นอกจากนี้จุดประสงค์ทั้งหมดก็เพื่อปรับปรุงความปลอดภัยโดยเพิ่มบัญชีที่สองที่มีสิทธิ์ "รูท" ช่วยเพิ่มความปลอดภัยได้ยาก
Linux ไม่ใช่ Windows และปัจจุบันไม่สามารถเปลี่ยนชื่อรูทได้อย่างง่ายดายโดยไม่ต้องสร้างปัญหาในอนาคต
การปิดใช้งานการล็อกอินจากระยะไกลและแบบโลคัลในขณะที่รูทเป็นวิธีที่ปลอดภัยกว่าเพราะจะเป็นการปิดใช้งานรูทบัญชี! UBUNTU ทำสิ่งนี้เป็นหลักและบังคับให้ sudo แทนการเข้าถึงรูท
เป็นหลักไม่มีใครสามารถใช้บัญชีรูทเพื่อโจมตีระบบของคุณได้เนื่องจากไม่สามารถใช้เพื่อเข้าสู่ระบบได้อีกต่อไป!
มันจะดีถ้าวิธีมาตรฐานถูกสร้างขึ้นเพื่อแก้ไขทั้งชื่อบัญชีรูทรวมถึงการสร้าง UID แบบสุ่มเมื่อทำการติดตั้งและหากเป็นไปได้ในทุกครั้งที่มีการเริ่มเย็นเพื่อป้องกันการกำหนดเป้าหมาย UID แต่ไม่มีอยู่ในปัจจุบัน
การปรับ / etc / passwd แก้ไข root: x: 0: 0: root: / root: / bin / nologin
สร้างบัญชีผู้ดูแลระบบทางเลือกเดียวสำหรับเหตุฉุกเฉินใช้เท่านั้น! fallbackadmin: x: 0: 0: ราก: ราก /: / bin / ทุบตี
ใช้ sudo สำหรับผู้ดูแลระบบทั้งหมดเพื่อให้การตรวจสอบบันทึกการเปลี่ยนแปลงสามารถดำเนินการได้อย่างถูกต้องเพื่อติดตามผู้ที่ทำการเปลี่ยนแปลงเพื่อความรับผิดชอบ!
สิ่งนี้ใช้ข้อกำหนด PCI US Gov เพื่อปิดใช้งานบัญชีผู้ดูแลระบบ / ผู้เยี่ยมชมเริ่มต้นและสร้างบัญชีผู้ดูแลระบบการใช้งานฉุกเฉินเพียงครั้งเดียว
วิธีหนึ่งในการเก็บถาวรบันทึกสำหรับการตรวจสอบคือการรวบรวมประวัติเทอร์มินัลจากผู้ใช้ทั้งหมดที่มีการเข้าถึงบัญชี sudo หากไม่ได้ใช้งาน AAA แบบรวมศูนย์
โซลูชันในการใช้งานบัญชีผู้ดูแลระบบเท่านั้นคือการสร้างบัญชีผู้ใช้หนึ่งบัญชีเท่านั้นและหนึ่งบัญชีที่เปิดใช้งาน sudo แล้วบังคับให้ผู้ใช้ su บัญชีที่เปิดใช้งาน sudo ของพวกเขาสำหรับการเข้าถึงการบริหาร
คุณสามารถใช้การรับรองความถูกต้องของสมาร์ทการ์ดถ้าคุณต้องการความปลอดภัยที่ดีขึ้นมีวิธีแก้ปัญหาสำหรับ GNU / Linux ที่เปรียบเทียบกับ US CAC Access Card CAC โซลูชั่นสำหรับการตรวจสอบสองปัจจัย