Рейтинг:18

root логин или пользователь sudo для администрирования сервера?

флаг br

Я пытаюсь понять технические аргументы/последствия безопасности между ssh'ингом с root напрямую или созданием вспомогательного пользователя sudo в контексте обслуживания сервера. Чтобы уточнить, мы говорим о серверах, принадлежащих одному администратору. Для нескольких человек, работающих на машине, очевидным преимуществом аудита является наличие уникальных пользователей для каждого реального человека и детальных разрешений.

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

Итак, есть ли какие-либо преимущества с точки зрения безопасности в создании «прокси-пользователя», которому вы все равно собираетесь использовать sudo для root, вместо того, чтобы напрямую предоставлять ssh-доступ к root?

Единственное преимущество, о котором я могу думать, - это безопасность через неизвестность, т. Е. Боты обычно пытаются проверить пользователя «root». Но, насколько я понимаю, если пользователь sudoers будет скомпрометирован, это то же самое, что скомпрометировать пользователя root, так что игра окончена.

Кроме того, большинство сред удаленного администрирования, систем NAS и гипервизоров поощряют использование пользователя root для входа в Интернет.

флаг ba
Если я хакер, я знаю, что root будет существовать на всех Linux-машинах. Блокировка root (и гостя), создание учетной записи «SupremeLeaderSnoke» и предоставление этой учетной записи полного доступа sudo — тривиальный уровень защиты. Теперь мне нужно угадать как имя пользователя, так и пароль, чтобы войти. Теперь вы можете стать более изощренным и создать несколько учетных записей с привилегиями sudo для определенных ресурсов для инструментов удаленного администрирования, таким образом, вы снова ограничите радиус взрыва, если кто-то проникнет.
флаг cn
@IanW: Незнание имени пользователя - это «безопасность по неизвестности», что вовсе не является безопасностью. Кроме того, вводя sudo, вы вводите потенциальные ошибки безопасности, которые могут привести к повышению локальных привилегий (например, CVE-2021-3156).
флаг ba
@jakub-luck%c3%bd, но чтобы использовать уже имеющуюся ошибку sudo, нужно быть внутри. Я ни в коем случае не предлагал отключать root-доступ, достаточно создать вторую учетную запись. Также не буду вступать в дискуссию о том, что такое «достаточно».При установке приложений с правами root и входе в систему с правами root пользователь неизбежно всегда будет входить в систему с правами root, даже для рутинных задач без полномочий root. Теперь вы открываете себя для еще большего количества векторов уязвимостей, чем просто sudo.
marcelm avatar
флаг ng
Существует третий вариант, не упомянутый в вопросе: использование «su» вместо «sudo» через прокси-аккаунт.
флаг ch
@JakubLucký безопасность по неизвестности _alone_ вовсе не безопасность. При использовании в качестве независимого уровня в дополнение к другим передовым методам обеспечения безопасности неясность считается действенным инструментом безопасности.
флаг in
В основном был дан ответ здесь: https://serverfault.com/questions/580881/is-it-ok-to-set-up-passwordless-sudo-on-a-cloud-server/581111#581111
Andrew Henle avatar
флаг ph
@JakubLucký * вводя sudo, вы вводите потенциальные ошибки безопасности, которые могут привести к повышению локальных привилегий * А? С таким же успехом можно сказать: «В заборе могут быть дыры, так что мы просто позволим коровам бегать на свободе». Предоставление прямого root-доступа из-за того, что `sudo` может быть скомпрометировано, вряд ли является улучшением безопасности. Неважно, что вы полностью удаляете ответственность и неотказуемость. Я уверен, что ваши аудиторы по безопасности это примут.
флаг br
@JakubLucký Я определенно не соглашусь с тем, что безопасность по неизвестности вовсе не является безопасностью - как и все меры безопасности, она работает как часть / уровень всей вашей стратегии, точно так же, как изменение порта SSH по умолчанию не является безопасностью как таковой, но устраняет практически все сканеры портов и ботов, исследующих вашу систему. Хотя, как я повторил, мой вопрос сугубо технический, а не социальная инженерия, не корпоративная политика, не религиозные верования и заклинания а-ля "никогда не использовать гото" :)
флаг br
@AndrewHenle, хотя я соглашусь с тем, что аргумент о компрометации sudo находится глубоко на параноидальной территории, время от времени мы видели обнаруженные дыры в критических компонентах ОС, поэтому я не думаю, что мы, как профессионалы, должны относиться к любому программному обеспечению как к безупречному :)
user avatar
флаг sa
@alex.b.bg Параноидальная территория? CVE-2021-3156 была выпущена всего год назад, и это была не единственная ошибка sudo. Существует также проблема неправильной настройки программного обеспечения. Это абсолютно правильное предложение рассмотреть потенциальные проблемы, просто добавив sudo к чему-либо.
флаг br
@user Да, параноик, потому что, если вы спуститесь в эту кроличью нору, вы можете прийти к выводу, что ничто во вселенной не является безопасным, включая тот момент, когда точно критическое количество дисков в вашем рейде выходит из строя одновременно или более элегантно - дата-центр загорается :) Возьмем шумиху вокруг log4j - довольно серьезная драма, дыра существует уже много лет - вы слышали о реальной атаке через них? у меня нет. Конечно, если вы работаете в АНБ, паранойя — это определенно плюс. Если вы защищаете свой домашний NAS — я так не думаю.
флаг br
@user, и я не говорю, что ваши личные данные не стоят того, что есть у АНБ - лично я даю ровно ноль центов, если данные Мира исчезнут по сравнению с моими семейными фотографиями :) Но что более важно - субъекты угрозы крупные корпорации или агентства сильно отличаются от тех, которые потенциально могут атаковать вашу частную сеть. Глядя на мой журнал fail2ban за последние 10 лет, я увидел только один зонд, который, вероятно, был специально нацелен на меня.
Рейтинг:16
флаг be

