Цель создания пользователя без полномочий root [закрыто]

В дополнение к обоснованной озабоченности, упомянутой в ответе @Ravexina, я думаю, что важно отметить:

SSHing в Ваш сервер не является единственным способом, которым злонамеренный агент мог выполнить действия

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

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

Посмотрите, когда Вы запустите программу, как Apache, PHP, или PHP/Python/NodeJS сценарий или даже Ваш веб-браузер: тот "процесс" также должен работать как пользователь. Например: Если Вы выполняете Сценарий PHP как root, затем это процесс PHP может сделать что-либо root может сделать.

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

Хитрая вещь здесь: уязвимость RCE даже не могла бы быть кодом, который Вы написали: это могло быть проложено под землей глубоко в некоторой сторонней библиотеке/модуле, в которую звонит Ваш код: вычислите даты, взаимодействуйте с базой данных, представьте HTML и т.д... Другими словами: Вы даже не могли бы знать, что это там. И можно было бы тихо добавить к Вашей кодовой базе при обновлении зависимостей/библиотек. Как мы видели во взломе EventStream, может быть тривиально легко получить контроль над восходящим репозиторием библиотеки и использовать его для продвижения вредоносного кода к не подозревающим приложениям в нисходящем направлении. Если тот вредоносный код работает как корень, он может взять под свой контроль Ваш весь сервер и даже замести следы туда, где Вы никогда не знаете, что это произошло.

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

*, Очевидно, если Ваш пароль abc123 это не применяется, потому что это - вероятно, один из первых хакеров, попробует когда принуждение скота.

Это на самом деле зависит от того, что Вы делаете на своем сервере. В дополнение к ответу @Ravexina (предполагают нападение пароля): Вы, например.

• доступ некоторые веб-сайты
• считайте почту
• просмотрите некоторые изображения
• считайте PDFs

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

• (некорневой) доступ и удаляет все Ваши файлы, устанавливает программное обеспечение для локального пользователя и т.д.
• (корень) делает все

В то время как некорневое использование может быть наращено (см. https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), это предлагает дополнительный слой защиты. Это также защищает от несчастных случаев, как упомянуто @David Schwartz:

У всех, кто использовал Linux довольно долго, было время, когда они случайно ввели команду, что, имел их корень в то время, полностью уничтожит их систему. Мое новое желало удалить все содержание моего текущего каталога и случайно вводило rm -rf . /* вместо rm -rf ./*.

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

https://xkcd.com/1200/

Но не забудьте защищать то, что действительно важно.