Hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8

ModSecurity, oft sem vísað er til sem Modsec, er ókeypis, opinn eldveggur fyrir vefforrit (WAF). ModSecurity var búið til sem eining fyrir Apache HTTP Server. Hins vegar, frá fyrstu dögum þess, hefur WAF vaxið og nær nú yfir fjölda HyperText Transfer Protocol beiðnir og svarsíunargetu fyrir ýmsa vettvanga eins og Microsoft IIS, Nginx og auðvitað Apache.

Hvernig WAF virkar, ModSecurity vélin er sett fyrir framan vefforritið, sem gerir vélinni kleift að skanna inn- og útleiðandi HTTP tengingar. ModSecurity er oftast notað í tengslum við OWASP Core Rule Set (CRS), opinn uppspretta reglna skrifaðar á SecRules tungumáli ModSecurity og er mjög virt meðal öryggisiðnaðarins.

OWASP reglusett með ModSecurity getur næstum samstundis hjálpað til við að vernda netþjóninn þinn gegn:

  • Slæmir umboðsmenn notenda
  • DDOS
  • Cross website forskriftir
  • SQL innspýting
  • Rán á þingi
  • Aðrar hótanir

Í eftirfarandi námskeiði muntu læra hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8.

Forsendur

  • Mælt með stýrikerfi: Rocky Linux 8.+.
  • Notendareikningur: Notendareikningur með sudo eða rót aðgang.

Uppfærðu stýrikerfi

Uppfærðu þína Rocky linux stýrikerfi til að tryggja að allir núverandi pakkar séu uppfærðir:

sudo dnf upgrade --refresh -y

Kennsluefnið mun nota sudo skipun og að því gefnu að þú sért með sudo stöðu.

Til að staðfesta sudo stöðu á reikningnum þínum:

sudo whoami

Dæmi um úttak sem sýnir sudo stöðu:

[joshua@rockylinux ~]$ sudo whoami
root

Til að setja upp núverandi eða nýjan sudo reikning skaltu fara á kennsluna okkar á Hvernig á að bæta notanda við Sudoers á Rocky Linux.

Til að nota rótarreikningur, notaðu eftirfarandi skipun með rót lykilorðinu til að skrá þig inn.

su

Virkjaðu EPEL geymslu

Til að setja upp ModSecurity með Rocky Linux 8 með góðum árangri þarftu að virkja EPEL geymsluna til að ljúka uppsetningu á Modsecurity.

Settu upp EPEL geymslu:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y

Fáðu


Settu upp nýjustu Nginx á Rocky Linux 8

Sjálfgefið er að þú getur haldið núverandi útgáfu af Nginx uppsettri ef þú getur fundið samsvarandi útgáfu fyrir hana. Ef ekki, er mælt með því að setja upp annað hvort nýjustu stöðugu eða aðalbygginguna af Nginx, þar sem kennsla fer í gegnum hér að neðan.

Fjarlægðu núverandi Nginx uppsetningu

Stöðvaðu núverandi Nginx þjónustu:

sudo systemctl stop nginx

Fjarlægðu nú núverandi Nginx uppsetningu sem hér segir:

sudo dnf remove nginx

Bætir við Ngnix geymslunni

Nú þegar þú hefur fjarlægt gömlu Nginx útgáfuna, ef þú hafðir hana uppsetta, til að setja upp Nginx mainline, þarftu fyrst að setja upp ósjálfstæði fyrir hana, sem er dnf-tól með eftirfarandi skipun:

sudo dnf install dnf-utils -y

Þegar það hefur verið sett upp skaltu nota uppáhalds textaritilinn þinn, búa til eftirfarandi skrá:

sudo nano /etc/yum.repos.d/nginx.repo

Næst þarftu að bæta við eftirfarandi kóða, sem tilgreinir Nginx geymslurnar sem þú getur sett upp annað hvort stöðugar eða aðallínu frá:

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

Til að spara notkun (CTRL+O), farðu síðan út (CTRL+X).

Settu upp Nginx

Sjálfgefið er að nýjasta geymslan fyrir stöðuga Nginx pakka er fyrst notuð. Hins vegar mun kennsla setja upp Nginx aðallína, svo þú þarft að keyra eftirfarandi skipun til að virkja aðallínugeymsluna sem hér segir:

sudo yum-config-manager --enable nginx-mainline

Athugaðu að ef þú vilt frekar stöðugt skaltu ekki nota skipunina hér að ofan og halda áfram í næsta hluta kennslunnar.

Næst skaltu setja upp Nginx mainline eins og hér segir:

sudo dnf install nginx
Hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8

Athugaðu að þú munt sjá sprettiglugga sem lætur þig vita um innflutning á GPG lykill meðan á uppsetningu stendur. Þetta er óhætt að gera og er nauðsynlegt til að klára uppsetningu Nginx mainline með góðum árangri. Gerð „Y“ og ýttu "KOMA INN".

Hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8

Sjálfgefið er að Nginx er ekki virkt og er óvirkt við uppsetningu. Til að virkja Nginx þjónustuna þína skaltu nota:

sudo systemctl start nginx

Til að gera kleift að ræsa Nginx við ræsingu, notaðu eftirfarandi skipun:

sudo systemctl enable nginx

Til að staðfesta útgáfuna þína af Nginx, okkar tilviki Nginx Mainline útgáfan, notaðu eftirfarandi skipun til að staðfesta:

nginx -v

Dæmi úttak:

Hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8

Stilla eldvegg

Ef þú ert ekki að skipta um núverandi Nginx þjónustu og setja upp Nginx í fyrsta skipti gætirðu þurft að stilla eldvegginn fyrir HTTP og HTTPS umferð. Dæmi um hvernig á að gera þetta er hér að neðan:

Til að leyfa HTTP umferð notaðu eftirfarandi skipun:

sudo firewall-cmd --permanent --zone=public --add-service=http

Til að leyfa HTTPS umferð notaðu eftirfarandi skipun:

sudo firewall-cmd --permanent --zone=public --add-service=https

Þegar þessu er lokið þarftu að gera breytingarnar virkar með því að endurhlaða eldvegginn:

sudo firewall-cmd --reload

Fáðu


Valfrjálst. Öruggt Nginx með Let's Encrypt SSL Free Certificate

Helst myndirðu vilja keyra Nginx þinn á HTTPS með SSL vottorði. Besta leiðin til að gera þetta er að nota Við skulum dulkóða, ókeypis, sjálfvirkt og opið vottunaryfirvald rekið af Internet Security Research Group (ISRG) sem ekki er rekin í hagnaðarskyni.

Fyrst skaltu setja upp EPEL geymsla og mod_ssl pakki fyrir betur uppfærða pakka og öryggi.

sudo dnf install epel-release mod_ssl -y

Settu næst upp certbot pakki eins og hér segir:

sudo dnf install python3-certbot-nginx -y

Þegar það hefur verið sett upp skaltu keyra eftirfarandi skipun til að hefja gerð vottorðsins þíns:

sudo certbot --nginx --agree-tos --redirect --hsts --staple-ocsp --email you@example.com -d www.example.com

Þetta er tilvalin uppsetning sem inniheldur þvingaða HTTPS 301 tilvísanir, Strict-Transport-Security haus og OCSP heftingu. Gakktu úr skugga um að aðlaga tölvupóstinn og lénið að þínum þörfum.

Nú verður vefslóðin þín HTTPS://www.example.com Í stað þess að HTTP://www.example.com.

Athugið, ef þú notar gamla HTTP vefslóð, mun það sjálfkrafa vísa til HTTPS.

Valfrjálst geturðu stillt cron starf til að endurnýja vottorðin sjálfkrafa. Certbot býður upp á handrit sem gerir þetta sjálfkrafa, og þú getur fyrst prófað til að ganga úr skugga um að allt virki með því að framkvæma þurrkeyrslu.

sudo certbot renew --dry-run

Ef allt virkar skaltu opna crontab gluggann þinn með því að nota eftirfarandi flugstöðvaskipun.

sudo crontab -e

Næst skaltu tilgreina tímann þegar það ætti að endurnýja sjálfkrafa. Þetta ætti að vera athugað daglega að lágmarki og ef endurnýja þarf vottorðið mun handritið ekki uppfæra vottorðið. Ef þú þarft hjálp við að finna góðan tíma til að stilla skaltu nota crontab.guru ókeypis tól.

00 00 */1 * * /usr/sbin/certbot-auto renew

Vista (CTRL+O) farðu síðan út (CTRL+X), og cronjob verður sjálfkrafa virkt.

Sækja Nginx Source

Þú þarft að hlaða niður Nginx frumkóðanum til að setja saman ModSecurity kraftmikla mát. Til að gera þetta þarftu að hlaða niður og geyma frumpakkann á möppustaðnum /etc/local/src/nginx.

Búðu til og stilltu möppur

Búðu til staðsetninguna sem hér segir:

sudo mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Valfrjálst - Úthlutaðu heimild til möppunnar ef þörf krefur eins og hér að neðan:

sudo chown username:username /usr/local/src/ -R

Sækja Source Archive

Næst skaltu hlaða niður Nginx upprunaskjalasafninu af niðurhalssíðunni til að passa við Nginx útgáfuna sem þú tilgreindir áðan. Jafnvel þó þú hafir ekki uppfært í nýjustu útgáfuna af stable eða mainline Nginx og notaðir eldri útgáfu, ættirðu að geta fundið heimild sem passar við þína eigin.

