ஹேக் செய்யப்பட்ட VPS-ஐ மீட்பது எப்படி?

ஹேக் செய்யப்பட்ட VPS-ஐ சுத்தம் செய்ய வேண்டாம்

உங்கள் VPS ஹேக் செய்யப்பட்டால், நீங்கள் எந்தக் கட்டளையையும் இயக்குவதற்கு முன்பே எடுக்க வேண்டிய மிக முக்கியமான முடிவு இதுதான். அந்த மெஷினை சுத்தம் செய்ய முயற்சிக்காதீர்கள். அதை உங்கள் service provider தளத்தில் தனிமைப்படுத்துங்கள் (isolate), ஆதாரத்திற்காக அதன் டிஸ்க்கை snapshot எடுங்கள், அதில் இருந்த அனைத்து credentials-களையும் மாற்றுங்கள், பின்னர் நீங்கள் நம்பும் source-களைக் கொண்டு புதிய server-ல் மீண்டும் கட்டமைக்கவும் (rebuild).

ஒரு rootkit நீக்கப்பட்டுவிட்டது என்பதை உங்களால் நிரூபிக்க முடியாது, ஏனெனில் அதை நிரூபிக்க நீங்கள் பயன்படுத்தும் கருவிகளே தாக்குதல் நடத்துபவரின் கட்டுப்பாட்டில் இருக்கும்.

இதுவே முழுமையான வாதம். இதன் பின்னணியில் உள்ள நுட்பம் இதோ. root access பெற்ற ஒரு தாக்குதல் நடத்துபவர் ps-ஐ மாற்றியமைக்க முடியும், இதனால் ஒரு குறிப்பிட்ட process ID அதன் வெளியீட்டில் ஒருபோதும் தெரியாது. /etc/ld.so.preload-ல் உள்ள ஒரு வரி, அந்த மெஷினில் உள்ள அனைத்து dynamically linked நிரல்களிலும் தாக்குதல் நடத்துபவரின் குறியீட்டை ஏற்றிவிடும். இதனால் ls, ss மற்றும் find ஆகிய அனைத்தும் ஒரே மாதிரியாகப் பொய் சொல்லும். ஒரு loadable kernel module, system call-க்கு கீழே கோப்புகளை மறைக்க முடியும், எனவே புதிதாகப் பதிவிறக்கம் செய்யப்பட்ட binary கூட சுத்தமான டிஸ்க்கையே பார்க்கும். நீங்கள் miner-ஐ நீக்குகிறீர்கள், CPU வரைபடம் குறைகிறது, server அமைதியாகிறது. ஒரு backdoor சரியாகச் செயல்படும்போதும் இதேபோன்ற அமைதியான நிலையே இருக்கும்.

மீண்டும் கட்டமைப்பதற்கான செலவு, அது தோன்றுவதை விடக் குறைவுதான். ஒரு சாதாரண VPS என்பது சில packages, ஒரு config directory மற்றும் ஒரு data set ஆகியவற்றின் தொகுப்பு மட்டுமே. எனவே, மீண்டும் கட்டமைப்பது என்பது ஒரு குறிப்பிட்ட காலக்கெடுவுக்குள் முடிக்கக்கூடிய வேலை. தாக்குதல் நடத்துபவர் செய்த ஒவ்வொரு மாற்றத்தையும் தேடுவது முடிவில்லாத வேலை, அது ஒருபோதும் முழுமையான ஆதாரத்தை அளிக்காது.

ஊடுருவல் உண்மையானதுதானா என்பதை உறுதிப்படுத்துதல்

ஹேக் செய்யப்பட்டதாகக் கருதப்படும் பல server-கள் உண்மையில் அவ்வாறு செய்யப்படுவதில்லை. தினமும் ஆயிரக்கணக்கான தோல்வியுற்ற SSH login முயற்சிகள் இணையத்தின் பின்னணி இரைச்சலே ஆகும், ஏனெனில் ஒவ்வொரு பொது IPv4 முகவரியும் தொடர்ந்து ஸ்கேன் செய்யப்படுகிறது. lastb வெளியீட்டில் நிறைய root மற்றும் admin முயற்சிகள் இருப்பது, ஸ்கேனர்கள் உங்கள் port-ஐக் கண்டறிந்துவிட்டன என்பதைக் குறிக்கிறது. இது யாரும் உள்ளே நுழைந்துவிட்டார்கள் என்று அர்த்தமல்ல.

கீழ்க்கண்ட அறிகுறிகள் ஏதேனும் இருந்தால், அது கவனிக்கப்பட வேண்டிய ஒன்று:

• நீங்கள் செய்யாத ஒரு வெற்றிகரமான login, உதாரணமாக Accepted password for root from 203.0.113.7.
• நீங்கள் சேர்க்காத ஒரு key, authorized_keys-ல் இருப்பது.
• உங்கள் server-லிருந்து வெளியேறும் traffic குறித்து உங்கள் host வழங்கும் துஷ்பிரயோக அறிவிப்பு (abuse notice).
• kernel thread-ன் பெயரைப் போலக் காட்டும், 100% CPU-வை பயன்படுத்தும் ஒரு process. திறந்த நிலையில் உள்ள Redis மற்றும் Docker sockets வழியாக நுழையும் miners, பெரும்பாலும் kdevtmpfsi மற்றும் kinsing போன்ற பெயர்களில் காணப்படுகின்றன.
• உங்கள் சேவைகள் எதற்கும் தொடர்பில்லாத முகவரிகளுக்குச் செல்லும் outbound இணைப்புகள்.

