Чи відключення кореневого входу підвищує безпеку?

Нещодавно я знайшов аргумент проти відключення кореневого користувача в системі Linux на веб-сайті http://archives.neohapsis.com/archives/openbsd/2005-03/2878.html

Я припускаю, що якщо всі використовують автентифікацію відкритого ключа, немає ризику втратити кореневий пароль.

Чи завжди краще відключити кореневий логін через ssh?

Коротка відповідь полягає в тому, що чим менше ваш напад, тим краще. Завжди. Якщо він вам не потрібен або ви можете використовувати таку альтернативу, як sudo або su, тоді не вмикайте кореневий вхід.

Одним з великих аргументів на користь відключення root та використання sudo / su є те, що ви можете відстежувати, хто що робить. Один користувач - один логін. Ніколи не діліться акаунтами.

Аргумент на цьому посиланні здається специфічним для локального входу, а не ssh.

I другий бал Денніса, плюс:

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

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

Ніколи не вимикайте кореневий обліковий запис, якщо у вас немає доступу до консолі. Якщо ваша файлова система заповнюється, а завантажувач не спрацьовує під час створення / etc / nologin, в машину буде входити лише кореневий обліковий запис.

Однак, якщо у вас є доступ до консолі для вирішення цих ситуацій, закриття кореневого облікового запису може врятувати вам головні болі, оскільки ніхто не зможе потрапити до кореневого облікового запису за допомогою атаки словника (мій досвід полягає в тому, що вони постійні в ці дні - хтось завжди намагається). Інші речі, про які ви можете подумати:

• Встановіть таку програму, як fail2ban, яка автоматично закриває доступ до IP-адреси, якщо вона більше ніж кілька разів не дає змоги перевірити автентифікацію (для активного захисту від атак на словники).
• Використовуйте лише ключі ssh.
• Якщо ви керуєте багатьма машинами, використовуйте cfengine або інше, щоб керувати відкритими ключами, дозволеними вводити машину (інакше ви досить швидко застаріли).

З найкращими побажаннями,
Жоао Мігель Невес

Завжди краще відключити кореневий вхід через SSH.

Є системи PKI (наприклад, відкриті ключі з SSH), які були порушені. Раніше SSH вже мали недоліки віддаленої автентифікації, що дозволило статися з кореневим компромісом. Програмні ПКІ, як відомо, слабкіші за апаратні ПКІ .... якщо ваш хост-комп'ютер порушений, цільовий сервер також може легко впасти. Або можуть бути нові недоліки, виявлені в SSH. Обмеживши кореневий логін, ви також можете продовжити період часу, якому зловмисник потребує, щоб здійснити ескалацію привілеїв.

Історично багато адміністраторів використовували хости бастіонів (в основному шлюзи) для того, щоб увійти в мережу, а потім перейти до вікон. Використання високого захищеного дистрибутива (наприклад, OpenBSD) в якості хоста бастіону в поєднанні з різними операційними системами забезпечує глибоку оборону та різноманітність оборони (одна вразливість рідше загрожує всій мережі).

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

Оскільки я параноїк і в безпеці, я з більшою ймовірністю використовую IPSEC VPN або Type1 VPN, а потім запускати SSH поверх нього, без будь-якого опромінення SSH в Інтернеті. Розміщення VPN на вашому мережевому апаратному забезпеченні може значно спростити це в реалізації.

Нам слід вивчити це питання з різних точок.

Ubuntu за замовчуванням відключає кореневий обліковий запис, це означає, що ви не можете ввійти через SSH з root. Але це дозволяє кожному, хто має компакт-диск Ubuntu, може завантажуватись та отримувати кореневий доступ.

Я вважаю, що найкращим компромісом є включення кореневого облікового запису з вимкненим SSH-доступом. Якщо вам потрібен кореневий доступ із SSH, увійдіть із звичайним користувачем та використовуйте sudo. Таким чином він забезпечує доступ до коробки, не заважаючи віддаленій безпеці.

Я б сказав, що так, вхід як root повинен бути вимкнено для перевірки. Якщо ви єдиний системний адміністратор на цій машині, неважливо визначити, хто що робив кому, але якщо десять людей мають право адмініструвати вікно, і всі вони знають кореневий пароль, у нас є проблема.

Увімкнено чи ні root, ні root, ні будь-який інший користувач не повинен дозволяти віддалено входити з паролем. fail2ban нічого не зробить проти повільного ботнету з грубою силою і зовсім не працює з IPv6. (Протокол ssh версії 1 та старіші версії версії 2 були вразливими до атак наведення пароля на інтерактивні запити пароля протягом сеансу ssh, але, здається, це вже не так у випадку досить недавньої реалізації ssh.)