VPS हैक होने पर क्या करें? सुरक्षित रिकवरी गाइड

हैक किए गए VPS को क्लीन न करें

यदि आपका VPS हैक हो गया है, तो सबसे महत्वपूर्ण निर्णय वह है जो आप कोई भी कमांड चलाने से पहले लेते हैं। मशीन को क्लीन करने का प्रयास न करें। इसे प्रोवाइडर के स्तर पर आइसोलेट करें, साक्ष्य के रूप में डिस्क का स्नैपशॉट लें, इसमें मौजूद प्रत्येक क्रेडेंशियल को रोटेट करें, और फिर अपने भरोसेमंद स्रोतों से एक नए सर्वर पर इसे फिर से बनाएं।

आप यह साबित नहीं कर सकते कि rootkit हट गया है, क्योंकि जिन टूल्स से आप इसे साबित करेंगे, वे वही टूल्स हैं जिन्हें हमलावर नियंत्रित करता है।

यही पूरा तर्क है। इसके पीछे की कार्यप्रणाली यहाँ दी गई है। एक हमलावर जो root तक पहुँच गया है, वह ps को बदल सकता है ताकि एक process ID कभी भी इसके आउटपुट में दिखाई न दे। /etc/ld.so.preload की एक लाइन बॉक्स पर मौजूद हर dynamically linked प्रोग्राम में हमलावर का कोड लोड कर देती है, इसलिए ls, ss और find सभी एक ही तरीके से झूठ बोलते हैं। एक loadable kernel module सिस्टम कॉल के नीचे फाइलों को छिपा सकता है, इसलिए एक नई डाउनलोड की गई बाइनरी भी डिस्क को क्लीन ही देखती है। आप माइनर को डिलीट करते हैं, CPU ग्राफ नीचे आता है, और सर्वर शांत हो जाता है। शांत दिखना ही एक सक्रिय backdoor की पहचान है।

रीबिल्डिंग की लागत उतनी नहीं होती जितनी महसूस होती है। एक सामान्य VPS में कुछ पैकेज, एक कॉन्फ़िगरेशन डायरेक्टरी और एक डेटा सेट होता है, इसलिए रीबिल्ड एक सीमित कार्य है जिसका अंत निश्चित है। हमलावर द्वारा किए गए हर बदलाव को खोजना एक अंतहीन प्रक्रिया है, और इसमें कभी भी पूर्ण प्रमाण नहीं मिलता।

पुष्टि करें कि क्या सर्वर वास्तव में breach हुआ है

कई सर्वर जिन्हें हैक किया गया माना जाता है, वे वास्तव में सुरक्षित होते हैं। प्रतिदिन हजारों विफल SSH लॉगिन इंटरनेट का सामान्य शोर हैं, क्योंकि हर सार्वजनिक IPv4 पते को लगातार स्कैन किया जाता है। lastb का आउटपुट यदि root और admin प्रयासों से भरा है, तो इसका अर्थ केवल इतना है कि स्कैनर्स ने आपके पोर्ट को ढूंढ लिया है। इसका मतलब यह नहीं है कि कोई अंदर घुस गया है।

ये संकेत वास्तव में चिंताजनक हैं:

• एक सफल लॉगिन जिसका विवरण आपके पास नहीं है, जैसे कि Accepted password for root from 203.0.113.7।
• authorized_keys में कोई ऐसी key जिसे आपने नहीं जोड़ा है।
• आपके होस्ट की ओर से आपके सर्वर से बाहर जाने वाले ट्रैफिक के बारे में कोई abuse notice।
• 100% CPU पर चल रही कोई प्रक्रिया जिसका नाम किसी kernel thread से कॉपी किया गया है। Redis और Docker sockets के माध्यम से डाले गए माइनर्स अक्सर kdevtmpfsi और kinsing जैसे नामों के तहत रिपोर्ट किए जाते हैं।
• ऐसे पतों पर आउटबाउंड कनेक्शन जिनका उपयोग आपकी कोई भी सर्विस नहीं करती है।

Kernel thread के छद्म नाम की जांच करने के लिए एक त्वरित परीक्षण है। वास्तविक kernel threads वर्गाकार कोष्ठक (square brackets) के भीतर दिखाई देते हैं और उनके पीछे कोई executable नहीं होता है, इसलिए उनके लिए sudo ls -l /proc/<pid>/exe कमांड No such file or directory के साथ विफल हो जाता है। यदि [kworker/0:2] के रूप में दिखाई देने वाली किसी प्रक्रिया का exe लिंक /tmp के अंतर्गत किसी फ़ाइल की ओर इशारा करता है, तो वह एक सामान्य उपयोगकर्ता प्रोग्राम है जो kernel का नाम इस्तेमाल कर रहा है।

इन जांचों को चलाते समय यह ध्यान रखें कि सर्वर आपको गलत जानकारी दे सकता है। ये जांच यह तय करने के लिए पर्याप्त हैं कि कुछ गलत है। लेकिन ये यह सुनिश्चित करने के लिए पर्याप्त नहीं हैं कि सब कुछ सुरक्षित है।

नेटवर्क को प्रोवाइडर स्तर पर काटें, सर्वर के अंदर से नहीं

आइसोलेशन सबसे पहले आता है, क्योंकि जब तक कोई और आपके सर्वर का एक्सेस रखे हुए है, तब तक उसके बाद का हर कदम व्यर्थ है। एक सक्रिय हमलावर की निगरानी में लॉग पढ़ना, कीज़ (keys) बदलना और डेटा रिस्टोर करना निरर्थक है।

इसे अपने प्रोवाइडर के कंट्रोल पैनल में करें, उस नेटवर्क फायरवाल का उपयोग करके जो आपके ऑपरेटिंग सिस्टम के बाहर चलती है। इनबाउंड और आउटबाउंड ट्रैफिक को ब्लॉक करें, और वेब कंसोल को ही अपना एकमात्र प्रवेश मार्ग बनाए रखें। वहां लागू किए गए नियम डिस्क पर होने वाली किसी भी गतिविधि से सुरक्षित रहते हैं।

सर्वर के अंदर से ऐसा न करने के दो कारण हैं। एक कॉम्प्रोमाइज्ड कर्नल के अंदर आप जो फायरवाल कॉन्फ़िगर करते हैं, उसे वही कर्नल लागू करता है, और root यूजर उतनी ही आसानी से nftables को फ्लश कर सकता है जितनी आसानी से आप उसे लिख सकते हैं। और SSH पर sudo ip link set enp1s0 down चलाने से आपका अपना सेशन पहले कट जाता है, जिससे आप उस मशीन से बाहर हो जाते हैं जिसे आप जांच रहे थे।

इनबाउंड के साथ-साथ आउटबाउंड को भी ब्लॉक करें। एक रिवर्स शेल आपके बॉक्स से हमलावर की ओर डायल करता है, इसलिए केवल इनबाउंड ब्लॉक करने से पहले से स्थापित कनेक्शन पूरी तरह काम करता रहता है। यदि आपका प्रोवाइडर केवल इनबाउंड नियम प्रदान करता है, तो शेष विकल्प नेटवर्क इंटरफ़ेस को अलग करना या इंस्टेंस को पावर ऑफ करना है।

अभी रीबूट न करें। पहले जांचें कि क्या /var/log/journal मौजूद है। यदि वह डायरेक्टरी अनुपस्थित है, तो journald /run/log/journal में लिख रहा है, जो मेमोरी में रहता है, इसलिए रीबूट करने पर घुसपैठ का रिकॉर्ड मिट जाएगा। रीबूट करने पर चल रही प्रक्रियाएं भी गायब हो जाती हैं, और उनकी कमांड लाइन अक्सर सबसे स्पष्ट सबूत होती है जो आपको मिल सकती है।

किसी भी बदलाव से पहले डिस्क का स्नैपशॉट लें

यहाँ स्नैपशॉट और बैकअप अलग-अलग काम करते हैं। आप जो स्नैपशॉट अभी ले रहे हैं, वह एक compromised डिस्क की कॉपी है: यह आपका सबूत है, और यही एकमात्र तरीका है जिससे आप गलती से कुछ ओवरराइट करने के बाद वापस पुरानी स्थिति में आ सकते हैं। आपके पुराने बैकअप रिकवरी का रास्ता हैं। यदि आपके प्रोवाइडर का पैनल इन दोनों शब्दों का ढीले ढंग से उपयोग करता है, तो पहले VPS स्नैपशॉट और वास्तविक बैकअप में क्या अंतर है पढ़ें, क्योंकि रिटेंशन नियम और रिस्टोर करने का व्यवहार एक समान नहीं होते हैं।

दोबारा लॉग इन करने से पहले प्रोवाइडर पैनल से स्नैपशॉट लें। एक लाइव स्नैपशॉट 'क्रैश कंसिस्टेंट' होता है: यह डिस्क को उसी क्षण की स्थिति में कैप्चर करता है, जैसे कि पावर बंद कर दी गई हो। सबूत के लिए यह पर्याप्त है। इसे ऐसा नाम दें कि कोई गलती से इसे रिस्टोर न कर दे। COMPROMISED-do-not-restore-2026-08-12 जैसा स्पष्ट नाम ही सबसे उपयुक्त है। इसे तब तक रखें जब तक आपकी जांच पूरी न हो जाए और आपके होस्ट के साथ कोई भी एब्यूज टिकट बंद न हो जाए।

SSH न होने पर एक्सेस कैसे प्राप्त करें

इसके दो रास्ते हैं, दोनों ही provider panel में उपलब्ध हैं। Web console (VNC या serial) मशीन से ऐसे जुड़ता है जैसे आपने कीबोर्ड लगाया हो। यह तब काम करता है जब sshd बंद हो, firewall गलत हो, या हमलावर ने SSH port बदल दिया हो। यह local password से authenticate करता है, इसलिए key-only सर्वर पर console का उपयोग करने से पहले root password reset करना पड़ सकता है।

Rescue mode बेहतर विकल्प है। यह एक छोटा live system बूट करता है जिसमें आपकी डिस्क जुड़ी होती है लेकिन चल नहीं रही होती, इसलिए आपके commands भरोसेमंद होते हैं: compromised kernel और compromised binaries निष्पादित नहीं हो रहे होते। डिस्क को read-only मोड में mount करें।

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

यदि lsblk साधारण partition के बजाय LVM (logical volume manager) volumes दिखाता है, तो उन्हें पहले sudo vgchange -ay के साथ activate करें, फिर उस device को mount करें जो /dev/mapper/ के अंतर्गत दिखाई देता है।

आस-पास देखने के लिए mounted डिस्क में chroot न करें। Chroot हमलावर की binaries को आपकी अनुमतियों के साथ निष्पादित करता है, जो rescue mode में बूट करने के पूरे उद्देश्य को ही खत्म कर देता है।

विश्वसनीय साक्ष्य एकत्र करें

इन्हें rescue mode से चलाएं, जहाँ डिस्क को /mnt/victim पर read-only मोड में mount किया गया हो। logins से शुरुआत करें, क्योंकि इनसे घुसपैठ का समय पता चलता है, और एक बार समय का पता चलने पर बाकी सब कुछ आसान हो जाता है।

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 में लॉग करता है, जिसे journalctl -D लाइन पढ़ती है। ध्यान देने वाली बात यह है कि क्या लॉग्स में कोई अंतराल है या कोई लॉग फाइल शून्य बाइट्स की हो गई है। लॉग्स को मिटाना एक सामान्य और अक्सर भद्दी प्रक्रिया है।

इसके बाद 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 लाइन उन सभी accounts को प्रिंट करती है जिनका user ID 0 है। इस आउटपुट में root के अलावा कुछ भी दिखना एक दूसरा root account होने का संकेत है। find पैटर्न जानबूझकर authorized_keys2 से भी मेल खाता है, क्योंकि OpenSSH डिफ़ॉल्ट रूप से दोनों फाइल नामों को पढ़ता है और दूसरी फाइल को नजरअंदाज करना आसान है। यदि lsattr एट्रिब्यूट लिस्ट में i प्रिंट करता है, तो फाइल immutable है: हमलावर यह फ्लैग सेट कर देते हैं ताकि आपकी key हटाने की कोशिश Operation not permitted के साथ विफल हो जाए, और एक थका हुआ admin यह मान ले कि बदलाव सफल रहा।

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 सिस्टम पर /etc/ld.so.preload मौजूद नहीं होता, इसलिए No such file or directory एक सामान्य परिणाम है और इसमें कोई भी सामग्री आपकी विशेष जाँच की हकदार है। एक login फाइल जो base64 -d आउटपुट को shell में पाइप करती है, वह भी समान स्थिति है: वैध कॉन्फ़िगरेशन को अपना टेक्स्ट छिपाने की आवश्यकता नहीं होती।

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 को किसी भी ऐसे मान पर सेट कर सकता है जो हमलावर चाहे, इसलिए mtime झूठ बोल सकता है। Change time (ctime) inode में किसी भी बदलाव पर अपडेट होता है, और touch इसे पीछे नहीं ले जा सकता, इसलिए -newerct हाल ही में लिखी गई फाइलों की अधिक सटीक सूची देता है। यह अभी भी पूर्ण प्रमाण नहीं है, क्योंकि root सिस्टम क्लॉक को बदल सकता है या सीधे block device पर लिख सकता है।

Package integrity के लिए एक कमांड और एक चेतावनी महत्वपूर्ण है। एक live सिस्टम पर sudo dpkg --verify उन सभी packaged फाइलों के लिए एक लाइन प्रिंट करता है जिनका checksum अब मेल नहीं खाता, जिसमें checksum कॉलम में 5 होता है, और sudo debsums -ac भी यही काम करता है, जिसमें debsums पैकेज इंस्टॉल होने पर कॉन्फ़िगरेशन फाइलें भी शामिल होती हैं। परिणाम को केवल एक दिशा में पढ़ें। एक बदला हुआ /usr/sbin/sshd वास्तविक साक्ष्य है। एक clean रिपोर्ट कुछ भी साबित नहीं करती, क्योंकि जिस root account ने binary को बदला है, वही /var/lib/dpkg/info/ के तहत checksum सूचियों को भी फिर से लिख सकता है। rkhunter और chkrootkit जैसे rootkit scanners भी इसी नियम का पालन करते हैं: एक hit जानकारी है, लेकिन एक clean run का मतलब यह नहीं है कि सिस्टम सुरक्षित है।

कुछ भी विनाशकारी करने से पहले जो कुछ भी आपने एकत्र किया है, उसकी एक प्रति मशीन से बाहर सुरक्षित रख लें।

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 को सर्वर से बाहर कहीं लिख लें। यदि यह कभी बीमा दावा या पुलिस रिपोर्ट का मामला बनता है, तो यह दिखाना कि संग्रह (archive) एकत्र करने के बाद से बदला नहीं है, साक्ष्य और फाइलों के एक फोल्डर के बीच का अंतर है। जाँच के दौरान गलती से चीजों को हटा देना सामान्य है, और snapshot के साथ यह संग्रह ही वह चीज है जो इसे सुरक्षित बनाती है। बाद में किसी गलत rm को सुधारना लोगों की अपेक्षा से कहीं अधिक कठिन होता है, जैसा कि rm -rf से हटाई गई फाइलों को रिकवर करना में समझाया गया है।

उस रास्ते का पता लगाएँ जहाँ से वे अंदर आए

एक rebuild जो प्रवेश के रास्ते को बंद नहीं करता, वह आपको कुछ ही दिनों में फिर से compromised स्थिति में डाल देगा, क्योंकि जिस scan ने आपको पहली बार ढूंढा था, वह कभी रुकता नहीं है। चार मुख्य रास्ते अधिकांश single-server compromises के लिए जिम्मेदार होते हैं।

SSH password login. किसी ऐसे address से आया Accepted password for root line अपने आप में ही उत्तर है जिसे आप नहीं पहचानते। /etc/ssh/sshd_config में और /etc/ssh/sshd_config.d/ के अंतर्गत हर file में PasswordAuthentication की जाँच करें। sshd किसी keyword के लिए प्राप्त पहले मान का उपयोग करता है, और Ubuntu पर मुख्य file में Include line सबसे ऊपर होती है, इसलिए बाद में डाली गई config file चुपचाप उस setting पर हावी हो जाती है जिसे आपने नीचे edit किया था।

बिना authentication के publish की गई service. 6379 पर Redis, 2375 पर Docker API, या 127.0.0.1 के बजाय 0.0.0.0 पर bind किया गया database। Docker अक्सर आश्चर्य का कारण बनता है। Container port को publish करने से DNAT (destination network address translation) rules insert हो जाते हैं, जिनका मूल्यांकन ufw की chains से पहले किया जाता है, इसलिए ufw status एक port को blocked दिखा सकता है जबकि उसके पीछे का container पूरे internet को जवाब दे रहा होता है। Rebuild से पहले इसे समझें: Docker द्वारा publish किए गए ports ufw को कैसे bypass करते हैं में rule ordering और इसके समाधान के बारे में बताया गया है।

एक unpatched web application. अपने सबसे शुरुआती संदिग्ध timestamp के आसपास web server access log में किसी upload path या admin path पर POST request खोजें, फिर 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 से दूर रखना आवश्यक है।

यदि इन सबके बाद भी आप उस रास्ते का पता नहीं लगा पाते, तो मान लें कि credential leak हुआ है और machine में मौजूद हर secret को public समझें।

मशीन द्वारा देखे जा सकने वाले प्रत्येक क्रेडेंशियल को रोटेट करें

नेटवर्क कट जाने के बाद ही रोटेट करें, उससे पहले कभी नहीं। हमलावर के पास कनेक्शन रहने के दौरान रोटेट करने से आप उन्हें नए सीक्रेट्स सौंप देते हैं।

• सर्वर पर संग्रहीत प्रत्येक SSH private key, और साथ ही अन्य जगहों के वे सभी अकाउंट जो संबंधित public key पर भरोसा करते थे।
• कोई भी की (key) जिसे आपने ssh -A के साथ बॉक्स में फॉरवर्ड किया था। Agent forwarding, /tmp के अंतर्गत एक सॉकेट छोड़ देता है, और उस मशीन पर root, आपकी की (key) का उपयोग करके कहीं भी authenticate कर सकता है, जब तक आपका सेशन खुला रहता है।
• .env फाइलों में, systemd Environment= लाइनों में, CI कॉन्फ़िगरेशन में और प्रदाता क्रेडेंशियल्स में मौजूद API टोकन।
• डेटाबेस पासवर्ड, और उनका उपयोग करने वाले एप्लिकेशन अकाउंट।
• सर्वर के पास मौजूद TLS (transport layer security) private keys। सर्टिफिकेट को फिर से जारी करें और पुराने को रद्द (revoke) करें।
• टू-फैक्टर ऑथेंटिकेशन चालू करके अपना होस्टिंग अकाउंट पासवर्ड बदलें। वह पैनल आपके स्वामित्व वाले प्रत्येक सर्वर को रीबिल्ड, स्नैपशॉट और कंसोल कर सकता है, इसलिए यह वास्तविक सुरक्षा घेरा (perimeter) है।
• उस होस्ट पर शेल सेशन में टाइप किया गया कोई भी पासवर्ड, क्योंकि root टर्मिनल सेशन को होते हुए रिकॉर्ड कर सकता है।

यदि उस मशीन पर मौजूद किसी पासवर्ड का उपयोग कहीं और किया जाता है, तो उसे वहां भी बदलें। पासवर्ड का पुन: उपयोग ही वह तरीका है जिससे एक compromised VPS एक compromised ईमेल अकाउंट बन जाता है।

रीबिल्ड चेकलिस्ट

1. एक नई डिस्ट्रीब्यूशन इमेज से नया सर्वर बनाएँ। इसे compromised सर्वर के स्नैपशॉट या पूरे रूट फाइलसिस्टम के रिस्टोर से न बनाएँ।
2. डिस्ट्रीब्यूशन रिपॉजिटरी से पैकेज इंस्टॉल करें। पुरानी डिस्क से किसी भी बाइनरी को कॉपी न करें।
3. केवल डेटा रिस्टोर करें, और वह बैकअप लें जो आपकी टाइमलाइन में मिले सबसे पुराने सबूत से पहले का हो। डेटाबेस डंप, अपलोड और एप्लिकेशन स्टेट को रिस्टोर करें। /etc, /usr और पुरानी यूनिट फाइलों को छोड़ दें।
4. रोटेट किए गए सीक्रेट्स को हाथ से दर्ज करें। पुराने .env को कॉपी न करें।
5. रिस्टोर किए गए वेब कंटेंट को दोबारा सर्व करने से पहले, घुसपैठ की अवधि के दौरान जोड़ी गई फाइलों के लिए उनकी जांच करें।
6. एक्सपोज़ करने से पहले हार्डनिंग करें: केवल की-आधारित SSH, एक नॉन-रूट वर्किंग अकाउंट, एक डिफॉल्ट-डिनाय इनबाउंड फायरवॉल, और किसी भी सर्विस को जरूरत से ज्यादा पब्लिश न करें। नए VPS पर शुरुआती दस मिनट के निर्देशों का पालन करें, फिर SSH को सही ढंग से हार्डन करें, और फिर लॉगिन शोर को कम करने के लिए Ubuntu 24.04 पर fail2ban जोड़ें। प्रत्येक सर्विस को उसका अपना लीस्ट-प्रिविलेज अकाउंट दें ताकि अगला फुटहोल्ड रूट फुटहोल्ड न बन सके।
7. पुराने सर्वर को पावर ऑफ करें, और जांच तथा किसी भी अब्यूज टिकट के बंद होने तक उसका स्नैपशॉट सुरक्षित रखें।
8. बैकअप को ठीक करें। यदि चरण 3 अनुमान पर आधारित था, तो असली सबक यह है कि आपका बैकअप इतिहास घुसपैठ के समय से पहले तक नहीं पहुँच पा रहा था। लंबे रिटेंशन वाले वर्शन्ड ऑफ-सर्वर बैकअप अगली बार एक क्लीन रिस्टोर पॉइंट सुनिश्चित करते हैं: VPS पर restic बैकअप आपको ये दोनों सुविधाएँ देता है।

यदि आप घुसपैठ की तारीख का पता नहीं लगा सकते हैं, तो आप सुरक्षित बैकअप नहीं चुन सकते। उस स्थिति में केवल वही डेटा रिस्टोर करें जिसे आप आंखों से देख सकते हैं: एक SQL डंप जिसे आप पढ़ सकते हैं, या इमेज की एक डायरेक्टरी जिसे आप लिस्ट कर सकते हैं। हर निष्पादन योग्य (executable) फाइल को संदिग्ध मानें और उसे रिपॉजिटरी से दोबारा इंस्टॉल करें।

आपके होस्ट से प्राप्त abuse notice का क्या अर्थ है

ज्यादातर लोग तब जानते हैं कि उनका सर्वर compromised हो गया है जब उन्हें अपने प्रदाता (provider) से सूचना मिलती है, न कि अपनी खुद की मॉनिटरिंग से। होस्ट outbound traffic को देखते हैं: अन्य नेटवर्क के खिलाफ SSH brute force, port 25 पर spam, या reflection attack में हिस्सेदारी। टिकट में आमतौर पर timestamps, ports और flows का एक नमूना होता है, साथ ही घंटों में मापी गई एक समय-सीमा (deadline) भी होती है।

इसका उत्तर दें, भले ही आपका एकमात्र जवाब यह हो कि सर्वर को isolate कर दिया गया है और उसे फिर से बनाया (rebuild) जा रहा है। जब किसी टिकट का उत्तर नहीं दिया जाता है, तो प्रदाता सर्वर को null-route कर देते हैं या suspend कर देते हैं, जिससे आपकी घटना एक outage में बदल जाती है। इसके बाद रिपोर्ट के पीछे की raw log lines मांगें। वे timestamps आपकी मशीन के बाहर रिकॉर्ड किए गए थे, इसलिए वे timeline का वह हिस्सा हैं जिसे हमलावर बदल नहीं सकता था, और वे अक्सर disk पर मौजूद किसी भी चीज़ की तुलना में intrusion की तारीख बेहतर तरीके से बताते हैं।

एक compromised customer server होस्ट के लिए नियमित काम है, और इसे अच्छी तरह से संभालना आपके खिलाफ नहीं जाता है। क्या VPS hosting सुरक्षित है का व्यापक प्रश्न मुख्य रूप से इस बात पर निर्भर करता है कि ग्राहक क्या configure करता है, जो कि बिल्कुल वही हिस्सा है जिसे अब आपको फिर से शून्य से करना है।

पेशेवर की सहायता कब लें

• सर्वर पर अन्य लोगों का व्यक्तिगत डेटा मौजूद था। GDPR (General Data Protection Regulation) के तहत, व्यक्तिगत डेटा के उल्लंघन (breach) की सूचना पर्यवेक्षी प्राधिकरण को बिना किसी अनुचित देरी के दी जानी चाहिए, और यदि संभव हो तो इसके बारे में पता चलने के 72 घंटों के भीतर दी जानी चाहिए। यह तय करना कि यह समय-सीमा कब शुरू हुई है, कानूनी कार्य है, न कि sysadmin का कार्य।
• भुगतान कार्ड डेटा (payment card data) दायरे में था। कार्ड स्कीमों के लिए एक अनुमोदित फॉरेंसिक जांचकर्ता की आवश्यकता होती है, और आपकी अपनी जांच-पड़ताल मामले को नुकसान पहुंचा सकती है।
• फिरौती की मांग की गई है, या आपका डेटा एन्क्रिप्ट कर दिया गया है।
• मशीन अन्य मशीनों तक पहुंच सकती थी: एक आंतरिक नेटवर्क, एक हाइपरवाइजर, या प्रोडक्शन क्रेडेंशियल्स रखने वाला CI रनर। जब तक अन्यथा सिद्ध न हो जाए, तब तक एक समूह में एक breached होस्ट को पूरे समूह की घटना माना जाता है।
• आपको बीमा या कानून प्रवर्तन के लिए साक्ष्य को सुरक्षित रखने की आवश्यकता होगी। स्नैपशॉट पर रुकें, पूरी डिस्क की इमेज लें, और रिकॉर्ड करें कि इसे किसने और कब संभाला।

अपने स्वयं के services चलाने वाले एक एकल VPS के लिए, जिस पर किसी और का डेटा नहीं है, ऊपर दिया गया playbook ही पूरा कार्य है। प्रदाता (provider) स्तर पर isolate करें। साक्ष्य के लिए स्नैपशॉट लें। जो अभी भी विश्वसनीय है उसे एकत्र करें। सब कुछ rotate करें। साफ-सुथरे तरीके से फिर से rebuild करें।

FAQ

क्या मैं हैक किए गए VPS को फिर से बनाने के बजाय उसे साफ (clean) कर सकता हूँ?

पूरी तरह से आश्वस्त होकर ऐसा नहीं किया जा सकता, क्योंकि आप एक compromised सिस्टम से ही उसके बारे में जानकारी मांग रहे होंगे। एक बदला हुआ ps किसी प्रोसेस को छिपा सकता है, /etc/ld.so.preload की एक लाइन आपके द्वारा चलाए जाने वाले हर dynamically linked टूल में कोड इंजेक्ट कर सकती है, और एक kernel module एक साथ सभी प्रोग्रामों से फाइलों को छिपा सकता है। यदि आपको कुछ मिल जाता है, तो वह एक ठोस सबूत है। लेकिन आप यह साबित नहीं कर सकते कि सिस्टम में कुछ भी गलत नहीं है, इसलिए 'साफ' परिणाम का कोई अर्थ नहीं है। सफाई तभी उचित है जब सर्वर पर आपके लिए कोई महत्वपूर्ण डेटा न हो और आप यह स्वीकार करें कि वह फिर से compromised हो सकता है।

क्या मुझे compromised सर्वर को बंद कर देना चाहिए या उसे चलते रहने देना चाहिए?

सबसे पहले प्रदाता (provider) के स्तर पर उसका नेटवर्क काट दें, फिर snapshot लेने और चल रही प्रक्रियाओं (running processes) को देखने के लिए उसे पर्याप्त समय तक चालू रखें। सर्वर को बंद करने से प्रोसेस लिस्ट नष्ट हो जाती है, और यदि /var/log/journal मौजूद न हो तो journal पूरी तरह से डिलीट हो जाता है, क्योंकि तब journald डेटा को /run के तहत मेमोरी में लिखता है। यदि सर्वर सक्रिय रूप से अन्य नेटवर्क पर हमला कर रहा है और आपके पास उसके आउटबाउंड ट्रैफिक को रोकने का कोई तरीका नहीं है, तो उसे तुरंत बंद कर दें। नुकसान को रोकना सबूतों को सुरक्षित रखने से अधिक महत्वपूर्ण है।

मुझे कैसे पता चलेगा कि हमलावर ने कब प्रवेश किया?

/var/log/auth.log या journal में ऐसी सबसे पुरानी Accepted password या Accepted publickey लाइन खोजें जिसे आप समझा न सकें। इसकी तुलना find / -xdev -newerct 'YYYY-MM-DD' -type f के साथ करें, क्योंकि ctime को mtime की तुलना में बदलना कठिन होता है। फिर इन दोनों की तुलना अपने प्रदाता के abuse ticket में दिए गए टाइमस्टैम्प से करें, जिन्हें मशीन के बाहर रिकॉर्ड किया गया था और जिन्हें बदला नहीं जा सकता था। इन तीनों तारीखों में से जो सबसे पुरानी हो, उससे पहले का बैकअप चुनें। यदि कुछ भी मेल नहीं खाता है, तो मान लें कि compromise आपके बैकअप इतिहास से भी पुराना है और केवल उसी डेटा को रिस्टोर करें जिसे आप जांच सकते हैं।

क्या compromise के बाद मेरे बैकअप रिस्टोर करने के लिए सुरक्षित हैं?

जांच करने पर डेटा आमतौर पर सुरक्षित होता है, लेकिन सिस्टम फाइलें नहीं। घुसपैठ के बाद लिए गए बैकअप में backdoor शामिल होता है, इसलिए पूरे root filesystem को रिस्टोर करने का मतलब है हमलावर को भी वापस लाना। बैकअप रिपॉजिटरी की भी जांच करें: यदि इसके क्रेडेंशियल्स compromised सर्वर पर स्टोर थे, तो इतिहास को डिलीट या बदला जा सकता है। यही कारण है कि append-only या pull-based बैकअप लक्ष्यों का उपयोग करने की सलाह दी जाती है। केवल एप्लिकेशन डेटा रिस्टोर करें, और फिर सॉफ्टवेयर को डिस्ट्रीब्यूशन रिपॉजिटरी से दोबारा इंस्टॉल करें।

क्या मुझे किसी को बताना होगा कि मेरा VPS compromised हो गया है?

अपने होस्ट के abuse notice का जवाब हमेशा दें। इसके अलावा, यह इस बात पर निर्भर करता है कि मशीन पर किसका डेटा था। अन्य लोगों के व्यक्तिगत डेटा के मामले में कानूनी रिपोर्टिंग का दायित्व हो सकता है, जैसे कि GDPR के तहत 72 घंटे के भीतर पर्यवेक्षी प्राधिकरण (supervisory authority) को सूचित करना। यदि सर्वर पर यूजर क्रेडेंशियल्स स्टोर थे, तो उन यूजर्स को बताएं ताकि वे अन्य जगहों पर पासवर्ड बदल सकें। यदि सर्वर पर मौजूद keys ने किसी तीसरे पक्ष के सिस्टम, जैसे कि कोड होस्ट या क्लाउड अकाउंट तक पहुंच प्रदान की थी, तो उन प्रदाताओं को सूचित करें ताकि वे दुरुपयोग की जांच कर सकें। यदि सर्वर पूरी तरह से व्यक्तिगत है और उस पर किसी और का डेटा नहीं है, तो abuse ticket के अलावा कोई अन्य दायित्व नहीं है।