Security group আর network ACL — stateful বনাম stateless firewall

১ · দুই পাহারাদার — রিসেপশন আর লঞ্চঘাট

পর্ব ২৫-এ আপনি VPC আর subnet দিয়ে জায়গা ভাগ করতে দেখেছেন। পর্ব ২৬-এ দেখেছেন packet কোন পথে যায়। কিন্তু পথ থাকা মানেই ঢোকার অনুমতি নয়। সেই অনুমতি ঠিক করে firewall. Firewall প্রতিটি packet-এর ঠিকানা, port আর protocol দেখে সিদ্ধান্ত নেয়: যেতে দেবে, না আটকাবে। তত্ত্বের দিকটি আছে Computer Networks কোর্সের firewall পর্বে; এখানে আমরা cloud-এ এটি চালানোর দিকটি দেখব।

Cloud-এ সাধারণত দুই স্তরের পাহারা থাকে। দুটির চরিত্র একেবারে আলাদা, আর এই পার্থক্যই পুরো পর্বের মূল কথা।

এবার সংজ্ঞা। Security group বসে প্রতিটি VM-এর network interface-এ, আর Network ACL (সংক্ষেপে NACL) বসে পুরো subnet-এর সীমানায়। নিচের তুলনাটি AWS-এর নাম ধরে করা, কারণ এই দুই নাম সেখান থেকেই এসেছে। অন্য provider-এর কথা অংশ ৫-এ আসবে।

একটি packet-কে firewall পাঁচটি জিনিস দিয়ে চেনে: source IP, source port, destination IP, destination port আর protocol. এই পাঁচটিকে একসাথে বলে five-tuple. Port আর সংযোগ তৈরির খুঁটিনাটি মনে করতে চাইলে TCP সংযোগের পর্ব দেখে নিন।

২ · Security group — যে দরজা মনে রাখে

একটি security group হলো কতগুলো allow নিয়মের তালিকা। প্রতিটি নিয়মে তিনটি জিনিস থাকে: protocol, port আর উৎস। যেমন “TCP, 443, যেকোনো জায়গা থেকে”। Outbound নিয়মে উৎসের জায়গায় থাকে গন্তব্য। আচরণের নিয়মগুলো এরকম:

• Inbound-এ শুরু থেকেই সব বন্ধ। একে বলে default deny. নতুন group-এ কোনো নিয়ম না লিখলে বাইরে থেকে কিছুই ঢুকবে না।
• Outbound-এ সাধারণত সব খোলা থাকে। AWS-এর নতুন group-এ ডিফল্টে একটি “সব outbound allow” নিয়ম থাকে। এটি মুছে কড়া করা যায়, আর ডেটা বাইরে যাওয়া ঠেকাতে সেটি ভালো অভ্যাস।
• Deny লেখা যায় না। তাই একটি নির্দিষ্ট IP-কে আটকাতে security group কাজে আসে না। সেই কাজ NACL বা WAF-এর।
• সব নিয়ম মিলে যোগফল। একটি VM-এ একাধিক group থাকলে নিয়মগুলোর union খাটে। কোনো একটি allow করলেই যথেষ্ট, তাই নিয়মের ক্রম নিয়ে ভাবতে হয় না।
• একই group-এর দুই VM আপনাআপনি কথা বলতে পারে না। তার জন্য self-referencing rule লাগে, অর্থাৎ group নিজেকেই উৎস হিসেবে দেখায়। ক্লাস্টারের VM-গুলোর পরস্পর যোগাযোগে এটি দরকার। (AWS-এর VPC-র সাথে আসা default group-এ এই নিয়মটি আগে থেকেই থাকে।)

“মনে রাখা” আসলে কী

স্মৃতির কাজটি করে connection tracking. একটি প্রবেশের অনুমতি পেলে firewall তার five-tuple একটি table-এ লিখে রাখে। পরে উল্টো দিক থেকে একই five-tuple-এর packet এলে table-এ মিলিয়েই ছেড়ে দেয়, নিয়মের তালিকা পড়ে না। নিচের সিমুলেটরে একই অনুরোধ, তার উত্তর আর একটি অচেনা packet তিনটি আলাদা firewall-এর ভেতর দিয়ে পাঠানো হয়েছে। চালিয়ে দেখুন, মান বদলে আবার চালান।

