VPS హ్యాక్ అయితే ఏం చేయాలి?

హ్యాక్‌కు గురైన VPS ను శుభ్రం చేయవద్దు

మీ VPS హ్యాక్‌కు గురైతే, మీరు ఏదైనా command అమలు చేయడానికి ముందే అత్యంత ముఖ్యమైన నిర్ణయం తీసుకోవాలి. ఆ machine ను శుభ్రం చేయడానికి ప్రయత్నించవద్దు. Provider స్థాయిలో దాన్ని isolate చేయండి, సాక్ష్యంగా disk snapshot తీసుకోండి, ఆ VPS లో ఉన్న ప్రతి credential ను మార్చండి. తరువాత మీరు విశ్వసించే sources నుంచి fresh server పై rebuild చేయండి.

Rootkit తొలగిపోయిందని నిరూపించలేరు. దాన్ని నిరూపించాల్సిన tools అన్నీ attacker నియంత్రణలో ఉండవచ్చు.

ఇదే ప్రధాన కారణం. దీని వెనుక ఉన్న విధానం ఇలా ఉంటుంది. Root ప్రాప్యత పొందిన attacker ps ను మార్చి, ఒక process ID దాని output లో ఎప్పుడూ కనిపించకుండా చేయవచ్చు. /etc/ld.so.preload లోని ఒక line system లోని ప్రతి dynamically linked program లోకి attacker code ను load చేయవచ్చు. అందువల్ల ls, ss మరియు find ఒకే విధంగా, పరస్పరం consistent గా తప్పుడు సమాచారం ఇస్తాయి. Loadable kernel module system call స్థాయికి దిగువన files ను దాచగలదు. కాబట్టి తాజాగా download చేసిన binary కూడా disk శుభ్రంగా ఉందని చూపించవచ్చు. మీరు miner ను delete చేస్తారు, CPU graph తగ్గుతుంది, server నిశ్శబ్దంగా మారుతుంది. పనిచేస్తున్న backdoor కూడా ఇలాగే నిశ్శబ్దంగా ఉంటుంది.

Rebuild ఖర్చు అనిపించినంత ఎక్కువగా ఉండదు. సాధారణ VPS లో కొన్ని packages, ఒక config directory, ఒక data set మాత్రమే ఉంటాయి. అందువల్ల rebuild కు స్పష్టమైన ముగింపు ఉన్న పరిమిత పని ఉంటుంది. Attacker చేసిన ప్రతి మార్పును గుర్తించడం మాత్రం అంతం లేని పని. దానితో ఎప్పటికీ పూర్తి నిర్ధారణకు చేరుకోలేరు.

నిజంగా compromise జరిగిందో నిర్ధారించండి

హ్యాక్ అయిందని నివేదించిన అనేక సర్వర్లు వాస్తవానికి హ్యాక్ అయి ఉండవు. రోజుకు వేలాది విఫలమైన SSH loginలు internet background noise మాత్రమే. ప్రతి public IPv4 address నిరంతరం scan చేయబడుతుంది. lastb outputలో root మరియు admin attempts ఎక్కువగా కనిపించడం అంటే scanners మీ portను కనుగొన్నాయని మాత్రమే. ఎవరైనా serverలోకి ప్రవేశించారని దాని అర్థం కాదు.

ఈ సంకేతాలు మాత్రం ముఖ్యమైనవే:

• మీరు వివరించలేని successful login, ఉదాహరణకు Accepted password for root from 203.0.113.7.
• మీరు జోడించని key authorized_keys లో ఉండటం.
• మీ server నుంచి బయటకు వెళ్తున్న traffic గురించి host అందించిన abuse notice.
• kernel thread నుంచి copy చేసిన పేరుతో 100% CPU వినియోగిస్తున్న process. Exposed Redis మరియు Docker sockets ద్వారా ప్రవేశించిన miners సాధారణంగా kdevtmpfsi మరియు kinsing వంటి పేర్లతో కనిపిస్తాయి.
• మీ సేవలు ఏవీ ఉపయోగించని addresses కు outbound connections.

