Rate limiting: brute force ও credential stuffing প্রতিরক্ষা

আক্রমণকারী যা স্বয়ংক্রিয়ভাবে চেষ্টা করতে পারে তা হাজার হাজার বার করবে: পাসওয়ার্ড, one-time code, কুপন কোড, reset token, API endpoint। Rate limiting নিয়ন্ত্রণ করে একজন client কত ঘন ঘন কিছু করতে পারে, ফলে অপব্যবহার ধীর ও ব্যয়বহুল হয় অথচ স্বাভাবিক ব্যবহারকারী প্রভাবিত হয় না। এটি দুর্ঘটনাজনিত অতিরিক্ত চাপ ও ছুটে যাওয়া script থেকেও রক্ষা করে।

এটি সীমা ও সংশ্লিষ্ট নিয়ন্ত্রণ নকশার প্রতিরক্ষামূলক নির্দেশিকা।

হুমকি

• Brute force: একটি অ্যাকাউন্টে অনেক অনুমান (যেমন সব পাসওয়ার্ড বা সব ৬-অঙ্কের code)।
• Password spraying: অনেক অ্যাকাউন্টে কয়েকটি সাধারণ পাসওয়ার্ড, প্রতি-অ্যাকাউন্ট সীমার নিচে থেকে।
• Credential stuffing: অন্য সাইট থেকে ফাঁস হওয়া username ও পাসওয়ার্ড জোড়া ব্যবহার, কারণ অনেকে পাসওয়ার্ড পুনর্ব্যবহার করে। প্রায়ই বড় botnet ও অনেক IP ঠিকানায় করা হয়।
• Enumeration: ভিন্ন উত্তর থেকে কোন email বা username আছে তা আবিষ্কার।
• ব্যয়বহুল endpoint-এর অপব্যবহার: search, export, পাসওয়ার্ড reset email, SMS পাঠানো (যাতে টাকা লাগে) এবং ভারী API কল।
• অতিরিক্ত request থেকে denial of service।

Rate limiting algorithm

• Fixed window: প্রতি সময় window-এ N টি request অনুমতি (যেমন মিনিটে ১০০)। সরল, কিন্তু window সীমানায় burst সীমার দ্বিগুণ পর্যন্ত অনুমতি দিতে পারে।
• Sliding window: চলমান সময়ে request গোনে, মসৃণ ও ন্যায্যতর।
• Token bucket: একটি bucket স্থির হারে ভরতে থাকা token রাখে। প্রতিটি request একটি token নেয়। এটি গড় হার বজায় রেখে ছোট burst অনুমতি দেয়, এবং ব্যাপক ব্যবহৃত।
• Leaky bucket: request স্থির হারে প্রক্রিয়া হয়, burst মসৃণ করে।
• Concurrency সীমা: একসাথে চলমান request-এর সংখ্যা সীমিত করে।

কয়েকটি server জুড়ে counter সামঞ্জস্যপূর্ণ রাখতে Redis-এর মতো ভাগ করা store সাধারণত ব্যবহৃত হয়। হালনাগাদ atomic করুন (যেমন Lua script বা মেয়াদসহ atomic increment) যাতে সমান্তরাল request পিছলে বেরিয়ে যেতে না পারে।

কীসের ভিত্তিতে সীমা

কোনো একক key যথেষ্ট নয়। কয়েকটি মেলান:

• IP ঠিকানা: সরল, কিন্তু অনেক ব্যবহারকারী একই IP ভাগ করতে পারে (অফিস, মোবাইল ক্যারিয়ার) এবং আক্রমণকারী IP বদলাতে পারে। বিশ্বস্ত proxy header থেকে আসল client IP ব্যবহার করুন, client জাল করতে পারে এমন মান নয়।
• অ্যাকাউন্ট বা username: অনেক IP থেকেও একটি লক্ষ্যের বিরুদ্ধে অনুমান সীমিত করে।
• Authenticated API-র জন্য API key বা user ID।
• অতিরিক্ত সংকেত হিসেবে device বা session fingerprint।
• Endpoint-নির্দিষ্ট সীমা: নিরীহ পড়ার চেয়ে login, পাসওয়ার্ড reset, OTP যাচাই ও SMS পাঠানোতে কড়া।

সীমায় পৌঁছালে সাড়া

