Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

ModSecurity-ն, որը հաճախ կոչվում է Modsec, անվճար, բաց կոդով վեբ հավելվածի firewall է (WAF): ModSecurity-ն ստեղծվել է որպես Apache HTTP սերվերի մոդուլ: Այնուամենայնիվ, իր վաղ օրերից ի վեր, WAF-ն աճել է և այժմ ընդգրկում է HyperText Transfer Protocol-ի հարցումների և պատասխանների զտման հնարավորությունների մի շարք տարբեր հարթակների համար, ինչպիսիք են Microsoft IIS-ը, Nginx-ը և Apache-ն: ModSecurity-ի առաջնային դերը վեբ հավելվածների համար պաշտպանություն ապահովելն է՝ մուտքային տրաֆիկի զտման և վնասակար հարցումների արգելափակման միջոցով: WAF-ը կարող է նաև կազմաձևվել, որպեսզի վերահսկի երթևեկությունը որոշակի տեսակի գործունեության համար, ինչպիսիք են SQL ներարկման հարձակումները, և ստեղծի ծանուցումներ, երբ այդպիսի ակտիվություն հայտնաբերվի: Ի հավելումն անվտանգության առավելությունների, ModSecurity-ն կարող է բարելավել վեբ կատարողականությունը՝ քեշավորելով կանոնները և վերացնելով նույն հարցումը բազմիցս մշակելու անհրաժեշտությունը:

Modsecurity-ի տեղադրման հետ մեկտեղ OWASP Core Rule Set-ը (CRS) սովորաբար օգտագործվում է համատեղ, որը բաց կոդով կանոնների հավաքածու է, որը գրված է ModSecurity-ի SecRules լեզվով: CRS-ը բարձր է գնահատվում անվտանգության ոլորտում, և ModSecurity-ն համարվում է վեբ հավելվածները հարձակումներից պաշտպանելու ամենաարդյունավետ միջոցներից մեկը: Թեև ModSecurity-ն արծաթափայլ չէ, այն կարևոր գործիք է ցանկացած կազմակերպության զինանոցում, որը լրջորեն է վերաբերվում վեբ անվտանգությանը:

OWASP կանոնների հավաքածուն ModSecurity-ով կարող է գրեթե ակնթարթորեն օգնել պաշտպանել ձեր սերվերը:

  • Վատ օգտագործող գործակալներ
  • DDoS- ը
  • Խաչաձև վեբ սկրիպտավորում
  • SQL ներարկումը
  • Նիստի առևանգում
  • Այլ սպառնալիքներ

Հետևյալ ձեռնարկում դուք կսովորեք, թե ինչպես տեղադրել ModSecurity 3 և OWASP Core Rule Set-ը Nginx-ով Rocky Linux 9-ի վրա՝ սկզբից մինչև վերջ օրինակ կազմաձևերով:

Բառը

Թարմացրեք Rocky Linux-ը

Նախ թարմացրեք ձեր համակարգը՝ համոզվելու համար, որ առկա բոլոր փաթեթները թարմացված են:

sudo dnf upgrade --refresh

Տեղադրեք վերջին Nginx Stable-ը կամ Mainline-ը

Լռելյայնորեն, դուք կարող եք տեղադրել Nginx-ի ձեր գոյություն ունեցող տարբերակը, եթե կարողանաք գտնել համապատասխան տարբերակի աղբյուր: Եթե ​​ոչ, ապա խորհուրդ է տրվում տեղադրել Nginx-ի կամ վերջին կայուն կամ հիմնական կառուցվածքը, քանի որ ձեռնարկը կանցնի ստորև:

Հեռացրեք գոյություն ունեցող Nginx տեղադրումը

Դադարեցրեք ընթացիկ Nginx ծառայությունը.

sudo systemctl stop nginx

Այժմ հեռացրեք գոյություն ունեցող Nginx տեղադրումը հետևյալ կերպ.

sudo dnf remove nginx

Այժմ, երբ դուք հաջողությամբ հեռացրեցիք Nginx-ի հին տարբերակը, եթե այն տեղադրված էիք, Nginx-ի հիմնական ցանցը տեղադրելու համար, նախ պետք է տեղադրեք դրա կախվածությունը, որը. dnf-կոմունալ ծառայություններ հետեւյալ հրամանով.

sudo dnf install dnf-utils -y

Հաջորդը, ներմուծեք ստորև բերված պահեստները:

Ներմուծեք Nginx հիմնական շտեմարան

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

Aarch ճարտարապետությամբ օգտվողները փոխարինեք վերը նշված հրամանով baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/ հետ baseurl=http://nginx.org/packages/mainline/centos/9/aarch64/.

