# WAF и виртуално пачване за PHP

> Виртуално пачване за PHP: комбинираме WAF правила с временните мерки според php.net, докато актуализацията стане възможна, и планираме истинския пач.

Източник: https://phpsos.de/bg/leistungen/waf-virtuelles-patching/  
Актуалност: 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 преодолява времето до внасянето на истинската актуализация. За целта комбинираме правила на Web Application Firewall с временните мерки, които php.net публикува за PHP2Shell, и веднага определяме пътя към редовния пач. Пълна защита това не дава, но намалява риска през преходния период.

## Кога виртуалното пачване за PHP е разумно

BSI препоръчва при PHP2Shell незабавна актуализация, а ако това не е възможно, уеб сървърите да се изключат временно от мрежата. За много фирми нито едното не е осъществимо веднага: магазинът трябва да остане достъпен, собствена разработка се нуждае от тест преди актуализацията или сървърът работи с PHP 8.1 и по-стар, за който вече няма официални актуализации.

В тези случаи виртуалното пачване е мост. То не заменя решението дали не би било по-уместно да се работи офлайн. Тази преценка правите Вие, ние предоставяме техническата оценка.

## Защо една WAF сама не стига

Cloudflare съобщи за наблюдавани опити за атака и внедри защитни правила, но предупреждава, че правила само по данните от заявките не са достатъчни. Причината е в естеството на уязвимостите. При CVE-2026-109618 състояние на недостиг на памет (Out-of-Memory) може да прекъсне PHP, докато данните от заявката са инициализирани само частично. При CVE-2026-109619 вътрешно състояние може да остане след освобождаването на паметта и да бъде използвано от по-късна заявка в същия worker. Такива грешки зависят от състоянието на сървъра, а не само от съдържанието на отделна заявка.

Затова залагаме на няколко слоя: WAF правила пред сървъра, временни мерки в самия PHP и засилено наблюдение на сървъра. Всеки слой спира част от атаките, никой сам не стига. Заедно те Ви осигуряват времето, за да внесете актуализацията подредено.

## Временните мерки според php.net

php.net назовава няколко настройки, които намаляват риска, изрично без пълна защита. Важно е приложенията да не могат да презаписват тези стойности. Пример за PHP-FPM пул с качвания:

```ini
; Временни мерки за PHP2Shell (не са пълна защита), след това рестартирайте всички worker процеси
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; само за PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
```

Без качвания php.net препоръчва `post_max_size = 8M`. Тъй като `memory_limit` се премахва, към това спада ограничение на паметта на ниво контейнер или cgroup, а не чрез `RLIMIT_AS` или `RLIMIT_DATA`. Настройката `session.upload_progress.enabled=0` принадлежи в php.ini, в FPM пула или в конфигурацията на сървъра, а не в `ini_set()` или `.user.ini`. Тя е същевременно и мярката за бележката относно [CVE-2026-115560](https://phpsos.de/bg/php2shell/cve-2026-115560/). Всички мерки накратко има на страницата [Незабавни мерки, когато още не можете да пачнете](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/).

> **Важно:**
> Временните мерки действат едва след рестартиране на всички PHP worker процеси. И те защитават само от бъдещи атаки: дали някой е проникнал преди това, не казват.

## Кога работата офлайн е по-добрият избор

Виртуалното пачване не е правилният отговор във всяка ситуация. При някои конфигурации съветваме да се следва BSI и уеб сървърът да се изключи временно от мрежата, докато не бъде пачнат:

- сървърът работи с **Apache и mod_php**, където екипът на PHP оценява риска като най-висок и е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението
- на сървъра има **особено защитими данни**, например здравни данни, данни на клиенти на кантори или платежни данни
- **няма възможност** временните мерки да се зададат твърдо в конфигурацията на сървъра, например при определени пакети със споделен хостинг
- вече има **признаци**, че сървърът е бил атакуван

Временната работа офлайн не означава, че уебсайтът Ви е хакнат. Някои доставчици са изключили уебсайтове от предпазливост. Кратка, делова страница с обяснение за посетителите е тогава обикновено по-добро решение от необяснима недостъпност.

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

1. **Проверка на положението:** Събираме PHP версиите, режимите на работа и наличните защитни слоеве като CDN, WAF или reverse proxy. При mod_php посочваме повишения риск, който екипът на PHP вижда там.
2. **Изграждане на слоеве:** Активираме или допълваме WAF правила, задаваме твърдо временните мерки в конфигурацията на сървъра и ограничаваме паметта чрез контейнер или cgroup. За Nginx конфигурации се ориентираме по [Защита на Nginx с PHP-FPM](https://phpsos.de/bg/server/nginx-php-fpm/).
3. **Рестартиране и тест:** Всички PHP процеси се рестартират, след това проверяваме качванията, формулярите, входа и касата.
4. **Наблюдение:** През преходния период обръщаме засилено внимание на сривове на worker процеси, пикове в паметта и необичайни процеси.
5. **Планиране на пача:** Определяме кога и как ще дойде редовната актуализация и я изпълняваме чрез [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/).

## Какво получавате, какво ни е нужно и какво не обещаваме

Получавате документация на всички зададени правила и настройки с обосновка, резултатите от тестовете и план със срокове и мерки за истинския пач. От Вас ни е нужен достъп до сървъра или панела, достъп до CDN или WAF, ако има такива, технически човек за контакт и информация за функциите за качване на Вашите приложения.

Не обещаваме, че виртуалното пачване предотвратява атака. То намалява риска за ограничено време. При PHP 8.1 и по-стари то не е постоянно състояние; тук в плана влиза [преминаването към поддържана версия](https://phpsos.de/bg/leistungen/php-migration-legacy/).


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

**Какво е виртуално пачване?**  
Виртуалното пачване означава позната уязвимост да се екранира пред приложението, вместо да се променя самият код. Това става най-често чрез Web Application Firewall или промени в конфигурацията. То е преодоляване на периода, а не заместител на актуализацията.

**Достатъчна ли е WAF на моя CDN доставчик срещу PHP2Shell?**  
Сама по себе си по правило не. Cloudflare внедри защитни правила, но сама предупреждава, че правила само по данните от заявките не са достатъчни. WAF е допълнителен слой до временните мерки и пача.

**Колко дълго мога да разчитам на виртуално пачване?**  
Колкото се може по-кратко. То трябва да преодолее времето до редовната актуализация, например докато се освободи прозорец за поддръжка или се тества дадено приложение. При PHP 8.1 и по-стари към това спада и план за миграция.

**Могат ли временните мерки да нарушат уебсайта ми?**  
Да, възможно е. По-малките ограничения за качване могат да попречат на качването на големи файлове, а изключването на session upload progress засяга индикаторите за напредък при качване. След всяка промяна тестваме най-важните функции.

## Източници

- [php.net: Съобщения за сигурност и временни мерки](https://www.php.net/)
- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)