معنی شکایت سوءاستفاده (Abuse) از VPS چیست؟

شکایت سوءاستفاده از VPS دقیقاً چیست

شکایت سوءاستفاده از VPS، گزارشی درباره ترافیکی است که از آدرس IP شما خارج شده است. این گزارش ابتدا به مخاطبِ مسئولِ سوءاستفاده (abuse contact) که برای آن بلوک IP منتشر شده ارسال می‌شود و سپس توسط میزبان (host) شما، همراه با یک مهلت زمانی برای پاسخ‌دهی، به دست شما می‌رسد. مخاطب منتشرشده متعلق به شرکتی است که مالک فضای آدرس است؛ بنابراین اولین کسی که گزارش مربوط به سرور شما را می‌خواند، تقریباً هرگز شما نیستید. میزبان شما، IP و زمان دقیق (timestamp) را با حساب کاربری شما تطبیق داده و گزارش را برایتان فوروارد می‌کند.

این اخطاریه به هیچ وجه مدرکی مبنی بر عمدی بودن اقدامات شما نیست. آدرس IP تنها شناسه‌ای است که گزارش‌دهنده در اختیار دارد. یک اپلیکیشنِ هک‌شده که در ساعت 03:00 اسپم ارسال می‌کند، همان گزارشی را تولید می‌کند که شخصی در ساعت 03:00 به صورت دستی ارسال کرده باشد. به همین دلیل است که پاسخ شما اهمیت اصلی را دارد. از شما خواسته می‌شود که منبع مشکل را مشخص کنید و توضیح دهید چه تغییراتی برای رفع آن اعمال کرده‌اید.

چه کسی گزارش را ارسال می‌کند و چگونه به میزبان شما می‌رسد

هر بلوک IP عمومی نزد یک نهاد ثبت اینترنت منطقه‌ای (RIR) ثبت شده است: RIPE NCC، ARIN، APNIC، LACNIC یا AFRINIC. هر ثبت، یک آدرس تماس برای سوءاستفاده (abuse contact) منتشر می‌کند و گزارش‌ها به همان مقصد ارسال می‌شوند. شما می‌توانید همان رکوردی را بخوانید که گزارش‌دهنده می‌خواند:

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

رکوردهای RIPE دارای یک شیء abuse-c: از نوع role هستند که شامل یک خط abuse-mailbox: است. رکوردهای ARIN شامل OrgAbuseEmail: هستند. هر آدرسی که در آنجا منتشر شده باشد، شکایت را دریافت می‌کند؛ به همین دلیل است که گزارش مربوط به سرور شما به جای صندوق ورودی شما، به دست میزبان (host) شما می‌رسد.

طرفی که گزارش را ثبت می‌کند معمولاً یک ماشین است. چهار نوع گزارش تقریباً تمام مواردی را که با آن مواجه می‌شوید پوشش می‌دهند:

• اسکنرهای خودکار و هانی‌پات‌ها (honeypots). یک ماشین تلاش برای اتصال از IP شما را ثبت کرده و گزارشی به همراه بخشی از لاگ ضمیمه‌شده ارسال می‌کند.
• حلقه‌های بازخورد (FBL) که توسط ارائه‌دهندگان سرویس ایمیل اجرا می‌شوند. گیرنده دکمه هرزنامه (junk) را کلیک می‌کند و یک کپی از پیام در قالب ARF (فرمت گزارش سوءاستفاده) بازمی‌گردد؛ یک فرمت ایمیل ساختاریافته که برای تجزیه توسط ماشین‌ها طراحی شده است.
• نمایندگان کپی‌رایت. آن‌ها دسته‌های تورنت را زیر نظر می‌گیرند یا URLهای عمومی را می‌خزند، سپس یک اخطاریه DMCA (قانون کپی‌رایت هزاره دیجیتال) ارسال می‌کنند که نام فایل، IP شما و یک برچسب زمانی به وقت UTC در آن ذکر شده است.
• گردانندگان لیست‌های مسدود (blocklist) و مهندسان شبکه، که ایمیل کوتاهی حاوی خطوط متخلف از لاگ‌های خودشان ارسال می‌کنند.

