VPS abuse तक्रार म्हणजे काय? अहवालाला कसे उत्तर द्यावे

VPS abuse तक्रार प्रत्यक्षात काय असते

VPS abuse तक्रार म्हणजे तुमच्या IP address वरून बाहेर गेलेल्या network traffic बद्दलचा अहवाल. हा अहवाल त्या IP block साठी प्रकाशित केलेल्या abuse contact कडे पाठवला जातो. त्यानंतर तुमचा host तुम्हाला उत्तर देण्यासाठी ठरावीक कालावधी देऊन तो अहवाल पुढे पाठवतो. प्रकाशित contact हा address space धारण करणाऱ्या कंपनीचा असतो. त्यामुळे तुमच्या server बद्दलचा अहवाल सर्वप्रथम वाचणारी व्यक्ती जवळजवळ कधीही तुम्ही नसता. तुमचा host IP आणि timestamp तुमच्या account शी जुळवतो आणि अहवाल तुम्हाला पाठवतो.

तुम्ही हे जाणूनबुजून केले याचा notice हा कोणताही पुरावा नाही. अहवाल देणाऱ्या व्यक्तीकडे IP address हाच एकमेव identifier असतो. 03:00 वाजता spam पाठवणारे compromised application आणि 03:00 वाजता spam पाठवणारी व्यक्ती यांच्यामुळे समान अहवाल तयार होतो. म्हणून reply महत्त्वाचा असतो. त्या network traffic चा source कोणता होता आणि तुम्ही कोणते बदल केले, हे तुम्हाला सांगण्यास सांगितले जाते.

अहवाल कोण पाठवतो आणि तो तुमच्या host पर्यंत कसा पोहोचतो

