OS নিরাপত্তা — authentication, privilege ring আর memory-সুরক্ষা

১ · নিরাপত্তার মূল প্রশ্ন — CIA triad, threat, vulnerability আর attack

পর্ব ৪৬-এ দেখেছেন protection — OS-এর ভেতরের নিয়ম, কোন প্রসেস কোন resource-এ কী করতে পারবে। Security বা নিরাপত্তা আরও বড় প্রশ্ন: কেউ যদি ইচ্ছে করে নিয়ম ভাঙতে চায় — বাইরের আক্রমণকারী, ক্ষতিকর প্রোগ্রাম, এমনকি ভেতরের কোনো মানুষ — তখন সিস্টেম কতটা টেকে? Protection হলো তালা-চাবির ব্যবস্থা; security হলো সেই প্রশ্ন, চোর এলে তালাটি আসলে কাজ করবে কি না।

CIA triad — কী রক্ষা করছি

অনেকে যোগ করেন accountability — কে কী করল, পরে প্রমাণ করা যায় কি না (log আর audit-এর কাজ)।

Threat, vulnerability, attack — তিনটি আলাদা শব্দ

• Vulnerability: সফটওয়্যার, কনফিগারেশন বা মানুষের অভ্যাসের এমন ত্রুটি, যা অপব্যবহার করা যায় — একটি memory বাগ, ডিফল্ট পাসওয়ার্ড, সবার জন্য খোলা ফাইল। প্রকাশিত দুর্বলতাগুলো একটি সাধারণ নম্বর পায়, যাকে বলে CVE.
• Exploit: নির্দিষ্ট একটি দুর্বলতা কাজে লাগানোর পদ্ধতি বা কোড। এই পর্বে আমরা exploit লিখব না — শিখব কোন ব্যবস্থা তা কঠিন বা অসম্ভব করে।
• Attack surface: বাইরের জগৎ সিস্টেমের যত জায়গা ছুঁতে পারে — খোলা network port, ইনপুট নেওয়া প্রোগ্রাম, system call, USB পোর্ট। যত ছোট, তত কম ঝুঁকি।
• Threat model: নকশার শুরুতে চারটি প্রশ্নের উত্তর — কী রক্ষা করছি, কার কাছ থেকে, সে কী কী পারে, আর ব্যর্থ হলে ক্ষতি কত। একটি ব্যক্তিগত ল্যাপটপ আর একটি ব্যাংকের সার্ভারের threat model আলাদা, তাই প্রতিরক্ষাও আলাদা।

২ · হুমকির ধরন — malware, ভেতরের মানুষ আর প্রতারণা

ক্ষতিকর সফটওয়্যারকে একসাথে বলে malware. কীভাবে ছড়ায় আর কী করে, তা দিয়ে কয়েকটি প্রধান ধরন — এখানে শুধু সংজ্ঞা, যাতে খবর বা নিরাপত্তা-রিপোর্ট পড়ে বুঝতে পারেন:

এর বাইরে আছে spyware (গোপনে তথ্য পাঠায়) আর botnet (হাজারো আক্রান্ত মেশিনকে দূর থেকে একসাথে চালানো)। বুটের স্তরে বসা rootkit-কে bootkit বলে — পর্ব ০৭-এ Secure Boot সেই হুমকির বিরুদ্ধেই দেখেছেন।

ভেতরের মানুষ আর প্রতারণা

• Insider threat: প্রতিষ্ঠানের ভেতরের কেউ — কর্মী, ঠিকাদার — যাঁর বৈধ প্রবেশাধিকার আছে, তিনি ইচ্ছায় বা অসাবধানে ক্ষতি করেন। প্রতিরক্ষা প্রযুক্তি আর নিয়ম দুটোই: প্রয়োজনের চেয়ে বেশি অধিকার না দেওয়া, গুরুত্বপূর্ণ কাজে দুজনের অনুমোদন, আর প্রতিটি admin কাজের log.
• Social engineering: প্রযুক্তি নয়, মানুষের বিশ্বাস আর তাড়াহুড়োকে কাজে লাগানো — “আমি ব্যাংক থেকে বলছি, আপনার অ্যাকাউন্ট বন্ধ হয়ে যাবে, এখনই কোডটি বলুন।”
• Phishing: আসলের মতো দেখতে নকল ইমেইল, SMS বা ওয়েবসাইট দিয়ে পাসওয়ার্ড বা OTP আদায়। সবচেয়ে মজবুত OS-ও রক্ষা করতে পারে না, যদি মানুষ নিজেই চাবি তুলে দেন — তাই অংশ ৪-এর passkey এত গুরুত্বপূর্ণ।

৩ · Authentication — “আপনি যে আপনিই”, তার প্রমাণ

OS কাউকে কিছু করতে দেওয়ার আগে দুটি প্রশ্ন করে। প্রথমটি authentication — আপনি কে, প্রমাণ দিন। দ্বিতীয়টি authorization — প্রমাণিত এই ব্যবহারকারী এই কাজটি করতে পারেন কি না (অংশ ৫, আর বিস্তারিত পর্ব ৪৬ ও ৪৭-এ)। প্রমাণ দেওয়ার তিন রকম উপায়, যাকে বলে factor:

• যা আপনি জানেন: পাসওয়ার্ড, PIN, passphrase.
• যা আপনার কাছে আছে: মোবাইল ফোন, security key, স্মার্ট কার্ড।
• যা আপনি নিজে: আঙুলের ছাপ, মুখ — biometrics. আধুনিক ফোনে biometrics সাধারণত শুধু ডিভাইসের ভেতরের চাবিটি খোলে; আঙুলের ছাপ সার্ভারে যায় না।

পাসওয়ার্ড কীভাবে রাখা হয় — hash, salt আর ইচ্ছাকৃত ধীরতা

