VPS abuse complaint என்றால் என்ன? அதை கையாள்வது எப்படி?

VPS abuse complaint என்பது உண்மையில் என்ன

VPS abuse complaint என்பது உங்கள் IP address-லிருந்து வெளியேறிய network traffic குறித்த ஒரு புகாராகும். இது அந்த IP block-க்கு பொதுவெளியில் குறிப்பிடப்பட்டுள்ள abuse contact முகவரிக்கு அனுப்பப்பட்டு, பின்னர் உங்கள் host நிறுவனத்தால் உங்களுக்குத் தெரிவிக்கப்படுகிறது; இதற்குப் பதிலளிக்க ஒரு குறிப்பிட்ட கால அவகாசம் வழங்கப்படும். அந்த IP address space-ஐ வைத்திருக்கும் நிறுவனமே பொதுத் தொடர்புக்குப் பொறுப்பானது என்பதால், உங்கள் server குறித்த புகாரை முதலில் படிப்பவர் நீங்கள் அல்ல. உங்கள் host நிறுவனம் அந்த IP மற்றும் timestamp-ஐ உங்கள் கணக்குடன் ஒப்பிட்டு, புகாரை உங்களுக்கு அனுப்பி வைக்கிறது.

இந்த அறிவிப்பு நீங்கள் வேண்டுமென்றே எதையும் செய்தீர்கள் என்பதற்கு ஆதாரமல்ல. புகாரளிப்பவருக்குத் தெரிந்த ஒரே அடையாளம் IP address மட்டுமே. ஒரு compromised application அதிகாலை 03:00 மணிக்கு spam அனுப்பினால், ஒரு நபர் அதே நேரத்தில் spam அனுப்பினால் கிடைக்கும் அதே புகார்தான் இதற்கும் வரும். இதனால்தான் உங்கள் பதில் மிக முக்கியமானது. அந்த traffic-ன் மூலம் எது மற்றும் நீங்கள் என்ன மாற்றங்களைச் செய்துள்ளீர்கள் என்பதுதான் உங்களிடம் கேட்கப்படுகிறது.

அறிக்கையை அனுப்புவது யார், அது உங்கள் host-ஐ எப்படி வந்தடைகிறது

ஒவ்வொரு பொது IP தொகுதியும் ஒரு பிராந்திய இணையப் பதிவகத்தில் (RIR) பதிவு செய்யப்பட்டுள்ளது: RIPE NCC, ARIN, APNIC, LACNIC அல்லது AFRINIC. ஒவ்வொரு பதிவும் ஒரு துஷ்பிரயோகத் தொடர்பு முகவரியை (abuse contact) வெளியிடுகிறது, அங்குதான் அறிக்கைகள் செல்கின்றன. அறிக்கையாளர் படிக்கும் அதே பதிவை நீங்களும் படிக்கலாம்:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

RIPE பதிவுகள் abuse-c: role object-ஐக் கொண்டுள்ளன, அதில் abuse-mailbox: வரி உள்ளது. ARIN பதிவுகள் OrgAbuseEmail:-ஐக் கொண்டுள்ளன. அங்கு வெளியிடப்பட்ட எந்த முகவரிக்கும் புகார் செல்லும், இதனால்தான் உங்கள் server பற்றிய அறிக்கை உங்கள் inbox-க்கு வராமல் உங்கள் host-க்கு வருகிறது.

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

