خيارات الإعداد لعقدة Wallarm المبنية على NGINX¶

تعلم خيارات التعديل المتاحة للوحدات Wallarm الخاصة بNGINX للحصول على أقصى استخدام من حل Wallarm.

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

توجيهات Wallarm¶

disable_acl¶

تتيح تعطيل تحليل أماكن المشتقات للطلبات. إذا تم تعطيلها (on)، لن يقوم العقدة الفرعية بتحميل قوائم IP من سحابة Wallarm وستتجاهل تحليل مصادر IPs للطلب.

wallarm_acl_access_phase¶

تجبر التوجيه عقدة Wallarm المبنية على NGINX على حجب الطلبات الواصلة من IPs مدرجة في القائمة السوداء في مرحلة الوصول إلى NGINX وهذا يعني:

• بواسطة wallarm_acl_access_phase on، ستحجب عقدة Wallarm فورًا أي طلبات من IPs مدرجة في القائمة السوداء في أي وضع تصفية ولن تبحث عن علامات هجوم في الطلبات من IPs المدرجة في القائمة السوداء.

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

• بواسطة wallarm_acl_access_phase off، ستحلل عقدة Wallarm الطلبات للعثور على علامات الهجوم أولًا ثم إذا كانت تعمل في وضع block أو safe_blocking ستحجب الطلبات القادمة من IPs مدرجة في القائمة السوداء.

  في وضع التصفية off، لا تقوم العقدة بتحليل الطلبات ولا تتحقق من القوائم السوداء.

  في وضع التصفية monitoring، تبحث العقدة عن علامات الهجوم في جميع الطلبات ولكنها أبدًا لن تحجبها حتى لو كانت IP المصدر مدرجة في القائمة السوداء.

  سلوك عقدة Wallarm عند wallarm_acl_access_phase off يزيد بشكل كبير من حمل وحدة المعالجة المركزية للعقدة.

wallarm_acl_export_enable¶

تتيح التوجيه تمكين on / تعطيل off إرسال الإحصائيات حول الطلبات من IPs مدرجة في القائمة السوداء من العقدة إلى السحابة.

• مع wallarm_acl_export_enable on سيتم عرض الإحصائيات على الطلبات من IPs المدرجة في القائمة السوداء في قسم الهجمات.

• مع wallarm_acl_export_enable off لن يتم عرض الإحصائيات حول الطلبات من IPs المدرجة في القائمة السوداء.

wallarm_api_conf¶

مسار إلى ملف node.yaml، الذي يحتوي على متطلبات الوصول لواجهة برمجة التطبيقات API الخاصة بـ Wallarm.

مثال:

wallarm_api_conf /etc/wallarm/node.yaml

# تثبيتات صور Docker المبنية على NGINX ، صور السحابة وجميع التثبيتات في حالة واحدة
# wallarm_api_conf /opt/wallarm/etc/wallarm/node.yaml

تُستخدم لتحميل طلبات مسلسلة مباشرةً من العقدة الفرعية إلى واجهة برمجة التطبيقات API لـ Wallarm (السحابة) بدلاً من تحميلها في وحدة postanalytics (Tarantool).

يتم إرسال الطلبات التي تحتوي على هجمات فقط إلى واجهة برمجة التطبيقات API. لا يتم حفظ الطلبات دون هجمات.

مثال على محتوى ملف node.yaml:

# بيانات اعتماد الاتصال بواجهة برمجة التطبيقات API

hostname: <بعض الأسماء>
uuid: <بعض uuid>
secret: <سر بعض>

# معلمات الاتصال بواجهة برمجة التطبيقات API (المعلمات أدناه تُستخدم افتراضيًا)

api:
  host: api.wallarm.com
  port: 443
  ca_verify: true

wallarm_application¶

معرف فريد للتطبيق المحمي المراد استخدامه في سحابة Wallarm. يمكن أن تكون القيمة عدد صحيح موجب باستثناء 0.

