ModSecurity برای وردپرس چطور پیکربندی می‌شود؟

در یک پروژه، سرور اختصاصی یک سایت وردپرسی مورد حمله SQL Injection قرار گرفت که از یک آسیب‌پذیری صفر-روز در یک افزونه استفاده می‌کرد. Cloudflare WAF آن را مسدود نکرد چون Pattern حمله جدید بود. اما ModSecurity با CRS و تنظیمات PL2، همان حمله را در سطح سرور شناسایی و مسدود کرد. این تجربه، تفاوت بین دفاع مبتنی بر Signature و دفاع مبتنی بر Anomaly Scoring را روشن کرد: ModSecurity در برخی سناریوها، دقت بالاتری دارد.

ModSecurity چیست و چرا برای وردپرس مهم است؟

ModSecurity یک Web Application Firewall (WAF) متن‌باز است که در سال ۲۰۰۲ توسط Ivan Ristić معرفی شد و از سال ۲۰۱۳ تحت مدیریت Trustwave و سپس OWASP توسعه می‌یابد. این WAF در سطح سرور وب اجرا می‌شود و ترافیک HTTP/HTTPS را قبل از رسیدن به اپلیکیشن تحلیل می‌کند. اگر با ModSecurity آشنا شده باشید، می‌دانید که این پروژه یکی از بالغ‌ترین WAFهای متن‌باز است.

مهم‌ترین ویژگی ModSecurity، معماری Rule Engine آن است. برخلاف WAFهای ساده که بر پایه Pattern Matching کار می‌کنند، ModSecurity از یک زبان قوانین قدرتمند استفاده می‌کند که امکان ترکیب چند شرط، تحلیل Anomaly، و تصمیم‌گیری بر پایه امتیاز را فراهم می‌نماید. این معماری، ModSecurity را به یک ابزار دقیق و انعطاف‌پذیر تبدیل می‌کند.

ضرورت ModSecurity برای وردپرس از چند جهت قابل تحلیل است. اول، کنترل کامل: برخلاف Cloudflare WAF که یک سرویس شخص ثالث است، ModSecurity روی سرور شما اجرا می‌شود و کنترل کامل روی قوانین و لاگ‌ها دارید. دوم، استقلال از شبکه: اگر CDN یا Cloudflare در دسترس نباشد، ModSecurity همچنان کار می‌کند. سوم، هزینه: ModSecurity متن‌باز و رایگان است. چهارم، دقت: در برخی سناریوها، ModSecurity با Anomaly Scoring دقیق‌تر از WAFهای ساده عمل می‌کند.

«ModSecurity یک WAF در دسترس شماست، نه یک WAF که از دور کنترل می‌شود. این تفاوت، در پروژه‌هایی که کنترل و استقلال اهمیت دارد، حیاتی است.»

اگر با امنیت وب و اصول آن آشنا شده باشید، می‌دانید که ModSecurity بخشی از یک استراتژی دفاع لایه‌ای است. اگر با Cloudflare WAF برای وردپرس آشنا شده باشید، می‌دانید که این دو مکمل یکدیگرند: Cloudflare در لبه و ModSecurity روی سرور.

معماری ModSecurity: از Rule Engine تا Logging

درک معماری ModSecurity برای پیکربندی صحیح ضروری است. این معماری از پنج لایه تشکیل شده:

لایه اول: Request Interception. ModSecurity درخواست HTTP را قبل از رسیدن به اپلیکیشن دریافت می‌کند. این کار از طریق یک ماژول در Nginx یا Apache انجام می‌شود.

لایه دوم: Parsing. درخواست به اجزای مختلف تجزیه می‌شود: URL، متد HTTP، هدرها، Cookieها، بدنه POST، فایل‌های آپلودی. هر جزء به یک متغیر ModSecurity نگاشت می‌شود.

لایه سوم: Rule Engine. قوانین ModSecurity اجرا می‌شوند. هر قانون از دو بخش تشکیل شده: SecRule (شرط) و Action (اقدام). شرط‌ها بر پایه متغیرها و عملگرها ساخته می‌شوند.

