Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Instalar e configurar o encaminhador no Linux

Este documento descreve como instalar e configurar o encaminhador no Linux. Para instalar o encaminhador no Windows, consulte Encaminhador do Windows.

Ele é usado para enviar registros do ambiente do cliente para a instância do Chronicle. Isso é usado quando os clientes querem enviar os registros diretamente para o Chronicle e não querem usar os buckets de nuvem para ingerir dados ou o tipo de registro não tem ingestão nativa por meio de API de terceiros. Ele pode ser usado como uma solução pronta para implantação, em vez de incorporar manualmente a API de ingestão.

É possível instalar o encaminhador em várias distribuições do Linux, incluindo Debian, Ubuntu, Red Hat e Suse. O Google Cloud fornece o software usando um contêiner do Docker. É possível executar e gerenciar o contêiner do Docker em uma máquina física ou virtual que executa o Linux.

Requisitos do sistema

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

  • RAM: 1 GB para cada tipo de dados coletados. Por exemplo, detecção e resposta de endpoint (EDR), DNS e DHCP são tipos de dados separados. Você precisa de 3 GB de RAM para coletar todos os três.

  • CPU: duas CPUs são suficientes para processar menos de 10.000 eventos por segundo (EPS, na sigla em inglês), total para todos os tipos de dados. Se você espera encaminhar mais de 10.000 EPS, provisione de 4 a 6 CPUs.

  • Disco: 100 MB de espaço em disco é suficiente, independentemente da quantidade de dados que o encaminhador do Chronicle processa. Se você precisar armazenar as mensagens armazenadas em buffer no disco em vez de na memória, consulte Armazenamento em buffer do disco. O encaminhador do Chronicle é armazenado em buffer na memória por padrão.

Verifique a configuração do firewall

Todos os firewalls ou proxies autenticados entre o contêiner do encaminhador do Chronicle e a Internet exigem regras para abrir o acesso aos seguintes hosts:

Tipo de conexão Destino Port
TCP malachiteingestion-pa.googleapis.com 443
TCP malachiteingestion-europe-backstory.googleapis.com 443
TCP malachiteingestion-asia-southeast1-backstory.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP storage.googleapis.com 443

Personalizar os arquivos de configuração

Entre em contato com seu representante do Chronicle para acessar os modelos de arquivo de configuração.

O Google Cloud personaliza os arquivos de configuração para a instância do encaminhador com metadados específicos, conforme mostrado na seção de saída. É possível modificar os arquivos de configuração de acordo com seus requisitos e incluir informações sobre os tipos de registro a serem ingeridos na seção de coletores. Se você precisar de mais informações sobre as definições de configuração, entre em contato com o suporte do Chronicle.

Para configurar o encaminhador do Linux, siga estas etapas:

  1. Faça uma cópia do modelo de arquivo de configuração fornecido com o software.

  2. Salve os dois arquivos no mesmo diretório usando a seguinte convenção de nomenclatura:

    FORWARDER_NAME.conf: use esse arquivo para definir as configurações relacionadas à ingestão de registros.

    FORWARDER_NAME_auth.conf: use esse arquivo para definir as credenciais de autorização.

  3. Modifique os arquivos para incluir a configuração da instância do encaminhador. Use as amostras fornecidas neste documento como referência.

  4. Verifique se há uma entrada para cada entrada no arquivo FORWARDER_NAME_auth.conf, mesmo que ela não tenha detalhes de autenticação correspondentes. Isso é necessário para mapear os dados corretamente.

Exemplo de configuração

Na amostra de código a seguir, mostramos o formato dos arquivos de configuração para um encaminhador. Para saber mais sobre as configurações de cada tipo de mecanismo de ingestão, como o Splunk ou o Syslog, consulte Coletar dados.

Arquivo FORWARDER_NAME.conf

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: COLLECTOR_ID \
    customer_id: CUSTOMER_ID \

