হ্যাক হওয়া VPS হলে কী করবেন

হ্যাক হওয়া VPS পরিষ্কার করবেন না

আপনার VPS হ্যাক হলে সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্তটি কোনো command চালানোর আগেই নিতে হবে। মেশিনটি পরিষ্কার করার চেষ্টা করবেন না। Provider-এর স্তরে এটিকে isolate করুন, evidence হিসেবে disk-এর snapshot নিন, এতে থাকা প্রতিটি credential পরিবর্তন করুন, তারপর আপনার বিশ্বাসযোগ্য source থেকে fresh server-এ rebuild করুন।

Rootkit চলে গেছে—এটি আপনি প্রমাণ করতে পারবেন না, কারণ তা প্রমাণ করার tools-ই attacker নিয়ন্ত্রণ করে।

এটাই মূল যুক্তি। এর পেছনের প্রক্রিয়াটি দেখুন। Root-এ পৌঁছানো attacker ps এমনভাবে বদলে দিতে পারে, যাতে একটি process ID কখনো তার output-এ দেখা না যায়। /etc/ld.so.preload-এর একটি লাইন মেশিনের প্রতিটি dynamically linked program-এ attacker-এর code load করতে পারে। ফলে ls, ss এবং find একই ধারাবাহিকভাবে মিথ্যা তথ্য দেয়। একটি loadable kernel module system call-এর নিচের স্তরেই file লুকিয়ে রাখতে পারে। তাই নতুন করে download করা binary-ও disk-কে পরিষ্কার দেখতে পারে। আপনি miner মুছে দেন, CPU graph কমে যায়, এবং server নীরব হয়ে যায়। কার্যকর backdoor থাকলেও server নীরব দেখাতে পারে।

Rebuild করতে যতটা কঠিন মনে হয়, বাস্তবে তার চেয়ে কম খরচ হয়। একটি সাধারণ VPS-এ কয়েকটি package, একটি config directory এবং একটি data set থাকে। তাই rebuild একটি সীমিত কাজ, যার শেষ আছে। Attacker করা প্রতিটি পরিবর্তন খুঁজে বের করার কাজের কোনো নির্দিষ্ট শেষ নেই। এতে কখনো নিশ্চিত প্রমাণও পাওয়া যায় না।

নিশ্চিত করুন যে সত্যিই compromise হয়েছে

হ্যাক হয়েছে বলে জানানো অনেক সার্ভার আসলে হ্যাক হয়নি। প্রতিদিন হাজার হাজার ব্যর্থ SSH login Internet-এর স্বাভাবিক background noise, কারণ প্রতিটি public IPv4 address নিয়মিত scan করা হয়। lastb output-এ root ও admin ধরনের attempt দেখা গেলে এর অর্থ scanner আপনার port খুঁজে পেয়েছে। এর অর্থ কেউ server-এ প্রবেশ করেছে, তা নয়।

নিচের সংকেতগুলো অবশ্যই গুরুত্বপূর্ণ:

• এমন কোনো সফল login যার ব্যাখ্যা আপনি দিতে পারেন না, যেমন Accepted password for root from 203.0.113.7।
• authorized_keys-এ এমন কোনো key যা আপনি যোগ করেননি।
• আপনার host থেকে server-এর বাইরে network traffic যাওয়ার বিষয়ে provider-এর abuse notice।
• 100% CPU ব্যবহার করা এমন কোনো process, যার নাম kernel thread থেকে নকল করা। Exposed Redis ও Docker socket দিয়ে প্রবেশ করা miner-গুলোকে সাধারণত kdevtmpfsi এবং kinsing-এর মতো নামে দেখা যায়।
• এমন address-এ outbound connection, যেগুলো আপনার কোনো service ব্যবহার করে না।

Kernel thread-এর ছদ্মবেশ শনাক্ত করার একটি দ্রুত পরীক্ষা আছে। প্রকৃত kernel thread-গুলো square bracket-এর মধ্যে নাম দেখায় এবং তাদের পেছনে কোনো executable থাকে না। তাই তাদের ক্ষেত্রে sudo ls -l /proc/<pid>/exe, No such file or directory দিয়ে ব্যর্থ হয়। [kworker/0:2] হিসেবে প্রদর্শিত কোনো process-এর exe link যদি /tmp-এর অধীনে কোনো কিছুর দিকে নির্দেশ করে, তাহলে সেটি kernel name ব্যবহার করা সাধারণ user program।

