ubuntuusers.de

2. Juni 2018

Dieser Artikel ist auf Wunsch von intux entstanden.

Im folgenden Artikel möchte ich darauf eingehen, wie man Prosody mit Let's Encrypt nutzen kann, ohne Zertifikate zu kopieren, Script zu schreiben oder die Rechte auf die Zertifikate zu ändern, damit Prosody sie lesen und nutzen kann.

Vorraussetzungen

Im Artikel gehe ich davon aus, dass ihr Prosody bereits installiert und eingerichtet habt. Zusätzlich gehe ich davon aus, dass ihr mit LE bereits für die entsprechende Domain Zertifikate angefordert habe und zwar für:

  • example.org
  • conference.example.org

Das lässt sich sehr schön mit der DNS Überprüfung von LE lösen.

Die Zertifikate sollten in dem Ordner

/etc/letsencrypt/live/example.org/

liegen und ihr nutzt den certbot für die Erstellung eurer Zertifikate.

Prosody SSL Konfiguration

Ich werde nur ganz kurz anschneiden, wie eine "sichere" SSL Konfiguration für die Verwendung mit Prosody aussehen sollte:

c2s_require_encryption = true;
s2s_require_encryption = true;
s2s_secure_auth = true;

ssl = {
    protocol = "tlsv1_2"; 
    ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
    options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" };
    dhparam = "/etc/prosody/dhparam.pem";
}

Bitte keine Angaben in die Datei wo das Zertifikate liegt, wenn ihr diese bereits habt, könnt ihr diese löschen.

Die Datei /etc/prosody/dhparam.pem wird mit dem folgenden Befehl erstellt:

openssl dhparam -dsaparam -out /etc/prosody/dhparam.pem 4096

Achtung: Das dauert sehr lange, ich empfehle es mit screen zu machen.

Prosody & Let's Encrypt

So jetzt kommen wir zum eigentlichen Teil, wichtig hier, dass ihr min. Version 0.10 habt:

root@vps73846:/etc/prosody# apt-cache policy prosody
prosody:
  Installed: 0.10.1-1~stretch1
  Candidate: 0.10.1-1~stretch1
  Version table:
 *** 0.10.1-1~stretch1 500

Um die aktuelle Version unter Debian Stable (Stretch) zu bekommen, solltet ihr die Prosody Repo nutzen.

So jetzt führen wir einfach den folgenden Befehl aus:

prosodyctl --root cert import /etc/letsencrypt/live

Wichtig, nur auf den live Ordner, nicht im example.org Ordner.

Prosody erkennt automatisch die richtigen Zertifikate und konfiguriert sich dementsprechend. Das war es eigentlich auch schon. Aber nur fast.

Das Problem, die Zertifikate müssen nach jedem neu erstellen wieder eingelesen werden. Dazu nutzen wir die Möglichkeit der globalen Konfigurationsdatei von Let's Encrypt, /etc/letsencrypt/cli.ini

Der Inhalt sollte so aussehen, ja ihr müsste die Datei erst anlegen

# Global config for letsencrypt runs
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.

renew-hook = prosodyctl --root cert import /etc/letsencrypt/live
post-hook = prosodyctl --root cert import /etc/letsencrypt/live

So das wars. Jetzt haben wir Prosody mit den aktuellen LE Zertifikaten ausgerüstet und auch dafür gesorgt, das es immer die aktuellen Zertifikate bekommt.

1. Juni 2018

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?

SLEMP 0.5 - Sicherer LEMP-Server

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

SLEMP 0.5 - Sicherer LEMP-Server

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)

SLEMP 0.5 - Sicherer LEMP-Server

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

SLEMP 0.5 - Sicherer LEMP-Server

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?

SLEMP 0.5 - Sicherer LEMP-Server

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

SLEMP 0.5 - Sicherer LEMP-Server

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)

SLEMP 0.5 - Sicherer LEMP-Server

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

SLEMP 0.5 - Sicherer LEMP-Server

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)

SLEMP 0.5 - Sicherer LEMP-Server

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

SLEMP 0.5 - Sicherer LEMP-Server

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)

SLEMP 0.5 - Sicherer LEMP-Server

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

SLEMP 0.5 - Sicherer LEMP-Server

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. 🙂

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! 🙂

Der Beitrag SLEMP 0.5 – Sicherer LEMP-Server erschien zuerst auf timscha.io.

Das folgende PhantomJS-Skript listlinks.js, listet alle Hyperlinks einer Website auf, wobei JavaScript und Frames unterstützt werden.

Damit ist es z.B. möglich…

  • sich über Gratisaktionen von Steam Informieren lassen (Free Weekend/Free For a Limited Time)
  • Werbebanner von Google Ads/Ad Scence automatisiert anklicken

Hinweis: Mittlerweile auch als Projekt auf Github zu finden: https://github.com/1nn3/listlinks

#!/usr/bin/phantomjs
// listlinks.js
// Lists all hyperlinks of an URL, supports JavaScript and Frames
// See also: http://phantomjs.org/api/
"use strict";

// Um Endlosrekursion in der Frametiefe zu erkennen und abzufangen
// FIXME: Make it a constant
// const FRAME_RECURSION_MAX_DEPTH = 10;
// SyntaxError: Unexpected token 'const'
// See: https://github.com/ariya/phantomjs/issues/14521
var FRAME_RECURSION_MAX_DEPTH = 10;

function getAttributesFromAllElementsByTagName(tagName, attributeList) {
	var elements = window.document.getElementsByTagName(tagName);

	var values = [];
	for (var i = 0; i < elements.length; i++) {
		values.push({});

		for (var j = 0; j < attributeList.length; j++) {
			values[i][attributeList[j]] = elements[i].getAttribute(attributeList[j]) || "";
		}

		values[i]["textContent"] = elements[i].textContent || "";
	}
	return values;
}

function listLinks () {
	var a = page.evaluate(getAttributesFromAllElementsByTagName, "a", ["href"]);

	for (var i = 0; i < a.length; i++) {
		// FIXME: Use the class URL to get an absolut URL
		// See: https://github.com/ariya/phantomjs/issues/14349
		var href = new URL(a[i]["href"], page.url).href || a[i]["href"];
		var textContent = a[i]["textContent"].replace(/\s+/g, " ");
		system.stdout.writeLine(href + "\t" + textContent);
	}
}

