Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Installa e configura l'inoltro su Linux

Questo documento descrive come installare e configurare l'inoltro su Linux. Per installare l'inoltro su Windows, consulta Inoltro Windows.

Lo strumento di inoltro viene utilizzato per inviare i log dall'ambiente del cliente all'istanza Chronicle. Viene utilizzato quando i clienti vogliono inviare i log direttamente a Chronicle e non vogliono utilizzare i bucket cloud per importare dati o il loglog non ha importazione nativa tramite API di terze parti. L'inoltro può essere utilizzato come soluzione pronta per il deployment, invece di incorporare manualmente l'API di importazione.

Puoi installare l'inoltro su una varietà di distribuzioni Linux, tra cui Debian, Ubuntu, Red Hat e Suse. Google Cloud fornisce il software utilizzando un container Docker. Puoi eseguire e gestire il container Docker su una macchina fisica o virtuale che esegue Linux.

Requisiti di sistema

Di seguito sono riportati consigli generali. Per consigli specifici per il tuo sistema, contatta l'assistenza Chronicle.

  • RAM: 1 GB per ogni tipo di dati raccolto. Ad esempio, EDR (Endpoint Detection and Response) è un tipo di dati separato per DNS e DHCP. Sono necessari 3 GB di RAM per raccogliere dati per tutti e tre.

  • CPU: 2 CPU sono sufficienti per gestire meno di 10.000 eventi al secondo (EPS) (totale per tutti i tipi di dati). Se prevedi di inoltrare più di 10.000 EPS, esegui il provisioning da 4 a 6 CPU.

  • Disco: sono sufficienti 100 MB di spazio su disco, indipendentemente dalla quantità di dati gestita dall'inoltro Chronicle. Se devi eseguire il buffer dei messaggi in backlog su disco anziché sulla memoria, vedi Buffering del disco. Per impostazione predefinita, l'inoltro a Chronicle esegue il buffer in memoria.

Verifica la configurazione del firewall

Tutti i firewall o i proxy autenticati tra il container di inoltro di Chronicle e Internet richiedono le regole per aprire l'accesso ai seguenti host:

Tipo di connessione Destinazione Port (Porta)
TCP malachiteingestion-pa.googleapis.com 443
TCP malachiteingestion-europe-backstory.googleapis.com 443
TCP malachiteingestion-asia-southeast1-backstory.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP storage.googleapis.com 443

Personalizzare i file di configurazione

Contatta il tuo rappresentante Chronicle per ricevere i modelli di file di configurazione.

Google Cloud personalizza i file di configurazione in base all'istanza del server di forwarding con metadati specifici, come mostrato nella sezione degli output. Puoi modificare i file di configurazione in base ai tuoi requisiti e includere informazioni sui tipi di log da importare nella sezione raccoglitori. Per saperne di più sulle impostazioni di configurazione, contatta l'assistenza di Chronicle.

Per configurare l'inoltro Linux:

  1. Crea una copia del modello di file di configurazione fornito nel software.

  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 del server di inoltro. Usa gli esempi forniti in questo documento come riferimento.

  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. Questa operazione è necessaria per mappare correttamente i dati.

Esempio di configurazione

Il seguente esempio di codice mostra il formato dei file di configurazione per uno strumento di inoltro. Per informazioni dettagliate sulle impostazioni per ogni tipo di meccanismo di importazione, come Splunk o Syslog, consulta la sezione Raccogli dati.

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
enable_auto_update: false

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"

Questi due file system consentono di archiviare le credenziali di autenticazione in un file separato per una maggiore sicurezza. Puoi archiviare il file FORWARDER_NAME.conf in un repository di controllo della versione o in qualsiasi sistema di gestione della configurazione aperto. Puoi archiviare il file FORWARDER_NAME_auth.conf direttamente nella macchina fisica o virtuale in cui viene eseguito il forwarding.

Configurazione di esempio (file singolo)

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

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

Se utilizzi un unico file di configurazione e vuoi passare ai due file system, segui questi passaggi:

  1. Crea una copia della 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 FORWARDER_NAME_auth.conf ed elimina dal file tutti i dati che non riguardano l'autorizzazione. Utilizza i file di configurazione di esempio forniti in questa guida come riferimento.
  4. Assicurati di seguire la convenzione di denominazione e le altre linee guida menzionate nella sezione Personalizzare i file di configurazione.

Installa Docker

