تأمين وتحصين سيرفر VPS من الصفر

لماذا تحصين VPS ليس خيارًا بل ضرورة؟

في اللحظة التي يصبح فيها خادمك متصلًا بالإنترنت بعنوان IP عام، يصبح هدفًا. هذه ليست مبالغة تخويفية، بل واقع قابل للقياس: ضع خادمًا جديدًا على الإنترنت بمنفذ SSH مفتوح على المنفذ 22، وراقب سجلّاته بعد ساعة واحدة. ستجد عشرات بل مئات محاولات تسجيل الدخول من عناوين IP حول العالم تجرّب أسماء مستخدمين شائعة (root, admin, user) وكلمات مرور من قوائم مسرّبة. هذه ليست هجمات موجّهة ضدّك شخصيًا، بل روبوتات (bots) تمسح الإنترنت بالكامل آليًا، تبحث عن أي خادم بإعداد افتراضي ضعيف لتخترقه.

الفرق بين الاستضافة المشتركة والـVPS جوهري هنا. في الاستضافة المشتركة، المزوّد يتولّى تأمين الخادم، وأنت معزول في حسابك. أمّا في الـVPS غير المُدار فأنت المسؤول الوحيد عن الأمان من الطبقة صفر. الخادم يصلك بنظام تشغيل خام وكلمة مرور root، وكل ما بعد ذلك — التحصين، التحديثات، المراقبة — عليك أنت. هذه القوة هي نفسها مصدر الخطر: خادم مُعَدّ افتراضيًا دون تحصين هو دعوة مفتوحة.

العواقب ليست نظرية. خادم مخترَق قد يُستخدم لإرسال بريد مزعج (spam) فيُحظر IP الخاص بك، أو يُحوَّل إلى عقدة في شبكة هجمات DDoS، أو يُعدَّن عليه عملات رقمية فتلتهم وحدة المعالجة موارده وفاتورتك، أو — الأسوأ — تُسرَق بيانات عملائك وقواعد بياناتك. والأخطر أن الاختراق غالبًا صامت: المهاجم لا يريد أن تكتشفه، بل يريد البقاء أطول فترة ممكنة.

الفلسفة: الدفاع في العمق (Defense in Depth)

المبدأ الذي يحكم هذا الدليل كلّه هو الدفاع في العمق: لا تعتمد على طبقة حماية واحدة، بل تبني عدّة طبقات مستقلّة بحيث إذا اخترق المهاجم واحدة، تصدّه التالية. لو اعتمدت على كلمة مرور قوية فقط، فإن تسريبها يعني انهيار كل شيء. لكن لو كان الدخول بمفتاح SSH (لا كلمة مرور)، وعلى منفذ غير قياسي، خلف جدار حماية يرفض كل المنافذ إلا المسموحة، مع Fail2ban يحظر المحاولات المتكرّرة، ومستخدم بصلاحيات محدودة لا يملك root — فإن اختراق طبقة واحدة لا يكفي إطلاقًا.

كل طبقة في هذا المخطّط مستقلّة عن الأخرى، وكل واحدة تضيف عائقًا جديدًا أمام المهاجم. الطبقات من الخارج إلى الداخل: التحكّم في الوصول (مفاتيح SSH وتعطيل root)، جدار الحماية (UFW)، كشف التسلّل والصدّ (Fail2ban)، تقليل سطح الهجوم (إيقاف الخدمات)، الحماية الذاتية (التحديثات التلقائية)، وأخيرًا الرؤية والتعافي (المراقبة والنسخ الاحتياطي). سنبني هذه الطبقات واحدة تلو الأخرى.

نظرة عامة على خريطة التحصين (قائمة تحقّق مبدئية)

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

إن كنت تنطلق من خادم فارغ تمامًا ولم تجرِ بعد الإعداد الأساسي (الاتصال الأول، تحديث النظام)، فابدأ بدليل إعداد أول سيرفر VPS من الصفر ثم عُد إلى هنا لطبقات التحصين المتقدّمة. وإن لم تكن متمكّنًا من أساسيات الاتصال بعد، فمقال أساسيات SSH هو نقطة البداية الصحيحة.

الطبقة الأولى: المستخدم non-root ومبدأ أقلّ امتياز

أوّل خطأ يرتكبه المبتدئون هو العيش داخل حساب root. مستخدم root هو الإله المطلق على نظام لينكس: يستطيع حذف أي ملف، تعديل أي إعداد، تثبيت أو إزالة أي شيء دون قيد. تشغيل أعمالك اليومية كـroot يعني أن أي خطأ مطبعي قد يدمّر النظام، وأن أي برنامج مخترَق يحصل فورًا على سيطرة كاملة. الحل هو مبدأ أقلّ امتياز (Least Privilege): تعمل دائمًا بأقلّ صلاحيات تكفي مهمّتك، وترفع الصلاحية مؤقتًا عند الحاجة فقط عبر sudo.

إنشاء مستخدم بصلاحيات sudo

اتصل بالخادم كـroot أول مرة، ثم أنشئ مستخدمًا جديدًا (سنسمّيه deploy كمثال) وأضفه إلى مجموعة sudo:

# أنشئ المستخدم الجديد (سيطلب منك تعيين كلمة مرور وبيانات اختيارية)
adduser deploy

# أضف المستخدم إلى مجموعة sudo (على Ubuntu/Debian)
usermod -aG sudo deploy

# على AlmaLinux/CentOS استخدم مجموعة wheel بدلًا من sudo:
# usermod -aG wheel deploy

# تحقّق من أن المستخدم في المجموعة الصحيحة
groups deploy

الآن صار لديك مستخدم deploy يستطيع تنفيذ أوامر إدارية بكتابة sudo قبلها (وسيُطلب منه كلمة مروره للتأكيد). تذكّر: لا تنتقل إلى تعطيل دخول root قبل أن تتأكّد تمامًا أن مستخدم deploy يعمل ويستطيع الدخول والحصول على sudo — وإلّا قد تقفل نفسك خارج الخادم.

مبدأ أقلّ امتياز عمليًا

الطبقة الثانية: مفاتيح SSH بدل كلمة المرور

أهمّ قرار أمني تتّخذه على الإطلاق هو التخلّي عن كلمة مرور SSH واستبدالها بمفاتيح التشفير. كلمة المرور — مهما كانت طويلة — قابلة للتخمين، ويمكن سرقتها بالتصيّد، وتُجرَّب آليًا ملايين المرّات. أمّا مفتاح SSH فهو زوج رياضي ضخم (عادةً 256 بت لـEd25519): مفتاح خاص يبقى على جهازك ولا يغادره أبدًا، ومفتاح عام يوضع على الخادم. لا يمكن اشتقاق الخاص من العام، ولا يمكن تخمينه عمليًا.

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

توليد زوج المفاتيح على جهازك

نفّذ هذا على جهازك المحلّي (لا على الخادم). نوصي بخوارزمية Ed25519 الحديثة، السريعة والأكثر أمانًا:

# ولّد زوج مفاتيح Ed25519 (الأفضل اليوم)
ssh-keygen -t ed25519 -C "deploy@my-vps" -f ~/.ssh/id_ed25519

# بديل متوافق مع أنظمة قديمة جدًا (RSA بطول 4096 بت)
# ssh-keygen -t rsa -b 4096 -C "deploy@my-vps"

سيُطلب منك إدخال عبارة مرور (passphrase) للمفتاح الخاص — أدخل عبارة قوية. هذه طبقة أمان إضافية: حتى لو سُرق ملف المفتاح الخاص، يبقى المهاجم عاجزًا دون العبارة. ستحصل على ملفّين: id_ed25519 (الخاص — احمِه بحياتك ولا تشاركه أبدًا) وid_ed25519.pub (العام — هذا الذي ينسخ للخادم).

نسخ المفتاح العام إلى الخادم

# الطريقة الأسهل: ssh-copy-id ينسخ المفتاح العام إلى المستخدم على الخادم
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

# إن لم يتوفّر ssh-copy-id، انسخ يدويًا:
cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

الآن جرّب الدخول: ssh deploy@203.0.113.10. يجب أن تدخل دون أن يُطلب منك كلمة مرور حساب الخادم (قد يُطلب منك عبارة مرور المفتاح إن وضعتها). لا تتقدّم خطوة واحدة قبل أن تتأكّد أن دخول المفتاح يعمل، لأن الخطوة التالية تعطّل كلمة المرور نهائيًا. لمزيد من تفاصيل توليد المفاتيح وإدارتها، راجع أساسيات SSH.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

الطبقة الثالثة: تحصين إعدادات sshd

الآن نأتي لقلب التحصين: ملف إعداد خدمة SSH على الخادم، الموجود في /etc/ssh/sshd_config. هنا نعطّل كل ما يفتح الباب للمهاجمين. افتح الملف بمحرّر (افعل ذلك من جلسة deploy بـsudo):

sudo nano /etc/ssh/sshd_config

عدّل (أو أضف) القيم التالية. الأهمّ: PermitRootLogin no, PasswordAuthentication no, وتحديد المنفذ والمستخدمين المسموحين:

# منفذ غير قياسي يقلّل ضوضاء المسح الآلي (اختياري لكن مفيد)
Port 2222

# منع دخول root مباشرة — يجب الدخول كمستخدم عادي ثم sudo
PermitRootLogin no

# تعطيل مصادقة كلمة المرور بالكامل — مفاتيح فقط
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# تفعيل مصادقة المفتاح العام صراحةً
PubkeyAuthentication yes

# منع المصادقة الفارغة وتقييد المحاولات والجلسات
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# قصر الدخول على مستخدمين محدّدين فقط
AllowUsers deploy

# تعطيل تمرير X11 إن لم تكن تحتاجه
X11Forwarding no

بعد الحفظ، اختبر صحّة الإعداد قبل إعادة التشغيل لتجنّب كسر الخدمة:

# افحص بنية الملف بحثًا عن أخطاء قبل التطبيق
sudo sshd -t

# إن لم يظهر خطأ، أعد تشغيل خدمة SSH
sudo systemctl restart ssh

# على بعض الأنظمة قد يكون اسم الخدمة sshd:
# sudo systemctl restart sshd

حرجة جدًا: قبل أن تغلق جلستك الحالية، افتح جلسة SSH جديدة في نافذة منفصلة وتأكّد أنك تستطيع الدخول بالمنفذ والمستخدم الجديدين (ssh -p 2222 deploy@203.0.113.10). إن نجحت، أغلق القديمة بأمان. إن فشلت، لا تزال جلستك القديمة مفتوحة لتصحيح الخطأ. هذه القاعدة تنقذك من سيناريو "قفلت نفسي خارج الخادم".

جدول إعدادات sshd_config الموصى بها

ملاحظة مهمّة: إن غيّرت المنفذ، فستحتاج لفتح المنفذ الجديد في جدار الحماية UFW قبل إعادة تشغيل SSH (الخطوة التالية)، وإلّا سيحجب UFW اتصالك الجديد. الترتيب الآمن: افتح المنفذ في UFW أولًا، ثم بدّل المنفذ في sshd، ثم أعد التشغيل.

الطبقة الرابعة: جدار الحماية UFW

جدار الحماية هو الحارس عند بوّابة الخادم: يقرّر أي حركة شبكية تُسمح وأيها تُرفض. المبدأ الذهبي هو سياسة الرفض الافتراضي (Default Deny): ارفض كل الاتصالات الواردة، ثم افتح فقط المنافذ التي تحتاجها فعلًا، بدلًا من فتح كل شيء ومحاولة سدّ الثغرات لاحقًا. أداة UFW (اختصار Uncomplicated Firewall) تجعل هذا سهلًا على Ubuntu/Debian.

# ثبّت UFW إن لم يكن موجودًا
sudo apt update && sudo apt install -y ufw

# الخطوة الأهمّ: ارفض كل الوارد، اسمح بكل الصادر
sudo ufw default deny incoming
sudo ufw default allow outgoing

# اسمح بمنفذ SSH — إن كنت على المنفذ الافتراضي:
sudo ufw allow OpenSSH

# إن غيّرت منفذ SSH إلى 2222، اسمح به صراحةً بدلًا من السطر السابق:
sudo ufw allow 2222/tcp

# اسمح بحركة الويب (HTTP و HTTPS) إن كنت تستضيف موقعًا
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# فعّل الجدار (سيحذّرك أنه قد يقطع اتصالات SSH — تأكّد أنك سمحت بمنفذك أولًا)
sudo ufw enable

# تحقّق من الحالة والقواعد المفعّلة
sudo ufw status verbose

تحذير حاسم: قبل تنفيذ ufw enable، تأكّد 100% أنك سمحت بمنفذ SSH الصحيح (سواء OpenSSH أو 2222). لو فعّلت الجدار بسياسة deny دون السماح لمنفذ SSH، ستُقطع جلستك فورًا ولن تستطيع العودة إلا عبر وحدة التحكّم (console) في لوحة المزوّد.

جدول المنافذ الشائعة في UFW

لاحظ القاعدة الذهبية في الجدول: قواعد البيانات وredis لا يُفتح منفذها للعالم أبدًا. هذه الخدمات يجب أن تستمع على 127.0.0.1 فقط، فلا تحتاج قاعدة UFW لها أصلًا — سنغطّي ذلك في قسم تأمين الخدمات.

تقييد المنافذ بمصدر محدّد

لمزيد من التحصين، يمكنك قصر منفذ SSH على عنوان IP الخاص بك فقط (إن كان لديك IP ثابت):

# اسمح بـSSH فقط من عنوان IP محدّد (استبدله بعنوانك)
sudo ufw allow from 198.51.100.25 to any port 2222 proto tcp

# لحذف قاعدة قديمة بالرقم: اعرض القواعد المرقّمة ثم احذف
sudo ufw status numbered
sudo ufw delete 3

الطبقة الخامسة: Fail2ban ضدّ هجمات التخمين

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

# ثبّت Fail2ban
sudo apt update && sudo apt install -y fail2ban

# لا تعدّل jail.conf مباشرة — أنشئ jail.local ليبقى عند التحديثات
sudo nano /etc/fail2ban/jail.local

ضع المحتوى التالي في jail.local. هذا يضبط القواعد العامّة ثم يفعّل حماية SSH (لاحظ مطابقة المنفذ لمنفذك المخصّص):

[DEFAULT]
# مدّة الحظر (بالثواني) — هنا ساعة
bantime  = 3600
# نافذة احتساب المحاولات (بالثواني) — 10 دقائق
findtime = 600
# عدد المحاولات الفاشلة قبل الحظر
maxretry = 3
# لا تحظر عناوينك الموثوقة (أضف IP جهازك وlocalhost)
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[sshd]
enabled = true
port    = 2222
# على Ubuntu الحديث يقرأ من systemd journal
backend = systemd
maxretry = 3
bantime  = 3600

شغّل الخدمة وتحقّق من حالتها:

# فعّل وشغّل Fail2ban عند الإقلاع
sudo systemctl enable --now fail2ban

# تحقّق من حالة الخدمة العامّة
sudo fail2ban-client status

# تحقّق من حالة حماية sshd تحديدًا (المحظورون، عدد المحاولات)
sudo fail2ban-client status sshd

جدول أوامر Fail2ban المفيدة

نصيحة مهمّة: أضف عنوان IP جهازك إلى ignoreip لتتجنّب حظر نفسك بالخطأ إن أخطأت في الدخول عدّة مرّات. إن قفلت نفسك فعلًا، فستحتاج للدخول عبر console المزوّد ورفع الحظر بـunbanip.

الطبقة السادسة: التحديثات الأمنية التلقائية

أكبر مصدر لاختراق الخوادم هو الثغرات المعروفة وغير المرقّعة. عندما تُكتشف ثغرة في حزمة، يصدر التصحيح بسرعة — لكن إن لم تثبّته، تبقى مكشوفًا. الحل: التحديثات الأمنية التلقائية عبر حزمة unattended-upgrades، التي تثبّت التصحيحات الأمنية دون تدخّل يدوي.

# ثبّت الأداة وحزمة ضبط الأولويات
sudo apt update
sudo apt install -y unattended-upgrades apt-listchanges

# فعّل التحديثات التلقائية (سيسألك اختر Yes)
sudo dpkg-reconfigure -plow unattended-upgrades

# اضبط التفاصيل في ملف الإعداد
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

في ملف 50unattended-upgrades، تأكّد أن مصدر التحديثات الأمنية مفعّل، وفعّل الإزالة التلقائية للحزم غير المستخدمة وإعادة التشغيل عند الحاجة (في وقت هادئ):

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// أزل الاعتماديات غير المستخدمة تلقائيًا
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// أعد التشغيل تلقائيًا إن لزم تحديث النواة — في وقت هادئ
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

فعّل الجدولة الدورية في ملف 20auto-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

اختبر أن كل شيء يعمل دون تطبيق فعلي:

# تشغيل تجريبي (dry-run) يبيّن ما سيُحدَّث دون تثبيت
sudo unattended-upgrade --dry-run --debug

جدول خيارات التحديث التلقائي

نصيحة: قصر التحديثات التلقائية على التصحيحات الأمنية فقط، واترك ترقيات الميزات الكبرى لتطبّقها يدويًا بعد اختبار، لتجنّب أن يكسر تحديثٌ تطبيقَك دون رقابة.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

الطبقة السابعة: تقليل سطح الهجوم

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

اكتشاف ما يستمع على الشبكة

أولًا، اعرف ما الذي يستمع على المنافذ فعلًا:

# اعرض كل المنافذ المستمعة مع البرامج المرتبطة (الأداة الحديثة ss)
sudo ss -tulpn

# بديل قديم لمن يفضّل netstat
# sudo netstat -tulpn

# لفحص المنافذ من الخارج (من جهاز آخر) باستخدام nmap
nmap -sV 203.0.113.10

ابحث في المخرجات عن أي خدمة تستمع على 0.0.0.0 (كل الواجهات) لا تتعرّف عليها أو لا تحتاجها. كل سطر هو منفذ مكشوف يجب أن تبرّره أو تغلقه.

إيقاف وإزالة الخدمات غير اللازمة

# اعرض كل الخدمات المفعّلة عند الإقلاع
sudo systemctl list-unit-files --type=service --state=enabled

# أوقف خدمة وامنعها من الإقلاع (مثال: خدمة لا تحتاجها)
sudo systemctl disable --now avahi-daemon

# أزل حزمة غير لازمة تمامًا (مثال شائع: خادم بريد افتراضي)
sudo apt purge -y exim4 exim4-base
sudo apt autoremove -y

أمثلة على خدمات يكثر وجودها دون حاجة: avahi-daemon (اكتشاف الشبكة المحلّية)، cups (الطباعة)، rpcbind، وخوادم بريد افتراضية مثل exim4 على خادم لا يرسل بريدًا. تحقّق من كل خدمة قبل إيقافها.

تأمين الخدمات: اجعلها تستمع محليًا

أخطر إعداد خاطئ هو ترك قاعدة بيانات تستمع على كل الواجهات (0.0.0.0) فتصبح مكشوفة للإنترنت. الصواب أن تستمع على 127.0.0.1 فقط، فيصلها تطبيقك المحلّي ولا يصلها أحد من الخارج.

# MySQL/MariaDB: في /etc/mysql/mariadb.conf.d/50-server.cnf تأكّد من:
# bind-address = 127.0.0.1

# PostgreSQL: في postgresql.conf تأكّد من:
# listen_addresses = 'localhost'

# Redis: في /etc/redis/redis.conf تأكّد من:
# bind 127.0.0.1 ::1
# protected-mode yes

# بعد التعديل أعد تشغيل الخدمة وتحقّق أنها لم تعد على 0.0.0.0
sudo systemctl restart mariadb
sudo ss -tulpn | grep 3306

أمّا خادم الويب Nginx فيجب تحصينه بإخفاء نسخته ومنع تنفيذ سكربتات في مجلّدات الرفع وإضافة رؤوس أمان:

# في /etc/nginx/nginx.conf داخل http {} أخفِ نسخة Nginx
# server_tokens off;

# اختبر صحّة الإعداد ثم أعد التحميل
sudo nginx -t && sudo systemctl reload nginx

لتعميق الجانب الخاص بـNginx ورؤوس الأمان (CSP, HSTS, X-Frame-Options)، راجع دليل رؤوس HTTP الأمنية الذي يشرح كل رأس وكيف تضبطه.

صلاحيات الملفات الحسّاسة

الصلاحيات الخاطئة على ملفات حسّاسة تتيح قراءتها أو تعديلها من مستخدمين لا يجب أن يصلوا إليها. اضبطها بدقّة:

# مجلّد SSH للمستخدم: 700 (المالك فقط)
chmod 700 ~/.ssh

# ملف المفاتيح المصرّح بها: 600
chmod 600 ~/.ssh/authorized_keys

# المفتاح الخاص (إن وُجد على الخادم): 600
chmod 600 ~/.ssh/id_ed25519

# ملف إعداد SSH العام مملوك لـroot بصلاحية 644
sudo chown root:root /etc/ssh/sshd_config
sudo chmod 644 /etc/ssh/sshd_config

# ملفات الإعداد الحاوية لكلمات مرور (مثل wp-config.php): 640، مملوكة لمستخدم الويب
sudo chown www-data:www-data /var/www/html/wp-config.php
sudo chmod 640 /var/www/html/wp-config.php

جدول صلاحيات الملفات الحسّاسة

الطبقة الثامنة: السجلّات والمراقبة والتنبيهات

التحصين لا يكتمل دون رؤية: القدرة على معرفة ما يجري على خادمك واكتشاف الشذوذ مبكرًا. الاختراق الأسوأ هو الصامت الذي لا تنتبه له لأشهر. السجلّات هي عينك على الخادم.

# مراقبة محاولات الدخول الفاشلة والناجحة (Ubuntu/Debian)
sudo journalctl -u ssh --since "today"
# أو الملف المباشر على بعض الأنظمة:
sudo tail -f /var/log/auth.log

# آخر عمليات الدخول الناجحة
last -a | head -20

# محاولات الدخول الفاشلة
sudo lastb | head -20

# مراقبة استهلاك الموارد لحظيًا (للكشف عن تعدين خفي)
top
# أو الأفضل
htop

جدول مؤشّرات المراقبة

للمراقبة المتقدّمة، فكّر في تركيب أداة فحص سلامة الملفات مثل AIDE التي تأخذ "بصمة" لملفات النظام وتنبّهك عند أي تعديل غير متوقّع، وأداة فحص الجذور الخفية مثل rkhunter:

# فحص الجذور الخفية (rootkits) دوريًا
sudo apt install -y rkhunter
sudo rkhunter --update
sudo rkhunter --check --skip-keypress

الطبقة التاسعة: النسخ الاحتياطي الخارجي

كل التحصين السابق يقلّل احتمال الكارثة، لكن لا يلغيها. النسخ الاحتياطي هو شبكة الأمان الأخيرة: إن اخترِق الخادم أو شُفّرت بياناته بفدية (ransomware) أو حدث عطب عتاد، فالنسخة الاحتياطية الخارجية هي ما يعيدك للحياة. القاعدة الذهبية هي 3-2-1: ثلاث نسخ من البيانات، على وسيطين مختلفين، واحدة منها خارج الموقع (off-site).

الأهمّ: النسخة يجب أن تكون خارج الخادم نفسه. نسخة على نفس القرص لا تنفعك إن اختُرق الخادم أو تعطّل العتاد. أرسلها إلى تخزين كائني (مثل Cloudflare R2 أو S3) أو خادم آخر:

# مثال: أرشفة قاعدة بيانات وملفات الموقع ثم رفعها لتخزين خارجي
# 1) نسخة قاعدة البيانات
mysqldump -u root -p --all-databases | gzip > /tmp/db-$(date +%F).sql.gz

# 2) أرشفة ملفات الموقع
tar czf /tmp/www-$(date +%F).tar.gz /var/www

# 3) مزامنة آمنة إلى خادم/تخزين خارجي عبر rsync فوق SSH
rsync -avz -e "ssh -p 2222" /tmp/db-*.sql.gz /tmp/www-*.tar.gz \
  backup@backup-server:/backups/

# 4) جدولة النسخ يوميًا عبر cron
crontab -e
# أضف السطر التالي للتشغيل يوميًا الساعة 3 فجرًا:
# 0 3 * * * /home/deploy/scripts/backup.sh

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

جدول طبقات النسخ الاحتياطي

2FA لـSSH (طبقة إضافية)

لمستوى أمان أعلى، يمكنك إضافة المصادقة الثنائية (2FA) إلى SSH عبر Google Authenticator، بحيث يُطلب — إضافة إلى المفتاح — رمز زمني (TOTP) من تطبيق على هاتفك. هذا يجمع بين "شيء تملكه" (المفتاح) و"شيء تملكه أيضًا" (الهاتف) في طبقة مستقلّة:

# تثبيت وحدة PAM لـTOTP
sudo apt install -y libpam-google-authenticator

# تشغيل الإعداد لكل مستخدم (يولّد رمز QR ومفاتيح طوارئ)
google-authenticator

يتطلّب التفعيل تعديل /etc/pam.d/sshd وضبط AuthenticationMethods publickey,keyboard-interactive في sshd_config. كن حذرًا واختبر في جلسة جديدة دائمًا قبل إغلاق الحالية، فهذه الخطوة دقيقة وقد تقفلك خارجًا إن أُسيء ضبطها.

نصائح خبير لما بعد التحصين الأساسي

• راجع سجلّاتك أسبوعيًا: خصّص 10 دقائق لمراجعة lastb وauth.log. الأنماط الشاذّة تظهر مبكرًا لمن ينظر.
• استخدم مدير كلمات مرور لعبارات مرور المفاتيح وحسابات الخدمات. لا تكرّر أبدًا.
• افصل البيئات: لا تشارك خادمًا واحدًا بين الإنتاج والتجربة. اختراق التجربة يجب ألّا يطال الإنتاج.
• مبدأ أقلّ امتياز للتطبيقات: شغّل كل تطبيق بمستخدم خدمة مخصّص محدود الصلاحية، لا بـroot ولا بمستخدمك الإداري.
• وثّق إعداداتك: احتفظ بسجلّ (خارج الخادم) لما غيّرته ولماذا، ليسهل التعافي وإعادة البناء.
• فعّل تنبيهات تلقائية: اضبط إشعارًا بالبريد عند كل دخول SSH ناجح، لتعرف فورًا بأي دخول غير متوقّع.
• حصّن لوحة التحكّم إن وُجدت: إن كنت تشغّل cPanel أو لوحة أخرى، فلها سطح هجوم خاص — راجع تأمين لوحة cPanel.
• حدّث بانتظام يدويًا أيضًا: التحديثات التلقائية تغطّي الأمني، لكن راجع شهريًا الترقيات الكبرى يدويًا بعد نسخة احتياطية.

استكشاف الأخطاء وإصلاحها (Troubleshooting)

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

إن قفلت نفسك خارج SSH تمامًا

أهمّ شبكة أمان لديك هي وحدة التحكّم (Console/VNC) في لوحة المزوّد. كل مزوّدي VPS الجادّين يوفّرون وصولًا للخادم عبر المتصفّح لا يمرّ بـSSH ولا بجدار الحماية إطلاقًا. عبرها تستطيع الدخول كـroot (أو بكلمة مرور المستخدم) وتصحيح أي خطأ في sshd_config أو UFW أو Fail2ban. لهذا السبب نكرّر طوال الدليل: لا تغلق جلستك القديمة قبل التأكّد من الجديدة، واعرف كيف تصل إلى console مزوّدك قبل أن تحتاجها.

الأسئلة الشائعة

هل تغيير منفذ SSH يحصّن الخادم فعلًا؟ تغيير المنفذ يقلّل بشكل كبير ضوضاء المسح الآلي الذي يستهدف المنفذ 22 الشهير، فيخفّ ازدحام سجلّاتك ومحاولات التخمين العشوائية. لكنه أمن بالغموض (security by obscurity) وليس حماية حقيقية بمفرده — ماسح منافذ مثل nmap يكشف منفذك خلال ثوانٍ. اعتبره تحسينًا تكميليًا لطيفًا فوق الأساس الحقيقي: مفاتيح SSH وتعطيل كلمة المرور والجدار وFail2ban.

هل أحتاج كل هذه الطبقات لمشروع صغير؟ نعم، الأساسيات على الأقلّ. مفاتيح SSH وتعطيل root وكلمة المرور وUFW والتحديثات التلقائية ليست "تحصينًا متقدّمًا"، بل الحدّ الأدنى لأي خادم على الإنترنت مهما صغر مشروعك. الروبوتات لا تفرّق بين موقع كبير وصغير — تهاجم أي IP مكشوف. الطبقات الأكثر تقدّمًا (2FA، AIDE) تضيفها حسب حساسية مشروعك.

ما الفرق بين تعطيل root وحذفه؟ نحن نعطّل دخول root عبر SSH (PermitRootLogin no)، لا نحذف الحساب. حساب root يبقى موجودًا وضروريًا للنظام، لكنك لم تعد تدخل به مباشرة من الإنترنت؛ بدلًا من ذلك تدخل كمستخدم عادي وترفع الصلاحية بـsudo. حذف root نفسه فكرة سيّئة قد تكسر النظام.

هل Fail2ban بديل عن مفاتيح SSH؟ لا، هما طبقتان مختلفتان ومكمّلتان. مفاتيح SSH تمنع التخمين أصلًا (لا توجد كلمة مرور تُخمَّن). Fail2ban يحمي من إغراق الخادم بمحاولات الاتصال ويصدّ هجمات على خدمات أخرى أيضًا. الأمن الحقيقي يجمعهما معًا ضمن الدفاع في العمق، لا أن يستبدل أحدهما الآخر.