function getFrames (parrents) {
	var a = page.evaluate(getAttributesFromAllElementsByTagName, "iframe", []);

	var frames = [];
	for (var i = 0; i < a.length; i++) {
		frames.push(parrents.concat([i])); // frame position
	}
	return frames;
}

function walkThroughFrames (frames) {
	for (var i = 0; i < frames.length; i++) {
		system.stderr.writeLine("I: Switching to frame: " + frames[i].toString() + " frameName=" + page.frameName + " frameURL=" + page.frameUrl);

		if (frames[i].length > FRAME_RECURSION_MAX_DEPTH) {
			system.stderr.writeLine("W: FRAME_RECURSION_MAX_DEPTH reached!");
			continue;
		}

		page.switchToMainFrame();
		for (var j = 0; j < frames[i].length; j++) {
			page.switchToFrame(frames[i][j]);
		}

		listLinks();
		walkThroughFrames(getFrames(frames[i])); // subframes
	}
}

var system = require('system');

if (system.args.length != 2) {
	system.stderr.writeLine("Usage: " + system.args[0] + " <url>");
	phantom.exit(1);
}

var page = require("webpage").create();
page.settings.javascriptEnabled = true
page.settings.userAgent = system.env["LISTLINKS_USER_AGENT"] || "";

page.open(system.args[1], function (status) {
	if (status !== "success") {
		system.stderr.writeLine("E: Fail to load URL: " + system.args[1]);
		phantom.exit(1);
	}

	listLinks();
	walkThroughFrames(getFrames([]));
	phantom.exit(0);
});

Download: fp-content/attachs/listlinks.js

Zur Installation laden das Skript nach /usr/local/bin/ herunter und machen es ausführbar. Dies ist für die Beispiele unten notwendig!

# wget -O /usr/local/bin/listlinks https://0010100.net/blog/fp-content/attachs/listlinks.js
# chmod +x /usr/local/bin/listlinks

Benutzt wird es dann so:

$ listlinks <URL>

Sich über Gratisaktionen von Steam Informieren lassen (Free Weekend/Free For a Limited Time)

Mit dem Shell-Skript free-games-on-steam.sh, kann man sich über Gratisaktionen von Steam informieren lassen (Free Weekend/Free For a Limited Time). Dazu erstellt man einen Cronjob: @hourly free-games-on-steam 2>/dev/null

So bekommt man alle neuen Gratisaktionen via Mail mitgeteilt.

#!/bin/sh

set -e

seen="${XDG_CACHE_HOME:-$HOME/.cache}/free-games-on-steam.seen"
listlinks="$(which listlinks)"
url="https://store.steampowered.com/news/?headlines=1"

mkdir -p "$(dirname "$seen")"
touch "$seen"

xvfb-run --auto-servernum "$listlinks" "$url" | cut -f 2 | grep -i -w "free" | while read REPLY; do
	if grep -q --line-regexp "$REPLY" "$seen"; then
		continue
	fi

	echo "$REPLY" | tee --append "$seen"
done

cut-cache "$seen"

Download: fp-content/attachs/free-games-on-steam.sh

Werbebanner von Google Ads/Ad Scence automatisiert anklicken

Mit dem Shell-Skript gadclick.sh, können Werbebanner von Google Ads/Ad Scence automatisiert anklicken werden. Das funktioniert allerdings nicht immer/mit allen Websites (Ich tippe mal auf ein Timing-Problem o.ä.).

#!/bin/sh

set -e

temp="$(/bin/mktemp --tmpdir=/dev/shm/)"
trap "rm -f -- '$temp'" 0 1 2 3 15 # Lösche Datei beim Beenden, Abbruch ...

listlinks="$(which listlinks)"
log="${XDG_CACHE_HOME:-$HOME/.cache}/gadclick.log"
sites="${XDG_CONFIG_HOME:-$HOME/.config}/gadclick.sites"

mkdir -p "$(dirname "$log")"
touch "$log"

get_gad() {
	local website="${1:-http://www.example.net}"
	xvfb-run --auto-servernum "$listlinks" "$website" | cut -f 1 >"$temp" \
		&& cat <<! | grep -E -f - "$temp" | shuf -n 1
^https?://adclick\.g\.doubleclick\.net/
^https?://googleads\.g\.doubleclick\.net/
^https?://www\.googleadservices\.com/
!
}

shuf "$sites" | while read REPLY; do
	if ! wget -qO "/dev/null" "$(get_gad "$REPLY")"; then
		date +"%D %T	0	$REPLY" >>"$log"
		continue
	else
		date +"%D %T	1	$REPLY" >>"$log"
	fi
done

cut-cache "$log"

Download: fp-content/attachs/gadclick.sh

cut-cache

#!/bin/sh
# Cache kürzen
# cut-cache <path/to/cachefile> [keep [threshold]]

set -e

cachefile="$1"
keep="${2:-100}"
threshold="${3:-500}"

if test "$( cat "$cachefile" | wc -l )" -gt "$threshold"; then
	temp="$(mktemp)"
	tail -n "$keep" "$cachefile" >"$temp"
	mv "$temp" "$cachefile"
fi

Download: fp-content/attachs/cut-cache.sh

Wie die anderen Skripte auch, kann cut-cache.sh nach /usr/local/bin/ installiert und ausführbar gemacht werden:

$ wget -O /usr/local/bin/listlinks https://0010100.net/blog/fp-content/attachs/listlinks.js
$ wget -O /usr/local/bin/free-games-on-steam https://0010100.net/blog/fp-content/attachs/free-games-on-steam.sh
$ wget -O /usr/local/bin/gadclick https://0010100.net/blog/fp-content/attachs/gadclick.sh
$ wget -O /usr/local/bin/cut-cache https://0010100.net/blog/fp-content/attachs/cut-cache.sh
$ chmod +x /usr/local/bin/{listlinks,free-games-on-steam,gadclick,cut-cache}

Anhang: Weitere Lösungen mit Selenium

Die Skripte nutzen z.Z. Chromium, aber Firefox sollte auch funktionieren (entsprechenden Code aktivieren).

PhantomJS funktioniert z.Z. nicht (könnte aber einzurichten sein):

Message: Error - Unable to load Atom ‘find_elements’ from file ‘:/ghostdriver/./third_party/webdriver-atoms/find_elements.js’

31. Mai 2018