collectors:
  - syslog:
      common:
        enabled: true
        data_type: `WINDOWS_DHCP`
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - 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
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
enable_auto_update: false

Arquivo FORWARDER_NAME_auth.conf

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
  - syslog:
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"

Esse sistema de dois arquivos permite armazenar credenciais de autenticação em um arquivo separado para aumentar a segurança. É possível armazenar o arquivo FORWARDER_NAME.conf em um repositório de controle de versões ou em qualquer sistema de gerenciamento de configuração aberto. É possível armazenar o arquivo FORWARDER_NAME_auth.conf diretamente na máquina física ou virtual que executa o encaminhador.

Exemplo de configuração (arquivo único)

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: "COLLECTOR_ID" \
    customer_id: "CUSTOMER_ID" \
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\ "PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/malachite-test-1%40malachite-test.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
      common:
        enabled: true
        data_type: `WINDOWS_DHCP`
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - 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
      connection_timeout_sec: 60
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"
      tcp_buffer_size: 524288
enable_auto_update: false

Se você estiver usando o único arquivo de configuração e quiser mover para o sistema de dois arquivos, faça o seguinte:

  1. Crie uma cópia da configuração.
  2. Salve um arquivo como FORWARDER_NAME.conf e exclua as credenciais de autorização dele.
  3. Salve o outro arquivo como FORWARDER_NAME_auth.conf e exclua todos os dados não autorizados do arquivo. Use os arquivos de configuração de amostra fornecidos neste guia como referência.
  4. Siga a convenção de nomes e outras diretrizes mencionadas na seção Personalizar os arquivos de configuração.

Instalar o Docker

A instalação do Docker depende do ambiente do host. É possível instalar o Docker em diferentes sistemas operacionais host. O Google Cloud fornece documentação limitada para ajudar você a instalar o Docker em várias das distribuições mais conhecidas do Linux. No entanto, o Docker é de código aberto, e toda a documentação necessária já está disponível. Para instruções sobre a instalação do Docker, consulte a documentação do Docker.

Depois que o Docker é instalado no sistema, o processo de instalação do encaminhador do Chronicle é semelhante a qualquer tipo de distribuição do Linux.

Para verificar se o Docker está instalado corretamente no sistema, execute o seguinte comando (privilégios elevados):

   docker ps
  

A resposta a seguir indica que o Docker foi instalado corretamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

É possível coletar mais informações sobre a instalação do Docker usando o seguinte comando:

    docker info
  

Se você tiver problemas com o Docker, a equipe de suporte do Chronicle poderá solicitar a saída desse comando para ajudar e depurar com o problema.

Instalar o encaminhador no Linux

Esta seção descreve como instalar o Chronicle Forwarder usando um contêiner do Docker em um sistema Linux.

Etapa 1. Fazer o download, transferir e instalar os arquivos de configuração do encaminhador

O Google Cloud fornece arquivos de configuração de encaminhamento específicos para seu sistema operacional (Linux ou Windows). Faça o download dos arquivos pelo link fornecido pelo representante do Chronicle para um diretório local do seu laptop (por exemplo, para um diretório chamado Chronicle). Depois de concluir as etapas a seguir, transfira os arquivos de configuração do seu laptop para o diretório /opt/chronicle/config dentro do diretório inicial do usuário.

  1. Conecte-se ao host do encaminhador do Linux pelo terminal.

  2. Crie um novo usuário no host do encaminhador do Linux.

      adduser USERNAME
      passwd USERNAME
      usermod -aG wheel USERNAME
    

  3. Altere o diretório para o diretório principal do novo usuário que executa o contêiner do Docker.

  4. Crie um diretório para armazenar os arquivos de configuração do encaminhador do Chronicle:

      mkdir /opt/chronicle/config
    

  5. Altere o diretório.

      cd /opt/chronicle/config
    

  6. Após transferir os arquivos, verifique se os arquivos de configuração estão localizados no diretório /opt/chronicle/config:

      ls -l
    