সার্ভার বা OS যদি পাসওয়ার্ড সরাসরি লিখে রাখে, তাহলে ফাইলটি একবার চুরি হলেই সবার পাসওয়ার্ড ফাঁস। তাই রাখা হয় একটি cryptographic hash — একমুখী হিসাব, যা থেকে আসল পাসওয়ার্ড উল্টো করে বের করা যায় না। লগইনের সময় আপনার টাইপ করা পাসওয়ার্ডের hash আবার হিসাব করে মেলানো হয়। কিন্তু শুধু hash যথেষ্ট নয়, দুটি কারণে:

1. একই পাসওয়ার্ড, একই hash: হাজার জন যদি 123456 ব্যবহার করেন, চুরি হওয়া ফাইলে হাজারটি একই সারি। আর জনপ্রিয় পাসওয়ার্ডের hash আগে থেকে হিসাব করা টেবিলে (rainbow table) মিলিয়ে নেওয়া যায়। সমাধান salt: প্রতিটি ব্যবহারকারীর জন্য একটি এলোমেলো মান, পাসওয়ার্ডের সাথে মিশিয়ে hash. salt গোপন নয়, hash-এর পাশেই থাকে — কিন্তু এখন একই পাসওয়ার্ডেও hash আলাদা, আর আগে-বানানো টেবিল অকেজো।
2. দ্রুত hash পাসওয়ার্ডের শত্রু: MD5, SHA-1 বা SHA-256 বানানো হয়েছে বড় ফাইল দ্রুত যাচাই করতে। ফাইল চুরি হলে একজন আক্রমণকারী নিজের মেশিনে (অফলাইনে) অনুমান করে করে মেলাতে পারে — দ্রুত hash-এ সেকেন্ডে বিপুলসংখ্যক অনুমান। সমাধান ইচ্ছাকৃত ধীর, অনেক মেমরি খায় এমন hash — key stretching: ১৯৯৯-এর bcrypt, ২০০৯-এর scrypt, আর ২০১৫ সালে Password Hashing Competition জেতা Argon2. বৈধ ব্যবহারকারীর কাছে একটি লগইনে কয়েকশো মিলিসেকেন্ড কিছুই নয়; কিন্তু কোটি কোটি অনুমানের কাছে প্রতিটির এই দাম বিশাল।

নিচের stepper-এ আসল scrypt (N = 16384, r = 8, p = 1) দিয়ে হিসাব করা মান দেখানো হয়েছে, পড়ার সুবিধায় hash-এর শুধু প্রথম ১৬টি hex অক্ষর:

1 register rahima: salt = random()2 store scrypt(pw, salt, params)3 register karim: same pw, new salt4 login rahima: recompute + compare5 login rahima: wrong password6 after the check

বিভিন্ন OS কোথায় রাখে

Linux-এ /etc/passwd-এ ব্যবহারকারীর নাম আর UID থাকে, পাসওয়ার্ডের ঘরে শুধু x; আসল hash /etc/shadow-এ, যা সাধারণ ব্যবহারকারী পড়তে পারেন না। hash-এর শুরুর চিহ্ন বলে দেয় অ্যালগরিদম: $6$ মানে SHA-512 crypt (হাজারো পুনরাবৃত্তির ধীর রূপ), $y$ মানে yescrypt — সাম্প্রতিক বেশ কিছু distro (যেমন Debian 11, Ubuntu 22.04, Fedora 35 থেকে) এটিকে ডিফল্ট করেছে বলে জানা যায়।

$ grep rahima /etc/passwd
rahima:x:1001:1001:Rahima Akter:/home/rahima:/bin/bash
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1342 Oct 20 10:12 /etc/shadow
$ sudo grep rahima /etc/shadow
rahima:$y$j9T$Kq3...salt...$Xw7...hash...:20381:0:99999:7:::
#       ^alg ^cost  ^salt       ^hash          ^last change (days since 1970)

Windows-এ স্থানীয় অ্যাকাউন্টের তথ্য থাকে SAM database-এ, আর লগইনের কাজ সামলায় LSASS প্রসেস; Windows Hello আর macOS-এর Touch ID-তে আঙুল বা মুখ শুধু ডিভাইসের ভেতরের নিরাপদ চিপে রাখা চাবি খোলে। নিয়ম সবখানে এক: পাসওয়ার্ড বা biometrics-এর আসল রূপ যেন কোথাও খোলা না থাকে।

৪ · ভালো পাসওয়ার্ড, MFA, TOTP, passkey আর PAM

দৈর্ঘ্য জটিলতার চেয়ে বেশি দামি

যুক্তরাষ্ট্রের মান-সংস্থা NIST-এর নির্দেশিকা SP 800-63B ২০১৭ সালের সংস্করণ থেকে পুরোনো অনেক নিয়ম উল্টে দিয়েছে; পরের সংশোধনে দিকটি আরও কড়া। মূল ভাবনা (খুঁটিনাটি সংস্করণভেদে বদলায়):

• দৈর্ঘ্যই মূল: ন্যূনতম দৈর্ঘ্য বাড়ানো, আর লম্বা passphrase (অন্তত ৬৪ অক্ষর পর্যন্ত) ও স্পেস-সহ সব অক্ষর গ্রহণ করা।
• জোর করে “একটি বড় হাতের অক্ষর, একটি চিহ্ন” নয়: এমন নিয়মে মানুষ Password1!-এর মতো অনুমানযোগ্য রূপ বানান।
• নিয়মিত জোর করে বদলানো নয় — শুধু ফাঁসের প্রমাণ পেলে বদলানো।
• ফাঁস হওয়া ও খুব প্রচলিত পাসওয়ার্ডের তালিকার সাথে মিলিয়ে বাতিল, আর অনলাইনে বারবার ভুল চেষ্টায় rate limit.

কেন দৈর্ঘ্য? সম্ভাব্য পাসওয়ার্ডের সংখ্যা = (অক্ষরের সংখ্যা)^{দৈর্ঘ্য}. দৈর্ঘ্য ঘাতে বসে, তাই প্রতিটি বাড়তি অক্ষর গোটা সংখ্যাকে গুণ করে। নিচের calculator শুধু পাটিগণিত: একটি এলোমেলোভাবে বাছা পাসওয়ার্ড অফলাইনে গড়ে খুঁজে পেতে কত সময় লাগবে, দুটি ধরে-নেওয়া গতিতে — দ্রুত salt-ছাড়া hash-এ সেকেন্ডে ১০^১০ অনুমান, আর ঠিকমতো সাজানো ধীর hash-এ সেকেন্ডে ১০^৪. আসল গতি হার্ডওয়্যার আর cost-এর মানে অনেক বদলায়; সংখ্যাগুলো তুলনার জন্য।

