pixel
Seite wählen

NETWAYS Blog

Pi-Hole – das Urgestein der DNS-basierten Werbeblocker

Im Rahmen meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services arbeite ich regelmäßig an neuen Projekte. Dabei steht neben dem Kennenlernen neuer Technik und Software besonders die Vertiefung von Schulungsinhalten im Fokus.
Im Rahmen des Projekts zur DNS-Schulung (Domain Name System) habe ich den DNS-basierten Werbeblocker Pi-Hole aufgesetzt und konfiguriert. Pi-Hole ist seit vielen Jahren die bekannteste und am weitesten verbreitete Anwendung für ein netzwerkweites Ad-Blocking. Das liegt besonders an den individuellen Konfigurationsmöglichkeiten, welche die Software anbietet sowie an der unkomplizierten Installation.

Warum ist ein DNS-Werbeblocker sinnvoll?

Viele Dienste und Websites im Internet bieten ihre Dienste für Endkunden kostenlos an. Da sich mit kostenlosen Inhalten in der Regel aber kein Geld verdienen lässt, sind Werbeanzeigen in den letzten zehn Jahren für viele Unternehmen eine, teilweise gar die wichtigste Einnahmequelle geworden.
Während der Einsatz von Werbung aus unternehmerischer Sicht sinnvoll und nachvollziehbar sind, können für die Nutzer:innen der Website / des Dienstes Probleme durch diese Werbeeinblendungen auftreten.

Teilweise sorgen Anzeigen „nur“ dafür, dass Websites nicht richtig funktionieren oder sie die Ästhetik stören. Es gab jedoch schon Fälle, in denen Werbeanzeigen zum Verteilen von schädlichem Code genutzt wurden. Um das eigene Netzwerk werbefrei zu halten, gibt es verschiedene Möglichkeiten. Die bekanntesten sind Pi-Hole und AdGuard Home.
Dank dieser Programme kann das Auspielen von Werbung auf allen mit dem Netzwerk verbundenen Geräten verhindert werden. Dieser Text beschäftigt sich mit der Einrichtung und Konfiguration von Pi-Hole, während unser Blogartikel von letzter Woche AdGuard Home genauer unter die Lupe nimmt.

Was ist Pi-Hole?

Pi-Hole ist eine Open-Source-Software, die als Werbe- und Trackingblocker fungiert. Welche Inhalte dabei für welches Gerät im lokalen Netzwerk geblockt werden, lässt sich individuell konfigurieren. Die Anwendung basiert auf Linux und ist dafür optimiert, um auf Computern mit minimaler Ausstattung, etwa dem Raspberry Pi, zu funktionieren.

Damit die Blockfunktion von Pi-Hole wie gewünscht funktioniert, fungiert das Programm als DNS-Server für das eigene Netzwerk, über den der komplette Netzwerkverkehr sowohl ausgehend als auch eingehend geleitet wird. Mithilfe dieser Schnittstellenfunktion bekommt Pi-Hole Zugriff auf alle eingehenden IP-Adressen, die mit dem Abruf einer Homepage oder eines Dienstes verbunden sind.
Diese Funktion sorgt dafür, dass Filter angewendet werden können, die Werbe- und Tracking-IP’s herausfiltern und z. B. die Website in einer werbefreien Form anzeigen. Die Werbung wird also verhindert, bevor das Endgerät überhaupt die Chance hat, den entsprechenden Inhalt zu laden.

Die angesprochenen Filter werden in Form von Filterlisten implementiert, die verschiedene Ziele erfüllen können. Neben dem bekannten Werbe- und Trackingblocker kann auch der Zugriff auf spezielle Seiten, etwa mit Inhalten der Erwachsenenunterhaltung oder soziale Netzwerke, eingeschränkt oder komplett verhindert werden. Sollten aufgrund einer oder mehrerer angewendeter Blocklisten Seiten gesperrt werden, auf die eigentlich zugegriffen werden soll, besteht die Möglichkeit, diese über eine Whitelist explizit für die gewünschten Clients freizugeben.

Technische Voraussetzungen

Um ein eigenes funktionierendes Pi-Hole zu installieren, sind nicht viele Komponenten nötig. Die technischen Voraussetzungen sind:

  • Ein Raspberry Pi mit Raspberry Pi OS+ Zubehör & Netzteil
  • Eine MicroSD-Karte (mindestens 8GB Speicherkapazität)
  • Ethernet- oder WiFi-Verbindung (bei Raspis mit WLAN-Modul) zum Router des lokalen Netzwerks, damit Pi-Hole als DNS-Server fungieren kann
  • Zugang zur Command Line Interface (CLI) des Pi

Die Einrichtung des Raspberry Pi vor der Installation von Pi-Hole ist simpel und unkompliziert. Es gibt ausreichend Guides, die diese Arbeit Schritt-für-Schritt erklären.

Installation von Pi-Hole

-HINWEIS-
Nach der Installation von Pi-Hole kann der Raspberry Pi problemlos ohne Peripheriegeräte betrieben werden. Für den Zugriff auf die Weboberfläche der Anwendung ist jedoch die statische IP-Adresse des Pi nötig, welche über das Terminal des Betriebssystems ausgelesen werden kann. Aus diesem Grund ist es sinnvoll, dass für die Dauer der Installation des Betriebssystems und des Werbeblockers Monitor und Tastatur angeschlossen sind.