• தானியங்கி ஸ்கேனர்கள் மற்றும் honeypots. உங்கள் IP-யிலிருந்து ஒரு இணைப்பு முயற்சி நடப்பதை ஒரு இயந்திரம் பதிவு செய்து, log-ன் ஒரு பகுதியை இணைத்து அறிக்கையைச் சமர்ப்பிக்கிறது.
• அஞ்சல் பெட்டி வழங்குநர்களால் இயக்கப்படும் feedback loops (FBL). ஒரு பெறுநர் junk பொத்தானைக் கிளிக் செய்யும்போது, அந்தச் செய்தியின் நகல் ARF (abuse reporting format)-ல் திரும்ப வரும்; இது இயந்திரங்கள் பகுப்பாய்வு செய்ய உருவாக்கப்பட்ட ஒரு கட்டமைக்கப்பட்ட மின்னஞ்சல் வடிவம்.
• பதிப்புரிமை முகவர்கள். இவர்கள் torrent swarms-ஐக் கண்காணிப்பார்கள் அல்லது பொது URL-களை ஊர்ந்து சென்று (crawl), DMCA (digital millennium copyright act) அறிவிப்பை அனுப்புவார்கள். அதில் கோப்பின் பெயர், உங்கள் IP மற்றும் UTC நேர முத்திரை ஆகியவை இருக்கும்.
• Blocklist இயக்குநர்கள் மற்றும் பிணையப் பொறியாளர்கள், இவர்கள் தங்கள் சொந்த log-களில் உள்ள தவறு செய்யும் வரிகளுடன் ஒரு சிறிய மின்னஞ்சலை அனுப்புவார்கள்.

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

அறிவிப்பில் ஏன் காலக்கெடு குறிப்பிடப்படுகிறது

உங்கள் host-ம் ஒரு வாடகைதாரர் தான். அதன் address space, upstream carriers-க்கு பின்னாலும், பிறர் நிர்வகிக்கும் reputation databases-க்கு உள்ளேயும் உள்ளது. பதிலளிக்கப்படாத புகார்கள், உங்கள் தனிப்பட்ட address-ஐ மட்டும் பாதிக்காமல், ஒட்டுமொத்த block-ன் மதிப்பீட்டையும் (score) உயர்த்தும். எனவே, உங்களுக்கு வழங்கப்படும் காலக்கெடு என்பது மேலிருந்து வரும் அழுத்தமாகும். அறிவிப்பில் குறிப்பிடப்பட்டுள்ள கால அவகாசத்தைப் படித்து, அதை உண்மையானதாகக் கருதி செயல்படுங்கள்.

பதிலளிக்கப்படாத ஒரு வழக்கில் நடவடிக்கை எடுக்கப்படும்போது, பொதுவாக அது null route செய்யப்படுகிறது. அதாவது, அந்த குறிப்பிட்ட IP-க்கான traffic upstream-லேயே தடுக்கப்படும் அல்லது அந்த instance தற்காலிகமாக நிறுத்தப்படும். இந்த நடவடிக்கையைத் தூண்டுவது அசல் நிகழ்வு அல்ல, மாறாக உங்கள் மௌனம் தான். ஒரு குறிப்பிட்ட host என்ன செய்யும், எப்போது செய்யும் என்பது அதன் சொந்த policy-யிலும், அறிவிப்பிலும் எழுதப்பட்டிருக்கும். அந்த இரண்டு ஆவணங்கள் மட்டுமே மேற்கோள் காட்டத் தகுந்தவை. எனவே, ஒரு provider எதை அனுமதிக்கிறார் என்று forum-களில் கூறப்படுவதை வைத்துச் செயல்பட வேண்டாம்.

Outbound spam: உங்கள் VPS நீங்கள் அனுப்பாத மின்னஞ்சல்களை ஏன் அனுப்புகிறது

உங்கள் IP முகவரி ஒரு spam trap-க்கு மின்னஞ்சல் அனுப்பியதாகவோ அல்லது பெறுநர்கள் உங்கள் மின்னஞ்சலை junk என்று குறிப்பிட்டதாகவோ அறிக்கை கூறுகிறது. பெரும்பாலான சந்தர்ப்பங்களில் நான்கு காரணங்கள் இதற்கு அடிப்படையாக அமைகின்றன: rate limit இல்லாத மின்னஞ்சல் படிவம் கொண்ட ஒரு web application, கசிந்த SMTP credential-ஐ வேறொருவர் பயன்படுத்துதல், அனுமதிக்கப்படாத host-களுக்கு relay செய்யும் ஒரு mail server, மற்றும் newsletter application-ல் திருடப்பட்ட login. முதலில் queue-வைச் சரிபார்க்கவும், ஏனெனில் பாதிக்கப்பட்ட sender பொதுவாக அங்குதான் தெரிவார்:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