// Offline guessing cost: keyspace / guess rate. Pure arithmetic, illustrative rates.
const FAST = 1e10;   // assumed guesses per second against a fast, unsalted hash (GPU rig)
const SLOW = 1e4;    // assumed guesses per second against a slow hash (bcrypt/Argon2 tuned)
const cases = [      // [description, symbols to choose from, length]
  ["8 digits",                      10,   8],
  ["8 lowercase letters",           26,   8],
  ["8 chars, all 94 printable",     94,   8],
  ["12 chars, all 94 printable",    94,  12],
  ["4 random words (7776 list)",  7776,   4],
  ["6 random words (7776 list)",  7776,   6],
];
const YEAR = 365.25 * 24 * 3600;
function human(sec) {
  if (sec < 1) return "< 1 second";
  if (sec < 60) return sec.toFixed(1) + " seconds";
  if (sec < 3600) return (sec / 60).toFixed(1) + " minutes";
  if (sec < 86400) return (sec / 3600).toFixed(1) + " hours";
  if (sec < YEAR) return (sec / 86400).toFixed(1) + " days";
  const y = sec / YEAR;
  return (y < 1e6 ? y.toFixed(0) : y.toExponential(1)) + " years";
}
console.log("password".padEnd(28) + "bits".padStart(6) + "   fast hash".padEnd(18) + "  slow hash");
for (const [name, symbols, len] of cases) {
  const space = symbols ** len;           // every possible password of this shape
  const bits = Math.log2(space);
  const avg = space / 2;                  // on average half the space is searched
  console.log(name.padEnd(28) + bits.toFixed(1).padStart(6) + "   " +
              human(avg / FAST).padEnd(16) + "  " + human(avg / SLOW));
}
console.log("\nslow hash is " + (FAST / SLOW).toExponential(0) + " times more work per guess");
console.log("Defence: long random passphrase + unique per site + MFA;");
console.log("servers: salted slow hash (Argon2id/bcrypt/scrypt) + rate limits.");

password                      bits   fast hash        slow hash
8 digits                      26.6   < 1 second        1.4 hours
8 lowercase letters           37.6   10.4 seconds      120.8 days
8 chars, all 94 printable     52.4   3.5 days          9658 years
12 chars, all 94 printable    78.7   754050 years      7.5e+11 years
4 random words (7776 list)    51.7   2.1 days          5793 years
6 random words (7776 list)    77.5   350270 years      3.5e+11 years

slow hash is 1e+6 times more work per guess
Defence: long random passphrase + unique per site + MFA;
servers: salted slow hash (Argon2id/bcrypt/scrypt) + rate limits.

MFA আর TOTP — ফোনের ছয় অঙ্কের কোড কোথা থেকে আসে

Multi-factor authentication মানে দুই বা ততোধিক ভিন্ন ধরনের factor. পাসওয়ার্ড চুরি হলেও দ্বিতীয় factor ছাড়া ঢোকা যায় না। Authenticator অ্যাপের ছয় অঙ্কের কোড আসে TOTP (time-based one-time password, RFC 6238, ২০১১) থেকে: সার্ভার আর ফোন একটি গোপন চাবি K ভাগ করে নেয়, তারপর দুজনেই আলাদাভাবে বর্তমান সময় থেকে একই কোড হিসাব করে। হিসাবের কেন্দ্রে HMAC — চাবি-নির্ভর একটি hash. নিচের মানগুলো RFC 6238-এর নিজস্ব পরীক্ষার চাবি দিয়ে হিসাব করা (বাস্তবে চাবি এলোমেলো):

Passkey — phishing-প্রতিরোধী লগইন

SMS-এ আসা OTP সুবিধাজনক, কিন্তু SIM বদলের প্রতারণা বা মানুষকে বুঝিয়ে কোড আদায়ের ঝুঁকি আছে; NIST-এর নির্দেশিকাও SMS-কে দুর্বলতর বিকল্প হিসেবে দেখে। সবচেয়ে মজবুত পথ FIDO2/WebAuthn (২০১৯ সালে W3C মান হয়), যার ভোক্তা-নাম passkey (২০২২ সাল থেকে Apple, Google আর Microsoft একসাথে প্রচার করছে):

• প্রতিটি সাইটের জন্য ডিভাইস একটি আলাদা public/private key জোড়া বানায়; সার্ভার পায় শুধু public key — চুরি হলেও লগইন করা যায় না।
• লগইনে সার্ভার একটি এলোমেলো challenge পাঠায়, ডিভাইস private key দিয়ে সই করে। Private key ডিভাইসের নিরাপদ চিপ (TPM, Secure Enclave) বা পাসওয়ার্ড-ম্যানেজারের ভেতরেই থাকে।
• মূল শক্তি: সইটি সাইটের আসল ঠিকানার (origin) সাথে বাঁধা — ব্রাউজার নিজে ঠিকানা মিলিয়ে দেয়। নকল ওয়েবসাইটের জন্য আসল সাইটের সই তৈরিই হয় না, তাই ব্যবহারকারী ভুল করলেও phishing কাজ করে না।

PAM — Linux-এ লগইনের নিয়মগুলো এক জায়গায়

login, sshd, sudo — প্রতিটি প্রোগ্রাম কি নিজে নিজে পাসওয়ার্ড যাচাই করে? না। Linux (আর অনেক Unix) ব্যবহার করে PAM — Pluggable Authentication Modules, যা ১৯৯০-এর দশকে Sun Microsystems-এ শুরু হয়। প্রতিটি সেবার নিয়ম /etc/pam.d/-এর একটি ফাইলে, ছোট ছোট module-এর তালিকা হিসেবে। নতুন নিয়ম (যেমন TOTP বা বারবার ভুলে অ্যাকাউন্ট আটকানো) যোগ করতে প্রোগ্রাম বদলাতে হয় না, শুধু তালিকা:

auth      required   pam_faillock.so preauth     # too many failures? stop early
auth      sufficient     pam_unix.so             # hash in /etc/shadow matches? done
auth      [default=die]  pam_faillock.so authfail  # reached only on failure: count it
password  requisite  pam_pwquality.so minlen=12  # reject short or common new passwords
password  required   pam_unix.so yescrypt        # store the new hash with yescrypt
session   required   pam_limits.so               # apply ulimits for the session

Windows-এ এই কাজ করে LSA আর তার authentication package (যেমন domain-এ Kerberos). PAM ফাইল ভুল সম্পাদনা করলে কেউই লগইন করতে না পারার ঝুঁকি থাকে — তাই একটি root shell খোলা রেখে পরীক্ষা করা হয়।

৫ · OS নিরাপত্তার শিকড় — privilege ring, kernel/user বিভাজন আর least privilege

পাসওয়ার্ড দরজা পাহারা দেয়। কিন্তু ভেতরে ঢোকার পর একটি প্রোগ্রাম কেন অন্য প্রোগ্রামের মেমরি পড়তে বা ডিস্কের যেকোনো সেক্টরে লিখতে পারে না? উত্তর হার্ডওয়্যারে। পর্ব ০৪ আর ০৫-এ দেখেছেন: CPU-র অন্তত দুটি অবস্থা — user mode আর kernel mode. x86-এ চারটি ring (০–৩), যার মধ্যে Linux, Windows আর macOS ব্যবহার করে শুধু ring 0 (kernel) আর ring 3 (অ্যাপ); ARM-এ একই ধারণা EL0 (অ্যাপ), EL1 (kernel), EL2 (hypervisor), EL3 (firmware-এর secure monitor).

তাই প্রতিটি system call একটি চেকপোস্ট: kernel সেখানে যাচাই করে প্রসেসটির পরিচয় (UID, group, capability) আর অনুমতি — এটিই authorization. পর্ব ৪৬-এ এর তত্ত্ব (domain, access matrix, ACL, capability), পর্ব ৪৭-এ Linux-এর বাস্তব রূপ (rwx, setuid, sudo). আর পর্ব ৪৯-এ দেখবেন কীভাবে seccomp আর SELinux এই চেকপোস্ট আরও কড়া করে।

Least privilege — যতটুকু দরকার, ঠিক ততটুকু

১৯৭৫ সালে Jerome Saltzer আর Michael Schroeder-এর বিখ্যাত নকশা-নীতির তালিকায় একটি নীতি: প্রতিটি প্রোগ্রাম আর মানুষ শুধু সেই অধিকার পাবে, যা তার কাজের জন্য অপরিহার্য — least privilege. বাস্তবে: দৈনন্দিন কাজ সাধারণ অ্যাকাউন্টে, admin অধিকার শুধু দরকারের মুহূর্তে (sudo, Windows-এর UAC); web server চালু হয়ে port 80 খোলার পর root ছেড়ে সাধারণ ব্যবহারকারী হয়ে যায়; ব্রাউজারের প্রতিটি tab আলাদা সীমিত প্রসেসে চলে। লক্ষ্য একটাই — কোনো অংশ ভাঙলে ক্ষতি যেন সেই অংশেই আটকে থাকে।

৬ · Memory-safety বাগ — buffer overflow, use-after-free আর integer overflow

C আর C++-এ লেখা কোড (প্রায় সব kernel, ব্রাউজারের ইঞ্জিন, অনেক system টুল) মেমরি সরাসরি নিয়ন্ত্রণ করে — দ্রুত, কিন্তু ভাষা নিজে সীমা পাহারা দেয় না। এমন ভুলকে বলে memory-safety বাগ, আর C মানদণ্ডে এগুলো undefined behavior. তিনটি প্রধান ধরন, শুধু ধারণা হিসেবে:

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

/* BUG: no length check; input longer than 15 chars overflows name[] */
void greet_bad(const char *input) {
    char name[16];
    strcpy(name, input);
    printf("hello %s\n", name);
}

/* FIX: the copy is bounded by the buffer size; long input is cut, not overflowed */
void greet_ok(const char *input) {
    char name[16];
    snprintf(name, sizeof name, "%s", input);
    printf("hello %s\n", name);
}

/* FIX for size arithmetic: check before multiplying (or use calloc, which checks) */
void *alloc_items(size_t count, size_t size) {
    if (size != 0 && count > SIZE_MAX / size) return NULL;   /* would wrap around */
    return malloc(count * size);
}

বাগ খুঁজতে development-এর সময় AddressSanitizer (-fsanitize=address), Valgrind আর fuzzing (এলোমেলো ইনপুট দিয়ে বারবার চালানো) ব্যবহার হয়; C-র নিরাপদ কোডিং নিয়ে বিস্তারিত আছে C কোর্সের undefined behavior ও secure coding পর্বে। কিন্তু কোটি লাইনের কোডে কিছু বাগ থেকেই যায় — তাই OS আর compiler মিলে আরেক স্তর পাহারা বসায়: বাগ থাকলেও তাকে কাজে লাগানো যেন কঠিন হয়, আর খারাপ কিছু ঘটার আগেই প্রোগ্রাম থেমে যায়।

৭ · স্তরে স্তরে প্রতিরক্ষা — NX, canary, ASLR, RELRO আর CFI

NX / DEP আর W^X — ডেটা কখনো কোড নয়

পর্ব ৩২-এর page table-এ প্রতিটি page-এর অনুমতি-বিট থাকে। আধুনিক x86-64-এ একটি বিশেষ বিট হলো NX (no-execute; Intel বলে XD) — AMD ২০০৩ সালে AMD64-এর সাথে আনে। এটি চালু থাকলে CPU সেই page থেকে নির্দেশ পড়তে অস্বীকার করে। OS নিয়ম করে stack, heap আর ডেটার page-এ NX বসায় — Windows-এ এর নাম DEP (data execution prevention, Windows XP SP2, ২০০৪)। মূল নীতির নাম W^X (write XOR execute, OpenBSD ২০০৩ সালে জনপ্রিয় করে): একটি page হয় লেখা যায়, নয় চালানো যায় — দুটি একসাথে নয়। ফলে কেউ ইনপুট দিয়ে মেমরিতে বাইট ঢোকাতে পারলেও সেগুলো নির্দেশ হিসেবে চলে না।

নিচের প্রোগ্রাম mmap দিয়ে একটি নতুন page নেয় — PROT_EXEC ছাড়া, শুধু পড়া-লেখা। /proc/self/maps থেকে অনুমতি দেখে, তারপর JIT compiler-এর মতো “লেখা শেষ, এবার শুধু পড়া আর চালানো” অবস্থায় mprotect দিয়ে বদলায়। কোনো কোড চালানো হয় না — শুধু অনুমতির স্ট্রিং ছাপা হয়:

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>
/* copy the perms of the /proc/self/maps line containing addr; count W+X lines */
static int perms_of(unsigned long addr, char out[8]) {
    char line[512], perms[8];  unsigned long lo, hi;  int wx = 0;
    FILE *f = fopen("/proc/self/maps", "r");
    strcpy(out, "?");
    if (!f) return -1;
    while (fgets(line, sizeof line, f)) {
        if (sscanf(line, "%lx-%lx %7s", &lo, &hi, perms) != 3) continue;
        if (strchr(perms, 'w') && strchr(perms, 'x')) wx++;
        if (addr >= lo && addr < hi) strcpy(out, perms);
    }
    fclose(f);
    return wx;
}
int main(void) {
    long pg = sysconf(_SC_PAGESIZE);
    char perm[8], *p = mmap(NULL, pg, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    int local = 0, wx;
    if (p == MAP_FAILED) { perror("mmap"); return 1; }
    strcpy(p, "config data");                        /* RW page: writing is allowed */
    perms_of((unsigned long)p, perm);      printf("new page (RW)      : %s\n", perm);
    if (mprotect(p, pg, PROT_READ | PROT_EXEC) != 0) { perror("mprotect"); return 1; }
    perms_of((unsigned long)p, perm);      printf("after mprotect R+X : %s\n", perm);
    perms_of((unsigned long)&local, perm); printf("stack              : %s\n", perm);
    wx = perms_of((unsigned long)&main, perm); printf("code of main()     : %s\n", perm);
    printf("W+X mappings in this process: %d\n", wx);
    printf("page size %ld, data still readable: \"%s\"\n", pg, p);
    munmap(p, pg);  return 0;
}

new page (RW)      : rw-p
after mprotect R+X : r-xp
stack              : rw-p
code of main()     : r-xp
W+X mappings in this process: 0
page size 4096, data still readable: "config data"

Stack canary — ফেরার আগে পাহারাদার পাখি

কয়লাখনিতে একসময় খাঁচায় ক্যানারি পাখি রাখা হতো; বিষাক্ত গ্যাসে পাখিটি আগে অসুস্থ হলে শ্রমিকেরা সতর্ক হতেন। Stack canary একই ধারণা: compiler প্রতিটি ঝুঁকিপূর্ণ ফাংশনের শুরুতে local buffer আর ফেরার ঠিকানার মাঝখানে একটি গোপন এলোমেলো মান বসায়, আর ফেরার ঠিক আগে মিলিয়ে দেখে। Buffer উপচে ফেরার ঠিকানার দিকে গেলে পথে canary-ও বদলায় — মিল না পেলে প্রোগ্রাম সঙ্গে সঙ্গে থেমে যায় (glibc-তে বার্তা *** stack smashing detected ***: terminated). ধারণাটি ১৯৯৮ সালের StackGuard গবেষণা থেকে; gcc-তে -fstack-protector (GCC 4.1 থেকে), আর বেশি ফাংশন ঢাকা -fstack-protector-strong (GCC 4.9 থেকে)। x86-64 Linux-এ glibc প্রতিটি প্রসেসের শুরুতে canary এলোমেলো করে thread-local জায়গায় রাখে। Windows-এর MSVC-তে সমতুল্য /GS.

ASLR আর PIE — ঠিকানা লুকিয়ে রাখা

ডেটা চালানো না গেলে আক্রমণকারী চাইতে পারে প্রোগ্রাম বা library-র আগে থেকে থাকা কোডের টুকরো জুড়ে কাজে লাগাতে — একে বলে code-reuse attack. তার জন্য জানতে হয় সেই কোড ঠিক কোন ঠিকানায়। পর্ব ০৮-এ দেখা ASLR প্রতিবার stack, heap, mmap এলাকা আর library-র ঠিকানা এলোমেলো করে; প্রোগ্রাম নিজে PIE হলে তার কোডের ঠিকানাও। ভুল ঠিকানায় লাফ দিলে প্রোগ্রাম crash করে — নিয়ন্ত্রণ নেওয়ার বদলে শুধু থেমে যাওয়া, আর বারবার crash log-এ ধরা পড়ে। Linux mainline-এ ASLR আসে ২০০৫ সালে (২.৬.১২), Windows-এ Vista (২০০৭) থেকে। সীমা: কোনো বাগ দিয়ে একটি ঠিকানাও ফাঁস হলে বাকিগুলোর অবস্থান অনুমান সহজ হয় — তাই ASLR একা নয়, অন্য স্তরের সাথে।

RELRO — লাফের টেবিল শুধু-পড়ার

Dynamic library-র ফাংশন ডাকা হয় GOT-এর ঠিকানা দেখে (C কোর্সের linker পর্বের বিষয়)। এই টেবিল লেখা যায় এমন থাকলে একটি memory বাগ দিয়ে তা বদলানো যেত। Partial RELRO কিছু অংশ শুধু-পড়ার করে; full RELRO (-Wl,-z,relro,-z,now) প্রোগ্রাম চালু হওয়ার সময়েই সব ঠিকানা মিলিয়ে (BIND_NOW) পুরো টেবিল শুধু-পড়ার করে দেয় — দাম শুধু একটু ধীর শুরু।

এবার নিজের চোখে দেখুন: একই ছোট প্রোগ্রাম দুইভাবে compile করে readelf দিয়ে ELF header পড়া — কোনো কিছু আক্রমণ করা হয় না, শুধু ফাইলের লেবেল পড়া:

cat > hello.c <<'EOF'
#include <stdio.h>
int main(int argc, char **argv) {
    char name[32];
    snprintf(name, sizeof name, "%s", argc > 1 ? argv[1] : "Dhaka");
    printf("hello, %s\n", name);
    return 0;
}
EOF
HARD="-O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fPIE -pie -Wl,-z,relro,-z,now"
WEAK="-O2 -fno-stack-protector -U_FORTIFY_SOURCE -no-pie -Wl,-z,norelro,-z,lazy"
gcc $HARD -o hard hello.c && gcc $WEAK -o weak hello.c || exit 1
check() {   # only reads ELF headers; nothing is attacked
  echo "== $1"
  readelf -h "$1" | grep 'Type:'
  readelf -lW "$1" | awk '$1=="GNU_STACK" || $1=="GNU_RELRO" {print "  " $1 " flags=" $(NF-1)}'
  readelf -d "$1" | grep -q BIND_NOW && echo "  BIND_NOW: yes" || echo "  BIND_NOW: no"
  readelf --dyn-syms -W "$1" | grep -q __stack_chk_fail && echo "  canary: yes" || echo "  canary: no"
  readelf --dyn-syms -W "$1" | grep -q __printf_chk && echo "  fortify: yes" || echo "  fortify: no"
}
check hard
check weak
./hard
./weak Sylhet

== hard
  Type:                              DYN (Position-Independent Executable file)
  GNU_STACK flags=RW
  GNU_RELRO flags=R
  BIND_NOW: yes
  canary: yes
  fortify: yes
== weak
  Type:                              EXEC (Executable file)
  GNU_STACK flags=RW
  BIND_NOW: no
  canary: no
  fortify: no
hello, Dhaka
hello, Sylhet

CFI আর shadow stack — লাফ দেওয়ার অনুমোদিত পথ

শেষ স্তরের প্রশ্ন: কোনো বাগ যদি তবুও ফেরার ঠিকানা বা একটি ফাংশন-pointer বদলায়? Control-flow integrity নিয়ম করে, প্রোগ্রাম শুধু তার বৈধ পথেই লাফ দিতে পারবে। দুই দিক: ফেরা (return) — হার্ডওয়্যারের shadow stack প্রতিটি call-এ ফেরার ঠিকানার একটি আলাদা, সাধারণ লেখার অযোগ্য কপি রাখে, আর ret-এর সময় দুটি না মিললে CPU exception তোলে। আর পরোক্ষ লাফ (function pointer) — শুধু চিহ্নিত বৈধ ফাংশন-শুরুতেই যাওয়া যায়। Intel CET (Control-flow Enforcement Technology) দুটিই দেয়, নতুন প্রজন্মের Intel ও AMD প্রসেসরে আছে বলে জানা যায়; Linux-এ user-space shadow stack-এর সমর্থন kernel ৬.৬ (২০২৩) নাগাদ যুক্ত হয়েছে, আর Windows-এ “hardware-enforced stack protection” নামে আছে — CPU, OS আর প্রোগ্রাম তিনটিকেই সমর্থন করতে হয়। সফটওয়্যার-রূপ: Windows-এর Control Flow Guard, clang-এর CFI; ARM-এ pointer authentication আর BTI একই লক্ষ্যে।

৮ · Kernel-এর নিজের পাহারা — KASLR, SMEP/SMAP, KPTI, Spectre আর memory-safe ভাষা

অ্যাপের জন্য যেমন, kernel-এর জন্যও একই ধরনের স্তর — কারণ kernel-এর একটি বাগই সবচেয়ে দামি।

• KASLR: বুটের সময় kernel-এর কোড আর ডেটার ঠিকানা এলোমেলো করা। Linux-এ ৩.১৪ (২০১৪)-এ যোগ হয়, পরে x86-এ ডিফল্ট চালু হয়। সাথে সাধারণ ব্যবহারকারী থেকে kernel-এর ঠিকানা লুকানো (kptr_restrict), যাতে ঠিকানা ফাঁস না হয়।
• SMEP (supervisor mode execution prevention) আর SMAP (… access prevention): Intel ২০১২ ও ২০১৪-এর দিকের প্রসেসরে আনে (AMD-ও পরে)। SMEP থাকলে kernel mode-এ থাকা CPU user মেমরির কোড চালাবে না; SMAP থাকলে kernel ইচ্ছাকৃতভাবে অনুমতি না খুললে user মেমরি পড়বেও না — kernel শুধু copy_from_user()-এর মতো নির্দিষ্ট পথে সাময়িক অনুমতি খোলে। ফলে kernel-কে ভুল করে user-এর ফাঁদে টেনে আনার একটি বড় শ্রেণির কৌশল অকেজো। ARM-এ সমতুল্য PXN আর PAN.
• Signed module আর lockdown: শুধু স্বাক্ষরিত kernel module লোড — পর্ব ০৭-এর Secure Boot-এর শিকলের পরের কড়া।

Meltdown, KPTI আর Spectre — যখন হার্ডওয়্যার নিজেই ফাঁক রাখে

২০১৮ সালের জানুয়ারিতে প্রকাশিত দুটি গবেষণা দেখাল, অংশ ৫-এর হার্ডওয়্যারের দেয়াল নিখুঁত নয়। আধুনিক CPU গতি বাড়াতে ফল জানার আগেই সামনের নির্দেশ অনুমানে চালিয়ে রাখে (speculative execution), অনুমান ভুল হলে ফল ফেলে দেয়। কিন্তু ফেলে দেওয়া কাজের ছাপ cache-এ থেকে যায়, আর সময় মেপে সেই ছাপ পড়া যায় — একে বলে side channel.

• Meltdown: আক্রান্ত প্রসেসরে (প্রধানত তখনকার অনেক Intel মডেল) user mode-এর প্রোগ্রাম অনুমানের ফাঁকে kernel-এর মেমরির ছাপ পেতে পারত, যদিও U/S বিট তা নিষেধ করে। প্রতিকার KPTI (Linux ৪.১৫; Windows-এ KVA Shadow): user mode-এ চলার সময় kernel-এর প্রায় সব মেমরি page table থেকেই সরিয়ে রাখা — যা ম্যাপই নেই, তা অনুমানেও ছোঁয়া যায় না। দাম: প্রতিটি system call আর interrupt-এ page table বদল, তাই syscall-ভারী কাজে লক্ষণীয় ধীরতা (পর্ব ০৯-এ PCID দিয়ে খরচ কমানোর কথা আছে)। নতুন প্রসেসর হার্ডওয়্যারেই এটি সারিয়েছে, সেখানে KPTI লাগে না।
• Spectre: আরও বিস্তৃত পরিবার — Intel, AMD, ARM-এর বহু প্রসেসরে। একটি প্রোগ্রাম নিজের বা অন্যের অনুমানের পথকে প্রভাবিত করে গোপন তথ্যের ছাপ cache-এ ফেলাতে পারে। একক কোনো সমাধান নেই; প্রতিকার স্তরে স্তরে: CPU microcode আপডেট, compiler-এর retpoline আর বিশেষ বাধা-নির্দেশ, kernel-এ সংবেদনশীল সীমা-যাচাইয়ের পরে অনুমান থামানো, ব্রাউজারে সূক্ষ্ম timer সরানো আর প্রতিটি সাইট আলাদা প্রসেসে।

নিজের মেশিনে এগুলো দেখার সবচেয়ে সহজ পথ — Linux kernel নিজেই /sys/devices/system/cpu/vulnerabilities/-এ প্রতিটি পরিচিত CPU-ত্রুটির জন্য “আক্রান্ত নয়”, “প্রতিকার চালু” বা “ঝুঁকিতে” লিখে রাখে। নিচের স্ক্রিপ্ট user-space ASLR আর kernel-এর দিক — দুটিই শুধু পড়ে দেখে:

echo "ASLR: randomize_va_space = $(cat /proc/sys/kernel/randomize_va_space)  (0 off, 1 partial, 2 full)"
for run in 1 2 3; do   # every grep is a NEW process, so /proc/self = that grep
  grep -E '\[(heap|stack)\]' /proc/self/maps |
    awk -v r="$run" '{split($1, a, "-"); printf "run %s  %-8s starts at %s\n", r, $6, a[1]}'
done
echo "--- kernel side (read-only checks, no root) ---"
echo "kptr_restrict = $(cat /proc/sys/kernel/kptr_restrict 2>/dev/null || echo hidden)"
echo "first /proc/kallsyms line for uid $(id -u): $(head -n 1 /proc/kallsyms 2>/dev/null || echo hidden)"
d=/sys/devices/system/cpu/vulnerabilities
for f in meltdown spectre_v1 spectre_v2; do
  printf '%-11s %s\n' "$f:" "$(cat "$d/$f" 2>/dev/null || echo 'not visible here')"
done

ASLR: randomize_va_space = 2  (0 off, 1 partial, 2 full)
run 1  [heap]   starts at 644353d71000
run 1  [stack]  starts at 7ffddc01d000
run 2  [heap]   starts at 6091d860c000
run 2  [stack]  starts at 7ffda49bb000
run 3  [heap]   starts at 603816884000
run 3  [stack]  starts at 7ffc799b7000
--- kernel side (read-only checks, no root) ---
kptr_restrict = 1
first /proc/kallsyms line for uid 999: 0000000000000000 A fixed_percpu_data
meltdown:   Not affected
spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2: Mitigation: Retpolines; IBPB: conditional; STIBP: always-on; RSB filling; PBRSB-eIBRS: Not affected; BHI: Not affected

শিকড় থেকে সমাধান — memory-safe ভাষা

এত স্তরের পরও কেন নতুন দুর্বলতা আসে? কারণ বাগের শ্রেণিটি থেকেই যায়। Microsoft-এর নিরাপত্তা-প্রকৌশলীরা ২০১৯ সালে জানান, বহু বছর ধরে তাঁদের পণ্যে প্রতি বছর যে CVE দেওয়া হয়, তার প্রায় ৭০% memory-safety সমস্যা; Google-এর Chromium দলও ২০২০ সালে গুরুতর নিরাপত্তা-বাগের মোটামুটি একই অনুপাতের কথা বলে। (এগুলো তাঁদের নিজেদের কোডভিত্তির হিসাব, সব সফটওয়্যারের সাধারণ সূত্র নয়।) সমাধানের পথ: নতুন কোড এমন ভাষায় লেখা, যেখানে compiler নিজেই এই ভুলগুলো আটকায় — Rust, Go, Swift, Java, C#. Linux kernel-এ Rust-এ driver লেখার প্রাথমিক সমর্থন ঢোকে ৬.১ সংস্করণে (২০২২-এর ডিসেম্বর), এখনো সীমিত পরিসরে বেড়ে চলেছে; Windows-এর kernel-এ আর Android-এ Rust-এর ব্যবহার বাড়ছে, আর Google জানিয়েছে Android-এ নতুন কোড memory-safe ভাষায় লেখার পর memory-safety দুর্বলতার অনুপাত কয়েক বছরে উল্লেখযোগ্যভাবে কমেছে।

৯ · প্রতিদিনের নিরাপত্তা — patch, log, antivirus/EDR আর বাংলাদেশের প্রেক্ষাপট

Patch আর update — সবচেয়ে কার্যকর একক কাজ

একটি দুর্বলতা প্রকাশিত হলে, আর তার patch আসার পর, সময়টা আক্রমণকারী আর প্রতিরক্ষাকারীর দৌড় — patch নিজেই বলে দেয় কোথায় সমস্যা ছিল। যে দুর্বলতার patch এখনো নেই, তাকে বলে zero-day; কিন্তু বাস্তবের বেশিরভাগ ক্ষতি হয় জানা, patch-থাকা দুর্বলতায়, যা কেউ ইনস্টল করেননি। অভ্যাস: OS-এর স্বয়ংক্রিয় নিরাপত্তা-আপডেট চালু রাখা (Ubuntu-তে unattended-upgrades, Windows Update, macOS Software Update), kernel আপডেটের পর reboot (বা live patching), আর যে OS বা ফোনের নিরাপত্তা-আপডেট বন্ধ হয়ে গেছে, সেটি সংবেদনশীল কাজে ব্যবহার না করা।

Logging আর auditing — কে কখন কী করল

• Linux: systemd-এর journalctl আর /var/log/auth.log (বা secure)-এ লগইন ও sudo-র রেকর্ড; আরও সূক্ষ্ম নজরের জন্য kernel-এর audit subsystem আর তার daemon auditd — নির্দিষ্ট ফাইল বা system call-এ নিয়ম বসিয়ে প্রতিটি ঘটনা লেখা।
• Windows: Event Log-এর Security log-এ সফল লগইন (event ID 4624) আর ব্যর্থ লগইন (4625)-এর মতো ঘটনা; Event Viewer দিয়ে দেখা যায়।
• নিয়ম: log অন্য একটি মেশিনে পাঠানো, যাতে আক্রমণকারী মুছতে না পারে; আর কেউ সত্যিই log দেখেন — সতর্কবার্তা ছাড়া log শুধু ময়নাতদন্তে কাজে লাগে।

# watch writes and attribute changes to /etc/shadow, tag them "shadow-watch"
$ sudo auditctl -w /etc/shadow -p wa -k shadow-watch
$ sudo passwd rahima            # a legitimate change, just to create an event
$ sudo ausearch -k shadow-watch -i | tail -n 3
type=SYSCALL ... syscall=openat success=yes ... comm=passwd exe=/usr/bin/passwd auid=karim uid=root ...
type=PATH ... name=/etc/shadow ...
# auid = the person who originally logged in (karim), even after sudo

Antivirus আর EDR

প্রথাগত antivirus পরিচিত malware-এর “চিহ্ন” (signature) মিলিয়ে ধরে — জানা হুমকিতে ভালো, নতুনটিতে দুর্বল। আধুনিক EDR (endpoint detection and response) প্রসেসের আচরণ দেখে: Word থেকে হঠাৎ একটি shell চালু হওয়া, কয়েক মিনিটে হাজারো ফাইল এনক্রিপ্ট হওয়া — আর প্রতিষ্ঠানের নিরাপত্তা-দলকে জানায় বা মেশিনটি network থেকে আলাদা করে। Windows-এ Microsoft Defender ডিফল্টভাবেই থাকে। মনে রাখুন, এরা শেষ স্তর — patch, least privilege আর backup-এর বিকল্প নয়।

বাংলাদেশের প্রেক্ষাপট — মোবাইল ব্যাংকিং আর OTP

বাংলাদেশে বিপুল মানুষ bKash, Nagad, Rocket-এর মতো মোবাইল আর্থিক সেবা আর ব্যাংকের অ্যাপ ব্যবহার করেন। এই পর্বের নীতিগুলো সেখানে সরাসরি খাটে:

• PIN আর OTP কাউকে বলবেন না — সেবাদাতা প্রতিষ্ঠানগুলো সাধারণত স্পষ্ট জানায় যে তাদের কর্মীরা কখনো PIN বা OTP চায় না। “ভুল করে টাকা চলে গেছে, কোডটি বলুন” — এটি social engineering-এর পরিচিত রূপ।
• OTP-এর SMS-এ লেখা কাজটি (কোন লেনদেন, কত টাকা) মিলিয়ে নিন; আপনি নিজে শুরু না করা লেনদেনের OTP এলে সেটি সতর্কসংকেত।
• অ্যাপ শুধু Play Store বা App Store-এর অফিসিয়াল পাতা থেকে; লিংক বা APK ফাইল থেকে নয় (Trojan-এর প্রধান পথ)।
• ফোনের OS আর অ্যাপ হালনাগাদ রাখুন, স্ক্রিন-লক চালু রাখুন, আর অন্য কাউকে ফোনে “রিমোট সাহায্য”-র অ্যাপ বসাতে দেবেন না।
• সন্দেহ হলে কল কেটে দিয়ে নিজে সেবাদাতার অফিসিয়াল হেল্পলাইনে (অ্যাপ বা ওয়েবসাইটে দেওয়া নম্বরে) যোগাযোগ করুন; প্রতিষ্ঠানের ক্ষেত্রে দেশের সরকারি সাইবার ইনসিডেন্ট রেসপন্স দলকেও (যেমন BGD e-GOV CIRT) জানানো যায়।

১০ · AI-এর যুগে OS নিরাপত্তা — সাহায্য নিন, অন্ধভাবে নয়

নিরাপত্তার প্রশ্নে AI-এর ভুল উত্তর সরাসরি দুর্বলতা তৈরি করে। বারবার দেখা ভুলগুলো:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• কোনো ধাপ কি সুরক্ষা বন্ধ করছে (chmod 777, mitigations=off, setenforce 0, -z execstack)? করলে থেমে কারণ খুঁজেছি
• কমান্ডটি আমার OS, distro আর version-এর জন্য কি না — man page বা অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি
• পরিবর্তনের আগে-পরে নিজে যাচাই করেছি (readelf, /proc, /sys/.../vulnerabilities, log)
• PAM বা SSH বদলানোর সময় একটি আলাদা সেশন খোলা রেখে, আগে একটি পরীক্ষামূলক VM-এ চালিয়ে দেখেছি
• পাসওয়ার্ড-সংক্রান্ত কোড salt-সহ ধীর hash ব্যবহার করে, আর তুলনা constant-time — নিজে কোড পড়ে নিশ্চিত হয়েছি
• সংখ্যাগত দাবি (কত বিট, কত বছর) হাতে বা এই পর্বের calculator-এ আবার হিসাব করেছি