Die Pi-Hole Installation ist unkompliziert und wird von einem ausführlichen Installationsassistenten begleitet, der jeden Schritt mit einer kurzen Erklärung begleitet. Um das Installationsskript zu starten, muss zunächst das Pi-Hole git-Repository geklont werden, in der das Skript enthalten ist. Anschließend wird das Skript ausgeführt. Die entsprechenden Befehle dafür sind:

git clone --depth 1 https://github.com/pi-hole/pi-hole.git Pi-hole
cd "Pi-hole/automated install/"
sudo bash basic-install.sh

Der automatisierte Pi-Hole Installer konfiguriert die Punkte:

  • Statische IP-Adresse
  • Auswahl des von Pi-Hole verwendeten Upstream DNS-Providers
  • Einfügen einer ersten, von den Pi-Hole-Entwickler:innen kuratierten Blockliste
  • Installation des Webinterface (kann ausgeschalten werden, wenn die Konfiguration komplett über SSH und CLI gemacht werden will)
  • Installation des Webservers lightttpd (Ist für die Anzeige des Webinterface unerlässlich)
  • Privacy level und loggen von Anfragen

Nachdem der Installer seine Arbeit getan hat, ist die Weboberfläche erreichbar und Pi-Hole ohne weitere Einstellungen direkt einsetzbar.

Individuelle Konfiguration von Pi-Hole …

Mit der vom Installer vorgegebenen Grundkonfiguration ist der Einsatz des Werbe- und Trackingblocker Pi-Hole ohne weitere Einstellungen möglich. Es wäre jedoch kein anständiges Linux- bzw. Open Source-Projekt, wenn es nicht vielfältige Konfigurationsmöglichkeiten geben würde, um Pi-Hole an die eigene Umgebung und die persönlichen Präferenzen anzupassen.

Zugriff auf die verschiedenen Konfigurationsmöglichkeiten bekommt man über das Dashboard, welches im Browser über http://IP-Adresse-des-Pi/admin (z. B. 192.168.112.23/admin o. Ä.) aufgerufen werden kann. Nachfolgend werde ich einige wichtige Einstellungen vorstellen.

… als DNS-Server

Wie bereits angesprochen, agiert Pi-Hole im lokalen Netzwerk als DNS-Server. Damit das funktioniert, muss im Menü unter Settings -> DNS ein Upstream DNS Server ausgewählt werden, mit dem der Pi kommunizieren kann. Zur Auswahl stehen einige vorkonfigurierte Möglichkeiten (u.A. Google, OpenDNS oder Quad9). Zudem können bis zu vier weitere DNS-Server hinzugefügt werden, indem die entsprechende IP-Adresse eingetragen wird. Somit haben Nutzer die volle Kontrolle über den genutzten Upstream DNS und können z. B. datenschutzfreundliche DNS-Anbieter verwenden.

… und Benutzer- / Gruppenmanagement

Die individuelle Konfigurierbarkeit ist einer der Gründe, warum sich Pi-Hole seit Jahren großer Beliebtheit erfreut. Dazu gehört besonders das Benutzer- und Gruppenmanagement.
Du möchtest verschiedene Gruppen anlegen, um für einen oder mehrere Client(s) Content zu sperren, für die anderen aber nicht? Kein Problem!
Du willst einen Client mehreren Gruppen hinzufügen? Kein Problem!
Um individuelle Gruppen anzulegen, muss einfach Group Management -> Groups aufgerufen werden. Die Client-Verwaltung wiederum befindet sich im gleichen Menü jedoch unter dem Unterpunkt Clients.

… und Adlists

Bei der Grundkonfiguration über den Pi-Hole-Installer wird eine kuratierte Adlist mitgeliefert, dass Pi-Hole direkt einsatzbereit ist. Bei dieser einen Liste muss es aber nicht bleiben. Egal was geblockt werden soll, es gibt die passende Liste dafür. Die folgenden drei Links bieten eine vielfältige Auswahl an regelmäßig aktualisierten Blocklisten:

Eingefügt werden die gewünschten Listen über Group Management -> Adlists. Hier lassen sich alle Listen zentral verwalten (z. B. Kommentare zu einzelnen Listen, Zuweisung zu Nutzergruppen, u.v.m.).

Es existieren noch viele weitere Einstellungsmöglichkeiten wie DHCP, Domainmanagement oder Whitelists, aber diese vorzustellen würde den Rahmen sprengen. Deshalb nun noch ein Punkt, der nicht unerwähnt bleiben sollte.

Grenzen von Pi-Hole

Wer bis hierhin gelesen hat, kann den Eindruck bekommen, dass Pi-Hole eine großartige Möglichkeit ist, um Werbung und Tracking aus dem eigenen Netzwerk zu verbannen. Und das ist auch zu 95 Prozent richtig. Doch Ehrlichkeit muss sein: NICHT JEDE WERBUNG lässt sich blockieren.

Wenn sich der abgerufene Inhalt und die Werbung den Server und die IP-Adresse teilen, führt ein Blockieren der Werbung zu einem Blockieren des Inhalts. Das bekannteste Beispiel für dieses Vorgehen ist YouTube, dass damit DNS-Werbeblockern wie Pi-Hole oder AdGuard Home zuvorkommen will. Um diese Inhalte abzurufen, muss man in den meisten Fällen ein wenig Werbung in Kauf nehmen.
Besonders für Nutzer von Smart-TVs oder TV-Sticks ist das eine bedauerliche Nachricht. (Während es auch hier Optionen gibt, hust SmartTube hust).

