Cybersicherheit

DNS-Poisoning durch DNSMasq – Warum es in modernen Anwendungen fehlschlägt und wie wir unsere Dienste schützen können

Geschrieben von Adam Muiz Aktualisiert: 06 Aug 2026 10 Min. gelesen

Vor einiger Zeit habe ich Ihnen von einem DNS-Router erzählt, der in die falsche Richtung geht – einem Vorfall, bei dem VPS1-Domäne zeigt plötzlich VPS2-Inhalte an, weil die DNS-Einstellungen auf dem Router versehentlich geändert wurden. Dieser Vorfall hat mir bewusst gemacht, wie viel Macht Menschen haben DNS. Eine Konfigurationszeile kann den Datenverkehr an jeden Server weiterleiten, ohne eine einzige Zeile auf dem Zielserver zu berühren.

Aber heute möchte ich die dunkle Seite derselben Geschichte besprechen. Was wäre, wenn die Fehlleitung nicht zufällig, sondern beabsichtigt wäre? Dh DNS-Poisoning – und Tools wie DNSMasq können das ganz einfach bewirken. Aber interessanterweise ist diese einst sehr mächtige Technik auf dem Vormarsch verliert angesichts moderner Anwendungen seine Reißzähne. Und noch wichtiger: Wie schützen wir unsere eigenen Dienste vor ähnlichen Angriffen?

DNS-Poisoning in DNSMasq – so einfach wie eine Konfigurationszeile

DNSMasq ist ein leichter DNS-Forwarder, der fast immer in jedem Linux- und eingebetteten Router vorhanden ist. Es ist für DNS- und DHCP-Caching konzipiert, verfügt aber auch über Funktionen --address, das DNS für bestimmte Domänen überschreiben kann: 

# Di /etc/dnsmasq.d/local-override.conf
address=/example.com/192.168.1.100
address=/mail.google.com/10.0.0.5

Mit der einen Zeile oben wird jedes Gerät im Netzwerk, das DNSMasq als DNS-Server verwendet, bei jedem Zugriff auf diese Domäne auf eine gefälschte IP umgeleitet. Dies Genau das Gleiche wie in der Geschichte mit der Fehlleitung des DNS-Routers – nur dass es bewusst und geplant geschah. Dies ist eine DNS-Vergiftung in ihrer ultimativen Form rein.

In dem von mir besprochenen Server-als-Router-Setup ist DNSMasq das DNS- und DHCP-Backbone. Der Server, der zum automatischen Gateway wird, hat die volle Macht, das DNS jedes Geräts im Netzwerk außer Kraft zu setzen. Dies ist nützlich für die Inhaltsfilterung oder die Weiterleitungsentwicklung – Aber in den falschen Händen ist es eine tödliche Waffe.

Aber warum schlägt es in modernen Anwendungen fehl?

Damals – Anfang der 2000er Jahre – war DNS-Poisoning einer der effektivsten Angriffe. Ein Angreifer in einem öffentlichen WLAN-Netzwerk kann das Ziel auf eine Phishing-Site leiten ohne ein bewusstes Ziel. Aber jetzt? Moderne Anwendungen verfügen über mehrere Verteidigungsebenen, die DNS-Poisoning für Spoofing praktisch unbrauchbar machen ihre Dienstleistungen.

1. Zertifikat-Pinning

Moderne Banking-, Social-Media- und Messaging-Apps führen das Zertifikat-Pinning durch – sie speichern den Hash eines gültigen TLS-Serverzertifikats. Selbst wenn eine DNS-Vergiftung eine Verbindung erfolgreich zum Server des Angreifers umleitet, lehnt die Anwendung die Verbindung ab, da das Zertifikat des Servers des Angreifers nicht mit dieser PIN übereinstimmt in der Anwendung gespeichert. Die Verbindung ist fehlgeschlagen, bevor Daten gesendet wurden.

Beispiel: WhatsApp-, Instagram- und TikTok-Anwendungen verfügen über ein hartes Zertifikat-Pinning. Versuchen Sie, ihre Domain auf eine gefälschte IP zu verweisen – es sind keine Seitenaufrufe, die passieren Phishing, aber Verbindungsfehler oder SSL-Handshake fehlgeschlagen.