உங்களுக்குத் தெரியாத முகவரிகளுக்கு ஆயிரக்கணக்கான செய்திகள் queue-வில் இருந்தால், உங்கள் server மின்னஞ்சல்களை அனுப்புகிறது என்று அர்த்தம். அடுத்து, யார் authenticate செய்தார்கள் என்பதைக் கண்டறியவும்:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

மற்றவற்றை விட மிக அதிகமான எண்ணிக்கையைக் கொண்ட ஒரு account, கசிந்த credential-ஐக் குறிக்கிறது. /var/log/mail.log இல்லை என்றால், அந்த system-ல் rsyslog நிறுவப்படவில்லை என்று அர்த்தம்; அப்போது அதே வரிகள் journal-ல் இருக்கும்: sudo journalctl -t postfix --since '2 days ago'.

எந்த account-ம் authenticate செய்யவில்லை என்றால், ஒரு local process மின்னஞ்சலை அனுப்புகிறது. Relay விதிகள் மற்றும் திறந்திருக்கும் connections-ஐச் சரிபார்க்கவும்:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

இயல்பான Debian அல்லது Ubuntu Postfix, அந்நியர்களுக்கு relay செய்யாது. mynetworks-ஐ கைமுறையாக ஒரு முழு hosting subnet-க்கு விரிவுபடுத்தும்போது அது open relay ஆக மாறுகிறது, ஏனெனில் அந்த subnet-ல் உள்ள மற்ற அனைத்து வாடிக்கையாளர்களும் உங்கள் வழியாக மின்னஞ்சல் அனுப்ப நம்பகமானவர்களாகக் கருதப்படுவார்கள். உங்கள் mail server அல்லாத ஒரு process-க்குச் சொந்தமான port 25-ன் எந்தவொரு connection-ம், தானாகவே மின்னஞ்சல் அனுப்பும் ஒரு script ஆகும்; இதுவே பாதிக்கப்பட்ட PHP application பொதுவாகச் செய்யும் செயலாகும்.

ஆய்வு செய்வதற்கு முன் மின்னஞ்சல் போக்குவரத்தை நிறுத்திவிட்டு, ஆதாரங்களைச் சேமிக்கவும்:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL queue-வை காலி செய்யும், ஆனால் அது அனுப்பப்பட்ட செய்திகளின் பதிவுகளையும் அழித்துவிடும், எனவே முதலில் ஒரு நகலை எடுத்துக்கொள்ளவும். அதன் பிறகு, application வைத்திருக்கும் அனைத்து credential-களையும் மாற்றவும், application-ஐ update செய்யவும், மற்றும் ஊடுருவியவர் விட்டுச் சென்றவற்றைக் கண்டறியவும். ஒரு spam சம்பவம் மற்றும் ஒரு compromise ஆகிய இரண்டும் பெரும்பாலும் ஒரே நிகழ்வுதான், எனவே queue-வை மட்டும் காலி செய்யாமல் hack செய்யப்பட்ட VPS-ஐ மீட்டெடுக்கும் வழிமுறைகளை முழுமையாகப் பின்பற்றவும்.

Port scanning மற்றும் brute force: சமரசம் செய்யப்பட்ட container-ன் தோற்றம்

இந்த அறிக்கை மற்றொரு ஆபரேட்டரின் log-களிலிருந்து பெறப்பட்ட வரிகளைக் கொண்டுள்ளது, அவை பின்வருமாறு அமையும்:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

நீங்கள் firewall மூலம் பாதுகாக்கப்பட்டதாகக் கருதிய ஒரு service-ல் ஏற்படும் குறைபாடே இதற்கு பெரும்பாலும் காரணமாகிறது. Docker-ல் இது அடிக்கடி நிகழ்கிறது. -p 6379:6379 மூலம் ஒரு port-ஐ வெளியிடும்போது, அது DOCKER-USER மற்றும் nat chains-ல் விதிகளை எழுதிவிடுகிறது. இவை ufw-ன் விதிகளுக்கு முன்பே மதிப்பீடு செய்யப்படுவதால், ufw deny 6379 அதைத் தடுப்பதில்லை; இதனால் அந்த database இணையம் முழுமைக்கும் பதிலளிக்கிறது.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

