OWASP CRS নিয়ম-সেটসহ ModSecurity দশ মিনিটে চালু হয় আর তিন দিন পরে বন্ধ করে দেওয়া হয় — যখন অ্যাডমিন এলাকায় লেখা সংরক্ষিত হওয়া বন্ধ হয়, ফাইল আপলোড ভেঙে যায়, আর ক্রেতা অর্ডার দিতে পারে না কারণ তার ঠিকানায় একটা অ্যাপস্ট্রফি ছিল। «WAF কাজে বাধা দেয়» সিদ্ধান্তটা আপনাআপনি আসে, আর সেটা ভুল: ওই আটকানোগুলোর প্রায় সবই তিন-চারটি নিখুঁত ছাড় দিয়ে সেরে যায়, আর পুরো কারিগরি হলো সেগুলো ঠিকভাবে খুঁজে বের করা।

অবরোধ সঙ্গে সঙ্গে চালু করবেন না

প্রথম সপ্তাহ কেবল পর্যবেক্ষণের। /etc/modsecurity/modsecurity.conf-এ:

SecRuleEngine DetectionOnly

এই মোডে WAF যা আটকাত তার সবই লগ করে আর কিছুই আটকায় না। বাস্তব ট্রাফিকের এক সপ্তাহ — অ্যাডমিন এলাকায় নিজের কাজ, ছবি আপলোড ও অর্ডার দেওয়াসহ — কাল্পনিক নয়, সত্যিকারের মিথ্যা ফলের তালিকা দেয়। ওই তালিকা সামলানোর পরেই On-এ যাওয়ার মানে হয়।

CRS কীভাবে কাজ করে: একটি নিয়ম নয়, যোগফল

পরের সবকিছুর চাবিকাঠি এটাই। CRS কোনো অনুরোধকে প্রায় কখনও একটিমাত্র নিয়ম দিয়ে আটকায় না। চালু হওয়া প্রতিটি নিয়ম অনুরোধে অস্বাভাবিকতার পয়েন্ট যোগ করে, আর অবরোধ ঘটে যখন মোট একটা সীমা ছাড়ায়। সেজন্যই লগে একটা নয়, কয়েকটা লাইন দেখা যায়, আর তাদের শেষটি হলো 949110 শনাক্তকারীর নিয়ম — যেটি মোট যোগ করে।

ব্যবহারিক ফলাফল: ছাড় দিতে হবে সেই নিয়মের জন্য যেটি পয়েন্ট যোগ করেছে, 949110-এর জন্য নয়। যোগ করা নিয়মটি বন্ধ করলে পুরো সেটই বন্ধ হয়ে যায়, আর WAF কনফিগ ফাইলের একটা লাইন হয়ে থাকে।

দ্বিতীয় ফলাফল হলো paranoia স্তর। ডিফল্টে সেটি এক, আর এটাই সঠিক পছন্দ। স্তর 2 ও 3 এমন নিয়ম যোগ করে যেগুলো সাধারণ সাইটে নকশা অনুযায়ীই মিথ্যা ফল দেয়, আর সেগুলো চালু করার মানে হয় কেবল প্রথম স্তর পুরোপুরি সাজানোর পরে।

দোষী নিয়ম খুঁজে বের করুন

যা দরকার তার সবই audit লগে (/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 injection। লম্বা বিষয়বস্তুসহ পাঠ্য ক্ষেত্রে চালু হয়: লেখার মূল অংশ, পণ্যের বিবরণ, মন্তব্য। সাধারণ গদ্যের ভেতরে উদ্ধরণ চিহ্ন, বন্ধনী আর 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 injection-এর জন্য যাচাই হওয়া বন্ধ হয়; দ্বিতীয় ও তৃতীয়টিতে পুরো সাইট যাচাই হওয়া বন্ধ হয়। পরিশ্রমের পার্থক্য প্রায় পাঁচ মিনিটের।

সম্পাদনার পরে কনফিগারেশন যাচাই করুন আর নরমভাবে পুনরায় লোড করুন:

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

যে ক্রম এক সপ্তাহ বাঁচায়

  1. DetectionOnly-তে এক সপ্তাহ, সাইট, অ্যাডমিন এলাকা ও আপলোডসহ স্বাভাবিক কাজের সঙ্গে।
  2. audit লগ থেকে নিয়মের কম্পাঙ্ক তালিকা। উপর থেকে নিচে চলুন — প্রথম তিন-চারটিই নব্বই শতাংশ কোলাহলের জন্য দায়ী।
  3. প্রতিটির জন্য: বুঝে নিন কোন প্যারামিটার আর কোন পাতায়। ছাড় দিন প্যারামিটার ধরে, নিয়ম ধরে নয়।
  4. এবং কেবল এখন SecRuleEngine On।
  5. মাসে একবার আটকানোগুলোতে উঁকি দিন: সাইট বদলেছে, তাই নতুন মিথ্যা ফল এসেছে।

শেষ বিন্দুতেই সাধারণত সব ভেঙে পড়ে: audit লগ গিগাবাইটের পাঠ্য আর সেটা হাতে কেউ পড়বে না। একত্র করা প্যানেলের মানে ঠিক এটাই যে চালু হওয়া নিয়মের তালিকা, আটকানো অনুরোধ আর সক্রিয় নিয়ম-সেট আপনার সামনে থাকুক, grep দিয়ে বের করা না হোক। সেটা কেমন দেখায় তা নিচের ডেমো পাতায়।