# ModSecurity ir OWASP Core Rule Set naudojimas > ModSecurity ir OWASP CRS naudojimas: tinkamo variklio pasirinkimas, anomalijų slenksčių ir paranojos lygių supratimas, tikslingas klaidingų signalų valdymas. Šaltinis: https://phpsos.de/lt/blog/modsecurity-owasp-crs/ Būsena: 2026-10-25 Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6 **Trumpai:** ModSecurity yra žiniatinklio programų ugniasienė (Web Application Firewall), veikianti žiniatinklio serveryje; OWASP Core Rule Set (CRS) prie jos pateikia laisvai prieinamas taisykles nuo paplitusių atakų rūšių. Apache CRS projektas rekomenduoja ModSecurity v2, Nginx tinka v3 jungtis (connector) arba Coraza. Pradėkite blokavimo režimu su labai aukštais anomalijų slenksčiais, mažinkite juos palaipsniui ir klaidingus signalus tvarkykite tikslingomis išimtimis. PHP atnaujinimo tai nepakeičia. ## Sava WAF kaip papildomas sluoksnis Nuo PHP2Shell daug įmonių klausia, ar joms reikia žiniatinklio programų ugniasienės. Kas savo svetaines teikia per Cloudflare, nuo 2026 m. spalio 21 d., pasak Cloudflare, automatiškai turi aktyvias apsaugos taisykles. Kas to nedaro arba nenori duomenų srauto leisti per trečiąją šalį, gali valdyti WAF tiesiai savo serveryje. Žinomiausias derinys tam yra ModSecurity su OWASP Core Rule Set. Abu yra atviro kodo ir nemokami. CRS yra bendrųjų atpažinimo taisyklių rinkinys, pavyzdžiui, nuo SQL injekcijos, Cross-Site-Scripting ar failų įterpimo. Pats projektas savo tikslą apibūdina kaip bendrą atakų atpažinimą su kuo mažiau klaidingų signalų, kaip vieną elementą tarp kelių. Tuo įvardijama ir riba. WAF tikrina užklausas ir atsakymus, ji netaiso spragos PHP interpretatoriuje. Kodėl reikia abiejų, aprašo [WAF ar atnaujinimas: kodėl reikia abiejų](https://phpsos.de/lt/blog/waf-oder-update/). ## Kuris variklis tinka jūsų žiniatinklio serveriui Taisyklėms reikia variklio, kuris jas vykdo. Pasak CRS dokumentacijos, yra trys suderinamos parinktys: | Variklis | Žiniatinklio serveris | Vertinimas pagal CRS projektą | |---|---|---| | ModSecurity v2 | Apache (modulis) | etaloninė realizacija, rekomenduojama Apache | | ModSecurity v3 (libModSecurity) | daugiausia Nginx per jungtį (connector) | tikrai produktyviai naudojama tik Nginx jungtis; neišlaiko 2-4 procentų CRS testų | | Coraza | Go pagrindo tarpiniai serveriai (proxy) ir integracijos | visiškai išlaiko CRS v4 testų rinkinį | Fonui: ModSecurity ilgai kūrė Trustwave. Trustwave 2021 m. paskelbė, kad 2024 m. nutrauks plėtrą. 2024 m. sausio 25 d. projektas perėjo OWASP Foundation. Naujoms įdiegtims patikrinkite, kurią versiją pateikia jūsų distribucija ir kiek ji aktuali. ## Kaip veikia Core Rule Set CRS numatytu nustatymu neblokuoja pirmo įtartino požymio. Jis veikia su anomalijų taškais: kiekviena suveikusi taisyklė prideda taškų pagal sunkumo laipsnį, ir tik kai suma viršija slenkstį, užklausa atmetama. 1. Sunkumo laipsniai: kritinis 5 taškai, klaida 4, įspėjimas 3, pastaba 2. 2. Užklausų slenkstis: `tx.inbound_anomaly_score_threshold`, numatytasis 5. 3. Atsakymų slenkstis: `tx.outbound_anomaly_score_threshold`, numatytasis 4. 4. Paranojos lygiai 1-4 faile `crs-setup.conf`: 1 lygis yra bazinė apsauga kiekvienam serveriui internete, 2 lygis, pasak projekto, tinka programoms su tikrais naudotojų duomenimis, pavyzdžiui, internetinėms parduotuvėms, 3 ir 4 lygiai atneša gerokai daugiau klaidingų signalų. Aukštesnis paranojos lygis atpažįsta daugiau, bet sukuria ir daugiau klaidingų signalų. Daugumai įmonių svetainių 1 lygis yra pradžia, 2 lygis vėlesnis tikslas. ## ModSecurity su OWASP CRS įvedimas nesustabdant svetainės CRS projektas naujoms įdiegtims rekomenduoja blokavimo režimą įjungti nuo pat pradžių, bet su labai aukštais slenksčiais, iki 10000, ir juos palaipsniui mažinti. Taip įgyjate patirties su tikrais kreipiniais neužblokuodami naudotojų. Slenksčius nustatote faile `crs-setup.conf`: ```apache # crs-setup.conf: pradinė fazė su labai aukštais slenksčiais SecAction \ "id:900110,\ phase:1,\ pass,\ t:none,\ nolog,\ setvar:tx.inbound_anomaly_score_threshold=10000,\ setvar:tx.outbound_anomaly_score_threshold=10000" ``` Įtraukimas Apache seka tvarką, kurią CRS dokumentacija nurodo papildiniams. Keliai skiriasi pagal distribuciją: ```apache 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 ``` Po to analizuokite audito žurnalą, nurodytą `SecAuditLog`. Kaip sistemingai peržiūrėti žurnalus, aprašo [Žiniatinklio serverio žurnalų analizė po atakos](https://phpsos.de/lt/ratgeber/logfiles-auswerten/). Slenksčius mažinkite pakopomis, pavyzdžiui, per kelias savaites, kol pasieksite numatytąją reikšmę. ## Klaidingų signalų tikslingas tvarkymas Klaidingi signalai yra normalūs, ypač CMS administravime su redaktoriais, kurie saugo HTML. Blogiausia reakcija yra išjungti WAF. Geriau du įrankiai. Pirma, papildiniai: CRS projektas prižiūri papildinius su išimčių taisyklėmis paplitusioms programoms, pavyzdžiui, WordPress. Jie nukopijuojami į papildinių aplanką ir įkeliami aukščiau parodytomis Include eilutėmis. Oficialų sąrašą projektas pateikia savo papildinių kataloge. Antra, savos, siaurai apibrėžtos išimtys. Užuot taisyklę išjungę visur, ją išimkite tik tam keliui, kuriame ji trukdo: ```apache # Sava išimtis, įkelti PRIEŠ CRS taisykles (pvz., faile *-before.conf) SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \ "id:1000010,\ phase:1,\ pass,\ nolog,\ ctl:ruleRemoveById=941100" ``` Taisyklės ID paimkite iš klaidingo signalo audito žurnalo. Kiekvieną išimtį dokumentuokite su priežastimi ir data, kad vėliau ją būtų galima peržiūrėti. > **Patarimas:** > Po kiekvieno slenksčių ar išimčių pakeitimo išbandykite kritinius savo programos kelius: prisijungimą, užsakymą, mokėjimą, kontaktų formą ir redakciją. WAF, kuri blokuoja užsakymus, greitai vėl išjungiama. Apache serveriams verta WAF spręsti kartu su likusia konfigūracija; pagrindai pateikti skyriuje [Saugi Apache konfigūracija PHP](https://phpsos.de/lt/blog/apache-fuer-php-absichern/). Kaip vertinti Cloudflare taisykles palyginti, parodo [Cloudflare apsaugos taisyklės nuo PHP2Shell](https://phpsos.de/lt/blog/cloudflare-waf-php2shell/). Pereinamosios priemonės pačiame serveryje pateiktos skyriuje [Skubios priemonės, kai dar negalite pataisyti](https://phpsos.de/lt/php2shell/sofortmassnahmen-ohne-patch/). ## Išvada: WAF reikia priežiūros ModSecurity su OWASP Core Rule Set suteikia našią žiniatinklio programų ugniasienę be licencijų išlaidų ir be priklausomybės nuo išorinės paslaugos. Kaina yra darbas: pasirinkti žiniatinklio serveriui tinkamą variklį, pradėti nuo aukštų slenksčių, analizuoti klaidingus signalus, prižiūrėti išimtis ir laikyti taisykles aktualias. Kas šio darbo kiekio negali atlikti, dažnai geriau pasielgia su gerai sukonfigūruota debesies WAF. Kas jį atlieka, gauna sluoksnį, kuris sustabdo daug standartinių atakų ir audito žurnaluose pateikia vertingų užuominų. Jokiu atveju ji nepakeičia atnaujinimo: nuo PHP2Shell saugo tik PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 arba patvirtintas atgalinis pataisų perkėlimas (backport), po kurio iš naujo paleidžiami visi PHP procesai. ## Kaip PHP SOS padeda konkrečiai? - **Pasirinkti variklį:** tikriname žiniatinklio serverį, distribuciją ir esamus paketus ir rekomenduojame tinkamą derinį. - **Įvesti:** įdiegiame CRS su aukštais pradiniais slenksčiais, įtraukiame tinkamus papildinius ir įrengiame registravimą. - **Suderinti:** per kelias savaites analizuojame klaidingus signalus, kuriame tikslines išimtis ir mažiname slenksčius. - **Įvertinti:** [WAF ir virtualaus pataisymo](https://phpsos.de/lt/leistungen/waf-virtuelles-patching/) rėmuose WAF susiejame su pereinamosiomis priemonėmis ir keliu į įprastą pataisą. ## Dažni klausimai **Ar OWASP CRS apsaugo nuo PHP2Shell?** Tuo neturėtumėte pasikliauti. Core Rule Set atpažįsta bendrus atakų šablonus ir nėra pritaikytas konkrečiai spragai. Be to, Cloudflare pažymi, kad PHP2Shell atveju vien taisyklių pagal užklausos duomenis nepakanka. PHP atnaujinimas lieka privalomas. **Kurį variklį turėčiau rinktis Nginx?** Pasak CRS projekto, ModSecurity v3 atveju tikrai produktyviai naudojamas tik Nginx jungtis (connector), o v3 neišlaiko nedidelės dalies CRS testų. Alternatyva yra Coraza, kuri, pasak projekto, visiškai išlaiko CRS v4 testų rinkinį. Apache projektas rekomenduoja ModSecurity v2. **Ar ModSecurity vis dar prižiūrimas?** Pasak CRS dokumentacijos, Trustwave buvo paskelbusi, kad 2024 m. nutrauks plėtrą. 2024 m. sausio 25 d. projektas perduotas OWASP Foundation ir nuo to laiko ten tęsiamas. **Kaip išvengti, kad WAF nesustabdytų mano parduotuvės?** Pradėkite nuo labai aukštų anomalijų slenksčių, kaip rekomenduoja CRS projektas, ir mažinkite juos palaipsniui. Analizuokite žurnalus ir kurkite tikslines išimtis savo programai, užuot taisykles išjungę bendrai. ## Šaltiniai - [OWASP CRS: dokumentacija](https://coreruleset.org/) - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [Cloudflare tinklaraštis](https://blog.cloudflare.com/) - [php.net: saugumo pranešimai](https://www.php.net/)