19Jul/170

Auslesen von Log-Dateien unter Linux und Windows

Jeder kennt es, man möchte ein Problem auf dem Server oder dem Heimcomputer genauer untersuchen, doch wo findet man die relevanten Informationen?

Im Folgenden werden wir auf spezifische Log-Dateien in Linux und auf den Windows Event Viewer näher eingehen. Ein weiterer Abschnitt wird die Log-Analyse unter Linux via Systemd behandeln.

Linux Log-Dateien

Leider ist es von Distribution zu Distribution unterschiedlich, welche Informationen aus welcher Log-Datei bezogen werden können. Wir werden im folgenden speziell die Struktur anhand von Debian 8 und CentOS 7.2 behandeln. Im Prinzip kann man sehr viele nützliche Log-Dateien unter dem Verzeichnis /var/log/ finden. Je nachdem, wie Apache, Nginx oder ähnliche Programme konfiguriert wurden, loggen diese ebenfalls in das /var/log/ Verzeichnis. In der Datei unter /etc/rsyslog.conf ist genau spezifiziert, welche Art von System-Logs in welche Datei geloggt werden.

Debian 8:

  • /var/log/auth.log

Hier können erfolgreiche und nicht erfolgreiche Login-Versuche auf Ihrem System eingesehen werden. Ebenfalls wird hier geloggt, wenn ein Benutzer via sudo Befehle ausführt.

  • /var/log/messages

In dieser Datei werden allgemeine Systeminformationen geloggt, unter anderem ist hier auch der Systemstart geloggt.

  • /var/log/dmesg bzw dmesg

Via dmesg kann der "Kernel ring buffer" ausgelesen werden. Hier finden sich Informationen über den Systemstart, Kernel-Nachrichten die zur Laufzeit - zum Beispiel von Kernel -Modulen - geschrieben wurden und viele weitere nützliche Informationen über Hardware und Software des Systems. Standardmäßig wird via dmesg der gesamte "ring buffer" ausgegeben. Man kann allerdings die Ausgabe nach eigenen Wünschen manipulieren, indem man weitere Parameter übergibt. Eine vollständige Dokumentation finden man auf der Manual Page (man dmesg).

  • /var/log/syslog

Dies ist eine der wichtigsten Log-Dateien, da hier im Prinzip jeder Linux-Prozess seine Logs anhängen kann.  Man kann hier ebenfalls die Kernel-Logs des Systemstarts, ausgeführte cron-jobs und Logs von jedem weiteren Prozess welcher die syslog Schnittstelle implementiert, einsehen.

CentOS 7.2:

Die Logging-Struktur von CentOS ist der von Debian 8 sehr ähnlich, weshalb wir hier nur die Unterschiede beleuchten werden.

  • /var/log/secure

Diese Datei ist das Äquivalent zu /var/log/auth.log auf Debian-Systemen. Authentifizierungen jeglicher Art werden hier aufgezeichnet.

  • /var/log/messages

In CentOS gibt es keine Trennung zwischen /var/log/messages und /var/log/syslog, alle systemweiten Logs von Prozessen, welche die syslog Schnittstelle implementieren, kann man hier finden.

  • /var/log/cron

Cron-spezifische Logs sind nicht Teil des syslogs wie in Debian, sondern werden in die obige Datei separat geloggt.

 

Loganalyse via Systemd

Systemd ist mittlerweile auf fast allen "Major" Linux-Distributionen das Standard Init System. Spätestens seit April 2015, als es ebenfalls standardmäßig auf Debian und Ubuntu eingeführt wurde, kommt jeder Administrator oder auch Benutzer mit Systemd in Berührung. Da Systemd ein sehr komplexes System ist, werden wir hier nur speziell auf die von Systemd bereitgestellte Log-Analyse eingehen. Im Prinzip sind alle via Systemd verwalteten Prozesse in sogenannte "Units" eingeteilt. Man kann alle aktiven Units mit folgendem Befehl auflisten:

systemctl list-units

Mit dem Parameter --all kann man auch alle inaktiven Units mit ausgeben.

Logs, welche via Systemd erfasst werden, werden im sogenannten Journal verwaltet. Diese Logs kann man mit dem binary journalctl einsehen.

Wenn man journalctl ohne Parameter aufruft, wird das gesamte Journal ausgegeben. Es ist aber auch ohne Probleme möglich, nur Logs von spezifischen Units auszugeben. Im folgenden Beispiel sollen die Logs des Apache-Webservers genauer untersucht werden.

journalctl -u httpd

Man kann diese Logs mit den Parametern --since und --until sehr fein granulieren.

journalctl -u httpd --since "2016-11-01 20:00:00" --until "2016-11-03 20:00:00"

Obiger Befehl würde die Apache-Logs zwischen 2016-11-01 20:00:00 und 2016-11-03 20:00:00 ausgeben. Es sind auch Schlagwörter wie "today" und "yesterday" möglich.

Man kann sich ebenfalls die Logs von mehreren Units gleichzeitig ausgeben lassen. Im folgenden Beispiel werden alle Apache- und Nginx-Logs ausgegeben, welche seit gestern geschrieben wurden.

journalctl -u httpd -u nginx --since yesterday

Wenn man den Parameter -f benutzt, kann man die gewünschten Logs live einsehen.

Dies waren nur ein paar nützliche Parameter um die Logs feiner zu granulieren, es gibt noch zahlreiche weitere nützliche Möglichkeiten, welche auf der Manual Page genauer beschrieben sind (man journalctl).

 

Loganalyse via Windows Event Viewer

Windows Event Viewer Übersicht

Im obigen Bild gibt es in der linken Navigation den Punkt "Windows Logs". Hier sind vor allem folgende Punkte interessant:

  • Application

Unter diesem Punkt werden Ereignisse von lokal installierten Anwendungen angezeigt.

  • Security

Hier werden erfolgreiche und fehlgeschlagene Anmeldungen protokolliert.

  • System

Unter diesem Punkt kann man betriebssysteminterne Ereignisse und Fehler einsehen.

Unter dem Punkt "Custom Views" -> "Server Roles" -> "Remote Desktop Services" werden RDP Verbindungen und Probleme protokolliert.

Eventuelle Hardware-Probleme kann man über "Application and Service Logs" -> "Hardware Events" identifizieren.

Hilfreich bei einer Problemanalyse ist auch der Punkt "Overview and Summary" -> "Summary of Administrative Events", welcher einen sehr guten Überblick über den derzeitigen Systemstatus gibt.

13Jan/170

Windows Updates bearbeiten (WS 2016)

Mit der Einführung von Windows Server 2016 hat sich auch die Verwaltung der Windows Updates leicht geändert. In diesem Tutorial möchten wir Ihnen jetzt erklären, welche Einstellungsmöglichkeiten bezüglich der Windows Updates von Windows Server 2016 bereitgestellt werden.

Bitte verbinden Sie sich über RDP mit Ihrem Server und öffnen die "Settings" App über das Windows Startmenü.

Daraufhin klicken Sie bitte auf "Update & Security", woraufhin Sie auf folgenden Bildschirm gelangen.

Alle Update Einstellungsmöglichkeiten können von diesem Bildschirm aus verwaltet werden.

Es gibt den Button "Check for updates", welcher nach den neuesten Updates sucht und diese automatisch herunterlädt und installiert. Sollte ein installiertes Update einen Neustart erfordern, wird Windows einen Zeitpunkt hierfür automatisch planen. Über den Link "Change active hours" kann man einen Zeitraum festlegen in dem der Neustart nicht durchgeführt werden darf.

Über den Link "Restart options" kann man einen exakten Zeitpunkt für den Neustart festlegen.

Der Link "Update history" öffnet eine Übersicht der bereits installierten Updates. Hier ist es möglich, Updates zu deinstallieren und weitere Wiederherstellungsoptionen einzusehen.

Über den Link "Advanced options" kann man unter anderem einstellen, dass auch andere Microsoft Produkte über das Windows Update aktuell gehalten werden. Man hat ebenfalls die Möglichkeit "Defer feature updates" zu aktivieren. Diese Option wird von Microsoft wie folgt beschrieben: "Wenn defer upgrades aktiviert ist, werden keine neuen Windows Features für mehrere Monate heruntergeladen und installiert. Diese Einstellung hat keinen Einfluss auf Sicherheitsupdates, welche weiterhin installiert werden".

Über den Link "Privacy settings" kommt man zu den allgemeinen Datenschutz Einstellungen von Windows.

17Nov/160

Let’s Encrypt!

In der heutigen Zeit ist Datensicherheit sehr wichtig und Verschlüsselung ist ein wichtiger Bestandteil dieses Themas. Leider ist das Verschlüsseln in vielen Fällen ein komplexer Prozess, welcher von vielen Benutzern aufgrund fehlender Fachkenntnisse nicht oder nur ungenügend bewältigt werden kann. Um eine Webseite via Secure Socket Layer (SSL) beziehungsweise über Transport Layer Security (TLS) abzusichern, sodass diese über das Hypertext-Transfer-Protocol Secure (HTTPS) erreichbar ist, ist ein Zertifikat notwendig.

Dieses Zertifikat dient als Basis für verschlüsselte Verbindungen. Wenn ein Benutzer auf eine via HTTPS verschlüsselte Seite zugreifen möchte, wird eine verschlüsselte Verbindung aufgebaut.  Bevor diese Verbindung aufgebaut werden kann, wird das vom angefragten Server präsentierte Zertifikat überprüft. Hierbei wird überprüft, ob dem vom Server übermittelten Zertifikat vertraut werden kann.  Diese Vertrauensüberprüfung funktioniert etwas vereinfacht dargestellt folgendermaßen:

  1. Überprüfung der Signatur des Zertifikats auf Basis der Vertrauenskette
  2. Überprüfung ob die aufgerufene Domain mit der für das Zertifikat hinterlegten übereinstimmt

