Come rilevare il DNS tunneling su un server Linux

Riconoscere un tunnel DNS

Catturare il traffico DNS del server con tcpdump

Installa tcpdump, e tshark per l'analisi più avanti. Su Debian e Ubuntu l'installazione di tshark chiede se gli utenti non root possono catturare: rispondi no.

sudo apt install tcpdump tshark

sudo dnf install tcpdump wireshark-cli

Registra cinque minuti di traffico DNS, UDP e TCP, su tutte le interfacce. Con systemd-resolved i programmi chiedono allo stub locale su 127.0.0.53 e lo stub chiede all'esterno: -i any vede entrambi.

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

Poi leggilo. Prima la quota di ogni tipo di query: tanti TXT? o NULL? saltano all'occhio.

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

Poi i domini con più nomi unici sotto di sé. Un tunnel porta in cima un solo dominio con centinaia di nomi; il traffico normale si distribuisce su molti domini con pochi nomi ciascuno. (Il conteggio raggruppa per le ultime due etichette, quindi example.co.uk compare come 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

E i nomi con un'etichetta di 30 caratteri o più:

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

Lo stesso con tshark

tshark dà le statistiche per tipo di query, l'origine e la destinazione di ogni query, e trova le risposte insolitamente grandi, che i tunnel usano per riportare indietro i dati:

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

Controllare i log del resolver

Guarda prima quali resolver il server è configurato per usare. Le query verso qualunque altro indirizzo meritano già da sole un'occhiata.

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

systemd-resolved non tiene un log delle query, ma da systemd 252 (Debian 12, Ubuntu 24.04, RHEL 9 e successivi) mostra ogni ricerca in tempo reale. Lascialo girare qualche minuto e cerca nomi lunghi e casuali:

sudo resolvectl monitor

Se il server ha un suo resolver, attivane il log delle query. Per unbound, poi 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

Entrambi scrivono nel journal. Questo elenca i nomi con un'etichetta di 30 caratteri o più dell'ultima ora:

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

Trovare il programma dietro le query

I socket DNS vivono una frazione di secondo, quindi vanno campionati: questo guarda una volta al secondo per un minuto e conta i programmi che avevano un socket DNS aperto. I programmi che interrogano lo stub di systemd-resolved compaiono con il loro nome, perché anche lo stub ascolta sulla porta 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

systemd-resolve, unbound o named in cima vuol dire che le query passano dal resolver, da parte di un altro programma: ripeti la cattura solo sull'interfaccia di loopback (-i lo) e confronta gli orari. Per un programma che non conosci, guarda il binario, la cartella e l'unità che lo ha avviato:

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

Un client di tunnel è il segno di una compromissione, non la compromissione stessa. Cerca il resto come in Come trovare e rimuovere un crypto miner dal server: persistenza in cron, systemd e chiavi SSH, binari di sistema modificati, e come è entrato l'attaccante.

Bloccare il tunnel

Ferma prima il programma. Poi fai in modo che il DNS possa uscire solo dai resolver che hai scelto: questa tabella nftables scarta il DNS verso qualunque altro indirizzo, e il DNS over TLS ovunque. Sostituisci 192.0.2.53 con i tuoi resolver del passo 3 (più di uno, separati da virgole).

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

Un tunnel attraverso il tuo resolver funziona ancora, perché il resolver inoltra le query. Se usi unbound, rispondi al dominio del tunnel con "non esiste":

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

sudo unbound-checkconf && sudo systemctl restart unbound

Con il solo systemd-resolved non c'è un blocco per dominio: punta il server a un resolver che sappia farlo, o affidati alla rimozione del programma. /etc/hosts non aiuta, perché non può coprire ogni sottodominio.

Domande

Il mio firewall blocca il traffico in uscita. Il DNS tunneling può funzionare lo stesso?

Sì, se il server può interrogare un resolver, e quasi ogni server può. È il resolver a inoltrare le query al name server dell'attaccante. Per questo anche il resolver deve bloccare il dominio, oppure il programma deve sparire.

DNSSEC o DNS over HTTPS lo fermano?

No. DNSSEC dimostra che le risposte sono autentiche, e le risposte dell'attaccante sono autentiche per il suo dominio. DNS over HTTPS nasconde le query alla rete, il che rende un tunnel più difficile da vedere, non impossibile da costruire.

Quale traffico legittimo somiglia a un tunnel?

Le ricerche di antivirus e reputazione che codificano gli hash dei file nei nomi, i controlli sulle blocklist di un server di posta, e alcuni nomi di CDN, cloud e telemetria. Controlla il dominio prima di agire.