Network-এর ঝুঁকি — eavesdropping, spoofing, MITM আর রক্ষা

১ · ইন্টারনেট কেন সবাইকে বিশ্বাস করত

পুরোনো দিনের একটি মহল্লা ভাবুন। সবাই সবাইকে চেনে। পিয়ন চিঠি দেওয়ার সময় খামের ওপর প্রেরকের নাম যাচাই করেন না। কেউ “আমি রহিম চাচা” বললে সেটাই মেনে নেওয়া হয়। মহল্লা ছোট থাকলে এই বিশ্বাস সস্তা আর কাজের। কিন্তু সেই মহল্লায় যদি শহরের সবাই ঢুকে পড়ে?

ইন্টারনেটের সাথে ঠিক এটাই হয়েছে। প্রথম দিকের network ছিল গবেষক আর বিশ্ববিদ্যালয়ের ছোট দল। নকশার লক্ষ্য ছিল টিকে থাকা আর নানা network জোড়া দেওয়া। David Clark-এর ১৯৮৮ সালের প্রবন্ধে DARPA Internet-এর লক্ষ্যের তালিকায় নিরাপত্তা আলাদা লক্ষ্য হিসেবে নেই। ফলে তিনটি অভ্যাস protocol-এর ভেতরে থেকে গেছে:

• প্রেরকই নিজের পরিচয় লেখে। IP header-এর source address, ARP-এর “এই IP আমার”, BGP-র “এই prefix আমার”, সবই দাবি। প্রমাণ নয়।
• প্রথম উত্তরই মেনে নেওয়া হয়। DHCP আর DNS-এ যে উত্তর মেলে আর আগে আসে, সাধারণত সেটাই গৃহীত হয়।
• লেখা খোলা থাকে। মূল protocol-এ বিষয়বস্তু encrypt হতো না। পথের যে কেউ পড়তে পারত।

এই পর্বের ভিত্তি দুটি পর্ব আগে থেকেই আছে। নিরাপত্তার সাধারণ ছবি আছে Computer Networks কোর্সের নেটওয়ার্ক নিরাপত্তার ভিত্তি-তে। আর DHCP ও ARP কীভাবে কাজ করে, তা আছে DHCP আর ARP পর্বে। এখানে সংক্ষেপে মনে করিয়ে দিই। DHCP নতুন যন্ত্রকে IP, gateway আর DNS-এর ঠিকানা দেয়। ARP একটি IP-র জন্য LAN-এর MAC address খুঁজে দেয়। বাকিটা ওই দুই পর্বেই পাবেন। আমরা এখানে রক্ষকের প্রশ্ন ধরব: কী ভাঙে, কে আটকায়, আর কীভাবে জানবেন।

২ · স্তরে স্তরে ঝুঁকির মানচিত্র

আলাদা আলাদা হামলার নাম মুখস্থ করলে দ্রুত গুলিয়ে যায়। তার চেয়ে স্তর ধরে ভাবা সহজ। প্রতিটি স্তরে প্রশ্ন একই: কোন দাবি জাল হতে পারে, আর সেখানে কে পাহারা দেয়। পর্ব ৪-এর STRIDE-এর ভাষায় এখানে মূলত spoofing, tampering, information disclosure আর denial of service দেখা যায়।

এবার একটি কাল্পনিক অফিসের জন্য একই মানচিত্র কোডে দেখুন। প্রতিটি ঝুঁকির পাশে দরকারি প্রতিরক্ষার তালিকা আছে। deployed-এ আছে অফিসটি আসলে কী চালু করেছে। Run চাপলে আপনি পাবেন ফাঁকের রিপোর্ট। আসল network-এ কিছুই যায় না।

// Threat -> layer -> defence report for a made-up office. No network.
const MAP = [
  { threat: 'open Wi-Fi sniffing',  layer: 'L1-2', fix: ['WPA3', 'TLS'] },
  { threat: 'rogue DHCP server',    layer: 'L2',   fix: ['DHCP snooping'] },
  { threat: 'ARP spoofing',         layer: 'L2',   fix: ['DAI', 'TLS'] },
  { threat: 'MAC flooding',         layer: 'L2',   fix: ['port security'] },
  { threat: 'IP spoofing',          layer: 'L3',   fix: ['BCP 38'] },
  { threat: 'BGP hijack',           layer: 'L3',   fix: ['RPKI ROV', 'TLS'] },
  { threat: 'TCP injection',        layer: 'L4',   fix: ['TLS'] },
  { threat: 'DNS cache poisoning',  layer: 'L7',   fix: ['DNSSEC', 'TLS'] },
];
// What this toy office has really switched on today.
const deployed = new Set(['TLS', 'WPA3', 'port security']);

