วิธีการติดตั้ง Apache ด้วย ModSecurity บน Ubuntu 22.04 LTS


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
  • เซสชั่นการหักหลัง
  • ภัยคุกคามอื่น ๆ

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

ในบทช่วยสอนต่อไปนี้ คุณจะได้เรียนรู้วิธีติดตั้ง ModSecurity 3 & OWASP Core Rule Set ด้วย Apache บน Ubuntu 22.04 LTS Jammy Jellyfish พร้อมตัวอย่างการกำหนดค่า



OWASP มีสามเวอร์ชันในการติดตั้ง; ฉันทดสอบทั้ง 3.3.2 และ 4.0.0 RC1 ที่ ทำงาน

อัปเดต Ubuntu

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

sudo apt update && sudo apt upgrade -y

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

อันดับแรก ขอแนะนำให้ลบการติดตั้ง Apache ที่มีอยู่ออกและติดตั้งเวอร์ชันล่าสุด ซึ่งเราจะใช้ Ondrey Surfury PPA

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

หยุดบริการปัจจุบันหากติดตั้งด้วยคำสั่งต่อไปนี้

sudo systemctl stop apache2

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

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

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

เมื่อคุณลบบริการ Apache เก่าของคุณแล้ว ให้นำเข้า PPA



sudo add-apt-repository ppa:ondrej/apache2 -y

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

sudo apt update

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

sudo apt install apache2 -y

ติดตั้ง/เปิดใช้งาน ModSecurity Apache Module

ขั้นตอนแรกคือการติดตั้งโมดูล Apache ที่รวมอยู่ในที่เก็บเริ่มต้นของ Ubuntu 22.04 ด้วยคำสั่งต่อไปนี้

sudo apt install libapache2-mod-security2

เมื่อติดตั้งแล้ว ให้เปิดใช้งานโมดูลดังนี้

sudo a2enmod security2

ตรวจสอบให้แน่ใจว่าคุณเริ่มบริการ Apache2 ใหม่เพื่อให้สอดคล้องกับโมดูลใหม่และการเปลี่ยนแปลง

sudo systemctl restart apache2

เปิดใช้งาน ModSecurity Module

การกำหนดค่าของ Apache ModSecurity สามารถพบได้ใน /etc/apache2/mods-enabled/security2.conf, ซึ่งจะมีบรรทัดที่ประกอบด้วยสิ่งต่อไปนี้



IncludeOptional /etc/modsecurity/*.conf

ตัวอย่าง:

วิธีการติดตั้ง Apache ด้วย ModSecurity บน Ubuntu 22.04 LTS

Apache จะโหลดทั้งหมด *.conf ไฟล์จาก /etc/modsecurity/ ไดเร็กทอรี แต่คุณจะต้องเปลี่ยนชื่อ modsecurity.conf-แนะนำ ไฟล์การกำหนดค่าก่อน

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

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

sudo nano /etc/modsecurity/modsecurity.conf

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

ในไฟล์การกำหนดค่า เปลี่ยนลักษณะการทำงานนี้เป็น (บน), พบในบรรทัดที่ 7

SecRuleEngine DetectionOnly

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



SecRuleEngine On

ตัวอย่าง:

วิธีการติดตั้ง Apache ด้วย ModSecurity บน Ubuntu 22.04 LTS

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

# Log everything we know about a transaction.
SecAuditLogParts ABDEFHIJZ

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

SecAuditLogParts ABCEFHJKZ

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

เริ่มบริการ Apache ของคุณใหม่โดยใช้คำสั่ง systemctl เพื่อทำการเปลี่ยนแปลงแบบสด

sudo systemctl restart apache2

ติดตั้ง OWASP Core Rule Set สำหรับ ModSecurity

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



ตรวจสอบ หน้าแท็กการเปิดตัว OWASP เพื่อดูว่าล่าสุดเป็นอย่างไร ดังตัวอย่างด้านล่างอาจมีการเปลี่ยนแปลงในอนาคต

ขั้นแรก สร้างไดเร็กทอรีที่จะเป็นพาเรนต์หลักสำหรับ OWASP

sudo mkdir /etc/apache2/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

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

sudo apt install unzip -y

ตอนนี้คลายซิปไฟล์เก็บถาวร

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

จำไว้ว่า หากคุณดาวน์โหลด v4.0 หรือทุกคืน ให้เปลี่ยนคำสั่งเพื่อสะท้อนสิ่งนี้

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

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

จำไว้ว่าคำสั่งข้างต้นเป็นเพียงตัวอย่างเท่านั้น อย่าลืมเปลี่ยน /coreruleset-3.3.2/ ด้วย OWASP เวอร์ชันที่แน่นอนที่คุณตัดสินใจด้วย

หากต้องการเปิดใช้กฎ ให้เปิด /etc/etc/apache2/mods-enabled/security2.conf ดังต่อไปนี้



sudo nano /etc/apache2/mods-enabled/security2.conf

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

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

จำไว้ว่าคำสั่งข้างต้นเป็นเพียงตัวอย่างเท่านั้น อย่าลืมเปลี่ยน /coreruleset-3.3.2/ ด้วย OWASP เวอร์ชันที่แน่นอนที่คุณตัดสินใจด้วย

นอกจากนี้ ให้เว้นบรรทัดต่อไปนี้หรือลบออก

IncludeOptional /usr/share/modsecurity-crs/*.load

ตัวอย่าง:

วิธีการติดตั้ง Apache ด้วย ModSecurity บน Ubuntu 22.04 LTS

บันทึกไฟล์ (CTRL+O) และออก (CTRL+T).

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



sudo systemctl restart apache2

การใช้และทำความเข้าใจ OWASP Core Rule Set

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

เปิดของคุณ CRS-setup.conf ไฟล์

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

ตัวอย่าง:



วิธีการติดตั้ง Apache ด้วย ModSecurity บน Ubuntu 22.04 LTS

ปัญหาที่พบบ่อยที่สุดคือการเปลี่ยนแปลงที่หายไป การตรวจจับเท่านั้น ไปยัง 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 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/apache2/modsec/coreruleset-3.3.2/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.2/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

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

ตัวอย่าง “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 สามารถใช้กันอย่างแพร่หลายมากขึ้นสำหรับเครือข่ายย่อย หากคุณต้องการปฏิเสธการเปลี่ยนซับเน็ตหรือที่อยู่ 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 วิกิพีเดีย.



WordPress WPRS Rule Set สำหรับ ModSecurity

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

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

สร้างไฟล์ ModSecurity LogRotate

บันทึก ModSecurity สามารถเติบโตได้มากเกินไป ดังนั้นคุณต้องตั้งค่าการหมุนเวียนบันทึกเนื่องจากไม่ได้ทำเพื่อคุณ

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

sudo nano /etc/logrotate.d/modsec

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

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

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



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

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



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

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