Gestire manualmente il file di configurazione dell'agente di inoltro

Supportato in:

Questa pagina descrive come creare e modificare manualmente un file di configurazione del forwarder di Google Security Operations. Per configurare il forwarder tramite l'interfaccia utente (consigliato), vedi Gestire le configurazioni del forwarder tramite l'interfaccia utente di Google SecOps.

Ogni inoltro Google SecOps di cui è stato eseguito il deployment richiede un file di configurazione dell'inoltro. Un file di configurazione del forwarder specifica le impostazioni per trasferire i dati all'istanza Google SecOps.

Per informazioni su come installare e configurare il forwarder Google SecOps, sui requisiti di sistema e sui dettagli delle impostazioni di configurazione, vedi Installare e configurare il forwarder.

Prima di iniziare

Prima di creare il file di configurazione, pianifica l'implementazione comprendendo i tipi di dati che possono essere importati e gli attributi chiave che devi definire all'interno del file di configurazione.

Crea il file di configurazione

Per creare manualmente il file di configurazione:

  1. Scarica i file di configurazione tramite la UI.

  2. Salva i due file nella stessa directory utilizzando la seguente convenzione di denominazione:

    FORWARDER_NAME.conf: utilizza questo file per definire le impostazioni di configurazione relative all'importazione dei log.

    FORWARDER_NAME_auth.conf: utilizza questo file per definire le credenziali di autorizzazione.

  3. Modifica i file per includere la configurazione dell'istanza dell'agente di inoltro.

    Per informazioni dettagliate sulle impostazioni per ogni tipo di meccanismo di importazione, come Splunk o Syslog, vedi Definire i tipi di dati nel file di configurazione. Per informazioni dettagliate sulla personalizzazione di ogni attributo, ad esempio la compressione dei dati o il buffering del disco, vedi Configurare gli attributi chiave nel file di configurazione.

  4. Assicurati che esista una voce per ogni input nel file FORWARDER_NAME_auth.conf anche se l'input non ha dettagli di autenticazione corrispondenti. Questo è necessario per mappare correttamente i dati.

Qualsiasi modifica apportata al file di configurazione verrà applicata automaticamente dal forwarder entro cinque minuti.

Configurazioni di esempio

Puoi fare riferimento ai seguenti file di configurazione come modelli per creare i tuoi.

Configurazione di esempio di due file

Questo sistema a due file memorizza le credenziali di autenticazione in un file separato per una maggiore sicurezza. Puoi archiviare il file FORWARDER_NAME.conf in un repository di controllo delle versioni o in qualsiasi sistema di gestione della configurazione aperto. Puoi archiviare il file FORWARDER_NAME_auth.conf direttamente nella macchina fisica o virtuale che esegue il forwarder.

Il seguente esempio di codice mostra il formato dei file di configurazione per un inoltratore.

Il file FORWARDER_NAME.conf

output:
  url: {region}-chronicle.googleapis.com (for example: us-chronicle.googleapis.com)
  use_dataplane : true
  project_id: PROJECT_ID
  region: {region} (for example: {us})
  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

Il file 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"

Configurazione di esempio di un singolo file

output:
  url: us-chronicle.googleapis.com
  use_dataplane: true
  project_id: PROJECT_ID
  region: us
    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

Conversione da un sistema a un solo file a un sistema a due file

Se utilizzi un unico file di configurazione e vuoi passare al sistema a due file, segui questi passaggi:

  1. Crea una copia del file di configurazione esistente.

  2. Salva un file come file FORWARDER_NAME.conf ed elimina le credenziali di autorizzazione dal file.

  3. Salva l'altro file come file FORWARDER_NAME_auth.conf ed elimina tutti i dati non di autorizzazione dal file. Puoi utilizzare la configurazione di esempio come riferimento. Assicurati di seguire la convenzione di denominazione e le altre linee guida menzionate nella sezione Personalizzare le configurazioni.

Definisci i tipi di dati nel file di configurazione

Le seguenti sezioni ti aiutano a configurare il forwarder Google SecOps per l'importazione di diversi tipi di dati, che vengono inoltrati all'istanza Google SecOps.

Dati Splunk