L'installazione di Docker dipende dall'ambiente host. Puoi installare Docker su diversi sistemi operativi host. Google Cloud fornisce documentazione limitata per aiutarti a installare Docker su diverse delle distribuzioni Linux più comuni. Tuttavia, Docker è open source e tutta la documentazione necessaria è già disponibile. Per istruzioni sull'installazione dei docker, consulta la documentazione di Docker.

Una volta installato Docker sul sistema, il processo di installazione dello strumento di forwarding di Chronicle è simile a qualsiasi tipo di distribuzione di Linux.

Per verificare che Docker sia installato correttamente sul tuo sistema, esegui il comando seguente (con privilegi elevati):

   docker ps

La seguente risposta indica che Docker è stato installato correttamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Puoi raccogliere informazioni aggiuntive sull'installazione di Docker utilizzando il seguente comando:

    docker info

In caso di problemi con Docker, il team di assistenza di Chronicle può richiedere l'output di questo comando per risolvere il problema ed eseguire il debug.

Installa l'inoltro su Linux

Questa sezione descrive come installare Chronicle Forwarder utilizzando un container Docker in un sistema Linux.

Passaggio 1: Scarica, trasferisci e installa i file di configurazione dell'inoltro

Google Cloud fornisce file di configurazione di forwarding specifici per il tuo sistema operativo (Linux o Windows). Scarica i file dal link fornito dal tuo rappresentante Chronicle in una directory locale sul tuo laptop (ad esempio, in una directory denominata chronicle). Dopo aver completato i passaggi seguenti, trasferisci i file di configurazione dal tuo laptop alla directory /opt/chronicle/config di inoltro all'interno della directory home dell'utente.

  1. Connettiti all'host dell'inoltro Linux tramite il terminale.

  2. Crea un nuovo utente sull'host dell'inoltro Linux. 

      adduser USERNAME
  passwd USERNAME
  usermod -aG wheel USERNAME

  3. Cambia la directory nella home directory del nuovo utente che esegue il container Docker.

  4. Crea una directory per archiviare i file di configurazione dell'inoltro Chronicle: 

      mkdir /opt/chronicle/config

  5. Cambia directory. 

      cd /opt/chronicle/config

  6. Una volta che i file sono stati trasferiti, assicurati che i file di configurazione si trovino nella directory /opt/chronicle/config: 

      ls -l

Passaggio 2: Eseguire l'inoltro all'interno del container Docker

Puoi utilizzare le seguenti procedure per avviare per la prima volta l'inoltro a Chronicle, nonché per eseguire l'upgrade alla versione più recente del container Chronicle:

Le opzioni --log-opt sono disponibili dal Docker 1.13. Queste opzioni limitano le dimensioni dei file di log del container e devono essere utilizzate purché la tua versione di Docker li supporti.

  1. Se stai eseguendo l'upgrade, inizia rimuovendo le eventuali esecuzioni di Docker precedenti. Nell'esempio seguente, il nome del container Docker è cfps. Recupera l'ultima immagine Docker da Google Cloud con il comando docker pull, come mostrato di seguito.

    docker stop cfps

    docker rm cfps

  2. Ottieni l'immagine Docker più recente da Google Cloud:

    docker pull gcr.io/chronicle-container/cf_production_stable

  3. Avvia lo strumento di inoltro di Chronicle dal container Docker:

    docker run \
--detach \
--name cfps \
--restart=always \
--log-opt max-size=100m \
--log-opt max-file=10 \
--net=host \
-v /opt/chronicle/config:/opt/chronicle/external \
gcr.io/chronicle-container/cf_production_stable

Disinstallare l'inoltro

I seguenti comandi Docker ti consentono di arrestare e disinstallare o rimuovere il server Chronicle.

Per arrestare o disinstallare il container forwarding:

    docker stop cfps

Per rimuovere il contenitore dello strumento di inoltro:

    docker rm cfps

Aggiorna l'inoltro

L'inoltro a Chronicle è composto da due parti e viene eseguito l'upgrade come segue:

  • Cofanetto di forwarding: viene aggiornato automaticamente e non è necessario riavviare.

  • Immagine Docker di forwarding: viene aggiornata manualmente dopo aver interrotto l'inoltro esistente e l'avvio di una nuova istanza, come indicato nel Passaggio 2.

Raccogli dati

Le seguenti sezioni consentono di configurare l'inoltro a Chronicle per importare diversi tipi di dati che vengono inoltrati all'istanza Chronicle.

Raccogli dati Splunk