Ներմուծում Nginx կայուն պահեստ

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

Aarch ճարտարապետությամբ օգտվողները փոխարինեք վերը նշված հրամանով baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/ հետ baseurl=http://nginx.org/packages/mainline/centos/9/aarch64/.

Տեղադրեք Nginx-ը

Լռելյայնորեն, սկզբում օգտագործվում է կայուն Nginx փաթեթների վերջին պահոցը: Այնուամենայնիվ, ձեռնարկը կտեղադրվի Nginx հիմնական, այնպես որ դուք պետք է գործարկեք հետևյալ հրամանը՝ հիմնական շտեմարանն ակտիվացնելու համար հետևյալ կերպ.

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

Ուշադրություն դարձրեք, եթե նախընտրում եք կայուն, մի օգտագործեք վերը նշված հրամանը և անցեք ձեռնարկի հաջորդ մասին:

Հաջորդը, տեղադրեք Nginx mainline-ը հետևյալ կերպ.

sudo dnf install nginx
Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Ինչպես վերևում, ձեռնարկը տեղադրում է Nginx-ի վերջին հիմնական տարբերակը անմիջապես Nginx.org-ից: Նկատի ունեցեք, որ դուք կտեսնեք թռուցիկ, որը ծանուցում է ձեզ ներմուծման մասին GPG ստեղնը տեղադրման ժամանակ: Սա անվտանգ է անել և պահանջվում է Nginx mainline-ի տեղադրումը հաջողությամբ ավարտելու համար:

Լռելյայնորեն, Nginx-ը միացված չէ և ապաակտիվացված է տեղադրման ժամանակ: Ձեր Nginx ծառայությունն ակտիվացնելու համար օգտագործեք՝

sudo systemctl start nginx

Միացնել Nginx-ը գործարկելու համար; օգտագործեք հետևյալ հրամանը.

sudo systemctl enable nginx

Ընտրովի, ստուգեք Nginx-ի ձեր տարբերակը: Մեր դեպքում դա Nginx Mainline տարբերակն է. օգտագործեք հետևյալ հրամանը.

nginx -v

Կարգավորեք FirewallD-ը Nginx-ի համար

Եթե ​​դուք չեք փոխարինում գոյություն ունեցող Nginx ծառայությունը և առաջին անգամ չեք տեղադրում Nginx-ը, գուցե հարկ լինի կարգավորել firewall-ը HTTP և HTTPS տրաֆիկի համար: Օրինակ, թե ինչպես դա անել, ստորև.

Թույլատրել HTTP տրաֆիկը օգտագործել հետևյալ հրամանը.

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

Թույլատրել HTTPS տրաֆիկը օգտագործել հետևյալ հրամանը.

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

Ավարտելուց հետո անհրաժեշտ է փոփոխություններն արդյունավետ դարձնել՝ վերաբեռնելով firewall-ը.

sudo firewall-cmd --reload

Ներբեռնեք Nginx աղբյուրը

Հաջորդ քայլը հիմա է, և դուք պետք է ներբեռնեք Nginx աղբյուրի կոդը՝ ModSecurity դինամիկ մոդուլը կազմելու համար: Դուք պետք է ներբեռնեք և պահեք աղբյուրի փաթեթը գրացուցակի վայրում /etc/local/src/nginx.

Ստեղծեք և կազմաձևեք դիրեկտորիաներ

Ստեղծեք գտնվելու վայրը հետևյալ կերպ.

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

Ներբեռնեք Աղբյուրի արխիվը

Հաջորդը, ներբեռնեք Nginx աղբյուրի արխիվը ներբեռնումների էջից, որպեսզի համապատասխանի Nginx տարբերակին, որը դուք նույնացրել եք ավելի վաղ: Նույնիսկ եթե դուք չեք թարմացրել կայուն կամ հիմնական Nginx-ի վերջին տարբերակին և օգտագործել ավելի հին տարբերակ, դուք պետք է կարողանաք գտնել աղբյուր, որը կհամապատասխանի ձեր աղբյուրին:

Nginx ներբեռնումների էջը կարող է լինել ծանոթանալ այստեղ:

Ներբեռնեք աղբյուրը՝ օգտագործելով wget հրահանգել հետևյալ կերպ (միայն օրինակ).

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

Հիշեք, որ կարևոր է, որ Nginx-ի տեղադրված տարբերակը համընկնի ներբեռնված արխիվի հետ, հակառակ դեպքում դուք ձախողումներ կունենաք հետագա ձեռնարկում:

Հաջորդը, հանեք արխիվը հետևյալ կերպ.

sudo tar -xvzf nginx-1.23.1.tar.gz

Ստուգեք աղբյուրի տարբերակը

