تثبيت الوحدة الديناميكية الخارجية لـ Wallarm لإصدارات NGINX المقدمة من التوزيع¶
تصف هذه التعليمات الخطوات لتثبيت Wallarm كوحدة ديناميكية خارجية باستخدام حزم Linux لـ NGINX المقدمة من التوزيع.
يمكن الحصول على NGINX Open Source من nginx.org أو المستودعات الافتراضية لـ Debian/CentOS اعتمادًا على متطلباتك وتفضيلات إصدار NGINX وسياسات إدارة المستودع. توفر Wallarm حزمًا لكل من nginx.org والإصدارات المقدمة من التوزيع. يركز هذا الدليل على NGINX من مستودعات Debian/CentOS.
تتوافق وحدة Wallarm مع NGINX المقدمة من التوزيع على أنظمة التشغيل التالية:
-
Debian 10.x (buster)
-
Debian 11.x (bullseye)
-
CentOS 7.x
-
AlmaLinux، Rocky Linux أو Oracle Linux 8.x
-
RHEL 8.x
حالات الاستخدام¶
Among all supported Wallarm deployment options, DEB/RPM packages for distribution-provided NGINX is recommended for Wallarm deployment in these use cases:
-
Your infrastructure is based on bare metal or virtual machines without using container-based methods. Typically, these setups are managed with Infrastructure as Code (IaC) tools like Ansible or SaltStack.
-
Your services are built around distribution-provided NGINX. Wallarm can extend its functionalities using these packages.
المتطلبات¶
-
Access to the account with the Administrator role in Wallarm Console for the US Cloud or EU Cloud
-
SELinux disabled or configured upon the instructions
-
Executing all commands as a superuser (e.g.
root
) -
Access to
https://repo.wallarm.com
to download packages. Ensure the access is not blocked by a firewall -
Access to
https://us1.api.wallarm.com
for working with US Wallarm Cloud or tohttps://api.wallarm.com
for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions -
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
-
Installed text editor vim, nano, or any other. In the instruction, vim is used
1. Add Debian/CentOS repositories¶
sudo apt -y install dirmngr
curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import
sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg
sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
2. Install NGINX with Wallarm packages¶
The command installs the following packages:
-
nginx
for NGINX -
libnginx-mod-http-wallarm
ornginx-mod-http-wallarm
for the NGINX-Wallarm module -
wallarm-node
for the postanalytics module, Tarantool database, and additional NGINX-Wallarm packages
3. Connect the Wallarm module¶
Copy the configuration files for the system setup:
4. Connect the filtering node to Wallarm Cloud¶
The Wallarm filtering node interacts with the Wallarm Cloud. You need to connect the node to the Cloud.
When connecting node to the Cloud, you can set the node name, under which it will be displayed in the Wallarm Console UI and put the node into the appropriate node group (used to logically organize nodes in UI).
To connect the node to the Cloud, use a Wallarm token of the appropriate type:
- Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
- Find or create API token with the
Node deployment/Deployment
usage type. - Copy this token.
-
Run the
register-node
script on a machine where you install the filtering node:<TOKEN>
is the copied value of the API token with theDeploy
role.--labels 'group=<GROUP>'
parameter puts your node to the<GROUP>
node group (existing, or, if does not exist, it will be created). If you are installing filtering and postanalytics modules separately, it is recommended to put them into the same group.
- Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
- Do one of the following:
- Create the node of the Wallarm node type and copy the generated token.
- Use existing node group - copy token using node's menu → Copy token.
-
Run the
register-node
script on a machine where you install the filtering node:
<TOKEN>
is the copied value of the node token. If you are installing filtering and postanalytics modules separately, it is recommended to put them into the same group using the same node token.
- You may add
-n <HOST_NAME>
parameter to set a custom name for your node instance. Final instance name will be:HOST_NAME_NodeUUID
.
5. تمكين Wallarm لتحليل حركة المرور¶
By default, the deployed Wallarm node does not analyze incoming traffic.
Perform the following configuration in the /etc/nginx/conf.d/default.conf
file on the machine with the installed node to configure Wallarm to process the traffic mirror:
-
For the Wallarm node to accept mirrored traffic, set the following configuration in the
server
NGINX block: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;
- The
set_real_ip_from
andreal_ip_header
directives are required to have Wallarm Console display the IP addresses of the attackers. - The
wallarm_force_response_*
directives are required to disable analysis of all requests except for copies received from the mirrored traffic.
- The
-
For the Wallarm node to analyze the mirrored traffic, set the
wallarm_mode
directive tomonitoring
:Since malicious requests cannot be blocked, the only mode Wallarm accepts is monitoring. For in-line deployment, there are also safe blocking and blocking modes but even if you set the
wallarm_mode
directive to a value different from monitoring, the node continues to monitor traffic and only record malicious traffic (aside from the mode set to off).
6. إعادة تشغيل NGINX¶
Providing user with root
permission
If you are running NGINX as a user that does not have root
permission, then add this user to the wallarm
group using the following command:
where <user_name>
is the name of the user without root
permission.
7. تكوين إرسال الحركة إلى كيان Wallarm¶
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.
8. اختبار تشغيل كيان Wallarm¶
-
Send the request with test Path Traversal attack to a protected resource address:
If traffic is configured to be proxied to
example.com
, include the-H "Host: example.com"
header in the request. -
Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.
-
Optionally, test other aspects of the node functioning.
9. ضبط الحل المنشور بدقة¶
تم تثبيت الوحدة الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX الثابت
. قد يتطلب كيان التصفية بعض التكوينات الإضافية بعد النشر.
تُعرّف إعدادات Wallarm باستخدام توجيهات NGINX أو واجهة المستخدم لوحة تحكم Wallarm. يجب ضبط التوجيهات في الملفات التالية على الجهاز الذي يحتوي على كيان Wallarm:
-
/etc/nginx/conf.d/default.conf
مع إعدادات NGINX -
/etc/nginx/conf.d/wallarm.conf
مع إعدادات كيان التصفية العالميةيُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات النطاقات المختلفة، استخدم الملف
default.conf
أو أنشئ ملفات تكوين جديدة لكل مجموعة نطاقات (على سبيل المثال،example.com.conf
وtest.com.conf
). المزيد من المعلومات التفصيلية حول ملفات تكوين NGINX متوفرة في التوثيق الرسمي لـ NGINX. -
/etc/nginx/conf.d/wallarm-status.conf
مع إعدادات مراقبة كيان Wallarm. الوصف التفصيلي متوفر ضمن الرابط -
/etc/default/wallarm-tarantool
أو/etc/sysconfig/wallarm-tarantool
مع إعدادات قاعدة بيانات Tarantool
أدناه بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر:
-
Using the balancer of the proxy server behind the filtering node
-
Limiting the single request processing time in the directive
wallarm_process_time_limit
-
Limiting the server reply waiting time in the NGINX directive
proxy_read_timeout
-
Limiting the maximum request size in the NGINX directive
client_max_body_size