Forwarder Chronicle per Linux

Questo documento descrive come installare e configurare il forwarding su Linux. Per installare il forwarding su Windows, vedi forwarder di Windows.

Il forwarding 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 i dati oppure il tipo di log non prevede l'importazione nativa tramite API di terze parti. Il forwarding può essere utilizzato come soluzione pronta per il deployment, invece di incorporare manualmente l'API di importazione.

Puoi installare il forwarding su varie 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 alcuni consigli generali. Per suggerimenti specifici per il tuo sistema, contatta l'assistenza di Chronicle.

  • RAM: 1 GB per ogni tipo di dati raccolti (raccoglitore) che Chronicle accetta per l'importazione. Ad esempio, se hai specificato quattro diversi raccoglitori, sono necessari 4 GB di RAM per raccogliere i dati per tutti e quattro i raccoglitori.

  • 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 di 4-6 CPU.

  • Disco: sono sufficienti 100 MB di spazio su disco, indipendentemente dalla quantità di dati gestita dal forwarding di Chronicle. Se devi eseguire il buffer dei messaggi in backlog su disco anziché sulla memoria, consulta buffering del disco. Il forwarding Chronicle esegue il buffer in memoria per impostazione predefinita.

Intervalli di indirizzi IP di Google

Potrebbe essere necessario che l'intervallo di indirizzi IP venga aperto quando configuri una configurazione del forwarding, ad esempio quando imposti la configurazione per il firewall. Google non può fornire un elenco specifico di indirizzi IP. Tuttavia, puoi ottenere intervalli di indirizzi IP di Google.

Verifica la configurazione del firewall

Eventuali firewall o proxy autenticati tra il container di forwarding Chronicle e internet richiedono regole per aprire l'accesso ai seguenti host:

Tipo di connessione Destinazione Port (Porta)
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Personalizzare i file di configurazione

Google Cloud personalizza i file di configurazione per l'istanza dell'inoltro con metadati specifici, come mostrato nella sezione di output. Puoi scaricare il 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, consulta l'articolo Riferimento alle impostazioni di configurazione.

Configura il forwarding di Linux

Per configurare il forwarding Linux tramite l'interfaccia utente, vedi Gestire le configurazioni del forwarding tramite l'interfaccia utente di Chronicle.

Per configurare manualmente il forwarding Linux, segui questi passaggi:

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

  2. Scarica il file di configurazione tramite l'interfaccia utente.

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

  4. Modifica i file in modo da includere la configurazione per l'istanza dell'inoltro. Utilizza gli esempi forniti in questo documento come riferimento.

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

Qualsiasi modifica apportata al file di configurazione verrà applicata automaticamente dall'utente che ha eseguito l'inoltro entro 5 minuti.

Esempio di configurazione

Il seguente esempio di codice mostra il formato dei file di configurazione per un forwarding. Per maggiori dettagli sulle impostazioni per ciascun tipo di meccanismo di importazione, ad esempio Splunk o Syslog, consulta 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

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 che esegue il forwarding.