Ich bin ein ziemlicher Fan von Markdown. Alle Dokumente, ob privat oder geschäftlich, verfasse ich in Markdown und speichere sie dann im PDF Format, bzw. gebe sie so auch weiter.

Eine zeitlang, habe ich meine Dokumente mit VIM geschrieben oder einigenen anderen Markdown Editoren, doch war ich nie zu 100% zufrieden mit der Lösung, jedoch hat sich das heute morgen geändert. Durch Zufall bin ich auf Typora gestoßen.

Screenshots

Screen1

Screen2

Screen3

Screen4

Features

  • Export
    • PDF
    • HTML
    • Word
    • OpenOffice
    • RTF
    • ePub
    • LaTeX
    • Media Wiki
    • reStructedText
    • Textil
    • OPML
    • Bild
  • Theme Support
  • Github Markdown
  • Direkte Vorschau (kein eigenes Fenster)
  • Autovervollständigung vom Markdown
  • etc…

Installation

Es gibt Installationspakete für Windows, Mac OSX (Beta) und für Linux. Für Debian/Ubuntu müsst ihr folgendes machen:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BA300B7755AFCFAE

sudo add-apt-repository 'deb https://typora.io/linux ./'
sudo apt-get update

sudo apt-get install typora

Für Archlinux gibt es ein AUR Package

pacaur -S typora

Ein RPM Package gibt es nicht, allerdings hat sich jemand die Mühe gemacht ein Script zu erstellen, das immer aus der aktuellsten Version ein RPM Paket baut:

Github

Dazu müssen wir folgendes tun:

git clone https://github.com/RPM-Outpost/typora
cd typora
./create-package.sh x64

Package

Das Script lädt die aktuellste Version herunter und baut dann das Paket. Zum Schluß biete es die Installation an. Danach liegt Typora im /opt Ordner. Eine .desktop Datei wird angelegt und sollte damit im Gnome/KDE auftauchen.

Fazit

Dieses Programm beschleundigt mein Schreiben noch deutlicher, nicht nur das ich durch Hotkeys zum Beispiel Tabellen hinzufügen kann, nein auch raffinierte Programmierung erledigt viel Arbeit. So wird zum Beispiel ein markierter Text nach der der Tastenkombination Strg + K direkt zu einem Link, wenn bereits ein Link in der Zwischenalage ist, wird dieser automatisch eingefügt.

Ich bin einfach total begeistert. Alleine diesen Blogartikel habe ich in unter 5 Minuten geschrieben.

Ich bin ein ziemlicher Fan von Markdown. Alle Dokumente, ob privat oder geschäftlich, verfasse ich in Markdown und speichere sie dann im PDF Format, bzw. gebe sie so auch weiter.

Eine zeitlang, habe ich meine Dokumente mit VIM geschrieben oder einigenen anderen Markdown Editoren, doch war ich nie zu 100% zufrieden mit der Lösung, jedoch hat sich das heute morgen geändert. Durch Zufall bin ich auf Typora gestoßen.

Screenshots

Screen1

Screen2

Screen3

Screen4

Features

  • Export
    • PDF
    • HTML
    • Word
    • OpenOffice
    • RTF
    • ePub
    • LaTeX
    • Media Wiki
    • reStructedText
    • Textil
    • OPML
    • Bild
  • Theme Support
  • Github Markdown
  • Direkte Vorschau (kein eigenes Fenster)
  • Autovervollständigung vom Markdown
  • etc...

Installation

Es gibt Installationspakete für Windows, Mac OSX (Beta) und für Linux. Für Debian/Ubuntu müsst ihr folgendes machen:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BA300B7755AFCFAE

sudo add-apt-repository 'deb https://typora.io/linux ./'
sudo apt-get update

sudo apt-get install typora

Für Archlinux gibt es ein AUR Package

pacaur -S typora

Ein RPM Package gibt es nicht, allerdings hat sich jemand die Mühe gemacht ein Script zu erstellen, das immer aus der aktuellsten Version ein RPM Paket baut:

Github

Dazu müssen wir folgendes tun:

git clone https://github.com/RPM-Outpost/typora
cd typora
./create-package.sh x64

Package

Das Script lädt die aktuellste Version herunter und baut dann das Paket. Zum Schluß biete es die Installation an. Danach liegt Typora im /opt Ordner. Eine .desktop Datei wird angelegt und sollte damit im Gnome/KDE auftauchen.

Fazit

Dieses Programm beschleundigt mein Schreiben noch deutlicher, nicht nur das ich durch Hotkeys zum Beispiel Tabellen hinzufügen kann, nein auch raffinierte Programmierung erledigt viel Arbeit. So wird zum Beispiel ein markierter Text nach der der Tastenkombination Strg + K direkt zu einem Link, wenn bereits ein Link in der Zwischenalage ist, wird dieser automatisch eingefügt.

Ich bin einfach total begeistert. Alleine diesen Blogartikel habe ich in unter 5 Minuten geschrieben.

30. Mai 2018

Nach aktueller Planung wird Firefox 62 einen deutlich erweiterten Tracking-Schutz besitzen. Erste Erweiterungen zeigen sich bereits in der Nightly-Version von Firefox 62.

Wer eine aktuelle Nightly-Version von Firefox 62 nutzt, dem ist unter Umständen bereits aufgefallen, dass Mozilla einen Schalter zur Aktivierung respektive Deaktivierung des Tracking-Schutzes prominent im Hauptmenü von Firefox integriert hat.

Tracking-Schutz im Firefox-Menü

Der Tracking-Schutz ist in privaten Fenstern standardmäßig aktiviert und kann vom Nutzer auch für reguläre Fenster aktiviert werden. Der neue Schalter im Hauptmenü erfüllt den gleichen Zweck wie die entsprechende Option in den Firefox-Einstellungen für den gerade aktiven Fenstermodus (regulär vs. privat), ist für den Anwender aber schneller erreichbar. Außerdem gelangt man hierüber schnell zu den Anti-Tracking-Einstellungen von Firefox.

Eine weitere Neuerung in der Nightly-Version von Firefox 62 zeigt sich bei Klick auf das Info-Symbol in der Adressleiste. Unter den speziellen Berechtigungen für die Domain des aktiven Tabs gibt es hier nun eine Schaltfläche, um alle Cookies und Seitendaten zu löschen, welche in Zusammenhang mit der Domain inklusive aller Subdomains des aktiven Tabs stehen.

