Я знаю, что одним из первых шагов, которые вы делаете для защиты сервера, является запрет удаленного входа в систему с правами root.
Пароли довольно слабые; что люди думают о разрешении входа в систему только root с помощью ключей ssh или других методов без пароля.
Какие методы самые лучшие? Лучше просто не рисковать? Использует ssh-соединение с дополнительной учетной записью и использует su - действительно добавление безопасности?
Как люди на serverfault.com получают доступ к root на удаленном сервере?
По большей части фактическое отключение удаленного входа в систему с правами root мало что дает. Это незначительно помогает обеспечить соблюдение политики, согласно которой администраторы входят в систему через свои собственные учетные записи и su рутировать по мере необходимости (или использовать sudo возможно с sudosh ... в зависимости от вашей политики).
Создание чрезвычайно длинных и громоздких корневых паролей (эффективно, если вы еще не используете древний 12-битный солевой хэш DES + для своих паролей) примерно так же эффективно для обеспечения соблюдения такой политики.
Один сайт, с которым я знаком, имел систему, в которой уникальные пароли генерировались случайным образом для каждого хоста, сохранялись в базе данных и отправлялись в системы. От администраторов требовалось использовать ssh со своими обычными аккаунтами, и sudo для большинства операций. Тем не менее, корневой пароль был доступен для них через внутреннюю веб-службу на основе SSL (для чего дополнительно требовался их токен RSA SecurID и ПИН-код). Получение пароля root повлекло за собой ввод обоснования (обычно ссылка на номер билета Remedy (TM)) и доступ, где периодически проверяется. Одной из немногих приемлемых причин для прямого использования пароля root были те случаи, когда система была остановлена на fsck в процессе загрузки ... и sulogin требовал реального пароля root для запуска процессов проверки и восстановления файловой системы вручную. (Было некоторое обсуждение альтернативных методов для этого - которые относительно просты для Linux, но становятся намного сложнее, когда вы пытаетесь расширить свои процедуры, чтобы учесть многие устаревшие системы HP-UX, AIX и более старые системы SunOS и Solaris, которые все еще находились в производстве в той среде).
В некоторых случаях пароль root необходим - или, по крайней мере, это лучшая альтернатива. Как правило, ваша лучшая стратегия - сохранить его доступным, но при этом сделать его достаточно устойчивым к разного рода угрозам.
Другой известный мне сайт предлагает довольно элегантный подход к децентрализованному управлению счетами. У них есть пакеты user- * и sudo- * (думаю, RPM), которые устанавливаются в системы с использованием обычных процедур управления пакетами и инфраструктуры автоматизации. В их случае пакет sudo- * зависит от соответствующего пакета user- *. Это хорошо, потому что позволяет иметь кластеры машин с локализованными учетными записями (все учетные записи являются администраторами, разработчиками, сотрудниками службы поддержки или «безгласными» учетными записями) и устраняет зависимость от LDAP / NIS или других сетевых служб идентификации и аутентификации. (Это уменьшает взаимосвязь между системами, что делает их значительно более надежными).
Что мне нравится в этом подходе, так это то, что он дает гибкость. Любой с sudo доступ может выдать команду на добавление обычного пользователя или другого sudo учетная запись пользователя. Итак, если я работаю над заявкой, любой из людей, у которых уже есть доступ к системе, может легко предоставить мне доступ. Нет никаких задержек, пока заявка на добавление меня в некоторый список управления доступом в какой-то центральной базе данных проходит через какой-то централизованный процесс утверждения и, наконец, распространяет изменение обратно в рассматриваемую систему. Любой из авторизованных sudo-ers в системе могут предоставить мне доступ, а затем удалить меня. (Да, если бы я был злым, и они меня играли sudo Я мог злонамеренно изменить что-либо, чтобы сохранить доступ ... на самом деле есть некоторые вещи, которые я мог бы сделать так же, как обычный пользователь, чтобы сохранить доступ после такого удаления. Однако их беспокоит не это. Мой доступ по-прежнему ограничен относительно небольшим количеством систем в целом; поэтому влияние взломанной учетной записи все еще более ограничено, чем у большинства подобных схем, которые я видел.
Я предлагаю вам настроить систему так, чтобы root-доступ был ТОЛЬКО с консоли.
В противном случае, используя sudo с параметром пароля, разрешите выбранным пользователям доступ к командам priv'd. Кстати, поймите, что sudo может быть разработан для ограничения учетной записи пользователя определенными командами, если вы хотите. Судо, оставляет в системном журнале «отметку» о том, что его использовали. sudo лучше, чем su, потому что пароль root не раскрывается. Таким образом, вы можете изменить пароль root, и пользователь, использующий sudo, не станет мудрее.
Разрешенное использование sudo для доступа к командам priv'd должно сопровождаться принудительной периодической сменой пароля с частотой, зависящей от среды.
Если вы отключите удаленный root-доступ, вы не позволите удаленным злоумышленникам получить root-доступ напрямую - они должны взломать другую учетную запись, получить доступ к машине, а затем попытаться получить доступ к root. Это дополнительный шаг.
Обычно root отключен для удаленного доступа. SU работает хорошо. Если что-то действительно ломается, всегда есть прямой доступ к коробке, чтобы это исправить.
Если вы хотите быть строже - просто отключите root полностью, sudo для этого и существует. Опять же, при таком подходе вы все равно можете получить root-доступ, перейдя в однопользовательский режим - а-ля Ubuntu. Хотя, я считаю, что они использовали для этого пропатченный init, согласно их документам.
Кроме того, вы можете настроить режим ожидания, чтобы отключать пользователей в режиме ожидания, если их терминалы остаются открытыми, а ПК тоже открыты. Вы можете заставить всех пользователей использовать ключи, но управление ключами может быть затруднено.
Единый сквозной хост для ведения журнала в качестве системы типа «breakglass» также обеспечил дополнительный уровень защиты и контрольный журнал.
никогда не разрешать root
настроить систему, чтобы разрешить доступ только по ключам без паролей
затем настройте sudo для пользователей, которым разрешено вносить изменения через учетную запись root