Ransomware প্রতিরক্ষা — প্রতিরোধ, immutable backup আর পুনরুদ্ধার

১ · Ransomware-এর ব্যবসা — চাঁদাবাজি যখন ফ্র্যাঞ্চাইজি

ভাবুন, আপনার দোকানে রাতে কেউ ঢুকল। সে কিছু নিল না। শুধু আলমারিতে নতুন তালা লাগিয়ে একটি চিরকুট রেখে গেল: “চাবি চাইলে টাকা দিন।” এই হলো ransomware-এর মূল ধারণা। ডেটা আপনার যন্ত্রেই আছে, কিন্তু ব্যবহার করতে পারছেন না। পর্ব ২-এর ভাষায়, প্রথম আঘাত availability-র ওপর। Malware-এর সাধারণ পরিবার আর আচরণ পর্ব ৩৩-এ আছে। এখানে আমরা শুধু এই একটি ঝুঁকিতে মন দেব।

আজকের চিরকুটে আরেকটি লাইন থাকে: “আপনার হিসাবের খাতার কপিও আমাদের কাছে। টাকা না দিলে বাজারে ছড়িয়ে দেব।” একে বলে double extortion. আগে ডেটা গোপনে বাইরে নেওয়া হয় (exfiltration), তারপর ফাইল অচল করা হয়। ফলে ভালো backup থাকলেও চাপের একটি অংশ থেকে যায়, কারণ এবার ঝুঁকি confidentiality-র। প্রকাশিত প্রতিবেদনে কখনো সেবা বন্ধ করার চাপ বা গ্রাহকদের সরাসরি যোগাযোগের কথাও আসে।

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

২ · হামলার ধাপ, রক্ষকের চোখে — কোথায় শিকল ভাঙবেন

স্ক্রিনে চিরকুট দেখা গেলেই অনেকে ভাবেন হামলা এইমাত্র শুরু হলো। আসলে সেটি প্রায়ই শেষ দৃশ্য। অনুপ্রবেশ থেকে ধরা পড়া পর্যন্ত সময়কে বলে dwell time. এই সময়টিই রক্ষকের সুযোগ। পর্ব ৫-এর kill chain আর ATT&CK মানচিত্র এখানে কাজে লাগে: প্রতিটি ধাপ একটি সংযোগ, আর শিকলের একটি সংযোগ ভাঙলেই হয়।

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

৩ · প্রতিরোধ — ছয়টি বাধা, প্রতিটির সীমাসহ

বেশিরভাগ সুপারিশ নতুন কিছু নয়। আগের পর্বগুলোর control-ই এখানে এক লক্ষ্যে কাজ করে। তাই বিস্তারিত না বলে শুধু দেখি, কোনটি কী থামায় আর কী থামায় না।

একটি অগ্রাধিকার মনে রাখুন। প্রথম কাজ Internet থেকে খোলা সব পথের তালিকা বানানো (attack surface, পর্ব ৪). Colonial Pipeline-এর ঘটনায় (অংশ ৯) সমস্যাটি ঠিক এখানেই ছিল: প্রতিষ্ঠানের নিজের অজানা একটি পুরোনো পথ। Remote access-এর ভালো নকশা দেখুন পর্ব ২৫-এ।

৪ · Backup — 3-2-1-1-0 আর হামলাকারী কেন আগে backup খোঁজে

জমির দলিলের কথা ভাবুন। আসলটি ব্যাংকের লকারে, ফটোকপি বাড়িতে, আরেকটি ভাইয়ের বাসায়। বাড়িতে আগুন লাগলে লকার বাঁচায়। লকারের চাবি বাড়ির একই ড্রয়ারে রাখলে কিন্তু চোর দুটোই পায়। Backup-এর সব নিয়ম এই চিন্তার বিস্তার।

