ModSecurity با مجموعه قواعد OWASP CRS در ده دقیقه فعال می‌شود و سه روز بعد خاموش — پس از آنکه مقاله‌ها در پنل مدیریت ذخیره نمی‌شوند، بارگذاری فایل خراب می‌شود، و مشتری‌ای نمی‌تواند سفارش ثبت کند چون در نشانی‌اش آپاستروف بوده است. نتیجه «دیوار آتش برنامه مانع کار است» خودبه‌خود پیش می‌آید و نادرست است: تقریباً همه این مسدودسازی‌ها با سه چهار استثنای دقیق درمان می‌شوند، و همه هنر در یافتن درست آن‌هاست.

مسدودسازی را بی‌درنگ فعال نکنید

هفته نخست تنها مشاهده است. در /etc/modsecurity/modsecurity.conf:

SecRuleEngine DetectionOnly

در این حالت دیوار آتش هر چیزی را که می‌بست ثبت می‌کند و چیزی را نمی‌بندد. و یک هفته ترافیک واقعی — همراه با کار خودتان در پنل مدیریت، بارگذاری تصویرها و ثبت یک سفارش — فهرستی از هشدارهای نادرست واقعی می‌دهد نه فرضی. گذر به On تنها پس از رسیدگی به آن فهرست معنا دارد.

CRS چگونه کار می‌کند: نه یک قاعده بلکه یک جمع

این کلید همه آن چیزی است که در پی می‌آید. CRS تقریباً هرگز درخواستی را با یک قاعده مسدود نمی‌کند. هر قاعده‌ای که فعال می‌شود به درخواست امتیاز ناهنجاری می‌افزاید، و مسدودسازی هنگامی رخ می‌دهد که جمع از آستانه بگذرد. به همین سبب گزارش نه یک سطر بلکه چند سطر نشان می‌دهد، و آخرینشان قاعده‌ای با شناسه 949110 است — همان که جمع را می‌بندد.

پیامد عملی: استثنا باید برای قاعده‌ای ساخته شود که امتیاز داده است، نه برای 949110. اگر قاعده جمع‌کننده را خاموش کنید تمام مجموعه را خاموش کرده‌اید و از دیوار آتش تنها سطری در یک فایل پیکربندی می‌ماند.

پیامد دوم سطح وسواس است. به‌صورت پیش‌فرض یک است، و همین گزینه درست است. سطح‌های ۲ و ۳ قواعدی می‌افزایند که بنا بر طراحی روی سایت‌های معمولی هشدار نادرست می‌سازند و تنها پس از تنظیم کامل سطح یک ارزش فعال‌شدن دارند.

قاعده مقصر را بیابید

هر آنچه نیاز دارید در گزارش ممیزی (/var/log/modsec_audit.log) و در گزارش خطای وب‌سرور است. بر پایه زمان مسدودسازی جست‌وجو کنید:

sudo grep -o 'id "[0-9]*"' /var/log/modsec_audit.log | sort | uniq -c | sort -rn | head

این فهرستی از بسامد قواعدی است که فعال شده‌اند. سپس برای شناسه‌ای مشخص ببینید دقیقاً چه چیزی آن را برانگیخته است:

sudo grep -A5 'id "942100"' /var/log/modsec_audit.log | head -40

سه چیز لازم است: شناسه قاعده، نام پارامتر (ARGS:content، ARGS:comment) و مسیر درخواست. استثنا از همین‌ها ساخته می‌شود.

مظنونان همیشگی

فهرست از سایتی به سایت دیگر تکرار می‌شود:

  • 942100 — تزریق SQL. روی میدان‌های متنی با محتوای بلند فعال می‌شود: متن مقاله، شرح محصول، دیدگاه. گیومه‌ها و پرانتزها و واژه‌هایی مانند select درون نثر معمولی برای آشکارساز مشکوک به نظر می‌رسند؛
  • 941100 و خانواده 941xxx — XSS. همراه با ویرایشگر دیداری می‌آیند: برچسب‌های HTML در یک میدان تمام معنای کار آن است؛
  • 920420 — Content-Type ناپذیرفته. APIها و بارگذاری فایل را خراب می‌کند: مجموعه پیش‌فرض گونه‌های مجاز تنگ است و در نسخه‌های قدیمی‌تر application/json در آن نبود؛
  • 913100 — پویشگر بر پایه User-Agent. ابزارهای مشروع را همراه پویشگرها می‌گیرد: پایش دسترس‌پذیری، و curl در اسکریپت‌های خودتان؛
  • 200002، 200004 — خطاهای تجزیه بدنه درخواست. معمولاً نه حمله بلکه گذشتن از حد اندازه بدنه را نشان می‌دهند، یعنی بارگذاری فایلی بزرگ.

سه راه ساختن استثنا

به ترتیب افزایش خشونت. همه آن‌ها به فایل خودتان می‌روند (برای نمونه /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES.conf) نه به خود فایل‌های CRS: مجموعه قواعد به‌روز می‌شود و ویرایش‌های شما همراه آن ناپدید خواهند شد.

یک پارامتر را از زیر یک قاعده بردارید. دقیق‌ترین گزینه و همان که باید به سویش رفت:

SecRuleUpdateTargetById 942100 "!ARGS:content"

قاعده را تنها روی یک مسیر خاموش کنید. درست وقتی صفحه‌ای مشخص سروصدا می‌کند — ویرایشگر، درون‌ریزی، فرم نظرسنجی:

SecRule REQUEST_URI "@beginsWith /admin/post" \
    "id:1001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"

قاعده را یکسره خاموش کنید. آخرین چاره و تقریباً همیشه نشانه آنکه علت هرگز یافته نشده است:

SecRuleRemoveById 942100

تفاوت میان نخست و سوم بنیادی است. در حالت نخست یک میدان — متن مقاله — از بررسی تزریق SQL با یک قاعده بیرون می‌ماند؛ در دوم و سوم کل سایت از بررسی بیرون می‌ماند. و تفاوت تلاش حدود پنج دقیقه است.

پس از ویرایش‌ها پیکربندی را بررسی کنید و به‌نرمی بارگذاری دوباره کنید:

sudo apachectl configtest && sudo systemctl reload apache2
sudo nginx -t && sudo systemctl reload nginx

ترتیبی که یک هفته صرفه‌جویی می‌کند

  1. یک هفته در DetectionOnly با کار عادی روی سایت، در پنل مدیریت و در بارگذاری‌ها.
  2. فهرست بسامد قواعد از گزارش ممیزی. از بالا به پایین کار کنید — سه چهار قاعده نخست نود درصد نویز را می‌سازند.
  3. برای هر یک: دریابید کدام پارامتر و در کدام صفحه. استثنا را بر پایه پارامتر بسازید نه بر پایه قاعده.
  4. و تنها اکنون SecRuleEngine On.
  5. ماهی یک‌بار به مسدودسازی‌ها سری بزنید: سایت تغییر کرده، پس هشدارهای نادرست تازه پیدا شده‌اند.

و کار معمولاً بر همین بند آخر فرو می‌ریزد: گزارش ممیزی گیگابایت‌ها متن است و کسی آن را با دست نخواهد خواند. معنای پنل گردآمده آن است که فهرست قواعد فعال‌شده، درخواست‌های مسدودشده و مجموعه قواعد فعال پیش چشمتان باشد نه اینکه با grep بیرون کشیده شوند. شکل این را صفحه نمایشی پایین نشان می‌دهد.