Kernel thread போல வேடமிட்டிருக்கும் process-களைச் சோதிக்க ஒரு எளிய வழி உள்ளது. உண்மையான kernel thread-கள் சதுர அடைப்புக்குறிக்குள் (square brackets) காட்டப்படும், அவற்றுக்கு என்று தனி executable இருக்காது, எனவே sudo ls -l /proc/<pid>/exe கட்டளை அவற்றுக்கு No such file or directory என்ற பிழையைத் தரும். ஒரு process [kworker/0:2] என்று காட்டப்பட்டு, அதன் exe இணைப்பு /tmp-க்குக் கீழ் எதையாவது சுட்டிக்காட்டினால், அது kernel-ன் பெயரைப் பயன்படுத்தும் ஒரு சாதாரண பயனர் நிரலாகும்.

இந்தச் சோதனைகளைச் செய்யும்போது, அந்த server உங்களை ஏமாற்றக்கூடும் என்பதை நினைவில் கொள்ளுங்கள். ஏதோ தவறு நடக்கிறது என்பதை உறுதிப்படுத்த இந்தச் சோதனைகள் போதுமானவை. ஆனால், எதுவும் நடக்கவில்லை என்று முடிவு செய்ய இவை போதாது.

சேவையகத்திற்குள் இருந்து அல்லாமல், சேவை வழங்குநரின் தளத்திலேயே நெட்வொர்க்கைத் துண்டிக்கவும்

தனிமைப்படுத்துதலே முதன்மையானது. ஏனெனில், வேறொருவர் உங்கள் கணினியில் shell-ஐ வைத்திருக்கும் வரை, அதற்குப் பிறகு நீங்கள் செய்யும் ஒவ்வொரு செயலும் வீணாகும். தாக்குதல் நடத்துபவர் நேரலையில் கவனித்துக் கொண்டிருக்கும்போது, logs-ஐப் படிப்பது, cryptographic keys-ஐ மாற்றுவது மற்றும் தரவை மீட்டெடுப்பது போன்றவை பயனற்றவை.

இதை உங்கள் சேவை வழங்குநரின் control panel-ல், உங்கள் operating system-க்கு வெளியே இயங்கும் network firewall மூலம் செய்யுங்கள். உள்வரும் (inbound) மற்றும் வெளியேறும் (outbound) போக்குவரத்தைத் தடை செய்யவும்; web console-ஐ மட்டும் உங்கள் அணுகல் வழியாக வைத்துக்கொள்ளுங்கள். அங்கு அமல்படுத்தப்படும் விதிகள், வட்டில் (disk) என்ன நடந்தாலும் மாறாமல் இருக்கும்.

சேவையகத்திற்குள் இருந்து இதைச் செய்யக்கூடாது என்பதற்கு இரண்டு காரணங்கள் உள்ளன. சமரசம் செய்யப்பட்ட kernel-க்குள் நீங்கள் அமைக்கும் firewall-ஐ அதே kernel-தான் நிர்வகிக்கிறது. நீங்கள் nftables-ஐ எழுதுவது போலவே, root பயனர் அதை எளிதாக அழிக்க முடியும். மேலும், SSH வழியாக sudo ip link set enp1s0 down கட்டளையை இயக்குவது உங்கள் சொந்த session-ஐ முதலில் துண்டித்துவிடும். இது நீங்கள் ஆய்வு செய்து கொண்டிருக்கும் இயந்திரத்திலிருந்து உங்களை வெளியேற்றிவிடும்.

உள்வரும் போக்குவரத்தைப் போலவே, வெளியேறும் போக்குவரத்தையும் தடுங்கள். ஒரு reverse shell உங்கள் கணினியிலிருந்து தாக்குதல் நடத்துபவருக்கு அழைப்பை ஏற்படுத்தும். எனவே, உள்வரும் போக்குவரத்தை மட்டும் தடுப்பது, ஏற்கனவே உள்ள இணைப்பைத் தடையின்றி இயங்க அனுமதிக்கும். உங்கள் சேவை வழங்குநர் உள்வரும் விதிகளுக்கு மட்டுமே அனுமதி அளித்தால், network interface-ஐத் துண்டிப்பது அல்லது instance-ஐ அணைப்பது மட்டுமே எஞ்சியிருக்கும் விருப்பங்கள்.

இப்போதே reboot செய்ய வேண்டாம். முதலில் /var/log/journal இருக்கிறதா என்று சரிபார்க்கவும். அந்த directory இல்லையென்றால், journald ஆனது /run/log/journal-ல் எழுதுகிறது. இது memory-ல் இருப்பதால், reboot செய்தால் ஊடுருவல் குறித்த பதிவுகள் அழிந்துவிடும். இயங்கிக் கொண்டிருக்கும் process-களும் reboot-ன் போது மறைந்துவிடும். அவற்றின் command lines-தான் உங்களுக்குக் கிடைக்கும் மிகத் தெளிவான ஆதாரங்களாக இருக்கும்.

எந்த மாற்றத்தையும் செய்வதற்கு முன் disk-ஐ snapshot எடுக்கவும்

