Trabalhando com Logs do Nó de Filtro¶

Um nó de filtro armazena os seguintes arquivos de log no diretório /var/log/wallarm:

• brute-detect.log: o log da recuperação dos contadores relacionados ao ataque de força bruta no cluster do nó de filtro.

• export-attacks.log: o log da exportação dos dados dos ataques do módulo pós-analítico para a nuvem Wallarm.

• export-environment.log: o log da coleta das versões do pacote Wallarm instalado e do upload desses dados para a nuvem Wallarm a serem exibidos nos detalhes do nó de filtragem no console Wallarm. Esses processos são executados uma vez por hora.

• syncnode.log: o log da sincronização do nó de filtro com a nuvem Wallarm (isso inclui a busca dos arquivos LOM e proton.db da nuvem).

• tarantool.log: o log das operações do módulo pós-analítico.

• sync-ip-lists.log (nomeado como sync-blacklist.log nas versões anteriores do nó): o log da sincronização do nó de filtragem com os endereços IP adicionados às listas IP como objetos únicos ou sub-redes.

• sync-ip-lists-source.log (nomeado como sync-mmdb.log nas versões anteriores do nó): o log da sincronização do nó de filtragem com os endereços IP registrados em países, regiões e data centers a partir das listas IP.

• appstructure.log (somente nos contêineres Docker): o log da atividade do módulo Descoberta de API.

• registernode_loop.log (somente nos contêineres Docker): o log da atividade do script de início que executa o script register-node enquanto ele é executado com sucesso.

• weak-jwt-detect.log: o log da detecção da vulnerabilidade JWT.

Configurando o Log Extendido para o Nó de Filtro Baseado em NGINX¶

NGINX escreve logs das solicitações processadas (logs de acesso) em um arquivo de log separado, usando o formato de log combined predefinido por padrão.

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $request_id $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" ';

Você pode definir e usar um formato de log personalizado incluindo uma ou várias variáveis do nó de filtro (além de outras variáveis do NGINX, se necessário). O arquivo de log NGINX permitirá diagnósticos de nó de filtro muito mais rápidos.

Variáveis do Nó de Filtro¶

Você pode usar as seguintes variáveis do nó de filtro ao definir o formato de log do NGINX:

Exemplo de Configuração¶

Vamos supor que você precise especificar o formato de log estendido chamado wallarm_combined que inclui as seguintes variáveis:

• todas as variáveis usadas no formato combined

• todas as variáveis do nó de filtro

Para fazer isso, execute as seguintes ações:

1. As linhas abaixo descrevem o formato de log desejado. Adicione-as ao bloco http do arquivo de configuração do NGINX.

   log_format wallarm_combined '$remote_addr - $remote_user [$time_local] '
                               '"$request" $request_id $status $body_bytes_sent '
                               '"$http_referer" "$http_user_agent" '
                               '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list';
   

2. Ative o formato de log estendido adicionando a seguinte diretiva ao mesmo bloco como na primeira etapa:

   access_log /var/log/nginx/access.log wallarm_combined;

   Os logs de solicitações processadas serão escritos no formato wallarm_combined no arquivo /var/log/nginx/access.log.

   Logging Condicional

   Com a diretiva listada acima, todas as solicitações processadas serão registradas em um arquivo de log, inclusive aquelas que não estão relacionadas a um ataque.

   Você pode configurar o log condicional para gravar logs apenas para as solicitações que fazem parte de um ataque (o valor da variável wallarm_attack_type não é zero para essas solicitações). Para fazer isso, adicione uma condição à diretiva mencionada: access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;

   Isso pode ser útil se você quiser reduzir o tamanho de um arquivo de log, ou se você integrar um nó de filtro com uma das soluções SIEM.

3. Reinicie o NGINX executando um dos seguintes comandos, dependendo do sistema operacional que você está usando:

   DebianUbuntuCentOS ou Amazon Linux 2.0.2021x e versões anterioresAlmaLinux, Rocky Linux ou Oracle Linux 8.xRHEL 8.x

   sudo systemctl restart nginx
   

   sudo service nginx restart
   

   sudo systemctl restart nginx
   

   sudo systemctl restart nginx
   

   sudo systemctl restart 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