Configurazione di esempio (singolo 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

Se utilizzi l'unico file di configurazione e vuoi passare al file system doppio, procedi nel seguente modo:

  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 file FORWARDER_NAME_auth.conf ed elimina dal file tutti i dati non di autorizzazione. Utilizza i file di configurazione di esempio riportati in questa guida come riferimento.
  4. Assicurati di seguire la convenzione di denominazione e le altre linee guida indicate nella sezione Personalizzazione dei file di configurazione.

Installa Docker

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

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

Per verificare se Docker è installato correttamente sul tuo sistema, esegui il comando seguente (privilegi elevati):

   docker ps

La risposta seguente indica che Docker è stato installato correttamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Comandi Docker utili

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

    docker info

  • Il servizio Docker potrebbe essere disabilitato per impostazione predefinita. Per controllare se è disabilitato, esegui questo comando:

    systemctl is-enabled docker

  • Per abilitare il servizio Docker e avviarlo immediatamente, esegui uno dei seguenti comandi:

    sudo systemctl enable --now docker

    sudo systemctl enable /usr/lib/systemd/system/docker.service

    Output:

    Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service

  • Quando avvii un forwarding, esegui questo comando per impostarlo sul riavvio automatico:

    sudo docker run --restart=always `IMAGE_NAME`

    IMAGE_NAME è il nome dell'immagine dell'inoltro.

  • Per controllare lo stato e i dettagli del servizio Docker, esegui questo comando:

    sudo systemctl status docker

    Output:

    ● docker.service - Docker Application Container Engine
    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
    Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago
TriggeredBy: ● docker.socket
      Docs: https://docs.docker.com
  Main PID: 263 (dockerd)
      Tasks: 20
    Memory: 100.4M
    CGroup: /system.slice/docker.service
            └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock"
Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine

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

Installare il forwarding su Linux

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

Passaggio 1: Scaricare, trasferire e installare i file di configurazione dell'inoltro

Chronicle fornisce file di configurazione del forwarding specifici per il tuo sistema operativo (Linux o Windows). Puoi scaricare il file di configurazione in base alle tue esigenze. Dopo aver completato i seguenti passaggi, trasferisci i file di configurazione dal tuo laptop alla directory /opt/chronicle/config dell'inoltro all'interno della home directory dell'utente.

  1. Connettiti all'host del forwarding Linux tramite terminale.

  2. Crea un nuovo utente sull'host del forwarding Linux. 

      adduser USERNAME
  passwd USERNAME
  usermod -aG wheel USERNAME

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

  4. Crea una directory per archiviare i file di configurazione del forwarding di Chronicle: 

      mkdir /opt/chronicle/config

  5. Cambia directory. 

      cd /opt/chronicle/config

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

      ls -l

Passaggio 2: Esegui il forwarding all'interno del container Docker

Puoi utilizzare le seguenti procedure per avviare il forwarding di Chronicle per la prima volta e per eseguire l'upgrade alla versione più recente del container Chronicle:

Le opzioni --log-opt sono disponibili a partire da Docker 1.13. Queste opzioni limitano le dimensioni dei file di log dei container e devono essere utilizzate finché la tua versione di Docker li supporta.

  1. Se stai eseguendo l'upgrade, inizia a ripulire le esecuzioni Docker precedenti. Nell'esempio seguente, il nome del container Docker è cfps. Ottieni l'immagine Docker più recente 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 il forwarding 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

Visualizza i log del forwarding

Per visualizzare i log del forwarding di Chronicle, esegui questo comando:

  sudo docker logs cfps

Per visualizzare il percorso del file in cui sono archiviati i log, esegui questo comando:

docker inspect --format='{{.LogPath}}' CONTAINER_NAME

Per visualizzare i log in esecuzione in tempo reale, esegui questo comando:

  sudo docker logs cfps -f

Per archiviare i log in un file, esegui questo comando:

  sudo docker logs cfps &> logs.txt

Disinstallare l'inoltro

I comandi Docker riportati di seguito ti aiutano a interrompere e disinstallare o rimuovere il forwarding di Chronicle.

Per arrestare o disinstallare il container del forwarding:

    docker stop cfps

Per rimuovere il container dell'inoltro:

    docker rm cfps

Aggiorna il gestore dell'inoltro

Lo strumento di inoltro di Chronicle è composto da due parti e viene aggiornato come segue:

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

  • Immagine Docker del forwarding: viene aggiornata manualmente dopo aver arrestato il forwarding esistente e avviato una nuova istanza, come indicato nel Passaggio 2.

Installa il mittente dietro un proxy

Questa sezione descrive come installare il forwarding di Chronicle tramite un proxy.

  1. Configura il tuo computer per l'utilizzo del proxy.

    1. Aggiungi le seguenti righe al tuo file /etc/resolv.conf:

      nameserver = 10.0.0.1
nameserver = 10.0.0.2

    2. Imposta le seguenti variabili di ambiente:

      $HTTP_PROXY = http://proxy.example.com:80
$HTTPS_PROXY = https://proxy.example.com:80

  2. Configura Docker per l'utilizzo del proxy.

    1. Creare una directory drop-in basata sul sistema per il servizio Docker.

      mkdir /etc/systemd/system/docker.service.d

    2. Crea un file /etc/systemd/system/docker.service.d/http-proxy.conf in cui vengano aggiunte le variabili di ambiente HTTP_PROXY e HTTPS_PROXY.

      [Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
Environment="HTTPS_PROXY=https://proxy.example.com:80/"

    3. Annulla le modifiche.

      $ sudo systemctl daemon-reload

    4. Verifica che la configurazione sia stata caricata.

      $ sudo systemctl show --property Environment docker
Environment=HTTP_PROXY=http://proxy.example.com:80/
Environment=HTTPS_PROXY=https://proxy.example.com:80/

    5. Riavvia Docker.

      $ sudo systemctl restart docker

  3. Ottieni l'immagine Docker del gestore di inoltro Chronicle più recente da Google Cloud.

    docker pull gcr.io/chronicle-container/cf_production_stable

  4. Esegui il container di forwarding Chronicle aggiungendo le variabili di ambiente del proxy.

    docker run \
--env HTTP_PROXY="http://proxy.example.com:80/" \
--env HTTPS_PROXY="https://proxy.example.com:80/" \
--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

Raccogli i dati

Le sezioni seguenti ti aiutano a configurare il forwarding di Chronicle per importare diversi tipi di dati, che vengono inoltrati all'istanza di Chronicle.

Raccogli dati Splunk

Puoi configurare il forwarding di Chronicle in modo che inoltri i dati di Splunk a Chronicle. Google Cloud configura il forwarding di Chronicle con le seguenti informazioni per inoltrare i tuoi 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 le credenziali del tuo account Splunk disponibili al gestore di Chronicle. Puoi farlo creando 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 il forwarding di Chronicle 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). 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

Il forwarding di 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 relativi dati al forwarding Chronicle. Puoi controllare i dati esatti che l'appliance o il server invia al server di inoltro di Chronicle. Lo spedizioniere 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, la porta 10514). Per impostazione predefinita, il forwarding di Chronicle accetta sia 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 la sintassi corretta. I seguenti esempi illustrano la configurazione di 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 al forwarding di Chronicle. Nel file di configurazione del forwarding di Chronicle (FORWARDER_NAME.conf), specifica il percorso del tuo certificato generato e della chiave del certificato come mostrato nell'esempio seguente:

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

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

  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 punti importanti da notare:

  • Puoi configurare 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 la connessione è inattiva per un periodo di tempo specificato.

  • La versione TLS minima viene verificata in base alla 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 nella directory di configurazione e archiviare i file dei certificati.

Raccogli i dati dei file

Un raccoglitore di file è progettato per recuperare i log da un file. Il file deve essere associato al container Docker.

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 il forwarding di 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/falconhostclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

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

In base a questo esempio, devi modificare la configurazione del forwarding di Chronicle (file FORWARDER_NAME.conf) come segue. Il file sample.txt dovrebbe essere presente nella cartella /var/log/crowdstrike/falconhostclient.

 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:

Configurazioni di 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 come input. Se questo criterio viene impostato su true, tutte le righe di log precedenti vengono inviate di nuovo durante i riavvii dell'inoltro. Questo causa la duplicazione dei log. L'impostazione di questo flag su true è utile in determinate situazioni (ad esempio, durante un'interruzione), perché il riavvio del forwarding comporta di nuovo l'invio delle righe di log mancanti.

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

Raccogli i dati del pacchetto

Il forwarding Chronicle può acquisire i pacchetti direttamente da un'interfaccia di rete, utilizzando libcap su Linux. Per maggiori informazioni su libcap, consulta la pagina di manuale su libcap - Linux.

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 di Chronicle.

Google Cloud configura il forwarding di Chronicle con l'espressione BPF (Berkeley PacketFilter) utilizzata durante l'acquisizione dei pacchetti (ad esempio la porta 53 e non il localhost). Per saperne di più, consulta la sezione Filtri dei pacchetti Berkeley.

Raccogli dati da un argomento Kafka

Puoi importare i dati dagli argomenti Kafka proprio come fai in syslog. I gruppi consumer vengono utilizzati per consentirti di eseguire il deployment di un massimo di tre server di inoltro e di estrarre dati dallo stesso argomento Kafka. Per ulteriori 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 del forwarding mostra come impostare il forwarding 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:

Raccogli dati WebProxy

Il forwarding Chronicle può acquisire i dati WebProxy direttamente da un'interfaccia di rete utilizzando libcap su Linux. Per maggiori informazioni su libcap, consulta la pagina del manuale su libcap - Linux. Per attivare l'acquisizione dei dati WebProxy per il tuo sistema, contatta l'assistenza di Chronicle.

Modifica la configurazione del forwarding di Chronicle (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

Personalizza configurazioni

La seguente tabella elenca i parametri importanti utilizzati nel file di configurazione dell'inoltro.

Parametro Descrizione
data_type Il tipo di dati di log che il raccoglitore può raccogliere ed elaborare.
metadati I metadati, che sostituiscono i 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. 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 anziché il buffer di memoria. Il valore predefinito è false.
batch_n_bytes Numero massimo di byte che possono essere accumulati dal raccoglitore dopo i quali i dati vengono raggruppati. Il valore predefinito è 1048576, ovvero 1 MB.
batch_n_seconds Il numero di secondi dopo i quali vengono raggruppati i dati raccolti dal raccoglitore. 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, consulta Campi di configurazione del forwarding e Campi di configurazione del raccoglitore.

Attiva/disattiva compressione dei dati

La compressione dei log riduce il consumo di larghezza di banda di rete durante il trasferimento dei log su 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à di cicli della CPU sull'host che esegue il forwarding e la necessità di ridurre il consumo di larghezza di banda di rete.

Ad esempio, i log basati su testo si comprimono bene e possono fornire un sostanziale risparmio di larghezza di banda con un utilizzo ridotto della CPU. Tuttavia, i payload crittografati dei pacchetti non elaborati non si comprimono bene e comportano un maggiore utilizzo della CPU.

Per impostazione predefinita, la compressione dei log è disattivata. L'abilitazione della compressione dei log potrebbe ridurre il consumo di larghezza di banda. Tuttavia, l'abilitazione della compressione dei log potrebbe 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 del forwarding 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é in memoria. I messaggi in backlog possono essere archiviati in caso di arresto anomalo dell'inoltro o dell'host sottostante. Tieni presente che l'abilitazione del buffering del disco può influire sulle prestazioni.

Se il buffering del disco è disattivato, il forwarding 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 è 4 GB.

Puoi configurare il buffering automatico della memoria in modo da utilizzare un buffer condiviso dinamicamente tra i collettori, in modo da gestire meglio i picchi di traffico. Per abilitare il buffer condiviso dinamicamente, aggiungi quanto segue nella configurazione del forwarding:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

Se esegui il forwarding utilizzando Docker, Google consiglia di montare un volume separato dal volume di configurazione ai fini dell'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 espressioni regolari

I filtri tramite espressioni regolari consentono di filtrare i log in base a corrispondenze di espressioni regolari con log non elaborati.

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

I filtri devono includere un'espressione regolare e, facoltativamente, definire un comportamento in caso di corrispondenza. Il comportamento predefinito di una corrispondenza è il blocco (puoi anche configurarlo esplicitamente come blocco).

In alternativa, puoi specificare i filtri con il comportamento allow. Se specifichi dei filtri allow, il forwarding blocca tutti i log che non corrispondono ad almeno un filtro allow.

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

Quando vengono definiti i filtri, è necessario assegnare loro un nome. I nomi dei filtri attivi verranno segnalati a Chronicle tramite le metriche di integrità del forwarding. I filtri definiti all'origine 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 vengono definiti filtri a livello di directory principale o di raccoglitore, il comportamento consente di consentire tutti.

Configurazione di esempio: filtri delle espressioni regolari

Nella seguente configurazione del forwarding, 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, qualsiasi log NIX_SYSTEM contenente "foo" o "bar" viene bloccato, nonostante allow_filter. Questo perché i filtri utilizzano un operatore logico OR. 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 utilizzando coppie chiave-valore. Le etichette possono essere configurate per un intero forwarding o all'interno di un raccoglitore specifico di un mittente. Se vengono fornite entrambe, le etichette vengono unite alle chiavi del raccoglitore, che hanno la precedenza su quelle dell'autore dell'inoltro in caso di sovrapposizione delle chiavi.

Configurazione di esempio: etichette arbitrarie

Nella seguente configurazione del forwarding, le coppie chiave e valore "foo=bar" e "meow=mix" sono entrambe collegate ai log WINEVTLOG, mentre le coppie chiave e 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 annullare i conflitti di indirizzi IP sovrapposti. Puoi configurare un'etichetta dello spazio dei nomi per un intero forwarding o all'interno di un raccoglitore specifico del forwarding. Se sono inclusi entrambi, lo spazio dei nomi del raccoglitore specifico ha la precedenza.

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

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 del forwarding, i log WINEVTLOG sono collegati allo spazio dei nomi FORWARDER, mentre 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

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

È possibile eseguire il deployment del forwarding di Chronicle per Linux in un ambiente in cui è installato un bilanciatore del carico di livello 4 tra l'origine dati e le istanze del forwarding. Ciò consente a un cliente di distribuire la raccolta dei log a più mittenti o di inviare i log a un altro forwarding in caso di errore. Questa funzionalità è supportata solo con il tipo di raccolta syslog.

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

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

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

  • http://<host:port>/meta/available: controlli di attività per programmi di pianificazione dei container o orchestratori.
  • http://<host:port>/meta/ready: controlli di idoneità e controlli di integrità tradizionali del bilanciatore del carico.

La seguente configurazione del forwarding è un esempio di bilanciamento del carico e disponibilità elevata:

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: Il periodo di tempo in cui il forwarding restituisce un controllo di idoneità/integrità non valido e continua ad accettare 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. Ciò concede al bilanciatore del carico il tempo necessario per rimuovere il forwarding dal pool.
Server : scarico_timeout Il tempo durante il quale l'inoltro attende la chiusura automatica delle connessioni attive 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à provenienti dal bilanciatore del carico. Il valore deve essere compreso tra 1024-65535.
server : http : host L'indirizzo IP, o nome host, che può essere risolto in indirizzi IP, che il server deve ascoltare. Se vuoto, il valore predefinito è sistema locale (0.0.0.0).
server : http : read_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. La quantità massima di tempo consentita per leggere l'intera richiesta, sia l'intestazione che il corpo. Puoi impostare sia read_timeout che read_header_timeout.
server : http : read_header_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. La quantità massima di tempo consentita per leggere le intestazioni delle richieste. La lettura della connessione, la scadenza viene reimpostata dopo la lettura dell'intestazione.
server : http : write_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Il tempo massimo consentito per inviare una risposta. Viene reimpostata quando viene letta una nuova intestazione di richiesta.
server : http : inattivo_timeout Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Il tempo massimo di attesa per la richiesta successiva quando sono abilitate le connessioni inattive. Se inattivo_timeout è pari a zero, viene utilizzato il valore di read_timeout. Se entrambi sono zero, viene usato 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 o da un agente di orchestrazione dei container.
  • 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'utente che ha effettuato l'inoltro quando riceve un controllo di attività e quando l'utente che ha effettuato l'inoltro è disponibile. Gli scheduler o gli orchestrator dei container spesso inviano controlli di attività.

Domande frequenti

Come faccio ad aggiornare lo spedizioniere?

Il forwarding Linux viene costantemente aggiornato tramite uno script shell nell'immagine Docker. Per aggiornare l'immagine Docker, esegui il forwarding.

Che cos'è un container Docker?

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

  • Macchine virtuali: hanno sia uno spazio con privilegi (kernel di Linux) sia uno spazio utente (tutto ciò con cui interagisci: libc, python, ls, tcpdump e così via).

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

Perché distribuire il server di inoltro di Chronicle utilizzando un container?

  • Maggiore sicurezza grazie all'isolamento:
    • L'ambiente e i requisiti del cliente non influiscono sul forwarding di Chronicle.
    • L'ambiente e i requisiti del mittente di Chronicle non influiscono sul cliente.
    • Il meccanismo di distribuzione del 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 inizialmente 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 a utilizzare i comandi Docker avanzati?

  • Il forwarding di Chronicle utilizza un singolo container, quindi non è necessario saperne di più su Swarm, orchestrazione o altri concetti o comandi Docker avanzati.