[{"data":1,"prerenderedAt":191},["ShallowReactive",2],{"seo-verification":3,"blog-قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم-ar":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"slugs":9,"title":13,"excerpt":14,"readTime":15,"views":16,"isPinned":17,"publishedAt":18,"category":19,"categories":25,"featuredImage":27,"bgImage":28,"posterImage":29,"relatedSolution":27,"intro":30,"sections":31,"ctaTitle":142,"ctaBody":143,"ctaButton":144,"ctaUrl":145,"relatedPosts":146},317,"قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم",{"fr":10,"en":11,"ar":8,"es":12},"linux-hardening-vps-checklist","linux-vps-hardening-checklist-for-agencies","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","قائمة تصليب خادم لينكس للوكالات بعد التسليم","قائمة تدقيق لتصليب لينكس قابلة للتكرار للوكالات: auditd وsudo ومفتاح SSH وUFW وfail2ban وإلغاء تفعيل root — مع إمكانية التتبع لكل عميل.",11,0,false,"2026-08-30T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},8,"الأمان والمراقبة","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[26],{"id":20,"name":21,"slug":22,"color":23,"icon":24},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg","وكالتك تسلّم خادمًا VPS وكل تقني يطبق «تقريبًا نفس الشيء» — بدون دليل مكتوب، بدون أثر موثق. عند وقوع حادث أمني، لا يمكنك إثبات أن تهيئة الأمان المتفق عليها قد طُبّقت فعليًا. يبدأ هذا الدليل من حيث ينتهي البرنامج التعليمي الفردي: التوحيد والتفويض والتتبع لإدارة محفظة خوادم العملاء.",[32,36,46,49,59,68,77,83,89,98,101,133,136,139],{"type":33,"title":34,"body":35},"h2","لماذا يغيّر الدليل المقنَّن كل شيء للوكالة","يستطيع المطور الفردي تطبيق خمس أوامر ذهنيًا بعد كل تسليم. الوكالة لا تستطيع ذلك: تقنيون متعددون، وعشرات خوادم VPS للعملاء، وجداول مناوبة متدورة. حين يُبلّغ عميل عن وصول مشبوه بعد ستة أشهر من الإطلاق، السؤال ليس «هل أمّنتم الخادم؟» بل «هل تستطيعون إثبات ذلك؟»\n\nأصبحت إمكانية التتبع متطلبًا تعاقديًا وتنظيميًا. تُلزم توجيهات **NIS2** (جاري تطبيقها في التشريعات الوطنية) و**GDPR** مقدمي الخدمات الذين يتعاملون مع البيانات الشخصية بتوثيق الإجراءات الأمنية المُطبَّقة. بدون دليل تشغيل موثق وبدون سجلات‏ `auditd`‏، لا تملك وكالتك أي وثيقة قابلة للاحتجاج بها.\n\nلا يُعيد هذا الدليل وصف تثبيت‏ `fail2ban`‏ أو‏ `UFW`‏ — فمقالا \u003Ca href=\"\u002Fblog\u002Fproteger-vps-fail2ban\">حماية VPS باستخدام fail2ban\u003C\u002Fa> و\u003Ca href=\"\u002Fblog\u002Fpare-feu-ufw-vps\">جدار الحماية UFW على VPS\u003C\u002Fa> يتناولان ذلك بالتفصيل. ينطلق هذا الدليل من مستوى أعلى: كيفية توحيد هذه الإجراءات وتفويضها وتتبعها عبر محفظة كاملة من عملاء.",{"type":37,"title":38,"items":39},"ul","ما يضيفه هذا الدليل لوكالتك",[40,41,42,43,44,45],"**قابلية التكرار**: يتبع كل تقني نفس الخطوات بالضبط، بنفس الترتيب، في كل خادم VPS جديد.","**إمكانية التتبع**: يسجّل‏ `auditd`‏ من فعل ماذا، ومتى، وأي أمر — دليل قابل للحفظ في حالات الحوادث أو مراجعات العملاء.","**التفويض الآمن**: يستطيع التقني المبتدئ تسليم خادم مُصلَّب دون ارتجال، لأن الدليل يحتوي القرارات نيابةً عنه.","**الدفاع التعاقدي**: بند الأمان في عقد الصيانة لا يمكن الاحتجاج به إلا بسجل تنفيذ مؤرخ.","**تقليص سطح الهجوم**: تُزيل القائمة الإهمالات الكلاسيكية — SSH للمستخدم root مفتوح، auditd غير مفعّل — وهي نقاط الدخول الأكثر استغلالًا.","**الاتساق بين العملاء**: نفس القاعدة الأمنية للجميع، مع فوارق فقط حيثما يستلزم ذلك مواصفات العميل.",{"type":33,"title":47,"body":48},"المتطلبات الأساسية ونطاق القائمة","تستهدف هذه القائمة **Ubuntu 24.04 LTS** و**Debian 12** (Bookworm)، وهما أكثر التوزيعات شيوعًا على خوادم VPS عام 2026. جرى التحقق من الأوامر على هذه الأنظمة؛ على AlmaLinux أو Rocky Linux تختلف أسماء الحزم ومسارات الخدمة.\n\nالمتطلبات الدنيا للـ‏VPS: نواة واحدة (vCPU)، 1 جيجابايت رام (2 جيجابايت مُوصى بها عند تشغيل fail2ban وauditd معًا)، 20 جيجابايت SSD. تسلّم ServOrbit كل VPS بوصول فوري للمستخدم root عبر SSH وطرفية KVM مضمّنة، مما يُتيح لوكالتك تطبيق هذا الدليل منذ اللحظة الأولى — دون الحاجة لطلب وصول وسيط من المضيف.\n\nالقائمة منظَّمة في **سبعة كتل** بترتيب التطبيق. تتوقف عند نطاق الأمان الأساسي للنظام: أمان التطبيقات (لوحة الإدارة المكشوفة، الهجمات على التطبيقات) مُعالَج بشكل منفصل في \u003Ca href=\"\u002Fblog\u002Fbackoffice-vps-surfaces-attaque-oubliees-2026\">لوحة الإدارة المكشوفة: سطوح الهجوم المنسية على VPS\u003C\u002Fa>.",{"type":50,"title":51,"steps":52},"steps","الكتلة 1 — التحديثات والجرد الأولي",[53,56],{"title":54,"body":55},"تحديث النظام وإعداد الجرد","أول إجراء بعد تسجيل الدخول كـ‏root‏ هو رفع النظام إلى مستوى التصحيحات الحالية.\n\n```bash\napt update && apt upgrade -y\napt install -y auditd audispd-plugins curl gnupg2 ufw fail2ban\n```\n\nسجّل في دليل التشغيل: التاريخ وإصدار النواة (`uname -r`) وقائمة الحزم المثبتة (`dpkg -l > \u002Froot\u002Finventory-$(date +%F).txt`). يُشكّل ملف الجرد هذا **خط الأساس** للخادم عند التسليم — وهو الوثيقة التي تقدمها إذا أبدى عميل اعتراضًا على الحالة الأولية لجهازه.\n\n**مرجع CIS Benchmark**: التحكم CIS 1.1 (Ubuntu Linux 24.04 LTS Benchmark، قسم «الإعداد الأولي»).",{"title":57,"body":58},"تفعيل التحديثات الأمنية التلقائية","```bash\napt install -y unattended-upgrades\ndpkg-reconfigure --priority=low unattended-upgrades\n```\n\nتحقق من أن السطر `Unattended-Upgrade::Allowed-Origins` يتضمن `${distro_id}:${distro_codename}-security`. لمحفظة العملاء، فعّل التحديثات التلقائية وجدوِل مراجعة شهرية للتحديثات غير الأمنية — تستلزم موافقة بشرية.\n\n**مرجع CIS**: التحكم CIS 1.9 (ضمان تثبيت التحديثات والتصحيحات والبرامج الأمنية الإضافية).",{"type":50,"title":60,"steps":61},"الكتلة 2 — مستخدم sudo وإغلاق root",[62,65],{"title":63,"body":64},"إنشاء حساب مخصص للإدارة","لا تستخدم `root` للمهام اليومية. أنشئ حسابًا اسميًا لكل تقني أو حساب خدمة للوكالة:\n\n```bash\nuseradd -m -s \u002Fbin\u002Fbash adminagency\nusermod -aG sudo adminagency\npasswd adminagency\n```\n\n**نصيحة للوكالة**: استخدم اسم حساب يمكن تمييزه في السجلات (`jean.dupont` أو `agency-admin`)، لا اسمًا عامًا مثل `admin`. حين يتتبع `auditd` إجراءً ما، يُسجَّل الحساب المُنفِّذ — الاسم العام يُفقد المراجعة قيمتها.",{"title":66,"body":67},"تعطيل تسجيل دخول root عبر SSH","```bash\nsed -i 's\u002F^#\\?PermitRootLogin.*\u002FPermitRootLogin no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\ngrep PermitRootLogin \u002Fetc\u002Fssh\u002Fsshd_config\n```\n\nتنبيه: لا تُعد تحميل `sshd` إلا **بعد** التحقق من قدرة مستخدم sudo على الاتصال وتنفيذ `sudo su`. وإلا ستُقفل نفسك خارج الخادم.\n\n**مرجع CIS**: التحكم CIS 5.2.8 (ضمان تعطيل تسجيل دخول root عبر SSH).",{"type":50,"title":69,"steps":70},"الكتلة 3 — المصادقة بمفتاح SSH",[71,74],{"title":72,"body":73},"نشر المفتاح العمومي للوكالة","```bash\nmkdir -p \u002Fhome\u002Fadminagency\u002F.ssh\nchmod 700 \u002Fhome\u002Fadminagency\u002F.ssh\necho \"\u003CAGENCY_PUBLIC_KEY>\" >> \u002Fhome\u002Fadminagency\u002F.ssh\u002Fauthorized_keys\nchmod 600 \u002Fhome\u002Fadminagency\u002F.ssh\u002Fauthorized_keys\nchown -R adminagency:adminagency \u002Fhome\u002Fadminagency\u002F.ssh\n```\n\n**نصيحة للوكالة**: احتفظ بمستودع مفاتيح عمومية بإصدارات (ملف واحد لكل تقني، تجديد سنوي). كل مفتاح يُنشر على VPS عميل يجب أن يكون مرجعًا في هذا المستودع — هذا ما يُتيح لك إلغاء وصول شخص غادر الفريق.",{"title":75,"body":76},"تعطيل المصادقة بكلمة المرور","بعد التحقق من المفتاح (اختبر من طرفية أخرى قبل التأكيد):\n\n```bash\nsed -i 's\u002F^#\\?PasswordAuthentication.*\u002FPasswordAuthentication no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\nsed -i 's\u002F^#\\?ChallengeResponseAuthentication.*\u002FChallengeResponseAuthentication no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\nsystemctl reload sshd\n```\n\n**مرجع CIS**: التحكم CIS 5.2.19 (ضمان تعطيل المصادقة بكلمة المرور في SSH).",{"type":50,"title":78,"steps":79},"الكتلة 4 — جدار الحماية UFW",[80],{"title":81,"body":82},"تهيئة UFW بسياسة الرفض الافتراضي","```bash\nufw default deny incoming\nufw default allow outgoing\nufw allow 22\u002Ftcp comment 'Agency SSH'\nufw allow 80\u002Ftcp comment 'HTTP'\nufw allow 443\u002Ftcp comment 'HTTPS'\nufw --force enable\nufw status verbose\n```\n\nافتح فقط المنافذ التي يستخدمها مشروع العميل فعليًا. إذا لم يستخدم تطبيق العميل منفذ بريد إلكتروني مباشر، لا تفتحه.\n\nللتفاصيل الكاملة عن fail2ban وخيارات UFW المتقدمة، راجع المقالين: \u003Ca href=\"\u002Fblog\u002Fproteger-vps-fail2ban\">حماية VPS باستخدام fail2ban\u003C\u002Fa> و\u003Ca href=\"\u002Fblog\u002Fpare-feu-ufw-vps\">جدار الحماية UFW على VPS\u003C\u002Fa>.\n\n**مرجع CIS**: التحكم CIS 3.5.1 (ضمان تثبيت حزمة جدار الحماية).",{"type":50,"title":84,"steps":85},"الكتلة 5 — fail2ban",[86],{"title":87,"body":88},"تفعيل fail2ban مع سجن SSH","```bash\ncp \u002Fetc\u002Ffail2ban\u002Fjail.conf \u002Fetc\u002Ffail2ban\u002Fjail.local\n```\n\nحرِّر `\u002Fetc\u002Ffail2ban\u002Fjail.local` واضبط قسم `[sshd]`:\n\n```bash\n[sshd]\nenabled = true\nmaxretry = 5\nfindtime = 600\nbantime = 3600\n```\n\n```bash\nsystemctl enable fail2ban\nsystemctl start fail2ban\nfail2ban-client status sshd\n```\n\nلمحفظة العملاء، يُنصح بالنظر في \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">CrowdSec\u003C\u002Fa> كبديل أو مكمّل: قائمة الحجب المجتمعية تجمع معلومات آلاف الخوادم.",{"type":50,"title":90,"steps":91},"الكتلة 6 — auditd: سجل التتبع",[92,95],{"title":93,"body":94},"تفعيل auditd وتهيئة القواعد الأساسية","`auditd` هو المكوّن الذي تنساه الوكالات في أغلب الأحيان — ومع ذلك فهو الذي يوفر الدليل القابل للاحتجاج عند وقوع حادث.\n\n```bash\nsystemctl enable auditd\nsystemctl start auditd\n```\n\nأنشئ ملف قواعد الوكالة في `\u002Fetc\u002Faudit\u002Frules.d\u002Fagency.rules`:\n\n```bash\n# تتبع جميع عمليات رفع الصلاحيات\n-w \u002Fetc\u002Fsudoers -p wa -k sudoers_changes\n-w \u002Fetc\u002Fsudoers.d\u002F -p wa -k sudoers_changes\n\n# تتبع اتصالات SSH\n-w \u002Fvar\u002Flog\u002Fauth.log -p wa -k auth_log\n\n# تتبع تعديلات ملفات الإعداد الأساسية\n-w \u002Fetc\u002Fssh\u002Fsshd_config -p wa -k sshd_config\n-w \u002Fetc\u002Fpasswd -p wa -k passwd_changes\n-w \u002Fetc\u002Fshadow -p wa -k shadow_changes\n\n# تتبع الأوامر المنفّذة بصلاحية root\n-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands\n```\n\n```bash\naugenrules --load\nauditctl -l\n```\n\n**مرجع CIS**: التحكم CIS 4.1.1 (ضمان تفعيل المراجعة) والتحكم CIS 4.1.3 (ضمان جمع الأحداث التي تُعدّل معلومات التاريخ والوقت).",{"title":96,"body":97},"تصدير سجلات auditd والاحتفاظ بها","يجب الاحتفاظ بسجلات `auditd` خارج الخادم لتكون قابلة للاحتجاج. هيّئ تصديرًا إلى نظامك المركزي (rsyslog أو Loki أو مزامنة `rsync` يومية بسيطة إلى تخزين الوكالة):\n\n```bash\n# مثال: تصدير rsyslog إلى جامع الوكالة\necho ':programname, isequal, \"auditd\" @\u003CIP_COLLECTEUR_AGENCE>:514' \\\n  >> \u002Fetc\u002Frsyslog.d\u002F99-auditd-remote.conf\nsystemctl restart rsyslog\n```\n\nاحتفظ بالسجلات لمدة 90 يومًا على الأقل. لا يحدد GDPR مدة احتفاظ دنيا لسجلات الأمان، لكن أُطر مثل **CIS Controls v8** (التحكم 8.3) توصي بـ 90 يومًا على الأقل في الموقع وسنة في أرشيف بارد.",{"type":33,"title":99,"body":100},"الكتلة 7 — التحقق النهائي وسجل التسليم","بعد تنفيذ الكتل الست السابقة، راجع حالة الخادم قبل تسليم الوصول إلى العميل:\n\n```bash\n# التحقق من الخدمات النشطة\nsystemctl is-active ufw fail2ban auditd sshd\n\n# التأكد أن root لا يستطيع الاتصال عبر SSH\ngrep PermitRootLogin \u002Fetc\u002Fssh\u002Fsshd_config\n\n# التحقق من قواعد UFW\nufw status verbose\n\n# التحقق من قواعد auditd المحمّلة\nauditctl -l\n\n# مراجعة آخر عمليات تسجيل الدخول\nlast -n 10\n```\n\nأنتج **سجل تسليم مؤرخًا وموقعًا** (حتى عبر البريد الإلكتروني) يُدرج الإجراءات المطبّقة وإصدارات حزم الأمان المثبتة وموقع جامع السجلات. هذه الوثيقة يوقّعها عميلك وتُشكّل الدليل التعاقدي على التهيئة الأولية.\n\nسجل التسليم ليس شكليةً: عميل يتعرض لاختراق بعد سنتين من الإطلاق سيطلب من وكالتك تبرير حالة الخادم عند التسليم. بدون هذه الوثيقة، يتحول عبء الإثبات.",{"type":102,"title":103,"headers":104,"rows":108},"comparison","دليل الوكالة مقابل التهيئة الارتجالية",[105,106,107],"المعيار","التهيئة الارتجالية","الدليل الموحَّد",[109,113,117,121,125,129],[110,111,112],"قابلية التكرار","تعتمد على التقني الحاضر","متطابقة في كل تسليم",[114,115,116],"تتبع auditd","نادرًا ما يُفعَّل، تهيئة متغيرة","مفعَّل ومهيَّأ بشكل منهجي",[118,119,120],"الدليل عند الحوادث","لا وثائق قابلة للاحتجاج","سجل تسليم مؤرخ + سجلات مركزية",[122,123,124],"التفويض لمبتدئ","محفوف بالمخاطر (إهمالات محتملة)","ممكن مع الدليل كمرشد",[126,127,128],"تجديد مفاتيح SSH","يدوي وكثيرًا ما يُنسى","إجراء مكتوب ومستودع بإصدارات",[130,131,132],"الامتثال لـ NIS2 \u002F GDPR","غير موثق","موثق وقابل للتكرار",{"type":134,"body":135},"tip","**نصيحة المراجعة الشهرية.** مرة في الشهر، أعِد تنفيذ التحققات النهائية من الكتلة 7 على كل VPS عميل نشط وأرشِف المخرجات. الفرق بين مراجعتين متتاليتين يكشف فورًا أي تعديل غير مصرح به: منفذ إضافي مفتوح، خدمة fail2ban موقوفة، قاعدة auditd ناقصة. تستغرق هذه المراجعة أقل من خمس دقائق للخادم الواحد حين تكون الأوامر في سكريبت.",{"type":33,"title":137,"body":138},"استكشاف الأخطاء: الأخطاء الشائعة عند تطبيق الدليل","**الخطأ 1 — `sshd` يرفض البدء بعد تعديل `sshd_config`**\nالرسالة: `sshd: \u002Fetc\u002Fssh\u002Fsshd_config line 42: unsupported option`\nالسبب: توجيه مهمل أو بصياغة خاطئة. تحقق بـ `sshd -t` قبل إعادة تحميل الخدمة. على Ubuntu 24.04، استُبدلت `ChallengeResponseAuthentication` بـ `KbdInteractiveAuthentication`.\n\n```bash\nsshd -t && systemctl reload sshd\n```\n\n**الخطأ 2 — UFW يحجب اتصال SSH الخاص بك**\nالرسالة: يتجمّد الاتصال SSH بعد `ufw enable`.\nالسبب: لم تُضَف قاعدة SSH قبل التفعيل. استخدم طرفية KVM الخاصة بـ ServOrbit للوصول إلى الخادم بدون SSH، ثم نفّذ `ufw allow 22\u002Ftcp` و`ufw reload`.\n\n**الخطأ 3 — `auditd` يعمل لكن `auditctl -l` يُعيد قائمة فارغة**\nالرسالة: `List of rules:` لا يتبعها شيء.\nالسبب: ملف القواعد غير محمّل. تحقق من وجود ملف `.rules` في `\u002Fetc\u002Faudit\u002Frules.d\u002F` ونفّذ `augenrules --load`.\n\n**الخطأ 4 — fail2ban لا يحظر رغم محاولات فاشلة متكررة**\nالرسالة: `fail2ban-client status sshd` يُظهر `Currently banned: 0` بعد 10 محاولات.\nالسبب: تغيّر مسار سجل SSH. على Debian 12 وUbuntu 24.04 مع journald، يجب ضبط الخلفية في `jail.local`: `backend = systemd`.\n\n**الخطأ 5 — `unattended-upgrades` يُعيد تشغيل خدمات الإنتاج**\nالسبب: التهيئة الافتراضية تُعيد تشغيل الخدمات تلقائيًا بعد التحديثات. لخادم VPS عميل في الإنتاج، عطّل إعادة التشغيل التلقائية وجدوِل نافذة صيانة:\n\n```bash\n# في \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades\nUnattended-Upgrade::Automatic-Reboot \"false\";\n```",{"type":33,"title":140,"body":141},"للمزيد: التحصين المتقدم والمراقبة المستمرة","تُغطي هذه القائمة **المستوى الأول** من تصليب النظام. لمحفظة عملاء تتطلب مستوى أمانًا أعلى:\n\n- **خادم الاستقبال SSH (Bastion)**: مركزة جميع الوصول عبر نقطة دخول واحدة محصّنة — راجع \u003Ca href=\"\u002Fblog\u002Fheberger-bastion-host-vps\">Bastion Host على VPS\u003C\u002Fa>.\n- **CrowdSec**: كشف سلوكي وقائمة حجب مجتمعية كمكمّل أو بديل لـ fail2ban — راجع \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">تأمين VPS بـ CrowdSec\u003C\u002Fa>.\n- **النسخ الاحتياطية**: تهيئة الأمان لا تحمي من فقدان البيانات — راجع \u003Ca href=\"\u002Fblog\u002Fbackups-borgbackup-vps\">النسخ الاحتياطية بـ BorgBackup على VPS\u003C\u002Fa>.\n- **تصحيحات التطبيقات**: تصليب النظام لا جدوى منه إذا لم يُصان التطبيقات المستضافة ذاتيًا — راجع \u003Ca href=\"\u002Fblog\u002Froutine-correctifs-apps-self-hosted\">روتين التصحيحات للتطبيقات المستضافة ذاتيًا\u003C\u002Fa>.\n- **شهادات SSL**: HTTPS شرط مسبق قبل أي تعرض عمومي — راجع \u003Ca href=\"\u002Fblog\u002Fcertificats-ssl-lets-encrypt-vps\">شهادات SSL مع Let's Encrypt على VPS\u003C\u002Fa>.","ServOrbit تسلّم كل VPS جاهزًا لهذا الدليل","وصول فوري عبر SSH كمستخدم root وطرفية KVM مضمّنة عند التسليم: تطبّق وكالتك هذا الدليل منذ الاتصال الأول، لكل عميل، دون طلب وصول وسيط من المضيف. أدِر محفظة خوادم VPS عملائك بالكامل من لوحة تحكم وكالة مركزية.","‏ServOrbit تسلّم كل VPS","\u002Fsolutions\u002Fagences",[147,162,177],{"id":148,"slug":149,"slugs":150,"title":154,"excerpt":155,"readTime":156,"views":16,"isPinned":17,"publishedAt":157,"category":158,"categories":159,"featuredImage":27,"bgImage":28,"posterImage":161,"relatedSolution":27},116,"شهادات-ssl-مجانية-باستخدام-lets-encrypt-على-خادم-vps",{"fr":151,"en":152,"ar":149,"es":153},"certificats-ssl-lets-encrypt-vps","free-ssl-certificates-with-lets-encrypt-on-a-vps","certificados-ssl-gratis-con-lets-encrypt-en-un-vps","شهادات SSL مجانية باستخدام Let's Encrypt على خادم VPS","انشر Let's Encrypt على خادمك VPS: HTTPS مجاني، وتجديد تلقائي، وتقييم A+ على SSL Labs مع Nginx أو Caddy أو Traefik في Docker.",4,"2026-02-24T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},[160],{"id":20,"name":21,"slug":22,"color":23,"icon":24},"\u002Fblog\u002Fcovers\u002Fcertificats-ssl-lets-encrypt-vps-poster.svg",{"id":163,"slug":164,"slugs":165,"title":169,"excerpt":170,"readTime":171,"views":16,"isPinned":17,"publishedAt":172,"category":173,"categories":174,"featuredImage":27,"bgImage":28,"posterImage":176,"relatedSolution":27},278,"لوحة-إدارة-الخادم-الافتراضي-أسطح-الهجوم-المنسية",{"fr":166,"en":167,"ar":164,"es":168},"backoffice-vps-surfaces-attaque-oubliees-2026","exposed-backoffice-on-vps-the-overlooked-attack-surfaces","backoffice-expuesto-en-vps-superficies-de-ataque-olvidadas","لوحة إدارة الخادم الافتراضي: أسطح الهجوم المنسية","أربع ثغرات ‎CVE‎ في أغسطس 2026 تشترك في النمط ذاته: لوحة إدارة مكشوفة، حساب مخترق. المصادقة التطبيقية وحدها لا تكفي.",12,"2026-08-17T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},[175],{"id":20,"name":21,"slug":22,"color":23,"icon":24},"\u002Fblog\u002Fcovers\u002Fbackoffice-vps-surfaces-attaque-oubliees-2026-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":156,"views":16,"isPinned":17,"publishedAt":186,"category":187,"categories":188,"featuredImage":27,"bgImage":28,"posterImage":190,"relatedSolution":27},114,"نسخ-خادم-vps-الاحتياطية-المشفرة-باستخدام-borgbackup",{"fr":181,"en":182,"ar":179,"es":183},"backups-borgbackup-vps","encrypted-vps-backups-with-borgbackup","copias-de-seguridad-vps-con-borgbackup","نسخ خادم VPS الاحتياطية المشفّرة باستخدام BorgBackup","انسخ خادمك VPS احتياطيًا باستخدام BorgBackup: إزالة تكرار قوية، وتشفير موثَّق (authenticated)، وضغط. دليل كامل ومقارنة مع Restic.","2026-02-26T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},[189],{"id":20,"name":21,"slug":22,"color":23,"icon":24},"\u002Fblog\u002Fcovers\u002Fbackups-borgbackup-vps-poster.svg",1788100067580]