Ответы:
На всех моих серверах учетная запись root отключена ( sp_pwdpустановлена на *). Это требуется sudoдля всех корневого доступа. [1] Целью этого является аудит всех действий суперпользователя, чтобы люди могли видеть, что было сделано с системой.
Для более хардкорного варианта вы можете сделать sudoзапись в файл журнала (в отличие от syslog) и сделать этот файл доступным только для добавления ( chattrв Linux или chflagsBSD). Таким образом, никто не может редактировать аудит впоследствии.
[1] У меня также есть политика не запускать корневую оболочку или выполнять экранирование оболочки от корневого процесса. (Это нормально использовать sudo sh -c '...'для выполнения конвейеров или перенаправлений, хотя.)
Я настоятельно рекомендую не отключать пользователя root. Отключите или ограничьте входы в систему root (через securetty и через sshd_config и через PAM и через что у вас есть) Если ваша система это разрешает, ограничьте привилегии root или разделите роль root (аналогично тому, как это делает RSBAC ). Но, пожалуйста , сделайте Не отключайте учетную запись root, удалив пароль, иначе станет невозможно войти в систему через sulogin. suloginиспользуется всеми начальными сценариями, которые я знаю, в случае серьезных ошибок, о которых сообщает fsck - и это означает, что вы будете заблокированы из системы, если корневая файловая система будет повреждена.
Для пояснения: под «отключением учетной записи root путем удаления пароля» я подразумеваю различные механизмы, которые в конечном итоге заканчиваются на! или * в поле пароля / etc / shadow, или аналогичное. Я не имею в виду «изменить механизм входа в систему root, чтобы не запрашивать пароль».
suили sudoдоступность в вашей системе пользователей означает больше рисков для безопасности, которых вы можете избежать, если у вас есть только выделенные пользователи root. Это позиция, отстаиваемая авторами безопасного дистрибутива Owl (и среди них Solar Designer ) - unix.stackexchange.com/questions/8581/… пытается представить свою позицию со ссылками.
fastbootопцией, разблокировать учетную запись root и перезапустить, чтобы наконец запустить fsckвручную.
У меня включена учетная запись root на всех моих серверах. Все администраторы имеют своего собственного пользователя и должны войти через него. Оттуда они переключаются на root. (root ssh отключен)
Держите счет администратора низким. Только люди, которым действительно нужен root-доступ на этом сервере, имеют пароль.
Я не фанат sudo. Слишком просто просто сделать sudo bash для корневой оболочки. Я знаю, что это можно отключить, но зачем? Просто ограничьте пользователей, которые могут выполнять задачи администратора и общаться друг с другом. У нас есть политика, запрещающая открывать корневые терминалы без присмотра. Так что, войдите, su, сделайте работу, выйдите.
Примечание: я работаю в довольно небольшой компании (около 50 человек), и у нас есть только 2 администратора с частичной занятостью (1 windows / 1 linux). Такой способ работы может быть не лучшим, когда у вас на порядок больше пользователей. Лично я бы по-прежнему не использовал sudo. Есть и другие способы регистрации активности root.
Отключение пароля root является ложной «хорошей идеей». В тот день, когда он вам понадобится, он вам действительно понадобится. (в зависимости от вашей конфигурации вам может понадобиться войти в однопользовательский режим для примера)
Отключение удаленного входа в систему root может иметь значение, но только если вы можете войти в систему локально.
И да, sudo должен быть установлен на каждом из ваших серверов. Это полезно и легко настроить. Почему бы вам не использовать его?
Disabling root remote login might be relevant but only if you are able to log on locally.Это просто очевидно ложно. Вы можете войти удаленно с любой учетной записи; отключение root удаленного входа не ограничивает вас локальным доступом.
Я просто отключаю SSH-доступ для root и требую, чтобы пользователи (часто просто разработчики) использовали ssh-ключи. Просто слишком много атак по словарю, и изменение порта SSH для нас не вариант.
Таким образом, вам не нужно доверять чьей-либо способности написать хороший пароль. Оказавшись внутри только администраторы имеют права на sudo.
Я знаю, что эта ветка действительно старая, но в логике связанных статей есть некоторые серьезные недостатки, и я чувствую себя "rant'ie" - sudo допускает как белый, так и черный список. Не только черный, как указано в связанной статье. Это пропускает идею AAA (Аутентификация, Авторизация и Аудит) - su & sudo допускает как дифференцированную аутентификацию, так и отчетность.
Сценарий 1 Администратор случайно вводит в систему некоторый мошеннический код, вошедший в систему как root, у которого полный доступ к коду, и администратор может никогда не узнать, что произошло. По крайней мере, с помощью логинов с градуированной регистрацией (например, su / sudo) администратору будет предложено пройти аутентификацию, если мошеннический код пытается использовать повышенные права ... Если он не повышает права, он ограничивается правами пользователей, что должно привести к минимальному ущербу.
Сценарий 2: мошеннический администратор хочет получить информацию / внести изменения. Они подключаются к консоли (физический доступ к консоли, доступ к консоли HP iLo / аналогичный или vGuest), входят в систему как root и делают все, что пожелают. Если не существует именованной учетной записи / карты доступа, используемой для получения доступа к консоли, возможно, не так много следов аудита.
Вы должны требовать, чтобы все использовали sudo для каждой корневой команды в качестве политики. Нет никакой причины запускать «sudo bash» или тому подобное, это только для удобства, из-за невежества или для того, чтобы скрыть следы.
Если вы отключите входы в систему под учетной записью root напрямую, вы лишите вас возможности исправлять систему в случае серьезных проблем.
Если вы не можете убедить своих администраторов войти в систему как они сами и запустить sudo для каждой команды, запускаемой от имени пользователя root, и не вырваться из нее в оболочку, у вас есть серьезные проблемы, для которых не существует технического решения.
Авторы безопасного дистрибутива Owl (и Solar design) придерживаются противоположной, тщательно обоснованной точки зрения; см., например, ответ /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 для представление своих требований. Проблема аудита действий суперпользователя (кто и чем занимался) также рассматривается с их точки зрения (в основном, решение состоит в том, чтобы иметь нескольких корневых пользователей с разными именами).