VPS हॅक झाल्यावर काय करावे? स्वच्छ करू नका

हॅक झालेला VPS स्वच्छ करण्याचा प्रयत्न करू नका

तुमचा VPS हॅक झाला असल्यास, कोणतीही command चालवण्यापूर्वी घेतलेला निर्णय सर्वात महत्त्वाचा असतो. मशीन स्वच्छ करण्याचा प्रयत्न करू नका. Provider स्तरावर ते isolate करा, पुरावा म्हणून disk चा snapshot घ्या, त्या मशीनवर उपलब्ध असलेली प्रत्येक credential बदला आणि तुमचा विश्वास असलेल्या sources मधून fresh server वर पुन्हा build करा.

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 च्या खाली files लपवू शकतो. त्यामुळे नुकतीच download केलेली binary देखील disk स्वच्छ असल्याचे दाखवू शकते. तुम्ही miner delete करता, CPU graph खाली येतो आणि server शांत होतो. कार्यरत backdoor साठीही अशीच शांत स्थिती दिसते.

Rebuild करण्याचा खर्च प्रत्यक्षात वाटतो त्यापेक्षा कमी असतो. सामान्य VPS मध्ये काही packages, एक config directory आणि एक data set एवढेच असतात. त्यामुळे rebuild हे शेवट असलेले मर्यादित काम असते. Attacker ने केलेला प्रत्येक बदल शोधण्याचे काम मात्र अमर्यादित असते आणि त्यातून कधीही खात्रीशीर पुरावा मिळत नाही.

प्रत्यक्ष उल्लंघन झाले आहे याची खात्री करा

हॅक झाल्याचे कळवलेले अनेक सर्व्हर प्रत्यक्षात तडजोड झालेले नसतात. दररोज होणारे हजारो अयशस्वी SSH लॉगिन प्रयत्न हे इंटरनेटवरील नेहमीचे पार्श्वभूमीतील स्कॅनिंग असते, कारण प्रत्येक सार्वजनिक IPv4 पत्त्याचे सतत स्कॅनिंग केले जाते. lastb च्या output मध्ये root आणि admin प्रयत्न मोठ्या प्रमाणात दिसत असतील, तर स्कॅन करणाऱ्यांना तुमचा port सापडला आहे. याचा अर्थ कोणी सर्व्हरमध्ये प्रवेश केला आहे असा होत नाही.

खालील संकेत मात्र महत्त्वाचे आहेत:

• तुम्ही स्पष्ट करू शकत नसलेले यशस्वी लॉगिन, जसे की Accepted password for root from 203.0.113.7.
• तुम्ही न जोडलेली key authorized_keys मध्ये आढळणे.
• तुमच्या सर्व्हरकडून बाहेर जाणाऱ्या traffic विषयी host कडून आलेली गैरवापराची सूचना.
• 100% CPU वापरणारी process, जिचे नाव kernel thread कडून घेतल्यासारखे दिसते. उघड्या Redis आणि Docker sockets द्वारे प्रवेश केलेले miners सामान्यतः kdevtmpfsi आणि kinsing यांसारख्या नावांनी नोंदवले जातात.
• तुमच्या कोणत्याही सेवेकडून न वापरल्या जाणाऱ्या पत्त्यांकडे जाणारे outbound connections.

Kernel thread चे सोंग घेतले आहे का, यासाठी एक जलद चाचणी आहे. खरे kernel threads square brackets मध्ये दिसतात आणि त्यांच्यामागे executable नसते. त्यामुळे sudo ls -l /proc/<pid>/exe त्यांच्यासाठी No such file or directory सह अपयशी ठरते. [kworker/0:2] म्हणून दिसणाऱ्या process कडे exe link असून तो /tmp अंतर्गत एखाद्या ठिकाणी निर्देश करत असेल, तर ती kernel नाव धारण करणारी सामान्य user program आहे.

हे checks चालवताना सर्व्हरवरील system तुमची दिशाभूल करत असण्याची शक्यता लक्षात ठेवा. काहीतरी चुकीचे आहे हे ठरवण्यासाठी ते पुरेसे आहेत. काहीही चुकीचे नाही हे ठरवण्यासाठी ते पुरेसे नाहीत.

