Gerenciar o arquivo de configuração do forwarder manualmente

Compatível com:

Esta página descreve como criar e modificar manualmente um arquivo de configuração de forwarder das Operações de segurança do Google. Para configurar o encaminhador pela UI (recomendado), consulte Gerenciar configurações de encaminhador pela interface do Google SecOps.

Cada encaminhador do Google SecOps implantado requer um arquivo de configuração. Um arquivo de configuração de encaminhador especifica as configurações para transferir os dados para sua instância do Google SecOps.

Para informações sobre como instalar e configurar o forwarder do Google SecOps, os requisitos do sistema e detalhes sobre as configurações, consulte Instalar e configurar o forwarder.

Antes de começar

Antes de criar o arquivo de configuração, planeje sua implementação entendendo os tipos de dados que podem ser ingeridos e os principais atributos que você precisa definir no arquivo de configuração.

Crie o arquivo de configuração

Para criar o arquivo de configuração manualmente, siga estas etapas:

  1. Faça o download dos arquivos de configuração pela UI.

  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 à transferência 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 sua instância de encaminhador.

    Para saber mais sobre as configurações de cada tipo de mecanismo de transferência, como Splunk ou Syslog, consulte Definir tipos de dados no arquivo de configuração. Para saber mais sobre a personalização de cada atributo, como compactação de dados ou buffer de disco, consulte Configurar atributos principais no arquivo de configuração.

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

Todas as mudanças feitas no arquivo de configuração serão aplicadas automaticamente pelo encaminhador em até cinco minutos.

Configurações de amostra

Você pode usar os arquivos de configuração a seguir como modelos para criar os seus.

Configuração de amostra de dois arquivos

Esse sistema de arquivos armazena 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ão ou em qualquer sistema aberto de gerenciamento de configuração. É possível armazenar o arquivo FORWARDER_NAME_auth.conf diretamente na máquina física ou virtual que executa o forwarder.

O exemplo de código abaixo mostra o formato dos arquivos de configuração de um forwarder.

O 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

O 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"

Exemplo de configuração de um arquivo

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

Converter de um único arquivo para um sistema de dois arquivos

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

  1. Crie uma cópia do arquivo de configuração atual.

  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 sem autorização do arquivo. Use a configuração de exemplo como referência. Siga a convenção de nomenclatura e outras diretrizes mencionadas na seção Personalizar as configurações.

Definir tipos de dados no arquivo de configuração

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

Dados do Splunk

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

  • URL da API REST do 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).

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 Google SecOps. Para isso, crie um arquivo creds.txt.

Para usar um arquivo creds.txt:

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

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

    cat creds.txt
    
    myusername
    mypassword
    
  3. Para usar o forwarder do Google SecOps 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 armazenados).

    Linux

    cp creds.txt /opt/chronicle/config/creds.txt
    

    Windows

    cp creds.txt c:/opt/chronicle/config/creds.txt
    
  4. Verifique se o arquivo creds.txt está no diretório correto:

    Linux

      ls /opt/chronicle/config
    

    Windows

    ls c:/opt/chronicle/config
    

Dados do Syslog

Um encaminhador pode funcionar como um servidor Syslog. É possível configurar qualquer servidor compatível com o envio de dados Syslog por uma conexão TCP ou UDP para encaminhar os dados ao forwarder do Google SecOps. Você pode controlar os dados que o servidor envia para o redirecionador, que pode encaminhar os dados para o Google SecOps.

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

É possível personalizar o tamanho do buffer TCP. O tamanho padrão do buffer TCP é 64 KB. O valor padrão e recomendado para connection_timeout é de 60 segundos. A conexão TCP será encerrada se ficar inativa por mais de 60 segundos.

Configurar o rsyslog

Para configurar o rsyslog, é necessário especificar um destino para cada porta (por exemplo, cada tipo de dados). Os exemplos a seguir ilustram a configuração de destino do rsyslog:

  • Tráfego de registro TCP: dns.* @@192.168.0.12:10514

  • Tráfego de registro UDP: dns.* @192.168.0.12:10514

Consulte a documentação do sistema para mais detalhes.

Ativar o TLS para configurações do Syslog

É possível ativar o TLS para a conexão Syslog ao encaminhador do Google SecOps. No arquivo de configuração do encaminhador (FORWARDER_NAME.conf), especifique o local do seu próprio certificado e chave de certificado gerados, conforme mostrado no exemplo abaixo. Você pode criar um diretório certs no diretório configuration e armazenar os arquivos de certificado nele.

Linux:

certificado /opt/chronicle/external/certs/client_generated_cert.pem
certificate_key /opt/chronicle/external/certs/client_generated_cert.key

Windows:

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 forwarder (FORWARDER_NAME.conf) da seguinte maneira:

Linux:

 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"

Windows:

  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"

A versão TLS da solicitação de entrada precisa ser maior que a versão mínima de TLS. A versão mínima do TLS precisa ser um dos seguintes valores: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Dados de arquivo

Um coletor de arquivos é projetado para buscar registros de um arquivo vinculado ao contêiner do Docker. Use essa opção para fazer upload manual de registros de um único arquivo de registro.

