VPS ہیک ہو جائے تو کیا کریں؟ صاف نہ کریں، rebuild کریں

ہیک شدہ VPS کو صاف نہ کریں

اگر آپ کا VPS ہیک ہو گیا ہے تو سب سے اہم فیصلہ کوئی بھی command چلانے سے پہلے کرنا ہوتا ہے۔ مشین کو صاف کرنے کی کوشش نہ کریں۔ اسے provider کی سطح پر isolate کریں، ثبوت کے طور پر disk کا snapshot بنائیں، اس میں موجود ہر credential کو rotate کریں، پھر اپنے اعتماد کے ذرائع سے ایک نئے server پر اسے دوبارہ build کریں۔

آپ یہ ثابت نہیں کر سکتے کہ rootkit ختم ہو چکا ہے، کیونکہ اسے ثابت کرنے والے tools وہی tools ہیں جنہیں attacker control کرتا ہے۔

بات کا خلاصہ یہی ہے۔ اس کے پیچھے موجود طریقۂ کار یہ ہے۔ جس attacker کو root تک رسائی مل جائے، وہ ps کو تبدیل کر سکتا ہے تاکہ ایک process ID اس کے output میں کبھی ظاہر نہ ہو۔ /etc/ld.so.preload میں ایک line مشین پر موجود ہر dynamically linked program میں attacker کا code load کر سکتی ہے، اس لیے ls، ss اور find سب ایک ہی مستقل انداز میں غلط معلومات دیتے ہیں۔ ایک loadable kernel module system call سے نیچے files کو hide کر سکتا ہے، اس لیے تازہ download کیا گیا binary بھی صاف disk دیکھتا ہے۔ آپ miner delete کرتے ہیں، CPU graph نیچے آتا ہے، اور server خاموش ہو جاتا ہے۔ کام کرنے والا backdoor بھی خاموش ہی دکھائی دیتا ہے۔

Rebuild کی لاگت محسوس ہونے سے کم ہوتی ہے۔ ایک عام VPS میں چند packages، ایک config directory اور ایک data set ہوتا ہے، اس لیے rebuild ایک محدود کام ہے جس کا اختتام ہوتا ہے۔ attacker کی کی گئی ہر تبدیلی تلاش کرنا لا محدود کام ہے، اور اس سے کبھی ثبوت حاصل نہیں ہوتا۔

واقعی breach کی تصدیق کریں

جن servers کو hacked بتایا جاتا ہے، ان میں سے بہت سے واقعی breached نہیں ہوتے۔ روزانہ ہزاروں ناکام SSH logins internet کا معمول کا background noise ہیں، کیونکہ ہر public IPv4 address کو مسلسل scan کیا جاتا ہے۔ lastb کا ایسا output جس میں root اور admin attempts کی بھرمار ہو، اس کا مطلب ہے کہ scanners نے آپ کا port تلاش کر لیا ہے۔ اس کا مطلب یہ نہیں کہ کوئی اندر داخل ہو گیا ہے۔

یہ signals واقعی اہم ہیں:

• ایسا successful login جس کی آپ وضاحت نہ کر سکیں، مثلاً Accepted password for root from 203.0.113.7۔
• authorized_keys میں ایسی key جسے آپ نے شامل نہ کیا ہو۔
• آپ کے host کی طرف سے آپ کے server سے باہر جانے والے traffic کے بارے میں abuse notice۔
• 100% CPU استعمال کرنے والا ایسا process جس کا نام kernel thread سے نقل کیا گیا ہو۔ Exposed Redis اور Docker sockets کے ذریعے داخل کیے گئے miners کے بارے میں عموماً kdevtmpfsi اور kinsing جیسے نام report کیے جاتے ہیں۔
• ایسے addresses کے لیے outbound connections جنہیں آپ کی کوئی service استعمال نہیں کرتی۔