ss -ltnp-ல் 0.0.0.0 அல்லது [::]-க்கு bound செய்யப்பட்ட எதுவாக இருந்தாலும், அது public address-ல் listening நிலையில் இருக்கும். host-க்கு மட்டுமே தேவைப்படும்போது, அதற்குப் பதிலாக loopback address-ல், அதாவது -p 127.0.0.1:6379:6379-ல் publish செய்யவும். ஒரு database-ஐ எங்கு இயக்குவது என்பது தனிப்பட்ட முடிவு, Docker-ல் அல்லது host-ல் database-ஐ இயக்குவது குறித்த கட்டுரை அந்தத் தேர்வுகளை விளக்குகிறது.

உங்கள் server தற்போது scanning செய்கிறதா என்பதை அறிய:

sudo ss -tnp state syn-sent

வெவ்வேறு இடங்களுக்கு அதிகப்படியான half-open connections இருப்பது, outbound scan நடைபெறுவதைக் குறிக்கிறது. kernel log-ல் nf_conntrack: table full, dropping packet நிரம்புவதும் இதையே உறுதிப்படுத்துகிறது: இந்த server-ன் தேவைக்கு அதிகமாக ஏதோ ஒன்று அதிகப்படியான இணைப்புகளைத் திறந்துகொண்டிருக்கிறது.

சமரசம் செய்யப்பட்ட container-ஐ சுத்தம் செய்வதற்குப் பதிலாக, அதை மீண்டும் உருவாக்கவும் (rebuild). அதற்குள் வேறு என்ன மாற்றங்கள் செய்யப்பட்டன என்பதை உங்களால் நிரூபிக்க முடியாது என்பதால், நீங்கள் நம்பும் image-லிருந்து மீண்டும் உருவாக்கி, நீங்கள் நம்பும் தரவை மட்டும் restore செய்து, அந்த container-ல் இருந்த keys-ஐ rotate செய்யவும்.

பதிப்புரிமை அறிவிப்புகள்: அவர்கள் உண்மையில் பார்த்த கோப்பு எது

ஒரு DMCA அறிவிப்பு ஒரு URL அல்லது torrent info hash, உங்கள் IP, மற்றும் UTC நேர முத்திரையைக் குறிப்பிடுகிறது. ஏறக்குறைய அனைத்து அறிவிப்புகளுக்கும் இரண்டு காரணங்களே உள்ளன: இணைய சேவையகத்தில் (web server) மீடியா கோப்புகளுடன் பொதுப்பார்வைக்கு விடப்பட்ட ஒரு அடைவு (directory), மற்றும் பதிவிறக்கம் முடிந்த பிறகும் seeding-ல் இருக்கும் ஒரு torrent client.

நேர முத்திரையை access log-உடன் ஒப்பிட்டுப் பார்க்கவும். Nginx combined log format-ல் status 9-வது புலத்திலும், கோரப்பட்ட பாதை (request path) 7-வது புலத்திலும் இருக்கும்:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

எதுவும் வழங்கப்படவில்லை (served) என்று முடிவெடுக்கும் முன், கடிகாரத்தைச் சரிபார்க்கவும். அறிவிப்பு UTC-ல் உள்ளது, ஆனால் உங்கள் logs சேவையகத்தின் timezone-ஐப் பயன்படுத்துகின்றன. எனவே, சில மணிநேர வேறுபாடு உங்களைத் தவறான கால இடைவெளியில் தேட வைத்து, தவறான எதிர்மறை முடிவைத் (false negative) தரும்:

timedatectl
sudo timedatectl set-timezone UTC

பின்பு அதற்கான காரணத்தைச் சரிசெய்யவும். கோப்பை நீக்கவும் அல்லது கட்டுப்படுத்தவும், nginx location block-ல் autoindex off; மூலம் directory listing-ஐ முடக்கவும், மேலும் torrent client-ஐ பொதுப்பயன்பாட்டில் இல்லாத ஒரு interface-உடன் இணைக்கவும் (bind). கோப்பின் பெயர், நீங்கள் செய்த மாற்றம் மற்றும் அதைச் செய்த நேரம் ஆகியவற்றைக் குறிப்பிட்டுப் பதிலளிக்கவும். உரிமைகோரலே தவறானது என்று நீங்கள் கருதினால், அது உங்களுக்கும் அனுப்புநருக்கும் இடையிலான சட்டப்பூர்வமான விவகாரம்; அதை எப்படி மறுப்பது என்பதை அறிவிப்பிலேயே குறிப்பிட்டிருப்பார்கள். உங்கள் host நிறுவனம் இதில் முடிவெடுக்கும் தரப்பு அல்ல, எனவே அதன் தகுதியைப் பற்றி விவாதிக்கும் ticket-களால் எந்தப் பயனும் இருக்காது.

