Какой самый безопасный способ получить права root: sudo, su или login?

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

В Ubuntu по умолчанию вы можете использовать sudo только по соображениям безопасности. Однако я не уверен, что это безопаснее, чем просто использовать логин на консоли в текстовом режиме. Есть слишком много вещей, которые могут пойти не так, если злоумышленник может выполнить код как мой обычный пользователь. Например, добавление псевдонимов, добавление материала в мой PATH, настройка клавиатурных шпионов LD_PRELOAD и X11 - это лишь некоторые из них. Единственное преимущество, которое я вижу, это тайм-аут, поэтому я никогда не забываю выйти из системы.

У меня такие же сомнения в отношении su, но у него даже нет ограничения по времени. Некоторые операции (особенно перенаправление ввода-вывода) более удобны с su, но с точки зрения безопасности это кажется хуже.

Вход в консоль в текстовом режиме кажется наиболее безопасным. Поскольку он запускается init, если злоумышленник может контролировать PATH или LD_PRELOAD, он уже является пользователем root. События нажатия клавиш не могут быть перехвачены программами, работающими на X. Я не знаю, могут ли программы, работающие на X, перехватывать [ctrl] + [alt] + [f1] (и открывать полноэкранное окно, которое выглядит как консоль) или это безопасно, как [Ctrl] + [Alt] + [Del] в Windows. Кроме того, единственная проблема, которую я вижу, это отсутствие тайм-аута.

Так я что-то упустил? Почему ребята из Ubuntu решили разрешить только sudo? Что я могу сделать, чтобы улучшить безопасность любого из методов?

Как насчет SSH? Традиционно root не может войти через SSH. Но использование вышеупомянутой логики не будет самым безопасным:

• разрешить рут через SSH
• переключиться в текстовый режим
• войдите как root
• SSH к другой машине
• войти в систему как root?

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

Атаки LD_PRELOAD и PATH, подобные описанным вами, предполагают, что злоумышленник уже имеет доступ к вашей учетной записи или, по крайней мере, к вашим точечным файлам. Судо не очень хорошо защищает от этого - в конце концов, если у них есть ваш пароль, нет необходимости пытаться обмануть вас на потом ... их можно просто использовать sudo сейчас .

Важно учитывать, для чего изначально был разработан Sudo: делегирование определенных команд (например, тех, которые управляют принтерами) «субадминистраторам» (возможно, аспирантам в лаборатории), не отдавая root полностью. Использование sudo для выполнения всех задач является наиболее распространенным видом использования, которое я вижу сейчас, но это не обязательно та проблема, которую должна была решить программа (отсюда и до смешного сложный синтаксис файла конфигурации).

Но, Судо-для-неограниченный корень делает решение еще одной проблем безопасности: управляемости корневых паролей. Во многих организациях их, как правило, раздают как конфеты, пишут на досках и оставляют неизменными навсегда. Это оставляет большую уязвимость, так как отзыв или изменение доступа становится большим производственным числом. Даже отслеживание того, какой компьютер имеет какой пароль, является проблемой - не говоря уже о том, кто знает, какой именно.

Помните, что большинство «киберпреступлений» происходит изнутри. С описанной ситуацией с паролем root трудно отследить, кто что сделал - что-то sudo с удаленной регистрацией справляется довольно хорошо.

В вашей домашней системе, я думаю, это больше связано с тем, что вам не нужно запоминать два пароля. Вполне вероятно, что многие люди просто устанавливали их одинаковыми - или, что еще хуже, изначально устанавливали их одинаковыми, а затем позволяли им потерять синхронизацию, оставляя пароль root для гниения.

Использование паролей вообще для SSH опасно, так как троянец-демоны ssh с перехватом паролей используются в 90% реальных системных компромиссов, которые я видел. Гораздо лучше использовать ключи SSH, и это также может быть работоспособной системой для удаленного корневого доступа.

Но проблема в том, что теперь вы перешли от управления паролями к управлению ключами, а ключи ssh на самом деле не очень управляемы. Нет никакого способа ограничить копии, и если кто-то действительно делает копию, у него есть все попытки, которые он хочет взломать парольную фразу. Вы можете сделать политику, гласящую, что ключи должны храниться на съемных устройствах и монтироваться только при необходимости, но нет способа обеспечить это - и теперь вы представили возможность потери или кражи съемного устройства.