2. DNS über HTTPS (DoH) und DNS über TLS (DoT)

In modernen Browsern wie Chrome, Firefox und Edge ist Secure DNS (DoH) standardmäßig aktiviert. Das bedeutet, dass DNS-Anfragen nicht mehr an den lokalen DNS-Server gesendet werden (wie DNSMasq auf einem Router), geht aber stattdessen über HTTPS direkt zum Upstream-DNS-Server. Chrome verfügt sogar über einen Fallback – wenn DoH fehlschlägt, kann es den DNS-Server versuchen hartcodierte Alternativen.

Das hat große Auswirkungen: DNS-Poisoning auf Router-Ebene hat keine Auswirkungen, da der Browser den Router nicht auffordert, die Domäne aufzulösen. Sie haben Cloudflare direkt gefragt (1.1.1.1), Google (8.8.8.8) oder andere DoH-Anbieter. Auf der nativen Anwendungsseite verwenden viele benutzerdefinierte DNS-Resolver – Bibliotheken wie c-ares oder Trusted DNS, das System-DNS ignoriert.

3. Hartcodierte IP-Adressen

Einige Anwendungen (insbesondere solche, die CDN-basiert sind oder über eigene Server verfügen) führen IP-Pinning durch und speichern eine Liste ihrer Server-IPs direkt im Code Anwendung. Eine DNS-Vergiftung ist nutzlos, da die Anwendung DNS überhaupt nicht auflöst. Sie verbinden sich direkt mit der angegebenen IP.

Beispiel: Anwendungen großer Unternehmen wie Google, Meta und Netflix verfügen über einige fest codierte IPs für kritische Dienste. Dies gilt nicht für alle Dienste. aber genug, um DNS-Poisoning als einzelnen Angriff nutzlos zu machen.

4. TLS-Validierung auf App-Ebene

Moderne Anwendungen verlassen sich bei der TLS-Validierung nicht ausschließlich auf das Betriebssystem. Sie verfügen über einen eigenen Vertrauensspeicher und strengere Validierungsrichtlinien. Selbst wenn ein gefälschtes Zertifikat in das System eingeschleust wird (z. B. über ein nicht vertrauenswürdiges Stammzertifikat), kann die Anwendung es erkennen und die Verbindung verweigern.

Beispiel: Anwendungen wie Signal, Telegram und Banking-Apps führen einen manuellen TLS-Handshake auf Anwendungsebene durch. Es ist ihnen egal, was das Betriebssystem sagt – das haben sie eigene Maßstäbe.

DNS-Poisoning ist also völlig nutzlos?

Nicht wirklich. DNS-Poisoning ist in einigen bestimmten Szenarien immer noch wirksam:

  • Websites ohne HTTPS – Es gibt immer noch viele Websites in internen oder lokalen Netzwerken, die kein HTTPS verwenden. DNS-Poisoning funktioniert hier immer noch einwandfrei.
  • Phishing über den Browser mit deaktiviertem DoH – viele Benutzer deaktivieren Secure DNS unwissentlich. Oder verwenden Sie einen alten Browser, der DoH nicht unterstützt.
  • Angriffe auf isolierte lokale Netzwerke – In Umgebungen, in denen Upstream-DNS nicht erreichbar ist, greift das Gerät auf lokales DNS zurück. Hier wirkt Vergiftung.
  • Weiterleitung zur Wartungsseite oder Blockseite – Dies ist eine legitime Verwendung, beispielsweise in Schulen oder Büros, die bestimmte Websites über internes DNS blockieren.

Aber um moderne Dienste wie soziale Medien, Banking-Apps oder Messaging-Apps zu fälschen, scheitert eine DNS-Vergiftung aufgrund der Schichten mit ziemlicher Sicherheit Verteidigung oben.

So schützen Sie unsere Dienste vor DNS-Poisoning

Wir wissen jetzt, dass DNS-Poisoning bei Angriffen auf moderne Anwendungen nicht mehr so effektiv ist wie früher. Aber wie sieht es mit unseren eigenen Dienstleistungen aus? Sind wir sicher vor ähnlicher Angriff?

