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

⚡ الإجابة المختصرة

لتأمين خادم VPS، طبّق هذه الأساسيات بالترتيب: (1) حدّث النظام، (2) اعمل بمستخدم non-root، (3) استخدم مفاتيح SSH وعطّل الدخول بكلمة المرور، (4) عطّل دخول root، (5) غيّر منفذ SSH من 22، (6) فعّل جدارًا ناريًا (UFW) يفتح أقل المنافذ، (7) ثبّت Fail2ban لحظر التخمين، ثمّ راقب السجلّات واحتفظ بنسخ احتياطية مشفّرة. أهمّها مفاتيح SSH وتغيير المنفذ وFail2ban — فهي تُنهي معظم الهجمات الآلية.

تأمين VPS في 10 خطوات: SSH ومفاتيح وFail2ban وجدار ناري UFWعشر خطوات دفاع متعدّد الطبقات — كل خطوة تُغلق بابًا يستغلّه المهاجمون

لماذا يُهاجَم خادمك من اللحظة الأولى؟

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

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

الخطوات 1-2: التحديث ومستخدم non-root

1. حدّث النظام وفعّل التحديثات الأمنية التلقائية

الثغرات المعروفة هي بوّابة المهاجمين الأولى. حدّث نظامك فورًا، وفعّل التحديثات الأمنية التلقائية لتُسدّ الثغرات فور صدور تصحيحها:

sudo apt update && sudo apt upgrade -y
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades   # فعّل التحديثات الأمنية التلقائية

2. أنشئ مستخدمًا non-root بصلاحيات sudo

العمل الدائم بحساب root خطر: أي خطأ أو اختراق يمنح تحكّمًا كاملًا. أنشئ مستخدمًا عاديًّا وامنحه sudo، واعمل به دائمًا:

adduser deploy
usermod -aG sudo deploy
# ثمّ سجّل الدخول بـdeploy بدل root

الخطوات 3-5: تحصين SSH (المفاتيح والمنفذ)

SSH هو بابك الرئيسي — وتحصينه أهمّ خطوة في VPS Security. ثلاثة تعديلات تحوّله من باب مكشوف إلى حصن:

تقوية SSH قبل وبعد: منفذ مخصّص وتعطيل root وكلمة المرور واعتماد المفاتيحثلاثة أسطر في sshd_config تُنهي معظم هجمات التخمين الآلي

3. استخدم مفاتيح SSH وعطّل كلمة المرور

المفتاح المشفّر لا يمكن تخمينه مثل كلمة المرور. أنشئ زوج مفاتيح على جهازك وانسخ العامّ إلى الخادم:

# على جهازك
ssh-keygen -t ed25519 -C "your@email"
ssh-copy-id -p 22 deploy@YOUR_SERVER_IP
# ثمّ في /etc/ssh/sshd_config على الخادم:
PasswordAuthentication no

4. عطّل دخول root المباشر

root هو الهدف الأول لكل مهاجم. امنع الدخول به مباشرةً عبر SSH:

# /etc/ssh/sshd_config
PermitRootLogin no

5. غيّر منفذ SSH من 22

معظم الهجمات الآلية تستهدف المنفذ 22 حصرًا. نقله إلى منفذ مخصّص لا يوقف مهاجمًا محدّدًا، لكنه يُخفي بابك عن آلاف الماسحات الآلية — وكما سنُثبت بالأرقام، هذا وحده يقلّص المحاولات إلى الصفر تقريبًا:

# /etc/ssh/sshd_config
Port 49222   # أي منفذ عالٍ غير مستخدم
sudo systemctl restart ssh

⚠ تحذير: قبل إعادة تشغيل SSH بعد أي تعديل، افتح جلسة جديدة للتأكّد أنها تعمل قبل إغلاق الحالية — وإلا قد تُقفَل خارج خادمك. وافتح المنفذ الجديد في الجدار الناري أولًا.

الخطوة 6: الجدار الناري UFW

الجدار الناري يطبّق مبدأ «أقل ما يلزم»: أغلق كل المنافذ إلا ما تحتاجه فعلًا (SSH، وويب 80/443). UFW يجعل هذا سهلًا:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 49222/tcp   # منفذ SSH الجديد
sudo ufw allow 80,443/tcp  # الويب
sudo ufw enable

💡 نصيحة: افتح منفذ SSH الجديد في UFW قبل تفعيل الجدار الناري، وإلا ستُقفَل خارج الخادم. راجع دليل إعداد Firewall في Linux للتفصيل.

الخطوة 7: Fail2ban ضد التخمين

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

sudo apt install -y fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# في jail.local فعّل قسم [sshd]:
# enabled = true
# maxretry = 3
# bantime = 1h
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd   # راقب المحجوبين

كما سنُثبت في القسم التالي، حجب Fail2ban ليس نظريًّا — اختبرناه فعليًّا على خادم مرام فحجب المصدر المخالف خلال ثوانٍ.

الخطوات 8-10: التقوية والمراقبة والنسخ

8. قوِّ إعدادات SSH الإضافية

أضِف طبقات تقييد إضافية في sshd_config: قلّل محاولات المصادقة، واضبط مهلة الخمول، وعطّل ما لا تحتاجه:

# /etc/ssh/sshd_config
MaxAuthTries 3
ClientAliveInterval 300
X11Forwarding no
AllowUsers deploy   # اسمح لمستخدمين محدّدين فقط

9. راقب السجلّات وفعّل التنبيهات

الكشف المبكر يحدّ من الضرر. راقب سجلّات المصادقة (/var/log/auth.log)، واستخدم أدوات مثل logwatch أو auditd لتلقّي ملخّصات ونشاطات مشبوهة. راجع أهمّية ذلك في التوافر العالي وسيناريوهات التعافي.

10. نسخ احتياطي مشفّر خارج الخادم

رغم كل التحصين، لا أمان مطلقًا. النسخ الاحتياطي المشفّر خارج الخادم هو خطّ دفاعك الأخير ضد الفدية والفشل الكارثي — طبّق قاعدة 3-2-1 (ثلاث نسخ، وسيطان، نسخة خارجية). راجع تصميم خطة تعافٍ من الكوارث.

إثبات VPS Security حقيقي من خادم مرام

النظرية سهلة، لكن ما أثر هذه الخطوات فعليًّا؟ قِسنا ذلك على أحد خوادم مرام الحيّة:

إثبات VPS Security حقيقي: منفذ SSH مخصّص يلغي brute-force وFail2ban يحجب فعليًّابيانات مقاسة من سجلّ خادم حيّ: المنفذ المخصّص + Fail2ban يعملان
  • أثر تغيير المنفذ: خادمنا يشغّل SSH على منفذ مخصّص (لا 22). فحص سجلّ المصادقة (29,462 سطرًا خلال نحو 30 يومًا) أظهر صفر محاولات brute-force عمليًّا — كلّها جلسات شرعية. بينما خادم على المنفذ 22 يتلقّى آلاف محاولات التخمين يوميًّا (حقيقة موثّقة عالميًّا).
  • Fail2ban يعمل فعليًّا: اختبرنا الحجب فأمرنا Fail2ban بحظر عنوان اختباري، فأظهرت الحالة فورًا Currently banned: 1 وTotal banned: 1 — أي أنه ثبّت قاعدة حظر خلال ثوانٍ — ثمّ رفعنا الحظر بعد الاختبار.

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

دور مزوّد الاستضافة في VPS Security

جزء من VPS Security خارج يدك ويقع على مزوّد الاستضافة: حماية الشبكة من هجمات DDoS، وعزل الخوادم عن بعضها، وأمان مركز البيانات المادي، وسرعة الاستجابة عند الحوادث. اختر مزوّدًا:

  • يوفّر حماية DDoS على مستوى الشبكة قبل أن تصل لخادمك.
  • يعزل خوادم العملاء (لا مشاركة موارد تسمح بتسريب بيانات).
  • يتيح لوحة تحكّم بجدار حماية وإدارة، ونسخًا احتياطيًّا موثوقًا.
  • يقدّم دعمًا سريعًا يفهم الأمان — خصوصًا عند حادث.

الأمان مسؤولية مشتركة: أنت تحصّن نظامك، والمزوّد يحصّن ما تحته. لمزيد عن اختيار خادم جيّد راجع 10 اختبارات تكشف overselling. وللمراجع الرسمية: توثيق OpenSSH وFail2ban وUFW ومعايير CIS للتحصين.

الخلاصة

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

تريد خادمًا آمنًا من الأساس؟ خوادم مرام تأتي بحماية شبكة وعزل موارد ودعم عربي يفهم الأمان — الأساس الذي تبني فوقه تحصينك، مع لوحة تحكّم ونسخ احتياطي موثوق.

احصل على VPS آمن مع مرام
نُشر هذا الشرح أصلاً في مدونة مرام هوست.
هل كانت المقالة مفيدة ؟ 0 أعضاء وجدوا هذه المقالة مفيدة (0 التصويتات)

Powered by WHMCompleteSolution