ওয়েবের পাবলিক সার্ভিসে আক্রমণকারীদের বিরুদ্ধে মৌলিক প্রতিরক্ষা ব্যবস্থা মূলত নেই

হ্যালো, আমি অযোগ্য।

সাম্প্রতিক সময়ে আক্রমণ বেশ বেড়েছে, তাই যা মনে আসে তা-ই লিখে ফেলছি।

HTTP ক্লায়েন্ট থেকে আসা আক্রমণ ঠেকানোর কোনো মৌলিক উপায় নেই

প্রথমেই, প্রতিটি প্রতিরক্ষা ব্যবস্থা বিবেচনা করে দেখি।

IP ঠিকানা

IPv6 ঠিকানা হলে ভালো, কিন্তু CGNAT পরিবেশে শেয়ার করা IPv4 ঠিকানা বরাদ্দ হয়, ফলে আক্রমণের লক্ষ্যবস্তু ছাড়াও অন্য ভুক্তভোগীরাও এর শিকার হন।
এ ছাড়া, IP রোটেশন করা সহজ। তাই ইদানীং আক্রমণের জন্য বেশি ব্যবহৃত, বিশ্বজুড়ে বিপুল সংখ্যক IP থাকা যুক্তরাষ্ট্রের সস্তা VPS বা চীনা ক্লাউড পরিবেশ থেকে হাজার হাজার IP ঠিকানা জোগাড় করে DDoS চালানোও সাধারণ হয়ে উঠেছে। AS Number-ভিত্তিতে ব্লক করলেও, চীনে কার্যক্রম চালানো পরিষেবা থাকলে চীনা ক্লাউডের IP ঠিকানা ব্লক করা যে মৌলিক সমাধান নয়, তা স্পষ্ট; এতে চীনা ব্যবহারকারীদেরও একটু মায়া লাগে।
মূলত, চীনের ক্লাউড পরিবেশ অন্য দেশ থেকে অপব্যবহারের শিকার হয় খুব বেশি, তাই আমি মনে করি না যে সেগুলোকে নির্বিচারে ব্লক করা উচিত।

আমার মূল ধারণা হলো, কোনো পরিষেবা যদি ওয়ার্ল্ড ওয়াইড ওয়েবের অংশ হয়, আর সেই পরিষেবাটি উপভোগ করেন এমন একজন মানুষও থাকেন, তাহলে আমি নির্বিচারে সেটি ব্লক করতে চাই না।
আমিও মাঝে মাঝে BiliBili-র ভিডিও দেখি, আর যুক্তরাষ্ট্রের পরিষেবাও দেখি।

User-Agent

মূলত, এটি বিবেচনাতেই আসে না; অনুরোধের হেডার যাচাইকে অ্যাক্সেস সীমাবদ্ধতার মানদণ্ড হিসেবে ব্যবহার করাকে প্রায় অর্থহীন মনে করি, তাই এ নিয়ে বেশি কিছু বলার নেই।
যেকোনো কিছু ছদ্মবেশে দেখানো যায়, তাই শুধু UA দেখে ব্লক করা যায় না।
যদি কিছু করতেই হয়, তাহলে আমি এখন এই সাইটে যেমন করছি, googlebot হিসেবে UA দাবি করা কোনো অনুরোধের বিপরীত DNS হোস্ট যদি *.googlebot.com অথবা *.google.com না হয়, তাহলে পুরোপুরি ব্লক করা যেতে পারে। তবে এটি নিজে বাস্তবায়ন করতে হবে, নাকি CDN-এ এরকম কোনো ব্যবস্থা আগে থেকেই আছে—তা যাচাই করা দরকার। তাছাড়া, Google আনুষ্ঠানিকভাবে এমনটাই বললেও, কিছু আসল bot Google এমন হোস্ট থেকেও পাঠায় যেগুলোর বিপরীত DNS হোস্ট এসবের মধ্যে পড়ে না। তাই শুধু এই যাচাইয়ের ওপর নির্ভর করে পুরোপুরি সিদ্ধান্ত নেওয়া যায় না।

প্রসঙ্গত, এই রকম নগণ্য সাইটেও নিজেদের Googlebot বলে পরিচয় দেওয়া লোকজনের সংখ্যা এতটাই:
fail2ban report - fake-googlebot

দেশ ব্লক করা

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

TLS Fingerprint

TLS ফিঙ্গারপ্রিন্টও সহজেই জাল করা সম্ভব।
কেন? HTTP ক্লায়েন্টে ব্রাউজারে ব্যবহৃত একই ধরনের ক্রিপ্টোগ্রাফিক লাইব্রেরি যুক্ত করলেই ব্রাউজারের ফিঙ্গারপ্রিন্ট জাল করা যায়।
এটি একেবারেই অকার্যকর—এমনটা বলা কঠিন। তবে, উদাহরণস্বরূপ, একই ক্রিপ্টোগ্রাফিক লাইব্রেরি ব্যবহার করে কোনো বৈধ bot অনুরোধ পাঠালে সেটি ভুল করে ব্লক হয়ে যেতে পারে।
অনেক HTTP ক্লায়েন্টের সঙ্গে ফিঙ্গারপ্রিন্ট মিলে যাওয়ার ঝুঁকি বেশি, তাই সরলভাবে এর ভিত্তিতে সিদ্ধান্ত নেওয়া যায় না।
সুতরাং, এটি একটি সিদ্ধান্তের মানদণ্ড হিসেবে ব্যবহার করা যেতে পারে; একমাত্র শর্ত হিসেবে না রেখে অন্যান্য নিয়মের সঙ্গে মিলিয়ে বিবেচনা করলে কিছুটা উপকার হতে পারে।

Cloudlfare Challenge / PoW Challenge

Cloudflare Challenge হেডলেস ব্রাউজার ব্যবহার না করেও সহজেই পাশ কাটানো যায়।
Anubis সম্পর্কে নিশ্চিত নই, তবে UX খুব একটা ভালো নয়; ক্লায়েন্ট-সাইডে হিসাব করতে হয়, আর পৃষ্ঠা বদলানোর সময় বেশ বিরক্তিকর লাগে।
এক অর্থে, এটি JS Challenge-এর সঙ্গে মিলিয়ে কিছুটা সুরক্ষা দিতে পারে। বাস্তবে, সাম্প্রতিক সময়ে ফাঁস হওয়া বিভিন্ন ফোরামেও নিজস্বভাবে তৈরি PoW Challenge ব্যবহারের ঘটনা বাড়ছে। তাই কোথায় PoW Challenge ব্যবহার করা হবে—বা DoS ঠেকানোর জন্য অ্যাপ্লিকেশন স্তরের কাছাকাছি এই PoW Challenge দিয়ে সুরক্ষা দেওয়া উচিত কি না—তা বলা কঠিন। ব্যবহারের ক্ষেত্র অনেকটা সীমিত করে বাস্তবায়ন করলে, UX যতটা সম্ভব অক্ষুণ্ণ রেখে তুলনামূলকভাবে সুরক্ষামূলক ফ্রন্টএন্ড ব্যবস্থা করা যেতে পারে।

Pay Wall

যেসব পরিষেবায় পে-ওয়াল দরকার, সেগুলো সীমিত—তাই বাদ দিলাম।

HTTP ক্যাশ

এই বিষয়টি আদৌ এই নিবন্ধে রাখব কি না, তা নিয়ে একটু দ্বিধায় ছিলাম, তবু রেখেছি।
CDN-এ ক্যাশ করে Origin পর্যন্ত পৌঁছানোর অনুরোধ কমানোর দিক থেকে GET ইত্যাদির ক্ষেত্রে এটি কাজে লাগতে পারে, তবে আমার ধারণা এখন প্রায় সব জায়গাতেই এটি চালু আছে।
এটিকে সুরক্ষা হিসেবে না ভেবে, ব্যবহারকারীর অভিজ্ঞতা উন্নত করা এবং ত্রুটি-সংক্রান্ত প্রতিক্রিয়া পাঠানোর সময় ফ্লাড ঠেকানোর দিক থেকে উপকারী বলে বিবেচনা করা ভালো। অ্যাপকে প্রভাবিত না করে পারফরম্যান্স উন্নত করার জন্য এটি ব্যবহার করাই উচিত বলে মনে হয়।

রেট সীমাবদ্ধতা

পরিষেবা অনুযায়ী key নিজেই বেশ আলাদা হয়, তাই বাস্তবায়নের নিয়ম ভালো করে যাচাই করা উচিত। শুধু Nginx-এর ক্ষেত্রে বললে, সামগ্রিক ট্র্যাফিক, URI, IP ঠিকানা—এমনকি এগুলোর সমন্বয়ের ভিত্তিতেও সীমাবদ্ধতা দেওয়া যায়। তাই DoS প্রতিরোধের দৃষ্টিকোণ থেকে এটি উপকারী বলে মনে করি।

তাহলে কী করা উচিত?

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

• .env ইত্যাদি স্ক্যান করেছে এমন IP

• নিজেকে googlebot বলে দাবি করে, কিন্তু নিশ্চিতভাবেই অস্বাভাবিক এমন কিছু

• POST/PUT ইত্যাদির মাধ্যমে অসম্ভব ধরনের অনুরোধ পাঠায়

• /login-এর অধীন কোনো পথ, বা সেশন তৈরি করা যায় এমন পথে উদ্ভট অনুরোধ পাঠায়

এ ধরনের ক্ষেত্রে একবারেই ব্লক করলেও চলে, তাই না? সত্যি বলতে, সস্তা VPS-গুলো অনেক ক্ষেত্রেই অপব্যবহৃত হয় বলে সব একসঙ্গে ব্লক করতে ইচ্ছে করে। তবে আমিও সস্তা VPS-এ VPN সার্ভার চালিয়ে তার এক্সিট IP থেকে বেশ প্রায়ই সাইট দেখি, তাই মনে হয় হয়তো একটু বাড়াবাড়ি হবে—যদিও কিছু পরিষেবার ক্ষেত্রে এটি ঠিকও হতে পারে।

এ ছাড়া, সাম্প্রতিক সময়ে অডিও ডিভাইস শনাক্তকরণে ফিঙ্গারপ্রিন্ট ব্যবহারের সমালোচনা হয়েছে, কিন্তু আমার মতে এটি আসলে উপকারী। শনাক্ত করতে না পারলে ব্লক করা বেশ যুক্তিসংগত হতে পারে। কোনো একসময় জাল করার পথ বের হবে ঠিকই, তবে...
GPU Fingerprint বা Audio Finderprint-এর মতো জিনিসগুলো ভবিষ্যতে ব্যবহারকারীর ডিভাইস শনাক্ত করতে একত্রে ব্যবহৃত হবে—এমন সম্ভাবনাও আছে।