হামলাকারীর হিসাবটি সরল: আপনি নিজে ফিরতে পারলে টাকা দেবেন না। তাই backup নষ্ট করা তার ব্যবসার অংশ। ATT&CK-এ এটি আলাদা করে আছে: Inhibit System Recovery (T1490), আর ফাইল অচল করা Data Encrypted for Impact (T1486). অনলাইন backup আর মূল system যদি একই admin login-এ চলে, তাহলে backup হলো একই বাড়ির আরেকটি ঘর।

3-2-1-1-0 কোনো আনুষ্ঠানিক standard নয়। এটি পুরোনো 3-2-1 নিয়মের ওপর backup শিল্পে জনপ্রিয় হওয়া একটি বিস্তার, তাই সূত্রভেদে শব্দ একটু আলাদা হতে পারে। মূল চিন্তাটি আসল কথা: একটি কপি এমন থাকবে, যা admin-এর চুরি হওয়া login দিয়েও মোছা যায় না।

Immutable, offline আর “প্রায় backup”-এর পার্থক্য

• Offline বা air gap: Network থেকে শারীরিকভাবে আলাদা, যেমন খুলে রাখা disk বা tape. সবচেয়ে সোজা সুরক্ষা। কিন্তু হাতে কাজ, আনতে সময় লাগে, আর হারাতে পারে।
• Immutable: নির্দিষ্ট সময় পর্যন্ত মোছা বা বদলানো যায় না। অনেক storage-এ এই সুবিধা object lock নামে আছে। সাবধান: কিছু mode-এ বিশেষ অধিকারী এই তালা খুলতে পারেন। কোন mode, কে খুলতে পারে, আর পুরো account বন্ধ হলে কী হয়, যাচাই করুন। ভুল retention-এ খরচও বাড়ে।
• Sync backup নয়: Cloud sync অচল ফাইলকেও বিশ্বস্তভাবে কপি করে। Version history কিছুটা বাঁচাতে পারে, তবে সীমা জেনে নিন।
• Replication backup নয়: ভুল আর মোছাও সাথে সাথে চলে যায়। Shadow copy বা একই disk-এর snapshot-ও শুধু দ্রুত ফেরার সুবিধা, ransomware-এর ভরসা নয়।

Backup-এর login রক্ষা

• Backup system মূল domain-এ যুক্ত না করে আলাদা পরিচয় রাখুন, MFA সহ।
• Backup network আলাদা zone-এ রাখুন, management শুধু নির্দিষ্ট পথে খুলুন।
• Retention কমানো বা কপি মোছায় দুজনের অনুমোদন রাখুন (maker-checker).
• Backup encrypt করলে key মূল পরিবেশের বাইরে রাখুন, একটি কপি offline. Key হারালে backup-ও হারাল।

নিচের audit খেলনা চারটি পরিকল্পনাকে নিয়মের পাঁচটি শর্ত আর একটি বাড়তি শর্তে মাপে। বাড়তি শর্তটি own login: backup-এর আলাদা login আছে কি না।

// Toy audit of made-up backup plans against 3-2-1-1-0. Touches no real system.
// Each copy: media type, offsite?, isolated? (immutable or offline).
const live = { media: 'disk', offsite: false, isolated: false };
const nas = { media: 'disk', offsite: false, isolated: false };
const sync = { media: 'cloud', offsite: true, isolated: false };
const tape = { media: 'tape', offsite: true, isolated: true };
const locked = { media: 'cloud', offsite: true, isolated: true };

const plans = [
  { name: 'office-nas', copies: [live, nas], errors: null, ownLogin: false },
  { name: 'cloud-sync', copies: [live, nas, sync], errors: null, ownLogin: false },
  { name: 'monthly-tape', copies: [live, nas, tape], errors: 3, ownLogin: true },
  { name: 'locked-cloud', copies: [live, nas, locked], errors: 0, ownLogin: true },
];
const rules = [
  ['3 copies', p => p.copies.length >= 3],
  ['2 media', p => new Set(p.copies.map(c => c.media)).size >= 2],
  ['1 offsite', p => p.copies.some(c => c.offsite)],
  ['1 isolated', p => p.copies.some(c => c.isolated)],
  ['0 errors', p => p.errors === 0],     // null = restore never tested
  ['own login', p => p.ownLogin],        // extra check, not part of the rule
];
for (const p of plans) {
  const failed = rules.filter(([, check]) => !check(p)).map(([label]) => label);
  const score = rules.length - failed.length;
  console.log(`${p.name.padEnd(13)} ${score}/${rules.length}  ` +
    (failed.length ? `FAIL: ${failed.join(', ')}` : 'PASS'));
}