Cookies löschen Firefox 62

Beide Neuerungen sind Teil eines für Firefox 62 geplantes Projektes, den Tracking-Schutz des Mozilla-Browsers zu verbessern. So soll bei Klick auf das Info-Symbol in der Adressleiste bei den Berechtigungen auch noch ein Link integriert werden, um direkt zu den Berechtigungs-Einstellungen zu gelangen, bei deaktiertem Tracking-Schutz soll es hier Informationen geben, was für Tracking-Scripts auf der Seite entdeckt worden sind.

Tracking-Schutz Firefox 62

Aber auch die Einstellungen des Tracking-Schutzes sollen überarbeitet werden. Konkret ist hier eine Unterteilung möglicher Tracking-Scripts in die folgenden Kategorien geplant: Werbung, Analyse, Fingerprinting, Crypto Mining sowie Sozial. Für jede einzelne dieser Kategorien soll der Nutzer separat einstellen können, ob diese Art von Tracker nur in privaten Fenstern, immer oder nie blockiert werden soll.

Tracking-Schutz Firefox 62

Der Beitrag Mozilla plant aufgebohrten Tracking-Schutz für Firefox 62 erschien zuerst auf soeren-hentzschel.at.

Parrot 4.0

Bereits vor einiger Zeit hat Parrot Security mit der Version 4.0 einen neuen Meilenstein erreicht.

Die italienische Sicherheitsdistribution bringt mit einer experimentellen Netzinstallation und einer Docker Unterstützung zwei neue Installationsmethoden mit. Beide Methoden werden die Verwendung um einiges vereinfachen und die eigene Bedürfnisse besser bedienen. Dockerfiles lassen sich leicht anpassen und eine Core Installation bietet zusätzliche Installationsoptionen an.

Parrot-Security-4.0
Desweitern wurde ein aktueller Kernel 4.16 eingebunden und die Oberfläche auf MATE 1.20 aktualisiert. 

Im Hintergrund werkelt nun eine firejail Sandbox, sowie NGINX anstatt Apache. 

Insgesamt wurden über 1500 Pakete aktualisiert.

Das System ist schnell aktualisiert.

sudo apt update
sudo apt purge tomoyo-tools
sudo apt full-upgrade
sudo apt autoremove

Download Parrot


Kali Linux 2018.2

Die bekannteste Distribution für Sicherheitsexperten und Penetration Tester hat ebenfalls nachgelegt und mit der neuen Version den Kernel 4.15 implementiert, um den Spectre und Meltdown Lücken den Garaus zu machen. Hier werden in Zukunft, wohl noch einige Fixes folgen müssen.

Die Unterstützung für AMD GPUS wurde verbessert, sowie AMD Secure Encrypted Virtualization integriert, was euch erlaubt den Hauptspeicher zu verschlüsseln.

Kali_Linux

Anwender des Metasploit Frameworks erhalten mit dem neuen Release einfacheren Zugang zu Scripten. Diese sind normalerweise unter "/usr/share/metasploit-framework/tools/exploit/" zu finden, sind nun aber Dank PATH direkt mit "msf-scriptname" aufrufbar.

Andere Tools wie BurpSuite, hashcat oder JoomScan wurden ebenfalls aktualisiert. Der komplette Changelog verrät alle Details.

Download Kali



Übersicht 05/2018

 

Name Version Tools Besonderes Basis GUI
Autopsy 4.0 ??? The Sleuth Kit Windows  
BackBox 5 70+ eigenes Repo Ubuntu Xfce
BlackArch 2017.11.24 1750+ ArchLinux ArchLinux Gnome
CAINE 9 100+ WinUFO Ubuntu Mate
DracOS 3.0 100+ CLI LFS DWM
DEFT 2017.1 250+ Dart2 Lubuntu 14.04 Lxde
Kali Linux 2018.2 300+ ARM fähig Debian Testing Multi
LionSec 5.0 ???   Ubuntu  
Matriux v3 RC1 300+ out of date Debian Gnome
NST 26 ??? Server integriert Fedora  
NetSecLOS 6.0 50+   OpenSuse Lxde
Paladin 6.0 30+   Ubuntu  
Parrot Sec 4.0 700+ Cloud fähig Debian Buster MATE
Pentoo 2015.0 RC5 ??? 64bit Gentoo Xfce
Ronin   150+ out of date Lubuntu Lxde
Sans SIFT 3.0 20+   Ubuntu  

29. Mai 2018

Dank Synchronisationsmöglichkeit können Firefox-Nutzer ihre Chronik, Lesezeichen und mehr auf verschiedenen Geräten gleichzeitig nutzen. Wer sich auf einem Gerät von Firefox Sync wieder abmeldet, wird ab Firefox 62 gefragt, ob die lokalen Daten gelöscht werden sollen.

Nach Angaben von Mozilla haben einige Firefox-Nutzer die Erwartung, dass eine Abmeldung von Firefox Sync gleichbedeutend damit ist, dass Daten wie Chronik und Lesezeichen anschließend auch aus Firefox gelöscht werden. Um diesen Nutzern gerecht zu werden, fragt Firefox ab Version 62 nach der Abmeldung von Firefox Sync nach, ob die Daten gelöscht werden sollen und bietet dabei zwei Optionen, die entweder einzeln oder zusammen ausgewählt werden können: ein Löschen synchronisierter Daten wie Chronik und Lesezeichen oder aber auch ein Löschen anderer privater Daten, die nicht synchronisiert werden, wie Cookies und Cache.

Firefox 62: von Sync abmelden

Von den Sync-Servern werden die Daten dabei nicht gelöscht, wie auch in dem neuen Abmelde-Dialog klar kommuniziert wird. Wer das tun will, kann dies über accounts.firefox.com machen. Von dort aus können übrigens sämtliche Geräte von Firefox Sync getrennt werden, die derzeit verbunden sind, ohne dass man das entsprechende Gerät dafür bei sich haben muss.

Tipp: für mehr Sicherheit lässt sich hierüber jetzt auch eine Zwei-Schritt-Authentifizierung für Firefox Sync aktivieren.

Der Beitrag Firefox 62: Firefox bietet nach Abmeldung von Firefox Sync Löschen der Daten an erschien zuerst auf soeren-hentzschel.at.