// One request and its reply through a stateful and a stateless filter.
const req = { src: '203.0.113.7', sport: 51514, dst: '10.0.1.20', dport: 443 };
const reply = { src: req.dst, sport: req.dport, dst: req.src, dport: req.sport };
const stray = { src: '203.0.113.99', sport: 443, dst: '10.0.1.20', dport: 51514 };
const flow = p => `${p.src}:${p.sport}>${p.dst}:${p.dport}`;
const back = p => `${p.dst}:${p.dport}>${p.src}:${p.sport}`;
const show = p => `${p.src}:${p.sport} -> ${p.dst}:${p.dport}`;
const allowed = (ranges, p) => ranges.some(([lo, hi]) => p.dport >= lo && p.dport <= hi);

function stateful(inRanges, outRanges) {
  const table = new Set();                  // connection tracking table
  return (p, dir) => {
    if (table.has(back(p))) return 'ALLOW (tracked, no rule read)';
    if (!allowed(dir === 'in' ? inRanges : outRanges, p)) return 'DENY (no rule matched)';
    table.add(flow(p));
    return 'ALLOW (rule matched, flow recorded)';
  };
}
function stateless(inRanges, outRanges) {
  return (p, dir) => allowed(dir === 'in' ? inRanges : outRanges, p)
    ? 'ALLOW (rule matched)' : 'DENY (no rule matched)';
}
function run(name, fw) {
  console.log('--- ' + name);
  console.log('request', show(req), '=>', fw(req, 'in'));
  console.log('reply  ', show(reply), '=>', fw(reply, 'out'));
  console.log('stray  ', show(stray), '=>', fw(stray, 'in'));
}
run('stateful: in 443, out nothing', stateful([[443, 443]], []));
run('stateless: in 443, out 443', stateless([[443, 443]], [[443, 443]]));
run('stateless: in 443, out 1024-65535', stateless([[443, 443]], [[1024, 65535]]));

৩ · উৎস হিসেবে IP, নাকি অন্য group

নিয়মের উৎস দুইভাবে লেখা যায়। প্রথমটি CIDR, যেমন 10.0.2.0/24, যা একটি ঠিকানার পরিসর। CIDR-এর হিসাব একবার মনে করে নিন: /n মানে 2³²⁻ⁿটি ঠিকানা। তাই /32 মানে ১টি, /24 মানে ২৫৬টি, /8 মানে ১,৬৭,৭৭,২১৬টি, আর 0.0.0.0/0 মানে ৪,২৯,৪৯,৬৭,২৯৬টি, অর্থাৎ পুরো IPv4 internet. (বিস্তারিত হিসাব Subnetting পর্বে আর পর্ব ২৫-এ।)

দ্বিতীয় উপায়টি হলো security group reference: উৎসের জায়গায় অন্য একটি group-এর নাম। এর মানে “ওই group যেসব network interface-এ লাগানো আছে, তাদের private ঠিকানা থেকে এলে packet যাবে”। ঠিকানা আপনাকে লিখতে হয় না, provider নিজেই সদস্য তালিকা মিলিয়ে নেয়।

হিসাব করে দেখি: reference কেন জেতে

ধরে নিই একটি app স্তরে ৪০টি instance চলে, আর প্রতিটির দুটি port-এ database-এর সাথে কথা বলা দরকার। IP-এর তালিকা লিখলে নিয়ম লাগবে ৪০ × ২ = ৮০টি। AWS-এ লেখার সময়ে এক group-এ ডিফল্ট সীমা প্রতি দিকে ৬০টি নিয়মের কাছাকাছি (quota বাড়ানো যায়, আর provider-ভেদে সংখ্যা আলাদা)। অর্থাৎ তালিকাটি বসানোই যাবে না। Reference দিলে লাগে ২টি নিয়ম, instance ৩টি হোক বা ৪০টি।

সংখ্যার চেয়েও বড় সুবিধা তিনটি:

• Autoscaling-এ কিছু বদলাতে হয় না। নতুন instance group নিয়ে জন্মায়, পুরোনোটি চলে গেলে সদস্যপদও যায়। (পর্ব ১৭)
• পুরোনো IP-র ঝুঁকি নেই। IP-এর তালিকায় মুছে যাওয়া instance-এর ঠিকানা থেকে যায়, আর সেই ঠিকানা পরে অন্য কেউ পেয়ে যেতে পারে।
• নিয়ম পড়ে অর্থ বোঝা যায়। from sg-app একটি উদ্দেশ্য বলে। 10.0.2.37/32 কিছুই বলে না।

Chaining: তিন স্তরের অনলাইন দোকান

একটি কাল্পনিক অনলাইন বাজার অ্যাপ ধরি: সামনে load balancer, মাঝে app server, পেছনে database. প্রতিটি স্তর শুধু তার আগের স্তরকে বিশ্বাস করে। একে বলে security group chaining. নিচের ছবিতে প্রতিটি তীর একটি নিয়ম, আর ছবিতে যে তীর নেই, সেই পথ বন্ধ।

খেয়াল করুন, sg-db-তে outbound নিয়ম নেই, তবু database উত্তর দিতে পারে। এটিই stateful হওয়ার সুবিধা। আর একটি কথা: reference নিয়ম অন্য group-এর নিয়ম কপি করে না, শুধু তার সদস্যদের চিনিয়ে দেয়। Chaining network-এর পথ সরু করে, কিন্তু app server হাতছাড়া হলে database-এ পথ থাকবেই। তাই database-এ আলাদা login, কম অনুমতি আর এনক্রিপশন লাগেই (পর্ব ২২)।

৪ · Network ACL — ক্রমে চলা, স্মৃতিহীন নিয়ম

NACL-এর প্রতিটি নিয়মের একটি নম্বর থাকে। Firewall সবচেয়ে ছোট নম্বর থেকে পড়তে শুরু করে। প্রথম যে নিয়ম মেলে, সেটির কথাই শেষ কথা; পরের নিয়ম আর পড়া হয় না। কিছুই না মিললে শেষের * নিয়মটি আটকে দেয়, যা মোছা যায় না।

রেলের সময়সূচির মতো ভাবুন: ওপর থেকে পড়তে পড়তে প্রথম যে ট্রেন মেলে, আপনি সেটিতেই ওঠেন। নিচে আরও ভালো ট্রেন থাকলেও লাভ নেই। সেজন্য একটি নির্দিষ্ট deny নিয়ম সব সময় সাধারণ allow-এর আগে, অর্থাৎ ছোট নম্বরে বসাতে হয়। না হলে সেটি কখনো কাজই করে না। একে বলে rule shadowing. নম্বর দেওয়ার সময় ১০০, ১১০, ১২০ এভাবে ফাঁক রাখুন, যাতে পরে মাঝখানে নতুন নিয়ম বসানো যায়।

// Network ACL: lowest rule number first, the first match decides, then stop.
const ip2n = s => s.split('.').reduce((a, b) => a * 256 + Number(b), 0);
function inCidr(ip, cidr) {
  const [net, len] = cidr.split('/');
  const size = 2 ** (32 - Number(len));
  return Math.floor(ip2n(ip) / size) === Math.floor(ip2n(net) / size);
}
function evaluate(acl, p) {
  const sorted = [...acl].sort((a, b) => a.no - b.no);
  const trail = [];
  for (const r of sorted) {
    const hit = inCidr(p.src, r.cidr) && p.port >= r.lo && p.port <= r.hi;
    trail.push(`${r.no}:${hit ? 'match' : 'skip'}`);
    if (hit) return `${r.action} by ${r.no}  [${trail.join(' ')}]`;
  }
  return `DENY by *  [${trail.join(' ')} *:match]`;
}
const DENY_FIRST = [
  { no: 200, action: 'ALLOW', cidr: '0.0.0.0/0', lo: 443, hi: 443 },
  { no: 100, action: 'DENY', cidr: '198.51.100.0/24', lo: 0, hi: 65535 },
];
const ALLOW_FIRST = [
  { no: 100, action: 'ALLOW', cidr: '0.0.0.0/0', lo: 443, hi: 443 },
  { no: 200, action: 'DENY', cidr: '198.51.100.0/24', lo: 0, hi: 65535 },
];
const packets = [
  { src: '198.51.100.9', port: 443 },
  { src: '203.0.113.7', port: 443 },
  { src: '203.0.113.7', port: 22 },
];
for (const [name, acl] of [['deny first', DENY_FIRST], ['allow first', ALLOW_FIRST]]) {
  console.log('--- ' + name);
  for (const p of packets) console.log(`${p.src}:${p.port}`.padEnd(18), evaluate(acl, p));
}

