Чому користувачеві «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? FYI, я вже /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), зловмисник повинен мати кореневий доступ до файлової системи, а це означає, що ви все одно перекручені.

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

Однак це виглядає так, що користувач bin не використовується в сучасних системах, що виробляються в Debian, і є суто киданням традицій або існує для дотримання деяких стандартів.