Linux hardening — CIS Benchmark, auditd, SELinux আর AppArmor

১ · Hardening কী — নিজের বাড়ির বাড়তি দরজা বন্ধ করা

একটি পুরোনো বাড়ি ভাবুন। ছয়টি দরজা, তার তিনটি কেউ ব্যবহার করে না। পেছনের গেটের চাবি কার কাছে, কেউ জানে না। দারোয়ান আছেন, কিন্তু রেজিস্টার খাতা নেই। চোর এলে কোন দরজা দিয়ে এল, পরে কেউ বলতে পারবে না।

নতুন একটি Linux server অনেকটা এমন। সাধারণ install সবার কাজে লাগার জন্য বানানো হয়, আপনার একটি নির্দিষ্ট কাজের জন্য নয়। তাই অনেক প্যাকেজ, চালু service আর উদার নিয়ম থাকতে পারে। Hardening মানে সেই সাধারণ অবস্থাকে আপনার server-এর কাজের মাপে ছেঁটে আনা। লক্ষ্য তিনটি: attack surface ছোট করা (পর্ব ৪), কিছু ভাঙলে ক্ষতি সীমিত রাখা, আর ঘটনা ঘটলে তা দেখতে পাওয়া।

এখানে সততাও দরকার। Hardening আপনার app-এর logic-এর বাগ সারায় না। চুরি হওয়া বৈধ admin credential-ও পুরোপুরি থামায় না। এটি হামলাকে কঠিন, ধীর আর দৃশ্যমান করে। তাই এটি defense in depth-এর একটি অংশ (পর্ব ৩), পুরো উত্তর নয়। নিচের ছবিতে স্তরগুলো দেখুন। এই পর্ব মোটামুটি এই ক্রমেই এগোবে।

২ · CIS Benchmark আর STIG — রেসিপি, আইন নয়

ভালো রান্নার বইয়ে বলা থাকে কতটা লবণ দিতে হবে। কিন্তু অতিথি ডায়াবেটিসের রোগী হলে রান্না বদলাতে হয়। CIS Benchmark আর STIG এমন রেসিপি। হাজারো অভিজ্ঞতা থেকে লেখা নির্দিষ্ট সেটিং, প্রতিটির কারণ, যাচাইয়ের উপায় আর সমাধানসহ।

Level 1 মানে এমন সেটিং, যা স্পষ্ট লাভ দেয় আর সেবায় সাধারণত বড় বাধা তৈরি করে না। Level 2 বাড়তি গভীর প্রতিরক্ষা, যেখানে নিরাপত্তা সুবিধার চেয়ে আগে আসে। এতে কিছু কাজ ভাঙতে পারে। Server আর workstation-এর profile-ও আলাদা হয়, আর প্রতিটি distribution-এর আলাদা Benchmark আছে। তাই সবসময় নিজের OS version-এর দলিল পড়ুন।

কেন চোখ বুজে চাপাবেন না

• Role আলাদা: অনেক নিয়ম বলে ip_forward বন্ধ রাখুন। কিন্তু container চালানো host বা router-এ এটি সাধারণত দরকার। অন্ধভাবে বন্ধ করলে container-এর network ভাঙবে।
• Mount-এর সীমা: /tmp-তে noexec ভালো নিয়ম। কিন্তু কিছু installer সেখানে script চালায় বলে ব্যর্থ হতে পারে।
• নিজেকে আটকে ফেলা: SSH-এর নিয়ম বদলে সবার প্রবেশ বন্ধ করা সবচেয়ে পরিচিত দুর্ঘটনা।
• Score মানে নিরাপত্তা নয়: ১০০% score মানে তালিকা মিলেছে। App-এর বাগ বা দুর্বল password process তালিকায় ধরা না-ও পড়তে পারে।

না মানা কোনো নিয়ম চুপচাপ বাদ দেবেন না। ব্যতিক্রম লিখুন: কোন নিয়ম, কেন, কে অনুমোদন করলেন, বিকল্প কী (compensating control), আর কবে আবার দেখা হবে। এটি risk acceptance-এর লিখিত রূপ। নিচের toy scorer এই ধারণা দেখায়। এটি কোনো আসল Benchmark নয়, শুধু একটি in-memory object পরীক্ষা করে।

// Toy CIS-style audit of an in-memory config object. Not a real Benchmark.
const host = { sshRoot: "no", sshPassword: "yes", ipForward: 1, syncookies: 1,
  auditd: true, worldWritable: 2, mac: "permissive", autoUpdates: true };

const checks = [
  { id: "1.1", lvl: 1, w: 3, name: "root SSH login off",  ok: h => h.sshRoot === "no" },
  { id: "1.2", lvl: 1, w: 3, name: "SSH password off",    ok: h => h.sshPassword === "no" },
  { id: "2.1", lvl: 1, w: 2, name: "IP forwarding off",   ok: h => h.ipForward === 0 },
  { id: "2.2", lvl: 1, w: 1, name: "TCP syncookies on",   ok: h => h.syncookies === 1 },
  { id: "3.1", lvl: 1, w: 2, name: "auditd running",      ok: h => h.auditd },
  { id: "3.2", lvl: 1, w: 2, name: "no world-writable",   ok: h => h.worldWritable === 0 },
  { id: "4.1", lvl: 2, w: 3, name: "MAC enforcing",       ok: h => h.mac === "enforcing" },
  { id: "5.1", lvl: 1, w: 2, name: "security updates on", ok: h => h.autoUpdates },
];
// Written exception: this host runs containers. Owner and review date are recorded.
const exceptions = { "2.1": "container host, ticket SEC-118, review 2027-01" };

function audit(maxLevel) {
  let got = 0, total = 0;
  for (const c of checks) {
    if (c.lvl > maxLevel) continue;
    if (exceptions[c.id]) { console.log(`SKIP ${c.id} ${c.name}: ${exceptions[c.id]}`); continue; }
    const pass = c.ok(host);
    total += c.w;
    if (pass) got += c.w;
    else console.log(`FAIL ${c.id} ${c.name} (weight ${c.w})`);
  }
  console.log(`Level ${maxLevel}: ${got}/${total} = ${(100 * got / total).toFixed(1)}%\n`);
}
audit(1);
audit(2);

আসল কাজে নিজের system যাচাইয়ের টুল আছে। যেমন SCAP-ভিত্তিক OpenSCAP, CIS-CAT বা Lynis. এগুলো উদাহরণ মাত্র, সুপারিশ নয়। আগে report mode-এ চালান, automatic সংশোধন নয়। Standard-এর বড় ছবি আসবে পর্ব ৬৯-এ।

৩ · ভিত্তি — কম software, patch, account আর SSH

সবচেয়ে সস্তা নিরাপত্তা হলো যে জিনিস নেই, তার বাগও নেই। তাই শুরু করুন minimal install দিয়ে। তারপর দেখুন কী চলছে আর কোন port শুনছে।

systemctl list-units --type=service --state=running
sudo ss -tulpn                         # কোন process কোন port শুনছে
sudo systemctl disable --now cups      # যদি printing না লাগে
sudo systemctl mask cups               # ভুলে আবার চালু হওয়া ঠেকায়

প্রতিটি লাইনের জন্য একটি প্রশ্ন করুন: এটি কার দরকার? উত্তর না পেলে আগে খোঁজ নিন, তারপর test machine-এ বন্ধ করে দেখুন। কোনো service 127.0.0.1-তে শুনলে বাইরে থেকে সরাসরি পৌঁছানো যায় না, কিন্তু 0.0.0.0 মানে সব interface.

Patch আর স্বয়ংক্রিয় নিরাপত্তা update

জানা ত্রুটির patch আসার পরও বসাতে দেরি হওয়া বহু breach-এর কারণ। ছোট server-এ স্বয়ংক্রিয় নিরাপত্তা update চালু রাখা সাধারণত ভালো। অগ্রাধিকার ঠিক করার পদ্ধতি আসবে পর্ব ৩২-এ।

# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

# /etc/dnf/automatic.conf
[commands]
upgrade_type = security
apply_updates = yes

User, sudo, password-এর বয়স আর pam_faillock

• প্রতিটি মানুষের নিজের account: ভাগের account থাকলে log বলতে পারে না কে কাজটি করলেন। পুরোনো account বন্ধ করুন: sudo usermod -L -e 1 oldstaff.
• Sudo ছোট রাখুন: ALL-এর বদলে নির্দিষ্ট command দিন, আর visudo দিয়ে sudoers বদলান। Editor বা shell-এর মতো প্রোগ্রাম root হিসেবে দেওয়া কার্যত পুরো root দেওয়া, তাই ফাইল সম্পাদনায় sudoedit ভালো। বিস্তারিত পর্ব ২০-এ।
• Password-এর বয়স: chage দিয়ে নীতি দেখা ও ঠিক করা যায়। কিন্তু NIST SP 800-63B-4 নিয়মিত জোর করে password বদলানোর বিপক্ষে, শুধু ফাঁসের প্রমাণে বদলের পক্ষে (পর্ব ১৫). কিছু benchmark-এ তবু বয়সের সীমা থাকে। প্রশ্ন ০৫-এ এই দ্বন্দ্ব দেখব। অস্থায়ী account-এ শেষ তারিখ বসানো কিন্তু খুব কাজের: sudo chage -E 2026-12-31 vendor1.
• pam_faillock: Linux PAM-এর এই module বারবার ভুল password-এ account সাময়িক আটকায়।

# /etc/security/faillock.conf
# পরপর ৫ বার ভুলে আটকাবে
deny = 5
# এই ৯০০ সেকেন্ডের ভেতরের ভুল গোনা হবে
fail_interval = 900
# ৯০০ সেকেন্ড পরে নিজে খুলবে
unlock_time = 900
# অজানা username-ও log করবে
audit

Module-এর ডিফল্ট deny=3, fail_interval=900 আর unlock_time=600. শুধু config লিখলেই হয় না, PAM stack-এ module যুক্তও থাকতে হয়। RHEL-ধরনের system-এ এটি সাধারণত authselect দিয়ে হয়, অন্যগুলোতে নিয়ম আলাদা। কার account আটকেছে তা দেখতে sudo faillock --user rina, আর খুলতে --reset. দুটি সীমা মনে রাখুন। এই আটকানোর সুযোগ নিয়ে কেউ ইচ্ছা করে বৈধ ব্যবহারকারীকে আটকে দিতে পারে। আর SSH key দিয়ে login-এ password যাচাই হয় না, তাই সেখানে এই গণনাও চলে না।

SSH — এক নজরে

SSH-এর পুরো গল্প আছে Cloud ও DevOps কোর্সের SSH পর্বে. এখানে শুধু স্মরণ করিয়ে দিই। Password-এর বদলে SSH key, root-এর সরাসরি login বন্ধ, আর শুধু নির্দিষ্ট group-কে প্রবেশ।

# /etc/ssh/sshd_config.d/00-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups sshusers
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

sshd_config-এ একই নিয়ম বারবার থাকলে প্রথম পাওয়া মানটি জেতে। তাই drop-in ফাইলের নাম 00- দিয়ে শুরু করা হলো, যাতে পরের কোনো ফাইল তাকে না বদলায়। প্রয়োগের আগে sudo sshd -t দিয়ে syntax যাচাই করুন, আর sudo sshd -T দিয়ে শেষ পর্যন্ত কোন মান কার্যকর হচ্ছে দেখুন।

৪ · ফাইল আর kernel — অনুমতি, umask, sysctl, boot

অনুমতির ভিত্তি পড়েছেন OS কোর্সের Linux permission পর্বে. Hardening-এ প্রশ্নটি আলাদা: আমার system-এ যা আছে, তা কি যা থাকার কথা তার সাথে মেলে? অফিসের স্টক মেলানোর মতো, খাতার সাথে তাকের জিনিস মিলিয়ে দেখা। নিচের block নিজের একটি ছোট folder বানিয়ে শুধু সেটিই পরীক্ষা করে।

# Toy audit: builds its own small tree and checks only that tree.
T=$(mktemp -d); cd "$T" || exit 1
mkdir -p app/conf app/public app/logs
echo "port=8080"             > app/conf/app.conf
echo "db_pass=example-token" > app/conf/secret.env
echo "hello"                 > app/public/index.html
echo "started"               > app/logs/app.log
echo "echo run"              > app/run.sh
chmod 755 app app/conf app/public; chmod 777 app/logs
chmod 644 app/conf/app.conf app/public/index.html
chmod 666 app/conf/secret.env; chmod 640 app/logs/app.log; chmod 4755 app/run.sh

echo "== world-writable =="
find app -perm -0002 | sort
echo "== SUID or SGID files =="
find app -type f -perm /6000 | sort
echo "== expected vs actual =="
cat > expected.txt <<'EOF'
640 app/conf/app.conf
600 app/conf/secret.env
644 app/public/index.html
640 app/logs/app.log
755 app/run.sh
EOF
while read -r want path; do
  got=$(stat -c '%a' "$path")
  if [ "$got" = "$want" ]; then echo "ok   $path $got"
  else echo "FIX  $path has $got, want $want"; fi
done < expected.txt
cd /; rm -rf "$T"

SUID আর SGID — নিজের system-এর হিসাব

SUID bit থাকলে প্রোগ্রাম ফাইলের মালিকের অধিকার নিয়ে চলে। যেমন passwd-এর এটি দরকার। কিন্তু root-এর SUID প্রোগ্রামের প্রতিটি বাগ বড় ঝুঁকি। তাই এদের সংখ্যা কম রাখা, আর হঠাৎ নতুন একটি এলে জানতে পারাই লক্ষ্য। এটি অডিট, কোনো হামলার কৌশল নয়। অনুমোদিত তালিকার সাথে আজকের অবস্থা মেলান:

# নিজের server-এ, আগে সংরক্ষিত অনুমোদিত তালিকার সাথে তুলনা
sudo find / -xdev -type f -perm /6000 -printf '%m %u %p\n' | sort -k3 > suid-today.txt
diff suid-approved.txt suid-today.txt

নতুন লাইন এলে দেখুন সেটি কোন package-এর, আর package manager-এর হিসাবের সাথে মেলে কি না (rpm -V বা dpkg --verify). /tmp-এর মতো user-লেখা জায়গায় nosuid আর nodev mount option বাড়তি বেড়া।

umask — নতুন ফাইলের ডিফল্ট

umask বলে দেয় নতুন ফাইল থেকে কোন অনুমতি বাদ যাবে। ফাইল শুরু হয় ৬৬৬ থেকে, folder ৭৭৭ থেকে। হিসাবটি বিয়োগ নয়, bit মোছা: অনুমতি = ভিত্তি AND (NOT umask).

শেষ সারি পরীক্ষার প্রিয় ফাঁদ। ৬ মানে 110, ৩ মানে 011. 011-এর NOT হলো 100. 110 AND 100 = 100, অর্থাৎ ৪। তাই ফল ৬৪৪।

sysctl — চলন্ত kernel-এর সুইচ

sysctl দিয়ে kernel-এর আচরণ বদলানো যায়। ফাইলে লিখলে reboot-এর পরেও থাকে।

# /etc/sysctl.d/60-hardening.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.ip_forward = 0
kernel.randomize_va_space = 2
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.yama.ptrace_scope = 1
fs.suid_dumpable = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

নতুন interface-এর জন্য .default. রূপও সেট করতে হতে পারে। প্রয়োগ করুন sudo sysctl --system দিয়ে, আর যাচাই করুন sysctl net.ipv4.tcp_syncookies দিয়ে।

Kernel, boot আর host firewall

• Secure Boot: Firmware শুধু স্বাক্ষর মেলা bootloader আর kernel চালায়। শিকলটি পাবেন OS কোর্সের boot পর্বে.
• Kernel lockdown: Root-কেও চলন্ত kernel বদলানোর কিছু পথ থেকে সরিয়ে রাখে।
• Kernel module-এর সীমা: অপ্রয়োজনীয় module, যেমন ব্যবহার না হওয়া filesystem বা USB storage, load হওয়া ঠেকানো যায়। Signed module বাধ্যতামূলক করা আরও শক্ত বেড়া।
• Bootloader আর disk: Bootloader password শারীরিক প্রবেশের ঝুঁকি কমায়। ল্যাপটপে disk encryption অপরিহার্য (পর্ব ২৯).
• Exploit-প্রতিরোধ: ASLR, KASLR আর অন্যান্য ব্যবস্থা আছে OS নিরাপত্তা পর্বে.
• Host firewall: Default deny inbound রাখুন, শুধু দরকারি port খুলুন। নিয়ম আর উদাহরণ আছে পর্ব ২২-এ। Cloud-এ security group এর বিকল্প নয়, আরেকটি স্তর।

৫ · auditd — অফিসের রেজিস্টার খাতা

সাধারণ log app যা লিখতে চায় তা-ই লেখে। auditd আলাদা। Kernel নিজে নিয়ম মিলিয়ে ঘটনা ধরে, আর auditd daemon সেটি /var/log/audit/audit.log-এ লেখে। নিয়ম দুই ধরনের: নির্দিষ্ট ফাইলে নজর (-w), আর system call-এর নিয়ম (-a).

# /etc/audit/rules.d/50-hardening.rules
-D
-b 8192
-f 1

# পরিচয় আর অধিকারের ফাইল: write বা attribute বদল (wa)
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudo_scope
-w /etc/sudoers.d/ -p wa -k sudo_scope
-w /etc/ssh/sshd_config -p wa -k sshd_config

# সাধারণ user login করে root হিসেবে যে প্রোগ্রাম চালালেন
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root_cmd

# অনুমতি বদল
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k perm_mod

# সবার শেষে: reboot ছাড়া নিয়ম বদলানো যাবে না
-e 2

লোড করুন sudo augenrules --load দিয়ে, দেখুন sudo auditctl -l দিয়ে। -k হলো খোঁজার চাবি। -e 2 নিয়মকে অপরিবর্তনীয় করে, তাই হামলাকারী root পেলেও সহজে নিয়ম মুছতে পারে না। কিন্তু আপনিও পারবেন না, তাই নিয়ম পাকা হওয়ার পরই এটি বসান। execve-এর নিয়মে log অনেক বাড়তে পারে, disk আর backlog মেপে নিন।

sudo ausearch -k sshd_config -i --start today
sudo aureport --summary

নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে, কিছু ঘর সংক্ষেপ করা হয়েছে:

type=PATH msg=audit(10/31/2026 03:14:07.218:4521) : item=1
  name=/etc/ssh/sshd_config mode=file,644 ouid=root
type=SYSCALL msg=audit(10/31/2026 03:14:07.218:4521) : syscall=openat
  success=yes ppid=2210 pid=2233 auid=rina uid=root euid=root
  tty=pts1 ses=14 comm=vi exe=/usr/bin/vi key=sshd_config

এখানে সবচেয়ে দামি ঘর auid. uid=root বলে কোন অধিকারে কাজটি হলো। auid=rina বলে কে প্রথমে login করেছিলেন। sudo করলেও auid বদলায় না। অর্থাৎ root-এর ভিড়েও মানুষটিকে চেনা যায়। একই ঘটনার সব লাইন একই serial নম্বর (4521) দিয়ে জোড়া।

Audit log ছাড়াও প্রতিদিনের log পড়তে পারা দরকার। নিচে একটি নির্দিষ্ট sample auth log আছে, যা block নিজেই বানায়। ঠিকানাগুলো documentation range-এর। ধরে নিন নীতি হলো শুধু SSH key.

# Reads only the fixed sample below. Addresses are documentation addresses.
T=$(mktemp -d); cd "$T" || exit 1
cat > auth.log <<'EOF'
Oct 31 02:11:04 web1 sshd[811]: Failed password for root from 203.0.113.7 port 50122 ssh2
Oct 31 02:11:06 web1 sshd[811]: Failed password for root from 203.0.113.7 port 50122 ssh2
Oct 31 02:11:09 web1 sshd[812]: Failed password for invalid user admin from 203.0.113.7 port 50130 ssh2
Oct 31 02:11:12 web1 sshd[812]: Failed password for invalid user test from 203.0.113.7 port 50130 ssh2
Oct 31 02:40:31 web1 sshd[815]: Failed password for rina from 198.51.100.24 port 50988 ssh2
Oct 31 02:40:52 web1 sshd[815]: Accepted password for rina from 198.51.100.24 port 50988 ssh2
Oct 31 03:02:10 web1 sshd[820]: Accepted publickey for karim from 198.51.100.9 port 51002 ssh2
Oct 31 03:02:55 web1 sudo: karim : TTY=pts/0 ; PWD=/home/karim ; USER=root ; COMMAND=/usr/bin/systemctl restart bazar-api
Oct 31 03:09:40 web1 sudo: rina : command not allowed ; TTY=pts/1 ; PWD=/home/rina ; USER=root ; COMMAND=/usr/sbin/visudo
EOF
echo "== failed logins by source =="
awk '/Failed password/ { for (i = 1; i <= NF; i++) if ($i == "from") n[$(i + 1)]++ }
     END { for (ip in n) print n[ip], ip }' auth.log | sort -rn
echo "== accepted logins =="
awk '/Accepted/ { tag = ($7 == "password") ? "  <-- breaks key-only policy" : ""
                  print $7, $9, $11 tag }' auth.log
echo "== sudo refused =="
awk '/sudo:.*command not allowed/ { print $3, $6, $NF }' auth.log
cd /; rm -rf "$T"

৬ · File integrity monitoring — আলমারির সিলগালা

ব্যাংকের লকার সিল করে রাখলে কেউ খুললে সিল ভাঙে। File integrity monitoring (FIM) ফাইলের ক্ষেত্রে একই কাজ করে। ভালো অবস্থায় প্রতিটি ফাইলের hash, অনুমতি আর মালিকের একটি baseline রাখে, পরে আবার হিসাব করে মিলিয়ে দেখে। Hash-এর ধারণা আছে পর্ব ৯-এ। এটি বদল থামায় না, শুধু বদল জানায়। নিচের block নিজের বানানো ফাইলেই এই কাজটি দেখায়।

# Toy integrity check: hashes only files this block creates.
T=$(mktemp -d); cd "$T" || exit 1
mkdir site
echo "listen 8080" > site/app.conf
echo "user=bazar"  > site/users.conf
echo "echo start"  > site/start.sh
sha256sum site/* > baseline.txt
echo "baseline: $(wc -l < baseline.txt) files"

# Later: one file changes, one disappears, one appears.
echo "listen 9999" > site/app.conf
rm site/users.conf
echo "echo extra"  > site/new.sh

sha256sum site/* > today.txt
awk 'NR == FNR { old[$2] = $1; next }
     { seen[$2] = 1
       if (!($2 in old)) print "NEW     " $2
       else if (old[$2] != $1)
         print "CHANGED " $2, substr(old[$2], 1, 10), "->", substr($1, 1, 10) }
     END { for (f in old) if (!(f in seen)) print "MISSING " f }' \
    baseline.txt today.txt | sort
echo "== sha256sum -c =="
sha256sum -c baseline.txt 2>/dev/null || echo "check failed: review needed"
cd /; rm -rf "$T"

আসল কাজে AIDE-এর মতো টুল এটিই বড় পরিসরে করে। Tripwire, Samhain বা অনেক HIDS-ও এই সুবিধা দেয়; এগুলো উদাহরণ মাত্র। AIDE-এ সাধারণ প্রবাহ হলো aide --init দিয়ে database বানানো, ভালো অবস্থার ফাইলটিকে সক্রিয় নামে আনা, আর aide --check নিয়মিত চালানো। Path আর wrapper distribution-ভেদে আলাদা।

একটি alert এলে কী করবেন? আগে baseline আপডেট করবেন না। নিচে ধাপে ধাপে দেখুন। সব মান নমুনা।

$ sudo aide --check
Changed entries:
f   ...    : /etc/ssh/sshd_config
 SHA512 : pV3k... | Zq9d...

$ sudo ausearch -f /etc/ssh/sshd_config -i
time: 10/31/2026 03:14:07
auid=rina uid=root comm=vi
change ticket: পাওয়া যায়নি

$ diff approved/sshd_config /etc/ssh/sshd_config
< PasswordAuthentication no
> PasswordAuthentication yes

রিনার ফোনে যাচাই: vendor-এর জন্য নিজে বদলেছেন
একই সময়ের login: শুধু পরিচিত ঠিকানা
রায়: নীতিভঙ্গ, হামলার প্রমাণ নেই

$ sudo sshd -t
$ sudo systemctl reload sshd
$ sudo sshd -T | grep -i passwordauthentication
passwordauthentication no

aide --check: কোনো বদল নেই
ticket: কারণ, প্রমাণ, সমাধান লেখা হলো
নতুন নিয়ম: vendor-এর প্রবেশ jump host দিয়ে

৭ · SELinux আর AppArmor — denial পড়ুন, বন্ধ করবেন না

ফাইলের সাধারণ অনুমতি হলো DAC: মালিক ঠিক করেন কে পাবে। সমস্যা হলো, root বা মালিকের অধিকারে চলা একটি আক্রান্ত প্রোগ্রাম সেই অধিকারের সব কিছু ছুঁতে পারে। MAC-এ কেন্দ্রীয় নীতি ঠিক করে দেয় কোন প্রোগ্রাম কোন ধরনের জিনিস ছুঁতে পারবে, মালিক বা root হলেও। ব্যাংকের কর্মীর হাতে চাবি থাকলেও ভল্টে ঢুকতে আলাদা নিয়ম মানতে হয়, এমন। তত্ত্বের গভীর অংশ আছে OS কোর্সের sandbox পর্বে. এখানে আমরা প্রয়োগে থাকব।

দুটিই kernel-এর LSM কাঠামোর ওপর বসে। Permissive বা complain mode একটি ডায়াগনস্টিক অবস্থা। এতে নীতি শেখা যায়, কিন্তু কিছু আটকায় না। সবচেয়ে বড় ভুল হলো সেটিকেই স্থায়ী করে ফেলা।

একটি AVC denial পড়তে পারা এই পর্বের সবচেয়ে কাজের দক্ষতাগুলোর একটি। ধরুন সাইটের ফাইল home folder থেকে mv করে /srv/web-এ আনা হলো। এখন nginx 403 দিচ্ছে। RHEL-ধরনের system-এ ধাপগুলো দেখুন।

$ curl -I http://127.0.0.1/
HTTP/1.1 403 Forbidden
$ ls -l /srv/web/index.html
-rw-r--r--. 1 nginx nginx 512 ... index.html

$ getenforce
Enforcing
# ইন্টারনেটের পরামর্শ:
setenforce 0   # পুরো মেশিনের পাহারা বন্ধ

$ sudo ausearch -m AVC -ts recent
avc: denied { read } for
  comm="nginx" name="index.html"
  scontext=system_u:system_r:httpd_t:s0
  tcontext=unconfined_u:object_r:user_home_t:s0
  tclass=file permissive=0

$ ls -Z /srv/web/index.html
unconfined_u:object_r:user_home_t:s0 index.html
# mv পুরোনো label সাথে আনে

$ sudo semanage fcontext -a \
    -t httpd_sys_content_t "/srv/web(/.*)?"
$ sudo restorecon -Rv /srv/web
Relabeled index.html from
  user_home_t to httpd_sys_content_t

$ curl -I http://127.0.0.1/
HTTP/1.1 200 OK
$ getenforce
Enforcing
$ sudo ausearch -m AVC -ts recent
<no matches>

ঠিক সমাধান বেছে নেওয়ার ছোট নিয়ম: ফাইলের label ভুল হলে semanage fcontext আর restorecon. নীতিতে একটি বৈধ সুবিধা বন্ধ থাকলে SELinux boolean, যেমন setsebool -P httpd_can_network_connect on. App নতুন port-এ শুনলে semanage port. কেবল এগুলোয় না মিটলে পর্যালোচনা করে ছোট একটি custom policy. আর কিছু denial dontaudit নিয়মে লুকানো থাকতে পারে, তাই log না পেলেই “SELinux নয়” বলা যায় না।

AppArmor-এ denial দেখতে এমন। এটি একটি কাল্পনিক bazar-api profile-এর নমুনা, version-ভেদে আলাদা হতে পারে।

audit: type=1400 apparmor="DENIED" operation="open"
  profile="bazar-api" name="/var/lib/bazar/uploads/a.png"
  comm="api" requested_mask="c" denied_mask="c" fsuid=998

একইভাবে পড়ুন: bazar-api profile-এ /var/lib/bazar/uploads/-তে ফাইল তৈরি (c) নিষেধ। সমাধান profile-এ ওই folder-টুকুর জন্য নির্দিষ্ট নিয়ম। পুরো /var/** নয়। পরে sudo apparmor_parser -r দিয়ে profile আবার লোড করুন। পরিবর্তন শেখার সময় একটি profile complain-এ রাখা যায়, পুরো AppArmor বন্ধ করে নয়। aa-logprof প্রস্তাব দিতে পারে, কিন্তু প্রতিটি প্রস্তাব নিজে পড়ুন।

৮ · systemd sandbox — একটি service-কে ছোট ঘরে রাখা

MAC-এর নীতি লেখা না থাকলেও আপনার নিজের service-কে সহজে ঘেরা যায়। systemd sandboxing-এ unit ফাইলে কয়েকটি লাইন লিখলেই kernel-এর namespace, capability আর অন্যান্য ব্যবস্থা কাজে লাগে। ভাড়াটিয়াকে পুরো বাড়ির চাবি না দিয়ে শুধু তাঁর ঘরের চাবি দেওয়ার মতো।

# sudo systemctl edit bazar-api.service
[Service]
User=bazar
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/bazar/uploads
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
CapabilityBoundingSet=

এক লাফে সব লিখবেন না। প্রতিটি ধাপে সেবা পরীক্ষা করুন। systemd-analyze security একটি exposure score দেয়, ১০ মানে সবচেয়ে উন্মুক্ত। এটি একটি কমপাস, প্রমাণ নয়। নিচের সব মান নমুনা।

1[Service]2User=bazar3ExecStart=/opt/bazar/api4NoNewPrivileges=yes5PrivateTmp=yes6ProtectHome=yes7ProtectSystem=strict8ReadWritePaths=/var/lib/bazar/uploads9ProtectKernelTunables=yes10ProtectKernelModules=yes11RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX12CapabilityBoundingSet=

প্রতিবার ফাইল বদলের পরে sudo systemctl daemon-reload আর service restart লাগে। systemctl edit এই reload নিজেই করে, তবু restart আপনাকে করতে হবে। Directive-এর সমর্থন systemd version-এর ওপর নির্ভর করে।

৯ · Central log, automation আর সেবা ভাঙেনি তার প্রমাণ

Log server-এর বাইরে পাঠান। Root পাওয়া হামলাকারী স্থানীয় log মুছতে পারে। তাই ঘটনা ঘটার প্রায় সাথে সাথে log অন্য একটি মেশিনে যাওয়া দরকার, যেখানে এই server-এর মুছে ফেলার অধিকার নেই। Syslog-ভিত্তিক agent সাধারণত TLS দিয়ে পাঠায় (RFC 5425, port 6514). সব মেশিনের ঘড়ি NTP দিয়ে মেলানো চাই, নইলে timeline জোড়া যায় না। পদ্ধতি আছে centralized logging পর্বে; কী রাখবেন আর কতদিন, তা আসবে পর্ব ৫৫-তে। আর পাঠানো থেমে গেলে যেন alert আসে, কারণ নীরবতাও একটি সংকেত।

হাতের কাজ automation-এ তুলুন। একশো server-এ হাতে hardening করলে প্রতিটি একটু আলাদা হবে, আর সময়ের সাথে আলাদাই হতে থাকবে। একে বলে configuration drift. Configuration management টুলে (যেমন Ansible) নিয়মগুলো কোড হিসেবে থাকে। এতে পর্যালোচনা, ইতিহাস আর একই ফলাফল মেলে। আর এই কোড idempotent হলে বারবার চালানো নিরাপদ।

ansible-playbook hardening.yml --limit test --check --diff

প্রথমে test group-এ --check --diff দিয়ে দেখুন কী বদলাবে। তারপর ছোট দলে ছড়ান। আলাদাভাবে একটি পরিষ্কার Linux image শক্ত করে তা থেকে নতুন server বানানোও ভালো পথ।

যাচাই ছাড়া hardening শেষ হয় না। “Command চলেছে” আর “সেবা ঠিক আছে” এক কথা নয়। প্রতিটি পরিবর্তনের জন্য তিন প্রশ্নের উত্তর রাখুন:

• নিরাপত্তা বসেছে? কার্যকর মান দেখুন: sshd -T, sysctl, auditctl -l, getenforce.
• সেবা চলছে? একটি smoke test চালান, শুধু health নয়, আসল কাজও: login, upload, database লেখা, backup, monitoring, নতুন SSH session.
• ফিরতে পারব? আগের config, runbook-এ লেখা ফেরার ধাপ আর console প্রবেশ তৈরি রাখুন। Cloud-এ snapshot, নিজের ঘরে হাতে পৌঁছানোর উপায়।

১০ · AI-এর যুগে hardening — দ্রুত উত্তর, কিন্তু খোলা দরজা

AI খুব দ্রুত config লিখে দেয়, আর denial বুঝতেও সাহায্য করে। কিন্তু সে আপনার server-এর কাজ জানে না। সবচেয়ে বিপজ্জনক অভ্যাস হলো error সরানোর জন্য নিরাপত্তা বন্ধের পরামর্শ।

AI-এর দেওয়া hardening যাচাইয়ের চেকলিস্ট

• প্রতিটি লাইন নিজের OS version-এর man পাতা বা দলিলে মিলিয়েছি
• Test machine-এ চালিয়েছি, production-এ সরাসরি নয়
• কোনো নিরাপত্তা ব্যবস্থা বন্ধ করে সমস্যা ঢাকিনি
• CVE আর নিয়মের নম্বর আসল উৎসে পেয়েছি
• Prompt-এ secret, key বা ব্যক্তিগত তথ্য দিইনি
• কার্যকর মান, সেবা আর ফেরার পথ, তিনটিই যাচাই করেছি