انتقل إلى المحتوى

تجهيز Wallarm OOB من الصورة المستخدمة Docker

تقدم هذه المقالة تعليمات حول تجهيز Wallarm OOB بالاستفادة من الصورة المستخدمة NGINX-based Docker. التحليل الوارد هنا صمم لتحليل حركة المرور المتكررة التي يوفرها الويب الخادم الأولي أو الخادم الوكيل.

سيناريوهات الاستخدام

Among all supported Wallarm deployment options, NGINX-based Docker image is recommended for Wallarm deployment in these use cases:

  • If your organization utilizes Docker-based infrastructure, Wallarm Docker image is the ideal choice. It integrates effortlessly into your existing setup, whether you are employing a microservice architecture running on AWS ECS, Alibaba ECS, or other similar services. This solution also applies to those using virtual machines seeking a more streamlined management through Docker containers.

  • If you require fine-grained control over each container, the Docker image excels. It affords a greater level of resource isolation than typically possible with traditional VM-based deployments.

For more information on running Wallarm's NGINX-based Docker image on popular public cloud container orchestration services, refer to our guides: AWS ECS, GCP GCE, Azure Container Instances, Alibaba ECS.

المتطلبات

  • Docker installed on your host system

  • Access to https://hub.docker.com/r/wallarm/node to download the Docker image. Please ensure the access is not blocked by a firewall

  • Access to the account with the Administrator role in Wallarm Console in the US Cloud or EU Cloud

  • Access to https://us1.api.wallarm.com if working with US Wallarm Cloud or to https://api.wallarm.com if working with EU Wallarm Cloud. Please ensure the access is not blocked by a firewall

  • Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers

    34.96.64.17
    34.110.183.149
    35.235.66.155
    34.102.90.100
    34.94.156.115
    35.235.115.105
    
    34.160.38.183
    34.144.227.90
    34.90.110.226
    

1. تكوين تكرار حركة المرور

Configure your environment to mirror incoming traffic to an instance with the Wallarm node you are deploying. For configuration details, we recommend to refer to documentation on the solution you are going to use to produce the traffic mirror (web server, proxy server, etc.).

Inside the link, you will find the example configuration for NGINX, Traefik, Envoy.

2. إعداد ملف تكوين لتحليل حركة المرور المكررة وأكثر

لتمكين عقدات Wallarm من تحليل حركة المرور المتكررة، يجب عليك تكوين الإعدادات الإضافية في ملف منفصل وتوصيله بحاوية Docker. الملف التكوين الافتراضي الذي يحتاج إلى تعديل موجود في /etc/nginx/sites-enabled/default ضمن الصورة المستخدمة Docker.

