প্রচলিত আক্রমণ আর প্রতিরক্ষা — DDoS, spoofing, MITM আর IDS

১ · আক্রমণের মানচিত্র — লক্ষ্য, স্তর আর ধরন

মডিউল ২ থেকে ৭-এ প্রায় প্রতিটি protocol-এর দুর্বল দিকও দেখেছেন — MAC table ভরানো, জাল ARP, SYN flood, DNS cache poisoning, জাল ইমেইল। এই পর্বের কাজ সেগুলোকে এক মানচিত্রে বসানো, যাতে নতুন আক্রমণের নাম শুনলেই জিজ্ঞেস করতে পারেন: “এটি কী ভাঙতে চায়, কোন স্তরে, আর প্রতিরক্ষা কোন জাতের?”

পর্ব ৪৬-এ (নেটওয়ার্ক নিরাপত্তার ভিত্তি) নিরাপত্তার তিনটি মূল লক্ষ্য দেখেছেন — একসাথে বলা হয় CIA triad:

• Confidentiality (গোপনীয়তা): যার দেখার কথা নয়, সে দেখবে না। আড়ি পাতা এটি ভাঙে।
• Integrity (অখণ্ডতা ও সত্যতা): বার্তা পথে বদলাবে না, আর প্রেরক যে বলে সে-ই। জাল ঠিকানা, জাল উত্তর এটি ভাঙে।
• Availability (প্রাপ্যতা): সেবা দরকারের সময় পাওয়া যাবে। Denial of service এটি ভাঙে।

দ্বিতীয় ভাগ ধরন দিয়ে। Passive attack-এ আক্রমণকারী শুধু শোনে বা দেখে — কিছু বদলায় না, তাই ধরা কঠিন; প্রতিরক্ষা মূলত এনক্রিপশন। Active attack-এ সে packet বানায়, বদলায়, আটকায় বা বন্যা বইয়ে দেয় — ধরা তুলনামূলক সহজ, প্রতিরক্ষা যাচাই, সীমা আর ছাঁকনি।

নিচের টেবিলে কোর্সের পরিচিত আক্রমণগুলো একসাথে। শেষ কলামে বিস্তারিত যেখানে পড়েছেন — এখানে সেগুলোর পুনরাবৃত্তি করব না, শুধু সাধারণ নীতিগুলো জোড়া লাগাব।

২ · আক্রমণকারীর পথ — রক্ষকের চোখে

গুরুতর আক্রমণ সাধারণত একটি ঘটনা নয়, একটি যাত্রা। রক্ষকের জন্য এর সুখবর: আক্রমণকারীকে প্রতিটি ধাপে সফল হতে হয়, আর রক্ষক যেকোনো একটি ধাপে থামাতে পারলেই চলে।

এই ধাপগুলোর খুঁটিনাটি নাম দেওয়ার জনপ্রিয় কাঠামো MITRE ATT&CK — অলাভজনক প্রতিষ্ঠান MITRE-এর উন্মুক্ত জ্ঞানভান্ডার, যেখানে বাস্তবে দেখা আক্রমণ-আচরণ “tactic” (উদ্দেশ্য, যেমন Initial Access, Lateral Movement) আর “technique” (পদ্ধতি) হিসেবে সাজানো। রক্ষকেরা এটিকে মূলত ভাষা হিসেবে ব্যবহার করেন: “কোন technique ধরার ব্যবস্থা আছে, কোনগুলোতে আমরা অন্ধ?” এটি সরল ক্রম নয় — বাস্তব আক্রমণ ধাপ বাদ দেয়, ফিরে যায়।

DDoS এই যাত্রার বাইরে: আক্রমণকারী ঢুকতে চায় না, শুধু দরজা বন্ধ করতে চায় — তাই প্রতিরক্ষাও আলাদা জাতের।

৩ · DoS আর DDoS — তিন ধরন, botnet আর ধারণক্ষমতার অঙ্ক

DDoS-এর মূল চিন্তা একটাই: প্রতিটি সেবার কোনো না কোনো সীমিত সম্পদ আছে — link-এর bandwidth, firewall বা সার্ভারের সংযোগ-টেবিল, CPU আর ডেটাবেস। যেকোনো একটি ফুরিয়ে দিলেই আসল ব্যবহারকারীরা আর সেবা পান না। কোন সম্পদ লক্ষ্য, তা দিয়ে তিন ধরন:

সূক্ষ্ম কথা: stateful firewall নিজেই state exhaustion-এর শিকার হতে পারে — টেবিল ভরলে নতুন বৈধ সংযোগও ফেলে দেয়। তাই অনেক নেটওয়ার্ক সামনে অবস্থাহীন (stateless) ছাঁকনি রাখে (পর্ব ৪৯, Firewall আর VPN).

Botnet আর Mirai — যখন ক্যামেরাই অস্ত্র

