# Основи на PHP за администратори

> Основи на PHP за администратори без опит в разработката: двоични файлове, нива на php.ini, FPM пулове, важни команди, логове и контролен списък след PHP2Shell.

Източник: https://phpsos.de/bg/php/php-grundwissen-admins/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** За администратори без опит в разработката са достатъчни пет основи, за да експлоатират PHP сигурно: PHP се състои от няколко програми (команден ред, PHP-FPM, модул на Apache), всяка със собствена версия; настройките действат на нива от php.ini до приложението; PHP-FPM разпределя заявките между worker процеси в пулове; актуализацията действа едва след рестартиране на всички процеси; а логовете са най-важната следа, когато нещо не е наред. Който познава тези точки, може бързо и доказуемо да затваря уязвимости като PHP2Shell.

## От какво се състои PHP на един сървър

PHP не е една-единствена програма. На типичен Linux сървър се намират няколко варианта, всеки свързан чрез сървърен интерфейс (SAPI):

| Вариант | Типично име | За какво |
|---|---|---|
| Команден ред (CLI) | `php`, `php8.3` | cron задачи, Composer, скриптове за поддръжка |
| PHP-FPM | `php-fpm`, `php-fpm8.3` | уеб заявки зад Nginx или Apache |
| Модул на Apache | `mod_php`, `libphp` | уеб заявки директно в процеса на Apache |
| CGI | `php-cgi` | по-стари конструкции |