Puoi configurare l'inoltro a Chronicle per inoltrare i dati di Splunk a Chronicle. Google Cloud configura l'inoltro a Chronicle con le seguenti informazioni per inoltrare i dati da Splunk:

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

  • Splunk query per generare dati per i tipi di dati richiesti (ad esempio index=dns).

Devi rendere disponibili le credenziali del tuo account Splunk all'inoltro del report di Chronicle. Puoi farlo creando un file creds.txt o aggiungendo i campi user e password nella sezione delle impostazioni splunk del file FORWARDER_NAME_auth.conf. Le due procedure seguenti descrivono ogni metodo. Utilizza un solo metodo. Il metodo consigliato è utilizzare il file FORWARDER_NAME_auth.conf.

Per utilizzare il file FORWARDER_NAME_auth.conf, aggiungi i campi user e password alla sezione splunk del file FORWARDER_NAME_auth.conf come mostrato di seguito.

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

collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10
      maximum_window_size: 30
      user: myusername
      password: mypassword
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size: l'intervallo di tempo minimo passato alla query Splunk. Il valore predefinito è 10 secondi. Questo parametro viene utilizzato per l'ottimizzazione se il requisito è modificare la frequenza con cui viene eseguita una query sul server Splunk quando l'inoltro è in stato stabile. Inoltre, quando c'è un ritardo, la chiamata API Splunk può essere effettuata più volte.

max_window_size: l'intervallo di tempo massimo trasmesso alla query Splunk. Il valore predefinito è 30 secondi. Questo parametro viene utilizzato per l'ottimizzazione nei casi in cui sia presente un ritardo o se sono necessari più dati per query.

Modifica questo parametro (uguale a o maggiore di) quando modifichi il parametro minimo. Potrebbero verificarsi casi di ritardo se una chiamata per una query Splunk richiede più tempo di dimensioni massime.

modalità_query: è presente un solo valore valido: realtime. Per informazioni dettagliate sulle ricerche in tempo reale in Splunk, consulta la documentazione di Splunk.

Per utilizzare un file cred.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 i clienti che utilizzano l'inoltro a Chronicle per accedere a un'istanza di Splunk, copia il file creds.txt nella directory di configurazione (la stessa directory in cui si trovano i file di configurazione). Ad esempio:

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

  4. Verifica che il file creds.txt si trovi nella posizione corretta: 

    ls /opt/chronicle/config

Raccogli dati syslog

L'inoltro a Chronicle può funzionare come server Syslog. Puoi configurare qualsiasi appliance o server che supporti l'invio di dati syslog tramite una connessione TCP o UDP per inoltrare i dati al server Chronicle. Puoi controllare i dati esatti che l'appliance o il server invia all'inoltro a Chronicle. L'inoltro di Chronicle può quindi inoltrare i dati a Chronicle.

Il file di configurazione FORWARDER_NAME.conf (fornito da Google Cloud) specifica le porte da monitorare per ogni tipo di dati inoltrati (ad esempio, porta 10514). Per impostazione predefinita, l'inoltro Chronicle accetta sia le connessioni TCP che UDP.

Configura rsyslog

Per configurare rsyslog, devi specificare una destinazione per ogni porta, ad esempio ogni tipo di dati. Consulta la documentazione del sistema per conoscere la sintassi corretta. I seguenti esempi illustrano la configurazione della destinazione rsyslog:

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

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

Abilita TLS per le configurazioni syslog

Puoi abilitare TLS per la connessione SysLog all'inoltro Chronicle. Nel file di configurazione dell'inoltro di Chronicle (FORWARDER_NAME.conf), specifica la posizione della chiave e del certificato generati, come illustrato nell'esempio seguente:

certificato "/opt/chronicle/external/certs/client_generate_cert.pem"
chiave_certificato "/opt/chronicle/external/certs/client_generate_cert.key"

In base all'esempio mostrato, modifica il file di configurazione dell'inoltro Chronicle (FORWARDER_NAME.conf) nel seguente modo:

  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"

Alcuni aspetti importanti da tenere in considerazione:

  • Puoi configurare la dimensione del buffer TCP. La dimensione predefinita del buffer TCP è di 64 kB.

  • Il valore predefinito e consigliato per connection_timeout è di 60 secondi. La connessione TCP viene terminata se rimane inattiva per un determinato periodo di tempo.

  • La versione TLS minima viene confrontata con la versione TLS della richiesta di input. La versione TLS della richiesta di input deve essere superiore alla versione TLS minima. La versione TLS minima deve essere uno dei seguenti valori: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Puoi creare una directory dei certificati sotto la directory di configurazione e archiviarvi i file dei certificati.

