TCP/IP ও নেটওয়ার্ক প্রোটোকল সিকিউরিটি বেসিকস

TCP/IP & network protocol security basics

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

এক নজরে · TL;DR

প্রতিটি TCP সংযোগ একটি থ্রি-ওয়ে হ্যান্ডশেক (SYN → SYN-ACK → ACK) দিয়ে শুরু হয়, যা L12-এর পোর্ট স্ক্যানিং কৌশলগুলোর ভিত্তি।
প্রতিটি খোলা পোর্ট একটি সম্ভাব্য attack surface — অপ্রয়োজনীয় সার্ভিস বন্ধ রাখাই সবচেয়ে মৌলিক নিরাপত্তা নীতিগুলোর একটি।
কিছু প্রোটোকল (Telnet, FTP, HTTP) ডিফল্টভাবে এনক্রিপ্ট করা নয় — যা তাদের L08-এর প্যাকেট স্নিফিং আক্রমণের জন্য বিশেষভাবে ঝুঁকিপূর্ণ করে তোলে; SSH ও HTTPS-এর মতো এনক্রিপ্টেড বিকল্প থাকলে সবসময় সেগুলো ব্যবহার করা উচিত।

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

TCP থ্রি-ওয়ে হ্যান্ডশেক কীভাবে কাজ করে (SYN, SYN-ACK, ACK)
সাধারণ পোর্ট ও প্রোটোকল (FTP, SSH, Telnet, SMTP, DNS, HTTP, HTTPS, RDP) এবং প্রতিটির নিরাপত্তা প্রেক্ষাপট
Attack surface ধারণা এবং কেন "যা প্রয়োজন নেই তা বন্ধ রাখা" একটি মৌলিক নিরাপত্তা নীতি
কোন পোর্ট/প্রোটোকল সরাসরি ইন্টারনেটে উন্মুক্ত থাকলে বিশেষভাবে বিপজ্জনক

১ · TCP থ্রি-ওয়ে হ্যান্ডশেক

যেকোনো TCP-ভিত্তিক সংযোগ (যেমন একটি ওয়েবসাইট ভিজিট করা) শুরুর আগে ক্লায়েন্ট ও সার্ভারকে একটি ছোট্ট, তিন-ধাপের "হ্যান্ডশেক" সম্পন্ন করতে হয় —

SYN — ক্লায়েন্ট সার্ভারকে একটি সংযোগ শুরুর অনুরোধ পাঠায় ("Synchronize")।
SYN-ACK — সার্ভার অনুরোধ গ্রহণ করে সাড়া দেয় ("Synchronize-Acknowledge")।
ACK — ক্লায়েন্ট নিশ্চিত করে ("Acknowledge") — এখন সংযোগ সম্পূর্ণ স্থাপিত।

এই হ্যান্ডশেকের গুরুত্ব শুধু ধারণাগত নয় — L12-এ আমরা দেখব কীভাবে একটি পোর্ট স্ক্যান এই হ্যান্ডশেককে ইচ্ছাকৃতভাবে অসম্পূর্ণ রেখে (শুধু SYN পাঠিয়ে) স্টেলথিয়ার স্ক্যানিং সম্ভব করে।

তিনটি ধাপের যেকোনো একটি অসম্পূর্ণ থাকলে সংযোগ পূর্ণাঙ্গভাবে স্থাপিত হয় না — L12-এর SYN scan ঠিক এই সুযোগটিই ব্যবহার করে।

২ · সাধারণ পোর্ট ও প্রোটোকল — নিরাপত্তা প্রেক্ষাপট

প্রতিটি নেটওয়ার্ক সার্ভিস একটি নির্দিষ্ট পোর্ট নম্বরে চলে। কিছু প্রোটোকল ডিজাইন করা হয়েছিল এমন এক যুগে যখন এনক্রিপশন সাধারণ ছিল না — ফলে তাদের ট্র্যাফিক আজও অনেক জায়গায় প্লেইনটেক্সট (unencrypted) থেকে যায়।

পোর্ট ২০/২১ — FTP
ফাইল ট্রান্সফারের জন্য, কিন্তু ক্রেডেনশিয়ালসহ সবকিছু সাধারণত প্লেইনটেক্সটে পাঠানো হয় — উচ্চ ঝুঁকি।

পোর্ট ২২ — SSH
এনক্রিপ্টেড রিমোট অ্যাক্সেস — Telnet-এর নিরাপদ বিকল্প হিসেবে ডিজাইন করা।

পোর্ট ২৩ — Telnet
রিমোট অ্যাক্সেসের জন্য, কিন্তু সম্পূর্ণ এনক্রিপশন-বিহীন লিগ্যাসি প্রোটোকল — আধুনিক সিস্টেমে ব্যবহার করা উচিত নয়।

পোর্ট ২৫ — SMTP
ইমেইল পাঠানোর প্রোটোকল — আধুনিক সেটআপে TLS দিয়ে সুরক্ষিত করা প্রয়োজন।

পোর্ট ৫৩ — DNS
ডোমেইন নেম রেজোলিউশন — L09-এ DNS স্পুফিং আক্রমণ বিস্তারিত কভার হবে।

পোর্ট ৮০ — HTTP
ওয়েব ট্র্যাফিক, কিন্তু এনক্রিপশন-বিহীন — L08-এ দেখব কীভাবে একজন পর্যবেক্ষক প্লেইনটেক্সট ডেটা দেখতে পারে।

পোর্ট ৪৪৩ — HTTPS
TLS দিয়ে এনক্রিপ্টেড ওয়েব ট্র্যাফিক — L38-এ TLS হ্যান্ডশেক বিস্তারিত কভার হবে।

পোর্ট ৩৩৮৯ — RDP
উইন্ডোজ রিমোট ডেস্কটপ — সরাসরি ইন্টারনেটে উন্মুক্ত থাকলে র‍্যানসমওয়্যার আক্রমণের একটি অত্যন্ত সাধারণ প্রবেশপথ (L33-এ বিস্তারিত)।

৩ · Attack Surface — প্রতিটি খোলা পোর্ট একটি সম্ভাব্য প্রবেশপথ

Attack SurfaceAttack Surfaceএকটি সিস্টেমের মোট সম্ভাব্য প্রবেশপথের সমষ্টি — প্রতিটি খোলা পোর্ট, চলমান সার্ভিস, বা এক্সপোজড ইন্টারফেস এই সারফেসের একটি অংশ। যত বেশি সার্ভিস চালু থাকে, ততই বেশি সম্ভাব্য প্রবেশপথ তৈরি হয় — এমনকি যদি প্রতিটি সার্ভিস আলাদাভাবে "নিরাপদ" মনে হয়। এই কারণেই একটি মৌলিক নিরাপত্তা নীতি হলো minimal-install/minimal-exposure principle — যা প্রয়োজন নেই তা বন্ধ রাখা বা সম্পূর্ণ আনইনস্টল করে দেওয়া, শুধু "ফায়ারওয়াল দিয়ে ব্লক করে রাখা" নয় (L06-এ ফায়ারওয়াল বিস্তারিত)।

ব্যবহারিক নিয়ম

যদি একটি সার্ভিস ইন্টারনেটে সরাসরি উন্মুক্ত থাকার প্রয়োজন না থাকে, তাহলে সেটি বন্ধ রাখুন বা শুধুমাত্র একটি নিরাপদ ভার্চুয়াল প্রাইভেট নেটওয়ার্ক (VPN, L07-এ বিস্তারিত) এর মাধ্যমে অ্যাক্সেসযোগ্য করুন। Telnet, FTP ও RDP-এর মতো প্রোটোকল সরাসরি পাবলিক ইন্টারনেটে উন্মুক্ত রাখা বাস্তব-জগতের নিরাপত্তা লঙ্ঘনের সবচেয়ে সাধারণ কারণগুলোর একটি।

৪ · কোড সেল — উচ্চ-ঝুঁকির পোর্ট চিহ্নিতকরণ

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

Python

port_services = {
    21:   {"service": "FTP",     "risk_if_exposed": "high"},
    22:   {"service": "SSH",     "risk_if_exposed": "low"},
    23:   {"service": "Telnet",  "risk_if_exposed": "high"},
    25:   {"service": "SMTP",    "risk_if_exposed": "medium"},
    53:   {"service": "DNS",     "risk_if_exposed": "medium"},
    80:   {"service": "HTTP",    "risk_if_exposed": "medium"},
    443:  {"service": "HTTPS",   "risk_if_exposed": "low"},
    3389: {"service": "RDP",     "risk_if_exposed": "high"},
}

def filter_by_risk(services, risk_level):
    return {port: info for port, info in services.items() if info["risk_if_exposed"] == risk_level}

high_risk = filter_by_risk(port_services, "high")
safe_ish = filter_by_risk(port_services, "low")

print("ইন্টারনেটে উন্মুক্ত থাকলে উচ্চ-ঝুঁকিপূর্ণ পোর্ট:")
for port, info in high_risk.items():
    print(f"  পোর্ট {port} — {info['service']}")

print("\nসাধারণভাবে নিরাপদ (এনক্রিপ্টেড) পোর্ট:")
for port, info in safe_ish.items():
    print(f"  পোর্ট {port} — {info['service']}")

লক্ষ্য করুন — SSH (২২) ও Telnet (২৩) দুটোই "রিমোট অ্যাক্সেস" দেয়, কিন্তু একটির ঝুঁকি low আর অন্যটির high। পার্থক্যটা কাজে নয়, এনক্রিপশনে — এটাই দেখায় শুধু "কী কাজ করে" জানা যথেষ্ট নয়, "কীভাবে এনক্রিপ্টেড" তাও জানা জরুরি।

মূল কথা · Key takeaway

TCP হ্যান্ডশেক নেটওয়ার্ক যোগাযোগের ভিত্তি, এবং প্রতিটি খোলা পোর্ট একটি সিদ্ধান্ত — এই সার্ভিস কি সত্যিই বাইরে উন্মুক্ত থাকা প্রয়োজন, এবং যদি হ্যাঁ, তা কি এনক্রিপ্টেড প্রোটোকল ব্যবহার করছে? এই দুটি প্রশ্নই এই কোর্সের পুরো নেটওয়ার্ক সিকিউরিটি মডিউলের (L06-L09) ভিত্তি তৈরি করে।

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

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

প্র ০১ TCP থ্রি-ওয়ে হ্যান্ডশেকের তৃতীয় ধাপ (ACK) বাদ দিয়ে শুধু প্রথম দুটি ধাপ সম্পন্ন করলে কী হয় — এবং কেন এটি একটি পোর্ট স্ক্যানিং কৌশলের ভিত্তি হতে পারে?

ACK ছাড়া সংযোগটি সম্পূর্ণরূপে স্থাপিত হয় না — এটি একটি "half-open" অবস্থায় থেকে যায়। যেহেতু সংযোগ সম্পূর্ণ হয়নি, তা লগ ও অ্যাপ্লিকেশন-স্তরে কম দৃশ্যমান হতে পারে। L12-এ আমরা দেখব এই আচরণকেই "SYN scan" কৌশল ইচ্ছাকৃতভাবে ব্যবহার করে — স্ক্যানার শুধু SYN পাঠায় এবং SYN-ACK পেলেই বুঝে ফেলে পোর্টটি খোলা, সম্পূর্ণ হ্যান্ডশেক সম্পন্ন না করেই।

প্র ০২ একটি কোম্পানি তাদের পুরনো Telnet সার্ভিস "দরকার নেই" জেনেও শুধু ফায়ারওয়ালে ব্লক করে রেখেছে, আনইনস্টল করেনি। এটি কেন একটি অসম্পূর্ণ সমাধান?

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

প্র ০৩ SSH ও Telnet একই কাজ (রিমোট অ্যাক্সেস) করে, কিন্তু একটির ঝুঁকি "low" আর অন্যটির "high" কেন লেবেল করা হয়েছে?

পার্থক্যটি কার্যকারিতায় নয়, এনক্রিপশনে। SSH ট্র্যাফিক এনক্রিপ্ট করে পাঠায় — একজন নেটওয়ার্ক পর্যবেক্ষক শুধু এনক্রিপ্টেড ব্লব দেখতে পান। Telnet সম্পূর্ণ প্লেইনটেক্সটে পাঠায় — ব্যবহারকারীর নাম, পাসওয়ার্ড, কমান্ড সবকিছু যে কেউ নেটওয়ার্ক ট্র্যাফিক ক্যাপচার করলে সরাসরি পড়তে পারবে (L08-এ প্রদর্শিত হবে)।

অনুশীলন

চিন্তা করুন: একটি ছোট ব্যবসার সার্ভার ইন্টারনেটে ৪টি পোর্ট উন্মুক্ত রেখেছে — ২১ (FTP), ২২ (SSH), ৪৪৩ (HTTPS), ৩৩৮৯ (RDP)। কোন পোর্টগুলো অগ্রাধিকার দিয়ে পর্যালোচনা/বন্ধ করা উচিত এবং কেন?

২১ (FTP) ও ৩৩৮৯ (RDP) — উভয়ই "high risk if exposed" ক্যাটাগরিতে পড়ে। FTP প্লেইনটেক্সট ক্রেডেনশিয়াল পাঠায়, আর RDP ransomware আক্রমণের একটি সুপরিচিত প্রবেশপথ। যদি এই সার্ভিসগুলো সত্যিই প্রয়োজন হয়, সেগুলো VPN-এর পেছনে রাখা বা এনক্রিপ্টেড বিকল্পে (যেমন FTP-এর বদলে SFTP, সরাসরি RDP-এর বদলে VPN + RDP) স্থানান্তর করা উচিত।
পরীক্ষা করুন: উপরের কোড সেলে port_services dict-এ একটি নতুন এন্ট্রি 465: {"service": "SMTPS", "risk_if_exposed": "low"} যোগ করুন এবং filter_by_risk(port_services, "low")-এর আউটপুট দেখুন।

নতুন এন্ট্রিটি "low" রিস্ক ফিল্টারের ফলাফলে যুক্ত হবে, HTTPS (৪৪৩) ও SSH (২২)-এর পাশে — কারণ SMTPS হলো SMTP-এর একটি TLS-এনক্রিপ্টেড সংস্করণ, ঠিক যেমন HTTPS হলো HTTP-এর এনক্রিপ্টেড সংস্করণ।