Всеки вариант може да има друга версия и друг php.ini. На много сървъри освен това работят паралелно няколко версии на PHP, например 8.2 и 8.4. При актуализация всяка трябва да се разгледа поотделно. Как работят интерфейсите, обяснява [PHP-FPM, обяснен](https://phpsos.de/bg/php/php-fpm-erklaert/).

Кой вариант действително обслужва Вашите уебсайтове, установявате чрез работещите процеси и конфигурацията на уеб сървъра:

```bash
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php     # зарежда ли Apache модул за PHP?
ls /run/php/ 2>/dev/null                    # FPM сокети, често за версия и пул
```

Колоната с времето на стартиране е по-късно важна при рестартирането: всички PHP процеси трябва да са стартирани след момента на актуализацията. Ако процесите работят под различни потребители, това сочи отделни пулове, което е добре. Ако в Apache се появи модул за PHP, макар всички уебсайтове да трябва да работят през FPM, това е знак за наследство, което трябва да бъде премахнато. За хостинг интерфейси като Plesk или cPanel важи същият принцип, само че интерфейсът показва версиите и handler-ите за всеки уебсайт; меродавно остава онова, което действително работи като процес.

## Най-важните команди за администратори

```bash
php -v                    # версия на командния ред
php --ini                 # заредения php.ini и допълнително прочетените директории
php --ini=diff            # от PHP 8.5: отклонения от стандартните стойности
php -m                    # вградени и заредени модули
php --ri session          # настройки на разширение
php -l datei.php          # проверка на синтаксиса без изпълнение
php-fpm8.3 -v             # версия на двоичния файл на FPM (името според дистрибуцията)
php-fpm8.3 -t             # тест на конфигурацията на FPM без рестартиране
systemctl status php8.3-fpm
```

Две бележки от ръководството: `php -l` открива синтактични грешки, но не и грешки, които възникват едва при изпълнение. И `php -i` извиква `phpinfo()`; изходът не принадлежи в публични файлове в уеб директорията.

## Как действат настройките на PHP

Една настройка може да се задава на няколко места. Кой къде какво може да променя, определя режимът на промяна на всяка директива:

1. **php.ini и conf.d:** основна конфигурация за вариант, четена при старта.
2. **FPM пул:** `php_value` и `php_admin_value` за всеки пул. Стойности, зададени с `php_admin_value`, приложението според ръководството не може да презапише с `ini_set()`.
3. **Ниво на директория:** `.user.ini` при FPM или `.htaccess` при mod_php, само за директиви в режим `INI_PERDIR` или `INI_ALL`.
4. **Приложение:** `ini_set()` по време на изпълнение, само за директиви в режим `INI_ALL`.

Пример: `memory_limit` е в режим `INI_ALL`, т.е. може да бъде променян от приложението. `post_max_size` е `INI_PERDIR` и не може да се променя с `ini_set()`. Затова php.net изисква при временните мерки срещу PHP2Shell стойностите да се задават така, че приложенията да не могат да ги презаписват. Подробности за нивата обяснява [php.ini, обяснен](https://phpsos.de/bg/php/php-ini-erklaert/).

## PHP-FPM пуловете накратко

Пулът е група от worker процеси със собствен потребител, собствен сокет и собствени настройки. Най-важните директиви според ръководството:

```ini
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic                 ; static, dynamic или ondemand
pm.max_children = 20         ; най-много 20 едновременни заявки
pm.max_requests = 500        ; обновяване на worker след 500 заявки
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
```

Отделен пул за всеки уебсайт със собствен потребител разделя уебсайтовете един от друг. `security.limit_extensions` по подразбиране е `.php .phar` и пречи на FPM да изпълнява други файлови разширения освен PHP. `clear_env` е по подразбиране включен и държи променливите на средата далеч от worker процеса.

## Логове: накъде да гледат администраторите

PHP записва грешките в зададената с `error_log` цел, PHP-FPM допълнително в собствения си лог, а при бавни заявки в slowlog с backtrace. Към това идват логовете за достъп и за грешки на уеб сървъра. Погрижете се `display_errors` да е изключен в продукция, а `log_errors` – включен: грешките принадлежат в лога, не на уеб страницата. Логовете трябва освен това да се ротират и да се пазят за определен период, за да ги има още в критичен случай. След PHP2Shell специализираната преса препоръчва сървърните логове да се пазят от 20.10.2026 г. Силен предупредителен сигнал е PHP-FPM или процес на уеб сървъра, който стартира шел; как да го разпознаете, е описано в [Предупредителен сигнал: уеб сървърът стартира шел](https://phpsos.de/bg/blog/webserver-startet-shell/).

## Контролен списък за администратори след PHP2Shell

1. Изброете всички варианти и версии на PHP на сървъра, дори неизползваните.
2. Проверете състоянието на пакетите; при backport на дистрибуцията претърсете changelog за CVE-2026-109618 и CVE-2026-109619.
3. Актуализирайте до 8.5.12, 8.4.27, 8.3.36 или 8.2.35, респективно до потвърдения backport.
4. Рестартирайте PHP-FPM, Apache и LiteSpeed и проверете времената на стартиране на процесите.
5. Контролна проверка с `php -r 'var_dump(ini_get("memory_hard_limit_percent"));'`; `bool(false)` според ръководството означава засегната версия.
6. Запазете логовете и ги проверете за нередности.

Как да докажете надеждно версията и състоянието на пачовете, описва [Правилна проверка на версията на PHP и състоянието на пачовете](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Как помага PHP SOS конкретно?

В [договора за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/) поемаме основната грижа за PHP заедно с Вашия екип:

- **Опис:** всички варианти на PHP, версии, пулове и места на конфигурацията за всеки сървър.
- **Конфигурация:** стойности, свързани със сигурността, зададени с `php_admin_value`, пулове за всеки уебсайт, разделени.
- **Актуализации:** внедряване, рестартиране, контрол и документиране при всяко издание за сигурност.
- **Предаване на знания:** Обясняваме на Вашите администратори какво сме променили и защо.


## Често задавани въпроси

**Защо php -v показва друга версия от уебсайта?**  
Командният ред, PHP-FPM и модулът на Apache са отделни програми със собствена версия и собствен php.ini. php -v показва само командния ред. За уебсайта важи версията на двоичния файл, който действително обработва заявките.

**Кой php.ini важи на моя сървър?**  
Това показва php --ini за командния ред. За PHP-FPM най-често има собствен php.ini и допълнителни файлове на пуловете. От PHP 8.5 php --ini=diff показва кои стойности се различават от стандартните.

**Каква е разликата между php_value и php_admin_value?**  
И двете задават настройки в един FPM пул. Стойности с php_admin_value приложението според ръководството не може да презапише с ini_set(). За настройки, свързани със сигурността, php_admin_value затова е правилният избор.

**Достатъчна ли е актуализация без рестартиране?**  
Не. Работещите PHP процеси запазват стария код в паметта. След актуализация PHP-FPM, Apache с mod_php или LiteSpeed трябва да се рестартират, иначе продължава да работи уязвимата версия.

## Източници

- [Ръководство на PHP: Опции на командния ред](https://www.php.net/manual/en/features.commandline.options.php)
- [Ръководство на PHP: Конфигурация на FPM](https://www.php.net/manual/en/install.fpm.configuration.php)
- [Ръководство на PHP: Основни настройки](https://www.php.net/manual/en/ini.core.php)
- [php.net: Съобщения за сигурност](https://www.php.net/)