Ephemeral port: ফিরতি পথের ঠিকানা

আপনি browser-এ একটি সাইট খুললে সংযোগের গন্তব্য port হয় 443. কিন্তু browser নিজেও একটি port থেকে কথা বলে, আর সেই port অপারেটিং সিস্টেম সংযোগের জন্য সাময়িকভাবে বেছে দেয়। একে বলে ephemeral port. Server-এর উত্তরের গন্তব্য port হয় সেটিই। NACL যেহেতু কিছু মনে রাখে না, তাকে নিয়ম করে বলে দিতে হয়: এই পরিসরের port-এ উত্তর বেরোতে পারবে।

হিসাবটি সহজ: শেষ − শুরু + ১। যেমন ৬৫,৫৩৫ − ১,০২৪ + ১ = ৬৪,৫১২। ক্লায়েন্ট কে হবে, তা আপনি ঠিক করতে পারেন না, তাই public দিকের NACL-এ সবচেয়ে চওড়া পরিসরটিই সাধারণত লিখতে হয়। উল্টো দিকও ভুলবেন না: আপনার server নিজে বাইরে কোনো API-কে ডাকলে তার উত্তর inbound হয়ে ephemeral port-এ ঢোকে।

এবার একটি পুরো যাত্রা দেখি। ক্লায়েন্ট 203.0.113.7 একটি web server-এ HTTPS অনুরোধ পাঠাচ্ছে। সহজ রাখার জন্য ঠিকানা-অনুবাদের অংশ (NAT) বাদ দিয়ে server-এর private ঠিকানা 10.0.1.20 দেখানো হলো। NACL-এর নিয়ম এরকম: inbound ১০০ allow TCP 443; outbound ১০০ allow TCP 443 আর ১১০ allow TCP 1024-65535.

এবার সেই বিখ্যাত ভুলটি দেখি। একজন সহকর্মী নিরাপত্তা বাড়াতে নতুন NACL বসালেন, কিন্তু outbound-এ শুধু 443 রাখলেন। নতুনদের হাতে এই ঘটনা অনেকবার ঘটে, কারণ নিয়মটি দেখতে একদম যুক্তিসঙ্গত লাগে।

এজন্য অনেক দলের ব্যবহারিক পরামর্শ হলো: মূল নিয়ন্ত্রণ security group-এ রাখুন, NACL-কে খোলা রেখে শুধু বিশেষ কাজে ব্যবহার করুন। যেমন একটি পুরো ঠিকানা-পরিসর দ্রুত আটকানো, বা সংবেদনশীল subnet-এর চারপাশে মোটা দাগের একটি সীমা টানা। AWS-এর default NACL সব allow করে, কিন্তু আপনার বানানো নতুন NACL শুরুতে সব deny করে। তাই নতুন NACL লাগানো মানেই subnet-এর সব traffic বন্ধ হওয়ার ঝুঁকি।

৫ · অন্য provider-এ একই ধারণা, ভিন্ন নিয়ম

ধারণা একই, কিন্তু আচরণ হুবহু এক নয়। এক provider-এর অভ্যাস অন্যটিতে নিয়ে গেলে ভুল হয়, তাই নিচের তুলনাটি মানচিত্র হিসেবে নিন, সমীকরণ হিসেবে নয়। খুঁটিনাটি লেখার সময়ের, তাই আসল সিদ্ধান্তের আগে provider-এর নথি দেখে নিন।

