Аутентифікація та авторизація

В сучасних дистрибутивах Linux за перевірку повноважень користувача відповідає підсистема PAM (Pluggable Authentication Module) — гнучкий механізм, який підтримує різні способи аутентифікації. Наприклад, при вході користувача пароль може перевірятися як локально (файли /etc/passwd та /etc/shadow), так і за участю зовнішніх сервісів (LDAP, ключі SSH та інших). Вибір залежить від конфігурації PAM та налаштувань адміністратора системи. Коли перевірка успішно пройдена, для користувача встановлюється сеанс з відповідними правами.

Упевнений, ви й без мене це знаєте, але давайте повторимо ще раз.

• Аутентифікація — це процес підтвердження особи користувача. Система удержається, що він — насправді той, за кого себе видає. Для цього потрібні облікові дані — наприклад, пара логін-пароль або криптографічний ключ.
• Авторизація — це процес надання прав доступу після успішної аутентифікації. Тепер система вирішує, що саме користувач може робити: які файли читати та команди виконувати, а також встановлює для нього інші подібні дозволи та обмеження.

Типи аутентифікації

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

Парольна аутентифікація

Це класичний спосіб входу в систему. Указуючи свій логін, користувач як би говорить ОС: «Привіт! Я…». Далі він надає докази, вводячи пароль. І при локальному доступі, і при віддаленому процес парольної аутентифікації практично ідентичний. Несуттєва відмінність — інтерфейс для введення облікових даних: це може бути GUI-форма або термінал. У будь-якому випадку за комбінацією логіна та пароля система встановлює автентичність користувача та авторизує його.

В Debian і дистрибутивах-спадкоємцях, таких як Ubuntu, облікові записи користувачів зберігаються у файлі /etc/passwd, а хеші паролів — у захищеному /etc/shadow. Прямий доступ до останнього дозволений тільки привілейованим процесам, запущеним від імені root. Однак навіть вони не зможуть побачити паролі ні за яких обставин — зберігаються тільки їх хеші.

Спеціальний модуль PAM незворотно перетворює введений пароль і порівнює отриманий результат з збереженим у /etc/shadow хешем. Використовуваний алгоритм та «сіль» також вказуються в рядку з хешем. В сучасних дистрибутивах Linux зазвичай використовується SHA-512 зі «сіллю» замість застарілого DES/MD5. Таким чином, перевірка виконується безпечно — реальні паролі не передаються і не зберігаються у відкритому вигляді.

Як я вже сказав, парольна аутентифікація може бути як локальною, так і віддаленою. У останньому випадку, як правило, використовується протокол SSH (Secure Shell). Звісно, його механізм може використовуватися не тільки для парольної аутентифікації — і про це ми докладно поговоримо нижче. Важливо знати, що в заснованих на Debian-дистрибутивах OpenSSH-сервер за замовчуванням дозволяє вхід по паролю всім, крім, можливо, користувача root. Параметр PasswordAuthentication у файлі /etc/ssh/sshd_config регулює цю можливість: значення yes дозволяє парольну аутентифікацію, no — забороняє.

Протокол SSH шифрує весь трафік, тому сам пароль передається на сервер у захищеному вигляді. Демон sshd на сервері розшифровує отриманий пароль. Далі модуль PAM обчислює хеш і співвідносить його з записом у /etc/shadow.

У паролів є кілька суттєвих недоліків

Пароль можна підібрати перебором. Користувачі часто вибирають паролі, які легко запам’ятати — а значить, нерідко це поширені слова або комбінації цифр. Зловмисники використовують спеціальні словники і програми для брутфорса — атаки грубої сили з перебором паролів. Вони без особливих проблем зламують облікові записи зі слабкими паролями.

Складні унікальні паролі важко запам’ятати. Рекомендації безпеки вимагають створювати довгі паролі, що складаються з випадкових символів. Проте людина не може утримувати в пам’яті багато нісенітниць. Як наслідок, у хід йдуть записи у відкритому вигляді, які зберігаються в небезпечних місцях, на виду у всіх бажаючих. А ще їх можна втратити.

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

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

Управління паролями на безлічі серверів стає нетривіальною задачею. Для десятків машин адміністратору доводилося б десь зберігати список різних складних паролів, регулярно їх змінювати, слідкувати за термінами дії тощо. Така складність викликає незручності і неминучі помилки. Один скомпрометований пароль — і під загрозою вся система, якщо не включена двофакторна захист.

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

SSH-авторизація: що це таке і як працюють SSH-ключі

SSH (Secure Shell) — мережевий протокол для захищеного віддаленого доступу до системи. Його назва перекладається як «безпечна оболонка». Протокол забезпечує шифрування з’єднання й перевірку автентичності обох сторін. SSH дозволяє підключитися до віддаленого сервера і виконувати команди в терміналі так, ніби використовувалося локальне підключення на тій же машині.

Робота будується за моделлю клієнт-сервер: на віддаленому вузлі повинен бути запущений SSH-демон (служба sshd), який «слухає» сетевий порт (стандартно 22) та очікує вхідних підключень. На стороні користувача використовується SSH-клієнт — програма, яка ініціює з’єднання, проходить аутентифікацію, а також шифрує і дешифрує дані.

OpenSSH — найбільш популярна реалізація SSH у Linux. У дистрибутивах, унаследованих від Debian, клієнтська частина OpenSSH вже присутня в системі. Для розгортання серверної частини достатньо встановити пакет openssh-server — служба запуститься автоматично і зможе приймати вхідні SSH-підключення. Конфігурація сервера зберігається у файлі /etc/ssh/sshd_config, де задаються параметри аутентифікації, використовувані протоколи шифрування та інші налаштування.

Для підключення по SSH користувач вводить команду виду:

ssh @

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

Принцип роботи SSH-ключів базується на асиметричному шифруванні. Приватний ключ шифрує дані. Обратне перетворення може виконати тільки пов’язаний з ним публічний ключ. По назві ключів можна бачити і принципи звернення з ними.

 

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

Публічний ключ не є секретом і може вільно передаватися мережею — він копіюється на цільовий сервер і зазвичай зберігається в домашній директорії користувача на сервері у спеціальному файлі ~/.ssh/authorized_keys.

Під час підключення по SSH сервер надсилає клієнту випадкову строку (челлендж), яку клієнт підписує своїм приватним ключем і надсилає назад. Сервер, використовуючи публічний ключ, перевіряє підпис. Якщо вона коректна, доступ надається, в іншому випадку — відхиляється. Таким чином, підтверджується володіння приватним ключем без передачі якихось секретних даних через мережу. Пароль при цьому не потрібен зовсім.

 

 

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

 

При необхідності, SSH-ключі можна доповнити допоміжною захистом. Один з прикладів — обмеження можливості входу тільки з певних IP-адрес. Інший варіант — додавання двофакторної авторизації, адже протокол SSH дозволяє вимагати одночасно і ключ, і одноразовий код, отримуваний, наприклад, через PAM-модуль Google Authenticator.

Чому ж SSH-ключі краще паролів

Ось основні аргументи на користь ключів.

Стійкість до злому

Пароль довжиною 8-10 символів можна відносно швидко підібрати. Це робиться або перебором, або за допомогою словаря, особливо, якщо пароль розповсюджений. SSH-ключ же — це послідовність з сотень випадкових символів, частіше всього довжиною 2048 або 4096 біт. Довжина і ентропія таких ключів в порядки перевищують навіть найскладніші паролі.

Повний перебір всіх можливих SSH-ключів неможливий навіть за допомогою суперсильних сучасних комп’ютерів. Фактично така задача вимагала б мільйони років обчислень. Як наслідок, відмова від входу за паролем на користь ключів виключає саму можливість подібного способу проникнення на сервер. Численні боти, постійно атакуючи сервери по SSH, просто не зможуть нічого зробити — підібрати ключ неможливо, а на вгадування пароля у них буде жодної спроби.

Конфіденційність приватного ключа

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

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

Стійкість до компрометації сервера та витоків даних

Зловмисник може скомпрометувати сервер, де зберігаються хеші паролів — наприклад, отримавши права root, і скопіює файл /etc/shadow. Тоді він може спробувати зламати паролі офлайн, перебираючи комбінації та порівнюючи отриманий хеш. При використанні ключів така атака безглузда: на сервері немає секретів, придатних для підбору, як немає і приватного ключа.

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

Виключення людського фактора

Ключ не потрібно пам’ятати, його неможливо вибрати «занадто простим» випадково. Користувач не зможе встановити тривіальний SSH-ключ, подібно до того, як може придумати слабкий пароль на кшталт «12345». Уходить ризик використання легко вгадуваних або слабких комбінацій.

Зручність, гнучкість та автоматизація

З SSH-ключами можна використовувати одну пару ключів для доступу до різних своїх серверів (або згенерувати окрему пару для різних груп машин). Це набагато зручніше, ніж управління безліччю унікальних паролів для кожного ресурсу. Не потрібно щоразу вводити пароль при підключенні: аутентифікація відбувається автоматично.

Зручність особливо відчутна при частих підключеннях або використанні автоматизованих скриптів та систем оркестрації. Наприклад, Ansible та Terraform використовують ключі для доступу до серверів без участі людини. Такий підхід безпечніший, ніж зберігання паролів у скриптах у відкритому вигляді.

Ще одна сторона зручності: при уході співробітника з компанії досить просто видалити його публічний ключ з усіх серверів, замість трудомісткої заміни безлічі паролів.

Концептуальна перевага: володіння проти знання

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

Звісно, ідеальний варіант — це комбінація методів. Наприклад, можна використовувати закритий ключ на апаратному токені разом з PIN-кодом або в зв’язці з одноразовим кодом. Але в контексті вибору «пароль чи ключ» останній виграє за всіма параметрами.

 

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

 

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

Неутішна статистика

Статистика інцидентів інформаційної безпеки ще раз підтверджує слабкість паролів як заходу захисту.

Перша атака підбором пароля спостерігається вже через 10-15 хвилин після підключення свіжозгорнутого сервера до мережі. Про це повідомляють дані наших ІБ-спеціалістів у Selectel. Далі атаки тривають постійно, скануючи машину в пошуках відкритих SSH-портів.

В рік фіксуються десятки мільйонів спроб входу. Компанія Rapid7 провела дослідження на пастках (honeypot) SSH і RDP і надала дані за 2021-2022 роки. Було виявлено понад 216 000 унікальних IP-адрес атакуючих і більше 512 000 паролів, використаних у цих атаках. Переважна більшість паролів — розповсюджені, які навіть зібрані у спеціальні словники. У першу п’ятірку ввійшли: 123456, nproc, test, qwerty та password — тобто відверто слабкі значення.

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

81% зломів акаунтів у 2022 році були викликані слабкими, повторно використовуваними або вкраденими паролями. Про це розповідає звіт LastPass. Іншими словами, вісім з десяти успішних атак на інформаційні системи, так або інакше, експлуатували вразливості, пов’язані з паролями. Це можуть бути фішингові крадіжки, витоки баз даних паролів, перебір простих комбінацій або використання паролів, вкрадених з інших сервісів.

2/3 атак на хмарні сервіси пов’язані з уразливими обліковими даними — ще один тривожний сигнал. Причина та ж — відсутність або слабкий пароль, про що свідчать дані Google Cloud за другу половину 2023 року. Паролі залишаються «слабким місцем», через яке зловмисники отримують первинний доступ перед розвитком атаки.

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

• складний ключ і сучасний алгоритм,
• захист приватного ключа,
• відключення входу за паролем.

 

Статистика атак підтверджує: перехід на аутентифікацію за криптографічними ключами кардинально знижує ймовірність зламу.

Налаштування доступу по SSH-ключу

В дистрибутивах на основі Debian OpenSSH-сервер підтримує авторизацію за ключами за замовчуванням (директива PubkeyAuthentication yes включена). Щоб налаштувати вхід за SSH-ключем, потрібно згенерувати ключ і встановити публічний ключ на сервер. Нижче наведено загальний порядок.

1. Генерація ключової пари на клієнті. В терміналі користувача на локальній машині, з якої буде здійснюватися доступ, виконайте команду генерації ключа. Наприклад, для RSA 3072 біт (значення за замовчуванням для OpenSSH), команда буде наступна:

ssh-keygen -t ed25519 -C

За замовчуванням буде запропоновано шлях для збереження ~/.ssh/id_ed25519. Можна змінити його, вказавши шлях, відносно домашнього каталогу — наприклад:

Enter file in which to save the key (/home/alex/.ssh/id_ed25519): .ssh/my_key

Крім того, за бажанням можна ввести парольну фразу для захисту ключа. Після завершення команди з’являться два файли: приватний та публічний ключі — ~/.ssh/my_key та ~/.ssh/my_key.pub.

2. Встановлення публічного ключа на сервері. Найзручніше зробити це утилітою ssh-copy-id, якщо поки що доступний вхід за паролем. За замовчуванням утиліта намагається скопіювати перший знайдений ключ — зазвичай це ~/.ssh/id_rsa.pub або ~/.ssh/id_ed25519.pub. Якщо ключів декілька, потрібно вказати, який з них використовувати. Скопіймо ключ з нашого прикладу — my_key.pub.

ssh-copy-id -i ~/.ssh/my_key.pub <ім'я_користувача>@<адреса_сервера>

Утиліта попросить поточний пароль користувача на сервері, а потім автоматично скопіює вміст my_key.pub у файл ~/<ім'я_користувача>/.ssh/authorized_keys на сервері. Якщо директорія .ssh або файл authorized_keys не існують, вони будуть створені.

Можна також скопіювати публічний ключ вручну. Для цього зберігаємо його в придатне місце на сервері, а потім додаємо до вмісту ~/.ssh/authorized_keys. Наприклад, можна скористатися утилітою scp (Secure Copy):

scp ~/.ssh/my_key.pub <ім'я_користувача>@<адреса_сервера>:~/

Далі в терміналі на сервері:

cat ~/my_key.pub >> ~/.ssh/authorized_keys

Звісно, щоб виконати подібну операцію, у користувача повинен бути доступ на сервер, а також відповідні права.

3. Перевірка входу по ключу. Перевіримо працездатність SSH — спробуємо підключитися до сервера, вказавши ключ:

ssh -i ~/.ssh/my_key <ім'я_користувача>@<адреса_сервера>

Коли ви підключаєтеся вперше, сервер попросить підтвердити відбиток його ключа — так і має бути, введіть yes і натисніть Enter. Якщо приватний ключ захищений додатковим паролем, система запитає його. Після цього ми повинні потрапити на віддалену систему — запрошення в терміналі зміниться. Можна також завжди набрати команду hostname — вона завжди покаже назву поточного хосту.

4. Вимкнення парольної авторизації (рекомендується). Досягнувши працюючого входу по ключу, забороняємо вхід за паролем — так ми позбудемося недоліків парольної аутентифікації і отримаємо всі переваги аутентифікації по ключу. Відредагуємо на сервері конфігураційний файл SSH /etc/ssh/sshd_config.

Переконайтеся, що вхід за ключами дійсно працює, перш ніж вимикати пароль. Інакше доступ до сервера вдасться відновити тільки через KVM-консоль або в Rescue Mode.

Змінюємо параметр PasswordAuthentication — його значення повинно стати no. Переконаємось, що також вимкнена опція ChallengeResponseAuthentication, яка відповідає за застарілу аутентифікацію keyboard-interactive. Щоб зміни вступили в силу, перезапустимо службу SSH:

sudo systemctl restart ssh

Сервер перестане приймати пароль після перезавантаження. Тепер вхід — тільки за ключами.

При створенні пари ключів утилітою ssh-keygen, якщо не змінювався шлях, запропонований за замовчуванням, вони зберігаються у каталозі ~/.ssh:

• id_rsa або id_ed25519 — приватний ключ (назва за замовчуванням залежить від використовуваного алгоритму);
• id_rsa.pub або id_ed25519.pub — публічний ключ.

Ці файли рекомендується захищати від несанкціонованого доступу. Каталог ~/.ssh повинен мати права 700, а приватний ключ — 600 (тільки власник може читати і записувати). Якщо права доступу налаштовані неправильно, сервер SSH може відмовити у вході за ключем з міркувань безпеки.

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

Щоб не вводити парольну фразу щоразу, можна скористатися утилітою ssh-agent — ввід passphrase знадобиться тільки одного разу за сесію:

ssh-add ~/.ssh/my_key

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