Der eine oder andere wird es schon mitbekommen haben, dass ich in Punkto Messenger große Hoffungen in der Protokoll Matrix lege. Der offizielle Client Riot war bisher aber immer ein großer Kritikpunkt bei vielen Nutzern.

Anfang 2018 haben die Entwickler von Matrix / Riot 5 Millionen von Status erhalten. Diese Summe sollte unter anderem in die Verbesserung des Referenz-Client Riot investiert werden. Heute wurden nun die ersten Screenshots des neuen Clients veröffentlicht

Wer nichts mit dem offiziellen Client anfangen kann, kann ich zum Beispiel die alternativen Clients Quaternion, nheko oder fractal ansehen. Diese sind vom Funktionsumfang her aber meist noch eingeschränkt, so dass bei nheko beispielsweise die Verschlüsselung noch nicht implementiert ist.

27. Mai 2018

Der Enterprise Policy Generator richtet sich an Administratoren von Unternehmen und Organisationen, welche Firefox konfigurieren wollen. Damit löst die Erweiterung den bekannten CCK2 Wizard in der Ära Firefox Quantum ab. Nun wurde der Enterprise Policy Generator 1.1.0 veröffentlicht.

Enterprise Policy Generator

Download Enterprise Policy Generator für Firefox

Mit Firefox 60 und Firefox ESR 60 hat Mozilla die sogenannte Enterprise Policy Engine eingeführt. Die Enterprise Policy Engine erlaubt es Administratoren, Firefox über eine Konfigurationsdatei zu konfigurieren. Der Vorteil dieser Konfigurationsdatei gegenüber Group Policy Objects (GPO) ist, dass diese Methode nicht nur auf Windows, sondern plattformübergreifend auf Windows, Apple macOS sowie Linux funktioniert.

Zwar steht diese Erweiterung in keiner direkten Verbindung zum bekannten CCK2 Wizard, teilt aber die grundlegende Idee vom CCK2 Wizard, welcher in Firefox Quantum nicht mehr funktioniert, und wurde als Nachfolger vom CCK2 Wizard konzipiert – aber für Firefox Quantum und Enterprise Policies. Der Enterprise Policy Generator hilft bei der Zusammenstellung der sogenannten Enterprise Policies, so dass kein tiefergehendes Studium der Dokumentation und aller möglichen Optionen notwendig ist und sich Administratoren die gewünschten Enterprise Policies einfach zusammenklicken können. Mehr Informationen gibt es in der Ankündigung zum Enterprise Policy Generator.

Neuerungen Enterprise Policy Generator 1.1.0

Der Enterprise Policy Generator bietet die Möglichkeit an, die erstellte Konfiguration direkt als benötigte „policies.json“-Datei herunterzuladen. Damit das möglich ist, muss der Erweiterung die Berechtigung erteilt werden, Dateien herunterladen und die Download-Chronik lesen sowie verändern zu dürfen. Auch wenn die Erweiterung nichts Verwerfliches mit dieser Berechtigung anstellt, so fühlen sich manche Anwender, vor allem im Unternehmens-Umfeld, möglicherweise sicherer, wenn der Enterprise Policy Generator diese Berechtigung nicht zwingend benötigt. Aus diesem Grund wurde die Berechtigung mit dem Update optional gemacht. Das bedeutet, dass der Enterprise Policy Generator ab sofort ohne Erteilung dieser Berechtigung installiert und genutzt werden kann. Der Inhalt kann dann einfach aus der Erweiterung in die selbst angelegte „policies.json“-Datei kopiert werden. Wer die Download-Funktion nutzen möchte, klickt wie gehabt auf den Download-Link. Firefox fragt dann zur Laufzeit nach der entsprechenden Berechtigung und merkt sich diese.

Enterprise Policy Generator 1.1.0

Eine zweite große Änderung vom Enterprise Policy Generator 1.1.0 fand unter der Haube statt und sollte für den Anwender in keiner sichtbaren Änderung resultieren. Ein großes Code-Refactoring wurde durchgeführt, welches in deutlich weniger dupliziertem Code, verbesserter Code-Struktur sowie deutlich mehr Code-Dokumentation resultierte. Nachdem es das Ziel war, eine erste Version der Erweiterung mit Veröffentlichung von Firefox 60 bereitzustellen, damit Administratoren damit arbeiten können, war die Zeit nach Veröffentlichung von Firefox 60 die perfekte Gelegenheit für die Verbesserung der Code-Qualität, um damit letztlich auch die Grundlage für weitere Verbesserungen zu bieten. Beispielsweise die Umsetzung des geplanten Features, Konfigurationen speichern und laden zu können, wird durch diese Code-Verbesserungen deutlich vereinfacht. Aber auch, wenn jemand anderes zum Code der Erweiterung beitragen möchte, ist dies nun leichter möglich.

Darüber hinaus geht ein Dank an milupo, der die Erweiterung in die beiden Sprachen Obersorbisch sowie Niedersorbisch übersetzt hat, womit der Enterprise Policy Generator nun in vier Sprachen zur Verfügung steht.

Roadmap

Wer sich für die Pläne der kommenden Versionen interessiert, findet hier die aktuelle Roadmap. Auch können an dieser Stelle Vorschläge für Verbesserungen gemacht werden.

Entwicklung unterstützen

Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt vom Enterprise Policy Generator erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.

Der Beitrag Enterprise Policy Generator 1.1.0 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Was ist DLNA? Die Digital Living Network Alliance (DLNA) ist ein festgelegter Standard/Netzwerkprotokoll für Geräte wie Mediaplayer, SmartTV oder Smartphones und definiert eine Norm für die Bild-, Ton- und Videoübertragung. So das alle zertifizierten Geräte die Daten abspielen können.

Der Server (hier MiniDLNA) kodiert dafür ggf. die Daten neu und stellt diese dann als Stream bereit (Mindestanforderung für die Datenübertragung ist dabei JPEG, lineare PCM-Ton und MPEG-2. Wobei wichtiger ist, welche Formate der Server einlesen kann).

minidlna einrichten

Mein Setup besteht aus diesen zwei Paketen: minidlna und bindfs

# apt-get install minidlna bindfs

Hat man seine Multimediasammlung z.B. unter /var/local/nas/ gespeichert, hängt man dieses Verzeichnis mittels bindfs ins Verzeichnis /var/lib/minidlna ein. Dies ist das Standardverzeichnis, wo nach Dateien gesucht wird:

# cat <<! >>/etc/fstab
/var/local/nas /var/lib/minidlna fuse.bindfs force-user=minidlna,force-group=minidlna,perms=0000:u=rD 0 0
!
# mount /var/lib/minidlna
# minidlnad -R # Dateien neu in die Datenbank einlesen

Der Server läuft unter Debian als Prozess minidlnad mit der UID minidlna und hat so auf das Verzeichnis /var/lib/minidlna nur lesenden Zugriff.

Die Einteilung in Fotos, Musik und Videos passiert dabei automatisch.

Immer wenn sich der Verzeichnisinhalt von /var/lib/minidlna geändert hat, muss mittels minidlnad -R bzw. minidlnad -r, die Datenbank aktualisiert werden (MiniDLNA hat aber auch inotify Unterstützung aktiviert, um neu hinzugefüge Dateien zu indizieren).

Eine eventuell eingerichtete Firewall, muss mindestens die Ports 8200/TCP und 1900/UDP zulassen.

GNOME

Die Denktopumgebung GNOME hat in den Einstellungen unter Freigabe/Medienfreigabe eine eigene integrierte Möglichkeit um Fotos, Musik und Videos über das Netzwerk mittels DLNA freizugeben (Es können auch benutzerdefinierte Verzeichnisse freigegeben werden). Fehlt diese Einstellung, muss rygel installiert werden.
Hier wird minidlna i.d.R. nicht gebraucht.

gnome-rygel.png

Fehlerbehandlung

Läuft der MiniDLNA Server, wird dieser über das Netzwerk meist als neue Eingangsquelle/Source/Input bei den Clients angezeigt.

Bei Problemen ist das folgende Kommando nützlich, um eine Fehlermeldung zu bekommen:

# service minidlna restart
# journalctl -f -u minidlna # Log anzeigen

Bild von Violinka via pixabay / Lizenz: CC0 Creative Commons

Der mobile Sektor gewinnt zunehmend an Bedeutung. Zwar wird der Desktop bzw. Laptop auf absehbare Zeit nicht verschwinden und ist insbesondere im beruflichen Bereich nicht weg zu denken. In Privathaushalten sind solche Geräte aber auf dem Rückzug und sofern noch vorhanden oft verhältnismäßig alt. Auch hinsichtlich des Datenschutzes sind die mobilen Begleiter viel bedeutsamer als die klassischen Systeme.

Moderne Smartphones und Tablets haben unzählige Sensoren, die ein umfangreiches Tracking ihrer Besitzer ermöglichen. Kamera, Mikrofon, GPS, Schrittzähler, NFC-Chips - diese Liste ließe sich beliebig fortsetzen. Hinzu kommen die gespeicherten Informationen, die persönlicher kaum sein könnten: Kontakte, Telefonhistorie, E-Mails und Messenger-Nachrichten. Wie sensibel diese Informationen sind zeigt nicht zuletzt die erregte Debatte um die so genannte Quellen-TKÜ.

Genau in diesem sensiblen Bereich sind die Anwender fast vollständig von geschlossenen, proprietären und nicht vertrauenswürdigen Systemen abhängig. Open Source-Enthusiasten empfehlen immer gerne Android, aber das zeigt eigentlich nur das Ausmaß der Verzweiflung. Android ist weder frei, noch sicher, noch vertrauenswürdig.

Siehe auch:

Doch was für wirklich freie Alternativen gibt es denn?

Freie Systeme

Die finnische Lösung - SailfishOS

SailfishOS ist unter den alternativen Betriebssystemen sicherlich eine der ausgereifteren Varianten. Dahinter steht das finnische Unternehmen Jolla, das von ehemaligen Nokia-Mitarbeitern gegründet wurde und an Entwicklungen wie das N9 und MeeGo anknüpft. Ältere Semester erinnern sich vielleicht. Die letzten Jahre liefen allerdings nicht sonderlich erfolgreich. Ein groß angekündigtes Tablet musste man einstampfen und Jolla kämpfte auch mit finanziellen Problemen. Die größte Leistung besteht also vermutlich darin, dass man immer noch da ist. Inzwischen kooperiert man mit anderen Herstellern und brachte z. B. SailfishOS auf das Sony Xperia X.

SailfishOS ist technisch eventuell das was man am ehesten als Linux-Smarphone-Betriebssystem bezeichnen kann. Die Mer-Basis verwendet den Linux-Kernel und Wayland für die Grafik, sowie Qt als Toolkit. Man kann sogar Pakete im RPM-Format installieren.

Im Laufe des Jahres 2018 soll dann auch die Version 3 erscheinen, die technisch zu iOS und Android aufschließen soll. Durch die Schwierigkeiten der letzten Jahre ist SailfishOS nämlich nicht mehr ganz zeitgemäß.

Problematisch ist zudem, dass die Oberfläche von SailfishOS keine freie Software ist, sondern man lediglich im Unterbau viel freie Software einbezieht.

Die Community übernimmt - Ubuntu Touch

Die Firma hinter Ubuntu, Canonical, hatte mit Ubuntu Touch große Erwartungen geweckt. Medienwirksam setzte man auf eine groß angelegte Crowdfunding-Initiative, die dann auch fulminant scheiterte - aber wenigstens viel Aufmerksamkeit einbrachte. Das Ziel war nichts weniger als absolute Konvergenz der Systeme, ein Konzept, an dem sich schon ganz andere die Zähne ausgebissen haben. Letztes Jahr zog man dann auch die Reißleine und beendete die konvergenten Träume.

Relativ überraschend fand sich dann aber doch eine Community, die das System übernahm und weiterentwickelte. Es ist weitestgehend funktionsfähig und läuft auf einer Reihe von Endgeräten, was schon beachtlich ist. Momentan versucht man das Projekt auf die 16.04-Basis zu aktualisieren um für die kommenden Jahre Stabilität zu erreichen.

Obwohl die Leistung der Community beachtlich ist, bleibt abzuwarten ob mit wenigen Entwicklern und ohne große Firma im Rücken das System gepflegt und weiterentwickelt werden kann.

Ein Gerät, viele Ideen - Purism 5

