Schlagwort-Archive: osbn

Tag OSBN

CVE — Ist mein RHEL-System betroffen? Was kann ich tun?

Regelmäßig berichtet die IT-Fachpresse über neue Common Vulnerabilities and Exposures (CVE). Dieser Artikel möchte euch eine kleine Hilfestellung geben, um herauszufinden, ob euer RHEL-System von einem CVE betroffen ist.

In unserem Rechenzentrum betreibe ich ein Patchmanagement mit Ansible für unsere RHEL-Systeme. Dieses stellt sicher, dass einmal im Monat verfügbare Red Hat Security Advisories (RHSA) auf allen RHEL-Systemen installiert werden. Damit gewährleisten wir ein Mindestmaß an Sicherheit. Selbstverständlich können darüber hinaus alle System-Betreiber*innen zu jeder Zeit verfügbare Updates auf den von ihnen betreuten Servern installieren.

Wie eingangs erwähnt berichtet in der Regel die IT-Fachpresse über neue Sicherheitslücken und Schwachstellen. Diese Meldungen enthalten häufig auch die sogenannten CVE-Nummern, welche eine Schwachstelle/Sicherheitslücke eindeutig identifizieren. Mit Hilfe dieser Nummer könnt ihr feststellen, ob euer RHEL-System verwundbar ist und ob ggf. schon ein Patch existiert, welcher das Problem behebt.

Für diesen Text habe ich exemplarisch zwei Schwachstellen ausgewählt:

Nutzung der Red Hat CVE-Datenbank

Red Hat betreibt eine CVE-Datenbank unter der URL: https://access.redhat.com/security/security-updates/#/cve

Hier kann man nach einer CVE-Nummer suchen und zu weiterführenden Informationen zu einer Schwachstelle gelangen (siehe Abb. 1). Hinter dem Link in der Tabelle verbirgt sich eine Detail-Seite für den jeweiligen CVE.

screenshot-cve-database.png
Abb. 1: Screenshot der Red Hat CVE-Datenbank für CVE-2020-0543

Liefert eine Suche keine Treffer zurück, kann dies verschiedene Ursachen haben (siehe Abb. 2).

screenshot-rh-cve-2020-0595.png
Abb. 2: Red Hat CVE-Datenbank liefert nicht zu jeder CVE-Nummer einen Treffer

Nutzung des Paket-Managers auf der Kommandozeile

Mit Hilfe des Paket-Managers YUM kann für jedes System individuell geprüft werden, ob für einen CVE ein entsprechender Fix existiert. Der folgende Codeblock veranschaulicht dies:

$ sudo yum updateinfo list --cve CVE-2020-0543                                
[...]
RHSA-2020:2432 Moderate/Sec. microcode_ctl-2:2.1-61.6.el7_8.x86_64
updateinfo list done
$
$ sudo yum updateinfo list --cve CVE-2020-13777
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
updateinfo list done
$

Die erste Abfrage nach CVE-2020-0543 zeigt, dass es ein Security-Advisory für ein installiertes Paket gibt, welches von der Schwachstelle betroffen ist. Gegen CVE-2020-13777 ist das System hingegen nicht verwundbar. Dies ist in diesem Fall der Tatsache geschuldet, dass GnuTLS auf dem genutzten System nicht installiert ist.

Mit Hilfe des folgenden Befehls lassen sich auch auf der Kommandozeile weitere Informationen zu einem CVE abrufen:

$ sudo yum updateinfo info --cve CVE-2020-0543 
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

===============================================================================
  Moderate: microcode_ctl security, bug fix and enhancement update
===============================================================================
  Update ID : RHSA-2020:2432
    Release : 0
       Type : security
     Status : final
     Issued : 2020-06-09 18:20:28 UTC
       Bugs : 1788786 - CVE-2020-0548 hw: Vector Register Data Sampling
	    : 1788788 - CVE-2020-0549 hw: L1D Cache Eviction Sampling
	    : 1827165 - CVE-2020-0543 hw: Special Register Buffer Data Sampling (SRBDS)
       CVEs : CVE-2020-0543
	    : CVE-2020-0548
	    : CVE-2020-0549
Description : Security Fix(es):
            : 
            : * hw: Special Register Buffer Data Sampling
            :   (SRBDS) (CVE-2020-0543)
            : 
            : * hw: L1D Cache Eviction Sampling (CVE-2020-0549)
            : 
            : * hw: Vector Register Data Sampling
            :   (CVE-2020-0548)
            : 
            : For more details about the security issue(s),
            : including the impact, a CVSS score,
            : acknowledgments, and other related information,
            : refer to the CVE page(s) listed in the References
            : section.
            : 
            : Bug Fix(es):
            : 
            : * Update Intel CPU microcode to microcode-20200602
            :   release, addresses:
            :   - Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0)
            :     microcode from revision 0x61f up to 0x621;
