خوادم سحابية
جدار الحماية وإدارة الأمان لخوادم سحابية
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
إدارة الأمان وجدار الحماية للخادم السحابي
يأتي كل خادم KapsuleHost مزودًا بجدار حماية مُدار يرفض حركة المرور الواردة افتراضيًا، بالإضافة إلى حماية من هجمات القوة الغاشمة وجدار حماية تطبيقات الويب والتصحيحات الأمنية التلقائية، والتي يتم التحكم فيها جميعًا من صفحة واحدة في KPanel.
تم اختيار الإعدادات الافتراضية بحيث يكون الخادم الجديد آمنًا قبل أن تلمسه. ما تضيفه عادةً هو فقط المنافذ التي يحتاجها تطبيقك. يرشدك هذا الدليل عبر صفحة إدارة الخادم بالكامل، لأن جدار الحماية هو قسم واحد منها والأقسام الأخرى هي ما يوقفك عن الحاجة إلى جدار الحماية في المقام الأول.
فتح صفحة الإدارة
- قم بتسجيل الدخول إلى KPanel.
- انقر على Cloud Servers في الشريط الجانبي الأيسر، ثم انقر على خادمك.
- انقر على Management في أزرار الإجراء في أعلى الصفحة.
العنوان المباشر هو /cloud-servers/<server-id>/management. تصف الصفحة نفسها بأنها "Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."
إذا كان البانر يقول "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately"، فإن اللوحة لا يمكنها الوصول إلى الخادم الآن. إعداداتك محفوظة بالفعل، فهي لم تُطبق بعد. تحقق من أن الخادم قيد التشغيل وقابل للوصول.
سياسة جدار الحماية الافتراضية
يحدد قسم Firewall (UFW) السياسة في سطر واحد: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
في الممارسة العملية، هذا يعني:
- لا شيء يمكنه الوصول إلى خادمك من الإنترنت ما لم تسمح به قاعدة.
- المنفذ 22 مفتوح دائمًا، لذلك تغيير جدار الحماية لن يقفلك أبدًا من الجهاز.
- يتم فتح المنافذ التي يحتاجها مكدس التطبيق الخاص بك، مثل 80 و 443 لتطبيق ويب، تلقائيًا.
- حركة المرور الصادرة من الخادم غير مقيدة.
بدون قواعد مخصصة، يظهر القسم "No custom rules. Defaults: SSH + app-stack ports." هذه حالة صحية، وليست تكوينًا ناقصًا.
إضافة قاعدة مخصصة
أضف قاعدة عندما تشغل شيئًا على منفذ لا تغطيه السياسة الافتراضية: تطبيق Node على 3000، قاعدة بيانات تحتاج إلى الوصول المباشر على 5432، خادم ألعاب أو وسائط على منفذ UDP.
- افتح قسم Firewall (UFW).
- اكتب رقم Port في الحقل الأول. القيم الصحيحة هي من 1 إلى 65535.
- اختر TCP أو UDP.
- اختر Allow أو Deny.
- انقر على Add.
تظهر القاعدة في القائمة مع شارة ALLOW أو DENY والمنفذ والبروتوكول، على سبيل المثال 3000/tcp. يتم دفعها إلى الخادم عبر اتصال الإدارة في غضون ثوانٍ.
لإزالة قاعدة، انقر على X في نهاية صفها. إزالة قاعدة Allow تغلق هذا المنفذ مرة أخرى على الفور.
فتح منفذ قاعدة البيانات لكل الإنترنت هو أحد أكثر الطرق شيوعًا التي يتعرض بها الخادم للاختراق. قبل السماح بـ 3306 أو 5432 أو 6379 أو 27017، تساءل عما إذا كان الشيء الذي يتصل يمكنه الوصول إلى قاعدة البيانات عبر واجهة loopback الخاصة بالخادم أو شبكة خاصة بدلاً من ذلك. إذا كان يجب بحق أن يكون قابلاً للوصول من الخارج، فتأكد من أن الخدمة نفسها تتطلب مصادقة قوية وتشفيرًا.
أضف القاعدة أولاً، ثم ابدأ الخدمة. الخدمة التي تبدأ خلف منفذ مغلق تبدو معطلة بنفس الطريقة تمامًا كما لو فشل بدؤها، ويمكنك أن تضيع الكثير من الوقت في تصحيح الطبقة الخاطئة.
مكدسات التطبيقات
يخبر قسم App stack المنصة بنوع التطبيق الذي يعمل على هذا الخادم، حتى يمكن ضبط إعداد التقسية على ذلك. يؤدي تثبيت تطبيق من خلال اللوحة إلى ضبط هذا تلقائيًا.
مكدسات معترف بها هي WordPress و WooCommerce و Ghost و Nextcloud و GitLab و Mattermost و Generic web و No app stack. يشرح القسم نفسه بأنه: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
يؤثر المكدس على المنافذ التي تُفتح تلقائيًا وكيف يتم ضبط الحماية الأخرى، بشكل واضح في fail2ban.
fail2ban
يراقب fail2ban محاولات المصادقة ويحظر العناوين التي تستمر في الفشل. يكون قيد التشغيل بشكل افتراضي والصفحة تصفه بأنه: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
اتركه قيد التشغيل. إنها أرخص حماية على الصفحة، لا تكلف شيئًا في الأداء، وتحول ضوضاء الخلفية المستمرة لمحاولات تخمين كلمات المرور إلى لا شيء على الإطلاق. على مكدس WordPress أو WooCommerce فإنه يحمي أيضًا نموذج تسجيل الدخول، وهو المكان الذي تهبط فيه معظم الهجمات على WordPress بالفعل.
ModSecurity، جدار حماية تطبيقات الويب
يفحص ModSecurity طلبات HTTP مقابل مجموعة OWASP Core Rule Set ويشير إلى تلك التي تبدو وكأنها هجمات. على خادم KapsuleHost يبدأ في وضع الكشف فقط: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
وضع الكشف فقط هو نقطة البداية الصحيحة. مجموعة القواعد الأساسية شاملة جدًا، وعلى تطبيق حقيقي ستطابق بعض الطلبات المشروعة قاعدة. قم بتشغيله في وضع الكشف فقط لفترة من الوقت، اقرأ السجلات، اكتشف القواعد التي تؤدي إليها حركة المرور الخاصة بك، وعندها فقط انتقل إلى الحظر داخل الخادم.
تشغيل الحظر بدون ضبط أولاً قد يعطل موقعك. إرسالات النماذج بنص غني وتحميلات الملفات وعملاء API برسائل غير عادية هي الضحايا المعتادة. تحقق من السجلات قبل التبديل.
التصحيح التلقائي لنظام التشغيل
يتم تطبيق التحديثات الأمنية لك تلقائيًا. يشرح القسم شبكة الأمان: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."
يوجد إعدادان تحت المبدل:
- السماح بإعادة التشغيل التلقائية عند الحاجة إلى تحديث kernel (فقط أثناء ساعات هادئة أدناه). تحديثات Kernel تأتي حيز التنفيذ بعد إعادة التشغيل فقط. إذا تركت هذا معطلاً، يتم تثبيت تصحيحات kernel لكنها غير نشطة حتى تقوم بإعادة التشغيل بنفسك.
- نافذة هادئة (UTC)، ساعة البداية والنهاية. تحدث إعادات التشغيل فقط بداخلها. اضبطها على أهدأ الساعات لجمهورك، وتذكر أن الحقل بصيغة UTC، وليس وقتك المحلي.
اترك التصحيح التلقائي قيد التشغيل. الأغلبية الساحقة من الخوادم المخترقة تعمل بواسطة برنامج يحتوي على تصحيح تم نشره قبل أسابيع. لقطة ما قبل التصحيح مع الاستعادة التلقائية تعني أن الاعتراض المعتاد، بأن التحديث قد يعطل شيئًا ما، يتم التعامل معه بالفعل.
سجل التصحيحات وتشغيل تصحيح الآن
يسرد قسم Patch history كل عملية تشغيل برسالة حالة RUNNING أو SUCCESS أو ROLLED_BACK أو FAILED أو SKIPPED، وعدد الحزم المحدثة، وما إذا كان الخادم يعيد التشغيل، والوقت الذي بدأ فيه.
للتصحيح على الفور بدلاً من الانتظار في الجدول الزمني، انقر على Run patch now. يقرأ التأكيد: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
يعني إدخال ROLLED_BACK أن شبكة الأمان قامت بعملها: لم يعود الخادم بشكل نظيف بعد إعادة التشغيل، لذلك تم استعادة لقطة ما قبل التصحيح. انظر Cloud Server Snapshots لمعرفة كيفية عمل تلك اللقطات.
خط أساس معقول
بالنسبة لمعظم الخوادم، هذا هو التكوين الأمني بالكامل:
| الإعداد | الموصى به |
|---|---|
| جدار الحماية | مفعّل، القواعد الافتراضية، بالإضافة إلى المنافذ التي يحتاجها تطبيقك فقط |
| fail2ban | مفعّل |
| ModSecurity | مفعّل، الكشف فقط حتى تقرأ السجلات |
| التصحيح التلقائي لنظام التشغيل | مفعّل، مع السماح بإعادة التشغيل في نافذة هادئة |
| مصادقة SSH | المفاتيح، وليس كلمات المرور |
الصف الأخير ليس على هذه الصفحة لكنه يهم أكثر من باقي الصفحة مجتمعة. انظر Connecting to Your Cloud Server With SSH.
استكشاف الأخطاء
"Could not load management config." لم تتمكن اللوحة من قراءة الإعدادات لهذا الخادم. أعد التحميل، وتحقق من أن الخادم موجود وتم توفيره.
"Port must be 1-65535." يأخذ حقل المنفذ رقمًا صحيحًا في هذا النطاق. النطاقات وأسماء الخدمات غير مقبولة هنا.
تم حفظ قاعدتي لكن لم يتغير شيء. ابحث عن بانر "Live apply unavailable". إذا كان يظهر، التغيير مخزن لكن لم يتم دفعه إلى الخادم حتى الآن.
يمكنني الوصول إلى خدمتي من شبكة واحدة لكن ليس من شبكة أخرى. هذا عادةً جدار الحماية الصادر الخاص بك، وليس الخادم. اختبر من اتصال مختلف قبل تغيير القواعس هنا.
تظهر عملية تصحيح FAILED. اقرأ رسالة الخطأ على الصف. امتلاء القرص هو السبب الأكثر شيوعًا. أفسح بعض المساحة وانقر على Run patch now.
بدأ حظر حركة المرور المشروعة. إذا قمت بتبديل ModSecurity إلى وضع الحظر، أرجعه إلى الكشف فقط، اقرأ السجلات، وحدد القاعدة قبل المحاولة مرة أخرى.
إذا رفضت قاعدة جدار الحماية التطبيق، أو تم قفلك من خدمة سمحت بها، أرسل بريدًا إلى support@kapsulehost.com مع اسم الخادم والمنفذ وما تتوقع الوصول إليه.