DDoS প্রতিরক্ষা — হামলার ধরন, capacity আর সাড়া দেওয়ার পরিকল্পনা

১ · DoS আর DDoS — দোকানের দরজায় ভিড় বানানো

ঈদের আগের সন্ধ্যায় নিউমার্কেটের একটি দোকান ভাবুন। হঠাৎ ৫০০ জন লোক ঢুকে পড়ল, কেউ কিছু কিনবে না। তারা শুধু দরজা আটকে দাঁড়িয়ে আছে আর দোকানিকে দাম জিজ্ঞেস করছে। আসল ক্রেতা ভেতরে ঢুকতে পারছেন না। চোর কিছু চুরি করেনি, তালাও ভাঙেনি। তবু দোকানের বিক্রি শূন্য।

এটিই denial of service, সংক্ষেপে DoS. লক্ষ্য তথ্য চুরি নয়, লক্ষ্য availability নষ্ট করা (পর্ব ২). বৈধ ব্যবহারকারী যেন সেবা না পান। DoS একটি উৎস থেকেও হতে পারে, যেমন একটি মাত্র বিশেষ অনুরোধে একটি দুর্বল service আটকে যাওয়া। DDoS মানে Distributed DoS: চাপ আসে হাজার হাজার উৎস থেকে একসাথে।

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

রক্ষকের চোখে আরও একটি কথা: DDoS কখনো কখনো একা আসে না। কিছু প্রকাশিত ঘটনায় দেখা গেছে, রক্ষকের মনোযোগ অন্যদিকে সরাতেও এটি ব্যবহার হতে পারে। তাই হামলার সময়ও login, admin কাজ আর অস্বাভাবিক data বের হওয়ার log দেখা বন্ধ করবেন না।

এই পর্বের প্রতিটি হিসাব আর simulator একটি কাল্পনিক অনলাইন বাজারের ছোট, মনগড়া তথ্যের ওপর চলে। কোনো network traffic পাঠানো হয় না। আইনের সীমা নিয়ে কথা অংশ ৯-এ, আর ভিত্তি আছে পর্ব ৬-এ।

২ · তিন পরিবার — কোন জিনিসটি ভরে যাচ্ছে

ঈদের আগের বাস টার্মিনাল ভাবুন। প্রথম সমস্যা: টার্মিনালে ঢোকার রাস্তাই গাড়িতে বন্ধ। দ্বিতীয় সমস্যা: কাউন্টারে সবাই অর্ধেক ফর্ম ফেলে রেখেছে, কর্মীরা অপেক্ষায় আটকে আছেন। তৃতীয় সমস্যা: লাইন চলছে, কিন্তু প্রত্যেকে এমন প্রশ্ন করছেন যার উত্তর খুঁজতে কর্মীকে গুদামে যেতে হয়। তিনটির ফল একই, কারণ আলাদা। DDoS-এর তিন পরিবারও ঠিক তাই।

Protocol পরিবারের পরিচিত উদাহরণ SYN flood, যার handshake-এর ভিত্তি আছে TCP সংযোগের পর্বে। সাধারণ মানচিত্রটি Computer Networks কোর্সে দেখানো হয়েছে, আর cloud-এ কে কোন স্তর সামলায় তা আছে CDN, WAF আর DDoS সুরক্ষার পর্বে। এখানে আমরা রক্ষকের সিদ্ধান্তে মন দেব।

নিচের ডায়াগ্রামে একটি কাল্পনিক হামলার মিশ্রণ বাইরে থেকে ভেতরে আসছে। প্রতিটি ধাপে দেখুন, কোন traffic কোথায় থেমে যায়। সব সংখ্যা অনুমান।

৩ · Reflection আর amplification — জাল ঠিকানাই মূল ফাঁক

একটি চিঠির কথা ভাবুন। কেউ একজন বহু দোকানে ছোট চিঠি পাঠাল: “আপনাদের পুরো মূল্যতালিকা পাঠান।” প্রেরকের ঘরে সে লিখে দিল আপনার ঠিকানা। পোস্ট অফিস প্রেরকের ঠিকানা যাচাই করে না। দোকানগুলো সৎ, তারা শুধু উত্তর দিচ্ছে। কিন্তু আপনার দরজায় মোটা মোটা খামের স্তূপ জমল, আর আসল চিঠি ঢুকতেই পারছে না।