Etapa 2: Executar o encaminhador no contêiner do Docker

Você pode usar os procedimentos a seguir para iniciar o encaminhador do Chronicle pela primeira vez e para fazer upgrade para a versão mais recente do contêiner do Chronicle:

As opções de --log-opt estão disponíveis desde o Docker 1.13. Essas opções limitam o tamanho dos arquivos de registro do contêiner e precisam ser usadas desde que sua versão do Docker seja compatível com elas.

  1. Se você estiver fazendo upgrade, comece limpando todas as execuções anteriores do Docker. No exemplo a seguir, o nome do contêiner do Docker é cfps. Consiga a imagem mais recente do Docker do Google Cloud com o comando docker pull, conforme mostrado abaixo.

    docker stop cfps
    
    docker rm cfps
    
  2. Encontre a imagem mais recente do Docker no Google Cloud:

    docker pull gcr.io/chronicle-container/cf_production_stable
    
  3. 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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    gcr.io/chronicle-container/cf_production_stable
    

Desinstalar o encaminhador

Os comandos do Docker a seguir ajudam você a interromper e desinstalar ou remover o encaminhador do Chronicle.

Para interromper ou desinstalar o contêiner do encaminhador:

    docker stop cfps
  

Para remover o contêiner do encaminhador, siga estas etapas:

    docker rm cfps
  

Atualizar o encaminhador

O encaminhador do Chronicle tem duas partes e foi atualizado da seguinte maneira:

  • Pacote de encaminhadores: atualizado automaticamente, sem necessidade de reinicialização.

  • Imagem do Docker do encaminhador: é atualizada manualmente após interromper o encaminhador atual e iniciar uma nova instância, conforme declarado na Etapa 2.

Coletar 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.

Coletar dados do Splunk

Você pode configurar o encaminhador do Chronicle para encaminhar seus dados do Splunk ao Chronicle. O Google Cloud configura o encaminhador do Chronicle com as seguintes informações para encaminhar os dados do Splunk:

  • URL da API REST Splunk (por exemplo, https://10.0.113.15:8089).

  • Consultas do Splunk para gerar dados para cada um dos tipos de dados necessários (por exemplo, index=dns).

Você precisa disponibilizar as credenciais da sua conta do Splunk para o encaminhador do Chronicle. Para isso, crie um arquivo creds.txt ou adicione os campos user e password na seção de configurações splunk do arquivo FORWARDER_NAME_auth.conf. Os dois procedimentos a seguir descrevem cada método. Use apenas um método. O método recomendado é usar o arquivo FORWARDER_NAME_auth.conf.

Para usar o arquivo FORWARDER_NAME_auth.conf, adicione os campos user e password à seção splunk do arquivo FORWARDER_NAME_auth.conf, conforme mostrado abaixo.

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

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: 10
      maximum_window_size: 30
      user: myusername
      password: mypassword
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size: período mínimo transmitido para a consulta do Splunk. O valor padrão é de 10 segundos. Esse parâmetro é usado para ajuste se o requisito for mudar a frequência com que o servidor Splunk é consultado quando o encaminhador estiver no estado estável. Além disso, quando há um atraso, a chamada da API Splunk pode ser feita várias vezes.

max_window_size: o período máximo transmitido para a consulta do Splunk. O valor padrão é de 30 segundos. Esse parâmetro é usado para ajustes em casos em que há um atraso ou se mais dados são necessários por consulta.

Altere esse parâmetro (igual ou maior que) quando você alterar o parâmetro mínimo. Pode haver casos de atraso se uma chamada de consulta Splunk estiver demorando mais do que o maximum_window_size.

query_mode:há apenas um valor válido: realtime. Para mais detalhes sobre pesquisas em tempo real no Splunk, consulte a documentação.

Para usar um arquivo creds.txt:

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

  2. Coloque seu nome de usuário na primeira linha e a senha na segunda linha:

    cat creds.txt
    
    myusername
    mypassword
    
  3. Para os clientes que usam 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 estão). Exemplo:

    cp creds.txt /opt/chronicle/config/creds.txt
    
  4. Verifique se o arquivo creds.txt está no local correto:

    ls /opt/chronicle/config
    

