الترقية إلى إصدار أحدث من صورة العقدة السحابية لـ EOL¶

توضح هذه التعليمات الخطوات التي يجب اتخاذها لترقية صورة العقدة السحابية التي تم الاستغناء عنها (الإصدار 3.6 والإصدارات الأقل) المنشورة على AWS أو GCP إلى 4.10.

متطلبات¶

• الوصول إلى الحساب بدور المدير في واجهة Wallarm عبر السحابة الأمريكية أو السحابة الأوروبية

• الوصول إلى https://us1.api.wallarm.com عند العمل مع سحابة Wallarm الأمريكية أو إلى https://api.wallarm.com عند العمل مع سحابة Wallarm الأوروبية. يُرجى التأكد من عدم حجب الوصول بواسطة جدار الحماية

الخطوة 1: التواصل مع الدعم الفني لـ Wallarm بأنك تقوم بترقية الوحدات النمطية للعقدة الفلترة (فقط إذا كنت تقوم بترقية العقدة الإصدار 2.18 أو الإصدار الأقل)¶

إذا كنت تقوم بترقية العقدة 2.18 أو الإصدار الأقل، يرجى إعلام الدعم الفني لـ Wallarm بأنك تقوم بترقية وحدات العقدة الفلترة إلى الإصدار الأخير وطلب تمكين منطق القائمة الشبكية IP الجديدة لحسابك في Wallarm. عند تمكين منطق قائمة IP الجديدة، يرجى التأكد من اتاحة القسم قوائم IP في لوحة التحكم Wallarm.

الخطوة 2: تعطيل وحدة التحقق من التهديد النشط (فقط في حال ترقية العقدة 2.16 أو الإصدارات الأقل)¶

إذا كنت تقوم بترقية العقدة Wallarm 2.16 أو الإصدار الأقل، يرجى تعطيل وحدة التحقق من التهديد النشط في لوحة التحكم Wallarm → الثغرات الأمنية → تكوين.

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

الخطوة 3: تحديث بوابة واجهة برمجة التطبيقات¶

Starting with version 4.0, the filtering node uploads data to the Cloud using the us1.api.wallarm.com:443 (US Cloud) and api.wallarm.com:443 (EU Cloud) API endpoints instead of us1.api.wallarm.com:444 and api.wallarm.com:444.

If you upgrade the node from the version 3.x or lower and your server with the deployed node has a limited access to the external resources and the access is granted to each resource separately, then after upgrade the synchronization between the filtering node and the Cloud will stop.

To restore the synchronization, in your configuration, change port 444 to 443 for API endpoint for each resource.

الخطوة 4: مراجعة أحدث التحديثات الهندسية¶

قدم التحديث الأخير تغييرات في الهندسة المعمارية قد يتأثر بها المستخدمون، خاصة الذين يقومون بتغيير ملفات التكوين الافتراضية للعقدة. يرجى التعرف على هذه التغييرات لضمان التكوين الصحيح واستخدام الصورة الجديدة بشكل صحيح.

الخطوة 5: إطلاق عُقدة فلترة جديدة مع الإصدار 4.10¶

نسخ إعدادات معالجة وتوكيل الطلبات من ملفات التكوين التالية لإصدار العقدة Wallarm السابق إلى ملفات العقدة الفلترة 4.10:

1. افتح صورة العقدة الفلترة Wallarm على سوق النظام السحابي وانتقل إلى إطلاق الصورة:

   • سوق أمازون
   • سوق GCP

2. في خطوة الإطلاق، قم بتعيين الإعدادات التالية:

   • اختر نسخة الصورة 4.10.x
   • لـ AWS، حدد المجموعة الأمنية المنشأة في حقل إعدادات المجموعة الأمنية
   • لـ AWS، حدد اسم الزوج المفتاح المنشأ في حقل إعدادات الزوج المفتاح

3. قم بتأكيد إطلاق العُقدة.

4. لـ GCP، قم بتكوين العُقدة وفقًا لهذه التعليمات.

الخطوة 6: ضبط إعدادات نمط التصفية للعقدة Wallarm لتكون متوافقة مع التغييرات المفعلة في الإصدارات الأخيرة (فقط في حال ترقية العقدة 2.18 أو الإصدارات الأقل)¶

1. تأكد من أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع المنطق المتغير لأوضاع التصفية off و monitoring:

   • موجهة wallarm_mode
   • قاعدة التصفية العامة المكونة في لوحة التحكم Wallarm
   • قواعد التصفية الموجهة للنقطة النهائية المكونة في لوحة التحكم Wallarm

2. إذا لم يكن السلوك المتوقع يتوافق مع منطق نمط التصفية المتغير، يرجى ضبط إعدادات نمط التصفية لتكون متوافقة مع التغييرات المفعلة باستخدام التعليمات.

الخطوة 7: ربط العقدة الفلترة بـ Wallarm Cloud¶

1. قم بالاتصال بالعُقدة الفلترة عبر SSH. تتوفر تعليمات أكثر تفصيلاً حول الاتصال بالعُقدة في وثائق النظام السحابي:

   • وثائق AWS
   • وثائق GCP

2. قم بإنشاء عُقدة Wallarm جديدة وربطها بـ Wallarm Cloud باستخدام الرمز المستخدم كموضح في التعليمات الخاصة بالنظام السحابي:

   • AWS
   • GCP

الخطوة 8: نسخ إعدادات العقدة الفلترة من الإصدار السابق إلى الإصدار الجديد¶