এটিই reflection: উত্তরটি যায় ভুক্তভোগীর কাছে, কারণ অনুরোধে উৎস ঠিকানা জাল ছিল (spoofing). আর উত্তর অনুরোধের চেয়ে বড় হলে তাকে বলে amplification. হামলাকারীর নিজের সামান্য bandwidth অনেক গুণ বড় হয়ে যায়, আর traffic আসে সাধারণ, বৈধ সার্ভার থেকে।

দুটি শর্ত একসাথে লাগে: উৎস ঠিকানা জাল করা যায়, আর ইন্টারনেটে এমন service আছে যা অচেনা যে কাউকে উত্তর দেয়। সবচেয়ে পরিচিত উদাহরণ open resolver: এমন DNS সার্ভার, যা নিজের ব্যবহারকারী ছাড়াও পৃথিবীর সবার প্রশ্নের উত্তর দেয়। Connection ছাড়া চলা UDP service-এই ঝুঁকিটি বেশি, কারণ TCP-র মতো handshake না থাকলে উত্তর পাঠানোর আগে ঠিকানা যাচাই হয় না। DNS-এর নিজস্ব সুরক্ষা দেখুন পর্ব ২৬-এ।

রক্ষকের দুই দায়িত্ব

• জাল ঠিকানা বেরোতে না দেওয়া: BCP 38 (RFC 2827, ২০০০) বলে, ISP তার গ্রাহকের কাছ থেকে আসা সেই প্যাকেট বাদ দেবে, যার উৎস ঠিকানা ওই গ্রাহকের নিজের ঠিকানার মধ্যে পড়ে না। আপনার প্রতিষ্ঠানের network থেকেও একই নিয়ম প্রযোজ্য।
• নিজের service খোলা না রাখা: Resolver, সময়ের service বা management service যদি শুধু ভেতরের জন্য হয়, তবে ইন্টারনেট থেকে তা বন্ধ রাখুন। আপনি না চাইলেও আপনার সার্ভার অন্যের ওপর হামলার অংশ হতে পারে।

নিচের দুটি উদাহরণ আপনার নিজের সার্ভার আর network-এর জন্য। Address-গুলো documentation-এর, নিজের মান বসিয়ে আগে test পরিবেশে দেখে নেবেন।

# Resolver answers only your own network (Unbound).
server:
    interface: 198.51.100.53
    access-control: 0.0.0.0/0 refuse
    access-control: 198.51.100.0/24 allow
    access-control: 127.0.0.0/8 allow

# Border router: drop packets from LAN whose source is not ours (nftables).
table inet border {
    chain forward {
        type filter hook forward priority 0; policy accept;
        iifname "lan0" ip saddr != 198.51.100.0/24 counter drop
    }
}

৪ · Botnet — যন্ত্রের মালিক জানেন না

DDoS-এর সংখ্যার চাপ কোথা থেকে আসে? প্রায়ই botnet থেকে: মালিকের অজান্তে অপরাধীর নিয়ন্ত্রণে চলে যাওয়া বহু যন্ত্রের জাল। পর্ব ৫-এর command and control ধারণা এখানেও আছে। মালিকের কাছে যন্ত্রটি স্বাভাবিকই চলে। শুধু বিল বা গতিতে সামান্য প্রভাব পড়তে পারে।

Botnet-এ traffic আসে আসল ঠিকানা থেকে, আসল যন্ত্র থেকে। তাই BCP 38 এখানে সাহায্য করে না, আর ঠিকানা ব্লক করলে অনেক সময় সাধারণ গ্রাহকও আটকে যান। এজন্যই application-layer হামলা আলাদা করা কঠিন।

রক্ষকের চোখে Mirai-র শিক্ষা তিনটি:

• Default password ব্যবস্থা-স্তরের ঝুঁকি: একজনের সস্তা camera অন্য কারও ব্যবসা বন্ধ করতে পারে। নিজের যন্ত্রের password বদলান, firmware হালনাগাদ করুন, আর ইন্টারনেট থেকে management বন্ধ রাখুন। IoT নিরাপত্তার বিস্তার পর্ব ৩৫-এ।
• Dependency-ও আপনার ঝুঁকি: Dyn-এর ঘটনায় বহু সাইটের নিজের কোনো দোষ ছিল না। তাদের DNS provider পড়ে গিয়েছিল। তাই DNS-এর মতো ভিত্তি সেবায় একটি মাত্র provider থাকলে সেটি আপনার single point of failure.
• আপনার network-ও উৎস হতে পারে: Outbound traffic-এর হঠাৎ বৃদ্ধি দেখুন। IoT যন্ত্র আলাদা segment-এ রাখুন (পর্ব ২২).