“Distributed” অংশটি আসে botnet থেকে — ক্ষতিকর সফটওয়্যারে আক্রান্ত হাজার থেকে লাখো যন্ত্র, যাদের দূর থেকে একসাথে নির্দেশ দেওয়া যায়। ২০১৬ সালের Mirai এর সবচেয়ে পরিচিত উদাহরণ: প্রকাশিত বিশ্লেষণ অনুযায়ী এটি ক্যামেরা, ভিডিও রেকর্ডার আর বাসার router-এর কারখানার ডিফল্ট পাসওয়ার্ডের সুযোগে ছড়িয়েছিল, আর একটি বড় DNS সেবাদাতার ওপর আক্রমণে বহু জনপ্রিয় ওয়েবসাইট কয়েক ঘণ্টা নাগালের বাইরে ছিল (বিস্তারিত ভাবনার প্রশ্ন ১-এ)। শিক্ষা: IoT যন্ত্রের ডিফল্ট পাসওয়ার্ড পুরো ইন্টারনেটের সমস্যা; প্রতিটি যন্ত্রের ট্রাফিক সামান্য বলে উৎসে চেনা কঠিন; আর DNS-এর মতো কেন্দ্রীয় নির্ভরতা পড়লে সবাই পড়ে। প্রকাশিত রিপোর্টে সাম্প্রতিক সবচেয়ে বড় আক্রমণগুলো “Tbps মাত্রার” — বেশিরভাগ প্রতিষ্ঠানের পুরো link-এর চেয়ে শত-হাজার গুণ বড়।

ধারণক্ষমতার অঙ্ক — কেন নিজের ঘরে বসে ঠেকানো যায় না

ধরুন একটি প্রতিষ্ঠানের ইন্টারনেট link ১০ Gbps, স্বাভাবিক ট্রাফিক ২ Gbps. একটি botnet-এ ১ লাখ আক্রান্ত যন্ত্র, প্রতিটি মাত্র ২ Mbps upload করতে পারে (একটি সাধারণ বাসার সংযোগের জন্য কম)।

এখানে মূল কথাটি হলো কোথায় packet ফেলা হয়। ISP-র router থেকে আপনার link-এ ঢোকার মুখে queue উপচে পড়ে, আর সেখানে আসল-ভুয়া কোনো বাছবিচার হয় না (পর্ব ৫-এর queue আর loss মনে করুন)। আপনার firewall বসে আছে link-এর পরে — সে যে ১০ Gbps পায়, তার ৯৫%-ই আক্রমণ, আর সেগুলো নিখুঁতভাবে ফেলে দিলেও হারানো বৈধ ট্রাফিক আর ফেরে না। অফিসের সামনের গলিতে শত শত রিকশা দাঁড়ালে রিসেপশন যত দক্ষই হোক, অতিথি দরজা পর্যন্তই পৌঁছান না — জট খুলতে হয় মোড়ে, বড় রাস্তায়।

নিচের simulator এই সরল মডেলটি তিনভাবে চালায়: সরাসরি botnet, reflection-এ amplification বাড়ালে, আর আক্রমণকারীর উৎস-নেটওয়ার্কগুলোর কত অংশ BCP 38 মানলে কী হয়। মডেলটি ইচ্ছা করে সরল — ভরা link এলোমেলোভাবে packet ফেলে, সংখ্যাগুলো উদাহরণ।

// Simplified DDoS capacity model - illustrative numbers, not real measurements.
const LINK = 10, LEGIT = 2;                  // victim uplink 10 Gbps, normal traffic 2 Gbps
function report(label, attack) {
  const offered = attack + LEGIT;
  const ok = Math.min(1, LINK / offered);    // a full link drops packets at random
  console.log(label.padEnd(20) + "attack " + attack.toFixed(1).padStart(5) + " Gbps | link load " +
    (offered / LINK * 100).toFixed(0).padStart(4) + "% | legit delivered " + (ok * 100).toFixed(1) + "%");
}
console.log("A) Direct flood from a botnet, 2 Mbps upload per bot");
for (const bots of [1000, 10000, 100000]) report("  " + bots + " bots", bots * 2 / 1000);
console.log("B) Reflection: attacker sends 1 Gbps of spoofed requests");
for (const amp of [1, 10, 50]) report("  amplification x" + amp, 1 * amp);
console.log("C) Same x50 reflection; fraction f of attacker networks apply BCP 38");
for (const f of [0, 0.5, 0.9, 0.99]) report("  f = " + f, 1 * (1 - f) * 50);
console.log("   (model assumes spoofed traffic is spread evenly over networks)");

A) Direct flood from a botnet, 2 Mbps upload per bot
  1000 bots         attack   2.0 Gbps | link load   40% | legit delivered 100.0%
  10000 bots        attack  20.0 Gbps | link load  220% | legit delivered 45.5%
  100000 bots       attack 200.0 Gbps | link load 2020% | legit delivered 5.0%
B) Reflection: attacker sends 1 Gbps of spoofed requests
  amplification x1  attack   1.0 Gbps | link load   30% | legit delivered 100.0%
  amplification x10 attack  10.0 Gbps | link load  120% | legit delivered 83.3%
  amplification x50 attack  50.0 Gbps | link load  520% | legit delivered 19.2%
C) Same x50 reflection; fraction f of attacker networks apply BCP 38
  f = 0             attack  50.0 Gbps | link load  520% | legit delivered 19.2%
  f = 0.5           attack  25.0 Gbps | link load  270% | legit delivered 37.0%
  f = 0.9           attack   5.0 Gbps | link load   70% | legit delivered 100.0%
  f = 0.99          attack   0.5 Gbps | link load   25% | legit delivered 100.0%
   (model assumes spoofed traffic is spread evenly over networks)

৪ · DDoS-এর প্রতিরক্ষা — নিজের ঘর থেকে ইন্টারনেটের উজান পর্যন্ত

ধারণক্ষমতার অঙ্ক থেকেই প্রতিরক্ষার নকশা আসে: আক্রমণ যত বড়, তাকে তত উজানে, তত বড় আর ছড়ানো নেটওয়ার্কে থামাতে হয়। কাছ থেকে দূরে স্তরগুলো:

RTBH কঠিন আপস: আক্রান্ত IP-টি পুরো অচল — এক অর্থে আক্রমণকারীর কাজই সম্পূর্ণ — কিন্তু একই link-এর বাকি সবাই বাঁচে। Flowspec সূক্ষ্মতর, তবে ভুল নিয়ম ছড়ালে বিপুল বৈধ ট্রাফিকও আটকায়। (BLACKHOLE community RFC 7999-এ, Flowspec-এর বর্তমান মান RFC 8955-এ; কোন ISP কী সমর্থন করে তা চুক্তি ভেদে আলাদা।)

মূলে আঘাত: BCP 38 আর BCP 84 — আর কেন spoofing টিকে আছে

Reflection আক্রমণ সম্ভব শুধু একটি কারণে: কোনো নেটওয়ার্ক তার গ্রাহকদের অন্যের উৎস-ঠিকানা বসিয়ে packet পাঠাতে দেয়। Ingress filtering — BCP 38 (RFC 2827, ২০০০) — বলে ISP যেন গ্রাহকের দিক থেকে আসা packet-এর উৎস-ঠিকানা সেই গ্রাহকের নিজের ঠিকানা-ব্লকের কি না যাচাই করে। BCP 84 (RFC 3704, পরে RFC 8704-এ হালনাগাদ) একাধিক ISP-তে যুক্ত (multihomed) নেটওয়ার্কের জন্য এর বাস্তব পদ্ধতিগুলো বর্ণনা করে, যার পরিচিত রূপ uRPF: “এই উৎস-ঠিকানায় ফেরার পথ কি এই interface দিয়েই?” — না হলে packet ফেলা (strict mode), বা অন্তত routing table-এ ঠিকানাটির কোনো পথ আছে কি না দেখা (loose mode).

তবু spoofing টিকে আছে, কারণ এটি প্রণোদনার সমস্যা: filtering-এর খরচ ISP-র, লাভ বাকি পৃথিবীর, আর একটি অবহেলিত নেটওয়ার্কই আক্রমণকারীর জন্য যথেষ্ট (পর্ব ২৮-এর ভাবনার প্রশ্নে বিস্তারিত)। তাই MANRS-এর মতো স্বেচ্ছা উদ্যোগ, প্রতিফলক কমানো আর নকশায় সতর্কতাও লাগে।

এবার পুরো ছবিটি ধাপে ধাপে দেখি: একটি reflection-amplification আক্রমণ পথে কোথায় কোথায় থামানো যায়। সংখ্যাগুলো উদাহরণ — simulator-এর মডেলের সাথে মেলানো।

৫ · Spoofing — সাধারণ ছবি: কী জাল হয়, কে ধরে

Spoofing মানে নিজেকে অন্য কেউ বলে দেখানো। নেটওয়ার্কে প্রায় প্রতিটি পরিচয়-চিহ্ন প্রেরক নিজেই লেখে — খামের ওপর প্রেরকের ঠিকানার মতো। তাই প্রশ্ন একই: “প্রাপক কীসের ভিত্তিতে বিশ্বাস করছে, আর তা যাচাইয়ের উপায় কী?”

TCP কেন অন্ধ spoofing কঠিন করে

UDP-তে জাল উৎস দিয়ে একটি packet পাঠালেই কাজ শেষ — তাই reflection. কিন্তু TCP-তে জাল ঠিকানায় পূর্ণ সংযোগ গড়া প্রায় অসম্ভব (পর্ব ২৯): সার্ভারের SYN-ACK যায় আসল ঠিকানার মালিকের কাছে, আক্রমণকারী তা দেখেই না (“অন্ধ”)। তাকে সার্ভারের ISN অনুমান করে ঠিক ACK পাঠাতে হবে; আধুনিক OS ISN এলোমেলো ৩২ bit-এর সংখ্যা হিসেবে বেছে নেয় (RFC 6528-এর পরামর্শ), তাই এক চেষ্টায় সম্ভাবনা প্রায় ২^৩২-এ ১। উপরন্তু আসল মালিক অপ্রত্যাশিত SYN-ACK পেলে RST পাঠিয়ে সংযোগ ভেঙে দেয়।

১৯৮০-র দশকে অনেক সিস্টেমের ISN অনুমানযোগ্য ছিল, আর ১৯৯০-এর দশকের মাঝামাঝি একটি বহুল আলোচিত অনুপ্রবেশে সেই দুর্বলতা আর “এই IP থেকে এলে বিশ্বাস” ধরনের পুরোনো সেবা একসাথে কাজে লাগানো হয়েছিল। শিক্ষা: উৎস IP ঠিকানা কখনো পরিচয়ের প্রমাণ নয় — প্রমাণ আসে cryptography থেকে (পর্ব ৪৭)। SYN flood-এ জাল উৎস কাজ করে, কারণ সেখানে সংযোগ সম্পূর্ণ করার দরকারই নেই — শুধু অর্ধেক-খোলা অবস্থায় টেবিল ভরানো, যার উত্তর SYN cookie.

৬ · MITM — পথের মাঝে বসা, আর কেন TLS তবু রক্ষা করে

Man-in-the-middle আক্রমণে আক্রমণকারী দুই পক্ষের মাঝে বসে — দুজনেই ভাবেন তাঁরা সরাসরি কথা বলছেন। মাঝখানে বসার পথ অনেক, প্রতিটি আগের কোনো পর্বের আক্রমণ:

সবচেয়ে গুরুত্বপূর্ণ উপলব্ধি: মাঝে বসতে পারা আর বিষয়বস্তু পড়তে পারা এক নয়। সংযোগ TLS-এ হলে আর ব্রাউজার certificate ঠিকভাবে যাচাই করলে (পর্ব ৪৮, TLS আর HTTPS), আক্রমণকারী শুধু metadata দেখে আর চাইলে সংযোগ আটকায় — পড়তে বা বদলাতে পারে না। তাই তার লক্ষ্য TLS এড়ানো: ব্যবহারকারীকে TLS-এ যেতেই না দেওয়া (SSL stripping), বা ভুয়া certificate দেখিয়ে আশা করা যে সতর্কবার্তা উপেক্ষিত হবে।

SSL stripping আর HSTS

বেশিরভাগ মানুষ address bar-এ শুধু bank.example লেখেন। পুরোনো দিনে ব্রাউজার তখন প্রথম অনুরোধ সরল http://-তে পাঠাত, আর সার্ভার বলত “https-এ যান”। এই প্রথম, এনক্রিপশনহীন মুহূর্তটিই SSL stripping-এর সুযোগ। ২০০৯ সালে কৌশলটি জনসমক্ষে দেখানোর পর প্রতিরক্ষা হিসেবে আসে HSTS (RFC 6797, ২০১২): সার্ভার একটি header পাঠায় — Strict-Transport-Security: max-age=31536000; includeSubDomains — আর ব্রাউজার মনে রাখে যে নির্দিষ্ট সময় এই ডোমেইনে শুধু https চলবে।

HSTS-এর দুর্বল জায়গা একেবারে প্রথম ভিজিট, header পাওয়ার আগে (“trust on first use”). সমাধান HSTS preload তালিকা — ব্রাউজারের ভেতরেই লেখা ডোমেইন, যেখানে প্রথম ভিজিট থেকেই শুধু https.

Certificate সতর্কবার্তা — কেন “তবু এগিয়ে যান” চাপবেন না

HSTS না থাকলে certificate সতর্কবার্তাই MITM-এর প্রায় একমাত্র দৃশ্যমান সংকেত। গবেষণায় বারবার দেখা গেছে, অভ্যাসবশে অনেকে এটি পেরিয়ে যান — বিশেষ করে ভুল কনফিগারেশনের কোনো সাইটে প্রতিদিন দেখলে। নিয়ম সহজ: ব্যাংক, ইমেইল বা অফিসের সেবায় সতর্কবার্তা এলে থামুন, অন্য নেটওয়ার্ক (নিজের মোবাইল ডেটা) থেকে চেষ্টা করুন। আর সার্ভার চালালে নিজের certificate কখনো মেয়াদোত্তীর্ণ বা ভুল নামের রাখবেন না, যাতে ব্যবহারকারীরা সতর্কবার্তায় অভ্যস্ত না হন।

দুই দিকের যাচাই — mutual authentication

সাধারণ HTTPS-এ শুধু সার্ভার নিজেকে প্রমাণ করে। Mutual TLS (mTLS)-এ ক্লায়েন্টও নিজের certificate দেখায় — যন্ত্রে-যন্ত্রে যোগাযোগে, ব্যাংকের API-তে, VPN আর 802.1X-এ প্রচলিত (পর্ব ১৪, ৪৯)। তখন private key চুরি না হলে মাঝের আক্রমণকারী কোনো পক্ষকেই ঠকাতে পারে না।

৭ · খোঁজখবর, scanning আর password আক্রমণ — রক্ষকের চোখে

আক্রমণের প্রথম ধাপ প্রায় সবসময় reconnaissance. একটি port scan অনেক port-এ সংযোগের চেষ্টা করে দেখে কে সাড়া দেয় — খোলা TCP port SYN-ACK দেয়, বন্ধ port RST দেয় (পর্ব ২৯), firewall-এ আটকানো port চুপ থাকে। এই আচরণের কারণেই scan রক্ষকের log-এ স্পষ্ট দাগ রাখে। নিচে একটি Linux firewall log-এর উদাহরণ (বানানো, ঠিকানা ডকুমেন্টেশন ব্লকের):

# উদাহরণ — firewall drop log (সংক্ষিপ্ত করা)
02:14:07 DROP IN=eth0 SRC=203.0.113.66 DST=198.51.100.10 PROTO=TCP SPT=41822 DPT=23   SYN
02:14:07 DROP IN=eth0 SRC=203.0.113.66 DST=198.51.100.10 PROTO=TCP SPT=41822 DPT=3389 SYN
02:14:07 DROP IN=eth0 SRC=203.0.113.66 DST=198.51.100.10 PROTO=TCP SPT=41822 DPT=445  SYN
02:14:08 DROP IN=eth0 SRC=203.0.113.66 DST=198.51.100.10 PROTO=TCP SPT=41822 DPT=6379 SYN
... (একই উৎস থেকে এক মিনিটে প্রায় ৯০০টি ভিন্ন DPT)

চিহ্নগুলো: এক উৎস, অনেক গন্তব্য-port, অল্প সময়; প্রায় সব SYN, handshake প্রায় সম্পূর্ণ হয় না; port-গুলো প্রায়ই পরিচিত সেবার। উল্টো ধরনও আছে: এক port, অনেক গন্তব্য-ঠিকানা। আর মনে রাখুন, ইন্টারনেটের যেকোনো public ঠিকানা প্রতিদিনই অসংখ্য স্বয়ংক্রিয় scan পায় — প্রশ্ন হলো খোলা অবস্থায় তারা কী পাবে।