Kernel thread کی نقالی کی فوری جانچ کی جا سکتی ہے۔ حقیقی kernel threads square brackets کے اندر ظاہر ہوتے ہیں اور ان کے پیچھے کوئی executable نہیں ہوتا، اس لیے sudo ls -l /proc/<pid>/exe ان کے لیے No such file or directory کے ساتھ fail ہوتا ہے۔ اگر [kworker/0:2] کے طور پر ظاہر ہونے والے process کا exe link /tmp کے اندر موجود کسی چیز کی طرف اشارہ کرتا ہو، تو یہ ایک عام user program ہے جو kernel name استعمال کر رہا ہے۔

یہ checks اس بات کو مدنظر رکھتے ہوئے چلائیں کہ ممکن ہے box آپ کو غلط معلومات دے رہا ہو۔ ان سے یہ فیصلہ کرنے کے لیے کافی شواہد مل جاتے ہیں کہ کچھ غلط ہے۔ لیکن ان سے یہ فیصلہ نہیں کیا جا سکتا کہ کچھ بھی غلط نہیں ہے۔

نیٹ ورک کو اندر سے نہیں، provider کی سطح پر منقطع کریں

سب سے پہلے isolation کریں، کیونکہ جب تک کوئی دوسرا شخص shell استعمال کر رہا ہو، اس کے بعد کا ہر قدم ضائع ہو جاتا ہے۔ فعال attacker کے logs دیکھنا، keys rotate کرنا اور data restore کرنا بے فائدہ ہے، کیونکہ وہ سب کچھ دیکھ رہا ہوتا ہے۔

یہ کام اپنے provider کے control panel میں موجود اس network firewall سے کریں جو آپ کے operating system سے باہر چلتا ہے۔ inbound اور outbound دونوں traffic deny کریں، اور web console کو رسائی کے اپنے طریقے کے طور پر برقرار رکھیں۔ وہاں نافذ کیے گئے rules، disk پر ہونے والی کسی بھی کارروائی کے باوجود برقرار رہتے ہیں۔

اس کام کو server کے اندر سے نہ کرنے کی دو وجوہات ہیں۔ compromised kernel کے اندر configure کیا گیا firewall اسی kernel کے ذریعے نافذ ہوتا ہے، اور root آپ کی طرح آسانی سے nftables rules flush کر سکتا ہے۔ مزید یہ کہ sudo ip link set enp1s0 down کو SSH پر چلانے سے پہلے آپ کا اپنا session منقطع ہو جاتا ہے، اور آپ اس machine سے lock out ہو جاتے ہیں جس کا آپ اسی وقت جائزہ لے رہے تھے۔

outbound traffic کو بھی inbound traffic کی طرح block کریں۔ reverse shell آپ کے box سے attacker کی طرف outbound connection بناتا ہے، اس لیے صرف inbound traffic block کرنے سے قائم connection پوری طرح فعال رہتا ہے۔ اگر آپ کا provider صرف inbound rules فراہم کرتا ہے تو باقی options network interface detach کرنا یا instance کو power off کرنا ہیں۔

ابھی reboot نہ کریں۔ پہلے دیکھیں کہ /var/log/journal موجود ہے یا نہیں۔ اگر یہ directory موجود نہ ہو تو journald /run/log/journal میں لکھ رہا ہے، جو memory میں رہتی ہے، اس لیے reboot intrusion کا record حذف کر دے گا۔ reboot کے وقت running processes بھی ختم ہو جاتے ہیں، جبکہ ان کی command lines اکثر وہ سب سے واضح evidence ہوتی ہیں جو آپ کو کبھی مل سکتی ہے۔

کسی بھی کارروائی سے پہلے disk کا snapshot لیں

یہاں snapshot اور backup مختلف کام انجام دیتے ہیں۔ جو snapshot آپ ابھی لیں گے، وہ breached disk کی نقل ہے۔ یہ آپ کا evidence ہے، اور یہی واحد چیز ہے جو آپ کو حادثاتی طور پر کچھ overwrite کرنے کے بعد واپس جانے دیتی ہے۔ آپ کے پرانے backups recovery path ہیں۔ اگر آپ کے provider کا panel ان دونوں الفاظ کو غیر واضح طور پر استعمال کرتا ہے تو پہلے یہ پڑھیں کہ VPS snapshots حقیقی backups سے کیسے مختلف ہیں، کیونکہ retention rules اور restore behaviour ایک جیسے نہیں ہوتے۔

