Sbin nologin что это

В чем разница между /sbin /nologin и /bin /false?

Я вижу на странице man, что /sbin/nologin печатает сообщение пользователю, говоря, что учетная запись отключена, а затем завершает работу. Предположительно /bin/false ничего не печатает.

3 ответа

POSIX (хотя я могу ошибаться, и это может быть SUS) ограничивает обе эти команды только тем, что возвращает только соответствующее логическое значение.

В любом случае scp не будет работать с недопустимой оболочкой. scponly может использоваться как оболочка в этом экземпляре.

После некоторых исследований по этому методу используемый вами метод зависит от того, что вам нужно заблокировать. Если пользователь входит в систему с этим набором в оболочку, тогда они получат сообщение, отображаемое с эффектом This account is currently unavailable. Обратите внимание, что вы можете изменить это, создав файл /etc/nologin.txt по крайней мере на производных RHEL.

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

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

Um, попросил ли кто-нибудь попробовать доказать, что /bin /false запретит доступ к FTP?

Я только что изменил оболочку моего пользователя на /bin /false и смог полностью FTP.

Я использую /dev /null для полностью блокирует пользователя (ну, кроме электронной почты, они могут по-прежнему POP3).

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

Можно ли обойти /sbin/nologin?

Модератор: Bizdelnick

Можно ли обойти /sbin/nologin?

Re: Можно ли обойти /sbin/nologin?

Сообщение Bizdelnick » 06.05.2016 14:24

Re: Можно ли обойти /sbin/nologin?

Сообщение SLEDopit » 07.05.2016 00:03

Насколько я понимаю, ssh daemon при попытке подключения по ssh запускает шелл, прописанный в качестве login shell’a, а тот уже дальше решает что делать: либо запускать ещё одну копию самого себя и передавать туда управление, либо запускать указанную команду.
Поэтому, если в качестве логин шелла что-то типа nologin или /bin/false, то до выполнения команды / другого шелла тупо не доходит.

Источник

Способы ограничения возможности входа пользователей в Ubuntu

Вступление

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

Данное руководство описывает основные понятия об управлении пользователями и регистрации их авторизации.

Эти понятия изучаются на Ubuntu 12.04 VPS, но данные действия можно выполнить на любом современном дистрибутиве Linux.

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

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

Как ограничить доступ с помощью /etc/passwd

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

Примером этому является пользователь «messagebus» в файле «/etc/passwd»:

less /etc/passwd | grep messagebus
messagebus:x:102:104::/var/run/dbus:/bin/false

последнее значение – это оболочка или команда, которая запускается в случае успешного входа. Сейчас это «/bin/false».

Если войти в учетную запись messagebus как root-пользователь, ничего не произойдет, так как переключиться на этого пользователя не получится:

sudo su messagebus

Попробуйте переключиться на пользователя sshd:

sudo su sshd
This account is currently not available.

Это уведомление появилось потому, что оболочка пользователя sshd помещена в «/usr/sbin/nologin».

less /etc/passwd | grep sshd
sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin

Итак, как же ограничить вход пользователей с помощью этих методов?

Нужно использовать инструмент «usermod», изменяющий легитимное значение оболочки фиктивным:

Как ограничить вход с помощью /etc/shadow

Другой подобный способ ограничения доступа – использование файла «/etc/shadow». Данный файл содержит хешированные пароли каждого пользователя системы.

Чтобы просмотреть хешированные пароли, введите:

Второе поле (которое начинается с «$6$r79Dod3Y#3…» в первой строке) содержит хешированное значение пароля.

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

Значение пароля можно деактивировать (сделав его, по сути равным значению «*»), установив перед хешированным значением восклицательный знак (!).

Два инструмента могут заблокировать указанную учетную запись.

Команда passwd может быть заблокирована с помощью флага «-l» и разблокирована флагом «-u»:

Учетная запись может быть разблокирована при помощи:

Подобные операции можно выполнить при помощи команды «usermod», которая использует флаги «-L» и «-U» для блокировки и разблокировки соответственно.

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

Как ограничить вход с помощью /etc/nologin

В экстренных ситуациях бывает необходимо запретить вход всем аккаунтам, кроме root.

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

В любом случае, это легко сделать, создав файл «/etc/nologin»:

sudo touch /etc/nologin

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

Пустой файл просто сбрасывает пользователей обратно в локальную оболочку без объяснения причин.

Дело в том, что пользователю просто возвращается содержимое файла. Если добавить в файл сообщение, то пользователи получат объяснение ошибки входа:

Попробуйте войти в систему с помощью пароля, тогда будет выведено установленное сообщение:

ssh user@host
user@host’s password:
Planned maintenance. Log in capabilities will be restored at 1545 UTC
Connection closed by host

Root-пользователь по-прежнему может войти в систему. Чтобы отменить ограничения входа, просто удалите файл «/etc/nologin»:

sudo rm /etc/nologin

Итоги

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

Источник

Управление учетными записями пользователей в Linux: создание и удаление пользователя

Как известно Linux есть многопользовательские системой, где может одновременно существовать и работать несколько пользователей. Все пользователи имеют своей установленный уровень доступа к файлам системы.

В этой инструкции разберем основные команды для работы и управление пользователями в системе c Linux.

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

Пользователи

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

— утилита adduser

Начнем с добавления нового пользователя с помощью утилиты adduser. Общий синтаксис утилиты таков:

adduser [options] [user_name]

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

Дальше система предложит задать свой пароль для входа (как корректно подобрать пароль для учетной записи можно ознакомиться в нашей статье здесь). Следующий шаг ввод личных данных, этот пункт есть необязательным и можно пропустить, просто нажимая Enter. В конце система переспросит, есть ли правильными все введенные данные, чтобы продолжить и подтвердить просто вводим символ Y.

Утилита имеет следующий синтаксис:

useradd [options] [user_name]

Чтобы создать пользователя и сразу домашний каталог пользователя в директории /home/user_name используем опцию -m.

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

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

Информация обо всех пользователях хранится в файле /etc/passwd, чтобы вывести список пользователей и краткие сведения о них можно вбить в терминале команду:

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
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
sync:x:4:65534:sync:/bin:/bin/sync
syslog:x:101:104::/home/syslog:/bin/false
messagebus:x:103:107::/var/run/dbus:/bin/false
bind:x:104:111::/var/cache/bind:/bin/false
dovecot:x:106:115:Dovecot mail server. /usr/lib/dovecot:/bin/false
dovenull:x:107:116:Dovecot login user. /nonexistent:/bin/false
landscape:x:108:117::/var/lib/landscape:/bin/false
sshd:x:109:65534::/var/run/sshd:/usr/sbin/nologin
masha:x:1000:1000. /home/masha:/bin/bash
maria:x:1001:1001::/home/maria:/bin/bash

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2p1 и ниже (все версии; возраст

20 лет) с включенной переадресацией X11

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

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

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

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

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

Теперь ваш злоумышленник может записать открытый ключ

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

Источник