Coletar dados do 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 para o encaminhador do Chronicle. Você pode controlar os dados exatos que o dispositivo ou servidor envia ao encaminhador Chronicle. Depois, o encaminhador do Chronicle pode encaminhar os dados para o Chronicle.

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

Configurar rsyslog

Para configurar o rsyslog, é necessário especificar um destino para cada porta (por exemplo, cada tipo de dados). Consulte a sintaxe do sistema na documentação do sistema. Os exemplos a seguir ilustram a configuração do destino 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 ao encaminhador do Chronicle. No arquivo de configuração do encaminhador do Chronicle (FORWARDER_NAME.conf), especifique o local do seu certificado e da chave de certificado gerados, conforme mostrado no exemplo a seguir:

certificado "/opt/chronicle/external/certs/client_generate_cert.pem"
Chave do certificado "/opt/chronicle/external/certs/client_generate_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: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

Observações importantes:

  • É possível configurar o tamanho do buffer de TCP. O tamanho padrão do buffer de TCP é de 64 KB.

  • O valor padrão e recomendado para connection_timeout é 60 segundos. A conexão TCP será encerrada se ficar inativa por um período especificado.

  • A versão TLS mínima é verificada em relação à versão TLS da solicitação de entrada. A versão TLS da solicitação de entrada precisa ser posterior à versão mínima TLS. A versão mínima de TLS precisa ser um dos seguintes valores: TLSv1_0, TLSv1_1, TLSv1_2 ou TLSv1_3.

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

Coletar dados do arquivo

Use essa opção se você quiser fazer o upload manual dos registros de um único arquivo de registros. 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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

Esse comando docker run é fundamental para mapear o volume de carga para o contêiner.

Com base nesse exemplo, você precisa modificar a configuração do encaminhador do Chronicle (FORWARDER_NAME.conf) da seguinte maneira:

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

Coletar dados do pacote

O encaminhador do Chronicle pode capturar pacotes diretamente de uma interface de rede usando o libcap no Linux. Para mais informações, consulte a página de libcap - manual do Linux (em inglês).

Os pacotes são capturados e enviados ao Chronicle em vez de entradas de registro. A captura de pacotes é processada somente em uma interface local. Para ativar a captura de pacotes no sistema, entre em contato com o suporte do Chronicle.

O Google Cloud configura o encaminhador do Chronicle com a expressão de filtro de pacote Benkeley (BPF) usada na captura de pacotes (por exemplo, porta 53 e não localhost). Para mais informações, consulte Filtros de pacote do Berkeley.

Coletar dados do tópico do Kafka

É possível ingerir dados dos tópicos do Kafka da mesma forma que é possível fazer a ingestão no syslog. Os grupos de consumidores são usados para que você implante até três encaminhadores e puxe dados do mesmo tópico do Kafka. Para mais informações, consulte Kafka.

Para mais informações sobre grupos de consumidores do Kafka, acesse: https://docs.confluent.io/platform/current/clients/consumer.html

Exemplo de configuração: entrada do Kafka

A configuração do encaminhador a seguir mostra como configurá-lo 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: "/path/to/cert.pem"
        certificate_key: "/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:

Personalizar configurações opcionais

Alternar a 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 causar um aumento no uso da CPU. O equilíbrio entre o uso da CPU e a largura de banda depende de muitos fatores, incluindo o tipo de dados de registro, a compactação desses dados, a disponibilidade de ciclos de CPU no host que executa o encaminhador e a necessidade de reduzir o consumo de largura de banda da rede.