Следует учитывать одну вещь: при использовании ключей SSH для удаленной аутентификации, что произойдет, если закрытый ключ будет скомпрометирован?

Если root: root-доступ скомпрометирован. Надеюсь, вы не использовали этот ключ для root-доступа на нескольких машинах.

Если пользователь: этот пользователь скомпрометирован. Однако, злоумышленник не сможет запустить sudo, поскольку пароль пользователя не скомпрометирован. Пока что. (Предполагая, что для использования sudo требуется пароль)

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

Dubu avatar
флаг do
Ну, этот закрытый ключ должен _по-прежнему_ иметь пароль.
Ben Voigt avatar
флаг pl
@Dubu: закрытый ключ - это просто большое число, там нет пароля. Я предполагаю, что вы имели в виду пароль к ключевому файлу, в котором постоянно хранится ключ.... но ключ по-прежнему будет временно незащищенным в памяти, в течение которого он уязвим для ошибок, подобных Heartbleed.
флаг jm
@BenVoigt Закрытый ключ - это просто большое число. Но вас спросят, хотите ли вы защитить это большое число парольной фразой при создании ключевого файла. Ответ всегда должен быть да.
Ben Voigt avatar
флаг pl
@ doneal24: Это то, на что я указывал, что парольная фраза защищает ключ только от раскрытия через ключевой файл, а не везде.
флаг br
Что помешает злоумышленнику просто изменить пароль вашего пользователя и таким образом выполнить sudo? Выбрав этот путь, вы можете защитить паролем свой ssh-ключ, что я определенно рекомендую всегда, каждый раз, и даже больше — у вас может быть отдельный пароль для root, который вам потребуется вводить в sudo с помощью rootpwd — это Таким образом, даже если ваш пользователь скомпрометирован, злоумышленник не сможет использовать sudo.НО, учитывая защищенный паролем ключ ssh, возможно, вышеизложенное переходит в страну параноиков.
joshudson avatar
флаг cn
Хотите посмотреть, что я могу сделать со скомпрометированным ключом ssh личной учетной записи администратора, когда используется sudo?
TylerW avatar
флаг be
@ alex.b.bg вы имеете в виду пользователя без полномочий root с скомпрометированным ключом? Пользователь должен ввести свой текущий пароль, чтобы изменить пароль пользователя. В противном случае для принудительного изменения требуется доступ администратора, такой как su или sudo... для чего, опять же, требуются пароли.
флаг br
@TylerW, верно, забыл об этом.
Рейтинг:10
флаг ng

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

