Текуща ситуация: PHP2Shell. Две критични уязвимости в PHP (CVSS 9,2) позволяват злонамерен код без вход. Корекции от 21.10.2026 г.Какво да направите сега →

Внедряване на ModSecurity и OWASP Core Rule Set

Собствена Web Application Firewall с ModSecurity и OWASP Core Rule Set е безплатна и мощна, но не работи сама. Така избирате двигател, стартирате без прекъсвания и настройвате правилата.

Актуалност 5 мин. четенеЗаздравяване и конфигурация

Накратко: ModSecurity е Web Application Firewall, която работи в уеб сървъра; OWASP Core Rule Set (CRS) предоставя свободно достъпни правила срещу разпространени видове атаки. За Apache проектът CRS препоръчва ModSecurity v2, за Nginx идват предвид конекторът v3 или Coraza. Стартирайте в режим на блокиране с много високи прагове на аномалии, намалявайте ги стъпка по стъпка и обработвайте фалшивите аларми с целенасочени изключения. Това не замества актуализацията на PHP.

Собствена WAF като допълнителен слой

След PHP2Shell много фирми питат дали се нуждаят от Web Application Firewall. Който обслужва сайтовете си през Cloudflare, според Cloudflare има автоматично активни защитни правила от 21 октомври 2026 г. Който не го прави или не иска да пренасочва трафика през трета страна, може да стартира WAF директно на собствения си сървър.

Най-известната комбинация за това е ModSecurity с OWASP Core Rule Set. И двете са с отворен код и безплатни. CRS е колекция от общи правила за откриване, например срещу SQL инжекция, Cross-Site Scripting или внедряване на файлове. Самият проект описва целта си като общо откриване на атаки с възможно най-малко фалшиви аларми, като един градивен елемент между няколко.

Така е посочена и границата. WAF проверява заявки и отговори, тя не поправя уязвимост в интерпретатора на PHP. Защо са нужни и двете, описва WAF или актуализация: защо са нужни и двете.

Кой двигател подхожда на Вашия уеб сървър

Наборът от правила се нуждае от двигател, който го изпълнява. Според документацията на CRS има три съвместими варианта:

Двигател Уеб сървър Оценка според проекта CRS
ModSecurity v2 Apache (модул) референтна имплементация, препоръчана за Apache
ModSecurity v3 (libModSecurity) най-вече Nginx през конектор само конекторът за Nginx е наистина използваем в продукция; не издържа 2 до 4 процента от тестовете на CRS
Coraza прокси сървъри и интеграции на базата на Go издържа напълно тестовия набор на CRS v4

Контекст: ModSecurity дълго се разработваше от Trustwave. Trustwave обяви през 2021 г., че ще прекрати разработката през 2024 г. На 25 януари 2024 г. проектът премина към OWASP Foundation. При нови инсталации проверете коя версия доставя Вашата дистрибуция и колко е актуална.

Как работи Core Rule Set

CRS при стандартната настройка не блокира при първата подозрителна особеност. Той работи с точки за аномалия: всяко задействано правило добавя точки според степента си на тежест и едва когато сборът надхвърли праг, заявката се отхвърля.

  1. Степени на тежест: критична 5 точки, грешка 4, предупреждение 3, бележка 2.
  2. Праг за заявки: tx.inbound_anomaly_score_threshold, по подразбиране 5.
  3. Праг за отговори: tx.outbound_anomaly_score_threshold, по подразбиране 4.
  4. Ниво на параноя от 1 до 4 в crs-setup.conf: ниво 1 е основната защита за всеки сървър в интернет, ниво 2 според проекта подхожда на приложения с реални потребителски данни като онлайн магазини, нива 3 и 4 носят значително повече фалшиви аларми.

По-високо ниво на параноя разпознава повече, но създава и повече фалшиви аларми. За повечето фирмени уебсайтове ниво 1 е началото, ниво 2 е по-късна цел.

Внедряване на ModSecurity с OWASP CRS без да спрете сайта

Проектът CRS препоръчва за нови инсталации режимът на блокиране да се включи от самото начало, но с много високи прагове, до 10000, които после да се намаляват стъпка по стъпка. Така трупате опит с реални достъпи, без да изключвате потребители. Праговете задавате в crs-setup.conf:

# crs-setup.conf: начална фаза с много високи прагове
SecAction \
    "id:900110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    setvar:tx.inbound_anomaly_score_threshold=10000,\
    setvar:tx.outbound_anomaly_score_threshold=10000"

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

<IfModule security2_module>
    SecRuleEngine On
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/plugins/*-config.conf
    Include /etc/modsecurity/crs/plugins/*-before.conf
    Include /etc/modsecurity/crs/rules/*.conf
    Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>

След това анализирате одит лога, определен в SecAuditLog. Как да претърсвате протоколи систематично, описва Анализ на логовете на уеб сървъра след атака. Намалявайте праговете на стъпки, например в продължение на няколко седмици, докато стигнете стойността по подразбиране.

Целенасочена обработка на фалшивите аларми

Фалшивите аларми са нормални, особено в бекендите на CMS с редактори, които записват HTML. Най-лошата реакция е да изключите WAF. По-добри са два инструмента.

Първо плъгини: проектът CRS поддържа плъгини с правила за изключения за разпространени приложения, например за WordPress. Те се копират в папката за плъгини и се зареждат през показаните по-горе редове Include. Официалния списък проектът води в своята директория на плъгините.

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

# Собствено изключение, зареждайте го ПРЕДИ правилата на CRS (напр. във файл *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
    "id:1000010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=941100"

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

Съвет

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

За сървърите с Apache си струва да подходите към WAF заедно с останалата конфигурация; основите са в Сигурна конфигурация на Apache за PHP. Как правилата на Cloudflare се сравняват, показва Защитните правила на Cloudflare срещу PHP2Shell. Преходните мерки на самия сървър са в Незабавни мерки, когато още не можете да пачнете.

Извод: WAF се нуждае от поддръжка

ModSecurity с OWASP Core Rule Set Ви дава ефективна Web Application Firewall без лицензни разходи и без зависимост от външна услуга. Цената е труд: двигател, подходящ за уеб сървъра, започване с високи прагове, анализ на фалшивите аларми, поддържане на изключенията и актуалност на правилата.

Който не може да вложи това усилие, често се справя по-добре с добре конфигурирана облачна WAF. Който може, получава слой, който прихваща много стандартни атаки и дава ценни указания в одит логовете. В никой случай тя не замества актуализацията: срещу PHP2Shell защитават само PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 или потвърден backport, последвани от рестартиране на всички PHP процеси.

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

  • Избор на двигател: проверяваме уеб сървъра, дистрибуцията и наличните пакети и препоръчваме подходящата комбинация.
  • Внедряване: инсталираме CRS с високи начални прагове, включваме подходящи плъгини и настройваме протоколирането.
  • Настройване: в продължение на няколко седмици анализираме фалшивите аларми, създаваме целенасочени изключения и намаляваме праговете.
  • Подреждане: в рамките на WAF и виртуално пачване свързваме WAF с преходните мерки и пътя към редовния пач.

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

Защитава ли OWASP CRS от PHP2Shell?

Не бива да приемате това. Core Rule Set разпознава общи модели на атаки и не е съобразен с конкретна уязвимост. Cloudflare освен това сочи, че правила само по данните от заявката при PHP2Shell не са достатъчни. Актуализацията на PHP остава задължителна.

Кой двигател да взема за Nginx?

Според проекта CRS при ModSecurity v3 само конекторът за Nginx е наистина използваем в продукция, а v3 не издържа малка част от тестовете на CRS. Алтернатива е Coraza, която според данните на проекта издържа напълно тестовия набор на CRS v4. За Apache проектът препоръчва ModSecurity v2.

Още ли се поддържа ModSecurity?

Според документацията на CRS Trustwave беше обявила, че ще прекрати разработката през 2024 г. На 25 януари 2024 г. проектът беше предаден на OWASP Foundation и оттогава се развива там.

Как да предотвратя WAF да спре моя магазин?

Започнете с много високи прагове на аномалии, както препоръчва проектът CRS, и ги намалявайте стъпка по стъпка. Анализирайте при това протоколите и създавайте целенасочени изключения за Вашето приложение, вместо да изключвате правила за всички.

Източници

Незабавен контакт

Всеки час има значение. Пишете ни сега.

Опишете накратко системата, версията на PHP и какво сте забелязали. Ние се свързваме с Вас, уточняваме ситуацията и работим отдалечено, докато инцидентът бъде приключен и документиран.

Незабавна помощ