Por exemplo, os registros de texto são bem compactados e podem oferecer economias de largura de banda significativas com baixo uso da CPU. No entanto, os payloads criptografados de pacotes brutos não compactam bem e geram maior uso da CPU.

Por padrão, a compactação de registros fica desativada. A ativação da compactação de registros pode reduzir o consumo de 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 compactação como true no arquivo de configuração de encaminhador do Chronicle, conforme mostrado no exemplo a seguir:

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 em disco

O armazenamento em buffer de disco permite que você armazene em buffer mensagens na memória, em vez de memória. As mensagens acumuladas podem ser armazenadas caso o encaminhador falhe ou o host subjacente falhe. Esteja ciente de que a ativação do armazenamento em buffer do disco pode afetar o desempenho.

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

Se você estiver executando o encaminhador usando o Docker, o Google recomenda ativar 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 em disco

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

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: /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ões regulares com base em registros brutos.

Os filtros empregam a sintaxe RE2 descrita aqui: https://github.com/google/re2/wiki/Sintaxe

Os filtros precisam incluir uma expressão regular e, opcionalmente, definir um comportamento quando houver uma correspondência. O comportamento padrão em uma correspondência é bloquear (ela também pode ser explicitamente configurada como bloco).

Como alternativa, é possível especificar filtros com o comportamento allow. Se você especificar filtros allow, o encaminhador bloqueará registros que não correspondam a pelo menos um filtro allow.

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

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

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

Na configuração do encaminhador a seguir, os registros WINEVTLOG que não correspondem ao filtro raiz (allow_filter) são bloqueados. Considerando a expressão regular, o filtro só permite registros com prioridades entre 0 e 99. No entanto, todos os registros NIX_SYSTEM que contêm "foo" ou "bar" serão bloqueados, apesar do allow_filter. Isso ocorre porque os filtros usam um operador lógico "OR". 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 usando pares de chave-valor. Os identificadores podem ser configurados para um encaminhador inteiro ou em um coletor específico de um encaminhador. Se os dois forem fornecidos, os rótulos serão mesclados com as chaves do coletor, que têm precedência sobre as chaves do encaminhador, caso elas se sobreponham.

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

Na configuração do encaminhador a seguir, os pares de chave e valor "foo=bar" e "meow=mix" são anexados aos registros WINEVTLOG, e os pares de chave e 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 diferentes segmentos de rede e conflitar endereços IP sobrepostos. É possível configurar um rótulo de namespace para todo um encaminhador ou dentro de um coletor específico do encaminhador. Se ambos forem incluídos, o namespace do coletor específico terá precedência.

Qualquer namespace configurado para o encaminhador aparece com os recursos associados na interface do usuário do Chronicle. Você também pode pesquisar namespaces usando o recurso Chronicle Search.

Para saber mais sobre como ver namespaces na interface do usuário do Chronicle, consulte este link.

Exemplo de configuração: namespaces

Na configuração do encaminhador a seguir, os registros WINEVTLOG estão anexados ao namespace FORWARDER e os registros NIX_SYSTEM estã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 o balanceamento de carga e as opções de alta disponibilidade

O encaminhador do Chronicle para Linux pode ser implantado em um ambiente em que um balanceador de carga da camada 4 está instalado entre a origem de dados e as instâncias do encaminhador. Isso permite que um cliente distribua a coleção de registros entre vários encaminhadores ou envie registros para um encaminhador diferente se um falhar. Esse recurso é compatível apenas com o tipo de coleção syslog.

O encaminhador do Linux inclui um servidor HTTP integrado que responde às 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.

Configure o servidor HTTP, o balanceamento de carga e as opções de alta disponibilidade na seção servidor do arquivo de configuração do encaminhador. Essas opções oferecem suporte à definição de durações de tempo limite e códigos de status retornados em resposta a verificações de integridade recebidas em implantações do programador de contêineres e com base em orquestração, bem como de balanceadores de carga tradicionais.

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.

  • http://<host:port>/meta/available: verificações de atividade para programador/orquestradores de contêiner, 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 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 O tempo que o encaminhador retorna de má verificação de integridade/verificação de integridade e ainda aceita novas conexões. Esse também é o tempo entre o recebimento de um sinal para parar e o encerramento do servidor. Assim, o balanceador de carga pode remover o encaminhador do pool.
