Logdatenanalyse mit graylog unter CentOS 7.x
Für die Überwachung unserer Systeme, genauer gesagt den Loginformationen, greifen wir auf das Projekt graylog zurück. Mit graylog haben wir ein sehr mächtiges Werkzeug in Händen, welches uns die Erfassung, Indizierung und Analyse von Logdateninformationen aus fast all unseren Systemen und Geräten zur Verfügung.
Vorbereitungen
Für den produktiven Einsatz von graylog müssen wir noch ein paar Vorbereitungen treffen; nähere Hinweise dazu findet man in der Architektur-Dokumentation von graylog. Im folgendem Installations- und Konfigurationsbeispiel orientieren wir uns am Minimum setup.
Bevor wir nun mit der Installation von graylog beginnen, müssen wir noch nachfolgende Voraussetzungen schaffen.
JAVA/OpenJDK Runtime Environment
Hier installieren wir die benötige Java Umgebung (min. 1.7) aus dem CentOS Base Repository.
MongoDB
graylog nutzt als Datenbank-Server die NoSQL-Datenbank MongoDB. Diese beziehen wir aus dem EPEL Repository, welches wir, falls noch nicht geschehen, in unser System wie hier beschrieben einbinden.
Elastcsearch
graylog nutzt als Suchmaschine/-server das Projekt Elasticsearch. Das benötigte aktuelle RPM beziehen wir direkt von elastic, die hierzu ein eigenes Repository anbieten.
ACHTUNG: Graylog 1.x doesn't support Elasticsearch 2.x! ⇒ https://github.com/Graylog2/graylog2-server/issues/1531#issuecomment-153648361
Zur Installation des Repositories selbst wir uns kein RPM angeboten. Daher werden wir kurzer Hand die benötigte Konfigurationsdatei für das Repository elasticsearch selbst anlegen.
# vim /etc/yum.repos.d/elasticsearch.repo
- /etc/yum.repos.d/elasticsearch.repo
# Django : 2015-12-21 - Repository elasticsearch 2.x ist nicht mit graylog 1.x kompatibel! [elasticsearch-2.x] name=Elasticsearch repository for 2.x packages baseurl=http://packages.elastic.co/elasticsearch/2.x/centos gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-elasticsearch priority = 20 enabled=0 # Django : 2015-12-28 - Repository elasticsearch für graylog-Installation [elasticsearch-1.7] name=Elasticsearch repository for 1.7.x packages baseurl=http://packages.elastic.co/elasticsearch/1.7/centos gpgcheck=1 gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch enabled=1
Damit später nur verifizierte, also RPM-Pakete mit einer gültigen PGP-Signatur installiert werden können, benötigen wir noch den passenden PGP-Key von elasticsearch. Hinweise zum Bezug des Schlüssels und dessen Fingerprint finden wir auf der elasticsearch Dokumentationsseite. Wir holen uns nun den RPM-PGP-Key auf unseren Server.
# wget https://packages.elastic.co/GPG-KEY-elasticsearch -P /etc/pki/rpm-gpg
Bevor wir diesen aber importieren, lassen wir uns den Fingerprint am Bildschirm ausgeben.
# gpg --with-fingerprint /etc/pki/rpm-gpg/GPG-KEY-elasticsearch
pub 2048R/D88E42B4 2013-09-16 Elasticsearch (Elasticsearch Signing Key) <dev_ops@elasticsearch.org> Key fingerprint = 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 sub 2048R/60D31954 2013-09-16
Diesen Key fingerprint = 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 vergleichen wir nun mit den Angaben auf der elasticsearch Dokumentationsseite. Stimmen beide Fingerprints überein, steht dem Import des Schlüssels nicht's mehr entgegen.
# rpm --import /etc/pki/rpm-gpg/GPG-KEY-elasticsearch
graylog
Graylog selbst werden wir später aus dem Repository von graylog installieren. So bleibt zum einen der Konfigurationsaufwand überschaubar und wir werden mit Updates versorgt, wenn Änderungen und/oder Erweiterungen am Programmcode von graylog notwendig werden. Die Integration des benötigten Repositories erfolgt direkt mit nachfolgendem Befehl:
# yum localinstall https://packages.graylog2.org/repo/el/7/1.3/x86_64/graylog-1.3-repository-el7-1.3.0-1.noarch.rpm
Leider bietet uns graylog selbst keine Möglichkeit, den Fingerprint des PGP-Key /etc/pki/rpm-gpg/RPM-GPG-KEY-graylog mit der Key-ID=B1606F22 einzusehen. Wir müssen daher auf einen PGP-Keyserver ausweichen. Über die URL http://keyserver.nausch.org/pks/lookup?search=0xB1606F22&fingerprint=on erhalten wir in einem Browserfenster direkt den Fingerprint angezeigt. Diesen Fingerprint vergleichen wir nun mit dem des RPM-Pakets.
# gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-graylog
pub 2048R/B1606F22 2014-06-04 TORCH GmbH <packages@torch.sh> Key fingerprint = 28AB 6EB5 7277 9C2A D196 BE22 D44C 1D8D B160 6F22
Sind beide Werte gleich, können wir auch diesen PGP-Key wie gewohnt importieren.
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-graylog
Installation
Da nun alle Voraussetzungen geschaffen sind, können wir uns an die Installation der einzelnen RPM-Pakete machen.
OpenJDK
Als erstes installieren wir nun die OpenJDK Runtime Environment mit Hilfe von YUM.
# yum install java-1.8.0-openjdk -y
Haben wir bereits eine installierte Java Umgebung installiert können wir mit folgendem Befehl abfragen ob die benötigte Version den Installationsvoraussetzungen (installiertes JAVA oder OpenJDK ab Version 1.7.0) von graylog genügt.
# java -version
openjdk version "1.8.0_65" OpenJDK Runtime Environment (build 1.8.0_65-b17) OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
Wollen wir wissen, welche Dateien und Verzeichnisse das Paket auf unseren Server packte, benutzen wir folgenden Befehl.
# rpm -qil java-1.8.0-openjdk
Name : java-1.8.0-openjdk
Epoch : 1
Version : 1.8.0.65
Release : 3.b17.el7
Architecture: x86_64
Install Date: Mon 21 Dec 2015 12:46:44 PM CET
Group : Development/Languages
Size : 512633
License : ASL 1.1 and ASL 2.0 and GPL+ and GPLv2 and GPLv2 with exceptions and LGPL+ and LGPLv2 and MPLv1.0 and MPLv1.1 and Public Domain and W3C
Signature : RSA/SHA256, Wed 25 Nov 2015 03:45:32 PM CET, Key ID 24c6a8a7f4a80eb5
Source RPM : java-1.8.0-openjdk-1.8.0.65-3.b17.el7.src.rpm
Build Date : Sat 21 Nov 2015 04:29:16 AM CET
Build Host : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager : CentOS BuildSystem <http://bugs.centos.org>
Vendor : CentOS
URL : http://openjdk.java.net/
Summary : OpenJDK Runtime Environment
Description :
The OpenJDK runtime environment.
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/bin/policytool
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/lib/amd64/libawt_xawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/lib/amd64/libjawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/lib/amd64/libjsoundalsa.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/lib/amd64/libsplashscreen.so
/usr/share/applications/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64-policytool.desktop
/usr/share/icons/hicolor/16x16/apps/java-1.8.0.png
/usr/share/icons/hicolor/24x24/apps/java-1.8.0.png
/usr/share/icons/hicolor/32x32/apps/java-1.8.0.png
/usr/share/icons/hicolor/48x48/apps/java-1.8.0.png
MongoDB
Als nächstes erfolgt die Installation unserer MongoDB. Dank dem eingebundenen zugehörigen Repository erfolgt dies mit Hilfe von YUM.
# yum install mongodb mongodb-server -y
Auch hier können wir uns einen Überblick verschaffen, welche Verzeichnisse angelegt und Dateien dort abgelegt wurden.
# rpm -qil mongodb
Name : mongodb
Version : 2.6.11
Release : 1.el7
Architecture: x86_64
Install Date: Wed 23 Dec 2015 10:19:36 AM CET
Group : Applications/Databases
Size : 137519320
License : AGPLv3 and zlib and ASL 2.0
Signature : RSA/SHA256, Thu 20 Aug 2015 07:39:20 PM CEST, Key ID 6a2faea2352c64e5
Source RPM : mongodb-2.6.11-1.el7.src.rpm
Build Date : Wed 19 Aug 2015 01:57:11 PM CEST
Build Host : buildvm-08.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://www.mongodb.org
Summary : High-performance, schema-free document-oriented database
Description :
Mongo (from "humongous") is a high-performance, open source, schema-free
document-oriented database. MongoDB is written in C++ and offers the following
features:
* Collection oriented storage: easy storage of object/JSON-style data
* Dynamic queries
* Full index support, including on inner objects and embedded arrays
* Query profiling
* Replication and fail-over support
* Efficient storage of binary data including large objects (e.g. photos
and videos)
* Auto-sharding for cloud-level scalability (currently in early alpha)
* Commercial Support Available
A key goal of MongoDB is to bridge the gap between key/value stores (which are
fast and highly scalable) and traditional RDBMS systems (which are deep in
functionality).
/usr/bin/bsondump
/usr/bin/mongo
/usr/bin/mongodump
/usr/bin/mongoexport
/usr/bin/mongofiles
/usr/bin/mongoimport
/usr/bin/mongooplog
/usr/bin/mongoperf
/usr/bin/mongorestore
/usr/bin/mongosniff
/usr/bin/mongostat
/usr/bin/mongotop
/usr/share/doc/mongodb-2.6.11
/usr/share/doc/mongodb-2.6.11/README
/usr/share/licenses/mongodb-2.6.11
/usr/share/licenses/mongodb-2.6.11/APACHE-2.0.txt
/usr/share/licenses/mongodb-2.6.11/GNU-AGPL-3.0.txt
/usr/share/man/man1/bsondump.1.gz
/usr/share/man/man1/mongo.1.gz
/usr/share/man/man1/mongodump.1.gz
/usr/share/man/man1/mongoexport.1.gz
/usr/share/man/man1/mongofiles.1.gz
/usr/share/man/man1/mongoimport.1.gz
/usr/share/man/man1/mongooplog.1.gz
/usr/share/man/man1/mongoperf.1.gz
/usr/share/man/man1/mongorestore.1.gz
/usr/share/man/man1/mongosniff.1.gz
/usr/share/man/man1/mongostat.1.gz
/usr/share/man/man1/mongotop.1.gz
# rpm -qil mongodb-server
Name : mongodb-server
Version : 2.6.11
Release : 1.el7
Architecture: x86_64
Install Date: Wed 23 Dec 2015 10:19:25 AM CET
Group : Applications/Databases
Size : 20949371
License : AGPLv3 and zlib and ASL 2.0
Signature : RSA/SHA256, Thu 20 Aug 2015 07:37:34 PM CEST, Key ID 6a2faea2352c64e5
Source RPM : mongodb-2.6.11-1.el7.src.rpm
Build Date : Wed 19 Aug 2015 01:57:11 PM CEST
Build Host : buildvm-08.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://www.mongodb.org
Summary : MongoDB server, sharding server and support scripts
Description :
This package provides the mongo server software, mongo sharding server
software, default configuration files, and init scripts.
/etc/logrotate.d/mongodb
/etc/mongod.conf
/etc/mongos.conf
/etc/sysconfig/mongod
/etc/sysconfig/mongos
/usr/bin/mongod
/usr/bin/mongos
/usr/lib/systemd/system/mongod.service
/usr/lib/systemd/system/mongos.service
/usr/lib/tmpfiles.d/mongodb.conf
/usr/share/man/man1/mongod.1.gz
/usr/share/man/man1/mongos.1.gz
/var/lib/mongodb
/var/log/mongodb
/var/run/mongodb
Elasticsearch
Im nächsten Schritt installieren wir nun noch elasticsearch als Suchmaschine/-server.
# yum install elasticsearch -y
Wollen wir wissen, welche Dateien und Verzeichnisse das Paket auf unseren Server packte, benutzen wir folgenden Befehl.
# rpm -qil elasticsearch
Name : elasticsearch
Version : 1.7.4
Release : 1
Architecture: noarch
Install Date: Mon 28 Dec 2015 02:05:49 PM CET
Group : Application/Internet
Size : 31336448
License : (c) 2009
Signature : RSA/SHA1, Tue 15 Dec 2015 05:53:18 PM CET, Key ID d27d666cd88e42b4
Source RPM : elasticsearch-1.7.4-1.src.rpm
Build Date : Tue 15 Dec 2015 05:53:15 PM CET
Build Host : monster
Relocations : /usr
Packager : Elasticsearch
Summary : elasticsearch
Description :
Elasticsearch - Open Source, Distributed, RESTful Search Engine
/etc/elasticsearch
/etc/elasticsearch/elasticsearch.yml
/etc/elasticsearch/logging.yml
/etc/init.d/elasticsearch
/etc/sysconfig/elasticsearch
/tmp/elasticsearch
/usr/lib/sysctl.d
/usr/lib/sysctl.d/elasticsearch.conf
/usr/lib/systemd/system/elasticsearch.service
/usr/lib/tmpfiles.d
/usr/lib/tmpfiles.d/elasticsearch.conf
/usr/share/elasticsearch/LICENSE.txt
/usr/share/elasticsearch/NOTICE.txt
/usr/share/elasticsearch/README.textile
/usr/share/elasticsearch/bin
/usr/share/elasticsearch/bin/elasticsearch
/usr/share/elasticsearch/bin/elasticsearch.in.sh
/usr/share/elasticsearch/bin/plugin
/usr/share/elasticsearch/lib/antlr-runtime-3.5.jar
/usr/share/elasticsearch/lib/apache-log4j-extras-1.2.17.jar
/usr/share/elasticsearch/lib/asm-4.1.jar
/usr/share/elasticsearch/lib/asm-commons-4.1.jar
/usr/share/elasticsearch/lib/elasticsearch-1.7.4.jar
/usr/share/elasticsearch/lib/groovy-all-2.4.4.jar
/usr/share/elasticsearch/lib/jna-4.1.0.jar
/usr/share/elasticsearch/lib/jts-1.13.jar
/usr/share/elasticsearch/lib/log4j-1.2.17.jar
/usr/share/elasticsearch/lib/lucene-analyzers-common-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-core-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-expressions-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-grouping-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-highlighter-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-join-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-memory-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-misc-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-queries-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-queryparser-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-sandbox-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-spatial-4.10.4.jar
/usr/share/elasticsearch/lib/lucene-suggest-4.10.4.jar
/usr/share/elasticsearch/lib/sigar
/usr/share/elasticsearch/lib/sigar/libsigar-amd64-linux.so
/usr/share/elasticsearch/lib/sigar/libsigar-ia64-linux.so
/usr/share/elasticsearch/lib/sigar/libsigar-x86-linux.so
/usr/share/elasticsearch/lib/sigar/sigar-1.6.4.jar
/usr/share/elasticsearch/lib/spatial4j-0.4.1.jar
/usr/share/elasticsearch/plugins
/var/lib/elasticsearch
/var/log/elasticsearch
/var/run/elasticsearch
graylog
Zu guter letzt installieren wir nun noch Pakete graylog sowie das Zusatzprogramm pwgen zum Generieren von Passwörtern, natürlich auch dieses mal mit Unterstützung von YUM.
# yum install graylog-server graylog-web pwgen -y
Auch hier können wir uns einen Überblick verschaffen, welche Verzeichnisse angelegt und Dateien dort abgelegt wurden.
# rpm -qil graylog-server
Name : graylog-server
Version : 1.3.2
Release : 1
Architecture: noarch
Install Date: Wed 23 Dec 2015 10:41:06 AM CET
Group : optional
Size : 76865791
License : GPLv3
Signature : RSA/SHA1, Fri 18 Dec 2015 04:37:43 PM CET, Key ID d44c1d8db1606f22
Source RPM : graylog-server-1.3.2-1.src.rpm
Build Date : Fri 18 Dec 2015 04:37:25 PM CET
Build Host : 861e2c96c63a
Relocations : /
Packager : Graylog, Inc. <hello@graylog.org>
Vendor : graylog
URL : https://www.graylog.org/
Summary : Graylog server
Description :
Graylog server
/etc/graylog/server/log4j.xml
/etc/graylog/server/server.conf
/etc/sysconfig/graylog-server
/usr/lib/systemd/system/graylog-server.service
/usr/share/graylog-server/bin/graylog-es-timestamp-fixup
/usr/share/graylog-server/bin/graylog-server
/usr/share/graylog-server/contentpacks/grok-patterns.json
/usr/share/graylog-server/graylog.jar
/usr/share/graylog-server/installation-source.sh
/usr/share/graylog-server/lib/sigar/libsigar-amd64-linux.so
/usr/share/graylog-server/lib/sigar/libsigar-x86-linux.so
/usr/share/graylog-server/plugin/usage-statistics-1.2.1.jar
# rpm -qil graylog-web
Name : graylog-web
Version : 1.3.2
Release : 1
Architecture: noarch
Install Date: Wed 23 Dec 2015 10:41:08 AM CET
Group : optional
Size : 46487307
License : GPLv3
Signature : RSA/SHA1, Fri 18 Dec 2015 04:39:01 PM CET, Key ID d44c1d8db1606f22
Source RPM : graylog-web-1.3.2-1.src.rpm
Build Date : Fri 18 Dec 2015 04:38:50 PM CET
Build Host : e1ea7e6dc62a
Relocations : /
Packager : Graylog, Inc. <hello@graylog.org>
Vendor : graylog
URL : https://www.graylog.org/
Summary : Graylog web
Description :
Graylog web
/etc/graylog/web/application.conf
/etc/graylog/web/logback.xml
/etc/graylog/web/play.plugins
/etc/graylog/web/web.conf
/etc/sysconfig/graylog-web
/usr/lib/systemd/system/graylog-web.service
/usr/share/graylog-web/README.md
/usr/share/graylog-web/bin/graylog-web
/usr/share/graylog-web/bin/graylog-web-interface
/usr/share/graylog-web/conf
/usr/share/graylog-web/lib/aopalliance.aopalliance-1.0.jar
/usr/share/graylog-web/lib/ch.qos.logback.logback-classic-1.1.1.jar
/usr/share/graylog-web/lib/ch.qos.logback.logback-core-1.1.1.jar
/usr/share/graylog-web/lib/com.fasterxml.classmate-1.1.0.jar
/usr/share/graylog-web/lib/com.fasterxml.jackson.core.jackson-annotations-2.6.2.jar
/usr/share/graylog-web/lib/com.fasterxml.jackson.core.jackson-core-2.6.2.jar
/usr/share/graylog-web/lib/com.fasterxml.jackson.core.jackson-databind-2.6.2.jar
/usr/share/graylog-web/lib/com.fasterxml.jackson.datatype.jackson-datatype-guava-2.6.2.jar
/usr/share/graylog-web/lib/com.fasterxml.jackson.datatype.jackson-datatype-joda-2.6.2.jar
/usr/share/graylog-web/lib/com.github.fdimuccio.play2-sockjs_2.10-0.3.1.jar
/usr/share/graylog-web/lib/com.google.code.findbugs.jsr305-3.0.1.jar
/usr/share/graylog-web/lib/com.google.guava.guava-18.0.jar
/usr/share/graylog-web/lib/com.google.inject.extensions.guice-assistedinject-4.0.jar
/usr/share/graylog-web/lib/com.google.inject.guice-4.0.jar
/usr/share/graylog-web/lib/com.ning.async-http-client-1.9.31.jar
/usr/share/graylog-web/lib/com.squareup.okhttp.okhttp-2.5.0.jar
/usr/share/graylog-web/lib/com.squareup.okio.okio-1.6.0.jar
/usr/share/graylog-web/lib/com.typesafe.akka.akka-actor_2.10-2.3.5.jar
/usr/share/graylog-web/lib/com.typesafe.akka.akka-slf4j_2.10-2.3.4.jar
/usr/share/graylog-web/lib/com.typesafe.config-1.2.1.jar
/usr/share/graylog-web/lib/com.typesafe.netty.netty-http-pipelining-1.1.2.jar
/usr/share/graylog-web/lib/com.typesafe.play.build-link-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-cache_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-datacommons_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-exceptions-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-functional_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-iteratees_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-java_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play-json_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.play_2.10-2.3.10.jar
/usr/share/graylog-web/lib/com.typesafe.play.twirl-api_2.10-1.0.2.jar
/usr/share/graylog-web/lib/commons-beanutils.commons-beanutils-1.8.3.jar
/usr/share/graylog-web/lib/commons-codec.commons-codec-1.9.jar
/usr/share/graylog-web/lib/commons-logging.commons-logging-1.1.3.jar
/usr/share/graylog-web/lib/dom4j.dom4j-1.6.1.jar
/usr/share/graylog-web/lib/graylog-web-interface.graylog-web-interface-1.3.2-assets.jar
/usr/share/graylog-web/lib/graylog-web-interface.graylog-web-interface-1.3.2.jar
/usr/share/graylog-web/lib/io.netty.netty-3.10.4.Final.jar
/usr/share/graylog-web/lib/javassist.javassist--3.12.1.GA-3.12.1.GA.jar
/usr/share/graylog-web/lib/javax.el.javax.el-api-3.0.0.jar
/usr/share/graylog-web/lib/javax.inject.javax.inject-1.jar
/usr/share/graylog-web/lib/javax.transaction.jta-1.1.jar
/usr/share/graylog-web/lib/javax.validation.validation-api-1.1.0.Final.jar
/usr/share/graylog-web/lib/joda-time.joda-time-2.8.2.jar
/usr/share/graylog-web/lib/net.sf.ehcache.ehcache-core-2.6.8.jar
/usr/share/graylog-web/lib/org.apache.commons.commons-lang3-3.1.jar
/usr/share/graylog-web/lib/org.apache.shiro.shiro-core-1.2.4.jar
/usr/share/graylog-web/lib/org.apache.tomcat.tomcat-servlet-api-8.0.5.jar
/usr/share/graylog-web/lib/org.graylog2.graylog2-rest-client--1.3.2-1.3.2.jar
/usr/share/graylog-web/lib/org.graylog2.graylog2-rest-models-1.3.2.jar
/usr/share/graylog-web/lib/org.graylog2.play2-graylog2_2.10-1.2.1.jar
/usr/share/graylog-web/lib/org.hibernate.hibernate-validator-5.2.2.Final.jar
/usr/share/graylog-web/lib/org.javassist.javassist-3.19.0-GA.jar
/usr/share/graylog-web/lib/org.jboss.logging.jboss-logging-3.2.1.Final.jar
/usr/share/graylog-web/lib/org.joda.joda-convert-1.6.jar
/usr/share/graylog-web/lib/org.reflections.reflections-0.9.8.jar
/usr/share/graylog-web/lib/org.scala-lang.scala-library-2.10.4.jar
/usr/share/graylog-web/lib/org.scala-lang.scala-reflect-2.10.4.jar
/usr/share/graylog-web/lib/org.scala-stm.scala-stm_2.10-0.7.jar
/usr/share/graylog-web/lib/org.slf4j.jcl-over-slf4j-1.7.6.jar
/usr/share/graylog-web/lib/org.slf4j.jul-to-slf4j-1.7.6.jar
/usr/share/graylog-web/lib/org.slf4j.slf4j-api-1.7.12.jar
/usr/share/graylog-web/lib/org.springframework.spring-aop--4.0.3.RELEASE-4.0.3.RELEASE.jar
/usr/share/graylog-web/lib/org.springframework.spring-beans-4.0.3.RELEASE.jar
/usr/share/graylog-web/lib/org.springframework.spring-context-4.0.3.RELEASE.jar
/usr/share/graylog-web/lib/org.springframework.spring-core-4.0.3.RELEASE.jar
/usr/share/graylog-web/lib/org.springframework.spring-expression--4.0.3.RELEASE-4.0.3.RELEASE.jar
/usr/share/graylog-web/lib/org.yaml.snakeyaml-1.13.jar
/usr/share/graylog-web/lib/xerces.xercesImpl-2.11.0.jar
/usr/share/graylog-web/lib/xml-apis.xml-apis-1.4.01.jar
# rpm -qil pwgen
Name : pwgen
Version : 2.07
Release : 1.el7
Architecture: x86_64
Install Date: Mon 28 Dec 2015 09:54:47 AM CET
Group : Applications/System
Size : 37925
License : GPL+
Signature : RSA/SHA256, Sat 06 Dec 2014 03:49:56 PM CET, Key ID 6a2faea2352c64e5
Source RPM : pwgen-2.07-1.el7.src.rpm
Build Date : Fri 05 Dec 2014 06:56:18 PM CET
Build Host : buildvm-08.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://sf.net/projects/pwgen
Summary : Automatic password generation
Description :
pwgen generates random, meaningless but pronounceable passwords. These
passwords contain either only lowercase letters, or upper and lower case, or
upper case, lower case and numeric digits. Upper case letters and numeric
digits are placed in a way that eases memorizing the password.
/usr/bin/pwgen
/usr/share/doc/pwgen-2.07
/usr/share/doc/pwgen-2.07/changelog
/usr/share/doc/pwgen-2.07/copyright
/usr/share/man/man1/pwgen.1.gz
Konfiguration
Nachdem wir die Installation aller benötigten Programmpakete erfolgreich abgeschlossen haben, können wir uns nun an die Installation der einzelnen Komponenten wagen.
MongoDB
Obwohl in der MongoDB nur Metainformationen gespeichert und vorgehalten werden, wollen wir diese NoSQL-Datenbank absichern, indem wir einen Datenbankbenutzer mit Passwort anlegen. Somit ist sichergestellt, dass kein unbefugter Daten der MongoDB abrufen, ändern oder gar löschen kann.
Start des Daemon
Unsere Konfigurationsänderungen werden mit Hilfe von mongo der MongoDB Shell vorgenommen. Dieses JavaScript stellt die Benutzerschnittstelle zum eigentlichen MongoDN-Daemon zur Verfügung. Damit sich der Client mit dem Server auch verbinden kann, muss der Server natürlich laufen; wir starten also nun unsere NoSQL-Datenbank mit folgendem Befehl.
# systemctl start mongod.service
Den Serverstatus können wir wie folgt abfragen.
# systemctl status mongod.service
● mongod.service - High-performance, schema-free document-oriented database Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2015-12-23 11:05:55 CET; 57min ago Main PID: 23784 (mongod) CGroup: /system.slice/mongod.service └─23784 /usr/bin/mongod --quiet -f /etc/mongod.conf run Dec 23 11:05:52 vml000117.dmz.nausch.org systemd[1]: Starting High-performance, schema-free document-oriented database... Dec 23 11:05:52 vml000117.dmz.nausch.org mongod[23782]: about to fork child process, waiting until server is ready for connections. Dec 23 11:05:52 vml000117.dmz.nausch.org mongod[23782]: forked process: 23784 Dec 23 11:05:55 vml000117.dmz.nausch.org systemd[1]: Started High-performance, schema-free document-oriented database.
Der erfolgreiche Start des Servers wird auch in dessen Logdatei protokolliert.
# less /var/log/mongodb/mongod.log
2015-12-23T11:05:52.629+0100 [initandlisten] MongoDB starting : pid=23784 port=27017 dbpath=/var/lib/mongodb 64-bit host=vml000117.dmz.nausch.org 2015-12-23T11:05:52.630+0100 [initandlisten] db version v2.6.11 2015-12-23T11:05:52.630+0100 [initandlisten] git version: nogitversion 2015-12-23T11:05:52.630+0100 [initandlisten] OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013 2015-12-23T11:05:52.630+0100 [initandlisten] build info: Linux buildvm-08.phx2.fedoraproject.org 4.1.4-100.fc21.x86_64 #1 SMP Tue Aug 4 03:25:05 UTC 2015 x86_64 BOOST_LIB_VERSION=1_53 2015-12-23T11:05:52.630+0100 [initandlisten] allocator: tcmalloc 2015-12-23T11:05:52.630+0100 [initandlisten] options: { command: [ "run" ], config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", unixDomainSocket: { pathPrefix: "/var/run/mongodb" } }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongod.pid" }, storage: { dbPath: "/var/lib/mongodb" }, systemLog: { destination: "file", path: "/var/log/mongodb/mongod.log", quiet: true } } 2015-12-23T11:05:52.630+0100 [initandlisten] 2015-12-23T11:05:52.630+0100 [initandlisten] ** WARNING: Readahead for /var/lib/mongodb is set to 4096KB 2015-12-23T11:05:52.630+0100 [initandlisten] ** We suggest setting it to 256KB (512 sectors) or less 2015-12-23T11:05:52.630+0100 [initandlisten] ** http://dochub.mongodb.org/core/readahead 2015-12-23T11:05:52.644+0100 [initandlisten] journal dir=/var/lib/mongodb/journal 2015-12-23T11:05:52.644+0100 [initandlisten] recover : no journal files present, no recovery needed 2015-12-23T11:05:54.446+0100 [initandlisten] preallocateIsFaster=true 11.28 2015-12-23T11:05:55.340+0100 [initandlisten] allocating new ns file /var/lib/mongodb/local.ns, filling with zeroes... 2015-12-23T11:05:55.519+0100 [FileAllocator] allocating new datafile /var/lib/mongodb/local.0, filling with zeroes... 2015-12-23T11:05:55.519+0100 [FileAllocator] creating directory /var/lib/mongodb/_tmp 2015-12-23T11:05:55.532+0100 [FileAllocator] done allocating datafile /var/lib/mongodb/local.0, size: 64MB, took 0.004 secs 2015-12-23T11:05:55.535+0100 [initandlisten] build index on: local.startup_log properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "local.startup_log" } 2015-12-23T11:05:55.535+0100 [initandlisten] added index to empty collection 2015-12-23T11:05:55.535+0100 [initandlisten] command local.$cmd command: create { create: "startup_log", size: 10485760, capped: true } ntoreturn:1 keyUpdates:0 numYields:0 reslen:37 195ms 2015-12-23T11:05:55.535+0100 [initandlisten] waiting for connections on port 27017
Standardmäßig öffnet der MongoDB-Daemon den Port 27017. Dies können wir wie folgt auch überprüfen:
# netstat -tulpen
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 184 19185 1460/mongod
Anpassung des Readahead-Parameters
Im Logfile finden wir eine Readahead-Warnmeldung mit dem Hinweis, dass die readahead-Einstellungen für das Block-Gerät auf dem die MongoDB gespeichert wurde nicht optimal zum Speichern der NoSQL-Datenbank MongoDB geeigent ist.
2015-12-23T11:05:52.630+0100 [initandlisten] ** WARNING: Readahead for /var/lib/mongodb is set to 4096KB 2015-12-23T11:05:52.630+0100 [initandlisten] ** We suggest setting it to 256KB (512 sectors) or less 2015-12-23T11:05:52.630+0100 [initandlisten] ** http://dochub.mongodb.org/core/readahead
Zunächst suchen wir, auf welchem Blockdevice das Verzeichnis /var/lib/mongodb liegt.
# mount | grep /var/lib/mongodb
/dev/vdc1 on /var/lib/mongodb type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
Fragen wir die Einstellungen unserer Blockdevices ab erhalten wir zunächst:
# blockdev --report
RO RA SSZ BSZ StartSec Size Device rw 8192 512 4096 0 10485760000 /dev/vda rw 8192 512 512 2048 524288000 /dev/vda1 rw 8192 512 4096 1026048 9960423424 /dev/vda2 rw 8192 512 4096 0 21474836480 /dev/vdb rw 8192 512 512 2048 21473787904 /dev/vdb1 rw 8192 512 4096 0 21474836480 /dev/vdc rw 8192 512 512 2048 21473787904 /dev/vdc1 rw 8192 512 4096 0 1073741824 /dev/dm-0 rw 8192 512 512 0 6731857920 /dev/dm-1 rw 8192 512 512 0 2147483648 /dev/dm-2
Wir setzen nunmehr den Wert RA auf die empfohlene Größe von 256KB (512 sectors) für das Blockdevice /dev/vdc1 auf dem unsere MongoDB bespeichert wird.
# blockdev --setra 256 /dev/vdc1
Fragen wir erneut die Einstellungen für /dev/vdc1 sehen wir, dass der Parameter RA nun den Wert von 256 hat.
# blockdev --report | grep /dev/vdc1
rw 256 512 512 2048 21473787904 /dev/vdc1
Wenn abschließend starten wir nun den MongoDB-Daemon einmal durch, damit unsere Änderung auch wirksam werden kann.
# systemctl restart mongod.service
Die Warnmeldung ist nunmehr verschwunden.
# less /var/log/mongodb/mongod.log
2015-12-23T12:11:50.221+0100 [initandlisten] MongoDB starting : pid=16609 port=27017 dbpath=/var/lib/mongodb 64-bit host=vml000117.dmz.nausch.org 2015-12-23T12:11:50.221+0100 [initandlisten] db version v2.6.11 2015-12-23T12:11:50.221+0100 [initandlisten] git version: nogitversion 2015-12-23T12:11:50.221+0100 [initandlisten] OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013 2015-12-23T12:11:50.221+0100 [initandlisten] build info: Linux buildvm-08.phx2.fedoraproject.org 4.1.4-100.fc21.x86_64 #1 SMP Tue Aug 4 03:25:05 UTC 2015 x86_64 BOOST_LIB_VERSION=1_53 2015-12-23T12:11:50.221+0100 [initandlisten] allocator: tcmalloc 2015-12-23T12:11:50.221+0100 [initandlisten] options: { command: [ "run" ], config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", unixDomainSocket: { pathPrefix: "/var/run/mongodb" } }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongod.pid" }, storage: { dbPath: "/var/lib/mongodb" }, systemLog: { destination: "file", path: "/var/log/mongodb/mongod.log", quiet: true } } 2015-12-23T12:11:50.235+0100 [initandlisten] journal dir=/var/lib/mongodb/journal 2015-12-23T12:11:50.235+0100 [initandlisten] recover : no journal files present, no recovery needed 2015-12-23T12:11:51.759+0100 [initandlisten] preallocateIsFaster=true 13.14 2015-12-23T12:11:52.660+0100 [initandlisten] waiting for connections on port 27017
Die eben gemachte Konfigurationsberichtigung wird aber bei einem Reboot des Servers wieder verworfen. Wir müssen also dafür sorgen, dass der readahead-Wert bei einem Neustart des Systems auf den gewünschten Wert 256 gesetzt wird. Hierzu legen wir uns ein kleines Bash-Script an.
# vim /usr/local/bin/setra256
- /usr/local/bin/setra256
#!/bin/bash # Django : 2015-12-28 # Setzen des readahead Wertes auf 256KB (512 Sektoren) /usr/sbin/blockdev --setra 256 /dev/vdc1
Nun müssen wir nur noch dafür sorgen, dass dieses Script bei einem Neustart gestartet wird. Dazu legen wir uns einen eigenen „kleinen Service“ an, in dem wir im Verzeichnis /etc/systemd/system/ eine systemd-Startscript anlegen.
# vim /etc/systemd/system/setra256.service
- /etc/systemd/system/setra256.service
[Unit] Description=Initialize hardware monitoring sensors After=syslog.target network.target Before=mongod.service [Service] Type=oneshot ExecStart=/usr/local/bin/setra256 [Install] WantedBy=multi-user.target
Zu guter letzt führen wir noch einen Reload des Systemd-Daemon durch und wir haben künftig immer den richtig gesetzten readahead von 256 gesetzt.
# systemctl daemon-reload
automatischer Start des Daemon
Damit der Daemon beim Hochfahren unseres Servers automatisch gestartet wird, nutzen wir folgenden Befehl.
# systemctl enable mongod.service
Created symlink from /etc/systemd/system/multi-user.target.wants/mongod.service to /usr/lib/systemd/system/mongod.service.
Wollen wir wissen, ob die Autostartfunktion bereits gesetzt ist, verwenden wir diesen Aufruf.
# systemctl is-enabled mongod.service
enabled
Datenbanknutzer anlegen
Wie bereits kurz erwähnt wollen wir unsere MongoDB absichern, indem wir einen Datenbakbenutzer mit Passwort anlegen. Dazu verbinden wir uns erst einmal mit der MongoDB Shell mongo.
# mongo
MongoDB shell version: 2.6.11 connecting to: test Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user >
Zunächst wechseln wir zur Datenbank admin mit folgendem Aufruf.
> use admin
switched to db admin >
Anschließend legen wir den Datenbankadministrator admin mit dem Passwort 5y510953rv3r53cr37 an.
> db.createUser({user:"admin",pwd:"5y510953rv3r53cr37",roles:[{role:"root",db:"admin"}]})
Successfully added user: { "user" : "admin", "roles" : [ { "role" : "root", "db" : "admin" } ] } >
Für den Zugriff von graylog auf die NoSQL-Datenbang MongoDB erstellen wir uns nun noch einen separaten Nutzer graylog-user mit dem zugehörigen Passwort 7h3FBI15n07ar0ckb4and. Bevor wir diesen Datenbank-Account anlegen, erstellen und wechseln wir noch zur Datenbank graylog.
> use graylog
switched to db graylog
Nun können wir auch unseren User graylog-user anlegen.
> db.createUser({user:"graylog-user",pwd:"7h3FBI15n07ar0ckb4and",roles:["readWrite"]})
Successfully added user: { "user" : "graylog-user", "roles" : [ "readWrite" ] } >
Wir haben die nötigen Definitionen erfolgreich zu Ende gebracht und nun können wir die MongoDB Shell mongo wieder verlassen.
> exit
bye
Zum Testen, ob unser Datenbanknutzer graylog-user sich auch erfolgreich mit der NoSQL-Datenbank graylog verbinden kann, melden wir uns mit dessen Daten an und fragen die vorhandenen Datenbanken ab.
# mongo -u "graylog-user" -p "7h3FBI15n07ar0ckb4and" 127.0.0.1:27017/graylog
MongoDB shell version: 2.6.11 connecting to: 127.0.0.1:27017/test >
Die Tabellen der gewählten Datenbank kann man sich mit dem Befehl show collections
anzeigen lassen.
> show collections
alarmcallbackconfigurations alarmcallbackhistory alerts cluster_config cluster_events collectors content_packs dashboards dead_letters grok_patterns index_failures index_ranges inputs ldap_settings nodes notifications roles sessions streamrules streams system.indexes system_messages users >
Da der Zugriff klappte, können wir die Datenbankverbindung wieder beenden.
> exit
bye
Geben wir ein falsches Passwort ein, wird natürlich der Zugang verwehrt.
# mongo -u "graylog-user" -p "7h3FBI15n07ar0ckb4and" 127.0.0.1:27017/graylog
MongoDB shell version: 2.6.11 connecting to: 127.0.0.1:27017/test 2015-12-23T13:08:02.381+0100 Error: 18 { ok: 0.0, errmsg: "auth failed", code: 18 } at src/mongo/shell/db.js:1292 exception: login failed
Zum Abschluss unterbinden wir nun noch den Passwortlosen Zugang zur MongoDB. Der Parameter auth im Abschnitt General options der Konfigurationsdatei /etc/mongod.conf
# vim /etc/mongod.conf
- /etc/mongod.conf
## ### Basic Defaults ## # Comma separated list of ip addresses to listen on (all local ips by default) bind_ip = 127.0.0.1 # Specify port number (27017 by default) #port = 27017 # Fork server process (false by default) fork = true # Full path to pidfile (if not set, no pidfile is created) pidfilepath = /var/run/mongodb/mongod.pid # Log file to send write to instead of stdout - has to be a file, not directory logpath = /var/log/mongodb/mongod.log # Alternative directory for UNIX domain sockets (defaults to /tmp) unixSocketPrefix = /var/run/mongodb # Directory for datafiles (defaults to /data/db/) dbpath = /var/lib/mongodb # Enable/Disable journaling (journaling is on by default for 64 bit) #journal = true #nojournal = true ## ### General options ## # Be more verbose (include multiple times for more verbosity e.g. -vvvvv) (v by default) #verbose = v # Max number of simultaneous connections (1000000 by default) #maxConns = 1000000 # Log to system's syslog facility instead of file or stdout (false by default) #syslog = true # Syslog facility used for monogdb syslog message (user by defautl) #syslogFacility = user # Append to logpath instead of over-writing (false by default) #logappend = true # Desired format for timestamps in log messages (One of ctime, iso8601-utc or iso8601-local) (iso8601-local by default) #timeStampFormat = arg # Private key for cluster authentication #keyFile = arg # Set a configurable parameter #setParameter = arg # Enable http interface (false by default) #httpinterface = true # Authentication mode used for cluster authentication. Alternatives are (keyFile|sendKeyFile|sendX509|x509) (keyFile by default) #clusterAuthMode = arg # Disable listening on unix sockets (false by default) #nounixsocket = true # Run with/without security (without by default) #auth = true #noauth = true # Django : 2015-12-23 - Passwortlose logins unterbinden # default: #auth = true # #noauth = true auth = true # Enable IPv6 support (disabled by default) #ipv6 = true # Allow JSONP access via http (has security implications) (false by default) #jsonp = true # Turn on simple rest api (false by default) #rest = true # Value of slow for profile and console log (100 by default) #slowms = 100 # 0=off 1=slow, 2=all (0 by default) #profile = 0 # Periodically show cpu and iowait utilization (false by default) #cpu = true # Print some diagnostic system information (false by default) #sysinfo = true # Each database will be stored in a separate directory (false by default) #directoryperdb = true # Don't retry any index builds that were interrupted by shutdown (false by default) #noIndexBuildRetry = true # Disable data file preallocation - will often hurt performance (false by default) #noprealloc = true # .ns file size (in MB) for new databases (16 MB by default) #nssize = 16 # Limits each database to a certain number of files (8 default) #quota # Number of files allowed per db, implies --quota (8 by default) #quotaFiles = 8 # Use a smaller default file size (false by default) #smallfiles = true # Seconds between disk syncs (0=never, but not recommended) (60 by default) #syncdelay = 60 # Upgrade db if needed (false by default) #upgrade = true # Run repair on all dbs (false by default) #repair = true # Root directory for repair files (defaults to dbpath) #repairpath = arg # Disable scripting engine (false by default) #noscripting = true # Do not allow table scans (false by default) #notablescan = true # Journal diagnostic options (0 by default) #journalOptions = 0 # How often to group/batch commit (ms) (100 or 30 by default) #journalCommitInterval = 100 ## ### Replication options ## # Size to use (in MB) for replication op log (default 5% of disk space - i.e. large is good) #oplogSize = arg ## ### Master/slave options (old; use replica sets instead) ## # Master mode #master = true # Slave mode #slave = true # When slave: specify master as <server:port> #source = arg # When slave: specify a single database to replicate #only = arg # Specify delay (in seconds) to be used when applying master ops to slave #slavedelay = arg # Automatically resync if slave data is stale #autoresync = true ## ### Replica set options ## # Arg is <setname>[/<optionalseedhostlist>] #replSet = arg # Specify index prefetching behavior (if secondary) [none|_id_only|all] (all by default) #replIndexPrefetch = all ## ### Sharding options ## # Declare this is a config db of a cluster (default port 27019; default dir /data/configdb) (false by default) #configsvr = true # Declare this is a shard db of a cluster (default port 27018) (false by default) #shardsvr = true ## ### SSL options ## # Use ssl on configured ports #sslOnNormalPorts = true # Set the SSL operation mode (disabled|allowSSL|preferSSL|requireSSL) # sslMode = arg # PEM file for ssl #sslPEMKeyFile = arg # PEM file password #sslPEMKeyPassword = arg # Key file for internal SSL authentication #sslClusterFile = arg # Internal authentication key file password #sslClusterPassword = arg # Certificate Authority file for SSL #sslCAFile = arg # Certificate Revocation List file for SSL #sslCRLFile = arg # Allow client to connect without presenting a certificate #sslWeakCertificateValidation = true # Allow server certificates to provide non-matching hostnames #sslAllowInvalidHostnames = true # Allow connections to servers with invalid certificates #sslAllowInvalidCertificates = true # Activate FIPS 140-2 mode at startup #sslFIPSMode = true
Nun werden wir den MongoDB-Daemon einaml noch durchstarten, damit die durchgeführten Änderungen auch aktiv werden.
# systemctl restart mongod.service
Ein Anmeldeversuch ohne Benutzerkennung samt Passwort ist ab sofort nicht mehr möglich.
Elasticsearch
In diesem Abschnitt werden wir nun den Suchserver elasticsearch, der auch die eigentlichen Nutztdaten von graylog vorhalten wird, konfigurieren.
In der Dokumentation von graylog im Abschnitt Architectural considerations finden wir folgenden Hinweis:
Elasticsearch nodes should have as much RAM as possible and the fastest disks you can get. Everything depends on I/O speed here.
Diesem Vorschlag wollen wir nun in die Tat umsetzen. Beim Blockdevice haben wir in unserem Konfigurationsbeispiel bereits ein RAID aus schnellen Server-SSD's verwendet. Nun werden wir dem elasticsearch-Daemon noch mehr an RAM zugestehen. Hierzu werden wir nun den Parameter vm.max_map_count anpassen. Zunächst aber fragen wird den aktuellen Wert von vm.max_map_count erst einmal ab.
# sysctl vm.max_map_count
vm.max_map_count = 65530
In der Dokumentation von elasticsearch zum virtuellen Speicherverbrauch wird empfohlen, den großzügigen Wert von 262144 zu setzen. Während der Laufzeit des Systems können wir die Änderung mit folgendem Befehl vornehmen.
# sysctl -w vm.max_map_count=262144
vm.max_map_count = 262144
Damit die Werteanpassung resetfest, also bei jedem Neustart des Servers auf den gewünschten Wert gesetzt wird, bearbeiten wir die Datei /etc/sysctl.conf.
# vim /etc/sysctl.conf
- /etc/sysctl.conf
# System default settings live in /usr/lib/sysctl.d/00-system.conf. # To override those settings, enter new settings here, or in an /etc/sysctl.d/<name>.conf file # # For more information, see sysctl.conf(5) and sysctl.d(5). # # Django : 2015-12-23 - den virtuellen Speicherverbrauch von elasticsearch anpassen vm.max_map_count=262144
elasticsearch.yml
Laut der Installationsdokumentation von graylog beschränkt sich die Konfiguration von elasticsearch auf das Setzen des cluster name. Den Node Name setzen wir im dem Zuge auf den Hoastname unseres Syslog-Servers.
The only important thing for Elasticsearch is that you set the exactly same cluster name (e. g. ``cluster.name: graylog``) that is being used by Graylog in the Elasticsearch configuration (``conf/elasticsearch.yml``).
Da aber in der Dokumentation Setup Configuration werden wir noch den Parameter mlockall auf true setzen.
# vim /etc/elasticsearch/elasticsearch.yml
- /etc/elasticsearch/elasticsearch.yml
##################### Elasticsearch Configuration Example ##################### # This file contains an overview of various configuration settings, # targeted at operations staff. Application developers should # consult the guide at <http://elasticsearch.org/guide>. # # The installation procedure is covered at # <http://elasticsearch.org/guide/en/elasticsearch/reference/current/setup.html>. # # Elasticsearch comes with reasonable defaults for most settings, # so you can try it out without bothering with configuration. # # Most of the time, these defaults are just fine for running a production # cluster. If you're fine-tuning your cluster, or wondering about the # effect of certain configuration option, please _do ask_ on the # mailing list or IRC channel [http://elasticsearch.org/community]. # Any element in the configuration can be replaced with environment variables # by placing them in ${...} notation. For example: # #node.rack: ${RACK_ENV_VAR} # For information on supported formats and syntax for the config file, see # <http://elasticsearch.org/guide/en/elasticsearch/reference/current/setup-configuration.html> ################################### Cluster ################################### # Cluster name identifies your cluster for auto-discovery. If you're running # multiple clusters on the same network, make sure you're using unique names. # # Django : 2015-12-28 # default: #cluster.name: elasticsearch cluster.name: graylog #################################### Node ##################################### # Node names are generated dynamically on startup, so you're relieved # from configuring them manually. You can tie this node to a specific name: # # Django : 2015-12-28 # default: #node.name: "Franz Kafka" node.name: vml000117 # Every node can be configured to allow or deny being eligible as the master, # and to allow or deny to store the data. # # Allow this node to be eligible as a master node (enabled by default): # #node.master: true # # Allow this node to store data (enabled by default): # #node.data: true # You can exploit these settings to design advanced cluster topologies. # # 1. You want this node to never become a master node, only to hold data. # This will be the "workhorse" of your cluster. # #node.master: false #node.data: true # # 2. You want this node to only serve as a master: to not store any data and # to have free resources. This will be the "coordinator" of your cluster. # #node.master: true #node.data: false # # 3. You want this node to be neither master nor data node, but # to act as a "search load balancer" (fetching data from nodes, # aggregating results, etc.) # #node.master: false #node.data: false # Use the Cluster Health API [http://localhost:9200/_cluster/health], the # Node Info API [http://localhost:9200/_nodes] or GUI tools # such as <http://www.elasticsearch.org/overview/marvel/>, # <http://github.com/karmi/elasticsearch-paramedic>, # <http://github.com/lukas-vlcek/bigdesk> and # <http://mobz.github.com/elasticsearch-head> to inspect the cluster state. # A node can have generic attributes associated with it, which can later be used # for customized shard allocation filtering, or allocation awareness. An attribute # is a simple key value pair, similar to node.key: value, here is an example: # #node.rack: rack314 # By default, multiple nodes are allowed to start from the same installation location # to disable it, set the following: #node.max_local_storage_nodes: 1 #################################### Index #################################### # You can set a number of options (such as shard/replica options, mapping # or analyzer definitions, translog settings, ...) for indices globally, # in this file. # # Note, that it makes more sense to configure index settings specifically for # a certain index, either when creating it or by using the index templates API. # # See <http://elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules.html> and # <http://elasticsearch.org/guide/en/elasticsearch/reference/current/indices-create-index.html> # for more information. # Set the number of shards (splits) of an index (5 by default): # #index.number_of_shards: 5 # Set the number of replicas (additional copies) of an index (1 by default): # #index.number_of_replicas: 1 # Note, that for development on a local machine, with small indices, it usually # makes sense to "disable" the distributed features: # #index.number_of_shards: 1 #index.number_of_replicas: 0 # These settings directly affect the performance of index and search operations # in your cluster. Assuming you have enough machines to hold shards and # replicas, the rule of thumb is: # # 1. Having more *shards* enhances the _indexing_ performance and allows to # _distribute_ a big index across machines. # 2. Having more *replicas* enhances the _search_ performance and improves the # cluster _availability_. # # The "number_of_shards" is a one-time setting for an index. # # The "number_of_replicas" can be increased or decreased anytime, # by using the Index Update Settings API. # # Elasticsearch takes care about load balancing, relocating, gathering the # results from nodes, etc. Experiment with different settings to fine-tune # your setup. # Use the Index Status API (<http://localhost:9200/A/_status>) to inspect # the index status. #################################### Paths #################################### # Path to directory containing configuration (this file and logging.yml): # #path.conf: /path/to/conf # Path to directory where to store index data allocated for this node. # #path.data: /path/to/data # # Can optionally include more than one location, causing data to be striped across # the locations (a la RAID 0) on a file level, favouring locations with most free # space on creation. For example: # #path.data: /path/to/data1,/path/to/data2 # Path to temporary files: # #path.work: /path/to/work # Path to log files: # #path.logs: /path/to/logs # Path to where plugins are installed: # #path.plugins: /path/to/plugins #################################### Plugin ################################### # If a plugin listed here is not installed for current node, the node will not start. # #plugin.mandatory: mapper-attachments,lang-groovy ################################### Memory #################################### # Elasticsearch performs poorly when JVM starts swapping: you should ensure that # it _never_ swaps. # # Set this property to true to lock the memory: # # Django : 2015-12-28 # default: unset bootstrap.mlockall: true # Make sure that the ES_MIN_MEM and ES_MAX_MEM environment variables are set # to the same value, and that the machine has enough memory to allocate # for Elasticsearch, leaving enough memory for the operating system itself. # # You should also make sure that the Elasticsearch process is allowed to lock # the memory, eg. by using `ulimit -l unlimited`. ############################## Network And HTTP ############################### # Elasticsearch, by default, binds itself to the 0.0.0.0 address, and listens # on port [9200-9300] for HTTP traffic and on port [9300-9400] for node-to-node # communication. (the range means that if the port is busy, it will automatically # try the next port). # Set the bind address specifically (IPv4 or IPv6): # #network.bind_host: 192.168.0.1 # Set the address other nodes will use to communicate with this node. If not # set, it is automatically derived. It must point to an actual IP address. # #network.publish_host: 192.168.0.1 # Set both 'bind_host' and 'publish_host': # #network.host: 192.168.0.1 # Set a custom port for the node to node communication (9300 by default): # #transport.tcp.port: 9300 # Enable compression for all communication between nodes (disabled by default): # #transport.tcp.compress: true # Set a custom port to listen for HTTP traffic: # #http.port: 9200 # Set a custom allowed content length: # #http.max_content_length: 100mb # Disable HTTP completely: # #http.enabled: false ################################### Gateway ################################### # The gateway allows for persisting the cluster state between full cluster # restarts. Every change to the state (such as adding an index) will be stored # in the gateway, and when the cluster starts up for the first time, # it will read its state from the gateway. # There are several types of gateway implementations. For more information, see # <http://elasticsearch.org/guide/en/elasticsearch/reference/current/modules-gateway.html>. # The default gateway type is the "local" gateway (recommended): # #gateway.type: local # Settings below control how and when to start the initial recovery process on # a full cluster restart (to reuse as much local data as possible when using shared # gateway). # Allow recovery process after N nodes in a cluster are up: # #gateway.recover_after_nodes: 1 # Set the timeout to initiate the recovery process, once the N nodes # from previous setting are up (accepts time value): # #gateway.recover_after_time: 5m # Set how many nodes are expected in this cluster. Once these N nodes # are up (and recover_after_nodes is met), begin recovery process immediately # (without waiting for recover_after_time to expire): # #gateway.expected_nodes: 2 ############################# Recovery Throttling ############################# # These settings allow to control the process of shards allocation between # nodes during initial recovery, replica allocation, rebalancing, # or when adding and removing nodes. # Set the number of concurrent recoveries happening on a node: # # 1. During the initial recovery # #cluster.routing.allocation.node_initial_primaries_recoveries: 4 # # 2. During adding/removing nodes, rebalancing, etc # #cluster.routing.allocation.node_concurrent_recoveries: 2 # Set to throttle throughput when recovering (eg. 100mb, by default 20mb): # #indices.recovery.max_bytes_per_sec: 20mb # Set to limit the number of open concurrent streams when # recovering a shard from a peer: # #indices.recovery.concurrent_streams: 5 ################################## Discovery ################################## # Discovery infrastructure ensures nodes can be found within a cluster # and master node is elected. Multicast discovery is the default. # Set to ensure a node sees N other master eligible nodes to be considered # operational within the cluster. This should be set to a quorum/majority of # the master-eligible nodes in the cluster. # #discovery.zen.minimum_master_nodes: 1 # Set the time to wait for ping responses from other nodes when discovering. # Set this option to a higher value on a slow or congested network # to minimize discovery failures: # #discovery.zen.ping.timeout: 3s # For more information, see # <http://elasticsearch.org/guide/en/elasticsearch/reference/current/modules-discovery-zen.html> # Unicast discovery allows to explicitly control which nodes will be used # to discover the cluster. It can be used when multicast is not present, # or to restrict the cluster communication-wise. # # 1. Disable multicast discovery (enabled by default): # #discovery.zen.ping.multicast.enabled: false # Django : 2015-12-28 # default: "enabled by default" discovery.zen.ping.multicast.enabled: false # # 2. Configure an initial list of master nodes in the cluster # to perform discovery when new nodes (master or data) are started: # #discovery.zen.ping.unicast.hosts: ["host1", "host2:port"] # Django : 2015-12-28 # default: unset discovery.zen.ping.unicast.hosts: ["127.0.0.1:9300"] # EC2 discovery allows to use AWS EC2 API in order to perform discovery. # # You have to install the cloud-aws plugin for enabling the EC2 discovery. # # For more information, see # <http://elasticsearch.org/guide/en/elasticsearch/reference/current/modules-discovery-ec2.html> # # See <http://elasticsearch.org/tutorials/elasticsearch-on-ec2/> # for a step-by-step tutorial. # GCE discovery allows to use Google Compute Engine API in order to perform discovery. # # You have to install the cloud-gce plugin for enabling the GCE discovery. # # For more information, see <https://github.com/elasticsearch/elasticsearch-cloud-gce>. # Azure discovery allows to use Azure API in order to perform discovery. # # You have to install the cloud-azure plugin for enabling the Azure discovery. # # For more information, see <https://github.com/elasticsearch/elasticsearch-cloud-azure>. ################################## Slow Log ################################## # Shard level query and fetch threshold logging. #index.search.slowlog.threshold.query.warn: 10s #index.search.slowlog.threshold.query.info: 5s #index.search.slowlog.threshold.query.debug: 2s #index.search.slowlog.threshold.query.trace: 500ms #index.search.slowlog.threshold.fetch.warn: 1s #index.search.slowlog.threshold.fetch.info: 800ms #index.search.slowlog.threshold.fetch.debug: 500ms #index.search.slowlog.threshold.fetch.trace: 200ms #index.indexing.slowlog.threshold.index.warn: 10s #index.indexing.slowlog.threshold.index.info: 5s #index.indexing.slowlog.threshold.index.debug: 2s #index.indexing.slowlog.threshold.index.trace: 500ms ################################## GC Logging ################################ #monitor.jvm.gc.young.warn: 1000ms #monitor.jvm.gc.young.info: 700ms #monitor.jvm.gc.young.debug: 400ms #monitor.jvm.gc.old.warn: 10s #monitor.jvm.gc.old.info: 5s #monitor.jvm.gc.old.debug: 2s ################################## Security ################################ # Uncomment if you want to enable JSONP as a valid return transport on the # http server. With this enabled, it may pose a security risk, so disabling # it unless you need it is recommended (it is disabled by default). # #http.jsonp.enable: true
elasticsearch.service
Damit Parameter bootstrap.mlockall auch richtig gesetzt werden kann, ist noch eine Änderung an dem Systemd-Startscript notwendig! Dieses werden wir nun noch anpassen; hierzu kopieren wir uns nun das entsprechende Script nach /etc/systemd/system/.
# cp -a /usr/lib/systemd/system/elasticsearch.service /etc/systemd/system/
In dieser Datei setzen wir den Parameter LimitMEMLOCK auf infinity.
# vim /etc/systemd/system/elasticsearch.service
- /etc/systemd/system/elasticsearch.service
[Unit] Description=Elasticsearch Documentation=http://www.elastic.co Wants=network-online.target After=network-online.target [Service] Environment=ES_HOME=/usr/share/elasticsearch Environment=CONF_DIR=/etc/elasticsearch Environment=CONF_FILE=/etc/elasticsearch/elasticsearch.yml Environment=DATA_DIR=/var/lib/elasticsearch Environment=LOG_DIR=/var/log/elasticsearch Environment=PID_DIR=/var/run/elasticsearch EnvironmentFile=-/etc/sysconfig/elasticsearch User=elasticsearch Group=elasticsearch ExecStart=/usr/share/elasticsearch/bin/elasticsearch \ -Des.pidfile=$PID_DIR/elasticsearch.pid \ -Des.default.path.home=$ES_HOME \ -Des.default.path.logs=$LOG_DIR \ -Des.default.path.data=$DATA_DIR \ -Des.default.config=$CONF_FILE \ -Des.default.path.conf=$CONF_DIR # Connects standard output to /dev/null StandardOutput=null # Connects standard error to journal StandardError=journal # When a JVM receives a SIGTERM signal it exits with code 143 SuccessExitStatus=143 # Specifies the maximum file descriptor number that can be opened by this process LimitNOFILE=65535 # Specifies the maximum number of bytes of memory that may be locked into RAM # Set to "infinity" if you use the 'bootstrap.mlockall: true' option # in elasticsearch.yml and 'MAX_LOCKED_MEMORY=unlimited' in /etc/sysconfig/elasticsearch # Django : 2015-12-28 # default: # LimitMEMLOCK=infinity LimitMEMLOCK=infinity # Shutdown delay in seconds, before process is tried to be killed with KILL (if configured) TimeoutStopSec=20 [Install] WantedBy=multi-user.target # Built for elasticsearch-1.7.4 (rpm)
Anschließend informieren wir den systemd über unser „updatesicheres“ Startscript.
systemctl daemon-reload
Start des Daemon
Unsere Konfigurationsänderungen werden mit Hilfe von mongo der MongoDB Shell vorgenommen. Dieses JavaScript stellt die Benutzerschnittstelle zum eigentlichen MongoDN-Daemon zur Verfügung. Damit sich der Client mit dem Server auch verbinden kann, muss der Server natürlich laufen; wir starten also nun unsere NoSQL-Datenbank mit folgendem Befehl.
# systemctl start mongod.service
Den Serverstatus können wir wie folgt abfragen.
# systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch Loaded: loaded (/etc/systemd/system/elasticsearch.service; disabled; vendor preset: disabled) Active: active (running) since Mon 2015-12-28 14:20:23 CET; 1min 56s ago Docs: http://www.elastic.co Main PID: 32221 (java) CGroup: /system.slice/elasticsearch.service └─32221 /bin/java -Xms256m -Xmx1g -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupan... Dec 28 14:20:23 vml000117.dmz.nausch.org systemd[1]: Started Elasticsearch. Dec 28 14:20:23 vml000117.dmz.nausch.org systemd[1]: Starting Elasticsearch...
Der erfolgreiche Start des Servers wird auch in dessen Logdatei protokolliert.
# /var/log/elasticsearch/elasticsearch.log
[2015-12-28 14:20:24,201][INFO ][node ] [vml000117] version[1.7.4], pid[32221], build[0d3159b/2015-12-15T16:45:04Z] [2015-12-28 14:20:24,202][INFO ][node ] [vml000117] initializing ... [2015-12-28 14:20:24,323][INFO ][plugins ] [vml000117] loaded [], sites [] [2015-12-28 14:20:24,378][INFO ][env ] [vml000117] using [1] data paths, mounts [[/var/lib/elasticsearch (/dev/vdc1)]], net usable_space [24.3gb], net total_space [24.4gb], types [xfs] [2015-12-28 14:20:29,846][INFO ][node ] [vml000117] initialized [2015-12-28 14:20:29,846][INFO ][node ] [vml000117] starting ... [2015-12-28 14:20:30,282][INFO ][transport ] [vml000117] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/10.0.0.117:9300]} [2015-12-28 14:20:30,352][INFO ][discovery ] [vml000117] graylog/EdAnadZuTiOjxFR7_Kvdrg [2015-12-28 14:20:33,462][INFO ][cluster.service ] [vml000117] new_master [vml000117][EdAnadZuTiOjxFR7_Kvdrg][vml000117.dmz.nausch.org][inet[/10.0.0.117:9300]], reason: zen-disco-join (elected_as_master) [2015-12-28 14:20:33,508][INFO ][http ] [vml000117] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/10.0.0.117:9200]} [2015-12-28 14:20:33,508][INFO ][node ] [vml000117] started [2015-12-28 14:20:33,541][INFO ][gateway ] [vml000117] recovered [0] indices into cluster_state [2015-12-28 14:20:35,573][INFO ][cluster.service ] [vml000117] added {[vml000117][4u6LKkewT-ClHj25SjY5gA][vml000117.dmz.nausch.org][inet[/10.0.0.117:9350]]{client=true, data=false, master=false},}, reason: zen-disco-receive(join from node[[vml000117][4u6LKkewT-ClHj25SjY5gA][vml000117.dmz.nausch.org][inet[/10.0.0.117:9350]]{client=true, data=false, master=false}]) [2015-12-28 14:20:44,296][INFO ][cluster.metadata ] [vml000117] [graylog_0] creating index, cause [api], templates [graylog-internal], shards [1]/[0], mappings [message] [2015-12-28 14:20:44,959][INFO ][cluster.metadata ] [vml000117] [graylog_1] creating index, cause [api], templates [graylog-internal], shards [1]/[0], mappings [message]
automatischer Start des Daemon
Damit der Daemon beim Hochfahren unseres Servers automatisch gestartet wird, nutzen wir folgenden Befehl.
# systemctl enable elasticsearch.service
Created symlink from /etc/systemd/system/multi-user.target.wants/elasticsearch.service to /usr/lib/systemd/system/elasticsearch.service.
Wollen wir wissen, ob die Autostartfunktion bereits gesetzt ist, verwenden wir diesen Aufruf.
# systemctl is-enabled elasticsearch.service
enabled
Test
Zum Testen unserer Konfigurationseinstellungen nutzen wir die Nodes Info API.
# curl localhost:9200/_nodes/process?pretty
{ "cluster_name" : "graylog", "nodes" : { "EdAnadZuTiOjxFR7_Kvdrg" : { "name" : "vml000117", "transport_address" : "inet[/10.0.0.117:9300]", "host" : "vml000117.dmz.nausch.org", "ip" : "10.0.0.117", "version" : "1.7.4", "build" : "0d3159b", "http_address" : "inet[/10.0.0.117:9200]", "process" : { "refresh_interval_in_millis" : 1000, "id" : 32221, "max_file_descriptors" : 65535, "mlockall" : true } } } }
Den Zustand des elastic-Servers kann man sich mit folgendem Aufruf anzeigen lassen.
# curl localhost:9200/_cluster/health?pretty
{ "cluster_name" : "graylog", "status" : "green", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 2, "active_shards" : 2, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0 }
graylog-server
Nachdem wir alle Vorbereitungen erfolgreich abgeschlossen haben, können wir uns nun der Konfiguration des graylog-server Daemons widmen.
/etc/sysconfig/graylog-server
Auf unserem System unter CentOS 7.x hatten wir als JAVA Runtime Enviroment das Paket openjdk in der Version 1.8 installiert. Ab Version 1.8 werden die beiden Parameter PermSize und MaxPermSize nicht mehr unterstützt. Wir werden daher in der Konfigurationsdatei /etc/sysconfig/graylog-server diese beiden Parameter bei den GRAYLOG_SERVERGRAYLOG_SERVER_JAVA_OPTS entfernen.
# vim /etc/sysconfig/graylog-server
- /etc/sysconfig/graylog-server
# Path to the java executable. JAVA=/usr/bin/java # Default Java options for heap and garbage collection. # # Django : 2015-12-28 - PermSize und MaxPermSize werden ab openjdk-1.8.0 nicht mehr unterstützt # default: GRAYLOG_SERVER_JAVA_OPTS="-Xms1g -Xmx1g -XX:NewRatio=1 -XX:PermSize=128m -XX:MaxPermSize=256m -server -XX:+ResizeTLAB -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:-OmitStackTraceInFastThrow" GRAYLOG_SERVER_JAVA_OPTS="-Xms1g -Xmx1g -XX:NewRatio=1 -server -XX:+ResizeTLAB -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:-OmitStackTraceInFastThrow" # Pass some extra args to graylog-server. (i.e. "-d" to enable debug mode) GRAYLOG_SERVER_ARGS="" # Program that will be used to wrap the graylog-server command. Useful to # support programs like authbind. GRAYLOG_COMMAND_WRAPPER=""
/etc/graylog/server/server.conf
Die eigentliche Konfiguration unseres graylog-Servers wird in dessen Konfigurationsdatei /etc/graylog/server/server.conf vorgenommen.
Bevor wir diese öffnen und bearbeiten, erstellen wir uns noch zwei Dinge:
- Passwort-Hash
Mit Hilfe des Passwort-Hash werden die Nutzerpassworte verschlüsselt. Diesen hash-Wert erstellen wir wie folgt:# pwgen -N 1 -s 128
yCWAd48fvOmR7xAmcKezZ2C0v3mtaXCJjA7NfhBlSf98PTxHrf9SrCQDX2xgjCzrHpxoV5UNOEfQZsOP1gkWkYlDarD75tbtztPhR59O70yZchaJcyQTeHBZllQc8RcT
- Admin-Passwort
Der administrative Benutzer admin benötigt noch ein zugehöriges Passwort, erzeugen wir nun mit folgendem Befehl.# echo -n N3v3r7ru57Y0URg0v3rnm3n7 | sha256sum
38337fd07fd4ee02548053d7bed3ee33e3e0c593c2802941e2349fc52e80b98d -
Diese beiden Werte hinterlegen wir nun in der Konfigurationsdatei unseres graylog-Daemon und passen anschließend die Konfigurationsoptionen unserer Umgebung an. Änderungen an den Default-Werten sind mit Django : <Zeitstempel> gekennzeichnet
# vim /etc/graylog/server/server.conf
- /etc/graylog/server/server.conf
# If you are running more than one instances of graylog2-server you have to select one of these # instances as master. The master will perform some periodical tasks that non-masters won't perform. is_master = true # The auto-generated node ID will be stored in this file and read after restarts. It is a good idea # to use an absolute file path here if you are starting graylog2-server from init scripts or similar. node_id_file = /etc/graylog/server/node-id # You MUST set a secret to secure/pepper the stored user passwords here. Use at least 64 characters. # Generate one by using for example: pwgen -N 1 -s 96 # Django : 2015-12-28 # default: password_secret = password_secret = yCWAd48fvOmR7xAmcKezZ2C0v3mtaXCJjA7NfhBlSf98PTxHrf9SrCQDX2xgjCzrHpxoV5UNOEfQZsOP1gkWkYlDarD75tbtztPhR59O70yZchaJcyQTeHBZllQc8RcT # The default root user is named 'admin' # Django : 2015-12-28 # default: #root_username = admin root_username = admin # You MUST specify a hash password for the root user (which you only need to initially set up the # system and in case you lose connectivity to your authentication backend) # This password cannot be changed using the API or via the web interface. If you need to change it, # modify it in this file. # Create one by using for example: echo -n yourpassword | shasum -a 256 # and put the resulting hash value into the following line # Django : 2015-12-28 # default: root_password_sha2 = root_password_sha2 = 38337fd07fd4ee02548053d7bed3ee33e3e0c593c2802941e2349fc52e80b98d # The email address of the root user. # Default is empty # Django : 2015-12-28 # default: #root_email = "" root_email = "graylog_admin@nausch.org" # The time zone setting of the root user. # The configured time zone must be parseable by http://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeZone.html#forID-java.lang.String- # Default is UTC # Django : 2015-12-28 # default: #root_timezone = UTC root_timezone = Europe/Berlin # Set plugin directory here (relative or absolute) plugin_dir = /usr/share/graylog-server/plugin # REST API listen URI. Must be reachable by other graylog2-server nodes if you run a cluster. rest_listen_uri = http://127.0.0.1:12900/ # REST API transport address. Defaults to the value of rest_listen_uri. Exception: If rest_listen_uri # is set to a wildcard IP address (0.0.0.0) the first non-loopback IPv4 system address is used. # If set, his will be promoted in the cluster discovery APIs, so other nodes may try to connect on # this address and it is used to generate URLs addressing entities in the REST API. (see rest_listen_uri) # You will need to define this, if your Graylog server is running behind a HTTP proxy that is rewriting # the scheme, host name or URI. #rest_transport_uri = http://192.168.1.1:12900/ # Django : 2015-12-28 # default: unset rest_transport_uri = http://127.0.0.1:12900/ # Enable CORS headers for REST API. This is necessary for JS-clients accessing the server directly. # If these are disabled, modern browsers will not be able to retrieve resources from the server. # This is disabled by default. Uncomment the next line to enable it. #rest_enable_cors = true # Django : 2015-12-28 # default: unset rest_enable_cors = true # Enable GZIP support for REST API. This compresses API responses and therefore helps to reduce # overall round trip times. This is disabled by default. Uncomment the next line to enable it. #rest_enable_gzip = true # Django : 2015-12-28 # default: unset rest_enable_gzip = true # Enable HTTPS support for the REST API. This secures the communication with the REST API with # TLS to prevent request forgery and eavesdropping. This is disabled by default. Uncomment the # next line to enable it. #rest_enable_tls = true # The X.509 certificate file to use for securing the REST API. #rest_tls_cert_file = /path/to/graylog2.crt # The private key to use for securing the REST API. #rest_tls_key_file = /path/to/graylog2.key # The password to unlock the private key used for securing the REST API. #rest_tls_key_password = secret # The maximum size of a single HTTP chunk in bytes. #rest_max_chunk_size = 8192 # The maximum size of the HTTP request headers in bytes. #rest_max_header_size = 8192 # The maximal length of the initial HTTP/1.1 line in bytes. #rest_max_initial_line_length = 4096 # The size of the execution handler thread pool used exclusively for serving the REST API. #rest_thread_pool_size = 16 # The size of the worker thread pool used exclusively for serving the REST API. #rest_worker_threads_max_pool_size = 16 # Embedded Elasticsearch configuration file # pay attention to the working directory of the server, maybe use an absolute path here #elasticsearch_config_file = /etc/graylog/server/elasticsearch.yml # Graylog will use multiple indices to store documents in. You can configured the strategy it uses to determine # when to rotate the currently active write index. # It supports multiple rotation strategies: # - "count" of messages per index, use elasticsearch_max_docs_per_index below to configure # - "size" per index, use elasticsearch_max_size_per_index below to configure # valid values are "count", "size" and "time", default is "count" # Django : 2015-12-28 # default: rotation_strategy = count rotation_strategy = time # (Approximate) maximum number of documents in an Elasticsearch index before a new index # is being created, also see no_retention and elasticsearch_max_number_of_indices. # Configure this if you used 'rotation_strategy = count' above. # Django : 2015-12-28 # default: elasticsearch_max_docs_per_index = 20000000 # (Approximate) maximum size in bytes per Elasticsearch index on disk before a new index is being created, also see # no_retention and elasticsearch_max_number_of_indices. Default is 1GB. # Configure this if you used 'rotation_strategy = size' above. #elasticsearch_max_size_per_index = 1073741824 # (Approximate) maximum time before a new Elasticsearch index is being created, also see # no_retention and elasticsearch_max_number_of_indices. Default is 1 day. # Configure this if you used 'rotation_strategy = time' above. # Please note that this rotation period does not look at the time specified in the received messages, but is # using the real clock value to decide when to rotate the index! # Specify the time using a duration and a suffix indicating which unit you want: # 1w = 1 week # 1d = 1 day # 12h = 12 hours # Permitted suffixes are: d for day, h for hour, m for minute, s for second. #elasticsearch_max_time_per_index = 1d # Django : 2015-12-28 # default: unset elasticsearch_max_time_per_index = 1d # Disable checking the version of Elasticsearch for being compatible with this Graylog release. # WARNING: Using Graylog with unsupported and untested versions of Elasticsearch may lead to data loss! #elasticsearch_disable_version_check = true # Disable message retention on this node, i. e. disable Elasticsearch index rotation. #no_retention = false # How many indices do you want to keep? # Django : 2015-12-28 # default: elasticsearch_max_number_of_indices = 20 elasticsearch_max_number_of_indices = 30 # Decide what happens with the oldest indices when the maximum number of indices is reached. # The following strategies are availble: # - delete # Deletes the index completely (Default) # - close # Closes the index and hides it from the system. Can be re-opened later. retention_strategy = delete # How many Elasticsearch shards and replicas should be used per index? Note that this only applies to newly created indices. # Django : 2015-12-28 # default: elasticsearch_shards = 4 elasticsearch_shards = 1 elasticsearch_replicas = 0 # Prefix for all Elasticsearch indices and index aliases managed by Graylog. # Django : 2015-12-28 # default: elasticsearch_index_prefix = graylog2 elasticsearch_index_prefix = graylog # Name of the Elasticsearch index template used by Graylog to apply the mandatory index mapping. # # Default: graylog-internal #elasticsearch_template_name = graylog-internal # Do you want to allow searches with leading wildcards? This can be extremely resource hungry and should only # be enabled with care. See also: https://www.graylog.org/documentation/general/queries/ allow_leading_wildcard_searches = false # Do you want to allow searches to be highlighted? Depending on the size of your messages this can be memory hungry and # should only be enabled after making sure your Elasticsearch cluster has enough memory. allow_highlighting = false # settings to be passed to elasticsearch's client (overriding those in the provided elasticsearch_config_file) # all these # this must be the same as for your Elasticsearch cluster #elasticsearch_cluster_name = graylog2 # Django : 2015-12-28 # default: unset elasticsearch_cluster_name = graylog # you could also leave this out, but makes it easier to identify the graylog2 client instance #elasticsearch_node_name = graylog2-server # Django : 2015-12-28 # default: unset elasticsearch_node_name = vml000117 # we don't want the graylog2 server to store any data, or be master node # Django : 2015-12-28 # default: #elasticsearch_node_master = false # #elasticsearch_node_data = false elasticsearch_node_master = false elasticsearch_node_data = false # use a different port if you run multiple Elasticsearch nodes on one machine #elasticsearch_transport_tcp_port = 9350 # we don't need to run the embedded HTTP server here # Django : 2015-12-28 # default: #elasticsearch_http_enabled = false elasticsearch_http_enabled = false # Django : 2015-12-28 # default: #elasticsearch_discovery_zen_ping_multicast_enabled = false elasticsearch_discovery_zen_ping_multicast_enabled = false # Django : 2015-12-28 # default: #elasticsearch_discovery_zen_ping_unicast_hosts = 127.0.0.1:9300 elasticsearch_discovery_zen_ping_unicast_hosts = 127.0.0.1:9300 # Change the following setting if you are running into problems with timeouts during Elasticsearch cluster discovery. # The setting is specified in milliseconds, the default is 5000ms (5 seconds). #elasticsearch_cluster_discovery_timeout = 5000 # the following settings allow to change the bind addresses for the Elasticsearch client in graylog2 # these settings are empty by default, letting Elasticsearch choose automatically, # override them here or in the 'elasticsearch_config_file' if you need to bind to a special address # refer to http://www.elasticsearch.org/guide/en/elasticsearch/reference/0.90/modules-network.html # for special values here #elasticsearch_network_host = #elasticsearch_network_bind_host = #elasticsearch_network_publish_host = # The total amount of time discovery will look for other Elasticsearch nodes in the cluster # before giving up and declaring the current node master. #elasticsearch_discovery_initial_state_timeout = 3s # Analyzer (tokenizer) to use for message and full_message field. The "standard" filter usually is a good idea. # All supported analyzers are: standard, simple, whitespace, stop, keyword, pattern, language, snowball, custom # Elasticsearch documentation: http://www.elasticsearch.org/guide/reference/index-modules/analysis/ # Note that this setting only takes effect on newly created indices. elasticsearch_analyzer = standard # Global request timeout for Elasticsearch requests (e. g. during search, index creation, or index time-range # calculations) based on a best-effort to restrict the runtime of Elasticsearch operations. # Default: 1m #elasticsearch_request_timeout = 1m # Time interval for index range information cleanups. This setting defines how often stale index range information # is being purged from the database. # Default: 1h #index_ranges_cleanup_interval = 1h # Batch size for the Elasticsearch output. This is the maximum (!) number of messages the Elasticsearch output # module will get at once and write to Elasticsearch in a batch call. If the configured batch size has not been # reached within output_flush_interval seconds, everything that is available will be flushed at once. Remember # that every outputbuffer processor manages its own batch and performs its own batch write calls. # ("outputbuffer_processors" variable) output_batch_size = 500 # Flush interval (in seconds) for the Elasticsearch output. This is the maximum amount of time between two # batches of messages written to Elasticsearch. It is only effective at all if your minimum number of messages # for this time period is less than output_batch_size * outputbuffer_processors. output_flush_interval = 1 # As stream outputs are loaded only on demand, an output which is failing to initialize will be tried over and # over again. To prevent this, the following configuration options define after how many faults an output will # not be tried again for an also configurable amount of seconds. output_fault_count_threshold = 5 output_fault_penalty_seconds = 30 # The number of parallel running processors. # Raise this number if your buffers are filling up. processbuffer_processors = 5 outputbuffer_processors = 3 #outputbuffer_processor_keep_alive_time = 5000 #outputbuffer_processor_threads_core_pool_size = 3 #outputbuffer_processor_threads_max_pool_size = 30 # UDP receive buffer size for all message inputs (e. g. SyslogUDPInput). #udp_recvbuffer_sizes = 1048576 # Wait strategy describing how buffer processors wait on a cursor sequence. (default: sleeping) # Possible types: # - yielding # Compromise between performance and CPU usage. # - sleeping # Compromise between performance and CPU usage. Latency spikes can occur after quiet periods. # - blocking # High throughput, low latency, higher CPU usage. # - busy_spinning # Avoids syscalls which could introduce latency jitter. Best when threads can be bound to specific CPU cores. processor_wait_strategy = blocking # Size of internal ring buffers. Raise this if raising outputbuffer_processors does not help anymore. # For optimum performance your LogMessage objects in the ring buffer should fit in your CPU L3 cache. # Start server with --statistics flag to see buffer utilization. # Must be a power of 2. (512, 1024, 2048, ...) ring_size = 65536 inputbuffer_ring_size = 65536 inputbuffer_processors = 2 inputbuffer_wait_strategy = blocking # Enable the disk based message journal. message_journal_enabled = true # The directory which will be used to store the message journal. The directory must me exclusively used by Graylog and # must not contain any other files than the ones created by Graylog itself. message_journal_dir = /var/lib/graylog-server/journal # Journal hold messages before they could be written to Elasticsearch. # For a maximum of 12 hours or 5 GB whichever happens first. # During normal operation the journal will be smaller. #message_journal_max_age = 12h #message_journal_max_size = 5gb #message_journal_flush_age = 1m #message_journal_flush_interval = 1000000 #message_journal_segment_age = 1h #message_journal_segment_size = 100mb # Number of threads used exclusively for dispatching internal events. Default is 2. #async_eventbus_processors = 2 # EXPERIMENTAL: Dead Letters # Every failed indexing attempt is logged by default and made visible in the web-interface. You can enable # the experimental dead letters feature to write every message that was not successfully indexed into the # MongoDB "dead_letters" collection to make sure that you never lose a message. The actual writing of dead # letter should work fine already but it is not heavily tested yet and will get more features in future # releases. dead_letters_enabled = false # How many seconds to wait between marking node as DEAD for possible load balancers and starting the actual # shutdown process. Set to 0 if you have no status checking load balancers in front. lb_recognition_period_seconds = 3 # Every message is matched against the configured streams and it can happen that a stream contains rules which # take an unusual amount of time to run, for example if its using regular expressions that perform excessive backtracking. # This will impact the processing of the entire server. To keep such misbehaving stream rules from impacting other # streams, Graylog limits the execution time for each stream. # The default values are noted below, the timeout is in milliseconds. # If the stream matching for one stream took longer than the timeout value, and this happened more than "max_faults" times # that stream is disabled and a notification is shown in the web interface. #stream_processing_timeout = 2000 #stream_processing_max_faults = 3 # Length of the interval in seconds in which the alert conditions for all streams should be checked # and alarms are being sent. #alert_check_interval = 60 # Since 0.21 the graylog2 server supports pluggable output modules. This means a single message can be written to multiple # outputs. The next setting defines the timeout for a single output module, including the default output module where all # messages end up. # # Time in milliseconds to wait for all message outputs to finish writing a single message. #output_module_timeout = 10000 # Time in milliseconds after which a detected stale master node is being rechecked on startup. #stale_master_timeout = 2000 # Time in milliseconds which Graylog is waiting for all threads to stop on shutdown. #shutdown_timeout = 30000 # MongoDB connection string # See http://docs.mongodb.org/manual/reference/connection-string/ for details # Django : 2015-12-28 # default: mongodb_uri = mongodb://localhost/graylog2 mongodb_uri = mongodb://graylog-user:R7xAmcKezZ2C0v3mtaXCJjA7Nf@127.0.0.1:27017/graylog # Authenticate against the MongoDB server #mongodb_uri = mongodb://grayloguser:secret@localhost:27017/graylog2 # Use a replica set instead of a single host #mongodb_uri = mongodb://grayloguser:secret@localhost:27017,localhost:27018,localhost:27019/graylog2 # Increase this value according to the maximum connections your MongoDB server can handle from a single client # if you encounter MongoDB connection problems. mongodb_max_connections = 100 # Number of threads allowed to be blocked by MongoDB connections multiplier. Default: 5 # If mongodb_max_connections is 100, and mongodb_threads_allowed_to_block_multiplier is 5, # then 500 threads can block. More than that and an exception will be thrown. # http://api.mongodb.org/java/current/com/mongodb/MongoOptions.html#threadsAllowedToBlockForConnectionMultiplier mongodb_threads_allowed_to_block_multiplier = 5 # Drools Rule File (Use to rewrite incoming log messages) # See: https://www.graylog.org/documentation/general/rewriting/ #rules_file = /etc/graylog/server/rules.drl # Email transport #transport_email_enabled = false #transport_email_hostname = mail.example.com #transport_email_port = 587 #transport_email_use_auth = true #transport_email_use_tls = true #transport_email_use_ssl = true #transport_email_auth_username = you@example.com #transport_email_auth_password = secret #transport_email_subject_prefix = [graylog2] #transport_email_from_email = graylog2@example.com # # Django : 2015-12-28 # default: unset transport_email_enabled = true transport_email_hostname = smtp.dmz.nausch.org transport_email_port = 25 transport_email_use_auth = false transport_email_use_tls = false transport_email_use_ssl = false transport_email_auth_username = graylog-admin@nausch.org transport_email_auth_password = 6zmNsgdrD4x1! transport_email_subject_prefix = [graylog] transport_email_from_email = graylog-admin@nausch.org # Specify and uncomment this if you want to include links to the stream in your stream alert mails. # This should define the fully qualified base url to your web interface exactly the same way as it is accessed by your users. #transport_email_web_interface_url = https://graylog2.example.com # Django : 2015-12-28 # default: transport_email_web_interface_url = https://graylog2.example.com transport_email_web_interface_url = https://panopticon.nausch.org # The default connect timeout for outgoing HTTP connections. # Values must be a positive duration (and between 1 and 2147483647 when converted to milliseconds). # Default: 5s #http_connect_timeout = 5s # The default read timeout for outgoing HTTP connections. # Values must be a positive duration (and between 1 and 2147483647 when converted to milliseconds). # Default: 10s #http_read_timeout = 10s # The default write timeout for outgoing HTTP connections. # Values must be a positive duration (and between 1 and 2147483647 when converted to milliseconds). # Default: 10s #http_write_timeout = 10s # HTTP proxy for outgoing HTTP connections #http_proxy_uri = # Disable the optimization of Elasticsearch indices after index cycling. This may take some load from Elasticsearch # on heavily used systems with large indices, but it will decrease search performance. The default is to optimize # cycled indices. #disable_index_optimization = true # Optimize the index down to <= index_optimization_max_num_segments. A higher number may take some load from Elasticsearch # on heavily used systems with large indices, but it will decrease search performance. The default is 1. #index_optimization_max_num_segments = 1 # The threshold of the garbage collection runs. If GC runs take longer than this threshold, a system notification # will be generated to warn the administrator about possible problems with the system. Default is 1 second. #gc_warning_threshold = 1s # Connection timeout for a configured LDAP server (e. g. ActiveDirectory) in milliseconds. #ldap_connection_timeout = 2000 # Enable collection of Graylog-related metrics into MongoDB # WARNING: This will add *a lot* of data into your MongoDB database on a regular interval (1 second)! # DEPRECATED: This setting and the respective feature will be removed in a future version of Graylog. #enable_metrics_collection = false # Disable the use of SIGAR for collecting system stats #disable_sigar = false # Amount of time of inactivity after which collectors are flagged as inactive (Default: 1 minute) #collector_inactive_threshold = 1m # Amount of time after which inactive collectors are purged (Default: 14 days) #collector_expiration_threshold = 14d # The default cache time for dashboard widgets. (Default: 10 seconds, minimum: 1 second) #dashboard_widget_default_cache_time = 10s # Automatically load content packs in "content_packs_dir" on the first start of Graylog. #content_packs_loader_enabled = true # The directory which contains content packs which should be loaded on the first start of Graylog. content_packs_dir = /usr/share/graylog-server/contentpacks # A comma-separated list of content packs (files in "content_packs_dir") which should be applied on # the first start of Graylog. content_packs_auto_load = grok-patterns.json
Start des Daemon
Unsere Konfigurationsänderungen werden mit Hilfe von mongo der MongoDB Shell vorgenommen. Dieses JavaScript stellt die Benutzerschnittstelle zum eigentlichen MongoDN-Daemon zur Verfügung. Damit sich der Client mit dem Server auch verbinden kann, muss der Server natürlich laufen; wir starten also nun unsere NoSQL-Datenbank mit folgendem Befehl.
# systemctl start graylog-server.service
Den Serverstatus können wir wie folgt abfragen.
# systemctl status graylog-server.service
● graylog-server.service - Graylog server Loaded: loaded (/usr/lib/systemd/system/graylog-server.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2015-12-28 14:27:40 CET; 6s ago Docs: http://docs.graylog.org/ Main PID: 5057 (graylog-server) CGroup: /system.slice/graylog-server.service ├─5057 /bin/sh /usr/share/graylog-server/bin/graylog-server └─5058 /usr/bin/java -Xms1g -Xmx1g -XX:NewRatio=1 -server -XX:+ResizeTLAB -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:+CMSClassUnloadingEnabled -XX:+UsePa... Dec 28 14:27:40 vml000117.dmz.nausch.org systemd[1]: Started Graylog server. Dec 28 14:27:40 vml000117.dmz.nausch.org systemd[1]: Starting Graylog server...
Der erfolgreiche Start des Servers wird auch in dessen Logdatei protokolliert.
# /var/log/elasticsearch/elasticsearch.log
Dec 28 14:27:40 vml000117.dmz.nausch.org systemd[1]: Started Graylog server. Dec 28 14:27:40 vml000117.dmz.nausch.org systemd[1]: Starting Graylog server... [root@vml000117 yum.repos.d]# tailf /var/log/graylog-server/server.log 2015-12-28T14:27:55.595+01:00 INFO [discovery] [vml000117] graylog/j4zrCy-gQpqKTAMqM_XGkg 2015-12-28T14:27:55.609+01:00 INFO [RestApiService] Enabling CORS for REST API 2015-12-28T14:27:58.627+01:00 WARN [discovery] [vml000117] waited for 3s and no initial state was set by the discovery 2015-12-28T14:27:58.627+01:00 INFO [node] [vml000117] started 2015-12-28T14:27:59.138+01:00 INFO [service] [vml000117] detected_master [vml000117][EdAnadZuTiOjxFR7_Kvdrg][vml000117.dmz.nausch.org][inet[/10.0.0.117:9300]], added {[vml000117][EdAnadZuTiOjxFR7_Kvdrg][vml000117.dmz.nausch.org][inet[/10.0.0.117:9300]],}, reason: zen-disco-receive(from master [[vml000117][EdAnadZuTiOjxFR7_Kvdrg][vml000117.dmz.nausch.org][inet[/10.0.0.117:9300]]]) 2015-12-28T14:28:05.324+01:00 INFO [IndexRotationThread] Deflector index <graylog_1> should be rotated, Pointing deflector to new index now! 2015-12-28T14:28:05.324+01:00 INFO [Deflector] Cycling deflector to next index now. 2015-12-28T14:28:05.340+01:00 INFO [Deflector] Cycling from <graylog_1> to <graylog_2> 2015-12-28T14:28:05.340+01:00 INFO [Deflector] Creating index target <graylog_2>... 2015-12-28T14:28:06.218+01:00 INFO [Deflector] Waiting for index allocation of <graylog_2> 2015-12-28T14:28:06.335+01:00 INFO [Deflector] Done! 2015-12-28T14:28:06.335+01:00 INFO [Deflector] Pointing deflector to new target index.... 2015-12-28T14:28:06.531+01:00 INFO [SystemJobManager] Submitted SystemJob <d4502600-ad66-11e5-8de7-5254005fa52f> [org.graylog2.indexer.ranges.CreateNewSingleIndexRangeJob] 2015-12-28T14:28:06.537+01:00 INFO [CreateNewSingleIndexRangeJob] Calculating ranges for index graylog_1. 2015-12-28T14:28:06.610+01:00 INFO [SystemJobManager] Submitted SystemJob <d4557d30-ad66-11e5-8de7-5254005fa52f> [org.graylog2.indexer.SetIndexReadOnlyJob] 2015-12-28T14:28:06.658+01:00 INFO [SystemJobManager] Submitted SystemJob <d461b230-ad66-11e5-8de7-5254005fa52f> [org.graylog2.indexer.ranges.CreateNewSingleIndexRangeJob] 2015-12-28T14:28:06.658+01:00 INFO [Deflector] Done! 2015-12-28T14:28:06.618+01:00 INFO [CreateNewSingleIndexRangeJob] Calculating ranges for index graylog_2. 2015-12-28T14:28:06.720+01:00 INFO [MongoIndexRangeService] Calculated range of [graylog_1] in [182ms]. 2015-12-28T14:28:06.807+01:00 INFO [CreateNewSingleIndexRangeJob] Created ranges for index graylog_1. 2015-12-28T14:28:06.807+01:00 INFO [SystemJobManager] SystemJob <d4502600-ad66-11e5-8de7-5254005fa52f> [org.graylog2.indexer.ranges.CreateNewSingleIndexRangeJob] finished in 269ms. 2015-12-28T14:28:06.879+01:00 INFO [MongoIndexRangeService] Calculated range of [graylog_2] in [180ms]. 2015-12-28T14:28:06.930+01:00 INFO [CreateNewSingleIndexRangeJob] Created ranges for index graylog_2. 2015-12-28T14:28:06.931+01:00 INFO [SystemJobManager] SystemJob <d461b230-ad66-11e5-8de7-5254005fa52f> [org.graylog2.indexer.ranges.CreateNewSingleIndexRangeJob] finished in 312ms. 2015-12-28T14:28:08.315+01:00 INFO [RestApiService] Adding security context factory: <org.graylog2.security.ShiroSecurityContextFactory@79ffbf1a> 2015-12-28T14:28:08.354+01:00 INFO [RestApiService] Started REST API at <http://127.0.0.1:12900/> 2015-12-28T14:28:08.355+01:00 INFO [ServiceManagerListener] Services are healthy 2015-12-28T14:28:08.357+01:00 INFO [ServerBootstrap] Services started, startup times in ms: {InputSetupService [RUNNING]=5, OutputSetupService [RUNNING]=32, BufferSynchronizerService [RUNNING]=33, MetricsReporterService [RUNNING]=36, JournalReader [RUNNING]=45, KafkaJournal [RUNNING]=45, PeriodicalsService [RUNNING]=304, IndexerSetupService [RUNNING]=4286, RestApiService [RUNNING]=13364} 2015-12-28T14:28:08.360+01:00 INFO [ServerBootstrap] Graylog server up and running. 2015-12-28T14:28:08.361+01:00 INFO [InputSetupService] Triggering launching persisted inputs, node transitioned from Uninitialized [LB:DEAD] to Running [LB:ALIVE]
automatischer Start des Daemon
Damit der Daemon beim Hochfahren unseres Servers automatisch gestartet wird, nutzen wir folgenden Befehl.
# systemctl enable graylog-server.service
Created symlink from /etc/systemd/system/multi-user.target.wants/graylog-server.service to /usr/lib/systemd/system/graylog-server.service.
Wollen wir wissen, ob die Autostartfunktion bereits gesetzt ist, verwenden wir diesen Aufruf.
# systemctl is-enabled graylog-server.service
enabled
graylog-web
Die Konfiguration des graylog-server Daemons haben wir im vorherigen Kapitel erfolgreich abgeschlossen. Was nun noch fehlt, ist die graylog-web GUI. Die Installation des zugehörigen RPM-Paketes graylog-web hatten wir bereits im Abschnitt Installation von graylog erledigt.
/etc/sysconfig/graylog-web
Zunächst binden wir den Web-Server auf loclahost unseres Syslog-Hosts.
# vim /etc/sysconfig/graylog-web
- /etc/sysconfig/graylog-web
# HTTP server settings. # Django : 2015-12-28 # default: GRAYLOG_WEB_HTTP_ADDRESS="0.0.0.0" GRAYLOG_WEB_HTTP_ADDRESS="10.0.0.117" GRAYLOG_WEB_HTTP_PORT="9000" # Might be used to adjust the Java heap size. (i.e. "-Xms1024m -Xmx2048m") GRAYLOG_WEB_JAVA_OPTS="" # Pass some extra args to graylog-web. (i.e. "-d" to enable debug mode or "-java-home /usr/lib/jvm/java-1.8.0") GRAYLOG_WEB_ARGS="" # Program that will be used to wrap the graylog-web command. Useful to # support programs like authbind. GRAYLOG_COMMAND_WRAPPER=""
Apache Reverse-Proxy
Da der graylog-web-Daemon ohne Root-Rechte gestartet wird, können wir nur unprivilegierte Ports (Ports größer als 1024) definieren. Da wir aber die Graylog-Web-GUI auch von außen, über einen TLS geschützten Transportkanal ansprechen wollen, nutzen wir einen Apache-vHOST als Reverse-Proxy.
Dazu legen wir uns folgende vHOST-Datei an.
# vim /etc/httpd/conf.d/graylog.conf
- /etc/httpd/conf.d/graylog.conf
# # Django : 2015-12-28 # vHost graylog # <VirtualHost 10.0.0.117:80> ServerAdmin webmaster@nausch.org ServerName graylog.nausch.org RewriteEngine on RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} # Welche Logdateien sollen beschrieben werden CustomLog logs/graylog_access.log combined ErrorLog logs/graylog_error.log </VirtualHost> <VirtualHost 10.0.0.117:443> ServerAdmin webmaster@nausch.org ServerName graylog.nausch.org ServerPath / # Wer soll Zugriff auf die Webseite(n) bekommen? <Proxy *> Options +FollowSymLinks +Multiviews -Indexes AllowOverride None AuthType Basic AuthName "Fuer den Zugriff auf den Webserver bitte Anmeldedaten eingeben!" AuthBasicProvider ldap AuthLDAPUrl ldaps://openldap.dmz.nausch.org:636/ou=People,dc=nausch,dc=org?uid AuthLDAPBindDN cn=Technischer_User,dc=nausch,dc=org AuthLDAPBindPassword "e1n531f!D4xIi57n393I1354u!" AuthLDAPBindAuthoritative on Require ldap-user django icinga2 </Proxy> # Welcher Inhalt soll angezeigt bzw. auf welchen Server sollen die HTTP-Requests weitergeleitet werden? ProxyRequests Off ProxyPreserveHost On ProxyPass / http://127.0.0.1:9000/ ProxyPassReverse / http://127.0.0.1:9000/ # Welche Logdateien sollen beschrieben werden CustomLog logs/graylog_access.log combined ErrorLog logs/graylog_error.log # Absicherung der Übertragung mit Hilfe von TLS # Konfiguration bei Verwendung von mod_gnutls <IfModule !mod_ssl.c> <IfModule mod_gnutls.c> # Django : 2015-10-29 - TLS-Verschlüsselung mit Hilfe von mod_gnutls GnuTLSEnable on # Definition der anzubietenden Protokolle und Ciphers GnuTLSPriorities PFS:-VERS-TLS-ALL:+VERS-TLS1.2:-ARCFOUR-128:+COMP-NULL:+CURVE-SECP384R1:+CURVE-SECP521R1 # Schlüsseldatei, mit der der CSR erstellt wurde GnuTLSKeyFile /etc/pki/tls/private/graylog.nausch.org.serverkey.pem # Zertifikatsdatei inkl. ggf. notwendiger Zwischen- und Root-Zertifikaten # 1) Server-Zertifikat, 2) Intermediate-Root-Zertifikat und 3) Root-Zertifikat der CA GnuTLSCertificateFile /etc/pki/tls/certs/graylog.nausch.org.certificatechain_150612.pem # Definition der Schlüssellänge für DHE und ECDHE # DHE Schlüssel mit einer Schlüssellänge von 4096 Bit verwenden; dieser wird 1x pro Tag via cronjob # (/etc/cron.daily/edh_keygen) neu generiert und der Neustart des nginx-Daemon veranlasst! GnuTLSDHFile /etc/pki/tls/private/dh_4096.pem # Session-Tickets für Clients nicht anbieten (dieser könnte versuchen über Tickets die Session zu cachen). GnuTLSSessionTickets off </IfModule> </IfModule> # Konfiguration bei Verwendung von mod_ssl <IfModule mod_ssl.c> <IfModule !mod_gnutls.c> # Django : 2015-10-04 - TLS-Verschlüsselung mit Hilfe von mod_ssl SSLEngine on # Definition der anzubietenden Protokolle SSLProtocol All -SSLv2 -SSLv3 # Definition der Cipher SSLCipherSuite "AES256+EECDH +AEAD" # Schlüsseldatei, mit der der CSR erstellt wurde SSLCertificateKeyFile /etc/pki/tls/private/graylog.nausch.org.serverkey.pem # Zertifikatsdatei, die von der CA signiert wurde SSLCertificateFile /etc/pki/tls/certs/graylog.nausch.org.certificate_150612.pem # Zertifikatsdatei des bzw. der Intermediate-Zertifikate(s) SSLCertificateChainFile /etc/pki/tls/certs/CAcert_class3.pem # Änderung der Cipherorder der Clienets verneinen SSLHonorCipherOrder on # TLS 1.0 Kompremmierung deaktivieren (CRIME attacks) SSLCompression off </IfModule> </IfModule> # special stuff ### # HTTP Strict Transport Security (HSTS), bei dem der Server dem Client im HTTP-Header mitteilt, # dass dieser nur noch verschlüsselt mit dem Server kommunizieren soll. Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" # This header enables the Cross-site scripting (XSS) filter built into most recent web browsers. # It's usually enabled by default anyway, so the role of this header is to re-enable the filter for # this particular website if it was disabled by the user. # https://www.owasp.org/index.php/List_of_useful_HTTP_headers Header set X-XSS-Protection "1; mode=block" # when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header, # to disable content-type sniffing on some browsers. # https://www.owasp.org/index.php/List_of_useful_HTTP_headers # currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx # http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx # 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020 Header set X-Content-Type-Options nosniff # config to don't allow the browser to render the page inside an frame or iframe # and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking # if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with ALLOW-FROM uri # https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options header set X-Frame-Options SAMEORIGIN </VirtualHost>
Bevor wir die Änderungen am Apache Webseerver scharf schalten, testen wir unsere Konfiguration noch auf syntaktische Fehler.
# apachectl -t
Syntax OK
Ist alles O.K. brauchen wir nur noch den Apache-Webserver einmal durchstarten.
# systemctl restart httpd.service
/etc/graylog/web/web.conf
Die installationsspezifische kundenindividuelle Konfiguration der graylog-web GUI wird über dessen Konfigurationsdatei /etc/graylog/web/web.conf vorgenommen.
Wie schon bei der Konfiguration des graylog-servers erstellen wir uns, vor der Bearbeitung der Konfigurationsdatei, noch einen Passwort-Hash, mit dem die Nutzerpassworte verschlüsselt werden. Diesen hash-Wert erstellen wir wie folgt:
# pwgen -N 1 -s 128
KM2OhCgRuTJe9f7bOr0uOtGcX45TB5kmF4L4Ty44bRUlu1y2qh0eDbs613Bv4QFk0ftGzuASpSW5DDBqpSKIlcdI39WdVHBSo33AoPZgKiABd7G7FduhKIMZVjiE7lod
Diese beiden Werte hinterlegen wir nun in der Konfigurationsdatei unseres graylog-web-Daemon und passen anschließend die Konfigurationsoptionen unserer Umgebung an. Änderungen an den Default-Werten sind mit Django : <Zeitstempel> gekennzeichnet
# vim /etc/graylog/web/web.conf
- /etc/graylog/web/web.conf
# graylog2-server REST URIs (one or more, comma separated) For example: "http://127.0.0.1:12900/,http://127.0.0.1:12910/" # Django : 2015-12-28 # default: graylog2-server.uris="" graylog2-server.uris="http://127.0.0.1:12900/" # Learn how to configure custom logging in the documentation: # http://docs.graylog.org/en/latest/pages/installation.html#manual-setup-graylog-web-interface-on-linux # Secret key # ~~~~~ # The secret key is used to secure cryptographics functions. Set this to a long and randomly generated string. # If you deploy your application to several instances be sure to use the same key! # Generate for example with: pwgen -N 1 -s 96 # Django : 2015-12-28 # default: application.secret="" application.secret="KM2OhCgRuTJe9f7bOr0uOtGcX45TB5kmF4L4Ty44bRUlu1y2qh0eDbs613Bv4QFk0ftGzuASpSW5DDBqpSKIlcdI39WdVHBSo33AoPZgKiABd7G7FduhKIMZVjiE7lod" # Web interface timezone # Graylog stores all timestamps in UTC. To properly display times, set the default timezone of the interface. # If you leave this out, Graylog will pick your system default as the timezone. Usually you will want to configure it explicitly. # timezone="Europe/Berlin" # Django : 2015-12-28 # default: unset timezone="Europe/Berlin" # Message field limit # Your web interface can cause high load in your browser when you have a lot of different message fields. The default # limit of message fields is 100. Set it to 0 if you always want to get all fields. They are for example used in the # search result sidebar or for autocompletion of field names. field_list_limit=100 # Use this to run Graylog with a path prefix #application.context=/graylog2 # You usually do not want to change this. application.global=lib.Global # Global timeout for communication with Graylog server nodes; default: 5s #timeout.DEFAULT=5s # Accept any server certificate without checking for validity; required if using self-signed certificates. # Default: true # graylog2.client.accept-any-certificate=true
Start des Daemon
Nun ist es an der Zeit den die Web-GUI graylog-web zu starten.
# systemctl start graylog-web.service
Den Serverstatus können wir wie folgt abfragen.
# systemctl status graylog-web.service
● graylog-web.service - Graylog web interface Loaded: loaded (/usr/lib/systemd/system/graylog-web.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2015-12-28 15:21:52 CET; 11s ago Docs: http://docs.graylog.org/ Main PID: 8767 (graylog-web) CGroup: /system.slice/graylog-web.service ├─8767 /bin/sh /usr/share/graylog-web/bin/graylog-web └─8768 java -Xms1024m -Xmx1024m -XX:ReservedCodeCacheSize=128m -Dconfig.file=/etc/graylog/web/web.conf -Dlogger.file=/etc/graylog/web/logback.xml -Dpidfile.path=/dev/... Dec 28 15:21:52 vml000117.dmz.nausch.org systemd[1]: Started Graylog web interface. Dec 28 15:21:52 vml000117.dmz.nausch.org systemd[1]: Starting Graylog web interface... Dec 28 15:21:53 vml000117.dmz.nausch.org graylog-web[8767]: Play server process ID is 8768
Der erfolgreiche Start des Servers wird auch in dessen Logdatei protokolliert.
# /var/log/graylog-web/application.log
2015-12-28T15:21:56.752+01:00 - [INFO] - from play in main Application started (Prod) 2015-12-28T15:21:56.812+01:00 - [INFO] - from play in main Listening for HTTP on /10.0.0.117:9000
automatischer Start des Daemon
Damit der Daemon beim Hochfahren unseres Servers automatisch gestartet wird, nutzen wir folgenden Befehl.
# systemctl enable graylog-web.service
Created symlink from /etc/systemd/system/multi-user.target.wants/graylog-web.service to /usr/lib/systemd/system/graylog-web.service.
Wollen wir wissen, ob die Autostartfunktion bereits gesetzt ist, verwenden wir diesen Aufruf.
# systemctl is-enabled graylog-web.service
enabled
Paketfilter/Firewall
graylog-web
Unter CentOS 7 wird als Standard-Firewall die dynamische firewalld verwendet. Ein großer Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.
Laufen der Apache-Reverse-Proxy und der Graylog-Servers nicht auf dem gleichen Host, benötigen wir noch eine Firewall-Definition die diesen Kommunkikationsweg definiert. Dabei soll in unserem Konfigurationsbeispiel die Source-IP die 10.0.0.97 und die Destination-IP die Ip-Adresse 10.0.0.117 sein.
Mit Hilfe des Programms firewall-cmd legen wir nun eine permanente Regel in der Zone public, dies entspricht in unserem Beispiel das Netzwerk-Interface eth0 mit der IP 10.0.0.117 an. Als Source-IP geben wir die beiden IP-Adressen der Apache-Webservers, also die 10.0.0.117 und 10.0.0.97 an. Genug der Vorrede, mit nachfolgendem Befehl wird diese restriktive Regel angelegt.
# firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.0.0.97/32" port protocol="tcp" port="9000" destination address="10.0.0.117/32" accept"
success
Zum Aktivieren brauchen wir nun nur einen reload des Firewall-Daemon vornehmen.
# firewall-cmd --reload
Fragen wir nun den Regelsatz unserer iptables-basieten Firewall ab, finden wir in der Chain IN_public_allow unsere aktivierten Regeln.
# iptables -nvL IN_public_allow
Chain IN_public_allow (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 10.0.0.97 10.0.0.117 tcp dpt:9000 ctstate NEW
syslog (Port 514)
Der graylog-server Daemon läuft mit den Rechten des Users graylog; daher kann der Dienst graylog-server nur Ports >1024 binden.
# ps aux | grep graylog-server
graylog 1382 0.0 0.0 113116 1404 ? Ss 2015 0:00 /bin/sh /usr/share/graylog-server/bin/graylog-server graylog 1391 3.4 17.4 3875072 1396880 ? Sl 2015 190:29 /usr/bin/java -Xms1g -Xmx1g -XX:NewRatio=1 -server -XX:+ResizeTLAB -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:-OmitStackTraceInFastThrow -jar -Dlog4j.configuration=file:///etc/graylog/server/log4j.xml -Djava.library.path=/usr/share/graylog-server/lib/sigar -Dgraylog2.installation_source=rpm /usr/share/graylog-server/graylog.jar server -f /etc/graylog/server/server.conf -np
Somit können wir keine bei der Definition von Eingangskanälen (Inputs) keine dieser privilegierte Ports direkt ansprechen. Bei vielen Netzwerkgeräten, wie Router, Switche oder Telefone kann man bei der Definition des Syslog-Dienstes nur den Namen bzw. IP-Adresse des Zielservers angeben, nicht aber die den vordefinierten Port 514.
Da wir aber aus Sicherheitsgründen keinenfalls den graylog Daemon mit root-Rechten wollen, müssen wir uns anders behelfen. Zunächst definieren wir uns einen input-Kanal und weisen diesem dem Port 10514.
Nun werden wir mit Hilfe von iptables den Port 514 auf den zuvor definierten 10514 mappen. Dazu brauchen wir zwei Dinge:
- Masquerading
Mit Hilfe des zugehörigen Kernel-Moduls werden ankommende Pakete auf Port 514 auf Port 10514 „umgerouted“ und ausgehende Pakte von Port 10514 wiederum als Absendeport 514 in den UDP/TCP-Paketen umgeschrieben. Die zugehörige firewalld-Regel zum Aktivieren von Masquerading lautet:# firewall-cmd --permanent --zone=public --add-masquerade
success
- DNAT-Regel
Aus Sicht unseres iptables-Filter wollen wir das Pakete auf den Ziel-Port 514 den der Client verwendet hat, auf auf den Port 10514 unseres graylog INPUTs umschreiben; dazu benötigen wir folgende Regel:# firewall-cmd --permanent --zone=public --add-forward-port=port=514:proto=udp:toport=10514
success
Zum Schluß führen wir nun noch einen Reload des Daemon firewalld durch.
# firewall-cmd --reload
success
Wenn wir jetzt einen Blick in die definierten INPUTs unseres graylog-Servers werfen, werden wir die angekommenen und verarbeiteten syslog-Meldungen unserer „syslog Port 514 only“-Geräte sehen.
LOGIN
Die Web-GUI unseres graylog-Servers erreichen wir über die URL, die wir bei der Konfiguration des Apache Reverse-Proxy definiert hatten: https://graylog.nausch.org
Nach erfolgter Erstanmeldung befinden wir uns im „“Getting Started„ Fenster. Dort finden wir auch schon ein paar Online-Hilfe Punkte
rsyslog
Nachdem wir unseren graylog-Server erfolgreich vorbereitet haben, werden wir nun unsere Linux-Hosts so konfigurieren, dass diese ihre syslog-Meldungen zu unserem zentralem syslog-/graylog-Server senden.
Das Weiterleiten der Syslogmeldungen ist nicht sonderlich schwer zu konfigurieren. Das Wichtigste das es zu beachten gibt, ist, dass die Meldungen gemäß dem RFC 5424 formatiert werden.
UDP
Im ersten Konfigurationsbeispiel wollen wir die Syslog-Meldungen an den Port 514 per UDP1) an unseren graylog-Server senden. Dazu tragen wir am Ende der Konfigurationsdatei des rsyslog-Daemon folgende Zeile ein.
# vim /etc/rsyslog.conf
# ### begin forwarding rule ### # The statement between the begin ... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # # Django : 2015-06-12 $template GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" *.* @10.0.0.117:514;GRAYLOGRFC5424 # # ### end of the forwarding rule ###
Zum Aktivieren der Konfigurationsänderung starten wir den rsyslog-Daemon einmal durch.
# systemctl restart rsyslog.service
TCP
Möchte man die die Syslog-Meldungen an den Port 514 per TCP2) an den graylog-Server senden, unterscheidet sich die Konfiguration nur unwesentlich. In der Konfigurationszeile wird statt einem @ zwei @@ angegeben. Am Ende der Konfigurationsdatei des rsyslog-Daemon tragen wir folgende Zeile ein.
# vim /etc/rsyslog.conf
# ### begin forwarding rule ### # The statement between the begin ... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # # Django : 2015-06-12 $template GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" *.* @@10.0.0.117:514;GRAYLOGRFC5424 # # ### end of the forwarding rule ###
Zum Aktivieren der Konfigurationsänderung starten wir den rsyslog-Daemon einmal durch.
# systemctl restart rsyslog.service
TLS-Absicherung des rsyslog-/graylog-Verkehrs
An zwei wesentlichen Stellen läuft in unserem Konfigurationsbeispiel noch völlig ungeschützt ab. Der erste Punkt den es zu bemängeln gilt, ist die Autorisierung der Datenquellen; d.h. jeder beliebige Client, der sich mit unserem Netz verbindet kann Daten an unseren graylog-Server schicken und diesen im schlimmsten Fall mit Datenmüll überfluten. Der zweite Punkt ist die unverschlüsselte Übertragung der rsyslog Daten. Schützenswerte Daten könnten also im Zweifelsfall ebenso mitgeschnitten wie auch manipuliert werden.
Zur Lösung dieser beiden unstrittigen Schwachstellen werden wir uns nun mit der Absicherung durch TLS3) näher beschäftigen. Die für die TLS-Verschlüsselung notwendigen Schlüssel und Zertifikate erstellen wir mittels OpenSSL, einer freien Implementierung von SSL4). SSL oder TLS5) ist ein hybrides Verschlüsselungsprotokoll zur Datenübertragung im Internet. Unter TLS 1.0, 1.1 und 1.2 versteht man die standardisierten Weiterentwicklungen von SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). Dies bedeutet also, SSL wird nun unter dem Namen TLS weiterentwickelt.
OpenSSL
Bei der Standardinstallation unseres Systems wurde in der Regel bereits das Paket openssl installiert. Ein kurzer Blick in die RPM-Datenbank schafft hierzu Gewissheit.
# yum list openssl
Installed Packages openssl.x86_64 1:1.0.1e-51.el7_2.1
Sollte das Paket noch fehlen, installieren wir dies einfach via:
# yum install openssl
Was uns das Paket openssl alles mitbringt und wohin die Programme und Konfigurationsdateien kopiert werden, offenbart uns das System wie folgt.
# rpm -qil openssl
Name : openssl Epoch : 1 Version : 1.0.1e Release : 51.el7_2.1 Architecture: x86_64 Install Date: Tue 15 Dec 2015 09:59:48 AM CET Group : System Environment/Libraries Size : 1611101 License : OpenSSL Signature : RSA/SHA256, Mon 14 Dec 2015 12:25:06 PM CET, Key ID 24c6a8a7f4a80eb5 Source RPM : openssl-1.0.1e-51.el7_2.1.src.rpm Build Date : Mon 14 Dec 2015 06:19:50 AM CET Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.openssl.org/ Summary : Utilities from the general purpose cryptography library with TLS implementation Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. /etc/pki/CA /etc/pki/CA/certs /etc/pki/CA/crl /etc/pki/CA/newcerts /etc/pki/CA/private /etc/pki/tls/certs/Makefile /etc/pki/tls/certs/make-dummy-cert /etc/pki/tls/certs/renew-dummy-cert /etc/pki/tls/misc/CA /etc/pki/tls/misc/c_hash /etc/pki/tls/misc/c_info /etc/pki/tls/misc/c_issuer /etc/pki/tls/misc/c_name /usr/bin/openssl /usr/share/doc/openssl-1.0.1e /usr/share/doc/openssl-1.0.1e/CHANGES /usr/share/doc/openssl-1.0.1e/FAQ /usr/share/doc/openssl-1.0.1e/INSTALL /usr/share/doc/openssl-1.0.1e/LICENSE /usr/share/doc/openssl-1.0.1e/NEWS /usr/share/doc/openssl-1.0.1e/README /usr/share/doc/openssl-1.0.1e/README.FIPS /usr/share/doc/openssl-1.0.1e/c-indentation.el /usr/share/doc/openssl-1.0.1e/openssl.txt /usr/share/doc/openssl-1.0.1e/openssl_button.gif /usr/share/doc/openssl-1.0.1e/openssl_button.html /usr/share/doc/openssl-1.0.1e/ssleay.txt /usr/share/man/man1/asn1parse.1ssl.gz /usr/share/man/man1/ca.1ssl.gz /usr/share/man/man1/ciphers.1ssl.gz /usr/share/man/man1/cms.1ssl.gz /usr/share/man/man1/crl.1ssl.gz /usr/share/man/man1/crl2pkcs7.1ssl.gz /usr/share/man/man1/dgst.1ssl.gz /usr/share/man/man1/dhparam.1ssl.gz /usr/share/man/man1/dsa.1ssl.gz /usr/share/man/man1/dsaparam.1ssl.gz /usr/share/man/man1/ec.1ssl.gz /usr/share/man/man1/ecparam.1ssl.gz /usr/share/man/man1/enc.1ssl.gz /usr/share/man/man1/errstr.1ssl.gz /usr/share/man/man1/gendsa.1ssl.gz /usr/share/man/man1/genpkey.1ssl.gz /usr/share/man/man1/genrsa.1ssl.gz /usr/share/man/man1/md2.1ssl.gz /usr/share/man/man1/md4.1ssl.gz /usr/share/man/man1/md5.1ssl.gz /usr/share/man/man1/mdc2.1ssl.gz /usr/share/man/man1/nseq.1ssl.gz /usr/share/man/man1/ocsp.1ssl.gz /usr/share/man/man1/openssl.1ssl.gz /usr/share/man/man1/pkcs12.1ssl.gz /usr/share/man/man1/pkcs7.1ssl.gz /usr/share/man/man1/pkcs8.1ssl.gz /usr/share/man/man1/pkey.1ssl.gz /usr/share/man/man1/pkeyparam.1ssl.gz /usr/share/man/man1/pkeyutl.1ssl.gz /usr/share/man/man1/req.1ssl.gz /usr/share/man/man1/ripemd160.1ssl.gz /usr/share/man/man1/rsa.1ssl.gz /usr/share/man/man1/rsautl.1ssl.gz /usr/share/man/man1/s_client.1ssl.gz /usr/share/man/man1/s_server.1ssl.gz /usr/share/man/man1/s_time.1ssl.gz /usr/share/man/man1/sess_id.1ssl.gz /usr/share/man/man1/sha.1ssl.gz /usr/share/man/man1/sha1.1ssl.gz /usr/share/man/man1/smime.1ssl.gz /usr/share/man/man1/speed.1ssl.gz /usr/share/man/man1/spkac.1ssl.gz /usr/share/man/man1/sslpasswd.1ssl.gz /usr/share/man/man1/sslrand.1ssl.gz /usr/share/man/man1/ts.1ssl.gz /usr/share/man/man1/tsget.1ssl.gz /usr/share/man/man1/verify.1ssl.gz /usr/share/man/man1/version.1ssl.gz /usr/share/man/man1/x509.1ssl.gz /usr/share/man/man5/config.5ssl.gz /usr/share/man/man5/openssl.cnf.5ssl.gz /usr/share/man/man5/x509v3_config.5ssl.gz /usr/share/man/man7/des_modes.7ssl.gz
Zertifikatserstellung
Wie bereits erwähnt benötigen wir für die TLS-Verschlüsselung Schlüssel und Zertifikate. Das Schlüsselmaterial werden wir ausschließlich und immer nur auf unserem Server generieren. Die Zertifikate können wir nun auch selbst erstellen, oder von einer externen CA6) beziehen.
Technisch gesehen unterscheiden sich Zertifikate einer „offiziellen“ oder besser gesagt einer kommerziellen CA nicht von Zertifikaten einer eigenen „self signed“ Zertifikaten. Da es sich bei unserem Unterfangen, die rsyslog-Datenübertragung und -Authorisierung von erlaubten Sendern und Empfängern um reine Maschinen zu Maschinen Kommunikation handelt, können wir zur Vereinfachung des ganzen Zertifikatshandlings auf eine eigen CA mit sehr langen Zertifikatslaufzeiten zurückgreifen.
Leider bietet uns weder graylog noch rsyslog so eine komfortable scriptgesteuerte Unterstützung, wie z.B. der ICINGA2 Node Wizard bei der Anbindung Client- zum Master-Node. Wir werden also bei der Erzeugung der folgendenden Stellen selbst Hand anlegen müssen:
- CA
- Serverzertifikat für den graylog-Server
- Clientzertifikate für die rsyslog-Clients
Die jeweils benötigten Arbeitsschritte sind bei allen drei Stellen jeweils die gleichen:
- Generieren eines privaten Schlüssels, den wir hüten wie unseren Augapfel,
- Unterschreiben des CSR mit dem privaten Schlüssel unserer CA8); auch bekannt als Zertifikatsgenerierung.
- Verteilen der erzeugten Zertifikate.
Sowohl bei der Laufzeit des Root-Zertifikates unserer CA wie auch bei den Client- und Server-Zertifikaten orientieren wir uns am Beispiel von ICINGA2 und wählen hier jeweils eine Laufzeit von 30 Jahren. Somit erübrigt sich die laufende Erneuerung der jeweiligen Zertifikate und der damit verbundenen Downtime der Clients und Server.
Root CA - Zertifizierungsstelle
Als erstes werden wir uns nun unsere Zertifizierungsstelle mit besagtem 30-jährigen Root CA Zertifikats erstellen.
Vorbereitung
Anlegen fehlender Dateien:
# echo "00" > /etc/pki/CA/serial
# touch /etc/pki/CA/index.txt
# mkdir /etc/pki/CA/csrs
Somit befindet sich in unserem Pfad /etc/pki/CA nun folgender Inhalt:
# ll /etc/pki/CA
total 4 drwxr-xr-x. 2 root root 6 Dec 14 06:18 certs drwxr-xr-x. 2 root root 6 Dec 14 06:18 crl drwxr-xr-x. 2 root root 3 Jan 3 19:40 csrs -rw-r--r--. 1 root root 0 Jan 3 19:40 index.txt drwxr-xr-x. 2 root root 6 Dec 14 06:18 newcerts drwx------. 2 root root 6 Dec 14 06:18 private -rw-r--r--. 1 root root 3 Jan 3 19:40 serial
privaten Schlüssel und selbstsigniertes Root CA Zertifikat erstellen
Als erstes werden wir uns nun den privaten Schlüssel unserer Root CA generieren, in zugehöriges Zertifikat erzeugen und dieses mit dem privaten Schlüssel der CA unterschreiben; all das passiert bei nachfolgendem Befehlsaufruf. Zur besseren Unterscheidung sind die Eingaben sowohl kursiv und fett gedruckt in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl req -new -x509 -newkey rsa:4096 -sha512 \ -keyout /etc/pki/CA/private/root-ca.key.pem \ -out /etc/pki/CA/certs/root-ca.certifikate.pem -days 10950
Generating a 4096 bit RSA private key ..................................................................................................................................................................++ .......................++ writing new private key to '/etc/pki/CA/private/root-ca.key.pem' Enter PEM pass phrase: des-woas-blos-I-und-sunst-koana! Verifying - Enter PEM pass phrase: des-woas-blos-I-und-sunst-koana! 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) [XX]:DE State or Province Name (full name) []:Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:Zertifizierungsstelle Common Name (eg, your name or your server's hostname) []:graylog CA Email Address []:ca-admin@nausch.org
privaten Schlüssel der Root CA schützen
Damit nun ausschließlich der Benuter root die Schlüsseldatei mit dem privaten Schlüssel unserer CA lesen kann, passen wir die Dateirechte entsprechend an.
# chmod 400 /etc/pki/CA/private/root-ca.key.pem
Root CA Zertifikat ausgeben
Möchten wir den Inhalt unseres Root Ca Zertifikates ausgeben und ansehen, verwenden wir den folgenden openssl-Aufruf.
# openssl x509 -noout -text -in /etc/pki/CA/certs/root-ca.certifikate.pem
Certificate: Data: Version: 3 (0x2) Serial Number: 10930264216988842831 (0x97b01964f2c87b4f) Signature Algorithm: sha512WithRSAEncryption Issuer: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Zertifizierungsstelle, CN=graylog CA/emailAddress=ca-admin@nausch.org Validity Not Before: Jan 3 22:57:12 2016 GMT Not After : Dec 26 22:57:12 2045 GMT Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Zertifizierungsstelle, CN=graylog CA/emailAddress=ca-admin@nausch.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ca:f4:bc:2b:0d:43:6a:63:fc:93:fb:e6:18:91: ed:73:22:3f:da:1c:fb:3a:8e:60:41:e1:33:6e:bf: 0c:8c:33:b2:52:04:50:05:5c:fb:73:d2:23:96:f4: 2a:31:5a:d6:e8:d2:48:47:b6:86:cd:1b:d4:9d:4c: b6:ac:fc:c9:94:fc:dc:8b:ca:50:ac:e4:4d:f2:06: 84:0d:e8:dd:bc:2f:bc:fb:fd:26:c1:19:5e:13:61: b2:37:d3:80:9b:0e:7c:bb:5c:19:69:06:3f:de:02: 8f:69:c1:c0:55:68:01:1a:49:72:a5:a5:8d:93:a7: cc:4a:e5:f8:6f:03:eb:71:22:b6:3f:5e:54:f7:57: 20:5f:5d:80:55:b5:b6:e1:85:ff:93:0e:47:f6:64: a7:3d:84:22:d9:45:f8:f8:01:70:3b:2a:b2:dd:18: 80:65:81:61:66:c2:9d:1a:c5:4b:4c:e0:89:05:28: fe:40:06:00:87:c1:13:ac:ae:dc:7e:fb:00:e7:95: 84:3d:83:e9:7e:48:ae:5a:a5:c0:d6:ae:75:b9:9e: 54:96:4b:8b:86:48:67:9e:b7:31:d0:b0:06:a5:29: 44:08:54:05:48:2c:0d:8d:99:bf:31:59:48:f4:3d: b5:bd:4b:c6:56:d0:59:90:6f:b8:12:97:81:ad:d8: eb:01:f4:41:4c:b3:59:c0:26:67:e9:4b:e5:59:5e: 96:7b:c2:df:ca:96:73:1b:ed:f3:ec:c6:05:12:db: be:67:a0:2a:d2:a7:03:67:c7:6d:b1:35:b3:ea:e5: 2c:65:7e:df:dc:dc:8f:57:86:f9:bc:7a:a5:45:a5: 67:a5:f4:9d:af:7b:af:9a:52:db:ea:8a:c8:be:f0: 50:f6:58:c3:88:28:0f:c4:04:d5:f3:a6:80:03:33: d7:64:d8:d2:83:39:f4:3d:94:1c:f4:68:c1:a8:bf: af:c7:c5:de:e3:85:86:47:ad:a0:47:bf:47:21:b0: 7b:61:9f:a8:05:32:81:0c:7c:54:e6:4b:ad:98:e6: c7:d3:08:50:03:3f:4b:b2:fc:b1:4b:18:5b:e4:b3: 71:be:f8:ca:2e:d4:89:84:b8:32:2b:ac:1f:e1:00: 71:bb:9f:07:95:ac:a8:fc:c5:b5:a8:5a:8f:cd:3d: 5d:a0:d7:2e:34:be:24:41:80:ee:5b:11:13:4e:05: c5:ff:53:ef:31:c2:1f:12:b4:bd:5f:80:0f:80:3d: af:d3:a7:23:17:b9:28:8a:6e:4b:57:33:59:38:f3: ea:f4:30:cc:0e:e8:41:83:eb:8f:88:ea:a2:03:2c: f5:16:0d:ef:b2:97:10:a0:0b:7e:0d:97:e1:0d:d4: 69:4e:97 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: F7:C3:04:70:25:38:2F:02:82:5D:5F:2F:7F:1B:66:97:43:9F:D8:0E X509v3 Authority Key Identifier: keyid:F7:C3:04:70:25:38:2F:02:82:5D:5F:2F:7F:1B:66:97:43:9F:D8:0E X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha512WithRSAEncryption 37:5c:48:19:a0:67:55:3c:e5:f8:74:2e:49:57:0b:fe:ea:d4: f3:82:3d:f5:8b:74:74:1d:ad:a4:ce:00:72:f8:19:19:b7:35: 7f:a1:85:61:b3:11:d1:90:b5:d9:d6:6f:55:04:83:28:05:b9: 0b:09:95:ac:c0:25:0d:17:02:ee:fd:c5:0d:48:12:ce:7c:09: 67:72:6a:47:0c:7b:f4:48:0a:1d:05:6d:78:7a:04:49:50:b7: 2b:fd:37:80:de:be:62:66:3b:b5:1b:52:78:af:b4:16:d6:f9: f9:64:b8:a9:d3:6d:9f:0e:81:67:1f:3a:c5:39:bc:5d:d9:73: f1:8d:9c:da:1e:f4:22:78:28:d6:d2:ef:2a:07:85:57:fc:f8: 9c:ac:b4:2f:51:06:f3:a5:fd:10:7e:fa:26:5e:6a:cd:ba:f1: 03:6c:fb:f1:d9:cd:86:65:32:18:46:ca:24:28:f1:e8:47:d8: d7:30:0c:b7:4a:5d:19:0f:9d:9c:59:40:15:60:1e:53:75:22: d1:99:4e:c1:c7:f0:d5:92:d0:43:8d:2a:9c:8b:a6:5c:18:88: 5a:73:0a:75:f2:b3:46:de:a4:02:0e:12:e3:e7:42:79:b5:c9: 20:a8:da:b2:ca:1e:42:b8:f5:ea:b5:3c:b7:6e:de:15:29:11: 2e:bd:0d:50:93:e5:19:85:b2:7a:f3:48:06:50:7d:ba:d4:f3: 3a:64:35:0b:6c:74:3a:6f:02:c5:7d:4c:2d:78:70:43:f9:4b: 1c:0e:44:1f:fb:91:1e:80:a7:96:2e:ee:04:8f:71:9a:74:a6: 80:28:41:19:b4:b0:46:d0:1d:d0:3c:8f:d3:9d:02:63:7e:5d: 38:f5:b4:29:b9:66:7a:fc:a1:94:24:0d:38:bb:31:f5:1c:cb: d5:13:a2:0d:fa:59:9c:2f:63:68:a9:ee:02:d7:45:68:47:7e: 10:b9:bc:58:75:7e:8f:4c:d8:2f:72:f8:a6:e9:e8:33:d7:1f: 6c:44:35:09:04:f2:96:8c:69:16:a9:f3:7b:50:6d:1a:fc:08: e3:77:3d:3c:c4:5a:45:33:81:25:c8:73:4e:ea:e1:c5:2c:5e: 0c:34:48:9b:7e:ec:fa:b1:82:75:6a:7d:80:5f:07:30:5c:81: 37:db:e1:a2:17:52:31:9b:7f:ce:0b:55:51:b4:e0:03:0d:7c: f6:60:3f:5b:e7:c9:95:17:30:91:6e:96:d6:02:9e:fa:64:8d: 35:0d:dc:32:e1:58:16:e7:2e:67:40:73:76:b4:ad:4e:4c:fa: 78:6f:31:30:7e:7b:ad:4f:10:8f:a5:e3:57:42:fa:04:a9:f6: 59:7d:69:78:92:af:7f:2b
Das Zertifikat im PEM-Format (Base64-kodiertes Zertifikat) können wir uns ganz einfach ausgeben lassen um es so z.B. auf einem Clientrechner abzulegen.
# cat /etc/pki/CA/certs/root-ca.certifikate.pem
-----BEGIN CERTIFICATE----- MIIGEzCCA/ugAwIBAgIJAJewGWTyyHtPMA0GCSqGSIb3DQEBDQUAMIGfMQswCQYD VQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYDVQQHDAhQbGllbmluZzETMBEG A1UECgwKbmF1c2NoLm9yZzEeMBwGA1UECwwVWmVydGlmaXppZXJ1bmdzc3RlbGxl MRMwEQYDVQQDDApncmF5bG9nIENBMSIwIAYJKoZIhvcNAQkBFhNjYS1hZG1pbkBu YXVzY2gub3JnMB4XDTE2MDEwMzIyNTcxMloXDTQ1MTIyNjIyNTcxMlowgZ8xCzAJ BgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAPBgNVBAcMCFBsaWVuaW5nMRMw EQYDVQQKDApuYXVzY2gub3JnMR4wHAYDVQQLDBVaZXJ0aWZpemllcnVuZ3NzdGVs bGUxEzARBgNVBAMMCmdyYXlsb2cgQ0ExIjAgBgkqhkiG9w0BCQEWE2NhLWFkbWlu QG5hdXNjaC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDK9Lwr DUNqY/yT++YYke1zIj/aHPs6jmBB4TNuvwyMM7JSBFAFXPtz0iOW9CoxWtbo0khH tobNG9SdTLas/MmU/NyLylCs5E3yBoQN6N28L7z7/SbBGV4TYbI304CbDny7XBlp Bj/eAo9pwcBVaAEaSXKlpY2Tp8xK5fhvA+txIrY/XlT3VyBfXYBVtbbhhf+TDkf2 ZKc9hCLZRfj4AXA7KrLdGIBlgWFmwp0axUtM4IkFKP5ABgCHwROsrtx++wDnlYQ9 g+l+SK5apcDWrnW5nlSWS4uGSGeetzHQsAalKUQIVAVILA2Nmb8xWUj0PbW9S8ZW 0FmQb7gSl4Gt2OsB9EFMs1nAJmfpS+VZXpZ7wt/KlnMb7fPsxgUS275noCrSpwNn x22xNbPq5Sxlft/c3I9Xhvm8eqVFpWel9J2ve6+aUtvqisi+8FD2WMOIKA/EBNXz poADM9dk2NKDOfQ9lBz0aMGov6/Hxd7jhYZHraBHv0chsHthn6gFMoEMfFTmS62Y 5sfTCFADP0uy/LFLGFvks3G++Mou1ImEuDIrrB/hAHG7nweVrKj8xbWoWo/NPV2g 1y40viRBgO5bERNOBcX/U+8xwh8StL1fgA+APa/TpyMXuSiKbktXM1k48+r0MMwO 6EGD64+I6qIDLPUWDe+ylxCgC34Nl+EN1GlOlwIDAQABo1AwTjAdBgNVHQ4EFgQU 98MEcCU4LwKCXV8vfxtml0Of2A4wHwYDVR0jBBgwFoAU98MEcCU4LwKCXV8vfxtm l0Of2A4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOCAgEAN1xIGaBnVTzl +HQuSVcL/urU84I99Yt0dB2tpM4AcvgZGbc1f6GFYbMR0ZC12dZvVQSDKAW5CwmV rMAlDRcC7v3FDUgSznwJZ3JqRwx79EgKHQVteHoESVC3K/03gN6+YmY7tRtSeK+0 Ftb5+WS4qdNtnw6BZx86xTm8Xdlz8Y2c2h70Ingo1tLvKgeFV/z4nKy0L1EG86X9 EH76Jl5qzbrxA2z78dnNhmUyGEbKJCjx6EfY1zAMt0pdGQ+dnFlAFWAeU3Ui0ZlO wcfw1ZLQQ40qnIumXBiIWnMKdfKzRt6kAg4S4+dCebXJIKjassoeQrj16rU8t27e FSkRLr0NUJPlGYWyevNIBlB9utTzOmQ1C2x0Om8CxX1MLXhwQ/lLHA5EH/uRHoCn li7uBI9xmnSmgChBGbSwRtAd0DyP050CY35dOPW0KblmevyhlCQNOLsx9RzL1ROi DfpZnC9jaKnuAtdFaEd+ELm8WHV+j0zYL3L4punoM9cfbEQ1CQTyloxpFqnze1Bt GvwI43c9PMRaRTOBJchzTurhxSxeDDRIm37s+rGCdWp9gF8HMFyBN9vhohdSMZt/ zgtVUbTgAw189mA/W+fJlRcwkW6W1gKe+mSNNQ3cMuFYFucuZ0BzdrStTkz6eG8x MH57rU8Qj6XjV0L6BKn2WX1peJKvfys= -----END CERTIFICATE-----
Root CA Zertifikat beim Client abspeichern
Nun müssen wir nur noch dafür sorgen, dass unser Root CA Zertifikat auf den bzw. die Clientrechner und auf unserem graylog-Server vorhanden ist. Entweder kopieren wir es via scp auf die Zielsysteme oder wir erzeugen und bearbeiten einfach die Zertifikatsdatei mit dem Editor unserer Wahl.
# vim /etc/pki/CA/certs/root-ca.certifikate.pem
-----BEGIN CERTIFICATE----- MIIGEzCCA/ugAwIBAgIJAJewGWTyyHtPMA0GCSqGSIb3DQEBDQUAMIGfMQswCQYD VQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYDVQQHDAhQbGllbmluZzETMBEG A1UECgwKbmF1c2NoLm9yZzEeMBwGA1UECwwVWmVydGlmaXppZXJ1bmdzc3RlbGxl MRMwEQYDVQQDDApncmF5bG9nIENBMSIwIAYJKoZIhvcNAQkBFhNjYS1hZG1pbkBu YXVzY2gub3JnMB4XDTE2MDEwMzIyNTcxMloXDTQ1MTIyNjIyNTcxMlowgZ8xCzAJ BgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAPBgNVBAcMCFBsaWVuaW5nMRMw EQYDVQQKDApuYXVzY2gub3JnMR4wHAYDVQQLDBVaZXJ0aWZpemllcnVuZ3NzdGVs bGUxEzARBgNVBAMMCmdyYXlsb2cgQ0ExIjAgBgkqhkiG9w0BCQEWE2NhLWFkbWlu QG5hdXNjaC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDK9Lwr DUNqY/yT++YYke1zIj/aHPs6jmBB4TNuvwyMM7JSBFAFXPtz0iOW9CoxWtbo0khH tobNG9SdTLas/MmU/NyLylCs5E3yBoQN6N28L7z7/SbBGV4TYbI304CbDny7XBlp Bj/eAo9pwcBVaAEaSXKlpY2Tp8xK5fhvA+txIrY/XlT3VyBfXYBVtbbhhf+TDkf2 ZKc9hCLZRfj4AXA7KrLdGIBlgWFmwp0axUtM4IkFKP5ABgCHwROsrtx++wDnlYQ9 g+l+SK5apcDWrnW5nlSWS4uGSGeetzHQsAalKUQIVAVILA2Nmb8xWUj0PbW9S8ZW 0FmQb7gSl4Gt2OsB9EFMs1nAJmfpS+VZXpZ7wt/KlnMb7fPsxgUS275noCrSpwNn x22xNbPq5Sxlft/c3I9Xhvm8eqVFpWel9J2ve6+aUtvqisi+8FD2WMOIKA/EBNXz poADM9dk2NKDOfQ9lBz0aMGov6/Hxd7jhYZHraBHv0chsHthn6gFMoEMfFTmS62Y 5sfTCFADP0uy/LFLGFvks3G++Mou1ImEuDIrrB/hAHG7nweVrKj8xbWoWo/NPV2g 1y40viRBgO5bERNOBcX/U+8xwh8StL1fgA+APa/TpyMXuSiKbktXM1k48+r0MMwO 6EGD64+I6qIDLPUWDe+ylxCgC34Nl+EN1GlOlwIDAQABo1AwTjAdBgNVHQ4EFgQU 98MEcCU4LwKCXV8vfxtml0Of2A4wHwYDVR0jBBgwFoAU98MEcCU4LwKCXV8vfxtm l0Of2A4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOCAgEAN1xIGaBnVTzl +HQuSVcL/urU84I99Yt0dB2tpM4AcvgZGbc1f6GFYbMR0ZC12dZvVQSDKAW5CwmV rMAlDRcC7v3FDUgSznwJZ3JqRwx79EgKHQVteHoESVC3K/03gN6+YmY7tRtSeK+0 Ftb5+WS4qdNtnw6BZx86xTm8Xdlz8Y2c2h70Ingo1tLvKgeFV/z4nKy0L1EG86X9 EH76Jl5qzbrxA2z78dnNhmUyGEbKJCjx6EfY1zAMt0pdGQ+dnFlAFWAeU3Ui0ZlO wcfw1ZLQQ40qnIumXBiIWnMKdfKzRt6kAg4S4+dCebXJIKjassoeQrj16rU8t27e FSkRLr0NUJPlGYWyevNIBlB9utTzOmQ1C2x0Om8CxX1MLXhwQ/lLHA5EH/uRHoCn li7uBI9xmnSmgChBGbSwRtAd0DyP050CY35dOPW0KblmevyhlCQNOLsx9RzL1ROi DfpZnC9jaKnuAtdFaEd+ELm8WHV+j0zYL3L4punoM9cfbEQ1CQTyloxpFqnze1Bt GvwI43c9PMRaRTOBJchzTurhxSxeDDRIm37s+rGCdWp9gF8HMFyBN9vhohdSMZt/ zgtVUbTgAw189mA/W+fJlRcwkW6W1gKe+mSNNQ3cMuFYFucuZ0BzdrStTkz6eG8x MH57rU8Qj6XjV0L6BKn2WX1peJKvfys= -----END CERTIFICATE-----
graylog-server Zertifikat erzeugen
Nachdem wir den ersten wichtigen Schritt - Erstellen unserer eigenen CA erfolgreich abgeschlossen haben, können wir uns nun dem zweiten Punkt, der Generierung des graylog-server Zertifikates widmen.
Schlüssel für das Serverzertifikat erzeugen
Nachdem wir nun unsere eigene CA erstellt haben, machen wir uns daran, endlich für unseren Server ein Zertifikat herausgeben. Hierzu erzeugen wir uns wieder als erstes einen 4096 Bit langen RSA Schlüssel, den wir mit AES 256 verschlüsselt auf der Platte abgelegt lassen. Da OpenSSL keine leere Passphrase zulässt braucht die Passphrase diesmal nicht sonderlich geheim sein, da wir diese im Anschluss ohnehin sofort wieder entfernen werden.
Die Eingaben sind auch hier zur besseren Unterscheidung fett und kursiv in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl genrsa -out /etc/pki/tls/serverkey.pem -aes256 4096
Generating RSA private key, 4096 bit long modulus .......................................................................................................................................................................................................................++ ........................................................................................................................................................................................++ e is 65537 (0x10001) Enter pass phrase for serverkey.pem: 12qwasyx Verifying - Enter pass phrase for serverkey.pem: 12qwasyx
Wie schon erwähnt, entfernen wir die Passphrase nun wieder, in dem wir bei der Frage Enter pass phrase: einfach die Taste [ENTER] drücken.
# openssl rsa -in /etc/pki/tls/serverkey.pem -out /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem
Enter pass phrase: writing RSA key
Wie schon zuvor schützen wir auch hier den Serverschlüssel über die Dateirechte.
# chmod 400 /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem
Da wir die Schlüsseldatei mit der unsicheren Passphrase nicht mehr benötigen, vernichten wir die zugehörige Datei.
# shred -u /etc/pki/tls/serverkey.pem
Wichtig:
Damit graylog den soeben erzeugten Schlüssel später auch laden kann, müssen wir diesen erst noch in das passende PKCS #8 Format konvertiert werden. Ein Versuch den originären PKCS #1 Schlüssel zu laden würde andernfalls graylog mit folgendem Fehler quittieren.
2015-12-23T23:42:21.666+01:00 WARN [AbstractNioSelector] Failed to initialize an accepted socket. java.lang.IllegalArgumentException: Unsupported key type PKCS#1, please convert to PKCS#8
Wir konvertieren also noch den Schlüssel in das passende Format mit folgendem openssl Kommando.
# openssl pkcs8 -topk8 -in /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem \ -inform pem -out /etc/pki/tls/private/graylog-server.dmz.nausch.org.key_pk8.pem -outform pem -nocrypt
Graylog selbst läuft mit den Nutzerrechten des Users graylog; wir müssen also auch noch dafür sorgen, dass der User graylog den Schlüssel auch lesen darf. Wir ändern daher die Berechtigungen wie folgt:
# chown graylog.root /etc/pki/tls/private/graylog-server.dmz.nausch.org.key_pk8.pem
CSR erstellen
Nachdem wir unseren privaten Schlüssel erzeugt haben, können wir uns nun unserem CSR9) widmen. Wie schon zuvor, sind die Eingaben auch hier zur besseren Unterscheidung fett und kursiv in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl req -new -key /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem \ -out /etc/pki/tls/private/graylog-server.dmz.nausch.org.csr.pem -nodes
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) [XX]:DE State or Province Name (full name) []:Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:IT-Monitoring Common Name (eg, your name or your server's hostname) []:graylog-server.dmz.nausch.org Email Address []:graylog-admin@nausch.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
CSR ausgeben
Möchten wir den Inhalt unseres Certificate Signing Request ausgeben und ansehen, verwenden wir den folgenden openssl-Aufruf.
# openssl req -noout -text -in /etc/pki/tls/private/graylog-server.dmz.nausch.org.csr.pem
Certificate Request: Data: Version: 0 (0x0) Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=IT-Monitoring, CN=graylog-server.dmz.nausch.org/emailAddress=graylog-admin@nausch.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:a4:89:62:85:af:56:b3:04:0c:34:86:4a:e3:b8: 6a:f4:23:6c:7f:bc:4c:a6:4e:cd:2e:fe:38:ad:74: 19:a1:de:cb:36:fa:c4:b4:85:31:1e:62:05:a5:f5: f5:f0:7b:94:69:21:b3:48:ae:27:1c:bd:bd:52:2f: 9b:ee:ad:cf:5f:fe:e4:0f:a4:8c:0a:91:e0:75:fd: 47:e9:11:35:94:bd:86:b5:9e:47:1c:f8:b7:13:c4: 60:68:b5:8f:2e:8f:0d:75:fe:7a:41:d8:e7:2b:1e: cb:d7:f2:4f:99:e6:c1:d9:c3:df:07:3b:0b:e4:cd: 1f:c3:0b:39:7a:15:38:09:df:a8:29:3c:73:c5:e1: 58:50:1e:4b:ef:cb:3c:63:e6:be:d2:ab:54:b7:ce: 03:69:3b:1f:d5:80:5a:be:98:af:a3:c9:3f:a8:84: 44:21:5d:f5:36:e8:11:ae:3f:7d:51:29:80:51:64: bd:96:ff:32:36:9c:66:1f:9c:8b:4a:f0:f4:0d:50: 2b:3b:ea:32:2f:1c:22:0f:ca:87:78:d5:1f:de:4c: 45:64:c4:42:ae:d3:bc:47:98:c5:19:15:17:db:d3: e3:1d:4e:84:76:d2:ba:ab:db:97:03:ff:bf:01:d7: 21:46:56:09:16:52:58:38:64:d0:8a:9b:7e:ba:5f: 9b:ec:f9:67:37:70:66:aa:b2:be:f2:af:ca:70:da: 8f:6e:5b:1d:5f:fa:97:da:6e:bf:f3:fb:6b:33:58: 74:bd:68:90:7d:21:c2:d3:9c:31:37:f1:88:f8:95: 8c:6e:68:ce:6c:71:83:35:8b:97:d8:94:78:fa:d7: d7:c5:bd:26:6f:30:28:ac:0c:08:5e:9b:98:f7:4c: 7b:48:8c:a8:3c:2a:9a:01:d0:51:7f:9d:8b:a3:5b: 09:a2:60:42:81:fc:18:c1:53:56:9f:78:d5:3b:96: 94:59:70:b7:44:a1:f9:8f:88:22:55:9e:e6:67:e4: 4f:b5:8b:dd:e2:7c:a7:09:b9:52:91:23:2b:7f:13: 5c:2b:f1:05:54:a6:a4:85:df:6c:fd:4e:0b:6f:96: 53:2a:01:e4:fa:af:2d:3e:af:93:c4:05:88:d4:be: 99:74:d1:be:b7:2d:e4:bc:20:3d:34:36:e4:0e:35: fc:d3:71:58:60:ec:91:b7:2b:35:76:4d:ae:ea:49: ac:4b:64:93:01:ce:3a:38:ea:38:8c:2f:5a:8e:af: d3:7f:aa:e4:17:0a:87:e4:92:94:06:2f:ca:b9:67: 20:7d:dc:65:f1:ff:f7:2b:a8:8c:55:71:d4:26:e0: c8:87:c8:1c:8f:0d:42:77:1c:8f:31:8a:b1:66:4c: 18:88:79 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha512WithRSAEncryption 2b:35:c6:1e:b4:d6:d6:3d:91:60:1a:e1:05:f8:00:dc:82:e6: 5b:4c:71:dc:3a:46:f2:8e:78:ba:3b:6c:2f:f7:fa:79:c5:e1: 8c:82:08:bf:3c:69:77:57:b6:a5:39:73:63:2b:a1:04:5b:1c: 24:c1:ba:55:59:d5:13:18:c1:88:02:e1:b1:82:c9:de:77:08: 41:d1:1d:72:e2:67:21:25:e5:43:de:3c:2e:13:ed:bc:a5:d1: 8d:d2:e5:71:37:b3:d1:4d:92:90:4f:71:b1:1f:e7:01:c0:66: 8c:7a:7b:29:5f:2d:96:f6:9e:bb:77:56:23:3d:5e:76:56:13: db:1f:88:54:ce:58:f1:4b:bf:b3:b2:33:7f:b8:a8:79:2d:01: 76:85:18:7f:7d:40:bf:da:05:cf:07:86:43:df:6f:58:56:f7: fc:a7:6c:b0:33:95:33:05:be:6f:d8:c0:cc:33:2f:3d:a0:a0: 7e:0a:5b:27:98:47:ab:44:2c:2a:bb:29:4f:de:70:27:24:59: b4:d0:98:08:a8:c8:22:f3:fb:de:7d:d2:5a:e9:8c:8f:3f:c8: 14:47:2b:7e:e3:82:89:98:f7:4c:11:39:59:a3:82:26:e9:24: e3:b2:9a:e0:73:11:01:aa:44:4f:12:6a:da:7e:ec:e8:6d:5d: fd:66:04:3f:f6:d6:2e:07:64:1d:3f:38:56:b4:6e:28:73:6a: e8:57:ca:27:99:12:51:17:03:f5:41:02:de:ba:b0:cb:29:8e: 28:eb:2b:61:81:9e:8f:d3:aa:9c:63:d5:e4:09:e0:1c:43:96: 3a:95:60:62:69:d2:38:45:ad:e2:26:0a:83:3c:13:16:e1:53: 8d:bc:e1:9e:6f:8a:a5:fd:c1:ac:8e:8b:01:66:e8:ff:51:8c: a0:c1:82:7c:2b:60:09:be:12:72:8b:a7:f7:29:e4:95:f0:02: 17:f8:6a:3d:82:a2:e8:f2:52:d5:ac:2d:14:f2:f9:63:04:e1: e0:1a:2f:98:4e:95:31:36:43:d4:b2:22:79:2c:7e:0a:a8:dd: f7:4b:86:2c:13:d4:c5:86:8f:ca:4f:18:13:3d:7c:6a:81:69: 35:76:fd:31:f7:ec:55:c7:57:08:9f:bf:b5:4c:36:8a:34:ab: 7a:79:91:be:11:da:e9:a0:58:a8:a6:9d:3d:5b:26:5c:7c:c4: 0d:ab:80:5b:15:ee:61:d9:a5:63:cb:ea:6b:fb:16:41:01:64: dc:b3:fd:43:1c:8b:86:a8:6d:45:49:fd:67:75:7a:73:43:9d: 55:db:90:d4:82:41:de:3a:c5:cf:1b:52:8c:59:0a:6a:6e:b6: 7e:7d:ed:ea:45:6d:8e:11
Wie auch schon beim Root CA Zertifikat können wir uns auch den CSR BASE64 kodiert ausgeben lassen.
# cat /etc/pki/tls/private/graylog-server.dmz.nausch.org.csr.pem
-----BEGIN CERTIFICATE REQUEST----- MIIE9TCCAt0CAQAwga8xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRYwFAYDVQQLDA1J VC1Nb25pdG9yaW5nMSYwJAYDVQQDDB1ncmF5bG9nLXNlcnZlci5kbXoubmF1c2No Lm9yZzEnMCUGCSqGSIb3DQEJARYYZ3JheWxvZy1hZG1pbkBuYXVzY2gub3JnMIIC IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEApIliha9WswQMNIZK47hq9CNs f7xMpk7NLv44rXQZod7LNvrEtIUxHmIFpfX18HuUaSGzSK4nHL29Ui+b7q3PX/7k D6SMCpHgdf1H6RE1lL2GtZ5HHPi3E8RgaLWPLo8Ndf56QdjnKx7L1/JPmebB2cPf BzsL5M0fwws5ehU4Cd+oKTxzxeFYUB5L78s8Y+a+0qtUt84DaTsf1YBavpivo8k/ qIREIV31NugRrj99USmAUWS9lv8yNpxmH5yLSvD0DVArO+oyLxwiD8qHeNUf3kxF ZMRCrtO8R5jFGRUX29PjHU6EdtK6q9uXA/+/AdchRlYJFlJYOGTQipt+ul+b7Pln N3BmqrK+8q/KcNqPblsdX/qX2m6/8/trM1h0vWiQfSHC05wxN/GI+JWMbmjObHGD NYuX2JR4+tfXxb0mbzAorAwIXpuY90x7SIyoPCqaAdBRf52Lo1sJomBCgfwYwVNW n3jVO5aUWXC3RKH5j4giVZ7mZ+RPtYvd4nynCblSkSMrfxNcK/EFVKakhd9s/U4L b5ZTKgHk+q8tPq+TxAWI1L6ZdNG+ty3kvCA9NDbkDjX803FYYOyRtys1dk2u6kms S2STAc46OOo4jC9ajq/Tf6rkFwqH5JKUBi/KuWcgfdxl8f/3K6iMVXHUJuDIh8gc jw1CdxyPMYqxZkwYiHkCAwEAAaAAMA0GCSqGSIb3DQEBDQUAA4ICAQArNcYetNbW PZFgGuEF+ADcguZbTHHcOkbyjni6O2wv9/p5xeGMggi/PGl3V7alOXNjK6EEWxwk wbpVWdUTGMGIAuGxgsnedwhB0R1y4mchJeVD3jwuE+28pdGN0uVxN7PRTZKQT3Gx H+cBwGaMenspXy2W9p67d1YjPV52VhPbH4hUzljxS7+zsjN/uKh5LQF2hRh/fUC/ 2gXPB4ZD329YVvf8p2ywM5UzBb5v2MDMMy89oKB+ClsnmEerRCwquylP3nAnJFm0 0JgIqMgi8/vefdJa6YyPP8gURyt+44KJmPdMETlZo4Im6STjsprgcxEBqkRPEmra fuzobV39ZgQ/9tYuB2QdPzhWtG4oc2roV8onmRJRFwP1QQLeurDLKY4o6ythgZ6P 06qcY9XkCeAcQ5Y6lWBiadI4Ra3iJgqDPBMW4VONvOGeb4ql/cGsjosBZuj/UYyg wYJ8K2AJvhJyi6f3KeSV8AIX+Go9gqLo8lLVrC0U8vljBOHgGi+YTpUxNkPUsiJ5 LH4KqN33S4YsE9TFho/KTxgTPXxqgWk1dv0x9+xVx1cIn7+1TDaKNKt6eZG+Edrp oFiopp09WyZcfMQNq4BbFe5h2aVjy+pr+xZBAWTcs/1DHIuGqG1FSf1ndXpzQ51V 25DUgkHeOsXPG1KMWQpqbrZ+fe3qRW2OEQ== -----END CERTIFICATE REQUEST-----
CSR bei CA zum Signieren vorlegen
Damit unsere CA den gerade erstellten CSR prüfen und signieren kann, müssen wir den Certificate Signing Request der CA vorlegen. Im Fall unsere graylog-Server Zertificates können wir die CSR-Datei einfach an Ort und Stelle kopieren.
# cp /etc/pki/tls/private/graylog-server.dmz.nausch.org.csr.pem /etc/pki/CA/csrs/
CSR durch die CA prüfen und signieren
Nun prüfen wir die Angaben des CSR und signieren den öffentlichen Schlüssel des CSRs mit dem privaten Schlüssel unserer CA; dies wir auch als Zertifikatsgenerierung bezeichnet. Diese Arbeit erledigen wir mit Hilfe des folgenden openssl-Aufrufs. Auch hier sind die Eingaben zur besseren Unterscheidung fett und kursiv in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl ca -in /etc/pki/CA/csrs/graylog-server.dmz.nausch.org.csr.pem \ -out /etc/pki/CA/certs/graylog-server.dmz.nausch.org.certificate.pem -days 10950
Die Option days setzen wir dabei auf die bereits erwähnten 30 Jahre, was 10950 Tage entspricht. Bei der Frage nach der Passphrase des privaten Schlüssels geben wir das Passwort an, welches wir bei der Generierung unserer CA vergeben hatten.
Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for /etc/pki/CA/private/root-ca.key.pem:des-woas-blos-I-und-sunst-koana! Check that the request matches the signature Signature ok Certificate Details: Serial Number: 0 (0x0) Validity Not Before: Jan 3 23:24:25 2016 GMT Not After : Dec 26 23:24:25 2045 GMT Subject: countryName = DE stateOrProvinceName = Bayern organizationName = nausch.org organizationalUnitName = IT-Monitoring commonName = graylog-server.dmz.nausch.org emailAddress = graylog-admin@nausch.org X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 7A:F2:41:CE:1C:E7:CE:06:CB:30:00:AD:69:2D:6B:42:79:D7:9F:4D X509v3 Authority Key Identifier: keyid:F7:C3:04:70:25:38:2F:02:82:5D:5F:2F:7F:1B:66:97:43:9F:D8:0E Certificate is to be certified until Dec 26 23:24:25 2045 GMT (10950 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
erstellte Zertifikat dem gralog-server zur Verfügung stellen
Als letzten Schritt stellen wir nun das gerade erzeugte Server-Zertifikat dem graylog-server zur Verfügung. Hierzu kopieren wir einfach das gerade generierte Zertifikat an Ort und Stelle.
# cp /etc/pki/CA/certs/graylog-server.dmz.nausch.org.certificate.pem /etc/pki/tls/certs/
Zertifikat ausgeben
Wollen wir den Inhalt unseres gerade erstellten Zertifikates ausgeben, können wir folgenden openssl-Aufruf verwenden.
# openssl x509 -noout -text -in /etc/pki/tls/certs/graylog-server.dmz.nausch.org.certificate.pem
Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha512WithRSAEncryption Issuer: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Zertifizierungsstelle, CN=graylog CA/emailAddress=ca-admin@nausch.org Validity Not Before: Jan 3 23:24:25 2016 GMT Not After : Dec 26 23:24:25 2045 GMT Subject: C=DE, ST=Bayern, O=nausch.org, OU=IT-Monitoring, CN=graylog-server.dmz.nausch.org/emailAddress=graylog-admin@nausch.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:a4:89:62:85:af:56:b3:04:0c:34:86:4a:e3:b8: 6a:f4:23:6c:7f:bc:4c:a6:4e:cd:2e:fe:38:ad:74: 19:a1:de:cb:36:fa:c4:b4:85:31:1e:62:05:a5:f5: f5:f0:7b:94:69:21:b3:48:ae:27:1c:bd:bd:52:2f: 9b:ee:ad:cf:5f:fe:e4:0f:a4:8c:0a:91:e0:75:fd: 47:e9:11:35:94:bd:86:b5:9e:47:1c:f8:b7:13:c4: 60:68:b5:8f:2e:8f:0d:75:fe:7a:41:d8:e7:2b:1e: cb:d7:f2:4f:99:e6:c1:d9:c3:df:07:3b:0b:e4:cd: 1f:c3:0b:39:7a:15:38:09:df:a8:29:3c:73:c5:e1: 58:50:1e:4b:ef:cb:3c:63:e6:be:d2:ab:54:b7:ce: 03:69:3b:1f:d5:80:5a:be:98:af:a3:c9:3f:a8:84: 44:21:5d:f5:36:e8:11:ae:3f:7d:51:29:80:51:64: bd:96:ff:32:36:9c:66:1f:9c:8b:4a:f0:f4:0d:50: 2b:3b:ea:32:2f:1c:22:0f:ca:87:78:d5:1f:de:4c: 45:64:c4:42:ae:d3:bc:47:98:c5:19:15:17:db:d3: e3:1d:4e:84:76:d2:ba:ab:db:97:03:ff:bf:01:d7: 21:46:56:09:16:52:58:38:64:d0:8a:9b:7e:ba:5f: 9b:ec:f9:67:37:70:66:aa:b2:be:f2:af:ca:70:da: 8f:6e:5b:1d:5f:fa:97:da:6e:bf:f3:fb:6b:33:58: 74:bd:68:90:7d:21:c2:d3:9c:31:37:f1:88:f8:95: 8c:6e:68:ce:6c:71:83:35:8b:97:d8:94:78:fa:d7: d7:c5:bd:26:6f:30:28:ac:0c:08:5e:9b:98:f7:4c: 7b:48:8c:a8:3c:2a:9a:01:d0:51:7f:9d:8b:a3:5b: 09:a2:60:42:81:fc:18:c1:53:56:9f:78:d5:3b:96: 94:59:70:b7:44:a1:f9:8f:88:22:55:9e:e6:67:e4: 4f:b5:8b:dd:e2:7c:a7:09:b9:52:91:23:2b:7f:13: 5c:2b:f1:05:54:a6:a4:85:df:6c:fd:4e:0b:6f:96: 53:2a:01:e4:fa:af:2d:3e:af:93:c4:05:88:d4:be: 99:74:d1:be:b7:2d:e4:bc:20:3d:34:36:e4:0e:35: fc:d3:71:58:60:ec:91:b7:2b:35:76:4d:ae:ea:49: ac:4b:64:93:01:ce:3a:38:ea:38:8c:2f:5a:8e:af: d3:7f:aa:e4:17:0a:87:e4:92:94:06:2f:ca:b9:67: 20:7d:dc:65:f1:ff:f7:2b:a8:8c:55:71:d4:26:e0: c8:87:c8:1c:8f:0d:42:77:1c:8f:31:8a:b1:66:4c: 18:88:79 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 7A:F2:41:CE:1C:E7:CE:06:CB:30:00:AD:69:2D:6B:42:79:D7:9F:4D X509v3 Authority Key Identifier: keyid:F7:C3:04:70:25:38:2F:02:82:5D:5F:2F:7F:1B:66:97:43:9F:D8:0E Signature Algorithm: sha512WithRSAEncryption ba:96:c5:fd:9d:1d:22:78:e3:1b:f4:c0:90:73:0c:7e:d6:e8: 2f:ad:92:75:3a:8c:18:37:7b:74:2d:ba:01:dd:4f:e2:07:f0: 6c:d2:e2:0b:a6:7f:67:f5:16:98:96:8a:71:fd:bd:ad:a2:5c: 07:40:23:4e:e1:0d:da:b4:61:cc:83:56:a9:89:56:4b:69:a1: cb:ae:f2:bc:14:7a:c4:8e:15:da:f6:43:77:42:f2:42:da:82: a1:63:16:4d:d4:8a:86:00:54:71:98:c9:2e:4f:df:e5:19:26: 7a:86:f3:62:88:81:64:75:8c:d0:1c:32:40:53:46:6c:cb:c0: 61:7b:7a:58:be:09:e6:06:00:88:d6:23:f9:f3:9f:ac:61:2c: c3:f1:62:c2:25:09:91:d5:3b:11:47:47:e5:d3:ed:a7:11:99: d2:7e:af:b1:0d:ec:e0:7e:2b:ba:34:e6:c3:32:16:cc:81:70: fd:37:a0:ee:8d:2d:48:2c:47:43:fc:9d:3a:b6:8d:8d:2c:c2: 68:2e:46:69:76:b7:33:a3:9b:56:ea:85:e4:93:62:1f:2a:3d: 54:d9:38:46:e4:d6:91:0f:88:63:b1:4c:0f:d7:3f:3e:db:cb: dd:1b:18:9e:d1:19:a3:bd:a0:53:1f:c1:ac:d7:cf:2a:5a:29: ef:d2:8b:85:b0:91:6e:69:22:9d:bc:11:42:e4:d1:bd:85:85: f9:cf:e9:52:b0:52:75:10:4b:9b:84:f2:e5:fb:15:36:36:41: 9b:0e:b2:d6:d4:7e:83:31:a3:b2:32:9d:39:5f:66:67:73:52: 56:f0:66:d2:b5:9e:75:38:27:e8:85:4a:b3:bb:20:92:94:04: 02:c8:d2:fb:24:67:48:6f:24:4e:6e:a4:b1:d6:ef:cf:e3:9a: e9:37:f2:73:32:b2:e5:be:e9:0c:52:1e:28:e5:c2:21:e7:b6: fc:52:88:15:a5:b2:0a:34:f3:de:89:1b:72:7c:1a:c6:55:3f: e3:43:24:62:8a:00:e3:9a:f9:02:7b:4e:77:0a:83:16:07:60: f6:21:b1:ee:47:4f:be:78:5a:36:38:c6:89:36:20:8a:d3:c0: f2:28:6d:db:4d:81:4b:2b:08:55:ed:23:e8:a7:e1:8f:46:9d: 29:24:cb:bb:ca:bc:10:58:49:e3:bc:11:b3:55:35:ec:25:f7: 66:2f:d9:c8:62:f2:d6:5a:c2:ff:b5:a3:ba:bd:5a:7d:05:59: 04:91:98:3b:41:01:ac:2b:d9:20:d8:df:4a:92:dd:a3:82:c3: fe:38:3c:fa:f0:65:c0:5c:89:f2:42:47:56:6c:e4:7e:43:dd: 70:7c:65:a7:52:b3:59:7e
rsyslog Client-Zertifikate
Was uns nun noch für unser Glück fehlt, ist ein Server-Zertifikat für den rsyslog-Daemon; dieses werden wir nun noch generieren bzw. erstellen lassen. Im Prinzip unterscheidet sich die Generierung eines rsyslog Client-Zertifikate nicht vom Vorgehen des zuvor erstellten graylog-server Zertifikates.
Im folgenden Konfigurationsbeispiel werden wir für den Host vml.dmz.nausch.org ein Clientzertifikat erstellen.
Schlüssel für das Clientzertifikat erzeugen
Wie auch schon beim graylog-server Zertifikat erzeugen wir uns zunächst einen 4096 Bit langen RSA Schlüssel, den wir mit AES 256 verschlüsselt auf der Platte abgelegt lassen. Da OpenSSL keine leere Passphrase zulässt braucht die Passphrase diesmal nicht sonderlich geheim sein, da wir diese im Anschluss ohnehin sofort wieder entfernen werden.
Die Eingaben sind auch hier zur besseren Unterscheidung fett und kursiv in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl genrsa -out /etc/pki/tls/clientkey.pem -aes256 4096
Generating RSA private key, 4096 bit long modulus .......................................................................................................................................................................................................................++ ........................................................................................................................................................................................++ e is 65537 (0x10001) Enter pass phrase for clientkey.pem: 12qwasyx Verifying - Enter pass phrase for clientkey.pem: 12qwasyx
Anschließend entfernen wir die Passphrase nun wieder, in dem wir bei der Frage Enter pass phrase: einfach die Taste [ENTER] drücken.
# openssl rsa -in /etc/pki/tls/clientkey.pem -out /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem
Enter pass phrase: writing RSA key
Wie schon zuvor schützen wir auch hier den Serverschlüssel über die Dateirechte.
# chmod 400 /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem
Da wir die Schlüsseldatei mit der unsicheren Passphrase nicht mehr benötigen, vernichten wir die zugehörige Datei.
# shred -u /etc/pki/tls/clientkey.pem
CSR erstellen
Nachdem wir unseren privaten Schlüssel erzeugt haben, können wir uns nun unserem CSR10) widmen. Wie schon zuvor, sind die Eingaben auch hier zur besseren Unterscheidung fett und kursiv in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl req -new -key /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem \ -out /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.csr.pem -nodes
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) [XX]:DE State or Province Name (full name) []:Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:IT-Monitoring Common Name (eg, your name or your server's hostname) []:rsyslog.vml000037.dmz.nausch.org Email Address []:graylog-admin@nausch.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
CSR ausgeben
Möchten wir den Inhalt unseres Certificate Signing Request ausgeben und ansehen, verwenden wir den folgenden openssl-Aufruf.
# openssl req -noout -text -in /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.csr.pem
Certificate Request: Data: Version: 0 (0x0) Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=IT-Monitoring, CN=rsyslog.vml000037.dmz.nausch.org/emailAddress=graylog-admin@nausch.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ea:65:5c:9a:3b:3e:a9:2d:7f:f1:a5:9f:b3:e3: cd:a4:53:fb:70:30:fd:c8:be:00:fd:04:2a:08:f4: ea:d2:69:66:02:2d:c5:d9:b8:53:8d:d9:5a:7c:fd: 7a:92:12:4c:ab:83:ce:7a:8a:d3:0e:60:16:87:a0: a6:21:5e:96:2b:36:87:e9:85:f1:1b:fe:56:87:e3: 6e:30:40:9e:f7:f8:f2:8f:05:fa:57:d0:fb:10:94: a4:2e:16:ed:55:cb:22:61:e3:ac:4c:13:6c:70:da: e6:8b:8b:54:f6:4e:d4:58:5a:18:06:f1:61:20:98: 0f:dc:4c:30:4e:ef:c4:b3:0c:63:93:82:4a:89:98: 2e:6b:ae:75:c7:3a:c9:60:25:ac:58:fc:da:d4:83: 35:c6:96:2c:d9:6f:5e:0c:9f:9d:7a:f2:2e:ab:f0: 06:5b:f5:4a:74:62:02:83:9a:76:e3:04:db:9f:ee: 40:d5:03:ad:45:0d:69:be:39:f4:00:75:db:4d:f0: e9:56:7b:e5:3e:3e:63:69:23:c9:b4:0a:e2:d1:cd: 56:76:41:8b:43:f3:fc:2e:01:ca:21:16:7d:a9:24: e5:65:9d:21:bc:64:bc:dd:e1:f7:89:33:28:38:4e: 09:7c:5d:7c:ec:1f:67:5a:c0:ac:3d:b2:32:9a:73: cc:f2:c5:41:4c:17:b7:75:ca:ad:76:37:7e:a6:f2: 85:10:c5:e3:ee:95:94:b2:d2:51:cc:59:96:ca:e4: 0f:96:c1:7b:89:42:50:61:01:6c:33:32:33:9d:72: 57:a2:45:92:f0:bd:f7:47:6f:c1:51:c0:b9:05:fd: a9:af:a8:6c:f6:9b:1a:a5:e4:2b:34:0b:62:04:b7: c3:89:aa:83:5a:5c:82:b0:d1:72:ac:0b:e0:e4:94: 3c:44:0b:95:e9:a5:97:96:ee:e9:38:b9:92:74:89: 93:31:a6:5e:ca:dd:f8:d9:f8:ea:ff:b3:62:4a:45: aa:1c:35:05:fc:2c:36:da:b2:59:af:82:69:2c:d7: 4d:6c:df:2e:fc:c1:4a:f6:e1:f9:57:b7:83:b3:b1: 4e:48:36:1e:57:94:65:1e:a9:3f:96:56:03:21:46: 02:dc:4a:54:46:f0:99:25:9c:c8:bf:25:8a:d6:1f: ba:fd:ab:70:cd:96:cc:28:36:3b:66:b0:fb:48:47: 59:78:69:5b:69:6c:a9:ca:a1:23:56:7a:47:f7:49: cf:25:b5:1d:37:83:84:fe:f9:8a:be:ff:be:e5:93: 9c:c0:05:99:d3:14:a6:ce:23:dc:75:ce:0c:a5:e3: 40:cf:f9:10:a6:40:93:1f:25:51:f6:7f:5c:a4:74: b7:b3:39 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption dd:25:b7:55:94:ae:7d:24:9a:5e:4d:84:e8:bc:12:37:20:a2: 64:f9:fd:15:83:9a:a1:59:72:fe:2a:2b:df:f8:f3:11:f0:0a: e0:b9:0e:ae:b8:93:ed:a3:3c:48:06:5a:5a:74:6d:62:c9:9d: f8:22:de:9b:5e:39:bd:a2:09:fa:9f:bd:3e:1d:87:37:f3:2f: 9f:35:9a:5e:b0:c6:7a:66:0c:86:4f:f3:6c:5b:fb:4b:25:9f: 83:ec:64:e2:43:ad:51:91:b7:56:eb:fc:00:4e:b4:36:0a:2f: 3d:c7:53:67:e6:b0:8d:11:68:dd:19:b5:ee:25:d9:d8:0c:49: 21:57:28:ec:ca:c8:ea:09:85:3b:14:54:72:73:58:5a:e3:4c: 21:3e:d6:e6:b4:7d:25:1a:31:ec:a1:d8:c7:31:bc:fb:44:1d: 2f:69:91:1a:11:8e:02:63:bf:f4:8f:ca:fc:45:3c:ef:a1:31: 54:4e:9f:c3:b2:ab:68:69:69:93:ac:17:02:5c:ad:70:9f:73: 98:ba:12:61:1e:94:d1:92:8a:8b:93:b0:f6:74:58:39:f8:96: 26:7a:ba:fc:48:63:09:95:21:ee:8e:36:5f:c7:ce:5b:61:1c: 6b:ed:75:a1:b1:9a:74:64:29:6d:03:64:7b:6e:8a:b5:5d:83: 62:ce:54:96:c5:47:68:7a:63:2a:8c:3c:3c:5f:54:3a:4f:51: a7:ae:49:e8:a4:31:6e:58:34:97:74:9f:6d:72:c1:55:23:ea: 75:7f:23:8b:0e:cb:f7:71:a0:11:64:50:c7:1e:3f:0f:1b:cd: 4d:d9:3b:79:6c:a4:39:8a:94:72:33:61:5a:fb:07:8a:0c:02: 73:77:72:c2:9d:6c:a6:d4:b9:32:e2:9a:6e:dc:ff:33:df:ee: 75:ff:4d:b8:0c:ee:11:ac:a5:f6:39:cb:9b:b2:9b:98:db:db: 89:8c:18:13:68:99:90:1d:65:99:21:10:14:b7:91:8f:0c:bd: 2c:1e:fd:0f:fd:9d:f5:dc:2a:1b:8f:15:37:c0:98:6e:e9:0f: 0d:96:cb:87:43:c5:1e:7e:28:7e:ca:d7:eb:58:e8:32:34:85: 29:4c:b1:56:b1:57:c6:e5:72:a6:0a:3b:26:64:af:bc:1f:2f: 72:ee:c7:50:c5:09:98:57:e6:92:5b:30:8b:f8:05:e5:8c:59: 1b:53:15:96:dc:4a:de:b2:d0:db:9a:6c:ce:60:38:9c:94:0f: 3c:21:63:ff:50:f9:a2:c1:64:78:02:fd:52:8c:41:ee:78:27: c8:d9:74:1c:31:dd:c2:b5:c9:82:48:2d:e5:e0:f3:e9:51:96: 1a:c0:d3:58:1b:3c:91:b0
Wie auch schon beim graylog-server Zertifikat können wir uns auch den CSR BASE64 kodiert ausgeben lassen.
# cat /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.csr.pem
-----BEGIN CERTIFICATE REQUEST----- MIIE+DCCAuACAQAwgbIxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRYwFAYDVQQLDA1J VC1Nb25pdG9yaW5nMSkwJwYDVQQDDCByc3lzbG9nLnZtbDAwMDAzNy5kbXoubmF1 c2NoLm9yZzEnMCUGCSqGSIb3DQEJARYYZ3JheWxvZy1hZG1pbkBuYXVzY2gub3Jn MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA6mVcmjs+qS1/8aWfs+PN pFP7cDD9yL4A/QQqCPTq0mlmAi3F2bhTjdlafP16khJMq4POeorTDmAWh6CmIV6W KzaH6YXxG/5Wh+NuMECe9/jyjwX6V9D7EJSkLhbtVcsiYeOsTBNscNrmi4tU9k7U WFoYBvFhIJgP3EwwTu/Eswxjk4JKiZgua651xzrJYCWsWPza1IM1xpYs2W9eDJ+d evIuq/AGW/VKdGICg5p24wTbn+5A1QOtRQ1pvjn0AHXbTfDpVnvlPj5jaSPJtAri 0c1WdkGLQ/P8LgHKIRZ9qSTlZZ0hvGS83eH3iTMoOE4JfF187B9nWsCsPbIymnPM 8sVBTBe3dcqtdjd+pvKFEMXj7pWUstJRzFmWyuQPlsF7iUJQYQFsMzIznXJXokWS 8L33R2/BUcC5Bf2pr6hs9psapeQrNAtiBLfDiaqDWlyCsNFyrAvg5JQ8RAuV6aWX lu7pOLmSdImTMaZeyt342fjq/7NiSkWqHDUF/Cw22rJZr4JpLNdNbN8u/MFK9uH5 V7eDs7FOSDYeV5RlHqk/llYDIUYC3EpURvCZJZzIvyWK1h+6/atwzZbMKDY7ZrD7 SEdZeGlbaWypyqEjVnpH90nPJbUdN4OE/vmKvv++5ZOcwAWZ0xSmziPcdc4MpeNA z/kQpkCTHyVR9n9cpHS3szkCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4ICAQDdJbdV lK59JJpeTYTovBI3IKJk+f0Vg5qhWXL+Kivf+PMR8ArguQ6uuJPtozxIBlpadG1i yZ34It6bXjm9ogn6n70+HYc38y+fNZpesMZ6ZgyGT/NsW/tLJZ+D7GTiQ61RkbdW 6/wATrQ2Ci89x1Nn5rCNEWjdGbXuJdnYDEkhVyjsysjqCYU7FFRyc1ha40whPtbm tH0lGjHsodjHMbz7RB0vaZEaEY4CY7/0j8r8RTzvoTFUTp/DsqtoaWmTrBcCXK1w n3OYuhJhHpTRkoqLk7D2dFg5+JYmerr8SGMJlSHujjZfx85bYRxr7XWhsZp0ZClt A2R7boq1XYNizlSWxUdoemMqjDw8X1Q6T1GnrknopDFuWDSXdJ9tcsFVI+p1fyOL Dsv3caARZFDHHj8PG81N2Tt5bKQ5ipRyM2Fa+weKDAJzd3LCnWym1Lky4ppu3P8z 3+51/024DO4RrKX2OcubspuY29uJjBgTaJmQHWWZIRAUt5GPDL0sHv0P/Z313Cob jxU3wJhu6Q8NlsuHQ8Uefih+ytfrWOgyNIUpTLFWsVfG5XKmCjsmZK+8Hy9y7sdQ xQmYV+aSWzCL+AXljFkbUxWW3ErestDbmmzOYDiclA88IWP/UPmiwWR4Av1SjEHu eCfI2XQcMd3CtcmCSC3l4PPpUZYawNNYGzyRsA== -----END CERTIFICATE REQUEST-----
CSR bei CA zum Signieren vorlegen
Damit unsere CA den gerade erstellten CSR prüfen und signieren kann, müssen wir den Certificate Signing Request der CA vorlegen. Wir kopieren entweder den gerade erstellten CSR via scp zum Server auf dem unsere CA erstellt hatten, oder wir legen die CSR-Datei mit dem Editor direkt auf dem Server ab.
# vim /etc/pki/CA/csrs/rsyslog.vml000037.dmz.nausch.org.csr.pem
-----BEGIN CERTIFICATE REQUEST----- MIIE+DCCAuACAQAwgbIxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRYwFAYDVQQLDA1J VC1Nb25pdG9yaW5nMSkwJwYDVQQDDCByc3lzbG9nLnZtbDAwMDAzNy5kbXoubmF1 c2NoLm9yZzEnMCUGCSqGSIb3DQEJARYYZ3JheWxvZy1hZG1pbkBuYXVzY2gub3Jn MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA6mVcmjs+qS1/8aWfs+PN pFP7cDD9yL4A/QQqCPTq0mlmAi3F2bhTjdlafP16khJMq4POeorTDmAWh6CmIV6W KzaH6YXxG/5Wh+NuMECe9/jyjwX6V9D7EJSkLhbtVcsiYeOsTBNscNrmi4tU9k7U WFoYBvFhIJgP3EwwTu/Eswxjk4JKiZgua651xzrJYCWsWPza1IM1xpYs2W9eDJ+d evIuq/AGW/VKdGICg5p24wTbn+5A1QOtRQ1pvjn0AHXbTfDpVnvlPj5jaSPJtAri 0c1WdkGLQ/P8LgHKIRZ9qSTlZZ0hvGS83eH3iTMoOE4JfF187B9nWsCsPbIymnPM 8sVBTBe3dcqtdjd+pvKFEMXj7pWUstJRzFmWyuQPlsF7iUJQYQFsMzIznXJXokWS 8L33R2/BUcC5Bf2pr6hs9psapeQrNAtiBLfDiaqDWlyCsNFyrAvg5JQ8RAuV6aWX lu7pOLmSdImTMaZeyt342fjq/7NiSkWqHDUF/Cw22rJZr4JpLNdNbN8u/MFK9uH5 V7eDs7FOSDYeV5RlHqk/llYDIUYC3EpURvCZJZzIvyWK1h+6/atwzZbMKDY7ZrD7 SEdZeGlbaWypyqEjVnpH90nPJbUdN4OE/vmKvv++5ZOcwAWZ0xSmziPcdc4MpeNA z/kQpkCTHyVR9n9cpHS3szkCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4ICAQDdJbdV lK59JJpeTYTovBI3IKJk+f0Vg5qhWXL+Kivf+PMR8ArguQ6uuJPtozxIBlpadG1i yZ34It6bXjm9ogn6n70+HYc38y+fNZpesMZ6ZgyGT/NsW/tLJZ+D7GTiQ61RkbdW 6/wATrQ2Ci89x1Nn5rCNEWjdGbXuJdnYDEkhVyjsysjqCYU7FFRyc1ha40whPtbm tH0lGjHsodjHMbz7RB0vaZEaEY4CY7/0j8r8RTzvoTFUTp/DsqtoaWmTrBcCXK1w n3OYuhJhHpTRkoqLk7D2dFg5+JYmerr8SGMJlSHujjZfx85bYRxr7XWhsZp0ZClt A2R7boq1XYNizlSWxUdoemMqjDw8X1Q6T1GnrknopDFuWDSXdJ9tcsFVI+p1fyOL Dsv3caARZFDHHj8PG81N2Tt5bKQ5ipRyM2Fa+weKDAJzd3LCnWym1Lky4ppu3P8z 3+51/024DO4RrKX2OcubspuY29uJjBgTaJmQHWWZIRAUt5GPDL0sHv0P/Z313Cob jxU3wJhu6Q8NlsuHQ8Uefih+ytfrWOgyNIUpTLFWsVfG5XKmCjsmZK+8Hy9y7sdQ xQmYV+aSWzCL+AXljFkbUxWW3ErestDbmmzOYDiclA88IWP/UPmiwWR4Av1SjEHu eCfI2XQcMd3CtcmCSC3l4PPpUZYawNNYGzyRsA== -----END CERTIFICATE REQUEST-----
CSR durch die CA prüfen und signieren
Nun prüfen wir die Angaben des CSR und signieren den öffentlichen Schlüssel des CSRs mit dem privaten Schlüssel unserer CA; dies wir auch als Zertifikatsgenerierung bezeichnet. Diese Arbeit erledigen wir mit Hilfe des folgenden openssl-Aufrufs. Auch hier sind die Eingaben zur besseren Unterscheidung fett und kursiv in der Farbe blau und die Rückmeldungen in der Farbe grau gekennzeichnet.
# openssl ca -in /etc/pki/CA/csrs/rsyslog.vml000037.dmz.nausch.org.csr.pem \ -out /etc/pki/CA/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem -days 10950
Die Option days setzen wir dabei wieder auf 30 Jahre, was 10950 Tage entspricht. Bei der Frage nach der Passphrase des privaten Schlüssels geben wir das Passwort an, welches wir bei der Generierung unserer CA vergeben hatten.
Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for /etc/pki/CA/private/root-ca.key.pem:des-woas-blos-I-und-sunst-koana! Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Jan 4 10:08:53 2016 GMT Not After : Dec 27 10:08:53 2045 GMT Subject: countryName = DE stateOrProvinceName = Bayern organizationName = nausch.org organizationalUnitName = IT-Monitoring commonName = rsyslog.vml000037.dmz.nausch.org emailAddress = graylog-admin@nausch.org X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 93:2E:9C:FB:B3:9D:5B:55:8A:09:81:B4:FB:C2:CA:86:28:9E:EA:88 X509v3 Authority Key Identifier: keyid:F7:C3:04:70:25:38:2F:02:82:5D:5F:2F:7F:1B:66:97:43:9F:D8:0E Certificate is to be certified until Dec 27 10:08:53 2045 GMT (10950 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
Zertifikat ausgeben
# openssl x509 -noout -text -in /etc/pki/CA/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem
Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha512WithRSAEncryption Issuer: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Zertifizierungsstelle, CN=graylog CA/emailAddress=ca-admin@nausch.org Validity Not Before: Jan 4 10:08:53 2016 GMT Not After : Dec 27 10:08:53 2045 GMT Subject: C=DE, ST=Bayern, O=nausch.org, OU=IT-Monitoring, CN=rsyslog.vml000037.dmz.nausch.org/emailAddress=graylog-admin@nausch.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ea:65:5c:9a:3b:3e:a9:2d:7f:f1:a5:9f:b3:e3: cd:a4:53:fb:70:30:fd:c8:be:00:fd:04:2a:08:f4: ea:d2:69:66:02:2d:c5:d9:b8:53:8d:d9:5a:7c:fd: 7a:92:12:4c:ab:83:ce:7a:8a:d3:0e:60:16:87:a0: a6:21:5e:96:2b:36:87:e9:85:f1:1b:fe:56:87:e3: 6e:30:40:9e:f7:f8:f2:8f:05:fa:57:d0:fb:10:94: a4:2e:16:ed:55:cb:22:61:e3:ac:4c:13:6c:70:da: e6:8b:8b:54:f6:4e:d4:58:5a:18:06:f1:61:20:98: 0f:dc:4c:30:4e:ef:c4:b3:0c:63:93:82:4a:89:98: 2e:6b:ae:75:c7:3a:c9:60:25:ac:58:fc:da:d4:83: 35:c6:96:2c:d9:6f:5e:0c:9f:9d:7a:f2:2e:ab:f0: 06:5b:f5:4a:74:62:02:83:9a:76:e3:04:db:9f:ee: 40:d5:03:ad:45:0d:69:be:39:f4:00:75:db:4d:f0: e9:56:7b:e5:3e:3e:63:69:23:c9:b4:0a:e2:d1:cd: 56:76:41:8b:43:f3:fc:2e:01:ca:21:16:7d:a9:24: e5:65:9d:21:bc:64:bc:dd:e1:f7:89:33:28:38:4e: 09:7c:5d:7c:ec:1f:67:5a:c0:ac:3d:b2:32:9a:73: cc:f2:c5:41:4c:17:b7:75:ca:ad:76:37:7e:a6:f2: 85:10:c5:e3:ee:95:94:b2:d2:51:cc:59:96:ca:e4: 0f:96:c1:7b:89:42:50:61:01:6c:33:32:33:9d:72: 57:a2:45:92:f0:bd:f7:47:6f:c1:51:c0:b9:05:fd: a9:af:a8:6c:f6:9b:1a:a5:e4:2b:34:0b:62:04:b7: c3:89:aa:83:5a:5c:82:b0:d1:72:ac:0b:e0:e4:94: 3c:44:0b:95:e9:a5:97:96:ee:e9:38:b9:92:74:89: 93:31:a6:5e:ca:dd:f8:d9:f8:ea:ff:b3:62:4a:45: aa:1c:35:05:fc:2c:36:da:b2:59:af:82:69:2c:d7: 4d:6c:df:2e:fc:c1:4a:f6:e1:f9:57:b7:83:b3:b1: 4e:48:36:1e:57:94:65:1e:a9:3f:96:56:03:21:46: 02:dc:4a:54:46:f0:99:25:9c:c8:bf:25:8a:d6:1f: ba:fd:ab:70:cd:96:cc:28:36:3b:66:b0:fb:48:47: 59:78:69:5b:69:6c:a9:ca:a1:23:56:7a:47:f7:49: cf:25:b5:1d:37:83:84:fe:f9:8a:be:ff:be:e5:93: 9c:c0:05:99:d3:14:a6:ce:23:dc:75:ce:0c:a5:e3: 40:cf:f9:10:a6:40:93:1f:25:51:f6:7f:5c:a4:74: b7:b3:39 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 93:2E:9C:FB:B3:9D:5B:55:8A:09:81:B4:FB:C2:CA:86:28:9E:EA:88 X509v3 Authority Key Identifier: keyid:F7:C3:04:70:25:38:2F:02:82:5D:5F:2F:7F:1B:66:97:43:9F:D8:0E Signature Algorithm: sha512WithRSAEncryption 5a:54:5d:08:53:1d:39:ef:85:c0:af:8e:85:bf:c9:b4:03:49: b7:dc:4a:42:ab:46:1f:54:d7:8e:6c:cc:70:00:b0:da:c1:8c: d8:92:d1:f1:d9:4d:d9:8f:8a:ad:8e:db:56:1b:8c:c2:63:1d: c4:06:41:f2:07:cd:e3:09:4a:68:06:9d:42:cb:e7:05:86:93: 26:8a:aa:11:fe:74:38:e2:27:9a:0f:a8:38:e3:ea:e6:63:a4: 70:09:7d:01:69:cc:60:f7:c1:32:3a:d6:3d:9a:3d:e1:6f:8e: 54:a7:bc:fe:de:9a:e1:f7:cb:75:65:c3:2e:39:34:8b:fc:42: f2:05:ea:7f:8b:11:90:d7:fc:17:e6:3e:a1:2c:6f:51:89:dc: da:60:12:77:99:2e:b3:20:2a:9b:63:b6:2b:83:60:3c:21:2b: 8d:a7:b6:a1:7c:31:75:08:e9:49:a9:23:60:22:49:b8:26:11: 74:00:a9:1e:0c:25:5b:0d:e2:1e:30:61:07:ca:6c:7e:10:92: d1:19:73:d9:11:53:8c:cc:50:2d:22:23:9d:de:af:02:c8:c0: 07:d3:2e:42:15:1a:78:76:03:93:8c:d1:3a:50:19:05:e2:c0: 6b:58:ae:58:96:10:93:6e:08:7f:b2:c1:53:5c:0e:d2:a7:28: e3:74:34:ad:d6:e2:5c:3b:6d:8f:a6:ab:69:b0:c8:b9:52:28: be:1f:df:2f:b6:e4:e2:e2:b5:b1:c1:e8:b2:cd:ae:01:7c:ee: a1:ae:0d:e2:58:f5:cf:d3:61:d9:48:e2:b0:2e:9a:6c:ce:28: bf:3d:02:67:48:ee:25:28:01:4b:e5:48:97:88:80:66:82:29: cf:55:da:67:1b:b1:6e:99:88:25:92:f6:fc:bc:6f:89:e0:a1: ce:b3:55:8e:39:5a:52:12:ca:06:b7:9a:c3:8a:89:a1:43:53: cf:70:8a:94:87:2f:42:24:3c:12:e9:87:fa:d3:9e:de:33:28: 55:8c:9b:f1:aa:b4:4d:ba:7d:de:b7:33:bc:6b:e2:8a:82:d4: d8:ae:84:78:90:27:3d:e2:15:da:fe:3a:b4:df:46:38:5c:a8: 5b:55:81:91:f2:38:20:2a:f9:28:5d:88:9d:b6:b4:d1:4b:07: 26:a4:ef:ab:fa:e7:e9:34:61:01:8d:77:8d:ae:4b:b7:19:93: dd:64:16:90:a0:86:eb:c2:51:a2:0c:a3:91:b5:d8:cb:70:1b: f0:42:c8:71:19:60:1f:5e:6a:4f:66:2d:42:75:d2:c2:3f:82: b1:3c:c1:5e:67:7b:99:f9:b1:35:16:00:ff:f8:c0:e8:91:8f: 99:f6:cf:7e:07:2e:48:57
# cat /etc/pki/CA/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem
-----BEGIN CERTIFICATE----- MIIGNjCCBB6gAwIBAgIBATANBgkqhkiG9w0BAQ0FADCBnzELMAkGA1UEBhMCREUx DzANBgNVBAgMBkJheWVybjERMA8GA1UEBwwIUGxpZW5pbmcxEzARBgNVBAoMCm5h dXNjaC5vcmcxHjAcBgNVBAsMFVplcnRpZml6aWVydW5nc3N0ZWxsZTETMBEGA1UE AwwKZ3JheWxvZyBDQTEiMCAGCSqGSIb3DQEJARYTY2EtYWRtaW5AbmF1c2NoLm9y ZzAeFw0xNjAxMDQxMDA4NTNaFw00NTEyMjcxMDA4NTNaMIGfMQswCQYDVQQGEwJE RTEPMA0GA1UECAwGQmF5ZXJuMRMwEQYDVQQKDApuYXVzY2gub3JnMRYwFAYDVQQL DA1JVC1Nb25pdG9yaW5nMSkwJwYDVQQDDCByc3lzbG9nLnZtbDAwMDAzNy5kbXou bmF1c2NoLm9yZzEnMCUGCSqGSIb3DQEJARYYZ3JheWxvZy1hZG1pbkBuYXVzY2gu b3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA6mVcmjs+qS1/8aWf s+PNpFP7cDD9yL4A/QQqCPTq0mlmAi3F2bhTjdlafP16khJMq4POeorTDmAWh6Cm IV6WKzaH6YXxG/5Wh+NuMECe9/jyjwX6V9D7EJSkLhbtVcsiYeOsTBNscNrmi4tU 9k7UWFoYBvFhIJgP3EwwTu/Eswxjk4JKiZgua651xzrJYCWsWPza1IM1xpYs2W9e DJ+devIuq/AGW/VKdGICg5p24wTbn+5A1QOtRQ1pvjn0AHXbTfDpVnvlPj5jaSPJ tAri0c1WdkGLQ/P8LgHKIRZ9qSTlZZ0hvGS83eH3iTMoOE4JfF187B9nWsCsPbIy mnPM8sVBTBe3dcqtdjd+pvKFEMXj7pWUstJRzFmWyuQPlsF7iUJQYQFsMzIznXJX okWS8L33R2/BUcC5Bf2pr6hs9psapeQrNAtiBLfDiaqDWlyCsNFyrAvg5JQ8RAuV 6aWXlu7pOLmSdImTMaZeyt342fjq/7NiSkWqHDUF/Cw22rJZr4JpLNdNbN8u/MFK 9uH5V7eDs7FOSDYeV5RlHqk/llYDIUYC3EpURvCZJZzIvyWK1h+6/atwzZbMKDY7 ZrD7SEdZeGlbaWypyqEjVnpH90nPJbUdN4OE/vmKvv++5ZOcwAWZ0xSmziPcdc4M peNAz/kQpkCTHyVR9n9cpHS3szkCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglghkgB hvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYE FJMunPuznVtVigmBtPvCyoYonuqIMB8GA1UdIwQYMBaAFPfDBHAlOC8Cgl1fL38b ZpdDn9gOMA0GCSqGSIb3DQEBDQUAA4ICAQBaVF0IUx0574XAr46Fv8m0A0m33EpC q0YfVNeObMxwALDawYzYktHx2U3Zj4qtjttWG4zCYx3EBkHyB83jCUpoBp1Cy+cF hpMmiqoR/nQ44ieaD6g44+rmY6RwCX0Bacxg98EyOtY9mj3hb45Up7z+3prh98t1 ZcMuOTSL/ELyBep/ixGQ1/wX5j6hLG9RidzaYBJ3mS6zICqbY7Yrg2A8ISuNp7ah fDF1COlJqSNgIkm4JhF0AKkeDCVbDeIeMGEHymx+EJLRGXPZEVOMzFAtIiOd3q8C yMAH0y5CFRp4dgOTjNE6UBkF4sBrWK5YlhCTbgh/ssFTXA7SpyjjdDSt1uJcO22P pqtpsMi5Uii+H98vtuTi4rWxweiyza4BfO6hrg3iWPXP02HZSOKwLppszii/PQJn SO4lKAFL5UiXiIBmginPVdpnG7FumYglkvb8vG+J4KHOs1WOOVpSEsoGt5rDiomh Q1PPcIqUhy9CJDwS6Yf6057eMyhVjJvxqrRNun3etzO8a+KKgtTYroR4kCc94hXa /jq030Y4XKhbVYGR8jggKvkoXYidtrTRSwcmpO+r+ufpNGEBjXeNrku3GZPdZBaQ oIbrwlGiDKORtdjLcBvwQshxGWAfXmpPZi1CddLCP4KxPMFeZ3uZ+bE1FgD/+MDo kY+Z9s9+By5IVw== -----END CERTIFICATE-----
erstellte Zertifikat dem rsyslog-Daemon auf dem Clientrechner zur Verfügung stellen
Als letzten Schritt stellen wir nun das gerade erzeugte Server-Zertifikat dem graylog-server zur Verfügung. Entweder kopieren wir das Zertifikat via scp auf den Clientrechner oder wir legen das BASE64 kodierte Zertifikat direkt mit dem Editor unserer Wahl auf dem Client Host ab.
# vim /etc/pki/tls/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem
-----BEGIN CERTIFICATE----- MIIGNjCCBB6gAwIBAgIBATANBgkqhkiG9w0BAQ0FADCBnzELMAkGA1UEBhMCREUx DzANBgNVBAgMBkJheWVybjERMA8GA1UEBwwIUGxpZW5pbmcxEzARBgNVBAoMCm5h dXNjaC5vcmcxHjAcBgNVBAsMFVplcnRpZml6aWVydW5nc3N0ZWxsZTETMBEGA1UE AwwKZ3JheWxvZyBDQTEiMCAGCSqGSIb3DQEJARYTY2EtYWRtaW5AbmF1c2NoLm9y ZzAeFw0xNjAxMDQxMDA4NTNaFw00NTEyMjcxMDA4NTNaMIGfMQswCQYDVQQGEwJE RTEPMA0GA1UECAwGQmF5ZXJuMRMwEQYDVQQKDApuYXVzY2gub3JnMRYwFAYDVQQL DA1JVC1Nb25pdG9yaW5nMSkwJwYDVQQDDCByc3lzbG9nLnZtbDAwMDAzNy5kbXou bmF1c2NoLm9yZzEnMCUGCSqGSIb3DQEJARYYZ3JheWxvZy1hZG1pbkBuYXVzY2gu b3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA6mVcmjs+qS1/8aWf s+PNpFP7cDD9yL4A/QQqCPTq0mlmAi3F2bhTjdlafP16khJMq4POeorTDmAWh6Cm IV6WKzaH6YXxG/5Wh+NuMECe9/jyjwX6V9D7EJSkLhbtVcsiYeOsTBNscNrmi4tU 9k7UWFoYBvFhIJgP3EwwTu/Eswxjk4JKiZgua651xzrJYCWsWPza1IM1xpYs2W9e DJ+devIuq/AGW/VKdGICg5p24wTbn+5A1QOtRQ1pvjn0AHXbTfDpVnvlPj5jaSPJ tAri0c1WdkGLQ/P8LgHKIRZ9qSTlZZ0hvGS83eH3iTMoOE4JfF187B9nWsCsPbIy mnPM8sVBTBe3dcqtdjd+pvKFEMXj7pWUstJRzFmWyuQPlsF7iUJQYQFsMzIznXJX okWS8L33R2/BUcC5Bf2pr6hs9psapeQrNAtiBLfDiaqDWlyCsNFyrAvg5JQ8RAuV 6aWXlu7pOLmSdImTMaZeyt342fjq/7NiSkWqHDUF/Cw22rJZr4JpLNdNbN8u/MFK 9uH5V7eDs7FOSDYeV5RlHqk/llYDIUYC3EpURvCZJZzIvyWK1h+6/atwzZbMKDY7 ZrD7SEdZeGlbaWypyqEjVnpH90nPJbUdN4OE/vmKvv++5ZOcwAWZ0xSmziPcdc4M peNAz/kQpkCTHyVR9n9cpHS3szkCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglghkgB hvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYE FJMunPuznVtVigmBtPvCyoYonuqIMB8GA1UdIwQYMBaAFPfDBHAlOC8Cgl1fL38b ZpdDn9gOMA0GCSqGSIb3DQEBDQUAA4ICAQBaVF0IUx0574XAr46Fv8m0A0m33EpC q0YfVNeObMxwALDawYzYktHx2U3Zj4qtjttWG4zCYx3EBkHyB83jCUpoBp1Cy+cF hpMmiqoR/nQ44ieaD6g44+rmY6RwCX0Bacxg98EyOtY9mj3hb45Up7z+3prh98t1 ZcMuOTSL/ELyBep/ixGQ1/wX5j6hLG9RidzaYBJ3mS6zICqbY7Yrg2A8ISuNp7ah fDF1COlJqSNgIkm4JhF0AKkeDCVbDeIeMGEHymx+EJLRGXPZEVOMzFAtIiOd3q8C yMAH0y5CFRp4dgOTjNE6UBkF4sBrWK5YlhCTbgh/ssFTXA7SpyjjdDSt1uJcO22P pqtpsMi5Uii+H98vtuTi4rWxweiyza4BfO6hrg3iWPXP02HZSOKwLppszii/PQJn SO4lKAFL5UiXiIBmginPVdpnG7FumYglkvb8vG+J4KHOs1WOOVpSEsoGt5rDiomh Q1PPcIqUhy9CJDwS6Yf6057eMyhVjJvxqrRNun3etzO8a+KKgtTYroR4kCc94hXa /jq030Y4XKhbVYGR8jggKvkoXYidtrTRSwcmpO+r+ufpNGEBjXeNrku3GZPdZBaQ oIbrwlGiDKORtdjLcBvwQshxGWAfXmpPZi1CddLCP4KxPMFeZ3uZ+bE1FgD/+MDo kY+Z9s9+By5IVw== -----END CERTIFICATE-----
Konfiguration graylog-server
Nachdem wir die benötigten Schlüssel und Zertifikate erfolgreich erstellt haben, machen wir uns nun an die Konfiguration des graylog-server.
Speicherort für Client-Zertifikate
Damit der graylog-server die zur Einlieferung von syslog-Daten berechtigten Clients prüfen kann, benötigt dieser ein Verzeichnis, in dem wir die Clientzertifikate ablegen können.
Zunächst erstellen wir uns ein Verzeichnis.
# mkdir /etc/pki/tls/graylog-client-certs
Anschließend kopieren wir das Clientzertifikat unseres Clientrechners vml000037 in das Clientverzeichnis.
# cp /etc/pki/CA/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem /etc/pki/tls/graylog-client-certs/
X.509 Dateien
Bevor wir die Konfiguration über die WEB-GUI unseres graylog-Webservers vornehmen, rufen wir uns die benötigten Zertifikate und Schlüssel noch einmal kurz in Erinnerung. So können wir später die Pfadangaben einfach via cut 'n' paste kopieren.
CA Root-Zertifikat
# ll /etc/pki/CA/certs/root-ca.certifikate.pem
-rw-r--r--. 1 root root 2167 Jan 3 23:57 /etc/pki/CA/certs/root-ca.certifikate.pem
private Schlüssel zum Zertifikat
# ll /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem
-r--------. 1 root root 3243 Jan 4 00:12 /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem
Server-Zertifikat
# ll /etc/pki/tls/certs/graylog-server.dmz.nausch.org.certificate.pem
-rw-r--r--. 1 root root 2212 Jan 4 00:32 /etc/pki/tls/certs/graylog-server.dmz.nausch.org.certificate.pem
graylog Input
Nun öffnen wir den zu konfigurierenden Input in der WEB-GUI mit dem Browser unserer Wahl.
$ firefox https://graylog.nausch.org/system/inputs
Folgende Optionen sind für die TLS-Aktivierung wichtig:
- Port = 6514
- TLS cert file (optional) = /etc/pki/tls/certs/graylog-server.dmz.nausch.org.certificate.pem
- TLS private key file (optional) = /etc/pki/tls/private/graylog-server.dmz.nausch.org.key.pem
- TLS client authentication (optional) = required
- TLS Client Auth Trusted Certs (optional) = /etc/pki/tls/graylog-client-certs
- Enable TLS (optional) * TCP keepalive (optional)
Über die Schaltfläche [ Update input ] verlassen und speichern wir unsere Änderungen.
Mit dem Update des Inputs wird auch der Port 6514 geöffnet; dies können wir mit Hilfe von netstat auch abfragen.
# netstat -tulpen | grep 6514
tcp6 0 0 :::6514 :::* LISTEN 988 9660525 1391/java
iptables Paketfilter
Damit sich unsere Clients auch mit dem Port 6514 verbinden können, benötigen wir eine passende Firewall-Regel, die wir nun noch anlegen müssen.
# firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.0.0.0/24" port protocol="tcp" port="6514" destination address="10.0.0.117/32" accept"
success
Zum Aktivieren führen wir einen reload des firewalld Daemon durch.
# firewall-cmd --reload
Zu guter letzt prüfen wir nun mit Hilfe von telnet, ob wir uns vom client vml000037 mit dem Port 6514 unseres graylog-servers vml000117 verbinden können
# telnet vml000117 6514
Trying 10.0.0.117... Connected to 10.0.0.117. Escape character is '^]'. Connection closed by foreign host.
Konfiguration des rsyslog client
Damit der rsyslog-Daemon TLS-gesicherte Verbindungen aufbauen kann, muss dieser über das Modul lmnsd_gtls verfügen. Dieses Modul ist Bestandteil des RPM-Paketes rsyslog-gnutls.
rsyslog-gnutls Modul installieren
In aller Regel wird das RPM rsyslog-gnutlsnoch nicht installiert sein, so dass wir dieses nun mit Hilfe von yum noch nachholen müssen.
# yum install rsyslog-gnutls -y
Den Inhalt dieses Paketes können wir wir folgt bei Bedarf ermitteln.
# rpm -qil rsyslog-gnutls
Name : rsyslog-gnutls
Version : 7.4.7
Release : 12.el7
Architecture: x86_64
Install Date: Sun 03 Jan 2016 02:12:09 PM CET
Group : System Environment/Daemons
Size : 33480
License : (GPLv3+ and ASL 2.0)
Signature : RSA/SHA256, Wed 25 Nov 2015 04:37:32 PM CET, Key ID 24c6a8a7f4a80eb5
Source RPM : rsyslog-7.4.7-12.el7.src.rpm
Build Date : Fri 20 Nov 2015 12:34:35 PM CET
Build Host : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager : CentOS BuildSystem <http://bugs.centos.org>
Vendor : CentOS
URL : http://www.rsyslog.com/
Summary : TLS protocol support for rsyslog
Description :
The rsyslog-gnutls package contains the rsyslog plugins that provide the
ability to receive syslog messages via upcoming syslog-transport-tls
IETF standard protocol.
/usr/lib64/rsyslog/lmnsd_gtls.so
X.509 Dateien
Wie schon bei der Konfiguration des graylog-server's, rufen wir uns auch hier nochmal die benötigten ins Gedächtnis. Lassen sich so so einfache Typo-Fehler bveim Bearbeiten vermeiden.
Root CA Zertifikat
# ll /etc/pki/CA/certs/root-ca.certifikate.pem
-rw-r--r--. 1 root root 2167 Jan 4 12:18 /etc/pki/CA/certs/root-ca.certifikate.pem
Client-Zertifikat
# ll /etc/pki/tls/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem
-rw-r--r--. 1 root root 2216 Jan 4 11:13 /etc/pki/tls/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem
Schlüssel zum Client-Zertifikat
# ll /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem
-r--------. 1 root root 3243 Jan 4 10:57 /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem
rsyslog konfigurieren
Nun bearbeiten wir die Konfigurationsdatei unseres rsyslog-Daemon und hinterlegen dort die entsprechenden Pfadangaben zu dem lmnsd_gtls-Modul, der Schlüsseldatei und den Zertifikaten. Die wichtigsten Änderungen sind hier noch einmal zusammengefasst:
- $DefaultNetstreamDriver gtls
- $DefaultNetstreamDriverCAFile /etc/pki/ca-trust/source/anchors/root-ca.nausch.org.pem
- $DefaultNetstreamDriverCertFile /etc/pki/tls/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem
- $DefaultNetstreamDriverKeyFile /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem
- $ActionSendStreamDriverAuthMode x509/name
- $ActionSendStreamDriverPermittedPeer graylog-server.dmz.nausch.org
- $ActionSendStreamDriverMode 1
Alle Änderungen in der Konfigurationsdatei sind mit dem Namen Django : <Datumsstempel> versehen.
# vim /etc/rsyslog.conf
- /etc/rsyslog.conf
# rsyslog configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### MODULES #### # Django : 2016-01-03 # default: unset $DefaultNetstreamDriver gtls #make gtls driver the default # The imjournal module bellow is now used as a message source instead of imuxsock. $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imjournal # provides access to the systemd journal #$ModLoad imklog # reads kernel messages (the same are read from journald) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # Provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 #### GLOBAL DIRECTIVES #### # Where to place auxiliary files $WorkDirectory /var/lib/rsyslog # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # File syncing capability is disabled by default. This feature is usually not required, # not useful and an extreme performance hit #$ActionFileEnableSync on # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf # Turn off message reception via local log socket; # local messages are retrieved through imjournal now. $OmitLocalLogging on # File to store the position in the journal $IMJournalStateFile imjournal.state # Django : 2016-01-03 - certificate files for TLS # default: unset $DefaultNetstreamDriverCAFile /etc/pki/ca-trust/source/anchors/root-ca.nausch.org.pem $DefaultNetstreamDriverCertFile /etc/pki/tls/certs/rsyslog.vml000037.dmz.nausch.org.certificate.pem $DefaultNetstreamDriverKeyFile /etc/pki/tls/private/rsyslog.vml000037.dmz.nausch.org.key.pem $ActionSendStreamDriverAuthMode x509/name $ActionSendStreamDriverPermittedPeer graylog-server.dmz.nausch.org # run driver in TLS-only mode $ActionSendStreamDriverMode 1 #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg :omusrmsg:* # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log # Django : 2015-07-14 Logging für OpenLDAP-Server aktiviert local4.* -/var/log/ldap.log # # ### begin forwarding rule ### # The statement between the begin ... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # # Django : 2015-06-12 #$template GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" #*.* @@10.0.0.117:514;GRAYLOGRFC5424 # Django : 2016-01-03 $template GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" *.* @@10.0.0.117:6514;GRAYLOGRFC5424 # # ### end of the forwarding rule ###
Zum Aktivieren der Änderungen führen wir nun einmal einen Reboot des rsyslog-Daemon durch.
# systemctl restart rsyslog.service
Im Syslog unseres Servers wir der erfolgreiche Neustart des rsyslog-Daemon entsprechend positiv vermerkt.
# tailf /var/log/messages
Jan 4 12:34:45 vml000037 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="28477" x-info="http://www.rsyslog.com"] exiting on signal 15. Jan 4 12:34:45 vml000037 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="28869" x-info="http://www.rsyslog.com"] start
Rufen wir nun wieder die Web-GUI unseres graylog-Webservers auf, wird sowohl die aktive Verbindung wie auch die bereits übertragenen Daten angezeigt.
$ firefox https://graylog.nausch.org/system/inputs
Alles in allem können wir feststellen, dass mit einem überschaubaren Aufwand, die Kommunikation zwischen den rsyslog-Clients und unserem graylog-server sicher und nur noch von authorisierten Quellen gestattet werden kann.