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

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

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

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

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

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

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

  • разрешить root через SSH
  • перейти в текстовый режим
  • войти как root
  • ssh на другую машину
  • войти в систему как root?
116 голосов | спросил stribika 4 MarpmFri, 04 Mar 2011 20:02:19 +03002011-03-04T20:02:19+03:0008 2011, 20:02:19

8 ответов


103

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

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

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

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

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

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

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

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

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

Это, вероятно, слишком много для дома, хотя у вас на самом деле нет проблем с управлением - пока вы следите за разумными методами безопасности.

ответил mattdm 4 MarpmFri, 04 Mar 2011 21:20:31 +03002011-03-04T21:20:31+03:0009 2011, 21:20:31
29

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

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

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

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

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

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

ответил Gilles 4 MarpmFri, 04 Mar 2011 23:04:40 +03002011-03-04T23:04:40+03:0011 2011, 23:04:40
9

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

... к сожалению, как su, так и sudo - тонко, но принципиально недостатки.

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

  

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

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

  

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

     

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

     

(за подотчетность нескольких   системных систем, система должна поддерживать   с несколькими привилегированными правами root   счета, например, Сова).

     

(Для рабочих столов с X это получает   хитрее.)

     

Вам также абсолютно необходимо иметь дело с ...

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

ответил imz -- Ivan Zakharyaschev 5 MarpmSat, 05 Mar 2011 21:47:45 +03002011-03-05T21:47:45+03:0009 2011, 21:47:45
4

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

  

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

     

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

     

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

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

ответил Cedric 4 MarpmFri, 04 Mar 2011 20:41:21 +03002011-03-04T20:41:21+03:0008 2011, 20:41:21
4

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

ответил Let_Me_Be 4 MarpmFri, 04 Mar 2011 21:13:27 +03002011-03-04T21:13:27+03:0009 2011, 21:13:27
3

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

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

Он будет и должен быть другим, если мы хотим обеспечить: my_data, my_company_data, my_company_network.

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

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

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

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

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

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

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

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

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

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

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

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

веселит F

ответил 9 MaramWed, 09 Mar 2011 00:38:46 +03002011-03-09T00:38:46+03:0012 2011, 00:38:46
2

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

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

ответил nowen 7 MarpmMon, 07 Mar 2011 20:03:58 +03002011-03-07T20:03:58+03:0008 2011, 20:03:58
0

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

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

Конечно, для обеспечения безопасности существуют организационные задачи и рабочие процессы.

ответил cornelinux 28 Maypm15 2015, 12:44:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132