নেটওয়ার্ক নিরাপত্তার ভিত্তি — CIA, হুমকি আর প্রতিরক্ষার স্তর

১ · ইন্টারনেট কেন নিরাপত্তা ছাড়াই জন্মাল

পর্ব ১ থেকে ৪৫ পর্যন্ত আমরা দেখেছি packet কীভাবে এক যন্ত্র থেকে আরেক যন্ত্রে যায়। প্রায় প্রতিটি পর্বের শেষ দিকে একটি অস্বস্তিকর অংশ ছিল — “এখানে বিশ্বাসের দুর্বলতা”। Switch যে কোনো উৎস-MAC বিশ্বাস করে, ARP-এর যে কোনো উত্তর বিশ্বাস করা হয়, IP-র উৎস-ঠিকানা কেউ যাচাই করে না, BGP-তে যে কেউ যে কোনো prefix ঘোষণা করতে পারত, SMTP-তে From: যা খুশি লেখা যায়। এগুলো দুর্ঘটনা নয় — এগুলো এক ঐতিহাসিক পছন্দের ফল।

১৯৬৯ সালের ARPANET আর ১৯৮৩ সালে TCP/IP-তে বদলে যাওয়া ইন্টারনেট ব্যবহার করতেন মূলত বিশ্ববিদ্যালয় আর গবেষণাগারের পরিচিত মানুষ। ১৯৮৮ সালে David Clark ইন্টারনেট-নকশার মূল লক্ষ্যগুলো লিখে প্রকাশ করেন — কিছু অংশ নষ্ট হলেও চলা, নানা ধরনের নেটওয়ার্ক জোড়া, বিকেন্দ্রিত পরিচালনা, কম খরচ; সেই তালিকায় “আক্রমণকারী থেকে সুরক্ষা” আলাদা লক্ষ্য ছিল না বলে সাধারণত উল্লেখ করা হয়। End-to-end নীতি (পর্ব ৩) অনুযায়ী নিরাপত্তাও প্রান্তের দায়িত্ব ধরা হয়েছিল, যা তখন খুব কম প্রান্তই নিত।

এরপরের তিন দশক কেটেছে “পরে জোড়া” নিরাপত্তায়: TLS (পর্ব ৪৮), IPsec আর VPN (পর্ব ৪৯), DNSSEC (পর্ব ৩৫), RPKI (পর্ব ২৫), SPF-DKIM-DMARC (পর্ব ৩৯), WPA3 (পর্ব ১৪)। প্রতিটি পুরোনো ব্যবস্থার সাথে মিল রেখে চলতে হয়, তাই প্রতিটির গ্রহণ ধীর আর অসম্পূর্ণ। এই মডিউলে আমরা সেই নিরাপত্তার ভিত্তি থেকে শুরু করব:

২ · CIA আর AAA — নিরাপত্তা আসলে কী রক্ষা করে

“নিরাপদ” শব্দটি অস্পষ্ট। কাজের সংজ্ঞা দেয় তিনটি লক্ষ্য, যাদের একসাথে বলে CIA triad:

Confidentiality ভাঙে যখন কেউ খোলা Wi-Fi-তে আপনার traffic পড়ে ফেলে (eavesdropping). Integrity ভাঙে যখন ARP spoofing করে কেউ মাঝখানে বসে packet বদলায় (পর্ব ১৮), বা DNS cache-এ ভুল ঠিকানা ঢোকায় (পর্ব ৩৫)। Availability ভাঙে DDoS-এ, SYN flood-এ (পর্ব ২৯), বা একটি fiber কাটা পড়লে — নিরাপত্তা দুর্ঘটনার বিরুদ্ধেও।

AAA — কে, কী পারবে, কী করেছে

তিনটি লক্ষ্য রক্ষা করতে নেটওয়ার্ককে আগে জানতে হয় কার সাথে কথা হচ্ছে। এর জন্য আরেকটি ত্রয়ী — AAA:

অফিসের রিসেপশনে পরিচয়পত্র দেখানো authentication; কোন তলার কোন ঘরে ঢুকতে দেওয়া হবে, সেটি authorization; খাতায় ঢোকা-বেরোনোর সময় লেখা accounting. অনেক ত্রুটির মূলে প্রথম দুটির গোলমাল — “লগইন করেছেন, তাই সব দেখতে পারবেন”। AAA-র নেটওয়ার্ক রূপ আগেই দেখেছেন: 802.1X আর RADIUS (পর্ব ১৪), HTTP-র cookie আর session (পর্ব ৩৬)।

৩ · নিরাপত্তার শব্দভান্ডার আর ঝুঁকির হিসাব

কয়েকটি শব্দ খুব নির্দিষ্ট অর্থে ব্যবহার হয়; একটি বাড়ির উদাহরণে দেখুন:

দুর্বলতা আছে কিন্তু হুমকি নেই — ঝুঁকি কম (বন্ধ ঘরের ভেতরের পুরোনো প্রিন্টার)। হুমকি আছে কিন্তু দুর্বলতা নেই — তাও ঝুঁকি কম। ঝুঁকি হয় যখন একটি মূল্যবান সম্পদ, একটি দুর্বলতা আর একটি সক্ষম হুমকি একসাথে মেলে।

Risk = likelihood × impact — একটি ঢাকার অফিসের হিসাব

সবচেয়ে প্রচলিত সহজ পদ্ধতি: প্রতিটি ঝুঁকির likelihood (ঘটার সম্ভাবনা) আর impact (ঘটলে ক্ষতি) — দুটোকেই ১ থেকে ৫-এর মাপে নম্বর দেওয়া, তারপর গুণ। ফল ১ থেকে ২৫. এই পর্বে আমরা ধরব ১৫ বা তার বেশি HIGH, ৮ থেকে ১৪ MEDIUM, ৭ বা কম LOW — এই সীমা প্রতিষ্ঠান নিজের মতো ঠিক করে, কোনো সার্বজনীন মান নেই। নিচের risk matrix-এ প্রতিটি ঘর হলো likelihood × impact:

হাতে একটি হিসাব: মতিঝিলের ২০ জনের একটি হিসাবরক্ষণ অফিস। ● গ্রাহকের database-এ কর্মীর চুরি হওয়া পাসওয়ার্ডে ঢোকা — phishing ইমেইল প্রায় প্রতি সপ্তাহে আসে, তাই likelihood ৪; ডেটা ফাঁস হলে গ্রাহক আর সুনাম দুটোই যাবে, impact ৫; risk = ৪ × ৫ = ২০, HIGH. MFA চালু করলে চুরি হওয়া পাসওয়ার্ড একা কাজ করে না — likelihood নামে ২-এ; least privilege দিয়ে একজন কর্মী শুধু নিজের গ্রাহকদের দেখেন, তাই impact নামে ৪-এ। বাকি ঝুঁকি (residual risk) = ২ × ৪ = ৮, MEDIUM. ঝুঁকি কখনো শূন্য হয় না; প্রশ্ন হলো বাকিটুকু প্রতিষ্ঠান মেনে নিতে রাজি কি না। ◆ ফাইল সার্ভারে ransomware: ৩ × ৫ = ১৫.

এমন তালিকাকে বলে risk register. নিচের প্রোগ্রাম ছয়টি ঝুঁকির score হিসাব করে, বড় থেকে ছোট সাজায় (সমান হলে বেশি impact আগে), আর পরিকল্পিত control-এর পরে residual risk দেখায়। “চালান” চাপুন, তারপর কোনো control-এর পরের সংখ্যা বদলে দেখুন:

// Risk register for a small Dhaka office: risk = likelihood x impact (1-5 each)
const risks = [
  // asset, threat, L, I, planned control, L after, I after
  ["Customer database",  "Stolen staff password",     4, 5, "MFA + least privilege",      2, 4],
  ["File server",        "Ransomware via phishing",   3, 5, "3-2-1 backup + segmentation", 2, 3],
  ["Office Wi-Fi",       "Shared WPA2 key leaks",     4, 3, "WPA3 + guest VLAN",          2, 2],
  ["Website",            "Unpatched CMS plugin",      3, 4, "Patch within 7 days + WAF",  2, 3],
  ["Accounting PC",      "USB malware",               2, 4, "Disable autorun + EDR",      1, 4],
  ["Internet link",      "Fibre cut / ISP outage",    2, 3, "Second ISP (backup link)",   1, 3],
];
const level = s => s >= 15 ? "HIGH" : s >= 8 ? "MEDIUM" : "LOW";
const rows = risks.map(([asset, threat, L, I, ctl, L2, I2]) =>
  ({ asset, threat, L, I, score: L * I, ctl, res: L2 * I2 }));
rows.sort((a, b) => b.score - a.score || b.I - a.I);   // tie: bigger impact first
console.log("rank  asset              threat                     LxI  score  level   -> residual");
rows.forEach((r, i) => console.log(
  `${String(i + 1).padStart(3)}   ${r.asset.padEnd(18)} ${r.threat.padEnd(26)} ${r.L}x${r.I}  ` +
  `${String(r.score).padStart(4)}   ${level(r.score).padEnd(7)} -> ${String(r.res).padStart(2)} ${level(r.res)}`));
const before = rows.reduce((s, r) => s + r.score, 0), after = rows.reduce((s, r) => s + r.res, 0);
console.log(`\ntotal risk score: ${before} -> ${after} (${Math.round(100 * (before - after) / before)}% lower)`);
const order = [...rows].sort((a, b) => (b.score - b.res) - (a.score - a.res));
console.log("biggest reduction first: " + order.slice(0, 3).map(r => `${r.asset} (-${r.score - r.res})`).join(", "));
const left = rows.filter(r => r.res >= 8).map(r => r.asset);
console.log("still MEDIUM or above after controls: " + (left.length ? left.join(", ") : "none"));

rank  asset              threat                     LxI  score  level   -> residual
  1   Customer database  Stolen staff password      4x5    20   HIGH    ->  8 MEDIUM
  2   File server        Ransomware via phishing    3x5    15   HIGH    ->  6 LOW
  3   Website            Unpatched CMS plugin       3x4    12   MEDIUM  ->  6 LOW
  4   Office Wi-Fi       Shared WPA2 key leaks      4x3    12   MEDIUM  ->  4 LOW
  5   Accounting PC      USB malware                2x4     8   MEDIUM  ->  4 LOW
  6   Internet link      Fibre cut / ISP outage     2x3     6   LOW     ->  3 LOW

total risk score: 73 -> 31 (58% lower)
biggest reduction first: Customer database (-12), File server (-9), Office Wi-Fi (-8)
still MEDIUM or above after controls: Customer database

CVE আর CVSS — দুর্বলতার নাম আর মাপ