இங்கே snapshot மற்றும் backup ஆகிய இரண்டும் வெவ்வேறு பணிகளைச் செய்கின்றன. நீங்கள் இப்போது எடுக்கும் snapshot என்பது பாதிக்கப்பட்ட disk-ன் நகலாகும்: இதுவே உங்களுக்கான ஆதாரமாகும், மேலும் தவறுதலாக எதையாவது அழித்துவிட்டால் மீண்டும் பழைய நிலைக்குத் திரும்ப இதுவே உதவும். உங்கள் பழைய backups-கள் தரவுகளை மீட்டெடுப்பதற்கான வழியாகும். உங்கள் service provider-ன் control panel-ல் இந்த இரண்டு சொற்களும் குழப்பமாகப் பயன்படுத்தப்பட்டிருந்தால், முதலில் VPS snapshots மற்றும் உண்மையான backups-களுக்கு இடையிலான வேறுபாடுகள் என்பதைப் படிக்கவும், ஏனெனில் அவற்றின் retention விதிகள் மற்றும் restore செய்யும் முறை மாறுபடும்.

மீண்டும் login செய்வதற்கு முன்பே provider panel மூலம் snapshot-ஐ எடுக்கவும். Live snapshot என்பது crash consistent முறையில் இருக்கும்: இது மின்சாரத்தைத் துண்டிப்பது போல, அந்த நொடியில் disk எப்படி இருந்ததோ அதை அப்படியே பதிவு செய்யும். ஆதாரத்திற்கு இது போதுமானது. தவறுதலாக யாரும் இதை restore செய்யாதவாறு இதற்குப் பெயரிடவும். COMPROMISED-do-not-restore-2026-08-12 என்பது போன்ற நேரடியான பெயரே இதற்குப் பொருத்தமானது. உங்கள் விசாரணை முடியும் வரையிலும், உங்கள் host-உடன் உள்ள abuse ticket மூடப்படும் வரையிலும் இதை வைத்திருக்கவும்.

SSH இணைப்பு துண்டிக்கப்பட்டால் அணுகுவது எப்படி

வழங்குநரின் (provider) கட்டுப்பாட்டுப் பலகத்தில் (panel) இரண்டு வழிகள் உள்ளன. Web console (VNC அல்லது serial) என்பது கணினியில் நேரடியாக விசைப்பலகையை இணைத்தது போன்றது. sshd செயலிழந்திருந்தாலும், firewall தவறாக அமைக்கப்பட்டிருந்தாலும், அல்லது தாக்குபவர் SSH port-ஐ மாற்றியிருந்தாலும் இது வேலை செய்யும். இது local password மூலம் அங்கீகரிக்கும்; எனவே, key-only முறையில் இயங்கும் server-களில் console-ஐப் பயன்படுத்த, முதலில் root password-ஐ reset செய்ய வேண்டியிருக்கலாம்.

Rescue mode சிறந்த வழி. இது உங்கள் disk-ஐ இணைத்து, ஆனால் இயக்காமல், ஒரு சிறிய live system-ஐ boot செய்யும். இதனால் உங்கள் கட்டளைகள் நம்பகமானவை: தாக்குதலுக்குள்ளான kernel மற்றும் binaries எதுவும் இயங்காது. Disk-ஐ 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 செய்யவும். பிறகு /dev/mapper/-ன் கீழ் தோன்றும் device-ஐ mount செய்யவும்.

Mount செய்யப்பட்ட disk-க்குள் chroot செய்ய வேண்டாம். Chroot செய்வது தாக்குபவரின் binaries-ஐ உங்கள் அனுமதியுடன் இயக்கும். இதுவே நீங்கள் rescue mode-ல் boot செய்ததற்கான நோக்கத்தையே சிதைத்துவிடும்.

நம்பகமான ஆதாரங்களைச் சேகரித்தல்

இவற்றை rescue mode-ல் இயக்கவும். வட்டு (disk) /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 logs journal-ல் மட்டுமே பதிவாகும். இதையே journalctl -D வரி வாசிக்கிறது. தொடர்ச்சியான logs-ல் இடைவெளி இருப்பதையோ அல்லது log file-ன் அளவு பூஜ்ஜியமாக (zero bytes) இருப்பதையோ கவனிக்க வேண்டும். logs-ஐ அழிப்பது பொதுவானது, ஆனால் அது பெரும்பாலும் கவனக்குறைவாகவே செய்யப்படுகிறது.

