วิธีการติดตั้ง ModSecurity 3 & OWASP Core Rule ที่ตั้งค่าด้วย Nginx บน Ubuntu 20.04


ModSecurity, บ่อยครั้ง เรียกว่า โมดเซค, เป็นไฟร์วอลล์เว็บแอปพลิเคชันโอเพ่นซอร์สฟรี (อปท.). ModSecurity ถูกสร้างขึ้นเป็นโมดูลสำหรับ Apache HTTP Server อย่างไรก็ตาม ตั้งแต่เริ่มแรก WAF ได้เติบโตขึ้น และตอนนี้ครอบคลุมอาร์เรย์ของคำขอ HyperText Transfer Protocol และความสามารถในการกรองการตอบสนองสำหรับแพลตฟอร์มต่างๆ เช่น Microsoft IIS, Nginx และแน่นอน Apache

วิธีการทำงานของ WAF เอ็นจิ้น ModSecurity ถูกปรับใช้ที่ด้านหน้าของเว็บแอปพลิเคชัน ทำให้เอ็นจิ้นสามารถสแกนการเชื่อมต่อ HTTP ขาเข้าและขาออกได้ ModSecurity มักใช้ร่วมกับ ชุดกฎหลัก OWASP (CRS)ซึ่งเป็นชุดกฎโอเพนซอร์สที่เขียนด้วยภาษา SecRules ของ ModSecurity และได้รับการยกย่องอย่างสูงในอุตสาหกรรมความปลอดภัย

ชุดกฎ OWASP พร้อม ModSecurity สามารถช่วยปกป้องเซิร์ฟเวอร์ของคุณจาก:

  • ตัวแทนผู้ใช้ที่ไม่ดี
  • DDOS
  • การเขียนสคริปต์ข้ามเว็บไซต์
  • การแทรก SQL
  • เซสชั่นการหักหลัง
  • ภัยคุกคามอื่น ๆ

ในบทช่วยสอนต่อไปนี้ คุณจะได้เรียนรู้ วิธีการติดตั้ง ModSecurity 3 & OWASP Core Rule Set ด้วย Nginx บน Ubuntu 20.04 LTS Focal Fossa

สารบัญ

เบื้องต้น

  • ระบบปฏิบัติการที่แนะนำ: อูบุนตู 20.04 หรือสูงกว่า
  • บัญชีผู้ใช้: บัญชีผู้ใช้งานกับ sudo or การเข้าถึงรูท

อัปเดตระบบปฏิบัติการ

อัปเดตของคุณ อูบุนตู ระบบปฏิบัติการเพื่อให้แน่ใจว่าแพ็คเกจที่มีอยู่ทั้งหมดเป็นปัจจุบัน:

sudo apt update && sudo apt upgrade -y

บทช่วยสอนจะใช้ the คำสั่ง sudo และ  สมมติว่าคุณมีสถานะ sudo.

วิธีตรวจสอบสถานะ sudo ในบัญชีของคุณ:

sudo whoami

ตัวอย่างผลลัพธ์ที่แสดงสถานะ sudo:

[joshua@ubuntu ~]$ sudo whoami
root

หากต้องการตั้งค่าบัญชี sudo ที่มีอยู่หรือใหม่ โปรดไปที่บทช่วยสอนของเราที่ วิธีเพิ่มผู้ใช้ใน Sudoers บน Ubuntu.

ในการใช้งาน บัญชีรูทให้ใช้คำสั่งต่อไปนี้ด้วยรหัสผ่าน root เพื่อเข้าสู่ระบบ

su

ติดตั้ง Nginx ล่าสุดบน Ubuntu 20.04

ขั้นแรก แนะนำให้ลบการติดตั้งที่มีอยู่ของ Nginx และติดตั้งเวอร์ชันล่าสุดโดยใช้ custom PPA ดูแลโดย ออนเดช ซูรีซึ่งยังมาพร้อมกับโมดูลไดนามิกพิเศษ เช่น โมดูล Brotli

