Ömrü Dolmuş (EOL) Docker NGINX tabanlı bir imajı yükseltme¶

Bu talimatlar, çalışan ömrü dolmuş Docker NGINX tabanlı imajın (sürüm 3.6 ve altı) 6.x sürümüne nasıl yükseltileceğini açıklar.

Gereksinimler¶

• 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 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
  

Adım 1: Filtreleme düğümü modüllerini yükselttiğinizi Wallarm teknik desteğine bildirin (yalnızca 2.18 veya daha eski düğüm yükseltiliyorsa)¶

Eğer 2.18 veya daha eski bir düğümü yükseltiyorsanız, lütfen Wallarm teknik desteğine filtreleme düğümü modüllerini 6.x sürümüne yükselttiğinizi bildirip Wallarm hesabınız için yeni IP list mantığının etkinleştirilmesini isteyin. Yeni IP list mantığı etkinleştirildiğinde, Wallarm Console içindeki IP lists bölümünün erişilebilir olduğundan emin olun.

Adım 2: Threat Replay Testing modülünü devre dışı bırakın (yalnızca 2.16 veya daha eski düğüm yükseltiliyorsa)¶

Eğer Wallarm düğümü 2.16 veya daha eski bir sürüme yükseltiliyorsa, 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üreci sırasında yanlış pozitiflere neden olabilir. Modülü devre dışı bırakmak bu riski en aza indirir.

Adım 3: 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 4: Güncellenmiş filtreleme düğümü imajını indirin¶

docker pull wallarm/node:6.5.1

Adım 5: Wallarm Cloud’a belirteç (token) tabanlı bağlantıya geçin¶

Konteyneri Wallarm Cloud’a bağlama yaklaşımı aşağıdaki şekilde güncellendi:

• "E‑posta ve parola" tabanlı yaklaşım kullanımdan kaldırıldı. Bu yaklaşımda, DEPLOY_USER ve DEPLOY_PASSWORD değişkenlerinde doğru kimlik bilgileri ile konteyner başlatıldığında düğüm Wallarm Cloud’da otomatik olarak kaydediliyordu.

• Belirteç tabanlı yaklaşım eklendi. Konteyneri Cloud’a bağlamak için, WALLARM_API_TOKEN değişkeni Wallarm Console UI’dan kopyalanan Wallarm API belirtecini içerecek şekilde konteyneri çalıştırın.

6.x imajını çalıştırmak için yeni yaklaşımın kullanılması önerilir. "E‑posta ve parola" tabanlı yaklaşım gelecekteki sürümlerde kaldırılacaktır; lütfen öncesinde geçiş yapın.

Yeni bir Wallarm düğümü oluşturup belirtecini almak için:

1. Wallarm Console → Settings → API Tokens açın ve kullanım türü Node deployment/Deployment olan bir belirteç oluşturun.

2. Oluşturulan belirteci kopyalayın.

Adım 6: Allowlist ve denylist’leri önceki Wallarm düğümü sürümünden 6.x’e taşıyın (yalnızca 2.18 veya daha eski düğüm yükseltiliyorsa)¶

Eğer 2.18 veya daha eski bir düğümü yükseltiyorsanız, allowlist ve denylist yapılandırmasını önceki Wallarm düğümü sürümünden 6.x’e taşıyın.

Adım 7: Kullanımdan kaldırılan yapılandırma seçeneklerinden geçiş yapın¶

Aşağıdaki yapılandırma seçenekleri kullanımdan kaldırılmıştır:

• WALLARM_ACL_ENABLE ortam değişkeni kullanımdan kaldırıldı.

  IP lists’ler yeni düğüm sürümüne taşındıysa, bu değişkeni docker run komutundan kaldırın.

• Postanalytics bellek miktarını TARANTOOL_MEMORY_GB ortam değişkeni ile ayarlıyorsanız, değişken adını SLAB_ALLOC_ARENA olarak değiştirin.

• Aşağıdaki NGINX yönergelerinin adları değiştirildi:

  • 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

  Yalnızca yönergelerin adlarını değiştirdik, mantıkları aynı kaldı. Eski adlara sahip yönergeler yakında kullanımdan kaldırılacağından, bunları önceden yeniden adlandırmanız önerilir.

  Eski adlara sahip yönergelerin bağlanmış yapılandırma dosyalarında açıkça belirtilip belirtilmediğini kontrol edin. Eğer öyleyse, yeniden adlandırın.

