Opções de configuração para o nó Wallarm baseado em NGINX¶

Saiba mais sobre as opções de ajuste fino disponíveis para os módulos NGINX da Wallarm para obter o máximo da solução Wallarm.

Diretivas Wallarm¶

disable_acl¶

Permite a desativação da análise de origens de solicitações. Se desativado (on), o nó de filtragem não baixa listas de IP do Wallarm Cloud e pula a análise de IPs de origem de solicitação.

wallarm_acl_access_phase¶

A diretiva obriga o nó Wallarm baseado em NGINX a bloquear solicitações originadas de IPs na lista de negação na fase de acesso NGINX, o que significa:

• Com wallarm_acl_access_phase on, o nó Wallarm bloqueia imediatamente quaisquer solicitações de IPs na lista de negação em qualquer modo de filtração e não procura sinais de ataque em solicitações de IPs na lista de negação.

  Este é o valor padrão e recomendado pois faz as listas de negação funcionarem de maneira padrão e reduz significativamente a carga da CPU do nó.

• Com wallarm_acl_access_phase off, o nó Wallarm analisa primeiro os sinais de ataque nas solicitações e então, se operando no modo block ou safe_blocking, bloqueia solicitações originadas de IPs na lista de negação.

  No modo de filtração off, o nó não analisa solicitações e não verifica listas de negação.

  No modo de filtração monitoring, o nó procura sinais de ataque em todas as solicitações, mas nunca bloqueia, mesmo se o IP de origem estiver na lista de negação.

  O comportamento do nó Wallarm com wallarm_acl_access_phase off aumenta significativamente a carga da CPU do nó.

wallarm_acl_export_enable¶

A diretiva habilita on/desabilita off o envio de estatísticas sobre as solicitações dos IPs na lista de negação do nó para a Nuvem.

• Com wallarm_acl_export_enable on, as estatísticas sobre as solicitações dos IPs na lista de negação serão exibidas na seção Eventos.

• Com wallarm_acl_export_enable off, as estatísticas sobre as solicitações dos IPs na lista de negação não serão exibidas.

wallarm_api_conf¶

Um caminho para o arquivo node.yaml, que contém requisitos de acesso para a API Wallarm.

Exemplo:

wallarm_api_conf /etc/wallarm/node.yaml

Usado para enviar solicitações serializadas do nó de filtragem diretamente para a API Wallarm (Cloud) em vez de fazer o upload para o módulo postanalytics (Tarantool).

Apenas solicitações com ataques são enviadas para a API. As solicitações sem ataques não são salvas.

Exemplo do conteúdo do arquivo node.yaml:

# Credenciais de conexão com a API

hostname: <algum nome>
uuid: <algum uuid>
secret: <algum secret>

# Parâmetros de conexão com a API (os parâmetros abaixo são usados por padrão)

api:
  host: api.wallarm.com
  port: 443
  ca_verify: true

wallarm_application¶

Identificador único da aplicação protegida a ser usado na Wallarm Cloud. O valor pode ser um número inteiro positivo, exceto 0.

Identificadores únicos podem ser definidos tanto para os domínios da aplicação quanto para os caminhos do domínio, por exemplo:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 1;
    location / {
            proxy_pass http://exemplo.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 2;
    location / {
            proxy_pass http://teste.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    location /login {
            proxy_pass http://exemplo.com/login;
            include proxy_params;
            wallarm_application 3;
    }

    location /users {
            proxy_pass http://exemplo.com/users;
            include proxy_params;
            wallarm_application 4;
    }
}

Mais detalhes sobre a configuração de aplicações →

wallarm_block_page¶

Permite a configuração da resposta à solicitação bloqueada.

Mais detalhes sobre a configuração de página e código de erro de bloqueio →

wallarm_block_page_add_dynamic_path¶

Esta diretiva é usada para inicializar a página de bloqueio que possui variáveis NGINX em seu código e o caminho para esta página de bloqueio também é definido usando uma variável. Caso contrário, a diretiva não é usada.

Mais detalhes sobre a configuração de página e código de erro de bloqueio →