لایه چهارم: Anomaly Scoring. برخلاف WAFهای ساده که بر پایه Block/Allow تصمیم می‌گیرند، ModSecurity از Anomaly Scoring استفاده می‌کند. هر قانون، یک امتیاز به درخواست اضافه می‌کند و اگر مجموع امتیاز از یک آستانه عبور کند، درخواست مسدود می‌شود. این رویکرد، False Positive را کاهش می‌دهد چون یک قانون به‌تنهایی باعث مسدودسازی نمی‌شود.

لایه پنجم: Logging. تمام رویدادها در یک Audit Log ثبت می‌شوند که شامل جزئیات کامل درخواست، قوانین مطابقت‌یافته، و اقدام انجام‌شده است.

Request → Interception → Parsing → Rule Engine → Anomaly Score → Action
                                        ↓
                                    Audit Log

نکته کلیدی در این معماری، Phase-based Execution است. ModSecurity پنج Phase دارد که در هر Phase، قوانین مختلف اجرا می‌شوند:

نصب ModSecurity روی Nginx و Apache

نصب ModSecurity بسته به وب سرور متفاوت است. در این بخش، هر دو روش بررسی می‌شود.

نصب روی Nginx

Nginx از ModSecurity به‌صورت بومی پشتیبانی نمی‌کند و نیازمند ماژول ModSecurity-nginx است. در توزیع‌های مدرن، این ماژول به‌صورت پکیج آماده ارائه می‌شود:

# Ubuntu/Debian
sudo apt install libmodsecurity3 libnginx-mod-http-modsecurity

# فعال‌سازی ماژول
sudo ln -s /etc/nginx/modules-available/mod-http-modsecurity.conf /etc/nginx/modules-enabled/

# بررسی نصب
nginx -V 2>&1 | grep modsecurity

پس از نصب، فایل پیکربندی ModSecurity در مسیر /etc/nginx/modsecurity/ قرار می‌گیرد. برای فعال‌سازی در یک Server Block:

server {
    listen 443 ssl http2;
    server_name example.com;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsecurity/main.conf;

    # ...
}

نصب روی Apache

Apache از ModSecurity به‌صورت بومی از طریق ماژول mod_security2 پشتیبانی می‌کند:

# Ubuntu/Debian
sudo apt install libapache2-mod-security2

# فعال‌سازی ماژول
sudo a2enmod security2

# راه‌اندازی فایل پیکربندی
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

# فعال‌سازی
sudo systemctl restart apache2

در Apache، پیکربندی ModSecurity از طریق فایل /etc/modsecurity/modsecurity.conf انجام می‌شود.

پیکربندی پایه

مهم‌ترین پارامترها در پیکربندی ModSecurity:

# حالت اجرا: DetectionOnly یا On
SecRuleEngine On

# فایل قوانین اصلی
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

# Audit Log
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsecurity/audit.log
SecAuditLogFormat JSON

# Request Body
SecRequestBodyAccess On
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# Response Body
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyLimit 524288

حالت SecRuleEngine DetectionOnly فقط لاگ می‌کند و مسدود نمی‌کند. این حالت برای تست اولیه و شناسایی False Positive ایده‌آل است.

اگر با تقویت امنیت وردپرس گام‌به‌گام آشنا شده باشید، این پیکربندی بخشی از سخت‌سازی سرور است.

OWASP Core Rule Set و سطوح Paranoia

OWASP ModSecurity Core Rule Set (CRS) مجموعه‌ای از بیش از ۲۰۰ قانون آماده است که توسط جامعه امنیتی توسعه و به‌روزرسانی می‌شود. این CRS، استاندارد صنعتی برای ModSecurity است و در سه سطح Paranoia ارائه می‌شود.

ساختار CRS از چند فایل تشکیل شده که هرکدام یک دسته از حملات را پوشش می‌دهد:

سطوح Paranoia در CRS:

سطح PL1 (پایه): کمترین سخت‌گیری، False Positive پایین. این سطح، برای اکثر سایت‌ها کافی است.

سطح PL2: سخت‌گیری متوسط، False Positive متوسط. این سطح، برای سایت‌های با نیازهای امنیتی بالاتر مناسب است.

سطح PL3: سخت‌گیری بالا، False Positive بالا. این سطح، نیازمند مدیریت دقیق Exclusions است.

سطح PL4: بالاترین سخت‌گیری، False Positive بسیار بالا. این سطح، فقط برای سایت‌های با نیاز امنیتی ویژه توصیه می‌شود.

