Накратко: За правата за файлове на уеб сървъра важи един принцип: потребителят, под който работи PHP, може да чете собствения си код, но не и да го променя. Права за запис получават само папките за качвания, кеш и temp, и там не се изпълнява PHP. Права като 777 нямат място на продуктивен сървър.
Защо правата за файлове правят разликата след проникване
Когато атакуващи изпълняват код на сървър през уязвимост, този код работи с правата на PHP процеса. Каквото може този потребител, може и атакуващият. Именно тук се решава дали от едно проникване ще стане трайна задна вратичка.
С PHP2Shell този сценарий през октомври 2026 г. стана съвсем конкретен. Уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват изпълнение на злонамерен код без вход в системата. Те са поправени от 21.10.2026 в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Добрите права за файлове не предотвратяват атака, но предотвратяват внедреният код да пренапише трайно Вашето приложение.
В много инсталации целият код принадлежи на потребителя на уеб сървъра, за да работят актуализациите с натискане на бутон. Това е удобно, но е точно констелацията, която атакуващите търсят.
Основният принцип: разделяне на собственика и потребителя по време на изпълнение
Разумно е разделение на две роли. Собственик, например deploy потребител, притежава файловете и внася актуализациите. PHP процесът работи под друг потребител и има право само да чете чрез групата.
| Област | Собственик : група | Права за файлове | Права за папки |
|---|---|---|---|
| Програмен код | deploy : seite1 | 640 | 750 |
| Конфигурация с пароли | deploy : seite1 | 640 | – |
| Качвания, кеш, temp | seite1 : seite1 | 640 | 750 |
| Логове | root или seite1 | 640 | 750 |
Самият уеб сървър, например Nginx, при PHP-FPM се нуждае само от достъп за четене до статични файлове като изображения и CSS. Този достъп получавате чрез групата или чрез целево правило за достъп. Който поддържа няколко уебсайта, дава на всеки собствен потребител по време на изпълнение; как това си взаимодейства с пуловете, е описано в наръчника open_basedir и изолация за всеки уебсайт.
Проверка на правата за файлове на уеб сървъра
Преди да промените нещо, си осигурете преглед. Следните команди не променят нищо.
# Под кой потребител работят PHP процесите?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Файлове и папки, достъпни за запис от всички
find /var/www -perm -o+w -ls
# Файлове, принадлежащи на потребителя на уеб сървъра (пример www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Права на конфигурационните файлове
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Записите, достъпни за запис от всички, почти винаги са грешка. PHP файловете, принадлежащи на потребителя по време на изпълнение, показват, че той може да променя своя код. Подозрителни са и отделни файлове, чийто собственик или права се различават от съседните. Това може да е указание за внедрени файлове, както е описано в наръчника Разпознаване и премахване на уеб шелове.
Корекция на правата: стъпка по стъпка
Променяйте правата само след архивиране и по възможност първо в тестова среда. Ако има подозрение за проникване, запазете предварително следите, защото собственикът и времевите печати тогава са доказателствени средства.
SITE=/var/www/seite1
# Собственик: deploy потребителят, група: потребителят по време на изпълнение
sudo chown -R deploy:seite1 "$SITE"
# Папки 750, файлове 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Само тези папки може да записва PHP (адаптирайте пътищата към приложението)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
След това проверете уебсайта изцяло: начална страница, вход, формуляри, качване на изображения, кешове. Кои папки приложението трябва да записва, е посочено в системните изисквания на производителя на неговата официална страница.
chmod -R 777, за да се реши бързо проблем, отваря сървъра за всеки локален потребител и за всеки внедрен процес. Вместо това коригирайте собственика и групата.
Предотвратяване на изпълнението на PHP в папки с права за запис
Правата за запис са наполовина по-опасни, ако там не може да се изпълнява код. Забранете изпълнението на PHP в папките за качвания и кеш на ниво уеб сървър. За Apache в конфигурацията на VirtualHost:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
За Nginx е достатъчен location блок, който отхвърля заявки към PHP файлове в тези папки. Правилото принадлежи в конфигурацията на сървъра, не в .htaccess в папката за качвания, която атакуващ с права за запис би могъл да промени отново.
Допълнително си струва да погледнете umask на deploy потребителя, за да не се създават новите файлове автоматично прекалено отворени. Стойност 027 води до 640 за файловете и 750 за папките. На собствени сървъри тази отговорност е изцяло Ваша; какво друго спада към нея, описва Сигурност на root сървъри и vServer със собствени сили.
Специални случаи: хостинг панели, споделен хостинг и deployments
Не всеки сървър може да се настрои по учебник. Хостинг панели като Plesk или cPanel създават собствени потребители и права и при някои действия ги нулират. Променяйте правата там по възможност чрез функциите на панела или след актуализации на панела проверявайте дали настройките Ви още важат.
При споделен хостинг обикновено имате само един потребител за всичко. Разделянето на собственик и потребител по време на изпълнение тогава не е възможно. Толкова по-важни са оскъдните права върху конфигурационните файлове, никакви права 777 и изключването на изпълнението на PHP в папките за качвания, доколкото хостинг доставчикът го позволява.
Който работи с автоматични deployments, трябва да задава правата в самия deployment скрипт. Иначе всяка нова версия възстановява старото, прекалено отворено състояние. Кратка проверка в края на deployment, например с командата за файлове с права за запис от по-горе, надеждно улавя такива връщания назад и може да се вгради във всеки pipeline без голямо усилие.
Как конкретно помага PHP SOS?
- Установяваме собственика, правата и потребителя по време на изпълнение на всички уебсайтове на сървъра.
- Определяме концепция за правата, която пасва на Вашето приложение и на пътя на актуализациите му.
- Въвеждаме права и забрани за изпълнение и след това тестваме уебсайта изцяло.
- Документираме концепцията, за да не я размиват deployments и актуализациите.
Как това е вградено в трайна защита, описва услугата Заздравяване на сървъри за PHP уеб сървъри.
Често задавани въпроси
Допустими ли са някога права 777?
На продуктивен сървър на практика никога. С 777 всеки потребител на системата може да създава и променя файлове. Ако приложението не работи без 777, обикновено е зададен грешен собственик, а не са твърде оскъдни правата.
Защо уеб сървърът не бива да може да променя собствените си файлове?
Защото внедреният код работи с правата на уеб сървъра. Ако уеб сървърът може да записва PHP файлове, атакуващият може да манипулира съществуващи скриптове или да създаде нови задни вратички. Ако собственикът и потребителят по време на изпълнение са разделени, кодът остава защитен от запис.
Как да актуализирам CMS, ако уеб сървърът не може да записва?
Актуализациите тогава минават през собственика, например чрез WP-CLI, Composer или deployment, а не през бутона за актуализация в административната част. Това е малко по-трудоемко, но внедреният код не може да променя програмни файлове.
Какви права трябва да има конфигурационният файл с паролата за базата данни?
Възможно най-малко: четим за потребителя на PHP, за никого другиго. Обичайни са 640 със съответната група или 400, ако потребителят на PHP е самият собственик.