...зачем использовать sudo

  • Если ваш ssh-ключ для root-логина скомпрометирован, у вас мало шансов правильно выйти из ситуации.
  • Команды, использующие sudo, регистрируются, это не только обеспечивает безопасность, когда есть несколько администраторов, но и если какой-то злоумышленник проник в вашу систему.
  • У тебя очень подробные параметры настроить разрешения для каждого пользователя, это через /etc/ssh/sshd_config или через SUDOers файл. (не используйте другой редактор, кроме зрение!)
  • Даже если ваш логин ssh по умолчанию скомпрометирован: дополнительный уровень, такой как sudo, делает права root менее доступными. (я всегда использую По умолчанию targetpw - как на моем настольном компьютере, так и на моих серверах. Так что нужно знать два разных пароля, чтобы стать root)

Чтобы добавить к последнему пункту: я лично использую отдельных пользователей для каждой задачи на своих серверах (я единственный администратор): например. один пользователь для бэкапов. У него есть доступ к файлам для резервного копирования и отдельный доступ по ssh к внешнему серверу. У меня есть один пользователь для мониторинга, который имеет очень ограниченный доступ к лог-файлам и API мониторинга. Достаточно упомянуть несколько примеров...

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

Итак, я настоятельно рекомендую: используйте sudo вместо пользователя root


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

ssh root вход

  • Независимо от открытия root-логина или нет: использование ключевых файлов ssh — единственный безопасный способ. Не используйте пароли без ключевых файлов. (Вот руководство)
  • Добавьте правила брандмауэра и правила sshd, например ЛогинGraceTime и MaxAuthTries для ограничения атак BruteForce.
  • Если вы оставите возможность входа в систему как пользователь root, это приведет к уязвимости в системе безопасности. Даже если это очень маловероятно, чтобы использовать недостаток. (Я предпочитаю РазрешитьRootВойти)
  • Технически, если вы защищаете вход root в соответствии с рекомендациями, это не менее безопасен, чем повседневный ssh.

су

  • На мой взгляд, единственная проблема при входе в систему с правами root заключается в том, что вам не нужно вводить судо перед каждой командой, что делает вас более подверженным ошибкам
void avatar
флаг ng
Не забывайте, что вы можете добавить несколько «функций» в sudo, используя `visudo`: Как долго будет длиться метка времени? Какой пароль вам нужно будет ввести? Какие команды доступны без пароля?...
флаг br
Я думаю, что то, что вы упомянули об изменении конфигурации sudoers с помощью значения по умолчанию targetpw, является единственным реальным случаем, когда технически вы получаете большую безопасность. В профессиональной среде это именно то, что я делаю, особенно на общедоступных конечных точках — таким образом, даже если у вас есть небрежный пароль на вашем ключе ssh (а люди обычно повторно используют свои «стандартные» пароли), даже если вы скомпрометируете ключ, по крайней мере, есть еще один пароль, который нужно взломать. Но без rootpw/targetpw, по крайней мере сейчас, я не уверен, что прокси-пользователь предоставляет какие-либо технические преимущества.
void avatar
флаг ng
Нет, технически у «прокси» пользователя нет реального преимущества перед действиями в качестве root. Но, тем не менее, вы можете реализовать еще большую безопасность с помощью sudo, например. комбинируйте с SELinux или даже установите свой собственный пароль. Я никогда не использовал его, но думаю, что это упростило бы использование баз данных аутентификации в качестве LDAP для sudo. Самое интересное, возможно, для однопользовательской машины: возможна также интеграция TOTP.
void avatar
флаг ng
Возвращаясь к вашему мнению о ключевых паролях: на самом деле я никогда не использую ключевые пароли (поскольку я храню свои ключи только на частных и зашифрованных устройствах), но я установил `AuthenticationMethods publickey,password` в `sshd_config` таким образом, чтобы требовался второй фактор. И после этого я использую sudo, как обсуждалось выше... Но, конечно, вы должны защитить паролем свои ключи в профессиональной среде.
флаг ba
Привет, @void, единственное, чего не хватает, чтобы сделать ваш ответ полным, - это справочная ссылка «Не используйте пароли без файлов ключей». на "как сделать" ключевые файлы.
void avatar
флаг ng
@lanW хорошая мысль. Опытный пользователь должен иметь возможность исследовать базовые вещи самостоятельно, но я добавлю ссылки для неопытных админов. +1
флаг br
@void Я бы рекомендовал использовать ключевые пароли независимо от того, где вы их храните. Утечка закрытых ключей происходит то здесь, то там, и особенно если вы используете их в нескольких местах, это становится единственной точкой (безопасности) отказа для всей вашей экосистемы. Я думаю, что ключи без пароля имеют смысл для автоматизированных вещей с очень ограниченными учетными записями разрешений, таких как запланированное задание резервного копирования или какая-либо другая интеграция. Кстати, я не знал, разделяете ли вы запятыми несколько методов аутентификации для sshd, они нужны оба :) Я должен попробовать это...
void avatar
флаг ng
@ alex.b.bg Вы абсолютно правы. Я не рекомендую не защищать паролем ключевые файлы. Это просто удобство для меня. Таким образом, я использую отдельные ключевые файлы для каждого устройства и каждой учетной записи ssh плюс второй фактор целевого пароля (pam на стороне сервера), который по-прежнему остается довольно безопасным.
Рейтинг:9
флаг it

