Як перейменувати корінь?

Не те, що це дуже гарна ідея змінити це, але заради розваги. Згідно цього повідомленням, все ще є деякі проблеми , навіть після зміни запису в /etc/passwd, /etc/shadowі /etc/sudoers. Будь-які пропозиції?

Теоретично, змінити його в /etc/passwdі /etc/shadowбуде все, що вам потрібно, щоб "перейменувати" корінь. Проблема виникає через те, що майже кожен фрагмент програмного забезпечення Unix припускає, що "root" імені користувача існує і що це суперпользователь - псевдоніми пошти, різні демони, крон ...

Якщо ви насправді пекла, спробували це спробувати, find /etc -type f -exec grep -l root {} +слід добре почати з пошуку списку кожного конфігураційного файлу, який вам, мабуть, потрібно буде змінити - але, як ви вже говорили, це справді погана ідея майже в кожній можливій ситуації.

РЕДАКТИРУЙТЕ Ще одна думка - якщо ви ще цього не зробили (що у вас повинно бути), переконайтеся, що вона /etc/aliasesмістить запис rootі ім’я користувача, яке існує, або адресу електронної пошти, яка правильно оцінює. Багато автоматизованих загальносистемних завдань ( cronнаприклад) надсилають свої результати електронною поштою root, що, як правило, надається системному адміністратору, відповідальному за діяльність цієї системи.

Весь цей страх надихався, кажучи: "Не роби цього!" смішно. Свого часу, так, це, ймовірно, зламало багато погано написаних сценаріїв, але я підозрюю, що вони вже не такі поширені; принаймні, не в стандартних дистрибутивах.

Нам сказали перейменувати кореневий обліковий запис на підмножині серверів Linux. Отож, намагаючись дослідити, як правильно робити це, я натомість знайшов багато-багато постів, які говорили "Не робіть цього!" з безліччю гострих попереджень про "погані речі", що трапляються, якщо ви вирішите це зробити. Але я ще не міг знайти конкретних прикладів "поганих речей", які можуть статися.

Отож, дозвольте створити резервну копію і пояснити, де я і як ми сюди потрапили. Ми створюємо середовище, сумісне з PCI, і один із інструментів, який допомагає нам відповідати цим "вимогам", говорить про те, що нам потрібно перейменовувати кореневі та облікові записи адміністраторів та гостей на щось інше. Для тих, хто не знає, що стосується PCI, у вас є можливість або слідувати вказівкам, або документувати, чому ви не можете або не вирішите не слідувати цим керівництву, і яку стратегію пом'якшення потрібно тримати в безпеці системи. Отже, я уявляю, що більшість місць документують, чому вони не збираються перейменовувати свої кореневі акаунти, однак наша група вирішила, що, якщо ми можемо без проблем перейменувати акаунти адміністратора Windows, також будемо перейменовувати кореневі акаунти linux.

Я добре розбираюся в аргументах "безпека через незрозумілість"; Я знаю, що лише зміна імені кореневого акаунта насправді не покращує безпеку на багато, корінь повинен бути відключений у SSH тощо. Мені також не цікаво більше попереджень "небо впаде". Я шукаю такі твердження: "> ця погана річ <станеться з> цим стандартним пакетом <(якщо ви не> зробите це <)".

Поки що у мене є 3 системи CentOS (RHEL), які, мабуть, не мають проблем з перейменуванням кореневого акаунта. Ось що я зробив: я змінив ім’я облікового запису в / etc / passwd, / etc / shadow, / etc / group та / etc / gshadow. Потім перехопили корінь імені в / etc / і змінили файл псевдонімів постфікса так, щоб корінь був псевдонімом нашої нової назви облікового запису, називайте його rojotoro. (Щось подібне слід зробити для інших систем електронної пошти). Я також виявив, що мені потрібно змінити деякі конфігурації для логротету, описуючи, хто повинен володіти файлами, які він створював би автоматично. І це було все, що я змінив досі.

Я переглянув багато сценаріїв init.d, але нічого не змінив, і, здається, все починається чудово при завантаженні. Я повинен вказати новий обліковий запис при використанні sudo: "sudo -u rojotoro vim / etc / passwd" як приклад, але мені насправді нічого не потрібно змінювати у файлі sudoers. Я очікував, що, можливо, деякі проблеми із selinux, які ми маємо та застосовуємо, але поки що мені не потрібно було торкатися цієї системи.

Я також бачу, що сценарії mkdev або mkfs, можливо, потрібно буде коригувати, але я не планую їх використовувати, тому я не розглядав їх із уважною увагою, яку вони заслуговують.

Якщо насправді це легко змінити без жодних негативних наслідків для системи з підтримкою selinux, навіщо продовжувати весь страх?

пропозиція: не робіть цього.

Деякі інструменти намагаються поговорити з root через uid, там у вас не повинно виникнути проблем. деякі інструменти припускають, що ваш кореневий обліковий запис називається root, і він порушиться. якщо ви не готові перекомпілювати половину системи "для розваги", просто не намагайтеся.

На мій погляд, найпростіше зробити це створити нового користувача (псевдонім), з UID 0 і /rootяк домашній.

Чому б вам не переключити оболонку за замовчуванням вашого 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

Якщо змінити оболонку кореня на нологін, судо, пошта або ftw не будуть пошкоджені.

Linux не є Windows, і root зараз не можна легко перейменувати без створення невідомих майбутніх проблем.

Відключення віддаленого та навіть локального входу як root - це більш безпечний підхід, оскільки він активно вимикає корінь акаунта! UBUNTU по суті робить це і змушує sudo замість кореневого доступу.

По суті, ніхто не може використовувати кореневий рахунок для атаки на вашу систему, оскільки він більше не може використовуватися для входу в систему!

Було б добре, якби було створено стандартний спосіб легкої модифікації як імені кореневого облікового запису, так і випадкового генерування його UID після встановлення, і якщо це можливо при кожному холодному запуску, щоб запобігти націлюванню на UID, але цього в даний час не існує.

Налаштування / etc / passwd Змінення кореня: x: 0: 0: root: / root: / bin / nologin

Створіть єдиний резервний обліковий запис адміністратора для ВИКОРИСТАННЯ АВАРІЙНОГО ВИКОРИСТАННЯ! dropbackadmin: x: 0: 0: root: / root: / bin / bash

Запровадьте sudo для всіх адміністраторів, щоб аудит журналу змін міг бути реалізований, щоб точно відслідковувати, хто вносить зміни для підзвітності!

Це реалізує вимоги PCI US Gov, щоб вимкнути облікові записи адміністратора / гостя за замовчуванням та створити єдиний обліковий запис адміністратора.

Один із способів архівувати журнали для аудиту - це збирати історію терміналів від усіх користувачів, які мають доступ до акаунта sudo, якщо централізований AAA не реалізований.

Рішення для впровадження облікових записів лише для адміністраторів - створити один обліковий запис лише для користувача та один обліковий запис із включеною sudo, а потім змусити користувача вступити на адміністративний доступ до свого облікового запису sudo.

Ви можете також реалізувати автентифікацію смарт-карт, якщо хочете покращити безпеку. Для GNU / Linux доступні рішення, які порівняно з рішеннями CAC загального доступу до карт CAC для двофакторної автентифікації.