# تنظیم Paranoia Level در crs-setup.conf
SecAction 
  "id:900000,
   phase:1,
   nolog,
   pass,
   t:none,
   setvar:tx.paranoia_level=2"

آستانه Anomaly Score نیز باید تنظیم شود. این آستانه تعیین می‌کند که در چه امتیازی، درخواست مسدود شود:

# آستانه ورودی
SecAction 
  "id:900110,
   phase:1,
   nolog,
   pass,
   t:none,
   setvar:tx.inbound_anomaly_score_threshold=5,
   setvar:tx.outbound_anomaly_score_threshold=4"

آستانه ۵ برای PL1 و ۴ برای PL2 رایج است. اگر آستانه پایین‌تر باشد، حساسیت بالاتر اما False Positive بیشتر می‌شود.

تنظیم CRS برای وردپرس

وردپرس چند ویژگی دارد که CRS پیش‌فرض را می‌شکند و نیازمند تنظیمات اختصاصی است. مهم‌ترین این ویژگی‌ها:

ویژگی اول: REST API. ویرایشگر گوتنبرگ از REST API استفاده می‌کند و درخواست‌های آن ممکن است توسط CRS مسدود شوند. راه‌حل: Skip کردن REST API برای کاربران لاگین‌کرده:

SecRule REQUEST_URI "@beginsWith /wp-json/" 
  "id:10001,
   phase:1,
   pass,
   nolog,
   ctl:ruleEngine=DetectionOnly"

ویژگی دوم: admin-ajax.php. این فایل برای درخواست‌های AJAX استفاده می‌شود و درخواست‌های آن ممکن است Patternهای مشکوک داشته باشند. راه‌حل: Skip کردن admin-ajax.php برای کاربران لاگین‌کرده:

SecRule REQUEST_URI "@contains /wp-admin/admin-ajax.php" 
  "id:10002,
   phase:1,
   pass,
   nolog,
   ctl:ruleRemoveTargetById=942100"

ویژگی سوم: صفحه‌سازها و فرم‌سازها. Elementor، Divi، Gravity Forms و سایر افزونه‌های مشابه، ورودی‌های پیچیده‌ای دارند که شبیه حمله به نظر می‌رسند. راه‌حل: Skip کردن پارامترهای خاص این افزونه‌ها:

SecRule REQUEST_URI "@contains /wp-admin/post.php" 
  "id:10003,
   phase:2,
   pass,
   nolog,
   ctl:ruleRemoveTargetById=941100,
   ctl:ruleRemoveTargetById=941110,
   ctl:ruleRemoveTargetById=942100"

اگر با ساخت بلاک سفارشی گوتنبرگ آشنا شده باشید، می‌دانید که ویرایشگر گوتنبرگ درخواست‌های REST زیادی ارسال می‌کند و باید این Endpointها Skip شوند.

ویژگی چهارم: فایل‌های استاتیک با Query String. برخی قالب‌ها و افزونه‌ها از Query String در URL فایل‌های CSS و JS استفاده می‌کنند که ممکن است شبیه SQL Injection به نظر برسد. راه‌حل: Skip کردن فایل‌های استاتیک:

SecRule REQUEST_URI "@rx .(css|js|jpg|jpeg|png|gif|webp|svg|woff2?|ttf|eot|ico)(?|$)" 
  "id:10004,
   phase:1,
   pass,
   nolog,
   ctl:ruleEngine=Off"

Exclusions و مدیریت False Positive

False Positive بزرگ‌ترین چالش ModSecurity است. سه نوع Exclusion وجود دارد که هرکدام کاربرد متفاوتی دارند:

نوع اول: Exclusion بر پایه URI. Skip کردن تمام قوانین برای یک URI مشخص:

SecRule REQUEST_URI "@beginsWith /wp-json/" 
  "id:10010,
   phase:1,
   pass,
   nolog,
   ctl:ruleEngine=Off"

نوع دوم: Exclusion بر پایه Rule ID. Skip کردن یک قانون خاص برای یک URI:

SecRule REQUEST_URI "@contains /wp-admin/admin-ajax.php" 
  "id:10011,
   phase:1,
   pass,
   nolog,
   ctl:ruleRemoveById=942100"

نوع سوم: Exclusion بر پایه پارامتر. Skip کردن یک قانون برای یک پارامتر خاص:

SecRule ARGS:content "@contains <div" 
  "id:10012,
   phase:2,
   pass,
   nolog,
   ctl:ruleRemoveTargetById=941100"

روش‌شناسی مدیریت False Positive:

1. ModSecurity را در حالت DetectionOnly راه‌اندازی کنید.
2. برای ۲۴ تا ۷۲ ساعت لاگ‌ها را پایش کنید.
3. رویدادهای False Positive را دسته‌بندی کنید.
4. برای هر دسته، یک Exclusion تعریف کنید.
5. حالت را به On تغییر دهید.
6. به‌طور مستمر لاگ‌ها را پایش کنید.

«False Positive در ModSecurity یک پدیده دائمی است. هر به‌روزرسانی وردپرس، افزونه یا CRS می‌تواند False Positive جدید ایجاد کند. Exclusions باید به‌طور مستمر به‌روزرسانی شوند.»

قوانین سفارشی برای وردپرس

علاوه بر CRS، قوانین سفارشی برای نیازهای خاص وردپرس مفید هستند. این قوانین، لایه‌ای اضافی از دفاع فراهم می‌کنند:

قانون اول: محافظت از wp-config.php.

SecRule REQUEST_URI "@contains /wp-config.php" 
  "id:20001,
   phase:1,
   deny,
   status:403,
   msg:'Access to wp-config.php blocked'"

قانون دوم: مسدودسازی XML-RPC.

SecRule REQUEST_URI "@contains /xmlrpc.php" 
  "id:20002,
   phase:1,
   deny,
   status:403,
   msg:'XML-RPC access blocked'"

قانون سوم: محدودسازی دسترسی به پیشخوان.

SecRule REQUEST_URI "@contains /wp-admin" 
  "id:20003,
   phase:1,
   chain,
   deny,
   status:403,
   msg:'Admin access restricted'"
  SecRule REMOTE_ADDR "!@ipMatch 192.0.2.1,192.0.2.2"

قانون چهارم: مسدودسازی User-Agentهای مشکوک.

SecRule REQUEST_HEADERS:User-Agent "@pmFromFile bad-user-agents.txt" 
  "id:20004,
   phase:1,
   deny,
   status:403,
   msg:'Bad user agent blocked'"

قانون پنجم: محافظت از صفحه ورود.

SecRule REQUEST_URI "@contains /wp-login.php" 
  "id:20005,
   phase:1,
   chain,
   deny,
   status:429,
   msg:'Too many login attempts'"
  SecRule IP:login_attempt "@gt 10"

این قوانین، مکمل CRS هستند و لایه‌ای اضافی از دفاع فراهم می‌کنند. اگر با Rate Limiting در وردپرس و جلوگیری از حملات آشنا شده باشید، می‌دانید که این رویکرد مکمل Rate Limiting است.

بهینه‌سازی عملکرد و کاهش Overhead

ModSecurity یک هزینه عملکردی دارد: هر درخواست باید از Rule Engine عبور کند. Overhead ModSecurity در حالت پیش‌فرض حدود ۵ تا ۱۵ درصد CPU است که می‌تواند در سایت‌های پرترافیک قابل توجه باشد. سه رویکرد برای کاهش این Overhead:

رویکرد اول: کاهش قوانین فعال. فقط قوانینی را فعال کنید که برای سایت شما مرتبط هستند. مثلاً اگر از XML-RPC استفاده نمی‌کنید، قوانین مربوط به آن را غیرفعال کنید:

SecRuleUpdateActionById 900000 "setvar:tx.rule_engine=On"

رویکرد دوم: Skip کردن فایل‌های استاتیک. فایل‌های CSS، JS، تصاویر و فونت‌ها نیازی به تحلیل WAF ندارند:

SecRule REQUEST_URI "@rx .(css|js|jpg|jpeg|png|gif|webp|svg|woff2?|ttf|eot|ico)$" 
  "id:20010,
   phase:1,
   pass,
   nolog,
   ctl:ruleEngine=Off"

رویکرد سوم: استفاده از Caching. اگر یک IP در چند ثانیه درخواست‌های مشابه ارسال کند، می‌توان نتیجه تحلیل را کش کرد. این رویکرد، Rule Caching نامیده می‌شود:

SecAction 
  "id:20011,
   phase:1,
   nolog,
   pass,
   t:none,
   setvar:tx.cache_ttl=300"

اگر با Performance Budget در وردپرس آشنا شده باشید، می‌دانید که Overhead ModSecurity بخشی از بودجه عملکردی است و باید مدیریت شود.

Logging و پایش

ModSecurity دو نوع Log تولید می‌کند: Error Log (لاگ مختصر) و Audit Log (لاگ کامل). Audit Log منبع اصلی تحلیل است چون جزئیات کامل درخواست، قوانین مطابقت‌یافته، و امتیاز Anomaly را ثبت می‌کند.

پیکربندی Audit Log:

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/modsecurity/audit.log
SecAuditLogFormat JSON

پارامتر SecAuditLogParts تعیین می‌کند که چه بخش‌هایی از درخواست لاگ شوند:

• A: Audit Log Header
• B: Request Headers
• I: Request Body (مختصر)
• J: Request Body (کامل)
• D: تخصیص امتیاز Anomaly
• E: Response Body
• F: Response Headers
• H: Audit Log Trailer
• Z: وضعیت نهایی

تحلیل Audit Log با ابزارهایی مثل modsec-audit-parser یا GoAccess انجام می‌شود:

# شمارش رویدادهای مسدودشده
grep -c "ModSecurity: Access denied" /var/log/modsecurity/audit.log

# شمارش بر پایه Rule ID
grep -o "[id "[0-9]*"]" /var/log/modsecurity/audit.log | sort | uniq -c | sort -rn

اگر با بررسی لاگ حملات سایت آشنا شده باشید، این تحلیل بخشی از استراتژی تشخیص است.

ModSecurity در مقابل Cloudflare WAF

انتخاب بین ModSecurity و Cloudflare WAF به نیازهای پروژه بستگی دارد. جدول زیر تفاوت‌های کلیدی را نشان می‌دهد:

اگر امنیت یکپارچه و مدیریت ساده برای شما اولویت است، Cloudflare WAF انتخاب بهتری است. اگر کنترل کامل روی سرور و استقلال از سرویس‌های شخص ثالث مهم است، ModSecurity گزینه مناسب‌تری است. در بسیاری از پروژه‌های حرفه‌ای، ترکیب هر دو استفاده می‌شود: Cloudflare WAF در لبه برای فیلتر اولیه و ModSecurity روی سرور برای دفاع در عمق. اگر با Cloudflare WAF برای وردپرس آشنا شده باشید، این ترکیب را به‌عنوان یک استراتژی حرفه‌ای می‌شناسید.

اشتباهات رایج در پیکربندی

اشتباه اول: فعال‌سازی ModSecurity در حالت On بدون تست. اگر ModSecurity مستقیم در حالت مسدودسازی فعال شود، ممکن است کاربران واقعی مسدود شوند. راه‌حل: شروع از DetectionOnly.

اشتباه دوم: Paranoia Level بالا. تنظیم PL3 یا PL4 باعث False Positive مکرر می‌شود. راه‌حل: شروع از PL1 و افزایش تدریجی.

اشتباه سوم: عدم Skip کردن REST API. اگر REST API Skip نشود، ویرایشگر گوتنبرگ از کار می‌افتد. راه‌حل: Skip کردن /wp-json/ برای کاربران لاگین‌کرده.

اشتباه چهارم: عدم Skip کردن فایل‌های استاتیک. اگر فایل‌های CSS و JS از Rule Engine عبور کنند، Overhead افزایش می‌یابد. راه‌حل: Skip کردن فایل‌های استاتیک بر پایه Extension.

اشتباه پنجم: عدم به‌روزرسانی CRS. قوانین CRS به‌طور مداوم به‌روزرسانی می‌شوند و نسخه قدیمی می‌تواند آسیب‌پذیری‌های جدید را نشناسد. راه‌حل: به‌روزرسانی ماهانه CRS.

اشتباه ششم: نبود پایش Audit Log. بدون پایش، نمی‌توان فهمید که ModSecurity درست کار می‌کند. راه‌حل: تحلیل هفتگی Audit Log و تنظیم هشدار برای رویدادهای غیرعادی.

اشتباه هفتم: عدم تنظیم Audit Log Parts. اگر تمام بخش‌های درخواست لاگ شوند، حجم لاگ‌ها به‌شدت افزایش می‌یابد. راه‌حل: استفاده از ABIJDEFHZ به‌جای ABCDEFGHIJKLMNOPQRSTUVWXYZ.

