Чи безпечно встановити виробничий сервер?

42

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

У мене також є gccкомпілятор на сервері, який я використовую для створення програм перед розгортанням.

security make gcc

— SK '
джерело

4

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

— MDMoore313

1

І той, хто має некореневий доступ до оболонки на сервер, може завантажити пакет "компілятора незалежно від дистрибутива" (.tar.gz), який не потрібно буде встановлювати так ...

1

Це я, або поєднання "це безпечно?" і "кореневий доступ" досить незручний ?

— ДНК

2

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

— Шадур

1

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

— Vality

50

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

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

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

Пакет може містити виконуваний файл suid або sgid.
Пакет може бути запуском послуг у системі.
У пакеті можуть бути встановлені сценарії, які автоматично викликаються за певних обставин (це включає завдання cron, але сценарії можуть викликатися іншими подіями, наприклад, коли стан мережевого інтерфейсу змінюється або коли користувач входить у систему).
У пакеті можуть бути встановлені вставки пристроїв.

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

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

Якщо ви виявите, що ці інструменти вам не потрібні на сервері, вам слід утримуватися від їх встановлення з кількох причин:

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

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

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

6

Я додам до цього, що ряд виробничих систем покладаються на інтерпретований код (наприклад, PHP, Perl, Python, ...). Заборона використання інструментів розвитку в цьому контексті не мала б сенсу. Я вважаю, що компілятори gccне хочуть представляти більш високий ризик, ніж цей. Як ви кажете, зловмисник, який може використовувати компілятори, встановлені в системі, як правило, може зробити гірші речі, такі як завантаження власного (можливо, статично пов'язаного) виконуваного файлу.

— Бруно

3

Відповідна: крихітна версія wget (51 байт?) . Приклад реального життя зловмисника, який переміщує двійковий файл на сервер, використовуючи наступні echoзаяви у файл. Весь процес автоматизований за допомогою сценарію, знайденого в одному посиланні.

— Аді

2

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

— Бруно

15

makeоболонка, яка має інший синтаксис, ніж bash.

Цей компілятор gccє потужним, awkналаштованим набором підстановок, які стандарт awkне підтримує. Це не сумісний з POSIX sortабо catвводить сміття у вихід. Це інтерактивний текстовий редактор (думаю vi), який налаштований для редагування під час запуску, а потім виходу перед відображенням інтерфейсу користувача.

В них немає нічого небезпечного, вони не роблять вашу машину більш небезпечною, ніж та, де ви маєте bash + cat+ перенаправлення оболонки.

— ігніс
джерело

2

Відповідь так дзен, я не знаю, як це оцінити.

— kasperd

4

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

— ignis

1

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

— kasperd

Мені подобається ця відповідь набагато більше, ніж прийнята :)

— Руслан

15

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

Ви повинні будувати свою програму на сервері збірки, упакувати її, а потім розгортати бінарний пакет у ваші виробничі системи.

Примітка: рідні засоби для пакування смокчуть . Навіть не турбуйся, намагаючись їх пограбувати. Натомість перевірте, чи є Йордан Сіссель fpm. Це робить упаковку абсолютною радістю.

— EEAA
джерело

8

Я запитую тут цікавість і незнання: Чому ви кажете, що наявність компіляторів є "важливою проблемою безпеки?" Яка проблема безпеки із встановленням компілятора? Це лише питання про те, що ви не повинні будувати свій код на виробничому сервері в першу чергу, і, таким чином, компілятор є зайвим, або насправді є значна проблема безпеки при наявності самого компілятора?

— Рейраб

11

Хоча це зручно будувати свої програми на окремому сервері, але наявність компіляторів у виробничій системі є важливою проблемою безпеки не має сенсу. А як щодо мов скриптування та компільованих JIT систем (Perl, Python, Java, ...)?

— Бруно

3

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

— Аді

1

Гарні бали, всі. Я відредагував свою відповідь, щоб уточнити.

— ЄЕАА

9

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

— Джон
джерело

4

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

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

Хто має доступ до сервера?
Що ви можете зробити для відкату після втручання?

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

— JakeGould
джерело

1

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

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

— Найгірший
джерело