Наивысшая степень защиты достигается за счет одноразовых ключей или криптографических токенов на основе времени / счетчика. Это можно сделать с помощью программного обеспечения, но аппаратная защита от несанкционированного доступа еще лучше. В мире с открытым исходным кодом есть WiKiD , YubiKey или LinOTP , и, конечно же, есть проприетарный тяжеловесный RSA SecurID . Если вы работаете в организации среднего или большого размера или даже в небольшой, заботящейся о безопасности, я настоятельно рекомендую использовать один из этих подходов для административного доступа.

Тем не менее, это, вероятно, излишне для дома, где у вас действительно нет проблем с управлением - если вы соблюдаете разумные меры безопасности.

Это очень сложный вопрос. Mattdm уже рассмотрел много вопросов .

Между su и sudo, когда вы рассматриваете одного пользователя, su немного более защищен тем, что злоумышленник, обнаруживший ваш пароль, не может сразу получить привилегии root. Но все, что нужно, это чтобы злоумышленник нашел локальную корневую дыру (относительно редко) или установил троян и ждал, пока вы запустите su.

У Sudo есть преимущества даже перед входом в консоль, когда есть несколько пользователей. Например, если система настроена с удаленными защищенными журналами, вы всегда можете узнать, кто последний запускал sudo (или чья учетная запись была взломана), но вы не знаете, кто набрал пароль root на консоли.

Я подозреваю, что решение Ubuntu было частично в интересах простоты (запоминать только один пароль) и частично в интересах безопасности и простоты распространения учетных данных на общих компьютерах (бизнес или семейство).

В Linux нет безопасного ключа внимания или другого безопасного пользовательского интерфейса для аутентификации. Насколько я знаю, даже в OpenBSD их нет. Если вас беспокоит доступ с правами root, вы можете полностью отключить доступ с правами root из работающей системы: если вы хотите быть пользователем root, вам нужно будет что-то набрать в приглашении загрузчика. Это явно не подходит для всех случаев использования. (* Уровень безопасности BSD работает следующим образом: на высоком уровне безопасности есть вещи, которые вы не можете сделать без перезагрузки, такие как снижение уровня безопасности или прямой доступ к подключенным необработанным устройствам.)

Ограничение способов получения прав root не всегда является преимуществом для безопасности. Помните о третьем члене триады безопасности : конфиденциальность , целостность , доступность . Блокировка себя от вашей системы может помешать вам реагировать на инцидент.

Разработчики защищенного дистрибутива OpenWall GNU / * / Linux также высказали критическое мнение о su(для того, чтобы стать пользователем root) и sudo. Вы можете быть заинтересованы в чтении этой темы:

... к сожалению, su и sudo тонко, но в корне ошибочны.

Помимо обсуждения недостатков suи прочего, Solar Designer также нацелен на одну конкретную причину использования su:

Да, это была обычная мудрость сисадмина для "su root", а не для входа в систему как root. Те немногие, кто, когда их спросят, действительно могут найти вескую причину такого предпочтения, будут ссылаться на лучшую подотчетность, достигнутую с помощью этого подхода. Да, это действительно хорошая причина в пользу такого подхода. Но это также единственный. ...(читать далее)

В своем дистрибутиве они «полностью избавились от корневых программ SUID при установке по умолчанию» (т. Е. Включая su; и они не используют возможности для этого):

Что касается серверов, я думаю, что люди должны пересмотреть и, в большинстве случаев, запретить пользователям запускать su и sudo. Не существует дополнительной защиты от старого «входа в систему как не-root, затем su или sudo для root« sysadmin «мудрость», по сравнению с входом в систему как не-root и напрямую как root (два отдельных сеанса). Напротив, последний подход является единственным правильным с точки зрения безопасности:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Для подотчетности нескольких системных администраторов система должна поддерживать наличие нескольких учетных записей с привилегированными правами root, как это делает Owl).

(Для настольных компьютеров с X это становится сложнее.)

Вы также должны иметь дело с ...

Кстати, они должны были заменить suloginс , msuloginчтобы позволить установку с несколькими корневых счетами: msuloginпозволяют ввести имя пользователя и при переходе в однопользовательский режим (и сохранить «ответственность») (эта информация исходит от этой дискуссии на русском языке ) ,

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