دوبارہ login کرنے سے پہلے provider panel سے snapshot لیں۔ Live snapshot crash consistent ہوتا ہے: یہ disk کو اسی لمحے کی حالت میں محفوظ کرتا ہے، بالکل ایسے جیسے power کھینچ دی گئی ہو۔ Evidence کے لیے یہ کافی ہے۔ اسے ایسا نام دیں کہ کوئی اسے غلطی سے restore نہ کر دے۔ COMPROMISED-do-not-restore-2026-08-12 جیسا بالکل واضح نام اس مقصد کے لیے مناسب ہے۔ اسے اس وقت تک محفوظ رکھیں جب تک آپ کی investigation مکمل نہ ہو جائے اور host کے ساتھ abuse ticket بند نہ ہو جائے۔

SSH دستیاب نہ ہونے کی صورت میں داخل ہونے کا طریقہ

اس کے دو طریقے ہیں، اور دونوں provider panel میں دستیاب ہوتے ہیں۔ web console (VNC یا serial) مشین سے اس طرح منسلک ہوتا ہے جیسے آپ نے اس میں keyboard لگایا ہو۔ یہ اس وقت بھی کام کرتا ہے جب sshd بند ہو، firewall کی configuration غلط ہو، یا attacker نے SSH port تبدیل کر دیا ہو۔ یہ local password سے authentication کرتا ہے، اس لیے key-only server میں console استعمال کرنے سے پہلے root password reset کرنا ضروری ہو سکتا ہے۔

Rescue mode بہتر انتخاب ہے۔ یہ ایک چھوٹا live system boot کرتا ہے اور آپ کی disk کو attached لیکن غیر فعال حالت میں رکھتا ہے، اس لیے آپ کے commands قابلِ اعتماد رہتے ہیں: compromised kernel اور compromised binaries execute نہیں ہو رہے ہوتے۔ 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) volumes دکھائی دیں تو پہلے sudo vgchange -ay سے انہیں activate کریں، پھر /dev/mapper/ کے تحت ظاہر ہونے والے device کو mount کریں۔

mounted disk کا جائزہ لینے کے لیے اس میں chroot نہ کریں۔ chroot، attacker کے binaries کو آپ کی permissions کے ساتھ execute کرتا ہے۔ اس سے rescue mode میں boot کرنے کی پوری وجہ ختم ہو جاتی ہے۔

اب بھی قابلِ اعتماد شواہد جمع کریں

یہ commands rescue mode سے چلائیں، اور disk کو /mnt/victim پر read only حالت میں mount کریں۔ پہلے logins سے شروع کریں، کیونکہ ان سے intrusion کا وقت معلوم ہوتا ہے۔ اس کے بعد time window دستیاب ہونے کی وجہ سے باقی جانچ آسان ہو جاتی ہے۔

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 images، rsyslog کے بغیر آتی ہیں، اس لیے sshd صرف journal میں log کرتا ہے، اور journalctl -D line اسی journal کو پڑھتی ہے۔ جس بات کو نوٹ کرنا چاہیے وہ مسلسل logs میں gap، یا ایسی log file ہے جسے truncate کرکے zero bytes کر دیا گیا ہو۔ Log wiping عام ہے اور عموماً غیر محتاط انداز میں کی جاتی ہے۔

اب accounts اور keys کی جانچ کریں۔

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 ہر اس account کو دکھاتی ہے جس کا user ID 0 ہو۔ اس output میں root کے علاوہ کوئی بھی چیز second root account ہے۔ find pattern جان بوجھ کر authorized_keys2 سے بھی match کرتا ہے، کیونکہ OpenSSH default طور پر دونوں file names پڑھتا ہے اور دوسری file آسانی سے نظر انداز ہو جاتی ہے۔ اگر lsattr attribute list میں i دکھائے، تو file immutable ہے۔ attacker یہ flag اس لیے set کرتا ہے کہ آپ کی key delete کرنے کی کوشش Operation not permitted کے ساتھ fail ہو جائے، اور تھکا ہوا administrator سمجھے کہ 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