Wenn du nun auch Lust auf abwechslungsreiche Projekte in einem modernen IT-Unternehmen im wunderschönen Nürnberg hast und aktuell noch einen spannenden Ausbildungsplatz suchst, dann solltest du noch heute deine Bewerbung an NETWAYS schicken.

Marc Rupprecht
Marc Rupprecht
Junior Consultant

Nach seinem Bachelorabschluss im Fach Technikjournalismus und zweieinhalb Jahren als Online-Redakteur hat Marc sich entschieden, die Medienwelt hinter sich zu lassen und den Wechsel in die IT vollzogen. Als Auszubildender zum Fachinformatiker für Systemintegration verstärkt er nun seit September 2021 das Team der NETWAYS Professional Services. In seiner Freizeit ist er seit vielen Jahren begeisterter Volleyballspieler und hat vor Kurzem das Scuba Diving für sich entdeckt. Ansonsten versucht er regelmäßig neue Länder auf seiner Weltkarte frei zu rubbeln und verbringt gerne auch den einen oder anderen Abend beim Zocken am PC.

AdGuard Home als Werbeblocker – ein ernstzunehmender Pi-Hole-Konkurrent?

Raspberry Pi – bei vielen Leuten klingelt ganz dumpf etwas. Bei einigen anderen wird die Fantasie durch eine schier unendliche Zahl an Anwendungsmöglichkeiten beflügelt.
Technikaffinen Personen ist der Pi nicht unbekannt und gerne nutzen sie diesen für diverse Projekte.
Doch auch Du – ob nun technisch versiert oder nicht – kannst von diesem Gerät profitieren.

Denn was mindestens 101% der Menschen sauer aufstößt ist Werbung im Internet. Mit einem Rapsberry Pi und der Open Source Software AdGuard Home (AGH) lässt sich sehr viel Werbung blockieren.
Speziell Werbebanner am Bildschirmrand wie sie oftmals auf diversen Nachrichtenportalen zu sehen sind können mit AGH der Vergangenheit angehören.

 

Werbung blockieren, bevor sie entsteht

Herkömmliche Werbeblocker in Form von Browsererweiterungen blockieren Werbung, nachdem sie im Browser geladen wurde. Mit einem DNS-basierten Werbeblocker, wie AdGuard Home es ist, kannst Du Werbung jedoch blockieren, noch bevor sie geladen wird.

Hier wird nämlich nicht die Werbung selbst blockiert, sondern die Anfrage an den Server, der die Werbung bereitstellt. Wenn Dein Endgerät also Werbung laden würde, schreitet AGH ein und teilt mit, der entsprechende Server sei nicht erreichbar.

Und schon musst Du keine nervigen Werbebanner mehr sehen.

 

Warum ein DNS-basierter Werbeblocker?

Diese Art von Werbeblockern ist deshalb interessant, weil sie für das gesamte Heimnetzwerk verwendet werden kann. Selbst Geräte, auf denen kein Werbeblocker installiert werden kann, können davon profitieren.
Hier sind vornehmlich Smart TVs zu erwähnen.

Außerdem bekommst Du hier eine zentrale Stelle, um Deine Einstellungen vorzunehmen, und ersparst Dir ggf. die Einrichtung mehrerer Einzelgeräte. Entsprechende Sperrlisten für DNS-basierte Werbeblocker gibt es im Internet zudem wie Sand am Meer.

 

Was Du brauchst

Um Strom zu sparen, empfiehlt es sich, einen Raspberry Pi für dieses Projekt zu nutzen. Es wird gar nicht viel Leistung benötigt.
Ein Raspberry Pi ist auch recht einfach einzurichten.

Für dieses Projekt benötigst Du also Folgendes:

  • Einen Raspberry Pi mit WLAN und/oder LAN + Zubehör/Netzteil
  • Eine microSD-Karte mit installierten Betriebssystem (Empfehlung: Raspberry Pi OS)
  • Zugang zum Command Line Interface (CLI) des Pi
  • Internetzugang für den Raspberry Pi

Sobald Du Deinen Pi eingerichtet und Bildschirm und Tastatur angeschlossen hast, kannst Du auf dem Pi ein Terminal öffnen.

Alternativ kannst Du Dich – sofern eingerichtet – auch mittels SSH auf den Pi aufschalten, z.B. mit PuTTY.

 

AdGuard Home Installation

Für die Installation von AdGuard Home musst Du auf der GitHub-Seite des Projekts die Veröffentlichung, die zur Architektur Deines Geräts passt, wählen.

Dieses Setup wurde mit einem Raspberry Pi 3 B+ getestet.
Bei diesem Modell wählst Du z.B. „AdGuardHome_linux_armv7.tar.gz“.

Kopiere Dir den Link und lade das Archiv auf Deinen Raspberry Pi mit folgendem Befehl herunter:

wget https://github.com/AdguardTeam/AdGuardHome/releases/download/v0.107.7/AdGuardHome_linux_armv7.tar.gz

Anschließend entpackst Du das Archiv und verschiebst die Dateien von AdGuard Home an die passende Stelle.

tar -xf AdGuardHome_linux_amd64.tar.gz
sudo mv AdGuardHome/ /opt/

Jetzt musst Du AdGuard Home nur noch installieren.

sudo /opt/AdGuardHome/AdGuardHome -s install

Damit hast Du den schwierigsten Teil geschafft!

 

In wenigen Schritten zum Ziel