ลบการติดตั้ง Nginx ที่มีอยู่

หยุดบริการ Nginx ปัจจุบัน:

sudo systemctl stop nginx

ตอนนี้ลบการติดตั้ง Nginx ที่มีอยู่ดังนี้:

sudo apt-get purge nginx -y && sudo apt autoremove nginx -y

เพิ่ม Nginx PPA . ล่าสุด

เมื่อคุณลบบริการ Nginx เก่าแล้ว ขอแนะนำให้ติดตั้ง PPA ตัวใดตัวหนึ่งตามรายการด้านล่าง

บทแนะนำจะแนะนำให้ติดตั้ง mainline ตามคำแนะนำของ Nginx เสมอ

ติดตั้งหนึ่งใน PPA ต่อไปนี้ด้วยคำสั่งต่อไปนี้:

ติดตั้ง Nginx ล่าสุด (STABLE):

sudo add-apt-repository ppa:ondrej/nginx-stable -y && sudo apt update

ติดตั้ง Nginx ล่าสุด (MAINLINE):

sudo add-apt-repository ppa:ondrej/nginx-mainline -y && sudo apt update

ตอนนี้คุณได้ติดตั้ง .แล้ว PPA และอัปเดตรายการที่เก็บ ติดตั้ง Nginx ด้วยสิ่งต่อไปนี้:

sudo apt install nginx-core nginx-common nginx nginx-full

โปรดทราบว่าคุณอาจได้รับแจ้งให้เก็บหรือแทนที่ .ที่มีอยู่ของคุณ / etc / nginx /nginx.conf ไฟล์การกำหนดค่าระหว่างการติดตั้ง ขอแนะนำให้เก็บไฟล์การกำหนดค่าปัจจุบันของคุณไว้โดยกด (n).

เพิ่มซอร์สโค้ด Nginx ไปยัง Repository

โดยค่าเริ่มต้น ซอร์สโค้ดจะไม่ถูกติดตั้งเมื่อทำการติดตั้ง PPA คุณจะต้องเปิดใช้งานสิ่งนี้ด้วยตนเองเพื่อดาวน์โหลดซอร์สโค้ด Nginx เพื่อคอมไพล์ Modsecurity ในภายหลังในบทช่วยสอน

ขั้นแรก เปิดไฟล์การกำหนดค่าใน /etc/apt/sources.list.d ด้วยนาโนดังต่อไปนี้:

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

ตอนนี้ให้วางบรรทัดที่ขึ้นต้นด้วย # deb-src และ ไม่แสดงความคิดเห็น (#) เส้น.

# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main

ตัวอย่างของสิ่งที่ควรมีลักษณะดังนี้:

วิธีการติดตั้ง ModSecurity 3 & OWASP Core Rule ที่ตั้งค่าด้วย Nginx บน Ubuntu 20.04

ตอนนี้บันทึกไฟล์ (CTRL+O) และออก (CTRL+X). ตอนนี้อัพเดตรายการที่เก็บโดยใช้คำสั่งต่อไปนี้:

sudo apt update

ดาวน์โหลด Nginx Source

คุณจะต้องดาวน์โหลดซอร์สโค้ด Nginx เพื่อคอมไพล์ ModSecurity โมดูลไดนามิก. ในการดำเนินการนี้ คุณจะต้องดาวน์โหลดและจัดเก็บแพ็คเกจต้นทางในตำแหน่งไดเรกทอรี /etc/local/src/nginx.

สร้างและกำหนดค่าไดเรกทอรี

สร้างสถานที่ดังนี้:

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

ไม่บังคับ – กำหนดสิทธิ์ให้กับไดเร็กทอรีหากจำเป็นดังนี้:

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

ติดตั้งการพึ่งพาและดำเนินการดาวน์โหลด

