Esta página foi traduzida pela API Cloud Translation.

Encaminhador do Chronicle para Windows no Docker

Neste documento, descrevemos como instalar e configurar o encaminhador do Chronicle para Windows no Docker.

Requisitos do sistema

Confira a seguir recomendações gerais. Para receber recomendações específicas para seu sistema, entre em contato com o suporte do Chronicle.

Versão do Windows Server: o encaminhador Chronicle é compatível com o Microsoft Windows Server 2022.
RAM: 1,5 GB para cada tipo de registro coletado. Por exemplo, detecção e resposta de endpoint (EDR, na sigla em inglês), DNS e DHCP são tipos de registro separados. Você precisaria de 4,5 GB de RAM para coletar os dados dos três. Para conferir uma lista de analisadores padrão e tipos de registro compatíveis, consulte analisadores padrão compatíveis.
CPU: duas CPUs são suficientes para processar menos de 10.000 eventos por segundo (EPS) no total em todos os tipos de dados. Se você pretende enviar mais de 10.000 EPS, serão necessárias de 4 a 6 CPUs.
Disco: 100 MB de espaço em disco é suficiente, independente da quantidade de dados que o encaminhador do Chronicle processe. É possível armazenar o disco em buffer adicionando os parâmetros write_to_disk_buffer_enabled e write_to_disk_dir_path ao arquivo de configuração.

Exemplo:
```
- <collector>:
     common:
         ...
         write_to_disk_buffer_enabled: true
         write_to_disk_dir_path: directory_path
         ...
```

Intervalos de endereços IP do Google

Talvez você precise que o intervalo de endereços IP seja aberto ao definir uma configuração de encaminhador do Chronicle, como ao definir a configuração do firewall. O Google não consegue fornecer uma lista específica de endereços IP. No entanto, você pode ter intervalos de endereços IP do Google.

Verifique a configuração do firewall

Se você tiver firewalls ou proxies autenticados entre o contêiner do encaminhador do Chronicle e a Internet, eles exigirão regras para permitir o acesso aos seguintes hosts do Google Cloud:

Tipo de conexão	Destino	Port
TCP	malachiteingestion-pa.googleapis.com	443
TCP	asia-northeast1-malachiteingestion-pa.googleapis.com	443
TCP	asia-south1-malachiteingestion-pa.googleapis.com	443
TCP	asia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	australia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	europe-malachiteingestion-pa.googleapis.com	443
TCP	europe-west2-malachiteingestion-pa.googleapis.com	443
TCP	europe-west3-malachiteingestion-pa.googleapis.com	443
TCP	europe-west6-malachiteingestion-pa.googleapis.com	443
TCP	me-central2-malachiteingestion-pa.googleapis.com	443
TCP	me-west1-malachiteingestion-pa.googleapis.com	443
TCP	northamerica-northeast2-malachiteingestion-pa.googleapis.com	443
TCP	accounts.google.com	443
TCP	gcr.io	443
TCP	oauth2.googleapis.com	443
TCP	storage.googleapis.com	443

Para verificar a conectividade de rede com o Google Cloud, siga estas etapas:

Inicie o Windows PowerShell com privilégios de administrador: clique em Iniciar, digite PowerShell, clique com o botão direito do mouse em Windows PowerShell e clique em Executar como administrador.

Execute o comando a seguir.

C:\> test-netconnection <host> -port <port>

O comando retorna que TcpTestSucceeded é true.

Exemplo:

C:\> test-netconnection malachiteingestion-pa.googleapis.com -port 443
ComputerName     :  malachiteingestion-pa.googleapis.com
RemoteAddress    : 198.51.100.1
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 203.0.113.1
TcpTestSucceeded : True

Instalar o Docker no Microsoft Windows

Nesta seção, descrevemos como instalar o Docker no Microsoft Windows usando a interface de linha de comando e o PowerShell.

Vantagens do encaminhador Chronicle ao usar um contêiner:

Melhor segurança com o isolamento:
- O ambiente e os requisitos do cliente não afetam o encaminhamento do Chronicle.
- O ambiente e os requisitos do encaminhador do Chronicle não afetam o cliente.
- O mecanismo de distribuição de contêineres já existe e pode ser particular e separado para o Google Cloud e os clientes. Para saber mais, consulte Artifact Registry.