• Retry-After header ও পরিষ্কার বার্তাসহ HTTP 429 Too Many Requests ফেরত দিন।
• দীর্ঘ স্থায়ী নয়, ক্রমবর্ধমান বিলম্ব (প্রতিটি ব্যর্থ চেষ্টায় বেশি অপেক্ষা) বা কয়েক মিনিটের অস্থায়ী lockout ব্যবহার করুন।
• সাবধান, কড়া অ্যাকাউন্ট lockout আক্রমণকারীকে ইচ্ছে করে আসল ব্যবহারকারীকে lock out করতে দেয় (denial of service)। নরম ব্যবস্থা পছন্দ করুন: ধীর করা, CAPTCHA চাওয়া, অচেনা device-এ বাড়তি যাচাই চাওয়া, অথচ পরিচিত device বা যাচাই করা reset পথ অনুমতি দেওয়া।
• সীমা নিয়ে আক্রমণকারীকে বেশি বিস্তারিত জানাবেন না। নিয়ম ও সীমা যুক্তিসঙ্গত রাখুন।

Login-নির্দিষ্ট সুরক্ষা

• সাধারণ error বার্তা: "email বা পাসওয়ার্ড ভুল", অচেনা ব্যবহারকারী ও ভুল পাসওয়ার্ডে একই। সাড়ার সময় সমান রাখুন, কারণ সময়ের পার্থক্যও কোন অ্যাকাউন্ট আছে ফাঁস করতে পারে।
• IP ও অ্যাকাউন্ট দুটিতেই সীমা প্রয়োগ করুন, এবং একটি IP অনেক username চেষ্টা করছে এমন ধরনের ওপর নজর রাখুন।
• Multi-factor authentication (MFA) credential stuffing-এর বিরুদ্ধে সবচেয়ে শক্ত প্রতিরক্ষা, কারণ শুধু চুরি যাওয়া পাসওয়ার্ড আর কাজ করে না। সম্ভব হলে SMS-এর বদলে authenticator অ্যাপ, security key বা passkey পছন্দ করুন।
• ব্যবহারকারী পাসওয়ার্ড সেট করার সময় জানা ফাঁস হওয়া তালিকার বিরুদ্ধে যাচাই করুন, এবং প্রকাশিত পাসওয়ার্ডের অ্যাকাউন্টে alert বা reset বাধ্য করুন।
• শক্ত password hashing ব্যবহার করুন (পাসওয়ার্ড সংরক্ষণ লেখা দেখুন) যাতে database ফাঁস কম কাজে লাগে।
• নতুন-device login ও সন্দেহজনক চেষ্টায় ব্যবহারকারীকে জানান।
• ঝুঁকি-ভিত্তিক authentication ভাবুন: device, অবস্থান বা আচরণ অস্বাভাবিক হলে বাড়তি প্রমাণ চান।

CAPTCHA ও bot ব্যবস্থাপনা

• CAPTCHA বা challenge স্বয়ংক্রিয় আক্রমণ ধীর করতে পারে, সবার জন্য নয়, সন্দেহজনক আচরণের পর ব্যবহার সবচেয়ে ভালো, কারণ এটি ব্যবহারযোগ্যতা ও accessibility ক্ষতি করে।
• Bot ব্যবস্থাপনা সেবা (প্রায়ই CDN বা WAF-এর অংশ) সুনাম, আচরণ ও fingerprint দিয়ে traffic ছাঁকে এবং জানা খারাপ network আটকাতে পারে।
• কোনো একক challenge নিখুঁত নয়, কারণ আক্রমণকারী সমাধান সেবা ব্যবহার করতে পারে, তাই নিয়ন্ত্রণ স্তরে স্তরে সাজান।

OTP ও reset token সুরক্ষা

• One-time code-এর যাচাই চেষ্টা সীমিত করুন। ৬-অঙ্কের code-এর সম্ভাবনা মাত্র দশ লাখ, তাই সীমা ছাড়া brute force করা যায়।
• Code ও reset token স্বল্পস্থায়ী, একবার-ব্যবহারযোগ্য ও এলোমেলো করুন।
• খরচের অপব্যবহার ও শিকারকে হয়রানি ঠেকাতে SMS ও email পাঠানোর rate limit দিন।
• নতুন code দিলে আগেরগুলো অকার্যকর করুন।

ব্যয়বহুল ও সংবেদনশীল endpoint সুরক্ষা