Kernel thread వేషధారణను త్వరగా పరీక్షించవచ్చు. నిజమైన kernel threads square brackets లోపల కనిపిస్తాయి. వాటి వెనుక executable ఉండదు. అందువల్ల వాటిపై sudo ls -l /proc/<pid>/exe, No such file or directory తో విఫలమవుతుంది. [kworker/0:2] గా కనిపించే processకు /tmp కింద ఉన్నదాన్ని సూచించే exe link ఉంటే, అది kernel పేరు ఉపయోగిస్తున్న సాధారణ user program.

ఈ checks నడిపేటప్పుడు box మీకు తప్పుడు సమాచారం ఇస్తూ ఉండవచ్చని గుర్తుంచుకోండి. ఏదో తప్పు ఉందని నిర్ణయించడానికి ఇవి సరిపోతాయి. ఏదీ తప్పు లేదని నిర్ణయించడానికి ఇవి సరిపోవు.

నెట్‌వర్క్‌ను సర్వర్‌ లోపల నుంచి కాకుండా provider వద్దనే కత్తిరించండి

ముందుగా isolation చేయాలి. ఎందుకంటే మరొకరు ఇప్పటికీ shell కలిగి ఉంటే, ఆ తర్వాత చేసే ప్రతి చర్య వృథా అవుతుంది. దాడి చేసేవారు logs ను గమనిస్తూ ఉన్నప్పుడు వాటిని చదవడం, keys ను మార్చడం, data ను పునరుద్ధరించడం వంటి చర్యలకు ఉపయోగం ఉండదు.

దీన్ని మీ provider control panel లో, operating system వెలుపల నడిచే network firewall లో చేయండి. inbound మరియు outbound రెండింటినీ deny చేయండి. లోపలికి ప్రవేశించే మార్గంగా web console ను మాత్రమే ఉంచండి. అక్కడ అమలు చేసే rules disk పై జరిగే ఏ మార్పులనైనా తట్టుకుని కొనసాగుతాయి.

దీన్ని server లోపల నుంచి చేయకూడదనడానికి రెండు కారణాలు ఉన్నాయి. compromised kernel లో మీరు configure చేసే firewall ను అదే kernel అమలు చేస్తుంది. మీరు nftables rules ను రాయగలిగినంత సులభంగా root వాటిని flush చేయగలదు. అలాగే sudo ip link set enp1s0 down ను SSH ద్వారా అమలు చేస్తే ముందుగా మీ స్వంత session కత్తిరించబడుతుంది. దాంతో మీరు పరిశీలిస్తున్న machine నుంచే బయటకు lock out అవుతారు.

outbound ను కూడా inbound తో పాటు block చేయండి. reverse shell మీ box నుంచి దాడి చేసేవారి వైపు connection ప్రారంభిస్తుంది. కాబట్టి inbound-only block చేస్తే ఇప్పటికే ఏర్పడిన connection సరిగ్గా పనిచేస్తూనే ఉంటుంది. మీ provider inbound rules మాత్రమే అందిస్తే, మిగిలిన మార్గాలు network interface ను detach చేయడం లేదా instance ను power off చేయడం.

ఇప్పుడే reboot చేయవద్దు. ముందుగా /var/log/journal ఉందో లేదో పరిశీలించండి. ఆ directory లేకపోతే journald, memoryలో ఉండే /run/log/journal కు రాస్తుంది. అందువల్ల reboot చేస్తే intrusion కు సంబంధించిన record తొలగిపోతుంది. reboot సమయంలో running processes కూడా అదృశ్యమవుతాయి. వాటి command lines మీకు ఎప్పటికీ లభించే అత్యంత స్పష్టమైన evidence కావచ్చు.

ఏదైనా మార్చే ముందు డిస్క్ snapshot తీసుకోండి

