Как Вы переименовываете корень?

Теоретически, изменение его в /etc/passwd и /etc/shadow было бы все, что необходимо 'переименовать' корень. Проблема происходит, потому что в значительной степени каждая часть существующего программного обеспечения Unix предполагает, что имя пользователя 'корень' существует и что это - суперпользователь - почтовые псевдонимы, различные демоны, крон...

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

ОТРЕДАКТИРУЙТЕ Другую мысль - если Вы уже не имеете (который Вы должны иметь), удостоверьтесь это /etc/aliases содержит запись для root и имя пользователя, которое существует или адрес электронной почты, который оценивает правильно. Много автоматизированных задач в масштабе всей системы (cron например), отправляют их вывод по электронной почте в 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, почта или ftw не будут повреждены.

Все это нагнетание страха, говоря "Не делает этого!" смешно. Когда-то, да, это, вероятно, повреждало много плохо записанных сценариев, но я подозреваю, что это не так распространено больше; по крайней мере, не в стандартных дистрибутивах.

Нам сказали переименовать корневую учетную запись на подмножестве серверов Linux. Так, после попытки исследовать то, как пойти о выполнении этого правильно, меня, вместо этого нашло многих, много высказываний сообщений "Не делают этого!" с большим количеством страшных предупреждений "плохого материала" случай, если Вы принимаете решение сделать это. Но, я должен все же найти любого с конкретными примерами "плохого материала", который мог произойти.

Так, позвольте мне создать резервную копию и объяснить, где я, и как мы добрались здесь. Мы создаем PCI совместимая среда, и один из инструментов, который помогает нам отвечать тем "требованиям", говорит нам, что мы должны переименовать корень и учетные записи администратора и гостя к чему-то еще. Для необразованных о PCI, у Вас есть опция или после инструкций или после документирования, почему Вы или не можете или принимать решение не следовать той инструкции, и какое смягчение стратегии необходимо бережно хранить системы. Так, я воображаю большую часть документа мест, почему они не собираются переименовывать свои корневые учетные записи, однако, наша группа решила, что, если мы можем переименовать учетные записи администратора окон без проблемы, собирались переименовать корневые учетные записи Linux также.

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

До сих пор у меня есть 3 CentOS (RHEL) системы, которые, по-видимому, не имеют никаких проблем с переименованием корневой учетной записи. Вот то, что я сделал: Я изменил имя учетной записи в/etc/passwd,/etc/shadow,/etc/group, и/etc/gshadow. Затем захваченный для имени базируются в/etc/и измененный постфиксный файл псевдонимов так, чтобы корень был псевдонимом к нашему новому имени учетной записи, назовите это rojotoro. (Что-то подобное должно быть сделано для других почтовых систем). Я также нашел, что должен был изменить некоторые конфигурации для logrotate при описании, кто должен владеть файлами, которые он создал бы автоматически. И это было всем, что я изменил к настоящему времени.

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

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

Если это действительно, это легкое измениться без вредных воздействий на selinux включило систему, почему продолжение всего нагнетания страха?

Linux - это не Windows, и в настоящее время невозможно легко переименовать root, не создавая неизвестных проблем в будущем.

Отключение удаленного и даже локального входа в систему от имени root является более безопасным подходом, так как он активно отключает учетную запись root! UBUNTU, по сути, делает это и заставляет sudo вместо root доступа.

По сути, никто не может использовать учетную запись root для атаки на вашу систему, так как она больше не может использоваться для входа в систему!

Было бы неплохо, если бы был создан стандартный способ легко изменять имя учетной записи root, а также случайно генерировать ее UID при установке и, если это возможно, при каждом холодном запуске, чтобы предотвратить UID-таргетинг, но который в настоящее время не существует.

Настройка /etc/passwd Изменить root:x:0:0:root:/root:/bin/nologin

Создайте единственную учетную запись администратора для аварийного использования ТОЛЬКО! fallbackadmin:x:0:0:root:/root:/bin/bash

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

Это реализует требования PCI US Gov по отключению стандартных администраторских/гостевых учетных записей и созданию единой учетной записи администратора аварийного использования.

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

Решение по внедрению учетных записей только для администраторов заключается в создании одной учетной записи только для пользователей и одной учетной записи с доступом только для администраторов, а затем в принудительном порядке заставить пользователя обратиться в su к своей учетной записи с доступом для администраторов.

Вы также можете внедрить аутентификацию с помощью смарт-карт, если вам нужна лучшая безопасность. Для GNU/Linux доступны решения, которые сравнимы с US Common Access Card CAC Solutions для двухфакторной аутентификации.