const row = { full: 0, partial: 0, gap: 0 };
for (const m of MAP) {
  const have = m.fix.filter(f => deployed.has(f));
  const state = have.length === m.fix.length ? 'full'
              : have.length > 0 ? 'partial' : 'gap';
  row[state]++;
  const missing = m.fix.filter(f => !deployed.has(f)).join(', ') || '-';
  console.log(`${m.layer.padEnd(5)}${m.threat.padEnd(21)}${state.padEnd(8)}${missing}`);
}
console.log(`\nfull=${row.full} partial=${row.partial} gap=${row.gap} of ${MAP.length}`);

// If TLS alone were removed, how many threats lose their only cover?
const lost = MAP.filter(m => {
  const have = m.fix.filter(f => deployed.has(f));
  return have.length === 1 && have[0] === 'TLS';
}).map(m => m.threat);
console.log('only TLS stands here: ' + lost.join('; '));

৩ · Eavesdropping — খোলা পথে আড়ি পাতা

চায়ের দোকানে জোরে বলা কথা পাশের টেবিলের সবাই শোনে। Eavesdropping মানে পথের ডেটা চুপচাপ পড়া। এতে ডেটা বদলায় না, তাই ভুক্তভোগী টেরও পান না। এটি confidentiality-র ওপর সরাসরি আঘাত, আর শোনা হয় নিঃশব্দে, তাই ধরাও কঠিন। এজন্য এখানে প্রতিরোধই প্রধান ভরসা।

কেন শোনা সম্ভব

• Shared medium: Wi-Fi-র বাতাস মহল্লার মাইকের মতো। নাগালের ভেতরের সব radio একই সংকেত পায়। পুরোনো hub-ও প্রতিটি frame সব port-এ পাঠাত।
• Switched LAN: Switch frame শুধু গন্তব্যের port-এ দেয়, তাই পাশের কম্পিউটার সাধারণত অন্যের traffic পায় না। কিন্তু এটি সুরক্ষা নকশা নয়, সুবিধার ফল। Switch-এর টেবিল ভরে গেলে বা ARP বিষিয়ে গেলে সেই সুবিধা হারাতে পারে।
• খোলা Wi-Fi: Password ছাড়া Wi-Fi-তে radio-র ওপর সাধারণত কোনো encryption থাকে না। আর সবার জানা password দিলে অন্য ব্যবহারকারীও একই network-এ আপনার পাশে থাকেন। হোটেল, ক্যাফে আর হোস্টেলে ঝুঁকি এখান থেকেই আসে।
• পথের যন্ত্র: Router, ISP আর মাঝের লিংকের যেকোনো জায়গায় traffic দেখা যায়। কাছের ঝুঁকি বেশি আলোচিত, কিন্তু পথ পুরোটাই লম্বা।

সমাধান: encryption, আর সে কতদূর রক্ষা করে

লক্ষ করুন, লিংক-স্তরের encryption পথের একটি টুকরো ঢাকে, আর end-to-end encryption পুরো পথ ঢাকে। বিস্তারিত Wi-Fi সুরক্ষা আসবে পর্ব ২৭-এ, আর VPN পর্ব ২৫-এ। রক্ষকের জন্য নিয়মটি সহজ: কোনো সংবেদনশীল ডেটা network-কে বিশ্বাস করে খোলা পাঠাবেন না। ধরে নিন পথ শত্রুর হাতে থাকতে পারে। এটি zero trust-এর ভাবনাও।

৪ · IP spoofing আর ingress filtering

খামের ওপর প্রেরকের ঘরে যে কেউ অন্যের ঠিকানা লিখতে পারে। পোস্ট অফিস সাধারণত যাচাই করে না। IP spoofing ঠিক তাই: packet-এর source address-এ অন্য কারো ঠিকানা বসানো। Router শুধু গন্তব্য দেখে পথ বেছে নেয়, উৎস নিয়ে মাথা ঘামায় না।

কেন এটি ক্ষতিকর, আর কোথায় কাজ করে না

• উৎস লুকায়: DDoS-এ হামলার যন্ত্র ধরা কঠিন হয়।
• Reflection: জাল উৎস হিসেবে শিকারের ঠিকানা থাকলে অন্য server-এর উত্তর শিকারের কাছে যায়। উত্তর অনুরোধের চেয়ে বড় হলে বোঝাও বাড়ে। প্রতিরক্ষা আসবে পর্ব ২৮-এ।
• ঠিকানা-ভিত্তিক বিশ্বাস ভাঙে: “এই IP থেকে এলে login লাগবে না” ধরনের নিয়ম পুরোনো, কিন্তু আজও মেলে।