ถัดไป ดาวน์โหลดแพ็คเกจต้นทางดังต่อไปนี้:

sudo apt install dpkg-dev -y && sudo apt source nginx

หมายเหตุ คุณจะเห็นข้อความแสดงข้อผิดพลาดดังต่อไปนี้:

dpkg-source: info: extracting nginx in nginx-1.21.1
dpkg-source: info: unpacking nginx_1.21.1.orig.tar.gz
dpkg-source: info: unpacking nginx_1.21.1-1+ubuntu20.04.1+deb.sury.org+1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
dpkg-source: info: applying 0002-define_gnu_source-on-other-glibc-based-platforms.patch
W: Download is performed unsandboxed as root as file 'nginx_1.21.1.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

นี้สามารถละเว้นได้อย่างปลอดภัย

ตรวจสอบเวอร์ชันต้นทาง

ถัดไป แสดงรายการไฟล์ไดเร็กทอรีด้วย the ls คำสั่งดังต่อไปนี้:

ls

คุณควรเห็นผลลัพธ์ต่อไปนี้ใน your /usr/src/local/nginx ไดเรกทอรี:

jjames@ubuntu:/usr/local/src/nginx$ ls
nginx-1.21.1
nginx_1.21.1-1+ubuntu20.04.1+deb.sury.org+1.debian.tar.xz
nginx_1.21.1-1+ubuntu20.04.1+deb.sury.org+1.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc

ต่อไป ให้ยืนยันว่าแพ็คเกจต้นทางเหมือนกับรุ่น Nginx ของคุณที่ติดตั้งบนระบบปฏิบัติการ Ubuntu ของคุณ เมื่อต้องการทำเช่นนี้ ใช้สิ่งต่อไปนี้ nginx -v คำสั่งดังต่อไปนี้:

nginx -v

คุณควรได้รับเวอร์ชันเอาต์พุตเดียวกันกับแหล่งที่มาดังนี้:

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

ติดตั้ง libmodsecurity3 สำหรับ ModSecurity

แพคเกจ libmodsecurity3 เป็นส่วนที่แท้จริงของ WAF ที่ทำ การกรอง HTTP สำหรับเว็บแอปพลิเคชันของคุณ บน Ubuntu 20.04 คุณสามารถติดตั้งได้จากที่เก็บเริ่มต้นของ Ubuntu 20.04 อย่างไรก็ตาม ไม่แนะนำเช่นเดียวกับเวอร์ชัน LTS ส่วนใหญ่ และมักจะล่าช้า แต่คุณจะคอมไพล์จากแหล่งที่อัปเดตกว่าดังนี้

โคลน ModSecurity Repsoitory จาก Github

ขั้นตอนแรกคือการโคลนจาก Github และหากคุณไม่ได้ติดตั้ง git คุณจะต้องรันคำสั่งต่อไปนี้:

sudo apt install git -y

หมายเหตุ สิ่งนี้จะติดตั้งเวอร์ชันที่เก็บเริ่มต้นของ Ubuntu 20.04 หากคุณต้องการเวอร์ชันล่าสุดโดยใช้ PPA จากทีมพื้นที่เก็บข้อมูล GIT โปรดไปที่คำแนะนำในการติดตั้งและอัปเดตเวอร์ชันล่าสุด Git บน Ubuntu 20.04.

ถัดไป โคลนที่เก็บ libmodsecurity3 GIT ดังนี้:

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 การพึ่งพา

ในการคอมไพล์ คุณจะต้องติดตั้งการพึ่งพาดังต่อไปนี้:

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen -y

เพื่อปิดท้าย ให้ติดตั้งโมดูลย่อย GIT ดังต่อไปนี้:

git submodule init

จากนั้นอัปเดตโมดูลย่อย:

git submodule update

การสร้างสภาพแวดล้อม ModSecurity

