EOL durumundaki Wallarm NGINX modüllerinin yükseltilmesi¶

Bu talimatlar, destek süresi dolmuş (EOL) Wallarm NGINX modüllerinin (sürüm 3.6 ve altı) en son 6.x sürümüne yükseltilmesi adımlarını açıklar. Wallarm NGINX modülleri, aşağıdaki talimatlardan birine göre kurulan modüllerdir:

• NGINX stable için bireysel paketler

• NGINX Plus için bireysel paketler

• Dağıtımın sağladığı NGINX için bireysel paketler

EOL düğümü yükselttiğinizi Wallarm teknik desteğine bildirin¶

Destek süresi dolmuş (EOL) Wallarm NGINX modüllerini (sürüm 3.6 ve altı) 6.x sürümüne yükseltiyorsanız, Wallarm teknik desteği ile iletişime geçip bilgi verin ve yardım isteyin.

Diğer yardımların yanı sıra, Wallarm hesabınız için yeni IP lists mantığının etkinleştirilmesini talep edin. Yeni IP lists mantığı etkinleştirildiğinde lütfen Wallarm Console'u açın ve IP lists bölümünün mevcut olduğunu doğrulayın.

Gereksinimler¶

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

• Access to https://meganode.wallarm.com to download all-in-one Wallarm installer. Ensure the access is not blocked by a firewall.

• Access to https://us1.api.wallarm.com for working with US Wallarm Cloud or to https://api.wallarm.com for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions.

• Executing all commands as a superuser (e.g. root).

• Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers.

  US CloudEU Cloud

  node-data0.us1.wallarm.com - 34.96.64.17
  node-data1.us1.wallarm.com - 34.110.183.149
  us1.api.wallarm.com - 35.235.66.155
  34.102.90.100
  34.94.156.115
  35.235.115.105
  

  node-data1.eu1.wallarm.com - 34.160.38.183
  node-data0.eu1.wallarm.com - 34.144.227.90
  api.wallarm.com - 34.90.110.226
  

Yükseltme prosedürü¶

• Filtreleme düğümü ve postanalytics modülleri aynı sunucuya kuruluysa, tümünü yükseltmek için aşağıdaki talimatları izleyin.

  Daha yeni sürümü temiz bir makinede all-in-one yükleyiciyle çalıştırmanız, düzgün çalıştığını test etmeniz, ardından öncekini durdurmanız ve trafiği önceki makine yerine yeni makineden akacak şekilde yapılandırmanız gerekecektir.

• Filtreleme düğümü ve postanalytics modülleri farklı sunucularda kuruluysa, bu talimatları izleyerek önce postanalytics modülünü, sonra filtreleme modülünü yükseltin.

Adım 1: Threat Replay Testing modülünü devre dışı bırakın (sadece düğüm 2.16 veya altından yükseltiliyorsa)¶

Wallarm düğümünü 2.16 veya altından yükseltiyorsanız, lütfen Wallarm Console → Vulnerabilities → Configure içinde Threat Replay Testing modülünü devre dışı bırakın.

Modülün çalışması yükseltme sürecinde false positive üretebilir. Modülü devre dışı bırakmak bu riski en aza indirir.

Adım 2: Temiz makine hazırlayın¶

When upgrading modules with all-in-one installer, you cannot upgrade an old package installation - instead you need to use a clean machine. Thus, as step 1, prepare a machine with one of the supported OS:

• Debian 10, 11 and 12.x

• Ubuntu LTS 18.04, 20.04, 22.04

• CentOS 7, 8 Stream, 9 Stream

• Alma/Rocky Linux 9

• RHEL 8.x

• RHEL 9.x

• Oracle Linux 8.x

• Oracle Linux 9.x

• Redox

• SuSe Linux

• Others (the list is constantly widening, contact Wallarm support team to check if your OS is in the list)

Using new clean machine will lead to that at some moment you will have both old and new node, which is good: you can test the new one working properly without stopping the old one.

