VPS abuse complaint क्या है और इसका जवाब कैसे दें

VPS abuse complaint वास्तव में क्या है

VPS abuse complaint आपके IP address से उत्पन्न traffic के बारे में एक रिपोर्ट होती है। यह रिपोर्ट उस IP block के लिए प्रकाशित abuse contact को भेजी जाती है, और फिर आपका host इसे आपको भेजता है, साथ ही जवाब देने के लिए एक समय-सीमा भी दी जाती है। प्रकाशित contact उस कंपनी का होता है जिसके पास address space का स्वामित्व है, इसलिए आपके सर्वर के बारे में रिपोर्ट पढ़ने वाला पहला व्यक्ति लगभग कभी भी आप नहीं होते हैं। आपका host IP और timestamp का मिलान आपके account से करता है और इसे आपको forward कर देता है।

यह नोटिस इस बात का प्रमाण नहीं है कि आपने जानबूझकर कुछ गलत किया है। रिपोर्ट करने वाले के पास केवल IP address ही एकमात्र पहचानकर्ता होता है। 03:00 बजे spam भेजने वाला एक compromised application भी वही रिपोर्ट उत्पन्न करता है जो 03:00 बजे spam भेजने वाला कोई व्यक्ति करता है। यही कारण है कि आपका जवाब ही सबसे महत्वपूर्ण हिस्सा है। आपसे यह पूछा जा रहा है कि इसका स्रोत क्या था और आपने क्या बदलाव किए हैं।

रिपोर्ट कौन भेजता है, और यह आपके host तक कैसे पहुँचती है

प्रत्येक public IP block एक regional 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: लाइन होती है। ARIN रिकॉर्ड में OrgAbuseEmail: होता है। वहां जो भी पता प्रकाशित होता है, शिकायत उसी पर प्राप्त होती है, यही कारण है कि आपके सर्वर के बारे में रिपोर्ट आपके इनबॉक्स के बजाय आपके host के पास पहुँचती है।

इसे फाइल करने वाली पार्टी आमतौर पर एक मशीन होती है। चार प्रकार के स्रोत लगभग हर उस चीज़ को कवर करते हैं जिसका आप सामना करेंगे:

• स्वचालित स्कैनर्स और honeypots। एक मशीन आपके IP से कनेक्शन के प्रयास को रिकॉर्ड करती है और log excerpt संलग्न करके रिपोर्ट फाइल करती है।
• मेलबॉक्स प्रदाताओं द्वारा चलाए जाने वाले feedback loops (FBL)। एक प्राप्तकर्ता junk बटन पर क्लिक करता है और संदेश की एक प्रति ARF (abuse reporting format) में वापस आती है, जो मशीनों द्वारा पार्स करने के लिए बनाया गया एक संरचित मेल प्रारूप है।
• कॉपीराइट एजेंट। वे torrent swarms पर नज़र रखते हैं या public URLs को क्रॉल करते हैं, फिर एक DMCA (digital millennium copyright act) नोटिस भेजते हैं जिसमें एक फ़ाइल, आपका IP, और UTC में एक टाइमस्टैम्प का उल्लेख होता है।
• ब्लॉकलिस्ट ऑपरेटर और नेटवर्क इंजीनियर, जो अपने स्वयं के लॉग से आपत्तिजनक लाइनों के साथ एक संक्षिप्त मेल भेजते हैं।

चूंकि अधिकांश पहली रिपोर्ट स्वचालित रूप से उत्पन्न होती हैं, इसलिए उत्तर में तर्क करने से कुछ हासिल नहीं होता है। एक तथ्य सब कुछ हासिल कर लेता है: क्या चल रहा था, और यह कब बंद हुआ।

नोटिस में समय-सीमा (deadline) क्यों दी जाती है

आपका होस्ट भी एक किरायेदार (tenant) है। इसका एड्रेस स्पेस अपस्ट्रीम कैरियर के पीछे और उन रेपुटेशन डेटाबेस के अंदर स्थित होता है जिन्हें अन्य लोग संचालित करते हैं। जिन रिपोर्टों का उत्तर नहीं दिया जाता, वे आपके एकल पते के बजाय पूरे ब्लॉक के स्कोर को बढ़ा देती हैं, इसलिए आपको दी गई समय-सीमा वास्तव में आप पर डाला गया दबाव है। नोटिस में दी गई समय-सीमा को पढ़ें और उसे वास्तविक मानें।