একটি ব্যবহারিক ফাঁদ: AWS-এর group-এ ক্রম নিয়ে ভাবতে হয় না, কিন্তু Azure আর Google-এ priority ভুল হলে একটি deny আপনার allow-কে ঢেকে ফেলতে পারে। নিচে একই নিয়ম, “app থেকে database-এ 5432”, তিন CLI-তে। এগুলো উদাহরণ মাত্র, আইডি ও নাম কাল্পনিক। Cloud ব্যবহারে টাকা লাগতে পারে, আর পরীক্ষার পর resource মুছে ফেলবেন।

# Allow PostgreSQL into the db group, only from members of the app group
aws ec2 authorize-security-group-ingress \
  --group-id sg-0db0000000example \
  --protocol tcp --port 5432 \
  --source-group sg-0a00000000example

# Lower priority number is read first; the source is an application security group
az network nsg rule create \
  --resource-group shop-rg --nsg-name db-nsg \
  --name allow-app-to-db --priority 200 \
  --direction Inbound --access Allow --protocol Tcp \
  --source-asgs app-asg --destination-port-ranges 5432

# Target and source are network tags on the VMs
gcloud compute firewall-rules create allow-app-to-db \
  --network shop-net --direction INGRESS --action ALLOW \
  --rules tcp:5432 --source-tags app --target-tags db

৬ · 0.0.0.0/0 — কোন দরজায় চলে, কোন দরজায় নয়

Public website-এর 443-এ 0.0.0.0/0 স্বাভাবিক, কারণ সেটিই দোকানের সদর দরজা। সমস্যা হয় যখন একই মান বসে পেছনের দরজায়:

• SSH (22): Internet-এ চালু থাকা যেকোনো server-এ স্বয়ংক্রিয় স্ক্যান আসতেই থাকে। Key ছাড়া login বন্ধ থাকলেও sshd-এর নিজের দুর্বলতার ঝুঁকি থাকে।
• RDP (3389): Windows server-এর দূর-নিয়ন্ত্রণ। অতীতে login ছাড়াই আক্রমণযোগ্য ত্রুটি পাওয়া গেছে (যেমন ২০১৯-এর BlueKeep, CVE-2019-0708), তাই internet-এ খোলা রাখা বড় ঝুঁকি।
• Database (3306, 5432, 6379, 27017): এগুলো internet-এর জন্য তৈরিই হয়নি। ভুল সেটিংয়ে কিছু database login ছাড়াই খোলা থাকে।

IPv6 ভুলবেন না: ::/0 মানে একই জিনিস, পুরো IPv6 internet. 0.0.0.0/0 মুছে ::/0 রেখে দিলে দরজা খোলাই থাকে। আর port-এর পরিসর দেখেও সতর্ক হোন, 3000-3400 লিখলে তার ভেতরে 3306 আর 3389 দুটিই ঢুকে যায়।

এবার একটি অডিটর। ধরা যাক প্রতিটি নিয়মের সাথে আপনি flow log থেকে জেনেছেন কত দিন কোনো traffic আসেনি (idle মান)। নিচের সিমুলেটর ঝুঁকি খুঁজে গুরুত্ব অনুযায়ী সাজায়। গুরুত্বের নামগুলো এই উদাহরণের নিজস্ব, কোনো মান (standard) নয়।

// Flag risky security-group rules. Sample data; the severity scheme is ours, not a standard.
const ADMIN = { 22: 'SSH', 3389: 'RDP' };
const DB = { 3306: 'MySQL', 5432: 'PostgreSQL', 6379: 'Redis', 27017: 'MongoDB' };
const RANK = { CRITICAL: 0, HIGH: 1, MEDIUM: 2, LOW: 3 };
const rules = [
  { id: 'r1', group: 'sg-alb', lo: 443, hi: 443, src: '0.0.0.0/0', note: 'public https', idle: 0 },
  { id: 'r2', group: 'sg-app', lo: 22, hi: 22, src: '0.0.0.0/0', note: '', idle: 12 },
  { id: 'r3', group: 'sg-db', lo: 5432, hi: 5432, src: '::/0', note: 'temp debug', idle: 200 },
  { id: 'r4', group: 'sg-db', lo: 5432, hi: 5432, src: 'sg-app', note: 'app to db', idle: 0 },
  { id: 'r5', group: 'sg-old', lo: 0, hi: 65535, src: '10.0.0.0/8', note: 'vendor test', idle: 400 },
  { id: 'r6', group: 'sg-app', lo: 3000, hi: 3400, src: '0.0.0.0/0', note: 'dev tool', idle: 30 },
  { id: 'r7', group: 'sg-app', lo: 8080, hi: 8080, src: '10.0.1.25/32', note: 'old lb node', idle: 120 },
];
const isOpen = s => s === '0.0.0.0/0' || s === '::/0';
const covered = (map, r) => Object.keys(map).map(Number)
  .filter(p => p >= r.lo && p <= r.hi).map(p => map[p]);
