Seite wählen

NETWAYS Blog

Graylog: Basics für eine Best Practice Installation

Graylog hat hier einiges an Best Practice definiert, die Euch dabei hilft, eine stabil und sicher laufende Installation aufzubauen. Ein Hauptaugenmerk liegt dabei auf der Anzahl der Nodes, die für eine produktiv eingesetzte Umgebung folgendermaßen aussieht:

  • mehrere Graylog Nodes mit evtl. vorgeschaltetem Loadbalancer. Hier sollte auch im Nachhinein immer wieder über entsprechende Skalierungen oder Performance-Optimierungen nachgedacht werden.
  • jeder Graylog Node ist an die MongoDB Datenbank angeschlossen. Die MongoDB Instanzen sollten als Replica Set aufgesetzt sein.
  • ein Elasticsearch Cluster bestehend aus mindestens drei Nodes, um hier mit einem Quorum arbeiten zu können. (Vermeidung von Split Brain!)
  • ein Browser Eurer Wahl für den Zugriff auf die Graylog Web GUI

 

Hier eine schematische Darstellung einer Produktivumgebung:

Quelle: https://docs.graylog.org/docs/architecture

Des Weiteren sollten Log-Daten mithilfe der geeigneten Tools, z. B. syslog, GELF oder den Beats in Graylog wandern.  Zusätzlich wird ein Loadbalancer empfohlen, über den die gesamte Kommunikation mit Graylog erfolgt und somit eine Verteilung der Last ermöglicht und die Performance optimiert. Die Kommunikation umfasst hierbei alle Aufrufe über den Browser per HTTP(S) sowie die Weiterleitung der Log-Dateien an die vorhin genannten Graylog Nodes.

Wer hier tiefer einsteigen möchte, dem seien die folgenden Links zur Graylog Dokumentation empfohlen:

 

Natürlich könnt Ihr Euer KnowHow auch mit unserer Unterstützung aufbauen und erweitern! Ihr benötigt z. B. Unterstützung bei der Skalierung Eurer Umgebung? Ihr habt neue Systeme, deren Log Daten in Graylog laufen sollen? Ihr möchtet auf Graylog Enterprise umsteigen und benötigt eine Lizenz? Mit all diesen Fragen könnt Ihr einfach auf uns zukommen über unser Kontaktformular oder per Mail an sales@netways.de.

Infos zu Schulungen und deren Buchung zum Thema Graylog könnt Ihr hier finden: Graylog Schulung

SSL leicht gemacht – Zertifikat einbinden (Apache2)

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.
Bestandsaufnahme:
nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.
Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Hier sollte die Zusammengehörigkeit der einzelnen Dateien noch einmal überprüft werden. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen „SSL zu sprechen“. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.
Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.
Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann „ignoriert“ werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Aktivierung JMX

Hallo zusammen, heute fassen wir wieder ein Grundthema auf, welches wohl oft Fragen aufwirft aber so einfach sein kann. Die Rede ist von der Aktivieren der JMX– oder auch Java Management Extension genannt.
In unserem Blog haben wir schon viele Themen gehabt, welche sich mit JMX Monitoring auseinander setzen – Jolokia, JConsole oder die Überwachung mit Nagios. Aber noch keinen, welcher in den Grundzügen zeigt, wie es aktiviert wird, also gehen wir einen Schritt zurück und zeigen auch dies.
Wir machen das ganze am Beispiel des Apache Tomcats – aber da JMX vom Java bereitgestellt wird, besteht die Möglichkeit bei vielen Application Server und meist auch bei Standalone Systemen. Nun aber zum Setup selbst, nehmt euer Start-Skript des Tomcats oder die des Application Server oder die Environment Settings von Standalone Systemen. Hier müssen nun nur die Java Optionen angepasst werden. Für ein schlichtest Setup mit Remote Zugang und einer Passwortabfrage fügt ihr folgendes an:

-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=_WUNSCHPORT_ \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.password.file=.../CONF_PFAD/jmxremote.password \
-Dcom.sun.management.jmxremote.access.file=../CONF_PFAD/jmxremote.access

Die Regelung der Anmeldung und der Rollen macht Ihr mit der jmxremote.access und .password Datei. Hier wird vermerkt, welche Login welche Rollen hat (readonly/readwrite – .access) und welche Passwörter für die Rollen gelten (.password). Zu beachten wäre hierbei, dass das Passwort-File nur vom User des Server zu lesen/schreiben ist, die Access-Datei dagegen kann default mit 644 belassen werden:

chmod 600 .../CONF_PFAD/jmxremote.password
chown APP_USER .../CONF_PFAD/jmxremote.password

Nun startet Ihr die Application und ruft z.B. wie mit der JConsole beschrieben, den Server und Port mit den Anmeldedaten auf.
Das ganze ist – wie gesagt – nur ein Grundsetup und es gibt noch mehr Möglichkkeiten den Zugriff anzupassen. Aber Ihr könnt das o.g. Beispiel nutzen um etwaige Überwachungen für das Monitoring zu implementieren oder einfach mal ein paar mehr Infos über einen Prozess zu bekommen.