AdGuard Home läuft bereits und will eingerichtet werden. Hierfür rufst Du in einem Browser die IP-Adresse Deines Raspberry Pi auf und gibst die Portnummer „3000“ an.
Beispiel: „192.168.123.10:3000“

Wenn alles funktioniert hat, siehst Du jetzt den Einrichtungsassistenten.

In zwei einfachen Schritten kannst Du nun AGH einrichten.
Zunächst wirst Du gefragt, über welche Adressen die Weboberfläche erreichbar sein soll. Die Auswahl „Alle Schnittstellen“ und „Port 80“ kannst Du so übernehmen.

Die andere Frage nach der DNS-Schnittstelle kannst Du ebenfalls mit „Alle Schnittstellen“ und „Port 53“ beantworten.
Damit ist Dein AGH sicher erreichbar und beantwortet auch DNS-Anfragen.

Im zweiten Schritt kannst Du noch ein Benutzernamen und ein Passwort wählen. An dieser Stelle solltest Du direkt ein gutes Passwort wählen, da es sich (aktuell) nur über Umwege wieder ändern lässt.

AGH zeigt Dir außerdem im Anschluss an, wie Du AdGuard Home auf Deinen Endgeräten als DNS-Server auswählst.

Sobald Du AGH über die Weboberfläche erreichen kannst, bist Du im Prinzip fertig.
Standardmäßig blockiert AGH bereits ca. 46.000 Domains. Weitere Sperrlisten kannst Du bequem über den „Filter-Reiter“ hinzufügen. Dort sind einige vorgefertigte Listen hinterlegt.

AGH verwendet außerdem DNS-over-HTTPS (DoH).
Kurz gesagt: Deine DNS-Anfragen werden verschlüsselt an DNS-Server außerhalb deines Netzwerks übertragen.
Dein Internetanbieter beispielsweise kann so nicht mehr direkt sehen, welche Domains Du aufrufst. Ein bisschen Privatsphäre muss schließlich sein.

An dieser Stelle ist eigentlich keine weitere Konfiguration mehr nötig.
Aber wenn Du in den Genuss der Features kommen willst, die AdGuard Home besonders machen, solltest Du Dich noch ein wenig umsehen.

 

Zusatzoptionen

Interessant wird es bereits im Bereich „Allgemeine Einstellungen„.
Du möchtest Seiten blockieren, die für Viren bekannt sind?
Du kannst einen Haken setzen.

Du möchtest explizite Inhalte der Erwachsenenunterhaltung blockieren?
Setze den Haken.

Du möchtest bei der Googlesuche keine anstößigen Inhalte sehen?
Haken.

AdGuard Home macht es Dir wirklich kinderleicht.

Die genannten Einstellungen kannst Du allgemein aktivieren oder nur für bestimmte Geräte in Deinem Netzwerk. Dafür musst Du lediglich Deine jeweiligen Endgeräte als „Client“ in den „Client-Einstellungen“ eintragen.
Etwas technisches Verständnis oder ein guter Umgang mit Google sind hier hilfreich.
Anschließend können die Regeln für den Client separat gesetzt werden.

Client-Einstellungen werden vor allem dann spannend, wenn Du Dein Heimnetzwerk selbst tiefgreifender einrichten und steuern möchtest. Der Aspekt Kinderschutz ist dabei besonders interessant und mit dieser Lösung sehr leicht umzusetzen.

AdGuard Home ermöglicht es Dir außerdem, auf sehr bequeme Weise ganze Dienste zu blockieren. Aktuell können Domains von 35 verschiedenen Diensten einfach per Mausklick blockiert werden.
Populäre Vertreter sind hier Twitter, WhatsApp, YouTube, Facebook, Netflix und Amazon.

Gesperrte Dienste

Wenn Du Interesse daran hast, kannst Du AGH sogar als DHCP-Server nutzen. Nur Frühstück musst Du Dir noch selbst machen.

 

Gekommen, um zu bleiben

Wie Du siehst bietet AdGuard Home das meiste, was man sich von einem DNS-basierten Werbeblocker wünscht. AGH ist leicht zu konfigurieren und hat eine sehr übersichtliche und intuitive Weboberfläche.
Dazu kommt, dass AGH selbst für Laien leicht zu installieren ist. Alles, was es braucht, ist der Wille und die Fähigkeit, ein paar Anleitungen aus dem Internet zu folgen.

Dass AdGuard Home erst in der Version „0.107“ zu haben ist – es gibt also offiziell noch keine richtige erste Version – schmälert den Nutzen nicht.
Es deutet vielmehr darauf hin, dass wir in Zukunft noch viel Gutes von diesem Projekt erwarten können.

Aber Ehrlichkeit muss sein: Du wirst nicht jede Werbung blockieren können. Denn oftmals teilen sich Inhalte und Werbung denselben Server. Diesen Server zu blockieren, führt entsprechend dazu, dass Du auch keine Inhalte mehr abrufen kannst.
YouTube ist ein klassisches Beispiel, bei dem Du mit DNS-basierten Werbeblockern nicht weit kommen wirst. Aber viel Werbung zu blockieren, ist immer noch besser als keine Werbung zu blockieren. Und schließlich sind Browsererweiterungen nach wie vor eine gute Ergänzung.

Ob Du nun ein neugieriger Anfänger oder ein Technikprofi bist, AdGuard Home ist eine ernstzunehmende Lösung für 101% der Bevölkerung. AGH ist Dein Interesse definitiv wert!
Wenn Du aber lieber auf lang bewährte Lösungen zurückgreifen möchtest, sei Dir Pi-Hole wärmstens an’s Herz gelegt.

