Я хотел бы иметь корневую учетную запись в безопасности, даже если мой непривилегированный пользователь скомпрометирован.
В 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 . Если вы работаете в организации среднего или большого размера или даже в небольшой, заботящейся о безопасности, я настоятельно рекомендую использовать один из этих подходов для административного доступа.
Тем не менее, это, вероятно, излишне для дома, где у вас действительно нет проблем с управлением - если вы соблюдаете разумные меры безопасности.
источник
sudo
очень похож на Контроль учетных записей пользователей в Windows Vista. Оба на самом деле предназначены не для повышения безопасности, а для того, чтобы облегчить ее контролируемое снижение . Но поскольку они облегчают временное повышение ваших привилегий с минимальным трением, вам не нужно работать с повышенными привилегиями в течение продолжительных периодов времени, что повышает безопасность. (Это не было большой проблемой в Unix, но в Windows я помню, как работал администратором целыми днями, просто потому, что переключение было таким болезненным.)root
паролей вашей компании, также упоминаются в качестве последнего пункта в отчете Ops , который стоит прочитать.Это очень сложный вопрос. 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
:В своем дистрибутиве они «полностью избавились от корневых программ SUID при установке по умолчанию» (т. Е. Включая
su
; и они не используют возможности для этого):Кстати, они должны были заменить
sulogin
с ,msulogin
чтобы позволить установку с несколькими корневых счетами:msulogin
позволяют ввести имя пользователя и при переходе в однопользовательский режим (и сохранить «ответственность») (эта информация исходит от этой дискуссии на русском языке ) ,источник
Вы, кажется, предполагаете, что использование
sudo
всегда сохраняет переменные окружения, но это не всегда так. Вот выдержка из справочной страницы sudo:Поэтому, если
env_reset
включено (по умолчанию), злоумышленник не может переопределить вашиPATH
или другие переменные среды (если вы специально не добавите их в белый список переменных, которые должны быть сохранены).источник
Password:
ничего не отображает, когда я печатаю, посылает ему то, что я набрал, говорит, что пароль неправильный, затем исполняет настоящее sudo.alias /usr/bin/sudo="echo pwned"
кроме того, что задействовано множество программ (X, xterm, оболочка), любая из которых может украсть пароль. Вот почему я сказал, что слишком много проблем с безопасным переключением.bash: alias: `/usr/bin/sudo': invalid alias name
Самым безопасным подходом является вход по 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, если ключу больше нельзя доверять.
Конечно, есть организационные задачи и рабочие процессы, чтобы обезопасить систему.
источник