Puoi configurare il forwarder Google SecOps per inoltrare i dati di Splunk a Google SecOps. Google Cloud configura il forwarder Google SecOps con le seguenti informazioni per inoltrare i dati da Splunk:

  • URL dell'API REST di Splunk (ad esempio https://10.0.113.15:8089).

  • Query Splunk per generare dati per ciascuno dei tipi di dati richiesti (ad esempio, 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
  • Rendi disponibili le credenziali del tuo account Splunk al forwarder Google SecOps. Per farlo, crea un file creds.txt.

Per utilizzare un file creds.txt:

  1. Crea un file locale per le tue credenziali Splunk e chiamalo creds.txt.

  2. Inserisci il nome utente sulla prima riga e la password sulla seconda:

    cat creds.txt

myusername
mypassword

  3. Per utilizzare il forwarder Google SecOps per accedere a un'istanza Splunk, copia il file creds.txt nella directory di configurazione (la stessa directory in cui si trovano i file di configurazione).

    Linux

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

    Windows

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

  4. Verifica che il file creds.txt si trovi nella directory prevista:

    Linux

      ls /opt/chronicle/config

    Windows

    ls c:/opt/chronicle/config

Dati Syslog

Un forwarder può funzionare come server Syslog. Puoi configurare qualsiasi server che supporti l'invio di dati Syslog tramite una connessione TCP o UDP per inoltrare i dati al forwarder Google SecOps. Puoi controllare i dati che il server invia al forwarder, che a sua volta può inoltrare i dati a Google SecOps.

Il file di configurazione FORWARDER_NAME.conf (fornito da Google Cloud) specifica le porte da monitorare per ogni tipo di dati inoltrati (ad esempio, la porta 10514). Per impostazione predefinita, il forwarder Google SecOps accetta connessioni TCP e UDP.

Puoi personalizzare la dimensione del buffer TCP. La dimensione predefinita del buffer TCP è 64 kB. Il valore predefinito e consigliato per connection_timeout è 60 secondi. La connessione TCP viene terminata se è inattiva per più di 60 secondi.

Configura rsyslog

Per configurare rsyslog, devi specificare una destinazione per ogni porta (ad esempio, ogni tipo di dati). Gli esempi seguenti illustrano la configurazione della destinazione rsyslog:

  • Traffico log TCP: dns.* @@192.168.0.12:10514

  • Traffico log UDP: dns.* @192.168.0.12:10514

Per informazioni dettagliate, consulta la documentazione del sistema.

Attiva TLS per le configurazioni Syslog

Puoi attivare TLS per la connessione Syslog al forwarder Google SecOps. Nel file di configurazione del forwarder (FORWARDER_NAME.conf), specifica la posizione del certificato e della chiave del certificato generati, come mostrato nell'esempio seguente. Puoi creare una directory certs nella directory configuration e archiviare i file del certificato.

Linux:

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

Windows:

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

In base all'esempio mostrato, modifica il file di configurazione del forwarder (FORWARDER_NAME.conf) come segue:

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"

La versione TLS della richiesta di input deve essere maggiore della versione TLS minima. La versione TLS minima deve essere uno dei seguenti valori: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Dati del file

Un raccoglitore di file è progettato per recuperare i log da un file associato al container Docker. Puoi utilizzare questa opzione se vuoi caricare manualmente i log da un singolo file di log.

Avvia il programma di inoltro Google SecOps dal container Docker per mappare il volume di carico al container:

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

Puoi aggiungere più porte utilizzando più opzioni o più intervalli. Ad esempio: -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000. I numeri di porta forniti nel codice campione sono esempi. Sostituisci i numeri di porta in base alle tue esigenze.

In base all'esempio, puoi modificare la configurazione del forwarder Google SecOps (file FORWARDER_NAME.conf) come segue:

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:

Il file sample.txt deve essere presente nella cartella /var/log/crowdstrike/falconhostclient.

Configurazioni dei flag

skip_seek_to_end (booleano): questo flag è impostato su false per impostazione predefinita e l'input del file invia solo le nuove righe di log come input. Se imposti questo valore su true, tutte le righe di log precedenti vengono inviate di nuovo durante i riavvii del forwarder. Ciò causa la duplicazione dei log. L'impostazione di questo flag su true è utile in determinate situazioni (ad esempio, durante le interruzioni), perché il riavvio del forwarder invia di nuovo le righe di log mancanti.

poll (booleano): il raccoglitore di file utilizza la libreria Tail per verificare la presenza di modifiche nel file system. Se imposti questo flag su true, la libreria Tail utilizza il metodo di polling anziché il metodo di notifica predefinito.

Dati dei pacchetti

Il forwarder Google SecOps può acquisire pacchetti anziché voci di log direttamente da un'interfaccia di rete.

Sistemi Linux

Il forwarder Google SecOps può acquisire pacchetti utilizzando libcap su Linux. Per saperne di più su libcap, consulta libcap - Linux manual page.

Anziché le voci di log, vengono acquisiti e inviati a Google SecOps i pacchetti di rete non elaborati. Questa acquisizione è limitata a un'interfaccia locale. Per attivare l'acquisizione di pacchetti per il tuo sistema, contatta l'assistenza Google SecOps.

Google SecOps configura il forwarder Google SecOps con l'espressione Berkeley Packet Filter (BPF) utilizzata durante l'acquisizione dei pacchetti (ad esempio, porta 53 e non localhost). Per saperne di più, consulta Filtri di pacchetti Berkeley.

Sistemi Windows

Il forwarder Google SecOps può acquisire pacchetti utilizzando Npcap sui sistemi Windows.

Anziché le voci di log, vengono acquisiti e inviati a Google SecOps i pacchetti di rete non elaborati. Questa acquisizione è limitata a un'interfaccia locale. Per configurare il tuo forwarder Google SecOps per l'acquisizione di pacchetti, contatta l'assistenza Google SecOps.

Requisiti per un programma di inoltro PCAP di acquisizione pacchetti:

  • Installa Npcap sull'host Microsoft Windows.

  • Concedi i privilegi di root o amministratore al forwarder Google SecOps per monitorare l'interfaccia di rete.

  • Durante l'installazione di Npcap, attiva la modalità di compatibilità WinPcap.

Per configurare un forwarder PCAP, Google Cloud ha bisogno del GUID dell'interfaccia utilizzata per acquisire i pacchetti. Esegui getmac.exe sulla macchina in cui prevedi di installare il forwarder Google SecOps (il server o la macchina in ascolto sulla porta span) e invia l'output a Google SecOps.

In alternativa, puoi modificare il file di configurazione. Individua la sezione PCAP e sostituisci il valore GUID esistente con il GUID ottenuto eseguendo getmac.exe.

Ad esempio, ecco una sezione PCAP originale:

- 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

Output dell'esecuzione di getmac.exe:

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

Sezione PCAP rivista con il nuovo 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

L'output getmac.exe per il nome del trasporto inizia con \Device\Tcpip, mentre la sezione pcap comparabile inizia con \Device\NPF.

Dati dall'argomento Kafka

Il forwarder Google SecOps supporta l'importazione di dati direttamente dagli argomenti Kafka. Puoi eseguire il deployment di un massimo di tre forwarder ed estrarre i dati dallo stesso argomento Kafka sfruttando il concetto di gruppi di consumer per un'elaborazione efficiente e parallela. Per ulteriori informazioni, vedi Kafka. Per ulteriori informazioni sui gruppi di consumer Kafka, vedi Consumer Kafka.

La seguente configurazione del forwarder mostra come configurare il forwarder per l'importazione dei dati dagli argomenti Kafka.

Linux

Il file 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

Il file FORWARDER_NAME_auth.conf

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

Windows

File 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

File FORWARDER_NAME_auth.conf

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

Dati WebProxy

Il forwarder Google SecOps può acquisire i dati WebProxy direttamente da un'interfaccia di rete.

Linux

Il forwarder Google SecOps può acquisire i dati di WebProxy utilizzando libcap su Linux. Per saperne di più su libcap, consulta libcap - Linux manual page. Per attivare l'acquisizione dei dati WebProxy per il tuo sistema, contatta l'assistenza Google SecOps.

Modifica la configurazione dell'agente di inoltro Google SecOps (file FORWARDER_NAME.conf) come segue:

   - 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

Il forwarder può acquisire i dati di WebProxy utilizzando Npcap e inviarli a Google Cloud.

Per attivare l'acquisizione dei dati WebProxy per il tuo sistema, contatta l'assistenza Google SecOps.

Prima di eseguire un forwarder WebProxy:

  1. Installa Npcap sull'host Microsoft Windows. Attiva la modalità di compatibilità WinPcap durante l'installazione.

  2. Concedi i privilegi di root o amministratore al forwarder per monitorare l'interfaccia di rete.

  3. Ottieni il GUID dell'interfaccia utilizzata per acquisire i pacchetti WebProxy.

    Esegui getmac.exe sulla macchina in cui vuoi installare il forwarder Google SecOps e invia l'output a Google SecOps. In alternativa, puoi modificare il file di configurazione. Individua la sezione WebProxy e sostituisci il GUID mostrato accanto all'interfaccia con il GUID visualizzato dopo l'esecuzione di getmac.exe.

    Modifica il file di configurazione dell'agente di inoltro Google SecOps (FORWARDER_NAME.conf) come segue:

      - 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

Configura gli attributi della chiave nel file di configurazione

La tabella seguente elenca i parametri importanti utilizzati nel file di configurazione del forwarder.

Parametro Descrizione
data_type Il tipo di dati di log che il raccoglitore può raccogliere ed elaborare.
metadati Metadati, che sostituiscono i metadati globali.
max_file_buffer_bytes Il numero massimo di byte che possono essere accumulati nel buffer del disco o del file. Il valore predefinito è 1073741824, ovvero 1 GB.
max_memory_buffer_bytes Numero massimo di byte che possono essere accumulati nel buffer di memoria. Il valore predefinito è 1073741824, ovvero 1 GB.
write_to_disk_dir_path Il percorso da utilizzare per il buffer del file o del disco.
write_to_disk_buffer_enabled Se true, viene utilizzato il buffer su disco anziché il buffer di memoria. Il valore predefinito è false.
batch_n_bytes Numero massimo di byte che possono essere accumulati dal raccoglitore dopo il quale i dati vengono raggruppati in batch. Il valore predefinito è 1048576, ovvero 1 MB.
batch_n_seconds Il numero di secondi dopo i quali i dati raccolti dal raccoglitore vengono raggruppati in batch. Il valore predefinito è 11 secondi.
data_hint Formato dei dati che il raccoglitore può ricevere (di solito l'intestazione del file di log che descrive il formato).

Per un elenco completo dei parametri utilizzati nel file di configurazione, vedi Campi di configurazione del forwarder e Campi di configurazione del raccoglitore.

Compressione dei dati

Per impostazione predefinita, la compressione dei log è disattivata. L'attivazione della compressione dei log potrebbe ridurre il consumo di larghezza di banda. Tuttavia, l'attivazione della compressione dei log potrebbe anche aumentare l'utilizzo della CPU. Valuta il compromesso in base al tuo ambiente e ai dati di log.

Per abilitare la compressione dei log, imposta il campo compression su true nel file di configurazione del forwarder Google SecOps come mostrato nell'esempio seguente:

Il file 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
...

Il file FORWARDER_NAME_auth.conf

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

Buffering del disco

Il buffering su disco consente di eseguire il buffering dei messaggi arretrati sul disco anziché sulla memoria.

Puoi configurare il buffering automatico della memoria in modo da utilizzare un buffer condiviso dinamicamente tra i raccoglitori, che gestisce meglio i picchi di traffico. Per attivare il buffer condiviso dinamicamente, aggiungi quanto segue alla configurazione del forwarder:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

Se il buffering automatico del disco è attivato, ma target_memory_utilization non è definito, viene utilizzato un valore predefinito di 70.

Se esegui il forwarder utilizzando Docker, ti consigliamo di montare un volume separato dal volume di configurazione per motivi di isolamento. Inoltre, ogni input deve essere isolato con la propria directory o il proprio volume per evitare conflitti.

Esempio di configurazione

La seguente configurazione include la sintassi per attivare il buffering del 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

Filtri basati su espressioni regolari

I filtri con espressioni regolari consentono di filtrare i log in base ai pattern corrispondenti ai dati di log non elaborati. I filtri utilizzano la sintassi RE2. I filtri devono includere un'espressione regolare e, facoltativamente, definire un comportamento in caso di corrispondenza.

Il comportamento predefinito in caso di corrispondenza è block. Puoi specificare i filtri con il comportamento allow. Se specifichi un filtro allow, l'inoltro blocca tutti i log che non corrispondono ad almeno un filtro allow.

È possibile definire un numero arbitrario di filtri. I filtri Block hanno la precedenza sui filtri allow.

Quando vengono definiti i filtri, deve essere assegnato loro un nome. I nomi dei filtri attivi verranno segnalati a Google SecOps tramite le metriche di integrità del forwarder. I filtri definiti nella radice della configurazione vengono uniti a quelli definiti a livello di collettore. I filtri a livello di raccoglitore hanno la precedenza in caso di nomi in conflitto. Se non vengono definiti filtri a livello di root o di raccoglitore, il comportamento è quello di consentire tutti i log.

Esempio di configurazione

Nella seguente configurazione del forwarder, i log WINEVTLOG che non corrispondono al filtro principale (allow_filter) vengono bloccati. Data l'espressione regolare, il filtro consente solo i log con priorità comprese tra 0 e 99. Tuttavia, tutti i log NIX_SYSTEM contenenti "foo" o "bar" vengono bloccati, nonostante allow_filter. Questo perché i filtri utilizzano un OR logico. Tutti i log vengono elaborati finché non viene attivato un filtro.

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

Etichette arbitrarie

Le etichette vengono utilizzate per allegare metadati personalizzati ai log utilizzando coppie chiave-valore. Puoi configurare le etichette per un intero forwarder o all'interno di un raccoglitore specifico del forwarder. Se sono presenti entrambi, le etichette a livello di raccoglitore sostituiscono le etichette a livello di inoltro se le chiavi si sovrappongono.

Esempio di configurazione

Nella seguente configurazione del forwarder, le coppie chiave-valore "foo=bar" e "meow=mix" sono entrambe associate ai log WINEVTLOG, mentre le coppie chiave-valore "foo=baz" e "meow=mix" sono associate ai log 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

Spazi dei nomi

Puoi utilizzare le etichette dello spazio dei nomi per identificare i log da segmenti di rete distinti e risolvere i conflitti degli indirizzi IP sovrapposti. Qualsiasi spazio dei nomi configurato per il forwarder viene visualizzato con gli asset associati nell'interfaccia utente di Google SecOps. Puoi anche cercare gli spazi dei nomi utilizzando la funzionalità di ricerca di Google SecOps.

Per informazioni su come visualizzare gli spazi dei nomi nell'interfaccia utente di Google SecOps, consulta Spazi dei nomi degli asset.

Esempio di configurazione

Nella seguente configurazione del forwarder, i log WINEVTLOG sono associati allo spazio dei nomi FORWARDER e i log NIX_SYSTEM sono associati allo spazio dei nomi 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

Opzioni di bilanciamento del carico e alta disponibilità

Puoi configurare le opzioni del server HTTP, del bilanciamento del carico e dell'alta disponibilità nella sezione server del file di configurazione del forwarder. Queste opzioni supportano l'impostazione delle durate del timeout e dei codici di stato restituiti in risposta ai controlli di integrità ricevuti nelle implementazioni basate su scheduler e orchestrazione dei container, nonché dai bilanciatori del carico.

Utilizza i seguenti percorsi URL per i controlli di integrità, idoneità e attività. I valori <host:port> sono definiti nella configurazione del forwarder.

  • http://<host:port>/meta/available: Controlli di attività per gli orchestratori o gli scheduler dei container
  • http://<host:port>/meta/ready: Controlli di idoneità e controlli di integrità del bilanciatore del carico

La seguente configurazione del forwarder è un esempio per il bilanciamento del carico e l'alta disponibilità:

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
Percorso di configurazione Descrizione
server : graceful_timeout Il periodo di tempo durante il quale il forwarder restituisce un controllo di integrità/prontezza non valido e accetta ancora nuove connessioni. Questo è anche il tempo di attesa tra la ricezione di un segnale di arresto e l'inizio effettivo dell'arresto del server stesso. In questo modo il bilanciatore del carico ha il tempo di rimuovere l'inoltro dal pool.
server : drain_timeout Il tempo di attesa del forwarder prima che le connessioni attive si chiudano autonomamente prima di essere chiuse dal server.
server : http : port Il numero di porta su cui il server HTTP rimane in ascolto per i controlli di integrità dal bilanciatore del carico. Deve essere compreso tra 1024 e 65535.
server : http : host L'indirizzo IP o il nome host che può essere risolto in indirizzi IP a cui il server deve rimanere in ascolto. Se è vuoto, il valore predefinito è il sistema locale (0.0.0.0).
server : http : read_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Il tempo massimo consentito per leggere l'intera richiesta, sia l'intestazione che il corpo. Puoi impostare sia read_timeout sia read_header_timeout.
server : http : read_header_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Il periodo di tempo massimo consentito per leggere le intestazioni della richiesta. Il termine di lettura della connessione viene reimpostato dopo la lettura dell'intestazione.
server : http : write_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Il periodo di tempo massimo consentito per inviare una risposta. Viene reimpostato quando viene letto un nuovo header della richiesta.
server : http : idle_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Il tempo massimo di attesa per la successiva richiesta quando le connessioni inattive sono abilitate. Se idle_timeout è zero, viene utilizzato il valore di read_timeout. Se entrambi sono zero, viene utilizzato read_header_timeout.
routes : meta : ready_status Il codice di stato restituito dal forwarder quando è pronto ad accettare il traffico in una delle seguenti situazioni:
  • Il controllo di idoneità viene ricevuto da un orchestratore o da uno scheduler di container.
  • Il controllo di integrità viene ricevuto da un bilanciatore del carico tradizionale.
routes : meta : unready_status Il codice di stato restituito dal forwarder quando non è pronto ad accettare il traffico.
routes : meta : available_status Il codice di stato restituito dall'inoltratore quando viene ricevuto un controllo di reattività e l'inoltratore è disponibile. Gli orchestratori o gli scheduler di container spesso inviano controlli di attività.

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.