staging.inyokaproject.org

8. Mai 2018

Ich bin ein großer Freund vom Datenschutz, leider unterstützt Hugo nur disqus, was alles andere als freundlich zum Datenschutz ist. Also gab es die letzten Monate nie eine Kommentar Funktion, das hat sich jetzt geändert.

Ich bin durch Zufall auf den Artikel von Don Williamson gestoßen, der es mir erlaubt eine Kommentar Funktion für meine Artikel durch Github anzubieten.

Konfiguration

Als erstes legen wir eine Datei comments.html im Ordner themes/THEME_NAME/layouts/partials/ mit folgenden Inhalt an:

<div id="gh-comments">
          <h2>Kommentare</h2>
              <div id="gh-comments-list"></div>
                  <a href="javascript:void(0)" id="gh-load-comments" class="btn" style="display:none">Load more comments</a>
</div>

   <script type="text/javascript" data-ghid="{{ $.Params.ghcommentid }}" src="{{ .Site.BaseURL }}js/github-comments.js"></script>

Als nächstes brauchen wir jetzt noch die JS Datei, die für uns die ganze Arbeit macht themes/THEME_NAME/static/js/github-comments.js mit folgenden Inhalt:

// use of ajax vs getJSON for headers use to get markdown (body vs body_htmml)
// todo: pages, configure issue url, open in new window?
//

var this_js_script = $('script[src*=github-comments]');


var ghid = this_js_script.attr('data-ghid');   
if (typeof ghid === "undefined" ) {
   var ghid = '0';
}

DoGithubComments(ghid);

var CurrentPage = 0;

function ParseLinkHeader(link)
{
    var entries = link.split(",");
    var links = { };
    for (var i in entries)
    {
        var entry = entries[i];
        var link = { };
        link.name = entry.match(/rel=\"([^\"]*)/)[1];
        link.url = entry.match(/<([^>]*)/)[1];
        link.page = entry.match(/page=(\d+).*$/)[1];
        links[link.name] = link;
    }
    return links;
}

function DoGithubComments(comment_id, page_id)
{
    var repo_name = "beli3ver/malte-kiefer.de";

    if (page_id === undefined)
        page_id = 1;

    var api_url = "https://api.github.com/repos/" + repo_name;
    var api_issue_url = api_url + "/issues/" + comment_id;
    var api_comments_url = api_url + "/issues/" + comment_id + "/comments" + "?page=" + page_id;

    var url = "https://github.com/beli3ver/malte-kiefer.de/issues/" + comment_id;

    $(document).ready(function ()
    {
        $.getJSON(api_issue_url, function(data) {
            NbComments = data.comments;
        });

        $.ajax(api_comments_url, {
            headers: {Accept: "application/vnd.github.v3.html+json"},
            dataType: "json",
            success: function(comments, textStatus, jqXHR) {

                // Add post button to first page
                if (page_id == 1)
                    $("#gh-comments-list").append("<a href='" + url + "#new_comment_field' rel='nofollow' class='btn'>Füge eine Kommentar hinzu</a>");

                // Individual comments
                $.each(comments, function(i, comment) {

                    var date = new Date(comment.created_at);

                    var t = "<div id='gh-comment'>";
                    t += "<img src='" + comment.user.avatar_url + "' width='24px'>";
                    t += "<b><a href='" + comment.user.html_url + "'>" + comment.user.login + "</a></b>";
                    t += " posted at ";
                    t += "<em>" + date.toUTCString() + "</em>";
                    t += "<div id='gh-comment-hr'></div>";
                    t += comment.body_html;
                    t += "</div>";
                    $("#gh-comments-list").append(t);
                });

                // Setup comments button if there are more pages to display
                var links = ParseLinkHeader(jqXHR.getResponseHeader("Link"));
                if ("next" in links)
                {
                    $("#gh-load-comments").attr("onclick", "DoGithubComments(" + comment_id + "," + (page_id + 1) + ");");
                    $("#gh-load-comments").show();
                }
                else
                {
                    $("#gh-load-comments").hide();
                }
            },
            error: function() {
                $("#gh-comments-list").append("Kommentarfunktion für diesen Beitrag nicht aktiviert!");
            }
        });
    });
}

Jetzt müssen die Links in der Datei angepasst werden. Ihr müsst eine eigne Repo anlegen bei Github und hier in der Datei anpassen. Achtung: Wir brauchen auch jQuery!. jQuery sollte umbedingt im <head></head> geladen werden.

Zum Schluss noch das Template für die Beitragsdatei anpassen (themes/THEME_NAME/layouts/_default/single.html) und den folgenden Teil for dem Aufruf des <footer></footer> Tags einfügen:

{{ partial "comments.html" . }}

Um jetzt die Kommentarfunktion zu nutzen, ein entsprechendes issue bei Github eröffnen, die ID merken. Wenn ihr dann einen neuen Beitrag erstellt, müsst ihr vor den "---" folgendes einfügen:

ghcommentid: ID

Und das wars, nun habt ihr und ich eine Kommentarfunktion.

CSP

Damit ihr diese Funktion mit CSP nutzen könnt, müssen folgende Einstellungen gesetzt sein:

img-src 'self' https://*.githubusercontent.com;
connect-src 'self' https://*.github.com

7. Mai 2018

Mozilla wird am Mittwoch Firefox 60 veröffentlichen. Firefox 60 wird gleichzeitig die neue Basis für Firefox ESR sein, die Firefox-Version mit Langzeitunterstützung. Während Firefox 60 und Firefox ESR 60 grundsätzlich identisch sind, gibt es doch ein paar wichtige Unterschiede zwischen beiden Versionen.

Mozilla wird am 9. Mai 2018 Firefox 60 und Firefox ESR 60 veröffentlichen. Nutzer von Firefox ESR 52 haben ab dann noch 17 Wochen Zeit, ehe sie mit Erscheinen von Firefox 62 und Firefox ESR 60.2 am 5. September 2018 automatisch auf Firefox ESR 60 migriert werden. Wie schon Firefox ESR 52 unterscheidet sich auch Firefox ESR 60 in ein paar Aspekten von seinem Mainstream-Pendant.

Firefox ESR 60: standardmäßig keine Service Workers

Service Workers gehören zweifelsohne zu den Webstandards, welche in Zukunft aus vielen modernen Webapplikationen nicht mehr wegzudenken sein werden. Firefox unterstützt Service Workers seit Version 44. Schon in Firefox ESR 45 waren Service Workers aufgrund damals zu erwartender Spezifikations- und Implementierungsänderungen standardmäßig deaktiviert. Auch in Firefox ESR 52 waren Service Workers standardmäßig deaktiviert, wegen andauernden Änderungen unter der Haube zur vollständigungen Unterstützung mehrerer Content-Prozesse, was es schwierig machen würde, Fixes für Firefox ESR zurück zu portieren. Aus dem gleichen Grund werden Service Workers auch in Firefox ESR 60 standardmäßig deaktiviert sein.

Zur Aktivierung in Firefox ESR 60 muss der folgende Schalter über about:config auf true geschaltet werden:

dom.serviceWorkers.enabled

Firefox ESR 60: standardmäßig keine Push-Benachrichtigungen

Ebenfalls werden Push-Benachrichtigungen in Firefox ESR 60 standardmäßig deaktiviert sein, da diese Service Workers als technische Voraussetzung haben.

Zur Aktivierung in Firefox ESR 60 muss der folgende Schalter über about:config auf true geschaltet werden:

dom.push.enabled

Nur in Firefox ESR 60: zusätzliche Enterprise Policies

Mit Firefox 60 liefert Mozilla erstmals seine sogenannte Enterprise Policy Engine aus. Damit ist es für Systemadministratoren möglich, Firefox für die Verteilung im Unternehmen vorzukonfigurieren, wofür bis einschließlich Firefox ESR 52 gerne der sogenannte CCK2 Wizard benutzt worden ist, der allerdings mit Firefox 57 und höher nicht kompatibel ist.

Firefox ESR 60 wird zusätzliche Enterprise Policies unterstützen, welche in der Mainstream-Version von Firefox nicht funktionieren.

Tipp: Die Firefox-Erweiterung Enterprise Policy Generator, welche ich voraussichtlich in dieser Woche veröffentlichen werde, erlaubt ein einfaches Zusammenklicken aller möglichen Enterprise Policies und wird außerdem diejenigen Policies besonders kennzeichnen, welche ausschließlich in Firefox ESR funktionieren.

Firefox Enterprise Policy Generator Vorschau

Nur in Firefox ESR 60: deaktivierbare Signaturpflicht für Add-ons

Zum Schutz seiner Nutzer hat Mozilla eine Signaturpflicht für Add-ons in Firefox eingeführt, welche seit Firefox 43 standardmäßig aktiviert ist. Diese kann nur in Nightly-Builds sowie in der Developer Edition von Firefox deaktiviert werden, nicht in Beta- oder finalen Versionen. Die ESR-Version von Firefox 60 erlaubt auch in der finalen Ausführung die Deaktivierung der Signaturpflicht.

Zur Deaktivierung in Firefox ESR 60 muss der folgende Schalter über about:config auf false geschaltet werden:

xpinstall.signatures.required

Achtung: Es ist aus Sicherheitsgründen nicht empfohlen, die Signaturpflicht für Erweiterungen zu deaktivieren. Wer seine Erweiterungen ausschließlich über addons.mozilla.org bezieht, findet außerdem in der Regel sowieso ausschließlich signierte Erweiterungen vor.

Folgende Unterschiede aus Firefox ESR 52 existieren nicht mehr

Folgende Unterschiede existierten noch zwischen Firefox 52 und Firefox ESR 52, werden aber nicht mehr zwischen Firefox 60 und Firefox ESR 60 existieren:

Multiprozess-Architektur: Für die Auslieferung der Multiprozess-Architektur gab es in Firefox ESR 52 strengere Kriterien als in der Mainstream-Version von Firefox 52, was dazu führte, dass die Multiprozess-Architektur in der ESR-Version mit einer höheren Wahrscheinlichkeit deaktiviert war. In Firefox ESR 60 besteht diesbezüglich kein Unterschied zu Firefox 60.

NPAPI-Plugins: Während in der Mainstream-Version von Firefox 52 der Adobe Flash Player als einziges NPAPI-Plugin unterstützt worden ist, konnten in Firefox ESR 52 auch andere NPAPI-Plugins wie Microsoft Silverlight und Oracle Java genutzt werden. Firefox ESR 60 unterstützt wie die Mainstream-Version nur noch den Adobe Flash Player als einziges NPAPI-Plugin.

WebAssembly (wasm): WebAssembly, oder kurz: wasm, ist ein neues Binärformat für das Web. Ähnlich wie bei Mozillas asm.js oder Googles PNaCl handelt es sich dabei um das Resultat kompilierten Codes und soll die Performance von Webanwendungen auf eine neue Ebene heben. In Firefox ESR 52 war WebAssembly standardmäßig deaktiviert, in Firefox ESR 60 wird WebAssembly standardmäßig aktiviert sein.

Windows XP: Nutzer von Windows XP und Windows Vista erhalten bis zum Lebensende von Firefox ESR 52 noch Sicherheits-Aktualisierungen. Ein Update auf Firefox 60 respektive Firefox ESR 60 wird es für entsprechende Nutzer nicht mehr geben.

Der Beitrag Alle Unterschiede zwischen Firefox 60 und Firefox ESR 60 erschien zuerst auf soeren-hentzschel.at.

Im folgenden Artikel möchte ich erklären, wie man eine Webserver Umgebung mit PHP-FPM und Let’s Encrypt Zertifikaten mit dem Webserver Lighttpd (lighty) umsetzen kann. Die folgende Konfiguration führt dazu, dass ihr bei folgenden Tests, eine A(+) bekommt:

Hinweis: Ein natürlicher Menschenverstand wird vorausgesetzt, bitte nicht einfach blind kopieren!

Installation

Als erstes installieren wir die benötigt Software:

apt install lighttpd php-fpm certbot

Konfiguration

lighttpd - PHP-FPM

Im folgenden werden wir lighttpd konfigurieren. Als erstes sorgen wir dafür das lighttpd mit PHP-FPM umgehen kann, dazu gehen wir in den Ordner /etc/lighttpd/conf-available/.

Dort werden wir jetzt die Datei 15-fastcgi-php.conf bearbeiten, und folgenden Inhalt einfügen:

# -*- depends: fastcgi -*-
# /usr/share/doc/lighttpd/fastcgi.txt.gz
# http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions#mod_fastcgi-fastcgi

## Start an FastCGI server for php (needs the php5-cgi package)
fastcgi.server += ( ".php" =>
        ((
                "socket" => "/var/run/php/php7.2-fpm.sock",
                "broken-scriptfilename" => "enable"
        ))
)

Umbedingt den Socket Pfad kontrollieren! Jetzt sagen wir lighttpd er soll das Modul laden:

lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php
service lighttpd force-reload

Jetzt kann lighttpd mit PHP Dateien umgehen.

lighttpd

Im folgenden werden wir lighttpd konfigurieren. Dazu bearbeiten wir die Datei /etc/lighttpd/lighttpd.conf und fügen folgenden Inhalt hinzu:

server.modules = (
        "mod_access",
        "mod_alias",
        "mod_compress",
        "mod_redirect",
        )
#default webseite
server.document-root        = "/var/www/html/kiefer-networks.de/"
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
#Server Tag ist der Name der angezeigt wird beim Abtasten des Servers (Nginx v.234)
server.tag                  = "Mein Server"


index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )
#Zugriff auf folgende Dateien untersagen
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

