تأمين خادم VPS من أول دخول على Ubuntu 24.04

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

وفي هذا الدليل نفترض أن السيرفر يعمل بنظام Ubuntu 24.04، وأنك ما زلت في الدقائق الأولى بعد استلامه، وإذا لم تختر سيرفرك بعد فابدأ بدليل كيف تختار خادماً افتراضياً VPS ثم ارجع إلى هنا.

وسوف نناقش في هذا المقال ما يلي:

• إنشاء مفتاح SSH على جهازك، وتحديث النظام، وإنشاء مستخدم عادي بصلاحية sudo بدلاً من العمل بحساب root.
• تعطيل الدخول بكلمة المرور Password Authentication ومنع حساب root، ولماذا يتجاهل السيرفر إعدادك أحياناً إذا أخطأت في اسم الملف.
• مراجعة المنافذ المفتوحة، وتفعيل جدار الحماية Firewall، والتحديثات الأمنية التلقائية Automatic Security Updates.
• fail2ban وملف swap، ثم التأكد من نجاح كل خطوة، والنسخ الاحتياطي، والتحديث، وأشهر المشكلات وحلولها.

ما تحتاجه قبل أن تبدأ Requirements

• سيرفر افتراضي VPS يعمل بنظام Ubuntu Server 24.04 LTS، وإمكانية الدخول إليه بحساب root أو بالمستخدم الذي ينشئه المزود.
• جهاز محلي فيه عميل Client OpenSSH، وهو مدمج في Linux وmacOS وWindows 10 وما بعده.
• عنوان IP العام للسيرفر، وسوف نستخدم في هذا الدليل العنوان التوضيحي 203.0.113.10، فضع عنوانك مكانه في كل الأوامر.

الدخول الأول وتأمين السيرفر

ما إن يحصل السيرفر على عنوان عام حتى تبدأ البرامج الآلية بتجربة كلمات المرور على المنفذ 22، لذلك نفذ الخطوات التالية بترتيبها، وسوف تغلق هذا الباب خلال ربع ساعة تقريباً. ونفترض هنا أن السيرفر يعمل بنظام Ubuntu 24.04، وأن المزود أعطاك الدخول بحساب root بمفتاح أو بكلمة مرور.

إنشاء مفتاح SSH على جهازك

إذا لم يكن لديك مفتاح، فأنشئه على جهازك المحلي وليس على السيرفر، والسبب أن المفتاح الخاص Private Key يجب أن يبقى عندك أنت ولا يغادر جهازك. واختر النوع ed25519 فمفتاحه قصير وقوي، واحمه بعبارة مرور Passphrase حتى لا يستفيد منه من يصل إلى جهازك:

ssh-keygen -t ed25519 -C "[email protected]"

والأفضل أن تضيف المفتاح العام Public Key، أي الملف ~/.ssh/id_ed25519.pub، في لوحة المزود عند إنشاء السيرفر، وبالتالي يدخل root بالمفتاح من البداية ولا تمر كلمة المرور عبر الشبكة أبداً.

ابدأ بتحديث النظام System Update

بعد ذلك ادخل إلى السيرفر وحدث النظام، ثم أعطه اسماً واضبط منطقته الزمنية:

ssh [email protected]
apt update && apt full-upgrade -y
hostnamectl set-hostname app01
timedatectl set-timezone UTC

ضبط المنطقة الزمنية Time Zone على UTC يسهل مقارنة السجلات Logs بين الأنظمة، فلا تحتاج أن تحسب فروق التوقيت كلما تتبعت مشكلة بين سيرفرين. وإذا تطلب التحديث إعادة التشغيل Reboot، أي إذا وجدت الملف /var/run/reboot-required، فأعد التشغيل الآن قبل أن تبني أي شيء على السيرفر.

وتأكد أن ساعة السيرفر متزامنة Time Synchronization، والسبب أن السجلات وfail2ban وشهادات TLS كلها تعتمد على الوقت الصحيح. ويتولى ذلك في Ubuntu 24.04 الخدمة systemd-timesyncd، ولاحظ أن الأمر timedatectl يجب أن يعرض السطرين System clock synchronized: yes وNTP service: active.

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