प्रदाता स्तरावर नेटवर्क बंद करा, सर्व्हरच्या आतून नाही

प्रत्येक गोष्टीपूर्वी विलगीकरण करा. दुसऱ्या व्यक्तीकडे अजूनही shell access असेल, तर त्यानंतरची प्रत्येक कृती व्यर्थ ठरते. logs वाचणे, keys फिरवणे आणि data restore करणे यांना अर्थ राहत नाही, कारण हल्लेखोर ते सर्व पाहत असतो.

हे तुमच्या provider च्या control panel मध्ये करा. तुमच्या operating system च्या बाहेर चालणाऱ्या network firewall मध्ये नियम लागू करा. inbound आणि outbound दोन्ही traffic नाकारा आणि प्रवेशासाठी web console वापरा. तेथे लागू केलेले नियम disk वर काहीही घडले तरी टिकून राहतात.

हे server च्या आतून न करण्याची दोन कारणे आहेत. compromised kernel मध्ये configure केलेला firewall त्याच kernel कडून लागू केला जातो. root तुमच्याइतकेच सहज nftables चे नियम flush करू शकतो. तसेच sudo ip link set enp1s0 down over SSH केल्यास तुमचे स्वतःचे session आधी बंद होते आणि तुम्ही तपासत असलेल्या machine मधूनच बाहेर पडता.

inbound प्रमाणे outbound traffic देखील block करा. reverse shell तुमच्या box मधून हल्लेखोराकडे बाहेरून connection सुरू करते. त्यामुळे फक्त inbound block केल्यास स्थापित connection पूर्णपणे कार्यरत राहते. तुमचा provider फक्त inbound rules देत असल्यास, उरलेले पर्याय म्हणजे network interface detach करणे किंवा instance बंद करणे.

अजून reboot करू नका. प्रथम /var/log/journal अस्तित्वात आहे का ते तपासा. ती directory नसल्यास journald /run/log/journal मध्ये लिहित आहे. हे स्थान memory मध्ये असते. त्यामुळे reboot केल्यावर intrusion चा record नष्ट होतो. reboot वेळी चालू processes देखील नाहीसे होतात. त्यांच्या command lines अनेकदा तुम्हाला मिळणारा सर्वात स्पष्ट पुरावा असतात.

काहीही बदल करण्यापूर्वी डिस्कचा snapshot घ्या

येथे snapshot आणि backup वेगवेगळी कामे करतात. तुम्ही आता घेतलेला snapshot हा breached डिस्कची प्रत आहे. तो तुमचा पुरावा आहे. चुकून काहीतरी overwrite झाल्यानंतर मागील स्थितीत परत जाण्याची एकमेव सुविधा त्यातून मिळते. जुने backups हा recovery चा मार्ग आहे. तुमच्या provider च्या panel मध्ये हे दोन शब्द सैलपणे वापरले जात असल्यास, आधी VPS snapshots आणि वास्तविक backups यांतील फरक वाचा. कारण retention चे नियम आणि restore चे वर्तन समान नसते.

पुन्हा login करण्यापूर्वी provider panel मधून snapshot घ्या. चालू प्रणालीचा snapshot crash-consistent असतो. त्या क्षणी डिस्क जशी होती तशीच ती capture केली जाते. हे वीज थेट बंद केल्यासारखे असते. पुराव्यासाठी ते योग्य आहे. snapshot ला असे नाव द्या की कोणीही तो चुकून restore करणार नाही. COMPROMISED-do-not-restore-2026-08-12 इतके स्पष्ट नाव योग्य आहे. तपासणी पूर्ण होईपर्यंत आणि 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 हा अधिक चांगला पर्याय आहे. तो disk जोडलेली, पण चालू नसलेली लहान live system सुरू करतो. त्यामुळे तुम्ही चालवलेल्या 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 तुमच्या permissions सह attacker's binaries execute करतो. त्यामुळे rescue mode सुरू करण्यामागचा संपूर्ण उद्देशच नष्ट होतो.

अजून विश्वसनीय असलेले पुरावे गोळा करा