يمكن تعيين معرفات فريدة لكلاً من نطاقات التطبيق ومسارات النطاق، على سبيل المثال:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 1;
    location / {
            proxy_pass http://example.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 2;
    location / {
            proxy_pass http://test.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    location /login {
            proxy_pass http://example.com/login;
            include proxy_params;
            wallarm_application 3;
    }

    location /users {
            proxy_pass http://example.com/users;
            include proxy_params;
            wallarm_application 4;
    }
}

المزيد من التفاصيل عن إعداد التطبيقات →

wallarm_block_page¶

تتيح لك إعداد الرد على الطلب المحجوب.

مزيد من التفاصيل حول تكوين صفحة الحجب ورمز الخطأ→

wallarm_block_page_add_dynamic_path¶

يُستخدم هذا التوجيه لتهيئة صفحة الحجب التي لديها متغيرات NGINX في كودها والمسار إلى هذه الصفحة المحجوبة المُعينة أيضا باستخدام المتغير. خلاف ذلك، لا يُستخدم التوجيه.

مزيد من التفاصيل حول تكوين صفحة الحجب ورمز الخطأ→

wallarm_cache_path¶

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

wallarm_custom_ruleset_path¶

مسار إلى الملف المجموعة القاعدية المخصصة التي تحتوي على معلومات حول التطبيق المحمي وإعدادات العقدة الفرعية.

wallarm_enable_libdetection¶

تمكين/تعطيل التحقق الإضافي من الهجمات SQL Injection عبر مكتبة libdetection. استخدام libdetection يضمن الكشف المزدوج عن الهجمات ويقلل من عدد الإيجابيات الكاذبة.

تحليل الطلبات بمكتبة libdetection مُمكّن بشكل افتراضي في جميع خيارات الإنشاء. لتقليل عدد الإيجابيات الكاذبة، نوصي بالمحافظة على تمكين التحليل.

المزيد من التفاصيل على libdetection →

wallarm_fallback¶

مع القيمة المُعيَّنة كـ on، لدى NGINX القدرة على الدخول في وضع الطوارئ؛ إذا لم يتمكن من تنزيل بروتون.دي بي أو مجموعة القواعد المخصصة، يعطل هذا الإعداد وحدة Wallarm للـ blocks http، server، و location، الذين فشلت البيانات في التنزيل. NGINX يستمر في العمل.

wallarm_force¶

تعيين تحليل الطلبات وتوليد القواعد المخصصة استنادًا إلى حركة المرور المتناظرة لـ NGINX. انظر تحليل حركة المرور المتناظرة مع NGINX.

wallarm_general_ruleset_memory_limit¶

تعيين حد للكمية القصوى من الذاكرة التي يمكن استخدامها بواسطة نسخة واحدة من بروتون.دي بي وملف مجموعة القواعد المخصصة.

إذا تم تجاوز الحد المعيَّن خلال معاللجة بعض الطلبات، سيلغى المستخدم الخطأ 500.

يمكن استخدام اللاحقات التالية في هذا المعلم:

• k أو K للكيلوبايت

• m أو M لميغابايت

• g أو G لجيغابايت

قيمة 0 توقف الحد.

wallarm_global_trainingset_path¶

wallarm_file_check_interval¶

تعرف فاستقة بين فحص البيانات الجديدة في بروتون.دي بي وملف مجموعة القواعد المخصصة. تحدد وحدة القياس في اللاحقة على النحو التالي:

• لا لاحقة للدقائق

• s للثواني

• ms للمللي ثانية

wallarm_instance¶

wallarm_key_path¶

مسار إلى المفتاح الخاص الخاص بـ Wallarm المُستخدم لتشفير / فك تشفير ملفات بروتون.دي بي ومجموعة القواعد المخصصة.

wallarm_local_trainingset_path¶

wallarm_memlimit_debug¶

هذا التوجيه يحدد ما إذا كانت وحدة Wallarm NGINX تولد ملف /tmp/proton_last_memlimit.req الذي يحتوي على تفاصيل الطلب عند تجاوز حد الذاكرة. يمكن أن يكون هذا لا غنى عنه لتصحيح مشكلات المعالجة المتعلقة بحد ذاكرة الطلب.

wallarm_mode¶

وضع معالجة حركة المرور:

• off

• monitoring

• safe_blocking

• block

