Чому запуск імені (bind) у chroot так важливий для безпеки? А може, це не так?

Я грав з bind і почав цікавитись, чому це програмне забезпечення, наприклад, у CentOS працює в chroot. Не розумійте мене неправильно, я знаю, що таке прив'язка і для чого потрібний Chroot (в'язниця). Але моє головне питання: чи прив’язаний біг без хротону так дуже незахищено?

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

Як згадував @Some Guy, ви повинні думати про це в історичній перспективі.

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

З віртуалізацією це набагато менше питання. Хоча вийти з ВМ неможливо, це далеко не банально. Звісно, ​​складніше вийти з віртуального комп'ютера, тоді це виходить з процесу, який працює з кореневими привілеями. Тож мої сервери зв'язування працюють на власному VM. У цьому випадку насправді не так багато сенсу, оскільки шкода вже обмежена просто тим, що це VM.

Chroot - це дуже слабка спроба створити щось на зразок VM. Chroots можна уникнути, хоча будь-яким процесом з правами root. Chroot не призначений і не працює як механізм захисту. Chroot з в'язницею BSD або LXC надає вам віртуалізацію на рівні ОС і надає функції безпеки. Але в наші дні, оскільки настільки легко закрутити новий VM цілої машини, можливо, не варто докладати зусиль для налаштування або навчитися використовувати засоби віртуалізації рівня ОС для цієї мети.

Раніші версії bind не припускали привілеїв. У Unix лише кореневий акаунт може відкривати порти нижче 1024, а Bind, як ми всі знаємо, повинен слухати udp / 53 та tcp / 53. Оскільки Bind запускається як корінь і не відмовляється від привілеїв, будь-який компроміс означав би, що вся система може бути порушена. Практично будь-яке програмне забезпечення розпочне відкривати свої сокети та виконувати будь-які інші речі, для яких потрібні кореневі привілеї, тоді вони змінять користувача, якого він працює, на непривілейований обліковий запис. Після того, як пільги будуть скасовані, вплив на компрометацію буде значно нижчим для хост-системи.

Інші відповіді досить хороші, але не згадують поняття безпеки в шарах. Кожен рівень безпеки, який ви додаєте до вашої системи, - це ще один шар, який супротивник повинен подолати. Поміщення BIND в chroot додає ще одну перешкоду.

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

Згадана ситуація дещо малоймовірна, як згадує SomeGuy, BIND в даний час має досить мало вразливих ситуацій, і вони в основному обмежені сценаріями типу DoS, а не віддаленим виконанням. Але це означає, що запуск за допомогою chroot - це конфігурація за замовчуванням на досить багатьох ОС, тому навряд чи будете докладати жодних зусиль з вашого боку, щоб зберегти незмінно підвищену безпеку.

преамбула

Я продовжую чути, як люди повторюють помилки з усього Інтернету .. таким чином, я спробую дати деяке уточнення

По-перше; скільки випадкових відкриттів було, що просто .. внаслідок причини та наслідку в кінцевому підсумку використовувались для чогось іншого, ніж за призначенням?

що було, а що таке - тюрма Chroot

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

chroot ефективно використовується і знаходиться безпосередньо в базі коду для декількох програм і бібліотек (наприклад, openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot тощо ). якщо припустити, що всі ці основні програми впровадили несправні рішення безпеки, це просто неправда

chroot - це рішення для віртуалізації файлової системи: ні менше, ні більше. припущення, що ви можете легко вирватися з хротону, також не відповідає дійсності ... доки ви дотримуєтесь вказівок щодо запуску процесів усередині в'язниці Chroot.

кілька кроків, щоб убезпечити тюрму Chroot

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

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

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

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

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

чому Chroot досі використовується, на відміну від повної віртуалізації системи

врахуйте цей сценарій: ви запускаєте віртуальний приватний сервер, а вузловий хост працює на OpenVZ. ви просто не можете запустити нічого, що працює на рівні ядра. це також означає, що ви не можете використовувати віртуалізацію операційної системи для розділення процесів та надання додаткової безпеки. таким чином, Ви ПОВИНЕН використовувати chroot для цієї мети.

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

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

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

У відповідь на ваше запитання

Я особливо не використовую CentOS, але я знаю, що Bind тепер відмовляється від своїх привілеїв перед операціями. Я б припускав, однак, що зв'язування введене в силу своєї історії векторів атак та потенційних вразливих місць.

також ... має сенс автоматично хронізувати цю програму, ніж ні, тому що НЕ ВСЕ кожен має доступ до повної віртуалізації на рівні системи / операційної системи. це, в свою чергу, і теоретично допомагає забезпечити безпеку бази користувачів CentOS:

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

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

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

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

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