৫ · Restore পরীক্ষা, RPO আর RTO — অনুমান নয়, সংখ্যা

লোডশেডিংয়ের জন্য অফিসে একটি জেনারেটর আছে। এক বছর ধরে কেউ চালিয়ে দেখেনি। যেদিন দরকার পড়ল, সেদিন জানা গেল ডিজেল নেই, ব্যাটারি মরে গেছে। কেনা জেনারেটর আর চালু জেনারেটর এক জিনিস নয়। Backup-ও তাই। যে backup থেকে কখনো ফেরানো হয়নি, সেটি একটি আশা।

দুটি সংখ্যা ব্যবসার সাথে কথা বলার ভাষা। বিস্তারিত আছে Cloud কোর্সের Backup আর disaster recovery পর্বে। সংক্ষেপে:

সূত্র: copy hours = GB × 8000 ÷ Mbps ÷ 3600. ধরুন ১২ TB ডেটা, মানে ১২,০০০ GB, আর আসল গতি ৪০০ Mbps. ১২,০০০ × ৮,০০০ = ৯,৬০,০০,০০০ megabit. একে ৪০০ দিয়ে ভাগ করলে ২,৪০,০০০ সেকেন্ড, মানে প্রায় ৬৬.৭ ঘণ্টা। তারপর মোট = আনা + rebuild + কপি + যাচাই. Rebuild ৮ ঘণ্টা আর যাচাই ৬ ঘণ্টা ধরলে মোট ৮০.৭ ঘণ্টা, প্রায় সাড়ে তিন দিন। লক্ষ্য ২৪ ঘণ্টা হলে পরিকল্পনাটি কাগজেই ফেল।

Ransomware-এর বিশেষ মোচড়: বন্যা বা disk নষ্টের ক্ষেত্রে সবচেয়ে নতুন backup-ই সেরা। Ransomware-এ তা নয়। হামলাকারী ১৮ দিন ভেতরে থাকলে গত ১৮ দিনের system কপিগুলোতেও তার ব্যবস্থা থাকতে পারে। তাই retention অন্তত সম্ভাব্য dwell time-এর চেয়ে লম্বা হওয়া উচিত। ১৪ দিনের retention আর ১৮ দিনের dwell time মানে আপনার কোনো system কপিই নিশ্চিতভাবে পরিষ্কার নয়। আর পরিষ্কার বিন্দুতে ফিরতে হলে আসল ডেটা হারানোর পরিমাণ RPO ছাড়িয়ে যায়।

// Restore time and data loss for a made-up office. All numbers are assumptions.
// copy hours = GB x 8000 megabits / Mbps / 3600 seconds
const target = { rtoH: 24, rpoH: 24 };
const plans = [
  { name: 'everything at once', gb: 12000, mbps: 400, fetchH: 0, rebuildH: 8, checkH: 6, everyH: 24, backH: 0 },
  { name: 'tier 1 only', gb: 1500, mbps: 400, fetchH: 0, rebuildH: 8, checkH: 3, everyH: 24, backH: 0 },
  { name: 'tier 1, offline media', gb: 1500, mbps: 2000, fetchH: 6, rebuildH: 8, checkH: 3, everyH: 24, backH: 0 },
  { name: 'tier 1, 4-hourly', gb: 1500, mbps: 400, fetchH: 0, rebuildH: 8, checkH: 3, everyH: 4, backH: 0 },
  { name: 'tier 1, clean 5 days back', gb: 1500, mbps: 400, fetchH: 0, rebuildH: 8, checkH: 3, everyH: 4, backH: 120 },
];
for (const p of plans) {
  const copyH = p.gb * 8000 / p.mbps / 3600;
  const rtoH = p.fetchH + p.rebuildH + copyH + p.checkH;
  // Worst case: failure just before the next job, plus any roll-back to a clean point.
  const rpoH = p.everyH + p.backH;
  const verdict = (rtoH <= target.rtoH ? 'RTO ok ' : 'RTO MISS') + ' ' +
    (rpoH <= target.rpoH ? 'RPO ok' : 'RPO MISS');
  console.log(`${p.name.padEnd(26)} copy ${copyH.toFixed(1).padStart(5)} h  ` +
    `total ${rtoH.toFixed(1).padStart(5)} h  loss ${String(rpoH).padStart(3)} h  ${verdict}`);
}