wallarm_cache_path¶

Um diretório em que o catálogo de backup para o armazenamento de cópia do arquivo proton.db e o arquivo de regras personalizado é criado ao inicializar o servidor. Este diretório deve ser gravável para o cliente que executa o NGINX.

wallarm_custom_ruleset_path¶

Um caminho para o arquivo conjunto de regras personalizado que contém informações sobre a estrutura da aplicação protegida e as configurações do nó de filtragem.

wallarm_enable_libdetection¶

Ativa/desativa a validação adicional dos ataques de injeção de SQL por meio da biblioteca libdetection. O uso de libdetection garante a detecção dupla de ataques e reduz o número de falsos positivos.

A análise de solicitações com a biblioteca libdetection é habilitada por padrão em todas as opções de implementação. Para reduzir o número de falsos positivos, recomendamos que a análise permaneça habilitada.

Mais detalhes sobre libdetection →

wallarm_fallback¶

Com o valor definido como on, o NGINX tem a habilidade de entrar em um modo de emergência; se o proton.db ou o conjunto de regras personalizado não puderem ser baixados, esta configuração desabilita o módulo Wallarm para os blocos http, server e location, para os quais os dados não conseguem ser baixados. O NGINX continua funcionando.

wallarm_force¶

Define a análise das solicitações e a geração de regras personalizadas com base no tráfego espelhado do NGINX. Veja Analisando tráfego espelhado com NGINX.

wallarm_general_ruleset_memory_limit¶

Define um limite para a quantidade máxima de memória que pode ser usada por uma instância do proton.db e um arquivo de conjunto de regras personalizadas.

Se o limite de memória for excedido durante o processamento de alguma solicitação, o usuário receberá um erro 500.

Os seguintes sufixos podem ser usados neste parâmetro:

• k ou K para kilobytes

• m ou M para megabytes

• g ou G para gigabytes

Um valor de 0 desativa o limite.

wallarm_global_trainingset_path¶

wallarm_file_check_interval¶

Define um intervalo entre verificar novos dados no proton.db e no arquivo de conjunto de regras personalizadas. A unidade de medida é especificada no sufixo conforme abaixo:

• sem sufixo para minutos

• s para segundos

• ms para milissegundos

wallarm_instance¶

wallarm_key_path¶

Um caminho para a chave privada Wallarm usada para encriptação/descriptografia dos arquivos proton.db e conjunto de regras personalizadas.

wallarm_local_trainingset_path¶

wallarm_mode¶

Modo de processamento de tráfego:

• off

• monitoring

• safe_blocking

• block

A utilização de wallarm_mode pode ser restrita pela diretiva wallarm_mode_allow_override.

Instruções detalhadas sobre a configuração do modo de filtração →

wallarm_mode_allow_override¶

Gerencia a habilidade de substituir os valores de wallarm_mode via regras de filtragem baixadas da Wallarm Cloud (conjunto de regras personalizadas):

• off - as regras personalizadas são ignoradas.
• strict - regras personalizadas só podem fortalecer o modo de operação.
• on - é possível fortalecer e suavizar o modo de operação.

Por exemplo, com wallarm_mode monitoring e wallarm_mode_allow_override strict configurados, o Wallarm Console pode ser usado para habilitar o bloqueio de algumas solicitações, mas a análise de ataques não pode ser totalmente desativada.

Instruções detalhadas sobre a configuração do modo de filtração →

wallarm_parse_response¶

Se analisar ou não as respostas da aplicação. A análise de resposta é necessária para a detecção de vulnerabilidades durante a detecção passiva e verificação ativa de ameaças.

Os possíveis valores são on (a análise da resposta está habilitada) e off (a análise da resposta está desabilitada).

wallarm_parse_websocket ¶

O Wallarm oferece suporte total ao WebSockets sob o plano de assinatura API Security. Por padrão, as mensagens do WebSockets não são analisadas quanto a ataques.

Para forçar o recurso, ative o plano de assinatura API Security e use a diretiva wallarm_parse_websocket.

Possíveis valores:

• on: a análise de mensagens está habilitada.
• off: a análise de mensagens está desabilitada.

wallarm_parser_disable¶

Permite a desativação de parsers. Os valores de diretiva correspondem ao nome do parser a ser desativado:

• cookie
• zlib
• htmljs
• json
• multipart
• base64
• percent
• urlenc
• xml
• jwt

Exemplo

wallarm_parser_disable base64;
wallarm_parser_disable xml;
location /ab {
    wallarm_parser_disable json;
    wallarm_parser_disable base64;
    proxy_pass http://exemplo.com;
}
location /zy {
    wallarm_parser_disable json;
    proxy_pass http://exemplo.com;
}

wallarm_parse_html_response¶

Se aplicar ou não os parsers HTML ao código HTML recebido na resposta da aplicação. Os possíveis valores são on (o parser HTML é aplicado) e off (o parser HTML não é aplicado).

Este parâmetro só é efetivo se wallarm_parse_response on.

wallarm_partner_client_uuid¶

Identificador único do inquilino para o nó Wallarm multi-inquilino. O valor deve ser uma string no formato UUID, por exemplo:

• 11111111-1111-1111-1111-111111111111

• 123e4567-e89b-12d3-a456-426614174000

Exemplo de configuração:

server {
  server_name  inquilino1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  ...
  location /login {
     wallarm_application 21;
     ...
  }
  location /users {
     wallarm_application 22;
     ...
  }

server {
  server_name  inquilino1-1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  wallarm_application 23;
  ...
}

server {
  server_name  inquilino2.com;
  wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222;
  ...
}
...
}

Na configuração acima:

• O Inquilino é o cliente do parceiro. O parceiro tem 2 clientes.

• O tráfego direcionado para inquilino1.com e inquilino1-1.com será associado ao cliente 11111111-1111-1111-1111-111111111111.

• O tráfego direcionado para inquilino2.com será associado ao cliente 22222222-2222-2222-2222-222222222222.

• O primeiro cliente também possui 3 aplicativos, especificados via a diretiva wallarm_application:

  • inquilino1.com/login - wallarm_application 21
  • inquilino1.com/users - wallarm_application 22
  • inquilino1-1.com - wallarm_application 23

  O tráfego direcionado a esses 3 caminhos será associado à aplicação correspondente, e o restante será o tráfego genérico do primeiro cliente.

wallarm_process_time_limit¶

Configura o limite de tempo para o processamento de uma única solicitação pelo nó Wallarm.

Se o tempo exceder o limite, será registrado um erro no log e o pedido será marcado como o ataque overlimit_res. Dependendo do valor de wallarm_process_time_limit_block, o ataque pode ser bloqueado, monitorado ou ignorado.

O valor é especificado em milissegundos sem unidades, por exemplo:

wallarm_process_time_limit 1200; # 1200 milissegundos
wallarm_process_time_limit 2000; # 2000 milissegundos

wallarm_process_time_limit_block¶

A capacidade de gerenciar o bloqueio de solicitações, que excedem o limite de tempo definido na diretiva wallarm_process_time_limit:

• on: as solicitações são sempre bloqueadas a menos que wallarm_mode off

• off: as solicitações são sempre ignoradas

  Risco de contornar a proteção

  O valor off deve ser usado com cuidado, pois este valor desabilita a proteção contra ataques overlimit_res.

  É recomendado usar o valor off apenas nas localizações estritamente específicas onde é realmente necessário, por exemplo, onde o upload de arquivos grandes é realizado e onde não há risco de contornar a proteção e explorar a vulnerabilidade.

  É fortemente recomendado não definir wallarm_process_time_limit_block para off globalmente para blocos http ou server.

• attack: depende do modo de bloqueio de ataque definido na diretiva wallarm_mode:

  • off: as solicitações não são processadas.
  • monitoring: as solicitações são ignoradas, mas os detalhes sobre os ataques overlimit_res são enviados para a Wallarm Cloud e exibidos no Wallarm Console.
  • safe_blocking: apenas solicitações originárias de endereços IP na lista cinza são bloqueadas e os detalhes sobre todos os ataques overlimit_res são enviados para a Wallarm Cloud e exibidos no Wallarm Console.
  • block: as solicitações são bloqueadas.

