পাঠ ৪৫ · ৫৭-এর মধ্যে · মডিউল ১০
Home / Courses / Computer Networks / থ্রেট মডেল

নেটওয়ার্ক সিকিউরিটি থ্রেট মডেল

Network security threat model
৭ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

  • এই কোর্সে ইতিমধ্যে শেখা প্রোটোকলগুলোর সাথে সরাসরি যুক্ত সাধারণ নেটওয়ার্ক-স্তরের হুমকিগুলো চেনা
  • Eavesdropping, spoofing, ও denial-of-service-এর মূল ধারণা ও কোন স্তরে এগুলো ঘটে
  • Defense-in-depth নীতি ও কেন এটি নেটওয়ার্কিংয়ের layered ডিজাইনের সাথে সামঞ্জস্যপূর্ণ
  • প্রতিটি হুমকিকে তার সংশ্লিষ্ট আগের পাঠের সাথে যুক্ত করে একটি রেফারেন্স টেবিল তৈরি করা

০ · এই মডিউলের সুযোগ

এই কোর্স (Computer Networks) মূলত প্রোটোকল ও অ্যালগরিদম কীভাবে কাজ করে তার উপর কেন্দ্রীভূত — নিরাপত্তা এই কোর্সের মূল ফোকাস নয়। Cybersecurity & Ethical Hacking কোর্সের নিজস্ব নেটওয়ার্ক সিকিউরিটি মডিউল অনেক গভীরভাবে আক্রমণ কৌশল, টুলস, ও প্রতিরক্ষা কৌশল কভার করে। এই পাঠ ও পরবর্তী তিনটি (L46-L48) একটি সংক্ষিপ্ত, প্রোটোকল-স্তরের ওভারভিউ দেয় — যা দেখায় নিরাপত্তা সমস্যাগুলো এই কোর্সে ইতিমধ্যে শেখা নির্দিষ্ট প্রোটোকলগুলোর সাথে ঠিক কীভাবে সংযুক্ত।

১ · Eavesdropping ও Sniffing

এনক্রিপ্ট না করা প্রোটোকলে ডেটা প্লেইন টেক্সটে (কোনো এনক্রিপশন ছাড়া) নেটওয়ার্কের মধ্য দিয়ে ভ্রমণ করে — যেমন plain HTTP (M6/L29) বা FTP (M6/L32)। যদি কেউ সেই ট্রাফিকের পথে থাকে (একই লোকাল নেটওয়ার্কে, বা একটি রাউটারে যার মধ্য দিয়ে ট্রাফিক যায়), তারা এই ডেটা স্নিফ করে পড়ে ফেলতে পারে — যেমন পাসওয়ার্ড, ব্যক্তিগত বার্তা। প্রধান প্রতিরক্ষা হলো এনক্রিপশন — HTTPS (HTTP + TLS, M10/L48-এ বিস্তারিত), যা ডেটা এনক্রিপ্ট করে দেয় যাতে পথের মধ্যবর্তী কেউ তা পড়তে না পারে, যদিও তারা প্যাকেট দেখতে পারে।

২ · Spoofing — পরিচয় জাল করা

স্পুফিং মানে একটি প্যাকেটের প্রকৃত উৎস সম্পর্কে মিথ্যা দাবি করা। ARP SpoofingARP Spoofingযেহেতু ARP রিপ্লাই ডিফল্টভাবে প্রমাণীকৃত (authenticated) নয় (M3/L13), একটি দূষিত ডিভাইস মিথ্যা দাবি করতে পারে যে সে একটি IP-এর মালিক, ট্রাফিক নিজের দিকে ঘুরিয়ে নিতে। (M3/L13-এর সরাসরি সম্প্রসারণ) লোকাল নেটওয়ার্কে ট্রাফিক পুনর্নির্দেশিত করে, কারণ ARP রিপ্লাই ডিফল্টভাবে প্রমাণীকৃত নয়। IP Spoofing (M4/L14-এর সম্প্রসারণ) মানে একটি প্যাকেটের উৎস IP অ্যাড্রেস জাল করা — প্রকৃত প্রেরকের আইডেন্টিটি লুকানো বা অন্য কারো আইডেন্টিটি ধার করার জন্য।

৩ · Denial of Service (DoS)

একটি DoS আক্রমণে টার্গেটকে এত বেশি ট্রাফিক দিয়ে প্লাবিত করা হয় যে এটি বৈধ ব্যবহারকারীদের সেবা দিতে পারে না। M9/L42-এর লেটেন্সি/থ্রুপুট ও M9/L43-এর কিউয়িং থিওরির গণিত অনুযায়ী, এটি মূলত টার্গেটের ইউটিলাইজেশন $\rho = \lambda/\mu$ ইচ্ছাকৃতভাবে ১-এর কাছাকাছি বা তার উপরে ঠেলে দেওয়ার একটি প্রায়োগিক উদাহরণ — যার ফলে কিউয়িং ডিলে অনিয়ন্ত্রিতভাবে বেড়ে যায় (M9/L43-এ যেমন গাণিতিকভাবে দেখানো হয়েছিল)।

মূল অন্তর্দৃষ্টি

লক্ষ্য করুন — এই তিনটি হুমকিই একেবারে নতুন কিছু নয়; প্রতিটিই এই কোর্সে ইতিমধ্যে শেখা একটি প্রোটোকলের একটি নির্দিষ্ট ডিজাইন সিদ্ধান্তকে (যেমন ARP-এর প্রমাণীকরণ না থাকা, HTTP-এর এনক্রিপশন না থাকা, বা কিউয়িং-এর গাণিতিক আচরণ) কাজে লাগায়। নিরাপত্তা বোঝার প্রথম ধাপ হলো প্রোটোকল কীভাবে কাজ করে তা ভালোভাবে জানা — যা এই কোর্সের বাকি ৪৪টি পাঠ ইতিমধ্যে দিয়েছে।

৪ · Defense-in-Depth

কোনো একটি একক প্রতিরক্ষা স্তরই যথেষ্ট নয় — একটি স্তর ব্যর্থ হলেও পরবর্তী স্তর যেন সুরক্ষা দিতে পারে, এই নীতিকে বলে defense-in-depth। এটি M1/L01-এ শেখা প্রোটোকল স্ট্যাকের layered ডিজাইনের সাথে একটি সুন্দর সমান্তরাল — যেমন নেটওয়ার্কিং ফাংশনকে স্বতন্ত্র স্তরে ভাগ করা হয়েছিল, নিরাপত্তাও একইভাবে একাধিক স্বাধীন স্তরে (এনক্রিপশন, ফায়ারওয়াল, প্রমাণীকরণ, মনিটরিং) বিভক্ত থাকা উচিত।

নিচের কোডে প্রতিটি হুমকিকে তার সংশ্লিষ্ট স্তর, এই কোর্সের কোন আগের পাঠ সেই প্রোটোকলটি কভার করেছে, ও প্রধান প্রতিরক্ষার সাথে যুক্ত করে একটি রেফারেন্স টেবিল তৈরি করা হয়েছে।

Python
# নেটওয়ার্ক থ্রেট রেফারেন্স টেবিল -- প্রতিটি হুমকি এই কোর্সের আগের পাঠের সাথে যুক্ত
threats = {
    "Eavesdropping/Sniffing": {
        "exploited_layer": "Application (M6)",
        "related_lesson": "L29 HTTP/HTTPS, L32 FTP",
        "primary_defense": "এনক্রিপশন -- TLS/HTTPS (M10/L48)",
    },
    "ARP Spoofing": {
        "exploited_layer": "Data Link (M3)",
        "related_lesson": "L13 ARP",
        "primary_defense": "Dynamic ARP Inspection / স্ট্যাটিক ARP এন্ট্রি",
    },
    "IP Spoofing": {
        "exploited_layer": "Network (M4)",
        "related_lesson": "L14 IP অ্যাড্রেসিং",
        "primary_defense": "Ingress/Egress ফিল্টারিং (উৎস IP যাচাই)",
    },
    "Denial of Service (DoS)": {
        "exploited_layer": "Transport/Network (M5, M9)",
        "related_lesson": "L42 লেটেন্সি/থ্রুপুট, L43 কিউয়িং থিওরি",
        "primary_defense": "রেট-লিমিটিং, ফায়ারওয়াল ফিল্টারিং (M10/L46)",
    },
}

print(f"{'হুমকি':26s} {'আক্রান্ত স্তর':26s} {'সম্পর্কিত পাঠ':26s} প্রধান প্রতিরক্ষা")
print("-" * 115)
for threat, info in threats.items():
    print(f"{threat:26s} {info['exploited_layer']:26s} {info['related_lesson']:26s} {info['primary_defense']}")

    
লক্ষ্য করুন — টেবিলের প্রতিটি সারি একটি নির্দিষ্ট আগের পাঠের সাথে যুক্ত। এটি ইচ্ছাকৃত: নিরাপত্তা কোনো বিচ্ছিন্ন বিষয় নয়, বরং প্রতিটি প্রোটোকলের ডিজাইনের একটি সরাসরি ফলাফল — একটি প্রোটোকল যত ভালোভাবে বোঝা যায়, তার নিরাপত্তা দুর্বলতাও তত স্পষ্ট হয়।

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

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

প্র ০১ ARP-এ কেন প্রমাণীকরণ (authentication) নেই — এটি কি একটি ডিজাইন ভুল ছিল?

ARP ডিজাইন করা হয়েছিল ১৯৮০-এর দশকে, যখন লোকাল নেটওয়ার্কের সব ডিভাইসকে বিশ্বস্ত ধরে নেওয়া হতো (তখনকার নেটওয়ার্ক পরিবেশ আজকের তুলনায় অনেক বেশি নিয়ন্ত্রিত ছিল)। এটি একটি ঐতিহাসিক প্রেক্ষাপটের সিদ্ধান্ত, ভুল বলা কঠিন — কিন্তু আজকের বিশ্বাসযোগ্যতা-ঘাটতিপূর্ণ নেটওয়ার্ক পরিবেশে এটি একটি বাস্তব দুর্বলতা, যা Dynamic ARP Inspection-এর মতো অতিরিক্ত সুরক্ষা স্তর দিয়ে সমাধান করতে হয়।

প্র ০২ HTTPS ব্যবহার করলে কি eavesdropping সম্পূর্ণ অসম্ভব হয়ে যায়?

HTTPS ডেটার বিষয়বস্তু এনক্রিপ্ট করে দেয়, তাই কেউ পথে বসে মেসেজ পড়তে পারবে না। কিন্তু কিছু মেটাডেটা (যেমন আপনি কোন ডোমেইনে সংযুক্ত হচ্ছেন, কতটা ডেটা আদান-প্রদান হচ্ছে, কখন) এখনও দৃশ্যমান থাকতে পারে (M10/L48-এ TLS নিয়ে বিস্তারিত)। তাই HTTPS eavesdropping-কে অনেক কঠিন করে দেয়, তবে "সম্পূর্ণ অদৃশ্য" করে দেয় না।

প্র ০৩ Defense-in-depth নীতি অনুযায়ী, শুধু একটি ফায়ারওয়াল থাকা কি যথেষ্ট নিরাপত্তা?

না — defense-in-depth অনুযায়ী কখনোই একটি একক স্তরের উপর সম্পূর্ণ নির্ভর করা উচিত নয়। একটি ফায়ারওয়াল (M10/L46) নেটওয়ার্ক-স্তরের প্রতিরক্ষা দেয়, কিন্তু এনক্রিপশন (ট্রানজিটে ডেটা সুরক্ষা), প্রমাণীকরণ (কে অ্যাক্সেস পাচ্ছে তা নিয়ন্ত্রণ), ও মনিটরিং (আক্রমণ সনাক্তকরণ) — প্রতিটি স্বতন্ত্র, পরিপূরক স্তর হিসেবে একসাথে থাকা দরকার, ঠিক যেমন প্রোটোকল স্ট্যাকের প্রতিটি স্তর তার নিজের দায়িত্ব পালন করে।

অনুশীলন

  1. চিন্তা করুন: আপনি যদি একটি পাবলিক ওয়াই-ফাই (যেমন ক্যাফেতে) ব্যবহার করেন, কোন হুমকিগুলো (এই পাঠের টেবিল থেকে) সবচেয়ে বেশি প্রাসঙ্গিক বলে মনে হয়?

    পাবলিক ওয়াই-ফাই-তে eavesdropping/sniffing ও ARP spoofing উভয়ই বিশেষভাবে প্রাসঙ্গিক — কারণ আপনি অপরিচিত মানুষদের সাথে একই লোকাল নেটওয়ার্ক শেয়ার করছেন, যেখানে তাদের মধ্যে কেউ ট্রাফিক স্নিফ করতে বা ARP spoofing করতে পারে। এই কারণেই পাবলিক ওয়াই-ফাই-তে সবসময় HTTPS ওয়েবসাইট ব্যবহার করা ও সংবেদনশীল কাজের জন্য VPN (M10/L47) ব্যবহার করার পরামর্শ দেওয়া হয়।

  2. পরীক্ষা করুন: উপরের কোড সেলের threats ডিকশনারিতে একটি নতুন এন্ট্রি যোগ করুন — "DNS Spoofing" — এবং এর exploited_layer, related_lesson (ইঙ্গিত: M6/L30), ও primary_defense পূরণ করুন।

    একটি যুক্তিসঙ্গত এন্ট্রি হতে পারে: exploited_layer="Application (M6)", related_lesson="L30 DNS", primary_defense="DNSSEC (DNS রেসপন্স প্রমাণীকরণ)" — যেহেতু DNS-এও ARP-এর মতো ডিফল্টভাবে কোনো প্রমাণীকরণ নেই, একজন আক্রমণকারী মিথ্যা DNS রেসপন্স পাঠিয়ে ব্যবহারকারীকে ভুল (দূষিত) IP-তে পুনর্নির্দেশিত করতে পারে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
QoS মেকানিজম