يمكن تقييد استخدام wallarm_mode بواسطة التوجيه wallarm_mode_allow_override.

تعليمات تفصيلية حول تكوين وضع التصفية →

wallarm_mode_allow_override¶

تدير القدرة على تجاوز قيم wallarm_mode عبر قواعد الفلترة التي تم تنزيلها من سحابة Wallarm (مجموعة القواعد المخصصة):

• off - يتم تجاهل القواعد المخصصة.
• strict - يمكن للقواعد المخصصة فقط تقوية وضع التشغيل.
• on - من الممكن تقوية وتخفيف وضع التشغيل.

على سبيل المثال، مع wallarm_mode monitoring و wallarm_mode_allow_override strict مُعيّنين، يمكن استخدام Wallarm Console لتمكين حجب بعض الطلبات، ولكن لا يمكن تعطيل تحليل الهجوم بالكامل.

تعليمات تفصيلية حول تكوين وضع التصفية →

wallarm_parse_response¶

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

القيم الممكنة هي on (تحليل الاستجابة مُمكّن) و off (تحليل الاستجابة معطل).

wallarm_parse_websocket ¶

يوفر Wallarm الدعم الكامل لـ WebSockets تحت خطة الاشتراك في الأمان API. بشكل افتراضي، رسائل WebSockets لا يتم تحليلها للهجمات.

لإرغام الميزة، قم بتنشيط خطة الاشتراك في الأمان API واستخدم التوجيه wallarm_parse_websocket.

القيم الممكنة:

• on: تحليل الرسائل مُمكّن.
• off: تحليل الرسائل معطل.

wallarm_parser_disable¶

يتيح تعطيل المحلل. تتوافق قيم التوجيه مع اسم المحلل الذي سيتم تعطيله:

• cookie
• zlib
• htmljs
• json
• multipart
• base64
• percent
• urlenc
• xml
• jwt

مثال

wallarm_parser_disable base64;
wallarm_parser_disable xml;
location /ab {
    wallarm_parser_disable json;
    wallarm_parser_disable base64;
    proxy_pass http://example.com;
}
location /zy {
    wallarm_parser_disable json;
    proxy_pass http://example.com;
}

wallarm_proton_log_mask_master¶

إعدادات لتسجيل التصحيح لعملية السيد NGINX.

wallarm_proton_log_mask_worker¶

إعدادات التصحيح لعملية NGINX العاملة.

wallarm_protondb_path¶

مسار إلى ملف proton.db الذي يحتوي على الإعدادات العامة لتصفية الطلبات، التي لا تعتمد على هيكل التطبيق.

wallarm_rate_limit¶

تعيين تكوين حد السرعة في الشكل التالي:

wallarm_rate_limit <المفتاح لقياس الحدود> rate=<معدل> burst=<تفجير> delay=<تأخير>;

• المفتاح لقياس الحدود - المفتاح الذي تود قياس الحدود له. يمكن أن يحتوي على نص، متغيرات NGINX ومزيجها.

  على سبيل المثال: "$remote_addr +login" للحد من الطلبات الواصلة من نفس IP والمستهدفة على المسار /login.

• rate=<معدل> (مطلوب) - حد السرعة، يمكن أن يكون rate=<رقم>r/s أو rate=<رقم>r/m.

• burst=<تفجير> (اختياري) - العدد الأقصى للطلبات الزائدة للتخزين المؤقت بمجرد تجاوز RPM/RPS المحدد ويتم معالجتها بمجرد عودة السرعة إلى الطبيعي. 0 بشكل افتراضي.

• delay=<تأخير> - إذا كانت قيمة <تفجير> مختلفة عن 0، يمكنك التحكم في ما إذا كان سيكون لديك للحفاظ على RPM/RPS المحدد بين تنفيذ الطلبات الزائدة المخزنة ضمن النطاق. يشير nodelay إلى التنفيذ المتزامن لجميع الطلبات الزائدة المخزنة ضمن النطاق، دون تأخير حد السرعة. القيمة العددية تعني التحصيل المتزامن للعدد المحدد من الطلبات الزائدة، يتم معالجة البقية بتأخير معين في RPS/RPM.

