Должны ли мы отключить пользователя root?

На всех моих серверах отключена учетная запись root (sp_pwdp установлен в *). Это необходимо sudo для всего корневого доступа. [1] Целью этого является аудит всех действий суперпользователя, чтобы люди могли видеть, что было сделано с системой.

Для более жесткого варианта вы можете сделать sudo записывать в файл журнала (в отличие от syslog) и сделайте файл доступным только для добавления (используя chattr в Linux или chflags на BSD). Таким образом, никто не сможет впоследствии редактировать аудит.

[1] У меня также есть политика не запускать корневую оболочку или выполнять экранирование оболочки из корневого процесса. (Можно использовать sudo sh -c '...' для выполнения конвейеров или перенаправлений.)

я решительно рекомендую не отключать пользователя root. Отключить или ограничить вход в систему root (через securetty и через sshd_config и через PAM и через то, что у вас есть) Если ваша система позволяет это, ограничьте привилегии root или разделите корневую роль (аналогично тому, как RSBAC делает это.) Но пожалуйста, пожалуйста, не отключайте учетную запись root, удалив пароль, иначе будет невозможно войти в систему через sulogin. sulogin используется всеми известными мне сценариями инициализации в случае серьезных ошибок, о которых сообщает fsck, а это означает, что вы будете заблокированы в системе, если корневая файловая система будет повреждена.

Чтобы уточнить: под «отключением учетной записи root путем удаления пароля» я имею в виду различные механизмы, которые приводят к появлению файла! или * в поле пароля / etc / shadow или аналогичный. Я не имею в виду «изменить механизм входа в систему с правами root, чтобы не запрашивать пароль».

У меня есть учетная запись root на всех моих серверах. У всех администраторов есть собственный пользователь, и они должны входить в систему через него. Оттуда они переключаются на root. (root ssh отключен)

Держите администраторов на низком уровне. Только люди, которым действительно нужен root-доступ на этом сервере, имеют пароль.

Я не фанат sudo. Слишком просто выполнить sudo bash для корневой оболочки. Я знаю, что это можно отключить, но зачем? Просто ограничьте количество пользователей, которые могут выполнять задачи администратора и разговаривать друг с другом. У нас есть политика, запрещающая открывать корневые терминалы без присмотра. Итак, войдите, su, сделайте работу, выйдите из системы.

Примечание: я работаю в довольно небольшой компании (около 50 сотрудников), и у нас всего 2 администратора, работающие неполный рабочий день (1 windows / 1 linux). Такой способ работы может оказаться не лучшим, когда у вас на порядки больше пользователей. Лично я бы все равно не стал использовать sudo. Есть и другие способы регистрации активности root.

Я просто отключаю доступ по SSH для root и требую, чтобы пользователи (часто это только разработчики) использовали ключи ssh. Слишком много словарных атак, и изменение порта SSH для нас не вариант.

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

Отключение пароля root - это ложная "хорошая идея". В тот день, когда вам это понадобится, вы будете действительно нужно это. (в соответствии с вашей конфигурацией вам может потребоваться, например, для входа в однопользовательский режим)

Отключение удаленного входа в систему root может иметь значение, но только в том случае, если вы можете войти в систему локально.

И да, sudo должен быть установлен на каждом из ваших серверов. Это полезно и легко настраивается. Почему бы вам не использовать его?

Я знаю, что эта ветка действительно устарела, но в логике связанных статей есть некоторые серьезные недостатки, и я чувствую себя "rant'ie" - sudo позволяет заносить в белый и черный список. Не просто черный, как указано в связанной статье - это пропускает идею AAA (аутентификация, авторизация и аудит) - su & sudo позволяют как градуированную аутентификацию, так и подотчетность.

Сценарий 1 Администратор случайно вводит в систему какой-то мошеннический код, вошел в систему как root, код имеет полный доступ, и администратор может никогда не узнать, что произошло. По крайней мере, с градуированными входами (например, su / sudo) администратору будет предложено пройти аутентификацию, если мошеннический код попытается использовать повышенные права ... Если он не повысит, то он ограничен правами пользователей, что должно привести к минимальному ущербу.

Сценарий 2 Администратор-мошенник хочет получить информацию / внести изменения. Они подключаются к консоли (доступ к физической консоли, HP iLo / аналогичный или доступ к консоли vGuest), входят в систему как root и делают все, что хотят. Если для получения доступа к консоли не используется именованная учетная запись / карта доступа, то, вероятно, не так много контрольного журнала.

1. Убедитесь, что они действительно такие, о которых говорят. Проблема не в краже личных данных, а в проверке личности.
2. Проверьте их авторизацию, дайте им только то, что им нужно в данный момент. Градуированная авторизация позволяет им повышать уровень, когда они в этом нуждаются.
3. Проверяйте все это, ведите записи, чтобы знать, кто, что делал, когда и где. Желательно, почему тоже

Вы должны потребовать от всех использовать sudo для каждой корневой команды в качестве политики. Нет причин запускать «sudo bash» или что-то подобное, это только для удобства, из-за незнания или для того, чтобы замести следы.

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

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

Авторы Owl secure distribuion (и Solar Designer) придерживаются противоположной, тщательно обоснованной точки зрения; см., например, ответ https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 для изложения своих требований. Проблема аудита действий суперпользователя (кто что делал) также решается с их точки зрения (в основном, решение состоит в том, чтобы иметь несколько пользователей root с разными именами).