একটি সীমাও জানা দরকার। জাল উৎস দিলে উত্তর জাল-ঠিকানায় যায়, প্রেরকের কাছে আসে না। তাই পূর্ণ TCP সংযোগ জাল ঠিকানায় সাধারণত গড়া যায় না। Spoofing মূলত UDP-র মতো এক-বার্তার protocol আর flood-এ কাজে লাগে।

প্রতিরক্ষা: উৎসের কাছেই আটকানো

পাড়ার পোস্ট অফিস জানে কোন ঠিকানা তার এলাকার। এলাকার বাইরের প্রেরক-ঠিকানার চিঠি কেউ জমা দিলে সেখানেই ফেরত দেওয়া যায়। Ingress filtering এই কাজটিই করে। ISP-র edge router জানে কোন গ্রাহককে কোন prefix দেওয়া হয়েছে। সেই গ্রাহকের লিংকে অন্য উৎসের packet এলে ফেলে দেয়। এই নিয়ম লেখা আছে RFC 2827-এ (BCP 38, মে ২০০০, Ferguson ও Senie). পরে RFC 3704 (BCP 84, ২০০৪) একে বহু-সংযোগের network-এ প্রসারিত করে, আর সেখানে uRPF-এর ধরনগুলো আলোচিত হয়।

প্রতিষ্ঠানের নিজের সীমানায় একই কাজের আরেক নাম egress filtering: আপনার network থেকে বাইরে শুধু আপনার prefix-এর উৎস যাবে। একই নিয়ম, শুধু দেখার দিক আলাদা। নিচে ধাপগুলো দেখুন।

from customer link
src = 198.51.100.20
dst = 203.0.113.9
198.51.100.20 in 198.51.100.0/24 ? yes -> PASS

from customer link
src = 203.0.113.9    (অন্য কারো ঠিকানা)
dst = 192.0.2.53

allowed source = 198.51.100.0/24
203.0.113.9 in 198.51.100.0/24 ? no

DROP  source is not yours
counter antispoof +1
192.0.2.53 কিছুই পেল না
203.0.113.9 কোনো অবাঞ্ছিত উত্তর পেল না

packet পৌঁছে যেত 192.0.2.53-এ
উত্তর যেত 203.0.113.9-এ (যে কিছুই চায়নি)
আসল প্রেরককে দেখা যেত না

একই নিয়ম কোডে। এখানে দুই দিকের যাচাই আছে: গ্রাহকের দিক থেকে আসা packet-এর উৎস অবশ্যই prefix-এর ভেতরে, আর ইন্টারনেটের দিক থেকে আসা packet-এর উৎস prefix-এর বাইরে। Packet এখানে শুধু JavaScript object.

// Toy edge router: BCP 38 style source check. Packets are plain objects.
const ip = s => s.split('.').reduce((n, o) => n * 256 + Number(o), 0);
function inPrefix(addr, cidr) {
  const [net, bits] = cidr.split('/');
  const size = 2 ** (32 - Number(bits));
  return Math.floor(ip(addr) / size) === Math.floor(ip(net) / size);
}
const CUSTOMER = '198.51.100.0/24';   // the only source this link may use

function check(p) {
  const mine = inPrefix(p.src, CUSTOMER);
  if (p.from === 'customer' && !mine) return 'DROP  source is not yours';
  if (p.from === 'internet' && mine)  return 'DROP  outsider claims inside';
  return 'PASS';
}
const packets = [
  { from: 'customer', src: '198.51.100.20', dst: '203.0.113.9' },
  { from: 'customer', src: '203.0.113.9',   dst: '192.0.2.53' },
  { from: 'customer', src: '192.0.2.7',     dst: '203.0.113.9' },
  { from: 'customer', src: '198.51.100.99', dst: '203.0.113.9' },
  { from: 'internet', src: '203.0.113.9',   dst: '198.51.100.20' },
  { from: 'internet', src: '198.51.100.20', dst: '198.51.100.21' },
];
let pass = 0, drop = 0;
for (const p of packets) {
  const verdict = check(p);
  verdict === 'PASS' ? pass++ : drop++;
  console.log(`${p.from.padEnd(9)}${p.src.padEnd(15)}${verdict}`);
}
console.log(`pass=${pass} drop=${drop}`);
console.log('note: 198.51.100.99 passed. The filter checks the prefix,');
console.log('not which host inside the prefix really sent the packet.');

