Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

Ang ModSecurity, nga sagad gitawag nga Modsec, usa ka libre, open-source nga web application firewall (WAF). Ang ModSecurity gimugna isip module para sa Apache HTTP Server. Bisan pa, sukad sa unang mga adlaw niini, ang WAF mitubo ug karon naglangkob sa usa ka han-ay sa HyperText Transfer Protocol nga hangyo ug mga kapabilidad sa pagsala sa tubag alang sa nagkalain-laing mga plataporma sama sa Microsoft IIS, Nginx, ug Apache. Ang panguna nga tahas sa ModSecurity mao ang paghatag proteksyon sa mga aplikasyon sa web pinaagi sa pagsala sa umaabot nga trapiko ug pagbabag sa mga malisyosong hangyo. Ang WAF mahimo usab nga i-configure aron ma-monitor ang trapiko alang sa pipila nga mga matang sa kalihokan, sama sa mga pag-atake sa SQL injection, ug makamugna og mga alerto kung ang ingon nga kalihokan mamatikdan. Dugang sa mga benepisyo sa seguridad niini, ang ModSecurity makapauswag sa performance sa web pinaagi sa pag-cache sa mga lagda ug pagwagtang sa panginahanglan nga balik-balikon ang pagproseso sa samang hangyo.

Uban sa pag-instalar sa Modsecurity, ang OWASP Core Rule Set (CRS) sagad gigamit kauban nga usa ka open-source set sa mga lagda nga gisulat sa SecRules nga pinulongan sa ModSecurity. Ang CRS gitamod pag-ayo sa industriya sa seguridad, ug ang ModSecurity gikonsiderar nga usa sa labing epektibo nga paagi sa pagpanalipod sa mga aplikasyon sa web gikan sa pag-atake. Samtang ang ModSecurity dili usa ka pilak nga bala, kini usa ka hinungdanon nga himan sa arsenal sa bisan unsang organisasyon nga nagseryoso sa seguridad sa web.

Ang OWASP Rule Set nga adunay ModSecurity hapit dayon makatabang sa pagpanalipod sa imong server.

  • Dili maayo nga mga ahente sa tiggamit
  • DDOS
  • Cross website scripting
  • SQL injection
  • Pag-hijack sa sesyon
  • Ubang mga Panghulga

Sa mosunud nga panudlo, mahibal-an nimo kung giunsa ang pag-install sa ModSecurity 3 & OWASP Core Rule Set nga adunay Nginx sa Rocky Linux 9 nga adunay mga panig-ingnan nga mga pag-configure gikan sa pagsugod hangtod sa katapusan.

Pag-update sa Rocky Linux

Una, i-update ang imong sistema aron masiguro nga ang tanan nga naglungtad nga mga pakete bag-o.

sudo dnf upgrade --refresh

I-install ang Pinakabag-o nga Nginx Stable o Mainline

Sa kasagaran, mahimo nimong ipadayon ang imong kasamtangan nga bersyon sa Nginx nga naka-install kung makit-an nimo ang usa ka gipares nga gigikanan nga bersyon. Kung dili, girekomenda ang pag-instalar sa pinakabag-o nga stable o mainline nga pagtukod sa Nginx, tungod kay ang tutorial moagi sa ubos.

Kuhaa ang Naglungtad nga Pag-install sa Nginx

Hunonga ang kasamtangan nga serbisyo sa Nginx:

sudo systemctl stop nginx

Karon kuhaa ang kasamtangan nga pag-instalar sa Nginx sama sa mosunod:

sudo dnf remove nginx

Karon nga malampuson nimong natangtang ang daan nga bersyon sa Nginx, kung na-install nimo kini, aron ma-install ang panguna nga linya sa Nginx, kinahanglan nimo nga i-install una ang dependency alang niini, nga mao dnf-utilities uban sa mosunod nga sugo:

sudo dnf install dnf-utils -y

Sunod, i-import ang mga repository sa ubos.

I-import ang Nginx Mainline Repository

sudo tee /etc/yum.repos.d/nginx-mainline.repo<<EOF

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

EOF

Ang mga tiggamit nga adunay aarch nga arkitektura, ilisan sa sugo sa ibabaw baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/ uban sa baseurl=http://nginx.org/packages/mainline/centos/9/aarch64/.