[...]

CVE durch Update schließen

Ich persönlich empfehle in der Regel, das gesamte System mittels sudo yum -y upgrade zu aktualisieren und so alle installierten Pakete auf den aktuellsten Stand zu bringen. Es ist jedoch auch möglich, nur die Updates zu installieren, die notwendig sind, um eine spezielle Schwachstelle zu schließen. Auch hierfür wird wieder die CVE-Nummer genutzt:

$ sudo yum upgrade --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
 --> mock-2.2-1.el7.noarch from @epel removed (updateinfo)
 --> unbound-libs-1.6.6-3.el7.x86_64 from @rhel-7-server-rpms removed (updateinfo)
 --> mock-2.3-1.el7.noarch from epel removed (updateinfo)
 --> unbound-libs-1.6.6-4.el7_8.x86_64 from rhel-7-server-rpms removed (updateinfo)
1 package(s) needed (+0 related) for security, out of 3 available
Resolving Dependencies
--> Running transaction check
---> Package microcode_ctl.x86_64 2:2.1-61.el7 will be updated
---> Package microcode_ctl.x86_64 2:2.1-61.6.el7_8 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================
 Package                              Arch                          Version                                   Repository                                 Size
==============================================================================================================================================================
Updating:
 microcode_ctl                        x86_64                        2:2.1-61.6.el7_8                          rhel-7-server-rpms                        2.6 M

Transaction Summary
==============================================================================================================================================================
Upgrade  1 Package

Total size: 2.6 M
Is this ok [y/d/N]:

Obigem Code-Block ist zu entnehmen, dass Updates für insgesamt drei Pakete zur Verfügung stehen. Um CVE-2020-0543 zu schließen, wird jedoch nur das Paket microcode_ctl aktualisiert. Die beiden anderen Pakete werden nicht verändert.

Weitere Informationsquellen zu diesem Thema

Thunderbird-Daten auf neue Rechner/Installationen übertragen

Es ist so einfach und doch suche ich jedes Mal erneut. Darum verlinke ich hier die deutschsprachige Anleitung von Mozilla: Thunderbird-Daten auf einen neuen Rechner übertragen

Ergänzend zu obiger Anleitung dokumentiere ich an dieser Stelle, wie die Einstellungen des Add-Ons Enigmail zur Übertragung auf einen neuen Rechner gesichert werden können.

Dazu geht man in die Add-On-Einstellungen von Enigmail und öffnet die Registerkarte „Einstellungen übertragen“. Anschließend lässt man sich vom Export-Assistenten durch den Prozess führen.

Firefox-Profil auf neue Rechner/Installationen umziehen

Es ist eigentlich so einfach und doch suche ich jedes Mal erneut danach. Deshalb möchte ich hier kurz die Links zu den deutschsprachigen Mozilla-Artikeln festhalten, welche den Umgang und Umzug von Firefox-Profilen erläutern.

tmux und tmux-xpanes

Die beiden genannten Anwendungen ergänzen erst seit kurzer Zeit meine SysAdmin-Werkzeugsammlung und werden im folgenden kurz vorgestellt.

Um Programme auch nach dem Beenden einer SSH-Sitzung weiterlaufen lassen zu können, habe ich in der Vergangenheit unter verschiedenen Distributionen das Programm screen verwendet. Mit dem Release von RHEL 7.6 (en) ist screen deprecated (en). Da es somit in RHEL 8 nicht mehr enthalten ist, wurde es Zeit, sich nach einer Alternative umzusehen, welche ich in tmux gefunden habe.

Mit tmux werden die gleichen Anforderungen erfüllt, welche ich an screen gestellt habe und ermöglicht es darüber hinaus, innerhalb eines Terminals oder einer Terminalemulation verschiedene virtuelle Konsolensitzungen zu erzeugen und zu verwalten. Sitzungen können getrennt („detach“) und später weitergeführt werden („attach“). Auch die Möglichkeit, ein Fenster vertikal und horizontal in mehrere „panes“ zu unterteilen, finde ich sehr praktisch.

Die Möglichkeit, ein tmux-Fenster in verschiedene Bereiche zu unterteilen, brachte mich zu der Frage, ob es damit nicht auch möglich ist ein weiteres Werkzeug aus meiner Sammlung abzulösen.

Cluster SSH (en) ermöglicht es, auf einfache Weise parallele SSH-Sitzungen zu mehreren Hosts aufzubauen. Für jeden Host wird dabei ein eigenes xterm-Fenster geöffnet und Befehle können zeitgleich an alle verbundenen Hosts gesendet werden.

Zwar bietet auch tmux mit der Option „synchronize-panes on“ die Möglichkeit, Befehle gleichzeitig an mehrere „panes“ zu senden, doch müssen diese und die SSH-Sitzungen darin zuvor manuell hergestellt werden, was sich als recht umständlich erwies.