Հաջորդը, ցուցակագրեք դիրեկտորիաների ֆայլերը ls հրամանը Ինչպես նշված է հետեւյալում.

ls

Օրինակ ելք ձեր /usr/src/local/nginx Հայաստան.

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

Հաջորդը, հաստատեք, որ սկզբնական փաթեթը նույնն է, ինչ ձեր համակարգում տեղադրված Nginx տարբերակը, ինչպես նշվեց ավելի վաղ:

Տեղադրեք libmodsecurity3-ը ModSecurity-ի համար

Փաթեթ libmodsecurity3 WAF-ի հիմնարար մասն է, որն անում է HTTP զտում ձեր վեբ հավելվածների համար: Դուք այն կկազմեք սկզբնաղբյուրից։

Կլոնավորեք ModSecurity պահոցը Github-ից

Առաջին քայլը Github-ի կլոնն է, և եթե դուք չունեք տեղադրված git, ապա ձեզ հարկավոր է կատարել հետևյալ հրամանը.

sudo dnf install git -y

Հաջորդը, կլոնավորեք libmodsecurity3 GIT պահեստը հետևյալ կերպ.

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

Կլոնավորվելուց հետո ձեզ հարկավոր կլինի CD գրացուցակին:

cd /usr/local/src/ModSecurity/

Տեղադրեք libmodsecurity3 Dependencies

Նախքան կազմելը, ձեզ հարկավոր է տեղադրել հետևյալ կախվածությունները հետևյալ կերպ.

Առաջին խնդիրը EPEL պահեստի տեղադրումն է, իսկ առաջարկությունը՝ երկու պահեստների տեղադրումը:

Նախ, միացրեք CRB պահեստը:

sudo dnf config-manager --set-enabled crb

Հաջորդը, տեղադրել EPEL օգտագործելով հետևյալը (dnf) տերմինալի հրաման:

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

Հաջորդը, գործարկեք հետևյալ հրամանը՝ Modsecurity-ի պահանջվող փաթեթները տեղադրելու համար: Սա պետք է ընդգրկի ընտրանքների և հնարավորությունների մեծ մասը, որոնք դուք կարող եք օգտագործել Modsecurity-ի և հիմնական կանոնների հավաքածուի հետ:

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

Տեղադրեք GeoIP-ը, նախ պետք է ներմուծեք Remi պահեստը:

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

Այժմ տեղադրեք GeoIP-devel-ը՝ օգտագործելով հետևյալ հրամանը.

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

Այժմ ավարտելու համար տեղադրեք հետևյալ GIT ենթամոդուլները հետևյալ կերպ.

sudo git submodule init

Այնուհետև թարմացրեք ենթամոդուլները.

sudo git submodule update

ModSecurity միջավայրի ստեղծում

Հաջորդ քայլն այժմ իրականում նախ միջավայրի ստեղծումն է: Օգտագործեք հետևյալ հրամանը.

sudo ./build.sh

Հաջորդը, գործարկեք կազմաձևման հրամանը:

sudo ./configure

Նկատի ունեցեք, որ դուք հավանաբար կտեսնեք հետևյալ սխալը.

fatal: No names found, cannot describe anything.

Դուք կարող եք ապահով կերպով անտեսել սա և անցնել հաջորդ քայլին:

ModSecurity Source Code-ի կազմում

Այժմ, երբ դուք ստեղծել և կազմաձևել եք միջավայրը libmodsecurity3-ի համար, ժամանակն է այն կազմելու հրամանով անել.

sudo make

Հարմար հնարք է նշել քանի որ դա կարող է զգալիորեն մեծացնել կոմպիլյացիայի արագությունը, եթե դուք ունեք հզոր սերվեր:

Օրինակ, սերվերն ունի 6 պրոցեսոր, և ես կարող եմ օգտագործել բոլոր 6-ը կամ առնվազն 4-ից 5-ը արագությունը բարձրացնելու համար:

sudo make -j 6

Աղբյուրի կոդը կազմելուց հետո այժմ գործարկեք տեղադրման հրամանը ձեր տերմինալում.

sudo make install

Նշենք, որ տեղադրումը կատարվում է /usr/local/modsecurity/, որին կանդրադառնաք ավելի ուշ:

Տեղադրեք ModSecurity-nginx միակցիչը

The ModSecurity-nginx միակցիչ nginx-ի և libmodsecurity-ի միջև կապի կետն է: Դա այն բաղադրիչն է, որը հաղորդակցվում է Nginx-ի և ModSecurity-ի միջև (libmodsecurity3).

Կլոնավորեք ModSecurity-nginx պահոցը Github-ից