Raccogli i dati dei file

Utilizza questa opzione se vuoi caricare manualmente i log da un singolo file di log. Può essere utilizzata per eseguire il backfill dei log per un determinato file di log.

Avvia l'inoltro Chronicle dal container Docker:

  docker run \
    --name cfps \
    --log-opt max-size=100m \
    --log-opt max-file=10 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

Questo comando docker run è fondamentale per mappare il volume di carico al container.

In base a questo esempio, devi modificare la configurazione dell'inoltro Chronicle (FORWARDER_NAME.conf file) nel seguente modo:

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

Raccogli i dati del pacchetto

L'inoltro a Chronicle può acquisire pacchetti direttamente da un'interfaccia di rete utilizzando libcap su Linux. Per maggiori informazioni su libcap, consulta la pagina del manuale Linux di libcap.

I pacchetti vengono acquisiti e inviati a Chronicle anziché alle voci di log. L'acquisizione dei pacchetti viene gestita solo da un'interfaccia locale. Per abilitare l'acquisizione dei pacchetti per il tuo sistema, contatta l'assistenza Chronicle.

Google Cloud configura l'inoltro a Chronicle con l'espressione Berkeley Packet Filter (BPF) utilizzata durante l'acquisizione dei pacchetti (ad esempio, porta 53 e non localhost). Per ulteriori informazioni, consulta Filtri pacchetto di Berkeley.

Raccogli dati dall'argomento Kafka

Puoi importare i dati dagli argomenti Kafka come fai con syslog. I gruppi di consumatori vengono utilizzati per consentirti di eseguire il deployment di un massimo di tre server di forwarding ed estrarre i dati dallo stesso argomento Kafka. Per maggiori informazioni, consulta Kafka.

Per ulteriori informazioni sui gruppi di consumatori Kafka, consulta quanto segue: https://docs.confluent.io/platform/current/clients/consumer.html

Configurazione di esempio: input Kafka

La seguente configurazione per lo strumento di inoltro mostra come configurare lo strumento di inoltro per importare i dati dagli argomenti Kafka.

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:

Personalizza le configurazioni facoltative

Attiva/disattiva compressione dati

La compressione dei log riduce il consumo della larghezza di banda della rete durante il trasferimento dei log a Chronicle. Tuttavia, la compressione potrebbe causare un aumento dell'utilizzo della CPU. Il compromesso tra l'utilizzo della CPU e la larghezza di banda dipende da molti fattori, tra cui il tipo di dati di log, la comprimibilità di questi dati, la disponibilità dei cicli di CPU sull'host che esegue il forwarding e la necessità di ridurre il consumo della larghezza di banda della rete.

Ad esempio, i log basati su testo si adattano bene e possono fornire notevoli risparmi di larghezza di banda con un utilizzo ridotto della CPU. Tuttavia, i payload criptati dei pacchetti non elaborati non si comprimeno correttamente e comportano un maggiore utilizzo della CPU.

La compressione dei log è disattivata per impostazione predefinita. 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. Fai attenzione ai compromessi.

Per attivare la compressione dei log, imposta il campo compression su true nel file di configurazione dello strumento di inoltro di Chronicle, 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",
...
    }

Configura il buffering del disco

Il buffering del disco consente di eseguire il buffer dei messaggi in backlog su disco anziché sulla memoria. I messaggi in arretrato possono essere archiviati se l'inoltro si arresta in modo anomalo o l'host sottostante si arresta in modo anomalo. Tieni presente che l'abilitazione del buffering del disco può influire sulle prestazioni.

Se il buffer del disco è disabilitato, l'inoltro utilizza 1 GB di memoria (RAM) per ogni tipo di log (ad esempio per connettore). Specifica il parametro di configurazione max_memory_buffer_bytes. La memoria massima consentita è di 4 GB.

Se esegui il forwarding utilizzando Docker, Google consiglia di montare un volume separato dal volume di configurazione a scopo di isolamento. Inoltre, ogni input deve essere isolato con la propria directory o il proprio volume per evitare conflitti.

Configurazione di esempio: buffering del disco

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

Imposta filtri per espressioni regolari

I filtri delle espressioni regolari consentono di filtrare i log in base a corrispondenze di espressioni regolari rispetto ai log non elaborati.