এবার একটি ছোট restore test ঘড়ি ধরে দেখি। ফাইল সার্ভারের ২০০ GB, লক্ষ্য RTO ৪ ঘণ্টা আর RPO ২৪ ঘণ্টা। সব সংখ্যা অনুমান।

৬ · Detection — শেষ মুহূর্তের আগের সংকেত

দারোয়ান যদি শুধু আগুন দেখলে খবর দেন, দেরি হয়ে যায়। ধোঁয়ার গন্ধেই খবর দেওয়া চাই। Ransomware-এর “ধোঁয়া” কয়েক রকম। এগুলো SIEM বা EDR-এ জুড়ুন, তারপর false positive সামলান।

নিচে একটি Sigma নিয়মের উদাহরণ, যা নিজের Windows পরিবেশের process log পড়ে একটি পরিচিত shadow copy মোছার চিহ্ন খোঁজে। এটি শুধু detection, আপনার নিজের log-এ ব্যবহারের জন্য। একই কাজ অন্য পথেও হতে পারে, তাই এক নিয়মের ওপর ভরসা করবেন না। ফলে backup-এর সতর্কবার্তা আর আচরণভিত্তিক সংকেতও রাখুন।

title: Shadow copy deletion by vssadmin (teaching example)
status: experimental
description: A process asked vssadmin to delete shadow copies.
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains|all:
      - 'delete'
      - 'shadows'
  condition: selection
falsepositives:
  - Rare, planned administrator maintenance
level: high
tags:
  - attack.impact
  - attack.t1490

গণহারে ফাইল বদল ধরার সহজ উপায়: প্রতিটি process-এর জন্য একটি sliding window রাখা, যা গত ৬০ সেকেন্ডের ঘটনা গোনে। নিচের ঘটনার ধারা কৃত্রিম, seeded PRNG আর simulated clock দিয়ে বানানো। এখানে “ঘটনা” মানে শুধু একটি লেবেল, কোনো ফাইলে কিছু হয় না।

// Mass-change detector on a toy event stream. Simulated clock; no real files.
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 rand = mulberry32(34), events = [];
for (let t = 0; t < 600; t++) {
  if (rand() < 0.2) events.push({ t, proc: 'word' });         // normal office work
  if (t >= 200 && t < 230) events.push({ t, proc: 'sync' }, { t, proc: 'sync' }); // nightly sync
  if (t >= 400) for (let i = 0; i < 4; i++) events.push({ t, proc: 'unknown' });  // incident
}
function detect(limit, windowSec, allow) {
  const seen = {}, alerts = [];
  for (const e of events) {
    if (allow.includes(e.proc)) continue;
    const w = (seen[e.proc] ||= []);
    w.push(e.t);
    while (w[0] <= e.t - windowSec) w.shift();
    if (w.length >= limit && !alerts.some(a => a.proc === e.proc)) alerts.push({ proc: e.proc, t: e.t });
  }
  return alerts;
}
const hurt = t => events.filter(e => e.proc === 'unknown' && e.t <= t).length;
console.log(`events ${events.length}, unknown starts at t=400`);
for (const [limit, allow] of [[10, []], [50, []], [50, ['sync']], [400, ['sync']]]) {
  const alerts = detect(limit, 60, allow);
  const hit = alerts.find(a => a.proc === 'unknown');
  console.log(`limit ${String(limit).padStart(3)}/60s allow [${allow}]  alerts: ` +
    `${alerts.map(a => `${a.proc}@${a.t}`).join(' ') || 'none'}  ` +
    `changed before alert: ${hit ? hurt(hit.t) : 'all ' + hurt(600)}`);
}