Libmodsecurity3 պահոցը կլոնավորելու նախորդ քայլի նման, դուք պետք է նորից կլոնավորեք միակցիչի պահոցը՝ օգտագործելով հետևյալ հրամանը.

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

Տեղադրեք ModSecurity-nginx Dependencies

Հաջորդը, նավարկեք Nginx աղբյուրի գրացուցակում; հիշեք, որ ստորև բերված օրինակը կտարբերվի ձեր տարբերակից. դա ընդամենը օրինակ է։

Example:

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

Հաջորդը, դուք կկազմեք ModSecurity-nginx միակցիչ մոդուլը միայն –Համաձայն դրոշը հետևյալ կերպ.

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

Ելքի օրինակ, եթե մինչ այժմ ամեն ինչ ճիշտ է աշխատել.

Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Հիմա անել (ստեղծեք) դինամիկ մոդուլները հետևյալ հրամանով.

sudo make modules

Ելքի օրինակ.

Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Հաջորդը, երբ գտնվում եք Nginx աղբյուրի գրացուցակում, օգտագործեք հետևյալ հրամանը՝ ձեր պատրաստած դինամիկ մոդուլը տեղափոխելու համար, որը պահվել է տեղում: objs/ngx_http_modsecurity_module.so և պատճենեք այն /usr/share/nginx/մոդուլներ Հայաստան.

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

Դուք կարող եք պահել դինամիկ մոդուլը ցանկացած վայրում, եթե բեռնելիս նշեք ամբողջական ուղին:

Օգտագործողների համար, ովքեր տեղադրել են Nginx հիմնական կամ կայուն, գտնվելու վայրը կլինի հետևյալը.

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

Բեռնել և կարգավորել ModSecurity-nginx միակցիչը Nginx-ով

Այժմ, երբ դուք կազմել եք դինամիկ մոդուլը և համապատասխանաբար տեղադրել այն, դուք պետք է խմբագրեք ձեր /etc/nginx/nginx.conf կազմաձևման ֆայլ, որպեսզի ModSecurity-ն աշխատի ձեր Nginx վեբսերվերի հետ:

Միացնել ModSecurity-ը nginx.conf-ում

Նախ, դուք պետք է նշեք load_module և ուղին դեպի ձեր modsecurity մոդուլը:

Բացել nginx.conf ցանկացած տեքստային խմբագրիչով: Ուսուցման համար նանո կօգտագործվի՝

sudo nano /etc/nginx/nginx.conf

Հաջորդը, վերևի մոտ գտնվող ֆայլին ավելացրեք հետևյալ տողը.

load_module modules/ngx_http_modsecurity_module.so;

Եթե ​​դուք տեղադրել եք մոդուլը այլ տեղ, ներառեք ամբողջական ուղին:

Այժմ ավելացրեք հետևյալ կոդը տակ HTTP {} բաժինը հետևյալ կերպ.

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

Example:

Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Եթե ​​դուք տեղադրել եք մոդուլը այլ տեղ, ներառեք ամբողջական ուղին:

Պահեք ֆայլը (CTRL + O), ապա ելք (CTRL+X).

Ստեղծեք և կազմաձևեք տեղեկատու և ֆայլեր ModSecurity-ի համար

Ուսուցման համար ձեզ հարկավոր է ստեղծել գրացուցակ՝ կոնֆիգուրացիայի ֆայլերը և ապագա կանոնները պահելու համար՝ OWASP CRS:

Ստեղծելու համար օգտագործեք հետևյալ հրամանը /etc/nginx/modsec Հայաստան.

sudo mkdir /etc/nginx/modsec/

Դուք պետք է պատճենեք օրինակելի ModSecurity կազմաձևման ֆայլը մեր կլոնավորված GIT գրացուցակից:

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

Օգտագործելով ձեր սիրելի տեքստային խմբագրիչը, բացեք modsecurity.conf ֆայլը հետևյալ կերպ.

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

Լռելյայնորեն, ModSecurity կոնֆիգուրացիան ունի կանոնների շարժիչը, որը նշված է որպես (Միայն հայտնաբերում), որն այլ կերպ ասած՝ գործարկում է ModSecurity-ը և հայտնաբերում է բոլոր վնասակար վարքագիծը, բայց չի արգելափակում կամ արգելում և գրանցում այն ​​բոլոր HTTP գործարքները, որոնք նշում է: Սա պետք է օգտագործվի միայն այն դեպքում, եթե դուք ունեք բազմաթիվ կեղծ պոզիտիվներ կամ բարձրացրել եք անվտանգության մակարդակի կարգավորումները ծայրահեղ մակարդակի և փորձարկում եք՝ տեսնելու, թե արդյոք որևէ կեղծ դրական արդյունք է տեղի ունենում:

Կազմաձևման ֆայլում փոխեք այս վարքագիծը (վրա), հայտնաբերվել է 7-րդ տողում։

SecRuleEngine DetectionOnly

ModSecurity-ն ակտիվացնելու համար փոխեք տողը սրա վրա.

SecRuleEngine On

Example:

Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Այժմ դուք պետք է գտնեք հետևյալը SecAuditLogParts, որը գտնվում է 224 տողում։

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Սա ճիշտ չէ և պետք է փոխվի: Փոփոխեք տողը հետևյալով.

SecAuditLogParts ABCEFHJKZ

Այժմ պահպանեք ֆայլ օգտագործելով (CTRL + O), ապա ելք (CTRL+X).

Հաջորդ մասը հետևյալ ֆայլի ստեղծումն է modsec-config.conf. Այստեղ դուք կավելացնեք modsecurity.conf ֆայլի հետ միասին և հետագայում այլ կանոնների վրա, ինչպիսիք են OWASP CRS, և եթե օգտագործում եք WordPress, ապա WPRS CRS կանոնների հավաքածու.

Ֆայլը ստեղծելու և բացելու համար օգտագործեք հետևյալ հրամանը:

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

Ֆայլը ներս մտնելուց հետո ավելացրեք հետևյալ տողը.

include /etc/nginx/modsec/modsecurity.conf

Պահպանեք modsec-config.conf ֆայլը (CTRL + O), ապա (CTRL+X) ելք

Ի վերջո, պատճենեք ModSecurity-ը unicode.mapping ֆայլի հետ CP հրաման Ինչպես նշված է հետեւյալում.

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

Նախքան առաջ շարժվելը, դուք պետք է ձեր Nginx ծառայությանը չոր գործարկեք հետևյալ տերմինալի հրամանով.

sudo nginx -t

Եթե ​​ամեն ինչ ճիշտ եք կարգավորել, ապա պետք է ստանաք հետևյալ արդյունքը.

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

Փոփոխությունները կենդանի դարձնելու համար վերագործարկեք ձեր Nginx ծառայությունը՝ օգտագործելով systemctl հրամանը.

sudo systemctl restart nginx

Տեղադրեք OWASP Core Rule Set-ը ModSecurity-ի համար

ModSecurity-ն ինքնուրույն չի պաշտպանում ձեր վեբ սերվերը, և դուք պետք է կանոններ ունենաք: Ամենահայտնի, հարգված և հայտնի կանոններից մեկը OWASP CRS կանոնների հավաքածուն է: Կանոնները ամենատարածվածն են վեբ սերվերների և այլ WAF-ների միջև, և նմանատիպ այլ համակարգերի մեծ մասը հիմնում են իրենց կանոնների մեծ մասը այս CRS-ի վրա: Այս կանոնների տեղադրումը ավտոմատ կերպով ձեզ մեծ պաշտպանության աղբյուր կտա համացանցում առաջացող սպառնալիքների մեծ մասի դեմ՝ հայտնաբերելով վնասակար դերակատարներին և արգելափակելով նրանց:

Ստուգել OWASP Թողարկման պիտակի էջ տեսնելու, թե որն է վերջինը, քանի որ ստորև բերված օրինակը կարող է փոխվել ապագայում:

Նախ, նավարկեք ձեր ստեղծած modsec գրացուցակը:

cd /etc/nginx/modsec

Օգտագործելով wget հրամանը, բեռնել OWASP CRS 3.3.2 արխիվ, որը այս ամսաթվի դրությամբ ամենավերջին կայուն է, բայց հիշեք, որ չորս օր առաջ, նախնական թողարկումը թողարկվել է, ուստի իմ խորհուրդն է ստուգել հղումը մի քանի տող վերևում, որպեսզի տեսնեք, թե ինչ տեսք ունեն թողարկումները հիմնական կանոնների համար:

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

Դուք կարող եք ներբեռնել գիշերային կառուցվածքը նրանց համար, ովքեր ցանկանում են ապրել ծայրամասում: Օգտագործեք գիշերը միայն այն դեպքում, եթե պատրաստ եք շարունակել նորից հավաքել և ստուգել CoreRuleSet Github-ը թարմացումների համար և ավելի վստահ լինել խնդիրները պարզելու հարցում: Տեխնիկապես գիշերը կարող է ավելի ապահով լինել, բայց կարող է խնդիրներ առաջացնել:

Սկսնակ օգտվողների համար օգտագործեք կայուն տարբերակը և մի օգտագործեք ստորև բերված տարբերակը:

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

Ուսուցման ստեղծման պահին հասանելի է նաև v4.0.0-RC1 նախնական թողարկումը, ինչպես նշվեց ավելի վաղ:

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