اشتباه هشتم: عدم تنظیم آستانه Anomaly. اگر آستانه پیش‌فرض (۵) برای سایت شما مناسب نباشد، False Positive یا False Negative رخ می‌دهد. راه‌حل: تنظیم آستانه بر پایه تحلیل لاگ‌ها.

اشتباه نهم: Skip کردن همه قوانین برای یک URI. اگر ctl:ruleEngine=Off برای یک URI تنظیم شود، تمام قوانین Skip می‌شوند و آن URI از محافظت خارج می‌شود. راه‌حل: استفاده از ctl:ruleRemoveById برای Skip کردن قوانین خاص.

پرسش‌های پرتکرار درباره ModSecurity

ModSecurity چیست و چرا برای وردپرس مهم است؟

ModSecurity یک Web Application Firewall متن‌باز است که روی سرور اجرا می‌شود و ترافیک HTTP را در سطح Application تحلیل می‌کند. برای وردپرس مهم است چون کنترل کامل روی قوانین را فراهم می‌کند، از CDN مستقل است، و با CRS دقت بالایی در تشخیص حملات دارد.

چگونه ModSecurity را روی Nginx نصب کنم؟

با نصب پکیج libnginx-mod-http-modsecurity و فعال‌سازی ماژول، سپس تنظیم modsecurity on در Server Block و تعیین مسیر فایل قوانین با modsecurity_rules_file.

OWASP CRS چیست و چه کاربردی دارد؟

OWASP Core Rule Set مجموعه‌ای از بیش از ۲۰۰ قانون آماده است که برای ModSecurity طراحی شده و حملات رایج مثل SQL Injection، XSS، RCE و LFI را پوشش می‌دهد. این CRS استاندارد صنعتی است و به‌طور مداوم به‌روزرسانی می‌شود.

Paranoia Level چیست و چه سطحی مناسب است؟

Paranoia Level سطح سخت‌گیری CRS را تعیین می‌کند. PL1 کمترین سخت‌گیری و کمترین False Positive، PL4 بالاترین سخت‌گیری و بیشترین False Positive. برای اکثر سایت‌های وردپرسی، PL1 یا PL2 مناسب است.

چگونه False Positive را مدیریت کنم؟

شروع از DetectionOnly، پایش ۲۴ تا ۷۲ ساعت، شناسایی False Positiveها، تعریف Exclusion بر پایه URI، Rule ID، یا پارامتر، و تغییر به حالت On. این فرآیند باید مستمر باشد.

آیا ModSecurity با ویرایشگر گوتنبرگ سازگار است؟

بله، اما باید REST API را برای کاربران لاگین‌کرده Skip کنید. ویرایشگر گوتنبرگ از REST API برای ذخیره محتوا استفاده می‌کند و اگر ModSecurity این درخواست‌ها را مسدود کند، ویرایشگر از کار می‌افتد.

ModSecurity چقدر CPU مصرف می‌کند؟

در حالت پیش‌فرض ۵ تا ۱۵ درصد CPU. با Skip کردن فایل‌های استاتیک، کاهش قوانین فعال، و تنظیم PL1، می‌توان Overhead را به ۲ تا ۵ درصد کاهش داد.

تفاوت ModSecurity و Cloudflare WAF چیست؟

ModSecurity روی سرور اجرا می‌شود و کنترل کامل روی قوانین فراهم می‌کند اما منابع سرور را مصرف می‌کند. Cloudflare WAF در لبه اجرا می‌شود، منابع سرور را مصرف نمی‌کند، Managed Rules خودکار دارد اما کنترل روی قوانین محدودتر است.

آیا ModSecurity بر سرعت سایت تأثیر می‌گذارد؟

بله، Overhead آن ۵ تا ۱۵ درصد CPU است که در سایت‌های پرترافیک می‌تواند قابل توجه باشد. با بهینه‌سازی می‌توان این Overhead را کاهش داد اما حذف کامل آن ممکن نیست.

آیا ModSecurity برای سایت‌های اشتراکی مناسب است؟