Es gibt mehrere Verteidigungsebenen, die wir implementieren können – und interessanterweise haben wir einige davon im vorherigen Artikel besprochen Server als Router.

1. Alle DNS über den Server erzwingen – Alternative Port 53 blockieren

Durch die Einrichtung des Servers als Router haben wir die volle Kontrolle auf Firewall-Ebene. Eine der Gefahren einer DNS-Vergiftung besteht darin, dass Geräte im Netzwerk einen DNS-Server verwenden andere (z. B. öffentliches DoH). Die Lösung: Alle DNS-Anfragen an lokale Server umleiten und DoH für externe Server blockieren. 

# nftables — redirect port 53 ke DNSMasq lokal
table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        udp dport 53 redirect to 53
        tcp dport 53 redirect to 53
    }
}

# Blokir DoH ke Cloudflare, Google, Quad9
table ip filter {
    chain forward {
        type filter hook forward priority 0; policy accept;
        ip daddr 1.1.1.0/24 tcp dport 443 drop
        ip daddr 8.8.8.0/24 tcp dport 443 drop
        ip daddr 9.9.9.0/24 tcp dport 443 drop
    }
}

Mit diesen Firewall-Regeln:

  • Alle DNS-Anfragen an Port 53 – von jedem Gerät – werden an die lokale DNSMasq weitergeleitet
  • DoH zu öffentlichen Servern (Cloudflare, Google, Quad9) wird blockiert
  • Browser, die DoH ausprobieren, greifen auf das von uns kontrollierte reguläre DNS zurück

2. DNSSEC-Validierung in DNSMasq

DNSMasq unterstützt die DNSSEC-Validierung – einen Mechanismus, der sicherstellt, dass DNS-Antworten tatsächlich von autorisierenden Nameservern stammen und nicht auf halbem Weg modifiziert. Selbst wenn es einem Angreifer gelingt, DNS zu fälschen, wird mit DNSSEC die gefälschte Antwort abgelehnt, da die kryptografische Signatur ungültig ist. 

# Di /etc/dnsmasq.conf
conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec
dnssec-check-unsigned

Wichtiger Hinweis: DNSSEC validiert die Integrität der Antworten vom Upstream, verhindert jedoch keine Vergiftung auf lokaler Ebene. Wenn jemand die DNSMasq-Konfiguration ändert direkt auf dem Server hilft DNSSEC nicht. Aber um Angriffe von außerhalb des Netzwerks zu verhindern, ist es sehr effektiv.

3. Überwachung von DNS-Abfragen in Echtzeit

Wenn der Server als Router eingerichtet ist, laufen alle DNS-Anfragen über DNSMasq. Wir können die Protokollierung aktivieren, um verdächtige Muster zu überwachen: 

# Di /etc/dnsmasq.conf
log-queries
log-facility=/var/log/dnsmasq.log

Anhand dieser Protokolle können wir Anomalien erkennen wie:

  • Gerät löst plötzlich eine ungewöhnliche Domäne auf
  • Wiederholte DNS-Anfragen an dieselbe Domain innerhalb kurzer Zeit (Malware-Hinweis)
  • Domain wurde in eine IP aufgelöst, die sie nicht haben sollte

Ich persönlich verwende tail -f /var/log/dnsmasq.log für die Live-Überwachung. Aber in größerem Maßstab kann es in Dashboards wie integriert werden der im Serverartikel als Router besprochen wird – alle DNS-Protokolle gehen in die Datenbank und können visualisiert werden.

4. HTTPS mit HSTS und Zertifikat-Pinning

Eine DNS-Vergiftung ist nutzlos, wenn unser Dienst HTTPS ordnungsgemäß verwendet. Aber es gibt eine Lücke: Wenn der Benutzer zum ersten Mal auf unseren Dienst zugreift (first Verbindung) ist immer noch anfällig für MITM-Angriffe, wenn der Angreifer die erste Verbindung abfangen kann. Die Lösung:

  • HSTS (HTTP Strict Transport Security) – teilt dem Browser mit, dass auf diese Domain nur über HTTPS zugegriffen werden soll. Sobald der Browser den HSTS-Header erhält, Alle nachfolgenden Verbindungen werden über HTTPS erzwungen, auch wenn der Benutzer http://.
    • eingibt
  • HSTS Preload – Registrieren Sie die Domain mit hstspreload.org, damit der Browser bereits vor der ersten Verbindung weiß, dass Ihre Domain nur HTTPS ist.
  • Zertifikat-Pinning über HPKP (in Chrome veraltet) – moderne Alternativen können den Expect-CT-Header verwenden, um dies sicherzustellen gültiges Zertifikat.
