Права доступу до файлів на хостингу: як три цифри вирішують, хто господар вашого сайту

Уявіть: ви приходите додому, а двері навстіж. Не зламані - просто ви самі забули їх зачинити. Саме так виглядає 80% зламаних сайтів. Не якийсь геніальний хакер обійшов ваш захист - ви самі залишили файли з правами 777 і фактично повісили на сервер табличку "заходьте, беріть що хочете". За моєю практикою, неправильні chmod-права - причина номер один, чому CMS-сайти потрапляють у чорні списки пошуковиків. І найгірше - виправити це можна за 10 хвилин, але більшість власників сайтів навіть не знають, де дивитися.

Що таке права доступу і чому вони важливіші за будь-який плагін безпеки

Кожен файл і кожна папка на вашому сервері мають три набори дозволів: для власника (owner), для групи (group) і для всіх інших (others). Кожен набір визначає три дії: читати (read), записувати (write), виконувати (execute). Ці дії кодуються цифрами: 4 - читання, 2 - запис, 1 - виконання. Сума дає фінальне число.

Коли ви бачите 755 або 644 - це не магічні заклинання. Це конкретний набір інструкцій:

• 7 (4+2+1) - повний доступ: читати, писати, виконувати
• 5 (4+0+1) - читати і виконувати, але не змінювати
• 4 (4+0+0) - тільки читати, нічого більше
• 0 - доступ повністю закритий

Тобто 755 означає: власник може все, група і решта - тільки читати та виконувати. А 777? Це як видати ключі від квартири кожному перехожому на вулиці. Ніколи не ставте 777 на production-сервері. Ніколи. Навіть "тимчасово". Тимчасово в IT - це назавжди.

Таблиця прав: що ставити на файли, папки і конфіги

Я бачив десятки форумів, де новачкам радять "просто поставити 777, якщо щось не працює". Це як порада "просто зніміть замок з дверей, якщо ключ не повертається". Ось орієнтири, перевірені роками роботи з WordPress, Joomla, Laravel і чистим PHP:

Зверніть увагу: папка uploads часто стає вектором атаки. Якщо хтось завантажить PHP-шелл під виглядом картинки, а у папці дозволено виконання - гра закінчена. Тому окрім chmod варто додати в .htaccess цієї папки рядок, що забороняє виконання PHP.

Як перевірити та змінити права: три способи від простого до просунутого

Добре, теорію ми розібрали. Тепер руки на клавіатуру.

1. Файловий менеджер cPanel / Plesk. Відкриваєте File Manager, клікаєте правою кнопкою на файл або папку, вибираєте "Change Permissions". Бачите чекбокси та числове поле. Простий, візуальний спосіб. Але повільний, якщо треба змінити сотні файлів.
2. FTP-клієнт (FileZilla, WinSCP). Правою кнопкою - "File Permissions". Можна застосувати рекурсивно до всіх вкладених папок і файлів. WinSCP навіть дозволяє задати окремі права для файлів і папок за один прохід.
3. SSH-команди. Найшвидший і наймогутніший варіант. Два рядки вирішують 90% проблем:

find /var/www/html -type d -exec chmod 755 {} ;
find /var/www/html -type f -exec chmod 644 {} ;

Перша команда знаходить усі папки і ставить 755. Друга - всі файли і ставить 644. Після цього вручну підтягуєте конфіги до 600. П'ять хвилин - і ваш сайт закритий як сейф.

Типові помилки, що відкривають двері хакерам

За 15 років я зібрав колекцію "улюблених" помилок. Деякі з них зустрічаю щотижня.

"Більшість зломів відбуваються не через вразливості коду, а через неправильну конфігурацію сервера. Неправильні file permissions - це low-hanging fruit для будь-якого атакуючого." - OWASP Server Security Cheat Sheet

Помилка №1: chmod 777 на всьому сайті. Класика. Хтось читає форум, де "експерт" радить поставити 777, бо "інакше плагін не працює". Плагін запрацював. А через тиждень на сайті з'являється фармацевтичний спам.

Помилка №2: wp-config.php з правами 644. Так, це краще за 777. Але конфіг, де лежать логін і пароль до бази даних, повинен мати 600. На shared-хостингу - мінімум 640. Інакше будь-який сусідній акаунт може прочитати ваші облікові дані.

Помилка №3: забути про власника файлу (ownership). Chmod - це половина рівняння. Друга половина - chown. Якщо файли належать root, а веб-сервер працює як www-data, то навіть з правами 755 сайт може не працювати. Або навпаки - якщо все належить www-data, будь-яка RCE-вразливість дає повний контроль.

Помилка №4: ігнорувати umask. Новостворені файли отримують права за замовчуванням. Якщо ваш umask налаштований як 000, кожен новий файл буде з правами 666. Перевірте umask у терміналі і встановіть 022 - це дасть нові файли з правами 644.

Shared-хостинг vs VPS: різні правила гри

На shared-хостингу ви ділите сервер з десятками або сотнями інших сайтів. Це як комуналка. Ваші сусіди - незнайомці, і деякі з них можуть бути цікавими у поганому сенсі слова. Тому:

• Конфіги - тільки 600 або 640
• Перевірте, чи увімкнений suPHP або PHP-FPM - вони запускають скрипти від імені вашого користувача, а не загального apache
• Якщо провайдер не підтримує suPHP/FPM - серйозно подумайте про зміну хостингу

На VPS або виділеному сервері ви - єдиний мешканець. Але і відповідальність повністю на вас. Тут важливо правильно налаштувати ownership:

chown -R www-data:www-data /var/www/html - для Debian/Ubuntu
chown -R nginx:nginx /var/www/html - для серверів на Nginx

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

Автоматизація: щоб не перевіряти вручну кожного разу

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

1. Bash-скрипт на cron. Створіть файл fix-permissions.sh з командами find/chmod/chown і запускайте його щоночі. Якщо щось зіпсується - наступний запуск виправить.
2. Wordfence / Sucuri Scanner (для WordPress). Ці плагіни перевіряють права на ключових файлах і попереджають, якщо щось не так.
3. Ansible / Chef / Puppet. Для тих, хто керує кількома серверами. Описуєте бажаний стан один раз - інструмент підтримує його автоматично.
4. Git-хуки. При деплої через Git можна додати post-receive хук, що автоматично фіксить права після кожного оновлення коду.

Мій улюблений підхід - комбінація: Git-хук для коду + cron-скрипт як страхувальна сітка. Надмірність? Можливо. Але я ще жодного разу не прокинувся від листа "Ваш сайт заражено".

А що робити прямо зараз?

Відкрийте термінал або файловий менеджер. Подивіться на права wp-config.php (або .env, або будь-якого конфігу з паролями). Якщо там стоїть щось відмінне від 600 - змініть прямо зараз. Це займе рівно 10 секунд і може врятувати вам тижні нервів.

Три цифри. Саме стільки відділяє захищений сайт від відкритого запрошення для зловмисників. Ви вже перевірили свої?