Накратко: Който иска да заздрави сървъра си за PHP, се грижи една-единствена уязвимост да не отваря целия сървър. Разделяме уебсайтовете един от друг, настройваме PHP и уеб сървъра сигурно, ограничаваме правата и достъпите и документираме всяка промяна. Така щетите остават по-малки, ако все пак нещо се случи.
Защо заздравяването стана по-важно след PHP2Shell
PHP2Shell показа колко бързо една уязвимост в самия PHP се превръща в проблем за всички уебсайтове на един сървър. Чрез CVE-2026-109618 и CVE-2026-109619 атакуващите могат да изпълняват код без удостоверяване. Пачът затваря тази врата. Заздравяването отговаря на друг въпрос: какво може да направи някой, който въпреки това влезе, през тази или през следващата уязвимост?
На незаздравен сървър често всички уебсайтове работят под един и същи потребител, PHP има право да изпълнява системни команди, а данните за достъп са четими за всички процеси. Проникване в малък страничен сайт стига тогава чак до онлайн магазина. Доброто заздравяване разделя тези области. То не е еднократно действие, а базово състояние, което трябва да се запази при всеки нов уебсайт и при всяка смяна на версия.
Заздравяване на сървър за PHP: какво конкретно настройваме
Изолация за всеки уебсайт
Всеки уебсайт получава собствен системен потребител и собствен PHP-FPM пул. С open_basedir и подходящи права върху файловете приложението вижда само собствената си директория. Повече има на страницата open_basedir и изолация за всеки уебсайт.
Сигурна PHP конфигурация
Настройваме php.ini и конфигурацията на пула така, че приложенията да не могат сами да презаписват стойности, свързани със сигурността. Откъс как може да изглежда това в един FPM пул:
; Стойностите се задават твърдо в FPM пула и не могат да се променят чрез ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Кои функции могат допълнително да се блокират, зависи от приложението. Бележки по темата има на страниците Как да конфигурирате php.ini сигурно и Правилно използване на disable_functions.
Права върху файловете и достъп за запис
Уеб сървърът има право да пише само там, където е нужно, например в папката за качвания. В директориите за качвания изпълнението на PHP се забранява. Програмният код принадлежи на друг потребител, различен от този, под който работи PHP. Принципите обяснява страницата Права върху файловете на уеб сървъра.
Достъпи, услуги и протоколи
SSH само с ключ, администраторски интерфейси с двуфакторно удостоверяване, ненужни услуги и портове затворени. Логовете се съхраняват и архивират така, че да са налични и след инцидент. Резервните копия проверяваме дали могат да бъдат възстановени.
Уеб сървър и хедъри за сигурност
И самият уеб сървър е част от заздравяването: скриване на данните за версията, изключване на списъците с директории, блокиране на достъпа до конфигурационни файлове, архиви и файлове на системи за контрол на версиите и допълнителна защита на администраторските области, например чрез разрешаване само на определени IP адреси. Хедъри за сигурност като Content-Security-Policy или HSTS защитават посетителите на Вашия уебсайт в браузъра.
Какво често намираме при описа
Много слабости се повтарят от сървър на сървър. Типични са няколко уебсайта под общ потребител, публично достъпни интерфейси на бази данни, стари тестови инсталации в поддиректории, забравени PHP версии до актуалната и резервни копия, които лежат в уеб директорията и могат да се изтеглят. Често липсва и всякакво протоколиране на влизанията или логовете се изтриват след няколко дни.
Нито една от тези точки сама по себе си не е зрелищна. Заедно обаче те решават дали едно проникване остава ограничено до един уебсайт, или засяга целия сървър.
Как помага PHP SOS конкретно?
- Опис: Събираме операционната система, уеб сървъра, PHP версиите, уебсайтовете, потребителите, отворените услуги и наличните архиви.
- План от мерки: Получавате приоритизиран списък с усилията и възможните последици за всяка точка. Вие решавате какво да се изпълни.
- Изпълнение на стъпки: Променяме конфигурациите след уговорка, тестваме уебсайтовете след всяка стъпка и записваме как всяка промяна може да се върне.
- Контрол: След изпълнението проверяваме ефекта, например дали даден уебсайт наистина вече не може да чете чужди директории.
- Предаване: Получавате документация на новото състояние, която може да следва и Вашият хостинг доставчик или Вашата агенция.
Какво получавате и какво ни е нужно
Получавате доклад за заздравяването с изходното положение, изпълнените мерки, съзнателно оставените неуредени точки с обосновка и препоръка за редовен контрол. Промените в конфигурационните файлове са документирани проследимо.
От Вас ни е нужно:
- Root или администраторски достъп до сървъра, при панели допълнително достъп до панела
- списък с приложенията и техните особености, например качвания, интерфейси, cron задачи
- технически лице за контакт, което може да потвърждава функциите след промени
- прозорци за поддръжка за рестартиране
- актуално резервно копие или поръчка предварително да се направи такова
Какво не обещаваме
Заздравяването не прави един сървър неуязвим. То намалява повърхността за атака и ограничава щетите, но не замества нито актуализациите, нито наблюдението. Непачната PHP версия остава уязвима, колкото и добре да е настроено останалото. Затова свързваме заздравяването с услугата за пач на PHP и препоръчваме след това постоянна грижа чрез договор за поддръжка на сигурността.
При споделен хостинг много неща не могат да се настройват, защото хостинг доставчикът задава конфигурацията. Тогава показваме какво е възможно в рамките на Вашия пакет и къде би било разумно преминаване към собствен или управляван сървър.
Често задавани въпроси
Какво означава да се заздрави един сървър?
Заздравяването означава да се изключи или ограничи всичко, което не е нужно за работата. Към това спадат излишни услуги, прекалено широки права, отворени портове и несигурни стандартни настройки. Целта е една-единствена грешка да не отваря веднага целия сървър.
Би ли предотвратило заздравяването PHP2Shell?
Не, срещу уязвимост в самия PHP помага само пачът. Заздравяването обаче ограничава какво може да постигне атакуващият след успешно проникване, например дали може да достигне други уебсайтове или данни за достъп.
Ще се счупи ли уебсайтът ми от заздравяването?
Рискът съществува, ако настройките се променят без тест. Внасяме промените стъпка по стъпка, проверяваме функциите след всяка стъпка и записваме как всяка промяна може да се върне.
Колко често трябва да се проверява заздравяването?
Най-късно след по-големи актуализации, смяна на PHP версията или нови приложения на сървъра. Разумен е редовен контрол в рамките на текущата поддръжка.