الطريقة الأسهل هي أن تعمل يومياً بحساب root، وهي أسوأ الطرق على الإطلاق، فأي خطأ مطبعي سوف ينفذ بكامل الصلاحيات، والمهاجم يعرف مسبقاً نصف بيانات الدخول وهو اسم المستخدم «root»، فلا يبقى عليه إلا أن يخمن النصف الآخر. لذلك أنشئ مستخدماً باسم من اختيارك وامنحه صلاحية sudo:

adduser deploy
usermod -aG sudo deploy
id deploy

والمخرج سوف يكون كما يلي، ولاحظ وجود المجموعة sudo بين مجموعات المستخدم:

uid=1001(deploy) gid=1001(deploy) groups=1001(deploy),27(sudo),100(users)

الآن انسخ مفاتيح root المصرح بها Authorized Keys إلى المستخدم الجديد، واضبط الملكية Ownership والصلاحيات Permissions كما في الأمر التالي، والسبب أن سيرفر SSH يرفض المفاتيح إذا كانت صلاحيات المجلد أوسع من اللازم:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

وإذا كان الدخول بكلمة المرور لا يزال مفعلاً، فيمكنك نسخ المفتاح من جهازك المحلي بالأمر ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

تعطيل الدخول بكلمة المرور ومنع حساب root

الطريقة التي يبدأ بها كثيرون هي تعديل الملف الرئيسي /etc/ssh/sshd_config مباشرة، والأنظف أن تبقيه كما هو، لذلك لا تعدله، وإنما ضع إعداداتك في ملف مستقل داخل المجلد sshd_config.d. وهنا تفصيل يغفل عنه كثيرون، حيث يأخذ sshd أول قيمة يقرؤها لكل خيار ويقرأ الملفات بالترتيب الأبجدي، وكثير من الصور السحابية Cloud Images تأتي بملف 50-cloud-init.conf فيه PasswordAuthentication yes، فلو سميت ملفك 99-... كما يفعل البعض ظناً أن الأخير يفوز، لما سرى مفعوله وبقي السيرفر يقبل كلمة المرور دون أن تنتبه، ولهذا نسميه 00-hardening.conf. وإذا اخترت اسم مستخدم غير deploy فضعه في السطر AllowUsers، وإلا رفض السيرفر دخولك أنت أيضاً:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers deploy
EOF

في الإعداد أعلاه لاحظ التالي:

• السطران PermitRootLogin وPasswordAuthentication يمنعان حساب root ويعطلان الدخول بكلمة المرور، ويغلق KbdInteractiveAuthentication الطريق الآخر الذي قد تمر منه كلمة المرور.
• السطر AuthenticationMethods يجعل المفتاح هو الطريقة الوحيدة المقبولة للدخول.
• السطران MaxAuthTries وLoginGraceTime يقللان عدد المحاولات في الاتصال الواحد والوقت المسموح لإتمام الدخول.
• السطر AllowUsers يقصر الدخول على المستخدمين المذكورين فيه فقط.

افحص الصياغة Syntax أولاً، ثم اعرض الإعداد الفعلي الذي سوف يعمل به sshd بعد دمج كل الملفات:

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|allowusers|maxauthtries) '

والمخرج سوف يكون كما يلي:

maxauthtries 3
permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
allowusers deploy
authenticationmethods publickey

بعد ذلك أعد تحميل الخدمة، واسمها في Ubuntu 24.04 هو ssh، ولاحظ أن الجلسات المفتوحة لن تنقطع:

sudo systemctl reload ssh

ثم تأكد من جهازك أن الدخول بالمفتاح يعمل، وأن السيرفر يرفض كلمة المرور ويرفض حساب root:

ssh [email protected] 'whoami'
ssh -o PubkeyAuthentication=no [email protected]
ssh [email protected]

والمخرج سوف يكون كما يلي، حيث يعيد الأمر الأول اسم المستخدم ويرفض السيرفر الأمرين الآخرين:

deploy
[email protected]: Permission denied (publickey).
[email protected]: Permission denied (publickey).

مراجعة المنافذ المفتوحة Listening Ports

قبل إعداد جدار الحماية اعرف ما يستمع على السيرفر فعلاً، فلا معنى أن تغلق أبواباً لا تعرف بوجودها. ويعرض الأمر ss منافذ TCP وUDP المفتوحة واسم البرنامج الذي يملك كل منفذ:

sudo ss -tulpn

وعلى سيرفر جديد سوف تجد غالباً المنفذ 22، وقد يظهر باسم systemd أو sshd بسبب آلية Socket Activation، وسوف تجد أيضاً systemd-resolved على العنوان المحلي 127.0.0.53، وهذا لا يصل إليه أحد من الخارج. أما أي خدمة أخرى تستمع على 0.0.0.0 أو [::] ولا تحتاجها، فأوقفها بالأمر sudo systemctl disable --now متبوعاً باسمها أو احذف حزمتها، والسبب أن كل خدمة مفتوحة للإنترنت هي باب إضافي عليك أن تحرسه وتحدثه.

إعداد جدار الحماية ufw

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

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

والمخرج سوف يكون كما يلي:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

وإذا كان عنوانك ثابتاً، في مكتب أو عبر VPN، فالأكثر أماناً أن تقصر الوصول إلى SSH عليه، فنفذ sudo ufw allow from 198.51.100.7 to any port 22 proto tcp ثم احذف القاعدة العامة بالأمر sudo ufw delete allow OpenSSH. ويمكنك أيضاً استخدام sudo ufw limit OpenSSH بدلاً من allow، وعندها يرفض ufw اتصالات أي عنوان يحاول فتح 6 اتصالات أو أكثر خلال 30 ثانية.

التحديثات الأمنية التلقائية

أغلب الاختراقات تستغل ثغرات Vulnerabilities صدرت تحديثاتها قبل أسابيع، فالمشكلة في الغالب ليست أن الإصلاح غير موجود، وإنما أن أحداً لم يثبته. وأداة unattended-upgrades تثبت التحديثات الأمنية يومياً دون تدخل منك، والحزمة Package مثبتة عادة في صور Ubuntu Server، فيكفي أن تفعلها وتتأكد من إعدادها:

sudo apt install -y unattended-upgrades
echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

والمخرج سوف يكون كما يلي، حيث يعني الرقم 1 في السطرين أن تحديث قائمة الحزم Package Lists والتثبيت التلقائي يعملان كل يوم:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

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

sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF

ثم شغل تجربة Dry Run تعرض ما سوف يحدث دون أن تنفذه:

sudo unattended-upgrade --dry-run --debug 2>&1 | grep -E 'Allowed origins|Packages that will be upgraded'

والمخرج سوف يكون كما يلي، ولاحظ أن المصادر المسموحة كلها من مستودعات Ubuntu الأمنية:

Allowed origins are: o=Ubuntu,a=noble, o=Ubuntu,a=noble-security, o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-security

fail2ban (اختياري)

وقد يتساءل البعض: إذا عطلنا الدخول بكلمة المرور، فما فائدة fail2ban؟ والإجابة أن تخمين كلمات المرور لم يعد خطراً حقيقياً على SSH بالفعل، ولكن fail2ban يبقى مفيداً، فهو يحجب العناوين المزعجة مؤقتاً ويخفف الضجيج في السجلات، ويمكنك لاحقاً توسيعه ليحمي تطبيقات أخرى تقبل كلمات المرور:

sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd

[sshd]
enabled = true
EOF
sudo fail2ban-client -t
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

في الإعداد أعلاه لاحظ أن أي عنوان يفشل 5 مرات خلال 10 دقائق سوف يحجب لمدة ساعة، وأن السطر backend = systemd يجعل fail2ban يقرأ السجلات من journald.

إنشاء ملف swap صغير

