OWASP CRS قواعد کے مجموعے کے ساتھ ModSecurity دس منٹ میں فعال ہوتا ہے اور تین دن بعد بند کر دیا جاتا ہے — جب انتظامی حصے میں مضامین محفوظ ہونا بند ہو جائیں، فائلوں کا اپ لوڈ ٹوٹ جائے، اور کوئی گاہک اس لیے آرڈر نہ دے سکے کہ اس کے پتے میں واوین آ گیا تھا۔ «ویب ایپلیکیشن فائروال کام میں رکاوٹ ہے» کا نتیجہ خودبخود سامنے آتا ہے، اور وہ غلط ہے: یہ تقریباً تمام رکاوٹیں تین چار درست استثناؤں سے حل ہو جاتی ہیں، اور سارا ہنر انہیں ٹھیک ٹھیک ڈھونڈنے میں ہے۔

روکنا فوراً فعال نہ کریں

پہلا ہفتہ صرف مشاہدہ ہے۔ /etc/modsecurity/modsecurity.conf میں:

SecRuleEngine DetectionOnly

اس وضع میں فائروال ہر وہ چیز درج کرتا ہے جسے وہ روکتا اور کچھ بھی نہیں روکتا۔ اور ایک ہفتے کا حقیقی ٹریفک — بشمول آپ کا اپنا کام انتظامی حصے میں، تصویروں کا اپ لوڈ اور ایک آرڈر — فرضی نہیں بلکہ اصل جھوٹی اطلاعات کی فہرست دیتا ہے۔ On کی طرف جانا اسی وقت معنی رکھتا ہے جب یہ فہرست نمٹا لی جائے۔

CRS کیسے کام کرتا ہے: ایک قاعدہ نہیں بلکہ مجموعہ

یہی آگے کی ہر بات کی کنجی ہے۔ CRS تقریباً کبھی ایک قاعدے سے درخواست نہیں روکتا۔ ہر چلنے والا قاعدہ درخواست میں بے قاعدگی کے نکات جمع کرتا ہے، اور روک اُس وقت لگتی ہے جب مجموعہ ایک حد پار کر جائے۔ اسی لیے لاگ میں ایک نہیں بلکہ کئی سطریں ہوتی ہیں، اور اسی لیے ان میں آخری وہ قاعدہ ہوتا ہے جس کا شناخت کنندہ 949110 ہے — وہی جو مجموعہ لگاتا ہے۔

عملی نتیجہ: استثنا اُس قاعدے کے لیے بنانا چاہیے جس نے نکات دیے، نہ کہ 949110 کے لیے۔ اگر آپ مجموعہ لگانے والا قاعدہ بند کر دیں تو پورا مجموعہ بند ہو جائے گا اور فائروال محض ترتیبات کی فائل میں ایک سطر رہ جائے گا۔

دوسرا نتیجہ حساسیت کی سطح ہے۔ بطور طے شدہ یہ ایک ہے، اور یہی درست انتخاب ہے۔ سطح 2 اور 3 ایسے قواعد شامل کرتی ہیں جو عام سائٹوں پر اپنی ساخت ہی کی وجہ سے جھوٹی اطلاعات دیتی ہیں، اور انہیں تبھی فعال کرنا چاہیے جب پہلی سطح مکمل طور پر ترتیب پا چکی ہو۔

قصوروار قاعدہ ڈھونڈیں

ہر ضروری چیز آڈٹ لاگ (/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 سے نکالے جائیں۔ یہ کیسا لگتا ہے، نیچے ڈیمو صفحہ دکھاتا ہے۔