Inicie o forwarder do Google SecOps no contêiner do Docker para mapear o volume de carga para o contêiner:

Linux

     docker run 
--detach
--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/falconhostclient:/opt/chronicle/edr
gcr.io/chronicle-container/cf_production_stable

Windows

  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/falconhostclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable_windows

É possível adicionar várias portas usando várias opções ou intervalos. Por exemplo: -p 3001:3000 -p 2023:2022 ou -p 7000-8000:7000-8000. Os números de porta fornecidos no código de exemplo são exemplos. Substitua os números de porta conforme necessário.

Com base no exemplo, é possível modificar a configuração do forwarder do Google SecOps (arquivo FORWARDER_NAME.conf) da seguinte maneira:

Linux

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

Windows

 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/sample.txt
       filter:

O arquivo sample.txt precisa estar presente na pasta /var/log/crowdstrike/falconhostclient.

Configurações de sinalização

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

poll (booleano): o coletor de arquivos usa a biblioteca Tail para verificar se há alterações 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.

Dados de pacote

O encaminhador do Google SecOps pode capturar pacotes em vez de entradas de registro, diretamente de uma interface de rede.

Sistemas Linux

O encaminhador do Google SecOps pode capturar pacotes usando libcap no Linux. Para mais informações sobre libcap, consulte libcap - Página de manual do Linux.

Em vez de entradas de registro, os pacotes de rede brutos são capturados e enviados para o Google Cloud. Essa captura é limitada a uma interface local. Para ativar a captura de pacotes no seu sistema, entre em contato com o Suporte do Google SecOps.

O Google Cloud configura o forwarder do Google SecOps com a expressão Berkeley Packet Filter (BPF, na sigla em inglês) usada ao capturar pacotes (por exemplo, a porta 53 e não o localhost). Para mais informações, consulte Filtros de pacote Berkeley.

Sistemas Windows

O encaminhador do Google SecOps pode capturar pacotes usando o Npcap em sistemas Windows.

Em vez de entradas de registro, os pacotes de rede brutos são capturados e enviados para o Google Cloud. Essa captura é limitada a uma interface local. Para configurar o encaminhador do Google SecOps para captura de pacotes, entre em contato com o suporte do Google SecOps.

Requisitos para um encaminhador de PCAP de captura de pacotes:

  • Instale o Npcap no host do Microsoft Windows.

  • Conceda privilégios de administrador ou raiz do encaminhador do Google SecOps para monitorar a interface de rede.

  • Na instalação do Npcap, ative o modo de compatibilidade do WinPcap.

Para configurar um encaminhador de 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 forwarder do Google SecOps (o servidor ou a máquina que ouve na porta de span) e envie a saída para o Google SecOps.

Como alternativa, você pode modificar o arquivo de configuração. Localize a seção PCAP e substitua o valor de GUID atual por GUID obtido com a execução de getmac.exe.

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

- 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

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}

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

A saída getmac.exe para o nome do transporte começa com \Device\Tcpip, enquanto a seção pcap comparável começa com \Device\NPF.

Dados do tópico do Kafka

O encaminhador das operações de segurança do Google oferece suporte à ingestão de dados diretamente dos tópicos do Kafka. É possível implantar até três encaminhadores e extrair dados do mesmo tópico do Kafka usando o conceito de grupos de consumidores para processamento eficiente e paralelo. Para mais informações, consulte Kafka. Para mais informações sobre grupos de consumidores do Kafka, consulte Consumidor do Kafka.

A configuração do forwarder a seguir mostra como configurá-lo para ingerir dados dos tópicos do Kafka.

Linux

O 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
   

O arquivo FORWARDER_NAME_auth.conf

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

Windows

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:

Dados do WebProxy

O encaminhador do Google SecOps pode capturar dados do WebProxy diretamente de uma interface de rede.

Linux

O encaminhador do Google SecOps pode capturar dados do WebProxy usando libcap no Linux. Para mais informações sobre libcap, consulte libcap - Página de manual do Linux. Para ativar a captura de dados do WebProxy no seu sistema, entre em contato com o suporte do Google SecOps.

Modifique a configuração do forwarder do Google SecOps (arquivo FORWARDER_NAME.conf) da seguinte maneira:

   - webproxy:
         common:
           enabled : true
           data_type: <Your LogType>
           batch_n_seconds: 10
           batch_n_bytes: 1048576
         interface: any
         bpf: tcp and dst port 80

Windows

O forwarder pode capturar dados do WebProxy 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 Google SecOps.

Antes de executar um encaminhador do WebProxy, siga estas etapas:

  1. Instale o Npcap no host do Microsoft Windows. Ative o modo de compatibilidade do WinPcap durante a instalação.

  2. Conceda privilégios de raiz ou administrador ao forwarder para monitorar a interface de rede.

  3. Obtenha o GUID da interface usada para capturar os pacotes do WebProxy.

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

    Modifique o arquivo de configuração do forwarder do Google SecOps (FORWARDER_NAME.conf) da seguinte maneira:

      - 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
    

Configurar atributos de chave no arquivo de configuração

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