प्रत्येक सार्वजनिक IP block ची नोंद प्रादेशिक internet registry (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: line असते. ARIN नोंदींमध्ये OrgAbuseEmail: असते. तेथे प्रकाशित केलेल्या पत्त्यावरच तक्रार पोहोचते. म्हणून तुमच्या server विषयीचा अहवाल तुमच्या inbox मध्ये न येता तुमच्या host पर्यंत पोहोचतो.

अहवाल पाठवणारी यंत्रणा सहसा machine असते. तुम्हाला आढळणाऱ्या जवळजवळ सर्व प्रकरणांसाठी चार प्रकार पुरेसे आहेत:

• Automated scanners आणि honeypots. एखादी machine तुमच्या IP कडून झालेला connection attempt नोंदवते आणि log excerpt जोडून अहवाल पाठवते.
• Mailbox providers चालवणारे feedback loops (FBL). प्राप्तकर्ता junk button क्लिक करतो आणि संदेशाची प्रत ARF (abuse reporting format) मध्ये परत येते. हा machines ना parse करता यावा यासाठी तयार केलेला structured mail format आहे.
• Copyright agents. ते torrent swarms चे निरीक्षण करतात किंवा public URLs crawl करतात. त्यानंतर file, तुमचा IP आणि UTC मधील timestamp नमूद करणारी DMCA (digital millennium copyright act) notice पाठवतात.
• Blocklist operators आणि network engineers. ते त्यांच्या स्वतःच्या logs मधील offending lines असलेला छोटा mail पाठवतात.

पहिले बहुतेक अहवाल स्वयंचलितपणे तयार होतात. त्यामुळे उत्तरात केलेला युक्तिवाद निष्फळ ठरतो. तथ्य मात्र अत्यंत महत्त्वाचे असते: काय चालू होते आणि ते कधी थांबले.

मुदत देऊन सूचना का येते

तुमचा host देखील एका tenant प्रमाणेच असतो. त्याचा address space upstream carriers मागे आणि इतर संस्था चालवत असलेल्या reputation databases मध्ये नोंदलेला असतो. अहवालांना उत्तर न दिल्यास गुणांकन केवळ तुमच्या एका address विरुद्ध न वाढता संपूर्ण block विरुद्ध वाढते. त्यामुळे तुम्हाला मिळणारी मुदत ही वरच्या स्तरावरून खाली पाठवलेला दबाव असतो. सूचनेत दिलेली window वाचा आणि ती प्रत्यक्ष लागू आहे असे समजा.

उत्तर न दिलेल्या प्रकरणावर कारवाई झाल्यास ती सहसा null route असते. याचा अर्थ त्या एकाच IP कडे जाणारा network traffic upstream स्तरावर drop केला जातो. अन्यथा instance suspend केला जाऊ शकतो. मूळ घटनेपेक्षा शांतता हीच सहसा trigger असते. विशिष्ट host कडून काय कारवाई केली जाईल आणि केव्हा केली जाईल, हे त्याच्या स्वतःच्या policy मध्ये आणि सूचनेतच नमूद केलेले असते. उद्धृत करण्यास योग्य अशी ही दोनच documents आहेत. त्यामुळे provider काय परवानगी देतो असा forum मधील दावा पाहून कारवाई करू नका.

बाहेर जाणारा spam: मी पाठवलेले नसतानाही माझा VPS mail का पाठवत आहे

अहवालानुसार तुमच्या IP ने spam trap कडे mail पाठवले आहे किंवा प्राप्तकर्त्यांनी तुमचे mail junk म्हणून चिन्हांकित केले आहे. बहुतेक प्रकरणे चार स्रोतांमुळे असतात: rate limit नसलेले mail form असलेले web application, इतर कोणी वापरत असलेले leaked SMTP credential, ज्या hosts साठी relay करू नये त्यांच्यासाठी relay करणारा mail server आणि newsletter application वरील चोरीला गेलेले login. सर्वप्रथम queue तपासा, कारण sender compromised असल्यास तो सहसा तिथे दिसतो:

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

तुम्हाला ओळखता न येणाऱ्या addresses कडे हजारो messages असलेली queue म्हणजे हा system mail पाठवत आहे. पुढे कोण authenticate झाले ते शोधा:

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

इतरांपेक्षा count खूप जास्त असलेले एक account म्हणजे leaked credential. /var/log/mail.log अस्तित्वात नसल्यास system वर rsyslog installed नाही. त्याच lines journal मध्ये असतात: sudo journalctl -t postfix --since '2 days ago'.

कोणीही authenticate झाले नसेल, तर sender हा local process आहे. Relay rules आणि open connections तपासा:

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

मूळ Debian किंवा Ubuntu Postfix अनोळखी hosts साठी relay करत नाही. mynetworks हाताने संपूर्ण hosting subnet पर्यंत रुंद केल्यास तो open relay बनतो, कारण त्या subnet वरील प्रत्येक tenant तुमच्यामार्फत mail पाठवण्यासाठी trusted होतो. तुमचा mail server नसलेल्या process च्या मालकीचे port 25 वरील कोणतेही connection म्हणजे एखादा script स्वतः mail पाठवत आहे. Compromised PHP application सहसा असेच करते.

तपास करण्यापूर्वी mail flow थांबवा आणि पुरावे जतन करा:

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

sudo postsuper -d ALL queue रिकामी करते. तसेच काय पाठवले गेले याची नोंदही नष्ट करते. त्यामुळे आधी copy घ्या. त्यानंतर application कडे असलेले प्रत्येक credential rotate करा, application update करा आणि intruder ने मागे काय ठेवले आहे ते शोधा. बहुतेक वेळा spam incident आणि compromise ही एकच घटना असते. त्यामुळे फक्त queue clear करण्याऐवजी hacked VPS साठी recovery steps पूर्ण करा.

पोर्ट स्कॅनिंग आणि brute force: breach झालेला container कसा दिसतो

या अहवालात दुसऱ्या operator च्या logs मधील ओळी दिल्या आहेत. त्या अशा दिसतात:

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

याचे कारण जवळजवळ नेहमी अशी service असते जिचे firewall ने संरक्षण केले आहे असे तुम्हाला वाटत होते. Docker हे त्याचे सामान्य उदाहरण आहे. -p 6379:6379 वापरून port publish केल्यावर DOCKER-USER आणि nat chains मध्ये rules लिहिले जातात. या rules चे मूल्यांकन ufw च्या rules पूर्वी होते. त्यामुळे ufw deny 6379 तो port block करत नाही आणि database संपूर्ण internet ला उत्तर देतो.

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

ss -ltnp मधील कोणतीही गोष्ट 0.0.0.0 किंवा [::] वर bind केलेली असल्यास ती public address वर listening करत असते. फक्त host ला त्यापर्यंत पोहोचायचे असल्यास port loopback address वर publish करा: -p 127.0.0.1:6379:6379. Database ने मुळात कुठे चालावे हा स्वतंत्र निर्णय आहे. Docker मध्ये किंवा host वर database चालवणे या पर्यायांमधील तडजोड स्पष्ट करते.

तुमचा स्वतःचा box सध्या scan करत आहे का हे पाहण्यासाठी:

sudo ss -tnp state syn-sent

अनेक वेगवेगळ्या destinations कडे असलेली अर्धवट उघडी connections म्हणजे outbound scan सुरू असल्याचे लक्षण आहे. Kernel log मध्ये nf_conntrack: table full, dropping packet सतत येत असल्यास त्याच गोष्टीचा दुसऱ्या दृष्टिकोनातून पुरावा मिळतो: या server ने उघडण्याचे कोणतेही कारण नसताना एखादी गोष्ट अपेक्षेपेक्षा खूप जास्त connections उघडत आहे.

Breach झालेला container साफ करण्याऐवजी पुन्हा तयार करा. त्यामध्ये आणखी काय बदलले गेले आहे हे तुम्ही सिद्ध करू शकत नाही. त्यामुळे विश्वास असलेल्या image पासून तो पुन्हा तयार करा, फक्त विश्वास असलेला data restore करा आणि त्या container कडे असलेले keys बदला.

कॉपीराइट सूचना: त्यांनी प्रत्यक्षात कोणती फाइल पाहिली

DMCA सूचनेमध्ये URL किंवा torrent info hash, तुमचा IP आणि UTC मधील timestamp दिलेला असतो. जवळपास सर्व प्रकरणे दोन कारणांमुळे घडतात: media files असलेली आणि web server ने सार्वजनिकपणे list केलेली directory, किंवा download पूर्ण झाल्यानंतरही seeding सुरू ठेवणारा torrent client.

Timestamp access log मधील नोंदीशी जुळवा. nginx combined log format मध्ये status field 9 मध्ये आणि request path field 7 मध्ये असतो:

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

काहीही serve झाले नाही असा निष्कर्ष काढण्यापूर्वी clock तपासा. सूचना UTC मध्ये असते, तर तुमचे logs server च्या timezone मध्ये असतात. त्यामुळे काही तासांचा offset असल्यास तुम्ही चुकीच्या वेळेच्या कालावधीत शोध घेऊ शकता आणि false negative नोंदवू शकता:

timedatectl
sudo timedatectl set-timezone UTC

त्यानंतर मूळ कारण दुरुस्त करा. फाइल remove किंवा restrict करा, nginx location block मध्ये autoindex off; वापरून directory listing बंद करा आणि torrent client ला public interface नसलेल्या interface शी bind करा. Reply मध्ये file चे नाव, केलेला बदल आणि तो बदल केल्याची वेळ नमूद करा. दावा स्वतः चुकीचा आहे असे तुम्हाला वाटत असल्यास, तो तुमच्यातील आणि sender मधील legal question आहे; तो dispute कसा करायचा हे सूचनेमध्ये दिलेले असते. त्याचा निर्णय तुमचा host घेत नाही. त्यामुळे दाव्याच्या merits वर युक्तिवाद करणारे ticket पाठवून उपयोग होत नाही.

Blocklist सूची: माझे outbound mail पाठवणे का थांबले?

या समस्येबाबत अनेकदा तुम्हाला कोणताही mail मिळत नाही. Outbound mail स्वीकारले जाणे अचानक थांबते आणि bounce मध्ये कारण दिलेले असते:

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

IP चे चार octets उलट क्रमाने लावून आणि त्या list च्या zone ला query करून listing तपासा:

dig +short 10.113.0.203.zen.spamhaus.org

रिकाम्या उत्तराचा अर्थ असा की तुम्ही त्या list मध्ये listed नाही. 127.0.0.x उत्तराचा अर्थ असा की तुम्ही listed आहात आणि शेवटचा octet कोणती sublist match झाली ते दर्शवतो. 127.255.255.x range मधील उत्तराचा अर्थ query ला उत्तर देण्याऐवजी नकार देण्यात आला. हे सहसा query मोठ्या public resolver मार्फत गेल्यामुळे होते; free service अशा resolver ला सेवा देत नाही. वास्तविक निकाल मिळवण्यासाठी server च्या स्वतःच्या resolver वरून पुन्हा query चालवा.

Delisting ही प्रक्रिया तुमच्या host मार्फत होत नाही. ती list operator च्या site वर करावी लागते. मात्र source आधी दुरुस्त केल्यासच तिचा परिणाम टिकतो. कारण तुम्हाला listed करणारा trap पुढील message वर पुन्हा listing करू शकतो. त्यानंतर mail flow होईल की नाही हे आणखी दोन गोष्टी ठरवतात. तुमचा PTR record, म्हणजे IP साठीचा reverse DNS name, तुमचा host नियंत्रित करतो. त्यामुळे त्यांना असा PTR record सेट करण्यास सांगा जो त्याच address कडे resolve होईल आणि तोच name तुमचा HELO म्हणून वापरा. तसेच, मागील tenant कडून recycled झालेल्या address चा इतिहास तुमच्यामुळे निर्माण झालेला नसला तरी तो त्यासोबत राहू शकतो. DNS पुन्हा लिहिण्यावर एक आठवडा खर्च करण्यापूर्वी याबाबत चौकशी करणे योग्य ठरेल. SPF (sender policy framework) आणि DKIM (domainkeys identified mail) records योग्य प्रकारे सेट करणे, तसेच त्यांना एकत्र जोडणारी DMARC policy कॉन्फिगर करणे, Mailcow वापरून स्वतःचा mail server चालवण्याच्या मार्गदर्शिकेत सुरुवातीपासून शेवटपर्यंत स्पष्ट केले आहे.

Relay infrastructure, जिथे abuse mail हा कामाचा भाग असतो

तुम्ही Tor exit node, सार्वजनिक VPN किंवा इतर लोकांसाठी proxy चालवत असाल, तर तुम्ही निर्माण न केलेल्या network traffic बद्दल तक्रारी येणे हा नियमित operational खर्च मानावा लागतो. तुमची प्रणाली breached झालेल्या सर्व्हरसारखी न दिसता स्पष्टपणे relay म्हणून दिसणे, हे मुख्य काम आहे. reverse DNS साठी वर्णनात्मक नाव सेट करा. port 80 वर हा पत्ता कशासाठी आहे हे स्पष्ट करणारे छोटे notice page उपलब्ध करा. abuse mail ला त्याच स्पष्टीकरणासह त्वरित उत्तर द्या. तसेच, सर्वाधिक reports निर्माण करणारे ports बंद करण्यासाठी software उपलब्ध करून देत असलेले policy पर्याय वापरा. हे स्वतंत्र IP address वर आणि शक्य असल्यास स्वतंत्र instance वर चालवा. त्यामुळे त्या address वर null route लागू झाल्यास तुमचे web application देखील बंद पडणार नाही. सुरू करण्यापूर्वी तुमच्या host ला विचारा. परवानगी कंपनीनुसार आणि कधी कधी IP block नुसार बदलते. याचे उत्तर forum thread कडून नव्हे, तर तुमच्या host कडून घ्यायचे आहे. VPS वर Tor exit node चालवणे exit policy आणि notice page यांचे सविस्तर स्पष्टीकरण देते.

तक्रार बंद होण्यासाठी कसे उत्तर द्यावे

• एखादी व्यक्ती वाचेल असा संपर्क पत्ता जाहीर करा. RFC 2142 नुसार तुमच्या domain वरील abuse@ आणि postmaster@ हे reporter प्रथम प्रयत्न करणारे पत्ते असतात. हा mailbox ज्या server चे संरक्षण करतो त्यापेक्षा वेगळ्या ठिकाणी host करा, कारण suspended instance त्याला suspend केल्याची सूचना पाठवू शकत नाही.
• सर्व प्रश्नांची उत्तरे देता येतील इतक्या काळासाठी logs जतन करा. सात दिवसांनंतर log rotate झाला असेल, तर बारा दिवसांपूर्वीच्या traffic बद्दल आलेल्या report चे उत्तर देता येणार नाही. journalctl --disk-usage तपासा, /etc/systemd/journald.conf मध्ये MaxRetentionSec=90d सेट करा, आणि नंतर sudo systemctl restart systemd-journald चालवा. Web आणि mail logs /etc/logrotate.d/ अंतर्गत त्यांच्या स्वतंत्र schedule नुसार rotate होतात.
• Server UTC वर ठेवा. त्यामुळे report मधील timestamp आणि logs मधील timestamp यांच्यात स्वतंत्रपणे वेळेची गणना करावी लागत नाही.
• तक्रारी आकर्षित करणाऱ्या सेवा आणि गमावता न येणाऱ्या सेवा वेगळ्या ठेवा. Mail एका address वर, web application दुसऱ्या address वर, आणि relay services त्यांच्या स्वतंत्र instance वर ठेवा. एखाद्या IP विरुद्ध केलेली कारवाई त्यामागील सर्व सेवांवर लागू होते.
• तपास पूर्ण झाला नसला तरी दिलेल्या कालमर्यादेत उत्तर द्या. त्यात अपेक्षित वेळ दिलेला holding reply पहिल्या फेरीसाठी पूर्ण उत्तर मानला जातो.

बहुतेक तक्रारी बंद करणारे पहिले उत्तर लहान आणि विशिष्ट असते:

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 ची देखभाल होत नाही असा अर्थ घेतला जातो, आणि escalation path ही देखभाल न होणाऱ्या servers साठी असते. यापैकी कोणतेही काम तुमच्या जबाबदारीत येते की नाही, हे तुम्ही खरेदी केलेल्या product वर अवलंबून असते. हाच managed आणि unmanaged VPS hosting मधील व्यावहारिक फरक आहे. Unmanaged plan मध्ये tenant हीच security team असते.

हे व्यवस्थित झाल्यावर चित्र असे दिसते

दुरुपयोगाची तक्रार सर्वप्रथम routing problem असते. एखाद्या address संदर्भातील report त्या address साठी जबाबदार पक्षाकडे जाते आणि ती समस्या दुरुस्त करू शकणाऱ्या व्यक्तीपर्यंत पाठवली जाते. तुमच्या नियंत्रणातील बाबी म्हणजे तुमचा contact address, logs किती काळ जतन करता, तुमच्या services वेगवेगळ्या IPs वर कशा विभागल्या आहेत आणि तुम्ही किती लवकर उत्तर देता या आहेत. या बाबी योग्यरीत्या हाताळल्यास, बहुतेक notices एका exchange नंतरच समाप्त होतात. याच सवयींमुळे VPS hosting सुरक्षित आहे का या व्यापक प्रश्नाचेही उत्तर मिळते, कारण ज्याच्या server वर कोणी लक्ष ठेवत नाही तोच शेवटी दुसऱ्याच्या logs मध्ये दिसतो.

FAQ

गैरवापराच्या तक्रारीचा अर्थ माझा VPS हॅक झाला आहे का?

स्वतःहून तसे नाही; परंतु सर्वप्रथम हेच तपासून बाद करा. या अहवालावरून फक्त तुमच्या IP वरून network traffic बाहेर गेले हे सिद्ध होते. Outbound spam आणि port scanning ही कामे account owner पेक्षा compromised application किंवा container कडून होण्याची शक्यता अधिक असते. त्यामुळे इतर काही करण्यापूर्वी sudo postqueue -p ने mail queue आणि sudo ss -ltnp ने listening sockets तपासा. Copyright आणि blocklist notices यांचे स्वरूप वेगळे असते. ती साधारणपणे तुम्ही जाणीवपूर्वक चालवत असलेल्या एखाद्या गोष्टीकडे निर्देश करतात.

Abuse notice ला उत्तर देण्यासाठी मला किती वेळ आहे?

तुम्हाला मिळालेल्या notice मध्ये ही मुदत दिलेली असते. ती host आणि category नुसार बदलते. Copyright आणि spam-trap reports साठीची मुदत सहसा सर्वांत कमी असते. दिलेली वेळ वास्तविक अंतिम मुदत समजा आणि ती संपण्यापूर्वी संक्षिप्त holding reply पाठवा, जरी तुम्ही अजूनही कारण शोधत असलात तरी. Ticket हाताळणाऱ्या व्यक्तीसाठी महत्त्वाचे हे असते की एखादी व्यक्ती या प्रकरणावर काम करत आहे आणि network traffic थांबले आहे.

माझा IP blocklist वर आहे. माझा host तो काढू शकतो का?

नाही. Delisting ही प्रक्रिया त्या list च्या operator कडून, त्याच्याच site वर केली जाते. त्यांच्या database वर तुमच्या host चे नियंत्रण नसते. तुमचा host PTR record नियंत्रित करतो. हा तुमच्या IP साठीचा reverse DNS name असतो. त्यासाठी त्याच वेळी स्वतंत्र request करणे उपयुक्त ठरते. Delisting मागण्यापूर्वी sending problem दुरुस्त करा. कारण ज्या spam trap मुळे तुमची नोंद झाली, तो पुढील message वर तुमची पुन्हा नोंद करेल.

प्रत्यक्षात काय घडले हे मला माझ्या host ला सांगावे लागेल का?

Ticket बंद करण्यासाठी आवश्यक तेवढी माहिती द्यावी लागते: source काय होता आणि तो कधी थांबला. तुम्हाला forensic report किंवा तुमच्या users चा data देणे आवश्यक नाही. अस्पष्ट reply देण्यापेक्षा थोडक्यात पण स्पष्ट reply चांगला असतो. काय बदलले हे दिसत नसल्यास ticket हाताळणाऱ्या व्यक्तीकडे हे प्रकरण resolved मानण्याचे कारण नसते.

Scanner कडून आलेला automated report मी दुर्लक्षित करू शकतो का?

नाही. Automated reports ची नोंद केली जाते. एका IP संदर्भातील repeated reports मुळे तुमच्या host च्या संपूर्ण address block विरुद्ध score वाढतो. त्यामुळे लहान प्रकरण escalation मध्ये बदलते. तुमचा reply एक परिच्छेदाचा असू शकतो. Automated reporter तो सहसा वाचत नाही. परंतु तुमच्या host वरील ticket हाताळणारी व्यक्ती तो वाचते. तुमच्या instance बाबत पुढे काय करायचे हे ठरवणारी व्यक्ती तीच असते.