كيف تؤمّن VPS جديداً خلال أول 10 دقائق؟

أول 10 دقائق تحدد مدى أمان خادمك

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

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

الدقيقة 1: حدّث كل شيء

سجّل الدخول بحساب root باستخدام بيانات الاعتماد التي زوّدك بها مزوّد الخدمة، وحدّث النظام بالكامل قبل تنفيذ أي إجراء آخر:

apt update && apt upgrade -y

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

الدقيقة 2: أنشئ مستخدماً عادياً مع sudo

لا تواصل العمل باستخدام root. أنشئ مستخدماً خاصاً بك وامنحه صلاحية sudo:

adduser matt
usermod -aG sudo matt

من الآن فصاعداً، سجّل الدخول بهذا المستخدم واستخدم sudo لتنفيذ المهام الإدارية. يؤدي العمل باستخدام root طوال الوقت إلى جعل كل خطأ وكل اختراق يحدثان بصلاحيات غير محدودة، وهذا تحديداً ما صُمم العمل كمستخدم غير مميّز لمنعه.

الدقيقة 4: إعداد مفاتيح SSH

يمكن تخمين كلمات المرور، أما المفاتيح فلا. على حاسوبك المحمول، إذا لم يكن لديك مفتاح بالفعل، أنشئ واحداً:

ssh-keygen -t ed25519

ثم انسخ الجزء العام إلى الخادم:

ssh-copy-id matt@YOUR_SERVER

يتطلب ssh-copy-id تفعيل تسجيل الدخول باستخدام كلمة المرور للمستخدم الجديد. إذا كان هذا الخيار معطلاً بالفعل، فانسخ ~/.ssh/authorized_keys الخاص بـroot إلى /home/matt/.ssh/authorized_keys، على أن يكون مالك الملف matt، أو ألصق مفتاحك العام في ذلك الملف يدوياً.

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

سجّل الخروج ثم سجّل الدخول مرة أخرى بصفة matt باستخدام المفتاح، وتأكد من أنه يعمل قبل الانتقال إلى الخطوة التالية. إن تقييد SSH قبل التأكد من قدرتك على الدخول باستخدام مفتاح يؤدي إلى فقدان الوصول إلى الخادم. إذا ظهر عند تسجيل الدخول Permission denied (publickey)، فحل المشكلة الآن بدلاً من العودة إلى كلمة المرور، لأن هذه الرسالة الواحدة تغطي خمسة أعطال مختلفة، ويخبرك ناتج ssh -v بأيٍّ منها حدث فعلياً.

الدقيقة 6: عطّل تسجيل الدخول بحساب root وكلمات المرور

بعد التأكد من عمل مفتاحك، أغلق نقطتي الدخول اللتين تعتمد عليهما عمليات الفحص. استخدم ملف drop-in حتى لا تستبدله تحديثات الحزم. سمّه 00- حتى يُرتَّب قبل 50-cloud-init.conf، الذي تأتي به صور Ubuntu السحابية مع PasswordAuthentication yes؛ إذ يحتفظ sshd بأول قيمة يقرأها، ولذلك سيفقد ملف يُرتَّب لاحقاً تأثيره بصمت:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

ثم أعد تحميل SSH:

sudo systemctl restart ssh

ثم تحقّق من الإعدادات التي يستخدمها sshd فعلياً، حتى لا يخدعك ملف drop-in خاسر في ترتيب القراءة:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

بعد تعطيل كلمات المرور وإيقاف تسجيل الدخول بحساب root، لن تنجح حركة brute-force المستمرة ضد خادمك. يتضمن الدليل الكامل، بما في ذلك تغيير اختياري للمنفذ، تقوية أمان SSH على VPS.

الدقيقة 8: فعّل جدار الحماية

ارفض كل الاتصالات الواردة افتراضياً، ثم اسمح فقط بما تحتاج إليه. اسمح بـSSH قبل تفعيله، وإلا قطعت اتصالك بنفسك:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

