Gerenciar o arquivo de configuração do forwarder manualmente
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:
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.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.
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:
Crie uma cópia do arquivo de configuração atual.
Salve um arquivo como
FORWARDER_NAME
.conf e exclua as credenciais de autorização dele.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
:
Crie um arquivo local para suas credenciais do Splunk e nomeie-o como
creds.txt
.Coloque seu nome de usuário na primeira linha e a senha na segunda:
cat creds.txt myusername mypassword
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
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:
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 administrador ao forwarder para monitorar a interface de rede.
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 degetmac.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êinereshttp://<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:
|
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. |