ఇక్కడ snapshot మరియు backup వేర్వేరు పనులు చేస్తాయి. మీరు ఇప్పుడు తీసుకునే snapshot compromised అయిన డిస్క్‌కు చెందిన కాపీ. అదే మీ evidence. పొరపాటున ఏదైనా overwrite చేసిన తర్వాత వెనక్కి వెళ్లడానికి అనుమతించే ఏకైక మార్గం కూడా అదే. మీ పాత backups recovery మార్గంగా ఉంటాయి. మీ provider panel ఈ రెండు పదాలను స్పష్టత లేకుండా ఉపయోగిస్తే, ముందుగా VPS snapshots నిజమైన backups కంటే ఎలా భిన్నంగా ఉంటాయి చదవండి. ఎందుకంటే retention నియమాలు మరియు restore ప్రవర్తన ఒకేలా ఉండవు.

మళ్లీ login చేయడానికి ముందు provider panel నుంచి snapshot తీసుకోండి. Live snapshot crash consistent గా ఉంటుంది. అంటే ఆ క్షణంలో డిస్క్ ఉన్న స్థితినే ఇది capture చేస్తుంది; ఇది power తొలగించినట్లే. Evidence కోసం ఇది సరిపోతుంది. ఎవరూ పొరపాటున restore చేయకుండా దానికి స్పష్టమైన పేరు పెట్టండి. COMPROMISED-do-not-restore-2026-08-12 వంటి నేరుగా చెప్పే పేరు సరైన స్థాయి. మీ investigation పూర్తయ్యే వరకు, అలాగే మీ hostతో ఉన్న ఏదైనా abuse ticket మూసివేయబడే వరకు దాన్ని ఉంచండి.

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 చేస్తుంది. అందువల్ల మీ commands విశ్వసనీయంగా ఉంటాయి: compromised kernel మరియు compromised binaries అమలులో ఉండవు. 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 binaries ను అమలు చేస్తుంది. అలా చేస్తే మీరు rescue mode ను boot చేసిన అసలు కారణమే తొలగిపోతుంది.

ఇంకా విశ్వసించగల ఆధారాలను సేకరించండి

వీటిని 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 logs ను journal లో మాత్రమే రాస్తుంది. journalctl -D line అదే journal ను చదువుతుంది. నిరంతరంగా ఉండాల్సిన logs లో ఖాళీ కనిపించడం లేదా log file పరిమాణం 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 user ID 0 ఉన్న ప్రతి account ను చూపుతుంది. ఆ output లో root కాకుండా మరేదైనా ఉంటే, అది రెండవ root account. find pattern ఉద్దేశపూర్వకంగా authorized_keys2 ను కూడా match చేస్తుంది. OpenSSH సాధారణంగా రెండు file names ను చదువుతుంది, కానీ రెండవ file name ను సులభంగా విస్మరించవచ్చు. lsattr attribute list లో i ను చూపిస్తే, ఆ file immutable గా ఉంది. దాడి చేసిన వ్యక్తి ఆ flag ను అమర్చితే, వారి 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 system లో /etc/ld.so.preload ఉండదు. కాబట్టి No such file or directory ఆరోగ్యకరమైన ఫలితం. ఏదైనా content కనిపిస్తే దానిని పరిశీలించాలి. Login file, base64 -d output ను shell కు pipe చేసినా ఇదే పరిస్థితి. Legitimate config తన 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 ఇటీవల రాయబడిన files కు మరింత విశ్వసనీయమైన జాబితాను ఇస్తుంది. అయినప్పటికీ ఇది తుది రుజువు కాదు. root system clock ను మార్చగలదు లేదా block device కు నేరుగా రాయగలదు.

