Не то, чтобы это было очень хорошей идеей, но ради интереса. Согласно этому сообщению, все еще есть некоторые проблемы , даже после изменения записи в /etc/passwd, /etc/shadowи /etc/sudoers. Какие-либо предложения?
имя учетной записи "root"? каталог верхнего уровня "/"?
Акира
4
имя пользователя root
yxkb
1
тогда, пожалуйста, проясните свой вопрос ...
Акира
Спустя 7 лет мне интересно, если бы вы пошли дальше и какого рода BadStuff произошло из-за этого ... ^ _ ^
Mioriin
Ответы:
29
Теоретически, изменение его /etc/passwdи /etc/shadowвсе, что вам нужно, чтобы «переименовать» root. Проблема возникает из-за того, что практически все существующие части программного обеспечения Unix предполагают, что имя пользователя root существует и что это суперпользователь - псевдонимы почты, различные демоны, cron ...
Если вы действительно одержимы попыткой сделать это, find /etc -type f -exec grep -l root {} +следует начать с поиска списка всех конфигурационных файлов, которые вам, вероятно, придется изменить, - но, как вы уже сказали, это действительно плохая идея почти во всех мыслимых ситуациях.
РЕДАКТИРОВАТЬ Еще одна мысль - если вы еще не сделали (что вы должны иметь), убедитесь, что /etc/aliasesсодержит запись для rootи имя пользователя, который существует или адрес электронной почты, который оценивается правильно. Многие автоматизированные общесистемные задачи ( cronнапример) отправляют свои выходные данные по электронной почте root, что традиционно присваивается системному администратору (администраторам), отвечающему за операции этой системы.
Только имена пользователей, когда рассматриваемая группа не является их группой по умолчанию, но это хороший момент.
Шадур
3
это? я думал, что большинство приложений используют UID, а не имя. В идеале, ни одно приложение не должно принимать «root = UID 0»
yxkb
2
@yxkb: Вы правы, ни одно приложение не должно предполагать это. Но я бы очень хотел получить 1 $ за каждое приложение или скрипт, который это делает! :)
Брэм
1
Верно. Давайте вспомним все времена, когда мы все лично писали chown root …или схожи в сценарии оболочки.
Дероберт
24
Весь этот страх торгует, говоря: «Не делай этого!» смешно Однажды, да, это, вероятно, сломало много плохо написанных сценариев, но я подозреваю, что они уже не так распространены; по крайней мере, не в стандартных дистрибутивах.
Нам сказали переименовать корневую учетную запись на подмножестве серверов Linux. Итак, после попытки выяснить, как сделать это правильно, я вместо этого нашел много, много сообщений, говорящих «Не делай этого!» с большим количеством страшных предупреждений о «плохих вещах», происходящих, если вы решите это сделать. Но мне еще предстоит найти какие-либо конкретные примеры «плохих вещей», которые могут произойти.
Итак, позвольте мне вернуться и объяснить, где я нахожусь и как мы сюда попали. Мы создаем среду, совместимую с PCI, и один из инструментов, который помогает нам удовлетворить эти «требования», говорит нам, что нам нужно переименовать учетные записи root, администратора и гостя в другое. Для тех, кто не знаком с PCI, у вас есть возможность либо следовать рекомендациям, либо задокументировать, почему вы не можете или не хотите следовать этим рекомендациям, и какую стратегию смягчения вы должны использовать для обеспечения безопасности систем. Итак, я представляю, что большинство мест документируют, почему они не собираются переименовывать свои корневые учетные записи, однако наша группа решила, что, если мы сможем переименовать учетные записи администраторов Windows без проблем, они собираются переименовать и корневые учетные записи linux.
Я хорошо разбираюсь в аргументах "безопасность через мрак"; Я знаю, что просто изменение имени учетной записи root на самом деле не сильно повышает безопасность, root должен быть отключен в SSH и т. Д. Я знаю, что это не главное, мне не интересно больше слышать. Меня также не интересует больше предупреждений "небо упадет". Я ищу заявления вроде этого: «> эта плохая вещь <произойдет с> этим стандартным пакетом <(если вы не сделаете это <)».
До сих пор у меня есть системы 3 CentOS (RHEL), у которых, очевидно, нет проблем с переименованием учетной записи root. Вот что я сделал: я изменил имя учетной записи в / etc / passwd, / etc / shadow, / etc / group и / etc / gshadow. Затем нашел имя root в / etc / и изменил файл псевдонимов postfix, чтобы root был псевдонимом для нашего нового имени учетной записи, назовите его rojotoro. (Нечто подобное должно быть сделано для других систем электронной почты). Я также обнаружил, что мне нужно было изменить некоторые конфигурации для logrotate при описании того, кто должен владеть файлами, которые он будет создавать автоматически. И это все, что я изменил до сих пор.
Я просмотрел много сценариев init.d, но ничего не изменил, и все, кажется, запускается просто отлично при загрузке. Я должен указать новую учетную запись при использовании sudo: "sudo -u rojotoro vim / etc / passwd" в качестве примера, но на самом деле мне не нужно ничего менять в файле sudoers. Я ожидал, может быть, некоторые проблемы с selinux, которые у нас есть и которые применяются, но пока мне не нужно было касаться этой системы.
Я также вижу, что скрипты mkdev или mkfs, возможно, нужно будет скорректировать, но я не планирую их использовать, поэтому я не смотрел на них с тщательностью, которой они заслуживают.
Если это действительно легко изменить без каких-либо негативных последствий для системы с поддержкой selinux, то почему продолжение всего распространения страха?
Это было бы лучше, если бы вы вырезали несколько абзацев, посвященных тому, чтобы называть людей невежественными; это на самом деле не нужно
Михаил Мрозек
3
Вы правы, но мне потребовалось некоторое время, чтобы признать это. Его цель состояла в том, чтобы помочь убедиться, что у других был реальный опыт изменения имени пользователя root, прежде чем просто выдумать идею, но это действительно не было нужно.
5mi11er
3
Поскольку вы работаете в CentOS: можете ли вы проверить, что rpm -Vaнаписано в системах, где корневая учетная запись переименована? Согласно руководству по максимальному количеству оборотов в минуту «Идентификаторы пользователей и групп должны быть не числовыми», поэтому любой RPM, который указывает файлы, должен принадлежать пользователю root, не сможет сделать это во время установки. Просто интересно, как ваши системы справятся с этим.
Брэм
1
Где в PCI сказано, что вам нужно переименовать ROOT?
Кидбурла
@MichaelMrozek, обычно я согласился бы, что ответ не должен иметь предысторию, подобную этой. Тем не менее, поиск в Интернете по этой теме обременен множеством точных предупреждений, о которых ОП тратит три абзаца, и я думаю, что в этом случае это необходимо. Это помогло сформулировать его параграф «Как» и облегчило мне понимание, зная, что контекст его решения аналогичен моему собственному.
user1717828
7
предложение: не делай этого.
Некоторые инструменты пытаются общаться с пользователем root через uid, там у вас не должно быть проблем. некоторые инструменты предполагают, что ваша учетная запись root называется root, и она сломается. если вы не готовы перекомпилировать половину своей системы «для удовольствия», просто не пытайтесь.
Я не думаю, что кто-то оспаривает, что переименование root - в лучшем случае ужасно плохая идея.
Шадур
Кухкац, это просто предосторожность. если кто-то это делает, это может помочь вернуть его, если вы знаете, что происходит, когда кто-то меняет root
yxkb
В статье вы получили эту идею из заметок о том, что это нарушает вход в систему как root, как при использовании sudo. поэтому, единственный способ вернуть его - это чистая переустановка. следовательно, вам не нужно пробовать это, это очевидно, как восстановить это. также имейте под рукой LART, на всякий случай, если ваш пользователь все равно попытается.
Кухтац
На счет перекомпиляции ... gogo gentoo? Один патч в каждом Ebuild, чтобы управлять ими всеми?
Bananguin
4
На мой взгляд, проще всего создать нового пользователя (псевдоним) с UID 0 и в /rootкачестве home.
Почему бы вам не переключить стандартную оболочку вашего 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
Если вы измените оболочку root на nologin, sudo, mail или ftw не будут повреждены.
По общему признанию, @ 5mi11er указал, что я не пробовал это, но если установлена оболочка root /bin/falseили /sbin/nologinон не сможет запускать какие-либо службы. Таким образом, все они должны быть перенастроены. Кроме того, вся цель состояла в том, чтобы повысить безопасность, добавив вторую учетную запись с правами «root», что вряд ли повысит безопасность.
Брэм
Я думаю, что это лучшее решение, оно позволяет искать имя в uid для root и отключает вход в систему для root. Вы можете поменять местами порядок строк так, чтобы root2 появился перед root, тогда whoami сообщит о root2, т.е. Поиск имени останавливает поиск при совпадении первой записи uid. Я не согласен с тем, что службы не смогут запускаться, так как ядро запускает процесс и дает ему uid 0 для настройки системы (init, upstart, ...)
X Tian
2
Linux не является Windows, и в настоящее время root не может быть легко переименован без создания неизвестных проблем в будущем.
Отключение удаленного и даже локального входа в систему как root - более безопасный подход, поскольку он активно отключает учетную запись root! UBUNTU, по сути, делает это и заставляет sudo вместо корневого доступа.
По сути, никто не может использовать учетную запись root для атаки на вашу систему, так как ее больше нельзя использовать для входа в систему!
Было бы неплохо, если бы был создан стандартный способ, позволяющий легко изменять как имя учетной записи root, так и случайным образом генерировать его UID при установке и, если возможно, при каждом холодном запуске, чтобы предотвратить таргетинг UID, но его в настоящее время не существует.
Настройка / etc / passwd Изменить root: x: 0: 0: root: / root: / bin / nologin
Создайте единственную резервную учетную запись администратора для ТОЛЬКО АВАРИЙНОГО ИСПОЛЬЗОВАНИЯ! fallbackadmin: х: 0: 0: корень: / корень: / Bin / Баш
Внедрите sudo для всех администраторов, чтобы можно было осуществлять аудит журнала изменений, чтобы точно отслеживать, кто вносит изменения для подотчетности!
Это реализует требования PCI US Gov для отключения стандартных учетных записей администратора / гостя и создания единой учетной записи администратора для использования в экстренных случаях.
Один из способов архивирования журналов для аудита - это сбор истории всех пользователей, имеющих доступ к учетной записи sudo, если централизованное AAA не реализовано.
Решение для реализации учетных записей только для администратора состоит в том, чтобы создать одну учетную запись только для пользователя и одну учетную запись с поддержкой sudo, а затем принудительно заставить пользователя использовать su для своей учетной записи с поддержкой sudo для административного доступа.
Вы также можете внедрить аутентификацию с помощью смарт-карты, если вы хотите повысить безопасность, для GNU / Linux доступны решения, которые сравниваются с решениями CAC для карт общего доступа США для двухфакторной аутентификации.
Ответы:
Теоретически, изменение его
/etc/passwd
и/etc/shadow
все, что вам нужно, чтобы «переименовать» root. Проблема возникает из-за того, что практически все существующие части программного обеспечения Unix предполагают, что имя пользователя root существует и что это суперпользователь - псевдонимы почты, различные демоны, cron ...Если вы действительно одержимы попыткой сделать это,
find /etc -type f -exec grep -l root {} +
следует начать с поиска списка всех конфигурационных файлов, которые вам, вероятно, придется изменить, - но, как вы уже сказали, это действительно плохая идея почти во всех мыслимых ситуациях.РЕДАКТИРОВАТЬ Еще одна мысль - если вы еще не сделали (что вы должны иметь), убедитесь, что
/etc/aliases
содержит запись дляroot
и имя пользователя, который существует или адрес электронной почты, который оценивается правильно. Многие автоматизированные общесистемные задачи (cron
например) отправляют свои выходные данные по электронной почтеroot
, что традиционно присваивается системному администратору (администраторам), отвечающему за операции этой системы.источник
chown root …
или схожи в сценарии оболочки.Весь этот страх торгует, говоря: «Не делай этого!» смешно Однажды, да, это, вероятно, сломало много плохо написанных сценариев, но я подозреваю, что они уже не так распространены; по крайней мере, не в стандартных дистрибутивах.
Нам сказали переименовать корневую учетную запись на подмножестве серверов Linux. Итак, после попытки выяснить, как сделать это правильно, я вместо этого нашел много, много сообщений, говорящих «Не делай этого!» с большим количеством страшных предупреждений о «плохих вещах», происходящих, если вы решите это сделать. Но мне еще предстоит найти какие-либо конкретные примеры «плохих вещей», которые могут произойти.
Итак, позвольте мне вернуться и объяснить, где я нахожусь и как мы сюда попали. Мы создаем среду, совместимую с PCI, и один из инструментов, который помогает нам удовлетворить эти «требования», говорит нам, что нам нужно переименовать учетные записи root, администратора и гостя в другое. Для тех, кто не знаком с PCI, у вас есть возможность либо следовать рекомендациям, либо задокументировать, почему вы не можете или не хотите следовать этим рекомендациям, и какую стратегию смягчения вы должны использовать для обеспечения безопасности систем. Итак, я представляю, что большинство мест документируют, почему они не собираются переименовывать свои корневые учетные записи, однако наша группа решила, что, если мы сможем переименовать учетные записи администраторов Windows без проблем, они собираются переименовать и корневые учетные записи linux.
Я хорошо разбираюсь в аргументах "безопасность через мрак"; Я знаю, что просто изменение имени учетной записи root на самом деле не сильно повышает безопасность, root должен быть отключен в SSH и т. Д. Я знаю, что это не главное, мне не интересно больше слышать. Меня также не интересует больше предупреждений "небо упадет". Я ищу заявления вроде этого: «> эта плохая вещь <произойдет с> этим стандартным пакетом <(если вы не сделаете это <)».
До сих пор у меня есть системы 3 CentOS (RHEL), у которых, очевидно, нет проблем с переименованием учетной записи root. Вот что я сделал: я изменил имя учетной записи в / etc / passwd, / etc / shadow, / etc / group и / etc / gshadow. Затем нашел имя root в / etc / и изменил файл псевдонимов postfix, чтобы root был псевдонимом для нашего нового имени учетной записи, назовите его rojotoro. (Нечто подобное должно быть сделано для других систем электронной почты). Я также обнаружил, что мне нужно было изменить некоторые конфигурации для logrotate при описании того, кто должен владеть файлами, которые он будет создавать автоматически. И это все, что я изменил до сих пор.
Я просмотрел много сценариев init.d, но ничего не изменил, и все, кажется, запускается просто отлично при загрузке. Я должен указать новую учетную запись при использовании sudo: "sudo -u rojotoro vim / etc / passwd" в качестве примера, но на самом деле мне не нужно ничего менять в файле sudoers. Я ожидал, может быть, некоторые проблемы с selinux, которые у нас есть и которые применяются, но пока мне не нужно было касаться этой системы.
Я также вижу, что скрипты mkdev или mkfs, возможно, нужно будет скорректировать, но я не планирую их использовать, поэтому я не смотрел на них с тщательностью, которой они заслуживают.
Если это действительно легко изменить без каких-либо негативных последствий для системы с поддержкой selinux, то почему продолжение всего распространения страха?
источник
rpm -Va
написано в системах, где корневая учетная запись переименована? Согласно руководству по максимальному количеству оборотов в минуту «Идентификаторы пользователей и групп должны быть не числовыми», поэтому любой RPM, который указывает файлы, должен принадлежать пользователю root, не сможет сделать это во время установки. Просто интересно, как ваши системы справятся с этим.предложение: не делай этого.
Некоторые инструменты пытаются общаться с пользователем root через uid, там у вас не должно быть проблем. некоторые инструменты предполагают, что ваша учетная запись root называется root, и она сломается. если вы не готовы перекомпилировать половину своей системы «для удовольствия», просто не пытайтесь.
источник
На мой взгляд, проще всего создать нового пользователя (псевдоним) с UID 0 и в
/root
качестве home.Почему бы вам не переключить стандартную оболочку вашего root на
/bin/false
или/sbin/nologin
(чтобы никто не мог войти в нее, но система все еще использует ее) и войти в систему с созданным новым псевдонимом?Если вы измените оболочку root на nologin, sudo, mail или ftw не будут повреждены.
источник
/bin/false
или/sbin/nologin
он не сможет запускать какие-либо службы. Таким образом, все они должны быть перенастроены. Кроме того, вся цель состояла в том, чтобы повысить безопасность, добавив вторую учетную запись с правами «root», что вряд ли повысит безопасность.Linux не является Windows, и в настоящее время root не может быть легко переименован без создания неизвестных проблем в будущем.
Отключение удаленного и даже локального входа в систему как root - более безопасный подход, поскольку он активно отключает учетную запись root! UBUNTU, по сути, делает это и заставляет sudo вместо корневого доступа.
По сути, никто не может использовать учетную запись root для атаки на вашу систему, так как ее больше нельзя использовать для входа в систему!
Было бы неплохо, если бы был создан стандартный способ, позволяющий легко изменять как имя учетной записи root, так и случайным образом генерировать его UID при установке и, если возможно, при каждом холодном запуске, чтобы предотвратить таргетинг UID, но его в настоящее время не существует.
Настройка / etc / passwd Изменить root: x: 0: 0: root: / root: / bin / nologin
Создайте единственную резервную учетную запись администратора для ТОЛЬКО АВАРИЙНОГО ИСПОЛЬЗОВАНИЯ! fallbackadmin: х: 0: 0: корень: / корень: / Bin / Баш
Внедрите sudo для всех администраторов, чтобы можно было осуществлять аудит журнала изменений, чтобы точно отслеживать, кто вносит изменения для подотчетности!
Это реализует требования PCI US Gov для отключения стандартных учетных записей администратора / гостя и создания единой учетной записи администратора для использования в экстренных случаях.
Один из способов архивирования журналов для аудита - это сбор истории всех пользователей, имеющих доступ к учетной записи sudo, если централизованное AAA не реализовано.
Решение для реализации учетных записей только для администратора состоит в том, чтобы создать одну учетную запись только для пользователя и одну учетную запись с поддержкой sudo, а затем принудительно заставить пользователя использовать su для своей учетной записи с поддержкой sudo для административного доступа.
Вы также можете внедрить аутентификацию с помощью смарт-карты, если вы хотите повысить безопасность, для GNU / Linux доступны решения, которые сравниваются с решениями CAC для карт общего доступа США для двухфакторной аутентификации.
источник