/etc/ld.so.preload عام Ubuntu یا Debian system پر موجود نہیں ہوتی، اس لیے No such file or directory صحت مند نتیجہ ہے، جبکہ کسی بھی قسم کا content توجہ کا مستحق ہے۔ ایسی login file جو base64 -d کے output کو shell میں pipe کرتی ہو، اسی نوعیت کی علامت ہے۔ جائز configuration کو اپنا text چھپانے کی ضرورت نہیں ہوتی۔

Timeline کو modification time کے بجائے change time سے بنائیں۔

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

touch modification time کو attacker کی مرضی کی کسی بھی value پر set کر دیتا ہے، اس لیے mtime آسانی سے جھوٹا بنایا جا سکتا ہے۔ Change time (ctime)، inode میں ہونے والی ہر تبدیلی پر update ہوتا ہے، اور touch اسے پیچھے نہیں کر سکتا۔ اس لیے -newerct حال ہی میں لکھی گئی files کی زیادہ قابلِ اعتماد فہرست دیتا ہے۔ پھر بھی یہ قطعی ثبوت نہیں ہے، کیونکہ root system clock تبدیل کر سکتا ہے یا block device پر براہِ راست لکھ سکتا ہے۔

Package integrity کے لیے ایک command اور ایک caveat کافی ہے۔ Live system پر sudo dpkg --verify ہر اس packaged file کے لیے ایک line دکھاتا ہے جس کا checksum match نہیں کرتا؛ checksum column میں 5 ہوتا ہے۔ sudo debsums -ac بھی یہی کام کرتا ہے، اور جب debsums package installed ہو تو config files بھی شامل کرتا ہے۔ نتیجے کو صرف ایک سمت میں سمجھیں۔ بدلا ہوا /usr/sbin/sshd حقیقی evidence ہے۔ Clean report کچھ ثابت نہیں کرتی، کیونکہ وہی root account جس نے binary بدلی ہے، /var/lib/dpkg/info/ کے تحت checksum lists بھی دوبارہ لکھ سکتا ہے۔ rkhunter اور chkrootkit جیسے rootkit scanners پر بھی یہی اصول لاگو ہوتا ہے: hit معلومات فراہم کرتا ہے، مگر clean run بری الذمہ ہونے کا ثبوت نہیں ہے۔

کسی بھی 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 اور صرف files کے ایک folder کے درمیان فرق ہے۔ Investigation کے دوران چیزیں غلطی سے delete ہو جانا عام ہے، اور snapshot کے ساتھ یہ archive ہی اس نقصان سے نمٹنے کو ممکن بناتے ہیں۔ بعد میں خراب rm کو undo کرنا لوگوں کی توقع سے کہیں زیادہ مشکل ہوتا ہے، جیسا کہ rm -rf سے delete کی گئی files recover کرنا میں بیان کیا گیا ہے۔

وہ راستہ تلاش کریں جہاں سے حملہ آور داخل ہوئے

ایسا rebuild جس میں داخلے کا راستہ بند نہ کیا جائے، آپ کو دوبارہ compromised کر دیتا ہے، اکثر چند دن کے اندر، کیونکہ جس scan نے پہلی بار آپ کو تلاش کیا تھا وہ کبھی بند نہیں ہوتا۔ ایک سرور کے زیادہ تر compromises کے لیے چار راستے ذمہ دار ہوتے ہیں۔

SSH password login۔ کسی ایسے address سے آنے والی Accepted password for root لائن جسے آپ نہیں پہچانتے، خود ہی کافی ثبوت ہے۔ /etc/ssh/sshd_config میں /etc/ssh/sshd_config.d/ کے تحت موجود ہر file میں PasswordAuthentication چیک کریں۔ sshd کسی keyword کے لیے جو پہلی value حاصل کرتا ہے، وہی استعمال کرتا ہے، اور Ubuntu میں Include لائن main file کے اوپر موجود ہوتی ہے۔ اس لیے بعد میں شامل کی گئی config file خاموشی سے اس setting پر غالب آ جاتی ہے جسے آپ نے file میں نیچے edit کیا تھا۔