அடுத்து, கணக்குகள் (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 வரி, user ID 0 கொண்ட அனைத்து கணக்குகளையும் அச்சிடும். அந்த வெளியீட்டில் root தவிர வேறு ஏதேனும் இருந்தால், அது மற்றொரு root கணக்காகும். find pattern, authorized_keys2-ஐயும் உள்ளடக்கும். ஏனெனில் OpenSSH இயல்பாகவே இரண்டு கோப்புப் பெயர்களையும் வாசிக்கும், இரண்டாவது கோப்பை எளிதில் கவனிக்கத் தவறிவிடலாம். lsattr கட்டளையின் attribute பட்டியலில் i இருந்தால், அந்த கோப்பு immutable ஆக உள்ளது என்று அர்த்தம். தாக்குதல் நடத்துபவர் இந்த flag-ஐ அமைப்பதன் மூலம், நீங்கள் அந்த key-ஐ நீக்க முயலும்போது Operation not permitted பிழை ஏற்படும். இதனால், திருத்தம் செய்யப்பட்டுவிட்டது என்று நிர்வாகி தவறாக நினைக்கக்கூடும்.

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 என்பதே சரியான முடிவாகும்; அதில் ஏதேனும் உள்ளடக்கம் இருந்தால் அது கவனிக்கப்பட வேண்டியது. base64 -d வெளியீட்டை shell-க்கு அனுப்பும் login file-ம் அதே போன்றதுதான்; முறையான configuration-க்கு அதன் சொந்த உரையை மறைக்க வேண்டிய அவசியம் இல்லை.

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-ஆக மாற்ற முடியும், எனவே mtime நம்பகமானது அல்ல. inode-ல் ஏதேனும் மாற்றம் ஏற்படும்போது change time (ctime) தானாகவே புதுப்பிக்கப்படும். touch கட்டளையால் இதை பின்னோக்கி மாற்ற முடியாது. எனவே, சமீபத்தில் எழுதப்பட்ட கோப்புகளை அறிய -newerct மிகவும் நம்பகமான பட்டியலைத் தரும். இது முழுமையான ஆதாரம் அல்ல, ஏனெனில் root பயனர் system clock-ஐ மாற்றலாம் அல்லது block device-ல் நேரடியாக எழுதலாம்.

Package integrity-ஐச் சரிபார்க்க ஒரு கட்டளை மற்றும் ஒரு எச்சரிக்கை உள்ளது. இயங்கும் system-ல், checksum பொருந்தாத ஒவ்வொரு packaged கோப்பிற்கும் sudo dpkg --verify ஒரு வரியை அச்சிடும், அதில் 5 இருக்கும். sudo debsums -ac கட்டளை, debsums package நிறுவப்பட்டிருக்கும்போது configuration கோப்புகளையும் சேர்த்துச் சரிபார்க்கும். முடிவுகளை ஒரு திசையில் மட்டுமே வாசிக்கவும். மாற்றப்பட்ட /usr/sbin/sshd என்பது உண்மையான ஆதாரம். ஒரு clean report எதையும் நிரூபிக்காது, ஏனெனில் binary-ஐ மாற்றிய அதே root கணக்கு, /var/lib/dpkg/info/-ன் கீழ் உள்ள checksum பட்டியல்களையும் மாற்றியிருக்கலாம். rkhunter மற்றும் chkrootkit போன்ற rootkit scanners-க்கும் இதே விதிதான் பொருந்தும்: ஒரு எச்சரிக்கை (hit) என்பது தகவல், ஆனால் clean run என்பது பாதுகாப்புச் சான்றிதழ் அல்ல.

எந்தவொரு அழிக்கும் நடவடிக்கையையும் எடுப்பதற்கு முன், சேகரித்தவற்றை machine-லிருந்து வெளியே நகலெடுக்கவும்.

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-க்கு வெளியே எங்காவது குறித்து வைக்கவும். இது காப்பீட்டுத் தொகை கோருவதற்கோ அல்லது காவல் துறை அறிக்கையிலோ பயன்படும் பட்சத்தில், சேகரித்த பிறகு அந்த archive மாறவில்லை என்பதை நிரூபிப்பது, வெறும் கோப்புகளைக் காட்டுவதற்கும் ஆதாரமாகச் சமர்ப்பிப்பதற்கும் உள்ள வித்தியாசமாகும். விசாரணையின் போது தவறுதலாக கோப்புகளை நீக்குவது இயல்பானது. snapshot மற்றும் இந்த archive இருந்தால் மட்டுமே அந்த இழப்பிலிருந்து மீள முடியும். தவறுதலாகச் செய்த rm-ஐச் சரிசெய்வது மக்கள் நினைப்பதை விட கடினமானது, இதைப் பற்றி rm -rf மூலம் நீக்கப்பட்ட கோப்புகளை மீட்டெடுத்தல் விளக்குகிறது.

அவர்கள் உள்ளே நுழைந்த வழியைக் கண்டறிதல்

நுழைவு வழியை மூடாமல் செய்யப்படும் ஒரு rebuild, உங்களை மீண்டும் சில நாட்களிலேயே compromised நிலைக்குத் தள்ளும். ஏனெனில், உங்களைக் கண்டறிந்த scan தொடர்ந்து இயங்கிக்கொண்டே இருக்கும். பெரும்பாலான single-server compromises-க்கு நான்கு வழிகள் காரணமாக அமைகின்றன.

SSH password login. நீங்கள் அறியாத முகவரியிலிருந்து வரும் ஒரு Accepted password for root வரி இதற்குப் போதுமான ஆதாரமாகும். /etc/ssh/sshd_config-ல் உள்ள PasswordAuthentication-ஐயும், /etc/ssh/sshd_config.d/-க்குக் கீழ் உள்ள அனைத்துக் கோப்புகளையும் சரிபார்க்கவும். sshd ஒரு keyword-க்கு முதலில் கிடைக்கும் மதிப்பையே பயன்படுத்தும். Ubuntu-வில் Include வரி முதன்மை கோப்பின் உச்சியில் இருப்பதால், நீங்கள் கீழே மாற்றியமைத்த அமைப்பை விட, புதிதாகச் சேர்க்கப்பட்ட config கோப்பு முன்னுரிமை பெற்றுவிடும்.

Authentication இல்லாத ஒரு service. 6379-ல் இயங்கும் Redis, 2375-ல் இயங்கும் Docker API, அல்லது 127.0.0.1-க்கு பதிலாக 0.0.0.0-ல் பிணைக்கப்பட்ட (bound) database. Docker பெரும்பாலும் ஆச்சரியத்தை அளிக்கும் காரணியாக உள்ளது. ஒரு container port-ஐ வெளியிடும்போது, அது ufw chains-க்கு முன்னதாகவே மதிப்பீடு செய்யப்படும் DNAT (destination network address translation) விதிகளைச் சேர்க்கிறது. எனவே, ufw status ஒரு port தடுக்கப்பட்டதாகக் காட்டினாலும், அதற்குப் பின்னால் உள்ள container முழு இணையத்திற்கும் பதிலளிக்கக்கூடும். rebuild செய்வதற்கு முன்பே இதைப் புரிந்துகொள்ளுங்கள்: Docker published ports ஏன் ufw-ஐத் தவிர்க்கின்றன என்பது விதிகளின் வரிசை மற்றும் தீர்வை விளக்குகிறது.

Patch செய்யப்படாத web application. சந்தேகத்திற்குரிய நேரத்திற்கு அருகில் உள்ள web server access log-ல், ஒரு upload path அல்லது admin path-க்கு அனுப்பப்பட்ட POST கோரிக்கையைத் தேடுங்கள். பின்னர், web root-க்குக் கீழ் உள்ள கோப்புகளில் அதே மாற்ற நேரத்தைக் கொண்ட கோப்புகளைத் தேடுங்கள். uploads directory-ல் காணப்படும் ஒரு தேவையற்ற PHP கோப்பு இதற்குச் சிறந்த உதாரணம்.

கசிந்த credential. repository-ல் commit செய்யப்பட்ட ஒரு key, chat-ல் பகிரப்பட்ட ஒரு token, அல்லது தவறாக configure செய்யப்பட்ட web server மூலம் static கோப்பாக வழங்கப்பட்ட ஒரு .env கோப்பு. Automation மூலம் இத்தகைய தவறுகள் எளிதாக நடக்கின்றன. இதனால்தான் secrets-ஐ AI agents மற்றும் அவற்றின் config கோப்புகளிலிருந்து விலக்கி வைப்பது அவசியமாகிறது.

இவை அனைத்தையும் செய்த பிறகும் நுழைவு வழியைக் கண்டறிய முடியவில்லை என்றால், credential கசிந்ததாகவே கருதி, அந்த machine-ல் இருந்த அனைத்து secrets-ம் பொதுவெளியில் கசிந்துவிட்டதாகக் கருதி செயல்படுங்கள்.

இயந்திரம் கண்டிருக்கக்கூடிய அனைத்து நற்சான்றிதழ்களையும் (credentials) மாற்றவும்

நெட்வொர்க் துண்டிக்கப்பட்ட பிறகு மாற்றவும், அதற்கு முன் செய்ய வேண்டாம். தாக்குதல் நடத்துபவர் இன்னும் இணைப்பில் இருக்கும்போது மாற்றினால், புதிய ரகசியங்களை அவரிடமே ஒப்படைப்பது போலாகும்.

• சர்வரில் சேமிக்கப்பட்டுள்ள ஒவ்வொரு SSH private key மற்றும் அதனுடன் தொடர்புடைய public key-ஐ நம்பியிருக்கும் பிற கணக்குகள்.
• ssh -A மூலம் நீங்கள் இந்த இயந்திரத்திற்குள் கொண்டு வந்த எந்தவொரு சாவியும். Agent forwarding, /tmp-ன் கீழ் ஒரு socket-ஐ விட்டுச் செல்கிறது. உங்கள் session திறந்திருக்கும் வரை, அந்த இயந்திரத்தின் root பயனர் உங்கள் சாவியைப் பயன்படுத்தி நீங்கள் அங்கீகரிக்கப்பட்ட எங்கும் நுழைய முடியும்.
• .env கோப்புகளில் உள்ள API tokens, systemd Environment= வரிகளில் உள்ளவை, CI configuration மற்றும் provider credentials-ல் உள்ளவை.
• Database கடவுச்சொற்கள் மற்றும் அவற்றைப் பயன்படுத்தும் application கணக்குகள்.
• சர்வரில் இருந்த TLS (transport layer security) private keys. சான்றிதழை மீண்டும் பெற்று, பழையதை ரத்து செய்யவும் (revoke).
• உங்கள் hosting கணக்கின் கடவுச்சொல், இரண்டு காரணி அங்கீகாரத்தை (two-factor authentication) இயக்கி மாற்றவும். அந்த panel மூலம் நீங்கள் வைத்திருக்கும் ஒவ்வொரு சர்வரையும் மீண்டும் உருவாக்கவோ, snapshot எடுக்கவோ அல்லது console மூலம் நுழையவோ முடியும் என்பதால், அதுவே உண்மையான பாதுகாப்பு எல்லை (perimeter).
• அந்த ஹோஸ்டில் சமரசம் செய்யப்பட்டபோது shell session-ல் தட்டச்சு செய்யப்பட்ட எந்தவொரு கடவுச்சொல்லும்; ஏனெனில் root பயனர் terminal session-ஐ அது நடக்கும்போதே பதிவு செய்ய முடியும்.

அந்த இயந்திரத்தில் உள்ள கடவுச்சொல் வேறு எங்காவது பயன்படுத்தப்பட்டிருந்தால், அங்கேயும் அதை மாற்றவும். கடவுச்சொற்களை மீண்டும் பயன்படுத்துவதால்தான் ஒரு சமரசம் செய்யப்பட்ட VPS, சமரசம் செய்யப்பட்ட மின்னஞ்சல் கணக்காக மாறுகிறது.

மீண்டும் கட்டமைப்பதற்கான சரிபார்ப்புப் பட்டியல்

1. புதிய distribution image-ஐப் பயன்படுத்தி ஒரு புதிய server-ஐ உருவாக்கவும். பாதிக்கப்பட்ட server-ன் snapshot-லிருந்தோ அல்லது முழு root-filesystem restore மூலமாகவோ இதைச் செய்ய வேண்டாம்.
2. Distribution repositories-லிருந்து packages-ஐ நிறுவவும். பழைய disk-லிருந்து எந்தவொரு binary-யையும் நகலெடுக்க வேண்டாம்.
3. உங்கள் காலவரிசையில் (timeline) ஊடுருவல் நடந்ததற்கான முதல் ஆதாரத்திற்கு முந்தைய தேதியிட்ட backup-லிருந்து தரவுகளை மட்டும் மீட்டெடுக்கவும். Database dumps, uploads, application state ஆகியவற்றை மட்டும் எடுக்கவும். /etc, /usr மற்றும் பழைய unit files-ஐத் தவிர்க்கவும்.
4. மாற்றப்பட்ட secrets-ஐ கைமுறையாக உள்ளிடவும். பழைய .env-ஐ நகலெடுக்க வேண்டாம்.
5. மீட்டெடுக்கப்பட்ட web content-ஐ மீண்டும் பயன்பாட்டிற்கு கொண்டு வருவதற்கு முன், ஊடுருவல் நடந்த காலத்தில் சேர்க்கப்பட்ட கோப்புகள் ஏதேனும் உள்ளதா என்று ஆய்வு செய்யவும்.
6. இணையத்தில் வெளியிடுவதற்கு முன் பாதுகாப்பை உறுதிப்படுத்தவும்: key-only SSH, root அல்லாத ஒரு working account, default-deny inbound firewall ஆகியவற்றை அமைக்கவும், மேலும் தேவைக்கு அதிகமாக எந்த service-ஐயும் பொதுவெளியில் வெளியிட வேண்டாம். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற வழிகாட்டியைப் பின்பற்றி, பின் SSH-ஐ முறையாகப் பாதுகாக்கவும், அதன் பிறகு Ubuntu 24.04-ல் fail2ban-ஐச் சேர்த்து login முயற்சிகளைக் குறைக்கவும். ஒவ்வொரு service-க்கும் அதற்கென குறைந்தபட்ச அதிகாரங்களைக் கொண்ட account-ஐ வழங்கவும், இதன் மூலம் அடுத்த முறை ஊடுருவல் நடந்தால் அது root-ஐ அடையாது.
7. பழைய server-ஐ அணைத்துவிடவும். விசாரணை மற்றும் abuse ticket முடிவடையும் வரை அதன் snapshot-ஐ வைத்திருக்கவும்.
8. Backup முறையைச் சரிசெய்யவும். படி 3-ல் நீங்கள் ஊகித்துச் செயல்பட வேண்டியிருந்தது என்றால், உங்கள் backup வரலாறு ஊடுருவலுக்கு முந்தைய காலத்தை எட்டவில்லை என்பதே உண்மை. நீண்ட காலம் சேமிக்கக்கூடிய, versioned off-server backups மட்டுமே அடுத்த முறை பாதுகாப்பான restore point-ஐ வழங்கும்: VPS-ல் restic backups உங்களுக்கு இரண்டையும் வழங்கும்.

ஊடுருவல் நடந்த தேதியை உங்களால் கண்டறிய முடியவில்லை என்றால், பாதுகாப்பான backup-ஐத் தேர்ந்தெடுக்க முடியாது. அத்தகைய சூழலில், உங்களால் நேரடியாகப் பார்க்கக்கூடிய தரவுகளை மட்டும் மீட்டெடுக்கவும்: உங்களால் வாசிக்கக்கூடிய SQL dump அல்லது நீங்கள் பட்டியலிடக்கூடிய images கோப்பகம். இயங்கக்கூடிய (executable) அனைத்துக் கோப்புகளையும் சந்தேகத்திற்குரியதாகக் கருதி, அவற்றை repositories-லிருந்து மீண்டும் நிறுவவும்.

உங்கள் host-லிருந்து வரும் abuse notice எதைக் குறிக்கிறது

பெரும்பாலானோர் தங்கள் server compromised ஆனதை தாங்களாகவே கண்காணிப்பதன் மூலம் அறிவதில்லை, மாறாக தங்கள் service provider மூலம் அறிகிறார்கள். பிற நெட்வொர்க்குகள் மீதான SSH brute force, port 25-ல் spam, அல்லது reflection attack-ல் பங்களிப்பு போன்ற outbound traffic-ஐ host-கள் கண்டறிகின்றன. அந்த ticket-ல் வழக்கமாக நேர முத்திரைகள் (timestamps), ports மற்றும் traffic flows-ன் மாதிரிகள், அத்துடன் சில மணிநேரங்களுக்குள் தீர்க்கப்பட வேண்டிய காலக்கெடுவும் குறிப்பிடப்பட்டிருக்கும்.

server தனிமைப்படுத்தப்பட்டு மீண்டும் கட்டமைக்கப்படுகிறது என்ற பதிலையாவது அந்த ticket-க்கு அனுப்பவும். பதில் அளிக்கப்படாத பட்சத்தில், provider-கள் server-ஐ null-route செய்வார்கள் அல்லது suspend செய்வார்கள்; இது உங்கள் சிக்கலை ஒரு முழுமையான outage-ஆக மாற்றிவிடும். அந்த அறிக்கைக்கு ஆதாரமான raw log வரிகளைக் கேட்கவும். அந்த நேர முத்திரைகள் உங்கள் கணினிக்கு வெளியே பதிவு செய்யப்பட்டவை என்பதால், அவற்றை attacker-ஆல் மாற்ற முடியாது. எனவே, disk-ல் உள்ள தகவல்களை விட, ஊடுருவல் நடந்த நேரத்தை அவை துல்லியமாகக் காட்டும்.

compromised ஆன customer server என்பது ஒரு host-க்கு வழக்கமான பணிதான், அதை நீங்கள் சரியாகக் கையாண்டால் அது உங்கள் நற்பெயரைப் பாதிக்காது. VPS hosting பாதுகாப்பானதா என்ற பரந்த கேள்வி, பெரும்பாலும் customer செய்யும் configuration-ஐப் பொறுத்தே அமைகிறது. இப்போது நீங்கள் அந்த configuration-ஐ மீண்டும் புதிதாகச் செய்யும் வாய்ப்பைப் பெற்றுள்ளீர்கள்.

நிபுணர்களின் உதவியை எப்போது நாட வேண்டும்

• அந்த server-ல் பிறருடைய தனிப்பட்ட தரவுகள் இருந்தால். GDPR (General Data Protection Regulation)-ன் கீழ், தனிப்பட்ட தரவு கசிவு ஏற்பட்டால், தாமதமின்றி சம்பந்தப்பட்ட அதிகார அமைப்பிற்குத் தெரிவிக்க வேண்டும். இது சாத்தியமானால், கசிவு கண்டறியப்பட்ட 72 மணி நேரத்திற்குள் தெரிவிக்கப்பட வேண்டும். இந்த காலக்கெடு தொடங்கிவிட்டதா என்பதைத் தீர்மானிப்பது சட்டரீதியான பணி, இது sysadmin-ன் பணி அல்ல.
• Payment card தரவுகள் பாதிக்கப்பட்டிருந்தால். Card schemes விதிகளின்படி, அங்கீகரிக்கப்பட்ட தடயவியல் ஆய்வாளர் (forensic investigator) மட்டுமே விசாரணை நடத்த வேண்டும். நீங்களாகச் சோதனைகளை மேற்கொள்வது ஆதாரங்களைச் சிதைக்கக்கூடும்.
• மிரட்டி பணம் பறிக்கும் கோரிக்கை (extortion demand) வந்தாலோ அல்லது உங்கள் தரவுகள் encrypt செய்யப்பட்டிருந்தாலோ.
• அந்த machine பிற machine-களை அணுகக்கூடிய நிலையில் இருந்தால்: அதாவது internal network, hypervisor, அல்லது production credentials கொண்ட CI runner போன்றவை. ஒரு host பாதிக்கப்பட்டால், அது முழு குழுவிற்கும் பாதிப்பு என்றுதான் கருதப்பட வேண்டும்.
• காப்பீடு அல்லது சட்ட அமலாக்கத்திற்காக ஆதாரங்கள் தேவைப்பட்டால். Snapshot-உடன் நிறுத்திவிட்டு, முழு disk image-ஐ எடுக்கவும். யார், எப்போது அதைக் கையாண்டார்கள் என்பதைப் பதிவு செய்யவும்.

சொந்தமாகச் சேவைகளை இயக்கும் ஒரு VPS-க்கு, அதில் பிறருடைய தரவுகள் இல்லை என்றால், மேலே உள்ள வழிமுறைகளே போதுமானது. Provider தளத்தில் அந்த server-ஐத் தனிமைப்படுத்தவும் (isolate). ஆதாரத்திற்காக snapshot எடுக்கவும். நம்பகமான தரவுகளை மட்டும் சேகரிக்கவும். அனைத்து credentials-ஐயும் மாற்றவும் (rotate). சுத்தமான நிலையில் மீண்டும் கட்டமைக்கவும் (rebuild).

FAQ

ஹேக் செய்யப்பட்ட VPS-ஐ மீண்டும் உருவாக்குவதற்குப் பதிலாக அதைச் சுத்தம் செய்ய முடியுமா?

நிச்சயமாக முடியாது, ஏனெனில் பாதிக்கப்பட்ட ஒரு சிஸ்டத்திடம் அதுவே தனது நிலையைப் பற்றி அறிக்கை தருமாறு நீங்கள் கேட்க முடியாது. மாற்றப்பட்ட ஒரு ps ஒரு process-ஐ மறைக்க முடியும், /etc/ld.so.preload-ல் உள்ள ஒரு வரி நீங்கள் இயக்கும் ஒவ்வொரு dynamically linked கருவியிலும் code-ஐ உட்புகுத்த முடியும், மேலும் ஒரு kernel module ஒரே நேரத்தில் அனைத்து நிரல்களிலிருந்தும் கோப்புகளை மறைக்க முடியும். நீங்கள் சிலவற்றை கண்டறியலாம், எனவே ஒரு 'hit' அர்த்தமுள்ளதாக இருக்கும். ஆனால், ஒரு விஷயம் இல்லை என்பதை உங்களால் நிரூபிக்க முடியாது, எனவே 'clean' என்ற முடிவு உண்மையானதாக இருக்காது. சர்வரில் உங்களுக்கு முக்கியமானது எதுவும் இல்லை என்றாலும், அது மீண்டும் பாதிக்கப்படலாம் என்பதை நீங்கள் ஏற்றுக்கொண்டால் மட்டுமே சுத்தம் செய்வது ஒரு தீர்வாக இருக்கும்.

பாதிக்கப்பட்ட சர்வரை ஆஃப் செய்ய வேண்டுமா அல்லது இயங்க விட வேண்டுமா?

முதலில் provider-ன் தளத்தில் அதன் network இணைப்பைத் துண்டிக்கவும், பின்னர் snapshot எடுக்கவும் இயங்கும் process-களைப் பார்க்கவும் போதுமான நேரம் அதை இயங்க விடவும். சர்வரை ஆஃப் செய்வது process பட்டியலை அழித்துவிடும், மேலும் /var/log/journal இல்லாதபோது journal-ஐ முழுமையாக நீக்கிவிடும், ஏனெனில் அப்போது journald /run-ன் கீழ் நினைவகத்தில் (memory) எழுதும். அது மற்ற நெட்வொர்க்குகளைத் தீவிரமாகத் தாக்கினால் மற்றும் அதன் வெளிச்செல்லும் traffic-ஐத் தடுக்க உங்களுக்கு வழி இல்லை என்றால், எப்படியும் அதை ஆஃப் செய்துவிடவும். ஆதாரங்களை வைத்திருப்பதை விட, பாதிப்பை நிறுத்துவதே முக்கியமானது.

தாக்குதல் நடத்தியவர் எப்போது உள்ளே நுழைந்தார் என்பதை நான் எப்படி கண்டறிவது?

/var/log/auth.log அல்லது journal-ல் உங்களால் விளக்க முடியாத மிக முந்தைய Accepted password அல்லது Accepted publickey வரியைக் கண்டறியவும். அதை find / -xdev -newerct 'YYYY-MM-DD' -type f-ல் உள்ள change-time பட்டியலுடன் ஒப்பிட்டுப் பார்க்கவும், ஏனெனில் mtime-ஐ விட ctime-ஐத் திருத்துவது கடினம். பின்னர், இரண்டையும் உங்கள் provider-ன் abuse ticket-ல் உள்ள timestamps-உடன் ஒப்பிடவும்; இவை சர்வர் இயந்திரத்திற்கு வெளியே பதிவு செய்யப்பட்டவை என்பதால் அவற்றை மாற்ற முடியாது. அந்த மூன்று தேதிகளில் மிக முந்தைய தேதிக்கு முந்தைய backup-ஐத் தேர்ந்தெடுக்கவும். எதுவும் ஒத்துப்போகவில்லை என்றால், உங்கள் backup வரலாற்றை விட பாதிப்பு பழையது என்று கருதி, உங்களால் ஆய்வு செய்யக்கூடிய தரவை மட்டும் restore செய்யவும்.

பாதிப்புக்குப் பிறகு எனது backup-களை restore செய்வது பாதுகாப்பானதா?

ஆய்வு செய்த பிறகு, தரவு பொதுவாகப் பாதுகாப்பானது. சிஸ்டம் கோப்புகள் பாதுகாப்பானவை அல்ல. ஊடுருவலுக்குப் பிறகு எடுக்கப்பட்ட backup-ல் backdoor இருக்கும், எனவே முழு root filesystem-ஐயும் restore செய்வது தாக்குதல் நடத்தியவரையும் மீண்டும் கொண்டு வரும். Backup repository-யையும் சரிபார்க்கவும்: அதற்கான credentials பாதிக்கப்பட்ட சர்வரில் சேமிக்கப்பட்டிருந்தால், வரலாறு நீக்கப்பட்டிருக்கலாம் அல்லது மாற்றப்பட்டிருக்கலாம்; இதனால்தான் append-only அல்லது pull-based backup இலக்குகள் பரிந்துரைக்கப்படுகின்றன. Application தரவை மட்டும் restore செய்துவிட்டு, distribution repositories-லிருந்து மென்பொருளை மீண்டும் நிறுவவும்.

எனது VPS பாதிக்கப்பட்டது குறித்து யாரிடமாவது சொல்ல வேண்டுமா?

உங்கள் host அனுப்பும் abuse notice-க்கு எப்போதும் பதிலளிக்கவும். அதைத் தாண்டி, அந்த இயந்திரத்தில் யாருடைய தரவு இருந்தது என்பதைப் பொறுத்தது. மற்றவர்களுக்குச் சொந்தமான தனிப்பட்ட தரவு இருந்தால், அது சட்டப்பூர்வமான அறிவிப்பு கடமையைத் தூண்டலாம், உதாரணமாக GDPR-ன் கீழ் 72 மணிநேரத்திற்குள் மேற்பார்வை ஆணையத்திற்குத் தெரிவிக்க வேண்டும். சர்வரில் பயனர் credentials சேமிக்கப்பட்டிருந்தால், அந்த பயனர்களுக்குத் தெரிவிக்கவும், அப்போதுதான் அவர்கள் மற்ற இடங்களில் கடவுச்சொற்களை மாற்ற முடியும். சர்வரில் உள்ள keys மூன்றாம் தரப்பு அமைப்புகளுக்கான (code host அல்லது cloud account போன்றவை) அணுகலை வழங்கியிருந்தால், அந்த providers-க்குத் தெரிவிக்கவும், அப்போதுதான் அவர்கள் தவறான பயன்பாடு உள்ளதா என்று சரிபார்க்க முடியும். மற்றவர்களின் தரவு இல்லாத முற்றிலும் தனிப்பட்ட சர்வர் என்றால், abuse ticket-க்கு பதிலளிப்பதைத் தவிர வேறு எந்தக் கடமையும் இல்லை.