Conclua as etapas a seguir no Microsoft Windows Server Core 2022.

Ative o recurso do contêiner do Microsoft Windows.
```
Install-WindowsFeature containers -Restart
```

Execute o seguinte comando no modo de administrador do PowerShell para instalar o Docker CE:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1

.\install-docker-ce.ps1

Execute o comando docker ps para testar a interface de linha de comando do Docker, que retorna uma lista de contêineres em execução. Se o comando não listar nenhum contêiner em execução, a instalação será bem-sucedida. Se o Docker não estiver instalado corretamente, um erro será exibido.

Para mais informações, consulte Primeiros passos: preparar janelas para contêineres.

Para implantações empresariais, instale o Mirantis Container Runtime, também conhecido como Docker EE.

Configurar o encaminhador do Chronicle

Para configurar o encaminhador do Chronicle para Windows no Docker, consulte Gerenciar configurações do encaminhador na interface do Chronicle.

Ao configurar o encaminhador do Chronicle, verifique se todos os caminhos nele começam com o prefixo "c:".

Todas as alterações feitas no arquivo de configuração serão aplicadas automaticamente pelo encaminhador do Chronicle em até cinco minutos.

Para coletar dados de pacote usando o encaminhador do Chronicle para Windows no Docker, consulte Coletar dados de pacote.

Executar o encaminhador do Chronicle no contêiner do Docker

Se você estiver fazendo upgrade do encaminhador do Chronicle, comece limpando as execuções anteriores do Docker. No exemplo a seguir, o nome do contêiner do Docker é cfps.
```
docker stop cfps

docker rm cfps
```
Consiga a imagem mais recente do Docker do Google Cloud usando este comando pull do Docker.
```
docker pull gcr.io/chronicle-container/cf_production_stable_windows
```
Inicie o encaminhador do Chronicle no contêiner do Docker.
```
docker run `
--detach `
--name cfps `
--restart=always `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v C:\config\:C:/opt/chronicle/external `
gcr.io/chronicle-container/cf_production_stable_windows
```
É possível adicionar várias portas usando várias opções ou vários intervalos. Por exemplo: -p 3001:3000 -p 2023:2022 ou -p 7000-8000:7000-8000

Observação :os números de porta fornecidos no código de amostra são exemplos. Substitua os números das portas de acordo com seus requisitos.

Conferir registros do encaminhador

Para ver os registros do encaminhador do Chronicle, execute o seguinte comando:

  sudo docker logs cfps

Para ver o caminho do arquivo em que os registros estão armazenados, execute o seguinte comando:

docker inspect --format='{{.LogPath}}' CONTAINER_NAME

Para visualizar os registros de execução em tempo real, execute o seguinte comando:

  sudo docker logs cfps -f

Para armazenar os registros em um arquivo, execute o seguinte comando:

  sudo docker logs cfps &> logs.txt

Desinstalar o encaminhador do Chronicle

Os comandos do Docker a seguir permitem interromper e desinstalar ou remover o encaminhador do Chronicle.

Este comando interrompe o contêiner do encaminhador do Chronicle:

  docker stop cfps

Este comando remove o contêiner do encaminhador do Chronicle:

  docker rm cfps

Fazer upgrade do encaminhador do Chronicle

Como o encaminhador do Chronicle para Windows no Docker é constantemente atualizado com um script de shell na imagem do Docker, não é necessário fornecer nenhum executável para isso.

Coleta de dados

As seções a seguir ajudam a configurar o encaminhador do Chronicle para ingerir diferentes tipos de dados, que são encaminhados para a instância do Chronicle.

Não configure um valor maior que 1 MB para batch_n_bytes. Se você configurar um valor maior que 1 MB, ele será redefinido automaticamente para 1 MB.

Coletar dados do Splunk

É possível configurar o encaminhador do Chronicle para encaminhar seus dados do Splunk para o Chronicle. O Google Cloud configura o encaminhador Chronicle com as seguintes informações para encaminhar seus dados do Splunk:

URL para a API REST do Splunk (por exemplo, https://10.0.113.15:8089).
Consultas de splunk para gerar dados para cada um dos tipos de dados necessários (por exemplo, index=dns).

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime

Disponibilize as credenciais da sua conta do Splunk para o encaminhador do Chronicle. Para isso, crie um arquivo creds.txt.

Para usar um arquivo creds.txt:

Crie um arquivo local para suas credenciais do Splunk e nomeie-o como creds.txt.

Observação :verifique se as credenciais estão armazenadas com segurança. Não encaminhe suas credenciais do Splunk para o Google Cloud.
Coloque seu nome de usuário na primeira linha e a senha na segunda linha:
```
cat creds.txt

