it-swarm-ru.tech

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

105
mattdm

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

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

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

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

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

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

30

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

... к сожалению, и su, и sudo тонко, но принципиально несовершенны.

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

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

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

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

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

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

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

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

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

10
imz -- Ivan Zakharyaschev

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

Есть два разных способа работы с переменными среды. По умолчанию опция env_reset sudoers включена. Это приводит к тому, что команды выполняются в минимальной среде, содержащей TERM, PATH, HOME, Shell, LOGNAME, USER и USERNAME в дополнение к переменным из процесса вызова, разрешенного опциями env_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 или другие переменные окружения (если вы специально не добавите их в белый список переменных, которые должны быть сохранены).

4
Cedric

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

4
Šimon Tóth

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ура F

3
user5520

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

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

2
nowen

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

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

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

0
cornelinux