Для всех целей я настоятельно рекомендую вам не использовать корень; даже отключить его, если это возможно. Я регулярно отключаю root на серверах Linux/UNIX. Пользователь root не может быть огорожен, его действия не протоколируются. По крайней мере, будет зарегистрирована команда sudo, что очень полезно в случае неправильного обращения администратора. Вы также можете настроить разрешения для пользователей, предоставив только некоторые привилегии. Конечно, если root отключен, ведение журнала ssh с использованием root невозможно.

По опыту, рута не хватает только в случае, если вам нужно загрузиться в режиме одиночного пользователя или аварийной загрузки; редкий сценарий, когда сервер не может правильно загрузиться. Но если это так, вы можете включить его, изменить пароль и перейти к восстановлению.
Другой случай - копирование файлов с использованием sftp (или ftp, чего, конечно, следует избегать, если только во внутренних сетях), где вам нужно напрямую копировать в / из каталогов только с правами root. В этом сценарии вы можете использовать ACL, чтобы предоставить разрешения другому пользователю и продолжить.

флаг br
Я прошу сценарий, в котором я являюсь единственным администратором данной машины - упускаю ли я технические преимущества / преимущества безопасности двух подходов (например, случай, когда даже «прокси-пользователь» скомпрометирован, он не может сделать такой большой ущерб по сравнению с скомпрометированным пользователем root напрямую. Для нескольких администраторов/пользователей хорошим аргументом является контрольный журнал. На самом деле я отредактирую вопрос, чтобы добавить это в контекст вопроса.
Scottie H avatar
флаг cn
Как системный администратор, важно использовать «лучшую практику», которая заключается в том, чтобы войти в систему как вы, а затем, когда это необходимо, переключиться на root. TBH, если вы ЕДИНСТВЕННЫЙ пользователь, у вас нет внешнего подключения, и у вас есть антивирус / антивирус для сканирования установочного носителя - ваше право, это не имеет большого значения (пожалуйста, перечитайте эти 3 предостережения и убедитесь, что вы их прекрасно понимаете). Тем не менее, привыкнуть к входу в систему с правами root трудно сломать; когда вы попадаете в «обычную и привычную» систему, вам будет трудно адаптироваться. *Научитесь делать это правильно, прежде чем начнете нарушать правила!* 0,02 $
флаг in
Обычно можно просто `sudo -s` и иметь корневую оболочку. Теоретически вы, конечно, можете настроить так, чтобы пользователь «обновления» мог просто запускать «подходящее обновление» или что-то в этом роде, но это усложнит ситуацию и выходит за рамки ОП.
флаг br
@ScottieH, если ваша административная станция скомпрометирована (то, что вы упомянули об антивирусе / антивредоносном ПО) и, скажем, злоумышленник записывает вашу процедуру входа в систему на сервере, я думаю, что игра окончена, независимо от того, насколько хорошо этот сервер защищен. Но я понимаю вашу точку зрения, и это действительно важно — безопасность касается всех узлов, которые так или иначе связаны.
joshudson avatar
флаг cn
Если вы можете запросить экстренную загрузку на консоли, пароль root — это лежачий полицейский, а не барьер.
Рейтинг:6
флаг gh

на сервере вы обычно входите в систему, чтобы поддерживать его, и в 99% случаев все ваши действия требуют прав root.

Я хотел бы оспорить это. Есть много рутинных задач, которые просто ищут информацию, которую может видеть любой пользователь. "top", "ps", "df", просмотр логов и т.д.

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

Если вы запускаете все как root, вы будете работать неаккуратно. С кем не бывает.
Когда вы небрежны, вы совершите ошибки. С кем не бывает.

Не приобретайте эту привычку.

(Я также согласен с тем, что несколько других сказали о том, что быть единственным администратором сегодня не означает, что вы будете единственным администратором завтра)

Рейтинг:5
флаг mx

Консультант по безопасности здесь.

Передовая практика все приложения, системы, решения, операционные системы и все остальное, что вы можете придумать, — это использовать учетную запись root только для настройки, а затем отключать ее.

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

Обфускация учетных записей по-прежнему неплохая идея, т. е. не называйте свои учетные записи администратора администратором, но реальная ценность этого невероятно низка.Большинство «взломов» происходят в течение недель и месяцев, а не секунд и минут, как это делают СМИ/фильмы/телевизионные шоу, и у любого будет набор навыков для «взлома», у вас также будет набор навыков для проверки таких вещей, как SID администратора Windows. (это всегда S-1-5-32-544 для встроенного администратора Windows).

флаг br
Это точно мое наблюдение — большинство атак, которые я видел, особенно в корпоративной инфраструктуре, вращаются вокруг вредоносных программ на рабочих станциях из-за небрежной безопасности ИЛИ мошеннических действий сотрудников, которые позже делятся разрезом с злоумышленниками. Но как только вы станете владельцем рабочей станции, машины, на которые вы входите с нее, в основном будут уничтожены, независимо от того, какие промежуточные шаги вы предпримете. Таким образом, из комментариев до сих пор кажется, что использование нетривиального имени для входа определенно помогло бы с автоматическими атаками и детишками-скриптами, но не для сдерживания серьезного актера.
mak47 avatar
флаг mx
Тем не менее, почти всегда кто-то нажимает на то, чего не должен. Особенно это касается старых фирм, я провел годы, борясь с тем фактом, что одни и те же старые точки отказа в ключевых системах терпят неудачу *каждый отдельный тест на фишинг*, который мы им бросаем, остается без выговоров. Можно утверждать, что это внутренняя угроза, если не злонамеренная, по крайней мере. imo все, на что действительно следует тратить деньги, это низко висящие фрукты, потому что у нас у всех их много, т.е.MFA/2FA для каждой отдельной учетной записи администратора, о которой вы заботитесь, решит значительное количество любых будущих *серьезных* инцидентов, которые могут возникнуть у вас.
флаг br
Полностью согласен - человеческий фактор всегда более легкая, дешевая и надежная поверхность атаки, чем всякая высокотехнологичная 1337 гиковщина. Зачем вы тратите часы за часами на изучение информации, когда вы можете просто отправить по электронной почте этот cute_animated_cat.exe :) Мы немного оффтопим здесь, но по моему опыту, лучший способ бороться с этим - максимально ограничить ущерб - заключение в тюрьму обычных пользователей, невозможность загрузки, ограничение использования флешки, хороший антивирус и слово, которое, к сожалению, мало кто воспринимает всерьез - стратегия РЕЗЕРВНОГО КОПИРОВАНИЯ!
Рейтинг:4
флаг cn
Bob

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

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

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