myusername
mypassword
```
Para usar o encaminhador do Chronicle para acessar uma instância do Splunk, copie o arquivo creds.txt para o diretório de configuração, o mesmo diretório em que os arquivos de configuração residem. Exemplo:
```
cp creds.txt c:/opt/chronicle/config/creds.txt
```
Verifique se o arquivo creds.txt está no local correto:
```
ls c:/opt/chronicle/config
```

Coletar dados syslog

O encaminhador do Chronicle pode funcionar como um servidor syslog. É possível configurar qualquer dispositivo ou servidor compatível com o envio de dados syslog por uma conexão TCP ou UDP para encaminhar os dados ao encaminhador do Chronicle. É possível controlar os dados exatos que o dispositivo ou o servidor envia para o encaminhador do Chronicle. O encaminhador do Chronicle pode encaminhar os dados para ele.

O arquivo de configuração FORWARDER_NAME.conf (fornecido pelo Google Cloud) especifica quais portas monitorar para cada tipo de dados encaminhados (por exemplo, porta 10514). Por padrão, o encaminhador do Chronicle aceita conexões TCP e UDP.

Configurar o rsyslog

Para configurar o rsyslog, é preciso especificar um destino para cada porta, por exemplo, para cada tipo de dado. Consulte a documentação do sistema para saber a sintaxe correta. Os exemplos a seguir ilustram a configuração de destino do rsyslog:

Tráfego de registros TCP: dns.* @@192.168.0.12:10514
Tráfego de registros UDP: dns.* @192.168.0.12:10514

Ativar TLS para configurações de syslog

É possível ativar o TLS para a conexão do syslog com o encaminhador do Chronicle. No arquivo de configuração do encaminhador do Chronicle (FORWARDER_NAME.conf), especifique o local do certificado e da chave de certificado gerados, conforme mostrado no exemplo a seguir:

certificado	`c:/opt/chronicle/external/certs/client_generated_cert.pem`
certificate_key	`c:/opt/chronicle/external/certs/client_generated_cert.key`

Com base no exemplo mostrado, modifique o arquivo de configuração do encaminhador do Chronicle (FORWARDER_NAME.conf) da seguinte maneira:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "c:/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "c:/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

Alguns pontos importantes:

É possível configurar o tamanho do buffer do TCP. O tamanho padrão do buffer do TCP é 64 KB.
O valor padrão e recomendado de connection_timeout é de 60 segundos. Se a conexão ficar inativa por um período especificado, a conexão TCP será encerrada.
A versão de TLS mínima é comparada à versão de TLS da solicitação de entrada. A versão de TLS da solicitação de entrada precisa ser maior que a versão de TLS mínima. A versão de TLS mínima precisa ser um destes valores: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

É possível criar um diretório "certs" no diretório de configuração e armazenar os arquivos de certificado nele.

Coletar dados de arquivos

Um coletor de arquivos foi projetado para buscar os registros de um arquivo. O arquivo precisa estar vinculado ao contêiner do Docker.

Use esse método se quiser fazer o upload manual dos registros de um único arquivo. Isso pode ser usado para preencher registros de um arquivo de registro específico.

Inicie o encaminhador do Chronicle no contêiner do Docker:

  docker run `
    --name cfps `
    --log-opt max-size=100m `
    --log-opt max-file=10 `
    -p 10514:10514 `
    -v c:/opt/chronicle/config:c:/opt/chronicle/external `
    -v c:/var/log/crowdstrike/falconhoseclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable

É possível adicionar várias portas usando várias opções ou vários intervalos. Por exemplo: -p 3001:3000 -p 2023:2022 ou -p 7000-8000:7000-8000

O comando docker run é fundamental para mapear o volume de carregamento para o contêiner.

Com base nesse exemplo, modifique a configuração do encaminhador do Chronicle (arquivo FORWARDER_NAME.conf) desta forma. O arquivo sample.txt precisa estar na pasta /var/log/crowdstrike/falconhostclient.

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: c:/opt/chronicle/edr/output/sample.txt
       filter:

Configurações de sinalização

skip_seek_to_end (bool): essa sinalização é definida como false por padrão e a entrada do arquivo envia apenas novas linhas de registro como entrada. Definir como true faz com que todas as linhas de registro anteriores sejam enviadas novamente durante as reinicializações do encaminhador. Isso causa duplicação de registros. Definir essa flag como true é útil em determinadas situações (por exemplo, durante interrupções), porque a reinicialização do encaminhador envia as linhas de registro ausentes novamente.

poll (bool): o coletor de arquivos usa a biblioteca Tail para verificar se há mudanças no sistema de arquivos. Ao definir essa flag como true, a biblioteca Tail usa o método de pesquisa em vez do método de notificação padrão.

Coletar dados de pacotes

O encaminhador do Chronicle pode capturar pacotes diretamente de uma interface de rede usando o Npcap em sistemas Windows.

Os pacotes são capturados e enviados para o Google Cloud em vez de entradas de registro. A captura é feita apenas em uma interface local.

Entre em contato com o suporte do Chronicle para atualizar o arquivo de configuração de encaminhador de suporte para oferecer suporte à captura de pacotes.

Para executar um encaminhador de captura de pacotes (PCAP, na sigla em inglês), você precisa do seguinte:

Instale o Npcap no host do Microsoft Windows.
Conceda privilégios de administrador ou raiz ao encaminhador do Chronicle para monitorar a interface de rede.
Nenhuma opção de linha de comando é necessária.
Na instalação do Npcap, ative o modo de compatibilidade do WinPcap.

Para configurar um encaminhador PCAP, o Google Cloud precisa do GUID da interface usada para capturar pacotes. Execute getmac.exe na máquina em que você planeja instalar o encaminhador do Chronicle (o servidor ou a máquina que detecta na porta span) e envie a saída para o Chronicle.

Também é possível modificar o arquivo de configuração. Localize a seção PCAP e substitua o valor do GUID mostrado ao lado da interface pelo GUID exibido na execução do getmac.exe.

Por exemplo, aqui está uma seção de PCAP original:

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{1A7E7C8B-DD7B-4E13-9637-0437AB1A12FE}
      bpf: udp port 53

Esta é a saída da execução de getmac.exe:

C:\>getmac.exe
  Physical Address    Transport Name
  ===========================================================================
  A4-73-9F-ED-E1-82   \Device\Tcpip_{2E0E9440-ABFF-4E5B-B43C-E188FCAD1234}

Por fim, veja a seção PCAP revisada com o novo GUID:

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: udp port 53

Coletar dados do tópico do Kafka

É possível ingerir dados dos tópicos do Kafka da mesma forma que você faz pelo syslog. Os grupos de consumidores são usados para permitir que você implante até três encaminhadores do Chronicle e extraia dados do mesmo tópico do Kafka. Para mais informações, consulte o Kafka (em inglês).

Para mais informações sobre grupos de consumidores do Kafka, consulte Grupos de consumidores do Kafka.

Exemplo de configuração: entrada do Kafka

A configuração do encaminhador do Chronicle a seguir mostra como configurar o encaminhador do Chronicle para ingerir dados dos tópicos do Kafka.

Arquivo FORWARDER_NAME.conf

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "c:/path/to/cert.pem"
        certificate_key: "c:/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Arquivo FORWARDER_NAME_auth.conf

collectors:
- kafka:
      username: user
      password: password
- syslog:

Coletar dados do WebProxy

O encaminhador do Chronicle pode capturar dados do WebProxy diretamente de uma interface de rede usando o Npcap e enviá-los ao Google Cloud.

Para ativar a captura de dados do WebProxy no seu sistema, entre em contato com o suporte do Chronicle.

Antes de executar um encaminhador do WebProxy, faça o seguinte:

Instale o Npcap no host do Microsoft Windows. Ative o modo de compatibilidade do WinPcap durante a instalação.
Conceda privilégios de raiz ou de administrador ao encaminhador do Chronicle para monitorar a interface de rede.
Para configurar um encaminhador do WebProxy, o Google Cloud precisa do GUID da interface usada para capturar os pacotes do WebProxy.

Execute getmac.exe na máquina em que você quer instalar o encaminhador do Chronicle e envie a saída para o Chronicle. Como alternativa, você pode modificar o arquivo de configuração. Localize a seção WebProxy e substitua o GUID mostrado ao lado da interface pelo GUID exibido após a execução de getmac.exe.

Modifique o arquivo de configuração do encaminhador do Chronicle (FORWARDER_NAME.conf) desta forma:
```
  - webproxy:
    common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: tcp and dst port 80