Was genau ist die Vertrauenskette des Zertifikats?

Im Prinzip sind in jedem Betriebssystem und zum Teil auch in Browsern wie Mozilla Firefox und Google Chrome Zertifikate von vertrauenswürdigen Zertifizierungsstellen vorinstalliert. Diesen Zertifikaten wird, sofern sie nicht zwischenzeitlich für ungültig erklärt wurden, immer vertraut. Bei der Überprüfung der Vertrauenskette wird, vereinfacht ausgedrückt, überprüft, ob der Signatur des Zertifikats bereits von den vorinstallierten Zertifikaten der vertrauenswürdigen Zertifizierungsstellen vertraut wird. Man spricht hier von einer Vertrauenskette, da es zum Beispiel möglich ist, dass der Signatur von Let's Encrypt auf Ihrem System nicht vertraut wird, allerdings wurde das Let's Encrypt Zertifikat, welches zum Signieren Ihres Zertifikats benutzt wurde, ebenfalls von einer dritten Zertifizierungsstelle signiert, welcher auf Ihrem System vertraut wird. Somit bürgt Let's Encrypt dafür, dass Ihr Zertifikat vertrauenswürdig ist und die dritte Zertifizierungsstelle, welcher auf Ihrem System vertraut wird, bürgt für die Vertrauenswürdigkeit von Let's Encrypt.

Wo und wie ist das Let's Encrypt Projekt einzuordnen?

Da der Aufbau und Betrieb einer vertrauenswürdigen Zertifizierungsstelle aufwändig und mit Kosten verbunden ist, war es bisher gang und gäbe, dass man für ein signiertes Zertifikat, dessen Signatur bereits von den vorinstallierten Zertifikaten vertraut wird, bezahlen muss. Let's Encrypt hat ebenfalls eine vertrauenswürdige Zertifizierungsstelle aufgebaut, welche kostenlos Zertifikate signiert und den Prozess der Zertifikatserstellung und Installation weitestgehend vereinfachen und automatisieren möchte. Der Hauptgedanke ist dabei, ein sichereres Internet voranzutreiben.

Automatische Zertifikate bei unseren Webspace Paketen

Wie wir bereits ausführlich im Post Webspace: Kostenlose SSL-Zertifikate sind ab sofort verfügbar informiert haben, ist auf unseren Webspace Paketen automatisch ein Zertifikat für die hinzugefügten Domains via Let's Encrypt aktiviert. Selbst das manuelle Erneuern der Zertifikate ist nicht mehr notwendig, da es ebenfalls automatisch passiert.

Let's Encrypt via AutoSSL in cPanel

Seit cPanel & WHM Version 58.0.17 wird Let's Encrypt offiziell von cPanel unterstützt. Zum jetzigen Zeitpunkt muss die Integration in AutoSSL vom Benutzer noch selbständig via Shell angestoßen werden. Hierfür muss das Installationsskript unter

/scripts/install_lets_encrypt_autossl_provider

 

als root Benutzer ausgeführt werden.

Nach erfolgreicher Installation kann Let's Encrypt unter Home >> SSL/TLS >> Manage AutoSSL als Zertifikat Provider ausgewählt werden.

autossl_lets_encryptEinstellungen für spezifische Benutzer können unter dem Reiter "Manage Users" vorgenommen werden.

Let's Encrypt über eine Erweiterung in Plesk

Auch Plesk unterstützt ab Version 12.5 Let's Encrypt über eine Erweiterung. Die Installation und Konfiguration in dieser Anleitung funktioniert für Linux und Windows Installationen gleichermaßen.

Um die Erweiterung zu installieren, gehen Sie bitte in Plesk zu:

"Tools & Settings" >> Oberpunkt "Plesk" >> "Updates & Upgrades"

Es öffnet sich ein neuer Tab, für den Sie eventuell im Browser noch ein selbst signiertes Zertifikat bestätigen müssen. In diesem Tab wechseln Sie bitte zu: "Add/Remove Components".

plugin

Wählen Sie bitte die Erweiterung, wie in Bild oben dargestellt, zur Installation aus und bestätigen Sie mit "Continue". Sobald das Plugin installiert ist, wird die Meldung "All operations with products and components have been successfully completed." erscheinen. Mit einem Klick auf OK kommen Sie wieder in das Hauptmenü. Sie können den Tab nun schließen.
Nun müssen Sie nur noch ein Zertifikat beziehen und es für die Domain aktivieren. Bitte wechseln Sie hierfür zu "Websites & Domains" und klappen Sie alle Optionen für die gewählte Domain auf. Hier ist nun die Option Let's Encrypt hinzugekommen:

letsencrypt

Öffnen Sie bitte diese Verlinkung und überprüfen Sie die E-Mail Adresse. Überlegen Sie, ob die Seite auch über www erreichbar sein soll und setzen Sie gegebenenfalls den Haken bei "Include www.ihredomain.de as an alternative domain name.". Schicken Sie abschließend, mit einem Klick auf "OK", die Anfrage für das Zertifikat ab. Sobald der Vorgang abgeschlossen ist, sollte Ihre Seite bereits über https aufrufbar sein. Zur Sicherheit können Sie aber auch noch in die "Hosting Settings" für Ihre Domain gehen, dort im Bereich "Security" die permanente Weiterleitung auf https aktivieren und das soeben bezogene Zertifikat aktiv auswählen, falls es noch nicht gesetzt ist. Wenn es bei dem Anfordern des Zertifikates zu einer Fehlermeldung kam, sollten Sie überprüfen, ob der A-Record für die gewählte Domain auf Ihre Server IP zeigt. Das gilt auch für die eventuell aktivierte Subdomain "www".

Benutzung von Let's Encrypt ohne Administration Panel (Debian 8)

Es wird empfohlen, Certbot in Verbindung mit Let's Encrypt zu benutzen. In unserem Beispiel benutzen wir Apache als Webserver und Debian 8 als Betriebssystem.

Als root Benutzer müssen folgende Befehle ausgeführt werden um Certbot für Apache und dessen Abhängigkeiten zu installieren:

# Debian Jessie backports repository aktivieren

echo "deb http://ftp.debian.org/debian jessie-backports main" >> /etc/apt/sources.list && apt-get update

 

# Certbot installieren

apt-get install python-certbot-apache -t jessie-backports

 

Nach dem Abschluss der Installation ist es via Certbot möglich, vollautomatisch signierte Zertifikate für Ihre Domains zu generieren. Diese werden dann, ebenfalls automatisch, in Apache für Sie konfiguriert. Folgender Befehl startet einen Konfigurationsdialog  in dem benötigte Informationen wie, Domain Namen und E-Mail Adresse abgefragt werden. Nach der Eingabe der erforderlichen Informationen und dem Bestätigen der AGB von Let's Encrypt, werden Ihre signierten Zertifikate bezogen und automatisch in Apache konfiguriert. Es ist ebenfalls möglich zu konfigurieren, ob Ihre Domains via HTTP und HTTPS oder nur via HTTPS erreichbar sein sollen.

# Automatischen Konfigurationsdialog starten

certbot --apache

Falls man das Zertifikat selbst konfigurieren möchte, kann folgender Befehl benutzt werden welcher nur das Zertifikat erstellt.

# Zertifikat Erstellen ohne automatische Konfiguration in Apache

certbot --apache certonly

Certbot funktioniert nicht nur in Verbindung mit dem Apache Webserver und Debian 8, es sind viele Betriebssystem und Webserver Kombinationen möglich, welche unter folgendem Link eingesehen werden können: Certbot.

Installation von Let's Encrypt ohne Administration Panel (CentOS 7.2)

Da die Benutzung von Certbot auf CentOS exakt wie auf Debian 8 funktioniert, wird im folgenden nur kurz auf die Installation von Certbot auf CentOS eingegangen. Da die Apache/httpd default Installation (yum install httpd) auf CentOS nicht das SSL Modul installiert, muss darauf geachtet werden, dass dieses ebenfalls installiert ist.

# Extra Packages for Enterprise Linux und optional mod_ssl installieren

yum install epel-release mod_ssl 

# Certbot installieren

yum install python-certbot-apache

 

Automatische Verlängerung der Zertifikate einrichten

Da Zertifikate von Let's Encrypt nur eine Gültigkeit von drei Monaten haben, ist es wichtig, eine automatische Verlängerung einzurichten.

Bei der Installation des Debian 8 Pakets von Certbot wurde solch ein "cron-job" bereits automatisch eingerichtet. Auf CentOS wird dieser nicht automatisch eingerichtet, allerdings kann man diesen, wie unten stehend, auf einer Standard CentOS Installation anlegen.

# /etc/cron.d/certbot

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew

 

Dieser cron-job wird alle 12 Stunden ausgeführt und erneuert die Gültigkeit aller Zertifikate, falls diese weniger als 30 Tage Gültigkeit aufweisen. Es wird empfohlen, dass alle 12 Stunden die Gültigkeit der Zertifikate überprüft wird, damit man zeitnah mitbekommt, ob Zertifikate für ungültig erklärt wurden.

 

 

Posted by: Dirk | Tagged as: , , , No Comments