পৃথিবীজুড়ে একই দুর্বলতা নিয়ে কথা বলতে একটি সাধারণ নাম দরকার। CVE (Common Vulnerabilities and Exposures) ১৯৯৯ সাল থেকে প্রকাশ্যে জানা দুর্বলতাকে একটি পরিচয় দেয়, যেমন CVE-2014-0160 (OpenSSL-এর Heartbleed) বা CVE-2021-44228 (Log4j-এর Log4Shell). তালিকাটি পরিচালনা করে MITRE নামের একটি অলাভজনক প্রতিষ্ঠান। গুরুত্বের মাপ দেয় CVSS — ০ থেকে ১০-এর score, যা হিসাব হয় দুর্বলতাটি নেটওয়ার্ক থেকে কাজে লাগানো যায় কি না, লগইন বা ব্যবহারকারীর সাহায্য লাগে কি না, আর CIA-র কোনটি কতটা ভাঙে — এসব দেখে। CVSS v3.x-এ ৯.০–১০ Critical, ৭.০–৮.৯ High, ৪.০–৬.৯ Medium, ০.১–৩.৯ Low; ২০২৩ সালে v4.0 প্রকাশিত হয়েছে, আর দুটিই এখন প্রচলিত — কোন সংস্করণের score, দেখে নিন।

সাবধান: CVSS মাপে দুর্বলতার তীব্রতা, আপনার ঝুঁকি নয়। ৯.৮ score-এর একটি বাগ এমন সেবায়, যা আপনার নেটওয়ার্কে বন্ধ, ঝুঁকি প্রায় শূন্য; আবার ৬.৫-এর বাগ ইন্টারনেটমুখী সার্ভারে, যার exploit প্রকাশ্যে ঘুরছে, অনেক জরুরি। তাই patch-এর অগ্রাধিকারে দেখা হয় — সফটওয়্যারটি কোথায় আছে, বাইরে থেকে পৌঁছানো যায় কি না, আর এটি সক্রিয়ভাবে কাজে লাগানো হচ্ছে কি না।

৪ · আক্রমণকারী কে, আর কোথায় কোথায় আঘাত করতে পারে

প্রতিরক্ষা নকশার আগে লিখে নিতে হয় আপনি কার বিরুদ্ধে লড়ছেন — এটিই threat model. কয়েকটি মৌলিক ভাগ:

• নিষ্ক্রিয় বনাম সক্রিয়। Passive আক্রমণকারী শুধু শোনে — Wi-Fi-র বাতাসে বা ISP-র তারে traffic পড়ে। কিছু বদলায় না বলে তাকে ধরা কঠিন; প্রতিরক্ষা encryption. Active আক্রমণকারী packet বদলায়, জাল packet ঢোকায়, পুরোনো packet আবার পাঠায় (replay), বা মাঝখানে বসে দুই পক্ষ সেজে কথা বলে (MITM). প্রতিরক্ষা integrity check আর authentication.
• Dolev–Yao মডেল। ১৯৮৩ সালে Danny Dolev আর Andrew Yao নিরাপত্তা-protocol বিশ্লেষণের জন্য একটি কঠোর অনুমান প্রস্তাব করেন: ধরে নিন নেটওয়ার্কটাই আক্রমণকারী। সে প্রতিটি বার্তা পড়তে, আটকাতে, বদলাতে আর নিজের বার্তা ঢোকাতে পারে — শুধু encryption ভাঙতে পারে না, যদি না চাবি জানে। TLS-এর মতো protocol এই মডেল মাথায় রেখে নকশা করা হয়; খোলা Wi-Fi-তে অনুমানটি মোটেই বাড়াবাড়ি নয়।
• বাইরের বনাম ভেতরের। Insider — কর্মী, ঠিকাদার, বা যার অ্যাকাউন্ট চুরি হয়েছে — ইতিমধ্যেই firewall-এর ভেতরে। “ভেতরের সবাই বিশ্বস্ত” ধরে নেওয়া পুরোনো নকশা এই কারণেই দুর্বল (অংশ ৬)।

স্তরে স্তরে attack surface

একটি যন্ত্র বা নেটওয়ার্কে আক্রমণকারী যত জায়গা দিয়ে ঢোকার চেষ্টা করতে পারে — খোলা port, চালু সেবা, ইন্টারফেস, ব্যবহারকারী — সব মিলিয়ে attack surface. আগের পর্বগুলোর আক্রমণ আর প্রতিরক্ষা এক টেবিলে:

Attack surface কমানোর প্রথম ধাপ — জানা, কী খোলা আছে। নিজের যন্ত্রে কোন port-এ কোন প্রোগ্রাম শুনছে, Linux-এ দেখায় ss -tuln (পর্ব ৬)। নিচের স্ক্রিপ্ট এই পাতার রানার container-এ সেটি দেখে; ss না থাকলে /proc/net/tcp আর udp সরাসরি পড়ে (ঠিকানা আর port সেখানে hex-এ লেখা — স্ক্রিপ্ট সেটি বদলে নেয়)। তারপর দুটি পরীক্ষামূলক সেবা চালু করে আবার দেখে — একটি শুধু loopback-এ, একটি সব interface-এ। এটি শুধু নিজের যন্ত্র দেখা; অন্যের যন্ত্রের port খোঁজা এই পর্বের বিষয় নয়।

echo "== 1. ss =="
command -v ss >/dev/null && ss -tuln || echo "  ss নেই — নিচে /proc/net/tcp আর udp থেকে পড়ছি"
list() {   # TCP sockets in LISTEN (state 0A) and bound UDP sockets (state 07), IPv4
  for f in tcp udp; do
    [ -r /proc/net/$f ] || continue
    while read -r _ local _ st _; do
      { [ $f = tcp ] && [ "$st" = 0A ]; } || { [ $f = udp ] && [ "$st" = 07 ]; } || continue
      h=${local%:*}; p=$((16#${local#*:}))
      echo "  $f  $((16#${h:6:2})).$((16#${h:4:2})).$((16#${h:2:2})).$((16#${h:0:2})):$p"
    done < <(tail -n +2 /proc/net/$f) | sort
  done
  echo "  (end of list)"
}
echo "== 2. listening now =="; list
# two test services for 2 seconds: one on loopback only, one on every interface
if command -v python3 >/dev/null; then
  python3 -c 'import socket, time
a = socket.socket(); a.bind(("127.0.0.1", 8080)); a.listen()
b = socket.socket(); b.bind(("0.0.0.0", 8081)); b.listen(); time.sleep(2)' &
elif command -v perl >/dev/null; then
  perl -MIO::Socket::INET -e '
    my $a = IO::Socket::INET->new(LocalAddr => "127.0.0.1:8080", Listen => 5) or die "8080: $!";
    my $b = IO::Socket::INET->new(LocalAddr => "0.0.0.0:8081", Listen => 5) or die "8081: $!";
    sleep 2' &
else
  echo "  python3 বা perl নেই — ধাপ ৩ বাদ"; exit 0
fi
sleep 1
echo "== 3. after starting two test services =="; list
command -v ss >/dev/null && ss -tln | { read -r h; echo "$h"; sort -b -k4; }
wait

== 1. ss ==
Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
== 2. listening now ==
  (end of list)
== 3. after starting two test services ==
  tcp  0.0.0.0:8081
  tcp  127.0.0.1:8080
  (end of list)
State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      5            0.0.0.0:8081      0.0.0.0:*
LISTEN 0      5          127.0.0.1:8080      0.0.0.0:*

৫ · নকশার নীতি — Saltzer-Schroeder থেকে defence in depth

১৯৭৫ সালে MIT-র Jerome Saltzer আর Michael Schroeder “The Protection of Information in Computer Systems” নামের একটি প্রবন্ধে সুরক্ষিত ব্যবস্থা নকশার কয়েকটি নীতি লেখেন। প্রায় পঞ্চাশ বছর পরেও সেগুলো নিরাপত্তা-প্রকৌশলের ভিত্তি হিসেবে পড়ানো হয় (মূল তালিকায় আটটি নীতি, পরে অনেকে আরও যোগ করেছেন)। নেটওয়ার্কের ভাষায়:

পরবর্তী সময়ে আরও দুটি নীতি সমান গুরুত্ব পেয়েছে: attack surface কমানো — যা লাগে না, তা বন্ধ বা মুছে ফেলা (অংশ ৪-এর পরীক্ষা); আর secure by default — পণ্য বাক্স থেকে বের করার সময়েই নিরাপদ অবস্থায় থাকবে, যেমন প্রতিটি router-এর আলাদা এলোমেলো পাসওয়ার্ড, সবার জন্য একটি admin/admin নয়। Kerckhoffs-এর নীতি (১৮৮৩) open design-এর পূর্বসূরি: একটি গোপন-লিখন ব্যবস্থা নিরাপদ থাকা উচিত এমনকি শত্রু পুরো ব্যবস্থা জানলেও — গোপন থাকবে শুধু চাবি। পর্ব ৪৭-এ এটি আবার পাবেন।

Defence in depth — একটি স্তরের ওপর ভরসা নয়

Defence in depth মানে কয়েকটি স্বাধীন প্রতিরক্ষা পরপর রাখা, যাতে একটি ব্যর্থ হলেও পরেরটি থামায়। ব্যাংকের ভল্টের কথা ভাবুন: গেটে প্রহরী, ভেতরে CCTV, ভল্টে দুই চাবির তালা, আর রাতে অ্যালার্ম। কোনোটি একা নিখুঁত নয়। নিচে একটি phishing আক্রমণ স্তর পেরিয়ে এগোনোর চেষ্টা করছে — ধাপে ধাপে দেখুন কোন স্তর ব্যর্থ, কোনটি টেকে:

৬ · Segmentation, zone আর zero trust

একটি সমতল নেটওয়ার্কে (সব যন্ত্র একই subnet-এ, ভেতরে কোনো বাধা নেই) একটি যন্ত্র আক্রান্ত হলেই বাকি সবার দরজা খোলা। Network segmentation নেটওয়ার্ককে আলাদা zone-এ ভাগ করে — সাধারণত আলাদা VLAN আর subnet (পর্ব ১৩), মাঝে firewall বা router-এর ACL — আর zone থেকে zone-এ শুধু দরকারি traffic যেতে দেয়। জাহাজের ভেতরের জলরোধী কক্ষের মতো: একটি কক্ষে পানি ঢুকলেও জাহাজ ডোবে না।

        Internet
           │
     ┌─────┴─────┐
     │ firewall  │──────────── DMZ 172.16.0.0/24  (website, mail relay)
     └─────┬─────┘
           ├──────── staff   10.10.0.0/16  (laptops, Wi-Fi)
           ├──────── servers 10.20.0.0/16  (file server, database)
           └──────── mgmt    10.99.0.0/24  (switch/router admin, jump host)
     guest Wi-Fi: separate VLAN, internet only

• Internet — অবিশ্বস্ত; ভেতরে শুধু DMZ-এর প্রকাশ্য সেবায় আসা যায়।
• DMZ (demilitarised zone) — বাইরের জন্য খোলা সার্ভারের আলাদা ঘর। ওয়েব সার্ভার আক্রান্ত হলেও সে শুধু নির্দিষ্ট port-এ database পর্যন্ত যেতে পারে, কর্মীদের ল্যাপটপে নয়।
• Internal — কর্মী আর সার্ভার, সম্ভব হলে আলাদা zone-এ।
• Management — router, switch আর সার্ভারের প্রশাসনিক সংযোগ; প্রবেশ শুধু একটি নির্দিষ্ট “jump host” থেকে, MFA দিয়ে।

নিচের simulator এই নকশার নিয়মগুলো ডেটা হিসেবে রাখে: ঠিকানা থেকে zone বের করে, নিয়ম ওপর থেকে নিচে মেলায়, প্রথম মেলা নিয়মই সিদ্ধান্ত (first match); কিছু না মিললে DENY. এটি আসল firewall কমান্ড নয়; nftables পর্ব ৪৯-এ।

// Zone policy checker: first matching rule wins, anything unmatched is DENIED
const zoneOf = ip =>
  ip.startsWith("10.10.")  ? "staff"  : ip.startsWith("10.20.") ? "servers" :
  ip.startsWith("10.99.")  ? "mgmt"   : ip.startsWith("172.16.") ? "dmz" : "internet";
const rules = [   // id, from zone, to zone, protocol/port, action
  { id: "R1", from: "internet", to: "dmz",      svc: "tcp/443", act: "allow" },
  { id: "R2", from: "staff",    to: "internet", svc: "tcp/443", act: "allow" },
  { id: "R3", from: "staff",    to: "servers",  svc: "tcp/445", act: "allow" },
  { id: "R4", from: "dmz",      to: "servers",  svc: "tcp/5432", act: "allow" },
  { id: "R5", from: "mgmt",     to: "*",        svc: "tcp/22",  act: "allow" },
  { id: "R6", from: "staff",    to: "mgmt",     svc: "*",       act: "deny"  },
];
const tests = [
  ["203.0.113.7", "172.16.0.10", "tcp/443"],   // customer opens the website
  ["203.0.113.7", "10.20.0.5",   "tcp/445"],   // internet tries the file server
  ["10.10.3.21",  "10.20.0.5",   "tcp/445"],   // staff laptop opens a shared folder
  ["10.10.3.21",  "10.20.0.8",   "tcp/22"],    // staff laptop tries SSH to a server
  ["172.16.0.10", "10.20.0.9",   "tcp/5432"],  // web server queries the database
  ["172.16.0.10", "10.10.3.21",  "tcp/445"],   // compromised web server -> staff laptop
  ["10.99.0.2",   "10.20.0.8",   "tcp/22"],    // admin jump host -> server SSH
  ["10.10.3.21",  "10.99.0.2",   "tcp/22"],    // staff laptop -> management network
];
const match = (r, f, t, s) => (r.from === "*" || r.from === f) && (r.to === "*" || r.to === t) &&
                              (r.svc === "*" || r.svc === s);
let allowed = 0;
for (const [src, dst, svc] of tests) {
  const f = zoneOf(src), t = zoneOf(dst);
  const r = rules.find(x => match(x, f, t, svc));
  const verdict = r ? r.act.toUpperCase() : "DENY";
  if (verdict === "ALLOW") allowed++;
  console.log(`${(src + " -> " + dst + " " + svc).padEnd(38)} ${(f + ">" + t).padEnd(17)} ${verdict.padEnd(5)} ${r ? r.id : "default deny"}`);
}
console.log(`\n${allowed} of ${tests.length} allowed; everything not written as a rule was denied.`);

203.0.113.7 -> 172.16.0.10 tcp/443     internet>dmz      ALLOW R1
203.0.113.7 -> 10.20.0.5 tcp/445       internet>servers  DENY  default deny
10.10.3.21 -> 10.20.0.5 tcp/445        staff>servers     ALLOW R3
10.10.3.21 -> 10.20.0.8 tcp/22         staff>servers     DENY  default deny
172.16.0.10 -> 10.20.0.9 tcp/5432      dmz>servers       ALLOW R4
172.16.0.10 -> 10.10.3.21 tcp/445      dmz>staff         DENY  default deny
10.99.0.2 -> 10.20.0.8 tcp/22          mgmt>servers      ALLOW R5
10.10.3.21 -> 10.99.0.2 tcp/22         staff>mgmt        DENY  R6

4 of 8 allowed; everything not written as a rule was denied.

এবার একটি সংযোগ ধরে দেখুন, simulator ভেতরে ভেতরে কী করে — 10.10.3.21 → 10.20.0.8 tcp/22:

Perimeter বনাম zero trust

পুরোনো perimeter মডেল দুর্গের মতো: শক্ত দেয়াল (firewall), কিন্তু ভেতরে — VPN দিয়ে ঢুকলেও — সবাই বিশ্বস্ত। সমস্যা: আক্রান্ত ল্যাপটপ ভেতরেই থাকে; cloud আর বাসা থেকে কাজের যুগে “ভেতর-বাইর” অস্পষ্ট; আর দেয়াল পেরোলে lateral movement সহজ।

Zero trust ধারণাটি বলে — নেটওয়ার্কে অবস্থান দিয়ে বিশ্বাস নয়; প্রতিটি অনুরোধে ব্যবহারকারীর পরিচয়, যন্ত্রের অবস্থা (patch আছে কি না, প্রতিষ্ঠানের যন্ত্র কি না) আর প্রসঙ্গ যাচাই করে, শুধু নির্দিষ্ট সেবার জন্য অনুমতি। Google ২০১০-এর দশকের শুরুতে নিজের ভেতরে BeyondCorp নামে এমন একটি ব্যবস্থা চালু করে আর ২০১৪ সাল থেকে এ নিয়ে প্রবন্ধ প্রকাশ করে বলে জানা যায়; ২০২০ সালে NIST SP 800-207 zero trust architecture-এর একটি সাধারণ কাঠামো দেয়। মনে রাখুন, zero trust একটি নকশা-দর্শন, কেনার মতো একটি পণ্য নয় — আর এটি segmentation বাদ দেয় না, বরং প্রতিটি সেবার চারপাশে আরও ছোট segment বানায়।

৭ · নেটওয়ার্কে পরিচয় — 802.1X, MFA, পাসওয়ার্ড আর passkey

Segmentation-এর নিয়ম কার্যকর হয় তখনই, যখন নেটওয়ার্ক জানে কোন যন্ত্র কে। অফিসের দেয়ালের Ethernet port-এ যে কেউ ল্যাপটপ লাগালেই যদি staff VLAN-এ ঢুকে যায়, তবে zone-এর দেয়াল অর্থহীন। এখানে আসে পোর্ট-স্তরের প্রবেশ-নিয়ন্ত্রণ: 802.1X-এ switch বা Wi-Fi AP যন্ত্রটিকে প্রথমে কিছুই করতে দেয় না, শুধু যাচাইয়ের বার্তা RADIUS সার্ভারে পাঠায় (পর্ব ১৪); সফল হলে RADIUS বলে দিতে পারে কোন VLAN-এ রাখতে হবে। এর ওপরে NAC (network access control) যন্ত্রের অবস্থাও দেখতে পারে — OS হালনাগাদ কি না, নিরাপত্তা-সফটওয়্যার চালু কি না — আর অচেনা যন্ত্রকে আলাদা VLAN-এ পাঠায়, যেমন রিসেপশন অতিথিকে আলাদা কার্ড দেয়।

পাসওয়ার্ড কত শক্ত — entropy-র হিসাব

একটি এলোমেলোভাবে বানানো গোপন শব্দের শক্তি মাপা হয় entropy দিয়ে, বিটে। N রকম চিহ্ন থেকে প্রতিটি অক্ষর এলোমেলোভাবে বেছে L দৈর্ঘ্যের পাসওয়ার্ড বানালে সম্ভাব্য পাসওয়ার্ড N^Lটি, তাই

শব্দের তালিকা থেকে এলোমেলো শব্দ নিয়ে বানানো passphrase-এর জন্য N = তালিকার শব্দসংখ্যা, L = শব্দসংখ্যা। Diceware-এর মতো ৭,৭৭৬ শব্দের তালিকায় প্রতিটি শব্দ log₂ ৭৭৭৬ ≈ ১২.৯ বিট দেয়। অনুমানকারী গড়ে অর্ধেক সম্ভাবনা পরখ করে ঠিকটি পায়, তাই গড় সময় = ২^{entropy − ১} ÷ (প্রতি সেকেন্ডে অনুমান)। নিচের হিসাব তিনটি হারে: অনলাইনে (সার্ভার সীমা দিলে সেকেন্ডে ১০টির মতো), চুরি হওয়া database-এ ধীর password hash-এর বিরুদ্ধে, আর দ্রুত (অনুপযুক্ত) hash-এর বিরুদ্ধে শক্তিশালী GPU-তে। হারগুলো মোটা দাগের অনুমান, মাপা মান নয়:

// Entropy of RANDOMLY generated secrets + rough offline guessing time (average = half the space)
const secrets = [
  ["8 lowercase letters",         26,   8],
  ["8 chars, all 95 printable",   95,   8],
  ["12 letters+digits (62)",      62,  12],
  ["16 letters+digits (62)",      62,  16],
  ["4 random words (7776 list)",  7776, 4],
  ["6 random words (7776 list)",  7776, 6],
];
const rates = [["online, 10/s", 1e1], ["slow hash, 1e4/s", 1e4], ["fast hash, 1e10/s", 1e10]];
function human(sec) {
  const units = [["years", 31557600], ["days", 86400], ["hours", 3600], ["min", 60], ["s", 1]];
  for (const [u, n] of units) if (sec >= n) {
    const v = sec / n;
    return (v >= 1e6 ? v.toExponential(1) : v.toFixed(v < 10 ? 1 : 0)) + " " + u;
  }
  return "< 1 s";
}
console.log(("secret                        bits  | " + rates.map(r => r[0].padEnd(18)).join(" | ")).trimEnd());
for (const [name, n, len] of secrets) {
  const bits = len * Math.log2(n);               // log2(n^len) = len * log2(n)
  const avgGuesses = Math.pow(2, bits - 1);      // on average the right guess comes halfway
  const cols = rates.map(([, r]) => human(avgGuesses / r).padEnd(18));
  console.log(`${name.padEnd(28)} ${bits.toFixed(1).padStart(5)}  | ${cols.join(" | ")}`.trimEnd());
}
console.log("\nRough only: real attackers try likely human choices first (names, years, leaked lists),");
console.log("so a human-chosen 'P@ssw0rd2024' has far less entropy than its length suggests.");
console.log("Online guessing is stopped by rate limiting/lockout, and a stolen password alone");
console.log("is not enough when MFA is on.");

secret                        bits  | online, 10/s       | slow hash, 1e4/s   | fast hash, 1e10/s
8 lowercase letters           37.6  | 331 years          | 121 days           | 10 s
8 chars, all 95 printable     52.6  | 1.1e+7 years       | 10511 years        | 3.8 days
12 letters+digits (62)        71.5  | 5.1e+12 years      | 5.1e+9 years       | 5112 years
16 letters+digits (62)        95.3  | 7.6e+19 years      | 7.6e+16 years      | 7.6e+10 years
4 random words (7776 list)    51.7  | 5.8e+6 years       | 5793 years         | 2.1 days
6 random words (7776 list)    77.5  | 3.5e+14 years      | 3.5e+11 years      | 350270 years

Rough only: real attackers try likely human choices first (names, years, leaked lists),
so a human-chosen 'P@ssw0rd2024' has far less entropy than its length suggests.
Online guessing is stopped by rate limiting/lockout, and a stolen password alone
is not enough when MFA is on.

MFA আর passkey

MFA (multi-factor authentication) দুই বা ততোধিক ভিন্ন ধরনের প্রমাণ চায়: যা আপনি জানেন (পাসওয়ার্ড), যা আপনার কাছে আছে (ফোন, hardware key), যা আপনি নিজে (আঙুলের ছাপ)। bKash-এর PIN আর ফোনের SIM — এটিও দুই ধরনের প্রমাণ। সব MFA সমান নয়: SMS OTP কিছু না-থাকার চেয়ে ভালো, কিন্তু SIM-প্রতারণা আর ভুয়া পাতায় OTP চেয়ে নেওয়ার ঝুঁকি আছে; authenticator app-এর কোড (TOTP) আরও ভালো, তবে সেটিও ভুয়া পাতায় টাইপ করানো যায়।

Passkey (FIDO2/WebAuthn মানদণ্ডের ওপর) এই সমস্যার মূলে যায়। যন্ত্রে একটি গোপন চাবি থাকে যা কখনো বাইরে যায় না, আর সার্ভার শুধু সংশ্লিষ্ট প্রকাশ্য চাবি রাখে (পর্ব ৪৭-এর public key cryptography). চাবিটি নির্দিষ্ট ওয়েবসাইটের ঠিকানার সাথে বাঁধা — ভুয়া ডোমেইনে ব্রাউজার সেটি ব্যবহারই করে না, তাই phishing-এ প্রায় অকার্যকর; আর সার্ভারে চুরি করার মতো কোনো পাসওয়ার্ড থাকে না। পাসওয়ার্ড যেখানে থাকছেই, সেখানে আধুনিক নির্দেশিকা (যেমন NIST-এর ডিজিটাল পরিচয় নির্দেশিকা) মোটামুটি বলে: দৈর্ঘ্য জটিলতার চেয়ে জরুরি, জোর করে ঘনঘন বদলানো নয়, ফাঁস-হওয়া তালিকার সাথে মিলিয়ে দেখা, আর password manager দিয়ে প্রতিটি সাইটে আলাদা পাসওয়ার্ড — যাতে এক সাইটের ফাঁস অন্য সাইটে কাজে না লাগে (credential stuffing).

৮ · নিরাপত্তা পরিচালনা — log, patch, backup আর incident response

নিরাপত্তা একবার বসিয়ে ভুলে যাওয়ার জিনিস নয়, প্রতিদিনের কাজ। চারটি অভ্যাস প্রায় প্রতিটি বড় ঘটনার পর্যালোচনায় ঘুরে ফিরে আসে:

• Log আর পর্যবেক্ষণ। Firewall-এর DENY, VPN লগইন, DHCP lease, DNS query, সার্ভারের auth log — যন্ত্রে ছড়িয়ে থাকলে কেউ দেখে না। Syslog বা অন্য উপায়ে এক জায়গায় জমা করলে, ঘড়ি মিলিয়ে রাখলে (NTP) আর কয়েকটি সতর্কসংকেতের নিয়ম লিখলে স্তর ৫-এর মতো ঘটনা মিনিটে ধরা পড়ে। Log রাখুন আক্রমণকারীর নাগালের বাইরে; IDS পর্ব ৫০-এ।
• Patch management. জানা দুর্বলতার patch সময়মতো বসানো। কোন যন্ত্রে কী সফটওয়্যার আছে তার তালিকা ছাড়া এটি অসম্ভব — যা জানেন না, তা patch করবেন কীভাবে? ইন্টারনেটমুখী আর সক্রিয়ভাবে কাজে লাগানো দুর্বলতা আগে।
• Backup — ৩-২-১ নিয়ম। অন্তত ৩টি কপি, ২ ধরনের মাধ্যমে, ১টি অন্য জায়গায় (offsite). Ransomware-এর যুগে আরও একটি শর্ত: অন্তত একটি কপি অফলাইন বা বদলানো যায় না এমন (immutable), কারণ আক্রমণকারী নেটওয়ার্কে যুক্ত backup-ও encrypt করে দেয়। আর backup থেকে ফেরত আনার অনুশীলন — যে backup কখনো পরীক্ষা হয়নি, সেটি আশা মাত্র।
• মানুষের সচেতনতা। Social engineering — মানুষকে ঠকিয়ে তথ্য বা কাজ আদায় — সম্ভবত সবচেয়ে প্রচলিত প্রবেশপথ। Phishing ইমেইল, “আমি মোবাইল ব্যাংকিং অফিস থেকে বলছি, OTP-টা বলুন” ফোনকল, বসের নামে জরুরি টাকা পাঠানোর বার্তা — একই কৌশল: তাড়া, ভয় বা লোভ। প্রতিরক্ষা: লিংকের আসল ডোমেইন দেখা, OTP বা পাসওয়ার্ড কাউকে না বলা, টাকার অনুরোধ অন্য পথে যাচাই করা, আর ভয় ছাড়া রিপোর্ট করার সহজ পথ।

Incident response — ঘটনা ঘটলে কী করবেন

Incident response হলো নিরাপত্তা-ঘটনায় সাড়া দেওয়ার পূর্বপরিকল্পিত প্রক্রিয়া। NIST-এর SP 800-61 নির্দেশিকা দীর্ঘদিন একে চার পর্বে ভাগ করেছে (প্রস্তুতি; শনাক্ত ও বিশ্লেষণ; ঠেকানো, নির্মূল ও পুনরুদ্ধার; ঘটনা-পরবর্তী শিক্ষা) — সাম্প্রতিক সংস্করণে কাঠামো বদলেছে, বর্তমানটি দেখে নিন। অনেক প্রশিক্ষণে একই কাজ ছয় ধাপে বলা হয়; একটি ছোট অফিসের ransomware ঘটনায় দেখুন:

৯ · আইন, নৈতিকতা আর পেশা

নিয়ম একটাই, আর এটি আলোচনাসাপেক্ষ নয়: শুধু সেই সিস্টেম পরীক্ষা করবেন, যা আপনার নিজের, অথবা যার মালিকের কাছ থেকে লিখিত অনুমতি আছে — কোন যন্ত্র, কোন সময়, কী কী পরীক্ষা, তা স্পষ্ট লেখা থাকবে। পেশাদার penetration testing ঠিক এভাবেই চুক্তি করে হয়। “শুধু দেখছিলাম” — আদালতে এই যুক্তি প্রায়ই টেকে না। শেখার জন্য নিজের ল্যাব বানান: নিজের যন্ত্রে কয়েকটি virtual machine বা container (পর্ব ৫৪)।

বাংলাদেশের আইন: দেশে তথ্যপ্রযুক্তি আর সাইবার নিরাপত্তা নিয়ে আইন আছে, যা অননুমোদিত প্রবেশ আর বিভিন্ন সাইবার অপরাধকে শাস্তিযোগ্য করে। গত কয়েক বছরে এই আইনগুলো একাধিকবার বদলেছে, তাই এখানে কোনো ধারা বা শাস্তির কথা বলা হচ্ছে না — সর্বশেষ আইন সরকারি উৎস বা আইনজীবীর কাছ থেকে জেনে নিন। অন্য দেশের সার্ভারে কিছু করলে সেই দেশের আইনও প্রযোজ্য হতে পারে।

কাকে জানাবেন: দেশে নিরাপত্তা-ঘটনায় সাড়া দেওয়ার দল (CERT বা CIRT) আছে — যেমন সরকারি পর্যায়ে BGD e-GOV CIRT, আর bdCERT নামেও একটি উদ্যোগ পরিচিত। নাম আর কাঠামো সময়ের সাথে বদলাতে পারে, তাই বর্তমান নাম আর যোগাযোগের উপায় অফিশিয়াল ওয়েবসাইট থেকে মিলিয়ে নিন।

পেশার পথ

প্রচলিত সার্টিফিকেশনের কয়েকটি নাম, কোনো ক্রম বা সুপারিশ ছাড়া: CompTIA Network+ আর Security+, Cisco-র CCNA ও CyberOps, ISC2-এর CC আর CISSP (অভিজ্ঞদের জন্য), EC-Council-এর CEH, OffSec-এর OSCP, আর GIAC-এর বিভিন্ন সনদ। নাম, বিষয় আর খরচ প্রায়ই বদলায় — চাকরির বিজ্ঞাপন আর অফিশিয়াল ওয়েবসাইট দেখে সিদ্ধান্ত নিন। হাতে-কলমে দক্ষতা, নিজের ল্যাব আর লিখে রাখা প্রজেক্ট প্রায়ই সনদের চেয়ে বেশি কথা বলে।

১০ · AI-এর যুগে নেটওয়ার্ক নিরাপত্তা — সাহায্য নিন, অন্ধভাবে নয়

AI নীতির খসড়া, log-এর সারাংশ বা risk register-এর প্রথম তালিকায় ভালো সাহায্য করে, কিন্তু একটি ভুল firewall নিয়ম পুরো নকশা খুলে দেয়। প্রচলিত ভুল:

AI-এর নিরাপত্তা-পরামর্শ মানার আগে — চেকলিস্ট

• প্রতিটি firewall নিয়মে উৎস, গন্তব্য আর port সুনির্দিষ্ট, আর শেষে default deny আছে
• subnet আর zone-এর হিসাব নিজে আবার করেছি, নিয়মগুলো simulator বা ল্যাবে পরীক্ষা করেছি
• কমান্ডগুলো আমার OS আর যন্ত্রের, man বা vendor-এর নথিতে মিলিয়েছি; আগে শুধু দেখার কমান্ড চালিয়েছি
• দূরের যন্ত্রে firewall বদলানোর আগে ফেরার পথ (console, নির্ধারিত সময়ের পরে আগের নিয়মে ফেরা) রেখেছি
• CVE, CVSS, RFC আর আইনের উল্লেখ অফিশিয়াল উৎসে মিলিয়েছি
• কোনো পরামর্শ অন্যের সিস্টেমকে লক্ষ্য করছে না; আমার কাছে লিখিত অনুমতি আছে