Не то, чтобы это было очень хорошей идеей, но ради интереса. Согласно этому сообщению, все еще есть некоторые проблемы , даже после изменения записи в /etc/passwd
, /etc/shadow
и /etc/sudoers
. Какие-либо предложения?
Не то, чтобы это было очень хорошей идеей, но ради интереса. Согласно этому сообщению, все еще есть некоторые проблемы , даже после изменения записи в /etc/passwd
, /etc/shadow
и /etc/sudoers
. Какие-либо предложения?
Ответы:
Теоретически, изменение его /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
(чтобы никто не мог войти в нее, но система все еще использует ее) и войти в систему с созданным новым псевдонимом?
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 не будут повреждены.
/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 для карт общего доступа США для двухфакторной аутентификации.