Independentemente do valor da diretiva, solicitações do tipo de ataque overlimit_res são enviadas para a Wallarm Cloud, exceto quando wallarm_mode off;.

wallarm_protondb_path¶

Um caminho para o arquivo proton.db que possui as configurações globais para a filtragem de solicitações, que não dependem da estrutura da aplicação.

wallarm_rate_limit¶

Configura a limitação de taxa no seguinte formato:

wallarm_rate_limit <KEY_TO_MEASURE_LIMITS_FOR> rate=<RATE> burst=<BURST> delay=<DELAY>;

• KEY_TO_MEASURE_LIMITS_FOR - uma chave que deseja medir os limites. Pode conter texto, variáveis NGINX e sua combinação.

  Por exemplo: "$remote_addr +location_name" para limitar solicitações originadas do mesmo IP e direcionadas ao endpoint /login.

• rate=<RATE> (obrigatório) - limite de taxa, pode ser rate=<número>r/s ou rate=<número>r/m.

• burst=<BURST> (opcional) - número máximo de solicitações excessivas a serem armazenadas em buffer assim que o RPS/RPM especificado for excedido e a serem processadas assim que a taxa voltar ao normal. 0 por padrão.

• delay=<DELAY> - se o valor <BURST> for diferente de 0, você pode controlar se manterá o RPS/RPM definido entre a execução das solicitações excessivas em buffer. nodelay aponta para o processamento simultâneo de todas as solicitações excessivas em buffer, sem o atraso do limite de taxa. Valor numérico implica o processamento simultâneo do número especificado de solicitações excessivas, outras são processadas com atraso definido em RPS/RPM.

Exemplo:

wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5;

wallarm_rate_limit_enabled¶

Habilita/desabilita a limitação de taxa Wallarm.

Se off, a regra de limitação de taxa (recomendada) e a diretiva wallarm_rate_limit não funcionam.

wallarm_rate_limit_log_level¶

O nível para o registro das solicitações rejeitadas pelo controle de limitação de taxa. Pode ser: info, notice, warn, error.

wallarm_rate_limit_status_code¶

Código para retornar em resposta às solicitações rejeitadas pelo módulo de limitação de taxa da Wallarm.

wallarm_rate_limit_shm_size¶

Define a quantidade máxima de memória compartilhada que o módulo de limitação de taxa da Wallarm pode consumir.

Com um comprimento médio de chave de 64 bytes (caracteres), e wallarm_rate_limit_shm_size de 64MB, o módulo pode lidar com cerca de 130.000 chaves únicas simultaneamente. Aumentando a memória por dois, dobra a capacidade do módulo de maneira linear.

Uma chave é um valor único de um ponto de solicitação que o módulo usa para medir limites. Por exemplo, se o módulo está limitando conexões com base em endereços IP, cada endereço IP único é considerado uma única chave. Com o valor de diretiva padrão, o módulo pode processar solicitações originadas de ~130.000 IPs diferentes simultaneamente.

wallarm_request_chunk_size¶

Limita o tamanho da parte da solicitação que é processada durante uma iteração. Você pode configurar um valor personalizado para a diretiva wallarm_request_chunk_size em bytes, atribuindo um número inteiro a ela. A diretiva também aceita os seguintes sufixos:

• k ou K para kilobytes

• m ou M para megabytes

• g ou G para gigabytes

wallarm_request_memory_limit¶

Define um limite para a quantidade máxima de memória que pode ser usada para o processamento de uma única solicitação.

Se o limiar for ultrapassado, o processamento da solicitação será interrompido e o usuário receberá um erro 500.

Os seguintes sufixos podem ser usados neste parâmetro:

• k ou K para kilobytes

• m ou M para megabytes

• g ou G para gigabytes

Um valor de 0 desativa o limite.

Por padrão, os limites estão desativados.

wallarm_stalled_worker_timeout¶

Define um limite de tempo para um único processamento de solicitação para um worker NGINX em segundos.