Hier betritt nun tmux-xpanes (en) von Yasuhiro Yamada die Bühne, welches diesen Arbeitsschritt enorm erleichtert.

Ich pflege recht umfangreiche ssh_config(5)-Dateien, welche sich hervorragend durch tmux-xpanes nutzen lassen. Folgendes Bild soll die Anwendungsmöglichkeiten veranschaulichen:

Quelle: https://raw.githubusercontent.com/wiki/greymd/tmux-xpanes/img/movie_v4.gif

Eine umfassende Beschreibung der hier vorgestellten Werkzeuge würde den Umfang eines Artikels sprengen. Daher sei für weiterführende Informationen auf die folgende Linksammlung verwiesen.

Linksammlung zu tmux und tmux-xpanes

Erfahrungsbericht zum Deployment meines Blogs mit Ansible

Vor ziemlich genau zwei Jahren habe ich in „Konzept zum Deployment meines Blogs mit Ansible“ geschrieben, wie ich diesen Blog mit Hilfe von Ansible ausgehend von einem bestehenden Backup auf einen neuen Server deployen bzw. wiederherstellen möchte.

Seither habe ich das dort beschriebene Verfahren mehrfach angewendet und möchte heute an dieser Stelle meine Erfahrungen mit euch teilen.

Umgebung

Wie schon vor zwei Jahren basiert mein Ansible Control Node auf einer RHEL 7 VM. Im Unterschied zu damals kommt heute statt Ansible in der Version 2.4.2 eine aktuell unterstützte Version 2.9.6 zum Einsatz.

Das Zielsystem war damals Ubuntu Bionic Beaver. Zwischendurch habe ich diesen Blog nach dem Konzept bereits auf CentOS/RHEL 7 sowie Debian 10 eingerichtet.

Die weiteren Rahmenbedingungen entsprechen der Testumgebung aus 2018. Auch verwende ich heute noch die gleichen Module wie vor zwei Jahren:

ModulStatusVerwendung
aptstableinterfaceVerwaltet APT-Pakete
unarchivepreviewEntpackt Archiv-Dateien und kopiert sie ggf. vorher auf das Zielsystem
copystableinterfaceKopiert Dateien auf entfernte Rechner
filestableinterfaceErstellt Dateien, Verzeichnisse, symbolische Links und setzt deren Attribute
mysql_dbpreviewHinzufügen von MySQL-Datenbanken (aus Backup)
mysql_userpreviewHinzufügen (und Entfernen) von Benutzern in MySQL-Datenbanken

In der Tabelle ist zu erkennen, dass jene Module, die 2018 den Status preview hatten, diesen auch heute noch besitzen. Ich persönlich finde es schade, dass es keines dieser Module innerhalb von zwei Jahren zu einem stableinterface gebracht hat.

Darüber hinaus schleppen einige Module wie mysql_db noch ein paar ziemlich alte Bugs mit sich herum. Darunter z.B. dieser aus dem Jahre 2016. Zwar kann ich nicht mit Sicherheit sagen, ob dieser seit 2.4.2 bereits gefixt wurde. In Version 2.9.6 ist er jedenfalls vorhanden. Als Workaround habe ich den MySQL-Dump zuvor entpackt und dann im Modul verwendet, wodurch eine erheblich größere Datenmenge über das Netzwerk übertragen werden muss.

Erfahrungen der letzten zwei Jahre

Am Status der Module hat sich leider nichts geändert. Positiv sei hier jedoch angemerkt, dass sämtliche Module noch existieren und weiterhin genutzt werden können. So hatte ich zumindest keinen Aufwand, mir zwischenzeitlich neue Module suchen zu müssen, um die gestellte Aufgabe erledigen zu können.

Grundsätzlich klappt das Deployment bzw. die Wiederherstellung meines Blogs aus einem Backup mittels der Ansible-Rolle gut. Je nach verwendetem Zielsystem sind kleinere Anpassungen notwendig, da einige Pakete in CentOS anders benannt sind als in Debian, oder sich der Name in einer neueren Version der Distribution leicht geändert hat. Dieser Umstand ist jedoch nicht Ansible anzulasten, sondern rührt von den jeweiligen Paketnamen der unterschiedlichen Distributionen her.

Was mir persönlich überhaupt nicht gefällt, ist dass Ansible bei Minor-Release-Upgrades (z.B. von 2.9 auf 2.10) teilweise nicht abwärtskompatible Änderungen an der Syntax vornimmt. Dies sollte nach den Richtlinien des Semantic Versioning nicht so sein und geht in meinen Augen gar nicht. Darunter finden sich Dinge wie die Art und Weise, wie Paketnamen an ein Modul wie apt oder yum zu übergeben sind oder dass plötzlich der Bindestrich (-) in Gruppennamen nicht mehr zulässig ist. Änderungen wie diese machen sehr häufig Anpassungen am Inventory, den Playbooks und Rollen erforderlich. In meinem Fall ist der Aufwand noch überschaubar. In größeren Organisationen mit einigen hundert oder gar tausenden von Playbooks sieht die Sache schnell anders aus und wird auch nicht von allen Kunden gut aufgenommen.

