Зачем пользователю 'bin' нужна оболочка входа?

Во время аудита /var/log/auth.logодного из моих общедоступных веб-серверов я обнаружил следующее:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

На первый взгляд, это похоже на типичный sshспам при входе в систему от случайных хакеров; однако, когда я посмотрел ближе, я заметил кое-что еще. Большинство неудачных /var/log/auth.logзаписей говорят invalid userв них, как этот:

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

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

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

Я думал, что охватил все имена пользователей по умолчанию, которые могли входить удаленно, когда я отключился PermitRootLoginв /etc/ssh/sshd_config; обнаружение этой записи открыло новые возможности в моем параноидальном уме. Если каким-то образом службы запускались bin, то удаленно возможно, что кто-то мог каким-то образом вставить ключ ssh в binкаталог пользователя из запущенной службы на коробке, поэтому я хотел бы полностью отключить вход для binпользователя, если это возможно.

Вопросов

• Этот сервер является удаленным и дорогим в исправлении (т.е. я заплачу за удаленные руки, чтобы подключить KVM, плюс аренду KVM). Я пытаюсь выяснить, что я могу сломать, если я изменю /etc/passwdзапись, binчтобы она выглядела так:

  bin:x:2:2:bin:/bin:/bin/false

• Я выполнил следующие команды, пытаясь выяснить, для чего binэто нужно ... Однако эти команды не дали файлов, и я не смог найти процессы, которыми владеет bin. Что делает binпользователь в любом случае?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Есть ли какие-либо другие пользователи, которым нужно установить свои оболочки входа /bin/false? К вашему сведению, у меня уже есть /bin/falseна www-data.

• Я слишком параноик?

Я использую Debian, если это имеет значение.

Пользователь, у которого есть действующая оболочка и нет пароля, может по-прежнему входить в систему, не используя парольные методы, наиболее распространенным из которых является ключ ssh. Действительная оболочка необходима для запуска заданий cron. Для работы также необходима корректная оболочка su bin -c 'wibble'(по крайней мере, в Linux, su bin -s /bin/sh -c 'wibble'также будет работать).

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

Нет никакого риска любой прямой атаки, позволяющей binвойти через SSH, потому что это потребует создания /bin/.ssh/authorized_keysот имени пользователя binили от имени пользователя root. Другими словами, единственный способ войти - это войти. Однако наличие действительной оболочки увеличивает риск неправильной конфигурации. Это может также разрешить некоторые удаленные атаки с сервисами, отличными от SSH; например, пользователь сообщает, что злоумышленник может установить пароль для daemonудаленного доступа через Samba, а затем использовать этот пароль для входа через SSH.

Вы можете закрыть дыру в SSH, перечислив имена системных пользователей в DenyUsersдирективе /etc/ssh/sshd_config(к сожалению, вы не можете использовать числовой диапазон). Или, наоборот, вы можете поместить AllowGroupsдирективу и разрешить только группы, которые содержат физических пользователей (например, usersесли вы предоставляете всем своим физическим пользователям это членство в группе).

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

Вам не нужно беспокоиться о них как о пользователях. Они являются «пользователями» в смысле групп безопасности, а не пользователями в смысле «входите и пользуйтесь» людьми. Если вы посмотрите в «/ etc / shadow», то увидите, что все эти «пользователи» не имеют паролей («x» или «!» Вместо длинного соленого хэша). Это означает, что эти пользователи не могут войти, несмотря ни на что.

Тем не менее, я не знаю, будет ли хорошей идеей изменить "/ bin / sh" на "/ bin / false" для всех этих пользователей. Поскольку программы выполняются в этих группах, это может не позволить им выполнять команды, которые им необходимы. Я бы оставил их как "/ bin / sh".

Вам не нужно беспокоиться об этих пользователях. Беспокойство касается только тех пользователей, которых вы создаете (и тех, у кого есть хэши в "/ etc / shadow")

Я полагаю, что это не проблема, поскольку для установки открытого ключа SSH в binдомашнем каталоге ( /bin) злоумышленнику необходимо иметь root-доступ к файловой системе, что означает, что вы все равно испорчены.

Если хотите, вы можете отключить все методы аутентификации для binпользователя в конфигурации sshd, используя MatchUserблок.

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