हे commands rescue mode मधून चालवा आणि disk /mnt/victim येथे read only स्वरूपात mount करा. सर्वप्रथम logins तपासा. त्यावरून 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 images मध्ये rsyslog नसते. त्यामुळे sshd फक्त journal मध्ये logs लिहिते. journalctl -D line तेच वाचते. मात्र सलग logs मध्ये दिसणारी तफावत किंवा शून्य bytes वर truncate केलेली log file नोंदवण्यासारखी आहे. 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 user ID 0 असलेले प्रत्येक account दाखवते. त्या output मध्ये root व्यतिरिक्त काहीही असल्यास ते दुसरे root account आहे. find pattern मध्ये authorized_keys2 जाणीवपूर्वक समाविष्ट आहे. OpenSSH दोन्ही file names default ने वाचते आणि दुसरे नाव सहज दुर्लक्षित होते. lsattr attribute list मध्ये i दाखवत असल्यास file immutable आहे. Attacker तो flag सेट करतो, त्यामुळे त्याची key delete करण्याचा तुमचा प्रयत्न 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 करत असल्यास हीच बाब लागू होते. Legitimate config ला स्वतःचा 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 वर सेट करू शकते. त्यामुळे mtime सहज खोटे चित्र दाखवते. Inode मध्ये कोणताही बदल झाल्यावर change time (ctime) update होते. touch ते मागील वेळेवर नेऊ शकत नाही. त्यामुळे -newerct अलीकडे लिहिलेल्या files ची अधिक विश्वासार्ह यादी देते. तरीही हा पुरावा निश्चित नाही. root system clock बदलू शकतो किंवा block device वर थेट लिहू शकतो.

Package integrity साठी एक command आणि एक महत्त्वाची मर्यादा पुरेशी आहे. Live system वर sudo dpkg --verify अशा प्रत्येक packaged file साठी एक line दाखवते जिचा checksum जुळत नाही. Checksum column मध्ये 5 दिसते. sudo debsums -ac हेच काम config files समाविष्ट करून करते, जेव्हा debsums package installed असते. Result चे अर्थ फक्त एका दिशेने लावा. बदललेले /usr/sbin/sshd हे ठोस पुरावे आहेत. Clean report काहीही सिद्ध करत नाही. कारण binary बदलणारे तेच root account /var/lib/dpkg/info/ अंतर्गत checksum lists पुन्हा लिहू शकते. rkhunter आणि chkrootkit सारखे Rootkit scanners याच नियमाने काम करतात. Hit म्हणजे माहिती. Clean run म्हणजे system सुरक्षित असल्याचे प्रमाणपत्र नाही.

काहीही destructive करण्यापूर्वी गोळा केलेली माहिती 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 मध्ये बदल झालेला नाही हे दाखवता येणे महत्त्वाचे ठरते. त्यामुळे ते files च्या साध्या folder ऐवजी पुरावा ठरते. तपासादरम्यान चुकून files delete होणे सामान्य आहे. Snapshot आणि हा archive यामुळे अशी चूक सहन करता येते. नंतर चुकीचे rm पूर्ववत करणे लोकांच्या अपेक्षेपेक्षा खूप कठीण असते, जसे rm -rf ने delete केलेल्या files recover करणे येथे स्पष्ट केले आहे.

ज्या मार्गाने प्रवेश झाला तो शोधा

प्रवेशाचा मार्ग बंद न करता केलेल्या rebuild नंतर सर्व्हर पुन्हा compromised होतो. हे अनेकदा काही दिवसांत घडते. कारण तुम्हाला पहिल्यांदा शोधणारे scan सतत सुरू असते. एका सर्व्हरवरील बहुतेक compromises साठी चार प्रवेशमार्ग असतात.

SSH password login. तुम्हाला अपरिचित असलेल्या address कडून आलेली Accepted password for root line हे एकट्यानेच पुरेसे उत्तर आहे. /etc/ssh/sshd_config मधील /etc/ssh/sshd_config.d/ अंतर्गत असलेल्या प्रत्येक file मध्ये PasswordAuthentication तपासा. sshd एखाद्या keyword साठी मिळणारी पहिली value वापरते. Ubuntu वर मुख्य file च्या सुरुवातीला Include line असते. त्यामुळे नंतर संपादित केलेल्या setting पेक्षा drop-in config file शांतपणे लागू होते.