৫ · Capacity মাপা — Gbps, pps, rps আর প্রথম bottleneck

“আমাদের ১ Gbps link আছে, তাই আমরা নিরাপদ।” এই কথায় একটি ভুল আছে। একটি সিস্টেম শিকলের মতো: সবচেয়ে দুর্বল আংটাতেই ছিঁড়বে। সেই আংটাকে বলে bottleneck. তিনটি মাপ আলাদা করে দেখুন।

• Gbps (bit per second): পথ কত চওড়া। এটি রাস্তার প্রস্থের মতো।
• pps (packet per second): কতগুলো প্যাকেট আলাদা করে দেখতে হচ্ছে। এটি টোল প্লাজায় কতটি গাড়ি থামছে, তার মতো। ট্রাক হোক বা রিকশা, প্রতিটিতে একবার থামতে হয়।
• rps (request per second): App কতগুলো অনুরোধের কাজ করছে।

কাজ করা হিসাব

সূত্র: bit/s = pps × bytes × 8. ধরুন ৪,০০,০০০ pps, প্রতিটি প্যাকেট ৬৪ byte: ৪,০০,০০০ × ৬৪ × ৮ = ২০,৪৮,০০,০০০ bit/s, মানে প্রায় ২০৫ Mbps. ১ Gbps link-এর মাত্র ২০%. কিন্তু যে firewall ২,০০,০০০ pps সামলাতে পারে, তার জন্য এটি দ্বিগুণ চাপ।

সবচেয়ে ছোট প্যাকেটে link-এর সীমা: Ethernet-এ সবচেয়ে ছোট frame ৬৪ byte, আর তার সাথে তারের ওপর আরও ২০ byte যায় (preamble আর দুই frame-এর ফাঁক). মোট ৮৪ byte, মানে ৬৭২ bit. ১ Gbps-এ ১,০০,০০,০০,০০০ ÷ ৬৭২ ≈ ১৪,৮৮,০৯৫ pps. তাই “১ Gbps ক্ষমতা” মানে সব যন্ত্র প্রায় ১৪.৯ লাখ pps সামলাতে পারবে, এমন নয়। Datasheet-এ দুটি সংখ্যাই খুঁজুন, আর কোন আকারের প্যাকেটে মাপা হয়েছে তাও দেখুন।

App-এর সীমা: ৬টি সার্ভারে ৫০টি করে worker মানে ৩০০ worker. একটি অনুরোধে গড়ে ১০০ ms লাগলে সীমা ৩০০ ÷ ০.১ = ৩,০০০ rps. কিন্তু একটি search-এ ৫০০ ms লাগলে শুধু search চালিয়ে সীমা ৩০০ ÷ ০.৫ = ৬০০ rps. অর্থাৎ rps-এর সংখ্যা তখনই অর্থবহ, যখন জানেন কোন path-এর rps.

নিচের calculator-এ একই কাল্পনিক অনলাইন বাজারের চারটি স্তর আছে: uplink, firewall, load balancer আর app. পাঁচটি পরিস্থিতিতে দেখুন, কোন স্তর আগে ভরে। সব সীমা অনুমান।

// Toy capacity check: which layer of a made-up shop runs out first?
// All limits and traffic numbers are assumptions, not measurements.
const layers = [
  { name: 'uplink', unit: 'Mbps', limit: 1000, load: t => t.pps * t.bytes * 8 / 1e6 },
  { name: 'firewall', unit: 'pps', limit: 200000, load: t => t.pps },
  { name: 'load balancer', unit: 'conn/s', limit: 20000, load: t => t.cps },
  { name: 'app + database', unit: 'rps', limit: 3000, load: t => t.rps },
];
const scenarios = [
  { name: 'normal evening', pps: 40000, bytes: 625, cps: 1500, rps: 1200 },
  { name: 'sale peak x3', pps: 120000, bytes: 625, cps: 4500, rps: 3600 },
  { name: 'small-packet flood', pps: 400000, bytes: 64, cps: 1500, rps: 1200 },
  { name: 'large-packet flood', pps: 300000, bytes: 1200, cps: 1500, rps: 1200 },
  { name: 'costly-page flood', pps: 45000, bytes: 625, cps: 2000, rps: 7500 },
];
for (const s of scenarios) {
  console.log(`--- ${s.name}`);
  let first = null, worst = 0;
  for (const l of layers) {
    const used = l.load(s) / l.limit;
    const load = Math.round(l.load(s));
    const mark = used >= 1 ? ' OVER' : '';
    console.log(`${l.name.padEnd(15)} ${String(load).padStart(7)} / ${String(l.limit).padStart(6)} ${l.unit.padEnd(6)} ${(used * 100).toFixed(0).padStart(4)}%${mark}`);
    if (used > worst) { worst = used; first = l.name; }
  }
  console.log(worst >= 1 ? `bottleneck: ${first}` : `no layer over limit, tightest: ${first}`);
}

