Варіанти хостингу
Варіанти хостингу для веб-сайту зазвичай є одним із наступних:
- виділений сервер
- віртуальний приватний сервер (VPS)
- спільний хостинг
З виділеним сервером на фізичному комп'ютері розміщується лише один сайт, а конфігурація настільки ж безпечна, як і сам комп’ютер.
З VPS програмне забезпечення працює на тому ж фізичному комп’ютері, що і віртуальні машини інших користувачів. Однак він функціонально еквівалентний виділеному серверу. Найголовніше, що VPS має конфіденційність та безпеку виділеного сервера.
За допомогою спільного хостингу ваш веб-сайт розміщений у файловій системі, спільною з іншими користувачами. Це, на жаль, робить його менш безпечним, ніж коли він працює на виділеному сервері або VPS. У решті цієї статті йдеться про безпеку WCMS у спільному хостинговому середовищі.
Середовище
Спільне середовище хостингу може розглядатися як складається з веб-сервера, файлової системи, файлу налаштувань, бази даних та деяких користувачів.
У наступних прикладах передбачається, що обліковий запис власника є "tom", а файл налаштувань (що містить облікові дані бази даних) має назву "settings.php".
Процес веб-сервера може запускатися з дозволами користувача облікового запису власника "tom" або з груповими дозволами групи "www", залежно від конфігурації.
Також передбачається стандартне середовище Gnu / Linux або Unix, і передбачається, що читач розуміє систему управління доступом Unix з окремими дозволами для читання (r), write (w) та виконання / доступу до каталогу (x), розділеними на три блоки (користувач, група, інше).
Перш ніж продовжувати обговорювати конкретні налаштування, може бути корисним перерахувати умови, які ми хочемо задовольнити:
- Щоб веб-сайт працював, веб-сервер повинен мати доступ для читання до всіх файлів, що складають сайт, та доступ до каталогу до всіх каталогів, що складають сайт.
- Для безпечної роботи веб-сервер не повинен мати доступ для запису до жодного з файлів, якими він обробляє.
- Для безпечної роботи веб-скрипт, керований шахрайським користувачем, не повинен мати доступу для читання до файлів, що належать іншому користувачеві.
- Щоб власник працював на своєму власному сайті за допомогою CLI, користувач повинен мати доступ для читання та запису до власних файлів.
- Для захисту файлів від несанкціонованого доступу інших користувачів з допомогою інтерфейсу командного рядка, «інший» блок не повинен мати НЕ набір дозволів.
На жаль, на спільному хості ви можете мати лише 4 з 5. Я не знаю, як ви зможете виконати всі п’ять умов спільного хоста.
Наскільки мені відомо, двома різними конфігураціями використовуються спільні провайдери хостів. Обидва розглянуті нижче, а також дозволи на використання для кращого захисту файлів і каталогів, а також умовам, яким конфігурація не відповідає.
Налаштування 1: Веб-сервер працює як власник
Це найпоширеніша конфігурація AFAIK. Веб-сервер працює як власник файлів. Це означає, що шахрайський користувач не може використовувати свого користувача веб-сервера для запуску сценарію для читання файлів іншого користувача. Цей тип конфігурації також захищає користувачів один від одного в CLI.
Однак це також означає, що ми не можемо мати окремих дозволів для власника та веб-сервера. Щоб задовольнити умову 2 з цим типом налаштування, вам потрібно обмежити дозволи власника на запис для власника, щоб не допустити доступ для запису веб-сервера до всього, крім каталогу завантаження.
Дозволи:
Directories: 500 r-x --- --- tom.tom
Files: 400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.: 700 rwx --- --- tom.tom
На жаль, це означає, що умову 4 не можна виконати. Тобто сайт не може підтримуватися через CLI. Власника буде обмежено використовувати якусь веб-панель інформаційної панелі для доступу до сайту (моя рекомендація полягає в тому, щоб власник зберігав копію на певному сервері постановки, де він має необмежений доступ, і відображав дзеркальні зміни, внесені на сервері постановки на спільний хост ).
Конфігурація 2: Веб-сервер працює як член групи www
Ця конфігурація використовується деякими (IMHO) менш професійними постачальниками спільного хост-рішення. Веб-сервер працює як член групи www і йому надається необхідний доступ для читання через груповий блок:
Дозволи:
Directories: 750 rwx r-x --- tom.www
Files: 640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.: 770 rwx rwx --- tom.www
Ці налаштування мають перевагу в тому, що надають власникові повний доступ до своїх файлів через CLI, а веб-сервер обмежує лише доступ для читання.
Однак він також не задовольняє умову 3. Тобто він дозволяє шахрайському користувачеві на спільному хості (або хакері, який в якості компрометованого сайту іншого користувача, що ділиться з хостом) запускати сценарій для читання будь-якого файлу, який може бути прочитаний веб-сервер. Це дає шахрайському скрипту доступ до файлу settings.php з обліковими даними бази даних, завдяки чому тривіально повністю зайняти сайт.
Моя рекомендація - уникати такого типу конфігурації.
Додаток: Наскільки небезпечно використовувати спільний хост?
Я, звичайно, не розміщував би нічого чутливого, наприклад, номери кредитних карток або медичні записи, на спільному хості. Але спільний хостинг - це дешево, і в цьому є привабливість. Я використовую спільний хостинг для декількох моїх сайтів. Мене ще не зламали, але я знаю, що ризик існує, і я готовий до дня, коли це станеться. Якщо мене зламають, я просто видалю все на спільному хості та переустановлюю сайт із дзеркальної копії, яку я зберігаю на захищеному сервері.
У "config 2" основна проблема - інші . Якщо якийсь інший веб-сайт, з яким ви ділитеся хостом, стає порушеним, ваш веб-сайт також обідає. Зробити безпеку залежною від іншої сторони, яку ви не знаєте, і не маєте контролю над нею, не є хорошою ідеєю. Ось чому моя рекомендація полягає в тому, щоб уникати хостингових типів "config 2".
"Конфігурація 1" ви лише контролюєте безпеку свого веб-сайту. Це краще (зокрема, якщо ви знаєте, що робите). Але це не дурень. Ніхто не ідеальний, і якщо ви перейдете на сайт і ваш сайт порушений, зловмисник матиме доступ до кожного файлу, що зберігається на тому хості, який належить вам. Іншими словами, щоб мінімізувати збитки, коли вас зламали, не тримайте на цьому хості нічого , що спричинить шкоду, якщо хтось інший отримає доступ до нього. Зокрема, не зберігайте свою електронну пошту на цьому спільному хості. Зазвичай є багато чутливих даних в електронній пошті, тому ви не хочете, щоб вони були поблизу веб-сервера, який виконується як "ви".
І якщо ваш веб-додаток обробляє конфіденційні дані, переконайтеся, що ваш бюджет передбачає виділений хост або VPS.
Ви також можете ознайомитися з цим посібником із забезпечення безпеки файлів та прав власності на Drupal.org.