Parâmetro Descrição
data_type O tipo de dados de registro que o coletor pode coletar e processar.
metadados Metadados, que substituem os metadados globais.
max_file_buffer_bytes Número máximo de bytes que podem ser acumulados no buffer de disco ou de arquivo. O valor padrão é 1073741824, ou seja, 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, ou 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 true, o buffer de disco é usado 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 depois que os dados são agrupados. O valor padrão é 1048576, ou 1 MB.
batch_n_seconds O número de segundos após o agrupamento dos dados coletados pelo coletor. O valor padrão é de 11 segundos.
data_hint Formato de dados que o coletor pode receber (geralmente o cabeçalho do arquivo de registro que descreve o formato).

Para conferir 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.

Compactação de dados

Por padrão, a compactação de registros está desativada. Ativar a 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. Avalie a compensação com base no seu ambiente e nos dados de registro.

Para ativar a compactação de registros, defina o campo compression como true no arquivo de configuração do forwarder do Google SecOps, conforme mostrado no exemplo abaixo:

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

O arquivo FORWARDER_NAME_auth.conf

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

Buffer de disco

O buffer de disco permite armazenar mensagens acumuladas no disco, em vez de na memória.

É possível configurar o buffer de memória automático para usar um buffer compartilhado dinamicamente em coletores, que lida melhor com picos no tráfego. Para ativar o buffer compartilhado dinamicamente, adicione o seguinte na configuração do forwarder:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

Se você estiver executando o forwarder usando o Docker, recomendamos 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

A configuração a seguir inclui sintaxe para ativar o buffer de 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

Filtros de expressão regular

Os filtros de expressão regular permitem filtrar registros com base na correspondência de padrões com os dados brutos. Os filtros usam a sintaxe RE2. 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 é block. É possível especificar filtros com o comportamento allow. Se você especificar um filtro allow, o encaminhador vai 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 Block têm precedência sobre os filtros allow.

Quando os filtros são definidos, eles precisam receber um nome. Os nomes dos filtros ativos serão informados ao Google SecOps por métricas de integridade do encaminhador. Os filtros definidos na raiz da configuração são mesclados com os filtros 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 coletor, o comportamento será permitir todos os registros.

Exemplo de configuração

Na configuração de encaminhamento 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" são bloqueados, mesmo com o 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

Rótulos arbitrários

Os rótulos são usados para anexar metadados personalizados aos registros usando pares de chave-valor. É possível configurar rótulos para um encaminhador inteiro ou em um coletor específico do encaminhador. Se ambos estiverem presentes, os rótulos no nível do coletor vão substituir os rótulos no nível do encaminhador se as chaves se sobreporem.

Exemplo de configuração

Na configuração do encaminhador a seguir, os pares de chave-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

Namespaces

É possível usar rótulos de namespace para identificar registros de segmentos de rede distintos e resolver conflitos de endereços IP sobrepostos. Qualquer namespace configurado para o encaminhador aparece com os recursos associados na interface do usuário do Google SecOps. Também é possível pesquisar namespaces usando o recurso de pesquisa de SecOps do Google.

Para saber como visualizar namespaces na interface do usuário do Google SecOps, consulte Namespace de recursos.

Exemplo de configuração

Na configuração de encaminhamento 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

Opções de balanceamento de carga e alta disponibilidade

É possível configurar o servidor HTTP, o balanceamento de carga e as opções de alta disponibilidade na seção do servidor do arquivo de configuração do forwarder. Essas opções oferecem suporte à configuração de durações de tempo limite e códigos de status retornados em resposta a verificações de integridade recebidas no programador de contêineres e implantações baseadas em orquestração, além de balanceadores de carga.

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

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

A configuração de 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
server : graceful_timeout O tempo que o encaminhador leva para retornar uma verificação de integridade/preparação incorreta e ainda aceitar novas conexões. Esse também é o tempo de espera entre o recebimento de um sinal para parar e o início do desligamento do servidor. Isso permite que o balanceador de carga remova o encaminhador do pool.
servidor : drain_timeout O tempo que o encaminhador aguarda o fechamento das conexões ativas por conta própria antes de serem fechadas pelo servidor.
server : http : port O número da porta que o servidor HTTP detecta para verificações de integridade do balanceador de carga. Precisa estar entre 1024 e 65.535.
server : http : host O endereço IP ou nome de 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).
server : 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, incluindo o cabeçalho e o corpo. É possível definir read_timeout e read_header_timeout.
server : http : read_header_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 cabeçalhos de solicitação. O prazo de leitura da conexão é redefinido após a leitura do cabeçalho.
server : 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.
server : 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 para a próxima solicitação quando as conexões inativas estão ativadas. Se idle_timeout for zero, o valor de read_timeout será usado. Se ambos forem zero, o read_header_timeout será usado.
routes : meta : ready_status O código de status que o encaminhador retorna quando está 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êineres.
  • A verificação de integridade é recebida de um balanceador de carga tradicional.
routes : meta : unready_status O código de status que o encaminhador retorna quando não está pronto para aceitar tráfego.
routes : 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. Os programadores ou orquestradores de contêineres geralmente enviam verificações de atividade.