كثير من صور VPS تأتي دون مساحة swap، وبالتالي إذا ارتفع استهلاك الذاكرة لحظة واحدة فقد يتدخل ال OOM Killer، وهو الآلية التي يوقف بها النظام برنامجاً عندما تنفد الذاكرة، فيوقف عملية Process مهمة مثل قاعدة البيانات. لذلك أنشئ ملف swap صغيراً يمتص هذه الارتفاعات العابرة:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

كيف تتأكد أن كل خطوة نجحت Verification

الآن سوف نتأكد أن كل خطوة سرى مفعولها، وفيما يلي ما يجب أن تراه:

• يرفض السيرفر ssh [email protected] وssh -o PubkeyAuthentication=no [email protected]، ويرد على كليهما بالرسالة Permission denied (publickey).
• الأمر sudo sshd -T | grep passwordauthentication يعيد passwordauthentication no.
• الأمر timedatectl يعرض System clock synchronized: yes.
• الأمر sudo ufw status يعيد Status: active، والمنافذ المفتوحة هي 22 و80 و443 فقط.
• الأمر systemctl is-active unattended-upgrades يعيد active، والأمر systemctl list-timers apt-daily-upgrade.timer يعرض موعد التشغيل التالي، وبعد يوم سوف تجد سجلها في /var/log/unattended-upgrades/unattended-upgrades.log.
• إذا نفذت nmap -Pn 203.0.113.10 من جهاز خارجي، فلن ترى إلا المنافذ التي سمحت بها.
• الأمر swapon --show يعرض الملف /swapfile، والأمر systemd-detect-virt يعرض نوع التقنية الافتراضية Virtualization، مثل kvm.

النسخ الاحتياطي Backup والاستعادة Restore

لم تثبت أي تطبيق بعد، ولكن جهز أساس النسخ الاحتياطي من الآن، والسبب أن أفضل وقت لأخذ نقطة رجوع نظيفة هو قبل أن يصبح السيرفر مليئاً بالخدمات:

1. فعل النسخ الاحتياطي التلقائي من لوحة المزود إن كان متاحاً.
2. بعد إتمام التأمين خذ Snapshot يدوياً وسمها باسم واضح (app01-base-2026-09)، فهي نقطة الرجوع النظيفة التي سوف تحتاجها إذا أفسد تثبيت لاحق شيئاً.
3. احفظ إعداداتك في مستودع Repository خاص أو في مجلد مخصص للنسخ، والملفات المهمة هي /etc/ssh/sshd_config.d/ و/etc/ufw/ و/etc/apt/apt.conf.d/52unattended-upgrades-local و/etc/fail2ban/jail.local، ويكفي لذلك أرشيف Archive واحد:

sudo tar czf ~/baseline-$(hostname)-$(date +%F).tar.gz /etc/ssh/sshd_config.d /etc/ufw /etc/apt/apt.conf.d/52unattended-upgrades-local /etc/fail2ban/jail.local /etc/fstab

بعد ذلك انقل الأرشيف إلى جهازك بالأمر scp [email protected]:baseline-*.tar.gz .. ولاستعادته على سيرفر جديد أنشئ المستخدم نفسه أولاً وانسخ إليه مفتاحك، والسبب أن السطر AllowUsers لا يسمح بغيره، ثم فك الأرشيف في /، ولكن لا تنسخ الملف /etc/fstab كما هو، فهو يشير إلى أقراص السيرفر القديم وقد يمنع الإقلاع Boot، وإنما خذ منه سطر ال swap فقط. ثم نفذ sudo sshd -t وsudo systemctl reload ssh وsudo ufw reload. وعندما تبدأ تثبيت التطبيقات سوف تجد طريقة النسخ الاحتياطي لكل تطبيق في دليله.

التحديث Upgrade إلى إصدار أحدث