Adım 3: NGINX ve bağımlılıklarını kurun¶

Install the latest NGINX version of:

• NGINX stable (the latest supported version is v1.28.0) - see how to install it in the NGINX documentation.

• NGINX Mainline (the latest supported version is v1.27.5) - see how to install it in the NGINX documentation.

• NGINX Plus (the latest supported version is NGINX Plus R33) - see how to install it in the NGINX documentation.

• Distribution-Provided NGINX - to install, use the following commands:

  DebianUbuntuCentOSAlmaLinux, Rocky Linux or Oracle Linux 8.xRHEL 8.x

  sudo apt update 
  sudo apt -y install --no-install-recommends nginx
  

  sudo apt-get update
  sudo apt-get install nginx
  

  sudo yum -y update 
  sudo yum install -y nginx
  

  sudo yum -y update 
  sudo yum install -y nginx
  

  sudo yum -y update 
  sudo yum install -y nginx
  

Adım 4: Wallarm token hazırlayın¶

To install node, you will need a Wallarm token of the appropriate type. To prepare a token:

Adım 5: Tüm‑bir‑arada Wallarm yükleyicisini indirin¶

Wallarm suggests all-in-one installations for the following processors:

• x86_64

• ARM64 (beta)

To download all-in-one Wallarm installation script, execute the command:

curl -O https://meganode.wallarm.com/6.6/wallarm-6.6.1.x86_64-glibc.sh

curl -O https://meganode.wallarm.com/6.6/wallarm-6.6.1.aarch64-glibc.sh

Adım 6: Tüm‑bir‑arada Wallarm yükleyicisini çalıştırın¶

Aynı sunucuda filtreleme düğümü ve postanalytics¶

1. Run downloaded script:

   API tokenNode token

   # If using the x86_64 version:
   sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.6.1.x86_64-glibc.sh
   
   # If using the ARM64 version:
   sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.6.1.aarch64-glibc.sh
   

   The WALLARM_LABELS variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI).

   # If using the x86_64 version:
   sudo sh wallarm-6.6.1.x86_64-glibc.sh
   
   # If using the ARM64 version:
   sudo sh wallarm-6.6.1.aarch64-glibc.sh
   

2. Select US Cloud or EU Cloud.

3. Enter Wallarm token.

Farklı sunucularda filtreleme düğümü ve postanalytics¶

1. Postanalytics modülünü şu talimatları izleyerek yükseltin.

2. Filtreleme düğümünü yükseltin:

   API belirteciNode belirteci

   # x86_64 sürümünü kullanıyorsanız:
   sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.5.1.x86_64-glibc.sh filtering
   
   # ARM64 sürümünü kullanıyorsanız:
   sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.5.1.aarch64-glibc.sh filtering
   

   WALLARM_LABELS değişkeni, düğümün ekleneceği grubu belirler (Wallarm Console UI içinde düğümlerin mantıksal gruplaması için kullanılır).

   # x86_64 sürümünü kullanıyorsanız:
   sudo sh wallarm-6.5.1.x86_64-glibc.sh filtering
   
   # ARM64 sürümünü kullanıyorsanız:
   sudo sh wallarm-6.5.1.aarch64-glibc.sh filtering
   

Adım 7: İzinli listeleri ve engelli listeleri önceki Wallarm düğümü sürümünden 6.x'e taşıyın (sadece düğüm 2.18 veya altından yükseltiliyorsa)¶

Düğümü 2.18 veya altından yükseltiyorsanız, izinli liste ve engelli liste yapılandırmasını önceki Wallarm düğümü sürümünden en yeni sürüme taşıyın.

Adım 8: NGINX ve postanalytics yapılandırmasını eski düğüm makinesinden yeniye aktarın¶

Gerekli yönergeleri veya dosyaları kopyalayarak düğüme ilişkin NGINX ve postanalytics yapılandırmalarını eski makineden yeniye taşıyın:

• /etc/nginx/conf.d/default.conf veya /etc/nginx/nginx.conf (http seviyesine ilişkin NGINX ayarları)

  Filtreleme ve postanalytics düğümleri farklı sunuculardaysa, filtreleme düğümü makinesindeki /etc/nginx/nginx.conf dosyasının http bloğunda wallarm_tarantool_upstream adını wallarm_wstore_upstream olarak değiştirin.

• /etc/nginx/sites-available/default (trafik yönlendirme için NGINX ve Wallarm ayarları)

• /etc/nginx/conf.d/wallarm-status.conf → yeni makinede /etc/nginx/wallarm-status.conf konumuna kopyalayın

  Ayrıntılı açıklama bağlantı içinde mevcuttur.

• /etc/wallarm/node.yaml → yeni makinede /opt/wallarm/etc/wallarm/node.yaml konumuna kopyalayın

  Ayrı bir postanalytics sunucusunda özel bir ana bilgisayar ve bağlantı noktası kullanıyorsanız, kopyalanan dosyada postanalytics düğümü makinesinde tarantool bölümünü wstore olarak yeniden adlandırın.

Kullanımdan kaldırılan NGINX yönergelerini yeniden adlandırın¶

Aşağıdaki NGINX yönergeleri yapılandırma dosyalarında açıkça belirtilmişse adlarını değiştirin:

• 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

• wallarm_tarantool_upstream → wallarm_wstore_upstream

Yalnızca yönergelerin adları değişti, mantıkları aynı kaldı. Eski adlara sahip yönergeler yakında kullanımdan kaldırılacaktır, bu nedenle önceden yeniden adlandırmanız önerilir.

Düğüm günlükleme değişkenlerini güncelleyin¶

Yeni düğüm sürümünde düğüm günlükleme değişkenlerinde aşağıdaki değişiklikler uygulanmıştır:

• wallarm_request_time değişkeninin adı wallarm_request_cpu_time olarak değiştirilmiştir.

  Yalnızca değişken adı değişti, mantığı aynı kaldı. Eski ad geçici olarak desteklenmektedir ancak yine de değişkenin yeniden adlandırılması önerilir.

• wallarm_request_mono_time değişkeni eklendi – aşağıdaki toplamın loglanmasına ihtiyaç duyuyorsanız günlük formatı yapılandırmasına ekleyin:

  • Kuyrukta geçen süre
  • CPU'nun isteği işlerken harcadığı süre (saniye)

En son sürümlerde yayınlanan değişikliklere göre Wallarm düğümü filtreleme modu ayarlarını uyarlayın¶

1. Aşağıda listelenen ayarların beklenen davranışının, off ve monitoring filtreleme modlarının değişen mantığı ile uyumlu olduğundan emin olun:

   • Yönerge wallarm_mode
   • Wallarm Console'da yapılandırılmış genel filtreleme kuralı
   • Wallarm Console'da yapılandırılmış uç nokta hedefli filtreleme kuralları

2. Beklenen davranış değişen filtreleme modu mantığıyla uyuşmuyorsa, talimatları kullanarak filtreleme modu ayarlarını yayınlanan değişikliklere göre uyarlayın.

overlimit_res saldırı algılama yapılandırmasını yönergelerden kurala taşıyın¶

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.

wallarm-status.conf dosya içeriğini güncelleyin¶

/etc/nginx/conf.d/wallarm-status.conf içeriğini aşağıdaki gibi güncelleyin:

server {
  listen 127.0.0.8:80;
  server_name localhost;

  allow 127.0.0.8/8;   # Erişim yalnızca filtreleme düğümü sunucusunun loopback adresleri için kullanılabilir  
  deny all;

  wallarm_mode off;
  disable_acl "on";   # İstek kaynaklarının kontrolü devre dışıdır, denylisted IP'lerin wallarm-status servisine istek yapmasına izin verilir. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl
  wallarm_enable_apifw off;
  access_log off;

  location ~/wallarm-status$ {
    wallarm_status on;
  }
}