ขั้นตอนต่อไปคือตอนนี้เพื่อสร้างสิ่งแวดล้อมก่อน ใช้คำสั่งต่อไปนี้:

./build.sh

จากนั้นรันคำสั่ง configuration:

./configure

หมายเหตุ คุณอาจเห็นข้อผิดพลาดต่อไปนี้

fatal: No names found, cannot describe anything.

คุณสามารถละเว้นสิ่งนี้ได้อย่างปลอดภัยและไปยังขั้นตอนถัดไป

การคอมไพล์ซอร์สโค้ด ModSecurity

เมื่อคุณได้สร้างและกำหนดค่าสภาพแวดล้อมสำหรับ libmodsecurity3 แล้ว ก็ถึงเวลาคอมไพล์ด้วยคำสั่ง ทำ.

make

เคล็ดลับที่มีประโยชน์คือการระบุ -NS เนื่องจากสิ่งนี้สามารถเพิ่มความเร็วในการคอมไพล์ได้อย่างมากหากคุณมีเซิร์ฟเวอร์ที่ทรงพลัง ตัวอย่างเช่น LinuxCapable เซิร์ฟเวอร์มี 6 CPU และฉันสามารถใช้ทั้ง 6 ตัวหรืออย่างน้อยก็ใช้ 4 ถึง 5 เพื่อเพิ่มความเร็ว

make -j 6

หลังจากรวบรวมซอร์สโค้ดแล้ว ให้รันคำสั่งการติดตั้งในเทอร์มินัลของคุณ:

sudo make install

หมายเหตุ การติดตั้งเสร็จสิ้นใน /usr/local/modsecurity/, ซึ่งคุณจะอ้างอิงในภายหลังในคู่มือนี้

ติดตั้ง ModSecurity-nginx Connector

พื้นที่ ตัวเชื่อมต่อ ModSecurity-nginx เป็นจุดเชื่อมต่อระหว่าง Nginx และ libmod ความปลอดภัย เป็นองค์ประกอบที่สื่อสารระหว่าง Nginx และ ModSecurity (libmodsecurity3).

โคลน ModSecurity-nginx Repsoitory จาก Github

คล้ายกับขั้นตอนก่อนหน้าในการโคลนที่เก็บ libmodsecurity3 คุณจะต้องโคลนที่เก็บตัวเชื่อมต่ออีกครั้งโดยใช้คำสั่งต่อไปนี้:

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

ติดตั้ง ModSecurity-nginx Dependencies

ถัดไป ไดเร็กทอรีซีดีลงในไดเร็กทอรีซอร์ส Nginx ดังนี้:

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

หมายเหตุ แทนที่เวอร์ชันของคู่มือด้วยเวอร์ชัน Nginx ปัจจุบันในระบบของคุณ

ตอนนี้ให้รันคำสั่งในเทอร์มินัล Ubuntu ของคุณเพื่อติดตั้งการพึ่งพาที่จำเป็น:

sudo apt build-dep nginx && sudo apt install uuid-dev -y

ต่อไปคุณจะรวบรวม ตัวเชื่อมต่อ ModSecurity-nginx โมดูลเฉพาะกับ เมื่อใช้-compat ธงดังต่อไปนี้:

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

ทำ (สร้าง) โมดูลไดนามิกด้วยคำสั่งต่อไปนี้:

sudo make modules

ถัดไป ในขณะที่อยู่ในไดเร็กทอรีต้นทาง Nginx ให้ใช้คำสั่งต่อไปนี้เพื่อย้ายโมดูลไดนามิกที่คุณเพิ่งสร้างขึ้นซึ่งถูกบันทึกไว้ที่ตำแหน่ง objs/ngx_http_modsecurity_module.so และคัดลอกไปที่ /usr/share/nginx/modules ไดเรกทอรี

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

คุณสามารถจัดเก็บโมดูลไดนามิกได้ทุกที่ ตราบใดที่คุณระบุพาธแบบเต็มเมื่อโหลด