servidor : esvazi_timeout O tempo que o encaminhador aguarda até que as conexões ativas sejam fechadas com sucesso antes de serem fechadas pelo servidor.
servidor : http : porta O número da porta que o servidor HTTP detecta para as verificações de integridade do balanceador de carga. Precisa estar entre 1024 e 65535.
servidor : http : host O endereço IP ou o nome do host que pode ser resolvido para os 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 é necessário mudar a configuração padrão. O tempo máximo permitido para ler toda a solicitação, o cabeçalho e o corpo. É possível definir read_timeout e read_header_timeout.
servidor : http : read_header_timeout Usado para ajustar o servidor HTTP. Normalmente, não é necessário mudar a configuração padrão. A quantidade máxima de tempo permitida para ler cabeçalhos de solicitação. Depois da leitura do cabeçalho, o prazo para a conexão é redefinido.
servidor : http : write_timeout Usado para ajustar o servidor HTTP. Normalmente, não é necessário mudar a 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 : idle_timeout Usado para ajustar o servidor HTTP. Normalmente, não é necessário mudar a configuração padrão. O tempo máximo de espera pela próxima solicitação quando as conexões inativas estiverem ativadas. Se o tempo de inatividade 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 retornado pelo encaminhador quando ele estiver pronto para aceitar o tráfego em uma das seguintes situações:
  • A verificação de prontidão é recebida de um programador ou orquestrador de contêiner, como o Kubernetes.
  • A verificação de integridade é recebida de um balanceador de carga tradicional.
rotas : meta : ready_status O código de status que o encaminhador retorna quando não está pronto para aceitar o tráfego.
rotas : meta : available_status O código de status que o encaminhador retorna quando uma verificação de atividade é recebida e o encaminhador está disponível. Programadores/orquestradores de contêiner, como o Kubernetes, geralmente enviam verificações de atividade.

Perguntas frequentes

Como faço para atualizar meu encaminhador?

O encaminhador do Windows não é atualizado constantemente porque é usado por poucos clientes. O encaminhador do Linux é atualizado constantemente por meio de um script do Shell na imagem do Docker. Portanto, não é necessário fornecer nenhum executável para isso. No entanto, se um cliente abrir um caso de suporte para receber o arquivo executável mais recente do Windows para o encaminhador, a equipe de suporte vai fornecer um arquivo EXE ao cliente usando o portal de suporte.

O que é um contêiner do Docker?

  • Os contêineres do Docker são como máquinas virtuais que oferecem mais segurança, isolamento e gerenciamento de recursos.

  • Máquinas virtuais: têm um espaço privilegiado (kernel do Linux) e um espaço de usuário (tudo com que você interage: libc, python, ls, tcpdump etc.).

  • Os contêineres têm apenas um espaço de usuário (tudo com que você interage: libc, python, ls, tcpdump etc.) e dependem do espaço de privilégios do host.

Por que distribuir o encaminhador do Chronicle usando um contêiner?

  • Mais 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. https://cloud.google.com/container-registry/

Por que apenas o Linux para contêineres? E o Windows?

  • Os contêineres foram desenvolvidos primeiro para Linux e estão prontos para produção.

  • O suporte do Windows para contêineres está em andamento. Os contêineres estão disponíveis para Windows Server 2016 e Windows 10.

Você precisa aprender os comandos avançados do Docker?

  • O encaminhador do Chronicle usa um único contêiner. Portanto, não é necessário aprender sobre o Swarm, a orquestração, o Kubernetes ou outros conceitos ou comandos avançados do Docker.