Benutzer-Werkzeuge

Webseiten-Werkzeuge


tachtler:graylog_archlinux_-_elastic_-_beats_-_filebeats

graylog ArchLinux - Elastic - beats - filebeats

Graylog ist eine vollständig integrierte Open-Source Protokoll-Management-Plattform für die Erfassung, Indizierung und Analyse von strukturierten und unstrukturierten Daten aus nahezu jeder Quelle.

Graylog benötigt nachfolgende externe Komponente zum Empfangen von systend-journald LOG-Einträgen:

Ab hier werden zur Ausführung nachfolgender Befehle root-Rechte benötigt. Um der Benutzer root zu werden, melden Sie sich bitte als root-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root:

$ su -
Password:

Voraussetzungen

Nachfolgende Voraussetzungen müssen vor der Installation von Elastic - beats - filebeat erfüllt sein, damit Elastic - beats - filebeat mit Graylog kommunizieren kann:

  • Lauffähiger Graylog-Server ab der Version 5.x

Vorbereitung

Zur Installation von Elastic - beats - filebeat zur Kommunikation mit Graylog sollte Graylog wie in nachfolgendem internen Link beschrieben installiert sein:

Die Einbindung des AUR-Repositories, kann wie in nachfolgenden internen Link beschrieben

durchgeführt werden.

filebeat TLS-Zertifikat erstellen

Um entsprechenden Inputs des Graylog-Server nicht nur unverschlüsselte, sondern auch via TLS/StartTLS-Verschlüsselung durvch den Elastic - beats - filebeat ansprechen zu können, muss zuerst ein Zertifikat erzeugt werden. Dies kann durch eine offizielle Zertifizierungsstelle durchgeführt werden, was jedoch natürlich mit Kosten verbunden ist, oder es kommt ein sogenanntes Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat zum Einsatz.

Um die Verschlüsselung einsetzen zu können, sind folgende Komponenten erforderlich:

  • eine eigen Certificate Authority (CA), welche Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat esrtellen kann
  • einen CSR (Certificate Request), welcher von einer Certificate Authority (CA) signiert wird
  • einem private key (privaten Schlüssel), welcher zum CRT (Certificate) gehört und zum Einsatz eines CRT (Certificate) benötigt wird
  • das CRT (Certificate) selbst, welcher von der Certificate Authority (CA) ausgestellt wird

Zur Erstellung eines Self-Signed-Certificate und zur Erstellung der oben genannten Komponenten, wird das Paket

  • openssl

benötigt, welches i.d.R. bereits installiert sein sollte.

Abschliessend soll mit nachfolgendem Befehl in das Verzeichnis /etc/ssl gewechselt werden:

# cd /etc/ssl

/etc/ssl/openssl.cnf

Nachfolgende Anpassungen müssen mindestens in der Konfigurationsdatei /etc/ssl/openssl.cnf durchgeführt werden, um SAN (Subject Alternative Names) in das Zertifikat mit aufnehmen zu können:

(Nur relevanter Ausschnitt):

[ v3_req ]
 
# Extensions to add to a certificate request
 
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Tachtler - NEW -
subjectAltName = @alt_names
 
# Tachtler - NEW -
[ alt_names ]
DNS.1 = localhost
DNS.2 = 127.0.0.1
DNS.3 = ::1

* Danke an Stefan Mayr für den Hinweis das Zertifikat mit Subject Alternative Names auszustatten → Hintergrund: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) - Section 6.4.4

Erstellen CA (Certificate Authority)

Zur Erstellung einer eigene Certificate Authority (CA) kann ein Script, welches bei der Installation von openssl mitgeliefert wird und sich im Verzeichnis /etc/ssl/misc/ befindet, genutzt werden. Der Name des Scripts lautet

  • /etc/ssl/misc/CA.pl.

:!: HINWEIS - Um Subject Alternative Names hinzufügen zu können, muss nachfolgende zweite Ergänzung abgeändert werden, das sonst die -extensions v3_req NICHT angezogen wird!

:!: HINWEIS - Die zu erstellende Certificate Authority (CA) hat standardmässig eine Laufzeit von 3 Jahren !!!

Falls eine längere Laufzeit als drei Jahre gewünscht sein soll, kann nachfolgender Parameter im Skript, in nachfolgendem Verzeichnis, mit nachfolgendem Namen

  • /etc/ssl/misc/CA.pl