Matthias Döhler
Matthias Döhler
Junior Consultant

Über ein paar Umwege ist Matthias nun endlich da gelandet, wo er sich wohl fühlt: in der IT! Bei NETWAYS hat er im September 2021 seine Ausbildung zum Fachinformatiker für Systemintegration im Bereich Professional Services begonnen. Wenn er sich zu Hause nicht auch noch mit Themen rund um Linux auseinandersetzt, sieht er sich leidenschaftlich gerne Horrorfilme und solche an, die man als "Trash" bezeichnen könnte. Je seltsamer, desto besser! Den üblichen Beschäftigungen wie Freunde treffen, Bars aufsuchen oder die Sonne im Freien genießen, geht er eben so nach wie pseudophilosophischen Fragen. Daneben spielt er außerdem wahnsinnig gerne Videospiele vergangener Generationen....

Lust auf mehr Privacy? DIY Wireguard mit DNSCrypt & Quad9

Privacy & Warum Wireguard?

Mein Ziel in diesem Artikel ist es, dir zu zeigen, wie man einen eigenen Wireguard Server aufsetzt. Warum nicht einfach eine fertige VPN-Lösung einkaufen? Weil du ansonsten nie wirklich weißt, was mit deinen Logs & Daten passiert und diese zu gerne zu Analysezwecken weiterverwendet und verkauft werden.

Grade im Hinblick auf Werbe-/User-Tracking, ist es relativ schwer, browserseitig Internet-Privacy in 2021 zu erreichen (wie man auf Seiten wie AmIUnique sehen kann). Ein VPN wird einen individuellen Browser-Fingerprint nicht wirklich entfernen. Schaltet man aber noch ein Squid zum VPN der Wahl hinzu, mit http_anonymizer standard oder http_anonymizer paranoid, könnte man kleinere Erfolge erzielen! Zum Thema Browser-Fingerprinting erzähle ich vielleicht in Zukunft mal mehr.

Auf andere Protokolle bezogen, macht ein VPN aus Privacysicht aber dennoch Sinn, um z.B. Vorteile durch spezielle Services, die ländergebunden sind, zu erreichen und / oder um ein besseres Routing zu gewinnen. Da z.B. eine Suchanfrage via Google schön zeigt (ganz unten im Browser), wie nahe man via IP ohne extra Geo-tracking den Standort bestimmen kann, macht ein VPN mit integriertem DNS aber doch Sinn. Auch, um all seine Geräte gegen fremde Router & IP & DNS basierte Netzwerkangriffe zu schützen.

Warum Wireguard als VPN?

  • Leistung: OpenVPN ist recheninvensiver und benötigt praktisch AES Beschleunigung auf CPU-Form. Das bedeutet, dass ein Router, der zumeist ein ARM-Board hat (ohne AES Chip), niemals die selbe Leistung erreichen wird (MBit Download/Upload – technisch) wie es mit Wireguard der Fall wäre. Dies sollte man auch skaliert mit mehreren Servern / Clients betrachten.
    Wireguard selbst läuft mittlerweile auch als Linux-Kernel-Modul. Dies bringt natürlich Performanz-Vorteile mit sich. Zugleich gibt es mittlerweile direkten Support für OpenWRT Router (ohne dedizierte AES Chips) auf Kernel-Level (!), sowie neuerdings auch in OPNSense im Userland, und ab FreeBSD 13 auch im Kernelland.
  • Batterie: Selbiges gilt für Smartphones & Laptops, die natürlich mitrechnen müssen. Via OpenVPN werden deine Geräte mehr Rechenleistung aufwenden müssen, und praktisch schneller an Batterie verlieren.
  • Sicherheit: Wireguard hat mehrere Krypto-Runden. Dazu kommt, dass man manuell, individuellen Clients Zugriff genehmigen muss / darf, via assymetrischer Kryptographie & IP sowie symmetrischer Kryptographie falls gewünscht.
  • Codebase: Der Code ist sehr viel kompakter (< 4000 Zeilen Code), was ihn fehlerfreier sein lassen könnte. Als Faustregel kann man sagen: ~ 1 Fehler pro 1000 Zeilen Code. (Stichwort OpenBSD)

Guide

Meinen Wireguard-Guide findest du hier im Github. Er ist die Schnittmenge aus mehreren anderen Guides und eigenen Experimenten.

Im Prinzip ist alles, was du dann noch machen musst, dir ein Redhat 8 (gibt es umsonst bis zu 16 Lizenzen für den Privatgebrauch) oder CentOs 8 – VPS zu holen, welche es teilweise schon ab 5 -10 € pro Monat gibt. Warum nicht Debian oder Ubuntu? Weil ich SELinux persönlich mächtiger finde, und dieser Guide komplett unter Enforcing-Policies läuft.

Weitere Tweaks

  • SSH nur per Wireguard zulassen / Fail2 Ban installieren
  • Automatische Updates via DNF-Automatic anschalten
  • Überlegen, ob du vielleicht den Wireguard Server nur als diesen laufen lassen solltest. Einerseits um sauberes Enforcing / Targeted SE-Linux beizubehalten -> ohne viele extra Services <- andererseits um gefährlichere Services (Mail / Web) auf einen anderen Server auszulagern
  • Je nach Situation Client-Isolation anschalten
  • In Clients Kill-Switches setzen