Есть два разных способа работы с переменными среды. По умолчанию опция env_reset sudoers включена. Это приводит к тому, что команды выполняются с минимальным окружением, содержащим TERM, PATH, HOME, SHELL, LOGNAME, USER и USERNAME в дополнение к переменным из процесса вызова, разрешенного опциями endo_check и env_keep sudoers. Фактически существует белый список для переменных среды.

Если, однако, опция env_reset отключена в sudoers, любые переменные, явно не запрещенные опциями env_check и env_delete, наследуются из вызывающего процесса. В этом случае env_check и env_delete ведут себя как черный список. Поскольку невозможно занести в черный список все потенциально опасные переменные среды, рекомендуется использовать поведение по умолчанию env_reset.

Во всех случаях переменные среды со значением, начинающимся с (), удаляются, так как они могут быть интерпретированы как функции bash. Список переменных среды, которые sudo разрешает или запрещает, содержится в выходных данных sudo -V при запуске от имени пользователя root.

Поэтому, если env_resetвключено (по умолчанию), злоумышленник не может переопределить ваши PATHили другие переменные среды (если вы специально не добавите их в белый список переменных, которые должны быть сохранены).

Самым безопасным подходом является вход по ssh с использованием (как минимум) длинного ключа 2048 (при отключенном входе с паролем) с использованием физического устройства для хранения ключа.

Я просто хочу добавить что-то немного не по теме. (для темы проверьте '/ bin / su -' здесь после)

Я думаю, что вышеупомянутая «безопасность» также должна быть связана с фактическими данными, которые мы хотим защитить.

Это будет и должно быть иначе, если мы хотим защитить: my_data, my_company_data, my_company_network.

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

Учитывая это, я думаю, что безопасность в целом - это равновесие между удобством использования, «безопасностью данных» и необходимыми усилиями по внедрению защищенной системы.

Цель Ubuntu была и остается главным конечным пользователем: по умолчанию используется Sudo.

Fedora - это бесплатная версия RedHat, которая, в свою очередь, больше ориентирована на серверы: раньше Sudo был отключен.

Для других дистрибутивов у меня нет прямой информации.

Я использую сейчас, в основном, Fedora. И как пользователь старого стиля я никогда не набирал 'su'. Но я могу набрать "/ bin / su -" в очень короткое время, даже если я не совсем машинистка. Переменная PATH .. не должна быть проблемой (я набираю путь). Также "-" (минус) в принципе должен удалить мои переменные окружения пользователя и загрузить только корневые. т.е. избегать некоторых дополнительных возможных проблем. Вероятно, также LS_PRELOAD.

В остальном, я думаю, что @mattdm был довольно точным.

Но давайте поместим это в правильную коробку. Предположим, что умный набор скриптов получит доступ к моим данным. Какого черта, ты думаешь, он собирается с этим делать? - Публиковать мои фотографии? мой? - Пытаясь выяснить мое имя подруги и сказать ей, что я посещаю порно-сайты?

На однопользовательском изображении две худшие ситуации: - Ребенок удаляет все мои данные: для забавы или по ошибке - Ребенок использует мою машину, чтобы создать дальнейшую атаку на какую-то другую сущность. Или похожие цели.

В первом случае, о котором я упоминал выше, лучше создавать резервные копии, чем защищать сеть. Да, вы спасены. Я имею в виду сбой оборудования не так уж и отличается.

Второй случай более тонкий. Но есть сигналы об этих действиях. В любом случае, вы можете сделать все возможное, но я бы не стал настраивать свой домашний ПК на защиту от террористических атак!

Я пропущу другие сценарии.

ура F

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

Вы можете принудительно использовать ключи для удаленных пользователей, но это может не пройти проверку на соответствие требованиям. Возможно, будет более эффективно настроить блок шлюза SSH, который требует двухфакторной аутентификации, а затем разрешить использование ключа оттуда. Вот документация по такой настройке: Защитите свое развертывание SSH с помощью двухфакторной аутентификации WiKID .

Вы также можете взглянуть на privacyIDEA , которое не только предоставляет вам возможность использовать OTP для входа в систему (или для выполнения su / sudo), но также может выполнять OTP в автономном режиме.

Кроме того, он способен управлять вашими ключами SSH. Т.е. если у вас много машин и несколько пользователей root, все ключи SSH хранятся централизованно. Таким образом, легко «отозвать» / удалить ключ SSH, если ключу больше нельзя доверять.

Конечно, есть организационные задачи и рабочие процессы, чтобы обезопасить систему.