Я знаю, что первое, что вы делаете для защиты сервера, это запрещение удаленного входа в систему 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
источник