1. قم بنسخ إعدادات معالجة وتوكيل الطلبات من ملفات التكوين التالية لإصدار العقدة السابق من Wallarm إلى ملفات العقدة الفلترة 4.10:

   • /etc/nginx/nginx.conf وغيرها من الملفات ذات الإعدادات NGINX

   • /etc/nginx/conf.d/wallarm-status.conf مع إعدادات خدمة مراقبة العقدة الفلترة

     تأكد من أن محتويات الملفات المنسوخة تتوافق مع التكوين الآمن الموصى به.

   • /etc/environment بالمتغيرات البيئية

   • أي ملفات تكوين أخرى مخصصة لمعالجة وتوكيل الطلبات، مع مراعاة التغييرات الهندسية الحديثة

2. قم بإعادة تسمية الأوامر التالية لـ NGINX إذا تم تحديدها بوضوح في ملفات التكوين:

   • wallarm_instance → wallarm_application
   • wallarm_local_trainingset_path → wallarm_custom_ruleset_path
   • wallarm_global_trainingset_path → wallarm_protondb_path
   • wallarm_ts_request_memory_limit → wallarm_general_ruleset_memory_limit

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

3. إذا تم تكوين تنسيق السجل الموسع، يرجى التحقق مما إذا كان المتغير wallarm_request_time محددًا بوضوح في التكوين.

   إذا كان الأمر كذلك، يرجى تغيير اسمه إلى wallarm_request_cpu_time.

   لقد قمنا فقط بتغيير اسم المتغير، مع الحفاظ على المنطق الأصلي. يتم دعم الاسم القديم مؤقتًا أيضًا، ولكن يفضل بعد ذلك تغيير اسم المتغير.

4. إذا كنت تقوم بترقية العقدة الإصدار 2.18 أو الإصدارات الأقل، قم بـالترحيل من الإصدار السابق لـ Wallarm إلى الإصدار 4.10.

5. إذا كان الكود &/usr/share/nginx/html/wallarm_blocked.html يتم إرجاعه للطلبات المحظورة، قم بنسخ وتخصيص الإصدار الجديد.

   في الإصدار الجديد للعُقدة، تم تغيير الصفحة النموذجية لحظر Wallarm. الشعار والبريد الإلكتروني للدعم المباشر على الصفحة الآن فارغة بشكل افتراضي.

معلومات مفصلة حول العمل مع ملفات التكوين الخاصة بـ NGINX متاحة في وثائق NGINX الرسمية.

قائمة توجيهات العقدة الفلترة متاحة هنا.

الخطوة 9: الانتقال من التكوين المباشر لكشف الهجمات overlimit_res إلى تحديده بالواعي للقواعد¶

Starting from the version 3.6, you can fine-tune the overlimit_res attack detection using the rule in Wallarm Console.

Earlier, the wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives have been used. The listed directives are considered to be deprecated with the new rule release and will be deleted in future releases.

If the overlimit_res attack detection settings are customized via the listed directives, it is recommended to transfer them to the rule as follows:

1. Open Wallarm Console → Rules and proceed to the Limit request processing time rule setup.

2. Configure the rule as done via the NGINX directives:

   • The rule condition should match the NGINX configuration block with the wallarm_process_time_limit and wallarm_process_time_limit_block directives specified.

   • The time limit for the node to process a single request (milliseconds): the value of wallarm_process_time_limit.

     Risk of running out of system memory

     The high time limit and/or continuation of request processing after the limit is exceeded can trigger memory exhaustion or out-of-time request processing.

   • The node will either block or pass the overlimit_res attack depending on the node filtration mode:

     • In the monitoring mode, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
     • In the safe blocking mode, the node blocks the request if it is originated from the graylisted IP address. Otherwise, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
     • In the block mode, the node blocks the request.

3. Delete the wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives from the NGINX configuration file.

   If the overlimit_res attack detection is fine-tuned using both the directives and the rule, the node will process requests as the rule sets.

الخطوة 10: إعادة تشغيل NGINX¶

أعد تشغيل NGINX لتطبيق الإعدادات:

sudo systemctl restart nginx

الخطوة 11: اختبار تشغيل العقدة Wallarm¶

1. Send the request with test Path Traversal attack to a protected resource address:

   curl http://localhost/etc/passwd
   

   If traffic is configured to be proxied to example.com, include the -H "Host: example.com" header in the request.

2. Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.

   

3. Optionally, test other aspects of the node functioning.

الخطوة 12: إنشاء صورة الجهاز الافتراضي استنادًا إلى العقدة الفلترة 4.10 في AWS أو GCP¶

لإنشاء صورة الجهاز الافتراضي استنادًا إلى العقدة الفلترة 4.10، يُرجى اتباع التعليمات المُناسبة لـ AWS أو GCP.

الخطوة 13: حذف المثيل السابق لعقدة Wallarm¶

إذا تم تكوين الإصدار الجديد من العقدة الفلترة بنجاح وتم اختباره، فعليك إزالة المثيل والصورة الظاهرة للجهاز بها الإصدار السابق من العقدة الفلترة بإستخدام واجهة التحكم AWS أو GCP.

الخطوة 14: إعادة تمكين وحدة التحقق من التهديد النشط (فقط في حال ترقية العقدة 2.16 أو الإصدارات الأقل)¶

اطلع على التوصية حول إعداد وحدة التحقق من التهديد النشط وأعد تمكينها إذا لزم الأمر.

بعد فترة، تأكد من أن تشغيل الوحدة لا يتسبب في تحذيرات إيجابية زائفة. في حالة اكتشاف تحذيرات إيجابية زائفة، يُرجى الاتصال بـ الدعم الفني لـ Wallarm.

هل كانت هذه الصفحة مفيدة؟

كيف يمكننا تحسين هذه المقالة؟ (خياري)

المعلومات غير واضحة أو محيرة

معلومات غير كافية

معلومات قديمة أو غير صحيحة

0/240

يرسل