# উদাহরণ: নিজের edge router-এর জন্য nftables নিয়ম, চালানোর কোড নয়।
# lan0 ভেতরের দিক, wan0 বাইরের দিক; prefix আপনার নিজের বসবে।
table inet antispoof {
  chain forward {
    type filter hook forward priority 0; policy accept;
    iifname "lan0" ip saddr != 198.51.100.0/24 counter drop
    iifname "wan0" ip saddr 198.51.100.0/24 counter drop
  }
}

এই উদাহরণ শুধু উৎস-যাচাই দেখায়। পুরো firewall নীতি নয়, সেটি পর্ব ২২-এর বিষয়। Counter বাড়তে থাকলে বুঝবেন ভেতরের কোনো যন্ত্র ভুল উৎসে packet পাঠাচ্ছে: ভুল configuration, নাকি আক্রান্ত যন্ত্র, সেটি খুঁজে দেখতে হবে।

৫ · LAN-এর বিশ্বাস — ARP spoofing, ভুয়া DHCP আর port security

এবার মহল্লার ভেতরে আসি। ARP মানে পাড়ায় চিৎকার করে জিজ্ঞেস করা, “192.0.2.1 কার?” যে উত্তর দেয়, সবাই তাকেই মেনে নেয়। উত্তর যাচাইয়ের কোনো নিয়ম নেই। ARP-এর মূল নকশা RFC 826 (১৯৮২) একটি বিশ্বস্ত LAN ধরে নিয়েছিল।

ARP spoofing এই বিশ্বাসের ভুল ব্যবহার। ধারণাটি সরল: একটি যন্ত্র দাবি করে, gateway-র IP তার MAC-এ। যাদের ARP cache এই দাবি মেনে নিল, তাদের বাইরের traffic ওই যন্ত্রের দিকে যায়। ফলাফল হতে পারে traffic ফেলে দেওয়া (network বন্ধ), অথবা পড়ে আসল gateway-তে পাঠানো (MITM). ঝুঁকি একই LAN বা VLAN-এর মধ্যে সীমিত। কারণ ARP router পার হয় না।

প্রতিরক্ষা: দারোয়ানের রেজিস্টার খাতা

একটি বড় ভবনে দারোয়ানের খাতায় লেখা থাকে কোন ফ্ল্যাটে কে থাকেন। কেউ এসে “আমি ৩বি-র মালিক” বললে দারোয়ান খাতা দেখেন, মুখের কথা নয়। Switch-এর খাতার নাম binding table. তিনটি প্রতিরক্ষা একে ঘিরে কাজ করে:

Rogue DHCP server নতুন যন্ত্রকে ভুল gateway বা ভুল DNS দিতে পারে। বহু ক্ষেত্রে কারণ নিরীহ: কেউ বাসার router এনে অফিসের তারে লাগিয়েছেন। DHCP snooping দুই ক্ষেত্রেই একই কাজ করে। MAC flooding-এ অসংখ্য ভুয়া MAC দিয়ে switch-এর টেবিল ভরে দেওয়া হয়, তখন switch অনেক frame সব port-এ ছড়াতে পারে। Port security এখানে সীমা বসায়। আর 802.1X অচেনা যন্ত্রকে port-এ ঢোকার আগেই থামায়। এই তিনের সাথে VLAN ভাগ আর Wi-Fi-র client isolation ক্ষতির পরিধি ছোট রাখে।

নিচের stepper আগে স্বাভাবিক ARP দেখায়, তারপর একটি জাল reply কীভাবে থামে। Dynamic ARP Inspection (DAI) এখানে মূল চরিত্র।

ARP request: who has 192.0.2.1?
cache: (empty)

192.0.2.1 is at 02:00:00:00:00:01
cache: 192.0.2.1 -> 02:00:00:00:00:01

192.0.2.1 is at 02:00:00:00:00:77
cache: 192.0.2.1 -> 02:00:00:00:00:01

192.0.2.10  02:00:00:00:00:0a  p1
192.0.2.77  02:00:00:00:00:77  p7
192.0.2.1   p7-এর জন্য কোনো binding নেই

DROP port=p7 ip=192.0.2.1 mac=02:00:00:00:00:77
cache: 192.0.2.1 -> 02:00:00:00:00:01  (অপরিবর্তিত)

এবার সিমুলেটর। একই পাঁচটি ARP বার্তা দুবার চলে: inspection বন্ধ রেখে আর চালু রেখে। সবই memory-র ভেতরের খেলনা, কোনো আসল frame তৈরি হয় না।

// Toy switch: ARP inspection against a trusted binding table. In memory only.
const GW = '192.0.2.1', GW_MAC = '02:00:00:00:00:01';
const binding = {            // learned from DHCP (or written by the admin)
  '192.0.2.10': { mac: '02:00:00:00:00:0a', port: 'p1' },
  '192.0.2.77': { mac: '02:00:00:00:00:77', port: 'p7' },
};
const TRUSTED = new Set(['uplink']);       // the gateway lives behind this port

