Atualizando módulos NGINX Wallarm EOL¶

Estas instruções descrevem as etapas para atualizar os módulos NGINX Wallarm end‑of‑life (versão 3.6 e abaixo) para a versão 4.8. Os módulos NGINX Wallarm são os módulos instalados de acordo com uma das seguintes instruções:

• Pacotes individuais para NGINX estável

• Pacotes individuais para NGINX Plus

• Pacotes individuais para NGINX fornecido pela distribuição

Informe ao suporte técnico da Wallarm sobre a atualização do nó EOL¶

Se estiver atualizando os módulos NGINX Wallarm end‑of‑life (versão 3.6 e abaixo) para a versão 4.8, informe o suporte técnico da Wallarm sobre isso e peça assistência.

Além de qualquer outra ajuda, peça para ativar a nova lógica de listas de IP para sua conta Wallarm. Quando a nova lógica de listas de IP estiver ativada, abra o Console Wallarm e certifique-se de que a seção IP lists está disponível.

Métodos de atualização¶

Você pode realizar a atualização de duas maneiras distintas:

• Migrar para o uso do instalador tudo-em-um durante o procedimento de atualização. Esse é o método recomendado, pois automatiza diversas atividades de instalação e atualização do nó, como identificação da versão do NGINX e do sistema operacional, adição de repositórios Wallarm adequados, instalação de pacotes e outros.

• Continue usando o método atual de instalação manual através de pacotes DEB/RPM individuais. No entanto, é importante salientar que em futuras atualizações esse método exigirá um esforço adicional e configuração manual em comparação ao novo método.

Atualização com instalador all-in-one¶

Use o procedimento abaixo para atualizar os módulos NGINX Wallarm end‑of‑life (versão 3.6 e abaixo) para a versão 4.8 usando o instalador all-in-one.

Requisitos para atualização usando o instalador all-in-one¶

• Acesso à conta com a função de Administrador no Console Wallarm para US Cloud ou EU Cloud.

• Acesso a https://meganode.wallarm.com para baixar o instalador Wallarm all-in-one. Certifique-se de que o acesso não está bloqueado por um firewall.

• Acesso a https://us1.api.wallarm.com para trabalhar com o US Wallarm Cloud ou para https://api.wallarm.com para trabalhar com o EU Wallarm Cloud. Se o acesso pode ser configurado somente via servidor proxy, então use as instruções.

• Execução de todos os comandos como superusuário (por exemplo, root).

Procedimento de atualização¶

• Se os módulos de nó de filtragem e postanalítica estiverem instalados no mesmo servidor, siga as instruções abaixo para atualizar todos.

  Você precisará executar um nó da versão mais nova usando o instalador all-in-one em uma máquina limpa, testar se ele funciona corretamente e parar o anterior e configurar o tráfego para fluir através da nova máquina em vez da anterior.

• Se os módulos de nó de filtragem e postanalítica estiverem instalados em servidores diferentes, primeiro atualize o módulo postanalytics e depois o módulo de filtragem seguindo estas instruções.

Passo 1: Desative o módulo de Verificação de ameaças ativas (se estiver atualizando nó 2.16 ou abaixo)¶

Se estiver atualizando o nó Wallarm 2.16 ou abaixo, desative o módulo Verificação de ameaças ativas no Console Wallarm → Vulnerabilidades → Configurar.

A operação do módulo pode causar falsos positivos durante o processo de atualização. Desativar o módulo minimiza este risco.

Passo 2: Prepare a máquina limpa¶

Ao atualizar os módulos 4.x com o instalador all-in-one, você não pode atualizar uma instalação de pacote antigo - em vez disso, você precisa usar uma máquina limpa. Assim, como passo 1, prepare uma máquina com um dos sistemas operacionais suportados:

• Debian 10, 11 e 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

• Outros (a lista está constantemente se expandindo, entre em contato com a equipe de suporte da Wallarm para verificar se seu sistema operacional está na lista)