৭ · সাড়ার playbook — আর টাকা দেওয়ার সিদ্ধান্ত

হামলার রাতে মানুষ ভালো সিদ্ধান্ত নিতে পারেন না। তাই সিদ্ধান্তগুলো আগেই লেখা থাকা চাই, ছাপা কাগজে, কারণ অনলাইনের নথিও তখন অচল হতে পারে। সাধারণ incident response-এর কাঠামো পর্ব ৬১-তে আর containment-এর গভীরতা পর্ব ৬২-তে থাকবে। এখানে ransomware-এর নির্দিষ্ট কাজগুলো দেখি। CISA, FBI, NSA আর MS-ISAC-এর যৌথ #StopRansomware Guide (সেপ্টেম্বর ২০২৩-এ হালনাগাদ) একটি ভালো মুক্ত চেকলিস্ট।

টাকা দেবেন কি?

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

• নিশ্চয়তা নেই: FBI জানায়, তারা মুক্তিপণ দেওয়াকে সমর্থন করে না, আর টাকা দিলেই ডেটা ফেরার নিশ্চয়তা নেই। পাওয়া decryptor ধীর বা ত্রুটিপূর্ণ হতে পারে।
• চুরি হওয়া ডেটা ফেরে না: “মুছে দিয়েছি” কথাটি যাচাই করার উপায় নেই।
• আইনি ঝুঁকি: মার্কিন Treasury-র OFAC ২১ সেপ্টেম্বর ২০২১-এর পরামর্শপত্রে জানায়, sanctions-ভুক্ত পক্ষকে টাকা দিলে বা তাতে সহায়তা করলে ঝুঁকি আছে, এমনকি প্রাপকের পরিচয় না জানলেও। নিয়ম দেশভেদে আলাদা ও বদলাতে পারে।
• নৈতিক দিক: টাকা অপরাধের ব্যবসা চালায়। অন্য দিকে হাসপাতালের মতো জায়গায় মানুষের জীবনও বিবেচনায় আসে। তাই বিতর্কটি সহজ নয়।
• আগে বিকল্প খুঁজুন: কিছু পুরোনো পরিবারের জন্য বিনামূল্যের decryptor আছে, যেমন আইন প্রয়োগকারী সংস্থা আর শিল্পের যৌথ No More Ransom প্রকল্পে। সব পরিবারের জন্য নেই।

৮ · পুনরুদ্ধারের ক্রম আর পরিষ্কারভাবে ফেরা

ঘূর্ণিঝড়ের পরে উপকূলে কী আগে ঠিক হয়? আগে রাস্তা আর বিদ্যুৎ, তারপর মোবাইল টাওয়ার, তারপর ব্যাংকের শাখা। বিদ্যুৎ ছাড়া টাওয়ার চালু করার চেষ্টা বৃথা। IT-তেও প্রতিটি সেবা অন্য কিছুর ওপর দাঁড়িয়ে। Payroll চায় database, database চায় login, login চায় DNS, আর সবার আগে network. এই ক্রম বের করার কাজটিকে গ্রাফের ভাষায় বলে topological sort.

নিচে একটি খেলনা অফিসের ৯টি system. প্রতি ধাপে “ready” সারি থেকে সবচেয়ে উঁচু অগ্রাধিকারের system-টি নেওয়া হচ্ছে। সংখ্যাগুলো অনুমান, আর একটি দল একবারে একটি কাজ করছে ধরা হয়েছে।