• Search, export, ফাইল প্রক্রিয়া এবং পেমেন্ট সেবা ডাকে এমন সবকিছুতে কড়া সীমা।
• Request আকার ও timeout সীমা, pagination সর্বোচ্চ ও query জটিলতার সীমা।
• API-তে প্ল্যান বা ব্যবহারকারী অনুযায়ী কোটা (দৈনিক বা মাসিক), সাথে স্বল্পমেয়াদী rate limit।
• ভারী কাজ queue-তে রেখে asynchronous প্রক্রিয়া করুন।

সঠিক স্তরে সীমা বসান

• Edge (CDN, WAF, API gateway): আপনার server-এ পৌঁছানোর আগেই flood ও স্পষ্ট bot-কে স্থূল, আগাম ছাঁকা।
• Application: ব্যবহারকারী, অ্যাকাউন্ট ও business যুক্তি বোঝা সূক্ষ্ম নিয়ম (যেমন প্রতি-অ্যাকাউন্ট login চেষ্টা)।
• দুই স্তর একসাথে সবচেয়ে ভালো কাজ করে।

Monitoring ও শনাক্তকরণ

• IP, অ্যাকাউন্ট, user agent ও endpoint সহ ব্যর্থ login, lockout ও rate-limit hit log করুন (পাসওয়ার্ড log না করে)।
• Spike-এ alert দিন: ব্যর্থ login হার, এক IP থেকে অনেক অ্যাকাউন্ট বা উল্টোটা, অস্বাভাবিক পরিমাণে নতুন-device login, বেশি 429 সংখ্যা।
• ঘটনার পর log পর্যালোচনা করুন এবং সীমা টিউন করুন। বেশি কড়া হলে আসল ব্যবহারকারীর ক্ষতি, বেশি শিথিল হলে কিছুই হয় না। বাস্তবসম্মত traffic দিয়ে পরীক্ষা করুন।

সাধারণ ভুল

• X-Forwarded-For header আপনার নিজের proxy থেকে আসছে যাচাই না করে বিশ্বাস, ফলে আক্রমণকারী IP জাল করে সীমা এড়ায়।
• শুধু IP বা শুধু অ্যাকাউন্ট দিয়ে সীমা।
• Atomic নয় এমন counter, বা load balancer-এর পেছনে একটি server-এর memory-তে রাখা।
• ভিন্ন error বার্তা যা বৈধ অ্যাকাউন্ট প্রকাশ করে।
• স্থায়ী কড়া lockout যা আক্রমণকারী অপব্যবহার করতে পারে।
• OTP যাচাই বা পাসওয়ার্ড reset অনুরোধে সীমা না থাকা।
• Monitoring না থাকা, ফলে আক্রমণ অলক্ষ্যে যায়।

Checklist

১. Login, reset, OTP ও signup endpoint IP ও অ্যাকাউন্ট দিয়ে সীমিত করুন। ২. Atomic ভাগ করা store-সহ token bucket বা sliding window ব্যবহার করুন। ৩. Retry-After-সহ 429 ফেরত দিন, এবং নরম, অস্থায়ী শাস্তি ব্যবহার করুন। ৪. MFA দিন, ফাঁস হওয়া পাসওয়ার্ড যাচাই করুন, নতুন device-এ জানান। ৫. সন্দেহজনক কার্যকলাপের পর CAPTCHA বা challenge যোগ করুন। ৬. OTP চেষ্টা সীমিত করুন এবং SMS ও email পাঠানোর rate limit দিন। ৭. ব্যয়বহুল endpoint কোটা দিয়ে সুরক্ষিত করুন। ৮. Log, alert ও টিউন করুন।

মূল কথা: ধরে নিন স্বয়ংক্রিয় অনুমান ঘটবে। IP ও অ্যাকাউন্টের rate limit, MFA, ফাঁস হওয়া পাসওয়ার্ড যাচাই, নরম lockout, bot নিয়ন্ত্রণ ও monitoring মিলিয়ে আক্রমণ ধীর, গোলমেলে ও অলাভজনক করুন।

---

ওয়েব নিরাপত্তা সিরিজ, পর্ব ৩ (অ্যাকাউন্ট ও প্রতিরক্ষা): 5 নম্বর (মোট 5)। আগের লেখা: Dependency ও supply chain নিরাপত্তা: package থেকে অ্যাপ রক্ষা.