function audit(r) {
  const found = [], admin = covered(ADMIN, r), db = covered(DB, r);
  if (isOpen(r.src) && admin.length) found.push(['CRITICAL', `internet to admin port ${admin}`]);
  if (isOpen(r.src) && db.length) found.push(['CRITICAL', `internet to database port ${db}`]);
  if (r.hi - r.lo >= 1000) found.push(['HIGH', `wide port range ${r.lo}-${r.hi}`]);
  if (r.src.endsWith('/32')) found.push(['MEDIUM', 'fixed IP, prefer a group reference']);
  if (r.idle >= 90) found.push(['MEDIUM', `no traffic for ${r.idle} days`]);
  if (!r.note) found.push(['LOW', 'no description']);
  return found.map(([sev, msg]) => ({ sev, msg, id: r.id, group: r.group }));
}
const report = rules.flatMap(audit).sort((a, b) => RANK[a.sev] - RANK[b.sev]);
for (const f of report) console.log(f.sev.padEnd(9), f.id, f.group.padEnd(7), f.msg);
const clean = rules.filter(r => audit(r).length === 0).map(r => r.id);
console.log(`\n${report.length} findings, clean rules: ${clean.join(', ')}`);

একই কাজ pipeline-এ করা যায় ছোট একটি shell script দিয়ে। Provider-এর CLI থেকে নিয়মগুলো বের করে CSV বানানো গেলে নিচের awk অংশ ঝুঁকিপূর্ণ নিয়ম ধরবে। এখানে CSV block-এর ভেতরেই বানানো হয়েছে, তাই কোনো account লাগে না।

set -euo pipefail
export LC_ALL=C
cd "$(mktemp -d)"
cat > rules.csv <<'CSV'
group,direction,proto,from_port,to_port,source,description
sg-alb,in,tcp,443,443,0.0.0.0/0,public https
sg-bastion,in,tcp,22,22,0.0.0.0/0,temp admin access
sg-app,in,tcp,8080,8080,sg-alb,from load balancer
sg-app,in,tcp,22,22,sg-bastion,admin through bastion
sg-win,in,tcp,3389,3389,::/0,windows admin
sg-db,in,tcp,5432,5432,0.0.0.0/0,temp debug
sg-db,in,tcp,5432,5432,sg-app,from app
sg-old,in,tcp,0,65535,0.0.0.0/0,vendor test
sg-app,out,tcp,443,443,0.0.0.0/0,payment api
CSV

awk -F, '
BEGIN { split("22 3389 3306 5432 6379 27017", ports, " ") }
NR == 1 || $2 != "in" { next }
$6 != "0.0.0.0/0" && $6 != "::/0" { next }
{
  found = ""
  for (i = 1; i in ports; i++)
    if (ports[i] + 0 >= $4 + 0 && ports[i] + 0 <= $5 + 0) found = found " " ports[i]
  if (found != "") { print $1 ":" found " open to " $6 " (" $7 ")"; n++ }
}
END { print "risky rules: " n + 0 }
' rules.csv > report.txt

cat report.txt
echo "--- rules per group"
grep -v '^risky' report.txt | cut -d: -f1 | sort | uniq -c | sort -rn

৭ · নিয়মের সীমা, পরিষ্কার করা আর flow log দিয়ে যাচাই

নিয়মের সীমা

নিয়ম অসীম নয়, কারণ প্রতিটি packet-এ এগুলো মেলাতে হয়। AWS-এ লেখার সময়ে ডিফল্ট হিসাব মোটামুটি এরকম: এক group-এ প্রতি দিকে ৬০টি নিয়ম, এক interface-এ ৫টি group, এক NACL-এ প্রতি দিকে ২০টি নিয়ম। অর্থাৎ এক interface-এ সর্বোচ্চ ৫ × ৬০ = ৩০০টি নিয়ম। কিছু quota বাড়ানো যায়, আর সংখ্যা বদলাতে পারে। অন্য provider-এর হিসাব আলাদা, সেখানকার quota পাতা দেখুন। সীমায় ঠেকলে প্রায়ই সেটি নকশার গন্ধ: reference, prefix list বা নিয়ম একত্র করার সময় এসেছে।

পুরোনো নিয়ম পরিষ্কার করা

Firewall-এর নিয়ম সহজে বাড়ে, কমে না। কেউ “দুই দিনের জন্য” একটি নিয়ম খোলেন, তারপর ভুলে যান। মুছতে সবাই ভয় পান, কারণ জানেন না কে ব্যবহার করছে। প্রতিকার হলো অভ্যাস:

• প্রতিটি নিয়মে description আর owner tag রাখুন; অস্থায়ী নিয়মে মেয়াদের তারিখ।
• সব নিয়ম IaC-তে লিখুন, যাতে পরিবর্তন review হয় আর হাতে করা বদল drift হিসেবে ধরা পড়ে (পর্ব ৫১)।
• নিয়মিত সময়ে, ধরুন প্রতি ত্রৈমাসিকে, অডিট চালান। ৯০ দিন traffic না থাকলে owner-কে জিজ্ঞেস করুন।
• “Traffic নেই” প্রমাণ নয়। মাসে একবার চলা job বা disaster recovery-র পথ ৯০ দিন চুপ থাকতে পারে। তাই মোছার আগে যাচাই করুন, আর ফেরত আনার পথ তৈরি রাখুন।

Flow log: কী ঘটল তার হিসাব

Flow log হলো network interface দিয়ে কোন সংযোগ গেল আর কোনটি আটকাল, তার সারাংশ রেকর্ড। এতে ঠিকানা, port, packet সংখ্যা আর ফল থাকে, কিন্তু ডেটার ভেতরের লেখা থাকে না। নিচে AWS-এর ডিফল্ট format-এর দুটি নমুনা লাইন, হাতে লেখা, কোনো আসল account-এর নয়। শেষ দিকের ACCEPT বা REJECT খেয়াল করুন।

2 123456789012 eni-0abc1234example 203.0.113.7 10.0.1.20 51514 443 6 8 1120 1761800000 1761800060 ACCEPT OK
2 123456789012 eni-0abc1234example 10.0.1.20 203.0.113.7 443 51514 6 6 3400 1761800000 1761800060 REJECT OK

ক্রমটি হলো version, account, interface, source IP, destination IP, source port, destination port, protocol (6 মানে TCP), packet, byte, শুরু, শেষ, ফল আর log-এর অবস্থা। এই জোড়াটি পড়ে বলা যায়, অনুরোধ ঢুকেছে, উত্তর আটকেছে, অর্থাৎ অংশ ৪-এর সেই NACL ভুল। উল্টোটিও সত্য: inbound-এই REJECT মানে NACL বা security group, দুটির যেকোনো একটি হতে পারে। Log সাধারণত কয়েক মিনিট দেরিতে আসে, আর রাখতে storage-এর খরচ আছে। Azure আর Google-এ নাম ও format আলাদা, ধারণা এক। সরাসরি পথ যাচাইয়ে পর্ব ১৩-এর ss আর curl কাজে আসবে। আর কিছু traffic, যেমন provider-এর নিজস্ব DNS বা metadata ঠিকানায় যাওয়া, অনেক সময় log বা নিয়মের আওতার বাইরে থাকে।

খোলা database, চলমান দোকান: নিরাপদে কড়া করা

এখন আসল পরীক্ষা। আপনি দেখলেন sg-db-তে 5432 সবার জন্য খোলা, আর দোকান চলছে। সরাসরি মুছলে কোনো অজানা সার্ভিস বন্ধ হতে পারে। Allow নিয়ম যোগফলে কাজ করে, তাই ক্রমটি হলো: আগে নতুন সরু নিয়ম যোগ, যাচাই, তারপর পুরোনোটি বাদ।

# Step 3: add the narrow rule first
aws ec2 authorize-security-group-ingress --group-id sg-0db0000000example \
  --protocol tcp --port 5432 --source-group sg-0a00000000example

# Step 5: only after checking, remove the wide rule
aws ec2 revoke-security-group-ingress --group-id sg-0db0000000example \
  --protocol tcp --port 5432 --cidr 0.0.0.0/0

৮ · Firewall একা নয় — স্তরে স্তরে নিরাপত্তা

Firewall ঠিক করে কে দরজা পর্যন্ত পৌঁছাবে। কে ভেতরে কী করবে, সেটি সে জানে না। একটি allow করা 443 সংযোগের ভেতর দিয়ে আসা খারাপ অনুরোধ security group দেখতে পায় না। তাই firewall প্রথম ও একমাত্র ভরসা নয়, এটি নিরাপত্তার একটি স্তর। একে বলে defense in depth: এক স্তর ব্যর্থ হলে পরেরটি ধরবে, যেমন গুদামঘরে গেটের তালা, ভেতরের ঘরের তালা আর সিন্দুকের তালা আলাদা। পূর্ণ ছবি পাবেন পর্ব ৩৪-এ, আর নকশার দিক System Design কোর্সে।

Managed network firewall

Security group five-tuple দেখে, domain name দেখে না। “App শুধু payments.example.com-এ যেতে পারবে” এমন নিয়ম এতে লেখা যায় না। এর জন্য আছে managed network firewall: AWS Network Firewall, Azure Firewall, Google Cloud-এর Cloud NGFW. এগুলো traffic-এর পথের মাঝে বসে domain-ভিত্তিক outbound নিয়ম, অনুপ্রবেশ শনাক্তকরণ আর কেন্দ্রীয় নীতি দেয়। দাম হলো route বদল (পর্ব ২৬), আলাদা খরচ আর বাড়তি latency. দাম ঘণ্টা ও ডেটার হিসাবে আসে, provider-এর দামের পাতা দেখে তবেই সিদ্ধান্ত নিন। ছোট দোকানে সাধারণত দরকার নেই, নিয়ন্ত্রিত শিল্পে বা অনেক VPC-তে কাজে লাগে। Kubernetes-এর ভেতরে এই কাজের সমতুল্য NetworkPolicy (পর্ব ৪৯), আর container network-এর ভিত্তি আছে এই পর্বে।

৯ · AI-এর যুগে firewall-এর নিয়ম

“সংযোগ হচ্ছে না” বললে AI-এর সবচেয়ে সহজ উত্তর হলো 0.0.0.0/0, কারণ তাতে সমস্যাটি সাথে সাথে চলে যায়। সমস্যা যায়, ঝুঁকি থেকে যায়। AI আপনার নেটওয়ার্ক দেখতে পায় না, তাই নিয়ম পড়ে যাচাই করার দায়িত্ব আপনার।

AI-এর দেওয়া নিয়ম হাতে পেলে — চেকলিস্ট

• প্রতিটি 0.0.0.0/0 আর ::/0 চিহ্নিত করেছি, এবং সেগুলো শুধু public দরজায় আছে
• Port-এর পরিসরের ভেতরে admin বা database port লুকিয়ে নেই
• Stateful স্তরে উত্তরের বাড়তি নিয়ম নেই, stateless স্তরে উত্তরের নিয়ম আছে
• IP-এর বদলে group reference ব্যবহার করেছি, যেখানে সম্ভব
• terraform plan বা --dry-run দেখে diff পড়েছি, throwaway পরিবেশে পরীক্ষা করেছি
• Flow log দিয়ে দেখেছি যা চেয়েছি তাই ঘটছে, শুধু “চলছে” দেখে থামিনি
• নিয়মে description, owner আর প্রয়োজনে মেয়াদ আছে; budget alert বসানো আছে