Se o tempo ultrapassar o limite, os dados sobre os trabalhadores NGINX serão gravados nos parâmetros de estatística stalled_workers_count e stalled_workers.

wallarm_status¶

Controla a operação do serviço de estatísticas Wallarm.

O valor da diretiva tem o seguinte formato:

wallarm_status [on|off] [format=json|prometheus];

É altamente recomendado configurar o serviço de estatísticas em um arquivo de configuração separado /etc/nginx/conf.d/wallarm-status.conf e não usar a diretiva wallarm_status em outros arquivos que você usa ao configurar o NGINX, porque este último pode ser inseguro.

Além disso, é fortemente recomendado não alterar nenhuma das linhas existentes da configuração wallarm-status padrão, pois isso pode corromper o processo de envio de dados de métrica para a nuvem Wallarm.

wallarm_tarantool_upstream¶

Com o wallarm_tarantool_upstream, você pode equilibrar as solicitações entre vários servidores postanalytics.

Exemplo:

upstream wallarm_tarantool {
    server 127.0.0.1:3313 max_fails=0 fail_timeout=0 max_conns=1;
    keepalive 1;
}

# omitido

wallarm_tarantool_upstream wallarm_tarantool;

Confira também Module ngx_http_upstream_module.

wallarm_timeslice¶

Um limite no tempo que um nó de filtragem gasta em uma iteração de processamento de uma solicitação antes de mudar para a próxima solicitação. Ao atingir o limite de tempo, o nó de filtragem procede ao processamento da próxima solicitação na fila. Após realizar uma iteração em cada uma das solicitações na fila, o nó realiza a segunda iteração de processamento na primeira solicitação da fila.

Você pode usar sufixos de intervalos de tempo que estão descritos na documentação NGINX para atribuir diferentes valores de unidade de tempo à diretiva.

wallarm_ts_request_memory_limit¶

wallarm_unpack_response¶

Se descompactar ou não os dados compactados retornados na resposta da aplicação. Os possíveis valores são on (a descompactação está habilitada) e off (a descompactação está desativada).

Este parâmetro só é efetivo se wallarm_parse_response on.

wallarm_upstream_backend¶

Um método para envio de solicitações serializadas. As solicitações podem ser enviadas para Tarantool ou para a API.

Possíveis valores de diretiva:

• tarantool

• api

Dependendo das outras diretivas, o valor padrão será atribuído da seguinte forma:

• tarantool - se não houver diretiva wallarm_api_conf na configuração.

• api - se houver uma diretiva wallarm_api_conf, mas não houver diretiva wallarm_tarantool_upstream na configuração.

  Note

  Se as diretivas wallarm_api_conf e wallarm_tarantool_upstream estiverem presentes simultaneamente na configuração, ocorrerá um erro de configuração do formulário diretiva ambígua do backend upstream wallarm.

wallarm_upstream_connect_attempts¶

Define o número de reconexões imediatas para o Tarantool ou Wallarm API.
Se uma conexão com o Tarantool ou API for encerrada, a tentativa de reconexão não ocorrerá. No entanto, isso não ocorre quando não há mais conexões e a fila de solicitações serializadas não está vazia.

wallarm_upstream_reconnect_interval¶

Define o intervalo entre tentativas de reconexão para o Tarantool ou Wallarm API após o número de tentativas malsucedidas exceder o limite wallarm_upstream_connect_attempts.

wallarm_upstream_connect_timeout¶

Define um tempo limite para a conexão com o Tarantool ou Wallarm API.

wallarm_upstream_queue_limit¶

Define um limite para o número de solicitações serializadas.
Definir simultaneamente o parâmetro wallarm_upstream_queue_limit e não definir o parâmetro wallarm_upstream_queue_memory_limit significa que não haverá limite para este último.

wallarm_upstream_queue_memory_limit¶

Define um limite para o volume total de solicitações serializadas.
Definir simultaneamente o parâmetro wallarm_upstream_queue_memory_limit e não definir o parâmetro wallarm_upstream_queue_limit significa que não haverá limite para este último.

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