ایسی service جسے authentication کے بغیر public کیا گیا ہو۔ 6379 پر Redis، 2375 پر Docker API، یا ایسی database جو 127.0.0.1 کے بجائے 0.0.0.0 پر bind ہو۔ Docker اس مسئلے کی عام اور غیر متوقع وجہ ہے۔ کسی container port کو publish کرنے سے DNAT (destination network address translation) کے rules شامل ہو جاتے ہیں۔ ان rules کا جائزہ ufw کی chains سے پہلے لیا جاتا ہے۔ اس لیے ufw status کسی port کو blocked دکھا سکتا ہے، جبکہ اس کے پیچھے موجود container پورے internet کو جواب دے رہا ہو۔ rebuild سے پہلے اس بات کو سمجھیں: Docker کے published ports ufw کو bypass کیوں کرتے ہیں میں rule ordering اور حل کی وضاحت ہے۔

ایسی web application جس پر patches لاگو نہ کیے گئے ہوں۔ web server access log میں اپنے earliest مشتبہ timestamp کے آس پاس upload path یا admin path پر ہونے والی POST تلاش کریں۔ پھر web root کے اندر ایسی files دیکھیں جن کا change time اس سے مطابقت رکھتا ہو۔ uploads directory میں موجود بے قاعدہ PHP file اس کی عام علامت ہے۔

leaked credential۔ repository میں commit کی گئی key، chat میں paste کیا گیا token، یا misconfigured web server کی جانب سے static file کے طور پر serve کی جانے والی .env file۔ Automation سے یہ غلطی سے آسانی سے ہو سکتا ہے۔ یہی وجہ ہے کہ secrets کو AI agents اور ان کی config files سے باہر رکھیں۔

اگر اس سب کے بعد بھی آپ یہ متعین نہیں کر سکتے کہ حملہ آور کس راستے سے داخل ہوئے، تو leaked credential فرض کریں اور machine میں موجود ہر secret کو public سمجھیں۔

ہر وہ credential تبدیل کریں جس تک مشین کو رسائی حاصل ہو سکتی تھی

Network منقطع کرنے کے بعد credentials تبدیل کریں، اس سے پہلے کبھی نہیں۔ اگر attacker کے پاس اب بھی connection موجود ہو اور آپ credentials تبدیل کریں، تو آپ نئے secrets بھی اسے فراہم کر دیں گے۔

• Server پر محفوظ ہر SSH private key، اور ہر وہ account جو کہیں اور متعلقہ public key پر اعتماد کرتا تھا۔
• ہر وہ key جسے آپ نے ssh -A کے ذریعے machine میں forward کیا تھا۔ Agent forwarding سے /tmp کے تحت ایک socket بنتا ہے۔ اس machine پر root اس socket کو استعمال کرکے آپ کی حیثیت سے ہر اس جگہ authenticate کر سکتا ہے جہاں آپ کی key قبول ہو، جب تک آپ کا session کھلا رہے۔
• .env files، systemd کی Environment= lines، CI configuration، اور provider credentials میں موجود API tokens۔
• Database passwords، اور وہ application accounts جو انہیں استعمال کرتے ہیں۔
• وہ TLS (transport layer security) private keys جو server کے پاس موجود تھیں۔ Certificate دوبارہ جاری کریں اور پرانے certificate کو revoke کریں۔
• اپنے hosting account کا password، اور اس پر two-factor authentication فعال کریں۔ وہ panel آپ کے ہر server کو rebuild، snapshot اور console access دے سکتا ہے، اس لیے حقیقی perimeter وہی ہے۔
• اس host پر compromised حالت کے دوران shell session میں درج کیا گیا ہر password، کیونکہ root terminal session کو اسی وقت record کر سکتا ہے۔

اگر اس machine کا کوئی password کہیں اور بھی استعمال ہوتا ہے تو وہاں بھی اسے تبدیل کریں۔ Password reuse کی وجہ سے ایک compromised VPS، compromised email account میں تبدیل ہو جاتا ہے۔

دوبارہ تعمیر کی چیک لسٹ

1. تازہ distribution image سے نیا server بنائیں۔ compromised server کے snapshot سے نہیں، اور نہ ہی پورے root filesystem کی restore سے۔
2. packages کو distribution repositories سے install کریں۔ پرانی disk سے کوئی binary کبھی copy نہ کریں۔
3. صرف data restore کریں، اور ایسا backup استعمال کریں جو آپ کی timeline میں موجود ابتدائی ترین evidence سے پہلے کا ہو۔ اس میں database dumps، uploads اور application state شامل ہیں۔ /etc، /usr اور پرانی unit files کو وہیں چھوڑ دیں۔
4. تبدیل کیے گئے secrets ہاتھ سے درج کریں۔ پرانا .env copy نہ کریں۔
5. restored web content کو دوبارہ serve کرنے سے پہلے intrusion window کے دوران شامل کی گئی files کے لیے inspect کریں۔
6. اسے public access دینے سے پہلے harden کریں: صرف key-based SSH، non-root working account، default-deny inbound firewall، اور کوئی بھی service ضرورت سے زیادہ وسیع سطح پر publish نہ ہو۔ نئے VPS کے پہلے دس منٹ کے مراحل مکمل کریں، پھر SSH کو درست طریقے سے harden کریں، اور اس کے بعد login noise کم کرنے کے لیے Ubuntu 24.04 پر fail2ban شامل کریں۔ ہر service کو اپنا least-privilege account دیں تاکہ اگلا foothold root foothold نہ بن سکے۔
7. پرانے server کو power off کریں، اور investigation اور abuse ticket بند ہونے تک اس کا snapshot محفوظ رکھیں۔
8. backups درست کریں۔ اگر step 3 اندازے پر مبنی تھا تو اصل سبق یہ ہے کہ آپ کی backup history اتنی مختصر تھی کہ intrusion سے پہلے کے وقت تک نہیں پہنچ سکتی تھی۔ طویل retention کے ساتھ versioned off-server backups اگلی بار صاف restore point فراہم کرتے ہیں: VPS پر restic backups دونوں سہولتیں فراہم کرتا ہے۔

اگر آپ intrusion کی تاریخ متعین نہیں کر سکتے تو محفوظ backup منتخب نہیں کر سکتے۔ ایسی صورت میں صرف وہ data restore کریں جسے آپ خود inspect کر سکتے ہوں: ایسا SQL dump جسے آپ پڑھ سکیں، یا images کی ایسی directory جس کی فہرست دیکھ سکیں۔ ہر executable کو مشتبہ سمجھیں اور اسے repositories سے دوبارہ install کریں۔

آپ کے host کی abuse notice کا مطلب

زیادہ تر لوگوں کو اپنے server کے compromised ہونے کا علم اپنی monitoring سے نہیں بلکہ provider سے ہوتا ہے۔ Hosts بیرونی سمت جانے والی network traffic دیکھتے ہیں، مثلاً دوسرے networks کے خلاف SSH brute-force، port 25 پر spam، یا reflection attack میں کسی سروس کا حصہ بننا۔ Ticket میں عموماً timestamps، ports اور flows کا ایک نمونہ شامل ہوتا ہے، ساتھ ہی گھنٹوں میں دی گئی deadline بھی ہوتی ہے۔

اس کا جواب ضرور دیں، چاہے آپ کا واحد جواب یہ ہو کہ server isolate کر دیا گیا ہے اور اسے دوبارہ build کیا جا رہا ہے۔ Ticket کا جواب نہ ملنے پر providers server کو null-route یا suspend کر دیتے ہیں، جس سے incident outage میں تبدیل ہو جاتا ہے۔ اس کے بعد report کے پیچھے موجود raw log lines طلب کریں۔ یہ timestamps آپ کی machine کے باہر record ہوئے تھے، اس لیے timeline میں یہ وہ حصہ ہیں جسے attacker edit نہیں کر سکتا تھا۔ اکثر یہ disk پر موجود کسی بھی چیز کے مقابلے میں intrusion کا وقت زیادہ درست بتاتے ہیں۔