#Wir erlauben nur das die HTTP Requests Methoden GET & POST erlaubt sind

$HTTP["request-method"] !~ "^(GET|POST)" {
    url.access-deny = ("")
}

#Setzten der entsprechenden HTTP Headers, Achtung CSP anpassen

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header  = (
            "Content-Security-Policy"   => "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self'; media-src 'self'; frame-src https://*.openstreetmap.org https://*.google.com; font-src https://fonts.googleapis.com; connect-src 'none'",
            "Strict-Transport-Security" => "max-age=15768000; includeSubDomains; preload",
            "X-Content-Type-Options" => "nosniff",
            "X-Frame-Options" => "DENY",
            "X-XSS-Protection" => "1; mode=block"
            )
}

#Umleiten von HTTP zu HTTPS

$HTTP["scheme"] == "http" {
    $HTTP["host"] =~ ".*" {
        url.redirect = (".*" => "https://%0$0")
    }
}

#Multi Webseiten Konfiguration

$HTTP["host"] =~ "(^|\.)example\.de$" {
    	server_name = "example.de"
        server.document-root = "/var/www/html/example.de" 
        server.errorlog = "/var/log/lighttpd/ex_de_error.log"	
}

$HTTP["host"] =~ "(^|\.)example\.com$" {
    	server_name = "example.com"
        server.document-root = "/var/www/html/example.com" 
        server.errorlog = "/var/log/lighttpd/ex_com_error.log"	
}

lighttpd SSL Konfiguration

Jetzt werden wir noch die SSL Konfiguration anpassen. Dazu bearbeiten wir die Datei /etc/lighttpd/conf-available/10-ssl.conf. Wir passen den Inhalt wir folgt an:

$SERVER["socket"] == ":443" {
    protocol     = "https://"
        ssl.engine   = "enable"
        ssl.disable-client-renegotiation = "enable"
        ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem" 
        ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"

        ssl.ec-curve              = "secp384r1"

        setenv.add-environment = (
                "HTTPS" => "on"
                )
        ssl.use-sslv2 = "disable"
        ssl.use-sslv3 = "disable"
        ssl.honor-cipher-order    = "enable"
        ssl.cipher-list           = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

        $HTTP["host"] =~ "(^|\.)example\.de$" {
            ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
        }


    	$HTTP["host"] =~ "(^|\.)example\.com$" {
        	ssl.pemfile = "/etc/lighttpd/ssl/example.com.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
    	}
}

Dazu erstellen wir noch den folgenden Ordner

mkdir /etc/lighttpd/ssl/

Jetzt noch das SSL Modul aktivieren

lighttpd-enable-mod ssl
service lighttpd restart

Let’s Encrypt

Bei lighttpd gibt es eine Besonderheit bei den Zertifikaten, so muss der Private Schlüssel und das Zertifikate in einer Datei sein und das CA immer als Referenz mit angebenen sein. Damit wir das nicht für jede Datei einzeln machen müssen, werden wird ein fertiges Script nehmen, was sich auch darum kümmert, die Zertifikate aktuell zu halten.

Dazu wechseln wir nach /opt. Dann klonen wir folgenden Repo:

git clone https://github.com/galeone/letsencrypt-lighttpd.git

Wechselt in den neuen Ordner letsencrypt-lighttpd. Als erstes bearbeiten wir die Datei letsencrypt-lighttpd.service und passen den ExecStart an nach /opt/letsencrypt-lighttpd/renew.sh.

ExecStart=/opt/letsencrypt-lighttpd/renew.sh

Dann kopieren die Service Dateien und starten den Dienst:

cp letsencrypt-lighttpd.* /etc/systemd/system/
systemctl enable letsencrypt-lighttpd.timer

Jetzt der “schwierige” Teil, wir passen noch renew.sh an:

#!/usr/bin/env bash 
set -eu

#Domain sudomain part (mail.example.de => mail)
domain_subdomains=( \
#domain     sub sub sub
"example.de w ww www" \
"example.com w ww www" \
)
email=mail@example.de
w_root=/var/www/html/ #Speicherort der Webseiten
user=root
group=root

# end configuration

if [ "$EUID" -ne 0 ]; then
    echo  "Please run as root"
    exit 1
fi

