Чому логін root через SSH такий поганий, що всі радить його відключити?

83

Усі в Інтернеті радять відключити кореневий вхід через SSH, оскільки це погана практика та безпека в системі, але ніхто не пояснює, чому це так.

Що таке небезпечне у ввімкненні кореневого входу (особливо з вимкненим входом пароля)?

І чим відрізняється ім'я користувача X-символу від пароля або кореневого імені користувача символу Y та пароля символу X + Y з точки зору безпеки у випадку, якщо автентифікація пароля дозволена?

ssh security root

— поспішати
джерело

2

Бути користувачем root у більшості систем погано само по собі, залишити в спокої можливість входу в SSH для вказаного користувача!

— Суман

1

Кореневий логін через ssh необхідний для ehealth-aussie.blogspot.com/2012/01/… . Все - це компроміс.

— emory

2

Гм ... чи варто перенести це питання на безпеку? Оскільки тема більше схиляється до безпеки, то система * nix.

— Брайам

Існує адміністративна причина відключення root. На комерційних серверах ви завжди хочете контролювати доступ особисто. корінь ніколи не є людиною. Навіть якщо ви дозволяєте деяким користувачам мати root-доступ, ви повинні змусити їх увійти через власного користувача, а потім su -або sudo -iтак, щоб їх реальний логін міг бути записаний. Це значно спрощує скасування доступу до окремої людини, так що навіть якщо вони мають корінний пароль, вони нічого не можуть з цим зробити.

— Філіп Кулінг

62

Чому корінь над SSH поганий

Там багато ботів, які намагаються увійти на свій комп’ютер через SSH. Ці боти працюють наступним чином.

Вони виконують щось на кшталт, ssh root@$IPа потім намагаються стандартні паролі, такі як "root" або "password123". Вони роблять це до тих пір, поки можуть, поки не знайдуть потрібний пароль. На доступному в усьому світі сервері ви можете бачити безліч записів у ваших журнальних файлах. Я можу піти до 20 за хвилину і більше.

Коли зловмисникам пощастить (або достатньо часу) і знайдуть пароль, вони отримають кореневий доступ, і це означатиме, що ви потрапили в біду.

Але коли ви забороняєте root входити через SSH, боту потрібно спочатку відгадати ім’я користувача, а потім відповідний пароль. Тож скажемо, що список правдоподібних паролів містить Nзаписи, а список правдоподібних користувачів - Mзаписи великі. У бота є набір N*Mзаписів для тестування, тому це робить його трохи складніше для бота порівняно з кореневим випадком, коли він є лише набором розміру N.

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

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

У коментарях зазначалося, що звичайний користувач може мати право користуватися, sudoі якщо здогадатися, що пароль цього користувача, система теж повністю втрачена.

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

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

Чому паролі через SSH погані

Причина відключення паролів дійсно проста.

Користувачі вибирають неправильні паролі!

Вся ідея спробувати паролі працює лише тоді, коли паролі можна вгадати. Тож, коли у користувача є пароль "pw123", ваша система стає незахищеною. Ще одна проблема паролів, обраних людьми, полягає в тому, що їх паролі ніколи не бувають справді випадковими, тому що їх важко запам'ятати.

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

Але коли ви використовуєте сертифікат для входу, користувач не вибирає свій пароль. Сертифікат ґрунтується на випадковій рядку, який є дуже довгим від 1024 Біт до 4096 Біт (~ 128 - 512 символьних пароля). Крім того, цей сертифікат існує лише для того, щоб увійти на ваш сервер і не використовується з будь-якими сторонніми службами.

Посилання

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

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

— Рафаель Аренс
джерело

10

Гарне резюме. Але приватні ключі ssh також можуть бути вкрадені.

— Faheem Mitha

16

@Faheem Mitha Так, але вкрадене відрізняється від здогаданого, що роблять боти. Також ваш приватний ключ знаходиться лише у ваших руках (або на жорсткому диску), а не в руках таких сторонніх осіб, як Stack Exchange або Google.

— Рафаель Аренс

2

+1. Ця відповідь насправді може звестись просто N*M > N. Оскільки більшість хостів * nix мають rootкористувача, якщо ви дозволяєте root входити безпосередньо з віддаленого хоста, розмір тестової матриці - кількість паролів, які слід спробувати; забороняючи прямі кореневі входи, кількість можливих комбінацій множиться на кількість імен користувачів, які ви хочете протестувати (і досі немає гарантії, що ви будете тестувати дійсні імена користувачів!).

— CVn

3

@ MichaelKjörling Я додам, що отримати ім'я користувача не важко, оскільки зазвичай ім'я користувача не є секретом, і я, мабуть, міг би попросити когось там. Але це допомагає проти ботів і простої спроби.

— Рафаель Аренс

2

@ Кожен, якщо ім'я користувача має символи X та пароль Y, можна спробувати # of X length words* # of Y length wordsможливі комбінації. Якщо ім’я користувача встановлено (наприклад, root), але пароль має символи X + Y, # of X+Y length wordsможливі паролі. І # of X+Y length words=# of X length words * # of Y length words

— скарап

10

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

Брутфорс спроби. Прямий вхід в корінь може призвести до більшої шкоди при успішній атаці грубої сили.
Missconfiguration на "безпарових" ключах SSH (трапляється помилка людини) може піднести вашу машину до Інтернету

Але це лише ТІПА айсберга. Вам потрібно налаштувати інші обмеження та конфігурації, такі як:

Змінити порт за замовчуванням (22)
Сильні паролі та пароль
Вимкнути автентифікацію на основі хоста
Створіть список дозволених користувачів
Налаштування часу очікування
Примусовий протокол SSHv2
Вимкнути порожні паролі
Використовуйте fail2ban як міру проти грубої сили
Пропишіть все
Налаштуйте ключі SSH та довіряйте лише відкритим ключам на .ssh / autorizirani_keys

5

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

— CVn

@ MichaelKjörling - Так, точно, що заплутане судо може бути таким же шкідливим, як PermitRoot;)

Дивіться unix.stackexchange.com/a/2944/9454

— Martin Schröder

1

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

— 0xC0000022L

+1 за згадування fail2ban, оскільки жорстокі напади викликають не тільки проблему SSH, а й усе інше на машині. Вам не потрібно ніде отримувати кореневі чи системні дозволи для "захоплення" машини для практичних цілей (доступ до приватних даних, використання як дамп файлів, використання для фішингу тощо).

— Ерік Ґрандж

8

Ви праві, що ім'я користувача root та пароль символу X + Y криптографічно принаймні настільки ж захищені, як ім’я користувача X символу + пароль символу Y. Насправді це ще безпечніше, тому що імена людей легко здогадатися (боти можуть просто спробувати Джона, Майка, Білла тощо ... та btw: саме це багато хто робить, а не намагатися викорінити). І вам особливо не пощастить, якщо це цілеспрямована атака, тому що якщо хтось хоче зламати сервер компанії, це не буде проблемою, щоб дізнатися ім'я (нік) sysadmin.

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

Це будь-який тип кореневих логінів, які з точки зору безпеки вважаються (або повинні) вважатися поганими практиками. "Нормальний" вхід користувача -> su / sudo ланцюг додає аудиторський слід. Простий англійською мовою: це дозволяє з’ясувати, хто що робив.

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

— скарап
джерело

4

Що таке небезпечне у ввімкненні кореневого входу (особливо з вимкненим входом пароля)?

Зловмиснику (бот / ботнету / хакеру) потрібно лише вгадати пароль і мати повний контроль над вашою системою, якщо ви відкриті для Інтернету. Також жоден із системних облікових записів (www-data, proxy тощо) не повинен мати змогу входити через SSH з тих же причин.

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

І чим відрізняється ім'я користувача X-символу від пароля або кореневого імені користувача символу Y та пароля символу X + Y з точки зору безпеки у випадку, якщо автентифікація пароля дозволена?

Додаткове ім'я користувача може додати рівень безпеки, оскільки: а) зловмисник повинен знати і пару, і ім’я користувача та пароль; б) у випадку, якщо зловмисник порушить вашу систему, він не матиме негайного доступу до привілейованого облікового запису, додавши трохи нюансу для зловмисника.

У цьому випадку відкритий ключ також є плюсом, оскільки:

Зловмиснику потрібен ваш відкритий ключ
Зловмиснику потрібен пароль (або метод аутентифікації), щоб отримати підвищені привілеї

— Браям
джерело

1

Дуже мало паролів, які я використовую, менше ніж приблизно 20 випадкових буквено-цифрових символів (набір [A-Za-z0-9] плюс кілька спеціальних символів). 20 таких символів (таким чином, довжина 20 з набору символів 40) дає вам на порядок 10 ^ 32 комбінації. 128 біт ентропії знаходиться на порядку 10 ^ 38. Немаловажна різниця, все, що враховано, і SSH-сервер вільний впроваджувати будь-які обмеження швидкості, що йому подобається, тому це не так, як ви робите офлайн-грубу атаку в такому випадку. З паролями немає нічого поганого, якщо ви можете жити з ними так само важко, як 128-розрядний ключ.

— CVn

@michael shh ... не дайте діапазону, тепер хакери знають, що вони повинні використовувати таблиці веселки порядку 20 символів довжиною ...?

— Брайам

6

@Braiam Rainbow таблиці корисні лише в тому випадку, якщо зловмисник має доступ до хешів для пошуку в офлайні. У випадку тут зловмисник має лише відповідь сервера на підтвердження проти, що, ймовірно, обмежується лише такою кількістю спроб - і набагато повільніше.

— Пітер

@ Peter ups, я переплутав і словник, і хеши, але в будь-якому випадку ОП запитав, чому він не повинен використовувати слабкі або порожні паролі, відьма смішна, тому я зіткнувся зі смішними ситуаціями, чому він не повинен. Вибачте, що мене не трактували таким чином і мене сприйняли як FUD.

— Брайам

2

Якщо ви хочете спробувати деякі паролі 1,8 * 10 ^ 35 (і це лише для діапазону 18-22 випадкових символів із набору 40, і ви не знаєте, які символи поза набором [A-Za-z0- 9] Я використовую), я майже сказав, весело. Це приблизно 117,1 біт еквівалента ентропії (2 ^ 117,1 ~ 1,78 * 10 ^ 35) і, як зазначав @Peter, вам, швидше за все, потрібно буде здійснити онлайн- атаку. Зберігання всіх цих паролів (не вдаючись до стиснення) виходить таким, що потребує приблизно 3,6 * 10 ^ 36 байт або 3 * 10 ^ 24 TiB (а якщо ця цифра помилкова на кілька порядків, кого це цікавить? ). Ключове слово випадкове .

— CVn

1

Це не зовсім погано, якщо ви дотримуєтесь заходів безпеки. Як приклад, ви можете встановити CSF (Налаштувати брандмауер сервера) і встановити йому кількість дозволених спроб відмови, тому якщо хтось спробував, скажімо, понад 5 спроб відмови ?, то вони автоматично блокуються. Таким чином, перша перша частина найкращого відповідача взагалі не буде проблемою. Це траплялося зі мною багато разів, і, на щастя, всі учасники були заблоковані назавжди. Я думаю, що для сервера це не велика проблема, якщо ви єдина людина, яка керує сервером, але, звичайно, якщо багато адміністраторів системи або якщо ви працюєте в організації, то, очевидно, не використовуйте корінь. Також для настільного ПК, мабуть, використовувати інший обліковий запис краще, оскільки є ризик для безпеки, оскільки ви використовуєте багато програмного забезпечення, але на сервері, ви не ' не йдіть за випадковим програмним забезпеченням, якому ви не довіряєте. Отже, висновок такий: Ні, це не дуже шкідливо, якщо ви знаєте, як правильно керувати сервером.

— Дон Діланга
джерело