Usar uma máquina limpa nova levará ao fato de que, em algum momento, você terá ambos os nós antigos e novos, o que é bom: você pode testar o novo funcionando corretamente sem interromper o antigo.

Passo 3: Instale o NGINX e as dependências¶

Instale a última versão do NGINX de:

• NGINX estável - veja como instalá-lo na documentação do NGINX.

• NGINX Plus - veja como instalá-lo na documentação do NGINX.

• NGINX fornecido pela distribuição - para instalar, use os seguintes comandos:

  Debian 10.x (buster)Debian 11.x (bullseye)CentOS 7.xAlmaLinux, Rocky Linux ou Oracle Linux 8.xRHEL 8.x

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

  sudo apt update 
  sudo apt -y install --no-install-recommends 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
  

Passo 4: Prepare o token Wallarm¶

Para instalar o node, você precisará de um token Wallarm do tipo apropriado. Para preparar um token:

Passo 5: Baixe o instalador all-in-one do Wallarm¶

A Wallarm sugere instalações all-in-one para os seguintes processadores:

• x86_64

• ARM64 (beta)

Para baixar o script de instalação all-in-one da Wallarm, execute o comando:

curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.0.x86_64-glibc.sh

curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.0.aarch64-glibc.sh

Passo 6: Execute o instalador all-in-one do Wallarm¶

Nó de filtragem e postanalytics no mesmo servidor¶

1. Execute o script baixado:

=== "Token da API"

# Se estiver usando a versão x86_64:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.8.0.x86_64-glibc.sh

# Se estiver usando a versão ARM64:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.8.0.aarch64-glibc.sh

   A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (usado para agrupar logicamente os nós na interface do usuário do Console Wallarm).

=== "Token do nó"

# Se estiver usando a versão x86_64:
sudo sh wallarm-4.8.0.x86_64-glibc.sh

# Se estiver usando a versão ARM64:
sudo sh wallarm-4.8.0.aarch64-glibc.sh

1. Selecione Nuvem dos EUA ou Nuvem da EU.

2. Insira o token Wallarm.

Nó de filtragem e postanalytics em servidores diferentes¶

1. Atualize o módulo postanalytics seguindo estas instruções.

2. Atualize o nó de filtragem:

   Token da APIToken do nó

   # Se estiver usando a versão x86_64:
   sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.8.0.x86_64-glibc.sh filtering
   
   # Se estiver usando a versão ARM64:
   sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.8.0.aarch64-glibc.sh filtering
   

   A variável WALLARM_LABELS define o grupo ao qual o nó será adicionado (usado para agrupamento lógico de nós na interface de usuário do Console Wallarm).

   # Se estiver usando a versão x86_64:
   sudo sh wallarm-4.8.0.x86_64-glibc.sh filtering
   
   # Se estiver usando a versão ARM64:
   sudo sh wallarm-4.8.0.aarch64-glibc.sh filtering
   

Passo 7: Migrar allowlists e denylists da versão anterior do nó Wallarm para 4.8 (somente se estiver atualizando nó 2.18 ou abaixo)¶

Se estiver atualizando nó 2.18 ou abaixo, migre a configuração de allowlist e denylist da versão anterior do nó Wallarm para a versão mais recente.

Passo 8: Transferir a configuração do NGINX e postanalytics do antigo nó para o novo¶

Transfira a configuração relacionada ao nó do NGINX e a configuração da postanalítica dos arquivos de configuração na máquina antiga para os arquivos na nova máquina. Você pode fazer isso copiando as diretivas necessárias.

Arquivos de origem

Em uma máquina antiga, dependendo do SO e da versão do NGINX, os arquivos de configuração do NGINX podem estar localizados em diretórios diferentes e ter nomes diferentes. Os mais comuns são os seguintes:

• /etc/nginx/conf.d/default.conf com configurações do NGINX

