একজন SaaS ডেভেলপার লক্ষ্য করলেন যে তার অ্যাকাউন্টের প্রতিটি ডোমেইনের জন্য Cloudflare-এর Bot Fight Mode চালু করার ফলে পুরো এক মাস API ট্রাফিক থমকে গিয়েছিল, যার ফলে তার পণ্যের অর্থপ্রদানকারী গ্রাহকরা মূল ফিচারগুলো ব্যবহার করতে পারছিলেন না।
সমস্যাটি সামনে আসে যখন ডেভেলপার ব্যবহারের মেট্রিক্সের (usage metrics) হঠাৎ স্থবিরতা লক্ষ্য করেন। নতুন সাইন-আপ আসছিল, কিন্তু সক্রিয় সেশন (active sessions) বাড়ছিল না। কয়েক সপ্তাহ কোড রিরাইট এবং ডিবাগিং করার পর দেখা গেল, একটি মাত্র সিকিউরিটি টগলই ছিল এর মূল কারণ: Cloudflare-এর Bot Fight Mode ওই SaaS-এর নিজস্ব AWS Lambda এন্ডপয়েন্টকে একটি ক্ষতিকারক বট হিসেবে চিহ্নিত করছিল এবং তা ব্লক করে দিচ্ছিল।
কীভাবে একটি মাত্র সেটিংস পুরো সার্ভিসটি অচল করে দিল
ডেভেলপারের স্ট্যাকটি সার্ভার-টু-সার্ভার কলের ওপর নির্ভরশীল ছিল। একটি ইন্টারনাল Lambda ফাংশন নিয়মিতভাবে SaaS-এর পাবলিক ডোমেইনে ডেটা পাঠাত, যা আধুনিক মাইক্রো-সার্ভিস আর্কিটেকচারে একটি সাধারণ প্যাটার্ন। Bot Fight Mode এমন সব রিকোয়েস্টকে চ্যালেঞ্জ করে বা ব্লক করে যা দেখতে অটোমেটেড স্ক্র্যাপারের মতো, যা কন্টেন্ট-চালিত সাইটগুলোকে ডেটা হার্ভেস্টিং থেকে রক্ষা করে।
যখন সব জোনে (zones) এই মোডটি চালু করা হয়েছিল, Cloudflare ওই Lambda-র আউটবাউন্ড রিকোয়েস্টকে অন্য একটি অটোমেটেড ক্লায়েন্ট হিসেবে গণ্য করেছিল। রিকোয়েস্টটি কখনোই অ্যাপ্লিকেশনে পৌঁছাতে পারেনি, এবং যেহেতু ব্লকটি এজ (edge) লেভেলে ঘটেছিল, তাই SaaS-এর মনিটরিং টুলগুলো কোনো এরর (error) দেখতে পায়নি – ট্রাফিকটি স্রেফ অদৃশ্য হয়ে গিয়েছিল। Cloudflare Workers-এ ডেভেলপারের CPU ব্যবহার হঠাৎ বেড়ে যায়, যা তাকে তার নিজস্ব ব্যাকএন্ডের পরিবর্তে একটি এক্সটারনাল স্ক্র্যাপারের কথা সন্দেহ করতে বাধ্য করে।
Cloudflare-এর লগগুলো গভীরভাবে পরীক্ষা করার পরেই তিনি দেখতে পান যে, “Bot Fight Mode” সেই সব এন্ট্রি ব্লক করেছে যা Lambda-র IP রেঞ্জের সাথে মিলে যাচ্ছিল। তিনি আক্রান্ত জোনে ফিচারটি বন্ধ করে দেন এবং API ট্রাফিক পুনরায় শুরু হয়, যার ফলে ব্যবহারের মেট্রিক্স আবার স্বাভাবিক অবস্থায় ফিরে আসে।
কেন এই ভুলটি SaaS অপারেটরদের জন্য গুরুত্বপূর্ণ
- API-কেন্দ্রিক পণ্যের জন্য উন্মুক্ত সার্ভার-টু-সার্ভার চ্যানেল প্রয়োজন। Bot Fight Mode ধরে নেয় যে প্রাথমিক ট্রাফিক হলো HTML, ছবি বা স্ট্যাটিক অ্যাসেটের জন্য মানুষের ব্রাউজার থেকে আসা রিকোয়েস্ট। যেসব SaaS প্ল্যাটফর্ম API, webhook বা ইন্টারনাল কলব্যাক প্রদান করে, সেগুলো অ্যাপ্লিকেশন লেয়ারে কোনো দৃশ্যমান এরর কোড না পৌঁছানোতেই থ্রটল (throttle) বা ব্লক হয়ে যেতে পারে।
- গ্লোবাল সিকিউরিটি সেটিংস খুব কমই সব ধরনের ওয়ার্কলোডের জন্য উপযুক্ত হয়। সব ডোমেইনে একটি মাত্র Cloudflare কনফিগারেশন প্রয়োগ করা মানে প্রতিটি সাইটকে একই থ্রেট মডেলের অংশ হিসেবে বিবেচনা করা। কন্টেন্ট সাইট, ফোরাম এবং SaaS ব্যাক-এন্ডের সিকিউরিটি রিকোয়ারমেন্ট বা নিরাপত্তা প্রয়োজনীয়তা সম্পূর্ণ ভিন্ন হয়।
- নীরব ব্যর্থতা (Silent failures) রাজস্ব কমিয়ে দেয়। ডেভেলপারের অ্যালার্ট সিস্টেমটি কাজ করেনি কারণ ব্লক করা রিকোয়েস্টগুলো কখনোই অ্যাপ্লিকেশনে পৌঁছাতে পারেনি। শুধুমাত্র ইউজার-এনগেজমেন্ট মেট্রিক্সের পতন সমস্যাটির ইঙ্গিত দিয়েছিল। প্রোঅ্যাক্টিভ এজ-লেভেল লগ রিভিউ না করলে এই ধরনের সমস্যাগুলো অলক্ষিত অবস্থায় থেকে যেতে পারে।
একই ভাগ্য এড়াতে ডেভেলপাররা যা করতে পারেন
- প্রতিটি জোনের ট্রাফিক প্রোফাইল অডিট করুন। Bot Fight Mode চালু করার আগে আপনার ডোমেইন কোন ধরনের রিকোয়েস্ট আশা করে তার একটি তালিকা তৈরি করুন: মানুষের ব্রাউজার, API কল, webhook কলব্যাক বা ইন্টারনাল সার্ভিস কল। যদি এগুলোর কোনোটিই মূল কার্যকারিতার জন্য অপরিহার্য হয়, তবে সেই জোনে “API-first” পদ্ধতি অনুসরণ করুন এবং বট-মিটিগেশন সেটিংস ন্যূনতম রাখুন।
- একটি স্টেজেড এনভায়রনমেন্টে (staged environment) পরিবর্তনগুলো পরীক্ষা করুন। Cloudflare আপনাকে একটি মাত্র সাবডোমেইন বা একটি স্টেজিং জোনে সেটিংস প্রয়োগ করার সুযোগ দেয়। পরিবর্তনটি গ্লোবালি চালু করার আগে নিশ্চিত হয়ে নিন যে বৈধ অটোমেশনগুলো এখনও কাজ করছে কি না।
- আপনার অবজারভেবিলিটি স্ট্যাকের (observability stack) অংশ হিসেবে এজ-লেভেল লগ মনিটর করুন। Cloudflare-এর ফায়ারওয়াল এবং বট-মিটিগেশন লগগুলো কোনো SIEM, Loki বা যেকোনো অ্যাগ্রিগেশন সার্ভিসে স্ট্রিম করুন। নীরব ব্যর্থতাগুলো দ্রুত শনাক্ত করতে ব্লক করা রিকোয়েস্টের বৃদ্ধি এবং অ্যাপ্লিকেশন মেট্রিক্সের পতনকে একে অপরের সাথে মিলিয়ে দেখুন।
- সিকিউরিটি সেটিংস পরিবর্তনযোগ্য বা রিভার্সিবল রাখুন। একটি ডকুমেন্ট করা রোলব্যাক প্ল্যান রাখুন। যদি কোনো নতুন রুল অপ্রত্যাশিত আচরণ তৈরি করে, তবে কোড নিয়ে কাজ করার আগে সেটি প্রথমে ডিজেবল করুন এবং পরিবর্তনটি নিশ্চিত করুন।
- সঠিক প্রশ্ন করুন। “কীভাবে আমি স্ক্র্যাপারদের থামাতে পারি?” তা জিজ্ঞাসা করার পরিবর্তে জিজ্ঞাসা করুন, “এই টুলটি কি আমার দেখা নির্দিষ্ট সমস্যাটি সমাধান করছে?” একটি সিকিউরিটি ফিচার যা স্ক্র্যাপারদের ব্লক করে, তা এমন একটি SaaS-এর জন্য সঠিক সমাধান নাও হতে পারে যার ওপেন API অ্যাক্সেস প্রয়োজন।
বৃহত্তর প্রেক্ষাপট
যেসব সাইটের আক্রমণাত্মক ক্রলার থেকে স্ট্যাটিক কন্টেন্ট রক্ষা করা প্রয়োজন, তাদের জন্য Bot Fight Mode এখনও মূল্যবান। এর অসুবিধা হলো, এটি একটি ক্ষতিকারক স্ক্র্যাপার এবং একই HTTP প্যাটার্ন অনুসরণকারী একটি বৈধ অটোমেটেড ক্লায়েন্টের মধ্যে পার্থক্য করতে পারে না।
সারসংক্ষেপ
যখন আপনি একটি মাত্র Cloudflare অ্যাকাউন্টের অধীনে একাধিক ডোমেইন পরিচালনা করেন, তখন প্রতিটি ডোমেইনকে একটি স্বতন্ত্র সিকিউরিটি জোন হিসেবে বিবেচনা করুন। Bot Fight Mode শুধুমাত্র সেখানেই চালু করুন যেখানে ট্রাফিক সম্পূর্ণভাবে মানুষের দ্বারা চালিত; API-নির্ভর SaaS ওয়ার্কলোডের জন্য সেটিংসটি বন্ধ রাখুন অথবা কাস্টম ফায়ারওয়াল রুল দিয়ে সূক্ষ্মভাবে টিউন (fine-tune) করুন। একটি মাত্র ক্লিক স্ক্র্যাপার থামানোর মতোই কার্যকরভাবে বৈধ ট্রাফিককেও স্তব্ধ করে দিতে পারে।