const arps = [
  { port: 'uplink', ip: GW,           mac: GW_MAC,              note: 'real gateway' },
  { port: 'p1',     ip: '192.0.2.10', mac: '02:00:00:00:00:0a', note: 'normal host' },
  { port: 'p7',     ip: GW,           mac: '02:00:00:00:00:77', note: 'forged reply' },
  { port: 'p1',     ip: '192.0.2.77', mac: '02:00:00:00:00:0a', note: 'wrong owner' },
  { port: 'p9',     ip: '192.0.2.50', mac: '02:00:00:00:00:50', note: 'static printer' },
];
function allowed(a) {
  if (TRUSTED.has(a.port)) return [true, 'trusted port'];
  const b = binding[a.ip];
  if (!b) return [false, 'no binding'];
  if (b.mac !== a.mac || b.port !== a.port) return [false, 'binding mismatch'];
  return [true, 'matches binding'];
}
function run(inspect) {
  const cache = {}; let dropped = 0;   // cache: what hosts on this LAN would believe
  console.log(`--- inspection ${inspect ? 'ON' : 'OFF'} ---`);
  for (const a of arps) {
    const [ok, why] = inspect ? allowed(a) : [true, 'no check'];
    if (ok) cache[a.ip] = a.mac; else dropped++;
    console.log(`${a.note.padEnd(15)}${(ok ? 'accept' : 'DROP').padEnd(7)}${why}`);
  }
  const mac = cache[GW];
  console.log(`gateway -> ${mac} ${mac === GW_MAC ? '(correct)' : '(WRONG)'}, dropped=${dropped}`);
}
run(false);
run(true);

Alert থেকে সিদ্ধান্ত: log পড়া

প্রতিরক্ষা চালু করা অর্ধেক কাজ। বাকি অর্ধেক হলো তার log পড়া। নিচের Bash block একটি বানানো switch log-এর গণনা করে। Log-এর ফরম্যাট কাল্পনিক; আসল switch-এ vendor অনুযায়ী আলাদা হবে।

# Review of a fixed, made-up switch log. Nothing here touches a real network.
cat > switch.log <<'EOF'
09:58:02 sw1 INFO  link-up port=p3
10:01:14 sw1 DHCP-SNOOP drop=OFFER port=p12 vlan=10 mac=02:00:00:00:00:c4
10:01:16 sw1 DHCP-SNOOP drop=OFFER port=p12 vlan=10 mac=02:00:00:00:00:c4
10:01:19 sw1 DHCP-SNOOP drop=ACK port=p12 vlan=10 mac=02:00:00:00:00:c4
10:03:40 sw1 INFO  link-up port=p5
10:07:02 sw1 ARP-INSPECT drop=reply port=p7 vlan=10 ip=192.0.2.1 mac=02:00:00:00:00:77
10:07:03 sw1 ARP-INSPECT drop=reply port=p7 vlan=10 ip=192.0.2.1 mac=02:00:00:00:00:77
10:07:05 sw1 ARP-INSPECT drop=reply port=p7 vlan=10 ip=192.0.2.1 mac=02:00:00:00:00:77
10:07:06 sw1 ARP-INSPECT drop=reply port=p7 vlan=10 ip=192.0.2.1 mac=02:00:00:00:00:77
10:09:31 sw1 ARP-INSPECT drop=request port=p9 vlan=10 ip=192.0.2.50 mac=02:00:00:00:00:50
10:12:45 sw1 INFO  link-up port=p8
EOF

echo "== alerts by type =="
awk '$3=="DHCP-SNOOP" || $3=="ARP-INSPECT" {print $3}' switch.log | sort | uniq -c

echo "== alerts by type and port =="
awk '$3!="INFO" {print $3, $5}' switch.log | sort | uniq -c | sort -rn

echo "== who claimed the gateway 192.0.2.1? =="
grep 'ip=192.0.2.1 ' switch.log | awk '{print $5, $8}' | sort -u

echo "== ports with 3 or more alerts (look at these first) =="
awk '$3!="INFO" {n[$5]++} END {for (p in n) if (n[p] >= 3) print p, n[p]}' switch.log | sort

৬ · নাম, সংযোগ আর পথ — DNS, TCP আর BGP

LAN পেরিয়ে এবার ইন্টারনেট। এখানে তিনটি বিশ্বাস আছে: নাম থেকে ঠিকানা (DNS), চলমান সংযোগ (TCP), আর পথের ঘোষণা (BGP). প্রতিটির ঝুঁকি আলাদা, কিন্তু শেষ ফল প্রায়ই একই: traffic ভুল জায়গায় যায়।

