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

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

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

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

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

Помимо отличных ответов, которые были даны, он служит еще одной цели.

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

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

выдержка

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

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

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

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

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

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

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

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

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

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

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

Мой сервер Debian был скомпрометирован из-за учетной записи демона, имеющей Допустимый вход в систему оболочки и наличие Samba Open для доступа в Интернет. Перерыв был сделан путем установки пароля удаленного через Samba для демона учетная запись и вход через SSH. Какой-то локальный корневой эксплуататор был Затем используется для владения моим сервером.

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

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

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

Ошибка безопасности в сервисе, работающем в качестве ограниченного пользователя, позволяет написать файл как пользователь. Этот файл может быть ~ / .ssh / aperized_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 в ~/.ssh/authorized_keys, затем войти по SSH и -бум! -у них есть доступ к вашему серверу через оболочку.

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

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

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