Безпечні права на файли та каталоги WordPress: практичне налаштування

Що означають права 644, 755 і 777

У Linux права записують трьома цифрами: окремо для власника, групи та інших користувачів. Значення 4 означає читання, 2 — запис, а 1 — виконання. Для звичайного файлу 644 означає: власник може читати й змінювати файл, а група та інші користувачі — лише читати його.

Для каталогу право виконання означає можливість заходити в каталог і звертатися до його вмісту. Тому каталоги зазвичай мають права 755: власник може читати, змінювати та переглядати вміст, а інші користувачі — переглядати й відкривати файли без права запису.

Права 777 надають читання, запис і виконання всім. Це майже ніколи не є виправданим рішенням для WordPress. Якщо плагін або хостинг вимагає 777, спочатку потрібно з'ясувати проблему з власником, групою, PHP-FPM або політикою запису, а не просто розширювати доступ.

• Файли WordPress: базово 644.
• Каталоги: базово 755.
• wp-config.php: 640 або суворіше, якщо це сумісно з конфігурацією сервера.
• Права 777 не використовуйте для файлів, каталогів або uploads.

Рекомендована схема для структури WordPress

Для більшості сайтів достатньо почати з 644 для файлів і 755 для каталогів. Ця схема дає вебсерверу можливість читати сайт, але не відкриває запис усім користувачам системи. Водночас фактичні вимоги залежать від моделі хостингу: PHP може працювати від імені користувача сайту, вебсерверного користувача або окремого пулу PHP-FPM.

wp-config.php містить дані підключення до бази, ключі безпеки та інші важливі параметри. Його можна обмежити до 640, якщо процес PHP має доступ через власника або групу. Значення 600 ще суворіше, але працюватиме лише тоді, коли PHP справді запускається від імені власника файла.

На деяких конфігураціях wp-config.php можна розмістити на рівень вище від кореня WordPress. Це зменшує ризик прямого доступу до файла, але не замінює правильні права та налаштування вебсервера.

• Кореневі PHP-файли, .htaccess та інші службові файли: зазвичай 644.
• wp-admin, wp-includes, wp-content та вкладені каталоги: зазвичай 755.
• Файли в wp-content/uploads: зазвичай 644, каталоги — 755.
• Файли резервних копій, дампів бази та приватних ключів не повинні лежати у публічній директорії з відкритим читанням.

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 640 /path/to/wordpress/wp-config.php

Чому ці команди не можна запускати без перевірки

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

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

Власник і група важливіші за самі цифри

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

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

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

• Перевірте, хто є власником кореня WordPress і wp-content.
• Переконайтеся, що один сайт не має можливості змінювати файли іншого.
• З'ясуйте, від імені якого користувача працює PHP-FPM або інший PHP-обробник.
• Для масової зміни власника використовуйте точний шлях і заздалегідь створіть резервну копію.

stat -c '%A %U:%G %n' /path/to/wordpress/wp-config.php
find /path/to/wordpress -maxdepth 2 -printf '%M %u:%g %p\n' | head -50

Особливий контроль каталогу wp-content/uploads

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

Одних прав 755 недостатньо, щоб заборонити виконання PHP. Вони визначають доступ до файлової системи, а можливість виконання залежить також від конфігурації Apache, Nginx, PHP-FPM та правил обробки розширень. Тому в uploads потрібно окремо заборонити виконання PHP-коду на рівні вебсервера.

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

• Не встановлюйте 777 для wp-content/uploads.
• Забороніть виконання PHP у каталозі завантажень на рівні вебсервера.
• Перевірте, що завантажені файли не можна відкрити за URL, якщо вони мають бути приватними.
• Обмежте типи та розмір файлів засобами WordPress, сервера або WAF.

Важливе застереження для Apache і Nginx

Правила для заборони виконання PHP залежать від вебсервера та його конфігурації. Для Apache це може бути окреме правило в конфігурації каталогу, а для Nginx — коректна схема location і передавання запитів до PHP-FPM. Неправильний універсальний фрагмент може заблокувати всі файли або створити хибне відчуття захисту.

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

Як перевірити права після міграції або відновлення

Міграції, розпакування архівів і відновлення бекапів часто змінюють власника або додають файли з надмірними дозволами. Плагін також може створити каталог із правами, які відрізняються від загальної схеми. Перевіряйте не лише корінь сайту, а й wp-content, uploads, plugins, themes та нові файли.

Для пошуку надмірних прав корисно окремо перевірити файли й каталоги. Не кожен результат автоматично означає вразливість, але 666, 775 або 777 потребують пояснення. Особливо уважно ставтеся до PHP-файлів, які з'явилися не під час планового оновлення.

• Знайдіть файли, доступні для запису всім користувачам.
• Знайдіть каталоги з правами 777 або 775 і перевірте, навіщо вони потрібні.
• Перевірте дату, власника та походження нових PHP-файлів.
• Після перевірки протестуйте сайт, адмінпанель, медіатеку та роботу кешування.

find /path/to/wordpress -type f -perm -002 -ls
find /path/to/wordpress -type d \( -perm -002 -o -perm -020 \) -ls
find /path/to/wordpress -type f -name '*.php' -printf '%M %u:%g %TY-%Tm-%Td %p\n' | sort

Типові помилки та безпечний порядок дій

Найпоширеніша помилка — виправляти помилку запису командою chmod -R 777. Це маскує проблему з власником або групою й одночасно збільшує наслідки компрометації іншого облікового запису на сервері.

Друга помилка — встановити 640 для всіх файлів без перевірки. Частина серверних конфігурацій не зможе прочитати потрібні файли, якщо PHP або вебсервер не входить до відповідної групи. Так само не варто бездумно робити всі каталоги 700: сайт може втратити доступ до ресурсів.

Працюйте поетапно: створіть резервну копію, зафіксуйте поточні права, змініть один сайт або тестову копію, перевірте функції та лише потім застосовуйте зміни на продакшні. Додатково обмежте доступ до SSH, оновлюйте WordPress і плагіни, використовуйте резервні копії та моніторинг змін.

• Не плутайте права доступу з правилами вебсервера: потрібні обидва рівні захисту.
• Не видаляйте незнайомі файли без резервної копії та аналізу.
• Не залишайте архіви міграції у публічному каталозі.
• Зберігайте окремі резервні копії поза сервером і періодично перевіряйте їх відновлення.