Blocklist பட்டியல்கள்: எனது வெளிச்செல்லும் மின்னஞ்சல் ஏன் வேலை செய்வதை நிறுத்தியது

இது பெரும்பாலும் உங்களுக்கு எந்த மின்னஞ்சலும் வராத சூழலில் நிகழும். வெளிச்செல்லும் மின்னஞ்சல்கள் ஏற்றுக்கொள்ளப்படாமல் நின்றுவிடும், மேலும் வரும் bounce செய்தியில் அதற்கான காரணம் குறிப்பிடப்பட்டிருக்கும்:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

IP-ன் நான்கு octet-களையும் தலைகீழாக மாற்றி, அந்தப் பட்டியலின் zone-ஐ query செய்வதன் மூலம் நீங்கள் பட்டியலிடப்பட்டுள்ளீர்களா என்று சரிபார்க்கவும்:

dig +short 10.113.0.203.zen.spamhaus.org

பதில் எதுவும் வரவில்லை என்றால், நீங்கள் அந்தப் பட்டியலில் இல்லை என்று அர்த்தம். 127.0.0.x என்ற பதில் வந்தால், நீங்கள் பட்டியலிடப்பட்டுள்ளீர்கள் என்று பொருள்; கடைசி octet எந்த sublist-ல் நீங்கள் உள்ளீர்கள் என்பதைக் குறிக்கும். 127.255.255.x வரம்பில் பதில் வந்தால், அந்த query நிராகரிக்கப்பட்டுள்ளது என்று அர்த்தம். பொதுவாக, பெரிய public resolver வழியாக query அனுப்பப்படும்போது இது நிகழும், ஏனெனில் இலவச சேவைகள் அவற்றை அனுமதிப்பதில்லை. சரியான முடிவைப் பெற, server-ன் சொந்த resolver-ஐப் பயன்படுத்தி மீண்டும் இயக்கவும்.

Delisting என்பது உங்கள் host மூலம் அல்ல, அந்தப் பட்டியலை நிர்வகிக்கும் தளத்தின் மூலமே செய்யப்பட வேண்டும். மூலக் காரணம் சரிசெய்யப்பட்டால் மட்டுமே இது நீடிக்கும், இல்லையெனில் அடுத்த மின்னஞ்சலை அனுப்பும்போது மீண்டும் அதே trap உங்களைப் பட்டியலிட்டுவிடும். மின்னஞ்சல் தொடர்ந்து செல்வதை உறுதி செய்ய மேலும் இரண்டு விஷயங்கள் உள்ளன. உங்கள் IP-க்கான PTR record (reverse DNS name) உங்கள் host-ன் கட்டுப்பாட்டில் உள்ளது; எனவே, அதே முகவரிக்கு மீண்டும் resolve ஆகும் வகையில் ஒன்றை அமைக்கச் சொல்லுங்கள், அந்தப் பெயரை உங்கள் HELO-வாகப் பயன்படுத்துங்கள். மேலும், முன்னால் இருந்த பயனர் பயன்படுத்திய முகவரி உங்களுக்குக் கிடைத்தால், அது நீங்கள் உருவாக்காத ஒரு வரலாற்றைக் கொண்டிருக்கலாம்; DNS-ஐ மாற்றி அமைக்க ஒரு வாரம் செலவிடும் முன் இதைப் பற்றி விசாரிப்பது நல்லது. SPF (sender policy framework) மற்றும் DKIM (domainkeys identified mail) record-களைச் சரியாக அமைப்பது, மற்றும் அவற்றை இணைக்கும் DMARC policy ஆகியவற்றை Mailcow மூலம் உங்கள் சொந்த மின்னஞ்சல் server-ஐ இயக்குவதற்கான வழிகாட்டி-யில் முழுமையாகக் காணலாம்.