• التحديثات الأمنية تتولاها أداة unattended-upgrades، فراجع سجلها كل أسبوع، وإذا لم تفعل إعادة التشغيل التلقائية فراقب الملف /var/run/reboot-required.
• التحديثات العادية مكانها نافذة صيانة Maintenance Window شهرية، تأخذ فيها Snapshot يدوياً ثم تنفذ sudo apt update && sudo apt full-upgrade.
• الانتقال إلى إصدار Ubuntu LTS التالي (إلى 26.04 مثلاً) لا يحتاج إلى عجلة، فانتظر أول إصدار تصحيحي Point Release (.1)، وخذ Snapshot، ثم نفذ sudo do-release-upgrade من جلسة داخل tmux أو screen، والسبب أن انقطاع اتصال SSH في منتصف الترقية لن يوقفها عندها. ولسيرفرات ال Containers بديل أنظف، وهو أن تجهز سيرفراً جديداً بالإصدار الجديد وتنقل إليه البيانات ثم توجه DNS إليه.
• زيادة موارد السيرفر: خذ Snapshot ثم غير الخطة من لوحة التحكم، وبعد الإقلاع تحقق بالأوامر nproc وfree -h وdf -h. ولاحظ أن بعض المزودين يقومون بزيادة حجم القرص دون أن يقوموا بتوسيع نظام الملفات Filesystem، وعندها تحتاج إلى growpart وresize2fs.

مشكلات شائعة وحلولها Troubleshooting

السيرفر لا يزال يقبل كلمة المرور

السبب غالباً ملف آخر في /etc/ssh/sshd_config.d/ يسبق ملفك في الترتيب الأبجدي كما ذكرنا، لذلك اعرض الملفات بالأمر ls /etc/ssh/sshd_config.d/، وتأكد أن اسم ملفك يبدأ بـ 00-، ثم تحقق بالأمر sudo sshd -T | grep passwordauthentication.

رسالة Permission denied (publickey) للمستخدم الجديد

السبب غالباً صلاحيات أو ملكية خاطئة، حيث يجب أن تكون صلاحية ~/.ssh هي 700 وصلاحية authorized_keys هي 600، وأن يملكهما المستخدم نفسه. وسجل السيرفر يوضح السبب بالأمر sudo journalctl -u ssh -n 30، أما على جهازك فيبين الأمر ssh -v [email protected] المفاتيح التي جربها العميل.

فقدت الوصول إلى السيرفر عبر SSH

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

رسالة Skipping unsupported IPv4 'limit' rule من ufw

سوف ترى هذه الرسالة عندما لا تدعم النواة أو بيئة السيرفر وحدة Module recent في iptables، ويحدث هذا داخل ال Containers وفي بعض أنواع التقنية الافتراضية الخفيفة، لذلك تحقق من نوع التقنية الافتراضية، واستخدم allow مع fail2ban بدلاً من limit.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• أمن السيرفر قبل أن تثبت عليه أي تطبيق، فالبرامج الآلية تبدأ بتجربة كلمات المرور بعد دقائق من تشغيله.
• ادخل بمفتاح ed25519 وبمستخدم عادي بصلاحية sudo، وعطل الدخول بكلمة المرور وحساب root.
• ضع إعدادات SSH في الملف 00-hardening.conf وليس في الملف الرئيسي، لأن sshd يأخذ أول قيمة يقرؤها، وتحقق دائماً بالأمر sshd -T.
• أبق جلسة مفتوحة واختبر الدخول من نافذة ثانية قبل أن تغلق الأولى.
• ارفض كل اتصال وارد في ufw إلا ما تحتاجه، وفعل التحديثات الأمنية التلقائية، فأغلب الاختراقات تستغل ثغرات إصلاحها موجود.
• خذ Snapshot نظيفة وأرشيفاً للإعدادات بعد التأمين، فهما نقطة رجوعك.

سجل التحديثات

• سبتمبر 2026: كتابة خطوات التأمين واختبارها على Ubuntu 24.04.5 LTS مع OpenSSH 9.6p1 وufw 0.36.2 وunattended-upgrades 2.9.1.
• أكتوبر 2026: فصل خطوات التأمين عن دليل اختيار الخادم في دليل مستقل.
• أكتوبر 2026: إضافة فحص تزامن الوقت ومراجعة المنافذ المفتوحة، وتصحيح مخرجات ufw status verbose، والتنبيه إلى ملف /etc/fstab عند الاستعادة.