տեղադրել Unzip փաթեթը եթե դուք չունեք սա տեղադրված ձեր սերվերի վրա:

sudo dnf install unzip -y

Այժմ բացեք արխիվը, և ձեռնարկը կտեղադրի RC-ի թեկնածուն, քանի որ այն մոտ է հնարավոր ամենաթարմացված տարբերակին՝ առանց գիշերային ռեժիմի օգտագործման, ինչը կարող է խնդրահարույց լինել, եթե դուք փորձ չունեք OWASP կանոնների և Modsecurity-ի հետ: Հետո ես խորհուրդ եմ տալիս օգտագործել այդ տարբերակը անվտանգության վերջին կանոնների համար:

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

Ես խորհուրդ եմ տալիս պահպանել OWASP կանոնների հավաքածուների տարբերակները, քանի որ կարող եք ներբեռնել մի քանիսը և հետագայում արագ փոխել դրանք ձեր modsecurity.conf-ում, որպեսզի տեսնեք, թե որ կանոնների հավաքածուն է լավագույնս աշխատում առանց խնդիրների, օրինակ՝ թեստավորումը թողարկման թեկնածուի և գիշերային կամ կայունության միջև: և ազատ արձակել թեկնածուին։

Ինչ վերաբերում է նախկինում, ինչպես modsecurity.conf նմուշի կոնֆիգուրացիա, OWASP CRS-ը գալիս է նմուշի կազմաձևման ֆայլով, որը պետք է վերանվանեք: Լավագույնն այն է, որ օգտագործեք CP հրամանը և պահեք կրկնօրինակը ապագայի համար, եթե նորից վերագործարկեք:

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

Կանոնները միացնելու համար բացեք /etc/nginx/modsec/modsec-config.conf.

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

Ֆայլը կրկին ներս մտնելուց հետո ավելացրեք հետևյալ երկու լրացուցիչ տողերը.

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

Example:

Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Պահեք ֆայլը (CTRL+O) և ելք (CTRL+T).

Հիշեք, ինչպես բացատրվեց մի փոքր ավելի վաղ, դուք կարող եք տեխնիկապես ներբեռնել բազմաթիվ տարբերակներ, փոփոխել այս ֆայլը և մի մոռացեք պատճենել և տեղադրել սպիտակ ցուցակում, սպիտակ ցուցակի կարևոր մասն այն է, որ այն մեծ մասամբ ընդհանուր է:

Ինչպես նախկինում, դուք պետք է փորձարկեք ձեր Nginx ծառայության ցանկացած նոր հավելում, նախքան այն կենդանի դարձնելը:

sudo nginx -t

Չոր վազքի թեստը գործարկելուց հետո դուք պետք է ստանաք հետևյալ արդյունքը, ինչը նշանակում է, որ ամեն ինչ ճիշտ է աշխատում.

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

Վերագործարկեք ձեր Nginx ծառայությունը, որպեսզի փոփոխությունները կատարվեն հետևյալ կերպ.

sudo systemctl restart nginx

Օգտագործելով և հասկանալով OWASP-ի հիմնական կանոնների հավաքածուն

OWASP CRS-ն ունի բազմաթիվ տարբերակներ, լռելյայն կարգավորումները, այնուամենայնիվ, առանց տուփի, անմիջապես կպաշտպանեն սերվերների մեծ մասը՝ չվնասելով ձեր իրական այցելուներին և լավ SEO բոտերին: Ստորև կներկայացվեն որոշ ոլորտներ, որոնք կօգնեն բացատրել: Հետագա ընթերցումը լավագույնն է ուսումնասիրել բոլոր ընտրանքները կազմաձևման ֆայլերում, քանի որ դրանք բացատրելու բավականին տեքստային տվյալներ ունեն:

Բացեք ձեր CRS-setup.conf ֆայլը.

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

Նկատի ունեցեք, որ սա մշակողի տարբերակի կազմաձևումն է՝ լրացուցիչ տարրերով՝ համեմատած 3.3 տարբերակի հետ:

Այստեղից կարող եք փոփոխել ձեր OWASP CRS կարգավորումների մեծ մասը:

OWASP CRS միավորներ

Այն քանդելու համար ModSecurity-ն ունի երկու ռեժիմ.

Անոմալիա գնահատման ռեժիմ

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

Անոմալիաների գնահատումը, ընդհանուր առմամբ, օգտագործողների մեծամասնության համար օգտագործելու լավագույն ռեժիմն է:

Պարանոյայի չորս մակարդակ կա.

  • Պարանոյա Մակարդակ 1 – Կանխադրված մակարդակ և առաջարկվում է օգտվողների մեծամասնության համար:
  • Պարանոյա Մակարդակ 2 – Միայն առաջադեմ օգտվողներ:
  • Պարանոյա Մակարդակ 3 – Միայն փորձագետ օգտվողներ:
  • Պարանոյա Մակարդակ 4 – Ընդհանրապես խորհուրդ չի տրվում, բացառությամբ բացառիկ դեպքերի։
# -- [[ 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.

Փորձարկեք OWASP CRS-ը ձեր սերվերի վրա

Ստուգելու համար, թե արդյոք OWASP CRS-ն աշխատում է ձեր սերվերի վրա, բացեք ձեր ինտերնետային զննարկիչը և օգտագործեք հետևյալը.

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

Դուք պետք է ստանաք ա 403 արգելված սխալ. Եթե ​​ոչ, ուրեմն մի քայլ բաց է թողնվել։

Example:

Ինչպես տեղադրել ModSecurity 3 + OWASP-ը Nginx-ով Rocky Linux 9-ում

Ամենատարածված խնդիրը փոխվում է Միայն հայտնաբերում դեպի On, ինչպես ավելի վաղ նկարագրված է ձեռնարկում:

Գործ ունենալ կեղծ դրականների և սովորական կանոնների բացառման հետ

Հաճախ անվերջ խնդիրներից մեկը կեղծ պոզիտիվների հետ գործ ունենալն է, ModSecurity-ը և OWASP CRS-ը միասին հիանալի աշխատանք են կատարում, բայց դա գալիս է ձեր ժամանակի գնով, բայց հաշվի առնելով ձեր ստացած պաշտպանությունը, արժե այն: Սկզբի համար, երբեք պարանոյայի մակարդակը բարձր չդնելը ոսկե կանոն է:

Լավ ընդհանուր կանոնն այն է, որ սահմանված կանոնները գործարկվեն մի քանի շաբաթից մինչև ամիսներ գրեթե ոչ մի կեղծ դրական արդյունքով, այնուհետև, օրինակ, պարանոյայի մակարդակը 1-ին հասցնել պարանոյայի մակարդակի 2-ի, այնպես որ դուք միաժամանակ մի տոննայով չճահճվեք:

Բացառելով կեղծ դրական հայտնի հավելվածները

Modsecurity-ն, ըստ լռելյայն, կարող է սպիտակ ցուցակագրել ամենօրյա գործողությունները, որոնք հանգեցնում են ստորև բերված կեղծ դրական արդյունքների.

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

Միացնելու համար, օրինակ, WordPress, phpBB և phpMyAdmin քանի որ դուք օգտագործում եք բոլոր երեքը, հանել տողերը և թողնել (1) համարը անփոփոխ է, փոխեք մյուս ծառայությունները, որոնք դուք չեք օգտագործում, օրինակ՝ Xenforo-ին (0) քանի որ դուք չեք ցանկանում սպիտակ ցուցակում ներառել այս կանոնները:

Ստորև բերված օրինակ.

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"

Կարող եք նաև փոփոխել շարահյուսությունը, որն ավելի մաքուր կլինի: Օրինակ:

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"

Ինչպես տեսնում եք, հեռացվել են այն տարբերակները, որոնք անհրաժեշտ չեն և ավելացվել են («) WordPress-ի վերջում՝ ճիշտ շարահյուսության համար:

CRS-ից առաջ կանոնների բացառումը

Մաքսային բացառումներով զբաղվելու համար նախ պետք է անունը փոխել REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf ֆայլի հետ cp հրամանը Ինչպես նշված է հետեւյալում:

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

Հիշեք, որ բացառման կանոններ ստեղծելիս յուրաքանչյուրը պետք է ունենա ID. և եղեք եզակի, այլապես, երբ փորձարկեք ձեր Nginx ծառայությունը, սխալ կստանաք:

Օրինակ «id:1544,phase:1,log,allow,ctl:ruleEngine=off», id 1544-ը չի կարող օգտագործվել երկրորդ կանոնի համար։

Օրինակ, որոշ REQUEST_URI-ներ կբարձրացնեն կեղծ դրական արդյունքներ: Ստորև բերված օրինակը երկուսն է՝ Google pagespeed beacon-ով և WordPress-ի համար WMUDEV հավելվածով.

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"

Ինչպես տեսնում եք, ցանկացած URL, որը սկսվում է ուղուց, ավտոմատ կերպով կթույլատրվի:

Մեկ այլ տարբերակ IP հասցեների սպիտակ ցուցակում ներառելն է. մի քանի ուղիներ, որոնցով դուք կարող եք գնալ այս մասին.

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 կարող է ավելի լայնորեն օգտագործվել ենթացանցերի համար: Եթե ​​ցանկանում եք մերժել ենթացանցը կամ IP հասցեի փոփոխությունը, թույլ տվեք մերժել: Որոշակի նոու-հաուով կարող եք նաև ստեղծել սև և սպիտակ ցուցակներ և կարգավորել դա fail2ban-ի միջոցով: Հնարավորությունները հաճախ կարող են անսահման լինել:

Վերջին օրինակն այն է, որ անջատեք միայն այն կանոնները, որոնք առաջացնում են կեղծ դրական արդյունքներ, այլ ոչ թե ամբողջ ճանապարհի սպիտակ ցուցակում ներառելը, ինչպես տեսաք առաջին REQUEST_URI օրինակում: Այնուամենայնիվ, սա ավելի շատ ժամանակ և փորձարկում է պահանջում:

Օրինակ, եթե ցանկանում եք հեռացնել կանոնները 941000 և 942999 ձեր կողմից / ադմին / տարածքը, քանի որ այն շարունակում է ձեր թիմի համար կեղծ արգելքներ և արգելափակումներ առաջացնել, ձեր ռեժիմի անվտանգության տեղեկամատյաններում գտեք կանոնի ID-ն և անջատեք միայն այդ ID-ն RemoveByID ինչպես ստորև բերված օրինակը.

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

Օրինակներ կարելի է գտնել ModSecurity GIT-ում վիքի էջ.

WordPress WPRS կանոնների հավաքածու ModSecurity-ի համար

Մեկ այլ տարբերակ ` WordPress օգտվողները պետք է տեղադրեն և աշխատեն ձեր OWASP CRS կանոնների հավաքածուի հետ մեկտեղ, որը հայտնի նախագիծ է, որը կոչվում է WPRS կանոնների հավաքածու: Քանի որ սա ընտրովի է և ոչ բոլորի համար, ձեռնարկը չի ընդգրկի այն այս բաժնում:

Այնուամենայնիվ, եթե ցանկանում եք տեղադրել սա լրացուցիչ պաշտպանության համար՝ օգտագործելով WordPress-ը ձեր սերվերի վրա, այցելեք մեր ձեռնարկը WordPress ModSecurity կանոնների հավաքածուի (WPRS) տեղադրում.

Ստեղծեք ModSecurity LogRotate ֆայլ

ModSecurity-ի տեղեկամատյանները կարող են չափազանց մեծանալ, այնպես որ դուք պետք է կարգավորեք մատյանները պտտվող, քանի որ դա ձեզ համար չի արվում:

Նախ, ստեղծեք և բացեք ձեր ModSecurity պտտվող ֆայլը modsec.

sudo nano /etc/logrotate.d/modsec

Ավելացնել հետևյալ կոդը.

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

Սա կպահի տեղեկամատյանները 31 օր: Եթե ​​նախընտրում եք ավելի քիչ ունենալ, փոխեք 31-ից 7 օր, հավասարապես մեկ շաբաթվա տեղեկամատյանները: Դուք պետք է ամեն օր պտտվեք ModSecurity-ի համար: Եթե ​​Ձեզ անհրաժեշտ է վերանայել տեղեկամատյանների ֆայլերը, որոնք ունեն շաբաթական ֆայլ, աղետալի կլինի մաղել՝ հաշվի առնելով, թե որքան մեծ կլինի այն:

Մեկնաբանություններ և եզրակացություն

Ընդհանուր առմամբ, ModSecurity-ի տեղակայումը ձեր սերվերի վրա կապահովի ակնթարթային պաշտպանություն: Այնուամենայնիվ, համբերությունը, ժամանակը և նվիրվածությունը սովորելուն այդքան հիանալի հատկանիշ կլինեն: Վերջին բանը, որ ցանկանում եք, արգելափակել SEO բոտերին կամ, ավելի կարևոր է, իրական օգտվողներին, որոնք կարող են լինել պոտենցիալ հաճախորդներ:

Հիշեք, որ ստուգեք և ստուգեք տեղեկամատյանները և չսահմանեք անվտանգության մակարդակը չափազանց բարձր: Որքան էլ այս ծրագրերը հիանալի լինեն, դրանք կարող են շատ արագ արգելափակել օրինական երթևեկությունը, և կախված այն հանգամանքից, թե արդյոք ձեր կայքը եկամտի աղբյուր է, կարող է աղետալի արդյունքներ ունենալ:



Հետևեք LinuxCapable.com-ին:

Ձեզ դուր է գալիս ավտոմատ թարմացումներ ստանալ: Հետևեք մեզ մեր սոցիալական մեդիայի հաշիվներից մեկում: