أمان خادم VPS من الصفر: مفاتيح SSH وجدار الحماية وFail2ban

لا يمكن اعتبار خادم VPS جديدًا آمنًا فور تثبيت Ubuntu. فقبل إعداد الوصول، يكون الخادم ظاهرًا بالفعل لأدوات الفحص؛ إذ تحاول تخمين كلمات مرور SSH، وتبحث عن لوحات تحكم مكشوفة، وتتحقق من الثغرات الشائعة. في هذا الدليل سنغطي الخطوات الأساسية لتأمين خادم VPS من الصفر: إنشاء مستخدم منفصل، وإعداد المصادقة باستخدام مفتاح SSH، وتقييد منافذ الشبكة عبر UFW، وإضافة Fail2ban. تصلح جميع الخطوات لـ Ubuntu 22.04 و24.04 عند تنفيذ الأوامر بواسطة مستخدم يملك صلاحيات sudo.

قبل البدء: أعد قائمة بالمنافذ

لا تفتح المنافذ «احتياطًا». يحتاج خادم الويب المعتاد إلى ما يلي:

• 22/tcp — SSH؛ ومن الأفضل تقييده حسب عنوان IP أو نقله إلى منفذ آخر كإجراء إضافي فقط؛
• 80/tcp — HTTP؛ ويُستخدم عادةً لإعادة التوجيه إلى HTTPS والتحقق من الشهادة؛
• 443/tcp — HTTPS.

يجب ألا يكون منفذ تطبيق مثل 3000 أو 8080 أو 9000 متاحًا من الإنترنت إذا كان Nginx أو Caddy يعمل أمام التطبيق. اربط التطبيق بالعنوان 127.0.0.1 أو اسمح بالوصول إلى منفذه من الشبكة الداخلية فقط. اكتشف أولًا المنافذ التي تستمع على الخادم:

sudo ss -tulpn

بعد تثبيت Docker، افحص قواعد iptables الخاصة به بشكل منفصل؛ فتعريف النشر -p 3000:3000 يمكن أن يعرّض منفذًا خارج الإعداد المتوقع. بالنسبة إلى الخدمة العامة، من الأكثر أمانًا استخدام وكيل HTTPS وإبقاء المنفذ الداخلي مخفيًا.

الخطوة 1. حدّث النظام وأنشئ مستخدمًا إداريًا

اتصل بخادم VPS باستخدام بيانات الاعتماد التي حصلت عليها وثبّت التحديثات:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

أنشئ مستخدمًا شخصيًا. استبدل alex باسمك:

sudo adduser alex
sudo usermod -aG sudo alex

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

الخطوة 2. أنشئ مفتاح SSH وثبّته على الخادم

على جهاز Linux أو macOS أو Windows PowerShell، نفّذ:

ssh-keygen -t ed25519 -C "alex@my-computer"

اضغط Enter لحفظ المفتاح في الملف الافتراضي، ثم عيّن عبارة مرور. لا ترسل المفتاح الخاص في محادثة، ولا تضعه في مستودع، ولا تنسخه إلى خادم VPS. يجب نقل الملف ذي الامتداد .pub فقط إلى الخادم:

ssh-copy-id alex@SERVER_IP

إذا لم يكن ssh-copy-id متاحًا، اعرض المفتاح العام باستخدام Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub في PowerShell، ثم أضفه إلى الخادم:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

ألصق المفتاح في سطر واحد واختبر تسجيل الدخول قبل تعطيل كلمات المرور:

ssh alex@SERVER_IP
sudo whoami

يجب أن تكون نتيجة الأمر الأخير root. إذا لم يتمكن عميل SSH من العثور على المفتاح، حدده صراحةً: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP.

الخطوة 3. عطّل تسجيل دخول root والمصادقة بكلمة المرور

أنشئ نسخة احتياطية من إعدادات SSH:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

تأكد من أن الملف يحتوي على هذه المعلمات:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

في Ubuntu، قد تكون الإعدادات موجودة في /etc/ssh/sshd_config.d/*.conf، لذلك تحقّق من الإعداد الفعّال:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

إذا أبلغ sshd -t عن خطأ، فلا تعِد تشغيل الخدمة قبل إصلاح الصياغة. بعد نجاح الفحص، طبّق الإعدادات:

sudo systemctl reload ssh

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

الخطوة 4. اضبط UFW من دون حظر SSH

UFW غلاف مريح لقواعد الشبكة في Linux. عيّن الإعدادات الافتراضية الآمنة أولًا، ثم اسمح بمنافذ SSH والويب:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

لا تؤكد التفعيل إلا بعد إضافة قاعدة SSH. راجع النتيجة:

sudo ufw status verbose
sudo ufw status numbered

بالنسبة إلى عنوان IP مكتبي ثابت، يمكنك تقييد SSH على ذلك العنوان:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

استخدم هذا الخيار فقط مع عنوان IP ثابت وإمكانية الوصول إلى وحدة تحكم مزود الخدمة؛ فإذا تغيّر العنوان قد تمنع نفسك من الوصول.

كيفية فتح منفذ تطبيق مؤقتًا

إذا احتجت إلى فحص خدمة مباشرة، أنشئ قاعدة بمصدر مقيّد:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

بعد الاختبار، احذفها باستخدام الرقم الظاهر في ufw status numbered:

sudo ufw delete RULE_NUMBER

لا تستخدم sudo ufw allow 1:65535/tcp؛ فهذه القاعدة تجعل جدار الحماية إجراءً شكليًا.

الخطوة 5. فعّل Fail2ban لـ SSH

يحلل Fail2ban السجلات ويضيف قاعدة حظر مؤقتة بعد عدة محاولات تسجيل دخول فاشلة. وهو لا يحل محل مفاتيح SSH أو جدار الحماية، لكنه يقلل الضجيج الناتج عن محاولات التخمين الآلية.

أنشئ إعدادًا محليًا حتى لا تستبدل تحديثات الحزم إعداداتك:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

عيّن قيمًا مناسبة في قسم [DEFAULT]:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

شغّل الخدمة وافحص jail:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

في مخرجات sshd، تحقّق من عدد المحاولات الفاشلة والعناوين المحظورة. لا تضف عنوان IP الخاص بك إلى قائمة الحظر. ولإنشاء استثناء دائم، استخدم ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP في [DEFAULT].

الخطوة 6. فعّل التحديثات التلقائية

التحديثات التلقائية مفيدة لحزم الأمان، لكن إعادة تشغيل الخادم بعد تحديث النواة تحتاج إلى إدارة يدوية:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

مرة كل أسبوع، تحقّق مما إذا كانت إعادة التشغيل مطلوبة:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

قبل إعادة التشغيل يدويًا، تأكد من وجود مفتاح يعمل ومن إمكانية الوصول إلى وحدة تحكم VPS. بعد إعادة التشغيل، افحص خدمات التطبيق وNginx وUFW وFail2ban.

الخطوة 7. افحص النتيجة من الخارج

اختبر الحماية من جهاز آخر، ولا تكتفِ بقراءة الإعدادات:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

يجب أن ينتهي الأمر بالرفض. اختبر تسجيل الدخول العامل باستخدام المفتاح بشكل منفصل:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

على خادم VPS، افحص عناوين الاستماع والقواعد:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

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

النسخ الاحتياطية والاسترداد

لا تحمي إجراءات SSH من حذف البيانات، أو خطأ المسؤول، أو اختراق التطبيق. خزّن نسخًا من قاعدة البيانات والإعدادات وملفات المستخدمين في مكان منفصل عن خادم VPS. الحد الأدنى المناسب هو نسخة احتياطية يومية، وعدة إصدارات من الأيام السابقة، واختبارات دورية للاسترداد.

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

كيفية اختيار VPS لمشروع آمن

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

عند إطلاق مشروع على VPS لدى tropic.host، حدّد نقاط الدخول العامة مسبقًا؛ ففي معظم الحالات تكفي SSH وHTTP وHTTPS. أبقِ قاعدة البيانات ولوحات التحكم داخل الشبكة الداخلية. ومع نمو المشروع، تساعد خوادم VPS منفصلة للتطبيق وقاعدة البيانات والمراقبة على عزل نطاقات الأعطال.

أخطاء شائعة

• تعطيل كلمات المرور قبل اختبار تسجيل الدخول باستخدام المفتاح. أبقِ الجلسة الحالية مفتوحة واختبر تسجيل دخول جديدًا بشكل منفصل.
• ترك 22/tcp مفتوحًا للعالم كله مع إمكانية السماح به للعناوين الموثوقة فقط.
• نشر منافذ Docker مباشرةً. افحص قواعد Docker وUFW أولًا.
• تثبيت Fail2ban وعدم فحص السجلات بعد ذلك. راجع journalctl -u ssh وحالة jail بعد التغييرات.

الخلاصة

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

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

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

هل أحتاج إلى تغيير منفذ SSH الافتراضي؟

ليس بالضرورة. يقلل نقل المنفذ الضجيج الآلي، لكنه لا يحل محل المفاتيح أو تعطيل كلمات المرور أو UFW أو Fail2ban. إذا غيّرت المنفذ، فحدّث قاعدة جدار الحماية ومعلمة port في jail الخاص بـ Fail2ban.

ماذا أفعل إذا فقدت الوصول بعد إعداد UFW؟

استخدم وحدة تحكم الويب أو وحدة الإنقاذ لدى مزود الخدمة، ثم افحص قاعدة SSH وإعدادات sshd. لا تغلق الجلسة القديمة العاملة قبل تأكيد تسجيل الدخول الجديد.

هل يكفي Fail2ban لحماية SSH؟

لا. يتفاعل Fail2ban مع محاولات تسجيل الدخول الفاشلة بعد حدوثها. يجب أن تكون الأساسيات هي مفاتيح SSH، وتعطيل مصادقة كلمات المرور، وتقليل صلاحيات المستخدم، وتقييد جدار الحماية.

هل يمكنني السماح بـ SSH من عنوان IP واحد فقط؟

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

كم مرة يجب أن أتحقق من أمان VPS؟

بعد كل تغيير في SSH أو جدار الحماية أو نشر منافذ Docker، أجرِ فحصًا للمنافذ واختبر تسجيل الدخول. وكصيانة دورية، راجع التحديثات والسجلات مرة واحدة أسبوعيًا على الأقل، واختبر استرداد النسخ الاحتياطية بانتظام.