الذكاء الاصطناعي وأمان الخادم: كيف يكشف محاولات الاختراق قبل أن تتحول إلى حادثة؟

يساعد الذكاء الاصطناعي في أمان الخادم بقراءة ما لا يتسع وقت الإنسان لقراءته: سجلات تسجيل الدخول، والملفات الجديدة في مجلدات الرفع، وقائمة الإضافات، والبريد الصادر. فينبهك إلى أربعة أنماط متكررة: تخمين كلمات المرور على SSH وwp-login.php، وملفات PHP في مجلد uploads، وإضافات فيها ثغرات معروفة، وعلبة بريد مخترقة ترسل البريد المزعج. ثم يرفق الدليل ويقترح الإجراء، ولا ينفذه إلا بموافقتك.

لماذا يحتاج أمان الخادم إلى من يقرأ السجلات؟

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

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

ما الذي يراقبه الذكاء الاصطناعي تحديدًا؟

كيف يكشف تخمين كلمات المرور على SSH وwp-login؟

على SSH

هذا مقتطف نموذجي من سجل المصادقة في خادم Debian أو Ubuntu:

Oct 25 02:14:07 server sshd[48211]: Failed password for root from 203.0.113.45 port 51122 ssh2
Oct 25 02:14:09 server sshd[48211]: Failed password for root from 203.0.113.45 port 51122 ssh2
Oct 25 02:14:12 server sshd[48215]: Invalid user admin from 203.0.113.45 port 51190
Oct 25 02:14:15 server sshd[48219]: Failed password for invalid user oracle from 203.0.113.45 port 51244 ssh2

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

• ضوضاء عامة: محاولات على أسماء غير موجودة. يكفي أن تكون المصادقة بكلمة المرور معطلة.
• استهداف: محاولات على اسم مستخدم حقيقي موجود على الخادم. هذا يستحق حظر عنوان IP ومراجعة من يعرف هذا الاسم.
• نجاح بعد فشل: سطر Accepted password من العنوان نفسه بعد سلسلة فشل. هذه أخطر حالة، ويعرضها في أعلى التقرير مع وقت الدخول وما حدث بعده.

الإجراء الذي يقترحه عادة في الحالتين الأوليين هو قصر SSH على المفاتيح:

# /etc/ssh/sshd_config.d/hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

وينبهك قبل الموافقة إلى خطوة لا تُتخطى: تأكد أن دخولك بالمفتاح يعمل في جلسة ثانية قبل إعادة تحميل SSH، حتى لا تغلق الباب على نفسك.

على wp-login.php

في سجل الوصول تظهر المحاولات على شكل طلبات POST متكررة:

198.51.100.23 - - [25/Oct/2026:02:20:41 +0000] "POST /wp-login.php HTTP/1.1" 200 4120 "-" "Mozilla/5.0"
198.51.100.23 - - [25/Oct/2026:02:20:42 +0000] "POST /wp-login.php HTTP/1.1" 200 4120 "-" "Mozilla/5.0"
198.51.100.31 - - [25/Oct/2026:02:20:42 +0000] "POST /xmlrpc.php HTTP/1.1" 200 412 "-" "Mozilla/5.0"

حالة الاستجابة 200 هنا لا تعني نجاح الدخول، فWordPress يعيد صفحة الدخول مع رسالة خطأ. لهذا يقارن الذكاء الاصطناعي بين حجم الاستجابة المعتاد للفشل وأي استجابة مختلفة، ويبحث عن إعادة توجيه إلى /wp-admin/ من العنوان نفسه، وهي علامة الدخول الناجح.

وحين تأتي المحاولات من عناوين كثيرة بمعدل منخفض لكل عنوان، يكون حظر العناوين واحدًا تلو الآخر بلا فائدة تقريبًا. هنا يكون الاقتراح الأنسب تفعيل المصادقة الثنائية لحسابات المديرين، وتعطيل xmlrpc.php إن لم يكن الموقع يحتاجه، وتغيير كلمات المرور الضعيفة.

ماذا يعني وجود ملفات PHP في مجلد uploads؟

مجلد wp-content/uploads مخصص للصور والمرفقات. وجود ملف PHP فيه يكاد يكون دائمًا علامة على أن أحدًا استغل ثغرة ورفع أداة تحكم عن بعد (Web Shell). أمر بسيط يكشفها:

find /home/example/public_html/wp-content/uploads \
  -type f -name '*.php' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

2026-10-24 03:12  /home/example/public_html/wp-content/uploads/2026/10/cache.php

لا يكتفي الذكاء الاصطناعي بوجود الملف، بل يجمع حوله الأدلة: محتواه (هل فيه eval أو base64_decode أو assert على مدخلات من الطلب؟)، ووقت إنشائه، والطلبات التي وصلت إليه في سجل الوصول، والطلب الذي سبق إنشاءه مباشرة. هذا الأخير هو غالبًا مدخل المهاجم: إضافة نموذج رفع، أو ثغرة في قالب.

لماذا لا يحذف الملف تلقائيًا؟

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

1. حفظ نسخة من الملف وسجلات الفترة كدليل.
2. تحديد المدخل وإغلاقه، بتحديث الإضافة أو تعطيلها.
3. البحث عن تعديلات أخرى في الملفات ومستخدمين جدد في قاعدة البيانات.
4. الاستعادة من نسخة احتياطية سابقة لتاريخ الإصابة إن كان التنظيف غير مضمون، كما في استراتيجية النسخ الاحتياطي 3-2-1.
5. تغيير كلمات المرور ومفاتيح WordPress السرية.

وكإجراء وقائي، يمكن منع تنفيذ PHP في مجلد الرفع أصلًا. ضع هذه الكتلة قبل كتلة PHP العامة، لأن Nginx يطبق أول كتلة regex تطابق الطلب:

# must come before the general "location ~ \.php$" block
location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

لماذا الإضافات القديمة أخطر من كلمات المرور الضعيفة؟

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

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

والاقتراح المعتاد هو التحديث، لكن التحديث نفسه قد يكسر الموقع. لذلك يمر عبر نسخة تجريبية أولًا ثم يُنشر، والتفاصيل في مقال صيانة WordPress بالذكاء الاصطناعي.

كيف تعرف أن علبة بريد مخترقة ترسل البريد المزعج؟

العلامة الأوضح قفزة في البريد الصادر من علبة بريد واحدة، لا من الخادم كله. لنفترض أن علبة sales@example.sa ترسل في العادة بضع عشرات من الرسائل يوميًا، ثم ظهر في سجل خادم البريد هذا النمط في ساعة واحدة:

2026-10-25 03:05:11 auth ok user=sales@example.sa ip=203.0.113.88
2026-10-25 03:05:14 out from=sales@example.sa rcpt=47 subject="Invoice overdue"
2026-10-25 03:05:16 out from=sales@example.sa rcpt=50 subject="Invoice overdue"
2026-10-25 03:06:02 bounce from=sales@example.sa reason="550 user unknown"

يربط الذكاء الاصطناعي بين ثلاثة أدلة: تسجيل دخول ناجح من عنوان لم يُرَ مع هذه العلبة من قبل، ورسائل كثيرة بعدد كبير من المستلمين وموضوع واحد، ونسبة مرتفعة من الرسائل المرتدة. هذا يكفي لاستنتاج أن كلمة المرور سُرقت، لا أن الموقع مخترق.

الخطة التي يقترحها:

1. إيقاف الإرسال من هذه العلبة مؤقتًا، بموافقة صاحب الحساب أو مدير الخادم.
2. تغيير كلمة المرور وإنهاء الجلسات المفتوحة.
3. مراجعة قواعد إعادة التوجيه والردود التلقائية، فالمهاجمون يضيفونها ليستمروا بعد تغيير كلمة المرور.
4. تفريغ الرسائل العالقة في طابور الإرسال.
5. متابعة سمعة عنوان الخادم في الأيام التالية.

كل ساعة يستمر فيها الإرسال تضر بسمعة الخادم وكل المجالات عليه، وهذا ما يجعل الكشف المبكر مهمًا. ولفهم أثر ذلك على وصول البريد راجع دليل SPF وDKIM وDMARC.

ما الذي ينبهك إليه الذكاء الاصطناعي، وما الذي لا يفعله وحده أبدًا؟

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

ما الأساس الذي لا يغني عنه أي ذكاء اصطناعي؟

الذكاء الاصطناعي يكشف ويشرح، لكن الحماية تبدأ قبله:

• المصادقة الثنائية لكل حساب يملك صلاحيات إدارة، في لوحة التحكم وفي WordPress.
• جدار الحماية يفتح المنافذ اللازمة فقط، ويمنع العناوين التي ثبت سوء سلوكها.
• سجل تسجيل الدخول تراجعه بنفسك من وقت لآخر، حتى بلا تنبيه.
• العزل بين الحسابات: حين يعمل كل موقع بمستخدم Linux خاص به، يبقى اختراق موقع واحد محصورًا فيه.
• التحديثات المنتظمة للنظام وPHP والإضافات.
• نسخ احتياطية خارج الخادم، فهي خط الرجوع الأخير بعد أي اختراق.

كيف يساعدك bPanel؟

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

وفي اللوحة نفسها شاشة أمان فيها المصادقة الثنائية وجدار الحماية وسجل تسجيل الدخول، وفحص يومي لإضافات WordPress وقوالبه بحثًا عن الثغرات المعروفة، ونسخ تجريبية لتجربة التحديث قبل نشره. ولكل حساب استضافة مستخدم Linux خاص وPHP-FPM pool خاص. يمكنك تجربة كل ذلك على خادمك سبعة أيام مجانًا من ابدأ مع bPanel.

الخلاصة

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