নিজের সংখ্যা কীভাবে জানবেন

• নিজের সীমা লিখে রাখুন: প্রতিটি স্তরের Gbps, pps, connection-এর সীমা আর প্রধান path-এর rps. Datasheet নয়, নিজের পরিবেশে মাপা সংখ্যা ভালো।
• স্বাভাবিকের রেখা (baseline) রাখুন: দিন আর ঘণ্টা ধরে কত traffic হয়, না জানলে অস্বাভাবিকও চিনবেন না।
• নিজের সিস্টেমে load test: অনুমতিসহ, নির্দিষ্ট সময়ে, staging-এ বা provider-কে জানিয়ে (অংশ ৯ দেখুন).

৬ · নেটওয়ার্কের স্তরে প্রতিরক্ষা — anycast, CDN, scrubbing আর SYN cookie

পানি উঠলে ঘরের ভেতরে বালতি দিয়ে কাজ হয় না, বাঁধ দিতে হয় নদীর ধারে। Volumetric চাপও তাই। আপনার link ভরে গেলে ভেতরের কোনো নিয়ম আর কাজে আসে না, কারণ ভালো-মন্দ দুটি প্যাকেটই পথে আটকে আছে। তাই শোষণের জায়গা হতে হবে আপনার link-এর আগে।

SYN cookie — টেবিলে না লিখে মনে রাখা

TCP-তে client SYN পাঠালে সার্ভার SYN-ACK দেয়, আর উত্তরের অপেক্ষায় একটি অর্ধেক-খোলা entry রাখে তার SYN backlog-এ। জাল উৎসের SYN-এর উত্তর কখনো আসে না, তাই সেই entry timeout পর্যন্ত জায়গা দখল করে থাকে। সারি ভরলে আসল ক্রেতাও আর ঢুকতে পারেন না।

SYN cookie-র কৌশল সুন্দর। ডাকঘরে পার্সেল জমা না রেখে একটি সিলমোহর দেওয়া রসিদ ধরিয়ে দেওয়ার মতো। সার্ভার কিছু জমা রাখে না। সে একটি গোপন চাবি দিয়ে হিসাব করা মান sequence number হিসেবে পাঠায়। সত্যিকারের client সেটি ফেরত দিলে, সার্ভার আবার হিসাব করে মিলিয়ে নেয়।

নিচের simulator একটি ১২৮ ঘরের খেলনা backlog চালায়। প্রতি tick-এ ১০ জন আসল client আসে, আর জাল SYN আসে ৬০টি। প্রতিটি entry ৫ tick পরে মুছে যায়। সিড-করা PRNG শুধু আগমনের ক্রম এলোমেলো করে, তাই ফল প্রতিবার একই।

// Toy SYN backlog on a simulated clock. Sends nothing; only arrays and counters.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const CAP = 128, TIMEOUT = 5, TICKS = 20, FAKE_PER_TICK = 60, REAL_PER_TICK = 10;
function run(label, cookies, fakeRate) {
  const rnd = mulberry32(2026);
  let backlog = [], ok = 0, refused = 0, stored = 0, peak = 0;
  for (let t = 0; t < TICKS; t++) {
    backlog = backlog.filter(expiry => expiry > t);           // half-open entries time out
    const arrivals = [...Array(fakeRate).fill('fake'), ...Array(REAL_PER_TICK).fill('real')];
    for (let i = arrivals.length - 1; i > 0; i--) {           // shuffle arrival order
      const j = Math.floor(rnd() * (i + 1));
      [arrivals[i], arrivals[j]] = [arrivals[j], arrivals[i]];
    }
    for (const who of arrivals) {
      const full = backlog.length >= CAP;
      if (full && cookies) { if (who === 'real') ok++; continue; }  // no entry stored
      if (full) { if (who === 'real') refused++; continue; }
      if (who === 'real') ok++;                                 // ACK returns at once
      else { backlog.push(t + TIMEOUT); stored++; }             // spoofed: ACK never comes
    }
    peak = Math.max(peak, backlog.length);
  }
  const total = TICKS * REAL_PER_TICK;
  console.log(`${label.padEnd(24)} real ok ${String(ok).padStart(3)}/${total}  refused ${String(refused).padStart(3)}  backlog peak ${peak}/${CAP}`);
}
run('no flood', false, 0);
run('flood, no cookies', false, FAKE_PER_TICK);
run('flood, with cookies', true, FAKE_PER_TICK);