کسی customer کے compromised server سے نمٹنا host کے لیے معمول کا کام ہے، اور اسے درست طریقے سے handle کرنا آپ کے خلاف شمار نہیں کیا جاتا۔ یہ سوال کہ VPS hosting محفوظ ہے یا نہیں زیادہ تر اس بات پر منحصر ہوتا ہے کہ customer کیا configure کرتا ہے۔ اب یہی کام آپ کو دوبارہ شروع سے کرنا ہے۔

ماہر سے رابطہ کب کریں

• سرور پر دوسرے لوگوں کا ذاتی ڈیٹا موجود تھا۔ GDPR (General Data Protection Regulation) کے تحت ذاتی ڈیٹا کی خلاف ورزی کی اطلاع بلاجواز تاخیر کے بغیر نگران اتھارٹی کو دینا ضروری ہے، اور جہاں ممکن ہو اس کا علم ہونے کے 72 گھنٹوں کے اندر اطلاع دینی ہوتی ہے۔ یہ طے کرنا کہ یہ مدت شروع ہو چکی ہے یا نہیں، قانونی کام ہے، sysadmin کا کام نہیں۔
• Payment card data دائرۂ کار میں تھا۔ card schemes منظور شدہ forensic investigator کا تقاضا کرتی ہیں، اور آپ کی اپنی غیر ضروری جانچ case کو نقصان پہنچا سکتی ہے۔
• extortion demand موجود ہے، یا آپ کا data encrypted ہو چکا ہے۔
• machine دوسرے machines تک پہنچ سکتی تھی: internal network، ایسا hypervisor، یا ایسا CI runner جس میں production credentials موجود ہوں۔ کسی group میں ایک compromised host ثابت ہونے تک پورے group کا incident سمجھا جاتا ہے۔
• آپ کو ایسا evidence درکار ہوگا جو insurance یا law enforcement کے سامنے قابلِ قبول رہے۔ snapshot لینے پر رک جائیں، مکمل disk image بنائیں، اور یہ record کریں کہ اسے کس نے اور کب handle کیا۔

اگر یہ ایک single VPS ہو جس پر آپ کی اپنی services چل رہی ہوں اور اس پر کسی دوسرے شخص کا data موجود نہ ہو، تو اوپر دیا گیا playbook ہی مکمل کارروائی ہے۔ provider پر اسے isolate کریں۔ evidence کے لیے snapshot لیں۔ جو data ابھی trustworthy ہے اسے collect کریں۔ ہر credential اور key rotate کریں۔ clean rebuild کریں۔

FAQ

کیا میں hacked VPS کو دوبارہ بنانے کے بجائے صاف کر سکتا ہوں؟

اعتماد کے ساتھ نہیں، کیونکہ آپ breached نظام ہی سے اس کے بارے میں رپورٹ طلب کر رہے ہوں گے۔ تبدیل کیا گیا ps کسی process کو چھپا سکتا ہے، /etc/ld.so.preload کی ایک line آپ کے چلائے ہوئے ہر dynamically linked tool میں code شامل کر سکتی ہے، اور kernel module بیک وقت ہر program سے files چھپا سکتا ہے۔ آپ مشتبہ چیزیں تلاش کر سکتے ہیں، اس لیے کوئی hit اہم ہوتا ہے۔ لیکن آپ یہ ثابت نہیں کر سکتے کہ کچھ موجود نہیں، اس لیے clean نتیجہ قابلِ اعتماد نہیں ہوتا۔ Cleaning صرف اسی وقت قابلِ دفاع ہے جب server پر ایسی کوئی چیز نہ ہو جس کی آپ کو فکر ہو، اور آپ یہ قبول کرتے ہوں کہ وہ دوبارہ compromised ہو سکتا ہے۔