துஷ்பிரயோக மின்னஞ்சல்கள் வேலையின் ஒரு பகுதியாக இருக்கும் Relay உள்கட்டமைப்பு

நீங்கள் ஒரு Tor exit node, பொது VPN, அல்லது பிறருக்காக ஒரு proxy-ஐ இயக்கினால், நீங்கள் உருவாக்காத traffic குறித்த புகார்கள் வருவது இயல்பான பராமரிப்புச் செலவாகும். உங்கள் server ஒரு compromised box போல இல்லாமல், ஒரு relay போலத் தெரிவது அவசியம். Reverse DNS-க்கு ஒரு விளக்கமான பெயரை அமைக்கவும், port 80-ல் இந்த முகவரி எதற்கானது என்பதை விளக்கும் ஒரு சிறிய அறிவிப்புப் பக்கத்தை (notice page) வைக்கவும், அதே விளக்கத்துடன் துஷ்பிரயோக மின்னஞ்சல்களுக்கு விரைவாகப் பதிலளிக்கவும், மேலும் அதிக புகார்களை உருவாக்கும் ports-ஐத் தடுக்க மென்பொருள் வழங்கும் policy-ஐப் பயன்படுத்தவும். இதை அதன் சொந்த IP முகவரியில் இயக்கவும், முடிந்தால் தனி instance-ஆக இயக்கவும்; அப்போதுதான் அந்த முகவரி null route செய்யப்பட்டால், உங்கள் web application பாதிக்கப்படாது. தொடங்குவதற்கு முன் உங்கள் host-இடம் கேளுங்கள், ஏனெனில் நிறுவனத்திற்கு நிறுவனம் மற்றும் சில நேரங்களில் IP block-க்கு ஏற்ப அனுமதிக்கப்படுபவை மாறுபடும்; இது ஒரு forum விவாதத்திற்குரியது அல்ல, உங்கள் host-இடம் கேட்க வேண்டிய கேள்வி. VPS-ல் Tor exit node-ஐ இயக்குதல் பகுதி exit policy மற்றும் அறிவிப்புப் பக்கம் குறித்து விரிவாக விளக்குகிறது.

டிக்கெட்டை முடிப்பதற்கான பதிலளிக்கும் முறை

• ஒரு நபர் வாசிக்கும்படியான contact முகவரியை வெளியிடவும். RFC 2142 தரநிலையின்படி, abuse@ மற்றும் postmaster@ ஆகிய முகவரிகளையே புகாரளிப்பவர்கள் முதலில் முயற்சிப்பார்கள். அந்த மின்னஞ்சல் பெட்டியை, அது பாதுகாக்கும் server-ல் வைக்காமல் வேறொரு இடத்தில் ஹோஸ்ட் செய்யவும். ஏனெனில், ஒரு server suspended செய்யப்பட்டால், அது ஏன் suspended செய்யப்பட்டது என்ற அறிவிப்பை உங்களால் பெற முடியாது.
• புகார்களுக்குப் பதிலளிக்கும் வகையில் logs-ஐ போதுமான காலம் வைத்திருக்கவும். ஏழு நாட்களுக்குப் பிறகு log rotate செய்யப்பட்டால், பன்னிரண்டு நாட்களுக்கு முந்தைய traffic குறித்த புகாருக்கு உங்களால் பதிலளிக்க முடியாது. journalctl --disk-usage-ஐ சரிபார்க்கவும், /etc/systemd/journald.conf-ல் MaxRetentionSec=90d-ஐ அமைக்கவும், பின் sudo systemctl restart systemd-journald-ஐ இயக்கவும். Web மற்றும் mail logs ஆகியவை /etc/logrotate.d/-ன் கீழ் அவற்றின் சொந்த கால அட்டவணையில் rotate ஆகும்.
• Server-ஐ UTC நேரத்திலேயே வைத்திருக்கவும். அப்போதுதான் புகாரில் உள்ள timestamp-ம் உங்கள் log-ல் உள்ள timestamp-ம் எந்தக் கணக்கீடும் இன்றி ஒத்துப்போகும்.
• புகார்களை ஈர்க்கும் சேவைகளையும், நீங்கள் இழக்கக்கூடாத முக்கியமான சேவைகளையும் தனித்தனியாகப் பிரிக்கவும். மின்னஞ்சலை ஒரு முகவரியிலும், web application-ஐ வேறொன்றிலும், relay services-ஐ தனி instance-லும் வைக்கவும். ஒரு IP மீது எடுக்கப்படும் நடவடிக்கை, அதன் பின்னால் உள்ள அனைத்தின் மீதும் எடுக்கப்படும் நடவடிக்கையாகும்.
• விசாரணை முடிவடையாத நிலையிலும், குறிப்பிட்ட காலக்கெடுவுக்குள் பதிலளிக்கவும். ஒரு குறிப்பிட்ட நேரத்தைக் குறிப்பிட்டு அனுப்பப்படும் பதில், முதல் கட்டத்திற்குப் போதுமானதாகும்.