Fazit

Es gibt einige Punkte, die mir an Ansible nicht so gut gefallen und bei denen ich auch keine schnelle Besserung erwarte. Auch sind von Zeit zu Zeit Anpassungen notwendig, um den Blog zu deployen bzw. wiederherstellen zu können. Jedoch hält sich der Aufwand dafür in Grenzen und ist deutlich geringer, als bspw. bei der ausschließlichen Verwendung von Bash-Skripten.

Verglichen zur manuellen Vorgehensweise (vgl. Testinstanz für einen WordPress Blog erstellen) erspart mir Ansible sogar eine Menge Zeit, welche ich z.B. mit meiner Familie verbringen kann. Daher bleibt Ansible für mich weiterhin gesetzt.

Welche Erfahrungen habt ihr mit Ansible gemacht? Und wie beurteilt ihr dieses heute im Vergleich zu den Vorjahren? Eure Berichte sind jederzeit willkommen.

RPM-Paket-Abhängigkeiten anzeigen

An dieser Stelle möchte ich kurz notieren, wie man sich die Abhängigkeiten eines RPM-Pakets anzeigen lassen kann zusammen mit den RPM-Paket-Namen, welche diese Abhängigkeiten erfüllen.

Dies geht mit dem Kommando repoquery aus dem Paket yum-utils bzw. dnf-utils. Der Aufruf erfolgt nach dem Muster:

$ repoquery --deplist PAKETNAME

Das folgende Listing zeigt dies beispielhaft für das Paket tmux:

$ repoquery --deplist tmux
Failed to set locale, defaulting to C.UTF-8
Not root, Subscription Management repositories not updated
Last metadata expiration check: 0:29:24 ago on Sat Jan 11 19:28:10 2020.
package: tmux-2.7-1.el8.x86_64
  dependency: /bin/sh
   provider: bash-4.4.19-10.el8.x86_64
  dependency: libc.so.6()(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.14)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.2.5)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.25)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.26)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.27)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.3)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.3.4)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.4)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.8)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libevent-2.1.so.6()(64bit)
   provider: libevent-2.1.8-5.el8.x86_64
  dependency: libresolv.so.2()(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libresolv.so.2(GLIBC_2.2.5)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libtinfo.so.6()(64bit)
   provider: ncurses-libs-6.1-7.20180224.el8.x86_64
  dependency: libutil.so.1()(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libutil.so.1(GLIBC_2.2.5)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: rtld(GNU_HASH)
   provider: glibc-2.28-72.el8.i686
   provider: glibc-2.28-72.el8.x86_64

Darüber hinaus kann repoquery euch auch das Changelog eines RPM-Pakets zeigen und welche Dateien es enthält.

In RPM-Paket enthaltene Dateien anzeigen

Neulich fragte mich ein Kollege, wie man sich anzeigen lassen kann, welche Dateien ein RPM-Paket enthält, bevor man dieses installiert. Dazu eignet sich das Programm repoquery aus dem Paket yum-utils bzw. dnf-utils.

Der Aufruf erfolgt nach dem Muster:

$ repoquery -l PAKETNAME

Das folgende Listing zeigt beispielhaft die Dateien im Paket tmux:

$ repoquery -l tmux
Failed to set locale, defaulting to C.UTF-8
Not root, Subscription Management repositories not updated
Last metadata expiration check: 0:10:46 ago on Sat Jan 11 19:28:10 2020.
/usr/bin/tmux
/usr/lib/.build-id
/usr/lib/.build-id/0e
/usr/lib/.build-id/0e/cd3ead12aab3291beeaacf69559804011eee9c
/usr/share/bash-completion/completions/tmux
/usr/share/doc/tmux
/usr/share/doc/tmux/CHANGES
/usr/share/doc/tmux/TODO
/usr/share/man/man1/tmux.1.gz

Darüber hinaus kann man sich mit repoquery auch das Changelog eines RPM-Pakets anzeigen lassen, ohne das Paket zuvor installieren zu müssen.

Geänderte Größe logischer Blockgeräte unter Linux ohne Neustart erkennen

Wird die Größe einer per iSCSI oder Fibre Channel eingebundenen LUN geändert, oder in einer virtualisierten Umgebung die Größe der virtuellen Festplatte (VMDK, VDI, VHD, qcow2, etc.) angepasst, kann man den Linux-Kernel auffordern die entsprechenden Blockgeräte auf Änderungen hin zu prüfen, ohne dafür das Betriebssystem neustarten zu müssen.

Die im folgenden genannten bzw. verlinkten Kommandos wurden unter RHEL 7 mit VMDK-Dateien und iSCSI-Disks getestet. Sie sollten jedoch für Linux im Allgemeinen gelten.

Änderungen an bestehenden Blockgeräten erkennen

Um Änderungen an Blockgeräten zu erkennen, welche dem Kernel bereits bekannt sind, wird folgender Befehl mit root-Rechten ausgeführt:

# echo 1 > /sys/class/block/sdX/device/rescan

Dabei ist sdX durch die Bezeichnung des konkreten Blockgeräts wie z.B. sda oder sdb etc. zu ersetzen. Statt dem genannten Bezeichner kann auch die SCSI-Nummer des entsprechenden Gerätes verwendet werden. Der Befehl lautet dann wie folgt (wobei X:X:X:X durch die jeweilige SCSI-Nummer zu ersetzen ist):

# echo 1 > /sys/class/scsi_device/X:X:X:X/device/block/device/rescan

Update 2019-12-15: Ist das Paket parted installiert, kann man den Kernel auch mit dem Kommando partprobe über die Änderungen informieren:

# partprobe /dev/sdX

Danke an Dirk für diesen Tipp.

Neue Blockgeräte erkennen

Wie neu hinzugefügte Blockgeräte erkannt werden können, habe ich bereits im Artikel Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen beschrieben.

Quellen und weiterführende Hinweise

  1. How to rescan disk in Linux after extending vmware disk
  2. How to map Linux disk to vmware disk
  3. Red Hat Storage Administration Guide: Sec. 37.2. Resizing an iSCSI Logical Unit

Der GNU/LinuxDay in Vorarlberg – am 19. Okt. 2019 in Dornbirn – ist vorbei

LinuxDay 2019 am 19. Okt. in Dornbirn

Update 20.10.2019: Nun ist der LInuxDay AT schon wieder vorbei und ich bin wohlbehalten in der Heimat angekommen. Vielen Dank an das Orga-Team für die tolle Organisation und den schönen Tag. Ebenfalls vielen Dank an die Hörer meines Vortrags, welche mir im Anschluss zahlreiche Rückmeldungen gaben. Bis nächstes Jahr.

Diesen Monat ist es wieder soweit. Die LUG Vorarlberg lädt zum LinuxDay AT in die HTL Dornbirn ein. Mit bis zu 500 Besuchern ist dies die größte Veranstaltung zu Linux und Freier Software in der Bodenseeregion.
Der Eintritt ist frei! Das Programm wartet auch in diesem Jahr wieder mit spannenden Vorträgen auf. Mit dabei auch ein Vortrag von mir zum Thema: Mehr Spaß beim Ausprobieren dank Virtualisierung

Dieser richtet sich vor allem an Anwender, die bisher nicht oder nur wenig mit Virtualisierung in Berührung gekommen sind und erfahren möchten, wie man mit dieser Technologie neue Betriebssysteme erkunden kann.

Natürlich freue ich mich auch darauf, bekannte Gesichter wiederzusehen und neue kennenzulernen. Also kommt vorbei. Wir sehen uns in Dornbirn.

DNS over HTTPS (DoH) — Was ändert sich für den Nutzer?

Mozilla und Google haben angekündigt, DoH in ihren Webbrowsern Firefox bzw. Chrome zu aktivieren. In diesem Artikel möchte ich allgemeinverständlich erklären, was sich dadurch für Nutzer dieser Programme ändern kann bzw. wird.

Dazu beschreibe ich zuerst in vereinfachender Weise, wie das heutige DNS-System funktioniert und was an diesem System kritisiert wird. Darauf folgt eine Beschreibung von DoH und der Kritik an diesem Protokoll. Der Artikel soll dem Leser helfen, sich eine eigene Meinung zu bilden.

Dieser Artikel richtet sich in erster Linie an (Privat-)Anwender und Nutzer der genannten Programme. Er soll ein grundlegendes Verständnis auch ohne vollständige Kenntnis der Fachterminologie ermöglichen. Den versierten Leser bitte ich daher zu entschuldigen, sollten einige Ausführungen fachlich nicht ganz exakt sein.

Das Domain Name System (DNS)

Das DNS ist einer der wichtigsten Dienste in vielen Netzwerken und quasi das Rückgrat des Internets. Denn es sorgt dafür, dass zu einer Eingabe im Webbrowser wie z.B. https://www.my-it-brain.de oder www.ubuntuusers.de der Server gefunden wird, welcher die entsprechende Seite ausliefern kann. Das DNS funktioniert dabei so ähnlich wie ein Telefonbuch bzw. eine Telefonauskunft.

Wie wird das DNS von (Privat-)Anwendern genutzt?

Um zu veranschaulichen, wie das DNS in den meisten Fällen genutzt wird, stelle man sich folgendes Heimnetzwerk vor, wie es vermutlich in vielen Haushalten existiert.

typical-soho-network
Darstellung eines typischen Heimnetzwerks mit Anbindung an das Internet über einen Internet Service Provider

Endgeräte wie Laptop, Smartphone, Tablet, PC, etc. sind via LAN oder WLAN an den heimischen (W)LAN-Router angebunden. Letzterer erhält vom Internet Service Provider (ISP) eine oder mehrere IP-Adressen mitgeteilt, über welche der Router — vom Internet aus gesehen — erreichbar ist. Darüber hinaus teilt der ISP noch die IP-Adressen seiner DNS-Server mit, welche ebenfalls im (W)LAN-Router gespeichert werden.

Der (W)LAN-Router wiederum weist jedem Endgerät eine IP-Adresse zu, unter welcher dieses Gerät im Heimnetzwerk erreicht werden kann. Darüber hinaus teilt er den Endgeräten eine sogenannte Gateway-Adresse mit. Diese Adresse stellt für die verbundenen Endgeräte quasi das Tor ins Internet dar. Gleichzeitig wird diese IP-Adresse meist auch als DNS-Serveradresse auf den Endgeräten konfiguriert. Erledigt wird dies alles in der Regel über das DHCP-Protokoll, um dem Nutzer die manuelle Konfiguration der beteiligten Komponenten zu ersparen.

Damit sind dann eigentlich auch schon alle Voraussetzungen geschaffen, um mit den Endgeräten im Internet surfen zu können.

Tippt nun ein Nutzer im Webbrowser seines PCs die Adresse https://www.my-it-brain.de ein, wird auf folgendem Weg die IP-Adresse des Servers ermittelt, welcher diesen Blog ausliefert. Das folgende Bild dient der Veranschaulichung der Schritte 1-5.

dns-request-answer-png
Darstellung der zur Namensauflösung durchlaufenden Schritte
  1. PC fragt den (W)LAN-Router nach der gesuchten IP-Adresse
  2. (W)LAN-Router fragt den bzw. die DNS-Server des ISP
  3. Der DNS-Server des ISP fragt ggf. weitere DNS-Server im Internet
  4. DNS-Server des ISP kennt die gesuchte IP-Adresse und teilt sie dem (W)LAN-Router mit
  5. Der (W)LAN-Router teilt die IP-Adresse dem PC mit

Der PC ist mit Kenntnis der IP-Adresse nun in der Lage, die gewünschte Seite beim Server anzufragen und im Webbrowser darzustellen.

Oftmals verfügen die in vorstehender Abbildung dargestellten Geräte über einen Zwischenspeicher für erfolgreich ausgeführte DNS-Abfragen, den sogenannten Cache. So muss bei einer wiederholten Anfrage einer bereits erfolgreich aufgelösten IP-Adresse nicht erneut die komplette Kette durchlaufen werden. Die Anfrage kann stattdessen aus dem Cache beantwortet und somit Zeit eingespart werden. Das folgende Code-Beispiel soll dies verdeutlichen. Dabei ist es nicht wichtig, jede einzelne Zeile interpretieren zu können. Der Befehl dig my-it-brain.de versucht den Namen ‚my-it-brain.de‘ in eine IP-Adresse aufzulösen. Die mit ‚Query time‘ beginnende Zeile gibt die Verarbeitungsdauer der Anfrage an.

user@X201:~$ dig my-it-brain.de

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> my-it-brain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;my-it-brain.de.			IN	A

;; ANSWER SECTION:
my-it-brain.de.		3600	IN	A	136.243.44.163

;; Query time: 68 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 26 15:45:15 CEST 2019
;; MSG SIZE  rcvd: 59

user@X201:~$ dig my-it-brain.de

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> my-it-brain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55400
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;my-it-brain.de.			IN	A

;; ANSWER SECTION:
my-it-brain.de.		3590	IN	A	136.243.44.163

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 26 15:45:24 CEST 2019
;; MSG SIZE  rcvd: 59

user@X201:~$

Die Beantwortung der ersten DNS-Abfrage dauerte noch 68 ms. Die zweite Anfrage konnte direkt aus dem Cache meines Laptops in 0 ms beantwortet werden. Dabei ist anzumerken, dass alle Anwendungen von diesem Cache profitieren können, sofern sie alle den Cache des Betriebssystems oder ggf. auch den des nachgelagerten (W)LAN-Routers nutzen können.

Kritik

Die Kommunikation über das DNS-Protokoll ist nicht verschlüsselt. Jeder Teilnehmer in einem Netzwerk, der eine DNS-Abfrage zu sehen bekommt, kann deren vollständigen Inhalt lesen. So kann z.B. der ISP sehen, welche Seiten wie oft von seinen Kunden aufgerufen werden. Wobei über die Häufigkeit wiederholter Seitenaufrufe keine genaue Aussage getroffen werden kann, wenn im Heimnetzwerk des Nutzers DNS-Caches verwendet werden.

Der DNS-Client, welcher einen Namen in eine IP-Adresse auflösen möchte, hat keinerlei Möglichkeit zu prüfen, ob die zurückgelieferte IP-Adresse wirklich dem Inhaber der gewünschten Seite gehört. Im Prinzip kann jeder, der eine DNS-Anfrage sieht, eine Antwort senden. Das Endgerät akzeptiert in der Regel die Antwort, die es als erstes erreicht als gültig.

Dadurch bestehen vielfältige Angriffsformen, welche meist das Ziel verfolgen, DNS-Teilnehmer durch Manipulation auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw. zu ergaunern. Darüber hinaus können Manipulationen auch für Zwecke der Zensur verwendet werden.

Die erwähnten Gefahren für Angriffe bzw. Zensur möchte ich mit zwei kurzen Beispielen verdeutlichen.

Beispiel 1: Phishing mit Hilfe von Cache Poisoning

cache-poisoning
Skizzierte Darstellung eines Angriffs mittels Cache Poisoning

Beim Cache Poisoning wird der DNS-Cache des (W)LAN-Routers manipuliert. In der Folge werden Aufrufe von z.B. Gmail, Amazon, eBay oder Online-Banking-Webseiten auf sogenannte Phishing-Webseiten umgeleitet. Diese sehen den echten Seiten meist zum Verwechseln ähnlich und sollen den Nutzer dazu verleiten, seine Zugangsdaten zu diesen Diensten preiszugeben.

Als Anwender gibt es nicht viel, was man tun kann, um sich vor diesen Angriffen zu schützen. Es bleibt lediglich:

  • Verfügbare Sicherheitsupdates für alle vorhandenen Geräte zeitnah zu installieren
  • Beim Besuch von Webseiten skeptisch zu prüfen, ob es Anomalien gibt, die auf Phishing-Versuche hindeuten können

Beispiel 2: Zensur durch den ISP

Eure DNS-Anfragen müssen in jedem Fall bei eurem ISP vorbei. Entweder, weil ihr die DNS-Server eures ISP verwendet, oder weil sie dessen Netz auf dem Weg zu eurem DNS-Provider passieren. In jedem Fall kann euer ISP die Pakete identifizieren und ihren Inhalt lesen. Damit ist euer ISP auch in der Lage, die Anfrage bzw. Antwort zum Zwecke der Zensur zu manipulieren.

Das Risiko der Zensur ist je nach Land und verwendetem ISP bzw. DNS-Provider unterschiedlich zu bewerten. Als Nutzer könnt ihr der Zensur evtl. entgehen, indem man VPN-Tunnel nutzt, um mit vertrauenswürdigen DNS-Providern zu kommunizieren. Dies funktioniert jedoch nur, sofern die VPN-Protokolle vom ISP nicht identifiziert und ebenfalls blockiert werden können.

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird.[1] Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.[2]

https://de.wikipedia.org/wiki/DNS_over_HTTPS

Was ändert sich für (Privat-)Anwender?

Bei Verwendung dieses Protokolls wird zur Auflösung von Namen in IP-Adressen nicht mehr die Infrastruktur eures Heimnetzwerks oder die eures ISP genutzt. Anwendungen wie z.B. Mozilla Firefox oder Google Chrome implementieren vorkonfigurierte DNS-Server-Adressen, welche zukünftig die Namensauflösung übernehmen. Wie dies aussehen kann, wird in folgender Skizze dargestellt.

dns-over-https
Darstellung zweier DNS-over-HTTPS-Verbindungen

Die Skizze zeigt Verbindungen zwischen verschiedenen Anwendungen und verschiedenen DNS-Diensten im Internet. Die Kommunikation erfolgt über das HTTPS-Protokoll und ist damit verschlüsselt. Die Verschlüsselung der DNS-Kommunikation soll vor Manipulation schützen. Ganz nach dem Motto: „Was man nicht sieht, kann man nicht manipulieren bzw. blockieren.“

Der Anwender selbst hat nichts weiter zu tun. Sein Internet funktioniert weiterhin, ohne etwas ändern zu müssen. Die in den obigen Beispielen beschriebenen Probleme scheinen gelöst, oder? Ja, aber …

Kritik an DoH

DoH verhindert effektiv Zensur durch den ISP. Dieser kann die in HTTPS versteckten DNS-Anfragen nicht von anderem HTTPS-Datenverkehr unterscheiden. Einzig vorstellbare Gegenmaßnahme ist die Blockade sämtlichen HTTPS-Datenverkehrs.

Cache Poisoning sollte keinen Einfluss mehr auf die Anwendungen haben, da diese die vorhandene Infrastruktur nicht mehr nutzen und die Anwendungen (hoffentlich) nur Antworten von den konfigurierten DNS-Services akzeptieren.

Tatsächlich fallen mir noch einige weitere Angriffsvektoren wie z.B. DNS-/IP-Spoofing und Man-in-the-Middle-Angriffe auf HTTPS ein, doch mögen diese durch Maßnahmen auf Anwendungsseite mitigiert worden sein. Daher gehe ich hier nicht weiter darauf ein. Sollte ich neue Erkenntnisse hierzu gewinnen, werde ich diese in einem folgenden Artikel thematisieren.

Statt dem eigenen ISP bzw. dem selbst gewählten DNS-Server zu vertrauen, liegt das Vertrauen nun bei den in den Anwendungen konfigurierten DNS-Providern. Warum ich diesen mehr Vertrauen sollte als meinem ISP, erschließt sich mir persönlich nicht.

In einer Welt, in der Google als Datenkrake verschrien ist, gebe ich diesem Unternehmen nur ungern auch noch meine DNS-Anfragen und würde diese lieber bei meinem ISP belassen. Nun lebe ich in einem Land, wo die ISPs noch nicht negativ durch Zensur aufgefallen sind. Wer hier das kleinere Übel darstellt, muss jeder für sich selbst beurteilen.

Stand heute ist mir nicht bekannt, ob die zu verwendenden DNS-Server in den Anwendungen (wie z.B. Firefox und Chrome) konfiguriert werden können oder man mit den Voreinstellungen leben muss. Möchte man die Vorgabe ändern, hat man nun definitiv mehr Arbeit als früher. Beim klassischen DNS lässt man einfach neue DNS-Server-Adressen über DHCP an seine Endgeräte verteilen und ist fertig. Bei DoH ist diese Konfiguration pro Anwendung und pro Endgerät durchzuführen. Ich fände es schon ärgerlich, wenn zukünftig jede Anwendung mit ihrem eigenen DNS-Resolver daherkommt und einzeln angepasst werden muss.

DoH geht an den im Heimnetzwerk existierenden Caches vorbei. Dies bedeutet entweder langsamere DNS-Abfragen oder erhöhten Bedarf an Arbeitsspeicher auf den Endgeräten, wenn alle Anwendungen nun ihren eigenen Cache implementieren.

Und wenn nun ein oder zwei dieser großen Dienste, auf die alle DNS-Anfragen konzentriert werden, ausfällt? Dann müssen unter Umständen eine Vielzahl von Anwendungen einzeln umkonfiguriert werden, um einen anderen DNS-Provider zu nutzen. Und das auf jedem Endgerät!

Fazit

Das bisherige DNS ist nicht perfekt. Es hat Stärken und Schwächen. Die Schwächen wurden oben bereits benannt. Zu einer der Stärken zählt, dass das DNS hierarchisch aufgebaut ist und dezentral betrieben wird. So ist es recht unwahrscheinlich, dass das DNS als Ganzes ausfallen bzw. kontrolliert werden kann. Fällt das DNS des ISP oder des gewählten DNS-Providers aus, kann man mit verhältnismäßig geringem Aufwand einen anderen DNS-Server verwenden und den Dienst weiterhin nutzen.

Mir persönlich gefällt das Konzept von DoH aus den oben genannten Gründen nicht. Ich hoffe und wünsche mir, dass sich auch in zukünftigen Versionen der verschiedenen Anwendungen DoH deaktivieren und die vorhandenen DNS-Resolver des Betriebssystems bzw. des Heimnetzwerks nutzen lassen.

Auch wenn ich selbst von DoH nicht überzeugt, geschweige denn begeistert bin, wird die Marktmacht von Mozilla und Google sicher ausreichen, um das Protokoll dauerhaft zu etablieren. Hoffentlich lassen die Anwendungshersteller uns Anwendern die Freiheit, die Anwendung nach unseren Wünschen zu konfigurieren.

Doch nun genug der Schmähkritik. Ich möchte hier nicht mit einem negativen Ausblick schließen, bietet DoH doch auch Chancen. Steigt mit der Zeit die Anzahl der verfügbaren DoH-Endpunkte, hat der Anwender in Zukunft evtl. eine ebenso große Auswahl wie heute bei den DNS-Servern. Und vielleicht unterstützen zukünftig auch die Resolver des Betriebssystems und der heimischen (W)LAN-Router DoH und können wie heute von den jeweiligen Anwendungen genutzt werden. All dies bleibt abzuwarten. Bis dahin wird das Internet für den normalen Anwender wohl auch weiter funktionieren, nachdem Firefox und Chrome DoH aktiviert haben.

Ich hoffe, ich konnte euch das DNS und DoH etwas näherbringen. So dass ihr die Eingangsfrage für euch selbst beantworten könnt. Solltet ihr Fragen haben oder über die beiden hier besprochenen Protokolle diskutieren wollen, nutzt gern die Kommentarfunktion dazu.

Weiterführende Quellen und Links

Dieser Beitrag darf gerne geteilt werden.