Package integrity కోసం ఒక command మరియు ఒక మినహాయింపు చాలు. Live system లో sudo dpkg --verify checksum సరిపోని ప్రతి packaged file కు ఒక line చూపుతుంది. Checksum column లో 5 కనిపిస్తుంది. sudo debsums -ac కూడా అదే పని చేస్తుంది. అయితే debsums package installed గా ఉంటే config files ను కూడా చేర్చుతుంది. Result ను ఒక్క దిశలో మాత్రమే అర్థం చేసుకోండి. మారిన /usr/sbin/sshd నిజమైన ఆధారం. Clean report ఏదీ నిరూపించదు. Binary ను మార్చిన అదే root account, /var/lib/dpkg/info/ లోని checksum lists ను కూడా తిరిగి రాయగలదు. rkhunter మరియు chkrootkit వంటి rootkit scanners కు కూడా ఇదే నియమం వర్తిస్తుంది. Hit అంటే సమాచారం. Clean run అంటే వ్యవస్థ సురక్షితమని నిర్ధారణ కాదు.

విధ్వంసక చర్యలు చేపట్టే ముందు సేకరించిన సమాచారాన్ని 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 సమయంలో పొరపాటున files తొలగించడం సాధారణం. Snapshot మరియు ఈ archive ఉంటే దాని ప్రభావాన్ని తట్టుకోవచ్చు. తరువాత జరిగిన తప్పు rm ను undo చేయడం, చాలామంది ఊహించేదానికంటే చాలా కష్టం. దీనిని rm -rf తో తొలగించిన files ను తిరిగి పొందడం వివరిస్తుంది.

వారు ప్రవేశించిన మార్గాన్ని కనుగొనండి

ప్రవేశ మార్గాన్ని మూసివేయకుండా చేసే rebuild వల్ల మళ్లీ compromise అవుతారు. ఇది తరచుగా కొన్ని రోజుల్లోనే జరుగుతుంది, ఎందుకంటే మొదటిసారి మిమ్మల్ని గుర్తించిన scan ఎప్పుడూ ఆగదు. ఒకే సర్వర్ compromise కావడానికి సాధారణంగా నాలుగు మార్గాలు ఉంటాయి.

SSH password login. మీకు తెలియని address నుంచి వచ్చిన Accepted password for root line ఒక్కటే సరిపడే ఆధారం. PasswordAuthentication ను /etc/ssh/sshd_config లో, అలాగే /etc/ssh/sshd_config.d/ కింద ఉన్న ప్రతి file లో పరిశీలించండి. sshd ఒక keyword కోసం మొదట పొందిన value నే ఉపయోగిస్తుంది. Ubuntuలో Include line ప్రధాన file పైభాగంలో ఉంటుంది. అందువల్ల మీరు కింద మార్చిన setting కంటే drop-in config file లోని setting నిశ్శబ్దంగా అమలవుతుంది.

Authentication లేకుండా public చేసిన 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 ఏర్పడతాయి. ఇవి ufw chains కంటే ముందుగా అమలవుతాయి. అందువల్ల ufw status ఒక port blocked అని చూపించినా, దాని వెనుక ఉన్న container మొత్తం internet నుంచి వచ్చే అభ్యర్థనలకు సమాధానం ఇవ్వవచ్చు. Rebuild కు ముందు దీన్ని అర్థం చేసుకోండి: Dockerలో public చేసిన ports ufwను ఎందుకు దాటుతాయి అనే విభాగంలో rule ordering మరియు పరిష్కారం వివరించబడ్డాయి.

Patch చేయని web application. మొదట అనుమానాస్పదంగా కనిపించిన timestamp చుట్టూ web server access log లో upload path లేదా admin path కు పంపిన POST కోసం వెతకండి. తరువాత matching change time ఉన్న files కోసం web root కింద పరిశీలించండి. uploads directory లో కనిపించే PHP file సాధారణ ఫలితం.

లీకైన credential. repositoryలో commit చేసిన key, chatలో paste చేసిన token, లేదా తప్పుగా configure చేసిన web server static fileగా అందించిన .env file. Automation వల్ల ఇది అనుకోకుండా సులభంగా జరుగుతుంది. అందుకే AI agents మరియు వాటి config files నుంచి secretsను దూరంగా ఉంచడం అవసరం.

