So erkennst du DNS-Tunneling auf einem Linux-Server

Erkennen, wie ein DNS-Tunnel aussieht

Den DNS-Verkehr des Servers mit tcpdump mitschneiden

Installier tcpdump und für die Auswertung weiter unten tshark. Unter Debian und Ubuntu fragt der tshark-Installer, ob Benutzer ohne Root-Rechte mitschneiden dürfen: Antworte mit Nein.

sudo apt install tcpdump tshark

sudo dnf install tcpdump wireshark-cli

Zeichne fünf Minuten DNS-Verkehr auf, UDP und TCP, auf allen Schnittstellen. Mit systemd-resolved fragen Programme den lokalen Stub auf 127.0.0.53, und der Stub fragt weiter nach außen: -i any sieht beides.

sudo timeout 300 tcpdump -i any -nn -Z root -w /root/dns.pcap 'port 53'

Dann wertest du aus. Zuerst den Anteil jedes Anfragetyps: Viele TXT? oder NULL? fallen auf.

sudo tcpdump -nn -r /root/dns.pcap 'dst port 53' 2>/dev/null \
  | grep -oE '[A-Z0-9]+\? [^ ]+' | awk '{print $1}' | sort | uniq -c | sort -rn

Dann die Domains mit den meisten eindeutigen Namen darunter. Ein Tunnel bringt eine Domain mit Hunderten Namen an die Spitze; normaler Verkehr verteilt sich auf viele Domains mit jeweils wenigen Namen. (Die Zählung gruppiert nach den letzten beiden Labels, example.co.uk erscheint also als co.uk.)

sudo tcpdump -nn -r /root/dns.pcap 'dst port 53' 2>/dev/null \
  | grep -oE '[A-Z0-9]+\? [^ ]+' | awk '{print tolower($2)}' | sort -u \
  | awk -F. '{n = NF - 1; if (n >= 2) print $(n-1) "." $n}' | sort | uniq -c | sort -rn | head -20

Und die Namen mit einem Label von 30 oder mehr Zeichen:

sudo tcpdump -nn -r /root/dns.pcap 'dst port 53' 2>/dev/null \
  | grep -oE '[A-Z0-9]+\? [^ ]+' | awk '{print $2}' \
  | awk -F. '{for (i = 1; i < NF; i++) if (length($i) >= 30) {print; break}}' | sort -u | head -20

Dasselbe mit tshark

tshark liefert Statistiken nach Anfragetyp und Quelle und Ziel jeder Anfrage und findet ungewöhnlich große Antworten, mit denen Tunnel Daten zurückschicken:

sudo tshark -r /root/dns.pcap -q -z dns,tree
sudo tshark -r /root/dns.pcap -Y 'dns.flags.response == 0' -T fields \
  -e ip.src -e ip.dst -e dns.qry.type -e dns.qry.name | head -50
sudo tshark -r /root/dns.pcap -Y 'dns.flags.response == 1 && udp.length > 512' -T fields \
  -e dns.qry.name | sort | uniq -c | sort -rn | head

Die Resolver-Logs prüfen

Sieh dir zuerst an, welche Resolver der Server nutzen soll. Anfragen an jede andere Adresse sind schon für sich einen Blick wert.

cat /etc/resolv.conf
resolvectl status 2>/dev/null | grep -E 'DNS Servers|Current DNS'

systemd-resolved führt kein Anfrage-Log, zeigt aber ab systemd 252 (Debian 12, Ubuntu 24.04, RHEL 9 und neuer) jede Abfrage live an. Lass es ein paar Minuten laufen und achte auf lange zufällige Namen:

sudo resolvectl monitor

Betreibt der Server einen eigenen Resolver, schalte dessen Anfrage-Log ein. Bei unbound danach sudo systemctl restart unbound:

# /etc/unbound/unbound.conf (RHEL) or a file in /etc/unbound/unbound.conf.d/ (Debian, Ubuntu)
server:
    log-queries: yes
    log-replies: yes

sudo rndc querylog on

Beide schreiben ins Journal. Das listet die Namen mit einem Label von 30 oder mehr Zeichen aus der letzten Stunde:

sudo journalctl --since "1 hour ago" -u unbound -u named -u bind9 \
  | grep -ioE '([a-z0-9-]{30,}\.)+[a-z0-9.-]+' | sort | uniq -c | sort -rn | head -20

Das Programm hinter den Anfragen finden

DNS-Sockets leben nur Sekundenbruchteile, also nimm Stichproben: Das schaut eine Minute lang jede Sekunde nach und zählt die Programme, die einen DNS-Socket offen hatten. Programme, die den Stub von systemd-resolved fragen, erscheinen mit ihrem eigenen Namen, denn auch der Stub lauscht auf Port 53.

for i in $(seq 1 60); do sudo ss -unpH '( dport = :53 )'; sleep 1; done \
  | grep -o 'users:(("[^"]*",pid=[0-9]*' | sort | uniq -c | sort -rn

Steht systemd-resolve, unbound oder named oben, kommen die Anfragen über den Resolver von einem anderen Programm: Schneide noch einmal nur auf der Loopback-Schnittstelle mit (-i lo) und vergleiche die Zeiten. Bei einem Programm, das du nicht kennst, sieh dir die Binärdatei, den Ordner und die Unit an, die es gestartet hat:

sudo ls -l /proc/PID/exe /proc/PID/cwd
sudo tr '\0' ' ' < /proc/PID/cmdline; echo
systemctl status PID

Ein Tunnel-Client ist ein Zeichen einer Kompromittierung, nicht die Kompromittierung selbst. Such nach dem Rest wie in Krypto-Miner auf dem Server finden und entfernen: Persistenz in cron, systemd und SSH-Schlüsseln, veränderte Systembinärdateien und der Weg, auf dem der Angreifer hereinkam.

Den Tunnel sperren

Stopp zuerst das Programm. Sorg dann dafür, dass DNS den Server nur über die Resolver verlassen kann, die du gewählt hast: Diese nftables-Tabelle verwirft DNS an jede andere Adresse und DNS over TLS überall. Ersetze 192.0.2.53 durch deine Resolver aus Schritt 3 (mehrere durch Kommas getrennt).

sudo nft add table inet dnsguard
sudo nft 'add chain inet dnsguard out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet dnsguard out ip daddr != { 127.0.0.0/8, 192.0.2.53 } meta l4proto { tcp, udp } th dport 53 drop
sudo nft add rule inet dnsguard out tcp dport 853 drop

Ein Tunnel über deinen eigenen Resolver funktioniert weiter, weil der Resolver die Anfragen weiterleitet. Wenn du unbound betreibst, beantworte die Tunnel-Domain mit „existiert nicht“:

# In the server: section of unbound.conf
    local-zone: "tunnel.example." always_nxdomain

sudo unbound-checkconf && sudo systemctl restart unbound

Mit systemd-resolved allein gibt es keine Sperre pro Domain: Richte den Server auf einen Resolver aus, der das kann, oder verlass dich darauf, das Programm zu entfernen. /etc/hosts hilft nicht, weil es nicht jede Subdomain abdecken kann.

Fragen

Meine Firewall sperrt ausgehenden Verkehr. Kann DNS-Tunneling trotzdem funktionieren?

Ja, wenn der Server einen Resolver fragen darf, und das darf fast jeder Server. Der Resolver leitet die Anfragen für dich an den Nameserver des Angreifers weiter. Deshalb muss auch der Resolver die Domain sperren, oder das Programm muss weg.

Stoppen DNSSEC oder DNS over HTTPS das?

Nein. DNSSEC belegt, dass Antworten echt sind, und die Antworten des Angreifers sind für seine eigene Domain echt. DNS over HTTPS verbirgt die Anfragen vor dem Netzwerk, was einen Tunnel schwerer erkennbar macht, aber nicht unmöglich.

Welcher legitime Verkehr sieht wie ein Tunnel aus?

Abfragen von Virenscannern und Reputationsdiensten, die Datei-Hashes in Namen kodieren, die Blocklist-Prüfungen eines Mailservers sowie manche CDN-, Cloud- und Telemetrie-Namen. Schlag die Domain nach, bevor du handelst.