# Read your own server's settings and counters. Values differ by system.
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog
nstat -az TcpExtSyncookiesSent TcpExtSyncookiesRecv TcpExtListenDrops
# In /etc/sysctl.d/90-tcp.conf (1 = use cookies when the queue overflows):
# net.ipv4.tcp_syncookies = 1

৭ · Application স্তরে — rate limit, WAF, cache আর autoscaling-এর ফাঁদ

Application-layer চাপে প্রতিটি অনুরোধ দেখতে স্বাভাবিক। Provider জানে না আপনার কোন path দামি। এই অংশের কাজ অনেকটাই আপনার নিজের। আগের কোর্সে rate limiting-এর পুরো নকশা আর resilience pattern দেখানো হয়েছে। এখানে শুধু DDoS-এর দৃষ্টিতে দেখি।

নিচের token bucket খেলনাটি দেখুন। প্রতিটি key-র একটি বালতি আছে, যাতে সর্বোচ্চ ১০টি token ধরে। সেকেন্ডে ৫টি token জমে। প্রতিটি অনুরোধে একটি token খরচ হয়। Clock simulated, ১০ সেকেন্ড চলে, আর শেষের সারিটি লক্ষ করুন।

// Token bucket per client key on a simulated clock (ms). Toy stream, no network.
const RATE = 5, BURST = 10, DURATION = 10000;      // 5 tokens/s, bucket holds 10
const clients = [
  { key: 'shopper 203.0.113.10', rps: 1 },
  { key: 'keen user 203.0.113.11', rps: 4 },
  { key: 'abuser 198.51.100.7', rps: 50 },
  { key: '40 users behind one CGNAT IP', rps: 40 },
];
function decide(bucket, now) {
  bucket.tokens = Math.min(BURST, bucket.tokens + (now - bucket.last) * RATE / 1000);
  bucket.last = now;
  if (bucket.tokens >= 1) { bucket.tokens -= 1; return true; }
  return false;
}
console.log('client                         sent  allowed  limited');
for (const c of clients) {
  const bucket = { tokens: BURST, last: 0 };
  const gap = 1000 / c.rps;
  let allowed = 0, limited = 0;
  for (let i = 0, now = 0; now < DURATION; i++, now = i * gap) {
    if (decide(bucket, now)) allowed++; else limited++;
  }
  console.log(`${c.key.padEnd(30)} ${String(allowed + limited).padStart(4)} ${String(allowed).padStart(8)} ${String(limited).padStart(8)}`);
}
console.log(`ceiling in 10 s = ${BURST} burst + ${RATE} * 10 refill = ${BURST + RATE * 10}`);

# Inside http { }: per-client state for your own site.
limit_req_zone  $binary_remote_addr zone=search:10m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=peraddr:10m;

server {
    location /search {
        limit_req zone=search burst=10 nodelay;
        limit_req_status 429;
        limit_conn peraddr 20;
        proxy_pass http://app_backend;
    }
}

CDN-এর পেছনে থাকলে $binary_remote_addr হবে CDN-এর ঠিকানা, ক্রেতার নয়। আগে আসল client ঠিকানা নিরাপদে নেওয়ার ব্যবস্থা করুন, শুধু বিশ্বস্ত proxy-র header মেনে।

Autoscaling-এর ফাঁদ: হামলা থামল না, শুধু bill বাড়ল

