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