মনে রাখবেন, এই server আপনাকে ভুল তথ্য দিতে পারে। এই পরীক্ষাগুলো থেকে বোঝা যায় যে কোনো সমস্যা আছে কি না। কিন্তু এগুলো থেকে বোঝা যায় না যে কোনো সমস্যা নেই।

প্রোভাইডারের দিক থেকে নেটওয়ার্ক বিচ্ছিন্ন করুন, সার্ভারের ভেতর থেকে নয়

বিচ্ছিন্নকরণই প্রথম কাজ। কারণ অন্য কেউ এখনও shell ধরে রাখলে এর পরের প্রতিটি পদক্ষেপই বৃথা। কোনো সক্রিয় আক্রমণকারী লগ দেখছে এমন অবস্থায় লগ পড়া, key পরিবর্তন করা এবং data পুনরুদ্ধার করা অর্থহীন।

এটি আপনার provider control panel-এ করুন, অর্থাৎ operating system-এর বাইরে চলা network firewall-এ। Inbound এবং outbound উভয় traffic deny করুন। প্রবেশের পথ হিসেবে web console চালু রাখুন। সেখানে প্রয়োগ করা rule disk-এ যা-ই ঘটুক, তা থেকে কার্যকর থাকে।

সার্ভারের ভেতর থেকে এটি না করার দুটি কারণ আছে। Compromised kernel-এর ভেতরে configure করা firewall সেই kernel-ই প্রয়োগ করে। আপনি যেভাবে nftables rule লিখতে পারেন, root ঠিক তেমন সহজে তা flush করতে পারে। আর sudo ip link set enp1s0 down over SSH চালালে প্রথমে আপনার নিজের session বিচ্ছিন্ন হবে। ফলে আপনি যে machine পরীক্ষা করছিলেন, সেটিতেই আর প্রবেশ করতে পারবেন না।

Outbound traffic-ও inbound traffic-এর মতো block করুন। Reverse shell আপনার box থেকে attacker-এর দিকে সংযোগ স্থাপন করে। তাই শুধু inbound block করলে প্রতিষ্ঠিত connection সম্পূর্ণ সচল থাকে। আপনার provider যদি শুধু inbound rule দেয়, তাহলে বাকি উপায় হলো network interface detach করা অথবা instance বন্ধ করে দেওয়া।

এখনও reboot করবেন না। প্রথমে দেখুন /var/log/journal আছে কি না। ওই directory না থাকলে journald /run/log/journal-এ লিখছে। এটি memory-তে থাকে, তাই reboot করলে intrusion-এর record মুছে যাবে। Reboot-এর সময় চলমান process-গুলোও চলে যায়। তাদের command line-ই অনেক সময় আপনার পাওয়া সবচেয়ে স্পষ্ট evidence হয়।

কোনো পরিবর্তন করার আগে ডিস্কের snapshot নিন

এখানে snapshot এবং backup ভিন্ন কাজ করে। আপনি এখন যে snapshot নেবেন, সেটি compromised disk-এর একটি অনুলিপি। এটি আপনার evidence এবং ভুল করে কোনো কিছু overwrite করার পর আগের অবস্থায় ফেরার একমাত্র উপায়। পুরোনো backup-গুলো recovery path হিসেবে কাজ করবে। আপনার provider-এর panel-এ শব্দ দুটি যদি ঢিলেঢালাভাবে ব্যবহার করা হয়, আগে VPS snapshot কীভাবে প্রকৃত backup থেকে ভিন্ন পড়ুন। কারণ retention rules এবং restore behaviour এক নয়।