Import Nginx Stable Repository

sudo tee /etc/yum.repos.d/nginx-stable.repo<<EOF

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

EOF

Ang mga tiggamit nga adunay aarch nga arkitektura, ilisan sa sugo sa ibabaw baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/ uban sa baseurl=http://nginx.org/packages/mainline/centos/9/aarch64/.

I-install ang Nginx

Sa kasagaran, ang pinakabag-o nga repository alang sa stable nga mga package sa Nginx gigamit una. Bisan pa, ang tutorial i-install Panguna nga linya sa Nginx, mao nga kinahanglan nimo nga ipadagan ang mosunud nga mando aron mahimo ang mainline repository sama sa mosunod:

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

Timan-i kung gusto nimo ang stable, ayaw gamita ang sugo sa ibabaw ug ipadayon ang sunod nga bahin sa tutorial.

Sunod, i-install ang Nginx mainline sama sa mosunod:

sudo dnf install nginx
Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

Sama sa ibabaw, ang tutorial nag-instalar sa Nginx pinakabag-o nga mainline nga bersyon diretso gikan sa Nginx.org. Timan-i nga makakita ka og pop-up nga nagpahibalo kanimo mahitungod sa pag-import sa GPG yawe sa panahon sa pag-instalar. Kini luwas nga buhaton ug gikinahanglan aron mahuman ang pag-install sa Nginx mainline nga malampuson.

Sa kasagaran, ang Nginx wala ma-enable ug gi-deactivate sa pag-instalar. Aron ma-aktibo ang imong serbisyo sa Nginx, gamita ang:

sudo systemctl start nginx

I-enable ang Nginx nga masugdan sa boot; gamita ang mosunod nga sugo:

sudo systemctl enable nginx

Opsyonal, pamatud-i ang imong bersyon sa Nginx. Sa among kaso, kini ang bersyon sa Nginx Mainline; gamita ang mosunod nga sugo.

nginx -v

I-configure ang FirewallD Alang sa Nginx

Kung dili nimo ilisan ang usa ka kasamtangan nga serbisyo sa Nginx ug i-install ang Nginx sa unang higayon, kinahanglan nimo nga i-configure ang firewall alang sa trapiko sa HTTP ug HTTPS. Ang usa ka pananglitan kung unsaon pagbuhat niini anaa sa ubos:

Tugoti ang trapiko sa HTTP nga gamiton ang mosunod nga sugo:

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

Tugoti ang trapiko sa HTTPS nga gamiton ang mosunod nga sugo:

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

Kung nahuman na, kinahanglan nimo nga himuon nga epektibo ang mga pagbag-o pinaagi sa pag-reload sa firewall:

sudo firewall-cmd --reload

Pag-download sa Nginx Source

Ang sunod nga lakang mao ang Karon, ug kinahanglan nimo nga i-download ang source code sa Nginx aron makolekta ang dinamikong module sa ModSecurity. Kinahanglan nimo nga i-download ug itago ang gigikanan nga pakete sa lokasyon sa direktoryo /etc/local/src/nginx.

Paghimo ug I-configure ang mga Direktoryo

Paghimo og lokasyon sama sa mosunod:

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

I-download ang Source Archive

Sunod, i-download ang Nginx source archive gikan sa pahina sa pag-download aron ipahiangay ang bersyon sa Nginx nga imong nahibal-an kaniadto. Bisan kung wala ka mag-update sa pinakabag-o nga bersyon sa stable o mainline nga Nginx ug mogamit usa ka mas karaan nga bersyon, kinahanglan nimo nga makapangita usa ka gigikanan nga mohaum sa imong kaugalingon.

Ang pahina sa pag-download sa Nginx mahimong nakit-an dinhi.

I-download ang tinubdan gamit ang wget sugo sa mosunod (pananglitan lang).

sudo wget http://nginx.org/download/nginx-1.23.1.tar.gz

Hinumdumi nga hinungdanon nga ang bersyon sa Nginx nga na-install motugma sa na-download nga archive, o kung dili ka adunay mga kapakyasan sa ulahi sa tutorial.

Sunod, kuhaa ang archive ingon sa mosunod.