for domain_set_string in "${domain_subdomains[@]}"; do
    domain_set=(${domain_set_string// / })
    domain=${domain_set[0]}
    unset domain_set[0]

    all_subdomains="-d $domain"
    if [ ${#domain_set[@]} -gt 0 ]; then
        for sub_domain in "${domain_set[@]}"; do
            all_subdomains="$all_subdomains -d $sub_domain.$domain"
        done
    fi

    /usr/bin/certbot certonly --agree-tos --renew-by-default \
        --rsa-key-size 4096 --email $email --webroot -w $w_root$domain \
        $all_subdomains
    cat /etc/letsencrypt/live/$domain/privkey.pem \
        /etc/letsencrypt/live/$domain/cert.pem \
        > /etc/lighttpd/ssl/$domain.pem
    cp /etc/letsencrypt/live/$domain/fullchain.pem \
       /etc/lighttpd/ssl/
    chown -R $user:$group /etc/lighttpd/
	chmod 600 /etc/lighttpd/*.pem
done

Hinweis: Die Webseiten müssen im Ordner /var/www/html/ gespeichert werden, im Format der angegebenen Domain: /var/www/html/example.de

Jetzt starten wir die Dienste neu:

service php7.2-fpm restart
service lighttpd restart

Dann lassen wir uns noch die Zertifikate austellen

bash /opt/letsencrypt-lighttpd/renew.sh

Fazit

Der Lighttpd ist ein leistungsstarker Server, der wunderbar ein Ersatz für nginx und Apache sein kann.

Im heutigen Beitrag aus der Kategorie Wochenend-Projekte geht es darum, wie man mit Hilfe eines Reverse-SSH-Tunnels ein Offsite-Backup für die heimische Datensammlung realisieren kann. Der Beitrag soll mir als Dokumentation und euch als Anregung für ähnliche Projekte dienen.

Anwendungsfall (Use Case)

In meinem Heimnetzwerk gibt es ein NAS, welches der Familie als allgemeines Datengrab dient. Lagen hier anfangs nur Datensicherungen anderer Geräte, verwalten wir heute, neben anderen Daten, unsere Familien- und Urlaubsfotos auf diesem Gerät. Es existiert eine lokale Datensicherung dieser Daten, die vor versehentlichem Löschen schützt.

Nun sind uns einige dieser Daten so wichtig, dass wir sie auch gern gegen Verlust durch z.B. Feuer oder Diebstahl schützen möchten. Dazu möchte ich die betreffenden Daten gern außerhalb der eigenen vier Wände an einem anderen Standort sichern. Diese Form der Datensicherung bezeichne ich im Folgenden auch als Offsite-Backup.

Anforderungen

An das Offsite-Backup stelle ich folgende Anforderungen:

  1. Die Datenübertragung erfolgt über gesicherte Verbindungen
  2. Die Daten werden in einem Format gespeichert, welches das Lesen ohne Abhängigkeit zu bestimmten Programmen ermöglicht
  3. Die Datenübertragung soll manuell angestoßen werden und optional zeitgesteuert ausgeführt werden können
  4. Eine Wiederherstellung der Daten soll über den gleichen Kanal wie die Datensicherung möglich sein
  5. Die Daten sollen nicht bei einem kommerziellen Anbieter gespeichert werden
  6. Die Daten sollen nicht in einem Speicher abgelegt werden, der sich des unmittelbaren Zugriffs entzieht
  7. In den Routern der beteiligten Heimnetzwerke sollen keine eingehenden Portweiterleitungen konfiguriert werden müssen

Alles was ich benötige, um die obigen Anforderungen umzusetzen sind:

  1. Ein Raspberry Pi
  2. Eine externe USB-Festplatte zum Anschluss an den Pi
  3. Einen Linux-Root-Server im Internet
  4. Einen LAN-Port und Stromanschluss im Elternhaus

Zu meinem Glück sind all diese Dinge bereits vorhanden und ich muss nicht erst eine Einkaufstour unternehmen.

Die Lösung

In groben Zügen erklärt, sieht die Lösung wie folgt aus. An den Raspberry Pi wird eine USB-Festplatte angeschlossen, welche als Speicher für die zu sichernden Daten dient. Der Pi wird in meinem Elternhaus an das dortige Heimnetzwerk angeschlossen. Von dort ausgehend baut er einen Reverse-SSH-Tunnel zu meinem Linux-Server auf, welcher bei einem Hoster läuft und auf eingehende SSH-Verbindungen lauscht. So kann ich von dem Linux-Server aus auf den Pi zugreifen, ohne dass im DSL-Router in meinem Elternhaus eine Portweiterleitung eingerichtet werden muss. Darüber hinaus entfällt auch die Notwendigkeit, die Gegenstelle über die sich ändernde dynamische IP-Adresse auf dem Laufenden zu halten.

model of an offsite backup

SSH-Verbindungen über eine Vermittlungsstelle für ein Offsite-Backup

Nun kann ich von dem NAS aus meinem Heimnetzwerk eine SSH-Verbindung über den Linux-Server zum Raspberry Pi in meinem Elternhaus aufbauen und Daten dorthin übertragen. Auch in meinem Heimnetzwerk muss dazu keine Portweiterleitung geschaffen werden.

Konfiguration auf dem Pi

Auf dem Raspberry Pi habe ich das Betriebssystem Raspbian installiert. Anschließend habe ich ein SSH-Schlüsselpaar erstellt und den öffentlichen SSH-Schlüssel auf dem Linux-Server hinzugefügt, um ohne die Eingabe eines Passworts eine SSH-Verbindung herstellen zu können. Für die Verbindung verwende ich normale Linux-Benutzer ohne besondere Privilegien. Nun kann mit dem Befehl ssh -R 22222:localhost:22 user@Linux-Server ein Reverse-SSH-Tunnel zum Raspberry Pi aufgebaut werden. Der Reverse-SSH-Tunnel ermöglicht es, vom Linux-Server aus mit dem Befehl ssh -p22222 localhost eine Verbindung zum Raspberry Pi aufbauen zu können.

Damit der Reverse-SSH-Tunnel nach der Provider-Zwangstrennung automatisch wieder aufgebaut wird, habe ich auf dem Raspberry Pi folgende Service-Unit erstellt:

[Unit]
Description="Reverse ssh tunnel to proxy"
After=network.target

[Service]
User=pusemuckel
ExecStart=/usr/bin/ssh -NTi /home/pusemuckel/.ssh/id_rsa -o ServerAliveInterval=60 -R 22222:localhost:22 user@Linux-Server
RestartSec=73
Restart=always

[Install]
WantedBy=multi-user.target

Die Option RestartSec gibt an, dass bei einem Verbindungsabbruch 73 Sekunden gewartet wird, bevor ein erneuter Verbindungsversuch gestartet wird. Damit möchte ich dem DSL-Router Zeit für die Wiedereinwahl geben.

Konfiguration auf dem NAS

Auf dem NAS erstelle ich im HOME-Verzeichnis des Benutzers, welcher später die Datensicherung ausführen wird, die Datei ~/.ssh/config mit folgendem Inhalt, um auf einfache Weise eine SSH-Verbindung zum Raspberry Pi im entfernten Standort herstellen zu können.

Host raspi
        HostName localhost
        Port 22222
        ProxyCommand ssh -i ~/.ssh/nas_rsa -A -W %h:%p user@linux-server
        IdentityFile ~/.ssh/nas_rsa

ProxyCommand gibt an, dass der Linux-Server als Proxy bzw. Zwischenpunkt der Verbindung dient. In neueren SSH-Versionen kann man statt dessen auch die etwas einfacher zu handhabende Option JumpHost verwenden.

Neben der obigen Datei wurde auf dem NAS ein SSH-Schlüsselpaar erstellt, dessen öffentlicher Schlüssel auf dem Linux-Server und dem Raspberry Pi im entfernten Standort hinterlegt wurde. Dadurch ist für die Durchführung der Datensicherung keine Passworteingabe erforderlich. Da beide Endpunkte der Verbindung in vertrauenswürdigen Netzen liegen, halte ich diese Vorgehensweise für vertretbar.

Probleme

Leider läuft das Ganze noch nicht so rund und störungsarm, wie ich es mir wünsche. Bei der Zwangstrennung reißt die Verbindung ab, ohne dass der Raspberry Pi eine Chance hätte, den Socket auf dem Server zu schließen.

Da der verwendete Port noch auf dem Linux-Server gebunden ist, schlägt eine erneute Einwahl fehl. Erst wenn der Socket nach einem Timeout geschlossen wurde, ist eine erneute Wiederherstellung der Verbindung möglich.

Update 2018-05-21: Danke an Christian F., welcher mich auf die Optionen ClientAliveCountMax und ClientAliveInterval hingewiesen hat. Mit diesen Optionen kann der SSH-Server erkennen, dass die Verbindung zum Client abgerissen ist und den Socket schließen.

Der Standardwert für ClientAliveCountMax beträgt 3. Dabei handelt es sich um client alive messages, welche der Server zum Client sendet. Bleiben alle drei unbeantwortet, baut der Server die Verbindung ab und gibt den Socket frei. Den Wert für ClientAliveInterval habe ich auf 15 gesetzt. Er gibt an, dass nach 15 Sekunden Inaktivität eine client alive message vom Server an den Client gesendet wird, um zu überprüfen, ob der Client noch antwortet.

Antwortet der Client nicht, wird mit der obigen Konfiguration die Verbindung vom Server nach 45 Sekunden abgebaut und der Socket freigegeben. Der Client kann sich anschließend wieder neu verbinden. Auf dem Client habe ich den Parameter RestartSec auf 73 Sekunden gesetzt (einfach weil mir die Zahl so gut gefällt). Nach dem Abriss der Verbindung durch die Zwangstrennung wird der Tunnel nach 73 Sekunden wieder aufgebaut.

Fazit

Mit dieser kleinen Bastellösung kann ich meine Daten über einen gesicherten Kanal in einen entfernten Standort sichern. Das manuelle Offsite-Backup klappt bereits gut, wenn der SSH-Tunnel zwischen Linux-Server und Raspberry Pi steht.

Da das Problem mit der Zwangstrennung nun etwas entschärft werden konnte, steht auch einem zeitgesteuerten Backup grundsätzlich nichts mehr im Wege. Es bleibt lediglich das Restrisiko, dass sich der Zeitpunkt der Zwangstrennung ändert und diese dann das zeitgesteuerte Backup unterbricht. Mit diesem Risiko komme ich jedoch zurecht.

Bild von harshahars via Pixabay / Lizenz: CC0 Creative Commons

App Stores sind gegenwärtig das Mittel der Wahl um Programme zu verwalten. Populär gemacht hat sie Apple mit dem iPhone aber inzwischen gibt es kaum ein System, das ohne sie auskommt. iOS, Android, macOS, Windows - und Linux? Nun, Linux versucht sich auch seit Jahren daran - und scheitert immer wieder. Die Frage ist warum?

Eigentlich hatten alle Linux-Distributionen gute Startbedingungen. Im Gegensatz zu Windows oder macOS verwaltete man die Software schon immer in handlichen Paketen über eine Paketverwaltung. Das gebündelte App Store-Prinzip war zum greifen nah. Es fehlten lediglich Metadaten und eine Trennung in "richtige" Programme und Bibliotheken etc., die als Abhängigkeiten benötigt wurden. Hier ist man in den letzten Jahren auch deutlich voran gekommen. Mit AppStream gibt es eine zentrale Stelle, die Metadaten zusammen trägt und von allen großen Distributionen unterstützt wird.

Leider scheitert man in der Praxis. Nachdem Ubuntu Software erst lange dahin siechte und schließlich zugunsten von GNOME Software aufgegeben wurde, gibt es noch zwei Stores: Plasma Discover und GNOME Software. Beide können über Backends mit allen großen Paketverwaltungen umgehen und beherrschen experimentell auch Snaps und Flatpaks.

Beide Lösungen versagen aber regelmäßig in der Praxis. Mit kaum einem Werkzeug schafft es der normale Anwender sein System mit Problemen zu belasten, wie mit der Benutzung eines Stores. Entweder weil man aus versehen Snaps statt normalen Paketen installiert oder weil Paketabhängigkeiten nicht korrekt aufgelöst werden. Manche Fehler sind auch gar nicht reproduzierbar. Die Kritik an diesen Systemen findet sich in fast jedem größeren Testbericht zu Ubuntu 18.04.

Die Distributionen gegeben dieses Problem quasi selbst zu indem sie wie Kubuntu mit Muon, Debian/Ubuntu mit Synaptic oder SUSE mit YaST klassische Paketverwaltungen empfehlen um Probleme zu lösen.

Trotzdem geht der Trend Richtung Store-Prinzip, weil man erkannt hat, dass bisherige Paketverwaltungen zu unübersichtlich, behäbig und zur modernen Softwareverwaltung nicht mehr zeitgemäß sind. Beim Basissystem mag das noch anders aussehen, aber die meisten Linux-Distributionen nehmen hier keine Trennung vor. Anders als z. B. FreeBSD, macOS oder Windows.

Warum scheitert Linux derart dabei eine moderne Programmverwaltung zu implementieren? Fehlender Wille alte Zöpfe abzuschneiden? Fehlende Unterstützung durch die Supportcommunity? Oder sehen wir bereits die Abkehr der Distributoren vom Desktop? App Stores spielen im Server- und Enterprise-Markt naturgemäß keine Rolle.

"

Im folgenden Artikel möchte ich erklären, wie man eine Webserver Umgebung mit PHP-FPM und Let's Encrypt Zertifikaten mit dem Webserver Lighttpd (lighty) umsetzen kann. Die folgende Konfiguration führt dazu, dass ihr bei folgenden Tests, eine A(+) bekommt:

Hinweis: Ein natürlicher Menschenverstand wird vorausgesetzt, bitte nicht einfach blind kopieren!

Installation

Als erstes installieren wir die benötigt Software:

apt install lighttpd php-fpm certbot

Konfiguration

lighttpd - PHP-FPM

Im folgenden werden wir lighttpd konfigurieren. Als erstes sorgen wir dafür das lighttpd mit PHP-FPM umgehen kann, dazu gehen wir in den Ordner /etc/lighttpd/conf-available/.

Dort werden wir jetzt die Datei 15-fastcgi-php.conf bearbeiten, und folgenden Inhalt einfügen:

# -*- depends: fastcgi -*-
# /usr/share/doc/lighttpd/fastcgi.txt.gz
# http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions#mod_fastcgi-fastcgi

## Start an FastCGI server for php (needs the php5-cgi package)
fastcgi.server += ( ".php" =>
        ((
                "socket" => "/var/run/php/php7.2-fpm.sock",
                "broken-scriptfilename" => "enable"
        ))
)

Umbedingt den Socket Pfad kontrollieren! Jetzt sagen wir lighttpd er soll das Modul laden:

lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php
service lighttpd force-reload

Jetzt kann lighttpd mit PHP Dateien umgehen.

lighttpd

Im folgenden werden wir lighttpd konfigurieren. Dazu bearbeiten wir die Datei /etc/lighttpd/lighttpd.conf und fügen folgenden Inhalt hinzu:

server.modules = (
        "mod_access",
        "mod_alias",
        "mod_compress",
        "mod_redirect",
        )
#default webseite
server.document-root        = "/var/www/html/kiefer-networks.de/"
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
#Server Tag ist der Name der angezeigt wird beim Abtasten des Servers (Nginx v.234)
server.tag                  = "Mein Server"


index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )
#Zugriff auf folgende Dateien untersagen
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

#Wir erlauben nur das die HTTP Requests Methoden GET & POST erlaubt sind

$HTTP["request-method"] !~ "^(GET|POST)" {
    url.access-deny = ("")
}

#Setzten der entsprechenden HTTP Headers, Achtung CSP anpassen

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header  = (
            "Content-Security-Policy"   => "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self'; media-src 'self'; frame-src https://*.openstreetmap.org https://*.google.com; font-src https://fonts.googleapis.com; connect-src 'none'",
            "Strict-Transport-Security" => "max-age=15768000; includeSubDomains; preload",
            "X-Content-Type-Options" => "nosniff",
            "X-Frame-Options" => "DENY",
            "X-XSS-Protection" => "1; mode=block"
            )
}

#Umleiten von HTTP zu HTTPS

$HTTP["scheme"] == "http" {
    $HTTP["host"] =~ ".*" {
        url.redirect = (".*" => "https://%0$0")
    }
}

#Multi Webseiten Konfiguration

$HTTP["host"] =~ "(^|\.)example\.de$" {
    	server_name = "example.de"
        server.document-root = "/var/www/html/example.de" 
        server.errorlog = "/var/log/lighttpd/ex_de_error.log"	
}

$HTTP["host"] =~ "(^|\.)example\.com$" {
    	server_name = "example.com"
        server.document-root = "/var/www/html/example.com" 
        server.errorlog = "/var/log/lighttpd/ex_com_error.log"	
}

lighttpd SSL Konfiguration

Jetzt werden wir noch die SSL Konfiguration anpassen. Dazu bearbeiten wir die Datei /etc/lighttpd/conf-available/10-ssl.conf. Wir passen den Inhalt wir folgt an:

$SERVER["socket"] == ":443" {
    protocol     = "https://"
        ssl.engine   = "enable"
        ssl.disable-client-renegotiation = "enable"
        ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem" 
        ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"

        ssl.ec-curve              = "secp384r1"

        setenv.add-environment = (
                "HTTPS" => "on"
                )
        ssl.use-sslv2 = "disable"
        ssl.use-sslv3 = "disable"
        ssl.honor-cipher-order    = "enable"
        ssl.cipher-list           = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

        $HTTP["host"] =~ "(^|\.)example\.de$" {
            ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
        }


    	$HTTP["host"] =~ "(^|\.)example\.com$" {
        	ssl.pemfile = "/etc/lighttpd/ssl/example.com.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
    	}
}

Dazu erstellen wir noch den folgenden Ordner

mkdir /etc/lighttpd/ssl/

Jetzt noch das SSL Modul aktivieren

lighttpd-enable-mod ssl
service lighttpd restart

Let's Encrypt

Bei lighttpd gibt es eine Besonderheit bei den Zertifikaten, so muss der Private Schlüssel und das Zertifikate in einer Datei sein und das CA immer als Referenz mit angebenen sein. Damit wir das nicht für jede Datei einzeln machen müssen, werden wird ein fertiges Script nehmen, was sich auch darum kümmert, die Zertifikate aktuell zu halten.

Dazu wechseln wir nach /opt. Dann klonen wir folgenden Repo:

git clone https://github.com/galeone/letsencrypt-lighttpd.git

Wechselt in den neuen Ordner letsencrypt-lighttpd. Als erstes bearbeiten wir die Datei letsencrypt-lighttpd.service und passen den ExecStart an nach /opt/letsencrypt-lighttpd/renew.sh.

ExecStart=/opt/letsencrypt-lighttpd/renew.sh

Dann kopieren die Service Dateien und starten den Dienst:

cp letsencrypt-lighttpd.* /etc/systemd/system/
systemctl enable letsencrypt-lighttpd.timer

Jetzt der "schwierige" Teil, wir passen noch renew.sh an:

#!/usr/bin/env bash 
set -eu

#Domain sudomain part (mail.example.de => mail)
domain_subdomains=( \
#domain     sub sub sub
"example.de w ww www" \
"example.com w ww www" \
)
email=mail@example.de
w_root=/var/www/html/ #Speicherort der Webseiten
user=root
group=root

# end configuration

if [ "$EUID" -ne 0 ]; then
    echo  "Please run as root"
    exit 1
fi

for domain_set_string in "${domain_subdomains[@]}"; do
    domain_set=(${domain_set_string// / })
    domain=${domain_set[0]}
    unset domain_set[0]

    all_subdomains="-d $domain"
    if [ ${#domain_set[@]} -gt 0 ]; then
        for sub_domain in "${domain_set[@]}"; do
            all_subdomains="$all_subdomains -d $sub_domain.$domain"
        done
    fi

    /usr/bin/certbot certonly --agree-tos --renew-by-default \
        --rsa-key-size 4096 --email $email --webroot -w $w_root$domain \
        $all_subdomains
    cat /etc/letsencrypt/live/$domain/privkey.pem \
        /etc/letsencrypt/live/$domain/cert.pem \
        > /etc/lighttpd/ssl/$domain.pem
    cp /etc/letsencrypt/live/$domain/fullchain.pem \
       /etc/lighttpd/ssl/
    chown -R $user:$group /etc/lighttpd/
	chmod 600 /etc/lighttpd/*.pem
done

Hinweis: Die Webseiten müssen im Ordner /var/www/html/ gespeichert werden, im Format der angegebenen Domain: /var/www/html/example.de

Jetzt starten wir die Dienste neu:

service php7.2-fpm restart
service lighttpd restart

Dann lassen wir uns noch die Zertifikate austellen

bash /opt/letsencrypt-lighttpd/renew.sh

Fazit

Der Lighttpd ist ein leistungsstarker Server, der wunderbar ein Ersatz für nginx und Apache sein kann.

6. Mai 2018

JSearchUtil ist ein Programm zum Suchen von Ordner in vorab definierten Pfaden. Es hat sich als äußerst effektiv erwiesen sobald ein Ordner in einem Verzeichnis mit sehr vielen anderen Ordnern und Verzeichnissen gesucht werden soll. In den meisten Betriebssystemen ist ein Suchfenster bereits vorgesehen, jedoch durchsuchen diese Funktionen häufig auch sämtliche Unterordner des Verzeichnisses. Das führt zu meist sehr langen Suchvorgängen. JSearchUtil sucht hingegenen nur auf Root-Verzeichnisebene, das heißt es wird vorab definiert in welchem Verzeichnissen gesucht werden soll. Im zweiten Schritt können diese Verzeichnisse nach einem Stichwort durchsucht werden. Die Ergebnisse werden gut sichtbar visualisiert und mittels Doppelklick kann das gewünschte Verzeichnis geöffnet werden. Die zur Suche genutzten Verzeichnisse werden automatisch im Hintergrund abgespeichert und sind beim nächsten Programmstart wieder verfügbar.

Screenshots:

Projektseite: klick

Download-Link: Klick

Github-Link: Klick

Angeregt durch Fryboyters Beitrag Alternative zu Isso habe ich mich auch mal wieder um meine Kommentarfunktion gekümmert. Commento ist leider noch nicht so weit, dass ich einen Umstieg von Isso erwägen würde, aber ich habe Isso immerhin auf den aktuellsten Entwicklungsstand gebracht. Es gibt zwar immer noch keine Benachrichtigungsfunktion aber immerhin kann man nun einen Feed zu den Artikelkommentaren abonnieren wenn man diese verfolgen möchte.

Ich habe Isso damals nach dieser Anleitung auf Uberspace 6 installiert und beschreibe wie man von dieser Basis auf den aktuellen Stand wechselt.

Zuerst installieren wir Isso und dessen Abhängigkeiten:

pip3.6 install flup werkzeug git+https://github.com/posativ/isso.git --user

Danach passen wir die Datei ~/fcgi-bin/isso folgendermaßen an (USER ist natürlich anzupassen):

#!/usr/bin/env python3.6

import os

from isso import make_app
from isso import config, dist

from flup.server.fcgi import WSGIServer

# load default configuration + user configuration
application = make_app(
    config.load(
        os.path.join(dist.location, dist.project_name, "defaults.ini"),
        "/home/USER/etc/isso/user.cfg"))

# start WSGI server
WSGIServer(application).run()

Anschließend müssen noch die aktuellen Javascript-Dateien in die Seite eingebaut werden. Ich habe dazu einfach das Repository geklont und den Ordner ./isso/js auf meine Seite hochgeladen und die Scripte folgendermaßen eingebunden:

<script src="/js/config.js"></script>
<script data-main="/js/embed" src="/js/components/requirejs/require.js"></script>
<script data-isso-vote="false" data-isso-lang="de" data-isso-feed="true" data-isso="/fcgi-bin/isso" src="/js/embed.js"></script>

Um die Beitragsfeeds zu aktivieren muss folgendes zur Konfiguration ~/etc/isso/user.cfg hinzugefügt werden:

[rss]
base = ../..
limit = 100

Ich habe base = ../.. gesetzt, da ich auf meiner Seite nur relative Links verwende, man kann natürlich auch einfach seine Domain eintragen.

Update 2018-05-07

Der Kommentarfeed wird jetzt auch im header der Blogeinträge verlinkt, auch wenn das leider kaum noch ein Browser prominent anzeigt1. 😔

Update 2018-05-07 #2

Mir ist gerade aufgefallen, dass die Links im Feed fehlerhaft sind. Ich weiß nicht, ob etwas mit meiner Anleitung nicht stimmt oder ob ich einen Fehler in dem Feature gefunden habe.

Update 2018-05-07 #3

Behoben. 😄 Es war ein kleiner Fehler in meiner config, den ich jetzt auch hier im Beitrag angepasst habe.

Update 2018-05-08

Ich habe eine Notiz bzgl. der Konfiguration base und einen Link zum Anzeigen von Feeds im Firefox hinzugefügt.

Linux ist bereits ein Nische aber verglichen mit FreeBSD fast schon Mainstream auf dem Desktop. Nichts desto weniger kann man auch FreeBSD in der aktuellen Inkarnation 11 auf dem Desktop installieren und produktiv nutzen. Die meisten Open Source Desktopumgebungen stehen für FreeBSD zur Verfügung. Seit vergangener Woche nun endlich auch Plasma 5.

Die Installation sollte natürlich - keine BSD-Erfahrugen vorausgesetzt - immer zum probieren in einer virtuellen Maschine, z. B. Virtualbox, erfolgen. Dazu lädt man sich am besten das Boot-Medium herunter, was dann alle benötigten Dateien aus dem Internet bezieht. Eine aktuelle ISO-Datei kann man auf der FreeBSD Homepage beziehen. Die Basisinstallation ist derart optionsarm, das hier keine weiteren Erläuterungen notwendig sind. Man kann im wesentlichen die Standardoptionen nehmen, wobei beim Umfang ports und lib32 nicht unbedingt notwendig sind. Zusätzlich legt man noch einen Benutzer an und wählt ein Root-Kennwort.

Plasma-Installation

Nach dem Neustart begrüßt einen die Konsole. Einen Desktop installiert FreeBSD nicht und überlässt dem Anwender hier somit die Wahl. Die folgende Anleitung installiert einen aktuellen Plasma 5 Desktop mit einem minimalen Anwendungsset.

Zuerst bringt man das neu installierte System auf einen aktuellen Stand mittels freebsd-update:

# freebsd-update fetch

# freebsd-update install

Anschließend installiert man pkg. Dieses stellt vereinfacht gesagt das Äquivalent zu APT oder Zypper dar.

# pkg

Plasma 5 ist noch relativ neu in den Quellen, weshalb man noch eine Änderung vornehmen muss. In der Konfigurationsdatei /etc/pkg/FreeBSD.conf ist folgende Zeile anzupassen:

url: “pkg+http://pkg.FreeBSD.org/${ABI}/quarterly”,

zu 

url: “pkg+http://pkg.FreeBSD.org/${ABI}/latest”,

Mittels folgenden Befehl anschließend die Paketquellen aktualisieren:

# pkg update

Anschließen installiert man zuerst X11. Von modernen "Spielereien" wie Wayland sollte man unter BSD erst einmal die Finger lassen.

# pkg install xorg xterm twm

Darauf aufbauen kann man nun den Plasma 5-Desktop, sowie SDDM für die Anmeldung installieren. Man kann auch das volle KDE-Paket kde5 installieren, aber dadurch bekommt man wirklich die komplette KDE-Suite auf das System. Ich persönliche empfehle immer eine Basisinstallation und dann ein hinzufügen benötigter Komponenten.

# pkg install plasma5-plasma-desktop sddm

Die nun installierten Pakete sind wirklich sehr minimal. Da ist außer dem puren Plasma-Desktop nichts enthalten. Für zusätzliche Basiskomponenten wie Dolphin oder den KDE-Terminal sollte zusätzlich folgendes Metapaket installiert werden:

# pkg install kde-baseapps

Anschließend sind noch einige Änderungen in den Konfigurationsdateien vorzunehmen. Hier ist FreeBSD immer noch sehr altmodisch und erinnert an das Arch Linux früherer Jahre.

In der Datei /etc/rc.conf sind folgende beiden Zeilen hinzuzufügen:

dbus_enable="YES"
sddm_enable="YES"

Sofern man beabsichtigt Kontact/Akonadi zu nutzen sind zudem folgende Änderungen in /etc/sysctl.conf nötig:

net.local.stream.recvspace=65536
net.local.stream.sendspace=65536

Sofern man Plasma in deutscher Sprache nutzen möchte ist noch eine Änderung in /etc/profile notwendig. Hier muss die folgende Zeile hinzugefügt werden:

LANG=de_DE; export LANG

SDDM erscheint nun standardmäßig mit dem wenig anumutigen Standarddesign und englischem Tastaturlayout. Insbesondere letzteres ist bei der Passworteingabe zu berücksichtigen. Nach der Anmeldung erscheint ein aufgeräumter Plasma-Desktiop.

Konfigurationshinweise

SDDM kann in der Datei /usr/local/etc/sddm.conf konfiguriert werden. Das grafische KCM-Modul ist zwar vorhanden, funktionierte im Test aber nicht zuverlässig.

 Viele weitere Optionen kann man dem Desktop HowTo.

Fazit

FreeBSD mit Plasma 5 funktioniert zufriedenstellend und lässt sich für in etwa die gleichen Aufgaben nutzen wie der Linux Desktop. Insbesondere bei Problemen und vielen Einstellungen muss man noch unter der Haube konfigurieren. So mancher Linux-Nutzer dürfte sich da in vergangene Zeiten zurück versetzt fühlen. Letztlich gibt es keinen zwingenden Grund für FreeBSD, weshalb Linux-Nutzern kein Wechsel angeraten werden kann. Wer aber mal einen Blick über den Tellerrand riskieren will, sollte es mal probieren. BSD ist schon lange nicht mehr unbenutzbar!


Bilder:

Einleitungs- und Beitragsbild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

"

Ich habe mir jetzt doch Xubuntu 18.04 auf meinem Produktiv-Rechner installiert. Ich möchte wissen wie 18.04 läuft und wo es eventuell Probleme gibt.

Bionic Beaver
Xubuntu 18.04 Bionic Beaver

Hintergrund der Aktion ist, dass ich auf ubuntuusers.de am Wiki mitarbeiten möchte. Mir ist aufgefallen, dass viele Artikel seit mehreren Ubuntu-Versionen nicht mehr gepflegt werden.
Das Ubuntu Wiki ist auch immer eine Anlaufstelle für Anwender anderer Distributionen. Gerade deshalb finde ich es sehr wichtig, dass dieses Wiki aktuell gehalten wird. Ich denke wir erfahrenden Linux-User haben auch eine Verantwortung dafür, dass die Dokumentationen über GNU/Linux gepflegt werden. 🙂

5. Mai 2018

Am letzten Wochenende haben sich die Entwickler und Aktive rund um das linuxmuster.net Projekt zu einem Arbeitstreffen getroffen. Dort stellten sie unter anderem den aktuelle Stand zur neuen Version der Schulserverlösung vor. Die neue Version v7 wird ein großer Schritt um Vergleich zur aktuellen Version, da sich einige Dinge ändern werden. Darüber hatte ich bereits vor einigen Monaten gebloggt. Linuxmuster v7 soll bald als Alpha-Version verfügbar sein!

Releaseplan

Der Releaseplan sieht wie folgt aus, wobei der Grundsatz gilt: Es ist fertig, wenn es fertig ist!

  • Alpha Version → Mitte Mai 2018
  • Beta-Version → Juli 2018
  • Release von linuxmuster.net v7 → Dezember 2018

Es werden Tester gesucht, die bereit sind, die Alpha- und Beta-Versionen zu testen. Dazu kann man sich vorgefertigte Virtualbox-Images herunterladen. Eine Anleitung für die Ersteinrichtung und das Setup gibt es im Github-Repo des Projekts. Anleitung für die Ersteinrichtung

Die Protokolle der Arbeitstagungen werden i.d.R. im Vereinwiki des Projekts veröffentlicht.

Fazit

Persönlich freue ich mich sehr auf die neue Version von linuxmuster.net, denn die aktuelle Version funktioniert zwar gut und zuverlässig, doch technisch gesehen ist sie schon etwas in die Jahre gekommen (Samba3, Ubuntu 12.04). Auch der Wechsel zu einer neuen (besseren) Firewall finde ich gut, denn mit der neuen Version können wir unsere Firewall pfSense noch besser mit linuxmuster.net integrieren.

1 Kommentar

Der Beitrag Linuxmuster v7 bald als Alpha-Version verfügbar erschien zuerst auf .:zefanjas:..

4. Mai 2018

Ich habe hier vor einiger Zeit begonnen eine kleine Seite zu bauen, die es auch technisch weniger versierten einfacher machen soll in XMPP einzusteigen. Ziel war es JIDs in dieser Form an Kontakte zu geben und diese, falls sie XMPP noch nicht kennen, an die Hand zu nehmen und es jedem zu ermöglichen selbst einen Account zu erstellen, einen Client einzurichten und zu benutzen.

Leider hatte ich wenig Zeit das voranzutreiben und so ist die Seite leider noch in großen Teilen unvollständig und das Vorhandene teilweise vielleicht schon wieder veraltet.

Aus diesem Grund möchte ich den aktuellen Arbeitsstand heute mit diesem Blogpost bekannt machen und hoffe, dass der ein oder andere das Projekt sinnvoll findet und etwas dazu beitragen möchte.

Sollte die Seite einmal fertig werden könnte man auch über eine eigene Domain nachdenken. Die Seite wird mit Hugo generiert, liegt bei salsa.debian.org und ist CC BY-SA lizenziert, es kann also auch jeder einen Fork erstellen.

Die bisherigen Inhalte sollten auch ausreichend illustrieren wie die Seite einmal aufgebaut sein sollte:
Einfache Erklärungen, die für jeden verständlich sind, d.h. möglichst auf Fachbegriffe verzichten wo dies nicht unbedingt nötig ist und die Anleitungen sollten ausreichend mit Screenshots ausgestattet sein. Es sollte auch lieber eine Option gewählt und erläutert werden als neue User mit zu viel Wahlmöglichkeiten zu erschlagen, als konkretes Beispiel würde ich einen Client pro Betriebssystem erklären, statt erst den potentiellen XMPP-Nutzer mit den Vor- und Nachteilen bestimmter Anwendungen zu ermüden.

Natürlich kann man das alles noch unter Fortgeschrittene Themen unterbringen, aber die eigentliche Anleitung würde ich gerne so einfach wie möglich halten, damit sie leicht verständlich bleibt.

Update 2018-06-08

Das Repository ist von GitHub weggezogen.

Ich habe hier vor einiger Zeit begonnen eine kleine Seite zu bauen, die es auch technisch weniger versierten einfacher machen soll in XMPP einzusteigen. Ziel war es JIDs in dieser Form an Kontakte zu geben und diese, falls sie XMPP noch nicht kennen, an die Hand zu nehmen und es jedem zu ermöglichen selbst einen Account zu erstellen, einen Client einzurichten und zu benutzen.

Leider hatte ich wenig Zeit das voranzutreiben und so ist die Seite leider noch in großen Teilen unvollständig und das Vorhandene teilweise vielleicht schon wieder veraltet.

Aus diesem Grund möchte ich den aktuellen Arbeitsstand heute mit diesem Blogpost bekannt machen und hoffe, dass der ein oder andere das Projekt sinnvoll findet und etwas dazu beitragen möchte.

Sollte die Seite einmal fertig werden könnte man auch über eine eigene Domain nachdenken. Die Seite wird mit Hugo generiert, liegt bei salsa.debian.org und ist CC BY-SA lizenziert, es kann also auch jeder einen Fork erstellen.

Die bisherigen Inhalte sollten auch ausreichend illustrieren wie die Seite einmal aufgebaut sein sollte:
Einfache Erklärungen, die für jeden verständlich sind, d.h. möglichst auf Fachbegriffe verzichten wo dies nicht unbedingt nötig ist und die Anleitungen sollten ausreichend mit Screenshots ausgestattet sein. Es sollte auch lieber eine Option gewählt und erläutert werden als neue User mit zu viel Wahlmöglichkeiten zu erschlagen, als konkretes Beispiel würde ich einen Client pro Betriebssystem erklären, statt erst den potentiellen XMPP-Nutzer mit den Vor- und Nachteilen bestimmter Anwendungen zu ermüden.

Natürlich kann man das alles noch unter Fortgeschrittene Themen unterbringen, aber die eigentliche Anleitung würde ich gerne so einfach wie möglich halten, damit sie leicht verständlich bleibt.

Update 2018-06-08

Das Repository ist von GitHub weggezogen.

2. Mai 2018

Im Herbst 2016 hatte Mozilla das Projekt Mortar angekündigt. In dessen Rahmen hatte Mozilla damit experimentiert, den von Google entwickelten PDF-Betrachter PDFium in Firefox zu integrieren sowie das in Chrome genutzte Pepper-Plugin des Adobe Flash Players in Firefox zu verwenden anstelle des bisherigen NPAPI-Plugins. Das Projekt wurde nun offiziell gestoppt.

Mozilla hatte im Oktober 2016 das Projekt Mortar angekündigt. Ziel dieser Initiative war es, den Fokus noch stärker als bisher darauf zu legen, das Web weiterzuentwickeln und die Komplexität sowie den Wartungsaufwand von Firefox zu reduzieren. Konkret sollte dabei die Zeit reduziert werden, die Mozilla in Technologien investieren muss, welche für einen Browser zwingend erforderlich sind, damit das Web vollständig genutzt werden kann, aber kein elementarer Bestandteil der eigentlichen Web-Plattform sind.

Speziell hatte sich Mozilla dabei mit zwei Thematiken befasst: Mozilla selbst entwickelter PDF-Betrachter pdf.js sollte durch PDFium von Google ersetzt werden und der Adobe Flash Player sollte über eine Untermenge von Googles Pepper-API bereitgestellt werden anstelle der bisherigen NPAPI-Schnittstelle.

Nachdem das Projekt vor einigen Monaten bereits depriorisiert worden ist, folgte nun das offizielle Aus. Mozilla ist zu dem Entschluss gekommen, dass die Implementierung und Wartung von PDFium und der Pepper-API den Aufwand nicht ausreichend rechtfertigt.

Was Pepper-Flash betrifft, kommt mit Sicherheit auch dazu, dass seit vergangenem Jahr bekannt ist, dass die Unterstützung für den Adobe Flash Player Anfang 2020 komplett eingestellt werden wird.

Der Beitrag Mortar gestoppt: Kein PDFium und Pepper-Flash für Firefox erschien zuerst auf soeren-hentzschel.at.

1. Mai 2018

Vor gut einem Monat hat Google angekündigt, seinen hauseigenen URL-Shortener goo.gl einzustellen. Schade, denn ich habe den Dienst sehr gerne genutzt, um z.B. Artikel auf Twitter zu verteilen. URL-Shortener ermöglichen es, aus einer langen URL eine kurze zu erstellen, welche dann auf die ursprüngliche weiterleitet.

Darin steckt auch einer der Gründe und vormals Notwendigkeiten solcher Dienste, denn bevor Twitter eigene Maßnahmen zur Verbesserung von Links in Tweets ergriff (z.B. Einführung von t.co), waren die Services der einzige Weg, um halbwegs einen Link in den 140 Zeichen unterzubringen. Es wurde dafür in Kauf genommen, dass die entstandenen URLs alles andere als lesbar waren – sie sollten einfach nur funktionieren. 26 Groß- und Kleinbuchstaben und die zehn Ziffern bilden schon bei einer Zeichenlänge von konstant 5 Zeichen über 900 Millionen Möglichkeiten. ((26 + 26 + 10)5) Bitly ging als einer der bekanntesten Dienste hervor.

Auch nach der Anpassung seitens Twitter blieben die URLs trotz einiger Sicherheitsbedenken, denn man weiß auf den ersten Blick nicht, wohin man geleitet wird, weiter beliebt. Unternehmen wie Google nutzen für Firmeninhalte eigene URL-Shortener (z.B. g.co), um kürzere URLs zu erstellen – mit dem Unterschied, dass diese URLs klanghaft (Stichwort Vanity URLs) sind, man sich diese auch merken kann. So führt g.co/recover zum Wiederherstellungsprozess eines Google-Kontos.

Vorteil einer solchen Variante ist es, dass kürzere und merkfähigere URLs erstellt werden können, ohne die URL-Struktur einer Seite in ihrer Beständigkeit einzuschränken, denn Cool URIs don’t change. (zumindest die Canonical-URLs)

Warum also nicht einen Linkshortener auch auf der eigenen Seite einsetzen? Ziel sollte es sein, die Funktionalität für die eigenen Seite bereitzustellen und auch die komplette Kontrolle über den Shortener-Service zu behalten.

Und es gab für mein Einsatzszenario noch eine Besonderheit: das zugrunde liegende System bzw. Script sollte so klein und einfach wie möglich sein. One file. KISS eben. Deswegen fiel leider Yourls raus, weil es aus meiner Sicht für diesen Zweck etwas zu anspruchsvoll ist. Wer eine leistungsfähigere Lösung braucht, ist mit Yourls gut bedient, ich will aber z.B. nur v-gar.de/-mysql-1698 zu meinem MySQL-Artikel weiterleiten.

So entstand Atajlio. Die Installation ist denkbar einfach: index.php herunterladen, u.U. umbenennen, auf den Webspace packen, sicherstellen, dass PHP sowie der PHP PDO-SQLite-Support laufen (ist i.d.R. der Fall) und das Script in dem Verzeichnis schreiben kann und die File über den Webserver aufrufen. Nach erfolgreicher Initialisierung (d.h. ./atajlio.db wird angelegt, Pfad lässt sich aber vorher umkonfigurieren) wird eine Admin-URL einmalig angezeigt. Diese merken bzw. sichern, sie ist der Zugang für die Verwaltungskonsole. Jetzt ein URL-Rewriting konfigurieren und z.B.
example.com/-XXX auf example.com/atajlio/?l=XXX mappen.

Abschließend example.com/-adminurl entsprechend aufrufen, UNBEDINGT den Zugriff auf die DB-File (in .htaccess bzw. Webserver-Configfile) sperren – fertig.

Der Source Code liegt bei GitHub und steht unter der MIT-Lizenz.

Das Projekt soll weiterentwickelt sowie dokumentiert werden und ich überlege momentan, doch noch einige Einstellungsmöglichkeiten für z.B. MySQL einzubauen, bin aber mit dem aktuellen Ergebnis in der Funktionsweise schon ganz zufrieden.

Selbstverständlich freue ich mich über jedes Feedback!

Mit der bevorstehenden Veröffentlichung von Mozilla Thunderbird 60 bekommt der freie E-Mail-Client nicht nur neue Funktionen und optisch einen überarbeiteten Anstrich, ähnlich wie bei Firefox mit Version 57 wird auch das Logo von Thunderbird erneuert. Dieser Artikel enthüllt, wie das neue Logo aussehen soll.

Mit Firefox 57 hat Mozilla seinen Browser grundlegend verbessert. Die Änderungen waren so groß, dass es Mozilla für den idealen Zeitpunkt hielt, auch das Firefox-Logo zu modernisieren. Nun steht die Veröffentlichung von Thunderbird 60 kurz bevor, dem ersten großen Update seit Thunderbird 52 vor einem Jahr.

Neben dem neuen Firefox-Logo sieht das bisherige Thunderbird-Logo nicht mehr ganz auf der Höhe der Zeit aus. Um das zu ändern, hat die Thunderbird-Community in Anlehnung an das neue Firefox-Logo das Logo von Thunderbird überarbeitet. Das Thunderbird-Konsul hat dem neuen Logo gestern zugestimmt, jetzt muss es nur noch von der Mozilla Foundation freigegeben werden.

Thunderbird Logo 2018

Der Beitrag Das ist das neue Thunderbird-Logo erschien zuerst auf soeren-hentzschel.at.

Vor gut einem Monat hat Google angekündigt, seinen hauseigenen URL-Shortener goo.gl einzustellen. Schade, denn ich habe den Dienst sehr gerne genutzt, um z.B. Artikel auf Twitter zu verteilen. URL-Shortener ermöglichen es, aus einer langen URL eine kurze zu erstellen, welche dann auf die ursprüngliche weiterleitet.

Darin steckt auch einer der Gründe und vormals Notwendigkeiten solcher Dienste, denn bevor Twitter eigene Maßnahmen zur Verbesserung von Links in Tweets ergriff (z.B. Einführung von t.co), waren die Services der einzige Weg, um halbwegs einen Link in den 140 Zeichen unterzubringen. Es wurde dafür in Kauf genommen, dass die entstandenen URLs alles andere als lesbar waren - sie sollten einfach nur funktionieren. 26 Groß- und Kleinbuchstaben und die zehn Ziffern bilden schon bei einer Zeichenlänge von konstant 5 Zeichen über 900 Millionen Möglichkeiten. ((26 + 26 + 10)5) Bitly ging als einer der bekanntesten Dienste hervor.

Auch nach der Anpassung seitens Twitter blieben die URLs trotz einiger Sicherheitsbedenken, denn man weiß auf den ersten Blick nicht, wohin man geleitet wird, weiter beliebt. Unternehmen wie Google nutzen für Firmeninhalte eigene URL-Shortener (z.B. g.co), um kürzere URLs zu erstellen - mit dem Unterschied, dass diese URLs klanghaft (Stichwort Vanity URLs) sind, man sich diese auch merken kann. So führt g.co/recover zum Wiederherstellungsprozess eines Google-Kontos.

Vorteil einer solchen Variante ist es, dass kürzere und merkfähigere URLs erstellt werden können, ohne die URL-Struktur einer Seite in ihrer Beständigkeit einzuschränken, denn Cool URIs don't change. (zumindest die Canonical-URLs)

Warum also nicht einen Linkshortener auch auf der eigenen Seite einsetzen? Ziel sollte es sein, die Funktionalität für die eigenen Seite bereitzustellen und auch die komplette Kontrolle über den Shortener-Service zu behalten.

Und es gab für mein Einsatzszenario noch eine Besonderheit: das zugrunde liegende System bzw. Script sollte so klein und einfach wie möglich sein. One file. KISS eben. Deswegen fiel leider Yourls raus, weil es aus meiner Sicht für diesen Zweck etwas zu anspruchsvoll ist. Wer eine leistungsfähigere Lösung braucht, ist mit Yourls gut bedient, ich will aber z.B. nur v-gar.de/-mysql-1698 zu meinem MySQL-Artikel weiterleiten.

So entstand Atajlio. Die Installation ist denkbar einfach: index.php herunterladen, u.U. umbenennen, auf den Webspace packen, sicherstellen, dass PHP sowie der PHP PDO-SQLite-Support laufen (ist i.d.R. der Fall) und das Script in dem Verzeichnis schreiben kann und die File über den Webserver aufrufen. Nach erfolgreicher Initialisierung (d.h. ./atajlio.db wird angelegt, Pfad lässt sich aber vorher umkonfigurieren) wird eine Admin-URL einmalig angezeigt. Diese merken bzw. sichern, sie ist der Zugang für die Verwaltungskonsole. Jetzt ein URL-Rewriting konfigurieren und z.B. example.com/-XXX auf example.com/atajlio/?l=XXX mappen.

Abschließend example.com/-adminurl entsprechend aufrufen, UNBEDINGT den Zugriff auf die DB-File (in .htaccess bzw. Webserver-Configfile) sperren - fertig.

Der Source Code liegt bei GitHub und steht unter der MIT-Lizenz.

Das Projekt soll weiterentwickelt sowie dokumentiert werden und ich überlege momentan, doch noch einige Einstellungsmöglichkeiten für z.B. MySQL einzubauen, bin aber mit dem aktuellen Ergebnis in der Funktionsweise schon ganz zufrieden.

Selbstverständlich freue ich mich über jedes Feedback!

Wählt man bei Online-Händlern die Zahlungsweise Kreditkartenzahlung aus, wird man heute in den meisten Fällen mit dem Verfahren 3-D Secure [1] konfrontiert. Je nachdem welche Kreditkarte man verwendet, heißt das Verfahren Verified by Visa oder bei einer Mastercard SecureCode.

Durch das Verfahren sollen Zahlungsausfälle durch Kreditkartenmissbrauch reduziert werden. Teilnehmenden Online-Händlern wird zudem der Zahlungseingang garantiert, wenn sie 3-D Secure einsetzen.

Doch welche Vorteile bietet dieses Verfahren für den Kunden? Auf den ersten Blick gar keine. Statt eines Passwortes muss der Kunde sich nun eine PIN für die Banking-App bzw. für sein mobiles Endgerät merken.

Im Wikipedia-Artikel zu 3-D Secure [1] wird zudem ausgeführt:

Auch im Jahr 2018 gibt es jedoch noch Konstellationen, in denen die Haftungsfrage eindeutig zu Lasten des Kunden ausfällt und die Registrierung zu 3-D Secure ein im Vergleich zu anderen Zahlungswegen für den Kunden außergewöhnlich riskantes Verfahren sein kann, wie folgender Fall verdeutlicht: Die DKB hat vom statischen Sicherheitscode auf einen dynamischen Code per App oder mTAN umgestellt. In ihren Sonderbedingungen für 3-D Secure legt die DKB aktuell einen Haftungsausschluss für den Fall fest, „dass das mobile Endgerät verloren, gestohlen oder weitergegeben wird und dadurch Dritte ggf. Zugriff auf SMS erhalten und diese unberechtigt nutzen können“. Bei einem möglichen gleichzeitigen Verlust von Kreditkarte und Mobilfunkgerät kann ein Finder also beliebige Zahlungen zu Lasten des Besitzers auslösen und verifizieren, vorausgesetzt er bekommt Zugang zum Mobilgerät (etwa durch eine einfache Tastensperre). Für diese missbräuchlichen Zahlungen haftet der Kunde vollständig bis zur Sperrung der Karte, bei einer Zahlung ohne 3-D Secure haftet er dagegen nur bis maximal 50 €. Bei Verlust stellen weder die auf der Karte aufgedruckten Daten, noch das 3-D-Secure-Verfahren eine Hürde für den einfachen Missbrauch dar, sondern lediglich die PIN oder vergleichbare Sicherungsmechanismen des Mobilgeräts. Das Risiko für den Kunden ist in dieser Konstellation höher, als ohne Registrierung zum 3-D-Secure-Verfahren, unabhängig davon, ob der Kunde 3-D Secure überhaupt benutzt.

Diese Aussage ließ mich zunächst zweifeln, ob ich mich überhaupt noch zum dynamischen 3-D Secure Verfahren anmelden sollte. Ich beschloss daher, die Sonderbedingungen für das 3D Secure Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte [2] genau zu lesen und im Zweifel bei meiner Bank nachzufragen, wie es sich mit der Haftung verhält.

Aus den Sonderbedingungen für das 3D Secure Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte

Im Folgenden zitiere ich aus den oben genannten Sonderbedingungen [2] und liste die Fragen auf, welche durch die genannten Punkte aufgeworfen wurden.

Sorgfaltspflichten des Karteninhabers

Hier Punkt 1:

1) Der Karteninhaber
a) hat das Risiko eines unberechtigten Zugriffs auf sein mobiles Endgerät u. a. durch geeignete Schutzmaßnahmen zu minimieren (z.B. PIN auf mobiles Endgerät).
b) hat das Betriebssystem des von ihm verwendeten Endgerätes auf dem neuesten Stand zu halten.
c) hat die App nur aus offiziellen App-Stores (iTunes, Google Playstore, Windows Store) herunterzuladen und dafür vorgesehene Updates regelmäßig durchzuführen.

Während Punkt a) noch einleuchtet, wirft Punkt b) bereits erste Fragen auf. Was mache ich, wenn mein Endgerät schon älter ist und der Hersteller keine Updates mehr für das Betriebssystem veröffentlicht? Was ist, wenn ich mir im Handel ein neues Android-Gerät kaufe, welches mit einer älteren Android-Version ausgeliefert wird und vom Hersteller ebenfalls keine Updates mehr für das Betriebssystem erhält? Darf ich in oben genannten Fällen überhaupt noch am 3-D Secure Verfahren teilnehmen? Oder darf die DKB in diesen Fällen bereits die Haftung im Missbrauchsfall ablehnen?

Zu Punkt 3:

Die DKB AG haftet nicht für den Fall, dass das mobile Endgerät verloren, gestohlen oder weitergegeben wird und dadurch Dritte ggf. Zugriff auf SMS erhalten und diese unberechtigt nutzen können.

Dies ist der Punkt, welcher bereits im Wikipedia-Artikel [1] kritisiert wurde. Hier stellt sich die Frage, ob ich mich mit einer Teilnahme an 3-D Secure nicht schlechter stelle.

Verantwortlichkeit und Haftung

Punkt 7 der Sonderbedingungen [2] widmet sich dann konkret der Haftung:

[…] Die DKB AG übernimmt außerdem keine Haftung bei Manipulation des mobilen Endgeräts (z.B. Jailbreaking, Rooting).

Bedeutet dies, dass Nutzer freier bzw. alternativer Betriebssysteme das Verfahren nicht nutzen können? Schließlich sind Jailbreaks und Rooting oftmals Voraussetzung, um ein Custom-ROM auf ein Endgerät aufspielen zu können.

Mit obigen Fragen habe ich mich per E-Mail an die DKB gewendet und um schriftliche Antwort gebeten.

Die Antwort der DKB

Eine Antwort ließ nicht lange auf sich warten. Man bat darum, die Sache zunächst am Telefon zu erörtern. Auf Wunsch bestätigte man mir die wesentlichen Inhalte dann auch schriftlich.

Nach Aussage eines Mitarbeiters aus der Technik wurde die DKB Secure App so entworfen, dass sie den Patchlevel des mobilen Betriebssystems prüfen und erkennen kann, ob das Gerät gerootet bzw. gejailbreakt wurde. Ist letzteres der Fall oder ist der Patchlevel des Endgerätes zu alt, verweigert die App den Start.

Mir wurde bestätigt, dass dies im Umkehrschluss bedeutet, dass wenn die App startet, die Sorgfaltspflicht aus Punkt 1.b) als erfüllt angesehen werden kann.

Die schlechte Nachricht für die Freunde freier Betriebssysteme ist, dass die DKB jegliche Haftung ablehnt, wenn die App nicht aus den offiziellen App Stores bezogen wurde und/oder unter einem Custom-ROM betrieben wird. Der Haftungsausschluss gilt in diesem Fall übrigens auch, wenn man statt der App das mTAN-Verfahren via SMS nutzen möchte.

Steht noch die Antwort zu Punkt 3 aus. Hierzu teilte mir eine Mitarbeiterin aus der Fachabteilung Privatkundenservice mit, dass die Haftung bei Diebstahl des mobilen Endgeräts nur dann ausgeschlossen ist, wenn der Kunde grob fahrlässig gehandelt hat. Unter grobe Fahrlässigkeit fällt dabei zum Beispiel, dass:

  • das Endgerät nicht mit einer Zugangssperre (PIN) versehen ist,
  • oder die PIN des Endgeräts bzw. der App zusammen mit der Kreditkarte oder dem Endgerät aufbewahrt wird.

Die Beweislast, dass grobe Fahrlässigkeit vorliegt, liegt in diesem Fall bei der Bank.

Mein persönliches Fazit

Die DKB hat zeitnah auf meine Fragen reagiert und diese zu meiner Zufriedenheit beantwortet. Dies empfinde ich als positiv.

Dass die Nutzung freier bzw. alternativer Betriebssysteme quasi ausgeschlossen ist, da bei Jailbreak oder Rooting die Haftung komplett ausgeschlossen wird, bedaure ich. Da man mit einem Jailbreak bzw. Rooting jedoch elementare Sicherheitsmechanismen umgehen kann, kann ich den Haftungsausschluss an dieser Stelle nachvollziehen.

Ich selbst habe mein Telefon nun wieder mit einer PIN versehen und meine Kreditkarte registriert.

Ob es bei SecureCode für Mastercard genauso aussieht, kann ich noch nicht sagen. Sobald ich die Bedingungen hierfür gefunden, studiert und eventuelle Fragen geklärt habe, werde ich diesen Artikel aktualisieren.

Quellen und weiterführende Links

[1] Wikipedia: 3-D Secure
[2] Sonderbedingungen für das 3D Secure-Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte
[3] smsTAN vs. pushTAN vs. chipTAN

Bild von TheDigitalArtist via pixabay / Lizenz: CC0 Public Domain

Sicherheit ist genau so wie Privacy Protection mittlerweile in nahezu jeder Ankündigung, Produktvorstellung oder Updatemeldung zu finden. Die Firmen bedienen damit ein Bedürfnis nach gefühlter Sicherheit unter den Kunden und Dienstnutzern. Doch "Sicherheit" ist kein feststehender Begriff und oftmals äußerst schwammig formuliert. Teilweise gewinnt man den Eindruck Firmen wollen den technisch unbedarften Anwender gezielt in die Irre führen um ihre Dienste populärer zu machen.

Keine definierten Begriffe

Die bekanntesten Beispiele für dieses Vorgehen sind sicherlich die sozialen Netzwerke. Datenschutz meint hier in der Regel keine Datensparsamkeit, die in den meisten europäischen Gesellschaften noch immer dem Datenschutz-Konzept zu Grunde liegt, sondern die Möglichkeit die öffentliche Sichtbarkeit zu steuern. Frei nach dem Motto "Was der Staat oder der Dienstanbieter weiß ist kein Problem, Hauptsache die Nachbarn wissen es nicht".

Deutlich extremer betrieb in den vergangenen Monaten Google dieses Sicherheitsmarketing. Google versucht sich schon seit längerem an einer Charme-Offensive im europäischen Raum, was vermutlich auch an den laufenden EU-Verfahren gegen den Konzern liegt. Die Quasi-Monopolisten aus Kalifornien werden langsam mit normalen wirtschaftspolitischen Maßstäben gemessen und reguliert, weshalb diese nun versuchen nun global staatliche Maßnahmen zu abzuschwächen. Sowas nennt sich halt Lobbyarbeit. In Demokratien ist es dafür nicht schlecht, wenn die Bevölkerung meint, man gehöre zu "den Guten".

Hier ist hilfreich, dass zwar viele Menschen "Sicherheit" und "Datenschutz" gut finden. Die wenigsten aber diese Begriffe wirklich definieren und somit leere Marketinghülsen als solche entlarven können.

Produktankündigungen ohne kritische Presse

Im konkreten Fall verspricht z. B. Google man entwickle "ein neues Gmail". Hier bewirbt man neben Phishing-Schutzmaßnahmen auch vertrauliche E-Mails mit Ablaufdaten und Widerruf. Sowie der Möglichkeit E-Mail Funktionen wie Weiterleiten, Kopieren, Herunterladen etc. zu deaktivieren. Klingt alles ziemlich gut und viele IT-Medien gaben die Pressemitteilung ziemlich kritiklos wieder. Zum Glück bezahlten manche Seiten noch Redakteure für kritische Berichterstattung.

Die E-Mail ist ein standardisiertes Protokoll und wirkliche Veränderungen auf Protokollebene sind folglich ein langwieriger Abstimmungsprozess. Man muss kein Experte sein um das zu wissen. Viele dieser Funktionen werden folglich nur zur Verfügung stehen, wenn man sich ausschließlich innerhalb des GMail-Systems bewegt. Sowohl Empfänger, als auch Absender müssen GMail verwenden um diese Funktionen zu nutzen. Das hebelt einen entscheidenden Vorteil des E-Mail Systems aus: Die Dezentralität. GMail ist sehr erfolgreich, Ausflüge Googles in den Messenger-Bereich waren dies eher nicht. Vielleicht möchte man nun den sehr erfolgreichen Dienst zum Sprungbrett für ein geschlossenes Kommunikationssystem machen, bei dem man eben auch noch nach außen schreiben kann - mit abgespeckten Funktionen.

Gleichwohl ist Sicherheit hier auch wieder in der oben genannten Definition zu verstehen. "Sicher" ist wenn ich verhindern kann, dass der Empfänger meine Nachricht beliebig vervielfältigt, "sicher" ist wenn ich vor Phishing geschützt bin. Ende-zu-Ende Verschlüsselung kommt nicht vor. Auch E-Mails mit Ablaufdatum und Vervielfältigungsschutz werden für Google ein offenes Buch sein - auch wenn man inzwischen das scannen für Werbezwecke eingestellt hat.

Ein anderes Beispiel ist Chrome. Hier präsentiert man sich als Vorreiter für ein sicheres Web und beginnt nun im Sommer aktiv damit Seiten ohne HTTPS-Verbindung zu bestrafen. Eine durchgehende HTTPS-Verschlüsselung des Netzes wäre zwar wünschenswert, ändern aber nichts daran, dass HTTPS nichts am hemmungslosen Nutzertracking ändert. Ein Bereich in dem Google als Werbefirma führend ist, es gibt schließlich gute Gründe Google als Datenkrake zu bezeichnen.

Der kürzlich lancierte integrierte Werbeblocker in Chrome soll wohl dementsprechend auch eher dazu führen, dass der Werbemarkt konsolidiert wird und weniger Anwender Blocker nutzen, die auch Google-Werbung blockieren.

Open Source Verflechtungen

Besonders prekär ist diese Marketing-Strategie im Open Source-Bereich. Open Source-Software bzw. quelloffene Entwicklung sind extrem positiv besetzt. In einer Gesellschaft die nach Transparenz strebt hört sich das einfach gut an. Dem gegenüber stehen geschlossene Firmen wie Apple oder Microsoft, die bestenfalls den Ruf haben einen goldenen Käfig zu errichten und schlimmstenfalls als dunkle Monopolisten erscheinen, die wie Kraken Staaten korrumpieren und ihre Dienste durchsetzen. (siehe z.B. die Resonanz auf die ARD Dokumentation "Das Microsoft Dilemma" oder die Berichterstattung zu Lizenzkosten des Bundes)

Viel zu wenig Beachtung finden Abhängigkeiten in der Open Source-Entwicklung. Hier haben Firmen wie beispielsweise Google ein enges Netz von Abhängigkeiten errichtet. Erstens hat man es geschafft, dass man als Open Source-Unternehmen wahrgenommen wird. Produkte wie Android und Chrome respektive Chromium sind ja quelloffen, der zweite Satz auf Wikipedia zu Chrome bezieht sich z. B. darauf.. Die ganzen proprietären Apps und nicht freien Teile finden kaum Beachtung. Zweitens hat man durch Sponsoring wie den Google Summer of Code ein ungutes Abhängigkeitsverhältnis vieler Open Source-Projekte geschaffen. Man sponsert Projekte, finanziert Sicherheitsüberprüfungen, unterstützt mit viel Geld den Hauptkonkurrenten auf dem Browsermarkt Mozilla. etc. pp.

Viele Open Source-Projekte stehen daher Google Diensten viel zu unkritisch gegenüber. Die starke Einbindung von Google Produkten wie der Engine Blink, Chromium in Distributionen, Google als Standardsuche usw. usf. sprechen da Bände.

Plan? Wohl eher nicht

Sind die IT-Giganten im Silicon Valley nun alle böse? Nein ganz bestimmt nicht. Die großen IT-Firmen haben keinen dunklen Plan zur Weltherrschaft oder arbeiten alle für böse Geheimdienste. Solche Verschwörungstheorien sind quatsch.

Die Firmen haben aber erkannt, dass man ein gutes Image braucht um erfolgreich zu sein und sein Geschäftsmodell zu behaupten. Man kann schließlich sehen, wie schwer es werden kann sich am Markt zu behaupten, wenn man erst einmal - wie beispielsweise Microsoft - ein eher zweifelhaftes Bild in der Öffentlichkeit hat. Wenn das eigene Geschäftsmodell auf Werbung und der damit zusammenhängen massenhaften Auswertung von Benutzerdaten beruht, dann sollte man dafür sorgen, dass der Gesetzgeber in den wichtigen Märkten hier nicht zu stark regulierend eingreift.

Um das zu erreichen tut man so, als ob einem die Sicherheit des Internets am Herzen liegt. Man tut natürlich auch etwas für die Sicherheit, z. B. für den Schutz vor illegalen Angriffen und anderen Bedrohungen. Allerdings hat man auch nichts dagegen, wenn der Kunde davon ausgehend stillschweigend davon ausgeht, dass man etwas für die Datensicherheit tut.

Die Open Source-Gemeinschaft sollte jedenfalls aufpassen, dass sie ihre Unabhängigkeit hier nicht zusehends verliert. Tabakfirmen sponsern manchmal auch Nichtraucherkampagnen. Demnächst sollen ja auch dann auch Linux-Apps auf ChromeOS laufen.

"

30. April 2018

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Ich verstehe, dass es Websiten gibt, die sich über Werbung finanzieren. Das ist in meinen Augen auch vollkommen in Ordnung.
Nicht in Ordnung ist es in meinen Augen jedoch, wenn entweder die Werbung überhand vor dem eigentlichen Inhalt nimmt oder aber, wenn ein Gerät, welches ich gekauft habe, mir auf einmal Werbung um die Ohren haut. Als ein Beispiel sei hier einmal mein TV von Samsung genannt.

Das erste Problem kann man mittels Werbeblockern mittlerweile ziemlich gut in den Griff bekommen. Ich selbst bin ein großer Fan von Ublock Origin. Aber zum einen mag ich möglichst wenige Extensions in meinem Browser nutzen, zum anderen löst es nicht das Problem mit den Werbe-Apps auf meinem TV.

Ich nutze nun seit einigen Monaten Pi-Hole. Pi-Hole ist ein DNS-Server, der im lokalen Netzwerk aufgesetzt wird. Ob auf einem Raspberry Pi, der sich dafür anbietet, oder jedem anderen Server ist vollkommen egal. Für die gängigsten Linux-Distributionen gibt es fertige Binaries.

Hardware

Pi-hole is very lightweight as it only handles DNS queries and returns a blank HTML file so it doesn’t need much processing power.

~52MB of free space
512 MB RAM

We officially support the following:

Raspbian: Jessie (Only up to Pi-hole v3.2.1 1.1k) / Stretch (lite / with pixel)
Ubuntu: 16.04 / 16.10
Debian: 8 / 9
Fedora 26
CentOS: 7 (not ARM)

Anders als ein Werbeblocker im Browser, der die entsprechenden Javascript-Dateien auf der Website blockiert, blockiert Pi-Hole auf DNS-Ebene, was bedeutet, dass die Auflösung der URls der Werbenetzwerke bereits beim Versuch des Verbindungsaufbaus verhindert wird. Ein Werbeblocker im Browser ist damit quasi obsolet - kann aber trotzdem nicht schaden, sofern Pi-Hole mal etwas entgehen sollte.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Ich selbst nutze Pi-Hole auf einem Raspberry Pi der ersten Generation mit 512 MB Ram, der damit noch wunderbar klar kommt. Die Installation ist ziemlich simpel. Voraussetzung ist ein bereits eingerichter Raspberry, idealerweise erreichbar über SSH.

Mittels curl -sSL https://install.pi-hole.net | bash wird automatisch der Installer heruntergladen und gestartet. Pi-Hole selbst führt euch mittels Assistenten durch die Konfiguration.
Neben der Netzwerkkonfiguration, den Nameservern, die zur Abfrage genutzt werden, könnt ihr hier auch IPV6-Support aktivieren.

Anschließend ist das Webportal von Pi-Hole unter http://IP-eures-PIs/admin erreichbar. Über dieses lassen sich nicht nur Statistiken anzeigen, ihr könnt Pi-Hole bei Problemen auch testweise deaktivieren oder Einstellungen bezüglich verwendeten der DNS-Server vornehmen. Auch DNSSEC support kann auf Wunsch aktiviert werden.

Damit eure Endgeräte in eurem Netzwerk nun aber auch eure Pi-Hole-Installation nutzen, ist es notwendig den DNS-Server in eurem Router, in meinem Falle einer Fritzbox anzupassen - natürlich könnte man das auch manuell je Gerät nutzen - ich möchte jedoch, dass jedes Gerät, welches mit meinem Netzwerk verbunden ist Pi-Hole als DNS-Server verwendet.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Geht dazu in die Oberfläche eurer Fritzbox und wechselt in den Punkt Heimnetz. Dort findet ihr unter dem Reiter Netzwerkeinstellungen den Bereich IP-Adressen. Abhängig davon, ob ihr IPv4 und/oder IPv6 nutzt, müssen die folgenden Schritte pro Protokoll durchgeführt werden - was beispielsweise bei mir durch Dual Stack notwendig ist.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Im nächsten Dialog könnt ihr nun den DNS-Server hinterlegen. Tragt hier je nach Protokoll die IPv4 oder IPv6-Adresse eurer Installation ein. Diese hat euch der Konfigurations-Assistent am Ende auch mitgeteilt.

Anschließend speichern, ggf. einmal eure Endgeräte neustarten bzw. den DHCP-Lease erneuern. Fertig.

Ich verstehe, dass es Websiten gibt, die sich über Werbung finanzieren. Das ist in meinen Augen auch vollkommen in Ordnung.
Nicht in Ordnung ist es in meinen Augen jedoch, wenn entweder die Werbung überhand vor dem eigentlichen Inhalt nimmt oder aber, wenn ein Gerät, welches ich gekauft habe, mir auf einmal Werbung um die Ohren haut. Als ein Beispiel sei hier einmal mein TV von Samsung genannt.

Das erste Problem kann man mittels Werbeblockern mittlerweile ziemlich gut in den Griff bekommen. Ich selbst bin ein großer Fan von Ublock Origin. Aber zum einen mag ich möglichst wenige Extensions in meinem Browser nutzen, zum anderen löst es nicht das Problem mit den Werbe-Apps auf meinem TV.

Ich nutze nun seit einigen Monaten Pi-Hole. Pi-Hole ist ein DNS-Server, der im lokalen Netzwerk aufgesetzt wird. Ob auf einem Raspberry Pi, der sich dafür anbietet, oder jedem anderen Server ist vollkommen egal. Für die gängigsten Linux-Distributionen gibt es fertige Binaries.

Hardware

Pi-hole is very lightweight as it only handles DNS queries and returns a blank HTML file so it doesn’t need much processing power.

~52MB of free space512 MB RAM

We officially support the following:

Raspbian: Jessie (Only up to Pi-hole v3.2.1 1.1k) / Stretch (lite / with pixel)Ubuntu: 16.04 / 16.10Debian: 8 / 9Fedora 26CentOS: 7 (not ARM)

Anders als ein Werbeblocker im Browser, der die entsprechenden Javascript-Dateien auf der Website blockiert, blockiert Pi-Hole auf DNS-Ebene, was bedeutet, dass die Auflösung der URls der Werbenetzwerke bereits beim Versuch des Verbindungsaufbaus verhindert wird. Ein Werbeblocker im Browser ist damit quasi obsolet – kann aber trotzdem nicht schaden, sofern Pi-Hole mal etwas entgehen sollte.

alt

Ich selbst nutze Pi-Hole auf einem Raspberry Pi der ersten Generation mit 512 MB Ram, der damit noch wunderbar klar kommt. Die Installation ist ziemlich simpel. Voraussetzung ist ein bereits eingerichter Raspberry, idealerweise erreichbar über SSH.

Mittels curl -sSL https://install.pi-hole.net | bash wird automatisch der Installer heruntergladen und gestartet. Pi-Hole selbst führt euch mittels Assistenten durch die Konfiguration.
Neben der Netzwerkkonfiguration, den Nameservern, die zur Abfrage genutzt werden, könnt ihr hier auch IPV6-Support aktivieren.

Anschließend ist das Webportal von Pi-Hole unter http://IP-eures-PIs/admin erreichbar. Über dieses lassen sich nicht nur Statistiken anzeigen, ihr könnt Pi-Hole bei Problemen auch testweise deaktivieren oder Einstellungen bezüglich verwendeten der DNS-Server vornehmen. Auch DNSSEC support kann auf Wunsch aktiviert werden.

Damit eure Endgeräte in eurem Netzwerk nun aber auch eure Pi-Hole-Installation nutzen, ist es notwendig den DNS-Server in eurem Router, in meinem Falle einer Fritzbox anzupassen – natürlich könnte man das auch manuell je Gerät nutzen – ich möchte jedoch, dass jedes Gerät, welches mit meinem Netzwerk verbunden ist Pi-Hole als DNS-Server verwendet.

alt

Geht dazu in die Oberfläche eurer Fritzbox und wechselt in den Punkt Heimnetz. Dort findet ihr unter dem Reiter Netzwerkeinstellungen den Bereich IP-Adressen. Abhängig davon, ob ihr IPv4 und/oder IPv6 nutzt, müssen die folgenden Schritte pro Protokoll durchgeführt werden – was beispielsweise bei mir durch Dual Stack notwendig ist.

alt

Im nächsten Dialog könnt ihr nun den DNS-Server hinterlegen. Tragt hier je nach Protokoll die IPv4 oder IPv6-Adresse eurer Installation ein. Diese hat euch der Konfigurations-Assistent am Ende auch mitgeteilt.

Anschließend speichern, ggf. einmal eure Endgeräte neustarten bzw. den DHCP-Lease erneuern. Fertig.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Ich verstehe, dass es Websiten gibt, die sich über Werbung finanzieren. Das ist in meinen Augen auch vollkommen in Ordnung.
Nicht in Ordnung ist es in meinen Augen jedoch, wenn entweder die Werbung überhand vor dem eigentlichen Inhalt nimmt oder aber, wenn ein Gerät, welches ich gekauft habe, mir auf einmal Werbung um die Ohren haut. Als ein Beispiel sei hier einmal mein TV von Samsung genannt.

Das erste Problem kann man mittels Werbeblockern mittlerweile ziemlich gut in den Griff bekommen. Ich selbst bin ein großer Fan von Ublock Origin. Aber zum einen mag ich möglichst wenige Extensions in meinem Browser nutzen, zum anderen löst es nicht das Problem mit den Werbe-Apps auf meinem TV.

Ich nutze nun seit einigen Monaten Pi-Hole. Pi-Hole ist ein DNS-Server, der im lokalen Netzwerk aufgesetzt wird. Ob auf einem Raspberry Pi, der sich dafür anbietet, oder jedem anderen Server ist vollkommen egal. Für die gängigsten Linux-Distributionen gibt es fertige Binaries.

Hardware

Pi-hole is very lightweight as it only handles DNS queries and returns a blank HTML file so it doesn’t need much processing power.

~52MB of free space
512 MB RAM

We officially support the following:

Raspbian: Jessie (Only up to Pi-hole v3.2.1 1.1k) / Stretch (lite / with pixel)
Ubuntu: 16.04 / 16.10
Debian: 8 / 9
Fedora 26
CentOS: 7 (not ARM)

Anders als ein Werbeblocker im Browser, der die entsprechenden Javascript-Dateien auf der Website blockiert, blockiert Pi-Hole auf DNS-Ebene, was bedeutet, dass die Auflösung der URls der Werbenetzwerke bereits beim Versuch des Verbindungsaufbaus verhindert wird. Ein Werbeblocker im Browser ist damit quasi obsolet - kann aber trotzdem nicht schaden, sofern Pi-Hole mal etwas entgehen sollte.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Ich selbst nutze Pi-Hole auf einem Raspberry Pi der ersten Generation mit 512 MB Ram, der damit noch wunderbar klar kommt. Die Installation ist ziemlich simpel. Voraussetzung ist ein bereits eingerichter Raspberry, idealerweise erreichbar über SSH.

Mittels curl -sSL https://install.pi-hole.net | bash wird automatisch der Installer heruntergladen und gestartet. Pi-Hole selbst führt euch mittels Assistenten durch die Konfiguration.
Neben der Netzwerkkonfiguration, den Nameservern, die zur Abfrage genutzt werden, könnt ihr hier auch IPV6-Support aktivieren.

Anschließend ist das Webportal von Pi-Hole unter http://IP-eures-PIs/admin erreichbar. Über dieses lassen sich nicht nur Statistiken anzeigen, ihr könnt Pi-Hole bei Problemen auch testweise deaktivieren oder Einstellungen bezüglich verwendeten der DNS-Server vornehmen. Auch DNSSEC support kann auf Wunsch aktiviert werden.

Damit eure Endgeräte in eurem Netzwerk nun aber auch eure Pi-Hole-Installation nutzen, ist es notwendig den DNS-Server in eurem Router, in meinem Falle einer Fritzbox anzupassen - natürlich könnte man das auch manuell je Gerät nutzen - ich möchte jedoch, dass jedes Gerät, welches mit meinem Netzwerk verbunden ist Pi-Hole als DNS-Server verwendet.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Geht dazu in die Oberfläche eurer Fritzbox und wechselt in den Punkt Heimnetz. Dort findet ihr unter dem Reiter Netzwerkeinstellungen den Bereich IP-Adressen. Abhängig davon, ob ihr IPv4 und/oder IPv6 nutzt, müssen die folgenden Schritte pro Protokoll durchgeführt werden - was beispielsweise bei mir durch Dual Stack notwendig ist.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Im nächsten Dialog könnt ihr nun den DNS-Server hinterlegen. Tragt hier je nach Protokoll die IPv4 oder IPv6-Adresse eurer Installation ein. Diese hat euch der Konfigurations-Assistent am Ende auch mitgeteilt.

Anschließend speichern, ggf. einmal eure Endgeräte neustarten bzw. den DHCP-Lease erneuern. Fertig.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Ich verstehe, dass es Websiten gibt, die sich über Werbung finanzieren. Das ist in meinen Augen auch vollkommen in Ordnung.
Nicht in Ordnung ist es in meinen Augen jedoch, wenn entweder die Werbung überhand vor dem eigentlichen Inhalt nimmt oder aber, wenn ein Gerät, welches ich gekauft habe, mir auf einmal Werbung um die Ohren haut. Als ein Beispiel sei hier einmal mein TV von Samsung genannt.

Das erste Problem kann man mittels Werbeblockern mittlerweile ziemlich gut in den Griff bekommen. Ich selbst bin ein großer Fan von Ublock Origin. Aber zum einen mag ich möglichst wenige Extensions in meinem Browser nutzen, zum anderen löst es nicht das Problem mit den Werbe-Apps auf meinem TV.

Ich nutze nun seit einigen Monaten Pi-Hole. Pi-Hole ist ein DNS-Server, der im lokalen Netzwerk aufgesetzt wird. Ob auf einem Raspberry Pi, der sich dafür anbietet, oder jedem anderen Server ist vollkommen egal. Für die gängigsten Linux-Distributionen gibt es fertige Binaries.

Hardware

Pi-hole is very lightweight as it only handles DNS queries and returns a blank HTML file so it doesn’t need much processing power.

~52MB of free space
512 MB RAM

We officially support the following:

Raspbian: Jessie (Only up to Pi-hole v3.2.1 1.1k) / Stretch (lite / with pixel)
Ubuntu: 16.04 / 16.10
Debian: 8 / 9
Fedora 26
CentOS: 7 (not ARM)

Anders als ein Werbeblocker im Browser, der die entsprechenden Javascript-Dateien auf der Website blockiert, blockiert Pi-Hole auf DNS-Ebene, was bedeutet, dass die Auflösung der URls der Werbenetzwerke bereits beim Versuch des Verbindungsaufbaus verhindert wird. Ein Werbeblocker im Browser ist damit quasi obsolet - kann aber trotzdem nicht schaden, sofern Pi-Hole mal etwas entgehen sollte.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Ich selbst nutze Pi-Hole auf einem Raspberry Pi der ersten Generation mit 512 MB Ram, der damit noch wunderbar klar kommt. Die Installation ist ziemlich simpel. Voraussetzung ist ein bereits eingerichter Raspberry, idealerweise erreichbar über SSH.

Mittels curl -sSL https://install.pi-hole.net | bash wird automatisch der Installer heruntergladen und gestartet. Pi-Hole selbst führt euch mittels Assistenten durch die Konfiguration.
Neben der Netzwerkkonfiguration, den Nameservern, die zur Abfrage genutzt werden, könnt ihr hier auch IPV6-Support aktivieren.

Anschließend ist das Webportal von Pi-Hole unter http://IP-eures-PIs/admin erreichbar. Über dieses lassen sich nicht nur Statistiken anzeigen, ihr könnt Pi-Hole bei Problemen auch testweise deaktivieren oder Einstellungen bezüglich verwendeten der DNS-Server vornehmen. Auch DNSSEC support kann auf Wunsch aktiviert werden.

Damit eure Endgeräte in eurem Netzwerk nun aber auch eure Pi-Hole-Installation nutzen, ist es notwendig den DNS-Server in eurem Router, in meinem Falle einer Fritzbox anzupassen - natürlich könnte man das auch manuell je Gerät nutzen - ich möchte jedoch, dass jedes Gerät, welches mit meinem Netzwerk verbunden ist Pi-Hole als DNS-Server verwendet.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Geht dazu in die Oberfläche eurer Fritzbox und wechselt in den Punkt Heimnetz. Dort findet ihr unter dem Reiter Netzwerkeinstellungen den Bereich IP-Adressen. Abhängig davon, ob ihr IPv4 und/oder IPv6 nutzt, müssen die folgenden Schritte pro Protokoll durchgeführt werden - was beispielsweise bei mir durch Dual Stack notwendig ist.

Pi-Hole - Der Werbeblocker für das gesamte Netzwerk

Im nächsten Dialog könnt ihr nun den DNS-Server hinterlegen. Tragt hier je nach Protokoll die IPv4 oder IPv6-Adresse eurer Installation ein. Diese hat euch der Konfigurations-Assistent am Ende auch mitgeteilt.

Anschließend speichern, ggf. einmal eure Endgeräte neustarten bzw. den DHCP-Lease erneuern. Fertig.

Ich verstehe, dass es Websiten gibt, die sich über Werbung finanzieren. Das ist in meinen Augen auch vollkommen in Ordnung.
Nicht in Ordnung ist es in meinen Augen jedoch, wenn entweder die Werbung überhand vor dem eigentlichen Inhalt nimmt oder aber, wenn ein Gerät, welches ich gekauft habe, mir auf einmal Werbung um die Ohren haut. Als ein Beispiel sei hier einmal mein TV von Samsung genannt.

Das erste Problem kann man mittels Werbeblockern mittlerweile ziemlich gut in den Griff bekommen. Ich selbst bin ein großer Fan von Ublock Origin. Aber zum einen mag ich möglichst wenige Extensions in meinem Browser nutzen, zum anderen löst es nicht das Problem mit den Werbe-Apps auf meinem TV.

Ich nutze nun seit einigen Monaten Pi-Hole. Pi-Hole ist ein DNS-Server, der im lokalen Netzwerk aufgesetzt wird. Ob auf einem Raspberry Pi, der sich dafür anbietet, oder jedem anderen Server ist vollkommen egal. Für die gängigsten Linux-Distributionen gibt es fertige Binaries.

Hardware

Pi-hole is very lightweight as it only handles DNS queries and returns a blank HTML file so it doesn’t need much processing power.

~52MB of free space512 MB RAM

We officially support the following:

Raspbian: Jessie (Only up to Pi-hole v3.2.1 1.1k) / Stretch (lite / with pixel)Ubuntu: 16.04 / 16.10Debian: 8 / 9Fedora 26CentOS: 7 (not ARM)

Anders als ein Werbeblocker im Browser, der die entsprechenden Javascript-Dateien auf der Website blockiert, blockiert Pi-Hole auf DNS-Ebene, was bedeutet, dass die Auflösung der URls der Werbenetzwerke bereits beim Versuch des Verbindungsaufbaus verhindert wird. Ein Werbeblocker im Browser ist damit quasi obsolet – kann aber trotzdem nicht schaden, sofern Pi-Hole mal etwas entgehen sollte.

alt

Ich selbst nutze Pi-Hole auf einem Raspberry Pi der ersten Generation mit 512 MB Ram, der damit noch wunderbar klar kommt. Die Installation ist ziemlich simpel. Voraussetzung ist ein bereits eingerichter Raspberry, idealerweise erreichbar über SSH.

Mittels curl -sSL https://install.pi-hole.net | bash wird automatisch der Installer heruntergladen und gestartet. Pi-Hole selbst führt euch mittels Assistenten durch die Konfiguration.
Neben der Netzwerkkonfiguration, den Nameservern, die zur Abfrage genutzt werden, könnt ihr hier auch IPV6-Support aktivieren.

Anschließend ist das Webportal von Pi-Hole unter http://IP-eures-PIs/admin erreichbar. Über dieses lassen sich nicht nur Statistiken anzeigen, ihr könnt Pi-Hole bei Problemen auch testweise deaktivieren oder Einstellungen bezüglich verwendeten der DNS-Server vornehmen. Auch DNSSEC support kann auf Wunsch aktiviert werden.

Damit eure Endgeräte in eurem Netzwerk nun aber auch eure Pi-Hole-Installation nutzen, ist es notwendig den DNS-Server in eurem Router, in meinem Falle einer Fritzbox anzupassen – natürlich könnte man das auch manuell je Gerät nutzen – ich möchte jedoch, dass jedes Gerät, welches mit meinem Netzwerk verbunden ist Pi-Hole als DNS-Server verwendet.

alt

Geht dazu in die Oberfläche eurer Fritzbox und wechselt in den Punkt Heimnetz. Dort findet ihr unter dem Reiter Netzwerkeinstellungen den Bereich IP-Adressen. Abhängig davon, ob ihr IPv4 und/oder IPv6 nutzt, müssen die folgenden Schritte pro Protokoll durchgeführt werden – was beispielsweise bei mir durch Dual Stack notwendig ist.

alt

Im nächsten Dialog könnt ihr nun den DNS-Server hinterlegen. Tragt hier je nach Protokoll die IPv4 oder IPv6-Adresse eurer Installation ein. Diese hat euch der Konfigurations-Assistent am Ende auch mitgeteilt.

Anschließend speichern, ggf. einmal eure Endgeräte neustarten bzw. den DHCP-Lease erneuern. Fertig.