أضف قواعد allow لكل خدمة تشغّلها فعلياً، مثل 80/tcp و443/tcp لموقع ويب. إذا توقفت جلسة SSH جديدة عن الاتصال بعد ذلك، اقرأ رسالة الخطأ قبل أن تغيّر أي شيء، لأن الرفض يعني أن sshd استجاب، بينما تعني مهلة الانتظار عادةً أن جدار الحماية أسقط الحزمة. تحقق من تغطية IPv4 وIPv6 معاً، لأن جدار الحماية الذي يرشّح IPv4 فقط يترك جانب IPv6 مفتوحاً بالكامل. راجع الشرح الكامل في أساسيات جدران الحماية على VPS. تفترض أوامر ufw هذه استخدام Ubuntu أو Debian. على خادم Rocky أو AlmaLinux يكون هدف الرفض الافتراضي نفسه، لكن الأداة هي firewalld، لذلك اتبع إصدار firewalld من هذه الخطوة بدلاً من ذلك.

الدقيقة 10: أبطئ عمليات الفحص باستخدام Fail2ban

أخيراً، أضف Fail2ban لطرد العناوين التي تهاجم منافذك باستمرار:

sudo apt install -y fail2ban

في Ubuntu 24.04، يحمي التثبيت الافتراضي SSH منذ أول إقلاع. وبما أن استخدام المفاتيح مطلوب مسبقاً، فإن هذه طبقة احتياطية تقلل ضوضاء السجلات وتحظر المخالفين المتكررين، وليست وسيلة دفاعك الرئيسية.

قائمة التحقق الخاصة بك

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

نفّذ الخطوات بالترتيب مرة واحدة لكل خادم جديد، وستصبح العملية تلقائية. توفر عشر دقائق الآن عليك فترة صعبة جداً بعد اختراق الخادم.

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

FAQ

ما أول شيء ينبغي أن أفعله على VPS جديد؟

حدّث النظام باستخدام apt update && apt upgrade -y، ثم أنشئ مستخدماً عادياً يمتلك صلاحيات sudo وتوقّف عن العمل باستخدام root. بعد ذلك، أعدد مفاتيح SSH، وعطّل تسجيل الدخول إلى root والمصادقة بكلمة المرور، وفعّل جداراً نارياً بسياسة الرفض الافتراضي، وثبّت Fail2ban. يضمن تنفيذ هذه الخطوات بهذا الترتيب أن تكون كل خطوة آمنة ولا تتسبب في فقدان إمكانية الوصول إلى الخادم.

كيف أتجنب فقدان الوصول أثناء تأمين SSH؟

أعدد تسجيل الدخول باستخدام مفتاح SSH واختبره قبل تعطيل كلمات المرور أو root. سجّل الخروج ثم سجّل الدخول مجدداً باستخدام المفتاح للتأكد من عمله، وبعدها فقط عطّل PasswordAuthentication وPermitRootLogin. عند تفعيل الجدار الناري، اسمح بالمنفذ 22 قبل تشغيل ufw enable. إذا فقدت الوصول، فستتيح لك وحدة التحكم على الويب التي يوفرها مزود الخدمة تسجيل الدخول مجدداً من دون SSH.

هل أحتاج فعلاً إلى كل هذه الإجراءات على خادم صغير؟

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

ما الإجراء الأهم على الإطلاق؟

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

كيف أتأكد من أن الخادم مؤمّن فعلاً؟

تحقق يدوياً من ثلاثة أمور قبل أن تثق بإعداده. شغّل sudo ss -tlnp وتأكد من أن المنافذ التي قصدت فتحها فقط تستمع على عنوان عام، وألا توجد خدمة 0.0.0.0 أو [::] نسيتها. شغّل sudo ufw status verbose وتأكد من أن السياسة الافتراضية للاتصالات الواردة هي deny، وأن قاعدتي plain و(v6) موجودتان. وافتح دائماً جلسة SSH ثانية قبل إغلاق الجلسة الأولى، حتى لا يتسبب خطأ في إعداد SSH في فقدان وصولك إلى الخادم. إذا بدت الأمور الثلاثة صحيحة، فالإعدادات الأساسية مكتملة.