أول 10 دقائق على خادم VPS جديد

الدقائق العشر الأولى تحدد مدى أمان خادمك

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

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

الدقيقة 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 قبل أن تتمكن من الدخول بمفتاح هو بالضبط ما يجعل الناس يحبسون أنفسهم خارج خوادمهم.

الدقيقة 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 لموقع ويب. وتأكد من تغطية IPv4 وIPv6 معًا، لأن جدار الحماية الذي يرشّح IPv4 وحده يترك جانب IPv6 مفتوحًا على مصراعيه. الشرح الكامل خطوة بخطوة في أساسيات جدران الحماية على VPS.

الدقيقة 10: أبطئ أدوات المسح بواسطة Fail2ban

أخيرًا، أضف Fail2ban لطرد العناوين التي تدقّ على منافذك بلا توقف:

sudo apt install -y fail2ban

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

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

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

راجِع بنودها بندًا بندًا مع كل خادم جديد وسيتحول الأمر كله إلى عادة تلقائية. عشر دقائق الآن تقيك ذلك اليوم العصيب الذي يعقب الاستيلاء على أحد خوادمك.

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

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 وأن القواعد العادية وقواعد (v6) موجودة معًا. وافتح دائمًا جلسة SSH ثانية قبل أن تغلق الأولى، حتى لا يتمكن خطأ في إعدادات SSH من حبسك خارج الخادم. إذا بدت الأمور الثلاثة سليمة، فالأساسيات في مكانها.