Hinweise

  • Mir fiel auf, dass unter DNSCrypt-Proxy anfänglich Cloudflare DNS-Leaks provoziert hat (falsche Routes?), während Quad9 das per Default nicht getan hat. -> Ob das reproduzierbar ist oder an meinem Setup liegt, kannst du mir gerne in den Kommentaren sagen.
  • Mir ist außerdem aufgefallen, dass Hibernate unter manchen Linux-Distros, nach dem Hibernate, DNS-Leaks hervorruft. Hier sind die DNS-Adresse des Netzwerk-Interfaces, /etc/systemd/resolved.conf & /etc/dhcp/dhclient.conf (prepend domain-name-servers) drei Anlaufstellen, welche man dann am besten mit der neuen DNS des Wireguard-Servers versieht.
  • Mein VPS unterstützt leider kein IPv6, ich habe aber die Settings mal für dich im Github angelassen. Testen kann ich es nicht, aber die Konfiguration läuft genau so auch unter IPv4, falls dein VPS änlich ist.
  • Scheinbar leiden selbst DoH & DoT unter dem Problem, dass die initialen Client-Hello-Messages vor dem TLS Handshake sichtbar sind (Stichwort ESNI, dies muss also Serverseitig nachgerüstet werden). Das bedeutet konkret, dass ein VPN Server wirklich immer Sinn macht, da man dann im Notfall auf ihn zurückfällt, ohne die eigene IP zu leaken. Adguard liefert mit DNS-over-QUIC einen anderen interessanten Ansatz und begräbt TLS, was man im DNSCRYPT einstellen könnte.

 

Unser NETWAYS Github ist eine super Anlaufstelle, falls du Lust auf noch mehr Open Source hast.

Patrick Dolinic
Patrick Dolinic
Junior Consultant

Nachdem Patrick sein Psychologiestudium abgeschlossen hat, ist er 2020 zu NETWAYS, wo er nun sein Hobby zum Beruf macht: Endlich kann er sich voll und ganz der Linux-Welt widmen und sein Faible für Computersicherheit ausleben. Wenn er nicht gerade arbeitet, arbeitet oder zockt er. Nebenbei versucht er beim Joggen 8 km zu reißen, schafft aktuell aber nicht mal die ersten 7.

Netzwerkprobleme im Homeoffice erkennen

In den letzten Monaten gab es zwischenzeitlich wegen allgemein erhöhtem Datenvolumen im Internet ja immer wieder ein mal Probleme mit diversen Providern bezüglich langsamer oder nur sporadisch oder tagelang nicht richtig funktionierender Internet Verbindungen.

Gerade die zunehmende Verbreitung von Videokonferenzen in Unternehmen durch Homeoffice und parallel ein immenser Zuwachs der Kunden von Streaming Plattformen hat dazu sicher massgeblich beigetragen.

Nun ist es auf den ersten Blick auch nicht immer so einfach zu erkennen, welche Ursachen z.B. Probleme bei einer Videokonferenz haben können.

Wenn alle anderen Dienste wie E-Mail, normale Webseiten, oder auch das Arbeiten auf der Kommandozeile trotzdem irgendwie funktionieren, denkt man nicht immer gleich daran, dass es trotzdem ein Problem im lokalen Netzwerk oder auf der Strecke zum entsprechenden Server geben könnte.

Zunächst ist es natürlich sinnvoll erst ein mal zu schauen, ob man nicht grundsätzliche Probleme im lokalen Netzwerk hat, z.B. bei Mehrfamilien Häusern oder Wohnblöcken ein überlastetes 2,4 GHz WLAN.
Dabei ist es sehr hilfreich, wenn man entsprechende Tools für sein Betriebssystem nutzt, die die Auslastung und die Verbindungsqualität der aktuellen WLAN Verbindung anzeigen können.
(Beispiel siehe unten)

Falls dort alles o.k. ist, es aber trotzdem noch Probleme gibt, helfen altbekannte Tools, die es auch für alle gängigen Betriebssysteme gibt, bei der Eingrenzung weiter.

Einige im Beispiel mit der IP des Google DNS als Ziel:
(Syntax kann von System zu System unterschiedlich sein)

1. Ein simpler Ping
(die Antwortzeiten sollten nicht zu hoch sein, das Beispiel unten ist in dem Fall i.O.)

2. Traceroute
(man sieht die Antwortzeiten für alle Hops auf dem Weg zum Ziel)

3. MTR (mytraceroute)

MTR finde ich persönlich am besten, da es eine Kombination von Ping und Traceroute ist und man für jeden einzelnen Hop die Paket Verluste sieht und dadurch ziemlich gut einschätzen kann, ob die Probleme z.B. eher im lokalen Netz, auf dem Weg zum Ziel, oder direkt nur am Ziel liegen (oder an allem gleichzeitig).

Leider blocken immer mehr Service Anbieter und Provider, oder auch Cloud Software Lösungen ICMP Pakete, so dass diese Tools nicht immer funktionieren, bzw. dann an bestimmten Stellen nur drei ??? eingeblendet werden.

Am Beispiel oben zum Google DNS war das zum Glück nicht der Fall.

Stefan Gundel
Stefan Gundel
Senior Systems Engineer

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Jitsi Best Practice und Skalierung

Seit nun mehr als zwei Wochen wird dort wo es möglich ist von Zu Hause aus gearbeitet. Home-Office für ALLE! Naja mindest für die die es können.