जब किसी अनुत्तरित मामले में कोई कार्रवाई होती है, तो आमतौर पर वह null route होता है, जिसका अर्थ है कि उस एक IP पर आने वाले ट्रैफिक को अपस्ट्रीम स्तर पर ही ड्रॉप कर दिया जाता है, या फिर इंस्टेंस को सस्पेंड कर दिया जाता है। इसका कारण आमतौर पर चुप्पी होती है, न कि मूल घटना। कोई विशिष्ट होस्ट क्या करता है और कब करता है, यह उसकी अपनी पॉलिसी और स्वयं नोटिस में लिखा होता है। केवल ये दो दस्तावेज़ ही उद्धृत करने योग्य हैं, इसलिए किसी फोरम में किए गए दावों के आधार पर कोई कदम न उठाएं कि कोई प्रदाता क्या अनुमति देता है।

Outbound spam: मेरा VPS मेरे द्वारा न भेजे गए ईमेल क्यों भेज रहा है

रिपोर्ट बताती है कि आपके IP ने किसी स्पैम ट्रैप पर मेल डिलीवर किया है, या प्राप्तकर्ताओं ने आपके मेल को जंक के रूप में चिह्नित किया है। चार स्रोत अधिकांश मामलों के लिए जिम्मेदार होते हैं: बिना रेट लिमिट वाला मेल फॉर्म युक्त वेब एप्लिकेशन, लीक हुआ SMTP क्रेडेंशियल जिसका उपयोग अब कोई और कर रहा है, एक मेल सर्वर जो उन होस्ट्स के लिए रिले करता है जिनके लिए उसे नहीं करना चाहिए, और न्यूज़लेटर एप्लिकेशन पर चोरी हुआ लॉगिन। मेल क्यू (queue) से शुरुआत करें, क्योंकि एक समझौता (compromised) हुआ प्रेषक आमतौर पर वहां दिखाई देता है:

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

हजारों संदेशों वाली क्यू, जो उन पतों पर जा रहे हैं जिन्हें आप नहीं पहचानते, का अर्थ है कि सर्वर मेल भेज रहा है। इसके बाद, पता लगाएँ कि किसने ऑथेंटिकेट किया है:

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

एक अकाउंट जिसका उपयोग दूसरों की तुलना में बहुत अधिक है, वह लीक हुआ क्रेडेंशियल है। यदि /var/log/mail.log मौजूद नहीं है, तो सिस्टम में rsyslog इंस्टॉल नहीं है और वही पंक्तियाँ जर्नल में होती हैं: sudo journalctl -t postfix --since '2 days ago'।

यदि किसी ने ऑथेंटिकेट नहीं किया है, तो प्रेषक एक स्थानीय प्रोसेस है। रिले नियमों और खुले कनेक्शनों की जाँच करें:

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

एक स्टॉक Debian या Ubuntu Postfix अजनबियों के लिए रिले नहीं करता है। यह तब एक ओपन रिले बन जाता है जब mynetworks को मैन्युअल रूप से पूरे होस्टिंग सबनेट तक बढ़ा दिया जाता है, क्योंकि तब उस सबनेट के अन्य सभी टेनेंट्स को आपके माध्यम से मेल भेजने के लिए विश्वसनीय माना जाता है। पोर्ट 25 से जुड़ा कोई भी कनेक्शन जो आपके मेल सर्वर के अलावा किसी अन्य प्रोसेस के स्वामित्व में है, वह एक स्क्रिप्ट है जो स्वयं मेल भेज रही है, जो कि आमतौर पर एक समझौता (compromised) हुआ PHP एप्लिकेशन करता है।

जांच करने से पहले प्रवाह को रोकें, और सबूत सुरक्षित रखें:

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

sudo postsuper -d ALL क्यू को खाली कर देता है, और यह क्या भेजा गया था इसका रिकॉर्ड भी नष्ट कर देता है, इसलिए पहले कॉपी ले लें। फिर एप्लिकेशन के पास मौजूद हर क्रेडेंशियल को रोटेट करें, एप्लिकेशन को अपडेट करें, और देखें कि घुसपैठिए ने पीछे क्या छोड़ा है। स्पैम की घटना और सिस्टम का समझौता होना अधिकतर समय एक ही घटना होती है, इसलिए केवल क्यू को साफ करने के बजाय hacked VPS के लिए रिकवरी स्टेप्स का पालन करें।

Port scanning और brute force: एक compromised container कैसा दिखता है

यह रिपोर्ट किसी अन्य ऑपरेटर के लॉग्स की पंक्तियों को दर्शाती है, जो कुछ इस तरह दिखती हैं:

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

इसका कारण लगभग हमेशा वह service होती है जिसे आपने firewalled समझा था। Docker अक्सर इसका कारण बनता है। -p 6379:6379 के साथ port publish करने पर DOCKER-USER और nat chains में rules लिख दिए जाते हैं, और ये rules ufw के rules से पहले evaluate होते हैं। इसलिए ufw deny 6379 इसे block नहीं कर पाता और database पूरे internet को response देने लगता है।

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

ss -ltnp में 0.0.0.0 या [::] पर bound कोई भी service public address पर listen कर रही होती है। जब केवल host को ही उस तक पहुँचने की आवश्यकता हो, तो loopback address, -p 127.0.0.1:6379:6379, पर publish करें। Database को कहाँ रखा जाना चाहिए, यह एक अलग निर्णय है, और database को Docker में या host पर चलाना इस विकल्प के फायदे और नुकसान को कवर करता है।

यह देखने के लिए कि क्या आपका अपना box अभी scanning कर रहा है:

sudo ss -tnp state syn-sent

कई अलग-अलग destinations के लिए बहुत सारे half-open connections का मतलब है कि outbound scan चल रहा है। kernel log का nf_conntrack: table full, dropping packet से भर जाना भी यही संकेत देता है: कोई process इस server की सामान्य आवश्यकता से कहीं अधिक connections खोल रही है।

Compromised container को clean करने के बजाय उसे rebuild करें। आप यह साबित नहीं कर सकते कि उसके अंदर और क्या बदलाव किए गए हैं, इसलिए एक भरोसेमंद image से rebuild करें, केवल भरोसेमंद data restore करें, और उस container में मौजूद keys को rotate करें।

कॉपीराइट नोटिस: उन्होंने वास्तव में कौन सी फाइल देखी

DMCA नोटिस में एक URL या टोरेंट इंफो हैश, आपका IP, और UTC में एक टाइमस्टैम्प होता है। लगभग सभी नोटिस दो कारणों से आते हैं: एक ऐसी डायरेक्टरी जिसे वेब सर्वर मीडिया फाइलों के साथ सार्वजनिक रूप से लिस्ट करता है, और एक टोरेंट क्लाइंट जो डाउनलोड पूरा होने के बाद भी सीडिंग कर रहा है।

टाइमस्टैम्प का मिलान एक्सेस लॉग से करें। Nginx कंबाइंड लॉग फॉर्मेट में स्टेटस 9वें फील्ड में और रिक्वेस्ट पाथ 7वें फील्ड में होता है:

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

यह निष्कर्ष निकालने से पहले कि कुछ भी सर्व नहीं किया गया, घड़ी की जांच करें। नोटिस UTC में होता है और आपके लॉग सर्वर के टाइमज़ोन का उपयोग करते हैं, इसलिए कुछ घंटों का अंतर आपको गलत समय सीमा में खोजने के लिए प्रेरित करेगा और आप गलत परिणाम (false negative) रिपोर्ट कर सकते हैं:

timedatectl
sudo timedatectl set-timezone UTC

फिर कारण को ठीक करें। फाइल को हटा दें या प्रतिबंधित करें, Nginx लोकेशन ब्लॉक में autoindex off; के साथ डायरेक्टरी लिस्टिंग बंद करें, और टोरेंट क्लाइंट को ऐसे इंटरफेस से बाइंड करें जो सार्वजनिक नहीं है। जवाब में फाइल का नाम, किया गया बदलाव, और वह समय बताएं जब आपने यह बदलाव किया। यदि आपको लगता है कि दावा ही गलत है, तो यह आपके और भेजने वाले के बीच का कानूनी प्रश्न है, और नोटिस में बताया गया है कि इसे कैसे चुनौती दी जाए। आपका होस्ट यह तय करने वाली पार्टी नहीं है, इसलिए इसके गुण-दोष पर बहस करने वाली टिकट का कोई परिणाम नहीं निकलेगा।

Blocklist listings: मेरा आउटबाउंड मेल काम करना क्यों बंद हो गया

यह समस्या अक्सर तब आती है जब आपको कोई मेल प्राप्त नहीं होता है। आउटबाउंड मेल स्वीकार किया जाना बंद हो जाता है, और बाउंस मैसेज में इसका कारण दिया होता है:

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

IP के चार ऑक्टेट्स को उल्टा करके और लिस्ट के ज़ोन को क्वेरी करके लिस्टिंग की जाँच करें:

dig +short 10.113.0.203.zen.spamhaus.org

एक खाली उत्तर का मतलब है कि आप वहां लिस्टेड नहीं हैं। 127.0.0.x उत्तर का मतलब है कि आप लिस्टेड हैं, और अंतिम ऑक्टेट यह बताता है कि कौन सी सबलिस्ट मैच हुई है। 127.255.255.x रेंज में उत्तर का मतलब है कि क्वेरी का उत्तर देने के बजाय उसे अस्वीकार कर दिया गया है, आमतौर पर इसलिए क्योंकि यह एक बड़े पब्लिक रिज़ॉल्वर के माध्यम से गई थी, जिसे फ्री सर्विस सपोर्ट नहीं करती है। वास्तविक परिणाम प्राप्त करने के लिए इसे सर्वर के अपने रिज़ॉल्वर से दोबारा चलाएं।

डिलिस्टिंग लिस्ट ऑपरेटर की साइट पर होती है, आपके होस्ट के माध्यम से नहीं, और यह तभी प्रभावी रहती है यदि स्रोत को पहले ठीक किया जाए, क्योंकि जिस ट्रैप ने आपको लिस्ट किया है, वह अगले मैसेज पर आपको फिर से लिस्ट कर देगा। इसके बाद मेल फ्लो करेगा या नहीं, यह दो अन्य बातों पर निर्भर करता है। आपका PTR रिकॉर्ड, जो IP के लिए रिवर्स DNS नाम है, आपके होस्ट द्वारा नियंत्रित होता है, इसलिए उनसे एक ऐसा रिकॉर्ड सेट करने के लिए कहें जो वापस उसी पते पर रिज़ॉल्व हो और उस नाम को अपने HELO के रूप में उपयोग करें। और एक पिछला पता जो किसी अन्य उपयोगकर्ता द्वारा इस्तेमाल किया गया हो, उसका इतिहास ऐसा हो सकता है जिसे आपने नहीं बनाया है, जिसके बारे में DNS को फिर से लिखने में एक सप्ताह बिताने से पहले पूछ लेना उचित है। SPF (sender policy framework) और DKIM (domainkeys identified mail) रिकॉर्ड्स को सही करना, और साथ ही उन्हें जोड़ने वाली DMARC पॉलिसी, Mailcow के साथ अपना खुद का मेल सर्वर चलाने की गाइड में पूरी तरह से कवर की गई है।

रिले इंफ्रास्ट्रक्चर, जहाँ दुरुपयोग मेल (abuse mail) काम का हिस्सा है

यदि आप Tor exit node, पब्लिक VPN, या अन्य लोगों के लिए प्रॉक्सी चलाते हैं, तो आपके द्वारा उत्पन्न न किए गए ट्रैफ़िक के बारे में शिकायतें सामान्य परिचालन लागत हैं। काम का तरीका ऐसा होना चाहिए कि यह किसी compromised बॉक्स के बजाय स्पष्ट रूप से एक रिले की तरह दिखे। रिवर्स DNS को एक वर्णनात्मक नाम पर सेट करें, पोर्ट 80 पर एक संक्षिप्त सूचना पृष्ठ (notice page) रखें जो यह बताए कि यह पता क्या है, उसी स्पष्टीकरण के साथ दुरुपयोग मेल का तुरंत उत्तर दें, और उन पोर्ट्स को ड्रॉप करने के लिए सॉफ़्टवेयर द्वारा प्रदान की गई किसी भी नीति का उपयोग करें जो सबसे अधिक रिपोर्ट उत्पन्न करते हैं। इसे अपने स्वयं के IP पते पर और आदर्श रूप से अपने स्वयं के इंस्टेंस पर चलाएं, ताकि उस पते पर null route होने से आपका वेब एप्लिकेशन बंद न हो जाए। शुरू करने से पहले अपने होस्ट से पूछें, क्योंकि क्या अनुमति है यह कंपनी और कभी-कभी IP ब्लॉक के आधार पर भिन्न होता है, और यह एक फ़ोरम थ्रेड के बजाय उनके लिए एक प्रश्न है। VPS पर Tor exit node चलाना एग्जिट पॉलिसी और सूचना पृष्ठ के बारे में विस्तार से बताता है।

टिकट बंद करने के लिए उत्तर कैसे दें

• ऐसा संपर्क पता प्रकाशित करें जिसे कोई व्यक्ति पढ़ सके। RFC 2142 के अनुसार abuse@ और postmaster@ आपके डोमेन पर वे पते हैं जिन पर रिपोर्ट करने वाले सबसे पहले संपर्क करते हैं। उस मेलबॉक्स को उस सर्वर के अलावा कहीं और होस्ट करें जिसकी वह सुरक्षा करता है, क्योंकि सस्पेंड किया गया इंस्टेंस आपको यह सूचना देने वाला नोटिस डिलीवर नहीं कर पाएगा कि उसे सस्पेंड कर दिया गया है।
• लॉग्स को इतना पुराना रखें कि आप उत्तर दे सकें। बारह दिन पहले के ट्रैफिक के बारे में आई रिपोर्ट का उत्तर देना असंभव है यदि लॉग सात दिन बाद रोटेट हो गए हों। journalctl --disk-usage की जाँच करें, /etc/systemd/journald.conf में MaxRetentionSec=90d सेट करें, और फिर sudo systemctl restart systemd-journald चलाएँ। वेब और मेल लॉग्स /etc/logrotate.d/ के तहत अपने स्वयं के शेड्यूल पर रोटेट होते हैं।
• सर्वर को UTC पर रखें, ताकि रिपोर्ट में दिया गया टाइमस्टैम्प आपके लॉग्स के टाइमस्टैम्प से बिना किसी गणना के मेल खा सके।
• शिकायतों का कारण बनने वाली चीजों को उन चीजों से अलग रखें जिन्हें आप खोना नहीं चाहते। एक पते पर मेल रखें, दूसरे पर वेब एप्लिकेशन, और रिले सर्विसेज को उनके अपने इंस्टेंस पर रखें। किसी 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.

जो आप जानते हैं वह बताएं, और जो आपने अभी तक पता नहीं लगाया है उसके बारे में भी बताएं। चुप्पी का अर्थ यह निकाला जाता है कि सर्वर का रखरखाव नहीं किया जा रहा है, और रखरखाव न किए जाने वाले सर्वर्स के लिए एस्केलेशन पाथ मौजूद होता है। क्या यह काम पूरी तरह से आपका है, यह आपके द्वारा खरीदे गए प्रोडक्ट पर निर्भर करता है, जो managed और unmanaged VPS hosting के बीच व्यावहारिक अंतर है। एक unmanaged प्लान पर, किरायेदार ही सुरक्षा टीम होता है।

जब सब कुछ सही तरीके से काम करता है तो यह कैसा दिखता है

एक abuse complaint सबसे पहले एक routing की समस्या होती है। किसी IP address के बारे में रिपोर्ट उस पार्टी के पास जाती है जो उस address के लिए जिम्मेदार है, और फिर उसे उस व्यक्ति तक पहुँचाया जाता है जो इसे ठीक कर सकता है। जिन हिस्सों पर आपका नियंत्रण है, वे हैं: आपका contact address, आपके logs को सुरक्षित रखने की अवधि, आपकी services का अलग-अलग IPs पर बँटा होना, और आप कितनी जल्दी जवाब देते हैं। यदि आप इन्हें सही रखते हैं, तो अधिकांश नोटिस एक बार के आदान-प्रदान के बाद समाप्त हो जाते हैं। यही आदतें क्या VPS hosting सुरक्षित है के बड़े सवाल को भी हल करती हैं, क्योंकि जिस सर्वर पर कोई निगरानी नहीं रख रहा होता, वही अंत में किसी और के logs में दिखाई देता है।

FAQ

क्या abuse complaint का मतलब यह है कि मेरा VPS हैक हो गया है?

स्वयं में इसका यह अर्थ नहीं है, लेकिन सबसे पहले इसी संभावना की जाँच करनी चाहिए। यह रिपोर्ट केवल यह सिद्ध करती है कि आपके IP से traffic बाहर गया है। Outbound spam और port scanning अक्सर account owner के बजाय किसी compromised application या container के कारण होते हैं, इसलिए कुछ भी करने से पहले sudo postqueue -p के साथ mail queue और sudo ss -ltnp के साथ listening sockets की जाँच करें। Copyright और blocklist की सूचनाएं अलग प्रकृति की होती हैं: वे आमतौर पर उस चीज़ की ओर इशारा करती हैं जिसे आप जानबूझकर चला रहे हैं।

abuse notice का उत्तर देने के लिए मेरे पास कितना समय है?

समय सीमा उस notice में दी गई होती है जो आपको प्राप्त हुई है, और यह host तथा श्रेणी के आधार पर अलग-अलग होती है। Copyright और spam-trap रिपोर्ट में समय सीमा सबसे कम होती है। दी गई समय सीमा को वास्तविक मानें और इसके समाप्त होने से पहले एक संक्षिप्त प्रारंभिक उत्तर भेजें, भले ही आप अभी भी कारण का पता लगा रहे हों। Ticket संभालने वाले व्यक्ति के लिए यह महत्वपूर्ण है कि कोई व्यक्ति इस पर काम कर रहा है और traffic रुक गया है।

मेरा IP blocklist में है। क्या मेरा host इसे हटा सकता है?

नहीं। Delisting उस list के operator द्वारा उनकी अपनी साइट पर की जाती है, और आपके host का उनके database पर कोई नियंत्रण नहीं होता है। आपका host PTR record, यानी आपके IP के लिए reverse DNS name को नियंत्रित करता है, जिसके लिए उसी समय अनुरोध करना उचित रहता है। Delisting का अनुरोध करने से पहले भेजने की समस्या को ठीक करें, क्योंकि जिस spam trap ने आपको list किया है, वह अगले संदेश पर आपको फिर से list कर देगा।

क्या मुझे अपने host को यह बताना होगा कि वास्तव में क्या हुआ था?

आपको उन्हें इतना बताना होगा कि ticket बंद हो सके: स्रोत क्या था, और यह कब रुका। आपको forensic report या अपने users का data देने की आवश्यकता नहीं है। अस्पष्ट उत्तर देने से बेहतर है कि छोटा लेकिन स्पष्ट उत्तर दें, क्योंकि जो handler यह नहीं देख सकता कि क्या बदला है, उसके पास मामले को हल हुआ मानने का कोई कारण नहीं होगा।

क्या मैं scanner से आने वाली automated रिपोर्ट को अनदेखा कर सकता हूँ?

नहीं। Automated रिपोर्ट की गिनती की जाती है, और एक ही IP के बारे में बार-बार आने वाली रिपोर्ट आपके host के पूरे address block के खिलाफ score बढ़ा देती है, जो एक छोटे मामले को गंभीर बना देता है। आपका उत्तर एक paragraph का हो सकता है। Automated reporter आमतौर पर इसे कभी नहीं पढ़ता है, लेकिन आपके host पर ticket संभालने वाला व्यक्ति इसे पढ़ता है, और वही पाठक यह तय करता है कि आपके instance का क्या होगा।