নিজের যন্ত্রে কী খোলা আছে — attack surface কমানো

রক্ষকের প্রথম কাজ নিজের attack surface জানা। শুরু নিজের যন্ত্রেই: Linux-এ ss -tuln (পর্ব ০৬) দেখায় কোন TCP আর UDP socket কোন ঠিকানায় শুনছে। একটি সার্ভারের উদাহরণ আউটপুট:

$ ss -tuln        # উদাহরণ আউটপুট, একটি সাধারণ Linux সার্ভার
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
udp   UNCONN 0      0          127.0.0.53%lo:53         0.0.0.0:*
tcp   LISTEN 0      4096         127.0.0.1:5432        0.0.0.0:*
tcp   LISTEN 0      128            0.0.0.0:22          0.0.0.0:*
tcp   LISTEN 0      511            0.0.0.0:443         0.0.0.0:*
tcp   LISTEN 0      511            0.0.0.0:6379        0.0.0.0:*

127.0.0.1 মানে শুধু এই যন্ত্রের ভেতর থেকে পৌঁছানো যায় — ডেটাবেস (5432) ঠিক জায়গায়। 0.0.0.0 মানে সব interface, বাইরে থেকেও। 443 (ওয়েবসাইট) খোলা থাকাই উদ্দেশ্য; 22 (SSH)-এ শুধু key-ভিত্তিক login আর নির্দিষ্ট উৎসের সীমা ভালো। কিন্তু 6379 (একটি in-memory ডেটাবেস, সাধারণত শুধু ভেতরের ব্যবহারের) সব interface-এ শুনছে — 127.0.0.1-এ bind করা বা firewall-এ আটকানো দরকার। নীতিগুলো:

• যা দরকার নেই, বন্ধ করুন; যা দরকার, শুধু দরকারি interface আর উৎসে সীমিত করুন (পর্ব ৪৯), প্রশাসনিক সেবা VPN-এর পেছনে।
• Banner ছোট রাখুন: অনেক সেবা শুরুতে বা header-এ নিজের নাম আর সংস্করণ জানায় (service banner). কমালে স্বয়ংক্রিয় খোঁজে কম তথ্য যায় — তবে এটি গৌণ; আসল প্রতিরক্ষা patch.
• বাইরের চোখে যাচাই হয় নিরাপত্তা দলের অনুমোদিত পরীক্ষা বা লিখিত চুক্তির penetration test-এ — ব্যক্তিগত কৌতূহলে নয়।

Password আক্রমণ — brute force থেকে credential stuffing

খোলা login সেবা পেলে সবচেয়ে সহজ পথ পাসওয়ার্ড অনুমান: brute force — একটি অ্যাকাউন্টে বহু পাসওয়ার্ড; password spraying — বহু অ্যাকাউন্টে অল্প কয়েকটি প্রচলিত পাসওয়ার্ড; আর credential stuffing — অন্য সাইট থেকে ফাঁস হওয়া username-password জোড়া এখানে চেষ্টা।

এখন একটি token bucket (পর্ব ২৬) দিয়ে login-এর প্রতি-IP সীমা simulate করি: প্রতিটি IP-র বালতিতে সর্বোচ্চ ৫টি token, প্রতি ১০ সেকেন্ডে একটি জমে, প্রতিটি চেষ্টায় একটি খরচ। ৬০ সেকেন্ডে চার ধরনের ক্লায়েন্ট: ৮ জন সাধারণ ব্যবহারকারী (প্রত্যেকে ২ বার), NAT-এর পেছনে ১২ জন কর্মীর একটি অফিস (এক IP), ৩টি IP থেকে সেকেন্ডে ৩টি করে credential stuffing, আর ৫০টি IP-র একটি ধীর botnet, প্রতিটি মাত্র ২ বার।

// Per-IP token bucket for login attempts: 5 burst, refill 1 token every 10 s.
const CAP = 5, RATE = 0.1;                   // tokens per second
const events = [];                           // [time s, source IP, kind]
for (let u = 1; u <= 8; u++) events.push([u * 7, "10.1.0." + u, "user"], [u * 7 + 3, "10.1.0." + u, "user"]);
for (let i = 0; i < 12; i++) events.push([2 + 2 * i, "203.0.113.50", "office NAT"]);    // 12 staff, 1 IP
for (const ip of ["198.51.100.7", "198.51.100.8", "198.51.100.9"])
  for (let t = 0; t < 60; t += 1 / 3) events.push([t, ip, "stuffing"]);                // 3 tries/s each
for (let b = 1; b <= 50; b++) events.push([b, "192.0.2." + b, "slow bots"], [b + 5, "192.0.2." + b, "slow bots"]);
events.sort((a, b) => a[0] - b[0]);
const bucket = {}, stat = {};
for (const [t, ip, kind] of events) {
  const s = bucket[ip] || (bucket[ip] = { tokens: CAP, last: t });
  s.tokens = Math.min(CAP, s.tokens + (t - s.last) * RATE); s.last = t;     // refill
  const k = stat[kind] || (stat[kind] = { ips: new Set(), ok: 0, blocked: 0 });
  k.ips.add(ip);
  if (s.tokens >= 1) { s.tokens -= 1; k.ok++; } else k.blocked++;
}
console.log("kind          IPs  allowed  blocked");
for (const [kind, k] of Object.entries(stat))
  console.log(kind.padEnd(13), String(k.ips.size).padStart(3), String(k.ok).padStart(8), String(k.blocked).padStart(8));
console.log("false blocks (legit users refused):", stat["user"].blocked + stat["office NAT"].blocked);
console.log("abusive attempts that got through:", stat["stuffing"].ok + stat["slow bots"].ok);

kind          IPs  allowed  blocked
stuffing        3       30      510
slow bots      50      100        0
office NAT      1        7        5
user            8       16        0
false blocks (legit users refused): 5
abusive attempts that got through: 130

৮ · IDS আর IPS — আক্রমণ চেনার যন্ত্র, আর তার গাণিতিক সীমা

Firewall নিয়ম মেনে দরজা খোলে বা বন্ধ রাখে; খোলা দরজা দিয়ে যা ঢোকে তা ভালো না খারাপ — দেখে IDS (intrusion detection system), আর সন্দেহজনক কিছু পেলে সতর্ক করে। IPS একই বিশ্লেষণ করে ট্রাফিকের পথে (inline) বসে, সন্দেহজনক packet সরাসরি ফেলে দেয়।

প্রচলিত তিনটি open-source নাম: Snort (১৯৯৮ সালে প্রথম প্রকাশ, signature-ভিত্তিক NIDS/IPS-এর পথিকৃৎ), Suricata (বহু-thread-এ চলে, Snort-ধাঁচের নিয়মের বড় অংশ বোঝে), আর Zeek (আগের নাম Bro; মূলত সংযোগ, DNS, HTTP, TLS-এর বিস্তারিত log বানানো আর script দিয়ে বিশ্লেষণের জন্য পরিচিত)। একটি নিরীহ, নীতিমালা-ধাঁচের নিয়মের উদাহরণ:

# উদাহরণ — Snort/Suricata ধাঁচের নিয়ম (সঠিক syntax সংস্করণ ভেদে আলাদা হতে পারে)
# নীতি: ভেতরের কোনো যন্ত্র যেন এনক্রিপশনহীন telnet ব্যবহার না করে
alert tcp $HOME_NET any -> any 23 (msg:"POLICY outbound telnet (unencrypted)"; flags:S; sid:1000001; rev:1;)

বাঁ থেকে ডানে: alert — মিললে কী হবে (IPS-এ হতে পারত drop); tcp; নিজের নেটওয়ার্কের যেকোনো port থেকে যেকোনো গন্তব্যের port 23; বন্ধনীতে বার্তা, শর্ত (flags:S — শুধু প্রথম SYN) আর নিয়মের পরিচয় নম্বর।

এনক্রিপশনের যুগে IDS — বিষয়বস্তু নয়, metadata

আজ ওয়েব ট্রাফিকের বেশিরভাগ TLS বা QUIC-এ এনক্রিপ্টেড, তাই NIDS ভেতরের লেখা পড়তে পারে না। রক্ষকেরা সরে এসেছেন যন্ত্রের ভেতরে (HIDS আর endpoint নজরদারি), কোথাও প্রতিষ্ঠানের নিজের proxy-তে নিয়ন্ত্রিত TLS interception-এ (বড় আপসসহ, পর্ব ৪৮), আর flow বিশ্লেষণে। NetFlow বা তার মানসম্মত উত্তরসূরি IPFIX (RFC 7011) প্রতিটি কথোপকথনের সারসংক্ষেপ দেয় — কে, কার সাথে, কোন port-এ, কখন, কত বাইট — বিষয়বস্তু ছাড়াই। এতেই ধরা যায় scan (এক উৎস, অনেক port), DDoS (হঠাৎ বিপুল pps), নিয়মিত ছন্দে বাইরের এক ঠিকানায় ছোট সংযোগ, বা রাত তিনটায় বাইরে কয়েক GB upload.

নিচের খেলনা anomaly IDS এমন flow-সারসংক্ষেপ নিয়ে কাজ করে: প্রতিটি উৎসের গত ১০ মিনিটের প্রতি-মিনিট নতুন সংযোগ থেকে গড় আর standard deviation, তারপর এই মিনিটের z-score. দুটি নিয়ম: (১) z > ৩ আর অন্তত ৫০টি সংযোগ হলে “volume spike”; (২) অন্তত ১০০টি SYN-এর ২০%-এর কম handshake সম্পূর্ণ হলে “SYN ratio”.

// Toy anomaly IDS on synthetic flow logs: new TCP connections per source per minute.
const flows = {   // last 10 minutes (history), this minute: SYNs sent, handshakes completed
  "10.0.0.21":    { hist: [30, 32, 28, 31, 29, 30, 33, 27, 31, 29], syn: 34,  done: 34 },
  "10.0.0.35":    { hist: [5, 6, 4, 5, 5, 6, 5, 4, 5, 5],           syn: 220, done: 220 },
  "10.0.0.48":    { hist: [40, 80, 20, 60, 90, 30, 70, 50, 85, 45], syn: 95,  done: 93 },
  "203.0.113.66": { hist: [0, 0, 0, 0, 0, 0, 0, 0, 1, 0],           syn: 900, done: 12 },
};
const Z_LIMIT = 3, MIN_COUNT = 50;           // rule 1: unusual volume for THIS source
const RATIO_LIMIT = 0.2, MIN_SYN = 100;      // rule 2: most handshakes never complete
console.log("source         mean   std  now      z  done/syn");
for (const [ip, f] of Object.entries(flows)) {
  const n = f.hist.length, mean = f.hist.reduce((a, b) => a + b) / n;
  const sd = Math.sqrt(f.hist.reduce((a, b) => a + (b - mean) ** 2, 0) / n);
  const z = (f.syn - mean) / Math.max(sd, 1);  // floor sd at 1 so silent hosts don't divide by ~0
  const ratio = f.done / f.syn;
  console.log(ip.padEnd(13), mean.toFixed(1).padStart(6), sd.toFixed(1).padStart(5),
    String(f.syn).padStart(4), z.toFixed(1).padStart(6), ratio.toFixed(2).padStart(9));
  f.alerts = [];
  if (z > Z_LIMIT && f.syn >= MIN_COUNT) f.alerts.push("volume spike (z=" + z.toFixed(1) + ")");
  if (f.syn >= MIN_SYN && ratio < RATIO_LIMIT) f.alerts.push("SYN ratio " + ratio.toFixed(2) + " - scan or flood?");
}
for (const [ip, f] of Object.entries(flows))
  if (f.alerts.length) console.log("ALERT", ip + ":", f.alerts.join("; "));

source         mean   std  now      z  done/syn
10.0.0.21       30.0   1.7   34    2.3      1.00
10.0.0.35        5.0   0.6  220  215.0      1.00
10.0.0.48       57.0  22.7   95    1.7      0.98
203.0.113.66     0.1   0.3  900  899.9      0.01
ALERT 10.0.0.35: volume spike (z=215.0)
ALERT 203.0.113.66: volume spike (z=899.9); SYN ratio 0.01 - scan or flood?

Base-rate fallacy — “৯৯% নির্ভুল” IDS কেন বেশিরভাগ সময় ভুল বলে

Detector-এর দুই ধরনের ভুল: false positive আর false negative (আক্রমণ মিস)। Detector বর্ণনা হয় দুটি হারে: detection rate বা TPR = P(alert | আক্রমণ), আর FPR = P(alert | নিরীহ)। কিন্তু নিরাপত্তা দলের প্রশ্ন উল্টো: alert এলে সেটি আক্রমণ হওয়ার সম্ভাবনা কত? — এর নাম precision. Bayes-এর উপপাদ্য থেকে, p = base rate (সব ঘটনার মধ্যে আক্রমণের অনুপাত) ধরে:

হাতে কষা উদাহরণ: দিনে ১০,০০,০০০টি flow, আসল আক্রমণ ১০টি (p = ০.০০০০১); TPR ৯৯%, FPR ০.১%. সত্যি alert = ১০ × ০.৯৯ = ৯.৯; ভুয়া alert = ৯,৯৯,৯৯০ × ০.০০১ ≈ ১,০০০; precision = ৯.৯ ÷ ১,০১০ ≈ ১%. অর্থাৎ প্রতি ১০০ alert-এর মোটামুটি ৯৯টিই ভুয়া — ভুলের হার ছোট হলেও নিরীহ ঘটনার সংখ্যা বিশাল। এটিই base-rate fallacy; বিরল রোগের পরীক্ষায় প্রথম পজিটিভের পর দ্বিতীয় পরীক্ষা করার কারণও এটাই।

// Base-rate fallacy: how many IDS alerts are real? (Bayes' theorem)
function ids(events, prevalence, tpr, fpr) {
  const bad = events * prevalence, good = events - bad;
  const tp = bad * tpr, fp = good * fpr;      // true alerts, false alarms
  const precision = tp / (tp + fp);           // P(attack | alert)
  console.log(String(fpr).padEnd(8), (tp + fp).toFixed(0).padStart(7), tp.toFixed(1).padStart(6),
    fp.toFixed(1).padStart(8), (precision * 100).toFixed(1).padStart(7) + "%",
    String(Math.round(1 / precision)).padStart(6));
}
const EVENTS = 1e6, PREV = 1e-5, TPR = 0.99;  // 1 million flows/day, 10 of them malicious
console.log("1,000,000 events/day, 10 malicious, detection rate 99%");
console.log("FPR       alerts     TP       FP  precision  1-in-N");
for (const fpr of [1e-2, 1e-3, 1e-4, 1e-5, 1e-6]) ids(EVENTS, PREV, TPR, fpr);
console.log("Same FPR 1e-3 but prevalence 1e-2 (a targeted alert stream):");
ids(EVENTS, 1e-2, TPR, 1e-3);

1,000,000 events/day, 10 malicious, detection rate 99%
FPR       alerts     TP       FP  precision  1-in-N
0.01       10010    9.9   9999.9     0.1%   1011
0.001       1010    9.9   1000.0     1.0%    102
0.0001       110    9.9    100.0     9.0%     11
0.00001       20    9.9     10.0    49.7%      2
0.000001      11    9.9      1.0    90.8%      1
Same FPR 1e-3 but prevalence 1e-2 (a targeted alert stream):
0.001      10890 9900.0    990.0    90.9%      1

৯ · Log, SIEM, honeypot আর একটি alert-এর যাচাই

IDS একা কিছু প্রমাণ করে না — সিদ্ধান্ত আসে অনেক উৎসের log মিলিয়ে: firewall, router, সার্ভার, অ্যাপ, DNS, VPN, login. ভালো log-ব্যবস্থার তিন নিয়ম: এক জায়গায় জমা (syslog বা agent দিয়ে কেন্দ্রীয় সার্ভারে, যাতে আক্রমণকারী একটি সার্ভারের log মুছলেও কপি থাকে); ঠিক সময় (সব ঘড়ি NTP-তে মেলানো, নইলে ঘটনার ক্রম বলা যায় না); আর যথেষ্ট দিন রাখা, কারণ অনুপ্রবেশ প্রায়ই অনেক পরে ধরা পড়ে — তবে log-এ ব্যক্তিগত তথ্য থাকে, তাই কে কতদিন দেখবে তাও নীতির অংশ।