Damit ist auch von einem Tag auf den anderen der Bedarf an Kommunikations-Werkzeugen vor allem für Video-Konferenzen gestiegen.
Hierfür gibt es einige Plattformen welche mittels Jitsi Video- und Audiokommunikation als Service anbieten. Darunter auch NETWAYS Web Services
Jitsi ist eine Freie Software welche auch selbst betrieben werden kann.
Beim Betrieb von Jitsi jedoch zeigt sich das Jitsi sehr schwierig in der Skalierung ist. Es benötigt die richtigen Ressourcen und die richtigen Clients für die Nutzung, um nicht ab einer zweistelligen Zahl von Nutzern in einen reinen Ton- und Bildsalat zu enden. Die technischen Dokumentationen jedoch sind nicht sehr ausgeprägt und durch ihre Zerstreuung sehr schwer zu einem ganzen zusammen zu fügen.

Daher werden wir uns folgend mit den Punkten Anforderungen, Skalierung und Nutzung auseinander setzen.

Empfehlung für einen eigenen Jitsi Server/Videobridge

Nach meinen Tests und der Güte an vorhandenen Quellen zur Hilfe und Dokumentation komme ich zu folgendem Ergebnis:

    • Betriebssystem: Debian 10 oder Ubuntu 18.04.4 LTS
    • Soviel CPU wie geht
      (klingt komisch ist aber so)
      CPU: bei durchschnittlich 10 Teilnehmer pro Konferenz kommen ich mit 2vCPU für die Videobridge ganz gut klar. Mehr zur Skalierung der CPU findet ihr hier:

jitsi-videobridge-performance-evaluation

  • CPU Jitis/Jifico/Prosody: Hier würde auch eine (v)CPU ausreichen, hängt jedoch auch wieder von der Frequentierung ab.
  • RAM: 4-8 GB für beide Server-Varianten
  • Speicherplatz: max. 50 GB SSD für beide Server-Varianten
  • Eine hohe Bandbreite
  • Die Unstable Version von Jitsi:
# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c &amp;amp;quot;echo 'deb https://download.jitsi.org unstable/' &amp;amp;gt; /etc/apt/sources.list.d/jitsi-unstable.list&amp;amp;quot;
apt update

Eine gute Installations-Anleitung dazu gibt es zum einen von Jan Doberstein auf seinem Blog jalogisch.de
oder auch sehr hilfreich und weiterführend auf der Seite lw1.at guides

Skalierung einer Jitsi Infrastruktur

Ausgangslage

Wir haben einen vollständig installierten Jitsi Server Namens jitsi.example.com auf Basis von Debian. Jetzt wollen wir mehr mehr Ressourcen bereit stellen, so müssen wir weitere jitsi-videobridge Instanzen aufsetzen.
In der vollständigen Installation eines Jitsi-Servers auf Basis von Debian 10 sind folgende Pakete installiert:

ii jitsi-meet 1.0.4314-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.3914-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-web 1.0.3914-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.3914-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 1132-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)

Der Part jitsi-videobridge ist der Teil der den jtisi-meet mit der Video und Audio Übertragung versorgt. Er schließt sich an jitsi-meet und dem verwendeten prosody (XMPP-Server) an.

Anbindung einer Videobridge

Dazu binden wir die die Paketquellen auf dem zweiten Server vb1.example.com ein und installieren die Videobridge:

# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c &amp;amp;quot;echo 'deb https://download.jitsi.org unstable/' &amp;amp;amp;gt; /etc/apt/sources.list.d/jitsi-unstable.list&amp;amp;quot;
apt update
apt install jitsi-videobridge2

Sollte eine Firewall auf dem Server jitsi.example.com aktiviert sein so müssen wir den Port 5222 für eingehende Kommunikation öffnen.

Auf dem zweiten Server vb1.example.com passen wir jetzt die Datei „/etc/jitsi/videobridge/config“ an:

# Jitsi Videobridge settings

# sets the XMPP domain (default: none)
JVB_HOSTNAME=jitsi.example.com

# sets the hostname of the XMPP server (default: domain if set, localhost otherwise)
JVB_HOST=jitsi.example.com
....

Dann kommen wir zu Datei für die SIP-Kommunikation. Diese sollte vom Hauptserver jitsi.example.com übernommen werden und die UUID sollte hierbei auf jedem Server unterschiedlich gesetzt sein.
Die Datei „/etc/jitsi/videobridge/sip-communicator.properties“ wird wie folgt eingestellt:

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true
# Notwendig falls der Server hinter einem NAT steht.
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=local-ip
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=public-ip
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.jitsi.example.com
#UUID am besten mit &amp;amp;quot;uuidgen&amp;amp;quot; neu gernieren muss auf beiden Servern Einzigartig sein.
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=9a6187f0-6d3f-46df-b1ff-ce7d2d69513a
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Auf Debian 10 tritt mit Java 11 folgender Fehler auf:

VB 2020-03-21 19:29:23.687 SEVERE: [16] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception.
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not &amp;amp;quot;opens com.sun.management.internal&amp;amp;quot; to unnamed module @54ca3634
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450)
at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321)
at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

Dieser kann beseitigt werden mittels folgender Ergänzung am Ende der Java System Properties in der Datei „/etc/jitsi/videobridge/config“:

JAVA_SYS_PROPS=&amp;amp;quot;-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED&amp;amp;quot;

Nun können wir die Videobridge starten:

systemctl enable jitsi-videobridge &amp;amp;amp;&amp;amp;amp; systemctl start jitsi-videobridge