பெரும்பாலான டிக்கெட்டுகளை முடிவுக்குக் கொண்டுவரும் முதல் பதில் சுருக்கமாகவும் தெளிவாகவும் இருக்க வேண்டும்:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

உங்களுக்குத் தெரிந்ததைச் சொல்லுங்கள், இன்னும் எதைக் கண்டறியவில்லை என்பதையும் குறிப்பிடுங்கள். நீங்கள் மௌனமாக இருந்தால், அந்த server பராமரிக்கப்படவில்லை என்று கருதப்படும். பராமரிக்கப்படாத server-களுக்கு escalation path பயன்படுத்தப்படும். இந்த வேலைகள் அனைத்தும் உங்களைச் சார்ந்ததா என்பது நீங்கள் வாங்கிய product-ஐப் பொறுத்தது. இதுவே managed மற்றும் unmanaged VPS hosting இடையே உள்ள நடைமுறை வேறுபாடாகும். Unmanaged திட்டத்தில், வாடகைதாரரே (tenant) பாதுகாப்புப் பொறுப்பாளராகச் செயல்பட வேண்டும்.

எல்லாம் சரியாக நடக்கும்போது இது எப்படி இருக்கும்

ஒரு abuse complaint என்பது எல்லாவற்றிற்கும் மேலாக ஒரு routing சிக்கலாகும். ஒரு IP address குறித்த புகார், அந்த முகவரிக்கு பொறுப்பான தரப்பினருக்குச் சென்று, அதைச் சரிசெய்யக்கூடிய நபருக்குக் கொண்டு செல்லப்படுகிறது. உங்கள் தொடர்பு முகவரி, log retention, உங்கள் சேவைகள் எவ்வாறு வெவ்வேறு IP-களில் பிரிக்கப்பட்டுள்ளன, மற்றும் நீங்கள் எவ்வளவு விரைவாகப் பதிலளிக்கிறீர்கள் ஆகியவற்றை நீங்கள் கட்டுப்படுத்தலாம். இவற்றைச் சரியாகச் செய்தால், பெரும்பாலான அறிவிப்புகள் ஒரு பரிமாற்றத்துடன் முடிந்துவிடும். VPS hosting பாதுகாப்பானதா என்ற பெரிய கேள்விக்கும் இதே பழக்கவழக்கங்களே தீர்வாக அமைகின்றன, ஏனெனில் யாரும் கவனிக்காத ஒரு server தான் மற்றவர்களின் logs-ல் சிக்கிக்கொள்கிறது.

FAQ

துஷ்பிரயோகப் புகார் (abuse complaint) வந்தாலே என் VPS ஹேக் செய்யப்பட்டுவிட்டதா?

அப்படியல்ல, ஆனால் முதலில் இதைத்தான் உறுதிப்படுத்த வேண்டும். உங்கள் IP-யிலிருந்து traffic வெளியேறியதை மட்டுமே அந்த அறிக்கை நிரூபிக்கிறது. கணக்கு உரிமையாளரை விட, பாதிக்கப்பட்ட application அல்லது container மூலமாகவே outbound spam மற்றும் port scanning அதிகம் நடக்கின்றன. எனவே, எதையும் செய்வதற்கு முன் sudo postqueue -p மூலம் mail queue-ஐயும், sudo ss -ltnp மூலம் listening sockets-ஐயும் சரிபார்க்கவும். பதிப்புரிமை (copyright) மற்றும் blocklist அறிவிப்புகள் வேறுபட்டவை: நீங்கள் வேண்டுமென்றே இயக்கும் ஏதோ ஒன்றையே அவை சுட்டிக்காட்டுகின்றன.