SIEM এই সব log এক জায়গায় এনে খোঁজা, মেলানো আর alert দেওয়ার ব্যবস্থা। শক্তি correlation-এ: “IP X থেকে scan” একা সামান্য, “একই X থেকে ১০ মিনিট পরে সফল VPN login” একসাথে গুরুতর। কিন্তু base rate এখানেও তাড়া করে: নিয়ম বেশি হলে দিনে হাজারো alert, আর বিশ্লেষকেরা ক্লান্ত হয়ে সবকিছু দ্রুত বন্ধ করতে থাকেন — alert fatigue. প্রকাশিত বিভিন্ন বড় অনুপ্রবেশের তদন্তে দেখা গেছে, প্রাসঙ্গিক alert বেজেছিল, কিন্তু ভিড়ে গুরুত্ব পায়নি। প্রতিকার: নিয়মিত tuning, সম্পদের গুরুত্ব ধরে অগ্রাধিকার, আর প্রতিটি নিয়মের precision মাপা।

Honeypot একটি ফাঁদ-যন্ত্র বা সেবা, যার কোনো বৈধ ব্যবহারকারী নেই — তাই এতে যে-ই সংযোগ করে, তা প্রায় নিশ্চিতভাবে ভুল কনফিগারেশন বা কারও খোঁজাখুঁজি। Base-rate-এর ভাষায় এখানে আক্রমণের অনুপাত প্রায় ১, তাই alert-এর precision খুব বেশি। ছোট রূপ honeytoken — যেমন একটি ভুয়া পাসওয়ার্ড, যা ব্যবহার হলেই alert. Honeypot বাকি নেটওয়ার্ক থেকে আলাদা রাখতে হয়, আর উদ্দেশ্য শুধু শনাক্ত করা — পাল্টা আক্রমণ নয়।

একটি alert-এর triage — ধাপে ধাপে

অংশ ৮-এর IDS দুটি alert দিয়েছিল। একজন বিশ্লেষক এগুলো কীভাবে সামলান, দেখি। মূলনীতি: alert একটি প্রশ্ন, উত্তর নয়।

সমস্যা খোঁজার পদ্ধতিগত দিক — packet capture পড়া, অনুমান যাচাই — পর্ব ৫৫-এ (সমস্যা খোঁজা); নিরাপত্তার triage সেই একই বৈজ্ঞানিক মানসিকতার রূপ।

দায়িত্বশীল প্রকাশ, bug bounty আর বাংলাদেশ

কারও সিস্টেমে দুর্বলতা চোখে পড়লে সঠিক পথ responsible disclosure: আর এগোবেন না, অন্যের ডেটা খুলবেন না, প্রতিষ্ঠানকে গোপনে জানান (অনেক সাইট /.well-known/security.txt-এ যোগাযোগের ঠিকানা দেয়, RFC 9116), ঠিক করার সময় দিন। অনেক প্রতিষ্ঠান bug bounty চালায় — নির্দিষ্ট পরিসর আর নিয়মের মধ্যে জানালে পুরস্কার; পরিসরের বাইরে পরীক্ষা তখনো অনুমতিহীন কাজ। বাংলাদেশে সরকারি পর্যায়ে সাইবার ঘটনার সমন্বয়ে একটি জাতীয় CIRT আছে, আর আর্থিক খাতের জন্য নিয়ন্ত্রকের নিজস্ব নিরাপত্তা নির্দেশনা আছে — হালনাগাদ তথ্য অফিসিয়াল সূত্রে দেখুন। ২০১৬ সালের বাংলাদেশ ব্যাংকের রিজার্ভ চুরির ঘটনা segmentation আর নজরদারির গুরুত্বের বহুল আলোচিত উদাহরণ — পর্ব ১৩-এর (VLAN) ভাবনার প্রশ্নে আলোচনা আছে।

১০ · AI-এর যুগে নেটওয়ার্ক নিরাপত্তা — পরামর্শ যাচাই করে নিন

AI সহকারী log ব্যাখ্যা, firewall নিয়মের খসড়া বা alert-এর সম্ভাব্য কারণ ভাবতে সাহায্য করতে পারে। কিন্তু এখানে ভুলের দাম বেশি — একটি ভুল নিয়ম পুরো নেটওয়ার্ক খুলে বা বন্ধ করে দিতে পারে। পরিচিত ভুলগুলো:

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

• প্রস্তাবিত পরিবর্তন attack surface বাড়ায় না কমায়, নিজে বিচার করেছি; “সব খুলে দিন” ধরনের পরামর্শ বাতিল করেছি
• Firewall বা rate-limit-এর নিয়ম আগে ল্যাব বা VM-এ পরীক্ষা করেছি, আর নিজেকে আটকে ফেলার আগে ফেরার পথ (console access) রেখেছি
• Detection-এর দাবিতে base rate ধরে precision হিসাব করেছি
• RFC, CVE আর কমান্ড অফিসিয়াল সূত্র ও man page-এ মিলিয়েছি; ifconfig/netstat-এর বদলে ip/ss কাজ করে কি না দেখেছি
• যা পরীক্ষা করছি তা শুধু নিজের বা অনুমতিপ্রাপ্ত সিস্টেমে, আর log-এর ব্যক্তিগত তথ্য AI-কে দেওয়ার আগে মুছেছি