Sæktu heimildina með því að nota wget skipun sem hér segir (aðeins dæmi):

wget http://nginx.org/download/nginx-1.21.1.tar.gz

Næst skaltu draga út skjalasafnið sem hér segir:

tar -xvzf nginx-1.21.1.tar.gz

Staðfestu upprunaútgáfu

Næst skaltu skrá möppuskrárnar með ls skipun sem hér segir:

ls

Dæmi framleiðsla í þínu /usr/src/local/nginx Skrá:

jjames@rockylinux:/usr/local/src/nginx$ ls
nginx-1.21.1

nginx_1.21.1.orig.tar.gz

Næst skaltu staðfesta að frumpakkinn sé sá sami og Nginx útgáfan þín uppsett á Rocky Linux stýrikerfinu þínu.

Til að gera þetta, notaðu eftirfarandi nginx -v skipun sem hér segir:

nginx -v

Þú ættir að fá sömu úttaksútgáfu og upprunann sem hér segir:

jjames@rockylinux:/usr/local/src/nginx$ nginx -v
nginx version: nginx/1.21.1

Fáðu


Settu upp libmodsecurity3 fyrir ModSecurity

Pakkinn libmodsecurity3 er grundvallarhluti WAF sem gerir HTTP síun fyrir vefforritin þín. Þú munt safna saman úr upprunanum.

Klóna ModSecurity Repsoitory frá Github

Fyrsta skrefið er klóninn frá Github og ef þú ert ekki með git uppsett þarftu að framkvæma eftirfarandi skipun:

sudo dnf install git -y

Næst skaltu klóna libmodsecurity3 GIT geymsla sem hér segir:

sudo git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

Þegar það hefur verið klónað þarftu að gera það CD í möppuna:

cd /usr/local/src/ModSecurity/

Settu upp libmodsecurity3 Dependencies

Til að safna saman þarftu að setja upp eftirfarandi ósjálfstæði eins og hér segir:

sudo dnf install gcc-c++ flex bison yajl curl-devel zlib-devel pcre-devel autoconf automake git curl make libxml2-devel pkgconfig libtool httpd-devel redhat-rpm-config wget openssl openssl-devel nano

Næst skaltu setja upp önnur ósjálfstæði með því að nota PowerTool geymsluna:

sudo dnf --enablerepo=powertools install doxygen yajl-devel

Settu nú upp GeoIP með því að nota REMI geymsluna sem þú bættir við í upphafi kennslunnar:

sudo dnf --enablerepo=remi install GeoIP-devel

Nú til að klára skaltu setja upp eftirfarandi GIT undireiningar sem hér segir:

sudo git submodule init

Uppfærðu síðan undireiningarnar:

sudo git submodule update

Að byggja upp ModSecurity umhverfið

Næsta skref er nú í raun að byggja upp umhverfið fyrst. Notaðu eftirfarandi skipun:

sudo ./build.sh

Næst skaltu keyra stilla skipunina:

sudo ./configure

Athugaðu, þú munt hugsanlega sjá eftirfarandi villu

fatal: No names found, cannot describe anything.

Þú getur örugglega hunsað þetta og haldið áfram í næsta skref.

Að setja saman ModSecurity frumkóðann

Nú þegar þú hefur smíðað og stillt umhverfið fyrir libmodsecurity3 er kominn tími til að setja það saman með skipuninni gera.

sudo make

Handhægt bragð er að tilgreina -j þar sem þetta getur aukið samsetningarhraða verulega ef þú ert með öflugan netþjón. Til dæmis, LinuxCapable miðlarinn hefur 6 örgjörva, og ég get notað alla 6 eða að minnsta kosti notað 4 til 5 til að auka hraðann.

sudo make -j 6

Eftir að hafa safnað saman frumkóðann skaltu keyra uppsetningarskipunina í flugstöðinni þinni:

sudo make install

Athugið að uppsetningin er gerð í /usr/local/modsecurity/, sem þú munt vísa til síðar í handbókinni.

Settu upp ModSecurity-nginx tengi

The ModSecurity-nginx tengi er tengipunktur milli Nginx og libmodsecurity. Það er íhluturinn sem hefur samskipti á milli Nginx og ModSecurity (libmodsecurity3).

Klóna ModSecurity-nginx Repsoitory frá Github

Svipað og í fyrra skrefi sem klónaði libmodsecurity3 geymsluna, þá þarftu að klóna tengigeymsluna aftur með því að nota eftirfarandi skipun:

sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

Settu upp ModSecurity-nginx

Næst skaltu geisladiskaskrá inn í Nginx upprunaskrána sem hér segir:

cd /usr/local/src/nginx/nginx-1.21.1

Athugaðu, skiptu út útgáfu handbókarinnar fyrir núverandi Nginx útgáfu í kerfinu þínu.

