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.
Intervalli di indirizzi IP di Google
Potrebbe essere necessario aprire l'intervallo di indirizzi IP durante la configurazione di un server di inoltro, ad esempio per la configurazione del firewall. Google non può fornire un elenco specifico di indirizzi IP. Tuttavia, puoi ottenere gli intervalli di indirizzi IP di Google.
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 | europe-malachiteingestion-pa.googleapis.com | 443 |
TCP | europe-west2-malachiteingestion-pa.googleapis.com | 443 |
TCP | asia-southeast1-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
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:
Crea una copia del modello di file di configurazione fornito nel software.
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.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.
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:
- Crea una copia della configurazione esistente.
- Salva un file come file
FORWARDER_NAME
.conf ed elimina le credenziali di autorizzazione dal file. - 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. - 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
Chronicle fornisce file di configurazione di inoltro 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
dell'inoltro all'interno della home directory dell'utente.
Connettiti all'host dell'inoltro Linux tramite il terminale.
Crea un nuovo utente sull'host dell'inoltro Linux.
adduser
USERNAME
passwdUSERNAME
usermod -aG wheelUSERNAME
Cambia la directory nella home directory del nuovo utente che esegue il container Docker.
Crea una directory per archiviare i file di configurazione dell'inoltro Chronicle:
mkdir /opt/chronicle/config
Cambia directory.
cd /opt/chronicle/config
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.
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 comandodocker pull
, come mostrato di seguito.docker stop cfps
docker rm cfps
Ottieni l'immagine Docker più recente da Google Cloud:
docker pull gcr.io/chronicle-container/cf_production_stable
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).
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 all'inoltro di Chronicle. Creando un file
creds.txt
puoi farlo.
Per utilizzare un file creds.txt
:
Crea un file locale per le tue credenziali Splunk e assegnagli il nome
creds.txt
.Inserisci il tuo nome utente nella prima riga e la password nella seconda riga:
cat creds.txt myusername mypassword
Per utilizzare 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
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:
|
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.