# WAF или ъпдейт: защо Ви трябват и двете

> WAF вместо ъпдейт при PHP2Shell? Какво прави Web Application Firewall, докъде стига и защо само ъпдейтът на PHP с рестарт затваря уязвимостта.

Източник: https://phpsos.de/bg/blog/waf-oder-update/  
Актуалност: 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

**Накратко:** WAF вместо ъпдейт при PHP2Shell не работи. Web Application Firewall, тоест филтър пред уебсайта, проверява заявките и може да блокира познати модели на атака. Самата уязвимост обаче е в интерпретатора на PHP и изчезва едва с ъпдейта и рестарта на всички PHP процеси. WAF е разумен допълнителен слой и мост за няколко дни, а не решението.

## Защо въпросът се задава толкова често именно сега

Много оператори прочетоха през седмицата на PHP2Shell привидно добра новина: Cloudflare според собствените си данни има от 21.10.2026 г., 03:02 UTC, активни защитни правила, и за клиентите на безплатния план. Който така или иначе стои зад Cloudflare или друга WAF, разбираемо се пита дали ъпдейтът тогава още е спешен.

Честният отговор е да. Самият Cloudflare прави уговорка: правила само по данните на заявката не стигат, затова услугата проверява допълнително и отговора на сървъра. Cloudflare наблюдава освен това променени модели на атака. И защитата действа само за трафик, който действително минава през Cloudflare. Подробностите за този доставчик описва [Защитните правила на Cloudflare срещу PHP2Shell](https://phpsos.de/bg/blog/cloudflare-waf-php2shell/). Тук става дума за принципната преценка, независимо от доставчика.

## Какво вижда WAF и какво променя ъпдейтът

WAF стои пред приложението. Тя вижда всяка заявка, сравнява я с правила и я пропуска, блокира или протоколира. Не знае как PHP обработва заявката вътрешно. Двете уязвимости на PHP2Shell обаче възникват точно там: CVE-2026-109618 при състояние Out-of-Memory, докато данните на заявката са само частично инициализирани, CVE-2026-109619 поради вътрешно състояние, което остава след една заявка в същия worker.

Ъпдейтът поправя този код. След това причината е премахната, независимо как изглежда една заявка. Който иска да разбере на кое място от хода на една заявка се случва това, ще намери основите в [Жизнения цикъл на заявката в PHP](https://phpsos.de/bg/php/request-lebenszyklus/).

## WAF вместо ъпдейт: честното сравнение

| Критерий | Web Application Firewall | Ъпдейт на PHP с рестарт |
|---|---|---|
| Какво се отстранява? | Нищо, познатите модели се улавят | Причината в интерпретатора на PHP |
| Защита при нови варианти на атака | Само ако правилата се адаптират навреме | Да, уязвимостта вече не съществува |
| Възможно ли е заобикаляне? | Да, например чрез директна достъпност на изходния сървър | Не, при условие че всички PHP процеси са рестартирани |
| Скорост | Често активна веднага | Зависи от версията, достъпа и прозореца за поддръжка |
| Странични ефекти | Фалшиви аларми, нарушени формуляри или качвания | Редки, при скокове във версиите са нужни тестове за съвместимост |
| Полза при следващата уязвимост | Висока, ако е поддържана | Никаква, всяка уязвимост изисква собствен ъпдейт |
| Помага ли при PHP 8.1 и по-стари? | Като преход | Само чрез backport или миграция |

Таблицата показва защо двете мерки са свързани. WAF е бърза и широка, но никога не е пълна. Ъпдейтът е пълен, но само за определена уязвимост и не винаги е възможен веднага.

Една точка често се пропуска на практика: WAF променя поведението на уебсайта. Строгите правила могат да блокират легитимни поръчки, контактни формуляри или качване на файлове, без някой веднага да го забележи. Който включи WAF в строг режим в криза, затова трябва веднъж сам да мине през най-важните процеси на уебсайта и да провери протоколите от първите дни за блокирани, но основателни заявки.

## Как да комбинирате двете разумно

1. **Веднага:** Проверете дали има WAF и дали подходящите правила са активни. При Cloudflare в платените планове според доставчика настройте Managed Ruleset на Block.
2. **Веднага:** Погрижете се изходният сървър да е достъпен само през WAF, например чрез разрешение във firewall само за нейните адресни диапазони. Иначе защитата остава напразна.
3. **В рамките на следващия прозорец за поддръжка:** Актуализирайте PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 или инсталирайте потвърдения backport на дистрибуцията.
4. **Веднага след това:** Рестартирайте всички PHP worker и процеси и проверете, че не работи стар процес. Само нови файлове не стигат; повече за това в [След ъпдейта: рестартиране на PHP-FPM и на всички работници](https://phpsos.de/bg/php2shell/php-fpm-neustart/).
5. **След това:** Запазете правилата на WAF, оценете фалшивите аларми и задавайте изключения целенасочено, вместо да изключвате правила общо.

Със собствена WAF на основата на ModSecurity и OWASP Core Rule Set може да се постигне подобно нещо; основите описва [Използване на ModSecurity и OWASP Core Rule Set](https://phpsos.de/bg/blog/modsecurity-owasp-crs/). Особена форма е предложеното от специалисти филтриране на заявки за качване извън истинските пътища за качване. То е неофициално, може да счупи формуляри и влиза в експлоатация само след тест.

> **Важно:**
> Нито WAF, нито ъпдейтът премахват зловреден софтуер, внесен преди това. Проверете след пача дали от 17.10.2026 г. насам са се появили необичайни неща.

## Кога не Ви трябва WAF и кога не Ви трябва доставчик

WAF не е задължителна за всеки уебсайт. Малък фирмен уебсайт при хостинг доставчик, който пачва PHP своевременно и го потвърждава, често е достатъчно защитен и без собствена WAF, ако CMS и добавките са актуални. И който може сам да актуализира сървъра си за кратко време, няма нужда от WAF като мост.

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

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

- Проверяваме дали Вашата WAF действително стои пред всички достъпи и дали изходният сървър е достъпен директно.
- Настройваме правила или ги адаптираме и тестваме формуляри, качвания и интерфейси за странични ефекти.
- Инсталираме ъпдейта на PHP, рестартираме всички процеси и документираме състоянието.
- Където ъпдейтът отнема време, го преодоляваме с [WAF и виртуално пачване](https://phpsos.de/bg/leistungen/waf-virtuelles-patching/) и с твърд срок за истинския пач.

## Извод

Въпросът „WAF или ъпдейт“ е зададен погрешно. Ъпдейтът затваря уязвимостта, WAF дава време и улавя много други неща. Който разчита само на WAF, се осланя на правила, които нападателите могат да заобиколят. Който само пачва, при следващата уязвимост отново остава без мост.


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

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

**Автоматично ли съм защитен зад Cloudflare?**  
Само за трафика, който действително минава през Cloudflare. Ако изходният сървър е достъпен директно от интернет, защитата се заобикаля. При платените планове според Cloudflare трябва да проверите дали Managed Ruleset е настроен на Block.

**Има ли смисъл от WAF и след ъпдейта?**  
Често да. WAF може да улавя масови сканирания, познати атаки срещу добавки и злоупотреба със страници за вход и дава време при следващата уязвимост. Нуждае се обаче от поддръжка и тестове, иначе фалшивите аларми пречат на работата.

**Какво е виртуално пачване?**  
Имат се предвид временното екраниране на уязвимост с правила пред приложението, вместо промяна на кода. Това е мост до истинския ъпдейт, а не заместител.

## Източници

- [Блог на Cloudflare](https://blog.cloudflare.com/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)