Чи / 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/InstallingTomcat.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 для облікового запису демон та входу через ssh. Потім деякі локальні кореневі експлуатації використовувались для власного власного сервера.

Я рекомендую вам прочитати цю чудову відповідь Гілла, де він також надав посилання на деякі помилки.

У цій програмі Debian (274229, 330882, 581899) є помилки, які наразі відкриті та віднесені до списку бажань. Я схильний погоджуватися, що це помилки, і користувачі системи повинні мати / bin / false як свою оболонку, якщо не видається необхідним робити інше.

Щоб додати до чудових відповідей @slm та @ramesh:

Так, як ви вже вказували, ви все одно можете переходити до користувачів, які мають нологін, як оболонку за замовчуванням, запускаючи sudoз визначеною оболонкою, але в цьому випадку вам довелося:

1. Увійдіть як інший користувач, який має дійсну оболонку
2. Встановіть права доступу sudo для цього користувача для запуску suкоманди та
3. Якби ваша спроба su увійшла до журналу sudoers (якщо, звичайно, ввімкнено ведення журналу sudoers).

Користувачі, у яких нологін визначений як їх оболонка за замовчуванням, часто мають більші привілеї / здатні нанести більше шкоди системі, ніж звичайний користувач, тому, не маючи змоги увійти безпосередньо, намагаються обмежити шкоду, яку може зазнати порушення вашої системи. .

Окрім відмінних відповідей, які були надані, це слугує ще одній цілі.

Якщо ви запустите демон FTP на своєму сервері, він перевіряє оболонку входу користувачів, які намагаються увійти. Якщо оболонка не вказана в списку /etc/shells, вона не дозволяє їм увійти. Отже, надання демоновим обліковим записам спеціальної оболонки не дозволяє комусь змінювати рахунок через FTP.

Поруч із вже даними чудових відповідей, я можу придумати наступний сценарій.

Помилка безпеки в службі, що працює як обмежений користувач, дозволяє записати файл як цей користувач. Цей файл може бути ~ / .ssh / autorizirane_keys.

Це дозволяє зловмиснику входити безпосередньо в оболонці, що значно полегшить виконання ескалації привілеїв.

Вимкнення оболонки для входу ускладнить цю опцію набагато складніше.

Як правило, я б сказав, що / bin / false та / sbin / nologin однакові - але я вважаю, що це залежить від того, який SSH-сервер ви використовуєте.

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

Exploit впливає на більшість версій:

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 , в якій зловмисник вставляє відкритий ключ SSH у вашу базу даних Redis, потім надсилає команду, яка каже Redis, щоб записати вміст бази даних .ssh/authorized_keys, а потім намагається в SSH. Мене врятували від наслідків моєї власної некомпетентності лише тим, що redis-serverтехнічні працівники пакету Apt (який я використовував для встановлення Redis) мали мудрість змусити його запускати Redis якredisкористувач, який не має домашнього каталогу або оболонки для входу; якби не вони, мій сервер, швидше за все, був би покупований або перетворився на частину ботнету якогось хакера.

Цей досвід дав мені певну ступінь смирення і змусив мене глибоко оцінити важливість захисту , і, зокрема, не надавати оболонки для входу в облікові записи, на яких працюють веб-сервери, бази даних та інші довідкові послуги.