ماذا تعني شكوى إساءة استخدام VPS؟

ما هي شكوى إساءة استخدام VPS فعلياً

شكوى إساءة استخدام VPS هي بلاغ عن حركة شبكة خرجت من عنوان IP الخاص بك، وأُرسلت إلى جهة اتصال إساءة الاستخدام المنشورة لكتلة عناوين IP تلك، ثم أحالها إليك مضيفك مع مهلة للرد. تعود جهة الاتصال المنشورة إلى الشركة التي تملك نطاق العناوين، لذلك فإن أول شخص يقرأ بلاغاً عن خادمك لا يكون أنت في الغالب. يطابق مضيفك عنوان IP والطابع الزمني مع حسابك، ثم يحيل البلاغ إليك.

لا يثبت الإشعار أنك فعلت شيئاً عن قصد. عنوان IP هو المعرّف الوحيد المتاح لمُرسل البلاغ. ينتج تطبيق مخترق يرسل رسائل غير مرغوب فيها عند الساعة 03:00 البلاغ نفسه الذي ينتجه شخص يرسل رسائل غير مرغوب فيها عند الساعة 03:00. لذلك، يكون الرد هو الجزء الأهم. يُطلب منك تحديد مصدر المشكلة وشرح ما غيّرته.

من يرسل التقرير، وكيف يصل إلى خادمك

كل كتلة IP عامة مسجّلة لدى سجل إنترنت إقليمي (RIR): RIPE NCC أو ARIN أو APNIC أو LACNIC أو AFRINIC. ينشر كل تسجيل جهة اتصال للإبلاغ عن إساءة الاستخدام، وإليها تُرسل التقارير. يمكنك قراءة السجل نفسه الذي يقرأه مُرسل التقرير:

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

تتضمن سجلات RIPE كائن دور abuse-c: يحتوي على سطر abuse-mailbox:. وتتضمن سجلات ARIN OrgAbuseEmail:. يتلقى الشكوى عنوان البريد المنشور هناك، ولذلك يصل التقرير المتعلق بخادمك إلى مضيفك، لا إلى صندوق بريدك الوارد.

عادةً ما يكون الطرف الذي يقدّم التقرير جهازاً. وتغطي الأنواع الأربعة التالية معظم الحالات التي ستواجهها:

• الماسحات الآلية وأنظمة honeypot. يسجل جهاز محاولة اتصال من عنوان IP الخاص بك، ويقدّم تقريراً مرفقاً به مقتطف من السجل.
• حلقات الملاحظات (FBL) التي يديرها مزودو صناديق البريد. ينقر المستلم زر الرسائل غير المرغوب فيها، وتعود نسخة من الرسالة بتنسيق ARF (تنسيق الإبلاغ عن إساءة الاستخدام)، وهو تنسيق بريد منظم صُمّم لتحليله آلياً.
• وكلاء حقوق الطبع والنشر. يراقبون أسراب torrent أو يزحفون إلى عناوين URL عامة، ثم يرسلون إشعار DMCA (قانون حقوق الطبع والنشر للألفية الرقمية) يذكر ملفاً وعنوان IP الخاص بك وطابعاً زمنياً بتوقيت UTC.
• مشغلو قوائم الحظر ومهندسو الشبكات، الذين يرسلون رسالة بريد قصيرة تتضمن الأسطر المخالفة من سجلاتهم الخاصة.

بما أن معظم التقارير الأولى تُنشأ آلياً، فلن يحقق الجدال في الرد شيئاً. أما المعلومة الواقعية فتحقق الكثير: ما الذي كان يعمل، ومتى توقف.

لماذا يصل الإشعار مع مهلة زمنية

أنت أيضاً مستأجر لدى مزود الاستضافة. يقع نطاق عناوين خادمك خلف شركات نقل الشبكة upstream، وضمن قواعد بيانات السمعة التي تديرها جهات أخرى. تؤدي البلاغات التي لا يُرد عليها إلى رفع التقييم السلبي على الكتلة بأكملها، وليس على عنوانك وحده. لذلك تمثل المهلة التي تتلقاها ضغطاً يُنقل إليك من مستويات أعلى. اقرأ المهلة المحددة في الإشعار وتعامل معها على أنها ملزمة فعلياً.

عندما يُتخذ إجراء بشأن حالة لم يُرد عليها، يكون ذلك عادةً عبارة عن null route، أي إسقاط حركة الشبكة المتجهة إلى عنوان IP الواحد هذا على مستوى الشبكة upstream، أو تعليق instance. ويكون المحفز عادةً هو الصمت، لا الحدث الأصلي. يحدد كل من سياسة المضيف نفسه والإشعار ذاته ما الذي سيفعله أي مضيف محدد ومتى. هاتان الوثيقتان هما المصدران الوحيدان اللذان يستحقان الاقتباس، لذلك لا تتصرف بناءً على ما يزعم أحد المنتديات أن المزود يسمح به.

البريد المزعج الصادر: لماذا يرسل VPS الخاص بي رسائل لم أرسلها؟

يفيد التقرير بأن عنوان IP الخاص بك سلّم رسائل إلى مصيدة للبريد المزعج، أو بأن المستلمين صنّفوا رسائلك على أنها غير مرغوب فيها. تغطي أربعة مصادر معظم الحالات: تطبيق ويب يحتوي على نموذج لإرسال البريد دون تحديد لمعدل الطلبات، أو بيانات اعتماد SMTP مسرّبة يستخدمها شخص آخر الآن، أو خادم بريد يسمح بالترحيل لمضيفين لا ينبغي له السماح لهم بذلك، أو بيانات تسجيل دخول مسروقة إلى تطبيق النشرات البريدية. ابدأ بفحص قائمة الانتظار، لأن المُرسِل المخترق يظهر فيها عادةً:

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 بالترحيل للجهات المجهولة. ويصبح مرحّلاً مفتوحاً عندما توسّع mynetworks يدوياً ليشمل شبكة استضافة كاملة، لأن كل مستأجر آخر على تلك الشبكة يصبح موثوقاً به لإرسال البريد من خلالك. وأي اتصال بالمنفذ 25 تملكه عملية ليست خادم البريد الخاص بك يعني أن هناك نصاً برمجياً يرسل البريد من تلقاء نفسه، وهذا ما يفعله عادةً تطبيق PHP مخترق.

أوقف تدفق البريد قبل التحقيق، واحتفظ بالأدلة:

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

يفرغ sudo postsuper -d ALL قائمة الانتظار، كما أنه يتلف سجل الرسائل التي أُرسلت، لذلك أنشئ النسخة أولاً. بعد ذلك، غيّر كل بيانات الاعتماد التي يملكها التطبيق، وحدّث التطبيق، وابحث عما تركه المتسلل وراءه. تكون حادثة البريد المزعج والاختراق الحادثة نفسها في معظم الأحيان، لذلك اتبع خطوات استعادة VPS مخترق بدلاً من الاكتفاء بإفراغ قائمة الانتظار.

فحص المنافذ وهجمات التخمين المتكرر: كيف تبدو الحاوية المخترقة

يتضمن هذا التقرير أسطراً من سجلات مشغّل آخر، وتبدو على النحو الآتي:

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 أو [::] يستمع على العنوان العام. بدلاً من ذلك، انشر المنفذ على عنوان loopback، وهو -p 127.0.0.1:6379:6379، عندما يحتاج المضيف وحده إلى الوصول إليه. أما تحديد المكان الذي ينبغي أن توجد فيه قاعدة البيانات من الأساس فهو قرار منفصل، وتتناول تشغيل قاعدة البيانات في Docker أو على المضيف هذه المفاضلة.

لمعرفة ما إذا كان خادمك يجري فحصاً الآن:

sudo ss -tnp state syn-sent

وجود اتصالات كثيرة نصف مفتوحة إلى وجهات مختلفة يعني أن فحصاً صادراً جارٍ. كما يشير امتلاء سجل النواة برسائل nf_conntrack: table full, dropping packet إلى الأمر نفسه من زاوية أخرى: هناك شيء يفتح اتصالات أكثر بكثير مما يحتاج هذا الخادم إلى فتحه لأي سبب.

أعد إنشاء الحاوية المخترقة بدلاً من تنظيفها. لا يمكنك إثبات ما الذي تغيّر فيها أيضاً، لذلك أعد إنشاءها من صورة تثق بها، واستعد البيانات التي تثق بها فقط، وبدّل المفاتيح التي كانت تلك الحاوية تملكها.

إشعارات حقوق النشر: ما الملف الذي شاهدوه فعلياً

يذكر إشعار DMCA عنوان URL أو تجزئة معلومات torrent، وعنوان IP الخاص بك، وطابعاً زمنياً بتوقيت UTC. وهناك سببان يغطيان معظم هذه الحالات: دليل يعرضه خادم الويب للعامة ويحتوي على ملفات وسائط، أو عميل torrent يستمر في الرفع بعد اكتمال التنزيل.