โหลดและกำหนดค่าตัวเชื่อมต่อ ModSecurity-nginx ด้วย Nginx

ตอนนี้ คุณได้คอมไพล์โมดูลไดนามิกและกำหนดตำแหน่งตามนั้นแล้ว คุณต้องแก้ไข your /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;

ตัวอย่าง:

วิธีการติดตั้ง ModSecurity ด้วย Nginx บน Ubuntu 20.04

หากคุณพบโมดูลที่อื่น ตรวจสอบให้แน่ใจว่าได้รวมพาธแบบเต็ม

บันทึก nginx.conf ไฟล์ (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

ใช้โปรแกรมแก้ไขข้อความที่คุณชื่นชอบใน Ubuntu เปิดไฟล์ modsecurity.conf ดังนี้:

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

โดยค่าเริ่มต้น การกำหนดค่า ModSecurity มีเอ็นจิ้นกฎที่ระบุเป็น (การตรวจจับเท่านั้น)ซึ่งกล่าวอีกนัยหนึ่งคือรัน ModSecurity และตรวจจับพฤติกรรมที่เป็นอันตรายทั้งหมด แต่จะไม่บล็อกหรือแบนและบันทึกธุรกรรม HTTP ทั้งหมดที่ตั้งค่าสถานะ ควรใช้เฉพาะเมื่อคุณมีผลบวกปลอมจำนวนมากหรือได้เพิ่มการตั้งค่าระดับความปลอดภัยเป็นระดับสูงสุดแล้ว และทดสอบเพื่อดูว่ามีผลบวกปลอมเกิดขึ้นหรือไม่

เพื่อเปลี่ยนพฤติกรรมนี้เป็น (บน), ค้นหาสิ่งต่อไปนี้บน บรรทัด 7:

SecRuleEngine DetectionOnly

เปลี่ยนบรรทัดนี้เพื่อเปิดใช้งาน ModSecurity:

SecRuleEngine On

ตอนนี้ คุณต้องค้นหาสิ่งต่อไปนี้ ซึ่งตั้งอยู่บน บรรทัด 224:

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

สิ่งนี้ไม่ถูกต้องและจำเป็นต้องเปลี่ยน แก้ไขบรรทัดดังต่อไปนี้:

SecAuditLogParts ABCEFHJKZ

ตอนนี้บันทึก modsecurity.conf ไฟล์โดยใช้ (CTRL+O) แล้วออก (CTRL+X).

ส่วนต่อไปคือการสร้างไฟล์ต่อไปนี้ modsec-config.conf. ที่นี่คุณจะเพิ่ม modsecurity.conf ไฟล์พร้อมและต่อมาในกฎอื่น ๆ เช่น OWASP CRS, และหากคุณใช้ WordPress, the WPRS ซีอาร์เอส ชุดกฎ

ใช้คำสั่งต่อไปนี้เพื่อสร้างไฟล์และเปิด:

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

เมื่ออยู่ในไฟล์แล้ว ให้เพิ่มบรรทัดต่อไปนี้:

Include /etc/nginx/modsec/modsecurity.conf

บันทึก modsec-config.conf ไฟล์ด้วย (CTRL+O) แล้วก็ (CTRL+X) เพื่อออก

สุดท้าย คัดลอก ModSecurity's 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 นี้ การติดตั้งชุดกฎนี้จะทำให้คุณมีแหล่งป้องกันที่ดีจากภัยคุกคามที่เกิดขึ้นส่วนใหญ่บนอินเทอร์เน็ตโดยอัตโนมัติโดยการตรวจจับผู้มุ่งร้ายและบล็อกพวกเขา

การใช้ คำสั่ง 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

ติดตั้ง เปิดเครื่องรูดแพ็คเกจ หากคุณไม่ได้ติดตั้งสิ่งนี้บนเซิร์ฟเวอร์ของคุณ:

sudo dnf install unzip -y

 เปิดเครื่องรูด   มาสเตอร์.zip เก็บถาวรดังนี้:

sudo unzip v3.3.2.zip -d /etc/nginx/modsec

เมื่อก่อนเช่น modsecurity.conf การกำหนดค่าตัวอย่าง, OWASP CRS มาพร้อมกับไฟล์การกำหนดค่าตัวอย่างที่คุณต้องเปลี่ยนชื่อ เป็นการดีที่สุดที่จะใช้ CP คำสั่ง และสำรองข้อมูลไว้สำหรับอนาคตในกรณีที่คุณจำเป็นต้องเริ่มต้นใหม่อีกครั้ง

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

หากต้องการเปิดใช้กฎ ให้เปิด /etc/nginx/modsec/modsec-config.conf ใช้โปรแกรมแก้ไขข้อความอีกครั้ง:

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

เมื่อเข้าไปในไฟล์อีกครั้ง ให้เพิ่มสองบรรทัดต่อไปนี้:

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

บันทึกไฟล์ (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 Core Rule Set

OWASP CRS มีตัวเลือกค่อนข้างมาก อย่างไรก็ตาม การตั้งค่าเริ่มต้นจะปกป้องเซิร์ฟเวอร์ส่วนใหญ่ทันทีโดยไม่สร้างความเสียหายให้กับผู้เยี่ยมชมจริงและบอท SEO ที่ดี ด้านล่างนี้จะครอบคลุมบางส่วนเพื่อช่วยอธิบาย การอ่านเพิ่มเติมจะเป็นการดีที่สุดที่จะตรวจสอบตัวเลือกทั้งหมดในไฟล์การกำหนดค่าเอง เนื่องจากมีข้อมูลข้อความค่อนข้างน้อยที่จะอธิบายว่ามันคืออะไร

เปิดของคุณ CRS-setup.conf ไฟล์ดังต่อไปนี้:

sudo nano /etc/nginx/modsec/coreruleset-3.4-dev/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 ถ้าไม่เช่นนั้นก็พลาดไปหนึ่งขั้นตอน

ปัญหาที่พบบ่อยที่สุดคือการเปลี่ยนแปลงที่หายไป การตรวจจับเท่านั้น ไปยัง บน, ดังที่ได้กล่าวไว้ก่อนหน้านี้ในบทช่วยสอน

การจัดการกับผลบวกที่ผิดพลาดและการยกเว้นกฎที่กำหนดเอง

งานหนึ่งที่ไม่มีวันจบสิ้นคือการจัดการกับผลบวกที่ผิดพลาด 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 to (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-ก่อน-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

ข้อควรจำเมื่อสร้างกฎการยกเว้นแต่ละรายการต้องมีรหัส: และไม่ซ้ำกัน มิฉะนั้น เมื่อคุณทดสอบบริการ Nginx คุณจะได้รับข้อผิดพลาด ตัวอย่าง “id:1544, เฟส:1, บันทึก, อนุญาต, ctl:ruleEngine=off”ไม่สามารถใช้รหัส 1544 สำหรับกฎข้อที่สองได้

ตัวอย่างเช่น REQUEST_URI บางตัวจะทำให้เกิดผลบวกลวง ตัวอย่างด้านล่างมีสองแบบที่มี Google pagespeed beacon และปลั๊กอิน WMUDEV สำหรับ 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"

อย่างที่คุณเห็น 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"

พื้นที่ @ipMatch สามารถใช้กันอย่างแพร่หลายมากขึ้นสำหรับเครือข่ายย่อย หากคุณต้องการปฏิเสธ เครือข่ายย่อย or ที่อยู่ IP เปลี่ยนให้ปฏิเสธ คุณยังสามารถสร้างบัญชีดำและบัญชีขาวด้วยความรู้เล็กน้อยและกำหนดค่าด้วย fail2ban. ความเป็นไปได้มักจะไม่มีที่สิ้นสุด

ตัวอย่างสุดท้ายคือการปิดใช้งานเฉพาะกฎที่ทริกเกอร์ผลบวกลวง ไม่ใช่แบบครอบคลุมการอนุญาตพิเศษทั้งเส้นทาง ดังที่คุณเห็นในตัวอย่าง REQUEST_URI แรก อย่างไรก็ตาม ต้องใช้เวลาและการทดสอบมากกว่า ตัวอย่างเช่น คุณต้องการลบกฎ 941000 และ 942999 จากพื้นที่ /admin/ ของคุณ เนื่องจากมันทำให้เกิดการแบนและบล็อกที่ผิดพลาดสำหรับทีมของคุณ ค้นหาไฟล์บันทึกการรักษาความปลอดภัยในไฟล์ ID กฎ จากนั้นปิดใช้งานเฉพาะ ID นั้นด้วย RemoveByID ดังตัวอย่างด้านล่าง:

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

ตัวอย่างสามารถพบได้ใน ModSecurity GIT วิกิพีเดีย.

ไม่บังคับ – รวม Project Honeypot

โครงการหม้อน้ำผึ้ง เป็นระบบกระจายระบบแรกและแห่งเดียวสำหรับระบุผู้ส่งอีเมลขยะและสแปมบอทที่พวกเขาใช้ขูดที่อยู่จากเว็บไซต์ของคุณ เมื่อใช้ระบบ Project Honey Pot คุณสามารถติดตั้งที่อยู่ที่ติดแท็กแบบกำหนดเองตามเวลาและที่อยู่ IP ของผู้เยี่ยมชมไซต์ของคุณได้ หากที่อยู่ใดที่อยู่หนึ่งเหล่านี้เริ่มได้รับอีเมล เราไม่เพียงแต่สามารถบอกได้ว่าข้อความนั้นเป็นสแปม แต่ยังรวมถึงช่วงเวลาที่แน่นอนเมื่อมีการรวบรวมที่อยู่และที่อยู่ IP ที่รวบรวม

ModSecurity สามารถมีตัวเลือกในการรวม Project Honeypot ซึ่งจะสืบค้นฐานข้อมูลและบล็อกที่อยู่ใด ๆ ที่อยู่ในบัญชีดำของ HoneyPot โปรดทราบว่าการใช้สิ่งนี้สามารถนำไปสู่ผลบวกที่ผิดพลาดได้ อย่างไรก็ตาม ข้อมูลนี้มีขนาดเล็กเนื่องจากข้อมูลมีความน่าเชื่อถือ แต่บางครั้งบ็อตที่ดีมักถูกตั้งค่าสถานะ ดังนั้นควรระมัดระวัง

ขั้นตอนที่ 1 สร้างบัญชี บัญชีฟรี.

ขั้นตอนที่ 2 เมื่อคุณสมัครและเข้าสู่ระบบบนแดชบอร์ด ให้ค้นหาบรรทัด (คีย์ http:BL API ของคุณ) และคลิก รับ.

วิธีการติดตั้ง ModSecurity ด้วย Nginx บน Ubuntu 20.04

ขั้นตอนที่ 3 กลับไปที่ CRS-setup.conf ไฟล์โดยเปิดโดยใช้โปรแกรมแก้ไขข้อความ:

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

ขั้นตอนที่ 4 ค้นหาบรรทัดที่ขึ้นต้นด้วย #SecHttpBlKey ซึ่งอยู่ในบรรทัด 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"

ขั้นตอนที่ 5 เปลี่ยน SecHttpBlKey XXXXXXXXXXXXXXXX ด้วยคีย์ของคุณจาก Project HoneyPot

ตัวอย่าง:

SecHttpBlKey amhektvkkupe

ขั้นตอนที่ 6 ถัดไป ยกเลิกหมายเหตุบรรทัดทั้งหมดเพื่อเปิดใช้งานกฎ หากคุณต้องการปิดใช้งานกฎแทน (1) ใส่ (0) แทนหากคุณต้องการปิดใช้งานกฎใด ๆ โดยค่าเริ่มต้น block_search_ip=0 มีไว้สำหรับบอทของเครื่องมือค้นหา อย่าเปิดใช้งานสิ่งนี้ เว้นแต่คุณต้องการให้ Bing, Google และบอทดีๆ อื่นๆ มาที่เว็บไซต์ของคุณ

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"

หมายเหตุ อย่าใช้ แอมเฮกตเวกูเป้. ใช้ กุญแจของคุณแทน!

ขั้นตอนที่ 7 ทดสอบ 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

WordPress WPRS Rule Set สำหรับ ModSecurity

ตัวเลือกอื่นสำหรับ WordPress ผู้ใช้ต้องติดตั้งและรันควบคู่ไปกับชุดกฎ OWASP CRS ของคุณ ซึ่งเป็นโปรเจ็กต์ที่รู้จักกันดีซึ่งมีชื่อว่าชุดกฎ WPRS เนื่องจากเป็นทางเลือกและไม่เหมาะสำหรับทุกคน บทแนะนำจะไม่ครอบคลุมเนื้อหาในส่วนนี้

อย่างไรก็ตาม หากคุณต้องการติดตั้งสิ่งนี้เพื่อการป้องกันเพิ่มเติม หากคุณใช้ WordPress บนเซิร์ฟเวอร์ของคุณ โปรดไปที่บทช่วยสอนของเราที่ การติดตั้ง WordPress ModSecurity Rule Set (WPRS).

สร้างไฟล์ ModSecurity LogRotate:

บันทึก ModSecurity สามารถเติบโตได้ค่อนข้างเร็ว ขณะที่คุณกำลังคอมไพล์โมดูลและไม่ได้ติดตั้งโมดูลผ่านที่เก็บอย่างเป็นทางการจาก Ubuntu คุณจะต้องสร้างไฟล์หมุนบันทึกของคุณเอง

ขั้นแรก สร้างและเปิดไฟล์หมุน ModSecurity ของคุณ โมเด็ม:

sudo nano /etc/logrotate.d/modsec

เพิ่มรหัสต่อไปนี้:

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

สิ่งนี้จะเก็บบันทึกสำหรับ 31 วัน ถ้าอยากมีน้อยก็เปลี่ยน 31 เพื่อพูด 7 วันเท่ากับค่าบันทึกของสัปดาห์ คุณควรหมุนเวียน ModSecurity ทุกวัน หากคุณต้องการตรวจทานล็อกไฟล์ที่มีไฟล์รายสัปดาห์จะเป็นความหายนะที่ต้องกลั่นกรอง โดยพิจารณาจากขนาดไฟล์

ความคิดเห็นและข้อสรุป

ในบทช่วยสอนนี้ คุณจะเข้าใจในการติดตั้งซอร์ส Nginx, รวบรวม ModSecurity และตั้งค่า OWASP Rules จากส่วนต่างๆ ด้านบน โดยรวมแล้ว การปรับใช้ ModSecurity กับเซิร์ฟเวอร์ของคุณจะให้การป้องกันในทันที อย่างไรก็ตาม ความอดทน เวลา และความทุ่มเทในการเรียนรู้จะเป็นคุณสมบัติที่ยอดเยี่ยม สิ่งสุดท้ายที่คุณต้องการคือการบล็อกบอท SEO หรือที่สำคัญกว่านั้นคือผู้ใช้จริงที่อาจเป็นผู้มีโอกาสเป็นลูกค้า



ไม่ใช่สิ่งที่คุณกำลังมองหา? ลองค้นหาบทช่วยสอนเพิ่มเติม

แสดงความคิดเห็น