angepasst werden:

(Nur relevanter Ausschnitt)

...
# Tachtler
# default: my $DAYS = "-days 365";
my $DAYS = "-days 28023"; # 10.04.2023 - 30.12.2099
# Tachtler
# default: my $CADAYS = "-days 1095";   # 3 years
my $CADAYS = "-days 28024"; # 10.04.2023 - 31.12.2099
...
...
...
} elsif ($WHAT eq '-sign' ) {
    $RET = run("$CA -policy policy_anything -out $NEWCERT"
            # Tachtler
            # default: . " -infiles $NEWREQ $EXTRA{ca}");
            . " -extensions v3_req -infiles $NEWREQ $EXTRA{ca}");
    print "Signed certificate is in $NEWCERT\n" if $RET == 0;
... 

:!: WICHTIG - Die Laufzeit der Certificate Authority (CA) muss länger als die Laufzeit des Zertifikates sein !!!

Folgender Aufruf erstellt eine eigene Certificate Authority (CA):

:!: HINWEIS - Nicht benötigte Angaben werden mit Eingabe eines Punktes [.] übersprungen!

# /etc/ssl/misc/CA.pl -newca
# /etc/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)
 
Making CA certificate ...
====
openssl req  -new -keyout /etc/ssl/private/cakey.pem -out /etc/ssl/careq.pem 
Generating a RSA private key
.............................+++++
......+++++
writing new private key to '/etc/ssl/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria (Bayern)
Locality Name (eg, city) []:Munich (Muenchen)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tachtler.net
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:www.tachtler.net
Email Address []:hostmaster@tachtler.net
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:.
==> 0
====
====
openssl ca  -create_serial -out /etc/ssl/cacert.pem -days 28024 -batch -keyfile /etc/ssl/private/cakey.pem -selfsign -extensions v3_ca  -infiles /etc/ssl/careq.pem
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            58:b7:f2:c0:f9:30:8d:48:4f:77:d3:56:3d:9d:a9:98:19:e6:a2:49
        Validity
            Not Before: Apr 10 10:48:57 2023 GMT
            Not After : Dec 31 10:48:57 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            organizationName          = tachtler.net
            commonName                = www.tachtler.net
            emailAddress              = hostmaster@tachtler.net
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                07:39:3F:8F:38:B5:EA:69:3E:FA:BC:C4:AB:7C:30:18:93:26:B8:77
            X509v3 Authority Key Identifier: 
                keyid:07:39:3F:8F:38:B5:EA:69:3E:FA:BC:C4:AB:7C:30:18:93:26:B8:77
 
            X509v3 Basic Constraints: critical
                CA:TRUE
Certificate is to be certified until Dec 31 10:48:57 2099 GMT (28403 days)
 
Write out database with 1 new entries
Data Base Updated
==> 0
====
CA certificate is in /etc/ssl/cacert.pem

Durch ausführen des Skriptes mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -newca ist eine neue Verzeichnisstruktur und neue Dateien unter

  • /etc/ssl

entstanden, deren Inhalt mit nachfolgendem Befehl bequem aufgelistet werden kann:

# ls -l /etc/ssl
total 64
-rw-r--r-- 1 root root  4611 Apr 10 12:48 cacert.pem
-rw-r--r-- 1 root root  1078 Apr 10 12:48 careq.pem
lrwxrwxrwx 1 root root    46 Jun  3  2021 cert.pem -> ../ca-certificates/extracted/tls-ca-bundle.pem
drwxr-xr-x 1 root root 13526 Apr 16 09:30 certs
drwxr-xr-x 1 root root     0 Apr 10 12:47 crl
-rw-r--r-- 1 root root     3 Apr 10 12:47 crlnumber
-rw-r--r-- 1 root root   412 Dec 18 11:31 ct_log_list.cnf
-rw-r--r-- 1 root root   412 Dec 18 11:31 ct_log_list.cnf.dist
-rw-r--r-- 1 root root   166 Apr 10 12:48 index.txt
-rw-r--r-- 1 root root    21 Apr 10 12:48 index.txt.attr
-rw-r--r-- 1 root root     0 Apr 10 12:47 index.txt.old
drwxr-xr-x 1 root root    36 Apr 10 12:47 misc
drwxr-xr-x 1 root root    88 Apr 10 12:48 newcerts
-rw-r--r-- 1 root root 11160 Apr 10 12:46 openssl.cnf
-rw-r--r-- 1 root root 10909 Dec 18 11:31 openssl.cnf.dist
drwxr-xr-x 1 root root    18 Apr 10 12:47 private
-rw-r--r-- 1 root root    41 Apr 10 12:48 serial
# ls -l /etc/ssl/newcerts
total 8
-rw-r--r-- 1 root root 4611 Apr 10 12:48 58B7F2C0F9308D484F77D3563D9DA99819E6A249.pem
# ls -l /etc/ssl/private
total 4
-rw------- 1 root root 1854 Apr 10 12:48 cakey.pem

Erstellen CSR (Certificate Request)

Ebenfalls mit dem Script, welches schon bei der Erstellung einer eigene Certificate Authority (CA) genutzt wurde und sich unter /etc/ssl/misc befindet und den Namen CA trägt, kann nun dieses auch zur Erstellung von

  • einem CSR (Certificate Request)
  • einem private key (privaten Schlüssel)

genutzt werden.

:!: HINWEIS - Das zu erstellende Zertifikat hat standardmässig eine Laufzeit von 1 Jahr !!!

Falls eine längere Laufzeit als ein Jahr gewünscht sein soll, kann nachfolgender Parameter im Skript, in nachfolgendem Verzeichnis, mit nachfolgendem Namen

  • /etc/ssl/openssl.cnf

angepasst werden:

(Nur relevanter Ausschnitt)

...
# Tachtler
# default: default_days = 365           # how long to certify for
default_days    = 28023         # how long to certify for 10.04.2023 - 30.12.2099
...

:!: HINWEIS - Nicht benötigte Angaben werden mit Eingabe eines Punktes [.] übersprungen!

# /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req
# /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req
Use of uninitialized value $1 in concatenation (.) or string at /etc/ssl/misc/CA.pl line 137.
====
openssl req  -new  -keyout newkey.pem -out newreq.pem -days 28023 -extensions=v3_req
Ignoring -days; not generating a certificate
Generating a RSA private key
...+++++
....................................+++++
writing new private key to 'newkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria (Bayern)
Locality Name (eg, city) []:Munich (Muenchen)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tachtler.net
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:filebeat.idmz.tachtler.net
Email Address []:hostmaster@tachtler.net
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: 
An optional company name []:.
==> 0
====
Request is in newreq.pem, private key is in newkey.pem

Durch ausführen des Scripts mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req sind zwei neue Dateien unter

  • /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden können:

# ls -l /etc/ssl/new*.pem
-rw------- 1 root root 1854 Apr 10 14:01 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1086 Apr 10 14:03 /etc/ssl/newreq.pem

:!: WICHTIG - Die so entstandene Datei /etc/ssl/newreq.pem enthält den CSR (Certificate Request).

Signieren CSR (Certificate Request)

Um den in obigen Beispiel entstandenen CSR (Certificate Request) nun mit der Certificate Authority (CA) zu unterschreiben und somit ein signiertes CRT (Certificate) zu erzeugen, kann wieder das Script, welches schon bei der Erstellung der Certificate Authority (CA) genutzt wurde und sich unter /etc/ssl/misc befindet und den Namen CA.pl trägt, mit nachfolgendem Befehl genutzt werden:

:!: WICHTIG - Das Passwort, ist das Passwort, welches im Schritt graylog ArchLinux - Elastic - beats - filebeats - Erstellen CA (Certificate Authority) verwendet wurde!

# /etc/ssl/misc/CA.pl -sign -extra-ca
# /etc/ssl/misc/CA.pl -sign -extra-ca
====
openssl ca  -policy policy_anything -out newcert.pem -extensions=v3_req -infiles newreq.pem
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            58:b7:f2:c0:f9:30:8d:48:4f:77:d3:56:3d:9d:a9:98:19:e6:a2:4a
        Validity
            Not Before: Apr 10 12:04:22 2023 GMT
            Not After : Dec 30 12:04:22 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            localityName              = Munich (Muenchen)
            organizationName          = tachtler.net
            commonName                = filebeat.idmz.tachtler.net
            emailAddress              = hostmaster@tachtler.net
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name: 
                DNS:localhost, DNS:127.0.0.1, DNS:::1
Certificate is to be certified until Dec 30 12:04:22 2099 GMT (28402 days)
Sign the certificate? [y/n]:y
 
 
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
==> 0
====
Signed certificate is in newcert.pem

Durch ausführen des Skriptes mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -sign -extra-ca ist eine weitere neue Dateien unter

  • /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden kann:

# ls -l /etc/ssl/new*.pem
-rw-r--r-- 1 root root 4639 Apr 10 14:04 /etc/ssl/newcert.pem
-rw------- 1 root root 1854 Apr 10 14:01 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1086 Apr 10 14:03 /etc/ssl/newreq.pem

:!: WICHTIG - Die so entstandene Datei /etc/ssl/newcert.pem enthält das neue signierte CRT (Certificate)!

Entfernen des Passwortes vom private key

Ein Problem ist durch die Erstellung der einzelnen Komponenten, wie in den drei vorhergehenden Schritten beschrieben worden noch offen.

:!: WICHTIG - Der private key (privaten Schlüssel) ist mit einer Passphrase gesichert !

Um dieses Problem zu lösen und das Passwort aus dem private key (privaten Schlüssel) zu entfernen, kann folgender Aufruf von openssl genutzt werden:

:!: WICHTIG - Das Passwort, ist das Passwort, welches im Schritt graylog ArchLinux - Elastic - beats - filebeats - Erstellen CA (Certificate Authority) verwendet wurde!

# openssl rsa < /etc/ssl/newkey.pem > /etc/ssl/key.pem
Enter pass phrase: 
writing RSA key

Durch ausführen des oben genannten Befehls ist eine weitere neue Dateien unter

  • /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden kann:

# ls -l /etc/ssl/*key*
-rw-r--r-- 1 root root 1679 Apr 10 13:16 /etc/ssl/key.pem
-rw------- 1 root root 1854 Apr 10 13:12 /etc/ssl/newkey.pem

:!: WICHTIG - Die so entstandene Datei /etc/ssl/key.pem enthält den private key (privaten Schlüssel) OHNE Passphrase!

Installation Zertifikat

Nach dem ein Zertifikat wie hier: graylog ArchLinux - Elastic - beats - filebeats - TLS-Zertifikat erstellen beschrieben erstellt wurde, müssen die benötigen Komponenten noch an die entsprechenden Stellen im Betriebssystem kopiert werden. Dazu sind nachfolgende Befehle notwendig.

Bevor mit der abschliessenden Konfiguration von Elastic - beats - filebeat zur Nutzung von HTTPS begonnen werden kann, sind die in den vorhergehenden Schritten erstellten Dateien:

  • /etc/ssl/key.pem
  • /etc/ssl/newcert.pem
  • /etc/ssl/cacert.pem

noch zu kopieren und ggf. umzubenennen und die Besitz- und Dateirechte der entsprechend Dateien noch anzupassen!

Als erstes werden mit den nachfolgenden Befehlen zwei neue Verzeichnisse im bestehen Verzeichnis /etc/kea angelegt:

# mkdir -p /etc/filebeat-oss/ssl/{certs,private}

Anschliessend werden mit den nachfolgenden Befehlen die entsprechenden Dateien an den jeweiligen Bestimmungsort kopiert und ggf. umbenannt:

# cp -a /etc/ssl/key.pem /etc/filebeat-oss/ssl/private/filebeat.idmz.tachtler.net.key
# cp -a /etc/ssl/newcert.pem /etc/filebeat-oss/ssl/certs/filebeat.idmz.tachtler.net.pem
# cp -a /etc/ssl/cacert.pem /etc/filebeat-oss/ssl/certs/CAcert.pem

Die Besitz- und Dateirechte der soeben kopieren und ggf. umbenannten Dateien

  • /etc/filebeat-oss/ssl/private/filebeat.idmz.tachtler.net.key
  • /etc/filebeat-oss/ssl/certs/filebeat.idmz.tachtler.net.pem
  • /etc/filebeat-oss/ssl/certs/CAcert.pem

können mit folgenden Befehlen die Besitzrechte wie folgt korrigiert werden:

# chown root:root /etc/filebeat-oss/ssl/private/filebeat.idmz.tachtler.net.key
# chown root:root /etc/filebeat-oss/ssl/certs/filebeat.idmz.tachtler.net.pem
# chown root:root /etc/filebeat-oss/ssl/certs/CAcert.pem

und mit folgenden Befehlen die Dateirechte:

# chmod 400 /etc/filebeat-oss/ssl/private/filebeat.idmz.tachtler.net.key
# chmod 444 /etc/filebeat-oss/ssl/certs/filebeat.idmz.tachtler.net.pem
# chmod 444 /etc/filebeat-oss/ssl/certs/CAcert.pem

Durch Ausführen der oben genannten Befehle sieht der Inhalt des Verzeichnisses

  • /etc/kea/ssl

wie folgt aus, welches mit nachfolgendem Befehl aufgelistet werden kann:

# ls -l /etc/kea/ssl/*
/etc/filebeat-oss/ssl/certs:
total 16
-r--r--r-- 1 root root 4611 Apr 10 14:59 CAcert.pem
-r--r--r-- 1 root root 4810 Apr 10 14:59 filebeat.idmz.tachtler.net.pem

/etc/filebeat-oss/sslprivate:
total 4
-r-------- 1 root root 1675 Apr 10 14:59 filebeat.idmz.tachtler.net.key

Installation: filebeat

Nachdem das AUR-Repository von ArchLinux - AUR

erfolgreich eingebunden wurde, kann mit nachfolgendem Befehl, das AUR-Paket - filebeat-oss-bin installiert werden:

# pikaur --noconfirm -S filebeat-oss-bin

Installationsverlauf

Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket filebeat-oss-bin installiert wurden:

# pacman -Qil filebeat-oss-bin

Installierte Dateien

Konfiguration: filebeat

/etc/filebeat-oss/filebeat.yml

Bevor der Dienst/Daemon von Elastic - beats - filebeat gestartet werden kann, ist nachfolgende Konfiguration in der Konfigurationsdatei

  • /etc/filebeat-oss/filebeat.yml

durchzuführen:

(Komplette Konfigurationsdatei):

###################### Filebeat Configuration Example #########################
 
# This file is an example configuration file highlighting only the most common
# options. The filebeat.reference.yml file from the same directory contains all the
# supported options with more comments. You can use it as a reference.
#
# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/filebeat/index.html
 
# For more available modules and options, please see the filebeat.reference.yml sample
# configuration file.
 
# ============================== Filebeat inputs ===============================
 
filebeat.inputs:
# Tachtler - NEW -
- type: journald
  enabled: true
  id: everything
 
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
 
# filestream is an input for collecting log messages from files.
- type: filestream
 
  # Unique ID among all inputs, an ID is required.
  id: my-filestream-id
 
  # Change to true to enable this input configuration.
  enabled: false
 
  # Paths that should be crawled and fetched. Glob based paths.
  paths:
    - /var/log/*.log
    #- c:\programdata\elasticsearch\logs\*
 
  # Exclude lines. A list of regular expressions to match. It drops the lines that are
  # matching any regular expression from the list.
  # Line filtering happens after the parsers pipeline. If you would like to filter lines
  # before parsers, use include_message parser.
  #exclude_lines: ['^DBG']
 
  # Include lines. A list of regular expressions to match. It exports the lines that are
  # matching any regular expression from the list.
  # Line filtering happens after the parsers pipeline. If you would like to filter lines
  # before parsers, use include_message parser.
  #include_lines: ['^ERR', '^WARN']
 
  # Exclude files. A list of regular expressions to match. Filebeat drops the files that
  # are matching any regular expression from the list. By default, no files are dropped.
  #prospector.scanner.exclude_files: ['.gz$']
 
  # Optional additional fields. These fields can be freely picked
  # to add additional information to the crawled log files for filtering
  #fields:
  #  level: debug
  #  review: 1
 
# ============================== Filebeat modules ==============================
 
filebeat.config.modules:
  # Glob pattern for configuration loading
  path: ${path.config}/modules.d/*.yml
 
  # Set to true to enable config reloading
  reload.enabled: false
 
  # Period on which files under path should be checked for changes
  #reload.period: 10s
 
# ======================= Elasticsearch template setting =======================
 
setup.template.settings:
  index.number_of_shards: 1
  #index.codec: best_compression
  #_source.enabled: false
 
 
# ================================== General ===================================
 
# The name of the shipper that publishes the network data. It can be used to group
# all the transactions sent by a single shipper in the web interface.
#name:
 
# The tags of the shipper are included in their own field with each
# transaction published.
#tags: ["service-X", "web-tier"]
 
# Optional fields that you can specify to add additional information to the
# output.
#fields:
#  env: staging
 
# ================================= Dashboards =================================
# These settings control loading the sample dashboards to the Kibana index. Loading
# the dashboards is disabled by default and can be enabled either by setting the
# options here or by using the `setup` command.
#setup.dashboards.enabled: false
 
# The URL from where to download the dashboards archive. By default this URL
# has a value which is computed based on the Beat name and version. For released
# versions, this URL points to the dashboard archive on the artifacts.elastic.co
# website.
#setup.dashboards.url:
 
# =================================== Kibana ===================================
 
# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
# Tachtler - DISABLED -
# default: setup.kibana:
#setup.kibana:
 
  # Kibana Host
  # Scheme and port can be left out and will be set to the default (http and 5601)
  # In case you specify and additional path, the scheme is required: http://localhost:5601/path
  # IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
  #host: "localhost:5601"
 
  # Kibana Space ID
  # ID of the Kibana Space into which the dashboards should be loaded. By default,
  # the Default Space will be used.
  #space.id:
 
# =============================== Elastic Cloud ================================
 
# These settings simplify using Filebeat with the Elastic Cloud (https://cloud.elastic.co/).
 
# The cloud.id setting overwrites the `output.elasticsearch.hosts` and
# `setup.kibana.host` options.
# You can find the `cloud.id` in the Elastic Cloud web UI.
#cloud.id:
 
# The cloud.auth setting overwrites the `output.elasticsearch.username` and
# `output.elasticsearch.password` settings. The format is `<user>:<pass>`.
#cloud.auth:
 
# ================================== Outputs ===================================
 
# Configure what output to use when sending the data collected by the beat.
 
# ---------------------------- Elasticsearch Output ----------------------------
# Tachtler - DISABLED -
# default: output.elasticsearch:
#output.elasticsearch:
  # Array of hosts to connect to.
  # hosts: ["localhost:9200"]
 
  # Protocol - either `http` (default) or `https`.
  #protocol: "https"
 
  # Authentication credentials - either API key or username/password.
  #api_key: "id:api_key"
  #username: "elastic"
  #password: "changeme"
 
# ------------------------------ Logstash Output -------------------------------
# Tachtler - ENABLED -
# default: #output.logstash:
output.logstash:
  # The Logstash hosts
  # default: #hosts: ["localhost:5044"]
  hosts: ["server.idmz.tachtler.net:5044"]
  enabled: true
 
  # Optional SSL. By default is off.
  # List of root certificates for HTTPS server verifications
  # Tachtler
  # default: #ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
  ssl.certificate_authorities: ["/etc/filebeat-oss/ssl/certs/CAcert.pem"]
 
  # Certificate for SSL client authentication
  # Tachtler
  # default: #ssl.certificate: "/etc/pki/client/cert.pem"
  ssl.certificate: "/etc/filebeat-oss/ssl/certs/filebeat-oss.idmz.tachtler.net.pem"
 
  # Client Certificate Key
  # Tachtler
  # default: ssl.key: "/etc/pki/client/cert.key"
  ssl.key: "/etc/filebeat-oss/ssl/private/filebeat-oss.idmz.tachtler.net.key"
 
  # Tachtler - DISABLED, only for testing! -
  #ssl.verification_mode: none
 
# ================================= Processors =================================
processors:
  - add_host_metadata:
      when.not.contains.tags: forwarded
  - add_cloud_metadata: ~
  - add_docker_metadata: ~
  - add_kubernetes_metadata: ~
 
# ================================== Logging ===================================
 
# Sets log level. The default log level is info.
# Available log levels are: error, warning, info, debug
#logging.level: debug
 
# At debug level, you can selectively enable logging only for some components.
# To enable all selectors use ["*"]. Examples of other selectors are "beat",
# "publisher", "service".
#logging.selectors: ["*"]
 
# ============================= X-Pack Monitoring ==============================
# Filebeat can export internal metrics to a central Elasticsearch monitoring
# cluster.  This requires xpack monitoring to be enabled in Elasticsearch.  The
# reporting is disabled by default.
 
# Set to true to enable the monitoring reporter.
#monitoring.enabled: false
 
# Sets the UUID of the Elasticsearch cluster under which monitoring data for this
# Filebeat instance will appear in the Stack Monitoring UI. If output.elasticsearch
# is enabled, the UUID is derived from the Elasticsearch cluster referenced by output.elasticsearch.
#monitoring.cluster_uuid:
 
# Uncomment to send the metrics to Elasticsearch. Most settings from the
# Elasticsearch output are accepted here as well.
# Note that the settings should point to your Elasticsearch *monitoring* cluster.
# Any setting that is not set is automatically inherited from the Elasticsearch
# output configuration, so if you have the Elasticsearch output configured such
# that it is pointing to your Elasticsearch monitoring cluster, you can simply
# uncomment the following line.
#monitoring.elasticsearch:
 
# ============================== Instrumentation ===============================
 
# Instrumentation support for the filebeat.
#instrumentation:
    # Set to true to enable instrumentation of filebeat.
    #enabled: false
 
    # Environment in which filebeat is running on (eg: staging, production, etc.)
    #environment: ""
 
    # APM Server hosts to report instrumentation results to.
    #hosts:
    #  - http://localhost:8200
 
    # API Key for the APM Server(s).
    # If api_key is set then secret_token will be ignored.
    #api_key:
 
    # Secret token for the APM Server(s).
    #secret_token:
 
 
# ================================= Migration ==================================
 
# This allows to enable 6.7 migration aliases
#migration.6_to_7.enabled: true

Nachfolgende Änderungen wurden durchgeführt:

  • # ============================== Filebeat inputs ===============================
     
    filebeat.inputs:
    # Tachtler - NEW -
    - type: journald
      enabled: true
      id: everything

Mit den vorhergeheden Konfigurationszeilen wird ein weiterer Typ - type: journald als Eingabe-Quelle zum Elastic - beats - filebeat hinzugefügt und aktiviert - enabled: true. Die Angabe einer id ist optional wird hier mit einem allgemeinen Wert gesetzt.

  • # =================================== Kibana ===================================
     
    # Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
    # This requires a Kibana endpoint configuration.
    # Tachtler - DISABLED -
    # default: setup.kibana:
    #setup.kibana:

Da in dieser Konfiguration kein Elatsic - Kibana benötigt wird, kann dies durch auskommentiren der gesmaten Sektion, deaktiviert werden.

  • # ---------------------------- Elasticsearch Output ----------------------------
    # Tachtler - DISABLED -
    # default: output.elasticsearch:
    #output.elasticsearch:

Da in dieser Konfiguration kein Elasticsearch - Output benötigt wird, kann dies durch auskommentiren der gesmaten Sektion, deaktiviert werden.

  • # ------------------------------ Logstash Output -------------------------------
    # Tachtler - ENABLED -
    # default: #output.logstash:
    output.logstash:
      # The Logstash hosts
      # default: #hosts: ["localhost:5044"]
      hosts: ["server.idmz.tachtler.net:5044"]
      enabled: true

Da die Ausgabe im Elatsic - Logstach-Format benötigt wird, um die systemd-journald LOG-Daten nach Graylog zu transportieren, wird diese Sektion einkommentiert.

Zusätzliche Angaben wie der Paramerer hosts: [„server.idmz.tachtler.net:5044“] mit Angabe der URL des Graylog-Servers und des Ports auf dem der Graylog-Server bzw. der entsprechende Listener lauscht, ist hier ebenfalls erforderlich. Abschließend muss noch die Angabe enabled: true gesetzt werden, um die Ausgabe zu aktivieren.

  •   # Optional SSL. By default is off.
      # List of root certificates for HTTPS server verifications
      # Tachtler
      # default: #ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
      ssl.certificate_authorities: ["/etc/filebeat-oss/ssl/certs/CAcert.pem"]

Hier kann eine ROOT-Zertifikatsdatei oder eine Datei mit mehreren ROOT-Zertifikaten z.B. auch /etc/ssl/cert.pem angegeben werden, in dem, wie schon erwähnt, sich das ROOT-Zertifikat oder die ROOT-Zertifikate befinden, mit Hilfe das Zertifikat für den Elastic - beats - filebeat ausgestellt wurde - hier ein ROOT-Zertifikate - ssl.certificate_authorities: [„/etc/filebeat-oss/server/ssl/certs/CAcert.pem“].

  •   # Certificate for SSL client authentication
      # Tachtler
      # default: #ssl.certificate: "/etc/pki/client/cert.pem"
      ssl.certificate: "/etc/filebeat-oss/ssl/certs/filebeat-oss.idmz.tachtler.net.pem"

Hier kann die Zertifikatsdatei - ssl.certificate: „/etc/filebeat-oss/server/ssl/certs/filebeat-oss.idmz.tachtler.net.pem“ angegeben werden, mit dem sich der Elastic - beats - filebeat beim Graylog-Server authentifizieren kann.

  •   # Client Certificate Key
      # Tachtler
      # default: ssl.key: "/etc/pki/client/cert.key"
      ssl.key: "/etc/filebeat-oss/ssl/private/filebeat-oss.idmz.tachtler.net.key"

Hier kann die Schlüsseldatei - ssl.key: „/etc/filebeat-oss/server/ssl/private/filebeat-oss.idmz.tachtler.net.key“ - zur Zertifikatsdatei angegeben werden, mit dem sich der Elastic - beats - filebeat beim Graylog-Server authentifizieren kann.

  •   # Tachtler - DISABLED, only for testing! -
      #ssl.verification_mode: none

Hier kann, zu Test-Zwecken die Überprüfung des Zertifikats des Elastic - beats - filebeat deaktiviert werden, falls z.B. ein Self-Signet-Zertifikat zum Einsatz kommt, dessen ROOT-Zertifikat sich nicht im allgemeinen Zertifikatsspeicher befindet, oder bei dem das ROOT-Zertifikat nicht zur Vefügung steht.

filebeat: Dienst/Deamon-Start einrichten

Um Elastic - beats - filebeat, welches als Dienst/Deamon als Hintergrundprozess läuft, auch nach einem Neustart des Servers zur Verfügung zu haben, soll der Dienst/Daemon mit dem Server mit gestartet werden, was mit nachfolgendem Befehl realisiert werden kann:

# systemctl enable filebeat-oss.service
Created symlink /etc/systemd/system/multi-user.target.wants/filebeat-oss.service → /usr/lib/systemd/system/filebeat-oss.service.

Eine Überprüfung, ob beim Neustart des Server der filebeat-oss-Dienst/Deamon wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben:

# systemctl list-unit-files --type=service | grep -e filebeat-oss.service
filebeat-oss.service                       enabled         disabled

bzw.

# systemctl is-enabled filebeat-oss.service
enabled

filebeat: Erster Start

Danach kann der filebeat-oss.service-Server mit nachfolgendem Befehle gestartet werden:

# systemctl start filebeat-oss.service

Mit nachfolgendem Befehl kann der Status des Elastic - beats - filebeat-Daemon/Dienst abgefragt werden:

# systemctl status filebeat-oss.service
● filebeat-oss.service - Filebeat OSS sends log files to Logstash or directly t>
     Loaded: loaded (/usr/lib/systemd/system/filebeat-oss.service; enabled; pre>
     Active: active (running) since Sat 2023-05-13 16:12:27 CEST; 3s ago
       Docs: https://www.elastic.co/guide/en/beats/filebeat/7.12/index.html
   Main PID: 2580 (filebeat-oss)
      Tasks: 6 (limit: 4656)
     Memory: 37.1M
        CPU: 150ms
     CGroup: /system.slice/filebeat-oss.service
             └─2580 /usr/bin/filebeat-oss -e -c /etc/filebeat-oss/filebeat.yml >

May 13 16:12:27 server systemd[1]: Started Filebeat OSS sends log files to Logs>
May 13 16:12:28 server filebeat-oss[2580]: {"log.level":"info","@timestamp":"20>
May 13 16:12:28 server filebeat-oss[2580]: {"log.level":"info","@timestamp":"20>
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
tachtler/graylog_archlinux_-_elastic_-_beats_-_filebeats.txt · Zuletzt geändert: 2023/07/31 13:42 von klaus