Служит ли / 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/InstallTomcat.html

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

От какой атаки мы пытаемся защитить себя, не предоставляя этим пользователям настоящие логины?

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

выдержка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, уже авторизован для доступа к системе.

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

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

Основная причина, по которой он служит цели, состоит в том, что существуют различные программные компоненты, которые проверяют некоторую форму учетных данных для входа для указанного пользователя, а затем используют оболочку входа этого пользователя для запуска команды. Возможно, наиболее заметным примером является SSH. Если вы успешно аутентифицируетесь как пользователь по SSH, SSH затем запускает оболочку входа пользователя (или использует ее для запуска предоставленной вами команды, если вы используете ssh someuser@example.com 'command to run'синтаксис).

Конечно, в идеале злоумышленник вообще не сможет аутентифицироваться как пользователь. Но предположим, что происходит следующая ситуация:

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

Теперь ваш злоумышленник может записать открытый ключ ~/.ssh/authorized_keysSSH, затем SSH и - бум! - у них есть доступ к вашему серверу.

Если вместо этого пользователь использует в /usr/sbin/nologinкачестве оболочки входа в систему, то даже после того, как злоумышленник успешно запишет открытый ключ authorized_keys, он не будет им полезен. Все, что он может сделать, это запустить удаленно nologin, что не очень полезно. Они не могут получить снаряд, и их атака была смягчена.

Если этот сценарий кажется очень гипотетическим, я хотел бы отметить, что именно эта атака была направлена именно на меня в 2015 году, примерно через год после того, как я задал этот вопрос. Как чертов идиот, я оставил экземпляр Redis без пароля для открытого мира. Он был атакован атакой Redis Crackit , в ходе которой злоумышленник вставляет открытый ключ SSH в вашу базу данных Redis, затем отправляет команду, сообщающую Redis о необходимости записи содержимого базы данных .ssh/authorized_keys, а затем пытается войти в SSH. Я был спасен от последствий моей собственной некомпетентности только из-за того, что сопровождающие redis-serverпакета Apt (который я использовал для установки Redis) имели мудрость, чтобы заставить его запускать Redis какredisпользователь, у которого нет домашней директории или логина; если бы не они, мой сервер, скорее всего, был бы выкуплен или оказался бы частью ботнета какого-то хакера.

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