• wallarm_request_time loglama değişkeninin adı wallarm_request_cpu_time olarak değiştirildi.

  Yalnızca değişken adı değişti, mantığı aynı kaldı. Eski ad geçici olarak desteklenmeye de devam ediyor, ancak yine de değişkeni yeniden adlandırmanız önerilir.

Adım 8: Wallarm engelleme sayfasını güncelleyin (NGINX tabanlı imaj yükseltiliyorsa)¶

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.

Docker konteyneri engellenen isteklere &/usr/share/nginx/html/wallarm_blocked.html sayfasını döndürecek şekilde yapılandırılmışsa, bu yapılandırmayı aşağıdaki gibi değiştirin:

1. Yeni sürüm örnek sayfayı kopyalayın ve özelleştirin.

2. Özelleştirilmiş sayfayı ve NGINX yapılandırma dosyasını bir sonraki adımda yeni Docker konteynerine bağlayın (mount).

Adım 9: Son mimari güncellemeleri gözden geçirin (NGINX tabanlı Docker imajı için)¶

En son güncelleme, imaj optimizasyonu ve Tarantool’un değişimi nedeniyle, özellikle konteyner başlatımı sırasında özel yapılandırma dosyalarını bağlayan kullanıcıları etkileyebilecek, belirli dosyaların yollarındaki değişikliklerden kaynaklanan mimari değişiklikler getirdi. Lütfen bu değişiklikleri gözden geçirerek yeni imajın doğru şekilde yapılandırıldığından ve kullanıldığından emin olun.

Adım 10: overlimit_res saldırı tespiti 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 and parameters 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 parameters, 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 in the mounted configuration files:

   • The time limit for the node to process a single request (milliseconds): the value of wallarm_process_time_limit or 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, wallarm_process_time_limit_block NGINX directives from the mounted configuration file.

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

Adım 11: Çalışan konteyneri durdurun¶

docker stop <RUNNING_CONTAINER_NAME>

Adım 12: Güncellenmiş imajı kullanarak konteyneri çalıştırın¶

Güncellenmiş imajı kullanarak konteyneri çalıştırın ve gerekirse imaj optimizasyonu ve Tarantool’un değişimi nedeniyle imajda yapılan son değişikliklerin gerektirdiği şekilde bağlanan dosyaların yollarında gerekli düzenlemeleri yapın.

Güncellenmiş imajla konteyneri çalıştırmanın iki seçeneği vardır:

• Ortam değişkenleri ile

• Bağlanan yapılandırma dosyasında

Adım 13: Wallarm düğümü filtreleme modu ayarlarını en son sürümlerde yayınlanan değişikliklere uyarlayın (yalnızca 2.18 veya daha eski düğüm yükseltiliyorsa)¶

1. Aşağıda listelenen ayarların beklenen davranışının, off ve monitoring filtreleme modlarının değişen mantığına karşılık geldiğinden emin olun:

   • NGINX tabanlı Docker konteynerinin WALLARM_MODE ortam değişkeni veya wallarm_mode yönergesi
   • Wallarm Console’da yapılandırılan General filtration rule
   • Wallarm Console’da yapılandırılan Endpoint-targeted filtration rules

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.

Adım 14: Filtreleme düğümünün çalışmasını test edin¶

1. Send the request with the test Path Traversal attack to the application 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. Make sure the node of the new type processes the request in the same way as the regular node did, e.g.:

   • Blocks the request if the appropriate filtration mode is configured.
   • Returns the custom blocking page if it is configured.

3. Open Wallarm Console → Attacks in the EU Cloud or US Cloud and make sure that:

   • The attack is displayed in the list.
   • Hit details display the Wallarm node UUID.

   

Adım 15: Önceki sürümün filtreleme düğümünü silin¶

6.x sürümündeki dağıtılmış imaj düzgün çalışıyorsa, Wallarm Console → Nodes bölümünden önceki sürümün filtreleme düğümünü silebilirsiniz.

Adım 16: Threat Replay Testing modülünü yeniden etkinleştirin (yalnızca 2.16 veya daha eski düğüm yükseltiliyorsa)¶

Threat Replay Testing modülünün kurulumuna ilişkin öneriyi gözden geçirin ve gerekirse yeniden etkinleştirin.

Bir süre sonra, modülün çalışmasının yanlış pozitiflere yol açmadığından emin olun. Yanlış pozitiflerle karşılaşırsanız lütfen Wallarm teknik desteği ile iletişime geçin.

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