সার্ভিস এনুমারেশন ও ব্যানার গ্র্যাবিং

Service enumeration & banner grabbing

৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

Port scan (L12) শুধু বলে কোন পোর্ট খোলা; ব্যানার গ্র্যাবিং বলে ঠিক কোন সার্ভিস ও ভার্সন সেই পোর্টে চলছে।
একটি নির্দিষ্ট সফটওয়্যার ভার্সনের সাথে প্রায়ই পরিচিত CVE যুক্ত থাকে (L14, L16-এর ভিত্তি)।
ডিফেন্স সাইড: ব্যানার suppress/generic করা একটি hardening স্তর — কিন্তু patch করার বিকল্প নয়।
কোড সেল সম্পূর্ণ সিমুলেটেড ব্যানার ডেটা ব্যবহার করে — কোনো বাস্তব সকেট কানেকশন নেই।

এই পাঠে যা শিখবেন

ব্যানার গ্র্যাবিং কী এবং কেন এটি port scanning-এর পরের স্বাভাবিক ধাপ
কীভাবে একটি ব্যানার থেকে সফটওয়্যার নাম ও ভার্সন শনাক্ত করা যায়
কেন নির্দিষ্ট ভার্সন জানা attacker ও defender উভয়ের জন্যই গুরুত্বপূর্ণ
Banner suppression কেন "security through obscurity" — একটি স্তর মাত্র, সমাধান নয়

১ · Port Scanning থেকে Service Enumeration — পরের ধাপ

L12-এ আমরা দেখেছি একটি স্ক্যান শুধু বলে দেয় পোর্ট ২২ "open"। কিন্তু এটি জানায় না ঠিক কোন সফটওয়্যার সেখানে চলছে — OpenSSH নাকি অন্য কিছু, কোন ভার্সন। এই ফাঁক পূরণ করে ব্যানার গ্র্যাবিংBanner Grabbingএকটি open পোর্টে কানেক্ট করে সেই সার্ভিসের প্রাথমিক প্রতিক্রিয়া (ব্যানার) সংগ্রহ করা, যা প্রায়ই সফটওয়্যার নাম ও ভার্সন প্রকাশ করে। — একটি সার্ভিসের সাথে প্রাথমিক সংযোগ স্থাপন করে তার "self-introduction" পড়া। উদাহরণস্বরূপ, পোর্ট ২২-এ কানেক্ট করলে সার্ভিস নিজেই ফেরত পাঠাতে পারে "SSH-2.0-OpenSSH_7.4"-এর মতো একটি স্ট্রিং।

২ · ব্যানার কী প্রকাশ করে

বেশিরভাগ নেটওয়ার্ক সার্ভিস কানেকশনের শুরুতেই একটি সংক্ষিপ্ত পরিচয়মূলক বার্তা পাঠায় — এটিই ব্যানার। এতে সাধারণত থাকে সফটওয়্যারের নাম, ভার্সন, কখনো কখনো অপারেটিং সিস্টেমের তথ্যও।

কেন ভার্সন এত গুরুত্বপূর্ণ

নিরাপত্তা গবেষকরা পাবলিকলি নথিভুক্ত করেন কোন সফটওয়্যার ভার্সনে কোন CVE (L14-এ বিস্তারিত) আছে। "Apache চলছে" জানা যথেষ্ট নয় — কিন্তু "Apache 2.4.29 চলছে" জানা মানে সরাসরি সেই নির্দিষ্ট ভার্সনের পরিচিত দুর্বলতার তালিকা খুঁজে বের করা সম্ভব। এই কারণেই ব্যানার গ্র্যাবিং reconnaissance-এর এত মূল্যবান একটি ধাপ — এটি স্ক্যানিংকে "কী খোলা আছে" থেকে "কী দুর্বল হতে পারে" পর্যন্ত নিয়ে যায়।

৩ · হ্যান্ডস-অন: ব্যানার থেকে সম্ভাব্য দুর্বলতা শনাক্তকরণ