ఇవన్నీ పరిశీలించిన తరువాత కూడా ఆ మార్గాన్ని గుర్తించలేకపోతే, credential లీక్ అయిందని భావించండి. ఆ machineలో ఉన్న ప్రతి secret public అయిందిగా పరిగణించండి.

మెషీన్ చూడగలిగే ప్రతి credential ను మార్చండి

నెట్‌వర్క్‌ను కట్ చేసిన తర్వాతే credentials ను మార్చండి; అంతకుముందు ఎప్పుడూ మార్చవద్దు. దాడి చేసేవారికి ఇంకా connection ఉన్న సమయంలో మార్చితే, కొత్త secrets ను వారికి నేరుగా అందించినట్టే అవుతుంది.

• సర్వర్‌లో నిల్వ చేసిన ప్రతి SSH private key, అలాగే దానికి సరిపోలే public key పై నమ్మకం ఉంచిన ఇతర ప్రాంతాల్లోని ప్రతి account.
• ssh -A ద్వారా మీరు ఆ మెషీన్‌కు forward చేసిన ఏదైనా key. Agent forwarding వల్ల /tmp కింద ఒక socket ఏర్పడుతుంది. ఆ మెషీన్‌లోని root మీ key అంగీకరించబడే ఏ ప్రాంతంలోనైనా మీ తరఫున authenticate చేయడానికి దాన్ని ఉపయోగించగలదు; మీ session తెరిచి ఉన్నంతకాలం ఇది సాధ్యమే.
• .env files లోని API tokens, systemd Environment= lines లోని tokens, CI configuration లోని tokens, అలాగే provider credentials.
• Database passwords, అలాగే వాటిని ఉపయోగించే application accounts.
• సర్వర్ వద్ద ఉన్న TLS (transport layer security) private keys. Certificate ను మళ్లీ జారీ చేసి, పాతదాన్ని revoke చేయండి.
• మీ hosting account password. దానిపై two-factor authentication ను turn on చేయండి. మీరు నిర్వహించే ప్రతి server ను ఆ panel ద్వారా rebuild, snapshot, console చేయవచ్చు. అందువల్ల అదే నిజమైన perimeter.
• ఆ host compromised గా ఉన్న సమయంలో shell session లో టైప్ చేసిన ప్రతి password, ఎందుకంటే root terminal session ను జరుగుతున్నప్పుడే record చేయగలదు.

ఆ మెషీన్‌లోని ఏదైనా 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 ను network కు expose చేయడానికి ముందు దాన్ని harden చేయండి: key-only SSH, root కాని working account, default-deny inbound firewall, మరియు అవసరమైన దానికంటే విస్తృతంగా ఏ service ను publish చేయకపోవడం. కొత్త VPS లో మొదటి పది నిమిషాలు అనే విధానాన్ని అనుసరించండి. తరువాత SSH ను సరిగ్గా harden చేయండి. ఆపై login noise ను తగ్గించడానికి Ubuntu 24.04 లో fail2ban ను జోడించండి. ప్రతి service కు కనిష్ట అనుమతులు కలిగిన ప్రత్యేక account ఇవ్వండి. అప్పుడు వచ్చే foothold root foothold గా మారదు.
7. పాత server ను power off చేయండి. దర్యాప్తు మరియు abuse ticket పూర్తయ్యే వరకు దాని snapshot ను ఉంచండి.
8. backups ను సరిచేయండి. 3వ దశ ఊహాగానాలపై ఆధారపడి ఉంటే, intrusion కు ముందుకు వెళ్లేంత పొడవైన backup history మీ వద్ద లేదనేది అసలు పాఠం. దీర్ఘకాల retention తో versioned off-server backups ఉంటే, తదుపరి సారి clean restore point లభిస్తుంది: VPS లో restic backups రెండింటినీ అందిస్తుంది.