Authentication नसलेली प्रकाशित 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 जोडले जातात. ही rules ufw च्या chains आधी evaluate होतात. त्यामुळे ufw status एखादा port blocked असल्याचे दाखवू शकते, तरी त्यामागील container संपूर्ण internet कडून आलेल्या requests ला उत्तर देऊ शकतो. Rebuild करण्यापूर्वी हे समजून घ्या: Docker ने प्रकाशित केलेले ports ufw ला कसे bypass करतात या लेखात rule ordering आणि त्यावरील उपाय दिला आहे.

Patch न केलेले web application. सर्वात सुरुवातीच्या संशयास्पद timestamp च्या आसपास web server access log मध्ये upload path किंवा admin path कडे केलेली POST request शोधा. त्यानंतर web root अंतर्गत matching change time असलेल्या files शोधा. uploads directory मधील अनोळखी PHP file हा नेहमी दिसणारा परिणाम आहे.

गळती झालेली credential. repository मध्ये commit केलेली key, chat मध्ये paste केलेला token किंवा चुकीच्या configuration मुळे web server ने static file म्हणून serve केलेली .env file. Automation मुळे हे चुकून करणे सोपे होते. त्यामुळे AI agents आणि त्यांच्या config files पासून secrets दूर ठेवणे आवश्यक आहे.

हे सर्व केल्यानंतरही प्रवेशमार्गाचे नाव सांगता येत नसेल, तर credential गळती झाली असे गृहीत धरा. मशीनकडे असलेली प्रत्येक secret सार्वजनिक झाल्याप्रमाणे हाताळा.

मशीनला उपलब्ध असलेली प्रत्येक credentials फिरवा

नेटवर्क विभक्त केल्यानंतरच credentials फिरवा; त्यापूर्वी कधीही करू नका. आक्रमणकर्त्याचे कनेक्शन अजूनही सुरू असताना credentials फिरवल्यास नवीन secrets त्याच्या हातातच जातात.

• सर्व्हरवर साठवलेली प्रत्येक SSH private key, तसेच संबंधित public key वर विश्वास ठेवणारे इतर ठिकाणचे प्रत्येक account.
• ssh -A वापरून मशीनमध्ये forward केलेली कोणतीही key. Agent forwarding मुळे /tmp अंतर्गत एक socket तयार होतो. त्या मशीनवरील root तुमची key स्वीकारली जात असलेल्या कोणत्याही ठिकाणी तुमच्या नावाने authenticate करण्यासाठी तो socket वापरू शकतो, आणि तुमचे session सुरू असेपर्यंत हे शक्य राहते.
• .env files, systemd Environment= lines, CI configuration आणि provider credentials मधील API tokens.
• Database passwords आणि ते वापरणारे application accounts.
• सर्व्हरकडे असलेल्या TLS (transport layer security) private keys. Certificate पुन्हा issue करा आणि जुना certificate revoke करा.
• तुमच्या hosting account चा password आणि त्यावर two-factor authentication सुरू करा. त्या panel मधून तुमच्या मालकीच्या प्रत्येक server ला rebuild, snapshot आणि console access करता येतो. त्यामुळे तेच तुमचे प्रत्यक्ष perimeter आहे.
• मशीन compromised असताना त्या host वरील shell session मध्ये टाइप केलेला कोणताही password, कारण root terminal session सुरू असतानाच त्याची नोंद करू शकतो.

त्या मशीनवरील एखादा password इतर कोणत्याही ठिकाणी वापरला असल्यास, तेथेही तो बदला. Password reuse मुळे एक compromised VPS, compromised email account मध्ये बदलू शकतो.

पुनर्बांधणी तपासणीसूची