DNS spoofing আর cache poisoning

মোবাইলে রাখা নম্বরের তালিকায় কেউ “ব্যাংক” নামের নম্বর বদলে দিলে আপনি নিজের অজান্তেই ভুল নম্বরে ফোন করবেন। DNS-এর ঝুঁকি এমনই। DNS spoofing মানে জাল উত্তর দেওয়া। DNS cache poisoning আরও বড়: জাল উত্তর একটি resolver-এর cache-এ বসে গেলে তার সব ব্যবহারকারী ভুল ঠিকানা পান।

UDP-তে resolver চেনে উত্তরকে মূলত দুটি সংখ্যায়: ১৬-bit transaction ID আর প্রশ্ন পাঠানোর UDP port. রক্ষকের চোখে হিসাবটি সরল। সংখ্যা যত এলোমেলো, অন্ধভাবে মেলানো তত কঠিন।

২০০৮ সালে Dan Kaminsky একটি নকশাগত DNS দুর্বলতা প্রকাশ করেন। তখন বহু vendor সমন্বিতভাবে source port randomization ছড়িয়ে দেন, RFC 5452 (২০০৯) এই শক্তিশালী আচরণ লিখে রাখে। তবে এটি সম্ভাবনা কমায়, প্রমাণ দেয় না। প্রমাণ দেয় DNSSEC: zone-এর signature দিয়ে উত্তর যাচাই। বিস্তারিত পর্ব ২৬-এ। আর যদি DNS ভুলও বলে, ঠিকমতো যাচাই করা TLS ভুয়া সাইটকে সেখানে থামায়, কারণ ভুয়া server-এর কাছে আসল নামের certificate নেই।

TCP session-এর ঝুঁকি

TCP সংযোগ চিহ্নিত হয় দুই ঠিকানা, দুই port আর sequence number দিয়ে। এখানে কোনো cryptography নেই। যে পথে বসে আছে, সে এগুলো দেখতে পায়। তাই সে সংযোগ কেটে দিতে পারে (TCP reset) বা খোলা লেখায় ডেটা ঢোকাতে পারে (session hijacking).

পথের বাইরের কেউ হলে তাকে অন্ধভাবে অনুমান করতে হয়। সংখ্যার হিসাব দেখুন। Sequence space ২^৩২, আর গ্রহণযোগ্য window ধরুন ৬৫,৫৩৫। তাহলে একটি অনুমান window-তে পড়ার সম্ভাবনা প্রায় ৬৫,৫৩৭ ভাগের ১ ভাগ। এটিও খুব বড় বাধা নয়। তাই RFC 5961 (২০১০) নিয়ম কড়া করেছে: RST-এর sequence একদম প্রত্যাশিত না হলে TCP সংযোগ না কেটে challenge ACK পাঠায়। আর RFC 6528 প্রাথমিক sequence number-কে অনুমান-অযোগ্য রাখতে বলে, যে নিয়ম এখন RFC 9293 (২০২২)-এর অংশ।

BGP hijack আর RPKI

ঢাকা শহরের কোনো মোড়ে কেউ ভুয়া সাইনবোর্ড লাগাল, “গাবতলীর পথ এদিকে।” যারা বিশ্বাস করল, তারা ভুল পথে গেল। BGP-এ প্রতিটি autonomous system প্রতিবেশীদের জানায় কোন prefix-এ কোন পথে যাওয়া যায়, আর মূল protocol এই ঘোষণা প্রমাণ চায় না। BGP hijack মানে এমন prefix ঘোষণা করা, যা আপনার নয়। ভুলে ঘটলে তাকে সাধারণত route leak বা ভুল ঘোষণা বলা হয়; মাঝের সীমারেখা সব সময় স্পষ্ট নয়। বিস্তারিত গঠন আছে BGP পর্বে।

২০০৮ সালের ফেব্রুয়ারিতে Pakistan Telecom-এর একটি অননুমোদিত prefix ঘোষণা উপরের provider হয়ে ছড়িয়ে পড়ে, ফলে YouTube-এর traffic প্রায় দুই ঘণ্টা ধরে ভুল পথে যায় (RIPE NCC-র case study). নির্দিষ্টতর prefix জিতে যাওয়াই ছিল কারণ। আসল সমস্যা ছিল: উপরের provider সেই ঘোষণা যাচাই না করেই ছড়িয়েছিল।