Вы не хотите, чтобы их уход требовал сброса паролей (и файлов ~/.ssh/authorized_keys) всех корневых и других общих учетных записей, к которым (могли) иметь доступ покидающие. Это административная работа PITA, которая часто не выполняется, поэтому вам нужно в первую очередь не допустить, чтобы это стало проблемой.

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

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

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

флаг cn
Bob
Не так красноречиво, как хотелось бы выразиться, но в деловой обстановке не используйте ярлыки. Дома ; делай как пожелаешь.
Рейтинг:2
флаг cn

Как и все вопросы безопасности, это вопрос аппетита к риску. Как заявляли другие, использование SSH в качестве пользователя без полномочий root с ключом, а затем повышение прав до уровня root означает, что в игре есть второй фактор (у вас есть ключ, вы ЗНАЕТЕ пароль), который может ограничить радиус действия компрометации. . Есть также аспект аудита, о котором упоминали другие.

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

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

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

флаг br
Будет ли справедливо сказать, что 2-й уровень безопасности будет таким же, как защита паролем вашего ssh-ключа?
флаг cn
Я полагаю, но это второй слой в другой части системы. Наличие пароля на вашем SSH-ключе помогает снизить вероятность того, что кто-то его использует, но как только он взломает его, нет никаких дополнительных мер для входа в качестве пользователя root. Все дело в глубокоэшелонированной защите...
Рейтинг:1
флаг jo