I filtri utilizzano la sintassi RE2 descritta qui: https://github.com/google/re2/wiki/Sintassi

I filtri devono includere un'espressione regolare e, facoltativamente, definire un comportamento quando esiste una corrispondenza. Il comportamento predefinito su una corrispondenza è un blocco (puoi anche configurarlo esplicitamente come blocco).

In alternativa, puoi specificare i filtri con il comportamento allow. Se specifichi qualsiasi 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 a blocchi hanno la precedenza sui filtri allow.

Quando vengono definiti i filtri, devono essere assegnati un nome. I nomi dei filtri attivi verranno segnalati a Chronicle tramite le metriche relative allo stato di Forwarder. I filtri definiti nella radice della configurazione vengono uniti ai filtri definiti a livello di raccoglitore. I filtri a livello di raccoglitore hanno la precedenza in caso di nomi in conflitto. Se non è stato definito alcun filtro a livello di directory principale o di raccoglitore, il comportamento è consentire tutti.

Configurazione di esempio: filtri di espressioni regolari

Nella seguente configurazione dell'inoltro, 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, eventuali log NIX_SYSTEM contenenti "foo" o "bar" vengono bloccati, nonostante allow_filter. Questo avviene perché i filtri utilizzano un OR logico. Tutti i log 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

Configura etichette arbitrarie

Le etichette vengono utilizzate per collegare metadati arbitrari ai log mediante coppie chiave-valore. Le etichette possono essere configurate per un intero inoltro o all'interno di un raccoglitore specifico di un inoltro. Se vengono forniti entrambi, le etichette vengono unite alle chiavi del raccoglitore che hanno la precedenza su quelle dell'inoltro, in caso di sovrapposizione.

Configurazione di esempio: etichette arbitrarie

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

Configura spazi dei nomi

Utilizza le etichette dello spazio dei nomi per identificare i log di segmenti di rete distinti e creare conflitti tra gli indirizzi IP. Puoi configurare un'etichetta dello spazio dei nomi per un inoltro intero o all'interno di un raccoglitore specifico dello strumento di inoltro. Se sono entrambi inclusi, lo spazio dei nomi del raccoglitore specifico ha la precedenza.

Qualsiasi spazio dei nomi configurato per l'inoltro viene visualizzato con gli asset associati nell'interfaccia utente di Chronicle. Puoi anche cercare gli spazi dei nomi utilizzando la funzionalità di ricerca di Chronicle.

Per informazioni su come visualizzare gli spazi dei nomi nell'interfaccia utente di Chronicle, visita questa pagina.

Configurazione di esempio: spazi dei nomi

Nella seguente configurazione dello strumento di forwarding, i log WINEVTLOG vengono associati allo spazio dei nomi FORWARDER e i log NIX_SYSTEM vengono 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

Configura il bilanciamento del carico e le opzioni ad alta disponibilità

È possibile eseguire il deployment dell'inoltro Chronicle per Linux in un ambiente in cui è installato un bilanciatore del carico di livello 4 tra le istanze dell'origine dati e dell'inoltro. Questo consente a un cliente di distribuire la raccolta di log tra più server di forwarding o di inviare i log a un inoltro diverso in caso di esito negativo. Questa funzionalità è supportata solo con il tipo di raccolta syslog.

L'inoltro Linux include un server HTTP integrato che risponde ai controlli di integrità HTTP dal bilanciatore del carico. Il server HTTP contribuisce inoltre a garantire che i log non vadano persi durante l'avvio o l'arresto di un server di inoltro.

Configura le opzioni relative a server HTTP, bilanciamento del carico e alta disponibilità nella sezione server del file di configurazione del server di inoltro. Queste opzioni supportano l'impostazione di durate di timeout e codici di stato restituiti in risposta ai controlli di integrità ricevuti nei deployment di pianificazione e basati sull'orchestrazione dei container, nonché dai bilanciatori del carico tradizionali.

Usa i seguenti percorsi degli URL per i controlli di integrità, recupero e attività. I valori <host:port> sono definiti nella configurazione del server di inoltro.

  • http://<host:port>/meta/available: controlli di attività per pianificatori/orchestratori di container, come Kubernetes.
  • http://<host:port>/meta/ready: controlli di idoneità e tradizionali controlli di integrità del bilanciatore del carico.

