Gestisci manualmente il file di configurazione dell'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 (opzione consigliata), consulta Gestire le configurazioni del forwarder tramite l'interfaccia utente di Google SecOps.

Ogni utente che esegue il deployment di Google SecOps richiede un servizio di inoltro di configurazione del deployment. Un file di configurazione del forwarding specifica le impostazioni in cui trasferire i dati la tua istanza Google SecOps.

Per informazioni su come installare e configurare Google SecOps inoltro, requisiti di sistema e dettagli sulle impostazioni di configurazione, vedi Installa e configura il forwarding.

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 da definire all'interno del file di configurazione.

Crea il file di configurazione

Per creare il file di configurazione manualmente:

  1. Scarica i file di configurazione tramite l'interfaccia utente.

  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 in modo da includere la configurazione per l'istanza di inoltro.

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

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

Qualsiasi modifica al file di configurazione verrà applicata automaticamente lo spedizioniere entro cinque minuti.

Configurazioni di esempio

Puoi fare riferimento ai seguenti file di configurazione come modelli per creare la tua.

Configurazione di esempio con due file

Questo file system archivia le credenziali di autenticazione in un per una maggiore sicurezza. Puoi archiviare il file FORWARDER_NAME.conf in un repository di controllo della versione o in qualsiasi sistema aperto di gestione delle configurazioni. Puoi memorizzare il FORWARDER_NAME_auth.conf direttamente nella macchina virtuale o fisica su cui è in esecuzione il forwarder.

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

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

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 con un unico file

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

Converti da singolo file a due file system

Se utilizzi un unico file di configurazione e vuoi passare al sistema di due file:

  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 e eliminare dal file tutti i dati non di autorizzazione. Puoi utilizzare lo configurazione di esempio come riferimento. Assicurati di seguire la convenzione di denominazione e altre linee guida menzionate nella sezione Personalizza le configurazioni.

Definire i tipi di dati nel file di configurazione

Le sezioni seguenti aiutano a configurare le impostazioni Google SecOps di importare diversi tipi di dati, ovvero vengono inoltrati all'istanza di Google SecOps.

Dati di Splunk

Puoi configurare lo strumento di forwarding di Google SecOps in modo che inoltri il tuo 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 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 per Google SecOps spedizioniere. Per farlo, puoi creare un file creds.txt.

Per utilizzare un file creds.txt:

  1. Crea un file locale per le tue credenziali Splunk e assegnagli il nome creds.txt.

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

    cat creds.txt