1. नवीन distribution image वापरून नवीन server तयार करा. Compromised server च्या snapshot वरून किंवा संपूर्ण root filesystem restore वरून तो तयार करू नका.
2. distribution repositories मधून packages install करा. जुन्या disk मधून कोणतीही binary copy करू नका.
3. तुमच्या timeline मधील सर्वात जुन्या पुराव्यापूर्वीच्या तारखेचा backup वापरून फक्त data restore करा. Database dumps, uploads आणि application state restore करा. /etc, /usr आणि जुन्या unit files तशाच मागे ठेवा.
4. बदललेली secrets हाताने प्रविष्ट करा. जुने .env copy करू नका.
5. restored web content पुन्हा serve करण्यापूर्वी intrusion window दरम्यान जोडलेल्या files साठी त्याची तपासणी करा.
6. server सार्वजनिकरित्या उपलब्ध करण्यापूर्वी त्याची सुरक्षा मजबूत करा: key-only SSH, root नसलेले working account, default-deny inbound firewall आणि आवश्यकतेपेक्षा व्यापकपणे प्रकाशित केलेली कोणतीही service नसावी. नवीन VPS वरील पहिली दहा मिनिटे या प्रक्रियेने सुरुवात करा, त्यानंतर SSH योग्य प्रकारे सुरक्षित करा, आणि login noise कमी करण्यासाठी Ubuntu 24.04 वर fail2ban जोडा. प्रत्येक service साठी किमान विशेषाधिकार असलेले स्वतंत्र account द्या, जेणेकरून पुढील foothold मुळे root account वर प्रवेश मिळणार नाही.
7. जुना server बंद करा आणि investigation तसेच कोणतेही abuse ticket बंद होईपर्यंत त्याचा snapshot जतन करा.
8. backups दुरुस्त करा. step 3 अंदाजावर आधारित असेल, तर intrusion च्या आधीचा काळ गाठण्यासाठी तुमचा backup history अपुरा होता, हा खरा धडा आहे. पुढच्या वेळी स्वच्छ restore point मिळवण्यासाठी दीर्घ retention असलेले versioned off-server backups आवश्यक आहेत: VPS वर restic backups दोन्ही सुविधा देते.

जर तुम्ही intrusion ची तारीख ठरवू शकत नसाल, तर सुरक्षित backup निवडता येणार नाही. अशा वेळी प्रत्यक्ष तपासता येणारे dataच restore करा: वाचता येणारा SQL dump किंवा list करता येणारी 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ही दिलेली असते.

त्या notice ला उत्तर द्या. तुमचे एकमेव उत्तर server isolate करून rebuild केला जात आहे, एवढेच असले तरी उत्तर द्या. Ticket ला उत्तर न मिळाल्यास providers server ला null-route किंवा suspend करतात. त्यामुळे तुमची incident outage मध्ये बदलते. त्यानंतर report मागील raw log lines मागवा. ते timestamps तुमच्या machine च्या बाहेर नोंदवलेले असतात. त्यामुळे timeline मधील attacker संपादित करू न शकलेला तो एकमेव भाग असतो. तसेच disk वरील इतर कोणत्याही पुराव्यापेक्षा ते intrusion ची वेळ अधिक अचूकपणे दर्शवतात.

Compromised customer server हाताळणे हे host साठी नियमित काम असते. ते योग्य प्रकारे हाताळल्यामुळे तुमच्याविरुद्ध नोंद केली जात नाही. VPS hosting सुरक्षित आहे का हा व्यापक प्रश्न मुख्यतः customer ने काय configure केले आहे यावर अवलंबून असतो. आता तोच भाग तुम्हाला पुन्हा सुरुवातीपासून करायचा आहे.

व्यावसायिक तज्ज्ञांशी कधी संपर्क साधावा