İstatistik servisinin yapılandırılması hakkında daha fazla ayrıntı

Wallarm engelleme sayfasını güncelleyin¶

Yeni düğüm sürümünde Wallarm örnek engelleme sayfası değiştirildi. Sayfadaki logo ve destek e‑postası artık varsayılan olarak boştur.

Eğer &/usr/share/nginx/html/wallarm_blocked.html sayfası engellenen isteklere yanıt olarak döndürülmek üzere yapılandırılmışsa, yeni örnek sayfanın sürümünü kopyalayıp özelleştirin.

Adım 9: API portunu güncelleyin¶

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.

Adım 10: Threat Replay Testing modülünü yeniden etkinleştirin (sadece düğüm 2.16 veya altından yükseltiliyorsa)¶

Threat Replay Testing modülü kurulumuna ilişkin öneriyi inceleyin ve gerekirse yeniden etkinleştirin.

Bir süre sonra, modülün çalışmasının false positive üretmediğinden emin olun. False positive tespit ederseniz lütfen Wallarm teknik desteği ile iletişime geçin.

Adım 11: NGINX'i yeniden başlatın¶

Restart NGINX using the following command:

sudo systemctl restart nginx

Adım 12: Wallarm düğümü çalışmasını test edin¶

Yeni düğümün çalışmasını test etmek için:

1. Korunan kaynak adresine test SQLI ve XSS saldırıları içeren bir istek gönderin:

   curl http://localhost/?id='or+1=1--a-<script>prompt(1)</script>'
   

2. Wallarm Console → Attacks bölümünü US Cloud veya EU Cloud içinde açın ve saldırıların listede göründüğünden emin olun.

3. Cloud üzerinde saklanan verileriniz (kurallar, IP lists) yeni düğümle senkronize olur olmaz, kurallarınızın beklendiği gibi çalıştığından emin olmak için bazı test saldırıları gerçekleştirin.

Adım 13: Trafiğin Wallarm düğümüne gönderilmesini yapılandırın¶

Yük dengeleyicinizin hedeflerini Wallarm örneğine trafik gönderecek şekilde güncelleyin. Ayrıntılar için, yük dengeleyicinizin belgelerine bakın.

Trafiği tamamen yeni düğüme yönlendirmeden önce, önce kısmen yönlendirmeniz ve yeni düğümün beklendiği gibi davrandığını kontrol etmeniz önerilir.

Adım 14: Eski düğümü kaldırın¶

1. Wallarm Console → Nodes içinde düğümünüzü seçip Delete tıklayarak eski düğümü silin.

2. İşlemi onaylayın.

   Düğüm Cloud'dan silindiğinde, uygulamalarınıza gelen isteklerin filtrelenmesini durduracaktır. Filtreleme düğümünü silme işlemi geri alınamaz. Düğüm, düğümler listesinden kalıcı olarak silinecektir.

3. Eski düğümlü makineyi silin veya sadece Wallarm düğüm bileşenlerinden temizleyin:

   DebianUbuntuCentOS veya Amazon Linux 2.0.2021x ve altıAlmaLinux, Rocky Linux veya Oracle Linux 8.xRHEL 8.x

   sudo apt remove wallarm-node nginx-module-wallarm
   

   sudo apt remove wallarm-node nginx-module-wallarm
   

   sudo yum remove wallarm-node nginx-module-wallarm
   

   sudo yum remove wallarm-node nginx-module-wallarm
   

   sudo yum remove wallarm-node nginx-module-wallarm
   

Ayarların özelleştirilmesi¶

Wallarm modülleri 6.x sürümüne güncellendi. Önceki filtreleme düğümü ayarları yeni sürüme otomatik olarak uygulanacaktır. Ek ayarlar yapmak için kullanılabilir yönergeleri kullanın.

Common customization options:

• Configuration of the filtration mode

• Logging Wallarm node variables

• 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

• Configuring dynamic DNS resolution in NGINX

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send