প্রতিরক্ষা হলো RPKI (RFC 6480, ২০১২)। Prefix-এর মালিক একটি স্বাক্ষরিত ROA প্রকাশ করেন: “এই prefix ঘোষণা করতে পারে এই AS.” Router route origin validation (RFC 6811, ২০১৩) করে ফল পায়: valid, invalid বা not found. সাধারণ নীতি হলো invalid route ফেলে দেওয়া। একে বাসের রুট পারমিটের সিলমোহর ভাবতে পারেন: এই রুটে এই কোম্পানি চালাতে পারে কি না, সেটুকুই মেলানো হয়। সীমাও এখানেই: RPKI origin যাচাই করে, পুরো পথ নয়। তাই সাথে প্রতিবেশীর prefix filter আর route monitoring চালু রাখতে হয়। রুট ঘোষণা করা সবার কাজ নয়, তাই বেশিরভাগ প্রতিষ্ঠানের করণীয় সহজ: নিজের prefix-এর ROA বানানো, ISP-কে জিজ্ঞেস করা তারা invalid route ফেলে কি না, আর নিজের prefix নজরে রাখা।

৭ · On-path attacker — authentication কীভাবে তাকে হারায়

আগের সব ঝুঁকির একটি সাধারণ গন্তব্য আছে। ভুয়া Wi-Fi, ARP spoofing, ভুয়া DHCP, DNS poisoning বা BGP hijack, পথ যেটাই হোক, শেষে কেউ দুই পক্ষের পথে বসে যায়। পুরোনো নাম man-in-the-middle, আজকের RFC-গুলোতে প্রায়ই on-path attacker. এই নামটি সঠিক, কারণ সে বিশেষ কোনো “মাঝে” নয়, শুধু পথে আছে।

এখানে পর্ব ১০-এর একটি কথা ফিরে আসে: শুধু key exchange নিজে পরিচয় দেয় না। মাঝের কেউ দুই দিকে আলাদা করে Diffie-Hellman করলে দুই পক্ষই তার সাথে encrypted কথা বলবে। Encryption আছে, নিরাপত্তা নেই। পরিচয়ের প্রমাণ আসে পর্ব ১১-এর digital signature আর certificate থেকে, আর সবকিছু একসাথে জোড়ে পর্ব ১২-এর TLS handshake. নিচের stepper দুটি চেষ্টা দেখায়, দুটিই ব্যর্থ। লক্ষ করুন, কোনটি কোথায় থামল।

TLS 1.3 ClientHello
server_name = example.com
key_share   = client-share-A

Certificate subject = not-example.test
issuer = unknown-local-ca
example.com-এর আসল private key তার কাছে নেই

chain ends in trust store?  NO
name matches example.com?   NO
result: certificate error, stop

certificate   = real example.com    (chain OK)
key_share     = swapped
CertificateVerify over transcript?  NO VALID SIGNATURE

TLS alert, connection closed
password, cookie: কিছুই যায়নি
তবু দেখতে পায়: IP, সময়, আকার
তবু পারে: সংযোগ কেটে দিতে

কোথায় authentication বসাবেন

• Browser আর API: TLS, certificate যাচাই চালু, HSTS.
• Service থেকে service: mTLS, যেখানে দুই পক্ষই নিজের পরিচয় প্রমাণ করে।
• Admin login: SSH-এ host key যাচাই। “প্রথমবার yes” চাপার আগে fingerprint মেলান।
• মানুষের login: Origin-এর সাথে বাঁধা passkey. পর্ব ১৬-এ দেখেছেন, ভুয়া সাইটে এটি কাজই করে না, তাই on-path relay-ও ফল পায় না।

৮ · Reconnaissance, রক্ষকের চোখে — আপনার network কী দেখায়

পর্ব ৫-এর reconnaissance ধাপে আক্রমণকারী তথ্য জোগাড় করে। ইন্টারনেটে খোলা port-এর স্বয়ংক্রিয় খোঁজ সব সময়ই চলছে, তাই কোনো সার্ভিস “কেউ জানে না” ভাবা ভুল। এই পর্বে আমরা খোঁজার উপায় শিখব না, শিখব রক্ষকের প্রশ্নটি: বাইরে থেকে আমার কী দেখা যায়, আর তার কতটা না দেখালেও চলে?

একটি বাড়ির কথা ভাবুন। যত দরজা আর জানালা রাস্তায় খোলে, পাহারার কাজ তত বেশি। অব্যবহৃত দরজা ইট দিয়ে বন্ধ করাই সস্তা নিরাপত্তা। এটিই attack surface কমানো।

শুরু করবেন asset inventory দিয়ে: কোন যন্ত্র, কোন ঠিকানা, কোন সার্ভিস, মালিক কে। তালিকায় না থাকা জিনিস রক্ষা করা যায় না। তারপর নিয়মিত যাচাই। প্রতিষ্ঠানের অনুমোদন নিয়ে নিজের ঠিকানার exposure দেখার সেবা বা নিরাপত্তা দলের নির্ধারিত প্রক্রিয়া ব্যবহার করুন। পরীক্ষার পরিধি আগে লিখে নিন; সেই কাজ পর্ব ৫০-এর নিয়মে চলে।

৯ · Baseline hardening আর অনুমোদনের সীমা

এই চেকলিস্ট একটি ছোট বা মাঝারি প্রতিষ্ঠানের শুরু। সব একদিনে নয়, আর চালুর আগে log-only ধাপে দেখে নিন। কোনটি আগে করবেন, তা ঠিক হবে আপনার threat model দিয়ে।

• সব যন্ত্র, ঠিকানা আর খোলা সার্ভিসের তালিকা আছে, প্রতিটির মালিক আছে
• Edge-এ default deny আর দুই দিকের anti-spoof filter চালু
• ব্যবহারকারীর VLAN-এ DHCP snooping, DAI আর port security; static যন্ত্রের তালিকা লেখা
• অতিথি Wi-Fi আলাদা VLAN-এ, client isolation চালু, অফিসের network-এ পথ নেই
• অফিসের Wi-Fi-তে WPA3 বা WPA2-Enterprise, পরিচয়সহ 802.1X যেখানে সম্ভব
• Management interface আলাদা network-এ, admin login-এ MFA
• Telnet, FTP আর পুরোনো TLS বন্ধ; SSH আর TLS 1.2 বা 1.3 চালু
• Internal সার্ভিসেও TLS আর certificate যাচাই, verify=False কোথাও নেই
• Resolver-এ DNSSEC যাচাই বা বিশ্বস্ত resolver, নিজের domain-এ DNSSEC বিবেচিত
• নিজের prefix থাকলে ROA প্রকাশিত, ISP-র RPKI অবস্থান জানা
• Switch, router আর firewall-এর log কেন্দ্রীয় জায়গায় যায়, snooping ও DAI alert কেউ পড়েন
• Firmware আপডেটের নিয়ম আর দায়িত্ব আছে, config-এর backup আছে

Host-এর দিকেও ছোট একটি baseline দেওয়া যায়। নিচের ফাইল আপনার নিজের Linux server-এর জন্য:

# উদাহরণ: /etc/sysctl.d/90-net-baseline.conf (নিজের Linux host)
# এই ফাইলে মন্তব্য নিজের লাইনে লিখতে হয়, মানের পাশে নয়।
# উৎস যাচাই (strict)
net.ipv4.conf.all.rp_filter = 1
# ICMP redirect না মানা
net.ipv4.conf.all.accept_redirects = 0
# host-এ দরকার নেই
net.ipv4.conf.all.send_redirects = 0
# source routing না মানা
net.ipv4.conf.all.accept_source_route = 0
# অসম্ভব উৎসের packet log করা
net.ipv4.conf.all.log_martians = 1
# SYN flood-এ সুরক্ষা
net.ipv4.tcp_syncookies = 1

এগুলো host-এর ভেতরের উৎস-যাচাই আর পুরোনো ফিচার বন্ধের নিয়ম। rp_filter = 1 asymmetric routing-এ বৈধ traffic-ও ফেলতে পারে; তখন 2 (loose) ব্যবহার হয়। পরিবর্তনের আগে কোনো test যন্ত্রে দেখে নিন। পুরো host hardening আসবে পর্ব ৩০-এ।

১০ · AI-এর যুগে network নিরাপত্তা

AI network config পড়তে, log সাজাতে আর ধারণা বোঝাতে ভালো সাহায্য করে। কিন্তু সে আপনার network দেখে না। একটি ভুল নিয়ম পুরো অফিসের সংযোগ বন্ধ করতে পারে। তাই AI-এর উত্তর একটি খসড়া, সিদ্ধান্ত নয়।

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

• Prompt-এ কোনো আসল secret, password বা ব্যক্তিগত তথ্য নেই
• প্রতিটি RFC, CVE আর কমান্ড মূল নথিতে নিজে মিলিয়েছি
• Config বদল আগে নিজের ল্যাবে দেখেছি, ফেরার পথ (rollback) লেখা আছে
• AI-এর “এটি হামলা” কথাকে অনুমান ধরেছি; log আর মানুষ দিয়ে নিশ্চিত করেছি
• যে সিদ্ধান্ত কারো চাকরি বা সেবায় প্রভাব ফেলে, তা একজন মানুষ নিয়েছেন