myusername
mypassword

  3. Per utilizzare lo strumento di inoltro di Google SecOps per accedere a uno Splunk copia il file creds.txt nella directory di configurazione (lo stesso 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 server di inoltro può funzionare come server Syslog. Puoi configurare qualsiasi server che supporta l'invio di dati Syslog tramite TCP o UDP connessione per inoltrare i propri dati al forwarding Google SecOps. Puoi controllare i dati inviati dal server al forwarder, che a sua volta può inoltrarli a Google SecOps.

Il file di configurazione FORWARDER_NAME.conf (fornito da Google Cloud) specifica quali porte monitorare per ciascun tipo dati inoltrati (ad esempio, porta 10514). Per impostazione predefinita, il forwarder Google SecOps accetta connessioni sia TCP che 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 rimane inattiva per più di 60 secondi.

Configura rsyslog

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

  • Registra il traffico TCP: dns.* @@192.168.0.12:10514

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

Per informazioni dettagliate, consulta la documentazione del sistema.

Abilita TLS per configurazioni Syslog

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

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 l'utente che ha eseguito l'inoltro di configurazione del deployment (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 superiore a la versione TLS minima. La versione TLS minima deve essere uno dei seguenti valori: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Dati dei file

Un raccoglitore di file è progettato per recuperare i log da un file associato al contenitore Docker. Puoi usare questa opzione se vuoi caricare manualmente da un unico file di log.

Avvia il forwarder Google SecOps dal container Docker per mappare il volume di caricamento 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 intervalli. Per esempio: -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000. I numeri di porta forniti nel codice di esempio sono esempi. Sostituisci i numeri delle porte 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 /var/log/crowdstrike/falconhostclient cartella.

Configurazioni dei flag

skip_seek_to_end (bool): questo flag è impostato su false per impostazione predefinita e l'input del file invia solo nuove righe di log. Se viene impostato su true, righe di log precedenti da inviare di nuovo durante i riavvii dell'inoltro. Questo fa sì che i log duplicati. L'impostazione di questo flag su true è utile in alcuni (ad esempio durante le interruzioni), perché il riavvio del server di inoltro invia mancano di nuovo le righe di log.

poll (bool): il raccoglitore di file utilizza la libreria Tail per verificare eventuali modifiche nel sistema file. Se imposti questo flag su true, la libreria Tail utilizza i sondaggi anziché il metodo di notifica predefinito.

Dati dei pacchetti

Il forwarding di Google SecOps può acquisire i pacchetti anziché il log direttamente da un'interfaccia di rete.

Sistemi Linux

Il forwarder Google SecOps può acquisire i pacchetti utilizzando libcap su Linux. Per ulteriori informazioni su libcap, consulta libcap - Pagina del manuale di Linux.

Invece delle voci di log, i pacchetti di rete non elaborati vengono acquisiti e inviati in Google Cloud. Questa acquisizione è limitata a un'interfaccia locale. Per attivare la cattura dei pacchetti per il tuo sistema, contatta l'assistenza di Google SecOps.

Google Cloud configura il forwarder Google SecOps con l'espressione Berkeley Packet Filter (BPF) utilizzata per acquisire i pacchetti (ad esempio la porta 53 e non localhost). Per ulteriori informazioni, vedi Filtri di pacchetto Berkeley.

Sistemi Windows

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

Invece delle voci di log, i pacchetti di rete non elaborati vengono acquisiti e inviati a Google Cloud. Questa acquisizione è limitata a un'interfaccia locale. Per configurare il tuo forwarding Google SecOps per l'acquisizione dei pacchetti, Assistenza di Google SecOps.

Requisiti per un forwarding PCAP di acquisizione pacchetti:

  • Installa Npcap sull'host Microsoft Windows.

  • Concedi all'amministratore o al rooter di Google SecOps per monitorare l'interfaccia di rete.

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

Per configurare un forwarder PCAP, Google Cloud ha bisogno del GUID per l'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 dall'esecuzione di 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 aggiornata 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 paragonabile inizia con \Device\NPF.

Dati da argomento Kafka

Il forwarding di Google Security Operations supporta l'importazione di dati direttamente da Kafka argomenti. Puoi implementare fino a tre forwarder e recuperare i dati dallo stesso argomento Kafka sfruttando il concetto di gruppi di consumer per un'elaborazione efficiente e parallela. Per ulteriori informazioni, consulta Kafka. Per ulteriori informazioni sul consumer Kafka gruppi, vedi consumatore 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

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

FORWARDER_NAMEFile_auth.conf

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

Dati WebProxy

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

Linux

Il forwarding Google SecOps può acquisire dati WebProxy utilizzando libcap su Linux. Per ulteriori informazioni su libcap, consulta libcap - Pagina di manuale di Linux. Per attivare l'acquisizione dei dati di WebProxy per il tuo sistema, contatta l'assistenza di Google SecOps.

Modifica la configurazione dell'inoltro di 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

L'utente che esegue l'inoltro può acquisire i dati del proxy Web utilizzando Npcap e inviarli a Google Cloud.

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

Prima di eseguire un inoltro WebProxy:

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

  2. Concedi i privilegi root o amministratore all'utente che ha eseguito l'inoltro per monitorare l'interfaccia di rete.

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

    Esegui getmac.exe sulla macchina su 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 visualizzato accanto all'interfaccia con quello visualizzato dopo l'esecuzione di getmac.exe.

    Modifica la configurazione dello strumento di forwarding di 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

Configurare gli attributi chiave nel file di configurazione

Nella tabella seguente sono elencati i parametri importanti utilizzati nello strumento di inoltro di configurazione del deployment.

Parametro Descrizione
data_type Il tipo di dati dei log che il raccoglitore può raccogliere ed elaborare.
metadati Metadati, che eseguono l'override dei metadati globali.
max_file_buffer_bytes 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. La 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 del disco al posto del buffer di memoria. Il valore predefinito è false.
batch_n_bytes Numero massimo di byte che possono essere accumulati dal raccoglitore dopo la quale i dati vengono raggruppati. Il valore predefinito è 1048576, ovvero 1 MB.
batch_n_seconds Il numero di secondi dopo i quali i dati raccolti dal raccoglitore vengono in batch. Il valore predefinito è 11 secondi.
data_hint Formato dei dati che il raccoglitore può ricevere (in genere l'intestazione del file di log che descrive il formato).

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

Compressione 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'abilitazione della compressione dei log potrebbe aumenta l'utilizzo della CPU. Valuta il compromesso in base al tuo ambiente e ai dati dei log.

Per abilitare la compressione dei log, imposta il campo compression su true nel file di configurazione dello strumento di inoltro di Google SecOps come mostrato nell'esempio che segue:

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 del disco consente di eseguire il buffer dei messaggi in backlog sul disco, la memoria.

Puoi configurare il buffering automatico della memoria per utilizzare un buffer condiviso dinamicamente tra i collector, che gestisce meglio i picchi di traffico. Per attivare il buffer condiviso dinamicamente, aggiungi quanto segue nella 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 distinto dal volume di configurazione a scopo di isolamento. Inoltre, ogni input deve essere isolato con la propria directory o volume per evitare conflitti.

Esempio di configurazione

La seguente configurazione include la sintassi per abilitare 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 delle espressioni regolari ti consentono di filtrare i log associando i pattern ai dati non elaborati dei log. 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 su una corrispondenza è block. Puoi specificare filtri con comportamento allow. Se specifichi un filtro allow, il forwarder blocca tutti i log che non corrispondono ad almeno un filtro allow.

È possibile definire un numero arbitrario di filtri. Block filtri richiedono precedenza sui filtri di allow.

Quando i filtri sono definiti, devono essere assegnati un nome. I nomi delle persone attive i filtri verranno segnalati a Google SecOps tramite lo stato dello inoltro metriche di valutazione. Filtri definiti alla base della configurazione vengono uniti ai filtri definiti alla a livello di raccoglitore. I filtri a livello di raccoglitore hanno la precedenza nei casi di nomi in conflitto. Se non è definito nessun filtro nella directory principale o nel raccoglitore di accesso, il comportamento è consentire tutti i log.

Esempio di configurazione

Nella seguente configurazione del forwarder, i log WINEVTLOG che non corrispondono al filtro principale (allow_filter) sono 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" sono bloccati, nonostante allow_filter. perché i filtri utilizzano un operatore logico OR. Tutti vengono elaborati fino all'attivazione di 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 collegare metadati personalizzati ai log utilizzando coppie chiave-valore. Puoi configurare le etichette per un intero server di inoltro o all'interno di un raccoglitore specifico dello spedizioniere. Se sono presenti entrambe, le etichette a livello di gatherer sostituiscono le etichette a livello di forwarder 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 di segmenti di rete distinti o eliminare i conflitti di indirizzi IP sovrapposti. Tutti gli spazi dei nomi configurati per il server di inoltro vengono visualizzati con gli asset associati in l'interfaccia utente di Google SecOps. Puoi anche cercare spazi dei nomi usando 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 delle risorse.

Esempio di configurazione

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

Bilanciamento del carico e opzioni di alta disponibilità

Puoi configurare il server HTTP, il bilanciamento del carico e le opzioni di alta disponibilità nella sezione del server del file di configurazione del forwarder. Queste opzioni supportano l'impostazione delle durate dei timeout e dei codici di stato restituiti in risposta ai controlli di salute ricevuti nei deployment basati su orchestrazione e nello scheduler 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 il container scheduler o orchestratori
  • http://<host:port>/meta/ready: controlli di idoneità e controlli di integrità del bilanciatore del carico

La seguente configurazione del server di inoltro è un esempio per il bilanciamento del carico e 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 tempo durante il quale il forwarder restituisce un controllo di idoneità/integrità errato e accetta ancora nuove connessioni. Questo è anche il tempo di attesa tra ricevere un segnale per interrompere e avviare effettivamente l'arresto della sul server stesso. In questo modo il bilanciatore del carico ha il tempo di rimuovere il forwarder dal pool.
server : scratch_timeout Il tempo che il forwarder attende prima che le connessioni attive si chiudano autonomamente prima di essere chiuse dal server.
server : http : porta Il numero di porta su cui il server HTTP rimane in ascolto per i controlli di integrità dal bilanciatore del carico. Il valore deve essere compreso tra 1024 e 65535.
server : http : host L'indirizzo IP o il nome host che può essere risolto in indirizzi IP su cui il server deve ascoltare. Se è vuoto, il valore predefinito è il sistema locale (0.0.0.0).
server : http : tempo_di_lettura 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 tempo massimo consentito per leggere la richiesta intestazioni. La scadenza di lettura della connessione viene reimpostata dopo la lettura dell'intestazione.
server : http : write_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario cambiare l'impostazione predefinita. Il tempo massimo consentito per inviare una risposta. Viene reimpostata quando viene letta l'intestazione di una nuova 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 il successivo quando vengono abilitate le connessioni inattive. Se idle_timeout è pari a zero, è utilizzato il valore read_timeout. Se entrambi sono pari a zero, viene utilizzato il valore read_header_timeout.
route : 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 pianificatore o un orchestratore dei container.
  • Il controllo di integrità viene ricevuto da un bilanciatore del carico tradizionale.
route : meta : unready_status Il codice di stato restituito dal mittente quando non è pronto ad accettare per via del traffico.
routes : meta : available_status Il codice di stato restituito dall'inoltro quando viene ricevuto un controllo di attività e chi invia sia disponibile. Gli scheduler o gli orchestratori dei container spesso inviano e controlli di attività.