مثال:

wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5;

wallarm_rate_limit_enabled¶

تمكين/تعطيل حد السرعة لـ Wallarm.

إذا off، فلا تعمل قاعدة حد السرعة (موصى به) ولا التوجيه wallarm_rate_limit.

wallarm_rate_limit_log_level¶

مستوى التسجيل للطلبات المرفوضة من قبل التحكم بحد السرعة. يمكن أن تكون: info، notice، warn، error.

wallarm_rate_limit_status_code¶

رمز لإرجاع في الاستجابة إلى الطلبات المرفوضة بواسطة وحدة حد السرعة لـ Wallarm.

wallarm_rate_limit_shm_size¶

تعيين الحد الأقصى لكمية الذاكرة المشتركة التي يمكن استهلاكها بواسطة حد السرعة لـ Wallarm.

مع متوسط طول المفتاح 64 بايتًا (حروف)، و wallarm_rate_limit_shm_size من 64MB، يمكن للوحدة التعامل مع حوالي 130,000 مفتاح فريد في وقت واحد. زيادة الذاكرة بمقدار ضعفين يضاعف سعة الوحدة على نحو خطي.

المفتاح هو قيمة فريدة للنقطة الطلب التي تستخدمها الوحدة لقياس الحدود. على سبيل المثال، إذا كانت الوحدة تحد من الاتصالات استنادًا إلى عناوين IP، يعتبر كل عنوان IP فريد مفتاحًا واحدًا. بفضل القيمة الافتراضية للتوجيه، يمكن للوحدة معالجة الطلبات الصادرة من ~130,000 IPs مختلفة متزامنًا.

wallarm_request_chunk_size¶

تحدد حجم جزء من الطلب الذي يتم معالجته خلال تكرار واحد. يمكنك تعيين قيمة مخصصة للتوجيه wallarm_request_chunk_size في البايتات عبر تعيين أي عدد صحيح له. التوجيه يدعم أيضا اللاحقات التالية:

• k أو K للكيلوبايت

• m أو M لميغابايت

• g أو G لجيغابايت

wallarm_request_memory_limit¶

تعيين حد للكمية القصوى من الذاكرة التي يمكن استخدامها لمعالجة طلب واحد.

إذا تم تجاوز الحد، سيلغى معالجة الطلب وسيلغى المستخدم الخطأ 500.

يمكن استخدام اللاحقات التالية في هذا المعلم:

• k أو K للكيلوبايت

• m أو M لميغابايت

• g أو G لجيغابايت

قيمة 0 توقف الحد.

افتراضيا، الحدود معطلة.

wallarm_stalled_worker_timeout¶

تعيين حد زمني لمعالجة طلب واحد للعمل عقدة NGINX بالثواني.

إذا تجاوز الزمن الحد، يتم كتابة بيانات حول عمال NGINX إلى القيم stalled_workers_count و stalled_workers إحصائيات العوامل.

wallarm_status¶

تتحكم في خدمة الإحصاءات Wallarm.

تحتوي قيمة التوجيه على التنسيق التالي:

wallarm_status [on|off] [format=json|prometheus];

من الأفضل تكوين خدمة الإحصاءات في ملف خاص بها، وتجنب التوجيه wallarm_status في ملفات الإعداد الأخرى NGINX، لأن الأخير قد يكون غير آمن. يقع ملف التكوين wallarm-status في:

• /etc/nginx/wallarm-status.conf للمثبت كل في واحد

• /etc/nginx/conf.d/wallarm-status.conf للتثبيتات الأخرى

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

wallarm_tarantool_upstream¶

مع wallarm_tarantool_upstream، يمكنك موازنة الطلبات بين عدة خوادم postanalytics.

مثال:

upstream wallarm_tarantool {
    server 127.0.0.1:3313 max_fails=0 fail_timeout=0 max_conns=1;
    keepalive 1;
}

# متروك

wallarm_tarantool_upstream wallarm_tarantool;

انظر أيضًا إلى وحدة ngx_http_upstream_module.

wallarm_unpack_response¶