از آنجا که اکثر گزارش‌های اولیه توسط ماشین تولید می‌شوند، بحث و جدل در پاسخ به آن‌ها هیچ نتیجه‌ای ندارد. تنها ارائه واقعیت کارساز است: چه چیزی در حال اجرا بوده و چه زمانی متوقف شده است.

چرا این اخطار با مهلت زمانی ارسال می‌شود

میزبان شما نیز یک مستأجر است. فضای آدرس‌دهی آن پشت حامل‌های بالادستی (upstream carriers) و درون پایگاه‌های دادهٔ شهرت (reputation databases) قرار دارد که توسط دیگران مدیریت می‌شوند. گزارش‌هایی که بی‌پاسخ می‌مانند، امتیاز کل بلوک IP را افزایش می‌دهند، نه فقط آدرس تکی شما را؛ بنابراین مهلتی که دریافت می‌کنید، فشاری است که از سطوح بالاتر به شما منتقل شده است. بازهٔ زمانی ذکرشده در اخطار را بخوانید و آن را جدی تلقی کنید.

وقتی به یک پروندهٔ بی‌پاسخ رسیدگی نمی‌شود، معمولاً نتیجهٔ آن null route است؛ به این معنی که ترافیکِ آن IP خاص در لایهٔ بالادستی مسدود می‌شود یا کل instance به حالت تعلیق درمی‌آید. عامل محرک این اقدام معمولاً سکوت شماست، نه رویداد اولیه. اینکه هر میزبان خاص چه اقدامی انجام می‌دهد و در چه زمانی، در سیاست‌های داخلی همان میزبان و در متن خودِ اخطار نوشته شده است. این دو سند تنها منابع قابل استناد هستند؛ بنابراین بر اساس ادعاهای مطرح‌شده در انجمن‌ها دربارهٔ آنچه یک ارائه‌دهنده مجاز می‌داند، عمل نکنید.

هرزنامه خروجی: چرا VPS من ایمیلی که ارسال نکرده‌ام را می‌فرستد

گزارش نشان می‌دهد که IP شما ایمیلی را به یک تله هرزنامه (spam trap) تحویل داده است، یا گیرندگان ایمیل شما را به عنوان هرزنامه علامت‌گذاری کرده‌اند. چهار منبع، اکثر موارد را پوشش می‌دهند: یک برنامه وب با فرم ایمیل بدون محدودیت نرخ (rate limit)، یک اعتبارنامه SMTP لو رفته که اکنون توسط شخص دیگری استفاده می‌شود، یک سرور ایمیل که برای میزبان‌هایی که نباید، رله (relay) انجام می‌دهد، و یک ورود سرقت‌شده در یک برنامه خبرنامه. با صف شروع کنید، زیرا فرستنده نفوذ‌یافته معمولاً در آنجا قابل مشاهده است:

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 نصب نکرده است و همان خطوط در journal قرار دارند: sudo journalctl -t postfix --since '2 days ago'.

اگر هیچ‌کس احراز هویت نکرده است، فرستنده یک پردازش محلی است. قوانین رله و اتصالات باز را بررسی کنید:

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

یک Postfix پیش‌فرض در Debian یا Ubuntu برای غریبه‌ها رله انجام نمی‌دهد. این سرور زمانی به یک open relay تبدیل می‌شود که mynetworks به‌صورت دستی برای کل زیرشبکه میزبانی گسترش یابد، زیرا در این صورت به هر مستأجر دیگری در آن زیرشبکه اعتماد می‌شود تا از طریق شما ارسال انجام دهد. هر اتصالی به پورت 25 که متعلق به پردازشی غیر از سرور ایمیل شما باشد، یک اسکریپت است که مستقلاً ایمیل می‌فرستد؛ این همان کاری است که یک برنامه PHP نفوذ‌یافته معمولاً انجام می‌دهد.

پیش از بررسی، جریان را متوقف کنید و شواهد را نگه دارید:

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

