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


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 ด้วย Nginx บนเดสก์ท็อปหรือเซิร์ฟเวอร์ Debian 11 Bullseye

สารบัญ

เบื้องต้น

  • ระบบปฏิบัติการที่แนะนำ: เดเบียน 11 บูลส์อาย.
  • บัญชีผู้ใช้: บัญชีผู้ใช้ที่มีการเข้าถึง sudo หรือรูท
  • แพ็คเกจที่จำเป็น: ระบุไว้ตลอดบทช่วยสอน

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

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

sudo apt update && sudo apt upgrade -y

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

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

sudo whoami

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

[joshua@debian~]$ sudo whoami
root

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

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

su

ติดตั้งแพ็คเกจ CURL & UNZIP

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

sudo apt install curl unzip -y

ติดตั้ง Nginx . ล่าสุด

ขั้นแรก คุณจะต้องติดตั้ง Nginx และขอแนะนำให้ทำเช่นนี้กับ Nginx เวอร์ชันเสถียรหรือเวอร์ชันล่าสุด ก่อนดำเนินการต่อขอแนะนำให้ ลบการติดตั้งที่มีอยู่ออก ของ Nginx และติดตั้งล่าสุด Nginx เวอร์ชันเสถียรหรือเวอร์ชันหลัก.

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

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

sudo systemctl stop nginx

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

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

นำเข้าที่เก็บ Nginx ล่าสุด & ติดตั้ง

หากต้องการใช้เวอร์ชันล่าสุดของ nginx mainline หรือเวอร์ชันเสถียร คุณจะต้องนำเข้าที่เก็บก่อน

ในการนำเข้าที่เก็บ mainline:

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x

ในการนำเข้าที่เก็บถาวร:

curl -sSL https://packages.sury.org/nginx/README.txt | sudo bash -x

อัปเดตที่เก็บของคุณเพื่อแสดงการเปลี่ยนแปลงใหม่:

apt update

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

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

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

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

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

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

สายหลัก:

nano /etc/apt/sources.list.d/nginx-mainline.list

เสถียร:

nano /etc/apt/sources.list.d/nginx.list

ทั้งใน mainline และ stable เมื่อเปิดไฟล์ คุณจะเห็นเพียงบรรทัดเดียวดังนี้:

#Mainline File#
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
#Stable File#
deb-src https://packages.sury.org/nginx/ bullseye main

ใต้บรรทัดเดิม เพิ่มบรรทัดต่อไปนี้:

สายหลัก:

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

เสถียร:

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

ตัวอย่างลักษณะที่ควรจะเป็น (ตัวอย่างหลักเท่านั้น):

วิธีการติดตั้งและตั้งค่า ModSecurity ด้วย Nginx บน Debian 11

ดาวน์โหลด Nginx Source

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

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

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

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

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

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

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

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

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+0~20210802.31+debian11~1.gbp08d591.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-1+0~20210802.31+debian11~1.gbp08d591.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

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

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

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

ls

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

nginx-1.21.1
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc

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

sudo nginx -v

แหล่งที่มาที่คุณดาวน์โหลดควรตรงกับเวอร์ชันไบนารีที่ติดตั้งในระบบของคุณ

ตัวอย่าง:

nginx version: nginx/1.21.1

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

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

โคลน ModSecurity Repsoitory จาก Github

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

apt install git -y

ถัดไป โคลนที่เก็บ 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

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

make install

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

ติดตั้ง ModSecurity-nginx Connector

พื้นที่ ตัวเชื่อมต่อ ModSecurity-nginx เป็นจุดเชื่อมต่อระหว่าง nginx และ libmodsecurity โดยพื้นฐานแล้ว มันคือองค์ประกอบที่สื่อสารระหว่าง 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 ปัจจุบันในระบบของคุณ

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

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

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

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

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

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 Web Server

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

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

บันทึก 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

ใช้โปรแกรมแก้ไขข้อความที่คุณชื่นชอบ เปิดไฟล์ 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 apt 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+X).

ก่อนหน้านี้ คุณต้องทดสอบบริการ 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 CRS

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

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

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 วิกิพีเดีย; LinuxCapable ในอนาคตจะสร้างบทช่วยสอนในส่วนนี้เนื่องจากมีเนื้อหาค่อนข้างมากที่จะครอบคลุม

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

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

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

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

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

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

