Хостинг на декількох сайтах - важлива вразливість для захисту сайтів один від одного?

РЕДАКТИРУЙТЕ №2 23 липня 2015 року: шукаєте нову відповідь, яка визначає важливий елемент безпеки, пропущений у нижченаведених налаштуваннях, або може дати підстави вважати, що все охоплено.

EDIT № 3 29 липня 2015 року: Я особливо шукаю можливу неправильну конфігурацію, наприклад, щоб ненавмисно дозволити щось, що можна було б використати, щоб обійти обмеження безпеки або ще гірше, але залишати щось відкритим.

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

Ось що я маю досі:

• Переконайтеся, що сценарії PHP працюють як облікові записи та групи користувачів веб-сайту Linux, і чи вони знаходяться у в'язниці (наприклад, за допомогою CageFS), або принаймні належним чином обмежені за допомогою дозволів файлової системи Linux.
• Використовуйте suexec, щоб гарантувати, що сценарії CGI не можуть бути запущені як користувач Apache.
• Якщо вам потрібна підтримка на стороні сервера (наприклад, у файлах shtml), використовуйте Options IncludesNOEXECдля запобігання запуску CGI, коли ви цього не очікуєте (хоча це не повинно викликати особливих проблем при використанні suexec).
• Встановіть захист від атак від символьної посилання, щоб хакер не міг обманути Apache в обслуговуванні файлів іншого веб-сайту у вигляді простого тексту та розкритті інформації, що експлуатується, як паролі БД.
• Налаштувати AllowOverride/ AllowOverrideListдозволити лише ті директиви, які хакер не міг використовувати. Я думаю, що це викликає занепокоєння, якщо вищезазначені пункти виконані належним чином.

Я б пішов з MPM ITK, якби це не було так повільно і не працював як root, але ми спеціально хочемо використовувати спільний Apache, але переконайтеся, що це зроблено надійно.

Я знайшов http://httpd.apache.org/docs/2.4/misc/security_tips.html , але це було не всебічно з цієї теми.

Якщо це корисно знати, ми плануємо використовувати CloudLinux з CageFS та mod_lsapi.

Чи є ще щось, щоб переконатися в тому, щоб зробити чи знати?

EDIT 20 липня 2015 року: люди подали кілька хороших альтернативних рішень, які загалом цінні, але зауважте, що це питання спрямоване лише на безпеку спільної установки Apache. Зокрема, є щось, що не висвітлено вище, що могло б дозволити одному сайту отримати доступ до файлів іншого сайту або якось компрометувати інші сайти?

Дякую!

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

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

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

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

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

Моя пропозиція полягала б у тому, щоб використовувати якесь програмне забезпечення VM (VMware, VirtualBox, Qemu тощо), щоб дати кожному сайту власну в'язницю ОС. Це дозволяє вам, як системному адміністратору, не турбуватися про єдиний порушений сайт. Якщо хакер отримує корінь, використовуючи php (або будь-яке інше програмне забезпечення) на VM сайту, просто призупиніть програму VM та розчленуйте її пізніше, застосуйте виправлення або поверніть до неперервного стану. Це також дозволяє адміністраторам сайтів застосовувати певне програмне забезпечення або параметри безпеки до їх конкретного середовища (що може порушити інший сайт).

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

Цей тип налаштування зменшує кількість векторів атак, за якими вам слід відстежувати, і дозволяє зосередитись на безпеці Host Machines та вирішувати все інше на сайті на сайті.

Я б запропонував, щоб кожен сайт запускався під власною демон Apache, і хронізував Apache. Вся функція системного php вийде з ладу, оскільки середовище Apache chroot не матиме доступу до / bin / sh. Це також означає, що функція пошти () php також не працюватиме, але якщо ви використовуєте зовнішнього постачальника пошти для надсилання пошти з вашої програми електронної пошти, це не повинно бути проблемою для вас.

SELinux може бути корисним для mod_selinux. Тут представлений короткий опис:

Як я можу використовувати SELinux для обмеження скриптів PHP?

Оскільки вказівки трохи датовані, я перевірив, чи працює це на RHEL 7.1:

Я використовував версію Fedora 19 і компілював з макетом проти RHEL 7.1 + EPEL.

YMMV, якщо ви використовуєте базовий пакет epel config, який використовується з:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Спочатку оновіть цільову систему, щоб переконатися, що selinux-policyвона поточна.

Встановіть у цільове поле (або спочатку поставте на місцеве дзеркало):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Тепер ви повинні призначити кожному віртуальному хосту в категорії apache. Це робиться шляхом додавання рядка, такого як у наведеному нижче прикладі selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Далі, у корені документа для кожного хоста, відновіть корені їх документів до тієї ж категорії, що й те, позначені в конфігурації httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Якщо ви хочете, щоб маркування отримало честь, якщо ви робите системний релебел, також краще оновіть локальну політику!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Надано вже багато хороших технічних відповідей (будь ласка, також ознайомтесь тут: https://security.stackexchange.com/q/77/52572 та Поради щодо забезпечення безпеки LAMP-сервера ), але я все одно хотів би зазначити тут важливий момент (з іншої точки зору) щодо безпеки: безпека - це процес . Я впевнений, що ви вже це врахували, але все ж сподіваюся, що це може бути корисно (також для інших читачів), щоб іноді переосмислити це.

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

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

1. Перш за все, не забувайте, що безпека - це процес і, зокрема, про цикл "Плануйте-робіть-перевіряйте-дію", як це рекомендовано багатьма стандартами, включаючи ISO 27001 ( http://www.isaca.org/ Журнал / архіви / 2011 / Том-4 / Сторінки / Планування-для-та-впровадження-ISO27001.aspx ). В основному це означає, що вам потрібно регулярно переглядати заходи безпеки, оновлювати та перевіряти їх .

2. Регулярно оновлюйте систему. Це не допоможе проти націлених атак із використанням вразливих даних із нульовим днем, але допоможе проти майже всіх автоматизованих атак.

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

   Про це говорить статистика: "Середній час від інфільтрації до відкриття становить 173,5 днів" ( http://www.triumfant.com/detection.html ), "205 середня кількість днів до виявлення" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-Trends-2015.pdf ). І я сподіваюся, що ці цифри - це не те, що ми всі хочемо мати.

   Існує маса рішень (в тому числі безкоштовних) не тільки для моніторингу стану сервісу (як Nagios), але й систем виявлення вторгнень (OSSEC, Snort) та систем SIEM (OSSIM, Splunk). Якщо це стає занадто складним, ви можете принаймні включити щось на кшталт 'fail2ban' та / або переслати свої журнали для відокремлення сервера syslog та отримувати сповіщення електронною поштою про важливі події.

   Знову ж таки, найважливішим моментом є не те, яку систему моніторингу ви обрали, найважливіше - це те, що у вас є певний моніторинг і регулярно його переглядати відповідно до циклу "Плануй-роби-перевіри-дій" .

4. Будьте в курсі вразливих місць. Те саме, що моніторинг. Просто підпишіться на деякий список вразливості, який буде повідомлено, коли буде виявлена ​​критична вразливість для Apache або іншої служби, важливої ​​для вашої установки. Мета - повідомити про найважливіші речі, які з’являються до наступного запланованого оновлення.

5. Майте план, що робити у випадку інциденту (і регулярно його оновлюйте та переглядайте відповідно до циклу "Плануйте, зробіть перевірку"). Якщо ви ставите питання щодо безпечної конфігурації, це означає, що безпека вашої системи стає для вас важливою. Однак що робити у випадку, якщо система зламалася, незважаючи на всі заходи безпеки? Знову ж таки, я не маю на увазі лише технічні заходи, такі як "перевстановлення ОС": Де ви повинні повідомити про аварію відповідно до чинного законодавства? Чи дозволено вам негайно відключити / відключити ваш сервер (скільки це коштує вашій компанії)? До кого слід зв’язатися, якщо головна відповідальна особа перебуває у відпустці / хворіє?

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

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

Ваш корпус використання ідеально підходить для контейнерів-докерів.

Кожен контейнер може представляти клієнта або клієнта, з унікальними ідентифікаторами користувачів, присвоєними кожній групі контейнерів Apache як додаткову безпеку. Ключовим моментом буде відмовитись від привілеїв root при запуску контейнера, перш ніж запускати стек apache. Кожен клієнт отримує власну службу БД із власними унікальними паролями, без головного болю стоячи десятки віртуальних машин, кожен з яких вимагає власних ядер сніжинки та інших накладних витрат. Адже в основі докера лежить хорут. Правильно адмініструючи, я б взяв це за типовий віртуальний кластер в будь-який день.

Тут вже багато хороших пропозицій. Хоча речі, пропущені в обговоренні, поки що.

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

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

Програми PHP зазвичай не обслуговують власні статичні файли, і якщо у вас є спільний процес apache, то я здогадуюсь, що ваш процес apache читає речі прямо з в'язниць із середовища перебування? Якщо так, то це викликає різні проблеми.

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

Менш очевидним є те, як apache вирішує, що таке статичний файл у будь-якому випадку. наприклад, що це робиться з файлом *.php.gifабо *.php.enфайлом? Якщо цей або інший механізм обдурює дискримінацію щодо того, що є статичним файлом, чи можна апаче запускати php взагалі поза в'язниці? Я створив би окремий легкий веб-сервер для статичного контенту, який не налаштований жодними модулями для виконання динамічного контенту, і маю балансир завантаження, який вирішує, які запити надсилати на статичний сервер, а який на динамічний.

Щодо пропозиції Докера Стефана, можливо, є один веб-сервер, який сидить поза контейнером і який розмовляє з демонами php у кожному контейнері для динамічного вмісту, а також має другий веб-сервер, який сидить у контейнері докера, і який розділяє обсяги, які кожен використовує для свого вмісту, і, таким чином, здатний обслуговувати статичний вміст, який приблизно такий же, як у попередньому пункті. Я вітаю докера серед різних підходів до в'язниці, але з цим чи іншим підходом до тюремного ув'язнення у вас з'явиться маса інших проблем. Як працює завантаження файлів? Чи поміщаєте демони передачі файлів у кожен контейнер? Ви використовуєте підхід на основі git у стилі PAAS? Як зробити доступні журнали, створені всередині контейнера, і згортати їх? Як ти керуєш і виконуєш роботи із cron? Чи збираєтесь ви надати користувачам будь-який доступ до оболонки, і якщо так, це ще один демон у контейнері? тощо.

Перше, що я не бачу, це управління процесами, тому один процес не може голодувати іншим процесором або оперативною пам’яттю (або вводу / виводу з цього приводу, хоча ваша файлова система може бути архітектурованою, щоб запобігти цьому). Однією з головних переваг «контейнерного» підходу до ваших примірників PHP порівняно з намаганням запустити їх на одному зображенні «ОС» є те, що ви можете таким чином обмежити використання ресурсів. Я знаю, що це не ваш дизайн, але це щось, що слід враховувати.

Так чи інакше, повернемося до випадку використання PHP, який працює за Apache, в основному функціонує як проксі. suexec не заважає чомусь запускатися як користувач apache - він надає можливість запускатись як інший користувач. Отож, одна проблема повинна переконатися, що все зроблено належним чином - сторінка doc для неї викликає таку потенційну небезпеку: https://httpd.apache.org/docs/2.2/suexec.html . Отже, знаєте, зерно солі та все таке.

З точки зору безпеки це може бути корисно мати обмежений набір призначених для користувача довічних файлів для роботи з (що cagefs поставки), особливо , якщо вони складені по- різному або проти іншої бібліотеки (наприклад , той , який не включає в себе можливості , які є небажаними) , але небезпека полягає в тому, що в цей момент ви більше не стежите за відомим дистрибутивом для оновлень, ви стежите за іншим розповсюдженням (cagefs) для ваших установок PHP (принаймні, стосовно інструментів для користувацького простору). Хоча, оскільки ви, мабуть, вже стежите за певним розповсюдженням з cloudlinux, це додатковий ризик, не обов'язково цікавий сам по собі.

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

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

Це мій відвал мозку. Сподіваюсь, там є щось неясно корисне. :)