Viele Hoffnungen verbinden sich gegenwärtig mit Purism und dem erfolgreich finanzierten Projekt Purism 5. Purism scheint sich aber nicht so recht entscheiden zu können, wohin man mit dem System will. Sowohl GNOME, als auch KDE kooperieren mit Purism. UBports ist seit kurzem auch dabei. Aus nicht ganz nachvollziehbaren Gründen hat sich Purism dazu entschlossen den Fokus auf GNOME zu legen. Also auf jene Oberfläche, die bisher von allen Alternativen am wenigsten für Touch und Mobilsysteme ausgelegt ist.

Wie man die Arbeiten bis 2019 abschließen will fragen sich aber viele Beobachter - vermutlich nicht zu unrecht.

Zersplitterung

Im Grunde genommen sieht man im Bereich der mobilen Entwicklung die Probleme der Open Source/Linux-Gemeinschaft wie unter dem Brennglas. Der chronische Entwicklermangel - keines der obigen Projekte hat mehr als eine Handvoll Entwickler - verhindert schnelle Fortschritte, während sich die anderen Systeme rasant weiter entwickeln. Auf dem Desktop arbeitet man unter ganz anderen Bedingungen. Die Hardware verändert sich nur noch langsam und die großen konkurrierenden Systeme werden tendenziell eher gepflegt, denn wirklich rasant weiter entwickelt. Die kräftezehrende Zersplitterung fällt hier weniger auf.

Im Grunde genommen müsste sich die Entwicklergemeinschaft hier mal zusammenraufen und überhaupt ein funktionsfähiges System zusammen stellen. So aber übertragen die rivalisierenden Gemeinschaften von KDE und GNOME ihre Konkurrenzsituation eins zu eins auf den mobilen Markt und hinzu kommt mit UBports noch ein weiterer Spieler. Linux bietet nämlich auch abseits von Android durchaus eine funktionsfähige Basis, wie die Entwickler von Jolla eindrucksvoll bewiesen haben.

Erste Ansätze, dass man das Problem erkannt hat, sieht man bei die Entwicklung von HaliumOS. Vermutlich kommt das aber zu spät, die Anzeichen, dass Google Android aufgibt mehren sich ja schon.

So bleibt dem Anwender nur die Wahl zwischen Pest und Cholera. Entweder das in Teilen freie Android, dessen Entwicklung komplett von der Datenkrake Google abhängt oder der goldene Käfig iOS, bei dem Apple sich zumindest sehr datenschutzfreundlich geriert.

"

26. Mai 2018

openSUSE hat mit seinem jüngsten Release einen Versionsnummernsprung zurück gemacht. Die Versionsnummer 15 (zuletzt 42.3) soll die Synchronizität mit SUSE Linux Enterprise (SLE) zum Ausdruck bringen — wobei SLE 15 aber noch gar nicht fertig ist.

KDE ist weiterhin das Default-Desktopsystem von openSUSE

Installation

openSUSE steht nur noch als 64-Bit-Version zur Verfügung. Das Installationsprogramm wurde in einigen Details vereinfacht. Standardmäßig schlägt openSUSE weiterhin ein btrfs-Dateisystem für die Systempartition und ein xfs-Dateisystem für /home vor. Im Root-Dateisystem gibt es nun aber weniger btrfs-Subvolumes. Insbesondere wurden alle /var-Subvolumes zu einem Volume zusammengefasst, für das die Option nocow gilt. Das ist mit Geschwindigkeitsvorteilen beim Logging sowie beim Ändern von Datenbank- und Image-Dateien (Virtualisierung) verbunden.

Partitionierungsvorschlag im openSUSE-Installationsprogramm

Versionsnummern

Die Versionsnummern sind openSUSE-typisch ein Mix zwischen der stabilen Basis von SLE und neueren Desktop-Paketen:

Basis            Desktop             Programmierung   Server
--------------   ------------------  --------------   --------------
Kernel    4.12   KDE          5.12   bash       4.4   Apache     2.4
glibc     2.26   Firefox        60   gcc        7.3   CUPS       2.2
X-Server  1.19   Gimp          2.8   Java        10   MariaDB   10.2
Wayland   1.14   LibreOffice   6.0   PHP        7.2   OpenSSH    7.6
Mesa        18   Thunderbird    52   Python     3.6   qemu/KVM  2.11
Systemd    234                                        Postfix    3.3
NetworkMan 1.10                                       Samba      4.7
GRUB       2.02 

KDE setzt sich aus Plasma 5.12, dem KDE Framework 5.45 und den KDE Applications in der Version 17.12 zusammen. Alternativ kann Gnome in Version 3.26 als Desktop-System installiert werden. Java liegt in der aktuellen Version 10 vor. Wie openSUSE mit den halbjährlichen Java-Updates umgehen will, ist mir nicht bekannt. Auch die Release Notes zur noch im Beta-Test befindlichen SLE-15-Version schweigen sich dazu aus.

Das Paket zypper lifecycle verrät, wie lange die Distribution gewartet werden soll:

zypper lifecycle

Product end of support                                  
Codestream: openSUSE Leap 15                            2021-11-30
    openSUSE Leap 15.0                                  2019-11-30

No packages with end of support different from product.

Wenn zypper lifecycle Pakete entdeckt, für die Updates zur Verfügung stehen bzw. für die andere Wartungszeiträume gelten, werden diese explizit aufgezählt.

Neuerungen

Außer den Versionsnummern gab es auch auf technischer Ebene einige Neuerungen:

  • Firewall: openSUSE hat das Firewall-System firewalld von RHEL/Fedora übernommen. Auf eine Integration in YaST hat man verzichtet. Das entsprechende YaST-Modul startet einfach das aus Red-Hat-Systemen bekannte Programm firewall-config.
  • DKMS: Zur Verwaltung von zusätzlichen Kernelmodulen, die im Quellcode zur Verfügung stehen, verwendet openSUSE nun wie die meisten anderen Distributionen DKMS.

  • Chrony: Um die Synchronisierung der Uhrzeit kümmert sich nun Chrony, nicht mehr ntpd.

  • Transaktionaler Server: Während der Installation können Sie im Desktop-Auswahldialog nicht nur zwischen KDE und Gnome wählen, sondern openSUSE auch als Server bzw. als Transaktionalen Server einrichten. Dabei führt openSUSE Updates in Form von Transaktionen durch; sollte ein Update fehlschlagen, wird der gesamte Update-Prozess widerrufen. Details zu diesem Verfahren, das btrfs als Dateisystem voraussetzt, können Sie in den Release-Notes und im openSUSE-Blog nachlesen.

  • update-alternatives: Einige Einstellungen, die bisher in /etc/sysconfig gespeichert wurden, werden jetzt durch update-alternatives verwaltet. Dazu zählen der Display-Manager und das Default-Desktop-System (siehe die Release Notes). Wem das Kommando update-alternatives nicht zusagt, kann stattdessen das neue YaST-Modul yast2-alternatives installieren.