کیا مجھے compromised server کو power off کرنا چاہیے یا اسے چلتا رہنے دینا چاہیے؟

پہلے provider کے ذریعے اس کا network منقطع کریں، پھر اسے اتنی دیر چلتا رہنے دیں کہ snapshot لے سکیں اور running processes دیکھ سکیں۔ Power off کرنے سے process list ختم ہو جاتی ہے، اور جب /var/log/journal موجود نہ ہو تو journal بھی مکمل طور پر ضائع ہو جاتا ہے، کیونکہ journald اس صورت میں /run کے تحت memory میں لکھتا ہے۔ اگر server دوسرے networks پر فعال حملہ کر رہا ہو اور آپ اس کے outbound traffic کو block نہ کر سکتے ہوں تو اسے بہرحال power off کر دیں۔ نقصان روکنا evidence محفوظ رکھنے سے زیادہ اہم ہے۔

میں کیسے معلوم کروں کہ attacker کب اندر داخل ہوا؟

/var/log/auth.log یا journal میں سب سے ابتدائی Accepted password یا Accepted publickey line تلاش کریں جس کی آپ وضاحت نہیں کر سکتے۔ اس کا change-time listing، find / -xdev -newerct 'YYYY-MM-DD' -type f سے تقابل کریں، کیونکہ ctime کو mtime کے مقابلے میں جعل سازی کرنا زیادہ مشکل ہے۔ پھر دونوں کا تقابل provider کے abuse ticket میں موجود timestamps سے کریں۔ یہ timestamps machine کے باہر ریکارڈ کیے گئے تھے اور ان میں ترمیم نہیں کی جا سکتی تھی۔ ان تین تاریخوں میں سب سے ابتدائی تاریخ سے پرانا backup منتخب کریں۔ اگر کچھ بھی مطابقت نہ رکھتا ہو تو فرض کریں کہ compromise آپ کی backup history سے بھی پرانا ہے، اور صرف وہ data restore کریں جس کا آپ معائنہ کر سکتے ہیں۔

کیا compromise کے بعد میرے backups restore کرنے کے لیے محفوظ ہیں؟

معائنے کے بعد عموماً data محفوظ ہوتا ہے۔ System files محفوظ نہیں ہوتیں۔ Intrusion کے بعد لیا گیا backup backdoor پر مشتمل ہوتا ہے، اس لیے پورا root filesystem restore کرنے سے attacker بھی واپس آ جاتا ہے۔ Backup repository کا بھی معائنہ کریں: اگر اس کے credentials compromised server پر محفوظ تھے تو history حذف یا تبدیل کی جا سکتی تھی۔ یہی append-only یا pull-based backup targets استعمال کرنے کی وجہ ہے۔ Application data restore کریں، پھر distribution repositories سے software دوبارہ install کریں۔

کیا مجھے کسی کو بتانا ہوگا کہ میرا VPS compromised ہو گیا تھا؟

اپنے host کے abuse notice کا ہمیشہ جواب دیں۔ اس کے علاوہ معاملہ اس بات پر منحصر ہے کہ machine پر کس کا data موجود تھا۔ دوسرے لوگوں سے متعلق personal data قانونی reporting duty پیدا کر سکتا ہے، مثلاً GDPR کے تحت supervisory authority کو 72-hour notification دینا لازم ہو سکتا ہے۔ اگر server پر user credentials محفوظ تھے تو ان users کو بتائیں تاکہ وہ دوسری جگہوں پر passwords تبدیل کر سکیں۔ اگر box پر موجود keys نے third-party systems، مثلاً code host یا cloud account، تک رسائی مجاز بنائی تھی تو ان providers کو اطلاع دیں تاکہ وہ misuse کی جانچ کر سکیں۔ ایسا خالصتاً ذاتی server جس پر کسی اور کا data موجود نہ ہو، abuse ticket کے علاوہ کوئی اضافی ذمہ داری عائد نہیں کرتا۔