طابق الطابع الزمني مع سجل الوصول. يضع تنسيق السجل الموحّد في 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، واربط عميل torrent بواجهة ليست الواجهة العامة. أرسل رداً يذكر اسم الملف والتغيير ووقت تنفيذه. إذا كنت ترى أن الادعاء نفسه غير صحيح، فهذه مسألة قانونية بينك وبين الجهة المرسلة، ويذكر الإشعار كيفية الاعتراض عليه. مضيفك ليس الجهة التي تفصل في ذلك، ولذلك لن يفيد فتح تذكرة تجادل في أساس الادعاء.

قوائم الحظر: لماذا توقف البريد الصادر عن العمل

غالباً لا يصلك أي بريد عند حدوث ذلك. يتوقف قبول البريد الصادر ببساطة، وتتضمن رسالة الارتداد السبب:

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 إلى أن الاستعلام رُفض بدلاً من الإجابة عنه، ويحدث ذلك عادةً لأن الاستعلام أُرسل عبر محلل DNS عام كبير لا توفّره الخدمة المجانية. أعد تشغيله من محلل DNS الخاص بالخادم للحصول على نتيجة فعلية.

تتم إزالة الإدراج من موقع مشغّل القائمة، وليس عبر مزوّد الاستضافة، ولا تستمر الإزالة إلا إذا أصلحت المصدر أولاً، لأن المصيدة التي أدرجت عنوانك ستدرجه مرة أخرى عند الرسالة التالية. وهناك أمران آخران يحددان ما إذا كان البريد سيُسلَّم بعد ذلك. يتحكم مزوّد الاستضافة في سجل PTR، أي اسم DNS العكسي لعنوان IP، لذا اطلب منه ضبط اسم يُحلّ إلى العنوان نفسه، واستخدم هذا الاسم في HELO. وقد يحمل عنوان أُعيد استخدامه بعد مستأجر سابق سجلّاً لم تنشئه أنت، لذلك يجدر بك الاستفسار عن ذلك قبل قضاء أسبوع في إعادة كتابة سجلات DNS. يوضَّح إعداد سجلات SPF (إطار سياسة المرسل) وDKIM (البريد المعرّف بمفاتيح النطاق)، إضافةً إلى سياسة DMARC التي تربط بينها، من البداية إلى النهاية في دليل تشغيل خادم البريد الخاص بك باستخدام Mailcow.

بنية Relay التحتية، حيث تُعد رسائل إساءة الاستخدام جزءاً من العمل

إذا كنت تشغّل عقدة خروج Tor، أو VPN عاماً، أو Proxy لمستخدمين آخرين، فستكون الشكاوى بشأن حركة الشبكة التي لم تُنشئها بنفسك تكلفة تشغيل عادية. تتمثل المهمة في أن يبدو الخادم بوضوح كـRelay، لا كخادم مخترق. اضبط reverse DNS على اسم وصفي، وقدّم صفحة إشعار قصيرة على المنفذ 80 توضّح طبيعة هذا العنوان، وردّ سريعاً على رسائل abuse mail بالتفسير نفسه، واستخدم أي سياسة يوفّرها البرنامج لإسقاط المنافذ التي تتسبب في أكبر عدد من التقارير. شغّل ذلك على عنوان IP مستقل، ويفضل أن يكون على instance مستقلة أيضاً، حتى لا يؤدي null route لذلك العنوان إلى تعطيل تطبيق الويب لديك معه. اسأل مزود الاستضافة قبل البدء، لأن المسموح به يختلف حسب الشركة وأحياناً حسب نطاق IP، وهذا سؤال ينبغي طرحه على الشركة لا في موضوع ضمن منتدى. يشرح تشغيل عقدة خروج Tor على VPS سياسة الخروج وصفحة الإشعار بالتفصيل.

كيفية الرد حتى يُغلق البلاغ

• انشر عنوان تواصل يقرأه شخص فعلياً. يحدّد RFC 2142 العنوانين abuse@ وpostmaster@ على نطاقك، وهما العنوانان اللذان يحاول المبلّغون استخدامهما أولاً. استضف صندوق البريد هذا في مكان مختلف عن الخادم الذي يحميه، لأن المثيل المعلّق لا يستطيع تسليم الإشعار الذي يخبرك بتعليقه.
• احتفظ بالسجلات مدة تكفي للإجابة عن البلاغ. لا يمكن الإجابة عن بلاغ يتعلق بحركة مرور حدثت قبل اثني عشر يوماً إذا دُوِّر السجل بعد سبعة أيام. تحقّق من journalctl --disk-usage، واضبط MaxRetentionSec=90d في /etc/systemd/journald.conf، ثم شغّل 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.

اذكر ما تعرفه، واذكر ما لم تتوصل إليه بعد. يُفهم الصمت على أنه دليل على أن الخادم غير مُدار، ومسار التصعيد موجود للخوادم غير المُدارة. يعتمد ما إذا كان هذا العمل من مسؤوليتك أصلاً على المنتج الذي اشتريته، وهذا هو الفرق العملي بين استضافة VPS المُدارة وغير المُدارة. في الخطة غير المُدارة، يكون المستأجر هو فريق الأمان.

كيف يبدو الأمر عند سيره على النحو الصحيح

تبدأ شكوى إساءة الاستخدام كمشكلة توجيه قبل أن تكون أي شيء آخر. يُرسَل البلاغ المتعلق بعنوان IP إلى الجهة المسؤولة عن ذلك العنوان، ثم يُحال إلى الشخص القادر على معالجة المشكلة. تتمثل الجوانب التي تتحكم فيها في عنوان التواصل الخاص بك، ومدة الاحتفاظ بالسجلات، وطريقة توزيع خدماتك على عناوين IP، وسرعة ردك. إذا ضبطت هذه الجوانب، تنتهي معظم الإشعارات بعد تبادل واحد. وتساعد العادات نفسها في حسم السؤال الأكبر حول ما إذا كانت استضافة VPS آمنة، لأن الخادم الذي لا يراقبه أحد هو الخادم الذي ينتهي به الأمر في سجلات شخص آخر.

FAQ

هل تعني شكوى إساءة الاستخدام أن VPS الخاص بي تعرّض للاختراق؟

ليس بالضرورة، لكن يجب استبعاد ذلك أولاً. يثبت التقرير فقط أن حركة شبكة خرجت من عنوان IP الخاص بك. غالباً ما ينتج البريد العشوائي الصادر وفحص المنافذ عن تطبيق أو حاوية مخترقة، وليس عن صاحب الحساب، لذلك افحص قائمة انتظار البريد باستخدام sudo postqueue -p والمقابس التي تستمع للاتصالات باستخدام sudo ss -ltnp قبل أي شيء آخر. تختلف إشعارات حقوق الطبع والنشر وقوائم الحظر من حيث طبيعتها؛ فهي تشير عادةً إلى شيء تشغّله عن قصد.

كم من الوقت لدي للرد على إشعار إساءة الاستخدام؟

تحدد المهلة في الإشعار الذي تلقيته، وتختلف حسب مضيف الخدمة ونوع البلاغ. عادةً ما تكون المهلات الأقصر في بلاغات حقوق الطبع والنشر ومصائد البريد العشوائي. تعامل مع المهلة المحددة على أنّها فعلية، وأرسل رداً مختصراً يفيد بأنك تتابع المشكلة قبل انتهائها، حتى إذا كنت لا تزال تتعقب السبب. ما يهم الشخص الذي يعالج التذكرة هو أن شخصاً يتولى الأمر وأن حركة الشبكة قد توقفت.

عنوان IP الخاص بي مدرج في قائمة حظر. هل يستطيع مضيف الخدمة إزالته؟

لا. يتولى مشغّل القائمة إزالة الإدراج من موقعه، ولا يملك مضيف الخدمة أي تحكم في قاعدة بياناته. لكن مضيف الخدمة يتحكم في سجل PTR، أي اسم DNS العكسي لعنوان IP الخاص بك، وهو طلب منفصل يستحق تقديمه في الوقت نفسه. أصلح مشكلة الإرسال قبل طلب إزالة الإدراج، لأن مصيدة البريد العشوائي التي أدرجتك ستدرجك مرة أخرى عند الرسالة التالية.

هل يجب أن أخبر مضيف الخدمة بما حدث فعلاً؟

يجب أن تخبرهم بما يكفي لإغلاق التذكرة: ما مصدر المشكلة ومتى توقفت. لا يلزمك تقديم تقرير جنائي رقمي أو بيانات المستخدمين. الرد الغامض أسوأ من الرد المختصر، لأن الشخص الذي يعالج التذكرة ولا يستطيع معرفة ما الذي تغيّر لن يملك سبباً لاعتبار الحالة محلولة.

هل يمكنني تجاهل تقرير آلي من أداة فحص؟

لا. تُحتسب التقارير الآلية، وتؤدي التقارير المتكررة عن عنوان IP واحد إلى رفع التقييم السلبي على كامل نطاق العناوين التابع لمضيف الخدمة، وهذا ما يحوّل الحالة الصغيرة إلى تصعيد. يمكن أن يتكون ردك من فقرة واحدة. غالباً لا يقرأه مُصدر التقرير الآلي، لكن الشخص الذي يعالج التذكرة لدى مضيف الخدمة يقرأه، وهو من يقرر ما سيحدث لمثيلتك.