intrusion జరిగిన తేదీని నిర్ణయించలేకపోతే, సురక్షితమైన backup ను ఎంచుకోలేరు. అటువంటి సందర్భంలో మీరు స్వయంగా పరిశీలించగల data ను మాత్రమే restore చేయండి: చదవగలిగే SQL dump లేదా జాబితా చేయగలిగే images directory వంటివి. executable గా ఉన్న ప్రతిదాన్ని అనుమానాస్పదంగా పరిగణించండి. దాన్ని repositories నుంచి మళ్లీ install చేయండి.

మీ host పంపిన abuse notice అర్థం ఏమిటి

చాలామందికి తమ server breached అయిందని తమ monitoring ద్వారా కాకుండా provider ద్వారా తెలుస్తుంది. Hosts outbound network traffic ను చూస్తాయి: ఇతర networks పై SSH brute-force దాడులు, port 25 పై spam లేదా reflection attack లో భాగంగా ఉపయోగించిన server. సాధారణంగా ticket లో timestamps, ports, network flows కు సంబంధించిన ఒక sample, అలాగే గంటల్లో కొలిచిన deadline ఉంటాయి.

మీ సమాధానం server isolated అయి rebuild అవుతోందని చెప్పడానికే పరిమితమైనా, ఆ ticket కు తప్పనిసరిగా స్పందించండి. Ticket కు సమాధానం రాకపోతే providers server కు null-route అమలు చేయవచ్చు లేదా దానిని suspend చేయవచ్చు. దాంతో మీ incident outage గా మారుతుంది. తరువాత report కు ఆధారమైన raw log lines ను అడగండి. ఆ timestamps మీ machine వెలుపల record చేయబడ్డాయి. అందువల్ల attacker మార్చలేని timeline లోని ఏకైక భాగం అవే. Disk పై ఉన్న ఇతర ఆధారాలకన్నా intrusion ఎప్పుడు జరిగిందో అవి తరచుగా మరింత ఖచ్చితంగా తెలియజేస్తాయి.

Customer server breached కావడం host కు సాధారణ నిర్వహణ పనిలో భాగమే. దాన్ని సరిగ్గా నిర్వహించినందుకు మీపై ప్రతికూలంగా పరిగణించరు. VPS hosting సురక్షితమేనా అనే విస్తృత ప్రశ్నకు సమాధానం ప్రధానంగా customer ఏ configuration చేస్తాడనే దానిపై ఆధారపడి ఉంటుంది. ఇప్పుడు అదే పనిని మొదటి నుంచి మళ్లీ చేయాల్సి ఉంటుంది.

వృత్తిపరుడిని ఎప్పుడు సంప్రదించాలి

• సర్వర్‌లో ఇతర వ్యక్తులకు చెందిన వ్యక్తిగత డేటా ఉంది. GDPR (General Data Protection Regulation) ప్రకారం, వ్యక్తిగత డేటా breach గురించి supervisory authorityకి అనవసరమైన ఆలస్యం లేకుండా, సాధ్యమైనప్పుడు breach గురించి తెలిసిన 72 గంటల్లోపు నివేదించాలి. ఆ గడువు ప్రారంభమైందా లేదా అనేది నిర్ణయించడం legal పని, sysadmin పని కాదు.
• Payment card data పరిధిలో ఉంది. Card schemes ఆమోదించబడిన forensic investigatorను తప్పనిసరి చేస్తాయి. మీరు స్వయంగా ఆధారాలను పరిశీలించడం వల్ల case దెబ్బతినవచ్చు.
• Extortion demand వచ్చింది లేదా మీ data encrypted అయింది.
• ఆ machine ఇతర machinesను చేరుకోగలిగింది: internal network, production credentials కలిగిన hypervisor లేదా CI runner. ఒక groupలోని compromised hostకు విరుద్ధంగా నిరూపించేవరకు, అది మొత్తం groupకు సంబంధించిన incidentగానే పరిగణించాలి.
• Insurance లేదా law enforcement కోసం evidence చెల్లుబాటు అయ్యేలా ఉండాలి. Snapshot వద్ద ఆపండి, పూర్తి disk image తీసుకోండి, దాన్ని ఎవరు ఎప్పుడు నిర్వహించారో నమోదు చేయండి.