ধরুন একটি সার্ভার ৫০০ rps সামলায়, আর হামলা ৭,৫০০ rps যোগ করল। Autoscaling ৭,৫০০ ÷ ৫০০ = ১৫টি বাড়তি সার্ভার চালু করবে। ধরা যাক প্রতি সার্ভার-ঘণ্টার খরচ ৳২০ (এটি শুধু অনুমান). ৭২ ঘণ্টায় ১৫ × ৭২ × ৳২০ = ৳২১,৬০০, এর সাথে data transfer আর log-এর খরচ যোগ হবে। হামলাকারী খরচ বাড়াতে পারলেই কিছুটা সফল। একে অনেকে economic denial of sustainability বলেন। অন্যদিকে database-এর সীমা একই থাকলে bottleneck শুধু এক ধাপ ভেতরে সরে যায়।

• সর্বোচ্চ সীমা রাখুন: Autoscaling-এর ছাদ আর bill-এর alert.
• দামি path আগে রক্ষা করুন: Search, login, report, OTP পাঠানো। এখানে কড়া সীমা আর queue.
• Graceful degradation: চাপে search সীমিত করুন, কিন্তু checkout চালু রাখুন।
• Provider-এর শর্ত পড়ুন: কিছু paid সুরক্ষায় হামলার সময়ের বাড়তি খরচ নিয়ে শর্ত থাকে। চুক্তিতে যাচাই করুন।

৮ · উজানের সাহায্য আর সাড়ার পরিকল্পনা

আপনার link ভরলে সমাধান আপনার ঘরে নেই, আছে আপনার ISP-র হাতে। হামলা শুরু হওয়ার পরে প্রথমবার ISP-র NOC-এর নম্বর খোঁজা খুব খারাপ পরিকল্পনা। তাই আগে থেকে জানুন, ISP কী কী দিতে পারে, চুক্তিতে কী আছে, আর কত সময়ে দেবে।

Blackholing-কে বাড়িতে আগুন লাগলে একটি ঘরের দরজা বন্ধ করে পুরো বাড়ি বাঁচানোর মতো ভাবুন। একই IP-তে সবকিছু থাকলে পুরো সেবাই বন্ধ হবে, তাই গুরুত্বপূর্ণ সেবাগুলো আলাদা ঠিকানায় রাখা ভালো।

DDoS runbook-এ যা থাকবে

Runbook হলো চাপের মধ্যে অনুসরণ করার লেখা ধাপ। সাধারণ incident-এর ভিত্তি Incident management পর্বে আছে, আর পুরো IR প্রক্রিয়া আসবে পর্ব ৬১-এ। DDoS-এর জন্য বিশেষ করে যা লাগে:

৯ · ভিড় না হামলা — একটি সেলের দিন আর পরীক্ষার সীমা

ঈদের সেলের রাত ৮টা। লাখো মানুষ একসাথে ঢুকলেন, সাইট ধীর হলো। এটি flash crowd, হামলা নয়। ভুল করে আসল ক্রেতাকে block করলে আপনি নিজেই সেই ক্ষতি করবেন, যা হামলাকারী চাইছিল। আবার হামলাকে “ভিড়” ভেবে অপেক্ষা করলেও বিক্রি যায়। পার্থক্য চেনার কিছু সংকেত:

কোনো একটি সংকেত একা যথেষ্ট নয়। সাইট খুব ধীর হলে আসল ক্রেতারাও অর্ডার করতে পারেন না, তাই conversion পড়ে যায়। নিচের খেলনা নিয়মটি কয়েকটি সংকেত মিলিয়ে ৭টি সময়-খণ্ড বিচার করে। ফল তিন রকম: crowd, attack, আর অনিশ্চিত হলে human.

