مركز المساعدة
62 نتائج
نعم، شهادة SSL مجانية من Let's Encrypt مشمولة مع استضافة الويب وتُجدَّد تلقائيًا. ويُفعَّل HTTPS بمجرد نشر الموقع.
نعم. إذا كنت بحاجة إلى شهادة ذات تحقّق موسَّع (EV) أو تحقّق من المؤسسة (OV)، فيمكنك تثبيتها على استضافتك. وفريق الدعم لدينا يساعدك في ذلك.
يمكن تفعيل إعادة التوجيه التلقائي من HTTP إلى HTTPS بنقرة واحدة من cPanel، لتقديم موقعك بالكامل بشكلٍ آمن.
تطبّق بنيتنا التحتية عزل الحسابات وجدارًا ناريًا وتحديثات منتظمة. وعلى خادم VPS، تبقى مسؤولية أمن بيئتك على عاتقك (ويمكننا تقديم المشورة لك).
نعم، عندما يستخدم نطاقك خدمة DNS المُدارة لدينا مع تفعيل الوكيل (proxy) على سجلّ موقعك: تمرّ حركة المرور حينئذٍ عبر شبكة Cloudflare التي تمتصّ هجمات DDoS على النطاق العالمي — الحماية نفسها التي تتمتّع بها أكبر مواقع الويب، مشمولة ودون تكلفة إضافية.
Cloudflare هي الشبكة التي تُسرّع وتحمي ما يقارب 20% من الويب العالمي. نربط نطاقك بها تلقائيًا ومجانًا: تحصل على شبكة CDN عالمية (موقع أسرع في كل مكان)، وحماية من هجمات DDoS، ونظام DNS من نوع anycast يتّسم بالمرونة، إضافةً إلى HTTPS — دون أي إجراء من جانبك.
حافظ على تحديث WordPress وقوالبه وإضافاته، واستخدم كلمات مرور قوية، وقيّد محاولات تسجيل الدخول، وفعّل SSL، وأجرِ نسخًا احتياطية منتظمة.
تواصل مع فريق الدعم لدينا دون تأخير: نرافقك لاستعادة نسخة احتياطية سليمة وتحديد الثغرة، تفاديًا لتكرار الحادثة.
شهادات Let's Encrypt صالحة لمدة 90 يومًا، مما يستوجب تجديدًا تلقائيًا كل 60 يومًا تقريبًا. على خوادم الاستضافة لدينا يتمّ هذا التجديد تلقائيًا دون أي تدخل منك. أصدر منتدى CA/B Forum خارطة طريق لتقصير المدة تدريجيًا: أولًا إلى 100 يوم، ثم إلى 47 يومًا بحلول 2029. إن كنت تدير شهادة على خادم خارج منصتنا، تأكّد من تحديث أداة الأتمتة (Certbot أو acme.sh) لتستوعب هذه المدد.
تتيح عملاء ACME مثل `certbot` و`acme.sh` وCaddy تجديد شهادات SSL تلقائيًا دون أي تدخل يدوي. تُثبّت معظم العملاء مؤقت systemd أو مهمة cron بشكل أصيل عند التثبيت. هذه الأتمتة باتت ضرورة ملحّة، إذ يعتزم منتدى CA/B تقليص مدة صلاحية الشهادات إلى 47 يومًا بحلول 2029.
يدمج Traefik بشكل أصيل عميل ACME متوافق مع Let's Encrypt. كل ما تحتاجه هو الإعلان عن محلّل في قسم `certificatesResolvers` من ملف `traefik.yml`، ثم إضافة الوسم `traefik.http.routers.<service>.tls.certresolver=<name>` لكل حاوية Docker تريد حمايتها. يتولى Traefik بعدها التفاوض على التحدي HTTP-01 أو DNS-01، وإصدار الشهادة وتجديدها تلقائيًا قبل انتهاء صلاحيتها. تُخزَّن الشهادات في ملف JSON مستمر (`acme.json`) يجب ربطه بحجم تخزين لتجنب فقدانها عند إعادة تشغيل الحاوية.
نعم. تتيح حلول مفتوحة المصدر مثل Authentik وAuthelia، المتوفّرة في متجر ServOrbit، مركزة المصادقة لجميع تطبيقاتك (Gitea وNextcloud وChatwoot…) عبر بوابة SSO/OIDC واحدة. تدير المستخدمين والصلاحيات والمصادقة الثنائية من واجهة موحّدة دون إعادة تكوين كل تطبيق على حدة. يُنصح بخطة VPS Power (4 نواة، 8 GB) لـAuthentik، أما Authelia فأخفّ استهلاكًا للموارد.
نعم، تعمل الاستضافة المشتركة في ServOrbit على نظام CloudLinux الذي يضمن عزلاً قوياً بين الحسابات. يعمل كل عميل داخل بيئة معزولة تُسمى LVE (Linux Virtual Environment): ملفاتك وعملياتك وموارد المعالج والذاكرة مفصولة تماماً عن تلك الخاصة بالعملاء الآخرين على نفس الخادم. لذا لا يمكن لموقع مجاور مخترق أو مُعد بشكل خاطئ الوصول إلى بياناتك أو التأثير في أدائك بشكل غير متناسب. يوفر هذا الهيكل طبقة حماية إضافية مقارنةً بالاستضافة المشتركة التقليدية التي لا تعتمد CloudLinux.
انشر Promtail على كل VPS تريد مراقبته: يجمع سجلات النظام (auth.log وsyslog وjournald) ويرسلها إلى نسخة Loki مركزية على VPS ثانٍ أو حاوية تخزين متوافقة. تتصل Grafana بـ Loki كمصدر بيانات وتتيح إنشاء تنبيهات عند محاولات تسجيل دخول فاشلة (sudo، SSH) أو أخطاء في التطبيقات. هذه المجموعة خفيفة — تعمل Loki وGrafana معاً على VPS ابتداءً من 99 درهم/شهر — وتحافظ على سريّة سجلاتك بعيداً عن خدمات الطرف الثالث.
نعم. يُنشئ Cloudflare Tunnel (المعروف سابقاً بـ Argo Tunnel) اتصالاً صادراً من VPS الخاص بك إلى شبكة Cloudflare، مما يتيح نشر تطبيق ويب عبر HTTPS دون فتح أي منفذ وارد — مثالي إذا كان VPS خاضعاً لجدار ناري صارم. يُثبَّت وكيل `cloudflared` على خادمك ويُدير الاتصال؛ يجب أن يكون نطاقك مُدار في Cloudflare. يشرح مقال مدونتنا المخصص الإعداد خطوةً بخطوة.
نعم، يمكنك توليد وتثبيت شهادة Let's Encrypt wildcard مجانية عبر Certbot باستخدام تحدي DNS-01، التي تغطي نطاقك الرئيسي وجميع نطاقاته الفرعية (*.example.com). على خادم مخصص أو VPS بصلاحيات root، العملية حرة تماماً من جانبنا. يمكنك أيضاً تثبيت شهادة wildcard تجارية (OV أو EV) تحصل عليها من جهة إصدار شهادات من اختيارك.
اكتُشفت ثغرتان حرجتان لتجاوز المصادقة الثنائية في Nextcloud في مايو 2026: CVE-2026-45690 (تجاوز عبر HTTP Basic Auth، CVSS 5.9) وCVE-2026-45691 (تجاوز عبر رمز Bearer DAV، CVSS 5.9). **الخطوة 1 — التحقق من إصدارك**: سجّل الدخول إلى Nextcloud كمسؤول، اذهب إلى **الإدارة → نظرة عامة** وتحقق من الإصدار المعروض. **الإصدارات المُصلَّحة**: Nextcloud 32.0.9 و33.0.3. ⚠️ Nextcloud 34.0.2 يحتوي على انحدار — لا تستخدمه. **الخطوة 2 — التحديث إذا لزم**: من واجهة الإدارة، اذهب إلى **الإدارة → نظرة عامة → التحقق من التحديثات** وطبّق آخر تحديث متاح. لمثيل Docker، غيّر وسم الصورة إلى `nextcloud:32.0.9-apache` وأعد تشغيل الحاوية. **الخطوة 3 — التحقق من تطبيق المصادقة الثنائية**: تأكد من تفعيل تطبيق TOTP أو الرسائل القصيرة في **الإدارة → الأمان** وأنه إلزامي لحسابات المسؤولين.
Authelia وكيلٌ خفيف للمصادقة (أقل من 30 MB من الذاكرة) يضيف طبقة 2FA وSSO عبر OIDC أمام تطبيقاتك من خلال وكيل عكسي (Traefik أو nginx). لا يدير دليل مستخدمين كاملاً ولا يدعم SAML 2.0. أما Authentik فهو منصة IAM (Identity and Access Management) متكاملة: تغطّي OIDC وSAML 2.0 وLDAP وSCIM وتوفير الحسابات تلقائيًا. تتطلّب VPS بذاكرة لا تقل عن 4 GB (4 حاويات: server وworker وPostgreSQL وRedis). عمليًا: استخدم Authelia لحماية 2 إلى 6 تطبيقات داخلية بـ2FA، وAuthentik إن احتجت SAML 2.0 أو ربط أكثر من خمسة تطبيقات أو توفير الحسابات تلقائيًا. كلاهما متاح في Marketplace ServOrbit.
تستغل ثغرات CVE ما بعد المصادقة نقاط ضعف يمكن الوصول إليها بعد تسجيل الدخول: حافظ على تحديث تطبيقاتك فور نشر أي تصحيح، وقيّد الوصول إلى واجهة الإدارة بالعنوان IP أو عبر وكيل عكسي مع مصادقة قوية. يتيح وضع WAF أمام لوحة التحكم حجب أنماط الاستغلال المعروفة.
منذ الإصدار 2026.4.1 من عملاء Bitwarden، لم تعد بعض واجهات التشفير الأقدم مقبولة من التثبيتات الجديدة: يُطبّق العميل الجديد فحوصات أكثر صرامة مقارنةً بالجلسات المفتوحة مسبقًا. تأكد من أن نسخة Vaultwarden لديك محدَّثة (صورة `vaultwarden/server:latest` أو إصدار حديث محدد) وأن الخادم الوكيل العكسي يُمرّر الترويسات بشكل صحيح — ولا سيما `X-Real-IP` و`X-Forwarded-For`. إذا استمرت المشكلة، افتح تذكرة من لوحة العملاء مرفقًا بها إصدار Vaultwarden (`docker inspect vaultwarden | grep -i version`) ورسالة الخطأ التي يعرضها العميل.
ضع وكيلًا عكسيًا (Traefik أو nginx) أمام نسخة Docmost وربط Authelia أو Authentik كـ middleware مصادقة. مع Traefik، أضف `forwardAuth` يشير إلى نقطة قرار Authelia. مع nginx، استخدم `auth_request`. Authentik متاح عبر متجر ServOrbit ويدعم OIDC وSAML 2.0 ورؤوس forward auth المتوافقة مع Traefik.
قبل الهجرة، صدّر قاعدة البيانات SQLite (`kuma.db`) واحفظها في مكان آمن — فهي المصدر الوحيد لمراقباتك وتنبيهاتك. يغيّر الإصدار 2 مخطط قاعدة البيانات: شغّل الحاوية الجديدة بنفس مجلد البيانات وسينفّذ Uptime Kuma الهجرات تلقائياً عند الإطلاق الأول. تحقق بعدها من نشاط كل مراقبة وعمل قنوات الإشعارات قبل حذف النسخة القديمة. يُصلح الإصدار 2 الثغرة CVE-2026-45618 (حقن عبر ترويسات HTTP) — التحديث موصى به.
تُنشئ شبكة شبكية (mesh) مبنية على WireGuard — مثل Netbird أو Tailscale — شبكة مشفرة نظير-إلى-نظير بين خوادم VPS الخاصة بك عبر اتصالات صادرة فحسب، دون كشف أي منفذ وارد على العنوان العام. تتولى عقدة التنسيق (STUN/TURN) اختراق NAT، ويسير الاتصال مباشرةً بين الأجهزة بمجرد إقامة النفق. هذا النهج مناسب لمجموعات قواعد البيانات والخدمات الداخلية وخطوط CI/CD التي يجب ألا تكون متاحة من الإنترنت.
CVE-2026-45672 ثغرة تنفيذ كود عن بعد في Open WebUI تطال الإصدارات قبل 0.6.10: يستطيع مهاجم مصادق عليه تنفيذ كود تعسفي على الخادم عبر آلية معالجة الملفات. تحقّق من إصدارك من واجهة الإدارة (الإعدادات ← حول) أو بالأمر: `docker inspect ghcr.io/open-webui/open-webui:latest | grep 'version'`. إن كنت دون 0.6.10، حدِّث فورًا: `docker compose pull && docker compose up -d`. في الأثناء، قيِّد الوصول إلى واجهتك بعنوان IP عبر الوكيل العكسي. تواصل مع [email protected] للحصول على مساعدة في التحديث.
يُعيد الوسم :latest كتابة مفتاح تشفير التضمينات (embeddings) في كل docker pull: فقدان لا رجعة فيه للوثائق المتجهة. احرص دائمًا على تثبيت إصدار ثابت (مثلاً v1.8.x) في docker-compose. المصدر: المشكلة #5256 على github.com/Mintplex-Labs/anything-llm.
يُشفِّر Passbolt كل إدخال بمفتاح GPG العام للمستلم. لا يستطيع الخادم ولا المسؤول قراءة كلمات المرور دون المفتاح الخاص لصاحبها. يُنجَز التشفير في المتصفح عبر امتداد Passbolt.
قبل الترقية، راجع سجل التغييرات الرسمي وقاعدة NVD/CVE بحثًا عن الثغرات المرتبطة بالإصدار المستهدف؛ إذ عالجت الفروع v4 ثغرات في معالجة رموز المصادقة. احرص على نسخ احتياطي كامل لقاعدة PostgreSQL والأحجام قبل أي تحديث، ثم اختبر على نسخة مستنسخة قبل الإنتاج. إن كنت غير متأكد من مستوى تعرُّض مثيلك، افتح تذكرة من فضائك العميل أو تواصل على [email protected].
**Let's Encrypt (مجاني)**: - شهادات **DV (التحقق من النطاق)** فقط: تُثبت أنك تتحكم في النطاق، لا هوية مؤسستك - صالحة 90 يوماً (تجديد تلقائي عبر certbot) - معترف بها من جميع المتصفحات الحديثة - مناسبة لغالبية المواقع - Wildcard متاح (عبر DNS-01): شهادة واحدة تغطي `*.نطاقك.com` **الشهادات المدفوعة**: - **OV (التحقق من المنظمة)**: تتحقق جهة الإصدار من الوجود القانوني لشركتك - **EV (التحقق الموسَّع)**: تحقق مكثف، كان يظهر سابقاً كشريط أخضر في المتصفحات (أُزيل من المتصفحات الحديثة عام 2019) - صالحة 1–2 سنة **لـ 99% من حالات الاستخدام، Let's Encrypt كافٍ.** شهادات EV/OV مفيدة للامتثال الداخلي أو عقود شركاء معينين أو قطاعات منظَّمة (بنوك، تأمين) تشترطها تعاقدياً.
اشترك في إصدارات Gitea على GitHub (github.com/go-gitea/gitea/releases) وفعّل الإشعارات. تُحدد كل إصدارة ما إذا كانت تصحح CVEs وخطورتها (CVSS). على VPS ServOrbit، التحديثات تتم عبر `docker compose pull && docker compose up -d` — احتفظ بنسخة احتياطية قبل أي تحديث رئيسي.
ابدأ بتصدير خزنة مشفَّرة من مديرك الحالي، تحقَّق من سلامتها قبل حذف الأصل، ثم انشر Vaultwarden أو Passbolt على VPS مخصَّص عبر HTTPS مع شهادة صالحة — يرفض عملاء Bitwarden الاتصالات غير المشفَّرة. فعِّل المصادقة الثنائية على جميع الحسابات منذ أول تسجيل دخول، وجدوِل التبديل خارج أوقات العمل، ولا تلغِ الوصول إلى الحل القديم إلا بعد أن يتحقق كل عضو من الفريق من الجديد. يمكن لفريق الدعم مساعدتك في إعداد TLS عبر [email protected].
راجع ملف `/var/log/auth.log` في أنظمة Debian/Ubuntu لرصد محاولات تسجيل الدخول الفاشلة (`Failed password`، `Invalid user`) والاتصالات الناجحة خارج أوقاتك المعتادة. يُدرج أمر `last` جلسات SSH الأخيرة مع الطابع الزمني وعنوان IP المصدر. للمراقبة المستمرة، يحجب `fail2ban` تلقائياً عناوين IP التي تراكم عليها كثير من الفشل، ويمكنك إعداد تنبيهات بالبريد الإلكتروني. إن تأكدت من وجود اتصال غير معروف، اقطع الجلسة فوراً بالأمر `pkill -u <user>`، ودوّر مفاتيح SSH، وافتح تذكرة دعم من فضائك الخاص.
للاستخدام الداخلي البحت — فريق العمل والمشاريع الداخلية دون تعريض الخدمة لأطراف خارجية — لا تفرض BSL وSSPL عموماً أي قيد، إذ لا تستهدف أيٌّ منهما الاستخدام الخاص. يُفعَّل قيد SSPL حين تقدّم البرنامج كخدمة للمستخدمين الخارجيين (SaaS)؛ وتحظر BSL تقديم خدمة تجارية تنافس المطوّر الأصلي. إذا كان عملاؤك يستخدمون الأداة، استشر محامياً قبل النشر. اشترك في إشعارات إصدارات GitHub للمشاريع التي تعتمد عليها لرصد أي تغيير في الترخيص مع كل إصدار رئيسي.
يتيح لك تحدي DNS-01 الحصول على شهادة عامة (`*.نطاقك.ma`) دون الحاجة إلى فتح منفذ HTTP: ينشئ Certbot سجل TXT باسم `_acme-challenge` في منطقة DNS الخاصة بك ليتحقق منه Let's Encrypt. إذا كان نطاقك مُدار عبر Cloudflare، فإن الإضافة `certbot-dns-cloudflare` تُؤتمِت هذه الخطوة برمز API محدود الصلاحيات (`Zone:DNS:Edit`). أضف مهمة cron أو مؤقت systemd لتشغيل `certbot renew` وإعادة تحميل nginx تلقائياً بعد كل تجديد. اختبر التجديد مسبقاً بخيار `--dry-run` قبل تفعيل المجدوِل.
يستمع PostgreSQL افتراضياً على المنفذ 5432؛ إذا كان هذا المنفذ متاحاً من الإنترنت، يستطيع أي شخص محاولة الاتصال به. تحقق من حالة الكشف بتشغيل `ss -tlnp | grep 5432` (أو `netstat`): إذا كان عنوان الاستماع `0.0.0.0` أو `::`، فالخدمة قابلة للوصول من الخارج. لتأمينها: اربط PostgreSQL بـ `127.0.0.1` في ملف `postgresql.conf` (السطر `listen_addresses = 'localhost'`)، وأغلق المنفذ بجدار الحماية (`ufw deny 5432`)، ولا تسمح بالوصول عن بُعد إلا عبر نفق SSH أو VPN. إذا احتجت مساعدةً لتصليب الإعداد، افتح تذكرة من منطقة العميل.
ابدأ بمراجعة سجلات Certbot باستخدام الأمر journalctl -u certbot أو بقراءة الملف /var/log/letsencrypt/letsencrypt.log لتحديد سبب الفشل. إذا كنت تستخدم اختبار HTTP-01، تحقق من أن المنفذ 80 متاح من الخارج وأن إعداد خادم الويب يعرض مجلد .well-known/acme-challenge/ بشكل صحيح. إذا كان المنفذ 80 محجوباً أو كنت بحاجة إلى شهادة wildcard، انتقل إلى اختبار DNS-01 باستخدام ملحق DNS المناسب لمزودك. لإجبار التجديد الفوري واختبار الإعداد، استخدم الأمر certbot renew --force-renewal.
تغطي شهادة SSL من نوع wildcard نطاقاً ما وجميع نطاقاته الفرعية من المستوى الأول، مثل *.example.com. تُصدر Let's Encrypt شهادات wildcard فقط عبر اختبار DNS-01، الذي يتطلب إنشاء سجل TXT في منطقة DNS الخاصة بك لإثبات ملكية النطاق. لأتمتة هذه العملية، استخدم Certbot مع ملحق DNS المناسب لمزود DNS لديك. ZeroSSL هو بديل لـLet's Encrypt يوفر أيضاً شهادات wildcard مجانية عبر اختبار DNS-01 ويتيح واجهة ويب لتسهيل الإصدار اليدوي.
عندما يكون نطاقك مُوكَّلاً عبر Cloudflare، قد يفشل تحدي HTTP-01 الخاص بـCertbot لأن Cloudflare يستجيب بدلاً من خادمك. استخدم بدلاً من ذلك تحدي DNS-01: ثبّت الإضافة `certbot-dns-cloudflare`، وأنشئ رمز API لـCloudflare بصلاحية `Zone:DNS:Edit`، ثم شغّل `certbot renew --dns-cloudflare --dns-cloudflare-credentials ~/cloudflare.ini`. يتم التجديد دون الحاجة إلى كشف أي منفذ ويعمل حتى لو كان خادمك غير قابل للوصول من الإنترنت. تذكر أتمتة التجديد عبر مهمة cron بالأمر `certbot renew` لتجنب أي انتهاء صلاحية مستقبلي.
يمكنك التحقق من تثبيت شهادة SSL وتاريخ انتهاء صلاحيتها مباشرةً من متصفحك: انقر على رمز القفل في شريط العنوان، ثم على «الاتصال آمن» لعرض تفاصيل الشهادة (الجهة المُصدِرة، النطاق المُغطَّى، الصلاحية). كما تتيح أدوات عبر الإنترنت مثل SSL Labs (ssllabs.com/ssltest) أو check-host.net إجراء تحليل معمّق (سلسلة الشهادات، الخوارزميات، التوافق). إذا كانت الشهادة مُدارة تلقائيًا بواسطة ServOrbit (Let's Encrypt)، فإن التجديد يتم دون الحاجة إلى أي تدخل من جانبك.
تستهدف هذه الثغرة نسخ Artifactory ذاتية الاستضافة التي تكشف بعض نقاط REST دون مصادقة. تحقق من الإصدار المثبت (الإدارة ← النظام ← التهيئة العامة) وطبّق التصحيح الوارد في ملاحظات الإصدار الرسمية لـ JFrog. في غضون ذلك، أغلق الوصول العام إلى منفذ الإدارة (8081/8082) عبر جدار حماية VPS أو الخادم المخصص في ServOrbit، وعطّل الوصول المجهول في إعدادات الأمان.
نعم، منذ Docker Compose v2.24 أصبحت Docker Secrets مدعومة بشكل أصلي بدون Swarm. تُعلن عن كتلة secrets في ملف docker-compose.yml مع الإشارة إلى ملف محلي: يُركّب Docker السر كملف مؤقت في المسار /run/secrets/<name> داخل الحاوية، دون كشفه في متغيرات البيئة أو في docker inspect. هذا هو الأسلوب الموصى به لحماية مفاتيح API وكلمات مرور قواعد البيانات والرموز المميزة على VPS بصلاحيات root. راجع دليلنا حول Docker Secrets في الإنتاج للأوامر الدقيقة وحدود كل أسلوب.
تتوفر ثلاثة أساليب على VPS بصلاحيات root: Docker Secrets (ملفات تُركَّب في /run/secrets/، بدون Swarm منذ Compose v2.24)، و.env.vault مع أداة dotenvx التي تُشفّر ملف .env وتكشف فقط مفتاح فك التشفير DOTENV_KEY، وSOPS الذي يُشفّر قيم ملف YAML أو .env باستخدام مفتاح age أو AWS KMS. في جميع الحالات، يجب ألا يُضمَّن ملف .env بصيغته العادية في Git. راجع دليلنا حول Docker Secrets في الإنتاج للأوامر والحدود الفعلية لكل أسلوب.
يُعدّ CVE-2026-87902 ثغرةً تتيح تنفيذ أكواد برمجية عن بُعد (RCE) في إصدارات WordPress السابقة للإصدار 7.1.2. إذا كان موقعك يعمل بإصدار أقدم، فهو معرّض للخطر. تحقق من الإصدار الحالي في لوحة تحكم WordPress ضمن قائمة التحديثات. لحماية موقعك، قم بالتحديث إلى الإصدار 7.1.2 أو أحدث عبر لوحة ServOrbit أو من إدارة WordPress مباشرةً.
بعد نشر ثغرة CVE، تقوم الروبوتات الآلية بمسح واسع للخوادم المكشوفة. على خادم VPS الخاص بك لدى ServOrbit، فعّل جدار الحماية المدمج لحظر نطاقات IP المشبوهة، وحدّث WordPress فوراً، وفكّر في إضافة ترخيص Imunify360 المتوفّر كخيار، والذي يوفّر جدار حماية للتطبيقات. ضع موقعك أيضاً خلف Cloudflare في وضع الوكيل (proxy) للاستفادة من الحماية من هجمات DDoS ومن تصفية إضافية على مستوى التطبيقات. يمكن لفريق الدعم لدينا مرافقتك في عملية الإعداد.
تأثرت إصدارات Dokploy 0.29.x بعدة ثغرات CVE حرجة تتيح رفع الصلاحيات وتنفيذ أكواد عن بُعد عبر Docker API. للتحقق من إصدارك، اتصل بالخادم عبر SSH ونفّذ `dokploy --version` أو راجع واجهة الإدارة. إذا كنت تستخدم 0.29.x، حدّث فوراً باستخدام `curl -sSL https://dokploy.com/install.sh | sh` أو اتبع ملاحظات الإصدار الرسمية. في انتظار التحديث، قيّد الوصول إلى منفذ الواجهة (افتراضياً 3000) على عناوين IP الموثوقة فقط عبر جدار الحماية.
نعم، يمكن لـ `unattended-upgrades` إعادة التشغيل تلقائيًا بعد تثبيت تحديث النواة إذا كان الخيار `Unattended-Upgrade::Automatic-Reboot` مُفعَّلًا في `/etc/apt/apt.conf.d/50unattended-upgrades`. هذا الخيار معطَّل افتراضيًا لتجنب الانقطاعات غير المخطط لها. يمكن تحديد وقت ثابت لإعادة التشغيل باستخدام `Unattended-Upgrade::Automatic-Reboot-Time`، مما يتيح جدولة إعادة التشغيل خارج أوقات الذروة. في بيئات الإنتاج الحرجة، يفضل كثير من المسؤولين إبقاء هذا الخيار معطَّلًا ومعالجة إعادة التشغيل يدويًا، مستعينين بـ `needrestart` لتحديد ما إذا كانت إعادة التشغيل ضرورية فعلًا.
توجد عدة طرق للتحقق من عمل `unattended-upgrades` بشكل صحيح. يسرد ملف السجل `/var/log/unattended-upgrades/unattended-upgrades.log` الحزم المثبَّتة خلال التشغيلات الأخيرة. أما الأمر `unattended-upgrades --dry-run --debug` فيحاكي التنفيذ دون إجراء أي تغييرات ويعرض ما سيُحدَّث. يسجّل الملف `/var/log/dpkg.log` كل عملية تثبيت حزمة مع طابعها الزمني. على الأنظمة الحديثة، يُظهر `systemctl status unattended-upgrades` حالة الخدمة. وأخيرًا، يُمكّنك `apt-get -s upgrade` مع التصفية على حزم الأمان من التحقق من عدم وجود تحديثات حرجة معلَّقة.
نعم، بشرط أن يُنشأ النطاق الفرعي عبر cPanel وأن يشير سجل DNS الخاص به إلى خادم استضافتك. حينئذٍ تُصدر Let's Encrypt شهادة لهذا النطاق الفرعي في غضون دقائق من إضافته، دون الحاجة إلى أي إجراء من جانبك. إذا كان النطاق الفرعي مستضافاً في مكان آخر أو غير محلول في DNS، فلا يمكن إصدار شهادة تلقائياً.
يكشف Qdrant بشكل افتراضي واجهته HTTP على المنفذ 6333 دون مصادقة. على خادم ServOrbit VPS، يجب دمج ثلاثة إجراءات. أولاً، حدّد مفتاح API في إعدادات Qdrant بإضافة `api_key: مفتاحك-السري` إلى ملف `config/production.yaml` أو باستخدام متغير البيئة `QDRANT__SERVICE__API_KEY`؛ وسيتعين على كل طلب تضمين الترويسة `api-key: مفتاحك-السري`. ثانياً، قيّد الوصول إلى المنفذ 6333 عبر UFW بالسماح فقط لعناوين IP الخاصة بتطبيقاتك (الخادم التطبيقي وخط الاستيعاب) وحجب الباقي. ثالثاً، لا تكشف Qdrant مباشرةً على الإنترنت دون خادم وكيل عكسي مشفر بـ TLS: ضع vhost خاصاً بـ nginx أمامه مع شهادة Let's Encrypt وأعِد توجيه اتصالات HTTPS إلى المنفذ المحلي 6333. يدمج قالب ServOrbit لـ Qdrant هذه الإجراءات الثلاثة بشكل افتراضي. لأي استفسار حول إعدادات الشبكة، تواصل مع [email protected].
يقع الامتثال لمتطلبات ملفات تعريف الارتباط — شريط الموافقة، وحجب النصوص البرمجية الخارجية قبل القبول، وسجل الموافقات — على عاتقك أنت بوصفك ناشر الموقع، بصرف النظر عن مزود الاستضافة. يوفر ServOrbit البنية التحتية الآمنة (HTTPS، عزل الحساب، النسخ الاحتياطية) دون التدخل في تعليمات برمجية واجهتك الأمامية. يمكنك دمج حل مفتوح المصدر مثل Klaro أو Cookie Consent على استضافتك أو VPS الخاص بك. لأي سؤال تقني، افتح تذكرة دعم من منطقة العميل.
تُمرِّر شبكة VPN الكلاسيكية كل الحركة عبر خادم بوابة مركزي: يتصل كل عميل بالخادم الذي يعيد توزيعها. أما شبكة VPN الشبكية (Tailscale/Headscale) فتُنشئ أنفاقاً مشفرة مباشرة بين كل زوج من النقاط (peer-to-peer) عبر بروتوكول WireGuard دون مرور الحركة بعقدة مركزية. النتيجة: لا عنق زجاجة مركزي، مع إدارة مفاتيح موزعة تلقائياً عبر كل نقاط الشبكة. Headscale هو الإصدار الذاتي الاستضافة لخادم تنسيق Tailscale.
تشترط المادة 21 من توجيه NIS2 اتخاذ تدابير أمنية ملائمة تشمل تشفير البيانات أثناء النقل، مما يجعل شهادة TLS صالحة إلزامية لأي نسخة مستضافة ذاتيًا ومعرّضة للإنترنت. على ServOrbit، يمكن لكل VPS الحصول على شهادة Let's Encrypt مجانية عبر واجهتنا أو مباشرةً عبر Certbot. لا تستوفي الشهادة المنتهية أو الموقّعة ذاتيًا متطلبات NIS2 وتُعرّض مؤسستك لعدم الامتثال.
نعم، صُمِّم Zitadel تحديداً لهذا الغرض: يمكنك إنشاء مشروع Zitadel واحد وتسجيل عدة تطبيقات (عملاء OIDC) فيه، كلٌّ منها يمثّل أحد التطبيقات الذاتية التي تريد حمايتها. يحصل كل تطبيق على معرّف عميل وسر خاصَّين مع نطاق أدوار وصلاحيات مميّز، مما يضمن عزلاً دقيقاً لحقوق الوصول. يمكن استضافة Zitadel ذاتياً على خادم VPS من ServOrbit نفسه خلف Traefik، مع تعيين نطاق فرعي مخصص له وإدارة شهادة TLS تلقائياً. تتيح التطبيقات المتوافقة مع OIDC (Gitea وPortainer وGrafana وn8n…) إعدادها في دقائق بإضافة رابط مزوّد Zitadel وبيانات اعتماد العميل. خطّط لذاكرة RAM لا تقل عن 2 غيغابايت لتشغيل مريح لـZitadel إذا كان يعمل جنباً إلى جنب مع خدمات أخرى على المضيف نفسه.
Wazuh منصة SIEM/XDR مفتوحة المصدر يمكنك تثبيتها على VPS من ServOrbit (الحد الأدنى الموصى به: 4 نوى و8 GB رام). يجمع Wazuh Manager التنبيهات من الوكلاء المنشورين على كل خادم تحت المراقبة، فيما يوفر لوحة OpenSearch Dashboards المدمجة رؤية لحظية لأحداث الأمان. تعرض ServOrbit Wazuh في متجرها للنشر بنقرة واحدة؛ للتثبيت اليدوي أو المساعدة في الإعداد تواصل مع [email protected].
لا تشترط الوكالة الوطنية لتقنين الاتصالات (ANRT) وجود شهادة SSL كشرط لتسجيل نطاق .ma، غير أن بروتوكول HTTPS أصبح متطلباً فعلياً تفرضه المتصفحات الحديثة ومحركات البحث التي تحجب الصفحات غير المشفرة أو تخفض ترتيبها. تتضمن جميع خطط الاستضافة في ServOrbit شهادة Let's Encrypt مجانية تُجدَّد تلقائياً. إذا كنت بحاجة إلى امتثال أكثر صرامة (RGPD أو NIS2 أو التزامات قطاعية)، يمكن تثبيت شهادات OV أو EV عند الطلب — تواصل معنا عبر نموذج الاتصال.
تؤدي حلقة الأعطال (CrashLoopBackOff) إلى إعادة تشغيل الحاوية على فترات متزايدة؛ وقد تتبادل سبر «ping container» بين حالتَي «متاح» و«غير متاح» دون إطلاق تنبيه إن كان حد التأكيدات منخفضاً. طوّر Uptime Kuma v2 آلية اكتشاف الحالات الوسيطة مقارنةً بالإصدار الأول — تحديث نسختك يُقلِّل هذا الخطر. للخدمات الحساسة، أضف فحص صحة HTTP على نقطة نهاية تطبيقية فعلية تتحقق من الحالة الداخلية للحاوية لا من مجرد إقلاعها.
نعم. Pocket ID هو مزوّد OIDC/OAuth 2.0: سجّل كل تطبيق كعميل منفصل في واجهة الإدارة (client ID + redirect URI)، ويصادق مستخدموك مرة واحدة للوصول إلى جميع التطبيقات المتوافقة مع OIDC. هذا النهج في SSO المركزي فعّال بشكل خاص لحماية مجموعة خدمات على نفس VPS أو عبر عدة خوادم ServOrbit تشترك في نطاق فرعي للمصادقة.
نعم، شهادات SSL من نوع OV (التحقق من المنظمة) وEV (التحقق الموسّع) متاحة في ServOrbit للشركات المغربية التي تمتلك رقم RC أو ICE ساري المفعول. تعرض هذه الشهادات اسم شركتك في تفاصيل الشهادة، مما يعزز ثقة الزوار، لا سيما لمواقع التجارة الإلكترونية أو البوابات المالية. تستلزم عملية التحقق تقديم وثائق رسمية (سجل تجاري، نظام أساسي)؛ خصص 3 إلى 5 أيام عمل. تواصل معنا على [email protected] لبدء الإجراءات.
ليس بالضرورة. تنقل توزيعات Debian وUbuntu وAlmaLinux وRocky Linux التصحيحات الأمنية إلى الإصدار الذي تحزّمه دون تغيير الرقم الأصلي: وحدها لاحقة الحزمة تتغير، ولا يكفي الرقم الذي يعرضه `nginx -v` للحكم. ابحث عن معرّف CVE المعلن في سجل تغييرات الحزمة المثبّتة (`apt changelog nginx` على Debian أو Ubuntu، و`rpm -q --changelog nginx` على AlmaLinux أو Rocky Linux)، أو راجع متتبّع الأمان الخاص بتوزيعتك — والطريقة نفسها تصلح لـ OpenSSH. على استضافة الويب أو استضافة الموزّع، هذا التحقق من مسؤوليتنا؛ أما على خادم VPS أو خادم مخصص، فهو من مسؤوليتك.
يغلق التحديث الثغرة لكنه لا يخبركم إن كانت قد استُغلّت قبل ذلك. إذا كان تطبيقكم معرّضاً للإنترنت خلال فترة الثغرة، فاعتبروا الأسرار الموجودة على الخادم (مفاتيح API وكلمات مرور قاعدة البيانات وملف البيئة) مقروءةً احتمالاً وجدّدوها، ثم راجعوا سجلات الوصول. وإذا شككتم في وقوع اختراق، فافتحوا تذكرة من مساحة العميل.
لا تكتفِ بالانتظار: فالإضافة المصابة بثغرة والتي لا تصحيح لها تبقى باباً مفتوحاً. خذ نسخة احتياطية، ثم عطّل الإضافة واحذفها (فالتعطيل وحده يترك ملفاتها غالباً في مكانها) واستبدلها بإضافة مماثلة ما زالت تُصان. وإذا بقي الموقع مكشوفاً، فابحث عن ملفات عُدّلت حديثاً وعن حسابات مدير غير معروفة، واستعد نسخة احتياطية سليمة إن وجدت شيئاً من ذلك. ويمكن لمدير ووردبريس في cPanel لديك (WP Toolkit) و[email protected] مساعدتك في فحص حالة الموقع.
اختاروا «Full (strict)» ما دام خادمكم يقدّم شهادة صالحة: عندها يشفّر Cloudflare أيضًا الجزء الواصل إلى الخادم الأصلي ويتحقق من شهادته. في وضع «Flexible» يتصل Cloudflare بالخادم الأصلي عبر HTTP؛ فإذا كان هذا الخادم يعيد توجيه HTTP إلى HTTPS تدور الطلبات في حلقة ويعرض المتصفح «تمت إعادة التوجيه مرات كثيرة». أما وضع «Full» دون «strict» فيقبل شهادة موقَّعة ذاتيًا أو منتهية: خصّصوه للتشخيص فقط. اضبطوا الوضع قبل تفعيل الوكيل (proxy) ثم اختبروا الموقع بعد كل تغيير.
في الاستضافة، الخادم والنظام من مسؤولية المستضيف، أما محتوى موقعك فيبقى من مسؤوليتك: نظام إدارة المحتوى والقوالب والإضافات وإصدار PHP المختار لكل نطاق. وهذه العناصر، لا الخادم، هي ما تستهدفه معظم الثغرات المعلن عنها في أنظمة إدارة المحتوى. يعرض لك مدير WordPress في cPanel (WP Toolkit) التحديثات المتاحة؛ طبّقها بعد أخذ نسخة احتياطية. وإن راودك شك في حالة موقعك فراسلنا على [email protected].
تصفّح مركز المساعدة والأسئلة الشائعة، أو تواصل مع فريقنا — معاودة اتصال أو WhatsApp أو بريد إلكتروني. الدعم بـالعربية والفرنسية والإنجليزية.
راسلنا على WhatsAppيُفتح في علامة تبويب جديدة