Накратко: За администратори без опит в разработката са достатъчни пет основи, за да експлоатират 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, обяснен.
Кой вариант действително обслужва Вашите уебсайтове, установявате чрез работещите процеси и конфигурацията на уеб сървъра:
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-ите за всеки уебсайт; меродавно остава онова, което действително работи като процес.
Най-важните команди за администратори
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
Една настройка може да се задава на няколко места. Кой къде какво може да променя, определя режимът на промяна на всяка директива:
- php.ini и conf.d: основна конфигурация за вариант, четена при старта.
- FPM пул:
php_valueиphp_admin_valueза всеки пул. Стойности, зададени сphp_admin_value, приложението според ръководството не може да презапише сini_set(). - Ниво на директория:
.user.iniпри FPM или.htaccessпри mod_php, само за директиви в режимINI_PERDIRилиINI_ALL. - Приложение:
ini_set()по време на изпълнение, само за директиви в режимINI_ALL.
Пример: memory_limit е в режим INI_ALL, т.е. може да бъде променян от приложението. post_max_size е INI_PERDIR и не може да се променя с ini_set(). Затова php.net изисква при временните мерки срещу PHP2Shell стойностите да се задават така, че приложенията да не могат да ги презаписват. Подробности за нивата обяснява php.ini, обяснен.
PHP-FPM пуловете накратко
Пулът е група от worker процеси със собствен потребител, собствен сокет и собствени настройки. Най-важните директиви според ръководството:
[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 или процес на уеб сървъра, който стартира шел; как да го разпознаете, е описано в Предупредителен сигнал: уеб сървърът стартира шел.
Контролен списък за администратори след PHP2Shell
- Изброете всички варианти и версии на PHP на сървъра, дори неизползваните.
- Проверете състоянието на пакетите; при backport на дистрибуцията претърсете changelog за CVE-2026-109618 и CVE-2026-109619.
- Актуализирайте до 8.5.12, 8.4.27, 8.3.36 или 8.2.35, респективно до потвърдения backport.
- Рестартирайте PHP-FPM, Apache и LiteSpeed и проверете времената на стартиране на процесите.
- Контролна проверка с
php -r 'var_dump(ini_get("memory_hard_limit_percent"));';bool(false)според ръководството означава засегната версия. - Запазете логовете и ги проверете за нередности.
Как да докажете надеждно версията и състоянието на пачовете, описва Правилна проверка на версията на PHP и състоянието на пачовете.
Как помага PHP SOS конкретно?
В договора за поддръжка на сигурността поемаме основната грижа за 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 трябва да се рестартират, иначе продължава да работи уязвимата версия.