An der Stelle geht auch ein Dank an Jan Doberstein der mich auf diese Spur gebracht hat und in seinem Blog-Folge Artikel zu Scaling Jitsi

Nutzung

Das Protkoll WebRTC, welches Jitsi nutzt, wird zur Zeit nur sauber von Google Chrome unterstützt. Somit sollte allen Nutzern dieser Browser, für die Anwendung am Notebook empfohlen werden. Für Androide und iOS Geräte gibt es Applikationen den jeweiligen App-Stores. Sehr schöne Zusammenfassung und eine ausführliche Benutzer-Anleitung hierzu gibt es auch auf der Seite des Freifunk München.

Sicherheit

Zum Thema Sicherheit empfiehlt es sich am Besten zuerst die Stunning-Server von Google in der Datei „/etc/jitsi/meet/jitsi.example.com-config.js zu ersetzen. Eine geeignete Stunning-Server Konfiguration kann wie folgt lauten:

stunServers: [
{ urls: 'stun:stun.schlund.de:3478' },
{ urls: 'stun:stun.t-online.de:3478' },
{ urls: 'stun:stun.1und1.de:3478' },
{ urls: 'stun:stun.hosteurope.de:3478' },
{ urls: 'stun:stun.gmx.de:3478' },
],

Zustätzlich wenn Ihr nicht eine gänzlich freie Plattform, sondern eine mit Moderaten oder sogennante Host per Raum gestützte Instanz betreiben wollt, empfiehlt es sich in prosody und jitsi-meet die Benutzerauthentifzierung für das erstellen von Räumen zu aktivieren.
In der Datei für die prosody-Konfiguration „/etc/prosody/conf.avail/jitsi.example.com.cfg.lua“, setzen wir den Wert für „authentication“ auf „internal_plain“ und fügen einen neuen VirtualHost darunter ein ein:

VirtualHost &amp;amp;quot;jitsi.yourdomain.example&amp;amp;quot;
-- enabled = false -- Remove this line to enable this host
authentication = &amp;amp;quot;internal_plain&amp;amp;quot;
-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to &amp;amp;quot;token&amp;amp;quot;
--app_id=&amp;amp;quot;example_app_id&amp;amp;quot;
--app_secret=&amp;amp;quot;example_app_secret&amp;amp;quot;
-- Assign this host a certificate for TLS, otherwise it would use the one
-- set in the global section (if any).
-- Note that old-style SSL on port 5223 only supports one certificate, and will always
-- use the global one.
ssl = {
key = &amp;amp;quot;/etc/prosody/certs/jitsi.yourdomain.example.key&amp;amp;quot;;
certificate = &amp;amp;quot;/etc/prosody/certs/jitsi.yourdomain.example.crt&amp;amp;quot;;
}
-- we need bosh
modules_enabled = {
&amp;amp;quot;bosh&amp;amp;quot;;
&amp;amp;quot;pubsub&amp;amp;quot;;
&amp;amp;quot;ping&amp;amp;quot;; -- Enable mod_ping
}
c2s_require_encryption = false

VirtualHost &amp;amp;quot;guest.jitsi.example.com&amp;amp;quot;
authentication = &amp;amp;quot;anonymous&amp;amp;quot;
c2s_require_encryption = false

In der Datei „/etc/jitsi/meet/jitsi.example.com-config.js“ geben wir nun den neuen VirtualHost an:

var config = {
hosts: {
// XMPP domain.
domain: 'jitsi.yourdomain.example',

// When using authentication, domain for guest users.
anonymousdomain: 'guest.jitsi.yourdomain.example',
}
}

Nun müssen wir noch jifico dazu veranlassen auch eine Authentifizierung durchzuführen und die Klasse in der „/etc/jitsi/jicofo/sip-communicator.properties“ laden:

org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com

Danach müssen die Dienste neu gestartet werden:

sudo systemctl restart prosody.service
sudo systemctl restart jicofo.service

Für die Anbindung einer Authentifizierung in Prosody gibt es auch Enterprise fähige Funktionen für LDAP und Co. Die obige Lösung beschreibt es für ein überschaubares Setup, denn die Benutzer hier müssen dann im Anschluss mit der prosodctl generiert werden:

prosodyctl register  jitsi-meet.example.com

Abschließend bleibt zusagen…

Es ist nicht leicht gute Dokumentationen zu Jitsi und dessen Betrieb zu finden, eben so wie für das Scalling. Eine einheitliche Dokumentation gibt es nicht und somit macht es einen Gesamtüberblick nicht sehr leicht.
Neben der Jitis-Community und der Docs auf GitHub gibt es eine paar bereits schon erwähnte Artikel aber auch die sind rah. Daher die Bitte wenn jemand verbesserungen hat, meldet euch gerne!

Wenn Ihr eine Instanz dringend benötigt und euch nicht mit dem Betrieb ausseinandersetzen könnt oder naja vielleicht nicht wollt, dann schaut doch einfach bei unseren Kollengen von NWS vorbei. Dort bekommt Ihr aktuell mit dem Code #StayAtHome eine kostenlose Jitsi-Instanz für drei Monate und das ganz ohne Abo-Falle!

Also bleibt Zuhause und fragt euch gerade in diesen Tagen doch mindestens einmal am Tag:

1. Ist es wahr?
2. Ist es fair für alle Beteiligten?
3. Wird es Freundschaft und guten Willen fördern?
4. Wird es dem Wohl aller Beteiligten dienen?“

(Das sollten wir uns bei allem Fragen, was wir denken, sagen oder tun IMHO!)

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.