لماذا يجب أن تستمع قاعدة البيانات على localhost فقط؟ لأن تطبيق الويب على نفس الخادم يصل قاعدة البيانات عبر 127.0.0.1 دون حاجة لكشفها للإنترنت. ترك قاعدة البيانات تستمع على 0.0.0.0 يجعلها هدفًا مباشرًا لهجمات التخمين والثغرات من أي مكان في العالم. الاستماع المحلّي يلغي هذا السطح بالكامل دون أن يؤثّر على عمل تطبيقك.

كم مرّة يجب أن أحدّث الخادم؟ التصحيحات الأمنية يجب أن تُثبَّت تلقائيًا يوميًا عبر unattended-upgrades — هذا غير قابل للتأجيل. أمّا الترقيات الكبرى (نسخ النظام، تحديثات الميزات) فطبّقها يدويًا شهريًا أو حسب الحاجة، دائمًا بعد أخذ نسخة احتياطية واختبار، لتجنّب أن يكسر تحديثٌ كبيرٌ تطبيقَك دون رقابة.

هل التحديثات التلقائية قد تكسر موقعي؟ احتمال ضئيل إن قصرتها على المصدر الأمني (-security) فقط كما في إعدادنا، لأن التصحيحات الأمنية مصمّمة لتكون متوافقة رجعيًا قدر الإمكان. الخطر يأتي من ترقيات الميزات الكبرى — ولهذا نتركها للتطبيق اليدوي. كإجراء احترازي، اجعل النسخ الاحتياطي يوميًا حتى تستطيع التراجع إن حدث ما لم يكن في الحسبان.

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

هل أحتاج جدار حماية إن كان لدى مزوّدي جدار سحابي (Cloud Firewall)؟ نعم، استخدم كليهما — هذا دفاع في عمق. الجدار السحابي يصفّي الحركة قبل وصولها للخادم، وUFW يصفّي على مستوى النظام نفسه كطبقة ثانية. لو أُعِدّ الجدار السحابي خطأً أو عُطّل، يبقى UFW حارسك. الاعتماد على طبقة واحدة فقط يخالف مبدأ الدفاع في العمق كلّه.

هل المصادقة الثنائية (2FA) لـSSH ضرورية؟ ليست ضرورية لمعظم الحالات إن كنت تستخدم مفاتيح SSH بعبارة مرور قوية، لأن المفتاح وحده مناعته عالية جدًا أمام التخمين. لكنها قيّمة للخوادم بالغة الحساسية أو حين يصلها عدّة أشخاص، إذ تضيف عاملًا مستقلًّا (هاتفك) فلا يكفي امتلاك المفتاح وحده. وازِن بين الأمان الإضافي وتعقيد الإعداد حسب حساسية خادمك.

هل يكفي كل هذا أم يبقى تحصين أكثر؟ هذا الدليل يغطّي التحصين الأساسي القوي الذي يصدّ الغالبية الساحقة من الهجمات الآلية. للبيئات الأعلى حساسية تُضاف طبقات مثل أنظمة كشف التسلّل (IDS)، تجزئة الشبكة، تدقيق auditd، تقوية النواة (sysctl, kernel hardening)، وحاويات معزولة. لكن إن طبّقت قائمة التحقّق هنا كاملة، فأنت متقدّم على الأغلبية الساحقة من الخوادم المكشوفة على الإنترنت.

الخلاصة وقائمة التحقّق النهائية

تحصين VPS ليس مهمّة تُنجزها مرّة وتنساها، بل ممارسة مستمرّة من الدفاع في العمق: طبقات متتالية كلٌّ منها تصدّ ما تجاوز سابقتها. ابدأ بالأساس غير القابل للتفاوض — مفاتيح SSH وتعطيل root وكلمة المرور وجدار UFW والتحديثات التلقائية — ثم أضف Fail2ban وتقليل سطح الهجوم والمراقبة والنسخ الاحتياطي. ولا تنسَ القاعدة الذهبية في كل خطوة حسّاسة: جلسة جديدة للاختبار قبل إغلاق القديمة، ومعرفة طريق console المزوّد قبل أن تحتاجه.

راجع هذه القائمة قبل أن تعتبر خادمك محصّنًا:

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

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS