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

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

Разъясниться: Путем "отключения корневой учетной записи путем удаления пароля" я имею в виду различные механизмы, которые заканчиваются с a! или * в поле пароля/etc/shadow, или подобный. Я не имею в виду, "изменяют корневой механизм входа в систему, таким образом, Вы не становитесь предложенными пароль".

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

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

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

Примечание: Я работаю в довольно небольшой компании (50 - что-то сотрудники), и мы двигаемся только с 2 частично занятыми администраторами (1 окно/1 Linux). Этот способ сделать вещи не мог бы быть лучшим, когда у Вас есть порядки величины больше пользователей. Я был бы лично все еще не использовать sudo. Существуют другие способы зарегистрировать корневое действие.

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

При отключении логинов корневой учетной записи непосредственно Вы наносите вред своей способности зафиксировать систему, когда существуют серьезные проблемы.

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

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

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

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

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

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

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

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

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

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

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