Использует ли / usr / sbin / nologin в качестве оболочки для входа службу безопасности?

В моем /etc/passwd я вижу, что пользователь www-data используемый Apache, а также всевозможные системные пользователи, имеет либо /usr/sbin/nologin либо /bin/false качестве своей оболочки входа. Например, вот выбор строк:

 daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin games:x:5:60:games:/usr/games:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin syslog:x:101:104::/home/syslog:/bin/false whoopsie:x:109:116::/nonexistent:/bin/false mark:x:1000:1000:mark,,,:/home/mark:/bin/bash 

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

 mark@lunchbox:~$ sudo su www-data This account is currently not available. mark@lunchbox:~$ sudo su syslog mark@lunchbox:~$ 

Конечно, это не так много неудобств, потому что я все еще могу запустить оболочку для них с помощью такого метода:

 mark@lunchbox:~$ sudo -u www-data /bin/bash www-data@lunchbox:~$ 

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

Установка оболочки пользователя Apache для чего-то неинтерактивного – это, как правило, хорошая практика безопасности (действительно, всем пользователям сервиса, которые не должны входить в интерактивную систему, должна быть установлена ​​их оболочка для чего-то, что не является интерактивным).

– https://serverfault.com/a/559315/147556

оболочка для пользовательских www-данных установлена ​​в / usr / sbin / nologin, и она установлена по очень веской причине.

– https://askubuntu.com/a/486661/119754

[системные учетные записи] могут быть дырами в безопасности , особенно если они имеют оболочку:

  • Плохо

     bin:x:1:1:bin:/bin:/bin/sh 
  • Хорошо

     bin:x:1:1:bin:/bin:/sbin/nologin 

– https://unix.stackexchange.com/a/78996/29001

По соображениям безопасности я создал учетную запись пользователя без оболочки входа для запуска сервера Tomcat:

 # groupadd tomcat # useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat 

– http://www.puschitz.com/InstallingTomcat.html

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

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

  • Настройка прав доступа к файлам для группы
  • Пользователи с паролем (по крайней мере, для входа)
  • Добавьте новые шаги пользователя для Oracle Linux 5
  • Есть ли Linux-эквивалент супер-администратора Windows?
  • Процессы Killall под пользователем?
  • Имеет ли пользователь разрешение на запись за пределами / home / userDir?
  • Как отключить опцию Switch User из Fedora 15
  • Как получить имя пользователя, запустившего `sudo`
  • 7 Solutions collect form web for “Использует ли / usr / sbin / nologin в качестве оболочки для входа службу безопасности?”

    Если вы посмотрите на страницу руководства nologin вы увидите следующее описание.

    выдержка

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

    Если файл /etc/nologin.txt существует, nologin отображает его содержимое пользователю вместо сообщения по умолчанию.

    Код выхода, возвращаемый nologin , всегда равен 1.

    Таким образом, фактическое намерение nologin заключается в том, что когда пользователь пытается войти в систему с учетной записью, которая использует ее в /etc/passwd , так, чтобы они были представлены удобным для пользователя сообщением и что любые скрипты / команды, которые попытайтесь использовать этот логин, получите код выхода 1.

    Безопасность

    Что касается безопасности, вы обычно увидите /sbin/nologin а иногда и /bin/false , между прочим в этом поле. Оба они выполняют одну и ту же цель, но /sbin/nologin , вероятно, является предпочтительным методом. В любом случае они ограничивают прямой доступ к оболочке как к этой конкретной учетной записи пользователя.

    Почему это считается ценным в отношении безопасности?

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

    С помощью nologin или /bin/false выполняется это. Ограничение уровня атаки вашей системы является распространенным методом в мире безопасности, будь то отключение служб на определенных портах или ограничение характера входа в систему.

    Тем не менее существуют другие рационализации для использования nologin . Например, scp больше не будет работать с учетной записью пользователя, которая не назначает действительную оболочку, как описано в этом Q & A ServerFault под названием «В чем разница между / sbin / nologin и / bin / false? ,

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

    Мой сервер debian был скомпрометирован из-за того, что учетная запись daemon имеет действующую оболочку для входа и открыта для доступа к Интернету samba. Перерыв был сделан путем установки пароля удаленно через samba для учетной записи демона и входа в систему через ssh. Затем локальный корневой эксплоит был использован для СОБСТВЕННОГО моего сервера.

    Я бы рекомендовал вам прочитать этот замечательный ответ Жиля, где он предоставил ссылки на некоторые из ошибок.

    В Debian (274229, 330882, 581899) обнаружены ошибки, которые в настоящее время открыты и классифицируются как «список пожеланий». Я склонен согласиться с тем, что это ошибки, и пользователи системы должны иметь / bin / false в качестве своей оболочки, если не представляется необходимым сделать это иначе.

    Чтобы добавить к отличным ответам @slm и @ramesh:

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

    1. Войдите в систему как другой пользователь, у которого есть действительная оболочка
    2. У вас есть разрешения sudo для этого пользователя для запуска команды su и
    3. Если бы ваша попытка была зарегистрирована в журнале sudoers (при условии, конечно, что sudo logging включен).

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

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

    Ошибка безопасности в службе, запущенной как ограниченный пользователь, позволяет писать файл в качестве этого пользователя. Этот файл может быть ~ / .ssh / authorized_keys.

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

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

    В дополнение к отличным ответам, которые были даны, это служит другой цели.

    Если вы запустите FTP-сервер на своем сервере, он проверяет оболочку входа пользователей, которые пытаются войти в систему. Если оболочка не указана в /etc/shells , она не позволяет им входить в систему. Поэтому предоставление учетным записям демона специальной оболочки запрещает кому-то изменять учетную запись через FTP.

    В общем, я бы сказал, что / bin / false и / sbin / nologin одинаковы – но я полагаю, это зависит от того, какой SSH-сервер вы используете.

    Было бы разумно отметить, что недавний эксплойт на OpenSSH влияет на логические / bin / false логины, но NOT / sbin / nologin. Однако он утверждает, что Dropbear отличается таким образом (также эксплойт специально применяется к OpenSSH).

    Exploit влияет на большинство версий:

    7.2p1 и ниже (все версии, начиная с 20 лет) С включенной пересылкой X11

    https://www.exploit-db.com/exploits/39569/

    Поэтому, основываясь на этом, я лично сделал / sbin / nologin, однако я не уверен, что это может повлиять на службы, которые создают запись / bin / false в / etc / passwd. Вы можете экспериментировать и видеть свои результаты, но, пожалуйста, сделайте это на свой страх и риск! Я предполагаю, что в худшем случае вы можете просто изменить его и перезапустить любые службы (-ы). У меня лично есть довольно много записей с помощью / bin / false. Не уверен, хочу ли я беспокоиться об этом, поскольку пересылка X11 – это не то, что я разрешил;)

    Если вы используете OpenSSH (многие люди, я думаю …) И включили переадресацию X11 – вы можете рассмотреть / sbin / nologin (или, возможно, переключиться на Dropbear).

    Как правило, хорошая практика безопасности – устанавливать учетные записи служб и приложений для неинтерактивного входа. Уполномоченный пользователь может по-прежнему иметь доступ к этим учетным записям с использованием SU или SUDO, но все их действия отслеживаются в файлах журнала Sudoers и могут быть прослежены до пользователя, выполнившего команды под привилегиями учетной записи службы. Вот почему важно хранить файлы журналов в централизованной системе управления журналом, чтобы системные администраторы не имели доступа к файлам журналов изменений. Пользователь, выполняющий команды под SU или SUDO, уже имеет право доступа к системе.

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

    Linux и Unix - лучшая ОС в мире.