• सर्व्हरवर इतर लोकांचा वैयक्तिक डेटा होता. GDPR (General Data Protection Regulation) अंतर्गत वैयक्तिक डेटा breach झाल्यास supervisory authority ला अनावश्यक विलंब न करता कळवणे आवश्यक आहे. हे शक्य असल्यास breach ची जाणीव झाल्यापासून 72 तासांच्या आत कळवावे. तो कालावधी सुरू झाला आहे की नाही हे ठरवणे हे sysadmin चे काम नसून कायदेशीर काम आहे.
• Payment card data या घटनेच्या कक्षेत होता. Card schemes ना मान्यताप्राप्त forensic investigator आवश्यक असतो. स्वतःची अनधिकृत तपासणी केल्यास प्रकरणातील पुरावे खराब होऊ शकतात.
• Extortion ची मागणी आली आहे किंवा तुमचा डेटा encrypted झाला आहे.
• मशीनला इतर मशीनपर्यंत पोहोचता येत होते: internal network, production credentials असलेला hypervisor किंवा CI runner. समूहातील एका host वर breach झाल्यास, अन्यथा सिद्ध होईपर्यंत तो संपूर्ण समूहाचा incident मानावा.
• Insurance किंवा law enforcement साठी पुरावे ग्राह्य स्वरूपात ठेवणे आवश्यक आहे. Snapshot घेतल्यानंतर थांबा, संपूर्ण disk image घ्या आणि ते कोणी, केव्हा हाताळले याची नोंद ठेवा.

तुमच्या स्वतःच्या services चालवणाऱ्या एका VPS वर इतर कोणाचाही डेटा नसेल, तर वरील playbook एवढेच संपूर्ण काम आहे. Provider कडे मशीन isolate करा. पुराव्यासाठी snapshot घ्या. अजून विश्वासार्ह असलेली माहिती गोळा करा. सर्व credentials आणि keys rotate करा. स्वच्छ पद्धतीने rebuild करा.

FAQ

हॅक झालेला VPS पुन्हा तयार करण्याऐवजी तो स्वच्छ करू शकतो का?

पूर्ण विश्वासाने नाही, कारण तडजोड झालेल्या system कडून त्याच्याबद्दल स्वतःच अहवाल देण्याची अपेक्षा असेल. बदललेला ps एखादी process लपवू शकतो, /etc/ld.so.preload मधील एक ओळ तुम्ही चालवलेल्या प्रत्येक dynamically linked tool मध्ये code inject करू शकते आणि kernel module एकाच वेळी प्रत्येक program पासून files लपवू शकतो. तुम्हाला काही गोष्टी सापडू शकतात, त्यामुळे मिळालेला hit अर्थपूर्ण असतो. मात्र काहीही उरलेले नाही हे तुम्ही सिद्ध करू शकत नाही, त्यामुळे clean result पुरेसा पुरावा नसतो. Server वर महत्त्वाचा कोणताही data नसल्यास आणि तो पुन्हा compromised होऊ शकतो हे मान्य असल्यासच cleaning समर्थनीय आहे.

compromised server बंद करावा की सुरू ठेवावा?

प्रथम provider कडे त्याचे network disconnect करा. त्यानंतर snapshot घेण्यासाठी आणि चालू processes पाहण्यासाठी तो काही काळ सुरू ठेवा. Server बंद केल्यास process list नष्ट होते. तसेच /var/log/journal अस्तित्वात नसल्यास journal पूर्णपणे नष्ट होते, कारण journald त्यावेळी /run अंतर्गत memory मध्ये लिहितो. तो इतर networks वर सक्रियपणे हल्ले करत असेल आणि outbound traffic block करण्याचा कोणताही मार्ग नसेल, तर तो बंद करा. हानी थांबवणे हा evidence जतन करण्यापेक्षा अधिक महत्त्वाचा आहे.

attacker कधी आत शिरला हे कसे ठरवावे?

/var/log/auth.log किंवा journal मध्ये तुम्हाला समजावून सांगता येणार नाही अशी सर्वात जुनी Accepted password किंवा Accepted publickey ओळ शोधा. त्याची 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 देखील restore होतो. Backup repository स्वतःही तपासा. तिचे credentials compromised server वर साठवलेले असल्यास history delete किंवा alter केलेली असू शकते. 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 मुळे code host किंवा cloud account सारख्या third-party systems ला access मिळत असल्यास त्या providers ना कळवा, जेणेकरून ते misuse तपासू शकतील. इतर कोणाचाही data नसलेल्या पूर्णपणे वैयक्तिक server साठी abuse ticket पलीकडे कोणतीही अतिरिक्त जबाबदारी नसते.