// Toy triage rule: flash crowd or attack? Windows and labels are invented.
// conv = orders per 100 sessions (normal is 3.0), local = share from usual regions,
// dc = share from data-centre networks, pages = pages per session, campaign = announced.
const windows = [
  { id: 'W1', truth: 'crowd', x: 4, conv: 3.4, local: 0.93, dc: 0.02, pages: 5.1, campaign: true },
  { id: 'W2', truth: 'crowd', x: 6, conv: 1.9, local: 0.90, dc: 0.03, pages: 3.8, campaign: true },
  { id: 'W3', truth: 'crowd', x: 3, conv: 2.6, local: 0.88, dc: 0.04, pages: 2.9, campaign: false },
  { id: 'W4', truth: 'crowd', x: 8, conv: 0.4, local: 0.91, dc: 0.03, pages: 1.2, campaign: true },
  { id: 'W5', truth: 'attack', x: 9, conv: 0.1, local: 0.31, dc: 0.58, pages: 1.1, campaign: false },
  { id: 'W6', truth: 'attack', x: 5, conv: 0.3, local: 0.42, dc: 0.47, pages: 1.0, campaign: true },
  { id: 'W7', truth: 'attack', x: 4, conv: 1.0, local: 0.71, dc: 0.12, pages: 1.3, campaign: false },
];
function score(w) {
  let s = 0;
  if (w.conv < 1.0) s += 2;
  if (w.local < 0.6) s += 2;
  if (w.dc > 0.3) s += 2;
  if (w.pages < 1.5) s += 1;
  if (w.campaign) s -= 2;
  return s;
}
const verdict = s => (s >= 3 ? 'attack' : s <= 0 ? 'crowd' : 'human');
let tp = 0, fp = 0, human = 0;
console.log('id  size   score  verdict  truth');
for (const w of windows) {
  const s = score(w), v = verdict(s);
  console.log(`${w.id}  x${w.x}  ${String(s).padStart(6)}  ${v.padEnd(7)}  ${w.truth}`);
  if (v === 'human') { human++; continue; }
  if (v === 'attack' && w.truth === 'attack') tp++;
  if (v === 'attack' && w.truth === 'crowd') fp++;
}
console.log(`sent to a person: ${human}`);
const attacks = windows.filter(w => w.truth === 'attack').length;
console.log(`precision ${(tp / (tp + fp)).toFixed(2)}  recall ${(tp / attacks).toFixed(2)}`);

একটি কাল্পনিক সেলের রাত

এবার সব মিলিয়ে দেখি। কাল্পনিক অনলাইন বাজার, origin-এর সীমা ৩,০০০ rps, uplink ১ Gbps, আর স্বাভাবিক cache hit ৬০%. মোট rps মানে edge-এ আসা সব অনুরোধ। ধাপে ধাপে এগিয়ে দেখুন, প্রতিটি সংখ্যা কী সিদ্ধান্তের জন্ম দিচ্ছে।

ঘটনার পরের পর্যালোচনা

Post-incident review-এ মানুষকে দোষ না দিয়ে ব্যবস্থাকে প্রশ্ন করুন। উপরের ঘটনায় কয়েকটি প্রশ্ন:

• সময়রেখা: Alert কখন, সিদ্ধান্ত কখন, প্রতিকার কখন? ২০:১২ থেকে ২০:২৩, মানে ১১ মিনিট, কমানো যায় কি?
• Alert ঠিক ছিল? /search-এর আলাদা মাপ থাকলে আগে ধরা পড়ত কি?
• কী কাজ করেনি? Search-এ cache আগে থেকে থাকলে কেমন হতো? /search ৬০ সেকেন্ডের cache-এ ভুল ফল দিয়েছিল কি?
• কার ক্ষতি হলো? কতজন আসল ক্রেতা আটকেছেন, কত অর্ডার গেছে? এটি মাপুন, শুধু হামলার আকার নয়।
• কী বদলাবে? প্রতিটি সিদ্ধান্তের একজন মালিক আর একটি তারিখ। Runbook হালনাগাদ, আর একটি মহড়া (পর্ব ৬৬).

পরীক্ষার আইনি সীমা

১০ · AI-এর যুগে DDoS-এর প্রস্তুতি

AI একটি runbook-এর খসড়া, nginx-এর সীমা বা log-এর সারাংশ খুব দ্রুত দিতে পারে। কিন্তু সে আপনার traffic, চুক্তি আর গ্রাহককে দেখতে পায় না। হামলার সময়ের একটি ভুল নিয়ম নিজেই outage হতে পারে।

AI-এর পরামর্শ কাজে লাগানোর চেকলিস্ট

• প্রতিটি RFC, standard বা CVE নম্বর মূল সূত্রে পড়েছি
• Rate limit বা WAF নিয়ম আগে count mode-এ বা staging-এ চালিয়েছি
• নিয়মটি CGNAT-এর গ্রাহক আর বিশ্বস্ত proxy-র ক্ষেত্রে কী করবে, ভেবেছি
• Prompt-এ কোনো গোপন তথ্য, key বা গ্রাহকের ব্যক্তিগত ডেটা দিইনি
• নিয়ম বদলানোর আগে rollback-এর পথ ঠিক করেছি, আর সিদ্ধান্ত মানুষ নিয়েছেন