sudo tar -xvzf nginx-1.23.1.tar.gz

Tinoa ang Bersyon sa Tinubdan

Sunod, ilista ang mga file sa direktoryo gamit ang ls sugo ingon sa mga sumusunod.

ls

Pananglitan nga output sa imong /usr/src/local/nginx directory.

[joshua@rocky-linux-9 nginx]$ ls
nginx-1.23.1  nginx-1.23.1.tar.gz

Sunod, kumpirmahi nga ang gigikanan nga pakete parehas sa imong bersyon sa Nginx nga na-install sa imong sistema, sama sa nahisgutan sa sayo pa.

I-install ang libmodsecurity3 para sa ModSecurity

Ang pakete libmodsecurity3 mao ang sukaranan nga bahin sa WAF nga naghimo sa Pagsala sa HTTP alang sa imong mga aplikasyon sa web. Imong i-compile kini gikan sa tinubdan.

Clone ModSecurity Repository gikan sa Github

Ang una nga lakang mao ang clone gikan sa Github, ug kung wala nimo na-install ang git, kinahanglan nimo nga ipatuman ang mosunud nga mando:

sudo dnf install git -y

Sunod, i-clone ang libmodsecurity3 GIT repository sama sa mosunod.

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

Sa higayon nga ma-clone, kinahanglan nimo CD ngadto sa direktoryo.

cd /usr/local/src/ModSecurity/

I-install ang libmodsecurity3 Dependencies

Sa dili ka pa mag-compile, kinahanglan nimo nga i-install ang mga mosunud nga dependency sama sa mosunod.

Ang unang tahas mao ang pag-instalar sa EPEL repository, ug ang rekomendasyon mao ang pag-instalar sa duha ka repository.

Una, i-enable ang CRB repository.

sudo dnf config-manager --set-enabled crb

Sunod, pag-instalar EPEL gamit ang mosunod (dnf) terminal nga sugo.

sudo dnf install \
    https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm \
    https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

Sunod, padagana ang mosunod nga sugo aron i-install ang mga pakete nga gikinahanglan sa Modsecurity. Kini kinahanglan nga maglakip sa kadaghanan sa mga kapilian ug mga bahin nga imong magamit sa Modsecurity ug ang kinauyokan nga lagda nga gitakda.

sudo dnf install doxygen yajl-devel gcc-c++ flex bison yajl curl-devel zlib-devel pcre-devel autoconf automake git curl make libxml2-devel pcre-static pkgconfig libtool httpd-devel redhat-rpm-config wget curl openssl openssl-devel geos geos-devel geocode-glib-devel geolite2-city geolite2-country nano -y

I-install ang GeoIP, kinahanglan una nimo nga i-import ang Remi repository.

sudo dnf install dnf-utils http://rpms.remirepo.net/enterprise/remi-release-9.rpm -y

Karon i-install ang GeoIP-devel gamit ang mosunod nga sugo.

sudo dnf --enablerepo=remi install GeoIP-devel -y

Karon aron mahuman, i-install ang mosunod nga mga submodules sa GIT sama sa mosunod.

sudo git submodule init

Dayon i-update ang mga submodules:

sudo git submodule update

Pagtukod sa ModSecurity Environment

Ang sunod nga lakang mao ang pagtukod una sa palibot. Gamita ang mosunod nga sugo:

sudo ./build.sh

Sunod, pagdagan ang configure command.

sudo ./configure

Timan-i nga posibleng makita nimo ang mosunod nga sayop.

fatal: No names found, cannot describe anything.

Mahimo nimo kini luwas nga ibaliwala ug magpadayon sa sunod nga lakang.

Pag-compile sa ModSecurity Source Code

Karon nga imong gitukod ug gi-configure ang palibot alang sa libmodsecurity3, panahon na nga i-compile kini gamit ang command sa paghimo sa.

sudo make

Ang usa ka dali nga limbong mao ang pagtino sa -j tungod kay kini makadugang sa katulin sa pag-compile kung ikaw adunay kusgan nga server.

Pananglitan, ang server adunay 6 nga mga CPU, ug magamit nako ang tanan nga 6 o labing menos 4 hangtod 5 aron madugangan ang katulin.

sudo make -j 6

Human sa pag-compile sa source code, karon padagana ang installation command sa imong terminal:

sudo make install

Timan-i nga ang pag-instalar gihimo sa /usr/local/modsecurity/, nga imong hisgotan unya.

I-install ang ModSecurity-nginx Connector

ang ModSecurity-nginx connector mao ang punto sa koneksyon tali sa nginx ug libmodsecurity. Kini ang sangkap nga nakigsulti tali sa Nginx ug ModSecurity (libmodsecurity3).

Clone ModSecurity-nginx Repository gikan sa Github

Sama sa miaging lakang nga pag-clone sa libmodsecurity3 repository, kinahanglan nimo nga i-clone pag-usab ang connector repository gamit ang mosunod nga command:

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

I-install ang ModSecurity-nginx Dependencies

Sunod, navigate sa Nginx source directory; hinumdomi nga ang panig-ingnan sa ubos lahi sa imong bersyon; kini usa lamang ka pananglitan.

Panig-ingnan:

cd /usr/local/src/nginx/nginx-1.23.1/

Sunod, imong i-compile ang ModSecurity-nginx Connector module lamang uban sa -Sa-compat bandila ingon sa mosunod:

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

Pananglitan nga output kung ang tanan nagtrabaho sa husto hangtod karon:

Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

karon sa paghimo sa (paghimo) sa dinamikong mga module nga adunay mosunod nga sugo:

sudo make modules

Pananglitan nga output:

Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

Sunod, samtang naa sa direktoryo sa gigikanan sa Nginx, gamita ang mosunud nga mando aron ibalhin ang dinamikong module nga imong gihimo nga na-save sa lokasyon objs/ngx_http_modsecurity_module.so ug kopyaha kini sa /usr/share/nginx/modules directory.

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

Mahimo nimong tipigan ang dinamikong module bisan asa kung imong itakda ang tibuuk nga agianan kung nagkarga.

Alang sa mga tiggamit nga nag-install sa Nginx mainline o stable, ang lokasyon mao ang mosunod.

sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

I-load ug I-configure ang ModSecurity-nginx Connector sa Nginx

Karon nga imong gihugpong ang dinamikong module ug nahimutang kini sumala niana, kinahanglan nimo nga i-edit ang imong /etc/nginx/nginx.conf configuration file aron ma-operate ang ModSecurity sa imong Nginx webserver.

I-enable ang ModSecurity sa nginx.conf

Una, kinahanglan nimo nga itakda load_module ug dalan sa imong modsecurity module.

Ablihi nginx.conf uban sa bisan unsang text editor. Alang sa tutorial, ang nano gamiton:

sudo nano /etc/nginx/nginx.conf

Sunod, idugang ang mosunod nga linya sa file duol sa ibabaw:

load_module modules/ngx_http_modsecurity_module.so;

Kung nakit-an nimo ang module sa ubang lugar, iapil ang tibuuk nga agianan.

Karon idugang ang mosunod nga code ubos sa HTTP {} seksyon sama sa mosunod:

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

Panig-ingnan:

Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

Kung nakit-an nimo ang module sa ubang lugar, iapil ang tibuuk nga agianan.

I-save ang file (CTRL+O), unya exit (CTRL+X).

Paghimo ug I-configure ang Direktoryo ug mga File para sa ModSecurity

Alang sa panudlo, kinahanglan nimo nga maghimo usa ka direktoryo aron tipigan ang mga file sa pag-configure ug mga lagda sa umaabot, OWASP CRS.

Gamita ang mosunod nga sugo sa paghimo sa /etc/nginx/modsec directory.

sudo mkdir /etc/nginx/modsec/

Kinahanglan nimong kopyahon ang sample nga ModSecurity configuration file gikan sa among cloned GIT directory.

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

Gamit ang imong paboritong text editor, ablihi ang modsecurity.conf file sama sa mosunod.

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

Sa kasagaran, ang ModSecurity configuration adunay rule engine nga gipiho nga (DetectionOnly), nga sa laing pagkasulti, nagpadagan sa ModSecurity ug nakamatikod sa tanan nga malisyoso nga pamatasan apan dili aksyon nga mga bloke o pagdili ug pag-log sa tanan nga mga transaksyon sa HTTP nga gibandera niini. Kini kinahanglan nga gamiton lamang kung ikaw adunay daghang mga sayop nga positibo o gipataas ang mga setting sa lebel sa seguridad sa usa ka grabe nga lebel ug pagsulay aron makita kung adunay bisan unsang sayup nga mga positibo nga nahitabo.

Sa configuration file, usba kini nga kinaiya ngadto sa (sa), makita sa linya 7.

SecRuleEngine DetectionOnly

Usba ang linya niini aron mahimo ang ModSecurity:

SecRuleEngine On

Panig-ingnan:

Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

Karon, kinahanglan nimo nga pangitaon ang mosunod SecAuditLogParts, nga nahimutang sa linya 224.

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Dili kini husto ug kinahanglan nga usbon. Usba ang linya sa mosunod:

SecAuditLogParts ABCEFHJKZ

Karon i-save ang gamit ang file (CTRL+O), unya exit (CTRL+X).

Ang sunod nga bahin mao ang paghimo sa mosunod nga file modsec-config.conf. Dinhi imong idugang ang modsecurity.conf file uban ug sa ulahi sa ubang mga lagda sama sa OWASP CRS, ug kon ikaw naggamit sa WordPress, ang WPRS CRS set sa lagda.

Gamita ang mosunod nga sugo sa paghimo sa file ug pag-abli niini.

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

Sa higayon nga sa sulod sa file, idugang ang mosunod nga linya.

include /etc/nginx/modsec/modsecurity.conf

I-save ang modsec-config.conf file gamit ang (CTRL+O), unya (CTRL+X) paggawas.

Katapusan, kopyaha ang ModSecurity's unicode.mapping file uban sa CP nga sugo ingon sa mga sumusunod.

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

Sa dili pa magpadayon, kinahanglan nimo nga hatagan ang imong serbisyo sa Nginx nga usa ka dry run gamit ang mosunod nga terminal command.

sudo nginx -t

Kung imong gipahimutang ang tanan sa husto, kinahanglan nimo nga makuha ang mosunod nga output:

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

Aron mabuhi ang mga pagbag-o, i-restart ang imong serbisyo sa Nginx gamit ang systemctl command:

sudo systemctl restart nginx

I-install ang OWASP Core Rule Set para sa ModSecurity

Ang ModSecurity sa iyang kaugalingon dili manalipod sa imong web server, ug kinahanglan nimo nga adunay mga lagda. Usa sa labing inila, respetado, ug ilado nga mga lagda mao ang OWASP CRS rule set. Ang mga lagda mao ang labing kaylap nga gigamit taliwala sa mga web server ug uban pang mga WAF, ug kadaghanan sa ubang parehas nga mga sistema nagbase sa kadaghanan sa ilang mga lagda niini nga CRS. Ang pag-instalar niini nga ruleset awtomatik nga maghatag kanimo ug dakong tinubdan sa panalipod batok sa kadaghanan sa mga mitumaw nga hulga sa Internet pinaagi sa pag-ila sa mga malisyosong aktor ug pagbabag kanila.

Susiha ang mga OWASP Release tag panid aron makita kung unsa ang pinakabag-o, tungod kay ang panig-ingnan sa ubos mahimong nausab sa umaabot.

Una, pag-navigate balik sa imong modsec directory nga gibuhat.

cd /etc/nginx/modsec

sa paggamit sa mga wget nga sugo, i-download ang OWASP CRS 3.3.2 archive, nga niining petsa ang pinakabag-o nga stable, apan hinumdomi upat ka adlaw ang milabay, ang pre-release nga bersyon nahulog, mao nga ang akong tambag mao ang pagsusi sa link sa pipila ka mga linya sa ibabaw aron makita kung unsa ang hitsura sa mga pagpagawas alang sa core ruleset.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.zip

Mahimo nimo i-download ang matag gabii nga pagtukod alang niadtong gusto nga magpuyo sa daplin. Gamita lang ang matag gabii kung andam ka nga magpadayon sa pag-compile ug pagsusi sa CoreRuleSet Github kanunay alang sa mga update ug mas masaligon sa pag-ila sa mga isyu. Sa teknikal nga paagi ang gabii mahimong mas luwas apan posibleng makamugna og mga problema.

Para sa mga bag-ong tiggamit, gamita ang stable nga bersyon ug ayaw gamita ang ubos nga bersyon.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.zip

Sa panahon sa paghimo sa tutorial, ang v4.0.0-RC1 pre-release anaa usab, sama sa gihisgutan sa sayo pa.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.0.0-rc1.zip

-instalar sa mga Unzip package kung wala nimo kini na-install sa imong server.

sudo dnf install unzip -y

Karon unzip ang archive, ug ang tutorial mag-install sa RC nga kandidato tungod kay kini duol sa pinakabag-o nga bersyon nga posible nga dili gamiton ang matag gabii, nga mahimong problema gawas kung ikaw nakasinati sa mga lagda sa OWASP ug Modsecurity. Dayon girekomendar nako ang paggamit niana nga bersyon alang sa pinakabag-o nga mga lagda sa seguridad.

sudo unzip v4.0.0-rc1 -d /etc/nginx/modsec

Girekomendar nako ang pagtipig sa mga bersyon sa OWASP rule sets tungod kay maka-download ka ug daghan ug, sa umaabot, dali nga usbon kini sa imong modsecurity.conf aron makita kung unsang ruleset ang labing maayo nga walay mga isyu, sama sa pagsulay tali sa mga releases nga kandidato ug kada gabii o stable ug buhian ang kandidato.

Sama sa kaniadto, sama sa modsecurity.conf sample nga configuration, ang OWASP CRS adunay usa ka sample configuration file nga kinahanglan nimong ilisan. Labing maayo nga gamiton ang CP command ug magtipig og backup alang sa umaabot kung kinahanglan nimo nga i-restart pag-usab.

sudo cp /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf.example /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf

Aron mahimo ang mga lagda, ablihi ang /etc/nginx/modsec/modsec-config.conf.

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

Sa higayon nga sulod sa file pag-usab, idugang ang mosunod nga duha ka dugang nga mga linya:

include /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf
include /etc/nginx/modsec/coreruleset-4.0.0-rc1/rules/*.conf

Panig-ingnan:

Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

I-save ang file (Ctrl + O) ug exit (CTRL+T).

Hinumdumi, sama sa gipatin-aw sa sayo pa, mahimo nimo nga teknikal nga mag-download sa daghang mga bersyon, usbon kini nga file, ug ayaw kalimti ang pagkopya ug pag-whitelist nga imong buhaton, ang hinungdanon nga bahin bahin sa whitelist mao nga kini kasagaran nga bahin.

Sama sa kaniadto, kinahanglan nimo nga sulayan ang bisan unsang bag-ong mga pagdugang sa imong serbisyo sa Nginx sa wala pa kini mabuhi.

sudo nginx -t

Human sa pagpadagan sa dry-run test, kinahanglan nimo nga makuha ang mosunod nga output nga nagpasabot nga ang tanan nagtrabaho sa husto:

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

I-restart ang imong serbisyo sa Nginx aron mahimo ang mga pagbag-o nga buhi sama sa mosunod:

sudo systemctl restart nginx

Paggamit ug Pagsabot sa OWASP Core Rule Set

Ang OWASP CRS adunay daghang mga kapilian, ang mga default nga setting, bisan pa, sa gawas sa kahon, mapanalipdan ang kadaghanan sa mga server dayon nga dili masakitan ang imong tinuud nga mga bisita ug maayo nga mga bot sa SEO. Sa ubos, pipila ka mga lugar ang hisgotan aron makatabang sa pagpatin-aw. Ang dugang nga pagbasa labing maayo nga imbestigahan ang tanan nga mga kapilian sa mga file sa pag-configure sa ilang kaugalingon tungod kay sila adunay gamay nga datos sa teksto nga ipatin-aw.

Ablihi ang imong CRS-setup.conf File.

sudo nano /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf

Timan-i nga kini ang configuration sa bersyon sa dev nga adunay dugang nga mga butang kumpara sa bersyon 3.3.

Gikan dinhi, mahimo nimong usbon ang kadaghanan sa imong mga setting sa OWASP CRS.

Pagmarka sa OWASP CRS

Aron mabungkag kini, ang ModSecurity adunay duha ka mga paagi:

Anomaliya nga Pagmarka Mode

# -- [[ 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.

Self-Contained nga Mode

# -- [[ 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.

Ang Anomaly Scoring sa kasagaran, alang sa kadaghanan sa mga tiggamit, ang pinakamaayong paagi nga gamiton.

Adunay upat ka lebel sa paranoia:

  • Paranoia Level 1 – Default nga lebel ug girekomenda alang sa kadaghanan sa mga tiggamit.
  • Paranoia Level 2 – Mga advanced user ra.
  • Paranoia Level 3 – Mga eksperto nga tiggamit lamang.
  • Paranoia Level 4 – Dili girekomenda sa tanan, gawas sa talagsaon nga mga kahimtang.
# -- [[ 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.

Sulayi ang OWASP CRS sa imong Server

Aron masulayan kung ang OWASP CRS nagtrabaho sa imong server, ablihi ang imong Internet Browser ug gamita ang mosunod:

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

Kinahanglan nimo madawat a 403 gidili nga sayop. Kung dili, nan usa ka lakang ang nawala.

Panig-ingnan:

Giunsa ang Pag-install sa ModSecurity 3 + OWASP sa Nginx sa Rocky Linux 9

Ang labing komon nga problema mao ang pagbag-o Detection Lamang sa On, ingon nga gitabonan sa sayo pa sa tutorial.

Pag-atubang sa Sayop nga Positibo ug Pasadya nga mga Lagda nga Wala'y Paglakip

Usa sa kanunay nga wala’y katapusan nga mga buluhaton mao ang pag-atubang sa mga sayup nga positibo, ModSecurity ug OWASP CRS ang usa ka maayo nga trabaho nga magkauban, apan kini moabut sa gasto sa imong oras, apan gihatagan ang proteksyon nga imong makuha, takus kini. Alang sa pagsugod, ang dili pagpataas sa lebel sa paranoia mao ang bulawan nga lagda.

Ang usa ka maayong lagda sa kumagko mao ang pagpadagan sa lagda nga gitakda sulod sa pipila ka semana ngadto sa mga bulan nga halos walay sayop nga mga positibo, unya dugangi, pananglitan, paranoia nga lebel 1 ngadto sa paranoia nga lebel 2, aron dili ka mapuno sa usa ka tonelada nga dungan.

Wala'y labot ang mga False Positive nga nailhan nga mga Aplikasyon

Ang Modsecurity, pinaagi sa default, mahimong mag-whitelist sa adlaw-adlaw nga mga aksyon nga mosangpot sa sayop nga mga positibo sama sa ubos:

#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"

Aron mahimo, pananglitan, WordPress, phpBB, ug phpMyAdmin samtang imong gigamit ang tanan nga tulo, uncomment sa mga linya ug biyaan ang (1) numero intact, usba ang ubang mga serbisyo nga wala nimo gigamit, pananglitan, Xenforo sa (0) tungod kay dili nimo gusto nga i-whitelist kini nga mga lagda.

Pananglitan sa ubos:

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"

Mahimo usab nimo usbon ang syntax, nga mas limpyo. Pananglitan:

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"

Sama sa imong nakita, gikuha ang mga kapilian nga dili kinahanglan ug idugang (") sa katapusan sa WordPress alang sa husto nga syntax.

Wala'y labot ang mga Lagda sa wala pa ang CRS

Aron maatubang ang mga kostumbre nga wala’y labot, una, kinahanglan nimo nga usbon ang ngalan gikan sa PANGAYO-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf file uban sa sugo sa cp ingon sa mosunod:

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

Hinumdumi sa paghimo sa mga lagda sa pagpahigawas, ang matag usa kinahanglan adunay id: ug mahimong talagsaon, o kung imong gisulayan ang imong serbisyo sa Nginx, makakuha ka usa ka sayup.

Panig-ingnan “id:1544,phase:1,log,allow,ctl:ruleEngine=off”, ang id 1544 dili magamit para sa ikaduhang lagda.

Pananglitan, pipila ka REQUEST_URI's magpatunghag sayop nga mga positibo. Ang pananglitan sa ubos mao ang duha nga adunay Google pagespeed beacon ug WMUDEV plugin alang sa 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"

Sama sa imong makita, ang bisan unsang URL nga nagsugod sa agianan awtomatik nga tugutan.

Ang laing kapilian mao ang pag-whitelist sa mga IP address; pipila ka mga paagi nga mahimo nimong buhaton bahin niini:

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"

ang @ipMatch mahimong magamit nga mas kaylap para sa mga subnet. Kung gusto nimo ipanghimakak ang usa ka subnet o pagbag-o sa IP address, tugoti ang pagdumili. Uban sa pipila ka kahibalo, mahimo ka usab nga maghimo mga blacklist ug whitelist ug i-configure kini gamit ang fail2ban. Ang mga posibilidad sa kasagaran walay katapusan.

Usa ka katapusan nga pananglitan mao ang pag-disable sa mga lagda lamang nga nag-aghat sa mga sayup nga positibo, dili ang habol nga pag-whitelist sa tibuuk nga agianan, sama sa imong nakita sa una nga REQUEST_URI nga pananglitan. Bisan pa, kini nagkinahanglag daghang oras ug pagsulay.

Pananglitan, kung gusto nimo tangtangon ang mga lagda 941000 ug 942999 gikan sa imo /admin/ nga lugar samtang nagpadayon kini nga nagpahinabog bakak nga mga pagdili ug mga bloke alang sa imong team, pangitaa sa imong modsecurity logs file ang lagda ID ug dayon i-disable ang ID nga adunay RemoveByID sama sa pananglitan sa ubos:

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

Ang mga pananglitan makita sa ModSecurity GIT wiki nga pahina.

WordPress WPRS Rule Set para sa ModSecurity

Laing kapilian alang sa WordPress ang mga tiggamit mao ang pag-instalar ug pagdagan tupad sa imong OWASP CRS rule set, usa ka ilado nga proyekto nga nag-ulohang WPRS rule set. Tungod kay kini opsyonal ug dili alang sa tanan, ang tutorial dili magtabon niini niini nga seksyon.

Bisan pa, kung gusto nimo i-install kini alang sa dugang nga proteksyon gamit ang WordPress sa imong server, palihug bisitaha ang among tutorial sa Pag-instalar sa WordPress ModSecurity Rule Set (WPRS).

Paghimo ModSecurity LogRotate File

Ang mga log sa ModSecurity mahimong motubo, mao nga kinahanglan nimo nga i-set up ang pag-rotate sa log tungod kay wala kini nahimo alang kanimo.

Una, paghimo ug ablihi ang imong ModSecurity rotate file modsec.

sudo nano /etc/logrotate.d/modsec

Idugang ang mosunod nga code:

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

Kini magtipig sa mga troso sulod sa 31 ka adlaw. Kung gusto nimo nga adunay gamay, usba ang 31 ngadto sa 7 ka adlaw, parehas nga kantidad sa mga log sa usa ka semana. Kinahanglan nga mag-rotate ka adlaw-adlaw para sa ModSecurity. Kung kinahanglan nimo nga repasohon ang mga file sa log nga adunay usa ka sinemana nga file mahimong usa ka katalagman nga susihon, kung unsa kini kadako.

Mga Komento ug Konklusyon

Sa kinatibuk-an, ang pag-deploy sa ModSecurity sa imong server maghatag dayon nga proteksyon. Bisan pa, ang pailub, oras, ug dedikasyon sa pagkat-on mahimong usa ka maayo nga bahin. Ang katapusan nga butang nga gusto nimo mao ang pag-block sa mga bot sa SEO o, labi ka hinungdanon, mga tinuud nga tiggamit nga mahimong potensyal nga kustomer.

Hinumdumi nga sulayan ug susihon ang mga troso ug ayaw ibutang ang lebel sa seguridad nga labi ka taas. Ingon ka dako sa kini nga software, mahimo nilang babagan ang lehitimong trapiko sa kadali ug, depende kung ang imong website usa ka gigikanan sa kita mahimong adunay makadaot nga mga sangputanan.



Sunda ang LinuxCapable.com!

Gusto nga makakuha og awtomatikong mga update? Sunda kami sa usa sa among mga social media account!