Næst muntu setja saman ModSecurity-nginx tengi mát aðeins með –Met-compat fána sem hér segir:

sudo ./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

nú gera (búa til) kviku einingarnar með eftirfarandi skipun:

sudo make modules

Næst, meðan þú ert í Nginx upprunaskránni, notaðu eftirfarandi skipun til að færa kraftmiklu eininguna sem þú varst að búa til sem var vistuð á staðnum objs/ngx_http_modsecurity_module.so og afritaðu það á /usr/lib64/user/modules skrá.

sudo cp objs/ngx_http_modsecurity_module.so /usr/lib64/nginx/modules/

Fáðu


Hladdu og stilltu ModSecurity-nginx tengi með Nginx

Nú þegar þú hefur tekið saman kviku eininguna og staðsett hana í samræmi við það þarftu að breyta /etc/nginx/nginx.conf stillingarskrá til að fá ModSecurity í notkun með Nginx vefþjóninum þínum.

Virkjaðu ModSecurity í nginx.conf

Í fyrsta lagi þarftu að tilgreina load_module og leið að modsecurity einingunni þinni.

Opinn upp nginx.conf með hvaða textaritli sem er. Fyrir kennsluna verður nano notað:

sudo nano /etc/nginx/nginx.conf

Næst skaltu bæta eftirfarandi línu við skrána nálægt toppnum:

load_module modules/ngx_http_modsecurity_module.so;

Ef þú hefur fundið eininguna annars staðar, vertu viss um að hafa alla leiðina með.

Bættu nú við eftirfarandi kóða undir HTTP {} kafla sem hér segir:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

Aðeins dæmi:

Hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8

Ef þú hefur fundið eininguna annars staðar, vertu viss um að hafa alla leiðina með.

Vista nginx.conf skrá (CTRL+O), farðu síðan út (CTRL+X).

Búðu til og stilltu möppu og skrár fyrir ModSecurity

Þú þarft að búa til möppu til að geyma stillingarskrár og framtíðarreglur, OWASP CRS fyrir kennsluna.

Notaðu eftirfarandi skipun til að búa til /etc/nginx/modsec skrá sem hér segir:

sudo mkdir -p /etc/nginx/modsec/

Nú þarftu að afrita sýnishorn af ModSecurity stillingarskránni aftur úr klónuðu okkar GIT Skrá:

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Notaðu uppáhalds textaritilinn þinn í Rocky Linux, opnaðu modsecurity.conf skjal sem hér segir:

sudo nano /etc/nginx/modsec/modsecurity.conf

Sjálfgefið er að ModSecurity stillingar hafa regluvélina tilgreinda sem (Aðeins uppgötvun), sem með öðrum orðum, keyrir ModSecurity og greinir alla illgjarna hegðun en gerir ekki aðgerðablokkir eða bannar og skráir allar HTTP færslur sem það flaggar. Þetta ætti aðeins að nota ef þú ert með fullt af fölskum jákvæðum eða hefur aukið öryggisstigsstillingar í öfgamikið stig og prófað til að sjá hvort rangar jákvæðar niðurstöður eiga sér stað.

Til að breyta þessari hegðun í (á), finndu eftirfarandi á 7. lína:

SecRuleEngine DetectionOnly

Breyttu línunni í þetta til að virkja ModSecurity:

SecRuleEngine On

Nú þarftu að finna eftirfarandi, sem er staðsett á 224. lína:

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Þetta er ekki rétt og þarf að breyta. Breyttu línunni í eftirfarandi:

SecAuditLogParts ABCEFHJKZ

Vistaðu nú modsecurity.conf skrá með (CTRL+O) farðu síðan út (CTRL+X).

Næsti hluti er að búa til eftirfarandi skrá modsec-config.conf. Hér munt þú bæta við modsecurity.conf skrá meðfram og síðar um aðrar reglur eins og OWASP CRS, og ef þú ert að nota WordPress, the WPRS CRS reglu sett.

Notaðu eftirfarandi skipun til að búa til skrána og opna hana:

sudo nano /etc/nginx/modsec/modsec-config.conf

Þegar þú ert inni í skránni skaltu bæta við eftirfarandi línu:

Include /etc/nginx/modsec/modsecurity.conf

Vista modsec-config.conf skrá með (CTRL+O) Þá (CTRL+X) að hætta.

Að lokum, afritaðu ModSecurity's unicode.mapping skrá með CP skipun sem hér segir:

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

Nú áður en þú heldur áfram ættirðu að gefa Nginx þjónustunni þinni þurrt hlaup með eftirfarandi flugstöðvarskipun:

sudo nginx -t

Ef þú hefur sett allt rétt upp ættirðu að fá eftirfarandi úttak:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Til að gera breytingarnar lifandi skaltu endurræsa Nginx þjónustuna þína með því að nota systemctl stjórn:

sudo systemctl restart nginx

Settu upp OWASP kjarnareglusett fyrir ModSecurity

ModSecurity eitt og sér verndar ekki vefþjóninn þinn og þú þarft að hafa reglur. Ein frægasta, virtasta og þekktasta reglan sem sett er er OWASP CRS reglusett. Reglurnar hér eru þær sem eru mest notaðar meðal netþjóna og annarra WAF. Reyndar, og flest önnur svipuð kerfi byggja flestar reglur sínar á þessu CRS. Að setja þetta reglusett upp mun sjálfkrafa veita þér frábæra vernd gegn flestum nýjum ógnum á netinu með því að greina illgjarna aðila og loka á þá.

Það er vert að hafa í huga að OWASP CRS hefur venjulega stöðugar útgáfur, sem tekur oft um eitt ár á milli útgáfur. Núverandi útgáfa er 3.3. Málið er að nýrri reglur sem unnið er að til úrbóta, nýrrar uppgötvunar, fjarlægingar á fölskum jákvæðum og innihalda frekari útilokanir fyrir staðlaðan hugbúnað eins og phpBB spjallborð sem kynntar voru í 3.4 forriturunum (beta) útgáfa eru ekki með fyrr en í næstu heildarútgáfu.

Gallinn má sjá á tvo vegu: notaðu 3.3 pakkana, hafa stöðugar framúrskarandi reglur og hugsanlega ekki uppfært fyrir nýjustu ógnirnar, lagfæringar og endurbætur með því að nota 3.4 dev útgáfuna. Þú munt hafa allt þetta en gætir kannski séð önnur vandamál koma upp. Hins vegar er þetta sjaldgæft þar sem áður en OWASP kjarnareglusettið tekur nýjar skuldbindingar til aðalgeymslunnar, þá halda þeir mánaðarlega fundi til að ræða breytingarnar svo oft er ekki bara einn einstaklingur sem hringir heldur heilt teymi sem fer yfir breytingarnar og samþykkir þær sem hópur sem gerir þróunarútgáfuna venjulega frekar stöðuga.

Í kennslunni verður farið yfir hvort tveggja og það er undir þér komið hvernig á að fara að því. Gakktu úr skugga um að þú fylgist með ModSecurity annálum þínum, í hvaða tilfelli sem er, óháð vandamálum, sérstaklega í kringum rangar jákvæðar.

Valkostur 1. Settu upp OWASP CRS 3.3 (stöðugt)

Notkun á wget skipun, hlaða niður OWASP CRS 3.3 skjalasafn eins og hér segir:

wget https://github.com/coreruleset/coreruleset/archive/refs/heads/v3.3/master.zip

setja Unzip pakkann ef þú ert ekki með þetta uppsett á þjóninum þínum:

sudo dnf install unzip -y

afpakka á master.zip skjalasafn sem hér segir:

sudo unzip /etc/nginx/master.zip -d /etc/nginx/modsec

Eins og áður, eins og modsecurity.conf sýnishorn stillingar, OWASP CRS kemur með sýnishorn af stillingarskrá sem þú þarft að endurnefna. Það er best að nota CP stjórn og geymdu öryggisafrit til framtíðar ef þú þarft að endurræsa aftur.

sudo cp /etc/nginx/modsec/coreruleset-3.3-master/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3-master/crs-setup.conf

Til að virkja reglurnar skaltu opna /etc/nginx/modsec/modsec-config.conf nota hvaða textaritil sem er aftur:

sudo nano /etc/nginx/modsec/modsec-config.conf

Þegar þú ert kominn inn í skrána aftur skaltu bæta við eftirfarandi tveimur línum til viðbótar:

Include /etc/nginx/modsec/coreruleset-3.3-master/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3-master/rules/*.conf

Vistaðu skrána (CTRL+O) og fara út (CTRL+T).

Eins og áður, þú þarft að prófa allar nýjar viðbætur við Nginx þjónustuna þína áður en þú gerir hana lifandi:

sudo nginx -t

Þú ættir að fá eftirfarandi úttak sem þýðir að allt virkar rétt:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Endurræstu Nginx þjónustuna þína til að gera breytingarnar lifandi sem hér segir:

sudo systemctl restart nginx

Valkostur 2. Settu upp OWASP CRS 3.4 (dev)

Athugið, með því að nota 3.4 dev, og þú þarft stöðugt að fylgjast með breytingum á geymslunni. Oft koma nýjar viðbætur nokkrum sinnum í mánuði til nokkrum sinnum í viku. Ef þú hefur ekki skuldbindinguna eða ert ekki öruggur skaltu setja upp valmöguleika 1 og sleppa þessum valmöguleika alveg.

Notkun á wget skipun, hlaða niður OWASP CRS 3.3.4 skjalasafn eins og hér segir:

wget https://github.com/coreruleset/coreruleset/archive/refs/heads/v3.4/dev.zip

setja Unzip pakkann ef þú ert ekki með þetta uppsett á þjóninum þínum:

sudo dnf install unzip -y

afpakka á dev.zip skjalasafn sem hér segir:

sudo unzip dev.zip /etc/nginx/modsec

Eins og áður, eins og modsecurity.conf sýnishorn stillingar, OWASP CRS kemur með sýnishorn af stillingarskrá sem þú þarft að endurnefna. Það er best að nota CP stjórn og geymdu öryggisafrit til framtíðar ef þú þarft að endurræsa aftur.

sudo mv /etc/nginx/modsec/coreruleset-3.3.4-dev/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.4-dev/crs-setup.conf

Til að virkja reglurnar skaltu opna /etc/nginx/modsec/modsec-config.conf nota hvaða textaritil sem er aftur:

sudo nano /etc/nginx/modsec/modsec-config.conf

Þegar þú ert kominn inn í skrána aftur skaltu bæta við eftirfarandi tveimur línum til viðbótar:

Include /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.4-dev/rules/*.conf

Vistaðu skrána (CTRL+O) og fara út (CTRL+T).

Eins og áður, þú þarft að prófa allar nýjar viðbætur við Nginx þjónustuna þína áður en þú gerir hana lifandi:

sudo nginx -t

Þú ættir að fá eftirfarandi úttak sem þýðir að allt virkar rétt:

Endurræstu Nginx þjónustuna þína til að gera breytingarnar lifandi sem hér segir:

sudo systemctl restart nginx

Uppfærsla 3.4-dev

Ef þú þarft að uppfæra reglurnar fyrir dev OWASP CRS útgáfuna skaltu hlaða niður skjalasafninu aftur eins og fyrsta skrefið og draga skrárnar aftur út. Skrárnar sem eru hannaðar til að breyta verður ekki skipt út, þess vegna hefur þú séð svo margar sýnishorn af uppsetningunni.


Fáðu


Notkun og skilning á OWASP CRS

OWASP kjarnareglan hefur ansi marga möguleika, sjálfgefnar stillingar, hins vegar úr kassanum, vernda flesta netþjóna strax án þess að skaða raunverulega gesti þína og góða SEO vélmenni. Hér að neðan verður farið yfir nokkur svæði til að útskýra. Frekari lestur væri best að kanna alla valkosti í stillingarskránum sjálfum þar sem þær hafa töluvert af textagögnum til að útskýra hvað þeir eru.

Opnaðu þinn CRS-setup.conf skjal sem hér segir:

sudo nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf

Athugið, þetta er uppsetning þróunarútgáfunnar með viðbótarhlutum miðað við útgáfu 3.3.

Héðan geturðu breytt flestum OWASP CRS stillingum þínum.

OWASP CRS stigagjöf

Til að brjóta það niður hefur ModSecurity tvær stillingar:

Fráviksstigastilling

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Sjálfvirk stilling

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

Fráviksstig er almennt fyrir flesta notendur besta stillingin til að nota.

Það eru fjögur ofsóknarstig:

  • Paranoia stig 1 – Sjálfgefið stig og mælt með fyrir flesta notendur.
  • Paranoia stig 2 – Aðeins háþróaðir notendur.
  • Paranoia stig 3 – Aðeins sérfræðingar notendur.
  • Paranoia stig 4 – Alls ekki mælt með því, nema í undantekningartilvikum.
# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Prófaðu OWASP CRS á netþjóninum þínum

Til að prófa hvort OWASP reglur virki á netþjóninum þínum skaltu opna netvafrann þinn og nota eftirfarandi:

https://www.yourdomain.com/index.html?exec=/bin/bash

Þú ættir að fá a 403 bönnuð villa. Ef ekki, þá hefur skref verið misst.

Algengasta vandamálið vantar til að breyta Einungis uppgötvun til Á, eins og fjallað var um fyrr í kennslunni.

Að takast á við falskt jákvætt og útilokun sérsniðna reglna

Eitt af oft endalausu verkunum er að takast á við rangar jákvæðar upplýsingar, ModSecurity og OWASP CRS gera frábært starf saman, en það kostar tíma þinn, en miðað við verndina þá færðu það er þess virði. Til að byrja með er það gullna reglan að setja ofsóknarstigið aldrei hátt til að byrja með.

Góð þumalputtaregla er að keyra reglusettið í nokkrar vikur til mánuði með varla neinum fölskum jákvæðum, hækka svo til dæmis ofsóknarstig 1 í ofsóknarstig 2, svo þú ert ekki yfirfullur af tonni samtímis.

Að frátöldum falskum jákvæðum þekktum forritum

Modsecurity getur sjálfgefið hvítlistað hversdagslegar aðgerðir sem leiða til rangra jákvæða eins og hér að neðan:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Til að virkja td. WordPress, phpBB og phpMyAdmin eins og þú notar öll þrjú, afskrifaðu línurnar og yfirgefa (1) númer ósnortið, breyttu öðrum þjónustum sem þú notar ekki, td Xenforo í (0) þar sem þú vilt ekki setja þessar reglur á hvítlista. Dæmi hér að neðan:

SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_cpanel=0,\
setvar:tx.crs_exclusions_dokuwiki=0,\
setvar:tx.crs_exclusions_drupal=0,\
setvar:tx.crs_exclusions_nextcloud=0,\
setvar:tx.crs_exclusions_phpbb=1,\
setvar:tx.crs_exclusions_phpmyadmin=1,\
setvar:tx.crs_exclusions_wordpress=1,\
setvar:tx.crs_exclusions_xenforo=0"

Þú getur líka breytt setningafræðinni, sem væri hreinni. Til dæmis:

SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_phpbb=1,\
setvar:tx.crs_exclusions_phpmyadmin=1,\
setvar:tx.crs_exclusions_wordpress=1"

Eins og þú sérð eru valkostirnir fjarlægðir sem ekki er þörf og bætt við (“) í lok WordPress fyrir rétta setningafræði.

Að undanskildum reglum í Before CRS

Til að takast á við sérsniðnar útilokanir þarftu í fyrsta lagi að breyta nafninu úr REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf skrá með CP stjórn eins og hér segir:

sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Atriði til að muna, þegar útilokunarreglur eru búnar til verður hver og einn að hafa auðkenni: og vertu einstakur, annars færðu villu þegar þú prófar Nginx þjónustuna þína. Dæmi „id:1544,phase:1,log,allow,ctl:ruleEngine=off“, ekki er hægt að nota auðkennið 1544 fyrir aðra reglu.

Til dæmis munu sumar REQUEST_URI birta rangar jákvæðar niðurstöður. Dæmið hér að neðan er tvö með Google pagespeed beacon og WMUDEV viðbót fyrir WordPress:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"
SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Eins og þú sérð verða allar vefslóðir sem byrja á slóðinni sjálfkrafa leyfðar.

Annar valkostur er að hvítlista IP tölur, nokkrar leiðir sem þú getur farið í þessu:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

The @ipMatch hægt að nota í meira mæli fyrir undirnet. Ef þú vilt neita a undirnet or IP-tala breyta, leyfa að neita. Með smá þekkingu geturðu líka búið til svarta lista og hvítlista og stillt þetta með fail2ban. Möguleikarnir geta oft verið endalausir.

Eitt síðasta dæmi er að slökkva aðeins á reglum sem kalla fram rangar jákvæðar niðurstöður, ekki hvítlista alla leiðina eins og þú sást með fyrsta REQUEST_URI dæminu. Hins vegar tekur þetta meiri tíma og próf. Til dæmis viltu fjarlægja reglur 941000 og 942999 frá /admin/ svæðinu þínu þar sem það kveikir stöðugt á fölskum bönnum og blokkum fyrir liðið þitt, finndu í öryggisskrárskránni þinni regluauðkennið og slökktu síðan á því auðkenni með RemoveByID eins og dæmið hér að neðan:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Dæmi er að finna á ModSecurity GIT wiki síðu; LinuxCapable mun í framtíðinni búa til kennsluefni um þennan hluta þar sem það er töluvert mikið sem þarf að fjalla um.

Valfrjálst – Láttu Project Honeypot fylgja með

Project Honey Pot er fyrsta og eina dreifða kerfið til að bera kennsl á ruslpóstsmiðlara og ruslpóstana sem þeir nota til að skafa heimilisföng af vefsíðunni þinni. Með því að nota Project Honey Pot kerfið geturðu sett upp sérmerkt heimilisföng á tíma og IP tölu gesta á síðuna þína. Ef eitt af þessum netföngum byrjar að fá tölvupóst getum við ekki aðeins sagt að skilaboðin séu ruslpóstur, heldur einnig nákvæmlega hvenær heimilisfangið var safnað og IP-tölu sem safnaði því.

ModSecurity getur haft möguleika á að samþætta Project Honeypot, sem mun spyrjast fyrir um gagnagrunninn og loka fyrir öll heimilisföng sem eru á HoneyPot svarta listanum. Athugaðu, að nota þetta getur leitt til rangra jákvæðra. Hins vegar er þetta lítið þar sem gögnin eru áreiðanleg, en stundum eru góðir vélmenni aðallega merktir, svo farðu varlega.

Annað vandamál með því að nota þessa þjónustu með ModSecurity þinni er að í fyrsta skipti sem gestur kemur á síðuna þína, mun dýrmætur og oft mikilvægur hleðslutími fyrir nýja gesti vera hægari vegna þess að vefþjónninn þinn mun senda fyrirspurn til Project Honeypot og bíða eftir svari. Í framtíðinni, þegar IP hefur verið sent, er svarið sem sent er til baka í skyndiminni, sem gerir næstu heimsókn fljótari. Hins vegar, miðað við svo mikla áherslu á hleðslutíma með SEO, gætu sumir ekki notið aukahleðslutímans, sama hversu lítill hann er.

Skref 1. Búðu til reikning a ókeypis reikningur.

Skref 2. Þegar þú hefur skráð þig og skráð þig inn, finndu línuna á mælaborðinu (http:BL API lykillinn þinn) og smelltu Fáðu einn.

Hvernig á að setja upp ModSecurity með Nginx á Rocky Linux 8

Skref 3. Farðu aftur í CRS-setup.conf skrána með því að opna hana með textaritli:

sudo nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf

Skref 4. Finndu línuna sem byrjar á #SecHttpBlKey, sem er á línu 629.

#SecHttpBlKey XXXXXXXXXXXXXXXXX
#SecAction "id:900500,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.block_search_ip=1,\
#  setvar:tx.block_suspicious_ip=1,\
#  setvar:tx.block_harvester_ip=1,\
#  setvar:tx.block_spammer_ip=1"

Skref 5. Breyttu SecHttpBlKey XXXXXXXXXXXXXXXXX með lyklinum þínum úr Project HoneyPot.

Dæmi:

SecHttpBlKey amhektvkkupe

Skref 6. Næst skaltu fjarlægja athugasemdir við allar línur til að virkja regluna. Ef þú vilt slökkva á reglu, í staðinn fyrir (1), setja (0) í staðinn ef þú vilt gera eitthvað af reglunum óvirka. Sjálfgefið, block_search_ip=0 er fyrir leitarvélar vélmenni, ekki virkja þetta nema þú viljir að Bing, Google og aðrir góðir vélmenni komi á síðuna þína.

SecHttpBlKey amhektvkkupe
SecAction "id:900500,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.block_search_ip=0,\
setvar:tx.block_suspicious_ip=1,\
setvar:tx.block_harvester_ip=1,\
setvar:tx.block_spammer_ip=1"

Athugið, ekki nota amhektvkkupe. Notaðu lykilinn þinn í staðinn!

Skref 7. Prófaðu Nginx til að ganga úr skugga um að engar villur hafi komið upp með eftirfarandi:

sudo nginx -t

Dæmi úttak ef allt er rétt:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Endurræstu nú Nginx þjónustuna þína:

sudo systemctl restart nginx

WordPress WPRS reglusett fyrir ModSecurity

Annar valkostur fyrir WordPress notendur eru að setja upp og keyra samhliða OWASP CRS reglusettinu þínu, vel þekkt verkefni sem ber yfirskriftina WPRS reglusett. Þar sem þetta er valfrjálst og er ekki fyrir alla, mun kennsluefnið ekki fjalla um það í þessum hluta. Hins vegar, ef þú vilt setja þetta upp til að auka vernd ef þú notar WordPress á netþjóninum þínum, vinsamlegast farðu á kennsluna okkar um Uppsetning WordPress ModSecurity Rule Set (WPRS).


Fáðu


Búðu til ModSecurity LogRotate skrá:

ModSecurity, miðað við hversu margar línur og upplýsingar það getur skráð, mun vaxa nokkuð hratt. Þar sem þú ert að setja saman eininguna og hún er ekki sett upp í gegnum neina opinbera geymslu frá Rocky Linux, þarftu að búa til þína eigin snúningsskrá.

Fyrst skaltu búa til og opna ModSecurity snúningsskrána þína modsec:

sudo nano /etc/logrotate.d/modsec

Bættu við eftirfarandi kóða:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Þetta mun halda logs fyrir 31 daga. Ef þú vilt frekar hafa minna skaltu breyta 31 að segja 7 daga jafnt viku virði af logum. Þú ættir að snúa daglega fyrir ModSecurity. Ef þú þarft að endurskoða annálaskrárnar að hafa vikulega skrá verður hörmung að sigta í gegnum, miðað við hversu stór hún verður.

Athugasemdir og niðurstaða

Í kennslunni hefurðu tök á því að setja upp Nginx upprunann, setja saman ModSecurity og setja upp OWASP reglurnar meðal efstu hlutanna. Á heildina litið mun það að dreifa ModSecurity á netþjóninn þinn veita tafarlausa vernd. Hins vegar, þolinmæði, tími og hollustu við nám þurfa að vera svo frábær eiginleiki. Það síðasta sem þú vilt er að loka fyrir SEO vélmenni eða, mikilvægara, alvöru notendur sem gætu verið hugsanlegir viðskiptavinir.

Leyfi a Athugasemd