Lyhyesti: ModSecurity on Web Application Firewall, joka toimii verkkopalvelimessa; OWASP Core Rule Set (CRS) tarjoaa siihen vapaasti saatavilla olevat säännöt yleisiä hyökkäystapoja vastaan. Apachelle CRS-projekti suosittelee ModSecurity v2:ta, Nginxille tulevat kyseeseen v3-liitin tai Coraza. Aloittakaa estotilassa hyvin korkeilla poikkeamakynnyksillä, laskekaa niitä asteittain ja käsitelkää väärät hälytykset kohdennetuilla poikkeuksilla. PHP-päivitystä se ei korvaa.
Oma WAF lisäkerroksena
PHP2Shellin jälkeen moni yritys kysyy, tarvitsevatko ne Web Application Firewallin. Joka tarjoilee verkkosivustonsa Cloudflaren kautta, on Cloudflaren mukaan saanut suojasäännöt automaattisesti käyttöön 21. lokakuuta 2026 alkaen. Joka ei tee niin tai ei halua ohjata liikennettä kolmannen osapuolen kautta, voi pyörittää WAF:ia suoraan omalla palvelimellaan.
Tunnetuin yhdistelmä siihen on ModSecurity OWASP Core Rule Setin kanssa. Molemmat ovat avointa lähdekoodia ja ilmaisia. CRS on kokoelma yleisiä tunnistussääntöjä esimerkiksi SQL-injektiota, Cross-Site Scriptingiä tai tiedostojen sisäänajoa vastaan. Projekti kuvaa tavoitteekseen yleisen hyökkäystunnistuksen mahdollisimman vähin vääriin hälytyksin, yhtenä rakennuspalikkana muiden joukossa.
Siinä on myös raja nimetty. WAF tarkistaa pyyntöjä ja vastauksia, mutta se ei korjaa aukkoa PHP-tulkissa. Miksi tarvitsette molemmat, kuvaa WAF vai päivitys: miksi tarvitsette molemmat.
Mikä moottori sopii verkkopalvelimeenne
Sääntökokoelma tarvitsee moottorin, joka suorittaa sen. CRS-dokumentaation mukaan on kolme yhteensopivaa vaihtoehtoa:
| Moottori | Verkkopalvelin | Arvio CRS-projektin mukaan |
|---|---|---|
| ModSecurity v2 | Apache (moduuli) | vertailutoteutus, suositeltu Apachelle |
| ModSecurity v3 (libModSecurity) | lähinnä Nginx liittimen kautta | vain Nginx-liitin on todella tuotantokäyttöön kelpaava; ei läpäise 2–4 prosenttia CRS-testeistä |
| Coraza | Go-pohjaiset välityspalvelimet ja integraatiot | läpäisee CRS v4 -testisarjan kokonaan |
Taustaksi: ModSecurityä kehitti pitkään Trustwave. Trustwave ilmoitti vuonna 2021 lopettavansa kehityksen vuonna 2024. 25. tammikuuta 2024 projekti siirtyi OWASP Foundationille. Uusissa asennuksissa tarkistakaa, minkä version jakelunne toimittaa ja kuinka ajan tasalla se on.
Miten Core Rule Set toimii
CRS ei oletusasetuksilla estä ensimmäisestä epäilyttävästä poikkeamasta. Se toimii poikkeamapisteillä: jokainen laukeava sääntö lisää pisteitä vakavuuden mukaan, ja vasta kun summa ylittää kynnyksen, pyyntö hylätään.
- Vakavuusasteet: kriittinen 5 pistettä, virhe 4, varoitus 3, huomautus 2.
- Pyyntöjen kynnys:
tx.inbound_anomaly_score_threshold, oletus 5. - Vastausten kynnys:
tx.outbound_anomaly_score_threshold, oletus 4. - Paranoia-taso 1–4 tiedostossa
crs-setup.conf: taso 1 on perussuoja jokaiselle internetissä olevalle palvelimelle, taso 2 sopii projektin mukaan sovelluksille, joissa on oikeita käyttäjätietoja, kuten verkkokaupoille, tasot 3 ja 4 tuovat selvästi enemmän vääriä hälytyksiä.
Korkeampi paranoia-taso tunnistaa enemmän mutta tuottaa myös enemmän vääriä hälytyksiä. Useimmille yritysten verkkosivustoille taso 1 on alku, taso 2 myöhempi tavoite.
ModSecurityn ja OWASP CRS:n käyttöönotto lamauttamatta verkkosivustoa
CRS-projekti suosittelee uusissa asennuksissa kytkemään estotilan päälle alusta alkaen mutta hyvin korkeilla kynnyksillä, jopa 10000, ja laskemaan niitä sitten asteittain. Näin keräätte kokemusta todellisista käynneistä sulkematta käyttäjiä pois. Kynnykset asetatte tiedostossa crs-setup.conf:
# crs-setup.conf: aloitusvaihe hyvin korkeilla kynnyksillä
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Liittäminen Apachessa noudattaa järjestystä, jonka CRS-dokumentaatio määrää liitännäisille. Polut vaihtelevat jakelun mukaan:
<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>
Sen jälkeen käytte läpi audit-lokin, joka on määritetty kohdassa SecAuditLog. Miten lokit käydään järjestelmällisesti läpi, kuvaa Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen. Laskekaa kynnyksiä vaiheittain, esimerkiksi usean viikon aikana, kunnes saavutatte oletusarvon.
Väärien hälytysten kohdennettu käsittely
Väärät hälytykset ovat normaaleja, erityisesti CMS-taustajärjestelmissä, joiden editorit tallentavat HTML:ää. Huonoin reaktio on kytkeä WAF pois. Parempia ovat kaksi työkalua.
Ensinnäkin liitännäiset: CRS-projekti ylläpitää liitännäisiä, joissa on poikkeussääntöjä yleisille sovelluksille, esimerkiksi WordPressille. Ne kopioidaan liitännäiskansioon ja ladataan yllä näytetyillä Include-riveillä. Virallisen listan projekti ylläpitää liitännäishakemistossaan.
Toiseksi omat, tiukasti rajatut poikkeukset. Sen sijaan, että sääntö kytkettäisiin pois kaikkialta, otatte sen pois vain polulta, jolla se häiritsee:
# Oma poikkeus, lataa ENNEN CRS-sääntöjä (esim. *-before.conf-tiedostossa)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Säännön tunnisteen saatte väärän hälytyksen audit-lokista. Dokumentoikaa jokainen poikkeus syineen ja päivämäärineen, jotta se voidaan tarkistaa myöhemmin.
Testatkaa jokaisen kynnys- tai poikkeusmuutoksen jälkeen sovelluksenne kriittiset reitit: kirjautuminen, tilaus, maksu, yhteydenottolomake ja toimitus. WAF, joka estää tilaukset, kytketään nopeasti taas pois.
Apache-palvelimilla kannattaa lähestyä WAF:ia yhdessä muun asetuksen kanssa; perusteet ovat kohdassa Apachen turvallinen asetus PHP:lle. Miten Cloudflare-säännöt asettuvat vertailussa, näyttää Cloudflaren suojasäännöt PHP2Shelliä vastaan. Siirtymäajan toimenpiteet itse palvelimella ovat kohdassa Pikatoimet, jos ette voi vielä päivittää.
Yhteenveto: WAF tarvitsee huoltoa
ModSecurity OWASP Core Rule Setin kanssa antaa tehokkaan Web Application Firewallin ilman lisenssikuluja ja riippumatta ulkoisesta palvelusta. Hinta on työ: moottorin valinta verkkopalvelimeen sopivaksi, aloitus korkeilla kynnyksillä, väärien hälytysten arviointi, poikkeusten ylläpito ja sääntöjen pitäminen ajan tasalla.
Joka ei pysty tähän vaivaan, pärjää usein paremmin hyvin konfiguroidulla pilvi-WAF:illa. Joka pystyy, saa kerroksen, joka pysäyttää monia vakiohyökkäyksiä ja antaa audit-lokeissa arvokkaita vihjeitä. Missään tapauksessa se ei korvaa päivitystä: PHP2Shelliltä suojaavat vain PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 tai vahvistettu backport, jota seuraa kaikkien PHP-prosessien uudelleenkäynnistys.
Miten PHP SOS auttaa konkreettisesti?
- Moottorin valinta: Tarkistamme verkkopalvelimen, jakelun ja olemassa olevat paketit ja suosittelemme sopivaa yhdistelmää.
- Käyttöönotto: Asennamme CRS:n korkein aloituskynnyksin, liitämme sopivat liitännäiset ja perustamme lokituksen.
- Hienosäätö: Usean viikon ajan arvioimme vääriä hälytyksiä, luomme kohdennettuja poikkeuksia ja laskemme kynnyksiä.
- Sijoittaminen: WAF:n ja virtuaalisen korjauksen yhteydessä yhdistämme WAF:n siirtymäajan toimenpiteisiin ja tiehen varsinaiseen korjaukseen.
Usein kysytyt kysymykset
Suojaako OWASP CRS PHP2Shelliltä?
Siitä ei pitäisi olettaa. Core Rule Set tunnistaa yleisiä hyökkäyskuvioita eikä ole räätälöity tiettyyn aukkoon. Cloudflare huomauttaa lisäksi, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä PHP2Shellin kohdalla. PHP-päivitys pysyy pakollisena.
Minkä moottorin otan Nginxille?
CRS-projektin mukaan ModSecurity v3:ssa vain Nginx-liitin on todella tuotantokäyttöön kelpaava, ja v3 ei läpäise pientä osaa CRS-testeistä. Vaihtoehtona on Coraza, joka projektin tietojen mukaan läpäisee CRS v4 -testisarjan kokonaan. Apachelle projekti suosittelee ModSecurity v2:ta.
Onko ModSecurityä yhä ylläpidetty?
CRS-dokumentaation mukaan Trustwave oli ilmoittanut lopettavansa kehityksen vuonna 2024. 25. tammikuuta 2024 projekti luovutettiin OWASP Foundationille, ja sitä jatketaan siellä siitä lähtien.
Miten estän WAF:ia lamauttamasta verkkokauppaani?
Aloittakaa hyvin korkeilla poikkeamakynnyksillä, kuten CRS-projekti suosittelee, ja laskekaa niitä asteittain. Arvioikaa samalla lokit ja luokaa kohdennettuja poikkeuksia sovelluksellenne sääntöjen yleisen kytkemisen pois sijaan.