معمولاً خیر. ModSecurity نیازمند دسترسی root و امکان پیکربندی سرور است. روی هاست اشتراکی، معمولاً نمی‌توان ModSecurity را نصب کرد. برای سایت‌های اشتراکی، Cloudflare WAF گزینه بهتری است.

نگاه معمارانه سطح ارشد

از منظر معماری نرم‌افزار، ModSecurity یک نمونه از Inline Security Enforcement است که در آن، تصمیمات امنیتی در مسیر درخواست قرار می‌گیرند و هر درخواست باید از یک لایه تحلیل عبور کند. این معماری، مزایای روشنی دارد: کنترل کامل، استقلال از شبکه، و امکان تحلیل عمیق. اما چالش‌هایی نیز دارد: Overhead عملکردی، پیچیدگی پیکربندی، و مدیریت مستمر False Positive.

چالش اصلی، Rule Engine Performance است. ModSecurity از یک موتور تحلیل Regex استفاده می‌کند که برای هر درخواست، ده‌ها یا صدها Regex اجرا می‌کند. این موتور، در سایت‌های پرترافیک می‌تواند گلوگاه شود. راه‌حل، استفاده از Hyperscan است که یک کتابخانه Regex با کارایی بالا است و در نسخه‌های جدید ModSecurity پشتیبانی می‌شود:

# فعال‌سازی Hyperscan
SecRuleEngine On
SecRequestBodyAccess On

اگر Hyperscan نصب باشد، ModSecurity به‌طور خودکار از آن استفاده می‌کند و Overhead را تا ۵۰ درصد کاهش می‌دهد.

چالش دوم، Anomaly Scoring Calibration است: تنظیم آستانه Anomaly نیازمند تحلیل دقیق ترافیک است. اگر آستانه پایین باشد، False Positive زیاد می‌شود. اگر بالا باشد، حملات عبور می‌کنند. راه‌حل، استفاده از Machine Learning برای تنظیم خودکار آستانه بر پایه Baseline ترافیک است. ابزارهایی مثل ML-Based WAF در حال توسعه هستند و در آینده نزدیک به ModSecurity اضافه خواهند شد.

چالش سوم، Distributed Deployment است: در یک معماری چند سروری، ModSecurity باید روی هر سرور نصب و به‌روزرسانی شود. مدیریت Exclusions و قوانین در چند سرور پیچیده است. راه‌حل، استفاده از Centralized Management با ابزارهایی مثل OWASP CRS Central Management یا Ansible است:

# Ansible playbook برای توزیع قوانین ModSecurity
- name: Deploy ModSecurity rules
  copy:
    src: /local/rules/custom.conf
    dest: /etc/modsecurity/rules/custom.conf
  notify: reload nginx

چالش چهارم، Observability است: Audit Log ModSecurity می‌تواند حجم بالایی داشته باشد و تحلیل آن در مقیاس بزرگ پیچیده است. راه‌حل، استفاده از ELK Stack یا Graylog برای جمع‌آوری و تحلیل متمرکز لاگ‌ها است. اگر با پروفایلینگ وردپرس با New Relic آشنا شده باشید، می‌دانید که این سطح از Observability در سیستم‌های حرفه‌ای ضروری است.

چالش پنجم، Compatibility با HTTP/۳ است: ModSecurity به‌طور کلاسیک برای HTTP/۱ و HTTP/۲ طراحی شده و پشتیبانی از HTTP/۳ در نسخه‌های فعلی محدود است. راه‌حل، استفاده از ModSecurity v۳ که از HTTP/۳ پشتیبانی می‌کند یا ترکیب با WAFهای مدرن.

در نهایت، ModSecurity یک Investment است: زمان اولیه بیشتر، اما کنترل کامل و استقلال بلندمدت. تیم‌هایی که این ابزار را با دانش و انضباط پیکربندی می‌کنند، سیستم‌هایی می‌سازند که در برابر طیف گسترده‌ای از حملات مقاوم هستند. تیم‌هایی که آن را نادیده می‌گیرند، با شکاف‌های امنیتی مواجه می‌شوند. اگر با استانداردهای امنیت وب آشنا شده باشید، این رویکرد را به‌عنوان یک اصل مهندسی می‌شناسید.

اگر این تجربه را در یک پروژه واقعی داشته‌اید، جالب است بدانید کدام قانون ModSecurity بیشترین تأثیر را در دفع حملات داشت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🔒