في هذا الملف، يجب عليك تحديد تكوين عقدة Wallarm لمعالجة حركة المرور المتكررة وأي إعدادات أخرى مطلوبة. اتبع هذه التعليمات للقيام بذلك:

  1. قم بإنشاء ملف التكوين NGINX المحلي المسمى default بالمحتوى التالي:

    server {
            listen 80 default_server;
            listen [::]:80 default_server ipv6only=on;
            #listen 443 ssl;
    
            server_name localhost;
    
            #ssl_certificate cert.pem;
            #ssl_certificate_key cert.key;
    
            root /usr/share/nginx/html;
    
            index index.html index.htm;
    
            wallarm_force server_addr $http_x_server_addr;
            wallarm_force server_port $http_x_server_port;
            # Change 222.222.222.22 to the address of the mirroring server
            set_real_ip_from  222.222.222.22;
            real_ip_header    X-Forwarded-For;
            real_ip_recursive on;
            wallarm_force response_status 0;
            wallarm_force response_time 0;
            wallarm_force response_size 0;
    
            wallarm_mode monitoring;
    
            location / {
    
                    proxy_pass http://example.com;
                    include proxy_params;
            }
    }
    
    • توجب وجود التوجيهات set_real_ip_from و real_ip_header لتعريض عناوين IP للمهاجمين في منصة Wallarm Console.
    • يتطلب توجيه wallarm_force_response_* تعطيل تحليل كل الطلبات باستثاء النسخ المتلقاة من حركة المرور المتكررة.
    • التوجيه wallarm_mode هو [وضعa تحليل حركة المرور. منذ أن الطلبات الخبيثة لا يمكنa حظرها, الوضع الوحيد الذي يقبله Wallarm هو المراقبة. لتجهيزها بشكل خطي, أيضاً هناك أوضاع آمنة للحظر ووضع حظر ولكن حتى ان قمت بتحديد التوجيه wallarm_mode لقيمة مختلفة عن المراقبة, سوف يستمر العقد في مراقبة حركة المرور وتسجيل فقط حركة
      المرور الخبيثة (باستثناء الوضع المحدد للإيقاف).
  2. حدد أي توجيهات Wallarm مطلوبة أخرى. يمكنك الرجوع لتوثيق معلمات تكوين Wallarm و استخدام السيناريوهات لفهم أي إعدادات قد تكون مفيدة لك.

  3. إذا كان ذلك ضرورياً، قم بتعديل إعدادات NGINX الأخرى لتخصيص سلوكها. استشر توثيق NGINX للمساعدة.

يمكنك أيضاً توصيل الملفات الأخرى إلى الدلائل الاستعدادية التالية للحاوية إذا تطلب الأمر:

  • /etc/nginx/conf.d — الإعدادات المشتركة

  • /etc/nginx/sites-enabled — إعدادات المضيف الافتراضي

  • /opt/wallarm/usr/share/nginx/html — الملفات الثابتة

3. احصل على رمز لتوصيل العقدة بالسحابة

احصل على رمز Wallarm من النوع المناسب:

  1. افتح واجهة Wallarm → الإعدادات → ** رموز ال API** في السحابة الأمريكية أو السحابة الأوروبية.
  2. ابحث أو أنشئ رمز API بدور مصدر Deploy.
  3. انسخ هذا الرمز.
  1. افتح واجهة Wallarm → العقدات في السحابة الأمريكية أو السحابة الأوروبية.
  2. قم بإحدى التالي:
    • أنشئ عقدة من نوع Wallarm node وانسخ الرمز الناتج.
    • استخدم مجموعة العقدة الحالية - انسخ الرمز باستخدام قائمة العقدة → نسخ الرمز.

4. تشغيل حاوية Docker مع العقدة

تشغيل حاوية Docker مع العقدة mounting الملف التكوين الذي أنشأته للتو.

docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.10.4-1
docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.10.4-1

ينبغي تمرير المتغيرات البيئية التالية للحاوية:

Environment variable Description Required
WALLARM_API_TOKEN Wallarm node or API token. Yes
WALLARM_API_HOST Wallarm API server:
  • us1.api.wallarm.com for the US Cloud
  • api.wallarm.com for the EU Cloud
By default: api.wallarm.com.
No
WALLARM_LABELS

Available starting from node 4.6. Works only if WALLARM_API_TOKEN is set to API token with the Deploy role. Sets the group label for node instance grouping, for example:

WALLARM_LABELS="group=<GROUP>"

...will place node instance into the <GROUP> instance group (existing, or, if does not exist, it will be created).

Yes (for API tokens)
SLAB_ALLOC_ARENA (TARANTOOL_MEMORY_GB [NGINX Node 5.x and earlier][what-is-new-wstore]) Amount of memory allocated to wstore. The value can be a float (a dot . is a decimal separator). By default: 1.0 (1 gygabyte). No
WALLARM_APID_ONLY (5.3.7 and higher) In this mode, attacks detected in your traffic are blocked locally by the node (if enabled) but not exported to Wallarm Cloud. Meanwhile, API Discovery and some other features remain fully functional, detecting your API inventory and uploading it to the Cloud for visualization. This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides sensitive attack data masking if needed. More details
By default: false.
No

5. اختبار تشغيل عقدة 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.

    Attacks in the interface

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

تكوين السجل

السجل مفعل بشكل افتراضي. الدلائل السجلية هي:

تكوين سيناريو الاستخدام

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