• /etc/nginx/conf.d/wallarm.conf com configurações globais do nó de filtragem

  O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a grupos de domínios diferentes, geralmente é usado o default.conf ou é criado um novo arquivo de configuração para cada grupo de domínio (por exemplo, example.com.conf e test.com.conf). Informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na documentação oficial do NGINX.

• /etc/nginx/conf.d/wallarm-status.conf com configurações de monitoramento do nó Wallarm. Uma descrição detalhada está disponível no link

Além disso, a configuração do módulo de postanalítica (configurações do banco de dados Tarantool) geralmente está localizada aqui:

• /etc/default/wallarm-tarantool ou

• /etc/sysconfig/wallarm-tarantool

Arquivos de destino

Como o instalador all-in-one funciona com diferentes combinações de SO e versões do NGINX, em sua nova máquina, os arquivos de destino podem ter nomes diferentes e estar localizados em diretórios diferentes.

Ao transferir a configuração, você precisa realizar as etapas listadas abaixo.

Renomeie as diretivas NGINX descontinuadas¶

Renomeie as seguintes diretivas NGINX se elas estiverem explicitamente especificadas nos arquivos de configuração:

• 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

Nós só mudamos os nomes das diretivas, sua lógica permanece a mesma. As diretivas com nomes anteriores serão descontinuadas em breve, então recomendamos que você as renomeie antes.

Atualize as variáveis de log do nó¶

Na nova versão do nó, as seguintes mudanças nas variáveis de log do nó foram implementadas:

• A variável wallarm_request_time foi renomeada para wallarm_request_cpu_time.

Só mudamos o nome da variável, a lógica dela permanece a mesma. O nome antigo ainda é suportado temporariamente, mas ainda assim é recomendado renomear a variável.

• A variável wallarm_request_mono_time foi adicionada - coloque-a na configuração do formato de log se precisar das informações de log sobre o tempo total sendo a soma de:

• Tempo na fila

• Tempo em segundos que a CPU gastou processando a solicitação

Ajuste as configurações do modo de filtragem do nó Wallarm para mudanças liberadas nas últimas versões¶

1. Verifique se o comportamento esperado das configurações listadas abaixo corresponde à lógica modificada dos modos de filtragem off e monitoring:

   • Diretiva wallarm_mode
   • Regra de filtragem geral configurada no Console Wallarm
   • Regras de filtragem de baixo nível configuradas no Console Wallarm

2. Se o comportamento esperado não corresponder à lógica modificada do modo de filtragem, ajuste as configurações do modo de filtragem para mudanças lançadas usando as instruções.

Transfira a configuração de detecção de ataque overlimit_res de diretivas para a regra¶

A partir da versão 3.6, você pode ajustar a detecção de ataque overlimit_res usando a regra no Console Wallarm.

Anteriormente, as diretivas NGINX wallarm_process_time_limit e wallarm_process_time_limit_block eram usadas. As diretivas listadas são consideradas obsoletas com o novo lançamento da regra e serão excluídas em futuros lançamentos.

Se as configurações de detecção de ataque overlimit_res forem personalizadas por meio das diretivas listadas, é recomendado transferi-las para a regra da seguinte forma:

1. Abra o Console Wallarm → Rules e prossiga para a configuração da regra Ajuste fino da detecção de ataque overlimit_res.