আবার login করার আগে provider panel থেকে snapshot নিন। একটি live snapshot crash consistent হয়। এটি সেই মুহূর্তে ডিস্কের যে অবস্থা ছিল, সেটিই capture করে—যেন power সরাসরি বন্ধ করা হয়েছে। Evidence হিসেবে এটি যথেষ্ট। এমন নাম দিন, যাতে কেউ ভুল করে এটি restore না করে। COMPROMISED-do-not-restore-2026-08-12-এর মতো স্পষ্ট নামই উপযুক্ত। আপনার investigation শেষ না হওয়া এবং host-এর সঙ্গে করা যেকোনো abuse ticket closed না হওয়া পর্যন্ত এটি সংরক্ষণ করুন।

SSH না থাকলে কীভাবে প্রবেশ করবেন

উভয় পদ্ধতিই provider panel-এ পাওয়া যায়। Web console (VNC বা serial) মেশিনের সঙ্গে এমনভাবে সংযুক্ত হয়, যেন আপনি সেখানে একটি keyboard সংযুক্ত করেছেন। sshd বন্ধ থাকলেও, firewall ভুলভাবে কনফিগার করা থাকলেও এবং attacker SSH port পরিবর্তন করলেও এটি কাজ করে। এটি local password দিয়ে authentication করে। তাই key-only server-এর ক্ষেত্রে console ব্যবহার করার আগে root password reset করতে হতে পারে।

Rescue mode ভালো বিকল্প। এটি আপনার disk সংযুক্ত অবস্থায় একটি ছোট live system boot করে, তবে disk-এর system চালু থাকে না। ফলে আপনার command নির্ভরযোগ্য থাকে: compromised kernel এবং compromised binary চালু থাকে না। Disk-টি read only হিসেবে mount করুন।

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

যদি lsblk plain partition-এর পরিবর্তে LVM (logical volume manager) volume দেখায়, আগে sudo vgchange -ay দিয়ে সেগুলো activate করুন। এরপর /dev/mapper/-এর অধীনে প্রদর্শিত device-টি mount করুন।

চারপাশ দেখার জন্য mounted disk-এ chroot করবেন না। chroot আপনার permission ব্যবহার করে attacker's binary চালায়। এতে rescue mode boot করার পুরো উদ্দেশ্য নষ্ট হয়ে যায়।

এখনও বিশ্বাসযোগ্য প্রমাণ সংগ্রহ করুন

rescue mode থেকে এগুলো চালান। ডিস্কটি /mnt/victim-এ read only হিসেবে mount করুন। প্রথমে login পরীক্ষা করুন, কারণ এগুলো intrusion-এর সময় নির্ধারণে সাহায্য করে। সময়সীমা জানা থাকলে পরের সব পরীক্ষা সহজ হয়।

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

/var/log/auth.log না থাকা নিজে সন্দেহজনক নয়। কিছু বর্তমান Ubuntu image-এ rsyslog থাকে না। তাই sshd শুধু journal-এ log লেখে, এবং journalctl -D line সেটিই পড়ে। তবে ধারাবাহিক log-এর মধ্যে কোনো gap থাকলে, অথবা কোনো log file-এর আকার শূন্য হয়ে গেলে তা নোট করুন। Log মুছে ফেলা সাধারণ ঘটনা এবং এটি সাধারণত অদক্ষভাবে করা হয়।

এরপর account ও key পরীক্ষা করুন।

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

awk line প্রতিটি user ID 0-সহ account দেখায়। ওই output-এ root ছাড়া অন্য কিছু থাকলে সেটি দ্বিতীয় root account। find pattern-এ ইচ্ছাকৃতভাবে authorized_keys2-কেও মেলানো হয়, কারণ OpenSSH ডিফল্টভাবে উভয় file name পড়ে এবং দ্বিতীয়টি সহজেই চোখ এড়িয়ে যায়। lsattr যদি attribute list-এ i দেখায়, তাহলে file-টি immutable। Attacker এই flag সেট করে, যাতে আপনার key মুছে ফেলার চেষ্টা Operation not permitted-এর মাধ্যমে ব্যর্থ হয় এবং ক্লান্ত admin ধরে নেন যে edit সফল হয়েছে।

Persistence অল্প কয়েকটি জায়গায় লুকিয়ে থাকে, তাই সবগুলো পরীক্ষা করুন।

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

স্বাভাবিক Ubuntu বা Debian system-এ /etc/ld.so.preload থাকে না। তাই No such file or directory-ই স্বাভাবিক ফলাফল। এতে যেকোনো content থাকলে তা গুরুত্ব দিয়ে পরীক্ষা করুন। কোনো login file যদি base64 -d output shell-এ pipe করে, সেটিও একই ধরনের সমস্যা। বৈধ configuration-এর নিজের text লুকিয়ে রাখার প্রয়োজন হয় না।

Modification time নয়, change time ব্যবহার করে timeline তৈরি করুন।

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch modification time attacker-এর ইচ্ছামতো যেকোনো মানে সেট করতে পারে। তাই mtime সহজেই মিথ্যা তথ্য দেয়। Inode-এ যেকোনো পরিবর্তন হলে change time (ctime) update হয়, এবং touch এটিকে পিছনের সময়ে নিতে পারে না। তাই -newerct সম্প্রতি লেখা file-এর তুলনামূলকভাবে বেশি নির্ভরযোগ্য তালিকা দেয়। তবু এটি প্রমাণ নয়, কারণ root system clock পরিবর্তন করতে পারে অথবা সরাসরি block device-এ লিখতে পারে।

Package integrity যাচাইয়ের জন্য একটি command যথেষ্ট, তবে একটি গুরুত্বপূর্ণ সীমাবদ্ধতা মনে রাখুন। Running system-এ sudo dpkg --verify এমন প্রতিটি packaged file-এর জন্য একটি line দেখায়, যার checksum আর মেলে না। Checksum column-এ 5 দেখা যায়। sudo debsums -ac একই কাজ করে এবং config file-ও অন্তর্ভুক্ত করে, যদি debsums package install করা থাকে। ফলাফল এক দিক থেকে ব্যাখ্যা করুন। পরিবর্তিত /usr/sbin/sshd সত্যিকারের প্রমাণ। কিন্তু clean report কিছুই প্রমাণ করে না, কারণ binary প্রতিস্থাপনকারী একই root account /var/lib/dpkg/info/-এর অধীনে checksum list আবার লিখতে পারে। rkhunter এবং chkrootkit-এর মতো rootkit scanner-এর ক্ষেত্রেও একই নিয়ম প্রযোজ্য: hit পাওয়া তথ্য দেয়, কিন্তু clean run system-কে নিরাপদ ঘোষণা করার প্রমাণ নয়।

কোনো destructive কাজ করার আগে সংগৃহীত data machine-এর বাইরে copy করুন।

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

সেই hash server-এর বাইরে কোথাও লিখে রাখুন। এটি কখনও insurance claim বা police report-এর বিষয় হলে, collection-এর পর archive পরিবর্তিত হয়নি তা দেখাতে পারা evidence এবং শুধু file-ভরা একটি folder-এর মধ্যে পার্থক্য তৈরি করে। Investigation চলাকালে ভুল করে কিছু delete হয়ে যাওয়া স্বাভাবিক। Snapshot এবং এই archive থাকলেই পরিস্থিতি সামাল দেওয়া সম্ভব হয়। পরে ভুল rm undo করা মানুষ যতটা ভাবেন, তার চেয়ে অনেক কঠিন। rm -rf দিয়ে মুছে ফেলা file পুনরুদ্ধার-এ বিষয়টি ব্যাখ্যা করা হয়েছে।

যে পথ দিয়ে তারা ঢুকেছিল তা শনাক্ত করুন

প্রবেশের পথ বন্ধ না করে সার্ভার পুনর্নির্মাণ করলে সেটি আবারও compromised হবে, প্রায়ই কয়েক দিনের মধ্যেই। কারণ যে scan প্রথমবার আপনাকে খুঁজে পেয়েছিল, সেটি চলতেই থাকে। একক সার্ভার compromised হওয়ার অধিকাংশ ঘটনা 4টি প্রবেশপথের একটির মাধ্যমে ঘটে।

SSH password login। আপনি চেনেন না এমন কোনো address থেকে আসা একটি Accepted password for root line-ই যথেষ্ট প্রমাণ। /etc/ssh/sshd_config-এ এবং /etc/ssh/sshd_config.d/-এর অধীন প্রতিটি file-এ PasswordAuthentication পরীক্ষা করুন। sshd কোনো keyword-এর জন্য যে প্রথম value পায়, সেটিই ব্যবহার করে। Ubuntu-তে Include line-টি main file-এর শুরুতে থাকে। তাই পরে আপনি যে setting সম্পাদনা করেছেন, তার বদলে যুক্ত করা config file-এর setting নীরবে কার্যকর হয়।

Authentication ছাড়া প্রকাশিত কোনো service। 6379 port-এ Redis, 2375 port-এ Docker API, অথবা 0.0.0.0-এ bind করা কোনো database, যা 127.0.0.1-এর বদলে ব্যবহৃত হয়েছে। Docker এখানে প্রায়ই অপ্রত্যাশিত কারণ হয়ে দাঁড়ায়। কোনো container port publish করলে DNAT (destination network address translation) rule যোগ হয়। এই rule-গুলো ufw chain-এর আগে মূল্যায়ন করা হয়। তাই ufw status কোনো port-কে blocked দেখাতে পারে, অথচ এর পেছনের container পুরো Internet-এর অনুরোধের উত্তর দিতে পারে। Rebuild-এর আগে বিষয়টি বুঝে নিন: কেন Docker-এর published port ufw বাইপাস করে rule-এর ক্রম এবং সমাধান ব্যাখ্যা করে।

Patch না করা কোনো web application। আপনার প্রথম সন্দেহজনক timestamp-এর কাছাকাছি সময়ে web server access log-এ upload path বা admin path-এ কোনো POST request খুঁজুন। এরপর web root-এর অধীন matching change time-সহ file খুঁজুন। uploads directory-তে থাকা একটি অপ্রত্যাশিত PHP file এ ধরনের ঘটনার প্রচলিত ফল।

ফাঁস হওয়া কোনো credential। কোনো repository-তে commit করা key, chat-এ paste করা token, অথবা misconfigured web server static file হিসেবে পরিবেশন করা কোনো .env file। Automation-এর কারণে এটি ভুল করে সহজেই ঘটতে পারে। তাই AI agent এবং তাদের config file-এর বাইরে secret রাখুন।

এসব পরীক্ষা করার পরও যদি প্রবেশপথটির নাম নির্দিষ্ট করতে না পারেন, তাহলে ধরে নিন কোনো credential ফাঁস হয়েছে। মেশিনে থাকা প্রতিটি secret-কে public হিসেবে বিবেচনা করুন।

মেশিনটি যেসব credential দেখতে পেরেছে, সব পরিবর্তন করুন

Network বিচ্ছিন্ন করার পরে credential পরিবর্তন করুন, কখনও তার আগে নয়। Attacker-এর connection সক্রিয় থাকা অবস্থায় credential পরিবর্তন করলে নতুন secret-ও তার হাতে চলে যেতে পারে।

• সার্ভারে সংরক্ষিত প্রতিটি SSH private key এবং সংশ্লিষ্ট public key-কে trust করা অন্য সব account।
• ssh -A দিয়ে box-এ forward করা যেকোনো key। Agent forwarding /tmp-এর অধীনে একটি socket রেখে যায়। ওই মেশিনে root account থাকলে, আপনার session খোলা থাকা পর্যন্ত এবং যেসব জায়গায় আপনার key গ্রহণযোগ্য, সেখানেই আপনার পরিচয়ে authenticate করা সম্ভব।
• .env file, systemd-এর Environment= line, CI configuration এবং provider credential-এ থাকা API token।
• Database password এবং সেগুলো ব্যবহার করা application account।
• সার্ভারে থাকা TLS (transport layer security) private key। Certificate পুনরায় issue করুন এবং পুরোনো certificate revoke করুন।
• আপনার hosting account-এর password। সেখানে two-factor authentication চালু করুন। ওই panel দিয়ে আপনার মালিকানাধীন প্রতিটি server rebuild, snapshot এবং console access করা যায়। তাই এটিই প্রকৃত perimeter।
• Server compromised থাকা অবস্থায় ওই host-এর shell session-এ টাইপ করা যেকোনো password। কারণ root account terminal session চলার সময় সেটি record করতে পারে।

ওই মেশিনের কোনো password অন্য কোথাও ব্যবহার করা হলে সেখানেও password পরিবর্তন করুন। Password reuse-এর কারণেই একটি compromised VPS থেকে email account-ও compromised হয়ে যেতে পারে।

পুনর্নির্মাণের চেকলিস্ট

1. একটি নতুন distribution image থেকে নতুন server তৈরি করুন। compromised server-এর snapshot থেকে নয় এবং সম্পূর্ণ root filesystem restore থেকেও নয়।
2. distribution repository থেকে package install করুন। পুরোনো disk থেকে কোনো binary কখনো copy করবেন না।
3. timeline-এ intrusion-এর প্রাচীনতম প্রমাণের আগের তারিখের backup থেকে শুধু data restore করুন। Database dump, upload এবং application state restore করুন। /etc, /usr এবং পুরোনো unit file বাদ দিন।
4. পরিবর্তিত secret হাতে লিখে দিন। পুরোনো .env copy করবেন না।
5. restored web content আবার serve করার আগে intrusion window-এর মধ্যে যোগ করা file আছে কি না পরীক্ষা করুন।
6. server-কে Internet-এ expose করার আগে harden করুন: শুধু key দিয়ে SSH login, non-root working account, inbound traffic-এর জন্য default-deny firewall এবং প্রয়োজনের চেয়ে বেশি network interface-এ কোনো service publish না করা। নতুন VPS-এর প্রথম দশ মিনিট অনুসরণ করুন, তারপর SSH সঠিকভাবে harden করুন, এবং login noise কমাতে Ubuntu 24.04-এ fail2ban যোগ করুন। প্রতিটি service-এর জন্য নিজস্ব least-privilege account ব্যবহার করুন, যাতে পরের foothold root account-এর foothold না হয়।
7. পুরোনো server power off করুন এবং investigation ও সংশ্লিষ্ট abuse ticket বন্ধ না হওয়া পর্যন্ত তার snapshot সংরক্ষণ করুন।
8. backup ব্যবস্থা ঠিক করুন। যদি step 3 অনুমানের ওপর নির্ভর করে করতে হয়, তাহলে মূল শিক্ষা হলো আপনার backup history intrusion-এর আগের সময়ে পৌঁছানোর জন্য যথেষ্ট দীর্ঘ ছিল না। দীর্ঘ retention-সহ versioned off-server backup পরের বার clean restore point পাওয়ার সুযোগ তৈরি করে: VPS-এ restic backup দুটিই দেয়।

যদি intrusion-এর তারিখ নির্ধারণ করতে না পারেন, তাহলে নিরাপদ backup বেছে নিতে পারবেন না। সে ক্ষেত্রে শুধু এমন data restore করুন যা চোখে দেখে পরীক্ষা করতে পারেন: পড়া যায় এমন একটি SQL dump বা তালিকা করা যায় এমন image-এর directory। সব executable-কে সন্দেহজনক ধরে নিন এবং repository থেকে আবার install করুন।

আপনার host-এর abuse notice-এর অর্থ

বেশিরভাগ মানুষ নিজেদের monitoring থেকে নয়, provider-এর কাছ থেকে জানতে পারেন যে তাদের server compromised হয়েছে। host-গুলো outbound traffic দেখতে পায়: অন্য network-এর বিরুদ্ধে SSH brute-force, port 25-এ spam, অথবা reflection attack-এ কোনো অংশগ্রহণ। ticket-এ সাধারণত timestamp, port এবং flow-এর নমুনা থাকে। এর সঙ্গে কয়েক ঘণ্টার মধ্যে ব্যবস্থা নেওয়ার deadline-ও থাকতে পারে।

এর উত্তর দিন। আপনার একমাত্র উত্তর যদি হয় যে server-টি isolated করা হয়েছে এবং নতুন করে rebuild করা হচ্ছে, তবুও উত্তর দিন। কোনো ticket-এর উত্তর না পেলে provider server-এ null route প্রয়োগ করতে বা server suspend করতে পারে। এতে incidentটি outage-এ পরিণত হয়। এরপর report-এর পেছনে থাকা raw log line চাইুন। ওই timestamp আপনার machine-এর বাইরে record করা হয়েছে। তাই timeline-এর এটিই এমন অংশ, যা attacker edit করতে পারেনি। Disk-এর অন্য যেকোনো তথ্যের তুলনায় এগুলো প্রায়ই intrusion-এর সময় নির্ধারণে বেশি নির্ভরযোগ্য।

কোনো customer-এর compromised server সামলানো host-এর জন্য নিয়মিত কাজ। এটি সঠিকভাবে সামলালে provider সাধারণত আপনাকে দোষী হিসেবে বিবেচনা করে না। VPS hosting নিরাপদ কি না—এই বৃহত্তর প্রশ্নটি মূলত customer কী configure করেন তার ওপর নির্ভর করে। এখন সেই configuration-ই আপনাকে শূন্য থেকে আবার করতে হবে।

কখন পেশাদারের সহায়তা নেবেন

• সার্ভারে অন্য ব্যক্তিদের ব্যক্তিগত ডেটা ছিল। GDPR (General Data Protection Regulation) অনুযায়ী, ব্যক্তিগত ডেটা breach-এর বিষয়টি অযথা বিলম্ব না করে supervisory authority-কে জানাতে হবে। এটি সম্ভব হলে breach সম্পর্কে জানার 72 ঘণ্টার মধ্যে জানাতে হবে। এই সময়সীমা শুরু হয়েছে কি না তা নির্ধারণ করা আইনি কাজ, sysadmin-এর কাজ নয়।
• Payment card data-এর আওতাভুক্ত তথ্য ছিল। Card scheme-গুলো অনুমোদিত forensic investigator নিয়োগের দাবি করে। নিজেরা অতিরিক্ত পরীক্ষা-নিরীক্ষা করলে তদন্তের প্রমাণ নষ্ট হতে পারে।
• Extortion demand এসেছে, অথবা আপনার ডেটা encrypted করা হয়েছে।
• মেশিনটি অন্য মেশিনে পৌঁছাতে পারত: internal network, production credential রাখা hypervisor, বা CI runner-এ। একটি group-এর একটি host compromised হলে, বিপরীত প্রমাণ না পাওয়া পর্যন্ত পুরো group-এর incident হিসেবে বিবেচনা করুন।
• Insurance claim বা law enforcement-এর জন্য evidence গ্রহণযোগ্য অবস্থায় রাখতে হবে। Snapshot নেওয়ার পর থামুন, full disk image নিন, এবং কে কখন এটি handle করেছে তা record করুন।

নিজের service চালানো একটি VPS-এ অন্য কারও ডেটা না থাকলে, ওপরের playbook-ই পুরো কাজ। Provider-এর দিক থেকে মেশিনটি isolate করুন। Evidence-এর জন্য snapshot নিন। এখনও trustworthy যা আছে তা collect করুন। সবকিছুর credential ও secret rotate করুন। পরিষ্কারভাবে rebuild করুন।

FAQ

আমি কি VPS পুনর্নির্মাণ না করে hacked VPS পরিষ্কার করতে পারি?

কোনো নির্ভরযোগ্যতার সঙ্গে নয়, কারণ এতে compromised system-কেই নিজের অবস্থা সম্পর্কে রিপোর্ট করতে বলা হয়। প্রতিস্থাপিত ps কোনো process আড়াল করতে পারে, /etc/ld.so.preload-এর একটি line আপনার চালানো প্রতিটি dynamically linked tool-এ code inject করতে পারে, এবং একটি kernel module একই সঙ্গে প্রতিটি program-এর কাছ থেকে file আড়াল করতে পারে। আপনি কিছু জিনিস খুঁজে পেতে পারেন, তাই কোনো ফল পাওয়া অর্থপূর্ণ। কিন্তু কিছুই নেই—এটি প্রমাণ করতে পারবেন না, তাই clean result নির্ভরযোগ্য নয়। Server-এ গুরুত্বপূর্ণ কিছু না থাকলে এবং এটি আবার compromised হতে পারে—এই ঝুঁকি মেনে নিলে—শুধু তখনই cleaning যুক্তিসঙ্গত।

compromised server কি বন্ধ করে দেব, নাকি চালু রাখব?

প্রথমে provider-এর মাধ্যমে এর network বিচ্ছিন্ন করুন। এরপর snapshot নেওয়া এবং চলমান process পরীক্ষা করার জন্য কিছু সময় server চালু রাখুন। Power off করলে process list নষ্ট হয়ে যায়। /var/log/journal না থাকলে journal-ও পুরোপুরি মুছে যায়, কারণ তখন journald /run-এর অধীনে memory-তে লেখে। তবে server সক্রিয়ভাবে অন্য network-এ আক্রমণ চালালে এবং outbound traffic block করার কোনো উপায় না থাকলে এটি বন্ধ করে দিন। ক্ষতি থামানো evidence সংরক্ষণের চেয়ে বেশি গুরুত্বপূর্ণ।

attacker কখন প্রবেশ করেছিল তা কীভাবে নির্ধারণ করব?

/var/log/auth.log অথবা journal-এ এমন সবচেয়ে পুরোনো Accepted password বা Accepted publickey line খুঁজুন, যার ব্যাখ্যা আপনি দিতে পারেন না। এরপর change-time listing, find / -xdev -newerct 'YYYY-MM-DD' -type f-এর সঙ্গে cross-check করুন, কারণ mtime-এর তুলনায় ctime জাল করা কঠিন। তারপর দুটির timestamp আপনার provider-এর abuse ticket-এর timestamp-এর সঙ্গে তুলনা করুন। ওই timestamp machine-এর বাইরে record করা হয়েছে এবং সম্পাদনা করা যায়নি। এই তিনটি তারিখের মধ্যে সবচেয়ে পুরোনোটির চেয়ে পুরোনো একটি backup বেছে নিন। কোনো timestamp সামঞ্জস্যপূর্ণ না হলে ধরে নিন যে আপনার backup history-এর চেয়েও আগে compromise ঘটেছে, এবং শুধু এমন data restore করুন যা আপনি পরীক্ষা করতে পারেন।

compromise-এর পরে আমার backup কি নিরাপদে restore করা যাবে?

Inspection-এর পরে data সাধারণত restore করা যায়। System file নিরাপদ নয়। Intrusion-এর পরে নেওয়া backup-এ backdoor থাকে। তাই পুরো root filesystem restore করলে attacker-ও ফিরে আসে। Backup repository নিজেও পরীক্ষা করুন। এর credentials যদি compromised server-এ সংরক্ষিত থাকে, তাহলে history মুছে ফেলা বা পরিবর্তন করা হয়ে থাকতে পারে। এ কারণেই append-only অথবা pull-based backup target ব্যবহার করা গুরুত্বপূর্ণ। Application data restore করুন। এরপর distribution repository থেকে software আবার install করুন।

আমার VPS compromised হয়েছে—এ কথা কি কাউকে জানাতে হবে?

আপনার host-এর abuse notice-এর জবাব সবসময় দিন। এর বাইরে কাকে জানাতে হবে, তা machine-এ কার data ছিল তার ওপর নির্ভর করে। অন্য ব্যক্তিদের personal data থাকলে আইনগত reporting duty তৈরি হতে পারে, যেমন GDPR অনুযায়ী supervisory authority-কে 72 ঘণ্টার মধ্যে notification দিতে হয়। Server-এ user credential সংরক্ষিত থাকলে ওই user-দের জানান, যাতে তারা অন্যত্র password পরিবর্তন করতে পারেন। Machine-এ third-party system-এ access অনুমোদনকারী key থাকলে, যেমন code host বা cloud account-এর key, সংশ্লিষ্ট provider-কে জানান, যাতে তারা অপব্যবহার পরীক্ষা করতে পারে। অন্য কারও data না থাকা সম্পূর্ণ ব্যক্তিগত server-এর ক্ষেত্রে abuse ticket-এর বাইরে অতিরিক্ত কোনো বাধ্যবাধকতা থাকে না।