تدقيق أمان VPS شهري للعميل: قائمة في 45 دقيقة

تحقّق من حالة قائمة، لا تعد بناءها

حدّد النطاق قبل أول تدقيق

ما يُجهَّز مرة واحدة قبل التدقيق

• حساب تدقيق مخصص — مستخدم باسم صاحبه مع sudo محصور في قراءة السجلات وفحص الشبكة، بدل حساب root مشترك.
• قائمة متوقعة لكل VPS — المنافذ التي يجب أن تستمع، والحسابات المصرّح بها، والنطاقات المخدومة، وأداة النسخ الاحتياطي ومستودعها. بلا مرجع لا تتميز المخالفة عن السلوك العادي.
• سكربت جمع للقراءة فقط — يسلسل أوامر القائمة ويكتب كل شيء في ملف مؤرخ، فلا يُكتب كل أمر إلا مرة واحدة.
• مجلد أرشيف لكل عميل — مجلد فرعي لكل شهر، محفوظ خارج الخادم المدقَّق، لتمكين مقارنة الأشهر.
• نموذج تقرير — القالب نفسه لجميع العملاء، يُملأ من المخرجات المجمّعة.
• تقويم — يوم ثابت من الشهر لكل عميل، مدوّن في أجندة الفريق، وإلا سقط التدقيق في أول شهر مزدحم.

الفحوصات السبعة وميزانية وقت كل منها

1. 01

   التحديثات المعلّقة (6 دقائق)

   sudo apt update
apt list --upgradable 2>/dev/null
apt list --upgradable 2>/dev/null | grep -i security
   اعزلوا الحزم التي ينتهي مصدرها بـ -security: تُعالج أولًا. أما البقية فتمرّ بتحقق بشري، لأن قفزة إصدار رئيسية قد تكسر تطبيقًا. على AlmaLinux أو RHEL يؤدي sudo dnf check-update --security الدور نفسه. وحتى مع تفعيل التحديثات التلقائية يُظهر هذا الفحص ما بقي عالقًا.

2. 02

   النواة وإعادة التشغيل المعلّقة (4 دقائق)

   uname -r
ls /boot/vmlinuz-*
ls /var/run/reboot-required
sudo needrestart -b -r l
   إذا اختلفت أحدث نواة مثبّتة عن uname -r، أو وُجد /var/run/reboot-required، فإعادة التشغيل مستحقة. في مخرجات needrestart يبيّن السطر NEEDRESTART-KSTA هل النواة المحمّلة محدّثة، وتعرض القائمة الخدمات التي ما زالت تستخدم مكتبات قديمة. لا تُجرى إعادة التشغيل منفردًا أبدًا: تُجدول مع العميل.

3. 03

   الحسابات ومفاتيح SSH (8 دقائق)

   awk -F: '$3>=1000' /etc/passwd
getent group sudo
sudo ssh-keygen -lf /home/<حساب>/.ssh/authorized_keys
lastlog | grep -v 'Never logged in'
last -n 20
   يجب أن يقابل كل حساب بشري شخصًا معروفًا لدى العميل أو الوكالة. ويجب أن تعود كل بصمة مفتاح إلى شخص ما زال يعمل على المشروع. حساب لم يتصل منذ أشهر، أو مفتاح مجهول، يصير برتقاليًا ويُرسل إلى العميل للتحقق.

4. 04

   المنافذ المفتوحة (5 دقائق)

   sudo ss -tlnp
sudo ss -ulnp
sudo ufw status verbose
   قارنوا النتيجة بالقائمة المتوقعة لهذا الخادم. قاعدة بيانات تستمع على كل الواجهات بدل الحلقة المحلية، أو منفذ اختبار منسي، أو خدمة مجهولة: تُسجَّل كل مخالفة مع العملية التي تفتحها، دون إغلاقها فورًا، لأن خدمة قد تعتمد على ذلك المنفذ.

5. 05

   الشهادات (4 دقائق)

   openssl s_client -connect your-domain‎.com:443 -servername your-domain‎.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
   اقرأوا تاريخ الانتهاء من الخدمة المعروضة فعلًا، لا من وجود مؤقّت التجديد فقط: فقد يفشل مؤقّت نشط كل ليلة. وإذا مرّ النطاق عبر CDN فهذا الأمر يقرأ شهادة الـ CDN. وللمصدر، استبدلوا المضيف في -connect بعنوان IP الخاص بالخادم مع إبقاء -servername.

6. 06

   النسخ الاحتياطية المستعادة (10 دقائق)

   restic snapshots
restic restore latest --target /tmp/restore-test --include /etc/nginx
   دوّنوا تاريخ آخر نقطة استعادة، ثم استعيدوا فعلًا ملفًا أو قاعدة بيانات في مجلد مؤقت وافتحوه. النسخة التي لم تُستعَد قط ليست دليلًا بل فرضية. احذفوا المجلد المؤقت بعد ذلك. وإذا استخدم العميل أداة أخرى فالمنطق نفسه: قائمة النقاط، واستعادة جزئية، وفحص المحتوى.

7. 07

   سجلات المصادقة (8 دقائق)

   sudo journalctl -u ssh --since '30 days ago' --no-pager | grep -c 'Failed password'
sudo journalctl -u ssh --since '30 days ago' --no-pager | grep 'Accepted'
sudo journalctl _COMM=sudo --since '30 days ago' --no-pager
   أحصوا الإخفاقات، واسردوا الاتصالات الناجحة وابحثوا عن تلك القادمة من عنوان مجهول. راجعوا استخدامات sudo. على RHEL ومشتقاته تسمى الوحدة sshd لا ssh.

ميزانية الـ 45 دقيقة لكل VPS

مرّر الجدول أفقيًا

سكربت جمع بدل سبع جلسات يدوية

أرشفوا وقارنوا: هنا يظهر الانحراف

تقرير الصفحة الواحدة المسلَّم للعميل

1. 08

   الترويسة

   اسم العميل، ومعرّف الـ VPS، وعنوان IP، وتاريخ التدقيق، واسم من أجراه.

2. 09

   جدول الفحوصات السبعة

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

3. 10

   المخالفات المرصودة

   كل مخالفة في جملة واقعية واحدة مع الدليل: سطر المخرجات، والمنفذ، والحساب المعني.

4. 11

   الإجراءات المنفَّذة

   ما طبقته الوكالة وحدها ضمن النطاق المتفق عليه، مثل تحديث أمني.

5. 12

   الإجراءات المعروضة على العميل للموافقة

   إعادة التشغيل، وحذف حساب، وإغلاق منفذ، مع خطر عدم فعل شيء.

6. 13

   الموعد التالي

   تاريخ التدقيق القادم، ولكل مخالفة برتقالية أو حمراء أجل نهائي للمعالجة.

حين لا يقول المخرج ما يبدو أنه يقوله

• needrestart غير موجود — الحزمة ليست مثبتة افتراضيًا في كل مكان. ثبّتوها مرة واحدة بموافقة العميل، أو قارنوا يدويًا uname -r بالنوى الموجودة في /boot.
• لا إخفاقات SSH في السجلات — تحققوا من اسم الوحدة قبل الاستنتاج. بحسب التوزيعة تُسجَّل المصادقة تحت ssh أو sshd أو، في إصدارات OpenSSH الحديثة، sshd-session. جرّبوا sudo journalctl _COMM=sshd-session --since '30 days ago'.
• ss -tlnp لا يعرض العمليات — بدون sudo يبقى عمود العمليات فارغًا لخدمات المستخدمين الآخرين.
• شهادة صالحة بينما يعرض الموقع خطأ — قرأتم شهادة CDN أو vhost آخر. وجّهوا الطلب إلى عنوان الـ VPS ومرّروا -servername الصحيح.
• restic يطلب كلمة مرور — المستودع مشفّر. احصلوا على السر من العميل قبل التدقيق لا أثناءه، وإلا سقط الفحص.

اعتراض الوقت: 45 دقيقة لكل عميل كل شهر

حين تكبر المحفظة

للمتابعة

• إرساء الأساس — يصف /blog/linux-hardening-vps-checklist التقوية الأولية التي يتحقق منها هذا التدقيق.
• أتمتة التصحيحات — يشرح /blog/securite-vps-mises-a-jour-automatiques-debian-ubuntu أداة unattended-upgrades التي يقيس الفحص الأول ما تبقى منها.
• النسخ الاحتياطي الصحيح — يغطي /blog/backup-vps-restic-s3-3-2-1 إعداد Restic الذي يتحقق الفحص السادس من استعادته.
• المراقبة المستمرة — يكمّل /blog/alertes-disque-ram-vps-monitoring-proactif التدقيق الشهري بتنبيهات بين مرورين.
• جرد إصدارات PHP — يطبق /blog/inventaire-versions-php-parc-sites-clients-agence الانضباط نفسه على أسطول المواقع.
• التفاعل مع ثغرة — تبيّن أدلة التصحيح في فئة الأمان والمراقبة بالمدونة ما يتيحه جرد محدَّث في اليوم الأول.

الوثائق الرسمية