2. Configure a regra da mesma maneira que as diretivas NGINX:

   • A condição da regra deve corresponder ao bloco de configuração NGINX com as diretivas wallarm_process_time_limit e wallarm_process_time_limit_block especificadas.
   • O limite de tempo para o nó processar uma única solicitação (milissegundos): o valor de wallarm_process_time_limit.

   • Processamento de solicitações: a opção Parar processamento é recomendada.

     Risco de esgotamento da memória do sistema

     O limite de tempo alto e/ou continuação do processamento de solicitações após o limite ser excedido pode desencadear o esgotamento de memória ou o processamento de solicitações fora do tempo.

   • Registrar o ataque overlimit_res: a opção Registrar e exibir nos eventos é recomendada.

     Se o valor de wallarm_process_time_limit_block ou process_time_limit_block for off, escolha a opção Não criar evento de ataque.

   • A regra não possui opção explícita equivalente para a diretiva wallarm_process_time_limit_block. Se a regra definir Registrar e exibir nos eventos, o nó bloqueará ou passará o ataque overlimit_res dependendo do modo de filtragem do nó:

     • No modo monitoramento, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da solicitação.
     • No modo bloqueio seguro, o nó bloqueia a solicitação se ela for originada do endereço IP graylisted. Caso contrário, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da solicitação.
     • No modo block, o nó bloqueia a solicitação.

3. Exclua as diretivas NGINX wallarm_process_time_limit e wallarm_process_time_limit_block do arquivo de configuração NGINX.

   Se a detecção de ataque overlimit_res for ajustada usando tanto as diretivas quanto a regra, o nó processará as solicitações conforme a regra define.

Atualize o conteúdo do arquivo wallarm-status.conf¶

Atualize o conteúdo de /etc/nginx/conf.d/wallarm-status.conf da seguinte maneira:

server {
  listen 127.0.0.8:80;
  server_name localhost;

  allow 127.0.0.0/8;   # O acesso está disponível apenas para endereços de loopback do servidor de nó de filtragem  
  deny all;

  wallarm_mode off;
  disable_acl "on";   # A verificação das fontes de solicitação está desativada, os IPs da lista negra têm permissão para solicitar o serviço wallarm-status. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl
  access_log off;

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

Mais detalhes sobre a configuração do serviço de estatísticas

Passo 9: Reative o módulo de Verificação de ameaças ativas (somente se estiver atualizando o nó 2.16 ou abaixo)¶

Aprenda a recomendação sobre a configuração do módulo Verificação de ameaças ativas e reative-o, se necessário.

Depois de um tempo, verifique se a operação do módulo não está causando falsos positivos. Se descobrir falsos positivos, entre em contato com o suporte técnico da Wallarm.

Passo 10: Configure o tráfego para o nó Wallarm¶

Dependendo da abordagem de implantação em uso, realize as seguintes configurações:

Passo 11: Remova o nó antigo¶

1. Delete o nó antigo no Console Wallarm → Nós selecionando seu nó e clicando em Excluir.

2. Confirme a ação.

   Quando o nó é excluído do Cloud, ele para a filtragem de solicitações para suas aplicações. A exclusão do nó de filtragem não pode ser desfeita. O nó será excluído permanentemente da lista de nós.

3. Delete a máquina com o nó antigo ou apenas limpe-a dos componentes do nó Wallarm:

   DebianUbuntuCentOS or Amazon Linux 2.0.2021x and lowerAlmaLinux, Rocky Linux or 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
   

Atualização manual¶

Requisitos para atualização manual¶

• Acesso à conta com a função de Administrador no Console Wallarm no US Cloud ou EU Cloud

• Acesso a https://us1.api.wallarm.com se estiver trabalhando com o Wallarm Cloud dos EUA ou para https://api.wallarm.com se estiver trabalhando com o Wallarm Cloud da UE. Por favor, certifique-se de que o acesso não está bloqueado por um firewall

Procedimento de atualização¶

• Se os módulos de nó de filtragem e postanalítica estiverem instalados no mesmo servidor, siga as instruções abaixo para atualizar todos os pacotes.

• Se os módulos de nó de filtragem e postanalítica estiverem instalados em servidores diferentes, primeiro atualize o módulo postanalytics seguindo estas instruções e depois execute as etapas abaixo para os módulos de nó de filtragem.

Passo 1: Desative o módulo de Verificação de ameaças ativas (se estiver atualizando nó 2.16 ou abaixo)¶

Se estiver atualizando o nó Wallarm 2.16 ou abaixo, desative o módulo Verificação de ameaças ativas no Console Wallarm → Vulnerabilidades → Configurar.

A operação do módulo pode causar falsos positivos durante o processo de atualização. Desativar o módulo minimiza este risco.

Passo 2: Atualize a porta da API¶

Começando com a versão 4.0, o nó de filtragem carrega dados para a nuvem usando os endpoints da API us1.api.wallarm.com:443 (NUvem EUA) e api.wallarm.com:443 (Nuvem EU) em vez de us1.api.wallarm.com:444 e api.wallarm.com:444.

Se você atualizar o nó da versão 3.x ou inferior e seu servidor com o nó implantado tiver acesso limitado aos recursos externos, e o acesso for concedido a cada recurso separadamente, então após a atualização a sincronização entre o nó de filtragem e a nuvem irá parar.

Para restaurar a sincronização, em sua configuração, altere a porta 444 para 443 para o endpoint da API para cada recurso.

Passo 3: Atualize o NGINX para a versão mais recente¶

Atualize o NGINX para a versão mais recente usando as instruções relevantes:

sudo apt update
sudo apt -y install nginx

sudo yum update
sudo yum install -y nginx

Se sua infraestrutura precisa usar uma versão específica do NGINX, entre em contato com o suporte técnico da Wallarm para construir o módulo Wallarm para uma versão personalizada do NGINX.

Passo 4: Adicione novo repositório Wallarm¶

Exclua o endereço do repositório Wallarm anterior e adicione um repositório com um novo pacote de versão de nó Wallarm. Por favor, use os comandos para a plataforma apropriada.

CentOS and Amazon Linux 2.0.2021x and lower

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm

Debian e Ubuntu

1. Abra o arquivo com o endereço do repositório Wallarm no editor de texto instalado. Nestas instruções, vim é usado.

   sudo vim /etc/apt/sources.list.d/wallarm.list
   

2. Comente ou exclua o endereço do repositório anterior.

3. Adicione um novo endereço de repositório:

   Debian 10.x (buster)Debian 11.x (bullseye)Ubuntu 18.04 LTS (bionic)Ubuntu 20.04 LTS (focal)

   Não suportado pelo NGINX estável e NGINX Plus

   As versões oficiais do NGINX (estável e Plus) e, consequentemente, o nó Wallarm 4.4 e acima não podem ser instalados no Debian 10.x (buster). Use este SO apenas se o NGINX for instalado dos repositórios Debian/CentOS.

   deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/
   

   deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/
   

   deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/
   

   deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/
   

Passo 5: Migrar allowlists e denylists da versão anterior do nó Wallarm para 4.8 (somente se estiver atualizando nó 2.18 ou abaixo)¶

Se estiver atualizando nó 2.18 ou abaixo, migre a configuração de allowlist e denylist da versão anterior do nó Wallarm para a versão mais recente.

Passo 6: Atualize os pacotes Wallarm¶

Nó de filtragem e postanalytics no mesmo servidor¶

Execute o comando a seguir para atualizar os módulos de nó de filtragem e postanalítica:

sudo apt update
sudo apt dist-upgrade

W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:As seguintes
assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999
E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' não está assinado.
N: Atualizar a partir de tal repositório não pode ser feito de maneira segura, e é, portanto, desativado por padrão.
N: Veja a página man do apt-secure(8) para detalhes da criação de repositório e configuração do usuário.

curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

sudo apt update
sudo apt dist-upgrade

W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:As seguintes
assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999
E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' não está assinado.
N: Atualizar a partir de tal repositório não pode ser feito de maneira segura, e é, portanto, desativado por padrão.
N: Veja a página man do apt-secure(8) para detalhes da criação de repositório e configuração do usuário.

curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

sudo yum update

sudo yum update

sudo yum update

Nó de filtragem e postanalytics em servidores diferentes¶

1. Atualize os pacotes do módulo postanalytics seguindo estas instruções.

2. Atualize os pacotes do nó Wallarm:

   DebianUbuntuCentOS or Amazon Linux 2.0.2021x and lowerAlmaLinux, Rocky Linux or Oracle Linux 8.xRHEL 8.x

   sudo apt update
   sudo apt dist-upgrade
   

   O erro "as assinaturas não puderam ser verificadas"

   Se as chaves GPG adicionadas expirarem, o seguinte erro será retornado:

   W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:As seguintes
   assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999
   E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' não está assinado.
   N: Atualizar a partir de tal repositório não pode ser feito de maneira segura, e é, portanto, desativado por padrão.
   N: Veja a página man do apt-secure(8) para detalhes da criação de repositório e configuração do usuário.
   

   Para corrigir o problema, importe novas chaves GPG para os pacotes Wallarm e então atualize os pacotes usando os seguintes comandos:

   curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
   sudo apt update
   sudo apt dist-upgrade
   

   Atualizando as dependências do Wallarm

   O comando sudo apt dist-upgrade atualiza tanto os pacotes Wallarm quanto as dependências do nó de filtragem. É a opção recomendada para a atualização, uma vez que assegura o correto funcionamento da nova versão do nó de filtragem.

   sudo apt update
   sudo apt dist-upgrade
   

   O erro "as assinaturas não puderam ser verificadas"

   Se as chaves GPG adicionadas expirarem, o seguinte erro será retornado:

   W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:As seguintes
   assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999
   E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' não está assinado.
   N: Atualizar a partir de tal repositório não pode ser feito de maneira segura, e é, portanto, desativado por padrão.
   N: Veja a página man do apt-secure(8) para detalhes da criação de repositório e configuração do usuário.
   

   Para corrigir o problema, importe novas chaves GPG para os pacotes Wallarm e então atualize os pacotes usando os seguintes comandos:

   curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
   sudo apt update
   sudo apt dist-upgrade
   

   Atualizando as dependências do Wallarm

   O comando sudo apt dist-upgrade atualiza tanto os pacotes Wallarm quanto as dependências do nó de filtragem. É a opção recomendada para a atualização, uma vez que assegura o correto funcionamento da nova versão do nó de filtragem.

   sudo yum update
   

   sudo yum update
   

   sudo yum update
   

3. Se o gerenciador de pacotes pedir confirmação para reescrever o conteúdo do arquivo de configuração /etc/cron.d/wallarm-node-nginx:

   1. Certifique-se de que a migração das listas de IP foi concluída.
   2. Confirme a reescrita do arquivo usando a opção Y.

   O gerenciador de pacotes pediria confirmação para reescrever se o arquivo /etc/cron.d/wallarm-node-nginx tivesse sido alterado nas versões anteriores do nó Wallarm. Como a lógica da lista de IPs foi alterada no nó Wallarm 3.x, o conteúdo do /etc/cron.d/wallarm-node-nginx foi atualizado de acordo. Para que a lista de IPs negados funcione corretamente, o nó Wallarm 3.x deve usar o arquivo de configuração atualizado.

   Por padrão, o gerenciador de pacotes usa a opção N, mas a opção Y é necessária para a correta operação da lista de IPs negados no nó Wallarm 3.x.

Passo 7: Atualize o tipo do nó¶

O nó implantado tem o tipo regular descontinuado que é substituído agora pelo novo tipo Nó Wallarm.

É recomendável instalar o novo tipo de nó em vez do descontinuado durante a migração para a versão 4.8. O tipo de nó regular será removido em lançamentos futuros. Por favor, migre antes.

Para substituir o nó regular pelo nó Wallarm:

1. Abra o Wallarm Console → Nós no Cloud US ou Cloud EU e crie o nó do tipo Nó Wallarm.

   

2. Copie o token gerado.

3. Pausar o serviço NGINX no servidor com o nó da versão anterior:

   DebianUbuntuCentOS or Amazon Linux 2.0.2021x and lowerAlmaLinux, Rocky Linux or Oracle Linux 8.xRHEL 8.x

   sudo systemctl stop nginx
   

   sudo service nginx stop
   

   sudo systemctl stop nginx
   

   sudo systemctl stop nginx
   

   sudo systemctl stop nginx
   

   A pausa do serviço NGINX mitiga o risco de cálculo incorreto do RPS.

4. Execute o script register-node para executar o Nó Wallarm:

   Nuvem EUANuvem UE

   sudo /usr/share/wallarm-common/register-node -t <TOKEN> -H us1.api.wallarm.com --force
   

   sudo /usr/share/wallarm-common/register-node -t <TOKEN> --force
   

   • <TOKEN> é o valor copiado do token do nó ou do token de API com a função Deploy.
   • A opção --force força a reescrita das credenciais de acesso ao Wallarm Cloud especificadas no arquivo /etc/wallarm/node.yaml.

Passo 8: Atualize a página de bloqueio Wallarm¶

Na nova versão do nó, a página de amostra de bloqueio da Wallarm foi modificada. O logotipo e o e-mail de suporte na página agora estão vazios por padrão.

Se a página &/usr/share/nginx/html/wallarm_blocked.html foi configurada para ser retornada em resposta a solicitações bloqueadas, copie e personalize a nova versão de uma página de amostra.

Passo 9: Renomeie as diretivas NGINX descontinuadas¶

Renomeie as seguintes diretivas NGINX se elas estiverem explicitamente especificadas nos arquivos de configuração:

• 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

Nós só mudamos os nomes das diretivas, sua lógica permanece a mesma. As diretivas com nomes anteriores serão descontinuadas em breve, então recomendamos que você as renomeie antes.

Passo 10: Atualize as variáveis de log do nó¶

Na nova versão do nó, as seguintes mudanças nas variáveis de log do nó foram implementadas:

• A variável wallarm_request_time foi renomeada para wallarm_request_cpu_time.

Só mudamos o nome da variável, a lógica dela permanece a mesma. O nome antigo ainda é suportado temporariamente, mas ainda assim é recomendado renomear a variável.

• A variável wallarm_request_mono_time foi adicionada - coloque-a na configuração do formato de log se precisar das informações de log sobre o tempo total sendo a soma de:

• Tempo na fila

• Tempo em segundos que a CPU gastou processando a solicitação

Passo 11: Ajuste as configurações do modo de filtragem do nó Wallarm para mudanças liberadas nas últimas versões¶

1. Verifique se o comportamento esperado das configurações listadas abaixo corresponde à lógica modificada dos modos de filtragem off e monitoring:

   • Diretiva wallarm_mode
   • Regra de filtragem geral configurada no Console Wallarm
   • Regras de filtragem de baixo nível configuradas no Console Wallarm

2. Se o comportamento esperado não corresponder à lógica modificada do modo de filtragem, ajuste as configurações do modo de filtragem para mudanças lançadas usando as instruções.

Passo 12: Transfira a configuração de detecção de ataque overlimit_res de diretivas para a regra¶

A partir da versão 3.6, você pode ajustar a detecção de ataque overlimit_res usando a regra no Console Wallarm.

Anteriormente, as diretivas NGINX wallarm_process_time_limit e wallarm_process_time_limit_block eram usadas. As diretivas listadas são consideradas obsoletas com o novo lançamento da regra e serão excluídas em futuros lançamentos.

Se as configurações de detecção de ataque overlimit_res forem personalizadas por meio das diretivas listadas, é recomendado transferi-las para a regra da seguinte forma:

1. Abra o Console Wallarm → Rules e prossiga para a configuração da regra Ajuste fino da detecção de ataque overlimit_res.

2. Configure a regra da mesma maneira que as diretivas NGINX:

   • A condição da regra deve corresponder ao bloco de configuração NGINX com as diretivas wallarm_process_time_limit e wallarm_process_time_limit_block especificadas.
   • O limite de tempo para o nó processar uma única solicitação (milissegundos): o valor de wallarm_process_time_limit.

   • Processamento de solicitações: a opção Parar processamento é recomendada.

     Risco de esgotamento da memória do sistema

     O limite de tempo alto e/ou continuação do processamento de solicitações após o limite ser excedido pode desencadear o esgotamento de memória ou o processamento de solicitações fora do tempo.

   • Registrar o ataque overlimit_res: a opção Registrar e exibir nos eventos é recomendada.

     Se o valor de wallarm_process_time_limit_block ou process_time_limit_block for off, escolha a opção Não criar evento de ataque.

   • A regra não possui opção explícita equivalente para a diretiva wallarm_process_time_limit_block. Se a regra definir Registrar e exibir nos eventos, o nó bloqueará ou passará o ataque overlimit_res dependendo do modo de filtragem do nó:

     • No modo monitoramento, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da solicitação.
     • No modo bloqueio seguro, o nó bloqueia a solicitação se ela for originada do endereço IP graylisted. Caso contrário, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da solicitação.
     • No modo block, o nó bloqueia a solicitação.

3. Exclua as diretivas NGINX wallarm_process_time_limit e wallarm_process_time_limit_block do arquivo de configuração NGINX.

   Se a detecção de ataque overlimit_res for ajustada usando tanto as diretivas quanto a regra, o nó processará as solicitações conforme a regra define.

Passo 13: Atualize o conteúdo do arquivo wallarm-status.conf¶

Atualize o conteúdo de /etc/nginx/conf.d/wallarm-status.conf da seguinte maneira:

server {
  listen 127.0.0.8:80;
  server_name localhost;

  allow 127.0.0.0/8;   # O acesso está disponível apenas para endereços de loopback do servidor de nó de filtragem  
  deny all;

  wallarm_mode off;
  disable_acl "on";   # A verificação das fontes de solicitação está desativada, os IPs da lista negra têm permissão para solicitar o serviço wallarm-status. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl
  access_log off;

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

Mais detalhes sobre a configuração do serviço de estatísticas

Passo 14: Reinicie o NGINX¶

Reinicie o NGINX usando o seguinte comando:

sudo systemctl restart nginx

Passo 15: Teste a operação do nó Wallarm¶

Para testar a operação do novo nó:

1. Envie a solicitação com teste de ataques SQLI e XSS para o endereço do recurso protegido:

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

2. Abra a seção Console Wallarm → Eventos no Nuvem US ou Nuvem EU e certifique-se de que os ataques estão exibidos na lista.

3. Assim que seus dados armazenados na Cloud (regras, listas de IP) forem sincronizados com o novo nó, realize alguns ataques de teste para se certificar de que suas regras funcionam conforme o esperado.

Passo 16: Exclua o nó da versão anterior¶

Uma vez que a operação do novo nó está devidamente testada, abra a seção Nós do Console Wallarm e exclua o nó regular da versão anterior da lista.

Se o módulo postanalytics estiver instalado em um servidor separado, exclua também a instância de nó relacionada a este módulo.

Personalização de configurações¶

Os módulos Wallarm são atualizados para a versão 4.8. As configurações do nó de filtragem anterior serão aplicadas automaticamente à nova versão. Para fazer configurações adicionais, use as diretivas disponíveis.

Opções comuns de personalização:

• Configuração do modo de filtragem

• Logando variáveis do nó Wallarm

• Usando o balanceador do servidor proxy atrás do nó de filtragem

• Limitando o tempo de processamento de uma única requisição na diretiva wallarm_process_time_limit

• Limitando o tempo de espera da resposta do servidor na diretiva NGINX proxy_read_timeout

• Limitando o tamanho máximo da solicitação na diretiva NGINX client_max_body_size

• Configurando a resolução de DNS dinâmico no 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