নিচের কোড সেলটি সম্পূর্ণ সিমুলেটেড — একটি ভুয়া dict পোর্ট-থেকে-ব্যানার ম্যাপিং হিসেবে কাজ করছে, এবং আরেকটি ভুয়া dict "known vulnerable" ব্যানার প্যাটার্নের একটি অতি-সরলীকৃত lookup টেবিল হিসেবে। এটি বাস্তব কোনো CVE ডেটাবেস বা নেটওয়ার্ক কানেকশন ব্যবহার করে না — শুধু ধারণাটি প্রদর্শন করছে।

Python

# সিমুলেটেড ব্যানার ডেটা — বাস্তব কোনো হোস্টে কানেক্ট করা হচ্ছে না
simulated_banners = {
    21: "vsftpd (toy-demo build)",
    22: "OpenSSH (toy-demo build)",
    80: "Apache (toy-demo build)",
    443: "nginx (toy-demo build)",
}

# টয় "vulnerability lookup" — বাস্তব CVE ডেটাবেসের অতি-সরলীকৃত, শিক্ষামূলক সংস্করণ
known_vulnerable_banners = {
    "vsftpd (toy-demo build)": "সিমুলেটেড-CVE-১ (ব্যাকডোর-ধরনের কমান্ড এক্সিকিউশন)",
    "Apache (toy-demo build)": "সিমুলেটেড-CVE-২ (পাথ ট্রাভার্সাল)",
}

def grab_banner(port):
    """সিমুলেটেড ব্যানার-গ্র্যাব — ইন-মেমরি dict থেকে রিড করে,
    বাস্তব সকেট কানেকশন নয়।"""
    return simulated_banners.get(port, "কোনো ব্যানার পাওয়া যায়নি")

print("সার্ভিস এনুমারেশন রিপোর্ট (সিমুলেটেড হোস্ট)")
print("-" * 55)
for port in simulated_banners:
    banner = grab_banner(port)
    print(f"পোর্ট {port:>4}  ->  {banner}")
    if banner in known_vulnerable_banners:
        print(f"           সতর্কতা: সম্ভাব্য পরিচিত দুর্বলতা - {known_vulnerable_banners[banner]}")

লক্ষ্য করুন — এই lookup সম্পূর্ণ শিক্ষামূলক ও কাল্পনিক (real CVE ID ব্যবহার করা হয়নি ইচ্ছাকৃতভাবে)। বাস্তব জগতে এই মিলগুলো Exploit-DB বা NVD-এর মতো পাবলিক ডেটাবেসে যাচাই করা হয় (L16-এ বিস্তারিত)।

৪ · ডিফেন্স: Banner Suppression — একটি স্তর মাত্র

অনেক hardening গাইড সুপারিশ করে ব্যানার suppress বা generic করার — যেমন সার্ভার প্রতিক্রিয়ায় ভার্সন নম্বর না দেখিয়ে শুধু "Web Server" দেখানো।

গুরুত্বপূর্ণ সীমাবদ্ধতা

ব্যানার suppress করা attacker-কে trivially fingerprint করা থেকে আটকায় — কিন্তু এটি security through obscurity-এর একটি উদাহরণ: এটি একটি অতিরিক্ত স্তর, বাস্তব দুর্বলতা ঠিক করার (patching) বিকল্প নয়। একজন দৃঢ়প্রতিজ্ঞ আক্রমণকারী অন্যান্য কৌশল (behavior fingerprinting, error-message differences) দিয়ে সফটওয়্যার শনাক্ত করতে পারে। তাই সঠিক প্রায়োরিটি সবসময়: প্যাচ প্রথমে (L16), obscurity শুধু বাড়তি নিরাপত্তা হিসেবে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন শুধু port scanning যথেষ্ট নয় — কেন service ও ভার্সন জানা দরকার?

"পোর্ট ২২ খোলা" জানলে শুধু বোঝা যায় কোনো একটি SSH-জাতীয় সার্ভিস চলছে — কিন্তু নির্দিষ্ট vulnerability সবসময় একটি নির্দিষ্ট সফটওয়্যার ও ভার্সনের সাথে যুক্ত থাকে (CVE ডেটাবেসগুলো ঠিক এভাবেই সংগঠিত)। ভার্সন না জানলে কোনো পক্ষই (attacker বা defender) জানতে পারে না ঠিক কোন পরিচিত দুর্বলতা প্রযোজ্য কি না।

প্র ০২ Banner suppression কেন একটি "সমাধান" নয়, শুধু একটি অতিরিক্ত স্তর?

Banner suppress করলে trivial ফিঙ্গারপ্রিন্টিং কঠিন হয়, কিন্তু আসল দুর্বলতা (যদি থাকে) অপরিবর্তিত থেকে যায় — সফটওয়্যারটি এখনও ঠিক একই দুর্বল কোড চালাচ্ছে। একজন দক্ষ আক্রমণকারী অন্য উপায়ে (error message-এর ধরন, প্রতিক্রিয়ার সময়, নির্দিষ্ট আচরণ) ভার্সন অনুমান করতে পারে। তাই patching-ই একমাত্র প্রকৃত সমাধান; suppression শুধু একটি বাড়তি বাধা।

প্র ০৩ একজন defender কীভাবে নিশ্চিত হবেন যে একটি ব্যানার বিশ্বাসযোগ্য — একজন attacker ইচ্ছাকৃতভাবে ভুয়া ব্যানার সেট করলে কী হয়?

ব্যানার টেক্সট সহজেই কনফিগার করে বদলানো যায় (banner spoofing) — তাই শুধুমাত্র ব্যানারের উপর সম্পূর্ণ নির্ভর করা যায় না। পেশাদার vulnerability assessment (L14) তাই প্রায়ই একাধিক সংকেত একত্রিত করে — প্রোটোকল-লেভেল আচরণ পরীক্ষা, প্রতিক্রিয়ার প্যাটার্ন, এবং যেখানে সম্ভব সরাসরি সংস্করণ-নির্দিষ্ট আচরণগত টেস্ট — শুধু ঘোষিত ব্যানার টেক্সট নয়।

অনুশীলন

চিন্তা করুন: একজন attacker ইচ্ছাকৃতভাবে একটি সার্ভিসের ব্যানার বদলে ভুল তথ্য দেখালে (banner spoofing) এর ফলে defender-রা কীভাবে বিভ্রান্ত হতে পারেন?

একজন defender যদি শুধু ব্যানার-ভিত্তিক স্ক্যানের উপর ভরসা করে "এই সার্ভার নিরাপদ" সিদ্ধান্তে পৌঁছান, একটি স্পুফড ব্যানার (যেমন একটি পুরনো দুর্বল সংস্করণকে নতুন, নিরাপদ সংস্করণ হিসেবে দেখানো) একটি false sense of security তৈরি করতে পারে। এই কারণেই vulnerability assessment-এ একাধিক স্বাধীন সংকেত ব্যবহার করা উচিত, শুধু একটি সেলফ-রিপোর্টেড ব্যানার নয়।
পরীক্ষা করুন: কোড সেলের simulated_banners dict-এ পোর্ট 8080-এর জন্য "nginx (toy-demo build)" যোগ করুন এবং আবার Run করে দেখুন output-এ নতুন লাইনটি কীভাবে যুক্ত হয়।

রিপোর্টে একটি নতুন লাইন যুক্ত হবে: পোর্ট 8080 -> nginx (toy-demo build) — যেহেতু এই ব্যানারটি known_vulnerable_banners-এ নেই, তাই কোনো সতর্কতা বার্তা দেখাবে না। এটি দেখায় কীভাবে grab_banner() এবং vulnerability lookup সম্পূর্ণ ইন-মেমরি ডেটার উপর নির্ভরশীল।