Відповіді:
На всіх моїх серверах вимкнено кореневий рахунок ( sp_pwdpвстановлено *). Це потрібно sudoдля всього кореневого доступу. [1] Метою цього є проведення всіх аудиторських заходів аудиту, щоб люди могли бачити, що зроблено з системою.
Для більш жорсткого варіанту ви можете зробити sudoзапис у файл журналу (на відміну від syslog) та зробити файл доданим лише (за допомогою chattrLinux або chflagsBSD). Таким чином, ніхто не може потім редагувати аудит.
[1] У мене також є політика не запускати кореневу оболонку або виконувати втечу з оболонки кореневого процесу. ( sudo sh -c '...'Однак це добре використовувати для здійснення конвеєрів або перенаправлень.)
Я настійно рекомендую не відключати користувача root. Вимкнення або обмеження кореневих логінів (через securetty і через sshd_config і через PAM і через те, що у вас є) Якщо ваша система дозволяє, обмежте привілеї root або розділіть кореневу роль (схоже на те, як це робить RSBAC .) Але, будь ласка, будь ласка , зробіть не вимикайте кореневий рахунок, видаливши пароль, інакше ввійти в систему через систему стане неможливо sulogin. suloginвикористовується всіма мені відомими initscripts у разі серйозних помилок, про які повідомляє fsck - і це означає, що ви будете заблоковані з системи, якщо пошкоджена коренева файлова система.
Для уточнення: "Відключення кореневого облікового запису шляхом видалення пароля" я маю на увазі різні механізми, які закінчуються символом a! або * у полі пароля / etc / shadow або подібне. Я не маю на увазі "змінити механізм кореневого входу, щоб ви не запросили пароль".
suабо sudoу вашій системі доступна для користувачів означає більше ризиків для безпеки, яких ви можете уникнути, якщо у вас є лише спеціальні користувачі root. Це позиція, яку відстоюють автори захищеної дистрибуції Owl (і Сонячний дизайнер серед них) - unix.stackexchange.com/questions/8581/… намагається представити свою позицію посиланнями.
fastbootможливістю, розблокувати кореневий рахунок та перезапустити, щоб нарешті запустити fsckвручну.
У мене активовано кореневий рахунок на всіх моїх серверах. Усі адміністратори мають свого власного користувача та мають увійти через це. Звідти вони переходять на корінь. (root ssh вимкнено)
Тримайте кількість адміністраторів низькою. Тільки люди, яким дійсно потрібен кореневий доступ на цьому сервері, мають пароль.
Я не шанувальник судо. Це занадто просто, щоб просто зробити "sudo bash" для кореневої оболонки. Я знаю, що це можна відключити, але чому це турбувати? Просто обмежте користувачів, які можуть виконувати завдання адміністратора та спілкуватися з іншими. У нас є політика, щоб не дозволяти кореневим терміналам відкриватися без нагляду. Отже, увійдіть, су, виконайте роботу, вийдіть із системи.
Примітка. Я працюю в досить невеликій компанії (50 співробітників), і ми обходимось лише з двома адміністраторами за сумісництвом (1 windows / 1 linux). Такий спосіб роботи може виявитися не найкращим, коли у вас на замовлення більше користувачів. Я особисто все ще не користувався б судо. Є й інші способи реєстрації кореневої активності.
Відключення кореневого пароля - це хибна "добра ідея". Дня, коли він вам знадобиться, він вам справді знадобиться. (відповідно до вашої конфігурації вам може знадобитися вхід в єдиний користувальницький режим для зразка)
Відключення кореневого віддаленого входу може бути релевантним, але лише в тому випадку, якщо ви можете ввійти локально.
І так, sudo має встановлюватися на кожному з ваших серверів. Це корисно і легко налаштувати. Чому б ви хотіли не використовувати його?
Disabling root remote login might be relevant but only if you are able to log on locally.Це просто відверто хибно. Ви можете ввійти дистанційно в будь-який обліковий запис; відключення кореневого віддаленого входу не обмежує локальний доступ.
Я просто відключаю доступ SSH для root та вимагаю від користувачів (часто це просто розробники) використовувати ключі ssh. Занадто багато атак на словник, а зміна порту SSH - це не варіант для нас.
Таким чином, вам не доведеться вірити ні в кого вміння написати хороший пароль. Потрапивши всередину, лише адміністратори мають дозволи на судо.
Я знаю, що ця тема справді стара, але є деякі основні вади в логіці пов'язаних статей, і я відчуваю себе "rant'ie" - sudo дозволяє як білі списки, так і чорні списки. Не просто чорний, як вони вказані у зв'язаній статті - Це пропускає ідею AAA (автентифікація, авторизація та аудит) - su & sudo дозволяють як ступінчасту аутентифікацію, так і підзвітність.
Сценарій 1 Адміністратор випадково вводить у систему якийсь шахрайський код, увійшовши як root, код має повний доступ, і адміністратор ніколи не може знати, що сталося. Принаймні з градуйованими входами (наприклад, su / sudo) адміністратору буде запропоновано підтвердити автентифікацію, якщо негідний код намагається використовувати підвищені права ... Якщо він не підвищує, то його обмежені права користувачів, що може призвести до мінімального збитку.
Сценарій 2 Адміністратор шахраїв хоче отримати інформацію / внести зміни. Вони підключаються до консолі (доступ до фізичної консолі, HP iLo / подібний або доступ до консолі vGuest), входять як root і роблять все, що завгодно. Якщо немає іменованого облікового запису / картки доступу, що використовується для отримання доступу до консолі, ймовірно, слід не багато.
Ви повинні вимагати від усіх використовувати sudo для кожної кореневої команди як політику. Ніколи не виникає причин запускати "судо баш" або подібне, це лише для зручності, через незнання або для того, щоб прикрити свої доріжки.
Якщо ви відключите вхід до кореневого облікового запису безпосередньо, ви калічите свою здатність виправляти систему, коли виникають серйозні проблеми.
Якщо ви не можете переконати своїх адміністраторів увійти як самі та запустити sudo для кожної команди, що запускається як root, і не вирватися з неї в оболонку, у вас є серйозні проблеми, для яких немає технічного рішення.
Автори захищеної дистрибуції Owl (та дизайнер Solar) мають протилежну ретельно обґрунтовану точку зору; див., наприклад, відповідь /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 для презентація своїх вимог. Проблема аудиту дій суперпользователя (яка людина зробила що) також вирішується в їхній точці зору (в основному, рішення полягає в тому, щоб мати декілька кореневих користувачів з різними іменами).