ما إذا كان سوف يُفك تشفير البيانات المضغوطة المُرجعة في الاستجابة التطبيقية. القيم الممكنة هي on (عملية التفكيك مُمكّنة) و off (عملية التفكيك معطلة).

هذا المعلم فعّال فقط إذا wallarm_parse_response on.

wallarm_upstream_backend¶

وسيلة لإرسال الطلبات المُسلسلة. يمكن إرسال الطلبات إما إلى Tarantool أو إلى الواجهة البرمجية للتطبيقات API.

القيم الممكنة للتوجيه:

• tarantool

• api

باعتماد التوجيهات الأخرى، سيتم تعيين القيمة الافتراضية على النحو التالي:

• tarantool - إذا لم يكن هناك توجيه wallarm_api_conf في التكوين.

• api - إذا كان هناك توجيه wallarm_api_conf، ولكن لا يوجد توجيه wallarm_tarantool_upstream في التكوين.

  Note

  إذا كان التوجيه wallarm_api_conf و wallarm_tarantool_upstream موجودين في نفس الوقت في التكوين، ستحدث خطأ في التكوين بشكل غامض في التصميم العلوي لـ wallarm.

wallarm_upstream_connect_attempts¶

تعرف عدد المحاولات الفورية لإعادة الاتصال بـ Tarantool أو واجهة برمجة التطبيقات API.
إذا تم إنهاء الاتصال بـ Tarantool أو الواجهة البرمجية للتطبيقات API، فلن يحدث محاولة لإعادة الاتصال. ومع ذلك، هذا ليس الأمر في حالة عدم وجود المزيد من الاتصالات وطابور الطلبات المُسلسلة ليس فارغًا.

wallarm_upstream_reconnect_interval¶

تحدد الفاصل بين محاولات إعادة الاتصال بـ Tarantool أو واجهة برمجة التطبيقات API بعد أن تجاوز عدد المحاولات الفاشلة الحد الذي حدده wallarm_upstream_connect_attempts.

wallarm_upstream_connect_timeout¶

تعريف وقت المهلة للاتصال بـ Tarantool أو واجهة برمجة التطبيقات API.

wallarm_upstream_queue_limit¶

تحدد حدًا لعدد الطلبات المُسلسلة.
تعيين المعلم wallarm_upstream_queue_limit متزامنًا وعدم تعيين المعلم wallarm_upstream_queue_memory_limit يعني أن لا يوجد حد على الأخير.

wallarm_upstream_queue_memory_limit¶

تحدد حدًا لإجمالي حجم الطلبات المُسلسلة.
تعيين المعلم wallarm_upstream_queue_memory_limit متزامنًا وعدم تعيين المعلم wallarm_upstream_queue_limit يعني أن لا يوجد حد على الأخير.

wallarm_upstream_connect_attempts¶

تعرف عدد المحاولات الفورية للاتصال بـ Tarantool أو API.
إذا تم إنهاء الاتصال بـ Tarantool أو API، فلن يحدث محاولة لإعادة الاتصال. ومع ذلك، هذا ليس الحال عندما لا تكون هناك المزيد من الاتصالات وطابور الطلبات المُسردة ليست فارغًا.

wallarm_upstream_reconnect_interval¶

تحدد الفاصل بين محاولات الاتصال بـ Tarantool أو API بعد تجاوز عدد المحاولات الفاشلة الحد الذي حدد في wallarm_upstream_connect_attempts.

wallarm_upstream_connect_timeout¶

تعرف مهلة التواصل إلى Tarantool أو API.

wallarm_upstream_queue_limit¶

تحدد حدًا لعدد الطلبات المُسلسلة.
تعيين المعلم wallarm_upstream_queue_limit متزامنًا وعدم تعيين المعلم wallarm_upstream_queue_memory_limit يعني أن لا يوجد حد على الأخير.

wallarm_upstream_queue_memory_limit¶

تحدد حدًا لإجمالي حجم الطلبات المُسلسلة.
تعيين المعلم wallarm_upstream_queue_memory_limit متزامنًا وعدم تعيين المعلم wallarm_upstream_queue_limit يعني أن لا يوجد حد على الأخير.

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

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

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

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

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

0/240

يرسل