دستور sudo postsuper -d ALL صف را خالی می‌کند، اما سوابق آنچه ارسال شده است را نیز از بین می‌برد، بنابراین ابتدا یک کپی تهیه کنید. سپس تمام اعتبارنامه‌هایی که برنامه در اختیار دارد را تغییر دهید، برنامه را به‌روزرسانی کنید و به دنبال آنچه نفوذگر باقی گذاشته است بگردید. یک حادثه هرزنامه و یک نفوذ امنیتی در بیشتر مواقع یک رویداد واحد هستند، بنابراین به‌جای پاک کردن صف، مراحل بازیابی برای یک VPS هک‌شده را دنبال کنید.

اسکن پورت و حملات brute force: وضعیت یک کانتینر نفوذپذیر

این گزارش شامل خطوطی از لاگ‌های یک اپراتور دیگر است که به این شکل دیده می‌شوند:

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

علت این موضوع تقریباً همیشه سرویسی است که تصور می‌کردید توسط فایروال مسدود شده است. Docker عامل شایعی در این زمینه است. انتشار یک پورت با -p 6379:6379، قوانینی را در زنجیره‌های DOCKER-USER و nat می‌نویسد و این قوانین پیش از قوانین ufw ارزیابی می‌شوند؛ بنابراین ufw deny 6379 مانع آن نمی‌شود و دیتابیس به کل اینترنت پاسخ می‌دهد.

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

هر چیزی در ss -ltnp که به 0.0.0.0 یا [::] متصل (bind) شده باشد، روی آدرس عمومی گوش می‌دهد. زمانی که فقط میزبان (host) نیاز به دسترسی به آن دارد، آن را به آدرس loopback یعنی -p 127.0.0.1:6379:6379 منتشر کنید. اینکه دیتابیس در وهله اول باید کجا قرار بگیرد، یک تصمیم جداگانه است و اجرای دیتابیس در Docker یا روی host این مبحث را پوشش می‌دهد.

برای اینکه ببینید آیا سرور شما در حال حاضر در حال اسکن کردن است یا خیر:

sudo ss -tnp state syn-sent

تعداد زیادی اتصال نیمه‌باز (half-open) به مقصدهای مختلف، نشان‌دهنده یک اسکن خروجی در حال انجام است. پر شدن لاگ کرنل با nf_conntrack: table full, dropping packet نیز همین موضوع را از زاویه‌ای دیگر بیان می‌کند: چیزی در حال باز کردن اتصالات بسیار بیشتری است که این سرور هیچ دلیلی برای انجام آن‌ها ندارد.

به‌جای پاکسازی یک کانتینر نفوذپذیر، آن را دوباره بسازید (rebuild). شما نمی‌توانید اثبات کنید چه تغییرات دیگری در آن رخ داده است؛ بنابراین از یک image مورد اعتماد دوباره آن را بسازید، فقط داده‌های مورد اعتماد را بازیابی کنید و کلیدهایی که آن کانتینر در اختیار داشت را تغییر دهید (rotate).

اعلامیه‌های حق تکثیر: آن‌ها واقعاً کدام فایل را مشاهده کرده‌اند

یک اخطاریه DMCA شامل یک URL یا info hash تورنت، آدرس IP شما و یک برچسب زمانی به وقت UTC است. تقریباً تمام این موارد ناشی از دو علت هستند: دایرکتوری که وب‌سرور آن را به‌صورت عمومی فهرست کرده و حاوی فایل‌های رسانه‌ای است، و کلاینت تورنتی که پس از اتمام دانلود، همچنان در حال seeding است.

برچسب زمانی را با لاگ دسترسی (access log) تطبیق دهید. فرمت لاگ ترکیبی 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 است و لاگ‌های شما از منطقه زمانی سرور استفاده می‌کنند؛ بنابراین یک اختلاف چند ساعته باعث می‌شود در بازه زمانی اشتباه جستجو کنید و به نتیجه منفی کاذب برسید:

timedatectl
sudo timedatectl set-timezone UTC

سپس علت را برطرف کنید. فایل را حذف یا دسترسی به آن را محدود کنید، فهرست‌بندی دایرکتوری را با استفاده از autoindex off; در بلاک location در nginx غیرفعال کنید و کلاینت تورنت را به اینترفیسی متصل کنید که اینترفیس عمومی نباشد. در پاسخ، نام فایل، تغییری که اعمال کردید و زمانی که آن را انجام دادید ذکر کنید. اگر معتقدید که خودِ ادعا نادرست است، این یک مسئله حقوقی بین شما و فرستنده است و اخطاریه نحوه اعتراض به آن را توضیح داده است. میزبان (host) شما طرفی نیست که در این مورد تصمیم‌گیری کند، بنابراین ارسال تیکت برای بحث در مورد ماهیت ادعا بی‌نتیجه خواهد بود.

لیست‌های مسدودکننده: چرا ارسال ایمیل من متوقف شده است

این مشکل اغلب بدون دریافت هیچ ایمیلی برای شما رخ می‌دهد. ارسال ایمیل به‌سادگی متوقف می‌شود و پیام بازگشتی (bounce) دلیل آن را اعلام می‌کند:

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

با معکوس کردن چهار اکتت IP و پرس‌وجو از zone مربوط به لیست، وضعیت قرارگیری در لیست را بررسی کنید:

dig +short 10.113.0.203.zen.spamhaus.org

پاسخ خالی به این معناست که شما در آن لیست قرار ندارید. پاسخ 127.0.0.x به این معناست که شما در لیست هستید و اکتت نهایی نشان می‌دهد کدام زیرلیست با شما مطابقت داشته است. پاسخ در محدوده 127.255.255.x به این معناست که پرس‌وجو رد شده است، نه اینکه به آن پاسخ داده شده باشد؛ این اتفاق معمولاً زمانی می‌افتد که درخواست از طریق یک resolver عمومی بزرگ ارسال شده باشد که سرویس‌های رایگان به آن پاسخ نمی‌دهند. برای دریافت نتیجه واقعی، دستور را دوباره از طریق resolver خودِ سرور اجرا کنید.

خروج از لیست (Delisting) در سایت اپراتور لیست انجام می‌شود، نه از طریق میزبان (host) شما. این خروج تنها در صورتی پایدار می‌ماند که منبع مشکل ابتدا رفع شده باشد، زیرا تله‌ای که باعث لیست شدن شما شده است، با ارسال پیام بعدی دوباره شما را لیست خواهد کرد. دو مورد دیگر تعیین می‌کنند که آیا پس از آن ایمیل‌ها جریان می‌یابند یا خیر. رکورد PTR شما، که همان نام DNS معکوس برای IP است، توسط میزبان شما کنترل می‌شود؛ بنابراین از آن‌ها بخواهید رکوردی تنظیم کنند که به همان آدرس بازگردد و از آن نام به عنوان HELO خود استفاده کنید. همچنین، آدرسی که از مستأجر قبلی بازیافت شده باشد، ممکن است دارای سابقه‌ای باشد که شما ایجاد نکرده‌اید؛ پیش از آنکه یک هفته وقت خود را صرف بازنویسی DNS کنید، ارزش دارد در این مورد پرس‌وجو کنید. تنظیم صحیح رکوردهای SPF (چارچوب سیاست فرستنده) و DKIM (ایمیل شناسایی‌شده با کلید دامنه)، به همراه سیاست DMARC که آن‌ها را به هم متصل می‌کند، به‌طور کامل در راهنمای راه‌اندازی سرور ایمیل شخصی با Mailcow پوشش داده شده است.

زیرساخت رله، جایی که ایمیل‌های سوءاستفاده بخشی از کار است

اگر یک Tor exit node، یک VPN عمومی یا یک پراکسی برای دیگران اجرا می‌کنید، شکایت درباره ترافیکی که شما تولید نکرده‌اید، بخشی از هزینه‌های عادی عملیاتی است. هدف این است که وضعیت سرور شما به‌وضوح به عنوان یک رله شناخته شود، نه یک سرور هک‌شده. برای آدرس IP خود یک reverse DNS با نامی توصیفی تنظیم کنید، یک صفحه اطلاع‌رسانی کوتاه روی پورت 80 قرار دهید که توضیح دهد این آدرس چیست، به ایمیل‌های سوءاستفاده (abuse mail) به‌سرعت با همان توضیح پاسخ دهید و از هر سیاستی که نرم‌افزار برای مسدود کردن پورت‌های پرگزارش ارائه می‌دهد، استفاده کنید. این سرویس را روی یک IP اختصاصی و در صورت امکان در یک instance مجزا اجرا کنید تا null route شدن آن آدرس، باعث از دسترس خارج شدن برنامه‌های وب شما نشود. پیش از شروع، از میزبان (host) خود سوال کنید، زیرا قوانین مجاز بسته به شرکت و گاهی اوقات بلوک‌های IP متفاوت است و این موضوعی است که باید با آن‌ها مطرح شود، نه در یک انجمن گفتگو. مقاله اجرای یک Tor exit node روی VPS سیاست‌های خروجی و صفحه اطلاع‌رسانی را به‌طور دقیق بررسی می‌کند.

چگونه پاسخ دهیم تا تیکت بسته شود

• یک راه ارتباطی منتشر کنید که توسط انسان خوانده شود. طبق RFC 2142، آدرس‌های abuse@ و postmaster@ روی دامنه شما اولین گزینه‌هایی هستند که گزارش‌دهندگان امتحان می‌کنند. آن صندوق پستی را در جایی غیر از سروری که از آن محافظت می‌کند میزبانی کنید، زیرا یک نمونه (instance) معلق‌شده نمی‌تواند اعلان تعلیق خود را به شما تحویل دهد.
• لاگ‌ها را به اندازه کافی نگه دارید تا بتوانید پاسخگو باشید. گزارش مربوط به ترافیک دوازده روز پیش، اگر لاگ پس از هفت روز چرخش (rotate) شده باشد، غیرقابل پاسخگویی است. journalctl --disk-usage را بررسی کنید، MaxRetentionSec=90d را در /etc/systemd/journald.conf تنظیم کنید و سپس sudo systemctl restart systemd-journald را اجرا کنید. لاگ‌های وب و ایمیل طبق زمان‌بندی خودشان در /etc/logrotate.d/ چرخش می‌یابند.
• سرور را روی UTC تنظیم کنید تا برچسب زمانی (timestamp) در گزارش با برچسب زمانی در لاگ‌های شما بدون نیاز به محاسبات اضافی مطابقت داشته باشد.
• آنچه باعث شکایت می‌شود را از آنچه نمی‌توانید از دست بدهید جدا کنید. ایمیل روی یک آدرس، برنامه وب روی آدرس دیگر و سرویس‌های relay روی نمونه‌های اختصاصی خودشان باشند. اقدام انجام‌شده علیه یک 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.

آنچه می‌دانید را بگویید و آنچه هنوز بررسی نکرده‌اید را مشخص کنید. سکوت به معنای یک سرور بدون پشتیبانی تلقی می‌شود و مسیر تشدید (escalation) برای سرورهای بدون پشتیبانی وجود دارد. اینکه آیا این کارها اصلاً وظیفه شماست یا خیر، به محصولی که خریداری کرده‌اید بستگی دارد؛ این همان تفاوت عملی بین میزبانی VPS مدیریت‌شده و مدیریت‌نشده است. در یک طرح مدیریت‌نشده، مستأجر همان تیم امنیتی است.

وقتی همه‌چیز به‌درستی پیش می‌رود، وضعیت چگونه است

شکایت سوءاستفاده (abuse complaint) پیش از آنکه هر چیز دیگری باشد، یک مشکل مسیریابی است. گزارشی درباره یک آدرس به طرفی ارسال می‌شود که مسئول آن آدرس است و سپس به شخصی ارجاع داده می‌شود که می‌تواند مشکل را برطرف کند. بخش‌هایی که شما کنترل می‌کنید عبارتند از: آدرس تماس، مدت زمان نگهداری لاگ‌ها، نحوه تقسیم سرویس‌ها بین IPها و سرعت پاسخ‌دهی شما. اگر این موارد را به‌درستی مدیریت کنید، اکثر اخطارها پس از یک بار تبادل پیام پایان می‌یابند. همین عادت‌ها، پرسش بزرگ‌تر درباره امنیت میزبانی VPS را نیز حل می‌کنند؛ زیرا سروری که کسی آن را پایش نمی‌کند، همان سروری است که در نهایت در لاگ‌های دیگران ظاهر می‌شود.