La seguente configurazione per l'inoltro è 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 : tolleranza_tempo_in uscita La quantità di tempo in cui l'inoltro restituisce un controllo di integrità o di controllo di integrità non soddisfacente e accetta ancora nuove connessioni. Questo è anche il tempo di attesa tra la ricezione di un segnale per l'arresto e l'avvio effettivo del server. Ciò consente al bilanciatore del carico di rimuovere il pool dal pool.
server : dump_timeout Il periodo di tempo in cui l'inoltratore attende che le connessioni attive vengano chiuse correttamente prima di essere chiuse dal server.
server : http : porta Il numero di porta che 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 che il server deve ascoltare. Se vuoto, il valore predefinito è system local (0.0.0.0).
server : http : read_timeout Utilizzato per ottimizzare il server HTTP. In genere, non occorre modificare l'impostazione predefinita. La quantità di tempo massima consentita per leggere l'intera richiesta, sia l'intestazione che il corpo. Puoi impostare le funzionalità read_timeout e read_header_timeout.
server : http : read_header_timeout Utilizzato per ottimizzare il server HTTP. In genere, non occorre modificare l'impostazione predefinita. La quantità massima di tempo consentita per la lettura delle intestazioni delle richieste. La lettura della scadenza della connessione viene reimpostata dopo aver letto l'intestazione.
server : http : write_timeout Utilizzato per ottimizzare il server HTTP. In genere, non occorre modificare l'impostazione predefinita. Il periodo di tempo massimo consentito per inviare una risposta. ma viene reimpostato quando viene letta una nuova intestazione della richiesta.
server : http : idle_timeout Utilizzato per ottimizzare il server HTTP. In genere, non occorre modificare l'impostazione predefinita. Il tempo massimo di attesa per la richiesta successiva quando sono attive le connessioni inattive. Se idle_timeout è zero, viene utilizzato il valore di read_timeout. Se entrambi sono zero, viene utilizzato il campo read_header_timeout.
route : meta : ready_status Il codice di stato restituito dall'inoltro quando è pronto ad accettare il traffico in una delle seguenti situazioni:
  • Il controllo di idoneità viene ricevuto da uno scheduler di container o da un orchestratore, come Kubernetes.
  • Il controllo di integrità viene ricevuto da un bilanciatore del carico tradizionale.
route : meta : unready_status Il codice di stato restituito dall'inoltro quando non è pronto ad accettare il traffico.
route : meta : available_status Il codice di stato restituito dall'inoltro quando viene ricevuto un controllo di attività e l'inoltro è disponibile. I programmatori/orchestratori di container come Kubernetes spesso inviano controlli di attività.

Domande frequenti

Come posso aggiornare il mio inoltro?

L'inoltro di Windows non viene aggiornato costantemente in quanto viene utilizzato da pochi clienti. Lo strumento di forwarding Linux viene costantemente aggiornato tramite uno script Shell nell'immagine docker, quindi non è necessario fornire eseguibile a questo scopo. Tuttavia, se un cliente apre una richiesta di assistenza per ottenere l'ultimo file eseguibile di Windows per l'inoltro, il team di assistenza fornirà al cliente un file EXE tramite il portale di assistenza.

Che cos'è un container Docker?

  • I container Docker sono come macchine virtuali che offrono ulteriore sicurezza, isolamento e gestione delle risorse.

  • Le macchine virtuali hanno uno spazio privilegiato (kernel Linux) e uno spazio utente (tutti gli elementi con cui interagisci: libc, python, ls, tcpdump e così via).

  • I container hanno solo uno spazio utente (tutti quelli con cui interagisci: libc, python, ls, tcpdump e così via) e si basano sullo spazio con privilegi dell'host.

Perché distribuire lo strumento di inoltro di Chronicle utilizzando un container?

  • Migliore sicurezza grazie all'isolamento:
    • L'ambiente e i requisiti dei clienti non influiscono su Chronicle.
    • L'ambiente e i requisiti per l'inoltro di Chronicle non influiscono sul cliente.
    • Il meccanismo di distribuzione dei container esiste già e può essere privato e separato per Google Cloud e per i clienti.https://cloud.google.com/container-registry/

Perché solo Linux per i container? E Windows?

  • I container sono stati sviluppati per Linux e sono pronti per la produzione.

  • È in corso il supporto di Windows per i container. I container sono disponibili per Windows Server 2016 e Windows 10.

Hai bisogno di imparare i comandi avanzati di Docker?

  • L'inoltro a Chronicle utilizza un singolo container, quindi non è necessario acquisire informazioni su Swarm, orchestrazione, Kubernetes o altri concetti o comandi Docker avanzati.