sudo nano /etc/nginx/modsec/coreruleset-3.3.3/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 จะเติบโตอย่างรวดเร็ว ขณะที่คุณกำลังคอมไพล์โมดูลและไม่ได้ติดตั้งโมดูลผ่านที่เก็บอย่างเป็นทางการจาก Debian คุณจะต้องสร้างไฟล์หมุนบันทึกของคุณเอง

ขั้นแรก สร้างและเปิดไฟล์หมุน 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 หรือที่สำคัญกว่านั้นคือผู้ใช้จริงที่อาจเป็นผู้มีโอกาสเป็นลูกค้า



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

คิด 2 ที่ "วิธีการติดตั้ง ModSecurity 3 & OWASP Core Rule ที่ตั้งค่าด้วย Nginx บน Debian 11 Bullseye"

  1. สวัสดี

    ที่ขั้นตอน "การสร้างสภาพแวดล้อม ModSecurity" ฉันมีข้อผิดพลาดมากมายในขั้นตอนการสร้าง เช่น:

    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/src'
    ทำให้ [3]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/src'
    ทำ[3]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/src'
    ทำ[2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/src'
    ทำ[1]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/src'
    ทำทุกอย่างใน doc
    ทำให้ [1]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/doc'
    ทำให้[1]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำให้ [1]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/doc'
    ทำทั้งหมดในเครื่องมือ
    ทำให้ [1]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/tools'
    ทำให้ทั้งหมดอยู่ในกฎ-ตรวจสอบ
    ทำ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/tools/rules-check'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/tools/rules-check'
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/tools'
    make[2]: ไม่มีอะไรจะทำเพื่อ 'all-am'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/tools'
    ทำ [1]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/tools'
    ทำให้ทั้งหมดในตัวอย่าง
    ทำให้ [1]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples'
    สร้างทั้งหมดใน multiprocess_c
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples/multiprocess_c'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples/multiprocess_c'
    ทำทั้งหมดใน reading_logs_with_offset
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples/reading_logs_with_offset'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำ[2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples/reading_logs_with_offset'
    ทำให้ทั้งหมดใน reading_logs_via_rule_message
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples/reading_logs_via_rule_message'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำให้ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples/reading_logs_via_rule_message'
    ทำทั้งหมดใน simple_example_using_c
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples/simple_example_using_c'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples/simple_example_using_c'
    ทำทั้งหมดโดยใช้_bodies_in_chunks
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples/using_bodies_in_chunks'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples/using_bodies_in_chunks'
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/examples'
    make[2]: ไม่มีอะไรจะทำเพื่อ 'all-am'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples'
    ทำ [1]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/examples'
    กำลังทดสอบทั้งหมด
    ทำให้ [1]: เข้าสู่ไดเร็กทอรี '/usr/local/src/ModSecurity/test'
    ทำให้ทั้งหมดอยู่ในเกณฑ์มาตรฐาน
    ทำให้ [2]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity/test/benchmark'
    ทำให้[2]: ไม่มีอะไรจะทำเพื่อ 'ทั้งหมด'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/test/benchmark'
    ทำให้ [2]: เข้าสู่ไดเร็กทอรี '/usr/local/src/ModSecurity/test'
    make[2]: ไม่มีอะไรจะทำเพื่อ 'all-am'
    ทำ [2]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/test'
    ทำ [1]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity/test'
    ทำให้ [1]: เข้าสู่ไดเรกทอรี '/usr/local/src/ModSecurity'
    make[1]: ไม่มีอะไรจะทำเพื่อ 'all-am'
    ทำให้ [1]: ออกจากไดเรกทอรี '/usr/local/src/ModSecurity'

    ตอบ
    • สวัสดี

      นั่นคือทั้งหมดที่พิมพ์?

      ไม่ได้รับผลผลิตนาน? นั่นเป็นเรื่องปกติสำหรับการทดสอบ ตัวอย่างที่ไม่ต้องทำอะไร แต่ถ้านั่นเป็นผลลัพธ์เดียวบอกฉัน

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

      คุณสามารถสร้างโมดูลไดนามิกได้หรือไม่?

      แจ้งให้เราทราบว่าคุณไปอย่างไร

      ขอบคุณ

      ตอบ

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