Чи налаштовано парольний `sudo` на хмарному сервері?

Мені подобається ідея доступу до серверів за допомогою ключів, так що мені не потрібно вводити свій пароль щоразу, коли я sshпотрапляю в поле, я навіть блокую (не root) пароль свого користувача ( passwd -l username), тому неможливо ввійти в систему без ключа.

Але все це порушується, якщо мені потрібно ввести пароль для sudoкоманд. Тож я спокусився налаштувати без паролів,sudo щоб вони відповідали безкористувальному входу.

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

Роз'яснення

1. Я говорю про використання тут sudoв інтерактивному сеансі користувача, а не для служб або адміністративних сценаріїв
2. Я говорю про використання хмарного сервера (тому я не маю фізичного локального доступу до машини і можу входити лише віддалено)
3. Я знаю, що у вас sudoє час очікування, протягом якого я не повинен повторно вводити свій пароль. Але мій концерт насправді не витрачає зайвий час, щоб фізично ввести пароль. Хоча моя ідея полягала в тому, що взагалі не потрібно мати справу з паролем, тому що я вважаю, що:
   • Якщо мені доведеться запам'ятати це взагалі, це, швидше за все, занадто коротко, щоб бути захищеним чи використаним
   • Якщо я генерую довгий і унікальний пароль для свого віддаленого облікового запису, мені доведеться зберігати його десь (локальна програма керування паролями або хмарний сервіс) і отримувати його кожного разу, коли я хочу користуватися sudo. Я сподівався, що зможу цього уникнути.

Тож з цим питанням я хотів краще зрозуміти ризики, застереження та компроміси однієї можливої ​​конфігурації над іншими.

Слідкуйте за 1

Усі відповіді говорять про те, що без паролів sudoце небезпечно, оскільки це дозволяє «легко» ескалювати привілеї, якщо мій особистий обліковий запис користувача буде порушений. Я розумію, що. Але з іншого боку, якщо я використовую пароль, ми несемо всі класичні ризики з паролями (занадто коротка або звичайна рядок, повторювана в різних службах тощо). Але я здогадуюсь, що якщо я відключу автентифікацію пароля, /etc/ssh/sshd_configщоб вам все-таки довелося мати ключ для входу, я можу використовувати простіший пароль лише для sudoтого, щоб це було простіше ввести? Це правильна стратегія?

Подальша робота 2

Якщо у мене також є ключ для входу як rootчерез ssh, якщо хтось отримає доступ до мого комп'ютера та вкраде мої ключі (вони все ще захищені паролем для введення ключів ОС!), Вони також можуть отримати прямий доступ до rootоблікового запису , обходячи sudoшлях. Якою має бути тоді політика доступу до rootоблікового запису?

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

Ви збираєтесь відключити вхід на основі пароля неправильним способом. Замість блокування облікового запису користувача встановіть PasswordAuthentication noу своєму /etc/ssh/sshd_config.

З цим набором автентифікацію пароля вимкнено для ssh, але ви все одно можете використовувати пароль для sudo.

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

Відповіді на ваші подальші запитання:

Але я здогадуюсь, що якщо я відключу автентифікацію пароля в / etc / ssh / sshd_config, щоб вам все-таки довелося мати ключ для входу, я можу використовувати простіший пароль лише для sudo, який простіше ввести? Це правильна стратегія?

Так, це правильно. Я все-таки рекомендую використовувати відносно міцні паролі локального облікового запису, але не смішно надійні. ~ 8 символів, генерованих випадковим чином, достатньо.

Якщо у мене також є ключ для входу як root через ssh, якщо хтось отримає доступ до мого комп'ютера та вкраде мої ключі (вони все ще захищені паролем для введення ключів ОС!), Вони також можуть отримати прямий доступ до кореневий рахунок, минаючи шлях судо.

Кореневий доступ через ssh має бути вимкнено. Період. Встановіть PermitRootLogin noу своєму sshd_config.

Якою має бути політика доступу до кореневого облікового запису?

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

Я, як правило, обмежую використання NOPASSWORDкоманд, які виконуються автоматизованим процесом. Переважно мати обліковий запис сервісу для цих команд і обмежити використання sudo необхідними командами.

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

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

Я використовував би це лише за двох обставин:

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

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

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

Щодо подальшої діяльності 2:

Якщо у мене також є ключ для входу як root через ssh

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

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

Я використовую це у виробництві більше п'яти років.

Щоб налаштувати його, встановіть модуль PAM, а потім додайте рядок /etc/pam.d/sudoабо еквівалент вашої системи:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Якщо ви це зробите, не забудьте захистити свої ключі на комп’ютері парольною фразою. Таким чином, комусь доведеться прорватися до вашого комп’ютера та вкрасти ключі, щоб увійти. Вони могли це зробити, витягнувши їх з пам’яті, поки вони були розблоковані, якщо вони мають доступ до вашого облікового запису, зламавши вашу парольну фразу або викравши ваш пароль кейлоггер або серфінг за плечима під час введення тексту (дивіться позаду!).

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

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Оскільки ви запитували, ось моя загальна порада щодо вирішення sudoпроблеми.

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

Правильно налаштований Sudo не використовуватиме цей ALL=(ALL) ALLпараметр, а скоріше щось обмежене тим, що саме користувачеві потрібно. Наприклад, якщо вам потрібен користувач, щоб мати змогу увійти та перезапустити послугу, що відключилася, їм, ймовірно, не потрібна можливість встановити нове програмне забезпечення або відключити ваш сервер, змінити правила брандмауера тощо.

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

Як захистити коробки:

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

Заборонити вхід Root через SSH, використовуючи AllowRootLogin noналаштування у своїй sshd_config. Це не дозволяє комусь звертатися з вашим кореневим рахунком. Це, як правило, хороша практика ніколи не дозволяти комусь безпосередньо входити в корінь / адміністратор з облікових записів з міркувань аудиту, а також безпеки. Якщо ви дозволите кореневий логін безпосередньо, ви не знаєте, хто ввійшов, хто отримав пароль і т.д. пошук аудиту (а також обліковий запис для скидання).

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

Редагуйте Sudoers за допомогою visudo та дозволяйте лише команди, які потрібні користувачеві. Про те, як це зробити, є багато глибоких посібників, тому я тут не буду деталізувати. Ось стартер: http://ubuntuforums.org/showthread.php?t=1132821

Суть цього полягає в тому, щоб не допустити небезпеки для компрометованого облікового запису вашої машини. тобто. якщо в обліковий запис Салі потрапляє розбиття, і Саллі може використовувати лише sudo для перезавантаження веб-сервера, добре, що зловмисник може весело перезапустити ваш веб-сервер у циклі, але принаймні вони не можуть rm -rf /your/webserver/directoryабо відкриють усі ваші порти брандмауера тощо.

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

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Також важливим є надійний пароль.Навіть якщо ви використовуєте SSH-ключі для віддаленого доступу, вам все одно потрібен пароль для використання судо. Це випадок, коли судо може забезпечити трохи більше безпеки. Якщо хтось вкраде ваші ключі ssh, вони все одно не зможуть зробити щось важливе на вашій скриньці, якщо їм доведеться все-таки жорстоко змусити пароль вашого облікового запису використовувати sudo. Паролі не повинні бути словом, а швидше пропустити фразу. Придумайте речення і використовуйте це. Зазвичай ви отримаєте щось більше 8 символів, що забезпечує велику кількість ентропії, але також легше запам’ятати, ніж якийсь випадковий пароль. Звичайно, хороші практики паролів говорять про використання машинного генерованого випадкового пароля, щоб обдурити зламуючі інструменти, як Джон Розпушувач, який буде прориватися прямо через більшість паролів та паролів. Ні, зміна E на 3 не працює, Джон також отримує ці перестановки.

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

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

Крім того, якщо ви набираєте багато кореневих привілейованих команд і не хочете постійно ставити sudo на передню частину їх, ви можете suабо sudo -sотримати кореневу оболонку. Ви введете свій пароль один раз, і тоді все.

Мене одного разу вкусив бездоглядний судо. Це був скрипт оболонки, якийсь інсталятор, який закликав sudo від мого імені , на відміну від, ви знаєте, просто вимагає судо або помилки.

Увімкніть набір тексту "make" та сценарій, який виконує частину "sudo make install" для вас, не встановлюючи і не показуючи базовий шлях, а сценарій настільки настільки розумний, що ви не впевнені, що вони знають про / usr / local і ви почнете перевіряти / usr на зміни ...

Я пообіцяв більше ніколи не використовувати NOPASSWD, а також змінив цей час очікування на 0.

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

З сторінки чоловіка sudoers :

timetamp_timeout

Кількість хвилин, яка може пройти до того, як судо знову попросить пройти паспорт. Час очікування може включати дробовий компонент, якщо хвилинна деталізація недостатня, наприклад 2,5. За замовчуванням - 5. Установіть це значення 0, щоб завжди запросити пароль. Якщо встановлено значення менше 0, штамп часу користувача ніколи не закінчується. Це можна використовувати, щоб дозволити користувачам створювати або видаляти власні часові позначки через "sudo -v" та "sudo -k" відповідно.

У цій публікації в блозі показано кілька прикладів, які використовують час visudoвстановлення часу в хвилинах, наприклад:

Defaults timestamp_timeout=60

Можливо, це щасливий середина між безпекою та зручністю у використанні?

Інші відповіді тут чудові і стосуються більшості важливих моментів. Одне, про що я не бачив, - це той факт, що будь-який тип автентифікації, який ви робите під час входу в систему, може бути захоплений віддаленим зловмисником, який уже встановив опору у вашому обліковому записі. Вони можуть змінювати ваші файли для входу в оболонку або PATH, щоб встановити кейлоггер, щоб все, що ви введете, включаючи ваш пароль sudo, надсилалося їм. Вони можуть додати зламаний бінарний судо до вашого PATH, щоб зібрати ваш пароль. Вони можуть викрасти з'єднання агента ssh назад до вашої підключувальної машини, щоб перемогти pam_ssh_agent_auth і стати корінними, як тільки ви підключитесь. Отже, що стосується абсолютної безпеки, я не бачу різниці між використанням пароля для sudo і ні. Звичайно, це робить його складнішим у атаці,

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