మీ స్వంత services నడుస్తున్న ఒకే VPSలో ఇతరుల data ఏదీ లేకపోతే, పై playbookతోనే మొత్తం పని పూర్తవుతుంది. Provider వద్ద isolate చేయండి. Evidence కోసం snapshot తీసుకోండి. ఇంకా విశ్వసించగల dataను సేకరించండి. ప్రతిదీ rotate చేయండి. Cleanగా rebuild చేయండి.

FAQ

నేను hack చేయబడిన VPS ను మళ్లీ నిర్మించకుండా శుభ్రం చేయవచ్చా?

పూర్తి నమ్మకంతో చేయలేరు. ఎందుకంటే compromised system ను దాని గురించే నివేదించమని అడిగినట్లవుతుంది. మార్చబడిన ps ఒక process ను దాచవచ్చు. /etc/ld.so.preload లోని ఒక line మీరు అమలు చేసే ప్రతి dynamically linked tool లో code inject చేయవచ్చు. Kernel module అన్ని programs నుంచీ files ను ఒకేసారి దాచవచ్చు. కొన్ని అంశాలను కనుగొనవచ్చు, కాబట్టి ఒక hit ప్రాముఖ్యమైనది. కానీ ఏదీ లేదని నిరూపించలేరు. అందువల్ల clean result నమ్మదగినది కాదు. Server లో మీకు విలువైనది ఏదీ లేకపోతే, అది మళ్లీ compromised కావచ్చని అంగీకరిస్తే మాత్రమే cleaning ను సమర్థించవచ్చు.

compromised server ను power off చేయాలా లేదా running లోనే ఉంచాలా?

ముందుగా provider వద్ద దాని network ను నిలిపివేయండి. తరువాత snapshot తీసి running processes ను పరిశీలించడానికి అవసరమైనంతసేపు దాన్ని running లో ఉంచండి. Power off చేస్తే process list తొలగిపోతుంది. /var/log/journal లేకపోతే journal కూడా పూర్తిగా తొలగిపోతుంది. ఎందుకంటే అప్పుడు journald /run కింద memory లో రాస్తుంది. అది ఇతర networks పై actively attack చేస్తుంటే, 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 తో cross-check చేయండి. ఎందుకంటే ctime ను mtime కంటే forge చేయడం కష్టం. తరువాత ఈ మూడు dates లోని timestamps ను మీ provider abuse ticket లోని timestamps తో పోల్చండి. ఆ timestamps machine వెలుపల record చేయబడ్డాయి, కాబట్టి వాటిని edit చేయలేరు. ఆ మూడు dates లో అత్యంత పాతదానికంటే పాత backup ను ఎంచుకోండి. ఏదీ సరిపోలకపోతే, మీ backup history కంటే compromise పాతదని భావించండి. మీరు inspect చేయగల data ను మాత్రమే restore చేయండి.

compromise తర్వాత నా backups ను restore చేయడం సురక్షితమేనా?

Inspection చేసిన తరువాత 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 కు ఎల్లప్పుడూ reply ఇవ్వండి. దాని తరువాతి బాధ్యత machine లో ఎవరి data ఉందో దానిపై ఆధారపడి ఉంటుంది. ఇతరులకు చెందిన personal data ఉంటే, చట్టపరమైన reporting duty ఏర్పడవచ్చు. ఉదాహరణకు, GDPR ప్రకారం supervisory authority కు 72-hour notification అవసరం కావచ్చు. Server లో user credentials నిల్వ ఉంటే, ఆ users కు తెలియజేయండి. వారు ఇతర చోట్ల passwords మార్చుకోవచ్చు. ఆ machine లోని keys code host లేదా cloud account వంటి third-party systems కు access ను authorize చేసి ఉంటే, ఆ providers కు తెలియజేయండి. వారు misuse జరిగిందో లేదో పరిశీలించగలరు. ఇతరుల data ఏదీ లేని purely personal server కు abuse ticket కు మించిన బాధ్యత ఉండదు.