```

Personalizar configurações

A tabela a seguir lista parâmetros importantes usados no arquivo de configuração do encaminhador.

Parâmetro	Descrição
data_type	O tipo de dados de registro que o coletor pode coletar e processar.
metadados	Metadados, que substituem metadados globais.
max_file_buffer_bytes	Número máximo de bytes que podem ser acumulados no disco ou no buffer de arquivo. O valor padrão é `1073741824`, que é 1 GB.
max_memory_buffer_bytes	Número máximo de bytes que podem ser acumulados no buffer de memória. O valor padrão é `1073741824`, que é 1 GB.
write_to_disk_dir_path	O caminho a ser usado para o buffer de arquivo ou disco.
write_to_disk_buffer_enabled	Se for `true`, será usado o buffer de disco em vez do buffer de memória. O valor padrão é `false`.
batch_n_bytes	Número máximo de bytes que podem ser acumulados pelo coletor após o qual os dados são agrupados. O valor padrão é `1048576`, que é 1 MB.
batch_n_seconds	O número de segundos após os quais os dados coletados pelo coletor são agrupados. O valor padrão é 11 segundos.
data_hint	Formato de dados que o coletor pode receber (geralmente o cabeçalho do arquivo de registros que descreve o formato).

Para ver uma lista completa de parâmetros usados no arquivo de configuração, consulte Campos de configuração do encaminhador e Campos de configuração do coletor.

Alternar compactação de dados

A compactação de registros reduz o consumo da largura de banda da rede ao transferir registros para o Chronicle. No entanto, a compactação pode aumentar o uso da CPU. A compensação entre o uso da CPU e a largura de banda depende de muitos fatores, incluindo o tipo de dados de registro, a compressibilidade desses dados, a disponibilidade de ciclos de CPU no host que executa o encaminhador Chronicle e a necessidade de reduzir o consumo de largura de banda da rede.

Por exemplo, registros baseados em texto são bem compactados e podem economizar bastante largura de banda com baixo uso da CPU. No entanto, os payloads criptografados de pacotes brutos não são bem compactados e geram maior uso da CPU.

Por padrão, a compactação de registros fica desativada. Ativar a compactação de registros pode reduzir o consumo da largura de banda. No entanto, ativar a compactação de registros também pode aumentar o uso da CPU. Esteja ciente da compensação.

Para ativar a compactação de registros, defina o campo compression como true no arquivo de configuração do encaminhador do Chronicle, conforme mostrado neste exemplo:

Arquivo FORWARDER_NAME.conf

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

Arquivo FORWARDER_NAME_auth.conf

output:
  identity:
    secret_key: |
    {
     "type": "service_account",
...
    }

Configurar o armazenamento em buffer do disco

O armazenamento em buffer de disco permite armazenar em buffer as mensagens acumuladas em buffer no disco, e não na memória. As mensagens acumuladas podem ser armazenadas caso o encaminhador do Chronicle falhe ou o host subjacente falhe. A ativação do armazenamento em buffer do disco pode afetar o desempenho.

Se o armazenamento em buffer de disco estiver desativado, o encaminhador do Chronicle usará 1 GB de memória (RAM) para cada tipo de registro, por exemplo, para cada conector. Especifique o parâmetro de configuração max_memory_buffer_bytes. A memória máxima permitida é de 4 GB.

Configure o armazenamento em buffer automático de disco para usar um buffer compartilhado dinamicamente entre os coletores, o que lida melhor com picos de tráfego. Para ativar o buffer compartilhado dinamicamente, adicione o seguinte na configuração do encaminhador:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

Se o armazenamento em buffer automático de disco estiver ativado, mas target_memory_utilization não estiver definido, ele usará um valor padrão de 70.

Se você estiver executando o encaminhador do Chronicle usando o Docker, o Google recomenda montar um volume separado do volume de configuração para fins de isolamento. Além disso, cada entrada precisa ser isolada com o próprio diretório ou volume para evitar conflitos.

Exemplo de configuração: armazenamento em buffer de disco

A configuração a seguir inclui a sintaxe para ativar o armazenamento em buffer do disco:

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # c:/buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: c:/buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Definir filtros de expressão regular

Os filtros de expressão regular permitem filtrar registros com base em correspondências de expressão regular em relação a registros brutos.

Os filtros usam a syntax RE2.

Os filtros precisam incluir uma expressão regular e, opcionalmente, definir um comportamento quando há uma correspondência. O comportamento padrão em uma correspondência é bloquear. Também é possível configurá-la explicitamente como bloqueio.

Como alternativa, você pode especificar filtros com o comportamento allow. Se você especificar qualquer filtro allow, o encaminhador do Chronicle bloqueará todos os registros que não corresponderem a pelo menos um filtro allow.

É possível definir um número arbitrário de filtros. Os filtros de bloco têm prioridade sobre os filtros allow.

Quando os filtros são definidos, é necessário atribuir um nome a eles. Os nomes dos filtros ativos serão informados ao Chronicle usando as métricas de integridade do encaminhador. Os filtros definidos na raiz da configuração são mesclados com filtros definidos no nível do coletor. Os filtros de nível do coletor têm precedência em casos de nomes conflitantes. Se nenhum filtro for definido no nível da raiz ou do coletor, o comportamento será permitir todos.

Exemplo de configuração: filtros de expressão regular

Na configuração do encaminhador do Chronicle a seguir, os registros WINEVTLOG que não correspondem ao filtro raiz (allow_filter) são bloqueados. Dada a expressão regular, o filtro só permite registros com prioridades entre 0 e 99. No entanto, todos os registros NIX_SYSTEM que contenham "foo" ou "bar" serão bloqueados, independentemente da allow_filter. Isso ocorre porque os filtros usam um OR lógico. Todos os registros são processados até que um filtro seja acionado.

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configurar rótulos arbitrários

Os identificadores são usados para anexar metadados arbitrários aos registros com pares de chave-valor. Os identificadores podem ser configurados para um encaminhador do Chronicle inteiro ou em um coletor específico de um encaminhador do Chronicle. Se ambos forem fornecidos, os rótulos serão mesclados com as chaves do coletor com precedência sobre as chaves do encaminhador do Chronicle se as chaves se sobrepuserem.

Exemplo de configuração: rótulos arbitrários

Na configuração de encaminhador do Chronicle a seguir, os pares de chave e valor foo=bar e meow=mix são anexados aos registros WINEVTLOG, e os pares de chave-valor foo=baz e meow=mix são anexados aos registros NIX_SYSTEM.

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configurar namespaces

Use rótulos de namespace para identificar registros de segmentos de rede distintos e eliminar o conflito de endereços IP sobrepostos. É possível configurar um rótulo de namespace para todo o encaminhador do Chronicle ou dentro de um coletor específico dele. Se ambos forem incluídos, o namespace do coletor específico terá precedência.

Qualquer namespace configurado para o encaminhador do Chronicle aparece com os recursos associados na interface do usuário do Chronicle. Também é possível pesquisar namespaces usando o recurso de pesquisa do Chronicle.

Para informações sobre como visualizar namespaces na interface do usuário do Chronicle, consulte este link.

Exemplo de configuração: namespaces

Na configuração de encaminhador do Chronicle a seguir, os registros WINEVTLOG são anexados ao namespace FORWARDER, e os registros NIX_SYSTEM são anexados ao namespace CORPORATE.

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Configurar opções de balanceamento de carga e alta disponibilidade

O encaminhador do Chronicle para Windows no Docker pode ser implantado em um ambiente em que um balanceador de carga de camada 4 é instalado entre a fonte de dados e as instâncias do encaminhador do Chronicle. Isso permite que você distribua a coleta de registros em vários encaminhadores do Chronicle ou envie registros para outro encaminhador do Chronicle se um deles falhar. Esse recurso é compatível apenas com o tipo de coleção syslog.

O encaminhador do Chronicle para Windows no Docker inclui um servidor HTTP integrado que responde a verificações de integridade HTTP do balanceador de carga. O servidor HTTP também ajuda a garantir que os registros não sejam perdidos durante a inicialização ou o encerramento de um encaminhador do Chronicle.

Configure as opções de servidor HTTP, balanceamento de carga e alta disponibilidade na seção server do arquivo de configuração do encaminhador do Chronicle. Essas opções são compatíveis com a configuração de durações de tempo limite e códigos de status retornados em resposta a verificações de integridade recebidas em implantações baseadas em orquestração e programador de contêineres, bem como de balanceadores de carga convencionais.

Use os caminhos de URL a seguir para verificações de integridade, prontidão e atividade. Os valores <host:port> são definidos na configuração do encaminhador do Chronicle.

http://<host:port>/meta/available: verificações de atividade para programadores/orquestradores de contêineres, como o Kubernetes.
http://<host:port>/meta/ready: verificações de prontidão e verificações de integridade do balanceador de carga tradicional.

A configuração do encaminhador do Chronicle a seguir é um exemplo de balanceamento de carga e alta disponibilidade:

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503

Caminho de configuração	Descrição
servidor : Graceful_timeout	A quantidade de tempo que o encaminhador do Chronicle retorna uma verificação de prontidão/integridade incorreta e ainda aceita novas conexões. Esse também é o tempo de espera entre o recebimento de um sinal para interromper e o início do encerramento do próprio servidor. Isso permite que o balanceador de carga tenha tempo de remover o encaminhador Chronicle do pool.
servidor : Dren_timeout	O tempo que o encaminhador do Chronicle aguarda até que as conexões ativas se fechem por conta própria antes de serem fechadas pelo servidor.
servidor : http : porta	O número da porta em que o servidor HTTP detecta verificações de integridade do balanceador de carga. Precisa estar entre 1024 e 65535.
servidor : http : host	O endereço IP, ou nome do host, que pode ser resolvido em endereços IP, que o servidor precisa detectar. Se estiver vazio, o valor padrão será o sistema local (0.0.0.0).
servidor : http : read_timeout	Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. O tempo máximo permitido para ler toda a solicitação, tanto o cabeçalho quanto o corpo. Você pode definir read_timeout e read_header_timeout.
servidor : http : read_header_timeout	Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. O tempo máximo permitido para ler os cabeçalhos de solicitação. O prazo de leitura da conexão é redefinido depois da leitura do cabeçalho.
servidor : http : write_timeout	Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. O tempo máximo permitido para enviar uma resposta. Ele é redefinido quando um novo cabeçalho de solicitação é lido.
servidor : http : touchscreen	Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. A quantidade máxima de tempo de espera pela próxima solicitação quando as conexões inativas estão ativadas. Se o empty_timeout for zero, o valor de read_timeout será usado. Se ambos forem zero, o read_header_timeout será usado.
rotas : meta : Ready_status	O código de status que o encaminhador do Chronicle retorna quando está pronto para aceitar o tráfego em uma destas situações: A verificação de prontidão é recebida de um programador ou orquestrador de contêineres, como o Kubernetes. A verificação de integridade é recebida de um balanceador de carga tradicional.
rotas : meta : não lidas	O código de status que o encaminhador do Chronicle retorna quando não está pronto para aceitar o tráfego.
rotas : meta : available_status	O código de status retornado pelo encaminhador do Chronicle quando uma verificação de atividade é recebida e quando o encaminhador do Chronicle está disponível. Programadores/orquestradores de contêineres, como o Kubernetes, geralmente enviam verificações de atividade.