Накратко: Според собствените си данни Cloudflare има активни правила за защита срещу PHP2Shell от 21 октомври 2026 г., 03:02 UTC, и то също за клиенти в безплатния план. Правилата намаляват риска за трафик, който минава през Cloudflare. Те не действат, когато първоизточникът на сървъра е достъпен директно, и не заместват актуализацията на PHP. Който ползва Cloudflare, трябва да провери режима на правилата, защитата на първоизточника и състоянието на пача.
Поводът: защита още преди пача
Cloudflare беше необичайно рано при PHP2Shell. Според блога на Cloudflare правилата за защита са работили няколко часа преди официалното публикуване на PHP актуализациите в 14:00 UTC. Cloudflare съобщи още, че е наблюдавала опити за атака срещу клиенти и че нападателите са променяли модела си, за да заобиколят правилата.
Много оператори заключиха: „Ние сме зад Cloudflare, значи сме защитени.“ Това е вярно само отчасти. Тази статия обяснява какво правилата действително покриват. Общата преценка между защитна стена и актуализация предлага статията WAF или актуализация?.
Какво пусна Cloudflare срещу PHP2Shell
Според данни от блога на Cloudflare има три елемента:
| План | Защита според Cloudflare | Какво да направите |
|---|---|---|
| Free | нови правила в Managed Free Ruleset, автоматично активни | проверете дали домейнът минава през Cloudflare |
| Pro, Business, Enterprise | подходящи правила в Managed Ruleset | уверете се, че Ruleset е на „Block“ |
| всички планове | стандартно правило в новата защитна стена за отговори | не изключвайте нищо, наблюдавайте събитията |
Третият елемент е нов. Cloudflare го нарича „full transaction detection“: WAF разглежда не само заявката, но и отговора на сървъра. Причината според Cloudflare: заявката сама по себе си не винаги стига, за да се отдели сигурно атаката от нормалния трафик. PHP2Shell е първото приложение на тази функция в управляваните правила.
Границите на правилата на Cloudflare
Колкото и полезни да са правилата, те имат ясни граници, които Cloudflare отчасти сама назовава:
- Само трафик през Cloudflare: Правилата проверяват това, което тече през Cloudflare. Ако първоизточникът на сървъра е достъпен директно по своя IP адрес, нападателят може да заобиколи защитата.
- Няма отмяна: Според Cloudflare правило от страна на отговора може да задържи отговора, но не може да отмени онова, което вече е станало на сървъра.
- Променящи се модели на атака: Cloudflare приспособява правилата непрекъснато, защото нападателите променят заявките си. Между нов вариант и ново правило може да има пролука.
- Не е заместител на актуализацията: Cloudflare изрично препоръчва PHP да се актуализира въпреки WAF. Също и актуализация на кода на приложението или на добавките не отстранява уязвимостите.
- Особен случай CVE-2026-115560: Според допълнението на Cloudflare от 23 октомври правилото не действа, ако името за session upload progress в конфигурацията е променено. Повече за това съобщение в CVE-2026-115560.
Какво казват блокираните заявки и какво не
Много клиенти след съобщението поглеждат в събитията си за сигурност и намират там блокирани заявки. Това показва първоначално само, че Вашият домейн е бил проверен и правилото е сработило. Пробив с това не е доказан. Обратно, празен списък със събития не е успокоение: ако атака е минала директно към първоизточника или преди 21 октомври, в Cloudflare тя изобщо не се появява.
По-надеждно е съпоставянето със самите логове на уеб сървъра. Заявки, които пристигат там, но не идват от адреси на Cloudflare, сочат директен достъп. Запазете тези логове от 20 октомври, както съветва специализираната преса. Cloudflare напомня още, че ограниченията за качване на файлове могат да намалят риска, но не заместват PHP актуализацията.
Най-честата слабост зад Cloudflare не е правилото, а пътят покрай него: първоизточник на сървъра, който отговаря директно по своя IP адрес или през незащитен поддомейн.
Списък за проверка за клиентите на Cloudflare
Тези стъпки можете да изпълните Вие или Вашият доставчик на услуги в кратък срок:
- Проверете плана и режима на правилата: При платените планове проверете в таблото, че Managed Ruleset е активен в режим „Block“.
- Разгледайте събитията за сигурност: В Security Events проверете дали се появяват блокирани заявки. Това показва дали Вашите домейни вече са били цел.
- Прегледайте DNS записите: Всеки запис, който сочи към уеб сървъра, но не минава през Cloudflare, е възможен заобиколен път. Типични са поддомейни за staging, FTP или поща на същия сървър.
- Затворете първоизточника: Конфигурирайте уеб сървъра така, че да приема HTTP и HTTPS само от Cloudflare, например чрез защитна стена с публикуваните от Cloudflare адресни диапазони или чрез тунел. Как се прави това принципно, описва статията Защитна стена за уеб сървър.
- Тествайте директния достъп: Проверете отвън дали първоизточникът отговаря без Cloudflare.
- Актуализирайте PHP и рестартирайте: Правилата са втората линия. Първата е PHP на поправена версия с рестартиране на всички PHP процеси.
За стъпка 5 стига безобиден тест, който изисква само заглавните редове. IP адресът е заместител за Вашия първоизточник:
# Отговаря ли първоизточникът директно, покрай Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Ако тук дойде редовен отговор на Вашия уебсайт, първоизточникът е достъпен директно и защитата на Cloudflare може да бъде заобиколена.
Как помага PHP SOS конкретно?
- Проверка на конфигурацията: Проверяваме режима на правилата, DNS записите и директния достъп до първоизточника.
- Защита на първоизточника: Ограничаваме уеб сървъра до трафик през Cloudflare, без да прекъсваме Вашия уебсайт.
- Пач и доказателство: Актуализираме PHP, рестартираме всички процеси и документираме състоянието.
- Анализ на събитията: Преглеждаме блокираните заявки и ги съпоставяме с логовете на сървъра.
Как комбинираме WAF правила и временни мерки, описва WAF и виртуален пач.
Заключение
Правилата на Cloudflare срещу PHP2Shell са истинска полза, особено защото дойдоха рано и също в безплатния план. Те обаче са щит пред вратата, не ключалка на вратата. Който е зад Cloudflare, трябва да осигури три неща: правила в режим Block, никакъв път покрай прокситото и PHP на поправена версия.
Често задавани въпроси
Защитен ли съм от PHP2Shell с безплатния план на Cloudflare?
Според Cloudflare и клиентите на безплатния план получават правилата за защита автоматично. Те обаче действат само за трафик, който минава през Cloudflare, и не заместват актуализацията на PHP на сървъра. Ако първоизточникът на сървъра е достъпен директно, защитата не действа.
Какво трябва да настроя при платените планове на Cloudflare?
Cloudflare съветва клиентите с планове Pro, Business и Enterprise да проверят дали Managed Ruleset работи в режим Block. Ако е само на запис в дневника, атаките се регистрират, но не се спират.
Какво е full transaction detection?
Нова функция на WAF на Cloudflare, която разглежда не само заявката, но и отговора на сървъра. Така може да се разпознае дали опитът за атака има ефект, а отговорът може да бъде задържан. Каквото вече е изпълнено на сървъра, според Cloudflare тя не отменя.
Покрива ли Cloudflare и CVE-2026-115560?
Cloudflare допълни статията си за CVE-2026-115560 на 23 октомври. Според Cloudflare съответното правило не действа, ако името за session upload progress е променено в PHP конфигурацията. Независимо от това php.net препоръчва да се зададе session.upload_progress.enabled=0.