துஷ்பிரயோக அறிவிப்புக்கு பதிலளிக்க எனக்கு எவ்வளவு காலம் உள்ளது?

உங்களுக்கு வந்த அறிவிப்பிலேயே அதற்கான காலக்கெடு குறிப்பிடப்பட்டிருக்கும்; இது host மற்றும் புகாரின் வகையைப் பொறுத்து மாறுபடும். பதிப்புரிமை மற்றும் spam-trap புகார்கள் மிகக் குறுகிய காலக்கெடுவைக் கொண்டிருக்கும். அந்த நேரத்தை உண்மையானதாகக் கருதி, காரணத்தைக் கண்டறியும் முயற்சியில் இருக்கும்போதே, காலாவதியாகும் முன் ஒரு சுருக்கமான இடைக்காலப் பதிலை அனுப்பவும். ஒரு மனிதர் இந்த விவகாரத்தைக் கவனிக்கிறார் என்பதும், traffic நிறுத்தப்பட்டுவிட்டது என்பதுமே அந்த ticket-ஐக் கையாள்பவருக்கு முக்கியம்.

என் IP ஒரு blocklist-ல் உள்ளது. என் host அதை நீக்க முடியுமா?

முடியாது. அந்தப் பட்டியலை நிர்வகிப்பவர்களே அவர்களின் தளத்தில் delisting செய்வார்கள்; அவர்களின் database மீது உங்கள் host-க்கு எந்தக் கட்டுப்பாடும் இல்லை. உங்கள் IP-க்கான PTR record எனப்படும் reverse DNS பெயரை உங்கள் host-ஆல் மாற்ற முடியும்; அதை அதே நேரத்தில் கோருவது நல்லது. delisting கோரும் முன், அனுப்பும் சிக்கலைச் சரிசெய்யவும்; ஏனெனில் உங்களைப் பட்டியலிட்ட அதே spam trap, அடுத்த செய்தி வரும்போது மீண்டும் உங்களைப் பட்டியலிடும்.

உண்மையில் என்ன நடந்தது என்பதை என் host-க்குச் சொல்ல வேண்டுமா?

ticket-ஐ முடிப்பதற்குத் தேவையான தகவலை மட்டும் சொன்னால் போதும்: சிக்கலின் மூலம் எது, அது எப்போது நிறுத்தப்பட்டது என்பதைத் தெரிவிக்கவும். நீங்கள் forensic அறிக்கை அல்லது உங்கள் பயனர்களின் தரவுகளைத் தர வேண்டிய அவசியமில்லை. தெளிவற்ற பதிலை விடச் சிறிய பதில் சிறந்தது; என்ன மாற்றம் செய்யப்பட்டது என்று தெரியாத பட்சத்தில், அந்த விவகாரம் தீர்க்கப்பட்டதாகக் கருத அந்த அதிகாரியிடம் எந்தக் காரணமும் இருக்காது.

ஸ்கேனரிலிருந்து வரும் தானியங்கி அறிக்கையைப் புறக்கணிக்கலாமா?

கூடாது. தானியங்கி அறிக்கைகள் கணக்கிடப்படுகின்றன; ஒரே IP குறித்து மீண்டும் மீண்டும் வரும் அறிக்கைகள் உங்கள் host-ன் முழு address block-ன் மதிப்பீட்டைக் குறைக்கும். இதுவே ஒரு சிறிய சிக்கலை தீவிரமானதாக மாற்றும். உங்கள் பதில் ஒரு பத்தியாக இருக்கலாம். தானியங்கி அறிக்கை அனுப்பும் கருவி அதை வாசிக்காது, ஆனால் உங்கள் host-ல் அந்த ticket-ஐக் கையாளும் நபர் அதைப் படிப்பார். அவரே உங்கள் instance-க்கு என்ன நடக்கும் என்பதை முடிவு செய்பவர்.