Das neue YaST-Modul Verschiedenes/Alternativen

Update von Version 42.3 auf 15

Die folgende Seite beschreibt den Update-Prozess im Detail: https://en.opensuse.org/SDB:System_upgrade

Die Kurzfassung:

  • Ein komplettes Update der aktuellen Version durchführen
  • Nicht offizielle Paketquellen deaktivieren
  • Optional: alle /var/xxx-Subvolumes auf /var zusammenfassen (siehe Punkt 3 in der Update-Anleitung)
  • In der Beschreibung der Paketquellen: 42.3 durch 15.0 ersetzen (sed)
  • Das eigentliche Distributionsupdate mit zypper dup starten
zypper update
sed -i 's/42.3/15.0/g' /etc/zypp/repos.d/*
zypper ref
zypper dup
  ...
  1467 packages to upgrade, 531 to downgrade, 657 new, 232 to remove, 7 to change arch.
  Overall download size: 1.78 GiB. Already cached: 0 B. 
  After the operation, additional 1.1 GiB will be used.
  ...

Ein Update-Test in einer VirtualBox-Maschine ist problemlos verlaufen. (Auf ‚echten‘ Installationen ziehe ich generell — unabhängig von der Distribution — eine Neuinstallation vor.)

Links und Tests

Bild: © Trueffelpix / Fotolia.com

Der Browser Cliqz gewinnt seit einiger Zeit an Popularität. Dabei handelt es sich um ein Produkt von Hubert Burda Media und Mozilla, der besonders datenschutzfreundlich sein soll. Zu Cliqz gehört seit Februar 2017 auch die Marke Ghostery.

Problematisch sind solche Datenschutzhelfer immer, wenn sie keinen Datenschutz bieten. Wie in Caschys Blog zu lesen ist, hat Ghostery im Zusammenhang mit der DSGVO eine Rundmail mit Informationen zur neuen Datenschutzerklärung verschickt. Alle Accountinhaber waren im CC zu sehen. So sieht gelebter Datenschutz nicht wirklich aus!

Meiner Meinung nach braucht es diese ganzen Aufsätze sowieso nicht. Mit ein paar Handgriffen kann man einen normalen Firefox so absichern, dass er mindestens genau so gut vor Trackern schützt wie diese vermeintlichen Wundermittel (siehe: Mozilla Firefox absichern). Zudem versteht man dann auch wirklich was man gemacht hat. Anonym ist man mit solchen Werkzeugen sowieso nicht unterwegs, das kann allein Tor bieten.

Foto: © Rogatnev / Fotolia.com

Die Entdecker der Lücke hatten ihre PR-Kampagne sorgsam geplant und mit EFAIL auch einen schönen Namen für die Lücke gefunden. Die voreilige Empfehlung der EFF Mailverschlüsselung gleich komplett zu deaktivieren war dann auch ziemlich drastisch (siehe auch: S/MIME und PGP - E-Mail Verschlüsselung anfällig).

Während sich aus dem Bereich S/MIME bisher niemand zu Wort meldete (gibt es überhaupt eine formalisierte Entwicklung des Standards?) starteten die Leute hinter GPG  eine eigene PR-Offensive mit vielschichtigen Stoßrichtungen. Erstens beklagte man, dass keine Kontaktaufnahme im Vorfeld erfolgte, was sich anschließend als falsch herausstellte. Parallel dazu verlegte man sich auf die Strategie, alle Schuld den Mailclients zuzuschieben. Diese seien fehlerhaft und der Verschlüsselungsstandard nicht gebrochen. Weiterhin verwies man auf bereits ausgerollte Updates.

Die Schwachstelle HTML war auch Wasser auf die Mühlen der Open Source-Gemeinde, die diese Erweiterungen der sauberen textbasierten E-Mail schon immer für Teufelszeug gehalten hat. Hier sprang man in den Kommentarspalten den GPG-Entwicklern gerne bei. Man konnte fast den Eindruck gewinnen, dass es gar kein Problem geben würde. Dabei ist genau das Gegenteil der Fall. Die Entdecker der Lücke (mit zugegebenermaßen einer etwas kritischen PR-Politik) hatten frühzeitig die Entwickler der entsprechenden Tools kontaktiert. Dort erkannt man teilweise nicht wie schwerwiegend das Problem war.

Bei anderen Projekten kippten die Entdecker der Lücke im übertragenen Sinne Benzin ins Feuer. Thunderbird ist bereits seit längerem als besonders anfälliger Mailclient bekannt. Ohne grundsätzliche Überarbeitung der Basis und des Addonsystems wird sich da nichts ändern. Anscheinend hat man auch grundlegende Problem umfassende Sicherheitsupdates rauszubringen. Laut Paper der Entdecker ist sogar der vielgescholtene Mailclient von KDE KMail, der chronisch unter Entwicklermangel leidet, nicht so hart betroffen und konnte schnell reagieren.

Das einzig gute für die Open Source Gemeinde. Die proprietären Clients und das von ihnen bevorzugte S/MIME ist noch viel schlimmer dran, denn der Standard bietet im Gegensatz zu OpenPGP noch nicht mal in der Theorie einen Schutz gegen Nachrichtenmanipulation. Außerdem haben Microsoft und Apple für ihre populären Clients Outlook und Mail bisher keine Updates ausgerollt oder wenigstens angekündigt.

Trotzdem sollte man nicht der Einnebelungsstrategie der GPG/PGP Entwickler aufsitzen. Der Standard ist anfällig und kommt mit modernen Bestandteilen einer E-Mail (ja, HTML ist inzwischen verbreitet!) nicht gut zurecht. Sich auf den Standpunkt zurückzuziehen, dass es keine Lücke gibt stärkt die eigene Glaubwürdigkeit nicht.

Unabhängig von der PR-Strategie der EFAIL-Forscher macht die Qualitätssicherung der GPG-Projekte auch keine besonders gute Figur. Es ist leider nicht das erste Mal, dass kritische Open Source-Projekte nicht professionell reagieren.

"