// Recovery order for toy systems: a topological sort (Kahn) with tier priority.
const systems = {
  network:  { tier: 0, hours: 2, needs: [] },
  backup:   { tier: 0, hours: 1, needs: ['network'] },
  dns:      { tier: 0, hours: 1, needs: ['network'] },
  identity: { tier: 0, hours: 3, needs: ['network', 'dns'] },
  database: { tier: 1, hours: 4, needs: ['identity', 'backup'] },
  files:    { tier: 2, hours: 3, needs: ['identity', 'backup'] },
  email:    { tier: 2, hours: 3, needs: ['identity', 'dns'] },
  payroll:  { tier: 1, hours: 2, needs: ['database'] },
  shop:     { tier: 1, hours: 2, needs: ['database'] },
};
function plan(graph) {
  const done = new Set(), left = new Set(Object.keys(graph));
  let clock = 0;
  while (left.size) {
    const ready = [...left].filter(s => graph[s].needs.every(n => done.has(n)))
      .sort((a, b) => graph[a].tier - graph[b].tier || a.localeCompare(b));
    if (!ready.length) return console.log(`STUCK, circular wait: ${[...left].join(', ')}`);
    const next = ready[0];
    clock += graph[next].hours;
    console.log(`t=${String(clock).padStart(2)}h  ${next.padEnd(9)} ready was: ${ready.join(' ')}`);
    left.delete(next); done.add(next);
  }
  console.log(`all ${done.size} systems back, one team at a time: ${clock} h`);
}
plan(systems);
console.log('--- same plan, but dns now needs identity');
plan({ ...systems, dns: { ...systems.dns, needs: ['network', 'identity'] } });

Rebuild, না restore?

আবার আক্রান্ত হওয়া ঠেকাতে: কাজগুলো একটি isolated recovery environment-এ করুন। আগে প্রবেশের পথ খুঁজে বন্ধ করুন। প্রথম অনুপ্রবেশের আগের বিন্দু খুঁজুন, সবচেয়ে নতুন বিন্দু নয়। EDR আর নজরদারি বসিয়ে তারপর ধাপে ধাপে যুক্ত করুন। ঘটনার পরে প্রায়ই নজর বেশি থাকে, কারণ একই বা অন্য দল আবার আসতে পারে। শেষে post-incident review করুন, মানুষকে দোষ না দিয়ে, আর শেখাটি control-এ বসান।

৯ · প্রকাশিত ঘটনা — রক্ষকের শিক্ষা

নিচের তিনটি ঘটনা শুধু প্রকাশিত প্রতিবেদন আর সরকারি নথির স্তরে দেওয়া হলো। লক্ষ্য দোষ দেওয়া নয়, কোন বাধা থাকলে গল্প বদলাত, সেটি বোঝা।

আরও ঘটনা ও পদ্ধতি থাকবে পর্ব ৬৫-তে। মহড়ার নিয়ম থাকবে পর্ব ৬৬-তে।

১০ · AI-এর যুগে ransomware প্রতিরক্ষা

AI আপনার playbook-এর খসড়া লিখতে, log সাজাতে, মহড়ার পরিস্থিতি বানাতে দারুণ সাহায্য করে। কিন্তু হামলার রাতে একটি ভুল পরামর্শ ঘণ্টার পর ঘণ্টা নষ্ট করতে পারে। AI আপনার network দেখতে পায় না, আর আত্মবিশ্বাসী ভঙ্গিতে ভুলও বলে।

AI ব্যবহারের চেকলিস্ট

• Prompt-এ কোনো password, key, আসল hostname বা গ্রাহকের তথ্য দিইনি
• AI-এর দেওয়া প্রতিটি CVE আর standard মূল উৎসে খুলে দেখেছি
• Script আগে test পরিবেশে চালিয়েছি, diff পড়েছি
• সময়ের হিসাব নিজে মিলিয়েছি, তারপর সত্যিকারের restore-এ মেপেছি
• Isolation, প্রকাশ আর টাকা নিয়ে সিদ্ধান্ত মানুষ নিচ্ছেন, AI নয়