# Di Nginx — HSTS header
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

5. Verwenden Sie einen sicheren DNS-Server für Upstream

DNSMasq ist nur eine Weiterleitung – es ist immer noch auf vorgelagerte DNS-Server angewiesen. Wenn der von uns verwendete Upstream-DNS-Server nicht sicher ist, sind alle darunter liegenden Schichten bedeutungslos. Verwenden Sie einen DNS-Server, der DNSSEC unterstützt und einen guten Ruf hat:

  • Cloudflare 1.1.1.1 (DNSSEC + DoH/DoT)
  • Google 8.8.8.8 (DNSSEC + DoH/DoT)
  • Quad9 9.9.9.9 (DNSSEC + Malware-Domänen blockieren)
# Di /etc/dnsmasq.conf
server=1.1.1.1
server=8.8.8.8
# Gunakan DoT atau DNSCrypt untuk enkripsi upstream
# (tapi itu topik artikel terpisah)

6. Firewall-Regeln – Verlassen Sie sich nicht nur auf DNS

DNS-Poisoning ist nur ein Angriffsvektor. Hat der Angreifer bereits Zugriff auf das lokale Netzwerk, kann er ARP-Spoofing durchführen bzw IP-Spoofing, das von keinem DNS verhindert werden kann. Daher bleiben Firewall-Regeln die letzte Verteidigung.

Bei der Einrichtung des Servers als Router haben wir die volle Kontrolle: 

# nftables — blokir koneksi langsung ke IP yang mencurigakan
table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        # hanya izinkan koneksi yang diperlukan
        ct state established,related accept
        iif lo accept
        tcp dport {22,80,443} accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        # izinkan forward hanya untuk device yang dikenal
        ip saddr 192.168.1.0/24 accept
    }
}

Schlussfolgerung

DNS-Poisoning über DNSMasq ist eine technisch einfach durchzuführende Technik – mit nur einer Konfigurationszeile können alle Geräte im Netzwerk auf einen gefälschten Server umgeleitet werden. Aber moderne Anwendungen haben sich mit Verteidigungsebenen wie Zertifikat-Pinning, DoH, hartcodierter IP und TLS-Validierung auf App-Ebene weiterentwickelt Dadurch ist diese Technik für das Spoofing großer Dienste wie Social Media oder Banking-Apps nahezu unbrauchbar.

Um unsere eigenen Dienste zu schützen, können wir uns jedoch nicht nur auf eine einzige Verteidigungsebene verlassen. Es ist ein Defense-in-Depth-Ansatz erforderlich:

  • Firewall zur Kontrolle des DNS-Verkehrs und zum Blockieren externer DoH
  • DNSSEC-Validierung zur Sicherstellung der Integrität von DNS-Antworten
  • DNS-Protokolle überwachen, um Anomalien zu erkennen
  • HTTPS + HSTS zur sicheren Verbindung
  • Vertrauenswürdiger Upstream-DNS

Die Geschichte der Router-DNS-Fehlleitung ist eine Erinnerung daran, dass ein einzelner Fehlerpunkt auf DNS-Ebene alles durcheinander bringen kann. Sondern indem wir verstehen, wie es funktioniert – und wie dagegen – wir können Systeme aufbauen, die viel widerstandsfähiger gegen Angriffe auf Netzwerkebene sind.

Wenn Sie es mit der Sicherung Ihres Heimnetzwerks oder Ihres kleinen Büronetzwerks ernst meinen, ist das Konzept eines Servers wie Der Router, den ich zuvor besprochen habe, ist die richtige Grundlage. Von dort aus können alle diese Sicherheitsebenen auf einem einzigen Kontrollpunkt aufgebaut werden: dem Linux-Server über die Sie selbst die Kontrolle haben.