Это чисто вопрос безопасности и удобства.

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

Однако чем крупнее ваша компания, тем серьезнее они будут относиться к безопасности.

Например, мой нынешний работодатель — компания с более чем 50 000 сотрудников в 5 странах. Получить ROOT-логин абсолютно невозможно. Получение доступа к SUDO также занимает около 2 недель с выходом из уровня директора.

флаг br
«значительно менее безопасный» - я пытаюсь технически понять, почему это так. Из ответов, которые я читал на похожие вопросы, и ответов здесь видно, что последствия для безопасности больше касаются аудиторского следа/детальных разрешений, а не технических различий - конечно, для большой компании или даже сервера, к которому обращаются несколько сопровождающих, имеет смысл иметь учетную запись для каждого человека. НО, в случае, когда это ваша собственная машина - скажем, персональный vps, домашняя лаборатория, я пытаюсь выяснить, есть ли разница, если вы единственный администратор.
флаг ba
re: «Однако, чем крупнее ваша компания, тем серьезнее они будут относиться к безопасности». риски, никто не будет сочувствовать, когда ваша ИТ-инфраструктура будет скомпрометирована, а ваш бизнес разорен. Злоумышленники не будут думать: «О, это малый бизнес, я не буду скомпрометировать их ради собственной выгоды, потому что я сочувствующий хакер». «Гораздо удобнее оставить дверь дома незапертой, чем искать ключи при возврате с продуктами»; Тебе следует?
Kai Burghardt avatar
флаг bo
Здесь я на стороне @madacoda: это зависит от вашего **уровня паранойи**. Хотите ли вы минимизировать эксплойты с помощью используемого вами программного обеспечения (или _аппаратного_ оборудования_!)? Хотите предотвратить автоматизированные атаки? Вы хотите предотвратить _физические_ атаки? _Кто_ напал на вас? По сути, вы проводите обычную [оценку уязвимости] (https://en.wikipedia.org/wiki/Vulnerability_assessment) и действуете соответственно. Ежегодный тест на проникновение, проводимый третьей стороной, предоставляет вам обратную связь. Чисто **технически** говоря, нет никакой _внутренней_ выгоды в наличии разных пользователей вообще.
флаг br
@KaiBurghardt «Чисто говоря, нет никакой внутренней выгоды в том, чтобы иметь разных пользователей». - на самом деле это именно контекст вопроса, есть ли техническое отличие, закрывающее любые потенциальные уязвимости. Из ответов здесь я вижу, что довольно сложно отделить эту небольшую деталь от общего контекста безопасности, но приятно видеть, что несколько человек согласны с тем, что вы сказали. Учитывая, что вы используете ключ, защищенный паролем, единственным преимуществом прокси-пользователя, по-видимому, является запутывание имени пользователя, с которым вы входите в систему.
Kai Burghardt avatar
флаг bo
@alex.b.bg: Моя точка зрения (и @madacoda) заключается в том, что все зависит от вашего «определения уязвимости». Наличие разных пользователей является _возможным средством предотвращения/предотвращения _определенных_ "атак", но если вы _не_ признаете такие сценарии потенциальной проблемой для вас, принятие меры "управление пользователями" является просто причиной неудобства. . Вы знаете, если бы все в мире были дружелюбны, никто никому не причинял вреда, не было бы оправдания для наличия разных учетных записей пользователей с разными уровнями привилегий.
флаг br
@KaiBurghardt да, я задал вопрос в основном для того, чтобы прояснить его для себя, если я что-то упускаю с технической стороны.С практической точки зрения, если мы говорим о домашних лабораториях, персональных компьютерах и т. д., которые находятся за приличными уровнями безопасности — например, с VPN, изоляцией от общего доступа и т. д., я думаю, как злоумышленник, я бы сосредоточился на гораздо большем установить кейлоггер на персональный компьютер, где пользователь вводит все свои пароли, чем пытаться взломать сами машины :)
Рейтинг:1
флаг sg

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

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

Ответить или комментировать

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