FAQ

آیا دریافت شکایت سوءاستفاده (abuse) به معنای هک شدن VPS من است؟

لزوماً خیر، اما این اولین احتمالی است که باید بررسی کنید. گزارش تنها ثابت می‌کند که ترافیکی از IP شما ارسال شده است. ارسال اسپم و اسکن پورت‌ها بسیار بیشتر از آنکه توسط مالک حساب انجام شود، ناشی از یک برنامه یا کانتینرِ رخنه شده است. بنابراین پیش از هر اقدامی، صف ایمیل‌ها را با sudo postqueue -p و سوکت‌های در حال گوش دادن (listening) را با sudo ss -ltnp بررسی کنید. اخطارهای مربوط به کپی‌رایت و لیست‌های سیاه ماهیت متفاوتی دارند؛ این موارد معمولاً به سرویسی اشاره دارند که شما آگاهانه در حال اجرای آن هستید.

برای پاسخ به اخطار سوءاستفاده چقدر زمان دارم؟

مهلت پاسخ‌دهی در اخطاری که دریافت کرده‌اید ذکر شده و بسته به میزبان و نوع گزارش متفاوت است. گزارش‌های مربوط به کپی‌رایت و تله‌های اسپم (spam-trap) معمولاً کوتاه‌ترین مهلت را دارند. زمان ذکر شده را جدی بگیرید و حتی در حالی که مشغول ریشه‌یابی مشکل هستید، پیش از پایان مهلت، یک پاسخ کوتاه برای اعلام پیگیری ارسال کنید. آنچه برای کارشناس رسیدگی‌کننده به تیکت اهمیت دارد، این است که یک انسان در حال رسیدگی به موضوع باشد و ترافیک غیرمجاز متوقف شده باشد.

IP من در یک لیست سیاه (blocklist) قرار گرفته است. آیا میزبان من می‌تواند آن را حذف کند؟

خیر. حذف از لیست توسط گرداننده همان لیست و در وب‌سایت خودشان انجام می‌شود و میزبان شما هیچ کنترلی بر دیتابیس آن‌ها ندارد. میزبان شما تنها کنترل رکورد PTR یا همان نام reverse DNS برای IP شما را در اختیار دارد که درخواست برای اصلاح آن همزمان با پیگیری حذف از لیست سیاه، اقدامی منطقی است. پیش از درخواست برای حذف از لیست سیاه، مشکل ارسال ترافیک را برطرف کنید؛ زیرا تله اسپمی که شما را لیست کرده است، با ارسال پیام بعدی دوباره شما را لیست خواهد کرد.

آیا باید به میزبان خود بگویم دقیقاً چه اتفاقی افتاده است؟

شما باید اطلاعات کافی برای بستن تیکت را ارائه دهید: منبع مشکل چه بوده و چه زمانی متوقف شده است. نیازی نیست گزارش جرم‌شناسی یا داده‌های کاربران خود را ارائه دهید. پاسخ مبهم از پاسخ کوتاه بدتر است، زیرا کارشناسی که متوجه تغییرات نشود، دلیلی برای مختومه اعلام کردن پرونده نخواهد داشت.

آیا می‌توانم گزارش‌های خودکارِ ارسالی از اسکنرها را نادیده بگیرم؟

خیر. گزارش‌های خودکار شمارش می‌شوند و گزارش‌های تکراری درباره یک IP، امتیاز منفی علیه کل بلوک آدرسِ میزبان شما ایجاد می‌کند؛ این همان چیزی است که یک مورد کوچک را به یک بحران تبدیل می‌کند. پاسخ شما می‌تواند تنها یک پاراگراف باشد. سیستم گزارش‌دهی خودکار معمولاً آن را نمی‌خواند، اما کارشناسی که در شرکت میزبان به تیکت شما رسیدگی می‌کند آن را می‌خواند و او همان کسی است که درباره سرنوشت instance شما تصمیم می‌گیرد.